On Mon, Mar 14, 2011 at 5:01 PM, Guennadi Liakhovetski
<g.liakhovetski@xxxxxx> wrote:
> On Sun, 13 Mar 2011, Magnus Damm wrote:
>> On Fri, Mar 11, 2011 at 4:52 PM, Guennadi Liakhovetski
>> <g.liakhovetski@xxxxxx> wrote:
>> > On sh-mobile platforms the SDHI driver was using the tmio_mmc SD/SDIO
>> > MFD cell driver. Now that the tmio_mmc driver has been split into a
>> > core and a separate MFD glue, we can support SDHI natively without the
>> > need to emulate an MFD controller. This also allows to support systems
>> > with an on-SoC SDHI controller and a separate MFD with a TMIO core.
>> >
>> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@xxxxxx>
>> > ---
>>
>> Nice, I believe this is the right direction..
>>
>> > --- a/drivers/mmc/host/tmio_mmc.h
>> > +++ b/drivers/mmc/host/tmio_mmc.h
>> > @@ -92,7 +92,7 @@ struct tmio_mmc_host {
>> > struct tasklet_struct dma_complete;
>> > struct tasklet_struct dma_issue;
>> > struct scatterlist bounce_sg;
>> > -#ifdef CONFIG_TMIO_MMC_DMA
>> > +#if defined(CONFIG_MMC_SDHI) || defined(CONFIG_MMC_SDHI_MODULE)
>> > u8 bounce_buf[PAGE_CACHE_SIZE] __attribute__((aligned(TMIO_MAX_ALIGN)));
>> > #else
>> > u8 bounce_buf[1]; /* A dummy in no-DMA case */
>>
>> ... but it would be nice if all this #ifdeffery could be avoided somehow.
>>
>> Is it possible to use devres to allocate the bounce buffer dynamically
>> in the dma portion of the code?
>
> Well, this #ifdef has been there before, it's not new. But sure, we could
> get rid of it. Basically, what you're suggesting, is to allocate that
> bounce buffer dynamically - whether or not using devres. Just calling
> __get_free_page() in tmio_mmc_request_dma() and __free_pages() in
> tmio_mmc_release_dma() should work without any memory-leaking too. Would
> this be ok?
Yes, tmio_mmc_request_dma() and tmio_mmc_free_dma() happen very
infrequently so that seems like a very good location for dynamic
allocation / free of the bounce buffer. Thanks!
/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
