How to know when tda4 pcie-ep received a PCI transaction from host ASAP

Jun Li4

When I use tda4 as a PCIe endpoint device, refer to linux SDK's ep test, I configured a dram memory region mapped to BAR0 register, I need to know what command be written by host, ep test(pci_epf_test_cmd_handler) read it per 1ms, it will cause ep device response this command with a delay and consume ep's cpu resource. Is there a way can notify or interrupt ep's cpu when ep received any PCI transaction? If yes, ep firmware can know when host write BAR as soon as possible, and cpu can get idle when no transaction from host.

over 6 years ago

0 Victor Kazmirenko over 6 years ago

Guru 13202 points

I apologize of could misunderstood your situation.

If the point is to know whether previous transaction has finished, one may disable transactions reordering on PCIe and issue read transaction to same memory after write. Return from read transaction would implicitly indicate previous write transaction has already finished.

If your objective is to trigger interrupt to EP, then one may consider MSI from RC towards EP. TI devices normally implement this feature, but you'd better check with TDA4 guru.

0 Jun Li4 over 6 years ago in reply to Victor Kazmirenko

Prodigy 200 points

Hi rrlagic,

Thanks for your quick response.

My objective is the second, I think your suggestion is let ep map gic-its register to a BAR inbound, and host write this BAR to trigger a MSI interrupt to ep, right? I can understand this may be a valid solution, but host always needs additional BAR write operation, is there anther way ep can be interrupted when ep controller received any memory transaction? so ep firmware can use it to know host has write cmd BAR as soon as possible.

Thanks,

Jun

Congratulations to Abby

0 Victor Kazmirenko over 6 years ago in reply to Jun Li4

Guru 13202 points

Hi again,

I had to start with disclaimer again, that I have no practical experience with TDA4 and things might differ for your device.

First, about BAR mappings for MSI generation. In C66x BAR0 in both RC & EP mode was mapped to PCIe Application registers and could not be remapped to any other memory region. Thus, this way we never lose BAR, it was matter of using it or not using. Consequently, for the host system the price is another memory window. In C66x we have dedicated register in App space, writing integer to which triggers MSI vector. I hope something similar exist in TDA4s as well. I do not know about other non-peripheral provided mechanisms where memory write would trigger event.

Meanwhile I'd like to suggest you other ways to accomplish your goal. As an example, you may stop using host to write data. Instead, host may prepare data buffer and trigger interrupt to TDA4. The SoC would use DMA to read data from host's memory, and DMA completion can be used as notification event for processing.

0 jian35385 over 5 years ago in reply to Victor Kazmirenko

TI__Mastermind 23125 points

Hi Jun,

I see you and RR discussed three options:

1. MSI/X - Host first write data then trigger an interrupt to EP. You tried to avoid the interrupt generation. One minor note here - MSI/X is specifically defined for EP to generate interrupt to RC, not the other way around. But the TDA4 controller has a vendor-specific capability register, F0_VSEC_INTERRUPT_OUT, that can be used for RC to trigger an interrupt to EP.

2. As RR suggested, instead of RC to write to EP, RC just prepare data buffer, then use the above method to trigger a interrupt to EP, then EP will DMA from RC memory. Do you have other system restrictions that can not fetch data via PCIe "on-demand"?

Jian