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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A33E5C43334 for ; Thu, 21 Jul 2022 16:17:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229715AbiGUQRL (ORCPT ); Thu, 21 Jul 2022 12:17:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233886AbiGUQQy (ORCPT ); Thu, 21 Jul 2022 12:16:54 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33B108AEE5; Thu, 21 Jul 2022 09:15:52 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C7068B825B5; Thu, 21 Jul 2022 16:15:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CEA70C3411E; Thu, 21 Jul 2022 16:15:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658420143; bh=aKwoXurJ8ulRwPNPOsnWs3xQ4UsvWh88KPItgK8MMuM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=npMkh7m8Oh15DP+rI1DqB9B6lnCWY4QLz0BSHjNzOUiW5cjyCaXHRlEd8Fh9rBVSI 1J0z4KZBzuDLMtao4Zd3EvoxDszjxkXRiyUK2qW9zw3cG1FqkcC83CcPiL3+VHviGo JrFc11zQ+/gZvn+MKNiFpS9U3yVv9ykaSJPFhrjWewCu1Lw93RPgc/yqCtCM+3OzeH o4Fpa4nBuq+QoWT6YDkuYYVdlxElEFfhZorA8Ov3DMZJp0/6SKohfmb/jCZb4jyhfd JI7KbshgSKgvg2iGH3aBr2HmLKbCpiqBRLWXkUcy3+B+onZ51F8TkUkq0v2/tW6CNw 7VWqVoa93Elmw== Date: Thu, 21 Jul 2022 17:15:35 +0100 From: Mark Brown To: Doug Anderson Cc: Johan Hovold , Kuogee Hsieh , Bjorn Andersson , Vinod Koul , dri-devel , Rob Clark , Sean Paul , Stephen Boyd , Daniel Vetter , David Airlie , Andy Gross , Dmitry Baryshkov , "Abhinav Kumar (QUIC)" , "Aravind Venkateswaran (QUIC)" , Sankeerth Billakanti , freedreno , linux-arm-msm , LKML , Liam Girdwood , Manivannan Sadhasivam , Rob Herring , Krzysztof Kozlowski Subject: Re: [PATCH v16 0/3] eDP/DP Phy vdda realted function Message-ID: References: <1657038556-2231-1-git-send-email-quic_khsieh@quicinc.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bUeDuiEk6fcD6K16" Content-Disposition: inline In-Reply-To: X-Cookie: Exercise caution in your daily affairs. Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org --bUeDuiEk6fcD6K16 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2022 at 07:52:01AM -0700, Doug Anderson wrote: > On Thu, Jul 21, 2022 at 7:39 AM Doug Anderson wro= te: > > vdda-phy-supply =3D <&vdda_mipi_dsi0_1p2>; > > vdda-phy-supply-base-load =3D <21800>; > Ah, sorry to respond to my own thread so quickly, but I just thought > of a reason for the "matching properties" solution instead of the two > cells. It would allow the SoC "dtsi" file to specify a base load while > the board "dts" file can then specify the supply. That feels like it > could be a nice solution. For a per device thing it probably shouldn't be called a "base load", it's just the load. I would question how useful this would be, aside =66rom the concerns vendors will likely have with disclosing actual power consumptions if the number never changes then it is immaterial which device contributes which milliamp of load, you just want to configure a fixed mode on the regulator and have done with it. --bUeDuiEk6fcD6K16 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmLZe6YACgkQJNaLcl1U h9BkCwf/ZX/ZcVyHzQF89Ws5jgAkSI71g6b+vTVGymg8Q8k62rRqUk7v8t+c6EyS IbyN2L5dNL+Fs7+aJvGJi9EhHaVxsErDeSKYqEKGnq/RJG0oHdt5lYMPoHOddnZU c4h8YZoVsFQqKbXwogmK01nG/OVYYID52ALzV6j04F+xAazbjwY5ftLOFcsplQ1z yqy6qiD5dnu6kYWNS6RgVhCIeY4WaRulldCHqrHz9DV549sxsv/0cDrT19ZpcZkp HkwgeFUhCd/xRDuhiZp+XTHwgg2AC8txVpqggzA2kXgNVmxzN8rcFLjYVtoOglMz PWh0O6ZDoxu0TIGGjCudo2nCbYnIdQ== =Lepm -----END PGP SIGNATURE----- --bUeDuiEk6fcD6K16--