From: Lars-Peter Clausen <lars@metafoo.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Stephen Warren <swarren@nvidia.com>,
"broonie@opensource.wolfsonmicro.com"
<broonie@opensource.wolfsonmicro.com>,
"clemens@ladisch.de" <clemens@ladisch.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Laxman Dewangan <ldewangan@nvidia.com>, "lrg@ti.com" <lrg@ti.com>
Subject: Re: [PATCH 0/3] ASoC: Move pcm writecombine dma buffer allocation to core
Date: Fri, 29 Jun 2012 18:32:35 +0200 [thread overview]
Message-ID: <4FEDD8A3.8000608@metafoo.de> (raw)
In-Reply-To: <s5h1ukyw0pb.wl%tiwai@suse.de>
On 06/29/2012 06:18 PM, Takashi Iwai wrote:
> At Fri, 29 Jun 2012 18:06:52 +0200,
> Lars-Peter Clausen wrote:
>>
>> On 06/29/2012 05:04 PM, Laxman Dewangan wrote:
>>> [...]
>>>
>>>
>>>> +/* allocate the coherent DMA pages */
>>>> +static void *snd_malloc_dev_pages(struct device *dev, size_t size,
>>>> dma_addr_t *dma)
>>>> +{
>>>> + return __snd_malloc_dev_pages(dev, size, dma, dma_alloc_coherent);
>>>
>>> This does not get compiled in ARM because dma_alloc_coherant is macro
>>> defined as
>>>
>>> #define dma_alloc_coherent(d, s, h, f) dma_alloc_attrs(d, s, h, f, NULL)
>>>
>>> static inline void *dma_alloc_attrs(struct device *dev, size_t size,
>>> dma_addr_t *dma_handle, gfp_t flag,
>>> struct dma_attrs *attrs)
>>>
>>>
>>> I fixed this by
>>> static void *_dma_alloc_coherent(struct device *dev, size_t size,
>>> dma_addr_t *dma_handle, gfp_t flag)
>>> {
>>> return dma_alloc_coherent(dev, size, dma_handle, flag);
>>> }
>>>
>>> /* allocate the coherent DMA pages */
>>> static void *snd_malloc_dev_pages(struct device *dev, size_t size,
>>> dma_addr_t *dma)
>>> {
>>> return _snd_malloc_dev_pages(dev, size, dma, _dma_alloc_coherent);
>>> }
>>
>> I think all dma_alloc_* functions use dma_alloc_attrs internally these days.
>> I think it might be a better idea just to use dma_alloc_attrs in
>> __snd_malloc_dev_pages and just pass a dma_attrs struct instead of a function.
>>
>> Something like:
>>
>> static void *__snd_malloc_dev_pages(struct device *dev, size_t size,
>> dma_addr_t *dma, struct dma_attrs *attrs)
>> {
>> ....
>> res = dma_alloc_attrs(dev, PAGE_SIZE << pg, dma, gfp_flags, attrs);
>> ....
>> }
>>
>>
>> static void *snd_malloc_dev_pages(struct device *dev, size_t size,
>> dma_addr_t *dma)
>> {
>> return __snd_malloc_dev_pages(dev, size, dma, NULL);
>> }
>>
>> static void *snd_malloc_dev_wc_pages(struct device *dev, size_t size,
>> dma_addr_t *dma)
>> {
>> DEFINE_DMA_ATTRS(attrs);
>> dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
>>
>> return __snd_malloc_dev_pages(dev, size, dma, &attrs);
>> }
>>
>> Same applies for freeing the memory again.
>
> Yes, that'd be cleaner.
> But I prefer the code still workable on 3.5-base kernel, which makes
> easier to test and merge for 3.6, at first.
Actually that part is already in 3.5. But I've just had a closer look and it
looks as if even for 3.6 not all archs have been converted to
dma_alloc_attrs yet :/
WARNING: multiple messages have this Message-ID (diff)
From: Lars-Peter Clausen <lars@metafoo.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: Laxman Dewangan <ldewangan@nvidia.com>, "lrg@ti.com" <lrg@ti.com>,
"broonie@opensource.wolfsonmicro.com"
<broonie@opensource.wolfsonmicro.com>,
Stephen Warren <swarren@nvidia.com>,
"perex@perex.cz" <perex@perex.cz>,
"clemens@ladisch.de" <clemens@ladisch.de>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] ASoC: Move pcm writecombine dma buffer allocation to core
Date: Fri, 29 Jun 2012 18:32:35 +0200 [thread overview]
Message-ID: <4FEDD8A3.8000608@metafoo.de> (raw)
In-Reply-To: <s5h1ukyw0pb.wl%tiwai@suse.de>
On 06/29/2012 06:18 PM, Takashi Iwai wrote:
> At Fri, 29 Jun 2012 18:06:52 +0200,
> Lars-Peter Clausen wrote:
>>
>> On 06/29/2012 05:04 PM, Laxman Dewangan wrote:
>>> [...]
>>>
>>>
>>>> +/* allocate the coherent DMA pages */
>>>> +static void *snd_malloc_dev_pages(struct device *dev, size_t size,
>>>> dma_addr_t *dma)
>>>> +{
>>>> + return __snd_malloc_dev_pages(dev, size, dma, dma_alloc_coherent);
>>>
>>> This does not get compiled in ARM because dma_alloc_coherant is macro
>>> defined as
>>>
>>> #define dma_alloc_coherent(d, s, h, f) dma_alloc_attrs(d, s, h, f, NULL)
>>>
>>> static inline void *dma_alloc_attrs(struct device *dev, size_t size,
>>> dma_addr_t *dma_handle, gfp_t flag,
>>> struct dma_attrs *attrs)
>>>
>>>
>>> I fixed this by
>>> static void *_dma_alloc_coherent(struct device *dev, size_t size,
>>> dma_addr_t *dma_handle, gfp_t flag)
>>> {
>>> return dma_alloc_coherent(dev, size, dma_handle, flag);
>>> }
>>>
>>> /* allocate the coherent DMA pages */
>>> static void *snd_malloc_dev_pages(struct device *dev, size_t size,
>>> dma_addr_t *dma)
>>> {
>>> return _snd_malloc_dev_pages(dev, size, dma, _dma_alloc_coherent);
>>> }
>>
>> I think all dma_alloc_* functions use dma_alloc_attrs internally these days.
>> I think it might be a better idea just to use dma_alloc_attrs in
>> __snd_malloc_dev_pages and just pass a dma_attrs struct instead of a function.
>>
>> Something like:
>>
>> static void *__snd_malloc_dev_pages(struct device *dev, size_t size,
>> dma_addr_t *dma, struct dma_attrs *attrs)
>> {
>> ....
>> res = dma_alloc_attrs(dev, PAGE_SIZE << pg, dma, gfp_flags, attrs);
>> ....
>> }
>>
>>
>> static void *snd_malloc_dev_pages(struct device *dev, size_t size,
>> dma_addr_t *dma)
>> {
>> return __snd_malloc_dev_pages(dev, size, dma, NULL);
>> }
>>
>> static void *snd_malloc_dev_wc_pages(struct device *dev, size_t size,
>> dma_addr_t *dma)
>> {
>> DEFINE_DMA_ATTRS(attrs);
>> dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
>>
>> return __snd_malloc_dev_pages(dev, size, dma, &attrs);
>> }
>>
>> Same applies for freeing the memory again.
>
> Yes, that'd be cleaner.
> But I prefer the code still workable on 3.5-base kernel, which makes
> easier to test and merge for 3.6, at first.
Actually that part is already in 3.5. But I've just had a closer look and it
looks as if even for 3.6 not all archs have been converted to
dma_alloc_attrs yet :/
next prev parent reply other threads:[~2012-06-29 16:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-29 10:23 [PATCH 0/3] ASoC: Move pcm writecombine dma buffer allocation to core Laxman Dewangan
2012-06-29 10:23 ` Laxman Dewangan
2012-06-29 10:23 ` [PATCH 1/3] ALSA: pcm: add apis for writecombine dma buffer allocation Laxman Dewangan
2012-06-29 10:23 ` Laxman Dewangan
2012-06-29 10:23 ` [PATCH 2/3] ASoC: add apis for creating/free pcm dma buffer Laxman Dewangan
2012-06-29 10:23 ` Laxman Dewangan
2012-06-29 10:23 ` [PATCH 3/3] ASoC: tegra: use core/pcm library for pcm buffer allocation Laxman Dewangan
2012-06-29 10:23 ` Laxman Dewangan
2012-06-29 12:13 ` [PATCH 0/3] ASoC: Move pcm writecombine dma buffer allocation to core Takashi Iwai
2012-06-29 12:13 ` Takashi Iwai
2012-06-29 15:04 ` Laxman Dewangan
2012-06-29 15:22 ` Takashi Iwai
2012-06-29 15:22 ` Takashi Iwai
2012-06-29 15:49 ` Laxman Dewangan
2012-06-29 16:06 ` Lars-Peter Clausen
2012-06-29 16:06 ` Lars-Peter Clausen
2012-06-29 16:18 ` Takashi Iwai
2012-06-29 16:32 ` Lars-Peter Clausen [this message]
2012-06-29 16:32 ` Lars-Peter Clausen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FEDD8A3.8000608@metafoo.de \
--to=lars@metafoo.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=clemens@ladisch.de \
--cc=ldewangan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=swarren@nvidia.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.