Re: [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Rafael J. Wysocki" <rjw@xxxxxxxx> writes:

> On Thursday, April 07, 2011, Kevin Hilman wrote:
>> Kevin Hilman <khilman@xxxxxx> writes:
>> 
>> [...]
>> 
>> > Replacing the PM ops for all devices was done on OMAP and SH-mobile
>> > because that was the only approach we had.  Now that we have device
>> > power domains (thanks Rafael!), we can be more selective about which
>> > devices to apply them to.
>> >
>> > Note that my RFC patch/series did not do the selective part of deciding
>> > which devices to override and which ones not to, that part will be
>> > platform specific.  
>> 
>> Actually, thinking about this a little more, my patch actually does
>> select only relevant devices, and not *all* platform devices.
>> 
>> In my patch, the device power domain pointers are only added for devices
>> where a clk_get() actually succeeds.  In the original version, the
>> runtime PM hooks are overridden for *all* platform devices, but ones
>> that have no clock (or where clk_get() failed) have the additional
>> overhead of still calling the custom PM ops, but the custom ops have
>> nothing to do.
>
> As I wrote in another message to Grant, the problem basically is that
> the platform bus type behavior is not the desirable one.  Namely, I don't
> generally want device driver callbacks to be invoked until we know that
> power will be removed from the devices.  

Ah, I didn't know that was a goal.  I totally agree there.

> However, the platform bus type executes driver callbacks automatically
> if they exist.  This currently is unavoidable, because power domain
> callbacks are executed in addition to and not instead the bus type
> callbacks.
>
> We've discussed that a bit at the LF Collab Summit with Grant and Paul and
> the conclusion is that to address this particular problem we'll need to change
> the core so that if there is a power domain for the given device, the
> power domain callbacks will be executed first and if they return a specific
> error code, the core will execute the bus type callbacks.  For devices that
> don't belong to any power domain, the bus type callbacks will be executed
> (which is the current behavior).
>
> I'm going to post a patch along these lines early next week.  Then, we
> can simply move the management of device clocks, the execution of device
> driver callbacks and the power removal into power domain callbacks.

Sounds good to me.

> At that point it may be possible to share some code between shmobile and
> OMAP, but I'm not sure yet how much of the code may be shared and it what
> way exactly.

I'll have a look again after you post your series, but I'm pretty sure
any runtime PM implementation based on basic clock gating could be
shared.  Basically, the idea is in the absence of real power domains, to
create a default "virtual" powerdomain that contains every device with a
clock.  This would capture all on-chip devices into a single power domain.
The device powerdomain callbacks for these would do the basic clock
gating (as is done in mach-shmobile/pm_runtime.c).

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux