partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]

[Sebastian Reichel]

Hi Tony,

On Wed, Dec 14, 2016 at 07:10:56AM -0800, Tony Lindgren wrote:
> * Sebastian Reichel <sre at kernel.org> [161214 05:32]:
> > Hi Pali & Pavel,
> > 
> > On Wed, Dec 14, 2016 at 01:53:23PM +0100, Pavel Machek wrote:
> > > > > [  220.248596] tty ttyO1: Radio packet sent
> > > > > [  220.249328] Bluetooth: hci0: Frame reassembly failed (-84)
> > > > > [  220.272949] tty ttyO1: wakeup received: 1 -> 0
> > > > > [  221.283477] tty ttyO1: radio packet timeout!
> > > > > [  221.283630] enqueue: hu c304cc80 skb cd4a9b40
> > > > > [  223.363372] Bluetooth: hci0 command 0xfc18 tx timeout
> > > > > pavel at n900:~$
> > > > 
> > > > In log are still some failures, but ... is bluetooth working now?
> > 
> > I could scan for devices. The code is still racy, though. It's
> > most likely related to the newly introduced idle code. (Without
> > sending the BT module to correctly idle the bcm2048 does not
> > work correctly at all)
> > 
> > I was quite busy the last few weeks and did not manage to find
> > much time for kernel work. Now I will first have to catch up
> > with my power-supply tree.
> > 
> > > It is... for Sebastian. I'm playing with camera now.
> > > 
> > > > I see that you applied this patch: 
> > > > https://git.kernel.org/cgit/linux/kernel/git/pavel/linux-n900.git/commit/?id=051aa3fbf03ac770d8344690f5a936a7f04c6884
> > > > 
> > > > Looks like that pinmux is in DTS file incorrect. Can somebody verify it? 
> > > > Maybe Tony?
> > > 
> > > Yes, it is. Sebastian was pretty certain about that.
> > 
> > Yes, I'm certain. The bootloader enables the pullup resistors.
> > Note, that the wrong DTS entry is not in mainline. My bluetooth
> > branch has a fixed DTS patch instead of a fixup patch on top of
> > the broken one:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/commit/?h=nokia-bluetooth-dev&id=6b63c111a979d100cfbdd76cb4a6bbadace35216
> 
> Maybe send it so we can merge it as a fix during the early -rc
> cycle?

Sorry if I was not clear enough: mainline does *not* contain
incorrect DT information. My bluetooth RFC patches did. So
this can go into the kernel once the driver is there and
the binding got accepted.

Alternatively I can prepare a patch, which just adds the
cts/rts pinmux for the bluetooth UART, but it's not very
useful on its own.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/5d0c089d/attachment.sig>