Re: [PATCH] serial: 8250: 8250_omap: Support native RS485

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 04/10/22 7:15 pm, Bin Liu wrote:
> Hi,
> 
> On Mon, Oct 03, 2022 at 09:42:24PM +0200, Lukas Wunner wrote:
>> On Mon, Oct 03, 2022 at 10:10:59AM -0500, Bin Liu wrote:
>>> On Tue, Sep 27, 2022 at 02:10:01PM +0200, Lukas Wunner wrote:
>>>> Recent TI Sitara SoCs such as AM64/AM65 have gained the ability to
>>>> automatically assert RTS when data is transmitted, obviating the need
>>>> to emulate this functionality in software.
>>>>
>>>> The feature is controlled through new DIR_EN and DIR_POL bits in the
>>>> Mode Definition Register 3.  For details see page 8783 and 8890 of the
>>>> AM65 TRM:  https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf
>> [...]
>>>> -	if (up->port.rs485.flags & SER_RS485_ENABLED)
>>>> +	if (priv->habit & UART_HAS_NATIVE_RS485)
>>>> +		serial_out(up, UART_OMAP_MDR3, priv->mdr3);
>>>
>>> This makes the NATIVE_RS485 always used if the SoC supports it, but
>>>
>>>> +	else if (up->port.rs485.flags & SER_RS485_ENABLED)
>>>>  		serial8250_em485_stop_tx(up);
>>>
>>> there are cases em485 should be used even if SoC supports NATIVE_RS485.
>>> For example:
>>> - the design has pinmux conflict and the RTS pin has to be used for
>>>   something else. Then a GPIO pin would be used for RS485 DE control;
>>> - the design requires customized delay_rts_before_send or
>>>   delay_rts_after_send which NATIVE_RS485 doesn't support;
>>>
>>> So we might need an option for such usecases. A device tree flag?
>>
>> I expect those cases to be rare, hence do not see the need to
> 
> Maybe rare, but I know some projects use GPIO for DE control.
> 
>> address them right from the start.  Support for falling back
> 
> So I think missing it is a regression, because this patch forces to
> use the RTS pin for DE control, this breaks the existing projects which
> use GPIO for RTS/DE or have customized delay_rts_{before,after}_send.

I agree with Bin. This patch as such can break DTs which intend to use
GPIO based DE.
Quick fix would be to simply look for presence of rts-gpios property in
DT, if so fallback to registering serial8250_em485_*. This should avoid
regressing DTs using GPIO for DE control.

Regards
Vignesh




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux