Re: [PATCH] ARM: shmobile: compile drivers/sh for CONFIG_ARCH_SHMOBILE_MULTI

[Mark Brown <broonie@kernel.org>]

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

On Sun, Jan 19, 2014 at 10:44:53PM +0100, Laurent Pinchart wrote:
> On Thursday 16 January 2014 17:25:09 Ben Dooks wrote:

> > I was having a think, and how about adding the following to each
> > driver that expects clock management to happen for it, such as the
> > following in the probe sequence:

> > 	pm_runtime_manage_clock(dev);

> > This would mean the following:

> > - People would know a driver had its clock managed elsewhere
> > - You couldn't build a system with the clock_ops disabled.
> > - A system where a mix of drivers where used would work fine
> > - drivers/sh/pm_runtime.c could be deleted too.

> That sounds like a good idea to me. I like how drivers will be responsible for 
> explicitly delegating clock handling to generic code. This combines simplicity 
> with flexibility, and doesn't hide clock handling.

> Mark, Rafael, any opinion ?

I think that just makes things more complicated and isn't adding
anything over pm_runtime_enable(), it's just boilerplate code.  In
theory essentially every driver running on platforms which don't have
explicit management of core IP clocks ought to be calling this since
potentially the IP might be deployed on another platform which does have
clock management (this does actually happen with things like the
DesignWare IPs) and it doesn't do anything like say which clocks are
expected to be managed in this way which is another thing that can come
up when moving devices between platforms.

I'm also struggling to see how it provides any sort of build time
protection, it would allow the generation of a warning at runtime at
best.

As far as I can tell the problem that Ben has seen here is that the
platform really, really needs the code for its power domains running to
be functional (this doesn't seem unreasonable and may not be related to
clocks, this may be required to have the IPs powered up at all).  I'd
expect this is something for the platform to sort out rather than
something for individual drivers to have to carry code for.

If it was going to be drivers carrying code for this I would expect it
to be something like providing a list of clocks to be managed along with
runtime PM - this would also make the code more widely applicable since
it's quite common for the runtime PM callbacks to do nothing more than
just enable and disable clocks.

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