* Re: s3c24xx : TIOCM_CTS handling problem [not found] <48D242DC.30102@parrot.com> @ 2008-12-16 13:43 ` Matthieu CASTET 2008-12-16 14:15 ` Alan Cox 0 siblings, 1 reply; 3+ messages in thread From: Matthieu CASTET @ 2008-12-16 13:43 UTC (permalink / raw) Cc: linux-serial, Ben Dooks, linux-kernel Matthieu CASTET a écrit : > Hi, > > there is a problem in samsung soc serial driver with the report of > TIOCM_CTS in get_mctrl. > > The uart layer check the status of the TIOCM_CTS in the open or > set_termios function and cache the result in the tty->hw_stopped flag. > > Then when sending data, in the function uart_start, it check > tty->hw_stopped flag before calling the start_tx uart driver callback. > > > For the samsung uart driver it means : > - if the other side is not connected or in a reset state, then CTS > signal is not activated > - we open and configure the uart. get_mctrl don't report TIOCM_CTS flag. > uart layer set tty->hw_stopped flag. > - we connect or start the other side. CTS signal become activated. > - we send some characters on the uart. This call uart_write which fill > uart tx queue and call uart_start. uart_start doesn't call driver > start_tx because tty->hw_stopped flag is set. > - because driver start_tx is never call, the data is never send on the uart. > >>From what I see, working driver managing TIOCM_CTS flag (amba-pl011, > 8250), call uart_handle_cts_change when the uart driver detect a CTS > signal change (via a interrupt). > > Because the samsung controller doesn't generate an interrupt when CTS > signal change, we can't call uart_handle_cts_change. > > And easy fix could be to always report TIOCM_CTS. > Ping ? The bug is still present on git tree and I have got no replies. Matthieu ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: s3c24xx : TIOCM_CTS handling problem 2008-12-16 13:43 ` s3c24xx : TIOCM_CTS handling problem Matthieu CASTET @ 2008-12-16 14:15 ` Alan Cox 2008-12-17 13:27 ` Matthieu CASTET 0 siblings, 1 reply; 3+ messages in thread From: Alan Cox @ 2008-12-16 14:15 UTC (permalink / raw) To: Matthieu CASTET; +Cc: linux-serial, Ben Dooks, linux-kernel > > And easy fix could be to always report TIOCM_CTS. > > > Ping ? > > The bug is still present on git tree and I have got no replies. Send patches instead then ;) If the chip can sense the CTS line then you could check on a timer event but it might be cleaner to add the functionality needed to allow a driver to say "always call my start_tx" method. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: s3c24xx : TIOCM_CTS handling problem 2008-12-16 14:15 ` Alan Cox @ 2008-12-17 13:27 ` Matthieu CASTET 0 siblings, 0 replies; 3+ messages in thread From: Matthieu CASTET @ 2008-12-17 13:27 UTC (permalink / raw) To: Alan Cox; +Cc: linux-serial, Ben Dooks, linux-kernel Hi Alan, Alan Cox a écrit : >>> And easy fix could be to always report TIOCM_CTS. >>> >> Ping ? >> >> The bug is still present on git tree and I have got no replies. > > Send patches instead then ;) > > If the chip can sense the CTS line then you could check on a timer event May be it could be usefull to do something generic that call driver get_mctrl instead of doing it in the driver (like it is done in bfin_5xx, sa1100, ...) > but it might be cleaner to add the functionality needed to allow a driver > to say "always call my start_tx" method. Or to say "recheck get_mctrl before my start_tx). But have you got an idea how the driver could ask that to the serial core ? flags in struct uart_port seems full. Matthieu ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-12-17 13:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <48D242DC.30102@parrot.com>
2008-12-16 13:43 ` s3c24xx : TIOCM_CTS handling problem Matthieu CASTET
2008-12-16 14:15 ` Alan Cox
2008-12-17 13:27 ` Matthieu CASTET
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox