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

From: Shaohui Xie <Shaohui.Xie@freescale.com>

This binding is for FMan MDIO, it covers FMan v2 & FMan v3.

Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
---
changes in V2:
addressed comments from Scott in V1.

 .../devicetree/bindings/powerpc/fsl/fman.txt       | 69 ++++++++++++++++++++++
 1 file changed, 69 insertions(+)

Ping.

Best Regards, 
Shaohui Xie

> -----Original Message-----
> From: shh.xie@gmail.com [mailto:shh.xie@gmail.com]
> Sent: Friday, November 14, 2014 5:53 PM
> To: linuxppc-dev@lists.ozlabs.org; devicetree@vger.kernel.org; Wood
> Scott-B07421
> Cc: Medve Emilian-EMMEDVE1; Liberman Igal-B31950; Xie Shaohui-B21989
> Subject: [PATCH] [v2] power/fsl: add MDIO dt binding for FMan
> 
> From: Shaohui Xie <Shaohui.Xie@freescale.com>
> 
> This binding is for FMan MDIO, it covers FMan v2 & FMan v3.
> 
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> changes in V2:
> addressed comments from Scott in V1.
> 
>  .../devicetree/bindings/powerpc/fsl/fman.txt       | 69
> ++++++++++++++++++++++
>  1 file changed, 69 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> index edeea16..1523a87 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> @@ -7,6 +7,7 @@ CONTENTS
>    - FMan MURAM Node
>    - FMan dTSEC/XGEC/mEMAC Node
>    - FMan IEEE 1588 Node
> +  - FMan MDIO Node
>    - Example
> 
> 
> =========================================================================
> ====
> @@ -357,6 +358,68 @@ ptp-timer@fe000 {
>  };
> 
> 
> =========================================================================
> ====
> +FMan MDIO Node
> +
> +DESCRIPTION
> +
> +The MDIO is a bus to which the PHY devices are connected.
> +
> +PROPERTIES
> +
> +- compatible
> +		Usage: required
> +		Value type: <stringlist>
> +		Definition: A standard property.
> +		Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
> +		Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
> +		Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
> +		FMan v3.
> +
> +- reg
> +		Usage: required
> +		Value type: <prop-encoded-array>
> +		Definition: A standard property.
> +
> +- bus-frequency
> +		Usage: optional
> +		Value type: <u32>
> +		Definition: Specifies external MDIO bus clock speed which is
> +		different from MDIO standard 2.5MHz. Should be defined for
> SoCs
> +		on which the standard one cannot work.
> +
> +- interrupts
> +		Usage: optional
> +		Value type: <prop-encoded-array>
> +		Definition: Event interrupt of external MDIO controller.
> +		1 Gb/s MDIO and 10 Gb/s MDIO has one interrupt respectively.
> +
> +- fsl,fman-internal-mdio
> +		Usage: required for internal MDIO
> +		Value type: boolean
> +		Definition: Fman has internal MDIO for internal PCS(Physical
> +		Coding Sublayer) PHYs and external MDIO for external PHYs.
> +		The settings and programming routines for internal/external
> +		MDIO are different. Must be included for internal MDIO.
> +
> +EXAMPLE
> +
> +Example for FMan v2 external MDIO:
> +
> +mdio@f1000 {
> +	compatible = "fsl,fman-xmdio";
> +	reg = <0xf1000 0x1000>;
> +	bus-frequency = <20000>;
> +};
> +
> +Example for FMan v3 internal MDIO:
> +
> +mdio@f1000 {
> +	compatible = "fsl,fman-memac-mdio";
> +	reg = <0xf1000 0x1000>;
> +	fsl,fman-internal-mdio;
> +};
> +
> +========================================================================
> =====
>  Example
> 
>  fman@400000 {
> @@ -531,4 +594,10 @@ fman@400000 {
>  		compatible = "fsl,fman-ptp-timer";
>  		reg = <0xfe000 0x1000>;
>  	};
> +
> +	mdio@f1000 {
> +		compatible = "fsl,fman-xmdio";
> +		reg = <0xf1000 0x1000>;
> +		bus-frequency = <20000>;
> +	};
>  };
> --
> 1.8.4.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, 2014-11-14 at 17:53 +0800, shh.xie@gmail.com wrote:
> From: Shaohui Xie <Shaohui.Xie@freescale.com>
> 
> This binding is for FMan MDIO, it covers FMan v2 & FMan v3.
> 
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> changes in V2:
> addressed comments from Scott in V1.
> 
>  .../devicetree/bindings/powerpc/fsl/fman.txt       | 69 ++++++++++++++++++++++
>  1 file changed, 69 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> index edeea16..1523a87 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> @@ -7,6 +7,7 @@ CONTENTS
>    - FMan MURAM Node
>    - FMan dTSEC/XGEC/mEMAC Node
>    - FMan IEEE 1588 Node
> +  - FMan MDIO Node
>    - Example
>  
>  =============================================================================
> @@ -357,6 +358,68 @@ ptp-timer@fe000 {
>  };
>  
>  =============================================================================
> +FMan MDIO Node
> +
> +DESCRIPTION
> +
> +The MDIO is a bus to which the PHY devices are connected.
> +
> +PROPERTIES
> +
> +- compatible
> +		Usage: required
> +		Value type: <stringlist>
> +		Definition: A standard property.
> +		Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
> +		Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
> +		Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
> +		FMan v3.
> +
> +- reg
> +		Usage: required
> +		Value type: <prop-encoded-array>
> +		Definition: A standard property.
> +
> +- bus-frequency
> +		Usage: optional
> +		Value type: <u32>
> +		Definition: Specifies external MDIO bus clock speed which is
> +		different from MDIO standard 2.5MHz. Should be defined for SoCs
> +		on which the standard one cannot work.
> +
> +- interrupts
> +		Usage: optional
> +		Value type: <prop-encoded-array>
> +		Definition: Event interrupt of external MDIO controller.
> +		1 Gb/s MDIO and 10 Gb/s MDIO has one interrupt respectively.
> +
> +- fsl,fman-internal-mdio
> +		Usage: required for internal MDIO
> +		Value type: boolean
> +		Definition: Fman has internal MDIO for internal PCS(Physical
> +		Coding Sublayer) PHYs and external MDIO for external PHYs.
> +		The settings and programming routines for internal/external
> +		MDIO are different. Must be included for internal MDIO.
> +
> +EXAMPLE
> +
> +Example for FMan v2 external MDIO:
> +
> +mdio@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?

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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@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.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

