From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751588AbbCTHgr (ORCPT ); Fri, 20 Mar 2015 03:36:47 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:20432 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751032AbbCTHgm (ORCPT ); Fri, 20 Mar 2015 03:36:42 -0400 Message-ID: <550BCE34.9010904@hisilicon.com> Date: Fri, 20 Mar 2015 15:37:24 +0800 From: kongxinwei User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mark Rutland CC: "rui.zhuang@intel.com" , "edubezval@gmail.com" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linuxarm@huawei.com" , "devicetree@vger.kernel.org" , "liguozhu@hisilicon.com" , "xuwei5@hisilicon.com" Subject: Re: [PATCH 1/3] thermal: hisilicon: add new hisilicon thermal sensor driver References: <1426751849-10604-1-git-send-email-kong.kongxinwei@hisilicon.com> <1426751849-10604-2-git-send-email-kong.kongxinwei@hisilicon.com> <20150319141753.GB25967@leverpostej> In-Reply-To: <20150319141753.GB25967@leverpostej> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.46.69.178] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.550BCE07.00BF,ss=1,re=0.001,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 530fc539283108e4dff2a3d8745b82fc Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2015/3/19 22:17, Mark Rutland 写道: > On Thu, Mar 19, 2015 at 07:57:27AM +0000, kongxinwei wrote: >> This patch adds the support for hisilicon thermal sensor, within >> hisilicon SoC. there will register sensors for thermal framework >> and use device tree to bind cooling device. >> >> Signed-off-by: Leo Yan >> Signed-off-by: kongxinwei >> --- >> drivers/thermal/Kconfig | 8 + >> drivers/thermal/Makefile | 1 + >> drivers/thermal/hisi_thermal.c | 531 +++++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 540 insertions(+) >> create mode 100644 drivers/thermal/hisi_thermal.c > > [...] > >> + ret = of_property_read_u32(np, "hisilicon,tsensor-lag-value", >> + &sensor->lag); > > This wasn't in the binding. > good comment, delete it. Xinwei > [...] > >> + ret = of_property_read_u32(np, "hisilicon,tsensor-thres-temp", >> + &sensor->thres_temp); >> + if (ret) { >> + dev_err(&pdev->dev, "failed to get thres value %d: %d\n", >> + index, ret); >> + return ret; >> + } >> + >> + ret = of_property_read_u32(np, "hisilicon,tsensor-reset-temp", >> + &sensor->reset_temp); >> + if (ret) { >> + dev_err(&pdev->dev, "failed to get reset value %d: %d\n", >> + index, ret); >> + return ret; >> + } > > I see now that these properties result in the HW being programmed. You > should figure out how to reconcile these with thermal-zone trip points > rather than having parallel properties. > oh,firstly,this "tsensor-thres-temp" property is threshold temperature value which causes interrupt function by setting thermal value register. "thermal -zone trip points" applies scanning mode to cause other function such as cooling freq .., but this "tsensor-thres-temp" property be used by interrupt mode. when scanning mode don't satisfies systerm demands, the interrut mode perfectly help scanning mode to complete function. "tsensor-thres-temp" temp- erature is higher than "thermal-zone trip points" temperature, so this " tsensor-thres-temp" property is secondary attribute. secondly, this "tsensor-reset-temp" property is hardware protect temperature which is close to or is below to burn out the SoC. When SoC temperature is "tsensor-reset-temp" temperature value, SoC will be force to reboot and ensure SoC not to burn out. So it don't conflict thermal-zone. >> + >> + if (of_property_read_bool(np, "hisilicon,tsensor-bind-irq")) { >> + >> + if (data->irq_bind_sensor != -1) >> + dev_warn(&pdev->dev, "irq has bound to index %d\n", >> + data->irq_bind_sensor); >> + >> + /* bind irq to this sensor */ >> + data->irq_bind_sensor = index; >> + } > > I don't see why this should be specified in the DT. Why do you believe > it should? > SoC include foure thermal sensor modules,every modules is able to cause interrupt,so binding a module to realize interupt function and i believe it should be specified. > [...] > >> +static int hisi_thermal_probe(struct platform_device *pdev) >> +{ >> + struct hisi_thermal_data *data; >> + struct resource *res; >> + int i; >> + int ret; >> + >> + if (!cpufreq_get_current_driver()) { >> + dev_dbg(&pdev->dev, "no cpufreq driver!"); >> + return -EPROBE_DEFER; >> + } > > Surely we care about not burning out the board even if we don't have > cpufreq? > > Is there any ordering guarantee between the probing of this driver and > cpufreq? > > Yes! It will use thermal framework to realize cpu cooling device function. > [...] > >> + data->clk = devm_clk_get(&pdev->dev, NULL); > > You gave this clock a name in the binding. Use it or drop it. > Thanks comment,use it. > Mark. > Xinwei > . >