Re: [U-Boot] [PATCH V2] Allow PHY addresses on kirkwood egiga to be non continuous.
On Thu, 2010-06-24 at 14:26 +0200, Prafulla Wadaskar wrote:
-----Original Message----- From: Tor Krill [mailto:tor@excito.com] Sent: Thursday, June 24, 2010 5:05 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de Subject: RE: [PATCH V2] Allow PHY addresses on kirkwood egiga to be non continuous.
Hi Prafulla,
On Thu, 2010-06-24 at 13:22 +0200, Prafulla Wadaskar wrote:
-----Original Message----- From: Tor Krill [mailto:tor@excito.com] Sent: Thursday, June 24, 2010 3:02 PM To: u-boot@lists.denx.de Cc: Prafulla Wadaskar; Tor Krill Subject: [PATCH V2] Allow PHY addresses on kirkwood egiga to be non continuous.
Changing its configuration from PHY_BASE_ADR single value to use CONFIG_PHY_BASE_ADDRS as an array with adresses.
Updated in version 2:
Merged board updates to single patch.
These two lines should go as changelog for v2 below (after ---)
Sorry, there seems to be no end on my mistakes :(
Signed-off-by: Tor Krill tor@excito.com
i.e. here..
board/keymile/km_arm/km_arm.c | 3 ++- drivers/net/kirkwood_egiga.c | 3 ++- drivers/net/kirkwood_egiga.h | 8 ++++---- include/configs/guruplug.h | 2 +- include/configs/km_arm.h | 2 +- include/configs/openrd_base.h | 2 +- include/configs/rd6281a.h | 2 +- include/configs/sheevaplug.h | 2 +- 8 files changed, 13 insertions(+), 11 deletions(-)
Hi Tom I understood your problem. But all of the Kirkwood boards so far have similar
implementation which is standard practice.
How does your board design differed in this case?
Instead of fixing it here for all other boards, can't you simply align PHY address on your board? I think this will be much easier.
We use both ethernet interfaces by default in our design, with the phy addresses 0x08 and 0x18, and unfortunately we have already started the manufacturing of these units which makes it expensive and hard to reverse this design decision :(
Do you think this will be corrected in next h/w version? If yes, then you can keep this patch private to yourself.
We will unfortunately not change this, what we know of now. If it had only been moving some resistors mounted or not it could perhaps have been fixable before mass production. But as it is now this would involve us changing the the design as well.
But if we turn this around if the hardware allows this then why not let this be configurable in u-boot as well? Do this have any technical implications on the other boards?
Overall
- This patch increases u-boot binary size by 20 bytes. (may be
critical issue on low footprint boards like mv88f6281gtw_ge).
Ok, i only get this to ~4 bytes but thats a valid point.
- For the boards using single port will also need to configure PHY address
for other port, which is meaningless, unnecessary and confusing.
Sure you had to put something there to be on the safe side. But is that really that confusing, the SOC really have two ports, them being used or not?
This is the exact same mechanism that is used for CONFIG_KIRKWOOD_EGIGA_PORTS which is implemented as an array telling the driver if it should initialize the port or not.
Technically no implications, but we need to keep code simple, small and standard.
And again, i think the flexibility is worth the "small" prize. I know that fx the TK71 devkit have non consecutive PHY addresses (Even though it not being present in mainline u-boot)
If you are able to set the addresses "freely", why limit this in software?
The alternative, as i see it, would be to have defines for each port and then ifdef each init. Would that be an alternative?
Regards,
/Tor
Dear Tor Krill,
In message 1277716302.2221.37.camel@tor-desktop you wrote:
- For the boards using single port will also need to configure PHY address
for other port, which is meaningless, unnecessary and confusing.
Sure you had to put something there to be on the safe side. But is that really that confusing, the SOC really have two ports, them being used or not?
It is indeed confusing and should be avoided if one has to configurwe hardware ports that are not actually present or used on a specific board.
If needed, provide sane defaults internally in the code.
But keep in mind that U-Boot requires that only used peripherals should be initialized - we should not initisalize any unused ports.
Best regards,
Wolfgang Denk
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Monday, June 28, 2010 5:32 PM To: Tor Krill Cc: Prafulla Wadaskar; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH V2] Allow PHY addresses on kirkwood egiga to be non continuous.
Dear Tor Krill,
In message 1277716302.2221.37.camel@tor-desktop you wrote:
- For the boards using single port will also need to
configure PHY address
for other port, which is meaningless, unnecessary and confusing.
Sure you had to put something there to be on the safe side.
But is that
really that confusing, the SOC really have two ports, them
being used or
not?
It is indeed confusing and should be avoided if one has to configurwe hardware ports that are not actually present or used on a specific board.
If needed, provide sane defaults internally in the code.
But keep in mind that U-Boot requires that only used peripherals should be initialized - we should not initisalize any unused ports.
Yes, This is already taken care by kirkwood_egiga driver, it only initialize selected port
Regards.. Prafulla . .
participants (3)
-
Prafulla Wadaskar -
Tor Krill -
Wolfgang Denk