Olof Johansson wrote: > > Stephen, > > On Mon, Dec 20, 2010 at 4:26 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote: > > > > Olof, > > > > I've been looking into getting mainline Linux better suited for developing > > the ALSA driver. Specifically, > > > > git://android.git.kernel.org/kernel/tegra.git for-next > > > > The primary thing I'm missing is an SDHCI driver. I notice that there is one > > in linux-tegra-2.6.36, and a different version derived from that in > > chromeos-2.6.37-rc5. > > The one in the chromeos tree is the one I have cleaned up for mainline > inclusion. You probably saw it posted here on the list last week, I > checked in the first version that I posted and will revise it on > future branches as it's updated. Moving the old driver with all its > additional quirks forward was more work than finally upstreaming the > driver. Were those additional quirks to WAR missing stuff in the driver rather than HW working in unexpected ways then? Otherwise, seems like they'd be needed either way? > > > > [ 11.985039] mmc2: ADMA error > > [ 11.988087] mmc2: Got data interrupt 0x02000000 even though no data > > operation was in progress. > > [ 11.996827] mmcblk0: retrying using single block read > > That looks like you're missing the "sdhci: don't finish commands in > flight" patch from the same series. Thanks. Some silly reason I just grabbed the sdhci files rather than cherry- picking the changes from the chromeos branch. Made more work for myself... Anyway, I had a couple of comments to make on the SDHCI driver in the chromeos branch: 1) In the platform_data, the various GPIOs used are listed, but harmony_sdhci_init is currently calling gpio_request/tegra_gpio_enable/gpio_direction_enable on those. I figured the SDHCI driver should be performing those operations in a probe call or similar? That way, every board doesn't have to duplicate all those calls, and for each SDHCI port. 2) Should tegra_sdhci_device1 be in devices.c (as it is in linux-tegra-2.6.36) so that it can be shared across all Tegra machines. I figured that initialization would work like: devices.[hc] define tegra_sdhci_device*, without .dev.platform_data board-harmony.c defines tegra_sdhci_platform_data1 board-harmoony.c:tegra_harmony_init() assigns tegra_sdhci_device*.dev.platform_data board-harmony.c:harmony_devices[] includes tegra_sdhci_device* This would reduce the SDHCI-related code for each machine to so little that a separate board-harmony-sdhci.c probably might not even be needed? -- Nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html