> -Original Message-
> From: Subhash Jadavani [mailto:subha...@codeaurora.org]
> Sent: Saturday, April 16, 2011 12:07 PM
> To: Nath, Arindam; 'Andrei Warkentin'; linux-mmc@vger.kernel.org
> Subject: RE: [PATCH v3 01/12] mmc: sdhci: add support for auto CMD23
>
>
>
> > -Original Messa
> -Original Message-
> From: Nath, Arindam [mailto:arindam.n...@amd.com]
> Sent: Saturday, April 16, 2011 11:56 AM
> To: Subhash Jadavani; 'Andrei Warkentin'; linux-mmc@vger.kernel.org
> Subject: RE: [PATCH v3 01/12] mmc: sdhci: add support for auto CMD23
>
> Hi Subhash,
>
>
> > -O
Hi Subhash,
> -Original Message-
> From: Subhash Jadavani [mailto:subha...@codeaurora.org]
> Sent: Saturday, April 16, 2011 11:47 AM
> To: 'Andrei Warkentin'; Nath, Arindam; linux-mmc@vger.kernel.org
> Subject: RE: [PATCH v3 01/12] mmc: sdhci: add support for auto CMD23
>
> > -Origin
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Andrei Warkentin
> Sent: Saturday, April 16, 2011 1:34 AM
> To: Nath, Arindam; linux-mmc@vger.kernel.org
> Subject: Re: [PATCH v3 01/12] mmc: sdhci: add support for auto CMD
Hi Andrei,
> -Original Message-
> From: Andrei Warkentin [mailto:andr...@motorola.com]
> Sent: Saturday, April 16, 2011 1:34 AM
> To: Nath, Arindam; linux-mmc@vger.kernel.org
> Subject: Re: [PATCH v3 01/12] mmc: sdhci: add support for auto CMD23
>
> +linux-mmc
>
> On Fri, Apr 15, 2011 a
SD cards operating at UHS104 or better support SET_BLOCK_COUNT.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin
---
drivers/mmc/card/block.c |9 ++---
drivers/mmc/core/sd.c|1 +
include/linux/mmc/card.h |1 +
include/linux/mmc/sd
Implements support for multiblock transfers bounded
by SET_BLOCK_COUNT (CMD23).
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin
---
drivers/mmc/host/sdhci.c | 60 +
1 files changed, 44 insertions(+), 16
CMD23-prefixed instead of open-ended multiblock transfers
have a performance advantage on some MMC cards.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin
---
drivers/mmc/card/block.c | 112 +
include/linu
On Fri, 15 Apr 2011, Chris Ball wrote:
> Hi,
>
> On Thu, Apr 14 2011, Chris Ball wrote:
> > Here's a sample disassembly of one function on ARM with gcc-4.6.0, and
> > diff -y. Explicit memset (which calls __memzero) on the left, and {0}
> > initializer (which calls memset) on the right:
>
> (I
Hi!
> > Yes, if all the consumers of mmc_command memset the structure to 0, there
> > will be no problem. But just reviewed the code, and found mmc_app_cmd() (in
> > sd_ops.c) didn't memset the command structure. So I think if we can make
> > sure all the command structures will be initialized befo
Hi!
> >> > mmc0: error -95 whilst initialising SD card
> >>
> >> That's interesting. Would you mind trying to bisect? (Knowing whether
> >> 2.6.38 final does it, for example, would be very helpful.)
> >
> > It may need one or two tries on 2.6.38 but it's there too.
> >
> >> There aren't many -EO
+linux-mmc
On Fri, Apr 15, 2011 at 3:03 PM, Andrei Warkentin wrote:
> On Fri, Apr 15, 2011 at 1:57 PM, Andrei Warkentin
> wrote:
>> Hi Arindam,
>>
>> On Fri, Apr 15, 2011 at 12:34 PM, Nath, Arindam wrote:
>>> Hi Andrei,
>>
I've recently posted changes relating to CMD23 support in blo
On Fri, Apr 15, 2011 at 1:08 PM, Guennadi Liakhovetski
wrote:
> Currently there is a race in the MMC core between a card-detect
> rescan work and the clock-gating work, scheduled from a command
> completion. Fix it by removing the dedicated clock-gating mutex and
> using the MMC standard locking m
Signed-off-by: Guennadi Liakhovetski
Cc: Simon Horman
Cc: Magnus Damm
---
arch/sh/boards/mach-ecovec24/setup.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/sh/boards/mach-ecovec24/setup.c
b/arch/sh/boards/mach-ecovec24/setup.c
index bb13d0e..3a32741 100644
--
Adding support for runtime power-management to the MMCIF driver allows
it to save power as long as no card is present. System-wide power
management has been verified with experimental PM patches on AP4-
based systems.
Signed-off-by: Guennadi Liakhovetski
Cc: Simon Horman
Cc: Magnus Damm
---
To
The MMC subsystem does not guarantee, that host driver .request() and
.set_ios() callbacks are serialised. Such concurrent calls, however,
do not have to be meaningfully supported, drivers just have to make
sure to avoid any severe problems.
Signed-off-by: Guennadi Liakhovetski
Cc: Simon Horman
This patch-series adds locking to the sh-mobile MMCIF driver to protect
against theoretical races between IO-requests and configuration and
implements power-management, based on recent experimental patches from
Magnus for the AP4 (sh7372) SoC.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Fr
Currently there is a race in the MMC core between a card-detect
rescan work and the clock-gating work, scheduled from a command
completion. Fix it by removing the dedicated clock-gating mutex and
using the MMC standard locking mechanism instead.
Signed-off-by: Guennadi Liakhovetski
Cc: Simon Horm
Hi,
On Thu, Apr 14 2011, Chris Ball wrote:
> Here's a sample disassembly of one function on ARM with gcc-4.6.0, and
> diff -y. Explicit memset (which calls __memzero) on the left, and {0}
> initializer (which calls memset) on the right:
(I checked on x86_64 too, and the code's identical -- it's
+Arindam (This is the patch set I mentioned)
On Fri, Apr 15, 2011 at 2:10 AM, Andrei Warkentin wrote:
> On Thu, Apr 14, 2011 at 6:18 PM, Chris Ball wrote:
>>
>> If we've seen a card that freaks out and loses significant bandwidth, that
>> would be a good reason to start with a whitelist. If all
Hi Chris,
> -Original Message-
> From: Chris Ball [mailto:c...@laptop.org]
> Sent: Friday, April 15, 2011 7:36 PM
> To: Nath, Arindam
> Cc: linux-mmc@vger.kernel.org; subha...@codeaurora.org;
> prak...@marvell.com; zhangfei@gmail.com; Su, Henry; Lu, Aaron;
> anath@gmail.com
> Subj
Hi Arindam,
On Fri, Apr 15 2011, Arindam Nath wrote:
> V3
Thanks very much for reposting this! I know it's a lot of work to keep
track of so many comments and changes.
I've checked that this applies to mmc-next and doesn't add any compile
warnings, and the patch quality (particularly your use o
Host Controller v3.00 can support retuning modes 1,2 or 3 depending on
the bits 46-47 of the Capabilities register. Also, the timer count for
retuning is indicated by bits 40-43 of the same register. We initialize
timer_list for retuning the first time we execute tuning procedure. This
condition is
Host Controller v3.00 supports programmable clock mode as an optional
feature. The support for this mode is indicated by non-zero value in
bits 48-55 of the Capabilities register. If supported, the actual
value of Clock Multiplier is one more than the value provided in the
bit fields. We only set C
According to the Host Controller spec v3.00, setting Preset Value Enable
in the Host Control2 register lets SDCLK Frequency Select, Clock Generator
Select and Driver Strength Select to be set automatically by the Host
Controller based on the UHS-I mode set. This patch enables this feature.
We also
Host Controller needs tuning during initialization to operate SDR50
and SDR104 UHS-I cards. Whether SDR50 mode actually needs tuning is
indicated by bit 45 of the Host Controller Capabilities register.
A new command CMD19 has been defined in the Physical Layer spec
v3.01 to request the card to send
Since only UHS-I cards respond with S18A set in response to ACMD41,
we set the card as ultra-high-speed after successfull initialization.
We need to decide whether a card is SDXC based on the C_SIZE field
of CSDv2.0 register. According to Physical Layer spec v3.01, the
minimum value of C_SIZE for S
We decide on the current limit to be set for the card based on the
Capability of Host Controller to provide current at 1.8V signalling,
and the maximum current limit of the card as indicated by CMD6
mode 0. We then set the current limit for the card using CMD6 mode 1.
As per the Physical Layer Spec
This patch adds support for setting UHS-I bus speed mode during UHS-I
initialization procedure. Since both the host and card can support
more than one bus speed, we select the highest speed based on both of
their capabilities. First we set the bus speed mode for the card using
CMD6 mode 1, and then
As per Host Controller spec v3.00, we reset SDCLK before setting
High Speed Enable, and then set it back to avoid generating clock
gliches. Before enabling SDCLK again, we make sure the clock is
stable, so we use sdhci_set_clock().
Signed-off-by: Arindam Nath
---
drivers/mmc/host/sdhci.c | 27
This patch adds support for setting driver strength during UHS-I
initialization prcedure. Since UHS-I cards set S18A (bit 24) in
response to ACMD41, we use this as a base for UHS-I initialization.
We modify the parameter list of mmc_sd_get_cid() so that we can
save the ROCR from ACMD41 to check whe
SD cards which conform to Physical Layer Spec v3.01 can support
additional Bus Speed Modes, Driver Strength, and Current Limit
other than the default values. We use CMD6 mode 0 to read these
additional card functions. The values read here will be used
during UHS-I initialization steps.
Signed-off-
Host Controller v3.00 adds another Capabilities register. Apart
from other things, this new register indicates whether the Host
Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec
doesn't mention about explicit support for SDR12 and SDR25 UHS-I
modes, so the Host Controller v3.00 sho
Host Controller v3.00 and later support Auto CMD23 in the Transfer
Mode register. Since Auto CMD23 can be used with or without DMA,
and if used with DMA, it should _only_ be ADMA, we check against
SDHCI_USE_SDMA not being set. This flag is reset when SDHCI_USE_ADMA
is set.
A new definition for SDH
V3
[01/12]: Changed function name from *_auto_cmd23_supported() to
*_auto_cmd23_required().
[02/12]: Set bit 24 and bit 28 of OCR within mmc_sd_get_cid(),
and only retry sending ACMD41 with bit 24 reset in case
signal voltage switch procedure fails.
[02/12]: Change (
On 06/04/11 20:07, Per Forlin wrote:
> Previously there has only been one function mmc_wait_for_req
> to start and wait for a request. This patch adds
> * mmc_start_req - starts a request wihtout waiting
> * mmc_wait_for_req_done - waits until request is done
> * mmc_pre_req - asks the host driv
On Thu, Apr 14, 2011 at 6:18 PM, Chris Ball wrote:
>
> If we've seen a card that freaks out and loses significant bandwidth, that
> would be a good reason to start with a whitelist. If all the data we have
> suggests that it's performance-wise either a win or a no-op, that's a fine
> reason to pu
37 matches
Mail list logo
