ibm_ocp_enet.c - PHY implementation requirements?

ibm_ocp_enet.c - PHY implementation requirements?

[Allen Curtis]

We have an 405GP design, very similar to the Walnut LSP. One of the major
differences is that we have a BroadCom 9-port switch instead of a dedicated
PHY for Ethernet. Supporting the switch is much easier than a dedicated PHY
because you can always assume:  100Mb, Full-Duplex and you do not have to
handle disconnect and mode change interrupts. The problem is that the OCP
Ethernet implementation has become much more complex and it is not obvious
what must be supported when adding a new interface and what could be a stub.
(and its expected result)

Another issue is that the switch supports both the MII and SPI interfaces.
These are mutually exclusive, determined by first access to the device. Our
design requires the use of the SPI interface. All currently supported PHY
are MII, which is expected. Do you forsee any problems using SPI within
ibm_ocp_phy.c?

TIA


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

ibm_ocp_enet.c - PHY implementation requirements?

[Allen Curtis]

We have an 405GP design, very similar to the Walnut LSP. One of the major
differences is that we have a BroadCom 9-port switch instead of a dedicated
PHY for Ethernet. Supporting the switch is much easier than a dedicated PHY
because you can always assume:  100Mb, Full-Duplex and you do not have to
handle disconnect and mode change interrupts. The problem is that the OCP
Ethernet implementation has become much more complex and it is not obvious
what must be supported when adding a new interface and what could be a stub.
(and its expected result)

Another issue is that the switch supports both the MII and SPI interfaces.
These are mutually exclusive, determined by first access to the device. Our
design requires the use of the SPI interface. All currently supported PHY
are MII, which is expected. Do you forsee any problems using SPI within
ibm_ocp_phy.c?

TIA


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ibm_ocp_enet.c - PHY implementation requirements?

[Armin]

Allen Curtis wrote:
> We have an 405GP design, very similar to the Walnut LSP. One of the major
> differences is that we have a BroadCom 9-port switch instead of a dedicated
> PHY for Ethernet. Supporting the switch is much easier than a dedicated PHY
> because you can always assume:  100Mb, Full-Duplex and you do not have to
> handle disconnect and mode change interrupts. The problem is that the OCP
> Ethernet implementation has become much more complex and it is not obvious
> what must be supported when adding a new interface and what could be a stub.
> (and its expected result)
>
> Another issue is that the switch supports both the MII and SPI interfaces.
> These are mutually exclusive, determined by first access to the device. Our
> design requires the use of the SPI interface. All currently supported PHY
> are MII, which is expected. Do you forsee any problems using SPI within
> ibm_ocp_phy.c?
>
> TIA

There are a few stubs for the zmii bridge

The MII functions can most likly be placed into it's own file and you
might want to think about creating  a spi.c file for its implimentation.
  This would allow us to have them be complied in depending on what mode
is configured. The questions is can we come up with a common api to mii
& spi?



armin


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: ibm_ocp_enet.c - PHY implementation requirements?

[Allen Curtis]

> There are a few stubs for the zmii bridge

I guess I am confused about how to create stubs. I looked at the code and it
appears that it wants to schedule mii functions to be completed for config,
ack, shutdown, ... I didn't see anything in the list processing that would
avoid the queue process. For instance, if you wanted to just initialize the
phy_status field from the config(), how could you do this without having it
go into the mii_queue processor? (setup for 100Mb, Full-Duplex)

> The MII functions can most likely be placed into it's own file and you
> might want to think about creating  a spi.c file for its implementation.

I totally agree.

>   This would allow us to have them be complied in depending on what mode
> is configured. The questions is can we come up with a common api to mii
> & spi?

The phy_info structure looks general enough. It is the function list
processing that concerns me. I will think about it tomorrow when the brain
is a little clearer. (and I have to come up with a viable solution)

THX


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/