Re: FW: [PATCH v2] mmc: sdhci: apply voltage range check only for non-fixed regulators

[Marek Szyprowski]

Hello,

On 11/14/2012 8:11 AM, Kevin Liu wrote:

> From: linux-mmc-ow...@vger.kernel.org 
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Chris Ball
> Sent: Tuesday, November 13, 2012 10:14 PM
> To: Marek Szyprowski
> Cc: linux-ker...@vger.kernel.org; linux-mmc@vger.kernel.org; Kyungmin Park; 
Mark Brown; Liam Girdwood; Philip Rakity
> Subject: Re: [PATCH v2] mmc: sdhci: apply voltage range check only for 
non-fixed regulators
>
> Hi,
>
> On Tue, Nov 13 2012, Marek Szyprowski wrote:
>>> On Tue, Nov 13 2012, Marek Szyprowski wrote:
>>> > Fixed regulators cannot change their voltage, so disable all voltage
>>> > range checking for them, otherwise the driver fails to operate with
>>> > fixed regulators. Up to now it worked only by luck, because
>>> > regulator_is_supported_voltage() function returned incorrect values.
>>> > Commit "regulator: fix voltage check in regulator_is_supported_voltage()"
>>> > fixed that function and now additional check is needed for fixed
>>> > regulators.
>>> >
>>> > Signed-off-by: Marek Szyprowski 
>>> > ---
>>> >  drivers/mmc/host/sdhci.c |2 +-
>>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >
>>> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> > index c7851c0..6f6534e 100644
>>> > --- a/drivers/mmc/host/sdhci.c
>>> > +++ b/drivers/mmc/host/sdhci.c
>>> > @@ -2923,7 +2923,7 @@ int sdhci_add_host(struct sdhci_host *host)
>>> >regulator_enable(host->vmmc);
>>> >
>>> >  #ifdef CONFIG_REGULATOR
>>> > -  if (host->vmmc) {
>>> > +  if (host->vmmc && regulator_count_voltages(host->vmmc) > 1) {
>>> >ret = regulator_is_supported_voltage(host->vmmc, 330,
>>> >330);
>>> >if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_330)))
>>>
>>> Thanks for the longer explanation.  I'm still missing something, though;
>>> what's wrong with running the check as it was with the new regulator code?
>>> (I haven't tried it yet.)
>>>
>>> #ifdef CONFIG_REGULATOR
>>>  if (host->vmmc) {
>>>  ret = regulator_is_supported_voltage(host->vmmc, 330,
>>>  330);
>>>  if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_330)))
>>>  caps[0] &= ~SDHCI_CAN_VDD_330;
>>>  ret = regulator_is_supported_voltage(host->vmmc, 300,
>>>  300);
>>>  if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_300)))
>>>  caps[0] &= ~SDHCI_CAN_VDD_300;
>>>  ret = regulator_is_supported_voltage(host->vmmc, 180,
>>>  180);
>>>  if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_180)))
>>>  caps[0] &= ~SDHCI_CAN_VDD_180;
>>>  }
>>> #endif /* CONFIG_REGULATOR */
>>>
>>> The point is to remove unsupported voltages, so if someone sets up a
>>> fixed regulator at 330, all of the other caps are disabled.  Why
>>> wouldn't that work without this change, and how are we supposed to
>>> remove those caps on a fixed regulator after your patchset?
>>>
>>> Thanks, sorry if I'm missing something obvious,
>>
>> On our boards eMMC is connected to fixed 2.8V regulator, what results in
>> clearing all available voltages and fail. The same situation is when one
>> enable dummy regulator and try to use sdhci with it. My patch fixes this
>> and restores sdhci to working state as it was before (before fixing
>> regulator regulator_is_supported_voltage() function and earlier when
>> MMC_BROKEN_VOLATGE capability was used).
>
> I see.  Sounds like a separate bug -- Philip (or anyone else), any
> idea how we should be treating eMMCs with a fixed voltage here?
>

I think we should check the voltage range rather than the voltage
point accoring to the spec.
Otherwise some valid voltage like 2.8v will be discarded by mistake.
My below old patch aim to fix this issue.
How do you think?

-Original Message-
From: Kevin Liu [mailto:keyuan@gmail.com]
Sent: Friday, September 28, 2012 3:56 PM
To: linux-mmc@vger.kernel.org; c...@laptop.org; pie...@ossman.eu;
ulf.hans...@linaro.org; Zhangfei Gao
Cc: Haojian Zhuang; Chao Xie; Philip Rakity; Kevin Liu; Jialing Fu
Subject: [PATCH v5 03/13] mmc: sdhci: use regulator min/max voltage
range according to spec

From: Kevin Liu 

For regulator vmmc/vmmcq, use voltage range as below
3.3v/3.0v: (2.7v, 3.6v)
1.8v: (1.7v, 1.95v)
Original code use the specific value which may fail in regulator
driver if it does NOT support the specific voltage.

Signed-off-by: Jialing Fu 
Signed-off-by: Kevin Liu 


Tested-by: Marek Szyprowski 

This patch restores sdhci devices to working state on Samsung boards
(tested on GONI and UniversalC210) after merging "regulator: fix voltage
check in regulator_is_supported_voltage()" patch to v3.7-rc6 (commit
f0f98b19e23d4426ca185e3d4ca80e6aff5ef51b). Would be great to have it
merged before the final v3.7 is out.


---
  drivers/mmc/host/sdhci.c |  

Re: [PATCH 1/3] mmc: omap_hsmmc: NULL pointer upon DTO after CC.

[Venkatraman S]

On Tuesday 20 November 2012 03:12 AM, Andreas Fenkart wrote:

Signed-off-by: Andreas Fenkart 
---
  drivers/mmc/host/omap_hsmmc.c |7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21ca331..13ef4a0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -991,9 +991,12 @@ static inline void omap_hsmmc_reset_controller_fsm(struct 
omap_hsmmc_host *host,
  static void hsmmc_command_incomplete(struct omap_hsmmc_host *host, int err)
  {
omap_hsmmc_reset_controller_fsm(host, SRC);
-   host->cmd->error = err;
+
+   if (host->cmd)
+   host->cmd->error = err;
  
  	if (host->data) {

+   host->data->error = err;
omap_hsmmc_reset_controller_fsm(host, SRD);
omap_hsmmc_dma_cleanup(host, err);
}
@@ -1022,7 +1025,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
*host, int status)
}
}
  
-	if (end_cmd || ((status & CC) && host->cmd))

+   if ((end_cmd || (status & CC)) && host->cmd)
omap_hsmmc_cmd_done(host, host->cmd);
if ((end_trans || (status & TC)) && host->mrq)
omap_hsmmc_xfer_done(host, data);

Hi Andreas,
  Thanks for this, but it's been fixed already with Balaji's patches 
which I reposted a few hours ago.

Can you please check if it fixes your issues ?
~V
--
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/2] mmc: sdhci-spear: Initialize sdhci clk to 50 MHz

[Viresh Kumar]

On 8 November 2012 20:39, Viresh Kumar  wrote:
> From: Vipul Kumar Samar 
>
> SPEAr sdhci driver expects the clock to be set to 50 MHz for proper 
> functioning.
> This patch sets clk to 50 MHz in probe.
>
> Signed-off-by: Vipul Kumar Samar 
> Signed-off-by: Viresh Kumar 

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

[PATCH 2/2] mmc/host/s3cmci: remove the excess "goto irq_out"

[Jing Wang]

From: Jing Wang 

This patch delete excess "goto irq_out", because the function can run as normal 
without this.

Signed-off-by: Jing Wang 
---
 drivers/mmc/host/s3cmci.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index 4638dda..e488e60 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -733,8 +733,6 @@ close_transfer:
clear_imask(host);
tasklet_schedule(&host->pio_tasklet);
 
-   goto irq_out;
-
 irq_out:
dbg(host, dbg_irq,
"csta:0x%08x dsta:0x%08x fsta:0x%08x dcnt:0x%08x status:%s.\n",
-- 
1.7.9.5

--
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: enable controller interrupt before calling mmc_start_host

[Yuvaraj Kumar]

Dear James,
Its not sufficient.In my case, sdio_reset command was submitted to
dw_mmc controller before interrupts are enabled.
By looking at your log,it seems something wrong with frequency set by
your U-boot.

Best Regards
Yuvaraj

On Mon, Nov 19, 2012 at 6:50 PM, James Hogan  wrote:
> On 19/11/12 13:01, Yuvaraj CD wrote:
>> As mmc_start_host is getting called before enabling the dw_mmc controller
>> interrupt, there is a problem of missing the SDMMC_INT_CMD_DONE for the
>> very first command sent by the sdio_reset.
>> This problem occurs only when we disable MMC debugging i.e, MMC_DEBUG [=n].
>> Hence this patch enables the dw_mmc controller interrupt before 
>> mmc_start_host.
>>
>> Signed-off-by: Yuvaraj CD 
>
> Hi Yuvaraj,
>
> I get the following errors after this patch is applied
> (2da1d7f2948900cd50d38643db39f790edb3cc96, merged in v3.7-rc5) and the
> driver doesn't work as a result. Reverting it fixes the problem.
>
> mmc0: error -110 whilst initialising SD card
> mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 30Hz, actual 
> 298922HZ div = 167)
> mmc0: error -110 whilst initialising SD card
> mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 20Hz, actual 
> 199680HZ div = 250)
> mmc0: error -110 whilst initialising SD card
> mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 195765Hz, actual 
> 195764HZ div = 255)
> mmc0: error -110 whilst initialising SD card
> mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 40Hz, actual 
> 399360HZ div = 125)
> mmc0: error -110 whilst initialising SD card
> mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 30Hz, actual 
> 298922HZ div = 167)
> mmc0: error -110 whilst initialising SD card
> mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 20Hz, actual 
> 199680HZ div = 250)
> mmc0: error -110 whilst initialising SD card
> mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 195765Hz, actual 
> 195764HZ div = 255)
> mmc0: error -110 whilst initialising SD card
>
> The interrupts are already cleared and disabled at the beginning of the
> probe function, so is the following sufficient (after reverting your
> patch) to fix the problem you've been observing?
>
> Thanks
> James
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index ec9b5a8..2be9899 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2266,7 +2266,6 @@ int dw_mci_probe(struct dw_mci *host)
>  * Enable interrupts for command done, data over, data empty, card 
> det,
>  * receive ready and error such as transmit, receive timeout, crc 
> error
>  */
> -   mci_writel(host, RINTSTS, 0x);
> mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
>SDMMC_INT_TXDR | SDMMC_INT_RXDR |
>DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
>
>
>> ---
>>  drivers/mmc/host/dw_mmc.c |   29 +++--
>>  1 file changed, 15 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index a23af77..729c031 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -2233,6 +2233,21 @@ int dw_mci_probe(struct dw_mci *host)
>> else
>> host->num_slots = ((mci_readl(host, HCON) >> 1) & 0x1F) + 1;
>>
>> +   /*
>> +* Enable interrupts for command done, data over, data empty, card 
>> det,
>> +* receive ready and error such as transmit, receive timeout, crc 
>> error
>> +*/
>> +   mci_writel(host, RINTSTS, 0x);
>> +   mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
>> +  SDMMC_INT_TXDR | SDMMC_INT_RXDR |
>> +  DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
>> +   mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci
>> interrupt */
>> +
>> +   dev_info(host->dev, "DW MMC controller at irq %d, "
>> +"%d bit host data width, "
>> +"%u deep fifo\n",
>> +host->irq, width, fifo_size);
>> +
>> /* We need at least one slot to succeed */
>> for (i = 0; i < host->num_slots; i++) {
>> ret = dw_mci_init_slot(host, i);
>> @@ -2262,20 +2277,6 @@ int dw_mci_probe(struct dw_mci *host)
>> else
>> host->data_offset = DATA_240A_OFFSET;
>>
>> -   /*
>> -* Enable interrupts for command done, data over, data empty, card 
>> det,
>> -* receive ready and error such as transmit, receive timeout, crc 
>> error
>> -*/
>> -   mci_writel(host, RINTSTS, 0x);
>> -   mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
>> -  SDMMC_INT_TXDR | SDMMC_INT_RXDR |
>> -  DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
>> -   mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci
>> interrupt */
>> -
>> -   dev_info(host->dev, "DW MMC controller at irq %d, "
>>

[PATCH] mmc: sdhci-s3c: Use NULL instead of 0 for pointers

[Tushar Behera]

The third argument for of_get_property() is a pointer, hence pass
NULL instead of 0.

Fixes following sparse warning.
drivers/mmc/host/sdhci-s3c.c:452:48: warning: Using plain integer as
NULL pointer
drivers/mmc/host/sdhci-s3c.c:457:52: warning: Using plain integer as
NULL pointer

Signed-off-by: Tushar Behera 
---
 drivers/mmc/host/sdhci-s3c.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index a54dd5d..80b10f2 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -449,12 +449,12 @@ static int __devinit sdhci_s3c_parse_dt(struct device 
*dev,
return -ENOMEM;
 
/* get the card detection method */
-   if (of_get_property(node, "broken-cd", 0)) {
+   if (of_get_property(node, "broken-cd", NULL)) {
pdata->cd_type = S3C_SDHCI_CD_NONE;
goto setup_bus;
}
 
-   if (of_get_property(node, "non-removable", 0)) {
+   if (of_get_property(node, "non-removable", NULL)) {
pdata->cd_type = S3C_SDHCI_CD_PERMANENT;
goto setup_bus;
}
-- 
1.7.4.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

[PATCH v3 2/2] mmc/host/rtsx: Explicitely include slab.h in rtsx_pci_sdmmc.c

[wei_wang]

From: Wei WANG 

This fixes the following build error on some architectures (parisc at least):

drivers/mmc/host/rtsx_pci_sdmmc.c: In function 'sd_normal_rw':
drivers/mmc/host/rtsx_pci_sdmmc.c:448:2: error: implicit
declaration of function 'kzalloc'
[-Werror=implicit-function-declaration]
drivers/mmc/host/rtsx_pci_sdmmc.c:448:6: warning: assignment
makes pointer from integer without a cast [enabled by default]
drivers/mmc/host/rtsx_pci_sdmmc.c:472:2: error: implicit
declaration of function 'kfree'
[-Werror=implicit-function-declaration]

Signed-off-by: Wei WANG 
Acked-by: Chris Ball 
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 067dd46..571915d 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -21,6 +21,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.7.9.5

--
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 v3 0/2] rtsx patch for for-next branch in MFD tree

[wei_wang]

From: Wei WANG 

Wei WANG (2):
  mmc/host/rtsx: Configure SD_CFG2 register in sd_rw_multi
  mmc/host/rtsx: Explicitely include slab.h in rtsx_pci_sdmmc.c

 drivers/mmc/host/rtsx_pci_sdmmc.c |2 ++
 1 file changed, 2 insertions(+)

-- 
1.7.9.5

--
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 v3 1/2] mmc/host/rtsx: Configure SD_CFG2 register in sd_rw_multi

[wei_wang]

From: Wei WANG 

For Realtek card reader, internal regsiter SD_CFG2 should be configured
before transferring data.
The default value of SD_CFG2 is proper for writing data. But for reading
sequence, the timing is not good enough. So in some extreme circumstance,
card reader may sample the response data from the card as good even if
the data is wrong. And this will cause the bad consequence.
In the prior version, the value of this register has been calculated,
but forgotten to write back to the internal register.

Signed-off-by: Wei WANG 
Acked-by: Chris Ball 
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 0e934bf..067dd46 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -405,6 +405,7 @@ static int sd_rw_multi(struct realtek_pci_sdmmc *host, 
struct mmc_request *mrq)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_DATA_SOURCE,
0x01, RING_BUFFER);
 
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_CFG2, 0xFF, cfg2);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_TRANSFER, 0xFF,
trans_mode | SD_TRANSFER_START);
rtsx_pci_add_cmd(pcr, CHECK_REG_CMD, SD_TRANSFER,
-- 
1.7.9.5

--
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 237/493] mmc: remove use of __devinit

