Re: mmc: Driver Strength Device Property

[Philip Rakity]

On Feb 16, 2015, at 5:39 PM, Arend van Spriel  wrote:

> On 02/16/15 15:25, Adrian Hunter wrote:
>> I am in the process of adding an ACPI Device Property to specify
>> the driver strength (aka drive strength, driver type) for use
>> with eMMC/SD/SDIO cards, however the ACPI Specification Workgroup
>> requires that Device Properties be sufficiently generic. This
>> raises several questions as to what is sufficiently generic. That
>> is covered in a Questions section below and is followed by a draft
>> ACPI Device Property Definition. Any comments would be greatly
>> appreciated.
>> 
>> First some background:
>> 
>> What are ACPI Device Properties and how do they relate to Device Tree
>> -
>> 
>> ACPI Device Properties are key / value pairs that can be recorded
>> in the ACPI DSDT using a _DSD object with a specific UUID. Refer:
>>  The ACPI specification and
>>  
>> http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
>>  http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf
>> 
>> Linux provides a common API to read ACPI Device Properties and
>> Device Tree properties. Refer:
>>  
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/base/property.c
>>  http://marc.info/?l=linux-kernel&m=141354745011569&w=4
>> 
>> Obviously, the common API only works when the same property name
>> is not defined differently for the same device or class
>> of devices.
>> 
>> What is Driver Strength
>> ---
>> 
>> Both the JEDEC eMMC Specification and the SD Association Physical
>> Layer Specification define Driver Strength. The specifications
>> also use the terms Drive Strength and Driver Type for the same
>> thing. While the specifications deal with cards, the Host
>> Controller can also have a Driver Strength value, for example as
>> specified in the SD Host Controller Specification.
>> 
>> For eMMC, Driver Strength is an optional setting for the HS200 and
>> HS400 transfer modes.
>> 
>> Currently JEDEC defines:
>> 
>>  Value   Nominal Impedance   Approx. capability
>>  relative to type 0
>> 
>>  0   50 ohm  x1
>>  1   33 ohm  x1.5
>>  2   66 ohm  x0.75
>>  3   100 ohm x0.5
>>  4   40 ohm  x1.2
>> 
>> For SD/SDIO, Driver Strength is an optional setting for the
>> UHS-I transfer modes.
>> 
>> The SD Association defines:
>> 
>> Driver   Value   Nominal Impedance   Approx. capability
>> Type relative to type 0
>> 
>> A1   33 ohm  x1.5
>> B0   50 ohm  x1
>> C2   66 ohm  x0.75
>> D3   100 ohm x0.5
>> 
>> So the values are the same with the exception that eMMCs have the
>> additional value 4 (40 ohm). It is assumed that the values will
>> anyway not conflict because eMMC is not removable.
>> 
>> The specifications state that support for Driver Strength 0
>> (Driver Type B) is both mandatory and the default value.
>> In addition, cards supply a mask of supported Driver Strength
>> values. Therefore the Driver Strength value is validated against
>> the supported values.
>> 
>> Questions
>> -
>> 
>> Question 1. Should there be separate Driver Strength values for
>> cards and host controllers?
>> 
>> There is no indication from the specifications that cards and
>> host controllers need have the same value for Driver Strength.
>> That suggests that separate properties for the card and host
>> controller should be provided for.
>> 
>> Originally, I was just proposing "driver-strength" for the
>> Driver Strength of the card, but now will separate this into
>> "card-driver-strength" and "host-driver-strength".
> 
> Hi Adrian,
> 
> I am not sure if it makes sense to have a 'card-driver-strength' 
> specification for the host controller. I have been under the impression that 
> the proper value for this is strongly depending on the card used in the slot. 
> For this reason and the fact that it is programmed in our device we added 
> brcm,drive-strength property in our device-tree bindings [1].
> 
> Regards,
> Arend
> 
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt

Adrian, Arend,

My experience is that the value also depends very much on the board design as 
well as the eMMC/sdio chip being used.  eMMC chips have
some variation.  A DT entry does make sense for eMMC and other wired in devices 
but in this case the value is a property of the hardware
and "burnt in" as a property of the board design.

regards,

Philip

>> Question 2. To what devices should the Drive

Re: [PATCH] mmc: sdhci: fix possible scheduling while atomic

[Philip Rakity]

I have no way to test this problem but I was thinking along the lines of

--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1862,6 +1862,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 
 
sdhci_runtime_pm_get(host);
disable_irq(host->irq);
+   sdhci_disable_card_detection(host);
spin_lock(&host->lock);
 
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
@@ -1883,6 +1884,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 
ctrl |= SDHCI_CTRL_EXEC_TUNING;
else {
spin_unlock(&host->lock);
+   sdhci_enable_card_detection(host);
enable_irq(host->irq);
sdhci_runtime_pm_put(host);
return 0;
@@ -1890,6 +1892,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 
 
if (host->ops->platform_execute_tuning) {
spin_unlock(&host->lock);
+   sdhci_enable_card_detection(host);
enable_irq(host->irq);
err = host->ops->platform_execute_tuning(host, opcode);
sdhci_runtime_pm_put(host);
@@ -2047,6 +2050,7 @@ out:
 
sdhci_clear_set_irqs(host, SDHCI_INT_DATA_AVAIL, ier);
spin_unlock(&host->lock);
+   sdhci_enable_card_detection(host);
enable_irq(host->irq);
sdhci_runtime_pm_put(host);
 

regards,

Philip

On Jan 20, 2014, at 9:51 AM, Philip Rakity  wrote:

> 
> Chris,
> 
> The suggested fix can lock out interrupts for up to 150ms.  There needs to be 
> another way.
> So, I would strongly recommend we find another solution.
> 
> Philip
> 
> On Jan 17, 2014, at 7:57 PM, Andrew Bresticker  wrote:
> 
>> sdhci_execute_tuning() takes host->lock without disabling interrupts.
>> Use spin_lock_irq{save,restore} instead so that we avoid taking an
>> interrupt and scheduling while holding host->lock.
>> 
>> Signed-off-by: Andrew Bresticker 
>> ---
>> drivers/mmc/host/sdhci.c | 13 +++--
>> 1 file changed, 7 insertions(+), 6 deletions(-)
>> 
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index ec3eb30..84c80e7 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1857,12 +1857,13 @@ static int sdhci_execute_tuning(struct mmc_host 
>> *mmc, u32 opcode)
>>  unsigned long timeout;
>>  int err = 0;
>>  bool requires_tuning_nonuhs = false;
>> +unsigned long flags;
>> 
>>  host = mmc_priv(mmc);
>> 
>>  sdhci_runtime_pm_get(host);
>>  disable_irq(host->irq);
>> -spin_lock(&host->lock);
>> +spin_lock_irqsave(&host->lock, flags);
> 
> 
> The disable_irq() call stops the controller from doing interrupts.  
> Please explain what problem you are seeing
> 
>> 
>>  ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
>> 
>> @@ -1882,14 +1883,14 @@ static int sdhci_execute_tuning(struct mmc_host 
>> *mmc, u32 opcode)
>>  requires_tuning_nonuhs)
>>  ctrl |= SDHCI_CTRL_EXEC_TUNING;
>>  else {
>> -spin_unlock(&host->lock);
>> +spin_unlock_irqrestore(&host->lock, flags);
>>  enable_irq(host->irq);
>>  sdhci_runtime_pm_put(host);
>>  return 0;
>>  }
>> 
>>  if (host->ops->platform_execute_tuning) {
>> -spin_unlock(&host->lock);
>> +spin_unlock_irqrestore(&host->lock, flags);
>>  enable_irq(host->irq);
>>  err = host->ops->platform_execute_tuning(host, opcode);
>>  sdhci_runtime_pm_put(host);
>> @@ -1963,7 +1964,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, 
>> u32 opcode)
>>  host->cmd = NULL;
>>  host->mrq = NULL;
>> 
>> -spin_unlock(&host->lock);
>> +spin_unlock_irqrestore(&host->lock, flags);
>>  enable_irq(host->irq);
>> 
>>  /* Wait for Buffer Read Ready interrupt */
>> @@ -1971,7 +1972,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, 
>> u32 opcode)
>>  (host->tuning_done == 1),
>>  msecs_to_jiffies(50));
>>  disable_irq(host->irq);
>> -spin_lock(&host->lock);
>> +spin_lock_irqsave(&host->lock, flags);
>> 
>>  if (!host->tuning_done) {
>>  pr_info(DRIVER_NAME ": Timeout w

Re: [PATCH] mmc: sdhci: fix possible scheduling while atomic

[Philip Rakity]

Chris,

The suggested fix can lock out interrupts for up to 150ms.  There needs to be 
another way.
So, I would strongly recommend we find another solution.

Philip

On Jan 17, 2014, at 7:57 PM, Andrew Bresticker  wrote:

> sdhci_execute_tuning() takes host->lock without disabling interrupts.
> Use spin_lock_irq{save,restore} instead so that we avoid taking an
> interrupt and scheduling while holding host->lock.
> 
> Signed-off-by: Andrew Bresticker 
> ---
> drivers/mmc/host/sdhci.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index ec3eb30..84c80e7 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1857,12 +1857,13 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, 
> u32 opcode)
>   unsigned long timeout;
>   int err = 0;
>   bool requires_tuning_nonuhs = false;
> + unsigned long flags;
> 
>   host = mmc_priv(mmc);
> 
>   sdhci_runtime_pm_get(host);
>   disable_irq(host->irq);
> - spin_lock(&host->lock);
> + spin_lock_irqsave(&host->lock, flags);


The disable_irq() call stops the controller from doing interrupts.  
Please explain what problem you are seeing

> 
>   ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> 
> @@ -1882,14 +1883,14 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, 
> u32 opcode)
>   requires_tuning_nonuhs)
>   ctrl |= SDHCI_CTRL_EXEC_TUNING;
>   else {
> - spin_unlock(&host->lock);
> + spin_unlock_irqrestore(&host->lock, flags);
>   enable_irq(host->irq);
>   sdhci_runtime_pm_put(host);
>   return 0;
>   }
> 
>   if (host->ops->platform_execute_tuning) {
> - spin_unlock(&host->lock);
> + spin_unlock_irqrestore(&host->lock, flags);
>   enable_irq(host->irq);
>   err = host->ops->platform_execute_tuning(host, opcode);
>   sdhci_runtime_pm_put(host);
> @@ -1963,7 +1964,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, 
> u32 opcode)
>   host->cmd = NULL;
>   host->mrq = NULL;
> 
> - spin_unlock(&host->lock);
> + spin_unlock_irqrestore(&host->lock, flags);
>   enable_irq(host->irq);
> 
>   /* Wait for Buffer Read Ready interrupt */
> @@ -1971,7 +1972,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, 
> u32 opcode)
>   (host->tuning_done == 1),
>   msecs_to_jiffies(50));
>   disable_irq(host->irq);
> - spin_lock(&host->lock);
> + spin_lock_irqsave(&host->lock, flags);
> 
>   if (!host->tuning_done) {
>   pr_info(DRIVER_NAME ": Timeout waiting for "
> @@ -2046,7 +2047,7 @@ out:
>   err = 0;
> 
>   sdhci_clear_set_irqs(host, SDHCI_INT_DATA_AVAIL, ier);
> - spin_unlock(&host->lock);
> + spin_unlock_irqrestore(&host->lock, flags);
>   enable_irq(host->irq);
>   sdhci_runtime_pm_put(host);
> 
> -- 
> 1.8.5.2
> 
> --
> 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
---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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

https://lkml.org/lkml/2013/11/13/574 (Ping !)

[Philip Rakity]

Hi Chris,

Hi Chris,

Could we progress this patch ?

Fixes a loop that never terminates if the SD card is bad in just the right way.

Philip


FromNeal Buckendahl <>
Subject [PATCH] mmc: host: sdhci: prevent mmcqd from becoming locked on mmc 
timeout
DateWed, 13 Nov 2013 20:22:54 -0800

fixed a condition where device issues a status cmd to sdcard but no response
comes from sdcard. The sdhci irq fires and we hit a timeout case which calls
sdhci_finish_data(). sdhci_finish_data eventually attempt to reset controller
and issues stop cmd. However mmcdq is wait_for_completion(&mrq->completion)
in function mmc_wait_for_req_done which never occurs.

Signed-off-by: Neal Buckendahl 
Signed-off-by: Narayanan Gopalakrishnan 
Signed-off-by: Philip Rakity 
---
 drivers/mmc/host/sdhci.c |5 +
 1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 6785fb1..21620d2 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -973,6 +973,11 @@ static void sdhci_finish_data(struct sdhci_host *host)
if (data->error) {
sdhci_reset(host, SDHCI_RESET_CMD);
sdhci_reset(host, SDHCI_RESET_DATA);
+   if (data->error == -ETIMEDOUT) {
+   host->mrq->cmd->error = -ETIMEDOUT;
+   tasklet_schedule(&host->finish_tasklet);
+   WARN_ON(1);
+   }
}
 
sdhci_send_command(host, data->stop);
-- 
1.7.10.4
---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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: sdhci: fix possible scheduling while atomic

[Philip Rakity]

On Jan 17, 2014, at 7:57 PM, Andrew Bresticker  wrote:

> sdhci_execute_tuning() takes host->lock without disabling interrupts.
> Use spin_lock_irq{save,restore} instead so that we avoid taking an
> interrupt and scheduling while holding host->lock.
> 
> Signed-off-by: Andrew Bresticker 
> ---
> drivers/mmc/host/sdhci.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index ec3eb30..84c80e7 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1857,12 +1857,13 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, 
> u32 opcode)
>   unsigned long timeout;
>   int err = 0;
>   bool requires_tuning_nonuhs = false;
> + unsigned long flags;
> 
>   host = mmc_priv(mmc);
> 
>   sdhci_runtime_pm_get(host);
>   disable_irq(host->irq);
> - spin_lock(&host->lock);
> + spin_lock_irqsave(&host->lock, flags);


The disable_irq() call stops the controller from doing interrupts.  
Please explain what problem you are seeing

> 
>   ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> 
> @@ -1882,14 +1883,14 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, 
> u32 opcode)
>   requires_tuning_nonuhs)
>   ctrl |= SDHCI_CTRL_EXEC_TUNING;
>   else {
> - spin_unlock(&host->lock);
> + spin_unlock_irqrestore(&host->lock, flags);
>   enable_irq(host->irq);
>   sdhci_runtime_pm_put(host);
>   return 0;
>   }
> 
>   if (host->ops->platform_execute_tuning) {
> - spin_unlock(&host->lock);
> + spin_unlock_irqrestore(&host->lock, flags);
>   enable_irq(host->irq);
>   err = host->ops->platform_execute_tuning(host, opcode);
>   sdhci_runtime_pm_put(host);
> @@ -1963,7 +1964,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, 
> u32 opcode)
>   host->cmd = NULL;
>   host->mrq = NULL;
> 
> - spin_unlock(&host->lock);
> + spin_unlock_irqrestore(&host->lock, flags);
>   enable_irq(host->irq);
> 
>   /* Wait for Buffer Read Ready interrupt */
> @@ -1971,7 +1972,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, 
> u32 opcode)
>   (host->tuning_done == 1),
>   msecs_to_jiffies(50));
>   disable_irq(host->irq);
> - spin_lock(&host->lock);
> + spin_lock_irqsave(&host->lock, flags);
> 
>   if (!host->tuning_done) {
>   pr_info(DRIVER_NAME ": Timeout waiting for "
> @@ -2046,7 +2047,7 @@ out:
>   err = 0;
> 
>   sdhci_clear_set_irqs(host, SDHCI_INT_DATA_AVAIL, ier);
> - spin_unlock(&host->lock);
> + spin_unlock_irqrestore(&host->lock, flags);
>   enable_irq(host->irq);
>   sdhci_runtime_pm_put(host);
> 
> -- 
> 1.8.5.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: sdhci: don't limit discard timeout by data line timeout

[Philip Rakity]

On Nov 27, 2013, at 2:57 PM, Vladimir Zapolskiy  wrote:

> On 11/27/13 10:21, Adrian Hunter wrote:
>> On 26/11/13 18:33, Vladimir Zapolskiy wrote:
>>> On 11/26/13 11:04, Adrian Hunter wrote:
 On 22/11/13 17:21, Vladimir Zapolskiy wrote:
> On 22.11.2013 16:04, Adrian Hunter wrote:
>> On 22/11/13 15:50, Vladimir Zapolskiy wrote:
>>> On 22.11.2013 14:04, Adrian Hunter wrote:
 On 22/11/13 14:24, Vladimir Zapolskiy wrote:
> On 22.11.2013 12:38, Adrian Hunter wrote:
>> On 21/11/13 17:07, Vladimir Zapolskiy wrote:
>>> JEDEC specification defines quite high erase timeout value for 300ms
>>> multiplied by erase group number, and SD Host Controller 
>>> specification
>>> data line timeout may be much less, e.g. 2^13 / 52MHz ~ 160us.
>>> 
   From block layer and MMC perfromance perspective it is 
 desirable
 that
>>> millions of erase groups are discarded at once, so there is no much
>>> sense to limit maximum erase timeout by data line timeout, if a
>>> controller handles correctly erase operation without indication of
>>> data line timeout.
>> 
>> Would you explain that some more.  Do you mean that:
>>a) it does not have a timeout
> 
> JEDEC defines a timeout on erase/trim operations, also in
> drivers/mmc/core/core.c
> there is a reasonable enough 10 minutes limitation for discard
> operations.
> 
>>b) it has a timeout which is less than the timeout specified
>> by the
>> standard but the operation nevertheless completes
> 
> SDHC data line timeout is enormously less than erase group timeout, 
> and
> trivial testing shows that those two timeouts are independent, 
> probably
> except some particular cases of controllers not known before commits
> 58d1246db3 and e056a1b5b.
> 
> According to the currently implemented logic, mmc_do_erase() commonly 
> is
> instructed to discard 1-2 erase groups at maximum, however it tends
> to be
> capable to successfully discard millions of erase groups at once
> ignoring
> that SDHC data line timeout limitation.
> 
 
 You seem to be trying to say that the SDHCI spec. says that the host
 controller does not timeout erase operations or uses a different 
 timeout
 than the one programmed in the "Timeout Control Register".  Where is
 that is
 the SDHCI spec?
>>> 
>>> According to the spec a host controller timeouts erase operations like 
>>> any
>>> other R1B command.
>>> 
>>> So in your opinion, should there be SDHCI_QUIRK_BROKEN_TIMEOUT_VAL 
>>> instead
>>> of the new quirk?
>> 
>> I don't understand how SDHCI_QUIRK_BROKEN_TIMEOUT_VAL would help.  It 
>> just
>> sets the timeout to maximum but max_discard_to is the maximum timeout.
> 
> Here I meant to do something like:
> 
>  if (host->quirks&   SDHCI_QUIRK_BROKEN_TIMEOUT_VAL)
>  mmc->max_discard_to = 0;
> 
> Again I'm not sure that this applies well to all
> SDHCI_QUIRK_BROKEN_TIMEOUT_VAL
> controllers, therefore a new quirk might be better.
> 
>> As I understand it you don't want to limit the discard size, either 
>> because
>> your controller does not timeout, or because you are happy that the 
>> maximum
>> timeout is enough for your users and their use-cases.
>> 
>> If that is the case then the original patch just needs the quirk the 
>> other
>> way around. i.e.
>> 
>>   if (host->quirks2&SDHCI_QUIRK2_NO_DISCARD_LIMIT)
>>   mmc->max_discard_to = 0;
>>   else
>>   mmc->max_discard_to = (1<<27) / host->timeout_clk;
> 
> This suits me fine, thanks for review, and I'll resend a change based on
> this.
> 
> Also I'd like to pay your attention to (1<<   27) / host->timeout_clk 
> part of
> calculation, following the spec it might be better to account the actual
> value of Data Timeout Counter, otherwise a controller may get 
> unintentional
> Data Timeout Error pretty soon. Please correct me, if I'm mistaken here.
 
 Not sure what you mean.  max_discard_to is the maximum timeout (in
 milliseconds) that the host controller supports.  The intent is to limit
 erase operations to ones that have a timeout that is less than or equal to
 that.
>>> 
>>> That's clear. But it's not obvious why do you prefer (1<<  27) numerator
>>> instead
>>> of secure (1<<  13) or (1<<  (13 + sdhci_readl(host, 
>>> SDHCI_TIMEOUT_CONTROL))).
>> 
>> The maximum value of "Data Timeout Counter Value" in "Timeout Control
>> Register" is 14 and the maximum timeout is therefore (1

Re: [PATCH 0/8] sdhci: Move real work out of an atomic context

[Philip Rakity]

On Jul 9, 2013, at 4:44 PM, Jeremie Samuel  
wrote:

> Hi all,
> 
> Currently the sdhci driver does everything in the atomic context.
> And what is worse, PIO transfers are made from the IRQ handler.
> 
> Some patches were already submitted to solve this issue. But there were
> rejected because they involved new issues.
> 
> This set of patches is an evolution of an old patch from Anton Vorontsov.
> I tried to fix all the problems involved by the patches. I tested it for
> several time now with SD cards and SDIO.
> 
> So, this patch set reworks sdhci code to avoid atomic context,
> almost completely.
> 
> Thanks,
> 

Running DDR50, SDR104 or HS200 what is the performance impact ?


> Jeremie Samuel
> 
> Jeremie Samuel (8):
>  sdhci: Turn timeout timer into delayed work
>  sdhci: Turn tuning timeout timer into delayed work
>  sdhci: Use work structs instead of tasklets
>  sdhci: Use threaded IRQ handler
>  sdhci: Delay led blinking
>  sdhci: Turn host->lock into a mutex
>  sdhci: Get rid of mdelay()s where it is safe and makes sense
>  sdhci: Use jiffies instead of a timeout counter
> 
> drivers/mmc/host/sdhci.c  |  327 ++---
> include/linux/mmc/sdhci.h |   13 +-
> 2 files changed, 168 insertions(+), 172 deletions(-)
> 
> -- 
> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH (v2)] mmc: sdhci: fix caps2 for HS200

[Philip Rakity]

On Jun 12, 2013, at 7:16 AM, Giuseppe CAVALLARO  wrote:

