Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
Hi Benoit,
On Fri, Sep 3, 2010 at 1:51 PM, kishore kadiyala
kishorek.kadiy...@gmail.com wrote:
Hi Benoit
snip
+ 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
snip
+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
snip
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 Lindgrent...@atomide.com
Cc: Adrian Hunteradrian.hun...@nokia.com
Cc: Madhusudhan Chikkaturemadhu...@ti.com
Cc: Andrew Mortona...@linux-foundation.org
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
---
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;
+ /*
Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
Hi Benoit
snip
+ 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.
snip
+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
snip
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
[PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
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 t...@atomide.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
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();
@@ -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
