Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition dependency between devices. This patch
enables sdhci-acpi devices to s
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition dependency between devices. This patch
enables mmc hosts to suspend/re
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition dependency between devices. This patch
enables MMC/SD/SDIO card and SD
On 11/23/2015 11:26 PM, Ulf Hansson wrote:
> On 17 November 2015 at 14:48, Fu, Zhonghui
> wrote:
>>
>> On 11/16/2015 7:30 PM, Ulf Hansson wrote:
>>> On 15 November 2015 at 14:53, Fu, Zhonghui
>>> wrote:
>>>> Now, PM core supports asynchro
Any comments are welcome.
Thanks,
Zhonghui
On 11/16/2015 2:23 PM, Fu, Zhonghui wrote:
> Now, PM core supports asynchronous suspend/resume mode for devices
> during system suspend/resume, and the power state transition of one
> device may be completed in separate kernel thread. PM cor
Any comments are welcome.
Thanks,
Zhonghui
On 11/16/2015 12:20 AM, Fu, Zhonghui wrote:
> Now, PM core supports asynchronous suspend/resume mode for devices
> during system suspend/resume, and the power state transition of one
> device may be completed in separate kernel thread. PM cor
On 11/17/2015 9:48 PM, Fu, Zhonghui wrote:
>
> On 11/16/2015 7:30 PM, Ulf Hansson wrote:
>> On 15 November 2015 at 14:53, Fu, Zhonghui
>> wrote:
>>> Now, PM core supports asynchronous suspend/resume mode for devices
>>> during system suspend/resume, a
On 11/16/2015 7:30 PM, Ulf Hansson wrote:
> On 15 November 2015 at 14:53, Fu, Zhonghui
> wrote:
>> Now, PM core supports asynchronous suspend/resume mode for devices
>> during system suspend/resume, and the power state transition of one
>> device may be completed in se
On 9/21/2015 5:32 PM, Andy Shevchenko wrote:
> On Mon, 2015-09-21 at 14:51 +0800, Fu, Zhonghui wrote:
>> Now, PM core supports asynchronous suspend/resume mode for devices
>> during system suspend/resume, and the power state transition of one
>> device may be completed in s
Please review the latest version: "[PATCH v3] mmc/sdhci-acpi: enable sdhci-acpi
device to suspend/resume asynchronously"
Thanks,
Zhonghui
On 9/21/2015 2:51 PM, Fu, Zhonghui wrote:
> Now, PM core supports asynchronous suspend/resume mode for devices
> during system suspend
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables sdhci-acpi devic
Please review the latest version: "[PATCH v3] mmc: enable mmc host device to
suspend/resume asynchronously"
Thanks,
Zhonghui
On 9/21/2015 2:13 PM, Fu, Zhonghui wrote:
> Now, PM core supports asynchronous suspend/resume mode for devices
> during system suspend/resume, and
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables mmc host device
On 9/21/2015 4:41 PM, Adrian Hunter wrote:
> On 21/09/15 11:15, Adrian Hunter wrote:
>> On 21/09/15 08:29, Fu, Zhonghui wrote:
>>>
>>> On 2015/8/24 15:07, Fu, Zhonghui wrote:
>>>> On 2015/8/17 14:48, Adrian Hunter wrote:
>>>>> On 17/08/15 0
Please see the latest version: "[PATCH v3] MMC/SDIO: enable SDIO device to
suspend/resume asynchronously".
Thanks,
Zhonghui
On 9/21/2015 12:30 PM, Fu, Zhonghui wrote:
> Now, PM core supports asynchronous suspend/resume mode for devices
> during system suspend/resume, and
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables SDIO card and fu
On 2015/8/24 23:14, Fu, Zhonghui wrote:
>
> On 2015/8/17 14:51, Adrian Hunter wrote:
>> On 17/08/15 06:38, Fu, Zhonghui wrote:
>>> Hi,
>>>
>>> Any comments are welcome.
>> Same comments as here:
>>
>> http://marc.info/?l=linux-kernel&
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables sdhci-acpi devic
On 2015/8/27 21:05, Ulf Hansson wrote:
> On 3 August 2015 at 14:39, Fu, Zhonghui wrote:
>> Enable mmc host device to suspend/resume asynchronously.
>> This can improve system suspend/resume speed.
> Can or will?
>
> It would be nice to see some statistics of this to j
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables mmc host device
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables SDIO card and fu
On 2015/8/17 14:51, Adrian Hunter wrote:
> On 17/08/15 06:38, Fu, Zhonghui wrote:
>> Hi,
>>
>> Any comments are welcome.
> Same comments as here:
>
> http://marc.info/?l=linux-kernel&m=143979428424353&w=2
Now, PM core support asynchronous device
On 2015/8/17 14:52, Adrian Hunter wrote:
> On 17/08/15 06:36, Fu, Zhonghui wrote:
>> Hi,
>>
>> Any comments are welcome.
> Same comments as here:
>
> http://marc.info/?l=linux-kernel&m=143979428424353&w=2
Now, PM core support asynchronous device
On 2015/8/17 14:48, Adrian Hunter wrote:
> On 17/08/15 06:26, Fu, Zhonghui wrote:
>> Hi,
>>
>> Any comments are welcome.
>>
>>
>> Thanks,
>> Zhonghui
>>
>> On 2015/7/30 15:40, Fu, Zhonghui wrote:
>>> Enable SDIO card and func
Hi,
Any comments are welcome.
Thanks,
Zhonghui
On 2015/8/3 21:10, Fu, Zhonghui wrote:
> Enable sdhci-acpi device to suspend/resume asynchronously.
> This can improve system suspend/resume speed.
>
> Signed-off-by: Zhonghui Fu
> ---
> drivers/mmc/host/sdhci-acpi.c |
Hi,
Any comments are welcome.
Thanks,
Zhonghui
On 2015/8/3 20:39, Fu, Zhonghui wrote:
> Enable mmc host device to suspend/resume asynchronously.
> This can improve system suspend/resume speed.
>
> Signed-off-by: Zhonghui Fu
> ---
> drivers/mmc/core/host.c |1 +
>
Hi,
Any comments are welcome.
Thanks,
Zhonghui
On 2015/7/30 15:40, Fu, Zhonghui wrote:
> Enable SDIO card and function device to suspend/resume asynchronously.
> This can improve system suspend/resume speed.
>
> Signed-off-by: Zhonghui Fu
> ---
> drivers/mmc/core/sdio.
Enable sdhci-acpi device to suspend/resume asynchronously.
This can improve system suspend/resume speed.
Signed-off-by: Zhonghui Fu
---
drivers/mmc/host/sdhci-acpi.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-a
Enable mmc host device to suspend/resume asynchronously.
This can improve system suspend/resume speed.
Signed-off-by: Zhonghui Fu
---
drivers/mmc/core/host.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 99a9c90..
Enable SDIO card and function device to suspend/resume asynchronously.
This can improve system suspend/resume speed.
Signed-off-by: Zhonghui Fu
---
drivers/mmc/core/sdio.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.
Hi,Uffe
Could you please tell me into which git repository this patch is merged now?
Thanks,
Zhonghui
On 2014/8/26 0:10, Fu, Zhonghui wrote:
>
> Many thanks for your helps.
>
>
>
> Thanks,
> Zhonghui
>
>
> On 2014/8/18 20:07, Ulf Hansson wrote:
>> O
Many thanks for your helps.
Thanks,
Zhonghui
On 2014/8/18 20:07, Ulf Hansson wrote:
> On 18 August 2014 05:04, Fu, Zhonghui wrote:
>> From 21266249bbbaf9407c1e88cd5950e06ac88aeebf Mon Sep 17 00:00:00 2001
>> From: Fu Zhonghui
>> Date: Mon, 18 Aug 2014 10:48:14 +08
>From 21266249bbbaf9407c1e88cd5950e06ac88aeebf Mon Sep 17 00:00:00 2001
From: Fu Zhonghui
Date: Mon, 18 Aug 2014 10:48:14 +0800
Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on sdio
thread
781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
bf3b
Hi, everyone
I have posted this new patch in a separate mail. Many thanks for your comments.
Thanks,
Zhonghui
On 2014/8/7 14:58, Fu, Zhonghui wrote:
> kindly reminder.
>
> Thanks,
> Zhonghui
>
> On 2014/8/5 12:56, Fu, Zhonghui wrote:
>> Hi, Jaehoon
>>
>> A
>From 6cee984e1d76ba0a3320430f8cf4318ab65fcf06 Mon Sep 17 00:00:00 2001
From: Fu Zhonghui
Date: Tue, 5 Aug 2014 12:44:38 +0800
Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on sdio
thread
781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
bf3b
kindly reminder.
Thanks,
Zhonghui
On 2014/8/5 12:56, Fu, Zhonghui wrote:
> Hi, Jaehoon
>
> According to your comments, I created a new patch for this issue as follows:
>
>
> Thanks,
> Zhonghui
>
>
> From 6cee984e1d76ba0a3320430f8cf4318ab65fcf06 Mon Sep 17 00:
On 2014/8/5 4:12, Arend van Spriel wrote:
> On 08/04/14 18:52, Russell King - ARM Linux wrote:
>> On Tue, Aug 05, 2014 at 12:36:49AM +0800, Fu, Zhonghui wrote:
>>> Hi, Arend
>>>
>>> I investigated this issue, and its root cause is still that sdio
>>>
On 2014/8/5 0:52, Russell King - ARM Linux wrote:
> On Tue, Aug 05, 2014 at 12:36:49AM +0800, Fu, Zhonghui wrote:
>> Hi, Arend
>>
>> I investigated this issue, and its root cause is still that sdio
>> controller can't receive interrupts from WiFi chip on sdio b
Hi, Jaehoon
According to your comments, I created a new patch for this issue as follows:
Thanks,
Zhonghui
>From 6cee984e1d76ba0a3320430f8cf4318ab65fcf06 Mon Sep 17 00:00:00 2001
From: Fu Zhonghui
Date: Tue, 5 Aug 2014 12:44:38 +0800
Subject: [PATCH] mmc: core: sdio: Fix unconditio
On 2014/7/24 23:22, Fu, Zhonghui wrote:
> On 2014/7/21 15:42, Fu, Zhonghui wrote:
>> On 2014/6/20 0:37, Arend van Spriel wrote:
>>> On 19-06-14 18:28, Fu, Zhonghui wrote:
>>>> On 2014/6/16 16:15, Arend van Spriel wrote:
>>>>> On 16-0
Hi,
Any comments for this new patch?
Thanks,
Zhonghui
On 2014/7/20 22:51, Fu, Zhonghui wrote:
> Hi,
>
> Chris' patch is not enough to fix this bug. I made a patch as follows and
> verified it can work. Could you please give out some comments about this
> patch?
>
On 2014/7/21 15:42, Fu, Zhonghui wrote:
> On 2014/6/20 0:37, Arend van Spriel wrote:
>> On 19-06-14 18:28, Fu, Zhonghui wrote:
>>> On 2014/6/16 16:15, Arend van Spriel wrote:
>>>> On 16-06-14 07:49, Fu, Zhonghui wrote:
>>>>> From 14485894add32aedacb3
On 2014/6/20 0:37, Arend van Spriel wrote:
> On 19-06-14 18:28, Fu, Zhonghui wrote:
>>
>> On 2014/6/16 16:15, Arend van Spriel wrote:
>>> On 16-06-14 07:49, Fu, Zhonghui wrote:
>>>> From 14485894add32aedacb3e486ebb2cc2b73861abf Mon Sep 17 00:00:00 2001
>&g
Hi,
Chris' patch is not enough to fix this bug. I made a patch as follows and
verified it can work. Could you please give out some comments about this patch?
Thanks,
Zhonghui
>From 72d6f5b56fa04290fd3a055ade1d89e7c8d4 Mon Sep 17 00:00:00 2001
From: Fu Zhonghui
Date: Sun, 20 Jul
Hi,
The data type of "host" is "struct mmc_host", and there is not "quirks" member
in this structure.
Thanks,
Zhonghui
On 2014/7/14 21:26, Chris Ball wrote:
> Hi Zhonghui,
>
> On Tue, Jul 08 2014, Fu, Zhonghui wrote:
>> Why add "mmc->cap
Hi,
Why add "mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;" ? How to fix this bug?
Could you please give out some idea about this bug?
Thanks,
Zhonghui
On 2014/7/6 23:19, Fu, Zhonghui wrote:
> Yes, "mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;" of "sdhci_add_host
; MMC_CAP2_SDIO_IRQ_NOTHREAD))
> wake_up_process(host->sdio_irq_thread);
>
> I didn't test this..but i believe that it will be fixed.
>
> Best Regards,
> Jaehoon Chung
>
> On 07/04/2014 12:47 AM, Fu, Zhonghui wrote:
>> Hi, all
>>
>> The statement
Hi, all
The statement "mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;" is added in
"sdhci_add_host" function in host/sdhci.c file. In some cases, this will make
"host->sdio_irq_thread" a NULL pointer in "mmc_sdio_resume" functon of
core/sdio.c file and lead to resume failure. Could you please give
Hi, all
The mmc_sdio_init_card(drivers/mmc/core/sdio.c) function calls
mmc_alloc_card(drivers/mmc/core/bus.c) function to allocate a card structure.
card->dev.bus is assigned with mmc_bus_type in mmc_alloc_card function. Why not
assign sdio_bus_type to card->dev.bus?
struct mmc_card *mmc_all
On 2014/6/16 16:15, Arend van Spriel wrote:
> On 16-06-14 07:49, Fu, Zhonghui wrote:
>> From 14485894add32aedacb3e486ebb2cc2b73861abf Mon Sep 17 00:00:00 2001
>> From: Fu zhonghui
>> Date: Wed, 11 Jun 2014 11:06:55 +0800
>> Subject: [PATCH] brcmfmac: prevent wat
50 matches
Mail list logo
