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
From: Scott Wood <hidden> Date: 2011-01-04 19:23:30
On Tue, 4 Jan 2011 10:58:35 -0800
[off-list ref] 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
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...
quoted
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2011-01-04 21:06:08
On Tue, 2011-01-04 at 13:23 -0600, Scott Wood wrote:
On Tue, 4 Jan 2011 10:58:35 -0800
[off-list ref] wrote:
quoted
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...
quoted
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.
quoted
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.
From: Scott Wood <hidden> Date: 2011-01-04 21:20:36
On Tue, 4 Jan 2011 13:00:07 -0800
[off-list ref] 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
From: Sean MacLennan <hidden> Date: 2011-01-04 21:33:38
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
Okay, I get that and it makes sense with what I know so far about how
the
quoted
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
quoted
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
quoted
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