Hi Ulf,
On Mon, Dec 8, 2014 at 3:40 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> On 6 December 2014 at 13:43, Alim Akhtar <alim.akhtar@xxxxxxxxx> wrote:
>> Hi Ulf,
>>
>> On Fri, Dec 5, 2014 at 5:29 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>>> Instead of having a local hack taking care of sending the tuning
>>> command and as well to verify the response pattern, let's convert to
>>> the common mmc_send_tuning() API.
>>>
>>> This change affects the Exynos variant, since it's the only one which
>>> support the dw_mmc's ->execute_tuning() callback.
>>>
>>> Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
>>> ---
>>>
>
> Alim, thanks for helping out testing!
>
>> With this change HS200 mode does not work on exynos5800 peach-pi board.
>> I got below error while testing this series:
>>
>> mmc0: tuning execution failed
>> mmc0: error -5 whilst initialising MMC card
>>
>> Though, your's next branch with commit _a1d06b4_ works fine in HS200 mode.
>
> I was looking into the details of what change my patchset introduces
> for dw_mmc-exynos. Apparently, dw_mmc-exynos was using the
> MMC_STOP_TRANSMISSION to end the tuning reqeust (CMD21/19). The new
> mmc_send_tuning() API doesn't, which also conforms to what the eMMC/SD
> specifications states.
>
> Do you have any idea of why dw_mmc-exynos was using
> MMC_STOP_TRANSMISSION for CMD19/21?
>
> To see if my theory is correct, could you try out the following patch
> on top of $subject patch?
> BTW, I have queued patch 1 and 2, from this patchset available on my
> next branch.
>
>
> From e1ac35bb0e90254275ec7088f41e6e2d59e48367 Mon Sep 17 00:00:00 2001
> From: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
> Date: Mon, 8 Dec 2014 10:58:48 +0100
> Subject: [PATCH] mmc: core: End tuning request with stop command
>
> Not to be merged!
>
> This patch adds the MMC_STOP_TRANSMISSION command to end a tuning
> request. For some reason dw_mmc seems to need this to complete the
> tuning request without errors.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
> ---
> drivers/mmc/core/mmc_ops.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index 3b044c5..aa79e0c 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -551,6 +551,7 @@ int mmc_send_tuning(struct mmc_host *host)
> {
> struct mmc_request mrq = {NULL};
> struct mmc_command cmd = {0};
> + struct mmc_command stop = {0};
> struct mmc_data data = {0};
> struct scatterlist sg;
> struct mmc_ios *ios = &host->ios;
> @@ -576,10 +577,14 @@ int mmc_send_tuning(struct mmc_host *host)
>
> mrq.cmd = &cmd;
> mrq.data = &data;
> + mrq.stop = &stop;
>
> cmd.opcode = opcode;
> cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
>
> + stop.opcode = MMC_STOP_TRANSMISSION;
> + stop.flags = MMC_RSP_R1B | MMC_CMD_AC;
> +
> data.blksz = size;
> data.blocks = 1;
> data.flags = MMC_DATA_READ;
> --
> 1.9.1
>
Sorry for delay in testing this suggested patch, I would say this
certainly helps, but still I need to change sample phase to make it
work with generic tuning function.
So with your's adding STOP_TRANSMISSION command and below change,
HS200 works well on exynos5800
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index e8fdda8..e0f0337 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -555,7 +555,7 @@
card-detect-delay = <200>;
clock-frequency = <400000000>;
samsung,dw-mshc-ciu-div = <3>;
- samsung,dw-mshc-sdr-timing = <0 4>;
+ samsung,dw-mshc-sdr-timing = <2 4>;
This basically change the clock-sample phase with which the tuning
process starts.
I didn't find anything is exynos documentations which suggest
STOP_TRANSMISSION is needed, may be Seungwon might be know as he wrote
this.
Are you ok to add STOP_TRANSMISSION in generic tuning code (probably
with a quirk, so that other hosts are still happy)?
If so, I can send the above DT change as a fix.
> Kind regards
> Uffe
--
Regards,
Alim
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
