All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arend van Spriel <arend@broadcom.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	Chris Ball <chris@printf.net>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Aaron Lu <aaron.lu@intel.com>, Philip Rakity <prakity@nvidia.com>,
	Girish K S <girish.shivananjappa@linaro.org>,
	Al Cooper <alcooperx@gmail.com>
Subject: Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning
Date: Tue, 13 Jan 2015 16:11:14 +0100	[thread overview]
Message-ID: <54B53592.9070303@broadcom.com> (raw)
In-Reply-To: <CAPDyKFr-U+z3B5bhfP36Lxju5=zS6ZxFL8usm4XypodYLZ0_dw@mail.gmail.com>

On 01/13/15 15:56, Ulf Hansson wrote:
> [...]
>
>>>> Thank you for looking at the patches.
>>>>
>>>> I am not sure I know what you mean. sdhci already has a re-tuning timer, so
>>>> this is just moving it into core, where it won't be used by other drivers
>>>> unless they enable it.
>>>
>>> I am kind of questioning the re-tuning timer in sdhci. What is it good for?
>>
>> It is part of the SD Host Controller Standard Specification. The timer
>> ensures that re-tuning is done before temperature changes could affect the
>> "sampling point". It is needed for re-tuning mode 1 for UHS-I modes like SDR104.
>
> Does the spec say what value the timer should have?

It is read from the Capabilities register in the SD host controller, ie. 
in field "Timer Count for Re-Tuning" (see below).

Regards,
Arend

Timer Count for Re-Tuning
This field indicates an initial value of the Re-Tuning Timer for 
Re-Tuning Mode 1 to 3. Setting to 0 disables Re-Tuning Timer.
0h	Re-Tuning Timer disabled
1h	1 seconds
2h	2 seconds
3h	4 seconds
4h	8 seconds
.....	......................
n	2(n-1) seconds
.....	......................
Bh	1024 seconds
Eh - Ch	Reserved
Fh	Get information from other source

>>
>>>
>>> Can sdhci rely on that the mmc core performs a re-tune from the
>>> request retry mechanism instead?
>>
>> Not according to the standard.
>
> We don't have to implement everything that comes with the standard. We
> can leave things out.
>
>>
>>>
>>>>
>>>> I am not sure what you want to leave in sdhci.c and what you want in core,
>>>> if anything.
>>>
>>> We need all the infrastructure code in the core. Much like what your
>>> patchset does. Except that I would like you to remove the option of
>>> having a timer and the corresponding complexity it adds.
>>
>> If we are going to follow the standard then that doesn't seem to be an option.
>
> I am not suggestion us to violating the spec. I am suggesting to
> currently not support all of it.
>
>>
>>>
>>>>
>>>> At a minimum I need sdhci to be able to switch from hs400 to hs200, re-tune,
>>>> and switch back.
>>>
>>> As stated, I am only questioning the timer, nothing else.
>>
>> Ok so how should I proceed?
>>
>
> As I stated, let's try without the timer first.
>
> If we find it's not enough to recover at the request retry path, since
> it happens too often - lets deal with that then.
>
> Okay?
>
> Kind regards
> Uffe


  reply	other threads:[~2015-01-13 15:11 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05 17:40 [RFC PATCH 00/13] mmc: host: Add facility to support re-tuning Adrian Hunter
2014-12-05 17:40 ` [PATCH 01/13] mmc: core: Simplify by adding mmc_execute_tuning() Adrian Hunter
2015-01-13 11:19   ` Ulf Hansson
2014-12-05 17:41 ` [PATCH 02/13] mmc: host: Add facility to support re-tuning Adrian Hunter
2015-01-13 11:25   ` Ulf Hansson
2015-01-13 13:23     ` Adrian Hunter
2015-01-13 14:22       ` Ulf Hansson
2015-01-13 14:36         ` Adrian Hunter
2015-01-13 14:56           ` Ulf Hansson
2015-01-13 15:11             ` Arend van Spriel [this message]
2015-01-13 15:41               ` Ulf Hansson
2015-01-13 16:02                 ` Arend van Spriel
2015-01-14  9:47                   ` Ulf Hansson
2015-01-14  9:57                     ` Adrian Hunter
2015-01-14 10:13                       ` Ulf Hansson
2015-01-14 12:24                         ` Adrian Hunter
2015-01-14 12:59                           ` Ulf Hansson
2015-01-15 10:17                             ` Adrian Hunter
2015-01-15 13:39                               ` Ulf Hansson
2015-01-15 14:07                                 ` Arend van Spriel
2015-01-15 14:17                                   ` Arend van Spriel
2015-01-15 14:46                                     ` Ulf Hansson
2015-01-15 14:59                                       ` Arend van Spriel
2015-01-19  9:27                                         ` Ulf Hansson
2015-01-19  9:56                                           ` Adrian Hunter
2015-01-14 12:38                         ` Arend van Spriel
2015-01-14 12:52                           ` Ulf Hansson
2015-01-13 15:04         ` Arend van Spriel
2014-12-05 17:41 ` [PATCH 03/13] mmc: core: Disable re-tuning when card is no longer initialized Adrian Hunter
2014-12-05 17:41 ` [PATCH 04/13] mmc: core: Move mmc_card_removed() into mmc_start_request() Adrian Hunter
2015-01-13 11:20   ` Ulf Hansson
2014-12-05 17:41 ` [PATCH 05/13] mmc: core: Add support for re-tuning before each request Adrian Hunter
2014-12-05 17:41 ` [PATCH 06/13] mmc: core: Check re-tuning before retrying Adrian Hunter
2014-12-05 17:41 ` [PATCH 07/13] mmc: core: Hold re-tuning during switch commands Adrian Hunter
2014-12-05 17:41 ` [PATCH 08/13] mmc: core: Hold re-tuning during erase commands Adrian Hunter
2014-12-05 17:41 ` [PATCH 09/13] mmc: core: Hold re-tuning while bkops ongoing Adrian Hunter
2014-12-05 17:41 ` [PATCH 10/13] mmc: mmc: Comment that callers need to hold re-tuning if the card is put to sleep Adrian Hunter
2014-12-05 17:41 ` [PATCH 11/13] mmc: core: Add support for HS400 re-tuning Adrian Hunter
2014-12-05 17:41 ` [PATCH 12/13] mmc: sdhci: Always init buf_ready_int Adrian Hunter
2015-01-13 11:21   ` Ulf Hansson
2014-12-05 17:41 ` [PATCH 13/13] mmc: sdhci: Change to new way of doing re-tuning Adrian Hunter
2014-12-19 14:07 ` [RFC PATCH 00/13] mmc: host: Add facility to support re-tuning Adrian Hunter
2014-12-19 14:37   ` Ulf Hansson
2015-01-12 13:05   ` Adrian Hunter
2015-01-13 11:27 ` 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=54B53592.9070303@broadcom.com \
    --to=arend@broadcom.com \
    --cc=aaron.lu@intel.com \
    --cc=adrian.hunter@intel.com \
    --cc=alcooperx@gmail.com \
    --cc=chris@printf.net \
    --cc=girish.shivananjappa@linaro.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=prakity@nvidia.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.