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
Fwd: [PATCH v2] media: uvc_driver: add NO-MMU arch support
-- Forwarded message --
From: Bob Liu
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
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
---
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 uvc_queue_get_unmapped_area(struct uv
Re: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Tue, 2011-04-19 at 13:12 -0400, Eric B Munson wrote: > On Tue, 19 Apr 2011, Andy Walls wrote: > > > > > Have you used v4l2-ctl or ivtv-tune to tune to the proper tv channel > > > (the driver defaults to US channel 4)? > > > > > > emunson@grover:~$ v4l2-ctl -F > > > Frequency: 0 (0.00 MHz) > > > emunson@grover:~$ v4l2-ctl -f 259.250 > > > Frequency set to 4148 (259.25 MHz) > > > emunson@grover:~$ v4l2-ctl -F > > > Frequency: 0 (0.00 MHz) > > > > OK, that doesn't look good. The tda18271 tuner and/or tda8290 demod > > drivers may not be working right. I looked into this. Apparently the tda18271 tuner driver doesn't report back analog frequency setting. So reading back 0.0 MHz is OK. > > I'll have to look into that later this week. > > > > BTW, Mike Krufky just submitted some patches that may be relevant: > > > > http://kernellabs.com/hg/~mkrufky/tda18271-fix > > > > I have applied these patches and I am still seeing the same problem (frequency > still report 0 after being set) and mplayer still closes immediately. I don't have those patches applied. I just tested my 74351 HVR-1600 again tonight, and analog channel 3 works for me. I don't know what to say > > > > > > > Does v4l2-ctl --log-status still show no signal present for the '843 > > > > core in the CX23418? > > > > > > Yeah, > > >[94465.349721] cx18-0 843: Video signal: not present > > > > The tuner or demod isn't tuning to a channel or getting a signal. > > > > Can you try channel 3 (61.250 MHz)? That one works for me. > > Still shows not present on channel 3. OK. Tonight was the first time I have *ever* been able to reproduce the "red screen" out of a CX23418. I am fairly sure the red screen happens because of some kernel bug or PCI bus problem that ends up corrupting the CX23418 registers responsible for configuring the CX25843 A/V core inside of the CX23418. The '843 core is responsible for digitizing the analog video, so when it stops functioning, the result is a red screen. I guess the root cause could also happen due to some thermal or power condition causes the '843 core to stop, but I think that is less likely. Anyway, when you're going to get a red screen, the '843 core will always indicate "cx18-N 843: Video signal:not present", even if there is a signal present from the analog tuner and demodulator chips. > > > > Does mplayer /dev/videoN -cache 8192 have a tv station when set to the > > > > rf analog input with v4l2-ctl? > > > > > > emunson@grover:~$ mplayer /dev/video0 -cache 8192 > > > MPlayer 1.0rc4-4.4.5 (C) 2000-2010 MPlayer Team > > > > > > Playing /dev/video0. > > > Cache fill: 0.00% (0 bytes) > > > > > > > > > Exiting... (End of file) > > > > Hmmm. I would have expected at least a black picture with snow, if not > > tuned to a channel. > > > > Does analog S-Video or Composite work? > > Unfortunately, I do not have anything I can use to test these. The card only > takes coaxial or S-Video input and I don't have any sort of S-Video cables or > converters. With new HVR-1600 from Hauppauge, an adapter for plugging a Composite RCA cable into the S-Video jack is in the box. It looks very much like the one at the end of this thread, but it is grey in color: http://www.hauppauge.co.uk/board/showthread.php?t=22115 If this is a second hand card, or one bought from e-Bay, etc. have you ever tested it in a Windows machine with the Hauppauge Windows drivers? (In other words, are you reasonably confident the card is not defective or broken.) When testing tonight, I unloaded all the drivers, performed the following commands to get verbose debugging, and saved the dmesg: # modinfo tuner # modprobe tuner debug=7 # modinfo tda8290 # modprobe tda8290 debug=7 # modinfo tda18271 # modprobe tda18271 debug=31 # modinfo cx18 # modprobe cx18 debug=255 # ivtv-tune -d /dev/video1 -c3 # v4l2-ctl -d /dev/video1 --log-status # mplayer /dev/video1 -cache 8192 I'll send you the 138 kB dmesg file off list, so you can see the messgaes generated by a functioning 73451 HVR-1600 setup. Note that the card of interest in the dmesg output was 'cx18-1'. You'll want to look to see that the TDA18271 and TDA8290 related messages look the same, to get reasonable assurance that the tuner and demodulator chip are being set up properly and repsonding. If you consistently get "cx18-N 843: Video signal: not present" in your v4l2-ctl --log-status output but the tuner chip configurations look good (i.e. closely match the debug output from my machine), then you really have a "red screen" problem versus a problem related to the analog tuner/demod chips. The "red screen" will be a tough one to track down. It's a system level issue, likely involving one or more of: 1. a kernel bug in a driver for some other hardware in your system 2. a hardware problem with your PCI chipset when the PCI bus is heavily loaded 3. a power or thermal condition that causes problems f
Re: [PATCH 3/5] tm6000: add audio mode parameter
Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu:
> From: Stefan Ringel
>
> add audio mode parameter
Why we need a parameter for it? It should be determined based on
the standard.
>
> Signed-off-by: Stefan Ringel
> ---
> 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
[GIT PULL REQ] IR additions and misc media fixes for 2.6.40
IR additions and misc minor media_tree fixes for 2.6.40. There's an input.h patch included in here, which was merged in 2.6.39-rc4, that the patch just after it depends upon, wasn't quite sure how to handle that, since it wasn't already in the staging/for_v2.6.40 branch that this is on top of... The main IR additions are the improved support for more variants of the Nuvoton Super I/O LPC integrated CIR function in nuvoton-cir and the addition of a TiVo keymap which is now used by default with the mceusb driven TiVo branded transceiver that ships in the Nero LiquidTV bundle. The following changes since commit f2dae48f7f0888fdfb978677ab0d03af468c2218: [media] gspca - kinect: New subdriver for Microsoft Kinect (2011-04-19 17:24:56 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jarod/linux-2.6-ir.git linuxtv-dev Jarod Wilson (10): rc: add tivo/nero liquidtv keymap mceusb: tivo transceiver should default to tivo keymap Input: add KEY_IMAGES specifically for AL Image Browser [media] rc: further key name standardization [media] rc/nuvoton-cir: only warn about unknown chips [media] rc/nuvoton-cir: enable CIR on w83667hg chip variant [media] mceusb: Formosa e017 device has no tx ttusb-budget: driver has a debug param, use it lirc_sasem: key debug spew off debug modparam tm6000: fix vbuf may be used uninitialized drivers/media/dvb/dvb-usb/dibusb-common.c |2 +- drivers/media/dvb/dvb-usb/m920x.c | 16 ++-- drivers/media/dvb/dvb-usb/nova-t-usb2.c|2 +- drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c | 60 ++--- drivers/media/rc/keymaps/Makefile |1 + drivers/media/rc/keymaps/rc-avermedia-cardbus.c|2 +- drivers/media/rc/keymaps/rc-imon-mce.c |2 +- drivers/media/rc/keymaps/rc-imon-pad.c |6 +- .../media/rc/keymaps/rc-kworld-plus-tv-analog.c|2 +- drivers/media/rc/keymaps/rc-rc6-mce.c |4 +- drivers/media/rc/keymaps/rc-tivo.c | 98 drivers/media/rc/mceusb.c | 16 +++- drivers/media/rc/nuvoton-cir.c | 62 ++--- drivers/media/rc/nuvoton-cir.h | 17 +++- drivers/staging/lirc/lirc_sasem.c | 13 ++- drivers/staging/tm6000/tm6000-video.c |4 +- include/linux/input.h |9 +- include/media/rc-map.h |1 + 18 files changed, 235 insertions(+), 82 deletions(-) create mode 100644 drivers/media/rc/keymaps/rc-tivo.c -- Jarod Wilson ja...@redhat.com -- 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
Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu:
> From: Stefan Ringel
>
> 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.
>
>
> Signed-off-by: Stefan Ringel
> ---
> 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
Re: [PATCH 1/5] tm6000: add mts parameter
Em 04-04-2011 17:18, stefan.rin...@arcor.de escreveu:
> From: Stefan Ringel
>
> 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.
>
>
> Signed-off-by: Stefan Ringel
> ---
> 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
Re: [GIT PATCHES FOR 2.6.40] gspca for_v2.6.40
Em 19-04-2011 16:54, Antonio Ospite escreveu: > On Tue, 19 Apr 2011 20:20:29 +0200 > Jean-Francois Moine wrote: > >> The following changes since commit >> d58307d6a1e2441ebaf2d924df4346309ff84c7d: >> >> [media] anysee: add more info about known board configs (2011-04-19 >> 10:35:37 -0300) >> >> are available in the git repository at: >> git://linuxtv.org/jfrancois/gspca.git for_v2.6.40 >> >> Antonio Ospite (2): >> Add Y10B, a 10 bpp bit-packed greyscale format. >> gspca - kinect: New subdriver for Microsoft Kinect >> > > Ah glad to see that, so there was no major concern on the code, was > there? There's just a problem that I noticed: drivers/media/video/gspca/kinect.c: In function ‘send_cmd.clone.0’: drivers/media/video/gspca/kinect.c:202: warning: the frame size of 1548 bytes is larger than 1024 bytes Please, don't do things like: + uint8_t obuf[0x400]; + uint8_t ibuf[0x200]; at the stack. Instead, put it into a per-device struct. Anyway, I've applied your patches here. Please send us a fix for it as soon as possible. Thanks, 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: [GIT PATCHES FOR 2.6.40] gspca for_v2.6.40
On Tue, 19 Apr 2011 20:20:29 +0200 Jean-Francois Moine wrote: > The following changes since commit > d58307d6a1e2441ebaf2d924df4346309ff84c7d: > > [media] anysee: add more info about known board configs (2011-04-19 > 10:35:37 -0300) > > are available in the git repository at: > git://linuxtv.org/jfrancois/gspca.git for_v2.6.40 > > Antonio Ospite (2): > Add Y10B, a 10 bpp bit-packed greyscale format. > gspca - kinect: New subdriver for Microsoft Kinect > Ah glad to see that, so there was no major concern on the code, was there? Thanks Jean-Francois, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpnTLdnOtL3H.pgp Description: PGP signature
Sensoray Model 311 Jumper settings for LiPPERT's Cool XpressRunner-GS45 SBC
Per Sensoray Model 311 ( http://www.sensoray.com/products/311.htm ) customer's request, we have tested 311 with LiPPERT's Cool XpressRunner-GS45 ( http://www.lippertembedded.com/en/lipperts-cool-xpressrunner-gs45.html ) SBC (Single Board Computer). Per customer's request and for their convenience, here, we list the Model 311's jumper setting combinations that work with the LiPPERT's Cool XpressRunner-GS45 SBC: (on Model 311) JP-8 -7 -6 -5 JP3B JP3A Slot # and INT Verified | : : :|| Slot #0 + INTA# V : | : :|: Slot #1 + INTB# V : : | ::| Slot #2 + INTC# V : : : |:: Slot #3 + INTD# V - Note:| -- close; : -- open Thanks and Best regards, Charlie X. Liu @ Sensoray Co. -Original Message- From: Charlie X. Liu [mailto:char...@sensoray.com] Sent: Tuesday, April 19, 2011 11:54 AM To: 'video4linux-l...@redhat.com' Cc: 'linux-media@vger.kernel.org' Subject: Sensoray Model 314 DIP Switch setting for LiPPERT's Cool XpressRunner-GS45 SBC Per Sensoray Model 314 ( http://www.sensoray.com/products/314.htm ) customer's request, we have tested 314 with LiPPERT's Cool XpressRunner-GS45 ( http://www.lippertembedded.com/en/lipperts-cool-xpressrunner-gs45.html ) SBC (Single Board Computer). Per customer's request and for their convenience, here, we list the Model 314's DIP switch setting combinations that work with the LiPPERT's Cool XpressRunner-GS45 SBC: (on Model 314) SW2-1 2 3 4 5 6 Slot # and INTVerified -- D D U U U D Slot #0 + INTA# V U D U U D U Slot #1 + INTB# V D U U D U U Slot #2 + INTC# V U U D U U U Slot #3 + INTD# V -- Note: D -- Down (ON); U -- Up (OFF) Best regards, Charlie X. Liu @ Sensoray Co. -- 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
Sensoray Model 314 DIP Switch setting for LiPPERT's Cool XpressRunner-GS45 SBC
Per Sensoray Model 314 ( http://www.sensoray.com/products/314.htm ) customer's request, we have tested 314 with LiPPERT's Cool XpressRunner-GS45 ( http://www.lippertembedded.com/en/lipperts-cool-xpressrunner-gs45.html ) SBC (Single Board Computer). Per customer's request and for their convenience, here, we list the Model 314's DIP switch setting combinations that work with the LiPPERT's Cool XpressRunner-GS45 SBC: (on Model 314) SW2-1 2 3 4 5 6 Slot # and INTVerified -- D D U U U D Slot #0 + INTA# V U D U U D U Slot #1 + INTB# V D U U D U U Slot #2 + INTC# V U U D U U U Slot #3 + INTD# V -- Note: D -- Down (ON); U -- Up (OFF) Best regards, Charlie X. Liu @ Sensoray Co. -- 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:Tue Apr 19 19:00:44 CEST 2011 git hash:d58307d6a1e2441ebaf2d924df4346309ff84c7d 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/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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
[GIT PATCHES FOR 2.6.40] gspca for_v2.6.40
The following changes since commit d58307d6a1e2441ebaf2d924df4346309ff84c7d: [media] anysee: add more info about known board configs (2011-04-19 10:35:37 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v2.6.40 Antonio Ospite (2): Add Y10B, a 10 bpp bit-packed greyscale format. gspca - kinect: New subdriver for Microsoft Kinect Jean-François Moine (1): gspca - zc3xx: Adjust the mc501cb exchanges Patrice Chotard (5): gspca - jeilinj: suppress workqueue gspca - jeilinj: use gspca_dev->usb_err to forward error to upper layer gspca - jeilinj: add 640*480 resolution support gspca - jeilinj: Add SPORTSCAM_DV15 camera support gspca - jeilinj: add SPORTSCAM specific controls Documentation/DocBook/media-entities.tmpl |1 + Documentation/DocBook/v4l/pixfmt-y10b.xml | 43 +++ Documentation/DocBook/v4l/pixfmt.xml |1 + Documentation/DocBook/v4l/videodev2.h.xml |3 + Documentation/video4linux/gspca.txt |1 + drivers/media/video/gspca/Kconfig |9 + drivers/media/video/gspca/Makefile|2 + drivers/media/video/gspca/jeilinj.c | 581 - drivers/media/video/gspca/kinect.c| 427 + drivers/media/video/gspca/zc3xx.c | 42 +-- include/linux/videodev2.h |3 + 11 files changed, 905 insertions(+), 208 deletions(-) create mode 100644 Documentation/DocBook/v4l/pixfmt-y10b.xml create mode 100644 drivers/media/video/gspca/kinect.c -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Tue, 19 Apr 2011, Andy Walls wrote: > On Mon, 2011-04-18 at 18:48 -0400, Eric B Munson wrote: > > On Mon, 18 Apr 2011, Andy Walls wrote: > > > > > Eric B Munson wrote: > > > > > > >On Mon, 11 Apr 2011, Eric B Munson wrote: > > > > > > > >> On Sun, 10 Apr 2011, Andy Walls wrote: > > > >> > > > >> > On Wed, 2011-04-06 at 13:28 -0400, Eric B Munson wrote: > > > >> > > On Tue, Apr 5, 2011 at 10:58 AM, Andy Walls > > > > > > > > >Is there anything else I can provide to help with this? > > > > > > Eric, > > > > > > Sorry for not getting back sooner (I've been dealing with a personal > > situation and haven't logged into my dev system for a few weeks). > > > > > > What rf analog source are you using? > > > > Sorry, very new to this, I am not sure what you are asking for here. > > I mean: analog cable, DTV Set Top Box (STB), VCR, etc. > > I have only tested the driver on analog US Broadcast Channel 3, since I > only have a DTV STB as an RF analog TV source. I am using analog cable. Cable here is about 25% digital and 75% analog. > > > > > > Have you used v4l2-ctl to ensure the tuner is set to the right tv > > standard (my changes default to NTSC-M)? > > > > emunson@grover:~$ v4l2-ctl -S > > Video Standard = 0xb000 > > NTSC-M/M-JP/M-KR > > emunson@grover:~$ v4l2-ctl -s ntsc > > Standard set to b000 > > emunson@grover:~$ v4l2-ctl -S > > Video Standard = 0xb000 > > NTSC-M/M-JP/M-KR > > > > What should the default be? NTSC-443? When I set to NTSC-443 I see > > the same behaviour as below when I try and change channels. > > NTSC-M is the default. Having it set to autodetect the US, Japanese > (-JP), or South Korean (-KR) variants is OK. > > Never use NTSC-443 as you likely will never encounter it in your life. > NTSC-443 is never broadcast over the air or cable. It is a weird > combination of NTSC video usings a PAL color subcarrier frequency. > > > > > > > Have you used v4l2-ctl or ivtv-tune to tune to the proper tv channel > > (the driver defaults to US channel 4)? > > > > emunson@grover:~$ v4l2-ctl -F > > Frequency: 0 (0.00 MHz) > > emunson@grover:~$ v4l2-ctl -f 259.250 > > Frequency set to 4148 (259.25 MHz) > > emunson@grover:~$ v4l2-ctl -F > > Frequency: 0 (0.00 MHz) > > OK, that doesn't look good. The tda18271 tuner and/or tda8290 demod > drivers may not be working right. > > I'll have to look into that later this week. > > BTW, Mike Krufky just submitted some patches that may be relevant: > > http://kernellabs.com/hg/~mkrufky/tda18271-fix > I have applied these patches and I am still seeing the same problem (frequency still report 0 after being set) and mplayer still closes immediately. > > > > > > Does v4l2-ctl --log-status still show no signal present for the '843 core > > > in the CX23418? > > > > Yeah, > >[94465.349721] cx18-0 843: Video signal: not present > > The tuner or demod isn't tuning to a channel or getting a signal. > > Can you try channel 3 (61.250 MHz)? That one works for me. Still shows not present on channel 3. > > > > > Does mplayer /dev/videoN -cache 8192 have a tv station when set to the rf > > > analog input with v4l2-ctl? > > > > emunson@grover:~$ mplayer /dev/video0 -cache 8192 > > MPlayer 1.0rc4-4.4.5 (C) 2000-2010 MPlayer Team > > > > Playing /dev/video0. > > Cache fill: 0.00% (0 bytes) > > > > > > Exiting... (End of file) > > Hmmm. I would have expected at least a black picture with snow, if not > tuned to a channel. > > Does analog S-Video or Composite work? Unfortunately, I do not have anything I can use to test these. The card only takes coaxial or S-Video input and I don't have any sort of S-Video cables or converters. Eric signature.asc Description: Digital signature
Re: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
On Tuesday 19 April 2011, Roedel, Joerg wrote: > > 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. > > The GPU IOMMUs can probably be handled in the GPU driver if they are > that different. Recent PCIe GPUs on x86 have their own IOMMUs too which > are very device specific and are handled in the device driver. I tend to disagree with this one, and would suggest that the GPUs should actually provide their own iommu_ops, even if they are the only users of these. However, this is a minor point that we don't need to worry about today. 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: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
On Tue, Apr 19, 2011 at 10:03:27AM -0400, Marek Szyprowski wrote: > 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? Definitly agreed. I plan this since some time but never found the time to implement it. In the end we can have a generic dma-ops implementation that works for all iommu-api implementations. > 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. The GPU IOMMUs can probably be handled in the GPU driver if they are that different. Recent PCIe GPUs on x86 have their own IOMMUs too which are very device specific and are handled in the device driver. Regards, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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] videobuf_pages_to_sg: sglist[0] length problem
On function videobuf_pages_to_sg the statement sg_set_page(&sglist[0], pages[0], PAGE_SIZE - offset, offset) will failed if if size is less than PAGE_SIZE. Signed-off-by: Newson Edouard http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
On Tue, Apr 19, 2011 at 10:28:39AM -0400, Arnd Bergmann wrote:
> On Tuesday 19 April 2011, Roedel, Joerg wrote:
> > On Tue, Apr 19, 2011 at 08:49:50AM -0400, Arnd Bergmann wrote:
> > > > Ok, it looks I don't fully get how this iommu.h should be used. It looks
> > > > that there can be only one instance of iommu ops registered in the
> > > > system,
> > > > so only one iommu driver can be activated. You are right that the iommu
> > > > driver has to be registered on first probe().
> > >
> > > 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.
> >
> > The current IOMMU-API interface is very simple. It delegates the
> > selection of the particular IOMMU device to the IOMMU driver. Handle
> > this selection above the IOMMU driver is a complex thing to do. We will
> > need some kind of generic IOMMU support in the device-core and
> > attach IOMMUs to device sub-trees.
> >
> > A simpler and less intrusive solution is to implement some wrapper code
> > which dispatches the IOMMU-API calls to the IOMMU driver implementation
> > required for that device.
>
> Right. We already do that for the dma-mapping API on some architectures,
> and I suppose we can consolidate the mechanism here, possibly into
> something that ends up in the common struct device rather than in
> the archdata.
The struct device solution is very much what I meant by adding this into
the device-core code :)
> > Question: Does every platform device has a different type of IOMMU? Or
> > are the IOMMUs on all of these platform devices similar enough to be
> > handled by a single driver?
>
> As Marek explained in the thread before you got on Cc, they are all the
> same, except for the graphics core (Mali) that has a different one but
> currently disables that.
Then it is no problem at all. The IOMMU driver can find out itself which
IOMMU needs to be used for which device. The x86 implementations already
do this.
> > > > For the drivers the most important are the following functions:
> > > > iommu_{attach,detach}_device(struct iommu_domain *domain, struct device
> > > > *dev);
> >
> > Right, and each driver can allocate its own domains.
>
> For the cases that use the normal dma-mapping API, I guess there only
> needs to be one domain to cover the kernel, which can then be hidden
> in the driver provides the dma_map_ops based on an iommu_ops.
Yes, for dma-api usage one domain is sufficient. But using one domain
for each device has benefits too. It reduces lock-contention on the
domain side and also increases security by isolating the devices from
each other.
> > > It's not quite how the domains are meant to be used. In the AMD IOMMU
> > > that the API is based on, any number of devices can share one domain,
> > > and devices might be able to have mappings in multiple domains.
> >
> > Yes, any number of devices can be assigned to one domain, but each
> > device only belongs to one domain at each point in time. But it is
> > possible to detach a device from one domain and attach it to another.
>
> I was thinking of the SR-IOV case, where a single hardware device is
> represented as multiple logical devices. As far as I understand, each
> logical devices can only belong to one domain, but they don't all have to
> be the same.
Well, right, the IOMMU-API makes no distinction between PF and VF. Each
function is just a pci_dev which can independently assigned to a domain.
So if 'device' means a physical card with virtual functions then yes, a
device can be attached to multiple domains, one domain per VF.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
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 Tuesday 19 April 2011, Marek Szyprowski wrote: > > > > 1. change the runtime_pm subsystem to allow it to ignore some devices > > in an easy way. > > > > 2. change the device layout if the sysmmu. If the iommu device is > > a child of the device that it is responsible for, I guess you don't > > have this problem. > > > > 3. Not represent the iommu as a device at all, just as a property > > of another device. > > Ok, we will handle this issue somehow. I consider this a minor issue and I > would like to focus on the IOMMU/dma-mapping APIs first. Yes, agreed. > > 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. Note that this also requires using dma-mapping-common.h, which we currently don't on ARM. > > 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. 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: imon: spews to dmesg
On Apr 18, 2011, at 11:06 PM, Vincent McIntyre wrote: > Hi list, > > I just (2011-04-19) upgraded to the current media_build with build.sh > commit bcfdefe9f4538abf12fca1cdb631c80e3d598026 > Author: Mauro Carvalho Chehab > Date: Sun Apr 17 08:21:25 2011 -0300 > and hit a problem. > > I have an Antec case with an LCD screen. It needs the imon driver. > The LCD screen has been working well using media_build from 2011-01-30. > > The imon kernel module now spews this at a high rate: > [ 38.532581] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.544545] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.552548] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.560560] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.568546] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.576557] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.584554] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.592558] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.600533] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.608551] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.620024] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.636034] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.652034] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > > If I stop LCDd > # /etc/init.d/LCDd stop > the spew stops. > > > I'm running on ubuntu 10.04 i386, with lcdproc 0.5.3-0ubuntu2. > $ uname -a > Linux ubuntu 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC > 2010 i686 GNU/Linux > $ modinfo imon > filename: /lib/modules/2.6.32-27-generic/kernel/drivers/media/rc/imon.ko > license:GPL > version:0.9.2 > description:Driver for SoundGraph iMON MultiMedia IR/Display > author: Jarod Wilson > srcversion: 268453AC090EFB24F487BE7 > alias: usb:v15C2p0046d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0045d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0044d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0043d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0042d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0041d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0040d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p003Fd*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p003Ed*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p003Dd*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p003Cd*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p003Bd*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p003Ad*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0039d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0038d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0037d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0036d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0035d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2p0034d*dc*dsc*dp*ic*isc*ip* > alias: usb:v15C2pFFDCd*dc*dsc*dp*ic*isc*ip* > depends:rc-core > vermagic: 2.6.32-27-generic SMP mod_unload modversions 586 > parm: debug:Debug messages: 0=no, 1=yes (default: no) (bool) > parm: display_type:Type of attached display. 0=autodetect, > 1=vfd, 2=lcd, 3=vga, 4=none (default: autodetect) (int) > parm: pad_stabilize:Apply stabilization algorithm to iMON > PAD presses in arrow key mode. 0=disable, 1=enable (default). (int) > parm: nomouse:Disable mouse input device mode when IR device > is open. 0=don't disable, 1=disable. (default: don't disable) (bool) > parm: pad_thresh:Threshold at which a pad push registers as > an arrow key in kbd mode (default: 28) (int) > > The module load looks normal: > $ dmesg|grep imon > [4.454786] imon 9-1:1.0: imon_probe: found iMON device (15c2:ffdc, intf0) > [4.454794] imon 9-1:1.0: imon_find_endpoints: found IR endpoint > [4.454794] imon 9-1:1.0: imon_find_endpoints: found display endpoint > [4.472053] imon 9-1:1.0: 0xffdc iMON LCD, MCE IR (id 0x9f) > [5.024035] Registered IR keymap rc-imon-mce > [5.024173] imon 9-1:1.0: Configuring IR receiver for MCE protocol > [5.032117] imon 9-1:1.0: Registering iMON display with sysfs > [5.032173] imon 9-1:1.0: iMON device (15c2:ffdc, intf0) on > usb<9:2> initialized > [5.032198] usbcore: registered new interface driver imon > > Then the display port is opened... > [ 38.519700] imon 9-1:1.0: display port opened > [ 38.532581] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.544545] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.552548] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.560560] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.568546] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.576557] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > [ 38.584554] imon 9-1:1.0: lcd_write: write 8 bytes to LCD > > I don't have any load options defined for the imon module. Those are almost all dev_dbg spew. This seems relevant: http://www.gossamer-threa
Re: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
On Tuesday 19 April 2011, Roedel, Joerg wrote:
> On Tue, Apr 19, 2011 at 08:49:50AM -0400, Arnd Bergmann wrote:
> > > Ok, it looks I don't fully get how this iommu.h should be used. It looks
> > > that there can be only one instance of iommu ops registered in the system,
> > > so only one iommu driver can be activated. You are right that the iommu
> > > driver has to be registered on first probe().
> >
> > 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.
>
> The current IOMMU-API interface is very simple. It delegates the
> selection of the particular IOMMU device to the IOMMU driver. Handle
> this selection above the IOMMU driver is a complex thing to do. We will
> need some kind of generic IOMMU support in the device-core and
> attach IOMMUs to device sub-trees.
>
> A simpler and less intrusive solution is to implement some wrapper code
> which dispatches the IOMMU-API calls to the IOMMU driver implementation
> required for that device.
Right. We already do that for the dma-mapping API on some architectures,
and I suppose we can consolidate the mechanism here, possibly into
something that ends up in the common struct device rather than in
the archdata.
> > > I think it might be beneficial to describe a bit more our hardware
> > > (Exynos4 platform). There are a number of multimedia blocks. Each has it's
> > > own IOMMU controller. Each IOMMU controller has his own set of hardware
> > > registers and irq. There is also a GPU unit (Mali) which has it's own
> > > IOMMU hardware, incompatible with the SYSMMU, so right now it is ignored.
> > >
> > > The multimedia blocks are modeled as platform devices and are independent
> > > of platform type (same multimedia blocks can be found on other Samsung
> > > machines, like for example s5pv210/s5pc110), see arch/arm/plat-s5p/dev-*.c
> > > and arch/arm/plat-samsung/dev-*.c.
>
> Question: Does every platform device has a different type of IOMMU? Or
> are the IOMMUs on all of these platform devices similar enough to be
> handled by a single driver?
As Marek explained in the thread before you got on Cc, they are all the
same, except for the graphics core (Mali) that has a different one but
currently disables that.
> > > For the drivers the most important are the following functions:
> > > iommu_{attach,detach}_device(struct iommu_domain *domain, struct device
> > > *dev);
>
> Right, and each driver can allocate its own domains.
For the cases that use the normal dma-mapping API, I guess there only
needs to be one domain to cover the kernel, which can then be hidden
in the driver provides the dma_map_ops based on an iommu_ops.
> > It's not quite how the domains are meant to be used. In the AMD IOMMU
> > that the API is based on, any number of devices can share one domain,
> > and devices might be able to have mappings in multiple domains.
>
> Yes, any number of devices can be assigned to one domain, but each
> device only belongs to one domain at each point in time. But it is
> possible to detach a device from one domain and attach it to another.
I was thinking of the SR-IOV case, where a single hardware device is
represented as multiple logical devices. As far as I understand, each
logical devices can only belong to one domain, but they don't all have to
be the same.
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: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
Hello,
On Tuesday, April 19, 2011 2:50 PM Arnd Bergmann wrote:
> On Tuesday 19 April 2011, Marek Szyprowski wrote:
>
> > > These look wrong for a number of reasons:
> > >
> > > * try_module_get(THIS_MODULE) makes no sense at all, the idea of the
> > > try_module_get is to pin down another module that was calling down,
> > > which I suppose is not needed here.
> > >
> > > * This extends the generic IOMMU API in platform specific ways, don't
> > > do that.
> > >
> > > * I think you can do without these functions by including a pointer
> > > to the iommu structure in dev_archdata, see
> > > arch/powerpc/include/asm/device.h for an example.
> >
> > We heavily based our solution on the iommu implementation found in
> > arch/arm/mach-msm/{devices-iommu,iommu,iommu_dev}.c
> >
> > The s5p_sysmmu_get/put functions are equivalent for
> msm_iommu_{get,put}_ctx.
> >
> > (snipped)
>
> Yes, I'm sorry about this. I commented on the early versions of the MSM
> driver, but then did not do another review of the version that actually
> got merged. That should also be fixed, ideally we can come up with a
> way that works for both drivers.
OK, so it looks that we misunderstood the IOMMU API basing on the
particular implementation.
> > > Why even provide these when they don't do anything?
> >
> > Because they are required by pm_runtime. If no runtime_{suspend,resume}
> > methods are provided, the pm_runtime core will not call proper methods
> > on parent device for pmruntime_{get,put}_sync(). The parent device for
> > each sysmmu platform device is the power domain the sysmmu belongs to.
> >
> > I know this is crazy, but this is the only way it can be handled now
> > with runtime_pm.
>
> Please don't try to work around kernel features when they don't fit
> what you are doing. The intent of the way that runtime_pm works is
> to make life easier for driver writers, not harder ;-)
>
> I can see three ways that would be better solutions:
>
> 1. change the runtime_pm subsystem to allow it to ignore some devices
> in an easy way.
>
> 2. change the device layout if the sysmmu. If the iommu device is
> a child of the device that it is responsible for, I guess you don't
> have this problem.
>
> 3. Not represent the iommu as a device at all, just as a property
> of another device.
Ok, we will handle this issue somehow. I consider this a minor issue and I
would like to focus on the IOMMU/dma-mapping APIs first.
> > > When you register the iommu unconditionally, it becomes impossible for
> > > this driver to coexist with other iommu drivers in the same kernel,
> > > which does against the concept of having a platform driver for this.
> >
> > > It might be better to call the s5p_sysmmu_register function from
> > > the board files and have no platform devices at all if each IOMMU
> > > is always bound to a specific device anyway.
> >
> > Ok, it looks I don't fully get how this iommu.h should be used. It looks
> > that there can be only one instance of iommu ops registered in the system,
> > so only one iommu driver can be activated. You are right that the iommu
> > driver has to be registered on first probe().
>
> 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?
(snipped)
> > The domain defined in iommu api are quite straightforward. Each domain
> > is just a set of mappings between physical addresses (phys) and io
> addresses
> > (iova).
> >
> > For the drivers the most important are the following functions:
> > iommu_{attach,detach}_device(struct iommu_domain *domain, struct device
> *dev);
> >
> > We assumed that they just assign the domain (mapping) to particular
> instance
> > of iommu. However the driver need to get somehow the pointer to the iommu
> > instance. That's why we added the s5p_sysmmu_{get,put} functions.
> >
> > Now I see that you want to make the clients (drivers) to provide their
> own
> > struct device pointer to the iommu_{attach,detach}_device() function
> instead of
> > giving there a pointer to iommu device. Am I right? We will need some
> kind of
> > mapping between multimedia devices and particular instanced of sysmmu
> > controllers.
> >
> > There will be also some problems with such approach. Mainly we have a
> > multimedia codec module, which have 2 memory controllers (for faster
Re: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
On Tue, Apr 19, 2011 at 08:49:50AM -0400, Arnd Bergmann wrote:
> (adding Joerg to Cc)
>
> On Tuesday 19 April 2011, Marek Szyprowski wrote:
>
> > > * This extends the generic IOMMU API in platform specific ways, don't
> > > do that.
This is certainly not a good idea. Please Cc me on IOMMU-API changes in
the future to that I can have a look at it. This is also a good way to
prevent misunderstandings (which I found some in this mail).
> > Ok, it looks I don't fully get how this iommu.h should be used. It looks
> > that there can be only one instance of iommu ops registered in the system,
> > so only one iommu driver can be activated. You are right that the iommu
> > driver has to be registered on first probe().
>
> 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.
The current IOMMU-API interface is very simple. It delegates the
selection of the particular IOMMU device to the IOMMU driver. Handle
this selection above the IOMMU driver is a complex thing to do. We will
need some kind of generic IOMMU support in the device-core and
attach IOMMUs to device sub-trees.
A simpler and less intrusive solution is to implement some wrapper code
which dispatches the IOMMU-API calls to the IOMMU driver implementation
required for that device.
> > I think it might be beneficial to describe a bit more our hardware
> > (Exynos4 platform). There are a number of multimedia blocks. Each has it's
> > own IOMMU controller. Each IOMMU controller has his own set of hardware
> > registers and irq. There is also a GPU unit (Mali) which has it's own
> > IOMMU hardware, incompatible with the SYSMMU, so right now it is ignored.
> >
> > The multimedia blocks are modeled as platform devices and are independent
> > of platform type (same multimedia blocks can be found on other Samsung
> > machines, like for example s5pv210/s5pc110), see arch/arm/plat-s5p/dev-*.c
> > and arch/arm/plat-samsung/dev-*.c.
Question: Does every platform device has a different type of IOMMU? Or
are the IOMMUs on all of these platform devices similar enough to be
handled by a single driver?
> > The domain defined in iommu api are quite straightforward. Each domain
> > is just a set of mappings between physical addresses (phys) and io addresses
> > (iova).
Each domain represents an address space. In the AMD IOMMU this is
basically a page-table.
> > For the drivers the most important are the following functions:
> > iommu_{attach,detach}_device(struct iommu_domain *domain, struct device
> > *dev);
Right, and each driver can allocate its own domains.
> > We assumed that they just assign the domain (mapping) to particular instance
> > of iommu. However the driver need to get somehow the pointer to the iommu
> > instance. That's why we added the s5p_sysmmu_{get,put} functions.
The functions attach a specific device to an IOMMU domain (== address
space). These devices might be behind different IOMMUs and it is the
responsibility of the IOMMU driver to setup everything correctly.
> It's not quite how the domains are meant to be used. In the AMD IOMMU
> that the API is based on, any number of devices can share one domain,
> and devices might be able to have mappings in multiple domains.
Yes, any number of devices can be assigned to one domain, but each
device only belongs to one domain at each point in time. But it is
possible to detach a device from one domain and attach it to another.
Regards,
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
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
(adding Joerg to Cc)
On Tuesday 19 April 2011, Marek Szyprowski wrote:
> > These look wrong for a number of reasons:
> >
> > * try_module_get(THIS_MODULE) makes no sense at all, the idea of the
> > try_module_get is to pin down another module that was calling down,
> > which I suppose is not needed here.
> >
> > * This extends the generic IOMMU API in platform specific ways, don't
> > do that.
> >
> > * I think you can do without these functions by including a pointer
> > to the iommu structure in dev_archdata, see
> > arch/powerpc/include/asm/device.h for an example.
>
> We heavily based our solution on the iommu implementation found in
> arch/arm/mach-msm/{devices-iommu,iommu,iommu_dev}.c
>
> The s5p_sysmmu_get/put functions are equivalent for msm_iommu_{get,put}_ctx.
>
> (snipped)
Yes, I'm sorry about this. I commented on the early versions of the MSM
driver, but then did not do another review of the version that actually
got merged. That should also be fixed, ideally we can come up with a
way that works for both drivers.
> > Why even provide these when they don't do anything?
>
> Because they are required by pm_runtime. If no runtime_{suspend,resume}
> methods are provided, the pm_runtime core will not call proper methods
> on parent device for pmruntime_{get,put}_sync(). The parent device for
> each sysmmu platform device is the power domain the sysmmu belongs to.
>
> I know this is crazy, but this is the only way it can be handled now
> with runtime_pm.
Please don't try to work around kernel features when they don't fit
what you are doing. The intent of the way that runtime_pm works is
to make life easier for driver writers, not harder ;-)
I can see three ways that would be better solutions:
1. change the runtime_pm subsystem to allow it to ignore some devices
in an easy way.
2. change the device layout if the sysmmu. If the iommu device is
a child of the device that it is responsible for, I guess you don't
have this problem.
3. Not represent the iommu as a device at all, just as a property
of another device.
> > When you register the iommu unconditionally, it becomes impossible for
> > this driver to coexist with other iommu drivers in the same kernel,
> > which does against the concept of having a platform driver for this.
>
> > It might be better to call the s5p_sysmmu_register function from
> > the board files and have no platform devices at all if each IOMMU
> > is always bound to a specific device anyway.
>
> Ok, it looks I don't fully get how this iommu.h should be used. It looks
> that there can be only one instance of iommu ops registered in the system,
> so only one iommu driver can be activated. You are right that the iommu
> driver has to be registered on first probe().
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.
> I think it might be beneficial to describe a bit more our hardware
> (Exynos4 platform). There are a number of multimedia blocks. Each has it's
> own IOMMU controller. Each IOMMU controller has his own set of hardware
> registers and irq. There is also a GPU unit (Mali) which has it's own
> IOMMU hardware, incompatible with the SYSMMU, so right now it is ignored.
>
> The multimedia blocks are modeled as platform devices and are independent
> of platform type (same multimedia blocks can be found on other Samsung
> machines, like for example s5pv210/s5pc110), see arch/arm/plat-s5p/dev-*.c
> and arch/arm/plat-samsung/dev-*.c.
>
> Platform driver data defined in the above files are registered by each
> board startup code, usually by platform_add_devices(), for more details
> please check arch/arm/mach-s5pv210/mach-goni.c. There is
> struct platform_device *goni_devices[] array which get registered in the
> last line in goni_machine_init() function.
>
> For IOMMU controllers on Exynos4 we created an array of platform devices:
> extern struct platform_device exynos4_device_sysmmu[];
>
> Now the board startup code registers only these sysmmu controllers
> (instances) that are required on the particular board. See "[PATCH 7/7]
> ARM: EXYNOS4: enable FIMC on Universal_C210":
> @@ -613,6 +616,15 @@ static struct platform_device *universal_devices[]
> __initdata = {
> &s3c_device_hsmmc2,
> &s3c_device_hsmmc3,
> &s3c_device_i2c5,
> + &s5p_device_fimc0,
> + &s5p_device_fimc1,
> + &s5p_device_fimc2,
> + &s5p_device_fimc3,
> + &exynos4_device_pd[PD_CAM],
> + &exynos4_device_sysmmu[S5P_SYSMMU_FIMC0],
> + &exynos4_device_sysmmu[S5P_SYSMMU_FIMC1],
> + &exynos4_device_sysmmu[S5P_SYSMMU_FIMC2],
> + &ex
Re: [REVERT] Re: V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
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 > Date: Mon Feb 28 06:37:02 2011 -0300 It seems the better option for now. Acked-by: Mauro Carvalho Chehab > > [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, -- 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: soc_camera with V4L2 driver
Hello Hans,
> >> The camera module needs to be initialized by writing values to the
> >> registers.
> >> Do I need to write init function at the following?
> >>
> >> static const struct v4l2_subdev_core_ops rj65na20_core_ops = {
> >> .reset = rj65na20_reset,
> >> [snip]
> >> }
> >
> > AFAICS neither soc_camera.c, nor sh_mobile_ceu_camera.c call the .reset
> > subdevice core method, so, no, at the moment implementing it wouldn't
> > produce any result. Either you have to choose one of the methods, that are
> > currently called, or you have to add a call to .reset() as required.
>
> I don't really like the use of reset for this. The reset op is a pretty
> poorly defined op. There is a registration op as well these days that
> might be better suited for this (see struct v4l2_subdev_internal_ops).
May I ask to guide me how to implement:
struct v4l2_subdev_internal_ops {
int (*registered)(struct v4l2_subdev *sd);
void (*unregistered)(struct v4l2_subdev *sd);
};
for the initializing camera module by writing values
to the register?
With kind regards,
Akira
--
Akira Tsukamoto
--
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: [RFCv1 PATCH 4/9] v4l2-ctrls: add per-control events.
Hi Sakari,
On Saturday 16 April 2011 10:51:27 Sakari Ailus wrote:
> Hans Verkuil wrote:
> >> Hans Verkuil wrote:
> >>> Whenever a control changes value an event is sent to anyone that
> >>> subscribed
> >>> to it.
> >>>
> >>> Signed-off-by: Hans Verkuil
> >>> ---
> >>>
> >>> drivers/media/video/v4l2-ctrls.c | 59 ++
> >>> drivers/media/video/v4l2-event.c | 126
> >>>
> >>> +++---
> >>>
> >>> drivers/media/video/v4l2-fh.c|4 +-
> >>> include/linux/videodev2.h| 17 +-
> >>> include/media/v4l2-ctrls.h |9 +++
> >>> include/media/v4l2-event.h |2 +
> >>> 6 files changed, 177 insertions(+), 40 deletions(-)
> >>>
> >>> diff --git a/drivers/media/video/v4l2-ctrls.c
> >>> b/drivers/media/video/v4l2-ctrls.c
> >>> index f75a1d4..163f412 100644
> >>> --- a/drivers/media/video/v4l2-ctrls.c
> >>> +++ b/drivers/media/video/v4l2-ctrls.c
> >>> @@ -23,6 +23,7 @@
> >>>
> >>> #include
> >>> #include
> >>> #include
> >>>
> >>> +#include
> >>>
> >>> #include
> >>>
> >>> /* Internal temporary helper struct, one for each v4l2_ext_control */
> >>>
> >>> @@ -537,6 +538,16 @@ static bool type_is_int(const struct v4l2_ctrl
> >>> *ctrl)
> >>>
> >>> }
> >>>
> >>> }
> >>>
> >>> +static void send_event(struct v4l2_ctrl *ctrl, struct v4l2_event *ev)
> >>> +{
> >>> + struct v4l2_ctrl_fh *pos;
> >>> +
> >>> + ev->id = ctrl->id;
> >>> + list_for_each_entry(pos, &ctrl->fhs, node) {
> >>> + v4l2_event_queue_fh(pos->fh, ev);
> >>> + }
> >>
> >> Shouldn't we do v4l2_ctrl_lock(ctrl) here? Or does something prevent
> >> changes to the file handle list while we loop over it?
> >
> > This function is always called with the lock taken.
>
> Yes, you're right.
>
> >> v4l2_ctrl_lock() locks a mutex. Events often arrive from interrupt
> >> context, which would mean the drivers would need to create a work queue
> >> to tell about changes to control values.
> >
> > I will have to check whether it is possible to make a function that can
> > be called from interrupt context. I have my doubts though whether it is
> > 1) possible and 2) desirable. At least in the area of HDMI
> > receivers/transmitters you will want to have a workqueue anyway.
>
> I wonder if there could be a more generic mechanism than to implement
> this in a driver itself. In some cases it may also be harmful that
> events are lost, and if there's just a single event for the workqueue,
> it happens too easily in my opinion.
>
> What do you think; could/should there be a queue for control events that
> arrive from interrupt context, or should that be implemented in the
> drivers themselves?
I expect most drivers to generate control events from interrupt context, so
pushing the workqueue down to individual drivers is probably not a good idea.
On a somehow related note, applications will often want to be informed of
control changes initiated by the device, but won't need to receive events for
control changes initiated by the application itself. Is that something we
support ?
> Another issue with this is that workqueues require to be scheduled so
> sending the event to user space gets delayed by that. One of the
> important aspects of events is latency and it would be nice to be able
> to minimise that --- that's one reason why events use a spinlock rather
> than a mutex, the other being that they can be easily sent from
> interrupt context where they mostly arrive from.
>
> It would be nice to have the same properties for control events.
>
> There are use cases where a user space control process would run on a
> real time priority to avoid scheduling latencies caused by other
> processes, and such control process receiving control events would be
> affected by the low priority of the work queues.
I would also prefer a solution implemented in the control framework that would
be interrupt context-friendly, without requiring a work queue.
> I agree with all your responses below on locking.
>
> Thanks.
>
> Regards,
--
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
Re: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Mon, 2011-04-18 at 18:48 -0400, Eric B Munson wrote: > On Mon, 18 Apr 2011, Andy Walls wrote: > > > Eric B Munson wrote: > > > > >On Mon, 11 Apr 2011, Eric B Munson wrote: > > > > > >> On Sun, 10 Apr 2011, Andy Walls wrote: > > >> > > >> > On Wed, 2011-04-06 at 13:28 -0400, Eric B Munson wrote: > > >> > > On Tue, Apr 5, 2011 at 10:58 AM, Andy Walls > > > > > >Is there anything else I can provide to help with this? > > > > Eric, > > > > Sorry for not getting back sooner (I've been dealing with a personal > situation and haven't logged into my dev system for a few weeks). > > > > What rf analog source are you using? > > Sorry, very new to this, I am not sure what you are asking for here. I mean: analog cable, DTV Set Top Box (STB), VCR, etc. I have only tested the driver on analog US Broadcast Channel 3, since I only have a DTV STB as an RF analog TV source. > > Have you used v4l2-ctl to ensure the tuner is set to the right tv > standard (my changes default to NTSC-M)? > > emunson@grover:~$ v4l2-ctl -S > Video Standard = 0xb000 > NTSC-M/M-JP/M-KR > emunson@grover:~$ v4l2-ctl -s ntsc > Standard set to b000 > emunson@grover:~$ v4l2-ctl -S > Video Standard = 0xb000 > NTSC-M/M-JP/M-KR > > What should the default be? NTSC-443? When I set to NTSC-443 I see > the same behaviour as below when I try and change channels. NTSC-M is the default. Having it set to autodetect the US, Japanese (-JP), or South Korean (-KR) variants is OK. Never use NTSC-443 as you likely will never encounter it in your life. NTSC-443 is never broadcast over the air or cable. It is a weird combination of NTSC video usings a PAL color subcarrier frequency. > > Have you used v4l2-ctl or ivtv-tune to tune to the proper tv channel > (the driver defaults to US channel 4)? > > emunson@grover:~$ v4l2-ctl -F > Frequency: 0 (0.00 MHz) > emunson@grover:~$ v4l2-ctl -f 259.250 > Frequency set to 4148 (259.25 MHz) > emunson@grover:~$ v4l2-ctl -F > Frequency: 0 (0.00 MHz) OK, that doesn't look good. The tda18271 tuner and/or tda8290 demod drivers may not be working right. I'll have to look into that later this week. BTW, Mike Krufky just submitted some patches that may be relevant: http://kernellabs.com/hg/~mkrufky/tda18271-fix > > > Does v4l2-ctl --log-status still show no signal present for the '843 core > > in the CX23418? > > Yeah, >[94465.349721] cx18-0 843: Video signal: not present The tuner or demod isn't tuning to a channel or getting a signal. Can you try channel 3 (61.250 MHz)? That one works for me. > > Does mplayer /dev/videoN -cache 8192 have a tv station when set to the rf > > analog input with v4l2-ctl? > > emunson@grover:~$ mplayer /dev/video0 -cache 8192 > MPlayer 1.0rc4-4.4.5 (C) 2000-2010 MPlayer Team > > Playing /dev/video0. > Cache fill: 0.00% (0 bytes) > > > Exiting... (End of file) Hmmm. I would have expected at least a black picture with snow, if not tuned to a channel. Does analog S-Video or Composite work? Regards, Andy > > > > From what I recall the analog tuner init looked ok. > > -Andy > > -- 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: Genius webcam problem on ARM
Hi, On Tuesday 12 April 2011 19:53:22 Zdeněk Materna wrote: > Hello, > > I'm sorry for another mail. It works with quirks 128 and uncompressed > YUV format. Is there any way how to use compressed MJPEG? Should I try > compile never uvcvideo driver? Could you post the output of lsusb -v for your camera when plugged in to your ARM board ? -- 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
Re: soc_camera with V4L2 driver
Hello Guennadi,
*1*
> I haven't reviewed your sources in detail, just two comments, regarding
> something, that caught my eye:
> > +static struct platform_device rj65na20_camera = {
> > + .name = "soc-camera-pdrv-2M",
>
> This name has to match with what's advertised in
> drivers/media/video/soc_camera.c, namely "soc-camera-pdrv"
*2*
> > static struct i2c_board_info i2c0_devices[] = {
> > {
> > I2C_BOARD_INFO("ag5evm_ts", 0x20),
> > .irq= pint2irq(12), /* PINTC3 */
> > },
> > + /* 2M camera */
> > + {
> > + I2C_BOARD_INFO("rj65na20", 0x40),
> > + },
I fixed the both above, thank you.
And add CEU init in it.
This is my current patch for temporary start.
(builds without error at least)
With kind regards,
Akira
--- linux_kernel_bsp/arch/arm/mach-shmobile/board-ag5evm.c 2011-03-22
12:30:14.0 +0900
+++ linux_kernel/arch/arm/mach-shmobile/board-ag5evm.c 2011-04-19
16:54:47.0 +0900
@@ -59,6 +59,7 @@
#include
#include
+#include
static struct r8a66597_platdata usb_host_data = {
.on_chip= 1,
@@ -317,11 +318,38 @@ static struct platform_device fsi_device
},
};
+static struct i2c_board_info rj65na20_info = {
+ I2C_BOARD_INFO("rj65na20", 0x40),
+};
+
+struct soc_camera_link rj65na20_link = {
+ .bus_id = 0,
+ .board_info = &rj65na20_info,
+ .i2c_adapter_id = 0,
+ .module_name= "rj65na20",
+};
+
+static struct platform_device rj65na20_camera = {
+ .name = "soc-camera-pdrv",
+ .id = 0,
+ .dev= {
+ .platform_data = &rj65na20_link,
+ },
+};
+
static struct i2c_board_info i2c0_devices[] = {
{
I2C_BOARD_INFO("ag5evm_ts", 0x20),
.irq= pint2irq(12), /* PINTC3 */
},
};
static struct i2c_board_info i2c1_devices[] = {
@@ -548,6 +576,8 @@ static struct platform_device *ag5evm_de
&usb_mass_storage_device,
&android_usb_device,
+
+ &rj65na20_camera,
};
static struct map_desc ag5evm_io_desc[] __initdata = {
@@ -748,6 +778,7 @@ static void __init ag5evm_init(void)
struct clk *sub_clk = clk_get(NULL, "sub_clk");
struct clk *extal2_clk = clk_get(NULL, "extal2");
struct clk *fsia_clk = clk_get(NULL, "fsia_clk");
+ struct clk *vck1_clk = clk_get(NULL, "vck1_clk");
clk_set_parent(sub_clk, extal2_clk);
__raw_writel(__raw_readl(SUBCKCR) & ~(1<<9), SUBCKCR);
@@ -853,6 +884,56 @@ static void __init ag5evm_init(void)
__raw_writel(0x2a8b9111, DSI1PHYCR);
clk_enable(clk_get(NULL, "dsi-tx"));
+ /* CEU */
+ gpio_request(GPIO_FN_VIO2_CLK2, NULL);
+ gpio_request(GPIO_FN_VIO2_VD3, NULL);
+ gpio_request(GPIO_FN_VIO2_HD3, NULL);
+ gpio_request(GPIO_FN_PORT16_VIO_CKOR, NULL);
+ gpio_request(GPIO_FN_VIO_D15, NULL);
+ gpio_request(GPIO_FN_VIO_D14, NULL);
+ gpio_request(GPIO_FN_VIO_D13, NULL);
+ gpio_request(GPIO_FN_VIO_D12, NULL);
+ gpio_request(GPIO_FN_VIO_D11, NULL);
+ gpio_request(GPIO_FN_VIO_D10, NULL);
+ gpio_request(GPIO_FN_VIO_D9, NULL);
+ gpio_request(GPIO_FN_VIO_D8, NULL);
+
+ if (!IS_ERR(vck1_clk)) {
+ clk_set_rate(vck1_clk, clk_round_rate(vck1_clk, 2400));
+ clk_enable(vck1_clk);
+ clk_put(vck1_clk);
+ udelay(50);
+ } else {
+ printk(KERN_ERR "clk_get(vck1_clk) failed.\n");
+ }
+
+ /* 2M camera */
+ gpio_request(GPIO_PORT44, NULL);
+ gpio_direction_output(GPIO_PORT44, 0);
+ udelay(10);
+ gpio_set_value(GPIO_PORT44, 1);
+
/* Unreset LCD Panel */
gpio_request(GPIO_PORT217, NULL);
gpio_direction_output(GPIO_PORT217, 0);
--
Akira Tsukamoto
--
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 4/7] v4l: videobuf2: add IOMMU based DMA memory allocator
On Tuesday 19 April 2011, Russell King - ARM Linux wrote: > On Tue, Apr 19, 2011 at 11:02:34AM +0200, Marek Szyprowski wrote: > > On Monday, April 18, 2011 4:16 PM Arnd Bergmann wrote: > > > My feeling is that this is not the right abstraction. Why can't you > > > just implement the regular dma-mapping.h interfaces for your IOMMU > > > so that the videobuf code can use the existing allocators? > > > > I'm not really sure which existing videobuf2 allocators might transparently > > support IOMMU interface yet > > > > Do you think that all iommu operations can be hidden behind dma_map_single > > and dma_unmap_single? > > That is one of the intentions of the DMA API. Exactly. All architectures that support IOMMUs today do that, see: arch/alpha/kernel/pci_iommu.c arch/ia64/hp/common/sba_iommu.c arch/powerpc/kernel/dma-iommu.c arch/sparc/kernel/iommu.c arch/x86/kernel/amd_iommu.c ARM would be the first one to combine an IOMMU with potentially noncoherent DMA, but there is no fundamental reason why we shouldn't be able to transparently support an IOMMU. Ideally, I think we should first find an architecture-independent way to define an IOMMU in one place instead of having to do both the iommu.h and dma-mapping.h interfaces, but I wouldn't require Samsung to do that in order to support their IOMMU. Doing support for the dma-mapping.h interface should be sufficient there. 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: Let's submit mt9p031 to mainline.
All right, just one more question, does this patch for mt9p031 apply in any repository out there out of the box so that I can test my hardware first? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- 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: Let's submit mt9p031 to mainline.
On Tuesday 19 April 2011 11:42:47 javier Martin wrote: > > Sure, feel free to grab this > > > > http://download.open-technology.de/BeagleBoard_xM-MT9P031/ > > > > follow instructions in the text file and update the sources. I'll be > > happy, if you manage to mainline it yourself, since I'm currently under a > > pretty severe time-pressure. > > Thanks, I'll do my best. > > >> What kernel are you using? In 2.6.38 usb works fine for me in the > >> Beagleboard xM. > > > > No, 2.6.38 is no good, it doesn't have MC / omap3isp in it. > > What GIT repository + branch should I use for developing then? 2.6.39-rc, or the linuxtv.org media-tree.git repository. -- 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
Re: Let's submit mt9p031 to mainline.
> Sure, feel free to grab this > > http://download.open-technology.de/BeagleBoard_xM-MT9P031/ > > follow instructions in the text file and update the sources. I'll be > happy, if you manage to mainline it yourself, since I'm currently under a > pretty severe time-pressure. Thanks, I'll do my best. >> What kernel are you using? In 2.6.38 usb works fine for me in the >> Beagleboard xM. > > No, 2.6.38 is no good, it doesn't have MC / omap3isp in it. > What GIT repository + branch should I use for developing then? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- 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: Let's submit mt9p031 to mainline.
On Tue, 19 Apr 2011, javier Martin wrote: > On 19 April 2011 11:19, Guennadi Liakhovetski wrote: > > On Tue, 19 Apr 2011, javier Martin wrote: > > > >> Hi, > >> I finally received my LI-5M03 for the Beagleboard which includes mt9p031 > >> sensor. > >> > >> I know Guennadi has somewhere an outdated version of a driver for it. > >> I would like to help you out on updating the driver so that it can be > >> submitted to mainline. > >> Guennadi please, if you could point me out to that code I could start > >> the job myself. > >> > >> Just one question: what GIT repository + branch should I choose to > >> work on, so that we can seamlessly integrate the changes later? > > > > I wanted to update the code, but usb is currently broken on beagle-board, > > so, I cannot work with it. I'm waiting for it to be fixed to continue with > > that. > > > > Thanks > > Guennadi > > So you are planning to do it yourself. > Is there anything I can do to help? Sure, feel free to grab this http://download.open-technology.de/BeagleBoard_xM-MT9P031/ follow instructions in the text file and update the sources. I'll be happy, if you manage to mainline it yourself, since I'm currently under a pretty severe time-pressure. > What kernel are you using? In 2.6.38 usb works fine for me in the > Beagleboard xM. No, 2.6.38 is no good, it doesn't have MC / omap3isp in it. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: Let's submit mt9p031 to mainline.
On 19 April 2011 11:19, Guennadi Liakhovetski wrote: > On Tue, 19 Apr 2011, javier Martin wrote: > >> Hi, >> I finally received my LI-5M03 for the Beagleboard which includes mt9p031 >> sensor. >> >> I know Guennadi has somewhere an outdated version of a driver for it. >> I would like to help you out on updating the driver so that it can be >> submitted to mainline. >> Guennadi please, if you could point me out to that code I could start >> the job myself. >> >> Just one question: what GIT repository + branch should I choose to >> work on, so that we can seamlessly integrate the changes later? > > I wanted to update the code, but usb is currently broken on beagle-board, > so, I cannot work with it. I'm waiting for it to be fixed to continue with > that. > > Thanks > Guennadi So you are planning to do it yourself. Is there anything I can do to help? What kernel are you using? In 2.6.38 usb works fine for me in the Beagleboard xM. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- 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 4/7] v4l: videobuf2: add IOMMU based DMA memory allocator
On Tue, Apr 19, 2011 at 11:02:34AM +0200, Marek Szyprowski wrote: > On Monday, April 18, 2011 4:16 PM Arnd Bergmann wrote: > > My feeling is that this is not the right abstraction. Why can't you > > just implement the regular dma-mapping.h interfaces for your IOMMU > > so that the videobuf code can use the existing allocators? > > I'm not really sure which existing videobuf2 allocators might transparently > support IOMMU interface yet > > Do you think that all iommu operations can be hidden behind dma_map_single > and dma_unmap_single? That is one of the intentions of the DMA API. -- 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: Let's submit mt9p031 to mainline.
On Tue, 19 Apr 2011, javier Martin wrote: > Hi, > I finally received my LI-5M03 for the Beagleboard which includes mt9p031 > sensor. > > I know Guennadi has somewhere an outdated version of a driver for it. > I would like to help you out on updating the driver so that it can be > submitted to mainline. > Guennadi please, if you could point me out to that code I could start > the job myself. > > Just one question: what GIT repository + branch should I choose to > work on, so that we can seamlessly integrate the changes later? I wanted to update the code, but usb is currently broken on beagle-board, so, I cannot work with it. I'm waiting for it to be fixed to continue with that. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Let's submit mt9p031 to mainline.
Hi, I finally received my LI-5M03 for the Beagleboard which includes mt9p031 sensor. I know Guennadi has somewhere an outdated version of a driver for it. I would like to help you out on updating the driver so that it can be submitted to mainline. Guennadi please, if you could point me out to that code I could start the job myself. Just one question: what GIT repository + branch should I choose to work on, so that we can seamlessly integrate the changes later? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- 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 4/7] v4l: videobuf2: add IOMMU based DMA memory allocator
Hello, On Monday, April 18, 2011 4:16 PM Arnd Bergmann wrote: > On Monday 18 April 2011, Marek Szyprowski wrote: > > From: Andrzej Pietrasiewicz > > > > This patch adds new videobuf2 memory allocator dedicated to devices that > > supports IOMMU DMA mappings. A device with IOMMU module and a driver > > with include/iommu.h compatible interface is required. This allocator > > aquires memory with standard alloc_page() call and doesn't suffer from > > memory fragmentation issues. The allocator support following page sizes: > > 4KiB, 64KiB, 1MiB and 16MiB to reduce iommu translation overhead. > > My feeling is that this is not the right abstraction. Why can't you > just implement the regular dma-mapping.h interfaces for your IOMMU > so that the videobuf code can use the existing allocators? I'm not really sure which existing videobuf2 allocators might transparently support IOMMU interface yet Do you think that all iommu operations can be hidden behind dma_map_single and dma_unmap_single? Best regards -- Marek Szyprowski Samsung Poland R&D 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 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
Hello,
On Monday, April 18, 2011 4:13 PM Arnd Bergmann wrote:
> On Monday 18 April 2011, Marek Szyprowski wrote:
> > From: Andrzej Pietrasiewicz
> >
> > This patch performs a complete rewrite of sysmmu driver for Samsung
> platform:
> > - simplified the resource management: no more single platform
> > device with 32 resources is needed, better fits into linux driver model,
> > each sysmmu instance has it's own resource definition
> > - the new version uses kernel wide common iommu api defined in
> include/iommu.h
> > - cleaned support for sysmmu clocks
> > - added support for custom fault handlers and tlb replacement policy
>
> Looks like good progress, but I fear that there is still quite a bit more
> work needed here.
Thanks for your comments! I've snipped the minor implementation comments
and focused only on the core iommu API.
(snipped)
> > +struct device *s5p_sysmmu_get(enum s5p_sysmmu_ip ip)
> > +{
> > + struct device *ret = NULL;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&sysmmu_slock, flags);
> > + if (sysmmu_table[ip]) {
> > + try_module_get(THIS_MODULE);
> > + ret = sysmmu_table[ip]->dev;
> > + }
> > + spin_unlock_irqrestore(&sysmmu_slock, flags);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(s5p_sysmmu_get);
> > +
> > +void s5p_sysmmu_put(void *dev)
> > +{
> > + BUG_ON(!dev);
> > + module_put(THIS_MODULE);
> > +}
> > +EXPORT_SYMBOL_GPL(s5p_sysmmu_put);
>
> These look wrong for a number of reasons:
>
> * try_module_get(THIS_MODULE) makes no sense at all, the idea of the
> try_module_get is to pin down another module that was calling down,
> which I suppose is not needed here.
>
> * This extends the generic IOMMU API in platform specific ways, don't
> do that.
>
> * I think you can do without these functions by including a pointer
> to the iommu structure in dev_archdata, see
> arch/powerpc/include/asm/device.h for an example.
We heavily based our solution on the iommu implementation found in
arch/arm/mach-msm/{devices-iommu,iommu,iommu_dev}.c
The s5p_sysmmu_get/put functions are equivalent for msm_iommu_{get,put}_ctx.
(snipped)
> > +static int
> > +s5p_sysmmu_suspend(struct platform_device *pdev, pm_message_t state)
> > +{
> > + int ret = 0;
> > + sysmmu_debug(3, "begin\n");
> > +
> > + return ret;
> > +}
> > +
> > +static int s5p_sysmmu_resume(struct platform_device *pdev)
> > +{
> > + int ret = 0;
> > + sysmmu_debug(3, "begin\n");
> > +
> > + return ret;
> > +}
> > +
> > +static int s5p_sysmmu_runtime_suspend(struct device *dev)
> > +{
> > + sysmmu_debug(3, "begin\n");
> > + return 0;
> > +}
> > +
> > +static int s5p_sysmmu_runtime_resume(struct device *dev)
> > +{
> > + sysmmu_debug(3, "begin\n");
> > + return 0;
> > +}
>
> Why even provide these when they don't do anything?
Because they are required by pm_runtime. If no runtime_{suspend,resume}
methods are provided, the pm_runtime core will not call proper methods
on parent device for pmruntime_{get,put}_sync(). The parent device for
each sysmmu platform device is the power domain the sysmmu belongs to.
I know this is crazy, but this is the only way it can be handled now
with runtime_pm.
> > +static int __init
> > +s5p_sysmmu_register(void)
> > +{
> > + int ret;
> > +
> > + sysmmu_debug(3, "Registering sysmmu driver...\n");
> > +
> > + slpt_cache = kmem_cache_create("slpt_cache", 1024, 1024,
> > + SLAB_HWCACHE_ALIGN, NULL);
> > + if (!slpt_cache) {
> > + printk(KERN_ERR
> > + "%s: failed to allocated slpt cache\n",
> __func__);
> > + return -ENOMEM;
> > + }
> > +
> > + ret = platform_driver_register(&s5p_sysmmu_driver);
> > +
> > + if (ret) {
> > + printk(KERN_ERR
> > + "%s: failed to register sysmmu driver\n",
> __func__);
> > + return -EINVAL;
> > + }
> > +
> > + register_iommu(&s5p_sysmmu_ops);
> > +
> > + return ret;
> > +}
>
> When you register the iommu unconditionally, it becomes impossible for
> this driver to coexist with other iommu drivers in the same kernel,
> which does against the concept of having a platform driver for this.
> It might be better to call the s5p_sysmmu_register function from
> the board files and have no platform devices at all if each IOMMU
> is always bound to a specific device anyway.
Ok, it looks I don't fully get how this iommu.h should be used. It looks
that there can be only one instance of iommu ops registered in the system,
so only one iommu driver can be activated. You are right that the iommu
driver has to be registered on first probe().
I think it might be beneficial to describe a bit more our hardware
(Exynos4 platform). There are a number of multimedia blocks. Each has it's
own IOMMU controller. Each IOMM
Re: OMAP3 ISP deadlocks on my new arm
Laurent Pinchart wrote: ... > That's the ideal situation: sensors should not produce any data (or rather > any > transition on the VS/HS signals) when they're supposed to be stopped. > Unfortunately that's not always easy, as some dumb sensors (or sensor-like > hardware) can't be stopped. The ISP driver should be able to cope with that > in > a way that doesn't kill the system completely. > > I've noticed the same issue with a Caspa camera module and an OMAP3503-based > Gumstix. I'll try to come up with a good fix. Hi Laurent, others, Do you think the cause for this is that the system is jammed in handling HS_VS interrupts triggered for every HS? A quick fix for this could be just choosing either VS configuration when configuring the CCDC. Alternatively, HS_VS interrupts could be just disabled until omap3isp_configure_interface(). But as the sensor is sending images all the time, proper VS configuration would be needed, or the counting of lines in the CCDC (VD* interrupts) is affected as well. The VD0 interrupt, which is used to trigger an interrupt near the end of the frame, may be triggered one line too early on the first frame, or too late. But this is up to a configuration. I don't think it's a real issue to trigger it one line too early. Anything else? Cheers, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- 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
