linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrei Warkentin <andreiw@motorola.com>
To: "Nath, Arindam" <Arindam.Nath@amd.com>
Cc: Subhash Jadavani <subhashj@codeaurora.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>
Subject: Re: [PATCH v3 01/12] mmc: sdhci: add support for auto CMD23
Date: Sat, 16 Apr 2011 03:17:48 -0500	[thread overview]
Message-ID: <BANLkTimthD=bYat2zPUeL-1As8f4krnB1g@mail.gmail.com> (raw)
In-Reply-To: <6C03668EAF45B747AF947A1603D1B300EB444353@SAUSEXMBP01.amd.com>

On Sat, Apr 16, 2011 at 1:25 AM, Nath, Arindam <Arindam.Nath@amd.com> wrote:
> Hi Subhash,

> Please keep in mind that my patch _only_ adds support for Auto CMD23, and not CMD23. CMD23 support can be made part of block layer, but Auto CMD23 is a feature as per the Host Controller Spec v3.00. So my patch takes care of the second case.

All Auto CMD23 means is that the host sends the command automatically,
instead of having some code do it manually. Auto CMD23 makes no sense
if the block layer doesn't want or need CMD23. Let me explain:
1) Not all cards support CMD23
2) Not all cards that do support CMD23 want to use it for regular
multiblock transfers for performance reasons
3) If you disregard my current patch set, then your changes, if ever
enabled for MMCs, will actually break reliable writes because current
block code sent CMD23 manually (but the CMD23 support patch set fixed
that)

That means you can't just enable it in the host just because you feel
like it. Your current host changes make the host aware of the card
capabilities, and then force policy. This violates layering and makes
everything an unmaintainable mess.

Given the existing work for plumbing normal CMD23 support, you should
take advantage of that. Your current patch does not integrate well
with it, and I've tried to make it specifically very easy to enable
enhancements like Auto-CMD23. Let me help you out:

1) If you have mmc_request->sbc - then you should set your Auto-CMD23
flag and not send mmc_request->sbc.
2) You can forget your "save stop command". The current code should
function correctly as long as you can detect the error condition as
set data->error appropriately. But of course, feel
     free to change it if you see fit. Right now the stop command is
only sent if -
     a) No mmc_request->sbc so this must have been an open-ended
multiblock transfer
     b) An error condition detected in data transfer, so the stop must
be sent anyway

Anyway I'm at your disposal to answer your questions and make sure you
can implement AutoCMD23 support on top of existing MMC subsystem
changes.

A

  parent reply	other threads:[~2011-04-16  8:17 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
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 [this message]
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='BANLkTimthD=bYat2zPUeL-1As8f4krnB1g@mail.gmail.com' \
    --to=andreiw@motorola.com \
    --cc=Arindam.Nath@amd.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=subhashj@codeaurora.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).