At Wed, 15 Dec 2010 14:17:27 +0100,
Takashi Iwai wrote:
>
> Let's enable the new bus-width tests on SDHCI hosts unless 1-bit data
> is set forcibly.
>
> Signed-off-by: Takashi Iwai
Please drop this patch.
After a short discussion with Philip, we concluded that it's safer to
enable in individua
> I'll whip up the changes and see how invasive it gets as a -pltfm
> driver. It shouldn't be too bad. I'll repost the series that way, but
> I will still keep the quirks for now and do a pass reworking these as
> well as others separately (see below).
Sounds great!
> Anyway, I wonder if it does
In the patch "mmc: Add support for JMicron 388 SD/MMC controller",
I changed a wrong field for MMC during rewrite. Fixed now.
Signed-off-by: Takashi Iwai
---
drivers/mmc/host/sdhci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc
Let's enable the new bus-width tests on SDHCI hosts unless 1-bit data
is set forcibly.
Signed-off-by: Takashi Iwai
---
This is a patch to be applied after
"mmc: Test bus-width for old MMC devices (v2)"
drivers/mmc/host/sdhci.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
d
On Wed, Dec 15, 2010 at 12:59:11PM +0100, Wolfram Sang wrote:
>
> > > If there is something yet missing in sdhci-pltfm which you need, it
> > > probably is worth adding it there. Chances are good that other
> > > pltfm-users might want that, too.
> >
> > Taking that to an extreme, any sdhci drive
> > If there is something yet missing in sdhci-pltfm which you need, it
> > probably is worth adding it there. Chances are good that other
> > pltfm-users might want that, too.
>
> Taking that to an extreme, any sdhci driver should plug into sdhci-pltfm and
> just add the hooks needed. It will re
> > That won't scale for long, I fear (and will make sdhci.c an unreadable
> > mess). We need less quirks and more flexible means to handle flawed
> > controllers, I'd think.
>
> It won't scale for long, but it'll give a buffer while a cleaned up
> quirk structure can be hashed out and implemente
On Wed, Dec 15, 2010 at 11:37:30AM +0100, Wolfram Sang wrote:
>
> > Still, I don't see the point -- the amount of code would be about the
> > same between wrapping it with a coat of workarounds and op structures,
> > gpio setup, etc, and just doing a separate simple driver. The code shared
> > is
> > Return value is not checked.
>
> Good catch. Thanks.
It is checked in sdhci-pltfm.c ;)
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
On Wed, Dec 15, 2010 at 05:03:44PM +0530, Pavan Kondeti wrote:
> On 12/15/2010 10:19 AM, Olof Johansson wrote:
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (res == NULL)
> > + return -ENODEV;
> > +
> > + ioaddr = ioremap(res->start, res->end - res->star
On Wed, Dec 15, 2010 at 11:57:01AM +0100, Wolfram Sang wrote:
> On Tue, Dec 14, 2010 at 10:49:34PM -0600, Olof Johansson wrote:
> > Some controllers can't handle SDIO IRQ properly. Give a way to
> > disable it.
> >
> > Signed-off-by: Olof Johansson
> > ---
> > drivers/mmc/host/sdhci.c |6 ++
On 12/15/2010 10:19 AM, Olof Johansson wrote:
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (res == NULL)
> + return -ENODEV;
> +
> + ioaddr = ioremap(res->start, res->end - res->start);
> +
Return value is not checked.
> + sdhci = sdhci_alloc_ho
Hi,
On Wed, Dec 15, 2010 at 01:23:58PM +0200, Mike Rapoport wrote:
> Hi Olof,
>
> Overall looks good, just some nitpicking comments.
>
[...]
> > +struct tegra_sdhci_platform_data {
> > + int cd_gpio;
> > + int wp_gpio;
> > + int power_gpio;
>
> The power_gpio seems to be unused...
Yep,
On Wed, Dec 15, 2010 at 12:03:12PM +0100, Wolfram Sang wrote:
>
> > > Really appreciate if not using the valuable quirk resource, which is u32.
> >
> > No big deal. Next person that needs a quirk bit gets to bump the data
> > type to u64.
>
> That won't scale for long, I fear (and will make sdhc
Hi Olof,
Overall looks good, just some nitpicking comments.
On 12/15/10 06:49, Olof Johansson wrote:
> SDHCI driver for Tegra. Pretty straight forward, a few pieces of
> functionality left to fill in but nothing that stops it from going
> upstream. Board enablement submitted separately.
>
> This
> > Really appreciate if not using the valuable quirk resource, which is u32.
>
> No big deal. Next person that needs a quirk bit gets to bump the data
> type to u64.
That won't scale for long, I fear (and will make sdhci.c an unreadable
mess). We need less quirks and more flexible means to hand
On Tue, Dec 14, 2010 at 10:49:34PM -0600, Olof Johansson wrote:
> Some controllers can't handle SDIO IRQ properly. Give a way to
> disable it.
>
> Signed-off-by: Olof Johansson
> ---
> drivers/mmc/host/sdhci.c |6 +-
> include/linux/mmc/sdhci.h |2 ++
> 2 files changed, 7 insertions
On Wed, Dec 15, 2010 at 05:42:14AM -0500, zhangfei gao wrote:
> On Tue, Dec 14, 2010 at 11:49 PM, Olof Johansson wrote:
> > Some controllers can't handle SDIO IRQ properly. Give a way to
> > disable it.
> >
> > Signed-off-by: Olof Johansson
> > ---
> > drivers/mmc/host/sdhci.c | 6 +-
> >
On Tue, Dec 14, 2010 at 11:49 PM, Olof Johansson wrote:
> Some controllers can't handle SDIO IRQ properly. Give a way to
> disable it.
>
> Signed-off-by: Olof Johansson
> ---
> drivers/mmc/host/sdhci.c | 6 +-
> include/linux/mmc/sdhci.h | 2 ++
> 2 files changed, 7 insertions(+), 1 d
> Still, I don't see the point -- the amount of code would be about the
> same between wrapping it with a coat of workarounds and op structures,
> gpio setup, etc, and just doing a separate simple driver. The code shared
> is really just the resource allocation pieces.
? Saving 150 out of 260 lin
On Wed, Dec 15, 2010 at 02:43:07AM -0600, Olof Johansson wrote:
> Hi,
>
> On Wed, Dec 15, 2010 at 09:35:46AM +0100, Wolfram Sang wrote:
>
> > Can't you just use sdhci-pltfm?
>
> Not if I want to hide some of the SoC-specific errata with driver-local
> workarounds instead of polluting the global
Hi,
On Wed, Dec 15, 2010 at 09:35:46AM +0100, Wolfram Sang wrote:
> Can't you just use sdhci-pltfm?
Not if I want to hide some of the SoC-specific errata with driver-local
workarounds instead of polluting the global quirk namespace with them.
Otherwise, yeah, it'd be a good candidate for it.
Hi Olof,
On Tue, Dec 14, 2010 at 10:49:36PM -0600, Olof Johansson wrote:
> SDHCI driver for Tegra. Pretty straight forward, a few pieces of
> functionality left to fill in but nothing that stops it from going
> upstream. Board enablement submitted separately.
>
> This driver is based on an origin
23 matches
Mail list logo
