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