On 01/18/16 17:17, Brian J. Johnson wrote:
> On 01/18/2016 05:55 AM, Laszlo Ersek wrote:
>> On 01/18/16 12:41, Ryan Harkin wrote:
>>> >On 18 January 2016 at 11:33, Laszlo Ersek<ler...@redhat.com> wrote:
>>>> >>On 01/18/16 11:24, Zeng, Star wrote:
>>>>> >>>[...]
>>>>> >>>
>>>>>>> >>>>>
>>>>>>> >>>>>The above analysis is very clear, thanks. I am a little
>>>>>>> concern about if
>>>>>>> >>>>>the code changes below follow the comments in the code.
>>>>>>> >>>>>
>>>>>>> >>>>>In Terminal.c:
>>>>>>> >>>>> //
>>>>>>> >>>>> // Set the timeout value of serial buffer for
>>>>>>> >>>>> // keystroke response performance issue
>>>>>>> >>>>> //
>>>>>>> >>>>>In TerminalConIn.c:
>>>>>>> >>>>> //
>>>>>>> >>>>> // if current timeout value for serial device is not
>>>>>>> identical with
>>>>>>> >>>>> // the value saved in TERMINAL_DEV structure, then
>>>>>>> recalculate the
>>>>>>> >>>>> // timeout value again and set serial attribute
>>>>>>> according to this
>>>>>>> >>>>>value.
>>>>>>> >>>>> //
>>>>> >>>
>>>>> >>>Any comments about above concern?
>>>> >>
>>>> >>Not really.
>>>> >>
>>>> >>I don't know what the purpose of the Timeout calculation is (what
>>>> is the
>>>> >>"keystroke response performance issue"?), but in any case, it is a
>>>> good
>>>> >>sign that TerminalDxe sets*some* Timeout explicitly.
>>>> >>
>>>> >>Plus, it has worked reliably until now, so we shouldn't change the
>>>> >>Timeout argument.
>>>> >>
>>> >
>>> >I think "reliably" is a bit generous;-) The most common complaint I
>>> >get about EDK2 is that it can't handle more than a FIFO's worth of
>>> >pasted characters on the serial port.
>> I tend to think this comes, at least partly, from the fact that UEFI
>> doesn't do interrupt-driven drivers. There's timer based polling (in
>> drivers), and there are busy loops (in applications, I guess).
>>
>> I think you'll see the same behavior with network packet reception.
>>
>> I said "reliably" beause in my environment I've had practically zero
>> issues with the serial terminal (beyond the one, very lacking, textual
>> resolution list -- but I patched that for myself permanently).
>>
>> Thanks
>> Laszlo
>
> Can't you just enable hardware flow control (RTS/CTS) on the UART?
>From the spec:
Flow control is the responsibility of the software that uses the
protocol. Hardware flow control can be implemented through the use
of the GetControl() and SetControl() functions (described below) to
monitor and assert the flow control signals. The XON/XOFF flow
control algorithm can be implemented in software by inserting XON
and XOFF characters into the serial data stream as required.
(That's all I know about flow control over serial. :))
Grepping for EFI_SERIAL_HARDWARE_FLOW_CONTROL_ENABLE and
UART_FLOW_CONTROL_HARDWARE yields some results, but none in TerminalDxe.
Which makes me believe that most of the platform-specific serial IO
implementations offer hw flow control, but TerminalDxe doesn't use it.
Interestingly though, some hits are from the (now deprecated) Intel BDS:
"IntelFrameworkModulePkg/Universal/BdsDxe/BootMaint".
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
