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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171001/5665a0f4/attachment-0001.sig>