Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

On Wed, Oct 21, 2015 at 2:00 AM, Ulf Hansson wrote: To put a few more numbers on the "chunk size vs perf": 1EG (512KB) -> 44K commands -> ~20 minutes 32EG (16MB) -> 1375 commands -> ~1 minute 128EG (64MB) -> 344 commands -> ~30 seconds 8191EG

Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

On Tue, Oct 20, 2015 at 11:57 AM, Jeff Moyer <jmo...@redhat.com> wrote: > Hi Grant, > > Grant Grundler <grund...@chromium.org> writes: > >> Ping? Does no one care how long BLK_SECDISCARD takes? >> >> ChromeOS has landed this change as a compromise between

Re: [PATCH] mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD

Awesome! Thanks Ulf! :) cheers grant On Mon, Oct 5, 2015 at 3:55 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > On 24 September 2015 at 03:30, Grant Grundler <grund...@chromium.org> wrote: >> MMC_IOC_CMD and MMC_IOC_MULTI_CMD ioctl() code currently bails on >&g

Fwd: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

[resending...I forgot to switch gmail back to text-only mode. grrrh..] -- Forwarded message -- From: Grant Grundler <grund...@chromium.org> Date: Mon, Sep 28, 2015 at 2:42 PM Subject: Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE To: Grant Grundler <grund...@chr

Re: RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

ing about references to bio_iter.bi_size. cheers, grant On Tue, Sep 22, 2015 at 6:54 PM, Grant Grundler <grund...@chromium.org> wrote: > Jens, Ulf, > > I've run into a basic issue: BLK_SECDISCARD takes 15-35 minutes > perform a secure erase of ~23GB (mostly empty) partition o

Re: [PATCH V4] mmc: block: Add new ioctl to send multi commands

On Wed, Sep 23, 2015 at 2:42 PM, Ulf Hansson wrote: > On 22 September 2015 at 11:27, Jon Hunter wrote: >> Certain eMMC devices allow vendor specific device information to be read >> via a sequence of vendor commands. These vendor commands must be

RFC: 32-bit __data_len and REQ_DISCARD+REQ_SECURE

Jens, Ulf, I've run into a basic issue: BLK_SECDISCARD takes 15-35 minutes perform a secure erase of ~23GB (mostly empty) partition on a 32GB eMMC part (happens with two vendors). One of the vendors says it should take less than 60 seconds. I've confirmed erasing 2GB takes only ~6 seconds - so

Re: [PATCH V3] mmc: block: Add new ioctl to send multi commands

Jon, Ulf, Can we first get the current implementation upstream and _then_ add more patches to it? On Mon, Sep 21, 2015 at 4:19 AM, Jon Hunter wrote: ... + for (i = 0; i < num_of_cmds; i++) { + err = __mmc_blk_ioctl_cmd(card, md, idata[i]);

Re: [PATCH V3] mmc: block: Add new ioctl to send multi commands

h defaults to 255 and should be more than > sufficient). > > Signed-off-by: Seshagiri Holi <sh...@nvidia.com> > Cc: Arnd Bergmann <a...@arndb.de> > Cc: Grant Grundler <grund...@google.com> > Cc: Olof Johansson <ol...@chromium.org> > [ jonath...@nvidia.com:

Re: [PATCH V2] mmc: block: Add new ioctl to send multi commands

m_of_cmds member (which should be more than sufficient). > > Signed-off-by: Seshagiri Holi <sh...@nvidia.com> > Cc: Arnd Bergmann <a...@arndb.de> > Cc: Grant Grundler <grund...@google.com> Reviewed-by: Grant Grundler <grund...@chromium.org> One comment below. two

Re: [PATCH] mmc: block: Add new ioctl to send multi commands

On Thu, Sep 10, 2015 at 1:24 AM, Jon Hunter wrote: ... >> - you have some implicit padding after the structure and should replace that >> with explictit pad bytes to extend the structure to a multiple of its >> alignment (8 bytes). > > Would padding with __u32 at the end

Re: [PATCH] mmc: block: Add new ioctl to send multi commands

On Thu, Sep 10, 2015 at 11:20 AM, Jon Hunter <jonath...@nvidia.com> wrote: > > On 10/09/15 18:10, Grant Grundler wrote: ... >>>>>> struct mmc_ioc_multi_cmd { >>>>>> __u64 num_of_cmds; >>>>>> struct mmc_ioc_cmd cmds[0];

Re: [RFC PATCH] mmc: block: Add new ioctl to send combo commands

ap them in the updated version as this seems to make > sense. However, I left num_of_cmds as an 8-bit value unless someone has > a need for more than 256 commands ;-) Awesome - thanks! I saw that in the new version you posted. LGTM. You or Ulf can add "Reviewed by: Grant Grundler <grund..

Re: [RFC PATCH] mmc: block: Add new ioctl to send combo commands

[resending text-only] On Wed, Sep 2, 2015 at 3:07 PM, Grant Grundler <grund...@google.com> wrote: > > > On Wed, Sep 2, 2015 at 11:28 AM, Olof Johansson <o...@lixom.net> wrote: > ... >> > +/** >> > + * struct mmc_ioc_combo_cmd - combo command information

Re: [RFC PATCH 1/1 v7]mmc: Support-FFU-for-eMMC-v5.0

, grant On Tue, Jul 1, 2014 at 10:07 AM, Ulf Hansson ulf.hans...@linaro.org wrote: On 1 July 2014 17:47, Grant Grundler grund...@chromium.org wrote: On Mon, Jun 30, 2014 at 5:34 PM, Chris Ball ch...@printf.net wrote: Hi Grant, sorry about the delay. On Tue, Jul 01 2014, Grant Grundler wrote: ping

Re: [RFC PATCH 1/1 v7]mmc: Support-FFU-for-eMMC-v5.0

On Mon, Jun 30, 2014 at 5:34 PM, Chris Ball ch...@printf.net wrote: Hi Grant, sorry about the delay. On Tue, Jul 01 2014, Grant Grundler wrote: ping? Another week is past. I know you guys are busy with other stuff. But please at least publish what you think the next steps for this patch

Re: [RFC PATCH 1/1 v7]mmc: Support-FFU-for-eMMC-v5.0

and the lack of response in this case is making this unnecessarily difficult. thanks, grant On Mon, Jun 23, 2014 at 10:14 AM, Grant Grundler grund...@chromium.org wrote: Chris, Ulf, Any reason the eMMC 5.0 FFU patch can't be integrated into linux-mmc tree? While I can't directly test this patch

Re: [RFC PATCH 1/1 v7]mmc: Support-FFU-for-eMMC-v5.0

is the FFU upload is atomic (no other commands will get interleaved) and the FFU enable step is also atomic. If I misunderstood, SanDisk should be able to answer this question. cheers grant thanks, hsinhsiang 2014-06-24 1:14 GMT+08:00 Grant Grundler grund...@chromium.org: Chris, Ulf, Any

Re: [RFC PATCH 1/1 v7]mmc: Support-FFU-for-eMMC-v5.0

Chris, Ulf, Any reason the eMMC 5.0 FFU patch can't be integrated into linux-mmc tree? While I can't directly test this patch due to limitations of which HW ChromeOS supports, I believe it's a big step in the right direction. It would also make life easier for other vendors to add FFU support

Re: [PATCH] mmc-utils:add KSI eMMC 5.0 FFU support

Hi Darren! Did you understand what Puthikorn was asking for? linux-mmc maintainers don't care about Chrome-OS branches (stabilize-5784.0.B). Puthikorn was just pointing out the patch needs to be against something that linux-mmc can build. This Kingston support patch is a good example of why

Re: [PATCH] mmc: sdhci: remove mdelay in eMMC tuning

behavior for compatibility. This has been verified to fix observed glitching on local audio playback and recording on apps with inbuilt assumptions on storage latency. Signed-off-by: Nick Sanders nsand...@chromium.org Reviewed-by: Grant Grundler grund...@chromium.org Reviewed-by: Doug

Re: [RFC PATCH 1/1 v6 ]mmc: Support-FFU-for-eMMC-v5.0

alex.lemb...@sandisk.com Reviewed-by: Grant Grundler grund...@chromium.org I'm working on testing this which is why pwclient found the next nit on line 678 (see below). And add the patch version comments here: V5: - provides udev (request_firmware) implementation as advised in patch v2 comments

Re: [RFC PATCH 1/1 v6 ]mmc: Support-FFU-for-eMMC-v5.0

follow up on malformed patch problem: On Fri, May 9, 2014 at 9:44 AM, Grant Grundler grund...@chromium.org wrote: ... diff --git a/include/linux/mmc/ffu.h b/include/linux/mmc/ffu.h new file mode 100644 index 000..be70880 This diff line looks correct to me. But pwclient reported

Re: [RFC PATCH 1/1 v6 ]mmc: Support-FFU-for-eMMC-v5.0

On Fri, May 9, 2014 at 11:06 AM, Grant Grundler grund...@chromium.org wrote: follow up on malformed patch problem: Sorry...I'm now confident this patch is white space mangled before it was generated: +#define CARD_BLOCK_SIZE 512 + +/* + * eMMC5.0 Field Firmware Update (FFU) opcodes */ #define

Re: [PATCH] mmc: Support FFU for Samsung eMMC v4.5

On Fri, Apr 4, 2014 at 5:07 AM, Seunguk Shin seunguk.s...@samsung.com wrote: This change adds support to field firmware update (ffu) for Samsung emmc v4.5. Wow. I'm amazed and very happy that this has been posted. :) Samsung eMMC 4.5 FFU protocol is similar with eMMC 5.0 FFU without

Re: [PATCH] mmc-utils: Support sending Samsung eMMC 4.5 FFU

permanently recorded as the original author. I'm particularly interested in making sure @samsung.com is listed as the original author. :) I understand this code depends on a patch that hasn't been accepted yet. :) So effectively this might not matter: Reviewed-by: Grant Grundler grund...@chromium.org

