On Tue, 2019-08-06 at 19:26 +0100, Mark Brown wrote: > 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.
Yes, I think so too. > > > > 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. Okay, thanks for discussion! I will try to make something that will fit in mainline kernel and I will learn more about the regulator subsystem in general so I can make a solution that fits. But I'll need some time to do that. I will for sure link to that discussion when I send the patch. Philippe