Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
[...]
> > > > > Mike Turquette repeatedly said that he was against such a DT property:
> > > > > https://lkml.org/lkml/2014/5/12/693
> > > > 
> > > > Mike says in that email that he's opposing the addition of a property
> > > > for clocks that is the equivalent of regulator-always-on. That's not
> > > > what this is about. If at all it'd be a property to mark a clock that
> > > > should not be disabled by default because it's essential.
> > > 
> > > It's just semantic. How is "a clock that should not be disabled by
> > > default because it's essential" not a clock that stays always on?
> > 
> > Because a clock that should not be disabled by default can be turned off
> > when appropriate. A clock that is always on can't be turned off.
> 
> If a clock is essential, then it should never be disabled. Or we don't
> share the same meaning of essential.

Essential for the particular use-case.

> > > > But you can work around that for now by making the relevant clocks
> > > > always on and remove that workaround once a real driver is loaded
> > > > that knows how to handle them properly.
> > > 
> > > So, let me get this straight. The clock provider driver should behave
> > > as a clock consumer because it knows that in some cases, it might not
> > > have any willingful enough consumer? Doesn't that even ring your
> > > this-is-a-clear-abstraction-violation-bell just a tiny bit?
> > 
> > No. The clock driver should simply not allow the clocks to be disabled
> > if it isn't safe to do so.
> 
> Again, we do seem to differ on our interpretation of an essential
> clock. To me, it is perfectly safe to disable the clocks. The system
> will still be responding, the memory will be there, the CPU will keep
> running, and we do have a way to recover from that disabled to clock
> (for example to enable it back).
> 
> Plus, again, in Mike's mail, it's clearly said that adding hacks like
> this to the clock driver should only be considered in the case where
> we don't have a consuming driver, which is not our case here.

Well, that depends on what you mean by the consuming driver. simplefb
isn't a traditional driver in that sense. There will eventually, in a
more fully-featured system, be a driver that properly consumes the
clocks. Now, since this is only a temporary measure I think it's one of
the cases where having this encoded in the clock driver would be
appropriate.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]