[PATCH v3 3/6] dt-bindings: mfd: da9062: add regulator voltage selection documentation
Adam.Thomson.Opensource at diasemi.com
Tue Dec 17 03:32:48 AEDT 2019
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  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.
>  https://www.dialog-
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
More information about the Linux-aspeed