<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><br><div>Dear <span style="font-family: arial; white-space: pre-wrap;">Andrew£¬</span></div><div><span style="font-family: arial; white-space: pre-wrap;"><br></span></div><div><font face="arial"><span style="white-space: pre-wrap;">Thank you for your reply. I'll elaborate my opinion as follows:</span></font></div><br><pre><div><br></div><div><br></div>At 2019-11-22 08:31:05, "Andrew Jeffery" <andrew@aj.id.au> wrote:
>Hi Byron,
>
>I'm Cc'ing openbmc@ on this based on my earlier request (history is at
>the bottom)
>
>On Wed, 20 Nov 2019, at 18:34, www wrote:
>> Dear Andrew Jeffery£¬
>> 
>> Thank you for your reply. I've come up with a plan. Can I trouble you 
>> to see if it's ok? The brief introduction is as follows:
>> 1. write a pass-through driver; (can switch the pass through function 
>> or get the status in user space)
>> 2. modify pinctrl driver£»£¨Eliminating the influence of pinctrl on pass 
>> through register£¬At present, the operation of GPIOD/E will affect the 
>> pass through function£©
>> 3. First turn off the pass through function, then turn on or off the 
>> host, and then enable the pass through function.
>> 
>> In this way, there is no need to detect whether GPIO has input or 
>> not£¬and this is the real hardware pass through.
>> Do you think this is feasible?
>
>Your proposal sounds like more work than just hooking the two GPIOs
>together in userspace, so I need to understand why you're avoiding that
>approach. I have some questions:
>
>1. What mode of pass-through are you using? It comes in two flavours:
>hardware strapping that affects an entire GPIO bank or paired pass-
>through which must be explicitly muxed at runtime.
<div>></div><div><br></div><div>hardware strapping can be modified by software. turn off global pass-through switch, </div><div>and turn on paired pass-through(Set according to your hardware design), </div><div>The specific GPIO setting may need to be obtained from DTS.</div><div><br></div><div><br></div>>2. What is the requirement for hardware passthrough here (as
>opposed to doing it in userspace when the BMC comes up)? Please
>provide as much detail as you can in response so I'm clear on the
>motivation.
<div>></div><div><br></div><div>The hardware pass through function will be used for power button, reset button or ID button.</div><div>(Set according to your hardware design)</div><div>When some processes of BMC are hung up and kernel panic appears in BMC, </div><div>even when BMC fails to start(stop at uboot), these buttons can still be used, especially for power button. </div><div>(in this case, you can update the BMC firmware and repair the BMC firmware if you can boot into the system.)</div><div><br></div><div><br></div>>Another significant issue with your proposal is that removing the
>knowledge of pass-through from pinmux means that it's possible to
>achieve an inconsistent state between the intent of a pin request and
>its resulting behaviour. That's a bug that is currently not possible, so
>you will need to do a lot of work to convince me it's the right approach.
<div><br></div><div>I see that when gpioD/ E is operated, it will first turn off the pass through function, and then perform other operations. </div><div>Because the previous pass through state is not saved, there is no way to restore the pass through state.</div><div>I think we should remove the operation of pass thought in gpio driver, </div><div>and then use the special pass through part to open or close the pass through function.</div><div>I know this will have a great impact on the GPIO driver part, </div><div>because you are an expert in GPIO direction, so please consult your opinion.</div><div><br></div><div><br></div>>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.<br>>What are your thoughts on this?
<div>></div><div><br></div><div>I haven't heard of this way. Would you please explain it in detail? Thank you</div><div><br></div><div><br></div>>A couple of final notes:
>
>a. Aspeed confirmed that GPIOs configured as passthrough are
>constrained to read-only behaviour in the GPIO controller. I haven't
>tested this to verify, but if it's possible to drive the pin then you'd
>want to be mindful of multiple current sources in push-pull or
>open/source configurations.
<div>></div><div>In my test, it's true that when enable pass through, the GPIO can only read, not write.</div><div><br></div><div><br></div>>b. Looking at the ast2500 driver the groups for the strapping-based
>passthrough aren't described which means some of the mutual-
>exclusion behaviour won't quite work as desired. I should fix that.
<div>
</div><div>Thank you for your contribution to this part. I hope you can finish it as soon as possible. Thank you.</div><div><br></div><div>thanks,</div><div>Byron</div><div><br></div><div><br></div>>Cheers,
>
>Andrew
>
>> 
>> thanks,
>> Byron
>> 
>> 
>> 
>> 
>> At 2019-11-20 14:52:17, "Andrew Jeffery" <andrew@aj.id.au> wrote:
>> >Hi Byron,
>> >
>> >Sorry about the delayed reply, I have been on leave.
>> >
>> >Please ask me questions on the list in future, as others may have the same
>> >question as you but they can't learn if our exchanges are private :)
>> >
>> >On Fri, 15 Nov 2019, at 20:06, www wrote:
>> >> Dear Andrew Jeffery£¬
>> >> 
>> >> I saw that the speed pinctrl driver in the openbmc kernel was uploaded 
>> >> by you. 
>> >
>> >Yep, I maintain the pinctrl drivers for the Aspeed SoCs.
>> >
>> >> As a result of the test, I found that this driver will affect 
>> >> the pass-through function. When operating with GPIO, the pass through 
>> >> function will be automatically turned off (this is not the working mode 
>> >> of the aspeed chip. On the chip, the two functions can coexist).
>> >
>> >Only to a point. If the GPIOs are configured for passthrough then accessing
>> >the pin via the GPIO controller is read-only according to Aspeed. I'm trying
>> >to find where I found this information.
>> >
>> >> How 
>> >> can I modify it to eliminate this effect? I want it to turn on or off 
>> >> the system without affecting the passthrough function. Can you give me 
>> >> some advice or tell me how to modify it?
>> >
>> >I understand what you're after. Let me think about it a bit, as it might be
>> >possible to cook up a solution. It's complicated by the mutual-exclusion
>> >behaviour of the pinctrl subsystem - I want to retain this as it removes an
>> >entire class of hard-to-track-down bugs (last-function-probed-wins-the-pin).
>> >
>> >I assume your system is strapped so that the GPIOs are passthrough? If so, a
>> >possible software implementation is to export both of the relevant GPIOs to
>> >userspace, and provide a daemon that polls() on the input GPIO and some
>> >other external (dbus?) event, and writes the output GPIO when an event
>> >occurs. This gives the effect of hardware passthrough with the addition of the
>> >arbitrary control over the output GPIO.
>> >
>> >Hope that helps,
>> >
>> >Andrew
>> 
>> 
>>
</pre></div><br><br><span title="neteasefooter"><p> </p></span>