[viresh kumar]

On Mon, Nov 19, 2012 at 11:53 PM, Bill Pemberton  wrote:
> CONFIG_HOTPLUG is going away as an option so __devinit is no longer
> needed.
>
> Signed-off-by: Bill Pemberton 
> Cc: Ludovic Desroches 
> Cc: Chris Ball 
> Cc: Manuel Lauss 
> Cc: "Michał Mirosław" 
> Cc: Jarkko Lavinen 
> Cc: Venkatraman S 
> Cc: Viresh Kumar 
> Cc: Guennadi Liakhovetski 
> Cc: Ian Molton 
> Cc: Bruce Chang 
> Cc: Harald Welte 
> Cc: Pierre Ossman 
> Cc: linux-mmc@vger.kernel.org
> Cc: uclinux-dist-de...@blackfin.uclinux.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: spear-de...@list.st.com
> ---
>  drivers/mmc/host/sdhci-spear.c |  8 +++-

Acked-by: Viresh Kumar 
--
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] mmc/host/rtsx: Configure SD_CFG2 register in sd_rw_multi

[Chris Ball]

Hi,

On Mon, Nov 19 2012, wwang wrote:
> It's about compatibility issue. The default value of SD_CFG2 is proper
> for writing data. But for reading sequence, the timing is not good
> enough. So in some extreme circumstance,  card reader may sample the
> response data from the card as good even if the data is wrong. And
> this will cause the bad consequence.
>
> Shall I modify the commit and resend the patchset again?

Thanks!  Yes, please resend.

I won't be merging this one because Samuel is merging the initial
patchset, but I'll merge patches for the MMC side after 3.8.  For these:

Acked-by: Chris Ball 

- Chris.
-- 
Chris Ball  
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 077/493] mmc: remove use of __devexit_p

[viresh kumar]

On Mon, Nov 19, 2012 at 11:50 PM, Bill Pemberton  wrote:
> CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
> needed.
>
> Signed-off-by: Bill Pemberton 
> Cc: Chris Ball 
> Cc: "Michał Mirosław" 
> Cc: Jarkko Lavinen 
> Cc: Venkatraman S 
> Cc: Viresh Kumar 
> Cc: Guennadi Liakhovetski 
> Cc: Ian Molton 
> Cc: Bruce Chang 
> Cc: Harald Welte 
> Cc: Pierre Ossman 
> Cc: uclinux-dist-de...@blackfin.uclinux.org
> Cc: linux-mmc@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: spear-de...@list.st.com
> ---
>  drivers/mmc/host/sdhci-spear.c | 2 +-

Acked-by: Viresh Kumar 
--
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] mmc/host/rtsx: Configure SD_CFG2 register in sd_rw_multi

[wwang]

于 2012年11月20日 10:21, Chris Ball 写道:

Hi,

Sorry to be pedantic, but:

On Mon, Nov 19 2012, wei_w...@realsil.com.cn wrote:

For Realtek card reader, internal regsiter SD_CFG2 should be configured
before transferring data. In the prior version, the value of this register
has been calculated, but forgotten to write back to the internal register.

With what consequences?  Was the  data transfer failing?  Under which
circumstances?

Thanks,

- Chris.


Hi Chris:

It's about compatibility issue. The default value of SD_CFG2 is proper 
for writing data. But for reading sequence, the timing is not good 
enough. So in some extreme circumstance,  card reader may sample the 
response data from the card as good even if the data is wrong. And this 
will cause the bad consequence.


Shall I modify the commit and resend the patchset again?

BR,
Wei WANG
--
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] mmc/host/rtsx: Configure SD_CFG2 register in sd_rw_multi

[Chris Ball]

Hi,

Sorry to be pedantic, but:

On Mon, Nov 19 2012, wei_w...@realsil.com.cn wrote:
> For Realtek card reader, internal regsiter SD_CFG2 should be configured
> before transferring data. In the prior version, the value of this register
> has been calculated, but forgotten to write back to the internal register.

With what consequences?  Was the  data transfer failing?  Under which
circumstances?

Thanks,

- Chris.
-- 
Chris Ball  
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 v2 2/2] mmc/host/rtsx: Explicitely include slab.h in rtsx_pci_sdmmc.c

[wei_wang]

From: Wei WANG 

This fixes the following build error on some architectures (parisc at least):

drivers/mmc/host/rtsx_pci_sdmmc.c: In function 'sd_normal_rw':
drivers/mmc/host/rtsx_pci_sdmmc.c:448:2: error: implicit
declaration of function 'kzalloc'
[-Werror=implicit-function-declaration]
drivers/mmc/host/rtsx_pci_sdmmc.c:448:6: warning: assignment
makes pointer from integer without a cast [enabled by default]
drivers/mmc/host/rtsx_pci_sdmmc.c:472:2: error: implicit
declaration of function 'kfree'
[-Werror=implicit-function-declaration]

Signed-off-by: Wei WANG 
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 067dd46..571915d 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -21,6 +21,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.7.9.5

--
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 v2 1/2] mmc/host/rtsx: Configure SD_CFG2 register in sd_rw_multi

[wei_wang]

From: Wei WANG 

For Realtek card reader, internal regsiter SD_CFG2 should be configured
before transferring data. In the prior version, the value of this register
has been calculated, but forgotten to write back to the internal register.

Signed-off-by: Wei WANG 
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 0e934bf..067dd46 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -405,6 +405,7 @@ static int sd_rw_multi(struct realtek_pci_sdmmc *host, 
struct mmc_request *mrq)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_DATA_SOURCE,
0x01, RING_BUFFER);
 
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_CFG2, 0xFF, cfg2);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_TRANSFER, 0xFF,
trans_mode | SD_TRANSFER_START);
rtsx_pci_add_cmd(pcr, CHECK_REG_CMD, SD_TRANSFER,
-- 
1.7.9.5

--
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 v2 0/2] rtsx patch for for-next branch in MFD tree

[wei_wang]

From: Wei WANG 

Wei WANG (2):
  mmc/host/rtsx: Configure SD_CFG2 register in sd_rw_multi
  mmc/host/rtsx: Explicitely include slab.h in rtsx_pci_sdmmc.c

 drivers/mmc/host/rtsx_pci_sdmmc.c |2 ++
 1 file changed, 2 insertions(+)

-- 
1.7.9.5

--
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] mmc: fix async request mechanism for sequential read scenarios

[Seungwon Jeon]

On Thursday, November 15, 2012, Seungwon Jeon 
> I checked this commit.
> v3 doesn't work in dw_mmc host driver.
> It makes some driver warning while v1 is fine.
> I'm finding the reason. And could you check minor one below?
Please let me correct my test. There is something applied wrong.
Anyway I saw the working fine. Sorry for the confusion.

Thanks,
Seungwon Jeon
> 
> On Tuesday, November 13, 2012, Seungwon Jeon 
> > Hi Konstantin,
> >
> > I'm looking into this patch.
> > Idea looks good as a whole.
> >
> > On Tuesday, November 13, 2012, Konstantin Dorfman  
> > wrote:
> > > When current request is running on the bus and if next request fetched
> > > by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
> > > current request completes. This means if new request comes in while
> > > the mmcqd thread is blocked, this new request can not be prepared in
> > > parallel to current ongoing request. This may result in latency to
> > > start new request.
> > >
> > > This change allows to wake up the MMC thread (which
> > > is waiting for the current running request to complete). Now once the
> > > MMC thread is woken up, new request can be fetched and prepared in
> > > parallel to current running request which means this new request can
> > > be started immediately after the current running request completes.
> > >
> > > With this change read throughput is improved by 16%.
> > >
> > > Signed-off-by: Konstantin Dorfman 
> > > ---
> > > v3:
> > >   - new MMC_QUEUE_NEW_REQUEST flag to mark new request case
> > >   - lock added to update is_new_req flag
> > >   - condition for sending new req notification changed
> > >   - Moved start waiting for new req notification after
> > > fetching NULL
> > > v2:
> > >   - Removed synchronization flags
> > >   - removed lock from done()
> > >   - flags names changed
> > > v1:
> > >   - Initial submit
> > >
> > > diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> > > index 172a768..34d8bd9 100644
> > > --- a/drivers/mmc/card/block.c
> > > +++ b/drivers/mmc/card/block.c
> > > @@ -112,17 +112,6 @@ struct mmc_blk_data {
> > >
> > >  static DEFINE_MUTEX(open_lock);
> > >
> > > -enum mmc_blk_status {
> > > - MMC_BLK_SUCCESS = 0,
> > > - MMC_BLK_PARTIAL,
> > > - MMC_BLK_CMD_ERR,
> > > - MMC_BLK_RETRY,
> > > - MMC_BLK_ABORT,
> > > - MMC_BLK_DATA_ERR,
> > > - MMC_BLK_ECC_ERR,
> > > - MMC_BLK_NOMEDIUM,
> > > -};
> > > -
> > >  module_param(perdev_minors, int, 0444);
> > >  MODULE_PARM_DESC(perdev_minors, "Minors numbers to allocate per device");
> > >
> > > @@ -1225,6 +1214,7 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req 
> > > *mqrq,
> > >
> > >   mqrq->mmc_active.mrq = &brq->mrq;
> > >   mqrq->mmc_active.err_check = mmc_blk_err_check;
> > > + mqrq->mmc_active.mrq->context_info = &mq->context_info;
> > >
> > >   mmc_queue_bounce_pre(mqrq);
> > >  }
> > > @@ -1284,9 +1274,12 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue 
> > > *mq, struct request *rqc)
> > >   areq = &mq->mqrq_cur->mmc_active;
> > >   } else
> > >   areq = NULL;
> > > - areq = mmc_start_req(card->host, areq, (int *) &status);
> > > - if (!areq)
> > > + areq = mmc_start_req(card->host, areq, (int *)&status);
> > > + if (!areq) {
> > > + if (status == MMC_BLK_NEW_REQUEST)
> > > + mq->flags |= MMC_QUEUE_NEW_REQUEST;
> > >   return 0;
> > > + }
> > >
> > >   mq_rq = container_of(areq, struct mmc_queue_req, mmc_active);
> > >   brq = &mq_rq->brq;
> > > @@ -1295,6 +1288,8 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue 
> > > *mq, struct request *rqc)
> > >   mmc_queue_bounce_post(mq_rq);
> > >
> > >   switch (status) {
> > > + case MMC_BLK_NEW_REQUEST:
> > > + BUG(); /* should never get here */
> > >   case MMC_BLK_SUCCESS:
> > >   case MMC_BLK_PARTIAL:
> > >   /*
> > > @@ -1367,7 +1362,8 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue 
> > > *mq, struct request *rqc)
> > >* prepare it again and resend.
> > >*/
> > >   mmc_blk_rw_rq_prep(mq_rq, card, disable_multi, mq);
> > > - mmc_start_req(card->host, &mq_rq->mmc_active, NULL);
> > > + mmc_start_req(card->host, &mq_rq->mmc_active,
> > > + (int *)&status);
> > Here, we'll try to send previous request  which is not completed 
> > successfully.
> > And then at the top of do~while, mmc_start_req will be called for current 
> > request and get the status.
> > Above change looks like unnecessary. Is there any reason?
> >
> > Thanks,
> > Seungwon Jeon
> >
> > >   }
> > >   } while (ret);
> > >
> > > @@ -1407,6 +1403,8 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, 
> > > struct request *req)
> > >   goto out;
> > >   }
> > >
> > > + mq->flags &= ~MMC_QUEUE_NEW_REQUEST

Re: [PATCH 1/2] mmc: Configure SD_CFG2 register in sd_rw_multi

[Chris Ball]

Hi,

On Mon, Nov 19 2012, wei_w...@realsil.com.cn wrote:
> From: Wei WANG 
>
> Signed-off-by: Wei WANG 
> ---
>  drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
> b/drivers/mmc/host/rtsx_pci_sdmmc.c
> index 0e934bf..067dd46 100644
> --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
> +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
> @@ -405,6 +405,7 @@ static int sd_rw_multi(struct realtek_pci_sdmmc *host, 
> struct mmc_request *mrq)
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_DATA_SOURCE,
>   0x01, RING_BUFFER);
>  
> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_CFG2, 0xFF, cfg2);
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_TRANSFER, 0xFF,
>   trans_mode | SD_TRANSFER_START);
>   rtsx_pci_add_cmd(pcr, CHECK_REG_CMD, SD_TRANSFER,

Please write commit messages -- if this fixes a bug, what's the nature
of the bug that it fixes?  Thanks,

- Chris.
-- 
Chris Ball  
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 v3 4/4] mmc: dw-mmc: remove complier warning

[Jaehoon Chung]

Hi James,

This patch has already merged with Arnd's patch.
He also sent the same patch.

Best Regards,
Jaehoon Chung

On 11/19/2012 09:53 PM, James Hogan wrote:
> On 19/11/12 12:23, James Hogan wrote:
>> On 08/11/12 08:35, Jaehoon Chung wrote:
>>> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_prepare_command':
>>> drivers/mmc/host/dw_mmc.c:256:37: warning: initialization discards 'const' 
>>> qualifier from pointer target type [enabled by default]
>>> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_set_ios':
>>> drivers/mmc/host/dw_mmc.c:805:37: warning: initialization discards 'const' 
>>> qualifier from pointer target type [enabled by default]
>>> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_init_slot':
>>> drivers/mmc/host/dw_mmc.c:1849:37: warning: initialization discards 'const' 
>>> qualifier from pointer target type [enabled by default]
>>> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_parse_dt':
>>> drivers/mmc/host/dw_mmc.c:2049:37: warning: initialization discards 'const' 
>>> qualifier from pointer target type [enabled by default]
>>> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_probe':
>>> drivers/mmc/host/dw_mmc.c:2095:37: warning: initialization discards 'const' 
>>> qualifier from pointer target type [enabled by default]
>>>
>>> Signed-off-by: Jaehoon Chung 
>>
>> Acked-by: James Hogan 
> 
> Chris: Is it okay to get this patch into v3.7?
> 
> Thanks
> James
> 
> 

