Re: GPIO registration for external Ethernet PHY oscillator enable/disable

[Michael Welling]

On Fri, Sep 26, 2014 at 10:16:51AM -0700, Florian Fainelli wrote:
> On 09/26/2014 09:59 AM, Michael Welling wrote:
> > On Thu, Sep 25, 2014 at 12:56:34PM -0700, Florian Fainelli wrote:
> >> So, PHY drivers are allowed to provide specialized implementations for
> >> suspend/resume operations that are called by phy_suspend() and
> >> phy_resume(), the current Micrel PHY driver uses the generic
> >> suspend/resume implementation and it is best if we can keep doing that.
> >>
> > 
> > In my situation the defualt phy_suspend is not sufficient. We are
> > looking to use the board for an application that requires a low sleep
> > current. The KZS8081 has a slow oscillator low power mode that is 
> > required to meet the requirements.
> > 
> > So I have already overwritten the suspend/resume to send the required
> > commands to the PHY to achieve the slow clock mode.
> > 
> > If you are interested the sequence is explained in the datasheet pg 34:
> > http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ8081MNX-RNB.pdf
> > 
> >>> Can it be handled outside of the PHY driver?
> >>
> >> I see a few possible options:
> >>
> >> - hook a pm_runtime callbacks for your platform, check the device
> >> pointer to make sure this is the PHY device, and when that is the case,
> >> toggle the GPIO accordingly
> > 
> > Not too familiar with the pm_runtime callbacks.
> > 
> > Can you point me to a similar example that is already in the kernel?
> 
> drivers/sh/pm_runtime.c is a simple example, there might others in the
> OMAP code.
> 
> > 
> >>
> >> - add an additional "osc_gpio" configuration parameter passed to the
> >> Ethernet MAC driver (presumably drivers/net/ethernet/cadence/macb.c?)
> >> and toggle the GPIO before and after the calls to the PHY state machine
> >> (phy_suspend, phy_resume, phy_start, phy_stop), that might be simpler
> >>
> > 
> > This seems the wrong place as the oscillator is specific to the PHY.
> 
> Yes and no, this might feel like the wrong place, but ultimately, the
> Ethernet MAC is a consumer of the PHY device, and is in control, through
> the PHY library of how and when the PHY gets to be powered off.

This is a good point. This driver also has the added advantage that it
is a platform driver so the GPIO could more easily be registered via
the device tree.

Lets try this option first and see how it works out.

> 
> > 
> >> - last but not least, make the PHY driver aware of that optional GPIO,
> >> create customized PHY suspend/resume/config_aneg callbacks
> >>
> > 
> > This to me feels like the path of least resistance. Though the driver
> > does not appear to be a platform driver so I am not sure how to pass
> > GPIOs to it. Maybe I am missing something.
> 
> If your platform uses Device Tree, you need to add a probe() and
> remove() callbacks to the micrel PHY driver, and fetch the gpio resource
> from there.
> 
> For non-Device Tree, we might have to find an another to specify such
> auxiliary information, but traditionally, people have been using the
> help of the Ethernet MAC driver to provide additional information down
> to the PHY driver.
> --
> Florian
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/