Hi, On Wed, May 30, 2018 at 8:02 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Wed, May 30, 2018 at 07:46:50AM -0700, Doug Anderson wrote: >> On Wed, May 30, 2018 at 2:37 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> >> Linux vote for the lowest voltage it's comfortable with. Linux keeps >> >> track of the true voltage that the driver wants and will always change >> >> its vote back to that before enabling. Thus (assuming Linux is OK >> >> with 1.2 V - 1.4 V for a rail): > >> > That's pretty much what it should do anyway with normally designed >> > hardware. > >> I guess the question is: do we insist that the driver include this >> workaround, or are we OK with letting the hardware behave as the >> hardware does? > > What you're describing sounds like what we should be doing normally, if > we're not doing that we should probably be fixing the core. I'm not convinced that this behavior makes sense to move to the core. On most regulators I'd expect that when the regulator driver says to turn them off that they will output no voltage. The reason RPMh is special is that there's an aggregation outside of Linux. Specifically I like to make it concrete use the example where both Linux and "the modem" make requests for the same regulator and RPMh aggregates these requests. This aggregation happens separately for "enabled" and "voltage". Thus if you consider: Modem: vote for 1.3V and enabled=true Linux: vote for 1.4V and enabled=false The aggregated voltage is 1.4V and the aggregated enabled is true. Said another way: Linux's vote for the voltage affected the state of the rail even though Linux wanted the rail disabled. In any other system when Linux disabled the regulator it wouldn't matter that you left it set at 1.4V. Thus RPMh is special and IMO the workaround belongs there. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
