Re: [PATCH] mmc: core: Attach PM domain prior probing of SDIO func driver

2015-06-02 Thread Ulf Hansson
On 1 June 2015 at 21:42, Dmitry Torokhov dmitry.torok...@gmail.com wrote: Hi Ulf, On Mon, Jun 01, 2015 at 12:18:25PM +0200, Ulf Hansson wrote: Other subsystem buses attach PM domains during probe, but prior calling the driver's -probe() method. During the removal phase, detaching the PM

Re: [PATCH] mmc: core: Attach PM domain prior probing of SDIO func driver

2015-06-02 Thread Russell King - ARM Linux
On Tue, Jun 02, 2015 at 09:54:13AM +0200, Ulf Hansson wrote: On the other hand, the long term plan is to have PM domain pointers assigned at device registration point instead of at probe. Since driver core then invokes the -activate|sync|dismiss() callbacks, it will make the

RE: [PATCH] mmc: card: Fixup request missing in mmc_blk_issue_rw_rq

2015-06-02 Thread 王丁
-Original Message- From: Ulf Hansson [mailto:ulf.hans...@linaro.org] Sent: Thursday, May 28, 2015 4:29 PM To: Justin Wang (王丁) Cc: kuninori.morimoto...@renesas.com; jh80.ch...@samsung.com; a...@linux-foundation.org; jbottom...@odin.com; b...@decadent.org.uk;

[PATCH 2/2] mmc: esdhc: add quirk to support 3.3v for T4240

2015-06-02 Thread Yangbo Lu
Add SDHCI_QUIRK2_CIRCUIT_SUPPORT_VS33 for T4240 Signed-off-by: Yangbo Lu yangbo...@freescale.com --- drivers/mmc/host/sdhci-of-esdhc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c index 22e9111..4f5fe42 100644 ---

Re: [PATCH] mmc: core: Attach PM domain prior probing of SDIO func driver

2015-06-02 Thread Russell King - ARM Linux
On Tue, Jun 02, 2015 at 09:51:01AM +0100, Russell King - ARM Linux wrote: What would resolve that would be to have the device registration succeed, but also to scan all devices in the system when a PM domain is attached and attach the PM domain to matching devices. The problem you then have

[PATCH] mmc: sdhci-pxav3: fix device wakeup initialization

2015-06-02 Thread Jisheng Zhang
MMC_PM_KEEP_POWER doesn't imply MMC_PM_WAKE_SDIO_IRQ, we should only enable device wake up when MMC_PM_WAKE_SDIO_IRQ is set. And pm_flags is the requested pm features, we should not set it in the host driver. At the same time, device wakeup is disabled by default, so there's no need to disable

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

2015-06-02 Thread Vinod Koul
On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote: On 05/29/2015 01:18 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote: On Tue, May 26, 2015 at 04:25:57PM +0300,

Re: [PATCH] mmc: core: Attach PM domain prior probing of SDIO func driver

2015-06-02 Thread Ulf Hansson
On 2 June 2015 at 13:07, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jun 02, 2015 at 09:51:01AM +0100, Russell King - ARM Linux wrote: What would resolve that would be to have the device registration succeed, but also to scan all devices in the system when a PM domain is

Usage of restart_handler in pwrseq_emmc

2015-06-02 Thread Heiko Stübner
Hi, I'm confused by the pwrseq-emmc registering a restart_handler for resetting an emmc in a panic-reboot case at priority 129 to schedules it just before system reboot. From what I remember from the restart-handler discussion the actuall usage is traversing the ordered list until one

Re: [PATCH] mmc: core: Attach PM domain prior probing of SDIO func driver

2015-06-02 Thread Russell King - ARM Linux
On Tue, Jun 02, 2015 at 03:18:07PM +0200, Ulf Hansson wrote: On 2 June 2015 at 13:07, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jun 02, 2015 at 09:51:01AM +0100, Russell King - ARM Linux wrote: What would resolve that would be to have the device registration succeed,

Re: Usage of restart_handler in pwrseq_emmc

2015-06-02 Thread Guenter Roeck
On 06/02/2015 08:29 AM, Heiko Stübner wrote: Hi, I'm confused by the pwrseq-emmc registering a restart_handler for resetting an emmc in a panic-reboot case at priority 129 to schedules it just before system reboot. From what I remember from the restart-handler discussion the actuall usage is