GPIO-driven RTS on TI hardware with 8250_omap driver

GPIO-driven RTS on TI hardware with 8250_omap driver

[Ильяс Гасанов]

Hello.

We are upgrading to the 4.1.x kernel for our smart metering appliance
project, which is based on TI's Sitara hardware (AM335x SoC), and I
decided to switch from omap-serial legacy driver to the newer
8250-based one. It marginally increases throughput efficiency, CPU
cycle wise, among other goodies, but I'm looking to implement a rather
important feature that is present in the legacy driver, but the newer
one is lacking.

Namely, our project makes use of RS232<->RS485 converters, which in
turn need to consume RTS signals to switch between Rx and Tx modes at
the RS485 side, due to the bus variant we use being half-duplex.
However, the already manufactured hardware is already designed to make
the use of certain pins to take the RTS signal from, which can only be
configured as GPIO for that purpose (in other words, no "native" UART
RTS) - and basically redesigning the h/w configuration now is
definitely out of question. The omap-serial driver already provides
FDT options for that, named "rts-gpio", "rs485-rts-active-high" etc.

As far as I could ascertain, the 8250_omap driver (as well as the 8250
framework itself) at the moment lacks the means to make use of GPIO
pins for that purpose. While trying to implement it myself, I noticed
that the legacy driver has it made in a comparably straightforward
approach, via dispatching the code to switch the pin in its .start_tx
and .stop_tx handlers, and some timing adjustments. Unfortunately, the
situation with 8250-based drivers is different - the aforementioned
handlers are provided by the 8250_core module and are common for all
drivers within the framework.

At first, I thought that implementing such feature for the 8250
framework itself sounds like a good idea, but after reading this
particular post:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271377.html
I decided to comply with the point of view specified there. However,
I'm not that familiar with the 8250 framework internals (or serial
internals at all, for that matter), and my time is quite short, so I
would appreciate much any useful directions on how to do it
hardware-specific style, which functions/structs/handlers to use, etc.
Of particular interest is the following part:

> I don't care whether the drive does it via serial_out magic or a more explicit hook but it doesn't belong here in core code.

Any ideas/clarifications on what might be meant on that part?

Regards,
Ilyas G.

Re: GPIO-driven RTS on TI hardware with 8250_omap driver

[Andy Shevchenko]

+Peter, Russell, and Matwey.

I suggest you to ask people I added to the Cc list.

On Sat, Dec 26, 2015 at 6:17 PM, Ильяс Гасанов <torso.nafi@gmail.com> wrote:
> Hello.
>
> We are upgrading to the 4.1.x kernel for our smart metering appliance
> project, which is based on TI's Sitara hardware (AM335x SoC), and I
> decided to switch from omap-serial legacy driver to the newer
> 8250-based one. It marginally increases throughput efficiency, CPU
> cycle wise, among other goodies, but I'm looking to implement a rather
> important feature that is present in the legacy driver, but the newer
> one is lacking.
>
> Namely, our project makes use of RS232<->RS485 converters, which in
> turn need to consume RTS signals to switch between Rx and Tx modes at
> the RS485 side, due to the bus variant we use being half-duplex.
> However, the already manufactured hardware is already designed to make
> the use of certain pins to take the RTS signal from, which can only be
> configured as GPIO for that purpose (in other words, no "native" UART
> RTS) - and basically redesigning the h/w configuration now is
> definitely out of question. The omap-serial driver already provides
> FDT options for that, named "rts-gpio", "rs485-rts-active-high" etc.
>
> As far as I could ascertain, the 8250_omap driver (as well as the 8250
> framework itself) at the moment lacks the means to make use of GPIO
> pins for that purpose. While trying to implement it myself, I noticed
> that the legacy driver has it made in a comparably straightforward
> approach, via dispatching the code to switch the pin in its .start_tx
> and .stop_tx handlers, and some timing adjustments. Unfortunately, the
> situation with 8250-based drivers is different - the aforementioned
> handlers are provided by the 8250_core module and are common for all
> drivers within the framework.
>
> At first, I thought that implementing such feature for the 8250
> framework itself sounds like a good idea, but after reading this
> particular post:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271377.html
> I decided to comply with the point of view specified there. However,
> I'm not that familiar with the 8250 framework internals (or serial
> internals at all, for that matter), and my time is quite short, so I
> would appreciate much any useful directions on how to do it
> hardware-specific style, which functions/structs/handlers to use, etc.
> Of particular interest is the following part:
>
>> I don't care whether the drive does it via serial_out magic or a more explicit hook but it doesn't belong here in core code.
>
> Any ideas/clarifications on what might be meant on that part?
>
> Regards,
> Ilyas G.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
With Best Regards,
Andy Shevchenko

