7 messages, 3 authors, 2005-05-05 · open the first message on its own page
From: Vitaly Bordug <hidden>
Date: 2005-05-04 14:35:45
This patch contains actual Ethernet driver on platform bus. Currently tested on MPC8272ADS (PQII) board. Signed-off-by: Vitaly Bordug<redacted> -- Sincerely, Vitaly
From: Dan Malek <hidden>
Date: 2005-05-04 23:13:14
On May 4, 2005, at 10:35 AM, Vitaly Bordug wrote:
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
From: Pantelis Antoniou <hidden>
Date: 2005-05-05 11:36:59
Vitaly Bordug wrote:
This patch contains actual Ethernet driver on platform bus. Currently tested on MPC8272ADS (PQII) board.
[snip]
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
From: Vitaly Bordug <hidden>
Date: 2005-05-05 12:40:05
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?
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. -- Sincerely, Vitaly
From: Pantelis Antoniou <hidden>
Date: 2005-05-05 12:52:19
Vitaly Bordug wrote:
quoted
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?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.
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).
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.
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.
Yes, that's another thing that must be done; please go ahead. Regards Pantelis
From: Dan Malek <hidden>
Date: 2005-05-05 13:19:45
On May 5, 2005, at 8:36 AM, Pantelis Antoniou wrote:
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
From: Pantelis Antoniou <hidden>
Date: 2005-05-05 13:43:20
Dan Malek wrote:
On May 5, 2005, at 8:36 AM, Pantelis Antoniou wrote:quoted
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.
Sounds nice. I'm a much simpler guy it seems :)
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?
Thanks.
-- Dan
Regards Pantelis