RE: eMMC boot problem: switch to bus width 8 ddr failed

[Bough Chen]

> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Friday, January 13, 2017 7:23 PM
> To: Bough Chen <haibo.c...@nxp.com>
> Cc: Shawn Lin <shawn@rock-chips.com>; Clemens Gruber
> <clemens.gru...@pqgruber.com>; linux-...@vger.kernel.org; Linus Walleij
> <linus.wall...@linaro.org>; Adrian Hunter <adrian.hun...@intel.com>; A.S.
> Dong <aisheng.d...@nxp.com>; linux-kernel@vger.kernel.org; Gary Bisson
> <gary.bis...@boundarydevices.com>; Fabio Estevam <feste...@gmail.com>;
> Shawn Guo <shawn...@kernel.org>
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> [...]
> 
> > Hi Ulf and Shawn,
> >
> > Aisheng and I debug this issue these days, and we find the root cause.
> > There are two things to describe.
> >
> > 1) voltage switch issue.  The properity "no-1-8-v" do not work for
> MMC_TIMING_MMC_DDR52.
> > This is another bug, we need to fix, but has no relation with the current 
> > bug.
> 
> I am working on a patch which invents MMC_CAP_3_3V_DDR and which has a
> corresponding DT binding "mmc-ddr-3_3v".
> Give me a day or so, then I will post it.
> 
> Likely it should help to resolve your issue, don't you think?

Seems Yes, I will test the patch when you post.

Best Regards,
Haibo Chen

> 
> [...]
> 
> Kind regards
> Uffe

RE: eMMC boot problem: switch to bus width 8 ddr failed

[Bough Chen]

> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Friday, January 13, 2017 7:23 PM
> To: Bough Chen 
> Cc: Shawn Lin ; Clemens Gruber
> ; linux-...@vger.kernel.org; Linus Walleij
> ; Adrian Hunter ; A.S.
> Dong ; linux-kernel@vger.kernel.org; Gary Bisson
> ; Fabio Estevam ;
> Shawn Guo 
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> [...]
> 
> > Hi Ulf and Shawn,
> >
> > Aisheng and I debug this issue these days, and we find the root cause.
> > There are two things to describe.
> >
> > 1) voltage switch issue.  The properity "no-1-8-v" do not work for
> MMC_TIMING_MMC_DDR52.
> > This is another bug, we need to fix, but has no relation with the current 
> > bug.
> 
> I am working on a patch which invents MMC_CAP_3_3V_DDR and which has a
> corresponding DT binding "mmc-ddr-3_3v".
> Give me a day or so, then I will post it.
> 
> Likely it should help to resolve your issue, don't you think?

Seems Yes, I will test the patch when you post.

Best Regards,
Haibo Chen

> 
> [...]
> 
> Kind regards
> Uffe

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Ulf Hansson]

[...]

> Hi Ulf and Shawn,
>
> Aisheng and I debug this issue these days, and we find the root cause. There 
> are two things
> to describe.
>
> 1) voltage switch issue.  The properity "no-1-8-v" do not work for  
> MMC_TIMING_MMC_DDR52.
> This is another bug, we need to fix, but has no relation with the current bug.

I am working on a patch which invents MMC_CAP_3_3V_DDR and which has a
corresponding DT binding "mmc-ddr-3_3v".
Give me a day or so, then I will post it.

Likely it should help to resolve your issue, don't you think?

[...]

Kind regards
Uffe

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Ulf Hansson]

[...]

> Hi Ulf and Shawn,
>
> Aisheng and I debug this issue these days, and we find the root cause. There 
> are two things
> to describe.
>
> 1) voltage switch issue.  The properity "no-1-8-v" do not work for  
> MMC_TIMING_MMC_DDR52.
> This is another bug, we need to fix, but has no relation with the current bug.

I am working on a patch which invents MMC_CAP_3_3V_DDR and which has a
corresponding DT binding "mmc-ddr-3_3v".
Give me a day or so, then I will post it.

Likely it should help to resolve your issue, don't you think?

[...]

Kind regards
Uffe

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Ulf Hansson]

[...]

>>> >
>>> > In the meantime, I will follow the process of Haibo Chen's debugging
>>> > around the voltage switch issue and look into what Dong's suggesting
>>> > around this may be.
>>> >
>>> > Just to be clear, I would definitely prefer a fix in the sdhci driver,
>>>
>>> yup, I prefer to fix the sdhci* either, and given that it's juct -rc3 now, 
>>> we should
>>> still have some days for Haibo & Dong to help debug it.
>>> Once the fix is settled, we could drop the core fix from -next branch.

Seems like a fix in the sdhci driver isn't going to work. Well, we
could invent a specific mmc host cap, that tells the core to behave
differently - but at this moment I rather not.

>>>
>>
>> Hi Ulf and Shawn,
>>
>> Aisheng and I debug this issue these days, and we find the root cause. There 
>> are two things
>> to describe.
>>
>> 1) voltage switch issue.  The properity "no-1-8-v" do not work for  
>> MMC_TIMING_MMC_DDR52.
>> This is another bug, we need to fix, but has no relation with the current 
>> bug.
>>
>> 2) root cause, in __mmc_switch, the process is   send CMD6 --> set DDR52 
>> timing --> polling for busy.
>> For the DDR52 timing setting, we call set_ios(), in the set_ios, we first 
>> set DDR_EN to config sdhc in ddr mode,
>> and then config the sd clock again.   Here it is, after CMD6 complete, we 
>> find data0 still low, which means card
>> busy. At this time, if we set DDR_EN, there is a risk. For i.MX usdhc, 
>> DDR_EN setting becomes active only when
>> the DATA and CMD line are idle. So, at this time for HW, DDR_EN do not 
>> active, but software think DDR_EN already
>> active, and set the clock again to 49.5MHz, but actually the HW out put the 
>> clock as 198MHz. So there is clock glitch.
>> This is the root cause--set DDR_EN when card is still busy.
>>
>> The following method can fix this issue
>> a) change the HW behavior, DDR_EN setting becomes active at once no matter 
>> what the state of the DATA and
>> CMD line are.   This can fix this issue, but our IC guys do not prefer this, 
>> this method still not safe enough.
>>
>> b) add 1ms delay before DDR_EN to wait bus idle.  But we still not know 
>> whether the time 1ms is appropriate. Better
>> to poll for busy before set DDR_EN.
>>
>> c) set DDR52 timing after CMD6 and pull for busy. This is what Shawn's patch 
>> do.
>>
>> Hi Aisheng,
>> Correct me if anything wrong.
>>
>> My suggestion is that,  in __mmc_switch(), move the mmc_set_timing() after 
>> the function mmc_poll_for_busy().
>>

Yes. Agree!

>>
>
> Haibo, thx for the summary.
>
> I would try to simply things a bit based on Haibo's description!
>
> To be simple, i'd only talking IMX case of the issue that host without
> MMC_CAP_WAIT_WHILE_BUSY.
>
> The current process of mmc_select_hs_ddr handling is:
> Set card DDR52 timing (CMD6)->
> Set host DDR52 timing ->  (IMX issue happens at this step)
> Polling switch done by card_busy()->
> CMD13 to re-check
>
> What the issue here is that IMX can't allow to change host timing(DDREN bit)
> when card is still busy on the switch process (CMD6).
> It's unsafe and may cause host unwork.
>
> Currently host timing change set_ios(TIMING_DDR52) will gate off host clock,
> change timing, re-enable clock.
>
> Two issue in this process:
> 1) In theory we seem should not gate off clock due to card reply on this lock
> to release the bus busy line.
> (Actually IMX HW can't support gate off clock when data line busy)
>
> 2) Can't guarantee host timing changes won't cause any issue when card is
> still busy.
>
> It looks to me according to spec, we probably should't change host timing
> before the card timing change done.
> Because normally with a good host supporting R1B CMD well,
> CMD6 won't finish before the card timing switch done.
>
> Then the correct process would simply be:
> Set card DDR52 timing (CMD6) ->
> CMD6 completed and busy done ->
> Set host DDR52 timing ->
> CMD13 to re-check
>
> We added a lot tricks to support host without MMC_CAP_WAIT_WHILE_BUSY,
> e.g. via ops->card_busy().
>
> If we want to follow above standard process to do the timing change .
> We could do as:
> Set card DDR52 timing (CMD6) ->
> card_busy() done ->
> Set host DDR52 timing ->
> CMD13 to re-check
>
> Below is the draft patch for above approach and simply test works.
>

Haibo, Dong,

I really appreciate the level of details in the information and thanks
for helping out!

>
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index b11c345..3368b1a 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -451,7 +451,8 @@ int mmc_switch_status(struct mmc_card *card)
>  }
>
>  static int mmc_poll_for_busy(struct mmc_card *card, unsigned int timeout_ms,
> -   bool send_status, bool retry_crc_err)
> +   bool send_status, bool retry_crc_err,
> +   unsigned char timing)
>  {
> struct mmc_host *host = card->host;
> int err;
> 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Ulf Hansson]

[...]

>>> >
>>> > In the meantime, I will follow the process of Haibo Chen's debugging
>>> > around the voltage switch issue and look into what Dong's suggesting
>>> > around this may be.
>>> >
>>> > Just to be clear, I would definitely prefer a fix in the sdhci driver,
>>>
>>> yup, I prefer to fix the sdhci* either, and given that it's juct -rc3 now, 
>>> we should
>>> still have some days for Haibo & Dong to help debug it.
>>> Once the fix is settled, we could drop the core fix from -next branch.

Seems like a fix in the sdhci driver isn't going to work. Well, we
could invent a specific mmc host cap, that tells the core to behave
differently - but at this moment I rather not.

>>>
>>
>> Hi Ulf and Shawn,
>>
>> Aisheng and I debug this issue these days, and we find the root cause. There 
>> are two things
>> to describe.
>>
>> 1) voltage switch issue.  The properity "no-1-8-v" do not work for  
>> MMC_TIMING_MMC_DDR52.
>> This is another bug, we need to fix, but has no relation with the current 
>> bug.
>>
>> 2) root cause, in __mmc_switch, the process is   send CMD6 --> set DDR52 
>> timing --> polling for busy.
>> For the DDR52 timing setting, we call set_ios(), in the set_ios, we first 
>> set DDR_EN to config sdhc in ddr mode,
>> and then config the sd clock again.   Here it is, after CMD6 complete, we 
>> find data0 still low, which means card
>> busy. At this time, if we set DDR_EN, there is a risk. For i.MX usdhc, 
>> DDR_EN setting becomes active only when
>> the DATA and CMD line are idle. So, at this time for HW, DDR_EN do not 
>> active, but software think DDR_EN already
>> active, and set the clock again to 49.5MHz, but actually the HW out put the 
>> clock as 198MHz. So there is clock glitch.
>> This is the root cause--set DDR_EN when card is still busy.
>>
>> The following method can fix this issue
>> a) change the HW behavior, DDR_EN setting becomes active at once no matter 
>> what the state of the DATA and
>> CMD line are.   This can fix this issue, but our IC guys do not prefer this, 
>> this method still not safe enough.
>>
>> b) add 1ms delay before DDR_EN to wait bus idle.  But we still not know 
>> whether the time 1ms is appropriate. Better
>> to poll for busy before set DDR_EN.
>>
>> c) set DDR52 timing after CMD6 and pull for busy. This is what Shawn's patch 
>> do.
>>
>> Hi Aisheng,
>> Correct me if anything wrong.
>>
>> My suggestion is that,  in __mmc_switch(), move the mmc_set_timing() after 
>> the function mmc_poll_for_busy().
>>

Yes. Agree!

>>
>
> Haibo, thx for the summary.
>
> I would try to simply things a bit based on Haibo's description!
>
> To be simple, i'd only talking IMX case of the issue that host without
> MMC_CAP_WAIT_WHILE_BUSY.
>
> The current process of mmc_select_hs_ddr handling is:
> Set card DDR52 timing (CMD6)->
> Set host DDR52 timing ->  (IMX issue happens at this step)
> Polling switch done by card_busy()->
> CMD13 to re-check
>
> What the issue here is that IMX can't allow to change host timing(DDREN bit)
> when card is still busy on the switch process (CMD6).
> It's unsafe and may cause host unwork.
>
> Currently host timing change set_ios(TIMING_DDR52) will gate off host clock,
> change timing, re-enable clock.
>
> Two issue in this process:
> 1) In theory we seem should not gate off clock due to card reply on this lock
> to release the bus busy line.
> (Actually IMX HW can't support gate off clock when data line busy)
>
> 2) Can't guarantee host timing changes won't cause any issue when card is
> still busy.
>
> It looks to me according to spec, we probably should't change host timing
> before the card timing change done.
> Because normally with a good host supporting R1B CMD well,
> CMD6 won't finish before the card timing switch done.
>
> Then the correct process would simply be:
> Set card DDR52 timing (CMD6) ->
> CMD6 completed and busy done ->
> Set host DDR52 timing ->
> CMD13 to re-check
>
> We added a lot tricks to support host without MMC_CAP_WAIT_WHILE_BUSY,
> e.g. via ops->card_busy().
>
> If we want to follow above standard process to do the timing change .
> We could do as:
> Set card DDR52 timing (CMD6) ->
> card_busy() done ->
> Set host DDR52 timing ->
> CMD13 to re-check
>
> Below is the draft patch for above approach and simply test works.
>

Haibo, Dong,

I really appreciate the level of details in the information and thanks
for helping out!

>
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index b11c345..3368b1a 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -451,7 +451,8 @@ int mmc_switch_status(struct mmc_card *card)
>  }
>
>  static int mmc_poll_for_busy(struct mmc_card *card, unsigned int timeout_ms,
> -   bool send_status, bool retry_crc_err)
> +   bool send_status, bool retry_crc_err,
> +   unsigned char timing)
>  {
> struct mmc_host *host = card->host;
> int err;
> 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Dong Aisheng]

Hi Shawn,

On Fri, Jan 13, 2017 at 12:03 PM, Shawn Lin  wrote:

[...]

>
>> 2) root cause, in __mmc_switch, the process is   send CMD6 --> set DDR52
>> timing --> polling for busy.
>> For the DDR52 timing setting, we call set_ios(), in the set_ios, we first
>> set DDR_EN to config sdhc in ddr mode,
>> and then config the sd clock again.   Here it is, after CMD6 complete, we
>> find data0 still low, which means card
>> busy. At this time, if we set DDR_EN, there is a risk. For i.MX usdhc,
>> DDR_EN setting becomes active only when
>> the DATA and CMD line are idle. So, at this time for HW, DDR_EN do not
>> active, but software think DDR_EN already
>> active, and set the clock again to 49.5MHz, but actually the HW out put
>> the clock as 198MHz. So there is clock glitch.
>> This is the root cause--set DDR_EN when card is still busy.
>>
>
> Make sense. But it makes me more worried about the problem.
> Does it impact other controllers if changing timing settings when
> it's in busy state? It seems very likely possible. So I'm afraid
> that we now just break hs_ddr mode for your platform but on the
> contrary your case exposes this potention risk here. Thought?
>

Yes, i got the same concern as i replied in my last email.
Not sure if any other controllers exposes the same issue
since the kernel having this issue is quite new.

Regards
Dong Aisheng

>> The following method can fix this issue
>> a) change the HW behavior, DDR_EN setting becomes active at once no matter
>> what the state of the DATA and
>> CMD line are.   This can fix this issue, but our IC guys do not prefer
>> this, this method still not safe enough.
>>
>> b) add 1ms delay before DDR_EN to wait bus idle.  But we still not know
>> whether the time 1ms is appropriate. Better
>> to poll for busy before set DDR_EN.
>>
>> c) set DDR52 timing after CMD6 and pull for busy. This is what Shawn's
>> patch do.
>>
>> Hi Aisheng,
>> Correct me if anything wrong.
>>
>> My suggestion is that,  in __mmc_switch(), move the mmc_set_timing() after
>> the function mmc_poll_for_busy().
>>
>>
>> Best Regards
>> Haibo Chen
>>
>>
>>
 if that can be done. So I will give Haibo/Dong etc a couple of more
 days to investigate, before applying Shawn Lin's fix for the core.
 Hope that approach is okay with all of you?

 Kind regards
 Uffe



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

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Dong Aisheng]

Hi Shawn,

On Fri, Jan 13, 2017 at 12:03 PM, Shawn Lin  wrote:

[...]

>
>> 2) root cause, in __mmc_switch, the process is   send CMD6 --> set DDR52
>> timing --> polling for busy.
>> For the DDR52 timing setting, we call set_ios(), in the set_ios, we first
>> set DDR_EN to config sdhc in ddr mode,
>> and then config the sd clock again.   Here it is, after CMD6 complete, we
>> find data0 still low, which means card
>> busy. At this time, if we set DDR_EN, there is a risk. For i.MX usdhc,
>> DDR_EN setting becomes active only when
>> the DATA and CMD line are idle. So, at this time for HW, DDR_EN do not
>> active, but software think DDR_EN already
>> active, and set the clock again to 49.5MHz, but actually the HW out put
>> the clock as 198MHz. So there is clock glitch.
>> This is the root cause--set DDR_EN when card is still busy.
>>
>
> Make sense. But it makes me more worried about the problem.
> Does it impact other controllers if changing timing settings when
> it's in busy state? It seems very likely possible. So I'm afraid
> that we now just break hs_ddr mode for your platform but on the
> contrary your case exposes this potention risk here. Thought?
>

Yes, i got the same concern as i replied in my last email.
Not sure if any other controllers exposes the same issue
since the kernel having this issue is quite new.

Regards
Dong Aisheng

>> The following method can fix this issue
>> a) change the HW behavior, DDR_EN setting becomes active at once no matter
>> what the state of the DATA and
>> CMD line are.   This can fix this issue, but our IC guys do not prefer
>> this, this method still not safe enough.
>>
>> b) add 1ms delay before DDR_EN to wait bus idle.  But we still not know
>> whether the time 1ms is appropriate. Better
>> to poll for busy before set DDR_EN.
>>
>> c) set DDR52 timing after CMD6 and pull for busy. This is what Shawn's
>> patch do.
>>
>> Hi Aisheng,
>> Correct me if anything wrong.
>>
>> My suggestion is that,  in __mmc_switch(), move the mmc_set_timing() after
>> the function mmc_poll_for_busy().
>>
>>
>> Best Regards
>> Haibo Chen
>>
>>
>>
 if that can be done. So I will give Haibo/Dong etc a couple of more
 days to investigate, before applying Shawn Lin's fix for the core.
 Hope that approach is okay with all of you?

 Kind regards
 Uffe



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

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Dong Aisheng]

On Fri, Jan 13, 2017 at 11:12 AM, Bough Chen <haibo.c...@nxp.com> wrote:
>> -Original Message-
>> From: Shawn Lin [mailto:shawn@rock-chips.com]
>> Sent: Friday, January 13, 2017 10:11 AM
>> To: Ulf Hansson <ulf.hans...@linaro.org>; Clemens Gruber
>> <clemens.gru...@pqgruber.com>
>> Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
>> <linus.wall...@linaro.org>; Adrian Hunter <adrian.hun...@intel.com>; A.S.
>> Dong <aisheng.d...@nxp.com>; linux-kernel@vger.kernel.org; Bough Chen
>> <haibo.c...@nxp.com>; Gary Bisson <gary.bis...@boundarydevices.com>;
>> Fabio Estevam <feste...@gmail.com>; Shawn Guo <shawn...@kernel.org>
>> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
>>
>> On 2017/1/13 0:51, Ulf Hansson wrote:
>> > + Haibo, Gary, Fabio, Shawn Gou
>> >
>> > On 6 January 2017 at 16:56, Clemens Gruber
>> <clemens.gru...@pqgruber.com> wrote:
>> >> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
>> >>> On 2017/1/6 8:41, Clemens Gruber wrote:
>> >>>> Hi,
>> >>>>
>> >>>> with the current mainline 4.10-rc2 kernel, I can no longer boot
>> >>>> from the eMMC on my i.MX6Q board.
>> >>>>
>> >>>> Details:
>> >>>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
>> >>>> supports eMMC 4.41 features and we did not implement voltage
>> >>>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
>> >>>> of the mmc-ddr or mmc-hs
>> >>>> options) to the device tree. The bus-width is 8.
>> >>>>
>> >>>> With 4.9 the board booted fine, now with the current mainline 4.10
>> >>>> tree, I get the following (repeating) errors at boot:
>> >>>>
>> >>>> [4.326834] Waiting for root device /dev/mmcblk0p2...
>> >>>> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>> >>>> [   14.569619] sdhci: === REGISTER DUMP
>> (mmc0)===
>> >>>> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
>> >>>> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> >>>> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> >>>> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> >>>> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
>> >>>> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> >>>> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
>> >>>> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> >>>> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
>> >>>> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>> >>>> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>> >>>
>> >>> it shows you always fail to get resp of sending status within the
>> >>> expected period of time.
>> >>>
>> >>>
>> >>>> [   14.639682] sdhci: Host ctl2: 0x
>> >>>> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
>> >>>> [   14.649447] sdhci:
>> ===
>> >>>>
>> >>>> This repeats a few times, then more information is shown at the bottom:
>> >>>>
>> >>>> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>> >>>> [   86.899615] sdhci: === REGISTER DUMP
>> (mmc0)===
>> >>>> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
>> >>>> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> >>>> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> >>>> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> >>>> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
>> >>>> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> >>>> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
>> >>>> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> >>>> [   86.952154] sdhci: AC12 err:

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Dong Aisheng]

On Fri, Jan 13, 2017 at 11:12 AM, Bough Chen  wrote:
>> -Original Message-
>> From: Shawn Lin [mailto:shawn@rock-chips.com]
>> Sent: Friday, January 13, 2017 10:11 AM
>> To: Ulf Hansson ; Clemens Gruber
>> 
>> Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
>> ; Adrian Hunter ; A.S.
>> Dong ; linux-kernel@vger.kernel.org; Bough Chen
>> ; Gary Bisson ;
>> Fabio Estevam ; Shawn Guo 
>> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
>>
>> On 2017/1/13 0:51, Ulf Hansson wrote:
>> > + Haibo, Gary, Fabio, Shawn Gou
>> >
>> > On 6 January 2017 at 16:56, Clemens Gruber
>>  wrote:
>> >> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
>> >>> On 2017/1/6 8:41, Clemens Gruber wrote:
>> >>>> Hi,
>> >>>>
>> >>>> with the current mainline 4.10-rc2 kernel, I can no longer boot
>> >>>> from the eMMC on my i.MX6Q board.
>> >>>>
>> >>>> Details:
>> >>>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
>> >>>> supports eMMC 4.41 features and we did not implement voltage
>> >>>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
>> >>>> of the mmc-ddr or mmc-hs
>> >>>> options) to the device tree. The bus-width is 8.
>> >>>>
>> >>>> With 4.9 the board booted fine, now with the current mainline 4.10
>> >>>> tree, I get the following (repeating) errors at boot:
>> >>>>
>> >>>> [4.326834] Waiting for root device /dev/mmcblk0p2...
>> >>>> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>> >>>> [   14.569619] sdhci: === REGISTER DUMP
>> (mmc0)===
>> >>>> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
>> >>>> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> >>>> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> >>>> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> >>>> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
>> >>>> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> >>>> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
>> >>>> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> >>>> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
>> >>>> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>> >>>> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>> >>>
>> >>> it shows you always fail to get resp of sending status within the
>> >>> expected period of time.
>> >>>
>> >>>
>> >>>> [   14.639682] sdhci: Host ctl2: 0x
>> >>>> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
>> >>>> [   14.649447] sdhci:
>> ===
>> >>>>
>> >>>> This repeats a few times, then more information is shown at the bottom:
>> >>>>
>> >>>> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>> >>>> [   86.899615] sdhci: === REGISTER DUMP
>> (mmc0)===
>> >>>> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
>> >>>> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> >>>> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> >>>> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> >>>> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
>> >>>> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> >>>> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
>> >>>> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> >>>> [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
>> >>>> [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>> >>>> [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>> >>>> [   86.969668] sdhci: Host ctl2: 0x
>> >

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/13 11:12, Bough Chen wrote:

-Original Message-
From: Shawn Lin [mailto:shawn@rock-chips.com]
Sent: Friday, January 13, 2017 10:11 AM
To: Ulf Hansson <ulf.hans...@linaro.org>; Clemens Gruber
<clemens.gru...@pqgruber.com>
Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
<linus.wall...@linaro.org>; Adrian Hunter <adrian.hun...@intel.com>; A.S.
Dong <aisheng.d...@nxp.com>; linux-kernel@vger.kernel.org; Bough Chen
<haibo.c...@nxp.com>; Gary Bisson <gary.bis...@boundarydevices.com>;
Fabio Estevam <feste...@gmail.com>; Shawn Guo <shawn...@kernel.org>
Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed

On 2017/1/13 0:51, Ulf Hansson wrote:

+ Haibo, Gary, Fabio, Shawn Gou

On 6 January 2017 at 16:56, Clemens Gruber

<clemens.gru...@pqgruber.com> wrote:

On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot
from the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
supports eMMC 4.41 features and we did not implement voltage
switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10
tree, I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP

(mmc0)===

[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff


it shows you always fail to get resp of sending status within the
expected period of time.



[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci:

===


This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP

(mmc0)===

[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci:

===

[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core:

Update

CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!


By looking the changes itself, it should be good from the view of spec.
Maybe you could try the patch below, but don't beat me if that
doesn't help at all. :)

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card

*card)

   EXT_CSD_BUS_WIDTH,
   ext_csd_bits,
   card->ext_csd.generic_cmd6_time,
-  MMC_TIMING_MMC_DDR52,
+  0,
   true, true, true);
if (err) {
pr_err("%s: switch to bus width %d ddr failed\n", @@
-1118,6 +1118,9 @@ stati

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/13 11:12, Bough Chen wrote:

-Original Message-
From: Shawn Lin [mailto:shawn@rock-chips.com]
Sent: Friday, January 13, 2017 10:11 AM
To: Ulf Hansson ; Clemens Gruber

Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
; Adrian Hunter ; A.S.
Dong ; linux-kernel@vger.kernel.org; Bough Chen
; Gary Bisson ;
Fabio Estevam ; Shawn Guo 
Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed

On 2017/1/13 0:51, Ulf Hansson wrote:

+ Haibo, Gary, Fabio, Shawn Gou

On 6 January 2017 at 16:56, Clemens Gruber

 wrote:

On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot
from the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
supports eMMC 4.41 features and we did not implement voltage
switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10
tree, I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP

(mmc0)===

[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff


it shows you always fail to get resp of sending status within the
expected period of time.



[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci:

===


This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP

(mmc0)===

[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci:

===

[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core:

Update

CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!


By looking the changes itself, it should be good from the view of spec.
Maybe you could try the patch below, but don't beat me if that
doesn't help at all. :)

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card

*card)

   EXT_CSD_BUS_WIDTH,
   ext_csd_bits,
   card->ext_csd.generic_cmd6_time,
-  MMC_TIMING_MMC_DDR52,
+  0,
   true, true, true);
if (err) {
pr_err("%s: switch to bus width %d ddr failed\n", @@
-1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
if (err)
err = __mmc_set_signal_voltage(host,
MMC_SIGNAL_VOLTAGE_330);

+   if (!err)
+   mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
+




Hi,

thank you. This patch solves the problem! :)

Tested-by: Clemens Gruber 

Regar

RE: eMMC boot problem: switch to bus width 8 ddr failed

[Bough Chen]

> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: Friday, January 13, 2017 10:11 AM
> To: Ulf Hansson <ulf.hans...@linaro.org>; Clemens Gruber
> <clemens.gru...@pqgruber.com>
> Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
> <linus.wall...@linaro.org>; Adrian Hunter <adrian.hun...@intel.com>; A.S.
> Dong <aisheng.d...@nxp.com>; linux-kernel@vger.kernel.org; Bough Chen
> <haibo.c...@nxp.com>; Gary Bisson <gary.bis...@boundarydevices.com>;
> Fabio Estevam <feste...@gmail.com>; Shawn Guo <shawn...@kernel.org>
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> On 2017/1/13 0:51, Ulf Hansson wrote:
> > + Haibo, Gary, Fabio, Shawn Gou
> >
> > On 6 January 2017 at 16:56, Clemens Gruber
> <clemens.gru...@pqgruber.com> wrote:
> >> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> >>> On 2017/1/6 8:41, Clemens Gruber wrote:
> >>>> Hi,
> >>>>
> >>>> with the current mainline 4.10-rc2 kernel, I can no longer boot
> >>>> from the eMMC on my i.MX6Q board.
> >>>>
> >>>> Details:
> >>>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
> >>>> supports eMMC 4.41 features and we did not implement voltage
> >>>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
> >>>> of the mmc-ddr or mmc-hs
> >>>> options) to the device tree. The bus-width is 8.
> >>>>
> >>>> With 4.9 the board booted fine, now with the current mainline 4.10
> >>>> tree, I get the following (repeating) errors at boot:
> >>>>
> >>>> [4.326834] Waiting for root device /dev/mmcblk0p2...
> >>>> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>> [   14.569619] sdhci: === REGISTER DUMP
> (mmc0)===
> >>>> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> >>>> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>>> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>>> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>>> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>>> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>>> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> >>>> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>>> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>>> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>>> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>>
> >>> it shows you always fail to get resp of sending status within the
> >>> expected period of time.
> >>>
> >>>
> >>>> [   14.639682] sdhci: Host ctl2: 0x
> >>>> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> >>>> [   14.649447] sdhci:
> ===
> >>>>
> >>>> This repeats a few times, then more information is shown at the bottom:
> >>>>
> >>>> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>> [   86.899615] sdhci: === REGISTER DUMP
> (mmc0)===
> >>>> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> >>>> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>>> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>>> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>>> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>>> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>>> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> >>>> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>>> [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>>> [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>>> [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>>> [   86.969668] sdhci: Host ctl2: 0x
> >>>> [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> >

RE: eMMC boot problem: switch to bus width 8 ddr failed

[Bough Chen]

> -Original Message-
> From: Shawn Lin [mailto:shawn@rock-chips.com]
> Sent: Friday, January 13, 2017 10:11 AM
> To: Ulf Hansson ; Clemens Gruber
> 
> Cc: shawn@rock-chips.com; linux-...@vger.kernel.org; Linus Walleij
> ; Adrian Hunter ; A.S.
> Dong ; linux-kernel@vger.kernel.org; Bough Chen
> ; Gary Bisson ;
> Fabio Estevam ; Shawn Guo 
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> On 2017/1/13 0:51, Ulf Hansson wrote:
> > + Haibo, Gary, Fabio, Shawn Gou
> >
> > On 6 January 2017 at 16:56, Clemens Gruber
>  wrote:
> >> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> >>> On 2017/1/6 8:41, Clemens Gruber wrote:
> >>>> Hi,
> >>>>
> >>>> with the current mainline 4.10-rc2 kernel, I can no longer boot
> >>>> from the eMMC on my i.MX6Q board.
> >>>>
> >>>> Details:
> >>>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
> >>>> supports eMMC 4.41 features and we did not implement voltage
> >>>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
> >>>> of the mmc-ddr or mmc-hs
> >>>> options) to the device tree. The bus-width is 8.
> >>>>
> >>>> With 4.9 the board booted fine, now with the current mainline 4.10
> >>>> tree, I get the following (repeating) errors at boot:
> >>>>
> >>>> [4.326834] Waiting for root device /dev/mmcblk0p2...
> >>>> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>> [   14.569619] sdhci: === REGISTER DUMP
> (mmc0)===
> >>>> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> >>>> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>>> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>>> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>>> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>>> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>>> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> >>>> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>>> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>>> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>>> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>>
> >>> it shows you always fail to get resp of sending status within the
> >>> expected period of time.
> >>>
> >>>
> >>>> [   14.639682] sdhci: Host ctl2: 0x
> >>>> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> >>>> [   14.649447] sdhci:
> ===
> >>>>
> >>>> This repeats a few times, then more information is shown at the bottom:
> >>>>
> >>>> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>> [   86.899615] sdhci: === REGISTER DUMP
> (mmc0)===
> >>>> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> >>>> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>>> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>>> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>>> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>>> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>>> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> >>>> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>>> [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>>> [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>>> [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>>> [   86.969668] sdhci: Host ctl2: 0x
> >>>> [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> >>>> [   86.979433] sdhci:
> ===
> >>>> [   86.986356] mmc0: switch to bus width 8 ddr failed
> >>>> [   86.991163] mmc0: error -110 whilst initialising MMC card
> >>>> [   97.773859] m

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/13 0:51, Ulf Hansson wrote:

+ Haibo, Gary, Fabio, Shawn Gou

On 6 January 2017 at 16:56, Clemens Gruber  wrote:

On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff


it shows you always fail to get resp of sending status within the
expected period of time.



[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!


By looking the changes itself, it should be good from the view of spec.
Maybe you could try the patch below, but don't beat me if that doesn't
help at all. :)

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
   EXT_CSD_BUS_WIDTH,
   ext_csd_bits,
   card->ext_csd.generic_cmd6_time,
-  MMC_TIMING_MMC_DDR52,
+  0,
   true, true, true);
if (err) {
pr_err("%s: switch to bus width %d ddr failed\n",
@@ -1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
if (err)
err = __mmc_set_signal_voltage(host,
MMC_SIGNAL_VOLTAGE_330);

+   if (!err)
+   mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
+




Hi,

thank you. This patch solves the problem! :)

Tested-by: Clemens Gruber 

Regards,
Clemens


Everybody involved, thanks for looking into this!

I think the above approach seems like a reasonable fix for the 4.10
rcs. Shawn Lin, would you mind re-posting a proper patch with a
change-log?


Sure.



In the meantime, I will follow the process of Haibo Chen's debugging
around the voltage switch issue and look into what Dong's suggesting
around this may be.

Just to be clear, I would definitely prefer 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/13 0:51, Ulf Hansson wrote:

+ Haibo, Gary, Fabio, Shawn Gou

On 6 January 2017 at 16:56, Clemens Gruber  wrote:

On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff


it shows you always fail to get resp of sending status within the
expected period of time.



[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!


By looking the changes itself, it should be good from the view of spec.
Maybe you could try the patch below, but don't beat me if that doesn't
help at all. :)

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
   EXT_CSD_BUS_WIDTH,
   ext_csd_bits,
   card->ext_csd.generic_cmd6_time,
-  MMC_TIMING_MMC_DDR52,
+  0,
   true, true, true);
if (err) {
pr_err("%s: switch to bus width %d ddr failed\n",
@@ -1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
if (err)
err = __mmc_set_signal_voltage(host,
MMC_SIGNAL_VOLTAGE_330);

+   if (!err)
+   mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
+




Hi,

thank you. This patch solves the problem! :)

Tested-by: Clemens Gruber 

Regards,
Clemens


Everybody involved, thanks for looking into this!

I think the above approach seems like a reasonable fix for the 4.10
rcs. Shawn Lin, would you mind re-posting a proper patch with a
change-log?


Sure.



In the meantime, I will follow the process of Haibo Chen's debugging
around the voltage switch issue and look into what Dong's suggesting
around this may be.

Just to be clear, I would definitely prefer a fix in the sdhci driver,


yup, I prefer to fix the 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Ulf Hansson]

+ Haibo, Gary, Fabio, Shawn Gou

On 6 January 2017 at 16:56, Clemens Gruber  wrote:
> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
>> On 2017/1/6 8:41, Clemens Gruber wrote:
>> > Hi,
>> >
>> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
>> > the eMMC on my i.MX6Q board.
>> >
>> > Details:
>> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
>> > eMMC 4.41 features and we did not implement voltage switching from 3.3V
>> > to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
>> > options) to the device tree. The bus-width is 8.
>> >
>> > With 4.9 the board booted fine, now with the current mainline 4.10 tree,
>> > I get the following (repeating) errors at boot:
>> >
>> > [4.326834] Waiting for root device /dev/mmcblk0p2...
>> > [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>> > [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
>> > [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
>> > [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> > [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> > [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> > [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
>> > [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> > [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
>> > [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> > [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
>> > [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>> > [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>>
>> it shows you always fail to get resp of sending status within the
>> expected period of time.
>>
>>
>> > [   14.639682] sdhci: Host ctl2: 0x
>> > [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
>> > [   14.649447] sdhci: ===
>> >
>> > This repeats a few times, then more information is shown at the bottom:
>> >
>> > [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>> > [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
>> > [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
>> > [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> > [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> > [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> > [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
>> > [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> > [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
>> > [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> > [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
>> > [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>> > [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>> > [   86.969668] sdhci: Host ctl2: 0x
>> > [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
>> > [   86.979433] sdhci: ===
>> > [   86.986356] mmc0: switch to bus width 8 ddr failed
>> > [   86.991163] mmc0: error -110 whilst initialising MMC card
>> > [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
>> >
>> > --
>> >
>> > After looking through the latest commits to mmc/core, I found the
>> > culprit:
>> > Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
>> > CMD13 polling policy when switch to HS DDR mode")
>> >
>> > Reverting it fixes the problem. But I am unsure if that's the right
>> > course of action?
>> >
>> > Feel free to send me patches for testing!
>>
>> By looking the changes itself, it should be good from the view of spec.
>> Maybe you could try the patch below, but don't beat me if that doesn't
>> help at all. :)
>>
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
>>EXT_CSD_BUS_WIDTH,
>>ext_csd_bits,
>>card->ext_csd.generic_cmd6_time,
>> -  MMC_TIMING_MMC_DDR52,
>> +  0,
>>true, true, true);
>> if (err) {
>> pr_err("%s: switch to bus width %d ddr failed\n",
>> @@ -1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
>> if (err)
>> err = __mmc_set_signal_voltage(host,
>> MMC_SIGNAL_VOLTAGE_330);
>>
>> +   if (!err)
>> +   mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
>> +
>>
>>
>
> Hi,
>
> thank you. This patch solves the problem! :)
>
> Tested-by: Clemens Gruber 
>
> Regards,
> Clemens

Everybody involved, thanks for 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Ulf Hansson]

+ Haibo, Gary, Fabio, Shawn Gou

On 6 January 2017 at 16:56, Clemens Gruber  wrote:
> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
>> On 2017/1/6 8:41, Clemens Gruber wrote:
>> > Hi,
>> >
>> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
>> > the eMMC on my i.MX6Q board.
>> >
>> > Details:
>> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
>> > eMMC 4.41 features and we did not implement voltage switching from 3.3V
>> > to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
>> > options) to the device tree. The bus-width is 8.
>> >
>> > With 4.9 the board booted fine, now with the current mainline 4.10 tree,
>> > I get the following (repeating) errors at boot:
>> >
>> > [4.326834] Waiting for root device /dev/mmcblk0p2...
>> > [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>> > [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
>> > [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
>> > [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> > [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> > [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> > [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
>> > [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> > [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
>> > [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> > [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
>> > [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>> > [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>>
>> it shows you always fail to get resp of sending status within the
>> expected period of time.
>>
>>
>> > [   14.639682] sdhci: Host ctl2: 0x
>> > [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
>> > [   14.649447] sdhci: ===
>> >
>> > This repeats a few times, then more information is shown at the bottom:
>> >
>> > [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>> > [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
>> > [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
>> > [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> > [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> > [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> > [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
>> > [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> > [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
>> > [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> > [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
>> > [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>> > [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>> > [   86.969668] sdhci: Host ctl2: 0x
>> > [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
>> > [   86.979433] sdhci: ===
>> > [   86.986356] mmc0: switch to bus width 8 ddr failed
>> > [   86.991163] mmc0: error -110 whilst initialising MMC card
>> > [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
>> >
>> > --
>> >
>> > After looking through the latest commits to mmc/core, I found the
>> > culprit:
>> > Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
>> > CMD13 polling policy when switch to HS DDR mode")
>> >
>> > Reverting it fixes the problem. But I am unsure if that's the right
>> > course of action?
>> >
>> > Feel free to send me patches for testing!
>>
>> By looking the changes itself, it should be good from the view of spec.
>> Maybe you could try the patch below, but don't beat me if that doesn't
>> help at all. :)
>>
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
>>EXT_CSD_BUS_WIDTH,
>>ext_csd_bits,
>>card->ext_csd.generic_cmd6_time,
>> -  MMC_TIMING_MMC_DDR52,
>> +  0,
>>true, true, true);
>> if (err) {
>> pr_err("%s: switch to bus width %d ddr failed\n",
>> @@ -1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
>> if (err)
>> err = __mmc_set_signal_voltage(host,
>> MMC_SIGNAL_VOLTAGE_330);
>>
>> +   if (!err)
>> +   mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
>> +
>>
>>
>
> Hi,
>
> thank you. This patch solves the problem! :)
>
> Tested-by: Clemens Gruber 
>
> Regards,
> Clemens

Everybody involved, thanks for looking into this!

I think the above approach seems like a 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Dong Aisheng]

On Tue, Jan 10, 2017 at 6:25 AM, Jagan Teki  wrote:
> On Fri, Jan 6, 2017 at 5:07 PM, Clemens Gruber
>  wrote:
>> On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
>>> On 2017/1/6 8:41, Clemens Gruber wrote:
>>> > Hi,
>>> >
>>> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
>>> > the eMMC on my i.MX6Q board.
>>> >
>>> > Details:
>>> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
>>> > eMMC 4.41 features and we did not implement voltage switching from 3.3V
>>> > to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
>>> > options) to the device tree. The bus-width is 8.
>>> >
>>> > With 4.9 the board booted fine, now with the current mainline 4.10 tree,
>>> > I get the following (repeating) errors at boot:
>>> >
>>> > [4.326834] Waiting for root device /dev/mmcblk0p2...
>>> > [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>>> > [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
>>> > [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
>>> > [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>>> > [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>>> > [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>>> > [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
>>> > [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
>>> > [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
>>> > [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>>> > [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
>>> > [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>>> > [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>>> > [   14.639682] sdhci: Host ctl2: 0x
>>> > [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
>>> > [   14.649447] sdhci: ===
>>> >
>>> > This repeats a few times, then more information is shown at the bottom:
>>> >
>>> > [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>>> > [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
>>> > [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
>>> > [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>>> > [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>>> > [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>>> > [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
>>> > [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
>>> > [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
>>> > [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>>> > [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
>>> > [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>>> > [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>>> > [   86.969668] sdhci: Host ctl2: 0x
>>> > [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
>>> > [   86.979433] sdhci: ===
>>> > [   86.986356] mmc0: switch to bus width 8 ddr failed
>>> > [   86.991163] mmc0: error -110 whilst initialising MMC card
>>> > [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
>>> >
>>> > --
>>> >
>>> > After looking through the latest commits to mmc/core, I found the
>>> > culprit:
>>> > Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
>>> > CMD13 polling policy when switch to HS DDR mode")
>>> >
>>> > Reverting it fixes the problem. But I am unsure if that's the right
>>> > course of action?
>>> >
>>> > Feel free to send me patches for testing!
>>> >
>>>
>>> I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
>>> code miss a bit, so could you also try this one?
>>>
>>> drivers/mmc/core/mmc_ops.c
>>> @@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card,
>>> unsigned int timeout_ms,
>>> busy = host->ops->card_busy(host);
>>> } else {
>>> err = mmc_send_status(card, );
>>> -   if (retry_crc_err && err == -EILSEQ) {
>>> +   if (retry_crc_err && (err == -EILSEQ ||
>>> +   err == -ETIMEDOUT)) {
>>> busy = true;
>>> } else if (err) {
>>> return err;
>>>
>>
>> Hi,
>>
>> this patch (alone) does not solve the problem. The error message is the
>> same as before.
>>
>> But applying both your first patch and this one does work. Is this one
>> beneficial anyway, even if it does not fix my problem?
>
> Able to detect the eMMC, but getting kernel panic while formatting the
> disk, (even remove the mmc_ops change)
>

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Dong Aisheng]

On Tue, Jan 10, 2017 at 6:25 AM, Jagan Teki  wrote:
> On Fri, Jan 6, 2017 at 5:07 PM, Clemens Gruber
>  wrote:
>> On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
>>> On 2017/1/6 8:41, Clemens Gruber wrote:
>>> > Hi,
>>> >
>>> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
>>> > the eMMC on my i.MX6Q board.
>>> >
>>> > Details:
>>> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
>>> > eMMC 4.41 features and we did not implement voltage switching from 3.3V
>>> > to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
>>> > options) to the device tree. The bus-width is 8.
>>> >
>>> > With 4.9 the board booted fine, now with the current mainline 4.10 tree,
>>> > I get the following (repeating) errors at boot:
>>> >
>>> > [4.326834] Waiting for root device /dev/mmcblk0p2...
>>> > [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>>> > [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
>>> > [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
>>> > [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>>> > [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>>> > [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>>> > [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
>>> > [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
>>> > [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
>>> > [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>>> > [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
>>> > [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>>> > [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>>> > [   14.639682] sdhci: Host ctl2: 0x
>>> > [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
>>> > [   14.649447] sdhci: ===
>>> >
>>> > This repeats a few times, then more information is shown at the bottom:
>>> >
>>> > [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>>> > [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
>>> > [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
>>> > [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>>> > [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>>> > [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>>> > [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
>>> > [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
>>> > [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
>>> > [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>>> > [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
>>> > [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>>> > [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>>> > [   86.969668] sdhci: Host ctl2: 0x
>>> > [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
>>> > [   86.979433] sdhci: ===
>>> > [   86.986356] mmc0: switch to bus width 8 ddr failed
>>> > [   86.991163] mmc0: error -110 whilst initialising MMC card
>>> > [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
>>> >
>>> > --
>>> >
>>> > After looking through the latest commits to mmc/core, I found the
>>> > culprit:
>>> > Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
>>> > CMD13 polling policy when switch to HS DDR mode")
>>> >
>>> > Reverting it fixes the problem. But I am unsure if that's the right
>>> > course of action?
>>> >
>>> > Feel free to send me patches for testing!
>>> >
>>>
>>> I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
>>> code miss a bit, so could you also try this one?
>>>
>>> drivers/mmc/core/mmc_ops.c
>>> @@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card,
>>> unsigned int timeout_ms,
>>> busy = host->ops->card_busy(host);
>>> } else {
>>> err = mmc_send_status(card, );
>>> -   if (retry_crc_err && err == -EILSEQ) {
>>> +   if (retry_crc_err && (err == -EILSEQ ||
>>> +   err == -ETIMEDOUT)) {
>>> busy = true;
>>> } else if (err) {
>>> return err;
>>>
>>
>> Hi,
>>
>> this patch (alone) does not solve the problem. The error message is the
>> same as before.
>>
>> But applying both your first patch and this one does work. Is this one
>> beneficial anyway, even if it does not fix my problem?
>
> Able to detect the eMMC, but getting kernel panic while formatting the
> disk, (even remove the mmc_ops change)
>
> Log:
> 
> Disk /dev/mmcblk1: 3791 MB, 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Dong Aisheng]

On Fri, Jan 6, 2017 at 8:41 AM, Clemens Gruber
 wrote:
> Hi,
>
> with the current mainline 4.10-rc2 kernel, I can no longer boot from
> the eMMC on my i.MX6Q board.
>
> Details:
> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
> eMMC 4.41 features and we did not implement voltage switching from 3.3V
> to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
> options) to the device tree. The bus-width is 8.
>
> With 4.9 the board booted fine, now with the current mainline 4.10 tree,
> I get the following (repeating) errors at boot:
>
> [4.326834] Waiting for root device /dev/mmcblk0p2...
> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> [   14.639682] sdhci: Host ctl2: 0x
> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> [   14.649447] sdhci: ===
>
> This repeats a few times, then more information is shown at the bottom:
>
> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> [   86.969668] sdhci: Host ctl2: 0x
> [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> [   86.979433] sdhci: ===
> [   86.986356] mmc0: switch to bus width 8 ddr failed
> [   86.991163] mmc0: error -110 whilst initialising MMC card
> [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
>
> --
>
> After looking through the latest commits to mmc/core, I found the
> culprit:
> Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
> CMD13 polling policy when switch to HS DDR mode")
>
> Reverting it fixes the problem. But I am unsure if that's the right
> course of action?
>
> Feel free to send me patches for testing!
>

I can reproduce the same issue with 4.10 RC3 on MX6Q SabreSD board.
When the issue happened, it always failed with timeout on the first CMD13
after CMD6.

And it's true that reverting the following commit can avoid the issue.
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

I did a close look at that patch, the only change by the reverting is
hold on the MMC_TIMING_MMC_DDR52 timing setting after CMD13 polling.
Otherwise the CMD13 may fail.

The current code logic seems okay to me, i still don't understand why
changing host timing as well during card timing changing process can
cause such issue. It's quite strange.

I double checked the main IMX DDR timing change code are
a)  disable clock b) set_uhs_signaling
which includes DDR enable and pinstate change c) enable clock.
(a and c are common SDHCI code)
We may need find out which step causes the issue.

Another interesting is enabling CONFIG_MMC_DEBUG may hide the issue.
Looks like a bit timing dependent. If i add a bit delay before
mmc_poll_for_busy(),
the issue was also gone.

For the temporary fix, i think you can revert the patch first since
polling in low speed for the card in high speed mode(DDR) normally should work
in theory.

Regards
Dong Aisheng

> Regards,
> Clemens

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Dong Aisheng]

On Fri, Jan 6, 2017 at 8:41 AM, Clemens Gruber
 wrote:
> Hi,
>
> with the current mainline 4.10-rc2 kernel, I can no longer boot from
> the eMMC on my i.MX6Q board.
>
> Details:
> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
> eMMC 4.41 features and we did not implement voltage switching from 3.3V
> to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
> options) to the device tree. The bus-width is 8.
>
> With 4.9 the board booted fine, now with the current mainline 4.10 tree,
> I get the following (repeating) errors at boot:
>
> [4.326834] Waiting for root device /dev/mmcblk0p2...
> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> [   14.639682] sdhci: Host ctl2: 0x
> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> [   14.649447] sdhci: ===
>
> This repeats a few times, then more information is shown at the bottom:
>
> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> [   86.969668] sdhci: Host ctl2: 0x
> [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> [   86.979433] sdhci: ===
> [   86.986356] mmc0: switch to bus width 8 ddr failed
> [   86.991163] mmc0: error -110 whilst initialising MMC card
> [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
>
> --
>
> After looking through the latest commits to mmc/core, I found the
> culprit:
> Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
> CMD13 polling policy when switch to HS DDR mode")
>
> Reverting it fixes the problem. But I am unsure if that's the right
> course of action?
>
> Feel free to send me patches for testing!
>

I can reproduce the same issue with 4.10 RC3 on MX6Q SabreSD board.
When the issue happened, it always failed with timeout on the first CMD13
after CMD6.

And it's true that reverting the following commit can avoid the issue.
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

I did a close look at that patch, the only change by the reverting is
hold on the MMC_TIMING_MMC_DDR52 timing setting after CMD13 polling.
Otherwise the CMD13 may fail.

The current code logic seems okay to me, i still don't understand why
changing host timing as well during card timing changing process can
cause such issue. It's quite strange.

I double checked the main IMX DDR timing change code are
a)  disable clock b) set_uhs_signaling
which includes DDR enable and pinstate change c) enable clock.
(a and c are common SDHCI code)
We may need find out which step causes the issue.

Another interesting is enabling CONFIG_MMC_DEBUG may hide the issue.
Looks like a bit timing dependent. If i add a bit delay before
mmc_poll_for_busy(),
the issue was also gone.

For the temporary fix, i think you can revert the patch first since
polling in low speed for the card in high speed mode(DDR) normally should work
in theory.

Regards
Dong Aisheng

> Regards,
> Clemens

RE: eMMC boot problem: switch to bus width 8 ddr failed

[Bough Chen]

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Shawn Lin
> Sent: Monday, January 09, 2017 3:10 PM
> To: Clemens Gruber <clemens.gru...@pqgruber.com>; Shawn Lin
> <shawn@rock-chips.com>; linux-...@vger.kernel.org
> Cc: shawn@rock-chips.com; Ulf Hansson <ulf.hans...@linaro.org>; Linus
> Walleij <linus.wall...@linaro.org>; Adrian Hunter <adrian.hun...@intel.com>;
> A.S. Dong <aisheng.d...@nxp.com>; linux-kernel@vger.kernel.org
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> On 2017/1/6 23:56, Clemens Gruber wrote:
> > On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> >> On 2017/1/6 8:41, Clemens Gruber wrote:
> >>> Hi,
> >>>
> >>> with the current mainline 4.10-rc2 kernel, I can no longer boot from
> >>> the eMMC on my i.MX6Q board.
> >>>
> >>> Details:
> >>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
> >>> supports eMMC 4.41 features and we did not implement voltage
> >>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
> >>> of the mmc-ddr or mmc-hs
> >>> options) to the device tree. The bus-width is 8.
> >>>
> >>> With 4.9 the board booted fine, now with the current mainline 4.10
> >>> tree, I get the following (repeating) errors at boot:
> >>>
> >>> [4.326834] Waiting for root device /dev/mmcblk0p2...
> >>> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> >>> [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
> >>> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> >>> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> >>> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>
> >> it shows you always fail to get resp of sending status within the
> >> expected period of time.
> >>
> >>
> >>> [   14.639682] sdhci: Host ctl2: 0x
> >>> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> >>> [   14.649447] sdhci:
> ===
> >>>
> >>> This repeats a few times, then more information is shown at the bottom:
> >>>
> >>> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>> [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
> >>> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> >>> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> >>> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>> [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>> [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>> [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>> [   86.969668] sdhci: Host ctl2: 0x
> >>> [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> >>> [   86.979433] sdhci:
> ===
> >>> [   86.986356] mmc0: switch to bus width 8 ddr failed
> >>> [   86.991163] mmc0: error -110 whilst initialising MMC card
> >>> [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>
> >>> --
> >>>
> >>> After looking through the latest commits to mmc/core, I found the
> >>>

RE: eMMC boot problem: switch to bus width 8 ddr failed

[Bough Chen]

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Shawn Lin
> Sent: Monday, January 09, 2017 3:10 PM
> To: Clemens Gruber ; Shawn Lin
> ; linux-...@vger.kernel.org
> Cc: shawn@rock-chips.com; Ulf Hansson ; Linus
> Walleij ; Adrian Hunter ;
> A.S. Dong ; linux-kernel@vger.kernel.org
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
> 
> On 2017/1/6 23:56, Clemens Gruber wrote:
> > On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> >> On 2017/1/6 8:41, Clemens Gruber wrote:
> >>> Hi,
> >>>
> >>> with the current mainline 4.10-rc2 kernel, I can no longer boot from
> >>> the eMMC on my i.MX6Q board.
> >>>
> >>> Details:
> >>> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only
> >>> supports eMMC 4.41 features and we did not implement voltage
> >>> switching from 3.3V to 1.8V or lower, I did add no-1-8-v; (but none
> >>> of the mmc-ddr or mmc-hs
> >>> options) to the device tree. The bus-width is 8.
> >>>
> >>> With 4.9 the board booted fine, now with the current mainline 4.10
> >>> tree, I get the following (repeating) errors at boot:
> >>>
> >>> [4.326834] Waiting for root device /dev/mmcblk0p2...
> >>> [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> >>> [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
> >>> [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> >>> [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>> [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>> [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>> [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>> [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>> [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> >>> [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>> [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>> [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>> [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>
> >> it shows you always fail to get resp of sending status within the
> >> expected period of time.
> >>
> >>
> >>> [   14.639682] sdhci: Host ctl2: 0x
> >>> [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> >>> [   14.649447] sdhci:
> ===
> >>>
> >>> This repeats a few times, then more information is shown at the bottom:
> >>>
> >>> [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>> [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
> >>> [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> >>> [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> >>> [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> >>> [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> >>> [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> >>> [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> >>> [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> >>> [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> >>> [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> >>> [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> >>> [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> >>> [   86.969668] sdhci: Host ctl2: 0x
> >>> [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> >>> [   86.979433] sdhci:
> ===
> >>> [   86.986356] mmc0: switch to bus width 8 ddr failed
> >>> [   86.991163] mmc0: error -110 whilst initialising MMC card
> >>> [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
> >>>
> >>> --
> >>>
> >>> After looking through the latest commits to mmc/core, I found the
> >>> culprit:
> >>> Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
> >>> CMD13 polling policy when switch to HS DDR mode")
> >>

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

Hi Jagan,

On 2017/1/10 6:25, Jagan Teki wrote:

On Fri, Jan 6, 2017 at 5:07 PM, Clemens Gruber
 wrote:

On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!



I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
code miss a bit, so could you also try this one?

drivers/mmc/core/mmc_ops.c
@@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card,
unsigned int timeout_ms,
busy = host->ops->card_busy(host);
} else {
err = mmc_send_status(card, );
-   if (retry_crc_err && err == -EILSEQ) {
+   if (retry_crc_err && (err == -EILSEQ ||
+   err == -ETIMEDOUT)) {
busy = true;
} else if (err) {
return err;



Hi,

this patch (alone) does not solve the problem. The error message is the
same as before.

But applying both your first patch and this one does work. Is this one
beneficial anyway, even if it does not fix my problem?


Able to detect the eMMC, but getting kernel panic while formatting the
disk, (even remove the mmc_ops change)


Both of my test patch and Ulf's patchset didn't touch that area.
Given that the log didn't show up too much useful infomation, it
is hard to say you should blame for these change.

Could you help do git-bitsect and try to find out the problematic
commit?



Log:

Disk /dev/mmcblk1: 3791 MB, 3791650816 bytes
4 heads, 16 sectors/track, 115712 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Device Boot  Start End  Blocks  Id System
/dev/mmcblk1p1   1 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

Hi Jagan,

On 2017/1/10 6:25, Jagan Teki wrote:

On Fri, Jan 6, 2017 at 5:07 PM, Clemens Gruber
 wrote:

On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!



I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
code miss a bit, so could you also try this one?

drivers/mmc/core/mmc_ops.c
@@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card,
unsigned int timeout_ms,
busy = host->ops->card_busy(host);
} else {
err = mmc_send_status(card, );
-   if (retry_crc_err && err == -EILSEQ) {
+   if (retry_crc_err && (err == -EILSEQ ||
+   err == -ETIMEDOUT)) {
busy = true;
} else if (err) {
return err;



Hi,

this patch (alone) does not solve the problem. The error message is the
same as before.

But applying both your first patch and this one does work. Is this one
beneficial anyway, even if it does not fix my problem?


Able to detect the eMMC, but getting kernel panic while formatting the
disk, (even remove the mmc_ops change)


Both of my test patch and Ulf's patchset didn't touch that area.
Given that the log didn't show up too much useful infomation, it
is hard to say you should blame for these change.

Could you help do git-bitsect and try to find out the problematic
commit?



Log:

Disk /dev/mmcblk1: 3791 MB, 3791650816 bytes
4 heads, 16 sectors/track, 115712 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Device Boot  Start End  Blocks  Id System
/dev/mmcblk1p1   1  115712 3702776  83 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Jagan Teki]

On Fri, Jan 6, 2017 at 5:07 PM, Clemens Gruber
 wrote:
> On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
>> On 2017/1/6 8:41, Clemens Gruber wrote:
>> > Hi,
>> >
>> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
>> > the eMMC on my i.MX6Q board.
>> >
>> > Details:
>> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
>> > eMMC 4.41 features and we did not implement voltage switching from 3.3V
>> > to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
>> > options) to the device tree. The bus-width is 8.
>> >
>> > With 4.9 the board booted fine, now with the current mainline 4.10 tree,
>> > I get the following (repeating) errors at boot:
>> >
>> > [4.326834] Waiting for root device /dev/mmcblk0p2...
>> > [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>> > [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
>> > [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
>> > [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> > [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> > [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> > [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
>> > [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> > [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
>> > [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> > [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
>> > [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>> > [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>> > [   14.639682] sdhci: Host ctl2: 0x
>> > [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
>> > [   14.649447] sdhci: ===
>> >
>> > This repeats a few times, then more information is shown at the bottom:
>> >
>> > [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>> > [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
>> > [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
>> > [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> > [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> > [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> > [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
>> > [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> > [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
>> > [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> > [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
>> > [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>> > [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>> > [   86.969668] sdhci: Host ctl2: 0x
>> > [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
>> > [   86.979433] sdhci: ===
>> > [   86.986356] mmc0: switch to bus width 8 ddr failed
>> > [   86.991163] mmc0: error -110 whilst initialising MMC card
>> > [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
>> >
>> > --
>> >
>> > After looking through the latest commits to mmc/core, I found the
>> > culprit:
>> > Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
>> > CMD13 polling policy when switch to HS DDR mode")
>> >
>> > Reverting it fixes the problem. But I am unsure if that's the right
>> > course of action?
>> >
>> > Feel free to send me patches for testing!
>> >
>>
>> I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
>> code miss a bit, so could you also try this one?
>>
>> drivers/mmc/core/mmc_ops.c
>> @@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card,
>> unsigned int timeout_ms,
>> busy = host->ops->card_busy(host);
>> } else {
>> err = mmc_send_status(card, );
>> -   if (retry_crc_err && err == -EILSEQ) {
>> +   if (retry_crc_err && (err == -EILSEQ ||
>> +   err == -ETIMEDOUT)) {
>> busy = true;
>> } else if (err) {
>> return err;
>>
>
> Hi,
>
> this patch (alone) does not solve the problem. The error message is the
> same as before.
>
> But applying both your first patch and this one does work. Is this one
> beneficial anyway, even if it does not fix my problem?

Able to detect the eMMC, but getting kernel panic while formatting the
disk, (even remove the mmc_ops change)

Log:

Disk /dev/mmcblk1: 3791 MB, 3791650816 bytes
4 heads, 16 sectors/track, 115712 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Device Boot  Start 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Jagan Teki]

On Fri, Jan 6, 2017 at 5:07 PM, Clemens Gruber
 wrote:
> On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
>> On 2017/1/6 8:41, Clemens Gruber wrote:
>> > Hi,
>> >
>> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
>> > the eMMC on my i.MX6Q board.
>> >
>> > Details:
>> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
>> > eMMC 4.41 features and we did not implement voltage switching from 3.3V
>> > to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
>> > options) to the device tree. The bus-width is 8.
>> >
>> > With 4.9 the board booted fine, now with the current mainline 4.10 tree,
>> > I get the following (repeating) errors at boot:
>> >
>> > [4.326834] Waiting for root device /dev/mmcblk0p2...
>> > [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>> > [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
>> > [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
>> > [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> > [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> > [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> > [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
>> > [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> > [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
>> > [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> > [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
>> > [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>> > [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>> > [   14.639682] sdhci: Host ctl2: 0x
>> > [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
>> > [   14.649447] sdhci: ===
>> >
>> > This repeats a few times, then more information is shown at the bottom:
>> >
>> > [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>> > [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
>> > [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
>> > [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
>> > [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
>> > [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
>> > [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
>> > [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
>> > [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
>> > [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>> > [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
>> > [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
>> > [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
>> > [   86.969668] sdhci: Host ctl2: 0x
>> > [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
>> > [   86.979433] sdhci: ===
>> > [   86.986356] mmc0: switch to bus width 8 ddr failed
>> > [   86.991163] mmc0: error -110 whilst initialising MMC card
>> > [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
>> >
>> > --
>> >
>> > After looking through the latest commits to mmc/core, I found the
>> > culprit:
>> > Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
>> > CMD13 polling policy when switch to HS DDR mode")
>> >
>> > Reverting it fixes the problem. But I am unsure if that's the right
>> > course of action?
>> >
>> > Feel free to send me patches for testing!
>> >
>>
>> I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
>> code miss a bit, so could you also try this one?
>>
>> drivers/mmc/core/mmc_ops.c
>> @@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card,
>> unsigned int timeout_ms,
>> busy = host->ops->card_busy(host);
>> } else {
>> err = mmc_send_status(card, );
>> -   if (retry_crc_err && err == -EILSEQ) {
>> +   if (retry_crc_err && (err == -EILSEQ ||
>> +   err == -ETIMEDOUT)) {
>> busy = true;
>> } else if (err) {
>> return err;
>>
>
> Hi,
>
> this patch (alone) does not solve the problem. The error message is the
> same as before.
>
> But applying both your first patch and this one does work. Is this one
> beneficial anyway, even if it does not fix my problem?

Able to detect the eMMC, but getting kernel panic while formatting the
disk, (even remove the mmc_ops change)

Log:

Disk /dev/mmcblk1: 3791 MB, 3791650816 bytes
4 heads, 16 sectors/track, 115712 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Device Boot  Start End  Blocks  Id 

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/7 0:07, Clemens Gruber wrote:

On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!



I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
code miss a bit, so could you also try this one?

drivers/mmc/core/mmc_ops.c
@@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card,
unsigned int timeout_ms,
busy = host->ops->card_busy(host);
} else {
err = mmc_send_status(card, );
-   if (retry_crc_err && err == -EILSEQ) {
+   if (retry_crc_err && (err == -EILSEQ ||
+   err == -ETIMEDOUT)) {
busy = true;
} else if (err) {
return err;



Hi,

this patch (alone) does not solve the problem. The error message is the
same as before.

But applying both your first patch and this one does work. Is this one
beneficial anyway, even if it does not fix my problem?


I think so. It always assumed that if the card was not ready after
finishing switching the mode, we should got a CRC, namely -EILSEQ, from
the hosts. But the fact is if the host is in higher speed mode but the
eMMC havn't finished the switch, so the host could fail to sample the
resp of CMD13 due to the mismatch timing in between. Could it is
possible that response timeout was generated instaed of -EILSEQ? It's
quite IP specificed. So I don't think we should take the risk of relying
that. In another word, we don't expect to bail out early for any errors
bounced from hosts when polling the status, no just for explicit CRC.






Regards,
Clemens






--
Best Regards
Shawn Lin

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/7 0:07, Clemens Gruber wrote:

On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!



I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
code miss a bit, so could you also try this one?

drivers/mmc/core/mmc_ops.c
@@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card,
unsigned int timeout_ms,
busy = host->ops->card_busy(host);
} else {
err = mmc_send_status(card, );
-   if (retry_crc_err && err == -EILSEQ) {
+   if (retry_crc_err && (err == -EILSEQ ||
+   err == -ETIMEDOUT)) {
busy = true;
} else if (err) {
return err;



Hi,

this patch (alone) does not solve the problem. The error message is the
same as before.

But applying both your first patch and this one does work. Is this one
beneficial anyway, even if it does not fix my problem?


I think so. It always assumed that if the card was not ready after
finishing switching the mode, we should got a CRC, namely -EILSEQ, from
the hosts. But the fact is if the host is in higher speed mode but the
eMMC havn't finished the switch, so the host could fail to sample the
resp of CMD13 due to the mismatch timing in between. Could it is
possible that response timeout was generated instaed of -EILSEQ? It's
quite IP specificed. So I don't think we should take the risk of relying
that. In another word, we don't expect to bail out early for any errors
bounced from hosts when polling the status, no just for explicit CRC.






Regards,
Clemens






--
Best Regards
Shawn Lin

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/6 23:56, Clemens Gruber wrote:

On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff


it shows you always fail to get resp of sending status within the
expected period of time.



[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!


By looking the changes itself, it should be good from the view of spec.
Maybe you could try the patch below, but don't beat me if that doesn't
help at all. :)

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
   EXT_CSD_BUS_WIDTH,
   ext_csd_bits,
   card->ext_csd.generic_cmd6_time,
-  MMC_TIMING_MMC_DDR52,
+  0,
   true, true, true);
if (err) {
pr_err("%s: switch to bus width %d ddr failed\n",
@@ -1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
if (err)
err = __mmc_set_signal_voltage(host,
MMC_SIGNAL_VOLTAGE_330);

+   if (!err)
+   mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
+




Hi,

thank you. This patch solves the problem! :)


Again, from the view of spec, the code is fine.

So I *guess* that seems your host driver doesn't work fine under
DDR52 when it's in 3V3 vccq. But I don't have a real hardware to debug
it.  Could freescale guys help to check it?





Tested-by: Clemens Gruber 

Regards,
Clemens
--
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




--
Best Regards
Shawn Lin

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/6 23:56, Clemens Gruber wrote:

On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff


it shows you always fail to get resp of sending status within the
expected period of time.



[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!


By looking the changes itself, it should be good from the view of spec.
Maybe you could try the patch below, but don't beat me if that doesn't
help at all. :)

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
   EXT_CSD_BUS_WIDTH,
   ext_csd_bits,
   card->ext_csd.generic_cmd6_time,
-  MMC_TIMING_MMC_DDR52,
+  0,
   true, true, true);
if (err) {
pr_err("%s: switch to bus width %d ddr failed\n",
@@ -1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
if (err)
err = __mmc_set_signal_voltage(host,
MMC_SIGNAL_VOLTAGE_330);

+   if (!err)
+   mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
+




Hi,

thank you. This patch solves the problem! :)


Again, from the view of spec, the code is fine.

So I *guess* that seems your host driver doesn't work fine under
DDR52 when it's in 3V3 vccq. But I don't have a real hardware to debug
it.  Could freescale guys help to check it?





Tested-by: Clemens Gruber 

Regards,
Clemens
--
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




--
Best Regards
Shawn Lin

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Clemens Gruber]

On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
> On 2017/1/6 8:41, Clemens Gruber wrote:
> > Hi,
> > 
> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
> > the eMMC on my i.MX6Q board.
> > 
> > Details:
> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
> > eMMC 4.41 features and we did not implement voltage switching from 3.3V
> > to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
> > options) to the device tree. The bus-width is 8.
> > 
> > With 4.9 the board booted fine, now with the current mainline 4.10 tree,
> > I get the following (repeating) errors at boot:
> > 
> > [4.326834] Waiting for root device /dev/mmcblk0p2...
> > [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> > [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
> > [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> > [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> > [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> > [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> > [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> > [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> > [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> > [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> > [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> > [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> > [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> > [   14.639682] sdhci: Host ctl2: 0x
> > [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> > [   14.649447] sdhci: ===
> > 
> > This repeats a few times, then more information is shown at the bottom:
> > 
> > [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> > [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
> > [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> > [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> > [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> > [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> > [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> > [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> > [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> > [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> > [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> > [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> > [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> > [   86.969668] sdhci: Host ctl2: 0x
> > [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> > [   86.979433] sdhci: ===
> > [   86.986356] mmc0: switch to bus width 8 ddr failed
> > [   86.991163] mmc0: error -110 whilst initialising MMC card
> > [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
> > 
> > --
> > 
> > After looking through the latest commits to mmc/core, I found the
> > culprit:
> > Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
> > CMD13 polling policy when switch to HS DDR mode")
> > 
> > Reverting it fixes the problem. But I am unsure if that's the right
> > course of action?
> > 
> > Feel free to send me patches for testing!
> > 
> 
> I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
> code miss a bit, so could you also try this one?
> 
> drivers/mmc/core/mmc_ops.c
> @@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card,
> unsigned int timeout_ms,
> busy = host->ops->card_busy(host);
> } else {
> err = mmc_send_status(card, );
> -   if (retry_crc_err && err == -EILSEQ) {
> +   if (retry_crc_err && (err == -EILSEQ ||
> +   err == -ETIMEDOUT)) {
> busy = true;
> } else if (err) {
> return err;
> 

Hi,

this patch (alone) does not solve the problem. The error message is the
same as before.

But applying both your first patch and this one does work. Is this one
beneficial anyway, even if it does not fix my problem?

Regards,
Clemens

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Clemens Gruber]

On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
> On 2017/1/6 8:41, Clemens Gruber wrote:
> > Hi,
> > 
> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
> > the eMMC on my i.MX6Q board.
> > 
> > Details:
> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
> > eMMC 4.41 features and we did not implement voltage switching from 3.3V
> > to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
> > options) to the device tree. The bus-width is 8.
> > 
> > With 4.9 the board booted fine, now with the current mainline 4.10 tree,
> > I get the following (repeating) errors at boot:
> > 
> > [4.326834] Waiting for root device /dev/mmcblk0p2...
> > [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> > [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
> > [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> > [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> > [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> > [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> > [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> > [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> > [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> > [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> > [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> > [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> > [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> > [   14.639682] sdhci: Host ctl2: 0x
> > [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> > [   14.649447] sdhci: ===
> > 
> > This repeats a few times, then more information is shown at the bottom:
> > 
> > [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> > [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
> > [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> > [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> > [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> > [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> > [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> > [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> > [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> > [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> > [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> > [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> > [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> > [   86.969668] sdhci: Host ctl2: 0x
> > [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> > [   86.979433] sdhci: ===
> > [   86.986356] mmc0: switch to bus width 8 ddr failed
> > [   86.991163] mmc0: error -110 whilst initialising MMC card
> > [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
> > 
> > --
> > 
> > After looking through the latest commits to mmc/core, I found the
> > culprit:
> > Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
> > CMD13 polling policy when switch to HS DDR mode")
> > 
> > Reverting it fixes the problem. But I am unsure if that's the right
> > course of action?
> > 
> > Feel free to send me patches for testing!
> > 
> 
> I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
> code miss a bit, so could you also try this one?
> 
> drivers/mmc/core/mmc_ops.c
> @@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card,
> unsigned int timeout_ms,
> busy = host->ops->card_busy(host);
> } else {
> err = mmc_send_status(card, );
> -   if (retry_crc_err && err == -EILSEQ) {
> +   if (retry_crc_err && (err == -EILSEQ ||
> +   err == -ETIMEDOUT)) {
> busy = true;
> } else if (err) {
> return err;
> 

Hi,

this patch (alone) does not solve the problem. The error message is the
same as before.

But applying both your first patch and this one does work. Is this one
beneficial anyway, even if it does not fix my problem?

Regards,
Clemens

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Clemens Gruber]

On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> On 2017/1/6 8:41, Clemens Gruber wrote:
> > Hi,
> > 
> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
> > the eMMC on my i.MX6Q board.
> > 
> > Details:
> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
> > eMMC 4.41 features and we did not implement voltage switching from 3.3V
> > to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
> > options) to the device tree. The bus-width is 8.
> > 
> > With 4.9 the board booted fine, now with the current mainline 4.10 tree,
> > I get the following (repeating) errors at boot:
> > 
> > [4.326834] Waiting for root device /dev/mmcblk0p2...
> > [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> > [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
> > [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> > [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> > [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> > [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> > [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> > [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> > [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> > [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> > [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> > [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> > [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> 
> it shows you always fail to get resp of sending status within the
> expected period of time.
> 
> 
> > [   14.639682] sdhci: Host ctl2: 0x
> > [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> > [   14.649447] sdhci: ===
> > 
> > This repeats a few times, then more information is shown at the bottom:
> > 
> > [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> > [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
> > [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> > [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> > [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> > [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> > [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> > [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> > [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> > [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> > [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> > [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> > [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> > [   86.969668] sdhci: Host ctl2: 0x
> > [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> > [   86.979433] sdhci: ===
> > [   86.986356] mmc0: switch to bus width 8 ddr failed
> > [   86.991163] mmc0: error -110 whilst initialising MMC card
> > [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
> > 
> > --
> > 
> > After looking through the latest commits to mmc/core, I found the
> > culprit:
> > Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
> > CMD13 polling policy when switch to HS DDR mode")
> > 
> > Reverting it fixes the problem. But I am unsure if that's the right
> > course of action?
> > 
> > Feel free to send me patches for testing!
> 
> By looking the changes itself, it should be good from the view of spec.
> Maybe you could try the patch below, but don't beat me if that doesn't
> help at all. :)
> 
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
>EXT_CSD_BUS_WIDTH,
>ext_csd_bits,
>card->ext_csd.generic_cmd6_time,
> -  MMC_TIMING_MMC_DDR52,
> +  0,
>true, true, true);
> if (err) {
> pr_err("%s: switch to bus width %d ddr failed\n",
> @@ -1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
> if (err)
> err = __mmc_set_signal_voltage(host,
> MMC_SIGNAL_VOLTAGE_330);
> 
> +   if (!err)
> +   mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
> +
> 
> 

Hi,

thank you. This patch solves the problem! :)

Tested-by: Clemens Gruber 

Regards,
Clemens

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Clemens Gruber]

On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> On 2017/1/6 8:41, Clemens Gruber wrote:
> > Hi,
> > 
> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
> > the eMMC on my i.MX6Q board.
> > 
> > Details:
> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
> > eMMC 4.41 features and we did not implement voltage switching from 3.3V
> > to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
> > options) to the device tree. The bus-width is 8.
> > 
> > With 4.9 the board booted fine, now with the current mainline 4.10 tree,
> > I get the following (repeating) errors at boot:
> > 
> > [4.326834] Waiting for root device /dev/mmcblk0p2...
> > [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
> > [   14.569619] sdhci: === REGISTER DUMP (mmc0)===
> > [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
> > [   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> > [   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> > [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> > [   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
> > [   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
> > [   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
> > [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> > [   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
> > [   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> > [   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> 
> it shows you always fail to get resp of sending status within the
> expected period of time.
> 
> 
> > [   14.639682] sdhci: Host ctl2: 0x
> > [   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
> > [   14.649447] sdhci: ===
> > 
> > This repeats a few times, then more information is shown at the bottom:
> > 
> > [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
> > [   86.899615] sdhci: === REGISTER DUMP (mmc0)===
> > [   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
> > [   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
> > [   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
> > [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
> > [   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
> > [   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
> > [   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
> > [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
> > [   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
> > [   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
> > [   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
> > [   86.969668] sdhci: Host ctl2: 0x
> > [   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
> > [   86.979433] sdhci: ===
> > [   86.986356] mmc0: switch to bus width 8 ddr failed
> > [   86.991163] mmc0: error -110 whilst initialising MMC card
> > [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
> > 
> > --
> > 
> > After looking through the latest commits to mmc/core, I found the
> > culprit:
> > Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
> > CMD13 polling policy when switch to HS DDR mode")
> > 
> > Reverting it fixes the problem. But I am unsure if that's the right
> > course of action?
> > 
> > Feel free to send me patches for testing!
> 
> By looking the changes itself, it should be good from the view of spec.
> Maybe you could try the patch below, but don't beat me if that doesn't
> help at all. :)
> 
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
>EXT_CSD_BUS_WIDTH,
>ext_csd_bits,
>card->ext_csd.generic_cmd6_time,
> -  MMC_TIMING_MMC_DDR52,
> +  0,
>true, true, true);
> if (err) {
> pr_err("%s: switch to bus width %d ddr failed\n",
> @@ -1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
> if (err)
> err = __mmc_set_signal_voltage(host,
> MMC_SIGNAL_VOLTAGE_330);
> 
> +   if (!err)
> +   mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
> +
> 
> 

Hi,

thank you. This patch solves the problem! :)

Tested-by: Clemens Gruber 

Regards,
Clemens

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!



I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
code miss a bit, so could you also try this one?

drivers/mmc/core/mmc_ops.c
@@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card, 
unsigned int timeout_ms,

busy = host->ops->card_busy(host);
} else {
err = mmc_send_status(card, );
-   if (retry_crc_err && err == -EILSEQ) {
+   if (retry_crc_err && (err == -EILSEQ ||
+   err == -ETIMEDOUT)) {
busy = true;
} else if (err) {
return err;





Regards,
Clemens
--
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




--
Best Regards
Shawn Lin

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!



I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
code miss a bit, so could you also try this one?

drivers/mmc/core/mmc_ops.c
@@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card, 
unsigned int timeout_ms,

busy = host->ops->card_busy(host);
} else {
err = mmc_send_status(card, );
-   if (retry_crc_err && err == -EILSEQ) {
+   if (retry_crc_err && (err == -EILSEQ ||
+   err == -ETIMEDOUT)) {
busy = true;
} else if (err) {
return err;





Regards,
Clemens
--
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




--
Best Regards
Shawn Lin

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff


it shows you always fail to get resp of sending status within the
expected period of time.



[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!


By looking the changes itself, it should be good from the view of spec.
Maybe you could try the patch below, but don't beat me if that doesn't
help at all. :)

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
   EXT_CSD_BUS_WIDTH,
   ext_csd_bits,
   card->ext_csd.generic_cmd6_time,
-  MMC_TIMING_MMC_DDR52,
+  0,
   true, true, true);
if (err) {
pr_err("%s: switch to bus width %d ddr failed\n",
@@ -1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
if (err)
err = __mmc_set_signal_voltage(host, 
MMC_SIGNAL_VOLTAGE_330);


+   if (!err)
+   mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
+





Regards,
Clemens
--
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




--
Best Regards
Shawn Lin

Re: eMMC boot problem: switch to bus width 8 ddr failed

[Shawn Lin]

On 2017/1/6 8:41, Clemens Gruber wrote:

Hi,

with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.

Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
options) to the device tree. The bus-width is 8.

With 4.9 the board booted fine, now with the current mainline 4.10 tree,
I get the following (repeating) errors at boot:

[4.326834] Waiting for root device /dev/mmcblk0p2...
[   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
[   14.569619] sdhci: === REGISTER DUMP (mmc0)===
[   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x0002
[   14.581300] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   14.587140] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   14.598816] sdhci: Power:0x0002 | Blk gap:  0x0080
[   14.604654] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   14.610493] sdhci: Timeout:  0x008f | Int stat: 0x
[   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   14.622168] sdhci: AC12 err: 0x | Slot int: 0x0003
[   14.628007] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   14.633845] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff


it shows you always fail to get resp of sending status within the
expected period of time.



[   14.639682] sdhci: Host ctl2: 0x
[   14.643611] sdhci: ADMA Err: 0x | ADMA Ptr: 0x4e6f7208
[   14.649447] sdhci: ===

This repeats a few times, then more information is shown at the bottom:

[   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
[   86.899615] sdhci: === REGISTER DUMP (mmc0)===
[   86.905453] sdhci: Sys addr: 0x | Version:  0x0002
[   86.911291] sdhci: Blk size: 0x0200 | Blk cnt:  0x0001
[   86.917129] sdhci: Argument: 0x0001 | Trn mode: 0x0013
[   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x0031
[   86.928804] sdhci: Power:0x0002 | Blk gap:  0x0080
[   86.934642] sdhci: Wake-up:  0x0008 | Clock:0x001f
[   86.940479] sdhci: Timeout:  0x008f | Int stat: 0x
[   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
[   86.952154] sdhci: AC12 err: 0x | Slot int: 0x0003
[   86.957992] sdhci: Caps: 0x07eb | Caps_1:   0xa007
[   86.963830] sdhci: Cmd:  0x0d1a | Max curr: 0x00ff
[   86.969668] sdhci: Host ctl2: 0x
[   86.973596] sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[   86.979433] sdhci: ===
[   86.986356] mmc0: switch to bus width 8 ddr failed
[   86.991163] mmc0: error -110 whilst initialising MMC card
[   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.

--

After looking through the latest commits to mmc/core, I found the
culprit:
Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
CMD13 polling policy when switch to HS DDR mode")

Reverting it fixes the problem. But I am unsure if that's the right
course of action?

Feel free to send me patches for testing!


By looking the changes itself, it should be good from the view of spec.
Maybe you could try the patch below, but don't beat me if that doesn't
help at all. :)

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1074,7 +1074,7 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
   EXT_CSD_BUS_WIDTH,
   ext_csd_bits,
   card->ext_csd.generic_cmd6_time,
-  MMC_TIMING_MMC_DDR52,
+  0,
   true, true, true);
if (err) {
pr_err("%s: switch to bus width %d ddr failed\n",
@@ -1118,6 +1118,9 @@ static int mmc_select_hs_ddr(struct mmc_card *card)
if (err)
err = __mmc_set_signal_voltage(host, 
MMC_SIGNAL_VOLTAGE_330);


+   if (!err)
+   mmc_set_timing(host, MMC_TIMING_MMC_DDR52);
+





Regards,
Clemens
--
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




--
Best Regards
Shawn Lin