Re: [PATCH] MMC: move regulator handling closer to core v2
Linus Walleij wrote: 2010/8/31 Linus Walleij : After discovering a problem in regulator reference counting I took Mark Brown's advice to move the reference count into the MMC core by making the regulator status a member of struct mmc_host. This has an Reveiwed-by from the regulator maintainer and seems to address all comments, noone is objection so Andrew can you pick it up? One of our contractors had a look at the patch and had this comment: One comment/question: /host/mmci.c in function "static int __devexit mmci_remove(struct amba_device *dev)" there is code: if (regulator_is_enabled(host->vcc)) regulator_disable(host->vcc); should "ret = mmc_regulator_set_ocr(mmc, host->vcc, 0);" be added here? Yours, Linus Walleij -- 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: my custom SDIO card can be detected in 2.6.30 but not in 2.6.18
On Fri, 3 Sep 2010, hong zhang wrote: > List, > > My redpine wifi chip based custom SDIO card be detected in 2.6.30 but not in > 2.6.18. Just use 2.6.30 then. If you want free help from people here, you should at least consider using a kernel version that isn't absurdly old. If you're stuck with 2.6.18 because that's what your vendor provided to you, then please go to them for support. Nicolas -- 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
+ mmc-make-id-freq-configurable-checkpatch-fixes.patch added to -mm tree
The patch titled
mmc-make-id-freq-configurable-checkpatch-fixes
has been added to the -mm tree. Its filename is
mmc-make-id-freq-configurable-checkpatch-fixes.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
--
Subject: mmc-make-id-freq-configurable-checkpatch-fixes
From: Andrew Morton
WARNING: space prohibited between function name and open parenthesis '('
#76: FILE: drivers/mmc/core/core.c:1453:
+ printk ("mmc_rescan: trying %u Hz\n", host->f_init);
WARNING: line over 80 characters
#100: FILE: drivers/mmc/core/core.c:1467:
+ /* try SDMEM (but not MMC) even if SDIO is
broken */
total: 0 errors, 2 warnings, 131 lines checked
./patches/mmc-make-id-freq-configurable.patch has style problems, please
review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc:
Cc: Adrian Hunter
Cc: Ben Nizette
Cc: Chris Ball
Cc: Hein Tibosch
Cc: Matt Fleming
Cc: Pierre Ossman
Cc: Sascha Hauer
Signed-off-by: Andrew Morton
---
drivers/mmc/core/core.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff -puN
drivers/mmc/core/core.c~mmc-make-id-freq-configurable-checkpatch-fixes
drivers/mmc/core/core.c
--- a/drivers/mmc/core/core.c~mmc-make-id-freq-configurable-checkpatch-fixes
+++ a/drivers/mmc/core/core.c
@@ -1450,7 +1450,9 @@ void mmc_rescan(struct work_struct *work
else
host->f_init = host->f_min;
- printk ("mmc_rescan: trying %u Hz\n", host->f_init);
+ pr_info("%s: %s: trying to init card at %u Hz\n",
+ mmc_hostname(host), __func__, host->f_init);
+
mmc_power_up(host);
sdio_reset(host);
mmc_go_idle(host);
@@ -1464,7 +1466,10 @@ void mmc_rescan(struct work_struct *work
if (!err) {
if (mmc_attach_sdio(host, ocr)) {
mmc_claim_host(host);
- /* try SDMEM (but not MMC) even if SDIO is
broken */
+ /*
+* Try SDMEM (but not MMC) even if SDIO is
+* broken.
+*/
if (mmc_send_app_op_cond(host, 0, &ocr))
goto out_fail;
_
Patches currently in -mm which might be from a...@linux-foundation.org are
linux-next.patch
next-remove-localversion.patch
fs-inodec-work-around-bug.patch
i-need-old-gcc.patch
cgroups-fix-api-thinko-fix.patch
vmstat-update-zone-stat-threshold-when-onlining-a-cpu.patch
mm-page-allocator-update-free-page-counters-after-pages-are-placed-on-the-free-list-fix.patch
mm-vmap-area-cache.patch
drivers-gpu-drm-i915-intel_overlayc-needs-seq_fileh.patch
parport-prevent-arm-boards-frmo-crashing-when-cups-is-loaded-fix.patch
gcc-46-btrfs-clean-up-unused-variables-bugs.patch
hpet-factor-timer-allocate-from-open.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
security-add-const-to-security_task_setscheduler.patch
sched-make-sched_param-argument-static-variables-in-some-sched_setscheduler-caller.patch
usb-storage-add-new-no_read_disc_info-quirk-fix.patch
mm.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix-fix.patch
oom-rewrite-error-handling-for-oom_adj-and-oom_score_adj-tunables.patch
oom-fix-locking-for-oom_adj-and-oom_score_adj.patch
mm-only-build-per-node-scan_unevictable-functions-when-numa-is-enabled-cleanup.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
kernelh-add-minmax3-macros-fix.patch
include-linux-kernelh-add-__must_check-to-strict_strto.patch
sdhci-support-10-bit-divided-clock-mode-for-spec-30-checkpatch-fixes.patch
mmc-make-id-freq-configurable-checkpatch-fixes.patch
sdhci-get-rid-of-card-detect-work-fix.patch
checkpatch-returning-errno-typically-should-be-negative.patch
select-rename-estimate_accuracy-to-select_estimate_accuracy.patch
cgroup_freezer-update_freezer_state-does-incorrect-state-transitions-checkpatch-fixes.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2-checkpatc
Re: [PATCH v4] mmc: Make ID freq configurable
On Fri, 3 Sep 2010 02:47:57 +0100
Chris Ball wrote:
> > - mmc_send_if_cond(host, host->ocr_avail);
> > + printk ("mmc_rescan: trying %u Hz\n", host->f_init);
>
> Need a loglevel here, and an mmc_hostname. Something like:
>
> pr_info("%s: %s: trying to init card at %u Hz\n",
> mmc_hostname(host), __func__, host->f_init);
>
> > + mmc_power_up(host);
> > + sdio_reset(host);
> > + mmc_go_idle(host);
> >
> > - /*
> > -* First we search for SDIO...
> > -*/
> > - err = mmc_send_io_op_cond(host, 0, &ocr);
> > - if (!err) {
> > - if (mmc_attach_sdio(host, ocr)) {
> > - mmc_claim_host(host);
> > - /* try SDMEM (but not MMC) even if SDIO is broken */
> > - if (mmc_send_app_op_cond(host, 0, &ocr))
> > - goto out_fail;
> > + mmc_send_if_cond(host, host->ocr_avail);
> > +
> > + /*
> > +* First we search for SDIO...
> > +*/
> > + err = mmc_send_io_op_cond(host, 0, &ocr);
> > + if (!err) {
> > + if (mmc_attach_sdio(host, ocr)) {
> > + mmc_claim_host(host);
> > + /* try SDMEM (but not MMC) even if SDIO is
> > broken */
>
> This breaks 80-chars, so:
>
> /*
> * Try SDMEM (but not MMC) even if SDIO
> * is broken.
> */
yup.
--- a/drivers/mmc/core/core.c~mmc-make-id-freq-configurable-checkpatch-fixes
+++ a/drivers/mmc/core/core.c
@@ -1450,7 +1450,9 @@ void mmc_rescan(struct work_struct *work
else
host->f_init = host->f_min;
- printk ("mmc_rescan: trying %u Hz\n", host->f_init);
+ pr_info("%s: %s: trying to init card at %u Hz\n",
+ mmc_hostname(host), __func__, host->f_init);
+
mmc_power_up(host);
sdio_reset(host);
mmc_go_idle(host);
@@ -1464,7 +1466,10 @@ void mmc_rescan(struct work_struct *work
if (!err) {
if (mmc_attach_sdio(host, ocr)) {
mmc_claim_host(host);
- /* try SDMEM (but not MMC) even if SDIO is
broken */
+ /*
+* Try SDMEM (but not MMC) even if SDIO is
+* broken.
+*/
if (mmc_send_app_op_cond(host, 0, &ocr))
goto out_fail;
diff -puN
include/linux/mmc/host.h~mmc-make-id-freq-configurable-checkpatch-fixes
include/linux/mmc/host.h
_
--
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
+ mmc-make-id-freq-configurable.patch added to -mm tree
The patch titled
mmc: make ID freq configurable
has been added to the -mm tree. Its filename is
mmc-make-id-freq-configurable.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
--
Subject: mmc: make ID freq configurable
From: Hein Tibosch
In the latest releases of the mmc driver, the freq during initialization
is set to a fixed 400 Khz. This was reportedly too fast for several
users. As there doesn't seem to be an ideal frequency
which-works-for-all, Pierre suggested to let the driver try several
frequencies.
This patch implements that idea. It will try mmc-initialization using
several frequencies from an array 400, 300, 200 and 100.
In case SDIO is broken, it'll still try to detect SDMEM, also at different
freqs.
Signed-off-by: Hein Tibosch
Cc: Pierre Ossman
Reviewed-by: Chris Ball
Tested-by: Chris Ball
Cc: Ben Nizette
Cc: Sascha Hauer
Cc: Adrian Hunter
Cc: Matt Fleming
Cc:
Signed-off-by: Andrew Morton
---
drivers/mmc/core/core.c | 96 +++--
include/linux/mmc/host.h |1
2 files changed, 52 insertions(+), 45 deletions(-)
diff -puN drivers/mmc/core/core.c~mmc-make-id-freq-configurable
drivers/mmc/core/core.c
--- a/drivers/mmc/core/core.c~mmc-make-id-freq-configurable
+++ a/drivers/mmc/core/core.c
@@ -907,12 +907,7 @@ static void mmc_power_up(struct mmc_host
*/
mmc_delay(10);
- if (host->f_min > 40) {
- pr_warning("%s: Minimum clock frequency too high for "
- "identification mode\n", mmc_hostname(host));
- host->ios.clock = host->f_min;
- } else
- host->ios.clock = 40;
+ host->ios.clock = host->f_init;
host->ios.power_mode = MMC_POWER_ON;
mmc_set_ios(host);
@@ -1404,6 +1399,8 @@ void mmc_rescan(struct work_struct *work
u32 ocr;
int err;
unsigned long flags;
+ int i;
+ unsigned freqs[] = { 40, 30, 20, 10 };
spin_lock_irqsave(&host->lock, flags);
@@ -1443,55 +1440,64 @@ void mmc_rescan(struct work_struct *work
if (host->ops->get_cd && host->ops->get_cd(host) == 0)
goto out;
- mmc_claim_host(host);
+ for (i = 0; i < ARRAY_SIZE(freqs); i++) {
+ mmc_claim_host(host);
- mmc_power_up(host);
- sdio_reset(host);
- mmc_go_idle(host);
+ if (freqs[i] >= host->f_min)
+ host->f_init = freqs[i];
+ else if (i && freqs[i-1] <= host->f_min)
+ goto out;
+ else
+ host->f_init = host->f_min;
- mmc_send_if_cond(host, host->ocr_avail);
+ printk ("mmc_rescan: trying %u Hz\n", host->f_init);
+ mmc_power_up(host);
+ sdio_reset(host);
+ mmc_go_idle(host);
- /*
-* First we search for SDIO...
-*/
- err = mmc_send_io_op_cond(host, 0, &ocr);
- if (!err) {
- if (mmc_attach_sdio(host, ocr)) {
- mmc_claim_host(host);
- /* try SDMEM (but not MMC) even if SDIO is broken */
- if (mmc_send_app_op_cond(host, 0, &ocr))
- goto out_fail;
+ mmc_send_if_cond(host, host->ocr_avail);
+
+ /*
+* First we search for SDIO...
+*/
+ err = mmc_send_io_op_cond(host, 0, &ocr);
+ if (!err) {
+ if (mmc_attach_sdio(host, ocr)) {
+ mmc_claim_host(host);
+ /* try SDMEM (but not MMC) even if SDIO is
broken */
+ if (mmc_send_app_op_cond(host, 0, &ocr))
+ goto out_fail;
+
+ if (mmc_attach_sd(host, ocr))
+ mmc_power_off(host);
+ }
+ goto out;
+ }
+ /*
+* ...then normal SD...
+*/
+ err = mmc_send_app_op_cond(host, 0, &ocr);
+ if (!err) {
if (mmc_attach_sd(host, ocr))
mmc_power_off(host);
+ goto out;
}
- goto out;
- }
- /*
-* ...then normal SD...
-
my custom SDIO card can be detected in 2.6.30 but not in 2.6.18
List, My redpine wifi chip based custom SDIO card be detected in 2.6.30 but not in 2.6.18. Redpine reference SDIO card works well in 2.6.18. Where should I take a look in SDIO stack that invoke probe function? Any help will be appreciated. ---henry -- 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] MMC: move regulator handling closer to core v2
2010/8/31 Linus Walleij : > After discovering a problem in regulator reference counting I > took Mark Brown's advice to move the reference count into the > MMC core by making the regulator status a member of > struct mmc_host. This has an Reveiwed-by from the regulator maintainer and seems to address all comments, noone is objection so Andrew can you pick it up? Yours, Linus Walleij -- 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
install SDIO stack patch to 2.6.14
List, I donwload linux sdio stack patch from http://sourceforge.net/projects/sdio-linux/ and want to install it to 2.6.14 kernel. What else should I do beside installing the patches to 2.6.14 for ARM? ---henry -- 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())
+
