Received-SPF: pass (google.com: domain of linux-kernel+bounces-52847-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Mon, 5 Feb 2024 15:51:26 +0100
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: claudiu beznea <claudiu.beznea@tuxon.dev>
Cc: ulf.hansson@linaro.org, yoshihiro.shimoda.uh@renesas.com,
	masaharu.hayakawa.ry@renesas.com, takeshi.saito.xv@renesas.com,
	linux-mmc@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Subject: Re: [PATCH v3] mmc: renesas_sdhi: Fix change point of data handling
Message-ID: <ZcD17mTRnfIaueAW@shikoro>
Mail-Followup-To: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	claudiu beznea <claudiu.beznea@tuxon.dev>, ulf.hansson@linaro.org,
	yoshihiro.shimoda.uh@renesas.com, masaharu.hayakawa.ry@renesas.com,
	takeshi.saito.xv@renesas.com, linux-mmc@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
References: <20240205112702.213050-1-claudiu.beznea.uj@bp.renesas.com>
 <ZcDdn2AVz8FIXzak@shikoro>
 <237bd5c8-184d-4e46-ba66-253e3ef0c895@tuxon.dev>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="qEqW1x4AbDvxYxZ7"
Content-Disposition: inline
In-Reply-To: <237bd5c8-184d-4e46-ba66-253e3ef0c895@tuxon.dev>


--qEqW1x4AbDvxYxZ7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


> > According to my understanding, we should only mark this TAP good if it
> > is in the range 5-7. I need to double check with Renesas, though.
>=20
> OK, my understanding is that it should be in the middle (beginning being
> the tap that triggered change point of the input data, end being the next
> tap with the same ID). This is what I understand from this: "As the width
> of the input data is 1 (UI), select TAP6 or TAP7 which is
>=20
> *the median* of next TAP3 from TAP3."

Yes, I agree. With 0x0e, that means TAP1+2+3 are changing points and we
should be far away from them, like 5-7.

But: I am still waiting for Renesas to answer my questions regarding
SMPCMP. I'd like to get that first, so we have clear facts then.

> > Boot failure is one test. Read/write tests should be another, I think.
>=20
> OK, I'll try also read/write. Do you have in mind something particular?

Nope. Just consistency checks.

> > Because if we select a bad TAP, bad things might happen later. To reduce
> > the amount of testing, read/write testing could only be triggered if the
> > new code path was excecuted?
>=20
> I'm not sure how to trigger that (or maybe I haven't understood your
> statement...)

I thought something in the lines of:

- print out when you needed SMPCMP to select a TAP
- check the log for that printout
- if (printout) do read_write_tests

Dunno if that makes sense with your test setup.


--qEqW1x4AbDvxYxZ7
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmXA9eoACgkQFA3kzBSg
KbZncQ//f/ax+lI9WQAUTFM3v2A9bA6nLjRcWJr9G/EpZeEtrNs4C0OakdRE8Gwi
CLENdlS9pUSVUrHyfjv1LXo/SD+xcj3tHL42yDJ3m1zStuh2Vu3mvvvhcnFX+qcq
5EUjvtHpGfSg5QokJ0AV0U22DXeJOHWOXJK/PS+OnR9He66Xm+PC9PxFea5rzVQw
0xBqz/uUKC1jSqIWMHniAKsHh4sWMi+hgKdfdG9n1AbW89ofU8A3wN7PyggZIQz+
vYJvQgVuhfcr7hgLVo3wrayWfZfPpolF2Sbe6ThIWTEm1ZmDUAmM8buJ6vWKZwbl
e8k0JknLSRfrI+e09x57IbHDqx8O4e6kgIwQ5H/jlel3q236bWaLszRetw86IW+K
t/2kiny7aPRM2msFGoaefXtwDNSTBzLS9HIjoWlZUAkEzNozv+PTsKAczXheI0bu
ouZOPam/L9V49PaSrijs2d4+SKHiuRrP/QDA993SCIRmQ8eFTkGfpVpRnTyM6+Gd
xqzBzWI/U89x5U0isr0lZDlfiFs3IyVIdnSa+thcdaaUzJOYnN6axGvR5vYhNujR
zv7ptO3ZpetT7IodiYyIxXDo+zuesne9yj4X3HWnFiyuivBqauedUqtKHtgQeRqL
kcav4NdwvzUdqRN/HxDgLu81KXlwibniQEK0edE/M26kCl4jMCs=
=5JaQ
-----END PGP SIGNATURE-----

--qEqW1x4AbDvxYxZ7--