linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the dma-mapping tree with Linus' tree
@ 2019-06-30 22:42 Stephen Rothwell
  2019-07-09  0:16 ` Stephen Rothwell
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen Rothwell @ 2019-06-30 22:42 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Dan Williams,
	Andrew Morton, Fredrik Noring

[-- Attachment #1: Type: text/plain, Size: 3619 bytes --]

Hi all,

Today's linux-next merge of the dma-mapping tree got a conflict in:

  include/linux/genalloc.h

between commit:

  795ee30648c7 ("lib/genalloc: introduce chunk owners")

from Linus' tree and commit:

  cf394fc5f715 ("lib/genalloc.c: Add algorithm, align and zeroed family of DMA allocators")

from the dma-mapping tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/genalloc.h
index 205f62b8d291,ed641337df87..000000000000
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@@ -122,47 -116,21 +122,56 @@@ static inline int gen_pool_add(struct g
  	return gen_pool_add_virt(pool, addr, -1, size, nid);
  }
  extern void gen_pool_destroy(struct gen_pool *);
 -extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
 -extern unsigned long gen_pool_alloc_algo(struct gen_pool *, size_t,
 -		genpool_algo_t algo, void *data);
 +unsigned long gen_pool_alloc_algo_owner(struct gen_pool *pool, size_t size,
 +		genpool_algo_t algo, void *data, void **owner);
 +
 +static inline unsigned long gen_pool_alloc_owner(struct gen_pool *pool,
 +		size_t size, void **owner)
 +{
 +	return gen_pool_alloc_algo_owner(pool, size, pool->algo, pool->data,
 +			owner);
 +}
 +
 +static inline unsigned long gen_pool_alloc_algo(struct gen_pool *pool,
 +		size_t size, genpool_algo_t algo, void *data)
 +{
 +	return gen_pool_alloc_algo_owner(pool, size, algo, data, NULL);
 +}
 +
 +/**
 + * gen_pool_alloc - allocate special memory from the pool
 + * @pool: pool to allocate from
 + * @size: number of bytes to allocate from the pool
 + *
 + * Allocate the requested number of bytes from the specified pool.
 + * Uses the pool allocation function (with first-fit algorithm by default).
 + * Can not be used in NMI handler on architectures without
 + * NMI-safe cmpxchg implementation.
 + */
 +static inline unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size)
 +{
 +	return gen_pool_alloc_algo(pool, size, pool->algo, pool->data);
 +}
 +
  extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
  		dma_addr_t *dma);
+ extern void *gen_pool_dma_alloc_algo(struct gen_pool *pool, size_t size,
+ 		dma_addr_t *dma, genpool_algo_t algo, void *data);
+ extern void *gen_pool_dma_alloc_align(struct gen_pool *pool, size_t size,
+ 		dma_addr_t *dma, int align);
+ extern void *gen_pool_dma_zalloc(struct gen_pool *pool, size_t size, dma_addr_t *dma);
+ extern void *gen_pool_dma_zalloc_algo(struct gen_pool *pool, size_t size,
+ 		dma_addr_t *dma, genpool_algo_t algo, void *data);
+ extern void *gen_pool_dma_zalloc_align(struct gen_pool *pool, size_t size,
+ 		dma_addr_t *dma, int align);
 -extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
 +extern void gen_pool_free_owner(struct gen_pool *pool, unsigned long addr,
 +		size_t size, void **owner);
 +static inline void gen_pool_free(struct gen_pool *pool, unsigned long addr,
 +                size_t size)
 +{
 +	gen_pool_free_owner(pool, addr, size, NULL);
 +}
 +
  extern void gen_pool_for_each_chunk(struct gen_pool *,
  	void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
  extern size_t gen_pool_avail(struct gen_pool *);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: linux-next: manual merge of the dma-mapping tree with Linus' tree
  2019-06-30 22:42 linux-next: manual merge of the dma-mapping tree with Linus' tree Stephen Rothwell
@ 2019-07-09  0:16 ` Stephen Rothwell
  0 siblings, 0 replies; 6+ messages in thread
From: Stephen Rothwell @ 2019-07-09  0:16 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Dan Williams,
	Andrew Morton, Fredrik Noring

[-- Attachment #1: Type: text/plain, Size: 4049 bytes --]

Hi all,

On Mon, 1 Jul 2019 08:42:13 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the dma-mapping tree got a conflict in:
> 
>   include/linux/genalloc.h
> 
> between commit:
> 
>   795ee30648c7 ("lib/genalloc: introduce chunk owners")
> 
> from Linus' tree and commit:
> 
>   cf394fc5f715 ("lib/genalloc.c: Add algorithm, align and zeroed family of DMA allocators")
> 
> from the dma-mapping tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc include/linux/genalloc.h
> index 205f62b8d291,ed641337df87..000000000000
> --- a/include/linux/genalloc.h
> +++ b/include/linux/genalloc.h
> @@@ -122,47 -116,21 +122,56 @@@ static inline int gen_pool_add(struct g
>   	return gen_pool_add_virt(pool, addr, -1, size, nid);
>   }
>   extern void gen_pool_destroy(struct gen_pool *);
>  -extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
>  -extern unsigned long gen_pool_alloc_algo(struct gen_pool *, size_t,
>  -		genpool_algo_t algo, void *data);
>  +unsigned long gen_pool_alloc_algo_owner(struct gen_pool *pool, size_t size,
>  +		genpool_algo_t algo, void *data, void **owner);
>  +
>  +static inline unsigned long gen_pool_alloc_owner(struct gen_pool *pool,
>  +		size_t size, void **owner)
>  +{
>  +	return gen_pool_alloc_algo_owner(pool, size, pool->algo, pool->data,
>  +			owner);
>  +}
>  +
>  +static inline unsigned long gen_pool_alloc_algo(struct gen_pool *pool,
>  +		size_t size, genpool_algo_t algo, void *data)
>  +{
>  +	return gen_pool_alloc_algo_owner(pool, size, algo, data, NULL);
>  +}
>  +
>  +/**
>  + * gen_pool_alloc - allocate special memory from the pool
>  + * @pool: pool to allocate from
>  + * @size: number of bytes to allocate from the pool
>  + *
>  + * Allocate the requested number of bytes from the specified pool.
>  + * Uses the pool allocation function (with first-fit algorithm by default).
>  + * Can not be used in NMI handler on architectures without
>  + * NMI-safe cmpxchg implementation.
>  + */
>  +static inline unsigned long gen_pool_alloc(struct gen_pool *pool, size_t size)
>  +{
>  +	return gen_pool_alloc_algo(pool, size, pool->algo, pool->data);
>  +}
>  +
>   extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
>   		dma_addr_t *dma);
> + extern void *gen_pool_dma_alloc_algo(struct gen_pool *pool, size_t size,
> + 		dma_addr_t *dma, genpool_algo_t algo, void *data);
> + extern void *gen_pool_dma_alloc_align(struct gen_pool *pool, size_t size,
> + 		dma_addr_t *dma, int align);
> + extern void *gen_pool_dma_zalloc(struct gen_pool *pool, size_t size, dma_addr_t *dma);
> + extern void *gen_pool_dma_zalloc_algo(struct gen_pool *pool, size_t size,
> + 		dma_addr_t *dma, genpool_algo_t algo, void *data);
> + extern void *gen_pool_dma_zalloc_align(struct gen_pool *pool, size_t size,
> + 		dma_addr_t *dma, int align);
>  -extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
>  +extern void gen_pool_free_owner(struct gen_pool *pool, unsigned long addr,
>  +		size_t size, void **owner);
>  +static inline void gen_pool_free(struct gen_pool *pool, unsigned long addr,
>  +                size_t size)
>  +{
>  +	gen_pool_free_owner(pool, addr, size, NULL);
>  +}
>  +
>   extern void gen_pool_for_each_chunk(struct gen_pool *,
>   	void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
>   extern size_t gen_pool_avail(struct gen_pool *);

I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: linux-next: manual merge of the dma-mapping tree with Linus' tree
  2022-11-21 23:06 Stephen Rothwell
@ 2022-11-22  6:11 ` Christoph Hellwig
  0 siblings, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2022-11-22  6:11 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christoph Hellwig, Linux Kernel Mailing List,
	Linux Next Mailing List, Takashi Iwai

On Tue, Nov 22, 2022 at 10:06:11AM +1100, Stephen Rothwell wrote:
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks Stephen,

the fix look good.  The being said the code in the sound tree here
is questionable to start with:

>   #ifdef CONFIG_SND_DMA_SGBUF
>  +	if (!sgt && !get_dma_ops(dmab->dev.dev)) {
>   		if (dmab->dev.type == SNDRV_DMA_TYPE_DEV_WC_SG)
>   			dmab->dev.type = SNDRV_DMA_TYPE_DEV_WC_SG_FALLBACK;
>   		else

driver have no busuness calling get_dma_ops and poking into the
dma-mapping internals.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* linux-next: manual merge of the dma-mapping tree with Linus' tree
@ 2022-11-21 23:06 Stephen Rothwell
  2022-11-22  6:11 ` Christoph Hellwig
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen Rothwell @ 2022-11-21 23:06 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Takashi Iwai

[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

Hi all,

Today's linux-next merge of the dma-mapping tree got a conflict in:

  sound/core/memalloc.c

between commits:

  9736a325137b ("ALSA: memalloc: Don't fall back for SG-buffer with IOMMU")
  9d8e536d36e7 ("ALSA: memalloc: Try dma_alloc_noncontiguous() at first")

from Linus' tree and commit:

  3306877aff07 ("ALSA: memalloc: don't pass bogus GFP_ flags to dma_alloc_*")

from the dma-mapping tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc sound/core/memalloc.c
index ba095558b6d1,fe03cf796e8b..000000000000
--- a/sound/core/memalloc.c
+++ b/sound/core/memalloc.c
@@@ -543,9 -541,9 +542,9 @@@ static void *snd_dma_noncontig_alloc(st
  	void *p;
  
  	sgt = dma_alloc_noncontiguous(dmab->dev.dev, size, dmab->dev.dir,
- 				      DEFAULT_GFP, 0);
+ 				      DEFAULT_GFP | __GFP_COMP, 0);
 -	if (!sgt) {
  #ifdef CONFIG_SND_DMA_SGBUF
 +	if (!sgt && !get_dma_ops(dmab->dev.dev)) {
  		if (dmab->dev.type == SNDRV_DMA_TYPE_DEV_WC_SG)
  			dmab->dev.type = SNDRV_DMA_TYPE_DEV_WC_SG_FALLBACK;
  		else

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* linux-next: manual merge of the dma-mapping tree with Linus' tree
@ 2019-03-05 21:36 Stephen Rothwell
  0 siblings, 0 replies; 6+ messages in thread
From: Stephen Rothwell @ 2019-03-05 21:36 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Borislav Petkov

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

Hi all,

Today's linux-next merge of the dma-mapping tree got a conflict in:

  arch/x86/Kconfig

between commit:

  eac616557050 ("x86: Deprecate a.out support")

from Linus' tree and commit:

  ff4c25f26a71 ("dma-mapping: improve selection of dma_declare_coherent availability")

from the dma-mapping tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/Kconfig
index ade12ec4224b,0e33dede053e..000000000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -14,7 -14,7 +14,6 @@@ config X86_3
  	select ARCH_WANT_IPC_PARSE_VERSION
  	select CLKSRC_I8253
  	select CLONE_BACKWARDS
- 	select HAVE_GENERIC_DMA_COHERENT
 -	select HAVE_AOUT
  	select MODULES_USE_ELF_REL
  	select OLD_SIGACTION
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* linux-next: manual merge of the dma-mapping tree with Linus' tree
@ 2018-05-29 23:20 Stephen Rothwell
  0 siblings, 0 replies; 6+ messages in thread
From: Stephen Rothwell @ 2018-05-29 23:20 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Greentime Hu

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

Hi Christoph,

Today's linux-next merge of the dma-mapping tree got a conflict in:

  arch/nds32/Kconfig

between commit:

  aeaa7af744fa ("nds32: lib: To use generic lib instead of libgcc to prevent the symbol undefined issue.")

from Linus' tree and commit:

  267d2e18a281 ("nds32: use generic dma_noncoherent_ops")

from the dma-mapping tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/nds32/Kconfig
index b7404f2dcf5b,67d0ac0a989c..000000000000
--- a/arch/nds32/Kconfig
+++ b/arch/nds32/Kconfig
@@@ -9,12 -11,7 +11,13 @@@ config NDS3
  	select CLKSRC_MMIO
  	select CLONE_BACKWARDS
  	select COMMON_CLK
+ 	select DMA_NONCOHERENT_OPS
 +	select GENERIC_ASHLDI3
 +	select GENERIC_ASHRDI3
 +	select GENERIC_LSHRDI3
 +	select GENERIC_CMPDI2
 +	select GENERIC_MULDI3
 +	select GENERIC_UCMPDI2
  	select GENERIC_ATOMIC64
  	select GENERIC_CPU_DEVICES
  	select GENERIC_CLOCKEVENTS

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-11-22  6:12 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-30 22:42 linux-next: manual merge of the dma-mapping tree with Linus' tree Stephen Rothwell
2019-07-09  0:16 ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2022-11-21 23:06 Stephen Rothwell
2022-11-22  6:11 ` Christoph Hellwig
2019-03-05 21:36 Stephen Rothwell
2018-05-29 23:20 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).