+static bool mmc_can_do_foreground_hpi(struct mmc_queue *mq,
+ struct request *req, unsigned int thpi)
+{
+
+ /*
+ * If some time has elapsed since the issuing of previous write
+ * command, or if the size of the request was too small, there's
+ * no
On Wed, May 2, 2012 at 1:31 PM, Dong Aisheng b29...@freescale.com wrote:
From: Dong Aisheng dong.aish...@linaro.org
Enable pinctrl dummy states for imx platforms without pinctrl
support.
Acked-by: Stephen Warren swar...@wwwdotorg.org
Signed-off-by: Dong Aisheng dong.aish...@linaro.org
solves a deadlock problem which appears when a mmc card is
removing and a process is reading from the card at the same time.
---
drivers/mmc/host/atmel-mci.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
Hi Ludovic,
my hardware is a multiprocessor system by which the access to the card
is shared between two processors. Because of this changes happen really
frequently.
I have observed that the deadlock only occurs when the card is
desappearing and there are errors like 'end_request: I/O error,
On Mon, Apr 23, 2012 at 9:34 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
For the full text, please see
http://lists.arm.linux.org.uk/lurker/message/20120418.100954.7fa7acf8.en.html
This version contains updates for some of the comments received from the
previous round, and
mmc_execute_hpi should send the HPI command only
once, only if the card is in PRG state.
According to eMMC spec, the command's completion time is
not dependent on OUT_OF_INTERRUPT_TIME. Only the transition
out of PRG STATE is guarded by OUT_OF_INTERRUPT_TIME - which is
defined to begin at
Hi,
I see 2 fixes for existing mmc_interrupt_hpi() function:
- [PATCH 4/4] mmc: core: Send HPI only till it is successful
- [PATCH v2] mmc: core: Fix the HPI execution sequence
They are exclusive. Can you explain how final solution will look like?
Thanks,
Kostya
Try to send HPI only a fixed
On Wed, May 9, 2012 at 6:52 PM, kdorf...@codeaurora.org wrote:
Hi,
I see 2 fixes for existing mmc_interrupt_hpi() function:
- [PATCH 4/4] mmc: core: Send HPI only till it is successful
- [PATCH v2] mmc: core: Fix the HPI execution sequence
They are exclusive. Can you explain how final
On Wed, May 9, 2012 at 6:47 PM, kdorf...@codeaurora.org wrote:
mmc_execute_hpi should send the HPI command only
once, only if the card is in PRG state.
According to eMMC spec, the command's completion time is
not dependent on OUT_OF_INTERRUPT_TIME. Only the transition
out of PRG STATE is
On Wednesday 09 May 2012, Dave Chinner wrote:
In low end flash devices, some requests might take too long than normal
due to background device maintenance (i.e flash erase / reclaim procedure)
kicking in in the context of an ongoing write, stalling them by several
orders of magnitude.
On Wednesday 09 May 2012, kdorf...@codeaurora.org wrote:
+static bool mmc_can_do_foreground_hpi(struct mmc_queue *mq,
+ struct request *req, unsigned int thpi)
+{
+
+ /*
+ * If some time has elapsed since the issuing of previous write
+ * command, or
Hi,
On Wed, Apr 25 2012, Seungwon Jeon wrote:
Includes fixes for eMMC related with HS200.
Changes in v2:
- PATCH 1/2: Combine both the if conditions (from Subhash Jadavani)
Seungwon Jeon (2):
mmc: core: fix the decision of mmc card-type
mmc: core: fix the signalling 1.8V
On Wed, May 9, 2012 at 6:47 PM, kdorf...@codeaurora.org wrote:
@@ -403,6 +403,7 @@ int mmc_interrupt_hpi(struct mmc_card *card)
{
int err;
u32 status;
+ unsigned long starttime;
BUG_ON(!card);
@@ -421,27 +422,31 @@ int mmc_interrupt_hpi(struct mmc_card *card)
On Wed, May 9, 2012 at 2:05 PM, kdorf...@codeaurora.org wrote:
+static bool mmc_can_do_foreground_hpi(struct mmc_queue *mq,
+ struct request *req, unsigned int thpi)
+{
+
+ /*
+ * If some time has elapsed since the issuing of previous write
+ * command,
Hi,
On Fri, Apr 13 2012, Namjae Jeon wrote:
2012/4/12 Subhash Jadavani subha...@codeaurora.org:
With current implementation of power class selection,
mmc_select_powerclass() should never fail. So treat any error
returned by this function as serious enough to skip the card
initialization.
Hi Venkat,
On Fri, Apr 13 2012, Venkatraman S wrote:
The first 3 are straight forward / trivial fixes.
The last one is a functional change on how HPI should be invoked
on the card. This is required for my future foreground HPI series
that'll follow.
Also available at
On Wed, May 9, 2012 at 7:36 PM, kdorf...@codeaurora.org wrote:
On Wed, May 9, 2012 at 6:47 PM, kdorf...@codeaurora.org wrote:
@@ -403,6 +403,7 @@ int mmc_interrupt_hpi(struct mmc_card *card)
{
int err;
u32 status;
+ unsigned long starttime;
BUG_ON(!card);
@@
On Wed, May 9, 2012 at 7:41 PM, Chris Ball c...@laptop.org wrote:
Hi Venkat,
On Fri, Apr 13 2012, Venkatraman S wrote:
The first 3 are straight forward / trivial fixes.
The last one is a functional change on how HPI should be invoked
on the card. This is required for my future
From: Ulf Hansson ulf.hans...@linaro.org
For eMMC cards that has been initialized from a bootloader,
the VCC voltage supply must not be cut in an uncontrolled
manner, without first sending SLEEP or POWEROFF_NOTIFY.
The regulator_init_complete late initcall, may cut the VCC
regulator if it's
From: Saugata Das saugata@linaro.org
This patch adds the support for large sector size of 4KB by disabling emulation.
This patch passes eMMC DATA_SECTOR_SIZE as the logical block size during
mmc_blk_alloc_req.
In order to use this patch for 4KB sector size, ensure that USE_NATIVE_SECTOR
is
From: Saugata Das saugata@linaro.org
In this patch, we add utility to disable emulation mode in the eMMC-4.5.
This is done to increase the data sector size to 4KB.
Signed-off-by: Saugata Das saugata@linaro.org
---
mmc.c |6 ++
mmc.h |2 ++
mmc_cmds.c | 42
On Apr 13, 2012, at 7:39 AM, Namjae Jeon wrote:
Hi. Venkatraman.
You fixed 10 times. why is it 10 times ?
and checking err from mmc_send_status is not needed ? is it also
infinite case ?
Thanks.
2012/4/13 Venkatraman S svenk...@ti.com:
Try to send HPI only a fixed number of times
On Wed, May 09, 2012 at 01:59:40PM +, Arnd Bergmann wrote:
My feeling is that we should just treat every (REQ_SYNC | REQ_READ)
request the same and let them interrupt long-running writes,
independent of whether it's REQ_META or demand paging.
It's funny that the CFQ scheduler used to boost
On Mon, May 07, 2012 at 10:16:30PM +0530, S, Venkatraman wrote:
[..]
This feature doesn't fiddle with the I/O scheduler's ability to balance
read vs write requests or handling requests from various process queues (CFQ).
Does this feature work with CFQ? As CFQ does not submit sync IO (for
On Wed, May 09, 2012 at 04:15:26PM +0200, Ulf Hansson wrote:
From: Ulf Hansson ulf.hans...@linaro.org
For eMMC cards that has been initialized from a bootloader,
the VCC voltage supply must not be cut in an uncontrolled
manner, without first sending SLEEP or POWEROFF_NOTIFY.
The
On Wednesday 09 May 2012, Christoph Hellwig wrote:
On Wed, May 09, 2012 at 01:59:40PM +, Arnd Bergmann wrote:
My feeling is that we should just treat every (REQ_SYNC | REQ_READ)
request the same and let them interrupt long-running writes,
independent of whether it's REQ_META or demand
Hi,
On Wed, May 09 2012, Mark Brown wrote:
On Wed, May 09, 2012 at 04:15:26PM +0200, Ulf Hansson wrote:
From: Ulf Hansson ulf.hans...@linaro.org
For eMMC cards that has been initialized from a bootloader,
the VCC voltage supply must not be cut in an uncontrolled
manner, without first
From: David Daney david.da...@cavium.com
The OCTEON MMC controller is currently found on cn61XX and cnf71XX
devices. Device parameters are configured from device tree data.
Currenly supported are eMMC, MMC and SD devices.
Signed-off-by: David Daney david.da...@cavium.com
---
This patch
Hi. Chris.
Would you check this patch ?
Thanks.
2012/4/12, Namjae Jeon linkinj...@gmail.com:
2012/4/12 Philippe De Swert philippedesw...@gmail.com:
After the null check on md the code jumped to cmd_done, which then
will dereference md in mmc_blk_put. This patch avoids the possible
null
Hi. Chris.
Would you check this patch also ?
Thanks.
2012/4/12, Namjae Jeon linkinj...@gmail.com:
2012/4/12 Philippe De Swert philippedesw...@gmail.com:
bus_width is passed to the function and when 0 (MMC_BUS_WIDTH_1)
will cause the function to return. So in in the second test it
definitly
Hi,
On Wed, May 09 2012, Namjae Jeon wrote:
Hi. Chris.
Would you check this patch ?
Thanks.
2012/4/12, Namjae Jeon linkinj...@gmail.com:
2012/4/12 Philippe De Swert philippedesw...@gmail.com:
After the null check on md the code jumped to cmd_done, which then
will dereference md in
Hi,
On Wed, Apr 11 2012, Philippe De Swert wrote:
bus_width is passed to the function and when 0 (MMC_BUS_WIDTH_1)
will cause the function to return. So in in the second test it
definitly is different from 0, and the third test is redundant.
Signed-off-by: Philippe De Swert
32 matches
Mail list logo
