[Gta04-owner] Further 3.17 kernel development for GTA04

Dr. H. Nikolaus Schaller hns at goldelico.com
Tue Nov 4 06:54:33 CET 2014


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.

So a simple test scenario could be to add some dummy-gpio controller to the DT which
has no driver and reference it as dtr-gpio.

Maybe I should try if the same effect can be triggered by referencing a rts-gpio so that
it could be demonstrated with vanilla 3.17.

> 
> 
>> 
>> So it looks as if serial_omap_probe() is not robust for deferred probing (although we have only more
>> or less copied code from the RS485 RTS gpio stuff to get the DTR gpio).
>> 
>> Or (I can’t decide) the sequence of successful UART probing must be UART1, 2, 3.
>> 
>> Any suggestions how to address this? Bug report on LKML (but I have no test case for LKML
>> subscribers - only for GTA04 owners)?
> 
> You could set a global variable when UART3 is probed, and EPROBE_DEFER UART2
> until that variable is set.  But still disable the linkage with GPS.
> 
> If that causes a problem, the probe order is an issue.
> If it doesn’t then probably the GPS is the issue.

Ok. That is a good idea.

What Ido not understand is that there is nothing significantly done when probing of the dtr fails.
It just makes the omap-serial fail as well and I can’t see any code that could have a side-effect on
interrupts.

BR,
Nikolaus


> 
> NeilBrown
> 
> 
>> 
>> BR,
>> Nikolaus
>> 
>> [1]: comment out these 4 lines and hdq works 
>> 1705+1706: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/tty/serial/omap-serial.c;h=6398cb218b9fdd2b0551481a456f7b29ae809922;hb=refs/heads/3.18-rc2#l1705
>> 1737+1738: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/tty/serial/omap-serial.c;h=6398cb218b9fdd2b0551481a456f7b29ae809922;hb=refs/heads/3.18-rc2#l1737
>> 
>> _______________________________________________
>> Gta04-owner mailing list
>> Gta04-owner at goldelico.com
>> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner



More information about the Gta04-owner mailing list