All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: arnd@arndb.de, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH] asm-generic: add dma-mapping-linear.h
Date: Mon, 1 Jun 2009 08:51:14 +0100	[thread overview]
Message-ID: <20090601075114.GA29107@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20090601130319A.fujita.tomonori@lab.ntt.co.jp>

On Mon, Jun 01, 2009 at 01:02:42PM +0900, FUJITA Tomonori wrote:
> Where can I find dma_coherent_dev?
> 
> I don't fancy this since this is architecture-specific stuff (not
> generic things).

It _is_ very architecture specific.  The coherent-ness of devices hardly
depends on the device itself.  Eg, PCI devices on x86 are coherent, but
on ARM they aren't.

> > +static inline void
> > +dma_unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
> > +		 enum dma_data_direction direction)
> > +{
> > +	debug_dma_unmap_page(dev, dma_addr, size, direction, true);

Future ARMs will need to do something on unmaps.

> > +static inline void
> > +dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size,
> > +			enum dma_data_direction direction)
> > +{
> > +	debug_dma_sync_single_for_cpu(dev, dma_handle, size, direction);
> > +}
> > +
> > +static inline void
> > +dma_sync_single_range_for_cpu(struct device *dev, dma_addr_t dma_handle,
> > +			      unsigned long offset, size_t size,
> > +			      enum dma_data_direction direction)
> > +{
> > +	debug_dma_sync_single_range_for_cpu(dev, dma_handle,
> > +					    offset, size, direction);
> > +}
> 
> This looks wrong. You put dma_coherent_dev hook in sync_*_for_device
> but why you don't need it sync_*_for_cpu. It's architecture
> specific. Some need both, some need either, and some need nothing.

If you're non-coherent, you need to implement the sync APIs.

> > +static inline int
> > +dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
> > +{
> > +	return 0;

So mappings never fail?

> > +}
> > +
> > +/*
> > + * Return whether the given device DMA address mask can be supported
> > + * properly.  For example, if your device can only drive the low 24-bits
> > + * during bus mastering, then you would pass 0x00ffffff as the mask
> > + * to this function.
> > + */
> > +static inline int
> > +dma_supported(struct device *dev, u64 mask)
> > +{
> > +	/*
> > +	 * we fall back to GFP_DMA when the mask isn't all 1s,
> > +	 * so we can't guarantee allocations that must be
> > +	 * within a tighter range than GFP_DMA.
> > +	 */
> > +	if (mask < 0x00ffffff)
> > +		return 0;
> 
> I think that this is pretty architecture specific.

It is - it depends exactly on how you setup the DMA zone and whether
all your RAM is DMA-able.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

  reply	other threads:[~2009-06-01  7:51 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-28 20:04 [PATCH] asm-generic: add dma-mapping-linear.h Arnd Bergmann
2009-06-01  4:02 ` FUJITA Tomonori
2009-06-01  7:51   ` Russell King [this message]
2009-06-01  8:08     ` FUJITA Tomonori
2009-06-01  8:29       ` Russell King
2009-06-01  9:16         ` FUJITA Tomonori
2009-06-01  9:22           ` Russell King
2009-06-01  9:32             ` FUJITA Tomonori
2009-06-01 10:14               ` Russell King
2009-06-01 10:41                 ` Arnd Bergmann
2009-06-01 10:58                   ` Russell King
2009-06-01 11:42                     ` Arnd Bergmann
2009-06-01 10:28         ` Arnd Bergmann
2009-06-01 10:43           ` Russell King
2009-06-01 10:48             ` Arnd Bergmann
2009-06-01 10:11   ` Arnd Bergmann
2009-06-01 13:08     ` Michal Simek
2009-06-01 16:45       ` Arnd Bergmann
2009-06-02 11:11         ` Michal Simek
2009-06-04  7:57     ` FUJITA Tomonori
2009-06-04 12:35       ` Arnd Bergmann
2009-06-04 12:51         ` Russell King
2009-06-04 13:42           ` Arnd Bergmann
2009-06-04 14:38             ` Russell King
2009-06-04 14:49               ` Russell King
2009-06-04 16:29                 ` Arnd Bergmann
2009-06-04 15:05         ` FUJITA Tomonori
2009-06-04 16:47           ` Arnd Bergmann
2009-06-04 20:11             ` Geert Uytterhoeven
2009-06-08  5:49             ` FUJITA Tomonori
2009-06-08  8:03               ` Arnd Bergmann
2009-06-08  8:23                 ` FUJITA Tomonori
2009-06-08  8:49                   ` Arnd Bergmann
2009-06-04 12:45       ` Russell King

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=20090601075114.GA29107@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=arnd@arndb.de \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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.