From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753381AbdK2SP4 (ORCPT ); Wed, 29 Nov 2017 13:15:56 -0500 Received: from mail-wm0-f41.google.com ([74.125.82.41]:38777 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752586AbdK2SPs (ORCPT ); Wed, 29 Nov 2017 13:15:48 -0500 X-Google-Smtp-Source: AGs4zMYz9iMbYG4Jz6X0126Vkml3lVgHDbsBP9gA4EdXWpJ04Cr/EuEY6H+H68VOXuZH/Hzro9Qh2w== Subject: Re: [PATCH v2 1/2] pinctrl: Allow a device to indicate when to force a state To: Tony Lindgren Cc: linux-gpio@vger.kernel.org, Linus Walleij , Rob Herring , Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list , ckeepax@opensource.cirrus.com, ckeepax@opensource.wolfsonmicro.com, swarren@nvidia.com, andy.shevchenko@gmail.com, alcooperx@gmail.com, bcm-kernel-feedback-list@broadcom.com References: <20171102231551.16220-1-f.fainelli@gmail.com> <20171102231551.16220-2-f.fainelli@gmail.com> <20171129170102.GH28152@atomide.com> <20171129174500.GJ28152@atomide.com> From: Florian Fainelli Message-ID: Date: Wed, 29 Nov 2017 10:15:41 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20171129174500.GJ28152@atomide.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/29/2017 09:45 AM, Tony Lindgren wrote: > * Florian Fainelli [171129 17:37]: >> On 11/29/2017 09:01 AM, Tony Lindgren wrote: >>> * Florian Fainelli [171102 23:18]: >>>> It may happen that a device needs to force applying a state, e.g: >>>> because it only defines one state of pin states (default) but loses >>>> power/register contents when entering low power modes. Add a >>>> pinctrl_dev::flags bitmask to help describe future quirks and define >>>> PINCTRL_FLG_FORCE_STATE as such a settable flag. >>> >>> It makes sense to tag the existing state with the context loss >>> information as otherwise we'll be duplicating the state in the >>> pinctrl driver potentially for hundreds of pins. >>> >>> Maybe this patch description should clarify that it's the >>> pinctrl device restoring the pin state, not the pinctrl >>> consumer devices? >>> >>> So maybe just "a pinctrl device needs to force apply a state" >>> instead of just device above? >> >> It's a bit more involved than that, the pinctrl consumer device might >> want to restore a particular state by calling pinctrl_select_state(), >> however, because of the (p->state == state)check, the pinctrl provider >> driver has no chance of making that call do the actual HW programming. > > Hmm but isn't it the pinctrl provider device losing context here? It is the pinctrl provider indeed. > I think the restore of the pin state should somehow happen automatically > by the pinctrl provider driver without a need for the pinctrl consumer > drivers to do anything. Correct. > > Or what's the use case for pinctrl consumer driver wanting to store > a pin? I actually meant that a consumer driver could aalso call pinctrl_select_state() in one of its resume callback for instance, but if the pinctrl provider driver does nothing (or rather the core, on behalf of the provider), this would be an issue. This was not super clear, so I will stop using that example from now on :) -- Florian