Re: Possible regression with commit 52221610d

On Sun, Dec 21, 2014 at 7:01 PM, Tim Kryger wrote: > On Wed, Dec 17, 2014 at 11:57 AM, Bjorn Andersson wrote: > >> I'm somewhat puzzled to what benefit 52221610d brings after bringing >> back the write of BIT(0). Is it just that we don't hit the BUG() on >> non-standard voltages? > > It is to all

[PATCH 0/2] mmc: rtsx: add check before sending request

From: Micky Ching Add check before sending request can make request return faster. - finish request if no card exist This can make request finish faster, especial for some sdio card, when card removed, there still a lot of command pending, if we check card exist and stop request, the card w

[PATCH 1/2] mmc: rtsx: finish request if no card exist

From: Micky Ching Return error-code directly if no card exist, this can make card remove faster. Signed-off-by: Micky Ching --- drivers/mmc/host/rtsx_pci_sdmmc.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/r

[PATCH 2/2] mmc: rtsx: check sg_count before long data xfer

From: Micky Ching Check sg_count before sending long data xfer. Because dma_map_sg() return int, and sg_count may be negative, so using int instead of unsigned. Signed-off-by: Micky Ching --- drivers/mmc/host/rtsx_pci_sdmmc.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) d

[PATCH] mmc: dw_mmc: Power on vqmmc in MMC_POWER_ON, not MMC_POWER_UP

If we power up vqmmc in MMC_POWER_ON then we end up turning it on before mmc_power_up() sets the signal voltage. That's not so great since we might be powering it up at the wrong voltage. Note that this is how Yuvaraj originally coded things up in but

[PATCH] mmc: dw_mmc: rockchip: Add DW_MCI_QUIRK_RETRY_DELAY

We've seen at least one card that can get confused during all the errors generated during tuning on rk3288. These errors seem to go away with DW_MCI_QUIRK_RETRY_DELAY. That quirk is documented to be for 2.11a and on rk3288 I believe we have 2.70a, but it seems to be the same type of problem. Spe

Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning

On 01/13/15 16:41, Ulf Hansson wrote: On 13 January 2015 at 16:11, Arend van Spriel wrote: On 01/13/15 15:56, Ulf Hansson wrote: [...] Thank you for looking at the patches. I am not sure I know what you mean. sdhci already has a re-tuning timer, so this is just moving it into core, where i

Re: Possible regression with commit 52221610d

On Mon, Jan 5, 2015 at 11:52 AM, Bjorn Andersson wrote: > On Sun, Dec 21, 2014 at 7:01 PM, Tim Kryger wrote: >> On Wed, Dec 17, 2014 at 11:57 AM, Bjorn Andersson wrote: > [..] >>> Non-the-less, feel free to propose a patch and I will give it a test. >> >> Lets start with the simplest change firs

Re: Possible regression with commit 52221610d

On Mon, Jan 12, 2015 at 2:31 AM, Ulf Hansson wrote: > On 5 January 2015 at 20:52, Bjorn Andersson wrote: >> On Sun, Dec 21, 2014 at 7:01 PM, Tim Kryger wrote: >>> On Wed, Dec 17, 2014 at 11:57 AM, Bjorn Andersson wrote: >> [..] Non-the-less, feel free to propose a patch and I will give it

Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning

On 13 January 2015 at 16:11, Arend van Spriel wrote: > On 01/13/15 15:56, Ulf Hansson wrote: >> >> [...] >> > Thank you for looking at the patches. > > I am not sure I know what you mean. sdhci already has a re-tuning > timer, so > this is just moving it into core, where it won

[PATCH] mmc: host: sdhci: Added a space before (

This patch solves the coding style issue by adding a space before ( Signed-off-by: Mohammad Jamal --- drivers/mmc/host/sdhci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 1453cd1..910ee7b 100644 --- a/drivers/mm

Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning

On 01/13/15 15:56, Ulf Hansson wrote: [...] Thank you for looking at the patches. I am not sure I know what you mean. sdhci already has a re-tuning timer, so this is just moving it into core, where it won't be used by other drivers unless they enable it. I am kind of questioning the re-tunin

Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning

On 01/13/15 15:22, Ulf Hansson wrote: On 13 January 2015 at 14:23, Adrian Hunter wrote: On 13/01/15 13:25, Ulf Hansson wrote: Hi Adrian, Thanks for working on this and apologize for my late reply! On 5 December 2014 at 18:41, Adrian Hunter wrote: Currently, there is core support for tuning

Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning

[...] >>> Thank you for looking at the patches. >>> >>> I am not sure I know what you mean. sdhci already has a re-tuning timer, so >>> this is just moving it into core, where it won't be used by other drivers >>> unless they enable it. >> >> I am kind of questioning the re-tuning timer in sdhci.

Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning

On 13/01/15 16:22, Ulf Hansson wrote: > On 13 January 2015 at 14:23, Adrian Hunter wrote: >> On 13/01/15 13:25, Ulf Hansson wrote: >>> Hi Adrian, >>> >>> Thanks for working on this and apologize for my late reply! >>> >>> On 5 December 2014 at 18:41, Adrian Hunter wrote: Currently, there is

Re: [PATCH 0/4] mmc: core: Add support for MMC power sequences

[...] >> >> Thanks a lot for elaborating! I understand your concern now. >> >> In this context, I believe it's important to state that I think these >> host driver behaves badly! _All_ host drivers shall handle their >> "power_up" things while they get MMC_POWER_UP through the ->set_ios() >> callb

Re: [PATCH 0/4] mmc: core: Add support for MMC power sequences

On Tue, Jan 13, 2015 at 03:08:51PM +0100, Ulf Hansson wrote: > On 12 January 2015 at 17:18, Russell King - ARM Linux > wrote: > > On Mon, Jan 12, 2015 at 03:29:54PM +0100, Ulf Hansson wrote: > >> Regarding you concern, about me propagating the same design mistake as > >> for the ->set_ios() callba

Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning

On 13 January 2015 at 14:23, Adrian Hunter wrote: > On 13/01/15 13:25, Ulf Hansson wrote: >> Hi Adrian, >> >> Thanks for working on this and apologize for my late reply! >> >> On 5 December 2014 at 18:41, Adrian Hunter wrote: >>> Currently, there is core support for tuning during >>> initializati

Re: [PATCH 0/4] mmc: core: Add support for MMC power sequences

On 12 January 2015 at 17:18, Russell King - ARM Linux wrote: > On Mon, Jan 12, 2015 at 03:29:54PM +0100, Ulf Hansson wrote: >> Regarding you concern, about me propagating the same design mistake as >> for the ->set_ios() callback, I am not sure I fully understand why you >> think that's the case?

Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning

On 13/01/15 13:25, Ulf Hansson wrote: > Hi Adrian, > > Thanks for working on this and apologize for my late reply! > > On 5 December 2014 at 18:41, Adrian Hunter wrote: >> Currently, there is core support for tuning during >> initialization. There can also be a need to re-tune >> periodically (e

Re: [PATCH next 0/2] mmc: sdhci-pxav3: fix unbalanced pm and clock issues

On 4 January 2015 at 16:15, Jisheng Zhang wrote: > These two patches fix unbalanced pm and clock issues. The clock unbalance > issue would cause power consumption regression because the clock will never > be gated at runtime PM suspend. > > Jisheng Zhang (2): > mmc: sdhci-pxav3: fix unbalanced c

Re: [PATCH v3 4/4] mmc: sdhci: host: add new f_sdh30

On 9 January 2015 at 12:41, Vincent Yang wrote: > This patch adds new host controller driver for > Fujitsu SDHCI controller f_sdh30. > > Signed-off-by: Andy Green > Signed-off-by: Vincent Yang > Signed-off-by: Tetsuya Takinishi > --- > .../devicetree/bindings/mmc/sdhci-fujitsu.txt | 30 +

Re: [RFC PATCH 00/13] mmc: host: Add facility to support re-tuning

On 5 December 2014 at 18:40, Adrian Hunter wrote: > Hi > > Here are some patches to move re-tuning support out of > sdhci and into the core, and add support for HS400 > re-tuning. > > Currently sdhci does re-tuning transparently by > calling sdhci_execute_tuning() from its ->request() > function.

Re: [PATCH 02/13] mmc: host: Add facility to support re-tuning

Hi Adrian, Thanks for working on this and apologize for my late reply! On 5 December 2014 at 18:41, Adrian Hunter wrote: > Currently, there is core support for tuning during > initialization. There can also be a need to re-tune > periodically (e.g. sdhci) or to re-tune after the > host controlle

Re: [PATCH 12/13] mmc: sdhci: Always init buf_ready_int

On 5 December 2014 at 18:41, Adrian Hunter wrote: > There is no point making the initialization > of buf_ready_int conditional on host version. > Simplify by just doing it always. Note that > the other conditional initializations will be > removed when the new way of doing re-tuning > is taken int

Re: [PATCH 04/13] mmc: core: Move mmc_card_removed() into mmc_start_request()

On 5 December 2014 at 18:41, Adrian Hunter wrote: > Both callers of mmc_start_request() call mmc_card_removed() > so move that call into mmc_start_request(). > > This patch is preparation for adding re-tuning support. > > Signed-off-by: Adrian Hunter Thanks! Applied for next. Kind regards Uffe

Re: [PATCH 01/13] mmc: core: Simplify by adding mmc_execute_tuning()

On 5 December 2014 at 18:40, Adrian Hunter wrote: > For each MMC, SD and SDIO there is code that > holds the clock, calls ops->execute_tuning, and > releases the clock. Simplify the code a bit by > providing a separate function to do that. > > Signed-off-by: Adrian Hunter Thanks! Applied for nex

Re: [PATCH 0/17 v2] tmio: mmc: header cleanup / sh_mobile_cleanup

On 13 January 2015 at 05:56, Kuninori Morimoto wrote: > > Hi Ulf > > These are v2 of tmio mmc / sh_mobile_sdhi cleanup patches. > v1 patch and in its discuss, we need 3 type of patch-set > 1. header cleanup > 2. sh_mobile_sdhi DMA > 3. DMAEngine cleanup > > These are including 1. header cleanup

Re: [PATCH v1] sdhci-acpi: fix copy'n'paste typos in the comments

On 12 January 2015 at 18:37, Andy Shevchenko wrote: > Just fix the comments, no functional changes. > > Signed-off-by: Andy Shevchenko Thanks! Applied for next. Kind regards Uffe > --- > drivers/mmc/host/sdhci-acpi.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git

Re: [PATCH 0/3] Convert omap_hsmmc to use common devicetree parsing code.

On 12 January 2015 at 20:23, NeilBrown wrote: > This is another resend with mmc_gpio_set_cd_isr() now returning > void and being EXPORTed. > > I included > WARN_ON(ctx->cd_gpio_isr); > to guard against misuse. > > My goal is to get omap_hsmmc to use the common code for parsing of, > partic

Re: [PATCH v7 0/3] mmc: core: hw_reset changes

2015-01-13 9:19 GMT+01:00 Ulf Hansson : > On 12 January 2015 at 16:11, Ulf Hansson wrote: >> On 12 January 2015 at 15:38, Johan Rudholm wrote: >>> Make the mmc_hw_reset routine more generic, by putting the (e)MMC- >>> specific stuff in the new bus_ops->reset in mmc.c. Add a >>> bus_ops->reset for

Re: [PATCH v7 0/3] mmc: core: hw_reset changes

On 12 January 2015 at 16:11, Ulf Hansson wrote: > On 12 January 2015 at 15:38, Johan Rudholm wrote: >> Make the mmc_hw_reset routine more generic, by putting the (e)MMC- >> specific stuff in the new bus_ops->reset in mmc.c. Add a >> bus_ops->reset for SD cards, allowing them to be restarted when