LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Seungwon Jeon <tgih.jun@samsung.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Sonny Rao <sonnyrao@chromium.org>,
	Andrew Bresticker <abrestic@chromium.org>,
	Heiko Stuebner <heiko@sntech.de>,
	Addy Ke <addy.ke@rock-chips.com>,
	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>,
	Chris Ball <chris@printf.net>,
	"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: Fri, 13 Mar 2015 13:27:58 -0700	[thread overview]
Message-ID: <CAD=FV=VX3ix-j4y95W1q8b-aVuVEN+4xsd8WLx2xcE7KPNJwRw@mail.gmail.com> (raw)
In-Reply-To: <5502CA4E.9060401@samsung.com>

Hi,

On Fri, Mar 13, 2015 at 4:30 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote:
> Hi, Doug.
>
> On 03/11/2015 12:48 AM, Doug Anderson wrote:
>> The dw_mmc driver enables HLE errors as part of DW_MCI_ERROR_FLAGS but
>> nothing in the interrupt handler actually handles them and ACKs them.
>> That means that if we ever get an HLE error we'll just keep getting
>> interrupts and we'll wedge things.
>>
>> We really don't expect HLE errors but if we ever get them we shouldn't
>> silently ignore them.
>>
>> Note that I have seen HLE errors while constantly ejecting and
>> inserting cards (ejecting while inserting, etc).
>
> Right, It is occurred when card inserting/ejecting.(This case is the case of removable card.)
> Did you test with eMMC? We needs to consider how control HLE error.

I'm running it on systems with eMMC, SD Cards, and SDIO WiFi.  HLE
doesn't show up in normal circumstances, only in ejecting the SD card
at the wrong time.  ...since you can't eject eMMC, I didn't see
problems there.

> But I think this patch can't solve all of HLE problem.

Agreed.  HLE means that the controller is pretty wedged and (as I
understand it) means that there's something else we're doing wrong
elsewhere in the dw_mmc driver (like writing more data to an already
busy controller).  We should probably track down and find those cases,
too.

I agree also that this code probably won't fix the controller in all
cases of HLE errors.  ...but I'm not 100% certain of the best way to
really do that, do you know?

...but in any case the absolute worst thing to do is what the driver
is already doing: unmask the HLE interrupt but never handle it
anywhere...  My patch is at least better than that...

If you have another suggested way to make HLE error handling better
(or avoid them to begin with) I'm happy to test!  :)


-Doug

  reply	other threads:[~2015-03-13 20:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10 15:48 Doug Anderson
2015-03-13 11:30 ` Jaehoon Chung
2015-03-13 20:27   ` Doug Anderson [this message]
2015-03-16  5:56     ` Jaehoon Chung
2015-03-30  0:55       ` Jaehoon Chung
2015-03-30 15:47         ` Doug Anderson
2016-05-18  0:47           ` Doug Anderson
2016-05-18  1:59             ` Shawn Lin
2016-05-18  4:12               ` Doug Anderson
2016-05-18  9:14                 ` Shawn Lin
2016-05-18 17:37                   ` Doug Anderson
2016-05-18 18:01                     ` Heiko Stuebner
2016-05-19 11:31                     ` Shawn Lin
2016-05-19 13:07                       ` Jaehoon Chung
2016-05-26  2:23                         ` Shawn Lin
2016-05-26  3:59                           ` Jaehoon Chung
2016-05-26  4:07                             ` Shawn Lin
2016-05-18  2:08             ` Jaehoon Chung
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='CAD=FV=VX3ix-j4y95W1q8b-aVuVEN+4xsd8WLx2xcE7KPNJwRw@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=abrestic@chromium.org \
    --cc=addy.ke@rock-chips.com \
    --cc=alim.akhtar@samsung.com \
    --cc=amstan@chromium.org \
    --cc=chris@printf.net \
    --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 \
    --subject='Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).