From: Jon Hunter <jonathanh@nvidia.com>
To: Lucas Stach <dev@lynxeye.de>, Ulf Hansson <ulf.hansson@linaro.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Thierry Reding <thierry.reding@gmail.com>,
Alexandre Courbot <gnurou@gmail.com>,
linux-mmc@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH v2 3/5] mmc: tegra: implement UHS tuning
Date: Tue, 29 Mar 2016 17:37:45 +0100 [thread overview]
Message-ID: <56FAAF59.8080501@nvidia.com> (raw)
In-Reply-To: <1450809664-11360-4-git-send-email-dev@lynxeye.de>
Hi Lucas,
On 22/12/15 18:41, Lucas Stach wrote:
> This implements the UHS tuning sequence in a similar way to the one
> contained in the TRM. It deviates in the way how to check if the tap
> value is passing, by using the common Linux MMC function, which does
> not only check for data CRC errors, but also if the received block
> pattern is correct.
>
> Signed-off-by: Lucas Stach <dev@lynxeye.de>
I have been investigating a hang that occurs randomly during
system-suspend on Tegra124 Jetson TK1 (I have also reproduced the
problem on Tegra124 Nyan Big as well) with -next. The problem does not
occur on every suspend transition but if I execute 100 transitions I
will typically see it at some point. For example ...
count=0; while [ $count -lt 100 ]; do rtcwake -d rtc0 -m mem -s 3; echo
Suspend iteration $count; count=`expr $count + 1`; done
I was able to bisect this problem down to RMK's commit 71fcbda0fcdd
(“mmc: sdhci: fix command response CRC error handling”). However,
looking at RMK's change, I believe that this commit is not the problem
but has exposed a problem with the tegra SDHCI driver.
When the hang occurs I always see the following when starting the
suspend sequence and after which the system continues to suspend but
never exits suspend:
mmc0: Timeout waiting for hardware interrupt.
The above message is a symptom of RMK's commit and I have found that
when I see this, it always occurs during tegra_sdhci_execute_tuning()
because sometimes we get a CRC error.
I don't fully understand why the hang occurs in suspend, but putting
this aside (as well as the CRC error and timeout), the more I look at
the tuning code, the more it appears incomplete. Unfortunately, the
Tegra TRM alone does not give the complete procedure for performing the
tuning because there can be multiple windows where the tap values may
pass and these windows will vary with voltage/frequency. Plus we need to
ensure that the window is greater than a minimum width of 4 valid tap
values. The 3.18 kernel that is used for chrome-os products with
Tegra has a more complete implementation that is a good reference
(although not that easy to follow without good documentation!) [0].
We would definitely like to get this working in the mainline and I am
not sure if this is something that you are keen to spend time on or not?
Let me know and we can decide what makes most sense here.
Cheers
Jon
[0]
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.10/drivers/mmc/host/sdhci-tegra.c
next prev parent reply other threads:[~2016-03-29 16:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-22 18:40 [PATCH v2 0/5] Tegra SDHCI UHS-I support Lucas Stach
2015-12-22 18:41 ` [PATCH v2 2/5] mmc: tegra: disable SPI_MODE_CLKEN Lucas Stach
2015-12-22 18:41 ` [PATCH v2 3/5] mmc: tegra: implement UHS tuning Lucas Stach
2016-03-29 16:37 ` Jon Hunter [this message]
[not found] ` <56FAAF59.8080501-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-03-29 17:12 ` Jon Hunter
2015-12-22 18:41 ` [PATCH v2 4/5] mmc: tegra: enable UHS-I modes Lucas Stach
[not found] ` <1450809664-11360-1-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2015-12-22 18:41 ` [PATCH v2 1/5] mmc: tegra: implement module external clock change Lucas Stach
2015-12-22 18:41 ` [PATCH v2 5/5] mmc: tegra: use correct accessor for misc ctrl register Lucas Stach
2016-02-17 13:19 ` [PATCH v2 0/5] Tegra SDHCI UHS-I support Jon Hunter
2016-02-17 13:55 ` Jon Hunter
2016-02-17 19:52 ` Lucas Stach
2015-12-28 13:18 ` 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=56FAAF59.8080501@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=dev@lynxeye.de \
--cc=gnurou@gmail.com \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).