linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc <linux-mmc@vger.kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Chris Ball <chris@printf.net>,
	Russell King <linux@arm.linux.org.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH v3 1/3] mmc: mmci: Support any block sizes for ux500v2 and qcom variant
Date: Wed, 10 Sep 2014 10:07:20 +0100	[thread overview]
Message-ID: <541014C8.7050303@linaro.org> (raw)
In-Reply-To: <CAPDyKFqJw0Dc8ac2i0tebJpuHVhUVd=YUnGHZDTHNd2AAJqOtg@mail.gmail.com>

Hi Ulf,

On 10/09/14 08:58, Ulf Hansson wrote:
> On 22 August 2014 06:54, Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> For the ux500v2 variant of the PL18x block, any block sizes are
>> supported. This will make it possible to decrease data overhead
>> for SDIO transfers.
>>
>> This patch is based on Ulf Hansson patch
>> http://www.spinics.net/lists/linux-mmc/msg12160.html
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>          enabled this support on qcom variant.
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> I am not sure how to handle this patch.
>
> It will as you say in the cover letter for this patchset, improve
> situations for the ath6kl driver when it's issuing 12 bytes and 24
> bytes reads and solve those issues.
>
> On the other hand, as stated earlier mmci_pio_write need to be fixed
> to have full support for any block size. That applies to the qcom
> variant as well.
looking at current mmci_pio_write, I see it can support any block sizes 
as it is. Unless Am missing something obvious.

block size aligned to 4 is taken care in the code and is straight forward.
block sizes not aligned to 4 are also partly taken care in pio_write and 
partly by programming blksz in datactrl register. However Am not sure if 
it was safe to handle the buffer pointer out of its boundary.
>
> For ux500, I am sure this won't cause any regressions since the cw1200
> isn't probed. Also, I am not sure the "any block size" support is even
> enabled for that driver.
>
> How about, that we add a comment in the pio_write function describing
> that we need to fix it for "SDIO any block size" support? And leave
> that as a future improvement?

Is below patch any good?
With the below patch It should be possible to address the case where 
buffer passed the length is handled safely. If you ok with the approach 
I can send a patch as RFC.


