Hi,
On Thu, Jan 05, 2012 at 07:08:27AM +, 허종만 wrote:
Hi, all..
Here is description for MMC block devices in Documentation/devices.txt :
179 block MMC block devices
0 = /dev/mmcblk0 First SD/MMC card
1 = /dev/mmcblk0p1
Hi Bin,
On Mon, Jan 9, 2012 at 11:52 AM, Barry Song barry.s...@csr.com wrote:
From: Bin Shi bin@csr.com
This patch moves suspend/resume to dev_pm_ops and add hibernation support.
It was tested on CSR SiRFprimaII cortex-a9 platform. A sd partition is used
as swsusp partition.
On 01/09/2012 01:06 AM, Jaehoon Chung wrote:
In FIFOTH register, can find bit[27:16] = FIFO_DEPTH - 1.
Finally, FIFO_DEPTH = bit[27:16] + 1.
Now, Used the 0x7ff. but 0xfff is right.
Nice catch. The patch itself looks okay, but I don't think the commit
message is very understandable, maybe
Hi all,
Please excuse me, I have some noob question regarding MMC.
I'd like to erase(discard) certain MMC partition from kernel space (i.e. kernel
module).
I know this is quite ugly design, but I have no choice but to implement the
feature (erasing given MMC partition) within kernel space for
Adrian Hunter wrote:
On 3/01/2012 12:33 p.m., Ulf Hansson wrote:
Removing a card slowly can trigger a GPIO irq to be raised far
before the card is actually removed. This means the scheduled
detect work will not find out that the card were removed and thus
the card and the block device will not
Hi Dimitry,
I tried to clarify my comments below.
BR
Ulf Hansson
Dmitry Shmidt wrote:
On Wed, Jan 4, 2012 at 3:46 AM, Ulf Hansson ulf.hans...@stericsson.com wrote:
Dmitry Shmidt wrote:
Signed-off-by: Dmitry Shmidt dimitr...@google.com
---
drivers/mmc/card/block.c |2 +-
Russell King - ARM Linux wrote:
On Mon, Dec 05, 2011 at 06:35:56PM +0100, Ulf Hansson wrote:
Instead of reading a register value everytime we need to
apply a new value for it, maintain a cached copy for it.
This also means we are able to skip writes that are not
needed.
I'm not sure this is a
On 09/01/12 13:02, Ulf Hansson wrote:
Adrian Hunter wrote:
On 3/01/2012 12:33 p.m., Ulf Hansson wrote:
Removing a card slowly can trigger a GPIO irq to be raised far
before the card is actually removed. This means the scheduled
detect work will not find out that the card were removed and thus
My concern is more about what we actually can trust; either the GPIO irq
which likely is giving more than one irq when inserting/removing a card
since the slot is probably not glitch free, or that a rescan runs to make
sure a CMD13 is accepted from the previously inserted card.
Yes, I guess
On 09/01/12 15:14, Ulf Hansson wrote:
My concern is more about what we actually can trust; either the GPIO irq
which likely is giving more than one irq when inserting/removing a card
since the slot is probably not glitch free, or that a rescan runs to make
sure a CMD13 is accepted from the
Russell King - ARM Linux wrote:
On Mon, Dec 05, 2011 at 06:35:58PM +0100, Ulf Hansson wrote:
To decrease current consumption in suspend state the
VCORE regulator, the MCLK and PCLK for the ARM PL18x
are now disabled.
When resuming the resourses are re-enabled and
register values for MMCICLOCK,
Adrian Hunter wrote:
On 09/01/12 15:14, Ulf Hansson wrote:
My concern is more about what we actually can trust; either the GPIO irq
which likely is giving more than one irq when inserting/removing a card
since the slot is probably not glitch free, or that a rescan runs to make
sure a CMD13 is
Sorry, missed one of your comments.
Adrian Hunter wrote:
On 09/01/12 15:14, Ulf Hansson wrote:
My concern is more about what we actually can trust; either the GPIO irq
which likely is giving more than one irq when inserting/removing a card
since the slot is probably not glitch free, or that a
On 04/01/12 04:07, Aaron Lu wrote:
V3: Rework on top of Adrian's vmmc patch
V2: Error processing code in sdhci_pci_suspend should not be deleted,
it is used to resume hosts which are already successfully suspended for
a multi slot pci device as suggested by Adrian.
If there are errors
Signed-off-by: Dmitry Shmidt dimitr...@google.com
---
drivers/mmc/card/block.c |4 ++--
drivers/mmc/core/bus.c | 27 +--
include/linux/mmc/card.h |2 +-
3 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/card/block.c
Hi,
On 01/09/2012 08:27 PM, Ulf Hansson wrote:
Hi,
An overall question: How will you prevent each host driver from doing power
save operations while there is an ongoing BKOPS?
Power save operation could be to disable the clock to the card. Is that OK?
If not, I think we have two
Hi Tony,
On Tue, Jan 10, 2012 at 7:44 AM, Lin Tony-B19295 b19...@freescale.com wrote:
[Tony Lin]does it mean Runtime PM is not fully supported by SD/MMC stack?
SDIO runtime PM is fully supported (there were also some initial MMC
runtime PM patches circulating at some point, but they were not
Hi Dmitry,
On Mon, Jan 9, 2012 at 11:34 PM, Dmitry Shmidt dimitr...@google.com wrote:
Signed-off-by: Dmitry Shmidt dimitr...@google.com
---
drivers/mmc/card/block.c | 4 ++--
drivers/mmc/core/bus.c | 27 +--
include/linux/mmc/card.h | 2 +-
3 files
18 matches
Mail list logo
