From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755820AbdJJASC (ORCPT ); Mon, 9 Oct 2017 20:18:02 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:43026 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755605AbdJJAR6 (ORCPT ); Mon, 9 Oct 2017 20:17:58 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 2C74D60392 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=fenglinw@codeaurora.org Subject: Re: [PATCH V1] pinctrl: qcom: spmi-gpio: Update GPIO EN_CTL when setting pin config To: Bjorn Andersson Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Walleij , linux-gpio@vger.kernel.org, collinsd@codeaurora.org, aghayal@codeaurora.org, wruan@codeaurora.org, subbaram@codeaurora.org, kgunda@codeaurora.org References: <20170912003331.3092-1-fenglinw@codeaurora.org> <20171005162750.GY1165@minitux> <20171009055643.GB1165@minitux> From: Fenglin Wu Message-ID: <35aec5d7-8808-9930-8d6d-e0399df12a9e@codeaurora.org> Date: Tue, 10 Oct 2017 08:17:52 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171009055643.GB1165@minitux> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/9/2017 1:56 PM, Bjorn Andersson wrote: > On Sun 08 Oct 22:34 PDT 2017, Fenglin Wu wrote: > >> On 10/6/2017 12:27 AM, Bjorn Andersson wrote: >>> On Mon 11 Sep 17:32 PDT 2017, fenglinw@codeaurora.org wrote: >>> >>>> From: Fenglin Wu >>>> >>>> GPIO is expected to be disabled iff PIN_CONFIG_BIAS_HIGH_IMPEDANCE is >>>> configured. Update is_enabled flag in config_set() so that it can >>>> reflect GPIO status correctly. Also modify EN_CTL register based on >>>> is_enabled flag in config_set() to configure the GPIO properly. >>>> >>>> Signed-off-by: Fenglin Wu >>>> --- >>>> drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 5 +++++ >>>> 1 file changed, 5 insertions(+) >>>> >>>> diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c >>>> index c2c0bab..a0edaa8 100644 >>>> --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c >>>> +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c >>>> @@ -453,6 +453,7 @@ static int pmic_gpio_config_set(struct pinctrl_dev *pctldev, unsigned int pin, >>>> pad = pctldev->desc->pins[pin].drv_data; >>>> + pad->is_enabled = true; >>>> for (i = 0; i < nconfs; i++) { >>>> param = pinconf_to_config_param(configs[i]); >>>> arg = pinconf_to_config_argument(configs[i]); >>>> @@ -600,6 +601,10 @@ static int pmic_gpio_config_set(struct pinctrl_dev *pctldev, unsigned int pin, >>>> return ret; >>>> } >>>> + val = pad->is_enabled << PMIC_GPIO_REG_MASTER_EN_SHIFT; >>>> + >>>> + ret = pmic_gpio_write(state, pad, PMIC_GPIO_REG_EN_CTL, val); >>>> + >>> >>> This looks good. >>> >>> Acked-by: Bjorn Andersson >>> >>> >>> But I spotted another issue while reviewing this; currently the initial >>> state of is_enabled is unconditionally set to enabled in >>> pmic_gpio_populate(), so reading the initial pinconf or configuring a >>> pinmux before setting a pinconf will operate on the potentially wrong >>> information. >>> >>> So I think the initial value should be read out from REG_EN_CTL rather >>> than being just "true". >>> >>> Can you please either submit another patch for this? >> >> Hmm, considering a GPIO which is disabled by default in hardware >> setting, what's its expected state if we only define "function" for it? >> I was thinking we need to enable it once it has any setting in pinmux or >> pinconf. If you think that we need to keep its original state until we >> set pinconf for it, yes, I can submit a change to address this. >> > > Are there valid cases where only function should be selected and no > other configuration is used? If so it makes sense to make > pmic_gpio_set_mux() enable the block. > > > Regardless of this, if there are disabled pins that are not mentioned in > DT they will still appear as enabled in the debugfs interface; and this > I consider an error worth fixing. How about we do both: read the HW initial state in pmic_gpio_populate(), and also enable the GPIO block in pmic_gpio_set_mux()? > > Regards, > Bjorn > -- Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.