On Mon, Jun 27, 2011 at 2:02 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jun 27, 2011 at 01:34:48PM +0300, saeed bishara wrote:
Russell,
I'm curious about the correctness of this patch for systems with
outer cache. shouldn't the dsb be issued before the outer cache
From: Ulf Hansson ulf.hans...@stericsson.com
Stresstesting insert/remove of SD-cards can trigger
a StartBitErr. This made the driver to hang in forever
waiting for a non ocurring data timeout.
This bit and interrupt is documented in the original
PL180 TRM, just never implemented until now.
From: Ulf Hansson ulf.hans...@stericsson.com
For the st_clkdiv variant f_min is too low for practical cases,
there is a heuristic calculation that appear to set the min
frequency to mclk rounded up with 512, for our practical use
cases dividing by 257 gives a reasonable floor value on the
ST
From: Linus Walleij linus.wall...@linaro.org
This is a collection of ST-Ericsson patches for MMCI for 3.1.
They are arranged in rising controversy-order for incremental
handling...
[1/4] is pretty straight-formward handling of a missing error
bit.
[2/4] adjusts the min frequency for the card
From: Ulf Hansson ulf.hans...@stericsson.com
The end of a dma|pio data transfer is synced with the
DATAEND irq. This will prevent the mmci driver from ending
the request before the dma|pio job is completely done.
For dma we use DMA_PREP_INTERRUPT to register a callback
function which is called
pre_req() runs dma_map_sg(), post_req() runs dma_unmap_sg.
If not calling pre_req() before omap_hsmmc_request()
dma_map_sg will be issued before starting the transfer.
It is optional to use pre_req(). If issuing pre_req()
post_req() must be to be called as well.
Signed-off-by: Per Forlin
pre_req() runs dma_map_sg() and prepares the dma descriptor
for the next mmc data transfer. post_req() runs dma_unmap_sg.
If not calling pre_req() before mmci_request(), mmci_request()
will prepare the cache and dma just like it did it before.
It is optional to use pre_req() and post_req() for
Add a debugfs file testlist to print all available tests
Signed-off-by: Per Forlin per.for...@linaro.org
---
drivers/mmc/card/mmc_test.c | 39 ++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/mmc_test.c
Add four tests for read and write performance per
different transfer size, 4k to 4M.
* Read using blocking mmc request
* Read using non-blocking mmc request
* Write using blocking mmc request
* Write using non-blocking mmc request
The host dirver must support pre_req() and post_req()
in order
test that measures how the mmc bandwidth depends on the numbers of sg elements
in the sg list. The transfer size if fixed and sg length goes from a few up
to 512. The purpose is to measure overhead caused by multiple sg elements.
Signed-off-by: Per Forlin per.for...@linaro.org
---
The way the request data is organized in the mmc queue struct
it only allows processing of one request at the time.
This patch adds a new struct to hold mmc queue request data such as
sg list, request, blk request and bounce buffers, and updates any functions
depending on the mmc queue struct.
Break out code without functional changes. This simplifies the code and
makes way for handle two parallel request.
Signed-off-by: Per Forlin per.for...@linaro.org
---
drivers/mmc/card/block.c | 220 +++---
1 files changed, 131 insertions(+), 89
Add an additional mmc queue request instance to make way for
two active block requests. One request may be active while the
other request is being prepared.
Signed-off-by: Per Forlin per.for...@linaro.org
---
drivers/mmc/card/queue.c | 44 ++--
This simple fault injection proved to be very useful to
test the error handling in the block.c rw_rq(). It may
still be useful to test if the host driver handle
pre_req() and post_req() correctly in case of errors.
Signed-off-by: Per Forlin per.for...@linaro.org
---
drivers/mmc/core/core.c|
Change mmc_blk_issue_rw_rq() to become asynchronous.
The execution flow looks like this:
The mmc-queue calls issue_rw_rq(), which sends the request
to the host and returns back to the mmc-queue. The mmc-queue calls
issue_rw_rq() again with a new request. This new request is prepared,
in
Hi, Ohad
One question :(
Under pm_runtime mechanism, how to dynamically open/close wlan.
If the wlan chip really power off, the firmware should be reloaded,
since the firmware is download to ram and disappear after power off.
So wlan probe function should be called for re-downloading, is it be
On 28 June 2011 10:11, Per Forlin per.for...@linaro.org wrote:
Change mmc_blk_issue_rw_rq() to become asynchronous.
The execution flow looks like this:
The mmc-queue calls issue_rw_rq(), which sends the request
to the host and returns back to the mmc-queue. The mmc-queue calls
issue_rw_rq()
This patches are tested on samsung exynos4 platform.
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
On Tue, Jun 28, 2011 at 5:11 PM, Per Forlin per.for...@linaro.org wrote:
How significant is the cache maintenance over head?
It depends, the eMMC are much faster now
compared to a few years
Hi,
I'm trying to figure out why the broken write transfer tests in mmc_test
require the result to be -ETIMEDOUT, so that I can make dw_mmc pass
these tests. Perhaps somebody could explain.
I can understand for reads, that the controller is waiting for the start
bit on the data lines and so it
Hi,
I'm trying to figure out why the broken write transfer tests in mmc_test
require the result to be -ETIMEDOUT, so that I can make dw_mmc pass
these tests. Perhaps somebody could explain.
I can understand for reads, that the controller is waiting for the start
bit on the data lines and so it
Hi..
I found the MMC_CAP_BUS_WIDTH_TEST...
In mailing, I read the related patches..
but i didn't fully understand...
/*
* If controller can't handle bus width test,
* compare ext_csd previously read in 1 bit mode
* against ext_csd at new bus width
*/
if (!(host-caps MMC_CAP_BUS_WIDTH_TEST))
Hi Zhangfei,
On Tue, Jun 28, 2011 at 12:13 PM, zhangfei gao zhangfei@gmail.com wrote:
One question :(
Np, feel free to ask !
(but it's usually better to start a new thread, rather then forking an
existing one under the same subject)
Under pm_runtime mechanism, how to dynamically
Hi
Here is a patch that sets a maximum discard size for host controllers
that cannot manage large timeouts. And another patch putting it into
use for shdci.
Adrian Hunter (2):
mmc: queue: let host controllers specify maximum discard timeout
mmc: sdhci: specify maximum discard
Some host controllers will not operate without a hardware
timeout that is limited in value. However large discards
require large timeouts, so there needs to be a way to
specify the maximum discard size.
A host controller driver may now specify the maximum discard
timeout possible so that
In general, SDHC hardware timeout cannot be avoided.
Accordingly, the maximum timeout is specified to limit
the maximum discard size.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
drivers/mmc/host/sdhci.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git
On Tue, 28 Jun 2011 11:37:25 +0100
James Hogan james.ho...@imgtec.com wrote:
Hi,
I'm trying to figure out why the broken write transfer tests in mmc_test
require the result to be -ETIMEDOUT, so that I can make dw_mmc pass
these tests. Perhaps somebody could explain.
I can understand for
(cc'ing Adrian also)
Hi Balaji
On Wed, 22 Jun 2011, Balaji T K wrote:
Use runtime autosuspend APIs to enable auto suspend delay
Does this really need to use runtime autosuspend? Seems to me that since
PM runtime is just controlling the MMC IP blocks and not the regulators in
this instance,
Removing the custom state machine - lazy disable framework in omap_hsmmc
to make way for runtime pm to handle host controller
power states.
This allows mmc_host_enable/mmc_host_disable to be replaced by
runtime get_sync and put_sync at host controller driver.
Enable runtime PM in omap_hsmmc
lazy_disable framework in OMAP HSMMC manages multiple low power states
and Card is powered off after inactivity time of 8 seconds.
Based on previous discussion on the list, card power (regulator)
handling (when to power OFF/ON) should ideally be handled by core layer.
Remove usage of lazy disable
add runtime pm support to HSMMC host controller
Use runtime pm API to enable/disable HSMMC clock
Use runtime autosuspend APIs to enable auto suspend delay
Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala
Signed-off-by: Balaji T K balaj...@ti.com
---
changes since v1
After runtime conversion to handle clk,
iclk node is not used
However fclk node is still used to get clock rate.
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git
On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
(cc'ing Adrian also)
Hi Balaji
On Wed, 22 Jun 2011, Balaji T K wrote:
Use runtime autosuspend APIs to enable auto suspend delay
Does this really need to use runtime autosuspend? Seems to me that since
PM runtime is
On Tue, 28 Jun 2011, T Krishnamoorthy, Balaji wrote:
On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 22 Jun 2011, Balaji T K wrote:
Use runtime autosuspend APIs to enable auto suspend delay
Does this really need to use runtime autosuspend? Seems to me
T Krishnamoorthy, Balaji balaj...@ti.com writes:
On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote:
(cc'ing Adrian also)
Hi Balaji
On Wed, 22 Jun 2011, Balaji T K wrote:
Use runtime autosuspend APIs to enable auto suspend delay
Does this really need to use runtime
On 28 June 2011 06:55, Ohad Ben-Cohen o...@wizery.com wrote:
Obviously the second hunk is necessary, but I'd like to know whether
the first one really is too or not. Can you please retest this without
that hunk (try to suspend/resume while the chip is powered off, and
again while it is powered
On Tue, Jun 28, 2011 at 11:59 PM, Daniel Drake d...@laptop.org wrote:
On 28 June 2011 06:55, Ohad Ben-Cohen o...@wizery.com wrote:
Obviously the second hunk is necessary, but I'd like to know whether
the first one really is too or not. Can you please retest this without
that hunk (try to
On 28 June 2011 22:47, Ohad Ben-Cohen o...@wizery.com wrote:
On Tue, Jun 28, 2011 at 11:59 PM, Daniel Drake d...@laptop.org wrote:
On 28 June 2011 06:55, Ohad Ben-Cohen o...@wizery.com wrote:
Obviously the second hunk is necessary, but I'd like to know whether
the first one really is too or
On Wed, Jun 29, 2011 at 12:54 AM, Daniel Drake d...@laptop.org wrote:
Too many patches floating around, just trying to be sure of what I'm doing!
Ok, let's start from fresh :)
Let's take 3.0-rc5, it already includes our work:
297c7f2 mmc: sdio: fix runtime PM path during driver removal
c6e633a
+Rajendra
Balaji T K balaj...@ti.com writes:
add runtime pm support to HSMMC host controller
Use runtime pm API to enable/disable HSMMC clock
Use runtime autosuspend APIs to enable auto suspend delay
Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala
From: Wonil Choi wonil22.c...@samsung.com
Signed-off-by: Wonil Choi wonil22.c...@samsung.com
Signed-off-by: Minho Ban mh...@samsung.com
Cc: Ben Dooks ben-li...@fluff.org
Signed-off-by: Kukjin Kim kgene@samsung.com
---
drivers/mmc/host/sdhci-s3c.c |6 ++
1 files changed, 2
Philip Rakity wrote:
On Jun 28, 2011, at 3:54 AM, Jaehoon Chung wrote:
Hi..
I found the MMC_CAP_BUS_WIDTH_TEST...
In mailing, I read the related patches..
but i didn't fully understand...
/*
* If controller can't handle bus width test,
* compare ext_csd previously read in 1 bit mode
*
On Jun 28, 2011, at 9:42 PM, Jaehoon Chung wrote:
Philip Rakity wrote:
On Jun 28, 2011, at 3:54 AM, Jaehoon Chung wrote:
Hi..
I found the MMC_CAP_BUS_WIDTH_TEST...
In mailing, I read the related patches..
but i didn't fully understand...
/*
* If controller can't handle bus width
42 matches
Mail list logo
