Re: [RFC PATCH 1/2] Regulator: Core: Add clock-enable to fixed-regulator

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

On Tue, Jul 30, 2019 at 09:00:01PM +0000, Philippe Schenker wrote:
> On Tue, 2019-07-30 at 19:10 +0100, Mark Brown wrote:
> > On Tue, Jul 30, 2019 at 07:30:04PM +0200, Philippe Schenker wrote:

> > > This adds the possibility to enable a fixed-regulator with a clock.

> > Why?  What does the hardware which makes this make sense look like?

> Tomorrow I can provide some schematics if needed. But its just a simple
> switch that is switched by a clock (on when clock is on and off when
> clock is off). This clock is the RGMII 50MHz clock for the ethernet
> PHY.

So it's not switching with the clock, the circuit somehow keeps the
switch latched?

> Why is a regulator even needed?
> - On power up of the PHY there is a huge time I have to wait for
> voltage rail to settle. In the range of 100ms.
> - Because there is a switch in the circuit I abstract it with a
> regulator-fixed in devicetree to make use of the startup-delay.
> - This regulator/switch is enabled with a clock. So to be able to use
> the startup delay I need an enable-by-clock on regulator-fixed.

It does feel like it might be simpler to just handle this as a quirk in
the PHY or ethernet driver, this feels like an awful lot of work to
add a sleep on what's probably only going to ever be one system.

> Why do I think this should be in core?
> - Normally this task is done with gpio that is already in regulator-
> core.
> - Because that is already there I added the functionality for enabled-
> by-clock-functionality.
> - I thought of creating a new regulator-clock driver but that would
> hold a lot of code duplication from regulator-fixed.

Hopefully not a *lot* of duplication.  The GPIOs are handled in the core
because they're really common and used by many regulator devices, the
same will I hope not be true for clocks.

> Why is this a good Idea at all?
> - Well I'm here for the software part and should just support our
> hardware. If that is a good Idea at all I don't know, for sure it is
> not a solution that is from some school-book. But I tried it and
> measured it out and it seems to work pretty fine.
> - The reason behind all of that is limited GPIO availability from the
> iMX6ULL.

I guess my question here is what the trip through the regulator API buys
us - it's a bit of a sledgehammer to crack a nut thing.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]