Hello,
Has anyone implement Linux support for a SDIO port expander such as
the TI TXS02612? I'm wondering how painful it would be. Particularly
the issue with SDIO interrupts--it seems those would need to be routed
around the mux directly to the CPU. We are using a OMAP3530 for the
SD controlle
I mistyped the linaro email in this patch series.
Sorry for the mess
/Per
On 12 January 2011 19:13, Per Forlin wrote:
> Add support to prepare one MMC request while another is active on
> the host. This is done by making the issue_rw_rq() asynchronous.
> The increase in throughput is proportiona
From: Linus Walleij
NOT to be mainlined, only sets the base for the double
buffer example implementation. The DMA implemenation for
MMCI is under development.
This extends the MMCI/PL180 driver with generic DMA engine support
using the PrimeCell DMA engine interface.
---
drivers/mmc/host/mmci.c
From: Ulf Hansson
NOT to be mainlined, only sets the base for the double
buffer example implementation. The DMA implemenation for
MMCI is under development.
Make use of DMA_PREP_INTERRUPT to get a callback when DMA has
successfully completed the data transfer.
To entirely ending the transfer an
This is an example of how to utilize the double buffer
support in the mmc framework. This patch is not intended
nor ready for mainline.
Implement pre_req() and post_reg() hooks. pre_req()
runs dma_map_sg and prepares the dma descriptor and
post_req calls dma_unmap_sg.
Signed-off-by: Per Forlin
-
The mmci host driver implementation for double buffering is not intended
nor ready for mainline yet. It is only an example of how to implement
pre_req() and post_req(). The reason for this is that the basic DMA
support for MMCI is not complete yet.
This patch series depends on
"[PATCH 0/5] mmc: ad
From: Ulf Hansson
NOT to be mainlined, only sets the base for the double
buffer example implementation. The DMA implemenation for
MMCI is under development.
host->last_blockend flag is now set only for the last
MCI_DATABLOCKEND, the previous code would just react to
any blockend, which was buggy
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
isuue_rw_rq() again with a new request. This new request is prepared,
in isuue_rw_rq
Break out code from mmc_blk_issue_rw_rq to create a
block request prepare function. This doesn't change
any functionallity.
Signed-off-by: Per Forlin
---
drivers/mmc/card/block.c | 173 +-
1 files changed, 94 insertions(+), 79 deletions(-)
diff --git
Add an additional mmc queue request instance to make way for
double buffering. 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 |4 +++-
2
Move the mmc block request to the mmc queue struct in
order to make way for processing two brqs simultanously.
Signed-off-by: Per Forlin
---
drivers/mmc/card/block.c | 68 +-
drivers/mmc/card/queue.h |9 +-
2 files changed, 39 insertions(+),
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 and bounce buffers, and update functions depending on
the mmc queue struct. This lies the ground f
Add support to prepare one MMC request while another is active on
the host. This is done by making the issue_rw_rq() asynchronous.
The increase in throughput is proportional to the time it takes to
prepare a request and how fast the memory is. The faster the MMC/SD is
the more significant the prepa
It seems all the tabs were turned into spaces.
On Wed, Jan 12, 2011 at 11:09:56AM +0100, Sascha Hauer wrote:
> This switches the mxcmmc driver to use the dmaengine API. Unlike
> the old one this one is always present in the tree, even if no DMA
> is implement, hence we can remove all the #ifdefs i
Hi Chris,
On Mon, Jan 10, 2011 at 05:47:38, Chris Ball wrote:
> Hi Sekhar,
>
> On Mon, Jan 03, 2011 at 12:43:27PM +0530, Sekhar Nori wrote:
> > From: Alagu Sankar
> >
> > This patch adds support for handling SDIO interrupt on
> > DaVinci MMC/SD controller.
> >
> > The patch has been tested on
On Wed, Jan 12, 2011 at 10:26:32AM +, Russell King - ARM Linux wrote:
> On Wed, Jan 12, 2011 at 11:09:56AM +0100, Sascha Hauer wrote:
> > + host->dma_nents = dma_map_sg(mmc_dev(host->mmc), data->sg,
> > +data->sg_len, host->dma_dir);
>
> As recently discussed
On Wed, Jan 12, 2011 at 8:25 PM, Shawn Guo wrote:
> It seems all the tabs were turned into spaces.
>
My problem. Sorry for the noise.
> On Wed, Jan 12, 2011 at 11:09:56AM +0100, Sascha Hauer wrote:
>> This switches the mxcmmc driver to use the dmaengine API. Unlike
>> the old one this one is alw
On Wed, Jan 12, 2011 at 11:09:56AM +0100, Sascha Hauer wrote:
> + host->dma_nents = dma_map_sg(mmc_dev(host->mmc), data->sg,
> + data->sg_len, host->dma_dir);
As recently discussed, you don't need to save dma_nents - the value to
be passed to dma_unmap_sg() is
This switches the mxcmmc driver to use the dmaengine API. Unlike
the old one this one is always present in the tree, even if no DMA
is implement, hence we can remove all the #ifdefs in from the driver.
The driver automatically switches to PIO mode if no DMA support or no
suitable channel is availab
This saves us several ifdefs and also adds mxcmmc DMA support for the
i.MX31 processor.
Sascha
Sascha Hauer (1):
mxcmmc: use dmaengine API
drivers/mmc/host/mxcmmc.c | 172 +
1 files changed, 97 insertions(+), 75 deletions(-)
--
To unsubscribe
20 matches
Mail list logo
