All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: cjb@laptop.org, linux-mmc@vger.kernel.org,
	SH-Linux <linux-sh@vger.kernel.org>
Subject: Re: [PATCH] mmc: sh_mmcif: add SET_BLOCK_COUNT support
Date: Thu, 13 Jun 2013 18:01:26 +0900	[thread overview]
Message-ID: <51B98A66.8060902@renesas.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1306131024260.31976@axis700.grange>

Hello Guennadi-san,

(2013/06/13 17:33), Guennadi Liakhovetski wrote:
< snip >
>> +static bool sh_mmcif_send_sbc(struct sh_mmcif_host *host,
>> +			      struct mmc_request *mrq)
>> +{
>> +	struct mmc_request req_orig = *mrq;
>> +	long time;
>> +
>> +	/* Switch the commands around */
>> +	mrq->cmd = mrq->sbc;
>> +	mrq->sbc = NULL;
>> +	mrq->data = NULL;
>> +	mrq->stop = NULL;
>> +
>> +	/* Send SBC Cmd */
>> +	sh_mmcif_start_cmd(host, mrq);
>> +
>> +	/* Normal completion time is less than 1us */
>> +	time = wait_for_completion_interruptible_timeout(&host->sbc_complete,
>> +							 host->timeout);
> 
> I'm afraid this doesn't look like a correct approach to me. In commit 
> f985da1 "mmc: sh_mmcif: process requests asynchronously" I converted the 
> driver to not wait inside its .request() method. This your patch makes a 
> part of the .request() processing synchronous again by adding a wait to 
> it. Besides you're very much special casing the processing of the SBC 
> command. I think, it would be better to process it asynchronously too, 
> implementing it as a sequence of two requests, similar to how sdhci.c does 
> it (see sdhci_request() nearer the end the "if (mrq->sbc...) handling and 
> sdhci_finish_command() below the "Finished CMD23, now send actual 
> command" comment). Would that be possible to convert this patch to execute 
> similarly and to avoid special-casing as much as possible? Just check for 
> an SBC in .request(), if there is one send it instead of the proper 
> request. Then in completion check, whether it's the SBC that has just 
> completed, and if so, now send the actual request.

Thank you for your comment. I should have checked your patch...

I will modify this SBC patch to remove the wait_for_completion...() in
the .request().

Best regards,
Yoshihiro Shimoda

> Thanks
> Guennadi
> 

WARNING: multiple messages have this Message-ID (diff)
From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: cjb@laptop.org, linux-mmc@vger.kernel.org,
	SH-Linux <linux-sh@vger.kernel.org>
Subject: Re: [PATCH] mmc: sh_mmcif: add SET_BLOCK_COUNT support
Date: Thu, 13 Jun 2013 09:01:26 +0000	[thread overview]
Message-ID: <51B98A66.8060902@renesas.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1306131024260.31976@axis700.grange>

Hello Guennadi-san,

(2013/06/13 17:33), Guennadi Liakhovetski wrote:
< snip >
>> +static bool sh_mmcif_send_sbc(struct sh_mmcif_host *host,
>> +			      struct mmc_request *mrq)
>> +{
>> +	struct mmc_request req_orig = *mrq;
>> +	long time;
>> +
>> +	/* Switch the commands around */
>> +	mrq->cmd = mrq->sbc;
>> +	mrq->sbc = NULL;
>> +	mrq->data = NULL;
>> +	mrq->stop = NULL;
>> +
>> +	/* Send SBC Cmd */
>> +	sh_mmcif_start_cmd(host, mrq);
>> +
>> +	/* Normal completion time is less than 1us */
>> +	time = wait_for_completion_interruptible_timeout(&host->sbc_complete,
>> +							 host->timeout);
> 
> I'm afraid this doesn't look like a correct approach to me. In commit 
> f985da1 "mmc: sh_mmcif: process requests asynchronously" I converted the 
> driver to not wait inside its .request() method. This your patch makes a 
> part of the .request() processing synchronous again by adding a wait to 
> it. Besides you're very much special casing the processing of the SBC 
> command. I think, it would be better to process it asynchronously too, 
> implementing it as a sequence of two requests, similar to how sdhci.c does 
> it (see sdhci_request() nearer the end the "if (mrq->sbc...) handling and 
> sdhci_finish_command() below the "Finished CMD23, now send actual 
> command" comment). Would that be possible to convert this patch to execute 
> similarly and to avoid special-casing as much as possible? Just check for 
> an SBC in .request(), if there is one send it instead of the proper 
> request. Then in completion check, whether it's the SBC that has just 
> completed, and if so, now send the actual request.

Thank you for your comment. I should have checked your patch...

I will modify this SBC patch to remove the wait_for_completion...() in
the .request().

Best regards,
Yoshihiro Shimoda

> Thanks
> Guennadi
> 

  reply	other threads:[~2013-06-13  9:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-13  8:03 [PATCH] mmc: sh_mmcif: add SET_BLOCK_COUNT support Shimoda, Yoshihiro
2013-06-13  8:03 ` Shimoda, Yoshihiro
2013-06-13  8:33 ` Guennadi Liakhovetski
2013-06-13  8:33   ` Guennadi Liakhovetski
2013-06-13  9:01   ` Shimoda, Yoshihiro [this message]
2013-06-13  9:01     ` Shimoda, Yoshihiro

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=51B98A66.8060902@renesas.com \
    --to=yoshihiro.shimoda.uh@renesas.com \
    --cc=cjb@laptop.org \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.