Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp510051ybx; Tue, 5 Nov 2019 00:58:13 -0800 (PST) X-Google-Smtp-Source: APXvYqzFuAxwzjzONpikR6uh4Mc1DIu6OVrt+MlN+V7Wt9GYlipMRabL77ER/X9RlLsf67WoCLuA X-Received: by 2002:a17:906:d793:: with SMTP id pj19mr11796646ejb.303.1572944293808; Tue, 05 Nov 2019 00:58:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572944293; cv=none; d=google.com; s=arc-20160816; b=EYSYrRHkfnxVluC2FWIt+2vl/3o0TGugQdpOjyP+MhVksUwKIMEKhuwghMmq440vvM US8hisyLUsnTCI3+LvqPCB8oWkeuufpE24ZFjRYVb/4llRFPai0AwSn5LSd/HLCip30c WYmnacag2O4xRmnJuvrdzBS4Z6ziYJyEts3ju+frR99h98fd8WciGohPEOLUdcyDhqAI pqnPfKns1NejZKNGBqmBUsFik9f3svTqLsb1nt2VyPiO14CQ3sEDbyddZ0Vj7KqIcnxz 4HIxMbm2cW/v4B+3N2tqu+iRiiDqvAIRCWRiGPN/7TjArVlDNa2D7v3nDEoR9vE/hY+m b0ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references:dkim-signature; bh=bceDJHtyc/Gkpk2vkbmTb36e6CcHkOGhOjOBn4t9oXE=; b=it9cF6270uPs0GEQ8HkuPdJeUdJOhrfksw4jOD17WKUqe6kYcfhJh3eX8q6A8+fI5W kiFzaN2/x/dYBqhkKblTYtCQLgUryxMYo3akeShXW6NmR6a8g3p/1rDmb0iroXWZgTVr 9qyOaAg6qxUukyDnD/NX6K00yVyR2b9kAJC1vxMon4H0sBFIN4EyEsEbxdhrZMjDHeTz 0LGKYV5a6vTHyChKQBoW4ysKu0bwqAc8WxQ3hkeZo7EaX/pxS1P0a1xhxlf7XogjwLkQ z3rOFCD+Y1cA9kK8LRgnH3EqNyznGUCvAQ94zggXidzLDq9Ydjz7KnJ3OiGN57kt71O4 Cvqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=BsQ63bXJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d13si1287370edu.135.2019.11.05.00.57.50; Tue, 05 Nov 2019 00:58:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=BsQ63bXJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730579AbfKEIyn (ORCPT + 99 others); Tue, 5 Nov 2019 03:54:43 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:51290 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729765AbfKEIyn (ORCPT ); Tue, 5 Nov 2019 03:54:43 -0500 Received: by mail-wm1-f67.google.com with SMTP id q70so19856694wme.1 for ; Tue, 05 Nov 2019 00:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=bceDJHtyc/Gkpk2vkbmTb36e6CcHkOGhOjOBn4t9oXE=; b=BsQ63bXJSBOvzsjA7Jg0wTxrVHCNvgB2K/zGBlEUeHdSaIjrGH2fSQ/stDcujWWpvN NjVnwf4Io22VUXNP5xyNo96XQEeuh/cpSE5ZpoHbHzUwE+kLb5vdeDX2Dd0anIucf+Cw kLX7nqsnA5L4SZrI3Ow1zQmQclrRIsnJG0RiZDpgsKv8mO2cUqncFscJIXR3Zrld8Mw5 bNKfi5hrQ0dQ3D9TmzYvDTwOF+UMOowZPoYZPZ/sSUwgP4k082zs1ofz4Y8SfPvmikib gPs8WC/qQO3Wtv64xHUTluH2ODQP7J7YgxVitXgd0KFaeoOS/ie/KMSuH5A+5cGpxpmU xnKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=bceDJHtyc/Gkpk2vkbmTb36e6CcHkOGhOjOBn4t9oXE=; b=O7Xki1YRgNKaSxWsynWjMeFfPykY1bKTrU3F2wRXmyu+oMLrb1kF2ZIk+M1PQq5gtx hWalGa3r3jKBA27pVBcUBVWTQKELynJFKnVxtwvkDjUJ4iqLP4M+CwA+MbQMAalPf5CO ZwQqfouYUzAHUvz5ch/xr44Qq1p0u8TiJVRgjNZJKjNsMsJ+6wIojcdZ9tfJIobACzbf U/B+SGkLA+oLhtDK3F5RIUPzQ32jgFbCNNwRPKNfMMWjeDNn9As9MxskkGA1rlIUBtEZ AYt+mRXm7WYjdvSq0Q2NgvyTIY5DIWj4NKN9domckSGzgGLn2WR8FIa0HJ27O++PG15G pRMw== X-Gm-Message-State: APjAAAVIqfP0fJX15z8vIO8MLYFhNHy4G5OF6rvHvnEC+vJ7Wo0vmJut X9lRmY5+MCu3oSQCFxBJJjv+27Ukl1I= X-Received: by 2002:a1c:e91a:: with SMTP id q26mr2934616wmc.32.1572944078270; Tue, 05 Nov 2019 00:54:38 -0800 (PST) Received: from localhost (laubervilliers-658-1-213-31.w90-63.abo.wanadoo.fr. [90.63.244.31]) by smtp.gmail.com with ESMTPSA id b66sm22614377wmh.39.2019.11.05.00.54.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Nov 2019 00:54:37 -0800 (PST) References: <1572868495-84816-1-git-send-email-jianxin.pan@amlogic.com> <1ja79b4mje.fsf@starbuckisacylon.baylibre.com> <1j8sou4u1g.fsf@starbuckisacylon.baylibre.com> <7ec2e682-cfec-395e-cf38-58f050440c40@amlogic.com> User-agent: mu4e 1.3.3; emacs 26.2 From: Jerome Brunet To: Nan Li , Jianxin Pan , Ulf Hansson , Kevin Hilman Cc: Neil Armstrong , "linux-amlogic\@lists.infradead.org" , "linux-mmc\@vger.kernel.org" , "linux-kernel\@vger.kernel.org" , Victor Wan Subject: Re: [PATCH v2] mmc: meson-gx: fix mmc dma operation In-reply-to: <7ec2e682-cfec-395e-cf38-58f050440c40@amlogic.com> Date: Tue, 05 Nov 2019 09:54:36 +0100 Message-ID: <1j7e4e4sab.fsf@starbuckisacylon.baylibre.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 05 Nov 2019 at 09:30, Nan Li wrote: > > Based on Uffe comment I tried something else. > > Basically, it enables chained mode in the driver only when the framework > calls pre/post_req callback. As far as understood, the framework calls > this when there is more than one request pending ... which seems to be > when chained mode actually make sense > > Jerome, what you are talking about is the system framework problem when you call pre/post_req, > > which is not related to the patch I submitted. > > > > I strongly disagree. > As far as I understand from your description, the problem was with the > life cycle of the dma mapping. This is tighly related with pre/post req. > Just the variable names you have picked clearly show that. > > > > As you said, pre/post_req is called only when there is data to implement the chained mode, > > but it is also possible to cause memory consistency problems, > resulting in incorrect data. > > > > The life cycle of the mapping is also taken care of with patch, > since dma mapping is no longer handled in .request(). IOW the mapping, > if any, will be released after the request is done using .post_req() > > If you think otherwise, please elaborate. > > > I see what you mean. You want to pull the pre/post_req operation out of the request interface and invoke it at the top. > > I didn't notice the following modification of patch in your last email and reply in time. I'm really sorry. > > The following patch removes all pre/post_req operations, No it does not. Callbacks are still provided to the MMC framework. > but you do not send out the operation patch added to the upper layer > together. There is no modification needed in the upper layer > > Then the patch is incomplete, which will affect the dma data transfer function in start_cmd function and affect the multi-block write operation. > No it is not incomplete. pre and post request are correctly called. You can check that with ftrace if you want. Maybe you could try it ? > Please send your complete patch, including core layer modification, > thank you. > > > > > > Therefore, this patch is added to make memory consistent and obtain real effective information. > > > > ----8<----- > diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c > index e712315c7e8d..399604b4124d 100644 > --- a/drivers/mmc/host/meson-gx-mmc.c > +++ b/drivers/mmc/host/meson-gx-mmc.c > @@ -126,8 +126,7 @@ > #define SD_EMMC_CFG_CMD_GAP 16 /* in clock cycles */ > #define SD_EMMC_DESC_BUF_LEN PAGE_SIZE > > -#define SD_EMMC_PRE_REQ_DONE BIT(0) > -#define SD_EMMC_DESC_CHAIN_MODE BIT(1) > +#define SD_EMMC_DESC_CHAIN_MODE BIT(0) > > #define MUX_CLK_NUM_PARENTS 2 > > @@ -228,7 +227,6 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc, > struct mmc_data *data = mrq->data; > struct scatterlist *sg; > int i; > - bool use_desc_chain_mode = true; > > /* > * When Controller DMA cannot directly access DDR memory, disable > @@ -251,12 +249,11 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc, > /* check for 8 byte alignment */ > if (sg->offset & 7) { > WARN_ONCE(1, "unaligned scatterlist buffer\n"); > - use_desc_chain_mode = false; > - break; > + return; > } > > - if (use_desc_chain_mode) > - data->host_cookie |= SD_EMMC_DESC_CHAIN_MODE; > + /* The planets are aligned, let's chain them up */ > + data->host_cookie |= SD_EMMC_DESC_CHAIN_MODE; > } > > static inline bool meson_mmc_desc_chain_mode(const struct mmc_data *data) > @@ -278,7 +275,6 @@ static void meson_mmc_pre_req(struct mmc_host *mmc, struct mmc_request *mrq) > return; > > meson_mmc_get_transfer_mode(mmc, mrq); > - data->host_cookie |= SD_EMMC_PRE_REQ_DONE; > > if (!meson_mmc_desc_chain_mode(data)) > return; > @@ -803,25 +799,11 @@ static void meson_mmc_start_cmd(struct mmc_host *mmc, struct mmc_command *cmd) > static void meson_mmc_request(struct mmc_host *mmc, struct mmc_request *mrq) > { > struct meson_host *host = mmc_priv(mmc); > - bool needs_pre_post_req = mrq->data && > - !(mrq->data->host_cookie & SD_EMMC_PRE_REQ_DONE); > - > - if (needs_pre_post_req) { > - meson_mmc_get_transfer_mode(mmc, mrq); > - if (!meson_mmc_desc_chain_mode(mrq->data)) > - needs_pre_post_req = false; > - } > - > - if (needs_pre_post_req) > - meson_mmc_pre_req(mmc, mrq); > > /* Stop execution */ > writel(0, host->regs + SD_EMMC_START); > > meson_mmc_start_cmd(mmc, mrq->sbc ?: mrq->cmd); > - > - if (needs_pre_post_req) > - meson_mmc_post_req(mmc, mrq, 0); > } > > static void meson_mmc_read_resp(struct mmc_host *mmc, struct mmc_command *cmd) > ---->8----- > > No performance hit AFAICT. > From your description, it should address your problem too. > > > > > diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c > index e712315..7667e8a 100644 > --- a/drivers/mmc/host/meson-gx-mmc.c > +++ b/drivers/mmc/host/meson-gx-mmc.c > @@ -173,6 +173,7 @@ struct meson_host { > int irq; > > bool vqmmc_enabled; > + bool needs_pre_post_req; > }; > > #define CMD_CFG_LENGTH_MASK GENMASK(8, 0) > @@ -654,6 +655,8 @@ static void meson_mmc_request_done(struct mmc_host *mmc, > struct meson_host *host = mmc_priv(mmc); > > host->cmd = NULL; > + if (host->needs_pre_post_req) > + meson_mmc_post_req(mmc, mrq, 0); > mmc_request_done(host->mmc, mrq); > } > > @@ -803,25 +806,23 @@ static void meson_mmc_start_cmd(struct mmc_host *mmc, struct mmc_command *cmd) > static void meson_mmc_request(struct mmc_host *mmc, struct mmc_request *mrq) > { > struct meson_host *host = mmc_priv(mmc); > - bool needs_pre_post_req = mrq->data && > + > + host->needs_pre_post_req = mrq->data && > !(mrq->data->host_cookie & SD_EMMC_PRE_REQ_DONE); > > - if (needs_pre_post_req) { > + if (host->needs_pre_post_req) { > meson_mmc_get_transfer_mode(mmc, mrq); > if (!meson_mmc_desc_chain_mode(mrq->data)) > - needs_pre_post_req = false; > + host->needs_pre_post_req = false; > } > > - if (needs_pre_post_req) > + if (host->needs_pre_post_req) > meson_mmc_pre_req(mmc, mrq); > > /* Stop execution */ > writel(0, host->regs + SD_EMMC_START); > > meson_mmc_start_cmd(mmc, mrq->sbc ?: mrq->cmd); > - > - if (needs_pre_post_req) > - meson_mmc_post_req(mmc, mrq, 0); > } > > static void meson_mmc_read_resp(struct mmc_host *mmc, struct mmc_command *cmd)