Re: [PATCH 4/6] OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints

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

Hi Kevin,

On Wed, Nov 23, 2011 at 8:43 PM, Kevin Hilman <khilman@xxxxxx> wrote:
> Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> writes:
>> On Thu, Nov 17, 2011 at 10:29 PM, Kevin Hilman <khilman@xxxxxx> wrote:
>>> jean.pihet@xxxxxxxxxxxxxx writes:
>>>> From: Jean Pihet <j-pihet@xxxxxx>
>>>> The MPU latency figures for cpuidle include the MPU itself and also
>>>> the peripherals needed for the MPU to execute instructions (e.g.
>>>> main memory, caches, IRQ controller, MMU etc). On OMAP3 those
>>>> peripherals belong to the MPU and CORE power domains and so the
>>>> cpuidle C-states are a combination of MPU and CORE states.
>>>> This patch implements the relation between the cpuidle and per-
>>>> device PM QoS frameworks in the OMAP3 specific idle callbacks.
>>>> The chosen C-state shall satisfy the following conditions:
>>>>  . the 'valid' field is enabled,
>>>>  . it satisfies the enable_off_mode flag,
>>> Not directly related to this patch, but is there any reason to keep the
>>> 'enable_off_mode' flag after this series?
>> enable_off_mode could be removed completely after this series unless
>> there is a need to prevent OFF mode for debug reasons.
> Great.
> For debug reasons, we can just as easily set constraints to prevent off
> mode, so I would like to see it disappear.
I have a WIP patch that removes the enable_off_mode flag and will post
it as soon as this series is in the upstream pipe.


> Kevin
linux-pm mailing list

[Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Video 4 Linux]     [Linux Resources]     [Free Dating]     [Archives]
Add to Google Powered by Linux