Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934610AbdCWNKb (ORCPT ); Thu, 23 Mar 2017 09:10:31 -0400 Received: from mail-vk0-f52.google.com ([209.85.213.52]:33292 "EHLO mail-vk0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932997AbdCWNK2 (ORCPT ); Thu, 23 Mar 2017 09:10:28 -0400 MIME-Version: 1.0 In-Reply-To: <3a0f2112746a4f0fbaa73906c606a340@SIWEX5A.sing.micron.com> References: <4e7d0b4b8df1430698e822b1a36bcc11@SIWEX5A.sing.micron.com> <3a0f2112746a4f0fbaa73906c606a340@SIWEX5A.sing.micron.com> From: Ulf Hansson Date: Thu, 23 Mar 2017 14:10:18 +0100 Message-ID: Subject: Re: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off To: "Bean Huo (beanhuo)" Cc: "linus.walleij@linaro.org" , "shawn.lin@rock-chips.com" , "adrian.hunter@intel.com" , "axboe@fb.com" , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Zoltan Szubbocsev (zszubbocsev)" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1905 Lines: 46 On 23 March 2017 at 11:45, Bean Huo (beanhuo) wrote: > Hi, > >>On 19 March 2017 at 01:45, Bean Huo (beanhuo) 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