date:20140903

Hi Ulf,

On Thu, Jan 30, 2014 at 6:37 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 This patchset improves the handling around busy detection in the mmc core 
 layer
 while operating on host supporting MMC_CAP_WAIT_WHILE_BUSY.

 A R1B response is for an mmc command, specified as and R1 but with an optional
 busy assertion on the DAT0 line. Hosts supporting MMC_CAP_WAIT_WHILE_BUSY,
 normally has a busy detection mechanism build in it's controller HW.

 Using such a feature decreases the need for polling of the card's status using
 CMD13, which is the fallback method used by the mmc core for hosts that don't
 support MMC_CAP_WAIT_WHILE_BUSY.

 Typcial commands that expects R1B responses are CMD6 (SWITCH), CMD12 (STOP),
 CMD38 (ERASE) and CMD5 (SLEEP). This patchset adresses CMD6, CMD5 and improves
 some parts where CMD12 are used. If the implemented approach becomes accepted,
 a future patchset for CMD38 can be based on top if this patchset.

 Do note, the final two patches implements support for busy detection for the
 mmci host driver, since some of it's HW variants do supports busy detection.

 Future suggested improvements related to this patchset: (Please, feel free to
 implement any of them :-) ).

 a) For CMD38, select a fixed number maximum blocks to accept for
 erase/discard/trim operations. Compute the needed timeout depending on each
 card's erase information provided through it's CSD/EXT_CSD registers. Then
 follow the same principle as for sending a CMD6.

 b) At least for CMD38, but likely for other commands as well, we could benefit
 from doing a _periodic_ CMD13 polling to handle the busy completion. This will
 also be useful for hosts supporting MMC_CAP_WAIT_WHILE_BUSY, in particular for
 cases where the host are unable to support the needed busy timeout.


Do you have the plan to implement above two items?
Since currently the max_discard_sectors is still calculated based on
max_busy_timeout of host,
it is possible that for some eMMC chips, the max_discard_sectors is 1,
which then cause the erase operation terribly slow.

Regards
Dong Aisheng

 c) Handle timeouts while polling for card's status with CMD13 in cases where
 a CMD12 has been used to finalize a data DATA_WRITE transfer.


 Ulf Hansson (13):
   mmc: core: Rename max_discard_to to max_busy_timeout
   mmc: core: Rename cmd_timeout_ms to busy_timeout
   mmc: core: Add ignore_crc flag to __mmc_switch
   mmc: core: Minor simplifications to __mmc_switch
   mmc: core: Fixup busy detection for mmc switch operations
   mmc: core: Use generic CMD6 time while switching to eMMC HS200 mode
   mmc: core: Respect host's max_busy_timeout when sending sleep cmd
   mmc: block: Use R1 responses for stop cmds for read requests
   mmc: block: Implement card_busy_detect() for busy detection
   mmc: block: Respect hw busy detection in card_busy_detect()
   mmc: block: Fixup busy detection while invoking stop cmd at recovery
   mmc: mmci: Handle CMD irq before DATA irq
   mmc: mmci: Enable support for busy detection for ux500 variant

  drivers/mmc/card/block.c   |  178 
 
  drivers/mmc/core/core.c|   11 +--
  drivers/mmc/core/mmc.c |   34 ++---
  drivers/mmc/core/mmc_ops.c |   64 ++--
  drivers/mmc/host/mmci.c|   54 +++---
  drivers/mmc/host/mmci.h|2 +
  drivers/mmc/host/sdhci.c   |   10 +--
  include/linux/mmc/core.h   |4 +-
  include/linux/mmc/host.h   |2 +-
  9 files changed, 241 insertions(+), 118 deletions(-)

 --
 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 v3] mmc: core: try 1.8v signling in ddr mode if host and device

On 2 September 2014 17:31, Jean-Michel Hautbois jhautb...@gmail.com wrote:
 2014-08-15 10:36 GMT+02:00 Dong, Chuanxiao chuanxiao.d...@intel.com:

 -Original Message-
 From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
 Sent: Friday, August 15, 2014 4:34 PM
 To: Dong, Chuanxiao
 Cc: linux-mmc; ch...@printf.org
 Subject: Re: [PATCH v3] mmc: core: try 1.8v signling in ddr mode if host and
 device

 On 15 August 2014 05:28, Chuanxiao Dong chuanxiao.d...@intel.com
 wrote:
  Even (e)MMC card can support 3.3v to 1.2v vccq in DDR, but not all
  host controller can support this, like some of the SDHCI host which
  connect to an eMMC device. Some of these host controller still needs
  to use 1.8v vccq for supporting DDR mode.

  So the sequence will be:
  if (host and device can both support 1.2v IO)
  use 1.2v IO;
  else if (host and device can both support 1.8v IO)
  use 1.8v IO;
  so if host and device can only support 3.3v IO, this is the last choice.

  Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com
  Signed-off-by: Yunpeng Gao yunpeng@intel.com

 This looks good to me! But before I queue it for 3.18 I would appreciate if 
 we
 could get some help in testing this for some various platforms, that support
 MMC DDR.

 Thanks a lot. BTW, this patch is already tested on Intel's platform which 
 can support MMC DDR.

 This patch associated with vqmmc-supply and vmmc-supply in the DT is
 working for me too on i.MX6.
 JM

Thanks! Applied for next.

I took the liberty of updating the commit msg header to mmc: core:
Fix sequence for I/O voltage in DDR mode for eMMC, to get a better
description of the patch.

I also added a tested by tag from JM.

Please tell me if you have any concern with my changes.

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

RE: [PATCH v3] mmc: core: try 1.8v signling in ddr mode if host and device

2014-09-03 Thread Dong, Chuanxiao

-Original Message-
From: linux-mmc-ow...@vger.kernel.org
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Ulf Hansson
Sent: Wednesday, September 03, 2014 3:21 PM
To: Jean-Michel Hautbois; Dong, Chuanxiao
Cc: linux-mmc; ch...@printf.org
Subject: Re: [PATCH v3] mmc: core: try 1.8v signling in ddr mode if host and
device

On 2 September 2014 17:31, Jean-Michel Hautbois jhautb...@gmail.com
wrote:
2014-08-15 10:36 GMT+02:00 Dong, Chuanxiao
chuanxiao.d...@intel.com:

-Original Message-
From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
Sent: Friday, August 15, 2014 4:34 PM
To: Dong, Chuanxiao
Cc: linux-mmc; ch...@printf.org
Subject: Re: [PATCH v3] mmc: core: try 1.8v signling in ddr mode if
host and device

On 15 August 2014 05:28, Chuanxiao Dong chuanxiao.d...@intel.com
wrote:
Even (e)MMC card can support 3.3v to 1.2v vccq in DDR, but not all
host controller can support this, like some of the SDHCI host
which connect to an eMMC device. Some of these host controller
still needs to use 1.8v vccq for supporting DDR mode.

So the sequence will be:
if (host and device can both support 1.2v IO)
use 1.2v IO;
else if (host and device can both support 1.8v IO)
use 1.8v IO;
so if host and device can only support 3.3v IO, this is the last choice.

Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com
Signed-off-by: Yunpeng Gao yunpeng@intel.com

This looks good to me! But before I queue it for 3.18 I would
appreciate if we could get some help in testing this for some
various platforms, that support MMC DDR.

Thanks a lot. BTW, this patch is already tested on Intel's platform which
can
support MMC DDR.

This patch associated with vqmmc-supply and vmmc-supply in the DT is
working for me too on i.MX6.
JM

Thanks! Applied for next.

I took the liberty of updating the commit msg header to mmc: core:
Fix sequence for I/O voltage in DDR mode for eMMC, to get a better
description of the patch.

I also added a tested by tag from JM.

Please tell me if you have any concern with my changes.
No concern from my side.

Thanks JM for testing this patch, and also thanks Ulf for making this patch
better :)

Thanks
Chuanxiao

Kind regards
Uffe
--
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��yb�X��ǧv�^�)޺{.n�+{��g��^n�r���z���h����G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�

Re: [PATCH V2] mmc: sdhci: check 1.2v IO capability for SDHC host

On 19 August 2014 05:02, Chuanxiao Dong chuanxiao.d...@intel.com wrote:
 Right now enable 1.2v IO voltage for SDHC is by using vqmmc.
 Thus for the host which doesn't have vqmmc, or its vqmmc does
 not support 1.2v, directly use MMC_CAP2_HS200 may cause HS200
 failure.

 So needs to check if vqmmc is able to support 1.2v. If it does
 not support, disable 1.2v IO for HS200.

 Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com

Thanks! Applied for next!

Kind regards
Uffe

 ---
 Changelog V2: rebase this patch, and use IS_ERR to check vqmmc.

  drivers/mmc/host/sdhci.c |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

 diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
 index 4cc2ff9..a23738c 100644
 --- a/drivers/mmc/host/sdhci.c
 +++ b/drivers/mmc/host/sdhci.c
 @@ -3009,8 +3009,13 @@ int sdhci_add_host(struct sdhci_host *host)
 /* SD3.0: SDR104 is supported so (for eMMC) the caps2
  * field can be promoted to support HS200.
  */
 -   if (!(host-quirks2  SDHCI_QUIRK2_BROKEN_HS200))
 +   if (!(host-quirks2  SDHCI_QUIRK2_BROKEN_HS200)) {
 mmc-caps2 |= MMC_CAP2_HS200;
 +   if (IS_ERR(mmc-supply.vqmmc) ||
 +   !regulator_is_supported_voltage
 +   (mmc-supply.vqmmc, 110, 130))
 +   mmc-caps2 = ~MMC_CAP2_HS200_1_2V_SDR;
 +   }
 } else if (caps[1]  SDHCI_SUPPORT_SDR50)
 mmc-caps |= MMC_CAP_UHS_SDR50;

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

Re: [PATCH 00/13] mmc: Improve busy detection for MMC_CAP_WAIT_WHILE_BUSY

On 3 September 2014 08:51, Dong Aisheng donga...@gmail.com wrote:
 Hi Ulf,

 On Thu, Jan 30, 2014 at 6:37 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 This patchset improves the handling around busy detection in the mmc core 
 layer
 while operating on host supporting MMC_CAP_WAIT_WHILE_BUSY.

 A R1B response is for an mmc command, specified as and R1 but with an 
 optional
 busy assertion on the DAT0 line. Hosts supporting MMC_CAP_WAIT_WHILE_BUSY,
 normally has a busy detection mechanism build in it's controller HW.

 Using such a feature decreases the need for polling of the card's status 
 using
 CMD13, which is the fallback method used by the mmc core for hosts that don't
 support MMC_CAP_WAIT_WHILE_BUSY.

 Typcial commands that expects R1B responses are CMD6 (SWITCH), CMD12 (STOP),
 CMD38 (ERASE) and CMD5 (SLEEP). This patchset adresses CMD6, CMD5 and 
 improves
 some parts where CMD12 are used. If the implemented approach becomes 
 accepted,
 a future patchset for CMD38 can be based on top if this patchset.

 Do note, the final two patches implements support for busy detection for the
 mmci host driver, since some of it's HW variants do supports busy detection.

 Future suggested improvements related to this patchset: (Please, feel free to
 implement any of them :-) ).

 a) For CMD38, select a fixed number maximum blocks to accept for
 erase/discard/trim operations. Compute the needed timeout depending on each
 card's erase information provided through it's CSD/EXT_CSD registers. Then
 follow the same principle as for sending a CMD6.

 b) At least for CMD38, but likely for other commands as well, we could 
 benefit
 from doing a _periodic_ CMD13 polling to handle the busy completion. This 
 will
 also be useful for hosts supporting MMC_CAP_WAIT_WHILE_BUSY, in particular 
 for
 cases where the host are unable to support the needed busy timeout.


 Do you have the plan to implement above two items?

Yes, it's on top of my TODO list for MMC. I really need to get this
done asap. Thanks for pinging me about this.

 Since currently the max_discard_sectors is still calculated based on
 max_busy_timeout of host,
 it is possible that for some eMMC chips, the max_discard_sectors is 1,
 which then cause the erase operation terribly slow.

Yes!

Another issue to fix is get MMC_CAP_ERASE removed - and that should be
possible once the above described problem has been solved.

Kind regards
Uffe
--
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 00/13] mmc: Improve busy detection for MMC_CAP_WAIT_WHILE_BUSY

On Wed, Sep 03, 2014 at 09:32:35AM +0200, Ulf Hansson wrote:
 On 3 September 2014 08:51, Dong Aisheng donga...@gmail.com wrote:
  Hi Ulf,
 
  On Thu, Jan 30, 2014 at 6:37 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
  This patchset improves the handling around busy detection in the mmc core 
  layer
  while operating on host supporting MMC_CAP_WAIT_WHILE_BUSY.
 
  A R1B response is for an mmc command, specified as and R1 but with an 
  optional
  busy assertion on the DAT0 line. Hosts supporting MMC_CAP_WAIT_WHILE_BUSY,
  normally has a busy detection mechanism build in it's controller HW.
 
  Using such a feature decreases the need for polling of the card's status 
  using
  CMD13, which is the fallback method used by the mmc core for hosts that 
  don't
  support MMC_CAP_WAIT_WHILE_BUSY.
 
  Typcial commands that expects R1B responses are CMD6 (SWITCH), CMD12 
  (STOP),
  CMD38 (ERASE) and CMD5 (SLEEP). This patchset adresses CMD6, CMD5 and 
  improves
  some parts where CMD12 are used. If the implemented approach becomes 
  accepted,
  a future patchset for CMD38 can be based on top if this patchset.
 
  Do note, the final two patches implements support for busy detection for 
  the
  mmci host driver, since some of it's HW variants do supports busy 
  detection.
 
  Future suggested improvements related to this patchset: (Please, feel free 
  to
  implement any of them :-) ).
 
  a) For CMD38, select a fixed number maximum blocks to accept for
  erase/discard/trim operations. Compute the needed timeout depending on each
  card's erase information provided through it's CSD/EXT_CSD registers. Then
  follow the same principle as for sending a CMD6.
 
  b) At least for CMD38, but likely for other commands as well, we could 
  benefit
  from doing a _periodic_ CMD13 polling to handle the busy completion. This 
  will
  also be useful for hosts supporting MMC_CAP_WAIT_WHILE_BUSY, in particular 
  for
  cases where the host are unable to support the needed busy timeout.
 
 
  Do you have the plan to implement above two items?
 
 Yes, it's on top of my TODO list for MMC. I really need to get this
 done asap. Thanks for pinging me about this.
 