Re: [RFC PATCH 1/1 ]mmc: Support-FFU-for-eMMC-v5.0

argh...reposting my response as text only since linux-mmc doesn't like html mail. :( On Tue, Apr 1, 2014 at 1:26 PM, Grant Grundler grund...@chromium.org wrote: On Mon, Mar 31, 2014 at 9:17 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Seunguk. On 03/31/2014 07:51 PM, Seunguk Shin

RFC: raw extcsd dump

Chris, Are you interested in raw dump of extcsd data? We need it to dump vendor specific data that happens to be in a reserved field. Chromium.org code review is here: https://chromium-review.googlesource.com/#/c/189002/ git magic to pull that patch is here: git pull

Re: [RFC PATCH 1/1] mmc-utils: Support-sending-eMMC-5.0-FFU

Avi, Thanks for posting these - I look forward to seeing this functionality available in mmc-utils (and kernel as needed). Comments as usual inline. I've added Gwendal/Kees to CC to comment on security issues of this proposal. See notes below. On Sun, Feb 9, 2014 at 1:08 AM, Avi Shchislowski

Re: [RFC PATCH 1/1 ]mmc: Support-FFU-for-eMMC-v5.0

Avi, thanks for posting this and apologies for not seeing/reviewing this earlier. Comments inline below. On Sun, Feb 9, 2014 at 1:07 AM, Avi Shchislowski avi.shchislow...@sandisk.com wrote: Add Support to Field Firmware Update (FFU) for eMMC v5.0 and up devices. The code implemented

Re: [RFC PATCH 1/1 ]mmc: Support-FFU-for-eMMC-v5.0

Sorry. Gmail isn't vi and accidentally sent this prematurely. /o\ Continuing the review comments... On Thu, Feb 27, 2014 at 6:12 PM, Grant Grundler grund...@chromium.org wrote: ... + +/* + * Map memory into a scatterlist. + */ +static int mmc_ffu_map_sg(struct mmc_ffu_mem *mem, unsigned long

Re: [PATCH] Decode EXT_CSD of eMMC 5.0 device

for 200MHz, DDR at VCC= 3.6V [PWR_CL_DDR_200_360: 0x00] Generic CMD6 Timer [GENERIC_CMD6_TIME: 0x0a] Power off notification [POWER_OFF_LONG_TIME: 0x3c] Cache Size [CACHE_SIZE] is 65536 KiB ... Signed-off-by: Gwendal Grignou gwen...@chromium.org Reviewed-by: Grant Grundler grund...@chromium.org

Re: [PATCH v2] mmc-utils: add eMMC 5.0 FFU support

Chris, I haven't seen anything else get proposed. If not, can you include this patch in mmc-utils ToT and use it as a basis to drive the FFU support conversation forward? On Sun, Feb 9, 2014 at 1:06 AM, Alex Lemberg alex.lemb...@sandisk.com wrote: Hi Grant, We will contribute shortly our FFU

[PATCH V3] mmc-utils: add eMMC 5.0 FFU support

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 grund

Re: [PATCH v2] mmc-utils: add eMMC 5.0 FFU support

...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Grant Grundler Sent: Thursday, January 23, 2014 9:44 PM To: Chris Ball Cc: linux-mmc; Puthikorn Voravootivat; Gwendal Grignou; Grant Grundler Subject: [PATCH v2] mmc-utils: add eMMC 5.0 FFU support Field Firmware Update

Re: [PATCH v2] mmc-utils: add eMMC 5.0 FFU support

On Sun, Feb 2, 2014 at 9:52 AM, Chris Ball ch...@printf.net wrote: Hi Grant, Still waiting on the remaining warning/error, Sorry - was out thurs/fri. I'm wondering why I didn't see that warning before. and also noticed a trivial typo: Typo fixed (locally). I got good feedback from one of

Re: [PATCH] mmc-utils: add eMMC 5.0 FFU support

On Sat, Jan 25, 2014 at 5:47 PM, Chris Ball ch...@printf.net wrote: Hi Grant, On Thu, Jan 23 2014, Grant Grundler wrote: respin sent with v2 in subject line and includes the '\0' assignment change. Apologies again. Thanks, no worries. Would you like me to take this now, or wait

[PATCH] mmc-utils: add eMMC 5.0 FFU support

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

Re: [PATCH] mmc-utils: add eMMC 5.0 FFU support

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

Re: [PATCH] mmc-utils: add eMMC 5.0 FFU support

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

Re: [PATCH] mmc-utils: add eMMC 5.0 FFU support

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

[PATCH v2] mmc-utils: add eMMC 5.0 FFU support

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 grund

Re: [PATCH] mmc-utils: add eMMC 5.0 FFU support

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

Re: [PATCH] mmc-utils: add eMMC 5.0 FFU support

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

[PATCH] mmc: disable UHS on broadcom sdhci

the chip itself with the required quirks in general (lightly tested). o parrot (Acer C7 Chromebook) which uses the SDHCI_QUIRK2_BROKEN_UHS quirk: disables ADMA mode, and adds a delay after power. Signed-off-by: Stephen Hurd sh...@broadcom.com Signed-off-by: Grant Grundler grund...@chromium.org

dw_mmc: priv-sdr_timing set wrong

Chris, Yuvaraj, Alim, Jaehoon, This patch is wrong: https://git.kernel.org/cgit/linux/kernel/git/cjb/mmc.git/commit/?h=mmc-nextid=e6c784eded7b39caeaf2e9206336fa1daeccfd09 sdr_timing needs to come from the of_property samsung,dw-mshc-sdr-timing. Assignment of priv-sdr_timing needs to move back

Re: [PATCH 6/7] mmc: core: protect references to host-areq with host-lock