> Although the HC supports HS200 (eMMC) the caps2 are always zero; this means 
> that
> no way to use the super speed mode (when init the card).
> 
> If the HC support SDR104, for SD3.0, so it also supports HS200 for eMMC and
> this patch just sets the MMC_CAP2_HS200 in the host caps2 field.
> 
> v2: Since SDR104 and HS200 are effectively the same thing the patch deletes
> the defines for HS200 and use SDR104.
> 
> Reported-by: Youssef Triki 
> Signed-off-by: Giuseppe Cavallaro 
> Cc: Philip Rakity 
> ---
> drivers/mmc/host/sdhci.c  |   14 +-
> include/linux/mmc/sdhci.h |2 +-
> 2 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 2ea429c..b8bb3b3 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1846,7 +1846,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, 
> u32 opcode)
>*/
>   if (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR50) &&
>   (host->flags & SDHCI_SDR50_NEEDS_TUNING ||
> -  host->flags & SDHCI_HS200_NEEDS_TUNING))
> +  host->flags & SDHCI_SDR104_NEEDS_TUNING))
>   requires_tuning_nonuhs = true;
> 
>   if (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR104) ||
> @@ -2962,9 +2962,13 @@ int sdhci_add_host(struct sdhci_host *host)
>   mmc->caps |= MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25;
> 
>   /* SDR104 supports also implies SDR50 support */
> - if (caps[1] & SDHCI_SUPPORT_SDR104)
> + if (caps[1] & SDHCI_SUPPORT_SDR104) {
>   mmc->caps |= MMC_CAP_UHS_SDR104 | MMC_CAP_UHS_SDR50;
> - else if (caps[1] & SDHCI_SUPPORT_SDR50)
> + /* SD3.0: SDR104 is supported so (for eMMC) the caps2
> +  * field can be promoted to support HS200.
> +  */
> + mmc->caps2 |= MMC_CAP2_HS200;
> + } else if (caps[1] & SDHCI_SUPPORT_SDR50)
>   mmc->caps |= MMC_CAP_UHS_SDR50;
> 
>   if (caps[1] & SDHCI_SUPPORT_DDR50)
> @@ -2974,9 +2978,9 @@ int sdhci_add_host(struct sdhci_host *host)
>   if (caps[1] & SDHCI_USE_SDR50_TUNING)
>   host->flags |= SDHCI_SDR50_NEEDS_TUNING;
> 
> - /* Does the host need tuning for HS200? */
> + /* Does the host need tuning for SDR104 / HS200? */
>   if (mmc->caps2 & MMC_CAP2_HS200)
> - host->flags |= SDHCI_HS200_NEEDS_TUNING;
> + host->flags |= SDHCI_SDR104_NEEDS_TUNING;
> 
>   /* Driver Type(s) (A, C, D) supported by the host */
>   if (caps[1] & SDHCI_DRIVER_TYPE_A)
> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
> index b838ffc..0b1d7f4 100644
> --- a/include/linux/mmc/sdhci.h
> +++ b/include/linux/mmc/sdhci.h
> @@ -126,7 +126,7 @@ struct sdhci_host {
> #define SDHCI_AUTO_CMD23  (1<<7)  /* Auto CMD23 support */
> #define SDHCI_PV_ENABLED  (1<<8)  /* Preset value enabled */
> #define SDHCI_SDIO_IRQ_ENABLED(1<<9)  /* SDIO irq enabled */
> -#define SDHCI_HS200_NEEDS_TUNING (1<<10) /* HS200 needs tuning */
> +#define SDHCI_SDR104_NEEDS_TUNING (1<<10)/* SDR104/HS200 needs tuning */
> #define SDHCI_USING_RETUNING_TIMER (1<<11)/* Host is using a retuning 
> timer for the card */
> 
>   unsigned int version;   /* SDHCI spec. version */
> -- 
> 1.7.4.4
> 

Reviewed-by: Philip Rakity 

note:  cannot test code at this time.

--
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: sdhci: fix caps2 for HS200

[Philip Rakity]

On Jun 11, 2013, at 3:09 PM, Giuseppe CAVALLARO  wrote:

> Although the HC supports HS200 (eMMC) the caps2 are always zero; this means 
> that
> no way to use the super speed mode (when init the card).
> 
> If the HC support SDR104, for SD3.0, so it also supports HS200 for eMMC and
> this patch just sets the MMC_CAP2_HS200 in the host caps2 field.
> 
> Reported-by: Youssef Triki 
> Signed-off-by: Giuseppe Cavallaro 
> ---
> drivers/mmc/host/sdhci.c |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 2ea429c..5626f5f 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2962,9 +2962,13 @@ int sdhci_add_host(struct sdhci_host *host)
>   mmc->caps |= MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25;
> 
>   /* SDR104 supports also implies SDR50 support */
> - if (caps[1] & SDHCI_SUPPORT_SDR104)
> + if (caps[1] & SDHCI_SUPPORT_SDR104) {
>   mmc->caps |= MMC_CAP_UHS_SDR104 | MMC_CAP_UHS_SDR50;
> - else if (caps[1] & SDHCI_SUPPORT_SDR50)
> + /* SD3.0: SDR104 is supported so from eMMC caps2
> +  * can be promoted to support HS200.
> +  */
> + mmc->caps2 |= MMC_CAP2_HS200;
> + } else if (caps[1] & SDHCI_SUPPORT_SDR50)
>   mmc->caps |= MMC_CAP_UHS_SDR50;
> 
>   if (caps[1] & SDHCI_SUPPORT_DDR50)
> -- 
> 1.7.4.4


further down in the code could you  change the  comment from
/* Does the host need tuning for HS200? */
if (mmc->caps2 & MMC_CAP2_HS200)
host->flags |= SDHCI_HS200_NEEDS_TUNING;


to

/* Does the host need tuning for SDR104/HS200? */
if (mmc->caps2 & MMC_CAP2_HS200)
host->flags |= SDHCI_HS200_NEEDS_TUNING;

Since SDR104 and HS200 are effectively the same thing should we delete the 
defines for HS200 and use SDR104 ?
or
if we want SDR104 to be separate from HS200 create defines for that.  Like 
SDHCI_SDR104_NEEDS_TUNING 




> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: When bus width detection procedure takes place, kernel cannot lock on correct bus width

[Philip Rakity]

Elad,

I would like to discuss this problem with someone at sandisk.  Could you let me 
know what part you are using.

Also, since you have managed to track down the problem this far perhaps you can 
print out the fields values in 1, 4, and 8 bit modes and let me know what is 
present.

regards,

Philip

On Mar 22, 2013, at 6:56 PM, Philip Rakity  wrote:

> 
> Elad,
> 
> Please supply the name of the spec which shows that this field is dependent 
> on bit width.
> 
> I checked my sd / emmc specs and do not see this.
> 
> regards,
> 
> Philip
> 
> 
> On Mar 17, 2013, at 5:07 AM, Chris Ball  wrote:
> 
>> Hi Elad, I'm forwarding your bug report to the linux-mmc@ list.
>> 
>> - Chris.
>> 
>> 
>> I've been working on a bringup of an new board in Harmonic Inc.
>> This board uses Sandisk iNand eMMC flash.
>> I've noticed that the mmc driver keeps detecting 1 bit width although HW
>> supports 4 bit, looked into it, and found the problem. In line 571 at mmc.c:
>> There is:
>>   /* only compare read only fields */
>>   err = !((card->ext_csd.raw_partition_support ==
>>   bw_ext_csd[EXT_CSD_PARTITION_SUPPORT]) &&
>>   (card->ext_csd.raw_erased_mem_count ==
>>   bw_ext_csd[EXT_CSD_ERASED_MEM_CONT]) &&
>>   (card->ext_csd.rev ==
>>   bw_ext_csd[EXT_CSD_REV]) &&
>>   (card->ext_csd.raw_ext_csd_structure ==
>>   ...
>> 
>> The problem is that raw_partition_support is not the same when setting width 
>> of
>> 4 bits instead of 1 bit, and shouldn't be compared at all although it is read
>> only.
>> this should be changed to:
>>   /* only compare read only fields */
>>   err = !((card->ext_csd.raw_erased_mem_count ==
>>   bw_ext_csd[EXT_CSD_ERASED_MEM_CONT]) &&
>>   (card->ext_csd.rev ==
>>   bw_ext_csd[EXT_CSD_REV]) &&
>>   (card->ext_csd.raw_ext_csd_structure ==
>>   ...
>> 
>> -- 
>> Chris Ball  <http://printf.net/>
>> One Laptop Per Child
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: When bus width detection procedure takes place, kernel cannot lock on correct bus width

[Philip Rakity]

Elad,

Please supply the name of the spec which shows that this field is dependent on 
bit width.

I checked my sd / emmc specs and do not see this.

regards,

Philip


On Mar 17, 2013, at 5:07 AM, Chris Ball  wrote:

> Hi Elad, I'm forwarding your bug report to the linux-mmc@ list.
> 
> - Chris.
> 
> 
> I've been working on a bringup of an new board in Harmonic Inc.
> This board uses Sandisk iNand eMMC flash.
> I've noticed that the mmc driver keeps detecting 1 bit width although HW
> supports 4 bit, looked into it, and found the problem. In line 571 at mmc.c:
> There is:
>/* only compare read only fields */
>err = !((card->ext_csd.raw_partition_support ==
>bw_ext_csd[EXT_CSD_PARTITION_SUPPORT]) &&
>(card->ext_csd.raw_erased_mem_count ==
>bw_ext_csd[EXT_CSD_ERASED_MEM_CONT]) &&
>(card->ext_csd.rev ==
>bw_ext_csd[EXT_CSD_REV]) &&
>(card->ext_csd.raw_ext_csd_structure ==
>...
> 
> The problem is that raw_partition_support is not the same when setting width 
> of
> 4 bits instead of 1 bit, and shouldn't be compared at all although it is read
> only.
> this should be changed to:
>/* only compare read only fields */
>err = !((card->ext_csd.raw_erased_mem_count ==
>bw_ext_csd[EXT_CSD_ERASED_MEM_CONT]) &&
>(card->ext_csd.rev ==
>bw_ext_csd[EXT_CSD_REV]) &&
>(card->ext_csd.raw_ext_csd_structure ==
>...
> 
> -- 
> 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 v2] mmc: sdhci: update check code for cd-broken or nonremovable card

[Philip Rakity]

On Mar 1, 2013, at 9:40 AM, Kevin Liu  wrote:

> in function sdhci_request:
> 1. If quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION is selected, there is no
> card detection available and polling must be used. Gpio detect must
> _not_ be supported under this case.
> Change the sequence to check SDHCI_QUIRK_BROKEN_CARD_DETECTION first,
> which make code more clear.
> 2. nonremovable card should be also assumed always present.
> 
> in function sdhci_enable_irq_wakeups:
> 1. nonremovable card should be also assumed no insert/remove wakeup
> needed like some sdio cards which is nonremovable and can wakeup host
> only by card int.
> 
> Signed-off-by: Kevin Liu 
> ---
> drivers/mmc/host/sdhci.c |   30 --
> 1 file changed, 16 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index c94fd6c..e4ada0d 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1337,19 +1337,20 @@ static void sdhci_request(struct mmc_host *mmc, 
> struct mmc_request *mrq)
> 
>   host->mrq = mrq;
> 
> - /*
> -  * Firstly check card presence from cd-gpio.  The return could
> -  * be one of the following possibilities:
> -  * negative: cd-gpio is not available
> -  * zero: cd-gpio is used, and card is removed
> -  * one: cd-gpio is used, and card is present
> -  */
> - present = mmc_gpio_get_cd(host->mmc);
> - if (present < 0) {
> - /* If polling, assume that the card is always present. */
> - if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
> - present = 1;
> - else
> + /* If polling/nonremovable, assume that the card is always present. */
> + if ((host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) ||
> + (host->mmc->caps & MMC_CAP_NONREMOVABLE)) {
> + present = 1;
> + } else {
> + /*
> +  * Firstly check card presence from cd-gpio.  The return could
> +  * be one of the following possibilities:
> +  * negative: cd-gpio is not available
> +  * zero: cd-gpio is used, and card is removed
> +  * one: cd-gpio is used, and card is present
> +  */
> + present = mmc_gpio_get_cd(host->mmc);
> + if (IS_ERR_VALUE(present))
>   present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
>   SDHCI_CARD_PRESENT;

Hi Kevin

does it make sense to move this logic to a more generic function (static inline 
?)
int sdhci_card_present ()

and encapsulate all the logic there for gpio cd, present state (card is there) 
etc.

Philip

>   }
> @@ -2504,7 +2505,8 @@ void sdhci_enable_irq_wakeups(struct sdhci_host *host)
>   val = sdhci_readb(host, SDHCI_WAKE_UP_CONTROL);
>   val |= mask ;
>   /* Avoid fake wake up */
> - if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
> + if ((host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) ||
> + (host->mmc->caps & MMC_CAP_NONREMOVABLE))
>   val &= ~(SDHCI_WAKE_ON_INSERT | SDHCI_WAKE_ON_REMOVE);
>   sdhci_writeb(host, val, SDHCI_WAKE_UP_CONTROL);
> }
> -- 
> 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 v7 1/2] mmc: core: enhance card removal judgement for slow removal

[Philip Rakity]

Reviewed-by: Philip Rakity 

On Feb 28, 2013, at 7:29 AM, Kevin Liu  wrote:

> Function _mmc_detect_card_removed will be called to know whether
> the card is still present when host->bus_ops->detect is called.
> In current code, the return value of this function generally only
> depend on the result of sending cmd13 to card, which may not safe
> for card with detection support like slot gpio detection.
> Because the communication status between host and card may out of
> sync with the detect status if remove the card slowly or hands shake
> during the process. The direct reason is the async between card
> detect switch and card/slot pad contaction in hardware, which is
> defined by spec.
> 
> The spec define card insert/remove sequence as below (both standard size
> SD card and MicroSD card have the same sequence):
> "Part 1 Standard Size SD Card Mechanical Addendum Ver4.00 Final,
> Appendix C: Card Detection Switch" (Take normally open type as example)
> a)SD card insertion sequence:
>  The card detection switch should be turned on after all SD card
>  contact pads are connected to the host connector contact pads.
> b)SD removal sequence:
>  The card detection switch should be turned off when the SD card
>  is just going to be removed and before any SD card contact pad is
>  disconnected from the host connector contact pad.
> 
> Below is the sequence when this issue occur (Take slot gpio detection
> as example and remove the card slowly during the process):
> 1. gpio level changed and card detect interrupt triggered.
> 2. mmc_rescan was launched.
> 3. the card pads were still contacted with the slot pads because of slow
>   removal. So _mmc_detect_card_removed and mmc_rescan think card was
>   still present (cmd13 succeed).
> 4. card pads were discontacted from the card slot pads.
> So the card was actually removed finally but the card removal event
> has been missed by system.
> The interval length between step 1 and step 4 depends on the
> card removal speed. If it's longer than the detect work schedule
> delay which is 200ms, this issue will likely happen.
> 
> This patch add the card detect status check in function
> _mmc_detect_card_removed if cmd13 check succeed and host->ops->get_cd
> provided. If get_cd detect no card present then schedule another detect
> work 200ms later.
> 
> Signed-off-by: Kevin Liu 
> ---
> drivers/mmc/core/core.c |   13 +
> 1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index b8c3d41..d9ac96c 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -2290,6 +2290,19 @@ int _mmc_detect_card_removed(struct mmc_host *host)
>   return 1;
> 
>   ret = host->bus_ops->alive(host);
> + /*
> +  * Card detect status and alive check may out of sync if card is
> +  * removed slowly when card detect switch changed while card/slot
> +  * pads still contacted in hardware.(refer to "SD Card Mechanical
> +  * Addendum, Appendix C: Card Detection Switch") So reschedule a
> +  * detect work 200ms later for this case.
> +  */
> + if (!ret && host->ops->get_cd && !host->ops->get_cd(host)) {
> + mmc_detect_change(host, msecs_to_jiffies(200));
> + pr_debug("%s: card remove too slowly\n",
> + mmc_hostname(host));
> + }
> +
>   if (ret) {
>   mmc_card_set_removed(host->card);
>   pr_debug("%s: card remove detected\n", mmc_hostname(host));
> -- 
> 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 v2 3/3] mmc: sdhci: update signal voltage switch code

[Philip Rakity]

On Dec 17, 2012, at 8:50 AM, Kevin Liu  wrote:

> The protocal related code is moved to core stack. So update the host
> driver accordingly.
> 
> Signed-off-by: Kevin Liu 
> Tested-by: Tim Wang 
> ---
> drivers/mmc/host/sdhci.c |  194 +++---
> 1 files changed, 81 insertions(+), 113 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 6f0bfc0..beaa233 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1608,145 +1608,99 @@ static void sdhci_enable_sdio_irq(struct mmc_host 
> *mmc, int enable)
>   spin_unlock_irqrestore(&host->lock, flags);
> }
> 
> -static int sdhci_do_3_3v_signal_voltage_switch(struct sdhci_host *host,
> - u16 ctrl)
> +static int sdhci_do_start_signal_voltage_switch(struct sdhci_host *host,
> + int signal_voltage)
> {
> + u16 ctrl;
>   int ret;
> 
> - /* Set 1.8V Signal Enable in the Host Control2 register to 0 */
> - ctrl &= ~SDHCI_CTRL_VDD_180;
> - sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
> -
> - if (host->vqmmc) {
> - ret = regulator_set_voltage(host->vqmmc, 270, 360);
> - if (ret) {
> - pr_warning("%s: Switching to 3.3V signalling voltage "
> -" failed\n", mmc_hostname(host->mmc));
> - return -EIO;
> - }
> - }
> - /* Wait for 5ms */
> - usleep_range(5000, 5500);
> -
> - /* 3.3V regulator output should be stable within 5 ms */
> - ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> - if (!(ctrl & SDHCI_CTRL_VDD_180))
> + /*
> +  * Signal Voltage Switching is only applicable for Host Controllers
> +  * v3.00 and above.
> +  */
> + if (host->version < SDHCI_SPEC_300)
>   return 0;
> 
> - pr_warning("%s: 3.3V regulator output did not became stable\n",
> -mmc_hostname(host->mmc));
> -
> - return -EIO;
> -}
> + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> 
> -static int sdhci_do_1_8v_signal_voltage_switch(struct sdhci_host *host,
> - u16 ctrl)
> -{
> - u8 pwr;
> - u16 clk;
> - u32 present_state;
> - int ret;
> + switch (signal_voltage) {
> 
> - /* Stop SDCLK */
> - clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> - clk &= ~SDHCI_CLOCK_CARD_EN;
> - sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> + case MMC_SIGNAL_VOLTAGE_330:
> + /* Set 1.8V Signal Enable in the Host Control2 register to 0 */
> + ctrl &= ~SDHCI_CTRL_VDD_180;
> + sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
> 
> - /* Check whether DAT[3:0] is  */
> - present_state = sdhci_readl(host, SDHCI_PRESENT_STATE);
> - if (!((present_state & SDHCI_DATA_LVL_MASK) >>
> -SDHCI_DATA_LVL_SHIFT)) {
> - /*
> -  * Enable 1.8V Signal Enable in the Host Control2
> -  * register
> -  */
> - if (host->vqmmc)
> - ret = regulator_set_voltage(host->vqmmc,
> - 170, 195);
> - else
> - ret = 0;
> + if (host->vqmmc) {
> + ret = regulator_set_voltage(host->vqmmc, 270, 
> 360);
> + if (ret) {
> + pr_warning("%s: Switching to 3.3V signalling 
> voltage "
> + " failed\n", 
> mmc_hostname(host->mmc));
> + return -EIO;
> + }
> + }
> + /* Wait for 5ms */
> + usleep_range(5000, 5500);
> 
> - if (!ret) {
> - ctrl |= SDHCI_CTRL_VDD_180;
> - sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
> + /* 3.3V regulator output should be stable within 5 ms */
> + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> + if (!(ctrl & SDHCI_CTRL_VDD_180))
> + return 0;
> 
> - /* Wait for 5ms */
> - usleep_range(5000, 5500);
> + pr_warning("%s: 3.3V regulator output did not became stable\n",
> + mmc_hostname(host->mmc));
> 
> - ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> - if (ctrl & SDHCI_CTRL_VDD_180) {
> - /* Provide SDCLK again and wait for 1ms */
> - clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> - clk |= SDHCI_CLOCK_CARD_EN;
> - sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> - usleep_range(1000, 1500);
> + return -EAGAIN;
> 
> - /*
> -

Re: [PATCH v9 05/10] mmc: sdhci: introduce signal_voltage_switch callback function

[Philip Rakity]

On Dec 7, 2012, at 2:36 AM, Kevin Liu  wrote:

> Some soc/platform need specific handling for signal voltage
> switch. For example, mmp2/mmp3 need to set the AIB IO domain
> control register accordingly.
> 
> Signed-off-by: Bin Wang 
> Signed-off-by: Philip Rakity 
> Signed-off-by: Kevin Liu 
> ---
> drivers/mmc/host/sdhci.c |   17 +
> drivers/mmc/host/sdhci.h |1 +
> 2 files changed, 18 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 50d0382..10d06fd 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1687,6 +1687,15 @@ static int sdhci_do_3_3v_signal_voltage_switch(struct 
> sdhci_host *host,
>   return -EIO;
>   }
>   }
> +
> + /*
> +  * May need to apply soc/platfrom settings for the
> +  * voltage switch
> +  */
> + if (host->ops->signal_voltage_switch)
> + host->ops->signal_voltage_switch(host,
> + host->mmc->ios.signal_voltage);
> +
>   /* Wait for 5ms */
>   usleep_range(5000, 5500);
> 
> @@ -1729,6 +1738,14 @@ static int sdhci_do_1_8v_signal_voltage_switch(struct 
> sdhci_host *host,
>   ret = 0;
> 
>   if (!ret) {
> + /*
> +  * May need to apply soc/platfrom settings for the
> +  * voltage switch
> +  */
> + if (host->ops->signal_voltage_switch)
> + host->ops->signal_voltage_switch(host,
> + host->mmc->ios.signal_voltage);
> +
>   ctrl |= SDHCI_CTRL_VDD_180;
>   sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
> 

I am wondering if this is needed.  

A better way would be to install a notifier for voltage switch notification 
from the regulator in the platform code for sdhci-pxav2 or -pxav3.
When the regulator changes the voltage the notifier is called and one can tell
a) The new voltage
b) The device asking for the voltage switch (passed in via the void data 
parameter on the request notitifer)

The only issue I can see is for voltage changes that occur via a SD Host 
Controller that handles voltage changes.



> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 7c659dd..cc408c4 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -291,6 +291,7 @@ struct sdhci_ops {
>   void(*platform_suspend)(struct sdhci_host *host);
>   void(*platform_resume)(struct sdhci_host *host);
>   void(*platform_init)(struct sdhci_host *host);
> + void(*signal_voltage_switch)(struct sdhci_host *host, u8 vol);
> };
> 
> #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> -- 
> 1.7.0.4
> 

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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] sdhci: add quirk for lack of 1.8v support

[Philip Rakity]

On Nov 25, 2012, at 6:01 PM, Daniel Drake  wrote:

> The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v
> capable, and it truthfully reports so in its capabilities. This
> alternate voltage is used for driving new "UHS-I" SD cards at their
> full speed.
> 
> However, what the controller doesn't know is that the motherboard
> physically doesn't have a 1.8v supply available.
> 
> Add a quirk so that systems such as this one can override disable
> 1.8v support, adding support for UHS-I cards (by running them at
> 3.3v).
> 
> This avoids a problem where the system would first try to run the
> card at 1.8v, fail, and then not be able to fully reset the card
> to retry at the normal 3.3v voltage.
> 
> This is more appropriate than using the MISSING_CAPS quirk, which
> is intended for cases where the SDHCI controller is actually lying
> about its capabilities, and would force us to somehow override both
> caps words from another source.
> 
> Signed-off-by: Daniel Drake 
> ---
> drivers/mmc/host/sdhci.c  | 4 
> include/linux/mmc/sdhci.h | 2 ++
> 2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index c7851c0..7273523 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2865,6 +2865,10 @@ int sdhci_add_host(struct sdhci_host *host)
>   caps[1] &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
>  SDHCI_SUPPORT_DDR50);
> 
> + if (host->quirks2 & SDHCI_QUIRK2_NO_1_8_V)
> + caps[1] &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
> +SDHCI_SUPPORT_DDR50);
> +
>   /* Any UHS-I mode in caps implies SDR12 and SDR25 support. */
>   if (caps[1] & (SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
>  SDHCI_SUPPORT_DDR50))
> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
> index 1edcb4d..1a42747 100644
> --- a/include/linux/mmc/sdhci.h
> +++ b/include/linux/mmc/sdhci.h
> @@ -92,6 +92,8 @@ struct sdhci_host {
> 
> #define SDHCI_QUIRK2_HOST_OFF_CARD_ON (1<<0)
> #define SDHCI_QUIRK2_HOST_NO_CMD23(1<<1)
> +/* The system physically doesn't support 1.8v, even if the host does */
> +#define SDHCI_QUIRK2_NO_1_8_V(1<<2)
> 
>   int irq;/* Device IRQ */
>   void __iomem *ioaddr;   /* Mapped address */
> -- 
> 1.7.11.7
> 

Reviewed-by:  Philip Rakity 

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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] sdhci: add quirk for lack of 1.8v support

[Philip Rakity]

Daniel 

The same effect can be achieved by setting the quirk
SDHCI_QUIRK_MISSING_CAPS
reading caps[0] and removing from caps[1] the UHS values in the controller 
specific code for your board.

What is the reason you cannot do this ?

Philip

On Nov 25, 2012, at 6:01 PM, Daniel Drake  wrote:

> The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v
> capable, and it truthfully reports so in its capabilities. This
> alternate voltage is used for driving new "UHS-I" SD cards at their
> full speed.
> 
> However, what the controller doesn't know is that the motherboard
> physically doesn't have a 1.8v supply available.
> 
> Add a quirk so that systems such as this one can override disable
> 1.8v support, adding support for UHS-I cards (by running them at
> 3.3v).
> 
> This avoids a problem where the system would first try to run the
> card at 1.8v, fail, and then not be able to fully reset the card
> to retry at the normal 3.3v voltage.
> 
> This is more appropriate than using the MISSING_CAPS quirk, which
> is intended for cases where the SDHCI controller is actually lying
> about its capabilities, and would force us to somehow override both
> caps words from another source.
> 
> Signed-off-by: Daniel Drake 
> ---
> drivers/mmc/host/sdhci.c  | 4 
> include/linux/mmc/sdhci.h | 2 ++
> 2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index c7851c0..7273523 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2865,6 +2865,10 @@ int sdhci_add_host(struct sdhci_host *host)
>   caps[1] &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
>  SDHCI_SUPPORT_DDR50);
> 
> + if (host->quirks2 & SDHCI_QUIRK2_NO_1_8_V)
> + caps[1] &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
> +SDHCI_SUPPORT_DDR50);
> +
>   /* Any UHS-I mode in caps implies SDR12 and SDR25 support. */
>   if (caps[1] & (SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
>  SDHCI_SUPPORT_DDR50))
> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
> index 1edcb4d..1a42747 100644
> --- a/include/linux/mmc/sdhci.h
> +++ b/include/linux/mmc/sdhci.h
> @@ -92,6 +92,8 @@ struct sdhci_host {
> 
> #define SDHCI_QUIRK2_HOST_OFF_CARD_ON (1<<0)
> #define SDHCI_QUIRK2_HOST_NO_CMD23(1<<1)
> +/* The system physically doesn't support 1.8v, even if the host does */
> +#define SDHCI_QUIRK2_NO_1_8_V(1<<2)
> 
>   int irq;/* Device IRQ */
>   void __iomem *ioaddr;   /* Mapped address */
> -- 
> 1.7.11.7
> 

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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: eMMC

[Philip Rakity]

On Nov 22, 2012, at 11:26 AM, Kevin Liu  wrote:

>> From: linux-mmc-ow...@vger.kernel.org 
>> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Philip Rakity
>> Sent: Wednesday, November 21, 2012 8:42 PM
>> To: linux-mmc@vger.kernel.org
>> Subject: RFC: eMMC
>> 
>> Recently there have been a number of patches to sdhci.c and discussions on 
>> regulators for folks using eMMC.
>> 
>> I would appreciate any feedback.  The opinions below are my own.
>> 
>> eMMC is a hardware device.  It is NOT voltage configurable in any real sense 
>> other then turning on/off the voltage,
>> The board designer is supposed to read the data sheet and hook things up.  
>> It is somewhat unclear to me how having a dummy regulator really helps.
>> 
> But if the system enabled dummy regulator, regulator_get will return a
> dummy regulator if vmmc/vmmcq not found.
> So we had better take dummy regulator into consideration.
> 
>> Given that -- voltage checking for vmmc or vmmcq is not meaningful. eMMC 
>> either works or does not.
>> The testing for vccq/vcc has no meaning since it cannot be changed.  In fact 
>> the samsung eMMC we used for DDR worked at 2.8v.
> 
> You set the vmmcq regulator to 2.8v while enable the 1.8v signaling
> enable bit in host control 2 register.
> It's mismatch in logic. But it's good to make DDR50 work under 2.8v(3v).
> The reason for this working is the 1.8v signaling enable bit does NOT
> control actual signal voltage at all.
> In your case, although the 1.8v bit is set, the signal voltage for
> both mmc host and emmc chip vmmcq is still 2.8v. Because the actual
> signal voltage is controlled by external regulator whose voltage is
> not changed.
> So DDR50 can keep working since DDR50 support both 1.8v and 3v.

There is no mismatch in logic. The samsung datas sheet says it will work.
No external regulators are used.  vmmc and vmmvq are not NULL.
> 
>> Given this -- we have a chicken and egg situation in sdhci.c
>> if we are in this code and the kernel was on eMMC obviously the system is 
>> working.
>> If we booted the kernel from say SPI then hopefully the boot code has set up 
>> the voltage rails correctly.
>> I would argue that for eMMC the regulator structure should not be exposed to 
>> sdhci.c and everything would just work.
>> 
> The easy way is just not register vmmc/vmmcq regulator for emmc, right?
> 
>> SD/UHS cards are a completely different matter and regulators make complete 
>> sense.

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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: eMMC

[Philip Rakity]

On Nov 22, 2012, at 11:44 AM, Kevin Liu  wrote:

> 2012/11/22 Philip Rakity :
>> 
>> On Nov 22, 2012, at 11:26 AM, Kevin Liu  wrote:
>> 
>>>> From: linux-mmc-ow...@vger.kernel.org 
>>>> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Philip Rakity
>>>> Sent: Wednesday, November 21, 2012 8:42 PM
>>>> To: linux-mmc@vger.kernel.org
>>>> Subject: RFC: eMMC
>>>> 
>>>> Recently there have been a number of patches to sdhci.c and discussions on 
>>>> regulators for folks using eMMC.
>>>> 
>>>> I would appreciate any feedback.  The opinions below are my own.
>>>> 
>>>> eMMC is a hardware device.  It is NOT voltage configurable in any real 
>>>> sense other then turning on/off the voltage,
>>>> The board designer is supposed to read the data sheet and hook things up.  
>>>> It is somewhat unclear to me how having a dummy regulator really helps.
>>>> 
>>> But if the system enabled dummy regulator, regulator_get will return a
>>> dummy regulator if vmmc/vmmcq not found.
>>> So we had better take dummy regulator into consideration.
>>> 
>>>> Given that -- voltage checking for vmmc or vmmcq is not meaningful. eMMC 
>>>> either works or does not.
>>>> The testing for vccq/vcc has no meaning since it cannot be changed.  In 
>>>> fact the samsung eMMC we used for DDR worked at 2.8v.
>>> 
>>> You set the vmmcq regulator to 2.8v while enable the 1.8v signaling
>>> enable bit in host control 2 register.
>>> It's mismatch in logic. But it's good to make DDR50 work under 2.8v(3v).
>>> The reason for this working is the 1.8v signaling enable bit does NOT
>>> control actual signal voltage at all.
>>> In your case, although the 1.8v bit is set, the signal voltage for
>>> both mmc host and emmc chip vmmcq is still 2.8v. Because the actual
>>> signal voltage is controlled by external regulator whose voltage is
>>> not changed.
>>> So DDR50 can keep working since DDR50 support both 1.8v and 3v.
>> 
>> There is no mismatch in logic. The samsung datas sheet says it will work.
>> No external regulators are used.  vmmc and vmmvq are not NULL.
> 
> The mismatch here I mean you set 1.8v as signal voltage but actually
> you use 2.8v. For the host controller, it's mismatch.
> 

This is why I added the callback in shdci.c to handle broken controllers.

> I don't understand "No external regulators are used.  vmmc and vmmvq
> are not NULL".
> vmmc and vmmcq regulator exist or not?
> 
>>> 
>>>> Given this -- we have a chicken and egg situation in sdhci.c
>>>> if we are in this code and the kernel was on eMMC obviously the system is 
>>>> working.
>>>> If we booted the kernel from say SPI then hopefully the boot code has set 
>>>> up the voltage rails correctly.
>>>> I would argue that for eMMC the regulator structure should not be exposed 
>>>> to sdhci.c and everything would just work.
>>>> 
>>> The easy way is just not register vmmc/vmmcq regulator for emmc, right?
>>> 
>>>> SD/UHS cards are a completely different matter and regulators make 
>>>> complete sense.
>> 

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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

RFC: eMMC

[Philip Rakity]

Recently there have been a number of patches to sdhci.c and discussions on 
regulators for folks using eMMC.

I would appreciate any feedback.  The opinions below are my own.

eMMC is a hardware device.  It is NOT voltage configurable in any real sense 
other then turning on/off the voltage,
The board designer is supposed to read the data sheet and hook things up.  It 
is somewhat unclear to me how having a dummy regulator really helps.

Given that -- voltage checking for vmmc or vmmcq is not meaningful. eMMC either 
works or does not.
The testing for vccq/vcc has no meaning since it cannot be changed.  In fact 
the samsung eMMC we used for DDR worked at 2.8v.
Given this -- we have a chicken and egg situation in sdhci.c
if we are in this code and the kernel was on eMMC obviously the system is 
working.
If we booted the kernel from say SPI then hopefully the boot code has set up 
the voltage rails correctly.
I would argue that for eMMC the regulator structure should not be exposed to 
sdhci.c and everything would just work.

SD/UHS cards are a completely different matter and regulators make complete 
sense.
---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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: UHS-I voltage switching on OLPC XO-1.75

[Philip Rakity]

On Nov 18, 2012, at 5:42 PM, Daniel Drake  wrote:

> On Fri, Nov 2, 2012 at 8:35 AM, Johan Rudholm  wrote:
>> Good question. I’d guess that mmc_power_off/up does not work as
>> expected here, that the card is not at all power cycled.
> 
> Before going further on the "find a way to quirk it" route, there is
> something else we could look into.
> 
> According to our hardware engineers, the external SD card power has
> been "always-on" until now. It is actually controlled by our embedded
> controller, separate from the CPU.
> 
> In a test firmware, I can now control the SD card power via our "OLPC
> EC" interface, I call into that from mmc_power_up and mmc_power_down.
> And, with your hacky patch to make the voltage switch failure
> detection work, this fixes it: it tries 10 times at 1.8v then falls
> back to 3.3 successfully. No more problems with the power cycle.
> 
> So we have the option of fixing it that way: if we can fix the voltage
> switch failure detection, we could implement a custom vmmc regulator
> driver that uses our EC interface to enable and disable the SD power
> appropriately, solving our ability to power cycle.
> 
> On the other hand, we may have a good basis to add a quirk, triggered
> by the device tree, for when the hardware physically does not have
> 1.8v capabilities.
> 
> I'm also curious if there is a 3rd option. It seems like in the case
> of our SoC, the SoC design mandates that the SD card power is separate
> from the SDHCI interface - requiring either a GPIO or some other
> mechanism (e.g. OLPC EC) to be able to control it.
> 
> I'm wondering if this is the same for all sdhci-pxa devices. And the
> same for all sdhci devices? Maybe the SDHCI specs would help here, but
> I guess they aren't public.
> 
> If this is the case, the driver could have another heuristic: if there
> is no vmmc regulator, there is no way of cutting the card power,
> therefore we could avoid even trying 1.8v on the basis that we know we
> can't recover if things go wrong.
> 
> Similarly, for our next product we are looking at adding 1.8v
> capabilities. However, it seems that again, the SoC design (or
> something more fundamental?) requires that this power is controlled
> via some external mechanism - we're planning to use a GPIO to switch
> between 1.8v and 3.3v, which can be exposed as a regulator. So again,
> would it be fair for sdhci-pxa or sdhci to drop the UHS-I support when
> no regulator is present? Or am I over-generalizing?

You can use a notifier to get control when voltage switch is called in your low 
level board file.
I did this originally to control PAD settings for 3.3 and 1.8v.  I had the 
receiver of the notifier in my low level board file and I registered it my 
sdhci-xxx.c file.
The notified is called at the end of the voltage switch by the regulator code 
but maybe there is now a case to add notifier control at the beginning of the 
routines.

> 
> Thanks,
> Daniel
> --
> 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

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Philip Rakity]

On Nov 14, 2012, at 8:57 AM, Kevin Liu  wrote:

> 2012/11/14 Mark Brown :
>> On Wed, Nov 14, 2012 at 04:36:28PM +0800, Kevin Liu wrote:
>>> 2012/11/14 Mark Brown :
>> 
>>>> Should this be regulator_set_voltage_tol()?  Otherwise it'd be good to
>>>> explain where the numbers come from.
>> 
>>> In SD physical layer spec 3.01 chapter 6.6.1, the threshold level for
>>> voltage range is defined as below:
>>> Vdd(min) = 2.7V while Vdd(max) = 3.6V.
>>> The card should work within the voltage range.
>> 
>>> If you are afraid the voltage value is too aggressive, maybe we can
>>> use regulator_set_voltage_tol() to set a smaller range.
>>> But which range should be reasonable?
>> 
>> The above makes total sense - thanks!  I just wasn't aware that the
>> range was specified in this fashion in the spec.  Might be worth a
>> comment in the code if you need to respin.
> 
> Sure, I will update the patch. Thanks!
> --
> 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-read spec.  Please apply Kevin;s patch.

Reviewed-by: Philip Rakity 
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Philip Rakity]

Hi Marek,

Is the regulator dedicated ?  or is it shared ?   Is it used for eMMC ?

If it cannot be turned off -- then just don't list it in the regulators list 
for vmmc.  

If it CAN be turned off then need to get back to you.

Philip 

On Nov 13, 2012, at 2:14 PM, Chris Ball  wrote:

> 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?
> 
> 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: UHS-I voltage switching on OLPC XO-1.75

[Philip Rakity]

On Nov 8, 2012, at 7:03 PM, Philip Rakity  wrote:

> Don't know enough about the device tree to help.  Originally I suggested a 
> quirk simular to what you are suggesting but it was felt to be too specific 
> since the bits in caps2 achieve the same effect.  Maybe your board specific 
> code can check if the regulator is capable of switching and can be turned on 
> and off.  Not sure how to do the later.  Checking the usage count does not 
> help.  You want exclusive access.  Mark Brown might know how to do this else 
> perhaps the regulator framework needs extending.

upon reflection you can configure the regulator supply with the name of the 
specific device.  That should make it exclusive to the mmc subsystem.  In the 
general case I do not know how one can test for this (in say sdhci.c).
> 
> - Reply message -
> From: "Daniel Drake" 
> To: "Philip Rakity" 
> Cc: "Johan Rudholm" , "Chris Ball" , 
> "linux-mmc@vger.kernel.org" 
> Subject: UHS-I voltage switching on OLPC XO-1.75
> Date: Thu, Nov 8, 2012 19:52
> 
> 
> 
> On Thu, Nov 8, 2012 at 12:48 PM, Philip Rakity  wrote:
> > This is already there.  Use broken caps and in the board code clear out the
> > nits in caps2.
> 
> There is no board code; we're working with device tree. So I'm still
> not exactly clear on the best way to work this.
> 
> Maybe something like this: "sdhci,disable-1-8v" property in the device
> tree, would trigger the sdhci-pxa2 code to:
> 1. sdhci_readl() to retrieve caps and caps1
> 2. Drop the 1.8v flag from caps1
> 3. Set the BROKEN_CAPS quirk
> 
> It would work but I'm not too fond of it, and I can't really think of
> an approach I do like (except maybe having a specific "1.8v broken"
> sdhci quirk).
> 
> Daniel

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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: UHS-I voltage switching on OLPC XO-1.75

[Philip Rakity]

On Nov 5, 2012, at 1:11 PM, Chris Ball  wrote:

> Hi,
> 
> On Mon, Nov 05 2012, Philip Rakity wrote:
>> Hi Daneil, Chris,
>> 
>> I reviewed kevin's patch in September which fixes this issue.  Chris
>> -- can we pull it into mmc-next ?  This patch is okay as a standalone
>> change.

That was the original intent.

The question is what to do if no regulator.  regulator_get was returning NULL 
in Daniel;s case.
IS_ERR patch was not taken so UHS support was removed.  
The intent of the original code was to remove UHS support if there was a 
regulator but it could not support voltage switching.

Phlip

>> 
>> From: Philip Rakity  marvell.com>
>> Subject: Re: [PATCH v2 5/8] mmc: sdhci: fix null return check of 
>> regulator_get
>> Newsgroups: gmane.linux.kernel.mmc
>> Date: 2012-09-24 15:02:34 GMT (5 weeks, 6 days, 21 hours and 44 minutes ago)
> 
> It sounds like I misread this patch, then -- I understood it as only
> affecting whether a pr_info() call is made, which would not fix a
> voltage switching bug.  What am I missing?  (Dan, here's a copy of
> Kevin's patch.)
> 
> 
> From: Kevin Liu 
> 
> regulator_get() returns NULL when CONFIG_REGULATOR not defined,
> which should not print out the warning.
> 
> Reviewed-by: Philip Rakity 
> Signed-off-by: Bin Wang 
> Signed-off-by: Kevin Liu 
> ---
> drivers/mmc/host/sdhci.c |   18 --
> 1 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 8e6a6f0..0104ae9 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2845,9 +2845,12 @@ int sdhci_add_host(struct sdhci_host *host)
> 
>   /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
>   host->vqmmc = regulator_get(mmc_dev(mmc), "vqmmc");
> - if (IS_ERR(host->vqmmc)) {
> - pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> - host->vqmmc = NULL;
> + if (IS_ERR_OR_NULL(host->vqmmc)) {
> + if (PTR_ERR(host->vqmmc) < 0) {
> + pr_info("%s: no vqmmc regulator found\n",
> + mmc_hostname(mmc));
> + host->vqmmc = NULL;
> + }
>   }
>   else if (regulator_is_supported_voltage(host->vqmmc, 180, 180))
>   regulator_enable(host->vqmmc);
> @@ -2903,9 +2906,12 @@ int sdhci_add_host(struct sdhci_host *host)
>   ocr_avail = 0;
> 
>   host->vmmc = regulator_get(mmc_dev(mmc), "vmmc");
> - if (IS_ERR(host->vmmc)) {
> - pr_info("%s: no vmmc regulator found\n", mmc_hostname(mmc));
> - host->vmmc = NULL;
> + if (IS_ERR_OR_NULL(host->vmmc)) {
> + if (PTR_ERR(host->vmmc) < 0) {
> + pr_info("%s: no vmmc regulator found\n",
> + mmc_hostname(mmc));
> + host->vmmc = NULL;
> + }
>   } else
>   regulator_enable(host->vmmc);
> 
> -- 
> Chris Ball  <http://printf.net/>
> One Laptop Per Child

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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: UHS-I voltage switching on OLPC XO-1.75

[Philip Rakity]

Hi Daneil, Chris,

I reviewed kevin's patch in September which fixes this issue.  Chris -- can we 
pull it into mmc-next ?  This patch is okay as a standalone change.

From: Philip Rakity  marvell.com>
Subject: Re: [PATCH v2 5/8] mmc: sdhci: fix null return check of regulator_get
Newsgroups: gmane.linux.kernel.mmc
Date: 2012-09-24 15:02:34 GMT (5 weeks, 6 days, 21 hours and 44 minutes ago)

Philip

On Oct 30, 2012, at 9:11 PM, Daniel Drake  wrote:

> Hi,
> 
> Following on from the recent thread
> [PATCH 2/2] mmc: core: Power cycle card on voltage switch fail
> I have tried to get a better grip on the problems being faced.
> 
> Test setup:
> OLPC XO-1.75 laptop, based on Marvell MMP2 ARM SoC (includes sdhci-pxa
> interface)
> 32GB Sandisk Ultra SD card being inserted into external SD slot
> 
> The SoC apparently has support for 1.8V, but we physically do not have
> the right power lines wired on the motherboard, so we need to detect
> the 1.8V failure and go back to 3.3V mode.
> 
> Before patching anything, inserting this card results in:
> sdhci: Switching to 1.8V signalling voltage failed, retrying with
> S18R set to 0
> mmc0: error -110 whilst initialising SD card
> 
> Now, working on Linux-3.5.4, I add these patches:
> 
>  mmc: core: reset sigal voltage on power up
>  [RFC/PATCH,v2] mmc: core: Fixup signal voltage switch
>  regulator: add missing defintion regulator_is_supported_voltage
>  mmc: sdhci: Add regulator support for vccq (voltage regualor)
>  mmc: sdhci: Let core handle UHS switch failure
> 
> I also tweaked the sdhci code so that UHS-I flags are not
> unconditionally disabled by the vccq commit (as explained in "sdhci
> vccq regulator support drops UHS-I flags").
> 
> 
> Under this setup, the first problem encountered is that the system no
> longer identifies the fact that the 1.8V voltage failed. Things are
> not happy afterwards. The card_busy check in sdhci is saying that the
> card is not busy.
> Full kernel logs: http://dev.laptop.org/~dsd/20121030/mmc1.log
> 
> I tracked down what causes this regression. In order to get the
> failure detection working again, I have to make the following change
> in mmc_set_signal_voltage():
>  if (cmd11) {
>  host->ios.clock = 0;
> -   mmc_set_ios(host);
> +   //mmc_set_ios(host);
>  }
> (i.e. don't mess with ios before asking sdhci to do the voltage switch)
> 
> and at the top of sdhci_do_1_8v_signal_voltage_switch:
> +   /* Stop SDCLK */
> +   clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> +   clk &= ~SDHCI_CLOCK_CARD_EN;
> +   sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> (i.e. add the equivalent clock disabling code here)
> 
> 
> With that change, I now get:
> mmc2: Signal voltage switch failed, power cycling card (retries = 10)
> mmc2: error -110 whilst initialising SD card
> 
> The -110 error comes from mmc_send_app_op_cond(), but its worth noting
> that mmc_send_if_cond() (called immediately above) silently failed
> with -110 too. Neither of these failed the first time around before
> 1.8V was tried.
> 
> Full patch that I'm testing with: 
> http://dev.laptop.org/~dsd/20121030/mmc.patch
> 
> So, now the question is: why is the card not responding to
> if_cond/app_op_cond after being powered down and up again? Is the
> power down/up sequence OK?
> I tried inserting the mmc_power_off, mmc_power_up, mmc_send_if_cond
> sequence into various points in the codepaths being discussed.
> Measuring success as the card responding to mmc_send_if_cond(0x30080)
> without error (0x30080 is a known good value from when before 1.8V is
> tried), I find that this "reset sequence" works just fine up until the
> point when CMD11 is run.
> CMD11 is sent and returns successfully without error, but from this
> point, running the reset sequence will fail (send_if_cond will fail
> with -110).
> 
> Is this kind of test valid? Does this suggest that something is wrong
> with the host controller hardware? My assumption is that whatever
> state is modified by CMD11 should be erased here, and of course the
> hope is that mmc_power_off and mmc_power_up will do a full power cycle
> anyway. But whatever is happening, it looks like the effects of CMD11
> are persisting past the reset sequence and are breaking later
> communication.
> 
> In the mail last week, I think we found some kind of configuration (on
> Linux-3.0) where this same setup successfully detected the 1.8V
> switching failure, and successfully switched back to 3.3V. I plan to
> go back and test that, maybe there is some kind of sequence that
> doesn't make the hardware die.
> 
&g

Re: UHS-I voltage switching on OLPC XO-1.75

[Philip Rakity]

Hi Daneil, Chris,

I reviewed kevin's patch in September which fixes this issue.  Chris -- can we 
pull it into mmc-next ?  This patch is okay as a standalone change.

From: Philip Rakity  marvell.com>
Subject: Re: [PATCH v2 5/8] mmc: sdhci: fix null return check of regulator_get
Newsgroups: gmane.linux.kernel.mmc
Date: 2012-09-24 15:02:34 GMT (5 weeks, 6 days, 21 hours and 44 minutes ago)

Philip

On Oct 30, 2012, at 9:11 PM, Daniel Drake  wrote:

> Hi,
> 
> Following on from the recent thread
>  [PATCH 2/2] mmc: core: Power cycle card on voltage switch fail
> I have tried to get a better grip on the problems being faced.
> 
> Test setup:
> OLPC XO-1.75 laptop, based on Marvell MMP2 ARM SoC (includes sdhci-pxa
> interface)
> 32GB Sandisk Ultra SD card being inserted into external SD slot
> 
> The SoC apparently has support for 1.8V, but we physically do not have
> the right power lines wired on the motherboard, so we need to detect
> the 1.8V failure and go back to 3.3V mode.
> 
> Before patching anything, inserting this card results in:
>  sdhci: Switching to 1.8V signalling voltage failed, retrying with
> S18R set to 0
>  mmc0: error -110 whilst initialising SD card
> 
> Now, working on Linux-3.5.4, I add these patches:
> 
>mmc: core: reset sigal voltage on power up
>[RFC/PATCH,v2] mmc: core: Fixup signal voltage switch
>regulator: add missing defintion regulator_is_supported_voltage
>mmc: sdhci: Add regulator support for vccq (voltage regualor)
>mmc: sdhci: Let core handle UHS switch failure
> 
> I also tweaked the sdhci code so that UHS-I flags are not
> unconditionally disabled by the vccq commit (as explained in "sdhci
> vccq regulator support drops UHS-I flags").
> 
> 
> Under this setup, the first problem encountered is that the system no
> longer identifies the fact that the 1.8V voltage failed. Things are
> not happy afterwards. The card_busy check in sdhci is saying that the
> card is not busy.
> Full kernel logs: http://dev.laptop.org/~dsd/20121030/mmc1.log
> 
> I tracked down what causes this regression. In order to get the
> failure detection working again, I have to make the following change
> in mmc_set_signal_voltage():
>if (cmd11) {
>host->ios.clock = 0;
> -   mmc_set_ios(host);
> +   //mmc_set_ios(host);
>}
> (i.e. don't mess with ios before asking sdhci to do the voltage switch)
> 
> and at the top of sdhci_do_1_8v_signal_voltage_switch:
> +   /* Stop SDCLK */
> +   clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> +   clk &= ~SDHCI_CLOCK_CARD_EN;
> +   sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> (i.e. add the equivalent clock disabling code here)
> 
> 
> With that change, I now get:
>  mmc2: Signal voltage switch failed, power cycling card (retries = 10)
>  mmc2: error -110 whilst initialising SD card
> 
> The -110 error comes from mmc_send_app_op_cond(), but its worth noting
> that mmc_send_if_cond() (called immediately above) silently failed
> with -110 too. Neither of these failed the first time around before
> 1.8V was tried.
> 
> Full patch that I'm testing with: 
> http://dev.laptop.org/~dsd/20121030/mmc.patch
> 
> So, now the question is: why is the card not responding to
> if_cond/app_op_cond after being powered down and up again? Is the
> power down/up sequence OK?
> I tried inserting the mmc_power_off, mmc_power_up, mmc_send_if_cond
> sequence into various points in the codepaths being discussed.
> Measuring success as the card responding to mmc_send_if_cond(0x30080)
> without error (0x30080 is a known good value from when before 1.8V is
> tried), I find that this "reset sequence" works just fine up until the
> point when CMD11 is run.
> CMD11 is sent and returns successfully without error, but from this
> point, running the reset sequence will fail (send_if_cond will fail
> with -110).
> 
> Is this kind of test valid? Does this suggest that something is wrong
> with the host controller hardware? My assumption is that whatever
> state is modified by CMD11 should be erased here, and of course the
> hope is that mmc_power_off and mmc_power_up will do a full power cycle
> anyway. But whatever is happening, it looks like the effects of CMD11
> are persisting past the reset sequence and are breaking later
> communication.
> 
> In the mail last week, I think we found some kind of configuration (on
> Linux-3.0) where this same setup successfully detected the 1.8V
> switching failure, and successfully switched back to 3.3V. I plan to
> go back and test that, maybe there is some kind of sequence that
> doesn't make the ha

Re: UHS-I voltage switching on OLPC XO-1.75

[Philip Rakity]

On Nov 2, 2012, at 2:35 PM, Johan Rudholm  wrote:

> Hi Daniel,
> 
> 2012/10/30 Daniel Drake :
>> Hi,
>> 
>> Following on from the recent thread
>>  [PATCH 2/2] mmc: core: Power cycle card on voltage switch fail
>> I have tried to get a better grip on the problems being faced.
>> 
>> Test setup:
>> OLPC XO-1.75 laptop, based on Marvell MMP2 ARM SoC (includes sdhci-pxa
>> interface)
>> 32GB Sandisk Ultra SD card being inserted into external SD slot
>> 
>> The SoC apparently has support for 1.8V, but we physically do not have
>> the right power lines wired on the motherboard, so we need to detect
>> the 1.8V failure and go back to 3.3V mode.
> 
> An initial question, would it be possible to solve this by disabling
> the UHS support in the host cap, or through a quirk? Maybe this kind
> of solution is not applicable in this scenario? I wonder this because
> I guess it will be very hard to know how a card will react if we first
> tell it that we're going to switch voltages and then don't, since this
> is out of spec.
> 

I submitted a patch a while ago that allows the board specific code to change 
host->caps2
The controller may indicate support for UHS but the board design can prohibit 
this.

>> I tracked down what causes this regression. In order to get the
>> failure detection working again, I have to make the following change
>> in mmc_set_signal_voltage():
>>if (cmd11) {
>>host->ios.clock = 0;
>> -   mmc_set_ios(host);
>> +   //mmc_set_ios(host);
>>}
>> (i.e. don't mess with ios before asking sdhci to do the voltage switch)
>> 
>> and at the top of sdhci_do_1_8v_signal_voltage_switch:
>> +   /* Stop SDCLK */
>> +   clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
>> +   clk &= ~SDHCI_CLOCK_CARD_EN;
>> +   sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
>> (i.e. add the equivalent clock disabling code here)
> 
> Ok, so this suggests that the SDHCI driver does not stop the clock
> when we set ios.clock = 0 and call mmc_set_ios?
> 
>> With that change, I now get:
>>  mmc2: Signal voltage switch failed, power cycling card (retries = 10)
>>  mmc2: error -110 whilst initialising SD card
>> 
>> The -110 error comes from mmc_send_app_op_cond(), but its worth noting
>> that mmc_send_if_cond() (called immediately above) silently failed
>> with -110 too. Neither of these failed the first time around before
>> 1.8V was tried.
>> 
>> Full patch that I'm testing with: 
>> http://dev.laptop.org/~dsd/20121030/mmc.patch
>> 
>> So, now the question is: why is the card not responding to
>> if_cond/app_op_cond after being powered down and up again? Is the
>> power down/up sequence OK?
> 
> Good question. I’d guess that mmc_power_off/up does not work as
> expected here, that the card is not at all power cycled. But it seems
> that the power cycle code in sdhci_do_start_signal_voltage_switch
> works? What if we export a couple of debug functions from sdhci.c
> which allow us to power cycle and control the clock just like sdhci
> does, and call these functions from core.c and sd.c? If this works
> (and the failure is detected properly by the core layer, and 10
> retries are made etc), then we know that the problems most likely
> depend on how mmc_set_ios and mmc_power_off/up work with sdhci. I've
> attached a patch suggesting this, if you'd like to give it a try
> (warning: the patch has not been tested). The patch does not do
> anything about pm_runtime, but perhaps we don't need to worry about
> this here.
> 
>> I tried inserting the mmc_power_off, mmc_power_up, mmc_send_if_cond
>> sequence into various points in the codepaths being discussed.
>> Measuring success as the card responding to mmc_send_if_cond(0x30080)
>> without error (0x30080 is a known good value from when before 1.8V is
>> tried), I find that this "reset sequence" works just fine up until the
>> point when CMD11 is run.
>> CMD11 is sent and returns successfully without error, but from this
>> point, running the reset sequence will fail (send_if_cond will fail
>> with -110).
>> 
>> Is this kind of test valid? Does this suggest that something is wrong
>> with the host controller hardware? My assumption is that whatever
>> state is modified by CMD11 should be erased here, and of course the
>> hope is that mmc_power_off and mmc_power_up will do a full power cycle
>> anyway. But whatever is happening, it looks like the effects of CMD11
>> are persisting past the reset sequence and are breaking later
>> communication.
> 
> I think that the power cycle has simply failed here, I find it hard to
> believe that CMD11 has persistent effects :) If mmc_power_off/up
> actually works, then perhaps the 1ms udelay is too small for this
> case?
> 
> Kind regards, Johan
> <0001-Clock-and-power-control.patch>

---
This email message is for the sole use of the intended recipient(s) and may 
con

Re: sdhci vccq regulator support drops UHS-I flags

[Philip Rakity]

The intent is if there is no regulator should hit this if statement.

+   if (IS_ERR(host->vqmmc)) {
+   pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
+   host->vqmmc = NULL;


On Oct 30, 2012, at 9:56 PM, Daniel Drake  wrote:

> On Tue, Oct 30, 2012 at 2:37 PM, Philip Rakity  wrote:
>> Intentional.
>> 
>> if no vqmmc regulator then just assume it will work.
> 
> When you say "it", do you mean "UHS-I support"?
> The code in this case will *disable* UHS-I support, because these lines are 
> hit.
> +   caps[1] &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
> +  SDHCI_SUPPORT_DDR50);
> 
>> if there is a regulator it needs to support 1.8V.  (If I remember correctly 
>> UHS mode require 1.8V vccq)  I need to check if we 1.2V should be allowed 
>> but it was not in the spec that I had.
> 
> I'm asking about the case when there is no regulator.
> 
> Thanks
> Daniel

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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: sdhci vccq regulator support drops UHS-I flags

[Philip Rakity]

Hi Daniel,

Intentional.  

if no vqmmc regulator then just assume it will work.

if there is a regulator it needs to support 1.8V.  (If I remember correctly UHS 
mode require 1.8V vccq)  I need to check if we 1.2V should be allowed but it 
was not in the spec that I had.

Are you thinking we need 1.2V support ?  

regards,

Philip


On Oct 30, 2012, at 9:30 PM, Daniel Drake  wrote:

> Hi,
> 
> Please check this commit:
> 
> 
> commit 6231f3de1332b2a8a90e0c598ab6acc8f1eff7c1
> Author: Philip Rakity 
> Date:   Mon Jul 23 15:56:23 2012 -0700
> 
>mmc: sdhci: Add regulator support for vccq (voltage regualor)
> 
> Particularly this hunk:
> 
> +   /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
> +   host->vqmmc = regulator_get(mmc_dev(mmc), "vqmmc");
> +   if (IS_ERR(host->vqmmc)) {
> +   pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> +   host->vqmmc = NULL;
> +   }
> +   else if (regulator_is_supported_voltage(host->vqmmc, 180, 
> 180))
> +   regulator_enable(host->vqmmc);
> +   else
> +   caps[1] &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
> +  SDHCI_SUPPORT_DDR50);
> 
> One effect of this code is that if the system has no vqmmc regulator,
> the UHS-I flags are always cleared on the final line, so the ultra
> speed mode is always disabled.
> 
> Is this intentional or is there a check missing?
> 
> Thanks
> Daniel

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: core: debugfs: Add signal_voltage to ios dump

[Philip Rakity]

On Oct 26, 2012, at 11:31 AM, Johan Rudholm  
wrote:

> Signed-off-by: Johan Rudholm 
> ---
> drivers/mmc/core/debugfs.c |   16 
> 1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
> index d96c643..35c2f85 100644
> --- a/drivers/mmc/core/debugfs.c
> +++ b/drivers/mmc/core/debugfs.c
> @@ -144,6 +144,22 @@ static int mmc_ios_show(struct seq_file *s, void *data)
>   }
>   seq_printf(s, "timing spec:\t%u (%s)\n", ios->timing, str);
> 
> + switch (ios->signal_voltage) {
> + case MMC_SIGNAL_VOLTAGE_330:
> + str = "3.30 V";
> + break;
> + case MMC_SIGNAL_VOLTAGE_180:
> + str = "1.80 V";
> + break;
> + case MMC_SIGNAL_VOLTAGE_120:
> + str = "1.20 V";
> + break;
> + default:
> + str = "invalid";

would "is unknown"  be a better str ?
> +     break;
> + }
> + seq_printf(s, "signal voltage:\t%u (%s)\n", ios->chip_select, str);
> +
>   return 0;
> }
> 
Reviewed-by: Philip Rakity 
> -- 
> 1.7.10
> 
> --
> 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

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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 2/2] mmc: sdhci: Defer probe if regulator_get fails

[Philip Rakity]

On 23 Oct 2012, at 09:19, Pavan Kunapuli  wrote:

> vmmc and vqmmc regulators control the voltage to
> the host and device. Defer the probe if either of
> them is not registered.
> 
> Signed-off-by: Pavan Kunapuli 
> ---
> drivers/mmc/host/sdhci.c |   25 ++---
> 1 files changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 7922adb..925c403 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2844,11 +2844,17 @@ int sdhci_add_host(struct sdhci_host *host)
>   !(host->mmc->caps & MMC_CAP_NONREMOVABLE))
>   mmc->caps |= MMC_CAP_NEEDS_POLL;
> 
> - /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
> + /*
> +  * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
> +  * vqmmc regulator should be present. If it's not present,
> +  * assume the regulator driver registration is not yet done and
> +  * defer the probe.
> +  */
>   host->vqmmc = regulator_get(mmc_dev(mmc), "vqmmc");
>   if (IS_ERR(host->vqmmc)) {
> - pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> + pr_err("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
>   host->vqmmc = NULL;
> + return -EPROBE_DEFER;

Some systems exist where vmmc regulator exists and vqmmc regulator does not.  
The vmmc regular is fixed at 3.3v.  
Deferring the probe will cause issues.

>   }
>   else if (regulator_is_supported_voltage(host->vqmmc, 180, 180))
>   regulator_enable(host->vqmmc);
> @@ -2903,10 +2909,17 @@ int sdhci_add_host(struct sdhci_host *host)
> 
>   ocr_avail = 0;
> 
> + /*
> +  * vmmc regulator should be present. If it's not present,
> +  * assume the regulator driver registration is not yet done
> +  * and defer the probe.
> +  */
>   host->vmmc = regulator_get(mmc_dev(mmc), "vmmc");
>   if (IS_ERR(host->vmmc)) {
> - pr_info("%s: no vmmc regulator found\n", mmc_hostname(mmc));
> + pr_err("%s: no vmmc regulator found\n", mmc_hostname(mmc));
>   host->vmmc = NULL;
> + ret = -EPROBE_DEFER;
> + goto vmmc_err;
>   } else
>   regulator_enable(host->vmmc);
> 
> @@ -3121,7 +3134,13 @@ reset:
> untasklet:
>   tasklet_kill(&host->card_tasklet);
>   tasklet_kill(&host->finish_tasklet);
> +vmmc_err:
> + if (host->vqmmc) {
> + if (regulator_is_enabled(host->vqmmc))
> + regulator_disable(host->vqmmc);
> 
> + regulator_put(host->vqmmc);
> + }
>   return ret;
> }
> 
> -- 
> 1.7.1.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

--
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: core: bus.c: removed unnecessary NULL check for kfree(...)

[Philip Rakity]

On 19 Oct 2012, at 14:58, Sangho Yi  wrote:

> kfree(NULL) is safe so I removed the if statements for NULL check.
> 
> Signed-off-by: Sangho Yi 
> ---
> drivers/mmc/core/bus.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> index 9b68933..420cb67 100644
> --- a/drivers/mmc/core/bus.c
> +++ b/drivers/mmc/core/bus.c
> @@ -225,8 +225,7 @@ static void mmc_release_card(struct device *dev)
> 
>   sdio_free_common_cis(card);
> 
> - if (card->info)
> - kfree(card->info);
> + kfree(card->info);
> 
>   kfree(card);
> }
> -- 
> 1.7.9.5

Reviewed-by: Philip Rakity 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] drivers: mmc: core: sdio.c: fixed coding style error on for() statement

[Philip Rakity]

On 18 Oct 2012, at 17:06, Sangho Yi  wrote:

> add a whitespace after ";" on for statement, to follow a coding style 
> guideline.
> 
> Signed-off-by: Sangho Yi 
> ---
> drivers/mmc/core/sdio.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index 14326e8..df09b63 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -819,7 +819,7 @@ static void mmc_sdio_remove(struct mmc_host *host)
>   BUG_ON(!host);
>   BUG_ON(!host->card);
> 
> - for (i = 0;i < host->card->sdio_funcs;i++) {
> + for (i = 0; i < host->card->sdio_funcs; i++) {
>   if (host->card->sdio_func[i]) {
>   sdio_remove_func(host->card->sdio_func[i]);
>   host->card->sdio_func[i] = NULL;
> @@ -1151,7 +1151,7 @@ int mmc_attach_sdio(struct mmc_host *host)
>   /*
>* ...then the SDIO functions.
>*/
> - for (i = 0;i < funcs;i++) {
> + for (i = 0; i < funcs; i++) {
>   err = sdio_add_func(host->card->sdio_func[i]);
>   if (err)
>   goto remove_added;
> -- 
> 1.7.9.5
> 
> --

Reviewed-by: Philip Rakity 

> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mmc: core: Support all MMC capabilities when booting from Device Tree

[Philip Rakity]

On 17 Oct 2012, at 14:38, Arnd Bergmann  wrote:

> On Monday 15 October 2012, Lee Jones wrote:
>>> and so on. What are you actually missing in the properties that
>>> are already there?
>> 
>> MMC_CAP_ERASE
> 
> This one seems to be set unconditionally on some controllers but
> not on others. Why would it need to be configurable?
> 
>> MMC_CAP_UHS_SDR12
>> MMC_CAP_UHS_SDR25
>> MMC_CAP_UHS_DDR50
> 
> Could this be derived from max-frequency?

The problem is the controller may signal it supports DDR but the host cannot.  
For example no voltage at correct level.
Same issue with 8 bit support.  Controller could say supports it but board has 
only 4 "wires"
> 
>> MMC_CAP_1_8V_DDR
> 
> Right, I suppose we need this. Should we have a minimum and maximum
> voltage added to the common properties for this?
> 
>> MMC_CAP2_DETECT_ON_ERR
>> MMC_CAP2_NO_SLEEP_CMD
> 
> I don't see these ones being set anywhere, but they were both
> added by Ulf. Maybe he can comment on if or why they are needed
> in devicetree, rather than being set by the driver unconditionally
> or for specific versions of the host controller.
> 
>   Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] drivers: mmc: core: sdio.c: fixed lines with > 80 chars

[Philip Rakity]

On 17 Oct 2012, at 15:13, Sangho Yi  wrote:

> Fixed coding style warning cases for exceeding 80 chars per line on
> sdio.c.
> 
> Signed-off-by: Sangho Yi 
> ---
> drivers/mmc/core/sdio.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index 2273ce6..14326e8 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -47,7 +47,8 @@ static int sdio_read_fbr(struct sdio_func *func)
> 
>   if (data == 0x0f) {
>   ret = mmc_io_rw_direct(func->card, 0, 0,
> - SDIO_FBR_BASE(func->num) + SDIO_FBR_STD_IF_EXT, 0, 
> &data);
> + SDIO_FBR_BASE(func->num) + SDIO_FBR_STD_IF_EXT,
> + 0, &data);
>   if (ret)
>   goto out;
>   }
> @@ -619,7 +620,8 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 
> ocr,
>   card->type = MMC_TYPE_SD_COMBO;
> 
>   if (oldcard && (oldcard->type != MMC_TYPE_SD_COMBO ||
> - memcmp(card->raw_cid, oldcard->raw_cid, 
> sizeof(card->raw_cid)) != 0)) {
> + memcmp(card->raw_cid, oldcard->raw_cid,
> + sizeof(card->raw_cid)) != 0)) {
could you ident the sizeof one more tab stop
>   mmc_remove_card(card);
>   return -ENOENT;
>   }
> -- 
> 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

--
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 2/2] mmc: core: Power cycle card on voltage switch fail

[Philip Rakity]

On Sep 25, 2012, at 12:30 AM, Ulf Hansson  wrote:

> Hi Johan,
> 
> An overall comment; would it be possible to include this patch as a
> piece of patch 1/2 "mmc: core: Proper signal voltage switch".
> They seems like quite tight connected.
> 
> Anyway, some comment below.
> 
> On 25 September 2012 09:04, Johan Rudholm  
> wrote:
>> Signed-off-by: Johan Rudholm 
>> ---
>> drivers/mmc/core/core.c |2 +-
>> drivers/mmc/core/core.h |1 +
>> drivers/mmc/core/sd.c   |8 ++--
>> 3 files changed, 8 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index dae6744..fb03bd9 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -1348,7 +1348,7 @@ static void mmc_poweroff_notify(struct mmc_host *host)
>>  * If a host does all the power sequencing itself, ignore the
>>  * initial MMC_POWER_UP stage.
>>  */
>> -static void mmc_power_up(struct mmc_host *host)
>> +void mmc_power_up(struct mmc_host *host)
>> {
>>int bit;
>> 
>> diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
>> index 3bdafbc..5a5170d 100644
>> --- a/drivers/mmc/core/core.h
>> +++ b/drivers/mmc/core/core.h
>> @@ -45,6 +45,7 @@ int mmc_set_signal_voltage(struct mmc_host *host, int 
>> signal_voltage,
>> void mmc_set_timing(struct mmc_host *host, unsigned int timing);
>> void mmc_set_driver_type(struct mmc_host *host, unsigned int drv_type);
>> void mmc_power_off(struct mmc_host *host);
>> +void mmc_power_up(struct mmc_host *host);
>> 
>> static inline void mmc_delay(unsigned int ms)
>> {
>> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
>> index 74972c2..9a165451 100644
>> --- a/drivers/mmc/core/sd.c
>> +++ b/drivers/mmc/core/sd.c
>> @@ -720,6 +720,7 @@ int mmc_sd_get_cid(struct mmc_host *host, u32 ocr, u32 
>> *cid, u32 *rocr)
>> * state.  We wait 1ms to give cards time to
>> * respond.
>> */
>> +try_again:
>>mmc_go_idle(host);
>> 
>>/*
>> @@ -748,7 +749,6 @@ int mmc_sd_get_cid(struct mmc_host *host, u32 ocr, u32 
>> *cid, u32 *rocr)
>>if (max_current > 150)
>>ocr |= SD_OCR_XPC;
>> 
>> -try_again:
>>err = mmc_send_app_op_cond(host, ocr, rocr);
>>if (err)
>>return err;
>> @@ -761,7 +761,11 @@ try_again:
>>   ((*rocr & 0x4100) == 0x4100)) {
>>err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180, 
>> true);
>>if (err) {
>> -   ocr &= ~SD_OCR_S18R;
>> +   /* Power cycle card */
>> +   pr_warning("%s: Signal voltage switch failed, "
>> +   "power cycling card\n", mmc_hostname(host));
>> +   mmc_power_off(host);
>> +   mmc_power_up(host);
> 
> This mean you will retry forever even if the card is not capable of
> 1.8V. I doubt this really what you want?
> 
>>goto try_again;
>>}
>>}
>> --
>> 1.7.10
>> 


 I did a patch for this problem in sdhci.c when voltage switch failed.  It 
turned off and then
turned on the regulator.  The patch worked on the UHS cards I was testing.  The 
fix
has been pulled upstream.

 
> 
> Kind regards
> Ulf Hansson
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/8] mmc: sdhci-pxav3: controller can't get base clock

[Philip Rakity]

On Sep 24, 2012, at 1:15 AM, Kevin Liu  wrote:

> From: Kevin Liu 
> 
> Enable the quirk SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN since
> SD_CAPABILITIES_1[15:8](BASE_FREQ) can't get correct base
> clock value. It return a fixed pre-set value like 200 on
> some sdhci-pxav3 based platforms like MMP3 while return 0
> on the other sdhci-pxav3 based platforms.
> So we enable the quirk and get the base clock via function
> get_max_clock.
> 
> Signed-off-by: Kevin Liu 
> ---
> drivers/mmc/host/sdhci-pxav3.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> index e918a2b..75cc79b 100644
> --- a/drivers/mmc/host/sdhci-pxav3.c
> +++ b/drivers/mmc/host/sdhci-pxav3.c
> @@ -249,7 +249,8 @@ static int __devinit sdhci_pxav3_probe(struct 
> platform_device *pdev)
> 
>   host->quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL
>   | SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC
> - | SDHCI_QUIRK_32BIT_ADMA_SIZE;
> + | SDHCI_QUIRK_32BIT_ADMA_SIZE
> + | SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN;
> 
>   /* enable 1/8V DDR capable */
>   host->mmc->caps |= MMC_CAP_1_8V_DDR;
> -- 
> 1.7.0.4
> 


Kevin,

would you mind adding:  

Reported-by: Philip Rakity  since I originally sent you 
different code to fix this.

This patch is NOT sufficient to fix the problem since the clock code was not 
correct in the marvell mmp3 code.
Has someone sent upstream the patch to fix the base code in linux ?

Reviewed-by: Philip Rakity --
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 5/8] mmc: sdhci: fix null return check of regulator_get

[Philip Rakity]

On Sep 24, 2012, at 1:15 AM, Kevin Liu  wrote:

> From: Kevin Liu 
> 
> regulator_get() returns NULL when CONFIG_REGULATOR not defined,
> which should not print out the warning.
> 
> Signed-off-by: Bin Wang 
> Signed-off-by: Kevin Liu 
> ---
> drivers/mmc/host/sdhci.c |   18 --
> 1 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 4b5631e..7c85e49 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2845,9 +2845,12 @@ int sdhci_add_host(struct sdhci_host *host)
> 
>   /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
>   host->vqmmc = regulator_get(mmc_dev(mmc), "vqmmc");
> - if (IS_ERR(host->vqmmc)) {
> - pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> - host->vqmmc = NULL;
> + if (IS_ERR_OR_NULL(host->vqmmc)) {
> + if (PTR_ERR(host->vqmmc) < 0) {
> + pr_info("%s: no vqmmc regulator found\n",
> + mmc_hostname(mmc));
> + host->vqmmc = NULL;
> + }
>   }
>   else if (regulator_is_supported_voltage(host->vqmmc, 165, 195))
>   regulator_enable(host->vqmmc);
> @@ -2912,9 +2915,12 @@ int sdhci_add_host(struct sdhci_host *host)
>   ocr_avail = 0;
> 
>   host->vmmc = regulator_get(mmc_dev(mmc), "vmmc");
> - if (IS_ERR(host->vmmc)) {
> - pr_info("%s: no vmmc regulator found\n", mmc_hostname(mmc));
> - host->vmmc = NULL;
> + if (IS_ERR_OR_NULL(host->vmmc)) {
> + if (PTR_ERR(host->vmmc) < 0) {
> + pr_info("%s: no vmmc regulator found\n",
> + mmc_hostname(mmc));
> + host->vmmc = NULL;
> + }
>   } else
>   regulator_enable(host->vmmc);
> 
> -- 
> 1.7.0.4
> 

Reviewed-by: Philip Rakity 

--
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: core: Add a capability for disabling mmc cards

[Philip Rakity]

On Aug 22, 2012, at 8:44 AM, Doug Anderson  wrote:

> Jaehoon,
> 
> On Tue, Aug 21, 2012 at 9:35 PM, Jaehoon Chung  wrote:
>> 
>> Hi Doug,
>> 
>> I didn't know what purpose is.
>> Why need to add the MMC_CAP2_NO_MMC?
>> If card is SD or SDIO, mmc_attach_mmc(host) should not be entered.
>> Could you explain to me in more detail?
> 
> Thanks for your feedback.  In this case I have a card that is an MMC
> card so mmc_attach_sdio() and mmc_attach_sd() will fail.  If I let
> mmc_attach_mmc() run it will actually find the MMC card.  However, on
> this platform it is not valid to recognize MMC cards.
> 


Understand.   

Can you explain why the change is needed.  Is it for technical 
reasons that MMC is not allowed -- if so then I do not understand how SD can 
work
and MMC cannot.

If it is for marketing reasons -- then --- oh well .


Could you add some additional comments to the commit message.
I think it makes sense to handle all 3 cases
a) SDIO not allowed
b) SD not allowed
c) MMC not allowed

> -Doug
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add MSI support for SDHCI PCI hosts

[Philip Rakity]

The interrupt source could be from a non-pci device.  Say a gpio or whatever.
Does it make sense to break this patch into two patches ?  

On Aug 17, 2012, at 2:14 AM, Daniel J Blueman  wrote:

> Allow module parameter 'enable_msi' to request an MSI interrupt for
> hosts where available (presently PCI). Useful as a workaround on
> platforms where the legacy interrupt is broken.
> 
> Signed-off-by: Daniel J Blueman 
> ---
> drivers/mmc/host/sdhci-pci.c |   30 ++
> drivers/mmc/host/sdhci.c |   23 +++
> drivers/mmc/host/sdhci.h |2 ++
> 3 files changed, 55 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
> index 504da71..fbde589 100644
> --- a/drivers/mmc/host/sdhci-pci.c
> +++ b/drivers/mmc/host/sdhci-pci.c
> @@ -934,6 +934,34 @@ static int sdhci_pci_enable_dma(struct sdhci_host *host)
>   return 0;
> }
> 
> +static int sdhci_pci_enable_msi(struct sdhci_host *host)
> +{
> + struct sdhci_pci_slot *slot;
> + struct pci_dev *pdev;
> + int ret;
> +
> + slot = sdhci_priv(host);
> + pdev = slot->chip->pdev;
> +
> + ret = pci_enable_msi(pdev);
> + if (ret)
> + return ret;
> +
> + host->irq = pdev->irq;
> + return 0;
> +}
> +
> +static void sdhci_pci_disable_msi(struct sdhci_host *host)
> +{
> + struct sdhci_pci_slot *slot;
> + struct pci_dev *pdev;
> +
> + slot = sdhci_priv(host);
> + pdev = slot->chip->pdev;
> +
> + pci_disable_msi(pdev);
> +}
> +
> static int sdhci_pci_8bit_width(struct sdhci_host *host, int width)
> {
>   u8 ctrl;
> @@ -976,6 +1004,8 @@ static void sdhci_pci_hw_reset(struct sdhci_host *host)
> 
> static struct sdhci_ops sdhci_pci_ops = {
>   .enable_dma = sdhci_pci_enable_dma,
> + .enable_msi = sdhci_pci_enable_msi,
> + .disable_msi= sdhci_pci_disable_msi,
>   .platform_8bit_width= sdhci_pci_8bit_width,
>   .hw_reset   = sdhci_pci_hw_reset,
> };
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 9a11dc3..9fa2180 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -45,6 +45,7 @@
> 
> static unsigned int debug_quirks = 0;
> static unsigned int debug_quirks2;
> +static bool enable_msi;
> 
> static void sdhci_finish_data(struct sdhci_host *);
> 
> @@ -2433,6 +2434,9 @@ int sdhci_suspend_host(struct sdhci_host *host)
> 
>   free_irq(host->irq, host);
> 
> + if (host->ops->disable_msi && enable_msi)
> + host->ops->disable_msi(host);
> +
>   return ret;
> }
> 
> @@ -2447,6 +2451,12 @@ int sdhci_resume_host(struct sdhci_host *host)
>   host->ops->enable_dma(host);
>   }
> 
> + if (host->ops->enable_msi && enable_msi) {
> + ret = host->ops->enable_msi(host);
> + if (ret)
> + return ret;
> + }
> +
>   ret = request_irq(host->irq, sdhci_irq, IRQF_SHARED,
> mmc_hostname(host->mmc), host);
>   if (ret)
> @@ -3024,6 +3034,12 @@ int sdhci_add_host(struct sdhci_host *host)
>   host->tuning_timer.function = sdhci_tuning_timer;
>   }
> 
> + if (host->ops->enable_msi && enable_msi) {
> + ret = host->ops->enable_msi(host);
> + if (ret)
> + return ret;
> + }
> +
>   ret = request_irq(host->irq, sdhci_irq, IRQF_SHARED,
>   mmc_hostname(mmc), host);
>   if (ret) {
> @@ -3071,6 +3087,8 @@ int sdhci_add_host(struct sdhci_host *host)
> reset:
>   sdhci_reset(host, SDHCI_RESET_ALL);
>   free_irq(host->irq, host);
> + if (host->ops->disable_msi && enable_msi)
> + host->ops->disable_msi(host);
> #endif
> untasklet:
>   tasklet_kill(&host->card_tasklet);
> @@ -3114,6 +3132,9 @@ void sdhci_remove_host(struct sdhci_host *host, int 
> dead)
> 
>   free_irq(host->irq, host);
> 
> + if (host->ops->disable_msi && enable_msi)
> + host->ops->disable_msi(host);
> +
>   del_timer_sync(&host->timer);
> 
>   tasklet_kill(&host->card_tasklet);
> @@ -3162,6 +3183,7 @@ module_exit(sdhci_drv_exit);
> 
> module_param(debug_quirks, uint, 0444);
> module_param(debug_quirks2, uint, 0444);
> +module_param(enable_msi, bool, 0444);
> 
> MODULE_AUTHOR("Pierre Ossman ");
> MODULE_DESCRIPTION("Secure Digital Host Controller Interface core driver");
> @@ -3169,3 +3191,4 @@ MODULE_LICENSE("GPL");
> 
> MODULE_PARM_DESC(debug_quirks, "Force certain quirks.");
> MODULE_PARM_DESC(debug_quirks2, "Force certain other quirks.");
> +MODULE_PARM_DESC(debug_quirks2, "Enable MSI interrupt support where 
> possible.");
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 97653ea..df4e003 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -264,6 +264,8 @@ struct sdhci_ops {
>   void(*set_clock)(struct sdhci_host *host, unsigned int clock);
> 
>   int 

Re: [PATCH] sdhci: Add regulator support for vccq (voltage regualor)

[Philip Rakity]

Hi Chris,

Looks good.

Philip

On Aug 7, 2012, at 7:43 PM, Chris Ball  wrote:

> Hi Philip,
> 
> On Mon, Jul 23 2012, philipspatc...@gmail.com wrote:
>> From: Philip Rakity 
>> 
>> On some systems the host controller does not support vccq
>> signaling.  This is supplied by a dedicated regulator (vqmmc).
>> 
>> Add support for this regulator.
>> 
>> Signed-off-by: Philip Rakity 
> 
> I've folded in this trivial cleanup patch, let me know if there's anything
> in there you disagree with:
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index ac50d35..828ac6c 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1607,11 +1607,10 @@ static int sdhci_do_3_3v_signal_voltage_switch(struct 
> sdhci_host *host,
>   sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
> 
>   if (host->vqmmc) {
> - ret = regulator_set_voltage(host->vqmmc,
> - 330, 330);
> + ret = regulator_set_voltage(host->vqmmc, 330, 330);
>   if (ret) {
> - pr_info(DRIVER_NAME ": Switching to 3.3V "
> - "signalling voltage failed\n");
> + pr_warning("%s: Switching to 3.3V signalling voltage "
> +" failed\n", mmc_hostname(host->mmc));
>   return -EIO;
>   }
>   }
> @@ -1623,7 +1622,9 @@ static int sdhci_do_3_3v_signal_voltage_switch(struct 
> sdhci_host *host,
>   if (!(ctrl & SDHCI_CTRL_VDD_180))
>   return 0;
> 
> - pr_info(DRIVER_NAME ": Switching to 3.3V signalling voltage failed\n");
> + pr_warning("%s: 3.3V regulator output did not became stable\n",
> +mmc_hostname(host->mmc));
> +
>   return -EIO;
> }
> 
> @@ -1700,8 +1701,9 @@ static int sdhci_do_1_8v_signal_voltage_switch(struct 
> sdhci_host *host,
>   if (host->vmmc)
>   regulator_enable(host->vmmc);
> 
> - pr_info(DRIVER_NAME ": Switching to 1.8V signalling "
> - "voltage failed, retrying with S18R set to 0\n");
> + pr_warning("%s: Switching to 1.8V signalling voltage failed, "
> +"retrying with S18R set to 0\n", mmc_hostname(host->mmc));
> +
>   return -EAGAIN;
> }
> 
> @@ -2834,15 +2836,13 @@ int sdhci_add_host(struct sdhci_host *host)
>   !(host->mmc->caps & MMC_CAP_NONREMOVABLE))
>   mmc->caps |= MMC_CAP_NEEDS_POLL;
> 
> - /* if vqmmc regulator and no 1.8V signaling no UHS */
> -
> + /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
>   host->vqmmc = regulator_get(mmc_dev(mmc), "vqmmc");
>   if (IS_ERR(host->vqmmc)) {
> - pr_info("%s: no vqmmc regulator found\n",
> - mmc_hostname(mmc));
> + pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
>   host->vqmmc = NULL;
> - } else if (regulator_is_supported_voltage(host->vqmmc,
> - 180, 180))
> + }
> + else if (regulator_is_supported_voltage(host->vqmmc, 180, 180))
>   regulator_enable(host->vqmmc);
>   else
>   caps[1] &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
> 
> -- 
> Chris Ball  <http://printf.net/>
> One Laptop Per Child

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mmc: sd: Fix sd current limit setting

[Philip Rakity]

It is much cleaner solution then before !  I like it.

Reviewed-by: Philip Rakity 

On Jul 18, 2012, at 7:41 PM, Chris Ball wrote:

> Hi,
> 
> On Wed, Jul 18 2012, Aaron Lu wrote:
>> I've prepared the following code, please check if this is better than
>> the current one:
> 
> I think the diffstat speaks for itself.  :-)
> 
> drivers/mmc/core/sd.c|   77 ++
> drivers/mmc/host/sdhci.c |   51 ++
> include/linux/mmc/host.h |   22 +++--
> 3 files changed, 51 insertions(+), 99 deletions(-)
> 
> Girish/Philip, does this look good to you too?  If so, I'll squash it
> into the original patch.
> 
> Thanks!
> 
> - Chris.
> -- 
> Chris Ball  <http://printf.net/>
> One Laptop Per Child

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] mmc: sdhci: A new flag SDHCI_USING_RETUNING_TIMER

[Philip Rakity]

Reviewed-by: Philip Rakity 

On Jul 3, 2012, at 10:29 PM, Aaron Lu wrote:

> Add a new flag of SDHCI_USING_RETUNING_TIMER to represent if the host
> is using a retuning timer for the card inserted.
> 
> This flag is set when the host does tuning the first time for the card
> and the host's retuning mode is 1. This flag is used afterwards whenever
> needs to decide if the host is currently using a retuning timer.
> 
> This flag is cleared when the card is removed in sdhci_reinit.
> 
> The set/clear of the flag and the start/stop of the retuning timer is
> associated with the card's init/remove time, so there is no need to
> touch it when the host is to be removed as at that time the card should
> have already been removed.
> 
> Signed-off-by: Aaron Lu 
> ---
> v3:
> Change the macro name from SDHCI_NEEDS_RETUNING_TIMER to
> SDHCI_USING_RETUNING_TIMER for better description of the flag as suggested
> by Chris Ball.
> 
> v2:
> v1 mistakenly removed the line del_timer_sync(&host->timer) in
> sdhci_remove_host, fix this by adding back the code.
> 
> drivers/mmc/host/sdhci.c  | 30 --
> include/linux/mmc/sdhci.h |  1 +
> 2 files changed, 13 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index b0a5629..3ec4182 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -250,8 +250,9 @@ static void sdhci_reinit(struct sdhci_host *host)
>* applicable to UHS-I cards. So reset these fields to their initial
>* value when card is removed.
>*/
> - if (host->version >= SDHCI_SPEC_300 && host->tuning_count &&
> - host->tuning_mode == SDHCI_TUNING_MODE_1) {
> + if (host->flags & SDHCI_USING_RETUNING_TIMER) {
> + host->flags &= ~SDHCI_USING_RETUNING_TIMER;
> +
>   del_timer_sync(&host->tuning_timer);
>   host->flags &= ~SDHCI_NEEDS_RETUNING;
>   host->mmc->max_blk_count =
> @@ -1873,6 +1874,7 @@ out:
>*/
>   if (!(host->flags & SDHCI_NEEDS_RETUNING) && host->tuning_count &&
>   (host->tuning_mode == SDHCI_TUNING_MODE_1)) {
> + host->flags |= SDHCI_USING_RETUNING_TIMER;
>   mod_timer(&host->tuning_timer, jiffies +
>   host->tuning_count * HZ);
>   /* Tuning mode 1 limits the maximum data length to 4MB */
> @@ -1890,10 +1892,10 @@ out:
>* try tuning again at a later time, when the re-tuning timer expires.
>* So for these controllers, we return 0. Since there might be other
>* controllers who do not have this capability, we return error for
> -  * them.
> +  * them. SDHCI_USING_RETUNING_TIMER means the host is currently using
> +  * a retuning timer to do the retuning for the card.
>*/
> - if (err && host->tuning_count &&
> - host->tuning_mode == SDHCI_TUNING_MODE_1)
> + if (err && (host->flags & SDHCI_USING_RETUNING_TIMER))
>   err = 0;
> 
>   sdhci_clear_set_irqs(host, SDHCI_INT_DATA_AVAIL, ier);
> @@ -2400,7 +2402,6 @@ out:
> int sdhci_suspend_host(struct sdhci_host *host)
> {
>   int ret;
> - bool has_tuning_timer;
> 
>   if (host->ops->platform_suspend)
>   host->ops->platform_suspend(host);
> @@ -2408,16 +2409,14 @@ int sdhci_suspend_host(struct sdhci_host *host)
>   sdhci_disable_card_detection(host);
> 
>   /* Disable tuning since we are suspending */
> - has_tuning_timer = host->version >= SDHCI_SPEC_300 &&
> - host->tuning_count && host->tuning_mode == SDHCI_TUNING_MODE_1;
> - if (has_tuning_timer) {
> + if (host->flags & SDHCI_USING_RETUNING_TIMER) {
>   del_timer_sync(&host->tuning_timer);
>   host->flags &= ~SDHCI_NEEDS_RETUNING;
>   }
> 
>   ret = mmc_suspend_host(host->mmc);
>   if (ret) {
> - if (has_tuning_timer) {
> + if (host->flags & SDHCI_USING_RETUNING_TIMER) {
>   host->flags |= SDHCI_NEEDS_RETUNING;
>   mod_timer(&host->tuning_timer, jiffies +
>   host->tuning_count * HZ);
> @@ -2468,8 +2467,7 @@ int sdhci_resume_host(struct sdhci_host *host)
>   host->ops->platform_resume(host);
> 
>   /* Set the re-tuning expiration flag */
> - if ((host->version >= SDHCI_SPEC_300) && host->tuning

Re: [PATCH v2 2/2] mmc: sd: Fix sd current limit setting

[Philip Rakity]

Reviewed-by: Philip Rakity 

On Jul 3, 2012, at 10:31 PM, Aaron Lu wrote:

> Host has different current capabilities at different voltages, we need
> to record these settings seperately. The defined voltages are 1.8/3.0/3.3.
> For other voltages, we do not touch current limit setting.
> 
> Before set current limit for the sd card, find out the host's operating
> voltage first and then find out the current capabilities of the host at
> that voltage to set the current limit.
> 
> Signed-off-by: Aaron Lu 
> ---
> v2:
> Do not call BUG() when the host's voltage is not supported as suggested by
> Chris Ball.
> Do not use 0/1/2 to represent the host's voltage as suggested by Philip 
> Rakity.
> 
> drivers/mmc/core/sd.c| 44 +---
> drivers/mmc/host/sdhci.c | 28 
> include/linux/mmc/host.h | 16 
> 3 files changed, 73 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
> index 8460568..312b78d 100644
> --- a/drivers/mmc/core/sd.c
> +++ b/drivers/mmc/core/sd.c
> @@ -521,11 +521,25 @@ static int sd_set_current_limit(struct mmc_card *card, 
> u8 *status)
> {
>   int current_limit = SD_SET_CURRENT_NO_CHANGE;
>   int err;
> + u32 voltage;
> 
>   /*
>* Current limit switch is only defined for SDR50, SDR104, and DDR50
>* bus speed modes. For other bus speed modes, we do not change the
>* current limit.
> +  */
> + if ((card->sd_bus_speed != UHS_SDR50_BUS_SPEED) &&
> + (card->sd_bus_speed != UHS_SDR104_BUS_SPEED) &&
> + (card->sd_bus_speed != UHS_DDR50_BUS_SPEED))
> + return 0;
> +
> + /*
> +  * Host has different current capabilities when operating at
> +  * different voltages, so find out the current voltage first.
> +  */
> + voltage = 1 << card->host->ios.vdd;
> +
> + /*
>* We only check host's capability here, if we set a limit that is
>* higher than the card's maximum current, the card will be using its
>* maximum current, e.g. if the card's maximum current is 300ma, and
> @@ -533,16 +547,32 @@ static int sd_set_current_limit(struct mmc_card *card, 
> u8 *status)
>* when we set current limit to 400/600/800ma, the card will draw its
>* maximum 300ma from the host.
>*/
> - if ((card->sd_bus_speed == UHS_SDR50_BUS_SPEED) ||
> - (card->sd_bus_speed == UHS_SDR104_BUS_SPEED) ||
> - (card->sd_bus_speed == UHS_DDR50_BUS_SPEED)) {
> - if (card->host->caps & MMC_CAP_MAX_CURRENT_800)
> + if (voltage == MMC_VDD_165_195) {
> + if (card->host->caps & MMC_CAP_MAX_CURRENT_800_180)
> + current_limit = SD_SET_CURRENT_LIMIT_800;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_600_180)
> + current_limit = SD_SET_CURRENT_LIMIT_600;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_400_180)
> + current_limit = SD_SET_CURRENT_LIMIT_400;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_200_180)
> + current_limit = SD_SET_CURRENT_LIMIT_200;
> + } else if (voltage & (MMC_VDD_29_30 | MMC_VDD_30_31)) {
> + if (card->host->caps & MMC_CAP_MAX_CURRENT_800_300)
> + current_limit = SD_SET_CURRENT_LIMIT_800;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_600_300)
> + current_limit = SD_SET_CURRENT_LIMIT_600;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_400_300)
> + current_limit = SD_SET_CURRENT_LIMIT_400;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_200_300)
> + current_limit = SD_SET_CURRENT_LIMIT_200;
> + } else if (voltage & (MMC_VDD_32_33 | MMC_VDD_33_34)) {
> + if (card->host->caps & MMC_CAP_MAX_CURRENT_800_330)
>   current_limit = SD_SET_CURRENT_LIMIT_800;
> - else if (card->host->caps & MMC_CAP_MAX_CURRENT_600)
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_600_330)
>   current_limit = SD_SET_CURRENT_LIMIT_600;
> - else if (card->host->caps & MMC_CAP_MAX_CURRENT_400)
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_400_330)
>   current_limit = SD_SET_CURRENT_LIMIT_400;
> - else if (card->host->caps & MMC_CAP_MAX_

Re: [PATCH 2/2] mmc: sd: Fix sd current limit setting

[Philip Rakity]

Hi Arron,

One minor comment -- okay without the change but clearer IMHO with the change.

Reviewed-by: Philip Rakity 

Philip


On Jul 2, 2012, at 11:16 PM, Aaron Lu wrote:

> Host has different current capabilities at different voltages, we need
> to record these settings seperately. Before set current limit for the sd
> card, find out the current voltage first and then find out the current
> capabilities of the host to set the limit.
> 
> Signed-off-by: Aaron Lu 
> ---
> drivers/mmc/core/sd.c| 58 ++--
> drivers/mmc/host/sdhci.c | 28 +++
> include/linux/mmc/host.h | 16 +
> 3 files changed, 87 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
> index ae72d6e..4b4cf4d 100644
> --- a/drivers/mmc/core/sd.c
> +++ b/drivers/mmc/core/sd.c
> @@ -521,11 +521,39 @@ static int sd_set_current_limit(struct mmc_card *card, 
> u8 *status)
> {
>   int current_limit = SD_SET_CURRENT_NO_CHANGE;
>   int err;
> + u8 voltage;
u32 voltage;
> 
>   /*
>* Current limit switch is only defined for SDR50, SDR104, and DDR50
>* bus speed modes. For other bus speed modes, we do not change the
>* current limit.
> +  */
> + if ((card->sd_bus_speed != UHS_SDR50_BUS_SPEED) &&
> + (card->sd_bus_speed != UHS_SDR104_BUS_SPEED) &&
> + (card->sd_bus_speed != UHS_DDR50_BUS_SPEED))
> + return 0;
> +
> + /*
> +  * Host has different current capabilities when operating at
> +  * different voltages, so find out the current voltage first.
> +  */
> + switch (1 << card->host->ios.vdd) {
> + case MMC_VDD_165_195:
> + voltage = 0; /* host's voltage is 1.8V */

It is a little clearly if you do this or make voltage 0, 1, 2 an enum for the 
routine.
otherwise
reviewed-by: Philip Rakity 
voltage = MMC_VDD_165_195;
> 
> + break;
> + case MMC_VDD_29_30:
> + case MMC_VDD_30_31:
> + voltage = 1; /* host's voltage is 3.0V */
voltage = MMC_VDD_29_30 | MMC_VDD_30_31;
> 
> + break;
> + case MMC_VDD_32_33:
> + case MMC_VDD_33_34:
> + voltage = 2; /* host's voltage is 3.3V */
voltage = MMC_VDD_32_33 | MMC_VDD_33_34;
> 
> + break;
> + default:
> + BUG(); /* host's voltage is invalid */
> + }
> +
> + /*
>* We only check host's capability here, if we set a limit that is
>* higher than the card's maximum current, the card will be using its
>* maximum current, e.g. if the card's maximum current is 300ma, and
> @@ -533,16 +561,32 @@ static int sd_set_current_limit(struct mmc_card *card, 
> u8 *status)
>* when we set current limit to 400/600/800ma, the card will draw its
>* maximum 300ma from the host.
>*/
> - if ((card->sd_bus_speed == UHS_SDR50_BUS_SPEED) ||
> - (card->sd_bus_speed == UHS_SDR104_BUS_SPEED) ||
> - (card->sd_bus_speed == UHS_DDR50_BUS_SPEED)) {
> - if (card->host->caps & MMC_CAP_MAX_CURRENT_800)
> + if (voltage == 0) {
if (voltage == MMC_VDD_165_195) { 
> + if (card->host->caps & MMC_CAP_MAX_CURRENT_800_180)
> + current_limit = SD_SET_CURRENT_LIMIT_800;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_600_180)
> + current_limit = SD_SET_CURRENT_LIMIT_600;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_400_180)
> + current_limit = SD_SET_CURRENT_LIMIT_400;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_200_180)
> + current_limit = SD_SET_CURRENT_LIMIT_200;
> + } else if (voltage == 1)
} else if (voltage == ( MMC_VDD_29_30 | MMC_VDD_30_31)

etc ?
> {
> + if (card->host->caps & MMC_CAP_MAX_CURRENT_800_300)
> + current_limit = SD_SET_CURRENT_LIMIT_800;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_600_300)
> + current_limit = SD_SET_CURRENT_LIMIT_600;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_400_300)
> + current_limit = SD_SET_CURRENT_LIMIT_400;
> + else if (card->host->caps & MMC_CAP_MAX_CURRENT_200_300)
> + current_limit

RE: [PATCH v2] mmc: sdhci: fix incorrect command used in tuning

[Philip Rakity]

Reviewed-by philip Rakity prak...@marvell.com

From: Aaron Lu [aaron...@amd.com]
Sent: Tuesday, July 03, 2012 2:27 AM
To: Girish K S; Subhash Jadavani; Philip Rakity; Chris Ball
Cc: linux-mmc@vger.kernel.org; Aaron Lu; Aaron Lu; stable; 
"[3.3+]"@domain.invalid
Subject: [PATCH v2] mmc: sdhci: fix incorrect command used in tuning

V2:
Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.

V1:
For SD hosts using retuning mode 1, when retuning timer expired, it will
need to do retuning in sdhci_request before processing the actual
request. But the retuning command is fixed: cmd19 for SD card and cmd21
for eMMC card, so we can't use the original request's command to do the
tuning.

And since the tuning command depends on the card type atteched to the
host, we will need to know the card type to use the correct tuning
command.

Cc: stable  [3.3+]
Signed-off-by: Aaron Lu 
---
 drivers/mmc/host/sdhci.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f76736b..4e53e6b 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -27,6 +27,7 @@

 #include 
 #include 
+#include 

 #include "sdhci.h"

@@ -1245,6 +1246,7 @@ static void sdhci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
struct sdhci_host *host;
bool present;
unsigned long flags;
+   u32 tuning_opcode;

host = mmc_priv(mmc);

@@ -1292,8 +1294,12 @@ static void sdhci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
 */
if ((host->flags & SDHCI_NEEDS_RETUNING) &&
!(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) {
+   /* eMMC uses cmd21 while sd and sdio use cmd19 */
+   tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
+   MMC_SEND_TUNING_BLOCK_HS200 :
+   MMC_SEND_TUNING_BLOCK;
spin_unlock_irqrestore(&host->lock, flags);
-   sdhci_execute_tuning(mmc, mrq->cmd->opcode);
+   sdhci_execute_tuning(mmc, tuning_opcode);
spin_lock_irqsave(&host->lock, flags);

/* Restore original mmc_request structure */
--
1.7.11.1.3.g4c8a9db


--
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: Where to power on the wifi device before loading the driver.

[Philip Rakity]

Why can't you use the regulator notify to get called back on power or voltage 
change options to plumb in the manipulation of the gpio. I can imagine you 
might need to add a notify call in core.c if you need to assert the gpio before 
power is applied



From: linux-mmc-ow...@vger.kernel.org [linux-mmc-ow...@vger.kernel.org] On 
Behalf Of Wei Ni [w...@nvidia.com]
Sent: Sunday, June 17, 2012 11:20 PM
To: 'Stephen Warren'; Rakesh Kumar
Cc: Mark Brown; 'fran...@broadcom.com'; Thierry Reding; Mursalin Akon; 
'linux-mmc@vger.kernel.org'; devicetree-disc...@lists.ozlabs.org; 
'linux-wirel...@vger.kernel.org'; linux-te...@vger.kernel.org; 
linux-arm-ker...@lists.infradead.org
Subject: RE: Where to power on the wifi device before loading the driver.

On Fri, Jun 15, 2012 at 23:49:10, Stephen Warren wrote:
>> I talked with Franky, this power sequence is generally for 4329, so
>> it mean this sequence can be put into the wifi driver.
>> We can use the virtual platform device both for OOB and non OOB.
>> I will send out patches later.
>
>Can you please expand on what a "virtual platform device" is; device tree 
>typically represents real hardware rather than anything "virtual".

The "virtual platform device" is created before the real wifi device, so that 
it can pass the gpios to the driver, and power up the device before calling 
sdio_register_driver.
But as Franky said, this power sequence is only generally for 4329, not for the 
USB dongle chips. So it's not a good idea to add this "power up" in brcmfmac.

>
>Now if this means adding a child node under the SDIO controller to represent 
>the attached device, and storing any settings required by that device in that 
>child node, that's probably a reasonable basic approach.
>
>BTW, which GPIO is the power GPIO; is it WF_EN on the schematic? That seems 
>reasonable to represent as a GPIO rather than a regulator since it connects 
>directly into the WiFi device as a GPIO, and its use within the WiFi device 
>can indeed be governed purely internally to the WiFi driver/HW. However, if 
>this is some GPIO that controls the power to e.g.
>VBAT3V3_IN_WF, VDDIO_WF, or other power supply to the WiFi card, then it'd be 
>better represented as a regulator, since the control point is outside the WiFi 
>device.

I think Rakesh may can answer this.

Wei.
---
nvpublic


--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] regulator: core.c Pass voltage to notifier when setting voltage

[Philip Rakity]

On Jun 15, 2012, at 11:50 AM, Pankaj Jangra wrote:

> Hi,
> 
> On Fri, Jun 15, 2012 at 11:57 PM, Philip Rakity
>  wrote:
>> V3
>> --
>> 
>> Fix type where data argument was not passed in
>> blocking_notifier_call_chain.
>> 
>> edits to check in comments (below)
>> 
>> V2
>> --
>> 
>> Incorporate performance suggestions made by Mark Brown
>> Use linux-next as base code rather than mmc-next
>> 
>> The voltage being set should be passed to the call in handler
>> requesting the callback.  Currently this is not done.
>> 
>> The callin handler cannot call regulator_get_voltage() to get the
> 
> "The calling"

I am not sure what the correct term for this.  The blocking_notifier_call_chain 
calls 
what ?   calling might imply blocking_notifier_call_chain() since it is doing 
the calling.
What is the receiver of the call named ?

> 
>> information since the mutex is held by the regulator and
>> deadlock occurs.
>> 
>> Without this change the receiver of the call in cannot know what
>> action to take.  This is used, for example, to set PAD voltages
>> when doing SD vccq voltage changes.
>> 
>> Signed-off-by: Philip Rakity 
>> ---
> 
> Since you are submitting your patch from the different email than your
> Singed-off email. So you should put in first line of message
> From: .
> 
> Regards,
> Pankaj Jangra

--
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] regulator: core.c Pass voltage to notifier when setting voltage

[Philip Rakity]

On Jun 15, 2012, at 10:58 AM, Pankaj Jangra wrote:

> Hi Philip,
> 
> Just a cosmetic comments.
> 
> On Fri, Jun 15, 2012 at 3:36 AM, Philip Rakity  
> wrote:
> V2
> --
> 
> Incorporate performance suggestions made by Mark Brown
> Use linux-next as base code rather than mmc-next
> 
> The voltage being set should be passed to the handler requesting
> the callback.  Currently this is not done.

thanks -- my typo when redoing the patch -- V3 has this fixed.

> 
> The callback cannot call regulator_get_voltage() to get the
> information since the mutex is held by the regulator and
> deadlock occurs.
> 
> Without this change the receiver of the notify cannot now what
>  
> You mean to say "cannot know what" ?   
> 
> action to take.  This is used, for example, to set PAD voltages
> when doing SD vccq voltage changes.


if you call in that receives the notify does not know the new voltage
then in our case we do not know if we should switch the pad from
3.3v to 1.8v for example.  vccq signaling in SD is normally 3.3V
but in UHS mode it is lowered to 1.8V

> 
> Signed-off-by: Philip Rakity 
> ---
>  drivers/regulator/core.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 63507a5..5b04916 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -2153,7 +2153,7 @@ static int _regulator_do_set_voltage(struct 
> regulator_dev *rdev,
>if (rdev->desc->ops->list_voltage)
>best_val = rdev->desc->ops->list_voltage(rdev, selector);
>else
> -   best_val = -1;
> +   best_val = _regulator_get_voltage(rdev);
> 
>/* Call set_voltage_time_sel if successfully obtained old_selector */
>if (_regulator_is_enabled(rdev) && ret == 0 && old_selector >= 0 &&
> @@ -2176,9 +2176,9 @@ static int _regulator_do_set_voltage(struct 
> regulator_dev *rdev,
>udelay(delay);
>}
> 
> -   if (ret == 0)
> +   if (ret == 0 && best_val >= 0)
>_notifier_call_chain(rdev, REGULATOR_EVENT_VOLTAGE_CHANGE,
> -NULL);
> +(void *)best_val);
> 
> 
> I am also curious to know if you pass the  voltage here to notifier call how 
> does it make any difference, since in 
> blocking_notifier_call_chain() again passes the NULL. So does your patch 
> should  modify the arguments to this function also?
> Please let me know if i am missing something in understanding.
> 
> Regards,
> Pankaj Jangra
> 
>trace_regulator_set_voltage_complete(rdev_get_name(rdev), best_val);
> 
> --
> 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
> 

--
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] regulator: core.c Pass voltage to notifier when setting voltage

[Philip Rakity]

V3
--

Fix type where data argument was not passed in
blocking_notifier_call_chain.

edits to check in comments (below)

V2
--

Incorporate performance suggestions made by Mark Brown
Use linux-next as base code rather than mmc-next

The voltage being set should be passed to the call in handler
requesting the callback.  Currently this is not done.

The callin handler cannot call regulator_get_voltage() to get the
information since the mutex is held by the regulator and
deadlock occurs.

Without this change the receiver of the call in cannot know what
action to take.  This is used, for example, to set PAD voltages
when doing SD vccq voltage changes.

Signed-off-by: Philip Rakity 
---
 drivers/regulator/core.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 63507a5..cdf6905 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2153,7 +2153,7 @@ static int _regulator_do_set_voltage(struct regulator_dev 
*rdev,
if (rdev->desc->ops->list_voltage)
best_val = rdev->desc->ops->list_voltage(rdev, selector);
else
-   best_val = -1;
+   best_val = _regulator_get_voltage(rdev);
 
/* Call set_voltage_time_sel if successfully obtained old_selector */
if (_regulator_is_enabled(rdev) && ret == 0 && old_selector >= 0 &&
@@ -2176,9 +2176,9 @@ static int _regulator_do_set_voltage(struct regulator_dev 
*rdev,
udelay(delay);
}
 
-   if (ret == 0)
+   if (ret == 0 && best_val >= 0)
_notifier_call_chain(rdev, REGULATOR_EVENT_VOLTAGE_CHANGE,
-NULL);
+(void *)best_val);
 
trace_regulator_set_voltage_complete(rdev_get_name(rdev), best_val);
 
@@ -2692,7 +2692,7 @@ static void _notifier_call_chain(struct regulator_dev 
*rdev,
  unsigned long event, void *data)
 {
/* call rdev chain first */
-   blocking_notifier_call_chain(&rdev->notifier, event, NULL);
+   blocking_notifier_call_chain(&rdev->notifier, event, data);
 }
 
 /**
-- 
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

[PATCH 2/2] regulator: core.c Only delay when setting voltage requires this

[Philip Rakity]

minor optimization: move delay code to where delay is set and
thus where it is used vs in the main line path.

Signed-off-by: Philip Rakity 
---
 drivers/regulator/core.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5b04916..4407ed2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2166,14 +2166,14 @@ static int _regulator_do_set_voltage(struct 
regulator_dev *rdev,
  delay);
delay = 0;
}
-   }
 
-   /* Insert any necessary delays */
-   if (delay >= 1000) {
-   mdelay(delay / 1000);
-   udelay(delay % 1000);
-   } else if (delay) {
-   udelay(delay);
+   /* Insert any necessary delays */
+   if (delay >= 1000) {
+   mdelay(delay / 1000);
+   udelay(delay % 1000);
+   } else if (delay) {
+   udelay(delay);
+   }
}
 
if (ret == 0 && best_val >= 0)
-- 
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

[PATCH 1/2] regulator: core.c Pass voltage to notifier when setting voltage

[Philip Rakity]

V2
--

Incorporate performance suggestions made by Mark Brown
Use linux-next as base code rather than mmc-next

The voltage being set should be passed to the handler requesting
the callback.  Currently this is not done.

The callback cannot call regulator_get_voltage() to get the
information since the mutex is held by the regulator and
deadlock occurs.

Without this change the receiver of the notify cannot now what
action to take.  This is used, for example, to set PAD voltages
when doing SD vccq voltage changes.

Signed-off-by: Philip Rakity 
---
 drivers/regulator/core.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 63507a5..5b04916 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2153,7 +2153,7 @@ static int _regulator_do_set_voltage(struct regulator_dev 
*rdev,
if (rdev->desc->ops->list_voltage)
best_val = rdev->desc->ops->list_voltage(rdev, selector);
else
-   best_val = -1;
+   best_val = _regulator_get_voltage(rdev);
 
/* Call set_voltage_time_sel if successfully obtained old_selector */
if (_regulator_is_enabled(rdev) && ret == 0 && old_selector >= 0 &&
@@ -2176,9 +2176,9 @@ static int _regulator_do_set_voltage(struct regulator_dev 
*rdev,
udelay(delay);
}
 
-   if (ret == 0)
+   if (ret == 0 && best_val >= 0)
_notifier_call_chain(rdev, REGULATOR_EVENT_VOLTAGE_CHANGE,
-NULL);
+(void *)best_val);
 
trace_regulator_set_voltage_complete(rdev_get_name(rdev), best_val);
 
-- 
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 v4] mmc: add a function to get regulators, supplying card's power

[Philip Rakity]

On Jun 12, 2012, at 9:52 AM, Guennadi Liakhovetski wrote:

> On Tue, 12 Jun 2012, Philip Rakity wrote:
> 
>> 
>> On Jun 12, 2012, at 8:57 AM, Guennadi Liakhovetski wrote:
>> 
>>> Add a function to get regulators, supplying card's Vdd and Vccq on a
>>> specific host. If a Vdd supplying regulator is found, the function checks,
>>> whether a valid OCR mask can be obtained from it. The Vccq regulator is
>>> optional. A failure to get it is not fatal.
>>> 
>>> Signed-off-by: Guennadi Liakhovetski 
>>> ---
>>> 
>>> v4:
>>> 
>>> 1. add _GPL to EXPORT_SYMBOL (note: a recently posted patch changes 
>>> another occurrence of EXPORT_SYMBOL too, so, this patch will apply with a 
>>> fuzz, if merged after)
>>> 
>>> 2. add an optional vqmmc regulator, which also changes the function 
>>> prototype
>>> 
>>> 3. print a warning, if failed to get an OCR mask
>>> 
>>> Thanks to all, who commented
>>> 
>>> drivers/mmc/core/core.c  |   27 +++
>>> include/linux/mmc/host.h |   12 
>>> 2 files changed, 39 insertions(+), 0 deletions(-)
>>> 
>>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>>> index 0b6141d..d77a238 100644
>>> --- a/drivers/mmc/core/core.c
>>> +++ b/drivers/mmc/core/core.c
>>> @@ -1013,6 +1013,33 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
>>> }
>>> EXPORT_SYMBOL(mmc_regulator_set_ocr);
>>> 
>>> +int mmc_regulator_get_supply(struct mmc_host *mmc, struct mmc_supply *s)
>>> +{
>>> +   struct device *dev = mmc_dev(mmc);
>>> +   struct regulator *supply;
>>> +   int ret;
>>> +
>>> +   if (!mmc || !s)
>>> +   return -EINVAL;
>>> +
>>> +   supply = devm_regulator_get(dev, "vmmc");
>>> +
>>> +   if (IS_ERR(supply))
>>> +   return PTR_ERR(supply);
>>> +
>>> +   s->vmmc = supply;
>>> +   s->vqmmc = devm_regulator_get(dev, "vqmmc");
>> 
>> Should we set vqmmc to NULL if an error was returned ?
> 
> Don't think so, drivers can perfectly check for IS_ERR() themselves.

sdhci.c checks for 

if (host->vmmc) {
regulator_disable(host->vmmc);
regulator_put(host->vmmc);
}

so better to set regulator to NULL if not used.
> 
>>> +
>>> +   ret = mmc_regulator_get_ocrmask(supply);
>>> +   if (ret > 0)
>>> +   mmc->ocr_avail = ret;
>>> +   else
>>> +   dev_warn(mmc_dev(mmc), "Failed getting OCR mask: %d\n", ret);
>> 
>> I was wondering if  sdhci (or the other SD Host drivers can work if no 
>> ocr_avail mask is set ?  
> 
> Yes, e.g., if it's a dummy regulator and the board actually doesn't need 
> one.
> 
>>> +
>>> +   return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(mmc_regulator_get_supply);
>>> +
>>> #endif /* CONFIG_REGULATOR */
>>> 
>>> /*
>>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>>> index 0707d22..3192335 100644
>>> --- a/include/linux/mmc/host.h
>>> +++ b/include/linux/mmc/host.h
>>> @@ -359,11 +359,17 @@ static inline void mmc_signal_sdio_irq(struct 
>>> mmc_host *host)
>>> 
>>> struct regulator;
>>> 
>>> +struct mmc_supply {
>>> +   struct regulator *vmmc; /* Card power supply */
>>> +   struct regulator *vqmmc;/* Optional Vccq supply */
>>> +};
>>> +
>>> #ifdef CONFIG_REGULATOR
>>> int mmc_regulator_get_ocrmask(struct regulator *supply);
>>> int mmc_regulator_set_ocr(struct mmc_host *mmc,
>>> struct regulator *supply,
>>> unsigned short vdd_bit);
>>> +int mmc_regulator_get_supply(struct mmc_host *mmc, struct mmc_supply *s);
>>> #else
>>> static inline int mmc_regulator_get_ocrmask(struct regulator *supply)
>>> {
>>> @@ -376,6 +382,12 @@ static inline int mmc_regulator_set_ocr(struct 
>>> mmc_host *mmc,
>>> {
>>> return 0;
>>> }
>>> +
>>> +static inline int mmc_regulator_get_supply(struct mmc_host *mmc,
>>> +  struct mmc_supply *s)
>>> +{
>>> +   return 0;
>>> +}
>>> #endif
>>> 
>>> int mmc_card_awake(struct mmc_host *host);
>>> -- 
>>> 1.7.2.5
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/

--
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 v4] mmc: add a function to get regulators, supplying card's power

[Philip Rakity]

On Jun 12, 2012, at 8:57 AM, Guennadi Liakhovetski wrote:

> Add a function to get regulators, supplying card's Vdd and Vccq on a
> specific host. If a Vdd supplying regulator is found, the function checks,
> whether a valid OCR mask can be obtained from it. The Vccq regulator is
> optional. A failure to get it is not fatal.
> 
> Signed-off-by: Guennadi Liakhovetski 
> ---
> 
> v4:
> 
> 1. add _GPL to EXPORT_SYMBOL (note: a recently posted patch changes 
> another occurrence of EXPORT_SYMBOL too, so, this patch will apply with a 
> fuzz, if merged after)
> 
> 2. add an optional vqmmc regulator, which also changes the function 
> prototype
> 
> 3. print a warning, if failed to get an OCR mask
> 
> Thanks to all, who commented
> 
> drivers/mmc/core/core.c  |   27 +++
> include/linux/mmc/host.h |   12 
> 2 files changed, 39 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 0b6141d..d77a238 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1013,6 +1013,33 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
> }
> EXPORT_SYMBOL(mmc_regulator_set_ocr);
> 
> +int mmc_regulator_get_supply(struct mmc_host *mmc, struct mmc_supply *s)
> +{
> + struct device *dev = mmc_dev(mmc);
> + struct regulator *supply;
> + int ret;
> +
> + if (!mmc || !s)
> + return -EINVAL;
> +
> + supply = devm_regulator_get(dev, "vmmc");
> +
> + if (IS_ERR(supply))
> + return PTR_ERR(supply);
> +
> + s->vmmc = supply;
> + s->vqmmc = devm_regulator_get(dev, "vqmmc");

Should we set vqmmc to NULL if an error was returned ?

> +
> + ret = mmc_regulator_get_ocrmask(supply);
> + if (ret > 0)
> + mmc->ocr_avail = ret;
> + else
> + dev_warn(mmc_dev(mmc), "Failed getting OCR mask: %d\n", ret);

I was wondering if  sdhci (or the other SD Host drivers can work if no 
ocr_avail mask is set ?  


> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(mmc_regulator_get_supply);
> +
> #endif /* CONFIG_REGULATOR */
> 
> /*
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 0707d22..3192335 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -359,11 +359,17 @@ static inline void mmc_signal_sdio_irq(struct mmc_host 
> *host)
> 
> struct regulator;
> 
> +struct mmc_supply {
> + struct regulator *vmmc; /* Card power supply */
> + struct regulator *vqmmc;/* Optional Vccq supply */
> +};
> +
> #ifdef CONFIG_REGULATOR
> int mmc_regulator_get_ocrmask(struct regulator *supply);
> int mmc_regulator_set_ocr(struct mmc_host *mmc,
>   struct regulator *supply,
>   unsigned short vdd_bit);
> +int mmc_regulator_get_supply(struct mmc_host *mmc, struct mmc_supply *s);
> #else
> static inline int mmc_regulator_get_ocrmask(struct regulator *supply)
> {
> @@ -376,6 +382,12 @@ static inline int mmc_regulator_set_ocr(struct mmc_host 
> *mmc,
> {
>   return 0;
> }
> +
> +static inline int mmc_regulator_get_supply(struct mmc_host *mmc,
> +struct mmc_supply *s)
> +{
> + return 0;
> +}
> #endif
> 
> int mmc_card_awake(struct mmc_host *host);
> -- 
> 1.7.2.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 4/5 v3] mmc: add a function to get a regulator, supplying card's Vdd

[Philip Rakity]

On Jun 11, 2012, at 7:23 AM, Mark Brown wrote:

> On Mon, Jun 11, 2012 at 02:39:29PM +0200, Guennadi Liakhovetski wrote:
>> On Mon, 28 May 2012, Mark Brown wrote:
> 
>>> Even if the supply is always on you can easily provide an always on
>>> regulator.  From the point of view of the consumer if there are two
>>> physical supplies needed it's much clearer and easier to just code that
>>> and deal with the fact that we might have no control over them
>>> externally, there's nothing device specific about that process.
> 
>> Mark, I'm not sure I understand your above comment correctly. The 
>> function, that I add in this patch doesn't do much now, that we removed 
> 
>> IIUC, to satisfy Philip's requirement for a second regulator it would 
>> suffice to just issue one more devm_regulator_get() and let the caller 
>> deal with any errors. Is this what you're suggesting or are you against 
>> adding the second regulator? We could of course also add it later, but 
>> that would change the function prototype (unless we add regulator pointers 
>> to struct mmc_host itself). Whith existing users such changes are a bit 
>> messy...
> 
> Yes, that's what I'm suggesting.  I guess you could wrap the two
> regulators up in a small struct without it being too invasive?


Some background notes:
Historically SD cards operated with the same vccq (signaling for dat and clk 
pins)
and vcc (core) voltage.
usually 3.3v --> we would use one regulator to supply both.  The power 
(regulator)
was always on and as far as the SD code was concerned never exposed
(eg regulator_get (vmmc) returned an error).

Now enter UHS cards.  They allow (require) the vccq voltage change from
3.3v to 1.8v when operating in UHS mode (DDR50, SDR50, SDR104).
They also note that when a voltage switch is done to move the card 
into UHS mode (3.3V to 1.8V) the switch may fail.  In this case vcc
needs to turned off and then back on to cause the card to reinitialize.

This led me to the conclusion two regulators are required.
vccq must be switchable between 3.3 and 1.8
vcc must be able to be turned off/on and may be switchable to a lower voltage.

Note: embedded MMC is different (eMMC).  Since it is embedded it is
assumed by the spec that the board designed knows that they are doing
and the correct voltages are supplied. 



--
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] regulator: pass voltage when calling notifier for change

[Philip Rakity]

The notified call back does pass the voltage that has
changed when calling the notifier callback.  This makes
it impossible to know what to do.  Pass the data
parameter (voltage) to the notifier.

A call to regulator_get_voltage cannot be made by the
receiver of the notifier since the mutex is held by
the regulator code and the call is blocked.  Deadlock
occurs.

This code was tested on a slightly earlier version of
linux where it was used to adjust the chip pad voltage
when doing SD vccq signaling for SDXC cards.

Signed-off-by: Philip Rakity 
---
 drivers/regulator/core.c |   15 ++-
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e70dd38..f3d66d6 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1916,11 +1916,16 @@ static int _regulator_do_set_voltage(struct 
regulator_dev *rdev,
udelay(delay);
}
 
-   if (ret == 0)
-   _notifier_call_chain(rdev, REGULATOR_EVENT_VOLTAGE_CHANGE,
-NULL);
+   if (ret == 0) {
+   int voltage;
 
-   trace_regulator_set_voltage_complete(rdev_get_name(rdev), selector);
+   voltage = _regulator_get_voltage(rdev);
+   if (voltage >= 0)
+   _notifier_call_chain(rdev,
+   REGULATOR_EVENT_VOLTAGE_CHANGE,
+   (void *)voltage);
+   }
+   trace_regulator_set_voltage_complete(rdev_get_name(rdev), ret);
 
return ret;
 }
@@ -2405,7 +2410,7 @@ static void _notifier_call_chain(struct regulator_dev 
*rdev,
  unsigned long event, void *data)
 {
/* call rdev chain first */
-   blocking_notifier_call_chain(&rdev->notifier, event, NULL);
+   blocking_notifier_call_chain(&rdev->notifier, event, data);
 }
 
 /**
-- 
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: sdhci: Allow CAPABILITY_1 Register to be overridden

[Philip Rakity]

On Jun 5, 2012, at 7:11 PM, Mark F. Brown wrote:

> Hi Philip,
> 
> Minor nitpicks: You should reuse SDHCI_QUIRK_MISSING_CAPS rather than
> adding SDHCI_QUIRK2_MISSING_CAPS2. The less quirks the better IMHO.

I am not sure that this is a good idea.  It breaks the existing code for people 
using quirks
for capability register 1.

> 
> Also add an initializer for caps array rather than having an else statement:
> 
> Instead of this:
> +   } else
> +   caps[1] = 0;
> 
> Do this:
> u32 caps[2] = { 0, 0 };

okay

> 
> -- Mark
> 
> On Sat, Jun 2, 2012 at 4:30 PM,   wrote:
>> From: Philip Rakity 
>> 
>> CAPABILITY_1 can be changed by the platform code using a quirk
>> CAPALBILTY_2 should also be allowed to be redefined.
>> 
>> This is useful if UHS or other modes are not supported that
>> are defined in the the register but the platform code has
>> specific information that these value should be changed.
>> 
>> Signed-off-by: Philip Rakity 
>> ---
>>  drivers/mmc/host/sdhci.c  |7 +--
>>  include/linux/mmc/sdhci.h |4 +++-
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index e626732..0fec448 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -2614,8 +2614,11 @@ int sdhci_add_host(struct sdhci_host *host)
>>caps[0] = (host->quirks & SDHCI_QUIRK_MISSING_CAPS) ? host->caps :
>>sdhci_readl(host, SDHCI_CAPABILITIES);
>> 
>> -   caps[1] = (host->version >= SDHCI_SPEC_300) ?
>> -   sdhci_readl(host, SDHCI_CAPABILITIES_1) : 0;
>> +   if (host->version >= SDHCI_SPEC_300) {
>> +   caps[1] = (host->quirks & SDHCI_QUIRK2_MISSING_CAPS1) ?
>> +   host->caps1 : sdhci_readl(host, SDHCI_CAPABILITIES_1);
>> +   } else
>> +   caps[1] = 0;
>> 
>>if (host->quirks & SDHCI_QUIRK_FORCE_DMA)
>>host->flags |= SDHCI_USE_SDMA;
>> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
>> index e9051e1..560fe22 100644
>> --- a/include/linux/mmc/sdhci.h
>> +++ b/include/linux/mmc/sdhci.h
>> @@ -91,6 +91,7 @@ struct sdhci_host {
>>unsigned int quirks2;   /* More deviations from spec. */
>> 
>>  #define SDHCI_QUIRK2_HOST_OFF_CARD_ON  (1<<0)
>> +#define SDHCI_QUIRK2_MISSING_CAPS1 (1<<1)
>> 
>>int irq;/* Device IRQ */
>>void __iomem *ioaddr;   /* Mapped address */
>> @@ -155,7 +156,8 @@ struct sdhci_host {
>> 
>>struct timer_list timer;/* Timer for timeouts */
>> 
>> -   unsigned int caps;  /* Alternative capabilities */
>> +   unsigned int caps;  /* replace capability register 1 */
>> +   unsigned int caps1; /* replace capability register 2 */
>> 
>>unsigned intocr_avail_sdio; /* OCR bit masks */
>>unsigned intocr_avail_sd;
>> --
>> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] mmc: do not attempt UHS 1.8v support if board does not support it

[Philip Rakity]

Alan,

I have your patch in my mmc-next.  Our controller indicates it SUPPORTS UHS 
modes.
The regulators do NOT.  Cannot switch to 1.8v.  

Not the same problem as you saw.

Philip


On Jun 1, 2012, at 6:55 AM, Alan Cooper wrote:

> I recently added a patch that prevents the switch to 1.8v if the host
> capabilities register does not indicate support for any of the UHS
> speeds (SDR50, DDR50, SDR104). This allowed our controller to work
> with UHS cards in HS mode (50MHz, 3.3v).
> 
> Al
> 
> On Sun, May 27, 2012 at 9:36 PM,   wrote:
>> From: Philip Rakity 
>> 
>> We have h/w that does not support 1.8v signaling even though the
>> controller does support this.  If we enable 1.8v support UHS
>> cards are recognised but recovery to 3.3v is not possible
>> depending on the SD card.
>> 
>> Ensure that when we do not support 1.8v UHS mode cards can
>> work (in non UHS mode).
>> 
>> Signed-off-by: Philip Rakity 
>> ---
>>  drivers/mmc/host/sdhci.c  |   71 
>> +++-
>>  include/linux/mmc/sdhci.h |3 ++
>>  2 files changed, 40 insertions(+), 34 deletions(-)
>> 
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 8d8dff0..f9b37c4 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -2782,27 +2782,45 @@ int sdhci_add_host(struct sdhci_host *host)
>>mmc_card_is_removable(mmc))
>>mmc->caps |= MMC_CAP_NEEDS_POLL;
>> 
>> -   /* Any UHS-I mode in caps implies SDR12 and SDR25 support. */
>> -   if (caps[1] & (SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
>> -  SDHCI_SUPPORT_DDR50))
>> -   mmc->caps |= MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25;
>> +   if (!(host->quirks2 & SDHCI_QUIRK2_HOST_NO_UHS_1_8V_SUPPORT)) {
>> +   /* Any UHS-I mode in caps implies SDR12 and SDR25 support. */
>> +   if (caps[1] & (SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
>> +  SDHCI_SUPPORT_DDR50))
>> +   mmc->caps |= MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25;
>> +
>> +   /* SDR104 supports also implies SDR50 support */
>> +   if (caps[1] & SDHCI_SUPPORT_SDR104)
>> +   mmc->caps |= MMC_CAP_UHS_SDR104 | MMC_CAP_UHS_SDR50;
>> +   else if (caps[1] & SDHCI_SUPPORT_SDR50)
>> +   mmc->caps |= MMC_CAP_UHS_SDR50;
>> +
>> +   if (caps[1] & SDHCI_SUPPORT_DDR50)
>> +   mmc->caps |= MMC_CAP_UHS_DDR50;
>> +
>> +   /* Does the host need tuning for SDR50? */
>> +   if (caps[1] & SDHCI_USE_SDR50_TUNING)
>> +   host->flags |= SDHCI_SDR50_NEEDS_TUNING;
>> +
>> +   /* Does the host need tuning for HS200? */
>> +   if (mmc->caps2 & MMC_CAP2_HS200)
>> +   host->flags |= SDHCI_HS200_NEEDS_TUNING;
>> +
>> +   /* Initial value for re-tuning timer count */
>> +   host->tuning_count =
>> +   (caps[1] & SDHCI_RETUNING_TIMER_COUNT_MASK) >>
>> +   SDHCI_RETUNING_TIMER_COUNT_SHIFT;
>> 
>> -   /* SDR104 supports also implies SDR50 support */
>> -   if (caps[1] & SDHCI_SUPPORT_SDR104)
>> -   mmc->caps |= MMC_CAP_UHS_SDR104 | MMC_CAP_UHS_SDR50;
>> -   else if (caps[1] & SDHCI_SUPPORT_SDR50)
>> -   mmc->caps |= MMC_CAP_UHS_SDR50;
>> -
>> -   if (caps[1] & SDHCI_SUPPORT_DDR50)
>> -   mmc->caps |= MMC_CAP_UHS_DDR50;
>> -
>> -   /* Does the host need tuning for SDR50? */
>> -   if (caps[1] & SDHCI_USE_SDR50_TUNING)
>> -   host->flags |= SDHCI_SDR50_NEEDS_TUNING;
>> +   /*
>> +* In case Re-tuning Timer is not disabled, the actual value 
>> of
>> +* re-tuning timer will be 2 ^ (n - 1).
>> +*/
>> +   if (host->tuning_count)
>> +   host->tuning_count = 1 << (host->tuning_count - 1);
>> 
>> -   /* Does the host need tuning for HS200? */
>> -   if (mmc->caps2 & MMC_CAP2_HS200)
>> -   host->flags |= SDHCI_HS200_NEEDS_TUNING;
>> +   /* Re-tuning mode supported by the Host Controller */
>> +   host->tuning_mode = (caps[1] & SDHCI_RETUNING_MODE_MAS

Re: [PATCH 4/5 v3] mmc: add a function to get a regulator, supplying card's Vdd

[Philip Rakity]

I have started looking at this area and I am rather confused.  It seems to me 
two "dedicated" regulators are required.
One regulator controls VDD (vcc) and this is the regulator called vmmc.  This 
regulator MAY support the ability to switch voltages and MAY support the 
ability to be turned on and off.
The other regulator supports signal voltage (vccq) for UHS and SDXC cards.  
Currently this is not in sdhci.c (I have a patch for this in preparation).  Use 
of this regulator requires that the VDD regulator be capable of being set to 
1.8 or 3.3v and be capable of being turned on/off.  on/off support is needed is 
the switch to 1.8v signaling fails for any reason.



On May 27, 2012, at 8:20 PM, Ulf Hansson wrote:

> Hi Guennadi,
> 
> On 25 May 2012 17:14, Guennadi Liakhovetski  wrote:
>> Add a function to get a regulator, supplying card's Vdd on a specific host.
>> If such a regulator is found, the function checks, whether a valid OCR mask
>> can be obtained from this regulator.
>> 
>> Signed-off-by: Guennadi Liakhovetski 
>> ---
>> 
>> v3: remove bogus attempts to ignore the dummy regulator, drop the check
>> for whether the regulator can change status, do not assign
>> MMC_CAP_POWER_OFF_CARD automatically. Thanks to Mark and Magnus for
>> comments.
>> 
>>  drivers/mmc/core/core.c  |   17 +
>>  include/linux/mmc/host.h |6 ++
>>  2 files changed, 23 insertions(+), 0 deletions(-)
>> 
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index 0b6141d..0f92ec0 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -1013,6 +1013,23 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
>>  }
>>  EXPORT_SYMBOL(mmc_regulator_set_ocr);
>> 
>> +struct regulator *mmc_regulator_get_vmmc(struct mmc_host *mmc)
>> +{
>> +   struct device *dev = mmc_dev(mmc);
>> +   struct regulator *supply = devm_regulator_get(dev, "vmmc");
>> +   int ret;
>> +
>> +   if (IS_ERR(supply))
>> +   return NULL;
>> +
>> +   ret = mmc_regulator_get_ocrmask(supply);
>> +   if (ret > 0)
> 
> Could we have an "else" were a dev_warn prints some info and as well
> the "ret" maybe?
> 
>> +   mmc->ocr_avail = ret;
>> +
>> +   return supply;
>> +}
>> +EXPORT_SYMBOL(mmc_regulator_get_vmmc);
>> +
>>  #endif /* CONFIG_REGULATOR */
>> 
>>  /*
>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>> index 0707d22..368b317 100644
>> --- a/include/linux/mmc/host.h
>> +++ b/include/linux/mmc/host.h
>> @@ -364,6 +364,7 @@ int mmc_regulator_get_ocrmask(struct regulator *supply);
>>  int mmc_regulator_set_ocr(struct mmc_host *mmc,
>>struct regulator *supply,
>>unsigned short vdd_bit);
>> +struct regulator *mmc_regulator_get_vmmc(struct mmc_host *mmc);
>>  #else
>>  static inline int mmc_regulator_get_ocrmask(struct regulator *supply)
>>  {
>> @@ -376,6 +377,11 @@ static inline int mmc_regulator_set_ocr(struct mmc_host 
>> *mmc,
>>  {
>>return 0;
>>  }
>> +
>> +static inline struct regulator *mmc_regulator_get_vmmc(struct mmc_host *mmc)
>> +{
>> +   return NULL;
>> +}
>>  #endif
>> 
> 
> Some follow-up thoughts, if mmc_regulator_get_vmmc is supposed to be
> used from the host drivers, the mmc_regulator_get_ocrmask function do
> no longer have to be an exported function, but instead a static
> function on core.c I suppose this can be fixed in separate patch,
> where we also add mmc_regulator_get_vmmc for all host drivers?


 have started looking at this area and I am rather confused.  It seems to me 
two "dedicated" regulators are required.
One regulator controls VDD (vcc) and this is the regulator called vmmc.  This 
regulator MAY support the ability to switch voltages and MAY support the 
ability to be turned on and off.  The main sdhci.c code needs to check the 
voltages supported by the regulator against the voltages that the host 
controller supports and adjust the  mmc capabilities to the common set.  I 
don't think we do this at the moment.

The other regulator supports signal voltage (vccq) for UHS and SDXC cards.  
Currently this is not in sdhci.c (I have a patch for this in preparation).  Use 
of this regulator requires that the vccq regulator be capable of being set to 
1.8 or 3.3v and the VDD (vmmc) regulator be capable of being turned on/off.  
on/off support is needed is the switch to 1.8v signaling fails for any reason.



> 
> Kind regards
> Ulf Hansson
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

UHS Support

[Philip Rakity]

Voltage for vcc/vccq is supplied on some of our boards for SD using either a 
dedicated voltage supply at 3.3v.

The SD controller indicates in the capability1 register (caps[1])  that UHS is 
supported but since 1.8v is not available in practice there is no support.

There are two ways I can see to solve this problem

a) allow caps[1] to be passed in (like caps[0]) is today via a quirk) and have 
the caller to sdhci_add_host() just clear the bits for UHS support.
b) define a new quirk that indicates UHS is not supported.

I favor a) but wanted the list to have a chance to respond if there is a 
preference.

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

regulator advise needed

[Philip Rakity]

In sdhci_set_ios() we call sdhci_set_power()

this code assumes that the SDHCI_POWER_CONTROL register works in the SD 
controller.
In our controller it does not.  We need a regulator to do the right thing.

I hae added regulator support (patch coming)
BUT the code crashes because we are scheduling in atomic context  when 
sdhci_set_power() is called.

the current "hack" is

spin_unlock_irqrestore(&host->lock, flags);
printk("%s/%d: ios->power_mode = %x\n", __func__, __LINE__, ios->power_mode);
if (ios->power_mode == MMC_POWER_OFF)
sdhci_set_power(host, -1);
else
sdhci_set_power(host, ios->vdd);
spin_lock_irqsave(&host->lock, flags);


I could just disable the interrupt line on the controller while I do this 
change (like I proposed before)
but maybe someone knows another way to get there from here.

Philip
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] mmc:sdio:guarantee setting card data bus width as 4-bit

[Philip Rakity]

ACK

On May 14, 2012, at 10:09 PM, yongd wrote:

>  SDIO_CCCR_IF[1:0] in SDIO card is used for card data bus width
> setting as below,
> 00b: 1-bit bus
> 01b: Reserved
> 10b: 4-bit bus
> 11b: 8-bit bus(only for embedded SDIO)
>  And sdio_enable_wide is for setting data bus width as 4-bit. But
> currently, it 1stly read the register, 2ndly OR' 1b with SDIO_CCCR_IF[1],
> and then write it back.
>  As we can see, such way is based on such assumption that the
> SDIO_CCCR_IF[0] is always 0. Apparently, this is not right.
> 
> Signed-off-by: yongd 
> ---
> drivers/mmc/core/sdio.c  |7 +++
> include/linux/mmc/sdio.h |2 ++
> 2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index 13d0e95..7b528cf 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -218,6 +218,13 @@ static int sdio_enable_wide(struct mmc_card *card)
>   if (ret)
>   return ret;
> 
> + if ((ctrl & SDIO_BUS_WIDTH_MASK)
> + == SDIO_BUS_WIDTH_RESERVED)
> + printk(KERN_WARNING"%s: SDIO_CCCR_IF is invalid: 0x%02X\n",
> + mmc_hostname(card->host), ctrl);
> +
> + /* set as 4-bit bus width */
> + ctrl &= ~SDIO_BUS_WIDTH_MASK;
>   ctrl |= SDIO_BUS_WIDTH_4BIT;
> 
>   ret = mmc_io_rw_direct(card, 1, 0, SDIO_CCCR_IF, ctrl, NULL);
> diff --git a/include/linux/mmc/sdio.h b/include/linux/mmc/sdio.h
> index c9fe66c..17446d3 100644
> --- a/include/linux/mmc/sdio.h
> +++ b/include/linux/mmc/sdio.h
> @@ -98,7 +98,9 @@
> 
> #define SDIO_CCCR_IF  0x07/* bus interface controls */
> 
> +#define  SDIO_BUS_WIDTH_MASK 0x03/* data bus width setting */
> #define  SDIO_BUS_WIDTH_1BIT  0x00
> +#define  SDIO_BUS_WIDTH_RESERVED 0x01
> #define  SDIO_BUS_WIDTH_4BIT  0x02
> #define  SDIO_BUS_ECSI0x20/* Enable continuous SPI 
> interrupt */
> #define  SDIO_BUS_SCSI0x40/* Support continuous SPI 
> interrupt */
> -- 
> 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:sdio:guarantee setting card data bus width as 4-bit

[Philip Rakity]

ACK

but see below for printk change


On May 14, 2012, at 1:35 AM, yongd wrote:

>  SDIO_CCCR_IF[1:0] in SDIO card is used for card data bus width
> setting as below,
> 00b: 1-bit bus
> 01b: Reserved
> 10b: 4-bit bus
> 11b: 8-bit bus(only for embedded SDIO)
>  And sdio_enable_wide is for setting data bus width as 4-bit. But
> currently, it 1stly read the register, 2ndly OR' 1b with SDIO_CCCR_IF[1],
> and then write it back.
>  As we can see, such way is based on such assumption that the
> SDIO_CCCR_IF[0] is always 0. Apparently, this is not right.
> 
> Signed-off-by: yongd 
> ---
> drivers/mmc/core/sdio.c  |6 ++
> include/linux/mmc/sdio.h |2 ++
> 2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index 13d0e95..6b6f902 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -218,6 +218,12 @@ static int sdio_enable_wide(struct mmc_card *card)
>   if (ret)
>   return ret;
> 
> + if ((ctrl & SDIO_BUS_WIDTH_MASK)
> + == SDIO_BUS_WIDTH_RESERVED)
> + printk(KERN_WARNING"SDIO_CCCR_IF is invalid: %d\n", ctrl);
printk(KERN_WARNING("%s: SDIO_CCCR_IF is invalid: %02X\n", 
mmc_hostname(card->host), ctrl);

please double check mmc_hostname argument.

> +
> + /* set as 4-bit bus width */
> + ctrl &= ~SDIO_BUS_WIDTH_MASK;
>   ctrl |= SDIO_BUS_WIDTH_4BIT;
> 
>   ret = mmc_io_rw_direct(card, 1, 0, SDIO_CCCR_IF, ctrl, NULL);
> diff --git a/include/linux/mmc/sdio.h b/include/linux/mmc/sdio.h
> index c9fe66c..17446d3 100644
> --- a/include/linux/mmc/sdio.h
> +++ b/include/linux/mmc/sdio.h
> @@ -98,7 +98,9 @@
> 
> #define SDIO_CCCR_IF  0x07/* bus interface controls */
> 
> +#define  SDIO_BUS_WIDTH_MASK 0x03/* data bus width setting */
> #define  SDIO_BUS_WIDTH_1BIT  0x00
> +#define  SDIO_BUS_WIDTH_RESERVED 0x01
> #define  SDIO_BUS_WIDTH_4BIT  0x02
> #define  SDIO_BUS_ECSI0x20/* Enable continuous SPI 
> interrupt */
> #define  SDIO_BUS_SCSI0x40/* Support continuous SPI 
> interrupt */
> -- 
> 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 4/4] mmc: core: Send HPI only till it is successful

[Philip Rakity]

On Apr 13, 2012, at 7:39 AM, Namjae Jeon wrote:

> Hi. Venkatraman.
> 
> You fixed 10 times. why is it 10 times ?
> and checking err from mmc_send_status is not needed ? is it  also
> infinite case ?
> 
> Thanks.
> 
> 2012/4/13 Venkatraman S :
>> Try to send HPI only a fixed number of times till it is
>> successful. One successful transfer is enough - but wait
>> till the card comes out of transfer state.
>> Return an error if the card was not in programming state to
>> begin with - so that the caller knows that HPI was not sent.
>> 
>> Reported-by: Alex Lemberg 
>> Signed-off-by: Venkatraman S 
>> ---
>>  drivers/mmc/core/core.c |   34 ++
>>  1 file changed, 18 insertions(+), 16 deletions(-)
>> 
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index e541efb..ceabef5 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -401,7 +401,7 @@ EXPORT_SYMBOL(mmc_wait_for_req);
>>  */
>>  int mmc_interrupt_hpi(struct mmc_card *card)
>>  {
>> -   int err;
>> +   int err, i;
>>u32 status;
>> 
>>BUG_ON(!card);
>> @@ -421,27 +421,29 @@ int mmc_interrupt_hpi(struct mmc_card *card)
>>/*
>> * If the card status is in PRG-state, we can send the HPI command.
>> */
>> +   err = -EINVAL;
>>if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
>> -   do {
>> -   /*
>> -* We don't know when the HPI command will finish
>> -* processing, so we need to resend HPI until out
>> -* of prg-state, and keep checking the card status
>> -* with SEND_STATUS.  If a timeout error occurs when
>> -* sending the HPI command, we are already out of
>> -* prg-state.
>> -*/
>> +   /* To prevent an infinite lockout, try to send HPI
>> +* a fixed number of times and bailout if it can't
>> +* succeed.
>> +*/
>> +   for (i = 0; i < 10 && err != 0 ; i++)


would it make more sense to check time as well as retry count ?
worry that count may be too short or behavior is dependent on card manufacturer.


>>err = mmc_send_hpi_cmd(card, &status);
>> -   if (err)
>> +   /* Once HPI was sent successfully, the card is
>> +* supposed to be back to transfer state.
>> +*/
>> +   do {
>> +   if (err) {
>>pr_debug("%s: abort HPI (%d error)\n",
>> mmc_hostname(card->host), err);
>> -
>> -   err = mmc_send_status(card, &status);
>> -   if (err)
>>break;
>> +   }
>> +   err = mmc_send_status(card, &status);
>>} while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
>> -   } else
>> -   pr_debug("%s: Left prg-state\n", mmc_hostname(card->host));
>> +   } else {
>> +   pr_debug("%s: Can't send HPI. State=%d\n",
>> +   mmc_hostname(card->host), R1_CURRENT_STATE(status));
>> +   }
>> 
>>  out:
>>mmc_release_host(card->host);
>> --
>> 1.7.10.rc2
>> 
>> --
>> 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
> N�r��y���b�X��ǧv�^�)޺{.n�+{��g"��^n�r���z���h&���G���h�(�階�ݢj"���m�z�ޖ���f���h���~�m�

N�r��yb�X��ǧv�^�)޺{.n�+{��g"��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Re: [PATCH 2/2] mmc: Remove dead code

[Philip Rakity]

Acked-by: Philip Rakity 

On Apr 11, 2012, at 1:32 PM, Philippe De Swert wrote:

> bus_width is passed to the function and when 0 (MMC_BUS_WIDTH_1)
> will cause the function to return. So in in the second test it 
> definitly is different from 0, and the third test is redundant.
> 
> Signed-off-by: Philippe De Swert 
> ---
> drivers/mmc/core/mmc.c |6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 54df5ad..4a1bf8f 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -556,14 +556,10 @@ static int mmc_compare_ext_csds(struct mmc_card *card, 
> unsigned bus_width)
>   err = mmc_get_ext_csd(card, &bw_ext_csd);
> 
>   if (err || bw_ext_csd == NULL) {
> - if (bus_width != MMC_BUS_WIDTH_1)
> - err = -EINVAL;
> + err = -EINVAL;
>   goto out;
>   }
> 
> - if (bus_width == MMC_BUS_WIDTH_1)
> - goto out;
> -
>   /* only compare read only fields */
>   err = !((card->ext_csd.raw_partition_support ==
>   bw_ext_csd[EXT_CSD_PARTITION_SUPPORT]) &&
> -- 
> 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: Prevent 1.8V switch for SD hosts that don't support UHS modes.

[Philip Rakity]

Acked-by: Philip Rakity 

On Apr 3, 2012, at 8:46 PM, Nath, Arindam wrote:

> Hi,
> 
> 
>> -Original Message-
>> From: Chris Ball [mailto:c...@laptop.org]
>> Sent: Tuesday, April 03, 2012 6:12 AM
>> To: Alan Cooper
>> Cc: linux-mmc@vger.kernel.org; Girish K S; Ulf Hansson; Nath, Arindam;
>> Philip Rakity
>> Subject: Re: [PATCH] mmc: Prevent 1.8V switch for SD hosts that don't
>> support UHS modes.
>> 
>> Hi Al,
>> 
>> On Mon, Apr 02 2012, Alan Cooper wrote:
>>> Still hoping for comments on the patch.
>> 
>> Thanks for the reminder; adding a few potential reviewers to CC:.
> 
> Acked-by: Arindam Nath 
> 
> Regards,
> Arindam
> 
>> 
>> - Chris.
>> 
>>> On Fri, Mar 16, 2012 at 3:54 PM, Al Cooper  wrote:
>>>> The driver should not try to switch to 1.8V when the SD 3.0 host
>>>> controller does not have any UHS capabilities bits set (SDR50, DDR50
>>>> or SDR104). See page 72 of "SD Specifications Part A2 SD Host
>>>> Controller Simplified Specification Version 3.00" under
>>>> "1.8V Signaling Enable". Instead of setting SDR12 and SDR25 in the
>> host
>>>> capabilities data structure for all V3.0 host controllers, only set
>> them
>>>> if SDR104, SDR50 or DDR50 is set in the host capabilities register.
>> This
>>>> will prevent the switch to 1.8V later.
>>>> 
>>>> Signed-off-by: Al Cooper 
>>>> ---
>>>>  drivers/mmc/host/sdhci.c |5 +++--
>>>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>>> index 8d66706..cdf900e 100644
>>>> --- a/drivers/mmc/host/sdhci.c
>>>> +++ b/drivers/mmc/host/sdhci.c
>>>> @@ -2762,8 +2762,9 @@ int sdhci_add_host(struct sdhci_host *host)
>>>>mmc_card_is_removable(mmc))
>>>>mmc->caps |= MMC_CAP_NEEDS_POLL;
>>>> 
>>>> -   /* UHS-I mode(s) supported by the host controller. */
>>>> -   if (host->version >= SDHCI_SPEC_300)
>>>> +   /* Any UHS-I mode in caps implies SDR12 and SDR25 support.
>> */
>>>> +   if (caps[1] & (SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
>>>> +  SDHCI_SUPPORT_DDR50))
>>>>mmc->caps |= MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25;
>>>> 
>>>>/* SDR104 supports also implies SDR50 support */
>>>> --
>>>> 1.7.6
>> 
>> --
>> Chris Ball  <http://printf.net/>
>> One Laptop Per Child
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Patch v1]mmc:core: correct mmc_erase_timeout calculation

[Philip Rakity]

On Mar 28, 2012, at 7:50 PM, Dong, Chuanxiao wrote:

>> -Original Message-
>> From: Namjae Jeon [mailto:linkinj...@gmail.com]
>> Sent: Wednesday, March 28, 2012 8:36 PM
>> To: Dong, Chuanxiao
>> Cc: linux-mmc@vger.kernel.org; c...@laptop.org; Hunter, Adrian
>> Subject: Re: [Patch v1]mmc:core: correct mmc_erase_timeout calculation
>> 
>> If ERASE_GROUP_DEF is disable with secure erase, erase timeout is calculated 
>> with
>> 300ms * ERASE_TIMEOUT_MULT. Is it right ?
> 
> My understanding about the JESD84-A441 is different with current 
> mmc_mmc_erase_timeout implemented. From the EXT_CSD[230], seems no matter 
> ERASE_GROUP_DEF is enabled or not, secure erase timeout is calculated as 
> 300ms * ERASE_TIMEOUT_MULT * SECURE_ERASE_MULT. That is why I submitted this 
> patch.
> 

This is what is in the draft 4.51 spec

> Does someone else can correct me if my understanding about the erase timeout 
> calculation is wrong?
> 
> Thanks
> Chuanxiao
> 
>> 
>> Thanks.
>> 
>> 2012/3/28 Dong, Chuanxiao :
>>> What I am checking with is eMMC4.41 spec, not eMMC4.5 spec.
>>> Forward you the link:
>>> www.jedec.org/sites/default/files/docs/JESD84-A441.pdf
>>> 
>>> Thanks
>>> Chuanxiao
>>> 
 -Original Message-
 From: Namjae Jeon [mailto:linkinj...@gmail.com]
 Sent: Wednesday, March 28, 2012 5:17 PM
 To: Dong, Chuanxiao
 Cc: linux-mmc@vger.kernel.org; c...@laptop.org; Hunter, Adrian
 Subject: Re: [Patch v1]mmc:core: correct mmc_erase_timeout
 calculation
 
 Hi. Chuanxiao.
 Would you share your specification with me ?
 When I check the latest emmc 4.5 spec, I can not find it.
 Thanks.
 
 2012/3/28 Chuanxiao Dong :
> According to JEDEC 7.8.2, mmc_erase_timeout calculation should be follow:
> 1. Secure erase timeout = 300ms * ERASE_TIMEOUT_MULT *
> SEC_ERASE_MULT 2. Secure trim timeout = 300ms * ERASE_TIMEOUT_MULT *
>> SEC_TRIM_MULT 3.
> Trim timeout = 300ms * TRIM_MULT 4. Erase timeout:
>   a. if ERASE_GROUP_DEF is true: Erase timeout = 300ms *
> ERASE_TIMEOUT_MULT
>   b. if ERASE_GROUP_DEF is false: Erase timeout = write block delay
> 
> Signed-off-by: Chuanxiao Dong 
> ---
>  drivers/mmc/core/core.c |   42
> +-
>  1 files changed, 29 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 14f262e..d9d6d1c 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1405,12 +1405,36 @@ static unsigned int
> mmc_mmc_erase_timeout(struct mmc_card *card,
>  {
>unsigned int erase_timeout;
> 
> -   if (card->ext_csd.erase_group_def & 1) {
> -   /* High Capacity Erase Group Size uses HC timeouts
> */
> -   if (arg == MMC_TRIM_ARG)
> -   erase_timeout = card->ext_csd.trim_timeout;
> +   /*
> +* JEDEC 7.8.2
> +*
> +* 1. Secure erase/trim timeout is calculated absed on
> + Erase Timeout
> +* and additional SEC_ERASE_MULT/SEC_TRIM_MULT.
> +* So secure erase/trim timeout = ERASE Timeout *
> + SEC_ERASE_MULT/
> +* SEC_TRIM_MULT.
> +* ERASE Timeout = 300ms * ERASE_TIMEOUT_MULT
> +*
> +* 2. trim timeout is calculated based on the TRIM_MULT factor.
> +* So trim timeout = 300ms * TRIM_MULT
> +*
> +* 3. erase timeout calculation:
> +*  a. if ERASE_GROUP_DEF is enabled,
> + ERASE_TIMEOUT_MULT should be
> +*  used to calculate erase timeout, so:
> +*  erase timeout = 300 * ERASE_TIMEOUT_MULT
> +*  b. if ERASE_GROUP_DEF is diabled, the duration of
> + an erase
> +*  command will be the number of Erase blocks to be
> + erased
> +*  multiplied by the block write delay.
> +*/
> +   if (arg & MMC_SECURE_ARGS) {
> +   erase_timeout = card->ext_csd.hc_erase_timeout;
> +   if (arg == MMC_SECURE_ERASE_ARG)
> +   erase_timeout *=
> + card->ext_csd.sec_erase_mult;
>else
> -   erase_timeout =
> card->ext_csd.hc_erase_timeout;
> +   erase_timeout *=
> + card->ext_csd.sec_trim_mult;
> +   } else if (arg & MMC_TRIM_ARGS) {
> +   erase_timeout = card->ext_csd.trim_timeout;
> +   } else if (card->ext_csd.erase_group_def & 1) {
> +   erase_timeout = card->ext_csd.hc_erase_timeout;
>} else {
>/* CSD Erase Group Size uses write timeout */
>unsigned int mult = (10 << card->csd.r2w_factor); @@
> -1441,14 +1465,6 @@ static unsigned int
> mmc_mmc_erase_timeout(struct mmc_card *card,
>

Re: [PATCH] mmc: core: Fixup suspend/resume issues for UHS-I cards

[Philip Rakity]

acked-by: Philip Rakity 

On Mar 1, 2012, at 4:18 AM, Ulf Hansson wrote:

> Even if cards supports 1.8V I/O voltage those should anyway be
> initialized at 3.3V I/O according to (e)MMC, SD and SDIO specs.
> Some eMMC and embedded SDIO devices are able to be initialized
> at 1.8V as well, but it is better to be safe.
> 
> Do note that initialization in this context means that the card
> has been completely powered off, otherwise the card will remain
> at the last I/O voltage level that were negotitiated.
> 
> Due to the above being taken care of the suspend/resume issues
> for UHS-I SD-cards has been fixed.
> 
> Change-Id: Ia906f69d44b5be8374b0b536881190f67757b03e
> Signed-off-by: Ulf Hansson 
> ---
> drivers/mmc/core/core.c |3 +++
> drivers/mmc/core/mmc.c  |3 +++
> drivers/mmc/core/sd.c   |8 +++-
> drivers/mmc/core/sdio.c |9 +
> 4 files changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 0b317f0..faa0af1 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -2074,6 +2074,9 @@ static int mmc_rescan_try_freq(struct mmc_host *host, 
> unsigned freq)
>*/
>   mmc_hw_reset_for_init(host);
> 
> + /* Initialization should be done at 3.3 V I/O voltage. */
> + mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
> +
>   /*
>* sdio_reset sends CMD52 to reset card.  Since we do not know
>* if the card is being re-initialized, just send it.  CMD52
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 6b13776..6defddd 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -830,6 +830,9 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
>   if (!mmc_host_is_spi(host))
>   mmc_set_bus_mode(host, MMC_BUSMODE_OPENDRAIN);
> 
> + /* Initialization should be done at 3.3 V I/O voltage. */
> + mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
> +
>   /*
>* Since we're changing the OCR value, we seem to
>* need to tell some cards to go back to the idle
> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
> index 5017f93..c272c686 100644
> --- a/drivers/mmc/core/sd.c
> +++ b/drivers/mmc/core/sd.c
> @@ -911,6 +911,9 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 
> ocr,
>   BUG_ON(!host);
>   WARN_ON(!host->claimed);
> 
> + /* The initialization should be done at 3.3 V I/O voltage. */
> + mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
> +
>   err = mmc_sd_get_cid(host, ocr, cid, &rocr);
>   if (err)
>   return err;
> @@ -1156,11 +1159,6 @@ int mmc_attach_sd(struct mmc_host *host)
>   BUG_ON(!host);
>   WARN_ON(!host->claimed);
> 
> - /* Make sure we are at 3.3V signalling voltage */
> - err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, false);
> - if (err)
> - return err;
> -
>   /* Disable preset value enable if already set since last time */
>   if (host->ops->enable_preset_value) {
>   mmc_host_clk_hold(host);
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index 12cde6e..dac2e23 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -585,6 +585,10 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 
> ocr,
>* Inform the card of the voltage
>*/
>   if (!powered_resume) {
> +
> + /* The initialization should be done at 3.3 V I/O voltage. */
> + mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
> +
>   err = mmc_send_io_op_cond(host, host->ocr, &ocr);
>   if (err)
>   goto err;
> @@ -996,6 +1000,11 @@ static int mmc_sdio_power_restore(struct mmc_host *host)
>* With these steps taken, mmc_select_voltage() is also required to
>* restore the correct voltage setting of the card.
>*/
> +
> + if (!mmc_card_keep_power(host))
> + /* The initialization should be done at 3.3 V I/O voltage. */
> + mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
> +
>   sdio_reset(host);
>   mmc_go_idle(host);
>   mmc_send_if_cond(host, host->ocr_avail);
> -- 
> 1.7.7.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mmc sdhci mmcblk0: error -110 sending status command, retrying

[Philip Rakity]

On Feb 10, 2012, at 8:18 AM, Jeff Chua wrote:

> On Thu, Feb 9, 2012 at 3:09 AM, Philip Rakity  wrote:
>> 
>> 
>> Jeff,
>> 
>> I think the sdhci.c clock setting code was changed a while ago.   Maybe 
>> revert that mod and see what happens.
>> 
>> The card is a 24MHz which is rather slow so I would be surprised if that was 
>> it.
>> The other option is the force enable the High Speed bit in the  controller 
>> (used when speed is 25MHz or faster).  Will give the system more time (in 
>> theory) to work.
> 
> That's a good point to start looking. I poked around and by setting
> host->ios.clock to 1000 instead of 2500, read from a 16GB card
> is no longer giving any error.
> 
> I still don't dare to do any write. Already burn one 16GB SD and not
> ready to trash another. I asked earlier but haven't got any reply as
> to how to recover an SD that says "No medium found". Any chance of
> recovering it?
> 
> Here's what I did. If set too low (100) or too high (2500),
> random errors appeared.
> 
> --- linux/drivers/mmc/core/core.c.org   2012-02-10 23:57:49.0 +0800
> +++ linux/drivers/mmc/core/core.c   2012-02-10 23:53:59.0 +0800
> @@ -881,7 +881,7 @@
>if (hz > host->f_max)
>hz = host->f_max;
> 
> -   host->ios.clock = hz;
> +   host->ios.clock = 1000;
>mmc_set_ios(host);
> }
> 
> 

good news.  The other possibility but unlikely is that the timeout is too low 
for the card.

There is a quirk for this.

SDHCI_BROKEN_TIMEOUT_VAL

my guess is that you will need to measure the clk pin and see if it matches the 
frequency being programmed.  (could be less).

a simple hack is to add a printk to set_ios() or set_clock() and print out the 
clock rate clock register (divider) and see if they match what you should be 
seeing.
It is possible the bug is NOT in this area but in the platform code where an 
incorrect base freq is being setup for the controller.

Philip

> 
> Thanks,
> Jeff

--
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: mmc sdhci mmcblk0: error -110 sending status command, retrying

[Philip Rakity]

Jeff,

I think the sdhci.c clock setting code was changed a while ago.   Maybe revert 
that mod and see what happens.

The card is a 24MHz which is rather slow so I would be surprised if that was 
it. 
The other option is the force enable the High Speed bit in the  controller 
(used when speed is 25MHz or faster).  Will give the system more time (in 
theory) to work.  

Philip

On Feb 7, 2012, at 5:09 PM, Jeff Chua wrote:

> On Wed, Feb 8, 2012 at 7:45 AM, Jaehoon Chung  wrote:
>> On 02/08/2012 03:33 AM, Jeff Chua wrote:
> 
> I tried a Class6 8GB and after a few inserts, it could read without
> errors. The Class10 seems to be more sensitive to speed.
> 
> Jeff

--
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: core: UHS sdio card that fails should not exceed 50MHz

[Philip Rakity]

A UHS sdio card that fails initialization at 1.8v signaling
is not in UHS mode.  We cannot use the speed in the the cis
to reflect the bus speed as this is the maxiumum value and
will not reflect the fact that the host is operating at a
lower (non uhs) bus speed.

Signed-off-by: Philip Rakity 
Signed-off-by: Bing Zhao 
Reviewed-by: Aaron Lu 
---
drivers/mmc/core/sdio.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index b77f770..8b626ad 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -97,10 +97,11 @@ fail:
return ret;
}

-static int sdio_read_cccr(struct mmc_card *card)
+static int sdio_read_cccr(struct mmc_card *card, u32 ocr)
{
int ret;
int cccr_vsn;
+   int uhs = ocr & R4_18V_PRESENT;
unsigned char data;
unsigned char speed;

@@ -148,7 +149,7 @@ static int sdio_read_cccr(struct mmc_card *card)
card->scr.sda_spec3 = 0;
card->sw_caps.sd3_bus_mode = 0;
card->sw_caps.sd3_drv_type = 0;
-   if (cccr_vsn >= SDIO_CCCR_REV_3_00) {
+   if (cccr_vsn >= SDIO_CCCR_REV_3_00 && uhs) {
card->scr.sda_spec3 = 1;
ret = mmc_io_rw_direct(card, 0, 0,
SDIO_CCCR_UHS, 0, &data);
@@ -710,7 +711,7 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 
ocr,
/*
 * Read the common registers.
 */
-   err = sdio_read_cccr(card);
+   err = sdio_read_cccr(card, ocr);
if (err)
goto remove;

-- 
1.7.7.3

--
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: regression: sd cards no longer recognized

[Philip Rakity]

Ack-by: Philip Rakity 

On Jan 2, 2012, at 4:29 PM, Chris Ball wrote:

> Hi Alexander,
> 
> On Sun, Jan 01 2012, Alexander Elbs wrote:
>> Hi,
>> 
>> on a dell vostro with an integrated SD card reader I have the problem, that
>> inserted SD cards are no longer recognized.
>> The reader is a "O2 Micro, Inc. Integrated MMC/SD Controller (rev 02)"
>> (1217:7120).
>> 
>> Doing a git bisect I found that commit 49c468f "mmc: sd: add support for uhs
>> bus speed mode selection" caused this regression.
>> 
>> Looking more closely into it I found that the flag SDHCI_CTRL_HISPD is always
>> set even on MMC_TIMING_UHS_SDR12 (which is an alias for MMC_TIMING_LEGACY).
>> 
>> If that flag in that case is not set (as was before commit 49c468f) my reader
>> works fine again.
>> 
>> Could you include that fix or does it break other readers?
>> 
>> Regards,
>> Alexander Elbs
>> 
>> ---
>> drivers/mmc/host/sdhci.c |3 +--
>> 1 files changed, 1 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 6d8eea3..8872e92 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1364,8 +1364,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host,
>> struct mmc_ios *ios)
>>if ((ios->timing == MMC_TIMING_UHS_SDR50) ||
>>(ios->timing == MMC_TIMING_UHS_SDR104) ||
>>(ios->timing == MMC_TIMING_UHS_DDR50) ||
>> -   (ios->timing == MMC_TIMING_UHS_SDR25) ||
>> -   (ios->timing == MMC_TIMING_UHS_SDR12))
>> +   (ios->timing == MMC_TIMING_UHS_SDR25))
>>ctrl |= SDHCI_CTRL_HISPD;
>> 
>>ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> 
> Thanks for the report -- adding Arindam and Philip to CC for comments.
> 
> - Chris.
> -- 
> Chris Ball  <http://printf.net/>
> One Laptop Per Child

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V7 1/2] mmc: core: HS200 mode support for eMMC 4.5

[Philip Rakity]

On Dec 20, 2011, at 8:12 PM, Girish K S wrote:

> This patch adds the support of the HS200 bus speed for eMMC 4.5 devices.
> The eMMC 4.5 devices have support for 200MHz bus speed. The function
> prototype of the tuning function is modified to handle the tuning command
> number which is different in sd and mmc case.
>
> cc: Chris Ball 
> Signed-off-by: Girish K S 
> ---
> drivers/mmc/core/bus.c |3 +-
> drivers/mmc/core/debugfs.c |3 +
> drivers/mmc/core/mmc.c |  142 +---
> drivers/mmc/core/sd.c  |3 +-
> drivers/mmc/core/sdio.c|4 +-
> include/linux/mmc/card.h   |3 +
> include/linux/mmc/mmc.h|   66 -
> 7 files changed, 211 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> index f8a228a..5d011a3 100644
> --- a/drivers/mmc/core/bus.c
> +++ b/drivers/mmc/core/bus.c
> @@ -303,10 +303,11 @@ int mmc_add_card(struct mmc_card *card)
>mmc_card_ddr_mode(card) ? "DDR " : "",
>type);
>} else {
> -   printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
> +   pr_info("%s: new %s%s%s%s card at address %04x\n",
>mmc_hostname(card->host),
>mmc_card_uhs(card) ? "ultra high speed " :
>(mmc_card_highspeed(card) ? "high speed " : ""),
> +   (mmc_card_hs200(card) ? "HS200 " : ""),
>mmc_card_ddr_mode(card) ? "DDR " : "",
>type, card->rca);
>}
> diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
> index 027615d..9ab5b17 100644
> --- a/drivers/mmc/core/debugfs.c
> +++ b/drivers/mmc/core/debugfs.c
> @@ -135,6 +135,9 @@ static int mmc_ios_show(struct seq_file *s, void *data)
>case MMC_TIMING_UHS_DDR50:
>str = "sd uhs DDR50";
>break;
> +   case MMC_TIMING_MMC_HS200:
> +   str = "mmc high-speed SDR200";
> +   break;
>default:
>str = "invalid";
>break;
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index f0a9f1f..4de3416 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -286,6 +286,27 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 
> *ext_csd)
>}
>card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
>switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
> +   case EXT_CSD_CARD_TYPE_SDR_ALL:
> +   case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_8V:
> +   case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_2V:
> +   case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_52:
> +   card->ext_csd.hs_max_dtr = 2;
> +   card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
> +   break;
> +   case EXT_CSD_CARD_TYPE_SDR_1_2V_ALL:
> +   case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_8V:
> +   case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_2V:
> +   case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_52:
> +   card->ext_csd.hs_max_dtr = 2;
> +   card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_2V;
> +   break;
> +   case EXT_CSD_CARD_TYPE_SDR_1_8V_ALL:
> +   case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_8V:
> +   case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_2V:
> +   case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_52:
> +   card->ext_csd.hs_max_dtr = 2;
> +   card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_8V;
> +   break;
>case EXT_CSD_CARD_TYPE_DDR_52 | EXT_CSD_CARD_TYPE_52 |
> EXT_CSD_CARD_TYPE_26:
>card->ext_csd.hs_max_dtr = 5200;
> @@ -700,6 +721,58 @@ static int mmc_select_powerclass(struct mmc_card *card,
> }
>
> /*
> + * Selects the desired buswidth and switch to the HS200 mode
> + * if bus width set without error
> + */
> +static int mmc_select_hs200(struct mmc_card *card)
> +{
> +   int err = 0;
> +   struct mmc_host *host;
> +   u32 bus_width = MMC_BUS_WIDTH_4;
> +
> +   BUG_ON(!card);
> +
> +   host = card->host;
> +
> +   if ((card->ext_csd.card_type & EXT_CSD_CARD_TYPE_SDR_1_2V)
> +   && (host->caps2 & MMC_CAP2_HS200_1_2V_SDR))
> +   err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_120, 0);

if 1.2 volt is not supported should one try 1.8v signaling ?

> +
> +   /*
> +* Host is capable of 8bit transfer, then switch
> +* the device to work in 8bit transfer mode. If the
> +* mmc switch command returns error then switch to
> +* 4bit transfer mode. On success set the corresponding
> +* bus width on the host.
> +*/
> +   if (!err && host->caps & MMC_CAP_8_BIT_DATA) {
> +   err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> +EXT_CSD_BUS_WIDTH,
> +EXT_CSD_BUS_WIDT

Re: [PATCH] mmc: core: Fix voltage select in DDR mode

[Philip Rakity]

On Dec 15, 2011, at 9:06 AM, Subhash Jadavani wrote:

> 
> 
>> -Original Message-
>> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> ow...@vger.kernel.org] On Behalf Of Girish K S
>> Sent: Thursday, December 15, 2011 5:28 PM
>> To: linux-mmc@vger.kernel.org
>> Cc: patc...@linaro.org; linux-samsung-...@vger.kernel.org; Girish K S;
>> Philip Rakity; Arindam Nath; Chris Ball
>> Subject: [PATCH] mmc: core: Fix voltage select in DDR mode
>> 
>> This patch fixes the wrong comparison before setting the interface
>> voltage in DDR mode.
>> 
>> The assignment to the variable ddr before comaprison is either
>> ddr = MMC_1_2V_DDR_MODE; or ddr == MMC_1_8V_DDR_MODE. But the
>> comparison
>> is done wth the extended csd value if (ddr ==
>> EXT_CSD_CARD_TYPE_DDR_1_2V)
>> 
>> cc: Philip Rakity 
>> cc: Arindam Nath 
>> cc: Chris Ball 
>> Signed-off-by: Girish K S 
>> ---
>> drivers/mmc/core/mmc.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index 006e932..f0a9f1f 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -1058,7 +1058,7 @@ static int mmc_init_card(struct mmc_host *host,
>> u32 ocr,
>>   *
>>   * WARNING: eMMC rules are NOT the same as SD DDR
>>   */
>> -if (ddr == EXT_CSD_CARD_TYPE_DDR_1_2V) {
>> +if (ddr == MMC_1_2V_DDR_MODE) {
> 
> Looks fine. 
> Acked-by: Subhash Jadavani 

Acked-by: Philip Rakity 

NOTE:  standard sdhci controller (version 3.0) does not support 1.2v signaling.

> 
>>  err = mmc_set_signal_voltage(host,
>>  MMC_SIGNAL_VOLTAGE_120, 0);
>>  if (err)
>> --
>> 1.7.1
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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 1/2] mmc: core: HS200 mode support for eMMC 4.5

[Philip Rakity]

On Dec 18, 2011, at 10:36 PM, Girish K S wrote:

> This patch adds the support of the HS200 bus speed for eMMC 4.5 devices.
> The eMMC 4.5 devices have support for 200MHz bus speed. The function
> prototype of the tuning function is modified to handle the tuning command
> number which is different in sd and mmc case.
>
> cc: Chris Ball 
> Signed-off-by: Girish K S 
> ---
> drivers/mmc/core/bus.c |3 +-
> drivers/mmc/core/debugfs.c |3 +
> drivers/mmc/core/mmc.c |  147 +---
> drivers/mmc/core/sd.c  |3 +-
> drivers/mmc/core/sdio.c|4 +-
> include/linux/mmc/card.h   |3 +
> include/linux/mmc/mmc.h|   66 +++-
> 7 files changed, 216 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> index f8a228a..5d011a3 100644
> --- a/drivers/mmc/core/bus.c
> +++ b/drivers/mmc/core/bus.c
> @@ -303,10 +303,11 @@ int mmc_add_card(struct mmc_card *card)
>mmc_card_ddr_mode(card) ? "DDR " : "",
>type);
>} else {
> -   printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
> +   pr_info("%s: new %s%s%s%s card at address %04x\n",
>mmc_hostname(card->host),
>mmc_card_uhs(card) ? "ultra high speed " :
>(mmc_card_highspeed(card) ? "high speed " : ""),
> +   (mmc_card_hs200(card) ? "HS200 " : ""),
>mmc_card_ddr_mode(card) ? "DDR " : "",
>type, card->rca);
>}
> diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
> index 027615d..9ab5b17 100644
> --- a/drivers/mmc/core/debugfs.c
> +++ b/drivers/mmc/core/debugfs.c
> @@ -135,6 +135,9 @@ static int mmc_ios_show(struct seq_file *s, void *data)
>case MMC_TIMING_UHS_DDR50:
>str = "sd uhs DDR50";
>break;
> +   case MMC_TIMING_MMC_HS200:
> +   str = "mmc high-speed SDR200";
> +   break;
>default:
>str = "invalid";
>break;
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index f0a9f1f..d5d93de 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -286,6 +286,27 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 
> *ext_csd)
>}
>card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
>switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
> +   case EXT_CSD_CARD_TYPE_SDR_ALL:
> +   case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_8V:
> +   case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_2V:
> +   case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_52:
> +   card->ext_csd.hs_max_dtr = 2;
> +   card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
> +   break;
> +   case EXT_CSD_CARD_TYPE_SDR_1_2V_ALL:
> +   case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_8V:
> +   case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_2V:
> +   case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_52:
> +   card->ext_csd.hs_max_dtr = 2;
> +   card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_2V;
> +   break;
> +   case EXT_CSD_CARD_TYPE_SDR_1_8V_ALL:
> +   case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_8V:
> +   case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_2V:
> +   case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_52:
> +   card->ext_csd.hs_max_dtr = 2;
> +   card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_8V;
> +   break;
>case EXT_CSD_CARD_TYPE_DDR_52 | EXT_CSD_CARD_TYPE_52 |
> EXT_CSD_CARD_TYPE_26:
>card->ext_csd.hs_max_dtr = 5200;
> @@ -700,6 +721,52 @@ static int mmc_select_powerclass(struct mmc_card *card,
> }
>
> /*
> + * Selects the desired buswidth and switch to the HS200 mode
> + * if bus width set without error
> + */
> +static int mmc_select_hs200(struct mmc_card *card)
> +{
> +   int err = 0;
> +   struct mmc_host *host;
> +   u32 bus_width = MMC_BUS_WIDTH_4;
> +
> +   BUG_ON(!card);
> +
> +   host = card->host;
> +

Can you use BUS_WIDTH [183]  section 7.4.42 to determine the supported bus 
widths of the device
to avoid the switch if 8 bit is not supported.  CAP_8_BIT indicates controller 
supports 8 bit but the
BUS_WIDTH field indicates the card supports this.

> +   /*
> +* Host is capable of 8bit transfer, then switch
> +* the device to work in 8bit transfer mode. If the
> +* mmc switch command returns error then switch to
> +* 4bit transfer mode. On success set the corresponding
> +* bus width on the host.
> +*/
> +   if (host->caps & MMC_CAP_8_BIT_DATA) {
> +   err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> +EXT_CSD_BUS_WIDTH,
> +EXT_CSD_BUS_WIDTH_8,
> +   

Re: [PATCH V6 2/2] mmc: host: Adds support for eMMC 4.5 HS200 mode

[Philip Rakity]

HI,

minor comments below.

Philip

On Dec 18, 2011, at 10:36 PM, Girish K S wrote:

> This patch adds support for the HS200 mode on the host side.
> Also enables the tuning feature required when the HS200 mode
> is selected.
> 
> cc: Chris Ball 
> Signed-off-by: Girish K S 
> ---
> drivers/mmc/host/sdhci.c  |   43 +--
> drivers/mmc/host/sdhci.h  |1 +
> include/linux/mmc/host.h  |   11 ++-
> include/linux/mmc/sdhci.h |1 +
> 4 files changed, 45 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index ab6018f..049d51d 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -49,7 +49,7 @@ static void sdhci_finish_data(struct sdhci_host *);
> 
> static void sdhci_send_command(struct sdhci_host *, struct mmc_command *);
> static void sdhci_finish_command(struct sdhci_host *);
> -static int sdhci_execute_tuning(struct mmc_host *mmc);
> +static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
> static void sdhci_tuning_timer(unsigned long data);
> 
> #ifdef CONFIG_PM_RUNTIME
> @@ -1016,7 +1016,8 @@ static void sdhci_send_command(struct sdhci_host *host, 
> struct mmc_command *cmd)
>   flags |= SDHCI_CMD_INDEX;
> 
>   /* CMD19 is special in that the Data Present Select should be set */
> - if (cmd->data || (cmd->opcode == MMC_SEND_TUNING_BLOCK))
> + if (cmd->data || (cmd->opcode == MMC_SEND_TUNING_BLOCK) ||
> + (cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200))
>   flags |= SDHCI_CMD_DATA;
> 
>   sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND);
> @@ -1287,7 +1288,7 @@ static void sdhci_request(struct mmc_host *mmc, struct 
> mmc_request *mrq)
>   if ((host->flags & SDHCI_NEEDS_RETUNING) &&
>   !(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) {
>   spin_unlock_irqrestore(&host->lock, flags);
> - sdhci_execute_tuning(mmc);
> + sdhci_execute_tuning(mmc, mrq->cmd->opcode);
>   spin_lock_irqsave(&host->lock, flags);
> 
>   /* Restore original mmc_request structure */
> @@ -1375,7 +1376,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
> struct mmc_ios *ios)
>   (ios->timing == MMC_TIMING_UHS_SDR104) ||
>   (ios->timing == MMC_TIMING_UHS_DDR50) ||
>   (ios->timing == MMC_TIMING_UHS_SDR25) ||
> - (ios->timing == MMC_TIMING_UHS_SDR12))
> + (ios->timing == MMC_TIMING_UHS_SDR12) ||
> + (ios->timing == MMC_TIMING_MMC_HS200))
>   ctrl |= SDHCI_CTRL_HISPD;

move to first test so speed ordering is maintained.
> 
>   ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> @@ -1435,6 +1437,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
> struct mmc_ios *ios)
>   ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
>   else if (ios->timing == MMC_TIMING_UHS_DDR50)
>   ctrl_2 |= SDHCI_CTRL_UHS_DDR50;
> + else if (ios->timing == MMC_TIMING_MMC_HS200)
> + ctrl_2 |= SDHCI_CTRL_HS_SDR200;
>   sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
>   }

same as above

> 
> @@ -1673,7 +1677,7 @@ static int sdhci_start_signal_voltage_switch(struct 
> mmc_host *mmc,
>   return err;
> }
> 
> -static int sdhci_execute_tuning(struct mmc_host *mmc)
> +static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
> {

Can one deduce the type of tuning needed by the speed ?   is the opcode really 
needed?

>   struct sdhci_host *host;
>   u16 ctrl;
> @@ -1694,10 +1698,13 @@ static int sdhci_execute_tuning(struct mmc_host *mmc)
>* Host Controller needs tuning only in case of SDR104 mode
>* and for SDR50 mode when Use Tuning for SDR50 is set in
>* Capabilities register.
> +  * If the Host Controller supports the HS200 mode then tuning
> +  * function has to be executed.
>*/
>   if (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR104) ||
>   (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR50) &&
> - (host->flags & SDHCI_SDR50_NEEDS_TUNING)))
> + (host->flags & SDHCI_SDR50_NEEDS_TUNING)) ||
> + (host->flags & SDHCI_HS200_NEEDS_TUNING))
>   ctrl |= SDHCI_CTRL_EXEC_TUNING;
>   else {
>   spin_unlock(&host->lock);
> @@ -1733,7 +1740,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc)
>   if (!tuning_loop_counter && !timeout)
>   break;
> 
> - cmd.opcode = MMC_SEND_TUNING_BLOCK;
> + cmd.opcode = opcode;
>   cmd.arg = 0;
>   cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
>   cmd.retries = 0;
> @@ -1748,7 +1755,17 @@ static int sdh

