[GIT PULL v2 0/3] TrimSlice updates for 2.6.40

[GIT PULL v2 0/3] TrimSlice updates for 2.6.40

[Mike Rapoport]

Hi Colin,
Please consider pulling TrimSlice updates for 2.6.40 merge window.
These patches add registration of i2c, audio and USB devices.

v2 changes:
- update CDEV1 pinmux as per Stephen suggestion
- use GPIO table for USB-related GPIOs

The following changes since commit eed631e0d741d1a1067cfc6d709fdf2363126f9c:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable (2011-05-15 10:22:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux-tegra.git trimslice/upstream

Mike Rapoport (3):
      ARM: tegra: trimslice: register i2c busses and devices
      ARM: tegra: trimslice: add audio devices and clocks
      ARM: tegra: trimslice: enable USB ports

 arch/arm/mach-tegra/board-trimslice-pinmux.c |    7 ++-
 arch/arm/mach-tegra/board-trimslice.c        |   91 ++++++++++++++++++++++++++
 arch/arm/mach-tegra/board-trimslice.h        |    3 +
 3 files changed, 99 insertions(+), 2 deletions(-)

[GIT PULL v2 0/3] TrimSlice updates for 2.6.40

[Stephen Warren]

Mike Rapoport wrote at Monday, May 16, 2011 2:23 PM:
> Hi Colin,
> Please consider pulling TrimSlice updates for 2.6.40 merge window.
> These patches add registration of i2c, audio and USB devices.

Mike, a comment and a question:

First off, your git branch isn't based on tegra's for-next branch, but
rather something much in the future of it. Hence, the merge brings in a
bunch of unrelated changes. It is a fast-forward though so it's
probably fine?

Second, I tried to test this, but failed. I hit two issues:

1) USB didn't seem to work for me; the following prints continuously:

[   93.952248] usb 3-1: new high speed USB device number 126 using tegra-ehci
[   94.022291] hub 3-0:1.0: unable to enumerate USB device on port 1

This means I can't use the built-in SSD as the root filesystem.

I see this problem irrespective of whether I tell U-Boot to initialize
USB before booting or not.

Which branches did you have merged to test this? I did:

* Create a new branch from Tegra's for-next.
* Merge the branch from your pull request.
* Merge ASoC for-2.6.40 branch to pick up the audio driver.
* Cherry-pick a few I2C fixes I've been working on. I don't recall if
they are necessary for Trimslice or not, but shouldn't hurt.

2) I can boot into a recent ChromeOS filesystem on the SD card, and
see e.g. the audio driver initialize OK. However, both speaker-test
and aplay segfault immediately. They work fine on other HW, such as
Seaboard, with this disk image. I know this used to work on Trimslice
a few weeks back, so perhaps I'll go and try an older disk image.

-- 
nvpublic

[GIT PULL v2 0/3] TrimSlice updates for 2.6.40

[mike at compulab.co.il]

Hi Stephen,

On Tue, May 17, 2011 at 01:41:56PM -0700, Stephen Warren wrote:
> Mike Rapoport wrote at Monday, May 16, 2011 2:23 PM:
> > Hi Colin,
> > Please consider pulling TrimSlice updates for 2.6.40 merge window.
> > These patches add registration of i2c, audio and USB devices.
> 
> Mike, a comment and a question:
> 
> First off, your git branch isn't based on tegra's for-next branch, but
> rather something much in the future of it. Hence, the merge brings in a
> bunch of unrelated changes. It is a fast-forward though so it's
> probably fine?
 
My branch is based on recent Linus' tree. I presume Colin will reabse
his -next on it before sending pull request...

> Second, I tried to test this, but failed. I hit two issues:
> 
> 1) USB didn't seem to work for me; the following prints continuously:
> 
> [   93.952248] usb 3-1: new high speed USB device number 126 using tegra-ehci
> [   94.022291] hub 3-0:1.0: unable to enumerate USB device on port 1
> 
> This means I can't use the built-in SSD as the root filesystem.
>
> I see this problem irrespective of whether I tell U-Boot to initialize
> USB before booting or not.

Yeah, this is caused by issue with USB1 port reset. Greg already took
the patch that fixes it (1).

> Which branches did you have merged to test this? I did:
> 
> * Create a new branch from Tegra's for-next.
> * Merge the branch from your pull request.
> * Merge ASoC for-2.6.40 branch to pick up the audio driver.
> * Cherry-pick a few I2C fixes I've been working on. I don't recall if
> they are necessary for Trimslice or not, but shouldn't hurt.