this semaphore. apologies, grant On Thu, Sep 26, 2013 at 12:22 PM, Grant Grundler grund...@chromium.org wrote: Races between host-areq being NULL or not are resulting in mmcqd hung_task panics. Like this one: 3[ 240.501202] INFO: task mmcqd/1:85 blocked for more than 120 seconds. 3[ 240.501213

Re: [PATCH 0/7] mmc: core: cleanup and locking patches description

Ping? Has anyone had a chance to review/test this series and/or be willing to do so this week? grundler@firesword:~$ pwclient list -w 'grund...@chromium.org' -p LKML Patches submitted by Grant Grundler grund...@chromium.org: ID StateName -- - ... 2950961 New

Re: [PATCH 0/7] mmc: core: cleanup and locking patches description

On Thu, Oct 3, 2013 at 2:35 PM, Ulf Hansson ulf.hans...@linaro.org wrote: Den 3 okt 2013 22:35 skrev Grant Grundler grund...@chromium.org: Ping? Has anyone had a chance to review/test this series and/or be willing to do so this week? Hi Grant, It is on my todo list. My plan

[PATCH 0/7] mmc: core: cleanup and locking patches description

Following 7 patches are mostly cleanup with one key patch around host-areq locking. The host-areq locking problem description is here: http://www.spinics.net/lists/linux-mmc/msg21644.html I do believe this preposed host-areq locking patch is a complete fix. But it appears to fix the

[PATCH 4/7] mmc: core: use common code path to return error

Don't replicate how the *error is returned by mmc_start_req(). Signed-off-by: Grant Grundler grund...@chromium.org --- drivers/mmc/core/core.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 4d5de98..deb0ee5

[PATCH 6/7] mmc: core: protect references to host-areq with host-lock

. Just my clue that the timing is different (and the fio performance numbers are different too). Signed-off-by: Grant Grundler grund...@chromium.org --- drivers/mmc/core/core.c | 34 +++--- 1 file changed, 23 insertions(+), 11 deletions(-) diff --git a/drivers/mmc/core

[PATCH 5/7] mmc: core: handling polling more gracefully

In case threads race to harvest async req completions, just return. Signed-off-by: Grant Grundler grund...@chromium.org --- drivers/mmc/core/core.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index deb0ee5..36cfe91 100644

[PATCH 2/7] mmc: core: rename local var err to saved_err

Just making it more obvious 'err' refers to the status of the in flight request (aka saved_areq) and not the new async request we might start. Signed-off-by: Grant Grundler grund...@chromium.org --- drivers/mmc/core/core.c | 16 1 file changed, 8 insertions(+), 8 deletions

[PATCH 1/7] mmc: core: rename data to saved_areq

Replace data with a more descriptive name. Using a local variable (ie a register) makes explicit what the compiler is doing under the covers anyway: the function is dereferencing one pointer value the whole time. Signed-off-by: Grant Grundler grund...@chromium.org --- drivers/mmc/core/core.c

[PATCH 3/7] mmc: core: restructure error handling for start req

This is an intermediate step to fixing the locking around the access to host-areq. Reduce the number of if (saved_areq) vs if (areq) tests in the main code path since I'm going to add references to host-lock in the next patch. Signed-off-by: Grant Grundler grund...@chromium.org --- drivers/mmc

Re: [PATCH 0/7] mmc: core: cleanup and locking patches description

Argh...too much wordsmithing... On Thu, Sep 26, 2013 at 12:22 PM, Grant Grundler grund...@chromium.org wrote: Following 7 patches are mostly cleanup with one key patch around host-areq locking. The host-areq locking problem description is here: http://www.spinics.net/lists/linux-mmc

Re: [PATCH] mmc: core: remove issue_fn indirect function call

On Wed, Sep 25, 2013 at 7:37 PM, Chris Ball c...@laptop.org wrote: Hi, On Wed, Sep 25 2013, Chris Ball wrote: Hi, On Fri, Sep 20 2013, Ulf Hansson wrote: On 19 September 2013 19:20, Grant Grundler grund...@chromium.org wrote: struct mmc_queue defines issue_fn as an indirect function call

Re: [PATCH] mmc: core: remove issue_fn indirect function call

On Thu, Sep 26, 2013 at 2:56 PM, Grant Grundler grund...@chromium.org wrote: On Wed, Sep 25, 2013 at 7:37 PM, Chris Ball c...@laptop.org wrote: Hi, On Wed, Sep 25 2013, Chris Ball wrote: Hi, On Fri, Sep 20 2013, Ulf Hansson wrote: On 19 September 2013 19:20, Grant Grundler grund

[PATCH] mmc: core: remove issue_fn indirect function call

struct mmc_queue defines issue_fn as an indirect function call. issue_fn field only gets set to mmc_blk_issue_rq and only gets invoked immediately after calling blk_fetch_request(). Don't bother with indirect function call - it's pointless and just obfuscates the code. Signed-off-by: Grant

Re: MMC locking: mmc_request accesses from dw_mmc driver ok?

end up waiting for a areq that might already be done. thanks, grant Best Regards, Jaehoon Chung On 08/22/2013 05:18 AM, Grant Grundler wrote: On Mon, Aug 12, 2013 at 4:45 PM, Grant Grundler grund...@chromium.org wrote: I've been working on an task mmcqd/0:84 blocked for more than 120

Re: [PATCH 02/14] mmc: dw_mmc: exynos: add variable delay tuning sequence

On Wed, Aug 21, 2013 at 6:49 AM, Seungwon Jeon tgih@samsung.com wrote: Implements variable delay tuning. In this change, exynos host can determine the correct sampling point for the HS200 and SDR104 speed mode. Signed-off-by: Seungwon Jeon tgih@samsung.com ---

Re: [PATCH 03/14] mmc: dw_mmc: exynos: adjust the clock rate with speed mode

On Wed, Aug 21, 2013 at 6:49 AM, Seungwon Jeon tgih@samsung.com wrote: Exynos's host has divider logic before 'cclk_in' to controller core. It means that actual clock rate of ciu clock comes from this divider value. So, source clock should be adjusted along with 'ciu_div' which indicates

Re: MMC locking: mmc_request accesses from dw_mmc driver ok?

On Mon, Aug 12, 2013 at 4:45 PM, Grant Grundler grund...@chromium.org wrote: I've been working on an task mmcqd/0:84 blocked for more than 120 seconds panic for the past month or so in the chromeos-3.4 kernel tree. Stack trace below. Feel free to tell me fixed in v3.x. :) I've added

MMC locking: mmc_request accesses from dw_mmc driver ok?

I've been working on an task mmcqd/0:84 blocked for more than 120 seconds panic for the past month or so in the chromeos-3.4 kernel tree. Stack trace below. Feel free to tell me fixed in v3.x. :) After staring at the 14 MMC and DW driver data structures, I now think dw_mmc driver is accessing

RFC: clearing clk_old?

I'm trying to see where host-clk_old is cleared in MMC core. Since I didn't find it, any reason to NOT do one or both of the below patches? thanks, grant ps. This is cut/pasted and white space mangled...hopefully readable though. diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c

Bug in mmc_start_req() ?

I don't understand all the implications...but my gut feeling is this change is necessary. Can someone please explain why I'm wrong? (key here is to use err || start_err - same logic as a few lines above to call mmc_post_req(...-EINVAL)) - if (err) - host-areq = NULL; -

Re: [PATCH 3/5] mmc: dw_mmc: Add exynos resume callback to clear WAKEUP_INT

problems. I agree. Can add: Reviewed-by: Grant Grundler grund...@chromium.org thanks, grant -Doug -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: mmc_rescan/sdio_reset timeout missing?

-retries || mmc_card_removed(host-card)) break; Thanks! grant On 06/19/2013 10:44 PM, Grant Grundler wrote: I've looking through the code to understand this bug that caused this stack trace (and ended up panicing below): 3[ 1680.501338] INFO: task

