linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera
Date: Fri, 10 Dec 2010 17:03:56 +0000	[thread overview]
Message-ID: <20101210170356.GA28472@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <201012101203.09441.jkrzyszt@tis.icnet.pl>

On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
>  void __init omap1_camera_init(void *info)
>  {
>  	struct platform_device *dev = &omap1_camera_device;
> +	dma_addr_t paddr = omap1_camera_phys_mempool_base;
> +	dma_addr_t size = omap1_camera_phys_mempool_size;
>  	int ret;
>  
>  	dev->dev.platform_data = info;
>  
> +	if (paddr) {
> +		if (dma_declare_coherent_memory(&dev->dev, paddr, paddr, size,
> +				DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))

Although this works, you're ending up with SDRAM being mapped via
ioremap, which uses MT_DEVICE - so what is SDRAM ends up being
mapped as if it were a device.

For OMAP1, which is ARMv5 or lower, device memory becomes 'uncacheable,
unbufferable' which is luckily what is used for the DMA coherent
memory on those platforms - so no technical problem here.

However, on ARMv6 and later, ioremapped memory is device memory, which
has different ordering wrt normal memory mappings, and may appear on
different busses on the CPU's interface.  So, this is something I don't
encourage as it's unclear that the hardware will work.

Essentially, dma_declare_coherent_memory() on ARM with main SDRAM should
be viewed as a 'it might work, it might not, and it might stop working
in the future' kind of interface.  In other words, there is no guarantee
that this kind of thing will be supported in the future.

  reply	other threads:[~2010-12-10 17:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201012051929.07220.jkrzyszt@tis.icnet.pl>
2010-12-10 10:59 ` [RESEND] [PATCH 0/2] OMAP1: amsdelta: reserve memory for videobuf_contig Janusz Krzysztofik
2010-12-10 11:03   ` [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera Janusz Krzysztofik
2010-12-10 17:03     ` Russell King - ARM Linux [this message]
2010-12-10 21:03       ` Janusz Krzysztofik
2011-06-08 21:53         ` Janusz Krzysztofik
2011-06-08 22:13           ` Russell King - ARM Linux
2011-06-08 22:44             ` Janusz Krzysztofik
2011-07-12  9:53             ` Janusz Krzysztofik
2010-12-13 15:52       ` Catalin Marinas
2010-12-13 16:29         ` Russell King - ARM Linux
2010-12-15 12:39           ` Catalin Marinas
2010-12-15 17:01             ` Russell King - ARM Linux
2010-12-19 11:46               ` Janusz Krzysztofik
2010-12-10 11:05   ` [PATCH 2/2] OMAP1: Amstrad Delta: reserve " Janusz Krzysztofik

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=20101210170356.GA28472@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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 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).