<div dir="ltr">OK.  I didn't get that from the commit message or comments as written.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 31, 2017 at 2:23 PM, Xo Wang via openbmc <span dir="ltr"><<a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Jan 28, 2017 at 12:00 AM, Andrew Jeffery <<a href="mailto:andrew@aj.id.au">andrew@aj.id.au</a>> wrote:<br>
> On Fri, 2017-01-27 at 15:32 -0800, Rick Altherr wrote:<br>
>> I still don't follow.  Is this changing it to drop bytes until the<br>
>> host powers on?  Is this change making it so the device won't open?<br>
><br>
> I understand it to be the other way around:<br>
><br>
> In the existing configuration UART1 will drop bytes by being held in<br>
> reset until the host initialises the LPC bus (i.e. releases LPCRST#)<br>
> during boot.<br>
><br>
> Xo's change reconfigures the SoC so that UART1 reset state doesn't<br>
> depend on LPCRST# (i.e. the host initialising the LPC bus), so it is<br>
> immediately useful in that it won't discard bytes.<br>
><br>
> Xo?<br>
<br>
</span>Yes, what Andrew said. It releases UART1 from being controlled by LPC<br>
reset, so that it's available regardless of the host being up.<br>
<br>
cheers<br>
<span class="HOEnZb"><font color="#888888">xo<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
openbmc mailing list<br>
<a href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a><br>
<a href="https://lists.ozlabs.org/listinfo/openbmc" rel="noreferrer" target="_blank">https://lists.ozlabs.org/<wbr>listinfo/openbmc</a><br>
</div></div></blockquote></div><br></div>