public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 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