linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Mason <slash.tmp@free.fr>, linux-mmc <linux-mmc@vger.kernel.org>
Cc: Shawn Lin <shawn.lin@rock-chips.com>,
	Michal Simek <michal.simek@xilinx.com>,
	Soren Brinkmann <soren.brinkmann@xilinx.com>,
	Suman Tripathi <stripathi@apm.com>, Arnd Bergmann <arnd@arndb.de>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Sebastian Frias <sf84@laposte.net>,
	Anton Vorontsov <anton@enomsg.org>,
	Pierre Ossman <pierre@ossman.eu>
Subject: Re: mmc0: Invalid maximum block size, assuming 512 bytes
Date: Tue, 2 Feb 2016 13:30:39 +0200	[thread overview]
Message-ID: <56B0935F.7080503@intel.com> (raw)
In-Reply-To: <56B08106.9090708@free.fr>

On 02/02/16 12:12, Mason wrote:
> On 02/02/2016 09:58, Adrian Hunter wrote:
>> On 01/02/16 23:32, Mason wrote:
>>> On 22/01/2016 08:17, Mason wrote:
>>>
>>>> On 22/01/2016 03:07, Shawn Lin wrote:
>>>>
>>>>> On 2016/1/21 23:00, Mason wrote:
>>>>>
>>>>>> So that means I have to write code in
>>>>>> drivers/mmc/host/sdhci-of-arasan.c correct?
>>>>>
>>>>> It depends. If you think 512 block size if okay for you, leave it alone.
>>>>> Otherwise, add it in drivers/mmc/host/sdhci-of-arasan.c :)
>>>>
>>>> When I measured the read/write throughput to an attached
>>>> SD card, I got around 16 MB/s, and I thought raising the
>>>> block size might help with throughput?
>>>>
>>>> I'll test and report back.
>>>
>>> Haven't had time to test yet, but I wanted to ask experienced
>>> folks what to expect when raising the block size from 512 to
>>> 2048 bytes?
>>
>> mmc block driver sets block size to 512.
>>
>> What you are looking at is maximum block size.  SDIO uses bigger block
>> sizes, so it is useful for that.
> 
> You're right. I was looking at this block of code:
> 
> 	/*
> 	 * Maximum block size. This varies from controller to controller and
> 	 * is specified in the capabilities register.
> 	 */
> 	if (host->quirks & SDHCI_QUIRK_FORCE_BLK_SZ_2048) {
> 		mmc->max_blk_size = 2;
> 	} else {
> 		mmc->max_blk_size = (caps[0] & SDHCI_MAX_BLOCK_MASK) >>
> 				SDHCI_MAX_BLOCK_SHIFT;
> 		if (mmc->max_blk_size >= 3) {
> 			pr_warn("%s: Invalid maximum block size, assuming 512 bytes\n",
> 				mmc_hostname(mmc));
> 			mmc->max_blk_size = 0;
> 		}
> 	}
> 
> 	mmc->max_blk_size = 512 << mmc->max_blk_size;
> 
> 
> As Shawn pointed out, this was updated by commit 0633f654241
> 
> Author: Anton Vorontsov
> Date:   Tue Mar 17 00:14:03 2009 +0300
> 
>     sdhci: Add quirk for forcing maximum block size to 2048 bytes
>     
>     FSL eSDHC controllers can support maximum block size up to 4096 bytes,
>     the MBL (Maximum Block Length) field in the capabilities register
>     extended by one bit, and is set to 0x3.
>     
>     But the SDHCI core doesn't support blocks of 4096 bytes, and thus
>     forces blksz to the lowest value -- 512 bytes. With this patch we can
>     pin up the blksz to the maximum supported block size, i.e. 2048 bytes.
> 
> 
> But I'm wondering if the 2048-byte limitation in SDHCI core is
> still present?

The block size field of the Block Size register is only 12 bits, so yes.

> 
> I see some drivers apparently setting it to a higher value:
> 
> host/atmel-mci.c:	mmc->max_blk_size = 32768;
> host/dw_mmc.c:		mmc->max_blk_size = 65536;
> host/wbsd.c:		mmc->max_blk_size = 4087;

Sure, but not SDHCI.


      reply	other threads:[~2016-02-02 11:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19 15:33 mmc0: Invalid maximum block size, assuming 512 bytes Mason
2016-01-20  1:17 ` Shawn Lin
2016-01-21 15:00   ` Mason
2016-01-22  2:07     ` Shawn Lin
2016-01-22  7:17       ` Mason
2016-02-01 21:32         ` Mason
2016-02-02  8:58           ` Adrian Hunter
2016-02-02 10:12             ` Mason
2016-02-02 11:30               ` Adrian Hunter [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=56B0935F.7080503@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=anton@enomsg.org \
    --cc=arnd@arndb.de \
    --cc=linux-mmc@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=pierre@ossman.eu \
    --cc=sf84@laposte.net \
    --cc=shawn.lin@rock-chips.com \
    --cc=slash.tmp@free.fr \
    --cc=soren.brinkmann@xilinx.com \
    --cc=stripathi@apm.com \
    --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).