CPM2 mii-bitbang: Allowing mdio on port pins other than port C

[Laurent Pinchart]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080618/9d996ea1/attachment.pgp>