[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEo2pzsRf++Yaexn2K=RTu=NJs6GwC=6DXC50a=Xv92FO8N7Vg@mail.gmail.com>
Date: Thu, 18 Feb 2016 12:46:40 +0300
From: Ильяс Гасанов
<torso.nafi@...il.com>
To: "Matwey V. Kornilov" <matwey@....msu.ru>
Cc: Greg KH <gregkh@...uxfoundation.org>, Jiri Slaby <jslaby@...e.com>,
Peter Hurley <peter@...leysoftware.com>,
Andy Shevchenko <andy.shevchenko@...il.com>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-serial@...r.kernel.org
Subject: Re: [PATCH v8 3/3] tty: 8250_omap: Use software emulated RS485
direction control
2016-02-18 10:18 GMT+03:00 Ильяс Гасанов <torso.nafi@...il.com>:
> Also, forgot to mention that if serial8250_em485_init is called not
> upon uart startup but elsewhere (upon port register for example), and
> em485 is set, serial8250_do_startup should call
> serial8250_em485_rts_after_send, or else RTS might be in wrong state
> whenever the port device is opened, making it impossible to receive
> data through RTS-controlled RS232<->RS485 hardware converters.
Just found out that it doesn't help. Actually, it is the behavior of
tty_open function to call tty_port_block_til_ready after startup, and
of the latter - to set RTS via ioctl if baud is not zero - both of
which cannot be overriden within the scope of the 8250 framework. The
reason this works in legacy omap_serial is that my GPIO which is used
to emulate RTS is not tied to mctrl there, so the call of
tty_port_block_til_ready does not affect its state.
Therefore, a check for SER_RS485_ENABLED needs to be introduced to
tty_port_block_til_ready.
Regards,
Ilyas G.
Powered by blists - more mailing lists