FCC Ethernet PlatformDevice support for 82xx
RFC PATCH 3/3 FCC Ethernet PlatformDevice support for 82xx
This patch contains actual Ethernet driver on platform bus. Currently tested on MPC8272ADS (PQII) board.
Signature · 1 line
Sincerely, Vitaly
drivers/net/Kconfig +14 -0
@@ -1761,6 +1761,20 @@ source "drivers/net/fec_8xx/Kconfig" +config CPM2_FCC_ENET + tristate "CPM2 Fast Ethernet Controller (FCC)" + depends on CPM2 + help + This driver supports Fast Ethernet Controller (FCC) on 82xx family. + +config USE_MDIO + bool "Use MDIO for PHY configuration" + depends on CPM2_FCC_ENET + +config CPM2_FCC_ENET_NAPI + bool "NAPI Support" + depends on CPM2_FCC_ENET + endmenu #
drivers/net/Makefile +3 -1
@@ -11,9 +11,11 @@ obj-$(CONFIG_IXGB) += ixgb/ obj-$(CONFIG_BONDING) += bonding/ obj-$(CONFIG_GIANFAR) += gianfar_driver.o +obj-$(CONFIG_CPM2_FCC_ENET)+= cpm2_fcc_driver.o gianfar_driver-objs := gianfar.o gianfar_ethtool.o gianfar_phy.o - +cpm2_fcc_driver-objs:= cpm2_fcc_enet.o cpm2_fcc_ethtool.o cpm2_fcc_phy.o + # # link order important here #
drivers/net/cpm2_fcc_enet.c new file +1673 -0
1,673 lines not on this page · raw message
drivers/net/cpm2_fcc_enet.h new file +340 -0
340 lines not on this page · raw message
drivers/net/cpm2_fcc_ethtool.c new file +261 -0
261 lines not on this page · raw message
drivers/net/cpm2_fcc_phy.c new file +776 -0
694 lines not on this page · raw message
drivers/net/cpm2_fcc_phy.h new file +220 -0
220 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Part of the diff is not shown here. View the raw message.
Quoted 1 line · Vitaly Bordug
This patch contains actual Ethernet driver on platform bus. Currently tested on MPC8272ADS (PQII) board.
Hold off on this, please.
We need to get Panto to review it against the restructuring of all of the existing drivers.
Thanks.
-- Dan
Quoted 2 lines · Vitaly Bordug
This patch contains actual Ethernet driver on platform bus. Currently tested on MPC8272ADS (PQII) board.
[snip]
Quoted 1 line
Hi Vitaly
Since I'm also working on this, lets try to merge our work in one driver.
A few points regarding my driver.
1) It currently supports both 8xx FEC, 82xx FCCs.
2) It will also support SCC ENETS on both 8xx & 82xx, and FECs on coldfire's & 52xx's.
3) We should treat the current MII logic as temporary since Andy Flemming has a replacement by a MII bus.
Regarding your driver, there are a couple of things it does arguably better than mine.
1) It has more complete platformization.
2) Adjustuble ring sizes.
And here are some gripes.
1) I'm not a proponent of having drivers configuring pins, clocks & other things that are properties of each specific board. I'd rather have the bootloader or the platform initialization handle it once, and have the driver just use these settings. Opinions on this matter differ however :).
2) There are a number of platform defines that are not needed.
Well, what do you think?
Regards
Pantelis
Quoted 22 lines
Hi Vitaly
Since I'm also working on this, lets try to merge our work in one driver.
A few points regarding my driver.
1) It currently supports both 8xx FEC, 82xx FCCs.
2) It will also support SCC ENETS on both 8xx & 82xx, and FECs on coldfire's & 52xx's.
3) We should treat the current MII logic as temporary since Andy Flemming has a replacement by a MII bus.Regarding your driver, there are a couple of things it does arguably better than mine.
1) It has more complete platformization.
2) Adjustuble ring sizes.And here are some gripes.
Quoted 9 lines
1) I'm not a proponent of having drivers configuring pins, clocks & other things that are properties of each specific board. I'd rather have the bootloader or the platform initialization handle it once, and have the driver just use these settings. Opinions on this matter differ however :).
2) There are a number of platform defines that are not needed.Well, what do you think?
The idea itself sounds very good.
So, let's, as a starting point, implement mentioned things (platformization and dynamic rings) within your driver (if you don't mind of course). More specifically, I am going to add necessary platform stuff for 82xx and 8xx since we have only 8272ads and 885ads to test this on.
Firmware-only board-specific stuff configuration is a good thing, but IMHO it's impossible to provide a universal bootloader configuration that will meet all possible requirements, and a person should recompile or even modify the firmware in such cases. That is why I included clocks and etc stuff to the platform_data structure, so that in board-specific headers this values could be redefined if necessary. However I'm not sure about PIN setup, should it also reside in the platform_data struct, or in the driver (as it is in my patch).
Another thing we should change in existing code is direct cpm2_immr usage - the driver should be as isolated from this as possible. Dan mentioned that the stuff that will offer IOport and likewise access right way is almost completed so I'm looking forward some details about it from him.
Signature · 1 line
Sincerely, Vitaly
Quoted 29 lines · Vitaly Bordug
Quoted 29 lines
Hi Vitaly
Since I'm also working on this, lets try to merge our work in one driver.
A few points regarding my driver.
1) It currently supports both 8xx FEC, 82xx FCCs.
2) It will also support SCC ENETS on both 8xx & 82xx, and FECs on coldfire's & 52xx's.
3) We should treat the current MII logic as temporary since Andy Flemming has a replacement by a MII bus.Regarding your driver, there are a couple of things it does arguably better than mine.
1) It has more complete platformization.
2) Adjustuble ring sizes.And here are some gripes.
1) I'm not a proponent of having drivers configuring pins, clocks & other things that are properties of each specific board. I'd rather have the bootloader or the platform initialization handle it once, and have the driver just use these settings. Opinions on this matter differ however :).
2) There are a number of platform defines that are not needed.
Quoted 4 lines
Quoted 2 lines
Well, what do you think?
The idea itself sounds very good.
So, let's, as a starting point, implement mentioned things (platformization and dynamic rings) within your driver (if you don't mind of course).
Please go ahead.
Quoted 3 lines
More specifically, I am going to add necessary platform stuff for 82xx and 8xx since we have only 8272ads and 885ads to test this on.
Firmware-only board-specific stuff configuration is a good thing, but IMHO it's impossible to provide a universal bootloader configuration that will meet all possible requirements, and a person should recompile or even modify the firmware in such cases. That is why I included clocks and etc stuff to the
platform_datastructure, so that in board-specific headers this values could be redefined if necessary. However I'm not sure about PIN setup, should it also reside in theplatform_datastruct, or in the driver (as it is in my patch).
Granted, to do that in the bootloader is very hard. However we can definately do that in the board setup file, like arch/ppc/platforms/pq2ads_setup.c
In my experience it's much easier to configure these things once. Hunting down where the driver modifies pins & clocks is a nightmare, if you ever use a non standard configuration.
The driver however can probe for it's configuration and display it so that we can tell what is going on.
Quoted 3 lines
Another thing we should change in existing code is direct
cpm2_immrusage - the driver should be as isolated from this as possible. Dan mentioned that the stuff that will offer IOport and likewise access right way is almost completed so I'm looking forward some details about it from him.
Yes, that's another thing that must be done; please go ahead.
Regards
Pantelis
Quoted 3 lines · Pantelis Antoniou
In my experience it's much easier to configure these things once. Hunting down where the driver modifies pins & clocks is a nightmare, if you ever use a non standard configuration.
That doesn't quite work, as we have discussed before. The problem with setting them in the board set up is you can have loadable modules and select among several different IO pin configurations depending upon what you load. So, the plan is to have the drivers make a generic call out request using feature_call() to the supporting functions in the board specific directory. This is for more than just IO pin configurations, since boards may have power management or other external logic that has to be routed to the physical interface. For example, the SCC Ethernet driver will perform a feature_call() during set up requesting any necessary configuration for SCC2. The board specific function can chose to ignore this and get the "default" configuration, or to do whatever is necessary unique to the board to enable the external data path. All that drivers know is there are a couple of specific places where they need configuration assistance, they don't care what the specific board has to do.
It's in the works and nearly done for a few example 85xx and 82xx boards and CPM2 drivers. I'll be checking it in shortly. I just haven't decided if I want a varargs list or a data structure for passing the information and results.
Thanks.
-- Dan
Quoted 8 lines · Dan Malek
Quoted 3 lines · Pantelis Antoniou
In my experience it's much easier to configure these things once. Hunting down where the driver modifies pins & clocks is a nightmare, if you ever use a non standard configuration.
Quoted 15 lines
That doesn't quite work, as we have discussed before. The problem with setting them in the board set up is you can have loadable modules and select among several different IO pin configurations depending upon what you load. So, the plan is to have the drivers make a generic call out request using
feature_call()to the supporting functions in the board specific directory. This is for more than just IO pin configurations, since boards may have power management or other external logic that has to be routed to the physical interface. For example, the SCC Ethernet driver will perform afeature_call()during set up requesting any necessary configuration for SCC2. The board specific function can chose to ignore this and get the "default" configuration, or to do whatever is necessary unique to the board to enable the external data path. All that drivers know is there are a couple of specific places where they need configuration assistance, they don't care what the specific board has to do.
Sounds nice. I'm a much simpler guy it seems :)
Quoted 5 lines
It's in the works and nearly done for a few example 85xx and 82xx boards and CPM2 drivers. I'll be checking it in shortly. I just haven't decided if I want a varargs list or a data structure for passing the information and results.
Mind sharing?
Quoted 6 lines
Thanks.
-- Dan
Regards
Pantelis