All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: linux-mmc@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>
Subject: [PATCH v2 0/3] mmc: renesas_sdhi: improve TAP selection if all TAPs are good
Date: Wed,  8 Apr 2020 11:46:35 +0200	[thread overview]
Message-ID: <20200408094638.10375-1-wsa+renesas@sang-engineering.com> (raw)

SDHI (with SCC) has a mechanism to select an optimal TAP even if all
were considered good during the tuning process. This series implements
support for it. Before that, some refactoring of 'best TAP selection' is
done to avoid code duplication and get more understandable code.

This work is based on BSP patches by Masaharu Hayakawa and Takeshi
Saito. It is built on top of mmc/next. For convenience, a branch is
here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/sdhi/new_manual_calib

It has been tested on Renesas Salvator-XS boards (R-Car M3-N and R-Car
H3 ES2.0). There were no regressions detected. HS400 could be tuned the
same way, and checksumming large files still works.

And while this series is useful by itself, it is also the last
prerequisite to implement some 'bad tap avoidance' on top which is what
we are originally aiming for.

Note about backporting: The super useful iterator
bitmap_for_each_set_region() is only available since v5.6. If you want
that before, you need to backport the needed bits of e837dfde15a4
("bitmap: genericize percpu bitmap region iterators"), too.

Thank you to Shimoda-san for his valuable input since the RFT version
of this patchset (see patch 1 for details)!

Kind regards,

   Wolfram

Wolfram Sang (3):
  mmc: renesas_sdhi: refactor calculation of best TAP
  mmc: renesas_sdhi: clarify handling of selecting TAPs
  mmc: renesas_sdhi: improve TAP selection if all TAPs are good

 drivers/mmc/host/renesas_sdhi.h      |  2 +
 drivers/mmc/host/renesas_sdhi_core.c | 64 ++++++++++++++--------------
 2 files changed, 34 insertions(+), 32 deletions(-)

-- 
2.20.1


             reply	other threads:[~2020-04-08  9:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-08  9:46 Wolfram Sang [this message]
2020-04-08  9:46 ` [PATCH v2 1/3] mmc: renesas_sdhi: refactor calculation of best TAP Wolfram Sang
2020-04-09  8:58   ` Yoshihiro Shimoda
2020-04-08  9:46 ` [PATCH v2 2/3] mmc: renesas_sdhi: clarify handling of selecting TAPs Wolfram Sang
2020-04-08  9:46 ` [PATCH v2 3/3] mmc: renesas_sdhi: improve TAP selection if all TAPs are good Wolfram Sang
2020-04-09  9:04   ` Yoshihiro Shimoda
2020-04-15 10:21 ` [PATCH v2 0/3] " 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=20200408094638.10375-1-wsa+renesas@sang-engineering.com \
    --to=wsa+renesas@sang-engineering.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --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.