TDA4VM: AM68A Pcie

Hello D.,

It seems Kishon has left TI since that post, so I will need some time to determine what he meant by his comment of using the configuration space access, and furthermore to provide code snippet examples.

In order to understand the question more, could you clarify what the end goal is? Is it to send an interrupt from EP to RC, assuming EP and RC are both TDA4VM devices?

Regards,

Takuma

HI Takuma,

thank you for comments, we are looking forward for the explanation.

The end goal is to send an interrupt from RC to EP, assuming that RC is a Linux PC and Ep is a AM68A (J721S2) device.

Best Regards.

d.

Hi Takuma,

we are aware of the documentation, but we need to send the interrupt from RC ( linux PC) to EP ( AM68A/J721S2).

Best Regards,

d.

Hi Takuma,

thank you for the feedback.

1)

We also found this section in the TRM but we are missing the register description in j721s2_public_combined_registers.xlsx (spruj28c)

We are missing the following register description

PCIE_CORE_PFn_I_VENDOR_SPECIFIC_CONTROL_REG

PCIE_INTD_REVISION
PCIE_INTD_EOI_REG
PCIE_INTD_INTR_VECTOR_REG
PCIE_INTD_ENABLE_REG_SYS_0
PCIE_INTD_ENABLE_REG_SYS_1
PCIE_INTD_ENABLE_REG_SYS_2
PCIE_INTD_ENABLE_CLR_REG_SYS_0
PCIE_INTD_ENABLE_CLR_REG_SYS_1
PCIE_INTD_ENABLE_CLR_REG_SYS_2
PCIE_INTD_STATUS_REG_SYS_0 0290
PCIE_INTD_STATUS_REG_SYS_1 0290
PCIE_INTD_STATUS_REG_SYS_2 0290
PCIE_INTD_STATUS_CLR_REG_SYS_0
PCIE_INTD_STATUS_CLR_REG_SYS_1
PCIE_INTD_STATUS_CLR_REG_SYS_2
PCIE_INTD_INTR_VECTOR_REG_SYS

2) Do you have a code snippet on how to setup the interrupt in the AM68A device tree ?

3) Here are our code snippets for RC and EP please can you check the code and register values.

--------------------------------------------------------------------------------------------

RC side

#define PCIE_CORE_PFn_I_VENDOR_SPECIFIC_CONTROL_REG 0x0408



static void j7vnet_host_raise_ep_data_irq(struct j7vnet_priv *j7vnet)
{
u8 ep_irq_data_id;

ep_irq_data_id = READ_ONCE(j7vnet->bar_md->ep_irq_data_id);
ep_irq_data_id++;
WRITE_ONCE(j7vnet->bar_md->ep_irq_data_id, ep_irq_data_id);
smp_mb();
pci_write_config_dword(j7vnet->pdev, PCIE_CORE_PFn_I_VENDOR_SPECIFIC_CONTROL_REG, 0x300);
}

EP side

irq = platform_get_irq_byname(j7vnet_ep->pdev, "pcie0_downstream");
	if (irq < 0) {
		dev_err(dev, "%s: pcie0_downstream not found\n", __func__);
		return irq;
	}

	ret = devm_request_irq(dev, irq, j7vnet_ep_irq_downstream,
			0, "pcie0-downstream-irq", j7vnet_ep);
	if (ret < 0) {
		dev_err(dev, "%s: failed to request pcie0 downstream IRQ %d\n", __func__, irq);
		return ret;
	}
	// Enable downstream interrupt
	writel(0xFF000000, j7vnet_ep->pcie0_intd_cfg + PCIE0_INTD_ENABLE_REG_SYS_1);

Best Regards,

d.

Hi D.,

Apologies for the delay, but I will need a couple of more days to confirm some things with the broader team.

There seems to be a possibility that signalling interrupts from RC to EP has been descoped in terms of support/software because as I mentioned in my previous posts, signalling interrupt from RC to EP is not a typical use case and undefined in terms of PCIe standard specifications. My colleague mentions that for notifying from RC to EP, we would have to rely on polling shared memory locations or similar means instead.

Currently, checking with others to see if this statement is true, but again, I will need a few more days to get alignment on the status for these vendor specific registers.

Regards,

Takuma

Dear Takuma,

do you have any update?

Best Regards,

d.

Hi D.,

It is looking like interrupt signaling from RC to EP is no longer supported. What I can say for sure is that we do not have an example for RC to EP interrupt, and we only have EP to RC interrupt.

I think this is mainly due to RC to EP interrupt signaling not being a standard usecase defined by PCIe specification, and due to this, many standard PCIe devices that are non-TI does not support this feature.

The recommendation is using a polling method.

Regards,

Takuma

Hello D.,

Please note that I'm not TI, just another customer.

Not sure if polling is a viable alternative for your application.

Saying that this is unsupported because it's not covered by the PCIe specification is a bit too easy in my opinion. Your regular PCIe endpoint is "hardware", and if it's custom it is an FPGA or maybe an ASIC. With these devices every write could "trigger" an action in the EP, so no need for a dedicated "interrupt action", plus there's usually no CPU that could be interrupted, so defining it in a generic way makes little sense. For a software EP a means to interrupt the CPU seems rather critical to me.

I haven't used the AM68A yet and I didn't have to do it under Linux, but we've successfully used the downstream interrupt (i.e. RC->EP) on an AM64x with a mixture of TI's MCU+ SDK driver and custom code. The AM68A's PCIe controller is very similar with more features (e.g. multiple physical functions). Hardware-wise this should work. Unfortunately I don't have access to our unfinished prototype code right now. If this is still of interest for you I guess I could look it up next week.

An alternative to the cadence specific downstream functionality might be reusing MSIs. The Cortex-A's GIC (not all, but true for the AM6* series from what I've seen) for example is already able to handle inbound writes to trigger interrupts. From a brief look I found a patch series from April this year that might do just what you need:

https://lore.kernel.org/lkml/20230426203436.1277307-1-Frank.Li@nxp.com/

Regards,

Dominic