All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Doug Anderson <dianders@chromium.org>
Cc: "Jaehoon Chung" <jh80.chung@samsung.com>,
	"Seungwon Jeon" <tgih.jun@samsung.com>,
	"Alim Akhtar" <alim.akhtar@samsung.com>,
	"Sonny Rao" <sonnyrao@chromium.org>,
	"Andrew Bresticker" <abrestic@chromium.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	"H Hartley Sweeten" <hsweeten@visionengravers.com>,
	"Tony Lindgren" <tony@atomide.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Wolfram Sang" <wsa@the-dreams.de>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Chris Ball" <chris@printf.net>,
	"Grégory Soutadé" <gsoutade@neotion.com>,
	"Joe Perches" <joe@perches.com>, "Axel Lin" <axel.lin@ingics.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc
Date: Tue, 30 Dec 2014 11:29:10 +0100	[thread overview]
Message-ID: <CAPDyKFqGW2NaN+5mUrpBWrhM5ZfUSx70-Yyk9qmNaC1ft_ibpw@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=UCyOXfMqu_MYbd5pKOpgXPB87LQ7hCegeeY9vzsy6QAg@mail.gmail.com>

On 19 December 2014 at 20:02, Doug Anderson <dianders@chromium.org> wrote:
> Ulf,
>
> On Fri, Dec 19, 2014 at 2:17 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> On 3 December 2014 at 00:42, Doug Anderson <dianders@chromium.org> wrote:
>>> Bing Zhao at Marvell found a problem with dw_mmc where interrupts
>>> weren't firing sometimes.  He tracked it down to a read-modify-write
>>> problem with the INTMASK.  These patches fix the problem.
>>>
>>> Note: I've picked up a > 1-year old series here to make another
>>> attempt at landing it upstream.  These patches have been in shipping
>>> Chromebooks for the last year.  Note that v3 to v4 has no changes
>>> other than a rebase and a small commit message update.
>>>
>>> The first two patches extend the "init_card()" mechanism of MMC core
>>> to actually be called for all card types, not just SDIO.  That could
>>> be applied any time and should fix at least one longstanding bug
>>> (untested).
>>>
>>> The third patch is a cleanup patch to use init_card() to move things
>>> around a bit so we don't need to handle SDIO cards in such a strange
>>> place.  On earlier versions of this patch Seungwon brought up a few
>>> points which I have _not_ addressed.  See
>>> <https://patchwork.kernel.org/patch/3049071/>.  Other than talk of
>>> cards with out of band interrupts maybe being able to gate their
>>> clocks, he wanted to use MMC_QUIRK_BROKEN_CLK_GATING.  I didn't do
>>> that because of the ordering of init_card() and when the quirks are
>>> set.  Some users of init_card() like pandora_wl1251_init_card() rely
>>> on it being called very early in the process.
>>> pandora_wl1251_init_card() hardcodes a vendor and device and thus need
>>> to be called super early.  On the other hand the code that adds quirks
>>> _reads_ the vendor and device.  It can't possibly move before
>>> init_card().  If folks are willing to take an additional host op of
>>> init_card_late() I can certainly go that way, though.
>>>
>>> The fourth patch is (I think) reviewed and ready to go assuming the
>>> other two land.
>>
>> I have queued this up for 3.20.
>
> Thanks!
>
>
>> It was a bit hard to follow the
>> updated the revisions, please don't send patches "in-reply-to" for
>> future sets.
>
> Very strange.  I didn't send out anything in-reply-to other than what
> git-send-email usually does.  I believe I had:
>
> [0] - no in reply to.
>  [1] - in reply to [0]
>  [2] - in reply to [0]
>  [3] - in reply to [0]
>  [4] - in reply to [0]

That's good. As long as there are no in-reply to previous versions of
patches/patchsets.

I am using gmails web-based client so it could very well be that it
does some magic, which I am not yet aware of.

>
> Is there some other way you'd prefer?
>
> Looking full headers in <https://patchwork.kernel.org/patch/5425241/>,
> I confirm it is "in-reply-to"
> "1417563767-32181-1-git-send-email-dianders@chromium.org".  Patchwork
> doesn't keep cover letters, but you can see at
> <http://www.spinics.net/lists/linux-mmc/msg29699.html>) that there is
> no in-reply-to.
>
> I'm more than happy to adjust my workflow if you can give me some
> specifics.  Thanks!  :)
>
>
>> In v5, I don't find a patch 1/4. Anyway, I have taken patch 2->4.
>
> Ah, maybe because it wasn't sent to linux-mmc?  I messed that up and
> will try to do better in the future.  Sorry.  :(  You were in the To
> line, though.  You can see at
> <https://patchwork.kernel.org/patch/5425241/>.
>
> Do you want me to repost it and CC linux-mmc with Tony's Ack?

I suggest you have a look at my next branch and to verify that I
haven't screwed things up. If so, either I should drop the patches and
you make a resend or if it's possible to just send an incremental path
on top?

Kind regards
Uffe

>
> ---
>
> Note: patchwork seems to find all my patches:
>
> pwclient list -w dianders@chromium.org -p ""
>
> 5425241 New          [v5,1/4] ARM: OMAP2+: Make sure
> pandora_wl1251_init_card() applies to SDIO only
> 5425291 New          [v5,1/4] ARM: OMAP2+: Make sure
> pandora_wl1251_init_card() applies to SDIO only
> 5425311 New          [v5,1/4] ARM: OMAP2+: Make sure
> pandora_wl1251_init_card() applies to SDIO only
> 5425231 New          [v5,2/4] mmc: core: Support the optional
> init_card() callback for MMC and SD
> 5425301 New          [v5,2/4] mmc: core: Support the optional
> init_card() callback for MMC and SD
> 5425271 New          [v5,3/4] mmc: dw_mmc: Cleanup disable of low
> power mode w/ SDIO interrupts
> 5425281 New          [v5,3/4] mmc: dw_mmc: Cleanup disable of low
> power mode w/ SDIO interrupts
> 5425251 New          [v5,4/4] mmc: dw_mmc: Protect read-modify-write
> of INTMASK with a lock
> 5425261 New          [v5,4/4] mmc: dw_mmc: Protect read-modify-write
> of INTMASK with a lock

WARNING: multiple messages have this Message-ID (diff)
From: ulf.hansson@linaro.org (Ulf Hansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc
Date: Tue, 30 Dec 2014 11:29:10 +0100	[thread overview]
Message-ID: <CAPDyKFqGW2NaN+5mUrpBWrhM5ZfUSx70-Yyk9qmNaC1ft_ibpw@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=UCyOXfMqu_MYbd5pKOpgXPB87LQ7hCegeeY9vzsy6QAg@mail.gmail.com>

On 19 December 2014 at 20:02, Doug Anderson <dianders@chromium.org> wrote:
> Ulf,
>
> On Fri, Dec 19, 2014 at 2:17 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> On 3 December 2014 at 00:42, Doug Anderson <dianders@chromium.org> wrote:
>>> Bing Zhao at Marvell found a problem with dw_mmc where interrupts
>>> weren't firing sometimes.  He tracked it down to a read-modify-write
>>> problem with the INTMASK.  These patches fix the problem.
>>>
>>> Note: I've picked up a > 1-year old series here to make another
>>> attempt at landing it upstream.  These patches have been in shipping
>>> Chromebooks for the last year.  Note that v3 to v4 has no changes
>>> other than a rebase and a small commit message update.
>>>
>>> The first two patches extend the "init_card()" mechanism of MMC core
>>> to actually be called for all card types, not just SDIO.  That could
>>> be applied any time and should fix at least one longstanding bug
>>> (untested).
>>>
>>> The third patch is a cleanup patch to use init_card() to move things
>>> around a bit so we don't need to handle SDIO cards in such a strange
>>> place.  On earlier versions of this patch Seungwon brought up a few
>>> points which I have _not_ addressed.  See
>>> <https://patchwork.kernel.org/patch/3049071/>.  Other than talk of
>>> cards with out of band interrupts maybe being able to gate their
>>> clocks, he wanted to use MMC_QUIRK_BROKEN_CLK_GATING.  I didn't do
>>> that because of the ordering of init_card() and when the quirks are
>>> set.  Some users of init_card() like pandora_wl1251_init_card() rely
>>> on it being called very early in the process.
>>> pandora_wl1251_init_card() hardcodes a vendor and device and thus need
>>> to be called super early.  On the other hand the code that adds quirks
>>> _reads_ the vendor and device.  It can't possibly move before
>>> init_card().  If folks are willing to take an additional host op of
>>> init_card_late() I can certainly go that way, though.
>>>
>>> The fourth patch is (I think) reviewed and ready to go assuming the
>>> other two land.
>>
>> I have queued this up for 3.20.
>
> Thanks!
>
>
>> It was a bit hard to follow the
>> updated the revisions, please don't send patches "in-reply-to" for
>> future sets.
>
> Very strange.  I didn't send out anything in-reply-to other than what
> git-send-email usually does.  I believe I had:
>
> [0] - no in reply to.
>  [1] - in reply to [0]
>  [2] - in reply to [0]
>  [3] - in reply to [0]
>  [4] - in reply to [0]

That's good. As long as there are no in-reply to previous versions of
patches/patchsets.

I am using gmails web-based client so it could very well be that it
does some magic, which I am not yet aware of.

>
> Is there some other way you'd prefer?
>
> Looking full headers in <https://patchwork.kernel.org/patch/5425241/>,
> I confirm it is "in-reply-to"
> "1417563767-32181-1-git-send-email-dianders at chromium.org".  Patchwork
> doesn't keep cover letters, but you can see at
> <http://www.spinics.net/lists/linux-mmc/msg29699.html>) that there is
> no in-reply-to.
>
> I'm more than happy to adjust my workflow if you can give me some
> specifics.  Thanks!  :)
>
>
>> In v5, I don't find a patch 1/4. Anyway, I have taken patch 2->4.
>
> Ah, maybe because it wasn't sent to linux-mmc?  I messed that up and
> will try to do better in the future.  Sorry.  :(  You were in the To
> line, though.  You can see at
> <https://patchwork.kernel.org/patch/5425241/>.
>
> Do you want me to repost it and CC linux-mmc with Tony's Ack?

I suggest you have a look at my next branch and to verify that I
haven't screwed things up. If so, either I should drop the patches and
you make a resend or if it's possible to just send an incremental path
on top?

Kind regards
Uffe

>
> ---
>
> Note: patchwork seems to find all my patches:
>
> pwclient list -w dianders at chromium.org -p ""
>
> 5425241 New          [v5,1/4] ARM: OMAP2+: Make sure
> pandora_wl1251_init_card() applies to SDIO only
> 5425291 New          [v5,1/4] ARM: OMAP2+: Make sure
> pandora_wl1251_init_card() applies to SDIO only
> 5425311 New          [v5,1/4] ARM: OMAP2+: Make sure
> pandora_wl1251_init_card() applies to SDIO only
> 5425231 New          [v5,2/4] mmc: core: Support the optional
> init_card() callback for MMC and SD
> 5425301 New          [v5,2/4] mmc: core: Support the optional
> init_card() callback for MMC and SD
> 5425271 New          [v5,3/4] mmc: dw_mmc: Cleanup disable of low
> power mode w/ SDIO interrupts
> 5425281 New          [v5,3/4] mmc: dw_mmc: Cleanup disable of low
> power mode w/ SDIO interrupts
> 5425251 New          [v5,4/4] mmc: dw_mmc: Protect read-modify-write
> of INTMASK with a lock
> 5425261 New          [v5,4/4] mmc: dw_mmc: Protect read-modify-write
> of INTMASK with a lock

  reply	other threads:[~2014-12-30 10:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-02 23:42 [PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc Doug Anderson
2014-12-02 23:42 ` Doug Anderson
2014-12-02 23:42 ` [PATCH v5 1/4] ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only Doug Anderson
2014-12-02 23:42   ` Doug Anderson
2014-12-04 21:06   ` Tony Lindgren
2014-12-04 21:06     ` Tony Lindgren
2014-12-02 23:42 ` [PATCH v5 2/4] mmc: core: Support the optional init_card() callback for MMC and SD Doug Anderson
2014-12-02 23:42 ` [PATCH v5 3/4] mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts Doug Anderson
2014-12-03  0:17   ` Jaehoon Chung
2014-12-03  0:36     ` Doug Anderson
2014-12-03  1:06       ` Jaehoon Chung
2014-12-03  1:12         ` Doug Anderson
2014-12-03  1:19           ` Jaehoon Chung
2014-12-02 23:42 ` [PATCH v5 4/4] mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock Doug Anderson
2014-12-19 10:17 ` [PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc Ulf Hansson
2014-12-19 10:17   ` Ulf Hansson
2014-12-19 19:02   ` Doug Anderson
2014-12-19 19:02     ` Doug Anderson
2014-12-30 10:29     ` Ulf Hansson [this message]
2014-12-30 10:29       ` Ulf Hansson
2015-01-02 10:28       ` Javier Martinez Canillas
2015-01-02 10:28         ` Javier Martinez Canillas
2015-01-02 17:06       ` Doug Anderson
2015-01-02 17:06         ` Doug Anderson
2015-01-02 17:11         ` Tony Lindgren
2015-01-02 17:11           ` Tony Lindgren
2015-01-03  9:31           ` Ulf Hansson
2015-01-03  9:31             ` 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=CAPDyKFqGW2NaN+5mUrpBWrhM5ZfUSx70-Yyk9qmNaC1ft_ibpw@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --cc=abrestic@chromium.org \
    --cc=alim.akhtar@samsung.com \
    --cc=axel.lin@ingics.com \
    --cc=chris@printf.net \
    --cc=dianders@chromium.org \
    --cc=gsoutade@neotion.com \
    --cc=heiko@sntech.de \
    --cc=hsweeten@visionengravers.com \
    --cc=jh80.chung@samsung.com \
    --cc=joe@perches.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=s.hauer@pengutronix.de \
    --cc=sonnyrao@chromium.org \
    --cc=tgih.jun@samsung.com \
    --cc=tony@atomide.com \
    --cc=wsa@the-dreams.de \
    /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.