Question about combining a PCI driver with an OF driver

Question about combining a PCI driver with an OF driver

[Bruce_Leonard]

Hi all,

I'm working on a project with an MPC8347 and three ethernet ports. Because 
of end of life issues we've had to replace the part we're using for the 
third ethernet port and we decided rather than rely on a vendor who would 
pull a part out from under us every two to three years we would do our own 
MAC in an FPGA.  In order to reduce driver work it was decided that we 
would use the same hardware interface as the TSEC in the 8347 so we could 
reuse the gianfar driver.  And for speed sake it would go on the PCI bus. 
(So much for letting HW make decisions regarding SW :)   )

So now I'm stuck with hacking the gianfar driver to work on PCI.  However, 
I think it would be a lot more elegant if I could wrap the gianfar driver 
with a PCI interface.  After all the idea is sound, with a HW interface 
that looks like the TSEC I should be able to reuse the gianfar driver. But 
the gianfar driver is an open firmware driver registered with a call to 
of_register_platform_driver() and depending on the order in which the 
busses are walked the PCI bus may not be enumerated and available when the 
onboard TSECS are detected and the gianfar driver claims them.

So the question is, how can I wrap an OF driver with a PCI driver so that 
I can just do a thin layer of probing the PCI bus, registering with the 
PCI sub-system, and then calling the OF probe in the gianfar driver?

Thanks for any insight.

Bruce

Re: Question about combining a PCI driver with an OF driver

[Scott Wood]

On Tue, 4 Jan 2011 10:58:35 -0800
<Bruce_Leonard@selinc.com> wrote:

> Hi all,
> 
> I'm working on a project with an MPC8347 and three ethernet ports. Because 
> of end of life issues we've had to replace the part we're using for the 
> third ethernet port and we decided rather than rely on a vendor who would 
> pull a part out from under us every two to three years we would do our own 
> MAC in an FPGA.  In order to reduce driver work it was decided that we 
> would use the same hardware interface as the TSEC in the 8347 so we could 
> reuse the gianfar driver.

Making a faithful clone of any reasonably complex device strikes me as
more work than writing a new ethernet driver.

The last thing you want to end up doing is...

>  And for speed sake it would go on the PCI bus. 
> (So much for letting HW make decisions regarding SW :)   )

...hacking up the existing driver to deal with the quirks of the clone,
and having to maintain those hacks. :-)

> So now I'm stuck with hacking the gianfar driver to work on PCI.  However, 
> I think it would be a lot more elegant if I could wrap the gianfar driver 
> with a PCI interface.  After all the idea is sound, with a HW interface 
> that looks like the TSEC I should be able to reuse the gianfar driver. But 
> the gianfar driver is an open firmware driver registered with a call to 
> of_register_platform_driver() and depending on the order in which the 
> busses are walked the PCI bus may not be enumerated and available when the 
> onboard TSECS are detected and the gianfar driver claims them.

It shouldn't matter -- the way buses work in Linux, you should be able
to add a platform device at any time, and the driver will receive a
probe() callback.  The driver never actively searches for devices to
claim.

-Scott

Re: Question about combining a PCI driver with an OF driver

[Bruce_Leonard]

Scott,

Thanks for the feedback.

> 
> Making a faithful clone of any reasonably complex device strikes me as
> more work than writing a new ethernet driver.
> 
> The last thing you want to end up doing is...
> 
> >  And for speed sake it would go on the PCI bus. 
> > (So much for letting HW make decisions regarding SW :)   )
> 
> ...hacking up the existing driver to deal with the quirks of the clone,
> and having to maintain those hacks. :-)
>

True, but we really didn't want to recreate all the infrastructure that 
the gianfar driver has in it we wanted to just use it.  Maybe what I 
should do is just take the guts of the gianfar driver and make a pure PCI 
driver out of it. 
> 
> It shouldn't matter -- the way buses work in Linux, you should be able
> to add a platform device at any time, and the driver will receive a
> probe() callback.  The driver never actively searches for devices to
> claim.
> 

