From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter@hurleysoftware.com (Peter Hurley) Date: Fri, 15 Jan 2016 15:55:58 -0800 Subject: GPIO-driven RTS on TI hardware with 8250_omap driver In-Reply-To: References: Message-ID: <5699870E.8080804@hurleysoftware.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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, ????? ??????? 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753286AbcAOX4E (ORCPT ); Fri, 15 Jan 2016 18:56:04 -0500 Received: from mail-pf0-f177.google.com ([209.85.192.177]:34323 "EHLO mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750997AbcAOX4C (ORCPT ); Fri, 15 Jan 2016 18:56:02 -0500 Subject: Re: GPIO-driven RTS on TI hardware with 8250_omap driver To: =?UTF-8?B?0JjQu9GM0Y/RgSDQk9Cw0YHQsNC90L7Qsg==?= , "Matwey V. Kornilov" References: Cc: Andy Shevchenko , Russell King , "linux-kernel@vger.kernel.org" , linux-arm Mailing List From: Peter Hurley Message-ID: <5699870E.8080804@hurleysoftware.com> Date: Fri, 15 Jan 2016 15:55:58 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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, Ильяс Гасанов 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