mirror of https://lore.kernel.org/linux-amlogic/
 help / color / mirror / Atom feed
From: Nan Li <Nan.Li@amlogic.com>
To: Jerome Brunet <jbrunet@baylibre.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Jianxin Pan <Jianxin.Pan@amlogic.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Kevin Hilman <khilman@baylibre.com>
Cc: "linux-amlogic@lists.infradead.org"
	<linux-amlogic@lists.infradead.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Victor Wan <victor.wan@amlogic.com>
Subject: Re: [PATCH] mmc: fix mmc dma operation
Date: Tue, 22 Oct 2019 02:45:02 +0000	[thread overview]
Message-ID: <8fc785d5-78a7-6933-8462-22d4afa24068@amlogic.com> (raw)
In-Reply-To: <1jwocybgpw.fsf@starbuckisacylon.baylibre.com>

在 2019/10/21 17:17, Jerome Brunet 写道:
> On Mon 21 Oct 2019 at 09:57, Neil Armstrong <narmstrong@baylibre.com> wrote:
>
>> Hi,
>>
>> Thanks for the fix.
>>
>> First, you should add "mmc: meson-gx:" in the subject.
>>
>> On 21/10/2019 07:59, Jianxin Pan wrote:
>>> From: Nan Li <nan.li@amlogic.com>
>>>
>>> In MMC dma transfer, the region requested by dma_map_sg() may be released
>>> by dma_unmap_sg() before the transfer is completed.
>>>
>>> Put the unmap operation in front of mmc_request_done() to avoid this.
> Since we have seen this problem (yet), could you briefly how you've
> triggered it ?

The problem we found in the stress test was that the sdio device was 
constantly operated on and off electricity to make it repeatedly 
initialized.

During the test, we found that there was a chance that the information 
read by the controller from the sdio device side was wrong, which made 
the sdio initialization fail.

>> You should add a "Fixes:" tag so it can be backported on stable kernels.
>>
>>> Signed-off-by: Nan Li <nan.li@amlogic.com>
>>> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
>>> ---
>>>   drivers/mmc/host/meson-gx-mmc.c | 15 ++++++++-------
>>>   1 file changed, 8 insertions(+), 7 deletions(-)
>>>
>>> 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);
>>>   }
> The code around all this is getting quite difficult to follow eventhough
> it does not actually do much
>
> The root of the problem seems be that meson_mmc_pre_req() and
> meson_mmc_post_req() are passed to framework but also called manually
> from meson_mmc_request().
>
> Because of this, some code is added to make sure we don't do things twice.
> Maybe I'm missing something but it look weird ? Ulf, could you give us
> your view ?
>
> As far as I can tell:
>   * pre_req : determine if we use CHAIN_MODE or not AND
>               dma_map_sg() if we do
>   * post_req : dma_unmap_sg() if previously allocated
>
> Do we really need to do all this meson_mmc_request() ? Shouldn't we let the
> framework do the calls to pre/post_req for us ?
>
>>>   
>>>   static void meson_mmc_read_resp(struct mmc_host *mmc, struct mmc_command *cmd)
>>>
>> Neil


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

      parent reply	other threads:[~2019-10-22  2:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-21  5:59 Jianxin Pan
2019-10-21  7:57 ` Neil Armstrong
2019-10-21  8:23   ` Jianxin Pan
2019-10-21  9:17   ` Jerome Brunet
2019-10-21 14:48     ` Ulf Hansson
2019-10-21 15:36       ` Jerome Brunet
2019-10-22  2:45     ` Nan Li [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8fc785d5-78a7-6933-8462-22d4afa24068@amlogic.com \
    --to=nan.li@amlogic.com \
    --cc=Jianxin.Pan@amlogic.com \
    --cc=jbrunet@baylibre.com \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=ulf.hansson@linaro.org \
    --cc=victor.wan@amlogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®