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