> -----Original Message-----

> From: Wood Scott-B07421

> Sent: Friday, December 19, 2014 6:01 AM

> To: Xie Shaohui-B21989

> Cc: linuxppc-dev@lists.ozlabs.org; devicetree@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@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?

Thanks!
Shaohui

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@lists.ozlabs.org; devicetree@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@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.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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@lists.ozlabs.org; devicetree@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@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.

For the purpose of an example in the binding document, I suggest we just
stick with the IEEE standard frequency. We can continue this
conversation about errata handling when we submit the code relevant to
this binding (and the FMan v3 support)


Cheers,
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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@lists.ozlabs.org; devicetree@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@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?

> 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


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

> -----Original Message-----

> From: Wood Scott-B07421

> Sent: Monday, December 22, 2014 4:33 PM

> To: Medve Emilian-EMMEDVE1

> Cc: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org;

> devicetree@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@lists.ozlabs.org; devicetree@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@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

>

Hello Scott,


On 12/22/2014 02:32 AM, Scott Wood wrote:
> 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@lists.ozlabs.org; devicetree@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@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?
> 
>> 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.

While the standard claims 2.5 MHz, most MDIO controllers and PHY devices
support frequencies well beyond the standard. Specifying a lower then
the standard frequency for the benefit of some errata is just one side
of this property

>> 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.

I think this specific (unpublished yet) errata has less bearing on the
binding then you might believe. This is mostly about providing a
common/default frequency supported by all the devices on some board

Anyway, the above thread about bits and lowest frequency limitation(s)
is not really a problem/limitation. The range of frequencies (dividers)
supported by both controller versions in all the supported SoC(s) allows
responding to this (FMan v3 only) errata just fine


