Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754751AbbGCILx (ORCPT ); Fri, 3 Jul 2015 04:11:53 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:35877 "EHLO mail-wg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754746AbbGCILf (ORCPT ); Fri, 3 Jul 2015 04:11:35 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Tomeu Vizoso Date: Fri, 3 Jul 2015 10:11:14 +0200 X-Google-Sender-Auth: 7WiP3OCNg1z4FqtQIDFY1ALkeRE Message-ID: Subject: Re: [PATCH v3 2/2] PM / Runtime: Add pm_runtime_enable_recursive To: Alan Stern Cc: "linux-pm@vger.kernel.org" , Laurent Pinchart , Dmitry Torokhov , "Rafael J. Wysocki" , Len Brown , Pavel Machek , Greg Kroah-Hartman , Ulf Hansson , Kevin Hilman , Russell King , Krzysztof Kozlowski , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3078 Lines: 77 On 2 July 2015 at 17:21, Alan Stern wrote: > On Thu, 2 Jul 2015, Tomeu Vizoso wrote: > >> > Just because these sub-devices are virtual, it doesn't mean you can >> > ignore the way they interact with runtime PM. >> >> Fair enough, but then, how are we expected to be able to use the >> direct_complete facility if the core bails out if a descendant doesn't >> have runtime PM enabled? >> >> > In the case of ep_87 this doesn't matter. Endpoint devices (like all >> > devices) are in the SUSPENDED state by default when they are created, >> > and they never leave that state. >> >> I don't see why it doesn't matter for endpoints or the others. They >> don't have runtime PM enabled, so no ancestor will be able to do >> direct_complete. > > Ah, you're concerned about these lines near the start of > __device_suspend(): > > if (dev->power.direct_complete) { > if (pm_runtime_status_suspended(dev)) { > pm_runtime_disable(dev); > if (pm_runtime_suspended_if_enabled(dev)) > goto Complete; > > pm_runtime_enable(dev); > } > dev->power.direct_complete = false; > } > > Perhaps the pm_runtime_suspended_if_enabled() test should be changed to > pm_runtime_status_suspended(). Then it won't matter whether the > descendant devices are enabled for runtime PM. Yeah, that would remove the need for messing with the runtime PM enable status of descendant devices, but I wonder why Rafael went that way initially. >> > A possible way around the problem is to use pm_suspend_ignore_children >> > on the uvcvideo interface. But I'm not sure that would be the right >> > thing to do. >> >> Would that mean that if a device has ignore_children then it could >> still do direct_complete even if its descendants weren't able to? > > I think we could justify that. The ignore_children flag means we can > communicate with the children even when the device is in runtime > suspend, so there's no reason to force the device to leave runtime > suspend during a system sleep. IIUIC, what you are proposing is to use ignore_children in a way similar to how force_direct_complete was used in this patch? http://thread.gmane.org/gmane.linux.power-management.general/60198/focus=60292 That should work as well, but Rafael raised some objections and thus I went with the present direct_complete_default, which should work if we can relax the check as discussed above. Thanks, Tomeu > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/