Re: GPIO-driven RTS on TI hardware with 8250_omap driver

[Matwey V. Kornilov]

Andy,

The half of what is described here are implemented in my patches.
But I cannot understand the other half. Each of six AM335x UARTs has
RTS/CTS pins which are controlled by pinmux in device tree, no magic
required here.


2015-12-27 15:47 GMT+03:00 Andy Shevchenko <andy.shevchenko@gmail.com>:
> +Peter, Russell, and Matwey.
>
> I suggest you to ask people I added to the Cc list.
>
> On Sat, Dec 26, 2015 at 6:17 PM, Ильяс Гасанов <torso.nafi@gmail.com> wrote:
>> Hello.
>>
>> We are upgrading to the 4.1.x kernel for our smart metering appliance
>> project, which is based on TI's Sitara hardware (AM335x SoC), and I
>> decided to switch from omap-serial legacy driver to the newer
>> 8250-based one. It marginally increases throughput efficiency, CPU
>> cycle wise, among other goodies, but I'm looking to implement a rather
>> important feature that is present in the legacy driver, but the newer
>> one is lacking.
>>
>> Namely, our project makes use of RS232<->RS485 converters, which in
>> turn need to consume RTS signals to switch between Rx and Tx modes at
>> the RS485 side, due to the bus variant we use being half-duplex.
>> However, the already manufactured hardware is already designed to make
>> the use of certain pins to take the RTS signal from, which can only be
>> configured as GPIO for that purpose (in other words, no "native" UART
>> RTS) - and basically redesigning the h/w configuration now is
>> definitely out of question. The omap-serial driver already provides
>> FDT options for that, named "rts-gpio", "rs485-rts-active-high" etc.
>>
>> As far as I could ascertain, the 8250_omap driver (as well as the 8250
>> framework itself) at the moment lacks the means to make use of GPIO
>> pins for that purpose. While trying to implement it myself, I noticed
>> that the legacy driver has it made in a comparably straightforward
>> approach, via dispatching the code to switch the pin in its .start_tx
>> and .stop_tx handlers, and some timing adjustments. Unfortunately, the
>> situation with 8250-based drivers is different - the aforementioned
>> handlers are provided by the 8250_core module and are common for all
>> drivers within the framework.
>>
>> At first, I thought that implementing such feature for the 8250
>> framework itself sounds like a good idea, but after reading this
>> particular post:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271377.html
>> I decided to comply with the point of view specified there. However,
>> I'm not that familiar with the 8250 framework internals (or serial
>> internals at all, for that matter), and my time is quite short, so I
>> would appreciate much any useful directions on how to do it
>> hardware-specific style, which functions/structs/handlers to use, etc.
>> Of particular interest is the following part:
>>
>>> I don't care whether the drive does it via serial_out magic or a more explicit hook but it doesn't belong here in core code.
>>
>> Any ideas/clarifications on what might be meant on that part?
>>
>> Regards,
>> Ilyas G.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: GPIO-driven RTS on TI hardware with 8250_omap driver

[Ильяс Гасанов]

Hi Matwey,

2015-12-27 16:14 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> The half of what is described here are implemented in my patches.
> But I cannot understand the other half. Each of six AM335x UARTs has
> RTS/CTS pins which are controlled by pinmux in device tree, no magic
> required here.

