AST SOC gpio pass-through support

[Andrew Jeffery]

On Thu, 2017-08-10 at 18:55 +0800, Yong Li wrote:
> Hi Andrew,
> 
> I am thinking about "DYNAMIC DEVICE TREE". Maybe we can use it to
> change the gpio pass-through dynamically?

I feel you're barking up the wrong (device!) tree here. It might work
in the end, but I expect you would be better off going with the runtime
pinmuxing or bind/unbind than invoking the complexity of dynamic
devicetrees.

> 
> Let me study on these docs

Feel free to keep me in the loop.

Cheers,

Andrew

> 
> Thanks again!
> Yong
> 
> 
> 
> 2017-08-10 18:11 GMT+08:00 Andrew Jeffery <andrew at aj.id.au>:
> > On Thu, 2017-08-10 at 17:01 +0800, Yong Li wrote:
> > > thanks for your quick response Andrew!
> > 
> > No worries!
> > 
> > > i will read these info deeply. just a quick question, is it
> > > possible
> > > to enable/disable the pass through dynamically after kernel
> > > boots?  how?
> > 
> > So there is the concept of runtime pinmuxing[1]: It's possible for
> > a
> > device to have several pinmux states that can be
> > configured/selected
> > from process context. Alternatively, a naive approach might be just
> > unbinding the driver for the device you used to select the pass-
> > through
> > mux function(s) - this would free up the pins to be requested as
> > regular GPIOs. However, you'd need to request the mux on a device
> > node
> > other than the pinctrl node, as unbinding that would have
> > undesirable
> > consequences :)
> > 
> > Hope that helps.
> > 
> > Andrew
> > 
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.
> > git/tree/Documentation/driver-api/pinctl.rst#n1385
> > 
> > > 
> > > > > > 在 2017年8月10日，16:28，Andrew Jeffery <andrew at aj.id.au> 写道：
> > > > 
> > > > Hi Yong,
> > > > 
> > > > > On Thu, 2017-08-10 at 15:50 +0800, Yong Li wrote:
> > > > > Hi all,
> > > > 
> > > > Welcome to the list!
> > > > 
> > > > > 
> > > > > AST SOC supports GPIOE pass-through function, I would like to
> > > > > know if
> > > > > the kernel provides such API/interface to enable/disable
> > > > > pass-through?
> > > > 
> > > > Yes, the kernel's pinmux drivers can configure GPIO passthrough
> > > > for
> > > > you. In general, all the functions are documented in the
> > > > pinctrl
> > > > devicetree bindings:
> > > > 
> > > >    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin
> > > > ux.git/tree/Documentation/devicetree/bindings/pinctrl/pinctrl-
> > > > aspeed.txt?h=v4.12
> > > > 
> > > > Specifically, you are after functions/groups GPIE{0,2,4,6}. We
> > > > already
> > > > have these defined in the Aspeed DTSIs, so to configure them
> > > > you can
> > > > add something like the following snippet in your devicetree:
> > > > 
> > > >    &pinctrl {
> > > >            pinctrl-names = "default";
> > > >            pinctrl-0 = <&pinctrl_gpie0_default
> > > >                    &pinctrl_gpie2_default
> > > >                    &pinctrl_gpie4_default
> > > >                    &pinctrl_gpie6_default>;
> > > >    }
> > > > 
> > > > Specifying the mux configuration in the pinctrl node is
> > > > probably as
> > > > good a place as any, though if you have somewhere more relevant
> > > > you
> > > > should probably use that. Naturally you can remove any of these
> > > > phandles to only select the specific pass-through
> > > > configurations you
> > > > need.
> > > > 
> > > > If you want to pass-through the whole bank you can also set the
> > > > board
> > > > strapping to make it the case right from power-on. The
> > > > strapping
> > > > register *is* writeable, however the kernel's pinctrl driver
> > > > treats it
> > > > as read-only, as really, the system designer ought configure it
> > > > either
> > > > via pull-ups or in the boot firmware.
> > > > 
> > > > The passthrough capability is a bit of an odd case - despite
> > > > being GPIO
> > > > I chose to represent it as a pinctrl function. Hope it makes
> > > > sense to
> > > > you.
> > > > 
> > > > Cheers,
> > > > 
> > > > Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170810/09cc5d6d/attachment.sig>