Message-ID: <20190805163724.GK6432@sirena.org.uk>
Date:   Mon, 5 Aug 2019 17:37:24 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Philippe Schenker <philippe.schenker@...adex.com>
Cc:     "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/2] Regulator: Core: Add clock-enable to
 fixed-regulator

On Mon, Aug 05, 2019 at 11:07:58AM +0000, Philippe Schenker wrote:
> On Wed, 2019-07-31 at 22:23 +0100, Mark Brown wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

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

> No, it doesn't keep it latched. To make things clear here a status table:

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.

> > 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.

> I thought of that too, but the problem with that approach is that I
> can't reflect the actual switching behavior. What would happen is if
> you turnethernet off with 'ip link set eth0 down', the clock would
> stop and therefore no more supply voltage to the PHY. But the ethernet
> driverwould in that case let the regulator enabled preventing,
> switching off the clock.

You could include that in your quirk?

> Anyway I feel that to solve this with a quirk would be a little
> hackish, plus I'd anyway need to mess around with the Ethernet/PHY
> drivers. So why not solve it properly with a regulator that supports
> clocks?

I think you are going to end up with a hack no matter what.

> > 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.

> I agree that they are commonly and widely used. To add support for clocks in
> regulator-core was really easy to do as I did it the same way as it is done with
> gpio's. If I don't need to touch regulator-core I don't want to. But as I said
> it was really easy for me to integrate it in there in a way without even
> understanding the whole regulator API.

> If it makes more sense to do it in a new file like clock-regulator.c and
> creating a new compatible that is what I'm trying to find out here. I'd be happy
> to write also a new clock-regulator driver for that purpose.

It would be better if it wasn't in the core, that keeps everything
partitioned off nicely.

> > 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.

> In my opinion this is not only about to solve my problem with startup-delay. I
> think that this is really a behavior that can be generic. That's also why I'm
> asking here how we want to solve that so not only I solve my little problem with
> a board quirk but in a broader view for possible future usage by others.

> It is possible that a regulator needs a clock. That exactly is, what we have on
> our board and works better than expected (at least by myself :-)).

The majority of regulators that need clocks are PWM devices which is a
whole other thing that we already support.  This is a highly unusual
hardware design, we don't have the regmap stuff in the core and that's a
lot more common.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists