All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-mmc <linux-mmc@vger.kernel.org>,
	linux-renesas-soc@vger.kernel.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Kuninori Morimoto <kuninori.morimoto.gx@gmail.com>,
	Magnus Damm <magnus.damm@gmail.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Dirk Behme <dirk.behme@gmail.com>
Subject: Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support
Date: Thu, 11 Feb 2016 14:30:22 +0000	[thread overview]
Message-ID: <CAPDyKFpYCi5X=rsnAYqcadPHV-LsdVbGbD1u7A-5JGxXB7o7aA@mail.gmail.com> (raw)
In-Reply-To: <20160211133212.GA1656@katana>

On 11 February 2016 at 14:32, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Thu, Feb 11, 2016 at 10:00:50AM +0100, Ulf Hansson wrote:
>> On 11 February 2016 at 01:07, Wolfram Sang <wsa@the-dreams.de> wrote:
>> >> I suspect you are using a delayed work in this driver to deal with
>> >> request timeouts.
>> >>
>> >> The value for the delay that is used, needs to be informed towards the
>> >> mmc core via the "->max_busy_timeout".
>> >
>> > Shouldn't that be a seperate patch? In patch 9, I add support for
>> > another SoC. But your requested change will affect all SoCs.
>>
>> This is related to how the core treat hosts that announces
>> MMC_CAP_WAIT_WHILE_BUSY.
>>
>> Therefore max_busy_timeout needs to be set within the same patch.
>
> Right. I assumed previous SoC (Gen2) were using MMC_CAP_WAIT_WHILE_BUSY
> already, so this step would then have to be taken seperately to catch
> all SoC. But I was wrong.
>
> I meanwhile found the timeout bits which are present in Gen3 and also in
> Gen2 and are currently unused by the driver. While this helps explaining
> that the HW has internal busy detection, its full potential is not
> implemented yet.
>
> So, I am going to resend patch 9 without MMC_CAP_WAIT_WHILE_BUSY set and
> will implement timeout handling incrementally as a seperate series.
>
> Sounds good?

Yes, please!

Kind regards
Uffe

WARNING: multiple messages have this Message-ID (diff)
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-mmc <linux-mmc@vger.kernel.org>,
	linux-renesas-soc@vger.kernel.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Kuninori Morimoto <kuninori.morimoto.gx@gmail.com>,
	Magnus Damm <magnus.damm@gmail.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Dirk Behme <dirk.behme@gmail.com>
Subject: Re: [PATCH 9/9] mmc: sdhi: Add r8a7795 support
Date: Thu, 11 Feb 2016 15:30:22 +0100	[thread overview]
Message-ID: <CAPDyKFpYCi5X=rsnAYqcadPHV-LsdVbGbD1u7A-5JGxXB7o7aA@mail.gmail.com> (raw)
In-Reply-To: <20160211133212.GA1656@katana>

On 11 February 2016 at 14:32, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Thu, Feb 11, 2016 at 10:00:50AM +0100, Ulf Hansson wrote:
>> On 11 February 2016 at 01:07, Wolfram Sang <wsa@the-dreams.de> wrote:
>> >> I suspect you are using a delayed work in this driver to deal with
>> >> request timeouts.
>> >>
>> >> The value for the delay that is used, needs to be informed towards the
>> >> mmc core via the "->max_busy_timeout".
>> >
>> > Shouldn't that be a seperate patch? In patch 9, I add support for
>> > another SoC. But your requested change will affect all SoCs.
>>
>> This is related to how the core treat hosts that announces
>> MMC_CAP_WAIT_WHILE_BUSY.
>>
>> Therefore max_busy_timeout needs to be set within the same patch.
>
> Right. I assumed previous SoC (Gen2) were using MMC_CAP_WAIT_WHILE_BUSY
> already, so this step would then have to be taken seperately to catch
> all SoC. But I was wrong.
>
> I meanwhile found the timeout bits which are present in Gen3 and also in
> Gen2 and are currently unused by the driver. While this helps explaining
> that the HW has internal busy detection, its full potential is not
> implemented yet.
>
> So, I am going to resend patch 9 without MMC_CAP_WAIT_WHILE_BUSY set and
> will implement timeout handling incrementally as a seperate series.
>
> Sounds good?

Yes, please!

Kind regards
Uffe

  reply	other threads:[~2016-02-11 14:30 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-25 19:15 [PATCH 0/9] mmc: sdhi: some refactoring and adding basic r8a7795 support Wolfram Sang
2016-01-25 19:15 ` Wolfram Sang
2016-01-25 19:15 ` [PATCH 1/9] mmc: tmio_dma: remove debug messages with little information Wolfram Sang
2016-01-25 19:15   ` Wolfram Sang
2016-01-25 19:15 ` [PATCH 2/9] mmc: sdhi: Add EXT_ACC register busy check Wolfram Sang
2016-01-25 19:15   ` Wolfram Sang
2016-01-25 19:15 ` [PATCH 3/9] mmc: sdhi: error message on ENOMEM is superfluous Wolfram Sang
2016-01-25 19:15   ` Wolfram Sang
2016-01-25 19:15 ` [PATCH 4/9] mmc: tmio: add flag to reduce delay after changing clock status Wolfram Sang
2016-01-25 19:15   ` Wolfram Sang
2016-01-25 19:15 ` [PATCH 5/9] mmc: tmio: remove stale comments Wolfram Sang
2016-01-25 19:15   ` Wolfram Sang
2016-01-25 19:15 ` [PATCH 6/9] mmc: sdhi: use faster clock handling on RCar Gen2 Wolfram Sang
2016-01-25 19:15   ` Wolfram Sang
2016-01-25 19:15 ` [PATCH 7/9] mmc: tmio: refactor set_clock a little Wolfram Sang
2016-01-25 19:15   ` Wolfram Sang
2016-01-25 19:15 ` [PATCH 8/9] mmc: tmio: disable clock before changing it Wolfram Sang
2016-01-25 19:15   ` Wolfram Sang
2016-01-25 19:15 ` [PATCH 9/9] mmc: sdhi: Add r8a7795 support Wolfram Sang
2016-01-25 19:15   ` Wolfram Sang
2016-01-29 11:40   ` Ulf Hansson
2016-01-29 11:40     ` Ulf Hansson
2016-02-10 16:36     ` Wolfram Sang
2016-02-10 16:36       ` Wolfram Sang
2016-02-10 18:43       ` Ulf Hansson
2016-02-10 18:43         ` Ulf Hansson
2016-02-11  0:07         ` Wolfram Sang
2016-02-11  0:07           ` Wolfram Sang
2016-02-11  9:00           ` Ulf Hansson
2016-02-11  9:00             ` Ulf Hansson
2016-02-11 13:32             ` Wolfram Sang
2016-02-11 13:32               ` Wolfram Sang
2016-02-11 14:30               ` Ulf Hansson [this message]
2016-02-11 14:30                 ` Ulf Hansson
2016-01-29 11:40 ` [PATCH 0/9] mmc: sdhi: some refactoring and adding basic " Ulf Hansson
2016-01-29 11:40   ` Ulf Hansson
2016-02-02 14:06   ` Wolfram Sang
2016-02-02 14:06     ` Wolfram Sang
2016-02-02 14:50     ` Ulf Hansson
2016-02-02 14:50       ` Ulf Hansson
2016-02-02 14:59       ` Wolfram Sang
2016-02-02 14:59         ` Wolfram Sang

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='CAPDyKFpYCi5X=rsnAYqcadPHV-LsdVbGbD1u7A-5JGxXB7o7aA@mail.gmail.com' \
    --to=ulf.hansson@linaro.org \
    --cc=dirk.behme@gmail.com \
    --cc=kuninori.morimoto.gx@gmail.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=wsa@the-dreams.de \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /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.