From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Courbot Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences Date: Wed, 21 Nov 2012 19:00:32 +0900 Message-ID: <4275468.QAmZy3xUK6@percival> References: <1353149747-31871-1-git-send-email-acourbot@nvidia.com> <1699753.ZQsWMHINxd@percival> <50AC956D.7020303@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: <50AC956D.7020303@ti.com> Sender: linux-kernel-owner@vger.kernel.org To: Tomi Valkeinen Cc: Anton Vorontsov , Stephen Warren , Thierry Reding , Mark Zhang , Grant Likely , Rob Herring , Mark Brown , David Woodhouse , Arnd Bergmann , "linux-tegra@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , "devicetree-discuss@lists.ozlabs.org" , "linux-pm@vger.kernel.org" , Alexandre Courbot List-Id: linux-tegra@vger.kernel.org On Wednesday 21 November 2012 16:48:45 Tomi Valkeinen wrote: > If the power-off sequence disables a regulator that was supposed to be > enabled by the power-on sequence (but wasn't enabled because of an > error), the regulator_disable is still called when the driver runs the > power-off sequence, isn't it? Regulator enables and disables are ref > counted, and the enables should match the disables. And there collapses my theory. > > Failures might be better handled if sequences have some "recovery policy" > > about what to do when they fail, as mentioned in the link above. As you > > pointed out, the driver might not always know enough about the resources > > involved to do the right thing. > > Yes, I think such recovery policy would be needed. Indeed, from your last paragraph this makes even more sense now. Oh, and I noticed I forgot to reply to this: > This I didn't understand. Doesn't "<&pwm 2 xyz>" point to a single > device, no matter where and how many times it's used? That's true - however when dereferencing the phandle, the underlying framework will try to acquire the PWM, which will result in failure if the same resource is referenced several times. One could compare the phandles to avoid this, but in your example you must know that for PWMs the "xyz" part is not relevant for comparison. This makes referencing of resources by name much easier to implement and more elegant with respect to frameworks leveraging. Alex. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754298Ab2KUKAp (ORCPT ); Wed, 21 Nov 2012 05:00:45 -0500 Received: from hqemgate03.nvidia.com ([216.228.121.140]:10762 "EHLO hqemgate03.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754255Ab2KUKAk (ORCPT ); Wed, 21 Nov 2012 05:00:40 -0500 X-PGP-Universal: processed; by hqnvupgp06.nvidia.com on Wed, 21 Nov 2012 02:00:34 -0800 From: Alex Courbot To: Tomi Valkeinen CC: Anton Vorontsov , Stephen Warren , Thierry Reding , Mark Zhang , Grant Likely , Rob Herring , Mark Brown , David Woodhouse , Arnd Bergmann , "linux-tegra@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , "devicetree-discuss@lists.ozlabs.org" , "linux-pm@vger.kernel.org" , Alexandre Courbot Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences Date: Wed, 21 Nov 2012 19:00:32 +0900 Message-ID: <4275468.QAmZy3xUK6@percival> Organization: NVIDIA User-Agent: KMail/4.9.3 (Linux/3.6.6-1-ARCH; KDE/4.9.3; x86_64; ; ) In-Reply-To: <50AC956D.7020303@ti.com> References: <1353149747-31871-1-git-send-email-acourbot@nvidia.com> <1699753.ZQsWMHINxd@percival> <50AC956D.7020303@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 21 November 2012 16:48:45 Tomi Valkeinen wrote: > If the power-off sequence disables a regulator that was supposed to be > enabled by the power-on sequence (but wasn't enabled because of an > error), the regulator_disable is still called when the driver runs the > power-off sequence, isn't it? Regulator enables and disables are ref > counted, and the enables should match the disables. And there collapses my theory. > > Failures might be better handled if sequences have some "recovery policy" > > about what to do when they fail, as mentioned in the link above. As you > > pointed out, the driver might not always know enough about the resources > > involved to do the right thing. > > Yes, I think such recovery policy would be needed. Indeed, from your last paragraph this makes even more sense now. Oh, and I noticed I forgot to reply to this: > This I didn't understand. Doesn't "<&pwm 2 xyz>" point to a single > device, no matter where and how many times it's used? That's true - however when dereferencing the phandle, the underlying framework will try to acquire the PWM, which will result in failure if the same resource is referenced several times. One could compare the phandles to avoid this, but in your example you must know that for PWMs the "xyz" part is not relevant for comparison. This makes referencing of resources by name much easier to implement and more elegant with respect to frameworks leveraging. Alex. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Courbot Date: Wed, 21 Nov 2012 10:00:32 +0000 Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences Message-Id: <4275468.QAmZy3xUK6@percival> List-Id: References: <1353149747-31871-1-git-send-email-acourbot@nvidia.com> <1699753.ZQsWMHINxd@percival> <50AC956D.7020303@ti.com> In-Reply-To: <50AC956D.7020303@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On Wednesday 21 November 2012 16:48:45 Tomi Valkeinen wrote: > If the power-off sequence disables a regulator that was supposed to be > enabled by the power-on sequence (but wasn't enabled because of an > error), the regulator_disable is still called when the driver runs the > power-off sequence, isn't it? Regulator enables and disables are ref > counted, and the enables should match the disables. And there collapses my theory. > > Failures might be better handled if sequences have some "recovery policy" > > about what to do when they fail, as mentioned in the link above. As you > > pointed out, the driver might not always know enough about the resources > > involved to do the right thing. > > Yes, I think such recovery policy would be needed. Indeed, from your last paragraph this makes even more sense now. Oh, and I noticed I forgot to reply to this: > This I didn't understand. Doesn't "<&pwm 2 xyz>" point to a single > device, no matter where and how many times it's used? That's true - however when dereferencing the phandle, the underlying framework will try to acquire the PWM, which will result in failure if the same resource is referenced several times. One could compare the phandles to avoid this, but in your example you must know that for PWMs the "xyz" part is not relevant for comparison. This makes referencing of resources by name much easier to implement and more elegant with respect to frameworks leveraging. Alex. From mboxrd@z Thu Jan 1 00:00:00 1970 From: acourbot@nvidia.com (Alex Courbot) Date: Wed, 21 Nov 2012 19:00:32 +0900 Subject: [PATCHv9 1/3] Runtime Interpreted Power Sequences In-Reply-To: <50AC956D.7020303@ti.com> References: <1353149747-31871-1-git-send-email-acourbot@nvidia.com> <1699753.ZQsWMHINxd@percival> <50AC956D.7020303@ti.com> Message-ID: <4275468.QAmZy3xUK6@percival> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wednesday 21 November 2012 16:48:45 Tomi Valkeinen wrote: > If the power-off sequence disables a regulator that was supposed to be > enabled by the power-on sequence (but wasn't enabled because of an > error), the regulator_disable is still called when the driver runs the > power-off sequence, isn't it? Regulator enables and disables are ref > counted, and the enables should match the disables. And there collapses my theory. > > Failures might be better handled if sequences have some "recovery policy" > > about what to do when they fail, as mentioned in the link above. As you > > pointed out, the driver might not always know enough about the resources > > involved to do the right thing. > > Yes, I think such recovery policy would be needed. Indeed, from your last paragraph this makes even more sense now. Oh, and I noticed I forgot to reply to this: > This I didn't understand. Doesn't "<&pwm 2 xyz>" point to a single > device, no matter where and how many times it's used? That's true - however when dereferencing the phandle, the underlying framework will try to acquire the PWM, which will result in failure if the same resource is referenced several times. One could compare the phandles to avoid this, but in your example you must know that for PWMs the "xyz" part is not relevant for comparison. This makes referencing of resources by name much easier to implement and more elegant with respect to frameworks leveraging. Alex.