All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Becky Bruce <bgill@freescale.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC] POWERPC: Merge 32 and 64-bit dma code
Date: Fri, 23 May 2008 11:51:19 +0200	[thread overview]
Message-ID: <20080523095119.GA15722@lst.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0804301815020.12768@monty.am.freescale.net>

On Wed, Apr 30, 2008 at 06:36:43PM -0500, Becky Bruce wrote:
> In addition, the dma_map/unmap_page functions are added to dma_ops on
> HIGHMEM-enabled configs because we can't just fall back on map/unmap_single
> when HIGHMEM is enabled.  Adding these to dma_ops makes it cleaner to
> substitute different functionality once we have iommu/swiotlb support.

Maybe I'm missing something but we should only have the page ones.
virt_to_page is cheap and we'll most likely need the phys address which
we get from the page anyway.

> There will be other patches that precede this one - I plan to duplicate 
> dma_mapping.h into include/asm-ppc to avoid breakage there.  There will 
> also be a patch to rename dma_64.c to dma.c, and a series of patches to 
> modify drivers that pass NULL dev pointers.

Note that NULL dev pointers are fine for the pci_ API and we need to
handle those.  But if you're talking about NULL dev pointers to the dma_
API yes, those should be fixed.

> +				   udbg.o misc.o io.o dma_64.o\

Whitespace before the \ please.

> +#ifdef CONFIG_PPC64
> +#include <asm/iommu.h>
> +
>  /*
>   * Generic iommu implementation
>   */
> @@ -108,6 +110,8 @@ struct dma_mapping_ops dma_iommu_ops = {
>  	.dma_supported	= dma_iommu_dma_supported,
>  };
>  EXPORT_SYMBOL(dma_iommu_ops);
> +#endif /* CONFIG_PPC64 */

This should probably be split into a dma_iommu.c file

> +#ifndef CONFIG_NOT_COHERENT_CACHE
>  static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
>  				       dma_addr_t *dma_handle, gfp_t flag)
>  {
The alloc_coherent ops probably should go into a dma-coherent.c file

> -	struct page *page;
>  	void *ret;
> -	int node = dev->archdata.numa_node;
> +	struct page *page;
> +	int node = -1;
> +#ifdef CONFIG_PPC64
> +	node = dev->archdata.numa_node;
> +#else

Please convert 64bit powerpc to use the numa_node field directly in
struct device and use the dev_to_node accessor.  That way it does
the right thing and we save a field per struct device instance.


> +	/* ignore region specifiers */
> +	flag  &= ~(__GFP_DMA | __GFP_HIGHMEM);
> +
> +	/* Bust slacker drivers that pass a NULL dev ptr */
> +	BUG_ON(dev == NULL);

These should be done for 64bit, too.

> +	if (dev->coherent_dma_mask < 0xffffffff)
> +		flag |= GFP_DMA;

This one probably aswell.

> +#else /* CONFIG_NOT_COHERENT_CACHE */
> +
> +static void *dma_direct_alloc_noncoherent(struct device *dev, size_t size,
> +				       dma_addr_t *dma_handle, gfp_t flag)
> +{
> +	return __dma_alloc_coherent(size, dma_handle, flag);
> +}
> +
> +static void dma_direct_free_noncoherent(struct device *dev, size_t size,
> +				     void *vaddr, dma_addr_t dma_handle)
> +{
> +	__dma_free_coherent(size, vaddr);
> +}
> +#endif /* CONFIG_NOT_COHERENT_CACHE */

Should probably go into dma-noncoherent.c

> @@ -180,20 +215,59 @@ static void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sg,
>  
>  static int dma_direct_dma_supported(struct device *dev, u64 mask)
>  {
> +#ifdef CONFIG_PPC64
>  	/* Could be improved to check for memory though it better be
>  	 * done via some global so platforms can set the limit in case
>  	 * they have limited DMA windows
>  	 */
>  	return mask >= DMA_32BIT_MASK;
> +#else
> +	return 1;
> +#endif

I think this depends on the dma ops and thus should be turned into one.

  parent reply	other threads:[~2008-05-23  9:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-30 23:36 [RFC] POWERPC: Merge 32 and 64-bit dma code Becky Bruce
2008-05-23  8:06 ` Mark Nelson
2008-05-29  1:53   ` Mark Nelson
2008-06-04  0:18     ` Becky Bruce
2008-05-23  9:51 ` Christoph Hellwig [this message]
2008-06-04  0:10   ` Becky Bruce

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=20080523095119.GA15722@lst.de \
    --to=hch@lst.de \
    --cc=bgill@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    /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.