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=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 527C9C5519F for ; Thu, 12 Nov 2020 17:16:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D7A2420759 for ; Thu, 12 Nov 2020 17:16:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="xe2x5M1t" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725999AbgKLRQS (ORCPT ); Thu, 12 Nov 2020 12:16:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:48292 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725972AbgKLRQS (ORCPT ); Thu, 12 Nov 2020 12:16:18 -0500 Received: from localhost (fw-tnat.cambridge.arm.com [217.140.96.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 666A9216FD; Thu, 12 Nov 2020 17:16:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605201377; bh=lxI2SWRNu/vNMf3oMbzXFnq0SSD1w9QmvZ1Ujav1o8I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=xe2x5M1t18yJCKwVuL2NfQxj5Wr2gJMA2Gdc1O2AMfcZWsfxd8by8nRE2Mgl14ITQ YMJY1x709L8eGOFJ9b4e5+b+CEIDYbpiAtu37j1IxdZcUfsYJ+JNEDrtHsgeAnKobT hNNMtYZLOBGU52c9s3omM5ptGSNIrsuMJAWqI3q4= Date: Thu, 12 Nov 2020 17:16:00 +0000 From: Mark Brown To: Dmitry Osipenko Cc: Thierry Reding , Jonathan Hunter , Alan Stern , Peter Chen , Liam Girdwood , Adrian Hunter , Krzysztof Kozlowski , Greg Kroah-Hartman , Lee Jones , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Ulf Hansson , Mauro Carvalho Chehab , Rob Herring , Marek Szyprowski , Peter Geis , Nicolas Chauvet , linux-samsung-soc@vger.kernel.org, devel@driverdev.osuosl.org, linux-usb@vger.kernel.org, linux-pwm@vger.kernel.org, linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linux-tegra@vger.kernel.org Subject: Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling Message-ID: <20201112171600.GD4742@sirena.org.uk> References: <20201104234427.26477-1-digetx@gmail.com> <20201104234427.26477-12-digetx@gmail.com> <20201110202945.GF2375022@ulmo> <20201110203257.GC5957@sirena.org.uk> <72ae6462-13df-9fcb-510e-8e57eee0f035@gmail.com> <20201111115534.GA4847@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6WlEvdN9Dv0WHSBl" Content-Disposition: inline In-Reply-To: X-Cookie: Danger: do not shake. User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org --6WlEvdN9Dv0WHSBl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote: > 11.11.2020 14:55, Mark Brown =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote: > >> I already changed that code to use regulator_get_optional() for v2. > > That doesn't look entirely appropriate given that the core does most > > likely require some kind of power to operate. > We will need to do this because older DTBs won't have that regulator and > we want to keep them working. > Also, some device-trees won't have that regulator anyways because board > schematics isn't available, and thus, we can't fix them. This is what dummy supplies are for? > >> Regarding the enumerating supported voltage.. I think this should be > >> done by the OPP core, but regulator core doesn't work well if > >> regulator_get() is invoked more than one time for the same device, at > >> least there is a loud debugfs warning about an already existing > > I don't understand why this would be an issue - if nothing else the core > > could just offer an interface to trigger the check. > It's not an issue, I just described what happens when device driver > tries to get a regulator twice. > There was an issue once that check is added to the regulator core code. > But perhaps not worth to discuss it for now because I don't remember > details. So there's no known obstacle to putting enumeration of supported voltages into the OPP core then? I'm a bit confused here. > >> directory for a regulator. It's easy to check whether the debug > >> directory exists before creating it, like thermal framework does it for > >> example, but then there were some other more difficult issues.. I don't > >> recall what they were right now. Perhaps will be easier to simply get a > >> error from regulator_set_voltage() for now because it shouldn't ever > >> happen in practice, unless device-tree has wrong constraints. > > The constraints might not be wrong, there might be some board which has > > a constraint somewhere for=20 > In this case board's DT shouldn't specify unsupportable OPPs. Ah, so each board duplicates the OPP tables then, or there's an expectation that if there's some limit then they'll copy and modify the table? If that's the case then it's a bit redundant to do filtering indeed. --6WlEvdN9Dv0WHSBl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl+tbc8ACgkQJNaLcl1U h9DMCwgAg/TVHTXmevYwD5s1Ajz8QKM96GSjHTvRKagWLF+y+O7/6SvbHmWmiMqD 72lNxOyhMyrHsB/r2SJfYiZnTaxPvDwxTdU9CzTHTAPUdapJ6qyV0iuMkQHGTGKN SYqZvJhMfwBpvhvMDaUiOMYQ9uTqipBCfhqgXNhQaGfnIco6awkwlY3AKGp+50pg XKM7DBdL0naY0/Mog4jbOjAo3Np4dTsY/CPaIh/QPQe4p2lHaBmWLjobDZOlzEXI kZlYkHPdsANUEzVh7uuTgqYPs+WfxLW89lNjqL2/if0+KF5dNmcHORIOsJ5GQlQb J3JAZ0VQrlO7gydHgdEneannVwSdIg== =CmJu -----END PGP SIGNATURE----- --6WlEvdN9Dv0WHSBl--