I'd rather take the ASoC for-2.6.40 and apply the first two patches +
I2C fixes.

> 2) I can boot into a recent ChromeOS filesystem on the SD card, and
> see e.g. the audio driver initialize OK. However, both speaker-test
> and aplay segfault immediately. They work fine on other HW, such as
> Seaboard, with this disk image. I know this used to work on Trimslice
> a few weeks back, so perhaps I'll go and try an older disk image.

I've never tried audio with ChromiumOS. I've tested with Maverick and
aplay didn't complain.
>
[1] http://www.mail-archive.com/linux-tegra at vger.kernel.org/msg00581.html

--
Sincerely yours,
Mike.

[GIT PULL v2 0/3] TrimSlice updates for 2.6.40

[Stephen Warren]

mike at compulab.co.il wrote at Wednesday, May 18, 2011 10:13 AM:
> Hi Stephen,
> 
> On Tue, May 17, 2011 at 01:41:56PM -0700, Stephen Warren wrote:
> > Mike Rapoport wrote at Monday, May 16, 2011 2:23 PM:
> > > Hi Colin,
> > > Please consider pulling TrimSlice updates for 2.6.40 merge window.
> > > These patches add registration of i2c, audio and USB devices.
> >
> > Second, I tried to test this, but failed. I hit two issues:
> >
> > 1) USB didn't seem to work for me; the following prints continuously:
> >
> > [   93.952248] usb 3-1: new high speed USB device number 126 using tegra-ehci
> > [   94.022291] hub 3-0:1.0: unable to enumerate USB device on port 1
> >
> > This means I can't use the built-in SSD as the root filesystem.
> >
> > I see this problem irrespective of whether I tell U-Boot to initialize
> > USB before booting or not.
> 
> Yeah, this is caused by issue with USB1 port reset. Greg already took
> the patch that fixes it (1).
> [1] http://www.mail-archive.com/linux-tegra at vger.kernel.org/msg00581.html

OK, I applied that, and USB appears to work; I could mount the SSD OK.

I found a way to get around aplay/speaker-test crashing (which happens
both with the ChromeOS filesystem or the Ubuntu filesystem shipped with
the Trimslice). If you specify which ALSA PCM device to use ("-D hw:0,0")
then they both work OK.

That said, I do still see some issues. Specifically, when I play audio,
USB and/or MMC IO appear to go south, and then recovers when audio
playback terminates:

chronos at localhost ~ $ aplay -D hw:0,0 /home/abba-dq-48000-stereo.wav 
Playing WAVE '/home/abba-dq-48000-stereo.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
[   90.434741] usb 3-1: USB disconnect, device number 2
[   90.722342] hub 3-0:1.0: unable to enumerate USB device on port 1
<repeats about every 300mS>
^C Aborted by signal Interrupt...
chronos at localhost ~ $ [   97.262302] usb 3-1: new high speed USB device number 27 using tegra-ehci
[   97.684058] usb 3-1: New USB device found, idVendor=05e3, idProduct=0718
[   97.690758] usb 3-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2
[   97.698354] usb 3-1: Product: USB Storage
[   97.702511] usb 3-1: SerialNumber: 000000000033
[   97.710500] scsi1 : usb-storage 3-1:1.0
[   99.492400] scsi 1:0:0:0: Direct-Access     SanDisk  SSD P4 8GB       0015 PQ: 0 ANSI: 0
[   99.502508] sd 1:0:0:0: [sda] 15649196 512-byte logical blocks: (8.01 GB/7.46 GiB)
[   99.522376] sd 1:0:0:0: [sda] Write Protect is off
[   99.527169] sd 1:0:0:0: [sda] Assuming drive cache: write through
[   99.572658] sd 1:0:0:0: [sda] Assuming drive cache: write through
[   99.592671]  sda: sda1
[   99.597539] sd 1:0:0:0: [sda] Assuming drive cache: write through
[   99.604184] sd 1:0:0:0: [sda] Attached SCSI disk

Sometimes this affects mmcblk0 too.

This happens irrespective of whether my root filesystem is on USB (with
no SD card plugged in) or on SD card.

That said, I think these issues are some pre-existing condition that was
simply exposed because this patchset now enables USB and audio. Hence,
not a problem with the changes in the patch set itself.

Do you have a kernel branch that's been tested with the Ubuntu build
that shipped on the TrimSlice's SSD that I could test with? Alternatively,
how did you create the filesystem you're testing with, so I could test
with that instead?

Thanks.

-- 
nvpublic