* CPM2 mii-bitbang: Allowing mdio on port pins other than port C
@ 2008-06-16 6:19 Mark Ware
2008-06-16 8:52 ` Laurent Pinchart
0 siblings, 1 reply; 4+ messages in thread
From: Mark Ware @ 2008-06-16 6:19 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
Hello,
I am preparing a board port (from 2.4.18!) for a proprietary board which
has it's mdio on a different port than mdc. The current mii-bitbang
driver in fs_enet assumes both pins are connected to port C. I have
created a fairly simple patch to make this more flexible, but I'm new to
device trees and am unsure how best to describe the situation in the
dts.
The current mdio node for CPM2 looks something like:
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,cpm2-mdio-bitbang";
#address-cells = <1>;
#size-cells = <0>
reg = <0x10d40 0x14>;
fsl,mdio-pin = <12>;
fsl,mdc-pin = <15>;
}
I have made mdio work on our board by adding a second reg range and
using the first one for mdc and the second one for mdio:
reg = <0x10d40 0x14 0x10d60 0x14>; // mdc=port D, mdio=port A
fsl,mdio-pin = <12>; // PD12
fsl,mdc-pin = <15>; // PC15
The code remains backwards compatible, in that if only one reg range is
present it is used for both.
Is this a valid (and acceptable) way to extend the reg property? Is
their a cleaner way I should look at?
Regards,
Mark Ware
[-- Attachment #2: B2010.dts --]
[-- Type: application/octet-stream, Size: 5095 bytes --]
/*
* Device Tree for the CypherNet B2010A005 motherboard
*
* Copyright 2008 Senetas PTY LTD
*
*/
/dts-v1/;
/ {
model = "B2010A005";
compatible = "ctam,B2010";
#address-cells = <1>;
#size-cells = <1>;
aliases {
serial0 = &smc2; // internal serial
serial1 = &scc4; // CLI
ethernet0 = &enet0;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8280@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <32>;
i-cache-line-size = <32>;
d-cache-size = <16384>;
i-cache-size = <16384>;
timebase-frequency = <0>; // Filled in by U-Boot
clock-frequency = <0>; // Filled in by U-Boot
bus-frequency = <0>; // Filled in by U-Boot
};
};
memory {
device_type = "memory";
reg = <0 0>; // Filled in by U-Boot
};
localbus@f0010100 {
compatible = "fsl,mpc8280-localbus",
"fsl,pq2-localbus",
"simple-bus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0xf0010100 0x60>;
ranges = <0x0 0x0 0xfe000000 0x02000000 // via JMP4 flash/BootSIMM
0x3 0x0 0xe0000000 0x01000000 // local SDRAM
0x8 0x0 0xf0200000 0x00200000
>;
};
soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8280-immr", "fsl,pq2-soc", "simple-bus";
ranges = <0x00000000 0xf0000000 0x00053000>;
device_type = "soc";
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8280-cpm", "fsl,cpm2",
"simple-bus";
reg = <0x119c0 0x30>;
ranges;
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,cpm-muram";
ranges = <0 0 0x10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0x0 0x2000 0x9800 0x800>; // orig
// reg = <0x80 0x1f80 0x9800 0x800>;
};
};
brg@119f0 {
compatible = "fsl,mpc8280-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <0x119f0 0x10 0x115f0 0x10>;
clock-frequency = <150000000>;
};
// Internal serial port
smc2: serial@11a90 {
device_type = "serial";
compatible = "fsl,mpc8280-smc-uart",
"fsl,cpm2-smc-uart";
reg = <0x11a90 0x20 0x88fc 0x02>;
interrupts = <5 8>; //SIU_INT_SMC2
interrupt-parent = <&PIC>; //????
fsl,cpm-brg = <8>; // taken from 82xx/uart.c in 2.4.18
fsl,cpm-command = <0x21200000>;
current-speed = <19200>; // u-boot?
};
// CLI
scc4: serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8280-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a60 0x20 0x8300 0x100>;
interrupts = <0x2b 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>; // taken from 82xx/uart.c in 2.4.18
fsl,cpm-command = <0x0ce00000>;
current-speed = <9600>;
};
// Front panel etherent (fcc3)
enet0: ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8280-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <0x11340 0x20 0x8600 0x100 0x113d0 1>;
local-mac-address = [00 00 00 00 00 00 ]; // u-boot
interrupts = <0x22 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <0x1a400300>;
};
mdio@10d40 {
device_type = "mdio";
compatible = "ctam,B2010-mdio-bitbang",
"fsl,mpc8280-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x10d60 0x14 0x10d40 0x14>; //mdio, mdc
fsl,mdio-pin = <12>; // PD12
fsl,mdc-pin = <15>; // PC15
PHY0: ethernet-phy@0 {
reg = <0x0>;
device_type = "ethernet-phy";
};
};
};
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <0x10c00 0x80>;
compatible = "fsl,mpc8280-pic", "fsl,cpm2-pic"; // or fsl,pq2-pic
};
};
chosen {
linux,stdout-path = &smc2;
};
};
[-- Attachment #3: B2010.dts --]
[-- Type: application/octet-stream, Size: 5095 bytes --]
/*
* Device Tree for the CypherNet B2010A005 motherboard
*
* Copyright 2008 Senetas PTY LTD
*
*/
/dts-v1/;
/ {
model = "B2010A005";
compatible = "ctam,B2010";
#address-cells = <1>;
#size-cells = <1>;
aliases {
serial0 = &smc2; // internal serial
serial1 = &scc4; // CLI
ethernet0 = &enet0;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8280@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <32>;
i-cache-line-size = <32>;
d-cache-size = <16384>;
i-cache-size = <16384>;
timebase-frequency = <0>; // Filled in by U-Boot
clock-frequency = <0>; // Filled in by U-Boot
bus-frequency = <0>; // Filled in by U-Boot
};
};
memory {
device_type = "memory";
reg = <0 0>; // Filled in by U-Boot
};
localbus@f0010100 {
compatible = "fsl,mpc8280-localbus",
"fsl,pq2-localbus",
"simple-bus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0xf0010100 0x60>;
ranges = <0x0 0x0 0xfe000000 0x02000000 // via JMP4 flash/BootSIMM
0x3 0x0 0xe0000000 0x01000000 // local SDRAM
0x8 0x0 0xf0200000 0x00200000
>;
};
soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8280-immr", "fsl,pq2-soc", "simple-bus";
ranges = <0x00000000 0xf0000000 0x00053000>;
device_type = "soc";
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8280-cpm", "fsl,cpm2",
"simple-bus";
reg = <0x119c0 0x30>;
ranges;
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,cpm-muram";
ranges = <0 0 0x10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0x0 0x2000 0x9800 0x800>; // orig
// reg = <0x80 0x1f80 0x9800 0x800>;
};
};
brg@119f0 {
compatible = "fsl,mpc8280-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <0x119f0 0x10 0x115f0 0x10>;
clock-frequency = <150000000>;
};
// Internal serial port
smc2: serial@11a90 {
device_type = "serial";
compatible = "fsl,mpc8280-smc-uart",
"fsl,cpm2-smc-uart";
reg = <0x11a90 0x20 0x88fc 0x02>;
interrupts = <5 8>; //SIU_INT_SMC2
interrupt-parent = <&PIC>; //????
fsl,cpm-brg = <8>; // taken from 82xx/uart.c in 2.4.18
fsl,cpm-command = <0x21200000>;
current-speed = <19200>; // u-boot?
};
// CLI
scc4: serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8280-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a60 0x20 0x8300 0x100>;
interrupts = <0x2b 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>; // taken from 82xx/uart.c in 2.4.18
fsl,cpm-command = <0x0ce00000>;
current-speed = <9600>;
};
// Front panel etherent (fcc3)
enet0: ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8280-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <0x11340 0x20 0x8600 0x100 0x113d0 1>;
local-mac-address = [00 00 00 00 00 00 ]; // u-boot
interrupts = <0x22 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <0x1a400300>;
};
mdio@10d40 {
device_type = "mdio";
compatible = "ctam,B2010-mdio-bitbang",
"fsl,mpc8280-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x10d60 0x14 0x10d40 0x14>; //mdio, mdc
fsl,mdio-pin = <12>; // PD12
fsl,mdc-pin = <15>; // PC15
PHY0: ethernet-phy@0 {
reg = <0x0>;
device_type = "ethernet-phy";
};
};
};
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <0x10c00 0x80>;
compatible = "fsl,mpc8280-pic", "fsl,cpm2-pic"; // or fsl,pq2-pic
};
};
chosen {
linux,stdout-path = &smc2;
};
};
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: CPM2 mii-bitbang: Allowing mdio on port pins other than port C
2008-06-16 6:19 CPM2 mii-bitbang: Allowing mdio on port pins other than port C Mark Ware
@ 2008-06-16 8:52 ` Laurent Pinchart
2008-06-18 12:21 ` Mark Ware
0 siblings, 1 reply; 4+ messages in thread
From: Laurent Pinchart @ 2008-06-16 8:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mark Ware
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
Hi Mark,
On Monday 16 June 2008 08:19, Mark Ware wrote:
> Hello,
>
> I am preparing a board port (from 2.4.18!) for a proprietary board which
> has it's mdio on a different port than mdc. The current mii-bitbang
> driver in fs_enet assumes both pins are connected to port C. I have
> created a fairly simple patch to make this more flexible, but I'm new to
> device trees and am unsure how best to describe the situation in the
> dts.
>
> The current mdio node for CPM2 looks something like:
>
> mdio@10d40 {
> device_type = "mdio";
> compatible = "fsl,cpm2-mdio-bitbang";
> #address-cells = <1>;
> #size-cells = <0>
> reg = <0x10d40 0x14>;
> fsl,mdio-pin = <12>;
> fsl,mdc-pin = <15>;
> }
>
> I have made mdio work on our board by adding a second reg range and
> using the first one for mdc and the second one for mdio:
>
> reg = <0x10d40 0x14 0x10d60 0x14>; // mdc=port D, mdio=port A
> fsl,mdio-pin = <12>; // PD12
> fsl,mdc-pin = <15>; // PC15
>
> The code remains backwards compatible, in that if only one reg range is
> present it is used for both.
>
> Is this a valid (and acceptable) way to extend the reg property?
It is. Sergej Stepanov submitted similar patches some times ago. You can find
them at
http://www.spinics.net/lists/netdev/msg45778.html
http://www.spinics.net/lists/netdev/msg47159.html
> Is their a cleaner way I should look at?
Using the GPIO lib might be cleaner. Have a look at
http://www.nabble.com/-PATCH-0-2--MDIO-on-GPIO-support-for-the-fs_enet-driver-ts17468958.html
for a patch.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread* RE: CPM2 mii-bitbang: Allowing mdio on port pins other than port C
2008-06-16 8:52 ` Laurent Pinchart
@ 2008-06-18 12:21 ` Mark Ware
2008-06-18 14:36 ` Laurent Pinchart
0 siblings, 1 reply; 4+ messages in thread
From: Mark Ware @ 2008-06-18 12:21 UTC (permalink / raw)
To: Laurent Pinchart, linuxppc-dev
Hi Laurent,
> -----Original Message-----
> From: Laurent Pinchart [mailto:laurentp@cse-semaphore.com]=20
> Sent: Monday, 16 June 2008 18:53
> To: linuxppc-dev@ozlabs.org
> Cc: Mark Ware
> Subject: Re: CPM2 mii-bitbang: Allowing mdio on port pins=20
> other than port C
>=20
> Hi Mark,
>=20
> On Monday 16 June 2008 08:19, Mark Ware wrote:
> > Hello,
> >=20
> > I am preparing a board port (from 2.4.18!) for a proprietary board=20
> > which has it's mdio on a different port than mdc. The current=20
> > mii-bitbang driver in fs_enet assumes both pins are=20
> connected to port=20
> > C. I have created a fairly simple patch to make this more=20
> flexible,=20
> > but I'm new to device trees and am unsure how best to describe the=20
> > situation in the dts.
> >=20
> > The current mdio node for CPM2 looks something like:
> >=20
> > mdio@10d40 {
> > device_type =3D "mdio";
> > compatible =3D "fsl,cpm2-mdio-bitbang";
> > #address-cells =3D <1>;
> > #size-cells =3D <0>
> > reg =3D <0x10d40 0x14>;
> > fsl,mdio-pin =3D <12>;
> > fsl,mdc-pin =3D <15>;
> > }
> >=20
> > I have made mdio work on our board by adding a second reg range and=20
> > using the first one for mdc and the second one for mdio:
> >=20
> > reg =3D <0x10d40 0x14 0x10d60 0x14>; // mdc=3Dport D, mdio=3Dport =
A
> > fsl,mdio-pin =3D <12>; // PD12
> > fsl,mdc-pin =3D <15>; // PC15
> >=20
> > The code remains backwards compatible, in that if only one=20
> reg range=20
> > is present it is used for both.
> >=20
> > Is this a valid (and acceptable) way to extend the reg property?
>=20
> It is. Sergej Stepanov submitted similar patches some times=20
> ago. You can find them at
>=20
> http://www.spinics.net/lists/netdev/msg45778.html
> http://www.spinics.net/lists/netdev/msg47159.html
>=20
> > Is their a cleaner way I should look at?
>=20
> Using the GPIO lib might be cleaner. Have a look at=20
> http://www.nabble.com/-PATCH-0-2--MDIO-on-GPIO-support-for-the
> -fs_enet-driver-ts17468958.html
> for a patch.
>=20
Thanks for the links. It looks like I should have been searching in
netdev not powerpc for this.
I will look at Sergej's patch and perhaps submit a merged version, but
with the GPIO version likely to be merged is there much point? The GPIO
lib method appears to be a more generic replacement.
Regards,
Mark
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: CPM2 mii-bitbang: Allowing mdio on port pins other than port C
2008-06-18 12:21 ` Mark Ware
@ 2008-06-18 14:36 ` Laurent Pinchart
0 siblings, 0 replies; 4+ messages in thread
From: Laurent Pinchart @ 2008-06-18 14:36 UTC (permalink / raw)
To: Mark Ware; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2563 bytes --]
Hi Mark,
On Wednesday 18 June 2008 14:21, Mark Ware wrote:
> Hi Laurent,
> > Hi Mark,
> >
> > On Monday 16 June 2008 08:19, Mark Ware wrote:
> > > Hello,
> > >
> > > I am preparing a board port (from 2.4.18!) for a proprietary board
> > > which has it's mdio on a different port than mdc. The current
> > > mii-bitbang driver in fs_enet assumes both pins are
> > connected to port
> > > C. I have created a fairly simple patch to make this more
> > flexible,
> > > but I'm new to device trees and am unsure how best to describe the
> > > situation in the dts.
> > >
> > > The current mdio node for CPM2 looks something like:
> > >
> > > mdio@10d40 {
> > > device_type = "mdio";
> > > compatible = "fsl,cpm2-mdio-bitbang";
> > > #address-cells = <1>;
> > > #size-cells = <0>
> > > reg = <0x10d40 0x14>;
> > > fsl,mdio-pin = <12>;
> > > fsl,mdc-pin = <15>;
> > > }
> > >
> > > I have made mdio work on our board by adding a second reg range and
> > > using the first one for mdc and the second one for mdio:
> > >
> > > reg = <0x10d40 0x14 0x10d60 0x14>; // mdc=port D, mdio=port A
> > > fsl,mdio-pin = <12>; // PD12
> > > fsl,mdc-pin = <15>; // PC15
> > >
> > > The code remains backwards compatible, in that if only one
> > reg range
> > > is present it is used for both.
> > >
> > > Is this a valid (and acceptable) way to extend the reg property?
> >
> > It is. Sergej Stepanov submitted similar patches some times
> > ago. You can find them at
> >
> > http://www.spinics.net/lists/netdev/msg45778.html
> > http://www.spinics.net/lists/netdev/msg47159.html
> >
> > > Is their a cleaner way I should look at?
> >
> > Using the GPIO lib might be cleaner. Have a look at
> > http://www.nabble.com/-PATCH-0-2--MDIO-on-GPIO-support-for-the
> > -fs_enet-driver-ts17468958.html
> > for a patch.
> >
>
> Thanks for the links. It looks like I should have been searching in
> netdev not powerpc for this.
>
> I will look at Sergej's patch and perhaps submit a merged version, but
> with the GPIO version likely to be merged is there much point? The GPIO
> lib method appears to be a more generic replacement.
I don't see much reason to use the non-GPIO version (except maybe on very
memory constrained platforms to avoid pulling the GPIO lib in the kernel, but
that would help much).
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-06-18 14:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-16 6:19 CPM2 mii-bitbang: Allowing mdio on port pins other than port C Mark Ware
2008-06-16 8:52 ` Laurent Pinchart
2008-06-18 12:21 ` Mark Ware
2008-06-18 14:36 ` Laurent Pinchart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).