All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaehoon Chung <jh80.chung@samsung.com>
To: Alim Akhtar <alim.akhtar@gmail.com>,
	Doug Anderson <dianders@chromium.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Seungwon Jeon <tgih.jun@samsung.com>,
	Addy Ke <addy.ke@rock-chips.com>,
	Sonny Rao <sonnyrao@chromium.org>,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Andrew Bresticker <abrestic@chromium.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: Remove old card detect infrastructure
Date: Mon, 20 Oct 2014 12:23:15 +0900	[thread overview]
Message-ID: <54448023.1050008@samsung.com> (raw)
In-Reply-To: <CAGOxZ51x8cd9XmNg49aaUdZQkw-hhEA-mC=34ZSjLf0XF8Zbvw@mail.gmail.com>

Hi.

On 10/17/2014 09:44 PM, Alim Akhtar wrote:
> Hi Doug,
> 
> On Thu, Oct 16, 2014 at 9:40 PM, Doug Anderson <dianders@chromium.org> wrote:
>> Alim,
>>
>> On Thu, Oct 16, 2014 at 5:57 AM, Alim Akhtar <alim.akhtar@gmail.com> wrote:
>>> Hi Doug,
>>>
>>> On Tue, Oct 14, 2014 at 10:03 PM, Doug Anderson <dianders@chromium.org> wrote:
>>>> The dw_mmc driver had a bunch of code that ran whenever a card was
>>>> ejected and inserted.  However, this code was old and crufty and
>>>> should be removed.  Some evidence that it's really not needed:
>>>>
>>>> 1. Is is supposed to be legal to use 'cd-gpio' on dw_mmc instead of
>>>>    using the built-in card detect mechanism.  The 'cd-gpio' code
>>>>    doesn't run any of the crufty old code but yet still works.
>>>>
>>>> 2. While looking at this, I realized that my old change (369ac86 mmc:
>>>>    dw_mmc: don't queue up a card detect at slot startup) actually
>>>>    castrated the old code a little bit already and nobody noticed.
>>>>    Specifically "last_detect_state" was left as 0 at bootup.  That
>>>>    means that on the first card removal none of the crufty code ran.
>>>>
>>> Yes, right most of these codes are _almost_ never call. But I see
>>> dw_mci_reset() being called on card removal (after first
>>> insert/removal).
>>
>> Right.  The old crufty code was called on the 2nd removal, not the
>> 1st.  That meant that the two were accidentally different.  My point
>> was that if the old code was really required that someone would have
>> noticed crashes on the 1st removal after each boot.  Since nobody is
>> reporting crashes with that then it means it can't be too terrible.
>>
>> One thing to note: I remember in the last Chromebook project you were
>> trying to track down crashes associated with constant eject / insert
>> of SD Cards.  I wonder if my patch will fix these crashes?
>>
> Ah, yes, reproducing that and checking with this patch will be really
> interesting.
> 
>>
>>> I tested this on exynos5800 and this looks working fine. We need to
>>> test once cross suspend/resume as well.
>>
>> Good idea.  Can you test that?  I know that there's been lots of flux
>> with suspend/resume on exynos and I'm not sure I have all the latest
>> patches, but I'll search for them if you are unable to test easily.
>>
> Sure, I will do that..but probably sometime next week, as I will out
> of office for few days.
>>
>>> And as Jaehoon pointed out,probably lets look in TRM if there are some
>>> recommended  steps for cd-detect.
>>> Otherwise this looks good to me.
>>
>> If you see some other requirement than the one I addressed in my email
>> to Jaehoon, please let me know.

I know there is no other requirement for detecting card. 
So this patch can be applied after testing the above case(suspend/resume).

Best Regards,
Jaehoon Chung

>>
> Well, as most of the current CD detect code are dead code, so lets see
> more test results, specially across a suspend/resume and warm reboot
> test and take this forward.
>>
>> -Doug
> 
> 
> 


  reply	other threads:[~2014-10-20  3:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-14 16:33 [PATCH] mmc: dw_mmc: Remove old card detect infrastructure Doug Anderson
2014-10-16  8:19 ` Jaehoon Chung
2014-10-16  9:38   ` Jaehoon Chung
2014-10-16 16:05     ` Doug Anderson
2014-10-16 12:57 ` Alim Akhtar
2014-10-16 16:10   ` Doug Anderson
2014-10-17 12:44     ` Alim Akhtar
2014-10-20  3:23       ` Jaehoon Chung [this message]
2014-10-22 16:36         ` Doug Anderson
2014-10-23  1:13           ` Jaehoon Chung
2014-10-23 12:43           ` Alim Akhtar
2014-10-27 15:42 ` Ulf Hansson

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=54448023.1050008@samsung.com \
    --to=jh80.chung@samsung.com \
    --cc=abrestic@chromium.org \
    --cc=addy.ke@rock-chips.com \
    --cc=alim.akhtar@gmail.com \
    --cc=alim.akhtar@samsung.com \
    --cc=chris@printf.net \
    --cc=dianders@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.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.