All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Magnus Damm <magnus.damm@gmail.com>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v4 2/4] mmc: tmio: Add tuning support
Date: Thu, 25 Aug 2016 14:04:24 +0200	[thread overview]
Message-ID: <20160825120424.GA3385@verge.net.au> (raw)
In-Reply-To: <CAPDyKFpbMnOag7TZtQXxffXyq4XjTfz3vYM_atks15+d64QkfQ@mail.gmail.com>

On Tue, Aug 23, 2016 at 05:02:56PM +0200, Ulf Hansson wrote:
> [...]
> 
> >> > +static int tmio_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode)
> >> > +{
> >> > +       struct tmio_mmc_host *host = mmc_priv(mmc);
> >> > +       unsigned int num;
> >> > +       int i, ret = 0;
> >> > +       bool *tap;
> >> > +
> >> > +       if (!host->init_tuning || !host->select_tuning)
> >>
> >> When defining these callbacks, it would be nice to know which ones are
> >> optional and which ones are required.
> >
> > Would some comments in struct tmio_mmc_host be an appropriate way
> > to achieve that?
> 
> Yes, that would be nice!
> 
> [...]
> 
> >> >  static int tmio_mmc_init_ocr(struct tmio_mmc_host *host)
> >> > @@ -1202,6 +1276,9 @@ int tmio_mmc_host_runtime_suspend(struct device *dev)
> >> >         struct mmc_host *mmc = dev_get_drvdata(dev);
> >> >         struct tmio_mmc_host *host = mmc_priv(mmc);
> >> >
> >> > +       mmc_retune_timer_stop(host->mmc);
> >> > +       mmc_retune_needed(host->mmc);
> >>
> >> I am wondering whether it would it be possible to keep a cache of the
> >> currently used tuning values and then restore these values at
> >> runtime_resume?
> >>
> >> In that way you wouldn't need to force new re-tuning cycle here.
> >
> > I will check with the hardware people to see if it is practical from
> > that POV.
> 
> Okay!

The feedback I received is something like this:

* The tap values calculated during retuning depend on the temperature of
  the SoC and card.
* So after resume the values may be invalid.
* It may be possible to re-use the TAP values and re-tune if a transfer
  fails but the people I spoke with were unsure of the merit of that
  approach

Personally my feeling is that we should initiate a retune on resume for
now as that seems to be the safest option.

> > From a software POV that ought to be simple enough: a small bitmap ought
> > to be sufficient to save the values for the hardware covered by this
> > series.
> 
> Yes, indeed!
> 
> Kind regards
> Uffe
> 

  reply	other threads:[~2016-08-25 12:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-27  4:13 [PATCH v4 0/4] UHS-I SDR-104 support for sh_mobile_sdhi Simon Horman
2016-07-27  4:13 ` [PATCH v4 1/4] mmc: tmio: enhance illegal sequence handling Simon Horman
2016-07-27  4:13 ` [PATCH v4 2/4] mmc: tmio: Add tuning support Simon Horman
2016-08-10 13:10   ` Wolfram Sang
2016-08-22 13:39   ` Ulf Hansson
2016-08-23 13:52     ` Simon Horman
2016-08-23 15:02       ` Ulf Hansson
2016-08-25 12:04         ` Simon Horman [this message]
2016-08-26  8:01           ` Ulf Hansson
2016-08-29 12:05             ` Simon Horman
2016-08-29 14:05               ` Ulf Hansson
2016-08-30 20:51                 ` Simon Horman
2016-08-31  7:38                   ` Ulf Hansson
2016-09-01  6:46                     ` Simon Horman
2016-09-01  8:37                       ` Simon Horman
2016-09-01  9:55                         ` Ulf Hansson
2016-09-01 14:19                           ` Simon Horman
2016-07-27  4:13 ` [PATCH v4 3/4] mmc: sh_mobile_sdhi: " Simon Horman
2016-07-28  0:12   ` Simon Horman
2016-07-27  4:13 ` [PATCH v4 4/4] ARM: dts: r8a7790: lager: Enable UHS-I SDR-104 Simon Horman
2016-08-10 13:12 ` [PATCH v4 0/4] UHS-I SDR-104 support for sh_mobile_sdhi Wolfram Sang
2016-08-11  8:43   ` Simon Horman

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=20160825120424.GA3385@verge.net.au \
    --to=horms@verge.net.au \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=ulf.hansson@linaro.org \
    --cc=wsa+renesas@sang-engineering.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.