[{"id":1773559,"web_url":"http://patchwork.ozlabs.org/comment/1773559/","msgid":"<20170922124704.yfu46ak4rypai3vp@localhost.localdomain>","list_archive_url":null,"date":"2017-09-22T12:47:04","subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","submitter":{"id":71911,"url":"http://patchwork.ozlabs.org/api/people/71911/","name":"Charles Keepax","email":"ckeepax@opensource.cirrus.com"},"content":"On Wed, Sep 20, 2017 at 06:04:20PM -0700, Florian Fainelli wrote:\n> It may happen that a device needs to force applying a state, e.g:\n> because it only defines one state of pin states (default) but loses\n> power/register contents when entering low power modes. Add a\n> pinctrl_dev::flags bitmask to help describe future quirks and define\n> PINCTRL_FLG_FORCE_STATE as such a settable flag.\n> \n> Signed-off-by: Florian Fainelli \n> ---\n> drivers/pinctrl/core.c | 15 +++++++++++++++\n> drivers/pinctrl/core.h | 4 ++++\n> 2 files changed, 19 insertions(+)\n> \n> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c\n> index 56fbe4c3e800..c450a97de88f 100644\n> --- a/drivers/pinctrl/core.c\n> +++ b/drivers/pinctrl/core.c\n> @@ -1197,11 +1197,26 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)\n> {\n> \tstruct pinctrl_setting *setting, *setting2;\n> \tstruct pinctrl_state *old_state = p->state;\n> +\tbool force = false;\n> \tint ret;\n> \n> \tif (p->state == state)\n> \t\treturn 0;\n\nI am guessing you probably intended to remove these two lines.\n\n> \n> +\tif (p->state) {\n> +\t\tlist_for_each_entry(setting, &p->state->settings, node) {\n> +\t\t\tif (setting->pctldev->flags & PINCTRL_FLG_FORCE_STATE)\n> +\t\t\t\tforce = true;\n> +\t\t}\n> +\t}\n> +\n> +\t/* Some controllers may want to force this operation when they define\n> +\t * only one set of functions and lose power state, e.g: pinctrl-single\n> +\t * with its pinctrl-single,low-power-state-loss property.\n> +\t */\n> +\tif (p->state == state && !force)\n> +\t\treturn 0;\n> +\n\nThanks,\nCharles\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ppops.net;\n\tspf=none smtp.mailfrom=ckeepax@opensource.cirrus.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzCtT6X74z9sPk\n\tfor ;\n\tFri, 22 Sep 2017 22:47:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752326AbdIVMrR (ORCPT\n\t);\n\tFri, 22 Sep 2017 08:47:17 -0400","from mx0a-001ae601.pphosted.com ([67.231.149.25]:54646 \"EHLO\n\tmx0b-001ae601.pphosted.com\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1752290AbdIVMrQ (ORCPT\n\t); Fri, 22 Sep 2017 08:47:16 -0400","from pps.filterd (m0077473.ppops.net [127.0.0.1])\n\tby mx0a-001ae601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8MCimwv027622; Fri, 22 Sep 2017 07:47:06 -0500","from mail4.cirrus.com ([87.246.98.35])\n\tby mx0a-001ae601.pphosted.com with ESMTP id 2d11c1rgcj-1;\n\tFri, 22 Sep 2017 07:47:06 -0500","from EX17.ad.cirrus.com (unknown [172.20.9.81])\n\tby mail4.cirrus.com (Postfix) with ESMTP id A5E106125201;\n\tFri, 22 Sep 2017 07:47:04 -0500 (CDT)","from imbe.wolfsonmicro.main (198.61.95.81) by EX17.ad.cirrus.com\n\t(172.20.9.81) with Microsoft SMTP Server id 14.3.301.0;\n\tFri, 22 Sep 2017 13:47:05 +0100","from localhost.localdomain (algalon.ad.cirrus.com [198.90.223.36])\n\tby imbe.wolfsonmicro.main (8.14.4/8.14.4) with ESMTP id\n\tv8MCl44H022237; Fri, 22 Sep 2017 13:47:04 +0100"],"Date":"Fri, 22 Sep 2017 13:47:04 +0100","From":"Charles Keepax ","To":"Florian Fainelli ","CC":", ,\n\t, ,\n\t, ,\n\t, ,\n\t, ","Subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","Message-ID":"<20170922124704.yfu46ak4rypai3vp@localhost.localdomain>","References":"<20170921010421.7467-1-f.fainelli@gmail.com>\n\t<20170921010421.7467-2-f.fainelli@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Disposition":"inline","In-Reply-To":"<20170921010421.7467-2-f.fainelli@gmail.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","X-Proofpoint-Spam-Details":"rule=notspam policy=default score=0\n\tpriorityscore=1501 malwarescore=0\n\tsuspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011\n\tlowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam\n\tadjust=0\n\treason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709220178","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1773587,"web_url":"http://patchwork.ozlabs.org/comment/1773587/","msgid":"<20170922132011.wssbhnsggteffgte@localhost.localdomain>","list_archive_url":null,"date":"2017-09-22T13:20:11","subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","submitter":{"id":71911,"url":"http://patchwork.ozlabs.org/api/people/71911/","name":"Charles Keepax","email":"ckeepax@opensource.cirrus.com"},"content":"On Fri, Sep 22, 2017 at 01:55:22PM +0200, Linus Walleij wrote:\n> On Thu, Sep 21, 2017 at 3:04 AM, Florian Fainelli wrote:\n> \n> > It may happen that a device needs to force applying a state, e.g:\n> > because it only defines one state of pin states (default) but loses\n> > power/register contents when entering low power modes. Add a\n> > pinctrl_dev::flags bitmask to help describe future quirks and define\n> > PINCTRL_FLG_FORCE_STATE as such a settable flag.\n> >\n\nIs the intention here to have this as a hint to the driver that\nit needs to restore the state, or as something the core will act\nupon and restore the state for you?\n\n> > Signed-off-by: Florian Fainelli \n> \n> But I'm uncertain about the design.\n> \n> A while back, I applied this patch to the GPIO subsystem:\n> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/gpio/machine.h?id=05f479bf7d239f01ff6546f2bdeb14ad0fe65601\n> \n> commit 05f479bf7d239f01ff6546f2bdeb14ad0fe65601\n> Author: Charles Keepax \n> Date: Tue May 23 15:47:29 2017 +0100\n> \n> gpio: Add new flags to control sleep status of GPIOs\n> \n> Add new flags to allow users to specify that they are not concerned with\n> the status of GPIOs whilst in a sleep/low power state.\n> \n> Signed-off-by: Charles Keepax \n> Acked-by: Rob Herring \n> Signed-off-by: Linus Walleij \n> \n> diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h\n> index c0d712d22b07..13adadf53c09 100644\n> --- a/include/linux/gpio/machine.h\n> +++ b/include/linux/gpio/machine.h\n> @@ -9,6 +9,8 @@ enum gpio_lookup_flags {\n> GPIO_ACTIVE_LOW = (1 << 0),\n> GPIO_OPEN_DRAIN = (1 << 1),\n> GPIO_OPEN_SOURCE = (1 << 2),\n> + GPIO_SLEEP_MAINTAIN_VALUE = (0 << 3),\n> + GPIO_SLEEP_MAY_LOOSE_VALUE = (1 << 3),\n> };\n> \n> Charles is also working on pin control and will probably have some\n> input on design.\n> \n> Maybe we could do the same: a flag to maintain the value and\n> a flag to allow it to be lost across suspend/resume, which is the\n> core issue here.\n> \n> Your case is analogous to GPIO_SLEEP_MAY_LOOSE_VALUE\n> and you restore the state when you come back from sleep.\n\nI am not sure these are strictly analogous, my patch is about\nthe consumer of the GPIO specifying if it can tolerate the state\nbeing dropped whilst in suspend. Whereas this patch appears to be\nconcerned with whether the state of the controller needs restored\non resume.\n\nI guess in our case we didn't really consider the restore aspect\nbecause we essentially get that for free from regmap. Regmap\ncache's all our register state and provides a mechanism to sync\nthat back to the hardware, so we simply invoke that on resume and\nall our GPIO/pinctrl state is restored.\n\n> Next point, this commit from Baolin:\n> \n> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt?id=6606bc9dee63ad8cda2cc310d2ad5992673a785a\n> \n> output-low - set the pin to output mode with low level\n> output-high - set the pin to output mode with high level\n> +sleep-hardware-state - indicate this is sleep related state which\n> will be programmed\n> + into the registers for the sleep state.\n> slew-rate - set the slew rate\n> \n> This is another thing: here we are defining a state that will be managed\n> by autonomous hardware. The state settings will be poked into some\n> special registers that will automatically take effect when the system\n> goes into sleep.\n> \n> This is a hardware-induced state: the SLEEP line for the entire SoC\n> is asserted.\n> \n\nJust to make sure I understand this property is used to specify a\npinctrl state that will be automatically applied by the hardware when\nentering suspend? Kind of an odd one, feels like something you\ncould just have the software apply as part of the suspend\nprocess. Almost would have wondered should this be a driver\nspecific binding rather than a generic pinctrl one?\n\nI guess from looking at the driver using this I assume that said\nhardware also automatically replies the non-sleep settings on\nresume?\n\n> What you want is something different: a flag like:\n> \n> sleep-restore-state - indicate that this state needs to be restored after sleep\n> as the hardware loose states when sleeping.\n> \n> The driver could look for this in a more granular per-state manner, instead\n> of all states of the pin controller being restored, we mark what\n> states need to be restored on the way up after sleep.\n> \n> What are your thoughts about this?\n> \n> I do not rule out a global flag for the whole controller, it is just a bit\n> confusing if we start to have per-state, per-pin and per-controller\n> sleep behaviour. If we have to have this we have to, but I want to\n> fully understand the problem first.\n> \n> Yours,\n> Linus Walleij\n\nThanks,\nCharles\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ppops.net;\n\tspf=none smtp.mailfrom=ckeepax@opensource.cirrus.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzDcZ6sGgz9sPm\n\tfor ;\n\tFri, 22 Sep 2017 23:20:30 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752052AbdIVNU2 (ORCPT\n\t);\n\tFri, 22 Sep 2017 09:20:28 -0400","from mx0a-001ae601.pphosted.com ([67.231.149.25]:57316 \"EHLO\n\tmx0b-001ae601.pphosted.com\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1751923AbdIVNU1 (ORCPT\n\t); Fri, 22 Sep 2017 09:20:27 -0400","from pps.filterd (m0077473.ppops.net [127.0.0.1])\n\tby mx0a-001ae601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8MDJ4gB015248; Fri, 22 Sep 2017 08:20:13 -0500","from mail1.cirrus.com (mail1.cirrus.com [141.131.3.20])\n\tby mx0a-001ae601.pphosted.com with ESMTP id 2d11c1rnc3-1;\n\tFri, 22 Sep 2017 08:20:13 -0500","from EX17.ad.cirrus.com (unknown [172.20.9.81])\n\tby mail1.cirrus.com (Postfix) with ESMTP id 5C00B612A760;\n\tFri, 22 Sep 2017 08:20:12 -0500 (CDT)","from imbe.wolfsonmicro.main (198.61.95.81) by EX17.ad.cirrus.com\n\t(172.20.9.81) with Microsoft SMTP Server id 14.3.301.0;\n\tFri, 22 Sep 2017 14:20:11 +0100","from localhost.localdomain (algalon.ad.cirrus.com [198.90.223.36])\n\tby imbe.wolfsonmicro.main (8.14.4/8.14.4) with ESMTP id\n\tv8MDKBLW028845; Fri, 22 Sep 2017 14:20:11 +0100"],"Date":"Fri, 22 Sep 2017 14:20:11 +0100","From":"Charles Keepax ","To":"Linus Walleij ","CC":"Florian Fainelli ,\n\text Tony Lindgren ,\n\tCharles Keepax ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tStephen Warren ,\n\tAndy Shevchenko ,\n\tAl Cooper ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ,\n\tbcm-kernel-feedback-list ","Subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","Message-ID":"<20170922132011.wssbhnsggteffgte@localhost.localdomain>","References":"<20170921010421.7467-1-f.fainelli@gmail.com>\n\t<20170921010421.7467-2-f.fainelli@gmail.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170113 (1.7.2)","X-Proofpoint-Spam-Details":"rule=notspam policy=default score=0\n\tpriorityscore=1501 malwarescore=0\n\tsuspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011\n\tlowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam\n\tadjust=0\n\treason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709220186","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1773614,"web_url":"http://patchwork.ozlabs.org/comment/1773614/","msgid":"","list_archive_url":null,"date":"2017-09-22T13:57:16","subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","submitter":{"id":7055,"url":"http://patchwork.ozlabs.org/api/people/7055/","name":"Linus Walleij","email":"linus.walleij@linaro.org"},"content":"On Fri, Sep 22, 2017 at 3:20 PM, Charles Keepax\n wrote:\n> On Fri, Sep 22, 2017 at 01:55:22PM +0200, Linus Walleij wrote:\n\n>> Next point, this commit from Baolin:\n>>\n>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt?id=6606bc9dee63ad8cda2cc310d2ad5992673a785a\n>>\n>> output-low - set the pin to output mode with low level\n>> output-high - set the pin to output mode with high level\n>> +sleep-hardware-state - indicate this is sleep related state which\n>> will be programmed\n>> + into the registers for the sleep state.\n>> slew-rate - set the slew rate\n>>\n>> This is another thing: here we are defining a state that will be managed\n>> by autonomous hardware. The state settings will be poked into some\n>> special registers that will automatically take effect when the system\n>> goes into sleep.\n>>\n>> This is a hardware-induced state: the SLEEP line for the entire SoC\n>> is asserted.\n>>\n>\n> Just to make sure I understand this property is used to specify a\n> pinctrl state that will be automatically applied by the hardware when\n> entering suspend?\n\nYes. It is quite common in SoCs, we just never supported it properly.\n\n> Kind of an odd one, feels like something you\n> could just have the software apply as part of the suspend\n> process.\n\nNot really. It has special registers just for this purpose,\nand the driver is completely unaware that sleep is happening,\ninstead it is driven to the hardware by special hardware sleep\nlines inside the SoC. So it needs to be set up when the default\nstate is programmed.\n\n> Almost would have wondered should this be a driver\n> specific binding rather than a generic pinctrl one?\n\nNo, I've seen it in several hardwares. (The Nomadik pin controller\nhas this too.)\n\n> I guess from looking at the driver using this I assume that said\n> hardware also automatically replies the non-sleep settings on\n> resume?\n\nYep.\n\nYours,\nLinus Walleij\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"FHGQ5aWc\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzFRJ42THz9t16\n\tfor ;\n\tFri, 22 Sep 2017 23:57:32 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752078AbdIVN5T (ORCPT\n\t);\n\tFri, 22 Sep 2017 09:57:19 -0400","from mail-it0-f48.google.com ([209.85.214.48]:56438 \"EHLO\n\tmail-it0-f48.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752061AbdIVN5R (ORCPT\n\t); Fri, 22 Sep 2017 09:57:17 -0400","by mail-it0-f48.google.com with SMTP id g18so1363040itg.5\n\tfor ;\n\tFri, 22 Sep 2017 06:57:17 -0700 (PDT)","by 10.79.164.78 with HTTP; Fri, 22 Sep 2017 06:57:16 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=chSqeipDL8/v2008nIWpIWuE1nMn886DTMLkzD5nxiY=;\n\tb=FHGQ5aWc9zIZs3YfaEHKWGlZZcTCL6iFMdPXUCG8GJvYq7floYx5h2oTdkKZLWbKsM\n\tVadMKotsoS7rtd99ETraL2eABEq9trjzz0na+EjSbpbDZ5HY99owMdgXhUw7430CzRHJ\n\tb2AsSbMzhQtgpKIhHQE4PTdCXu2644jjvQxbg=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=chSqeipDL8/v2008nIWpIWuE1nMn886DTMLkzD5nxiY=;\n\tb=l97wr3x3pMAN/8YNzxstjHI9qgbxBaKmvfJGXcR9o76gKmJrO+21AUm0ToLztvKCqM\n\t5Hx6OuOBxBtnrOA0nAGZ/puY63zFsHo0Z5xwX7g3ux5RghrexkkUV0evoY93GQ9mXZpX\n\tpXpWTZjQQCu8q1BwqkbRS37UzVshfYmf8RFdzDm9N3IkCNOAvsOtXAKmiIYr8J6BD4db\n\tiY72QYZe8h7+rA2gW994AT6s61TCWlfBmragR/txT6IYaZZvra9ODQQjet7volcAoDtH\n\tBuMi/4GDemkcWONYfsfBL862XcCzfPGYfbkQq5kuuA1E9mHUz3QJyc7NF+ioEuW8QRrg\n\t/EZw==","X-Gm-Message-State":"AHPjjUg+6ZnFRUPOHVSSoZpvewSB9a92gDicZELpKoSw+CFpsCbTGdnl\n\ts6G4Pn6bQp2gAIbaBJCC4cmkeA58na+Ly0T2vD1iZQ==","X-Google-Smtp-Source":"AOwi7QDmalQ2B1eGVaAl+QEIFVnqJjEgTAy5d23qygrISr8tEKtfiifmFbr7i4K0EEKaJKAjv5FYpWynUaXv/N8uY/A=","X-Received":"by 10.36.182.78 with SMTP id d14mr7021421itj.74.1506088636977;\n\tFri, 22 Sep 2017 06:57:16 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170922132011.wssbhnsggteffgte@localhost.localdomain>","References":"<20170921010421.7467-1-f.fainelli@gmail.com>\n\t<20170921010421.7467-2-f.fainelli@gmail.com>\n\t\n\t<20170922132011.wssbhnsggteffgte@localhost.localdomain>","From":"Linus Walleij ","Date":"Fri, 22 Sep 2017 15:57:16 +0200","Message-ID":"","Subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","To":"Charles Keepax ","Cc":"Florian Fainelli ,\n\text Tony Lindgren ,\n\tCharles Keepax ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tStephen Warren ,\n\tAndy Shevchenko ,\n\tAl Cooper ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ,\n\tbcm-kernel-feedback-list ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1773758,"web_url":"http://patchwork.ozlabs.org/comment/1773758/","msgid":"","list_archive_url":null,"date":"2017-09-22T16:45:48","subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 09/22/2017 05:47 AM, Charles Keepax wrote:\n> On Wed, Sep 20, 2017 at 06:04:20PM -0700, Florian Fainelli wrote:\n>> It may happen that a device needs to force applying a state, e.g:\n>> because it only defines one state of pin states (default) but loses\n>> power/register contents when entering low power modes. Add a\n>> pinctrl_dev::flags bitmask to help describe future quirks and define\n>> PINCTRL_FLG_FORCE_STATE as such a settable flag.\n>>\n>> Signed-off-by: Florian Fainelli \n>> ---\n>> drivers/pinctrl/core.c | 15 +++++++++++++++\n>> drivers/pinctrl/core.h | 4 ++++\n>> 2 files changed, 19 insertions(+)\n>>\n>> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c\n>> index 56fbe4c3e800..c450a97de88f 100644\n>> --- a/drivers/pinctrl/core.c\n>> +++ b/drivers/pinctrl/core.c\n>> @@ -1197,11 +1197,26 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)\n>> {\n>> \tstruct pinctrl_setting *setting, *setting2;\n>> \tstruct pinctrl_state *old_state = p->state;\n>> +\tbool force = false;\n>> \tint ret;\n>> \n>> \tif (p->state == state)\n>> \t\treturn 0;\n> \n> I am guessing you probably intended to remove these two lines.\n\nArgh right, I cherry-picked what I done on an earlier kernel version and\nthis resolved to this, thanks for noticing!\n\n> \n>> \n>> +\tif (p->state) {\n>> +\t\tlist_for_each_entry(setting, &p->state->settings, node) {\n>> +\t\t\tif (setting->pctldev->flags & PINCTRL_FLG_FORCE_STATE)\n>> +\t\t\t\tforce = true;\n>> +\t\t}\n>> +\t}\n>> +\n>> +\t/* Some controllers may want to force this operation when they define\n>> +\t * only one set of functions and lose power state, e.g: pinctrl-single\n>> +\t * with its pinctrl-single,low-power-state-loss property.\n>> +\t */\n>> +\tif (p->state == state && !force)\n>> +\t\treturn 0;\n>> +\n> \n> Thanks,\n> Charles\n>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"mRmhm1X3\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzKB832Mkz9ryv\n\tfor ;\n\tSat, 23 Sep 2017 02:46:24 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752276AbdIVQpz (ORCPT\n\t);\n\tFri, 22 Sep 2017 12:45:55 -0400","from mail-qk0-f194.google.com ([209.85.220.194]:36914 \"EHLO\n\tmail-qk0-f194.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752244AbdIVQpx (ORCPT\n\t); Fri, 22 Sep 2017 12:45:53 -0400","by mail-qk0-f194.google.com with SMTP id r66so976445qke.4;\n\tFri, 22 Sep 2017 09:45:53 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\ti39sm199952qte.11.2017.09.22.09.45.49\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 22 Sep 2017 09:45:51 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=0VYRmDPwlgifyFsMvxus06p3Luz+UqsVFVoC2MUZnnQ=;\n\tb=mRmhm1X3hwzmeVkwN4rAwNGcnG4IZgBJwPsgl5XsfHiPF8rI4dKaaAMAxjA4yKtrgo\n\tF49SUfzG4QsN1AjQuGxMDDN42qCZq42DyUu9BOd0FyY8QKE80DWWOpYpTxZRYNHu6jf9\n\tkrCyTfwl//I23wcGAOysWSCznCUtg0eeOLjZrizBFX8T/qzKfO8d4X+yYzloy2rwKJH4\n\tFwynFI6Mc8vSCl7zbRFI8weRD5LkPQIZvcf/0imaTu5fbXzq18vZEjOLWskbIs8gHv04\n\tGFYLcA2+v02OLRLuiuLzZJE6LkzSCytAlnzpFAwH02uU2DFf/w/BVDyF7RfeKi+6ejZa\n\tU8DA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=0VYRmDPwlgifyFsMvxus06p3Luz+UqsVFVoC2MUZnnQ=;\n\tb=f9RGsqV4wS59d83YCH2nXopNmrtk/gkxlgJXeDh02aqR3BrGQfeui1240N2Dq1Ld9+\n\tlX6I1q8Z6FwxEP9ydgXaiFk2odTZxvzppa/jeJiiVP0ZMqlKJlg6rmH4RKA0xDbfPU7O\n\tlJNkBkNmHEaX0zf5OJRQL/BDRdojGue6T9pc8M6l0TIoUzWBy8qNkc2e+d8bz/X2SD7f\n\tzmCENT4ZH6wF9RiXD9870OWXbDbjcSVeCZmK3n4vA/U9515Up0TVT21f+hqQb74g3M+t\n\twXLe10ngoDmVKjcpDmt6q/G4LT5e1Vz/DZnuGpqGXegj+euJYCOcQE8kDPVeQ5Y4k8b/\n\tnifQ==","X-Gm-Message-State":"AHPjjUg9/u/Eg3guqML++SgPUWRylTBBMHkgkygpVxfMymYLePQaTUdv\n\to63/EZsUKvrZUY8fooKRx8I=","X-Google-Smtp-Source":"AOwi7QDlFVf3Q6fvf2HOHezZh2WQaySC0ZtemLO2vIEFK5thw7AUVsx5tq4O3y3fLO8Mk5/3aqAi6g==","X-Received":"by 10.55.212.28 with SMTP id l28mr8294917qki.259.1506098752581; \n\tFri, 22 Sep 2017 09:45:52 -0700 (PDT)","Subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","To":"Charles Keepax ,\n\tFlorian Fainelli ","Cc":"linux-kernel@vger.kernel.org, linus.walleij@linaro.org,\n\tswarren@nvidia.com, andy.shevchenko@gmail.com, alcooperx@gmail.com,\n\tlinux-gpio@vger.kernel.org, devicetree@vger.kernel.org,\n\trobh+dt@kernel.org, mark.rutland@arm.com,\n\tbcm-kernel-feedback-list@broadcom.com","References":"<20170921010421.7467-1-f.fainelli@gmail.com>\n\t<20170921010421.7467-2-f.fainelli@gmail.com>\n\t<20170922124704.yfu46ak4rypai3vp@localhost.localdomain>","From":"Florian Fainelli ","Message-ID":"","Date":"Fri, 22 Sep 2017 09:45:48 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170922124704.yfu46ak4rypai3vp@localhost.localdomain>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1773771,"web_url":"http://patchwork.ozlabs.org/comment/1773771/","msgid":"","list_archive_url":null,"date":"2017-09-22T16:57:22","subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 09/22/2017 06:20 AM, Charles Keepax wrote:\n> On Fri, Sep 22, 2017 at 01:55:22PM +0200, Linus Walleij wrote:\n>> On Thu, Sep 21, 2017 at 3:04 AM, Florian Fainelli wrote:\n>>\n>>> It may happen that a device needs to force applying a state, e.g:\n>>> because it only defines one state of pin states (default) but loses\n>>> power/register contents when entering low power modes. Add a\n>>> pinctrl_dev::flags bitmask to help describe future quirks and define\n>>> PINCTRL_FLG_FORCE_STATE as such a settable flag.\n>>>\n> \n> Is the intention here to have this as a hint to the driver that\n> it needs to restore the state, or as something the core will act\n> upon and restore the state for you?\n\nThe intention here is to tell the pinctrl core code that a pinctrl\nprovider hardware will lose its hardware state upon entering a system\nwide deep sleep. This is mainly because this specific pinctrl provider\nis no an ON/OFF power island that is powered off on suspend, and resumes\nwith its default pin state.\n\n> \n>>> Signed-off-by: Florian Fainelli \n>>\n>> But I'm uncertain about the design.\n>>\n>> A while back, I applied this patch to the GPIO subsystem:\n>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/gpio/machine.h?id=05f479bf7d239f01ff6546f2bdeb14ad0fe65601\n>>\n>> commit 05f479bf7d239f01ff6546f2bdeb14ad0fe65601\n>> Author: Charles Keepax \n>> Date: Tue May 23 15:47:29 2017 +0100\n>>\n>> gpio: Add new flags to control sleep status of GPIOs\n>>\n>> Add new flags to allow users to specify that they are not concerned with\n>> the status of GPIOs whilst in a sleep/low power state.\n>>\n>> Signed-off-by: Charles Keepax \n>> Acked-by: Rob Herring \n>> Signed-off-by: Linus Walleij \n>>\n>> diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h\n>> index c0d712d22b07..13adadf53c09 100644\n>> --- a/include/linux/gpio/machine.h\n>> +++ b/include/linux/gpio/machine.h\n>> @@ -9,6 +9,8 @@ enum gpio_lookup_flags {\n>> GPIO_ACTIVE_LOW = (1 << 0),\n>> GPIO_OPEN_DRAIN = (1 << 1),\n>> GPIO_OPEN_SOURCE = (1 << 2),\n>> + GPIO_SLEEP_MAINTAIN_VALUE = (0 << 3),\n>> + GPIO_SLEEP_MAY_LOOSE_VALUE = (1 << 3),\n>> };\n>>\n>> Charles is also working on pin control and will probably have some\n>> input on design.\n>>\n>> Maybe we could do the same: a flag to maintain the value and\n>> a flag to allow it to be lost across suspend/resume, which is the\n>> core issue here.\n>>\n>> Your case is analogous to GPIO_SLEEP_MAY_LOOSE_VALUE\n>> and you restore the state when you come back from sleep.\n> \n> I am not sure these are strictly analogous, my patch is about\n> the consumer of the GPIO specifying if it can tolerate the state\n> being dropped whilst in suspend. Whereas this patch appears to be\n> concerned with whether the state of the controller needs restored\n> on resume.\n\nYour patch does seem to be tackling a different angle indeed.\n\n> \n> I guess in our case we didn't really consider the restore aspect\n> because we essentially get that for free from regmap. Regmap\n> cache's all our register state and provides a mechanism to sync\n> that back to the hardware, so we simply invoke that on resume and\n> all our GPIO/pinctrl state is restored.\n\nAs you may see, the problem in my case is that the hardware has only onw\npinctrl state: \"default\", and it loses its hardware register contents,\nand because of early check in pinctrl_select_state(), we do nothing (the\nstate has not changed per-se), so we are left with SW thinking we\napplied the \"default\" state again, while in fact we did not.\n\nThe approach taken here was to move this to the core pinctrl code\nbecause this is not something a pinctrl consumer should be aware of,\nwhen it calls pinctrl_select_state(), it should do what it asked for.\n\nI also decided to make this a per-provider property as opposed to a\nper-group property because chances are that the state retention is on a\nper-controller basis, and not per-bank/group, although I may be wrong.\n\n> \n>> Next point, this commit from Baolin:\n>>\n>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt?id=6606bc9dee63ad8cda2cc310d2ad5992673a785a\n>>\n>> output-low - set the pin to output mode with low level\n>> output-high - set the pin to output mode with high level\n>> +sleep-hardware-state - indicate this is sleep related state which\n>> will be programmed\n>> + into the registers for the sleep state.\n>> slew-rate - set the slew rate\n>>\n>> This is another thing: here we are defining a state that will be managed\n>> by autonomous hardware. The state settings will be poked into some\n>> special registers that will automatically take effect when the system\n>> goes into sleep.\n>>\n>> This is a hardware-induced state: the SLEEP line for the entire SoC\n>> is asserted.\n>>\n> \n> Just to make sure I understand this property is used to specify a\n> pinctrl state that will be automatically applied by the hardware when\n> entering suspend? Kind of an odd one, feels like something you\n> could just have the software apply as part of the suspend\n> process. Almost would have wondered should this be a driver\n> specific binding rather than a generic pinctrl one?\n> \n> I guess from looking at the driver using this I assume that said\n> hardware also automatically replies the non-sleep settings on\n> resume?\n> \n>> What you want is something different: a flag like:\n>>\n>> sleep-restore-state - indicate that this state needs to be restored after sleep\n>> as the hardware loose states when sleeping.\n>>\n>> The driver could look for this in a more granular per-state manner, instead\n>> of all states of the pin controller being restored, we mark what\n>> states need to be restored on the way up after sleep.\n>>\n>> What are your thoughts about this?\n>>\n>> I do not rule out a global flag for the whole controller, it is just a bit\n>> confusing if we start to have per-state, per-pin and per-controller\n>> sleep behaviour. If we have to have this we have to, but I want to\n>> fully understand the problem first.\n>>\n>> Yours,\n>> Linus Walleij\n> \n> Thanks,\n> Charles\n>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"oAyKmYwC\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzKQz6HCzz9t3Z\n\tfor ;\n\tSat, 23 Sep 2017 02:57:31 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752323AbdIVQ53 (ORCPT\n\t);\n\tFri, 22 Sep 2017 12:57:29 -0400","from mail-qk0-f196.google.com ([209.85.220.196]:38500 \"EHLO\n\tmail-qk0-f196.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752261AbdIVQ51 (ORCPT\n\t); Fri, 22 Sep 2017 12:57:27 -0400","by mail-qk0-f196.google.com with SMTP id c69so994693qke.5;\n\tFri, 22 Sep 2017 09:57:27 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\tu51sm198711qth.67.2017.09.22.09.57.24\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 22 Sep 2017 09:57:25 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=iQzvJvCmW3C+VaEju5MFRt1/M72+7aUc0wxiYZSp/Iw=;\n\tb=oAyKmYwC6eQqqEzIXGparW9kEEasHXpxhM3x3OL6WHsnOagMKzMs2n8ZnMMrW59K+2\n\tdttU/LM+mIH1sQsj9edflNeJDnkbM0T4oYaSIeqVK37y9UvHfuSO/3j7VBkDEK1aFL8S\n\tgEJXdGmv/nfPW4MBXrdbSymLCtPg85le022dMouGswP/QOsXvR/06AN0VE6dDm26nMlu\n\tG7b/xyYIJ2o5UUM3+tDKk2JA8lAVc7lq+ho1RU3qdHsnlY2VROZOlrzywqm8Op7mlnE0\n\taFKi8WZiDQ5NNBHaphipJTYF/gew1IZKcvr3roY66z5mwjthFKfRcfP1wXfq1/7hiS4x\n\t/E5Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=iQzvJvCmW3C+VaEju5MFRt1/M72+7aUc0wxiYZSp/Iw=;\n\tb=KLabnv1bE402Xrof7DB7sYWqFDK0KQmGS4TRl10Wp8WlioHK9939p4sQgxjXVfM5nm\n\tdnV2ok96jOlo0AWZ076MSDn2aFDrPWVgSmF0ZZUit52bZOqY2EtNSJfsDm4VoGWmgf5w\n\tIj5tP11hn6PpP601RFLx1wuEkx8/vBu4R/QEeOrpU8WIXb554DIhc+Qn8JpE5Ojh/5IN\n\tIlNJ3lyh2NAI4hWFYb0Ukjck90BFd1sNviDmGdlR8Jz/YqEA02gvLOqwP27lha4+noH0\n\txOCkRA/GG4VYsrpz+IoAdHDtR+FfbfTrcHM1NmAgbj5PuM9gWelpFf9Q6A+AIaJFJr9b\n\tYXUw==","X-Gm-Message-State":"AHPjjUj2iF90eNh21qr9vDRLuH8/Tkph3ZQp0fRm4FWHwVg2bAIWBSl0\n\tf0YQS+JboutjeHQomnQP57yv/PZo","X-Google-Smtp-Source":"AOwi7QBe/qFodUtn4qLlNevmJdBVLqaUt9s9M+dB4FiExSNXGMhR3V04r3Z/TaJYozV+XAvuJ2O+ZQ==","X-Received":"by 10.55.163.195 with SMTP id m186mr8890630qke.304.1506099446658;\n\tFri, 22 Sep 2017 09:57:26 -0700 (PDT)","Subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","To":"Charles Keepax ,\n\tLinus Walleij ","Cc":"Florian Fainelli ,\n\text Tony Lindgren ,\n\tCharles Keepax ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tStephen Warren ,\n\tAndy Shevchenko ,\n\tAl Cooper ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ,\n\tbcm-kernel-feedback-list ","References":"<20170921010421.7467-1-f.fainelli@gmail.com>\n\t<20170921010421.7467-2-f.fainelli@gmail.com>\n\t\n\t<20170922132011.wssbhnsggteffgte@localhost.localdomain>","From":"Florian Fainelli ","Message-ID":"","Date":"Fri, 22 Sep 2017 09:57:22 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170922132011.wssbhnsggteffgte@localhost.localdomain>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1774937,"web_url":"http://patchwork.ozlabs.org/comment/1774937/","msgid":"","list_archive_url":null,"date":"2017-09-25T19:18:46","subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 09/22/2017 06:57 AM, Linus Walleij wrote:\n> On Fri, Sep 22, 2017 at 3:20 PM, Charles Keepax\n> wrote:\n>> On Fri, Sep 22, 2017 at 01:55:22PM +0200, Linus Walleij wrote:\n> \n>>> Next point, this commit from Baolin:\n>>>\n>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt?id=6606bc9dee63ad8cda2cc310d2ad5992673a785a\n>>>\n>>> output-low - set the pin to output mode with low level\n>>> output-high - set the pin to output mode with high level\n>>> +sleep-hardware-state - indicate this is sleep related state which\n>>> will be programmed\n>>> + into the registers for the sleep state.\n>>> slew-rate - set the slew rate\n>>>\n>>> This is another thing: here we are defining a state that will be managed\n>>> by autonomous hardware. The state settings will be poked into some\n>>> special registers that will automatically take effect when the system\n>>> goes into sleep.\n>>>\n>>> This is a hardware-induced state: the SLEEP line for the entire SoC\n>>> is asserted.\n>>>\n>>\n>> Just to make sure I understand this property is used to specify a\n>> pinctrl state that will be automatically applied by the hardware when\n>> entering suspend?\n> \n> Yes. It is quite common in SoCs, we just never supported it properly.\n\nThis appears to be solving another possible problem/feature with pin\ncontrollers during suspend, which is not exactly what I am after here.\n\nUnless we generalize this into a state of some kind, which would\nde-facto force a state transition in pinctrl_select_state() because\np->default != state, then I am not sure this how that is related to the\nproblem space exposed earlier.\n\n> \n>> Kind of an odd one, feels like something you\n>> could just have the software apply as part of the suspend\n>> process.\n> \n> Not really. It has special registers just for this purpose,\n> and the driver is completely unaware that sleep is happening,\n> instead it is driven to the hardware by special hardware sleep\n> lines inside the SoC. So it needs to be set up when the default\n> state is programmed.\n> \n>> Almost would have wondered should this be a driver\n>> specific binding rather than a generic pinctrl one?\n> \n> No, I've seen it in several hardwares. (The Nomadik pin controller\n> has this too.)\n> \n>> I guess from looking at the driver using this I assume that said\n>> hardware also automatically replies the non-sleep settings on\n>> resume?\n> \n> Yep.\n> \n> Yours,\n> Linus Walleij\n>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"iHZDHJkM\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1DQr1pfpz9sPk\n\tfor ;\n\tTue, 26 Sep 2017 05:19:00 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S935944AbdIYTS4 (ORCPT );\n\tMon, 25 Sep 2017 15:18:56 -0400","from mail-qt0-f194.google.com ([209.85.216.194]:34455 \"EHLO\n\tmail-qt0-f194.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S935491AbdIYTSz (ORCPT\n\t); Mon, 25 Sep 2017 15:18:55 -0400","by mail-qt0-f194.google.com with SMTP id q8so5634267qtb.1;\n\tMon, 25 Sep 2017 12:18:54 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\tb27sm5421379qtc.78.2017.09.25.12.18.48\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 25 Sep 2017 12:18:53 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=62C3DH7HLs6C9it4rTfTWutN8qV+CBDmXUc3M5hw220=;\n\tb=iHZDHJkMMRuTZyRDZvPbPr69RYPA9kEUu9rhyEB50QcJi7eJde8rkXTZ7zZ/RZ4EiE\n\tDmJGJuW17kzzVCG2PZ5NgmpnIRTQtSaJooyRBzXmd8fWy+q9Lr4TKSdukh2mGvrkgYhl\n\tTcJn0WTnglZYQ+cpCzuo2sQ4XR5QM1qCZGwQGcwPFKqgDpD72E7RAZ8QD12/7lew+0wK\n\tS45RQAJzbrfJhOeUtLGDXt4xkVs/lXbyCCYQ3YniFuSHebLvNXH/CpzseucxvZ9vCNtf\n\tkkaxh9BDN3G362O/oaFeZJEN1fJf1vXUW2Z0VEZ42rceUOpW9iqfZnpiI8JIYWwDkEUv\n\ttl4Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=62C3DH7HLs6C9it4rTfTWutN8qV+CBDmXUc3M5hw220=;\n\tb=j0BbAz29pB/1ai6/iY1zHNlbTYTZ2wOldsy0S7fLFdvGbLJ/TykFl+DogdeonRaPYm\n\tbqzrWzkCee2G+ZANHmynd4/nvd98pVR9gob/o6mTuuV9nOiAPROC6A2kgQ7eZmhjhoNk\n\tTiBHs+W+mm9E0XHn5xarRVQvGqCykZMFFMYEzNc5ductxbyJZKkTLe4Htr9KNzV6i6S2\n\tRC/bl+/OA9Z1DVBkSmKieiNkFrQpM1dB14kh+C7usHS9wX9xLiW94jyBRZhqP4ni+PDS\n\tG4pzyhfg4zV3gO2RPJbiyO2CM49BTUIw1CuQydBuBDWEdtVNfSgyMVlhextR8X8+QZ/5\n\tIwcQ==","X-Gm-Message-State":"AHPjjUgyt+YJGtzAg5plICJ21r73CoqPvtqyA7vCLBzxsNuWgkiRswoR\n\t+BGGT8lN3BjE8LPHA3KdSFo=","X-Google-Smtp-Source":"AOwi7QA6aw7bSj7XekPTyKPDBHQLFdEni9n1T0HW3+NlqVCBkPEg/BLWlETegUDSul5T8XLMCyMe+g==","X-Received":"by 10.200.27.6 with SMTP id y6mr12745271qtj.247.1506367134462;\n\tMon, 25 Sep 2017 12:18:54 -0700 (PDT)","Subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","To":"Linus Walleij ,\n\tCharles Keepax ","Cc":"Florian Fainelli ,\n\text Tony Lindgren ,\n\tCharles Keepax ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tStephen Warren ,\n\tAndy Shevchenko ,\n\tAl Cooper ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ,\n\tbcm-kernel-feedback-list ","References":"<20170921010421.7467-1-f.fainelli@gmail.com>\n\t<20170921010421.7467-2-f.fainelli@gmail.com>\n\t\n\t<20170922132011.wssbhnsggteffgte@localhost.localdomain>\n\t","From":"Florian Fainelli ","Message-ID":"","Date":"Mon, 25 Sep 2017 12:18:46 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1775568,"web_url":"http://patchwork.ozlabs.org/comment/1775568/","msgid":"<20170926141628.h27hcrujzhxu4sph@localhost.localdomain>","list_archive_url":null,"date":"2017-09-26T14:16:28","subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","submitter":{"id":71911,"url":"http://patchwork.ozlabs.org/api/people/71911/","name":"Charles Keepax","email":"ckeepax@opensource.cirrus.com"},"content":"On Fri, Sep 22, 2017 at 09:57:22AM -0700, Florian Fainelli wrote:\n> On 09/22/2017 06:20 AM, Charles Keepax wrote:\n> > On Fri, Sep 22, 2017 at 01:55:22PM +0200, Linus Walleij wrote:\n> >> On Thu, Sep 21, 2017 at 3:04 AM, Florian Fainelli wrote:\n> > I guess in our case we didn't really consider the restore aspect\n> > because we essentially get that for free from regmap. Regmap\n> > cache's all our register state and provides a mechanism to sync\n> > that back to the hardware, so we simply invoke that on resume and\n> > all our GPIO/pinctrl state is restored.\n> \n> As you may see, the problem in my case is that the hardware has only onw\n> pinctrl state: \"default\", and it loses its hardware register contents,\n> and because of early check in pinctrl_select_state(), we do nothing (the\n> state has not changed per-se), so we are left with SW thinking we\n> applied the \"default\" state again, while in fact we did not.\n> \n\nThat is exactly the situation we have on the CODECs when they go\ninto runtime suspend, power is removed, and everything is back at\ndefaults when we resume. Just in our case we re-apply the state\nas part of the CODEC resume using a regmap sync.\n\n> The approach taken here was to move this to the core pinctrl code\n> because this is not something a pinctrl consumer should be aware of,\n> when it calls pinctrl_select_state(), it should do what it asked for.\n> \n\nApologies if I have missed something here, but does the consumer\nnot still to some extent need to be aware with this solution\nsince it needs to re-request the pin state in resume?\n\nI think that is really my only reservation here, is it feels\nlike this should be something that is purely implemented on the\nprovider, and be invisible to the consumer, and I am not clear\nthis is.\n\n> I also decided to make this a per-provider property as opposed to a\n> per-group property because chances are that the state retention is on a\n> per-controller basis, and not per-bank/group, although I may be wrong.\n> \n\nIt seems quite likely that this property would mostly be\nper-provider to me as well.\n\nThanks,\nCharles\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ppops.net;\n\tspf=none smtp.mailfrom=ckeepax@opensource.cirrus.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1jgg08hrz9t3B\n\tfor ;\n\tWed, 27 Sep 2017 00:16:47 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S966844AbdIZOQo (ORCPT );\n\tTue, 26 Sep 2017 10:16:44 -0400","from mx0b-001ae601.pphosted.com ([67.231.152.168]:47134 \"EHLO\n\tmx0b-001ae601.pphosted.com\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S965237AbdIZOQn (ORCPT\n\t); Tue, 26 Sep 2017 10:16:43 -0400","from pps.filterd (m0077474.ppops.net [127.0.0.1])\n\tby mx0b-001ae601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8QE62uL016149; Tue, 26 Sep 2017 09:16:30 -0500","from mail3.cirrus.com ([87.246.76.56])\n\tby mx0b-001ae601.pphosted.com with ESMTP id 2d5m1mrs8y-1;\n\tTue, 26 Sep 2017 09:16:30 -0500","from EX17.ad.cirrus.com (ex17.ad.cirrus.com [172.20.9.81])\n\tby mail3.cirrus.com (Postfix) with ESMTP id 092316121AC0;\n\tTue, 26 Sep 2017 09:19:51 -0500 (CDT)","from imbe.wolfsonmicro.main (198.61.95.81) by EX17.ad.cirrus.com\n\t(172.20.9.81) with Microsoft SMTP Server id 14.3.301.0;\n\tTue, 26 Sep 2017 15:16:29 +0100","from localhost.localdomain (algalon.ad.cirrus.com [198.90.223.36])\n\tby imbe.wolfsonmicro.main (8.14.4/8.14.4) with ESMTP id\n\tv8QEGShA003449; Tue, 26 Sep 2017 15:16:28 +0100"],"Date":"Tue, 26 Sep 2017 15:16:28 +0100","From":"Charles Keepax ","To":"Florian Fainelli ","CC":"Linus Walleij ,\n\text Tony Lindgren ,\n\tCharles Keepax ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tStephen Warren ,\n\tAndy Shevchenko ,\n\tAl Cooper ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ,\n\tbcm-kernel-feedback-list ","Subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","Message-ID":"<20170926141628.h27hcrujzhxu4sph@localhost.localdomain>","References":"<20170921010421.7467-1-f.fainelli@gmail.com>\n\t<20170921010421.7467-2-f.fainelli@gmail.com>\n\t\n\t<20170922132011.wssbhnsggteffgte@localhost.localdomain>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170113 (1.7.2)","X-Proofpoint-Spam-Details":"rule=notspam policy=default score=0\n\tpriorityscore=1501 malwarescore=0\n\tsuspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011\n\tlowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam\n\tadjust=0\n\treason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709260205","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1775747,"web_url":"http://patchwork.ozlabs.org/comment/1775747/","msgid":"<61d19678-e90c-3b3a-099a-81200873edc8@gmail.com>","list_archive_url":null,"date":"2017-09-26T17:51:14","subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 09/26/2017 07:16 AM, Charles Keepax wrote:\n> On Fri, Sep 22, 2017 at 09:57:22AM -0700, Florian Fainelli wrote:\n>> On 09/22/2017 06:20 AM, Charles Keepax wrote:\n>>> On Fri, Sep 22, 2017 at 01:55:22PM +0200, Linus Walleij wrote:\n>>>> On Thu, Sep 21, 2017 at 3:04 AM, Florian Fainelli wrote:\n>>> I guess in our case we didn't really consider the restore aspect\n>>> because we essentially get that for free from regmap. Regmap\n>>> cache's all our register state and provides a mechanism to sync\n>>> that back to the hardware, so we simply invoke that on resume and\n>>> all our GPIO/pinctrl state is restored.\n>>\n>> As you may see, the problem in my case is that the hardware has only onw\n>> pinctrl state: \"default\", and it loses its hardware register contents,\n>> and because of early check in pinctrl_select_state(), we do nothing (the\n>> state has not changed per-se), so we are left with SW thinking we\n>> applied the \"default\" state again, while in fact we did not.\n>>\n> \n> That is exactly the situation we have on the CODECs when they go\n> into runtime suspend, power is removed, and everything is back at\n> defaults when we resume. Just in our case we re-apply the state\n> as part of the CODEC resume using a regmap sync.\n\nDo you just re-apply the previous state, or do you force a \"fake\" state\nby moving to a state different than the current during suspend, just to\nforce a transition during resume?\n\n> \n>> The approach taken here was to move this to the core pinctrl code\n>> because this is not something a pinctrl consumer should be aware of,\n>> when it calls pinctrl_select_state(), it should do what it asked for.\n>>\n> \n> Apologies if I have missed something here, but does the consumer\n> not still to some extent need to be aware with this solution\n> since it needs to re-request the pin state in resume?\n\nConsumers may indeed have to call pinctrl_select_state() but because of\nthe current check that does:\n\nif (p->state == state)\n\nthis is not happening, but you are absolutely right, consumers that wish\nto see their pin state be (re)configured during driver resume absolutely\nneed to tell the core about it, I am not thinking about any of this\nhappening \"under the hood\", this absolutely would not be right.\n\n> \n> I think that is really my only reservation here, is it feels\n> like this should be something that is purely implemented on the\n> provider, and be invisible to the consumer, and I am not clear\n> this is.\n> \n>> I also decided to make this a per-provider property as opposed to a\n>> per-group property because chances are that the state retention is on a\n>> per-controller basis, and not per-bank/group, although I may be wrong.\n>>\n> \n> It seems quite likely that this property would mostly be\n> per-provider to me as well.\n> \n> Thanks,\n> Charles\n>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"dh8eMPb0\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1pSt0Fpwz9tX4\n\tfor ;\n\tWed, 27 Sep 2017 03:52:44 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S967727AbdIZRvX (ORCPT );\n\tTue, 26 Sep 2017 13:51:23 -0400","from mail-qk0-f195.google.com ([209.85.220.195]:33465 \"EHLO\n\tmail-qk0-f195.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S965587AbdIZRvW (ORCPT\n\t); Tue, 26 Sep 2017 13:51:22 -0400","by mail-qk0-f195.google.com with SMTP id g128so7302568qke.0;\n\tTue, 26 Sep 2017 10:51:21 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\tg131sm7117108qkb.15.2017.09.26.10.51.16\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 26 Sep 2017 10:51:20 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=bNO5+fwUzoTmmamSNmqWewK91HOnNtYbpt4tAaYSs58=;\n\tb=dh8eMPb0djnaPvTA7I9cXmbbXkpJb/6bbqB+zWX9jcCFxT5GxI5/RucOOQop9zdhHg\n\tP5gKCRg16xtaJ71+rhW0clenQAPTLgzNeSzeb/d5rNmkJ/Kww1BTHufOITNALO4UDMXw\n\tcTPDDNNkikTe45AedCcfeukn8RXTDIQmLYMwyQmaPAOGT3lrZrjUrv9ohq4zyfofc3XC\n\t726+2JR6HOwpcxebdaYKpr3ip27lZkzm9cOwYCypCryeRO8uWbxrTIobSE0vPu1wEn4Q\n\tHM1hRmypF5ZFIF4U3wAQ/IiZ3hUroXnWHdriuqhWhGYVIK0xQeZ1ulSSCBwLCz5/1gj6\n\tNykA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=bNO5+fwUzoTmmamSNmqWewK91HOnNtYbpt4tAaYSs58=;\n\tb=G9ZWXIJYCrrEHnoRzxBA/b+qQ0EJSnxrLcFFbsPIy9Vw9SApdEOWd7XR93d9+soBCR\n\tbE8Tqj8DSv7vGdyiTV8fJhnL2k4axkxlYdJKOy8d/UNq0qeSa7oSOZdm5ARiXxzPTKQV\n\tsQfdYxFuto8HyfbmPM13HSy1FmX1gebKW+0Msj9ms3DTOA1BqJ5LGPgdfwIAqWW/tnh4\n\tYS+A5NJzON4excmsFxQRHjmasbjj70G691LJSfwjgmohCbcGl0/80p1++XxlMlWKuWQG\n\tx9uHNOm14TdFrFoqFnFcaczhF5k5+04rf2P3Di2UKcXqFHt7isTx1Uk3EMAbFHCGNjJp\n\tPY8g==","X-Gm-Message-State":"AHPjjUh0tZQKuS9UcVeDXlb6r3/CtnSgnJ7tp2LSO1Y1rwj+uUpAH5qS\n\tqLMiNXRepeC9igZJ2/b9y9k=","X-Google-Smtp-Source":"AOwi7QBqCH8pFHwNm1CUUAjbCcgA+xfJFBCQ7HjlOhCbrKh5+REdKKTS7q01EbqzHZmreoyRUCcoFg==","X-Received":"by 10.55.157.87 with SMTP id g84mr16507166qke.70.1506448281179; \n\tTue, 26 Sep 2017 10:51:21 -0700 (PDT)","Subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","To":"Charles Keepax ","Cc":"Linus Walleij ,\n\text Tony Lindgren ,\n\tCharles Keepax ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tStephen Warren ,\n\tAndy Shevchenko ,\n\tAl Cooper ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ,\n\tbcm-kernel-feedback-list ","References":"<20170921010421.7467-1-f.fainelli@gmail.com>\n\t<20170921010421.7467-2-f.fainelli@gmail.com>\n\t\n\t<20170922132011.wssbhnsggteffgte@localhost.localdomain>\n\t\n\t<20170926141628.h27hcrujzhxu4sph@localhost.localdomain>","From":"Florian Fainelli ","Message-ID":"<61d19678-e90c-3b3a-099a-81200873edc8@gmail.com>","Date":"Tue, 26 Sep 2017 10:51:14 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170926141628.h27hcrujzhxu4sph@localhost.localdomain>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1776130,"web_url":"http://patchwork.ozlabs.org/comment/1776130/","msgid":"<20170927082641.cuwuettnwcwofh7k@localhost.localdomain>","list_archive_url":null,"date":"2017-09-27T08:26:41","subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","submitter":{"id":71911,"url":"http://patchwork.ozlabs.org/api/people/71911/","name":"Charles Keepax","email":"ckeepax@opensource.cirrus.com"},"content":"On Tue, Sep 26, 2017 at 10:51:14AM -0700, Florian Fainelli wrote:\n> On 09/26/2017 07:16 AM, Charles Keepax wrote:\n> > On Fri, Sep 22, 2017 at 09:57:22AM -0700, Florian Fainelli wrote:\n> >> On 09/22/2017 06:20 AM, Charles Keepax wrote:\n> >>> On Fri, Sep 22, 2017 at 01:55:22PM +0200, Linus Walleij wrote:\n> >>>> On Thu, Sep 21, 2017 at 3:04 AM, Florian Fainelli wrote:\n> >>> I guess in our case we didn't really consider the restore aspect\n> >>> because we essentially get that for free from regmap. Regmap\n> >>> cache's all our register state and provides a mechanism to sync\n> >>> that back to the hardware, so we simply invoke that on resume and\n> >>> all our GPIO/pinctrl state is restored.\n> >>\n> >> As you may see, the problem in my case is that the hardware has only onw\n> >> pinctrl state: \"default\", and it loses its hardware register contents,\n> >> and because of early check in pinctrl_select_state(), we do nothing (the\n> >> state has not changed per-se), so we are left with SW thinking we\n> >> applied the \"default\" state again, while in fact we did not.\n> >>\n> > \n> > That is exactly the situation we have on the CODECs when they go\n> > into runtime suspend, power is removed, and everything is back at\n> > defaults when we resume. Just in our case we re-apply the state\n> > as part of the CODEC resume using a regmap sync.\n> \n> Do you just re-apply the previous state, or do you force a \"fake\" state\n> by moving to a state different than the current during suspend, just to\n> force a transition during resume?\n> \n\nYes we just reapply the state, I guess the important thing here\nis we arn't doing that through pinctrl we are just returning\nthe registers to the appropriate values (which regmap handily\nprovides) as part of resume.\n\nIt looks like there are other pinctrl drivers also doing this,\nalthough often hardcoding it rather than using regmap. See either\npinctrl-exynos-arm.c or pinctrl-at91-pio4.c\n\n> > \n> >> The approach taken here was to move this to the core pinctrl code\n> >> because this is not something a pinctrl consumer should be aware of,\n> >> when it calls pinctrl_select_state(), it should do what it asked for.\n> >>\n> > \n> > Apologies if I have missed something here, but does the consumer\n> > not still to some extent need to be aware with this solution\n> > since it needs to re-request the pin state in resume?\n> \n> Consumers may indeed have to call pinctrl_select_state() but because of\n> the current check that does:\n> \n> if (p->state == state)\n> \n> this is not happening, but you are absolutely right, consumers that wish\n> to see their pin state be (re)configured during driver resume absolutely\n> need to tell the core about it, I am not thinking about any of this\n> happening \"under the hood\", this absolutely would not be right.\n> \n\nSee that's the bit that is concerning me, shouldn't the default\nposition be you get your pin state reconfigured during resume,\nwithout having to do anything. Anything else seems to violate the\nprinciple of least surprise.\n\nIt also feels to me the provider driver should be handling that,\nrather than expecting the consumer to call pinctrl_select_state\nagain. So for example from the consumer I should be fine just to\ncall pinctrl_select_state in probe and have that state remain\nuntil someone changes it.\n\nThanks,\nCharles\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ppops.net;\n\tspf=none smtp.mailfrom=ckeepax@opensource.cirrus.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2BFl3Vq8z9t3x\n\tfor ;\n\tWed, 27 Sep 2017 18:44:27 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752377AbdI0IoB (ORCPT\n\t);\n\tWed, 27 Sep 2017 04:44:01 -0400","from mx0a-001ae601.pphosted.com ([67.231.149.25]:40482 \"EHLO\n\tmx0b-001ae601.pphosted.com\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1751841AbdI0In7 (ORCPT\n\t); Wed, 27 Sep 2017 04:43:59 -0400","from pps.filterd (m0077473.ppops.net [127.0.0.1])\n\tby mx0a-001ae601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8R8heaG014123; Wed, 27 Sep 2017 03:43:41 -0500","from mail4.cirrus.com ([87.246.98.35])\n\tby mx0a-001ae601.pphosted.com with ESMTP id 2d5n12byyg-1;\n\tWed, 27 Sep 2017 03:43:40 -0500","from EX17.ad.cirrus.com (unknown [172.20.9.81])\n\tby mail4.cirrus.com (Postfix) with ESMTP id C9ABD611CE89;\n\tWed, 27 Sep 2017 03:26:41 -0500 (CDT)","from imbe.wolfsonmicro.main (198.61.95.81) by EX17.ad.cirrus.com\n\t(172.20.9.81) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 27 Sep 2017 09:26:42 +0100","from localhost.localdomain (algalon.ad.cirrus.com [198.90.223.36])\n\tby imbe.wolfsonmicro.main (8.14.4/8.14.4) with ESMTP id\n\tv8R8Qf9w022364; Wed, 27 Sep 2017 09:26:41 +0100"],"Date":"Wed, 27 Sep 2017 09:26:41 +0100","From":"Charles Keepax ","To":"Florian Fainelli ","CC":"Linus Walleij ,\n\text Tony Lindgren ,\n\tCharles Keepax ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tStephen Warren ,\n\tAndy Shevchenko ,\n\tAl Cooper ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ,\n\tbcm-kernel-feedback-list ","Subject":"Re: [PATCH 1/2] pinctrl: Allow a device to indicate when to force a\n\tstate","Message-ID":"<20170927082641.cuwuettnwcwofh7k@localhost.localdomain>","References":"<20170921010421.7467-1-f.fainelli@gmail.com>\n\t<20170921010421.7467-2-f.fainelli@gmail.com>\n\t\n\t<20170922132011.wssbhnsggteffgte@localhost.localdomain>\n\t\n\t<20170926141628.h27hcrujzhxu4sph@localhost.localdomain>\n\t<61d19678-e90c-3b3a-099a-81200873edc8@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Disposition":"inline","In-Reply-To":"<61d19678-e90c-3b3a-099a-81200873edc8@gmail.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","X-Proofpoint-Spam-Details":"rule=notspam policy=default score=0\n\tpriorityscore=1501 malwarescore=0\n\tsuspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015\n\tlowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam\n\tadjust=0\n\treason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709270120","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]