mmc_rescan/sdio_reset timeout missing?

I've looking through the code to understand this bug that caused this stack trace (and ended up panicing below): 3[ 1680.501338] INFO: task kworker/u:22:9101 blocked for more than 120 seconds. 3[ 1680.501348] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. 6[ 1680.501357]

Re: [PATCH] mmc: dw_mmc: rewrite CLKDIV computation

Sorry - please ignore the previous version. Did not include a copyright (implied to be mine...but it's not) nor license. Same thing but with proper attribution. cheers, grant On Tue, Mar 26, 2013 at 3:53 PM, Grant Grundler grund...@chromium.org wrote: I've attached the test program I wrote

Re: [PATCH] mmc: dw_mmc: rewrite CLKDIV computation

On Wed, Mar 27, 2013 at 8:07 AM, Doug Anderson diand...@chromium.org wrote: Grant, Thanks for posting! See below... thanks for reviewing/feedback! :) On Tue, Mar 26, 2013 at 3:50 PM, Grant Grundler grund...@chromium.org wrote: Last year Seungwon Jeon (Samsung) fixed a bug in CLKDIV

Re: [PATCH] mmc: dw_mmc: rewrite CLKDIV computation

Hi Chris, On Wed, Mar 27, 2013 at 10:58 AM, Chris Ball c...@laptop.org wrote: Hi Grant, ... Please use the following (standard) syntax in the commit message: Commit e419990b5e8 (mmc: dw_mmc: correct the calculation for CLKDIV) fixed a bug in CLKDIV computation. [..] Ok - I didn't know that

[PATCH V2] mmc: dw_mmc: rewrite CLKDIV computation

When backporting Commit e419990b5e8 (mmc: dw_mmc: correct the calculation for CLKDIV) to 3.4 kernel and debugging a FW issue, I found the code unreadable. This rewrite simplifies the computation and explains each step. Signed-off-by: Grant Grundler grund...@chromium.org --- V2: rewrote commit

[PATCH] mmc: dw_mmc: rewrite CLKDIV computation