--
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 2/2] mmc: Explicitely include slab.h in rtsx_pci_sdmmc.c

[wei_wang]

From: Wei WANG 

Signed-off-by: Wei WANG 
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 067dd46..571915d 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -21,6 +21,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.7.9.5

--
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 0/2] rtsx patch for for-next branch in MFD tree

[wei_wang]

From: Wei WANG 

Wei WANG (2):
  mmc: Configure SD_CFG2 register in sd_rw_multi
  mmc: Explicitely include slab.h in rtsx_pci_sdmmc.c

 drivers/mmc/host/rtsx_pci_sdmmc.c |2 ++
 1 file changed, 2 insertions(+)

-- 
1.7.9.5

--
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 1/2] mmc: Configure SD_CFG2 register in sd_rw_multi

[wei_wang]

From: Wei WANG 

Signed-off-by: Wei WANG 
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 0e934bf..067dd46 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -405,6 +405,7 @@ static int sd_rw_multi(struct realtek_pci_sdmmc *host, 
struct mmc_request *mrq)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_DATA_SOURCE,
0x01, RING_BUFFER);
 
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_CFG2, 0xFF, cfg2);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_TRANSFER, 0xFF,
trans_mode | SD_TRANSFER_START);
rtsx_pci_add_cmd(pcr, CHECK_REG_CMD, SD_TRANSFER,
-- 
1.7.9.5

--
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] MMC: omap_hsmmc: add DT property for ti-swakeup-not-implemented.

[Andreas Fenkart]

Signed-off-by: Andreas Fenkart 
---
 arch/arm/boot/dts/am335x-sue-s800.dtsi |1 +
 drivers/mmc/host/omap_hsmmc.c  |3 +++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-sue-s800.dtsi 
b/arch/arm/boot/dts/am335x-sue-s800.dtsi
index 06304cc..7a446fe 100644
--- a/arch/arm/boot/dts/am335x-sue-s800.dtsi
+++ b/arch/arm/boot/dts/am335x-sue-s800.dtsi
@@ -158,6 +158,7 @@
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
ti,non-removable;
+   ti,swakeup-not-implemented;
bus-width = <4>;
vmmc-supply = <&ldo2_reg>;
vmmc_aux-supply = <&vmmc>;
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 90f4b32..290d5da 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1783,6 +1783,9 @@ static struct omap_mmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, "ti,dual-volt", NULL))
pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
 
+   if (of_find_property(np, "ti,swakeup-not-implemented", NULL))
+   pdata->controller_flags |= OMAP_HSMMC_SWAKEUP_NOT_IMPLEMENTED;
+
/* This driver only supports 1 slot */
pdata->nr_slots = 1;
pdata->slots[0].switch_pin = of_get_named_gpio(np, "cd-gpios", 0);
-- 
1.7.10.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

[PATCH 2/3] mmc: omap_hsmmc: Enable the use of SDIO card interrupts.

[Andreas Fenkart]

FCLK must be enabled while SDIO interrupts are enabled or the MMC
module won't wake-up (even though ENAWAKEUP in SYSCONFIG and IWE in
HTCL have been set).  Enabling the MMC module to wake-up would require
configuring the MMC module (and the mmci_dat[1] GPIO when the CORE
power domain is OFF) as wake-up sources in the PRCM.

The writes to STAT and ISE when starting a command are unnecessary and
have been removed.

Signed-off-by: David Vrabel 
Signed-off-by: Andreas Fenkart 
---
 drivers/mmc/host/omap_hsmmc.c  |   99 
 include/linux/platform_data/mmc-omap.h |1 +
 2 files changed, 88 insertions(+), 12 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 13ef4a0..90f4b32 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -106,7 +106,10 @@ static void apply_clk_hack(void)
 #define INT_EN_MASK0x307F0033
 #define BWR_ENABLE (1 << 4)
 #define BRR_ENABLE (1 << 5)
+#define CIRQ_ENABLE(1 << 8)
 #define DTO_ENABLE (1 << 20)
+#define CTPL   (1 << 11)
+#define CLKEXTFREE (1 << 16)
 #define INIT_STREAM(1 << 1)
 #define DP_SELECT  (1 << 21)
 #define DDIR   (1 << 4)
@@ -115,10 +118,12 @@ static void apply_clk_hack(void)
 #define BCE(1 << 1)
 #define FOUR_BIT   (1 << 1)
 #define DDR(1 << 19)
+#define IWE(1 << 24)
 #define DW8(1 << 5)
 #define CC 0x1
 #define TC 0x02
 #define OD 0x1
+#define CIRQ   (1 << 8)
 #define ERR(1 << 15)
 #define CMD_TIMEOUT(1 << 16)
 #define DATA_TIMEOUT   (1 << 20)
@@ -196,6 +201,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+   boolsdio_int;
struct omap_hsmmc_next  next_data;
 
struct  omap_mmc_platform_data  *pdata;
@@ -472,27 +478,45 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host 
*host)
 static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
  struct mmc_command *cmd)
 {
-   unsigned int irq_mask;
+   u32 irq_mask = INT_EN_MASK;
+   unsigned long flags;
 
if (host->use_dma)
-   irq_mask = INT_EN_MASK & ~(BRR_ENABLE | BWR_ENABLE);
-   else
-   irq_mask = INT_EN_MASK;
+   irq_mask &= ~(BRR_ENABLE | BWR_ENABLE);
 
/* Disable timeout for erases */
if (cmd->opcode == MMC_ERASE)
irq_mask &= ~DTO_ENABLE;
 
+   spin_lock_irqsave(&host->irq_lock, flags);
+
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
+
+   /* latch pending CIRQ, but don't signal */
+   if (host->sdio_int)
+   irq_mask |= CIRQ_ENABLE;
+
OMAP_HSMMC_WRITE(host->base, IE, irq_mask);
+
+   spin_unlock_irqrestore(&host->irq_lock, flags);
 }
 
 static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
 {
-   OMAP_HSMMC_WRITE(host->base, ISE, 0);
-   OMAP_HSMMC_WRITE(host->base, IE, 0);
+   u32 irq_mask = 0;
+   unsigned long flags;
+
+   spin_lock_irqsave(&host->irq_lock, flags);
+
+   if (host->sdio_int)
+   irq_mask |= CIRQ_ENABLE;
+
+   OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
+   OMAP_HSMMC_WRITE(host->base, IE, irq_mask);
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
+
+   spin_unlock_irqrestore(&host->irq_lock, flags);
 }
 
 /* Calculate divisor for the given clock frequency */
@@ -615,7 +639,7 @@ static int omap_hsmmc_context_restore(struct 
omap_hsmmc_host *host)
}
 
OMAP_HSMMC_WRITE(host->base, HCTL,
-   OMAP_HSMMC_READ(host->base, HCTL) | hctl);
+   OMAP_HSMMC_READ(host->base, HCTL) | hctl | IWE);
 
OMAP_HSMMC_WRITE(host->base, CAPA,
OMAP_HSMMC_READ(host->base, CAPA) | capa);
@@ -1040,8 +1064,13 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
 
status = OMAP_HSMMC_READ(host->base, STAT);
-   while (status & INT_EN_MASK && host->req_in_progress) {
-   omap_hsmmc_do_irq(host, status);
+   while (status & (INT_EN_MASK | CIRQ)) {
+
+   if (host->req_in_progress)
+   omap_hsmmc_do_irq(host, status);
+
+   if (status & CIRQ)
+   mmc_signal_sdio_irq(host->mmc);
 
/* Flush posted write */
OMAP_HSMMC_WRITE(host->base, STAT, status);
@@ -1557,6 +1586,50 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc, 
struct mmc_card *card)
mmc_slot(host).init_card(card);
 }
 
+static 

[PATCH 1/3] mmc: omap_hsmmc: NULL pointer upon DTO after CC.

[Andreas Fenkart]

Signed-off-by: Andreas Fenkart 
---
 drivers/mmc/host/omap_hsmmc.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21ca331..13ef4a0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -991,9 +991,12 @@ static inline void omap_hsmmc_reset_controller_fsm(struct 
omap_hsmmc_host *host,
 static void hsmmc_command_incomplete(struct omap_hsmmc_host *host, int err)
 {
omap_hsmmc_reset_controller_fsm(host, SRC);
-   host->cmd->error = err;
+
+   if (host->cmd)
+   host->cmd->error = err;
 
if (host->data) {
+   host->data->error = err;
omap_hsmmc_reset_controller_fsm(host, SRD);
omap_hsmmc_dma_cleanup(host, err);
}
@@ -1022,7 +1025,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
*host, int status)
}
}
 
-   if (end_cmd || ((status & CC) && host->cmd))
+   if ((end_cmd || (status & CC)) && host->cmd)
omap_hsmmc_cmd_done(host, host->cmd);
if ((end_trans || (status & TC)) && host->mrq)
omap_hsmmc_xfer_done(host, data);
-- 
1.7.10.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

[PATCH 0/3] mmc: omap_hsmmc: sdio irq am335x.

[Andreas Fenkart]

Here 2 patches enabling sdio irq on beaglebone and one bug fix. 

Signed-off-by: Andreas Fenkart 
--
 arch/arm/boot/dts/am335x-sue-s800.dtsi |1 +
 drivers/mmc/host/omap_hsmmc.c  |  109 
+++--
 include/linux/platform_data/mmc-omap.h |1 +
 3 files changed, 97 insertions(+), 14 deletions(-)



--
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 v1] mmc: fix async request mechanism for sequential read scenarios

[Per Förlin]

On 11/19/2012 03:32 PM, Per Förlin wrote:
> On 11/19/2012 10:48 AM, Konstantin Dorfman wrote:
>> Hello Per,
>>
>> Thank you for giving me an example, below I'm trying to explain some
>> logic issues of it and asking you some questions about your vision of
>> the patch.
>>
>> On 11/15/2012 06:38 PM, Per Förlin wrote:
>>> On 11/14/2012 04:15 PM, Konstantin Dorfman wrote:
 Hello Per,

 On 11/13/2012 11:10 PM, Per Forlin wrote:
> On Tue, Oct 30, 2012 at 1:19 PM, Konstantin Dorfman
>  wrote:
>> Hello,
>>
>> On 10/29/2012 11:40 PM, Per Forlin wrote:
>>> Hi,
>>>
>>> I would like to move the focus of my concerns from root cause analysis
>>> to the actual patch,
>>> My first reflection is that the patch is relatively complex and some
>>> of the code looks duplicated.
>>> Would it be possible to simplify it and re-use  the current execution 
>>> flow.
>>>
>>> Is the following flow feasible?
>>>
>>> in mmc_start_req():
>>> --
>>> if (rqc == NULL && not_resend)
>>>   wait_for_both_mmc_and_arrival_of_new_req
>>> else
>>>   wait_only_for_mmc
>>>
>>> if (arrival_of_new_req) {
>>>set flag to indicate fetch-new_req
>>>   return NULL;
>>> }
>>> -
>>>
>>> in queue.c:
>>> if (fetch-new_req)
>>>   don't overwrite previous req.
>>>
>>> BR
>>> Per
>>
>> You are talking about using both waiting mechanisms, old (wait on
>> completion) and new - wait_event_interruptible()? But how done()
>> callback, called on host controller irq context, will differentiate
>> which one is relevant for the request?
>>
>> I think it is better to use single wait point for mmc thread.
>
> I have sketch a patch to better explain my point. It's not tested it
> barely compiles :)
> The patch tries to introduce your feature and still keep the same code
> path. And it exposes an API that could be used by SDIO as well.
> The intention of my sketch patch is only to explain what I tried to
> visualize in the pseudo code previously in this thread.
> The out come of your final patch should be documented here I think:
> Documentation/mmc/mmc-async-req.txt
 This document is ready, attaching it to this mail and will be included
 in next version of the patch (or RESEND).
