On 06/10/22 12:46 pm, Vignesh Raghavendra wrote:
>
>
> 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?
>
Oops 3 cycles is for delay_rts_after_send.. 1 cycle for
delay_rts_before_send sounds good to me. sorry for the noise
Regards
Vignesh
