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? -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
