[Gta04-owner] Further 3.17 kernel development for GTA04
Dr. H. Nikolaus Schaller
hns at goldelico.com
Mon Nov 3 22:25:46 CET 2014
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).
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)?
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
More information about the Gta04-owner
mailing list