Re: [PATCH v3 2/4] ARM: pxa168: Add SDHCI support

[Philip Rakity]

Haojian,

Should the APMU definitions be moved to a separate include for pxa168 and say 
given the name pxa168_apmu.h ?

Same comment applies to all the register set since they are not really common.

Philip

On Dec 18, 2011, at 9:02 PM, Haojian Zhuang wrote:

> On Mon, Dec 19, 2011 at 12:55 PM, Tanmay Upadhyay
>  wrote:
>> 
>> 
>> On Monday 19 December 2011 10:15 AM, Haojian Zhuang wrote:
>>> 
>>> On Fri, Dec 16, 2011 at 7:15 AM, Chris Ball  wrote:
 
 Hi Eric and Jason,
 
 On Thu, Dec 01 2011, Chris Ball wrote:
> 
> Hi Eric, Jason,
> 
> Please could you ACK this patch if you agree with it, and I'll take it
> and the rest of the series via the MMC tree?  Thanks.
 
 Ping?
 
 Thanks,
 
 - Chris.
 
>>> NACK.
>>> 
>> +/* Offset defined in arch/arm/mach-mmp/include/mach/regs-apmu.h are
>> for MMP2
>> + * PXA168 has different offset */
>> +#undef APMU_SDH2
>> +#undef APMU_SDH3
>> +
>> +#define APMU_SDH2   APMU_REG(0xe0)
>> +#define APMU_SDH3   APMU_REG(0xe4)
>> +
>>> 
>>> Please don't use #undef at here. If the register setting is different,
>>> I prefer to use two different clk operations.
>>> 
>> 
>> Sorry I couldn't get you. Could you please elaborate? Here regs-apmu.h
>> defines clock register offsets. They are correct for MMP2, but not for
>> PXA168. So I thought to correct them in a PXA168 specific file. Could you
>> please point me a better way?
>> 
>> Thanks,
>> 
>> Tanmay
> 
> APMU_PXA168_SDH2
> APMU_MMP2_SDH2
> 
> I think this is better.

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4 v5] SDHCI: add sdhci_get_cd callback to detect the card

