date:20140904

Hi

On 3 September 2014 15:08, Jean-Michel Hautbois
jean-michel.hautb...@vodalys.com wrote:
 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... ?

Hi Jean-Michel,

I am not sure adding a DT binding for non access to rpmb would be
needed. At least until we heard of a similar case as Adrian describes
but for rpmb.

BTW, I just posted a patch which disabled partition scan of the boot
area, what to you think about that?
http://marc.info/?l=linux-mmcm=140973496402028w=2

Finally I am also wondering whether we could and thus should, handle
these situations entirely without using a host cap. In principle what
we need is a more sophisticated error handling when the switch errors
occurs, while trying to switch to the boot area/rpmb partitions. Could
you maybe investigate that option, before we decide to add a new DT
binding?

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: [RFC PATCH 1/1 v8]mmc: Support-FFU-for-eMMC-v5.0

2014-09-04 Thread Alex Lemberg

As for FW file size - we also know about 512KB data and above.

Thanks,
Alex

-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Hsin-Hsiang Tseng
Sent: Thursday, September 04, 2014 4:06 AM
To: Ulf Hansson
Cc: Alex Lemberg; linux-mmc@vger.kernel.org; c...@laptop.org; Grant
Grundler; Avi Shchislowski; Gwendal Grignou (gwen...@chromium.org)
Subject: Re: [RFC PATCH 1/1 v8]mmc: Support-FFU-for-eMMC-v5.0

Hi, Ulf

the data we expected to write in my case is about 288KB.
BTW, Alex's FFU flow already implemented on my platform which using exynos
SoC without problem.

Thanks,
Hsinhsiang

2014-09-01 19:27 GMT+08:00 Ulf Hansson ulf.hans...@linaro.org:
On 1 September 2014 11:26, Alex Lemberg alex.lemb...@sandisk.com
wrote:
[snip]

My conclusion from that is (correct me if I am wrong, since it may
be vendor specific), that only minor modifications should be needed
to the mmc ioctl. We need to add special treatment for when
cmd.opcode == MMC_FFU_DOWNLOAD_OP. In such scenario the
following
sequence needs to be maintained.

1. Claim host etc.
2. Set FFU mode.
3. Write some sectors to the FFU area, but in the same way as any
other mmc ioctl WRITE is done.
4. Set normal mode.
5. Relase host etc.

That sequence then needs to be repeated to write the complete
firmware, depending on buffer size. Between each and every piece of
FFU data that is written, normal READ/WRITE operations can be served.
Right?

We checked again the current IOCTL implementation, and we see issues
In implementing FFU as suggested above:

1. No support for multiple Write operations.
For running Multiple I/O, user need to send CMD23 or CMD12.
So structures sbc or stop of mmc_blk_request should be set
accordingly.

You are right regarding multiple I/O!

I suppose using single block write option (CMD24) still can be used
for FFU, right?

Yes, we would suffer from unoptimized performance, but on the other
hand - how much data could we typically be expected to write? Do you
have some rough numbers that you can share?

2. There is a limit in chunk size in current implementation of IOCTL.
From some reason we can't write more than 64KB on our platform,
Although, the MMC_IOC_MAX_BYTES is defined to be 128KB

That is likely because the mmc host driver may limit the size, due to
it's controller HW.

Based on this, we think that using existing IOCTL implementation is
not a good solution for FFU.

Okay, let's for now continue with your current approach and try to
address those concerns I have raised while reviewing the code. I will
happily review new versions of the patch(es).

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

2014-09-04 Thread Dong Aisheng

On Wed, Sep 3, 2014 at 11:11 PM, Jean-Michel Hautbois
jhautb...@gmail.com wrote:
 2014-09-03 10:15 GMT+02:00 Dong Aisheng donga...@gmail.com:
 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?

 When CONFIG_MMC_DEBUG=y there is no error.
 When CONFIG_MMC_DEBUG=n then, I get :

 [2.036958] SW2: Restricting voltage, 330-195uV
 [2.036965] mmc1: Switching to 1.8V signalling voltage  failed
 [2.043714] mmc1: new DDR MMC card at address 0001
 [2.044738] mmcblk1: mmc1:0001 SEM02G 1.82 GiB
 [2.045007] mmcblk1rpmb: mmc1:0001 SEM02G partition 3 128 KiB
 [2.048345] mmcblk1: error -84 transferring data, sector 0, nr 8,
 cmd response 0x900, card status 0xb00

It seems you're using Sandisk eMMC chip, right?
We ever got an errata of Sandisk eMMC that it needs certain delay
befor sending cmd13
after cmd6.
We tried 1ms seems ok for such eMMC chip.
You may give a try.

e.g.
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 49f04bc..83d17a9 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -440,6 +440,12 @@ int __mmc_switch(struct mmc_card *card, u8 set,
u8 index, u8 value,
if (!use_busy_signal)
return 0;

+   /*
+* WORKAROUND: for Sandisk eMMC cards, it might need certain delay
+* before sending CMD13 after CMD6
+*/
+   mdelay(1);
+
/* Must check status to be sure of no errors */
timeout = jiffies + msecs_to_jiffies(MMC_OPS_TIMEOUT_MS);
do {

BTW, you should also make sure the signal quality is not bad which may
also cause such issue.

Regards
Dong Aisheng

 [2.048352] mmcblk1: retrying using single block read
 [2.048858] mmcblk1: error -84 transferring data, sector 0, nr 8,
 cmd response 0x900, card status 0x0
 [2.048933] end_request: I/O error, dev mmcblk1, sector 0
 [2.049449] mmcblk1: error -84 transferring data, sector 1, nr 7,
 cmd response 0x900, card status 0x0
 [2.049459] end_request: I/O error, dev mmcblk1, sector 1
 [2.049969] mmcblk1: error -84 transferring data, sector 2, nr 6,
 cmd response 0x900, card status 0x0
 [2.049978] end_request: I/O error, dev mmcblk1, sector 2
 [2.050484] mmcblk1: error -84 transferring data, sector 3, nr 5,
 cmd response 0x900, card status 0x0
 [2.050493] end_request: I/O error, dev mmcblk1, sector 3
 [2.050998] mmcblk1: error -84 transferring data, sector 4, nr 4,
 cmd response 0x900, card status 0x0
 [2.051008] end_request: I/O error, dev mmcblk1, sector 4
 [2.051512] mmcblk1: error -84 transferring data, sector 5, nr 3,
 cmd response 0x900, card status 0x0
 [2.051521] end_request: I/O error, dev mmcblk1, sector 5
 [2.052028] mmcblk1: error -84 transferring data, sector 6, nr 2,
 cmd response 0x900, card status 0x0
 [2.052038] end_request: I/O error, dev mmcblk1, sector 6
 [2.052542] mmcblk1: error -84 transferring data, sector 7, nr 1,
 cmd response 0x900, card status 0x0
 [2.052551] end_request: I/O error, dev mmcblk1, sector 7
 [2.052620] Buffer I/O error on device mmcblk1, logical block 0
 [2.053338] mmcblk1: error -84 transferring data, sector 0, nr 8,
 cmd response 0x900, card status 0xb00
 [2.053345] mmcblk1: retrying using single block read
 [2.053849] mmcblk1: error -84 transferring data, sector 0, nr 8,
 cmd response 0x900, card status 0x0
 [2.053859] end_request: I/O error, dev mmcblk1, sector 0
 [2.054378] mmcblk1: error -84 transferring data, sector 1, nr 7,
 cmd response 0x900, card status 0x0
 [2.054388] end_request: I/O error, dev mmcblk1, sector 1
 [2.054892] mmcblk1: error -84 transferring data, sector 2, nr 6,
 cmd response 0x900, card status 0x0
 [2.055403] mmcblk1: error -84 transferring data, sector 3, nr 5,
 cmd response 0x900, card status 0x0
 [2.055917] mmcblk1: error -84 transferring data, sector 4, nr 4,
 cmd response 0x900, card status 0x0
 [2.056428] mmcblk1: error -84 transferring data, sector 5, nr 3,
 cmd response 0x900, card status 0x0
 [2.056937] mmcblk1: error -84 transferring data, sector 6, nr 2,
 cmd response 0x900, card status 0x0
 [2.057446] mmcblk1: error -84 transferring data, sector 7, nr 1,
 cmd response 0x900,

Re: sdhci-esdhc-imx : cannot read eMMC

2014-09-04 Thread Arnd Bergmann

On Thursday 04 September 2014 17:37:59 Dong Aisheng wrote:
 index 49f04bc..83d17a9 100644
 --- a/drivers/mmc/core/mmc_ops.c
 +++ b/drivers/mmc/core/mmc_ops.c
 @@ -440,6 +440,12 @@ int __mmc_switch(struct mmc_card *card, u8 set,
 u8 index, u8 value,
 if (!use_busy_signal)
 return 0;
 
 +   /*
 +* WORKAROUND: for Sandisk eMMC cards, it might need certain delay
 +* before sending CMD13 after CMD6
 +*/
 +   mdelay(1);
 +
 /* Must check status to be sure of no errors */
 timeout = jiffies + msecs_to_jiffies(MMC_OPS_TIMEOUT_MS);
 do {
 
 

mdelay() is a rather nasty function to call because it hogs the CPU.
Better use msleep(), which will allow another process to use the
CPU in the meantime.
It might be worthwhile to check the manufacturer ID field so we
don't delay the boot process for non-sandisk devices.

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

Re: [PATCH] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

Hi Ulf,

 I am not sure adding a DT binding for non access to rpmb would be
 needed. At least until we heard of a similar case as Adrian describes
 but for rpmb.

 BTW, I just posted a patch which disabled partition scan of the boot
 area, what to you think about that?
 http://marc.info/?l=linux-mmcm=140973496402028w=2

 Finally I am also wondering whether we could and thus should, handle
 these situations entirely without using a host cap. In principle what
 we need is a more sophisticated error handling when the switch errors
 occurs, while trying to switch to the boot area/rpmb partitions. Could
 you maybe investigate that option, before we decide to add a new DT
 binding?

According to me and what Hsin-Hsiang Tseng wrote, it seems that we
should be able to have access to boot partitions if we want to give a
possibility of writing u-boot in one (or both) of them. This is the
way the i.MX6 will boot on a eMMC if I read the reference manual
correctly, but I didn't tested it yet.
But there is no need to scan those partitions at boot, as there will
probably never be a partition table inside, as you said.
All we need is providing access to mmc[n]blkpboot0 and mmc[n]blkpboot1
and a way to tell which one is used as default boot partition.

This is my point of view, but I didn't read JESD84-A441 so I don't
know if this is the good way.

Regards,
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-04 11:43 GMT+02:00 Arnd Bergmann a...@arndb.de:
 On Thursday 04 September 2014 17:37:59 Dong Aisheng wrote:
 index 49f04bc..83d17a9 100644
 --- a/drivers/mmc/core/mmc_ops.c
 +++ b/drivers/mmc/core/mmc_ops.c
 @@ -440,6 +440,12 @@ int __mmc_switch(struct mmc_card *card, u8 set,
 u8 index, u8 value,
 if (!use_busy_signal)
 return 0;

 +   /*
 +* WORKAROUND: for Sandisk eMMC cards, it might need certain delay
 +* before sending CMD13 after CMD6
 +*/
 +   mdelay(1);
 +
 /* Must check status to be sure of no errors */
 timeout = jiffies + msecs_to_jiffies(MMC_OPS_TIMEOUT_MS);
 do {



 mdelay() is a rather nasty function to call because it hogs the CPU.
 Better use msleep(), which will allow another process to use the
 CPU in the meantime.
 It might be worthwhile to check the manufacturer ID field so we
 don't delay the boot process for non-sandisk devices.

OK, so I will also move MFID defines from drivers/mmc/core/block.c to
include/linux/mmc/card.h which will allow the use of these defines
from mmc_ops.c.

I am testing right now and if it works, I will send a patch.
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-04 11:55 GMT+02:00 Jean-Michel Hautbois jhautb...@gmail.com:
 2014-09-04 11:43 GMT+02:00 Arnd Bergmann a...@arndb.de:
 On Thursday 04 September 2014 17:37:59 Dong Aisheng wrote:
 index 49f04bc..83d17a9 100644
 --- a/drivers/mmc/core/mmc_ops.c
 +++ b/drivers/mmc/core/mmc_ops.c
 @@ -440,6 +440,12 @@ int __mmc_switch(struct mmc_card *card, u8 set,
 u8 index, u8 value,
 if (!use_busy_signal)
 return 0;

 +   /*
 +* WORKAROUND: for Sandisk eMMC cards, it might need certain delay
 +* before sending CMD13 after CMD6
 +*/
 +   mdelay(1);
 +
 /* Must check status to be sure of no errors */
 timeout = jiffies + msecs_to_jiffies(MMC_OPS_TIMEOUT_MS);
 do {



 mdelay() is a rather nasty function to call because it hogs the CPU.
 Better use msleep(), which will allow another process to use the
 CPU in the meantime.
 It might be worthwhile to check the manufacturer ID field so we
 don't delay the boot process for non-sandisk devices.

 OK, so I will also move MFID defines from drivers/mmc/core/block.c to
 include/linux/mmc/card.h which will allow the use of these defines
 from mmc_ops.c.

 I am testing right now and if it works, I will send a patch.
 Thanks,
 JM

And that will not work because card-cid.manfid is not yet defined
when __mmc_switch() is called.
The patch works, but now I need to have it SANDISK dependent.

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-04 Thread Arnd Bergmann

On Thursday 04 September 2014 12:06:41 Jean-Michel Hautbois wrote:
 And that will not work because card-cid.manfid is not yet defined
 when __mmc_switch() is called.
 The patch works, but now I need to have it SANDISK dependent.
 

Ok, I see. Then just use msleep() here.

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

Re: sdhci-esdhc-imx : cannot read eMMC

2014-09-04 12:12 GMT+02:00 Arnd Bergmann a...@arndb.de:
 On Thursday 04 September 2014 12:06:41 Jean-Michel Hautbois wrote:
 And that will not work because card-cid.manfid is not yet defined
 when __mmc_switch() is called.
 The patch works, but now I need to have it SANDISK dependent.


 Ok, I see. Then just use msleep() here.

 Arnd

Well, in fact, in dirvers/mmc/core/mmc.c :
card-cid.manfid= UNSTUFF_BITS(resp, 120, 8);

It gets 0x45 on my eMMC  but SANDISK datasheet says 0x02.
And in __mmc_switch, it is set, but to 0x45 which is not tested
correctly against CID_MANFID_SANDISK which is set to 0x2.

So maybe some sandisk have MID at 0x2 and some others have something else ?

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-04 11:37 GMT+02:00 Jean-Michel Hautbois
jean-michel.hautb...@vodalys.com:
 Hi Ulf,

 I am not sure adding a DT binding for non access to rpmb would be
 needed. At least until we heard of a similar case as Adrian describes
 but for rpmb.

 BTW, I just posted a patch which disabled partition scan of the boot
 area, what to you think about that?
 http://marc.info/?l=linux-mmcm=140973496402028w=2

 Finally I am also wondering whether we could and thus should, handle
 these situations entirely without using a host cap. In principle what
 we need is a more sophisticated error handling when the switch errors
 occurs, while trying to switch to the boot area/rpmb partitions. Could
 you maybe investigate that option, before we decide to add a new DT
 binding?

 According to me and what Hsin-Hsiang Tseng wrote, it seems that we
 should be able to have access to boot partitions if we want to give a
 possibility of writing u-boot in one (or both) of them. This is the
 way the i.MX6 will boot on a eMMC if I read the reference manual
 correctly, but I didn't tested it yet.
 But there is no need to scan those partitions at boot, as there will
 probably never be a partition table inside, as you said.
 All we need is providing access to mmc[n]blkpboot0 and mmc[n]blkpboot1
 and a way to tell which one is used as default boot partition.

 This is my point of view, but I didn't read JESD84-A441 so I don't
 know if this is the good way.

 Regards,
 JM

BTW, here is an interesting commit from Freescale tree :
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.17_1.0.0_gaid=28774b788ae0de5d88045dd60cac3656c305821d

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

On 4 September 2014 07:06, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Hi, Stephen.

 On 09/03/2014 10:57 PM, Stephen Boyd wrote:
 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,
  };
 In dw-mmc.c, tuning_block values are same.
 So I think we can move these value into generic header. how about?

Actually, I believe these values comes from the eMMC specification?
Shouldn't they be moved to the mmc core instead?

Kind regards
Uffe


 Best Regards,
 Jaehoon Chung


  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;


 --
 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] tmio_mmc_pio: prevent endless loop in tmio_mmc_set_clock()

On 3 September 2014 21:27, Sergei Shtylyov
sergei.shtyl...@cogentembedded.com wrote:
 Hello.


 On 06/26/2014 11:56 PM, Sergei Shtylyov wrote:

 I've spent a couple of days with the driver just hanging due to me
 forgetting
 to specify the external crystal frequency, so that clk_get_rate()
 returned 0
 and thus the loop in tmio_mmc_set_clock() never ended. I don't think
 that's an
 acceptable behavior, so I suggest that the minimum frequency is checked
 for 0
 in tmio_mmc_host_probe().


 Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com


 ---
 The patch is against Chris Ball's 'mmc.git' repo's 'master' branch.


 I'm still not seeing this patch applied anywhere in this repo...
 what's
 the problem with it?


Chris, Ulf, Ian, what's the issue with this patch? Do you want me to
 rework it?

I guess it has been forgotten, sorry about that.

Please rebase it towards my mmc tree, which is the one we are using
currently and repost it.

Kind regards
Uffe



   drivers/mmc/host/tmio_mmc_pio.c |9 +
   1 file changed, 9 insertions(+)


 Index: mmc/drivers/mmc/host/tmio_mmc_pio.c
 ===
 --- mmc.orig/drivers/mmc/host/tmio_mmc_pio.c
 +++ mmc/drivers/mmc/host/tmio_mmc_pio.c
 @@ -1044,6 +1044,15 @@ int tmio_mmc_host_probe(struct tmio_mmc_
   }

   /*
 + * Check the sanity of mmc-f_min to prevent tmio_mmc_set_clock()
 from
 + * looping forever...
 + */
 +if (mmc-f_min == 0) {
 +ret = -EINVAL;
 +goto pm_disable;
 +}
 +
 +/*
* There are 4 different scenarios for the card detection:
*  1) an external gpio irq handles the cd (best for power savings)
*  2) internal sdhi irq handles the cd


 WBR, Sergei

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

[PATCH v3 6/9] mmc: sdio: Convert to dev_pm_domain_attach|detach()

Previously only the ACPI PM domain was supported by the sdio bus.

Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.

Cc: linux-mmc@vger.kernel.org
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
 drivers/mmc/core/sdio_bus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
index 4fa8fef9..1df0fc6 100644
--- a/drivers/mmc/core/sdio_bus.c
+++ b/drivers/mmc/core/sdio_bus.c
@@ -315,7 +315,7 @@ int sdio_add_func(struct sdio_func *func)
ret = device_add(func-dev);
if (ret == 0) {
sdio_func_set_present(func);
-   acpi_dev_pm_attach(func-dev, false);
+   dev_pm_domain_attach(func-dev, false);
}
 
return ret;
@@ -332,7 +332,7 @@ void sdio_remove_func(struct sdio_func *func)
if (!sdio_func_present(func))
return;
 
-   acpi_dev_pm_detach(func-dev, false);
+   dev_pm_domain_detach(func-dev, false);
device_del(func-dev);
put_device(func-dev);
 }
-- 
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

Boot from eMMC and removing SDcard after boot results in Warning

Hi,

I have now a kernel which boots from eMMC card on mmc1 and mounts
partitions from mmc0 which is a SDcard. When I remove the SDcard, I
get the following warning :

[  109.182663] mmc0: card 0002 removed
[  109.448516] [ cut here ]
[  109.453205] WARNING: CPU: 1 PID: 855 at fs/fs-writeback.c:1200
__mark_inode_dirty+0x1bc/0x1d0()
[  109.461956] bdi-block not registered
[  109.465564] Modules linked in: snd_soc_sgtl5000 snd_soc_imx_sgtl5000
[  109.472017] CPU: 1 PID: 855 Comm: umount Tainted: GW
3.17.0-rc2+yocto+g49cd5a7d #40
[  109.480860] Backtrace:
[  109.483373] [80012ff0] (dump_backtrace) from [800132d4]
(show_stack+0x18/0x1c)
[  109.490988]  r6:80aa5ef4 r5:80aa5ef4 r4: r3:
[  109.496774] [800132bc] (show_stack) from [806db4ec]
(dump_stack+0x8c/0xa4)
[  109.504026] [806db460] (dump_stack) from [8002b8b8]
(warn_slowpath_common+0x70/0x94)
[  109.512145]  r6:801135d0 r5:0009 r4:bd043de8 r3:bd066b40
[  109.517915] [8002b848] (warn_slowpath_common) from [8002b914]
(warn_slowpath_fmt+0x38/0x40)
[  109.526640]  r8: r7:a00b0013 r6:bd898970 r5:bdc53b70 r4:bd898768
[  109.533460] [8002b8e0] (warn_slowpath_fmt) from [801135d0]
(__mark_inode_dirty+0x1bc/0x1d0)
[  109.542189]  r3:8095be98 r2:80951c5c
[  109.545840] [80113414] (__mark_inode_dirty) from [80119d1c]
(__set_page_dirty+0x90/0xc8)
[  109.554316]  r7:a00b0013 r6:bdc53cac r5:bdc53c9c r4:bef816e0
[  109.560095] [80119c8c] (__set_page_dirty) from [8011ad84]
(mark_buffer_dirty+0x84/0xbc)
[  109.568470]  r8:bc51d800 r7:80a82380 r6:bc51d800 r5:
r4:bef816e0 r3:bdc53c9c
[  109.576328] [8011ad00] (mark_buffer_dirty) from [801633b4]
(ext3_put_super+0x1fc/0x23c)
[  109.584699]  r5:bdabcc00 r4:bc8b7400
[  109.588328] [801631b8] (ext3_put_super) from [800ee73c]
(generic_shutdown_super+0x78/0xe0)
[  109.596958]  r7:80a82380 r6:806ed0a8 r5:bc51d890 r4:bc51d800
[  109.602694] [800ee6c4] (generic_shutdown_super) from [800eea50]
(kill_block_super+0x20/0x74)
[  109.611497]  r6:8010c5fc r5:0083 r4:bdc53a80 r3:800eea30
[  109.617248] [800eea30] (kill_block_super) from [800eee68]
(deactivate_locked_super+0x68/0x7c)
[  109.626138]  r6:8010c5fc r5:80aa0228 r4:bc51d800 r3:800eea30
[  109.631877] [800eee00] (deactivate_locked_super) from
[800efaec] (deactivate_super+0x68/0x6c)
[  109.640766]  r5:0001 r4:bc51d800
[  109.644399] [800efa84] (deactivate_super) from [8010aff0]
(mntput_no_expire+0x18c/0x27c)
[  109.652841]  r5:0001 r4:bd388780
[  109.656476] [8010ae64] (mntput_no_expire) from [8010c5fc]
(SyS_umount+0xa0/0x4a8)
[  109.664326]  r7:8000f680 r6:bd388780 r5: r4:bd3887a8
[  109.670068] [8010c55c] (SyS_umount) from [8000f680]
(ret_fast_syscall+0x0/0x48)
[  109.677747]  r10: r9:bd042000 r8:8000f844 r7:0034
r6:00cec7e0 r5:76f3e8c8
[  109.685684]  r4:00ceb038
[  109.688239] ---[ end trace 2709c6b2b9cdead5 ]---
[  109.693718] EXT3-fs (mmcblk0p2): I/O error while writing superblock

I am having a look into it, but if anyone already solved this ;-).
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: dw_mmc: Don't enable interrupts until we're ready

2014-09-04 Thread Doug Anderson

Jaehoon,

On Wed, Sep 3, 2014 at 10:21 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Hi Doug

 On 09/03/2014 08:37 AM, Doug Anderson wrote:
 On dw_mmc there's a small race if you happen to get a card detect
 interrupt at just the wrong time during probe.  You may have enabled
 the interrupt but host-slot[0] may be NULL.

 Fix the race by enabling interrupts all the way at the end of the
 probe.  We can also use free_irq() instead of dw_mmc specific masking
 to mask the IRQ at removal time.  Note that since we're now managing
 freeing of the irq ourselves, there's no need to use devm.

 FYI, the crash would look like:
   dwmmc_rockchip ff0c.dwmmc: DW MMC controller at irq 64, 32 bit host 
 data width, 256 deep fifo
   Unable to handle kernel NULL pointer dereference at virtual address 
 
   pgd = c0004000
   [] *pgd=
   ...
   ...
   [c0499380] (dw_mci_work_routine_card) from [c0134b94] 
 (process_one_work+0x260/0x3c4)
   [c0134b94] (process_one_work) from [c0135b10] 
 (worker_thread+0x240/0x3a8)
   [c0135b10] (worker_thread) from [c013b64c] (kthread+0x100/0x118)
   [c013b64c] (kthread) from [c0106418] (ret_from_fork+0x14/0x20)

 Signed-off-by: Doug Anderson diand...@chromium.org
 ---
 FYI: making dw_mmc into a module and trying module removal was not
 tested.  I'd appreciate any testing that folks can do there.  This
 code should be the equivalent and makes the error case of probe match
 the removal case more closely now.

  drivers/mmc/host/dw_mmc.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 7f227e9..540ba3c 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -2577,10 +2577,6 @@ int dw_mci_probe(struct dw_mci *host)
   goto err_dmaunmap;
   }
   INIT_WORK(host-card_work, dw_mci_work_routine_card);
 - ret = devm_request_irq(host-dev, host-irq, dw_mci_interrupt,
 -host-irq_flags, dw-mci, host);
 - if (ret)
 - goto err_workqueue;

   if (host-pdata-num_slots)
   host-num_slots = host-pdata-num_slots;
 @@ -2619,11 +2615,21 @@ int dw_mci_probe(struct dw_mci *host)
   goto err_workqueue;
   }

 + ret = request_irq(host-irq, dw_mci_interrupt, host-irq_flags,
 +   dw-mci, host);
 + if (ret)
 + goto err_initted;

 I didn't test and consider race condition yet.
 But if located request_irq at here, we can be confused something,
 since there is dev_info(host-dev, %d slots initialized\n, init_slots) 
 message at above.

 I think you can relocate this.

OK, good point.  Maybe we should skip this patch after all.  There is
definitely a race there, but I'm not 100% sure this is the right fix
for it.

In general we probably need to look at the dw_mci_work_routine_card()
a bit more (used for card detect) since that's only used for official
CD lines.  ...and as we've talked about anyone who wants to properly
power their card off should be using GPIOs, thus they won't get the
benefit of whatever dw_mci_work_routine_card() does.

I did play around a little bit with trying to test the module remove.
Both before and after my patch it hung.

-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

Re: [PATCH] mmc: sdhci-msm: Make tuning block table endian agnostic

2014-09-04 Thread Stephen Boyd

On 09/04/14 03:53, Ulf Hansson wrote:
 On 4 September 2014 07:06, Jaehoon Chung jh80.ch...@samsung.com wrote:

 In dw-mmc.c, tuning_block values are same.
 So I think we can move these value into generic header. how about?
 Actually, I believe these values comes from the eMMC specification?
 Shouldn't they be moved to the mmc core instead?

That sounds like good consolidation, but can we do that in a follow-up
patch? This fixes the driver for me and I was hoping to make something
minimal to go back to stable trees.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

Re: [PATCH] tmio_mmc_pio: prevent endless loop in tmio_mmc_set_clock()

2014-09-04 Thread Sergei Shtylyov


Hello.

On 09/04/2014 03:00 PM, Ulf Hansson wrote:


I've spent a couple of days with the driver just hanging due to me
forgetting
to specify the external crystal frequency, so that clk_get_rate()
returned 0
and thus the loop in tmio_mmc_set_clock() never ended. I don't think
that's an
acceptable behavior, so I suggest that the minimum frequency is checked
for 0
in tmio_mmc_host_probe().



Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com



---
The patch is against Chris Ball's 'mmc.git' repo's 'master' branch.



 I'm still not seeing this patch applied anywhere in this repo...
what's
the problem with it?



Chris, Ulf, Ian, what's the issue with this patch? Do you want me to
rework it?



I guess it has been forgotten, sorry about that.



Please rebase it towards my mmc tree, which is the one we are using
currently and repost it.


   It should still apply flawlessly to your tree, want me to repost it anyway?


Kind regards
Uffe


WBR, Sergei

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

Re: [PATCH] mmc: dw_mmc: Don't enable interrupts until we're ready

Doug,

On 09/05/2014 04:21 AM, Doug Anderson wrote:
 Jaehoon,
 
 On Wed, Sep 3, 2014 at 10:21 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Hi Doug

 On 09/03/2014 08:37 AM, Doug Anderson wrote:
 On dw_mmc there's a small race if you happen to get a card detect
 interrupt at just the wrong time during probe.  You may have enabled
 the interrupt but host-slot[0] may be NULL.

 Fix the race by enabling interrupts all the way at the end of the
 probe.  We can also use free_irq() instead of dw_mmc specific masking
 to mask the IRQ at removal time.  Note that since we're now managing
 freeing of the irq ourselves, there's no need to use devm.

 FYI, the crash would look like:
   dwmmc_rockchip ff0c.dwmmc: DW MMC controller at irq 64, 32 bit host 
 data width, 256 deep fifo
   Unable to handle kernel NULL pointer dereference at virtual address 
 
   pgd = c0004000
   [] *pgd=
   ...
   ...
   [c0499380] (dw_mci_work_routine_card) from [c0134b94] 
 (process_one_work+0x260/0x3c4)
   [c0134b94] (process_one_work) from [c0135b10] 
 (worker_thread+0x240/0x3a8)
   [c0135b10] (worker_thread) from [c013b64c] (kthread+0x100/0x118)
   [c013b64c] (kthread) from [c0106418] (ret_from_fork+0x14/0x20)

 Signed-off-by: Doug Anderson diand...@chromium.org
 ---
 FYI: making dw_mmc into a module and trying module removal was not
 tested.  I'd appreciate any testing that folks can do there.  This
 code should be the equivalent and makes the error case of probe match
 the removal case more closely now.

  drivers/mmc/host/dw_mmc.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 7f227e9..540ba3c 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -2577,10 +2577,6 @@ int dw_mci_probe(struct dw_mci *host)
   goto err_dmaunmap;
   }
   INIT_WORK(host-card_work, dw_mci_work_routine_card);
 - ret = devm_request_irq(host-dev, host-irq, dw_mci_interrupt,
 -host-irq_flags, dw-mci, host);
 - if (ret)
 - goto err_workqueue;

   if (host-pdata-num_slots)
   host-num_slots = host-pdata-num_slots;
 @@ -2619,11 +2615,21 @@ int dw_mci_probe(struct dw_mci *host)
   goto err_workqueue;
   }

 + ret = request_irq(host-irq, dw_mci_interrupt, host-irq_flags,
 +   dw-mci, host);
 + if (ret)
 + goto err_initted;

 I didn't test and consider race condition yet.
 But if located request_irq at here, we can be confused something,
 since there is dev_info(host-dev, %d slots initialized\n, init_slots) 
 message at above.

 I think you can relocate this.
 
 OK, good point.  Maybe we should skip this patch after all.  There is
 definitely a race there, but I'm not 100% sure this is the right fix
 for it.

I'm not sure this patch is fixed for it, too.
So i will check more with your patch.
But i think if we can maintain current status, it will be the best.

Best Regards,
Jaehoon Chung

 
 In general we probably need to look at the dw_mci_work_routine_card()
 a bit more (used for card detect) since that's only used for official
 CD lines.  ...and as we've talked about anyone who wants to properly
 power their card off should be using GPIOs, thus they won't get the
 benefit of whatever dw_mci_work_routine_card() does.
 
 I did play around a little bit with trying to test the module remove.
 Both before and after my patch it hung.
 
 -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

Re: [PATCH] mmc: sdhci-msm: Make tuning block table endian agnostic

On 09/05/2014 06:22 AM, Stephen Boyd wrote:
 On 09/04/14 03:53, Ulf Hansson wrote:
 On 4 September 2014 07:06, Jaehoon Chung jh80.ch...@samsung.com wrote:

 In dw-mmc.c, tuning_block values are same.
 So I think we can move these value into generic header. how about?
 Actually, I believe these values comes from the eMMC specification?
 Shouldn't they be moved to the mmc core instead?
 
 That sounds like good consolidation, but can we do that in a follow-up
 patch? This fixes the driver for me and I was hoping to make something
 minimal to go back to stable trees.

Sure, if my opinion is ok, i will do it after apply your patches.

Best Regards,
Jaehoon Chung

 

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

2014-09-04 Thread Stephen Boyd

On 09/05, Jaehoon Chung wrote:
 On 09/05/2014 06:22 AM, Stephen Boyd wrote:
  On 09/04/14 03:53, Ulf Hansson wrote:
  On 4 September 2014 07:06, Jaehoon Chung jh80.ch...@samsung.com wrote:
 
  In dw-mmc.c, tuning_block values are same.
  So I think we can move these value into generic header. how about?
  Actually, I believe these values comes from the eMMC specification?
  Shouldn't they be moved to the mmc core instead?
  
  That sounds like good consolidation, but can we do that in a follow-up
  patch? This fixes the driver for me and I was hoping to make something
  minimal to go back to stable trees.
 
 Sure, if my opinion is ok, i will do it after apply your patches.
 

Here's the patch

8
From: Stephen Boyd sb...@codeaurora.org
Subject: [PATCH] mmc: Consolidate emmc tuning blocks

The same tuning block array exists in the dw_mmc h.c and sdhci-msm.c
files. Move these into mmc.c so that they can be shared across
drivers.

Reported-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
 drivers/mmc/core/mmc.c   | 32 
 drivers/mmc/host/dw_mmc.c| 30 --
 drivers/mmc/host/sdhci-msm.c | 38 --
 include/linux/mmc/mmc.h  |  5 +
 4 files changed, 41 insertions(+), 64 deletions(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 793c6f7ddb04..9608cc8a1f65 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1135,6 +1135,38 @@ bus_speed:
return err;
 }
 
+const u8 tuning_blk_pattern_4bit[MMC_TUNING_BLK_PATTERN_4BIT_SIZE] = {
+   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,
+};
+EXPORT_SYMBOL(tuning_blk_pattern_4bit);
+
+const u8 tuning_blk_pattern_8bit[MMC_TUNING_BLK_PATTERN_8BIT_SIZE] = {
+   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,
+};
+EXPORT_SYMBOL(tuning_blk_pattern_8bit);
+
 /*
  * Execute tuning sequence to seek the proper bus operating
  * conditions for HS200 and HS400, which sends CMD21 to the device.
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c603b7..f1cefdf5e2d0 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -81,36 +81,6 @@ struct idmac_desc {
 };
 #endif /* CONFIG_MMC_DW_IDMAC */
 
-static const u8 tuning_blk_pattern_4bit[] = {
-   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 u8 tuning_blk_pattern_8bit[] = {
-   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,
-};
-
 static

[PATCH 0/4] mmc: dw_mmc: cleanup codes

This patch-set fixed the wrong variable type and remove the unused codes.

Jaehoon Chung (4):
  mmc: dw_mmc: modify the variable type
  mmc: dw_mmc: remove the blk-settings structure
  mmc: dw_mmc: remove the unused quirk.
  mmc: dw_mmc: fixed wrong condtion checking.

 drivers/mmc/host/dw_mmc-exynos.c |5 ++---
 drivers/mmc/host/dw_mmc.c|   15 ---
 drivers/mmc/host/dw_mmc.h|4 ++--
 include/linux/mmc/dw_mmc.h   |   15 ++-
 4 files changed, 10 insertions(+), 29 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

[PATCH 3/4] mmc: dw_mmc: remove the unused quirk.

DW_MCI_QUIRK_HIGHSPEED don't use.
If we need to set the highspeed mode by force, we can use to set
cap-mms/sd-highspeed into dt-file.

Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
 include/linux/mmc/dw_mmc.h |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 6dcc1c1..2796d9c 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -211,12 +211,10 @@ struct dw_mci_dma_ops {
 #define DW_MCI_QUIRK_IDMAC_DTO BIT(0)
 /* delay needed between retries on some 2.11a implementations */
 #define DW_MCI_QUIRK_RETRY_DELAY   BIT(1)
-/* High Speed Capable - Supports HS cards (up to 50MHz) */
-#define DW_MCI_QUIRK_HIGHSPEED BIT(2)
 /* Unreliable card detection */
-#define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(3)
+#define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(2)
 /* No write protect */
-#define DW_MCI_QUIRK_NO_WRITE_PROTECT  BIT(4)
+#define DW_MCI_QUIRK_NO_WRITE_PROTECT  BIT(3)
 
 /* Slot level quirks */
 /* This slot has no write protect */
-- 
1.7.9.5

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

[PATCH 2/4] mmc: dw_mmc: remove the blk-settings structure

It don't use anywhere. So it's meaningless.

Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
 drivers/mmc/host/dw_mmc.c  |   13 +++--
 include/linux/mmc/dw_mmc.h |9 -
 2 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b8e0ca8..0d31a8c 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2287,27 +2287,20 @@ static int dw_mci_init_slot(struct dw_mci *host, 
unsigned int id)
if (ret)
goto err_host_allocated;
 
-   if (host-pdata-blk_settings) {
-   mmc-max_segs = host-pdata-blk_settings-max_segs;
-   mmc-max_blk_size = host-pdata-blk_settings-max_blk_size;
-   mmc-max_blk_count = host-pdata-blk_settings-max_blk_count;
-   mmc-max_req_size = host-pdata-blk_settings-max_req_size;
-   mmc-max_seg_size = host-pdata-blk_settings-max_seg_size;
-   } else {
+
+   if (IS_ENABLED(CONFIG_MMC_DW_IDMAC)) {
/* Useful defaults if platform data is unset. */
-#ifdef CONFIG_MMC_DW_IDMAC
mmc-max_segs = host-ring_size;
mmc-max_blk_size = 65536;
mmc-max_blk_count = host-ring_size;
mmc-max_seg_size = 0x1000;
mmc-max_req_size = mmc-max_seg_size * mmc-max_blk_count;
-#else
+   } else {
mmc-max_segs = 64;
mmc-max_blk_size = 65536; /* BLKSIZ is 16 bits */
mmc-max_blk_count = 512;
mmc-max_req_size = mmc-max_blk_size * mmc-max_blk_count;
mmc-max_seg_size = mmc-max_req_size;
-#endif /* CONFIG_MMC_DW_IDMAC */
}
 
if (dw_mci_get_cd(mmc))
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 0013669..6dcc1c1 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -224,14 +224,6 @@ struct dw_mci_dma_ops {
 
 struct dma_pdata;
 
-struct block_settings {
-   unsigned short  max_segs;   /* see blk_queue_max_segments */
-   unsigned intmax_blk_size;   /* maximum size of one mmc block */
-   unsigned intmax_blk_count;  /* maximum number of blocks in one req*/
-   unsigned intmax_req_size;   /* maximum number of bytes in one req*/
-   unsigned intmax_seg_size;   /* see blk_queue_max_segment_size */
-};
-
 /* Board platform data */
 struct dw_mci_board {
u32 num_slots;
@@ -254,7 +246,6 @@ struct dw_mci_board {
 
struct dw_mci_dma_ops *dma_ops;
struct dma_pdata *data;
-   struct block_settings *blk_settings;
 };
 
 #endif /* LINUX_MMC_DW_MMC_H */
-- 
1.7.9.5

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

[PATCH 4/4] mmc: dw_mmc: fixed wrong condtion checking.

DDR mode can use  with 4bit or 8bit buswidth.

Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
 drivers/mmc/host/dw_mmc-exynos.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index aee39bc..0884df6 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -190,8 +190,7 @@ static void dw_mci_exynos_set_ios(struct dw_mci *host, 
struct mmc_ios *ios)
if (ios-timing == MMC_TIMING_MMC_DDR52) {
mci_writel(host, CLKSEL, priv-ddr_timing);
/* Should be double rate for DDR mode */
-   if (ios-bus_width == MMC_BUS_WIDTH_8)
-   wanted = 1;
+   wanted = 1;
} else {
mci_writel(host, CLKSEL, priv-sdr_timing);
}
-- 
1.7.9.5

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

[PATCH 1/4] mmc: dw_mmc: modify the variable type