Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2011-07-12 Thread Janusz Krzysztofik 
On Thu, 9 Jun 2011 at 00:13:30 Russell King - ARM Linux wrote:
 On Wed, Jun 08, 2011 at 11:53:49PM +0200, Janusz Krzysztofik wrote:
  On Fri 10 Dec 2010 at 22:03:52 Janusz Krzysztofik wrote:
   Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
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.
  
  Russell, Tony,
  
  Sorry for getting back to this old thread, but since my previous
  attempts to provide[1] or support[2] a possibly better solution to
  the problem all failed on one hand, and I can see patches not very
  different from mine[3] being accepted for arch/arm/mach-{mx3,imx}
  during this and previous merge windows[4][5][6] on the other, is
  there any chance for the 'dma_declare_coherent_memory() over a
  memblock_alloc()-free()-remove() obtained area' based solution
  being accepted for omap1_camera as well if I resend it refreshed?
 
 I stand by my answer to your patches quoted above from a technical
 point of view; we should not be mapping SDRAM using device mappings.

Russell,
Would it change anything here if we define ARCH_HAS_HOLES_MEMORYMODEL, 
as suggested by Marek Szyprowski recently[*], when configuring for 
ARCH_OMAP1 with VIDEO_OMAP1 (camera) selected?

[*] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/057447.html

 Certainly the memblock_alloc()+free()+remove() is the right way to
 reserve the memory, but as it stands dma_declare_coherent_memory()
 should not be used on ARMv6 or higher CPUs to pass that memory to the
 device driver.

Tony,
With full respect to all Russell's reservations about incorrectness of 
ioremapping SDRAM in general, would you be willing to accept this 
solution in the OMAP1 camera case, taking into account that, quoting 
Russell, there is no technical problem here, and similiar solutions 
had been accepted recently with other ARM platforms?

Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2011-06-08 Thread Janusz Krzysztofik 
On Fri 10 Dec 2010 at 22:03:52 Janusz Krzysztofik wrote:
 Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
  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.
 
 I was affraid of an unswer of this kind. I'm not capable of comming
 out with any better, alternative solutions. Any hints other than
 giving up with that old videobuf-contig, coherent memory based
 interface? Or can we agree on that 'luckily uncacheable,
 unbufferable, SDRAM based DMA coherent memory' solution for now?

Russell, Tony,

Sorry for getting back to this old thread, but since my previous 
attempts to provide[1] or support[2] a possibly better solution to the 
problem all failed on one hand, and I can see patches not very different 
from mine[3] being accepted for arch/arm/mach-{mx3,imx} during this and 
previous merge windows[4][5][6] on the other, is there any chance for the 
'dma_declare_coherent_memory() over a memblock_alloc()-free()-remove() 
obtained area' based solution being accepted for omap1_camera as well if 
I resend it refreshed?

BTW, commit 6d3163ce86dd386b4f7bda80241d7fea2bc0bb1d, mm: check if any 
page in a pageblock is reserved before marking it MIGRATE_RESERVE, 
almost corrected the problem for me, allowing for very stable device 
operation in videobuf_dma_contig mode once all resident programs get 
settled up and no unusual activity happens, but this is still not 100% 
reliable, so I think that only using a kind of memory area reservered 
during boot for the purpose can be considered as free of transient 
-ENOMEM issues.

Thanks,
Janusz

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036419.html
[2] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036551.html
[3] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/034643.html
[4] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;h=164f7b5237cca2701dd2943928ec8d078877a28d
[5] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;h=031e912741746e4350204bb0436590ca0e993a7d
[6] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;h=dca7c0b4293a06d1ed9387e729a4882896abccc2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2011-06-08 Thread Russell King - ARM Linux 
On Wed, Jun 08, 2011 at 11:53:49PM +0200, Janusz Krzysztofik wrote:
 On Fri 10 Dec 2010 at 22:03:52 Janusz Krzysztofik wrote:
  Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
   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.
  
  I was affraid of an unswer of this kind. I'm not capable of comming
  out with any better, alternative solutions. Any hints other than
  giving up with that old videobuf-contig, coherent memory based
  interface? Or can we agree on that 'luckily uncacheable,
  unbufferable, SDRAM based DMA coherent memory' solution for now?
 
 Russell, Tony,
 
 Sorry for getting back to this old thread, but since my previous 
 attempts to provide[1] or support[2] a possibly better solution to the 
 problem all failed on one hand, and I can see patches not very different 
 from mine[3] being accepted for arch/arm/mach-{mx3,imx} during this and 
 previous merge windows[4][5][6] on the other, is there any chance for the 
 'dma_declare_coherent_memory() over a memblock_alloc()-free()-remove() 
 obtained area' based solution being accepted for omap1_camera as well if 
 I resend it refreshed?

I stand by my answer to your patches quoted above from a technical point
of view; we should not be mapping SDRAM using device mappings.

That ioremap() inside dma_declare_coherent_memory() needs to die, but
it seems that those who now look after the DMA API really aren't
interested in the technical details of this being wrong for some
architecture - just like they're not really interested in the details
of devices using dma-engines for their DMA support.

I'm afraid that the DMA support in Linux sucks because of this, and I
have no real desire to participate in discussions with brick walls over
this.

Certainly the memblock_alloc()+free()+remove() is the right way to
reserve the memory, but as it stands dma_declare_coherent_memory()
should not be used on ARMv6 or higher CPUs to pass that memory to the
device driver.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2011-06-08 Thread Janusz Krzysztofik 
On Thu 09 Jun 2011 at 00:13:30 Russell King - ARM Linux wrote:
 
 I stand by my answer to your patches quoted above from a technical
 point of view; we should not be mapping SDRAM using device mappings.
 
 That ioremap() inside dma_declare_coherent_memory() needs to die,

Then how about your alternative, ARM specific solution, Avoid aliasing 
mappings in DMA coherent allocator? There was a series of initially 
two, then three patches, of which the two others (459c1517f987 ARM: 
DMA: Replace page_to_dma()/dma_to_page() with pfn_to_dma()/dma_to_pfn() 
and 9eedd96301ca ARM: DMA: top-down allocation in DMA coherent region) 
are already in the mainline tree. I'm still porting a copy of that third 
one from kernel version to version to have my device working 100% 
reliably, in hope you finally push it into the mainline. No plans 
against it? Or is there something about it I could help with?

Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2010-12-19 Thread Janusz Krzysztofik 
Wednesday 15 December 2010 18:01:42 Russell King - ARM Linux wrote:
 On Wed, Dec 15, 2010 at 12:39:20PM +, Catalin Marinas wrote:
 
  Should we not try to fix the generic code and still allow platforms
  to use dma_declare_coherent_memory() in a safer way? I guess it may
  need some arguing/explanation on linux-arch.

 I think so - 

Hi Russel,
I've already started implementing what you've suggested, with an already 
working result, but have two questions:

1. Is it save to leave iounmap() being called on virtual addresses not 
   obtained with ioremap()? This would make things less complicated.

2. Can I quote your full explanation, just like it looks below, in my 
   commit message?

Thanks,
Janusz

Wednesday 15 December 2010 18:01:42 Russell King - ARM Linux wrote:
 ... one of the issues with dma_declare_coherent_memory() is 
 that it's original intention (as I understand it) was to allow
 drivers to use on-device dma coherent memory.

 Eg, a network controller with its own local SRAM which it can fetch
 DMA descriptors from, which tells it where in the bus address space
 to fetch packets from.  This SRAM is not part of the hosts memory,
 but is on the peripheral's bus, and so ioremap() (or maybe
 ioremap_wc()) would be appropriate for it.

 However, ioremap() on system RAM (even that which has been taken out
 on the memory map) may be problematical.

 I think the correct solution would be to revise the interface so it
 takes a void * pointer, which can be handed out by
 dma_alloc_coherent() directly without the API having to worry about
 how to map the memory.  IOW, push the mapping of that memory up a
 level to the caller of
 dma_declare_coherent_memory().

 We can then sanely do preallocations via dma_coherent_alloc() and
 caching them back into dma_declare_coherent_memory() without creating
 additional mappings which cause architectural violations.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2010-12-15 Thread Catalin Marinas 