Last year Seungwon Jeon (Samsung) fixed a bug in CLKDIV computation. But when debugging a related issue (http://crbug.com/221828) I found the code unreadable. This rewrite simplifies the computation and explains each step. Signed-off-by: Grant Grundler grund...@chromium.org --- Tested on Samsung

Re: [PATCH] mmc: dw_mmc: rewrite CLKDIV computation

I've attached the test program I wrote to compare the different flavors of CLKDIV computation: old (3.4 kernel), current upstream, and my rewrite. thanks grant On Tue, Mar 26, 2013 at 3:50 PM, Grant Grundler grund...@chromium.org wrote: Last year Seungwon Jeon (Samsung) fixed a bug in CLKDIV

Re: Resume issue with brcmfmac *not* loaded

+olofj (chromium.org), sukeshs (Broadcom) On Mon, Jun 13, 2011 at 2:18 PM, Stephen Warren swar...@nvidia.com wrote: I'm having resume problems on a system (NVIDIA Tegra Seaboard) that would use the brcmfmac staging driver. Stephen, Are you using the chromium.org tree...and using 2.6.38 based

Re: [PATCH] SDHCI: Suspend/Resume needs to save/restore INT_ENABLE on ARM/Tegra2

Chris, Ping? The discussion on save/restoring SDHCI_INT_ENABLE reached consensus that this patch is needed. Can you still apply? On Tue, Mar 8, 2011 at 1:39 PM, Grant Grundler grund...@google.com wrote: Save and restore SDHCI interrupt mask during suspend/resume. Enables ARM Tegra2 board

Re: [PATCH] SDHCI: Suspend/Resume needs to save/restore INT_ENABLE on ARM/Tegra2

On Mon, Mar 28, 2011 at 7:21 PM, Chris Ball c...@laptop.org wrote: Hi Grant, On Tue, Mar 08 2011, Grant Grundler wrote: Save and restore SDHCI interrupt mask during suspend/resume. Enables ARM Tegra2 board to suspend/resume. Signed-off-by: Venkat Rao v...@broadcom.com Reviewed-by: Olof

[PATCH] tegra/mmc: add pm_flags

Tested-by: Grant Grundler grund...@chromium.org Reviewed-by: Olof Johansson ol...@chromium.org I'm not certain if this should go through tegra or mmc tree. Can you advise please? This is part of http://codereview.chromium.org/6474032 . The other three change sets required for Seaboard (Tegra2

Re: [PATCH] tegra/mmc: add pm_flags

On Fri, Mar 25, 2011 at 5:43 PM, Chris Ball c...@laptop.org wrote: Hi Grant, On Fri, Mar 25 2011, Grant Grundler wrote: Enable fast bcm4329 WIFI suspend/resume on Tegra2 board. This part allows the mach-tegra support tell the tegra MMC host controller to NOT turn off power for the MMC

Re: [PATCH] SDHCI: Suspend/Resume needs to save/restore INT_ENABLE on ARM/Tegra2

On Wed, Mar 9, 2011 at 12:24 PM, Andrei Warkentin andr...@motorola.com wrote: On Tue, Mar 8, 2011 at 3:39 PM, Grant Grundler grund...@google.com wrote: Save and restore SDHCI interrupt mask during suspend/resume. Enables ARM Tegra2 board to suspend/resume. Signed-off-by: Venkat Rao v

Re: [PATCH] SDHCI: Suspend/Resume needs to save/restore INT_ENABLE on ARM/Tegra2

On Wed, Mar 9, 2011 at 1:10 PM, Andrei Warkentin andr...@motorola.com wrote: On Wed, Mar 9, 2011 at 3:01 PM, Grant Grundler grund...@google.com wrote: On Wed, Mar 9, 2011 at 12:24 PM, Andrei Warkentin andr...@motorola.com wrote: On Tue, Mar 8, 2011 at 3:39 PM, Grant Grundler grund

Re: [PATCH] SDHCI: Suspend/Resume needs to save/restore INT_ENABLE on ARM/Tegra2

...@broadcom.com Reviewed-by: Olof Johansson ol...@chromium.org Reviewed-by: Grant Grundler grund...@chromium.org cheers, grant -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo

[PATCH] SDHCI: Suspend/Resume needs to save/restore INT_ENABLE on ARM/Tegra2

Save and restore SDHCI interrupt mask during suspend/resume. Enables ARM Tegra2 board to suspend/resume. Signed-off-by: Venkat Rao v...@broadcom.com Reviewed-by: Olof Johansson ol...@chromium.org Reviewed-by: Grant Grundler grund...@chromium.org --- drivers/mmc/host/sdhci.c |5