On Wed, Aug 27, 2014 at 10:41:42PM +0200, Tomasz Figa wrote: > On 27.08.2014 22:25, Mark Brown wrote: > > Well, presumably the bootloader is going to run again even for a warm > > reboot? > This is strange, but apparently it's not the case for the hardware which > this patch is supposed to fix or at least this is how I understood it. Fun. It's like everyone was setting out to define the most fragile system they could, from the chip design up... so many moving pieces that have to line up. > > It's not in general true that Linux should never change the mode (the > > main case for toggling modes is usually going between an idle/suspend > > state and active state) > I believe this is yet another reason why we should have a way to specify > opmodes in DT, now not only active but also suspend/idle opmodes. > However on many PMICs this is a bit more complicated. There are opmodes > such as Well, quite. Plus the more basic question of what a mode actually is and how you talk about them generically. It's not that there's no use for this functionality, it's that it doesn't lend itself to defining ABIs. > > You're talking about the case > > where the bootloader does set something but avoids doing so on warm > > reboots only here. > From Javier's description I understood this is the case for the board > for which he develops. No, the issue is that the bootloader isn't touching the regulator then Linux turns it off, reboots and ends up thinking the default operating mode is off which doesn't work terribly well when it tries to enable the regulator. The reading back from hardware is trying to implement the standard Linux behaviour of not changing a setting without explicit permission, this change is providing a fallback for the case where that's giving us something obviously wrong. > > Besides, even if we did have a way of specifying modes in DT (with all > > the problems that brings) we still have to pick a default if that's not > > used). > Sure we do and we can define the binding to default to something (e.g. > normal mode) if respective property is not present. Btw. the issue with > opmode also affects other PMIC chips such as Samsung S5M ones. That's then going against our purposely conservative implementation, and would be especially bad if it overrode one of the hardware managed modes on an otherwise unused regulator.
Attachment:
signature.asc
Description: Digital signature
