On Fri, 16 Feb 2024 at 02:14, 이승희 <sh043.lee@xxxxxxxxxxx> wrote: > > > -----Original Message----- > > > > On Tue, 13 Feb 2024 at 06:13, Seunghui Lee <sh043.lee@xxxxxxxxxxx> > > 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 initialization. > > > > > > > > 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 there > > are many cases where people recognize that it is not recognized later on. > > 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* the > > 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/off > > 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 common > > 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 that have problems in the market. > This is because there are many different SD card manufacturers and many manufacturers 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 application seems to be slow. > Currently, it seems to be a good structure for the first initialization at 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 inserted/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
