> Subject: Re: [PATCH 2/2] tty: serial: fsl_lpuart: writing a 1 and then a 0 to > trigger a break character > > Hi, > > Am 2022-07-15 04:59, schrieb Sherry Sun: > > According to the lpuart reference manual, need to writing a 1 and then > > a > > 0 to the UARTCTRL_SBK field queues a break character in the transmit > > data stream. Only writing a 1 cannot trigger the break character, so > > fix it. > > I don't think this is correct. The tty core will already call this: > .break_ctl(port, 1) > usleep() > .break_ctl(port, 0) > > So you'll have your 1->0 transition. > > My RM from the LS1028A says the following: > > | Writing a 1 and then a 0 to SBK queues a break character in the > | transmit data stream. Additional break characters of 10 to 13, or 13 > | to 16 if LPUART_STATBRK13] is set, bit times of logic 0 are queued as > | long as SBK is set. Depending on the timing of the set and clear of > | SBK relative to the information currently being transmitted, a second > | break character may be queued before software clears SBK. > > To me it seems that setting the SBK bit just pulls the TX line low and releasing > it will return to normal transmitter mode. > Hi Michael, Actually set break_ctl(tty, -1) then break_ctl(tty, 0) is only done in the send_break() function. If we call TIOCSBRK from user space, it will only set break_ctl(tty, -1) without break_ctl(tty, 0). And from the definition of .break_ctl(port,ctl), the callback is used to Control the transmission of a break signal(Documentation/driver-api/serial/driver.rst), if ctl is nonzero, it should queues a break character. I don't think it is reasonable to call break_ctl() twice in order to send one break signal. Also I have tried other uart IP, such as drivers/tty/serial/imx.c, it also queues a break character if we call break_ctl() once. So I believe the break_ctl() in lpuart driver should be fixed. Best regards Sherry
