Hello Ulf and everybody, On Wed, Jul 13, 2022 at 01:43:28PM +0200, Ulf Hansson wrote: > On Thu, 23 Jun 2022 at 18:14, Max Krummenacher <max.oss.09@xxxxxxxxx> wrote: > > So our plan is to explicitly handle a (shared) regulator in every > > driver involved, adding that regulator capability for drivers not > > already having one. > > Please don't! I have recently rejected a similar approach for Tegra > platforms, which now have been converted into using the power domain > approach. Just to quickly re-iterate how our hardware design looks like, we do have a single gpio that control the power of a whole board area that is supposed to be powered-off in suspend mode, this area could contains devices that have a proper Linux driver and some passive driver-less components (e.g. level shifter) - the exact mix varies. Our proposal in this series was to model this as a power domain that could be controlled with a regulator. Krzysztof, Robin and others clearly argued against this idea. The other approach would be to have a single regulator shared with the multiple devices we have there (still not clear how that would work in case we have only driver-less passive components). This is just a device-tree matter, maybe we would need to add support for a supply to some device drivers. Honestly my conclusion from this discussion is that the only viable option is this second one, do I miss something? > If it's a powerail that is shared between controllers (devices), used > to keep their registers values for example, that should be modelled as > a power domain. Moreover for power domains, we can support > voltage/frequency (performance) scaling, which isn't really applicable > to a plain regulator. > > However, if the actual powerrail fits well to be modelled as > regulator, please go ahead. Although, in this case, the regulator must > only be controlled behind a genpd provider's on/off callback, so you > still need the power domain approach, rather than using the regulator > in each driver and for each device. Francesco
