> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Tuesday, September 02, 2014 6:06 PM
> To: Gao, Yunpeng
> Cc: linux-mmc; Dong, Chuanxiao
> Subject: Re: [PATCH] mmc: sdhci-pci: disable preset register for Baytrail and
> Merrifield
>
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org
> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Ulf Hansson
> Sent: Tuesday, September 02, 2014 7:03 PM
> To: Gao, Yunpeng
> Cc: linux-mmc; Dong, Chuanxiao
> Subject: Re: [PATCH v2] mmc: sdhci
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org
> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Ulf Hansson
> Sent: Friday, August 29, 2014 8:04 PM
> To: Gao, Yunpeng
> Cc: linux-mmc; Dong, Chuanxiao
> Subject: Re: [PATCH] mmc: sdhci-acpi: add
> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Monday, August 18, 2014 5:57 PM
> To: Gao, Yunpeng
> Cc: linux-mmc; Dong, Chuanxiao
> Subject: Re: [PATCH] mmc: core: resolve divded by zero panic
>
> On 14 August 2014 12:29, Yunp
> -Original Message-
> From: Dong, Chuanxiao
> Sent: Monday, August 18, 2014 2:19 PM
> To: Gao, Yunpeng; linux-mmc@vger.kernel.org
> Subject: RE: [PATCH] mmc: core: optimize mmc device power up ramp up time
>
> > -Original Message-
> > From: Gao, Yu
, August 12, 2014 4:50 PM
To: Gao, Yunpeng; linux-mmc@vger.kernel.org
Cc: Dong, Chuanxiao
Subject: Re: [PATCH] mmc: core: export more sysfs for debugging purpose
Hi,
On 08/12/2014 04:28 PM, Yunpeng Gao wrote:
> Add some more sysfs export related to eMMC BK Ops, HPI and Hardware
> Reset fe
Sent: Tuesday, August 12, 2014 9:28 PM
To: Gao, Yunpeng
Cc: linux-mmc; Dong, Chuanxiao
Subject: Re: [PATCH] [RFC] Implement eMMC RPMB feature in kernel space
On 4 August 2014 09:15, Yunpeng Gao wrote:
> From: Chuanxiao Dong
>
> In current kernel mmc driver stack, seems it expect
,
Yunpeng
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-ow...@vger.kernel.org]
On Behalf Of Ulf Hansson
Sent: Tuesday, August 12, 2014 4:37 PM
To: Gao, Yunpeng
Cc: linux-mmc; Dong, Chuanxiao
Subject: Re: [PATCH] mmc: card: not access RPMB partition for normal read
...@samsung.com]
Sent: Monday, July 14, 2014 5:51 PM
To: Gao, Yunpeng; linux-mmc@vger.kernel.org
Subject: Re: [PATCH] mmc: blk: add emmc cache flush in shutdown callback
Hi,
On 07/14/2014 06:34 PM, Yunpeng Gao wrote:
> If eMMC Cache feature enabled, we'd better flush eMMC cache in the
> shutdo
Hi,
I'm investigating on eMMC 4.5 new features and have some concerns on below new
features:
1. Large sector size (Native 4KB sector behavior)
The eMMC4.5 Spec says 'All devices with capacities higher than 256GB
shall have native sector size of 4KB'.
And it also requires that in
>-Original Message-
>From: Andreas Dilger [mailto:adil...@dilger.ca]
>Sent: Wednesday, May 04, 2011 10:52 PM
>To: Gao, Yunpeng
>Cc: Martin K. Petersen; linux-bt...@vger.kernel.org;
>linux-e...@vger.kernel.org; linux-fsde...@vger.kernel.org;
>linux-mmc@vger.kernel.or
>Yes, I have been working on some changes that allow us to tag bios and
>pass the information out to storage. These patches have been on the back
>burner for a while due to other commitments. But I'll dig them out and
>post them later. We just discussed them a couple of weeks ago at the
>Linux Stor
Hi Park,
Thanks a lot for the response.
>It seems similar with TRIM. So how about to consider TRIM
>implementation or extend it?
Yes, file system set REQ_DISCARD flag to notify block device driver to execute
TRIM.
And I noticed there's already a flag REQ_META used for file system meta data.
But
Currently, some new storage devices have the ability to do performance
optimizations according to the type of data payload - say, file system
metadata, time-stamps, sequential write in some granularity, random write and
so on.
For example, the latest eMMC 4.5 device can support the so-called 'C
>-Original Message-
>From: linux-mmc-ow...@vger.kernel.org
>[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Andrei Warkentin
>Sent: Thursday, April 14, 2011 8:04 AM
>To: linux-mmc@vger.kernel.org
>Cc: a...@arndb.de; c...@laptop.org; Gao, Yunpeng
>Subject: Re: SE
>>> So, the question is, why the current mmc driver does not use the
>pre-defined multiple block read/write commands? Any comments?
>>>
>>
>> While I really don't know, I would guess becase the SD spec has a
>> different definition of ACMD23 than MMC, so perhaps avoiding
>> ACMD/CMD23 that was chos
Currently, the mmc driver uses open ended multiple block read/write
(CMD18/25+CMD12) commands and not use pre-defined multiple block read/write
(CMD23+CMD18/25) commands.
According to the feedback from some MMC/SD device vendors, they prefer the
pre-defined multiple block read/write commands si
>Our platform use sdhci host controller. And now there's a discussion to
>schedule
>inside sdhci_request() function of drivers/mmc/host/sdhci.c.
>According to the mmc stack code, seems the sdhci_request() is in the context
>of kernel thread (mmcqd), so I think it should be OK if schedule inside of
Hi all,
Our platform use sdhci host controller. And now there's a discussion to
schedule inside sdhci_request() function of drivers/mmc/host/sdhci.c.
According to the mmc stack code, seems the sdhci_request() is in the context of
kernel thread (mmcqd), so I think it should be OK if schedule insi
>> So, why we have to move to the 'aggressive clock gating framework'?
>
>The aggressive clock gating makes more sense since the different
>drivers will know better how to handle the gating. ios with f=0 can
>be interpreted differently. Else every driver has to register
>runtime PM hooks for this,
>> Another question is why to call pm_runtime_get/put when ios-clock changes?
>Is it based on
>> Linus Walleij's aggressive clock gating framework patch? Linus' patch doesn't
>gate SDIO cards.
>runtime_suspend of sdhci should *not* gate the sdio card. It should
>only gate the sdhci.
>An sdio bus in
>You shouldn't do this here.
>
>You didn't comment about or mentioned this change, but I guess you did
>it because you (quite reasonably) didn't want the card to be powered
>off as soon as mmc_blk_issue_rq() completes, and instead, you
>preferred to wait until some period of inactivity time passes.
>-Original Message-
>From: linux-mmc-ow...@vger.kernel.org
>[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Kyungmin Park
>Sent: Friday, August 27, 2010 3:15 PM
>To: Matt Fleming
>Cc: Jaehoon Chung; linux-mmc@vger.kernel.org; Marek Szyprowski; Andrew Morton;
>Ben Dooks
>Subject: Re: [
>>+static int mmc_runtime_suspend(struct device *dev)
>+{
>+ int status = 0;
>+ struct mmc_card *card = dev_to_mmc_card(dev);
>+
>+ mmc_power_save_host(card->host);
>+
>+ return status;
>+}
It seems the power_save callback is not implemented (Null pointer) yet for both
mmc and
Hi,
I noticed that in latest Linux kernel, a run time PM management framework has
been introduced. That is, bus/device drivers can dynamic manage their power by
calling the runtime APIs pm_runtime_put(),pm_runtime_get() and so on. I think
it's very useful for power-sensitive products, such as s
>-Original Message-
>From: linux-mmc-ow...@vger.kernel.org
>[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Alan Cox
>Sent: Thursday, June 17, 2010 11:17 PM
>To: pie...@ossman.eu; linux-mmc@vger.kernel.org
>Subject: [PATCH] MMC driver full patch for Moorestown platform
> ...
>@@ -240,
Thanks a lot to Alan for this suggestion. I think it makes sense to simulate a
scatter gather in driver for this case. I'll try it later and expect to see the
improved performance.
>-Original Message-
>From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk]
>Sent: 2010年4月13日
: 8, rw: r
start_sect: 48832, nsect: 8, rw: r
...
Thanks.
Regards,
Yunpeng
>-Original Message-
>From: James Bottomley [mailto:james.bottom...@suse.de]
>Sent: 2010年4月13日 3:58
>To: Martin K. Petersen
>Cc: Robert Hancock; Gao, Yunpeng; linux-...@vger.kernel.org;
>linux-mmc@vger.
Hi,
I'm working on a block device driver (NAND flash driver with FTL layer) on
2.6.31 Kernel. And try to improve sequential read/write performance of the
block driver.
When I debug the driver, I found that the sector numbers of every r/w request
in the request queue is always not bigger than 8
29 matches
Mail list logo
