<div dir="ltr"><div><br></div>Hi All,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 30, 2013 at 11:36 PM, David Hawkins <span dir="ltr"><<a href="mailto:dwh@ovro.caltech.edu" target="_blank">dwh@ovro.caltech.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi S.Saravanan,<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
<br>
I successfully mapped the Programmable Interrupt Controller registers<br></div>
in the EP to the PCI space. Thus now I can write the shared message<div class="im"><br>
interrupt registers in the EP from the RC over PCI.<br>
</div></blockquote>
<br>
Excellent.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But I am facing the following problems now.<br>
<br>
1) In my driver at EP, to register for this interrupt I need to know the<br>
hardware irq number but I can't find any interrupt number assigned by<br>
the PIC for the messages interrupt sources(Page 451 , MPC8641DRM manual).<br>
2) Otherwise i need to get the virtual irq number assigned by kernel<br>
corresponding to the message interrupt . I am unable to find a method to<br>
get this also.<br>
</blockquote>
<br></div>
I recall having to ask a similar question when trying to map a<br>
GPIO interrupt into a Linux interrupt number. I forget the<br>
convention (I'm "the hardware guy"). It may be a device tree<br>
thing, or an offset, I'll let someone more knowledgeable comment.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
In the RC side driver i get the virtual irq number after calling<br>
pci_enable_msi() which is straightforward.<br>
I studied the RC code which sets up shared message interrupts (Page 481,<br>
MPC manual) for PCI MSI interrupts . When msi is enabled the<br>
"arch_setup_msi_irqs()" is called leading to the fsl_setup_msi_irqs()<br>
(<a href="http://lxr.free-electrons.com/source/arch/powerpc/sysdev/fsl_msi.c?v=3.7#L151" target="_blank">http://lxr.free-electrons.<u></u>com/source/arch/powerpc/<u></u>sysdev/fsl_msi.c?v=3.7#L151</a>)<br>
. In this function the virtual irq no is obtained as below:<br>
<br></div>
/virq = irq_create_mapping(msi_data-><u></u>irqhost, hwirq);/<div class="im"><br>
<br>
In the above function the hardware irq number is same as the value<br>
written into the Shared Message Signaled Interrupt Index Register (Page<br>
482) which is strange. Further these functions are called in the RC<br>
during pci_probe at boot time or when pci_enable_msi() is called . Thus<br>
there is a always a PCI slave device context to it. However I require<br>
to do it in the EP which has no pci probing nor any pci device<br>
reference whatsoever as it a slave. Is this approach right ?<br>
</div></blockquote>
<br>
I'm not sure.<br>
<br>
You'll have two drivers;<br>
* The root-complex.<br>
This is a standard PCIe driver, so you'll just follow convention<br>
there<br>
* The end-point driver.<br>
This driver needs to use the PCIe bus, but its not responsible<br>
for the PCIe bus in the way a root-complex is. The driver needs<br>
to know what the root-complex is interrupting it for, eg.,<br>
"transmitter empty" (I've read your last message) or "receiver<br>
ready" (there is a message from me, waiting for you).<br>
So you need at least two unique interrupts or messages from the<br>
root-complex to the end-point.<br>
</blockquote><div><br></div><div>I am happy to inform you that I finally found a way to register for the interrupts from RC to EP. Now I have made a simple root and end point network driver for two MPC8640 nodes that are now up and running and I could successfully ping across them. The basic flow is as follows.<br>
<br></div><div> <u>Root Complex Driver</u>:<br></div><div> 1. It discovers the EP processor node and gets its base addresses.(BAR 1 and BAR 2)<br></div><div> 2. It sets a single inbound window mapping a portion of its RAM to PCI space.(This is to allow inbound memory writes from EP).<br>
</div><div> 3.It enables the MSI interrupt for the EP and registers an interrupt handler for the same.(To receive interrupts from EP. Note this is conventional PCI method)<br></div><div> 4. On receiving a transmit request from kernel it initiates a DMA memory copy of the packet(in the socket buffer) to the EP memory through BAR 1. After DMA finishes it sends an interrupt to EP by writing to its msi register mapped in BAR2.<br>
</div><div> 5 . On reception of a packet(from EP) the msi interrupt handler is called and it copies the packet in RAM to a socket buffer and passes it to the kernel.<br></div><div><u><br></u></div><div><u>End Point Driver:<br>
<br></u></div><div>1. It sets up the internal msi interrupt structure and registers an interrupt handler.(To receive interrupts from RC. Note this is not done by default in kernel as it is a slave and thus is added in the driver.)<br>
</div><div>2. It sets two inbound windows <br></div><div> i) BAR1 maps to RAM area.(To allow inbound memory write from RC)<br></div><div> ii) BAR2 is mapped to PIC register area.(To allow inbound message interrupt register write from RC)<br>
</div><div>3. It sets up one outbound window to map its local address to PCI address of RC .(To allow outbound memory write to RC RAM space).<br>4. On receiving a transmit request from kernel it initiates a DMA memory
copy of the packet(in the socket buffer) to the RC memory through the outbound window. After DMA finishes it sends an interrupt to RC through the conventional PCI MSI transaction.<br>5. On reception of a packet(from RC) the msi interrupt handler is
called and it copies the packet in RAM to a socket buffer and passes it to
the kernel.<br><br></div><div>So basically a bidirectional communication channel has been established but the driver is not ready for performance checks yet. I am working on it now. I will report any improvements obtained in this regard.<br>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Its always a good idea to discuss different options, and to stub out<br>
drivers or create minimal (but functional) drivers. That way you'll<br>
be able to see how similar your new driver is to other drivers, and<br>
you'll quickly discover if there is a hardware feature in the<br>
existing driver that you cannot emulate (eg., some SRIO feature<br>
used by the rionet driver).<br>
</blockquote>
<br>
Right now I am trying a very primitive driver just to check the<br>
feasibility of bi-directional communication between the RC and the EP.<br>
Once this is established I will be in a better position to get inputs<br>
on making it a more effective one.<br>
</blockquote>
<br></div>
You're on the right track. When I looked at using the messaging<br>
registers on the PLX PCI device, I started by simply creating<br>
what was effectively a serial port (one char at a time).<br>
Section 4 explains the interlocking required between two processors<br>
<br>
<a href="http://www.ovro.caltech.edu/~dwh/correlator/pdf/cobra_driver.pdf" target="_blank">http://www.ovro.caltech.edu/~<u></u>dwh/correlator/pdf/cobra_<u></u>driver.pdf</a><br>
<br></blockquote><div>Thank You for this document . Was very helpful in understanding the basics of a Host Target Communication and implementation of a virtual driver for the same.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The mailbox/interrupt registers are effectively being used to<br>
implement a mutex between the two processors.<br>
<br>
I think at one point Ira took similar code to this and hooked<br>
it into the actual serial layer, so that you had a tty over<br>
PCI. You could always start with a simplification like that too.<br>
<br>
Cheers,<br>
Dave<br>
<br></blockquote><div><br><br></div><div>Regards,<br></div><div>S.Saravanan <br></div></div><br></div></div>