> On 15. 07. 22, 13:52, Michael Walle wrote: > >> Seems we have the different understanding of the break_ctl(port,ctl) > >> callback. The original break_ctl(tty,-1) in lpuart will not send the > >> break signal until we call break_ctl(tty,0). > > > > That is not correct. The TX linue goes low as soon as the SBK bit is > > set. See below. > > In that case… > > >> Per my understanding of > >> "If ctl is nonzero, the break signal should be transmitted", call > >> break_ctl(tty,-1) is enough the send one break signal, now my patch > >> makes the behavior align with my understanding. > > > > As I said, Greg should clarify here. > > > > In any case, I've checked the hardware (LS1028A) and as soon as you > > set the SBK bit, the TX line goes low (TTL levels) as expected. It > > will go to high again as soon as you clear the bit again. > > > > So to me it seems there is nothing wrong here. Also have a look at man > > ioctl_tty: > > > > TIOCSBRK > > Turn break on, that is, start sending zero bits. > > > > TIOCCBRK > > Turn break off, that is, stop sending zero bits. > > > > So to send one break "character", you need to do ioctl(TIOCSBRK) > > followed by an ioctl(TIOCCBRK). > > … you're right. Hi Jiri and Michael, Per the understanding of the ioctl behavior here, does that mean the uart ops break_ctl(port,ctl) also perform the same behavior with ioctl_tty? break_ctl(port,-1) will turn the break on, which may keep TX line low until we call break_ctl(port,0) to turn break off, which may raise the TX line, right? If this is the correct understanding of break_ctl(port,ctl), then I will drop this patch, since my patch here cause the TX line only send one break signal(9 to 13 bits, or 12 to 15 bits if STAT[BRK13] is set). Thanks! Best regards Sherry > > regards, > -- > js
