From: khilman@baylibre.com (Kevin Hilman)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH] mmc: meson-gx: set max block count to 256
Date: Mon, 30 Jan 2017 08:53:56 -0800 [thread overview]
Message-ID: <m2o9yotrob.fsf@baylibre.com> (raw)
In-Reply-To: <c8f456f5-1722-55d6-58d8-c438d344cbc1@gmail.com> (Heiner Kallweit's message of "Sat, 28 Jan 2017 09:18:50 +0100")
Heiner Kallweit <hkallweit1@gmail.com> writes:
> Am 27.01.2017 um 19:28 schrieb Kevin Hilman:
>> Heiner Kallweit <hkallweit1@gmail.com> writes:
>>
>>> So far max_blk_count isn't set what results in a default of value 8
>>> to be used (PAGE_SIZE / block size).
>>>
>>> Set max_blk_count to 256 as used in the uboot driver.
>>>
>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>
>> Thanks for the patch. A minor comment below:
>>
>>> ---
>>> drivers/mmc/host/meson-gx-mmc.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
>>> index 3308b5b6..030425be 100644
>>> --- a/drivers/mmc/host/meson-gx-mmc.c
>>> +++ b/drivers/mmc/host/meson-gx-mmc.c
>>> @@ -799,6 +799,7 @@ static int meson_mmc_probe(struct platform_device *pdev)
>>> goto free_host;
>>> }
>>>
>>> + mmc->max_blk_count = 256;
>>
>> A step in the right direction, but the # blocks is actually a 9-bit
>> field (c.f. length field of cmd_cfg part of descriptor (bits 8:0).
>>
>> So this should be more like:
>>
>> /* blk count is 'length' field of cmd_cfg part of descriptor */
>> mmc->max_blk_count = CMD_CFG_LENGTH_MASK + 1;
>>
>> I tested that change locally, so after changing that, please resend and
>> feel free to add:
>>
> max_blk_count = 0 means unlimited number of blocks. Therefore I think
> we have to go with: mmc->max_blk_count = CMD_CFG_LENGTH_MASK
Ah, yes. Good catch.
Kevin
> And I figured out later that we also have to set mmc->max_req_size.
>
> In my tests the system never read / wrote more than 8 blocks in a row,
> most likely because the upper block layers use 4k blocks.
>
> Therefore setting max_blk_count doesn't really provide a benefit but
> I think it's cleaner to expose the actual chip limit.
>
>
>> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
>> Tested-by: Kevin Hilman <khilman@baylibre.com>
>>
>> Kevin
>>
prev parent reply other threads:[~2017-01-30 16:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-26 22:09 [PATCH] mmc: meson-gx: set max block count to 256 Heiner Kallweit
2017-01-27 18:28 ` Kevin Hilman
2017-01-28 8:18 ` Heiner Kallweit
2017-01-30 16:53 ` Kevin Hilman [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=m2o9yotrob.fsf@baylibre.com \
--to=khilman@baylibre.com \
--cc=linus-amlogic@lists.infradead.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