[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6931d6ad-7520-b585-a8ba-35349e730bb@linux.intel.com>
Date: Tue, 8 Mar 2022 14:16:56 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
cc: Lukas Wunner <lukas@...ner.de>,
"open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
Jiri Slaby <jirislaby@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Johan Hovold <johan@...nel.org>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Raymond Tan <raymond.tan@...el.com>,
Heiko Stuebner <heiko@...ech.de>
Subject: Re: [PATCH 1/7] serial: 8250_dwlib: RS485 HW half duplex support
On Mon, 7 Mar 2022, Andy Shevchenko wrote:
> On Mon, Mar 07, 2022 at 08:18:54PM +0100, Lukas Wunner wrote:
> > On Mon, Mar 07, 2022 at 11:19:59AM +0200, Ilpo Järvinen wrote:
> > > On Mon, 7 Mar 2022, Andy Shevchenko wrote:
>
> ...
>
> > That's for DT platforms, but I suppose you've got ACPI. Not sure
> > how it's handled there, the ACPI 6.4 spec contains a "UART Serial Bus
> > Connection Resource Descriptor" but nothing on RS-485, so I guess
> > the only option is to use regular DT properties in a _DSD object?
>
> Which make me think that this series needs an additional patch to
> describe RS485 enumeration for ACPI case (somewhere in
> Documentation/firmware-guide/acpi/enumeration.rst IIRC the filename).
>
> ...
>
> > > I initially had additional version check here while developing this
> > > patch series but it seemed to not provide any added value due those
> > > other factors that need to be considered.
> >
> > Here's another idea:
> >
> > Read TCR register on ->probe. It's POR value is 0x6 if RS-485 is
> > supported by the chip, else 0x0. (Page 220 of the 4.01a spec says
> > UCV register does not exist if additional features are not implemented
> > and reading from this register address returns 0, I suppose the same
> > applies to TCR if RS-485 is not implemented.)
> >
> > Since the driver may change the polarity in the TCR register, be sure
> > to write 0x6 to it on ->remove so that you can still correctly detect
> > presence of the RS-485 feature after unbind/rebind of the driver.
>
> What to do in the case when DE pin is muxed to RTS and locked in pin control
> IP by firmware (no possibility to change the muxing in the OS)?
The SoC also has a pin to select between RS485 and RS232. With a combo
transceiver, TCR-based heuristic just runs into the same problems as the
version-based one did.
--
i.
Powered by blists - more mailing lists