Kernel 3.17.0 broke xc4000-based DTV1800h
Since installing kernel 3.17.0-1.gc467423-desktop (on openSuSE 13.1) my xc4000/zl10353/cx88 based DTV card has failed to initialise on boot. The following messages are from dmesg; [ 78.468221] xc4000: I2C read failed [ 80.074604] xc4000: I2C read failed [ 80.074605] Unable to read tuner registers. [ 82.622062] Selecting best matching firmware (7 bits differ) for type=(0), id 0020b700: [ 82.626375] i2c i2c-0: sendbytes: NAK bailout. [ 148.063594] xc4000: I2C read failed [ 149.669994] xc4000: I2C read failed [ 149.669995] Unable to read tuner registers. [ 149.670198] cx88[0]/0: registered device video1 [v4l2] [ 149.670287] cx88[0]/0: registered device vbi0 [ 149.670338] cx88[0]/0: registered device radio0 [ 149.670340] cx88[0]/0: failed to create cx88 audio thread, err=-4 [ 149.670382] cx88[0]/2: cx2388x based DVB/ATSC card [ 149.670384] cx8802_alloc_frontends() allocating 1 frontend(s) [ 149.670515] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards [ 151.305364] zl10353_read_register: readreg error (reg=127, ret==-6) [ 151.305367] cx88[0]/2: frontend initialization failed [ 151.305369] cx88[0]/2: dvb_register failed (err = -22) [ 151.305370] cx88[0]/2: cx8802 probe failed, err = -22 It worked with 3.16.3-1.gd2bbe7f-desktop on the same machine. Regards, Rodney. -- == Rodney Baker VK5ZTV rodney.ba...@iinet.net.au == -- 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] usbvision-video: two use after frees
The lock has been freed in usbvision_release() so there is no need to
call mutex_unlock() here.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/usb/usbvision/usbvision-video.c
b/drivers/media/usb/usbvision/usbvision-video.c
index 68bc961..9bfa041 100644
--- a/drivers/media/usb/usbvision/usbvision-video.c
+++ b/drivers/media/usb/usbvision/usbvision-video.c
@@ -446,6 +446,7 @@ static int usbvision_v4l2_close(struct file *file)
if (usbvision->remove_pending) {
printk(KERN_INFO "%s: Final disconnect\n", __func__);
usbvision_release(usbvision);
+ return 0;
}
mutex_unlock(&usbvision->v4l2_lock);
@@ -1221,6 +1222,7 @@ static int usbvision_radio_close(struct file *file)
if (usbvision->remove_pending) {
printk(KERN_INFO "%s: Final disconnect\n", __func__);
usbvision_release(usbvision);
+ return err_code;
}
mutex_unlock(&usbvision->v4l2_lock);
--
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] usbvision-video: two use after frees
On Thursday 16 October 2014 10:57:21 Dan Carpenter wrote:
> The lock has been freed in usbvision_release() so there is no need to
> call mutex_unlock() here.
Yuck :-/
The driver should really be converted to use video_device::release. That might
be out of scope for this fix though. Is usbvision maintained ?
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/media/usb/usbvision/usbvision-video.c
> b/drivers/media/usb/usbvision/usbvision-video.c index 68bc961..9bfa041
> 100644
> --- a/drivers/media/usb/usbvision/usbvision-video.c
> +++ b/drivers/media/usb/usbvision/usbvision-video.c
> @@ -446,6 +446,7 @@ static int usbvision_v4l2_close(struct file *file)
> if (usbvision->remove_pending) {
> printk(KERN_INFO "%s: Final disconnect\n", __func__);
> usbvision_release(usbvision);
> + return 0;
> }
> mutex_unlock(&usbvision->v4l2_lock);
>
> @@ -1221,6 +1222,7 @@ static int usbvision_radio_close(struct file *file)
> if (usbvision->remove_pending) {
> printk(KERN_INFO "%s: Final disconnect\n", __func__);
> usbvision_release(usbvision);
> + return err_code;
> }
>
> mutex_unlock(&usbvision->v4l2_lock);
--
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: [patch] [media] usbvision-video: two use after frees
On 10/16/2014 10:09 AM, Laurent Pinchart wrote:
> On Thursday 16 October 2014 10:57:21 Dan Carpenter wrote:
>> The lock has been freed in usbvision_release() so there is no need to
>> call mutex_unlock() here.
>
> Yuck :-/
>
> The driver should really be converted to use video_device::release. That
> might
> be out of scope for this fix though. Is usbvision maintained ?
I have hardware, and at some point I plan to convert it to modern frameworks.
But ENOTIME for now. So I guess I might be the closest to a being a maintainer.
Regards,
Hans
>
>> Signed-off-by: Dan Carpenter
>>
>> diff --git a/drivers/media/usb/usbvision/usbvision-video.c
>> b/drivers/media/usb/usbvision/usbvision-video.c index 68bc961..9bfa041
>> 100644
>> --- a/drivers/media/usb/usbvision/usbvision-video.c
>> +++ b/drivers/media/usb/usbvision/usbvision-video.c
>> @@ -446,6 +446,7 @@ static int usbvision_v4l2_close(struct file *file)
>> if (usbvision->remove_pending) {
>> printk(KERN_INFO "%s: Final disconnect\n", __func__);
>> usbvision_release(usbvision);
>> +return 0;
>> }
>> mutex_unlock(&usbvision->v4l2_lock);
>>
>> @@ -1221,6 +1222,7 @@ static int usbvision_radio_close(struct file *file)
>> if (usbvision->remove_pending) {
>> printk(KERN_INFO "%s: Final disconnect\n", __func__);
>> usbvision_release(usbvision);
>> +return err_code;
>> }
>>
>> mutex_unlock(&usbvision->v4l2_lock);
>
--
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] usbvision-video: two use after frees
On Thursday 16 October 2014 10:23:05 Hans Verkuil wrote:
> On 10/16/2014 10:09 AM, Laurent Pinchart wrote:
> > On Thursday 16 October 2014 10:57:21 Dan Carpenter wrote:
> >> The lock has been freed in usbvision_release() so there is no need to
> >> call mutex_unlock() here.
> >
> > Yuck :-/
> >
> > The driver should really be converted to use video_device::release. That
> > might be out of scope for this fix though. Is usbvision maintained ?
>
> I have hardware, and at some point I plan to convert it to modern
> frameworks. But ENOTIME for now. So I guess I might be the closest to a
> being a maintainer.
Can you ack the patch then ? :-)
> >> Signed-off-by: Dan Carpenter
> >>
> >> diff --git a/drivers/media/usb/usbvision/usbvision-video.c
> >> b/drivers/media/usb/usbvision/usbvision-video.c index 68bc961..9bfa041
> >> 100644
> >> --- a/drivers/media/usb/usbvision/usbvision-video.c
> >> +++ b/drivers/media/usb/usbvision/usbvision-video.c
> >> @@ -446,6 +446,7 @@ static int usbvision_v4l2_close(struct file *file)
> >>if (usbvision->remove_pending) {
> >>printk(KERN_INFO "%s: Final disconnect\n", __func__);
> >>usbvision_release(usbvision);
> >> + return 0;
> >>}
> >>mutex_unlock(&usbvision->v4l2_lock);
> >>
> >> @@ -1221,6 +1222,7 @@ static int usbvision_radio_close(struct file *file)
> >>if (usbvision->remove_pending) {
> >>printk(KERN_INFO "%s: Final disconnect\n", __func__);
> >>usbvision_release(usbvision);
> >> + return err_code;
> >>}
> >>
> >>mutex_unlock(&usbvision->v4l2_lock);
--
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: [PATCH 1/2] [media] uvcvideo: add a new quirk UVC_QUIRK_SINGLE_ISO
Hi Laurent,
On 11/10/2014 14:03, Laurent Pinchart wrote:
> Hi John,
>
> On Friday 10 October 2014 20:41:12 John Crispin wrote:
>> The following patch adds the usb ids for the iPassion chip. This chip is
>> found on D-Link DIR-930 IP cameras. For them to work this patch needs to be
>> applied. I am almost certain that this is the incorrect fix. Could someone
>> shed a bit of light on how i should really implement the fix ?
> First of all, could you explain how the camera misbehaves without this patch
> set ?
good question, i created this patch 2 years ago. normally people will
install mjpeg-streamer on these units and that just gave black frames if
i remember correctly. digging through the GPL drop i found this patch.
i will need a couple of days to get my test unit back. once i have it
here i will do some tests and the let you know the exact symptoms.
John
>> Signed-off-by: John Crispin
>> ---
>> drivers/media/usb/uvc/uvc_video.c |2 ++
>> drivers/media/usb/uvc/uvcvideo.h |1 +
>> 2 files changed, 3 insertions(+)
>>
>> diff --git a/drivers/media/usb/uvc/uvc_video.c
>> b/drivers/media/usb/uvc/uvc_video.c index 9144a2f..61381fd 100644
>> --- a/drivers/media/usb/uvc/uvc_video.c
>> +++ b/drivers/media/usb/uvc/uvc_video.c
>> @@ -1495,6 +1495,8 @@ static int uvc_init_video_isoc(struct uvc_streaming
>> *stream, if (npackets == 0)
>> return -ENOMEM;
>>
>> +if (stream->dev->quirks & UVC_QUIRK_SINGLE_ISO)
>> +npackets = 1;
>> size = npackets * psize;
>>
>> for (i = 0; i < UVC_URBS; ++i) {
>> diff --git a/drivers/media/usb/uvc/uvcvideo.h
>> b/drivers/media/usb/uvc/uvcvideo.h index b1f69a6..b6df4f8 100644
>> --- a/drivers/media/usb/uvc/uvcvideo.h
>> +++ b/drivers/media/usb/uvc/uvcvideo.h
>> @@ -147,6 +147,7 @@
>> #define UVC_QUIRK_FIX_BANDWIDTH 0x0080
>> #define UVC_QUIRK_PROBE_DEF 0x0100
>> #define UVC_QUIRK_RESTRICT_FRAME_RATE 0x0200
>> +#define UVC_QUIRK_SINGLE_ISO0x0400
>>
>> /* Format flags */
>> #define UVC_FMT_FLAG_COMPRESSED 0x0001
--
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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
On 10/14/2014 04:58 PM, Shuah Khan wrote:
[...]
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
+ err = media_get_audio_tkn(&subs->dev->dev);
+ if (err == -EBUSY) {
+ dev_info(&subs->dev->dev, "%s device is busy\n",
+ __func__);
In my opinion this should not dev_info() as this is out of band error
signaling and also as the potential to spam the log. The userspace
application is already properly notified by the return code.
+ return err;
+ }
err = start_endpoints(subs, false);
if (err < 0)
return err;
--
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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
> On 10/14/2014 04:58 PM, Shuah Khan wrote:
> [...]
>> switch (cmd) {
>> case SNDRV_PCM_TRIGGER_START:
>> +err = media_get_audio_tkn(&subs->dev->dev);
>> +if (err == -EBUSY) {
>> +dev_info(&subs->dev->dev, "%s device is busy\n",
>> +__func__);
>
> In my opinion this should not dev_info() as this is out of band error
> signaling and also as the potential to spam the log. The userspace
> application is already properly notified by the return code.
>
Yes it has the potential to flood the dmesg especially with alsa,
I will remove the dev_info().
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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: V4L/DVB (7535): saa717x: add new audio/video decoder i2c driver
Hello Hans Verkuil,
The patch fb7b37cf913c: "V4L/DVB (7535): saa717x: add new audio/video
decoder i2c driver" from Apr 9, 2008, leads to the following static
checker warning:
drivers/media/i2c/saa717x.c:155 saa717x_read()
warn: right shifting more than type allows
drivers/media/i2c/saa717x.c
133 static u32 saa717x_read(struct v4l2_subdev *sd, u32 reg)
134 {
135 struct i2c_client *client = v4l2_get_subdevdata(sd);
136 struct i2c_adapter *adap = client->adapter;
137 int fw_addr = (reg >= 0x404 && reg <= 0x4b8) || reg == 0x528;
138 unsigned char mm1[2];
139 unsigned char mm2[4] = { 0, 0, 0, 0 };
^^
140 struct i2c_msg msgs[2];
141 u32 value;
142
143 msgs[0].flags = 0;
144 msgs[1].flags = I2C_M_RD;
145 msgs[0].addr = msgs[1].addr = client->addr;
146 mm1[0] = (reg >> 8) & 0xff;
147 mm1[1] = reg & 0xff;
148 msgs[0].len = 2;
149 msgs[0].buf = mm1;
150 msgs[1].len = fw_addr ? 3 : 1; /* Multibyte Registers contains
*only* 3 bytes */
151 msgs[1].buf = mm2;
152 i2c_transfer(adap, msgs, 2);
153
154 if (fw_addr)
155 value = (mm2[2] & 0xff) | ((mm2[1] & 0xff) >> 8) |
((mm2[0] & 0xff) >> 16);
The mask and shift doesn't make sense for chars (also it's reversed).
156 else
157 value = mm2[0] & 0xff;
My guess is the intention was:
if (fw_addr)
value = mm2[2] | mm2[1] | mm2[0];
else
value = mm2[0];
158
159 v4l2_dbg(2, debug, sd, "read: reg 0x%03x=0x%08x\n", reg,
value);
160 return value;
161 }
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
Re: [PATCH v2 1/6] media: add media token device resource framework
At Wed, 15 Oct 2014 18:53:28 -0600,
Shuah Khan wrote:
>
> On 10/15/2014 11:05 AM, Takashi Iwai wrote:
>
> >> +#if defined(CONFIG_MEDIA_SUPPORT)
> >> +extern int media_tknres_create(struct device *dev);
> >> +extern int media_tknres_destroy(struct device *dev);
> >> +
> >> +extern int media_get_tuner_tkn(struct device *dev);
> >> +extern int media_put_tuner_tkn(struct device *dev);
> >> +
> >> +extern int media_get_audio_tkn(struct device *dev);
> >> +extern int media_put_audio_tkn(struct device *dev);
> >
> > The words "tknres" and "tkn" (especially latter) look ugly and not
> > clear to me. IMO, it should be "token".
>
> No problem. I can change that to media_token_create/destroy()
> and expand token in other functions.
>
> >> +struct media_tkn {
> >> + spinlock_t lock;
> >> + unsigned int owner; /* owner task pid */
> >> + unsigned int tgid; /* owner task gid */
> >> + struct task_struct *task;
> >> +};
> >> +
> >> +struct media_tknres {
> >> + struct media_tkn tuner;
> >> + struct media_tkn audio;
> >> +};
> >
> > Why do you need to have both tuner and audio tokens? If I understand
> > correctly, no matter whether it's tuner or audio, if it's being used,
> > the open must fail, right?
>
> As it evolved during development, it turns out at the moment I don't
> have any use-cases that require holding audio and tuner separately.
> It probably could be collapsed into just a media token. I have to
> think about this some.
>
> >> +
> >> +static int __media_get_tkn(struct media_tkn *tkn, char *tkn_str)
> >> +{
> >> + int rc = 0;
> >> + unsigned tpid;
> >> + unsigned tgid;
> >> +
> >> + spin_lock(&tkn->lock);
> >
> > You should use spin_lock_irqsave() here and in all other places.
> > The trigger callback in usb-audio, for example, may be called in irq
> > context.
>
> ok. Good point, will change that.
>
> >
> >> +
> >> + tpid = task_pid_nr(current);
> >> + tgid = task_tgid_nr(current);
> >> +
> >> + /* allow task in the same group id to release */
> >
> > IMO, it's not "release" but "steal"... But what happens if the stolen
> > owner calls put? Then it'll be released although the stealing owner
> > still thinks it's being held.
>
> Yeah it could be called a steal. :) Essentially tgid happens to be
> the real owner. I am overwriting the pid with current pid when
> tgid is same.
>
> media dvb and v4l apps start two or more threads that all share the
> tgid and subsequent token gets should be allowed based on the tgid.
>
> Scenario 1:
>
> Please note that there are 3 device files in question and media
> token resource is the lock for all. Hence the changes to v4l-core,
> dvb-core, and snd-usb-audio to hold the token for exclusive access
> when the task or tgid don't match.
>
> program starts:
> - first thread opens device file in R/W mode - open gets the token
> or thread makes ioctls calls that clearly indicates intent to
> change tuner settings
> - creates one thread for audio
> - creates another for video or continues video function
> - video thread does a close and re-opens the device file
>
> In this case when thread tries to close, token put fails unless
> tasks with same tgid are allowed to release.
> ( I ran into this one of the media applications and it is a valid
> case to handle, thread can close the file and should be able to
> open again without running into token busy case )
>
> - or continue to just use the device file
> - audio thread does snd_pcm_capture ops - trigger start
>
> program exits:
> - video thread closes the device file
> - audio thread does snd_pcm_capture ops - trigger stop
>
> This got me thinking about the scenario when an application
> does a fork() as opposed to create a thread. I have to think
> about this and see how I can address that.
>
> >
> >> + if (tkn->task && ((tkn->task != current) && (tkn->tgid != tgid))) {
> >
> > Shouldn't the second "&&" be "||" instead?
> > And too many parentheses there.
>
> Right - this is my bad. The comment right above this conditional
> is a give away that, at some point I did a copy and paste from
> _put to _get and only changed the first task null check.
> I am yelling at myself at the moment.
>
> >
> >> + rc = -EBUSY;
> >
> > Wrong indentation.
>
> Yes. Will fix that.
>
> >
> > I have a feeling that the whole thing can be a bit more simplified in
> > the end...
> >
>
> Any ideas to simplify are welcome.
There are a few points to make things more consistent and simplified,
IMO. First of all, the whole concept can be more generalized. It's
not necessarily only for media and audio. Rather we can make it a
generic dev_token. Then it'll become more convincing to land into
lib/*.
The media-specific handling is only about the pid and gid checks.
This can be implemented as a callback that is passed at creating a
token, for example. This will reduce the core code in lib/*.
Also, get and put should handle a proper refcount. The point I
mentioned i
Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
At Thu, 16 Oct 2014 07:10:37 -0600,
Shuah Khan wrote:
>
> On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
> > On 10/14/2014 04:58 PM, Shuah Khan wrote:
> > [...]
> >> switch (cmd) {
> >> case SNDRV_PCM_TRIGGER_START:
> >> +err = media_get_audio_tkn(&subs->dev->dev);
> >> +if (err == -EBUSY) {
> >> +dev_info(&subs->dev->dev, "%s device is busy\n",
> >> +__func__);
> >
> > In my opinion this should not dev_info() as this is out of band error
> > signaling and also as the potential to spam the log. The userspace
> > application is already properly notified by the return code.
> >
>
> Yes it has the potential to flood the dmesg especially with alsa,
> I will remove the dev_info().
Yes. And, I think doing this in the trigger isn't the best.
Why not in open & close?
Also, is this token restriction needed only for PCM? No mixer or
other controls?
Takashi
--
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 v2 0/6] media token resource framework
At Wed, 15 Oct 2014 14:21:34 -0600, Shuah Khan wrote: > > On 10/15/2014 10:48 AM, Takashi Iwai wrote: > > At Tue, 14 Oct 2014 08:58:36 -0600, > > Shuah Khan wrote: > >> > >> Add media token device resource framework to allow sharing > >> resources such as tuner, dma, audio etc. across media drivers > >> and non-media sound drivers that control media hardware. The > >> Media token resource is created at the main struct device that > >> is common to all drivers that claim various pieces of the main > >> media device, which allows them to find the resource using the > >> main struct device. As an example, digital, analog, and > >> snd-usb-audio drivers can use the media token resource API > >> using the main struct device for the interface the media device > >> is attached to. > >> > >> This patch series consists of media token resource framework > >> and changes to use it in dvb-core, v4l2-core, au0828 driver, > >> and snd-usb-audio driver. > >> > >> With these changes dvb and v4l2 can share the tuner without > >> disrupting each other. Used tvtime, xawtv, kaffeine, and vlc, > >> vlc audio capture option, arecord/aplay during development to > >> identify v4l2 vb2 and vb1 ioctls and file operations that > >> disrupt the digital stream and would require changes to check > >> tuner ownership prior to changing the tuner configuration. > >> vb2 changes are made in the v4l2-core and vb1 changes are made > >> in the au0828 driver to encourage porting drivers to vb2 to > >> advantage of the new media token resource framework with changes > >> in the core. > >> > >> In this patch v2 series, fixed problems identified in the > >> patch v1 series. Important ones are changing snd-usb-audio > >> to use media tokens, holding tuner lock in VIDIOC_ENUMINPUT, > >> and VIDIOC_QUERYSTD. > > > > Just took a quick glance over the patches, and my first concern is why > > this has to be lib/*. This means it's always built-in as long as this > > config is enabled (and will be so on distro kernel) even if it's not > > used at all. > > > > Right this module gets built when CONFIG_MEDIA_SUPPORT is enabled > and stubs are in place when it is not enabled. The intent is for > this feature to be enabled by default when media support is enabled. > When a driver doesn't create the resource, it will simply not find it > and for drivers like snd-usb-audio that aren't tried to media support, > the stubs are in place and feature is essentially disabled. > > I picked lib so this module can be included in non-media drivers > e.g: snd-usb-audio. > > Does this help explain the design? I didn't want to introduce a new > config for this feature. If lib isn't right place, could you recommend > another one that makes this modules available to non-media drivers? > moving isn't a problem. We can create a small module depending on CONFIG_MEDIA. But it'll be rather a question of the size. If it's reasonably small and generic enough, it's worth to put into lib/*, I think. Takashi -- 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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
On 10/16/2014 08:01 AM, Takashi Iwai wrote:
> At Thu, 16 Oct 2014 07:10:37 -0600,
> Shuah Khan wrote:
>>
>> On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
>>> On 10/14/2014 04:58 PM, Shuah Khan wrote:
>>> [...]
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
+err = media_get_audio_tkn(&subs->dev->dev);
+if (err == -EBUSY) {
+dev_info(&subs->dev->dev, "%s device is busy\n",
+__func__);
>>>
>>> In my opinion this should not dev_info() as this is out of band error
>>> signaling and also as the potential to spam the log. The userspace
>>> application is already properly notified by the return code.
>>>
>>
>> Yes it has the potential to flood the dmesg especially with alsa,
>> I will remove the dev_info().
>
> Yes. And, I think doing this in the trigger isn't the best.
> Why not in open & close?
My first cut of this change was in open and close. I saw pulseaudio
application go into this loop trying to open the device. To avoid
such problems, I went with trigger stat and stop. That made all the
pulseaudio continues attempts to open problems go away.
>
> Also, is this token restriction needed only for PCM? No mixer or
> other controls?
snd_pcm_ops are the only ones media drivers implement and use. So
I don't think mixer is needed. If it is needed, it is not to hard
to add for that case.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
At Thu, 16 Oct 2014 08:10:52 -0600,
Shuah Khan wrote:
>
> On 10/16/2014 08:01 AM, Takashi Iwai wrote:
> > At Thu, 16 Oct 2014 07:10:37 -0600,
> > Shuah Khan wrote:
> >>
> >> On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
> >>> On 10/14/2014 04:58 PM, Shuah Khan wrote:
> >>> [...]
> switch (cmd) {
> case SNDRV_PCM_TRIGGER_START:
> +err = media_get_audio_tkn(&subs->dev->dev);
> +if (err == -EBUSY) {
> +dev_info(&subs->dev->dev, "%s device is busy\n",
> +__func__);
> >>>
> >>> In my opinion this should not dev_info() as this is out of band error
> >>> signaling and also as the potential to spam the log. The userspace
> >>> application is already properly notified by the return code.
> >>>
> >>
> >> Yes it has the potential to flood the dmesg especially with alsa,
> >> I will remove the dev_info().
> >
> > Yes. And, I think doing this in the trigger isn't the best.
> > Why not in open & close?
>
> My first cut of this change was in open and close. I saw pulseaudio
> application go into this loop trying to open the device. To avoid
> such problems, I went with trigger stat and stop. That made all the
> pulseaudio continues attempts to open problems go away.
But now starting the stream gives the error, and PA would loop it
again, no?
> > Also, is this token restriction needed only for PCM? No mixer or
> > other controls?
>
> snd_pcm_ops are the only ones media drivers implement and use. So
> I don't think mixer is needed. If it is needed, it is not to hard
> to add for that case.
Well, then I wonder what resource does actually conflict with
usb-audio and media drivers at all...?
Takashi
--
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 v2 1/6] media: add media token device resource framework
On 10/16/2014 08:00 AM, Takashi Iwai wrote:
> At Wed, 15 Oct 2014 18:53:28 -0600,
> Shuah Khan wrote:
>>
>> On 10/15/2014 11:05 AM, Takashi Iwai wrote:
>>
+#if defined(CONFIG_MEDIA_SUPPORT)
+extern int media_tknres_create(struct device *dev);
+extern int media_tknres_destroy(struct device *dev);
+
+extern int media_get_tuner_tkn(struct device *dev);
+extern int media_put_tuner_tkn(struct device *dev);
+
+extern int media_get_audio_tkn(struct device *dev);
+extern int media_put_audio_tkn(struct device *dev);
>>>
>>> The words "tknres" and "tkn" (especially latter) look ugly and not
>>> clear to me. IMO, it should be "token".
>>
>> No problem. I can change that to media_token_create/destroy()
>> and expand token in other functions.
>>
+struct media_tkn {
+ spinlock_t lock;
+ unsigned int owner; /* owner task pid */
+ unsigned int tgid; /* owner task gid */
+ struct task_struct *task;
+};
+
+struct media_tknres {
+ struct media_tkn tuner;
+ struct media_tkn audio;
+};
>>>
>>> Why do you need to have both tuner and audio tokens? If I understand
>>> correctly, no matter whether it's tuner or audio, if it's being used,
>>> the open must fail, right?
>>
>> As it evolved during development, it turns out at the moment I don't
>> have any use-cases that require holding audio and tuner separately.
>> It probably could be collapsed into just a media token. I have to
>> think about this some.
>>
+
+static int __media_get_tkn(struct media_tkn *tkn, char *tkn_str)
+{
+ int rc = 0;
+ unsigned tpid;
+ unsigned tgid;
+
+ spin_lock(&tkn->lock);
>>>
>>> You should use spin_lock_irqsave() here and in all other places.
>>> The trigger callback in usb-audio, for example, may be called in irq
>>> context.
>>
>> ok. Good point, will change that.
>>
>>>
+
+ tpid = task_pid_nr(current);
+ tgid = task_tgid_nr(current);
+
+ /* allow task in the same group id to release */
>>>
>>> IMO, it's not "release" but "steal"... But what happens if the stolen
>>> owner calls put? Then it'll be released although the stealing owner
>>> still thinks it's being held.
>>
>> Yeah it could be called a steal. :) Essentially tgid happens to be
>> the real owner. I am overwriting the pid with current pid when
>> tgid is same.
>>
>> media dvb and v4l apps start two or more threads that all share the
>> tgid and subsequent token gets should be allowed based on the tgid.
>>
>> Scenario 1:
>>
>> Please note that there are 3 device files in question and media
>> token resource is the lock for all. Hence the changes to v4l-core,
>> dvb-core, and snd-usb-audio to hold the token for exclusive access
>> when the task or tgid don't match.
>>
>> program starts:
>> - first thread opens device file in R/W mode - open gets the token
>> or thread makes ioctls calls that clearly indicates intent to
>> change tuner settings
>> - creates one thread for audio
>> - creates another for video or continues video function
>> - video thread does a close and re-opens the device file
>>
>> In this case when thread tries to close, token put fails unless
>> tasks with same tgid are allowed to release.
>> ( I ran into this one of the media applications and it is a valid
>> case to handle, thread can close the file and should be able to
>> open again without running into token busy case )
>>
>> - or continue to just use the device file
>> - audio thread does snd_pcm_capture ops - trigger start
>>
>> program exits:
>> - video thread closes the device file
>> - audio thread does snd_pcm_capture ops - trigger stop
>>
>> This got me thinking about the scenario when an application
>> does a fork() as opposed to create a thread. I have to think
>> about this and see how I can address that.
>>
>>>
+ if (tkn->task && ((tkn->task != current) && (tkn->tgid != tgid))) {
>>>
>>> Shouldn't the second "&&" be "||" instead?
>>> And too many parentheses there.
>>
>> Right - this is my bad. The comment right above this conditional
>> is a give away that, at some point I did a copy and paste from
>> _put to _get and only changed the first task null check.
>> I am yelling at myself at the moment.
>>
>>>
+ rc = -EBUSY;
>>>
>>> Wrong indentation.
>>
>> Yes. Will fix that.
>>
>>>
>>> I have a feeling that the whole thing can be a bit more simplified in
>>> the end...
>>>
>>
>> Any ideas to simplify are welcome.
>
> There are a few points to make things more consistent and simplified,
> IMO. First of all, the whole concept can be more generalized. It's
> not necessarily only for media and audio. Rather we can make it a
> generic dev_token. Then it'll become more convincing to land into
> lib/*.
Right. At the moment this is very media specific.
>
> The media-specific handling is only about the pid and gid checks.
> This can be implemented as a callback that is passed a
Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
On 10/16/2014 08:16 AM, Takashi Iwai wrote:
> At Thu, 16 Oct 2014 08:10:52 -0600,
> Shuah Khan wrote:
>>
>> On 10/16/2014 08:01 AM, Takashi Iwai wrote:
>>> At Thu, 16 Oct 2014 07:10:37 -0600,
>>> Shuah Khan wrote:
On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
> On 10/14/2014 04:58 PM, Shuah Khan wrote:
> [...]
>> switch (cmd) {
>> case SNDRV_PCM_TRIGGER_START:
>> +err = media_get_audio_tkn(&subs->dev->dev);
>> +if (err == -EBUSY) {
>> +dev_info(&subs->dev->dev, "%s device is busy\n",
>> +__func__);
>
> In my opinion this should not dev_info() as this is out of band error
> signaling and also as the potential to spam the log. The userspace
> application is already properly notified by the return code.
>
Yes it has the potential to flood the dmesg especially with alsa,
I will remove the dev_info().
>>>
>>> Yes. And, I think doing this in the trigger isn't the best.
>>> Why not in open & close?
>>
>> My first cut of this change was in open and close. I saw pulseaudio
>> application go into this loop trying to open the device. To avoid
>> such problems, I went with trigger stat and stop. That made all the
>> pulseaudio continues attempts to open problems go away.
>
> But now starting the stream gives the error, and PA would loop it
> again, no?
>
>
>>> Also, is this token restriction needed only for PCM? No mixer or
>>> other controls?
>>
>> snd_pcm_ops are the only ones media drivers implement and use. So
>> I don't think mixer is needed. If it is needed, it is not to hard
>> to add for that case.
>
> Well, then I wonder what resource does actually conflict with
> usb-audio and media drivers at all...?
>
audio for dvb/v4l apps gets disrupted when audio app starts. For
example, dvb or v4l app tuned to a channel, and when an audio app
starts. audio path needs protected to avoid conflicts between
digital and analog applications as well.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
At Thu, 16 Oct 2014 08:39:14 -0600,
Shuah Khan wrote:
>
> On 10/16/2014 08:16 AM, Takashi Iwai wrote:
> > At Thu, 16 Oct 2014 08:10:52 -0600,
> > Shuah Khan wrote:
> >>
> >> On 10/16/2014 08:01 AM, Takashi Iwai wrote:
> >>> At Thu, 16 Oct 2014 07:10:37 -0600,
> >>> Shuah Khan wrote:
>
> On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
> > On 10/14/2014 04:58 PM, Shuah Khan wrote:
> > [...]
> >> switch (cmd) {
> >> case SNDRV_PCM_TRIGGER_START:
> >> +err = media_get_audio_tkn(&subs->dev->dev);
> >> +if (err == -EBUSY) {
> >> +dev_info(&subs->dev->dev, "%s device is busy\n",
> >> +__func__);
> >
> > In my opinion this should not dev_info() as this is out of band error
> > signaling and also as the potential to spam the log. The userspace
> > application is already properly notified by the return code.
> >
>
> Yes it has the potential to flood the dmesg especially with alsa,
> I will remove the dev_info().
> >>>
> >>> Yes. And, I think doing this in the trigger isn't the best.
> >>> Why not in open & close?
> >>
> >> My first cut of this change was in open and close. I saw pulseaudio
> >> application go into this loop trying to open the device. To avoid
> >> such problems, I went with trigger stat and stop. That made all the
> >> pulseaudio continues attempts to open problems go away.
> >
> > But now starting the stream gives the error, and PA would loop it
> > again, no?
> >
> >
> >>> Also, is this token restriction needed only for PCM? No mixer or
> >>> other controls?
> >>
> >> snd_pcm_ops are the only ones media drivers implement and use. So
> >> I don't think mixer is needed. If it is needed, it is not to hard
> >> to add for that case.
> >
> > Well, then I wonder what resource does actually conflict with
> > usb-audio and media drivers at all...?
> >
>
> audio for dvb/v4l apps gets disrupted when audio app starts. For
> example, dvb or v4l app tuned to a channel, and when an audio app
> starts. audio path needs protected to avoid conflicts between
> digital and analog applications as well.
OK, then concentrating on only PCM is fine.
But, I'm still not convinced about doing the token management in the
trigger. The reason -EBUSY doesn't work is that it's the very same
error code when a PCM device is blocked by other processes. And
-EAGAIN is interpreted by PCM core to -EBUSY for historical reasons.
How applications (e.g. PA) should behave if the token get fails?
Shouldn't it retry or totally give up?
Takashi
--
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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
On 10/16/2014 08:48 AM, Takashi Iwai wrote:
> At Thu, 16 Oct 2014 08:39:14 -0600,
> Shuah Khan wrote:
>>
>> On 10/16/2014 08:16 AM, Takashi Iwai wrote:
>>> At Thu, 16 Oct 2014 08:10:52 -0600,
>>> Shuah Khan wrote:
On 10/16/2014 08:01 AM, Takashi Iwai wrote:
> At Thu, 16 Oct 2014 07:10:37 -0600,
> Shuah Khan wrote:
>>
>> On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
>>> On 10/14/2014 04:58 PM, Shuah Khan wrote:
>>> [...]
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
+err = media_get_audio_tkn(&subs->dev->dev);
+if (err == -EBUSY) {
+dev_info(&subs->dev->dev, "%s device is busy\n",
+__func__);
>>>
>>> In my opinion this should not dev_info() as this is out of band error
>>> signaling and also as the potential to spam the log. The userspace
>>> application is already properly notified by the return code.
>>>
>>
>> Yes it has the potential to flood the dmesg especially with alsa,
>> I will remove the dev_info().
>
> Yes. And, I think doing this in the trigger isn't the best.
> Why not in open & close?
My first cut of this change was in open and close. I saw pulseaudio
application go into this loop trying to open the device. To avoid
such problems, I went with trigger stat and stop. That made all the
pulseaudio continues attempts to open problems go away.
>>>
>>> But now starting the stream gives the error, and PA would loop it
>>> again, no?
>>>
>>>
> Also, is this token restriction needed only for PCM? No mixer or
> other controls?
snd_pcm_ops are the only ones media drivers implement and use. So
I don't think mixer is needed. If it is needed, it is not to hard
to add for that case.
>>>
>>> Well, then I wonder what resource does actually conflict with
>>> usb-audio and media drivers at all...?
>>>
>>
>> audio for dvb/v4l apps gets disrupted when audio app starts. For
>> example, dvb or v4l app tuned to a channel, and when an audio app
>> starts. audio path needs protected to avoid conflicts between
>> digital and analog applications as well.
>
> OK, then concentrating on only PCM is fine.
>
> But, I'm still not convinced about doing the token management in the
> trigger. The reason -EBUSY doesn't work is that it's the very same
> error code when a PCM device is blocked by other processes. And
> -EAGAIN is interpreted by PCM core to -EBUSY for historical reasons.
ah. ok your recommendation is to go with open and close.
Mauro has some reservations with holding at open when I discussed
my observations with pulseaudio when I was holding token in open
instead of trigger start. Maybe he can chime with his concerns.
I think his concern was breaking applications if token is held in
open().
Based on what you are seeing trigger could be worse.
>
> How applications (e.g. PA) should behave if the token get fails?
> Shouldn't it retry or totally give up?
>
It would be up to the application I would think. I see that arecord
quits right away when it finds the device busy. pluseaudio on the other
hand appears to retry. I downloaded pulseaudio sources to understand
what it is doing, however I didn't get too far. The way it does audio
handling is complex for me to follow without spending a lot of time.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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 03/12] [media] V4L2: mx3_camer: use dmaengine_pause() API
On Sat, 11 Oct 2014, Vinod Koul wrote:
> The drivers should use dmaengine_pause() API instead of
> accessing the device_control which will be deprecated soon
>
> Signed-off-by: Vinod Koul
Acked-by: Guennadi Liakhovetski
Thanks
Guennadi
> ---
> drivers/media/platform/soc_camera/mx3_camera.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/mx3_camera.c
> b/drivers/media/platform/soc_camera/mx3_camera.c
> index 83315df..7696a87 100644
> --- a/drivers/media/platform/soc_camera/mx3_camera.c
> +++ b/drivers/media/platform/soc_camera/mx3_camera.c
> @@ -415,10 +415,8 @@ static void mx3_stop_streaming(struct vb2_queue *q)
> struct mx3_camera_buffer *buf, *tmp;
> unsigned long flags;
>
> - if (ichan) {
> - struct dma_chan *chan = &ichan->dma_chan;
> - chan->device->device_control(chan, DMA_PAUSE, 0);
> - }
> + if (ichan)
> + dmaengine_pause(&ichan->dma_chan);
>
> spin_lock_irqsave(&mx3_cam->lock, flags);
>
> --
> 1.7.0.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
Re: [PATCH 0/2] media: soc_camera: rcar_vin: Add r8a7794, r8a7793 device support
Hello,
Thanks for the patches. Could you please fold these two into one - they
really don't deserve to be separated. As for your other series - patches
there look mostly good - from just a formal review. If you don't mind,
I'll adjust a couple of cosmetic issues like missing curly braces in
if (a)
x();
else {
y();
z();
}
or multiline comments or similar minor things.
Thanks
Guennadi
On Tue, 14 Oct 2014, Yoshihiro Kaneko wrote:
> This series is against master branch of linuxtv.org/media_tree.git.
>
> Koji Matsuoka (2):
> media: soc_camera: rcar_vin: Add r8a7794 device support
> media: soc_camera: rcar_vin: Add r8a7793 device support
>
> drivers/media/platform/soc_camera/rcar_vin.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> --
> 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 resend] [media] rc-core: fix protocol_change regression in ir_raw_event_register
On Thu, Oct 09, 2014 at 09:30:36PM +0300, Tomas Melin wrote:
>IR reciever using nuvoton-cir and lirc was not working anymore after
>upgrade from kernel 3.16 to 3.17-rcX.
>Bisected regression to commit da6e162d6a4607362f8478c715c797d84d449f8b
>("[media] rc-core: simplify sysfs code").
>
>The regression comes from adding function change_protocol in
>ir-raw.c. During registration, ir_raw_event_register enables all protocols
>by default. Later, rc_register_device also tests dev->change_protocol and
>changes the enabled protocols based on rc_map type. However, rc_map type
>only defines a single specific protocol, so in the case of a more generic
>driver, this disables all protocols but the one defined by the map.
>
>Changed back to original behaviour by removing empty function
>change_protocol in ir-raw.c. Instead only calling change_protocol for
>drivers that actually have the function set up.
I think this is already addressed in this thread:
http://www.spinics.net/lists/linux-media/msg79865.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
GrabBee-HD
I have just bought an HDMI to USB-2.0 grabber called "GrabBee-HD". http://www.greada.com/grabbeex-hd.html Motherboard photo: http://www.davekimble.org.au/computers/GrabBee-HD.jpg Inside it has chips labelled "Sigma PL330B-CPE3" and "iTE IT6604E". Note that it compresses the video with H.264 . I knew it probably wouldn't have drivers for Linux, but it does have Windows drivers on CD, so since I run Ubuntu-VirtualBox-WinXP I thought it might well work one way or another. On Ubuntu 14.04, the USB device is picked up: $ lsusb -v -d 0658:1100 Bus 001 Device 007: ID 0658:1100 Sigma Designs, Inc. Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0658 Sigma Designs, Inc. idProduct 0x1100 bcdDevice0.00 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 3 but it is not recognised as a video capture device by VLC. /dev/dvb/ , /dev/v4l/ , /dev/video0 do not exist. So I fired up VB-WinXP and installed the Windows drivers and software, and restarted. Then plugged in the device, which should connect the device to the driver, but it didn't. Starting the Grabbee-HD software gives "No video capture device is connected!" Then I realised the USB device has to be passed through the VB interface, VB-Manager > USB > Add > "no devices available". So because Ubuntu doesn't properly recognise the device, it can't pass it on to VB and XP. Is there any chance of getting this going on Ubuntu 14.04 natively? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GrabBee-HD
Ok, no nobody jumped in the first time around. my turn I guess... :) Comments below. On Thu, Oct 16, 2014 at 5:18 PM, Dave Kimble wrote: > I have just bought an HDMI to USB-2.0 grabber called "GrabBee-HD". > http://www.greada.com/grabbeex-hd.html > Motherboard photo: http://www.davekimble.org.au/computers/GrabBee-HD.jpg > Inside it has chips labelled "Sigma PL330B-CPE3" and "iTE IT6604E". > Note that it compresses the video with H.264 . I've worked on drivers for those two chips in the past. I have a large amount of experience with these parts. > > I knew it probably wouldn't have drivers for Linux, but it does have Windows > drivers on CD, > so since I run Ubuntu-VirtualBox-WinXP I thought it might well work one way > or another. Correct, no Linux drivers. > > On Ubuntu 14.04, the USB device is picked up: > $ lsusb -v -d 0658:1100 > > > but it is not recognised as a video capture device by VLC. > /dev/dvb/ , /dev/v4l/ , /dev/video0 do not exist. Correct. Linux has no support for that device. :( > > So I fired up VB-WinXP and installed the Windows drivers and software, and > restarted. > Then plugged in the device, which should connect the device to the driver, > but it didn't. That's odd. It suggests an (off topic) windows related driver problem, or a virtual machine issue. > Starting the Grabbee-HD software gives "No video capture device is > connected!" > Then I realised the USB device has to be passed through the VB interface, > VB-Manager > USB > Add > "no devices available". > > So because Ubuntu doesn't properly recognise the device, it can't pass it on > to VB and XP. I don't think the virtual machines work that way, at least not in my experience. I've always been able to do what you want to do on various platforms. Sorry, I can't really help you debug Windows / Virtual machine issues. > > Is there any chance of getting this going on Ubuntu 14.04 natively? Unlikely. Sigma are generally GPL unfriendly. I've done drivers for this chip on OSX before, mostly as a R&D exercise, so I'm highly familiar with it. The chip is a monster to write for, kinda nasty to be honest - not very straightforward. I think you're out of luck. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.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
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: Fri Oct 17 04:00:18 CEST 2014 git branch: test git hash: cf3167cf1e969b17671a4d3d956d22718a8ceb85 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.17-0.slh.1-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.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16-x86_64: WARNINGS linux-3.17-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
Re: [PATCH 0/2] media: soc_camera: rcar_vin: Add r8a7794, r8a7793 device support
Hi Guennadi,
On Thu, Oct 16, 2014 at 10:27:13PM +0200, Guennadi Liakhovetski wrote:
> Hello,
>
> Thanks for the patches. Could you please fold these two into one - they
> really don't deserve to be separated.
Thanks. Kaneko-san could you squash these patches and repost?
> As for your other series - patches
> there look mostly good - from just a formal review. If you don't mind,
> I'll adjust a couple of cosmetic issues like missing curly braces in
>
> if (a)
> x();
> else {
> y();
> z();
> }
>
> or multiline comments or similar minor things.
Feel free to make any minor updates.
> Thanks
> Guennadi
>
> On Tue, 14 Oct 2014, Yoshihiro Kaneko wrote:
>
> > This series is against master branch of linuxtv.org/media_tree.git.
> >
> > Koji Matsuoka (2):
> > media: soc_camera: rcar_vin: Add r8a7794 device support
> > media: soc_camera: rcar_vin: Add r8a7793 device support
> >
> > drivers/media/platform/soc_camera/rcar_vin.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > --
> > 1.9.1
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] media: soc_camera: rcar_vin: Add r8a7794, r8a7793 device support
2014-10-17 15:02 GMT+09:00 Simon Horman :
> Hi Guennadi,
>
> On Thu, Oct 16, 2014 at 10:27:13PM +0200, Guennadi Liakhovetski wrote:
>> Hello,
>>
>> Thanks for the patches. Could you please fold these two into one - they
>> really don't deserve to be separated.
>
> Thanks. Kaneko-san could you squash these patches and repost?
Sure, will do.
>
>> As for your other series - patches
>> there look mostly good - from just a formal review. If you don't mind,
>> I'll adjust a couple of cosmetic issues like missing curly braces in
>>
>> if (a)
>> x();
>> else {
>> y();
>> z();
>> }
>>
>> or multiline comments or similar minor things.
>
> Feel free to make any minor updates.
>
>> Thanks
>> Guennadi
>>
>> On Tue, 14 Oct 2014, Yoshihiro Kaneko wrote:
>>
>> > This series is against master branch of linuxtv.org/media_tree.git.
>> >
>> > Koji Matsuoka (2):
>> > media: soc_camera: rcar_vin: Add r8a7794 device support
>> > media: soc_camera: rcar_vin: Add r8a7793 device support
>> >
>> > drivers/media/platform/soc_camera/rcar_vin.c | 2 ++
>> > 1 file changed, 2 insertions(+)
>> >
>> > --
>> > 1.9.1
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sh" 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
