LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jaehoon Chung <jh80.chung@samsung.com>
To: Jaehoon Chung <jh80.chung@samsung.com>,
	Doug Anderson <dianders@chromium.org>
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: Mon, 30 Mar 2015 09:55:32 +0900	[thread overview]
Message-ID: <55189F04.8000404@samsung.com> (raw)
In-Reply-To: <5506707D.40708@samsung.com>

Dear Doug,

I'm considering to control HLE error..So holding this patch.
If this is absolutely necessary patch, let me know, plz.

Best Regards,
Jaehoon Chung

On 03/16/2015 02:56 PM, Jaehoon Chung wrote:
> Hi, Doug.
> 
> On 03/14/2015 05:27 AM, Doug Anderson wrote:
>> 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.
> 
> When card is inserting/removing, HLE is often occurred.
> Since there is some request into queue when card is removed.(in my understanding.)
> It's also related with controlling clock.
> 
>>
>>> 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...
> 
> Agreed, your patch should be at least better than now.
> But if pending is set HLE error bit,
> it should hit the cases of DW_MCI_DATA_ERROR_FLAGS & DW_MCI_CMD_ERROR_FLAGS.
> and i think send_stop_abort() can't run, doesn't?
> (If HLE is occurred at non-removable card, controller can't do anything.)
> 
> If i can reproduce HLE error, i can check more detailedly.(Trying to reproduce it.)
> I don't find fully solution yet. But finding the solution is my or our(?) part/role in future.
> Actually, i'm using the ctrl reset at my local tree, when HLE error is occurred.
> (Also it's not solution..)
> According to TRM, "HLE is raised, software then has to reload the command."
> We needs to consider how reload the command without lost previous request.
> 
>>
>> If you have another suggested way to make HLE error handling better
>> (or avoid them to begin with) I'm happy to test!  :)
> 
> I will try to find HLE error handling..if you also have other opinion, let me know, plz.
> I needs to listen other opinion, it's great helpful to me.. :)
> 
> Thank you a lot!
> 
> Best Regards,
> Jaehoon Chung
> 
>>
>>
>> -Doug
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  reply	other threads:[~2015-03-30  0:55 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
2015-03-16  5:56     ` Jaehoon Chung
2015-03-30  0:55       ` Jaehoon Chung [this message]
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=55189F04.8000404@samsung.com \
    --to=jh80.chung@samsung.com \
    --cc=abrestic@chromium.org \
    --cc=addy.ke@rock-chips.com \
    --cc=alim.akhtar@samsung.com \
    --cc=amstan@chromium.org \
    --cc=chris@printf.net \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=javier.martinez@collabora.co.uk \
    --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).