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
Attachment:
signature.asc
Description: PGP signature
