Re: [PATCH V5 0/7] cpufreq: suspend early/resume late: dpm_{suspend|resume}()

[Stephen Warren]

On 02/19/2014 06:50 PM, Linaro wrote:
> 
> 
>> On 20-Feb-2014, at 7:19 am, Linaro <viresh.kumar@xxxxxxxxxx> wrote:
>>
>>
>>
>>>> On 19-Feb-2014, at 10:56 pm, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
>>>>
>>>>> On 02/18/2014 09:15 PM, Viresh Kumar wrote:
>>>>>> On 19-Feb-2014 1:48 AM, "Stephen Warren" <swarren@xxxxxxxxxxxxx> wrote:
>>>>>>
>>>>>>> On 02/17/2014 02:20 AM, Viresh Kumar wrote:
>>>>>>> On 15 February 2014 05:33, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
>>>>>>> On 02/14/2014 03:23 PM, Rafael J. Wysocki wrote:
>>>>>>
>>>>>>>> Well, it would be good to verify which part, then.
>>>>>>>
>>>>>>> Patch 2/7 appears to stop that message from being printed during
>>>>>>> suspend, and perhaps reduce the number of times it's printed during
>>>>>>> resume. Patch 7/7 stops the message being printed at all.
>>>>>>>
>>>>>>> Looking at patch 7, I wonder if it's simply because tegra_target() was
>>>>>>> modified never to return -EBUSY, so the bug is still there, but it's
>>>>>>> just been hidden.
>>>>>>
>>>>>> No, the bug is removed now. Its hidden in current linus/master :)
>>>>>
>>>>> I'm not sure what that means; I still see the message:
>>>>
>>>> I have given a better reply in one of the earlier mails in this thread.
>>>> And skipped a more elaborative reply now.
>>>>
>>>> So this failure was always there since long time, as you disable your
>>>> target() fn early in suspend. But the message wasn't printed earlier.
>>>>
>>>> A recently added core patch started printing this, so not a new bug.
>>>> But this series fixes suspend resume completely and you wouldn't see it
>>>> anymore.
>>>
>>> OK, so I suppose we have two options:
>>>
>>> a) Just ignore the kernel error spew since it's a known issue.
>>>
>>> b) If I make the Tegra driver return 0 rather than -EBUSY, would that
>>> work? It would certainly silence the error. However, I wonder if it
>>> would cause the cpufreq core to get out of sync with HW; the core would
>>> think that it'd set some frequency, which the driver ignored, and if it
>>> later wanted to switch frequency, the call might get skipped because the
>>> core thought the HW was already set to that frequency?
>>
>> Option is the one you need.
> 
> Option a..

Well, except that still leaves a bunch of errors in the kernel log, and
I have to remember to ignore them:-/

It'd be nice if the cpufreq core didn't keep changing its behaviour and
adding new error prints. It really should be up to the cpufreq drivers
to log the errors if they experience any.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/