Thread (27 messages) 27 messages, 3 authors, 2018-08-09

Re: [PATCH 5/8] arm64: dts: tegra186: Add SDMMC4 DQS trim value

From: Thierry Reding <hidden>
Date: 2018-08-09 13:52:23
Also in: linux-mmc, linux-tegra, lkml

On Thu, Aug 09, 2018 at 03:02:26PM +0300, Aapo Vienamo wrote:
On Thu, 9 Aug 2018 13:49:22 +0200
Thierry Reding [off-list ref] wrote:
quoted
On Tue, Aug 07, 2018 at 05:00:01PM +0300, Aapo Vienamo wrote:
quoted
Add the HS400 DQS trim value for Tegra186 SDMMC4.

Signed-off-by: Aapo Vienamo <redacted>
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 +
 1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 6e9ef26..9e07bc6 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -313,6 +313,7 @@
 		nvidia,pad-autocal-pull-down-offset-1v8-timeout = <0x0a>;
 		nvidia,default-tap = <0x5>;
 		nvidia,default-trim = <0x9>;
+		nvidia,dqs-trim = <63>;
 		status = "disabled";
 	};
   
Isn't this technically dependent on the board layout and as such would
belong in the board DTS file? Or does this value work on all existing
Tegra186 platforms?
This value is specified as part of the controller initialization
sequence in the TRM. I've understood that this (and other tap and trim)
value(s) are used for compensating the propagation delay differences
that are caused by the internal SoC layout.
Hmm... it would seem to me like the routing on a board would have a more
significant impact than the SoC internal routing. But perhaps the board-
specific routing is actually what the automatic calibration is used for?

Anyway, if it ever turns out that we need slightly different values on a
given board, we can always override the value in the board DTS file.

Thierry

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help