[RFC] mmc: core: add the capability for broken voltage
This patch is added the MMC_CAP2_BROKEN_VOLTAGE.
if the voltage didn't satisfy between min_uV and max_uV,
try to change the voltage in core.c.
When change the voltage, maybe use the regulator_set_voltage().
In regulator_set_voltage(), check the below condition.
/* sanity check */
if (!rdev-desc-ops-set_voltage
!rdev-desc-ops-set_voltage_sel) {
ret = -EINVAL;
goto out;
}
If Some-board should use the fixed-regulator, always return -EINVAL.
Then, eMMC didn't initialize always.
So if use the fixed-regulator or etc, we need to add the
MMC_CAP2_BROKEN_VOLTAGE.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/core/core.c |4
include/linux/mmc/host.h |1 +
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index bec0bf2..6848789 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1121,6 +1121,10 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
* might not allow this operation
*/
voltage = regulator_get_voltage(supply);
+
+ if (mmc-caps2 MMC_CAP2_BROKEN_VOLTAGE)
+ min_uV = max_uV = voltage;
+
if (voltage 0)
result = voltage;
else if (voltage min_uV || voltage max_uV)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index dd13e05..5659aee 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -257,6 +257,7 @@ struct mmc_host {
#define MMC_CAP2_HS200_1_2V_SDR(1 6)/* can support */
#define MMC_CAP2_HS200 (MMC_CAP2_HS200_1_8V_SDR | \
MMC_CAP2_HS200_1_2V_SDR)
+#define MMC_CAP2_BROKEN_VOLTAGE(1 7)/* Use the broken
voltage */
mmc_pm_flag_t pm_caps;/* supported pm features */
unsigned intpower_notify_type;
--
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: dw-mmc: modify the condition for platdata of blk-setting
On Mon, Jan 16, 2012 at 2:45 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: When use the IDMAC, we can also want to use the pdata-blk-setting. So if pdata-blk-setting is unset, use the default value. if not, use the pdata-blk-setting. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/mmc/host/dw_mmc.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) Looks good. Acked-by: Will Newton will.new...@imgtec.com -- 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-4.5 Data Tag Support
On Fri, Jan 13, 2012 at 3:40 PM, Kyungmin Park kmp...@infradead.org wrote: On 1/13/12, Chris Ball c...@laptop.org wrote: Hi, On Thu, Jan 12 2012, S, Venkatraman wrote: On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das saugata@stericsson.com wrote: From: Saugata Das saugata@linaro.org MMC-4.5 data tag feature will be used to store the file system meta-data in the tagged region of eMMC. This will improve the write and subsequent read transfer time for the meta data. Signed-off-by: Saugata Das saugata@linaro.org I tested this on a device which supports a data tag unit size of 8K. Tested-by: Venkatraman S svenk...@ti.com Thanks for testing! I've pushed it to mmc-next. Chris, Can this go into 3.3 ? I think 3.4 would be better after a full round of linux-next testing, since this sounds like it could expose card-dependent quirks that could destroy filesystems. Better to be safe. I'm afraid it that it's really required since some features. data tag, context id, and packed command, are not mutual exclusive. so I hope to make it select. I mean it's not measured the real performance gain and/or other feature. so hope to enable/disable by platform data. How do you think? Thank you, Kyungmin Park I don't understand your comment on them not being mutually exclusive. As it is, these are core features and they don't belong in platform data. Can you explain a bit more ? Thanks, Venkat. -- 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: core: Force a detect to handle non-properly removed cards
Adrian Hunter wrote: On 13/01/12 16:35, Ulf Hansson wrote: Adrian Hunter wrote: On 13/01/12 15:14, Ulf Hansson wrote: In principles this means the following sequence: We will rely on that the get_cd function will return 0 (indicating card is removed) when the card is slowly removed at the point when the rescan function is calling it through the bus_ops-detect -- _mmc_detect_card_removed function. This then becomes a race, meaning that the rescan function must be executing at the same time the get_cd function will returns 0. Otherwise the rescan function will not remove the card. Thus my conclusion is that [PATCH 2/4 v4] MMC/SD: Add callback function to detect card will likely improve behavior but is not the safe solution to handle slowly removed cards. Again, to be sure, we must let the mmc_detect_card_remove function trigger a rescan when _mmc_detect_card_removed has detected that the card is removed. This should be safe in all circumstances. sdhci has no problem because it does this: - the host controller debounces the card detect line - the host controller records whether or not the card is present - the sdhci driver prevents (errors out) requests when the card is not present Debouncing will just be a way of triggering the problem more seldom. Or in worst case, state the card has been removed even if it has not. If a delay is used with mmc_detect_change, debouncing is not necessary. Just because you get a GPIO irq on the detect line does not mean the card is removed, debouncing or not. I consider this as pure mechanical switch which likely has glitches and I don't see that we should trust it fully. We only want to trigger a detect work, which is exactly what is done in the patch from Guennadi Liakhovetski mmc: add a generic GPIO card-detect helper. The original problem was slow card removal. Unreliable card detect is a separate problem. Currently there is polling (MMC_CAP_NEEDS_POLL) for that. Alternatively there is MMC_CAP2_RESCAN_ON_ERROR as we have discussed. I do not understand why you mention Unreliable card detect? That has nothing to do with this patch. So to conclude the discussion, do you believe that this patch is acceptable as long as we add a CAPS2 option MMC_CAP2_RESCAN_ON_ERROR, which if not set will prevent the detect work from being scheduled from mmc_detect_card_removed? Yes OK, but.. :-) I were just about to update the patch according to your recommendation when I realized the following: Once _mmc_detect_card_removed has set the card state as removed (mmc_card_set_removed), the card will never be accessible for I/O requests any more, all I/O will silently be thrown away in the block layer. This leads to that there should definitely be no reason for _not_ letting a scheduled rescan remove the card as soon as possible. In other words the CAP2 should not be needed. Did I miss something? Agree? No. mmc_detect_card_removed() will not check/set the card removed unless there has been a call to mmc_detect_change() to set the host-detect_change flag. That were before this patch. This patch removes the detect_change flag since it is used as you say to prevent mmc_detect_card_removed from calling _mmc_detect_card_removed and thus possibly setting the card state to removed. The use of the detect_flag is a bit strange I think. It means simply that after getting one GPIO cd irq and then an I/O error we will only try at _most_ _one_ time from mmc_detect_card_removed to see if the card really has been removed. If the mmc_detect_card_removed the first time does not detect that the card is removed it will have to wait for the rescan the cover it, which is likely not what we want!? I will see if I can figure out a way of keeping the old scenario in parallel with having MMC_CAP2_RESCAN_ON_ERROR... I will post a new patch. MMC_CAP2_RESCAN_ON_ERROR is definitely needed. Do not confuse mmc_detect_card_removed() with _mmc_detect_card_removed(). The former is called by block.c. The latter is only called by mmc_rescan() via the -detect method. -- 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 RFC] mmc : omap_hsmmc : Save and restore the sysc across reset
The commit 11dd62:[omap_hsmmc: context save/restore support]
does a reset and restores AUTOIDLE settings.
This patch saves the register does a reset and restores
the same configuration.
Cc: Denis Karpov ext-denis.2.kar...@nokia.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Untested
drivers/mmc/host/omap_hsmmc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..175029d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -680,7 +680,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
struct mmc_ios *ios = host-mmc-ios;
struct omap_mmc_platform_data *pdata = host-pdata;
int context_loss = 0;
- u32 hctl, capa;
+ u32 hctl, capa, sysc;
unsigned long timeout;
if (pdata-get_context_loss_count) {
@@ -700,6 +700,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
time_before(jiffies, timeout))
;
+ sysc = OMAP_HSMMC_READ(host-base, SYSCONFIG);
/* Do software reset */
OMAP_HSMMC_WRITE(host-base, SYSCONFIG, SOFTRESET);
timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
@@ -707,8 +708,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
time_before(jiffies, timeout))
;
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_WRITE(host-base, SYSCONFIG, sysc);
if (host-id == OMAP_MMC1_DEVID) {
if (host-power_mode != MMC_POWER_OFF
--
1.7.1
--
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-4.5 Data Tag Support
On Mon, Jan 16, 2012 at 7:37 PM, S, Venkatraman svenk...@ti.com wrote: On Fri, Jan 13, 2012 at 3:40 PM, Kyungmin Park kmp...@infradead.org wrote: On 1/13/12, Chris Ball c...@laptop.org wrote: Hi, On Thu, Jan 12 2012, S, Venkatraman wrote: On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das saugata@stericsson.com wrote: From: Saugata Das saugata@linaro.org MMC-4.5 data tag feature will be used to store the file system meta-data in the tagged region of eMMC. This will improve the write and subsequent read transfer time for the meta data. Signed-off-by: Saugata Das saugata@linaro.org I tested this on a device which supports a data tag unit size of 8K. Tested-by: Venkatraman S svenk...@ti.com Thanks for testing! I've pushed it to mmc-next. Chris, Can this go into 3.3 ? I think 3.4 would be better after a full round of linux-next testing, since this sounds like it could expose card-dependent quirks that could destroy filesystems. Better to be safe. I'm afraid it that it's really required since some features. data tag, context id, and packed command, are not mutual exclusive. so I hope to make it select. I mean it's not measured the real performance gain and/or other feature. so hope to enable/disable by platform data. How do you think? Thank you, Kyungmin Park I don't understand your comment on them not being mutually exclusive. As it is, these are core features and they don't belong in platform data. Can you explain a bit more ? To get the gain these features, data tag, context ID, it requires the firmware support. But currently there's no idea to support these feature at firmware. So we can't get the valuable performance gain. and now there's no data if it enables the both, data tag, packed command or other combination, e.g., cache and so on. So I suggest make it enable/disable these features at platform data, similarly support pre-defined op by MMC_CAP_CMD23. and I saw the Saugata's active regards with Context ID. so it's also make it configurable. Thank you, Kyungmin Park -- 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 RFC] mmc : omap_hsmmc : Save and restore the sysc across reset
ext Shubhrajyoti D wrote on 2012-01-16:
The commit 11dd62:[omap_hsmmc: context save/restore support]
does a reset and restores AUTOIDLE settings.
This patch saves the register does a reset and restores
the same configuration.
...
if (pdata-get_context_loss_count) {
@@ -700,6 +700,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host
*host)
time_before(jiffies, timeout))
;
+ sysc = OMAP_HSMMC_READ(host-base, SYSCONFIG);
/* Do software reset */
OMAP_HSMMC_WRITE(host-base, SYSCONFIG, SOFTRESET);
timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
@@ -707,8 +708,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host
*host)
time_before(jiffies, timeout))
;
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_WRITE(host-base, SYSCONFIG, sysc);
The meaning of the code is to restore the register context after it was lost
during transition into low power consumption state. SW reset is needed to bring
all the registers in a consistent state before reconfiguring some of them.
Saving and restoring the SYSCONFIG register across SW reset is not needed.
Also re-configuring AUTOIDLE feature is not necessary since SYSCONFIG reset
value has is 1 already, according to TRM. I guess it was done to make things
more explicit.
Denis
--
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 V2 1/2] SD/MMC: add an interface to re-initialize bounce buffer
Hi Chris,
Do you have any concerns about this patch? Or another advice?
Thanks.
-Original Message-
From: Liu Qiang-B32616
Sent: Wednesday, December 21, 2011 3:10 PM
To: c...@laptop.org; linux-mmc@vger.kernel.org
Cc: Li Yang-R58472; Liu Qiang-B32616; Liu Qiang-B32616
Subject: [PATCH V2 1/2] SD/MMC: add an interface to re-initialize bounce buffer
Add bounce_size under /sys/block/mmcblk0/bouncesz.
Support dynamic adjustment of bounce buffer in run-time (include mounted or
unmounted filesystem).
/sys/block/mmcblk0/bouncesz should be integer multiple of 512, the value should
be range from 4096 to 4194304.
1. use variable instead of MMC_QUEUE_BOUNCESZ; 2. Re-initialize bounce buffer
accorinding to new bounce size at run-time;
Signed-off-by: Qiang Liu qiang@freescale.com
---
changes for V2
merge former 2 patches to 1
Here is the test results with different mmc bounce size, IOzone is used to test
performance of mass data transmission.
Environment:
PowerPC P1022DS platform, Sandisk Class 10, 4G memory card, EXT4 filesystem
[root@p2020ds root]# cat /sys/fs/ block/mmcblk0/bouncesz
65536
[root@p2020ds root]# mount /dev/mmcblk0p1 /mnt/ EXT4-fs (mmcblk0p1): mounted
filesystem without journal. Opts:
[root@p2020ds root]# iozone -Rab result -i0 -i1 -r64 =- -n1g -g4g -f /mnt/ff
KB reclen write rewritereadreread
1048576 64 14229 13286 662028 663372
2097152 64 13758 126054954947443
4194304 64 13435 122152197422096
[root@p2020ds root]# echo 262144 /sys/block/mmcblk0/bouncesz [root@p2020ds
root]# cat /sys/block/mmcblk0/bouncesz
262144
[root@p2020ds root]# iozone -Rab result -i0 -i1 -r64 -n1g -g4g -f /mnt/ff
KB reclen write rewritereadreread
1048576 64 19228 19416 676659 677785
2097152 64 18512 184992697827055
4194304 64 17932 181852194521805
[root@p2020ds root]# echo 8192 /sys/block/mmcblk0/bouncesz [root@p2020ds
root]# cat /sys/block/mmcblk0/bouncesz
8192
[root@p2020ds root]# iozone -Rab result -i0 -i1 -r64 -n1g -g1g -f /mnt/ff
KB reclen write rewritereadreread
1048576 6450683324 640266 641609
---
drivers/mmc/card/block.c | 43 +++
drivers/mmc/card/queue.c | 102 +-
drivers/mmc/card/queue.h |6 +++
3 files changed, 149 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index
0c959c9..790abe2 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -59,6 +59,9 @@ MODULE_ALIAS(mmc:block); #define INAND_CMD38_ARG_SECTRIM1
0x81 #define INAND_CMD38_ARG_SECTRIM2 0x88
+#define MMC_MIN_QUEUE_BOUNCESZ 4096
+#define MMC_MAX_QUEUE_BOUNCESZ 4194304
+
static DEFINE_MUTEX(block_mutex);
/*
@@ -108,6 +111,7 @@ struct mmc_blk_data {
unsigned intpart_curr;
struct device_attribute force_ro;
struct device_attribute power_ro_lock;
+ struct device_attribute bouncesz;
int area_type;
};
@@ -1633,6 +1637,7 @@ static void mmc_blk_remove_req(struct mmc_blk_data *md)
del_gendisk(md-disk);
}
+ device_remove_file(disk_to_dev(md-disk), md-bouncesz);
/* Then flush out any already in there */
mmc_cleanup_queue(md-queue);
mmc_blk_put(md);
@@ -1739,6 +1744,33 @@ static const struct mmc_fixup blk_fixups[] =
END_FIXUP
};
+#ifdef CONFIG_MMC_BLOCK_BOUNCE
+static ssize_t mmc_bouncesz_show(struct device *dev,
+ struct device_attribute *attr, char *buf) {
+return sprintf(buf, %u\n, mmc_queue_bouncesz); }
+
+static ssize_t mmc_bouncesz_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned int bouncesz;
+ struct mmc_blk_data *md;
+
+ if ((sscanf(buf, %d, bouncesz) != 1) ||
+ (bouncesz MMC_MIN_QUEUE_BOUNCESZ) ||
+ (bouncesz MMC_MAX_QUEUE_BOUNCESZ) ||
+ (bouncesz % 512 != 0))
+ return -EINVAL;
+
+ md = mmc_blk_get(dev_to_disk(dev));
+ mmc_reinit_bounce_queue(md-queue, md-queue.card, bouncesz);
+ mmc_blk_put(md);
+ return mmc_queue_bouncesz;
+}
+#endif
+
static int mmc_blk_probe(struct mmc_card *card) {
struct mmc_blk_data *md, *part_md;
@@ -1771,6 +1803,17 @@ static int mmc_blk_probe(struct mmc_card *card)
mmc_set_drvdata(card, md);
mmc_fixup_device(card, blk_fixups);
+#ifdef CONFIG_MMC_BLOCK_BOUNCE
+ md-bouncesz.show = mmc_bouncesz_show;
+ md-bouncesz.store = mmc_bouncesz_store;
+ sysfs_attr_init(md-bouncesz.attr);
+
RE: [PATCH V2 2/2] mmc/doc: feature description of runtime bounce buffer size adjustment
Hi Chris, Is the description OK? Thanks. From: Liu Qiang-B32616 Sent: Wednesday, December 21, 2011 1:10 AM To: c...@laptop.org; linux-mmc@vger.kernel.org Cc: Li Yang-R58472; Liu Qiang-B32616; Liu Qiang-B32616 Subject: [PATCH V2 2/2] mmc/doc: feature description of runtime bounce buffer size adjustment Add feature description about runtime bounce buffer size adjustment. CC: Chris Ball c...@laptop.org Signed-off-by: Qiang Liu qiang@freescale.com --- changes for V2 add suplementary description of bouncesz limitation Documentation/mmc/mmc-dev-attrs.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt index 22ae844..1314cab 100644 --- a/Documentation/mmc/mmc-dev-attrs.txt +++ b/Documentation/mmc/mmc-dev-attrs.txt @@ -7,6 +7,8 @@ SD or MMC device. The following attributes are read/write. force_roEnforce read-only access even if write protect switch is off. + bounceszSupport dynamic adjustment of bounce buffer size at runtime, + from 4096 to 4194304, integer multiple of 512 bytes only. SD and MMC Device Attributes -- 1.6.4 -- 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 RFC] mmc : omap_hsmmc : Save and restore the sysc across reset
On Monday 16 January 2012 06:41 PM, ext-denis.2.kar...@nokia.com wrote:
ext Shubhrajyoti D wrote on 2012-01-16:
The commit 11dd62:[omap_hsmmc: context save/restore support]
does a reset and restores AUTOIDLE settings.
This patch saves the register does a reset and restores
the same configuration.
...
if (pdata-get_context_loss_count) {
@@ -700,6 +700,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host
*host)
time_before(jiffies, timeout))
;
+sysc = OMAP_HSMMC_READ(host-base, SYSCONFIG);
/* Do software reset */
OMAP_HSMMC_WRITE(host-base, SYSCONFIG, SOFTRESET);
timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
@@ -707,8 +708,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host
*host)
time_before(jiffies, timeout))
;
-OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
-OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+OMAP_HSMMC_WRITE(host-base, SYSCONFIG, sysc);
The meaning of the code is to restore the register context after it was lost
during transition into low power consumption state. SW reset is needed to
bring all the registers in a consistent state before reconfiguring some of
them.
Agreed thanks.
Saving and restoring the SYSCONFIG register across SW reset is not needed.
Also re-configuring AUTOIDLE feature is not necessary since SYSCONFIG reset
value has is 1 already, according to TRM. I guess it was done to make things
more explicit.
However in addition to autoidle there are other bits in the register
like the sidle mode , enable wakeup which will get not get overwritten now.
Do you agree?
Denis
--
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 RFC] mmc : omap_hsmmc : Save and restore the sysc across reset
ext Shubhrajyoti wrote on 2012-01-16:
On Monday 16 January 2012 06:41 PM, ext-denis.2.kar...@nokia.com wrote:
ext Shubhrajyoti D wrote on 2012-01-16:
The commit 11dd62:[omap_hsmmc: context save/restore support]
does a reset and restores AUTOIDLE settings.
This patch saves the register does a reset and restores
the same configuration.
...
if (pdata-get_context_loss_count) {
@@ -700,6 +700,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
time_before(jiffies, timeout)) ; + sysc =
OMAP_HSMMC_READ(host-base, SYSCONFIG);/* Do software reset */
OMAP_HSMMC_WRITE(host-base, SYSCONFIG, SOFTRESET); timeout =
jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
@@ -707,8 +708,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
time_before(jiffies, timeout))
;
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_WRITE(host-base, SYSCONFIG, sysc);
The meaning of the code is to restore the register context after it was lost
during transition into low power consumption state. SW reset is needed to
bring
all the registers in a consistent state before reconfiguring some of them.
Agreed thanks.
Saving and restoring the SYSCONFIG register across SW reset is not needed.
Also re-configuring AUTOIDLE feature is not necessary since SYSCONFIG reset
value has is 1 already, according to TRM. I guess it was done to make things
more explicit.
However in addition to autoidle there are other bits in the register
like the sidle mode , enable wakeup which will get not get overwritten now.
Do you agree?
No, there's no need to do that - after SW reset the registers have predefined
reset values; the reset value is correct in case of SYSCONFIG register for most
of omap3|4 boards based, doesn't need any update after SW reset.
If in case of your board the reset value of SYSCONFIG register is not what you
want - you still cannot rely on the contents of the SYSCONFIG register once the
context was lost, i.e. saving its value before SW reset doesn't help.
You would need to initialize it to the proper value after the SW reset
manually, probably the same value that you used during initialization.
Denis
--
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 RFC] mmc : omap_hsmmc : Save and restore the sysc across reset
On Monday 16 January 2012 08:23 PM, ext-denis.2.kar...@nokia.com wrote:
ext Shubhrajyoti wrote on 2012-01-16:
On Monday 16 January 2012 06:41 PM, ext-denis.2.kar...@nokia.com wrote:
ext Shubhrajyoti D wrote on 2012-01-16:
The commit 11dd62:[omap_hsmmc: context save/restore support]
does a reset and restores AUTOIDLE settings.
This patch saves the register does a reset and restores
the same configuration.
...
if (pdata-get_context_loss_count) {
@@ -700,6 +700,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
time_before(jiffies, timeout)) ; + sysc =
OMAP_HSMMC_READ(host-base, SYSCONFIG); /* Do software reset */
OMAP_HSMMC_WRITE(host-base, SYSCONFIG, SOFTRESET); timeout =
jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
@@ -707,8 +708,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
time_before(jiffies, timeout))
;
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_WRITE(host-base, SYSCONFIG, sysc);
The meaning of the code is to restore the register context after it was lost
during transition into low power consumption state. SW reset is needed to
bring
all the registers in a consistent state before reconfiguring some of them.
Agreed thanks.
Saving and restoring the SYSCONFIG register across SW reset is not needed.
Also re-configuring AUTOIDLE feature is not necessary since SYSCONFIG reset
value has is 1 already, according to TRM. I guess it was done to make things
more explicit.
However in addition to autoidle there are other bits in the register
like the sidle mode , enable wakeup which will get not get overwritten now.
Do you agree?
No, there's no need to do that - after SW reset the registers have predefined
reset values; the reset value is correct in case of SYSCONFIG register for
most of omap3|4 boards based, doesn't need any update after SW reset.
If in case of your board the reset value of SYSCONFIG register is not what
you want - you still cannot rely on the contents of the SYSCONFIG register
once the context was lost, i.e. saving its value before SW reset doesn't
help.
You would need to initialize it to the proper value after the SW reset
manually, probably the same value that you used during initialization.
if you check the following code
arch/arm/mach-omap2/omap_hwmod_44xx_data.c
/*
* 'mmc' class
* multimedia card high-speed/sd/sdio (mmc/sd/sdio) host controller
*/
static struct omap_hwmod_class_sysconfig omap44xx_mmc_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_MIDLEMODE |
SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
SYSC_HAS_SOFTRESET),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
.sysc_fields= omap_hwmod_sysc_type2,
arch/arm/mach-omap2/omap_hwmod.c
* upon error or 0 upon success.
*/
static int _enable_wakeup(struct omap_hwmod *oh, u32 *v)
{
if (!oh-class-sysc ||
!((oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP) ||
(oh-class-sysc-idlemodes SIDLE_SMART_WKUP) ||
(oh-class-sysc-idlemodes MSTANDBY_SMART_WKUP)))
return -EINVAL;
if (!oh-class-sysc-sysc_fields) {
WARN(1, omap_hwmod: %s: offset struct for sysconfig not
provided in class\n, oh-name);
return -EINVAL;
}
if (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)
*v |= 0x1 oh-class-sysc-sysc_fields-enwkup_shift;
if (oh-class-sysc-idlemodes SIDLE_SMART_WKUP)
_set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
if (oh-class-sysc-idlemodes MSTANDBY_SMART_WKUP)
_set_master_standbymode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
however, I agree we could use hwmod framework to reset.
Denis
--
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: core: claim host during mmc_power_off on suspend
On Wed, Jan 11, 2012 at 16:51, Arik Nemtsov a...@wizery.com wrote: Make sure the host is claimed in all calls of mmc_power_off() during suspend. In addition make sure mmc_power_off() isn't called twice in some suspend flows. Signed-off-by: Arik Nemtsov a...@wizery.com Signed-off-by: Ido Yariv i...@wizery.com ping -- 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: dw-mmc: add the capability of power-off -notify feature
Thanks, Will That's typo.. Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com On 01/13/2012 08:05 PM, Will Newton wrote: On Fri, Jan 13, 2012 at 8:31 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: This patch add the capability of power off notify for dw-mmc controller. In order to use Girish's patch(mmc: core: Add Power Off Notify Feature eMMC 4.5) Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Kyungmin Park kyungmin p...@samsung.com The patch looks ok but the email address for Kyungmin Park is broken. Otherwise: Acked-by: Will Newton will.new...@imgtec.com -- 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 -- 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: core: claim host during mmc_power_off on suspend
On 11/01/12 16:51, Arik Nemtsov wrote:
Make sure the host is claimed in all calls of mmc_power_off() during
suspend. In addition make sure mmc_power_off() isn't called twice in
some suspend flows.
Signed-off-by: Arik Nemtsov a...@wizery.com
Signed-off-by: Ido Yariv i...@wizery.com
---
drivers/mmc/core/core.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 950b97d..d830c5c 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2305,6 +2305,7 @@ EXPORT_SYMBOL(mmc_cache_ctrl);
int mmc_suspend_host(struct mmc_host *host)
{
int err = 0;
+ bool powered_off = false;
if (host-caps MMC_CAP_DISABLE)
cancel_delayed_work(host-disable);
@@ -2348,6 +2349,7 @@ int mmc_suspend_host(struct mmc_host *host)
mmc_release_host(host);
host-pm_flags = 0;
err = 0;
+ powered_off = true;
}
} else {
err = -EBUSY;
@@ -2355,8 +2357,11 @@ int mmc_suspend_host(struct mmc_host *host)
}
mmc_bus_put(host);
- if (!err !mmc_card_keep_power(host))
+ if (!powered_off !err !mmc_card_keep_power(host)) {
+ mmc_claim_host(host);
Why not mmc_try_claim_host() etc?
mmc_power_off(host);
+ mmc_release_host(host);
+ }
out:
return err;
--
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
