On Wednesday, January 22, 2014 03:23 PM, Sascha Hauer wrote:
On Wed, Jan 22, 2014 at 03:19:48PM +0800, Chris Ruehl wrote:
On Wednesday, January 22, 2014 02:42 PM, Sascha Hauer wrote:
On Wed, Jan 22, 2014 at 12:32:39PM +0800, Chris Ruehl wrote:
Function mxcmci_request() throw an exception on a
On 20 January 2014 04:55, Seungwon Jeon tgih@samsung.com wrote:
Hi Ulf,
On Sat, January 18, 2014, Ulf Hansson wrote:
On 16 January 2014 11:50, Ulf Hansson ulf.hans...@linaro.org wrote:
On 15 January 2014 15:10, Seungwon Jeon tgih@samsung.com wrote:
This change distinguishes DDR
On 22/01/14 17:00, Ulf Hansson wrote:
Hosts supporting MMC_CAP_WAIT_WHILE_BUSY shall not be waiting for busy
detection completion in the recovery path, which were the case when
using R1B response.
Start using R1 as response instead to align behavior, no matter if
MMC_CAP_WAIT_WHILE_BUSY is
On 22/01/14 17:00, Ulf Hansson wrote:
If the host controller supports busy detection in HW, we expect the
MMC_CAP_WAIT_WHILE_BUSY to be set. Likewise the corresponding
host-max_busy_timeout shall reflect the maximum busy detection timeout
supported by the host. A timeout set to zero, is
On 22/01/14 17:00, Ulf Hansson wrote:
When sending the sleep command for host drivers supporting
MMC_CAP_WAIT_WHILE_BUSY, we need to confirm that max_busy_timeout is
big enough comparing to the sleep timeout specified from card's
EXT_CSD. If this isn't case, we use a R1 response instead of R1B
Some error or warning messages that appear on one line in the kernel
log are split on two lines in sdhci.c although they are not too long
to fit on one 80-characters line.
This impairs grep'ping for them, so unsplit them.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
On 23 January 2014 11:09, Adrian Hunter adrian.hun...@intel.com wrote:
On 22/01/14 17:00, Ulf Hansson wrote:
Hosts supporting MMC_CAP_WAIT_WHILE_BUSY shall not be waiting for busy
detection completion in the recovery path, which were the case when
using R1B response.
Start using R1 as
On 23 January 2014 11:10, Adrian Hunter adrian.hun...@intel.com wrote:
On 22/01/14 17:00, Ulf Hansson wrote:
If the host controller supports busy detection in HW, we expect the
MMC_CAP_WAIT_WHILE_BUSY to be set. Likewise the corresponding
host-max_busy_timeout shall reflect the maximum busy
On 23 January 2014 11:23, Adrian Hunter adrian.hun...@intel.com wrote:
On 22/01/14 17:00, Ulf Hansson wrote:
When sending the sleep command for host drivers supporting
MMC_CAP_WAIT_WHILE_BUSY, we need to confirm that max_busy_timeout is
big enough comparing to the sleep timeout specified from
On 23/01/14 15:21, Ulf Hansson wrote:
On 23 January 2014 11:09, Adrian Hunter adrian.hun...@intel.com wrote:
On 22/01/14 17:00, Ulf Hansson wrote:
Hosts supporting MMC_CAP_WAIT_WHILE_BUSY shall not be waiting for busy
detection completion in the recovery path, which were the case when
using
Hi Will,
Wow , Thank you very much for your kindly help to me .
I think the suggestions you mentioned are very very important and useful to me ,
I am really a freshman in Linux Opensource Community .
As for the patch ,
The reason why use PAGE_SIZE to decide to use vmalloc or kmalloc is that
If
On 23 January 2014 15:29, Adrian Hunter adrian.hun...@intel.com wrote:
On 23/01/14 15:21, Ulf Hansson wrote:
On 23 January 2014 11:09, Adrian Hunter adrian.hun...@intel.com wrote:
On 22/01/14 17:00, Ulf Hansson wrote:
Hosts supporting MMC_CAP_WAIT_WHILE_BUSY shall not be waiting for busy
Some toolchains include asm-generic/int-l64.h from their asm/types.h
file for certain 64-bit architectures. This causes a conflict between
types like this one:
asm-generic/int-l64.h:28:25: error: conflicting types for '__s64'
typedef __signed__ long __s64;
^
In file included from
Field Firmware Update feature is new for 5.0 spec.
Code written per JESD84-B50.pdf spec available from:
http://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc
Signed-off-by: Grant Grundler grund...@chromium.org
---
This patch needs to be reviewed and
Hi Grant,
On Thu, Jan 23 2014, Grant Grundler wrote:
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
CC ?= gcc
AM_CFLAGS = -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2
CFLAGS ?= -g -O2
-objects = mmc.o mmc_cmds.o
+objects = mmc.o mmc_cmds.o mmc_cmds-emmc5.o
CHECKFLAGS = -Wall -Werror
Hi,
On Thu, Jan 23 2014, Grant Grundler wrote:
+ cid[13] = 0;/* make sure string is NULL terminated */
Ah, and if you're respinning the patch anyway, would you object to
using '\0' here? Just a style preference, either way is okay.
Thanks,
- Chris.
--
Chris Ball ch...@printf.net
On Thu, Jan 23, 2014 at 10:42 AM, Chris Ball ch...@printf.net wrote:
Hi Grant,
On Thu, Jan 23 2014, Grant Grundler wrote:
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
CC ?= gcc
AM_CFLAGS = -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2
CFLAGS ?= -g -O2
-objects = mmc.o mmc_cmds.o
On Thu, Jan 23, 2014 at 10:45 AM, Chris Ball ch...@printf.net wrote:
Hi,
On Thu, Jan 23 2014, Grant Grundler wrote:
+ cid[13] = 0;/* make sure string is NULL terminated */
Ah, and if you're respinning the patch anyway, would you object to
using '\0' here? Just a style preference,
On Thu, Jan 23, 2014 at 11:28 AM, Chris Ball ch...@printf.net wrote:
Hi Grant,
On Thu, Jan 23 2014, Grant Grundler wrote:
You can directly pull into a local branch/review with:
git fetch
https://chromium.googlesource.com/chromiumos/third_party/mmc-utils
refs/changes/21/179621/2 git
Hi Grant,
On Thu, Jan 23 2014, Grant Grundler wrote:
You can directly pull into a local branch/review with:
git fetch
https://chromium.googlesource.com/chromiumos/third_party/mmc-utils
refs/changes/21/179621/2 git cherry-pick FETCH_HEAD
Thanks, that worked fine. Now I'm seeing:
cc
Field Firmware Update feature is new for 5.0 spec.
Code written per JESD84-B50.pdf spec available from:
http://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc
Change-Id: I0a22e9862876421630f53ac27fc0a161a9c70131
Signed-off-by: Grant Grundler
On Thu, Jan 23, 2014 at 11:30 AM, Grant Grundler grund...@chromium.org wrote:
Will respin ASAP. and resend. *sigh*
respin sent with v2 in subject line and includes the '\0' assignment change.
Apologies again.
cheers,
grant
--
To unsubscribe from this list: send the line unsubscribe linux-mmc
On Thu, Jan 23, 2014 at 11:30 AM, Grant Grundler grund...@chromium.org wrote:
...
Sorry - I fixed that yesterday but apparently didn't update the git
format-patch output I used to send the patch out today. /o\
I figure out what happened. Sharing to remind others of this silly brain fart.
I
23 matches
Mail list logo
