[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f4100ee2c655df5394322bb167f62dfd0a6587b8.camel@siemens.com>
Date: Thu, 8 Jan 2026 17:54:21 +0000
From: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
To: "nm@...com" <nm@...com>, "alexander.sverdlin@...il.com"
<alexander.sverdlin@...il.com>
CC: "d-gole@...com" <d-gole@...com>, "sebin.francis@...com"
<sebin.francis@...com>, "devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "a-kaur@...com" <a-kaur@...com>,
"k-willis@...com" <k-willis@...com>, "vigneshr@...com" <vigneshr@...com>,
"vishalm@...com" <vishalm@...com>, "khilman@...libre.com"
<khilman@...libre.com>, "msp@...libre.com" <msp@...libre.com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger
Hi Nishanth!
> > > > I think we would need to discuss this with TI via our FAE, because the change
> > > > in question has both been discussed with former FAE and the technical team
> > > > behind, and adopted in TI SDK.
> > > >
> > > > Or have you already discused this with corresponding TI HW team?
> > > >
> > > > Which hardware is affected, is it the official SK-AM62A-LP?
> > > > Is MMC2 the SD-card?
> > >
> > > I only tested my am62a board on u-boot v2026.01. It is a SK-AM62A-LP.
> > > MMC2 is the SD-card and mmc1 in the devicetree.
> >
> > just wanted to let you know, I was able to reproduce the problems with SD
> > card access via MMC2 under Linux on AM623 with ST enabled.
> >
> > We will seek clarification from TI on why this happens, which peripherals
> > are affected and what should be the course of actions.
>
>
> I have passed this up the chain here at TI. What confuses the heck out
Great, thanks Nishanth!
> of me is this: from an internal email chain I am privy to, i am being
> told that "the ST_EN bit in every PADCONFIG register should never be
> changed from its power-on default state of 0b1" and the fact that Linux
that's the info we've got from FAE initially and...
> kernel has been stable with the setting for a long period, So I am
... realized that Linux actually did the exact opposite of it since the first K3s
(AM65) and though "Ouch!"
That's how I quickly came up with 5b272127884b and though "finally we are safe!"
And "stable" is relative, we've found it out because GPIOs did produce
spurious interrupts, it's just that most of the drivers can handle it
gracefully. Except interrupt event counters...
> confused why U-Boot would show this instability.. I don't have answers
> at the moment. until we clarify the reasoning, I am going to have to
> hold off this given that kernel behavior has not regressed that I am
> aware of.
Indeed, I've reproduced it with AM623 in Linux [1], even though it's not
TI evaluation board, it's our HW. We do have other HW design where the
problem doesn't manifest itself, so ST seems to put MMC on the edge somehow.
I can try to retest TI AM625 based EKs at some point, but it could take
some days on my side...
[1] https://lore.kernel.org/all/6c90102537c3e3f1712538ca0b165cd54d71d8c2.camel@gmail.com/
--
Alexander Sverdlin
Siemens AG
www.siemens.com
Powered by blists - more mailing lists