From: "Pali Rohár" <pali@kernel.org>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: "Marek Behún" <kabel@kernel.org>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Bjorn Helgaas" <helgaas@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 03/11] PCI: aardvark: Add support for DLLSC and hotplug interrupt
Date: Tue, 27 Sep 2022 13:13:57 +0200 [thread overview]
Message-ID: <20220927111357.wctpynl6lmr5ei3a@pali> (raw)
In-Reply-To: <YzK0Zo6+5OoVwirK@lpieralisi>
Hello! Just briefly from my side, but Marek would probably answer it
better.
On Tuesday 27 September 2022 10:29:26 Lorenzo Pieralisi wrote:
> Better, certainly. Question, also related to Marc's query. Do you
> rely on the hotplug (emulated IRQ) to be run _before_ carrying on
> with PCI config space accesses following a link-up detection ?
During PCI config space access is PCI core code holding atomic raw spin
lock, so link-up check from PCI config space can throw emulated HP IRQ
only _after_ config space is finished (when IRQs are unmasked again). So
it happens after (not before).
> How was the jiffies + 1 expiration time determined ?
jiffies + 1 was chosen as the earliest possible time when HP IRQ can be
thrown. Somebody said to me (year or more ago, no remember who and
when) that I cannot use just "jiffies", I have to use "jiffies + 1", so
timer would be scheduled after my call finish, which is after PCI config
space access finish. jiffies + 1 should be the earliest possible time
with the highest priority.
> I assume you
> want to run the emulated HP IRQ asap - the question though is
> how fast should it be ?
HP IRQ should be thrown _ASAP_ when we know that link is up, so PCIe HP
driver can handle it and do its job. Just like for hardware which fully
and correctly supports link up HP IRQs.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-09-27 11:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 13:51 [PATCH 00/11] PCI: aardvark controller changes BATCH 6 Marek Behún
2022-08-18 13:51 ` [PATCH 01/11] PCI: pciehp: Enable DLLSC interrupt only if supported Marek Behún
[not found] ` <20220821124621.GA23239@wunner.de>
2022-08-22 10:37 ` Marek Behún
2022-08-18 13:51 ` [PATCH 02/11] PCI: pciehp: Enable Command Completed Interrupt " Marek Behún
2022-09-28 8:39 ` Lorenzo Pieralisi
2022-08-18 13:51 ` [PATCH 03/11] PCI: aardvark: Add support for DLLSC and hotplug interrupt Marek Behún
2022-09-09 14:57 ` Lorenzo Pieralisi
2022-09-16 16:23 ` Marek Behún
2022-09-27 8:29 ` Lorenzo Pieralisi
2022-09-27 11:13 ` Pali Rohár [this message]
2022-09-27 15:57 ` Lorenzo Pieralisi
2022-09-17 9:05 ` Marc Zyngier
2022-09-26 11:49 ` Lorenzo Pieralisi
2022-09-26 12:35 ` Marc Zyngier
2022-09-26 14:00 ` Lorenzo Pieralisi
2022-09-27 13:40 ` Marek Behún
2022-08-18 13:51 ` [PATCH 04/11] PCI: aardvark: Send Set_Slot_Power_Limit message Marek Behún
2022-08-18 13:51 ` [PATCH 05/11] arm64: dts: armada-3720-turris-mox: Define slot-power-limit-milliwatt for PCIe Marek Behún
2022-08-18 13:51 ` [PATCH 06/11] PCI: aardvark: Add clock support Marek Behún
2022-08-18 13:51 ` [PATCH 07/11] PCI: aardvark: Add suspend to RAM support Marek Behún
2022-09-09 10:33 ` Lorenzo Pieralisi
2022-09-27 8:30 ` Lorenzo Pieralisi
2022-08-18 13:51 ` [PATCH 08/11] PCI: aardvark: Replace custom PCIE_CORE_ERR_CAPCTL_* macros by linux/pci_regs.h macros Marek Behún
2022-08-18 13:51 ` [PATCH 09/11] PCI: aardvark: Don't write read-only bits explicitly in PCI_ERR_CAP register Marek Behún
2022-08-18 13:51 ` [PATCH 10/11] PCI: aardvark: Explicitly disable Marvell strict ordering Marek Behún
2022-08-18 13:51 ` [PATCH 11/11] PCI: aardvark: Cleanup some register macros Marek Behún
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220927111357.wctpynl6lmr5ei3a@pali \
--to=pali@kernel.org \
--cc=helgaas@kernel.org \
--cc=kabel@kernel.org \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=lpieralisi@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).