Discussion:
[OpenWrt-Devel] [PATCH] ar71xx: Allow for activation of second mdio bus in ar7242 / ag71xx driver
Andrew McDonnell
2013-05-14 12:30:28 UTC
Permalink
This patch allows a board to enable the mdio bus on the second ethernet port
provided by the AR7242 (as used in the D-Link DIR-632-A1.) The AR7242 (at
least on the dir632) has two ethernet, eth0 at 0x19000000 and eth1 at
0x1a000000, and both have enumerable mdio busses.

It further defaults to connecting eth1 to ag71xx-mdio.1 when registering eth1
with ath79 platform data.

Please note this superseded prior email with missing subject(!)


Signed-off-by: Andrew McDonnell <***@andrewmcdonnell.net>
---

.../linux/ar71xx/files/arch/mips/ath79/dev-eth.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
index 47e1350..cbd782d 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
@@ -183,6 +183,7 @@ void __init ath79_register_mdio(unsigned int id, u32 phy_mask)
if (ath79_soc == ATH79_SOC_AR9341 ||
ath79_soc == ATH79_SOC_AR9342 ||
ath79_soc == ATH79_SOC_AR9344 ||
+ ath79_soc == ATH79_SOC_AR7242 ||
ath79_soc == ATH79_SOC_QCA9556 ||
ath79_soc == ATH79_SOC_QCA9558)
max_id = 1;
@@ -202,6 +203,13 @@ void __init ath79_register_mdio(unsigned int id, u32
phy_mask)
mdio_data = &ath79_mdio1_data;
break;

+ case ATH79_SOC_AR7242:
+ ath79_set_pll(AR71XX_PLL_REG_SEC_CONFIG,
+ AR7242_PLL_REG_ETH0_INT_CLOCK, 0x62000000,
+ AR71XX_ETH0_PLL_SHIFT);
+ /* The driver in DD-WRT always has a 100ms delay after setting
the PLL */
+ udelay(100*1000);
+ /* fall through - the AR7242 has two eth ports */
case ATH79_SOC_AR9341:
case ATH79_SOC_AR9342:
case ATH79_SOC_AR9344:
@@ -216,11 +224,6 @@ void __init ath79_register_mdio(unsigned int id, u32
phy_mask)
}
break;

- case ATH79_SOC_AR7242:
- ath79_set_pll(AR71XX_PLL_REG_SEC_CONFIG,
- AR7242_PLL_REG_ETH0_INT_CLOCK, 0x62000000,
- AR71XX_ETH0_PLL_SHIFT);
- /* fall through */
default:
mdio_dev = &ath79_mdio0_device;
mdio_data = &ath79_mdio0_data;
@@ -236,7 +239,11 @@ void __init ath79_register_mdio(unsigned int id, u32
phy_mask)
case ATH79_SOC_AR7241:
mdio_data->builtin_switch = 1;
break;
-
+ case ATH79_SOC_AR7242:
+ if (id == 1) {
+ mdio_data->builtin_switch = 1;
+ }
+ break;
case ATH79_SOC_AR9330:
mdio_data->is_ar9330 = 1;
/* fall through */
Felix Fietkau
2013-05-14 13:09:44 UTC
Permalink
Post by Andrew McDonnell
This patch allows a board to enable the mdio bus on the second ethernet port
provided by the AR7242 (as used in the D-Link DIR-632-A1.) The AR7242 (at
least on the dir632) has two ethernet, eth0 at 0x19000000 and eth1 at
0x1a000000, and both have enumerable mdio busses.
It further defaults to connecting eth1 to ag71xx-mdio.1 when registering eth1
with ath79 platform data.
Please note this superseded prior email with missing subject(!)
Are you sure about this? In other AR724x SoCs one MDIO bus goes to the
built-in switch, and the other one is external. You don't seem to make
use of the second MDIO bus in your DIR-632-A1 patch either.
I think the AR7242 does not have the built-in switch, so it would
surprise me to see a second MDIO bus being used there.

- Felix
Andrew McDonnell
2013-05-14 13:22:31 UTC
Permalink
Hi Felix

at this stage I have had no luck getting eth1 to work so I have deliberately
left out all the code attempting to make eth1 work. (I am intending to post
my progress to my github but I am all coded out for tonight)

But again, having no other point of reference I traced through the working
DDWRT driver and discovered that eth1 in this board is connected to S26
internal switch and sends mdio commands over 0x1a000000.

An easy test is when the following is present in the mach-dir632-a1.c, and if
you add debugging printks into the right places in ag71xx, you can see the
kernel enumerating phys 0..8 and 18 in eth0 and phys 0..4 in eth1 and
ag71xx_mdio.1.00 --> 05 shows up in /sys/class/mdio

+ ath79_register_mdio(1, 0);
+ ath79_eth1_data.mii_bus_dev = &ath79_mdio1_device.dev;

When I printk instrument the DD-WRT driver you can also see it writing to the
mdio registers on 0x1a000000 for eth1

