Re: V4L hg tree fails to compile against latest stable kernel 2.6.35
Hello Derek, On Tue, Aug 3, 2010 at 10:37 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 03-08-2010 03:44, VDR User escreveu: On Mon, Aug 2, 2010 at 11:36 PM, VDR User user@gmail.com wrote: Any idea when this will be fixed? It is up to Douglas to do the backport, but you can just use the latest git tree, where those patches are applied already at 2.6.35, at the branch staging/v2.6.36. I am already working to give a full update to hg tree. Sorry this problem. Cheers Douglas -- 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/PATCH v3 06/10] media: Entities, pads and links enumeration
Hi Marko, On Wednesday 04 August 2010 21:28:22 Marko Ristola wrote: Hi Hans and Laurent. I hope my thoughts help you further. Thank you for sharing them. 03.08.2010 12:22, Laurent Pinchart wrote: On Monday 02 August 2010 23:01:55 Hans Verkuil wrote: On Monday 02 August 2010 16:35:54 Laurent Pinchart wrote: On Sunday 01 August 2010 13:58:20 Hans Verkuil wrote: On Thursday 29 July 2010 18:06:39 Laurent Pinchart wrote: [snip] [snip] It's a possibility, but it's always a bit of a hassle in an application to work with group IDs. I wonder if there is a more elegant method. The problem is a bit broader than just showing relationships between video nodes and ALSA devices. We also need to show relationships between lens/flash controllers and sensors for instance. Group IDs sound easy, but I'm open to suggestions. Low level example DVB I2C bus is easy: get all I2C devices from an entity (DVB demuxer). Some external chip (entity, the tuner) might be behind some I2C bridge device. With I2C you need to know the characteristics, how you talk with the destination device via the bus (extra sleeps, clock speed, quiesce the whole bus for 50ms after talking to the slave device). I'd like that each device would describe how it should be talked to via the bus. There's probably some confusion here. The media controller aims at giving userspace the ability to discover the internal device topology. This includes various information about the entities, such as a name, a version number, ... The I2C data you mention are low-level information required by the kernel to talk to the I2C device, but I don't think they're useful to userspace at all. That kind of information come either from platform data or from the I2C device driver and get used internally in the kernel. Do you see any need to expose such information to userspace ? On i2c_transfer you could hide opening and closing the I2C bridge, and hide the callbacks for extra sleeps so that the main driver and core framework code is free from such ugly details. By storing entity's special requirements inside of it, you could reuse the callbacks with another product variant. The callbacks are implemented by I2C device drivers that should know about the specific device requirements (either hardcoded in the driver, or provided through platform data). I'm not sure to understand the exact problem here. With I2C, an array of I2C slave devices that are reachable via I2C bus would work for controlling the device rather nicely. Higher abstraction level So detailed descriptions and bus knowledge is needed for controlling each entity and pad. It's needed to control them inside the kernel, but I don't think it's needed in userspace. That hierarchy is a bit different than optimal hierarchy of how the streams can flow into, within and out from the entity (the driver). Buses are the gateways for the data stream flows, shared by two or more entities/pads by links. Thus I'd suggest to separate these two hierarchies (initialization time hierarchy and stream flow capability hierarchy) at necessary points, and use buses to bind the entities/pads by links to each other. I don't get it, sorry. A single wire with just two end points can also be thought like a bus. -- 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
V4L Kconfig defaults
Hi Mauro At some point the usefullness of the VIDEO_HELPER_CHIPS_AUTO option has been questioned and a patch has even been submitted to disable this on embedded systems [1], which, somehow, doesn't seem to have been successful, even though there haven't been any objections. Or was I expected to push it via my tree? Now, since a few kernel versions there are _many_ more of default y options in drivers/media/*/Kconfig around IR / remote drivers. Can we kill them (defaults, of course, not drivers), please? Thanks Guennadi [1] http://article.gmane.org/gmane.linux.kernel.embedded/2721 --- 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: Not able to capture video frames
On Thu, 5 Aug 2010 11:34:28 +0530 Sudhindra Nayak sudhindra.na...@gmail.com wrote: As you requested, I'm including the lsusb output below: Hi Sudhindra, The USB information indicate that the webcam uses uses isochronous transfer. The driver ov534 you used as a base uses bulk transfer. So, you must either remove the 'cam-bulk..' in sd_conf() or change your base driver to ov519. In any case, don't forget to adjust the pkt_scan function... Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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:Thu Aug 5 19:00:33 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14994:a14d56c730c4 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-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/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v3 06/10] media: Entities, pads and links enumeration
05.08.2010 12:38, Laurent Pinchart wrote: Hi Marko, On Wednesday 04 August 2010 21:28:22 Marko Ristola wrote: Hi Hans and Laurent. I hope my thoughts help you further. Thank you for sharing them. Thank you for taking time to answer for me. [ snip ] There's probably some confusion here. The media controller aims at giving userspace the ability to discover the internal device topology. This includes various information about the entities, such as a name, a version number, ... The I2C data you mention are low-level information required by the kernel to talk to the I2C device, but I don't think they're useful to userspace at all. That kind of information come either from platform data or from the I2C device driver and get used internally in the kernel. Do you see any need to expose such information to userspace ? I don't see any needs to expose such information into userspace. I have some thoughts about I2C hardware problems, but that is of course off topic. I wrote them here only because I tried to draw some bigger picture how this entity, pads and links thing relates to the whole driver. [ snip ] With I2C, an array of I2C slave devices that are reachable via I2C bus would work for controlling the device rather nicely. Higher abstraction level So detailed descriptions and bus knowledge is needed for controlling each entity and pad. It's needed to control them inside the kernel, but I don't think it's needed in userspace. I agree: The detailed information needs to be internal to the driver, and userspace needs only the information that is needed for being able to decide how to configure the streams over many drivers, and how each driver must be asked to do the configuration for it, without driver needing knowledge about other related drivers. Maybe a pad could have a list of pads that it can connect to. Each destination pad reference could have a link as a property if the link is mandatory for binding the pads together. A list of open links without pads might be usable too, enabling binding different drivers to pass data to each other with pad-link-pad binding. Driver could be a property of a pad for being able to do binding over drivers. You have of course a better picture and understanding about these, and you will need to come up with the best solution together on your own. Maybe I just need to do something else and go and buy another motherboard from Helsinki Ruoholahti to replace my overheated one, walking by some Nokia Research Center buildings. Best regards from the summerish Finland. Marko Ristola -- 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/5] mx2_camera: change to register and probe
On Tue, 3 Aug 2010, Michael Grzeschik wrote:
change this driver back to register and probe, since some platforms
first have to initialize an already registered power regulator to switch
on the camera.
I shall be preparing a pull-request for 2.6.36-rc1 #2, but since we
haven't finished discussing this and when this is ready, this will be a
fix - without this your platform doesn't work, right? So, we can push it
after rc1.
Thanks
Guennadi
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
drivers/media/video/mx2_camera.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index 98c93fa..c77a673 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -1491,13 +1491,15 @@ static struct platform_driver mx2_camera_driver = {
.driver = {
.name = MX2_CAM_DRV_NAME,
},
+
+ .probe = mx2_camera_probe,
.remove = __devexit_p(mx2_camera_remove),
};
static int __init mx2_camera_init(void)
{
- return platform_driver_probe(mx2_camera_driver, mx2_camera_probe);
+ return platform_driver_register(mx2_camera_driver);
}
static void __exit mx2_camera_exit(void)
--
1.7.1
---
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
[PATCH 19/42] drivers/media/video: Adjust confusing if indentation
From: Julia Lawall ju...@diku.dk
In cx23885/cx23885-video.c, cx88/cx88-video.c, davinci/vpif_capture.c, and
davinci/vpif_display.c, group the aligned code into a single if branch.
In saa7134/saa7134-video.c, outdent the code following the if.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@r disable braces4@
position p1,p2;
statement S1,S2;
@@
(
if (...) { ... }
|
if (...) s...@p1 s...@p2
)
@script:python@
p1 r.p1;
p2 r.p2;
@@
if (p1[0].column == p2[0].column):
cocci.print_main(branch,p1)
cocci.print_secs(after,p2)
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
The patch changes the semantics for the first four files, and might not be
what is intended.
drivers/media/video/cx23885/cx23885-video.c |3 ++-
drivers/media/video/cx88/cx88-video.c |3 ++-
drivers/media/video/davinci/vpif_capture.c |3 ++-
drivers/media/video/davinci/vpif_display.c |3 ++-
drivers/media/video/saa7134/saa7134-video.c |2 +-
5 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index 4e44dcd..0f48967 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -1165,9 +1165,10 @@ static int cx23885_enum_input(struct cx23885_dev *dev,
struct v4l2_input *i)
i-type = V4L2_INPUT_TYPE_CAMERA;
strcpy(i-name, iname[INPUT(n)-type]);
if ((CX23885_VMUX_TELEVISION == INPUT(n)-type) ||
- (CX23885_VMUX_CABLE == INPUT(n)-type))
+ (CX23885_VMUX_CABLE == INPUT(n)-type)) {
i-type = V4L2_INPUT_TYPE_TUNER;
i-std = CX23885_NORMS;
+ }
return 0;
}
diff --git a/drivers/media/video/cx88/cx88-video.c
b/drivers/media/video/cx88/cx88-video.c
index 0fab65c..4fba913 100644
--- a/drivers/media/video/cx88/cx88-video.c
+++ b/drivers/media/video/cx88/cx88-video.c
@@ -1267,9 +1267,10 @@ int cx88_enum_input (struct cx88_core *core,struct
v4l2_input *i)
i-type = V4L2_INPUT_TYPE_CAMERA;
strcpy(i-name,iname[INPUT(n).type]);
if ((CX88_VMUX_TELEVISION == INPUT(n).type) ||
- (CX88_VMUX_CABLE == INPUT(n).type))
+ (CX88_VMUX_CABLE == INPUT(n).type)) {
i-type = V4L2_INPUT_TYPE_TUNER;
i-std = CX88_NORMS;
+ }
return 0;
}
EXPORT_SYMBOL(cx88_enum_input);
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index a7f48b5..2b42473 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -1030,9 +1030,10 @@ static int vpif_qbuf(struct file *file, void *priv,
struct v4l2_buffer *buf)
goto qbuf_exit;
if ((VIDEOBUF_NEEDS_INIT != buf1-state)
-(buf1-baddr != tbuf.m.userptr))
+(buf1-baddr != tbuf.m.userptr)) {
vpif_buffer_release(common-buffer_queue, buf1);
buf1-baddr = tbuf.m.userptr;
+ }
break;
default:
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index da07607..4770fda 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -935,9 +935,10 @@ static int vpif_qbuf(struct file *file, void *priv, struct
v4l2_buffer *buf)
goto qbuf_exit;
if ((VIDEOBUF_NEEDS_INIT != buf1-state)
-(buf1-baddr != tbuf.m.userptr))
+(buf1-baddr != tbuf.m.userptr)) {
vpif_buffer_release(common-buffer_queue, buf1);
buf1-baddr = tbuf.m.userptr;
+ }
break;
default:
diff --git a/drivers/media/video/saa7134/saa7134-video.c
b/drivers/media/video/saa7134/saa7134-video.c
index 45f0ac8..645224c 100644
--- a/drivers/media/video/saa7134/saa7134-video.c
+++ b/drivers/media/video/saa7134/saa7134-video.c
@@ -1825,7 +1825,7 @@ static int saa7134_querycap(struct file *file, void
*priv,
if ((tuner_type == TUNER_ABSENT) || (tuner_type == UNSET))
cap-capabilities = ~V4L2_CAP_TUNER;
- return 0;
+ return 0;
}
int saa7134_s_std_internal(struct saa7134_dev *dev, struct saa7134_fh *fh,
v4l2_std_id *id)
--
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/3 v2] media: Add a cached version of the contiguous video buffers
On 08/04/2010 12:34 PM, Pawel Osciak wrote: Richard Röjforsrichard.rojf...@pelagicore.com wrote: On 08/04/2010 11:50 AM, Pawel Osciak wrote: How do you propose to allocate the buffers? They need to be contiguous and using uncached memory gave really bad performance. 829440 bytes is a quite a lot and one can't reliably depend on kmalloc to be able to allocate such big chunks of contiguous memory. Were you testing this on a freshly rebooted system? The systems have been running for a while, but not days. I don't see why would dma_alloc_coherent work better than kmalloc? In principle it wouldn't. It's just it's much less intensively used and allocates from a special area. Not really a bullet-proof solution either though, I agree. So how do we move forward? I would like to see this kind of patch go in, it obviously makes our video driver useful. I could change and verify the patch using dma_alloc_noncoherent instead of kmalloc. It would have the same limitations as todays' uncached buffers. --Richard -- 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 42/42] drivers/media/video/bt8xx: Adjust confusing if indentation
From: Julia Lawall ju...@diku.dk
Indent the branch of an if.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@r disable braces4@
position p1,p2;
statement S1,S2;
@@
(
if (...) { ... }
|
if (...) s...@p1 s...@p2
)
@script:python@
p1 r.p1;
p2 r.p2;
@@
if (p1[0].column == p2[0].column):
cocci.print_main(branch,p1)
cocci.print_secs(after,p2)
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
drivers/media/video/bt8xx/bttv-i2c.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/video/bt8xx/bttv-i2c.c
b/drivers/media/video/bt8xx/bttv-i2c.c
index 685d659..695765c 100644
--- a/drivers/media/video/bt8xx/bttv-i2c.c
+++ b/drivers/media/video/bt8xx/bttv-i2c.c
@@ -123,7 +123,7 @@ bttv_i2c_wait_done(struct bttv *btv)
if (wait_event_interruptible_timeout(btv-i2c_queue,
btv-i2c_done, msecs_to_jiffies(85)) == -ERESTARTSYS)
- rc = -EIO;
+ rc = -EIO;
if (btv-i2c_done BT848_INT_RACK)
rc = 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 5/5] mx2_camera: add informative camera clock frequency printout
On Tue, 3 Aug 2010, Michael Grzeschik wrote: ported mx27_camera to 2.6.33.2 Sorry, do not understand what this description has to do with the contents - adding a printk to a driver? I don't think this is something critical enough to be handled urgently now for 2.6.36, right? Thanks Guennadi Signed-off-by: Teresa Gamez t.ga...@phytec.de Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de --- drivers/media/video/mx2_camera.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c index 7f27492..fb1b1cb 100644 --- a/drivers/media/video/mx2_camera.c +++ b/drivers/media/video/mx2_camera.c @@ -1360,6 +1360,9 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev) goto exit_dma_free; } + dev_info(pdev-dev, Camera clock frequency: %ld\n, + clk_get_rate(pcdev-clk_csi)); + INIT_LIST_HEAD(pcdev-capture); INIT_LIST_HEAD(pcdev-active_bufs); spin_lock_init(pcdev-lock); -- 1.7.1 --- 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: PULL of cx23885-mpx series
Mauro, Stoth and I chatted and I'm OK with his cx23885-mpx series going in as is, since there is a plan in place to move cx23885/7/8 AV core handling out of cx25840. So, Reviewed-by: Andy Walls awa...@md.metrocast.net Acked-by: Andy Walls awa...@md.metrocast.net Sent via my Gmail account from my phone since the electrical storm here knocked out service from the cable ISP. Regards, Andy
Re: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300
On Wed, Aug 4, 2010 at 1:48 AM, lawrence rust lawre...@softsystem.co.uk wrote: [snip} Still to try the patch - will let you know. Unfortunately our HVR-1300 is in the process of being swapped out since the supplier wanted to try swapping boards first :-( Let us know how you get on. -- Lawrence Rust Well still no luck this end. Have done the following: 1) Swapped boards - no change 2) Applied the patch - no change (we were detecting the WM8775 OK anyway and the other changes were either non HVR-1300 or we had already tried them so probably not too surprising 3) Made sure I2SINPUT is enabled - no change So still have the following strange observations: 1) Repeatedly swapping between inputs eventually gives us audio 2) Once fixed it survives a warm reboot but not power cycle 3) Putting a scope on the I2S line out of the CX2388x shows noise when TV input selected and no noise for Composite (unless inject a tone). However MPEG-2 audio always contains hiss or hiss plus injected tone. So looks like two issues to me. I'll try and modify the driver so that when switching inputs we only config the WM8775 or the CX2388x or the MPEG encoder and see if I can determine which item has the configuration issue. Cheers Shane -- 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: PULL of cx23885-mpx series
Em 05-08-2010 19:32, Andy Walls escreveu: Mauro, Stoth and I chatted and I'm OK with his cx23885-mpx series going in as is, since there is a plan in place to move cx23885/7/8 AV core handling out of cx25840. So, Reviewed-by: Andy Walls awa...@md.metrocast.net Acked-by: Andy Walls awa...@md.metrocast.net I'm OK with this also, but the compilation breakage due to the removal of two videobuf calls need to be fixed, otherwise, I can't submit it upstream. Cheers, Mauro -- 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: Help wanted on removing dibusb_rc_keys from dvb_usb_rtl2831u module
OK. I found the solution by looking at the sources at: http://lxr.free-electrons.com/source/drivers/media/dvb/dvb-usb/dibusb-common.c What needed was a rename over all sources affected: struct dvb_usb_rc_key dibusb_rc_keys[] = struct dvb_usb_rc_key ir_codes_dibusb_table[] I also fixed missing renaming in dib_usb driver. I have updated http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2/ Jan Hoogenraad wrote: This is probably caused by the current dvb_usb_rtl2831u module using dibusb_rc_keys, which disapperead due to IR changes. Syncing the rtl2831-r2/ tree with the main archive cause compilation problems in v4l/dibusb-mc.c and I suppose rtd2830u.c will not compile anymore either. Can somebody with knowledge on IR help me with updating the code ? $ grep dibusb_rc_keys */*.[ch] v4l/dibusb-mc.c:.rc_key_map = dibusb_rc_keys, v4l/rtd2830u.c:d-props.rc_key_map = dibusb_rc_keys; v4l/rtd2830u.c:.rc_key_map = dibusb_rc_keys, v4l/rtd2830u.c:.rc_key_map = dibusb_rc_keys, I addition, I'd like to get help on how to move the IR code into http://linuxtv.org/hg/~anttip/rtl2831u That (in all other respects much better) version has NO IR support at all at. Adding IR to that driver, and getting it into the kernel would solve all problems. Thomas Holzeisen wrote: Hi, i am using a DVB-T USB-Stick with Realtek RTL2831 chip (14aa:0160) on Debian Lenny having the lastest Backport kernel 2.6.32. $ uname -a Linux xbmc 2.6.32-bpo.5-686 #1 SMP Fri Jun 11 22:20:29 UTC 2010 i686 GNU/Linux For v4l I took the drivers from here: http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2/ The checked out source compile and installs fine. I compiled them starting with make distclean. But when plugging the DVB-Stick this happens: [ 229.524028] usb 4-2: new high speed USB device using ehci_hcd and address 3 [ 229.658591] usb 4-2: New USB device found, idVendor=14aa, idProduct=0160 [ 229.661204] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 229.663841] usb 4-2: Product: DTV Receiver [ 229.666308] usb 4-2: Manufacturer: DTV Receiver [ 229.668826] usb 4-2: SerialNumber: 00067936 [ 229.671609] usb 4-2: configuration #1 chosen from 1 choice [ 230.266960] dvb-usb: found a 'Freecom USB 2.0 DVB-T Device' in warm state. [ 230.270314] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 230.273641] DVB: registering new adapter (Freecom USB 2.0 DVB-T Device) [ 230.277461] DVB: registering adapter 0 frontend 0 (Realtek RTL2831 DVB-T)... [ 230.282081] BUG: unable to handle kernel paging request at 02b65c40 [ 230.285794] IP: [f7c623ba] dvb_usb_remote_init+0x12e/0x209 [dvb_usb] [ 230.291463] *pde = [ 230.293969] Oops: 0002 [#1] SMP [ 230.293969] last sysfs file: /sys/devices/pci:00/:00:06.1/usb4/4-2/bmAttributes [ 230.293969] Modules linked in: dvb_usb_rtl2831u(+) dvb_usb_dibusb_common dvb_usb dib3000mc dibx000_common dvb_ttpci dvb_core saa7146_vv videodev v4l1_compat saa7146 videobuf_dma_sg videobuf_core ttpci_eeprom iscsi_trgt crc32c loop snd_hda_codec_nvhdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq snd_timer snd_seq_device snd tpm_tis soundcore tpm shpchp psmouse wmi serio_raw tpm_bios snd_page_alloc pcspkr pci_hotplug processor evdev button ir_core nvidia(P) lirc_imon i2c_nforce2 i2c_core lirc_dev ext3 jbd mbcache raid1 md_mod usbhid hid sg sr_mod cdrom sd_mod crc_t10dif usb_storage ahci ata_generic libata ehci_hcd ohci_hcd scsi_mod usbcore nls_base forcedeth thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 230.293969] [ 230.293969] Pid: 3279, comm: modprobe Tainted: P (2.6.32-bpo.5-686 #1) Point of View [ 230.293969] EIP: 0060:[f7c623ba] EFLAGS: 00010246 CPU: 0 [ 230.293969] EIP is at dvb_usb_remote_init+0x12e/0x209 [dvb_usb] [ 230.293969] EAX: 69656148 EBX: f589b000 ECX: c14c18e4 EDX: f589b018 [ 230.293969] ESI: f5904000 EDI: 03b8 EBP: 0077 ESP: f5851e88 [ 230.293969] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 230.293969] Process modprobe (pid: 3279, ti=f585 task=f5cd4400 task.ti=f585) [ 230.293969] Stack: [ 230.293969] f589b018 f5904000 f5904000 f5904864 0001 f7c61945 f5904418 f80bb8d0 [ 230.293969] 0 f5912000 f5b8f800 f80bad88 f80bad88 f5912000 [ 230.293969] 0 f80bb894 f80ba970 f80b886d f80ba960 f5912000 f80c8c98 f591201c [ 230.293969] Call Trace: [ 230.293969] [f7c61945] ? dvb_usb_device_init+0x515/0x51c [dvb_usb] [ 230.293969] [f80b886d] ? rtd2831u_usb_probe+0x19/0x48 [dvb_usb_rtl2831u] [ 230.293969] [f80c8c98] ? usb_probe_interface+0xe7/0x130 [usbcore] [ 230.293969] [c11b2c22] ? driver_probe_device+0x8a/0x11e [ 230.293969] [c11b2cf6] ? __driver_attach+0x40/0x5b [ 230.293969] [c11b2667] ? bus_for_each_dev+0x37/0x5f [ 230.293969] [c11b2af5] ? driver_attach+0x11/0x13 [ 230.293969] [c11b2cb6] ? __driver_attach+0x0/0x5b [ 230.293969]
Re: dvb_usb_rtl2831u module cause oops on kernel 2.6.32 when loading
Can you test the current version ? Thomas Holzeisen wrote: Hi, i am using a DVB-T USB-Stick with Realtek RTL2831 chip (14aa:0160) on Debian Lenny having the lastest Backport kernel 2.6.32. $ uname -a Linux xbmc 2.6.32-bpo.5-686 #1 SMP Fri Jun 11 22:20:29 UTC 2010 i686 GNU/Linux For v4l I took the drivers from here: http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2/ The checked out source compile and installs fine. I compiled them starting with make distclean. But when plugging the DVB-Stick this happens: [ 229.524028] usb 4-2: new high speed USB device using ehci_hcd and address 3 [ 229.658591] usb 4-2: New USB device found, idVendor=14aa, idProduct=0160 [ 229.661204] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 229.663841] usb 4-2: Product: DTV Receiver [ 229.666308] usb 4-2: Manufacturer: DTV Receiver [ 229.668826] usb 4-2: SerialNumber: 00067936 [ 229.671609] usb 4-2: configuration #1 chosen from 1 choice [ 230.266960] dvb-usb: found a 'Freecom USB 2.0 DVB-T Device' in warm state. [ 230.270314] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 230.273641] DVB: registering new adapter (Freecom USB 2.0 DVB-T Device) [ 230.277461] DVB: registering adapter 0 frontend 0 (Realtek RTL2831 DVB-T)... [ 230.282081] BUG: unable to handle kernel paging request at 02b65c40 [ 230.285794] IP: [f7c623ba] dvb_usb_remote_init+0x12e/0x209 [dvb_usb] [ 230.291463] *pde = [ 230.293969] Oops: 0002 [#1] SMP [ 230.293969] last sysfs file: /sys/devices/pci:00/:00:06.1/usb4/4-2/bmAttributes [ 230.293969] Modules linked in: dvb_usb_rtl2831u(+) dvb_usb_dibusb_common dvb_usb dib3000mc dibx000_common dvb_ttpci dvb_core saa7146_vv videodev v4l1_compat saa7146 videobuf_dma_sg videobuf_core ttpci_eeprom iscsi_trgt crc32c loop snd_hda_codec_nvhdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq snd_timer snd_seq_device snd tpm_tis soundcore tpm shpchp psmouse wmi serio_raw tpm_bios snd_page_alloc pcspkr pci_hotplug processor evdev button ir_core nvidia(P) lirc_imon i2c_nforce2 i2c_core lirc_dev ext3 jbd mbcache raid1 md_mod usbhid hid sg sr_mod cdrom sd_mod crc_t10dif usb_storage ahci ata_generic libata ehci_hcd ohci_hcd scsi_mod usbcore nls_base forcedeth thermal fan thermal_sys [last unloaded: scsi_wait_scan] [ 230.293969] [ 230.293969] Pid: 3279, comm: modprobe Tainted: P (2.6.32-bpo.5-686 #1) Point of View [ 230.293969] EIP: 0060:[f7c623ba] EFLAGS: 00010246 CPU: 0 [ 230.293969] EIP is at dvb_usb_remote_init+0x12e/0x209 [dvb_usb] [ 230.293969] EAX: 69656148 EBX: f589b000 ECX: c14c18e4 EDX: f589b018 [ 230.293969] ESI: f5904000 EDI: 03b8 EBP: 0077 ESP: f5851e88 [ 230.293969] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 230.293969] Process modprobe (pid: 3279, ti=f585 task=f5cd4400 task.ti=f585) [ 230.293969] Stack: [ 230.293969] f589b018 f5904000 f5904000 f5904864 0001 f7c61945 f5904418 f80bb8d0 [ 230.293969] 0 f5912000 f5b8f800 f80bad88 f80bad88 f5912000 [ 230.293969] 0 f80bb894 f80ba970 f80b886d f80ba960 f5912000 f80c8c98 f591201c [ 230.293969] Call Trace: [ 230.293969] [f7c61945] ? dvb_usb_device_init+0x515/0x51c [dvb_usb] [ 230.293969] [f80b886d] ? rtd2831u_usb_probe+0x19/0x48 [dvb_usb_rtl2831u] [ 230.293969] [f80c8c98] ? usb_probe_interface+0xe7/0x130 [usbcore] [ 230.293969] [c11b2c22] ? driver_probe_device+0x8a/0x11e [ 230.293969] [c11b2cf6] ? __driver_attach+0x40/0x5b [ 230.293969] [c11b2667] ? bus_for_each_dev+0x37/0x5f [ 230.293969] [c11b2af5] ? driver_attach+0x11/0x13 [ 230.293969] [c11b2cb6] ? __driver_attach+0x0/0x5b [ 230.293969] [c11b2135] ? bus_add_driver+0x99/0x1c2 [ 230.293969] [c11b2f2b] ? driver_register+0x87/0xe0 [ 230.293969] [f80c8aa6] ? usb_register_driver+0x5d/0xb4 [usbcore] [ 230.293969] [f80f6000] ? rtd2831u_usb_module_init+0x0/0x2c [dvb_usb_rtl2831u] [ 230.293969] [f80f6015] ? rtd2831u_usb_module_init+0x15/0x2c [dvb_usb_rtl2831u] [ 230.293969] [c100113e] ? do_one_initcall+0x55/0x155 [ 230.293969] [c1057dd7] ? sys_init_module+0xa7/0x1d7 [ 230.293969] [c10030fb] ? sysenter_do_call+0x12/0x28 [ 230.293969] Code: 3e c6 f7 20 74 18 8b 86 a0 00 00 00 55 ff 74 38 04 68 59 38 c6 f7 e8 1b a1 60 c9 83 c4 0c 8b 86 a0 00 00 00 8b 14 24 8b 44 38 04 f0 0f ab 02 45 83 c7 08 3b ae a4 00 00 00 7c c2 83 be ac 00 00 [ 230.293969] EIP: [f7c623ba] dvb_usb_remote_init+0x12e/0x209 [dvb_usb] SS:ESP 0068:f5851e88 [ 230.293969] CR2: 02b65c40 [ 230.663846] ---[ end trace e2ebfa1976bffdae ]--- Mostly interesting, the modules are still getting loaded: $ lsmod | grep dvb dvb_usb_rtl2831u 89189 15 dvb_usb_dibusb_common 4578 1 dvb_usb_rtl2831u dvb_usb13320 2 dvb_usb_rtl2831u,dvb_usb_dibusb_common dib3000mc 8544 1 dvb_usb_dibusb_common dvb_ttpci 70046 0 dvb_core
