Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
Hi Benoit,
On Fri, Sep 3, 2010 at 1:51 PM, kishore kadiyala
wrote:
> Hi Benoit
>
>
>
>>> + while (!(omap_readl(base + reg_off)&
>>> MMCHS_SYSSTATUS_RESETDONE))
>>> cpu_relax();
>>
>> Why does that series not seems to be based on your hwmod migration? The
>> reset is fully handle by the hwmod framework now.
>
> Agree. But Kevin has suggested to post this patch independent of hwmod.
> Does this patch has to go in hwmod series ?
>
>>
>> BTW, when do you have to apply a reset in your case? Do you have the need
>> for an API accessible by the driver?
>> I'm asking because for the moment the framework does not expose the reset
>> API and use it only at init time.
>
> Correct , I don't need reset API access in the driver.
One correction here , in case of context restore , driver does
software reset apart from
the initial reset. So reset is required and so both the tables needs
registers SYSCONFIG and
SYSSTATUS. In which case offset deviation of 0x100 can't be maintained.
Regards,
Kishore
>
>
>
>>>
>>> +enum {
>>> + OMAP_HSMMC_SYSCONFIG = 0,
>>> + OMAP_HSMMC_SYSSTATUS,
>>> + OMAP_HSMMC_CON,
>>> + OMAP_HSMMC_BLK,
>>> + OMAP_HSMMC_ARG,
>>> + OMAP_HSMMC_CMD,
>>> + OMAP_HSMMC_RSP10,
>>> + OMAP_HSMMC_RSP32,
>>> + OMAP_HSMMC_RSP54,
>>> + OMAP_HSMMC_RSP76,
>>> + OMAP_HSMMC_DATA,
>>> + OMAP_HSMMC_PSTATE,
>>> + OMAP_HSMMC_HCTL,
>>> + OMAP_HSMMC_SYSCTL,
>>> + OMAP_HSMMC_STAT,
>>> + OMAP_HSMMC_IE,
>>> + OMAP_HSMMC_ISE,
>>> + OMAP_HSMMC_CAPA,
>>> + OMAP_HSMMC_REV,
>>> + OMAP_HSMMC_CUR_CAPA,
>>> + OMAP_HSMMC_FE,
>>> + OMAP_HSMMC_ADMA_ES,
>>> + OMAP_HSMMC_ADMA_SAL,
>>> +};
>>> +
>>> +static const u16 omap3_mmc_reg_map[] = {
>>> + [OMAP_HSMMC_SYSCONFIG] = 0x0010,
>>> + [OMAP_HSMMC_SYSSTATUS] = 0x0014,
>>> + [OMAP_HSMMC_CON] = 0x002C,
>>> + [OMAP_HSMMC_BLK] = 0x0104,
>>> + [OMAP_HSMMC_ARG] = 0x0108,
>>> + [OMAP_HSMMC_CMD] = 0x010C,
>>> + [OMAP_HSMMC_RSP10] = 0x0110,
>>> + [OMAP_HSMMC_RSP32] = 0x0114,
>>> + [OMAP_HSMMC_RSP54] = 0x0118,
>>> + [OMAP_HSMMC_RSP76] = 0x011C,
>>> + [OMAP_HSMMC_DATA] = 0x0120,
>>> + [OMAP_HSMMC_PSTATE] = 0x0124,
>>> + [OMAP_HSMMC_HCTL] = 0x0128,
>>> + [OMAP_HSMMC_SYSCTL] = 0x012C,
>>> + [OMAP_HSMMC_STAT] = 0x0130,
>>> + [OMAP_HSMMC_IE] = 0x0134,
>>> + [OMAP_HSMMC_ISE] = 0x0138,
>>> + [OMAP_HSMMC_CAPA] = 0x0140,
>>> + [OMAP_HSMMC_REV] = 0x01FC,
>>> +};
>>> +
>>> +static const u16 omap4_mmc_reg_map[] = {
>>> + [OMAP_HSMMC_SYSCONFIG] = 0x0010, /* Use Highlander Version
>>> */
>>> + [OMAP_HSMMC_SYSSTATUS] = 0x0114,
>>
>> In fact that sysstatus is a legacy register that is not needed anymore in
>> the highlander version. The resetdone is in the sysconfig now.
>> So you can ignore it in OMAP4.
>
> Just verified and thanks for pointing this.
> ok will avoid checking resetdone in sysstatus for OMAP4
>
>>
>>> + [OMAP_HSMMC_CON] = 0x012C,
>>> + [OMAP_HSMMC_BLK] = 0x0204,
>>> + [OMAP_HSMMC_ARG] = 0x0208,
>>> + [OMAP_HSMMC_CMD] = 0x020C,
>>> + [OMAP_HSMMC_RSP10] = 0x0210,
>>> + [OMAP_HSMMC_RSP32] = 0x0214,
>>> + [OMAP_HSMMC_RSP54] = 0x0218,
>>> + [OMAP_HSMMC_RSP76] = 0x021C,
>>> + [OMAP_HSMMC_DATA] = 0x0220,
>>> + [OMAP_HSMMC_PSTATE] = 0x0224,
>>> + [OMAP_HSMMC_HCTL] = 0x0228,
>>> + [OMAP_HSMMC_SYSCTL] = 0x022C,
>>> + [OMAP_HSMMC_STAT] = 0x0230,
>>> + [OMAP_HSMMC_IE] = 0x0234,
>>> + [OMAP_HSMMC_ISE] = 0x0238,
>>> + [OMAP_HSMMC_CAPA] = 0x0240,
>>> + [OMAP_HSMMC_REV] = 0x, /* Use Highlander Version */
>>> + [OMAP_HSMMC_CUR_CAPA] = 0x0248,
>>> + [OMAP_HSMMC_FE] = 0x0250,
>>> + [OMAP_HSMMC_ADMA_ES] = 0x0254,
>>> + [OMAP_HSMMC_ADMA_SAL] = 0x0258,
>>
>> I didn't check all the registers, but it seems that there is a constant
>> 0x100 offset for most of these registers. Cannot you simplify this table?
>
> Sure will simplify and post.
>
>>
>> Regards,
>> Benoit
>>
>
>
>
> Regards,
> Kishore
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
On 9/3/2010 5:44 PM, Kevin Hilman wrote: kishore kadiyala writes: Hi Benoit + while (!(omap_readl(base + reg_off)& MMCHS_SYSSTATUS_RESETDONE)) cpu_relax(); Why does that series not seems to be based on your hwmod migration? The reset is fully handle by the hwmod framework now. Agree. But Kevin has suggested to post this patch independent of hwmod. Does this patch has to go in hwmod series ? I suggested that this register conversion patch could be merged before the hwmod conversion as it is independent of that. OK, I missed that part. I was surprised because the hwmod series was sent before that one. Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
kishore kadiyala writes: > Hi Benoit > > > >>> + while (!(omap_readl(base + reg_off)& >>> MMCHS_SYSSTATUS_RESETDONE)) >>> cpu_relax(); >> >> Why does that series not seems to be based on your hwmod migration? The >> reset is fully handle by the hwmod framework now. > > Agree. But Kevin has suggested to post this patch independent of hwmod. > Does this patch has to go in hwmod series ? I suggested that this register conversion patch could be merged before the hwmod conversion as it is independent of that. The hwmod conversion (based on this series) would then just remove the reset from here. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
Hi Benoit
>> + while (!(omap_readl(base + reg_off)&
>> MMCHS_SYSSTATUS_RESETDONE))
>> cpu_relax();
>
> Why does that series not seems to be based on your hwmod migration? The
> reset is fully handle by the hwmod framework now.
Agree. But Kevin has suggested to post this patch independent of hwmod.
Does this patch has to go in hwmod series ?
>
> BTW, when do you have to apply a reset in your case? Do you have the need
> for an API accessible by the driver?
> I'm asking because for the moment the framework does not expose the reset
> API and use it only at init time.
Correct , I don't need reset API access in the driver.
>>
>> +enum {
>> + OMAP_HSMMC_SYSCONFIG = 0,
>> + OMAP_HSMMC_SYSSTATUS,
>> + OMAP_HSMMC_CON,
>> + OMAP_HSMMC_BLK,
>> + OMAP_HSMMC_ARG,
>> + OMAP_HSMMC_CMD,
>> + OMAP_HSMMC_RSP10,
>> + OMAP_HSMMC_RSP32,
>> + OMAP_HSMMC_RSP54,
>> + OMAP_HSMMC_RSP76,
>> + OMAP_HSMMC_DATA,
>> + OMAP_HSMMC_PSTATE,
>> + OMAP_HSMMC_HCTL,
>> + OMAP_HSMMC_SYSCTL,
>> + OMAP_HSMMC_STAT,
>> + OMAP_HSMMC_IE,
>> + OMAP_HSMMC_ISE,
>> + OMAP_HSMMC_CAPA,
>> + OMAP_HSMMC_REV,
>> + OMAP_HSMMC_CUR_CAPA,
>> + OMAP_HSMMC_FE,
>> + OMAP_HSMMC_ADMA_ES,
>> + OMAP_HSMMC_ADMA_SAL,
>> +};
>> +
>> +static const u16 omap3_mmc_reg_map[] = {
>> + [OMAP_HSMMC_SYSCONFIG] = 0x0010,
>> + [OMAP_HSMMC_SYSSTATUS] = 0x0014,
>> + [OMAP_HSMMC_CON] = 0x002C,
>> + [OMAP_HSMMC_BLK] = 0x0104,
>> + [OMAP_HSMMC_ARG] = 0x0108,
>> + [OMAP_HSMMC_CMD] = 0x010C,
>> + [OMAP_HSMMC_RSP10] = 0x0110,
>> + [OMAP_HSMMC_RSP32] = 0x0114,
>> + [OMAP_HSMMC_RSP54] = 0x0118,
>> + [OMAP_HSMMC_RSP76] = 0x011C,
>> + [OMAP_HSMMC_DATA] = 0x0120,
>> + [OMAP_HSMMC_PSTATE] = 0x0124,
>> + [OMAP_HSMMC_HCTL] = 0x0128,
>> + [OMAP_HSMMC_SYSCTL] = 0x012C,
>> + [OMAP_HSMMC_STAT] = 0x0130,
>> + [OMAP_HSMMC_IE] = 0x0134,
>> + [OMAP_HSMMC_ISE] = 0x0138,
>> + [OMAP_HSMMC_CAPA] = 0x0140,
>> + [OMAP_HSMMC_REV] = 0x01FC,
>> +};
>> +
>> +static const u16 omap4_mmc_reg_map[] = {
>> + [OMAP_HSMMC_SYSCONFIG] = 0x0010, /* Use Highlander Version
>> */
>> + [OMAP_HSMMC_SYSSTATUS] = 0x0114,
>
> In fact that sysstatus is a legacy register that is not needed anymore in
> the highlander version. The resetdone is in the sysconfig now.
> So you can ignore it in OMAP4.
Just verified and thanks for pointing this.
ok will avoid checking resetdone in sysstatus for OMAP4
>
>> + [OMAP_HSMMC_CON] = 0x012C,
>> + [OMAP_HSMMC_BLK] = 0x0204,
>> + [OMAP_HSMMC_ARG] = 0x0208,
>> + [OMAP_HSMMC_CMD] = 0x020C,
>> + [OMAP_HSMMC_RSP10] = 0x0210,
>> + [OMAP_HSMMC_RSP32] = 0x0214,
>> + [OMAP_HSMMC_RSP54] = 0x0218,
>> + [OMAP_HSMMC_RSP76] = 0x021C,
>> + [OMAP_HSMMC_DATA] = 0x0220,
>> + [OMAP_HSMMC_PSTATE] = 0x0224,
>> + [OMAP_HSMMC_HCTL] = 0x0228,
>> + [OMAP_HSMMC_SYSCTL] = 0x022C,
>> + [OMAP_HSMMC_STAT] = 0x0230,
>> + [OMAP_HSMMC_IE] = 0x0234,
>> + [OMAP_HSMMC_ISE] = 0x0238,
>> + [OMAP_HSMMC_CAPA] = 0x0240,
>> + [OMAP_HSMMC_REV] = 0x, /* Use Highlander Version */
>> + [OMAP_HSMMC_CUR_CAPA] = 0x0248,
>> + [OMAP_HSMMC_FE] = 0x0250,
>> + [OMAP_HSMMC_ADMA_ES] = 0x0254,
>> + [OMAP_HSMMC_ADMA_SAL] = 0x0258,
>
> I didn't check all the registers, but it seems that there is a constant
> 0x100 offset for most of these registers. Cannot you simplify this table?
Sure will simplify and post.
>
> Regards,
> Benoit
>
Regards,
Kishore
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
Hi Kishore,
On 8/30/2010 7:48 PM, Kadiyala, Kishore wrote:
OMAP4 not only have newly added hsmmc registers but also
have registers which were there in OMAP3 and which doesn't
have a common offset deviation compared to OMAP3.
For generic handling, OMAP3 and OMAP4 has different array's of
register offset maintained and right one is choosen during run time.
Cc: Tony Lindgren
Cc: Adrian Hunter
Cc: Madhusudhan Chikkature
Cc: Andrew Morton
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/devices.c | 30 +++--
arch/arm/mach-omap2/hsmmc.c |6 +
arch/arm/plat-omap/include/plat/mmc.h | 78 ++-
drivers/mmc/host/omap_hsmmc.c | 251 +++--
4 files changed, 218 insertions(+), 147 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..03add6e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -506,6 +506,8 @@ static inline void omap_init_sham(void) { }
#define MMCHS_SYSCONFIG_SWRESET(1<< 1)
#define MMCHS_SYSSTATUS0x0014
#define MMCHS_SYSSTATUS_RESETDONE (1<< 0)
+#define OMAP4_MMCHS_SYSCONFIG_SWRESET (1<< 0)
+#define OMAP4_MMCHS_OFFSET 0x100
static struct platform_device dummy_pdev = {
.dev = {
@@ -528,6 +530,8 @@ static struct platform_device dummy_pdev = {
static void __init omap_hsmmc_reset(void)
{
u32 i, nr_controllers;
+ u32 reg_val = 0;
+ u32 reg_off = 0;
if (cpu_is_omap242x())
return;
@@ -562,9 +566,6 @@ static void __init omap_hsmmc_reset(void)
break;
}
- if (cpu_is_omap44xx())
- base += OMAP4_MMC_REG_OFFSET;
-
dummy_pdev.id = i;
dev_set_name(&dummy_pdev.dev, "mmci-omap-hs.%d", i);
iclk = clk_get(dev, "ick");
@@ -582,9 +583,18 @@ static void __init omap_hsmmc_reset(void)
break;
}
- omap_writel(MMCHS_SYSCONFIG_SWRESET, base + MMCHS_SYSCONFIG);
- v = omap_readl(base + MMCHS_SYSSTATUS);
- while (!(omap_readl(base + MMCHS_SYSSTATUS)&
+ if (cpu_is_omap44xx())
+ reg_val = MMCHS_SYSCONFIG_SWRESET;
+ else
+ reg_val = MMCHS_SYSCONFIG_SWRESET;
+ omap_writel(reg_val, base + MMCHS_SYSCONFIG);
+
+ reg_off = MMCHS_SYSSTATUS;
+ if (cpu_is_omap44xx())
+ reg_off += OMAP4_MMCHS_OFFSET;
+ v = omap_readl(base + reg_off);
+
+ while (!(omap_readl(base + reg_off)&
MMCHS_SYSSTATUS_RESETDONE))
cpu_relax();
Why does that series not seems to be based on your hwmod migration? The
reset is fully handle by the hwmod framework now.
BTW, when do you have to apply a reset in your case? Do you have the
need for an API accessible by the driver?
I'm asking because for the moment the framework does not expose the
reset API and use it only at init time.
@@ -745,13 +755,13 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data
**mmc_data,
case 3:
if (!cpu_is_omap44xx())
return;
- base = OMAP4_MMC4_BASE + OMAP4_MMC_REG_OFFSET;
+ base = OMAP4_MMC4_BASE;
irq = OMAP44XX_IRQ_MMC4;
break;
case 4:
if (!cpu_is_omap44xx())
return;
- base = OMAP4_MMC5_BASE + OMAP4_MMC_REG_OFFSET;
+ base = OMAP4_MMC5_BASE;
irq = OMAP44XX_IRQ_MMC5;
break;
default:
@@ -762,10 +772,8 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data
**mmc_data,
size = OMAP2420_MMC_SIZE;
name = "mmci-omap";
} else if (cpu_is_omap44xx()) {
- if (i< 3) {
- base += OMAP4_MMC_REG_OFFSET;
+ if (i< 3)
irq += OMAP44XX_IRQ_GIC_START;
- }
size = OMAP4_HSMMC_SIZE;
namee = "mmci-omap-hs";
} else {
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index c8f647b..d93b704 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -262,6 +262,12 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
mmc->slots[0].internal_clock = !c->ext_clock;
mmc->dma_mask = 0x;
+ /* Register offset Mapping */
+ if (cpu_is_omap44xx())
+
Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
On Wed, Sep 1, 2010 at 5:56 PM, Adrian Hunter wrote:
> kishore kadiyala wrote:
>>
>> OMAP4 not only have newly added hsmmc registers but also
>> have registers which were there in OMAP3 and which doesn't
>> have a common offset deviation compared to OMAP3.
>>
>> For generic handling, OMAP3 and OMAP4 has different array's of
>> register offset maintained and right one is choosen during run time.
>>
>> Cc: Tony Lindgren
>> Cc: Adrian Hunter
>> Cc: Madhusudhan Chikkature
>> Cc: Andrew Morton
>> Signed-off-by: Kishore Kadiyala
>> ---
>> arch/arm/mach-omap2/devices.c | 30 +++--
>> arch/arm/mach-omap2/hsmmc.c | 6 +
>> arch/arm/plat-omap/include/plat/mmc.h | 78 ++-
>> drivers/mmc/host/omap_hsmmc.c | 251
>> +++--
>> 4 files changed, 218 insertions(+), 147 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
>> index 2dbb265..03add6e 100644
>> --- a/arch/arm/mach-omap2/devices.c
>> +++ b/arch/arm/mach-omap2/devices.c
>> @@ -506,6 +506,8 @@ static inline void omap_init_sham(void) { }
>> #define MMCHS_SYSCONFIG_SWRESET (1 << 1)
>> #define MMCHS_SYSSTATUS 0x0014
>> #define MMCHS_SYSSTATUS_RESETDONE (1 << 0)
>> +#define OMAP4_MMCHS_SYSCONFIG_SWRESET (1 << 0)
>> +#define OMAP4_MMCHS_OFFSET 0x100
>>
>> static struct platform_device dummy_pdev = {
>> .dev = {
>> @@ -528,6 +530,8 @@ static struct platform_device dummy_pdev = {
>> static void __init omap_hsmmc_reset(void)
>> {
>> u32 i, nr_controllers;
>> + u32 reg_val = 0;
>> + u32 reg_off = 0;
>>
>> if (cpu_is_omap242x())
>> return;
>> @@ -562,9 +566,6 @@ static void __init omap_hsmmc_reset(void)
>> break;
>> }
>>
>> - if (cpu_is_omap44xx())
>> - base += OMAP4_MMC_REG_OFFSET;
>> -
>> dummy_pdev.id = i;
>> dev_set_name(&dummy_pdev.dev, "mmci-omap-hs.%d", i);
>> iclk = clk_get(dev, "ick");
>> @@ -582,9 +583,18 @@ static void __init omap_hsmmc_reset(void)
>> break;
>> }
>>
>> - omap_writel(MMCHS_SYSCONFIG_SWRESET, base +
>> MMCHS_SYSCONFIG);
>> - v = omap_readl(base + MMCHS_SYSSTATUS);
>> - while (!(omap_readl(base + MMCHS_SYSSTATUS) &
>> + if (cpu_is_omap44xx())
>> + reg_val = MMCHS_SYSCONFIG_SWRESET;
>
> Should this be OMAP4_MMCHS_SYSCONFIG_SWRESET?
Yes, it should be as mentioned [Late night post's take's away quality :) ] ,
will correct it and repost .
Thanks,
Kishore
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
kishore kadiyala wrote:
OMAP4 not only have newly added hsmmc registers but also
have registers which were there in OMAP3 and which doesn't
have a common offset deviation compared to OMAP3.
For generic handling, OMAP3 and OMAP4 has different array's of
register offset maintained and right one is choosen during run time.
Cc: Tony Lindgren
Cc: Adrian Hunter
Cc: Madhusudhan Chikkature
Cc: Andrew Morton
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/devices.c | 30 +++--
arch/arm/mach-omap2/hsmmc.c |6 +
arch/arm/plat-omap/include/plat/mmc.h | 78 ++-
drivers/mmc/host/omap_hsmmc.c | 251 +++--
4 files changed, 218 insertions(+), 147 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..03add6e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -506,6 +506,8 @@ static inline void omap_init_sham(void) { }
#define MMCHS_SYSCONFIG_SWRESET(1 << 1)
#define MMCHS_SYSSTATUS0x0014
#define MMCHS_SYSSTATUS_RESETDONE (1 << 0)
+#define OMAP4_MMCHS_SYSCONFIG_SWRESET (1 << 0)
+#define OMAP4_MMCHS_OFFSET 0x100
static struct platform_device dummy_pdev = {
.dev = {
@@ -528,6 +530,8 @@ static struct platform_device dummy_pdev = {
static void __init omap_hsmmc_reset(void)
{
u32 i, nr_controllers;
+ u32 reg_val = 0;
+ u32 reg_off = 0;
if (cpu_is_omap242x())
return;
@@ -562,9 +566,6 @@ static void __init omap_hsmmc_reset(void)
break;
}
- if (cpu_is_omap44xx())
- base += OMAP4_MMC_REG_OFFSET;
-
dummy_pdev.id = i;
dev_set_name(&dummy_pdev.dev, "mmci-omap-hs.%d", i);
iclk = clk_get(dev, "ick");
@@ -582,9 +583,18 @@ static void __init omap_hsmmc_reset(void)
break;
}
- omap_writel(MMCHS_SYSCONFIG_SWRESET, base + MMCHS_SYSCONFIG);
- v = omap_readl(base + MMCHS_SYSSTATUS);
- while (!(omap_readl(base + MMCHS_SYSSTATUS) &
+ if (cpu_is_omap44xx())
+ reg_val = MMCHS_SYSCONFIG_SWRESET;
Should this be OMAP4_MMCHS_SYSCONFIG_SWRESET?
+ else
+ reg_val = MMCHS_SYSCONFIG_SWRESET;
+ omap_writel(reg_val, base + MMCHS_SYSCONFIG);
+
+ reg_off = MMCHS_SYSSTATUS;
+ if (cpu_is_omap44xx())
+ reg_off += OMAP4_MMCHS_OFFSET;
+ v = omap_readl(base + reg_off);
+
+ while (!(omap_readl(base + reg_off) &
MMCHS_SYSSTATUS_RESETDONE))
cpu_relax();
@@ -745,13 +755,13 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data
**mmc_data,
case 3:
if (!cpu_is_omap44xx())
return;
- base = OMAP4_MMC4_BASE + OMAP4_MMC_REG_OFFSET;
+ base = OMAP4_MMC4_BASE;
irq = OMAP44XX_IRQ_MMC4;
break;
case 4:
if (!cpu_is_omap44xx())
return;
- base = OMAP4_MMC5_BASE + OMAP4_MMC_REG_OFFSET;
+ base = OMAP4_MMC5_BASE;
irq = OMAP44XX_IRQ_MMC5;
break;
default:
@@ -762,10 +772,8 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data
**mmc_data,
size = OMAP2420_MMC_SIZE;
name = "mmci-omap";
} else if (cpu_is_omap44xx()) {
- if (i < 3) {
- base += OMAP4_MMC_REG_OFFSET;
+ if (i < 3)
irq += OMAP44XX_IRQ_GIC_START;
- }
size = OMAP4_HSMMC_SIZE;
name = "mmci-omap-hs";
} else {
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index c8f647b..d93b704 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -262,6 +262,12 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
mmc->slots[0].internal_clock = !c->ext_clock;
mmc->dma_mask = 0x;
+ /* Register offset Mapping */
+ if (cpu_is_omap44xx())
+ mmc->regs_map = (u16 *) omap4_mmc_reg_map;
+ else
+ mmc->regs_map = (u16 *) omap3_mmc_reg_map;
+
mmc->get_context_loss_count = hsmmc_get_context_loss;
mmc->slots[0].switch_pin = c->gpio_cd;
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 9b89ec6..a85f
