Hi Geert,
On Monday 04 August 2014 13:28:32 Geert Uytterhoeven wrote:
> On Wed, Jul 30, 2014 at 2:06 AM, Laurent Pinchart wrote:
> > The third option would require storing the clocks lists in device drivers.
> > I believe this is our best option, as a trade-off between simplicity and
> > versatility. Drivers that use runtime PM already need to enable it
> > explicitly when probing devices. Passing a list of clock names to runtime
> > PM at that point wouldn't complicate drivers much. When the clocks list
> > isn't SoC- dependent it could be stored as static information. Otherwise
> > it could be derived from DT (or any other source of hardware description)
> > using C code, offering all the versatility we need.
> >
> > The only drawback of this solution I can think of right now is that the
> > runtime PM core couldn't manage device clocks before probing the device.
> > Specifically device clocks couldn't be managed if no driver is loaded for
> > that device. I somehow recall that someone raised this as being a
> > problem, but I can't remember why.
>
> Perhaps you're thinking of clocks that were enabled (by the boot loader or
> implicit reset state) before running Linux, and aren't disabled?
That wasn't the reason, I know that clk_disable_unused() takes care of that
problem (provided the clock drivers behave correctly, the commit you mention
below shows that's not always the case, but that's an unrelated issue).
> That was fixed by commit bb178da701382a230e26d90cf94e8a24b280e0d9
> ("clk: shmobile: mstp: Fix the is_enabled() operation").
--
Regards,
Laurent Pinchart
--
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