Cheers,
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote:
> Hello Scott,
> 
> 
> On 12/22/2014 02:32 AM, Scott Wood wrote:
> > On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
> >> 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.
> 
> While the standard claims 2.5 MHz, most MDIO controllers and PHY devices
> support frequencies well beyond the standard. Specifying a lower then
> the standard frequency for the benefit of some errata is just one side
> of this property

The erratum was (until now) the only claimed reason for it.  If there
are other reasons why one would specify a different frequency (in
particular, that relate to hardware description), please elaborate.

> >> 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.
> 
> I think this specific (unpublished yet) errata has less bearing on the
> binding then you might believe. This is mostly about providing a
> common/default frequency supported by all the devices on some board

What reason other than an erratum would there be for the standard
frequency not being supported?

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hello Scott,


On 12/22/2014 03:42 AM, Scott Wood wrote:
> On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 12/22/2014 02:32 AM, Scott Wood wrote:
>>> On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
>>>> 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.
>>
>> While the standard claims 2.5 MHz, most MDIO controllers and PHY devices
>> support frequencies well beyond the standard. Specifying a lower then
>> the standard frequency for the benefit of some errata is just one side
>> of this property
> 
> The erratum was (until now) the only claimed reason for it.  If there
> are other reasons why one would specify a different frequency (in
> particular, that relate to hardware description), please elaborate.

>From memory, the 1 Gb/s Vitesse PHY(s) we have on some of our DS boards
support 12.5 MHz. I can dig out more specs for specifics on other PHY(s)

2.5 MHz is slow and even more so for high speed interfaces. With both
polling and interrupts (both MDIO and/or PHY) we've noticed (or blamed)
in the past some Ethernet performance issues on this very slowness

As of right now I'm not aware of another way to specify/coordinate the
MDC speed so setting a default (common denominator) in the DT that is
different then the IEEE standard seems ok

>>>> 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.
>>
>> I think this specific (unpublished yet) errata has less bearing on the
>> binding then you might believe. This is mostly about providing a
>> common/default frequency supported by all the devices on some board
> 
> What reason other than an erratum would there be for the standard
> frequency not being supported?

This is not about not supporting the standard frequency. This is about
the default frequency being different then the standard


Cheers,
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, 2014-12-22 at 05:08 -0600, Emil Medve wrote:
> Hello Scott,
> 
> 
> On 12/22/2014 03:42 AM, Scott Wood wrote:
> > On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 12/22/2014 02:32 AM, Scott Wood wrote:
> >>> On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:
> >>>> 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.
> >>
> >> While the standard claims 2.5 MHz, most MDIO controllers and PHY devices
> >> support frequencies well beyond the standard. Specifying a lower then
> >> the standard frequency for the benefit of some errata is just one side
> >> of this property
> > 
> > The erratum was (until now) the only claimed reason for it.  If there
> > are other reasons why one would specify a different frequency (in
> > particular, that relate to hardware description), please elaborate.
> 
> From memory, the 1 Gb/s Vitesse PHY(s) we have on some of our DS boards
> support 12.5 MHz. I can dig out more specs for specifics on other PHY(s)
> 
> 2.5 MHz is slow and even more so for high speed interfaces. With both
> polling and interrupts (both MDIO and/or PHY) we've noticed (or blamed)
> in the past some Ethernet performance issues on this very slowness
> 
> As of right now I'm not aware of another way to specify/coordinate the
> MDC speed so setting a default (common denominator) in the DT that is
> different then the IEEE standard seems ok
>
> >>>> 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.
> >>
> >> I think this specific (unpublished yet) errata has less bearing on the
> >> binding then you might believe. This is mostly about providing a
> >> common/default frequency supported by all the devices on some board
> > 
> > What reason other than an erratum would there be for the standard
> > frequency not being supported?
> 
> This is not about not supporting the standard frequency. This is about
> the default frequency being different then the standard

