Re: [PATCH v7 1/6] DONOTMERGE: arm64: dts: ti: Add TI TPS65219 PMIC support for AM642 SK board.

From: Mark Brown <broonie@kernel.org>
To: Nishanth Menon <nm@ti.com>
Cc: jerome Neanne <jneanne@baylibre.com>,
	Wadim Egorov <W.Egorov@phytec.de>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"kristo@kernel.org" <kristo@kernel.org>,
	"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
	"krzysztof.kozlowski+dt@linaro.org" 
	<krzysztof.kozlowski+dt@linaro.org>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	"lee@kernel.org" <lee@kernel.org>,
	"tony@atomide.com" <tony@atomide.com>,
	"vigneshr@ti.com" <vigneshr@ti.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>,
	"dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>,
	"marcel.ziswiler@toradex.com" <marcel.ziswiler@toradex.com>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"biju.das.jz@bp.renesas.com" <biju.das.jz@bp.renesas.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"jeff@labundy.com" <jeff@labundy.com>, "afd@ti.com" <afd@ti.com>,
	"khilman@baylibre.com" <khilman@baylibre.com>,
	"narmstrong@baylibre.com" <narmstrong@baylibre.com>,
	"msp@baylibre.com" <msp@baylibre.com>,
	"j-keerthy@ti.com" <j-keerthy@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v7 1/6] DONOTMERGE: arm64: dts: ti: Add TI TPS65219 PMIC support for AM642 SK board.
Date: Fri, 16 Dec 2022 13:41:52 +0000	[thread overview]
Message-ID: <Y5x1oAzezZGqyZSx@sirena.org.uk> (raw)
In-Reply-To: <20221215214149.whcjdphxxvvedrih@affront>

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

On Thu, Dec 15, 2022 at 03:41:49PM -0600, Nishanth Menon wrote:

> Yeah - this happens to be SDcard supply (at least in my case).. I'd
> rather not change the mmc host or core layer to handle a case where
> LDO happened to be in bypass. it is a regulator driver's problem, IMHO
> how to provide the stated voltage OR fail to transition the voltage.

Well, if the regulator is in bypass mode then it is by definition not
regulating and so it's like programming the voltage while switched off,
setting the target for when it starts regulating again.  It's a weirder
use case but it does feel like the consistent thing to do at least.
The driver shouldn't enter/leave bypass without being explicitly told to
so since there'll be a performance impact.

> b) If I wanted the LDO to poweroff the bypass bit at start (define the
>    startup hardware condition), I dont seem to have a description for
>    that either.

That's something we could add in constraints, though the actual process
of implementing it might get messy if there's restrictions like having
to power off (though from further down the thread I see that might not
apply to this device).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]