[PATCH] mmc: core: add the warning message when card didn't support HPI
Though card didn't support HPI,someone could use the send_hpi_cmd().
Then maybe didn't work fine.
Because card-ext_csd.hpi_cmd didn't set.
So if card didn't support hpi, return the waring message.
And CMD12's flags is MMC_RSP_R1B.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/core/mmc_ops.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 4d41fa9..395f944 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -556,9 +556,15 @@ int mmc_send_hpi_cmd(struct mmc_card *card, u32 *status)
unsigned int flags;
int err;
+ if (!card-ext_csd.hpi) {
+ pr_waring(%s: Card didn't support HPI command\n,
+ mmc_hostname(card-host));
+ return -EINVAL;
+ }
+
opcode = card-ext_csd.hpi_cmd;
if (opcode == MMC_STOP_TRANSMISSION)
- flags = MMC_RSP_R1 | MMC_CMD_AC;
+ flags = MMC_RSP_R1B | MMC_CMD_AC;
else if (opcode == MMC_SEND_STATUS)
flags = MMC_RSP_R1 | MMC_CMD_AC;
--
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/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree
Hi Grant,
On Friday 09 March 2012 11:12 AM, Grant Likely wrote:
On Thu, 23 Feb 2012 17:31:27 +0530, Rajendra Nayakrna...@ti.com wrote:
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.
Signed-off-by: Rajendra Nayakrna...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 31 +
drivers/mmc/host/omap_hsmmc.c | 68
2 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be ti,omap2-hsmmc, for OMAP2/3 controllers
+ Should be ti,omap4-hsmmc, for OMAP4 controllers
+- ti,hwmods: Must be mmcn, n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+supply-name-supply: phandle to the regulator device tree node
+supply-name examples are vmmc, vmmc_aux etc
+ti,bus-width: Number of data lines, default assumed is 1 if the property is
missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
Binding looks okay. A couple comments below...
[...]
+static const struct of_device_id omap_mmc_of_match[];
If you move the omap_mmc_of_match[] table up to here then there is no
need for the forward declaration.
+
static int __init omap_hsmmc_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev-dev.platform_data;
@@ -1725,6 +1768,14 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+ const struct of_device_id *match;
+
+ match = of_match_device(omap_mmc_of_match,pdev-dev);
+ if (match) {
+ pdata = of_get_hsmmc_pdata(pdev-dev);
+ if (match-data)
+ pdata-reg_offset = *(u16 *)match-data;
Blech on the ugly cast. It is slightly safer to do thusly:
u16 *offsetp = match-data;
pdata-reg_offset = *offsetp
thanks for the review. I'll repost with these changes.
regards,
Rajendra
+ }
if (pdata == NULL) {
dev_err(pdev-dev, Platform Data is missing\n);
@@ -2120,12 +2171,29 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.runtime_resume = omap_hsmmc_runtime_resume,
};
+#if defined(CONFIG_OF)
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
+ {
+ .compatible = ti,omap2-hsmmc,
+ },
+ {
+ .compatible = ti,omap4-hsmmc,
+ .data =omap4_reg_offset,
+ },
+ {},
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
+#endif
+
static struct platform_driver omap_hsmmc_driver = {
.remove = omap_hsmmc_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
.pm =omap_hsmmc_dev_pm_ops,
+ .of_match_table = of_match_ptr(omap_mmc_of_match),
},
};
--
1.7.1
___
linaro-dev mailing list
linaro-...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
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 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data
On Friday 09 March 2012 11:16 AM, Grant Likely wrote:
On Fri, 24 Feb 2012 10:49:00 -0800, Tony Lindgrent...@atomide.com wrote:
* Rajendra Nayakrna...@ti.com [120223 19:29]:
On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
#size-cells =0;
ti,hwmods = i2c3;
};
+
+ mmc1: mmc@1 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ };
+
+ mmc2: mmc@2 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc2;
+ };
+
+ mmc3: mmc@3 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc3;
+ };
+
+ mmc4: mmc@4 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc4;
+ };
+
+ mmc5: mmc@5 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc5;
+ };
};
};
These all should all be ti,omap3-hsmmc I guess?
Well, I defined the binding such that both omap2 and omap3
can use the same compatible ti,omap2-hsmmc since there is
no difference in the way they are defined or handled. If thats
confusing, I can have separate compatibles.
Btw, I guess we do the same with a few other re-used IPs as well,
I just checked and mcpsi does the same.
Yeah let's use separate compatibles to avoid confusion.
For omap2 we also have the ti,omap2-mmc in addition to
ti,omap2-hsmmc..
Yes, absolutely use separate compatible values. It is always important
to be specific as to the silicon implementing the IP. The omap3 instance
can also carry the omap2 string in its compatible list:
compatible = ti,omap3-hsmmc, ti,omap2-hsmmc;
Sure, will repost with seperate compatible strings. Also missed adding
the 'status = disable;' for unused mmc blocks in the board .dts file
causing unused mmc modules to get probed too. Will fix that as well.
thanks,
Rajendra
g.
--
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 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data
Hi Paul, On Friday 09 March 2012 12:21 PM, Paul Walmsley wrote: On Thu, 8 Mar 2012, Grant Likely wrote: Yes, absolutely use separate compatible values. It is always important to be specific as to the silicon implementing the IP. In that case, it is probably best to use the full chip name in the compatible string, e.g., omap2420 or omap2430 rather than just omap2. Since omap2420 and omap2430 have different MMC controllers (and these bindings only cover the hsmmc controller used in 2430 and beyond, I haven't done the bindings for the legacy one yet), the idea was to differentiate between omap2420 and omap2430 by using compatible of ti,omap2-hsmmc for the High-Speed controller used in OMAP2 (2430) and ti,omap2-mmc for the legacy one used in OMAP2 (2420). Does that sound good to you? Particularly in the case of OMAP3, which is a largely meaningless group these days with AM33xx, OMAP34xx, OMAP36xx, and AM3517, many of which are quite different from each other... But these bindings are specific and limited to HSMMC module which is not quite different in the different SoC variants. There is a single driver to handle hsmmc module on all the SoCs which does not need to differentiate which SoC it is on. regards, Rajendra - Paul -- 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 v3 0/4] mmc: sdhci-s3c: use the sdhci-pltfm.c and move the header file
On Fri, Mar 09, 2012 at 10:53:26AM +0900, Jaehoon Chung wrote: On 03/08/2012 08:01 PM, Mark Brown wrote: It should be fine, like I say I didn't really read the patches in enough detail as the diffstat set off alarm bells. If you have any opinions, let me know. I believe that these patches can be maintain more efficiently for eMMC Like I said I think it's fine. If it helps: Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com signature.asc Description: Digital signature
Re: [PATCH 2/2] mmc: sdhci-s3c: Enable runtime power management
On Fri, Mar 09, 2012 at 12:08:58AM -0500, Chris Ball wrote: The reworked patch is below, please let me know if it looks incorrect: That looks about right, I'll find out soon enough if it doesn't work in -next as my main development system has the rootfs on this device :) signature.asc Description: Digital signature
RE: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
-Original Message- From: Chris Ball [mailto:c...@laptop.org] Sent: Thursday, March 08, 2012 10:39 PM To: Maupin, Chase Cc: linux-o...@vger.kernel.org; linux-mmc@vger.kernel.org Subject: Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices Hi Chase, On Thu, Mar 01 2012, Chase Maupin wrote: * With certain SD cards timeouts like the following have been seen due to an improper calculation of the dto value: mmcblk0: error -110 transferring data, sector 4126233, nr 8, card status 0xc00 * By removing the dto calculation and setting the timeout value to the maximum specified by the SD card specification part A2 section 2.2.15 these timeouts can be avoided. * This change has been used by beagleboard users as well as the Texas Instruments SDK without a negative impact. * There are multiple discussion threads about this but the most relevant ones are: * http://talk.maemo.org/showthread.php?p=1000707#post1000707 * http://www.mail-archive.com/linux- o...@vger.kernel.org/msg42213.html * Original proposal for this fix was done by Sukumar Ghoral of Texas Instruments * Tested using a Texas Instruments AM335x EVM Signed-off-by: Chase Maupin chase.mau...@ti.com Thanks, I've pushed this to mmc-next for 3.4. (With a trivial indentation fix, below.) Thank you Chris. diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 82b400793..9d4ce1c 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1360,7 +1360,7 @@ static void set_data_timeout(struct omap_hsmmc_host *host) if (clkd == 0) clkd = 1; -/* Use the maximum timeout value allowed in the standard of 14 or 0xE */ + /* Use the maximum timeout value allowed in the standard of 14 or 0xE */ dto = 14; reg = ~DTO_MASK; - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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: add the warning message when card didn't support HPI
Hi,
On Fri, Mar 09 2012, Jaehoon Chung wrote:
Though card didn't support HPI,someone could use the send_hpi_cmd().
Then maybe didn't work fine.
Because card-ext_csd.hpi_cmd didn't set.
So if card didn't support hpi, return the waring message.
And CMD12's flags is MMC_RSP_R1B.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/core/mmc_ops.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 4d41fa9..395f944 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -556,9 +556,15 @@ int mmc_send_hpi_cmd(struct mmc_card *card, u32 *status)
unsigned int flags;
int err;
+ if (!card-ext_csd.hpi) {
+ pr_waring(%s: Card didn't support HPI command\n,
This isn't going to compile. Please compile test patches before sending
them.
+ mmc_hostname(card-host));
+ return -EINVAL;
+ }
+
opcode = card-ext_csd.hpi_cmd;
if (opcode == MMC_STOP_TRANSMISSION)
- flags = MMC_RSP_R1 | MMC_CMD_AC;
+ flags = MMC_RSP_R1B | MMC_CMD_AC;
else if (opcode == MMC_SEND_STATUS)
flags = MMC_RSP_R1 | MMC_CMD_AC;
Thanks,
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
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] drivers: mmc: sdhci-s3c: fix broken compilation for non-Exynos SoCs
exynos4_sdhci_drv_data structure is not available on non-Exynos builds,
that's why EXYNOS4_SDHCI_DRV_DATA macro has been introduced. This patch
fixes commit 67819656 'mmc: sdhci-s3c: Add device tree support' to use
that macro. This fixes broken build for pre-Exynos SoCs.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/mmc/host/sdhci-s3c.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index ea0767e..984601e 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -859,7 +859,7 @@ MODULE_DEVICE_TABLE(platform, sdhci_s3c_driver_ids);
static const struct of_device_id sdhci_s3c_dt_match[] = {
{ .compatible = samsung,s3c6410-sdhci, },
{ .compatible = samsung,exynos4210-sdhci,
- .data = exynos4_sdhci_drv_data },
+ .data = EXYNOS4_SDHCI_DRV_DATA },
{},
};
MODULE_DEVICE_TABLE(of, sdhci_s3c_dt_match);
--
1.7.1.569.g6f426
--
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] mmc: sh_mobile_sdhi: support modular mmc-core with non-standard hotplug
On Fri, Mar 9, 2012 at 6:16 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Currently if a platform wants to implement a non-standard card-detection method, it would need to call tmio_mmc_cd_wakeup(), which is an inline function, calling mmc_detect_change(). For this the platform would have to link mmc_core statically into the kernel, losing the ability to build it as a module. This patch adds a callback to the sh_mobile_sdhi driver, which eliminates this dependency. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Looks good to me, thanks for this! Acked-by: Magnus Damm d...@opensource.se -- 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 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
On Thu, 8 Mar 2012, Kevin Hilman wrote: The word wakeup may refer to many different things, as well as the word resume. :-) Yes, but what's the confusion in this case? IMO, The existing /sys/devices/.../power/wakeup* meaning is the same meaning as as for the wakeup latency in this patch, No, it is not. They refer to system wakeup. :-) OK, now I'm confused (again). I thought those could be used for runtime PM wakeups also. At least I was planning on using them for any kind of wakeup. so I don't understand where the confusion would be. See above. ;-) Sheesh, this is getting ugly. So wakeup* attributes refer to system resume and resume* attribues refer to runtime PM. Yuck. How about calling it runtime latency? Or runtime wakeup latency in case people think there might be some other sort of latency associated with runtime power management. Alan Stern -- 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 3/4] arm/dts: OMAP4: Add mmc controller nodes and board data
On Fri, 24 Feb 2012 15:56:52 +0530, Rajendra Nayak rna...@ti.com wrote:
On Friday 24 February 2012 03:46 PM, T Krishnamoorthy, Balaji wrote:
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29f4589..9204f60 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -25,6 +25,11 @@
serial1 =uart2;
serial2 =uart3;
serial3 =uart4;
+ mmc1 =mmc1;
+ mmc2 =mmc2;
+ mmc3 =mmc3;
+ mmc4 =mmc4;
+ mmc5 =mmc5;
};
cpus {
@@ -155,5 +160,31 @@
#size-cells =0;
ti,hwmods = i2c4;
};
+
+ mmc1: mmc@1 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ };
+
+ mmc2: mmc@2 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc2;
+ };
Hi Rajendra,
Is there a way to control the device registration order,
eMMC connected to mmc2 needs to be registered as /dev/mmcblk0p ...
irrespective of whether SD card is mount or not on mmc1 card slot.
So that bootargs would not have to be modified when filesystem is on eMMC.
I don't know if we can, but even if we could, we take care of the same
bootargs working on two boards (say sdp and panda) *if* on sdp I have my
filesystem on eMMC and on panda I have it on external card.
What happens if I want to use my filesystem on both boards on external
card?
of_alias_get_id() may be able to help you here. It will extract the id
numbering from the /aliases node. That is the safe way to do global
enumeration of devices in the device tree (instead of 'cell-index' which
is strongly discouraged)
g.
+
+ mmc3: mmc@3 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc3;
+ };
+
+ mmc4: mmc@4 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc4;
+ };
+
+ mmc5: mmc@5 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc5;
+ };
};
};
--
1.7.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.
--
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] drivers: mmc: sdhci-s3c: fix broken compilation for non-Exynos SoCs
On 03/09/12 05:44, Marek Szyprowski wrote:
exynos4_sdhci_drv_data structure is not available on non-Exynos builds,
that's why EXYNOS4_SDHCI_DRV_DATA macro has been introduced. This patch
fixes commit 67819656 'mmc: sdhci-s3c: Add device tree support' to use
that macro. This fixes broken build for pre-Exynos SoCs.
I think, it is protected by CONFIG_OF and the pre-EXYNOS SoCs is not
support device tree yet. Could you please let me know the build error
and build condition?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
---
drivers/mmc/host/sdhci-s3c.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index ea0767e..984601e 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -859,7 +859,7 @@ MODULE_DEVICE_TABLE(platform, sdhci_s3c_driver_ids);
static const struct of_device_id sdhci_s3c_dt_match[] = {
{ .compatible = samsung,s3c6410-sdhci, },
{ .compatible = samsung,exynos4210-sdhci,
- .data =exynos4_sdhci_drv_data },
+ .data = EXYNOS4_SDHCI_DRV_DATA },
{},
};
MODULE_DEVICE_TABLE(of, sdhci_s3c_dt_match);
--
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] drivers: mmc: sdhci-s3c: fix broken compilation for non-Exynos SoCs
Hello, On Friday, March 09, 2012 4:56 PM Kukjin Kim wrote: On 03/09/12 05:44, Marek Szyprowski wrote: exynos4_sdhci_drv_data structure is not available on non-Exynos builds, that's why EXYNOS4_SDHCI_DRV_DATA macro has been introduced. This patch fixes commit 67819656 'mmc: sdhci-s3c: Add device tree support' to use that macro. This fixes broken build for pre-Exynos SoCs. I think, it is protected by CONFIG_OF and the pre-EXYNOS SoCs is not support device tree yet. Could you please let me know the build error and build condition? pre-EXYNOS SoC do not support device tree, but I had to enable flat device tree support to get them working once in the past and I still have it in my config. Now I see that kernel boots fine without enabling flat device tree, but imho the reported issue should be fixed to reduce the amount of work in the future. Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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: add the warning message when card didn't support HPI
Hi Chris.
Sorry..i will resend the patch after fixed.
Best Regards,
Jaehoon Chung
2012/3/9 Chris Ball c...@laptop.org:
Hi,
On Fri, Mar 09 2012, Jaehoon Chung wrote:
Though card didn't support HPI,someone could use the send_hpi_cmd().
Then maybe didn't work fine.
Because card-ext_csd.hpi_cmd didn't set.
So if card didn't support hpi, return the waring message.
And CMD12's flags is MMC_RSP_R1B.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/core/mmc_ops.c | 8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 4d41fa9..395f944 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -556,9 +556,15 @@ int mmc_send_hpi_cmd(struct mmc_card *card, u32 *status)
unsigned int flags;
int err;
+ if (!card-ext_csd.hpi) {
+ pr_waring(%s: Card didn't support HPI command\n,
This isn't going to compile. Please compile test patches before sending
them.
+ mmc_hostname(card-host));
+ return -EINVAL;
+ }
+
opcode = card-ext_csd.hpi_cmd;
if (opcode == MMC_STOP_TRANSMISSION)
- flags = MMC_RSP_R1 | MMC_CMD_AC;
+ flags = MMC_RSP_R1B | MMC_CMD_AC;
else if (opcode == MMC_SEND_STATUS)
flags = MMC_RSP_R1 | MMC_CMD_AC;
Thanks,
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
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 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
Alan Stern st...@rowland.harvard.edu writes: [...] How about calling it runtime latency? Or runtime wakeup latency in case people think there might be some other sort of latency associated with runtime power management. Either is better than just latency, but I would vote for runtime wakeup latency. 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 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
On Friday, March 09, 2012, Kevin Hilman wrote: Alan Stern st...@rowland.harvard.edu writes: [...] How about calling it runtime latency? Or runtime wakeup latency in case people think there might be some other sort of latency associated with runtime power management. Either is better than just latency, but I would vote for runtime wakeup latency. Well, that would be pm_qos_runtime_wakeup_latency_us. Kind of long, IMHO. Apart from this wakeup may be thought to refer to remote wakeup, which is when a device is resumed as a result of an external signal. pm_qos_resume_latency_us is shorter and since it is referred to in the documentation as resume latency, I don't see any problems with that name. Thanks, Rafael -- 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 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints
Rafael J. Wysocki r...@sisk.pl writes: On Friday, March 09, 2012, Kevin Hilman wrote: Alan Stern st...@rowland.harvard.edu writes: [...] How about calling it runtime latency? Or runtime wakeup latency in case people think there might be some other sort of latency associated with runtime power management. Either is better than just latency, but I would vote for runtime wakeup latency. Well, that would be pm_qos_runtime_wakeup_latency_us. Kind of long, IMHO. Yeah, the long names are why I initially suggested having a 'qos' subdir. Apart from this wakeup may be thought to refer to remote wakeup, which is when a device is resumed as a result of an external signal. pm_qos_resume_latency_us is shorter and since it is referred to in the documentation as resume latency, I don't see any problems with that name. OK 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
UHS card problem
I have a 3.0 host controller on a board that only does 3.3V. The capabilities registers don't specify support for any UHS modes and also don't show support for 1.8V. When I insert a UHS card the driver tries to switch to 1.8V and fails to init the card. I was hoping I could set the CAP registers so that the UHS card would just be run at HS/3.3V but I don't see a good way to do this in the current driver. Is this a driver issue or is there a capabilities setting that I'm missing? Thanks Al Cooper -- 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
