On 06/10/22 11:51 am, Lukas Wunner wrote:
> On Tue, Oct 04, 2022 at 12:06:21PM +0300, Ilpo Järvinen wrote:
>> On Mon, 3 Oct 2022, Lukas Wunner wrote:
>>> On Wed, Sep 28, 2022 at 02:38:40PM +0300, Ilpo Järvinen wrote:
>>>> On Tue, 27 Sep 2022, Lukas Wunner wrote:
>>>>> @@ -1377,6 +1426,14 @@ static int omap8250_probe(struct platform_device *pdev)
>>>>> DEFAULT_CLK_SPEED);
>>>>> }
>>>>>
>>>>> + if (priv->habit & UART_HAS_NATIVE_RS485) {
>>>>> + up.port.rs485_config = omap8250_rs485_config;
>>>>> + } else {
>>>>> + up.port.rs485_config = serial8250_em485_config;
>>>>> + up.rs485_start_tx = serial8250_em485_start_tx;
>>>>> + up.rs485_stop_tx = serial8250_em485_stop_tx;
>>>>> + }
>>>>
>>>> I guess .rs485_supported shouldn't be equal in both cases?
>>>
>>> I contemplated whether it should be different for hardware-assisted
>>> RS485 but came to the conclusion that it shouldn't:
> [...]
>> Core is not handling just flags but also delay_rts_before_send and
>> delay_rts_after_send sanitization. See
>> uart_sanitize_serial_rs485_delays().
>>
>> Btw, you can also get rid of this line once you provide separate
>> rs485_supported:
>> rs485->delay_rts_before_send = 0;
>>
>> What to do with delay_rts_after_send seems bit trickier though. Looking
>> the code, it cannot be configured to arbitrary values by the user but it
>> might not be zero either after the driver touches it. Maybe it safer to
>> have it supported (set to 1) to avoid spuriously triggering the warning in
>> uart_sanitize_serial_rs485_delays() (e.g., during init if non-zero delay
>> is provided).
>
> If I understand Figure 12-276 on page 8783 of the AM65 TRM correctly,
> there appears to be a 1 bit clock delay between writing to the THR register
> and transmission of the start bit:
>
> https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf
>
> I intend to respin the patch with the following addition:
>
> fixed_delay_rts_before_send = 1 * MSEC_PER_SEC / baud;
>
> As a result, both delay_rts_before_send and delay_rts_after_send should be
> set to 1 in the rs485_supported struct for hardware-controlled RTS.
>
12.1.5.4.8.2.1 RS-485 External Transceiver Direction Control
The direction is determined by the hardware monitoring the TX FIFO and
the TX shift register. When both are empty the transceiver is set to RX.
There is a guard band delay
counter of **3 bit clock cycles** after the TX shift register is going
empty to allow time for the stop bit to
transition through the transceiver before a direction change to receive
might be applied.
So, RTS deasserts 3 cycle after stop bit. Shouldn't this be 3 baud cycles?
Really appreciate working on this feature, thanks!
Regards
Vignesh
