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

Scott Wood scottwood at freescale.com
Tue Dec 23 08:25:51 AEDT 2014


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




More information about the Linuxppc-dev mailing list