>
> Here follows my patch sketch:
> 
> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
> index e360a97..08036a1 100644
> --- a/drivers/mmc/card/queue.c
> +++ b/drivers/mmc/card/queue.c
> @@ -66,6 +66,8 @@ static int mmc_queue_thread(void *d)
>   spin_unlock_irq(q->queue_lock);
>
>   if (req || mq->mqrq_prev->req) {
> + if (!req)
> + 
> mmc_prefetch_start(&mq->mqrq_prev->mmc_active, true);
>   set_current_state(TASK_RUNNING);
>   mq->issue_fn(mq, req);
>   } else {
> @@ -79,11 +81,13 @@ static int mmc_queue_thread(void *d)
>   }
>
>   /* Current request becomes previous request and vice versa. 
> */
> - mq->mqrq_prev->brq.mrq.data = NULL;
> - mq->mqrq_prev->req = NULL;
> - tmp = mq->mqrq_prev;
> - mq->mqrq_prev = mq->mqrq_cur;
> - mq->mqrq_cur = tmp;
> + if (!mmc_prefetch_pending(&mq->mqrq_prev->mmc_active)) {
> + mq->mqrq_prev->brq.mrq.data = NULL;
> + mq->mqrq_prev->req = NULL;
> + tmp = mq->mqrq_prev;
> + mq->mqrq_prev = mq->mqrq_cur;
> + mq->mqrq_cur = tmp;
> + }
>   } while (1);
>   up(&mq->thread_sem);
>
> @@ -109,10 +113,44 @@ static void mmc_request_fn(struct request_queue *q)
>   return;
>   }
>
> + if (mq->prefetch_enable) {
> + spin_lock(&mq->prefetch_lock);
> + if (mq->prefetch_completion)
> + complete(mq->prefetch_completion);
>> Since mq->prefetch_completion init happens only in core.c after
>> mmc_start_req(NULL), we can miss all new request notifications coming
>> from fetching NULL request until then.
> It's a mistake in the patch.
> I meant check mq->prefetch_pending to know whether we need to wait in the 
> first place.
> That's why mq->prefetch_pending is assigned even if mq->prefetch_completion 
> is not set yet.
> Patch needs to be updated to take it into account. One could let 
> mmc_prefecth_init() return and indicate if there is already a NEW_REQ 
> pending. If this is the case skip wait.
> 
> 
> + mq->prefetch_pending = true;
> + spin_unlock(&mq->

[PATCH 313/493] mmc: remove use of __devinitdata

[Bill Pemberton]

CONFIG_HOTPLUG is going away as an option so __devinitdata is no
longer needed.

Signed-off-by: Bill Pemberton 
Cc: Chris Ball  
Cc: Grant Likely  
Cc: Rob Herring  
Cc: linux-mmc@vger.kernel.org 
Cc: devicetree-disc...@lists.ozlabs.org 
---
 drivers/mmc/host/mmc_spi.c | 2 +-
 drivers/mmc/host/sdhci-dove.c  | 2 +-
 drivers/mmc/host/sdhci-tegra.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index f7df798..1e2256b 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -1517,7 +1517,7 @@ static int __devexit mmc_spi_remove(struct spi_device 
*spi)
return 0;
 }
 
-static struct of_device_id mmc_spi_of_match_table[] __devinitdata = {
+static struct of_device_id mmc_spi_of_match_table[] = {
{ .compatible = "mmc-spi-slot", },
{},
 };
diff --git a/drivers/mmc/host/sdhci-dove.c b/drivers/mmc/host/sdhci-dove.c
index 334ec5c..73c0eb8 100644
--- a/drivers/mmc/host/sdhci-dove.c
+++ b/drivers/mmc/host/sdhci-dove.c
@@ -129,7 +129,7 @@ static int __devexit sdhci_dove_remove(struct 
platform_device *pdev)
return 0;
 }
 
-static const struct of_device_id sdhci_dove_of_match_table[] __devinitdata = {
+static const struct of_device_id sdhci_dove_of_match_table[] = {
{ .compatible = "marvell,dove-sdhci", },
{}
 };
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 339c41e..d3936d0 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -206,7 +206,7 @@ static struct sdhci_tegra_soc_data soc_data_tegra30 = {
 };
 #endif
 
-static const struct of_device_id sdhci_tegra_dt_match[] __devinitdata = {
+static const struct of_device_id sdhci_tegra_dt_match[] = {
 #ifdef CONFIG_ARCH_TEGRA_3x_SOC
{ .compatible = "nvidia,tegra30-sdhci", .data = &soc_data_tegra30 },
 #endif
-- 
1.8.0

--
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 362/493] mmc: remove use of __devinitconst

[Bill Pemberton]

CONFIG_HOTPLUG is going away as an option so __devinitconst is no
longer needed.

Signed-off-by: Bill Pemberton 
Cc: Chris Ball  
Cc: linux-mmc@vger.kernel.org 
---
 drivers/mmc/host/sdhci-pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
index ff91651..3844771 100644
--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -653,7 +653,7 @@ static const struct sdhci_pci_fixes sdhci_via = {
.probe  = via_probe,
 };
 
-static const struct pci_device_id pci_ids[] __devinitconst = {
+static const struct pci_device_id pci_ids[] = {
{
.vendor = PCI_VENDOR_ID_RICOH,
.device = PCI_DEVICE_ID_RICOH_R5C822,
-- 
1.8.0

--
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 237/493] mmc: remove use of __devinit

[Bill Pemberton]

CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.

Signed-off-by: Bill Pemberton 
Cc: Ludovic Desroches  
Cc: Chris Ball  
Cc: Manuel Lauss  
Cc: "Michał Mirosław"  
Cc: Jarkko Lavinen  
Cc: Venkatraman S  
Cc: Viresh Kumar  
Cc: Guennadi Liakhovetski  
Cc: Ian Molton  
Cc: Bruce Chang  
Cc: Harald Welte  
Cc: Pierre Ossman  
Cc: linux-mmc@vger.kernel.org 
Cc: uclinux-dist-de...@blackfin.uclinux.org 
Cc: linux-o...@vger.kernel.org 
Cc: linux-arm-ker...@lists.infradead.org 
Cc: spear-de...@list.st.com 
---
 drivers/mmc/host/atmel-mci.c   |  2 +-
 drivers/mmc/host/au1xmmc.c |  2 +-
 drivers/mmc/host/bfin_sdh.c|  2 +-
 drivers/mmc/host/cb710-mmc.c   |  2 +-
 drivers/mmc/host/dw_mmc-pci.c  |  2 +-
 drivers/mmc/host/dw_mmc-pltfm.c|  2 +-
 drivers/mmc/host/jz4740_mmc.c  |  8 
 drivers/mmc/host/mmci.c|  6 +++---
 drivers/mmc/host/omap.c|  4 ++--
 drivers/mmc/host/omap_hsmmc.c  |  2 +-
 drivers/mmc/host/pxamci.c  |  4 ++--
 drivers/mmc/host/s3cmci.c  |  2 +-
 drivers/mmc/host/sdhci-cns3xxx.c   |  2 +-
 drivers/mmc/host/sdhci-dove.c  |  2 +-
 drivers/mmc/host/sdhci-esdhc-imx.c |  4 ++--
 drivers/mmc/host/sdhci-of-esdhc.c  |  2 +-
 drivers/mmc/host/sdhci-of-hlwd.c   |  2 +-
 drivers/mmc/host/sdhci-pci.c   |  6 +++---
 drivers/mmc/host/sdhci-pxav2.c |  2 +-
 drivers/mmc/host/sdhci-pxav3.c |  2 +-
 drivers/mmc/host/sdhci-s3c.c   |  6 +++---
 drivers/mmc/host/sdhci-spear.c |  8 +++-
 drivers/mmc/host/sdhci-tegra.c |  4 ++--
 drivers/mmc/host/sh_mmcif.c|  2 +-
 drivers/mmc/host/sh_mobile_sdhi.c  |  2 +-
 drivers/mmc/host/tmio_mmc.c|  2 +-
 drivers/mmc/host/tmio_mmc_pio.c|  2 +-
 drivers/mmc/host/via-sdmmc.c   |  2 +-
 drivers/mmc/host/wbsd.c| 18 +-
 29 files changed, 52 insertions(+), 54 deletions(-)

diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 8689989..722af1d 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -511,7 +511,7 @@ static const struct of_device_id atmci_dt_ids[] = {
 
 MODULE_DEVICE_TABLE(of, atmci_dt_ids);
 
-static struct mci_platform_data __devinit*
+static struct mci_platform_data*
 atmci_of_init(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
diff --git a/drivers/mmc/host/au1xmmc.c b/drivers/mmc/host/au1xmmc.c
index dbd0c8a..606c16a 100644
--- a/drivers/mmc/host/au1xmmc.c
+++ b/drivers/mmc/host/au1xmmc.c
@@ -943,7 +943,7 @@ static const struct mmc_host_ops au1xmmc_ops = {
.enable_sdio_irq = au1xmmc_enable_sdio_irq,
 };
 
-static int __devinit au1xmmc_probe(struct platform_device *pdev)
+static int au1xmmc_probe(struct platform_device *pdev)
 {
struct mmc_host *mmc;
struct au1xmmc_host *host;
diff --git a/drivers/mmc/host/bfin_sdh.c b/drivers/mmc/host/bfin_sdh.c
index 156ebe7..4ef3901 100644
--- a/drivers/mmc/host/bfin_sdh.c
+++ b/drivers/mmc/host/bfin_sdh.c
@@ -522,7 +522,7 @@ static void sdh_reset(void)
SSYNC();
 }
 
-static int __devinit sdh_probe(struct platform_device *pdev)
+static int sdh_probe(struct platform_device *pdev)
 {
struct mmc_host *mmc;
struct sdh_host *host;
diff --git a/drivers/mmc/host/cb710-mmc.c b/drivers/mmc/host/cb710-mmc.c
index 39280b5..c12a561 100644
--- a/drivers/mmc/host/cb710-mmc.c
+++ b/drivers/mmc/host/cb710-mmc.c
@@ -690,7 +690,7 @@ static int cb710_mmc_resume(struct platform_device *pdev)
 
 #endif /* CONFIG_PM */
 
-static int __devinit cb710_mmc_init(struct platform_device *pdev)
+static int cb710_mmc_init(struct platform_device *pdev)
 {
struct cb710_slot *slot = cb710_pdev_to_slot(pdev);
struct cb710_chip *chip = cb710_slot_to_chip(slot);
diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
index edb37e9..324c8bf 100644
--- a/drivers/mmc/host/dw_mmc-pci.c
+++ b/drivers/mmc/host/dw_mmc-pci.c
@@ -37,7 +37,7 @@ static struct dw_mci_board pci_board_data = {
.fifo_depth = 32,
 };
 
-static int __devinit dw_mci_pci_probe(struct pci_dev *pdev,
+static int dw_mci_pci_probe(struct pci_dev *pdev,
  const struct pci_device_id *entries)
 {
struct dw_mci *host;
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index 4c1b1df..ff73a87 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -62,7 +62,7 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
 }
 EXPORT_SYMBOL_GPL(dw_mci_pltfm_register);
 
-static int __devinit dw_mci_pltfm_probe(struct platform_device *pdev)
+static int dw_mci_pltfm_probe(struct platform_device *pdev)
 {
return dw_mci_pltfm_register(pdev, NULL);
 }
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index 31cf20f..81826be 100644
--- a/drivers/mmc/host/jz4740_mmc.c
+++ b/drivers/mmc/host/jz4740_mmc.c
@@ -702,7 +7

[PATCH 077/493] mmc: remove use of __devexit_p

[Bill Pemberton]

CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.

Signed-off-by: Bill Pemberton 
Cc: Chris Ball  
Cc: "Michał Mirosław"  
Cc: Jarkko Lavinen  
Cc: Venkatraman S  
Cc: Viresh Kumar  
Cc: Guennadi Liakhovetski  
Cc: Ian Molton  
Cc: Bruce Chang  
Cc: Harald Welte  
Cc: Pierre Ossman  
Cc: uclinux-dist-de...@blackfin.uclinux.org 
Cc: linux-mmc@vger.kernel.org 
Cc: linux-o...@vger.kernel.org 
Cc: linux-arm-ker...@lists.infradead.org 
Cc: spear-de...@list.st.com 
---
 drivers/mmc/host/bfin_sdh.c| 2 +-
 drivers/mmc/host/cb710-mmc.c   | 2 +-
 drivers/mmc/host/dw_mmc-pci.c  | 2 +-
 drivers/mmc/host/dw_mmc-pltfm.c| 2 +-
 drivers/mmc/host/jz4740_mmc.c  | 2 +-
 drivers/mmc/host/mmc_spi.c | 2 +-
 drivers/mmc/host/mmci.c| 2 +-
 drivers/mmc/host/omap.c| 2 +-
 drivers/mmc/host/omap_hsmmc.c  | 2 +-
 drivers/mmc/host/s3cmci.c  | 2 +-
 drivers/mmc/host/sdhci-cns3xxx.c   | 2 +-
 drivers/mmc/host/sdhci-dove.c  | 2 +-
 drivers/mmc/host/sdhci-esdhc-imx.c | 2 +-
 drivers/mmc/host/sdhci-of-esdhc.c  | 2 +-
 drivers/mmc/host/sdhci-of-hlwd.c   | 2 +-
 drivers/mmc/host/sdhci-pci.c   | 2 +-
 drivers/mmc/host/sdhci-pxav2.c | 2 +-
 drivers/mmc/host/sdhci-pxav3.c | 2 +-
 drivers/mmc/host/sdhci-s3c.c   | 2 +-
 drivers/mmc/host/sdhci-spear.c | 2 +-
 drivers/mmc/host/sdhci-tegra.c | 2 +-
 drivers/mmc/host/sh_mobile_sdhi.c  | 2 +-
 drivers/mmc/host/tmio_mmc.c| 2 +-
 drivers/mmc/host/via-sdmmc.c   | 2 +-
 drivers/mmc/host/wbsd.c| 4 ++--
 25 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/mmc/host/bfin_sdh.c b/drivers/mmc/host/bfin_sdh.c
index b9b463e..156ebe7 100644
--- a/drivers/mmc/host/bfin_sdh.c
+++ b/drivers/mmc/host/bfin_sdh.c
@@ -680,7 +680,7 @@ static int sdh_resume(struct platform_device *dev)
 
 static struct platform_driver sdh_driver = {
.probe   = sdh_probe,
-   .remove  = __devexit_p(sdh_remove),
+   .remove  = sdh_remove,
.suspend = sdh_suspend,
.resume  = sdh_resume,
.driver  = {
diff --git a/drivers/mmc/host/cb710-mmc.c b/drivers/mmc/host/cb710-mmc.c
index 83693fd..39280b5 100644
--- a/drivers/mmc/host/cb710-mmc.c
+++ b/drivers/mmc/host/cb710-mmc.c
@@ -773,7 +773,7 @@ static int __devexit cb710_mmc_exit(struct platform_device 
*pdev)
 static struct platform_driver cb710_mmc_driver = {
.driver.name = "cb710-mmc",
.probe = cb710_mmc_init,
-   .remove = __devexit_p(cb710_mmc_exit),
+   .remove = cb710_mmc_exit,
 #ifdef CONFIG_PM
.suspend = cb710_mmc_suspend,
.resume = cb710_mmc_resume,
diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
index 53a09cb..edb37e9 100644
--- a/drivers/mmc/host/dw_mmc-pci.c
+++ b/drivers/mmc/host/dw_mmc-pci.c
@@ -134,7 +134,7 @@ static struct pci_driver dw_mci_pci_driver = {
.name   = "dw_mmc_pci",
.id_table   = dw_mci_pci_id,
.probe  = dw_mci_pci_probe,
-   .remove = __devexit_p(dw_mci_pci_remove),
+   .remove = dw_mci_pci_remove,
.driver =   {
.pm =   &dw_mci_pci_pmops
},
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index 4e13370..4c1b1df 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -120,7 +120,7 @@ MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
 
 static struct platform_driver dw_mci_pltfm_driver = {
.probe  = dw_mci_pltfm_probe,
-   .remove = __devexit_p(dw_mci_pltfm_remove),
+   .remove = dw_mci_pltfm_remove,
.driver = {
.name   = "dw_mmc",
.of_match_table = of_match_ptr(dw_mci_pltfm_match),
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index c8852a8..31cf20f 100644
--- a/drivers/mmc/host/jz4740_mmc.c
+++ b/drivers/mmc/host/jz4740_mmc.c
@@ -1004,7 +1004,7 @@ const struct dev_pm_ops jz4740_mmc_pm_ops = {
 
 static struct platform_driver jz4740_mmc_driver = {
.probe = jz4740_mmc_probe,
-   .remove = __devexit_p(jz4740_mmc_remove),
+   .remove = jz4740_mmc_remove,
.driver = {
.name = "jz4740-mmc",
.owner = THIS_MODULE,
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index a600eab..f7df798 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -1529,7 +1529,7 @@ static struct spi_driver mmc_spi_driver = {
.of_match_table = mmc_spi_of_match_table,
},
.probe =mmc_spi_probe,
-   .remove =   __devexit_p(mmc_spi_remove),
+   .remove =   mmc_spi_remove,
 };
 
 module_spi_driver(mmc_spi_driver);
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 9446c17..705c3be 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1693,7 +1693,7 @@ static struct a

[PATCH 414/493] mmc: remove use of __devexit

[Bill Pemberton]

CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.

Signed-off-by: Bill Pemberton 
Cc: Manuel Lauss  
Cc: Chris Ball  
Cc: "Michał Mirosław"  
Cc: Jarkko Lavinen  
Cc: Venkatraman S  
Cc: Viresh Kumar  
Cc: Guennadi Liakhovetski  
Cc: Ian Molton  
Cc: Bruce Chang  
Cc: Harald Welte  
Cc: Pierre Ossman  
Cc: linux-mmc@vger.kernel.org 
Cc: uclinux-dist-de...@blackfin.uclinux.org 
Cc: linux-o...@vger.kernel.org 
Cc: linux-arm-ker...@lists.infradead.org 
Cc: spear-de...@list.st.com 
---
 drivers/mmc/host/au1xmmc.c | 2 +-
 drivers/mmc/host/bfin_sdh.c| 2 +-
 drivers/mmc/host/cb710-mmc.c   | 2 +-
 drivers/mmc/host/dw_mmc-pci.c  | 2 +-
 drivers/mmc/host/dw_mmc-pltfm.c| 2 +-
 drivers/mmc/host/dw_mmc-pltfm.h| 2 +-
 drivers/mmc/host/jz4740_mmc.c  | 2 +-
 drivers/mmc/host/mmc_spi.c | 2 +-
 drivers/mmc/host/mmci.c| 4 ++--
 drivers/mmc/host/omap.c| 2 +-
 drivers/mmc/host/omap_hsmmc.c  | 2 +-
 drivers/mmc/host/s3cmci.c  | 2 +-
 drivers/mmc/host/sdhci-cns3xxx.c   | 2 +-
 drivers/mmc/host/sdhci-dove.c  | 2 +-
 drivers/mmc/host/sdhci-esdhc-imx.c | 2 +-
 drivers/mmc/host/sdhci-of-esdhc.c  | 2 +-
 drivers/mmc/host/sdhci-of-hlwd.c   | 2 +-
 drivers/mmc/host/sdhci-pci.c   | 4 ++--
 drivers/mmc/host/sdhci-pxav2.c | 2 +-
 drivers/mmc/host/sdhci-pxav3.c | 2 +-
 drivers/mmc/host/sdhci-s3c.c   | 2 +-
 drivers/mmc/host/sdhci-spear.c | 2 +-
 drivers/mmc/host/sdhci-tegra.c | 2 +-
 drivers/mmc/host/sh_mmcif.c| 2 +-
 drivers/mmc/host/tmio_mmc.c| 2 +-
 drivers/mmc/host/via-sdmmc.c   | 2 +-
 drivers/mmc/host/wbsd.c| 6 +++---
 27 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/mmc/host/au1xmmc.c b/drivers/mmc/host/au1xmmc.c
index 606c16a..127a8fa 100644
--- a/drivers/mmc/host/au1xmmc.c
+++ b/drivers/mmc/host/au1xmmc.c
@@ -1114,7 +1114,7 @@ out0:
return ret;
 }
 
-static int __devexit au1xmmc_remove(struct platform_device *pdev)
+static int au1xmmc_remove(struct platform_device *pdev)
 {
struct au1xmmc_host *host = platform_get_drvdata(pdev);
 
diff --git a/drivers/mmc/host/bfin_sdh.c b/drivers/mmc/host/bfin_sdh.c
index 4ef3901..fb4348c 100644
--- a/drivers/mmc/host/bfin_sdh.c
+++ b/drivers/mmc/host/bfin_sdh.c
@@ -617,7 +617,7 @@ out1:
return ret;
 }
 
-static int __devexit sdh_remove(struct platform_device *pdev)
+static int sdh_remove(struct platform_device *pdev)
 {
struct mmc_host *mmc = platform_get_drvdata(pdev);
 
diff --git a/drivers/mmc/host/cb710-mmc.c b/drivers/mmc/host/cb710-mmc.c
index c12a561..777ca20 100644
--- a/drivers/mmc/host/cb710-mmc.c
+++ b/drivers/mmc/host/cb710-mmc.c
@@ -746,7 +746,7 @@ err_free_mmc:
return err;
 }
 
-static int __devexit cb710_mmc_exit(struct platform_device *pdev)
+static int cb710_mmc_exit(struct platform_device *pdev)
 {
struct cb710_slot *slot = cb710_pdev_to_slot(pdev);
struct mmc_host *mmc = cb710_slot_to_mmc(slot);
diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
index 324c8bf..083fcd2 100644
--- a/drivers/mmc/host/dw_mmc-pci.c
+++ b/drivers/mmc/host/dw_mmc-pci.c
@@ -85,7 +85,7 @@ err_disable_dev:
return ret;
 }
 
-static void __devexit dw_mci_pci_remove(struct pci_dev *pdev)
+static void dw_mci_pci_remove(struct pci_dev *pdev)
 {
struct dw_mci *host = pci_get_drvdata(pdev);
 
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index ff73a87..5e1fb1d 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -67,7 +67,7 @@ static int dw_mci_pltfm_probe(struct platform_device *pdev)
return dw_mci_pltfm_register(pdev, NULL);
 }
 
-static int __devexit dw_mci_pltfm_remove(struct platform_device *pdev)
+static int dw_mci_pltfm_remove(struct platform_device *pdev)
 {
struct dw_mci *host = platform_get_drvdata(pdev);
 
diff --git a/drivers/mmc/host/dw_mmc-pltfm.h b/drivers/mmc/host/dw_mmc-pltfm.h
index 2ac37b8..68e7fd2 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.h
+++ b/drivers/mmc/host/dw_mmc-pltfm.h
@@ -14,7 +14,7 @@
 
 extern int dw_mci_pltfm_register(struct platform_device *pdev,
const struct dw_mci_drv_data *drv_data);
-extern int __devexit dw_mci_pltfm_remove(struct platform_device *pdev);
+extern int dw_mci_pltfm_remove(struct platform_device *pdev);
 extern const struct dev_pm_ops dw_mci_pltfm_pmops;
 
 #endif /* _DW_MMC_PLTFM_H_ */
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index 81826be..2391c6b 100644
--- a/drivers/mmc/host/jz4740_mmc.c
+++ b/drivers/mmc/host/jz4740_mmc.c
@@ -938,7 +938,7 @@ err_free_host:
return ret;
 }
 
-static int __devexit jz4740_mmc_remove(struct platform_device *pdev)
+static int jz4740_mmc_remove(struct platform_device *pdev)
 {
struct jz4740_mmc_host *host = platform_get_drvdata(pdev);
 
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers

Re: [PATCH v3 0/5] mmc: Add access to RPMB partition

[Krishna Konda]

On Sat, 2012-11-17 at 18:12 -0500, Chris Ball wrote:
> I've merged this to mmc-next for 3.8 now; thanks to everyone who Acked.
> 
> If you have any userspace sample code that could be added to mmc-utils
> to show how the interface can be used, feel free to send a patch.
> Thanks,
> 
> - Chris.

Thanks Chris. Currently we dont have anything mmc-utils for using this
interface.

-- 

Thanks,
Krishna Konda
---
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation
---

--
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: [GIT PULL] at91: fixes for 3.7-rc7

[Nicolas Ferre]

On 11/19/2012 05:52 PM, Olof Johansson :
> Hi Nicolas,
> 
> On Mon, Nov 19, 2012 at 8:31 AM, Nicolas Ferre  
> wrote:
>> Arnd, Olof,
>>
>> Here is another "fixes" pull request for AT91. It enables the sd/mmc driver
>> for Device Tree enabled platforms. Those patches where part of a series that
>> was split in two for reaching upstream: the MMC part is already in Linus' 
>> tree
>> and this is the arm-soc part.
>> I have placed these patches on top of the fixes that you already have for 
>> AT91.
> 
> What regressions do these fixes resolve?
> 
> It looks more like they are DT-enablement patches to me, and thus 3.8
> material, not 3.7. I'll be happy to queue them up in next/dt though.

Hi Olof,

You are right, it does not strictly fixes a regression and we were late
for including these patches which are around since end of July...
I still sent this pull-request to enable more people to use device tree
on AT91 for the upcoming release.

If you do not take it for 3.7, maybe we will have to queue these patches
on top of our AT91 pinctrl work (on Linus Walleij side), so, you do need
to queue this one for the moment...

Best regards,
-- 
Nicolas Ferre
--
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: [GIT PULL] at91: fixes for 3.7-rc7

[Olof Johansson]

Hi Nicolas,

On Mon, Nov 19, 2012 at 8:31 AM, Nicolas Ferre  wrote:
> Arnd, Olof,
>
> Here is another "fixes" pull request for AT91. It enables the sd/mmc driver
> for Device Tree enabled platforms. Those patches where part of a series that
> was split in two for reaching upstream: the MMC part is already in Linus' tree
> and this is the arm-soc part.
> I have placed these patches on top of the fixes that you already have for 
> AT91.

What regressions do these fixes resolve?

It looks more like they are DT-enablement patches to me, and thus 3.8
material, not 3.7. I'll be happy to queue them up in next/dt though.

Thanks,

-Olof
--
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

[GIT PULL] at91: fixes for 3.7-rc7

[Nicolas Ferre]

Arnd, Olof,

Here is another "fixes" pull request for AT91. It enables the sd/mmc driver
for Device Tree enabled platforms. Those patches where part of a series that
was split in two for reaching upstream: the MMC part is already in Linus' tree
and this is the arm-soc part.
I have placed these patches on top of the fixes that you already have for AT91.

The following changes since commit 641f3ce64b050961d454a0716bb6dbf528315aac:

  ARM: at91/usbh: fix overcurrent gpio setup (2012-11-16 10:46:29 +0100)

are available in the git repository at:

  git://github.com/at91linux/linux-at91.git tags/at91-fixes

for you to fetch changes up to 83ce1c55cfb639438c2516cb05f3b8ee472023e5:

  ARM: at91/dts: add nodes for atmel hsmci controllers for atmel boards 
(2012-11-19 17:02:40 +0100)


Add entries for enabling the use of sd/mmc driver on AT91.
Those entries where missing for device tree use on these
platforms.


Ludovic Desroches (3):
  ARM: at91: add clocks for DT entries
  ARM: at91/dts: add nodes for atmel hsmci controllers for atmel SOCs
  ARM: at91/dts: add nodes for atmel hsmci controllers for atmel boards

 arch/arm/boot/dts/at91sam9260.dtsi  |  9 +
 arch/arm/boot/dts/at91sam9263.dtsi  | 18 ++
 arch/arm/boot/dts/at91sam9263ek.dts | 10 ++
 arch/arm/boot/dts/at91sam9g20ek_2mmc.dts| 12 
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi |  9 +
 arch/arm/boot/dts/at91sam9g25ek.dts | 18 ++
 arch/arm/boot/dts/at91sam9g45.dtsi  | 18 ++
 arch/arm/boot/dts/at91sam9m10g45ek.dts  | 19 +++
 arch/arm/boot/dts/at91sam9n12.dtsi  |  9 +
 arch/arm/boot/dts/at91sam9n12ek.dts |  9 +
 arch/arm/boot/dts/at91sam9x5.dtsi   | 18 ++
 arch/arm/mach-at91/at91sam9260.c|  1 +
 arch/arm/mach-at91/at91sam9263.c|  2 ++
 arch/arm/mach-at91/at91sam9g45.c|  2 ++
 arch/arm/mach-at91/at91sam9n12.c|  1 +
 arch/arm/mach-at91/at91sam9x5.c |  2 ++
 16 files changed, 157 insertions(+)

-- 
Nicolas Ferre
--
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 v2 7/7] mmc: omap_hsmmc: Cleanup up bitmap definitions of Interrupt Register

[Venkatraman S]

Define the most frequently used bitmasks of the Interrupt Enable /
Interrupt Status register with consistent naming ( with _EN suffix).

Use meaningful concatenation of bitfields for INT_EN_MASK, which shows
which interrupts are enabled by default.
No functional changes.

Signed-off-by: Venkatraman S 
Acked-by: Felipe Balbi 
---
v1->v2:
 Balaji's comments to not set ERR_EN for INT_EN_MASK is now
 handled.

 drivers/mmc/host/omap_hsmmc.c | 56 ---
 1 file changed, 32 insertions(+), 24 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9de0b9e..d0a912f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -80,29 +80,17 @@
 #define CLKD_SHIFT 6
 #define DTO_MASK   0x000F
 #define DTO_SHIFT  16
-#define INT_EN_MASK0x307F0033
-#define BWR_ENABLE (1 << 4)
-#define BRR_ENABLE (1 << 5)
-#define DTO_ENABLE (1 << 20)
 #define INIT_STREAM(1 << 1)
 #define DP_SELECT  (1 << 21)
 #define DDIR   (1 << 4)
-#define DMA_EN 0x1
+#define DMAE   0x1
 #define MSBS   (1 << 5)
 #define BCE(1 << 1)
 #define FOUR_BIT   (1 << 1)
 #define HSPE   (1 << 2)
 #define DDR(1 << 19)
 #define DW8(1 << 5)
-#define CC 0x1
-#define TC 0x02
 #define OD 0x1
-#define ERR(1 << 15)
-#define CMD_TIMEOUT(1 << 16)
-#define DATA_TIMEOUT   (1 << 20)
-#define CMD_CRC(1 << 17)
-#define DATA_CRC   (1 << 21)
-#define CARD_ERR   (1 << 28)
 #define STAT_CLEAR 0x
 #define INIT_STREAM_CMD0x
 #define DUAL_VOLT_OCR_BIT  7
@@ -111,6 +99,26 @@
 #define SOFTRESET  (1 << 1)
 #define RESETDONE  (1 << 0)
 
+/* Interrupt masks for IE and ISE register */
+#define CC_EN  (1 << 0)
+#define TC_EN  (1 << 1)
+#define BWR_EN (1 << 4)
+#define BRR_EN (1 << 5)
+#define ERR_EN (1 << 15)
+#define CTO_EN (1 << 16)
+#define CCRC_EN(1 << 17)
+#define CEB_EN (1 << 18)
+#define CIE_EN (1 << 19)
+#define DTO_EN (1 << 20)
+#define DCRC_EN(1 << 21)
+#define DEB_EN (1 << 22)
+#define CERR_EN(1 << 28)
+#define BADA_EN(1 << 29)
+
+#define INT_EN_MASK(BADA_EN | CERR_EN | DEB_EN | DCRC_EN |\
+   DTO_EN | CIE_EN | CEB_EN | CCRC_EN | CTO_EN | \
+   BRR_EN | BWR_EN | TC_EN | CC_EN)
+
 #define MMC_AUTOSUSPEND_DELAY  100
 #define MMC_TIMEOUT_MS 20
 #define OMAP_MMC_MIN_CLOCK 40
@@ -458,13 +466,13 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host 
*host,
unsigned int irq_mask;
 
if (host->use_dma)
-   irq_mask = INT_EN_MASK & ~(BRR_ENABLE | BWR_ENABLE);
+   irq_mask = INT_EN_MASK & ~(BRR_EN | BWR_EN);
else
irq_mask = INT_EN_MASK;
 
/* Disable timeout for erases */
if (cmd->opcode == MMC_ERASE)
-   irq_mask &= ~DTO_ENABLE;
+   irq_mask &= ~DTO_EN;
 
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
@@ -702,8 +710,8 @@ static void send_init_stream(struct omap_hsmmc_host *host)
OMAP_HSMMC_WRITE(host->base, CMD, INIT_STREAM_CMD);
 
timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
-   while ((reg != CC) && time_before(jiffies, timeout))
-   reg = OMAP_HSMMC_READ(host->base, STAT) & CC;
+   while ((reg != CC_EN) && time_before(jiffies, timeout))
+   reg = OMAP_HSMMC_READ(host->base, STAT) & CC_EN;
 
OMAP_HSMMC_WRITE(host->base, CON,
OMAP_HSMMC_READ(host->base, CON) & ~INIT_STREAM);
@@ -794,7 +802,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host, 
struct mmc_command *cmd,
}
 
if (host->use_dma)
-   cmdreg |= DMA_EN;
+   cmdreg |= DMAE;
 
host->req_in_progress = 1;
 
@@ -1018,14 +1026,14 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
*host, int status)
data = host->data;
dev_vdbg(mmc_dev(host->mmc), "IRQ Status is %x\n", status);
 
-   if (status & ERR) {
+   if (status & ERR_EN) {
omap_hsmmc_dbg_report_irq(host, status);
 
-   if (status & (CMD_TIMEOUT | CMD_CRC))
+   if (status & (CTO_EN | CCRC_EN))
end_cmd = 1;
-   if (status & (CMD_TIMEOUT | DATA_TIMEOUT))
+   if (status & (CTO_EN | DTO_EN))
 

[PATCH 6/7] mmc: omap_hsmmc: convert critical failure reports to dev_err

[Venkatraman S]

Fatal errors for the driver are not reported when just error
debug is enabled. Convert selected dev_dbg to dev_err for
accurate error reporting.

Reported-by: Benoit Cousson 
Signed-off-by: Venkatraman S 
---
 drivers/mmc/host/omap_hsmmc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fad9250..9de0b9e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -305,7 +305,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
 
reg = regulator_get(host->dev, "vmmc");
if (IS_ERR(reg)) {
-   dev_dbg(host->dev, "vmmc regulator missing\n");
+   dev_err(host->dev, "vmmc regulator missing\n");
return PTR_ERR(reg);
} else {
mmc_slot(host).set_power = omap_hsmmc_set_power;
@@ -1133,7 +1133,7 @@ static int omap_hsmmc_switch_opcond(struct 
omap_hsmmc_host *host, int vdd)
 
return 0;
 err:
-   dev_dbg(mmc_dev(host->mmc), "Unable to switch operating voltage\n");
+   dev_err(mmc_dev(host->mmc), "Unable to switch operating voltage\n");
return ret;
 }
 
@@ -1392,7 +1392,7 @@ omap_hsmmc_prepare_data(struct omap_hsmmc_host *host, 
struct mmc_request *req)
if (host->use_dma) {
ret = omap_hsmmc_start_dma_transfer(host, req);
if (ret != 0) {
-   dev_dbg(mmc_dev(host->mmc), "MMC start dma failure\n");
+   dev_err(mmc_dev(host->mmc), "MMC start dma failure\n");
return ret;
}
}
@@ -1927,13 +1927,13 @@ static int __devinit omap_hsmmc_probe(struct 
platform_device *pdev)
ret = request_irq(host->irq, omap_hsmmc_irq, 0,
mmc_hostname(mmc), host);
if (ret) {
-   dev_dbg(mmc_dev(host->mmc), "Unable to grab HSMMC IRQ\n");
+   dev_err(mmc_dev(host->mmc), "Unable to grab HSMMC IRQ\n");
goto err_irq;
}
 
if (pdata->init != NULL) {
if (pdata->init(&pdev->dev) != 0) {
-   dev_dbg(mmc_dev(host->mmc),
+   dev_err(mmc_dev(host->mmc),
"Unable to configure MMC IRQs\n");
goto err_irq_cd_init;
}
@@ -1956,7 +1956,7 @@ static int __devinit omap_hsmmc_probe(struct 
platform_device *pdev)
   IRQF_TRIGGER_RISING | 
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
   mmc_hostname(mmc), host);
if (ret) {
-   dev_dbg(mmc_dev(host->mmc),
+   dev_err(mmc_dev(host->mmc),
"Unable to grab MMC CD IRQ\n");
goto err_irq_cd;
}
-- 
1.8.0

--
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 5/7] mmc: omap_hsmmc: introduce omap_hsmmc_prepare/complete

[Venkatraman S]

From: Felipe Balbi 

prepare() is supposed to prevent new children from
being registered. On the MMC subsystem, children
(new cards) registration starts with the card
detect IRQ.

Move card detect IRQ disabling to prepare() so that
no new cards will be registered while we're trying
to suspend.

Likewise, move card detect IRQ enabling to complete()
so we only try to register new children after our MMC
IP is back up.

Signed-off-by: Felipe Balbi 
Signed-off-by: Venkatraman S 
---
 drivers/mmc/host/omap_hsmmc.c | 44 +++
 1 file changed, 24 insertions(+), 20 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 18d3f19..fad9250 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2070,6 +2070,25 @@ static int __devexit omap_hsmmc_remove(struct 
platform_device *pdev)
 }
 
 #ifdef CONFIG_PM
+static int omap_hsmmc_prepare(struct device *dev)
+{
+   struct omap_hsmmc_host *host = dev_get_drvdata(dev);
+
+   if (host->pdata->suspend)
+   return host->pdata->suspend(dev, host->slot_id);
+
+   return 0;
+}
+
+static void omap_hsmmc_complete(struct device *dev)
+{
+   struct omap_hsmmc_host *host = dev_get_drvdata(dev);
+
+   if (host->pdata->resume)
+   host->pdata->resume(dev, host->slot_id);
+
+}
+
 static int omap_hsmmc_suspend(struct device *dev)
 {
int ret = 0;
@@ -2083,23 +2102,10 @@ static int omap_hsmmc_suspend(struct device *dev)
 
pm_runtime_get_sync(host->dev);
host->suspended = 1;
-   if (host->pdata->suspend) {
-   ret = host->pdata->suspend(dev, host->slot_id);
-   if (ret) {
-   dev_dbg(dev, "Unable to handle MMC board"
-   " level suspend\n");
-   host->suspended = 0;
-   return ret;
-   }
-   }
ret = mmc_suspend_host(host->mmc);
 
if (ret) {
host->suspended = 0;
-   if (host->pdata->resume) {
-   if (host->pdata->resume(dev, host->slot_id))
-   dev_dbg(dev, "Unmask interrupt failed\n");
-   }
goto err;
}
 
@@ -2136,12 +2142,6 @@ static int omap_hsmmc_resume(struct device *dev)
if (!(host->mmc->pm_flags & MMC_PM_KEEP_POWER))
omap_hsmmc_conf_bus_power(host);
 
-   if (host->pdata->resume) {
-   ret = host->pdata->resume(dev, host->slot_id);
-   if (ret)
-   dev_dbg(dev, "Unmask interrupt failed\n");
-   }
-
omap_hsmmc_protect_card(host);
 
/* Notify the core to resume the host */
@@ -2157,8 +2157,10 @@ static int omap_hsmmc_resume(struct device *dev)
 }
 
 #else
+#define omap_hsmmc_prepare NULL
+#define omap_hsmmc_completeNULL
 #define omap_hsmmc_suspend NULL
-#define omap_hsmmc_resume  NULL
+#define omap_hsmmc_resume  NULL
 #endif
 
 static int omap_hsmmc_runtime_suspend(struct device *dev)
@@ -2186,6 +2188,8 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
 static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.suspend= omap_hsmmc_suspend,
.resume = omap_hsmmc_resume,
+   .prepare= omap_hsmmc_prepare,
+   .complete   = omap_hsmmc_complete,
.runtime_suspend = omap_hsmmc_runtime_suspend,
.runtime_resume = omap_hsmmc_runtime_resume,
 };
-- 
1.8.0

--
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 4/7] mmc: omap_hsmmc: Enable HSPE bit for high speed cards

[Venkatraman S]

From: "Hebbar, Gururaja" 

HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.

>From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)

The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.

There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
  capabilities register and
- MMC/SD clock coming out of controller > 25MHz

Signed-off-by: Hebbar, Gururaja 
Signed-off-by: Venkatraman S 
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |  1 +
 arch/arm/plat-omap/include/plat/mmc.h  |  1 +
 drivers/mmc/host/omap_hsmmc.c  | 30 +-
 3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
 "supply-name" examples are "vmmc", "vmmc_aux" etc
 ti,non-removable: non-removable slot (like eMMC)
 ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High 
Speed
 
 Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h 
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
 #define HSMMC_HAS_PBIAS(1 << 0)
 #define HSMMC_HAS_UPDATED_RESET(1 << 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 << 2)
unsigned features;
 
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 571cd80..18d3f19 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -63,6 +63,7 @@
 
 #define VS18   (1 << 26)
 #define VS30   (1 << 25)
+#define HSS(1 << 21)
 #define SDVS18 (0x5 << 9)
 #define SDVS30 (0x6 << 9)
 #define SDVS33 (0x7 << 9)
@@ -90,6 +91,7 @@
 #define MSBS   (1 << 5)
 #define BCE(1 << 1)
 #define FOUR_BIT   (1 << 1)
+#define HSPE   (1 << 2)
 #define DDR(1 << 19)
 #define DW8(1 << 5)
 #define CC 0x1
@@ -495,6 +497,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
*host)
struct mmc_ios *ios = &host->mmc->ios;
unsigned long regval;
unsigned long timeout;
+   unsigned long clkdiv;
 
dev_vdbg(mmc_dev(host->mmc), "Set clock to %uHz\n", ios->clock);
 
@@ -502,7 +505,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
*host)
 
regval = OMAP_HSMMC_READ(host->base, SYSCTL);
regval = regval & ~(CLKD_MASK | DTO_MASK);
-   regval = regval | (calc_divisor(host, ios) << 6) | (DTO << 16);
+   clkdiv = calc_divisor(host, ios);
+   regval = regval | (clkdiv << 6) | (DTO << 16);
OMAP_HSMMC_WRITE(host->base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host->base, SYSCTL,
OMAP_HSMMC_READ(host->base, SYSCTL) | ICE);
@@ -513,6 +517,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
*host)
&& time_before(jiffies, timeout))
cpu_relax();
 
+   /*
+* Enable High-Speed Support
+* Pre-Requisites
+*  - Controller should support High-Speed-Enable Bit
+*  - Controller should not be using DDR Mode
+*  - Controller should advertise that it supports High Speed
+*in capabilities register
+*  - MMC/SD clock coming out of controller > 25MHz
+*/
+   if ((mmc_slot(host).features & HSMMC_HAS_HSPE_SUPPORT) &&
+   (ios->timing != MMC_TIMING_UHS_DDR50) &&
+   ((OMAP_HSMMC_READ(host->base, CAPA) & HSS) == HSS)) {
+   regval = OMAP_HSMMC_READ(host->base, HCTL);
+   if (clkdiv && (clk_get_rate(host->fclk)/clkdiv) > 2500)
+   regval |= HSPE;
+   else
+   regval &= ~HSPE;
+
+   OMAP_HSMMC_WRITE(host->base, HCTL, regval);
+   }
+
omap_hsmmc

[PATCH 3/7] mmc: omap_hsmmc: update error code for response_busy cmd

[Venkatraman S]

From: Balaji T K 

update error code to cmd->error for commands with response_busy and no data

Signed-off-by: Balaji T K 
Reviewed-by: Felipe Balbi 
Signed-off-by: Venkatraman S 
---
 drivers/mmc/host/omap_hsmmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2d90da8..571cd80 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -981,8 +981,8 @@ static void hsmmc_command_incomplete(struct omap_hsmmc_host 
*host,
if (host->data) {
omap_hsmmc_reset_controller_fsm(host, SRD);
omap_hsmmc_dma_cleanup(host, err);
-   }
-
+   } else if (host->mrq && host->mrq->cmd)
+   host->mrq->cmd->error = err;
 }
 
 static void omap_hsmmc_do_irq(struct omap_hsmmc_host *host, int status)
-- 
1.8.0

--
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 2/7] mmc: omap_hsmmc: no reset of cmd state machine for DCRC

[Venkatraman S]

From: Balaji T K 

Avoid soft reset of command internal state machine on data errors.

Signed-off-by: Balaji T K 
Reviewed-by: Felipe Balbi 
Signed-off-by: Venkatraman S 
---
 drivers/mmc/host/omap_hsmmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0fcf792..2d90da8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -972,8 +972,8 @@ static inline void omap_hsmmc_reset_controller_fsm(struct 
omap_hsmmc_host *host,
 static void hsmmc_command_incomplete(struct omap_hsmmc_host *host,
int err, int end_cmd)
 {
-   omap_hsmmc_reset_controller_fsm(host, SRC);
if (end_cmd) {
+   omap_hsmmc_reset_controller_fsm(host, SRC);
if (host->cmd)
host->cmd->error = err;
}
-- 
1.8.0

--
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 1/7] mmc: omap_hsmmc: Fix Oops in case of data errors

[Venkatraman S]

From: Balaji T K 

"commit ae4bf788ee9bf7c2d51b0309117d1fcccbdd50a2
mmc: omap_hsmmc: consolidate error report handling of HSMMC IRQ"
sets both end_cmd and end_trans to 1.

Setting end_cmd to 1 for Data Timeout/CRC leads to NULL pointer dereference of
host->cmd as the command complete has previously been handled.
Set end_cmd only in case of command Timeout/CRC.

Moreover host->cmd->error should not be updated on data error case, only
host->data->error needs to be updated.

Signed-off-by: Balaji T K 
Reviewed-by: Felipe Balbi 
Signed-off-by: Venkatraman S 
---
 drivers/mmc/host/omap_hsmmc.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5434fd8..0fcf792 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -969,10 +969,14 @@ static inline void omap_hsmmc_reset_controller_fsm(struct 
omap_hsmmc_host *host,
__func__);
 }
 
-static void hsmmc_command_incomplete(struct omap_hsmmc_host *host, int err)
+static void hsmmc_command_incomplete(struct omap_hsmmc_host *host,
+   int err, int end_cmd)
 {
omap_hsmmc_reset_controller_fsm(host, SRC);
-   host->cmd->error = err;
+   if (end_cmd) {
+   if (host->cmd)
+   host->cmd->error = err;
+   }
 
if (host->data) {
omap_hsmmc_reset_controller_fsm(host, SRD);
@@ -991,14 +995,16 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
*host, int status)
 
if (status & ERR) {
omap_hsmmc_dbg_report_irq(host, status);
+
+   if (status & (CMD_TIMEOUT | CMD_CRC))
+   end_cmd = 1;
if (status & (CMD_TIMEOUT | DATA_TIMEOUT))
-   hsmmc_command_incomplete(host, -ETIMEDOUT);
+   hsmmc_command_incomplete(host, -ETIMEDOUT, end_cmd);
else if (status & (CMD_CRC | DATA_CRC))
-   hsmmc_command_incomplete(host, -EILSEQ);
+   hsmmc_command_incomplete(host, -EILSEQ, end_cmd);
 
-   end_cmd = 1;
if (host->data || host->response_busy) {
-   end_trans = 1;
+   end_trans = !end_cmd;
host->response_busy = 0;
}
}
-- 
1.8.0

--
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 0/5] mmc: omap_hsmmc: Few patches for omap_hsmmc

[Venkatraman S]

On Sun, Nov 18, 2012 at 6:39 AM, Chris Ball  wrote:
> Hi Venkat,
>
> On Tue, Nov 06 2012, Venkatraman S wrote:
>> Hi Chris,
>>   Please review and merge the below patches.
>> The first one is a bug fix that would be required to be sent
>> for 3.7-rcX, others are intended for 3.8.
>
> There have been some changes requested to these -- could you resend your
> 3.8 queue to me, please?
>

Yes - I am sending you now a series of 7 patches that has updated /
cleaned up revisions of
the previous patches. Also, it includes Balaji's mini bug fix series,
which is a better version of
my own fix.

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 v1] mmc: fix async request mechanism for sequential read scenarios

[Per Förlin]

On 11/19/2012 10:48 AM, Konstantin Dorfman wrote:
> Hello Per,
> 
> Thank you for giving me an example, below I'm trying to explain some
> logic issues of it and asking you some questions about your vision of
> the patch.
> 
> On 11/15/2012 06:38 PM, Per Förlin wrote:
>> On 11/14/2012 04:15 PM, Konstantin Dorfman wrote:
>>> Hello Per,
>>>
>>> On 11/13/2012 11:10 PM, Per Forlin wrote:
 On Tue, Oct 30, 2012 at 1:19 PM, Konstantin Dorfman
  wrote:
> Hello,
>
> On 10/29/2012 11:40 PM, Per Forlin wrote:
>> Hi,
>>
>> I would like to move the focus of my concerns from root cause analysis
>> to the actual patch,
>> My first reflection is that the patch is relatively complex and some
>> of the code looks duplicated.
>> Would it be possible to simplify it and re-use  the current execution 
>> flow.
>>
>> Is the following flow feasible?
>>
>> in mmc_start_req():
>> --
>> if (rqc == NULL && not_resend)
>>   wait_for_both_mmc_and_arrival_of_new_req
>> else
>>   wait_only_for_mmc
>>
>> if (arrival_of_new_req) {
>>set flag to indicate fetch-new_req
>>   return NULL;
>> }
>> -
>>
>> in queue.c:
>> if (fetch-new_req)
>>   don't overwrite previous req.
>>
>> BR
>> Per
>
> You are talking about using both waiting mechanisms, old (wait on
> completion) and new - wait_event_interruptible()? But how done()
> callback, called on host controller irq context, will differentiate
> which one is relevant for the request?
>
> I think it is better to use single wait point for mmc thread.

 I have sketch a patch to better explain my point. It's not tested it
 barely compiles :)
 The patch tries to introduce your feature and still keep the same code
 path. And it exposes an API that could be used by SDIO as well.
 The intention of my sketch patch is only to explain what I tried to
 visualize in the pseudo code previously in this thread.
 The out come of your final patch should be documented here I think:
 Documentation/mmc/mmc-async-req.txt
>>> This document is ready, attaching it to this mail and will be included
>>> in next version of the patch (or RESEND).

 Here follows my patch sketch:
 
 diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
 index e360a97..08036a1 100644
 --- a/drivers/mmc/card/queue.c
 +++ b/drivers/mmc/card/queue.c
 @@ -66,6 +66,8 @@ static int mmc_queue_thread(void *d)
   spin_unlock_irq(q->queue_lock);

   if (req || mq->mqrq_prev->req) {
 + if (!req)
 + 
 mmc_prefetch_start(&mq->mqrq_prev->mmc_active, true);
   set_current_state(TASK_RUNNING);
   mq->issue_fn(mq, req);
   } else {
 @@ -79,11 +81,13 @@ static int mmc_queue_thread(void *d)
   }

   /* Current request becomes previous request and vice versa. 
 */
 - mq->mqrq_prev->brq.mrq.data = NULL;
 - mq->mqrq_prev->req = NULL;
 - tmp = mq->mqrq_prev;
 - mq->mqrq_prev = mq->mqrq_cur;
 - mq->mqrq_cur = tmp;
 + if (!mmc_prefetch_pending(&mq->mqrq_prev->mmc_active)) {
 + mq->mqrq_prev->brq.mrq.data = NULL;
 + mq->mqrq_prev->req = NULL;
 + tmp = mq->mqrq_prev;
 + mq->mqrq_prev = mq->mqrq_cur;
 + mq->mqrq_cur = tmp;
 + }
   } while (1);
   up(&mq->thread_sem);

 @@ -109,10 +113,44 @@ static void mmc_request_fn(struct request_queue *q)
   return;
   }

 + if (mq->prefetch_enable) {
 + spin_lock(&mq->prefetch_lock);
 + if (mq->prefetch_completion)
 + complete(mq->prefetch_completion);
> Since mq->prefetch_completion init happens only in core.c after
> mmc_start_req(NULL), we can miss all new request notifications coming
> from fetching NULL request until then.
It's a mistake in the patch.
I meant check mq->prefetch_pending to know whether we need to wait in the first 
place.
That's why mq->prefetch_pending is assigned even if mq->prefetch_completion is 
not set yet.
Patch needs to be updated to take it into account. One could let 
mmc_prefecth_init() return and indicate if there is already a NEW_REQ pending. 
If this is the case skip wait.


 + mq->prefetch_pending = true;
 + spin_unlock(&mq->prefetch_lock);
 + }
 +
   if (!mq->mqrq_cur->req && !mq->mqrq_prev->req)
   wake_up_process(mq->thread);
  }

 +static void mmc

Re: [PATCH] mmc: dw_mmc: enable controller interrupt before calling mmc_start_host

[James Hogan]

On 19/11/12 13:01, Yuvaraj CD wrote:
> As mmc_start_host is getting called before enabling the dw_mmc controller
> interrupt, there is a problem of missing the SDMMC_INT_CMD_DONE for the
> very first command sent by the sdio_reset.
> This problem occurs only when we disable MMC debugging i.e, MMC_DEBUG [=n].
> Hence this patch enables the dw_mmc controller interrupt before 
> mmc_start_host.
> 
> Signed-off-by: Yuvaraj CD 

Hi Yuvaraj,

I get the following errors after this patch is applied
(2da1d7f2948900cd50d38643db39f790edb3cc96, merged in v3.7-rc5) and the
driver doesn't work as a result. Reverting it fixes the problem.

mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 30Hz, actual 
298922HZ div = 167)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 20Hz, actual 
199680HZ div = 250)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 195765Hz, actual 
195764HZ div = 255)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 40Hz, actual 
399360HZ div = 125)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 30Hz, actual 
298922HZ div = 167)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 20Hz, actual 
199680HZ div = 250)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 9984Hz (slot req 195765Hz, actual 
195764HZ div = 255)
mmc0: error -110 whilst initialising SD card

