• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 541 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

pcie MSI handler appears to have a timing problem

Gary Green1
Prodigy 90 points

Am testing the pcie interface with MSI on a dm8148 EVM using ezsdk 5.03.01.15.  As noted in another post, the main problem is a polarity issue in ack_msi() in /arch/arm/mach-omap2/pcie-ti81xx.c.  Writing a one instead of a zero to acknowledge MSI interrupts appears to work.

A second problem is that ti81xx_msi_handler() only works if CONFIG_PCI_DEBUG=y in the kernel configuration.  After patching ack_msi() and rebuilding the kernel, I ran several thousand transfers to test MSI functionality and it worked.  Until I disabled pci debugging in the kernel.  Then I only get one MSI interrupt, which appears to be waiting for an ack.  The difference between MSI working and non-working is the statement:

        pr_debug(DRIVER_NAME ": Handling MSI irq %d\n", irq);   // noop unless CONFIG_PCI_DEBUG=y

If we respond to an MSI interrupt too fast, the ack apparently gets dropped.  Is this behavior documented anywhere in the dm8148 technical documentation?  An obvious workaround is to always configure the kernel with CONFIG_PCI_DEBUG=y so the pcie MSI handling works correctly on the dm8148.  Besides the workaround, is there a known fix for this problem?

  • 0
    TI__Expert 5685 points

    Gary Green1 said:

    Am testing the pcie interface with MSI on a dm8148 EVM using ezsdk 5.03.01.15.  As noted in another post, the main problem is a polarity issue in ack_msi() in /arch/arm/mach-omap2/pcie-ti81xx.c.  Writing a one instead of a zero to acknowledge MSI interrupts appears to work.

    Yes, that change is mandatory when using the driver with DM8148 for MSI.

    Gary Green1 said:

    If we respond to an MSI interrupt too fast, the ack apparently gets dropped.

    Can you explain more on this? How are you sure that the ack is dropped? Have you ruled out any target driver issue - do you see the target device sending further MSI interrupts but are not handled by DM8148 - a PCIe packet capture could explain that.

    Thanks.

  • 0 in reply to HemantPedanekar
    Prodigy 90 points

    Hermant,

    1. The target device makes a pcie data transfer, signals completion with an MSI, and waits for the MSI to be acknowledged.  As far as I can tell, the target will not do anything else until the MSI is acknowledged.

    2. Regarding target driver issues, we can connect the target to a dm8168 board and run the same test.  It works every time.  The 8168 kernel configuration does NOT have CONFIG_PCI_DEBUG enabled.  If we connect the target to the dm8148 EVM and enable pci debugging, it works every time.  Build the 8148 kernel with pci debugging disabled and we only get ONE transfer.  The target appears to be waiting for the host to acknowledge the MSI interrupt - indefinitely.

    3. The question remains, why doesn't an MSI get acknowledged by the host when pci debugging is disabled in the kernel?  The software goes through the steps, but the target is STILL waiting for an ack.That looks like a dropped ack.

    4. No possibility of a PCIe packet capture.  I don't have the time and necessary lab equipment.

    5. As far as I can tell from the discussions on the forum, nobody else has msi working at all on the dm8148 processor.  The users talk about implementing the polarity patch already noted, then reverting to legacy interrupts because "something is wrong with MSI".  We have MSI working, but only when pci debugging is enabled.  How do I make it work without enabling pci debugging in the kernel?

    Thanks - Gary

  • 0 in reply to Gary Green1
    TI__Expert 5685 points

    Gary,

    Regarding "target will not do anything else until the MSI is acknowledged" - can you explain what does this mean? Is the target s/w waiting for some handshake from the s/w on root complex (DM8148)?

    Otherwise there is no real ack that will be sent to the target in case of MSI here.