Messages in this thread | | | Date | Tue, 6 Aug 2019 19:26:06 +0100 | From | Mark Brown <> | Subject | Re: [RFC PATCH 1/2] Regulator: Core: Add clock-enable to fixed-regulator |
| |
On Tue, Aug 06, 2019 at 12:57:32PM +0000, Philippe Schenker wrote: > On Mon, 2019-08-05 at 17:37 +0100, Mark Brown wrote:
> > So the capacitor on the input of the p-FET is keeping the switch on? > > When I say it's not switching with the clock I mean it's not constantly > > bouncing on and off at whatever rate the clock is going at.
> Ah, that's what you mean. Yes, the capacitor gets slowly charged with > the > resistor but nearly instantly discharged with the n-FET. So this > capacitor > is used as a Low-Pass filter to get the p-FET to be constantly switched.
> It is not bouncing on and off with the clock but rather it is switched > constantly.
Good, I guess this might be part of why it's got this poor ramp time.
> > I think you are going to end up with a hack no matter what.
> That's exactly what I'm trying to prevent. To introduce a fixed > regulator that can have a clock is not a hack for me. > That the hardware solution is a hack is debatable yes, but why should I > not try to solve it properly in software?
A lot of this discussion is around the definition of terms like "hack" and "proper".
> In the end I just want to represent our hardware in software. Would you > agree to create a new clock-regulator.c driver? > Or would it make more sense to extend fixed.c to support clocks-enable > without touching core?
At least a separate compatible makes sense, I'd have to see the code to be clear if a completely separate driver makes sense but it'll need separate ops at least. There'd definitely be a lot of overlap though so it's worth looking at. [unhandled content-type:application/pgp-signature] | |