Re: [RFCv1 PATCH 4/9] v4l2-ctrls: add per-control events.
Hi Hans,
Thanks for the reply.
Hans Verkuil wrote:
Hi Hans,
I have some more comments below. :-)
Hans Verkuil wrote:
Whenever a control changes value an event is sent to anyone that
subscribed
to it.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
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 media/v4l2-ioctl.h
#include media/v4l2-device.h
#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
#include media/v4l2-dev.h
/* 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?
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 agree with all your responses below on locking.
Thanks.
Regards,
--
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
Re: OMAP3 ISP deadlocks on my new arm
Hi Bastian,
On Thu, Apr 14, 2011 at 1:36 PM, Bastian Hecht hec...@googlemail.com wrote:
Yeah!
S... when I initialized the the camera (loading a 108 bytes
register listing) I just let run the camera and sent images. So I
first realized a counter overflow if (count++ 10) after a few
seconds. But this seemed to be handled correctly (ignore and delete
HS_VS_IRQ flag) while after 2 or more yavta calls it made the driver
hang.
I modified my register listing so that the chip gets booted silently.
In
static struct v4l2_subdev_video_ops framix_subdev_video_ops = {
.s_stream = framix_s_stream, ===
};
I correctly check the stream status now and enable/disable the camera signals.
I am unsure whether the isp should be able to handle an ongoing data
stream independently of ISP_PIPELINE_STREAM_STOPPED.
streamoff should finish synchronously with last ongoing data. So, it
should have no ongoing data afterwards. Was that your question?
Br,
David Cohen
If you decide it should, I will gladly help you find out more, just
ask. It worked on an OMAP3530 before, but I do not know if it is the
hardware or isp software that changed. Unfortunately I can't get an
3530 anymore (I trashed mine...).
You helped me so much! Big thanks.
Bastian Hecht
2011/4/14 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
On Thursday 14 April 2011 10:33:12 Bastian Hecht wrote:
2011/4/13 Sakari Ailus sakari.ai...@maxwell.research.nokia.com:
Bastian Hecht wrote:
Hello people,
Hi Bastian,
I'm cc'ing Laurent.
I switched to the new DM3730 from IGEP and while it's supposed to be
(almost) the same as the 3530 Version the isp deadlocks
deterministically after I start capturing the second time with yavta.
Does the capture work the first time w/o issues?
Yes, I can always run yavta once capturing 4 frames (3 skipped, last
saved). It usually deadlocks when running yavta the second time but I had
1 successful 2nd try (out of 20 maybe).
All extra locking debug output is enabled in the kernel .config.
I'm not fully certain on what this exactly is that you have below, but
it looks like your system is staying in interrupt context all the time.
My guess is that the ISP is producing interrupts that the driver is not
handling properly, causing the interrupt handler to be called again
immediately.
Nice! OK, I'd like to fully understand the panic output, maybe you can
help there:
After
[ 376.016906] [c02e3dc4] (_raw_spin_unlock_irqrestore+0x40/0x44)
from [bf01f678] (omap3isp_video_queue_streamon+0x80/0x90
the IRQs get enabled again. Immediately our offending irq wants to get
served but noone is clearing it.
At some time, the timer interrupt triggers the watchdog for a kernel panic.
So the last exception block is the process context that is currently
active. But why are there 2 irq routines displayed? Is the middle one the
hardware handling that causes a software irq to be triggered (upper
block)?
So my next step could be to find the unhandled irq number?
If the problem is caused by an interrupt storm, the following patch will make
your system responsive again after a couple of seconds (but will kill the ISP
driver :-)). If it doesn't, the problem is likely caused by something else.
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index de2dec5..6497300 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -462,6 +464,7 @@ static irqreturn_t isp_isr(int irq, void *_isp)
IRQ0STATUS_CCDC_VD0_IRQ |
IRQ0STATUS_CCDC_VD1_IRQ |
IRQ0STATUS_HS_VS_IRQ;
+ static unsigned int count = 0;
struct isp_device *isp = _isp;
u32 irqstatus;
int ret;
@@ -469,6 +472,11 @@ static irqreturn_t isp_isr(int irq, void *_isp)
irqstatus = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
isp_reg_writel(isp, irqstatus, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
+ if (count++ 10) {
+ isp_disable_interrupts(isp);
+ return IRQ_HANDLED;
+ }
+
isp_isr_sbl(isp);
if (irqstatus IRQ0STATUS_CSIA_IRQ) {
Do you have the same sensor working on OMAP 3530?
I never had this problem on an OMAP 3530, although I better test it
again with the current setup. I try to get my hands on an 3530 today.
I am unsure if this is an ISP thing or a problem in the
interrupthandling software.
This has probably something to do with the ISP driver. :-)
The first block is the watchdog that detects the deadlock. The last
block is in the isp-code but how can it hang when trying to UNlock a
spinlock? I am unsure about the 2nd block.
The assembler code of __irq_svc is located in
arch/arm/kernel/entry-armv.S Maybe I should try on
[PATCH] dvb-usb return device errors to demuxer.
Return device errors to demuxer from on/off streamming and
pid filtering.
Please test this patch with all dvb-usb devices.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/dvb-usb-dvb.c | 32 --
1 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
index df1ec3e..965698b 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
@@ -12,7 +12,7 @@
static int dvb_usb_ctrl_feed(struct dvb_demux_feed *dvbdmxfeed, int onoff)
{
struct dvb_usb_adapter *adap = dvbdmxfeed-demux-priv;
- int newfeedcount,ret;
+ int newfeedcount, ret;
if (adap == NULL)
return -ENODEV;
@@ -24,9 +24,12 @@ static int dvb_usb_ctrl_feed(struct dvb_demux_feed
*dvbdmxfeed, int onoff)
deb_ts(stop feeding\n);
usb_urb_kill(adap-stream);
- if (adap-props.streaming_ctrl != NULL)
- if ((ret = adap-props.streaming_ctrl(adap,0)))
- err(error while stopping stream.);
+ if (adap-props.streaming_ctrl != NULL) {
+ ret = adap-props.streaming_ctrl(adap, 0);
+ err(error while stopping stream.);
+ if (ret 0)
+ return ret;
+ }
}
adap-feedcount = newfeedcount;
@@ -49,17 +52,24 @@ static int dvb_usb_ctrl_feed(struct dvb_demux_feed
*dvbdmxfeed, int onoff)
deb_ts(controlling pid parser\n);
if (adap-props.caps DVB_USB_ADAP_HAS_PID_FILTER
- adap-props.caps
DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF
- adap-props.pid_filter_ctrl != NULL)
- if
(adap-props.pid_filter_ctrl(adap,adap-pid_filtering) 0)
+ adap-props.caps
+ DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF
+ adap-props.pid_filter_ctrl != NULL) {
+ ret = adap-props.pid_filter_ctrl(adap,
+ adap-pid_filtering);
+ if (ret 0) {
err(could not handle pid_parser);
-
+ return ret;
+ }
+ }
deb_ts(start feeding\n);
- if (adap-props.streaming_ctrl != NULL)
- if (adap-props.streaming_ctrl(adap,1)) {
+ if (adap-props.streaming_ctrl != NULL) {
+ ret = adap-props.streaming_ctrl(adap, 1);
+ if (ret 0) {
err(error while enabling fifo.);
- return -ENODEV;
+ return ret;
}
+ }
}
return 0;
--
1.7.4.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] [media] lmedm04: Do not unlock mutex if mutex_lock_interruptible failed
On Sat, 2011-04-16 at 01:01 +0100, Malcolm Priestley wrote:
On Sat, 2011-04-16 at 00:40 +0400, Alexey Khoroshilov wrote:
There are a couple of places where mutex_unlock() is called even
if mutex_lock_interruptible() failed. The patch fixes the issue.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/media/dvb/dvb-usb/lmedm04.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c
b/drivers/media/dvb/dvb-usb/lmedm04.c
index f2db012..40907df 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.c
+++ b/drivers/media/dvb/dvb-usb/lmedm04.c
@@ -591,9 +591,10 @@ static int lme2510_streaming_ctrl(struct
dvb_usb_adapter *adap, int onoff)
else {
deb_info(1, STM Steam Off);
/* mutex is here only to avoid collision with I2C */
- ret = mutex_lock_interruptible(adap-dev-i2c_mutex);
+ if (mutex_lock_interruptible(adap-dev-i2c_mutex) 0)
+ return -EAGAIN;
- ret |= lme2510_usb_talk(adap-dev, clear_reg_3,
+ ret = lme2510_usb_talk(adap-dev, clear_reg_3,
sizeof(clear_reg_3), rbuf, rlen);
st-stream_on = 0;
st-i2c_talk_onoff = 1;
Unfortunately dvb-usb does not provide -EAGAIN on streaming_ctrl
stopping and returns 0 instead.
I have added a patch to dvb-usb to return device errors to the demuxer
This patch may now be applied.
Tested by: Malcolm Priestley tvbox...@gmail.com
Regards
Malcolm
--
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:Sat Apr 16 19:00:41 CEST 2011 git hash:d9954d8547181f9a6a23f835cc1413732700b785 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/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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: stb0899 signal strength value in dvb-s2l
Hi everyone, Using a KNC-1 DVB-S2 board I noticed stb0899_read_signal_strength() in stb0899_drv.c always return the same value (1450) in dvb-s2 whatever the signal power is. It seems STB0899_READ_S2REG(STB0899_DEMOD, IF_AGC_GAIN) macro always returns zero. Any idea of what is causing this ? Try - reg = STB0899_READ_S2REG(STB0899_DEMOD, IF_AGC_GAIN); + reg = STB0899_READ_S2REG(STB0899_S2DEMOD, IF_AGC_GAIN); Than it is working, Johns -- 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