I am new to how kernel ethernet drivers work so it is quite possible I am
misunderstanding something or misinterpreting some output - and it is hard to
find decent documentation on how all this works other than tracing kernel code
and experimenting, and reading and instrumenting the working source code in
DD-WRT.



--Andrew
Post by Felix Fietkau
Post by Andrew McDonnell
This patch allows a board to enable the mdio bus on the second ethernet port
provided by the AR7242 (as used in the D-Link DIR-632-A1.) The AR7242 (at
least on the dir632) has two ethernet, eth0 at 0x19000000 and eth1 at
0x1a000000, and both have enumerable mdio busses.
It further defaults to connecting eth1 to ag71xx-mdio.1 when registering eth1
with ath79 platform data.
Please note this superseded prior email with missing subject(!)
Are you sure about this? In other AR724x SoCs one MDIO bus goes to the
built-in switch, and the other one is external. You don't seem to make
use of the second MDIO bus in your DIR-632-A1 patch either.
I think the AR7242 does not have the built-in switch, so it would
surprise me to see a second MDIO bus being used there.
- Felix
Felix Fietkau
2013-05-14 13:33:35 UTC
Permalink
Post by Andrew McDonnell
Hi Felix
at this stage I have had no luck getting eth1 to work so I have deliberately
left out all the code attempting to make eth1 work. (I am intending to post
my progress to my github but I am all coded out for tonight)
But again, having no other point of reference I traced through the working
DDWRT driver and discovered that eth1 in this board is connected to S26
internal switch and sends mdio commands over 0x1a000000.
An easy test is when the following is present in the mach-dir632-a1.c, and if
you add debugging printks into the right places in ag71xx, you can see the
kernel enumerating phys 0..8 and 18 in eth0 and phys 0..4 in eth1 and
ag71xx_mdio.1.00 --> 05 shows up in /sys/class/mdio
+ ath79_register_mdio(1, 0);
+ ath79_eth1_data.mii_bus_dev = &ath79_mdio1_device.dev;
When I printk instrument the DD-WRT driver you can also see it writing to the
mdio registers on 0x1a000000 for eth1
I am new to how kernel ethernet drivers work so it is quite possible I am
misunderstanding something or misinterpreting some output - and it is hard to
find decent documentation on how all this works other than tracing kernel code
and experimenting, and reading and instrumenting the working source code in
DD-WRT.
With DD-WRT you have to keep in mind that it does not have proper
hardware/platform detection in the kernel. It simply registers a whole
bunch of stuff and then tries to fix up the mess in user space. You
should not use its register writes as a reference of what to do.
As for the changes enabling the second MDIO bus - I think we should hold
those back. It's more likely that your board shares the primary MDIO bus
between eth0 and eth1. You could try setting the PHY mask to BIT(18) for
eth1 (using mdio0) to make it attach to that PHY.

- Felix
Andrew McDonnell
2013-05-14 13:42:09 UTC
Permalink
Hi Felix,

I was wondering why there was something out on 18...

if setting that to the phy mask makes everything work after all my debugging I
will be very annoyed at myself for not posting my work sooner (and at DD-WRT!)

Yes, this patch is not immediately needed for support for the rest of the DIR632

thanks again

--Andrew
Post by Felix Fietkau
Post by Andrew McDonnell
Hi Felix
at this stage I have had no luck getting eth1 to work so I have deliberately
left out all the code attempting to make eth1 work. (I am intending to post
my progress to my github but I am all coded out for tonight)
But again, having no other point of reference I traced through the working
DDWRT driver and discovered that eth1 in this board is connected to S26
internal switch and sends mdio commands over 0x1a000000.
An easy test is when the following is present in the mach-dir632-a1.c, and if
you add debugging printks into the right places in ag71xx, you can see the
kernel enumerating phys 0..8 and 18 in eth0 and phys 0..4 in eth1 and
ag71xx_mdio.1.00 --> 05 shows up in /sys/class/mdio
+ ath79_register_mdio(1, 0);
+ ath79_eth1_data.mii_bus_dev = &ath79_mdio1_device.dev;
When I printk instrument the DD-WRT driver you can also see it writing to the
mdio registers on 0x1a000000 for eth1
I am new to how kernel ethernet drivers work so it is quite possible I am
misunderstanding something or misinterpreting some output - and it is hard to
find decent documentation on how all this works other than tracing kernel code
and experimenting, and reading and instrumenting the working source code in
DD-WRT.
With DD-WRT you have to keep in mind that it does not have proper
hardware/platform detection in the kernel. It simply registers a whole
bunch of stuff and then tries to fix up the mess in user space. You
should not use its register writes as a reference of what to do.
As for the changes enabling the second MDIO bus - I think we should hold
those back. It's more likely that your board shares the primary MDIO bus
between eth0 and eth1. You could try setting the PHY mask to BIT(18) for
eth1 (using mdio0) to make it attach to that PHY.
- Felix
Loading...