OK, though rather than talk about defaults I'd phrase it as indicating
that a higher frequency than standard is supported, or that a lower
frequency than standard is required.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Best Regards, 
Shaohui Xie


> -----Original Message-----

> From: Wood Scott-B07421

> Sent: Tuesday, December 23, 2014 5:26 AM

> To: Medve Emilian-EMMEDVE1

> Cc: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org;

> devicetree@vger.kernel.org; Liberman Igal-B31950

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

> 

> On Mon, 2014-12-22 at 05:08 -0600, Emil Medve wrote:

> > Hello Scott,

> >

> >

> > On 12/22/2014 03:42 AM, Scott Wood wrote:

> > > On Mon, 2014-12-22 at 03:37 -0600, Emil Medve wrote:

> > >> Hello Scott,

> > >>

> > >>

> > >> On 12/22/2014 02:32 AM, Scott Wood wrote:

> > >>> On Mon, 2014-12-22 at 02:20 -0600, Emil Medve wrote:

> > >>>> 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.

> > >>

> > >> While the standard claims 2.5 MHz, most MDIO controllers and PHY

> > >> devices support frequencies well beyond the standard. Specifying a

> > >> lower then the standard frequency for the benefit of some errata is

> > >> just one side of this property

> > >

> > > The erratum was (until now) the only claimed reason for it.  If

> > > there are other reasons why one would specify a different frequency

> > > (in particular, that relate to hardware description), please

> elaborate.

> >

> > From memory, the 1 Gb/s Vitesse PHY(s) we have on some of our DS

> > boards support 12.5 MHz. I can dig out more specs for specifics on

> > other PHY(s)

> >

> > 2.5 MHz is slow and even more so for high speed interfaces. With both

> > polling and interrupts (both MDIO and/or PHY) we've noticed (or

> > blamed) in the past some Ethernet performance issues on this very

> > slowness

> >

> > As of right now I'm not aware of another way to specify/coordinate the

> > MDC speed so setting a default (common denominator) in the DT that is

> > different then the IEEE standard seems ok

> >

> > >>>> 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.

> > >>

> > >> I think this specific (unpublished yet) errata has less bearing on

> > >> the binding then you might believe. This is mostly about providing

> > >> a common/default frequency supported by all the devices on some

> > >> board

> > >

> > > What reason other than an erratum would there be for the standard

> > > frequency not being supported?

> >

> > This is not about not supporting the standard frequency. This is about

> > the default frequency being different then the standard

> 

> OK, though rather than talk about defaults I'd phrase it as indicating

> that a higher frequency than standard is supported, or that a lower

> frequency than standard is required.

[S.H] below is the statement in v2:

+- bus-frequency
+		Usage: optional
+		Value type: <u32>
+		Definition: Specifies external MDIO bus clock speed which is
+		different from MDIO standard 2.5MHz. Should be defined for SoCs
+		on which the standard one cannot work.

What should I rephrase it? Replace the last sentence with "Should be defined
For SoCs on which a lower frequency than the standard is required."?

How about the value used in example?
Should 2.5MHz be used or a lower one?

Thanks!
Shaohui

On Tue, 2014-12-23 at 01:35 -0600, Xie Shaohui-B21989 wrote:
> +- bus-frequency
> +		Usage: optional
> +		Value type: <u32>
> +		Definition: Specifies external MDIO bus clock speed which is
> +		different from MDIO standard 2.5MHz. Should be defined for SoCs
> +		on which the standard one cannot work.
> 
> What should I rephrase it? Replace the last sentence with "Should be defined
> For SoCs on which a lower frequency than the standard is required."?

Neither of these work with Emil's scenario of a system that allows a
faster-than-standard speed.

How about: "Definition: Specifies the external MDIO bus clock speed to
be used, if different from the standard 2.5 MHz.  This may be due to the
standard speed being unsupported (e.g. due to a hardware problem), or to
advertise that all relevant components in the system support a faster
speed."

> How about the value used in example?
> Should 2.5MHz be used or a lower one?

If you don't have a realistic example to use, don't put it in the
example at all.  2.5MHz is the worst example to use because that's the
default and there'd be no reason to use the property at all.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html