[PATCH 1/1] v4l: Remove experimental tag from certain API elements
Remove experimantal tag from the following API elements: V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY buffer type. V4L2_CAP_VIDEO_OUTPUT_OVERLAY capability flag. VIDIOC_ENUM_FRAMESIZES IOCTL. VIDIOC_G_ENC_INDEX IOCTL. VIDIOC_ENCODER_CMD and VIDIOC_TRY_ENCODER_CMD IOCTLs. VIDIOC_DECODER_CMD and VIDIOC_TRY_DECODER_CMD IOCTLs. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- VIDIOC_ENUM_FRAMEINTERVALS is already no longer experimental. Documentation/DocBook/media/v4l/compat.xml | 23 Documentation/DocBook/media/v4l/dev-osd.xml|7 -- Documentation/DocBook/media/v4l/io.xml |3 +- .../DocBook/media/v4l/vidioc-decoder-cmd.xml |7 -- .../DocBook/media/v4l/vidioc-encoder-cmd.xml |7 -- .../DocBook/media/v4l/vidioc-enum-framesizes.xml |7 -- .../DocBook/media/v4l/vidioc-g-enc-index.xml |7 -- 7 files changed, 1 insertions(+), 60 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 98e8d08..578135e 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2555,29 +2555,6 @@ and may change in the future./para paraVideo Output Overlay (OSD) Interface, xref linkend=osd /./para /listitem - listitem - paraconstantV4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY/constant, - v4l2-buf-type;, xref linkend=v4l2-buf-type /./para -/listitem -listitem - paraconstantV4L2_CAP_VIDEO_OUTPUT_OVERLAY/constant, -VIDIOC-QUERYCAP; ioctl, xref linkend=device-capabilities /./para -/listitem -listitem - paraVIDIOC-ENUM-FRAMESIZES; and -VIDIOC-ENUM-FRAMEINTERVALS; ioctls./para -/listitem -listitem - paraVIDIOC-G-ENC-INDEX; ioctl./para -/listitem -listitem - paraVIDIOC-ENCODER-CMD; and VIDIOC-TRY-ENCODER-CMD; -ioctls./para -/listitem -listitem - paraVIDIOC-DECODER-CMD; and VIDIOC-TRY-DECODER-CMD; -ioctls./para -/listitem listitem paraVIDIOC-DBG-G-REGISTER; and VIDIOC-DBG-S-REGISTER; ioctls./para diff --git a/Documentation/DocBook/media/v4l/dev-osd.xml b/Documentation/DocBook/media/v4l/dev-osd.xml index 479d943..dd91d61 100644 --- a/Documentation/DocBook/media/v4l/dev-osd.xml +++ b/Documentation/DocBook/media/v4l/dev-osd.xml @@ -1,13 +1,6 @@ titleVideo Output Overlay Interface/title subtitleAlso known as On-Screen Display (OSD)/subtitle - note -titleExperimental/title - -paraThis is an link linkend=experimentalexperimental/link -interface and may change in the future./para - /note - paraSome video output devices can overlay a framebuffer image onto the outgoing video signal. Applications can set up such an overlay using this interface, which borrows structures and ioctls of the link diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 1885cc0..2512649 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -827,8 +827,7 @@ should set this to 0./entry entryconstantV4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY/constant/entry entry8/entry entryBuffer for video output overlay (OSD), see xref - linkend=osd /. Status: link -linkend=experimentalExperimental/link./entry + linkend=osd /./entry /row row entryconstantV4L2_BUF_TYPE_PRIVATE/constant/entry diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml index 74b87f6..9215627 100644 --- a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml @@ -49,13 +49,6 @@ refsect1 titleDescription/title -note - titleExperimental/title - - paraThis is an link linkend=experimentalexperimental/link -interface and may change in the future./para -/note - paraThese ioctls control an audio/video (usually MPEG-) decoder. constantVIDIOC_DECODER_CMD/constant sends a command to the decoder, constantVIDIOC_TRY_DECODER_CMD/constant can be used to diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml index f431b3b..0619ca5 100644 --- a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml @@ -49,13 +49,6 @@ refsect1 titleDescription/title -note - titleExperimental/title - - paraThis is an link linkend=experimentalexperimental/link -interface and may change in the future./para -/note - paraThese ioctls control an audio/video (usually MPEG-) encoder. constantVIDIOC_ENCODER_CMD/constant sends a command to the encoder, constantVIDIOC_TRY_ENCODER_CMD/constant can be used to diff --git
[PATCH] tda8261: add printk levels
From: Alan Cox a...@linux.intel.com
This is done as a minimal printk updating patch to ensure correctness. Yes
it should all one day use dev_foo(), but that's one for the maintainers.
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=32932
Signed-off-by: Alan Cox a...@linux.intel.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
The file has been moved in -next, so to avoid unnecessary conflicts, I am
passing this one over from trivial tree to media maintainers.
Thanks.
drivers/media/dvb-frontends/tda8261.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/media/dvb-frontends/tda8261.c
b/drivers/media/dvb-frontends/tda8261.c
index 53c7d8f..19c4888 100644
--- a/drivers/media/dvb-frontends/tda8261.c
+++ b/drivers/media/dvb-frontends/tda8261.c
@@ -43,7 +43,7 @@ static int tda8261_read(struct tda8261_state *state, u8 *buf)
struct i2c_msg msg = { .addr= config-addr, .flags = I2C_M_RD,.buf
= buf, .len = 1 };
if ((err = i2c_transfer(state-i2c, msg, 1)) != 1)
- printk(%s: read error, err=%d\n, __func__, err);
+ pr_err(%s: read error, err=%d\n, __func__, err);
return err;
}
@@ -55,7 +55,7 @@ static int tda8261_write(struct tda8261_state *state, u8 *buf)
struct i2c_msg msg = { .addr = config-addr, .flags = 0, .buf = buf,
.len = 4 };
if ((err = i2c_transfer(state-i2c, msg, 1)) != 1)
- printk(%s: write error, err=%d\n, __func__, err);
+ pr_err(%s: write error, err=%d\n, __func__, err);
return err;
}
@@ -69,11 +69,11 @@ static int tda8261_get_status(struct dvb_frontend *fe, u32
*status)
*status = 0;
if ((err = tda8261_read(state, result)) 0) {
- printk(%s: I/O Error\n, __func__);
+ pr_err(%s: I/O Error\n, __func__);
return err;
}
if ((result 6) 0x01) {
- printk(%s: Tuner Phase Locked\n, __func__);
+ pr_debug(%s: Tuner Phase Locked\n, __func__);
*status = 1;
}
@@ -98,7 +98,7 @@ static int tda8261_get_state(struct dvb_frontend *fe,
tstate-bandwidth = 4000; /* FIXME! need to calculate
Bandwidth */
break;
default:
- printk(%s: Unknown parameter (param=%d)\n, __func__, param);
+ pr_err(%s: Unknown parameter (param=%d)\n, __func__, param);
err = -EINVAL;
break;
}
@@ -124,11 +124,11 @@ static int tda8261_set_state(struct dvb_frontend *fe,
*/
frequency = tstate-frequency;
if ((frequency 95) || (frequency 215)) {
- printk(%s: Frequency beyond limits, frequency=%d\n,
__func__, frequency);
+ pr_warn(%s: Frequency beyond limits, frequency=%d\n,
__func__, frequency);
return -EINVAL;
}
N = (frequency + (div_tab[config-step_size] - 1)) /
div_tab[config-step_size];
- printk(%s: Step size=%d, Divider=%d, PG=0x%02x (%d)\n,
+ pr_debug(%s: Step size=%d, Divider=%d, PG=0x%02x (%d)\n,
__func__, config-step_size,
div_tab[config-step_size], N, N);
buf[0] = (N 8) 0xff;
@@ -144,25 +144,25 @@ static int tda8261_set_state(struct dvb_frontend *fe,
/* Set params */
if ((err = tda8261_write(state, buf)) 0) {
- printk(%s: I/O Error\n, __func__);
+ pr_err(%s: I/O Error\n, __func__);
return err;
}
/* sleep for some time */
- printk(%s: Waiting to Phase LOCK\n, __func__);
+ pr_debug(%s: Waiting to Phase LOCK\n, __func__);
msleep(20);
/* check status */
if ((err = tda8261_get_status(fe, status)) 0) {
- printk(%s: I/O Error\n, __func__);
+ pr_err(%s: I/O Error\n, __func__);
return err;
}
if (status == 1) {
- printk(%s: Tuner Phase locked: status=%d\n, __func__,
status);
+ pr_debug(%s: Tuner Phase locked: status=%d\n,
__func__, status);
state-frequency = frequency; /* cache successful state
*/
} else {
- printk(%s: No Phase lock: status=%d\n, __func__,
status);
+ pr_debug(%s: No Phase lock: status=%d\n, __func__,
status);
}
} else {
- printk(%s: Unknown parameter (param=%d)\n, __func__, param);
+ pr_err(%s: Unknown parameter (param=%d)\n, __func__, param);
return -EINVAL;
}
@@ -214,7 +214,7 @@ struct dvb_frontend *tda8261_attach(struct dvb_frontend *fe,
// printk(%s:
Re: [PATCH] [media] davinci: vpfe: Add documentation
On Sat September 1 2012 16:22:30 Laurent Pinchart wrote: Hi Sakari, On Saturday 01 September 2012 12:57:07 Sakari Ailus wrote: On Wed, Aug 29, 2012 at 08:11:50PM +0530, Prabhakar Lad wrote: [snip] For test pattern you meant control to enable/disable it ? There are two approaches I can think of. One is a menu control which can be used to choose the test pattern (or disable it). The control could be standardised but the menu items would have to be hardware-specific since the test patterns themselves are not standardised. Agreed. The test patterns themselves are highly hardware-specific. From personal experience with sensors, most devices implement a small, fixed set of test patterns that can be exposed through a menu control. However, some devices also implement more configurable test patterns. For instance the MT9V032 can generate horizontal, vertical or diagonal test patterns, or a uniform grey test pattern with a user-configurable value. This would then require two controls. The alternative is to have a boolean control to enable (and disable) the test pattern and then a menu control to choose which one to use. Using or implemeting the control to select the test pattern isn't even strictly necessary to get a test pattern out of the device: one can enable it without knowing which one it is. So which one would be better? Similar cases include V4L2_CID_SCENE_MODE which is used to choose the scene mode from a list of alternatives. The main difference to this case is that the menu items of the scene mode control are standardised, too. I'd be inclined to have a single menu control, even if the other menu items will be device-specific. The first value (0) still has to be documented to mean the test pattern is disabled. Laurent, Hans: what do you think? A menu control with value 0 meaning test pattern disabled has my preference as well. +1 Hans -- 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: [PATCHv3 2/9] ir-rx51: Handle signals properly
Terve, On 09/01/12 20:14, Sakari Ailus wrote: Moi, On Thu, Aug 30, 2012 at 08:54:24PM +0300, Timo Kokkonen wrote: @@ -273,9 +281,18 @@ static ssize_t lirc_rx51_write(struct file *file, const char *buf, /* * Don't return back to the userspace until the transfer has - * finished + * finished. However, we wish to not spend any more than 500ms + * in kernel. No IR code TX should ever take that long. + */ +i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0, +HZ / 2); Why such an arbitrary timeout? In reality it might not bite the user space in practice ever, but is it (and if so, why) really required in the first place? Well, I can think of two cases: 1) Something goes wrong. Such before I converted the patch to use the up to date PM QoS implementation, the transmitting could take very long time because the interrupts were not waking up the MPU. Now that this is sorted out only unknown bugs can cause transmitting to hang indefinitely. 2) User is (intentionally?) doing something wrong. For example by feeding in an IR code that has got very long pulses, he could end up having the lircd process hung in kernel unkillable for long time. That could be avoided quite easily by counting the pulse lengths and rejecting any IR codes that are obviously too long. But since I'd like to also protect against 1) case, I think this solution works just fine. In the end, this is just safety measure that this driver behaves well. -Timo -- 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: [PATCHv3 9/9] ir-rx51: Add missing quote mark in Kconfig text
On 09/01/12 20:16, Sakari Ailus wrote: Moi, On Thu, Aug 30, 2012 at 08:54:31PM +0300, Timo Kokkonen wrote: This trivial fix cures the following warning message: drivers/media/rc/Kconfig:275:warning: multi-line strings not supported Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi --- drivers/media/rc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 4a68014..1300655 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -272,7 +272,7 @@ config IR_IGUANA be called iguanair. config IR_RX51 -tristate Nokia N900 IR transmitter diode +tristate Nokia N900 IR transmitter diode depends on OMAP_DM_TIMER LIRC ---help--- Say Y or M here if you want to enable support for the IR This should be combined with patch 1. Actually I'd rather keep the patch 1 as is as it has already a purpose. Instead, I'd squash this into patch 3 as it already touches the Kconfig file and it has also the other trivial fixes combined in it. -Timo -- 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: [PATCHv3 2/9] ir-rx51: Handle signals properly
Heippa, Timo Kokkonen wrote: Terve, On 09/01/12 20:14, Sakari Ailus wrote: Moi, On Thu, Aug 30, 2012 at 08:54:24PM +0300, Timo Kokkonen wrote: @@ -273,9 +281,18 @@ static ssize_t lirc_rx51_write(struct file *file, const char *buf, /* * Don't return back to the userspace until the transfer has -* finished +* finished. However, we wish to not spend any more than 500ms +* in kernel. No IR code TX should ever take that long. +*/ + i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0, + HZ / 2); Why such an arbitrary timeout? In reality it might not bite the user space in practice ever, but is it (and if so, why) really required in the first place? Well, I can think of two cases: 1) Something goes wrong. Such before I converted the patch to use the up to date PM QoS implementation, the transmitting could take very long time because the interrupts were not waking up the MPU. Now that this is sorted out only unknown bugs can cause transmitting to hang indefinitely. 2) User is (intentionally?) doing something wrong. For example by feeding in an IR code that has got very long pulses, he could end up having the lircd process hung in kernel unkillable for long time. That could be avoided quite easily by counting the pulse lengths and rejecting any IR codes that are obviously too long. But since I'd like to also protect against 1) case, I think this solution works just fine. In the end, this is just safety measure that this driver behaves well. In that case I think you should use wait_event_interruptible() instead. It's not the driver's job to decide what the user can do with the hardware and what not, is it? Terveisin, -- Sakari Ailus sakari.ai...@iki.fi -- 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: [PATCHv3 2/9] ir-rx51: Handle signals properly
On 09.02 2012 18:06:34, Sakari Ailus wrote: Heippa, Timo Kokkonen wrote: Terve, On 09/01/12 20:14, Sakari Ailus wrote: Moi, On Thu, Aug 30, 2012 at 08:54:24PM +0300, Timo Kokkonen wrote: @@ -273,9 +281,18 @@ static ssize_t lirc_rx51_write(struct file *file, const char *buf, /* * Don't return back to the userspace until the transfer has - * finished + * finished. However, we wish to not spend any more than 500ms + * in kernel. No IR code TX should ever take that long. + */ + i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0, + HZ / 2); Why such an arbitrary timeout? In reality it might not bite the user space in practice ever, but is it (and if so, why) really required in the first place? Well, I can think of two cases: 1) Something goes wrong. Such before I converted the patch to use the up to date PM QoS implementation, the transmitting could take very long time because the interrupts were not waking up the MPU. Now that this is sorted out only unknown bugs can cause transmitting to hang indefinitely. 2) User is (intentionally?) doing something wrong. For example by feeding in an IR code that has got very long pulses, he could end up having the lircd process hung in kernel unkillable for long time. That could be avoided quite easily by counting the pulse lengths and rejecting any IR codes that are obviously too long. But since I'd like to also protect against 1) case, I think this solution works just fine. In the end, this is just safety measure that this driver behaves well. In that case I think you should use wait_event_interruptible() instead. Well, that's what I had there in the first place. With interruptible wait we are left with problem with signals. I was told by Sean Young that the lirc API expects the write call to finish only after the IR code is transmitted. It's not the driver's job to decide what the user can do with the hardware and what not, is it? Yeah, policy should be decided by the user space. However, kernel should not leave any objvious denial of service holes open either. Allowing a process to get stuck unkillable within kernel for long time sounds like one to me. Anyway, we are trying to cover some rare corner cases here, I'm not sure how it should work exactly.. -Timo Terveisin, -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gspca_pac7302 driver broken ?
Hi, can anyone who owns such a device confirm that the gspca_pac7302 driver (kernel 3.6.0-rc1+) is fine ? Today I stumbled over a webcam which we do not support yet. The Windows driver of this device is called pac7302.sys, so I added it's USB-ID to the gspca-driver but couldn't get the device working. When I started capturing, the LED turned on for about a second and then off again. No frames are received. There were no error messages. I didn't have enough time for looking into this deeper today, but I think I could borrow this device again in a few days. Regards, Frank Schäfer -- 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: [PATCHv3 2/9] ir-rx51: Handle signals properly
On Sun, Sep 02, 2012 at 06:20:27PM +0300, Timo Kokkonen wrote: On 09.02 2012 18:06:34, Sakari Ailus wrote: Heippa, Timo Kokkonen wrote: Terve, On 09/01/12 20:14, Sakari Ailus wrote: Moi, On Thu, Aug 30, 2012 at 08:54:24PM +0300, Timo Kokkonen wrote: @@ -273,9 +281,18 @@ static ssize_t lirc_rx51_write(struct file *file, const char *buf, /* * Don't return back to the userspace until the transfer has -* finished +* finished. However, we wish to not spend any more than 500ms +* in kernel. No IR code TX should ever take that long. +*/ + i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0, + HZ / 2); Why such an arbitrary timeout? In reality it might not bite the user space in practice ever, but is it (and if so, why) really required in the first place? Well, I can think of two cases: 1) Something goes wrong. Such before I converted the patch to use the up to date PM QoS implementation, the transmitting could take very long time because the interrupts were not waking up the MPU. Now that this is sorted out only unknown bugs can cause transmitting to hang indefinitely. 2) User is (intentionally?) doing something wrong. For example by feeding in an IR code that has got very long pulses, he could end up having the lircd process hung in kernel unkillable for long time. That could be avoided quite easily by counting the pulse lengths and rejecting any IR codes that are obviously too long. But since I'd like to also protect against 1) case, I think this solution works just fine. In the end, this is just safety measure that this driver behaves well. In that case I think you should use wait_event_interruptible() instead. Well, that's what I had there in the first place. With interruptible wait we are left with problem with signals. I was told by Sean Young that the lirc API expects the write call to finish only after the IR code is transmitted. It's not the driver's job to decide what the user can do with the hardware and what not, is it? Yeah, policy should be decided by the user space. However, kernel should not leave any objvious denial of service holes open either. Allowing a process to get stuck unkillable within kernel for long time sounds like one to me. It's interruptible, so the user space can interrupt that wait if it chooses so. Besides, if you call this denial of service, then capturing video on V4L2 is, too, since others can't use the device in the meantime. :-) Anyway, we are trying to cover some rare corner cases here, I'm not sure how it should work exactly.. If there was a generic maximum timeout for sending a code, wouldn't it make sense to enforce that in the LIRC framework instead? Terveisin, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Sep 2 19:00:22 CEST 2012 git hash:79e8c7bebb467bbc3f2514d75bba669a3f354324 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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
Re: [PATCHv3 9/9] ir-rx51: Add missing quote mark in Kconfig text
On Sun, Sep 02, 2012 at 05:57:25PM +0300, Timo Kokkonen wrote: On 09/01/12 20:16, Sakari Ailus wrote: Moi, On Thu, Aug 30, 2012 at 08:54:31PM +0300, Timo Kokkonen wrote: This trivial fix cures the following warning message: drivers/media/rc/Kconfig:275:warning: multi-line strings not supported Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi --- drivers/media/rc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 4a68014..1300655 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -272,7 +272,7 @@ config IR_IGUANA be called iguanair. config IR_RX51 - tristate Nokia N900 IR transmitter diode + tristate Nokia N900 IR transmitter diode depends on OMAP_DM_TIMER LIRC ---help--- Say Y or M here if you want to enable support for the IR This should be combined with patch 1. Actually I'd rather keep the patch 1 as is as it has already a purpose. Instead, I'd squash this into patch 3 as it already touches the Kconfig file and it has also the other trivial fixes combined in it. Sounds good, that's actually a better place for it. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: [PATCHv3 2/9] ir-rx51: Handle signals properly
On 09/02/12 22:41, Sakari Ailus wrote: On Sun, Sep 02, 2012 at 06:20:27PM +0300, Timo Kokkonen wrote: On 09.02 2012 18:06:34, Sakari Ailus wrote: Heippa, Timo Kokkonen wrote: Terve, On 09/01/12 20:14, Sakari Ailus wrote: Moi, On Thu, Aug 30, 2012 at 08:54:24PM +0300, Timo Kokkonen wrote: @@ -273,9 +281,18 @@ static ssize_t lirc_rx51_write(struct file *file, const char *buf, /* * Don't return back to the userspace until the transfer has - * finished + * finished. However, we wish to not spend any more than 500ms + * in kernel. No IR code TX should ever take that long. + */ +i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0, +HZ / 2); Why such an arbitrary timeout? In reality it might not bite the user space in practice ever, but is it (and if so, why) really required in the first place? Well, I can think of two cases: 1) Something goes wrong. Such before I converted the patch to use the up to date PM QoS implementation, the transmitting could take very long time because the interrupts were not waking up the MPU. Now that this is sorted out only unknown bugs can cause transmitting to hang indefinitely. 2) User is (intentionally?) doing something wrong. For example by feeding in an IR code that has got very long pulses, he could end up having the lircd process hung in kernel unkillable for long time. That could be avoided quite easily by counting the pulse lengths and rejecting any IR codes that are obviously too long. But since I'd like to also protect against 1) case, I think this solution works just fine. In the end, this is just safety measure that this driver behaves well. In that case I think you should use wait_event_interruptible() instead. Well, that's what I had there in the first place. With interruptible wait we are left with problem with signals. I was told by Sean Young that the lirc API expects the write call to finish only after the IR code is transmitted. It's not the driver's job to decide what the user can do with the hardware and what not, is it? Yeah, policy should be decided by the user space. However, kernel should not leave any objvious denial of service holes open either. Allowing a process to get stuck unkillable within kernel for long time sounds like one to me. It's interruptible, so the user space can interrupt that wait if it chooses so. Besides, if you call this denial of service, then capturing video on V4L2 is, too, since others can't use the device in the meantime. :-) Well, of course there is no problem if we use interruptible waits. But I was told by Sean that the lirc API expects the IR TX to be finished always when the write call returns. I guess the assumption is to avoid breaking the transmission in the middle in case the process is signaled. And that's why we shouldn't use interruptible waits. However, if we allow simply breaking the transmitting in case the process is signaled any way during the transmission, then the handling would be trivial in the driver. That is, if someone for example kills or stops the lirc daemon process, then the IR code just wouldn't finish ever. Sean, do you have an opinion how this should or is allowed to work? Anyway, we are trying to cover some rare corner cases here, I'm not sure how it should work exactly.. If there was a generic maximum timeout for sending a code, wouldn't it make sense to enforce that in the LIRC framework instead? Yes, I agree it makes sense to leave unrestricted. But in that case we definitely have to use interruptible waits in case user space is doing something stupid and regrets it later :) Terveisin, -- 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: gspca_pac7302 driver broken ?
Hi Frank, On Sun, Sep 2, 2012 at 2:15 PM, Frank Schäfer fschaefer@googlemail.com wrote: Hi, can anyone who owns such a device confirm that the gspca_pac7302 driver (kernel 3.6.0-rc1+) is fine ? It's working here with latest media-tree kernel. Driver Info: Driver name : gspca_pac7302 Card type : USB Camera (093a:2625) Bus info : usb-:00:12.0-1 Driver version: 3.6.0 Capabilities : 0x8501 Video Capture Read/Write Streaming Device Capabilities Device Caps : 0x0501 Video Capture Read/Write Streaming Hope this helps, Ezequiel. -- 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] mxl5005s: implement get_if_frequency()
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/mxl5005s.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/media/tuners/mxl5005s.c b/drivers/media/tuners/mxl5005s.c
index 6133315..b473b76 100644
--- a/drivers/media/tuners/mxl5005s.c
+++ b/drivers/media/tuners/mxl5005s.c
@@ -4054,6 +4054,16 @@ static int mxl5005s_get_bandwidth(struct dvb_frontend
*fe, u32 *bandwidth)
return 0;
}
+static int mxl5005s_get_if_frequency(struct dvb_frontend *fe, u32 *frequency)
+{
+ struct mxl5005s_state *state = fe-tuner_priv;
+ dprintk(1, %s()\n, __func__);
+
+ *frequency = state-IF_OUT;
+
+ return 0;
+}
+
static int mxl5005s_release(struct dvb_frontend *fe)
{
dprintk(1, %s()\n, __func__);
@@ -4076,6 +4086,7 @@ static const struct dvb_tuner_ops mxl5005s_tuner_ops = {
.set_params= mxl5005s_set_params,
.get_frequency = mxl5005s_get_frequency,
.get_bandwidth = mxl5005s_get_bandwidth,
+ .get_if_frequency = mxl5005s_get_if_frequency,
};
struct dvb_frontend *mxl5005s_attach(struct dvb_frontend *fe,
--
1.7.11.4
--
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] af9013: add debug for IF frequency
Used IF frequency is one of the most important parameter to know. Signed-off-by: Antti Palosaari cr...@iki.fi --- drivers/media/dvb-frontends/af9013.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/dvb-frontends/af9013.c b/drivers/media/dvb-frontends/af9013.c index 5bc570d..2dac314 100644 --- a/drivers/media/dvb-frontends/af9013.c +++ b/drivers/media/dvb-frontends/af9013.c @@ -606,6 +606,8 @@ static int af9013_set_frontend(struct dvb_frontend *fe) else if_frequency = state-config.if_frequency; + dbg(%s: if_frequency=%d, __func__, if_frequency); + sampling_freq = if_frequency; while (sampling_freq (state-config.clock / 2)) -- 1.7.11.4 -- 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] mc44s803: implement get_if_frequency()
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/mc44s803.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/tuners/mc44s803.c b/drivers/media/tuners/mc44s803.c
index 5ddce7e..f1b7640 100644
--- a/drivers/media/tuners/mc44s803.c
+++ b/drivers/media/tuners/mc44s803.c
@@ -298,6 +298,12 @@ static int mc44s803_get_frequency(struct dvb_frontend *fe,
u32 *frequency)
return 0;
}
+static int mc44s803_get_if_frequency(struct dvb_frontend *fe, u32 *frequency)
+{
+ *frequency = MC44S803_IF2; /* 36.125 MHz */
+ return 0;
+}
+
static const struct dvb_tuner_ops mc44s803_tuner_ops = {
.info = {
.name = Freescale MC44S803,
@@ -309,7 +315,8 @@ static const struct dvb_tuner_ops mc44s803_tuner_ops = {
.release = mc44s803_release,
.init = mc44s803_init,
.set_params= mc44s803_set_params,
- .get_frequency = mc44s803_get_frequency
+ .get_frequency = mc44s803_get_frequency,
+ .get_if_frequency = mc44s803_get_if_frequency,
};
/* This functions tries to identify a MC44S803 tuner by reading the ID
--
1.7.11.4
--
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] Add the usb id of the Trekstor DVB-T Stick Terres 2.0
It needs the e4000 tuner driver.
Signed-off-by: Philipp Dreimann phil...@dreimann.net
---
drivers/media/dvb-core/dvb-usb-ids.h|1 +
drivers/media/usb/dvb-usb-v2/rtl28xxu.c |2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 26c4481..fed6dcd 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -82,6 +82,7 @@
#define USB_PID_AFATECH_AF9035_10030x1003
#define USB_PID_AFATECH_AF9035_90350x9035
#define USB_PID_TREKSTOR_DVBT 0x901b
+#define USB_PID_TREKSTOR_TERRES_2_00xC803
#define USB_VID_ALINK_DTU 0xf170
#define USB_PID_ANSONIC_DVBT_USB 0x6000
#define USB_PID_ANYSEE 0x861f
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 88b5ea1..d0d23f2 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1236,6 +1236,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
rtl2832u_props, NOXON DAB/DAB+ USB dongle, NULL) },
{ DVB_USB_DEVICE(USB_VID_REALTEK, 0x2838,
rtl2832u_props, Realtek RTL2832U reference design, NULL) },
+ { DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_TREKSTOR_TERRES_2_0,
+ rtl2832u_props, Trekstor DVB-T Stick Terres 2.0, NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
1.7.9.5
--
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
