Hi Lee,
On Wed, Feb 18, 2015 at 10:54 PM, Lee Jones <lee.jones@xxxxxxxxxx> wrote:
>> >> > +Some hardware is contains bunches of clocks which must never be
>> >> > +turned off. If drivers a) fail to obtain a reference to any of
>> >> > +these or b) give up a previously obtained reference during suspend,
>> >> > +the common clk framework will attempt to disable them and the
>> >> > +hardware can fail irrecoverably. Usually, the only way to recover
>> >> > +from these failures is to restart.
>> >>
>> >> How is (b) not a bug?
>> >
>> > Clocks are normally disabled during suspend. When clocks are disabled
>> > they give up their reference. If references reach 0, the clock is
>> > gated. If one of these clocks is gated, the system will never come
>> > out of suspend.
>> >
>> > How is it a bug?
>>
>> It a clock needs to be enabled during suspend, then the driver using
>> it should not disable it. Anyway, suspend is a bit orthogonal to this
>> issue.
>
> IMO, it's not the driver's responsibility to know which clock they are
> using and whether it's a critical clock or not.
So it's (partly) a platform/bus issue.
>> >> While I think we need something here, I worry that this will be abused
>> >> to be a list of clocks you have not gotten around to managing. We
>> >
>> > You can say that about any framework. It's our responsibility to ask
>> > the right questions and to disallow it from being abused. The clocks
>> > I use in the (real-world) example in this set are _really_ always-on.
>> > If any of them are turned off the system will cease to perform in any
>> > meaningful way.
>>
>> You cannot tell here up front whether clocks are really always-on. A
>> reviewer is not going to know, and the submitter may not even have all
>> the documentation and know the answer. Getting it wrong here means you
>> have to change the dtb to fix it. Granted, it doesn't really break
>> things in this case.
>
> We should make it clear in the documentation that this framework
> should only be used if the clock is a critical "if it's turned off it
> will cripple the system" one.
[...]
> I think the kernel's policy is a good one i.e. wait until all devices
> are probed and have had the opportunity to take the clocks they need,
> at which point we can usually safely gate the remainder. These types
> of clocks are the exception however; hence the need for this driver.
> There are other vendors which have similar issues with their h/w.
> These are currently using bespoke versions of this implementation, but
> IMO a generic solution would be better.
What kind of clocks are these? What do they control?
Memory controllers? Bus controllers?
They must control some device(s), so there should be one or more device
nodes in DT that reference these clocks.
As soon as that information is in DT, support can be added to Linux to
make sure the "critical" clocks stay enabled, either through a real driver,
or through platform code.
>> Does simple-pm-bus help you?
>
> I have no idea what this is, and I'm struggling to grep for it too?
Rob already provided a pointer.
If you have more questions, feel free to ask!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
