Re: Gadmei 380 on kernel 2.6.28.4
I did a dmesg, include please find the output. If you see carefully, towards the end, there is a USB driver error, and my KINGSTON usb thumb drive get disconnected and reconnected again. --- On Mon, 10/12/09, mctiew mct...@yahoo.com wrote: From: mctiew mct...@yahoo.com Subject: Gadmei 380 on kernel 2.6.28.4 To: linux-media@vger.kernel.org Date: Monday, October 12, 2009, 3:32 AM I am trying to use the gadmei 380 which I bought yesterday. I am using kernel 2.6.28.4, I downloaded the entire ~dougsland/em28xx and did a make and install. Everything went on smoothly. However, when I plug in the gadmei 380 usb device, it seems the driver can get loaded by the usb pnp, but at the same time, one of my usb pendrive will get disconnected. Because that's my boot drive ( I boot off from the usb drive ), that will cause problem with my system. Anyone has experienced this before ? gadmei.log Description: Binary data
S2API and DVB-T tuning
Hello, I have some problems with DVB-T tuning under s2-api/DVB API 5 To run these tests I use scan-s2-7effc68db255 My machine runs the following kernel (uname -a) Linux fixe_barcelone 2.6.31-13-generic #42-Ubuntu SMP Thu Oct 8 20:03:54 UTC 2009 x86_64 GNU/Linux And I own 3 DVB-T devices : 1: 01:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Device 1012 Flags: bus master, medium devsel, latency 64, IRQ 21 Memory at fa6ffc00 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_ci dvb Kernel modules: budget-ci 2: Bus 001 Device 010: ID 2040:7070 Hauppauge 3: Bus 001 Device 011: ID 07ca:a815 AVerMedia Technologies, Inc. All three devices tune well and work flawlessly with scan (dvb api v3) But when I use scan-s2, only the AVerMedia is able to lock I use the dvb-t/es-Collserola as an initial tuning file. I thought the S2API shouldn't change the tuning behavior. I tried to search the Mailing list archives via google I unfortunately found nothing. I'm sorry if this subject was discussed before. What can I do to investigate more on this issue ? PS : I join the debug output for the sucessful and unsucessful tuning Thanks -- Brice A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? Oct 12 13:02:28 fixe_barcelone kernel: [228614.407730] DiB7000P: setting output mode for demod 880139055000 to 0 Oct 12 13:02:28 fixe_barcelone kernel: [228614.416623] DiB0070: Tuning for Band: 2 (514000 kHz) Oct 12 13:02:28 fixe_barcelone kernel: [228614.448106] DiB0070: HFDIV code: 5 Oct 12 13:02:28 fixe_barcelone kernel: [228614.448112] DiB0070: VCO = 1 Oct 12 13:02:28 fixe_barcelone kernel: [228614.448115] DiB0070: VCOF in kHz: 6168000 ((6*514000) 1)) Oct 12 13:02:28 fixe_barcelone kernel: [228614.448120] DiB0070: REFDIV: 1, FREF: 12000 Oct 12 13:02:28 fixe_barcelone kernel: [228614.448124] DiB0070: FBDIV: 85, Rest: 43520 Oct 12 13:02:28 fixe_barcelone kernel: [228614.448127] DiB0070: Num: -22016, Den: 255, SD: 1 Oct 12 13:02:28 fixe_barcelone kernel: [228614.513606] DiB0070: CAPTRIM=64; ADC = 905 (ADC) 1590mV Oct 12 13:02:28 fixe_barcelone kernel: [228614.513613] DiB0070: CAPTRIM=64 is closer to target (505/3000) Oct 12 13:02:28 fixe_barcelone kernel: [228614.534355] DiB0070: CAPTRIM=32; ADC = 35 (ADC) 61mV Oct 12 13:02:28 fixe_barcelone kernel: [228614.534362] DiB0070: CAPTRIM=32 is closer to target (365/505) Oct 12 13:02:28 fixe_barcelone kernel: [228614.554356] DiB0070: CAPTRIM=48; ADC = 34 (ADC) 59mV Oct 12 13:02:28 fixe_barcelone kernel: [228614.574981] DiB0070: CAPTRIM=56; ADC = 141 (ADC) 247mV Oct 12 13:02:28 fixe_barcelone kernel: [228614.574988] DiB0070: CAPTRIM=56 is closer to target (259/365) Oct 12 13:02:28 fixe_barcelone kernel: [228614.594356] DiB0070: CAPTRIM=60; ADC = 285 (ADC) 500mV Oct 12 13:02:28 fixe_barcelone kernel: [228614.594363] DiB0070: CAPTRIM=60 is closer to target (115/259) Oct 12 13:02:28 fixe_barcelone kernel: [228614.614357] DiB0070: CAPTRIM=62; ADC = 420 (ADC) 738mV Oct 12 13:02:28 fixe_barcelone kernel: [228614.614364] DiB0070: CAPTRIM=62 is closer to target (20/115) Oct 12 13:02:28 fixe_barcelone kernel: [228614.634484] DiB0070: CAPTRIM=61; ADC = 343 (ADC) 602mV Oct 12 13:02:29 fixe_barcelone kernel: [228614.759111] DiB7000P: SPLIT 880139055000: 176 Oct 12 13:02:29 fixe_barcelone kernel: [228614.790742] DiB7000P: using default timf Oct 12 13:02:29 fixe_barcelone kernel: [228615.090748] DiB7000P: updated timf_frequency: 20452445 (default: 20452225) Oct 12 13:02:29 fixe_barcelone kernel: [228615.090756] DiB7000P: relative position of the Spur: 2000k (RF: 514000k, XTAL: 12000k) Oct 12 13:02:29 fixe_barcelone kernel: [228615.091871] DiB7000P: PALF COEF: 0 re: 25 im: 124 Oct 12 13:02:29 fixe_barcelone kernel: [228615.095246] DiB7000P: PALF COEF: 1 re: -103 im: 43 Oct 12 13:02:29 fixe_barcelone kernel: [228615.098618] DiB7000P: PALF COEF: 2 re: -52 im: -79 Oct 12 13:02:29 fixe_barcelone kernel: [228615.101995] DiB7000P: PALF COEF: 3 re: 54 im: -53 Oct 12 13:02:29 fixe_barcelone kernel: [228615.105368] DiB7000P: PALF COEF: 4 re: 45 im: 30 Oct 12 13:02:29 fixe_barcelone kernel: [228615.108745] DiB7000P: PALF COEF: 5 re: -11 im: 28 Oct 12 13:02:29 fixe_barcelone kernel: [228615.112995] DiB7000P: PALF COEF: 6 re: -5 im: 0 Oct 12 13:02:29 fixe_barcelone kernel: [228615.116373] DiB7000P: PALF COEF: 7 re: 0 im: 19 Oct 12 13:02:29 fixe_barcelone kernel: [228615.120871] DiB7000P: using updated timf Oct 12 13:02:29 fixe_barcelone kernel: [228615.124493] DiB7000P: setting output mode for demod 880139055000 to 5 Oct 12 13:02:29 fixe_barcelone kernel: [228615.129290] function : dvb_dmxdev_filter_set Oct 12 13:02:29 fixe_barcelone kernel: [228615.129514] function : dvb_dmxdev_filter_set Oct 12 13:01:55 fixe_barcelone kernel: [228581.408427] DiB7000P: setting output
Re: How to store the latest image without modifying videobuf-core.c
On Mon, Oct 12, 2009 at 3:33 AM, Mattias Persson d9...@yahoo.se wrote: Hi, Please send messages to the new mailing list: linux-media@vger.kernel.org from now on. I am developing a driver for a camera. As an example I am using the vivi driver (2.6.28) and the first major difference between my ISR and thread_tick() is that my driver will always attempt to store the latest image, even if nobody is waiting for a new image. I believe the standard here is that your driver should simply drop the frame if no one is waiting for it. In my driver, when all queued buffers are used any new images will be stored in the oldest frame which has already been captured (state == VIDEOBUF_DONE) and here is where my problems start. (If this is wrong, what shall I do to always keep the latest captured image?) If no one wants the image you should just drop it but note that it existed. I believe the v4l2 api has frame counters so that the application knows that it missed some. In the function videobuf_dqbuf in videobuf-core.c, if a new image is returned by stream_next_buffer and the ISR kicks in before videobuf_dqbuf can set buf-state to VIDEOBUF_IDLE, my driver will modify the image presented to userspace and that is not acceptable. Correct, it's not acceptable to modify userspace memory when not asked to do so. The only solution I can find is to use the spinlock in videobuf_queue when the userspace application is requesting a new image (DQBUF/poll) to check for a new image and set some flag indicating that the buffer can't be overwritten by the ISR. However, this approach would require changes to videobuf-core.c and that doesn't seem right. Can someone please give me some guidance on this? Regards, Mattias You might want to take a look at possibly using gspca as a base for your driver. It currently supports hundreds of cameras and there are quite a few drivers that you can use as a reference. gspca doesn't use videobuf.. but should make it less painful to write a driver. Regards, David Ellingsworth -- 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: S2API and DVB-T tuning
DUBOST Brice a écrit : Hello, I have some problems with DVB-T tuning under s2-api/DVB API 5 To run these tests I use scan-s2-7effc68db255 My machine runs the following kernel (uname -a) Linux fixe_barcelone 2.6.31-13-generic #42-Ubuntu SMP Thu Oct 8 20:03:54 UTC 2009 x86_64 GNU/Linux And I own 3 DVB-T devices : 1: 01:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Device 1012 Flags: bus master, medium devsel, latency 64, IRQ 21 Memory at fa6ffc00 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_ci dvb Kernel modules: budget-ci 2: Bus 001 Device 010: ID 2040:7070 Hauppauge 3: Bus 001 Device 011: ID 07ca:a815 AVerMedia Technologies, Inc. All three devices tune well and work flawlessly with scan (dvb api v3) But when I use scan-s2, only the AVerMedia is able to lock I use the dvb-t/es-Collserola as an initial tuning file. I thought the S2API shouldn't change the tuning behavior. I tried to search the Mailing list archives via google I unfortunately found nothing. I'm sorry if this subject was discussed before. What can I do to investigate more on this issue ? Hello One more information, if I change 51400 8MHz 2/3 AUTO QAM64 8k 1/4 NONE by 51400 8MHz 2/3 AUTO AUTO 8k 1/4 NONE it works with scan-s2 With old scan it works for both Hope this will help to find the issue Regards -- Brice A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Pull request: http://linuxtv.org/hg/~hgoede/gspca
Hi Mauro, Please pull from: http://linuxtv.org/hg/~hgoede/gspca Besides the changes from my previous pull request, my tree now also contains support for ovfx2 based cams Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC (v1.1): V4L - Support for video timings at the input/output interface
Hans,
So the only change will be about renaming the flags..
Do you expect LCD VESA timings defined by V4L2_DV_BT_656_1120 timing type?
I will update the RFC with capabilities flags renamed as discussed and re-send
it and work on implementation based on this version.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Saturday, October 10, 2009 2:39 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
Subject: Re: RFC (v1.1): V4L - Support for video timings at the
input/output interface
On Saturday 10 October 2009 17:07:36 Karicheri, Muralidharan wrote:
Hans,
From: Hans Verkuil [hverk...@xs4all.nl]
Sent: Friday, October 09, 2009 10:43 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
Subject: Re: RFC (v1.1): V4L - Support for video timings at the
input/output interface
i Murali,
Reading through this I noticed that there was one thing that is probably
no longer needed: now that we have the SUPPORTS_CUSTOM_TIMING capability
there is no need to include the CUSTOM preset when enumerating presets.
Instead I suggest that the INVALID preset define takes the place of the
CUSTOM preset.
[MK] Ok.
Also, these capabilities should probably be renamed to
V4L2_IN_CAP_STD/PRESETS/CUSTOM.
This is more in line with the current naming convention.
[MK] I think this is only partially correct. These presets applies to
OUTPUT as well. So We might want to
define V4L2_OUT_CAP_STD/PRESETS/CUSTOM as well or Keep it as is.
I got confused here by the tuner and modulator flags where the tuner flags
are reused by the modulator flags. Sorry about that.
So I think it is best to have both V4L2_IN_CAP and V4L2_OUT_CAP defines.
These
may initially be the same, but I would not be surprised if we start seeing
caps that are unique to either input or output in the future. Just my
opinion,
though.
Otherwise I think this is pretty good.
One thing: did you check against the FB API? We should have at least the
same timing parameters as they have (it is my understanding that timings
can also be setup through the FB API).
In FB, following parameters defined for video mode. I have mapped it
to
timing parameter below. I have used modedb.c to understand the parameters.
Probably add a timing type for VESA and a structure similar to
fb_videomode???
struct fb_videomode {
const char *name; /* optional */ - Missing in our API
I don't see a good reason for adding this.
u32 refresh;/* optional */ - Missing in
out API.
This can be calculated from the other arguments.
u32 xres; -
width
u32 yres; -
height
u32 pixclock; - -
pixelclock
u32 left_margin; -
hfrontporch (should we rename to left_margin ??)
u32 right_margin;- Need to
derive - should we add right margin??
u32 upper_margin; - vfrontporch
(should we rename to upper margin??)
u32 lower_margin; - Need to
derive - should we add lower margin??)
h/vfrontporch is more standard than margin, so I vote for keeping that
terminology. Neither should we add right/lower margin. We have total
width/height instead which is also more commonly used.
u32 hsync_len;- hsync -
better to rename this as hsync_len
u32 vsync_len;- vsync -
better to rename
No need for a rename IMHO. If we do that, then hfrontporch and htotal also
need to be renamed.
The important bit is that all the same timings are represented here.
u32 sync; -
polarities
u32 vmode; -
interlaced
u32 flag; -
Missing. May be add this ???
Are there any flags defined? We have reserved fields that we can utilize in
the future.
Regards,
Hans
};
Out timing definition.
/* bt.656/bt.1120 timing data */
struct v4l2_bt_timings {
__u32 interlaced;
__u64 pixelclock;
__u32 width, height;
__u32 polarities;
__u32 hfrontporch, hsync, htotal;
__u32 vfrontporch, vsync, vtotal;
/* timings for bottom frame for interlaced formats */
__u32 il_vtotal;
__u32 reserved[16];
};
Regards,
Hans
Hello,
Here is the version 1.1 of the RFC which will be used for implementing
the video timing APIs in the V4L2 core. Please review and let me
RE: RFC (v1.1): V4L - Support for video timings at the input/output interface
Hans,
So the only change will be about renaming the flags..
Do you expect LCD VESA timings defined by V4L2_DV_BT_656_1120 timing type?
As far as I am aware, yes. But I have little experience with LCDs.
I will update the RFC with capabilities flags renamed as discussed and
re-send it and work on implementation based on this version.
Great!
Hans
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Saturday, October 10, 2009 2:39 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
Subject: Re: RFC (v1.1): V4L - Support for video timings at the
input/output interface
On Saturday 10 October 2009 17:07:36 Karicheri, Muralidharan wrote:
Hans,
From: Hans Verkuil [hverk...@xs4all.nl]
Sent: Friday, October 09, 2009 10:43 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
Subject: Re: RFC (v1.1): V4L - Support for video timings at the
input/output interface
i Murali,
Reading through this I noticed that there was one thing that is
probably
no longer needed: now that we have the SUPPORTS_CUSTOM_TIMING
capability
there is no need to include the CUSTOM preset when enumerating presets.
Instead I suggest that the INVALID preset define takes the place of the
CUSTOM preset.
[MK] Ok.
Also, these capabilities should probably be renamed to
V4L2_IN_CAP_STD/PRESETS/CUSTOM.
This is more in line with the current naming convention.
[MK] I think this is only partially correct. These presets applies to
OUTPUT as well. So We might want to
define V4L2_OUT_CAP_STD/PRESETS/CUSTOM as well or Keep it as is.
I got confused here by the tuner and modulator flags where the tuner
flags
are reused by the modulator flags. Sorry about that.
So I think it is best to have both V4L2_IN_CAP and V4L2_OUT_CAP defines.
These
may initially be the same, but I would not be surprised if we start
seeing
caps that are unique to either input or output in the future. Just my
opinion,
though.
Otherwise I think this is pretty good.
One thing: did you check against the FB API? We should have at least
the
same timing parameters as they have (it is my understanding that
timings
can also be setup through the FB API).
In FB, following parameters defined for video mode. I have mapped
it
to
timing parameter below. I have used modedb.c to understand the
parameters.
Probably add a timing type for VESA and a structure similar to
fb_videomode???
struct fb_videomode {
const char *name; /* optional */ - Missing in our
API
I don't see a good reason for adding this.
u32 refresh;/* optional */ - Missing in
out API.
This can be calculated from the other arguments.
u32 xres; -
width
u32 yres; -
height
u32 pixclock; - -
pixelclock
u32 left_margin; -
hfrontporch (should we rename to left_margin ??)
u32 right_margin;- Need to
derive - should we add right margin??
u32 upper_margin; -
vfrontporch
(should we rename to upper margin??)
u32 lower_margin; - Need to
derive - should we add lower margin??)
h/vfrontporch is more standard than margin, so I vote for keeping that
terminology. Neither should we add right/lower margin. We have total
width/height instead which is also more commonly used.
u32 hsync_len;- hsync
-
better to rename this as hsync_len
u32 vsync_len;- vsync -
better to rename
No need for a rename IMHO. If we do that, then hfrontporch and htotal
also
need to be renamed.
The important bit is that all the same timings are represented here.
u32 sync; -
polarities
u32 vmode; -
interlaced
u32 flag; -
Missing. May be add this ???
Are there any flags defined? We have reserved fields that we can utilize
in
the future.
Regards,
Hans
};
Out timing definition.
/* bt.656/bt.1120 timing data */
struct v4l2_bt_timings {
__u32 interlaced;
__u64 pixelclock;
__u32 width, height;
__u32 polarities;
__u32 hfrontporch, hsync, htotal;
__u32 vfrontporch, vsync, vtotal;
/* timings for bottom frame for interlaced formats */
__u32 il_vtotal;
__u32 reserved[16];
};
Regards,
Hans
Hello,
Here is the version 1.1
pxa-camera: build error 2.6.32-rc4
Error was drivers/media/video/pxa_camera.c: In function 'pxa_camera_wakeup': drivers/media/video/pxa_camera.c:683: error: 'TASK_NORMAL' undeclared (first use in this function) drivers/media/video/pxa_camera.c:683: error: (Each undeclared identifier is reported only once drivers/media/video/pxa_camera.c:683: error: for each function it appears in.) CC [M] drivers/pcmcia/soc_common.o Line in question is wake_up(vb-done); in pxa_camera_wakeup. Looks like issue is lack of inclusion of sched.h. Right now I'm having trouble tracking down why this became and issue since 2.6.32-rc3. Might be related to Staging: comedi: Add include of linux/sched.h to fix build which is down to removal of sched.h from poll.h commmit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184 Looks like media/v4l2-dev.h and others include poll.h so I'm guessing we were original getting it from there. I'm happy to post a patch but was wondering if anyone else has seen this or has tracked down exactly what changed, not to mention if this is a more general problem? (or for that matter already fixed and I just missed it.) Thanks Jonathan -- 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: pxa-camera: build error 2.6.32-rc4
Jonathan Cameron wrote: Error was drivers/media/video/pxa_camera.c: In function 'pxa_camera_wakeup': drivers/media/video/pxa_camera.c:683: error: 'TASK_NORMAL' undeclared (first use in this function) drivers/media/video/pxa_camera.c:683: error: (Each undeclared identifier is reported only once drivers/media/video/pxa_camera.c:683: error: for each function it appears in.) CC [M] drivers/pcmcia/soc_common.o Line in question is wake_up(vb-done); in pxa_camera_wakeup. Looks like issue is lack of inclusion of sched.h. Right now I'm having trouble tracking down why this became and issue since 2.6.32-rc3. Might be related to Staging: comedi: Add include of linux/sched.h to fix build which is down to removal of sched.h from poll.h commmit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184 Looks like media/v4l2-dev.h and others include poll.h so I'm guessing we were original getting it from there. I'm happy to post a patch but was wondering if anyone else has seen this or has tracked down exactly what changed, not to mention if this is a more general problem? (or for that matter already fixed and I just missed it.) Just read lkml, Ingo Molnar has posted a whole set of patches (in reply to Linus' 2.6.32-rc4 thread) dealing with this issue in a number of other places. This one isn't there however. Jonathan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Oct 12 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13095:5578cc977a13 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc3-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.32-rc3-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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] pxa-camera: Fix missing sched.h
On Mon, 12 Oct 2009, Jonathan Cameron wrote: linux/sched.h include was removed form linux/poll.h by commmit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184 Required for wakeup call. Signed-off-by: Jonathan Cameron ji...@cam.ac.uk Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Mauro, can you take it from here with my ack for -rc5 or do I have to pull it through my tree? Thanks Guennadi --- drivers/media/video/pxa_camera.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c index 6952e96..5d01dcf 100644 --- a/drivers/media/video/pxa_camera.c +++ b/drivers/media/video/pxa_camera.c @@ -26,6 +26,7 @@ #include linux/device.h #include linux/platform_device.h #include linux/clk.h +#include linux/sched.h #include media/v4l2-common.h #include media/v4l2-dev.h -- 1.6.3.3 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB support for MSI DigiVox A/D II and KWorld 320U
On Mon, Oct 12, 2009 at 3:23 PM, Lauri Laanmets lauri.laanm...@proekspert.ee wrote: Hello I have KWorld 320U USB DVT-T Hybrid and trying to get DVB part working. The code from mcentral worked pretty well but as it is closed down now I would like to contribute to linux-media and enable and validate the hardware support for this device. I have: Linux 2.6.28-15-generic x86_64 GNU/Linux Bus 001 Device 002: ID eb1a:e320 eMPIA Technology, Inc. This device has the same id with MSI DigiVox A/D II but I guess it shouldn't matter because it appears to be exactly the same thing just with the different brand label with Zarlink ZL10353 DVB-T on both boards. I have downloaded the code from v4l-dvb and commented out the #if 0 around the device dvb definition ( em28xx-cards.c ), also added it to frontend registration ( em28xx-dvb.c) the same as KWorld 310 - just a normal Zarlink attach function. The trouble is that I get an error: zl10353_read_register: readreg error (reg=127, ret==-19) and I cannot understand why. I have the mcentral code still lying around and comparing those codes doesn't seem to have any difference. Maybe there still is a magic bit somewhere to set? In em28xx-dvb.c, try using em28xx_zl10353_with_xc3028_no_i2c_gate in the dvb_attach() instead of em28xx_zl10353_with_xc3028. Alternatively, move the case line for your board further down so it's the same as EM2882_BOARD_TERRATEC_HYBRID_XS instead of being the same as EM2880_BOARD_KWORLD_DVB_310U Devin -- Devin J. Heitmueller - 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
Re: Haupp. HVR-1100 problem and DVB-T card
Am Sonntag, den 11.10.2009, 19:29 + schrieb fabio tirapelle: Hi Hermann Hi Fabio, Am Donnerstag, den 08.10.2009, 20:02 + schrieb fabio tirapelle: Hi I have installed mythtv on this configuration: Asus M3N78-VM GF8200 RGVSM AMD Ath64 X2LV 3100BOX6000+ 1MB Haupp. WinTV HVR-1100 -t/a PCI TechniSat SkyStar 2 DVB-S PCI nVidia GeForce 8200 Ubuntu 8.10 - Linux htpc 2.6.27-11-generic did send to those likely interested too and might be able to give better advice. Two questions 1) But the Haupp. WinTV will not be found even if I have followed http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1110 http://ubuntuforums.org/showthread.php?t=623126page=2 (#12) Output of dmesg [ 13.062214] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 17 [ 13.062223] b2c2_flexcop_pci :01:06.0: PCI INT A - Link[LNKA] - GSI 17 (level, low) - IRQ 17 [ 13.076654] DVB: registering new adapter (FlexCop Digital TV device) [ 13.078432] b2c2-flexcop: MAC address = 00:d0:d7:0d:30:88 [ 13.078664] b2c2-flexcop: i2c master_xfer failed [ 13.078893] b2c2-flexcop: i2c master_xfer failed [ 13.078895] CX24123: cx24123_i2c_readreg: reg=0x0 (error=-121) [ 13.078897] CX24123: wrong demod revision: 87 [ 13.101063] saa7130/34: v4l2 driver version 0.2.14 loaded [ 13.360642] b2c2-flexcop: found 'ST STV0299 DVB-S' . [ 13.360647] DVB: registering frontend 0 (ST STV0299 DVB-S)... [ 13.360768] b2c2-flexcop: initialization of 'Sky2PC/SkyStar 2 DVB-S' at the 'PCI' bus controlled by a 'FlexCopIIb' complete [ 13.363507] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 16 [ 13.363517] saa7134 :01:07.0: PCI INT A - Link[LNKB] - GSI 16 (level, low) - IRQ 16 [ 13.363523] saa7133[0]: found at :01:07.0, rev: 255, irq: 16, latency: 255, mmio: 0x0 Memory allocation at the PCI bus fails and PCI latency is very high for nothing in the end. [ 13.363528] saa7133[0]: subsystem: :, board: UNKNOWN/GENERIC [card=0,autodetected] Either the eeprom is corrupted, or more likely, this fails because of the previous failing. [ 13.363531] saa7133[0]: can't get MMIO memory @ 0x0 [ 13.363538] saa7134: probe of :01:07.0 failed with error -16 [ 13.393682] saa7134 ALSA driver for DMA sound loaded [ 13.393685] saa7134 ALSA: no saa7134 cards found ouput lspci 01:06.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02) 01:07.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1) 2) What kind of DVB-T card will you suggest for my configuration instead of Hauppage WinTv? We have some unknowns on the various Hauppauge 1110s, but in general they are assumed to be well supported. They are all auto eeprom detectable and only for latest revisions you need some latest mercurial v4l-dvb. These look good now too. Could you try again with the HVR1110 as the only PCI card? I have tried without success If this still fails, the mobo seems not to be best treated anyway too, I would guess the card is broken. What kind of mobo do you suggest? If necessary I can buy a new mobo Cheers, Hermann Thanks Fabio Hi Fabio, I would try to test the HVR1110 next on another PC with known working PCI hardware, also above different operating systems if possible. We know that the HVR1110s are properly detected on almost all hardware. Before thinking about replacing mobo/PSU, make sure the card is OK. Cheers, Hermann -- 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: DVB support for MSI DigiVox A/D II and KWorld 320U
Hello Tried that but the result is basically the same: zl10353_attach gives [ 491.490259] zl10353_read_register: readreg error (reg=127, ret==-19) And it is funny that if I compile the mcentral latest code in the same kernel, it works, but I cannot find the difference in the code :) Lauri Devin Heitmueller wrote: In em28xx-dvb.c, try using em28xx_zl10353_with_xc3028_no_i2c_gate in the dvb_attach() instead of em28xx_zl10353_with_xc3028. Alternatively, move the case line for your board further down so it's the same as EM2882_BOARD_TERRATEC_HYBRID_XS instead of being the same as EM2880_BOARD_KWORLD_DVB_310U Devin -- 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: DVB support for MSI DigiVox A/D II and KWorld 320U
On Mon, Oct 12, 2009 at 4:41 PM, Lauri Laanmets lauri.laanm...@proekspert.ee wrote: Hello Tried that but the result is basically the same: zl10353_attach gives [ 491.490259] zl10353_read_register: readreg error (reg=127, ret==-19) And it is funny that if I compile the mcentral latest code in the same kernel, it works, but I cannot find the difference in the code :) Lauri Check the dvb_gpio setting in the board profile. On some of those boards you need to take put one of the GPO pins high to take the demod out of reset. The KWorld 315u and 330u are both like that. Devin -- Devin J. Heitmueller - 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
Re: Dazzle TV Hybrid USB and em28xx
Devin Heitmueller dheitmueller at kernellabs.com writes: Hello Giuseppe, Make sure you have the latest v4l-dvb code installed. The changes for that board went in relatively recently (make sure you do *not* specify a card= modprobe parameter). http://linuxtv.org/repo But analog TV has no audio (I've tried sox/arecord-aplay), Make sure you have the correct standard selected. This sort of thing often occurs when you are in an area with PAL support but you have the device configured for NTSC. teletext doesn't work (mtt segfaults) and DVB doesn't work too. Teletext is not supported currently - I did the NTSC VBI support and am planning on doing the PAL support in the next couple of weeks. With me-tv I get an error message like Failed to tune to channel and sometimes a timeout. A fix for this was done this week (but hasn't been checked in yet). Check the linux-media archive for the PCTV 320e thread. Devin Thanks for your prompt reply. I've downloaded v4l-dvb-5578cc977a13.tar.bz2, but it fails to compile when it reaches firedtv-1394.c. The first part of the error message is /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:21:17: error: dma.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:22:21: error: csr1212.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:23:23: error: highlevel.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:24:19: error: hosts.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:25:22: error: ieee1394.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:26:17: error: iso.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:27:21: error: nodemgr.h: No such file or directory what follows are several warning and error messages about implicit declarations and dereferencing pointer to incomplete type related to the lack of the above include files. I'll try again after configuring the compilation to avoid that error message, i.e. by compiling only the modules I need for em28xx. -- 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: Kworld Analog TV 305U without audio - updated
On Mon, Oct 12, 2009 at 5:20 PM, Dênis Goes denish...@gmail.com wrote: Hi... I updated the driver to latest in repository, but I having audio problems yet: I'm testing a USB TV Kworld PlusTV Analog TV stick VS-PVR-TV 305U the TV video works fine, but without audio... I tried to pipe the audio via sox: tvtime -d /dev/video1 sox -v 1 -V4 -S -t ossdsp /dev/dsp1 -t ossdsp /dev/dsp - But without sucess, sox report follow error: sox: SoX v14.2.0 time: Dec 1 2008 10:12:25 issue: Ubuntu jaunty (development branch) uname: Linux denis-laptop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 gcc: 4.3.3 20081130 (prerelease) arch: 1248 48 44 L sox oss: OSS driver only supports bytes and words sox oss: Forcing to signed linear word Input File : '/dev/dsp1' (ossdsp) Channels : 2 Sample Rate : 48000 Precision : 16-bit Sample Encoding: 16-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no Level adjust : 1 (linear gain) Output File : '/dev/dsp' (ossdsp) Channels : 2 Sample Rate : 48000 Precision : 16-bit Sample Encoding: 16-bit Signed Integer PCM Endian Type : little Reverse Nibbles: no Reverse Bits : no sox sox: effects chain: input 48000Hz 2 channels 16 bits (multi) sox sox: effects chain: output 48000Hz 2 channels 16 bits (multi) In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 sox sox: /dev/dsp1: lsx_readbuf: Input/output error In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 Done. - Follow my dmesg: [ 59.904056] usb 1-1: new high speed USB device using ehci_hcd and address 5 [ 60.058312] usb 1-1: configuration #1 chosen from 1 choice [ 60.180943] em28xx: New device USB 2861 Device @ 480 Mbps (eb1a:e305, interface 0, class 0) [ 60.181035] em28xx #0: chip ID is em2860 [ 60.450213] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 05 e3 d0 00 5c 00 6a 22 00 00 [ 60.450223] em28xx #0: i2c eeprom 10: 00 00 04 57 4e 03 00 00 00 00 00 00 00 00 00 00 [ 60.450231] em28xx #0: i2c eeprom 20: 06 00 01 00 f0 10 01 00 00 00 00 00 5b 00 00 00 [ 60.450239] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 60.450246] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 60.450253] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 60.450260] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [ 60.450268] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 36 00 31 00 20 00 44 00 [ 60.450275] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [ 60.450282] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 60.450289] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 60.450297] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 60.450304] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 60.450311] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 60.450318] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 60.450325] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 60.450334] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x28a51142 [ 60.450336] em28xx #0: EEPROM info: [ 60.450338] em28xx #0: AC97 audio (5 sample rates) [ 60.450340] em28xx #0: 500mA max power [ 60.450342] em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x [ 60.450345] em28xx #0: Identified as KWorld DVB-T 305U (card=47) [ 60.450347] em28xx #0: [ 60.450348] [ 60.450351] em28xx #0: The support for this board weren't valid yet. [ 60.450353] em28xx #0: Please send a report of having this working [ 60.450355] em28xx #0: not to V4L mailing list (and/or to other addresses) [ 60.450356] [ 60.458495] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0) [ 60.468901] tuner 1-0061: chip found @ 0xc2 (em28xx #0) [ 60.516398] xc2028 1-0061: creating new instance [ 60.516403] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [ 60.516413] usb 1-1: firmware: requesting xc3028-v27.fw [ 60.562982] xc2028
Re: Dazzle TV Hybrid USB and em28xx
On Mon, Oct 12, 2009 at 4:49 PM, Giuseppe Borzi gbo...@gmail.com wrote: Thanks for your prompt reply. I've downloaded v4l-dvb-5578cc977a13.tar.bz2, but it fails to compile when it reaches firedtv-1394.c. The first part of the error message is /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:21:17: error: dma.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:22:21: error: csr1212.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:23:23: error: highlevel.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:24:19: error: hosts.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:25:22: error: ieee1394.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:26:17: error: iso.h: No such file or directory /home/gborzi/v4l-dvb-5578cc977a13/v4l/firedtv-1394.c:27:21: error: nodemgr.h: No such file or directory Yeah, that happens with Ubuntu Karmic. The v4l-dvb firedtv driver depends on headers that are private to ieee1394 and not in their kernel headers package. To workaround the issue, open v4l/.config and set the firedtv driver from =m to =n Devin -- Devin J. Heitmueller - 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
Re: Kworld Analog TV 305U without audio - updated
On Mon, Oct 12, 2009 at 5:20 PM, Dênis Goes denish...@gmail.com wrote: Hi... I updated the driver to latest in repository, but I having audio problems yet: I'm testing a USB TV Kworld PlusTV Analog TV stick VS-PVR-TV 305U the TV video works fine, but without audio... I tried to pipe the audio via sox: tvtime -d /dev/video1 sox -v 1 -V4 -S -t ossdsp /dev/dsp1 -t ossdsp /dev/dsp Just as a test, try opening two console windows, run tvtime in one, and then once the video is showing run the sox command in the other window. I just want to rule out this being some sort of race condition. Devin -- Devin J. Heitmueller - 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
Status of v4l repositories / merging new one
Hello List AFAIK there are different v4l repositories supporting differnet hardware, e.g v4l-dvb(missing skystar HD), liplianin (missing knc1) etc. To add another one, we have a repository supporting the pci-e dual dvb-s low pointer profile mediapointer card :) But for my distribution I'd like to have one repository, supporting all cards Whats to do to get all these repositories merged ? Are there any plans about doing that ? -- Helmut Auer, hel...@helmutauer.de -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx mode switching
I was debugging an issue on a user's hybrid board, when I realized that we are switching the em28xx mode whenever we start and stop dvb streaming. We already have the ts_bus_ctrl callback implemented which puts the device into digital mode and puts it back into suspend whenever the frontend is opened/closed. This call seems redundant, and in fact can cause problems if the dvb_gpio definition strobes the reset pin, as it can put the driver out of sync with the demodulator's state (in fact this is what I ran into with the zl10353 - the reset pin got strobed when the streaming was started but the demod driver's init() routine was not being run because it already ran when the frontend was originally opened). The only case I can think of where toggling the device mode when starting/stopping dvb streaming might be useful is if we wanted to support being able to do an analog tune while the dvb frontend was still open but not streaming. However, this seems like this could expose all sorts of bugs, and I think the locking would have to be significantly reworked if this were a design goal. Thoughts anybody? Devin -- Devin J. Heitmueller - 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
Re: em28xx mode switching
On 10/13/2009 01:12 AM, Devin Heitmueller wrote: I was debugging an issue on a user's hybrid board, when I realized that we are switching the em28xx mode whenever we start and stop dvb streaming. We already have the ts_bus_ctrl callback implemented which puts the device into digital mode and puts it back into suspend whenever the frontend is opened/closed. This call seems redundant, and in fact can cause problems if the dvb_gpio definition strobes the reset pin, as it can put the driver out of sync with the demodulator's state (in fact this is what I ran into with the zl10353 - the reset pin got strobed when the streaming was started but the demod driver's init() routine was not being run because it already ran when the frontend was originally opened). The only case I can think of where toggling the device mode when starting/stopping dvb streaming might be useful is if we wanted to support being able to do an analog tune while the dvb frontend was still open but not streaming. However, this seems like this could expose all sorts of bugs, and I think the locking would have to be significantly reworked if this were a design goal. Thoughts anybody? Devin I ran this same trap few weeks ago when adding Reddo DVB-C USB Box support to em28xx :) Anyhow, since it is dvb only device I decided to switch from .dvb_gpio to .tuner_gpio to fix the problem. I haven't pull requested it yet. http://linuxtv.org/hg/~anttip/reddo-dvb-c/rev/38f946af568f Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kworld Analog TV 305U without audio - updated
On Mon, Oct 12, 2009 at 6:45 PM, Dênis Goes denish...@gmail.com wrote: Hi... I was seeing in em28xx-cards.c in KWorld DVB-T 305U section, that is the more aproximate model for my card, and I have a doubt, my card is analog only (although it's 305U also), but the 305U in em28xx-cards.c have DVB-T, can be any parameter for card that causing the problem ? Thanks. It's not clear why the product name says DVB-T since the board profile that follows doesn't have a DVB-T definition. Either way, that's not having an effect on your issue. Devin -- Devin J. Heitmueller - 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
Re: Dazzle TV Hybrid USB and em28xx
Yeah, that happens with Ubuntu Karmic. The v4l-dvb firedtv driver depends on headers that are private to ieee1394 and not in their kernel headers package. To workaround the issue, open v4l/.config and set the firedtv driver from =m to =n Devin Thanks Devin, following your instruction for firedtv I've compiled v4l-dvb-5578cc977a13 but the results aren't so good. After doing an make rminstall , compiling and make install I plugged the USB stick, the various devices were created (including /dev/dvb) and here is the dmesg output (now it's identified as card=1) usb 1-3.1: new high speed USB device using ehci_hcd and address 7 usb 1-3.1: configuration #1 chosen from 1 choice Linux video capture interface: v2.00 em28xx: New device USB 2881 Video @ 480 Mbps (eb1a:2881, interface 0, class 0) em28xx #0: chip ID is em2882/em2883 em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 00 6a 20 6a 00 em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 02 00 b8 00 00 00 5b 1e 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 02 00 00 00 00 00 00 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom e0: 5a 00 55 aa 79 55 54 03 00 17 98 01 00 00 00 00 em28xx #0: i2c eeprom f0: 0c 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb8846b20 em28xx #0: EEPROM info: em28xx #0: AC97 audio (5 sample rates) em28xx #0: USB Remote wakeup capable em28xx #0: 500mA max power em28xx #0: Table at 0x04, strings=0x206a, 0x006a, 0x em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) em28xx #0: Your board has no unique USB ID. em28xx #0: A hint were successfully done, based on eeprom hash. em28xx #0: This method is not 100% failproof. em28xx #0: If the board were missdetected, please email this log to: em28xx #0: V4L Mailing List linux-media@vger.kernel.org em28xx #0: Board detected as Pinnacle Hybrid Pro tvp5150 2-005c: chip found @ 0xb8 (em28xx #0) tuner 2-0061: chip found @ 0xc2 (em28xx #0) xc2028 2-0061: creating new instance xc2028 2-0061: type set to XCeive xc2028/xc3028 tuner usb 1-3.1: firmware: requesting xc3028-v27.fw xc2028 2-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 xc2028 2-0061: Loading firmware for type=BASE (1), id . xc2028 2-0061: Loading firmware for type=(0), id b700. SCODE (2000), id b700: xc2028 2-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. em28xx #0: Config register raw data: 0x58 em28xx #0: AC97 vendor ID = 0x em28xx #0: AC97 features = 0x6a90 em28xx #0: Empia 202 AC97 audio processor detected tvp5150 2-005c: tvp5150am1 detected. em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 video device registered as /dev/video0 em28xx #0: V4L2 VBI device registered as /dev/vbi0 em28xx audio device (eb1a:2881): interface 1, class 1 em28xx audio device (eb1a:2881): interface 2, class 1 usbcore: registered new interface driver em28xx em28xx driver loaded usbcore: registered new interface driver snd-usb-audio xc2028 2-0061: attaching existing instance xc2028 2-0061: type set to XCeive xc2028/xc3028 tuner em28xx #0/2: xc3028 attached DVB: registering new adapter (em28xx #0) DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... Successfully loaded em28xx-dvb Em28xx: Initialized (Em28xx dvb Extension) extension tvp5150 2-005c: tvp5150am1 detected. xc2028 2-0061: Loading firmware for type=BASE F8MHZ (3), id . xc2028 2-0061: Loading firmware for type=D2633 DTV8 (210), id . xc2028 2-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id . xc2028 2-0061: Loading firmware for type=BASE F8MHZ (3), id . xc2028 2-0061: Loading firmware for type=D2633 DTV8 (210), id . xc2028 2-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id . xc2028 2-0061: Loading firmware for type=BASE F8MHZ (3), id . xc2028 2-0061: Loading firmware for type=D2633 DTV78 (110), id . xc2028 2-0061: Loading SCODE for type=DTV6 QAM
Re: em28xx mode switching
Am Montag, den 12.10.2009, 18:12 -0400 schrieb Devin Heitmueller: I was debugging an issue on a user's hybrid board, when I realized that we are switching the em28xx mode whenever we start and stop dvb streaming. We already have the ts_bus_ctrl callback implemented which puts the device into digital mode and puts it back into suspend whenever the frontend is opened/closed. This call seems redundant, and in fact can cause problems if the dvb_gpio definition strobes the reset pin, as it can put the driver out of sync with the demodulator's state (in fact this is what I ran into with the zl10353 - the reset pin got strobed when the streaming was started but the demod driver's init() routine was not being run because it already ran when the frontend was originally opened). The only case I can think of where toggling the device mode when starting/stopping dvb streaming might be useful is if we wanted to support being able to do an analog tune while the dvb frontend was still open but not streaming. However, this seems like this could expose all sorts of bugs, and I think the locking would have to be significantly reworked if this were a design goal. Thoughts anybody? Devin Hi, on dvb were some telling us previously, by far not all, but the loudest, all the hybrid stuff will soon vanish and it is not even worth to look closer into it. This is years back, and the problem is still there. But, these days you can discuss it more relaxed and despite of all, we have lots of improvements now. See Mike's latest compromising about who has the gpio pins. Even only thinking about such in public was a crime previously ... (and heavily punished ;) Cheers, Hermann -- 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: Dazzle TV Hybrid USB and em28xx
On Mon, Oct 12, 2009 at 7:22 PM, Giuseppe Borzi gbo...@gmail.com wrote:
Yeah, that happens with Ubuntu Karmic. The v4l-dvb firedtv driver
depends on headers that are private to ieee1394 and not in their
kernel headers package.
To workaround the issue, open v4l/.config and set the firedtv driver
from =m to =n
Devin
Thanks Devin,
following your instruction for firedtv I've compiled
v4l-dvb-5578cc977a13 but the results aren't so good. After doing an
make rminstall , compiling and make install I plugged the USB
stick, the various devices were created (including /dev/dvb) and here
is the dmesg output (now it's identified as card=1)
then I started checking if it works. The command vlc channels.conf
works, i.e. it plays the first channel in the list, but is unable to
switch channel. me-tv doesn't start, but I think this is related to the
recent gnome upgrade. w_scan doesn't find any channel.
Open v4l/em28xx-cards.c and comment out line 181 so it looks like:
//{EM2880_R04_GPO,0x04, 0xff, 100},/*
zl10353 reset */
This is an issue I have been actively debugging for two other users.
Analog TV only shows video, no audio. Tried this both with sox and vlc.
When you say that I have to choose the right TV standard (PAL for my
region) do you mean I have to select this in the TV app I'm using
(tvtime, vlc, xawtv) or as a module option? I've not seen any em28xx
option for TV standard, so I suppose it's in the app.
Correct - the em28xx module does not have module parameters for the
standard - you have to select it in the application.
Finally, I've noticed that the device is much less hot than it happened
with out of kernel modules and the card=11 workaround.
Is your latest post em28xx mode switching related to my device?
Yes, it is one device effected by that discussion.
Devin
--
Devin J. Heitmueller - 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
Re: [linux-dvb] Linuxtv wiki needs email notification/more email-ready users
Hi Henrik, CityK wrote: H. Langos wrote: ...I'd like to keep an eye on changes. Not because of fear of vandalisim but because changes to the templates/date potentially have effects on a lot of pages. There are some people who day by day put a lot of effort and work into the wiki and I'd like to thank them all for their continuing effort. I myself have only occasionaly time to update information there and I miss a lot of changes, even to the pages I watch, because the watchlist and recent cahnges reaches only seven days back. Manually going through the pages on my watchlist (currently 57) is not what I'd call good use of resources. It would be great if it was possible to get (immediate/daily/weekly?) change notifications by email in order not to lose track of what is happening to the pages that I care about. (I bet this is standard functionality of mediawiki or at least one of the more common extentions.) In searching for something else, I came across this recent thread on the mediawiki m/l: http://lists.wikimedia.org/pipermail/mediawiki-l/2009-October/032214.html There are a few suggestions in it (I just skimmed through). Perhaps one of them would be good to implement. -- 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