The interrupts are already cleared and disabled at the beginning of the
probe function, so is the following sufficient (after reverting your
patch) to fix the problem you've been observing?

Thanks
James

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index ec9b5a8..2be9899 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2266,7 +2266,6 @@ int dw_mci_probe(struct dw_mci *host)
 * Enable interrupts for command done, data over, data empty, card det,
 * receive ready and error such as transmit, receive timeout, crc error
 */
-   mci_writel(host, RINTSTS, 0x);
mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
   SDMMC_INT_TXDR | SDMMC_INT_RXDR |
   DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);


> ---
>  drivers/mmc/host/dw_mmc.c |   29 +++--
>  1 file changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index a23af77..729c031 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2233,6 +2233,21 @@ int dw_mci_probe(struct dw_mci *host)
> else
> host->num_slots = ((mci_readl(host, HCON) >> 1) & 0x1F) + 1;
> 
> +   /*
> +* Enable interrupts for command done, data over, data empty, card 
> det,
> +* receive ready and error such as transmit, receive timeout, crc 
> error
> +*/
> +   mci_writel(host, RINTSTS, 0x);
> +   mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
> +  SDMMC_INT_TXDR | SDMMC_INT_RXDR |
> +  DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
> +   mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci
> interrupt */
> +
> +   dev_info(host->dev, "DW MMC controller at irq %d, "
> +"%d bit host data width, "
> +"%u deep fifo\n",
> +host->irq, width, fifo_size);
> +
> /* We need at least one slot to succeed */
> for (i = 0; i < host->num_slots; i++) {
> ret = dw_mci_init_slot(host, i);
> @@ -2262,20 +2277,6 @@ int dw_mci_probe(struct dw_mci *host)
> else
> host->data_offset = DATA_240A_OFFSET;
> 
> -   /*
> -* Enable interrupts for command done, data over, data empty, card 
> det,
> -* receive ready and error such as transmit, receive timeout, crc 
> error
> -*/
> -   mci_writel(host, RINTSTS, 0x);
> -   mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
> -  SDMMC_INT_TXDR | SDMMC_INT_RXDR |
> -  DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
> -   mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci
> interrupt */
> -
> -   dev_info(host->dev, "DW MMC controller at irq %d, "
> -"%d bit host data width, "
> -"%u deep fifo\n",
> -host->irq, width, fifo_size);
> if (host->quirks & DW_MCI_QUIRK_IDMAC_DTO)
> dev_info(host->dev, "Internal DMAC interrupt fix enabled.\n");
> 
> --
> 1.7.9.5
> 
> --
> 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  h

Re: [PATCH v3 4/4] mmc: dw-mmc: remove complier warning

[James Hogan]

On 19/11/12 12:23, James Hogan wrote:
> On 08/11/12 08:35, Jaehoon Chung wrote:
>> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_prepare_command':
>> drivers/mmc/host/dw_mmc.c:256:37: warning: initialization discards 'const' 
>> qualifier from pointer target type [enabled by default]
>> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_set_ios':
>> drivers/mmc/host/dw_mmc.c:805:37: warning: initialization discards 'const' 
>> qualifier from pointer target type [enabled by default]
>> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_init_slot':
>> drivers/mmc/host/dw_mmc.c:1849:37: warning: initialization discards 'const' 
>> qualifier from pointer target type [enabled by default]
>> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_parse_dt':
>> drivers/mmc/host/dw_mmc.c:2049:37: warning: initialization discards 'const' 
>> qualifier from pointer target type [enabled by default]
>> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_probe':
>> drivers/mmc/host/dw_mmc.c:2095:37: warning: initialization discards 'const' 
>> qualifier from pointer target type [enabled by default]
>>
>> Signed-off-by: Jaehoon Chung 
> 
> Acked-by: James Hogan 

Chris: Is it okay to get this patch into v3.7?

Thanks
James

--
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 4/4] mmc: dw-mmc: remove complier warning

