* Re: GPIO-driven RTS on TI hardware with 8250_omap driver
@ 2015-12-27 12:47 ` Andy Shevchenko
0 siblings, 0 replies; 12+ messages in thread
From: Andy Shevchenko @ 2015-12-27 12:47 UTC (permalink / raw)
To: Ильяс Гасанов,
Peter Hurley, Matwey V. Kornilov, Russell King
Cc: linux-kernel@vger.kernel.org, linux-arm Mailing List
+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
^ permalink raw reply [flat|nested] 12+ messages in thread
* GPIO-driven RTS on TI hardware with 8250_omap driver
2015-12-27 12:47 ` Andy Shevchenko
@ 2015-12-27 13:14 ` Matwey V. Kornilov
-1 siblings, 0 replies; 12+ messages in thread
From: Matwey V. Kornilov @ 2015-12-27 13:14 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GPIO-driven RTS on TI hardware with 8250_omap driver
@ 2015-12-27 13:14 ` Matwey V. Kornilov
0 siblings, 0 replies; 12+ messages in thread
From: Matwey V. Kornilov @ 2015-12-27 13:14 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Ильяс Гасанов,
Peter Hurley, Russell King, linux-kernel@vger.kernel.org,
linux-arm Mailing List
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* GPIO-driven RTS on TI hardware with 8250_omap driver
2015-12-27 13:14 ` Matwey V. Kornilov
@ 2015-12-27 13:43 ` Ильяс Гасанов
-1 siblings, 0 replies; 12+ messages in thread
From: Ильяс Гасанов @ 2015-12-27 13:43 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GPIO-driven RTS on TI hardware with 8250_omap driver
@ 2015-12-27 13:43 ` Ильяс Гасанов
0 siblings, 0 replies; 12+ messages in thread
From: Ильяс Гасанов @ 2015-12-27 13:43 UTC (permalink / raw)
To: Matwey V. Kornilov
Cc: Andy Shevchenko, Peter Hurley, Russell King, linux-kernel,
linux-arm Mailing List
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* GPIO-driven RTS on TI hardware with 8250_omap driver
2015-12-27 12:47 ` Andy Shevchenko
@ 2016-01-15 23:55 ` Peter Hurley
-1 siblings, 0 replies; 12+ messages in thread
From: Peter Hurley @ 2016-01-15 23:55 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GPIO-driven RTS on TI hardware with 8250_omap driver
@ 2016-01-15 23:55 ` Peter Hurley
0 siblings, 0 replies; 12+ messages in thread
From: Peter Hurley @ 2016-01-15 23:55 UTC (permalink / raw)
To: Ильяс Гасанов,
Matwey V. Kornilov
Cc: Andy Shevchenko, Russell King, linux-kernel@vger.kernel.org,
linux-arm Mailing List
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* GPIO-driven RTS on TI hardware with 8250_omap driver
2016-01-15 23:55 ` Peter Hurley
@ 2016-02-08 7:35 ` Ильяс Гасанов
-1 siblings, 0 replies; 12+ messages in thread
From: Ильяс Гасанов @ 2016-02-08 7:35 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GPIO-driven RTS on TI hardware with 8250_omap driver
@ 2016-02-08 7:35 ` Ильяс Гасанов
0 siblings, 0 replies; 12+ messages in thread
From: Ильяс Гасанов @ 2016-02-08 7:35 UTC (permalink / raw)
To: Peter Hurley
Cc: Matwey V. Kornilov, Andy Shevchenko, Russell King,
linux-kernel@vger.kernel.org, linux-arm Mailing List
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.
^ permalink raw reply [flat|nested] 12+ messages in thread