[Gta04-owner] Linux 3.2-rc4 - now with wifi

Klaus 'mrmoku' Kurzmann mok at mnet-online.de
Tue Dec 6 08:37:47 CET 2011


On Tue, 06 Dec 2011, NeilBrown wrote:

> On Mon, 5 Dec 2011 22:35:24 +0100 Klaus 'mrmoku' Kurzmann
> <mok at mnet-online.de> wrote:

> > On Tue, 06 Dec 2011, NeilBrown wrote:
> > 
> > > On Mon, 5 Dec 2011 17:20:45 +0100 Klaus 'mrmoku' Kurzmann
> > > <mok at mnet-online.de> wrote:
> > 
> > > > Hello Neil,
> > > > 
> > > > On Sat, 03 Dec 2011, NeilBrown wrote:
> > > > 
> > > > 
> > > > > hi all,
> > > > 
> > > > >  I've updated my mainline gta04 kernel tree to 3.2-rc4.
> > > > >     git://neil.brown.name/gta04 merge
> > > > 
> > > > 
> > > > > The main new functionality is wireless.  The details for enabling wireless
> > > > > are slightly different than with the hw-validation kernel.
> > > > 
> > > > > 1/ the reset line is /sys/class/gpio/gta04:wlan:reset
> > > > >     write 0 to reset, 1 to release the reset
> > > > >    The "reset" line is active-low.
> > > > 
> > > > > 2/ After power-on and reset you need to trigger a card-detect signal.
> > > > >    This requires making gpio/gta:wlan/cd go high, then low.  Card-detect
> > > > >    is active-low too.
> > > > 
> > > > > so:
> > > > 
> > > > > VDD=3150000
> > > > > # VDD=2800000
> > > > > echo 1 > /sys/class/gpio/gta04:wlan:cd/value
> > > > > echo "0" >/sys/class/gpio/gta04:wlan:reset/value # activate reset
> > > > > echo "$VDD" >/sys/devices/platform/reg-virt-consumer.4/max_microvolts
> > > > > echo "$VDD" >/sys/devices/platform/reg-virt-consumer.4/min_microvolts
> > > > > echo "normal" >/sys/devices/platform/reg-virt-consumer.4/mode
> > > > > echo "1" >/sys/class/gpio/gta04:wlan:reset/value # release reset
> > > > > echo 0 > /sys/class/gpio/gta04:wlan:cd/value  # edge triggers interrupt.
> > > > 
> > > > > Each gpio directory has an 'active_low' setting.  I should probably find a
> > > > > way to enable that...  Unless I end up hiding all of this inside an rfkill.
> > > > 
> > > > 
> > > > > I added the code to enable power-off, but it doesn't work.
> > > > > As soon as it tries to access the i2c device to send the power-down command to
> > > > > the twl4030 it triggers an error.  It seems that something earlier in the
> > > > > shutdown sequence disabled something that is needed for writing to I2C, but I
> > > > > have no idea what.
> > > > > I've sent an email to someone to ask for hints..
> > > > 
> > > > > I discovered that USB_OTG is disabled in the default config, because
> > > > > USB_SUSPEND is disabled.  If I enable this (because they sound like good
> > > > > things) the charging doesn't work any more.
> > > > > I think the usb port goes to sleep and so stops charging.  I really need to
> > > > > find a way for the charger to keep the usb port awake.
> > > > 
> > > > > Still to do:
> > > > >  - power off
> > > > >  - accelerometers
> > > > >  - explore various bugs reported in dmesg:
> > > > >  - Find out why 'suspend' doesn't suspend
> > > > >  - Make sure suspend saves maximum power.
> > > > >  - make sure can wake from suspend by:
> > > > >     power button, rtc, accelerometer, GSM
> > > > >  - tidy up LCD panel driver.
> > > > >  - make charger keep usb awake, and enable USB_OTG
> > > > >  - see if I can make an 'rfkill' device that will power-on wifi/BT for me.
> > > > >  - Maybe an rfkill for 'gps' as well.
> > > > >  - further explore the rtc alarm bug I found last week.
> > > > >  - gyroscope, compass, barometer,  FM radio?
> > > > >  - See if I can get it to charge from Openmoko charger.
> > > > >  - get all the fixes upstream.
> > > > 
> > > > > My goal is to be using this as my regular phone by LCA-2012 !!
> > > > 
> > > > great :-)
> > > > 
> > > > I have one problem with rc4. Touchsreen stopped working:
> > > > 
> > > > root at om-gta04:~# cat /dev/input/event0 
> > > > [  739.782196] omap_i2c omap_i2c.2: controller timed out
> > > > [  739.813537] tsc2007 2-0048: i2c io error: -110
> > 
> > > 110 is ETIMEDOUT
> > 
> > > > 
> > > > 
> > > > any hint?
> > 
> > > Not really.  I don't have a real touch screen attached yet so I might have
> > > trouble testing.  I'll have a look though.
> > 
> > > My guess is that it is related to runtime-power-management, but that is just
> > > because the last two weird bugs were.
> > 
> > I enabled debug for the i2c and this is what I get when touching the
> > screen:
> > 
> > [  119.375213] i2c i2c-2: master_xfer[0] W, addr=0x48, len=1
> > [  119.380828] i2c i2c-2: master_xfer[1] R, addr=0x48, len=2
> > [  119.386566] omap_i2c omap_i2c.2: addr: 0x0048, len: 1, flags: 0x0, stop: 0
> > [  119.393798] omap_i2c omap_i2c.2: IRQ (ISR = 0x1010)
> > [  119.398895] omap_i2c omap_i2c.2: IRQ (ISR = 0x1004)
> > [  119.404022] omap_i2c omap_i2c.2: addr: 0x0048, len: 2, flags: 0x1, stop: 1
> > [  119.411315] omap_i2c omap_i2c.2: IRQ (ISR = 0x1008)
> > [  119.416381] omap_i2c omap_i2c.2: IRQ (ISR = 0x0108)
> > [  119.421478] omap_i2c omap_i2c.2: IRQ (ISR = 0x0004)
> > [  119.426605] i2c i2c-2: master_xfer[0] W, addr=0x48, len=1
> > [  119.432281] i2c i2c-2: master_xfer[1] R, addr=0x48, len=2
> > [  119.437927] omap_i2c omap_i2c.2: addr: 0x0048, len: 1, flags: 0x0, stop: 0
> > [  119.445098] omap_i2c omap_i2c.2: IRQ (ISR = 0x0010)
> > [  119.450195] omap_i2c omap_i2c.2: IRQ (ISR = 0x1004)
> > [  119.455322] omap_i2c omap_i2c.2: addr: 0x0048, len: 2, flags: 0x1, stop: 1
> > [  119.462615] omap_i2c omap_i2c.2: IRQ (ISR = 0x1008)
> > [  119.467712] omap_i2c omap_i2c.2: IRQ (ISR = 0x0108)
> > [  119.472778] omap_i2c omap_i2c.2: IRQ (ISR = 0x0004)
> > [  119.477935] i2c i2c-2: master_xfer[0] W, addr=0x48, len=1
> > [  119.483551] i2c i2c-2: master_xfer[1] R, addr=0x48, len=2
> > [  119.489227] omap_i2c omap_i2c.2: addr: 0x0048, len: 1, flags: 0x0, stop: 0
> > [  119.496429] omap_i2c omap_i2c.2: IRQ (ISR = 0x0010)
> > [  119.501525] omap_i2c omap_i2c.2: IRQ (ISR = 0x1004)
> > [  119.506622] omap_i2c omap_i2c.2: addr: 0x0048, len: 2, flags: 0x1, stop: 1
> > [  119.513916] omap_i2c omap_i2c.2: IRQ (ISR = 0x1008)
> > [  119.519012] omap_i2c omap_i2c.2: IRQ (ISR = 0x0108)
> > [  119.524078] omap_i2c omap_i2c.2: IRQ (ISR = 0x0004)
> > [  119.529235] i2c i2c-2: master_xfer[0] W, addr=0x48, len=1
> > [  119.534881] i2c i2c-2: master_xfer[1] R, addr=0x48, len=2
> > [  119.540527] omap_i2c omap_i2c.2: addr: 0x0048, len: 1, flags: 0x0, stop: 0
> > [  119.547729] omap_i2c omap_i2c.2: IRQ (ISR = 0x0010)
> > [  119.552856] omap_i2c omap_i2c.2: IRQ (ISR = 0x1004)
> > [  119.557983] omap_i2c omap_i2c.2: addr: 0x0048, len: 2, flags: 0x1, stop: 1
> > [  119.565277] omap_i2c omap_i2c.2: IRQ (ISR = 0x1008)
> > [  119.570343] omap_i2c omap_i2c.2: IRQ (ISR = 0x0108)
> > [  119.575439] omap_i2c omap_i2c.2: IRQ (ISR = 0x0004)
> > [  119.580566] i2c i2c-2: master_xfer[0] W, addr=0x48, len=1
> > [  119.586212] i2c i2c-2: master_xfer[1] R, addr=0x48, len=2
> > [  119.591857] omap_i2c omap_i2c.2: addr: 0x0048, len: 1, flags: 0x0, stop: 0
> > [  119.599029] omap_i2c omap_i2c.2: IRQ (ISR = 0x0010)
> > [  119.604156] omap_i2c omap_i2c.2: IRQ (ISR = 0x1004)
> > [  119.609252] omap_i2c omap_i2c.2: addr: 0x0048, len: 2, flags: 0x1, stop: 1
> > [  119.616577] omap_i2c omap_i2c.2: IRQ (ISR = 0x1008)
> > [  119.621673] omap_i2c omap_i2c.2: IRQ (ISR = 0x0108)
> > [  119.626739] omap_i2c omap_i2c.2: IRQ (ISR = 0x0004)
> > 
> > no idea if that is of any help...

> I don't see the:
> [  739.782196] omap_i2c omap_i2c.2: controller timed out
> [  739.813537] tsc2007 2-0048: i2c io error: -110


> messages in here.  Do you always get them?  Can you get a trace that includes
> them along with the other debugging info?

Hmm, interesting... that one is no more in dmesg:

root at om-gta04:~# dmesg | grep tsc2007
[    0.305175] i2c i2c-2: client [tsc2007] registered with bus id 2-0048
[    3.158660] bus: 'i2c': add driver tsc2007
[    3.158752] bus: 'i2c': driver_probe_device: matched device 2-0048 with driver tsc2007
[    3.158752] bus: 'i2c': really_probe: probing driver tsc2007 with device 2-0048
[    3.158874] tsc2007 2-0048: probe
[    3.158996] tsc2007_init()
[    3.173400] driver: '2-0048': driver_bound: bound to device 'tsc2007'
[    3.173431] bus: 'i2c': really_probe: bound device 2-0048 to driver tsc2007
[    3.173614] i2c-core: driver [tsc2007] registered


> I suggest that you use 
>    evtest /dev/input/event0
> for testing.  It helps confirm you are looking at the right device, and the
> output is at least vaguely readable.

duh, should have thought about evtest before.

> Do you ever get any event output?  or is it always completely silent?
root at om-gta04:~# evtest /dev/input/event0 
Input driver version is 1.0.1
Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
Input device name: "TSC2007 Touchscreen"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 330 (Touch)
  Event type 3 (Absolute)
    Event code 0 (X)
      Value    816
      Min        0
      Max     4095
    Event code 1 (Y)
      Value   1356
      Min        0
      Max     4095
    Event code 24 (Pressure)
      Value      0
      Min        0
      Max     4095
Testing ... (interrupt to exit)
Event: time 1323100614.009307, type 1 (Key), code 330 (Touch), value 1
Event: time 1323100614.009307, type 3 (Absolute), code 0 (X), value 1846
Event: time 1323100614.009307, type 3 (Absolute), code 1 (Y), value 1535
Event: time 1323100614.009307, type 3 (Absolute), code 24 (Pressure), value 275
Event: time 1323100614.009338, -------------- Report Sync ------------
Event: time 1323100614.012939, type 1 (Key), code 330 (Touch), value 0
Event: time 1323100614.012939, type 3 (Absolute), code 24 (Pressure), value 0
Event: time 1323100614.012939, -------------- Report Sync ------------


hmm... damn and its working too :)

I don't know yet but probably I did a bad kernel build due to a bad
config... or a bad upgrade. Sorry for the noise. 


> NeilBrown




> > /me already regrets to not have attended Christoph's talk about i2c in
> > the kernel :/
> > 
> > 
> > > > 
> > > > And another big thank you for the great work you're doing (being burned
> > > > by the stuttering upstreaming works of Nokia for n900 we (SHR) really appreciate
> > > > that)
> > 
> > > :-)
> > > There is a reason we call it the bleeding edge - but when you bleed, at least
> > > that proves you are alive!
> > 
> > yeah, bleeding is fine as long as there is effort to make it stop - just
> > like in real life :-)
> > 
> > > NeilBrown
> > 
> > 


-- 
Klaus 'mrmoku' Kurzmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20111206/94451ebe/attachment.bin>


More information about the Gta04-owner mailing list