lkml.org 
[lkml]   [2017]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Questions about bluetooth on N900
Hi,

On Sun, Oct 01, 2017 at 11:01:33AM +0200, Pavel Machek wrote:
> Hi!
>
> > > There is some interest. I'd like to have working bluetooth, and people from postmarketos
> > > would probably like something, too. Unfortunately my experience is same as yours -- current
> > > mainline does not work well on N900.
> >
> > I might try debugging that at some point, but I doubt I can resolve the issue,
> > because I have no experience in serial port programming. With latest BlueZ I
> > got my braille display working for few seconds, before it stalled.
> >
> > > > I'm considering to rebase the old hci_h4p driver on current mainline, because
> > > > I just need a working BT connection, not code that is of good quality. Some
> >
> > > Ok, I may save you some work. I have rebased version, it should be in
> > > linux-n900 on kernel.org.
> >
> > I found a repo from
> > https://kernel.googlesource.com/pub/scm/linux/kernel/git/pavel/linux-n900/. I
> > assume that's what you meant.
> >
> > The latest version is based on 4.13, but it has also some changes which seem
> > not to be related to BT. I incorporated them also, but I don't know if they
> > are valid.
>
> Feel free to take those or not.
>
> > I was lucky that you had done rebasing of nokia_h4p, because I wouldn't have
> > known what to do with DTS.
> >
> > Unfortunately the driver does not work properly. I can access N900 to some
> > extent with my braille display, but the connection has random freezes, and
> > accessing my GPS receiver (through RFCOMM) causes the whole system to hang.
> >
> > I get the following message to syslog something like 100 times per second when
> > BRLTTY (the braille display daemon) is communicating with the display:
> > Got IIR_RX_TIMEOUT, handling it as IIR_DRI
> >
> > Active BT connection also seems to trigger a bug in nokia_h4p related to
> > spinlocks. This happens in random intervals between 0.1 s and 30 s.
> >
> > The bugs are:
> > BUG: scheduling while atomic
> > and
> > BUG: workqueue leaked lock or atomic
> >
> > Stack traces suggest that it is (at least sometimes) caused by h4p_set_clk
> > calling clk_prepare_enable and clk_disable_unprepare functions, which should
> > only be used in non-atomic context.
> >
> > So, I thought it would be good for you to know that BT does not really work. I
> > would like to work on this, but I'm afraid my knowledge is too limited to
> > track this down. It would be good to know what is causing those IIR RX
> > timeouts.
> >
> > Also working on an obsolete driver feels like stupid now that there is a
> > driver written more properly.
>
> Yes, fixing obsolete driver is hard and has drawbacks. The new one
> should be fixed.
>
> I believe the way forward would be
>
> a) add logging to the old driver, to see exact data being exchanged
> during initialization.
>
> b) add logging to the new driver, and compare old and new driver
>
> c) fix the new driver to do the initialization same way the old driver
> did

FWIW I don't think the problem on N900 with hci_nokia ("new") driver is
related to incorrect data/packets being sent. I'm pretty sure there is
still some problem with the handling of flow control signals (RTS/CTS +
the GPIOs) resulting in packets not being sent and/or received properly.

-- Sebastian
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2017-10-01 16:51    [W:0.294 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site