Re: Questions about bluetooth on N900

[Pavel Machek]

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

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

Attachment: signature.asc
Description: Digital signature