On 02/03/2016 01:45 AM, Greg Farrell wrote:
> Hi Peter,
>
> On 2016-02-03 00:16, Peter Hurley wrote:
>> Won't this turn on h/w flow control for designs where RTS/CTS
>> is unconnected?
>
> I don't believe so. What I believe it will do is flag the physical device as being capable of supporting H/W flow control, which all devices supported by omap-serial.c are. It will not enable h/w flow control, as you may or may not want it for your particular setup. You may have a UART that supports h/w flow control, but not physical wire connection for RTS signal.
Sorry, I was in a hurry and mis-wrote.
> My understanding of the code is that this code
>
> if (termios->c_cflag & CRTSCTS && up->port.flags & UPF_HARD_FLOW) {
> /* Enable AUTORTS and AUTOCTS */
> up->efr |= UART_EFR_CTS | UART_EFR_RTS;
>
> in serial_omap_set_termios() will mean that h/w flow control will not be enabled unless requested via termios.
>
> In fact, without the UPF_HARD_FLOW flag set in the up->port.flags, it is not possible to enable h/w flow-control, and any request to do so via termios will silently fail.
auto h/w flow control implies the remote must also have auto h/w flow
control. For example, throttling works by stopping rx receive. However,
if the remote does not stop sending within the minimum time, the rx fifo
will overflow.
There is no way for you to probe whether the remote supports auto h/w flow
control. This is why omap-serial doesn't automatically do auto h/w flow control.
Also, auto soft flow control on OMAP is broken.
1) if auto IXON is selected, and the uart receives XOFF, the only way to
restart flow is to receive XON. Even changing the flow control mode does
not restart flow.
2) auto IXOFF has the same problem as auto h/w flow control. The remote must
stop sending within the minimum time or the rx fifo will overflow.
Non-auto s/w flow control remotes will not be capable to this.
> Without this UPF_BOOT_AUTOCONF flag set, the serial_omap_config_port() configuration function is never called for the omap-serial device. This function is written and has the code to enable UPF_SOFT_FLOW and UPF_HARD_FLOW, as well as to flag the port as type = PORT_OMAP. However it is (I presume accidentally) dead code without the UPF_BOOT_AUTOCONF flag. This is because the call to the serial_omap_config_port() function is protected in serial_core.c by a test for the flag UPF_BOOT_AUTOCONF .
>
> if (port->flags & UPF_BOOT_AUTOCONF) {
> if (!(port->flags & UPF_FIXED_TYPE)) {
> port->type = PORT_UNKNOWN;
> flags |= UART_CONFIG_TYPE;
> }
> port->ops->config_port(port, flags); // this is a pointer to the device specific configuration function, serial_omap_config_port in this case
> }
>
> You can compare this to the behaviour of the 8250/8250_core.c driver, which I think (but am unsure) that the omap-serial driver was based on.
>
> It's serial8250_register_8250_port function (called by serial8250_probe()), specifically sets the UPF_BOOT_AUTOCONF flag. As do many of the other serial drivers.
>
> uart->port.flags = up->port.flags | UPF_BOOT_AUTOCONF;
Well, the 8250 driver does actually probe the device to configure it.
This is not necessary on the OMAP part because there are not different
OMAP uarts.
> Without this patch, we are not able to turn on h/w flow control.
ioctl(TIOCSERCONFIG)
> Thanks,
>
> Greg
>
>
> On 2016-02-03 00:16, Peter Hurley wrote:
>> On 01/25/2016 04:00 AM, Greg Farrell wrote:
>>>
>>> Enable the UPF_BOOT_AUTOCONF flag in serial_omap_probe().
>>> This will cause serial_omap_config_port() to be run and
>>> the hardware to correctly be flagged as supporting hardware
>>> and software flow-control.
>>>
>>> Without this, it is not possible to enable flow control.
>>
>> Won't this turn on h/w flow control for designs where RTS/CTS
>> is unconnected?
>>
>>
>>> Signed-off-by: Greg Farrell <greg@xxxxxxxxxxxxxxx>
>>> ---
>>> drivers/tty/serial/omap-serial.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
>>> index b645f92..5e82238 100644
>>> --- a/drivers/tty/serial/omap-serial.c
>>> +++ b/drivers/tty/serial/omap-serial.c
>>> @@ -1664,7 +1664,10 @@ static int serial_omap_probe(struct platform_device *pdev)
>>> sprintf(up->name, "OMAP UART%d", up->port.line);
>>> up->port.mapbase = mem->start;
>>> up->port.membase = base;
>>> - up->port.flags = omap_up_info->flags;
>>> + /*
>>> + * Enable UPF_BOOT_AUTOCONF so that serial_omap_config_port will execute
>>> + */
>>> + up->port.flags = omap_up_info->flags | UPF_BOOT_AUTOCONF;
>>> up->port.uartclk = omap_up_info->uartclk;
>>> up->port.rs485_config = serial_omap_config_rs485;
>>> if (!up->port.uartclk) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