The problem here is, the appliance schematics are already designed in
such way that pins which can be configured as "native" RTS are not
used for RS485 control - the ones that are though may only be used as
GPIO flipped by software on transmission start/end for that purpose.
We simply cannot change the schematics on production because of this
issue alone.

Regards,
Ilyas G.

Re: GPIO-driven RTS on TI hardware with 8250_omap driver

[Peter Hurley]

On 12/27/2015 04:47 AM, Andy Shevchenko wrote:
> +Peter, Russell, and Matwey.
> 
> I suggest you to ask people I added to the Cc list.
> 
> On Sat, Dec 26, 2015 at 6:17 PM, Ильяс Гасанов <torso.nafi@gmail.com> wrote:
>> Hello.
>>
>> We are upgrading to the 4.1.x kernel for our smart metering appliance
>> project, which is based on TI's Sitara hardware (AM335x SoC), and I
>> decided to switch from omap-serial legacy driver to the newer
>> 8250-based one. It marginally increases throughput efficiency, CPU
>> cycle wise, among other goodies, but I'm looking to implement a rather
>> important feature that is present in the legacy driver, but the newer
>> one is lacking.
>>
>> Namely, our project makes use of RS232<->RS485 converters, which in
>> turn need to consume RTS signals to switch between Rx and Tx modes at
>> the RS485 side, due to the bus variant we use being half-duplex.
>> However, the already manufactured hardware is already designed to make
>> the use of certain pins to take the RTS signal from, which can only be
>> configured as GPIO for that purpose (in other words, no "native" UART
>> RTS) - and basically redesigning the h/w configuration now is
>> definitely out of question. The omap-serial driver already provides
>> FDT options for that, named "rts-gpio", "rs485-rts-active-high" etc.
>>
>> As far as I could ascertain, the 8250_omap driver (as well as the 8250
>> framework itself) at the moment lacks the means to make use of GPIO
>> pins for that purpose. While trying to implement it myself, I noticed
>> that the legacy driver has it made in a comparably straightforward
>> approach, via dispatching the code to switch the pin in its .start_tx
>> and .stop_tx handlers, and some timing adjustments. Unfortunately, the
>> situation with 8250-based drivers is different - the aforementioned
>> handlers are provided by the 8250_core module and are common for all
>> drivers within the framework.
>>
>> At first, I thought that implementing such feature for the 8250
>> framework itself sounds like a good idea, but after reading this
>> particular post:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271377.html
>> I decided to comply with the point of view specified there. However,
>> I'm not that familiar with the 8250 framework internals (or serial
>> internals at all, for that matter), and my time is quite short, so I
>> would appreciate much any useful directions on how to do it
>> hardware-specific style, which functions/structs/handlers to use, etc.

Please use the helpers in serial_mctrl_gpio.c if you try this.

And please build on top of Matwey's patches, as those will likely be
the rs485 implementation for the 8250_omap driver soon.


>> Of particular interest is the following part:
>>
>>> I don't care whether the drive does it via serial_out magic or a more explicit hook but it doesn't belong here in core code.
>>
>> Any ideas/clarifications on what might be meant on that part?

What Alan means here is encapsulate gpio-as-RTS where RTS is actually
read/written rather than all over the the code.

Regards,
Peter Hurley

Re: GPIO-driven RTS on TI hardware with 8250_omap driver

[Ильяс Гасанов]

Hello,

2016-01-16 2:55 GMT+03:00 Peter Hurley <peter@hurleysoftware.com>:
> Please use the helpers in serial_mctrl_gpio.c if you try this.
>
> And please build on top of Matwey's patches, as those will likely be
> the rs485 implementation for the 8250_omap driver soon.

As far as I understand, since em485 callbacks are invoked by timers,
the code is to be executed in atomic context. However certain GPIO
controllers (particularly the OMAP-based one which is used on our
AM335x) require the use of the gpio_*_cansleep() functions, and cannot
work with the atomic-friendly non-cansleep ones. Do the aforementioned
helpers in serial_mctrl_gpio.c address this issue?

Regards,
Ilyas G.