Re: [PATCH 1/2] sh-mobile: enable both edges GPIO interrupts on sh7372
On Fri, Jul 15, 2011 at 08:14:23PM +0900, Magnus Damm wrote: On Fri, Jul 15, 2011 at 7:58 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: From: Magnus Damm d...@opensource.se IRQ-capable GPIOs on sh7372 can be configured to produce interrupts on both edges. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Magnus Damm d...@opensource.se --- ?drivers/sh/intc/chip.c | ? ?3 +++ ?1 files changed, 3 insertions(+), 0 deletions(-) Acked-by: Magnus Damm d...@opensource.se Applied, thanks. -- 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: [PATCH] mmc: sdhci: fix retuning timer wrongly deleted in sdhci_tasklet_finish
On Thu, Jul 21, 2011 at 05:35:02PM +0800, zhangfei gao wrote: Does the execute_tuning is called again? del_timer is not delete timer really, but deactivate the timer, which could be re-activated by mod_timer. So if execute_tuning is called, the mod_timer will tigger the tuning timer again. Hi zhangfei, Thanks for the comment. The execute_tuning will be called at two places: 1 In mmc_sd_init_uhs_card, when host is initializing an UHS card, and the re-tuning timer will be activated for the first time; 2 When re-tuning timer expired So if the re-tuning timer is deactivated in sdhci_tasklet_finish, execute_tuning will have no chance of getting called again, and the host will not be able to do the re-tuning anymore. Signed-off-by: Aaron Lu aaron...@amd.com --- drivers/mmc/host/sdhci.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 91d9892..6250bac 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1863,9 +1863,6 @@ static void sdhci_tasklet_finish(unsigned long param) del_timer(host-timer); - if (host-version = SDHCI_SPEC_300) - del_timer(host-tuning_timer); - mrq = host-mrq; /* -- 1.7.1 -- 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
[PATCH] OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1
Remove OMAP4_USBC1_ICUSB_PWRDNZ_MASK during enable/disable PWRDNZ mode for
MMC1_PBIAS and associated extended-drain MMC1 I/O cell. This is in accordance
with the control module programming guide. This fixes a bug where if trying to
use gpio_98 or gpio_99 and MMC1 at the same time the GPIO signal will be
affected by a changing SDMMC1_VDDS.
Software must keep MMC1_PBIAS cell and MMC1_IO cell PWRDNZ signals low whenever
SDMMC1_VDDS ramps up/down or changes for cell protection purposes.
MMC1 is based on SDMMC1_VDDS whereas USBC1 is based on SIM_VDDS therefore
they can operate independently.
Signed-off-by: Bryan Buckley bryan.buck...@ti.com
---
arch/arm/mach-omap2/hsmmc.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 3842405..a6135df 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -144,8 +144,7 @@ static void omap4_hsmmc1_before_set_reg(struct device *dev,
int slot,
*/
reg = omap4_ctrl_pad_readl(control_pbias_offset);
reg = ~(OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
- OMAP4_MMC1_PWRDNZ_MASK |
- OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
+ OMAP4_MMC1_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
@@ -165,8 +164,7 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev,
int slot,
else
reg |= OMAP4_MMC1_PBIASLITE_VMODE_MASK;
reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
- OMAP4_MMC1_PWRDNZ_MASK |
- OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
+ OMAP4_MMC1_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
/* 4 microsec delay for comparator to generate an error*/
udelay(4);
@@ -174,16 +172,14 @@ static void omap4_hsmmc1_after_set_reg(struct device
*dev, int slot,
if (reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK) {
pr_err(Pbias Voltage is not same as LDO\n);
/* Caution : On VMODE_ERROR Power Down MMC IO */
- reg = ~(OMAP4_MMC1_PWRDNZ_MASK |
- OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
+ reg = ~(OMAP4_MMC1_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
} else {
reg = omap4_ctrl_pad_readl(control_pbias_offset);
reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
OMAP4_MMC1_PWRDNZ_MASK |
- OMAP4_MMC1_PBIASLITE_VMODE_MASK |
- OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
+ OMAP4_MMC1_PBIASLITE_VMODE_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
}
--
1.7.0.4
--
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: [RFC/RFT] MMC: CORE: eMMC in Sleep mode before suspend
On 19/07/2011 7:48 p.m., Chris Ball wrote: Hi, On Tue, Jul 19 2011, S, Venkatraman wrote: On Wed, Jul 13, 2011 at 8:06 PM, Balaji T Kbalaj...@ti.com wrote: Put MMC to sleep if it supports SLEEP/AWAKE (CMD5) in the mmc suspend to minimize power consumption. Signed-off-by: Balaji T Kbalaj...@ti.com Balaji, Would you mind reposting the patch without the RFC and s/CORE/core in subject line ? You can add my Acked-by: Venkatraman Ssvenk...@ti.com No need to resend, thanks -- pushed to mmc-next with these changes and the ACK. Anyone object to letting this soak in mmc-next for a release and merging it in 3.2? I'm worried that we'll find card or host quirks around this, and the 3.0 release is probably happening today. eMMC often have VccQ (logic) always on (or sharing the same power as SDRAM which comes to the same thing), but can switch off Vcc (NAND core). However, turning off Vcc without first putting the card to sleep can result in errors i.e. you are not allowed to do it. This patch seems to be covering the VccQ always on case but relies on CMD0 to wake up the card. If that is what is going on, then some comments to that effect are needed, including within mmc_init_card to note that mmc_go_idle is needed for cards that are asleep - if that is, in fact, correct. Also, wouldn't it be nice to wake up the card with CMD5 which should be much faster than re-initialising? - Chris. -- 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: [PATCH] mmc: sdhci: fix retuning timer wrongly deleted in sdhci_tasklet_finish
Aaron,
Code is fine. Do you want to also fix the problem with suspend or should I do
the patch ?
When we are suspending we should kill the tuning timer.
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 4da6a4d..88c25e8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2289,18 +2289,14 @@ int sdhci_suspend_host(struct sdhci_host *host,
pm_message_t state)
sdhci_disable_card_detection(host);
- /* Disable tuning since we are suspending */
- if (host-version = SDHCI_SPEC_300 host-tuning_count
- host-tuning_mode == SDHCI_TUNING_MODE_1) {
- host-flags = ~SDHCI_NEEDS_RETUNING;
- mod_timer(host-tuning_timer, jiffies +
- host-tuning_count * HZ);
- }
-
ret = mmc_suspend_host(host-mmc);
if (ret)
return ret;
+ /* Disable tuning since we are suspending */
+ if (host-version = SDHCI_SPEC_300)
+ del_timer_sync(host-tuning_timer);
+
free_irq(host-irq, host);
if (host-vmmc)
Philip
On Jul 21, 2011, at 3:03 AM, Aaron Lu wrote:
On Thu, Jul 21, 2011 at 05:35:02PM +0800, zhangfei gao wrote:
Does the execute_tuning is called again?
del_timer is not delete timer really, but deactivate the timer, which
could be re-activated by mod_timer.
So if execute_tuning is called, the mod_timer will tigger the tuning
timer again.
Hi zhangfei,
Thanks for the comment.
The execute_tuning will be called at two places:
1 In mmc_sd_init_uhs_card, when host is initializing an UHS card,
and the re-tuning timer will be activated for the first time;
2 When re-tuning timer expired
So if the re-tuning timer is deactivated in sdhci_tasklet_finish,
execute_tuning will have no chance of getting called again, and the
host will not be able to do the re-tuning anymore.
Signed-off-by: Aaron Lu aaron...@amd.com
---
drivers/mmc/host/sdhci.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 91d9892..6250bac 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1863,9 +1863,6 @@ static void sdhci_tasklet_finish(unsigned long
param)
del_timer(host-timer);
- if (host-version = SDHCI_SPEC_300)
- del_timer(host-tuning_timer);
-
mrq = host-mrq;
/*
--
1.7.1
--
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: sdio add regulator vsdio
Hi Zhangfei,
See below.
Philip
sdio client may be required power on/off dynamically.
With regulator vsdio, sdio client power on/off could be executed by
mmc_power_up/down
CC: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Zhangfei Gao zhangfei@marvell.com
---
drivers/mmc/host/sdhci.c | 24
include/linux/mmc/sdhci.h |2 ++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 790f959..61fff10 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1295,6 +1295,18 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
sdhci_set_clock(host, ios-clock);
+ if (host-vsdio) {
Why does this code need to be specific to sdio ? Should be generalized.
+ if (ios-power_mode != host-power_mode_old) {
+ if (ios-power_mode == MMC_POWER_OFF)
+ regulator_disable(host-vsdio);
+
+ if (ios-power_mode == MMC_POWER_UP)
+ regulator_enable(host-vsdio);
+ }
+
+ host-power_mode_old = ios-power_mode;
move up inside if since if not change no need to set.
if the regulator is shared between different devices will this work ?
+ }
+
if (ios-power_mode == MMC_POWER_OFF)
sdhci_set_power(host, -1);
else
@@ -2751,6 +2763,13 @@ int sdhci_add_host(struct sdhci_host *host)
regulator_enable(host-vmmc);
}
+ host-vsdio = regulator_get(mmc_dev(mmc), vsdio);
comment on name -- should have nothing to do with sdio.
+ if (IS_ERR(host-vsdio))
+ host-vsdio = NULL;
+ else
+ printk(KERN_INFO %s: vsdio regulator found\n,
+ mmc_hostname(mmc));
+
sdhci_init(host, 0);
#ifdef CONFIG_MMC_DEBUG
@@ -2842,6 +2861,11 @@ void sdhci_remove_host(struct sdhci_host *host, int
dead)
regulator_put(host-vmmc);
}
+ if (host-vsdio) {
+ regulator_disable(host-vsdio);
+ regulator_put(host-vsdio);
+ }
+
kfree(host-adma_desc);
kfree(host-align_buffer);
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 13c13f8..bea07c7 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -94,6 +94,8 @@ struct sdhci_host {
const struct sdhci_ops *ops;/* Low level hw interface */
struct regulator *vmmc; /* Power regulator */
+ struct regulator *vsdio;/* sdio Power regulator */
+ unsigned char power_mode_old; /* power supply mode */
/* Internal data */
struct mmc_host *mmc; /* MMC structure */
--
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: sdio add regulator vsdio
Hi Zhangfei,
Comments below.
Philip
Add regulator vsdio, which controled by mmc core to handle sdio chip power
Test With CONFIG_PM_RUNTIME=y
8787 power is enabled if any client module over sdio is insmod, and disbled
automatically after all client modules over sdio are rmmod
Also 8787 power could be controled by mmc_start/stop_host
Signed-off-by: Zhangfei Gao zhangfei@marvell.com
---
arch/arm/mach-mmp/brownstone.c | 60 ++-
1 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index c79162a..63315e2 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -89,6 +89,9 @@ static unsigned long brownstone_pin_config[] __initdata = {
GPIO41_MMC2_CMD | MFP_PULL_HIGH,
GPIO42_MMC2_CLK,
+ GPIO57_GPIO | MFP_LPM_DRIVE_HIGH | MFP_PULL_HIGH,
+ GPIO58_GPIO | MFP_LPM_DRIVE_HIGH | MFP_PULL_HIGH,
+
/* MMC2 */
GPIO165_MMC3_DAT7 | MFP_PULL_HIGH,
GPIO162_MMC3_DAT6 | MFP_PULL_HIGH,
@@ -180,12 +183,66 @@ static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc0
= {
.clk_delay_cycles = 0x1f,
};
+static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc1 = {
+ .flags = PXA_FLAG_CARD_PERMANENT,
+};
+
static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc2 = {
.clk_delay_cycles = 0x1f,
.flags = PXA_FLAG_CARD_PERMANENT
| PXA_FLAG_SD_8_BIT_CAPABLE_SLOT,
};
+static struct regulator_consumer_supply sdio_power_supplies[] = {
+ REGULATOR_SUPPLY(vsdio, sdhci-pxav3.1),
+};
+
+static struct regulator_init_data sdio_power_data = {
+ .constraints= {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(sdio_power_supplies),
+ .consumer_supplies = sdio_power_supplies,
+};
+
+static struct fixed_voltage_config sdio_power = {
+ .supply_name= vsdio,
+ .microvolts = 300,
+ .gpio = mfp_to_gpio(MFP_PIN_GPIO57),
+ .enable_high= 1,
+ .enabled_at_boot= 0,
+ .init_data = sdio_power_data,
+};
+
+static struct platform_device sdio_power_device = {
+ .name = reg-fixed-voltage,
+ .id = 2,
+ .dev = {
+ .platform_data = sdio_power,
+ },
+};
+
+static int __init brownstone_init_mmc(void)
+{
+ /*
+ * PDn: GPIO58; RESETn: GPIO57
+ * 8787, RESETn keeps high, PDn control power
+ * on: PDn 1; off: PDn 0;
+ */
Comment unclear
GPIO57 is power
GPIO58 is reset
+ int RESETn = mfp_to_gpio(MFP_PIN_GPIO58);
+
+ if (gpio_request(RESETn, sdio RESETn)) {
+ pr_err(Failed to request sdio RESETn gpio\n);
+ return -EIO;
+ }
+ gpio_direction_output(RESETn, 1);
+ gpio_free(RESETn);
The 8787 data sheet indicated that PDn should be inactive as well as reset
before
initiating power up.
Pull PDn high.
+
+ platform_device_register(sdio_power_device);
+ mmp2_add_sdhost(0, mmp2_sdh_platdata_mmc0); /* SD/MMC */
+ mmp2_add_sdhost(1, mmp2_sdh_platdata_mmc1); /* sdio */
+ mmp2_add_sdhost(2, mmp2_sdh_platdata_mmc2); /* eMMC */
+}
static void __init brownstone_init(void)
{
@@ -195,8 +252,7 @@ static void __init brownstone_init(void)
mmp2_add_uart(1);
mmp2_add_uart(3);
mmp2_add_twsi(1, NULL, ARRAY_AND_SIZE(brownstone_twsi1_info));
- mmp2_add_sdhost(0, mmp2_sdh_platdata_mmc0); /* SD/MMC */
- mmp2_add_sdhost(2, mmp2_sdh_platdata_mmc2); /* eMMC */
+ brownstone_init_mmc();
/* enable 5v regulator */
platform_device_register(brownstone_v_5vp_device);
--
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: ARM: mmp2: support sdio with regulator vsdio
With correct subject
On Jul 21, 2011, at 5:10 PM, Philip Rakity wrote:
Hi Zhangfei,
Comments below.
Philip
Add regulator vsdio, which controled by mmc core to handle sdio chip power
Test With CONFIG_PM_RUNTIME=y
8787 power is enabled if any client module over sdio is insmod, and disbled
automatically after all client modules over sdio are rmmod
Also 8787 power could be controled by mmc_start/stop_host
Signed-off-by: Zhangfei Gao zhangfei@marvell.com
---
arch/arm/mach-mmp/brownstone.c | 60 ++-
1 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index c79162a..63315e2 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -89,6 +89,9 @@ static unsigned long brownstone_pin_config[] __initdata = {
GPIO41_MMC2_CMD | MFP_PULL_HIGH,
GPIO42_MMC2_CLK,
+GPIO57_GPIO | MFP_LPM_DRIVE_HIGH | MFP_PULL_HIGH,
+GPIO58_GPIO | MFP_LPM_DRIVE_HIGH | MFP_PULL_HIGH,
+
/* MMC2 */
GPIO165_MMC3_DAT7 | MFP_PULL_HIGH,
GPIO162_MMC3_DAT6 | MFP_PULL_HIGH,
@@ -180,12 +183,66 @@ static struct sdhci_pxa_platdata
mmp2_sdh_platdata_mmc0 = {
.clk_delay_cycles = 0x1f,
};
+static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc1 = {
+.flags = PXA_FLAG_CARD_PERMANENT,
+};
+
static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc2 = {
.clk_delay_cycles = 0x1f,
.flags = PXA_FLAG_CARD_PERMANENT
| PXA_FLAG_SD_8_BIT_CAPABLE_SLOT,
};
+static struct regulator_consumer_supply sdio_power_supplies[] = {
+REGULATOR_SUPPLY(vsdio, sdhci-pxav3.1),
+};
+
+static struct regulator_init_data sdio_power_data = {
+.constraints= {
+.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+},
+.num_consumer_supplies = ARRAY_SIZE(sdio_power_supplies),
+.consumer_supplies = sdio_power_supplies,
+};
+
+static struct fixed_voltage_config sdio_power = {
+.supply_name= vsdio,
+.microvolts = 300,
+.gpio = mfp_to_gpio(MFP_PIN_GPIO57),
+.enable_high= 1,
+.enabled_at_boot= 0,
+.init_data = sdio_power_data,
+};
+
+static struct platform_device sdio_power_device = {
+.name = reg-fixed-voltage,
+.id = 2,
+.dev = {
+.platform_data = sdio_power,
+},
+};
+
+static int __init brownstone_init_mmc(void)
+{
+/*
+ * PDn: GPIO58; RESETn: GPIO57
+ * 8787, RESETn keeps high, PDn control power
+ * on: PDn 1; off: PDn 0;
+ */
Comment unclear
GPIO57 is power
GPIO58 is reset
+int RESETn = mfp_to_gpio(MFP_PIN_GPIO58);
+
+if (gpio_request(RESETn, sdio RESETn)) {
+pr_err(Failed to request sdio RESETn gpio\n);
+return -EIO;
+}
+gpio_direction_output(RESETn, 1);
+gpio_free(RESETn);
The 8787 data sheet indicated that PDn should be inactive as well as reset
before
initiating power up.
Pull PDn high.
+
+platform_device_register(sdio_power_device);
+mmp2_add_sdhost(0, mmp2_sdh_platdata_mmc0); /* SD/MMC */
+mmp2_add_sdhost(1, mmp2_sdh_platdata_mmc1); /* sdio */
+mmp2_add_sdhost(2, mmp2_sdh_platdata_mmc2); /* eMMC */
+}
static void __init brownstone_init(void)
{
@@ -195,8 +252,7 @@ static void __init brownstone_init(void)
mmp2_add_uart(1);
mmp2_add_uart(3);
mmp2_add_twsi(1, NULL, ARRAY_AND_SIZE(brownstone_twsi1_info));
-mmp2_add_sdhost(0, mmp2_sdh_platdata_mmc0); /* SD/MMC */
-mmp2_add_sdhost(2, mmp2_sdh_platdata_mmc2); /* eMMC */
+brownstone_init_mmc();
/* enable 5v regulator */
platform_device_register(brownstone_v_5vp_device);
--
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: [PATCH] mmc: sdhci: fix retuning timer wrongly deleted in sdhci_tasklet_finish
Hi Philip,
On Thu, Jul 21, 2011 at 01:27:11PM -0700, Philip Rakity wrote:
Aaron,
Code is fine.
Thanks.
Do you want to also fix the problem with suspend or should I do the patch ?
When we are suspending we should kill the tuning timer.
Yes, that is a problem.
I've another patch to add support for re-tuning mode 2 queued for
submit which should have fixed this problem, but I didn't touch anything
if mmc_suspend_host failed, so when I submit the other patch, please
take you time to review it and let's see how we can fix the problem
altogether :-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 4da6a4d..88c25e8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2289,18 +2289,14 @@ int sdhci_suspend_host(struct sdhci_host *host,
pm_message_t state)
sdhci_disable_card_detection(host);
- /* Disable tuning since we are suspending */
- if (host-version = SDHCI_SPEC_300 host-tuning_count
- host-tuning_mode == SDHCI_TUNING_MODE_1) {
- host-flags = ~SDHCI_NEEDS_RETUNING;
- mod_timer(host-tuning_timer, jiffies +
- host-tuning_count * HZ);
- }
-
ret = mmc_suspend_host(host-mmc);
if (ret)
return ret;
+ /* Disable tuning since we are suspending */
+ if (host-version = SDHCI_SPEC_300)
+ del_timer_sync(host-tuning_timer);
+
free_irq(host-irq, host);
if (host-vmmc)
Philip
On Jul 21, 2011, at 3:03 AM, Aaron Lu wrote:
On Thu, Jul 21, 2011 at 05:35:02PM +0800, zhangfei gao wrote:
Does the execute_tuning is called again?
del_timer is not delete timer really, but deactivate the timer, which
could be re-activated by mod_timer.
So if execute_tuning is called, the mod_timer will tigger the tuning
timer again.
Hi zhangfei,
Thanks for the comment.
The execute_tuning will be called at two places:
1 In mmc_sd_init_uhs_card, when host is initializing an UHS card,
and the re-tuning timer will be activated for the first time;
2 When re-tuning timer expired
So if the re-tuning timer is deactivated in sdhci_tasklet_finish,
execute_tuning will have no chance of getting called again, and the
host will not be able to do the re-tuning anymore.
Signed-off-by: Aaron Lu aaron...@amd.com
---
drivers/mmc/host/sdhci.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 91d9892..6250bac 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1863,9 +1863,6 @@ static void sdhci_tasklet_finish(unsigned long
param)
del_timer(host-timer);
- if (host-version = SDHCI_SPEC_300)
- del_timer(host-tuning_timer);
-
mrq = host-mrq;
/*
--
1.7.1
--
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
[GIT PULL] MMC updates for 3.1-rc1.
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git for-linus to receive MMC updates for 3.1. There are currently no merge conflicts, and the patches have been tested in linux-next. Thanks. Highlights are: Core: * New non-blocking request framework from Per Forlin for removing DMA preparation overhead, used by adding pre_req() and post_req() driver hooks for preparing DMA descriptors ahead of time as described in Documentation/mmc/mmc-async-req.txt. * Improved MMC error detection and recovery from Russell King. Drivers: * Fix errors with the Ricoh e823 controller (as found in ThinkPad X220, Tecra R850, Portégé R830) by lowering its SD bus frequency to 50MHz. * Runtime PM support for omap_hsmmc, tmio_mmc, and sh_mmcif. * sdhci-pltfm architecture rework by Shawn Guo. * Split up sdhci-pxa into independent sdhci-pxav2 (pxa910) and sdhci-pxav3 (MMP2) drivers. * Implement non-blocking framework hooks for the mmci driver. The following changes since commit d1e9ae47a0285d3f1699e8219ce50f656243b93f: Merge branch 'rcu/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu into core/urgent (2011-07-20 20:59:26 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git for-linus Adrian Hunter (5): mmc: queue: let host controllers specify maximum discard timeout mmc: sdhci: specify maximum discard timeout mmc: sdhci-pci: allow 8-bit bus width for Intel Medfield eMMCs mmc: omap_hsmmc: correct debug report error status mnemonics mmc: omap_hsmmc: fix oops in omap_hsmmc_dma_cb() Andy Shevchenko (5): mmc: omap_hsmmc: move hardcoded frequency constants to defines mmc: omap_hsmmc: split duplicate code to calc_divisor() function mmc: omap_hsmmc: introduce start_clock and re-use stop_clock mmc: omap_hsmmc: fix a few bugs when setting the clock divisor mmc: omap_hsmmc: refactor duplicated code Balaji T K (3): mmc: omap_hsmmc: Remove lazy_disable mmc: omap_hsmmc: add runtime pm support mmc: omap_hsmmc: Remove unused iclk Daniel Drake (1): mmc: print debug messages for runtime PM actions Guennadi Liakhovetski (6): mmc: tmio: fix recursive spinlock, don't schedule with interrupts disabled mmc: tmio: maximize power saving mmc: sh_mmcif: maximize power saving mmc: tmio: fix a recently introduced bug in DMA code mmc: tmio: fix a deadlock mmc: MAINTAINERS: add myself as a tmio-mmc maintainer Jaehoon Chung (1): mmc: block: fixed NULL pointer dereference James Hogan (10): mmc: dw_mmc: clear TXDR/RXDR ints before enabling mmc: dw_mmc: fix race with request and removal mmc: dw_mmc: convert card tasklet to workqueue mmc: dw_mmc: brackets in register access macros mmc: dw_mmc: don't hard code fifo depth, fix usage mmc: dw_mmc: handle unaligned buffers and sizes mmc: dw_mmc: fix stop when fallen back to PIO mmc: dw_mmc: remove unnecessary error messages mmc: dw_mmc: handle no CRC status error mmc: dw_mmc: reset FIFO after an error Jean-Christophe PLAGNIOL-VILLARD (1): mmc: at91_mci: move register header from include/ to drivers/ Koen Beel (1): mmc: mxs-mmc: fix clock rate setting Madhusudhan Chikkature (1): mmc: MAINTAINERS: change omap_hsmmc maintainence to orphan Major Lee (1): mmc: sdhci-pci: add 8-bit bus width support for mrst hc0 Manoj Iyer (1): mmc: Added quirks for Ricoh 1180:e823 lower base clock frequency Nicolas Ferre (2): mmc: atmel-mci: add suspend/resume support mmc: kconfig: remove EXPERIMENTAL from the DMA selection of atmel-mci Ohad Ben-Cohen (1): mmc: fix runtime PM with -ENOSYS suspend case Paul Parsons (2): mmc: tmio: Fix build error without CONFIG_MMC_SDHI mmc: tmio: Fix race condition resulting in spurious interrupts Per Forlin (12): mmc: core: add non-blocking mmc request function mmc: omap_hsmmc: add support for pre_req and post_req mmc: mmci: implement pre_req() and post_req() mmc: mmc_test: add debugfs file to list all tests mmc: mmc_test: add test for non-blocking transfers mmc: mmc_test: test to measure how sg_len affect performance mmc: block: add member in mmc queue struct to hold request data mmc: block: add a block request prepare function mmc: block: move error path in issue_rw_rq to a separate function. mmc: queue: add a second mmc queue request member mmc: block: add handling for two parallel block requests in issue_rw_rq mmc: documentation of mmc non-blocking request usage and design. Philip Rakity (1): mmc: core: Set non-default Drive Strength via platform hook Robert P. J. Day (1): mmc: Standardize header file inclusion checks. Russell King - ARM Linux (3): mmc: block: allow get_card_status() to return
Re: mmc: sdio add regulator vsdio
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 790f959..61fff10 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1295,6 +1295,18 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
sdhci_set_clock(host, ios-clock);
+ if (host-vsdio) {
Why does this code need to be specific to sdio ? Should be generalized.
sdio device, like bt/wlan have the requirement to dynamically control power.
Also the runtime_pm introduced to mmc core by Ohad, is specifically for sdio.
For mmc/sd, still not consider to dynamically control power, there
already regulator vmmc to control power.
The requirement for sdio device is more complicated, for example
during suspend, sdio device may require continue power on.
+ if (ios-power_mode != host-power_mode_old) {
+ if (ios-power_mode == MMC_POWER_OFF)
+ regulator_disable(host-vsdio);
+
+ if (ios-power_mode == MMC_POWER_UP)
+ regulator_enable(host-vsdio);
+ }
+
+ host-power_mode_old = ios-power_mode;
move up inside if since if not change no need to set.
if the regulator is shared between different devices will this work ?
What do you mean different devices.
It is considered for different sdio client devices, not consider mmc/sd.
+ }
+
if (ios-power_mode == MMC_POWER_OFF)
sdhci_set_power(host, -1);
else
@@ -2751,6 +2763,13 @@ int sdhci_add_host(struct sdhci_host *host)
regulator_enable(host-vmmc);
}
+ host-vsdio = regulator_get(mmc_dev(mmc), vsdio);
comment on name -- should have nothing to do with sdio.
--
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: sdio add regulator vsdio
+
+static int __init brownstone_init_mmc(void)
+{
+ /*
+ * PDn: GPIO58; RESETn: GPIO57
+ * 8787, RESETn keeps high, PDn control power
+ * on: PDn 1; off: PDn 0;
+ */
Comment unclear
GPIO57 is power
GPIO58 is reset
yes, typo, thanks
+ int RESETn = mfp_to_gpio(MFP_PIN_GPIO58);
+
+ if (gpio_request(RESETn, sdio RESETn)) {
+ pr_err(Failed to request sdio RESETn gpio\n);
+ return -EIO;
+ }
+ gpio_direction_output(RESETn, 1);
+ gpio_free(RESETn);
The 8787 data sheet indicated that PDn should be inactive as well as reset
before
initiating power up.
Pull PDn high.
The PDn is super-set of RESETn, keep RESETn high, and control 8787
with PDn is enough.
The Internal Reset in data sheet is not RESET pin.
--
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
