[Letux-kernel] Pandora WiFi / wl1251 driver

H. Nikolaus Schaller hns at goldelico.com
Wed Sep 25 18:31:48 CEST 2019


> Am 25.09.2019 um 14:00 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 25.09.2019 um 08:52 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> 
>>> Am 24.09.2019 um 21:55 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> 
>>> WiFi on Pandora is broken for a long time. It is known that
>>> it did stop working with letux-4.7. And something additional
>>> became worse around letux-4.12 (not clear what that was - maybe
>>> some dmesg log):
>>> 
>>> http://projects.goldelico.com/p/gta04-kernel/issues/849/
>>> 
>>> I have rebuilt these old kernels and found out that the
>>> problem starts to occur with letux-4.7-rc1.
>>> 
>>> This means we need to bisect between letux-4.6..letux-4.7-rc1
>>> 
>>> Unfortunately git bisect can't do that because there is
>>> no fast-forward path between both. Both are derived from
>>> the linear history v4.6..v4.7 but add (different) set
>>> of feature branches.
>>> 
>>> So it is like trying to interpolate (walk) between the tips
>>> of branches in a tree. There is only gap in between...
> 
> Basically I have found a new method.
> 
> To walk between the tips you have to glue a copy of a branch to
> some intermediate point at the trunk.
> 
> Let's try to describe by formulae (+ means a git merge):
> 
> 	letux(version) = mainline(version) + feature-branches(version)
> 
> good:	letux(4.6) = v(4.6) + feature-branches(v4.6)
> 
> bad:	letux(4.7-rc1) = v(4.7-rc1) + feature-branches(v4.7-rc1)
> 
> Note that feature-branches(v4.6) and feature-branches(v4.7-rc1)
> are not necessarily the same. They have been rebased, new features
> have been added, bugs have been fixed and API changes covered during
> the development of feature-branches(v4.7-rc1).
> 
> bisect:	walks commits between v4.6 and v4.7-rc1 i.e.
> 
> 	v(4.6) < v(bisect) < v(4.7-rc1)
> 
> What we want is
> 
> 	letux(4.6) < letux(bisect) < letux(4.7-rc1)
> 
> The problem is that
> 
> 	letux(bisect) = v(bisect) + feature-branches(bisect)
> 
> does not exist and can't be provided (unless someone manually rebases, fixes bugs and APU changes).
> 
> So we try this:
> 
> 	letux(bisect) = v(4.6) + feature-branches(bisect) - cleanup
> 
> by a simple git merge. This almost succeeds since letux(4.7-rc1) includes
> both, v4.6 and v4.7-rc1.
> 
> We may need some cleanup to fix irrelevant merge conflicts and compile errors
> by checking out individual files from letux(4.6).
> 
> This allows to have a full letux(bisect) for testing.
> 
> Since it is not exactly interpolated, there may be strange effects by this
> but they are unlikely. Here in the WiFi example, I just have to disable w2sg0004
> and twl6040 config. They are not used on the Pandora and therefore should not
> influence anything.
> 
>> 
>> Ok, first bisect attempt reports:
>> 
>> f4c80d5a16eb4b08a0d9ade154af1ebdc63f5752 is the first bad commit
>> HEAD ist jetzt bei f4c80d5a16eb Merge tag 'sound-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
>> 
>> Well, this is a "merge". And a merge may hide the real reason
>> due to history that may have separate before the first good
>> commit.
>> 
>> So what I have to do is to restart/redo the bisect starting
>> earlier...
>> 
>> Let's try again with letux-4.6-rc1..letux-4.7-rc1
> 
> well, it appears as if letux-4.6-rc1 .. rc3 do not even
> start the kernel on the Pandora.
> 
> So let's see if a bisect letux-4.6-rc4..f4c80d5a16eb finds something.

Success! New bisect strategy works.


81eef6ca92014845d40e3f1310e42b7010303acc is the first bad commit
commit 81eef6ca92014845d40e3f1310e42b7010303acc
Author: Peter Ujfalusi <peter.ujfalusi at ti.com>
Date:   Fri Apr 29 16:06:18 2016 +0300

    mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel
    
    With the new dma_request_chan() the client driver does not need to look for
    the DMA resource and it does not need to pass filter_fn anymore.
    By switching to the new API the driver can now support deferred probing
    against DMA.
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
    Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>


Firstly, it sounds reasonable that this commit has something to
do with the wl1251 connected to the mmc3 port of the OMAP3...

Secondly, I have seen multiple of these log messages:

[    4.377227] omap_hsmmc omap_hsmmc.2: RX DMA channel request failed

and omap_hsmmc.2 is the mmc3 port where the WiFi chip is connected to.

So this is certainly a good reason why the driver starts to fail
at 4.7-rc1. It is likely that probing can now fail by deferred
probing...

Now let's check if a revert fixes the issue for 4.7-rc1 or even 4.7.

But there may be follow-up fixes for this patch to consider.

Then we have to find out what the real problem is. Maybe some component
doesn't support deferred probing. Or the DMA setup for omap3 mmc3
has a bug that nobody else did notice (the mmc3 interface is rarely
used by boards - as far as I can see only omap3-zoom3 and pandora).

BR,
Nikolaus



More information about the Letux-kernel mailing list