On 16 December 2019 08:55, Marco Felsch wrote: > On 19-12-12 16:51, Mark Brown wrote: > > On Thu, Dec 12, 2019 at 05:21:53PM +0100, Marco Felsch wrote: > > > > > "... what's driving the input ..": > > > Sorry I didn't get you here. What did you mean? The input is driven by > > > the host. This can be any gpio line and in my case it is a gpio line > > > driven by the soc-hw during a suspend operation. > > > > Something needs to say what that thing is, especially if it's runtime > > controllable. In your case from the point of view of software there is > > actually no enable control so we shouldn't be providing an enable > > operation to the framework. > > The enabel control signal is always available, please check [1] table > 63. There is a mux in front of the enable pin so: > > +------------- > Seq. |\ | Regulator > GPI1 | \ | > GPI2 | | -- > Enable > GPI3 | / | > |/ . > . > . > > Adam please correct me if this is wrong. Yes the register can always be configured regardless of the associated pin configuration, but if say GPIO1 was configured as a GPO but a regulator was configured to use GPIO1 as its GPI control mechanism, the output signal from GPIO1 would be ignored, the sequencer control would not have any effect and you're simply left with manual I2C control. Really we shouldn't be getting into that situation though. If a GPIO is to be used as a regulator control signal then it should be marked as such and I don't think we should be able to use that pin for anything other than regulator control. > > [1] https://www.dialog- > semiconductor.com/sites/default/files/da9062_datasheet_3v6.pdf > > Regards, > Marco > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
