From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C44FC04AAF for ; Tue, 21 May 2019 07:41:47 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F165421783 for ; Tue, 21 May 2019 07:41:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QgzQkmfj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F165421783 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VbX0zzxU5VUtMHbKCX27RAlFDNXuMhocD/+Qb3ApL2E=; b=QgzQkmfjckEiRS4DqPkNU/kMp qn2c1VRs5Gvrjn65bYqY9fy5SNcCszhvKxUBwPfNcRg5A6vWPaMJpvCoqLmPKdwhfXG6MsNMAf4xw nK0K2oKsI9mmk1oxy0vzr8QB5x2EO7h4I2WTVAz5lUPI4eOn8FgtEHvI5r6LtaeUAuV5ax1/0E7ie tCmbGJkYGJS4qVShwIJwHxjR8rkyWiIxNgmokWt0swwN/cY6+T7h6+6DQ7eXQ/PrVJLDIBYBnoQpA 3CFHx1uiuKYcC5slDjPkvPhh5/SXi7JoyqikRg4S/hTbeTO83/1HP86DrqNV9Rg4tjZ0PyJlD1wV3 tPWyNAgcQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hSzP6-0003Fb-0o; Tue, 21 May 2019 07:41:44 +0000 Received: from relay1-d.mail.gandi.net ([217.70.183.193]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hSzP2-0003Ee-F2 for linux-arm-kernel@lists.infradead.org; Tue, 21 May 2019 07:41:42 +0000 X-Originating-IP: 90.88.22.185 Received: from localhost (aaubervilliers-681-1-80-185.w90-88.abo.wanadoo.fr [90.88.22.185]) (Authenticated sender: maxime.ripard@bootlin.com) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 329F5240014; Tue, 21 May 2019 07:41:22 +0000 (UTC) Date: Tue, 21 May 2019 09:41:22 +0200 From: Maxime Ripard To: Frank Lee Subject: Re: [PATCH 2/3] thermal: sun50i: add thermal driver for h6 Message-ID: <20190521074122.syyctwvfsorl45dv@flea> References: <20190512082614.9045-1-tiny.windzz@gmail.com> <20190512082614.9045-3-tiny.windzz@gmail.com> <20190512133930.t5txssl7mou2gljt@flea> <20190512214128.qjyys3vfpwdiacib@core.my.home> <20190516150252.hf4u3bloo37chy6q@flea> <20190517073151.mz6hcmzubk7iqfre@flea> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20180716 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190521_004140_805342_F65BE95A X-CRM114-Status: GOOD ( 19.91 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , catalin.marinas@arm.com, will.deacon@arm.com, bjorn.andersson@linaro.org, marc.w.gonzalez@free.fr, Mauro Carvalho Chehab , paulmck@linux.ibm.com, stefan.wahren@i2se.com, Daniel Lezcano , Chen-Yu Tsai , Jagan Teki , Andy Gross , rui.zhang@intel.com, devicetree@vger.kernel.org, Linux PM , Eduardo Valentin , olof@lixom.net, robh+dt@kernel.org, Jonathan.Cameron@huawei.com, Linux ARM , Greg Kroah-Hartman , Linux Kernel Mailing List , enric.balletbo@collabora.com, David Miller Content-Type: multipart/mixed; boundary="===============6995607121836603688==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============6995607121836603688== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oyv7cdm2vd7as2px" Content-Disposition: inline --oyv7cdm2vd7as2px Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, May 18, 2019 at 01:19:54AM +0800, Frank Lee wrote: > On Fri, May 17, 2019 at 3:32 PM Maxime Ripard = wrote: > > > > On Fri, May 17, 2019 at 02:10:47AM +0800, Frank Lee wrote: > > > > On Sun, May 12, 2019 at 11:41:28PM +0200, Ond=C5=99ej Jirman wrote: > > > > > > > +static int tsens_get_temp(void *data, int *temp) > > > > > > > +{ > > > > > > > + struct tsensor *s =3D data; > > > > > > > + struct tsens_device *tmdev =3D s->tmdev; > > > > > > > + int val; > > > > > > > + > > > > > > > + regmap_read(tmdev->regmap, tmdev->chip->temp_data_base + > > > > > > > + 0x4 * s->id, &val); > > > > > > > + > > > > > > > + if (unlikely(val =3D=3D 0)) > > > > > > > + return -EBUSY; > > > > > > > > > > > > I'm not sure why a val equals to 0 would be associated with EBU= SY? > > > > > > > > > > Thermal zone driver can (will) call get_temp before we got the > > > > > first interrupt and the thermal data. In that case val will be 0. > > > > > > > > > > Resulting in: > > > > > > > > > > (val + offset) * scale =3D (-2794) * -67 =3D 187198 > > > > > > > > > > 187=C2=B0C and immediate shutdown during boot - based on cirtical > > > > > temperature being reached. > > > > > > > > > > Busy here means, get_temp does not yet have data. Thermal zone > > > > > driver just reports any error to dmesg output. > > > > > > > > Ah, that makes sense. > > > > > > > > I guess if we're switching to an interrupt-based driver, then we can > > > > just use a waitqueue, or is get_temp supposed to be atomic? > > > > > > I think get_temp should not be bloacked. > > > > Why not? > > Maybe, I am wrong. I also want to know if we should do this. I guess it really all depends on whether you can sleep or not in get_temps. If you can, then you should wait for the value to be converted and the THS raising an interrupt. If you can't, then we should ask what the thermal frameworks expects in such a case. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --oyv7cdm2vd7as2px Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXOOrogAKCRDj7w1vZxhR xULTAQC1mWNEVwrK+oid9JOzl0rrU7ybLUMo5gBPlvdd1iIu+QEAzEe9pVgCRCN6 Z8AqbAjBGsyR2h/P/5jg1jYC4d/GBQg= =MglJ -----END PGP SIGNATURE----- --oyv7cdm2vd7as2px-- --===============6995607121836603688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============6995607121836603688==--