From: Andrei Warkentin <andreiw@motorola.com>
To: "Nath, Arindam" <Arindam.Nath@amd.com>, linux-mmc@vger.kernel.org
Subject: Re: [PATCH v3 01/12] mmc: sdhci: add support for auto CMD23
Date: Fri, 15 Apr 2011 15:04:03 -0500 [thread overview]
Message-ID: <BANLkTikoAWEMGOAHrxJT4jNknVFtyuhdqw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTimfQo7wJ3_ecs64VSp7xKJrjYdJ3w@mail.gmail.com>
+linux-mmc
On Fri, Apr 15, 2011 at 3:03 PM, Andrei Warkentin <andreiw@motorola.com> wrote:
> On Fri, Apr 15, 2011 at 1:57 PM, Andrei Warkentin <andreiw@motorola.com> wrote:
>> Hi Arindam,
>>
>> On Fri, Apr 15, 2011 at 12:34 PM, Nath, Arindam <Arindam.Nath@amd.com> wrote:
>>> Hi Andrei,
>>
>>>>
>>>> I've recently posted changes relating to CMD23 support in block layer.
>>>> Effectively, in order to support hosts with and without Auto-CMD23
>>>> (and with proper error handling) there is a new MMC_CAP_CMD23 for the
>>>> host, and a new field "mmc_command sbc" inside the mmc_request.
>>>>
>>>> I also have a patch enabling CMD23 use with an SDHCI host (< 3.00).
>>>>
>>>> Could you be so kind as to rebase this patch on top of that? You're
>>>> doing a lot of things here that you really shouldn't be (like
>>>> enforcing policy on what gets sent to cards, knowing what's connected
>>>> to the host, conflicting with reliable writes code if Auto-CMD23 was
>>>> enabled for MMCs, not supporting MMCs which always have
>>>> SET_BLOCK_COUNT).
>>>
>>> Our Host Controller is complaint to the Host Controller Spec v3.00, and since Auto CMD23 is a feature added to the HC, I thought it would be better to make this feature part of sdhci and not the core/block layer.
>>>
>>> But in case you want Auto CMD23 to be implemented in a different way, it would rather be great if you help me implement in your own way, and then probably based on community suggestions, we can keep either of the patch.
>>
>> Let me clarify:
>>
>> 1) Sending CMD23 on multiblock transfers is not a an SDHCI specific
>> feature. It's a feature of MMC cards and SD cards operating at UHS104
>> or greater.
>> 2) CMD23-bounded multi block writes are a generic problem already -
>> eMMC reliable writes, for example.
>> 3) CMD23 is not bound to any specific controller - so having generic
>> code to allow execution of CMD23 will speed up transfers (and enable
>> certain features) on any host.
>> 4) Auto-CMD is a specific SDHCI enhancement, meant to reduce overhead
>> of sending CMD23.
>> 5) Host controller has to be aware of CMD23 sending, because on an
>> error STOP has to be sent, and without error, no STOP has to be sent.
>>
>> You are in a unique position where you have functional SDHCI 3.0
>> hardware and are able to test Auto-CMD23. Please look at the patch set
>> I sent - it should be trivial to extend current SDHCI patch to use
>> Auto-CMD23 when possible instead of sending mmc_request->sbc.
>> Basically, I have a generic improvement that affects all host
>> controllers. Auto-CMD23 is an optimization of that for SDHCI 3.0.
>>
>> Your current patch to enable Auto-CMD23 is not useful as far as non-SD
>> cards are concerned and you push way to much policy and
>> non-host-related complexity into it.
>>
>> Thanks,
>> A
>>
>
> More clarification:
>
> The block layer patch may change slightly (whitelisting/blacklisting
> certain MMC devices for using CMD23 for multiblock transfers), but the
> changes to mmc_request and SDHCI are not. So feel free to rebase it
> without waiting for anything. If you need help, I will gladly help
> you, but keep in mind I don't have SDHCI 3.0 hardware around.
>
> Thanks,
> A
>
next prev parent reply other threads:[~2011-04-15 20:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-15 10:38 [PATCH v3 00/12] add support for host controller v3.00 Arindam Nath
2011-04-15 10:38 ` [PATCH v3 01/12] mmc: sdhci: add support for auto CMD23 Arindam Nath
[not found] ` <BANLkTimZGonC+D0czjiY4i7pFFW=upj_qw@mail.gmail.com>
[not found] ` <6C03668EAF45B747AF947A1603D1B300EB443FB6@SAUSEXMBP01.amd.com>
[not found] ` <BANLkTimEKQceSiuL=dX2yhMw+MLu7BzLvQ@mail.gmail.com>
[not found] ` <BANLkTimfQo7wJ3_ecs64VSp7xKJrjYdJ3w@mail.gmail.com>
2011-04-15 20:04 ` Andrei Warkentin [this message]
2011-04-16 5:25 ` Nath, Arindam
2011-04-16 9:07 ` Andrei Warkentin
2011-04-16 9:40 ` Nath, Arindam
2011-04-16 10:04 ` Andrei Warkentin
2011-04-16 6:17 ` Subhash Jadavani
2011-04-16 6:25 ` Nath, Arindam
2011-04-16 6:37 ` Subhash Jadavani
2011-04-16 6:43 ` Nath, Arindam
2011-04-16 8:20 ` Andrei Warkentin
2011-04-16 8:17 ` Andrei Warkentin
2011-04-15 10:38 ` [PATCH v3 02/12] mmc: sd: add support for signal voltage switch procedure Arindam Nath
2011-04-15 10:38 ` [PATCH v3 03/12] mmc: sd: query function modes for uhs cards Arindam Nath
2011-04-15 10:38 ` [PATCH v3 04/12] mmc: sd: add support for driver type selection Arindam Nath
2011-04-15 10:38 ` [PATCH v3 05/12] mmc: sdhci: reset sdclk before setting high speed enable Arindam Nath
2011-04-15 10:38 ` [PATCH v3 06/12] mmc: sd: add support for uhs bus speed mode selection Arindam Nath
2011-04-15 10:38 ` [PATCH v3 07/12] mmc: sd: set current limit for uhs cards Arindam Nath
2011-04-15 14:06 ` [PATCH v3 00/12] add support for host controller v3.00 Chris Ball
2011-04-15 14:06 ` Nath, Arindam
2011-04-26 5:52 ` Nath, Arindam
2011-04-26 12:50 ` Chris Ball
2011-04-26 13:02 ` Wolfram Sang
2011-04-26 13:19 ` Chris Ball
2011-04-26 15:30 ` Philip Rakity
2011-04-26 15:41 ` Chris Ball
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=BANLkTikoAWEMGOAHrxJT4jNknVFtyuhdqw@mail.gmail.com \
--to=andreiw@motorola.com \
--cc=Arindam.Nath@amd.com \
--cc=linux-mmc@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 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).