mmc-utils boot enable conflict with mmc_blk_part_switch

Hi, Boot enable setting is enable with writting PARTITION_CONFIG ext csd. But the kernel also write it in mmc_blk_part_switch. This lead to weird result : ~ # mmc_utils extcsd read /dev/mmcblk0 | grep PARTITION_CONFIG Boot configuration bytes [PARTITION_CONFIG: 0x00] ## no boot partition

[PATCH 1/2] sdhci : handle busy timeout irq

-by: Matthieu CASTET matthieu.cas...@parrot.com --- drivers/mmc/host/sdhci.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 47055f3..9df59a4 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2301,6 +2301,11

Re: [PATCH 1/2] sdhci : handle busy timeout irq

Any news on these patches ? Le Wed, 9 Jul 2014 17:01:51 +0200, Matthieu CASTET matthieu.cas...@parrot.com a écrit : When we wait for busy after sending a command, if there is a timeout, we got SDHCI_INT_DATA_TIMEOUT flags. Before this commit we got the message : Got data interrupt 0x0010

[RFC 1/2] sdhci : recompute timeout_clk when needed

when SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set, timeout_clk is sdclk. We need to update it when we change sdclk in sdhci_set_clock. This allow to have a more precisse timeout and max_busy_timeout. This can help for command that need a big busy wait (erase, ...). Signed-off-by: Matthieu CASTET

[RFC] mmc : don't disable discard support because max_busy_timeout is too small

mmc_calc_max_discard compute a worst case : max(erase, trim). Without this commit, if the erase time is big (2400ms for example) and max_busy_timeout is 1300ms (sdhci running with a clock at 100Mhz and SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK), discard support will be disabled. But trim could be used

Re: [RFC 1/2] sdhci : recompute timeout_clk when needed

Please ignore this mail, it is a mistake (it was already sent). Sorry for the noise. Le Thu, 10 Jul 2014 10:01:03 +0200, Matthieu CASTET matthieu.cas...@parrot.com a écrit : when SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set, timeout_clk is sdclk. We need to update it when we change sdclk

[PATCH 1/2] sdhci : handle busy timeout irq

-by: Matthieu CASTET matthieu.cas...@parrot.com --- drivers/mmc/host/sdhci.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 47055f3..9df59a4 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2301,6 +2301,11

[PATCH 2/2] sdhci : recompute timeout_clk when needed

when SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set, timeout_clk is sdclk. We need to update it when we change sdclk in sdhci_set_clock. This allow to have a more precisse timeout and max_busy_timeout. This can help for command that need a big busy wait (erase, ...). Signed-off-by: Matthieu CASTET

SDHCI DDR50 implies MMC DDR

Hi, shouldn't we add something like that do auto-detect MMC_CAP_1_8V_DDR on sdhci controller ? MatthieuFrom f821501dada7041521fe80a5fe92bdc8b15f055b Mon Sep 17 00:00:00 2001 From: Matthieu CASTET matthieu.cas...@parrot.com Date: Fri, 18 Apr 2014 15:49:05 +0200 Subject: [PATCH] sdhci : UHS DDR50

password protected mmc/sd handling

Hi, some sdcard support password protection. It can be useful on some embedded system (smartphone for example) where you don't want other people reading your data if you loose it (and you can't use encryption because of extra cpu usage). But that doesn't seem supported on linux. Is there any

Re: sdhci max_blk_size

Aaron Lu a écrit : On Wed, Jan 04, 2012 at 04:01:07PM +0100, Matthieu CASTET wrote: Hi, our controller set Max Block Length to 3 (4096 byte), but the linux driver ignore this value [1]. Is there any reason to do that . The reason is, sd host controller spec defines 3 as reserved

OMAP HS-MMC: convert to dev_pm_ops broke hibernation

Hi, commit a791daa15305e7e549a418ef0ae6bc4b4580066e converted PM operations to use dev_pm_ops. But this broke hibernation/suspend to disk : - now there no state argument - but there is one call back per state : -- suspend/resume for s2ram -- freeze/thaw poweroff/restore for s2disk look like most

Re: sdhci : reduce irq off latency

Hi Chris, Chris Ball a écrit : Hi Matthieu, This patch didn't make it upstream. Kyungmin offered a suggestion for fixing it -- would you like to resend an updated patch? It seems http://marc.info/?l=linux-kernelm=127911287108683w=2 (http://marc.info/?a=127137055700010r=1w=2) is a better

Re: sdhci : reduce irq off latency

. This patch make a hang at probe time. it's tested against commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02 Author: Linus Torvalds torva...@linux-foundation.org Date: Fri Jun 11 19:14:04 2010 -0700 Linux 2.6.35-rc3 Thank you, Kyungmin Park On Thu, Jun 17, 2010 at 6:07 PM, Matthieu CASTET

sdhci : reduce irq off latency

[1] does busy pooling (with a granularity of 1 ms) on a register up to a timeout of 100 ms. With the current code, we got irq off during 2*1ms. With the attached patch we reduce irq off to 30 us. Note that worst case 100 ms irq off still exist. Signed-off-by: Matthieu CASTET matthieu.cas