[Philip Rakity]

On Dec 14, 2011, at 6:32 PM, Huang Changming-R66093 wrote:

> 
> 
>> -Original Message-----
>> From: Philip Rakity [mailto:prak...@marvell.com]
>> Sent: Wednesday, December 14, 2011 12:52 PM
>> To: Huang Changming-R66093
>> Cc: linux-mmc@vger.kernel.org; Huang Changming-R66093; Chris Ball
>> Subject: Re: [PATCH 3/4 v5] SDHCI: add sdhci_get_cd callback to detect
>> the card
>> 
>> 
>> On Dec 13, 2011, at 6:18 PM,  wrote:
>> 
>>> From: Jerry Huang 
>>> 
>>> Add callback function sdhci_get_cd to detect the card.
>>> And one new callback added to implement the card detect in sdhci
>> struncture.
>>> If special platform has the card detect callback, it will return the
>>> card state, the value zero is for absent cardi and one is for present
>> card.
>>> If the controller don't support card detect, sdhci_get_cd will return -
>> ENOSYS.
>>> 
>>> Signed-off-by: Jerry Huang 
>>> CC: Chris Ball 
>>> ---
>>> changes for v2:
>>> - when controller don't support get_cd, return -ENOSYS
>>> - add new callback for sdhci to detect the card
>>> - add the CC
>>> changes for v3:
>>> - use pin_lock only when get_cd defined changes for v4:
>>> - enalbe the controller clock in platform, instead of core changes
>>> for v5:
>>> - remove the copyright
>>> 
>>> drivers/mmc/host/sdhci.c |   21 ++
>>> drivers/mmc/host/sdhci.h |2 ++
>>> 2 files changed, 23 insertions(+), 0 deletions(-)
>>> 
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index
>>> 6d8eea3..fbe2f46 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -1518,6 +1519,26 @@ static int sdhci_get_ro(struct mmc_host *mmc)
>>> return ret;
>>> }
>>> 
>>> +/* Return values for the sdjco_get_cd callback:
>>> + *   0 for a absent card
>>> + *   1 for a present card
>>> + *   -ENOSYS when not supported (equal to NULL callback)
>>> + */
>>> +static int sdhci_get_cd(struct mmc_host *mmc) {
>>> +   struct sdhci_host *host = mmc_priv(mmc);
>>> +   unsigned long flags;
>>> +   int present = -ENOSYS;
>>> +
>>> +   if (host->ops->get_cd) {
>>> +   spin_lock_irqsave(&host->lock, flags);
>>> +   present = host->ops->get_cd(host);
>>> +   spin_unlock_irqrestore(&host->lock, flags);
>>> +   }
>>> +
>>> +   return present;
>>> +}
>> 
>> In  static void sdhci_request(struct mmc_host *mmc, struct mmc_request
>> *mrq)
>> 
>> there is code below to handle broken card detect.
>> 
>> 1257
>> 1258 /* If polling, assume that the card is always present. */
>> 1259 if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
>> 1260 present = true;
>> 1261 else
>> 1262 present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
>> 1263 SDHCI_CARD_PRESENT;
>> 
>> The problem with this code is that it assumes broken card detect is
>> broken since the present state register cannot be read.
>> 
>> would it make more sense to do something like
>>if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) {
>>  if (host->ops->get_cd)
>>  present = present = host->ops->get_cd(host);
>>  else
>>  present = true;
>> 
>> and adjust the code in host->ops->get_cd() to not -ENOSYS.
> 
> I think we should not detect the card present state in sdhci_request function,
> Because if we do it, this detection will be performed with any command to 
> card,
> which will down the performance.
> 
> And if the quirks has SDHCI_QUIRK_BROKEN_CARD_DETECTION, that means the card 
> is always present,
> We don't need to detect the card state.

currently WE do read the present state register on every request.  All the 
above suggestion does is try to use your code

maybe we want something like
>>  if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
>>  present = true;
>>  else if (host->ops->get_cd)
>>  present = present = host->ops->get_cd(host);
>>  else
>>  present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
>>  SDHCI_CARD_PRESENT;







> 

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4 v5] SDHCI: add sdhci_get_cd callback to detect the card

[Philip Rakity]

On Dec 13, 2011, at 6:18 PM,  wrote:

> From: Jerry Huang 
> 
> Add callback function sdhci_get_cd to detect the card.
> And one new callback added to implement the card detect in sdhci struncture.
> If special platform has the card detect callback, it will return the card
> state, the value zero is for absent cardi and one is for present card.
> If the controller don't support card detect, sdhci_get_cd will return -ENOSYS.
> 
> Signed-off-by: Jerry Huang 
> CC: Chris Ball 
> ---
> changes for v2:
>   - when controller don't support get_cd, return -ENOSYS
>   - add new callback for sdhci to detect the card
>   - add the CC
> changes for v3:
>   - use pin_lock only when get_cd defined
> changes for v4:
>   - enalbe the controller clock in platform, instead of core
> changes for v5:
>   - remove the copyright
> 
> drivers/mmc/host/sdhci.c |   21 ++
> drivers/mmc/host/sdhci.h |2 ++
> 2 files changed, 23 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 6d8eea3..fbe2f46 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1518,6 +1519,26 @@ static int sdhci_get_ro(struct mmc_host *mmc)
>   return ret;
> }
> 
> +/* Return values for the sdjco_get_cd callback:
> + *   0 for a absent card
> + *   1 for a present card
> + *   -ENOSYS when not supported (equal to NULL callback)
> + */
> +static int sdhci_get_cd(struct mmc_host *mmc)
> +{
> + struct sdhci_host *host = mmc_priv(mmc);
> + unsigned long flags;
> + int present = -ENOSYS;
> +
> + if (host->ops->get_cd) {
> + spin_lock_irqsave(&host->lock, flags);
> + present = host->ops->get_cd(host);
> + spin_unlock_irqrestore(&host->lock, flags);
> + }
> +
> + return present;
> +}

