public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
To: video4linux-list@redhat.com
Cc: video4linux-list@redhat.com, linux-sh@vger.kernel.org
Subject: Re: [PATCH 03/04] videobuf: Add physically contiguous queue code V2
Date: Mon, 14 Jul 2008 12:25:29 +0300	[thread overview]
Message-ID: <487B1B89.2030109@teltonika.lt> (raw)
In-Reply-To: <aec7e5c30807132051r16e51d71w177e410063ccefb@mail.gmail.com>

Magnus Damm wrote:
> On Sat, Jul 12, 2008 at 6:33 AM, Guennadi Liakhovetski
> <g.liakhovetski@gmx.de> wrote:
>> On Tue, 8 Jul 2008, Paulius Zaleckas wrote:
>>
>>> Magnus Damm wrote:
>>>> This is V2 of the physically contiguous videobuf queues patch.
>>>> Useful for hardware such as the SuperH Mobile CEU which doesn't
>>>> support scatter gatter bus mastering.
>> [snip]
>>
>>>> +   /* Try to remap memory */
>>>> +
>>>> +   size = vma->vm_end - vma->vm_start;
>>>> +   size = (size < mem->size) ? size : mem->size;
>>>> +
>>>> +   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>>>> +   retval = remap_pfn_range(vma, vma->vm_start,
>>>> +                            __pa(mem->vaddr) >> PAGE_SHIFT,
>>> __pa(mem->vaddr) doesn't work on ARM architecture... It is a long story
>>> about handling memory allocations and mapping for ARM (there is
>>> dma_mmap_coherent to deal with this), but there is a workaround:
>>>
>>> mem->dma_handle >> PAGE_SHIFT,
>>>
>>> It is safe to do it this way and also saves some CPU instructions :)
>> Paulius, even if the story is so long, could you perhaps point us to some
>> ML-threads or elaborate a bit? I did find one example in
>> drivers/media/video/atmel-isi.c (not in mainline), just would be
>> interesting to find out more.
>>
>> Magnus, have you investigated this further?
> 
> Both (__pa(mem->vaddr) >> PAGE_SHIFT) and (mem->dma_handle >>
> PAGE_SHIFT) work well with the current dma_alloc_coherent()
> implementation on SuperH. I do however lean towards using
> __pa(mem->vaddr) over mem->dma_handle, since I suspect that
> mem->dma_handle doesn't have to be a physical address.
> 
> Paul, any thoughts about this? Can we assume that the dma_handle
> returned from dma_alloc_coherent() is a physical address, or is it
> better to use __pa() on the virtual address to get the pfn?

Well dma_alloc_coherent() is supposed to return physically contiguous
memory physical address in dma_handle... Quick look at LXR didn't show
any architecture where it shouldn't work... but it showed that ARM and
possibly FRV(?) won't work with __pa() since these architectures are
allocating from different memory pool than kmalloc()

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

  reply	other threads:[~2008-07-14  9:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-05  2:53 [PATCH 00/04] soc_camera: SuperH Mobile CEU support V2 Magnus Damm
2008-07-05  2:53 ` [PATCH 01/04] soc_camera: Move spinlocks Magnus Damm
2008-07-05  4:19   ` Guennadi Liakhovetski
2008-07-05  4:24     ` Magnus Damm
2008-07-05  2:53 ` [PATCH 02/04] soc_camera: Add 16-bit bus width support Magnus Damm
2008-07-05  2:54 ` [PATCH 03/04] videobuf: Add physically contiguous queue code V2 Magnus Damm
2008-07-08 14:33   ` Paulius Zaleckas
2008-07-08 14:42     ` Laurent Pinchart
2008-07-09  8:33       ` Magnus Damm
2008-07-11 21:33     ` Guennadi Liakhovetski
2008-07-14  3:51       ` Magnus Damm
2008-07-14  9:25         ` Paulius Zaleckas [this message]
     [not found]         ` <20080715034850.GA3722@linux-sh.org>
2008-07-15  8:28           ` Magnus Damm
2008-07-11 13:38   ` Karicheri, Muralidharan
2008-07-05  2:54 ` [PATCH 04/04] sh_mobile_ceu_camera: Add SuperH Mobile CEU driver V2 Magnus Damm

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=487B1B89.2030109@teltonika.lt \
    --to=paulius.zaleckas@teltonika.lt \
    --cc=linux-sh@vger.kernel.org \
    --cc=video4linux-list@redhat.com \
    /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