V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
After switching from mem->dma_handle to virt_to_phys(mem->vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig stopped working on my ARM based board. The ARM architecture maintainer, Russell King, confirmed that using something like virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can be broken on other architectures as well. The author of the change, Jiri Slaby, also confirmed that his code may not work on all architectures.
The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem->dma_handle)) instead of problematic virt_to_phys(mem->vaddr). I think this should work even if those translations would occure inaccurate for DMA addresses, since possible errors introduced by both translations, performed in opposite directions, should compensate.
Tested on ARM OMAP1 based Amstrad Delta board.
---
v1 -> v2 changes:
- drop dma_mmap_coherent() path, it may not work correctly for device memory preallocated with dma_declare_coherent_memory().
drivers/media/video/videobuf-dma-contig.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/media/video/videobuf-dma-contig.c renamed from drivers/media/video/videobuf-dma-contig.c.orig +2 -2
@@ -300,8 +300,8 @@ static int __videobuf_mmap_mapper(struct vma->vm_page_prot =pgprot_noncached (vma->vm_page_prot); retval =remap_pfn_range (vma, vma->vm_start, -PFN_DOWN (virt_to_phys (mem->vaddr)), - size, vma->vm_page_prot); +PFN_DOWN (virt_to_phys (bus_to_virt (mem->dma_handle))), + size, vma->vm_page_prot);if (retval) {dev_err (q->dev,"mmap: remap failed with error %d. " , retval); dma_free_coherent(q->dev, mem->size,
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Quoted 3 lines · Janusz Krzysztofik
The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem->dma_handle)) instead of problematic
virt_to_phys(mem->vaddr).
Who says that DMA handles are bus addresses in the strictest sense?
DMA handles on ARM are the bus address to program 'dev' with in order for it to access the memory mapped by dma_alloc_coherent(). On some ARM platforms, this bus address is dependent on 'dev' - such as platforms with more than one root PCI bus, and so bus_to_virt() just doesn't hack it.
What is really needed is for this problem - the mapping of DMA coherent memory into userspace - to be solved with a proper arch API rather than all these horrible hacks which subsystems instead invent. That's something I tried to do with the dma_mmap_coherent() stuff but it was shot down by linux-arch as (iirc) PA-RISC objected to it.
Hence why ARM only implements it.
Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide dma_mmap_coherent().
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Quoted 19 lines · Russell King - ARM Linux
Quoted 3 lines · Janusz Krzysztofik
The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem->dma_handle)) instead of problematic
virt_to_phys(mem->vaddr).Who says that DMA handles are bus addresses in the strictest sense?
DMA handles on ARM are the bus address to program 'dev' with in order for it to access the memory mapped by
dma_alloc_coherent(). On some ARM platforms, this bus address is dependent on 'dev' - such as platforms with more than one root PCI bus, and sobus_to_virt()just doesn't hack it.What is really needed is for this problem - the mapping of DMA coherent memory into userspace - to be solved with a proper arch API rather than all these horrible hacks which subsystems instead invent. That's something I tried to do with the
dma_mmap_coherent()stuff but it was shot down by linux-arch as (iirc) PA-RISC objected to it.
Quoted 4 lines
Hence why ARM only implements it.
Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide
dma_mmap_coherent().
I do not know how this fits into the present discussion. Perhaps everyone who reads the above message is well aware of what is below. If so my comment below is superfluous. But just in case things are otherwise it might save someone a bit of trouble in trying to write something which will work "everywhere":
If one is speaking here of architecture problems, there is the additional problem that some ARM systems might have not two PCI buses, but instead no PCI bus at all.
Theodore Kilgore
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
In reply to Russell King - ARM LinuxQuoted 5 lines · On Tue 12 Apr 2011 at 23:40:11 Russell King - ARM Linux wrote:
Quoted 3 lines · Janusz Krzysztofik
The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem->dma_handle)) instead of problematic
virt_to_phys(mem->vaddr).
Quoted 7 lines
Who says that DMA handles are bus addresses in the strictest sense?
DMA handles on ARM are the bus address to program 'dev' with in order for it to access the memory mapped by
dma_alloc_coherent(). On some ARM platforms, this bus address is dependent on 'dev' - such as platforms with more than one root PCI bus, and sobus_to_virt()just doesn't hack it.
Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle?
If there is one, then I agree that my short-term fix is wrong.
Quoted 8 lines
What is really needed is for this problem - the mapping of DMA coherent memory into userspace - to be solved with a proper arch API rather than all these horrible hacks which subsystems instead invent. That's something I tried to do with the
dma_mmap_coherent()stuff but it was shot down by linux-arch as (iirc) PA-RISC objected to it.Hence why ARM only implements it.
I thought so too, but missed the fact that PowerPC implements it actually, even defining the ARCH_HAS_DMA_MMAP_COHERENT symbol, which ARM doesn't so far.
Quoted 3 lines
Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide
dma_mmap_coherent().
AFAICT, ARM implementation of dma_mmap_coherent() is not compatible with dma_declare_coherent_memory(), is it? If I'm wrong, please correct me, I'll get back to the idea presented in v1 of the fix.
Otherwise, I think that switching to dma_mmap_coherent() is not an option for the videobuf-dma-contig subsystem as long as there is no good solution to the problem of dma_alloc_coherent() not guaranteed to succeed with high-order allocations at any time. Any chance for your already proposed
(http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036463.html,
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/036809.html),
or perhaps a new, better solution ever finding its way to the mainline tree?
Thanks,
Janusz
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Quoted 6 lines · Janusz Krzysztofik
Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal
dma_handle?
I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong?
Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed.
Quoted 3 lines
I thought so too, but missed the fact that PowerPC implements it actually, even defining the
ARCH_HAS_DMA_MMAP_COHERENTsymbol, which ARM doesn't so far.
So, there's no problem adding that symbol to ARM.
Quoted 7 lines
Quoted 3 lines
Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide
dma_mmap_coherent().AFAICT, ARM implementation of
dma_mmap_coherent()is not compatible withdma_declare_coherent_memory(), is it? If I'm wrong, please correct me, I'll get back to the idea presented in v1 of the fix.
1. dma_declare_coherent_memory() doesn't work on ARM for memory which already exists (its not permitted to ioremap() the kernel direct-mapped memory due to attribute aliasing issues.)
2. dma_declare_coherent_memory() totally bypasses the DMA allocator, and so dma_mmap_coherent() has no knowledge of how to map the memory.
If we had a proper way to map DMA memory into userspace, then we wouldn't have these issues as the dma_declare_coherent_memory() would already support that.
And actually, talking about dma_declare_coherent_memory(), you've just provided a reason why virt_to_phys(bus_to_virt(dma_handle)) won't work - dma_declare_coherent_memory() can be used to provide on-device memory where the virt/handle may not be mappable with bus_to_virt().
Quoted 4 lines
Otherwise, I think that switching to
dma_mmap_coherent()is not an option for the videobuf-dma-contig subsystem as long as there is no good solution to the problem ofdma_alloc_coherent()not guaranteed to succeed with high-order allocations at any time.
Let me repeat: there is no official API or way to map DMA memory into userspace. Every way people try is a half-hacked up bodge which may or may not work for a limited subset of systems.
Until someone (like you) puts some serious effort into persuading *everyone* that this feature is needed, things are just going to continue being bodged and fragile.
All that's happening here is that you're changing one broken way which works for one subset with another broken way which works for a different subset of systems and architectures. What actually needs to happen is a _proper_ fix for this.
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia ?roda 13 kwiecie? 2011 o 20:32:31 Russell King - ARM Linux napisa?(a):
Quoted 8 lines · Janusz Krzysztofik
Quoted 6 lines
Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal
dma_handle?
Quoted 6 lines
I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong?
Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed.
In theory - of course. In practice - couldn't we now, close to -rc3, relax the rules a little bit and stop bothering with something that may break in the future if it doesn't break on any board supported so far (I hope)?
Quoted 5 lines
Quoted 3 lines
I thought so too, but missed the fact that PowerPC implements it actually, even defining the
ARCH_HAS_DMA_MMAP_COHERENTsymbol, which ARM doesn't so far.So, there's no problem adding that symbol to ARM.
OK, I can provide a patch as soon as dma_mmap_coherent() really works for me.
Quoted 11 lines
Quoted 7 lines
Quoted 3 lines
Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide
dma_mmap_coherent().AFAICT, ARM implementation of
dma_mmap_coherent()is not compatible withdma_declare_coherent_memory(), is it? If I'm wrong, please correct me, I'll get back to the idea presented in v1 of the fix.1.
dma_declare_coherent_memory()doesn't work on ARM for memory which already exists (its not permitted toioremap()the kernel direct-mapped memory due to attribute aliasing issues.)
But you had once inspired
(http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/034879.html),
then was supporting my attempts towards pushing ioremap() out of this function up to the caller
(http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036419.html),
which would allow for doing sane preallocations via dma_coherent_alloc() and caching them back into dma_declare_coherent_memory() at boot time for later reuse mempry from that pool as DMA coherent. Now, should my attepmts succeded, we would still end up with the following:
Quoted 1 line
2.
dma_declare_coherent_memory()totally bypasses the DMA allocator,
Would it still, under your terms, if it could accept dma_alloc_coherent() obtained cpu addresses, not trying to ioremap() them?
Quoted 2 lines
and so
dma_mmap_coherent()has no knowledge of how to map the memory.
I think it _could_ have a good knowledge if that memory was first preallocated with dma_alloc_coherent() at boot time, unless that memory was then fetched from that pool in smaller chunks. I think this is the reason it didn't work for me when I tried using this method with dma_mmap_coherent(). Am I missing something?
Quoted 9 lines
If we had a proper way to map DMA memory into userspace, then we wouldn't have these issues as the
dma_declare_coherent_memory()would already support that.And actually, talking about
dma_declare_coherent_memory(), you've just provided a reason why virt_to_phys(bus_to_virt(dma_handle)) won't work -dma_declare_coherent_memory()can be used to provide on-device memory where thevirt/handlemay not be mappable withbus_to_virt().
While I have no problems to agree with the principles, I can confirm that this _hack_ does coexist nicely with dma_declare_coherent_memory(), at least on my OMAP1 based board.
It also coexists nicely with your WiP patches I mentioned before and you didn't quote here, so I provide the links again:
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036461.html,
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/036809.html.
OTOH, dma_mmap_coherent() didn't work for me when I tried using it on top of those patches.
This doesn't mean I'm against a dma_mmap_coherent() based solution. I just think we can't afford switching to it _now_.
Quoted 7 lines
Quoted 4 lines
Otherwise, I think that switching to
dma_mmap_coherent()is not an option for the videobuf-dma-contig subsystem as long as there is no good solution to the problem ofdma_alloc_coherent()not guaranteed to succeed with high-order allocations at any time.Let me repeat: there is no official API or way to map DMA memory into userspace.
Doesn't dma_mmap_coherent(), already available on 2 architectures, ARM and PPC, aim to provide the correct API? From the fact you didn't dispute v1 of my patch, which provided a dma_mmap_coherent() based code path for architectures supporting it, I would conclude this is a solution which might get your support, isn't it?
However, I think that even if it was a _proper_ solution to the problem, it couldn't be accepted as a fix during the rc cycle for a simple
reason: this would break all those boards (ab)using dma_declare_coherent_memory().
Quoted 11 lines
Every way people try is a half-hacked up bodge which may or may not work for a limited subset of systems.
Until someone (like you) puts some serious effort into persuading *everyone* that this feature is needed, things are just going to continue being bodged and fragile.
All that's happening here is that you're changing one broken way which works for one subset with another broken way which works for a different subset of systems and architectures. What actually needs to happen is a _proper_ fix for this.
I don't believe you really think it would possible to come out with a _proper_ solution to the problem which could still be accepted as a _fix_. We are close to -rc3.
If I'm wrong, and you think this can still be fixed properly for this rc cycle, please share more of your idea and I'll try to do my best to implement it.
Thanks,
Janusz
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Quoted 14 lines · Janusz Krzysztofik
Dnia ?roda 13 kwiecie? 2011 o 20:32:31 Russell King - ARM Linux napisa?(a):
Quoted 12 lines · Janusz Krzysztofik
Quoted 6 lines
Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal
dma_handle?I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong?
Quoted 7 lines
Quoted 2 lines
Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed.
In theory - of course. In practice - couldn't we now, close to -rc3, relax the rules a little bit and stop bothering with something that may break in the future if it doesn't break on any board supported so far (I hope)?
If we are worried about closeness to -final, then what should happen is that the original commit is reverted; the "fix" for IOMMUs resulted in a regression for existing users which isn't trivial to resolve without risking possible breakage of other users.
Do we even know whether bus_to_virt(iommu_bus_address) works? I suspect it doesn't, so by doing so you're already re-breaking the IOMMU case.
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia czwartek 14 kwiecie? 2011 o 00:00:08 Russell King - ARM Linux napisa?(a):
Quoted 5 lines · Janusz Krzysztofik
Quoted 4 lines
Dnia ?roda 13 kwiecie? 2011 o 20:32:31 Russell King - ARM Linux
napisa?(a):
Quoted 1 line
On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik
Quoted 20 lines · wrote:
Quoted 12 lines
Quoted 12 lines
Quoted 7 lines
Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal
dma_handle?I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong?
Quoted 7 lines
Quoted 2 lines
Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed.
In theory - of course. In practice - couldn't we now, close to -rc3, relax the rules a little bit and stop bothering with something that may break in the future if it doesn't break on any board supported so far (I hope)?
Quoted 8 lines
If we are worried about closeness to -final, then what should happen is that the original commit is reverted; the "fix" for IOMMUs resulted in a regression for existing users which isn't trivial to resolve without risking possible breakage of other users.
Do we even know whether
bus_to_virt(iommu_bus_address)works? I suspect it doesn't, so by doing so you're already re-breaking the IOMMU case.
Hard to deny with only me having actually tested this dirty hack on one single board :)
Thanks for your support,
Janusz
Quoted 23 lines · Russell King - ARM Linux
Quoted 14 lines · Janusz Krzysztofik
Dnia ?roda 13 kwiecie? 2011 o 20:32:31 Russell King - ARM Linux napisa?(a):
Quoted 12 lines · Janusz Krzysztofik
Quoted 6 lines
Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal
dma_handle?I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong?
Quoted 7 lines
Quoted 2 lines
Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed.
In theory - of course. In practice - couldn't we now, close to -rc3, relax the rules a little bit and stop bothering with something that may break in the future if it doesn't break on any board supported so far (I hope)?
Quoted 4 lines
If we are worried about closeness to -final, then what should happen is that the original commit is reverted; the "fix" for IOMMUs resulted in a regression for existing users which isn't trivial to resolve without risking possible breakage of other users.
Hi, as -rc4 is out, I think it's time to revert that commit and rethink the mmap behaviour for some of next -rc1s.
Linus, please revert
commit 35d9f510b67b10338161aba6229d4f55b4000f5b
Author: Jiri Slaby <[email protected]> Date: Mon Feb 28 06:37:02 2011 -0300
[media] V4L: videobuf, don't use dma addr as physical
===
It fixes mmap when IOMMU is used on x86 only, but breaks architectures like ARM or PPC where virt_to_phys(dma_alloc_coherent) doesn't work. We need there dma_mmap_coherent or similar (the trickery what snd_pcm_default_mmap does but in some saner way). But this cannot be done at this phase.
thanks,
Signature · 2 lines
js suse labs
Mauro Carvalho Chehab
Acked-byEm 19-04-2011 03:08, Jiri Slaby escreveu:
Quoted 29 lines · Russell King - ARM Linux
Quoted 23 lines · Janusz Krzysztofik
Quoted 14 lines
Dnia ?roda 13 kwiecie? 2011 o 20:32:31 Russell King - ARM Linux napisa?(a):
Quoted 12 lines · Janusz Krzysztofik
Quoted 6 lines
Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal
dma_handle?I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong?
Quoted 7 lines
Quoted 2 lines
Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed.
In theory - of course. In practice - couldn't we now, close to -rc3, relax the rules a little bit and stop bothering with something that may break in the future if it doesn't break on any board supported so far (I hope)?
Quoted 4 lines
If we are worried about closeness to -final, then what should happen is that the original commit is reverted; the "fix" for IOMMUs resulted in a regression for existing users which isn't trivial to resolve without risking possible breakage of other users.
Quoted 7 lines
Hi, as -rc4 is out, I think it's time to revert that commit and rethink the mmap behaviour for some of next -rc1s.
Linus, please revert
commit35d9f510b67b10338161aba6229d4f55b4000f5bAuthor: Jiri Slaby <[email protected]> Date: Mon Feb 28 06:37:02 2011 -0300
It seems the better option for now.
Quoted 11 lines
[media] V4L: videobuf, don't use dma addr as physical
===It fixes mmap when IOMMU is used on x86 only, but breaks architectures like ARM or PPC where
virt_to_phys(dma_alloc_coherent)doesn't work. We need theredma_mmap_coherentor similar (the trickery whatsnd_pcm_default_mmapdoes but in some saner way). But this cannot be done at this phase.thanks,
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
In reply to Janusz KrzysztofikHello.
Quoted 3 lines · Janusz Krzysztofik
After switching from
mem->dma_handletovirt_to_phys(mem->vaddr)used for obtaining page frame number passed toremap_pfn_range()(commit35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig
Please specify the commit summary -- for the human readers.
Quoted 13 lines
stopped working on my ARM based board. The ARM architecture maintainer, Russell King, confirmed that using something like virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can be broken on other architectures as well. The author of the change, Jiri Slaby, also confirmed that his code may not work on all architectures.
The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem->dma_handle)) instead of problematic
virt_to_phys(mem->vaddr). I think this should work even if those translations would occure inaccurate for DMA addresses, since possible errors introduced by both translations, performed in opposite directions, should compensate.
Quoted 3 lines
Tested on ARM OMAP1 based Amstrad Delta board.
Signed-off-by Janusz Krzysztofik<[email protected]>
WBR, Sergei
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia ?roda 13 kwiecie? 2011 o 14:03:44 Sergei Shtylyov napisa?(a):
Quoted 9 lines
Hello.
Quoted 4 lines · Janusz Krzysztofik
After switching from
mem->dma_handletovirt_to_phys(mem->vaddr)used for obtaining page frame number passed toremap_pfn_range()(commit35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contigPlease specify the commit summary -- for the human readers.
Hi,
OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code.
Thanks,
Janusz
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Hello.
Quoted 11 lines · Janusz Krzysztofik
Quoted 6 lines
Quoted 4 lines
After switching from
mem->dma_handletovirt_to_phys(mem->vaddr)used for obtaining page frame number passed toremap_pfn_range()(commit35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contigPlease specify the commit summary -- for the human readers.
Hi,
OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code.
I wasn't asking you to rework your summary but to specify the summary of the
commit you've mentioned (in parens).
Quoted 2 lines
Thanks,
Janusz
WBR, Sergei
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia ?roda 13 kwiecie? 2011 o 19:36:30 Sergei Shtylyov napisa?(a):
Quoted 10 lines
Hello.
Quoted 7 lines · Janusz Krzysztofik
Quoted 6 lines
Quoted 5 lines
After switching from
mem->dma_handletovirt_to_phys(mem->vaddr)used for obtaining page frame number passed toremap_pfn_range()(commit35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contigPlease specify the commit summary -- for the human readers.
Quoted 7 lines
Quoted 4 lines
Hi,
OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code.I wasn't asking you to rework your summary but to specify the
summary of the commit you've mentioned (in parens).
Ah, I see. How about just reordered wording:
After commit 35d9f510b67b10338161aba6229d4f55b4000f5b (switching from mem->dma_handle to virt_to_phys(mem->vaddr) used for obtaining page frame number passed to remap_pfn_range()), ....
Do you think this would be clear enough?
Thanks,
Janusz
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia ?roda 13 kwiecie? 2011 o 23:01:55 Janusz Krzysztofik napisa?(a):
Quoted 22 lines
Dnia ?roda 13 kwiecie? 2011 o 19:36:30 Sergei Shtylyov napisa?(a):
Quoted 17 lines
Hello.
Quoted 6 lines · Janusz Krzysztofik
Quoted 6 lines
Quoted 6 lines
After switching from
mem->dma_handletovirt_to_phys(mem->vaddr)used for obtaining page frame number passed toremap_pfn_range()(commit35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contigQuoted 8 lines
Quoted 1 line
Please specify the commit summary -- for the human readers.
Hi,
OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code.Quoted 3 lines
I wasn't asking you to rework your summary but to specify the
summary of the commit you've mentioned (in parens).
Quoted 7 lines
Ah, I see. How about just reordered wording:
After commit
35d9f510b67b10338161aba6229d4f55b4000f5b(switching frommem->dma_handletovirt_to_phys(mem->vaddr)used for obtaining page frame number passed toremap_pfn_range()), ....Do you think this would be clear enough?
Oh no, I probably missed your point again.
You meant just quoting the commit original summary line, didn't you?
Thanks,
Janusz
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Hello.
Quoted 25 lines · Janusz Krzysztofik
Quoted 24 lines
Quoted 15 lines
Quoted 6 lines · Janusz Krzysztofik
Quoted 5 lines
Quoted 5 lines
After switching from
mem->dma_handletovirt_to_phys(mem->vaddr)used for obtaining page frame number passed toremap_pfn_range()(commit35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contigQuoted 7 lines
Quoted 1 line
Please specify the commit summary -- for the human readers.
Hi,
OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code.Quoted 3 lines
I wasn't asking you to rework your summary but to specify the
summary of the commit you've mentioned (in parens).
Ah, I see. How about just reordered wording:
After commit
35d9f510b67b10338161aba6229d4f55b4000f5b(switching frommem->dma_handletovirt_to_phys(mem->vaddr)used for obtaining page frame number passed toremap_pfn_range()), ....
Quoted 5 lines
Quoted 1 line
Do you think this would be clear enough?
Oh no, I probably missed your point again.
You meant just quoting the commit original summary line, didn't you?
Yes.
Quoted 2 lines
Thanks,
Janusz
WBR, Sergei
PATCH v2 1/1 V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
In reply to Janusz KrzysztofikHello.
Quoted 15 lines · Janusz Krzysztofik
Quoted 7 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
After switching from
mem->dma_handletovirt_to_phys(mem->vaddr)used for obtaining page frame number passed toremap_pfn_range()(commit35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contigPlease specify the commit summary -- for the human readers.
Quoted 7 lines
Quoted 4 lines
Hi,
OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code.I wasn't asking you to rework your summary but to specify the
summary of the commit you've mentioned (in parens).
Quoted 7 lines
Ah, I see. How about just reordered wording:
After commit
35d9f510b67b10338161aba6229d4f55b4000f5b(switching frommem->dma_handletovirt_to_phys(mem->vaddr)used for obtaining page frame number passed toremap_pfn_range()), ....Do you think this would be clear enough?
As I can see, the summary of that commit is "[media] V4L: videobuf, don't
use dma addr as physical". That's what you should have inserted.
Quoted 2 lines
Thanks,
Janusz
WBR, Sergei