On 23 March 2017 at 11:45, Bean Huo (beanhuo) <bean...@micron.com> wrote: > Hi, > >>On 19 March 2017 at 01:45, Bean Huo (beanhuo) <bean...@micron.com> wrote: >>> This patch fixes the issue that mmc_blk_issue_rq still flushes cache >>> when eMMC cache has already been off through user space tool, such as >>> mmc-utils. >>> The reason is that card->ext_csd.cache_ctrl isn't reset. >> >>First, why do you want to turn of the cache ctrl? Is the eMMC device having >>issues with it? Then we should invent a card quirk instead. > > > Why I turn off it? because I did power loss testing and validation, I should > switch it off and on. > When I do some performance and power loss case validation on several Linux > release versions, > I need to switch off or on cache through user space tool. > I can't confirm every user that likes me, But I think at least it is not > reasonable to > flush eMMC cache, when internal eMMC cache is off.
Ah, I see. Your use-case seems reasonable while validating robustness of the eMMC! > >>Second, what errors do you encounter when the mmc core tries to flush the >>cache when it has been turned off? Can you please elaborate on this? > > > No error found, but firstly, please think about overhead introduced by > useless flush cache, Unless you > Don't care this tiny time. second, under the condition of cache off, > additional flush cache request still has impact on > Internal eMMC logic. I don't know What and how impact, but at least it is > really exist. Got it! However I still don't like the mmc ioctls API to compensate and deal with all "crazy-ness" that user-space may cause. Cache-ctrl is only one case out of many. I see two viable options to solve your problem. 1) Extend mmc_test with a new test(s) for cache ctrl and perhaps suspend/resume. Isn't this actually exactly what you want? 2) Extend debugfs to be able to turn cache ctrl on/off. [...] Kind regards Uffe