----cut here----
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 264c947..8480c02 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1134,7 +1134,20 @@ static int mmci_pio_write(struct mmci_host *host, 
char *buffer, unsigned int rem
                  * byte become a 32bit write, 7 bytes will be two
                  * 32bit writes etc.
                  */
-               iowrite32_rep(base + MMCIFIFO, ptr, (count + 3) >> 2);
+               if (unlikely(count & 0x3)) {
+                       unsigned char buf[4] = {0, };
+
+                       if (count < 4) {
+                               memcpy(buf, ptr, count);
+                               iowrite32_rep(base + MMCIFIFO, buf, 1);
+                       } else {
+                               iowrite32_rep(base + MMCIFIFO, ptr, 
count >> 2);
+                               memcpy(buf, ptr + (count & ~0x3), count 
& 0x3);
+                               iowrite32_rep(base + MMCIFIFO, buf, 1);
+                       }
+               } else {
+                       iowrite32_rep(base + MMCIFIFO, ptr, count >> 2);
+               }

                 ptr += count;
                 remain -= count;

----cut here----

thanks,
srini
>
> Kind regards
> Uffe
>
>> ---
>>   drivers/mmc/host/mmci.c | 10 +++++++---
>>   1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
>> index c11cb05..533ad2b 100644
>> --- a/drivers/mmc/host/mmci.c
>> +++ b/drivers/mmc/host/mmci.c
>> @@ -77,6 +77,7 @@ static unsigned int fmax = 515633;
>>    * @qcom_fifo: enables qcom specific fifo pio read logic.
>>    * @reversed_irq_handling: handle data irq before cmd irq.
>>    * @qcom_dml: enables qcom specific dma glue for dma transfers.
>> + * @any_blksize: true if block any sizes are supported
>>    */
>>   struct variant_data {
>>          unsigned int            clkreg;
>> @@ -102,6 +103,7 @@ struct variant_data {
>>          bool                    qcom_fifo;
>>          bool                    reversed_irq_handling;
>>          bool                    qcom_dml;
>> +       bool                    any_blksize;
>>   };
>>
>>   static struct variant_data variant_arm = {
>> @@ -194,6 +196,7 @@ static struct variant_data variant_ux500v2 = {
>>          .pwrreg_clkgate         = true,
>>          .busy_detect            = true,
>>          .pwrreg_nopower         = true,
>> +       .any_blksize            = true,
>>   };
>>
>>   static struct variant_data variant_qcom = {
>> @@ -212,6 +215,7 @@ static struct variant_data variant_qcom = {
>>          .explicit_mclk_control  = true,
>>          .qcom_fifo              = true,
>>          .qcom_dml               = true,
>> +       .any_blksize            = true,
>>   };
>>
>>   static int mmci_card_busy(struct mmc_host *mmc)
>> @@ -239,10 +243,11 @@ static int mmci_card_busy(struct mmc_host *mmc)
>>   static int mmci_validate_data(struct mmci_host *host,
>>                                struct mmc_data *data)
>>   {
>> +       struct variant_data *variant = host->variant;
>> +
>>          if (!data)
>>                  return 0;
>> -
>> -       if (!is_power_of_2(data->blksz)) {
>> +       if (!is_power_of_2(data->blksz) && !variant->any_blksize) {
>>                  dev_err(mmc_dev(host->mmc),
>>                          "unsupported block size (%d bytes)\n", data->blksz);
>>                  return -EINVAL;
>> @@ -796,7 +801,6 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
>>          writel(host->size, base + MMCIDATALENGTH);
>>
>>          blksz_bits = ffs(data->blksz) - 1;
>> -       BUG_ON(1 << blksz_bits != data->blksz);
>>
>>          if (variant->blksz_datactrl16)
>>                  datactrl = MCI_DPSM_ENABLE | (data->blksz << 16);
>> --
>> 1.9.1
>>

  reply	other threads:[~2014-09-10  9:07 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-12 12:02 [PATCH RFC 0/5] mmc: mmci: sdio related fixes Srinivas Kandagatla
2014-08-12 12:03 ` [PATCH RFC 1/5] mmc: mmci: Enable SDIO support for Qualcomm variant data Srinivas Kandagatla
2014-08-12 12:03 ` [PATCH RFC 2/5] mmc: mmci: move block size validation under relevant code Srinivas Kandagatla
2014-08-12 12:04 ` [PATCH RFC 3/5] mmc: mmci: relax blksz check for SDIO Srinivas Kandagatla
2014-08-12 14:12   ` Russell King - ARM Linux
2014-08-13  5:14     ` Srinivas Kandagatla
2014-08-13  8:54       ` Linus Walleij
2014-08-12 12:05 ` [PATCH RFC 4/5] mmc: mmci: Add sdio enable mask in variant data Srinivas Kandagatla
2014-08-13  8:55   ` Linus Walleij
2014-08-12 12:05 ` [PATCH RFC 5/5] mmc: mmci: move ST specific sdio setup under a condition Srinivas Kandagatla
2014-08-13  8:58   ` Linus Walleij
2014-08-13  9:45     ` Srinivas Kandagatla
2014-08-19 11:13 ` [PATCH v2 0/4] mmc: mmci: sdio related fixes Srinivas Kandagatla
2014-08-19 11:14   ` [PATCH v2 1/4] mmc: mmci: Support any block sizes for ux500v2 and qcom variant Srinivas Kandagatla
2014-08-19 12:37     ` Ulf Hansson
2014-08-19 11:14   ` [PATCH v2 2/4] mmc: mmci: move block size validation under relevant code Srinivas Kandagatla
2014-08-19 11:55     ` Ulf Hansson
2014-08-19 12:08       ` Srinivas Kandagatla
2014-08-19 11:15   ` [PATCH v2 3/4] mmc: mmci: Add sdio enable mask in variant data Srinivas Kandagatla
2014-08-19 11:15   ` [PATCH v2 4/4] mmc: mmci: rename sdio flag in vendor data to st_sdio Srinivas Kandagatla
2014-08-22  4:53   ` [PATCH v3 0/3] mmc: mmci: sdio related fixes Srinivas Kandagatla
2014-08-22  4:54     ` [PATCH v3 1/3] mmc: mmci: Support any block sizes for ux500v2 and qcom variant Srinivas Kandagatla
2014-09-10  7:58       ` Ulf Hansson
2014-09-10  9:07         ` Srinivas Kandagatla [this message]
2014-09-10 10:51           ` Ulf Hansson
2015-07-09 21:40       ` Bjorn Andersson
2019-03-05 22:25       ` Linus Walleij
2019-03-06 17:03         ` Bjorn Andersson
2014-08-22  4:54     ` [PATCH v3 2/3] mmc: mmci: Add sdio enable mask in variant data Srinivas Kandagatla
2014-09-10  7:47       ` Ulf Hansson
2014-08-22  4:55     ` [PATCH v3 3/3] mmc: mmci: rename sdio flag in vendor data to st_sdio Srinivas Kandagatla
2014-09-10  7:48       ` Ulf Hansson
2014-09-09  8:34     ` [PATCH] mmc: mmci_qcom_dml: fix is never less than zero warning Srinivas Kandagatla
2014-09-09 11:53       ` Ulf Hansson

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=541014C8.7050303@linaro.org \
    --to=srinivas.kandagatla@linaro.org \
    --cc=chris@printf.net \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=ulf.hansson@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).