Fwd: [PATCH v2] media: uvc_driver: add NO-MMU arch support
-- Forwarded message --
From: Bob Liu lliu...@gmail.com
Date: Fri, Apr 8, 2011 at 7:16 PM
Subject: [PATCH v2] media: uvc_driver: add NO-MMU arch support
To: linux-ker...@vger.kernel.org
Cc: mche...@redhat.com, hverk...@xs4all.nl,
laurent.pinch...@ideasonboard.com,
sakari.ai...@maxwell.research.nokia.com, martin_ru...@logitech.com,
ja...@redhat.com, t...@kernel.org, a...@arndb.de, fweis...@gmail.com,
ag...@denx.de, gre...@suse.de, Bob Liu lliu...@gmail.com
UVC driver used to have partial no-mmu arch support, but it's removed by
commit c29fcff3daafbf46d64a543c1950bbd206ad8c1c.
This patch added them back and expanded to fully support no-mmu arch, so that
uvc cameras can be used on no-mmu platforms like Blackfin.
Signed-off-by: Bob Liu lliu...@gmail.com
---
drivers/media/video/uvc/uvc_queue.c | 47 +++
drivers/media/video/uvc/uvc_v4l2.c | 13 +
drivers/media/video/uvc/uvcvideo.h | 6
drivers/media/video/v4l2-dev.c | 18 +
include/media/v4l2-dev.h | 2 +
5 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_queue.c
b/drivers/media/video/uvc/uvc_queue.c
index f14581b..e505afe 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -424,6 +424,7 @@ int uvc_queue_mmap(struct uvc_video_queue *queue,
struct vm_area_struct *vma)
break;
}
+#ifdef CONFIG_MMU
if (i == queue-count || size != queue-buf_size) {
ret = -EINVAL;
goto done;
@@ -445,6 +446,20 @@ int uvc_queue_mmap(struct uvc_video_queue *queue,
struct vm_area_struct *vma)
addr += PAGE_SIZE;
size -= PAGE_SIZE;
}
+#else
+ if (i == queue-count ||
+ PAGE_ALIGN(size) != queue-buf_size) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ /* documentation/nommu-mmap.txt */
+ vma-vm_flags |= VM_IO | VM_MAYSHARE;
+
+ addr = (unsigned long)queue-mem + buffer-buf.m.offset;
+ vma-vm_start = addr;
+ vma-vm_end = addr + queue-buf_size;
+#endif
vma-vm_ops = uvc_vm_ops;
vma-vm_private_data = buffer;
@@ -489,6 +504,38 @@ done:
}
/*
+ * Get unmapped area.
+ *
+ * NO-MMU arch need this function to make mmap() work correctly.
+ */
+unsigned long uvc_queue_get_unmapped_area(struct uvc_video_queue *queue,
+ unsigned long addr, unsigned long len, unsigned long pgoff)
+{
+ struct uvc_buffer *buffer;
+ unsigned int i;
+ int ret = 0;
+
+ mutex_lock(queue-mutex);
+ for (i = 0; i queue-count; ++i) {
+ buffer = queue-buffer[i];
+ if ((buffer-buf.m.offset PAGE_SHIFT) == pgoff)
+ break;
+ }
+
+ if (i == queue-count ||
+ PAGE_ALIGN(len) != queue-buf_size) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ addr = (unsigned long)queue-mem + buffer-buf.m.offset;
+ ret = addr;
+done:
+ mutex_unlock(queue-mutex);
+ return ret;
+}
+
+/*
* Enable or disable the video buffers queue.
*
* The queue must be enabled before starting video acquisition and must be
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index 9005a8d..9efab61 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -1081,6 +1081,18 @@ static unsigned int uvc_v4l2_poll(struct file
*file, poll_table *wait)
return uvc_queue_poll(stream-queue, file, wait);
}
+static unsigned long uvc_v4l2_get_unmapped_area(struct file *file,
+ unsigned long addr, unsigned long len, unsigned long pgoff,
+ unsigned long flags)
+{
+ struct uvc_fh *handle = file-private_data;
+ struct uvc_streaming *stream = handle-stream;
+
+ uvc_trace(UVC_TRACE_CALLS, uvc_v4l2_get_unmapped_area\n);
+
+ return uvc_queue_get_unmapped_area(stream-queue, addr, len, pgoff);
+}
+
const struct v4l2_file_operations uvc_fops = {
.owner = THIS_MODULE,
.open = uvc_v4l2_open,
@@ -1089,5 +1101,6 @@ const struct v4l2_file_operations uvc_fops = {
.read = uvc_v4l2_read,
.mmap = uvc_v4l2_mmap,
.poll = uvc_v4l2_poll,
+ .get_unmapped_area = uvc_v4l2_get_unmapped_area,
};
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index 45f01e7..48a2378 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -580,6 +580,12 @@ extern int uvc_queue_mmap(struct uvc_video_queue *queue,
struct vm_area_struct *vma);
extern unsigned int uvc_queue_poll(struct uvc_video_queue *queue,
struct file *file, poll_table *wait);
+#ifdef CONFIG_MMU
+#define uvc_queue_get_unmapped_area NULL
+#else
+extern unsigned long
Re: WinTV 1400 broken with recent versions?
I have a WinTV 1200 card that has this exact issue. Have you made any new discoveries or progress? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] tm6000: add mts parameter
Am 19.04.2011 23:21, schrieb Mauro Carvalho Chehab:
Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu:
From: Stefan Ringelstefan.rin...@arcor.de
add mts parameter
Stefan,
The MTS config depends on the specific board design (generally present on
mono NTSC cards). So, it should be inside the cards struct, and not
provided as an userspace parameter.
Mauro.
No. It wrong. I think edge board must work under all region and TV
standards and if I set MTS, it doesn't work in Germany (PAL_BG and
DVB-T). The best is to set outside region specific params.
.
Signed-off-by: Stefan Ringelstefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 146c7e8..eef58da 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -61,6 +61,10 @@ module_param_array(card, int, NULL, 0444);
static unsigned long tm6000_devused;
+static unsigned int xc2028_mts;
+module_param(xc2028_mts, int, 0644);
+MODULE_PARM_DESC(xc2028_mts, enable mts firmware (xc2028/3028 only));
+
struct tm6000_board {
char*name;
@@ -685,6 +689,9 @@ static void tm6000_config_tuner(struct tm6000_core *dev)
ctl.demod = XC3028_FE_ZARLINK456;
ctl.vhfbw7 = 1;
ctl.uhfbw8 = 1;
+ if (xc2028_mts)
+ ctl.mts = 1;
+
xc2028_cfg.tuner = TUNER_XC2028;
xc2028_cfg.priv =ctl;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] tm6000: add audio mode parameter
Am 19.04.2011 23:26, schrieb Mauro Carvalho Chehab:
Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu:
From: Stefan Ringelstefan.rin...@arcor.de
add audio mode parameter
Why we need a parameter for it? It should be determined based on
the standard.
tm6010 has a sif decoder, and I think if auto detect doesn't work, use
can set the audio standard, which it has in your region. Or it's better
if users can see image but can hear audio?
Signed-off-by: Stefan Ringelstefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-stds.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-stds.c
b/drivers/staging/tm6000/tm6000-stds.c
index da3e51b..a9e1921 100644
--- a/drivers/staging/tm6000/tm6000-stds.c
+++ b/drivers/staging/tm6000/tm6000-stds.c
@@ -22,12 +22,17 @@
#include tm6000.h
#include tm6000-regs.h
+static unsigned int tm6010_a_mode;
+module_param(tm6010_a_mode, int, 0644);
+MODULE_PARM_DESC(tm6010_a_mode, set sif audio mode (tm6010 only));
+
struct tm6000_reg_settings {
unsigned char req;
unsigned char reg;
unsigned char value;
};
+/* must be updated */
enum tm6000_audio_std {
BG_NICAM,
BTSC,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] tm6000: add dtv78 parameter
Am 19.04.2011 23:22, schrieb Mauro Carvalho Chehab:
Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu:
From: Stefan Ringelstefan.rin...@arcor.de
add dtv78 parameter
The dtv78 entry is a hack meant for card usage in Australia, that
speeds up channel detection there. Again, it should be specified
only when needed, and at per-board basis.
I have test and auto detect doesn't work right. That is also region
specific staff and it's better to set outside. In other words in Germany
it must set this param and in other country, which use only 7MHz or 8MHz
it doesn't set (i.e. Australia).
Signed-off-by: Stefan Ringelstefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index eef58da..cf2e76c 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -65,6 +65,9 @@ static unsigned int xc2028_mts;
module_param(xc2028_mts, int, 0644);
MODULE_PARM_DESC(xc2028_mts, enable mts firmware (xc2028/3028 only));
+static unsigned int xc2028_dtv78;
+module_param(xc2028_dtv78, int, 0644);
+MODULE_PARM_DESC(xc2028_dtv78, enable dualband config (xc2028/3028 only));
struct tm6000_board {
char*name;
@@ -687,8 +690,12 @@ static void tm6000_config_tuner(struct tm6000_core *dev)
ctl.read_not_reliable = 0;
ctl.msleep = 10;
ctl.demod = XC3028_FE_ZARLINK456;
- ctl.vhfbw7 = 1;
- ctl.uhfbw8 = 1;
+
+ if (xc2028_dtv78) {
+ ctl.vhfbw7 = 1;
+ ctl.uhfbw8 = 1;
+ }
+
if (xc2028_mts)
ctl.mts = 1;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH v2] media: uvc_driver: add NO-MMU arch support
On Wed, Apr 20, 2011 at 02:02:41PM +0800, Bob Liu wrote:
-- Forwarded message --
Forwarding broke tabs.
@@ -445,6 +446,20 @@ int uvc_queue_mmap(struct uvc_video_queue *queue,
struct vm_area_struct *vma)
addr += PAGE_SIZE;
size -= PAGE_SIZE;
}
+#else
+ if (i == queue-count ||
+ PAGE_ALIGN(size) != queue-buf_size) {
Why do you need to round up size on nommu?
+ ret = -EINVAL;
+ goto done;
+ }
+
+ /* documentation/nommu-mmap.txt */
I don't see where Documentation/nommu-mmap.txt provides any information
on the following line(s).
+ vma-vm_flags |= VM_IO | VM_MAYSHARE;
+
+ addr = (unsigned long)queue-mem + buffer-buf.m.offset;
+ vma-vm_start = addr;
+ vma-vm_end = addr + queue-buf_size;
You don't need to do this here. vm_start and vm_end have already been
modified like this by do_mmap_pgoff after get_unmapped_area had been
called.
+#endif
vma-vm_ops = uvc_vm_ops;
vma-vm_private_data = buffer;
@@ -489,6 +504,38 @@ done:
}
/*
+ * Get unmapped area.
+ *
+ * NO-MMU arch need this function to make mmap() work correctly.
+ */
+unsigned long uvc_queue_get_unmapped_area(struct uvc_video_queue *queue,
+ unsigned long addr, unsigned long len, unsigned long pgoff)
+{
+ struct uvc_buffer *buffer;
+ unsigned int i;
+ int ret = 0;
ret should be an unsigned long. You later try to store a pointer in
there.
+
+ mutex_lock(queue-mutex);
+ for (i = 0; i queue-count; ++i) {
+ buffer = queue-buffer[i];
+ if ((buffer-buf.m.offset PAGE_SHIFT) == pgoff)
+ break;
+ }
+
+ if (i == queue-count ||
+ PAGE_ALIGN(len) != queue-buf_size) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ addr = (unsigned long)queue-mem + buffer-buf.m.offset;
+ ret = addr;
+done:
+ mutex_unlock(queue-mutex);
+ return ret;
+}
+
+/*
* Enable or disable the video buffers queue.
*
* The queue must be enabled before starting video acquisition and must be
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index 9005a8d..9efab61 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -1081,6 +1081,18 @@ static unsigned int uvc_v4l2_poll(struct file
*file, poll_table *wait)
return uvc_queue_poll(stream-queue, file, wait);
}
+static unsigned long uvc_v4l2_get_unmapped_area(struct file *file,
+ unsigned long addr, unsigned long len, unsigned long pgoff,
+ unsigned long flags)
+{
+ struct uvc_fh *handle = file-private_data;
+ struct uvc_streaming *stream = handle-stream;
+
+ uvc_trace(UVC_TRACE_CALLS, uvc_v4l2_get_unmapped_area\n);
+
+ return uvc_queue_get_unmapped_area(stream-queue, addr, len, pgoff);
+}
+
const struct v4l2_file_operations uvc_fops = {
.owner = THIS_MODULE,
.open = uvc_v4l2_open,
@@ -1089,5 +1101,6 @@ const struct v4l2_file_operations uvc_fops = {
.read = uvc_v4l2_read,
.mmap = uvc_v4l2_mmap,
.poll = uvc_v4l2_poll,
+ .get_unmapped_area = uvc_v4l2_get_unmapped_area,
};
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index 45f01e7..48a2378 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -580,6 +580,12 @@ extern int uvc_queue_mmap(struct uvc_video_queue *queue,
struct vm_area_struct *vma);
extern unsigned int uvc_queue_poll(struct uvc_video_queue *queue,
struct file *file, poll_table *wait);
+#ifdef CONFIG_MMU
+#define uvc_queue_get_unmapped_area NULL
+#else
+extern unsigned long uvc_queue_get_unmapped_area(struct uvc_video_queue
*queue,
+ unsigned long addr, unsigned long len, unsigned long pgoff);
+#endif
extern int uvc_queue_allocated(struct uvc_video_queue *queue);
static inline int uvc_queue_streaming(struct uvc_video_queue *queue)
{
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
Rest looks good.
Did you change anything in the generic code or is this a plain
git revert c29fcff3daafbf46d64a543c1950bbd206ad8c1c
?
Maybe one can unify the mmu and nommu versions of uvc_queue_mmap by using
remap_vmalloc_range but IMHO the nommu versions of the remap_*_range
functions are broken and should only validate if the source and destination
addresses match.
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WinTV 1400 broken with recent versions?
Hello Ryan, i'm sorry, no. I was trying to revert patches and downgrading the kernel, but this was way more work then i thought. This problem should happen with a few other cards also, it's not dedicated to the hvr 1400. Jean On Wed, 20 Apr 2011 06:09:40 + (UTC) Ryan eekr...@eekrano.com wrote: I have a WinTV 1200 card that has this exact issue. Have you made any new discoveries or progress? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH v2] media: uvc_driver: add NO-MMU arch support
On Wed, Apr 20, 2011 at 4:59 PM, Daniel Glöckner daniel...@gmx.net wrote:
On Wed, Apr 20, 2011 at 02:02:41PM +0800, Bob Liu wrote:
-- Forwarded message --
Forwarding broke tabs.
Hi, Daniel
Thanks for your review, I will make a new patch later.
@@ -445,6 +446,20 @@ int uvc_queue_mmap(struct uvc_video_queue *queue,
struct vm_area_struct *vma)
addr += PAGE_SIZE;
size -= PAGE_SIZE;
}
+#else
+ if (i == queue-count ||
+ PAGE_ALIGN(size) != queue-buf_size) {
Why do you need to round up size on nommu?
If didn't round up, it always return -EINVAL.
I don't know why config-mmu doesn't have this problem.
I use luvcview for testing and added some print, you can see that size
always != queue-buf_size.
So we need round up.
root:/ luvcview -f yuv -s 320x240 -i 30
luvcview 0.2.4
SDL information:
Video driver: fbcon
Hardware surfaces are available (382k video memory)
Device information:
Device path: /dev/video0
Stream settings:
Frame format: YUYV
Frame size: 320x240
Fsaiz e tis 03x2f5800, align size is 0x26000, bufsize is 0x26000
size is 0x25800, align size is 0x26000, bufsize is 0x26000
Unable to map buffer: Invalid argument
Init v4L2 failed !! exit fatal
root:/
+ ret = -EINVAL;
+ goto done;
+ }
+
+ /* documentation/nommu-mmap.txt */
I don't see where Documentation/nommu-mmap.txt provides any information
on the following line(s).
I will rm it, sorry for that.
+ vma-vm_flags |= VM_IO | VM_MAYSHARE;
+
+ addr = (unsigned long)queue-mem + buffer-buf.m.offset;
+ vma-vm_start = addr;
+ vma-vm_end = addr + queue-buf_size;
You don't need to do this here. vm_start and vm_end have already been
modified like this by do_mmap_pgoff after get_unmapped_area had been
called.
will rm also.
+#endif
vma-vm_ops = uvc_vm_ops;
vma-vm_private_data = buffer;
@@ -489,6 +504,38 @@ done:
}
/*
+ * Get unmapped area.
+ *
+ * NO-MMU arch need this function to make mmap() work correctly.
+ */
+unsigned long uvc_queue_get_unmapped_area(struct uvc_video_queue *queue,
+ unsigned long addr, unsigned long len, unsigned long pgoff)
+{
+ struct uvc_buffer *buffer;
+ unsigned int i;
+ int ret = 0;
ret should be an unsigned long. You later try to store a pointer in
there.
okay.
+
+ mutex_lock(queue-mutex);
+ for (i = 0; i queue-count; ++i) {
+ buffer = queue-buffer[i];
+ if ((buffer-buf.m.offset PAGE_SHIFT) == pgoff)
+ break;
+ }
+
+ if (i == queue-count ||
+ PAGE_ALIGN(len) != queue-buf_size) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ addr = (unsigned long)queue-mem + buffer-buf.m.offset;
+ ret = addr;
+done:
+ mutex_unlock(queue-mutex);
+ return ret;
+}
+
+/*
* Enable or disable the video buffers queue.
*
* The queue must be enabled before starting video acquisition and must be
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index 9005a8d..9efab61 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -1081,6 +1081,18 @@ static unsigned int uvc_v4l2_poll(struct file
*file, poll_table *wait)
return uvc_queue_poll(stream-queue, file, wait);
}
+static unsigned long uvc_v4l2_get_unmapped_area(struct file *file,
+ unsigned long addr, unsigned long len, unsigned long pgoff,
+ unsigned long flags)
+{
+ struct uvc_fh *handle = file-private_data;
+ struct uvc_streaming *stream = handle-stream;
+
+ uvc_trace(UVC_TRACE_CALLS, uvc_v4l2_get_unmapped_area\n);
+
+ return uvc_queue_get_unmapped_area(stream-queue, addr, len, pgoff);
+}
+
const struct v4l2_file_operations uvc_fops = {
.owner = THIS_MODULE,
.open = uvc_v4l2_open,
@@ -1089,5 +1101,6 @@ const struct v4l2_file_operations uvc_fops = {
.read = uvc_v4l2_read,
.mmap = uvc_v4l2_mmap,
.poll = uvc_v4l2_poll,
+ .get_unmapped_area = uvc_v4l2_get_unmapped_area,
};
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index 45f01e7..48a2378 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -580,6 +580,12 @@ extern int uvc_queue_mmap(struct uvc_video_queue *queue,
struct vm_area_struct *vma);
extern unsigned int uvc_queue_poll(struct uvc_video_queue *queue,
struct file *file, poll_table *wait);
+#ifdef CONFIG_MMU
+#define uvc_queue_get_unmapped_area NULL
+#else
+extern unsigned long uvc_queue_get_unmapped_area(struct uvc_video_queue
*queue,
+ unsigned long addr, unsigned long len,
Re: [PATCH 1/5] tm6000: add mts parameter
Em 20-04-2011 05:14, Stefan Ringel escreveu:
Am 19.04.2011 23:21, schrieb Mauro Carvalho Chehab:
Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu:
From: Stefan Ringelstefan.rin...@arcor.de
add mts parameter
Stefan,
The MTS config depends on the specific board design (generally present on
mono NTSC cards). So, it should be inside the cards struct, and not
provided as an userspace parameter.
Mauro.
No. It wrong. I think edge board must work under all region and TV standards
and if I set MTS, it doesn't work in Germany (PAL_BG and DVB-T). The best is
to set outside region specific params.
Stefan,
Not all boards have MTS wired. Also, MTS works only for BTSC and EIAJ,
e. g. STD M/N. The SIF output works for all standards, depending of the audio
decoder capabilities, and if the SIF is properly wired. AFAIK,
tm5600/6000/tm6010
is a worldwide decoder, so if SIF is wired, it should be capable of also
decoding
BTSC, EIAJ and the other sound standards found elsewhere.
In other words, boards shipped outside NTSC or PAL-M Countries use SIF and
supports
worldwide standards. however, most boards shipped in US with xc3028 have only
MTS wired and won't work outside NTSC/PAL-M/PAL-N area (America, Japan and a few
other places).
.
Signed-off-by: Stefan Ringelstefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 146c7e8..eef58da 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -61,6 +61,10 @@ module_param_array(card, int, NULL, 0444);
static unsigned long tm6000_devused;
+static unsigned int xc2028_mts;
+module_param(xc2028_mts, int, 0644);
+MODULE_PARM_DESC(xc2028_mts, enable mts firmware (xc2028/3028 only));
+
struct tm6000_board {
char*name;
@@ -685,6 +689,9 @@ static void tm6000_config_tuner(struct tm6000_core *dev)
ctl.demod = XC3028_FE_ZARLINK456;
ctl.vhfbw7 = 1;
ctl.uhfbw8 = 1;
+if (xc2028_mts)
+ctl.mts = 1;
+
xc2028_cfg.tuner = TUNER_XC2028;
xc2028_cfg.priv =ctl;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v18 08/13] davinci: eliminate use of IO_ADDRESS() on sysmod
On Tue, Apr 05, 2011 at 16:28:33, Nori, Sekhar wrote: Hi Manju, On Sat, Apr 02, 2011 at 15:13:17, Hadli, Manjunath wrote: Current devices.c file has a number of instances where IO_ADDRESS() is used for system module register access. Eliminate this in favor of a ioremap() based access. Consequent to this, a new global pointer davinci_sysmodbase has been introduced which gets initialized during the initialization of each relevant SoC Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Sekhar Nori nsek...@ti.com --- diff --git a/arch/arm/mach-davinci/include/mach/hardware.h b/arch/arm/mach-davinci/include/mach/hardware.h index 414e0b9..2a6b560 100644 --- a/arch/arm/mach-davinci/include/mach/hardware.h +++ b/arch/arm/mach-davinci/include/mach/hardware.h @@ -21,6 +21,12 @@ */ #define DAVINCI_SYSTEM_MODULE_BASE0x01C4 +#ifndef __ASSEMBLER__ +extern void __iomem *davinci_sysmodbase; +#define DAVINCI_SYSMODULE_VIRT(x) (davinci_sysmodbase + (x)) +void davinci_map_sysmod(void); +#endif Russell has posted[1] that the hardware.h file should not be polluted with platform private stuff like this. Your patch 7/13 actually helped towards that goal, but this one takes us back. This patch cannot be used in the current form. Currently there are separate header files for dm644x, dm355, dm646x and dm365. I would like to start by removing unnecessary code from these files and trying to consolidate them into a single file. Done. I have consolidated all the headers for DM6446, Dm6467, DM365 and DM355 into a single header as per your suggestion. Example, the EMAC base address definitions in dm365.h should be moved into dm365.c. Similarly, there is a lot of VPIF specific stuff in dm646x.h which is not really specific to dm646x.h and so should probably be moved to include/media/ or arch/arm/mach-davinci/include/mach/vpif.h Done. Once consolidated into a single file, davinci_sysmodbase can be moved into that file. Done. Also, Russell has said[2] that at least for this merge window only consolidation and bug fixes will go through his tree. This means that as far as mach-davinci is concerned, the clean-up part of this series can go to 2.6.40 - but not the stuff which adds new support. Thanks, Sekhar [1] http://www.spinics.net/lists/arm-kernel/msg120410.html [2] http://www.spinics.net/lists/arm-kernel/msg120606.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] tm6000: add mts parameter
Am 20.04.2011 14:37, schrieb Mauro Carvalho Chehab:
Em 20-04-2011 05:14, Stefan Ringel escreveu:
Am 19.04.2011 23:21, schrieb Mauro Carvalho Chehab:
Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu:
From: Stefan Ringelstefan.rin...@arcor.de
add mts parameter
Stefan,
The MTS config depends on the specific board design (generally present on
mono NTSC cards). So, it should be inside the cards struct, and not
provided as an userspace parameter.
Mauro.
No. It wrong. I think edge board must work under all region and TV standards
and if I set MTS, it doesn't work in Germany (PAL_BG and DVB-T). The best is to
set outside region specific params.
Stefan,
Not all boards have MTS wired.
standard option that param is not auto.
MTS = 0 or not set means load firmware without MTS.
MTS = 1 means load firmware with MTS.
That means, if you MTS then add a param MTS=1.
Have you other method to detect norm BTSC and EIAJ and set it? I have
not that.
Also, MTS works only for BTSC and EIAJ,
e. g. STD M/N. The SIF output works for all standards, depending of the audio
decoder capabilities, and if the SIF is properly wired. AFAIK,
tm5600/6000/tm6010
is a worldwide decoder, so if SIF is wired, it should be capable of also
decoding
BTSC, EIAJ and the other sound standards found elsewhere.
In other words, boards shipped outside NTSC or PAL-M Countries use SIF and
supports
worldwide standards. however, most boards shipped in US with xc3028 have only
MTS wired and won't work outside NTSC/PAL-M/PAL-N area (America, Japan and a few
other places).
Which board is only MTS?
Which board is only no MTS?
Which board will both?
.
Signed-off-by: Stefan Ringelstefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 146c7e8..eef58da 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -61,6 +61,10 @@ module_param_array(card, int, NULL, 0444);
static unsigned long tm6000_devused;
+static unsigned int xc2028_mts;
+module_param(xc2028_mts, int, 0644);
+MODULE_PARM_DESC(xc2028_mts, enable mts firmware (xc2028/3028 only));
+
struct tm6000_board {
char*name;
@@ -685,6 +689,9 @@ static void tm6000_config_tuner(struct tm6000_core *dev)
ctl.demod = XC3028_FE_ZARLINK456;
ctl.vhfbw7 = 1;
ctl.uhfbw8 = 1;
+if (xc2028_mts)
+ctl.mts = 1;
+
xc2028_cfg.tuner = TUNER_XC2028;
xc2028_cfg.priv =ctl;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] tm6000: add dtv78 parameter
Am 20.04.2011 14:38, schrieb Mauro Carvalho Chehab:
Em 20-04-2011 05:19, Stefan Ringel escreveu:
Am 19.04.2011 23:22, schrieb Mauro Carvalho Chehab:
Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu:
From: Stefan Ringelstefan.rin...@arcor.de
add dtv78 parameter
The dtv78 entry is a hack meant for card usage in Australia, that
speeds up channel detection there. Again, it should be specified
only when needed, and at per-board basis.
I have test and auto detect doesn't work right. That is also region
specific staff and it's better to set outside. In other words in Germany
it must set this param and in other country, which use only 7MHz or 8MHz it
doesn't set (i.e. Australia).
xc3028 has a logic to detect and work on both Australia and Europe.
If that logic is broken, we should fix it, not adding a manual
parameter for it.
It positively a bug. When I use lower band (7MHz, load DTV7 SCODE) it
doesn't work, then I go in the high band (8MHz, load DTV78, DTV8 SCODE)
and have channels and can watch TV. If I go now in the lower band (7MHz,
don't reload SCODE) it works. This effect is for me a bug.
Signed-off-by: Stefan Ringelstefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index eef58da..cf2e76c 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -65,6 +65,9 @@ static unsigned int xc2028_mts;
module_param(xc2028_mts, int, 0644);
MODULE_PARM_DESC(xc2028_mts, enable mts firmware (xc2028/3028 only));
+static unsigned int xc2028_dtv78;
+module_param(xc2028_dtv78, int, 0644);
+MODULE_PARM_DESC(xc2028_dtv78, enable dualband config (xc2028/3028 only));
struct tm6000_board {
char*name;
@@ -687,8 +690,12 @@ static void tm6000_config_tuner(struct tm6000_core *dev)
ctl.read_not_reliable = 0;
ctl.msleep = 10;
ctl.demod = XC3028_FE_ZARLINK456;
-ctl.vhfbw7 = 1;
-ctl.uhfbw8 = 1;
+
+if (xc2028_dtv78) {
+ctl.vhfbw7 = 1;
+ctl.uhfbw8 = 1;
+}
+
if (xc2028_mts)
ctl.mts = 1;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
Hello, On Tuesday, April 19, 2011 4:30 PM Arnd Bergmann wrote: That is a limitation of the current implementation. We might want to change that anyway, e.g. to handle the mali IOMMU along with yours. I believe the reason for allowing only one IOMMU type so far has been that nobody required more than one. As I mentioned, the IOMMU API is rather new and has not been ported to much variety of hardware, unlike the dma-mapping API, which does support multiple different IOMMUs in a single system. Ok. I understand. IOMMU API is quite nice abstraction of the IOMMU chip. dma-mapping API is something much more complex that creates the actual mapping for various sets of the devices. IMHO the right direction will be to create dma-mapping implementation that will be just a client of the IOMMU API. What's your opinion? Sounds good. I think we should put it into a new drivers/iommu, along with your specific iommu implementation, and then we can convert the existing ones over to use that. I see, this sounds quite reasonable. I think I finally got how this should be implemented. The only question is how a device can allocate a buffer that will be most convenient for IOMMU mapping (i.e. will require least entries to map)? IOMMU can create a contiguous mapping for ANY set of pages, but it performs much better if the pages are grouped into 64KiB or 1MiB areas. Can device allocate a buffer without mapping it into kernel space? The problem that still left to be resolved is the fact the dma_coherent_alloc() should also be able to use IOMMU. This would however trigger the problem of double mappings with different cache attributes: dma api might require to create coherent (==non-cached mappings), while all low-memory is still mapped with (super)sections as cached, what is against ARM CPU specification and might cause unpredicted behavior especially on CPUs that do speculative prefetch. Right now this problem has been ignored in dma-mappings implementation, but there have been some patches posted to resolve this by reserving some area exclusively for dma coherent mappings: http://thread.gmane.org/gmane.linux.ports.arm.kernel/100822/focus=100913 Right now I would like to postpone resolving this issue because the Samsung iommu task already became really big. Note that this also requires using dma-mapping-common.h, which we currently don't on ARM. Yes, I noticed this, shouldn't be much problem, imho. The domain really reflects the user, not the device here, which makes more sense if you think of virtual machines than of multimedia devices. I would suggest that you just use a single iommu_domain globally for all in-kernel users. There are cases where having a separate mapping for each device makes sense. It definitely increases the security and helps to find some bugs in the drivers. Getting back to our video codec - it has 2 IOMMU controllers. The codec hardware is able to address only 256MiB of space. Do you have an idea how this can be handled with dma-mapping API? The only idea that comes to my mind is to provide a second, fake 'struct device' and use it for allocations for the second IOMMU controller. Good question. How do you even decide which controller to use from the driver? I would need to understand better what you are trying to do to give a good recommendation. Both controllers are used by the hardware depending on the buffer type. For example, buffers with chroma video data are accessed by first (called 'left') memory channel, the others (with luma video data) - by the second channel (called 'right'). Each memory channel is limited to 256MiB address space and best performance is achieved when buffers are allocated in separate physical memory banks (the boards usually have 2 or more memory banks, memory is not interleaved). Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] tm6000: add mts parameter
Em 20-04-2011 11:19, Stefan Ringel escreveu: Am 20.04.2011 14:37, schrieb Mauro Carvalho Chehab: Em 20-04-2011 05:14, Stefan Ringel escreveu: Am 19.04.2011 23:21, schrieb Mauro Carvalho Chehab: Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu: From: Stefan Ringelstefan.rin...@arcor.de add mts parameter Stefan, The MTS config depends on the specific board design (generally present on mono NTSC cards). So, it should be inside the cards struct, and not provided as an userspace parameter. Mauro. No. It wrong. I think edge board must work under all region and TV standards and if I set MTS, it doesn't work in Germany (PAL_BG and DVB-T). The best is to set outside region specific params. Stefan, Not all boards have MTS wired. standard option that param is not auto. MTS = 0 or not set means load firmware without MTS. MTS = 1 means load firmware with MTS. That means, if you MTS then add a param MTS=1. Have you other method to detect norm BTSC and EIAJ and set it? I have not that. Yes. Audio standard is related to video standard. So, it is easy to map on what standards you have BTSC or EIAJ. You could find that info listed on some places, like: http://www.videouniversity.com/articles/world-wide-tv-standards http://en.wikipedia.org/wiki/BTSC and on good analog TV books. Basically, BTSC/EIAJ applies only to PAL/M, PAL/N and NTSC/M. So, if the standard is not PAL/MN, mts should always be equal to 0. We may have a patch at tuner-xc2028 for that. If standard is V4L_STD_MN, we have: For NTSC standards: if standard == V4L2_STD_NTSC_M_KR, audio is A2 (Korea) and mts should be 0. if standard == V4L2_STD_NTSC_M_JP, audio is EIAJ (Japan). All the rest use BTSC (or are mono, but the BTSC decoder is designed to be backward compatible with NTSC mono FM transmission). For PAL: V4L2_STD_PAL_M - always BTSC V4L2_STD_PAL_Nc (only Argentina) - always BTSC V4L2_STD_PAL_N (Paraguay/Uruguay) - they also use FM for audio. I think it is also BTSC. So, basically, assuming that some device could potentiallt have both SIF and MTS baseband wired and that the audio decoder is not capable of decoding EIAJ/BTSC, it makes sense to add something like this at tuner-xc2028: /* MTS is only valid for M/N standars, except in Korea */ if (!(std V4L2_STD_MN) || (std == V4L2_STD_NTSC_M_KR)) mts = 0; and, for such device, specify xc2028 with mts = 1. For devices that support only mts, it makes sense to change the supported standards to just V4L2_STD_MN. However, we cannot assume that (std V4L2_STD_MN) (std != V4L2_STD_NTSC_M_KR) is always mts, as it will depend on how xc2028/xc3028 is wired to the bridge/audio demod. Also, MTS works only for BTSC and EIAJ, e. g. STD M/N. The SIF output works for all standards, depending of the audio decoder capabilities, and if the SIF is properly wired. AFAIK, tm5600/6000/tm6010 is a worldwide decoder, so if SIF is wired, it should be capable of also decoding BTSC, EIAJ and the other sound standards found elsewhere. In other words, boards shipped outside NTSC or PAL-M Countries use SIF and supports worldwide standards. however, most boards shipped in US with xc3028 have only MTS wired and won't work outside NTSC/PAL-M/PAL-N area (America, Japan and a few other places). Which board is only MTS? Developers need to test, but, based on my experience with other xc3028/2028 devices, in general, the ones sold in US are only MTS. Which board is only no MTS? Which board will both? Except if the tm5600/tm6000 SIF decoder for BTSC/EIAJ is broken, we don't need to map the differences between only SIF and SIF + MTS. All boards sold in Europe should support SIF, so mts should be 0 for them. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP and tvp5151 driver.
Hi Laurent, On Wed, Mar 30, 2011 at 3:32 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Loïc, On Wednesday 30 March 2011 13:05:08 Loïc Akue wrote: Hi Laurent, The OMAP3 ISP should support interleaving interlaced frames, but that's not implemented in the driver. You will need to at least implement interlaced frames support in the CCDC module to report field identifiers to userspace. Are you saying that the OMAP ISP could be configured to provide some full field frames on the CCDC output? I'm looking at the ISP's TRM but I can't find anything interesting. Look at the Line-Output Control section in the OMAP3 TRM (SWPU177B, page 1201). Or is it the job of the user space application to recompose the image with the interleaved frames? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I'm using tvp5151 in DaVinci with the drivers/media/video/tvp5150.c driver with little modification to enhance v4l2 interface. It works. Now I'm moving to dm3730 and I see that evm dm3730 uses tvp514x-int.c from Arago tree, that is really different from tvp514x.c . I'm trying to understand if I need to create a tvp5150-int.c using the call v4l2_int_device_register instead of v4l2_i2c_subdev_init. The drivers/media/video/omap34xxcam.c driver calls v4l2_int_device_register and so it needs v4l2_int_device_register. Maybe you have done some modifications to drivers/media/video/tvp5150.c that I could merge with mines ? Bye, Raffaele -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] tm6000: add mts parameter
Am 20.04.2011 17:17, schrieb Mauro Carvalho Chehab: Em 20-04-2011 11:19, Stefan Ringel escreveu: Am 20.04.2011 14:37, schrieb Mauro Carvalho Chehab: Em 20-04-2011 05:14, Stefan Ringel escreveu: Am 19.04.2011 23:21, schrieb Mauro Carvalho Chehab: Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu: From: Stefan Ringelstefan.rin...@arcor.de add mts parameter Stefan, The MTS config depends on the specific board design (generally present on mono NTSC cards). So, it should be inside the cards struct, and not provided as an userspace parameter. Mauro. No. It wrong. I think edge board must work under all region and TV standards and if I set MTS, it doesn't work in Germany (PAL_BG and DVB-T). The best is to set outside region specific params. Stefan, Not all boards have MTS wired. standard option that param is not auto. MTS = 0 or not set means load firmware without MTS. MTS = 1 means load firmware with MTS. That means, if you MTS then add a param MTS=1. Have you other method to detect norm BTSC and EIAJ and set it? I have not that. Yes. Audio standard is related to video standard. So, it is easy to map on what standards you have BTSC or EIAJ. You could find that info listed on some places, like: http://www.videouniversity.com/articles/world-wide-tv-standards http://en.wikipedia.org/wiki/BTSC and on good analog TV books. Basically, BTSC/EIAJ applies only to PAL/M, PAL/N and NTSC/M. So, if the standard is not PAL/MN, mts should always be equal to 0. We may have a patch at tuner-xc2028 for that. If standard is V4L_STD_MN, we have: For NTSC standards: if standard == V4L2_STD_NTSC_M_KR, audio is A2 (Korea) and mts should be 0. if standard == V4L2_STD_NTSC_M_JP, audio is EIAJ (Japan). All the rest use BTSC (or are mono, but the BTSC decoder is designed to be backward compatible with NTSC mono FM transmission). For PAL: V4L2_STD_PAL_M - always BTSC V4L2_STD_PAL_Nc (only Argentina) - always BTSC V4L2_STD_PAL_N (Paraguay/Uruguay) - they also use FM for audio. I think it is also BTSC. So, basically, assuming that some device could potentiallt have both SIF and MTS baseband wired and that the audio decoder is not capable of decoding EIAJ/BTSC, it makes sense to add something like this at tuner-xc2028: /* MTS is only valid for M/N standars, except in Korea */ if (!(std V4L2_STD_MN) || (std == V4L2_STD_NTSC_M_KR)) mts = 0; and, for such device, specify xc2028 with mts = 1. For devices that support only mts, it makes sense to change the supported standards to just V4L2_STD_MN. However, we cannot assume that (std V4L2_STD_MN) (std != V4L2_STD_NTSC_M_KR) is always mts, as it will depend on how xc2028/xc3028 is wired to the bridge/audio demod. Is that better to use no mts parameter and always mts = 0? Also, MTS works only for BTSC and EIAJ, e. g. STD M/N. The SIF output works for all standards, depending of the audio decoder capabilities, and if the SIF is properly wired. AFAIK, tm5600/6000/tm6010 is a worldwide decoder, so if SIF is wired, it should be capable of also decoding BTSC, EIAJ and the other sound standards found elsewhere. In other words, boards shipped outside NTSC or PAL-M Countries use SIF and supports worldwide standards. however, most boards shipped in US with xc3028 have only MTS wired and won't work outside NTSC/PAL-M/PAL-N area (America, Japan and a few other places). Which board is only MTS? Developers need to test, but, based on my experience with other xc3028/2028 devices, in general, the ones sold in US are only MTS. Which board is only no MTS? Which board will both? Except if the tm5600/tm6000 SIF decoder for BTSC/EIAJ is broken, we don't need to map the differences between only SIF and SIF + MTS. All boards sold in Europe should support SIF, so mts should be 0 for them. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
On Wednesday 20 April 2011, Marek Szyprowski wrote: On Tuesday, April 19, 2011 4:30 PM Arnd Bergmann wrote: Sounds good. I think we should put it into a new drivers/iommu, along with your specific iommu implementation, and then we can convert the existing ones over to use that. I see, this sounds quite reasonable. I think I finally got how this should be implemented. The only question is how a device can allocate a buffer that will be most convenient for IOMMU mapping (i.e. will require least entries to map)? IOMMU can create a contiguous mapping for ANY set of pages, but it performs much better if the pages are grouped into 64KiB or 1MiB areas. Can device allocate a buffer without mapping it into kernel space? Not today as far as I know. You can register coherent memory per device using dma_declare_coherent_memory(), which will be used to back dma_alloc_coherent(), but I believe it is always mapped right now. This can of course be changed. The problem that still left to be resolved is the fact the dma_coherent_alloc() should also be able to use IOMMU. This would however trigger the problem of double mappings with different cache attributes: dma api might require to create coherent (==non-cached mappings), while all low-memory is still mapped with (super)sections as cached, what is against ARM CPU specification and might cause unpredicted behavior especially on CPUs that do speculative prefetch. Right now this problem has been ignored in dma-mappings implementation, but there have been some patches posted to resolve this by reserving some area exclusively for dma coherent mappings: http://thread.gmane.org/gmane.linux.ports.arm.kernel/100822/focus=100913 Right now I would like to postpone resolving this issue because the Samsung iommu task already became really big. Agreed. Getting back to our video codec - it has 2 IOMMU controllers. The codec hardware is able to address only 256MiB of space. Do you have an idea how this can be handled with dma-mapping API? The only idea that comes to my mind is to provide a second, fake 'struct device' and use it for allocations for the second IOMMU controller. Good question. How do you even decide which controller to use from the driver? I would need to understand better what you are trying to do to give a good recommendation. Both controllers are used by the hardware depending on the buffer type. For example, buffers with chroma video data are accessed by first (called 'left') memory channel, the others (with luma video data) - by the second channel (called 'right'). Each memory channel is limited to 256MiB address space and best performance is achieved when buffers are allocated in separate physical memory banks (the boards usually have 2 or more memory banks, memory is not interleaved). Ok, I see. Having one device per channel as you suggested could probably work around this, and it's at least consistent with how you'd represent IOMMUs in the device tree. It is not ideal because it makes the video driver more complex when it now has to deal with multiple struct device that it binds to, but I can't think of any nicer way either. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP and tvp5151 driver.
Hi Laurent, On Wed, Apr 20, 2011 at 5:25 PM, Raffaele Recalcati lamiapost...@gmail.com wrote: Hi Laurent, On Wed, Mar 30, 2011 at 3:32 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Loïc, On Wednesday 30 March 2011 13:05:08 Loïc Akue wrote: Hi Laurent, The OMAP3 ISP should support interleaving interlaced frames, but that's not implemented in the driver. You will need to at least implement interlaced frames support in the CCDC module to report field identifiers to userspace. Are you saying that the OMAP ISP could be configured to provide some full field frames on the CCDC output? I'm looking at the ISP's TRM but I can't find anything interesting. Look at the Line-Output Control section in the OMAP3 TRM (SWPU177B, page 1201). Or is it the job of the user space application to recompose the image with the interleaved frames? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I'm using tvp5151 in DaVinci with the drivers/media/video/tvp5150.c driver with little modification to enhance v4l2 interface. It works. Now I'm moving to dm3730 and I see that evm dm3730 uses tvp514x-int.c from Arago tree, that is really different from tvp514x.c . I'm trying to understand if I need to create a tvp5150-int.c using the call v4l2_int_device_register instead of v4l2_i2c_subdev_init. The drivers/media/video/omap34xxcam.c driver calls v4l2_int_device_register and so it needs v4l2_int_device_register. Maybe you have done some modifications to drivers/media/video/tvp5150.c that I could merge with mines ? I stop boring you with this item. I have seen in linuxtv tree the omap3isp directory. At the moment I think not to move from 2.6.32 to latest linuxtv kernel, but I keep in mind this possibility. Regards, Raffaele -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] tm6000: add mts parameter
Em 20-04-2011 12:27, Stefan Ringel escreveu: Am 20.04.2011 17:17, schrieb Mauro Carvalho Chehab: Em 20-04-2011 11:19, Stefan Ringel escreveu: Am 20.04.2011 14:37, schrieb Mauro Carvalho Chehab: Em 20-04-2011 05:14, Stefan Ringel escreveu: Am 19.04.2011 23:21, schrieb Mauro Carvalho Chehab: Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu: From: Stefan Ringelstefan.rin...@arcor.de add mts parameter Stefan, The MTS config depends on the specific board design (generally present on mono NTSC cards). So, it should be inside the cards struct, and not provided as an userspace parameter. Mauro. No. It wrong. I think edge board must work under all region and TV standards and if I set MTS, it doesn't work in Germany (PAL_BG and DVB-T). The best is to set outside region specific params. Stefan, Not all boards have MTS wired. standard option that param is not auto. MTS = 0 or not set means load firmware without MTS. MTS = 1 means load firmware with MTS. That means, if you MTS then add a param MTS=1. Have you other method to detect norm BTSC and EIAJ and set it? I have not that. Yes. Audio standard is related to video standard. So, it is easy to map on what standards you have BTSC or EIAJ. You could find that info listed on some places, like: http://www.videouniversity.com/articles/world-wide-tv-standards http://en.wikipedia.org/wiki/BTSC and on good analog TV books. Basically, BTSC/EIAJ applies only to PAL/M, PAL/N and NTSC/M. So, if the standard is not PAL/MN, mts should always be equal to 0. We may have a patch at tuner-xc2028 for that. If standard is V4L_STD_MN, we have: For NTSC standards: if standard == V4L2_STD_NTSC_M_KR, audio is A2 (Korea) and mts should be 0. if standard == V4L2_STD_NTSC_M_JP, audio is EIAJ (Japan). All the rest use BTSC (or are mono, but the BTSC decoder is designed to be backward compatible with NTSC mono FM transmission). For PAL: V4L2_STD_PAL_M - always BTSC V4L2_STD_PAL_Nc (only Argentina) - always BTSC V4L2_STD_PAL_N (Paraguay/Uruguay) - they also use FM for audio. I think it is also BTSC. So, basically, assuming that some device could potentiallt have both SIF and MTS baseband wired and that the audio decoder is not capable of decoding EIAJ/BTSC, it makes sense to add something like this at tuner-xc2028: /* MTS is only valid for M/N standars, except in Korea */ if (!(std V4L2_STD_MN) || (std == V4L2_STD_NTSC_M_KR)) mts = 0; and, for such device, specify xc2028 with mts = 1. For devices that support only mts, it makes sense to change the supported standards to just V4L2_STD_MN. However, we cannot assume that (std V4L2_STD_MN) (std != V4L2_STD_NTSC_M_KR) is always mts, as it will depend on how xc2028/xc3028 is wired to the bridge/audio demod. Is that better to use no mts parameter and always mts = 0? No. The better is to use a per-board mts parameter, as we have on all other drivers that use xc2028/xc3028. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Apr 20 19:01:01 CEST 2011 git hash:a4761a092fd3b6bf8b5f9cfe361670c86cdcc8ca gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tm6000: add detection based on eeprom name
On some situations, it is desired to use eeprom data to detect
the board type. This patch adds a logic for it and fixes 2 detection
issues:
1) 10Moons UT-821 uses a generic Trident ID. Other boards
also share the same ID. So, better to use an alternative way for
it;
2) Sometimes, HVR-900H is loaded with the default Trident
ID. This seems to be some hardware bug or race condition.
The new logic will only be enabled if the device is detected as
having a generic ID.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 146c7e8..6e51486 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -54,6 +54,11 @@
#define TM6010_BOARD_BEHOLD_VOYAGER_LITE 15
#define TM5600_BOARD_TERRATEC_GRABSTER 16
+#define is_generic(model) ((model == TM6000_BOARD_UNKNOWN) || \
+ (model == TM5600_BOARD_GENERIC) || \
+ (model == TM6000_BOARD_GENERIC) || \
+ (model == TM6010_BOARD_GENERIC))
+
#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
@@ -64,6 +69,9 @@ static unsigned long tm6000_devused;
struct tm6000_board {
char*name;
+ chareename[16]; /* EEPROM name */
+ unsignedeename_size;/* size of EEPROM name */
+ unsignedeename_pos; /* Position where it appears at
ROM */
struct tm6000_capabilities caps;
enumtm6000_inaudio aradio;
@@ -139,6 +147,9 @@ struct tm6000_board tm6000_boards[] = {
[TM5600_BOARD_10MOONS_UT821] = {
.name = 10Moons UT 821,
.tuner_type = TUNER_XC2028,
+ .eename = { '1', '0', 'M', 'O', 'O', 'N', 'S', '5', '6',
'0', '0', 0xff, 0x45, 0x5b},
+ .eename_size = 14,
+ .eename_pos = 0x14,
.type = TM5600,
.tuner_addr = 0xc2 1,
.caps = {
@@ -205,6 +216,9 @@ struct tm6000_board tm6000_boards[] = {
},
[TM6010_BOARD_HAUPPAUGE_900H] = {
.name = Hauppauge WinTV HVR-900H / WinTV USB2-Stick,
+ .eename = { 'H', 0, 'V', 0, 'R', 0, '9', 0, '0', 0, '0',
0, 'H', 0 },
+ .eename_size = 14,
+ .eename_pos = 0x42,
.tuner_type = TUNER_XC2028, /* has a XC3028 */
.tuner_addr = 0xc2 1,
.demod_addr = 0x1e 1,
@@ -370,7 +384,7 @@ struct tm6000_board tm6000_boards[] = {
/* table of devices that work with this driver */
struct usb_device_id tm6000_id_table[] = {
- { USB_DEVICE(0x6000, 0x0001), .driver_info = TM5600_BOARD_10MOONS_UT821
},
+ { USB_DEVICE(0x6000, 0x0001), .driver_info = TM5600_BOARD_GENERIC },
{ USB_DEVICE(0x6000, 0x0002), .driver_info = TM6010_BOARD_GENERIC },
{ USB_DEVICE(0x06e1, 0xf332), .driver_info =
TM6000_BOARD_ADSTECH_DUAL_TV },
{ USB_DEVICE(0x14aa, 0x0620), .driver_info =
TM6000_BOARD_FREECOM_AND_SIMILAR },
@@ -729,16 +743,10 @@ static void tm6000_config_tuner(struct tm6000_core *dev)
}
}
-static int tm6000_init_dev(struct tm6000_core *dev)
+static int fill_board_specific_data(struct tm6000_core *dev)
{
- struct v4l2_frequency f;
- int rc = 0;
-
- mutex_init(dev-lock);
+ int rc;
- mutex_lock(dev-lock);
-
- /* Initializa board-specific data */
dev-dev_type = tm6000_boards[dev-model].type;
dev-tuner_type = tm6000_boards[dev-model].tuner_type;
dev-tuner_addr = tm6000_boards[dev-model].tuner_addr;
@@ -756,16 +764,80 @@ static int tm6000_init_dev(struct tm6000_core *dev)
/* initialize hardware */
rc = tm6000_init(dev);
if (rc 0)
- goto err;
+ return rc;
rc = v4l2_device_register(dev-udev-dev, dev-v4l2_dev);
if (rc 0)
- goto err;
+ return rc;
- /* register i2c bus */
- rc = tm6000_i2c_register(dev);
- if (rc 0)
- goto err;
+ /* initialize hardware */
+ rc = tm6000_init(dev);
+
+ return rc;
+}
+
+
+static void use_alternative_detection_method(struct tm6000_core *dev)
+{
+ int i, model = -1;
+
+ if (!dev-eedata_size)
+ return;
+
+ for (i = 0; i ARRAY_SIZE(tm6000_boards); i++) {
+ if (!tm6000_boards[i].eename_size)
+ continue;
+ if (dev-eedata_size tm6000_boards[i].eename_pos +
+ tm6000_boards[i].eename_size)
+ continue;
+
+ if (!memcmp(dev-eedata[tm6000_boards[i].eename_pos],
+ tm6000_boards[i].eename,
+
[PATCH v3] media:uvc_driver: add uvc support on no-mmu arch
UVC driver used to have partial no-mmu arch support, but it's removed by
commit c29fcff3daafbf46d64a543c1950bbd206ad8c1c.
This patch added them back and expanded to fully support no-mmu arch, so that
uvc cameras can be used on no-mmu platforms like Blackfin.
Signed-off-by: Bob Liu lliu...@gmail.com
---
drivers/media/video/uvc/uvc_queue.c | 30 ++
drivers/media/video/uvc/uvc_v4l2.c | 13 +
drivers/media/video/uvc/uvcvideo.h |6 ++
drivers/media/video/v4l2-dev.c | 18 ++
include/media/v4l2-dev.h|2 ++
5 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_queue.c
b/drivers/media/video/uvc/uvc_queue.c
index f14581b..448a753 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -424,7 +424,11 @@ int uvc_queue_mmap(struct uvc_video_queue *queue, struct
vm_area_struct *vma)
break;
}
+#ifdef CONFIG_MMU
if (i == queue-count || size != queue-buf_size) {
+#else
+ if (i == queue-count || PAGE_ALIGN(size) != queue-buf_size) {
+#endif
ret = -EINVAL;
goto done;
}
@@ -436,6 +440,7 @@ int uvc_queue_mmap(struct uvc_video_queue *queue, struct
vm_area_struct *vma)
vma-vm_flags |= VM_IO;
addr = (unsigned long)queue-mem + buffer-buf.m.offset;
+#ifdef CONFIG_MMU
while (size 0) {
page = vmalloc_to_page((void *)addr);
if ((ret = vm_insert_page(vma, start, page)) 0)
@@ -445,6 +450,7 @@ int uvc_queue_mmap(struct uvc_video_queue *queue, struct
vm_area_struct *vma)
addr += PAGE_SIZE;
size -= PAGE_SIZE;
}
+#endif
vma-vm_ops = uvc_vm_ops;
vma-vm_private_data = buffer;
@@ -489,6 +495,30 @@ done:
}
/*
+ * Get unmapped area.
+ *
+ * NO-MMU arch need this function to make mmap() work correctly.
+ */
+unsigned long uvc_queue_get_unmapped_area(struct uvc_video_queue *queue,
+ unsigned long addr, unsigned long len, unsigned long pgoff)
+{
+ struct uvc_buffer *buffer;
+ unsigned int i;
+ int ret = 0;
+
+ mutex_lock(queue-mutex);
+ for (i = 0; i queue-count; ++i) {
+ buffer = queue-buffer[i];
+ if ((buffer-buf.m.offset PAGE_SHIFT) == pgoff)
+ break;
+ }
+ addr = (unsigned long)queue-mem + buffer-buf.m.offset;
+ ret = addr;
+ mutex_unlock(queue-mutex);
+ return ret;
+}
+
+/*
* Enable or disable the video buffers queue.
*
* The queue must be enabled before starting video acquisition and must be
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index 9005a8d..9efab61 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -1081,6 +1081,18 @@ static unsigned int uvc_v4l2_poll(struct file *file,
poll_table *wait)
return uvc_queue_poll(stream-queue, file, wait);
}
+static unsigned long uvc_v4l2_get_unmapped_area(struct file *file,
+ unsigned long addr, unsigned long len, unsigned long pgoff,
+ unsigned long flags)
+{
+ struct uvc_fh *handle = file-private_data;
+ struct uvc_streaming *stream = handle-stream;
+
+ uvc_trace(UVC_TRACE_CALLS, uvc_v4l2_get_unmapped_area\n);
+
+ return uvc_queue_get_unmapped_area(stream-queue, addr, len, pgoff);
+}
+
const struct v4l2_file_operations uvc_fops = {
.owner = THIS_MODULE,
.open = uvc_v4l2_open,
@@ -1089,5 +1101,6 @@ const struct v4l2_file_operations uvc_fops = {
.read = uvc_v4l2_read,
.mmap = uvc_v4l2_mmap,
.poll = uvc_v4l2_poll,
+ .get_unmapped_area = uvc_v4l2_get_unmapped_area,
};
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index 45f01e7..48a2378 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -580,6 +580,12 @@ extern int uvc_queue_mmap(struct uvc_video_queue *queue,
struct vm_area_struct *vma);
extern unsigned int uvc_queue_poll(struct uvc_video_queue *queue,
struct file *file, poll_table *wait);
+#ifdef CONFIG_MMU
+#define uvc_queue_get_unmapped_area NULL
+#else
+extern unsigned long uvc_queue_get_unmapped_area(struct uvc_video_queue *queue,
+ unsigned long addr, unsigned long len, unsigned long pgoff);
+#endif
extern int uvc_queue_allocated(struct uvc_video_queue *queue);
static inline int uvc_queue_streaming(struct uvc_video_queue *queue)
{
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 498e674..221e73f 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -368,6 +368,23 @@ static int v4l2_mmap(struct file *filp, struct
vm_area_struct *vm)
return ret;
}
