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.
signature.asc
Description: PGP signature