In  static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)

there is code below to handle broken card detect.

1257
1258 /* If polling, assume that the card is always present. */
1259 if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
1260 present = true;
1261 else
1262 present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
1263 SDHCI_CARD_PRESENT;

The problem with this code is that it assumes broken card detect is broken since
the present state register cannot be read.

would it make more sense to do something like
if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) {
if (host->ops->get_cd)
present = present = host->ops->get_cd(host);
else
present = true;

and adjust the code in host->ops->get_cd() to not -ENOSYS.

Philip

> +
> static void sdhci_enable_sdio_irq_nolock(struct sdhci_host *host, int enable)
> {
>   if (host->flags & SDHCI_DEVICE_DEAD)
> @@ -1884,6 +1905,7 @@ static const struct mmc_host_ops sdhci_ops = {
>   .request= sdhci_request,
>   .set_ios= sdhci_set_ios,
>   .get_ro = sdhci_get_ro,
> + .get_cd = sdhci_get_cd,
>   .hw_reset   = sdhci_hw_reset,
>   .enable_sdio_irq = sdhci_enable_sdio_irq,
>   .start_signal_voltage_switch= sdhci_start_signal_voltage_switch,
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 0a5b654..82f4d27 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -69,6 +69,7 @@
> #define  SDHCI_SPACE_AVAILABLE0x0400
> #define  SDHCI_DATA_AVAILABLE 0x0800
> #define  SDHCI_CARD_PRESENT   0x0001
> +#define  SDHCI_CARD_CDPL 0x0004
> #define  SDHCI_WRITE_PROTECT  0x0008
> #define  SDHCI_DATA_LVL_MASK  0x00F0
> #define   SDHCI_DATA_LVL_SHIFT20
> @@ -261,6 +262,7 @@ struct sdhci_ops {
> 
>   void(*set_clock)(struct sdhci_host *host, unsigned int clock);
> 
> + int (*get_cd)(struct sdhci_host *host);
>   int (*enable_dma)(struct sdhci_host *host);
>   unsigned int(*get_max_clock)(struct sdhci_host *host);
>   unsigned int(*get_min_clock)(struct sdhci_host *host);
> -- 
> 1.7.5.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

--
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/4] SDHCI: add sdhci_get_cd callback to detect the card

[Philip Rakity]

On Dec 5, 2011, at 1:23 AM,   wrote:

> From: Jerry Huang 
> 
> Add callback function sdhci_get_cd to detect the card.
> In order to check if the card is present, we will read the PRESENT STATE
> register and check the bit13(Card detect pin level) and bit15(CINS).
> 
> Signed-off-by: Jerry Huang 
> ---
> drivers/mmc/host/sdhci.c |   20 
> drivers/mmc/host/sdhci.h |1 +
> 2 files changed, 21 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 6d8eea3..66afd82 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2,6 +2,7 @@
>  *  linux/drivers/mmc/host/sdhci.c - Secure Digital Host Controller Interface 
> driver
>  *
>  *  Copyright (C) 2005-2008 Pierre Ossman, All Rights Reserved.
> + *  Copyright (C) 2011 Freescale Semiconductor Inc.


Lots of folks have made mods to this code and they have not added a copyright 
name.
What is the rule Chris ?

>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License as published by
> @@ -1518,6 +1519,24 @@ static int sdhci_get_ro(struct mmc_host *mmc)
>   return ret;
> }
> 
> +static int sdhci_get_cd(struct mmc_host *mmc)
> +{
> + struct sdhci_host *host = mmc_priv(mmc);
> + unsigned long flags;
> + int present;
> +
> + spin_lock_irqsave(&host->lock, flags);
> +
> + if (host->flags & SDHCI_DEVICE_DEAD)
> + present = 0;
> + else
> + present = sdhci_readl(host, SDHCI_PRESENT_STATE);
> +
> + spin_unlock_irqrestore(&host->lock, flags);
> +
> + return (present & (SDHCI_CARD_PRESENT | SDHCI_CARD_CDPL));
> +}
> +
> static void sdhci_enable_sdio_irq_nolock(struct sdhci_host *host, int enable)
> {
>   if (host->flags & SDHCI_DEVICE_DEAD)
> @@ -1884,6 +1903,7 @@ static const struct mmc_host_ops sdhci_ops = {
>   .request= sdhci_request,
>   .set_ios= sdhci_set_ios,
>   .get_ro = sdhci_get_ro,
> + .get_cd = sdhci_get_cd,


A better approach would be to define a callback into platform specific code and 
use that.  For your
chip reading present state works but for other chips this will not be 
sufficient so a more general
solution would be better.



>   .hw_reset   = sdhci_hw_reset,
>   .enable_sdio_irq = sdhci_enable_sdio_irq,
>   .start_signal_voltage_switch= sdhci_start_signal_voltage_switch,
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 0a5b654..8ea7e00 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -69,6 +69,7 @@
> #define  SDHCI_SPACE_AVAILABLE0x0400
> #define  SDHCI_DATA_AVAILABLE 0x0800
> #define  SDHCI_CARD_PRESENT   0x0001
> +#define  SDHCI_CARD_CDPL 0x0004
> #define  SDHCI_WRITE_PROTECT  0x0008
> #define  SDHCI_DATA_LVL_MASK  0x00F0
> #define   SDHCI_DATA_LVL_SHIFT20
> -- 
> 1.7.5.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

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] mmc: sdhci-pxa: Add SDHCI driver for PXA16x

[Philip Rakity]

On Nov 25, 2011, at 4:47 AM, zhangfei gao wrote:

> 
> 
> On Mon, Nov 21, 2011 at 12:26 PM, Tanmay Upadhyay 
>  wrote:
> PXA16x devices uses SDHCI controller v1. As it's not much different
> than v2 controller, v1 driver is merged with sdhci-pxav2 driver
> 
> v2 - instead of having separate file sdhci-pxav1, merge code with
> sdhci-pxav2 driver code as suggested by Chris Ball
> 
> Signed-off-by: Philip Rakity 
> Signed-off-by: Tanmay Upadhyay 
> ---
> +/*
> + * we cannot talk to controller for 8 bus cycles according to sdio spec
> + * at lowest speed this is 100,000 HZ per cycle or 800,000 cycles
> + * which is quite a LONG TIME on a fast cpu -- so delay if needed
> + */
> 
> Would you mind provide more info, still not understand.
> What sdio spec 12.1 says cards shall switch speed mode within 8 clocks after 
> the end bit of the corresponding response.
> 


The pxa168 h/w controller is broken.  It does NOT wait  for the 8 clocks.


> +static void platform_specific_completion(struct sdhci_host *host)
> +{
> +   struct platform_device *pdev = to_platform_device(mmc_dev(host->mmc));
> +   struct sdhci_pxa_platdata *pdata = pdev->dev.platform_data;
> +
> +   if (host->clock < 320 && pdata && pdata->delay_in_ms)
> +   mdelay(pdata->delay_in_ms);
> +}
> +
> 

--
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: support SDIO UHS cards

[Philip Rakity]

Chris,

Checked out mmc-next from scratch and reapplied patch.  I think the auto merge 
feature from my update may have changed things.

Philip


This patch adds support for sdio UHS cards per the version 3.0
spec.

UHS mode is only enabled for version 3.0 cards when both the
host and the controller support UHS modes.

1.8v signaling support is removed if both the card and the
host do not support UHS.  This is done to maintain
compatibility and some system/card combinations break when
1.8v signaling is enabled when the host does not support UHS.

Signed-off-by: Philip Rakity 
Signed-off-by: Aaron Lu 
Reviewed-by: Arindam Nath 
Tested-by: Bing Zhao 
---
 drivers/mmc/core/bus.c   |2 +-
 drivers/mmc/core/sd.c|2 +-
 drivers/mmc/core/sdio.c  |  329 ++
 include/linux/mmc/card.h |4 +-
 include/linux/mmc/sdio.h |   29 -
 5 files changed, 336 insertions(+), 30 deletions(-)

diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 46b6e84..5639fdf 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -303,7 +303,7 @@ int mmc_add_card(struct mmc_card *card)
} else {
printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
mmc_hostname(card->host),
-   mmc_sd_card_uhs(card) ? "ultra high speed " :
+   mmc_card_uhs(card) ? "ultra high speed " :
(mmc_card_highspeed(card) ? "high speed " : ""),
mmc_card_ddr_mode(card) ? "DDR " : "",
type, card->rca);
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index bcc2c90..1d5a3bd 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -959,7 +959,7 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 ocr,
goto free_card;

/* Card is an ultra-high-speed card */
-   mmc_sd_card_set_uhs(card);
+   mmc_card_set_uhs(card);

/*
 * Since initialization is now complete, enable preset
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 3ab565e..8c04f7f 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -102,6 +102,7 @@ static int sdio_read_cccr(struct mmc_card *card)
int ret;
int cccr_vsn;
unsigned char data;
+   unsigned char speed;

memset(&card->cccr, 0, sizeof(struct sdio_cccr));

@@ -140,12 +141,60 @@ static int sdio_read_cccr(struct mmc_card *card)
}

if (cccr_vsn >= SDIO_CCCR_REV_1_20) {
-   ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_SPEED, 0, &data);
+   ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_SPEED, 0, &speed);
if (ret)
goto out;

-   if (data & SDIO_SPEED_SHS)
-   card->cccr.high_speed = 1;
+   card->scr.sda_spec3 = 0;
+   card->sw_caps.sd3_bus_mode = 0;
+   card->sw_caps.sd3_drv_type = 0;
+   if (cccr_vsn >= SDIO_CCCR_REV_3_00) {
+   card->scr.sda_spec3 = 1;
+   ret = mmc_io_rw_direct(card, 0, 0,
+   SDIO_CCCR_UHS, 0, &data);
+   if (ret)
+   goto out;
+
+   if (card->host->caps &
+   (MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 |
+MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 |
+MMC_CAP_UHS_DDR50)) {
+   if (data & SDIO_UHS_DDR50)
+   card->sw_caps.sd3_bus_mode
+   |= SD_MODE_UHS_DDR50;
+
+   if (data & SDIO_UHS_SDR50)
+   card->sw_caps.sd3_bus_mode
+   |= SD_MODE_UHS_SDR50;
+
+   if (data & SDIO_UHS_SDR104)
+   card->sw_caps.sd3_bus_mode
+   |= SD_MODE_UHS_SDR104;
+   }
+
+   ret = mmc_io_rw_direct(card, 0, 0,
+   SDIO_CCCR_DRIVE_STRENGTH, 0, &data);
+   if (ret)
+   goto out;
+
+   if (data & SDIO_DRIVE_SDTA)
+   card->sw_caps.sd3_drv_type |= SD_DRIVER_TYPE_A;
+   if (data & SDIO_DRIVE_SDTC)
+   card->sw_caps.sd3_drv_type |= SD_DRIVER_TYPE_C;
+   if (data & SDIO_DRIVE_SDTD)
+   card->sw_caps.sd3_drv_type |= SD_DRIV

[PATCH] mmc: sdio: support SDIO UHS cards

[Philip Rakity]

This patch adds support for sdio UHS cards per the version 3.0
spec.

UHS mode is only enabled for version 3.0 cards when both the
host and the controller support UHS modes.

1.8v signaling support is removed if both the card and the
host do not support UHS.  This is done to maintain
compatibility and some system/card combinations break when
1.8v signaling is enabled when the host does not support UHS.

Signed-off-by: Philip Rakity 
Signed-off-by: Aaron Lu 
Reviewed-by: Arindam Nath 
Tested-by: Bing Zhao 
---
 drivers/mmc/core/bus.c   |2 +-
 drivers/mmc/core/sd.c|2 +-
 drivers/mmc/core/sdio.c  |  329 ++
 include/linux/mmc/card.h |4 +-
 include/linux/mmc/sdio.h |   29 -
 5 files changed, 336 insertions(+), 30 deletions(-)

diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 46b6e84..5639fdf 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -303,7 +303,7 @@ int mmc_add_card(struct mmc_card *card)
} else {
printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
mmc_hostname(card->host),
-   mmc_sd_card_uhs(card) ? "ultra high speed " :
+   mmc_card_uhs(card) ? "ultra high speed " :
(mmc_card_highspeed(card) ? "high speed " : ""),
mmc_card_ddr_mode(card) ? "DDR " : "",
type, card->rca);
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index a230e7f..d68cf4a 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -959,7 +959,7 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 ocr,
goto free_card;

/* Card is an ultra-high-speed card */
-   mmc_sd_card_set_uhs(card);
+   mmc_card_set_uhs(card);

/*
 * Since initialization is now complete, enable preset
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 3ab565e..8c04f7f 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -102,6 +102,7 @@ static int sdio_read_cccr(struct mmc_card *card)
int ret;
int cccr_vsn;
unsigned char data;
+   unsigned char speed;

memset(&card->cccr, 0, sizeof(struct sdio_cccr));

@@ -140,12 +141,60 @@ static int sdio_read_cccr(struct mmc_card *card)
}

if (cccr_vsn >= SDIO_CCCR_REV_1_20) {
-   ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_SPEED, 0, &data);
+   ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_SPEED, 0, &speed);
if (ret)
goto out;

-   if (data & SDIO_SPEED_SHS)
-   card->cccr.high_speed = 1;
+   card->scr.sda_spec3 = 0;
+   card->sw_caps.sd3_bus_mode = 0;
+   card->sw_caps.sd3_drv_type = 0;
+   if (cccr_vsn >= SDIO_CCCR_REV_3_00) {
+   card->scr.sda_spec3 = 1;
+   ret = mmc_io_rw_direct(card, 0, 0,
+   SDIO_CCCR_UHS, 0, &data);
+   if (ret)
+   goto out;
+
+   if (card->host->caps &
+   (MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 |
+MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 |
+MMC_CAP_UHS_DDR50)) {
+   if (data & SDIO_UHS_DDR50)
+   card->sw_caps.sd3_bus_mode
+   |= SD_MODE_UHS_DDR50;
+
+   if (data & SDIO_UHS_SDR50)
+   card->sw_caps.sd3_bus_mode
+   |= SD_MODE_UHS_SDR50;
+
+   if (data & SDIO_UHS_SDR104)
+   card->sw_caps.sd3_bus_mode
+   |= SD_MODE_UHS_SDR104;
+   }
+
+   ret = mmc_io_rw_direct(card, 0, 0,
+   SDIO_CCCR_DRIVE_STRENGTH, 0, &data);
+   if (ret)
+   goto out;
+
+   if (data & SDIO_DRIVE_SDTA)
+   card->sw_caps.sd3_drv_type |= SD_DRIVER_TYPE_A;
+   if (data & SDIO_DRIVE_SDTC)
+   card->sw_caps.sd3_drv_type |= SD_DRIVER_TYPE_C;
+   if (data & SDIO_DRIVE_SDTD)
+   card->sw_caps.sd3_drv_type |= SD_DRIVER_TYPE_D;
+   }
+
+   /* if no uhs mode ensure we check for high speed */
+   if (!card->sw_caps.sd3_bu

Re: [PATCH v2 1/3] ARM: pxa168: Add SDHCI support

[Philip Rakity]

_disable,
> +};
> +
> /* APB peripheral clocks */
> static APBC_CLK(uart1, PXA168_UART1, 1, 14745600);
> static APBC_CLK(uart2, PXA168_UART2, 1, 14745600);
> @@ -84,6 +117,11 @@ static APMU_CLK(nand, NAND, 0x19b, 15600);
> static APMU_CLK(lcd, LCD, 0x7f, 31200);
> static APMU_CLK(eth, ETH, 0x09, 0);
> 
> +static APMU_CLK_OPS(sdh0, SDH0, 0x12, 4800, &sdh_clk_ops);
> +static APMU_CLK_OPS(sdh1, SDH1, 0x12, 4800, &sdh_clk_ops);
> +static APMU_CLK_OPS(sdh2, SDH2, 0x12, 4800, &sdh_clk_ops);
> +static APMU_CLK_OPS(sdh3, SDH3, 0x12, 4800, &sdh_clk_ops);
> +
> /* device and clock bindings */
> static struct clk_lookup pxa168_clkregs[] = {
>   INIT_CLKREG(&clk_uart1, "pxa2xx-uart.0", NULL),
> @@ -104,6 +142,10 @@ static struct clk_lookup pxa168_clkregs[] = {
>   INIT_CLKREG(&clk_lcd, "pxa168-fb", NULL),
>   INIT_CLKREG(&clk_keypad, "pxa27x-keypad", NULL),
>   INIT_CLKREG(&clk_eth, "pxa168-eth", "MFUCLK"),
> + INIT_CLKREG(&clk_sdh0, "sdhci-pxav1.0", "PXA-SDHCLK"),
> + INIT_CLKREG(&clk_sdh1, "sdhci-pxav1.1", "PXA-SDHCLK"),
> + INIT_CLKREG(&clk_sdh2, "sdhci-pxav1.2", "PXA-SDHCLK"),
> + INIT_CLKREG(&clk_sdh3, "sdhci-pxav1.3", "PXA-SDHCLK"),
> };
> 
> static int __init pxa168_init(void)
> @@ -169,3 +211,7 @@ PXA168_DEVICE(ssp5, "pxa168-ssp", 4, SSP5, 0xd4021000, 
> 0x40, 60, 61);
> PXA168_DEVICE(fb, "pxa168-fb", -1, LCD, 0xd420b000, 0x1c8);
> PXA168_DEVICE(keypad, "pxa27x-keypad", -1, KEYPAD, 0xd4012000, 0x4c);
> PXA168_DEVICE(eth, "pxa168-eth", -1, MFU, 0xc080, 0x0fff);
> +PXA168_DEVICE(sdh0, "sdhci-pxav1", 0, SDH1, 0xd428, 0x100);
> +PXA168_DEVICE(sdh1, "sdhci-pxav1", 1, SDH1, 0xd4281000, 0x100);
> +PXA168_DEVICE(sdh2, "sdhci-pxav1", 2, SDH2, 0xd427e000, 0x100);
> +PXA168_DEVICE(sdh3, "sdhci-pxav1", 3, SDH2, 0xd427f000, 0x100);
> -- 
> 1.7.0.4

Review-by: Philip Rakity 

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: Ricoh Controller sd

[Philip Rakity]

A couple of clarifications:

a) if no signal voltage switch UHS SDR50 works
b) The CMD11 does not return a error -- after the voltage switch future command 
fail with error -110 (timeout)

Thanks Arindam for helping with the clarification.

Philip

On Nov 2, 2011, at 5:10 AM, Philip Rakity wrote:

> 
> Folks,
> 
> We are working on some changes to support SDR50 and SDR104 for SDIO cards.  
> The code works on some controllers but not
> on the ricoh r5c822.  The system is 64-bit Fedora 11 x86 with PCI-to-SD 
> adapter card (Ricoh controller).
> DMI: Hewlett-Packard HP Compaq dx2200 MT /0A48, BIOS MS7254 1.05 08/14/2006
> 
> 
> The trace shows:
> 
> mmc0: no vmmc regulator found
> Registered led device: mmc0::
> mmc0: SDHCI controller on PCI [:03:00.0] using DMA
> mmc_attach_sdio:mmc0 ocr = B1FF8000
> mmc_attach_sdio:mmc0 R4_18V_PRESENT = 0100, v18 = 1
> mmc_sdio_init_card:mmc0 ocr = B130
> mmc_sdio_init_card:mmc0: mmc_set_signal_voltage ret = 0
> mmc0: error -110 whilst initialising SDIO card
> mmc_attach_sdio:mmc0 ocr = 31FF8000
> mmc_attach_sdio:mmc0 R4_18V_PRESENT = 0100, v18 = 1
> mmc_sdio_init_card:mmc0 ocr = B130
> mmc_sdio_init_card:mmc0: mmc_set_signal_voltage ret = 0
> mmc0: error -110 whilst initialising SDIO card
> mmc_attach_sdio:mmc0 ocr = 31FF8000
> mmc_attach_sdio:mmc0 R4_18V_PRESENT = 0100, v18 = 1
> mmc_sdio_init_card:mmc0 ocr = B130
> mmc_sdio_init_card:mmc0: mmc_set_signal_voltage ret = 0
> mmc0: error -110 whilst initialising SDIO card
> mmc_attach_sdio:mmc0 ocr = 31FF8000
> mmc_attach_sdio:mmc0 R4_18V_PRESENT = 0100, v18 = 1
> mmc_sdio_init_card:mmc0 ocr = B130
> mmc_sdio_init_card:mmc0: mmc_set_signal_voltage ret = 0
> mmc0: error -110 whilst initialising SDIO card
> EXT4-fs (dm-0): re-mounted. Opts: (null)
> 
> We have narrowed this down to the sending of the CMD11.  If this is NOT done 
> the the ultra high speed card works.
> CMD11 is required for signal voltage switching.
> 
> The register dump from the host controller:
> 
> sdhci-pci :03:00.0: SDHCI controller found [1180:0822] (rev 22)
> 
> 
> [2.030053] mmc1: SDHCI controller on PCI [:02:05.0] using ADMA
> [2.030187] sdhci: === REGISTER DUMP (mmc1)===
> [2.030268] sdhci: Sys addr: 0x | Version:  0x1002
> [2.030342] sdhci: Blk size: 0x | Blk cnt:  0x
> [2.030425] sdhci: Argument: 0x | Trn mode: 0x
> [2.030503] sdhci: Present:  0x01ff | Host ctl: 0x0004
> [2.030589] sdhci: Power:0x | Blk gap:  0x
> [2.030668] sdhci: Wake-up:  0x | Clock:0x
> [2.030753] sdhci: Timeout:  0x | Int stat: 0x
> [2.030832] sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083
> [2.030917] sdhci: AC12 err: 0x | Slot int: 0x00ff
> [2.030996] sdhci: Caps: 0x31fe32b2 | Caps_1:   0x00030503
> [2.031082] sdhci: Cmd:  0x | Max curr: 0x00c80064
> [2.031158] sdhci: Host ctl2: 0x
> [2.031242] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> [2.031315] sdhci: ===
> 
> 
> This shows that the controller is V3 and does support SDR50 and SDR104.
> 
> We can hack our way around this by adding a quirk to sdhci-pci.c for the 
> controller to disable sending CMD11 
> 
> something along the lines of 
> #define SDHCI_QUIRK_NO_VOLTAGE_SIGNAL_CMD11_SUPPORT
> 
> and check in core.c (mmc_set_signal_voltage()).  and just not send the CMD11.
> 
> very ugly.
> 
> Any other suggestions ?
> 
> 
> 
> Philip
> 
> 
> 
> 
> On Nov 1, 2011, at 3:52 PM, Philip Rakity wrote:
> 
>> 
>> Chris,
>> 
>> Testing my SDIO 3.0 changes UHS mode 100 m/bps   Code works find on MMP2.
>> 
>> Using the system
>>> 64-bit Fedora 11 x86 with PCI-to-SD adapter card (Ricoh controller).
>> 
>> The code fails.  Bing found that if CMD11 is sent when doing the voltage 
>> switch timeout errors (-110) occur.
>> If CMD11 is not sent then everything. works.   Unfortunately CMD11 is 
>> required.  No error is returned when the CMD11 is sent.
>> 
>> I know there are some quirks for the controller in sdhci-pci.  
>> 
>> Any ideas who to ask about this if you do not know the answer ?
>> 
>> regards,
>> 
>> Philip
>> 
> 

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

RFC: Ricoh Controller sd

[Philip Rakity]

Folks,

We are working on some changes to support SDR50 and SDR104 for SDIO cards.  The 
code works on some controllers but not
on the ricoh r5c822.  The system is 64-bit Fedora 11 x86 with PCI-to-SD adapter 
card (Ricoh controller).
DMI: Hewlett-Packard HP Compaq dx2200 MT /0A48, BIOS MS7254 1.05 08/14/2006


The trace shows:

mmc0: no vmmc regulator found
Registered led device: mmc0::
mmc0: SDHCI controller on PCI [:03:00.0] using DMA
mmc_attach_sdio:mmc0 ocr = B1FF8000
mmc_attach_sdio:mmc0 R4_18V_PRESENT = 0100, v18 = 1
mmc_sdio_init_card:mmc0 ocr = B130
mmc_sdio_init_card:mmc0: mmc_set_signal_voltage ret = 0
mmc0: error -110 whilst initialising SDIO card
mmc_attach_sdio:mmc0 ocr = 31FF8000
mmc_attach_sdio:mmc0 R4_18V_PRESENT = 0100, v18 = 1
mmc_sdio_init_card:mmc0 ocr = B130
mmc_sdio_init_card:mmc0: mmc_set_signal_voltage ret = 0
mmc0: error -110 whilst initialising SDIO card
mmc_attach_sdio:mmc0 ocr = 31FF8000
mmc_attach_sdio:mmc0 R4_18V_PRESENT = 0100, v18 = 1
mmc_sdio_init_card:mmc0 ocr = B130
mmc_sdio_init_card:mmc0: mmc_set_signal_voltage ret = 0
mmc0: error -110 whilst initialising SDIO card
mmc_attach_sdio:mmc0 ocr = 31FF8000
mmc_attach_sdio:mmc0 R4_18V_PRESENT = 0100, v18 = 1
mmc_sdio_init_card:mmc0 ocr = B130
mmc_sdio_init_card:mmc0: mmc_set_signal_voltage ret = 0
mmc0: error -110 whilst initialising SDIO card
EXT4-fs (dm-0): re-mounted. Opts: (null)

We have narrowed this down to the sending of the CMD11.  If this is NOT done 
the the ultra high speed card works.
CMD11 is required for signal voltage switching.

The register dump from the host controller:

sdhci-pci :03:00.0: SDHCI controller found [1180:0822] (rev 22)


[2.030053] mmc1: SDHCI controller on PCI [:02:05.0] using ADMA
[2.030187] sdhci: === REGISTER DUMP (mmc1)===
[2.030268] sdhci: Sys addr: 0x | Version:  0x1002
[2.030342] sdhci: Blk size: 0x | Blk cnt:  0x
[2.030425] sdhci: Argument: 0x | Trn mode: 0x
[2.030503] sdhci: Present:  0x01ff | Host ctl: 0x0004
[2.030589] sdhci: Power:0x | Blk gap:  0x
[2.030668] sdhci: Wake-up:  0x | Clock:0x
[2.030753] sdhci: Timeout:  0x | Int stat: 0x
[2.030832] sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083
[2.030917] sdhci: AC12 err: 0x | Slot int: 0x00ff
[2.030996] sdhci: Caps: 0x31fe32b2 | Caps_1:   0x00030503
[2.031082] sdhci: Cmd:  0x | Max curr: 0x00c80064
[2.031158] sdhci: Host ctl2: 0x
[2.031242] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[2.031315] sdhci: ===


This shows that the controller is V3 and does support SDR50 and SDR104.

We can hack our way around this by adding a quirk to sdhci-pci.c for the 
controller to disable sending CMD11 

something along the lines of 
#define SDHCI_QUIRK_NO_VOLTAGE_SIGNAL_CMD11_SUPPORT

and check in core.c (mmc_set_signal_voltage()).  and just not send the CMD11.

very ugly.

Any other suggestions ?



Philip




On Nov 1, 2011, at 3:52 PM, Philip Rakity wrote:

> 
> Chris,
> 
> Testing my SDIO 3.0 changes UHS mode 100 m/bps   Code works find on MMP2.
> 
> Using the system
>> 64-bit Fedora 11 x86 with PCI-to-SD adapter card (Ricoh controller).
> 
> The code fails.  Bing found that if CMD11 is sent when doing the voltage 
> switch timeout errors (-110) occur.
> If CMD11 is not sent then everything. works.   Unfortunately CMD11 is 
> required.  No error is returned when the CMD11 is sent.
> 
> I know there are some quirks for the controller in sdhci-pci.  
> 
> Any ideas who to ask about this if you do not know the answer ?
> 
> regards,
> 
> Philip
> 

--
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: slow eMMC write speed

[Philip Rakity]

On Sep 28, 2011, at 7:24 PM, Praveen G K wrote:

> On Wed, Sep 28, 2011 at 5:57 PM, Philip Rakity  wrote:
>> 
>> 
>> On Sep 28, 2011, at 4:16 PM, Praveen G K wrote:
>> 
>>> On Wed, Sep 28, 2011 at 3:59 PM, J Freyensee
>>>  wrote:
>>>> On 09/28/2011 03:24 PM, Praveen G K wrote:
>>>>> 
>>>>> On Wed, Sep 28, 2011 at 2:34 PM, J Freyensee
>>>>>   wrote:
>>>>>> 
>>>>>> On 09/28/2011 02:03 PM, Praveen G K wrote:
>>>>>>> 
>>>>>>> On Wed, Sep 28, 2011 at 2:01 PM, J Freyensee
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> On 09/28/2011 01:34 PM, Praveen G K wrote:
>>>>>>>>> 
>>>>>>>>> On Wed, Sep 28, 2011 at 12:59 PM, J Freyensee
>>>>>>>>>   wrote:
>>>>>>>>>> 
>>>>>>>>>> On 09/28/2011 12:06 PM, Praveen G K wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, Sep 27, 2011 at 10:42 PM, Linus Walleij
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, Sep 23, 2011 at 7:05 AM, Praveen G K
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I am working on the block driver module of the eMMC driver (SDIO
>>>>>>>>>>>>> 3.0
>>>>>>>>>>>>> controller).  I am seeing very low write speed for eMMC transfers.
>>>>>>>>>>>>> On
>>>>>>>>>>>>> further debugging, I observed that every 63rd and 64th transfer
>>>>>>>>>>>>> takes
>>>>>>>>>>>>> a long time.
>>>>>>>>>>>> 
>>>>>>>>>>>> Are you not just seeing the card-internal garbage collection?
>>>>>>>>>>>> http://lwn.net/Articles/428584/
>>>>>>>>>>> 
>>>>>>>>>>> Does this mean, theoretically, I should be able to achieve larger
>>>>>>>>>>> speeds if I am not using linux?
>>>>>>>>>> 
>>>>>>>>>> In theory in a fairy-tale world, maybe, in reality, not really.  In
>>>>>>>>>> R/W
>>>>>>>>>> performance measurements we have done, eMMC performance in products
>>>>>>>>>> users
>>>>>>>>>> would buy falls well, well short of any theoretical numbers.  We
>>>>>>>>>> believe
>>>>>>>>>> in
>>>>>>>>>> theory, the eMMC interface should be able to support up to 100MB/s,
>>>>>>>>>> but
>>>>>>>>>> in
>>>>>>>>>> reality on real customer platforms write bandwidths (for example)
>>>>>>>>>> barely
>>>>>>>>>> approach 20MB/s, regardless if it's a Microsoft Windows environment
>>>>>>>>>> or
>>>>>>>>>> Android (Linux OS environment we care about).  So maybe it is
>>>>>>>>>> software
>>>>>>>>>> implementation issues of multiple OSs preventing higher eMMC
>>>>>>>>>> performance
>>>>>>>>>> numbers (hence the reason why I sometimes ask basic coding questions
>>>>>>>>>> of
>>>>>>>>>> the
>>>>>>>>>> MMC subsystem- the code isn't the easiest to follow); however, one
>>>>>>>>>> looks
>>>>>>>>>> no
>>>>>>>>>> further than what Apple has done with the iPad2 to see that eMMC
>>>>>>>>>> probably
>>>>>>>>>> just is not a good solution to use in the first place.  We have
>>>>>>>>>> measured
>>>>>>>>>> Apple's iPad2 write performance on *WHAT A USER WOULD SEE* being
>>>>>>>>>> double
>>>>>>>>>> what
>>>>>>>>>> we see with products using eMMC solutions. The b

Re: slow eMMC write speed

[Philip Rakity]

On Sep 28, 2011, at 4:16 PM, Praveen G K wrote:

> On Wed, Sep 28, 2011 at 3:59 PM, J Freyensee
>  wrote:
>> On 09/28/2011 03:24 PM, Praveen G K wrote:
>>> 
>>> On Wed, Sep 28, 2011 at 2:34 PM, J Freyensee
>>>   wrote:
 
 On 09/28/2011 02:03 PM, Praveen G K wrote:
> 
> On Wed, Sep 28, 2011 at 2:01 PM, J Freyensee
> wrote:
>> 
>> On 09/28/2011 01:34 PM, Praveen G K wrote:
>>> 
>>> On Wed, Sep 28, 2011 at 12:59 PM, J Freyensee
>>>   wrote:
 
 On 09/28/2011 12:06 PM, Praveen G K wrote:
> 
> On Tue, Sep 27, 2011 at 10:42 PM, Linus Walleij
> wrote:
>> 
>> On Fri, Sep 23, 2011 at 7:05 AM, Praveen G K
>> wrote:
>> 
>>> I am working on the block driver module of the eMMC driver (SDIO
>>> 3.0
>>> controller).  I am seeing very low write speed for eMMC transfers.
>>> On
>>> further debugging, I observed that every 63rd and 64th transfer
>>> takes
>>> a long time.
>> 
>> Are you not just seeing the card-internal garbage collection?
>> http://lwn.net/Articles/428584/
> 
> Does this mean, theoretically, I should be able to achieve larger
> speeds if I am not using linux?
 
 In theory in a fairy-tale world, maybe, in reality, not really.  In
 R/W
 performance measurements we have done, eMMC performance in products
 users
 would buy falls well, well short of any theoretical numbers.  We
 believe
 in
 theory, the eMMC interface should be able to support up to 100MB/s,
 but
 in
 reality on real customer platforms write bandwidths (for example)
 barely
 approach 20MB/s, regardless if it's a Microsoft Windows environment
 or
 Android (Linux OS environment we care about).  So maybe it is
 software
 implementation issues of multiple OSs preventing higher eMMC
 performance
 numbers (hence the reason why I sometimes ask basic coding questions
 of
 the
 MMC subsystem- the code isn't the easiest to follow); however, one
 looks
 no
 further than what Apple has done with the iPad2 to see that eMMC
 probably
 just is not a good solution to use in the first place.  We have
 measured
 Apple's iPad2 write performance on *WHAT A USER WOULD SEE* being
 double
 what
 we see with products using eMMC solutions. The big difference?  Apple
 doesn't use eMMC at all for the iPad2.
>>> 
>>> Thanks for all the clarification.  The problem is I am seeing write
>>> speeds of about 5MBps on a Sandisk eMMC product and I can clearly see
>>> the time lost when measured between sending a command and receiving a
>>> data irq.  I am not sure what kind of an issue this is.  5MBps feels
>>> really slow but can the internal housekeeping of the card take so much
>>> time?
>> 
>> Have you tried to trace through all structs used for an MMC
>> operation??!
>> Good gravy, there are request, mmc_queue, mmc_card, mmc_host,
>> mmc_blk_request, mmc_request, multiple mmc_command and multiple
>> scatterlists
>> that these other structs use...I've been playing around on trying to
>> cache
>> some things to try and improve performance and it blows me away how
>> many
>> variables and pointers I have to keep track of for one operation going
>> to
>> an
>> LBA on an MMC.  I keep wondering if more of the 'struct request' could
>> have
>> been used, and 1/3 of these structures could be eliminated.  And
>> another
>> thing I wonder too is how much of this infrastructure is really needed,
>> that
>> when I do ask "what is this for?" question on the list and no one
>> responds,
>> if anyone else understands if it's needed either.
> 
> I know I am not using the scatterlists, since the scatterlists are
> aggregated into a 64k bounce buffer.  Regarding the different structs,
> I am just taking them on face value assuming everything works "well".
> But, my concern is why does it take such a long time (250 ms) to
> return a transfer complete interrupt on occasional cases.  During this
> time, the kernel is just waiting for the txfer_complete interrupt.
> That's it.
 
 I think one fundamental problem with execution of the MMC commands is
 even
 though the MMC has it's own structures and own DMA/Host-controller, the
 OS's
 block subsystem and MMC subsystem do not really run independent of either
 other and each are still tied to each others' fate, holding up
 performance
 of the kernel in general.
 
 In particular, I have found that in the 2.6.36+ kernels that the sooner
 you
 can retire the 's

Re: [PATCH] MMC: ext_csd.raw_* used in comparison but never set

[Philip Rakity]

Acked-by: Philip Rakity 

On Sep 22, 2011, at 9:25 PM, Andrei Warkentin wrote:

> f39b2dd9d065151a04f5996656d1f27a7eb32d45 added code to
> only compare read-only ext_csd fields in bus width
> testing code, yet it's comparing some fields that are
> never set.
> 
> The affected fields are ext_csd.raw_erased_mem_count and
> ext_csd.raw_partition_support.
> 
> Signed-off-by: Andrei Warkentin 
> ---
> drivers/mmc/core/mmc.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 5700b1c..bb33832 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -359,6 +359,7 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 
> *ext_csd)
>* card has the Enhanced area enabled.  If so, export enhanced
>* area offset and size to user by adding sysfs interface.
>*/
> + card->ext_csd.raw_partition_support = 
> ext_csd[EXT_CSD_PARTITION_SUPPORT];
>   if ((ext_csd[EXT_CSD_PARTITION_SUPPORT] & 0x2) &&
>   (ext_csd[EXT_CSD_PARTITION_ATTRIBUTE] & 0x1)) {
>   u8 hc_erase_grp_sz =
> @@ -405,6 +406,7 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 
> *ext_csd)
>   if (card->ext_csd.rev >= 5)
>   card->ext_csd.rel_param = ext_csd[EXT_CSD_WR_REL_PARAM];
> 
> + card->ext_csd.raw_erased_mem_count = ext_csd[EXT_CSD_ERASED_MEM_CONT];
>   if (ext_csd[EXT_CSD_ERASED_MEM_CONT])
>   card->erased_byte = 0xFF;
>   else
> -- 
> 1.7.6.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: confusion regarding the CMD19 and CMD21 in eMMC/SD card spec

[Philip Rakity]

Different committee's --- Different standards.

There is no issue with overlap.  


On Sep 15, 2011, at 4:58 AM, Girish K S wrote:

> Dear all,
> The eMMC 4.5 specification mentions that the CMD21 in
> class 2 is a SEND_TUNING BLOCK command. where as the SD card
> specification
> in the given link says CMD19 in class 2 is the SEND_TUNING_BLOCK
> http://www.scribd.com/doc/50685191/53/Figure-4-8-Send-Tuning-Block-Command.
> Also the implementation in the drivers/mmc/host/sdhci.c uses the CMD19
> as the SEND_TUNING_BLOCK.
> Can anybody clarify why there is overlapping in this command number.
> May be my understand is wrong.
> 
> In the MMC spec the CMD19 is BUS_TEST_W in class 0 and CMD21 is
> reserved till eMMC 4.41 version.
> But in the SD specification (given link) CMD19 is SEND_TUNING_BLOCK
> and CMD21 is reserved.
> 
> Thanks and regards
> Girish K S
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SDHCI regression since 2.6.39

[Philip Rakity]

What card are you using ?


On Sep 13, 2011, at 1:27 PM, Jeremy Fitzhardinge wrote:

> On 09/13/2011 12:29 PM, Manoj Iyer wrote:
>> 
>> @Jeremy, Could the problem be BIOS related? we have seen a number of
>> issues with older bioses on the x220s.
> 
> I have 1.17 installed at the moment.  It looks like 1.21 is current, so
> I could try updating it.  But the Fedora 15 2.6.38 kernel worked fine
> with this controller and cards, so I don't think BIOS version is an
> issue.  Also, there's nothing obviously related to the SD controller in
> the release notes (not that I trust their competeness).
> 
>J
> 
> 
>> 
>> Here are a few cards I tested with the 3.1 RC4 kernel on Ubuntu
>> running on
>> a Lenovo X220. with Ricoh e823 card reader.
>> 
>> == kernel version ==
>> Linux u 3.1.0-0301rc4-generic #201108290905 SMP MonO Aug 29 09:11:07
>> UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
>> This is the upstream RC4 kernel build for ubuntu.
>> http://kernel.ubuntu.com/~kernel-ppa/mainline/
>> 
>> == LSPCI output for SD card reader ==
>> 0d:00.0 System peripheral [0880]: Ricoh Co Ltd Device [1180:e823] (rev
>> 04) (prog-if 01)
>>Subsystem: Lenovo Device [17aa:21db]
>>Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx-
>>Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> SERR- >Latency: 0, Cache Line Size: 64 bytes
>>Interrupt: pin A routed to IRQ 16
>>Region 0: Memory at 9150 (32-bit, non-prefetchable) [size=256]
>>Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>>Address:   Data: 
>>Capabilities: [78] Power Management version 3
>>Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
>> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>>Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME+
>>Capabilities: [80] Express (v1) Endpoint, MSI 00
>>DevCap:MaxPayload 128 bytes, PhantFunc 0, Latency L0s
>> unlimited, L1 unlimited
>>ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE+ FLReset-
>>DevCtl:Report errors: Correctable- Non-Fatal- Fatal-
>> Unsupported-
>>RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>MaxPayload 128 bytes, MaxReadReq 128 bytes
>>DevSta:CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
>> TransPend-
>>LnkCap:Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1,
>> Latency L0 <4us, L1 unlimited
>>ClockPM+ Surprise- LLActRep- BwNot-
>>LnkCtl:ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain-
>> CommClk+
>>ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>LnkSta:Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
>> DLActive- BWMgmt- ABWMgmt-
>>Capabilities: [100 v1] Virtual Channel
>>Caps:LPEVC=0 RefClk=100ns PATEntryBits=1
>>Arb:Fixed- WRR32- WRR64- WRR128-
>>Ctrl:ArbSelect=Fixed
>>Status:InProgress-
>>VC0:Caps:PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>>Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>>Ctrl:Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
>>Status:NegoPending- InProgress-
>>Capabilities: [800 v1] Advanced Error Reporting
>>UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>UEMsk:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>UESvrt:DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>CESta:RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>>CEMsk:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>>AERCap:First Error Pointer: 00, GenCap+ CGenEn- ChkCap+
>> ChkEn-
>>Kernel driver in use: sdhci-pci
>>Kernel modules: sdhci-pci
>> 
>> == Sandisk Extreme Pro 16GB ==
>> Was able to mount Ultra high speed SDHC card 45MB/s, read and write
>> works.
>> 
>> [   60.578630] mmc0: new ultra high speed SDHC card at address e624
>> [   60.611808] mmcblk0: mmc0:e624 SD16G 14.8 GiB [   60.644314] 
>> mmcblk0: p1
>> [   60.947772] mmcblk0: error -84 transferring data, sector 8192, nr
>> 8, cmd response 0x900, card status 0xb00
>> [   60.94] mmcblk0: retrying using single block read
>> 
>> /dev/mmcblk0p1 on /media/New Volume type vfat
>> (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
>> 
>> == Sandisk 2GB SD card ==
>> Was able to mount Sandisk SD card, read and write works.
>> [  298.540999] mmc0: new SD card at address 0002
>> [  298.541306] mmcblk0: mmc0:0002 0 1.86 GiB [  298.543157] 
>> mmcblk0: p1
>> 
>> /dev/mmcblk0p1 on /media/E0FD-1813 type vfat
>> (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
>> 
>> == Transcend 2GB MMC plus card ==
>> Was able to mount and read/write. Shows up as SD card.
>> [  734.032981] m

Re: [PATCH v1 1/1] mmc: sd: UHS-I bus speed should be set last in UHS initialization

[Philip Rakity]

On Aug 7, 2011, at 11:46 PM, Nath, Arindam wrote:

> Hi Subhash,
> 
> 
>> -Original Message-
>> From: Subhash Jadavani [mailto:subha...@codeaurora.org]
>> Sent: Monday, August 08, 2011 12:09 PM
>> To: Nath, Arindam; linux-mmc@vger.kernel.org; 'Philip Rakity'
>> Cc: linux-arm-...@vger.kernel.org
>> Subject: RE: [PATCH v1 1/1] mmc: sd: UHS-I bus speed should be set last
>> in UHS initialization
>> 
>> Hi Arindam,
>> 
>>> -Original Message-
>>> From: Nath, Arindam [mailto:arindam.n...@amd.com]
>>> Sent: Friday, August 05, 2011 10:54 PM
>>> To: Subhash Jadavani; linux-mmc@vger.kernel.org; 'Philip Rakity'
>>> Cc: linux-arm-...@vger.kernel.org
>>> Subject: RE: [PATCH v1 1/1] mmc: sd: UHS-I bus speed should be set
>> last
>>> in UHS initialization
>>> 
>>> Hi Subhash,
>>> 
>>> The patch in general looks good to me, I have one comment below.
>>> 
>>>> -Original Message-
>>>> From: Subhash Jadavani [mailto:subha...@codeaurora.org]
>>>> Sent: Friday, August 05, 2011 9:55 PM
>>>> To: linux-mmc@vger.kernel.org; Nath, Arindam; 'Philip Rakity'
>>>> Cc: linux-arm-...@vger.kernel.org
>>>> Subject: RE: [PATCH v1 1/1] mmc: sd: UHS-I bus speed should be set
>>> last
>>>> in UHS initialization
>>>> 
>>>> Chris, Arindam, Philip,
>>>> 
>>>> Please let me know you comments on this reworked patch.
>>>> 
>>>> Regards,
>>>> Subhash
>>>> 
>>>>> -Original Message-
>>>>> From: linux-arm-msm-ow...@vger.kernel.org [mailto:linux-arm-msm-
>>>>> ow...@vger.kernel.org] On Behalf Of Subhash Jadavani
>>>>> Sent: Thursday, August 04, 2011 4:08 PM
>>>>> To: linux-mmc@vger.kernel.org
>>>>> Cc: linux-arm-...@vger.kernel.org; Subhash Jadavani
>>>>> Subject: [PATCH v1 1/1] mmc: sd: UHS-I bus speed should be set
>> last
>>>> in
>>>>> UHS initialization
>>>>> 
>>>>> mmc_sd_init_uhs_card function sets the driver type, current limit
>>>>> and bus speed mode on card as well as on host controller side.
>>>>> 
>>>>> Currently bus speed mode is set by sending CMD6 to card and
>>>>> immediately setting the timing mode in host controller. But
>>>>> then before initiating tuning sequence, it also tries to set
>>>>> current limit by sending CMD6 to card which results in data
>>>>> timeout errors in controller if bus speed mode is SDR50/SDR104
>>> mode.
>>>>> 
>>>>> So basically bus speed mode should be set only after current
>> limit
>>>>> is set in the card and immediately after setting the bus speed
>>> mode,
>>>>> tuning sequence should be initiated.
>>>>> 
>>>>> Signed-off-by: Subhash Jadavani 
>>>>> ---
>>>>> drivers/mmc/core/sd.c |   65 ++-
>> --
>>> --
>>>> --
>>>>> 
>>>>> 1 files changed, 45 insertions(+), 20 deletions(-)
>>>>> 
>>>>> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
>>>>> index ff27741..769e587 100644
>>>>> --- a/drivers/mmc/core/sd.c
>>>>> +++ b/drivers/mmc/core/sd.c
>>>>> @@ -459,10 +459,9 @@ static int sd_select_driver_type(struct
>>> mmc_card
>>>>> *card, u8 *status)
>>>>>   return 0;
>>>>> }
>>>>> 
>>>>> -static int sd_set_bus_speed_mode(struct mmc_card *card, u8
>>> *status)
>>>>> +static int sd_get_bus_speed_mode(struct mmc_card *card)
>>>>> {
>>>>> - unsigned int bus_speed = 0, timing = 0;
>>>>> - int err;
>>>>> + int bus_speed = 0;
>>>>> 
>>>>>   /*
>>>>>* If the host doesn't support any of the UHS-I modes,
>> fallback
>>>>> on
>>>>> @@ -475,32 +474,57 @@ static int sd_set_bus_speed_mode(struct
>>>> mmc_card
>>>>> *card, u8 *status)
>>>>>   if ((card->host->caps & MMC_CAP_UHS_SDR104) &&
>>>>>   (card->sw_caps.sd3_bus_mode & SD_MODE_UHS_SDR104)) {
>>>>>   bus_speed = UHS_SDR104_BUS_SPEED;
>>>>> - tim

Re: [PATCH 2/2] ARM: mmp2: support sdio device 8787

[Philip Rakity]

On Jul 27, 2011, at 7:44 PM, zhangfei gao wrote:

>>> +
>>> +static struct fixed_voltage_config sdio_power = {
>>> + .supply_name= "vmmc",
>>> + .microvolts = 300,
>>> + .gpio   = mfp_to_gpio(MFP_PIN_GPIO57),
>>> + .enable_high= 1,
>>> + .enabled_at_boot= 0,
>>> + .init_data  = &sdio_power_data,
>>> +};
>>> +
>> 
>> ldo7 is the power source.   The 8787 is the consumer and the code should 
>> reflect this.
>> GPIO57 is an on/off switch to the 8787.
>> 
>> 
> Instead of LDO7, 8787 is powered with V_SD2, V_BATT, and VLDO12 on brownstone.
> Use PDn to control 8787 power is recommended method.
> 1. Some LDO is shared and can not be cut down.
> 2. Control LDO is much slower, some time is needed for voltage to
> decay, and the time is not accurate to control.
> 3. With LDO powered, 8787 is under control and 8787 could put itself
> to the lowest state.


LDO is dedicated to 8787 and can be left on.The power picture is ldo (as 
regulator)
and 8787 as consumer.  Code does not show this relationship.  The 8787 in deep 
sleep
draws very little power but since even this small power usage is a concern the 
disabling
the ldo can reduce power further.--
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 2/2] ARM: mmp2: support sdio device 8787

[Philip Rakity]

On Jul 27, 2011, at 10:55 AM, Philip Rakity wrote:

> Support 8787 device, provide regulator vmmc
> 
> With CONFIG_PM_RUNTIME=y
> 8787 power is enabled if any client module over sdio is insmod, and disbled 
> automatically after all client modules over sdio are rmmod
> Also 8787 power could be controled by mmc_start/stop_host via debugfs
> 
> Signed-off-by: Zhangfei Gao 
> ---
> arch/arm/mach-mmp/brownstone.c |   60 ++-
> 1 files changed, 58 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
> index c79162a..46a67b9 100644
> --- a/arch/arm/mach-mmp/brownstone.c
> +++ b/arch/arm/mach-mmp/brownstone.c
> @@ -89,6 +89,9 @@ static unsigned long brownstone_pin_config[] __initdata = {
>   GPIO41_MMC2_CMD | MFP_PULL_HIGH,
>   GPIO42_MMC2_CLK,
> 
> + GPIO57_GPIO | MFP_LPM_DRIVE_HIGH | MFP_PULL_HIGH,
> + GPIO58_GPIO | MFP_LPM_DRIVE_HIGH | MFP_PULL_HIGH,
> +
>   /* MMC2 */
>   GPIO165_MMC3_DAT7 | MFP_PULL_HIGH,
>   GPIO162_MMC3_DAT6 | MFP_PULL_HIGH,
> @@ -180,12 +183,66 @@ static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc0 
> = {
>   .clk_delay_cycles = 0x1f,
> };
> 
> +static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc1 = {
> + .flags = PXA_FLAG_CARD_PERMANENT,
> +};
> +
> static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc2 = {
>   .clk_delay_cycles = 0x1f,
>   .flags = PXA_FLAG_CARD_PERMANENT
>   | PXA_FLAG_SD_8_BIT_CAPABLE_SLOT,
> };
> 
> +static struct regulator_consumer_supply sdio_power_supplies[] = {
> + REGULATOR_SUPPLY("vmmc", "sdhci-pxav3.1"),
> +};
> +
> +static struct regulator_init_data sdio_power_data = {
> + .constraints= {
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + },
> + .num_consumer_supplies  = ARRAY_SIZE(sdio_power_supplies),
> + .consumer_supplies  = sdio_power_supplies,
> +};
> +
> +static struct fixed_voltage_config sdio_power = {
> + .supply_name= "vmmc",
> + .microvolts = 300,
> + .gpio   = mfp_to_gpio(MFP_PIN_GPIO57),
> + .enable_high= 1,
> + .enabled_at_boot= 0,
> + .init_data  = &sdio_power_data,
> +};
> +

ldo7 is the power source.   The 8787 is the consumer and the code should 
reflect this.
GPIO57 is an on/off switch to the 8787.


> +static struct platform_device sdio_power_device = {
> + .name   = "reg-fixed-voltage",
> + .id = 2,
> + .dev = {
> + .platform_data = &sdio_power,
> + },
> +};
> +
> +static void __init brownstone_init_mmc(void)
> +{
> + /*
> +  * PDn: GPIO57; RESETn: GPIO58
> +  * 8787, RESETn keeps high, PDn control power
> +  * on: PDn 1; off: PDn 0;
> +  */
> + int RESETn = mfp_to_gpio(MFP_PIN_GPIO58);
> +
> + if (gpio_request(RESETn, "sdio RESETn")) {
> + pr_err("Failed to request sdio RESETn gpio\n");
> + return;
> + }
> + gpio_direction_output(RESETn, 1);
> + gpio_free(RESETn);
> +
> + platform_device_register(&sdio_power_device);
> + mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
> + mmp2_add_sdhost(1, &mmp2_sdh_platdata_mmc1); /* sdio */
> + mmp2_add_sdhost(2, &mmp2_sdh_platdata_mmc2); /* eMMC */
> +}
> 
> static void __init brownstone_init(void)
> {
> @@ -195,8 +252,7 @@ static void __init brownstone_init(void)
>   mmp2_add_uart(1);
>   mmp2_add_uart(3);
>   mmp2_add_twsi(1, NULL, ARRAY_AND_SIZE(brownstone_twsi1_info));
> - mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
> - mmp2_add_sdhost(2, &mmp2_sdh_platdata_mmc2); /* eMMC */
> + brownstone_init_mmc();
> 
>   /* enable 5v regulator */
>   platform_device_register(&brownstone_v_5vp_device);
> -- 
> 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

--
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: sdhci: fix retuning timer wrongly deleted in sdhci_tasklet_finish

[Philip Rakity]

Reviewed-by: Philip Rakity  

From: Aaron Lu [aaron...@amd.com]
Sent: Wednesday, July 27, 2011 2:15 AM
To: zhangfei gao; Philip Rakity
Cc: Nath, Arindam; Chris Ball; linux-mmc@vger.kernel.org
Subject: Re: [PATCH] mmc: sdhci: fix retuning timer wrongly deleted in 
sdhci_tasklet_finish

On Fri, Jul 22, 2011 at 06:21:11PM +0800, zhangfei gao wrote:
>
> Thanks for explanation, looks good to me.
>

Hi Philip & Zhangfei,

Can I have your reviewed-by tag in the patch?

Thanks,
Aaron

> >> >> >
> >> >> > Signed-off-by: Aaron Lu 
> >> >> > ---
> >> >> >  drivers/mmc/host/sdhci.c |3 ---
> >> >> >  1 files changed, 0 insertions(+), 3 deletions(-)
> >> >> >
> >> >> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> >> >> > index 91d9892..6250bac 100644
> >> >> > --- a/drivers/mmc/host/sdhci.c
> >> >> > +++ b/drivers/mmc/host/sdhci.c
> >> >> > @@ -1863,9 +1863,6 @@ static void sdhci_tasklet_finish(unsigned long
> >> >> > param)
> >> >> >
> >> >> > del_timer(&host->timer);
> >> >> >
> >> >> > -   if (host->version >= SDHCI_SPEC_300)
> >> >> > -   del_timer(&host->tuning_timer);
> >> >> > -
> >> >> > mrq = host->mrq;
> >> >> >
> >> >> > /*
> >> >> > --
> >> >> > 1.7.1
> >> >>
> >> >>
> >> >
> >> >
> >>
> >
> >
>

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: sdio add regulator vsdio

[Philip Rakity]

Could we have an architecture discussion about how this is supposed to be done 
and a picture please !
(a pointer to good working code would be nice)

On brownstone the SDIO 8787 power is supplied by a ldo which is dedicated to 
the internal SDIO chip.  
The Power GPIO (PDn) is an on/off switch for the 8787.  It does not affect the 
power from the ldo.

What is the responsibility of the 8787 SDIO driver for power management ?  It 
is obviously called at
probe / init time.  Is it supposed to turn on power ?  I realize that it may 
not be aware of what device
to power on?  Does it register a call back ?  Is it responsible for turning 
itself on/off at suspend/resume
time?   Thought about open time but the firmware needs to be loaded before the 
device can respond.
Is firmware loading done at the right place ?  Should it be done at open and 
NOT at probe? That way
the driver could look present and open might handle firmware loading and power 
control.

What is the responsibilty of MMC layer.  Obviously it needs to supply power to 
the device on the bus.
Is there supposed to be a callback in the board file that handles these 
specifics ?  Would this call back
then call then set the ldo on and turn on the 8787 ?


regards,

Philip

 

On Jul 21, 2011, at 11:50 PM, Daniel Drake wrote:

> On 21 July 2011 03:34, Zhangfei Gao  wrote:
>> sdio client may be required power on/off dynamically.
>> With regulator vsdio, sdio client power on/off could be executed by 
>> mmc_power_up/down
> 
> I think you can/should do this with vmmc. When the device gets powered
> down (e.g. in runtime suspend), the voltage should be cut, so it
> should be possible to use the existing regulator.
> 
> I also looked at doing this before, when it looked like we would have
> to manipulate a GPIO reset line for SD8686. I decided that the current
> vmmc implementation in sdhci wasn't quite complete enough, but it
> wouldn't be much effort to correct this.
> 
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: ARM: mmp2: support sdio with regulator vsdio

[Philip Rakity]

With correct subject

On Jul 21, 2011, at 5:10 PM, Philip Rakity wrote:

> Hi Zhangfei,
> 
> Comments below.
> 
> Philip
> 
> 
>> Add regulator vsdio, which controled by mmc core to handle sdio chip power
>> 
>> Test With CONFIG_PM_RUNTIME=y
>> 8787 power is enabled if any client module over sdio is insmod, and disbled 
>> automatically after all client modules over sdio are rmmod
>> Also 8787 power could be controled by mmc_start/stop_host
>> 
>> Signed-off-by: Zhangfei Gao 
>> 
>> ---
>> arch/arm/mach-mmp/brownstone.c |   60 ++-
>> 1 files changed, 58 insertions(+), 2 deletions(-)
>> 
>> diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
>> index c79162a..63315e2 100644
>> --- a/arch/arm/mach-mmp/brownstone.c
>> +++ b/arch/arm/mach-mmp/brownstone.c
>> @@ -89,6 +89,9 @@ static unsigned long brownstone_pin_config[] __initdata = {
>>  GPIO41_MMC2_CMD | MFP_PULL_HIGH,
>>  GPIO42_MMC2_CLK,
>> 
>> +GPIO57_GPIO | MFP_LPM_DRIVE_HIGH | MFP_PULL_HIGH,
>> +GPIO58_GPIO | MFP_LPM_DRIVE_HIGH | MFP_PULL_HIGH,
>> +
>>  /* MMC2 */
>>  GPIO165_MMC3_DAT7 | MFP_PULL_HIGH,
>>  GPIO162_MMC3_DAT6 | MFP_PULL_HIGH,
>> @@ -180,12 +183,66 @@ static struct sdhci_pxa_platdata 
>> mmp2_sdh_platdata_mmc0 = {
>>  .clk_delay_cycles = 0x1f,
>> };
>> 
>> +static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc1 = {
>> +.flags = PXA_FLAG_CARD_PERMANENT,
>> +};
>> +
>> static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc2 = {
>>  .clk_delay_cycles = 0x1f,
>>  .flags = PXA_FLAG_CARD_PERMANENT
>>  | PXA_FLAG_SD_8_BIT_CAPABLE_SLOT,
>> };
>> 
>> +static struct regulator_consumer_supply sdio_power_supplies[] = {
>> +REGULATOR_SUPPLY("vsdio", "sdhci-pxav3.1"),
>> +};
>> +
>> +static struct regulator_init_data sdio_power_data = {
>> +.constraints= {
>> +.valid_ops_mask = REGULATOR_CHANGE_STATUS,
>> +},
>> +.num_consumer_supplies  = ARRAY_SIZE(sdio_power_supplies),
>> +.consumer_supplies  = sdio_power_supplies,
>> +};
>> +
>> +static struct fixed_voltage_config sdio_power = {
>> +.supply_name= "vsdio",
>> +.microvolts = 300,
>> +.gpio   = mfp_to_gpio(MFP_PIN_GPIO57),
>> +.enable_high= 1,
>> +.enabled_at_boot= 0,
>> +.init_data  = &sdio_power_data,
>> +};
>> +
>> +static struct platform_device sdio_power_device = {
>> +.name   = "reg-fixed-voltage",
>> +.id = 2,
>> +.dev = {
>> +.platform_data = &sdio_power,
>> +},
>> +};
>> +
>> +static int __init brownstone_init_mmc(void)
>> +{
>> +/*
>> + * PDn: GPIO58; RESETn: GPIO57
>> + * 8787, RESETn keeps high, PDn control power
>> + * on: PDn 1; off: PDn 0;
>> + */
> 
> Comment unclear
> 
> GPIO57 is power
> GPIO58 is reset
> 
> 
> 
>> +int RESETn = mfp_to_gpio(MFP_PIN_GPIO58);
>> +
>> +if (gpio_request(RESETn, "sdio RESETn")) {
>> +pr_err("Failed to request sdio RESETn gpio\n");
>> +return -EIO;
>> +}
>> +gpio_direction_output(RESETn, 1);
>> +gpio_free(RESETn);
> 
> 
> The 8787  data sheet indicated that PDn should be inactive as well as reset 
> before
> initiating power up.
> 
> Pull PDn high.
> 
> 
>> +
>> +platform_device_register(&sdio_power_device);
>> +mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
>> +mmp2_add_sdhost(1, &mmp2_sdh_platdata_mmc1); /* sdio */
>> +mmp2_add_sdhost(2, &mmp2_sdh_platdata_mmc2); /* eMMC */
>> +}
>> 
>> static void __init brownstone_init(void)
>> {
>> @@ -195,8 +252,7 @@ static void __init brownstone_init(void)
>>  mmp2_add_uart(1);
>>  mmp2_add_uart(3);
>>  mmp2_add_twsi(1, NULL, ARRAY_AND_SIZE(brownstone_twsi1_info));
>> -mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
>> -mmp2_add_sdhost(2, &mmp2_sdh_platdata_mmc2); /* eMMC */
>> +brownstone_init_mmc();
>> 
>>  /* enable 5v regulator */
>>  platform_device_register(&brownstone_v_5vp_device);

--
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: mmc: sdio add regulator vsdio

[Philip Rakity]

Hi Zhangfei,

Comments below.

Philip


>Add regulator vsdio, which controled by mmc core to handle sdio chip power
>
>Test With CONFIG_PM_RUNTIME=y
>8787 power is enabled if any client module over sdio is insmod, and disbled 
>automatically after all client modules over sdio are rmmod
>Also 8787 power could be controled by mmc_start/stop_host
>
>Signed-off-by: Zhangfei Gao 
>
>---
>arch/arm/mach-mmp/brownstone.c |   60 ++-
> 1 files changed, 58 insertions(+), 2 deletions(-)
>
>diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
>index c79162a..63315e2 100644
>--- a/arch/arm/mach-mmp/brownstone.c
>+++ b/arch/arm/mach-mmp/brownstone.c
>@@ -89,6 +89,9 @@ static unsigned long brownstone_pin_config[] __initdata = {
>   GPIO41_MMC2_CMD | MFP_PULL_HIGH,
>   GPIO42_MMC2_CLK,
> 
>+  GPIO57_GPIO | MFP_LPM_DRIVE_HIGH | MFP_PULL_HIGH,
>+  GPIO58_GPIO | MFP_LPM_DRIVE_HIGH | MFP_PULL_HIGH,
>+
>   /* MMC2 */
>   GPIO165_MMC3_DAT7 | MFP_PULL_HIGH,
>   GPIO162_MMC3_DAT6 | MFP_PULL_HIGH,
>@@ -180,12 +183,66 @@ static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc0 
>= {
>   .clk_delay_cycles = 0x1f,
> };
> 
>+static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc1 = {
>+  .flags = PXA_FLAG_CARD_PERMANENT,
>+};
>+
> static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc2 = {
>   .clk_delay_cycles = 0x1f,
>   .flags = PXA_FLAG_CARD_PERMANENT
>   | PXA_FLAG_SD_8_BIT_CAPABLE_SLOT,
> };
> 
>+static struct regulator_consumer_supply sdio_power_supplies[] = {
>+  REGULATOR_SUPPLY("vsdio", "sdhci-pxav3.1"),
>+};
>+
>+static struct regulator_init_data sdio_power_data = {
>+  .constraints= {
>+  .valid_ops_mask = REGULATOR_CHANGE_STATUS,
>+  },
>+  .num_consumer_supplies  = ARRAY_SIZE(sdio_power_supplies),
>+  .consumer_supplies  = sdio_power_supplies,
>+};
>+
>+static struct fixed_voltage_config sdio_power = {
>+  .supply_name= "vsdio",
>+  .microvolts = 300,
>+  .gpio   = mfp_to_gpio(MFP_PIN_GPIO57),
>+  .enable_high= 1,
>+  .enabled_at_boot= 0,
>+  .init_data  = &sdio_power_data,
>+};
>+
>+static struct platform_device sdio_power_device = {
>+  .name   = "reg-fixed-voltage",
>+  .id = 2,
>+  .dev = {
>+  .platform_data = &sdio_power,
>+  },
>+};
>+
>+static int __init brownstone_init_mmc(void)
>+{
>+  /*
>+   * PDn: GPIO58; RESETn: GPIO57
>+   * 8787, RESETn keeps high, PDn control power
>+   * on: PDn 1; off: PDn 0;
>+   */

Comment unclear

GPIO57 is power
GPIO58 is reset



>+  int RESETn = mfp_to_gpio(MFP_PIN_GPIO58);
>+
>+  if (gpio_request(RESETn, "sdio RESETn")) {
>+  pr_err("Failed to request sdio RESETn gpio\n");
>+  return -EIO;
>+  }
>+  gpio_direction_output(RESETn, 1);
>+  gpio_free(RESETn);


The 8787  data sheet indicated that PDn should be inactive as well as reset 
before
initiating power up.

Pull PDn high.


>+
>+  platform_device_register(&sdio_power_device);
>+  mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
>+  mmp2_add_sdhost(1, &mmp2_sdh_platdata_mmc1); /* sdio */
>+  mmp2_add_sdhost(2, &mmp2_sdh_platdata_mmc2); /* eMMC */
>+}
> 
> static void __init brownstone_init(void)
> {
>@@ -195,8 +252,7 @@ static void __init brownstone_init(void)
>   mmp2_add_uart(1);
>   mmp2_add_uart(3);
>   mmp2_add_twsi(1, NULL, ARRAY_AND_SIZE(brownstone_twsi1_info));
>-  mmp2_add_sdhost(0, &mmp2_sdh_platdata_mmc0); /* SD/MMC */
>-  mmp2_add_sdhost(2, &mmp2_sdh_platdata_mmc2); /* eMMC */
>+  brownstone_init_mmc();
> 
>   /* enable 5v regulator */
>   platform_device_register(&brownstone_v_5vp_device);
>--
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: mmc: sdio add regulator vsdio

[Philip Rakity]

Hi Zhangfei,

See below.

Philip

>
>sdio client may be required power on/off dynamically.
>With regulator vsdio, sdio client power on/off could be executed by 
>mmc_power_up/down
>
>CC: Ohad Ben-Cohen 
>Signed-off-by: Zhangfei Gao 
>
>---
>drivers/mmc/host/sdhci.c  |   24 
> include/linux/mmc/sdhci.h |2 ++
> 2 files changed, 26 insertions(+), 0 deletions(-)
>
>diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>index 790f959..61fff10 100644
>--- a/drivers/mmc/host/sdhci.c
>+++ b/drivers/mmc/host/sdhci.c
>@@ -1295,6 +1295,18 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct 
>mmc_ios *ios)
> 
>   sdhci_set_clock(host, ios->clock);
> 
>+  if (host->vsdio) {

Why does this code need to be specific to sdio ?  Should be generalized.

>+  if (ios->power_mode != host->power_mode_old) {
>+  if (ios->power_mode == MMC_POWER_OFF)
>+  regulator_disable(host->vsdio);
>+
>+  if (ios->power_mode == MMC_POWER_UP)
>+  regulator_enable(host->vsdio);
>+  }
>+
>+  host->power_mode_old = ios->power_mode;

move up inside if since if not change no need to set.

if the regulator is shared between different devices will this work ?

>+  }
>+
>   if (ios->power_mode == MMC_POWER_OFF)
>   sdhci_set_power(host, -1);
>   else
>@@ -2751,6 +2763,13 @@ int sdhci_add_host(struct sdhci_host *host)
>   regulator_enable(host->vmmc);
>   }
> 
>+  host->vsdio = regulator_get(mmc_dev(mmc), "vsdio");

comment on name -- should have nothing to do with sdio.

>+  if (IS_ERR(host->vsdio))
>+  host->vsdio = NULL;
>+  else
>+  printk(KERN_INFO "%s: vsdio regulator found\n",
>+  mmc_hostname(mmc));
>+
>   sdhci_init(host, 0);
> 
> #ifdef CONFIG_MMC_DEBUG
>@@ -2842,6 +2861,11 @@ void sdhci_remove_host(struct sdhci_host *host, int 
>dead)
>   regulator_put(host->vmmc);
>   }
> 
>+  if (host->vsdio) {
>+  regulator_disable(host->vsdio);
>+  regulator_put(host->vsdio);
>+  }
>+
>   kfree(host->adma_desc);
>   kfree(host->align_buffer);
> 
>diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
>index 13c13f8..bea07c7 100644
>--- a/include/linux/mmc/sdhci.h
>+++ b/include/linux/mmc/sdhci.h
>@@ -94,6 +94,8 @@ struct sdhci_host {
>   const struct sdhci_ops *ops;/* Low level hw interface */
> 
>   struct regulator *vmmc; /* Power regulator */
>+  struct regulator *vsdio;/* sdio Power regulator */
>+  unsigned char power_mode_old;   /* power supply mode */
> 
>   /* Internal data */
>   struct mmc_host *mmc;   /* MMC structure */
>--
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