Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1298234 > unrolled thread

GPIO-driven RTS on TI hardware with 8250_omap driver

Back to article view | Back to linux.kernel

Contents

  GPIO-driven RTS on TI hardware with 8250_omap driver Ильяс Гасанов   <torso.nafi@gmail.com> - 2015-12-26 17:20 +0100
    Re: GPIO-driven RTS on TI hardware with 8250_omap driver Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-12-27 13:50 +0100
      Re: GPIO-driven RTS on TI hardware with 8250_omap driver "Matwey V. Kornilov" <matwey@sai.msu.ru> - 2015-12-27 14:20 +0100
        Re: GPIO-driven RTS on TI hardware with 8250_omap driver Ильяс Гасанов   <torso.nafi@gmail.com> - 2015-12-27 14:50 +0100

#1298234 — 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.
--
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/

[toc] | [next] | [standalone]

#1298369

+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
--
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/

[toc] | [prev] | [next] | [standalone]

#1298376

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1298397

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.
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web