Thread (28 messages) 28 messages, 9 authors, 2019-12-03

Re: [PATCH v3 5/7] PCI: brcmstb: add MSI capability

From: Nicolas Saenz Julienne <hidden>
Date: 2019-12-02 10:00:10
Also in: linux-pci, lkml

Hi Andrew,

On Fri, 2019-11-29 at 15:46 +0000, Andrew Murray wrote:
On Tue, Nov 26, 2019 at 10:19:43AM +0100, Nicolas Saenz Julienne wrote:
quoted
From: Jim Quinlan <redacted>

This adds MSI support to the Broadcom STB PCIe host controller. The MSI
controller is physically located within the PCIe block, however, there
is no reason why the MSI controller could not be moved elsewhere in the
future. MSIX is not supported by the HW.

Since the internal Brcmstb MSI controller is intertwined with the PCIe
controller, it is not its own platform device but rather part of the
PCIe platform device.

Signed-off-by: Jim Quinlan <redacted>
Co-developed-by: Nicolas Saenz Julienne <redacted>
Signed-off-by: Nicolas Saenz Julienne <redacted>
Reviewed-by: Marc Zyngier <maz@kernel.org>

---

Changes since v2 (kept Marc's Reviewed-by as changes didn't affect irq
subsystem stuff or seem petty enough):
  - Use standard APIs on register operations
  - Get rid of revision code
Do any RPI4's have a HW revision of less than 33?
No, IIRC it's actually revision 34. I had left that bit of code in, following
the same train of thought as with the of_data on the device-tree part of the
driver: "It's harmless and should make accomodating other devices easier." It
turned out not to be such a great approach. Lesson's learned. So I decided to
remove it.
quoted
  - Update rules to msi_target_addr selection
  - Remove unwarranted MSI_FLAG_PCI_MSIX
  - Small cosmetic changes

Changes since v1:cuando tenías tu vacaciones?
  - Move revision code and some registers to this patch
  - Use PCIE_MSI_IRQ_DOMAIN in Kconfig
  - Remove redundant register read from ISR
  - Fail probe on MSI init error
  - Get rid of msi_internal
  - Use bitmap family of functions
  - Use edge triggered setup
  - Add comment regarding MultiMSI
  - Simplify compose_msi_msg to avoid reg read

This is based on Jim's original submission[1] with some slight changes
regarding how pcie->msi_target_addr is decided.

[1] https://patchwork.kernel.org/patch/10605955/

 drivers/pci/controller/Kconfig        |   1 +
 drivers/pci/controller/pcie-brcmstb.c | 261 +++++++++++++++++++++++++-
 2 files changed, 261 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 27504f108ee5..918e283bbff1 100644
+
+static void brcm_msi_compose_msi_msg(struct irq_data *data, struct msi_msg
*msg)
+{
+	struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
+
+	msg->address_lo = lower_32_bits(msi->target_addr);
+	msg->address_hi = upper_32_bits(msi->target_addr);
+	msg->data = 0x6540 | data->hwirq;
NIT: Perhaps this 0x6540 can be a define - just in the same way we have a
define
for PCIE_MISC_MSI_DATA_CONFIG_VAL.
Noted

Regards,
Nicolas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help