On 08/24/12 12:04, Jean Pihet wrote:
> Hi Timo,
>
> On Fri, Aug 24, 2012 at 10:14 AM, Timo Kokkonen
> wrote:
>> Hi Jean,
>>
>> On 08/23/12 14:58, Jean Pihet wrote:
>>> Hi Timo,
>>>
>>> On Wed, Aug 22, 2012 at 9:50 PM, Timo Kokkonen
>>> wrote:
>>> That is correct. The API to use is the PM QoS A
Hi Timo,
On Fri, Aug 24, 2012 at 10:14 AM, Timo Kokkonen wrote:
> Hi Jean,
>
> On 08/23/12 14:58, Jean Pihet wrote:
>> Hi Timo,
>>
>> On Wed, Aug 22, 2012 at 9:50 PM, Timo Kokkonen
>> wrote:
>> That is correct. The API to use is the PM QoS API which cpuidle uses
>> to determine the next MPU sta
Hi Jean,
On 08/23/12 14:58, Jean Pihet wrote:
> Hi Timo,
>
> On Wed, Aug 22, 2012 at 9:50 PM, Timo Kokkonen wrote:
> That is correct. The API to use is the PM QoS API which cpuidle uses
> to determine the next MPU state based on the allowed latency.
>
>> A more appropriate fix for the problem w
Hi Timo,
On Wed, Aug 22, 2012 at 9:50 PM, Timo Kokkonen wrote:
> The ir-rx51 driver calls omap_pm_set_max_mpu_wakeup_lat() in order to
> avoid problems that occur when MPU goes to sleep in the middle of
> sending an IR code. Without such calls it takes ridiculously long for
> the MPU to wake up f
The ir-rx51 driver calls omap_pm_set_max_mpu_wakeup_lat() in order to
avoid problems that occur when MPU goes to sleep in the middle of
sending an IR code. Without such calls it takes ridiculously long for
the MPU to wake up from a sleep, which distorts the IR signal
completely.
However, the actua
