RE: SDHCI driver for Tegra

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux