Hi Shawn, > > From experience. One of my customers has a long-term test which works > > fine without HS200 and has occasional tuning problems with HS200. Of > > course, we are also debugging why HS200 fails in the first place. > > > > Still, there is this question why Linux doesn't fall back to something > > I can't remember linux-mmc had a discussion about fallback for this, > so I guess it is just because nobody proposed patch(es) for that. > Honestly I thought of fallback last year, not just for tuning failure > but allow it from HS400(es) -> HS200 -> DDR52 -> SDRx etc, but never > start writing one bit for that. What other scenarios except tuning failure did you have in mind? > Just like your case, could that confuse users that sometimes the > system I/O work slowly but sometime not？ some boards luckily work fine In my case, with unattended systems deployed in the field, a slow rootfs is much preferable to a Kernel OOPS. Likely, a demon will be running checking the logs for unexpected messages but I don't know that for sure. > but some boards not, which make the user experience(probably production > quality) not so much consistent? The users seldom check the log to know > what happended but we/developers do, and we still need to help point out > what's wrong here.:) Here, there is no user using the device. > Another one is, if the tuning works fine mostly, should we retry more > tuning to make is work? What we should do if the re-tuning fails but For me, signs are that it is indeed a SoC errata which causes a wrong internal state. If this turns out to be true, more retries wouldn't help, sadly. > tuning when booting works? I guess we need a power cycle and dynamic > speed mode fallback for runtime. Yes, I'd agree. Thanks, Wolfram
Attachment:
signature.asc
Description: PGP signature
