[Pkg-n900-maint] Packaging phone functionality for Debian/N900

[Pali Rohár]

On Friday 12 August 2016 23:19:14 Pavel Machek wrote:
> On Mon 2016-07-25 23:57:53, Sebastian Reichel wrote:
> > On Mon, Jul 25, 2016 at 04:50:55PM +0200, Pali Rohár wrote:
> > > On Friday 22 July 2016 00:52:58 Sebastian Reichel wrote:
> > > > On Thu, Jul 21, 2016 at 11:55:51PM +0200, Pali Rohár wrote:
> > > > > On Thursday 21 July 2016 23:46:31 Sebastian Reichel wrote:
> > > > > > On Thu, Jul 21, 2016 at 08:51:08AM +0200, Pavel Machek
> > > > > > wrote:
> > > > > > > First, thanks for the great project. Debian is usable on
> > > > > > > N900 now.
> > > > > > 
> > > > > > From the kernel-side cameras and bluetooth are still
> > > > > > missing, though. I got my H4+ driver working on N950 last
> > > > > > week. It's still broken on N900, though (if you are
> > > > > > curious search for "This fails on N900" in
> > > > > > drivers/bluetooth/hci_h4p.c). My current guess is, that
> > > > > > the bcm2048 requires more carful flow control handling.
> > > > > > 
> > > > > > https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900
> > > > > > .git/log/? h=n950-bluetooth
> > > > > 
> > > > > Maybe add extensive logging of what is sending via uart and
> > > > > compare old working Pavel's driver with your new?
> > > > > Or some timing issue?
> > > > 
> > > > I did that already quite some time ago before I had the N950
> > > > and nothing interesting came up. "06 0a 00 a1 01 00 00 4c 00
> > > > 96 00 00" is the very first packet being send by both drivers.
> > > > The working N950 proves, that the correct bytes are being sent
> > > > (the negotiation packet is the same for N900 and N950).
> > > > 
> > > > I can also rule incorrect RTS/CTS behaviour after reset
> > > > resulting in possible stale byte, since the bcm2048 answers
> > > > alive check packets.
> > > > 
> > > > Next thought was, that maybe the new driver is sending to fast,
> > > > but the error is already being sent after the first three
> > > > bytes. Since the alive check works and is 4 bytes, that can
> > > > also be ruled out. (and that should not happen with flow
> > > > control anyways)
> > > > 
> > > > Suspicious is, that the error is sent after the first byte of a
> > > > u16 value. So the data may be sent too slow. I doubt that,
> > > > though. The omap3-serial module has a 64 byte transmission
> > > > FIFO, which is big enough to handle all of the bytes.
> > > > Unfortunately the serial lines cannot easily be probed with an
> > > > oscilloscope. *That* would be really helpful.
> > > > 
> > > > I also contacted Ville Tervo last week, but he did not remember
> > > > such a problem and did not see any obvious mistakes in the
> > > > driver.
> > > 
> > > Maybe some misconfigured clocks? Or some bad declaration in DTS
> > > file? Or power management? IIRC Pavel also modified n900 DTS
> > > file to make his driver working...
> > 
> > All of that can be ruled out, since the alive check package works
> > correctly.
> 
> It looked to me like the failure is config-related. I guess we can
> merge a driver that works on n950, and then I can try to get it
> working on n900.

Yes, this sounds like a good step forward. Having "one" version of 
driver in mainline kernel on which can look more people instead ten 
different implementation and each worked only with some specific old 
kernel version...

> Or it should be possible to do .config-bisection and see what went
> wrong...

I do not expect that this is .config related problem. That could not be 
such "easy".

-- 
Pali Rohár
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-n900-maint/attachments/20160812/5ad57af0/attachment.sig>