Okay, I get that and it makes sense with what I know so far about how the 
kernel device model works (which I'm still learning).  So how would I 
manually add a device?  Say I create the PCI wrapper driver that claims 
the clone-TSEC, is there a "register device" type call similar to 
pci_register_driver() that I could put in the wrapper code that causes the 
gfar_probe() to be called?

Bruce

Re: Question about combining a PCI driver with an OF driver

[Scott Wood]

On Tue, 4 Jan 2011 13:00:07 -0800
<Bruce_Leonard@selinc.com> wrote:

> Okay, I get that and it makes sense with what I know so far about how the 
> kernel device model works (which I'm still learning).  So how would I 
> manually add a device?  Say I create the PCI wrapper driver that claims 
> the clone-TSEC, is there a "register device" type call similar to 
> pci_register_driver() that I could put in the wrapper code that causes the 
> gfar_probe() to be called?

Create an OF node (probably under the root node) programatically with
all the information the gianfar driver will want, based on what you
detect on PCI, and call of_platform_device_create().

-Scott

Re: Question about combining a PCI driver with an OF driver

[Bruce_Leonard]

> 
> > Okay, I get that and it makes sense with what I know so far about how 
the 
> > kernel device model works (which I'm still learning).  So how would I 
> > manually add a device?  Say I create the PCI wrapper driver that 
claims 
> > the clone-TSEC, is there a "register device" type call similar to 
> > pci_register_driver() that I could put in the wrapper code that causes 
the 
> > gfar_probe() to be called?
> 
> Create an OF node (probably under the root node) programatically with
> all the information the gianfar driver will want, based on what you
> detect on PCI, and call of_platform_device_create().
> 

Ah, the light bulb clicks on!  Thanks for the info.  I appreciate it.

Bruce

Re: Question about combining a PCI driver with an OF driver

[Sean MacLennan]

On Tue, 4 Jan 2011 13:00:07 -0800
Bruce_Leonard@selinc.com wrote:

> True, but we really didn't want to recreate all the infrastructure
> that the gianfar driver has in it we wanted to just use it.  Maybe
> what I should do is just take the guts of the gianfar driver and make
> a pure PCI driver out of it. 

This is what I would do. Odds are the final FPGA driver will have a lot
of "optimizations" and "we don't need this" changes to the point where
you won't be able to read the original code for ifdefs ;)

Cheers,
   Sean

Re: Question about combining a PCI driver with an OF driver

[Benjamin Herrenschmidt]

On Tue, 2011-01-04 at 13:23 -0600, Scott Wood wrote:
> On Tue, 4 Jan 2011 10:58:35 -0800
> <Bruce_Leonard@selinc.com> wrote:
> 
> > Hi all,
> > 
> > I'm working on a project with an MPC8347 and three ethernet ports. Because 
> > of end of life issues we've had to replace the part we're using for the 
> > third ethernet port and we decided rather than rely on a vendor who would 
> > pull a part out from under us every two to three years we would do our own 
> > MAC in an FPGA.  In order to reduce driver work it was decided that we 
> > would use the same hardware interface as the TSEC in the 8347 so we could 
> > reuse the gianfar driver.
> 
> Making a faithful clone of any reasonably complex device strikes me as
> more work than writing a new ethernet driver.
> 
> The last thing you want to end up doing is...
> 
> >  And for speed sake it would go on the PCI bus. 
> > (So much for letting HW make decisions regarding SW :)   )
> 
> ...hacking up the existing driver to deal with the quirks of the clone,
> and having to maintain those hacks. :-)

I definitely agree. You're up for more work and problems than just doing
a new design or getting an existing one off opencores or even buying an
IP block with its own driver.

> > So now I'm stuck with hacking the gianfar driver to work on PCI.  However, 
> > I think it would be a lot more elegant if I could wrap the gianfar driver 
> > with a PCI interface.  After all the idea is sound, with a HW interface 
> > that looks like the TSEC I should be able to reuse the gianfar driver. But 
> > the gianfar driver is an open firmware driver registered with a call to 
> > of_register_platform_driver() and depending on the order in which the 
> > busses are walked the PCI bus may not be enumerated and available when the 
> > onboard TSECS are detected and the gianfar driver claims them.
> 
> It shouldn't matter -- the way buses work in Linux, you should be able
> to add a platform device at any time, and the driver will receive a
> probe() callback.  The driver never actively searches for devices to
> claim.

Cheers,
Ben.

> -Scott
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev