From: Shawn Lin <shawn.lin@rock-chips.com>
To: Doug Anderson <dianders@chromium.org>
Cc: shawn.lin@rock-chips.com, Jaehoon Chung <jh80.chung@samsung.com>,
Seungwon Jeon <tgih.jun@samsung.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
Sonny Rao <sonnyrao@chromium.org>,
Heiko Stuebner <heiko@sntech.de>,
Alexandru Stan <amstan@chromium.org>,
Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors
Date: Wed, 18 May 2016 17:14:43 +0800 [thread overview]
Message-ID: <573C3283.1040606@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=VneQR3wurjezBkRhtQiH+q-FfhDN8=Ym=XqtZpVmsdUw@mail.gmail.com>
Hi
On 2016-5-18 12:12, Doug Anderson wrote:
> Hi,
>
> On Tue, May 17, 2016 at 6:59 PM, Shawn Lin
> <shawn.lin@kernel-upstream.org> wrote:
>> Could you try this patch to see if you can still find HLE?
>>
>> @@ -2356,12 +2356,22 @@ static void dw_mci_cmd_interrupt(struct dw_mci
>> *host, u32 status)
>> static void dw_mci_handle_cd(struct dw_mci *host)
>> {
>> int i;
>> + int present;
>>
>> for (i = 0; i < host->num_slots; i++) {
>> struct dw_mci_slot *slot = host->slot[i];
>>
>> if (!slot)
>> continue;
>>
>> + present = !(mci_readl(slot->host, CDETECT) & (1 <<
>> slot->id));
>> + if (present)
>> + set_bit(DW_MMC_CARD_PRESENT, &slot->flags);
>> + else
>> + clear_bit(DW_MMC_CARD_PRESENT, &slot->flags);
>
> No, because we don't use the builtin card detect on veyron. ;)
>
> We use GPIO card detect because we didn't like the way JTAG and SD
> interacted. Also on rk3288 the builtin card detect line had the wrong
> voltage domain (you couldn't detect a card when the IO lines were
> powered off). The builtin card detect line is always driven low on
> veyron.
Okay, I see.
>
>
> I'm nearly certain that the root cause of my HLE errors is actually
> related to the same problem addressed by the commit 7c5209c315ea
> ("mmc: core: Increase delay for voltage to stabilize from 3.3V to
> 1.8V"). I think that on minnie we're still on the hairy edge and
> sometimes the line doesn't transition fast enough.
Things are not so simple from your details.
I was not enabling SD3.0 support, then I also found HLE sometimes.
So it seems commit 7c5209c315ea does not contibute to this phenomenon.
The scenario looks like:
remove sd-card -> mmc_sd_detect -> send status(CMD13) ->power_off ->
set_ios -> setup_bus -> disabled clk , then HLE irq storm coming
From the code of dw_mci_prepare_command:
SDMMC_CMD_PRV_DAT_WAIT will not be used for CMD13, so we don't
wait_busy here, then cmd code is loding into queue of dw_mmc but
still failing send out because it's in busy?
With my patch, things go well:
remove sd-card -> clear bit of DW_MMC_CARD_PRESENT -> send
status(CMD13) return directly -> power_off -> set_ios -> setup_bus ->
disable clk
So why should we allow inquiry of card status if we sure the card is
removed? I mean no any further cmds should be delivered.
And another question: should we wait busy for cmd13?
>
> It appears that increasing this to 30ms avoids the HLE errors.
>
> I _think_ I can actually fully fix this properly by temporarily
> engaging the internal pull-ups while the voltage switch is happening.
> This will bleed away the voltage just a little bit faster (since lines
> are driven low here). I'll try to confirm that.
>
>
> In any case, it seems like we should take this patch since (without
> this patch) the failure case when you get HLE errors is that the
> interrupt controller fires over and over again (with no printouts) and
> your system stalls with no error messages.
Sure, at least we need to address this irq storm...
>
> -Doug
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: shawn.lin@rock-chips.com (Shawn Lin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors
Date: Wed, 18 May 2016 17:14:43 +0800 [thread overview]
Message-ID: <573C3283.1040606@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=VneQR3wurjezBkRhtQiH+q-FfhDN8=Ym=XqtZpVmsdUw@mail.gmail.com>
Hi
On 2016-5-18 12:12, Doug Anderson wrote:
> Hi,
>
> On Tue, May 17, 2016 at 6:59 PM, Shawn Lin
> <shawn.lin@kernel-upstream.org> wrote:
>> Could you try this patch to see if you can still find HLE?
>>
>> @@ -2356,12 +2356,22 @@ static void dw_mci_cmd_interrupt(struct dw_mci
>> *host, u32 status)
>> static void dw_mci_handle_cd(struct dw_mci *host)
>> {
>> int i;
>> + int present;
>>
>> for (i = 0; i < host->num_slots; i++) {
>> struct dw_mci_slot *slot = host->slot[i];
>>
>> if (!slot)
>> continue;
>>
>> + present = !(mci_readl(slot->host, CDETECT) & (1 <<
>> slot->id));
>> + if (present)
>> + set_bit(DW_MMC_CARD_PRESENT, &slot->flags);
>> + else
>> + clear_bit(DW_MMC_CARD_PRESENT, &slot->flags);
>
> No, because we don't use the builtin card detect on veyron. ;)
>
> We use GPIO card detect because we didn't like the way JTAG and SD
> interacted. Also on rk3288 the builtin card detect line had the wrong
> voltage domain (you couldn't detect a card when the IO lines were
> powered off). The builtin card detect line is always driven low on
> veyron.
Okay, I see.
>
>
> I'm nearly certain that the root cause of my HLE errors is actually
> related to the same problem addressed by the commit 7c5209c315ea
> ("mmc: core: Increase delay for voltage to stabilize from 3.3V to
> 1.8V"). I think that on minnie we're still on the hairy edge and
> sometimes the line doesn't transition fast enough.
Things are not so simple from your details.
I was not enabling SD3.0 support, then I also found HLE sometimes.
So it seems commit 7c5209c315ea does not contibute to this phenomenon.
The scenario looks like:
remove sd-card -> mmc_sd_detect -> send status(CMD13) ->power_off ->
set_ios -> setup_bus -> disabled clk , then HLE irq storm coming
From the code of dw_mci_prepare_command:
SDMMC_CMD_PRV_DAT_WAIT will not be used for CMD13, so we don't
wait_busy here, then cmd code is loding into queue of dw_mmc but
still failing send out because it's in busy?
With my patch, things go well:
remove sd-card -> clear bit of DW_MMC_CARD_PRESENT -> send
status(CMD13) return directly -> power_off -> set_ios -> setup_bus ->
disable clk
So why should we allow inquiry of card status if we sure the card is
removed? I mean no any further cmds should be delivered.
And another question: should we wait busy for cmd13?
>
> It appears that increasing this to 30ms avoids the HLE errors.
>
> I _think_ I can actually fully fix this properly by temporarily
> engaging the internal pull-ups while the voltage switch is happening.
> This will bleed away the voltage just a little bit faster (since lines
> are driven low here). I'll try to confirm that.
>
>
> In any case, it seems like we should take this patch since (without
> this patch) the failure case when you get HLE errors is that the
> interrupt controller fires over and over again (with no printouts) and
> your system stalls with no error messages.
Sure, at least we need to address this irq storm...
>
> -Doug
>
>
>
next prev parent reply other threads:[~2016-05-18 9:15 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-10 15:48 [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors Doug Anderson
2015-03-10 15:48 ` Doug Anderson
2015-03-13 11:30 ` Jaehoon Chung
2015-03-13 11:30 ` Jaehoon Chung
2015-03-13 20:27 ` Doug Anderson
2015-03-13 20:27 ` Doug Anderson
2015-03-16 5:56 ` Jaehoon Chung
2015-03-16 5:56 ` Jaehoon Chung
2015-03-30 0:55 ` Jaehoon Chung
2015-03-30 0:55 ` Jaehoon Chung
2015-03-30 15:47 ` Doug Anderson
2015-03-30 15:47 ` Doug Anderson
2016-05-18 0:47 ` Doug Anderson
2016-05-18 0:47 ` Doug Anderson
2016-05-18 1:59 ` Shawn Lin
2016-05-18 1:59 ` Shawn Lin
2016-05-18 4:12 ` Doug Anderson
2016-05-18 4:12 ` Doug Anderson
2016-05-18 9:14 ` Shawn Lin [this message]
2016-05-18 9:14 ` Shawn Lin
2016-05-18 17:37 ` Doug Anderson
2016-05-18 17:37 ` Doug Anderson
2016-05-18 18:01 ` Heiko Stuebner
2016-05-18 18:01 ` Heiko Stuebner
2016-05-19 11:31 ` Shawn Lin
2016-05-19 11:31 ` Shawn Lin
2016-05-19 13:07 ` Jaehoon Chung
2016-05-19 13:07 ` Jaehoon Chung
2016-05-26 2:23 ` Shawn Lin
2016-05-26 2:23 ` Shawn Lin
2016-05-26 3:59 ` Jaehoon Chung
2016-05-26 3:59 ` Jaehoon Chung
2016-05-26 4:07 ` Shawn Lin
2016-05-26 4:07 ` Shawn Lin
2016-05-18 2:08 ` Jaehoon Chung
2016-05-18 2:08 ` Jaehoon Chung
2016-05-18 4:13 ` Doug Anderson
2016-05-18 4:13 ` Doug Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=573C3283.1040606@rock-chips.com \
--to=shawn.lin@rock-chips.com \
--cc=alim.akhtar@samsung.com \
--cc=amstan@chromium.org \
--cc=dianders@chromium.org \
--cc=heiko@sntech.de \
--cc=javier.martinez@collabora.co.uk \
--cc=jh80.chung@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=sonnyrao@chromium.org \
--cc=tgih.jun@samsung.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.