[PATCH 1/2] davinci: Support disabling modem status interrupts on SOC UARTS

[michael.williamson@criticallink.com (Michael Williamson)]

On 1/3/2011 1:21 AM, Nori, Sekhar wrote:

> Hi Michael,
> 
> On Sat, Jan 01, 2011 at 06:41:56, Michael Williamson wrote:
>> On the da850/omap-l138/am18x family of SoCs, up to three on chip UARTS may be
>> configured.  These peripherals support the standard Tx/Rx signals as well as
>> CTS/RTS hardware flow control signals.  The pins on these SOC's associated with
>> these signals are multiplexed; e.g., the pin providing UART0_TXD capability
>> also provides SPI0 chip select line 5 output capability.  The configuration of
>> the pin multiplexing occurs during platform initialization (or by earlier
>> bootloader operations).
>>
>> There is a problem with the multiplexing implementation on these SOCs.  Only
>> the output and output enable portions of the I/O section of the pin are
>> multiplexed.  All peripheral input functions remain connected to a given pin
>> regardless of configuration.
>>
>> In many configurations of these parts, providing a UART with Tx/Rx capability
>> is needed, but the HW flow control capability is not.  Furthermore, the pins
>> associated with the CTS inputs on these UARTS are often configured to support
>> a different peripheral, and they may be active/toggling during runtime.  This
>> can result in false modem status (CTS) interrupts being asserted to the 8250
>> driver controlling the associated Tx/Rx pins, and can impact system
>> performance.  This is especially true if the CTS pin is shared with something
>> like a clock line as is the case with UART1 CTS and the McASP AHCLKX.
>>
>> The 8250 serial driver platform data does not provide a direct mechanism to
>> tell the driver to disable modem status (i.e., CTS) interrupts for a given
>> port.  As a work-around, allow davinci platforms to override set_termios for
>> configured UARTS that do not provide a true CTS input and ensure any request
>> does not enable HW flow control.
>>
>> This patch was tested using a MityDSP-L138 SOM having UART1 enabled with the
>> associated CTS pin connected to a clock (configured for the AHCLKX function).
>>
>> Background / problem reports related to this issue are captured in the links
>> below:
>> http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/36701.aspx
>> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg19524.html
>>
>> Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
>> Tested-by: Michael Williamson <michael.williamson@criticallink.com>
>> ---
>> This patch is against davinci-linux.
>>
>> I'm open to suggestions for reducing the patch description.
>>
>> I'm open to alternatives to the solution below, outside of disabling the
>> UARTs in question as is done on the DA850 evm and the hawkboard (both
>> of which might be able to use this patch?).
> 
> Can you please CC linux-serial on this patch? Folks on that list
> will have ideas on how best to work around this issue.
> 
> I think setting the UART_BUG_NOMSR in up->bugs for these ports
> (as you previously implemented on your tree) is a better patch
> since it utilizes an existing established mechanism. 
> 
> I understand there is no existing way to pass the bugs through
> platform data, but may be that needs to be created (or may be
> have a new port type for "DaVinci UART with no flow control" and
> then setup up->bugs after checking for this port type).
> 


I will post to linux-serial and see what their take is on this issue.

Thanks for the comments.

-Mike