Re: [PATCH v3 00/12] Add RS485 support to DW UART

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

On Sun, 24 Apr 2022, Vicente Bergas wrote:

> Hi Ilpo, thank you for your quick reply with a solution!
> 
> On Fri, Apr 22, 2022 at 3:07 PM Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> >
> > On Fri, 22 Apr 2022, Ilpo Järvinen wrote:
> >
> > > On Thu, 21 Apr 2022, Vicente Bergas wrote:
> > >
> > > > 1.- rs485_stop_tx is never called because there are no interrupts.
> > > > I worked around this by disabling DMA:
> > >
> > > I'll need to look into this.
> >
> > 8250 DMA tx complete path lacks calls to normal 8250 stop handling and
> > I think it probably also assumes too much from dmaengine's completion
> > callback. ...It also seems bit early to call serial8250_rpm_put_tx from
> > there(?).
> >
> > This patch allowed em485_start/stop_tx to be called in my tests:
> > [PATCH 1/1] serial: 8250: use THRE & __stop_tx also with DMA
> 
> I confirm that this patch fixes the issue when DMA is enabled.
> 
> I also confirm that your other patch
> > +                       stop_delay = p->port.frame_time + DIV_ROUND_UP(p->port.frame_time, 7);
> fixes the issue with RTS/DriverEnable deassertion time.
> I've tested it again at 19200e1 and now RTS is deasserted
> approximately at the same time as the end of the stop bit.
> Please, note the "e" for even parity bit, that extra bit after the
> data byte might have an impact on this timings.

Great, thanks again for testing.

I don't think that parity "e" makes the calculations incorrect as parity 
bit should be taken into account in tty_get_frame_size(). My guess is it's 
more about whether THRE might get asserted already during the stop bit or 
only after the stop bit has been fully sent.


-- 
 i.