[Gta04-owner] Further 3.17 kernel development for GTA04
Dr. H. Nikolaus Schaller
hns at goldelico.com
Mon Nov 3 08:36:01 CET 2014
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.
Tnx,
Nikolaus
More information about the Gta04-owner
mailing list