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@xxxxxxxxxxxxxxx> 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.
