linux-kernel - Re: [PATCH 0/2] arm64: tegra: add wp-gpio to P2957 board

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <goi3wqrbva565ejst25fwflgvp4d5vznmqlba4q6liylzdkwfk@hovwpzcnvf2q>
Date: Mon, 23 Sep 2024 13:01:21 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Diogo Ivo <diogo.ivo@...nico.ulisboa.pt>
Cc: Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Jonathan Hunter <jonathanh@...dia.com>, devicetree@...r.kernel.org, linux-tegra@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] arm64: tegra: add wp-gpio to P2957 board

On Fri, Aug 30, 2024 at 11:20:45AM GMT, Diogo Ivo wrote:
> Hi Thierry,
> 
> On Thu, Aug 29, 2024 at 05:31:23PM GMT, Thierry Reding wrote:
> > From: Thierry Reding <treding@...dia.com>
> > 
> > 
> > On Thu, 15 Aug 2024 16:50:38 +0100, Diogo Ivo wrote:
> > > Define the wp-gpio for the P2597 board.
> > > 
> > > For this, patch 1 fixes the assignment of the vmmc supply's gpio that
> > > was incorrectly assigned to the wp-gpio of the external slot.
> > > 
> > > Patch 2 adds the definition of the wp-gpio.
> > > 
> > > [...]
> > 
> > Applied, thanks!
> 
> Thanks for picking up the patches! In my testing around SD/MMC I found that
> currently UHS-I cards are broken on the P2597. When trying to use one
> the system shows somewhat erratic behaviour where it sometimes hangs and
> some other times it simply fails to read from the SD card. I have
> tracked the point at which this happens to be around
> tegra_sdhci_pad_autocalib() when switching to SDR104 mode, where there
> is the possibility of using specific offsets for this mode. Currently
> there are no values specified in tegra210.dtsi, so the 1.8V values are
> being used. However, when I tried specifying them as
> 
> 	nvidia,pad-autocal-pull-up-offset-sdr104 = <0>;
> 	nvidia,pad-autocal-pull-down-offset-sdr104 = <0>;
> 
> in the DT things started working fine. I did not send a patch with these
> values since I could not find what they should be on the X1 TRM, are
> there any recommended values for these parameters so that we can have
> this fixed?

Sorry for the late reply. Looking at the Tegra X1 TRM, section 32.7
"Programming Guidelines" (starting on page 2473), I see there are a
few subsections called "Run Auto-Calibration", which list recommended
values for the auto-calibration pull-down/-up offsets, depending on the
signaling mode (3.3V vs. 1.8V).

They are:

          3.3V    1.8V
          PD  PU  PD  PU
  SDMMC1  125  0  123 123
  SDMMC2  n/a n/a  5   5
  SDMMC3  125  0  123 123
  SDMMC4  n/a n/a  5   5

Now these aren't the ones you've been using, but it is what we have in
the Tegra210 DTSI file. Interestingly the TRM doesn't make those
specific to the mode (such as SDR104 and HS400 like the DT bindings
suggest they should be).

Also interestingly, on Tegra234 the recommended values in the TRM for
these fields is 0 (like you're using), irrespective of mode.

It's not entirely clear to me why we need these offsets during auto-
calibration, so 0 makes as much sense as any other value. The
documentation isn't very clear on what these values do, either. So I'd
be inclined to accept a patch such as yours based purely on the fact
that it makes things work.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)