Re: [PATCH v2 3/5] mmc: tegra: implement UHS tuning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>

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


--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux