All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* Marvell DSA switch 88E6165 - CPU port in PHY mode
@ 2012-03-04 18:09 mdsmith
  0 siblings, 0 replies; 4+ messages in thread
From: mdsmith @ 2012-03-04 18:09 UTC (permalink / raw
  To: netdev

Hello - have a question about the net/dsa driver code, how does one 
bring up the CPU connected port on the switch when it isn't in RGMII 
mode, i.e. with the built-in GPHY enabled.

Normally (at least according to Marvell documentation, existing 
reference designs and Lennert's DSA driver code) the CPU Ethernet 
interface is connected to the switch port as RGMII. Due to a hardware 
design constraint our new platform has the following arrangement - both 
Ethernet ports on the Kirkwood 6282 SoC are wired to a 1121 dual phy 
(this is a system on module), the only way to connect to GE00 & GE01 is 
via a copper interface. Reading the data sheet for the 6165 switch chip 
we noticed that Port 4 can be configured as a copper interface using the 
built-in PHY (using P4_MODE[2:0]) so it seemed that the configuration 
described below is feasible:

+-----------+          +-----------+
|           |          |           |
|           |   RGMII  |           | PHY
|       GE00+----------+           +-------------------------- 
1000baseT MDI eth0
|           |          |  88E1121R |
|           |          |  dual phy |       +-----------+
|           |   RGMII  |           | PHY  4|          0+------ 
1000baseT MDI lan0
|       GE01+----------+           +-------+  88E6165 1+------ 
1000baseT MDI lan1
|           |          |           |       |  switch  2+------ 
1000baseT MDI lan2
| 88F6282   |          |           |       |          3+------ 
1000baseT MDI lan3
| SoC       |          |           |       |  port5    |
|           |          | MDC/MDIO  |       |  disabled |
|        SMI+----------+[0:1]------+-------+[8]        |
|           |          |           |       |           |
+-----------+          +-----------+       +-----------+

To summarize:
- GE00's PHY is directly wired to an RJ45, this interface works fine.
- GE01's PHY is wired to switch port 4 (hardware strapped to GPHY 
mode), cannot bring this link up.
- SMI bus is shared between the 1121 dual PHY and the 6165 switch, we 
can talk to both chips fine (6165 via indirect register access)

I believe my Kirkwood platform initialization code is good as the 
kernel finds GE00, GE01 and the switch. I did have to tweak the 
mach-orion/common.c platform code slightly to associate GE01 with the 
switch CPU port (d->netdev = &orion_ge01.dev;). Relevant kernel output 
(I have eth0 plugged into an upstream switch and lan0 connected to 
another external standalone switch):

mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
mv643xx_eth smi: probed
mv643xx_eth_port mv643xx_eth_port.0: eth0: port 0 with MAC address 
00:50:43:22:2
6:29
mv643xx_eth_port mv643xx_eth_port.1: eth1: port 0 with MAC address 
00:50:43:72:2
6:29
<snip>
eth1[0]: detected a Marvell 88E6165 switch
dsa slave smi: probed
<snip>
ADDRCONF(NETDEV_UP): eth0: link is not ready
<snip>
mv643xx_eth_port mv643xx_eth_port.0: eth0: link up, 1000 Mb/s, full 
duplex, flow
control disabled
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
<snip>
ADDRCONF(NETDEV_UP): eth1: link is not ready
<snip>
lan0: link up, 1000 Mb/s, full duplex, flow control disabled
ADDRCONF(NETDEV_CHANGE): lan0: link becomes ready

I see eth0 come up, good. I don't see eth1 come up which means that the 
6165 switch Port 4 is not up. I see lan0 come up when I plug it into an 
external switch.

mii-tool confirms that eth1 has no link.

root@testme:~# mii-tool -v eth1
eth1: 10 Mbit, full duplex, no link
product info: vendor 00:50:43, model 11 rev 3
basic mode:   10 Mbit, full duplex
basic status: no link
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 
10baseT-FD 10baseT-HD
advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
root@testme:~# mii-tool -v lan0
lan0: negotiated 1000baseT-FD flow-control, link ok
product info: vendor 00:50:43, model 11 rev 1
basic mode:   autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 
10baseT-FD 10baseT-HD
advertising:  1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 
10baseT-HD
link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 
10baseT-FD 10baseT-HD flow-control

I've gone through the DSA code and cannot see exactly where one can 
modify the CPU connected port to be PHY instead of RGMII. Nearest I 
could find was in mv88e6123_61_65_setup_port where various registers are 
written to to initialize the different ports, there is a reference to 
forcing the CPU connected port to 1000Mb/s full duplex so I thought it 
would be logical to add some register writes to power up the PHY. 
However this still doesn't bring the PHY up...

Any ideas on how I can bring my board up correctly?
Or is this just not possible with this hardware configuration? I find 
it hard to believe because DSA switches can be daisy chained across any 
port using copper (or other media).

thanks for your help…
Matthew D. Smith

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Marvell DSA switch 88E6165 - CPU port in PHY mode
       [not found] <516EEEFC-DEEC-4CF5-BEF6-C5F3F86FCDD5@partychief.com>
@ 2012-03-05 17:12 ` Lennert Buytenhek
  2012-03-08 13:57   ` mdsmith
  0 siblings, 1 reply; 4+ messages in thread
From: Lennert Buytenhek @ 2012-03-05 17:12 UTC (permalink / raw
  To: Matthew D. Smith; +Cc: netdev

On Sun, Mar 04, 2012 at 03:11:53PM +0100, Matthew D. Smith wrote:

> Hello - have a question about CPU port configuration in the net/dsa
> driver code. Can't seem to work out how to bring up the CPU connected
> port on the switch (in our case this is Port 4 hardware strapped with
> its embedded PHY enabled).

Hello!  I know of at least a couple of platforms that have a DSA chip
connected to the CPU via an MDI type link, but I'm not sure why it's
not working for you.  I'd suggest double-checking all the port 5 PHY
registers against the chip documentation..


thanks,
Lennert

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Marvell DSA switch 88E6165 - CPU port in PHY mode
  2012-03-05 17:12 ` Lennert Buytenhek
@ 2012-03-08 13:57   ` mdsmith
  2012-03-12  8:51     ` Lennert Buytenhek
  0 siblings, 1 reply; 4+ messages in thread
From: mdsmith @ 2012-03-08 13:57 UTC (permalink / raw
  To: Lennert Buytenhek; +Cc: netdev

Le 2012-03-05 18:12, Lennert Buytenhek a écrit :
> On Sun, Mar 04, 2012 at 03:11:53PM +0100, Matthew D. Smith wrote:
>
>> Hello - have a question about CPU port configuration in the net/dsa
>> driver code. Can't seem to work out how to bring up the CPU 
>> connected
>> port on the switch (in our case this is Port 4 hardware strapped 
>> with
>> its embedded PHY enabled).
>
> Hello!  I know of at least a couple of platforms that have a DSA chip
> connected to the CPU via an MDI type link, but I'm not sure why it's
> not working for you.  I'd suggest double-checking all the port 5 PHY
> registers against the chip documentation..
>

Hi - perhaps I misunderstood something about the built-in PHY on Port 
4. We expected to see the PHY enabled in hardware by setting logic on 
the P4_MODE pins. But this doesn't seem to be sufficient as I guess one 
still has to enable the PHY in the driver code (like how you do it for 
the LAN interfaces in net/dsa/slave.c).

So, after digging through the net/dsa source I found that there is 
nothing explicit in the code to enable the CPU port if it needs a PHY. I 
would like to say that way it is written assumes that it is always RGMII 
so I guess the other platforms you refer to above use customized 
(non-mainline) driver code?

I have managed to get the DSA switch working by making the following 
changes:

--- ./kernel/linux-source-3.2-csb1724/net/dsa/dsa.c
+++ ./kernel/linux-source-3.2-csb1724/net/dsa/dsa.c (unsaved)
@@ -124,7 +124,6 @@
  			}
  			dst->cpu_switch = index;
  			dst->cpu_port = i;
+			ds->phys_port_mask |= 1 << i;
  		} else if (!strcmp(name, "dsa")) {
  			ds->dsa_port_mask |= 1 << i;
  		} else {

--- ./kernel/linux-source-3.2-csb1724/net/dsa/mv88e6123_61_65.c
+++ ./kernel/linux-source-3.2-csb1724/net/dsa/mv88e6123_61_65.c 
(unsaved)
@@ -193,7 +193,12 @@
  	 * full duplex.
  	 */
  	if (dsa_is_cpu_port(ds, p) || ds->dsa_port_mask & (1 << p)) {
-		REG_WRITE(addr, 0x01, 0x003e);
+		REG_WRITE(addr, 0x01, 0x0003);
  	}
  	else
  		REG_WRITE(addr, 0x01, 0x0003);

Basically this tells the DSA driver to create an interface for the CPU 
port. Perhaps overkill but it does bring up the built-in PHY in the same 
way it brings up the LAN slave interfaces. As slave.c sets autoneg on I 
needed to change the register value from 1000FD to autoneg. Likewise for 
the CPU GE01 port in my platform init code.

I don't really like this, but it works. Is there a better way?

regards
Matthew

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Marvell DSA switch 88E6165 - CPU port in PHY mode
  2012-03-08 13:57   ` mdsmith
@ 2012-03-12  8:51     ` Lennert Buytenhek
  0 siblings, 0 replies; 4+ messages in thread
From: Lennert Buytenhek @ 2012-03-12  8:51 UTC (permalink / raw
  To: mdsmith; +Cc: netdev

On Thu, Mar 08, 2012 at 02:57:57PM +0100, mdsmith@partychief.com wrote:

> >>Hello - have a question about CPU port configuration in the net/dsa
> >>driver code. Can't seem to work out how to bring up the CPU
> >>connected
> >>port on the switch (in our case this is Port 4 hardware strapped
> >>with
> >>its embedded PHY enabled).
> >
> >Hello!  I know of at least a couple of platforms that have a DSA chip
> >connected to the CPU via an MDI type link, but I'm not sure why it's
> >not working for you.  I'd suggest double-checking all the port 5 PHY
> >registers against the chip documentation..
> 
> Hi - perhaps I misunderstood something about the built-in PHY on
> Port 4. We expected to see the PHY enabled in hardware by setting
> logic on the P4_MODE pins. But this doesn't seem to be sufficient as
> I guess one still has to enable the PHY in the driver code (like how
> you do it for the LAN interfaces in net/dsa/slave.c).
> 
> So, after digging through the net/dsa source I found that there is
> nothing explicit in the code to enable the CPU port if it needs a
> PHY. I would like to say that way it is written assumes that it is
> always RGMII so I guess the other platforms you refer to above use
> customized (non-mainline) driver code?

The platform I work on the most configures the CPU PHY port via the
EEPROM and/or handles it in the bootloader (I'm not entirely sure as
I haven't worked on that piece of the system) -- this may work for
you as well.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-03-12  8:51 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-04 18:09 Marvell DSA switch 88E6165 - CPU port in PHY mode mdsmith
     [not found] <516EEEFC-DEEC-4CF5-BEF6-C5F3F86FCDD5@partychief.com>
2012-03-05 17:12 ` Lennert Buytenhek
2012-03-08 13:57   ` mdsmith
2012-03-12  8:51     ` Lennert Buytenhek

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.