[PATCH] [v2] power/fsl: add MDIO dt binding for FMan

[Shaohui Xie]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Monday, December 22, 2014 4:33 PM
> To: Medve Emilian-EMMEDVE1
> Cc: Xie Shaohui-B21989; linuxppc-dev at lists.ozlabs.org;
> devicetree at vger.kernel.org; Liberman Igal-B31950
> Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> 
> On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
> > Hello Shao-Hui,
> >
> >
> > On 12/21/2014 08:31 PM, Xie Shaohui-B21989 wrote:
> > >> On Fri, 2014-12-19 at 01:23 -0600, Xie Shaohui-B21989 wrote:
> > >>>> -----Original Message-----
> > >>>> From: Wood Scott-B07421
> > >>>> Sent: Friday, December 19, 2014 6:01 AM
> > >>>> To: Xie Shaohui-B21989
> > >>>> Cc: linuxppc-dev at lists.ozlabs.org; devicetree at vger.kernel.org;
> > >>>> Medve
> > >>>> Emilian- EMMEDVE1; Liberman Igal-B31950
> > >>>> Subject: Re: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> > >>>>
> > >>>> On Thu, 2014-12-18 at 06:53 -0600, Xie Shaohui-B21989 wrote:
> > >>>>> Ping.
> > >>>>>
> > >>>>> Best Regards,
> > >>>>> Shaohui Xie
> > >>>>
> > >>>> I can't put patches in my -next until the merge window closes.
> > >>>>
> > >>>>>>>> +EXAMPLE
> > >>>>>>>> +
> > >>>>>>>> +Example for FMan v2 external MDIO:
> > >>>>>>>> +
> > >>>>>>>> +mdio at f1000 {
> > >>>>>>>> +	compatible = "fsl,fman-xmdio";
> > >>>>>>>> +	reg = <0xf1000 0x1000>;
> > >>>>>>>> +	bus-frequency = <20000>;
> > >>>>>>>> +};
> > >>>>>>>
> > >>>>>>> So the bus frequency is only 20 KHz?  Or is the unit supposed
> > >>>>>>> to be something other than Hz?
> > >>>>>> [S.H] it's only an example, it could be different on real SoCs,
> > >>>>>> but they always lower than the standard one, The standard one
> > >>>>>> is 2.5MHz, I have
> > >>>> to use Hz for it.
> > >>>>
> > >>>> Is there any SoC for which 20 kHz is the right frequency?  I just
> > >>>> want to make sure the example is realistic.
> > >>> [S.H] the clock divider has a limitation that the MAX value it can
> > >>> get on Fman v2 is 255 (0xff, 8 bits), On Fman v3 is 511(0x1ff, 9 bits).
> > >>>
> > >>> So the lowest frequency on Fman v2 is: Fman_clock / (2 * 255), On
> > >>> Fman
> > >>> v3 is: Fman_clock / ((2 * 511) + 1).
> > >>>
> > >>> Take default Fman frequency setting from SDK1.7 as example, the
> > >>> lowest clock used for Fman v2 is 581MHz, The lowest clock for Fman v3 is
> 600MHz.
> > >>>
> > >>> Then the lowest bus frequency can get is:
> > >>> Fman v2: ~1140KHz
> > >>> Fman v3: ~587KHz
> > >>>
> > >>> 20KHz is not practice, we don't have a suggested value in errata document.
> > >>> For this example, should I post a new version with a value like 1200KHz?
> > >>
> > >> This is different from how you described the problem before.  If
> > >> the limitation is on the divider, rather than the absolute bus
> > >> frequency, then specifiy the max divider.  Or better, since
> > >> according to the above this correlates with fman version, just have the
> driver know what the max divider is for each fman version.
> > > [S.H] The problem is not the divider has limitation, the problem is
> > > a different bus frequency Is needed which is lower than the
> > > standard, but due to the divider limitation, the lowest bus
> > > frequency also has limitation. i.e. we need to use the divider to get a
> lower frequency, but how much lower the value could be is restricted by the
> divider limitation.
> 
> This is difficult to follow -- are you saying the erratum requires a speed that
> is not achievable?
[S.H] The errata only stated that it need to use a larger divider to reduce the clock
Frequency, but it did not provide a suggested value, what we know is since the divider
Has a limitation, then how much lower the clock frequency could be reduced has a limitation.

Thanks!
Shaohui
> 
> > For the purpose of an example in the binding document, I suggest we
> > just stick with the IEEE standard frequency.
> 
> The whole reason for this property existing in the device tree is non-standard
> frequencies.
> 
> > We can continue this conversation about errata handling when we submit
> > the code relevant to this binding (and the FMan v3 support)
> 
> It affects the binding, so let's discuss it now please.
> 
> -Scott
>