Most architectures that define CONFIG_HAVE_DMA=y, have implementations for
both dma_alloc_attrs() and dma_free_attrs(). All achitectures that do
not define CONFIG_HAVE_DMA also have both of these definitions provided by
dma-mapping-broken.h.
Provide a default definition for the archs that define CONFIG_HAVE_DMA=y,
but have no implementation for dma_{alloc,free}_attrs().
As I don't have hardware for any of these systems, the patches are only
compile-tested where I could (arm64, s390) and untested for the archs
where I couldn't find a readily available prebuilt cross-compiler (c6x, parisc).
Changes from v1
---------------
arm64, s390:
* Since these archs are using dma_ops, pass appropirate value for attrs to
dma_ops->alloc().
* Indicate that these patches are compile teseted only (I don't have hardware)
c6x, parisc:
* Indicate that these patches are untested (I don't have cross compilers)
Cheers,
Damian
Damian Hobson-Garcia (4):
arm64: Provide default implementation for dma_{alloc,free}_attrs
c6x: Provide default implementation for dma_{alloc,free}_attrs
parisc: Provide default implementation for dma_{alloc,free}_attrs
s390: Provide default implementation for dma_{alloc,free}_attrs
arch/arm64/include/asm/dma-mapping.h | 17 +++++++++++------
arch/c6x/include/asm/dma-mapping.h | 3 +++
arch/parisc/include/asm/dma-mapping.h | 3 +++
arch/s390/include/asm/dma-mapping.h | 17 +++++++++++------
4 files changed, 28 insertions(+), 12 deletions(-)
--
1.7.5.4
Hello,
On 2013/04/30 12:01, Damian Hobson-Garcia wrote:
> Most architectures that define CONFIG_HAVE_DMA=y, have implementations for
> both dma_alloc_attrs() and dma_free_attrs(). All achitectures that do
> not define CONFIG_HAVE_DMA also have both of these definitions provided by
> dma-mapping-broken.h.
>
> Provide a default definition for the archs that define CONFIG_HAVE_DMA=y,
> but have no implementation for dma_{alloc,free}_attrs().
>
> As I don't have hardware for any of these systems, the patches are only
> compile-tested where I could (arm64, s390) and untested for the archs
> where I couldn't find a readily available prebuilt cross-compiler (c6x, parisc).
>
> arch/arm64/include/asm/dma-mapping.h | 17 +++++++++++------
> arch/c6x/include/asm/dma-mapping.h | 3 +++
> arch/parisc/include/asm/dma-mapping.h | 3 +++
> arch/s390/include/asm/dma-mapping.h | 17 +++++++++++------
> 4 files changed, 28 insertions(+), 12 deletions(-)
>
Since this series spans several architectures, what would be the best
way to have this patch series merged?
Should I resubmit each patch to the mailing list for each architecture
separately?
Thank you,
Damian
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
On Wed, May 22, 2013 at 03:37:17AM +0100, Damian Hobson-Garcia wrote:
> Hello,
> On 2013/04/30 12:01, Damian Hobson-Garcia wrote:
> > Most architectures that define CONFIG_HAVE_DMA=y, have implementations for
> > both dma_alloc_attrs() and dma_free_attrs(). All achitectures that do
> > not define CONFIG_HAVE_DMA also have both of these definitions provided by
> > dma-mapping-broken.h.
BTW, shouldn't this be called CONFIG_HAVE_DMA_ATTRS?
> > Provide a default definition for the archs that define CONFIG_HAVE_DMA=y,
> > but have no implementation for dma_{alloc,free}_attrs().
> >
> > As I don't have hardware for any of these systems, the patches are only
> > compile-tested where I could (arm64, s390) and untested for the archs
> > where I couldn't find a readily available prebuilt cross-compiler (c6x, parisc).
>
> > arch/arm64/include/asm/dma-mapping.h | 17 +++++++++++------
> > arch/c6x/include/asm/dma-mapping.h | 3 +++
> > arch/parisc/include/asm/dma-mapping.h | 3 +++
> > arch/s390/include/asm/dma-mapping.h | 17 +++++++++++------
> > 4 files changed, 28 insertions(+), 12 deletions(-)
> >
>
> Since this series spans several architectures, what would be the best
> way to have this patch series merged?
> Should I resubmit each patch to the mailing list for each architecture
> separately?
I'm happy to take the arm64 patch.
Thanks.
--
Catalin
On 05/22/2013 04:37 AM, Damian Hobson-Garcia wrote:
> Hello,
> On 2013/04/30 12:01, Damian Hobson-Garcia wrote:
>> Most architectures that define CONFIG_HAVE_DMA=y, have implementations for
>> both dma_alloc_attrs() and dma_free_attrs(). All achitectures that do
>> not define CONFIG_HAVE_DMA also have both of these definitions provided by
>> dma-mapping-broken.h.
>>
>> Provide a default definition for the archs that define CONFIG_HAVE_DMA=y,
>> but have no implementation for dma_{alloc,free}_attrs().
>>
>> As I don't have hardware for any of these systems, the patches are only
>> compile-tested where I could (arm64, s390) and untested for the archs
>> where I couldn't find a readily available prebuilt cross-compiler (c6x, parisc).
>>
>
>
>> arch/arm64/include/asm/dma-mapping.h | 17 +++++++++++------
>> arch/c6x/include/asm/dma-mapping.h | 3 +++
>> arch/parisc/include/asm/dma-mapping.h | 3 +++
>> arch/s390/include/asm/dma-mapping.h | 17 +++++++++++------
>> 4 files changed, 28 insertions(+), 12 deletions(-)
>>
>
> Since this series spans several architectures, what would be the best
> way to have this patch series merged?
> Should I resubmit each patch to the mailing list for each architecture
> separately?
I already pushed the parisc change upstream.
See commit 7f64fb41aad9a8504dd76e81b2391eae64e1498a
Helge
Hi Catalin,
On 2013/05/22 18:47, Catalin Marinas wrote:
> On Wed, May 22, 2013 at 03:37:17AM +0100, Damian Hobson-Garcia wrote:
>> Hello,
>> On 2013/04/30 12:01, Damian Hobson-Garcia wrote:
>>> Most architectures that define CONFIG_HAVE_DMA=y, have implementations for
>>> both dma_alloc_attrs() and dma_free_attrs(). All achitectures that do
>>> not define CONFIG_HAVE_DMA also have both of these definitions provided by
>>> dma-mapping-broken.h.
>
> BTW, shouldn't this be called CONFIG_HAVE_DMA_ATTRS?
CONFIG_HAVE_DMA_ATTRS is currently used to enable the functions to
set/get the DMA attribute values. Poking through the headers, it looks
like the struct dma_attrs is defined regardless of the
CONFIG_HAVE_DMA_ATTRS setting, so in that respect
we always seem to "have" DMA attributes (if we have DMA), but they may
not always be meaningful (ie. set to some value).
>
>>> Provide a default definition for the archs that define CONFIG_HAVE_DMA=y,
>>> but have no implementation for dma_{alloc,free}_attrs().
>>>
>>> As I don't have hardware for any of these systems, the patches are only
>>> compile-tested where I could (arm64, s390) and untested for the archs
>>> where I couldn't find a readily available prebuilt cross-compiler (c6x, parisc).
>>
>>> arch/arm64/include/asm/dma-mapping.h | 17 +++++++++++------
>>> arch/c6x/include/asm/dma-mapping.h | 3 +++
>>> arch/parisc/include/asm/dma-mapping.h | 3 +++
>>> arch/s390/include/asm/dma-mapping.h | 17 +++++++++++------
>>> 4 files changed, 28 insertions(+), 12 deletions(-)
>>>
>>
>> Since this series spans several architectures, what would be the best
>> way to have this patch series merged?
>> Should I resubmit each patch to the mailing list for each architecture
>> separately?
>
> I'm happy to take the arm64 patch.
Very much appreciated.
>
> Thanks.
>
Damian
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
On Thu, May 23, 2013 at 03:47:13AM +0100, Damian Hobson-Garcia wrote:
> Hi Catalin,
> On 2013/05/22 18:47, Catalin Marinas wrote:
> > On Wed, May 22, 2013 at 03:37:17AM +0100, Damian Hobson-Garcia wrote:
> >> Hello,
> >> On 2013/04/30 12:01, Damian Hobson-Garcia wrote:
> >>> Most architectures that define CONFIG_HAVE_DMA=y, have implementations for
> >>> both dma_alloc_attrs() and dma_free_attrs(). All achitectures that do
> >>> not define CONFIG_HAVE_DMA also have both of these definitions provided by
> >>> dma-mapping-broken.h.
> >
> > BTW, shouldn't this be called CONFIG_HAVE_DMA_ATTRS?
>
> CONFIG_HAVE_DMA_ATTRS is currently used to enable the functions to
> set/get the DMA attribute values. Poking through the headers, it looks
> like the struct dma_attrs is defined regardless of the
> CONFIG_HAVE_DMA_ATTRS setting, so in that respect
> we always seem to "have" DMA attributes (if we have DMA), but they may
> not always be meaningful (ie. set to some value).
My point was about the commit log - grep'ing the kernel for
CONFIG_HAVE_DMA did not return anything.
--
Catalin
On 2013/05/23 18:47, Catalin Marinas wrote:
> On Thu, May 23, 2013 at 03:47:13AM +0100, Damian Hobson-Garcia wrote:
>> Hi Catalin,
>> On 2013/05/22 18:47, Catalin Marinas wrote:
>>> On Wed, May 22, 2013 at 03:37:17AM +0100, Damian Hobson-Garcia wrote:
>>>> Hello,
>>>> On 2013/04/30 12:01, Damian Hobson-Garcia wrote:
>>>>> Most architectures that define CONFIG_HAVE_DMA=y, have implementations for
>>>>> both dma_alloc_attrs() and dma_free_attrs(). All achitectures that do
>>>>> not define CONFIG_HAVE_DMA also have both of these definitions provided by
>>>>> dma-mapping-broken.h.
>>>
>>> BTW, shouldn't this be called CONFIG_HAVE_DMA_ATTRS?
>>
>> CONFIG_HAVE_DMA_ATTRS is currently used to enable the functions to
>> set/get the DMA attribute values. Poking through the headers, it looks
>> like the struct dma_attrs is defined regardless of the
>> CONFIG_HAVE_DMA_ATTRS setting, so in that respect
>> we always seem to "have" DMA attributes (if we have DMA), but they may
>> not always be meaningful (ie. set to some value).
>
> My point was about the commit log - grep'ing the kernel for
> CONFIG_HAVE_DMA did not return anything.
>
Oh yes, my mistake. It should be CONFIG_HAS_DMA instead of
CONFIG_HAVE_DMA. I'll update it.
Damian
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp