Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp914889pxp; Wed, 16 Mar 2022 21:09:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJww+5z0c86SnVvNEB15mKWL4lkWaYhVpMitVB/BkTl8YrK3p67f8p3LRCIcE2ZY01gitgzu X-Received: by 2002:a17:902:dacc:b0:151:c216:2772 with SMTP id q12-20020a170902dacc00b00151c2162772mr2627222plx.107.1647490158445; Wed, 16 Mar 2022 21:09:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647490158; cv=none; d=google.com; s=arc-20160816; b=Buek6FmafpTmUaGa79m9x0EsufGqacfinSzUTBjz62+9/8oBCm7wnczO9vdsh25Js7 bmmSEJV6FiCVDCqWVfVoP6KEO21rymFUuxlia5F8Y7yzUeDcWMWKzwAXAfjMuRZdx3JH XzUD9ezDFDzvKCP+gjkkkvc9QdLSQMvjsDP6tb1RNTJv9d/GRN+neTLVnV+N2BmxwYY9 xEfRsSh36EqDtr+/2b2dASkW8u7+4MZf9JpjqAENumU5bYbX1syfuhWS8GV74nAj4Umh XswKgIFS05zUX3cr36jmEUQ+1XlyqNytkCAFo35E/rS7iCGlyPkxWimqY0qX5qTIkTh9 580g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from; bh=TzlqbrzAmSRQw38J007Va+/NnAThAQoiKPym+pmaG1A=; b=E0blCr+WqS2EoYHLsGLkiTc6sWgfSA05HKApL4O8yIG5UFTN77hbDGYW1YfwbdNMjX z76Dpj+9bT3Pf99PhJSTFcwB+czKxHPV3l45UbZs8INZAqYjGyk4UevwKfkG1gK6jzPa l90rmN8uNfomxl4ObH0eIa/x4l4KWwsDqAtsVPEUWFGECej2HdiTwnn1BNaxXKbmVn+H GlZpckeRoo7ahzaorH6leT+P+Fa9jwvDNu/Su4IpztxTb2GIZw/BE33Kj8hJo0jMJVgt Mrqrjb95XcQ6tTuLixUnUjb85/bXoQBQTWdXrqp8dnC+TRrGAUR8FDIZcpevCuxpgQeZ Yn3Q== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hyperstone.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id h15-20020a17090a3d0f00b001bf7b9c1dfasi1204166pjc.66.2022.03.16.21.09.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 21:09:18 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hyperstone.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0F8C0A0BD0; Wed, 16 Mar 2022 20:48:56 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237682AbiCPOxS convert rfc822-to-8bit (ORCPT + 99 others); Wed, 16 Mar 2022 10:53:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356972AbiCPOxK (ORCPT ); Wed, 16 Mar 2022 10:53:10 -0400 X-Greylist: delayed 350 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 16 Mar 2022 07:51:55 PDT Received: from mail3.swissbit.com (mail3.swissbit.com [176.95.1.57]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C01975F4C6 for ; Wed, 16 Mar 2022 07:51:55 -0700 (PDT) Received: from mail3.swissbit.com (localhost [127.0.0.1]) by DDEI (Postfix) with ESMTP id E48BB463677; Wed, 16 Mar 2022 15:46:02 +0100 (CET) Received: from mail3.swissbit.com (localhost [127.0.0.1]) by DDEI (Postfix) with ESMTP id CC38F4619D1; Wed, 16 Mar 2022 15:46:02 +0100 (CET) X-TM-AS-ERS: 10.149.2.84-127.5.254.253 X-TM-AS-SMTP: 1.0 ZXguc3dpc3NiaXQuY29t Y2xvZWhsZUBoeXBlcnN0b25lLmNvbQ== X-DDEI-TLS-USAGE: Used Received: from ex.swissbit.com (SBDEEX02.sbitdom.lan [10.149.2.84]) by mail3.swissbit.com (Postfix) with ESMTPS; Wed, 16 Mar 2022 15:46:02 +0100 (CET) Received: from sbdeex02.sbitdom.lan (10.149.2.84) by sbdeex02.sbitdom.lan (10.149.2.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Wed, 16 Mar 2022 15:46:02 +0100 Received: from sbdeex02.sbitdom.lan ([fe80::e0eb:ade8:2d90:1f74]) by sbdeex02.sbitdom.lan ([fe80::e0eb:ade8:2d90:1f74%8]) with mapi id 15.02.0986.022; Wed, 16 Mar 2022 15:46:02 +0100 From: =?Windows-1252?Q?Christian_L=F6hle?= To: Adrian Hunter , Avri Altman , Michael Wu , "ulf.hansson@linaro.org" , "beanhuo@micron.com" , "porzio@gmail.com" CC: "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , allwinner-opensource-support Subject: Re: [PATCH] mmc: block: enable cache-flushing when mmc cache is on Thread-Topic: [PATCH] mmc: block: enable cache-flushing when mmc cache is on Thread-Index: AQHYNcu3WGf4zsUDOUapUgyqsaCvc6y+ZEOAgAAo/4CAAASLgIADKXiAgAAU4oCAAAVPgIAARzTm Date: Wed, 16 Mar 2022 14:46:02 +0000 Message-ID: <7ec0cf3e316a4ed9987962b4cbf01604@hyperstone.com> References: <20220312044315.7994-1-michael@allwinnertech.com> <83edf9a1-1712-5388-a3fa-d685f1f581df@intel.com> <88e53cb9-791f-ee58-9be8-76ae9986e0e2@allwinnertech.com> <32b29790-eb5c-dac0-1f91-aede38220914@allwinnertech.com> ,<312d724c-e43f-d766-49fb-9c5b10fe8b07@intel.com> In-Reply-To: <312d724c-e43f-d766-49fb-9c5b10fe8b07@intel.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.1.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-TMASE-Version: DDEI-5.1-8.6.1018-26774.007 X-TMASE-Result: 10--9.729900-10.000000 X-TMASE-MatchedRID: LVkZzMT5mErUL3YCMmnG4vHkpkyUphL9dwX/SSKrKHjVjNsehGf0vQC7 AZSleJMNLomIDFQh53DZZZGAG9uFDUY/tllaHgmN0oNxPV/0KMTVBDonH99+Vq/bdPGXvkG/Zng ixNorteDHyjn2xyeLrBUELlX2mE/eXlJqiTX99kKp3Btb1bH20MnlJe2gk8vIP4H+2nyK0FOK/P cAuVLj1ijPeL52ePwPS8AxUE03d7BYp62gPtNXt7/HywF9D+dAZR+OFNkbtdpAbza1VIHIZU7wF MoiPJlq4vM1YF6AJbYaC1V1wQ87fFZ0V5tYhzdWxEHRux+uk8jHUU+U0ACZwIT257H9q+85MsP+ X06aRAtbjgTjpLMNveg6+HNjHuNbnqg/VrSZEiM= X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-TMASE-INERTIA: 0-0;;;; X-TMASE-XGENCLOUD: 18a9737a-b486-407a-8cc0-72a4f22bf289-0-0-200-0 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >So we are not going to let the block layer know about SD cache? >Or is it a separate change? I have some code for this laying around, but as it requires reading, parsing and writing Function Registers, in particular PEH, it's a lot of boilerplate code to get the functionality, but I'll clean it up and send a patch in the coming weeks. From: Adrian Hunter Sent: Wednesday, March 16, 2022 12:28 PM To: Avri Altman; Michael Wu; ulf.hansson@linaro.org; beanhuo@micron.com; porzio@gmail.com Cc: linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org; allwinner-opensource-support Subject: Re: [PATCH] mmc: block: enable cache-flushing when mmc cache is on ? On 16.3.2022 13.09, Avri Altman wrote: >> Hi Avril & Adrian, >> Thanks for your efforts. Could we have an agreement now -- >> >> 1. enabling-cache and cmd23/reliable-write should be independent; >> >> Here's what I found in the spec JESD84-B51: >>? > 6.6.31 Cache >>? > Caching of data shall apply only for the single block >>? > read/write(CMD17/24), pre-defined multiple block >>? > read/write(CMD23+CMD18/25) and open ended multiple block >>? > read/write(CMD18/25+CMD12) commands and excludes any other access >>? > e.g., to the register space(e.g., CMD6). >> Which means with CMD18/25+CMD12 (without using CMD23), the cache can >> also be enabled. Maybe this could be an evidence of the independence >> between enabling-cache and cmd23/reliable-write? > Acked-by: Avri Altman > > Thanks, > Avri > >> >> 2. We don't consider supporting SD in this change. >> >>? > On 14/03/2022 19:10, Avri Altman wrote: >>? >> Here is what our SD system guys wrote: >>? >> " In SD we don?t support reliable write and this eMMC driver may not >>? >>??? be utilizing the cache feature we added in SD5.0. >>? >>?? The method of cache flush is different between SD and eMMC." >>? >> >>? >> So adding SD seems to be out of scope of this change. >> >> Is there anything else I can do about this patch? Thanks again. So we are not going to let the block layer know about SD cache? Or is it a separate change? = Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz Managing Director: Dr. Jan Peter Berns. Commercial register of local courts: Freiburg HRB381782