* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-12 21:06 ` Janusz Krzysztofik
0 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-12 21:06 UTC (permalink / raw)
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab, linux-arm-kernel, Jiri Slaby
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.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
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(-)
--- git/drivers/media/video/videobuf-dma-contig.c.orig 2011-04-09 00:38:45.000000000 +0200
+++ git/drivers/media/video/videobuf-dma-contig.c 2011-04-12 22:36:44.000000000 +0200
@@ -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,
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-12 21:06 ` Janusz Krzysztofik
0 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-12 21:06 UTC (permalink / raw)
To: linux-arm-kernel
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.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
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(-)
--- git/drivers/media/video/videobuf-dma-contig.c.orig 2011-04-09 00:38:45.000000000 +0200
+++ git/drivers/media/video/videobuf-dma-contig.c 2011-04-12 22:36:44.000000000 +0200
@@ -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,
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-12 21:06 ` Janusz Krzysztofik
@ 2011-04-12 21:40 ` Russell King - ARM Linux
-1 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2011-04-12 21:40 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Linux Media Mailing List, Jiri Slaby, linux-arm-kernel,
Mauro Carvalho Chehab
On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote:
> 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().
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-12 21:40 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2011-04-12 21:40 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote:
> 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().
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-12 21:40 ` Russell King - ARM Linux
@ 2011-04-12 22:12 ` Theodore Kilgore
-1 siblings, 0 replies; 34+ messages in thread
From: Theodore Kilgore @ 2011-04-12 22:12 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Janusz Krzysztofik, Mauro Carvalho Chehab, Jiri Slaby,
linux-arm-kernel, Linux Media Mailing List
On Tue, 12 Apr 2011, Russell King - ARM Linux wrote:
> On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote:
> > 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().
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-12 22:12 ` Theodore Kilgore
0 siblings, 0 replies; 34+ messages in thread
From: Theodore Kilgore @ 2011-04-12 22:12 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 12 Apr 2011, Russell King - ARM Linux wrote:
> On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote:
> > 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().
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-12 21:40 ` Russell King - ARM Linux
@ 2011-04-13 10:52 ` Janusz Krzysztofik
-1 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 10:52 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Linux Media Mailing List, Jiri Slaby, linux-arm-kernel,
Mauro Carvalho Chehab
On Tue 12 Apr 2011 at 23:40:11 Russell King - ARM Linux wrote:
> On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote:
> > 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.
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.
> 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.
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-13 10:52 ` Janusz Krzysztofik
0 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 10:52 UTC (permalink / raw)
To: linux-arm-kernel
On Tue 12 Apr 2011 at 23:40:11 Russell King - ARM Linux wrote:
> On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote:
> > 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.
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.
> 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.
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-12 21:06 ` Janusz Krzysztofik
@ 2011-04-13 12:03 ` Sergei Shtylyov
-1 siblings, 0 replies; 34+ messages in thread
From: Sergei Shtylyov @ 2011-04-13 12:03 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Linux Media Mailing List, Jiri Slaby, linux-arm-kernel,
Mauro Carvalho Chehab
Hello.
On 13-04-2011 1:06, Janusz Krzysztofik wrote:
> 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
Please specify the commit summary -- for the human readers.
> 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.
> Signed-off-by: Janusz Krzysztofik<jkrzyszt@tis.icnet.pl>
WBR, Sergei
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-13 12:03 ` Sergei Shtylyov
0 siblings, 0 replies; 34+ messages in thread
From: Sergei Shtylyov @ 2011-04-13 12:03 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 13-04-2011 1:06, Janusz Krzysztofik wrote:
> 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
Please specify the commit summary -- for the human readers.
> 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.
> Signed-off-by: Janusz Krzysztofik<jkrzyszt@tis.icnet.pl>
WBR, Sergei
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-13 12:03 ` Sergei Shtylyov
@ 2011-04-13 13:11 ` Janusz Krzysztofik
-1 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 13:11 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Linux Media Mailing List, Jiri Slaby, linux-arm-kernel,
Mauro Carvalho Chehab
Dnia środa 13 kwiecień 2011 o 14:03:44 Sergei Shtylyov napisał(a):
> Hello.
>
> On 13-04-2011 1:06, Janusz Krzysztofik wrote:
> > 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
>
> 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.
Thanks,
Janusz
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-13 13:11 ` Janusz Krzysztofik
0 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 13:11 UTC (permalink / raw)
To: linux-arm-kernel
Dnia ?roda 13 kwiecie? 2011 o 14:03:44 Sergei Shtylyov napisa?(a):
> Hello.
>
> On 13-04-2011 1:06, Janusz Krzysztofik wrote:
> > 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
>
> 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.
Thanks,
Janusz
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-13 13:11 ` Janusz Krzysztofik
@ 2011-04-13 17:36 ` Sergei Shtylyov
-1 siblings, 0 replies; 34+ messages in thread
From: Sergei Shtylyov @ 2011-04-13 17:36 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Sergei Shtylyov, Linux Media Mailing List, Jiri Slaby,
linux-arm-kernel, Mauro Carvalho Chehab
Hello.
Janusz Krzysztofik wrote:
>>> 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
>> 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.
I wasn't asking you to rework your summary but to specify the summary of the
commit you've mentioned (in parens).
> Thanks,
> Janusz
WBR, Sergei
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-13 17:36 ` Sergei Shtylyov
0 siblings, 0 replies; 34+ messages in thread
From: Sergei Shtylyov @ 2011-04-13 17:36 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
Janusz Krzysztofik wrote:
>>> 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
>> 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.
I wasn't asking you to rework your summary but to specify the summary of the
commit you've mentioned (in parens).
> Thanks,
> Janusz
WBR, Sergei
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-13 10:52 ` Janusz Krzysztofik
@ 2011-04-13 18:32 ` Russell King - ARM Linux
-1 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2011-04-13 18:32 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Linux Media Mailing List, Jiri Slaby, linux-arm-kernel,
Mauro Carvalho Chehab
On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
> 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.
> 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.
So, there's no problem adding that symbol to ARM.
> > 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.
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().
> 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.
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-13 18:32 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2011-04-13 18:32 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
> 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.
> 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.
So, there's no problem adding that symbol to ARM.
> > 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.
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().
> 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.
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-13 18:32 ` Russell King - ARM Linux
@ 2011-04-13 20:56 ` Janusz Krzysztofik
-1 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 20:56 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Linux Media Mailing List, Jiri Slaby, linux-arm-kernel,
Mauro Carvalho Chehab
Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux
napisał(a):
> On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
> > 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.
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)?
> > 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.
>
> 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.
> > > 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.
>
> 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.)
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:
> 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?
> 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?
> 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().
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_.
> > 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.
>
> 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().
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-13 20:56 ` Janusz Krzysztofik
0 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 20:56 UTC (permalink / raw)
To: linux-arm-kernel
Dnia ?roda 13 kwiecie? 2011 o 20:32:31 Russell King - ARM Linux
napisa?(a):
> On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
> > 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.
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)?
> > 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.
>
> 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.
> > > 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.
>
> 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.)
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:
> 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?
> 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?
> 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().
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_.
> > 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.
>
> 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().
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-13 17:36 ` Sergei Shtylyov
@ 2011-04-13 21:01 ` Janusz Krzysztofik
-1 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 21:01 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Linux Media Mailing List, Jiri Slaby, linux-arm-kernel,
Mauro Carvalho Chehab
Dnia środa 13 kwiecień 2011 o 19:36:30 Sergei Shtylyov napisał(a):
> Hello.
>
> Janusz Krzysztofik wrote:
> >>> 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
> >>>
> >> 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.
>
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-13 21:01 ` Janusz Krzysztofik
0 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 21:01 UTC (permalink / raw)
To: linux-arm-kernel
Dnia ?roda 13 kwiecie? 2011 o 19:36:30 Sergei Shtylyov napisa?(a):
> Hello.
>
> Janusz Krzysztofik wrote:
> >>> 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
> >>>
> >> 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.
>
> 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-13 21:01 ` Janusz Krzysztofik
@ 2011-04-13 21:16 ` Janusz Krzysztofik
-1 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 21:16 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Linux Media Mailing List, Jiri Slaby, linux-arm-kernel,
Mauro Carvalho Chehab
Dnia środa 13 kwiecień 2011 o 23:01:55 Janusz Krzysztofik napisał(a):
> Dnia środa 13 kwiecień 2011 o 19:36:30 Sergei Shtylyov napisał(a):
> > Hello.
> >
> > Janusz Krzysztofik wrote:
> > >>> 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
> > >>>
> > >> 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.
> > >
> > 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?
Oh no, I probably missed your point again.
You meant just quoting the commit original summary line, didn't you?
Thanks,
Janusz
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-13 21:16 ` Janusz Krzysztofik
0 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 21:16 UTC (permalink / raw)
To: linux-arm-kernel
Dnia ?roda 13 kwiecie? 2011 o 23:01:55 Janusz Krzysztofik napisa?(a):
> Dnia ?roda 13 kwiecie? 2011 o 19:36:30 Sergei Shtylyov napisa?(a):
> > Hello.
> >
> > Janusz Krzysztofik wrote:
> > >>> 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
> > >>>
> > >> 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.
> > >
> > 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?
Oh no, I probably missed your point again.
You meant just quoting the commit original summary line, didn't you?
Thanks,
Janusz
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-13 20:56 ` Janusz Krzysztofik
@ 2011-04-13 22:00 ` Russell King - ARM Linux
-1 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2011-04-13 22:00 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Linux Media Mailing List, Jiri Slaby, linux-arm-kernel,
Mauro Carvalho Chehab
On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote:
> Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux
> napisał(a):
> > On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
> > > 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.
>
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-13 22:00 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2011-04-13 22:00 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote:
> Dnia ?roda 13 kwiecie? 2011 o 20:32:31 Russell King - ARM Linux
> napisa?(a):
> > On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
> > > 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.
>
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-13 22:00 ` Russell King - ARM Linux
@ 2011-04-13 22:43 ` Janusz Krzysztofik
-1 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 22:43 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Linux Media Mailing List, Jiri Slaby, linux-arm-kernel,
Mauro Carvalho Chehab
Dnia czwartek 14 kwiecień 2011 o 00:00:08 Russell King - ARM Linux
napisał(a):
> On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote:
> > Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux
> >
> > napisał(a):
> > > On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik
wrote:
> > > > 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.
> >
> > 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.
Hard to deny with only me having actually tested this dirty hack on one
single board :)
Thanks for your support,
Janusz
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-13 22:43 ` Janusz Krzysztofik
0 siblings, 0 replies; 34+ messages in thread
From: Janusz Krzysztofik @ 2011-04-13 22:43 UTC (permalink / raw)
To: linux-arm-kernel
Dnia czwartek 14 kwiecie? 2011 o 00:00:08 Russell King - ARM Linux
napisa?(a):
> On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote:
> > Dnia ?roda 13 kwiecie? 2011 o 20:32:31 Russell King - ARM Linux
> >
> > napisa?(a):
> > > On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik
wrote:
> > > > 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.
> >
> > 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.
Hard to deny with only me having actually tested this dirty hack on one
single board :)
Thanks for your support,
Janusz
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-13 21:01 ` Janusz Krzysztofik
@ 2011-04-14 11:17 ` Sergei Shtylyov
-1 siblings, 0 replies; 34+ messages in thread
From: Sergei Shtylyov @ 2011-04-14 11:17 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Sergei Shtylyov, Linux Media Mailing List, Jiri Slaby,
linux-arm-kernel, Mauro Carvalho Chehab
Hello.
On 14-04-2011 1:01, Janusz Krzysztofik wrote:
>>>>> 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
>>>> 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.
>> 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?
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.
> Thanks,
> Janusz
WBR, Sergei
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-14 11:17 ` Sergei Shtylyov
0 siblings, 0 replies; 34+ messages in thread
From: Sergei Shtylyov @ 2011-04-14 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 14-04-2011 1:01, Janusz Krzysztofik wrote:
>>>>> 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
>>>> 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.
>> 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?
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.
> Thanks,
> Janusz
WBR, Sergei
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-13 21:16 ` Janusz Krzysztofik
@ 2011-04-15 12:25 ` Sergei Shtylyov
-1 siblings, 0 replies; 34+ messages in thread
From: Sergei Shtylyov @ 2011-04-15 12:25 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Sergei Shtylyov, Linux Media Mailing List, Jiri Slaby,
linux-arm-kernel, Mauro Carvalho Chehab
Hello.
On 14-04-2011 1:16, Janusz Krzysztofik wrote:
>>> Janusz Krzysztofik wrote:
>>>>>> 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
>>>>> 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.
>>> 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?
> Oh no, I probably missed your point again.
> You meant just quoting the commit original summary line, didn't you?
Yes.
> Thanks,
> Janusz
WBR, Sergei
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-15 12:25 ` Sergei Shtylyov
0 siblings, 0 replies; 34+ messages in thread
From: Sergei Shtylyov @ 2011-04-15 12:25 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 14-04-2011 1:16, Janusz Krzysztofik wrote:
>>> Janusz Krzysztofik wrote:
>>>>>> 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
>>>>> 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.
>>> 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?
> Oh no, I probably missed your point again.
> You meant just quoting the commit original summary line, didn't you?
Yes.
> Thanks,
> Janusz
WBR, Sergei
^ permalink raw reply [flat|nested] 34+ messages in thread
* [REVERT] Re: V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-13 22:00 ` Russell King - ARM Linux
@ 2011-04-19 6:08 ` Jiri Slaby
-1 siblings, 0 replies; 34+ messages in thread
From: Jiri Slaby @ 2011-04-19 6:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Russell King - ARM Linux, Janusz Krzysztofik,
Linux Media Mailing List, linux-arm-kernel,
Mauro Carvalho Chehab, Jiri Slaby
On 04/14/2011 12:00 AM, Russell King - ARM Linux wrote:
> On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote:
>> Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux
>> napisał(a):
>>> On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
>>>> 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.
>>
>> 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.
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 <jslaby@suse.cz>
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,
--
js
suse labs
^ permalink raw reply [flat|nested] 34+ messages in thread
* [REVERT] Re: V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-19 6:08 ` Jiri Slaby
0 siblings, 0 replies; 34+ messages in thread
From: Jiri Slaby @ 2011-04-19 6:08 UTC (permalink / raw)
To: linux-arm-kernel
On 04/14/2011 12:00 AM, Russell King - ARM Linux wrote:
> On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote:
>> Dnia ?roda 13 kwiecie? 2011 o 20:32:31 Russell King - ARM Linux
>> napisa?(a):
>>> On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
>>>> 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.
>>
>> 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.
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 <jslaby@suse.cz>
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,
--
js
suse labs
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [REVERT] Re: V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
2011-04-19 6:08 ` Jiri Slaby
@ 2011-04-19 12:37 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2011-04-19 12:37 UTC (permalink / raw)
To: Jiri Slaby
Cc: Linus Torvalds, Russell King - ARM Linux, Janusz Krzysztofik,
Linux Media Mailing List, linux-arm-kernel, Jiri Slaby
Em 19-04-2011 03:08, Jiri Slaby escreveu:
> On 04/14/2011 12:00 AM, Russell King - ARM Linux wrote:
>> On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote:
>>> Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux
>>> napisał(a):
>>>> On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
>>>>> 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.
>>>
>>> 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.
>
> 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 <jslaby@suse.cz>
> Date: Mon Feb 28 06:37:02 2011 -0300
It seems the better option for now.
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>
> [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,
^ permalink raw reply [flat|nested] 34+ messages in thread
* [REVERT] Re: V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
@ 2011-04-19 12:37 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 34+ messages in thread
From: Mauro Carvalho Chehab @ 2011-04-19 12:37 UTC (permalink / raw)
To: linux-arm-kernel
Em 19-04-2011 03:08, Jiri Slaby escreveu:
> On 04/14/2011 12:00 AM, Russell King - ARM Linux wrote:
>> On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote:
>>> Dnia ?roda 13 kwiecie? 2011 o 20:32:31 Russell King - ARM Linux
>>> napisa?(a):
>>>> On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
>>>>> 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.
>>>
>>> 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.
>
> 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 <jslaby@suse.cz>
> Date: Mon Feb 28 06:37:02 2011 -0300
It seems the better option for now.
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>
> [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,
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2011-04-19 12:38 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-12 21:06 [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM Janusz Krzysztofik
2011-04-12 21:06 ` Janusz Krzysztofik
2011-04-12 21:40 ` Russell King - ARM Linux
2011-04-12 21:40 ` Russell King - ARM Linux
2011-04-12 22:12 ` Theodore Kilgore
2011-04-12 22:12 ` Theodore Kilgore
2011-04-13 10:52 ` Janusz Krzysztofik
2011-04-13 10:52 ` Janusz Krzysztofik
2011-04-13 18:32 ` Russell King - ARM Linux
2011-04-13 18:32 ` Russell King - ARM Linux
2011-04-13 20:56 ` Janusz Krzysztofik
2011-04-13 20:56 ` Janusz Krzysztofik
2011-04-13 22:00 ` Russell King - ARM Linux
2011-04-13 22:00 ` Russell King - ARM Linux
2011-04-13 22:43 ` Janusz Krzysztofik
2011-04-13 22:43 ` Janusz Krzysztofik
2011-04-19 6:08 ` [REVERT] " Jiri Slaby
2011-04-19 6:08 ` Jiri Slaby
2011-04-19 12:37 ` Mauro Carvalho Chehab
2011-04-19 12:37 ` Mauro Carvalho Chehab
2011-04-13 12:03 ` [PATCH 2.6.39 v2] " Sergei Shtylyov
2011-04-13 12:03 ` Sergei Shtylyov
2011-04-13 13:11 ` Janusz Krzysztofik
2011-04-13 13:11 ` Janusz Krzysztofik
2011-04-13 17:36 ` Sergei Shtylyov
2011-04-13 17:36 ` Sergei Shtylyov
2011-04-13 21:01 ` Janusz Krzysztofik
2011-04-13 21:01 ` Janusz Krzysztofik
2011-04-13 21:16 ` Janusz Krzysztofik
2011-04-13 21:16 ` Janusz Krzysztofik
2011-04-15 12:25 ` Sergei Shtylyov
2011-04-15 12:25 ` Sergei Shtylyov
2011-04-14 11:17 ` Sergei Shtylyov
2011-04-14 11:17 ` Sergei Shtylyov
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.