[James Hogan]

On 08/11/12 08:35, Jaehoon Chung wrote:
> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_prepare_command':
> drivers/mmc/host/dw_mmc.c:256:37: warning: initialization discards 'const' 
> qualifier from pointer target type [enabled by default]
> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_set_ios':
> drivers/mmc/host/dw_mmc.c:805:37: warning: initialization discards 'const' 
> qualifier from pointer target type [enabled by default]
> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_init_slot':
> drivers/mmc/host/dw_mmc.c:1849:37: warning: initialization discards 'const' 
> qualifier from pointer target type [enabled by default]
> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_parse_dt':
> drivers/mmc/host/dw_mmc.c:2049:37: warning: initialization discards 'const' 
> qualifier from pointer target type [enabled by default]
> drivers/mmc/host/dw_mmc.c: In function 'dw_mci_probe':
> drivers/mmc/host/dw_mmc.c:2095:37: warning: initialization discards 'const' 
> qualifier from pointer target type [enabled by default]
> 
> Signed-off-by: Jaehoon Chung 

Acked-by: James Hogan 

Thanks
James

--
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: Standardise capability type

[Lee Jones]

On Mon, 19 Nov 2012, Chris Ball wrote:

> Hi,
> 
> On Mon, Nov 19 2012, Lee Jones wrote:
> >> > There are discrepancies with regards to how MMC capabilities
> >> > are carried throughout the subsystem. Let's standardise them
> >> > to elevate any confusion.
> >> 
> >> I think you meant "eliminate" here.  :)  Thanks,
> >
> > No, I meant alleviate. :)
> >
> > Do you want me to re-submit, or have you fixed up?
> 
> I already pushed with a change to "eliminate" -- I'll leave it like
> that if that's okay.

No problem.

Thanks Chris.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 1/1] mmc: sdhci-dove: remove duplicate inclusion of linux/err.h

[Sachin Kamat]

linux/err.h was included twice.

Signed-off-by: Sachin Kamat 
---
 drivers/mmc/host/sdhci-dove.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/sdhci-dove.c b/drivers/mmc/host/sdhci-dove.c
index 8fd50a2..2a03f30 100644
--- a/drivers/mmc/host/sdhci-dove.c
+++ b/drivers/mmc/host/sdhci-dove.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
1.7.4.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: Standardise capability type

[Chris Ball]

Hi,

On Mon, Nov 19 2012, Lee Jones wrote:
>> > There are discrepancies with regards to how MMC capabilities
>> > are carried throughout the subsystem. Let's standardise them
>> > to elevate any confusion.
>> 
>> I think you meant "eliminate" here.  :)  Thanks,
>
> No, I meant alleviate. :)
>
> Do you want me to re-submit, or have you fixed up?

I already pushed with a change to "eliminate" -- I'll leave it like
that if that's okay.

Thanks,

- Chris.
-- 
Chris Ball  
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 v6 12/14] mmc: sdhci-pxav3: remove set_uhs_signaling function

[Kevin Liu]

2012/11/18 Chris Ball :
> Hi,
>
> On Wed, Oct 17 2012, Kevin Liu wrote:
>> From: Kevin Liu 
>>
>> Because sdhci can do the same thing so no need to implement this.
>>
>> Acked-by:  Zhangfei Gao 
>> Signed-off-by: Kevin Liu 
>
> In that case, we can remove the callbacks from sdhci.c/sdhci.h too --
> sdhci-pxav3 was the only user.
>
updated the patch in v8. thanks!

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 v3 0/5] mmc: Add access to RPMB partition

[Linus Walleij]

On Sun, Nov 18, 2012 at 12:12 AM, Chris Ball  wrote:

> I've merged this to mmc-next for 3.8 now; thanks to everyone who Acked.

Thanks Chris :-)

> If you have any userspace sample code that could be added to mmc-utils
> to show how the interface can be used, feel free to send a patch.

Loïc, Johan: do you have an RPMB example at hand, or could you
cook some nice patch for mmc-utils?

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: [PATCH v1] mmc: fix async request mechanism for sequential read scenarios

[Konstantin Dorfman]

Hello Per,

Thank you for giving me an example, below I'm trying to explain some
logic issues of it and asking you some questions about your vision of
the patch.

On 11/15/2012 06:38 PM, Per Förlin wrote:
> On 11/14/2012 04:15 PM, Konstantin Dorfman wrote:
>> Hello Per,
>>
>> On 11/13/2012 11:10 PM, Per Forlin wrote:
>>> On Tue, Oct 30, 2012 at 1:19 PM, Konstantin Dorfman
>>>  wrote:
 Hello,

 On 10/29/2012 11:40 PM, Per Forlin wrote:
> Hi,
>
> I would like to move the focus of my concerns from root cause analysis
> to the actual patch,
> My first reflection is that the patch is relatively complex and some
> of the code looks duplicated.
> Would it be possible to simplify it and re-use  the current execution 
> flow.
>
> Is the following flow feasible?
>
> in mmc_start_req():
> --
> if (rqc == NULL && not_resend)
>   wait_for_both_mmc_and_arrival_of_new_req
> else
>   wait_only_for_mmc
>
> if (arrival_of_new_req) {
>set flag to indicate fetch-new_req
>   return NULL;
> }
> -
>
> in queue.c:
> if (fetch-new_req)
>   don't overwrite previous req.
>
> BR
> Per

 You are talking about using both waiting mechanisms, old (wait on
 completion) and new - wait_event_interruptible()? But how done()
 callback, called on host controller irq context, will differentiate
 which one is relevant for the request?

 I think it is better to use single wait point for mmc thread.
>>>
>>> I have sketch a patch to better explain my point. It's not tested it
>>> barely compiles :)
>>> The patch tries to introduce your feature and still keep the same code
>>> path. And it exposes an API that could be used by SDIO as well.
>>> The intention of my sketch patch is only to explain what I tried to
>>> visualize in the pseudo code previously in this thread.
>>> The out come of your final patch should be documented here I think:
>>> Documentation/mmc/mmc-async-req.txt
>> This document is ready, attaching it to this mail and will be included
>> in next version of the patch (or RESEND).
>>>
>>> Here follows my patch sketch:
>>> 
>>> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
>>> index e360a97..08036a1 100644
>>> --- a/drivers/mmc/card/queue.c
>>> +++ b/drivers/mmc/card/queue.c
>>> @@ -66,6 +66,8 @@ static int mmc_queue_thread(void *d)
>>>   spin_unlock_irq(q->queue_lock);
>>>
>>>   if (req || mq->mqrq_prev->req) {
>>> + if (!req)
>>> + 
>>> mmc_prefetch_start(&mq->mqrq_prev->mmc_active, true);
>>>   set_current_state(TASK_RUNNING);
>>>   mq->issue_fn(mq, req);
>>>   } else {
>>> @@ -79,11 +81,13 @@ static int mmc_queue_thread(void *d)
>>>   }
>>>
>>>   /* Current request becomes previous request and vice versa. */
>>> - mq->mqrq_prev->brq.mrq.data = NULL;
>>> - mq->mqrq_prev->req = NULL;
>>> - tmp = mq->mqrq_prev;
>>> - mq->mqrq_prev = mq->mqrq_cur;
>>> - mq->mqrq_cur = tmp;
>>> + if (!mmc_prefetch_pending(&mq->mqrq_prev->mmc_active)) {
>>> + mq->mqrq_prev->brq.mrq.data = NULL;
>>> + mq->mqrq_prev->req = NULL;
>>> + tmp = mq->mqrq_prev;
>>> + mq->mqrq_prev = mq->mqrq_cur;
>>> + mq->mqrq_cur = tmp;
>>> + }
>>>   } while (1);
>>>   up(&mq->thread_sem);
>>>
>>> @@ -109,10 +113,44 @@ static void mmc_request_fn(struct request_queue *q)
>>>   return;
>>>   }
>>>
>>> + if (mq->prefetch_enable) {
>>> + spin_lock(&mq->prefetch_lock);
>>> + if (mq->prefetch_completion)
>>> + complete(mq->prefetch_completion);
Since mq->prefetch_completion init happens only in core.c after
mmc_start_req(NULL), we can miss all new request notifications coming
from fetching NULL request until then.
>>> + mq->prefetch_pending = true;
>>> + spin_unlock(&mq->prefetch_lock);
>>> + }
>>> +
>>>   if (!mq->mqrq_cur->req && !mq->mqrq_prev->req)
>>>   wake_up_process(mq->thread);
>>>  }
>>>
>>> +static void mmc_req_init(struct mmc_async_req *areq, struct completion 
>>> *compl)
>>> +{
>>> + struct mmc_queue *mq =
>>> + container_of(areq->prefetch, struct mmc_queue, prefetch);
>>> +
>>> + spin_lock(&mq->prefetch_lock);
>>> + mq->prefetch_completion = compl;
>>> + if (mq->prefetch_pending)
>>> + complete(mq->prefetch_completion);
>>> + spin_unlock(&mq->prefetch_lock);
>>> +}
>>> +
>>> +static void mmc_req_start(struct mmc_async_req *areq, bool enable)
>>> +{
>>> + struct mmc_queue *mq =
>>> + container_of(areq->prefet

Re: [PATCH] mmc: Standardise capability type

[Lee Jones]

On Sat, 17 Nov 2012, Chris Ball wrote:

> Hi Lee, 
> 
> Pushed to mmc-next for 3.8 with a minor change:
> 
> On Wed, Nov 14 2012, Lee Jones wrote:
> > There are discrepancies with regards to how MMC capabilities
> > are carried throughout the subsystem. Let's standardise them
> > to elevate any confusion.
> 
> I think you meant "eliminate" here.  :)  Thanks,

No, I meant alleviate. :)

Do you want me to re-submit, or have you fixed up?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v6 11/14] mmc: sdhci: fix the bug that DDR50 can't work for emmc

[Kevin Liu]

2012/11/19 Kevin Liu :
> 2012/11/18 Chris Ball :
>> Hi,
>>
>> On Wed, Oct 17 2012, Kevin Liu wrote:
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index c3e786d..522e501 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -1529,8 +1529,15 @@ static void sdhci_do_set_ios(struct sdhci_host 
>>> *host, struct mmc_ios *ios)
>>>   ctrl_2 |= SDHCI_CTRL_UHS_SDR50;
>>>   else if (ios->timing == MMC_TIMING_UHS_SDR104)
>>>   ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
>>> - else if (ios->timing == MMC_TIMING_UHS_DDR50)
>>> + else if (ios->timing == MMC_TIMING_UHS_DDR50) {
>>> + struct mmc_card *card;
>>> +
>>>   ctrl_2 |= SDHCI_CTRL_UHS_DDR50;
>>> + card = container_of(&(host->mmc),
>>> + struct mmc_card, host);
>>> + if (mmc_card_mmc(card))
>>> + ctrl_2 |= SDHCI_CTRL_VDD_180;
>>> + }
>>>   sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
>>>   }
>>>   if (!(host->quirks2 & SDHCI_QUIRK2_PRESET_VALUE_BROKEN) &&
>>
>> I'm using DDR50 on an eMMC that's only powered by 3.3V (no 1.8V
>> available) with sdhci-pxav3, so it sounds like I don't want to merge
>> this patch?
>>
> This patch is NEEDED for both 3.3v and 1.8v signaling.
> In the SD host spec for host control 2 register, 1.8v signaling enable
> bit must be set in order for UHS-I mode taking effect. Otherwise, the
> DDR50 mode won't take effect on host even it is selected.
> It's the SD host requirement.

In fact, I don't think 3.3v vccq for emmc can work under DDR50 mode
with SD host.
You must enable 1.8v signaling on host for UHS-I modes, but you set
3.3v for emmc vccq. It's conflictable.
The only way for emmc DDR50 to work is to set 1.8v for vccq although
JEDEC spec said both 1.8v and 3.3v are ok.

Thanks
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] mmc,sdio: advancing the setting of dev name in mmc_sdio_init_card()

[Huang Changming-R66093]

This is new version?
Maybe you should add prefix v2 in subject and the version history.

Best Regards
Jerry Huang


> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Chuansheng Liu
> Sent: Tuesday, November 20, 2012 1:38 AM
> To: c...@laptop.org; o...@wizery.com
> Cc: linux-mmc@vger.kernel.org; linux-ker...@vger.kernel.org;
> chuansheng@intel.com
> Subject: [PATCH] mmc,sdio: advancing the setting of dev name in
> mmc_sdio_init_card()
> 
> 
> In below call trace:
> mmc_rescan
> -> mmc_rescan_try_freq()
> -> mmc_attach_sdio()
> -> mmc_sdio_init_card()
>...
>pm_runtime_set_active()
>...
>mmc_add_card()
> 
> The dev name is set until in mmc_add_card(), but before that, it is
> possible the dev name is needed, for example in pm_runtime_set_active(),
> we can call trace event to trace which dev is changing the runtime status.
> 
> So here advance it into mmc_sdio_init_card() to benefit others.
> 
> Signed-off-by: liu chuansheng 
> ---
>  drivers/mmc/core/bus.c  |5 +++--
>  drivers/mmc/core/sdio.c |5 -
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c index
> 9b68933..4884d6e 100644
> --- a/drivers/mmc/core/bus.c
> +++ b/drivers/mmc/core/bus.c
> @@ -270,8 +270,9 @@ int mmc_add_card(struct mmc_card *card)
>   [UHS_DDR50_BUS_SPEED] = "DDR50 ",
>   };
> 
> -
> - dev_set_name(&card->dev, "%s:%04x", mmc_hostname(card->host), card-
> >rca);
> + if (!dev_name(&card->dev))
> + dev_set_name(&card->dev, "%s:%04x", mmc_hostname(card->host),
> + card->rca);
> 
>   switch (card->type) {
>   case MMC_TYPE_MMC:
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c index
> 2273ce6..a9f6f02 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -795,8 +795,11 @@ static int mmc_sdio_init_card(struct mmc_host *host,
> u32 ocr,
>   goto remove;
>   }
>  finish:
> - if (!oldcard)
> + if (!oldcard) {
>   host->card = card;
> + dev_set_name(&card->dev, "%s:%04x", mmc_hostname(card->host),
> + card->rca);
> + }
>   return 0;
> 
>  remove:
> --
> 1.7.0.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] mmc,sdio: Fix the panic due to devname NULL when calling pm_runtime_set_active()

[Ohad Ben-Cohen]

On Mon, Nov 19, 2012 at 10:01 AM, Liu, Chuansheng
 wrote:
>> > Rechecked these codes, the trace event runtime_pm_status is added newly,
>> this is different with vanilla
>> > Linux.
>>
>> Not sure I'm following - can you point out which tree are you working with ?
> Sorry, it is added internally for debugging purpose.

Maybe keep this patch internally too then ?
--
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] mmc,sdio: advancing the setting of dev name in mmc_sdio_init_card()

[Chuansheng Liu]

In below call trace:
mmc_rescan
-> mmc_rescan_try_freq()
-> mmc_attach_sdio()
-> mmc_sdio_init_card()
   ...
   pm_runtime_set_active()
   ...
   mmc_add_card()

The dev name is set until in mmc_add_card(), but before that, it is
possible the dev name is needed, for example in pm_runtime_set_active(),
we can call trace event to trace which dev is changing the runtime status.

So here advance it into mmc_sdio_init_card() to benefit others.

Signed-off-by: liu chuansheng 
---
 drivers/mmc/core/bus.c  |5 +++--
 drivers/mmc/core/sdio.c |5 -
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 9b68933..4884d6e 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -270,8 +270,9 @@ int mmc_add_card(struct mmc_card *card)
[UHS_DDR50_BUS_SPEED] = "DDR50 ",
};
 
-
-   dev_set_name(&card->dev, "%s:%04x", mmc_hostname(card->host), 
card->rca);
+   if (!dev_name(&card->dev))
+   dev_set_name(&card->dev, "%s:%04x", mmc_hostname(card->host),
+   card->rca);
 
switch (card->type) {
case MMC_TYPE_MMC:
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 2273ce6..a9f6f02 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -795,8 +795,11 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 
ocr,
goto remove;
}
 finish:
-   if (!oldcard)
+   if (!oldcard) {
host->card = card;
+   dev_set_name(&card->dev, "%s:%04x", mmc_hostname(card->host),
+   card->rca);
+   }
return 0;
 
 remove:
-- 
1.7.0.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] mmc,sdio: Fix the panic due to devname NULL when calling pm_runtime_set_active()

[Liu, Chuansheng]

> -Original Message-
> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
> Sent: Monday, November 19, 2012 3:47 PM
> To: Liu, Chuansheng
> Cc: Chris Ball; linux-mmc@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] mmc,sdio: Fix the panic due to devname NULL when
> calling pm_runtime_set_active()
> 
> On Mon, Nov 19, 2012 at 7:57 AM, Liu, Chuansheng
>  wrote:
> > Rechecked these codes, the trace event runtime_pm_status is added newly,
> this is different with vanilla
> > Linux.
> 
> Not sure I'm following - can you point out which tree are you working with ?
Sorry, it is added internally for debugging purpose.
> 
> > So I still think that calling pm_runtime_set_active is not safe when 
> > dev_name
> is NULL.
> > If you agree this point, I can refine the code that moving "init the 
> > dev_name "
> from mmc_add_card
> > to mmc_sdio_init_card.
> 
> This sounds more reasonable.
I will try a V2 patch soon, thanks.

> 
> Thanks,
> Ohad.
--
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