[Gta04-owner] Further 3.17 kernel development for GTA04
Dr. H. Nikolaus Schaller
hns at goldelico.com
Tue Nov 4 21:13:02 CET 2014
Hi Neil,
Am 04.11.2014 um 20:55 schrieb NeilBrown <neilb at suse.de>:
> On Tue, 4 Nov 2014 06:54:33 +0100 "Dr. H. Nikolaus Schaller"
> <hns at goldelico.com> wrote:
>
>>
>> Am 03.11.2014 um 22:50 schrieb NeilBrown <neilb at suse.de>:
>>
>>> On Mon, 3 Nov 2014 22:25:46 +0100 "Dr. H. Nikolaus Schaller"
>>> <hns at goldelico.com> wrote:
>>>
>>>> Hi again,
>>>>
>>>> Am 03.11.2014 um 20:04 schrieb Dr. H. Nikolaus Schaller <hns at goldelico.com>:
>>>>
>>>>> Hi Neil,
>>>>>
>>>>> Am 03.11.2014 um 14:44 schrieb Dr. H. Nikolaus Schaller <hns at goldelico.com>:
>>>>>
>>>>>> Hi Neil,
>>>>>>
>>>>>> Am 03.11.2014 um 08:36 schrieb Dr. H. Nikolaus Schaller <hns at goldelico.com>:
>>>>>>
>>>>>>>
>>>>>>> Am 03.11.2014 um 08:27 schrieb NeilBrown <neilb at suse.de>:
>>>>>>>
>>>>>>>> On Mon, 3 Nov 2014 07:57:00 +0100 "Dr. H. Nikolaus Schaller"
>>>>>>>> <hns at goldelico.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 03.11.2014 um 07:44 schrieb NeilBrown <neilb at suse.de>:
>>>>>>>>>
>>>>>>>>>> On Mon, 3 Nov 2014 07:00:42 +0100 "Dr. H. Nikolaus Schaller"
>>>>>>>>>> <hns at goldelico.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Am 02.11.2014 um 10:51 schrieb NeilBrown <neilb at suse.de>:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've made some useful progress.
>>>>>>>>>>>>
>>>>>>>>>>>> Nearly all the things that I need regularly work. So I can make phone calls
>>>>>>>>>>>> (on the GTA04a4, not on the a3),
>>>>>>>>>>>
>>>>>>>>>>> ah, did you solve the ALSA sound driver issues?
>>>>>>>>>>
>>>>>>>>>> What ALSA sound driver issues?
>>>>>>>>>
>>>>>>>>> Proper device tree based Tri-State control for McBSP to switch between hardware and
>>>>>>>>> software routing.
>>>>>>>>>
>>>>>>>>> http://projects.goldelico.com/p/gta04-kernel/issues/587/
>>>>>>>>>
>>>>>>>>> And, I had to disable something because I got kernel panics.
>>>>>>>>>
>>>>>>>>> Which sound system did you use? ti,omap-twl4030 or goldelico,gta04-audio?
>>>>>>>>
>>>>>>>> I don't have the goldelico one at all. Just ti,omap-twl4030 with some
>>>>>>>> modification to support an external device connected to the voice port.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The first one should work out of the box and the second one fails.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> use the wifi, charge the battery and
>>>>>>>>>>>> monitor its status, and turn the GPS on/off using my new approach. There is
>>>>>>>>>>>> no-longer an ‘rfkill' for GPS - opening /dev/ttyO1 does all that is needed.
>>>>>>>>>>>
>>>>>>>>>>> Hm. I am not happy that there is no rfkill. Well, someone commented that
>>>>>>>>>>> GPS is not a transmitter, but Linux provides the rfkill gps switch (and we have
>>>>>>>>>>> not introduced it). And, basically the antenna amplifier might transmit (if it runs
>>>>>>>>>>> out of control) so it is safer in an airplane situation to be able to turn off the
>>>>>>>>>>> LNA power explicitly. But keep gpsd and tangogps running. A user might
>>>>>>>>>>> be just looking into local maps.
>>>>>>>>>>
>>>>>>>>>> It can be added back if it is really needed.
>>>>>>>>>> It always thought it was a bit odd as rfkill is, like you say, primarily
>>>>>>>>>> about transmitters.
>>>>>>>>>>
>>>>>>>>>> I'd like to know if anyone else is using a 'gps' rfkill ... I couldn't find
>>>>>>>>>> any documentation or useful references last time I looked.
>>>>>>>>>
>>>>>>>>> I don’t know either, but that nobody might have to solve the same problem
>>>>>>>>> as we have to solve.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> I'm not entirely happy with this code yet but it is quite usable.
>>>>>>>>>>>>
>>>>>>>>>>>> Suspend seems to work reliably, but power usage is way too high - about
>>>>>>>>>>>> 50mA. There are hints in some patches in 3.18-rc, so USB might be to blame
>>>>>>>>>>>> for some of that extra usage, so I'll probably be looking that that when I
>>>>>>>>>>>> next get some time.
>>>>>>>>>>>>
>>>>>>>>>>>> My kernel doesn't currently "export" the various GPIOs that need to be
>>>>>>>>>>>> manually poked.
>>>>>>>>>>>> I have this code:
>>>>>>>>>>>>
>>>>>>>>>>>> for l in 186,high 175,high 23,low 21,high
>>>>>>>>>>>> do
>>>>>>>>>>>> g=${l%,*}
>>>>>>>>>>>> echo $g > /sys/class/gpio/export
>>>>>>>>>>>> echo ${l#*,} > /sys/class/gpio/gpio$g/direction
>>>>>>>>>>>> done
>>>>>>>>>>>>
>>>>>>>>>>>> in an init.d script which sets some of these up. GPIO186 is particularly
>>>>>>>>>>>> needed for turning the GSM modem on.
>>>>>>>>>>>
>>>>>>>>>>> What are these gpios good for? The modem should be controlled through
>>>>>>>>>>> rfkill wwan. For this we have prepared a special driver in the gta04-kernel that
>>>>>>>>>>> pulses the modem gpio in a similar way as for GPS (there is no UART we can
>>>>>>>>>>> use to auto-control modem power).
>>>>>>>>>>
>>>>>>>>>> A driver which I obviously don't have. I'll try to look at it when I get a
>>>>>>>>>> chance.
>>>>>>>>>> My user-space code wants to poke the gpio, so I provided it.
>>>>>>>>>> The others I just provided to I could be certain they were in the correct
>>>>>>>>>> position for low power usage.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've re-organised my tree as a set of topic branch, mostly based on
>>>>>>>>>>>> v3.17, though the 'dts' branch with device-tree changes is based on
>>>>>>>>>>>>
>>>>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
>>>>>>>>>>>> tag omap-for-v3.17/dt-gta04
>>>>>>>>>>>> which has some gta04 stuff that didn't quite make 3.17 - is in 3.18-rc1
>>>>>>>>>>>>
>>>>>>>>>>>> The branches are:
>>>>>>>>>>>>
>>>>>>>>>>>> 'dts', 'hdq', 'dss', 'pwm-old', 'input', 'hacks', 'wifi', 'extcon', 'itg',
>>>>>>>>>>>> ‘tty-slave', 'audio', 'twl4030' and 'charger'
>>>>>>>>>>>
>>>>>>>>>>> the hdq patch (there is a missing/wrong compatible entry in the driver)
>>>>>>>>>>> appears to be the last missing piece we have to make it working .
>>>>>>>>>>>
>>>>>>>>>>> Does it work for you? I see it start up and read the bq27000 several times,
>>>>>>>>>>> but ca. 4.5 seconds after kernel startup it stops. I suspect some IRQ
>>>>>>>>>>> interference (maybe from a subsystem that you do not have).
>>>>>>>>>>
>>>>>>>>>> It works very reliably for me.
>>>>>>>>>> The behaviour you describe is vaguely reminiscent of problems I was having
>>>>>>>>>> ages ago which were due to runtime PM issues with the hdq driver. I think
>>>>>>>>>> the fixes went upstream, possibly
>>>>>>>>>> commit c354a86484b61e32100eb94c1f3f0aa512958cee
>>>>>>>>>>
>>>>>>>>>> Looking at my mail records, the issue was fixed in 3.6.
>>>>>>>>>>
>>>>>>>>>> There was one time recently when reads from one of the sysfs bq27000 files started
>>>>>>>>>> returning ENXIO (or maybe ENODEV), but it hasn't happened again. I'll keep an eye
>>>>>>>>>> out for problems.
>>>>>>>>>
>>>>>>>>> It is indeed strange. I have added some printk to report hdq write&read and timeouts:
>>>>>>>>>
>>>>>>>>> [ 3.894470] omapfb omapfb: no displays
>>>>>>>>> [ 3.899444] omapfb omapfb: failed to setup omapfb
>>>>>>>>> [ 3.904449] platform omapfb: Driver omapfb requests probe deferral
>>>>>>>>> [ 3.912017] platform 4806a000.serial: Driver omap_uart requests probe deferral
>>>>>>>>> [ 3.920532] platform 4806c000.serial: Driver omap_uart requests probe deferral
>>>>>>>>> [ 3.929016] platform 480b4000.mmc: Driver omap_hsmmc requests probe deferral
>>>>>>>>> [ 3.938201] ALSA device list:
>>>>>>>>> [ 3.941314] No soundcards found.
>>>>>>>>> [ 3.947357] hdq_write_byte(00000027) ok
>>>>>>>>> [ 3.951568] hdq_read_byte -> 00
>>>>>>>>> [ 4.148071] hdq_write_byte timeout
>>>>>>>>> [ 4.350708] hdq_read_byte timeout
>>>>>>>>> [ 4.548431] hdq_write_byte timeout
>>>>>>>>> [ 4.748565] hdq_read_byte timeout
>>>>>>>>> [ 4.948394] hdq_write_byte timeout
>>>>>>>>>
>>>>>>>>> I suspect some other subsystem might be influencing interrupts.
>>>>>>>>>
>>>>>>>>> Something to locate by disabling one driver after the other…
>>>>>>>>
>>>>>>>> Can't explain that. Both my A3 and A4 boards work.
>>>>>>>> Maybe watch ‘grep hdq /proc/interrupts' and see if it changes at all.
>>>>>>>
>>>>>>> It says :
>>>>>>>
>>>>>>> 235: 22 INTC 58 omap_hdq
>>>>>>>
>>>>>>> and does not change if I try to cat /sys/class/power_supply/bq27000-battery/voltage_now
>>>>>>>
>>>>>>> So indeed someone is blocking these interrupts. Now I have to identify that “someone” first,
>>>>>>> but it is easier with a good test case.
>>>>>>
>>>>>> Looks as if I have found it, although I have really no explanation.
>>>>>>
>>>>>> It appears to be related to the DTR patch to omap-serial.c that we have (I think inherited from
>>>>>> kernel 3.7) to control the virtual GPIO of the w2sg driver. If I checkout the latest from linus/3.18-rc2, hdq works.
>>>>>>
>>>>>> Of course GPS does not work any more, because the DTR control is then missing.
>>>>>>
>>>>>> It appears to be sufficient to add/remove that patch (which is not in mainline Linux - just in
>>>>>> our 3.18-rc2 and therefore you have no chance to see this effect) to start/stop HDQ interrupts.
>>>>>>
>>>>>> I will report if I get a better understanding why this DTR code can interfere with HDQ and
>>>>>> which line(s) of code makes the difference.
>>>>>
>>>>> After a lot of trial and error, I still don’t understand it. But it appears to have something to do
>>>>> with the UART3 + console handling. There is one line in the driver where the DTR gpio is derived
>>>>> from the device tree.
>>>>>
>>>>> If I keep it as is (it reads the “dtr-gpio” property from the DT), we have serial and GPS, but the hdq hangup.
>>>>> If I force this gpio to 0, hdq works, but the console output goes to the LCD (I have never seen that before), and we have no GPS.
>>>>> If I force it to -ENOENT (which is equivalent to a DT definition with missing dtr-gpio specification), we have serial and hdq, but no GPS.
>>>>> If I force it to -EPROBE_DEFER, console goes to LCD. There is no GPS, hdq does not work.
>>>>>
>>>>> Now, I guess our DTR patch interferes with the takeover of UART3 by this driver. Or alternatively,
>>>>> that deferred probing in omap_serial has some side-effect for UART0 or UART1.
>>>>
>>>> after some more tests I am quite sure that the problem is deferred probing of uart drivers.
>>>>
>>>> If I disable the return -EPROBE_DEFER paths [2] in serial_omap_probe() hdq works (and GPS fails).
>>>> If I enable them, hdq fails and GPS works (if configured).
>>>
>>> Based on that evidence, it could be that the GPS interferes with HDQ.
>>
>> it is definitively not the GPS driver. I can disable it from .config and hdq still breaks. It is
>> sufficient to have it in the DT.
>>
>> The only condition is that the dtr-gpio defined for the UART does not successfully probe
>> immediately.
>>
>
> I decided to try your kernel
> Specifically, commit 16243938d0438c872c1da06183af726631402f24 from
> goldelico/work/hns/3.18-hdq, with
Yes, in the hdq branch hdq battery works - but without GPS. If GPS is configured/added
hdq fails.
But I think I have not commited such a state.
In 3.18-rc2 hdq fails - but because it is not properly configured.
>
> { .compatible = "ti,omap-hdq", },
>
>
> changed to
>
> { .compatible = "ti,omap3-1w", },
>
> and the HDQ deivce sees to work perfectly. Maybe there are differences
> in .config…
>
> If you would like to give me your .config
the defconfig used is arch/arm/configs/gta04_defconfig
> and a git commit number that is
> failing for you, I’ll see if I can reproduce it.
I was not fast enough to announce that it now appears to work.
What I have done:
cherry-pick the relevant patches from the 3.18-hdq branch
merge 3.18-rc3
And it simply works. The hdq interrupt hickup has gone.
I have two potential reasons but it is probably not worth to deeper analyse:
* it might be something was wrong in 3.18-rc1 and rc2 which was fixed now
* adding printk into drivers that are probed while UART3 is itself being probed might lead to this type of hangup
So the 3.18-rc3 works (I have tested on two boards). Both,
cat /sys/class/power_supply/bq27000-battery/uevent
and
cat /dev/ttyO1
work as expected.
Thanks for encouraging to continue to dig into this issue.
BR,
Nikolaus
More information about the Gta04-owner
mailing list