Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp1154216ybm; Wed, 22 May 2019 18:36:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqx4h18m/+Qp9bFq6FVdViDIDMMEezISyzv+Y7Mw0kkQVnjox8W52mSz2AU9FDBrdgSBg3d2 X-Received: by 2002:a17:902:9a9:: with SMTP id 38mr50942319pln.10.1558575377385; Wed, 22 May 2019 18:36:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558575377; cv=none; d=google.com; s=arc-20160816; b=KIywYwMRkHfoLnmZHF+B0QAISy3kLYGldc7AxPI3D2HV2kJYXqE/sOQ06EAN+WoSNt SdZBGdwvmImdxcxTBOR2W1boSfUEvae+iQdT/Y34+vAIMg9EddNGvBFKz2g3Sk8tokti VF2zYhGo9XIFyPkY+/fJ/qQKk1hVQWRqxdc2CtJDdDRXwlA640gXlP6LghT5JtsnDMks hiJiG8PMXyXtY4HTd4DsMYSVng3YBZChV/YBcfST2d4nmfkQ9d2sP7Lry2r9WlTjPdph SvQT7/4VDm/BwR9AAT3T7yp3tHVdaNhMIvl/O27TD1I6OqQMKZio2BLNrUMSGUttg/jO +BdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=MjkFXXDTBYNUCf6SGdC24kqhvRYlJrk42LJ2Ipfqkg0=; b=mblTBkDuwM+cDUJRd5BhwmO+FJ/bIycgxLXTQINW4Z6axelQDgijE0wHE6bSwUejcK PVCWjOnXsyFDjrYhmNHe02WtBnkm+RF13YsbaSIlJlpfA10JGYQpmpWCqCAvq7iNOTBh baUcVKrQnm8pqPSmj2pG0LiDN0Yzq4QI8nFVEuFmyEtkH3yYL8DuCiFASW+jrAJJyWiR rm7E0WOxNFsq/nCzeCICyN5pak1/mf1LYWxV3NvWg96+HHQ4k162N909xJXky+vVM2Bf cNA5RFiZnpAUoGwI6DCfDYr7AkhtfK+EKKJCfbdywDJmnZpeJvj/iUdB1pWjqUduEzaL EOng== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x22si29852038pgj.271.2019.05.22.18.36.02; Wed, 22 May 2019 18:36:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729551AbfEWBey (ORCPT + 99 others); Wed, 22 May 2019 21:34:54 -0400 Received: from regular1.263xmail.com ([211.150.70.200]:44536 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727305AbfEWBex (ORCPT ); Wed, 22 May 2019 21:34:53 -0400 Received: from zhangqing?rock-chips.com (unknown [192.168.167.243]) by regular1.263xmail.com (Postfix) with ESMTP id 3637E32F; Thu, 23 May 2019 09:34:41 +0800 (CST) X-263anti-spam: KSV:0;BIG:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ADDR-CHECKED4: 1 X-ABS-CHECKED: 1 X-SKE-CHECKED: 1 X-ANTISPAM-LEVEL: 2 Received: from [172.16.12.236] (unknown [58.22.7.114]) by smtp.263.net (postfix) whith ESMTP id P9439T139953098970880S1558575278592295_; Thu, 23 May 2019 09:34:40 +0800 (CST) X-IP-DOMAINF: 1 X-UNIQUE-TAG: <0e1d8dc2cb0969a06cf6b0c8eac81de2> X-RL-SENDER: zhangqing@rock-chips.com X-SENDER: zhangqing@rock-chips.com X-LOGIN-NAME: zhangqing@rock-chips.com X-FST-TO: vicencb@gmail.com X-SENDER-IP: 58.22.7.114 X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH v3 1/3] thermal: rockchip: fix up the tsadc pinctrl setting error To: Heiko Stuebner , Enric Balletbo Serra Cc: Daniel Lezcano , Mark Rutland , "devicetree@vger.kernel.org" , huangtao@rock-chips.com, Linux PM list , xxx@rock-chips.com, xf@rock-chips.com, linux-kernel , Eduardo Valentin , "open list:ARM/Rockchip SoC..." , Rob Herring , Zhang Rui , Linux ARM , Doug Anderson , vicencb@gmail.com References: <1556618986-18923-1-git-send-email-zhangqing@rock-chips.com> <785392a0-282a-1e51-a4d6-a6d5ca478949@linaro.org> <2174314.1vfUlvne1O@phil> From: "elaine.zhang" Organization: rockchip Message-ID: Date: Thu, 23 May 2019 09:34:37 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2174314.1vfUlvne1O@phil> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org hi, Heiko & Enric: 在 2019/5/22 下午8:27, Heiko Stuebner 写道: > Hi Enric, > > Am Montag, 20. Mai 2019, 15:38:32 CEST schrieb Enric Balletbo Serra: >> Hi all, >> >> As pointed by [1] and [2] this commit, that now is upstream, breaks >> veyron (rk3288) and kevin (rk3399) boards. The problem is especially >> critical for veyron boards because they don't boot anymore. >> >> I didn't look deep at the problem but I have some concerns about this >> patch, see below. >> >> [1] https://www.spinics.net/lists/linux-rockchip/msg24657.html >> [2] https://www.spinics.net/lists/linux-rockchip/msg24735.html >> >> Missatge de Daniel Lezcano del dia dt., 30 >> d’abr. 2019 a les 15:39: >>> On 30/04/2019 12:09, Elaine Zhang wrote: >>>> Explicitly use the pinctrl to set/unset the right mode >>>> instead of relying on the pinctrl init mode. >>>> And it requires setting the tshut polarity before select pinctrl. >>>> >>>> When the temperature sensor mode is set to 0, it will automatically >>>> reset the board via the Clock-Reset-Unit (CRU) if the over temperature >>>> threshold is reached. However, when the pinctrl initializes, it does a >>>> transition to "otp_out" which may lead the SoC restart all the time. >>>> >>>> "otp_out" IO may be connected to the RESET circuit on the hardware. >>>> If the IO is in the wrong state, it will trigger RESET. >>>> (similar to the effect of pressing the RESET button) >>>> which will cause the soc to restart all the time. >>>> >>>> Signed-off-by: Elaine Zhang >>> Reviewed-by: Daniel Lezcano >>> >>> >>> >>>> --- >>>> drivers/thermal/rockchip_thermal.c | 36 +++++++++++++++++++++++++++++++++--- >>>> 1 file changed, 33 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c >>>> index 9c7643d62ed7..6dc7fc516abf 100644 >>>> --- a/drivers/thermal/rockchip_thermal.c >>>> +++ b/drivers/thermal/rockchip_thermal.c >>>> @@ -172,6 +172,9 @@ struct rockchip_thermal_data { >>>> int tshut_temp; >>>> enum tshut_mode tshut_mode; >>>> enum tshut_polarity tshut_polarity; >>>> + struct pinctrl *pinctrl; >>>> + struct pinctrl_state *gpio_state; >>>> + struct pinctrl_state *otp_state; >>>> }; >>>> >>>> /** >>>> @@ -1242,6 +1245,8 @@ static int rockchip_thermal_probe(struct platform_device *pdev) >>>> return error; >>>> } >>>> >>>> + thermal->chip->control(thermal->regs, false); >>>> + >> That's the line that causes the hang. Commenting this makes the veyron >> boot again. Probably this needs to go after chip->initialize? > It needs to go after the clk_enable calls. > At this point the tsadc may still be unclocked. The clk is enable by default. The reason for this modification: The otp Pin polarity setting for tsadc must be set when tsadc is turned off. The order: Close the tsadc->Set the otp pin polarity ->Set the pinctrl->initialize the tsadc->Open the tsadc As for the problem you mentioned, I guess: The default polarity of otp does not match the default state, that is, the otp is triggered by default, and then the reset circuit of the hardware takes effect and is restarted all the time. Modification: 1. For this hardware, otp pin default state is modified. 2. The mode of using CRU is rockchip,hw-tshut-mode = <0> in DTS; /* tshut mode 0:CRU 1:GPIO */ Recommended use method 2. You can try it. > >>>> error = clk_prepare_enable(thermal->clk); >>>> if (error) { >>>> dev_err(&pdev->dev, "failed to enable converter clock: %d\n", >>>> @@ -1267,6 +1272,30 @@ static int rockchip_thermal_probe(struct platform_device *pdev) >>>> thermal->chip->initialize(thermal->grf, thermal->regs, >>>> thermal->tshut_polarity); >>>> >>>> + if (thermal->tshut_mode == TSHUT_MODE_GPIO) { >>>> + thermal->pinctrl = devm_pinctrl_get(&pdev->dev); >>>> + if (IS_ERR(thermal->pinctrl)) { >>>> + dev_err(&pdev->dev, "failed to find thermal pinctrl\n"); >>>> + return PTR_ERR(thermal->pinctrl); >>>> + } >>>> + >>>> + thermal->gpio_state = pinctrl_lookup_state(thermal->pinctrl, >>>> + "gpio"); >> Shouldn't this mode be documented properly in the binding first? > More importantly, it should be _backwards-compatible_, aka work with > old devicetrees without that property and not break thermal handling for > them entirely. If need  _backwards-compatible_,  It's can't return PTR_ERR(thermal->pinctrl) when get devm_pinctrl_get failed. > >> The binding [3] talks about init, default and sleep states but *not* >> gpio and otpout. The patch series looks incomplete to me or not using >> the proper names. >> >> [3] https://elixir.bootlin.com/linux/v5.2-rc1/source/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt >> >>>> + if (IS_ERR_OR_NULL(thermal->gpio_state)) { >>>> + dev_err(&pdev->dev, "failed to find thermal gpio state\n"); >>>> + return -EINVAL; >>>> + } >>>> + >>>> + thermal->otp_state = pinctrl_lookup_state(thermal->pinctrl, >>>> + "otpout"); >>>> + if (IS_ERR_OR_NULL(thermal->otp_state)) { >>>> + dev_err(&pdev->dev, "failed to find thermal otpout state\n"); >>>> + return -EINVAL; >>>> + } >>>> + >> Same here otpout is not a documented. >> >> As this change is now in mainline and is causing veyron to hang I'd >> suggest reverting this change for now. Even fixing the root cause >> (maybe the one I pointed above) after this patch we will have the >> thermal driver to fail because "gpio" and "otpout" states are not >> defined nor documented (a change on this will need some reviews and >> acks and time I guess). > I definitly agree here. Handling + checking the binding change > as well as needed fallback code is definitly not material for -rc-kernels > so we should just revert for now and let Elaine fix the issues for 5.3. > > Anyone volunteering for sending a revert-patch to Eduardo? :-) I agree to revert the patch,and I will correct it and push it later. Do I need to commit the revert the patch now?@Heiko > > Heiko > > > > > > >