On Thu, Jul 28, 2022 at 11:37:07AM +0200, Ulf Hansson wrote: > On Tue, 26 Jul 2022 at 18:03, Francesco Dolcini > <francesco.dolcini@xxxxxxxxxxx> wrote: > > > > 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. > > Well, historically we haven't modelled these kinds of power-rails > other than through power-domains. And this is exactly what genpd and > PM domains in Linux are there to help us with. > > Moreover, on another SoC/platform, maybe the power-rails are deployed > differently and maybe those have the ability to scale performance too. > Then it doesn't really fit well with the regulator model anymore. > > If we want to continue to keep drivers portable, I don't see any > better option than continuing to model these power-rails as > power-domains. > > > > > 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? > > No thanks! > > Well, unless you can convince me there are benefits to this approach > over the power-domain approach. I'm fine with our current power-domain proposal here, I do not need to convince you, I have the other problem to convince someone to merge it :-) Maybe Krzysztof, Robin or Mark can comment again after you explained your view on this topic. Francesco