zaurus bluetooth regression

Hi!

It seems this commit

commit 7a56aa45982bb87bfca98a2832b5ae782c03364a
Author: Yegor Yefremov [off-list ref]
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 [off-list ref]
    Signed-off-by: Greg Kroah-Hartman [off-list ref]

...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

Hi!

It seems this commit

commit 7a56aa45982bb87bfca98a2832b5ae782c03364a

...

...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...

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

								Pavel

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

Hi Pavel,

quoted

It seems this commit

commit 7a56aa45982bb87bfca98a2832b5ae782c03364a

...

quoted

...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...

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

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

Hi!

quoted

quoted

It seems this commit

commit 7a56aa45982bb87bfca98a2832b5ae782c03364a

...

quoted

...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...

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

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?

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

quoted

quoted

quoted

It seems this commit

commit 7a56aa45982bb87bfca98a2832b5ae782c03364a

...

quoted

...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...

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

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?

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

CAP_EFR seems to cause the problem.

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