[Snowball] USB doesn't work on IglooKernel V3.1

Working with git://igloocommunity.org/git/kernel/igloo-kernel.git,

Once androidized, USB works on 'linux-integration-3.0-ux500' but doesn't on 'integration', the 3.1.

Androidized 'linux-integration-3.0-ux500' can be found here:
http://git.linaro.org/git/people/mpoirier/snowball/linux-integration-3.0-ux500-androidized.git

Androidized version of a 3.1 integration, though getting old, can be found under the 'android' branch on
git://igloocommunity.org/git/kernel/igloo-kernel.git

Apparently this is due to an upstream patch which forces OTG, which is currently broken on Snowball. Philippe will send out an email Monday PM for escalation into ST-Ericsson.

Deepak (Kernel WG Tech Lead) will try and help us solve this problem by assigning some engineers but first we need to make sure we give them as much information as possible.

Philippe: Can you please provide the branch you need to get the kernel including logs and details of the problem.

IK stands for igloo-kernel (git://igloocommunity.org/git/kernel/igloo-kernel.git)

Problem met during MUSB 3.1 driver rebase:
The change 6228596: 'usb: musb: drop a gigantic amount of ifdeferry' introduced by "Felipe Balbi <email address hidden>" make the usb-3.0 topic branch (IK/usb-3.0) rebase difficult.
The rebased usb 3.1 topic branch (IK/usb-3.1 HEAD: eb5cb770) is my first try to solve the problem, but on Snowball we can't support full OTG support, so we have to revert "usb: musb: drop a gigantic amount of ifdeferry", to support USB host mode only.

On branch IK/android (first android Ginger Bread with 3.1 Linaro kernel from Mathieu),
I try to revert this commit with commits fd7aeaf: 'Revert "usb: musb: drop a gigantic amount of ifdeferry"' and
, 9faa4d3: 'Revert "mach-ux500: musb: Now musb is always in OTG mode"'
but I failed to have a functionnal USB mouse on Snowball, the USB mouse is recognized but no event has been received by Android, this is my latest status.
On 3.0 or older kernels, we are lucky the USB mouse is recognized and partially works if it's plugged before booting the board, now it's totally broken.
But there are multiple problems on USB HOST mode on Snowball due to this hardware problem: https://bugs.launchpad.net/bugs/894828).

My thoughts:
An USB specialist have to redo the usb rebase onto v3.1 with the Snowball HW pb in mind and make the minimum
workaround to have a functionnal USB mouse on such a board.

Has this been reproduced in the latest Linus HEAD (i.e 3.2-rc?)

On Thu, Dec 15, 2011 at 6:45 AM, Deepak Saxena <email address hidden> wrote:

> Has this been reproduced in the latest Linus HEAD (i.e 3.2-rc?)

We definately need to know if it's a mainline problem, we cannot spend
kernel WG resources maintaining the "IK" fork. If it's in mainline we may
look at it.

That said all USB key people are on vacation so there is no way for
me or Niklas to get into this quickly, given that a real smart guy like
Philippe has already been into this it's unrealistic for me atleast to have
a clue about this code within the week, and then I'm in vacation...

Sorry,
Linus Walleij

I never try on Linus 3.2-rc yet.
This is a test that I have to put in my pending tasks list.
Only Anmar or Lee can reschedule and change priority of these tasks.

Sorry,
Philippe Langlais

At the moment, Philippe is working hard at debugging a blocking bug.
Once he is finished, he will switch to the bug.

After many efforts, I succeded to setup my STM trace environment on Snowball with JTAG Lauterbach combiprobe
and took traces after issue a reboot command in console.

One file contains PRCMU trace see trace-PRCMU-reboot-pb.log (in the attached .tar.bz2):
we saw at end the RESET command send by linux kernel: IT6_A9WD_SFTRST_IN & SOFT_RESET_ACTIVE,
after only a specialist can tell if it's OK.

The second file Trace_PRCMU_reboot+ftrace.log (in the attached .tar.bz2) contains a STM capture trace with console+PRCMU+ftrace function interleaved.
How to read this trace:
"ssssss.nnnnnnnnn" is the STM timestamp seconds.nanoseconds
lines begin with [ssssss.nnnnnnnnn 5:00]* ===> PRCMU traces: example "[000113.337969740 5:00]IT6_A9WD_SFTRST_IN"
lines begin with [ssssss.nnnnnnnnn 0:00]<d>string ===> Linux console printk: example " [000113.337983960 0:00]<0>db8500_prcmu_system_reset after writel(1, PRCM_APE_SOFTRST)"
lines begin with [ssssss.nnnnnnnnn 0:00]function <-caller ===> ftrace function traces: example "[000113.315268900 0:00]ux500_restart <-machine_restart+0x58"

I can't do more software traces, the second stage is to analyse in parallel the reset pin behavior with an analyzer.
But before to go further, I wait a Robert Marklund workaround patch based on the usage of a Watchdog (PRCMU or AB).

Remark:
Often, I noticed also that the reset button has no effect on Snowball board, is it an already known hardware problem?

Hi,

Sorry, ignore previous comment, this isn't for this Bug, a multitask conflict.
Now I switch to this bug and test the USB behavior on Snowball with linus v3.2-rc5 kernel.

Cheers,
 Philippe

I tested USB HOST + USB mouse on Snowball (v5) with Linus v3.2-rc5 mainline kernel, the status:
the behavior is slightly different than with the Igloo kernel v3.1 but the result is the same, the USB mouse doesn't work.
The device is correctly detected and mounted on /dev/input/event2 but no data is received.
I use the evtest tool to dump input events, but I see nothing on event2, I try with an old STE Linaro kernel (2.6.38) in
the same condition (same board & rootfs) and that works.
I tried also with a v3.1 Igloo kernel with same musb driver as mainline (I revert only STE USB internal patches) and I get the same behavior as v3.2-rc5.
Sure there is a regression in USB driver since MUSB mainline changes introduced by v3.1 kernel.

I attach the u8500_defconfig patch I use to activate USB necessary drivers.
I attach a second patch to fix a regression introduced by MUSB mainline change where MUSB supports OTG only mode,
but this patch can't be applied for Snowball because hardware don't support OTG and only host mode is necessary
to have an USB mouse for Android, but this patch normally has to be applied for HREF boards (CONFIG_USB_MUSB_OTG,CONFIG_USB_MUSB_PERIPHERAL & CONFIG_USB_MUSB_HOST don't exist anymore).

In all cases to fix 3.1 and higher Igloo Kernel, a STE USB specialist has to rework MUSB STE part due to mainline changes.

On Fri, Dec 16, 2011 at 3:46 PM, Philippe Langlais
<email address hidden> wrote:

> I attach a second patch to fix a regression introduced by MUSB mainline change where MUSB supports OTG only mode,

Philippe can you please send this patch also to
<email address hidden> and Felipe
Balbi, the MUSB maintainer if it should be applied to mainline? It
would be super,
so we atleast fix the obvious problems.

Yours,
Linus Walleij

Today, I reverted again the commit "usb: musb: drop a gigantic amount of ifdeferry" and configure USB
in host mode only for Snowball, and redone USB mouse tests with a Linaro nano image and it seems to work.
But, we have to check with an Android Linaro build to confirm this.
The modifications are pushed onto stable-linux-ux500-3.1 Igloo Kernel branch (2 last revert commits).

Mathieu, can you apply these changes onto an Android 3.1 kernel and test it?
Thanks.

Philippe: Matheiu is off untll the new year. I will ping the
ST-Ericsson to see if there are any takers.

I androidized stable-linux-ux500-3.1 and USB was proven to
work. I pushed the result to IK under stable-android-ux500-3.1 and
stable-android-ux500-3.1-mali-v9.