Hi!

It seems this commit

commit 7a56aa45982bb87bfca98a2832b5ae782c03364a
Author: Yegor Yefremov <yegor_sub1@visionsystems.de>
Date:   Wed Jun 16 16:29:55 2010 +0200

    serial: add UART_CAP_EFR and UART_CAP_SLEEP flags to 16C950 UARTs
definition

    Adding UART_CAP_EFR and UART_CAP_SLEEP flags will enable sleep
mode
    and automatic CTS flow control for 16C950 UARTs. It will also
avoid
    capabilities detection warning like this:

    "ttyS0: detected caps 00000700 should be 00000100"

    Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

...is responsible for my bluetooth problems on zaurus -- at least
bisect pointed to it,  as I use 16C950-based bluetooth card, it seems
very logical. I'll try 2.6.37-rc8 with that patch reverted...

See https://bugzilla.kernel.org/show_bug.cgi?id=17061  .

								Pavel

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 09ef570..bc8ed4b 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -241,7 +241,7 @@ static const struct serial8250_config uart_config[] = {
 		.fifo_size	= 128,
 		.tx_loadsz	= 128,
 		.fcr		= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
-		.flags		= UART_CAP_FIFO,
+		.flags		= UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
 	},
 	[PORT_16654] = {
 		.name		= "ST16654",

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]

And yes, 37-rc8 with that reverted results in working bluetooth, so
yrs, that patch is responsible.


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]

could you tell, what kind of problem you're encountering and if you
could tell, which flag UART_CAP_EFR or UART_CAP_SLEEP causes the
problem?

Yegor
--

[ message continues ]

Bluetooth will not work with 'tx command timeout', details should be
in bugzilla.

CAP_EFR seems to cause the problem.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]

Aside from sleep functions the only impact CAP_EFR makes is enabling
automatic CTS flow control. Below the cite from 16C950 data sheet:

"EFR[7]: Enable automatic CTS flow control.
logic 0 ⇒   CTS flow control is disabled (default).
logic 1 ⇒   CTS flow control is enabled in Enhanced mode
(i.e. EFR[4] = 1), where the data transmission is
prevented  whenever  the  CTS#  pin  is  held
inactive high. 650 and 950-mode drivers should
use  this  bit  to  enable  CTS  flow  control.    750
mode drivers should use MCR[5].

When automatic CTS flow control is enabled and the CTS#
input becomes active, the UART will disable transmission
as soon as any current character transmission is complete.
Transmission   is   resumed   whenever   the   CTS#   input
becomes inactive. "

I've tested with such an UART and transmitted some chunk of data with
and without RTS/CTS flow control enabled at 460800 b/s. The test
showed that in enabled state all data was transmitted correctly.
Without RTS/CTS flow control enabled there was massive data loss, as
expected. So the flow control function seems to work correctly.

Regards,
Yegor
--

[ message continues ]