Received-SPF: pass (google.com: domain of linux-kernel+bounces-88256-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <CGME20240213051332epcas1p1f45d02dc34d1b95ea5608ab779d6b6cc@epcas1p1.samsung.com>
 <20240213051716.6596-1-sh043.lee@samsung.com> <CAPDyKFrjZ4jRHAfXsvrEvezuHTxbA3SAniF8CuObyLuW=AUoeA@mail.gmail.com>
 <000001da5faa$d34e1600$79ea4200$@samsung.com> <CAPDyKFpOLU3nsQuXLRdK2KAaQqX=Vwe0+A3jZc7pP4XaMG7Wug@mail.gmail.com>
 <000001da6075$754d6ee0$5fe84ca0$@samsung.com>
In-Reply-To: <000001da6075$754d6ee0$5fe84ca0$@samsung.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
Date: Fri, 1 Mar 2024 11:33:25 +0100
Message-ID: <CAPDyKFoaNFox5iuyh_veP203JYipa8Nt36Z1Y1J6CUJSCLhx_g@mail.gmail.com>
Subject: Re: [PATCH] mmc: sd: Add a variable to check a faulty device
To: =?UTF-8?B?7J207Iq57Z2s?= <sh043.lee@samsung.com>
Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	gregkh@linuxfoundation.org, avri.altman@wdc.com, grant.jung@samsung.com, 
	jt77.jang@samsung.com, dh0421.hwang@samsung.com, junwoo80.lee@samsung.com, 
	jangsub.yi@samsung.com, cw9316.lee@samsung.com, sh8267.baek@samsung.com, 
	wkon.kim@samsung.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 16 Feb 2024 at 02:14, =EC=9D=B4=EC=8A=B9=ED=9D=AC <sh043.lee@samsun=
g.com> wrote:
>
> > -----Original Message-----
> > > > On Tue, 13 Feb 2024 at 06:13, Seunghui Lee <sh043.lee@samsung.com>
> > wrote:
> > > > >
> > > > > In mobile devices, suspend/resume situations are frequent.
> > > > > In the case of a defective SD card in which initialization fails,
> > > > > unnecessary initialization time is consumed for each resume.
> > > > > A field is needed to check that SD card initialization has failed
> > > > > on the host. It could be used to remove unnecessary initializatio=
n.
> > > >
> > > > It's not clear to me, under what circumstance you want to optimize =
for.
> > > >
> > > > Is the SD card ever getting properly initialized during boot?
> > > >
> > > > Kind regards
> > > > Uffe
> > > >
> > > We receive a lot of reports about SD card issues in the market.
> > > There was no problem with the first time at the time of use, and ther=
e
> > are many cases where people recognize that it is not recognized later o=
n.
> > In most cases, this is a problem with the SD card itself.
> >
> > Right. Thanks for clarifying.
> >
> > A follow up question from me is then, do you know more exactly *why* th=
e
> > SD cards encounter problems?
> >
> > In the past people have told me that powering on/off an SD card during
> > system suspend/resume, too frequently, could damage the card. For non-
> > removable cards, the card stays powered-off even after a system resume,
> > but instead gets powered-on (and re-initialized) when there is a new
> > request for it.
> >
> > In other words, if the problem is related to too frequent powering on/o=
ff
> > the card, my advice would be to test with having the card set non-
> > removable (the DT property for this is "non-removable"), to see if that
> > can help. If that solves the problem, we can work towards another commo=
n
> > solution instead.
> >
>
> I understand your focus on finding the root cause of the problem.
> However, unlike internal storage, there is a limit to analyzing cards tha=
t have problems in the market.
> This is because there are many different SD card manufacturers and many m=
anufacturers leave it to OEMs.

I understand that this isn't an easy task, but for sure it should be
doable. There are plenty of less robust SD cards out there, let's just
try to find one and see if we can break it. :-)

>
> For deferred resume, a responsiveness problem occurs on the user side on =
mobile devices.
> The response time of the initializing SD card initialization in the appli=
cation seems to be slow.
> Currently, it seems to be a good structure for the first initialization a=
t runtime resume.

You are correct - an initial latency for the *first* I/O request will
be added. On the other hand, if the SD card remains unused after a
system resume, there should be some energy to save, as the card would
then remain powered-off.

Moreover, if we also can avoid breaking the SD card, I'm sure it would
be worth it.

>
> Regarding non-removable,
> We will test if we are given an opportunity to further analyze the cards =
occurring in the market.
> However, SD card detection is also used as a wakeup source and must be in=
serted/removed so I'll consider it for testing purposes.

Yes, I understand that part. A proper solution needs to take care of
removable cards, of course. The suggestion to set the slot as
non-removable, was just to try to understand if that would solve the
problem of breaking SD cards.

If the card-detect irq, can be configured as a wakeup source, I think
we should be able to distinguish - if we need to do a power-on
(re-init) of the SD card during system resume or if we can avoid it.

I try to get some time to put together a patch for this, no promises
for when, but I will keep you posted.

[...]

Kind regards
Uffe