Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2202653ybi; Sat, 25 May 2019 18:26:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqxm99Z8yqTm5z07uXtWJCK0TnATM7E2Lmn9QxeMbU5dHWFvCjOimbLb77q3rAhkNUJoP7TF X-Received: by 2002:a17:90a:dc86:: with SMTP id j6mr19572215pjv.141.1558833966778; Sat, 25 May 2019 18:26:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558833966; cv=none; d=google.com; s=arc-20160816; b=d05QhKlzG6sTyNsfdyJw8y1qpI60aaevCpT9qfZxtmQmV6G/RmYVE86I6j/UkQ5UtD GF7Gp2MSu/PugUVdUTCl//fYxgl+jLEDf5acmcsaGmALOk0Fc0xkMtTiIHptbRJ59kBx jbtpNyYU/yMMV5FYoXwYkrcgMmEsUaX7w0GfZba0uHAGXkWws1i269+Ro+S5WsohdCM5 w9kzi3nXI3qZqGViY8N1CdSr6GGbiwW+sqlmmm48xNXjK3ldl0AMdVMcPeYf15J2GdJe E4P4rvX4/7NmP7RPRuaIz9PCGT6rAi+utKxOj1jWSihxIIuhvfv7dSkXRqupbb0BRFi9 Mo8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature; bh=6syLoSIiJJwth2wbbn5ybQFZLugxbVmdU+Dea4NN5wE=; b=ILPR42hlaO5yvi0LDOF8Tvy0kqsKxtlO1yXTmBqWbW2Mn0ktHUgXPvswJuV6N/OK1e U1wORWEcJhoMs+V3Cw+/y48fpRFbRiaoktdMNwlrlR27fflK8/v86pGncIyDjN7VNDpI 1+bUNCMpwg+G/62QvuvSKyW2WGFgoMVaSX8fdOQu2qMfGMbVdUDq8//TXyttWscuDslE iW9VPNNioxyCFz1aSuNY38p188fVvSQ4Rr8kwWnkf8bbYo6JpFAEtWrlV11KOQ7Phxyv hNVjHKuCy0Lr0UY8KL6PTwBw865z/iWikaat5A2cTbdc9uFK1K4V+JVCq8zquzBbjOHd nWLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@megous.com header.s=mail header.b="Oxb0w8/z"; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=megous.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s9si10007654pgp.9.2019.05.25.18.25.51; Sat, 25 May 2019 18:26:06 -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; dkim=pass header.i=@megous.com header.s=mail header.b="Oxb0w8/z"; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=megous.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727588AbfEZBYs (ORCPT + 99 others); Sat, 25 May 2019 21:24:48 -0400 Received: from vps.xff.cz ([195.181.215.36]:53546 "EHLO vps.xff.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727474AbfEZBYr (ORCPT ); Sat, 25 May 2019 21:24:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megous.com; s=mail; t=1558833885; bh=vvKWkGbp9K2vIliSPzvDEraQISpPMpRwGfH6Zi4LJd4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Oxb0w8/z/TFyS6ZmcEarY5+TIxaVwuNA6TUXSEQ3SiFSPdI/nMZGijsppYnTUG/M/ lJ2b9JECtdxy4o8UojXPuIIlNXC6gmmHHJ+vdmvGbF86+mefO7jPQKGGlcyjWBodep cXx0Gle207O0oDNP0DPNyf+RzVduWqxpfr9U+FJI= Date: Sun, 26 May 2019 03:24:44 +0200 From: =?utf-8?Q?Ond=C5=99ej?= Jirman To: Frank Lee Cc: rui.zhang@intel.com, Eduardo Valentin , Daniel Lezcano , robh+dt@kernel.org, Mark Rutland , Maxime Ripard , Chen-Yu Tsai , catalin.marinas@arm.com, will.deacon@arm.com, David Miller , Mauro Carvalho Chehab , Greg Kroah-Hartman , Jonathan.Cameron@huawei.com, Nicolas Ferre , paulmck@linux.ibm.com, Andy Gross , olof@lixom.net, bjorn.andersson@linaro.org, Jagan Teki , marc.w.gonzalez@free.fr, stefan.wahren@i2se.com, enric.balletbo@collabora.com, devicetree@vger.kernel.org, Linux Kernel Mailing List , Linux ARM , Linux PM Subject: Re: [PATCH 2/3] thermal: sun50i: add thermal driver for h6 Message-ID: <20190526012444.yrcellg3xdrt3bo5@core.my.home> Mail-Followup-To: Frank Lee , rui.zhang@intel.com, Eduardo Valentin , Daniel Lezcano , robh+dt@kernel.org, Mark Rutland , Maxime Ripard , Chen-Yu Tsai , catalin.marinas@arm.com, will.deacon@arm.com, David Miller , Mauro Carvalho Chehab , Greg Kroah-Hartman , Jonathan.Cameron@huawei.com, Nicolas Ferre , paulmck@linux.ibm.com, Andy Gross , olof@lixom.net, bjorn.andersson@linaro.org, Jagan Teki , marc.w.gonzalez@free.fr, stefan.wahren@i2se.com, enric.balletbo@collabora.com, devicetree@vger.kernel.org, Linux Kernel Mailing List , Linux ARM , Linux PM References: <20190512082614.9045-1-tiny.windzz@gmail.com> <20190512082614.9045-3-tiny.windzz@gmail.com> <20190512221612.ubmknvim4utnqpl4@core.my.home> <20190516182936.h6xdzp3gtg4ikave@core.my.home> <20190519142239.eolisexp5mrdyafz@core.my.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Yangtao, On Sun, May 26, 2019 at 02:48:13AM +0800, Frank Lee wrote: > On Sun, May 19, 2019 at 10:22 PM Ondřej Jirman wrote: > > > > I know, I don't think it needs to be per-soc. These actions are all shared by > > all SoCs. Maybe with an exception that some SoCs may need one more clock, but > > that can be made optionally-required by some flag in struct sunxi_thermal_chip. > > > > Only highly SoC specific thing is configuring the THS registers for sampling > > frequency/averaging/enabling interrupts. The reset/clock enable is generic, and > > already abstracted by the clock/reset framework. > > > > So what I suggest is having: > > > > sunxi_ths_enable() > > reset deassert > > bus clock prepare enable > > optionally module clock prepare enable (in the future) > > call per-soc calibration > > call per-soc setup callback > > > > sunxi_ths_disable() > > reset assert > > bus clock unprepare disable > > optionally module clock unprepare disable > > > > And if you could move devm_nvmem_cell_get to probe that should make per-SoC > > calibration callback also less repetitive and could avoid undoing the enable > > in case it returns EPROBE_DEFER (which is possible). > > > > All this should make it easier to support PM in the future and add less > > cumbersome to add support for A83T and H3/H5. > > > > BTW, what are your plans for more SoC support? I'd like to add support for > > A83T and H3/H5, maybe even during the 5.3 cycle if this driver happens to land > > early enough. If you don't have any plans I'll take it on. > > > > I plan to support h3 and a33 later. > Can you support other platforms? Yes, I can do A83T. H5 is similar (the same?) as H3. thank you and regards, o. > Cheers, > Yangtao > > > thank you and regards, > > o. > > > > > > > > > > thank you and regards, > > > > o. > > > > > > > > > Regards, > > > > > Yangtao > > > > > > _______________________________________________ > > > linux-arm-kernel mailing list > > > linux-arm-kernel@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel