Hi,
I was using this AOSP ICS build for Panda created by Linaro
http://releases.linaro.org/12.07/android/images/panda-master-gcc44-aosp-stable-blob/
This AOSP ICS build doesnot seem to have the usb networking issue (same as in the thread below) that I have been trying to fix for few weeks now.
So probably kernel in this AOSP ICS image created by Linaro has some fix for it.
I checked the pinned-manifest.xml for which kernel it uses
<project name="kernel/omap" revision="52f476403350050beb0dff135a55c06c9e7a82a9">
So as I understand its above revision checked out from git://android.git.linaro.org/kernel/omap.
I tried to download these sources, but I did not find any difference in the kernel sources I downloaded from AOSP git. (Both also have seem to have same revision!)
I tried to build this kernel and use in AOSP ICS and again I face same usb-ethernet networking issue.
So I am really curious to find the kernel sources used to build the kernel in the AOSP ICS images created by Linaro.
Please could you help with some pointers?
Thanks for your kind support.
BR
Sagar
On Tuesday, July 3, 2012 12:36:33 AM UTC+3, Pandita, Vikram wrote:On Mon, Jul 2, 2012 at 2:11 PM, Zach Pfeffer <zach.p...@linaro.org> wrote:
>
> On 29 June 2012 10:55, Émeric Vigier <emeric...@savoirfairelinux.com>
> wrote:
> > Hi,
> >
> > I am not 100% sure but it seems my smsc95xx is unable to wake up the CPU
> > while it is in WFI.
> > I have verified that my OMAP4430 constantly enters WFI. Note that sleep
> > states are disabled.
> > USB mouse and keyboard events wake it up properly. eth0 RX seems to wake
> > it up, but eth0 TX does not...
> > What could be possibly wrong in my config then? usbnet.c only creates
> > softirq to submit URB. No HW irq.
> >
> > How can I make smsc95xx trigger an interrupt (ehci_hcd:usb1) while
> > transferring data?
> > Do you know?
The pad for gpio will have to be made wakeup capable. Each ball on
omap has a mux that has one bit to make it wakeup capable...
typically disabling cpuidle if fixes the issue, then you are sure its
this issue.
>
> I don't know. Including linaro-android and pandaboard.
>
> > Emeric
> >
> > ----- Mail original -----
> >> De: "Émeric Vigier" <emeric...@savoirfairelinux.com>
> >> À: "Zach Pfeffer" <zach.p...@linaro.org>
> >> Cc: "Vikram Pandita" <vikram....@ti.com>,
> >> omapandroid...@gforge.ti.com
> >> Envoyé: Jeudi 28 Juin 2012 16:04:31
> >> Objet: Re: [Omapandroid-discussion] smsc95xx: download ok, upload hangs
> >>
> >> I tried 4AI.1.4-P1 kernel this morning. The panda_defconfig did not
> >> compiled out of the box:
> >> arch/arm/mach-omap2/temp_sensor_device.c:38: undefined reference to
> >> `omap_temp_sensor_idle'
> >> I disabled CONFIG_OMAP_TEMP_SENSOR and CONFIG_OMAP4_DIE_TEMP_SENSOR.
> >> It seems that there are not supported on omap4430 anyway...
> >> But kernel panics short after init, with my Android images. And I am
> >> not really into investigating this panic.
> >>
> >> Compiling my current kernel with gcc-4.6 (provided by google android)
> >> did not change the behavior.
> >>
> >> I made more tests though. My test setup is now as follows:
> >> On the pandaboard I run:
> >> # nc -l -p 1032 < /dev/zero &
> >> On my host computer (connected to the same network), I run:
> >> # nc 192.168.50.107 1032 > /dev/null
> >> I can see with nethogs that TX is stalled as I got "nc [...] 0KB/sec"
> >>
> >> I tried to change mtu, from 1500 to 512, no real improvement.
> >>
> >> here is a list of my usb devices:
> >>
> >> # cat /d/usb/devices
> >>
> >> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
> >> B: Alloc= 0/800 us ( 0%), #Int= 3, #Iso= 0
> >> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> >> P: Vendor=1d6b ProdID=0002 Rev= 3.00
> >> S: Manufacturer=Linux 3.0.8-g2562c68-dirty ehci_hcd
> >> S: Product=OMAP-EHCI Host Controller
> >> S: SerialNumber=ehci-omap.0
> >> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
> >> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
> >> E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
> >>
> >> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 5
> >> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
> >> P: Vendor=0424 ProdID=9514 Rev= 1.00
> >> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 2mA
> >> I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub
> >> E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
> >> I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub
> >> E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
> >>
> >> T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
> >> D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
> >> P: Vendor=0424 ProdID=ec00 Rev= 1.00
> >> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 2mA
> >> I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff
> >> Driver=smsc95xx
> >> E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> >> E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> >> E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> >>
> >> T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=1.5 MxCh= 0
> >> D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
> >> P: Vendor=04b3 ProdID=3025 Rev= 1.02
> >> S: Manufacturer=CHICONY
> >> S: Product=USB NetVista Full Width Keyboard
> >> C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
> >> I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
> >> E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
> >>
> >> T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=03 Dev#= 6 Spd=12 MxCh= 0
> >> D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
> >> P: Vendor=066b ProdID=400b Rev= 1.01
> >> S: Manufacturer=LINKSYS Inc
> >> S: Product=LINKSYS USB Adapter
> >> S: SerialNumber=9b1fa5
> >> C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=156mA
> >> I:* If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=pegasus
> >> E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> >> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> >> E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=1ms
> >>
> >> We can see the smsc9514 chipset which is causing me so much pain.
> >> Also I compiled the pegasus driver to support an external Linksys
> >> device. This device ethernet behaves just fine as eth1. I noticed
> >> that MxPS (MaxPacketSizes) and Cls (Class) are different on the two
> >> ethernet devices. But I don't think this is the cause of my problem.
> >>
> >> When I stress the cpu:
> >> # stress -c 1
> >> TX is resumed and speed increases to ~20KBps.
> >> This is strange, because I remember having tested with "stress -c 2"
> >> before, without seeing any improvement. My setup is probably
> >> different now...
> >>
> >> Something must be wrong with the wakeonlan capability of the chipset.
> >> I checked register 0x20, smsc95xx.h defines:
> >>
> >> #define PM_CTRL (0x20)
> >> #define PM_CTL_DEV_RDY_ (0x00000080)
> >> #define PM_CTL_SUS_MODE_ (0x00000060)
> >> #define PM_CTL_SUS_MODE_0 (0x00000000)
> >> #define PM_CTL_SUS_MODE_1 (0x00000020)
> >> #define PM_CTL_SUS_MODE_2 (0x00000060)
> >> #define PM_CTL_PHY_RST_ (0x00000010)
> >> #define PM_CTL_WOL_EN_ (0x00000008)
> >> #define PM_CTL_ED_EN_ (0x00000004)
> >> #define PM_CTL_WUPS_ (0x00000003)
> >> #define PM_CTL_WUPS_NO_ (0x00000000)
> >> #define PM_CTL_WUPS_ED_ (0x00000001)
> >> #define PM_CTL_WUPS_WOL_ (0x00000002)
> >> #define PM_CTL_WUPS_MULTI_ (0x00000003)
> >>
> >> # while(true); do ethtool -d eth0 | grep 020: ; sleep 1; done
> >> 020: 81 00 00 00 00 00 11 01 1f 00 00 1f a0 30 f8 00
> >> 020: 81 00 00 00 00 00 11 01 1f 00 00 1f a0 30 f8 00
> >> 020: 81 00 00 00 02 00 11 01 1f 00 00 1f a0 30 f8 00
> >> 020: 81 00 00 00 00 00 11 01 1f 00 00 1f a0 30 f8 00
> >> 020: 81 00 00 00 00 00 11 01 1f 00 00 1f a0 30 f8 00
> >>
> >> The only register changing is 0x24 which is LED_GPIO_CFG, which
> >> confirms that my register is correct.
> >> If I decode correctly, register 0x20 has PM_CTL_WUPS_ED_ and
> >> PM_CTL_WOL_EN_ set.
> >> Still lacking register description though...
> >>
> >> ethtool returns nothing regarding wakeonlan for eth0:
> >>
> >> # ethtool eth0
> >> Settings for eth0:
> >> Supported ports: [ TP MII ]
> >> Supported link modes: 10baseT/Half 10baseT/Full
> >> 100baseT/Half 100baseT/Full
> >> Supports auto-negotiation: Yes
> >> Advertised link modes: 10baseT/Half 10baseT/Full
> >> 100baseT/Half 100baseT/Full
> >> Advertised auto-negotiation: Yes
> >> Speed: 100Mb/s
> >> Duplex: Full
> >> Port: MII
> >> PHYAD: 1
> >> Transceiver: internal
> >> Auto-negotiation: on
> >> Current message level: 0x00000007 (7)
> >> Link detected: yes
> >>
> >> Same ethtool result returned with linaro-11.09, whose ethernet works
> >> like a charm.
> >>
> >> I checked again this linaro-11.09. ifconfig eth0 returns an MTU of
> >> 1488 Bytes, where my faulty android build makes eth0 return 1500
> >> Bytes. I believe this 1500 comes from the fact that I apply "9bbf566
> >> [PATCH] net: usb: smsc95xx: fix mtu" to my current kernel.
> >> Changing linaro build's mtu to 1500 does not impact its good
> >> performance.
> >> Decreasing the mtu to 512 on my current (and faulty) build does not
> >> improve the bad performance :-(.
> >>
> >> I am starting to go mad.
> >>
> >> Regards,
> >> Emeric
> >>
> >> ----- Mail original -----
> >> > De: "Émeric Vigier" <emeric...@savoirfairelinux.com>
> >> > À: "Zach Pfeffer" <zach.p...@linaro.org>
> >> > Cc: "Vikram Pandita" <vikram....@ti.com>,
> >> > omapandroid...@gforge.ti.com
> >> > Envoyé: Mercredi 27 Juin 2012 10:06:10
> >> > Objet: Re: [Omapandroid-discussion] smsc95xx: download ok, upload
> >> > hangs
> >> >
> >> > Hi Zach,
> >> >
> >> > Following Ti's advice
> >> > (http://e2e.ti.com/support/omap/f/849/p/196732/704452.aspx#704452),
> >> > I will try
> >> >
> >> > http://omapedia.org/wiki/4AI.1.4-P1_OMAP4_Icecream_Sandwich_Release_Notes
> >> > today.
> >> >
> >> > Also I just found out that my current 3.0.8 kernel is compiled with
> >> > gcc-4.4.3. I am currently trying with gcc-4.6 but I don't feel
> >> > confident about that.
> >> > I will try the one you mentioned right after.
> >> >
> >> > Thanks,
> >> > Emeric
> >> >
> >> > ----- Mail original -----
> >> > > De: "Zach Pfeffer" <zach.p...@linaro.org>
> >> > > À: "Émeric Vigier" <emeric...@savoirfairelinux.com>
> >> > > Cc: "Vikram Pandita" <vikram....@ti.com>,
> >> > > omapandroid...@gforge.ti.com
> >> > > Envoyé: Jeudi 21 Juin 2012 17:34:15
> >> > > Objet: Re: [Omapandroid-discussion] smsc95xx: download ok, upload
> >> > > hangs
> >> > >
> >> > > You may want to checkout our omapzoom focused tree:
> >> > >
> >> > >
> >> > > https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc47-omapzoom-stable-blob/
> >> > >
> >> > > On 21 June 2012 15:20, Émeric Vigier
> >> > > <emeric...@savoirfairelinux.com> wrote:
> >> > > > Hi Vikram,
> >> > > >
> >> > > > I made this diff and came up with few patches in smsc95xx.c and
> >> > > > usbnet.c (listed below). I applied them to my kernel, but issue
> >> > > > occurred again.
> >> > > >
> >> > > > Because linaro-12.05 uses a 3.4 kernel, and mine is only 3.0.8,
> >> > > > I
> >> > > > narrowed down the oldest linaro having ethernet working fine.
> >> > > > It came up to be linaro-11.09 for panda, which uses 3.1 kernel.
> >> > > > diff between my kernel and theirs is null for smsc95xx.c and
> >> > > > usbnet.c.
> >> > > >
> >> > > > Then something must be wrong with my config. I will make the
> >> > > > diff
> >> > > > of my config and theirs. I have to figure out what's the config
> >> > > > file linaro uses for 11.09.
> >> > > > My config file is for Android-4.0.4, quite long (and probably
> >> > > > faulty):
> >> > > > http://pastebin.com/2VXemSae
> >> > > >
> >> > > > Emeric
> >> > > >
> >> > > > ----- Mail original -----
> >> > > >> De: "Vikram Pandita" <vikram....@ti.com>
> >> > > >> À: "Émeric Vigier" <emeric...@savoirfairelinux.com>
> >> > > >> Cc: omapandroid...@gforge.ti.com
> >> > > >> Envoyé: Jeudi 21 Juin 2012 14:03:07
> >> > > >> Objet: Re: [Omapandroid-discussion] smsc95xx: download ok,
> >> > > >> upload
> >> > > >> hangs
> >> > > >>
> >> > > >> > test linaro-12.05 ICS release and see ethernet behavior -
> >> > > >> > PASSED
> >> > > >>
> >> > > >> What version kernel does this use if its working?
> >> > > >> Would be worth a try to take a diff of the smsc driver files
> >> > > >> between
> >> > > >> AOSP and this.
> >> > > >> At least says its not a hw issue.
> >> > > >>
> >> > > >>
> >> > > >> On Thu, Jun 21, 2012 at 8:30 AM, Émeric Vigier
> >> > > >> <emeric...@savoirfairelinux.com> wrote:
> >> > > >> >
> >> > > >> > Hi,
> >> > > >> >
> >> > > >> > I am experiencing ethernet issue with a pandaboard A3
> >> > > >> > (OMAP4430
> >> > > >> > rev
> >> > > >> > 2.2) featuring smsc LAN9514-JZX usbnet chipset.
> >> > > >> > My panda runs android-4.0.4 with linux kernel 3.0.8
> >> > > >> > (android-omap-panda-3.0 branch on
> >> > > >> > https://android.googlesource.com/kernel/omap.git).
> >> > > >> >
> >> > > >> > Receiving ethernet frames work fine, but transmitting them
> >> > > >> > does
> >> > > >> > not. The driver/chip seems stuck.
> >> > > >> > Moving the USB mouse (or USB keyboard key pressed) unlocks
> >> > > >> > this
> >> > > >> > behavior and transmission gets resumed for a second or two.
> >> > > >> > Then
> >> > > >> > ethernet transmission gets stuck again.
> >> > > >> >
> >> > > >> > Recently, I cherry-picked dozen of usbnet and smsc95xx
> >> > > >> > patches,
> >> > > >> > and
> >> > > >> > managed to get a watchdog barking (see test 21 below).
> >> > > >> >
> >> > > >> > Unfortunately I have no JTAG probe, so I am limited to
> >> > > >> > driver
> >> > > >> > tweaks and tryouts...
> >> > > >> > Here are the tests I have performed so far, along with a
> >> > > >> > todo
> >> > > >> > list:
> >> > > >> >
> >> > > >> > FAILED means that the issue came up.
> >> > > >> > PASSED means that the issue has not come up.
> >> > > >> > DONE, NOT DONE, ONGOING are more related to a todo list than
> >> > > >> > a
> >> > > >> > test
> >> > > >> > report.
> >> > > >> >
> >> > > >> > 1. check with constant cpu load (stress -c 2) - FAILED
> >> > > >> > 2. check if problem occurs on older releases (non ICS) - NOT
> >> > > >> > DONE
> >> > > >> > 3. try CONFIG_PL310_ERRATA_769419 patch in cpuidle - FAILED
> >> > > >> > 4. check without USB hub connected - FAILED
> >> > > >> > 5. check with usbcore.autosuspend=600 added to cmdline -
> >> > > >> > FAILED
> >> > > >> > 6. patch ehci-omap.c to verify clock frequency - NOT DONE
> >> > > >> > 7. check with CPU1 offlined - FAILED
> >> > > >> > 8. check ethtool on android - FAILED
> >> > > >> > Cannot get register dump: Operation not supported on
> >> > > >> > transport
> >> > > >> > endpoint
> >> > > >> > 9. check without USB_EHCI_TT_NEWSCHED - FAILED
> >> > > >> >
> >> > > >> > 10. try to unbind, rebind smsc95xx - FAILED
> >> > > >> > 11. disable turbo_mode and reset the chip - FAILED
> >> > > >> > 12. test with "CONFIG_NO_HZ is not set" - FAILED
> >> > > >> > 13. test with another external USB ethernet dongle - NOT
> >> > > >> > DONE
> >> > > >> > 14. test linaro-12.05 ICS release and see ethernet behavior
> >> > > >> > -
> >> > > >> > PASSED
> >> > > >> > Ethernet runs fine on release:
> >> > > >> > . 12.05 tracking - PASSED
> >> > > >> > . 11.10 tracking - PASSED
> >> > > >> > . 11.09 release - PASSED
> >> > > >> > 15. try with "netcfg eth0 dhcp" - FAILED
> >> > > >> > 16. check datasheet - ONGOING
> >> > > >> > registers description is missing on 9514.pdf, only eeprom is
> >> > > >> > described
> >> > > >> > 17. adapt driver to ethtool - DONE
> >> > > >> > 18. dump registers and check against linaro 11.09 - ONGOING
> >> > > >> > 19. ethtool returns heaps of "0", the pattern I added to the
> >> > > >> > array
> >> > > >> > is all replaced by "0"...
> >> > > >> > Actually the eeprom is blank. I found it out since each time
> >> > > >> > I
> >> > > >> > unbind/bind the device to smsc95xx driver, I get a random
> >> > > >> > MAC
> >> > > >> > address...
> >> > > >> >
> >> > > >> > 20. test with 11.09 linaro kernel - NOT DONE
> >> > > >> > zygote not starting
> >> > > >> > 21. uploading 24MB file on the web (http://dl.free.fr) -
> >> > > >> > FAILED
> >> > > >> > This occurred only with these patches added to my kernel:
> >> > > >> > From 8a78335 [PATCH] usbnet: consider device busy at each
> >> > > >> > recieved
> >> > > >> > packet
> >> > > >> > From 5d5440a [PATCH] usbnet: don't clear urb->dev in
> >> > > >> > tx_complete
> >> > > >> > From 4231d47 [PATCH] net/usbnet: avoid recursive locking in
> >> > > >> > usbnet_stop()
> >> > > >> > From 1aa9bc5 [PATCH] usbnet: use netif_tx_wake_queue
> >> > > >> > instead
> >> > > >> > of
> >> > > >> > netif_start_queue
> >> > > >> > From 7bdd402 [PATCH] net/usbnet: reserve headroom on rx
> >> > > >> > skbs
> >> > > >> > From 0956a8c [PATCH] usbnet: increase URB reference count
> >> > > >> > before
> >> > > >> > usb_unlink_urb
> >> > > >> > From 9bbf566 [PATCH] net: usb: smsc95xx: fix mtu
> >> > > >> > From 720f3d7 [PATCH] usbnet: fix leak of transfer buffer of
> >> > > >> > dev->interrupt
> >> > > >> > From a472384 [PATCH] usbnet: fix failure handling in
> >> > > >> > usbnet_probe
> >> > > >> > From 5b6e9bc [PATCH] usbnet: fix skb traversing races
> >> > > >> > during
> >> > > >> > unlink(v2)
> >> > > >> > From 07d69d4 [PATCH] smsc95xx: mark link down on startup
> >> > > >> > and
> >> > > >> > let
> >> > > >> > PHY interrupt
> >> > > >> > a timeout occurred:
> >> > > >> > http://pastebin.com/KpaTJY3N
> >> > > >> >
> >> > > >> > My current kernel is based on:
> >> > > >> > commit 52f476403350050beb0dff135a55c06c9e7a82a9
> >> > > >> > Author: Jean-Baptiste Queru <j...@google.com>
> >> > > >> > Subject: Revert "gpu: pvr: Revert to 1.8@550175"
> >> > > >> >
> >> > > >> > I managed to get a register and PHY dump when upload is
> >> > > >> > stuck,
> >> > > >> > thanks to ethtool:
> >> > > >> >
> >> > > >> > 000: 01 00 00 ec 00 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 010: 04 00 00 00 00 14 00 00 00 00 00 00 00 20 00 00
> >> > > >> > 020: 81 00 00 00 00 00 11 01 1f 00 00 1f a0 30 f8 00
> >> > > >> > 030: 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00
> >> > > >> > 040: 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 060: 00 00 00 00 00 00 00 00 00 80 00 00 00 20 00 00
> >> > > >> > 070: 00 00 00 00 83 0f 83 0f 00 00 00 00 0f 06 0f 06
> >> > > >> > 080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 0a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 0b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 0c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 100: 0c 20 10 00 f7 6f 00 00 a2 7d 13 dd 00 00 00 40
> >> > > >> > 110: 20 00 00 80 40 09 00 00 e1 c1 00 00 00 00 00 00
> >> > > >> > 120: 00 81 00 00 ff ff 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 130: 00 31 00 00 2d 78 00 00 07 00 00 00 c3 c0 00 00
> >> > > >> > 140: e1 0d 00 00 e1 c1 00 00 0b 00 00 00 ff ff 00 00
> >> > > >> > 150: ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00
> >> > > >> > 160: ff ff 00 00 ff ff 00 00 ff ff 00 00 00 00 00 00
> >> > > >> > 170: 40 00 00 00 02 00 00 00 e1 00 00 00 ff ff 00 00
> >> > > >> > 180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> > > >> > 190: ff ff 00 00 ff ff 00 00 00 00 00 00 0a 00 00 00
> >> > > >> > 1a0: 00 00 00 00 c8 00 00 00 50 00 00 00 58 10 00 00
> >> > > >> >
> >> > > >> > But the 9514.pdf datasheet I have misses register
> >> > > >> > description.
> >> > > >> > Then decoding all this is quite troublesome.
> >> > > >> >
> >> > > >> > I saw that Ubuntu release got trouble with this chipset and
> >> > > >> > acpi.
> >> > > >> > But there is no acpi on Android AFAIK.
> >> > > >> > Did anyone else experience this issue?
> >> > > >> > Does anyone have an idea where it can come from?
> >> > > >> >
> >> > > >> >
> >> > > >> > Thanks a lot for your kind support,
> >> > > >> > Emeric
> >> > > >> > _______________________________________________
> >> > > >> > Omapandroid-discussion mailing list
> >> > > >> > Omapandroid...@gforge.ti.com
> >> > > >> > https://gforge.ti.com/mailman/listinfo/omapandroid-discussion
> >> > > >>
> >> > > >
> >> > > > _______________________________________________
> >> > > > Omapandroid-discussion mailing list
> >> > > > Omapandroid...@gforge.ti.com
> >> > > > https://gforge.ti.com/mailman/listinfo/omapandroid-discussion
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Zach Pfeffer
> >> > > Android Platform Team Lead, Linaro Platform Teams
> >> > > Linaro.org | Open source software for ARM SoCs
> >> > > Follow Linaro: http://www.facebook.com/pages/Linaro
> >> > > http://twitter.com/#!/linaroorg -
> >> > > http://www.linaro.org/linaro-blog
> >> > >
>
>
>
> --
> Zach Pfeffer
> Android Platform Team Lead, Linaro Platform Teams
> Linaro.org | Open source software for ARM SoCs
> Follow Linaro: http://www.facebook.com/pages/Linaro
> http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog