Hi, On Mon, Dec 20, 2010 at 8:00 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote: > 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. Yeah, already pointed out in the previous reviews and will be addressed. > 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? Yes, agreed, and that was roughly what I had in mind as well. I have focused initially on getting the driver submitted, and was going to loop back and deal with the board pieces separate. The merge path for the two changes is independent, since the sdhci driver would go through the MMC tree, and the board files through the tegra tree. -Olof -- 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