Great!

  Since currently the max_discard_sectors is still calculated based on
  max_busy_timeout of host,
  it is possible that for some eMMC chips, the max_discard_sectors is 1,
  which then cause the erase operation terribly slow.
 
 Yes!
 
 Another issue to fix is get MMC_CAP_ERASE removed - and that should be
 possible once the above described problem has been solved.
 

Yes, seems MMC_CAP_ERASE is not needed anymore.

Regards
Dong Aisheng

 Kind regards
 Uffe
--
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-esdhc-imx : cannot read eMMC

Hi JM,

On Tue, Sep 2, 2014 at 11:10 PM, Jean-Michel Hautbois
jhautb...@gmail.com wrote:
 2014-09-02 11:20 GMT+02:00 Jean-Michel Hautbois
 jean-michel.hautb...@vodalys.com:
 Hi there,

 I start a new thread, as I have done lots of test and this will be clearer.
 I have problems reading and writing eMMC on my i.MX6 board with 3.17-rc3.
 Sometimes I don't have read errors explicitly in dmesg, but fdisk has
 no effects.
 I activated MMC debug in my config file, and here is an extract of
 mmc0 register dump and all mmc1 part.
 On Freescale kernel, I confirm it works well with the same board and
 sample, I can write a partition on mmc1.


My iMX6Q SabreSD board seems ok.
What board did you use?
What reading/writing problems did you meet?
I did not see errors in your log.
Can you paste the error log?

 snip

 [3.099853] sdhci [sdhci_add_host()]: mmc1: Auto-CMD23 available
 [ 3.100143] sdhci-esdhc-imx 219c000.usdhc: No vqmmc regulator found

 I have set my vqmmc-supply in my DT, and it works well now...
 I don't really know why specifying vqmmc-supply is better, but I can
 assure it is : I can mount the partition created on the eMMC.
 The only remaining errors are on boot partitions reading.
 Maybe should we have a parameter in DT in order to tell if we want to
 get thse partitions or not, instead of the return value of
 mmc_boot_partition_access() which is always 1 (if I don't miss
 something) ?


Currently I also can't see why specifying  vqmmc-supply is better.
You can measure if the voltage is different after using vqmmc-supply.

If the error you see is CRC errors(-84), usually you may want to double check
the pad setting,  board layout, which could affect the signal quality,
or capture the waveform of DATA signal and ask HW expert to help analyze
whether it's good enough.

Regards
Dong Aisheng

 Thanks,
 JM
 --
 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-esdhc-imx : cannot read eMMC

2014-09-03 10:15 GMT+02:00 Dong Aisheng donga...@gmail.com:
 Hi JM,

Hi Dong,

 On Tue, Sep 2, 2014 at 11:10 PM, Jean-Michel Hautbois
 jhautb...@gmail.com wrote:
 2014-09-02 11:20 GMT+02:00 Jean-Michel Hautbois
 jean-michel.hautb...@vodalys.com:
 Hi there,

 I start a new thread, as I have done lots of test and this will be clearer.
 I have problems reading and writing eMMC on my i.MX6 board with 3.17-rc3.
 Sometimes I don't have read errors explicitly in dmesg, but fdisk has
 no effects.
 I activated MMC debug in my config file, and here is an extract of
 mmc0 register dump and all mmc1 part.
 On Freescale kernel, I confirm it works well with the same board and
 sample, I can write a partition on mmc1.


 My iMX6Q SabreSD board seems ok.
 What board did you use?
 What reading/writing problems did you meet?
 I did not see errors in your log.
 Can you paste the error log?

This is a custom board.
You are right, activating debug seems to make the problem disappear...
I have CRC errors and my CMD signal is quite bad when this is happening.
I asked an HW engineer to look at this.

I also double checked the pads, and added the
MX6QDL_PAD_NANDF_ALE__SD4_RESET pad, but the reset signal is always
down when doing this, when it should go down then up...

Thanks,
JM
--
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-esdhc-imx: Enable boot partition access from DT

On 2 September 2014 17:49, Jean-Michel Hautbois
jean-michel.hautb...@vodalys.com wrote:
 This property is useful when we don't want to access boot partitions on eMMC

 Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
 ---
  Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
  drivers/mmc/host/sdhci-esdhc-imx.c| 8 
  include/linux/platform_data/mmc-esdhc-imx.h   | 1 +
  3 files changed, 10 insertions(+)

 diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
 b/Documentation/devicetree/bindings/mmc/mmc.txt
 index 431716e..59cc854 100644
 --- a/Documentation/devicetree/bindings/mmc/mmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
 @@ -40,6 +40,7 @@ Optional properties:
  - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
  - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
  - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
 +- no-boot-part : when preset, tells to access boot partitions

  *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers 
 line
  polarity properties, we have to fix the meaning of the normal and 
 inverted
 diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
 b/drivers/mmc/host/sdhci-esdhc-imx.c
 index ccec0e3..439e663 100644
 --- a/drivers/mmc/host/sdhci-esdhc-imx.c
 +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
 @@ -942,6 +942,11 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
 if (of_property_read_u32(np, fsl,delay-line, 
 boarddata-delay_line))
 boarddata-delay_line = 0;

 +   if (of_find_property(np, no-boot-part, NULL))
 +   boarddata-access_boot_part = false;
 +   else
 +   boarddata-access_boot_part = true;
 +
 return 0;
  }
  #else
 @@ -1119,6 +1124,9 @@ static int sdhci_esdhc_imx_probe(struct platform_device 
 *pdev)
 host-quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
 }

 +   if (!boarddata-access_boot_part)
 +   host-mmc-caps2 |= MMC_CAP2_BOOTPART_NOACC;
 +

Hmm, I don't think MMC_CAP2_BOOTPART_NOACC should have a DT binding.
Does it describe the hardware in some form?

Actually I would like to question why MMC_CAP2_BOOTPART_NOACC exists
at all. If there are cards that don't supports the BOOT area,
shouldn't we have a card quirk for it instead of a host cap? Maybe
Adrian Hunter, how originally wrote the patch for adding
MMC_CAP2_BOOTPART_NOACC, could help me understand the reasons behind
it!?

Kind regards
Uffe
--
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-esdhc-imx : cannot read eMMC

On Wed, Sep 3, 2014 at 4:40 PM, Jean-Michel Hautbois
jhautb...@gmail.com wrote:
 2014-09-03 10:39 GMT+02:00 Dong Aisheng donga...@gmail.com:
 On Wed, Sep 3, 2014 at 4:25 PM, Jean-Michel Hautbois
 jhautb...@gmail.com wrote:
 2014-09-03 10:15 GMT+02:00 Dong Aisheng donga...@gmail.com:
 Hi JM,

 Hi Dong,

 On Tue, Sep 2, 2014 at 11:10 PM, Jean-Michel Hautbois
 jhautb...@gmail.com wrote:
 2014-09-02 11:20 GMT+02:00 Jean-Michel Hautbois
 jean-michel.hautb...@vodalys.com:
 Hi there,

 I start a new thread, as I have done lots of test and this will be 
 clearer.
 I have problems reading and writing eMMC on my i.MX6 board with 3.17-rc3.
 Sometimes I don't have read errors explicitly in dmesg, but fdisk has
 no effects.
 I activated MMC debug in my config file, and here is an extract of
 mmc0 register dump and all mmc1 part.
 On Freescale kernel, I confirm it works well with the same board and
 sample, I can write a partition on mmc1.


 My iMX6Q SabreSD board seems ok.
 What board did you use?
 What reading/writing problems did you meet?
 I did not see errors in your log.
 Can you paste the error log?

 This is a custom board.
 You are right, activating debug seems to make the problem disappear...
 I have CRC errors and my CMD signal is quite bad when this is happening.
 I asked an HW engineer to look at this.

 I also double checked the pads, and added the
 MX6QDL_PAD_NANDF_ALE__SD4_RESET pad, but the reset signal is always
 down when doing this, when it should go down then up...


 The sdhci-esdhc-imx driver does not implement hw_reset support via
 eMMC reset pin.

 OK, that is what I thought, let's add it then :) ?

Yes, this feature needs to be added.

Regards
Dong Aisheng

 JM
--
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-esdhc-imx : cannot read eMMC

On Wed, Sep 3, 2014 at 4:25 PM, Jean-Michel Hautbois
jhautb...@gmail.com wrote:
 2014-09-03 10:15 GMT+02:00 Dong Aisheng donga...@gmail.com:
 Hi JM,

 Hi Dong,

 On Tue, Sep 2, 2014 at 11:10 PM, Jean-Michel Hautbois
 jhautb...@gmail.com wrote:
 2014-09-02 11:20 GMT+02:00 Jean-Michel Hautbois
 jean-michel.hautb...@vodalys.com:
 Hi there,

 I start a new thread, as I have done lots of test and this will be clearer.
 I have problems reading and writing eMMC on my i.MX6 board with 3.17-rc3.
 Sometimes I don't have read errors explicitly in dmesg, but fdisk has
 no effects.
 I activated MMC debug in my config file, and here is an extract of
 mmc0 register dump and all mmc1 part.
 On Freescale kernel, I confirm it works well with the same board and
 sample, I can write a partition on mmc1.


 My iMX6Q SabreSD board seems ok.
 What board did you use?
 What reading/writing problems did you meet?
 I did not see errors in your log.
 Can you paste the error log?

 This is a custom board.
 You are right, activating debug seems to make the problem disappear...
 I have CRC errors and my CMD signal is quite bad when this is happening.
 I asked an HW engineer to look at this.

 I also double checked the pads, and added the
 MX6QDL_PAD_NANDF_ALE__SD4_RESET pad, but the reset signal is always
 down when doing this, when it should go down then up...


The sdhci-esdhc-imx driver does not implement hw_reset support via
eMMC reset pin.

Regards
Dong Aisheng

 Thanks,
 JM
--
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-esdhc-imx : cannot read eMMC

2014-09-03 10:39 GMT+02:00 Dong Aisheng donga...@gmail.com:
 On Wed, Sep 3, 2014 at 4:25 PM, Jean-Michel Hautbois
 jhautb...@gmail.com wrote:
 2014-09-03 10:15 GMT+02:00 Dong Aisheng donga...@gmail.com:
 Hi JM,

 Hi Dong,

 On Tue, Sep 2, 2014 at 11:10 PM, Jean-Michel Hautbois
 jhautb...@gmail.com wrote:
 2014-09-02 11:20 GMT+02:00 Jean-Michel Hautbois
 jean-michel.hautb...@vodalys.com:
 Hi there,

 I start a new thread, as I have done lots of test and this will be 
 clearer.
 I have problems reading and writing eMMC on my i.MX6 board with 3.17-rc3.
 Sometimes I don't have read errors explicitly in dmesg, but fdisk has
 no effects.
 I activated MMC debug in my config file, and here is an extract of
 mmc0 register dump and all mmc1 part.
 On Freescale kernel, I confirm it works well with the same board and
 sample, I can write a partition on mmc1.


 My iMX6Q SabreSD board seems ok.
 What board did you use?
 What reading/writing problems did you meet?
 I did not see errors in your log.
 Can you paste the error log?

 This is a custom board.
 You are right, activating debug seems to make the problem disappear...
 I have CRC errors and my CMD signal is quite bad when this is happening.
 I asked an HW engineer to look at this.

 I also double checked the pads, and added the
 MX6QDL_PAD_NANDF_ALE__SD4_RESET pad, but the reset signal is always
 down when doing this, when it should go down then up...


 The sdhci-esdhc-imx driver does not implement hw_reset support via
 eMMC reset pin.

OK, that is what I thought, let's add it then :) ?
JM
--
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-esdhc-imx: Enable boot partition access from DT

2014-09-03 Thread Adrian Hunter

On 09/03/2014 11:30 AM, Ulf Hansson wrote:
 On 2 September 2014 17:49, Jean-Michel Hautbois
 jean-michel.hautb...@vodalys.com wrote:
 This property is useful when we don't want to access boot partitions on eMMC

 Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
 ---
  Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
  drivers/mmc/host/sdhci-esdhc-imx.c| 8 
  include/linux/platform_data/mmc-esdhc-imx.h   | 1 +
  3 files changed, 10 insertions(+)

 diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
 b/Documentation/devicetree/bindings/mmc/mmc.txt
 index 431716e..59cc854 100644
 --- a/Documentation/devicetree/bindings/mmc/mmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
 @@ -40,6 +40,7 @@ Optional properties:
  - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
  - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
  - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
 +- no-boot-part : when preset, tells to access boot partitions

  *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers 
 line
  polarity properties, we have to fix the meaning of the normal and 
 inverted
 diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
 b/drivers/mmc/host/sdhci-esdhc-imx.c
 index ccec0e3..439e663 100644
 --- a/drivers/mmc/host/sdhci-esdhc-imx.c
 +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
 @@ -942,6 +942,11 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
 if (of_property_read_u32(np, fsl,delay-line, 
 boarddata-delay_line))
 boarddata-delay_line = 0;

 +   if (of_find_property(np, no-boot-part, NULL))
 +   boarddata-access_boot_part = false;
 +   else
 +   boarddata-access_boot_part = true;
 +
 return 0;
  }
  #else
 @@ -1119,6 +1124,9 @@ static int sdhci_esdhc_imx_probe(struct 
 platform_device *pdev)
 host-quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
 }

 +   if (!boarddata-access_boot_part)
 +   host-mmc-caps2 |= MMC_CAP2_BOOTPART_NOACC;
 +
 
 Hmm, I don't think MMC_CAP2_BOOTPART_NOACC should have a DT binding.
 Does it describe the hardware in some form?
 
 Actually I would like to question why MMC_CAP2_BOOTPART_NOACC exists
 at all. If there are cards that don't supports the BOOT area,
 shouldn't we have a card quirk for it instead of a host cap? Maybe
 Adrian Hunter, how originally wrote the patch for adding
 MMC_CAP2_BOOTPART_NOACC, could help me understand the reasons behind
 it!?

It was added because platform firmware was able to prevent access to the
boot partitions (for security I think), so attempts to access them would
fail messily.  It was not related to any specific card.

--
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: card: Prevent partition scan for the eMMC boot areas

It seems very unlikely that eMMC devices would hold a standard
partitiontable in one of it's boot areas. Therefore, let's prevent
them from being scanned.

Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
 drivers/mmc/card/block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index ede41f0..b05c67f 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2131,7 +2131,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct 
mmc_card *card,
md-disk-queue = md-queue.queue;
md-disk-driverfs_dev = parent;
set_disk_ro(md-disk, md-read_only || default_ro);
-   if (area_type  MMC_BLK_DATA_AREA_RPMB)
+   if (area_type  (MMC_BLK_DATA_AREA_RPMB | MMC_BLK_DATA_AREA_BOOT))
md-disk-flags |= GENHD_FL_NO_PART_SCAN;
 
/*
-- 
1.9.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: sdhci-esdhc-imx: Enable boot partition access from DT

On 3 September 2014 11:02, Adrian Hunter adrian.hun...@intel.com wrote:
 On 09/03/2014 11:30 AM, Ulf Hansson wrote:
 On 2 September 2014 17:49, Jean-Michel Hautbois
 jean-michel.hautb...@vodalys.com wrote:
 This property is useful when we don't want to access boot partitions on eMMC

 Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
 ---
  Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
  drivers/mmc/host/sdhci-esdhc-imx.c| 8 
  include/linux/platform_data/mmc-esdhc-imx.h   | 1 +
  3 files changed, 10 insertions(+)

 diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
 b/Documentation/devicetree/bindings/mmc/mmc.txt
 index 431716e..59cc854 100644
 --- a/Documentation/devicetree/bindings/mmc/mmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
 @@ -40,6 +40,7 @@ Optional properties:
  - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
  - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
  - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
 +- no-boot-part : when preset, tells to access boot partitions

  *NOTE* on CD and WP polarity. To use common for all SD/MMC host 
 controllers line
  polarity properties, we have to fix the meaning of the normal and 
 inverted
 diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
 b/drivers/mmc/host/sdhci-esdhc-imx.c
 index ccec0e3..439e663 100644
 --- a/drivers/mmc/host/sdhci-esdhc-imx.c
 +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
 @@ -942,6 +942,11 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
 if (of_property_read_u32(np, fsl,delay-line, 
 boarddata-delay_line))
 boarddata-delay_line = 0;

 +   if (of_find_property(np, no-boot-part, NULL))
 +   boarddata-access_boot_part = false;
 +   else
 +   boarddata-access_boot_part = true;
 +
 return 0;
  }
  #else
 @@ -1119,6 +1124,9 @@ static int sdhci_esdhc_imx_probe(struct 
 platform_device *pdev)
 host-quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
 }

 +   if (!boarddata-access_boot_part)
 +   host-mmc-caps2 |= MMC_CAP2_BOOTPART_NOACC;
 +

 Hmm, I don't think MMC_CAP2_BOOTPART_NOACC should have a DT binding.
 Does it describe the hardware in some form?

 Actually I would like to question why MMC_CAP2_BOOTPART_NOACC exists
 at all. If there are cards that don't supports the BOOT area,
 shouldn't we have a card quirk for it instead of a host cap? Maybe
 Adrian Hunter, how originally wrote the patch for adding
 MMC_CAP2_BOOTPART_NOACC, could help me understand the reasons behind
 it!?

 It was added because platform firmware was able to prevent access to the
 boot partitions (for security I think), so attempts to access them would
 fail messily.  It was not related to any specific card.

Adrian, appreciate your clarification. After all it seems like adding
a DT binding for it should be appropriate.

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

[PATCH 0/7] mmc: sdhci/imx: a few clean up and fixes

A few clean up and fixes.

Dong Aisheng (7):
  mmc: sdhci-esdhc-imx: remove duplicated lines
  mmc: sdhci-esdhc-imx: usdhc does not have missing card interrupt
issue
  mmc: sdhci-esdhc-imx: add ADMA Length Mismatch errata fix
  mmc: sdhci: do not enable card detect interrupt for gpio cd type
  mmc: sdhci: do not enable card cd wakeup for gpio case
  mmc: sdhci-esdhc-imx: add imx6sx support
  mmc: sdhci-esdhc-imx: add quirk SDHCI_QUIRK2_BROKEN_HS200 for imx6qdl

 drivers/mmc/host/sdhci-esdhc-imx.c |   44 ---
 drivers/mmc/host/sdhci.c   |8 +-
 2 files changed, 41 insertions(+), 11 deletions(-)

-- 
1.7.8

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

[PATCH 5/7] mmc: sdhci: do not enable card cd wakeup for gpio case

Do not need to enable the controller card cd interrupt wakeup
if using GPIO as card detect since it's meaningless.

Signed-off-by: Dong Aisheng b29...@freescale.com
---
 drivers/mmc/host/sdhci.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 4d0b7b5..7aa98b9 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2548,13 +2548,16 @@ static irqreturn_t sdhci_thread_irq(int irq, void 
*dev_id)
 void sdhci_enable_irq_wakeups(struct sdhci_host *host)
 {
u8 val;
+   int gpio_cd = mmc_gpio_get_cd(host-mmc);
+
u8 mask = SDHCI_WAKE_ON_INSERT | SDHCI_WAKE_ON_REMOVE
| SDHCI_WAKE_ON_INT;
 
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 ||
+   !IS_ERR_VALUE(gpio_cd))
val = ~(SDHCI_WAKE_ON_INSERT | SDHCI_WAKE_ON_REMOVE);
sdhci_writeb(host, val, SDHCI_WAKE_UP_CONTROL);
 }
-- 
1.7.8

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

[PATCH 1/7] mmc: sdhci-esdhc-imx: remove duplicated lines

There is already the same register check above, no need the later one.
Move them into one place and delete the later one.

Signed-off-by: Dong Aisheng b29...@freescale.com
---
 drivers/mmc/host/sdhci-esdhc-imx.c |   12 +---
 1 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 587ee0e..256c901 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -315,6 +315,11 @@ static void esdhc_writel_le(struct sdhci_host *host, u32 
val, int reg)
data |= ESDHC_CTRL_D3CD;
writel(data, host-ioaddr + SDHCI_HOST_CONTROL);
}
+
+   if (val  SDHCI_INT_ADMA_ERROR) {
+   val = ~SDHCI_INT_ADMA_ERROR;
+   val |= ESDHC_INT_VENDOR_SPEC_DMA_ERR;
+   }
}
 
if (unlikely((imx_data-socdata-flags  ESDHC_FLAG_MULTIBLK_NO_INT)
@@ -335,13 +340,6 @@ static void esdhc_writel_le(struct sdhci_host *host, u32 
val, int reg)
}
}
 
-   if (unlikely(reg == SDHCI_INT_ENABLE || reg == SDHCI_SIGNAL_ENABLE)) {
-   if (val  SDHCI_INT_ADMA_ERROR) {
-   val = ~SDHCI_INT_ADMA_ERROR;
-   val |= ESDHC_INT_VENDOR_SPEC_DMA_ERR;
-   }
-   }
-
writel(val, host-ioaddr + reg);
 }
 
-- 
1.7.8

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

[PATCH 4/7] mmc: sdhci: do not enable card detect interrupt for gpio cd type

Except SDHCI_QUIRK_BROKEN_CARD_DETECTION and MMC_CAP_NONREMOVABLE,
we also do not need to handle controller native card detect interrupt
for gpio as card detect case.
If we wrong enabled the card detect interrupt for gpio case,
it will cause a lot of unexpected card detect interrupts during data transfer
which should not happen.

Signed-off-by: Dong Aisheng b29...@freescale.com
---
 drivers/mmc/host/sdhci.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f6a683b..4d0b7b5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -136,9 +136,10 @@ static void sdhci_dumpregs(struct sdhci_host *host)
 static void sdhci_set_card_detection(struct sdhci_host *host, bool enable)
 {
u32 present;
+   int gpio_cd = mmc_gpio_get_cd(host-mmc);
 
if ((host-quirks  SDHCI_QUIRK_BROKEN_CARD_DETECTION) ||
-   (host-mmc-caps  MMC_CAP_NONREMOVABLE))
+   (host-mmc-caps  MMC_CAP_NONREMOVABLE) || !IS_ERR_VALUE(gpio_cd))
return;
 
if (enable) {
-- 
1.7.8

--
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 7/7] mmc: sdhci-esdhc-imx: add quirk SDHCI_QUIRK2_BROKEN_HS200 for imx6qdl

The iMX6Q/DL can not support HS200 mode while iMX6SL and iMX6SX can,
so introduce a new flag to distinguish them.

Signed-off-by: Dong Aisheng b29...@freescale.com
---
 drivers/mmc/host/sdhci-esdhc-imx.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 87179c4..16eff00 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -120,6 +120,8 @@
  * when reading data from the card
  */
 #define ESDHC_FLAG_ERR004536   BIT(7)
+/* The IP supports HS200 mode */
+#define ESDHC_FLAG_HS200   BIT(8)
 
 struct esdhc_soc_data {
u32 flags;
@@ -147,12 +149,13 @@ static struct esdhc_soc_data usdhc_imx6q_data = {
 
 static struct esdhc_soc_data usdhc_imx6sl_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
-   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_ERR004536,
+   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_ERR004536
+   | ESDHC_FLAG_HS200,
 };
 
 static struct esdhc_soc_data usdhc_imx6sx_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
-   | ESDHC_FLAG_HAVE_CAP1,
+   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200,
 };
 
 struct pltfm_imx_data {
@@ -1063,6 +1066,9 @@ static int sdhci_esdhc_imx_probe(struct platform_device 
*pdev)
host-quirks2 |= SDHCI_QUIRK2_PRESET_VALUE_BROKEN;
host-mmc-caps |= MMC_CAP_1_8V_DDR;
 
+   if (!(imx_data-socdata-flags  ESDHC_FLAG_HS200))
+   host-quirks2 |= SDHCI_QUIRK2_BROKEN_HS200;
+
/*
 * errata ESDHC_FLAG_ERR004536 fix for MX6Q TO1.2 and MX6DL
 * TO1.1, it's harmless for MX6SL
-- 
1.7.8

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

[PATCH 2/7] mmc: sdhci-esdhc-imx: usdhc does not have missing card interrupt issue

The usdhc does not have missing card interrupt issue, so execute the
workaround conditionally.

Signed-off-by: Dong Aisheng b29...@freescale.com
---
 drivers/mmc/host/sdhci-esdhc-imx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 256c901..9594bf8 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -300,7 +300,7 @@ static void esdhc_writel_le(struct sdhci_host *host, u32 
val, int reg)
u32 data;
 
if (unlikely(reg == SDHCI_INT_ENABLE || reg == SDHCI_SIGNAL_ENABLE)) {
-   if (val  SDHCI_INT_CARD_INT) {
+   if ((val  SDHCI_INT_CARD_INT)  !esdhc_is_usdhc(imx_data)) {
/*
 * Clear and then set D3CD bit to avoid missing the
 * card interrupt.  This is a eSDHC controller problem
-- 
1.7.8

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

Re: [PATCH 0/7] mmc: sdhci/imx: a few clean up and fixes

2014-09-03 Thread Fabio Estevam

Hi Dong,

On Wed, Sep 3, 2014 at 9:04 AM, Dong Aisheng b29...@freescale.com wrote:
 A few clean up and fixes.

Usually it is a good idea to separate cleanup from fixes. Do any of
the fixes should go to 3.17-rc or stable?

Regards,

Fabio Estevam
--
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 6/7] mmc: sdhci-esdhc-imx: add imx6sx support

The imx6sx usdhc is derived from imx6sl, the difference is minor.
imx6sx have the errata ESDHC_FLAG_ERR004536 fixed.
So introduce a new compatible string for imx6sx to distinguish them.

Signed-off-by: Dong Aisheng b29...@freescale.com
---
 drivers/mmc/host/sdhci-esdhc-imx.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
b/drivers/mmc/host/sdhci-esdhc-imx.c
index dc0e384..87179c4 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -150,6 +150,11 @@ static struct esdhc_soc_data usdhc_imx6sl_data = {
| ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_ERR004536,
 };
 
+static struct esdhc_soc_data usdhc_imx6sx_data = {
+   .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
+   | ESDHC_FLAG_HAVE_CAP1,
+};
+
 struct pltfm_imx_data {
u32 scratchpad;
struct pinctrl *pinctrl;
@@ -190,6 +195,7 @@ static const struct of_device_id imx_esdhc_dt_ids[] = {
{ .compatible = fsl,imx35-esdhc, .data = esdhc_imx35_data, },
{ .compatible = fsl,imx51-esdhc, .data = esdhc_imx51_data, },
{ .compatible = fsl,imx53-esdhc, .data = esdhc_imx53_data, },
+   { .compatible = fsl,imx6sx-usdhc, .data = usdhc_imx6sx_data, },
{ .compatible = fsl,imx6sl-usdhc, .data = usdhc_imx6sl_data, },
{ .compatible = fsl,imx6q-usdhc, .data = usdhc_imx6q_data, },
{ /* sentinel */ }
-- 
1.7.8

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

Re: [PATCH 0/7] mmc: sdhci/imx: a few clean up and fixes

On Wed, Sep 03, 2014 at 09:34:28AM -0300, Fabio Estevam wrote:
 Hi Dong,
 
 On Wed, Sep 3, 2014 at 9:04 AM, Dong Aisheng b29...@freescale.com wrote:
  A few clean up and fixes.
 
 Usually it is a good idea to separate cleanup from fixes. Do any of
 the fixes should go to 3.17-rc or stable?
 

Thanks for reminder.
Most are tiny fixes and clean up.
If to be strictly, Patch 3 mmc: sdhci-esdhc-imx: add ADMA Length Mismatch 
errata fix
could go to stable although the issue is very very hard to reproduce as stated
in errata.

Regards
Dong Aisheng

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

[PATCH 3/7] mmc: sdhci-esdhc-imx: add ADMA Length Mismatch errata fix

The uSDHC has an ADMA Length Mismatch errata ERR004536 which may
cause ADMA work abnormally. The errata has already been fixed for
i.MX6Q TO1.2 and i.MX6DL TO1.1 by enable the bit 7 in 0x6c register.
Unfortunately this fix is not included in i.MX6SL.
So we disable ADMA for i.MX6SL and use SDMA instead.

Signed-off-by: Dong Aisheng b29...@freescale.com
---
 drivers/mmc/host/sdhci-esdhc-imx.c |   18 +-
 1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 9594bf8..dc0e384 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -114,6 +114,12 @@
 #define ESDHC_FLAG_STD_TUNING  BIT(5)
 /* The IP has SDHCI_CAPABILITIES_1 register */
 #define ESDHC_FLAG_HAVE_CAP1   BIT(6)
+/*
+ * The IP has errata ERR004536
+ * uSDHC: ADMA Length Mismatch Error occurs if the AHB read access is slow,
+ * when reading data from the card
+ */
+#define ESDHC_FLAG_ERR004536   BIT(7)
 
 struct esdhc_soc_data {
u32 flags;
@@ -141,7 +147,7 @@ static struct esdhc_soc_data usdhc_imx6q_data = {
 
 static struct esdhc_soc_data usdhc_imx6sl_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
-   | ESDHC_FLAG_HAVE_CAP1,
+   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_ERR004536,
 };
 
 struct pltfm_imx_data {
@@ -1050,6 +1056,13 @@ static int sdhci_esdhc_imx_probe(struct platform_device 
*pdev)
writel(0x08100810, host-ioaddr + ESDHC_WTMK_LVL);
host-quirks2 |= SDHCI_QUIRK2_PRESET_VALUE_BROKEN;
host-mmc-caps |= MMC_CAP_1_8V_DDR;
+
+   /*
+* errata ESDHC_FLAG_ERR004536 fix for MX6Q TO1.2 and MX6DL
+* TO1.1, it's harmless for MX6SL
+*/
+   writel(readl(host-ioaddr + 0x6c) | BIT(7),
+   host-ioaddr + 0x6c);
}
 
if (imx_data-socdata-flags  ESDHC_FLAG_MAN_TUNING)
@@ -1061,6 +1074,9 @@ static int sdhci_esdhc_imx_probe(struct platform_device 
*pdev)
ESDHC_STD_TUNING_EN | ESDHC_TUNING_START_TAP,
host-ioaddr + ESDHC_TUNING_CTRL);
 
+   if (imx_data-socdata-flags  ESDHC_FLAG_ERR004536)
+   host-quirks |= SDHCI_QUIRK_BROKEN_ADMA;
+
boarddata = imx_data-boarddata;
if (sdhci_esdhc_imx_probe_dt(pdev, boarddata)  0) {
if (!host-mmc-parent-platform_data) {
-- 
1.7.8

--
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-esdhc-imx: Enable boot partition access from DT

2014-09-03 11:09 GMT+02:00 Ulf Hansson ulf.hans...@linaro.org:
 On 3 September 2014 11:02, Adrian Hunter adrian.hun...@intel.com wrote:
 On 09/03/2014 11:30 AM, Ulf Hansson wrote:
 On 2 September 2014 17:49, Jean-Michel Hautbois
 jean-michel.hautb...@vodalys.com wrote:
 This property is useful when we don't want to access boot partitions on 
 eMMC

 Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
 ---
  Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
  drivers/mmc/host/sdhci-esdhc-imx.c| 8 
  include/linux/platform_data/mmc-esdhc-imx.h   | 1 +
  3 files changed, 10 insertions(+)

 diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
 b/Documentation/devicetree/bindings/mmc/mmc.txt
 index 431716e..59cc854 100644
 --- a/Documentation/devicetree/bindings/mmc/mmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
 @@ -40,6 +40,7 @@ Optional properties:
  - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
  - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
  - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
 +- no-boot-part : when preset, tells to access boot partitions

  *NOTE* on CD and WP polarity. To use common for all SD/MMC host 
 controllers line
  polarity properties, we have to fix the meaning of the normal and 
 inverted
 diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
 b/drivers/mmc/host/sdhci-esdhc-imx.c
 index ccec0e3..439e663 100644
 --- a/drivers/mmc/host/sdhci-esdhc-imx.c
 +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
 @@ -942,6 +942,11 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
 if (of_property_read_u32(np, fsl,delay-line, 
 boarddata-delay_line))
 boarddata-delay_line = 0;

 +   if (of_find_property(np, no-boot-part, NULL))
 +   boarddata-access_boot_part = false;
 +   else
 +   boarddata-access_boot_part = true;
 +
 return 0;
  }
  #else
 @@ -1119,6 +1124,9 @@ static int sdhci_esdhc_imx_probe(struct 
 platform_device *pdev)
 host-quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
 }

 +   if (!boarddata-access_boot_part)
 +   host-mmc-caps2 |= MMC_CAP2_BOOTPART_NOACC;
 +

 Hmm, I don't think MMC_CAP2_BOOTPART_NOACC should have a DT binding.
 Does it describe the hardware in some form?

 Actually I would like to question why MMC_CAP2_BOOTPART_NOACC exists
 at all. If there are cards that don't supports the BOOT area,
 shouldn't we have a card quirk for it instead of a host cap? Maybe
 Adrian Hunter, how originally wrote the patch for adding
 MMC_CAP2_BOOTPART_NOACC, could help me understand the reasons behind
 it!?

 It was added because platform firmware was able to prevent access to the
 boot partitions (for security I think), so attempts to access them would
 fail messily.  It was not related to any specific card.

 Adrian, appreciate your clarification. After all it seems like adding
 a DT binding for it should be appropriate.

 Kind regards
 Uffe

Thanks Adrian :).
Well, there is boot partitions and rpmb partition, and maybe should we
have a binding to prevent access to both of them ?
Something else came to my mind, when you want to boot on eMMC, do you
need to write u-boot in boot partitions or is it written at the
logical adress 0 which is what fdisk uses as start ?
Because, if this is not usuable but just scanned I can't see why we
bother doing it... ?

Thanks,
JM
--
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: sdhci-msm: Make tuning block table endian agnostic

2014-09-03 Thread Stephen Boyd

If we're tuning on a big-endian CPU we'll never determine we properly
tuned the device because we compare the data we received from the
controller with a table that assumes the CPU is little-endian.
Change the table to be an array of bytes instead of 32-bit words
so we can use memcmp() without needing to byte-swap every word
depending on the endianess of the CPU.

Cc: Asutosh Das asuto...@codeaurora.org
Cc: Venkat Gopalakrishnan venk...@codeaurora.org
Reviewed-by: Georgi Djakov gdja...@mm-sol.com
Fixes: 415b5a75da43 mmc: sdhci-msm: Add platform_execute_tuning implementation
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
 drivers/mmc/host/sdhci-msm.c | 42 +++---
 1 file changed, 27 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 40573a58486a..5aabffc15ae8 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -47,22 +47,34 @@
 #define CMUX_SHIFT_PHASE_SHIFT 24
 #define CMUX_SHIFT_PHASE_MASK  (7  CMUX_SHIFT_PHASE_SHIFT)
 
-static const u32 tuning_block_64[] = {
-   0x00ff0fff, 0xccc3ccff, 0xffcc3cc3, 0xeffefffe,
-   0xddffdfff, 0xfbfffbff, 0xff7fffbf, 0xefbdf777,
-   0xf0fff0ff, 0x3cccfc0f, 0xcfcc33cc, 0xeeffefff,
-   0xfdfffdff, 0xffbfffdf, 0xfff7ffbb, 0xde7b7ff7
+static const u8 tuning_block_64[] = {
+   0xff, 0x0f, 0xff, 0x00, 0xff, 0xcc, 0xc3, 0xcc,
+   0xc3, 0x3c, 0xcc, 0xff, 0xfe, 0xff, 0xfe, 0xef,
+   0xff, 0xdf, 0xff, 0xdd, 0xff, 0xfb, 0xff, 0xfb,
+   0xbf, 0xff, 0x7f, 0xff, 0x77, 0xf7, 0xbd, 0xef,
+   0xff, 0xf0, 0xff, 0xf0, 0x0f, 0xfc, 0xcc, 0x3c,
+   0xcc, 0x33, 0xcc, 0xcf, 0xff, 0xef, 0xff, 0xee,
+   0xff, 0xfd, 0xff, 0xfd, 0xdf, 0xff, 0xbf, 0xff,
+   0xbb, 0xff, 0xf7, 0xff, 0xf7, 0x7f, 0x7b, 0xde,
 };
 
-static const u32 tuning_block_128[] = {
-   0xff00, 0x, 0x, 0x33cc,
-   0xcccc, 0x, 0xeeff, 0xffff,
-   0xffdd, 0x, 0xbbff, 0xbbff,
-   0xffbb, 0xff77, 0x77ff, 0xffeeddbb,
-   0x00ff, 0x00ff, 0xcc00, 0xcc33,
-   0x, 0xffcc, 0xffee, 0x,
-   0xddff, 0xddff, 0xffdd, 0xffbb,
-   0x, 0x77ff, 0xffff, 0xeeddbb77
+static const u8 tuning_block_128[] = {
+   0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x00,
+   0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc, 0xcc,
+   0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff, 0xff,
+   0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee, 0xff,
+   0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd, 0xdd,
+   0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff, 0xbb,
+   0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff, 0xff,
+   0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee, 0xff,
+   0xff, 0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00,
+   0x00, 0xff, 0xff, 0xcc, 0xcc, 0xcc, 0x33, 0xcc,
+   0xcc, 0xcc, 0x33, 0x33, 0xcc, 0xcc, 0xcc, 0xff,
+   0xff, 0xff, 0xee, 0xff, 0xff, 0xff, 0xee, 0xee,
+   0xff, 0xff, 0xff, 0xdd, 0xff, 0xff, 0xff, 0xdd,
+   0xdd, 0xff, 0xff, 0xff, 0xbb, 0xff, 0xff, 0xff,
+   0xbb, 0xbb, 0xff, 0xff, 0xff, 0x77, 0xff, 0xff,
+   0xff, 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee,
 };
 
 struct sdhci_msm_host {
@@ -359,7 +371,7 @@ static int sdhci_msm_execute_tuning(struct sdhci_host 
*host, u32 opcode)
 {
int tuning_seq_cnt = 3;
u8 phase, *data_buf, tuned_phases[16], tuned_phase_cnt = 0;
-   const u32 *tuning_block_pattern = tuning_block_64;
+   const u8 *tuning_block_pattern = tuning_block_64;
int size = sizeof(tuning_block_64); /* Pattern size in bytes */
int rc;
struct mmc_host *mmc = host-mmc;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

SD-card endurance, wear and crappiness

2014-09-03 Thread Johan Rudholm

Hi all,

as you know, NAND flash can be programmed a limited number of times
before it reaches end of life, the number of times varies with the
NAND technology used, among other things.

As far as I can tell from the simplified SD-spec, there is no way of
asking the card about how many program/erase cycles it can handle, or
how many p/e cycles are left before reaching EOL. Right?

So, if one should want to give the user some kind of early warning
that it's time to change SD-cards, is there a way? Also, when a card
has reached EOL, is there a way of telling this condition apart from
all other error conditions that may arise? As you know, depending on
the quality of the card and controller, read timeouts, write timeouts,
lockups etc may occur but can usually be fixed with a power cycle.

I'm thinking of collecting simple statistics from for instance
card/block.c and exposing it via an ioctl or sysfs. The statistics can
be gathered and processed by some user space process which can
determine if the user needs to be alerted. The statistics can be, for
instance:

* Writes/reads that timeout, but succeed after a retry
* Writes/reads that timeout and never succeeds
* Different kinds of errors in the card status
* Anything else?

Perhaps it's not possible to detect worn out cards this way, but at
least it could point out and warn about crappy cards?

Any thoughts about this?

Kind regards, Johan
--
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-esdhc-imx : cannot read eMMC