omap35x mmc support

omap35x mmc support

[twebb]

Does the omap kernel support SD/MMC cards on all of the three
interfaces on OMAP35xx: SD/MMC1, SD/MMC2, and SD/MMC3?

Thanks,
twebb

Re: omap35x mmc support

[David Brownell]

On Tuesday 03 March 2009, twebb wrote:
> Does the omap kernel support SD/MMC cards on all of the three
> interfaces on OMAP35xx: SD/MMC1, SD/MMC2, and SD/MMC3?

I've seen it work for MMC1 and MMC2, and recent patches
should have improved the MMC3 support.

Note that MMC3 only supports 1.8V; and MMC2 needs some kind
of level shifting solution to use other voltages, such as a
transceiver.   (Or a dual-voltage managed NAND device.)

Re: omap35x mmc support

[Adrian Hunter]

David Brownell wrote:
> On Tuesday 03 March 2009, twebb wrote:
>> Does the omap kernel support SD/MMC cards on all of the three
>> interfaces on OMAP35xx: SD/MMC1, SD/MMC2, and SD/MMC3?
> 
> I've seen it work for MMC1 and MMC2, and recent patches
> should have improved the MMC3 support.
> 
> Note that MMC3 only supports 1.8V; and MMC2 needs some kind
> of level shifting solution to use other voltages, such as a
> transceiver.   (Or a dual-voltage managed NAND device.)

For MMC3 this patch:

    http://lkml.org/lkml/2009/1/27/101

seems to be missing.

Re: omap35x mmc support

[twebb]

>
> For MMC3 this patch:
>
>   http://lkml.org/lkml/2009/1/27/101
>
> seems to be missing.
>

Thanks.  Would this patch be applicable whether MMC3 is functioning as
SD or MMC or SDIO interface?

And on a bit of a tangent (but relevant to the link you provided),
what's the logic behind so many OMAP24XX references being used in
OMAP34XX (and even 35xx) code?  I'm sure there's a good reason; but
being new to using an OMAP processor (35xx), I'm just curious what it
is.  It gets confusing, particularly without knowing the reasoning
behind it.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap35x mmc support

[Adrian Hunter]

twebb wrote:
>> For MMC3 this patch:
>>
>>   http://lkml.org/lkml/2009/1/27/101
>>
>> seems to be missing.
>>
> 
> Thanks.  Would this patch be applicable whether MMC3 is functioning as
> SD or MMC or SDIO interface?

Yes

> And on a bit of a tangent (but relevant to the link you provided),
> what's the logic behind so many OMAP24XX references being used in
> OMAP34XX (and even 35xx) code?  I'm sure there's a good reason; but
> being new to using an OMAP processor (35xx), I'm just curious what it
> is.  It gets confusing, particularly without knowing the reasoning
> behind it.

It is just code reuse.  OMAP2 comes out so things are coded for OMAP2.
Then OMAP3 comes out, and anything that is the same is reused.

Re: omap35x mmc support

[Tony Lindgren]

* Adrian Hunter <adrian.hunter@nokia.com> [090304 06:25]:
> twebb wrote:
>>> For MMC3 this patch:
>>>
>>>   http://lkml.org/lkml/2009/1/27/101
>>>
>>> seems to be missing.
>>>
>>
>> Thanks.  Would this patch be applicable whether MMC3 is functioning as
>> SD or MMC or SDIO interface?
>
> Yes
>
>> And on a bit of a tangent (but relevant to the link you provided),
>> what's the logic behind so many OMAP24XX references being used in
>> OMAP34XX (and even 35xx) code?  I'm sure there's a good reason; but
>> being new to using an OMAP processor (35xx), I'm just curious what it
>> is.  It gets confusing, particularly without knowing the reasoning
>> behind it.
>
> It is just code reuse.  OMAP2 comes out so things are coded for OMAP2.
> Then OMAP3 comes out, and anything that is the same is reused.

Yeah from maintenance point of view we need to recycle code. Otherwise
we would already have something like six copies of the I2C controller,
four copies of the DMA controller, three different clock frameworks
and so on..

Tony