[PATCH v2 0/4] dma-mapping: Define dma_{alloc, free}_attrs() for all archs

[PATCH v2 0/4] dma-mapping: Define dma_{alloc, free}_attrs() for all archs

[Damian Hobson-Garcia]

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

[PATCH v2 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

[Damian Hobson-Garcia]

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

[PATCH v2 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

[Catalin Marinas]

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

[PATCH v2 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

[Damian Hobson-Garcia]

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

[PATCH v2 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

[Catalin Marinas]

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

[PATCH v2 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

[Damian Hobson-Garcia]

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

[PATCH v2 0/4] dma-mapping: Define dma_{alloc,free}_attrs() for all archs

[Helge Deller]

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