On 13 December 2010 16:29, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
 On 10 December 2010 17:03, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  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.

 BTW, does the generic dma_declare_coherent_memory() does the correct
 thing in using ioremap()?

 I argue it doesn't, as I said above.  It means we map SDRAM as device
 memory, and as I understand the way interconnects work, it's entirely
 possible that this may not result in the SDRAM being accessible.
[...]
 So, not only does this fail the kernel's own rules, but as we already know,
 it fails the architecture's restrictions with multiple mappings of memory
 when used with SDRAM, and it also maps main memory as a device.  I wonder
 how many more things this broken API needs to do wrong before it's current
 implementation is consigned to the circular filing cabinet.

Should we not try to fix the generic code and still allow platforms to
use dma_declare_coherent_memory() in a safer way? I guess it may need
some arguing/explanation on linux-arch.

-- 
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2010-12-15 Thread Russell King - ARM Linux 
On Wed, Dec 15, 2010 at 12:39:20PM +, Catalin Marinas wrote:
 On 13 December 2010 16:29, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
  On 10 December 2010 17:03, Russell King - ARM Linux
  li...@arm.linux.org.uk wrote:
   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.
 
  BTW, does the generic dma_declare_coherent_memory() does the correct
  thing in using ioremap()?
 
  I argue it doesn't, as I said above.  It means we map SDRAM as device
  memory, and as I understand the way interconnects work, it's entirely
  possible that this may not result in the SDRAM being accessible.
 [...]
  So, not only does this fail the kernel's own rules, but as we already know,
  it fails the architecture's restrictions with multiple mappings of memory
  when used with SDRAM, and it also maps main memory as a device.  I wonder
  how many more things this broken API needs to do wrong before it's current
  implementation is consigned to the circular filing cabinet.
 
 Should we not try to fix the generic code and still allow platforms to
 use dma_declare_coherent_memory() in a safer way? I guess it may need
 some arguing/explanation on linux-arch.

I think so - one of the issues with dma_declare_coherent_memory() is that
it's original intention (as I understand it) was to allow drivers to use
on-device dma coherent memory.

Eg, a network controller with its own local SRAM which it can fetch DMA
descriptors from, which tells it where in the bus address space to fetch
packets from.  This SRAM is not part of the hosts memory, but is on the
peripheral's bus, and so ioremap() (or maybe ioremap_wc()) would be
appropriate for it.

However, ioremap() on system RAM (even that which has been taken out on
the memory map) may be problematical.

I think the correct solution would be to revise the interface so it takes
a void * pointer, which can be handed out by dma_alloc_coherent() directly
without the API having to worry about how to map the memory.  IOW, push
the mapping of that memory up a level to the caller of
dma_declare_coherent_memory().

We can then sanely do preallocations via dma_coherent_alloc() and caching
them back into dma_declare_coherent_memory() without creating additional
mappings which cause architectural violations.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2010-12-13 Thread Catalin Marinas 
On 10 December 2010 17:03, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 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.

BTW, does the generic dma_declare_coherent_memory() does the correct
thing in using ioremap()? Maybe some other function that takes a
pgprot_t would be better (ioremap_page_range) and could pass something
like pgprot_noncached (though ideally a pgprot_dmacoherent). Or just
an architecturally-defined function.

-- 
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2010-12-13 Thread Russell King - ARM Linux 
On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
 On 10 December 2010 17:03, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  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.
 
 BTW, does the generic dma_declare_coherent_memory() does the correct
 thing in using ioremap()?

I argue it doesn't, as I said above.  It means we map SDRAM as device
memory, and as I understand the way interconnects work, it's entirely
possible that this may not result in the SDRAM being accessible.

 Maybe some other function that takes a
 pgprot_t would be better (ioremap_page_range) and could pass something
 like pgprot_noncached (though ideally a pgprot_dmacoherent). Or just
 an architecturally-defined function.

This API was designed in the ARMv5 days when things were a lot simpler.
What we now have is rather messy though, and really needs sorting out
before we get too many users of it.  (Arguably it should never have been
accepted in its current state.)

We have a rule that the returned value of ioremap() is not to be used
as a pointer which can be dereferenced by anything except driver code.
Yet this is exactly what dma_declare_coherent_memory() does:

struct dma_coherent_mem {
void*virt_base;
...
};

int dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
dma_addr_t device_addr, size_t size, int flags)
{
void __iomem *mem_base = NULL;
mem_base = ioremap(bus_addr, size);
dev-dma_mem-virt_base = mem_base;
}

int dma_alloc_from_coherent(struct device *dev, ssize_t size,
   dma_addr_t *dma_handle, void **ret)
{
*ret = mem-virt_base + (pageno  PAGE_SHIFT);
}

and drivers expect the returned value from dma_alloc_coherent() to be
dereferenceable.

Note that this also fails sparse checking.  It will fail on any
architecture where the return value from ioremap() is not a virtual
address.

So, not only does this fail the kernel's own rules, but as we already know,
it fails the architecture's restrictions with multiple mappings of memory
when used with SDRAM, and it also maps main memory as a device.  I wonder
how many more things this broken API needs to do wrong before it's current
implementation is consigned to the circular filing cabinet.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2010-12-10 Thread Janusz Krzysztofik 
OMAP1 camera driver, when starting up in its videobuf_contig mode, may have 
problems with allocating dma coherent memory after system memory gets 
fragmented if there is no dedicated memory declared as a dma coherent memory 
block associated with the device. To solve this issue, allow for removing a 
block of memory from system memory early on boot, then, if reserved this way, 
declare it as the device dedicated dma coherent memory.

An example use case on Amstrad Delta will be provided with patch 2/2.

Created and tested against linux-2.6.37-rc4.

Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
 arch/arm/mach-omap1/devices.c |   36 ++
 arch/arm/mach-omap1/include/mach/camera.h |1
 2 files changed, 37 insertions(+)

--- linux-2.6.37-rc4/arch/arm/mach-omap1/devices.c.orig 2010-12-04 
18:00:39.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/devices.c  2010-12-04 
22:22:13.0 +0100
@@ -16,6 +16,7 @@
 #include linux/platform_device.h
 #include linux/io.h
 #include linux/spi/spi.h
+#include linux/memblock.h
 
 #include mach/hardware.h
 #include asm/mach/map.h
@@ -222,13 +223,48 @@ static struct platform_device omap1_came
.resource   = omap1_camera_resources,
 };
 
+static phys_addr_t omap1_camera_phys_mempool_base;
+static phys_addr_t omap1_camera_phys_mempool_size;
+
+void __init omap1_camera_reserve(phys_addr_t size)
+{
+   phys_addr_t paddr;
+
+   if (!size)
+   return;
+
+   paddr = memblock_alloc(size, SZ_1M);
+
+   if (!paddr) {
+   pr_err(%s: failed to reserve %x bytes\n, __func__, size);
+   return;
+   }
+   memblock_free(paddr, size);
+   memblock_remove(paddr, size);
+
+   omap1_camera_phys_mempool_base = paddr;
+   omap1_camera_phys_mempool_size = size;
+}
+
 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))
+   pr_info(%s: reserved %d bytes camera buffer memory\n,
+   __func__, size);
+   else
+   pr_warn(%s: cannot reserve camera buffer memory\n,
+   __func__);
+   }
+
ret = platform_device_register(dev);
if (ret)
dev_err(dev-dev, unable to register device: %d\n, ret);
--- linux-2.6.37-rc4/arch/arm/mach-omap1/include/mach/camera.h.orig 
2010-12-04 18:00:39.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/include/mach/camera.h  2010-12-04 
22:26:23.0 +0100
@@ -3,6 +3,7 @@
 
 #include media/omap1_camera.h
 
+void omap1_camera_reserve(phys_addr_t);
 void omap1_camera_init(void *);
 
 static inline void omap1_set_camera_info(struct omap1_cam_platform_data *info)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2010-12-10 Thread Russell King - ARM Linux 
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.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH 1/2] OMAP1: allow reserving memory for camera

2010-12-10 Thread Janusz Krzysztofik 
Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
 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.

I was affraid of an unswer of this kind. I'm not capable of comming out with 
any better, alternative solutions. Any hints other than giving up with that 
old videobuf-contig, coherent memory based interface? Or can we agree on 
that 'luckily uncacheable, unbufferable, SDRAM based DMA coherent memory' 
solution for now?

Thanks,
Janusz
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html