AST SOC gpio pass-through support
Andrew Jeffery
andrew at aj.id.au
Fri Aug 11 09:45:22 AEST 2017
On Thu, 2017-08-10 at 09:11 -0700, Rick Altherr wrote:
>
>
> On Aug 10, 2017 3:12 AM, "Andrew Jeffery" <andrew at aj.id.au> wrote:
> 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.
>
>
> On Quanta Q71L, the hardware strap is used to enable pass through so
> the power button works even if the BMC fails to boot. The BMC
> firmware is expected to disable the pass through once it is ready to
> take over. I believe I sent the patch upstream to allow pinmux to
> modify the strap register for this case. That is, pass through is
> disabled when the user exports a GPIO to userspace.
Ah yes, I forgot we added an exception there. It does require that the
strapping is used for the configuration and not the alternative SCU
bits that are set by the GPIE{0,2,4,6} functions, which were enabled by
the devicetree snippet I sent previously. If the mux is requested with
the GPIE{0,2,4,6} functions then the runtime pinmuxing is really the
only choice.
Yong: What is your use case? If it's similar to the Q71L as Rick has
outlined, then please ensure the strapping is set correctly in hardware
- setting it in U-Boot doesn't really gain you much unless you fail to
load/boot the kernel.
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/20170811/3faaed35/attachment.sig>
More information about the openbmc
mailing list