OMAP baseline test results for v3.7-rc1

[Jean Pihet]

On Tue, Oct 30, 2012 at 9:17 AM, Paul Walmsley <paul at pwsan.com> wrote:
> On Tue, 30 Oct 2012, Felipe Balbi wrote:
>
>> On Tue, Oct 30, 2012 at 12:50:52PM +0000, Paul Walmsley wrote:
>> > certainly PM-idle related, given that the problem goes away by reverting
>> > Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc "ARM: OMAP: convert
>> > I2C driver to PM QoS for MPU latency constraints".
>> >
>> > The problem is consistent and easy to reproduce here.
>>
>> I don't doubt that :-) What I think, however, is that PM QoS just made
I dont doubt either but cannot have it reproduced.

>> the problem a bit easier to trigger for whatever reason. Maybe because
>> pm qos defers constraint updates, or something similar ?
PM QoS just influences the cpuidle decision on the next power state of
the CPU and CORE power domains.

>
> Based on a very quick look, I'd say the original patch 3db11fe is broken.
> I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is
> honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for
> omap2plus_defconfig.
Withtout CPU_IDLE set the PM QoS has no influence on the power domains states.

>
>
> - Paul

Jean