TDA4VM: PCIe Sending Interrupt from EP to RC via PCIe Core Downstream Interrupts

Hi, I would like to ask if there is any update of this?

Best regards,
Thomas

Hi Thomas,

The downstream interrupt is directly connected to the interrupt controller. Don't need SYSFW to configure. You can directly configure

GIC_SPI_IN_345 / 357 / 369 / 381 in the DT node (depending on the PCIe instance that you'd like to use) and register a handler in the driver.

In device tree, add something like below
+		interrupt-names = "downstream";
+		interrupts = <GIC_SPI 313 IRQ_TYPE_EDGE_RISING>;

And in driver pci-j721e.c

static irqreturn_t j721e_pcie_downstream_irq_handler(int irq, void *priv)
+{
+<handle interrupt>
+}

+static int j721e_pcie_probe(struct platform_device *pdev)

+{

+	irq = platform_get_irq_byname(pdev, "downstream");
+	if (irq < 0)
+		return irq;
+

+	ret = devm_request_irq(dev, irq, j721e_pcie_downstream_irq_handler,
+			       IRQF_SHARED, "j721e-pcie-downstream-irq", pcie);
+	if (ret < 0) {
+		dev_err(dev, "failed to request downstream IRQ %d\n", irq);
+	}

Hi Kishon,

thank you very much for pushing me into the right direction.

I would like to leave this thread open for the next days, for the case any new problems rise up!

Thanks & best regards,
Thomas

Thomas,

Sounds good.. Sure, we can leave it in a state that you can reply.

Please reply back on this post whenever you have further updates.

Regards

Karthik

Hi Kishon and Karthik,

I have some questions left, but I'm sure these are easy to answer.

My state is this: I implemented the example code from Kishon (thank you very much) on EP device.

I generate a downstream interrupt, whereas I connect via CCS to the EP TDA4 and following these steps:

1. Enable PCIE_DOWNSTREAM_PULSE by writing “1” in register PCIE_INTD_ENABLE_REG_SYS_1 [Bit 29], this will allow CP_INTD to aggregate   F0_VSEC_INTERRUPT_OUT;

2. Write HTI bit of the PCIE_CORE_PFn_I_VENDOR_SPECIFIC_CONTROL_REG register, this will cause the VSEC interrupt. Writing can be either from remote RC or via local interface;

3.We expect to see status bit set in PCIE_INTD_STATUS_REG_SYS_1 register, as well as seeing an interrupt coming to GIC. We had following interrupt connection:

So basically, I write (step 1) 0x2000 0000 to address 0x0290 0104, then (step 2) 0x300 to 0x0d00 0408, and verify (step 3)  value 0x2000 0000 at address 0x0290 0504.

This triggers the linux kernel interrupt handler "j721e_pcie_downstream_irq_handler". So far so good!

My questions are:

Q1: After writing on the registers, all three registers do not change after executing the linux interrupt handler. The PCIE_CORE_PFn_I_VENDOR_SPECIFIC_CONTROL_REG has still the value 0x300. Does the linux interrupt handler need to take care, to reset something (registers) to "prepare" the PCIe module for the next interrupt?

Q2: Kishon, first I thought you got a typo in the devicetree GIC_SPI interrupt number (313 instead of 345). But this is correct. Why is there a value shift of 32?

Q3: I "manually" generated the downstream interrupt on the EP via connecting CCS to EP and writing on the PCIe module registers. How should I generate the interrupt from a remote host ( RC? ).
Should I map BAR memory from EP to the PCIe module registers of EP, to access these registers from remote RC? Or does exist an alternative to that?

Very best regards,
Thomas

Hi Thomas,

A1: Since it is a pulse interrupt you have to reset PCIE_INTD_STATUS_REG_SYS_1 by writing to PCIE_INTD_STATUS_CLR_REG_SYS_1.

A2: The SPI interrupt in ARM GIC starts at interrupt number 32, so we just specific "GIC SPI" and the interrupt number in GIC SPI.

A3: You can also directly write to it using the configuration space access so mapping BAR is not required.

Thanks

Kishon