[Gta04-owner] Further 3.17 kernel development for GTA04

Mon Nov 3 22:43:24 CET 2014

On Mon, 3 Nov 2014 20:04:21 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

> 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.

I was going to suggest that the connection with UART3 was probably that the
padctrl settings for uart2_rx_irq_pins was wrong, but I see you've since
fixed that (and hdq_pins). (I assume the new .dtb file is actually being
installed and loaded .... that tripped me a couple of times).

Maybe add tracing to the pinctrl_select_state calls in w2sg0004.c and see if
a pinctrl change aligns with the HDQ failures.

Very strange....

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20141104/9ecf1499/attachment.asc>