On Sat, Jun 18, 2011 at 07:50:37PM +0200, Sebastian Rasmussen wrote:
> Signed-off-by: Sebastian Rasmussen
I don't think it improves readability, so not worth the change IMO.
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions
On Sat, Jun 18, 2011 at 07:50:32PM +0200, Sebastian Rasmussen wrote:
Description of what was done is missing. How it was tested might be interesting
for such patches, too.
> Signed-off-by: Sebastian Rasmussen
> ---
> drivers/mmc/card/block.c | 10 +-
> drivers/mmc/card/queue.c
On Sat, Jun 18, 2011 at 07:50:23PM +0200, Sebastian Rasmussen wrote:
Please state in the commit-msg what kind of errors have been fixed.
They all seem to be whitespace related issues. Have you checked that the
binaries are identical before and after your patch? That could also go into the
commit-
Hi Per,
On Fri, Jun 17 2011, Per Forlin wrote:
> Don't use the returned sg_len from dma_map_sg() as inparameter
> to dma_unmap_sg(). Use the original sg_len for both dma_map_sg
> and dma_unmap_sg according to the documentation in DMA-API.txt.
>
> Signed-off-by: Per Forlin
> Reviewed-by: Venkatram
Hi,
On Tue, Jun 14 2011, Sourav Poddar wrote:
> From: Anand Gadiyar
>
> The OMAP HSMMC driver uses an ocr_mask to determine the
> list of voltages supported by the card. It populates this
> mask based on the list of voltages supported by the
> regulator that supplies the voltage.
>
> Commit 64be9
Hi,
On Wed, Jun 08 2011, Zhangfei Gao wrote:
> v3->v4
> Update patch sequence and mmp2_defconfig
> update driver/mmc/host/Kconfig
> Remove get_ro
>
> The patches to provide separate sdhci driver for mmp2 and pxa910
> based on sdhci-platfm.
> Rename to sdhci-pxav3.c and sdhci-pxav2.c
> Remove obsol
Don't use the returned sg_len from dma_map_sg() as inparameter
to dma_unmap_sg(). Use the original sg_len for both dma_map_sg
and dma_unmap_sg according to the documentation in DMA-API.txt.
Signed-off-by: Per Forlin
Reviewed-by: Venkatraman S
---
drivers/mmc/host/omap_hsmmc.c |5 +++--
1 fi
Add a debugfs file "testlist" to print all available tests
Signed-off-by: Per Forlin
---
drivers/mmc/card/mmc_test.c | 39 ++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 233
Break out code without functional changes. This simplifies the code and
makes way for handle two parallel request.
Signed-off-by: Per Forlin
---
drivers/mmc/card/block.c | 246 ++---
1 files changed, 142 insertions(+), 104 deletions(-)
diff --git a/drive
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 isuue_rw_rq
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
---
drivers/mmc/core/core.c| 54 +
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
---
drivers/mmc/card/queue.c | 44 ++--
drivers/mmc/card/queue.h |3
Break out code from mmc_blk_issue_rw_rq to create a
block request prepare function. This doesn't change
any functionallity. This helps when handling more
than one active block request.
Signed-off-by: Per Forlin
---
drivers/mmc/card/block.c | 224 -
1
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. This
Add four tests for read and write performance per
different transfer size, 4k to 4M.
* Read using blocking mmc request
* Read using none blocking mmc request
* Write using blocking mmc request
* Write using none blocking mmc request
The host dirver must support pre_req() and post_req()
in orde
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 mmci
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
---
dri
Previously there has only been one function mmc_wait_for_req()
to start and wait for a request. This patch adds
* mmc_start_req() - starts a request wihtout waiting
If there is on ongoing request wait for completion
of that request and start the new one and return.
Does not wait for the n
On Thu, Jun 2, 2011 at 9:49 PM, Heiko Stübner wrote:
> Hi,
>
> after upgrading my development kernel from 2.6.38 to 3.0rc1 I get flooded
> (i.e.
> it never stops) by messages of the form:
Even though it's not really related to SDIO, does reverting 06e8935
("mmc: sdio: optimized SDIO IRQ handling
How significant is the cache maintenance over head?
It depends, the eMMC are much faster now
compared to a few years ago and cache maintenance cost more due to
multiple cache levels and speculative cache pre-fetch. In relation the
cost for handling the caches have increased and is now a bottle neck
Hi again,
Am Donnerstag 16 Juni 2011, 22:35:52 schrieb Andrei Warkentin:
> On Thu, Jun 16, 2011 at 3:14 PM, Heiko Stübner wrote:
> > Am Dienstag 14 Juni 2011, 22:32:41 schrieb Andrei Warkentin:
> >> Hi Heiko,
> >>
> >> On Tue, Jun 14, 2011 at 9:10 AM, Heiko Stübner wrote:
> >> > nope, no update
Signed-off-by: Sebastian Rasmussen
---
drivers/mmc/card/block.c| 26 --
drivers/mmc/card/queue.c|3 ++-
drivers/mmc/card/queue.h|3 ++-
drivers/mmc/core/bus.c |3 ++-
drivers/mmc/core/bus.h | 13 +++--
drivers/mmc/core/core.c
Signed-off-by: Sebastian Rasmussen
---
drivers/mmc/card/block.c | 10 +-
drivers/mmc/card/queue.c | 15 +--
drivers/mmc/card/sdio_uart.c |2 +-
drivers/mmc/core/bus.c |5 +
drivers/mmc/core/bus.h |2 +-
drivers/mmc/core/core.c |
Signed-off-by: Sebastian Rasmussen
---
drivers/mmc/card/block.c| 14 ++
drivers/mmc/card/mmc_test.c | 34 +-
drivers/mmc/card/queue.c| 14 +++---
drivers/mmc/core/core.c |2 +-
drivers/mmc/core/mmc.c |2 +-
drivers
From: Sebastian Rasmussen
Pretty self-descriptive.
Signed-off-by: Sebastian Rasmussen
---
drivers/mmc/host/mmci.c | 38 ++
1 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 5da5bea..a94
From: dsd.o...@gmail.com [dsd.o...@gmail.com] On Behalf Of Daniel Drake
[d...@laptop.org]
Sent: Saturday, June 18, 2011 2:33 AM
To: Philip Rakity
Cc: Zhangfei Gao; Bing Zhao; Benson Chau; linux-mmc@vger.kernel.org
Subject: Re: SD8686 fast power-cycle probl
On 17 June 2011 17:39, Daniel Drake wrote:
> If we power down the card, and then *immediately* power it on again
> (and performing the CMD5,5,3,7 init sequence), the card fails to
> respond to the first CMD5.
>
> We have identified two workarounds to this problem:
> 1. If we wait 300ms after power
On 17 June 2011 19:49, Philip Rakity wrote:
>
> sdio_reset is harmless to non-sdio devices. Especially since it is in the
> main power up path.
>
> I see no reason this should be done. Can you prepare a patch ?
A patch to remove the sdio_reset() call from mmc_rescan_try_freq()? If
my understan
28 matches
Mail list logo
