[POSSIBLE SPAM] Vacancy
Nous voulons que les gens innovantes pour rejoindre notre teams.Tullow huile Accra Ghana doit expatriés dans les services médicaux, de l'ingénierie, des gestionnaires administratifs, chefs, spécialiste du marketing pour l'emploi urgent. surmit votre Cv à un emploi. pouvez-vous parler anglais Tullow Oil plc annonces équipe -- 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: OK
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: Tue Jun 10 04:00:19 CEST 2014 git branch: test git hash: 5ea878796f0a1d9649fe43a6a09df53d3915c0ef gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-5.slh.5-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 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 Media Infrastructure API 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
Urgent Notification Free Lotto Award(Reference:WIN-37-14-29-14)
>From claim´s processing office. Free Lotto Lottery Award Notification Confirmation Ticket No: 33-48-19-H5H Reference:WIN-37-14-29-14 You have won( 1 Million Euros )in the Free Lotto Lottery Award 2014 held in Madrid Spain This email was sent to notify you officially as you are advise to contact the claim´s processing office with your details immediately for claim, Contact Person: Martinez Adela Contact Email: freelottoaward...@gmail.com Signed (Announcer) Director, Cooperate HR and Communication. FREE LOTTO LOTTERY AWARD -- 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] au0828: add missing tuner Kconfig dependency
The analog part of au0828 is missing the tuner Kconfig dependency. That makes the device to not work while in analog mode. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/au0828/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/usb/au0828/Kconfig b/drivers/media/usb/au0828/Kconfig index 953a37c613b1..fe48403eadd0 100644 --- a/drivers/media/usb/au0828/Kconfig +++ b/drivers/media/usb/au0828/Kconfig @@ -20,6 +20,7 @@ config VIDEO_AU0828_V4L2 bool "Auvitek AU0828 v4l2 analog video support" depends on VIDEO_AU0828 && VIDEO_V4L2 select DVB_AU8522_V4L if MEDIA_SUBDRV_AUTOSELECT + select VIDEO_TUNER default y ---help--- This is a video4linux driver for Auvitek's USB device. -- 1.9.3 -- 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] dm644x_ccdc: remove check for CONFIG_DM644X_VIDEO_PORT_ENABLE
Hi Paul, Thanks for the patch. On Thu, May 22, 2014 at 8:42 PM, Paul Bolle wrote: > A check for CONFIG_DM644X_VIDEO_PORT_ENABLE was added in v2.6.32. The > related Kconfig symbol was never added so this check has always > evaluated to false. Remove that check. > Applied. Thanks, --Prabhakar Lad > Signed-off-by: Paul Bolle > --- > Untested. > > Related, trivial, cleanup: make ccdc_enable_vport() a oneliner. > > drivers/media/platform/davinci/dm644x_ccdc.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/drivers/media/platform/davinci/dm644x_ccdc.c > b/drivers/media/platform/davinci/dm644x_ccdc.c > index 30fa08405d61..07e98df3d867 100644 > --- a/drivers/media/platform/davinci/dm644x_ccdc.c > +++ b/drivers/media/platform/davinci/dm644x_ccdc.c > @@ -581,13 +581,8 @@ void ccdc_config_raw(void) > config_params->alaw.enable) > syn_mode |= CCDC_DATA_PACK_ENABLE; > > -#ifdef CONFIG_DM644X_VIDEO_PORT_ENABLE > - /* enable video port */ > - val = CCDC_ENABLE_VIDEO_PORT; > -#else > /* disable video port */ > val = CCDC_DISABLE_VIDEO_PORT; > -#endif > > if (config_params->data_sz == CCDC_DATA_8BITS) > val |= (CCDC_DATA_10BITS & CCDC_FMTCFG_VPIN_MASK) > -- > 1.9.0 > -- 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 7/8] au0828: Only alt setting logic when needed
It seems that there's a bug at au0828 hardware/firmware
related to alternate setting: when the device is already at
alt 5, a further call causes the URBs to receive -ESHUTDOWN.
I found two different encarnations of this issue:
1) at qv4l2, it fails the second time we try to open the
video screen;
2) at xawtv, when audio underrun occurs, with is very
frequent, at least on my test machine.
The fix is simple: just check if alt=5 before calling
set_usb_interface().
Cc: sta...@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/usb/au0828/au0828-video.c | 34 -
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-video.c
b/drivers/media/usb/au0828/au0828-video.c
index 4aa1d7a1641b..85d83ca5a4cd 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -787,11 +787,27 @@ static int au0828_i2s_init(struct au0828_dev *dev)
/*
* Auvitek au0828 analog stream enable
- * Please set interface0 to AS5 before enable the stream
*/
static int au0828_analog_stream_enable(struct au0828_dev *d)
{
+ struct usb_interface *iface;
+ int ret;
+
dprintk(1, "au0828_analog_stream_enable called\n");
+
+ iface = usb_ifnum_to_if(d->usbdev, 0);
+ if (iface && iface->cur_altsetting->desc.bAlternateSetting != 5) {
+ dprintk(1, "Changing intf#0 to alt 5\n");
+ /* set au0828 interface0 to AS5 here again */
+ ret = usb_set_interface(d->usbdev, 0, 5);
+ if (ret < 0) {
+ printk(KERN_INFO "Au0828 can't set alt setting to
5!\n");
+ return -EBUSY;
+ }
+ }
+
+ /* FIXME: size should be calculated using d->width, d->height */
+
au0828_writereg(d, AU0828_SENSORCTRL_VBI_103, 0x00);
au0828_writereg(d, 0x106, 0x00);
/* set x position */
@@ -1002,15 +1018,6 @@ static int au0828_v4l2_open(struct file *filp)
return -ERESTARTSYS;
}
if (dev->users == 0) {
- /* set au0828 interface0 to AS5 here again */
- ret = usb_set_interface(dev->usbdev, 0, 5);
- if (ret < 0) {
- mutex_unlock(&dev->lock);
- printk(KERN_INFO "Au0828 can't set alternate to 5!\n");
- kfree(fh);
- return -EBUSY;
- }
-
au0828_analog_stream_enable(dev);
au0828_analog_stream_reset(dev);
@@ -1252,13 +1259,6 @@ static int au0828_set_format(struct au0828_dev *dev,
unsigned int cmd,
}
}
- /* set au0828 interface0 to AS5 here again */
- ret = usb_set_interface(dev->usbdev, 0, 5);
- if (ret < 0) {
- printk(KERN_INFO "Au0828 can't set alt setting to 5!\n");
- return -EBUSY;
- }
-
au0828_analog_stream_enable(dev);
return 0;
--
1.9.3
--
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 00/43] i.MX6 Video capture
On 06/08/2014 01:36 AM, Hans Verkuil wrote: > Hi Steve! > > On 06/07/2014 11:56 PM, Steve Longerbeam wrote: >> Hi all, >> >> This patch set adds video capture support for the Freescale i.MX6 SOC. >> >> It is a from-scratch standardized driver that works with community >> v4l2 utilities, such as v4l2-ctl, v4l2-cap, and the v4l2src gstreamer >> plugin. It uses the latest v4l2 interfaces (subdev, videobuf2). >> Please see Documentation/video4linux/mx6_camera.txt for it's full list >> of features! >> >> The first 38 patches: >> >> - prepare the ipu-v3 driver for video capture support. The current driver >> contains only video display functionality to support the imx DRM drivers. >> At some point ipu-v3 should be moved out from under staging/imx-drm since >> it will no longer only support DRM. >> >> - Adds the device tree nodes and OF graph bindings for video capture support >> on sabrelite, sabresd, and sabreauto reference platforms. >> >> The new i.MX6 capture host interface driver is at patch 39. >> >> To support the sensors found on the sabrelite, sabresd, and sabreauto, >> three patches add sensor subdev's for parallel OV5642, MIPI CSI-2 OV5640, >> and the ADV7180 decoder chip, beginning at patch 40. >> >> There is an existing adv7180 subdev driver under drivers/media/i2c, but >> it needs some extra functionality to work on the sabreauto. It will need >> OF graph bindings support and gpio for a power-on pin on the sabreauto. >> It would also need to send a new subdev notification to take advantage >> of decoder status change handling provided by the host driver. This >> feature makes it possible to correctly handle "hot" (while streaming) >> signal lock/unlock and autodetected video standard changes. > A new V4L2_EVENT_SOURCE_CHANGE event has just been added for that. Hello Hans! Ok, V4L2_EVENT_SOURCE_CHANGE looks promising. But v4l2-framework.txt states that v4l2 events are passed to userland. So I want to make sure this framework will also work internally; that is, the decoder subdev (adv7180) can generate this event and it can be subscribed by the capture host driver. That it can be passed to userland is fine and would be useful, it's not necessary in this case. > >> Usage notes are found in Documentation/video4linux/mx6_camera.txt for the >> above three reference platforms. >> >> The driver source is under drivers/staging/media/imx6/capture/. > Thank you for this patch series! Much appreciated that this hardware is > finally going to supported with a proper driver. > > I did a quick scan of the driver and I noticed a few things that need > to be fixed: instead of implementing g/s_crop, implement g/s_selection: > new drivers should implement the selection API and they will get the crop > API for free. Ok, I'll look into g/s_selection for v2 patches. > > You should use the vb2 helper functions (vb2_fop_*, vb2_ioctl_*) unless > there is a good reason not to do it. Those functions should simplify the > code and they give you proper 'streaming ownership'. See also the example > code Documentation/video4linux/v4l2-pci-skeleton.c. Ok, ditto. > > Finally you should run the v4l2-compliance test tool and fix any failures. > > That tool is part of git://linuxtv.org/v4l-utils.git. Always compile from > that repository to be sure you use the latest code. > > Test first with 'v4l2-compliance'. When all issues are fixed, then test > with 'v4l2-compliance -s' to test actual streaming behavior as well. > > When you post v2 of this patch series I want to see the output of > 'v4l2-compliance -s'! New drivers should pass v4l2-compliance. However, > this is a staging driver so I won't be that strict, but it seems to be > the intention that this driver will become a mainline driver, so I would > recommend to fix any issues now rather than later. Very cool, I'll make sure all v4l2-compliance issues are resolved. I can start that before issuing the v2 patches. > > If you have questions about v4l2-compliance it it might be easiest to > set up an irc session where we go through them. In that case mail me > so we can set up a time and date to do that. I'm in timezone UTC+2. Thanks for the offer. Give me a few days to compose v2 patches and I'll start looking at v4l2-compliance. Steve -- 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 5/6] update reference, kerneltrap.org no longer works
On Mon, Jun 9, 2014 at 7:55 PM, Pranith Kumar wrote: > kerneltrap.org no longer works, update to a working reference > > Signed-off-by: Pranith Kumar Acked-by: Alexey Klimov Thanks! -- Best regards, Klimov Alexey -- 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 5/6] update reference, kerneltrap.org no longer works
kerneltrap.org no longer works, update to a working reference Signed-off-by: Pranith Kumar --- drivers/media/radio/radio-mr800.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/radio/radio-mr800.c b/drivers/media/radio/radio-mr800.c index a360227..f476071 100644 --- a/drivers/media/radio/radio-mr800.c +++ b/drivers/media/radio/radio-mr800.c @@ -32,7 +32,7 @@ * achievements (specifications given). * Also, Faidon Liambotis wrote nice driver for this radio * in 2007. He allowed to use his driver to improve current mr800 radio driver. - * http://kerneltrap.org/mailarchive/linux-usb-devel/2007/10/11/342492 + * http://www.spinics.net/lists/linux-usb-devel/msg10109.html * * Version 0.01: First working version. * It's required to blacklist AverMedia USB Radio -- 1.9.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
[PATCH 5/6] update reference, kerneltrap.org no longer works
kerneltrap.org no longer works, update to a working reference Signed-off-by: Pranith Kumar --- drivers/media/radio/radio-mr800.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/radio/radio-mr800.c b/drivers/media/radio/radio-mr800.c index a360227..f476071 100644 --- a/drivers/media/radio/radio-mr800.c +++ b/drivers/media/radio/radio-mr800.c @@ -32,7 +32,7 @@ * achievements (specifications given). * Also, Faidon Liambotis wrote nice driver for this radio * in 2007. He allowed to use his driver to improve current mr800 radio driver. - * http://kerneltrap.org/mailarchive/linux-usb-devel/2007/10/11/342492 + * http://www.spinics.net/lists/linux-usb-devel/msg10109.html * * Version 0.01: First working version. * It's required to blacklist AverMedia USB Radio -- 1.9.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] cx18: remove duplicate CX18_ALSA_DBGFLG_WARN define
Btw, the ivtv-de...@ivtvdriver.org list appears to be subscribers-only even though it says moderated in the MAINTAINERS file. It's a waste of time to list it in MAINTAINERS at that point. regards, dan carpenter -- 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] [media] cx18: remove duplicate CX18_ALSA_DBGFLG_WARN define
The CX18_ALSA_DBGFLG_WARN is cut and pasted twice and we can delete the second instance. Signed-off-by: Dan Carpenter diff --git a/drivers/media/pci/cx18/cx18-alsa.h b/drivers/media/pci/cx18/cx18-alsa.h index 447da37..2718be2 100644 --- a/drivers/media/pci/cx18/cx18-alsa.h +++ b/drivers/media/pci/cx18/cx18-alsa.h @@ -49,7 +49,6 @@ static inline void snd_cx18_unlock(struct snd_cx18_card *cxsc) } #define CX18_ALSA_DBGFLG_WARN (1 << 0) -#define CX18_ALSA_DBGFLG_WARN (1 << 0) #define CX18_ALSA_DBGFLG_INFO (1 << 1) #define CX18_ALSA_DEBUG(x, type, fmt, args...) \ -- 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] [media] zoran: remove duplicate ZR050_MO_COMP define
The ZR050_MO_COMP define is cut and pasted twice so we can delete the
second instance.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/pci/zoran/zr36050.h
b/drivers/media/pci/zoran/zr36050.h
index 9f52f0c..ea083ad 100644
--- a/drivers/media/pci/zoran/zr36050.h
+++ b/drivers/media/pci/zoran/zr36050.h
@@ -126,7 +126,6 @@ struct zr36050 {
/* zr36050 mode register bits */
#define ZR050_MO_COMP0x80
-#define ZR050_MO_COMP0x80
#define ZR050_MO_ATP 0x40
#define ZR050_MO_PASS2 0x20
#define ZR050_MO_TLM 0x10
--
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] [media] davinci: vpfe: dm365: remove duplicate RSZ_LPF_INT_MASK
The RSZ_LPF_INT_MASK define is cut and pasted twice so we can remove the second instance. Signed-off-by: Dan Carpenter diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.h b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.h index 010fdb2..81176fb 100644 --- a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.h +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.h @@ -479,7 +479,6 @@ #define RSZ_TYP_Y_SHIFT0 #define RSZ_TYP_C_SHIFT1 #define RSZ_LPF_INT_MASK 0x3f -#define RSZ_LPF_INT_MASK 0x3f #define RSZ_LPF_INT_C_SHIFT6 #define RSZ_H_PHS_MASK 0x3fff #define RSZ_H_DIF_MASK 0x3fff -- 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/RFC v2 2/2] libv4l2: release the lock before doing a DQBUF
Hi,
On 06/09/2014 03:51 PM, Thiago Santos wrote:
> In blocking mode, if there are no buffers available the DQBUF will block
> waiting for a QBUF to be called but it will block holding the streaming
> lock which will prevent any QBUF from happening, causing a deadlock.
>
> Can be tested with: v4l2grab -t -b -s 2000
>
> Signed-off-by: Thiago Santos
Looks good now:
Acked-by: Hans de Goede
I'll leave reviewing the 1st patch to someone else. Gregor and/or
Mauro feel free to push this one.
Regards,
Hans
> ---
> lib/libv4l2/libv4l2-priv.h | 1 +
> lib/libv4l2/libv4l2.c | 13 -
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/lib/libv4l2/libv4l2-priv.h b/lib/libv4l2/libv4l2-priv.h
> index 585273c..ff4c8d2 100644
> --- a/lib/libv4l2/libv4l2-priv.h
> +++ b/lib/libv4l2/libv4l2-priv.h
> @@ -92,6 +92,7 @@ struct v4l2_dev_info {
> unsigned char *frame_pointers[V4L2_MAX_NO_FRAMES];
> int frame_sizes[V4L2_MAX_NO_FRAMES];
> int frame_queued; /* 1 status bit per frame */
> + int frame_info_generation;
> /* mapping tracking of our fake (converting mmap) frame buffers */
> unsigned char frame_map_count[V4L2_MAX_NO_FRAMES];
> /* buffer when doing conversion and using read() for read() */
> diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
> index c4d69f7..1dcf34d 100644
> --- a/lib/libv4l2/libv4l2.c
> +++ b/lib/libv4l2/libv4l2.c
> @@ -282,7 +282,7 @@ static int v4l2_dequeue_and_convert(int index, struct
> v4l2_buffer *buf,
> unsigned char *dest, int dest_size)
> {
> const int max_tries = V4L2_IGNORE_FIRST_FRAME_ERRORS + 1;
> - int result, tries = max_tries;
> + int result, tries = max_tries, frame_info_gen;
>
> /* Make sure we have the real v4l2 buffers mapped */
> result = v4l2_map_buffers(index);
> @@ -290,9 +290,12 @@ static int v4l2_dequeue_and_convert(int index, struct
> v4l2_buffer *buf,
> return result;
>
> do {
> + frame_info_gen = devices[index].frame_info_generation;
> + pthread_mutex_unlock(&devices[index].stream_lock);
> result = devices[index].dev_ops->ioctl(
> devices[index].dev_ops_priv,
> devices[index].fd, VIDIOC_DQBUF, buf);
> + pthread_mutex_lock(&devices[index].stream_lock);
> if (result) {
> if (errno != EAGAIN) {
> int saved_err = errno;
> @@ -305,6 +308,11 @@ static int v4l2_dequeue_and_convert(int index, struct
> v4l2_buffer *buf,
>
> devices[index].frame_queued &= ~(1 << buf->index);
>
> + if (frame_info_gen != devices[index].frame_info_generation) {
> + errno = -EINVAL;
> + return -1;
> + }
> +
> result = v4lconvert_convert(devices[index].convert,
> &devices[index].src_fmt,
> &devices[index].dest_fmt,
> devices[index].frame_pointers[buf->index],
> @@ -839,6 +847,7 @@ int v4l2_dup(int fd)
>
> static int v4l2_check_buffer_change_ok(int index)
> {
> + devices[index].frame_info_generation++;
> v4l2_unmap_buffers(index);
>
> /* Check if the app itself still is using the stream */
> @@ -1294,9 +1303,11 @@ no_capture_request:
> }
>
> if (!v4l2_needs_conversion(index)) {
> + pthread_mutex_unlock(&devices[index].stream_lock);
> result = devices[index].dev_ops->ioctl(
> devices[index].dev_ops_priv,
> fd, VIDIOC_DQBUF, buf);
> + pthread_mutex_lock(&devices[index].stream_lock);
> if (result) {
> saved_err = errno;
> V4L2_PERROR("dequeuing buf");
>
--
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: [RFC ATTN] Multi-dimensional matrices
Hi Mauro and Hans,
On Mon, May 12, 2014 at 09:56:05AM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 12 May 2014 13:06:45 +0200
> Hans Verkuil escreveu:
>
> > Hi all,
> >
> > During the mini-summit we discussed multi-dimensional matrix support.
> > My proposal only added support for 2D matrices. It turns out that there
> > is at least one case where a 3D matrix is used (a 17x17x17 matrix which
> > maps an RGB value to another RGB value, with R, G and B being the matrix
> > indices).
> >
> > I was requested to look into this a bit more and how it should be supported.
> >
> > One option is to support any number of dimensions by using a pointer to an
> > array of dimension sizes:
> >
> > __u32 dimensions;
> > __u32 *dims;
> >
> > The problem with this IMHO is that this complicates using the
> > VIDIOC_QUERY_EXT_CTRL
> > ioctl: you always need to supply a separate array when you call this ioctl,
> > and remember to set 'dimensions' to the size of your array. And be able to
> > handle the case where there are more dimensions than the size of your array
> > at which time you need to resize it and call the ioctl again.
>
> I see.
>
> >
> > My problem with that is that I think that that is simply not worth the
> > trouble.
> >
> > I agree that supporting 3D matrices makes sense, and perhaps 4D as well (in
> > case ARGB values are used as indices into the 4D matrix). But I think it is
> > unlikely
> > that 5D or up matrices will be seen in actual hardware (if only because of
> > the size of the data involved), and if those will appear then it is always
> > possible to implement them as a 4D matrix of a struct that contains the
> > remaining dimensions. E.g.:
> >
> > struct my_drv_type {
> > __u32 m[2][3];
> > };
> >
> > struct my_drv_type ctrl_matrix[4][3][2][2];
> >
> > This really is a 6D matrix '__u32 m[4][3][2][2][2][3];'.
> >
> > In other words, I am really opposed to add support for any number of
> > dimensions,
> > I think that is overengineering and I believe that there are alternative
> > solutions
> > should we encounter hardware that does something so strange.
> >
> > So the rest of my RFC outlines my proposal for extending the number of
> > dimensions
> > to a fixed number. For the sake of argument I'm going with 4 dimensions.
> >
> > In my current proposal the v4l2_query_ext_ctrl struct has two fields
> > describing
> > the dimensions of the matrix: width and height.
> >
> > A 1D matrix (aka array) means that one of the two will be set to 1. These
> > fields
> > are always >= 1. The number of elements in the matrix will always be width
> > * height.
> >
> > If we go to a higher number of dimensions then you do need a new 'elems' or
> > 'elements'
> > field that has the total number of elements in the matrix (for a 2D matrix
> > that would
> > be width * height). It just becomes too cumbersome in applications to
> > always have to
> > multiply all the dimension sizes to get the number of elements.
> >
> > The approach I want to take is to replace 'width' and 'height' by this:
> >
> > #define V4L2_CTRL_MAX_DIMS 4
> >
> > __u32 elems;
> > __u32 dimensions;
> > __u32 dims[V4L2_CTRL_MAX_DIMS];
> >
> > So if 'dimensions' is 2, then dims[0] would be the height and dims[1] the
> > width.
> > For 3D [0] would be depth, [1] height, [2] width.
> >
> > The remaining dims values would be 0.
>
> I really don't like this approach. mapping a 1D array as a 4D
> array sounds a really crappy design API. Also, whatever random
> value we use for the number of dimensions, it would be just an
> arbitrary number that we'll need to live with that forever.
>
> I can see only two sane approaches: either add support for just
> arrays (e. g. 1D), in a way that a 2D matrix would be an array of
> array, a 3D would be an array of array of array, and so on, or
> we should allow supporting an arbitrary number of dimensions.
>
> There is an alternative: we could use the support for not fixed
> size ioctls, like what's done at input subsystem (see, for example,
> how EVIOCGKEY is handled at drivers/input/evdev.c):
>
> #define EVIOCGKEY(len)_IOC(_IOC_READ, 'E', 0x18, len)
> /* get global key state */
>
> And the code that handles it gets the size via:
>
> size = _IOC_SIZE(cmd);
>
> We could do something similar, like:
>
> struct v4l2_query_ext_ctrl {
> __u32 id;
> __u32 type;
> char name[32];
> __s64 minimum;
> __s64 maximum;
> __u64 step;
> __s64 default_value;
> __u32 flags;
> __u32 elem_size;
> __u32 reserved[18];
> __u32 n_dimensions;
> __u32 *dimensions;
> } __attribute__((packed));
>
> #define VIDIOC_QUERY_EXT_CTRL(len) _IOC(_IOC_READ|_IOC_WRITE, 'V', 103,
> sizeof(struct v4l2_query_ext_ctrl) + (len - 1) * sizeof(__u32 *))
To just enumerate the controls, the user would have to call different IOCTLs
to even know what kind of controls exist. I would expect that certain
controls could have different dimensions dependi
[PATCH/RFC v2 1/2] v4l2grab: Add threaded producer/consumer option
Adds options to allow the buffer dqbuf to happen on one thread while
the qbuf happens on another. This is useful to test concurrency access to
the v4l2 features. To enable this, 3 new options were added:
t: enable threaded mode (off by default and will use the loop)
b: enable blocking io mode (off by default
s: how much the consumer thread will sleep after reading a buffer, this is to
simulate the time that it takes to process a buffer in a real application
(in ms)
For example, you can simulate an application that takes 1s to process a buffer
with:
v4l2grab -t -b -s 1000
Signed-off-by: Thiago Santos
---
contrib/test/Makefile.am | 2 +-
contrib/test/v4l2grab.c | 261 +++
2 files changed, 219 insertions(+), 44 deletions(-)
diff --git a/contrib/test/Makefile.am b/contrib/test/Makefile.am
index 80c7665..c2e3860 100644
--- a/contrib/test/Makefile.am
+++ b/contrib/test/Makefile.am
@@ -25,7 +25,7 @@ pixfmt_test_CFLAGS = $(X11_CFLAGS)
pixfmt_test_LDFLAGS = $(X11_LIBS)
v4l2grab_SOURCES = v4l2grab.c
-v4l2grab_LDADD = ../../lib/libv4l2/libv4l2.la
../../lib/libv4lconvert/libv4lconvert.la
+v4l2grab_LDADD = ../../lib/libv4l2/libv4l2.la
../../lib/libv4lconvert/libv4lconvert.la -lpthread
v4l2gl_SOURCES = v4l2gl.c
v4l2gl_LDFLAGS = $(X11_LIBS) $(GL_LIBS) $(GLU_LIBS)
diff --git a/contrib/test/v4l2grab.c b/contrib/test/v4l2grab.c
index 674cbe7..3e1be3d 100644
--- a/contrib/test/v4l2grab.c
+++ b/contrib/test/v4l2grab.c
@@ -24,8 +24,10 @@
#include
#include "../../lib/include/libv4l2.h"
#include
+#include
-#define CLEAR(x) memset(&(x), 0, sizeof(x))
+#define CLEAR_P(x,s) memset((x), 0, s)
+#define CLEAR(x) CLEAR_P(&(x), sizeof(x))
struct buffer {
void *start;
@@ -46,22 +48,206 @@ static void xioctl(int fh, unsigned long int request, void
*arg)
}
}
+/* Used by the multi thread capture version */
+struct buffer_queue {
+ struct v4l2_buffer *buffers;
+ int buffers_size;
+
+ int read_pos;
+ int write_pos;
+ int n_frames;
+
+ int fd;
+
+ pthread_mutex_t mutex;
+ pthread_cond_t buffer_cond;
+};
+
+/* Gets a buffer and puts it in the buffers list at write position, then
+ * notifies the consumer that a new buffer is ready to be used */
+static void *produce_buffer (void * p)
+{
+ struct buffer_queue *bq;
+ fd_set fds;
+ struct timeval tv;
+ int i;
+ struct v4l2_buffer *buf;
+ int r;
+
+ bq = p;
+
+ for (i = 0; i < bq->n_frames; i++) {
+ printf ("Prod: %d\n", i);
+ buf = &bq->buffers[bq->write_pos % bq->buffers_size];
+ do {
+ FD_ZERO(&fds);
+ FD_SET(bq->fd, &fds);
+
+ /* Timeout. */
+ tv.tv_sec = 2;
+ tv.tv_usec = 0;
+
+ r = select(bq->fd + 1, &fds, NULL, NULL, &tv);
+ } while ((r == -1 && (errno == EINTR)));
+ if (r == -1) {
+ perror("select");
+ pthread_exit (NULL);
+ return NULL;
+ }
+
+ CLEAR_P(buf, sizeof(struct v4l2_buffer));
+ buf->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ buf->memory = V4L2_MEMORY_MMAP;
+ xioctl(bq->fd, VIDIOC_DQBUF, buf);
+
+ pthread_mutex_lock (&bq->mutex);
+ bq->write_pos++;
+ printf ("Prod: %d (done)\n", i);
+ pthread_cond_signal (&bq->buffer_cond);
+ pthread_mutex_unlock (&bq->mutex);
+
+ }
+
+ pthread_exit (NULL);
+}
+
+/* will create a separate thread that will produce the buffers and put
+ * into a circular array while this same thread will get the buffers from
+ * this array and 'render' them */
+static int capture_threads (int fd, struct buffer *buffers, int bufpool_size,
+ struct v4l2_format fmt, int n_frames,
+ char *out_dir, int sleep_ms)
+{
+ struct v4l2_buffer buf;
+ unsigned inti;
+ struct buffer_queue buf_queue;
+ pthread_t producer;
+ charout_name[25 + strlen(out_dir)];
+ FILE*fout;
+ struct timespec sleeptime;
+
+ if (sleep_ms) {
+ sleeptime.tv_sec = sleep_ms / 1000;
+ sleeptime.tv_nsec = (sleep_ms % 1000) * 100;
+ }
+
+ buf_queue.buffers_size = bufpool_size * 2;
+ buf_queue.buffers = calloc(buf_queue.buffers_size,
+ sizeof(struct v4l2_buffer));
+ buf_queue.fd = fd;
+ buf_queue.read_pos = 0;
+ buf_queue.write_pos = 0;
+ buf_queue.n_frame
[PATCH/RFC v2 2/2] libv4l2: release the lock before doing a DQBUF
In blocking mode, if there are no buffers available the DQBUF will block
waiting for a QBUF to be called but it will block holding the streaming
lock which will prevent any QBUF from happening, causing a deadlock.
Can be tested with: v4l2grab -t -b -s 2000
Signed-off-by: Thiago Santos
---
lib/libv4l2/libv4l2-priv.h | 1 +
lib/libv4l2/libv4l2.c | 13 -
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/lib/libv4l2/libv4l2-priv.h b/lib/libv4l2/libv4l2-priv.h
index 585273c..ff4c8d2 100644
--- a/lib/libv4l2/libv4l2-priv.h
+++ b/lib/libv4l2/libv4l2-priv.h
@@ -92,6 +92,7 @@ struct v4l2_dev_info {
unsigned char *frame_pointers[V4L2_MAX_NO_FRAMES];
int frame_sizes[V4L2_MAX_NO_FRAMES];
int frame_queued; /* 1 status bit per frame */
+ int frame_info_generation;
/* mapping tracking of our fake (converting mmap) frame buffers */
unsigned char frame_map_count[V4L2_MAX_NO_FRAMES];
/* buffer when doing conversion and using read() for read() */
diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index c4d69f7..1dcf34d 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -282,7 +282,7 @@ static int v4l2_dequeue_and_convert(int index, struct
v4l2_buffer *buf,
unsigned char *dest, int dest_size)
{
const int max_tries = V4L2_IGNORE_FIRST_FRAME_ERRORS + 1;
- int result, tries = max_tries;
+ int result, tries = max_tries, frame_info_gen;
/* Make sure we have the real v4l2 buffers mapped */
result = v4l2_map_buffers(index);
@@ -290,9 +290,12 @@ static int v4l2_dequeue_and_convert(int index, struct
v4l2_buffer *buf,
return result;
do {
+ frame_info_gen = devices[index].frame_info_generation;
+ pthread_mutex_unlock(&devices[index].stream_lock);
result = devices[index].dev_ops->ioctl(
devices[index].dev_ops_priv,
devices[index].fd, VIDIOC_DQBUF, buf);
+ pthread_mutex_lock(&devices[index].stream_lock);
if (result) {
if (errno != EAGAIN) {
int saved_err = errno;
@@ -305,6 +308,11 @@ static int v4l2_dequeue_and_convert(int index, struct
v4l2_buffer *buf,
devices[index].frame_queued &= ~(1 << buf->index);
+ if (frame_info_gen != devices[index].frame_info_generation) {
+ errno = -EINVAL;
+ return -1;
+ }
+
result = v4lconvert_convert(devices[index].convert,
&devices[index].src_fmt,
&devices[index].dest_fmt,
devices[index].frame_pointers[buf->index],
@@ -839,6 +847,7 @@ int v4l2_dup(int fd)
static int v4l2_check_buffer_change_ok(int index)
{
+ devices[index].frame_info_generation++;
v4l2_unmap_buffers(index);
/* Check if the app itself still is using the stream */
@@ -1294,9 +1303,11 @@ no_capture_request:
}
if (!v4l2_needs_conversion(index)) {
+ pthread_mutex_unlock(&devices[index].stream_lock);
result = devices[index].dev_ops->ioctl(
devices[index].dev_ops_priv,
fd, VIDIOC_DQBUF, buf);
+ pthread_mutex_lock(&devices[index].stream_lock);
if (result) {
saved_err = errno;
V4L2_PERROR("dequeuing buf");
--
2.0.0
--
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/RFC v2 0/2] libv4l2: fix deadlock when DQBUF in block mode
Hello, thanks for the reviews and comments. I updated the example as suggested by Mauro and reimplemented the deadlock fix as suggested by Hans. Here is the second version of those patches. Thiago Santos (2): v4l2grab: Add threaded producer/consumer option libv4l2: release the lock before doing a DQBUF contrib/test/Makefile.am | 2 +- contrib/test/v4l2grab.c| 261 + lib/libv4l2/libv4l2-priv.h | 1 + lib/libv4l2/libv4l2.c | 13 ++- 4 files changed, 232 insertions(+), 45 deletions(-) -- 2.0.0 -- 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/2] gpio: gpiolib: set gpiochip_remove retval to void
On 06/09/2014 01:29 PM, Lars-Peter Clausen wrote:
> On 06/09/2014 01:18 AM, Ben Dooks wrote:
>> On Fri, May 30, 2014 at 08:16:59PM +0200, Lars-Peter Clausen wrote:
>>> On 05/30/2014 07:33 PM, David Daney wrote:
On 05/30/2014 04:39 AM, Geert Uytterhoeven wrote:
> On Fri, May 30, 2014 at 1:30 PM, abdoulaye berthe
> wrote:
>> --- a/drivers/gpio/gpiolib.c
>> +++ b/drivers/gpio/gpiolib.c
>> @@ -1263,10 +1263,9 @@ static void gpiochip_irqchip_remove(struct
>> gpio_chip *gpiochip);
>>*
>>* A gpio_chip with any GPIOs still requested may not be removed.
>>*/
>> -int gpiochip_remove(struct gpio_chip *chip)
>> +void gpiochip_remove(struct gpio_chip *chip)
>> {
>> unsigned long flags;
>> - int status = 0;
>> unsignedid;
>>
>> acpi_gpiochip_remove(chip);
>> @@ -1278,24 +1277,15 @@ int gpiochip_remove(struct gpio_chip *chip)
>> of_gpiochip_remove(chip);
>>
>> for (id = 0; id < chip->ngpio; id++) {
>> - if (test_bit(FLAG_REQUESTED, &chip->desc[id].flags)) {
>> - status = -EBUSY;
>> - break;
>> - }
>> - }
>> - if (status == 0) {
>> - for (id = 0; id < chip->ngpio; id++)
>> - chip->desc[id].chip = NULL;
>> -
>> - list_del(&chip->list);
>> + if (test_bit(FLAG_REQUESTED, &chip->desc[id].flags))
>> + panic("gpio: removing gpiochip with gpios still
>> requested\n");
>
> panic?
NACK to the patch for this reason. The strongest thing you should do here
is WARN.
That said, I am not sure why we need this whole patch set in the first
place.
>>>
>>> Well, what currently happens when you remove a device that is a
>>> provider of a gpio_chip which is still in use, is that the kernel
>>> crashes. Probably with a rather cryptic error message. So this patch
>>> doesn't really change the behavior, but makes it more explicit what
>>> is actually wrong. And even if you replace the panic() by a WARN()
>>> it will again just crash slightly later.
>>>
>>> This is a design flaw in the GPIO subsystem that needs to be fixed.
>>
>> Surely then the best way is to error out to the module unload and
>> stop the driver being unloaded?
>>
>
> You can't error out on module unload, although that's not really relevant
> here. gpiochip_remove() is typically called when the device that registered
> the GPIO chip is unbound. And despite some remove() callbacks having a
> return type of int you can not abort the removal of a device.
It is a design flaw in many subsystems having providers and consumers,
not only GPIO. The same situation is with clock providers, regulators,
phys, drm_panels, ..., at least it was such last time I have tested it.
The problem is that many frameworks assumes that lifetime of provider is
always bigger than lifetime of its consumers, and this is wrong
assumption - usually it is not possible to prevent unbinding driver from
device, so if the device is a provider there is no way to inform
consumers about his removal.
Some solution for such problems is to use some kind of availability
callbacks for requesting resources (gpios, clocks, regulators,...)
instead of simple 'getters' (clk_get, gpiod_get). Callbacks should
guarantee that the resource is always valid between callback reporting
its availability and callback reporting its removal. Such approach seems
to be complicated at the first sight but it should allow to make the
code safe and as a bonus it will allow to avoid deferred probing.
Btw I have send already RFC for such framework [1].
[1]: https://lkml.org/lkml/2014/4/30/345
Regards
Andrzej
>
> - Lars
>
--
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
Donation to you.
Funds donated to you. Contact email: mrneiltrot...@rogers.com for details -- 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
Kedves felhasználók e-mailben;
Kedves felhasználók e-mailben; Túllépte 23432 box set Web Service / Admin, és akkor nem lesz probléma a küldő és fogadhat e-maileket, amíg újra ellenőrizni. Kérjük, frissítse kattintva linkre, és töltse ki az adatokat, hogy ellenőrizze a számla Kérjük, kövesse az alábbi linkre, és majd másolja és illessze be a böngésző jelölőnégyzetet. http://mailupdattwre322.jigsy.com/ Figyelem! Ha nem, csak korlátozott hozzáférést az e-mail postafiókját. ha frissíteni? számla frissül három napon belül Értesítés a számla véglegesen be kell zárni. Tisztelettel, rendszergazda -- 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: non-working UVC device 058f:5608
On Mon, 2014-06-09 at 12:27 +0200, Johannes Berg wrote:
> Here we go - log + tracing:
> log: http://p.sipsolutions.net/d5926c43d531e3af.txt
> trace: http://johannes.sipsolutions.net/files/xhci.trace.dat.xz
Oh, and this was the kernel diff to commit
963649d735c8b6eb0f97e82c54f02426ff3f1f45:
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index eb009a4..00621cb 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -20,6 +20,8 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#define DEBUG
+
#include "xhci.h"
#define XHCI_INIT_VALUE 0x0
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 6231ce6..70b09cd 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -20,6 +20,8 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#define DEBUG
+
#include
#include
@@ -287,7 +289,7 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue) {
struct xhci_command *command;
command = xhci_alloc_command(xhci, false, false,
-GFP_NOIO);
+GFP_ATOMIC);
if (!command) {
spin_unlock_irqrestore(&xhci->lock, flags);
xhci_free_command(xhci, cmd);
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8056d90..2ceed51 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -20,6 +20,8 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#define DEBUG
+
#include
#include
#include
diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
index 1eefc98..4b289d6 100644
--- a/drivers/usb/host/xhci-mvebu.c
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -7,6 +7,8 @@
* version 2 as published by the Free Software Foundation.
*/
+#define DEBUG
+
#include
#include
#include
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index e20520f..aae5dc9 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -20,6 +20,8 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#define DEBUG
+
#include
#include
#include
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 29d8adb..2149b0c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -11,6 +11,8 @@
* version 2 as published by the Free Software Foundation.
*/
+#define DEBUG
+
#include
#include
#include
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d67ff71..a7eda28 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -64,6 +64,8 @@
* endpoint rings; it generates events on the event ring for these.
*/
+#define DEBUG
+
#include
#include
#include "xhci.h"
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2b8d9a2..fd350b7 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -20,6 +20,8 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#define DEBUG
+
#include
#include
#include
johannes
--
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: non-working UVC device 058f:5608
On Mon, 2014-06-09 at 11:59 +0200, Johannes Berg wrote: > > Johannes, could you enable USB debugging in the linus/master kernel and > > provide a kernel log ? > I'll try to get some logs (wasn't there tracing added to xhci too? will > check) Here we go - log + tracing: log: http://p.sipsolutions.net/d5926c43d531e3af.txt trace: http://johannes.sipsolutions.net/files/xhci.trace.dat.xz I plugged in the device, waited a bit, tried to run a camera application (didn't work) and then ran lsusb -t and lsusb -v. johannes -- 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: non-working UVC device 058f:5608
On Mon, 2014-06-09 at 11:25 +0200, Laurent Pinchart wrote: > > Indeed, that works! Interestingly, it works neither on a USB3 port > > directly, nor on a USB2 hub behind the USB3 port. > > I would thus be tempted to classify this as an XHCI controller issue. linux- > usb should be the right list to get help. I've CC'ed Mathias Nyman, the XHCI > maintainer. Yeah, I tend to agree. > Johannes, could you enable USB debugging in the linus/master kernel and > provide a kernel log ? Sure. Note that linus/next is having even more issues with this device, to the point where I couldn't even get the lsusb I pasted into the first email. I used 3.13 (because I had it installed on the system in question) to get that. It was also throwing an autosuspend warning: http://mid.gmane.org/1402177014.8442.1.ca...@jlt4.sipsolutions.net I'll try to get some logs (wasn't there tracing added to xhci too? will check) johannes -- 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: non-working UVC device 058f:5608
Hi Johannes, On Monday 09 June 2014 09:33:06 Johannes Berg wrote: > Hi Laurent, > > Thanks for the quick reply! You're welcome. > > > and then the kernel message repeats forever, while I can't even exit > > > uvccapture unless I kill it hard, at which point I get > > > > > > xhci_hcd :00:14.0: Signal while waiting for configure endpoint > > > command > > > usb 1-3.4.4.3: Not enough bandwidth for altsetting 0 > > > > > > from the kernel. > > > > This looks like low-level USB issues, CC'ing the linux-usb mailing list. > > Ok. > > > > Any thoughts? Just to rule out hardware defects I connected it to my > > > windows 7 work machine and it works fine without even installing a > > > driver. > > > > Could you try connecting it to an EHCI controller instead of XHCI on a > > Linux machine ? > > Indeed, that works! Interestingly, it works neither on a USB3 port > directly, nor on a USB2 hub behind the USB3 port. I would thus be tempted to classify this as an XHCI controller issue. linux- usb should be the right list to get help. I've CC'ed Mathias Nyman, the XHCI maintainer. Johannes, could you enable USB debugging in the linus/master kernel and provide a kernel log ? -- 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: V4L2 endpoint parser doesn't support empty ports
Hi Nikhil, On 09/06/14 10:22, Nikhil Devshatwar wrote: > Hi everyboady, > > When using V4l2 endpoint framework for parsing device tree nodes, > > I don't find any API which can allow me to iterate over all the > endpoints in a specific port > > Currectly we have v4l2_of_get_next_endpoint which can be used to > iterate over all the endpoints > under that device_node > > Typically, SoCs have multiple video ports in a video IP > We want a way to iterate over only the endpoints which belong to a certain > port > It isn't possible with this > > Also, Ideally, all the port definitions are in DTSI file whereas the > endpoints would be defined > in a DTS file overriding the port nodes > > So it is quite possible that we have some ports where nothing is connected, > v4l2_of_get_next_endpoint fails as soon as it gets the empty endpoint > > 2 questions > => Should we modify the v4l2_of_get_next_endpoint function to ignore > empty endpoints? Laurent addressed this issue with patch: https://patchwork.linuxtv.org/patch/22927 I'm not sure what kernel version you are using. Such changes are already in Linus' tree, however git history might not be straightforward due to merge conflict resolutions. See commit 3c83e61 "Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media" > => Does it make sense to create a new function which can iterate over > a specific port? The 'port' node can have only 'endpoint' subnodes, so once you get hold of the port node it should be as easy as iterating over its children ? -- Regards, Sylwester -- 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
We offer all purpose loan at 3% interest rate
We offer all purpose loan at 3% interest rate. Contact Us for more details by Email:santanderfinancegr...@gmail.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
V4L2 endpoint parser doesn't support empty ports
Hi everyboady, When using V4l2 endpoint framework for parsing device tree nodes, I don't find any API which can allow me to iterate over all the endpoints in a specific port Currectly we have v4l2_of_get_next_endpoint which can be used to iterate over all the endpoints under that device_node Typically, SoCs have multiple video ports in a video IP We want a way to iterate over only the endpoints which belong to a certain port It isn't possible with this Also, Ideally, all the port definitions are in DTSI file whereas the endpoints would be defined in a DTS file overriding the port nodes So it is quite possible that we have some ports where nothing is connected, v4l2_of_get_next_endpoint fails as soon as it gets the empty endpoint 2 questions => Should we modify the v4l2_of_get_next_endpoint function to ignore empty endpoints? => Does it make sense to create a new function which can iterate over a specific port? Thanks, Nikhil D -- 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: non-working UVC device 058f:5608
Hi Laurent, Thanks for the quick reply! > > and then the kernel message repeats forever, while I can't even exit > > uvccapture unless I kill it hard, at which point I get > > > > xhci_hcd :00:14.0: Signal while waiting for configure endpoint command > > usb 1-3.4.4.3: Not enough bandwidth for altsetting 0 > > > > from the kernel. > > This looks like low-level USB issues, CC'ing the linux-usb mailing list. Ok. > > Any thoughts? Just to rule out hardware defects I connected it to my > > windows 7 work machine and it works fine without even installing a > > driver. > > Could you try connecting it to an EHCI controller instead of XHCI on a Linux > machine ? Indeed, that works! Interestingly, it works neither on a USB3 port directly, nor on a USB2 hub behind the USB3 port. Thanks, johannes -- 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
