[openbmc-kernel]: How to make pinctrl not affect pass-through function?

[www]

Dear Andrew,


Thank you. I got it.
Pass-through function is only a small and special part of GPIO function.
If the entire pinctrl and /sys/class/gpio  are changed due to this function, I am not sure whether it is appropriate.


thanks,
Byron



At 2019-11-22 14:32:51, "Andrew Jeffery" <andrew at aj.id.au> wrote:
>On Fri, 22 Nov 2019, at 14:55, www wrote:
>> At 2019-11-22 08:31:05, "Andrew Jeffery" <andrew at aj.id.au> wrote:
>
>*snip* 
>
>> >Getting back to your problem rather than solutions, it's possible to view
>> >this as a deficiency in the GPIO subsystem and Aspeed GPIO driver: If we
>> >could describe that we want the pin muxed for pass-through as part of
>> >the GPIO request then your problem would be partly resolved, save for 
>> >the fact that the exported GPIO would still be read-only. However, that
>> >issue is fully resolved by multiple sequential GPIO requests: export the
>> >GPIO in pass-through mode initially, and then when it comes to changing
>> >the host state, re-export the GPIO in non-pass-through mode so that it is
>> >writable, and then again re-export the GPIO back in pass-through mode
>> >after the host state change has been applied. This is the sequence of
>> >your original solution above, just without the need for additional drivers
>> >with ad-hoc userspace interfaces or introducing bugs into the pinctrl
>> >driver.
>> >What are your thoughts on this?
>> >
>> 
>> I haven't heard of this way. Would you please explain it in detail? Thank you
>
>What details are you after? What I suggested above is not yet possible -
>we'd need to develop some kernel patches to make it work, but they would
>be something we could upstream. pinctrl needs to remain aware of whether
>a pin is in GPIO pass-through mode or not, as it not only affects how that pin
>will behave but how *other* "unrelated" pins might behave as well.
>
>Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191122/c9bc58ed/attachment.htm>