RE: omap2 camera
From: Aguirre, Sergio [saagui...@ti.com] Sent: Tuesday, March 23, 2010 11:54 AM To: Sakari Ailus; Viral Mehta Cc: linux-media@vger.kernel.org Subject: RE: omap2 camera > > From: Sakari Ailus [sakari.ai...@maxwell.research.nokia.com] > Sent: Monday, March 22, 2010 11:50 PM > To: Viral Mehta > Cc: Aguirre, Sergio; linux-media@vger.kernel.org > Subject: Re: omap2 camera > > Viral Mehta wrote: > > Hi Sakari, > > Hi Viral, > > > > > From: Sakari Ailus [sakari.ai...@maxwell.research.nokia.com] > > Sent: Monday, March 22, 2010 10:51 PM > > To: Aguirre, Sergio > > Cc: Viral Mehta; linux-media@vger.kernel.org > > Subject: Re: omap2 camera > > > > Aguirre, Sergio wrote: > >> Hi Viral, > >> > >>> -Original Message- > >>> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > >>> ow...@vger.kernel.org] On Behalf Of Viral Mehta > >>> Sent: Monday, March 22, 2010 5:20 AM > >>> To: linux-media@vger.kernel.org > >>> Subject: omap2 camera > >>> > >>> Hi list, > >>> > >>> I am using OMAP2430 board and I wanted to test camera module on that > >>> board. > >>> I am using latest 2.6.33 kernel. However, it looks like camera module is > >>> not supported with latest kernel. > >>> > >>> Anyone is having any idea? Also, do we require to have ex3691 sensor > >>> driver in mainline kernel in order to get omap24xxcam working ? > >>> > >>> These are the steps I followed, > >>> 1. make omap2430_sdp_defconfig > >>> 2. Enable omap2 camera option which is under drivers/media/video > >>> 3. make uImage > >>> > >>> And with this uImage, camera is not working. I would appreciate any help. > >> > >> I'm adding Sakari Ailus to the CC list, which is the owner of the driver. > > > >> Thanks, Sergio! > > > > Thanks for your response. Thanks Sergio. > > > >> I've only aware of the tcm825x sensor driver that works with the OMAP > >> 2420 camera controller (omap24xxcam) driver. > > > > Does this also mean that omap24xxcam.ko will *only* work with OMAP2420? > > Or the same driver can be used for OMAP2430 board as well ? As name > > suggests, omap24xxcam > > I'm not fully aware of the differences in the camera controllers in 2420 > and 2430 --- never had a 2430. If they are the same then the driver > should work as it is. Sergio, do you know whether there are differences > between the two? > Well, I personally haven't worked with OMAP2 family, but by looking at the > differences in both chip descriptions: > OMAP 2430 / 2431: > http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12609&contentId=4672 >OMAP 2420: >http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=11990&contentId=4671 > Camera wise, I can see that the 243x chips have interface for 2 cameras, > meanwhile the 2420 only has one. Comment on top of the file suggests that Author for this driver is Sakari only. I would like to change file name, kconfig, Makefile in case if it does not support omap2430. Any way that I can get HW manual for omap2430 and/or 2420 ? > Generally speaking, the xx3x variants are usually more resourceful than xx2x > sub-families. Regards, Sergio > > >> So likely you'd need the driver for the sensor you have on that board. > > Okie, I am trying to get that done. I took linux-2.6.14-V5 kernel from > > linux.omap.com and > > that supports camera on OMAP2430 and it has functional driver for ex3691 > > sensor. > > I am trying to know if I can forward port that. > > That one very likely isn't using even the v4l2-int-device. But as soon > as you do, it is very easy to convert it to v4l2_subdev. The interface > is different but the ops are almost the same. > > >> The omap24xxcam and tcm825x drivers should be moved to use v4l2_subdev > >> but I'm not quite sure what will be the schedule of that. Then we could > >> get rid of the v4l2-int-device interface that those drives still use. > > > > They are still using v4l2-int-device as of 2.6.33. > > That's true. AFAIK no work has been done to get rid of this yet. > > Regards, > > -- > Sakari Ailus > sakari.ai...@maxwell.research.nokia.com > __ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. __ -- 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] http://kernellabs.com/hg/~dheitmueller/ngene2-bullshit
Ok, here's take two of the PULL request issued yesterday. It's basically the same as yesterday, but except instead of moving the unused code to separate files where it might actually be useful to someone else in the future, I delete it entirely because Mauro's scripts mangle the patches when pulling them into git (therefore the resulting git patches appear to have zero actual content). http://kernellabs.com/hg/~dheitmueller/ngene2-bullshit When a developer has to waste several hours rebasing four development trees and reworking a large patch series just to address a couple of patches that "don't quite look right", it's amazing we get anything done. People wonder why their tuners don't get support added sooner? THIS IS WHY. What a colossal waste of my time when I could have been actually working on drivers instead... 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: omap2 camera
> > From: Sakari Ailus [sakari.ai...@maxwell.research.nokia.com] > Sent: Monday, March 22, 2010 11:50 PM > To: Viral Mehta > Cc: Aguirre, Sergio; linux-media@vger.kernel.org > Subject: Re: omap2 camera > > Viral Mehta wrote: > > Hi Sakari, > > Hi Viral, > > > > > From: Sakari Ailus [sakari.ai...@maxwell.research.nokia.com] > > Sent: Monday, March 22, 2010 10:51 PM > > To: Aguirre, Sergio > > Cc: Viral Mehta; linux-media@vger.kernel.org > > Subject: Re: omap2 camera > > > > Aguirre, Sergio wrote: > >> Hi Viral, > >> > >>> -Original Message- > >>> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > >>> ow...@vger.kernel.org] On Behalf Of Viral Mehta > >>> Sent: Monday, March 22, 2010 5:20 AM > >>> To: linux-media@vger.kernel.org > >>> Subject: omap2 camera > >>> > >>> Hi list, > >>> > >>> I am using OMAP2430 board and I wanted to test camera module on that > >>> board. > >>> I am using latest 2.6.33 kernel. However, it looks like camera module is > >>> not supported with latest kernel. > >>> > >>> Anyone is having any idea? Also, do we require to have ex3691 sensor > >>> driver in mainline kernel in order to get omap24xxcam working ? > >>> > >>> These are the steps I followed, > >>> 1. make omap2430_sdp_defconfig > >>> 2. Enable omap2 camera option which is under drivers/media/video > >>> 3. make uImage > >>> > >>> And with this uImage, camera is not working. I would appreciate any help. > >> > >> I'm adding Sakari Ailus to the CC list, which is the owner of the driver. > > > >> Thanks, Sergio! > > > > Thanks for your response. Thanks Sergio. > > > >> I've only aware of the tcm825x sensor driver that works with the OMAP > >> 2420 camera controller (omap24xxcam) driver. > > > > Does this also mean that omap24xxcam.ko will *only* work with OMAP2420? > > Or the same driver can be used for OMAP2430 board as well ? As name > > suggests, omap24xxcam > > I'm not fully aware of the differences in the camera controllers in 2420 > and 2430 --- never had a 2430. If they are the same then the driver > should work as it is. Sergio, do you know whether there are differences > between the two? Well, I personally haven't worked with OMAP2 family, but by looking at the differences in both chip descriptions: OMAP 2430 / 2431: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12609&contentId=4672 OMAP 2420: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=11990&contentId=4671 Camera wise, I can see that the 243x chips have interface for 2 cameras, meanwhile the 2420 only has one. Generally speaking, the xx3x variants are usually more resourceful than xx2x sub-families. Regards, Sergio > > >> So likely you'd need the driver for the sensor you have on that board. > > Okie, I am trying to get that done. I took linux-2.6.14-V5 kernel from > > linux.omap.com and > > that supports camera on OMAP2430 and it has functional driver for ex3691 > > sensor. > > I am trying to know if I can forward port that. > > That one very likely isn't using even the v4l2-int-device. But as soon > as you do, it is very easy to convert it to v4l2_subdev. The interface > is different but the ops are almost the same. > > >> The omap24xxcam and tcm825x drivers should be moved to use v4l2_subdev > >> but I'm not quite sure what will be the schedule of that. Then we could > >> get rid of the v4l2-int-device interface that those drives still use. > > > > They are still using v4l2-int-device as of 2.6.33. > > That's true. AFAIK no work has been done to get rid of this yet. > > Regards, > > -- > Sakari Ailus > sakari.ai...@maxwell.research.nokia.com > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/media/video: avoid NULL dereference
> I think we can pretty safely assume that we never get here with ov==NULL. > > Oh well, I'll leave the test there for others to ponder. OK. I didn't read far enough in this email and sent another patch, in case it's useful. julia -- 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] drivers/media/video: avoid NULL dereference
From: Julia Lawall
It seems impossible for ov to be NULL at this point.
The semantic match that finds the problem is as follows:
(http://coccinelle.lip6.fr/)
//
@r exists@
expression E, E1;
identifier f;
statement S1,S3;
iterator iter;
@@
if ((E == NULL && ...) || ...)
{
... when != false ((E == NULL && ...) || ...)
when != true ((E != NULL && ...) || ...)
when != iter(E,...) S1
when != E = E1
(
sizeof(E->f)
|
* E->f
)
... when any
return ...;
}
else S3
//
Signed-off-by: Julia Lawall
---
drivers/media/video/ov511.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/ov511.c b/drivers/media/video/ov511.c
index e0bce8d..dd1b1ac 100644
--- a/drivers/media/video/ov511.c
+++ b/drivers/media/video/ov511.c
@@ -5916,11 +5916,6 @@ ov51x_disconnect(struct usb_interface *intf)
mutex_lock(&ov->lock);
usb_set_intfdata (intf, NULL);
- if (!ov) {
- mutex_unlock(&ov->lock);
- return;
- }
-
/* Free device number */
ov511_devused &= ~(1 << ov->nr);
--
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] drivers/media/video: avoid NULL dereference
On Sun, 21 Mar 2010 22:31:06 +0100 (CET) Julia Lawall wrote:
> From: Julia Lawall
>
> If ov is NULL, it will not be possible to take the lock in the first place,
> so move the test up earlier.
>
> ...
>
> --- a/drivers/media/video/ov511.c
> +++ b/drivers/media/video/ov511.c
> @@ -5913,14 +5913,12 @@ ov51x_disconnect(struct usb_interface *intf)
>
> PDEBUG(3, "");
>
> + if (!ov)
> + return;
> +
> mutex_lock(&ov->lock);
> usb_set_intfdata (intf, NULL);
>
> - if (!ov) {
> - mutex_unlock(&ov->lock);
> - return;
> - }
> -
> /* Free device number */
> ov511_devused &= ~(1 << ov->nr);
I think we can pretty safely assume that we never get here with ov==NULL.
Oh well, I'll leave the test there for others to ponder.
--
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: omap2 camera
Viral Mehta wrote: > Hi Sakari, Hi Viral, > > From: Sakari Ailus [sakari.ai...@maxwell.research.nokia.com] > Sent: Monday, March 22, 2010 10:51 PM > To: Aguirre, Sergio > Cc: Viral Mehta; linux-media@vger.kernel.org > Subject: Re: omap2 camera > > Aguirre, Sergio wrote: >> Hi Viral, >> >>> -Original Message- >>> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- >>> ow...@vger.kernel.org] On Behalf Of Viral Mehta >>> Sent: Monday, March 22, 2010 5:20 AM >>> To: linux-media@vger.kernel.org >>> Subject: omap2 camera >>> >>> Hi list, >>> >>> I am using OMAP2430 board and I wanted to test camera module on that >>> board. >>> I am using latest 2.6.33 kernel. However, it looks like camera module is >>> not supported with latest kernel. >>> >>> Anyone is having any idea? Also, do we require to have ex3691 sensor >>> driver in mainline kernel in order to get omap24xxcam working ? >>> >>> These are the steps I followed, >>> 1. make omap2430_sdp_defconfig >>> 2. Enable omap2 camera option which is under drivers/media/video >>> 3. make uImage >>> >>> And with this uImage, camera is not working. I would appreciate any help. >> >> I'm adding Sakari Ailus to the CC list, which is the owner of the driver. > >> Thanks, Sergio! > > Thanks for your response. Thanks Sergio. > >> I've only aware of the tcm825x sensor driver that works with the OMAP >> 2420 camera controller (omap24xxcam) driver. > > Does this also mean that omap24xxcam.ko will *only* work with OMAP2420? > Or the same driver can be used for OMAP2430 board as well ? As name > suggests, omap24xxcam I'm not fully aware of the differences in the camera controllers in 2420 and 2430 --- never had a 2430. If they are the same then the driver should work as it is. Sergio, do you know whether there are differences between the two? >> So likely you'd need the driver for the sensor you have on that board. > Okie, I am trying to get that done. I took linux-2.6.14-V5 kernel from > linux.omap.com and > that supports camera on OMAP2430 and it has functional driver for ex3691 > sensor. > I am trying to know if I can forward port that. That one very likely isn't using even the v4l2-int-device. But as soon as you do, it is very easy to convert it to v4l2_subdev. The interface is different but the ops are almost the same. >> The omap24xxcam and tcm825x drivers should be moved to use v4l2_subdev >> but I'm not quite sure what will be the schedule of that. Then we could >> get rid of the v4l2-int-device interface that those drives still use. > > They are still using v4l2-int-device as of 2.6.33. That's true. AFAIK no work has been done to get rid of this yet. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: omap2 camera
Hi Sakari, From: Sakari Ailus [sakari.ai...@maxwell.research.nokia.com] Sent: Monday, March 22, 2010 10:51 PM To: Aguirre, Sergio Cc: Viral Mehta; linux-media@vger.kernel.org Subject: Re: omap2 camera Aguirre, Sergio wrote: > Hi Viral, > >> -Original Message- >> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- >> ow...@vger.kernel.org] On Behalf Of Viral Mehta >> Sent: Monday, March 22, 2010 5:20 AM >> To: linux-media@vger.kernel.org >> Subject: omap2 camera >> >> Hi list, >> >> I am using OMAP2430 board and I wanted to test camera module on that >> board. >> I am using latest 2.6.33 kernel. However, it looks like camera module is >> not supported with latest kernel. >> >> Anyone is having any idea? Also, do we require to have ex3691 sensor >> driver in mainline kernel in order to get omap24xxcam working ? >> >> These are the steps I followed, >> 1. make omap2430_sdp_defconfig >> 2. Enable omap2 camera option which is under drivers/media/video >> 3. make uImage >> >> And with this uImage, camera is not working. I would appreciate any help. > > I'm adding Sakari Ailus to the CC list, which is the owner of the driver. > Thanks, Sergio! Thanks for your response. Thanks Sergio. > I've only aware of the tcm825x sensor driver that works with the OMAP > 2420 camera controller (omap24xxcam) driver. Does this also mean that omap24xxcam.ko will *only* work with OMAP2420? Or the same driver can be used for OMAP2430 board as well ? As name suggests, omap24xxcam > So likely you'd need the driver for the sensor you have on that board. Okie, I am trying to get that done. I took linux-2.6.14-V5 kernel from linux.omap.com and that supports camera on OMAP2430 and it has functional driver for ex3691 sensor. I am trying to know if I can forward port that. > The omap24xxcam and tcm825x drivers should be moved to use v4l2_subdev > but I'm not quite sure what will be the schedule of that. Then we could > get rid of the v4l2-int-device interface that those drives still use. They are still using v4l2-int-device as of 2.6.33. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com __ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. __ -- 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
FM1216ME MK5 radio
Hi Dmitry, please have a look at tveeprom concerning your FM1216ME/I MK5. It still maps to the MK3 and should break for radio. 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: [PATCH 12/24] media/video: fix dangling pointers
> > > Personally I'd much rather just not bother setting the driver data in
> > > the removal path, it seems unneeded. I had assumed that the subsystem
> > > code cared for some reason when I saw the patch series.
> >
> > Anyway, should this really be necessary, then for the media drivers this
> > should be done in v4l2_device_unregister_subdev() and not in every driver.
> >
> > But this just feels like an i2c core thing to me. After remove() is called
> > the core should just set the client data to NULL. If there are drivers that
> > rely on the current behavior, then those drivers should be reviewed first as
> > to the reason why they need it.
>
> I tend to agree, now.
>
> Wolfram, how do you feel about this? I feel a little sorry that I more
> or less encouraged you to submit this patch series, and now I get to
> agree with the objections which were raised against it.
Well, this is a valuable outcome in my book. Maybe seeing the actual amount of
modifications necessary for cleaning up clientdata helped the process. While
working on it, I also got the impression that it should be handled differently
in the future, of course. Although I was thinking of something different
('i2c_(allocate|free)_clientdata' as mentioned before), I prefer the above
proposal as it is most simple.
> My key motivation was that I wanted i2c_set_clientdata() to be called
> before kfree(). Now that everybody seems to agree that the latter
> belongs to the drivers while the former belongs to lower layers
> (i2c-core or even driver core), this is not going to happen. So I guess
> we want to remove calls to i2c_set_clientdata(NULL) from all drivers
> and have only one in i2c-core for now?
Fine with me. Let me know if I can assist you with the series.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: Kworld Plus TV Hybrid PCI (DVB-T 210SE)
Hi Peter, Am Samstag, den 20.03.2010, 16:20 +1100 schrieb 0123pe...@gmail.com: > on Wed, 17 Mar 2010 09:12 am > in the Usenet newsgroup gmane.linux.drivers.video-input-infrastructure > hermann pitton wrote: > > [snip] > > > > unfortunately the problem with these cards is known, but no good > > solution for now. > > > > Best description is from Hartmut and starts here. > > > > http://www.spinics.net/lists/linux-dvb/msg26683.html > > > [snip] > > Interesting link. I have one of the cards mentioned > (an MSI TV(at)nywhere A/D hybrid). I've decided not to throw it away. to not leave you without any response at least. In hind sight, seeing how unfortunate using such devices can be, mainly because of being forced to try at random again with a cold boot after some i2c war brought down the tuner, we better should have such only in a still experimental league and not as supported. This was not foreseeable in such rudeness and neither Hartmut nor me have such devices. The Asus triple OEM 3in1 I have does not have any problems with loading firmware from file, the others do all get it from eeprom. So, actually nobody is investigating on it with real hardware. Maybe you can catch something with gpio_tracking and i2c_debug=1. I would expect that the complex analog tuner initialization gets broken somehow. This is at least known to be good to bring all down. 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: [PATCH 12/24] media/video: fix dangling pointers
On Mon, Mar 22, 2010 at 09:33:58PM +0100, Jean Delvare wrote: > On Sun, 21 Mar 2010 17:09:56 +0100, Hans Verkuil wrote: > > On Sunday 21 March 2010 15:14:17 Mark Brown wrote: > > > I agree with this. There are also some use cases where the device data > > > is actually static (eg, a generic description of the device or a > > > reference to some other shared resource rather than per device allocated > > > data). > From a technical perspective, there is little rationale to have the > client data pointed to static data. If you could reach it from probe(), > it has to be a global, and if it is a global, you can reach it again > directly from the rest of your code. The use case I can think of there is bus type specific stuff for devices that support multiple buses. -- 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: WARNINGS
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 Mar 22 19:00:21 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14494:929298149eba git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 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-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS 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: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS 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: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS 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 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: [PATCH 12/24] media/video: fix dangling pointers
Replying to myself... On Sun, 21 Mar 2010 14:46:55 +0100, Jean Delvare wrote: > I get the feeling that this would be a job for managed resources as > some drivers already do for I/O ports and IRQs. Managed resources don't > care about symmetry of allocation and freeing, by design (so it can > violate point 1 above.) Aha! Isn't it exactly what devm_kzalloc() is > all about? Thinking about it again, this really only addresses the calls to kfree(), not the calls to i2c_set_clientdata(), so apparently I'm quite off-topic for this discussion. I still think that moving drivers to managed resources is the way to go, but that's a different issue. -- Jean Delvare -- 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 12/24] media/video: fix dangling pointers
Hi Hans, Mark, Wolfram, On Sun, 21 Mar 2010 17:09:56 +0100, Hans Verkuil wrote: > On Sunday 21 March 2010 15:14:17 Mark Brown wrote: > > On Sun, Mar 21, 2010 at 02:46:55PM +0100, Jean Delvare wrote: > > > On Sat, 20 Mar 2010 23:02:49 +0100, Hans Verkuil wrote: > > > > > > I feel I am missing something here. Why does clientdata have to be set > > > > to > > > > NULL when we are tearing down the device anyway? > > > > > We're not tearing down the device, that's the point. We are only > > > unbinding it from its driver. The device itself survives the operation. > > > > That's the subsystem point of view, not the driver point of view. As > > far as the driver is concerned the device appears when probe() is called > > and vanishes after remove() has completed, any management the subsystem > > does in between is up to it. > > Right. And from the point of view of the driver I see no reason why I would > have to zero the client data pointer when I know nobody will ever access it > again. If there is a good reason, then that is (again, from the PoV of the > driver) completely unexpected and it is guaranteed that driver writers will > continue to make that mistake in the future. I can't disagree. Given that there is no way to enforce the rule, it is likely not everybody will follow it. > > > 1* It is good practice to have memory freed not too far from where it > > > was allocated, otherwise there is always a risk of unmatched pairs. In > > > this regard, it seems preferable to let each i2c driver kfree the > > > device memory it kalloc'd, be it in probe() or remove(). > > > > I agree with this. There are also some use cases where the device data > > is actually static (eg, a generic description of the device or a > > reference to some other shared resource rather than per device allocated > > data). >From a technical perspective, there is little rationale to have the client data pointed to static data. If you could reach it from probe(), it has to be a global, and if it is a global, you can reach it again directly from the rest of your code. That being said, that doesn't mean drivers aren't actually doing it. > Definitely. Freeing should be done in the i2c drivers. > > > > 2* References to allocated memory should be dropped before that memory > > > is freed. This means that we want to call i2c_set_clientdata(c, NULL) > > > before kfree(d). As a corollary, we can't do the former in i2c-core and > > > the later in device drivers. > > > > This is where the mismatch between the subsystem view of the device > > lifetime and the driver view of the device lifetime comes into play. > > For the driver once the device is unregistered the device no longer > > exists - if the driver tries to work with the device it's buggy. This > > means that to the driver returning from the remove() function is > > dropping the reference to the data and there's no reason for the driver > > to take any other action. > > > > The device may hang around after the remove() has happened, but if the > > device driver knows or cares about it then it's doing something wrong. > > Similarly on probe() we can't assme anything about the pointer since > > even if we saw the device before we can't guarantee that some other > > driver didn't do so as well. The situation is similar to that with > > kfree() - we don't memset() data we're freeing with that, even though it > > might contain pointers to other things. I'm not sure if this comparison really holds. When you free memory, nobody is supposed to use that memory afterwards, so whether it contains pointers to other memory locations is irrelevant. Unbinding a device doesn't make it disappear, it might still get access, now or later, so the value of struct device members is more relevant. But of course we can discuss the guarantees made on these struct members over the device's lifetime. I don't this is documented anywhere. > Indeed. The client data is for the client. Once the client is gone (unbound) > the client data can safely be set back to NULL. > > > > So we are in the difficult situation where we can't do both in i2c-core > > > because that violates point 1 above, we can't do half in i2c-core and > > > half in device drivers because this violates point 2 above, so we fall > > > back to doing both in device drivers, which doesn't violate any point > > > but duplicates the code all around. > > > > Personally I'd much rather just not bother setting the driver data in > > the removal path, it seems unneeded. I had assumed that the subsystem > > code cared for some reason when I saw the patch series. > > Anyway, should this really be necessary, then for the media drivers this > should be done in v4l2_device_unregister_subdev() and not in every driver. > > But this just feels like an i2c core thing to me. After remove() is called > the core should just set the client data to NULL. If there are drivers that > rely on the current behavior, then those drivers should be reviewed fir
Re: [PATCH 5/5] Staging: cx25821: fix coding style issues in cx25821-medusa-video.c
> > Missing a space there. Otherwise looks good. > In the previous mail I have resent the patch with the missing space added. Regards, Olimpiu Pascariu -- 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] Staging: cx25821: fix coding style issues in cx25821-medusa-video.c
>From 32591165a537a03f472c68289798044d6eeea2e0 Mon Sep 17 00:00:00 2001
From: Olimpiu Pascariu
Date: Mon, 22 Mar 2010 22:07:20 +0200
Subject: [PATCH 5/5] Staging: cx25821: fix coding style issues in
cx25821-medusa-video.c
This is a patch to cx25821-medusa-video.c file that fixes up warnings and
errors found by the checkpatch.pl tool
Signed-off-by: Olimpiu Pascariu
---
drivers/staging/cx25821/cx25821-medusa-video.c | 207 ---
1 files changed, 108 insertions(+), 99 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-medusa-video.c
b/drivers/staging/cx25821/cx25821-medusa-video.c
index d601620..60dd086 100644
--- a/drivers/staging/cx25821/cx25821-medusa-video.c
+++ b/drivers/staging/cx25821/cx25821-medusa-video.c
@@ -24,11 +24,12 @@
#include "cx25821-medusa-video.h"
#include "cx25821-biffuncs.h"
-/
-//medusa_enable_bluefield_output()
-//
-// Enable the generation of blue filed output if no video
-//
+/*
+ * medusa_enable_bluefield_output()
+ *
+ * Enable the generation of blue filed output if no video
+ *
+ */
static void medusa_enable_bluefield_output(struct cx25821_dev *dev, int
channel,
int enable)
{
@@ -73,15 +74,15 @@ static void medusa_enable_bluefield_output(struct
cx25821_dev *dev, int channel,
}
value = cx25821_i2c_read(&dev->i2c_bus[0], out_ctrl, &tmp);
- value &= 0xFF7F;// clear BLUE_FIELD_EN
+ value &= 0xFF7F;/* clear BLUE_FIELD_EN */
if (enable)
- value |= 0x0080;// set BLUE_FIELD_EN
+ value |= 0x0080;/* set BLUE_FIELD_EN */
ret_val = cx25821_i2c_write(&dev->i2c_bus[0], out_ctrl, value);
value = cx25821_i2c_read(&dev->i2c_bus[0], out_ctrl_ns, &tmp);
value &= 0xFF7F;
if (enable)
- value |= 0x0080;// set BLUE_FIELD_EN
+ value |= 0x0080;/* set BLUE_FIELD_EN */
ret_val = cx25821_i2c_write(&dev->i2c_bus[0], out_ctrl_ns, value);
}
@@ -95,17 +96,18 @@ static int medusa_initialize_ntsc(struct cx25821_dev *dev)
mutex_lock(&dev->lock);
for (i = 0; i < MAX_DECODERS; i++) {
- // set video format NTSC-M
+ /* set video format NTSC-M */
value =
cx25821_i2c_read(&dev->i2c_bus[0], MODE_CTRL + (0x200 * i),
&tmp);
value &= 0xFFF0;
- value |= 0x10001; // enable the fast locking mode bit[16]
+ /* enable the fast locking mode bit[16] */
+ value |= 0x10001;
ret_val =
cx25821_i2c_write(&dev->i2c_bus[0], MODE_CTRL + (0x200 * i),
value);
- // resolution NTSC 720x480
+ /* resolution NTSC 720x480 */
value =
cx25821_i2c_read(&dev->i2c_bus[0],
HORIZ_TIM_CTRL + (0x200 * i), &tmp);
@@ -119,17 +121,17 @@ static int medusa_initialize_ntsc(struct cx25821_dev *dev)
cx25821_i2c_read(&dev->i2c_bus[0],
VERT_TIM_CTRL + (0x200 * i), &tmp);
value &= 0x00C00C00;
- value |= 0x1C1E001A;// vblank_cnt + 2 to get camera ID
+ value |= 0x1C1E001A;/* vblank_cnt + 2 to get camera ID */
ret_val =
cx25821_i2c_write(&dev->i2c_bus[0],
VERT_TIM_CTRL + (0x200 * i), value);
- // chroma subcarrier step size
+ /* chroma subcarrier step size */
ret_val =
cx25821_i2c_write(&dev->i2c_bus[0],
SC_STEP_SIZE + (0x200 * i), 0x43E0);
- // enable VIP optional active
+ /* enable VIP optional active */
value =
cx25821_i2c_read(&dev->i2c_bus[0],
OUT_CTRL_NS + (0x200 * i), &tmp);
@@ -139,7 +141,7 @@ static int medusa_initialize_ntsc(struct cx25821_dev *dev)
cx25821_i2c_write(&dev->i2c_bus[0],
OUT_CTRL_NS + (0x200 * i), value);
- // enable VIP optional active (VIP_OPT_AL) for direct output.
+ /* enable VIP optional active (VIP_OPT_AL) for direct output. */
value =
cx25821_i2c_read(&dev->i2c_bus[0], OUT_CTRL1 + (0x200 * i),
&tmp);
@@ -149,19 +151,21 @@ static int medusa_initialize_ntsc(struct cx25821_dev *dev)
cx25821_i2c_write(&dev->i2c_bus[0], OUT_CTRL1 + (0x200 * i),
value);
- // clear VPRES_VERT_EN bit, fixes the chroma run away probl
Re: av7110 and budget_av are broken!
Am 20.3.2010 22:37, schrieb Hans Verkuil: > On Saturday 20 March 2010 17:03:01 e9hack wrote: > OK, I know that. But does the patch I mailed you last time fix this problem > without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Regards, Hartmut -- 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] DTV2000 H Plus issues
On 03/15/2010 05:15 AM, Devin Heitmueller wrote: > I'll try to go through my tree and see if I can get something upstream > this week which you could build on. Are there any news on this ? By the way, I have just received this mail from Mirek Slugen, with a patch for PxDVR3200 with XC4000 tuner. Should that patch also be submitted ? On 03/22/2010 04:40 PM, Mirek Slugeň wrote: > First I would like to thank you for your work on XC4000 Leadtek > tuners, analog TV, analog FM and DVB-T works great. > > I created patch for new revision of Leadtek DVR3200 (xc4000) based on > your patch and it works also (patch is included). > > After long testing I found only one small bug, signal strength is not > working on DVB-T XC4000 based tuners, so i will try to fix it. -- 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] V4L/DVB: ds3000: fix divide-by-zero error in ds3000_read_snr()
Fix a divide-by-zero error in ds3000's ds3000_read_snr(), when getting
a very low signal reading (dvbs2_signal_reading >= 1). This prevents
some nasty EIPs when running szap-s2 with a very low signal strength.
Signed-off-by: Nicolas Noirbent
---
drivers/media/dvb/frontends/ds3000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/frontends/ds3000.c
b/drivers/media/dvb/frontends/ds3000.c
index cff3535..78001e8 100644
--- a/drivers/media/dvb/frontends/ds3000.c
+++ b/drivers/media/dvb/frontends/ds3000.c
@@ -719,7 +719,7 @@ static int ds3000_read_snr(struct dvb_frontend *fe, u16
*snr)
(ds3000_readreg(state, 0x8d) << 4);
dvbs2_signal_reading = ds3000_readreg(state, 0x8e);
tmp = dvbs2_signal_reading * dvbs2_signal_reading >> 1;
- if (dvbs2_signal_reading == 0) {
+ if (tmp == 0) {
*snr = 0x;
return 0;
}
--
1.7.0.2
--
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 - Your board has no unique USB ID and thus need a hint to be detected
On Mon, Mar 22, 2010 at 1:45 PM, Steffen Pankratz wrote: > Hi Devin, > > I don't want to push you but are there any news? I've been too buried in other projects to work on it. In the meantime, you can add "card=53" as a modprobe option to em28xx, and it should start working for you. 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 - Your board has no unique USB ID and thus need a hint to be detected
On Fri, 19 Mar 2010 13:17:20 -0400 Devin Heitmueller wrote: > On Fri, Mar 19, 2010 at 1:13 PM, Steffen Pankratz wrote: > > On Fri, 19 Mar 2010 13:07:23 -0400 > > Devin Heitmueller wrote: > > > >> On Fri, Mar 19, 2010 at 1:01 PM, Steffen Pankratz wrote: > >> > Hi, > >> > > >> > this USB stick is a Pinnacle Pctv Hybrid Pro 320e device > >> > (ID eb1a:2881 eMPIA Technology, Inc.). > >> > > >> > Is there anything else you need to know? > >> > >> > >> This was fixed some time ago. Just install the current v4l-dvb code > >> (instructions can be found at http://linuxtv.org/repo) > > > > This is what I did. > > > > hg tip output: > > > > changeset: 14494:929298149eba > > tag: tip > > user: Douglas Schilling Landgraf > > date: Thu Mar 18 23:47:27 2010 -0300 > > summary: ir-keytable: fix prototype for kernels < 2.6.22 > > Hmm... Interesting. Your eeprom hash is different than everybody > else who has a 320e. I will have to do a manual comparison and see > why it is different. Hi Devin, I don't want to push you but are there any news? -- Hermes powered by LFS SVN-20070420 (Linux 2.6.33.1) Best regards, Steffen Pankratz. signature.asc Description: PGP signature
Re: Questions to ngene/dvb_frontend driver [Original email was "Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)"]
Hi list, in addition to my previous tests, I found that the problems with long tuning delays only occurs when switching to an SD channel. If I switch to an HD channel, e.g., using adapter 0, I always get fast tuning times (see my tests below). Since the large delays only occur when switching to an SD channel, I have the following questions. 1) Is there different code for tuning to an HD channel or tuning to an SD-channel? 2) If yes, which which methods in which modules are repsonsible for tuning to an SD/HD channel? 3) Are there any methods wihtin the dvb_frontend oder ngene Modul (or anywhere in the DVB driver) that have to differ between SD- and HD channels? It would be realy great, if somone can answer these questions or give me some hints to find the problem. Best regards Michael Tests (channels_DVB-S2_transponder_switch_HD.conf and channels_DVB-S2_transponder_switch.conf are attached to this email): 1) Tune to a TV channel and forward data to dvr device ./szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r 2) In paralle to1) use adapter 0 to tune to an HD-Kanal ./szap-s2 -H -c channels_DVB-S2_transponder_switch_HD.conf -a 0 -n 2 -x -S 1 | grep Delay Delay : 0.569672 3) In paralle to1) use adapter 0 to tune to an HD-Kanal ./szap-s2 -H -c channels_DVB-S2_transponder_switch_HD.conf -a 0 -n 1 -x -S 1 | grep Delay Delay : 0.581712 4) In paralle to1) use adapter 0 to tune to an SD-Kanal ./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x | grep Delay Delay : 1.760880 Michael Repplinger wrote: > Hi, > I read the problems described in email thread "Problems with ngene based > DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 > Dual)". Unfortunately, I just subscribed to this list so I cannot > respond to the original mail directly but it can be found at the end of > this mail. > > For tracking down the described problems with high delays, I tried to > understand the dvb_frontend and ngene driver and added some output > messages. The added output messages are attached as a ptach to this > email. Since this was the first time I read the source code of the > module I was not able to find a real problem or bug. > > However, I found 3 issues that I would like to report. Especially issue > 1) could be a problem. Here the irq handler of ngene module is still > triggered for 60secs if the last application using the DVB devices > terminates. > In Issue 2) I describe the methods that need more time when the > described problem occur. Unfortunately, I could only determine that > these methods need more time but was not able to find a reason. > Issue 3) could be related to issue 1). Here I saw that the ngene module > is not informed if the DVB frontend device is closed. > > Again, since I read the source code of a driver for the first time I > don't know if the described issues are OK or not. It would be great if > some of you could check the described issues. Maybe this information > helps to find/solve the problem. > > Thanks in advance > Michael Repplinger > > Testsystem: > -Kernel: 2.6.25.20-0.5-pae (Suse 11.0 distribution) > -Driver: following endriss/ngene DVB driver + attached patch > *Repository URL : http://linuxtv.org/hg/~endriss/ngene > *Revision : 14413:510e37da759e > > *Issue 1) IRQ handler is triggered for 60 seconds after last > application stops using the dvb device:* > > Reproduce Test: > a) load dvb modules as follows: > rmmod ngene > rmmod dvb_core > > modprobe dvb_core dvbdev_debug=1 frontend_debug=1 debug=1 cam_debug=1 > dvb_demux_tscheck=1 dvb_net_debug=1 > modprobe ngene debug=1 one_adapter=0 > > b) tail -f /var/log/messages > c) In parallel to b) start >./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x > > *Observation 1: * > In b) one can see the following output messages: > Mar 20 14:18:01 dvb_host kernel: ngene>: irq_handler IRQ 16 > Mar 20 14:18:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED > Mar 20 14:18:01 dvb_host kernel: ngene: demux_tasklet > Mar 20 14:18:01 dvb_host kernel: ngene: tsin_exchange > > => The following mehtods of ngene-core.c are called > - static irqreturn_t irq_handler(int irq, void *dev_id) ( produces the > first two lines of the above output messages) > - static void demux_tasklet(unsigned long data) ( produces the third > lines of the above output messages) > - static void *tsin_exchange(void *priv, void *buf, u32 len, u32 clock, > u32 flags) (procudes the last output message) > > => IRQ handler of ngene-core module is periodically triggered as soon as the > first application using DVB device has been used > > *Observation 2: * > Exactly 60 seconds after executing c), the IRQ handler is no longer > triggered > and no more output messages appear in b). > Here the last output messages are: > > Mar 20 14:19:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED > Mar 20 14:19:01 dvb_host kernel: ngene: demux_tasklet > Mar 20 14:19:01 dvb_ho
Re: omap2 camera
Aguirre, Sergio wrote: > Hi Viral, > >> -Original Message- >> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- >> ow...@vger.kernel.org] On Behalf Of Viral Mehta >> Sent: Monday, March 22, 2010 5:20 AM >> To: linux-media@vger.kernel.org >> Subject: omap2 camera >> >> Hi list, >> >> I am using OMAP2430 board and I wanted to test camera module on that >> board. >> I am using latest 2.6.33 kernel. However, it looks like camera module is >> not supported with latest kernel. >> >> Anyone is having any idea? Also, do we require to have ex3691 sensor >> driver in mainline kernel in order to get omap24xxcam working ? >> >> These are the steps I followed, >> 1. make omap2430_sdp_defconfig >> 2. Enable omap2 camera option which is under drivers/media/video >> 3. make uImage >> >> And with this uImage, camera is not working. I would appreciate any help. > > I'm adding Sakari Ailus to the CC list, which is the owner of the driver. Thanks, Sergio! I've only aware of the tcm825x sensor driver that works with the OMAP 2420 camera controller (omap24xxcam) driver. So likely you'd need the driver for the sensor you have on that board. The omap24xxcam and tcm825x drivers should be moved to use v4l2_subdev but I'm not quite sure what will be the schedule of that. Then we could get rid of the v4l2-int-device interface that those drives still use. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch v2] cx231xx: card->driver "Conexant cx231xx Audio" too long
At Mon, 22 Mar 2010 19:54:30 +0300,
Dan Carpenter wrote:
>
> On Mon, Mar 22, 2010 at 05:04:55PM +0100, Takashi Iwai wrote:
> > At Mon, 22 Mar 2010 08:43:47 -0700,
> > Joe Perches wrote:
> > >
> > > On Mon, 2010-03-22 at 18:39 +0300, Dan Carpenter wrote:
> > > > card->driver is 15 characters and a NULL, the original code could
> > > > cause a buffer overflow.
> > >
> > > > In version 2, I used a better name that Takashi Iwai suggested.
> > >
> > > Perhaps it's better to use strncpy as well.
> >
> > strlcpy() would be safer :)
> >
> > But, in such a case, we want rather that the error is notified at
> > build time.
> >
> > Maybe a macro like below would be helpful to catch such bugs?
> >
> > #define COPY_STRING(buf, src)
> > \
> > do {\
> > if (__builtin_constant_p(src)) \
> > BUILD_BUG_ON(strlen(src) >= sizeof(buf)); \
> > strcpy(buf, src); \
> > } while (0)
> >
> > and used like:
> >
> > struct foo {
> > char foo[5];
> > } x;
> >
> > COPY_STRING(x.foo, "OK"); // OK
> > COPY_STRING(x.foo, "1234567890"); // NG
> >
>
> I can do the same thing with Smatch. The smatch check can also find
> bugs like this:
>
> buf = kmalloc(10, GFP_KERNEL);
> strcpy(buf, "1234567890");
>
> I used smatch to find this bug and 5 others on my allmodconfig w/ staging.
> I also found 19 other places that use strcpy() to copy from a large buffer
> into a smaller buffer.
Ah, nice.
> Your idea is nice, but I think anyone who deliberately uses the new
> macro is not going to have the bug in the first place. ;)
Yeah, in theory, such a code should be never committed because it
can be caught at build time ;)
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] cx231xx: card->driver "Conexant cx231xx Audio" too long
On Mon, Mar 22, 2010 at 05:04:55PM +0100, Takashi Iwai wrote:
> At Mon, 22 Mar 2010 08:43:47 -0700,
> Joe Perches wrote:
> >
> > On Mon, 2010-03-22 at 18:39 +0300, Dan Carpenter wrote:
> > > card->driver is 15 characters and a NULL, the original code could
> > > cause a buffer overflow.
> >
> > > In version 2, I used a better name that Takashi Iwai suggested.
> >
> > Perhaps it's better to use strncpy as well.
>
> strlcpy() would be safer :)
>
> But, in such a case, we want rather that the error is notified at
> build time.
>
> Maybe a macro like below would be helpful to catch such bugs?
>
> #define COPY_STRING(buf, src) \
> do {\
> if (__builtin_constant_p(src)) \
> BUILD_BUG_ON(strlen(src) >= sizeof(buf)); \
> strcpy(buf, src); \
> } while (0)
>
> and used like:
>
> struct foo {
> char foo[5];
> } x;
>
> COPY_STRING(x.foo, "OK"); // OK
> COPY_STRING(x.foo, "1234567890"); // NG
>
I can do the same thing with Smatch. The smatch check can also find
bugs like this:
buf = kmalloc(10, GFP_KERNEL);
strcpy(buf, "1234567890");
I used smatch to find this bug and 5 others on my allmodconfig w/ staging.
I also found 19 other places that use strcpy() to copy from a large buffer
into a smaller buffer.
Your idea is nice, but I think anyone who deliberately uses the new
macro is not going to have the bug in the first place. ;)
regards,
dan carpenter
>
> 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] cx231xx: card->driver "Conexant cx231xx Audio" too long
At Mon, 22 Mar 2010 08:43:47 -0700,
Joe Perches wrote:
>
> On Mon, 2010-03-22 at 18:39 +0300, Dan Carpenter wrote:
> > card->driver is 15 characters and a NULL, the original code could
> > cause a buffer overflow.
>
> > In version 2, I used a better name that Takashi Iwai suggested.
>
> Perhaps it's better to use strncpy as well.
strlcpy() would be safer :)
But, in such a case, we want rather that the error is notified at
build time.
Maybe a macro like below would be helpful to catch such bugs?
#define COPY_STRING(buf, src) \
do {\
if (__builtin_constant_p(src)) \
BUILD_BUG_ON(strlen(src) >= sizeof(buf)); \
strcpy(buf, src); \
} while (0)
and used like:
struct foo {
char foo[5];
} x;
COPY_STRING(x.foo, "OK"); // OK
COPY_STRING(x.foo, "1234567890"); // NG
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] cx231xx: card->driver "Conexant cx231xx Audio" too long
On Mon, 2010-03-22 at 18:39 +0300, Dan Carpenter wrote: > card->driver is 15 characters and a NULL, the original code could > cause a buffer overflow. > In version 2, I used a better name that Takashi Iwai suggested. Perhaps it's better to use strncpy as well. -- 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 v2] cx231xx: card->driver "Conexant cx231xx Audio" too long
card->driver is 15 characters and a NULL, the original code could cause a buffer overflow. Signed-off-by: Dan Carpenter --- In version 2, I used a better name that Takashi Iwai suggested. diff --git a/drivers/media/video/cx231xx/cx231xx-audio.c b/drivers/media/video/cx231xx/cx231xx-audio.c index 7793d60..7cae95a 100644 --- a/drivers/media/video/cx231xx/cx231xx-audio.c +++ b/drivers/media/video/cx231xx/cx231xx-audio.c @@ -495,7 +495,7 @@ static int cx231xx_audio_init(struct cx231xx *dev) pcm->info_flags = 0; pcm->private_data = dev; strcpy(pcm->name, "Conexant cx231xx Capture"); - strcpy(card->driver, "Conexant cx231xx Audio"); + strcpy(card->driver, "Cx231xx-Audio"); strcpy(card->shortname, "Cx231xx Audio"); strcpy(card->longname, "Conexant cx231xx Audio"); -- 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] cx231xx: card->driver "Conexant cx231xx Audio" too long
At Fri, 19 Mar 2010 14:49:57 +0300, Dan Carpenter wrote: > > card->driver is 15 characters and a NULL, the original code could > cause a buffer overflow. > > Signed-off-by: Dan Carpenter This should rather a string without spaces because this string is used as an identifier in alsa-lib. Better to use "Cx231xx" or "Cx231xx-Audio". Takashi > > diff --git a/drivers/media/video/cx231xx/cx231xx-audio.c > b/drivers/media/video/cx231xx/cx231xx-audio.c > index 7793d60..b3282ae 100644 > --- a/drivers/media/video/cx231xx/cx231xx-audio.c > +++ b/drivers/media/video/cx231xx/cx231xx-audio.c > @@ -495,7 +495,7 @@ static int cx231xx_audio_init(struct cx231xx *dev) > pcm->info_flags = 0; > pcm->private_data = dev; > strcpy(pcm->name, "Conexant cx231xx Capture"); > - strcpy(card->driver, "Conexant cx231xx Audio"); > + strcpy(card->driver, "Cx231xx Audio"); > strcpy(card->shortname, "Cx231xx Audio"); > strcpy(card->longname, "Conexant cx231xx Audio"); > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- 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: Phase 1: Proposal to convert V4L1 drivers
On Mon, 22 Mar 2010, Hans de Goede wrote: > > [...] I've seen the same > problem (not streaming) with the "old" version when used with machines > with UHCI usb controllers (rather then OHCI), such as atom based > laptops. > > So maybe this is some timing issues, and your changes have speed up some > path? Sorry to break into a very interesting discussion which I was otherwise just watching. But how many other cases of this kind of UHCI versus OHCI kind of thing has anyone else witnessed? Recall, we faced exactly the same situation in developing the current version of the mr97310a driver? That I was doing everything on an OHCI machine and then, at the very last step I tested on a UHCI machine and suddenly some of the cameras would not work? And there was one magic command to the camera which "fixed" the problem and we still don't know why that one magic command fixed the problem, only that the fix is very critical, very necessary, and it does work? Please, anyone who can report similar mysterious events, let me know. I would still like to get to the bottom of what is going on, if I can. Sorry for the interruption. Anyone who is interested in pursuing this, start a new thread if you want. Theodore Kilgore -- 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: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Hans de Goede wrote: > Hi, > > On 03/22/2010 09:11 AM, Hans Verkuil wrote: >> On Sunday 21 March 2010 00:14:25 Hans de Goede wrote: >>> Hi, >>> >>> On 03/20/2010 10:21 AM, Hans Verkuil wrote: Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. >>> >>> Yes it can, this for example already happens when using v4l1 apps with >>> uvcvideo (which is not possible without libv4l1). >> >> In what way does libv4l1 still depend on the kernel's v4l1 compat layer? > > It depends on some of the ioctl compatibility stuff, which lives in > drivers/media/video/v4l1-compat.c > > Basically it depends on: > > v4l_compat_translate_ioctl() > > From that file and on what that depends on in turn. Note that it does not > depend on v4l_compat_translate_ioctl() for all ioctl's. It handles > some of them in its own, see: > lib/libv4l1/libv4l1.c > > In v4l-utils git, specifically the v4l1_ioctl() function. Note that simply > checking which one are listed in the switch case is not enough to determine > which ones are already handled by libv4l, some still call > v4l_compat_translate_ioctl() (by doing the v4l1 ioctl) and then munge the > results. > > Currently it is mainly targeted and tested with webcam using apps, so no > overlay, input switching, vbi or tuning support. Probably no radio. Radio is not that different from tuning, but, as radio uses tuning on a different way (it needs only a subset of ioctl's), you may see troubles on radio applications with V4L1 even when the driver works with TV with V4L1. We had this issue when ported the radio drivers from V4L1 to V4L2: we had to implement some dummy V4L2 ioctls, for the V4L1 compat logic to work. > Adding input switching, vbi and tuning support, should be easy I think. > Overlay has me worried as the v4l1 API does not clearly separate between > overlay and capture. Since overlay does not really work out of the box > on any distro's anyways (in my experience), I think the best thing to > do would be to just hide the overlay capability for v4l1 apps. The last time I tested overlay, it worked perfectly. You need to be sure that you're not running it on a machine with Via or Sys chipsets, as those chips have bugs with pci2pci data transfers, so the PCI quirk code disables overlay with broken north bridge chipsets. 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: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Hans Verkuil wrote: > On Sunday 21 March 2010 00:14:25 Hans de Goede wrote: >> Yes it can, this for example already happens when using v4l1 apps with >> uvcvideo (which is not possible without libv4l1). > > In what way does libv4l1 still depend on the kernel's v4l1 compat layer? And > what is needed to remove that dependency? > > Because I think that that is the best approach. Agreed. After being sure that it will properly work with all types of app (e. g. radio/vbi/tv/stream/record/..), we can add a features removal patch announcing that the backport got moved to userspace and it will be removed from kernel. > >>> The third phase that can be done in parallel is to convert V4L1-only apps. >>> I strongly suspect that any apps that are V4L1-only are also unmaintained. >>> We have discussed before that we should set up git repositories for such >>> tools (xawtv being one of the more prominent apps since it contains several >>> v4l1-only console apps). Once we have maintainership, then we can convert >>> these tools to v4l2 and distros and other interested parties have a place >>> to send patches to. >>> >> As said before I wouldn't mind maintaining an xawtv git tree @ linuxtv, >> assuming this tree were to be based on the 3.95 release. > > Mauro, do you have any objection to hosting xawtv on linuxtv? We may need > another tree later as well if we decide to split off the xawtv console tools > into a separate tree. But perhaps they would fit under v4l-utils as well, > we'll have to see. Not at all. Feel free to add a git tree to all applications you want. If you have problems, please ping me. After creating the tree(s), just send me an email with the name of the maintainer(s) and I'll move them to the right place, enabling the announcement hooks if needed. If possible, please get the old maintainer's ack. With respect to the announcements, we're currently using the same mailing list (linuxtv-comm...@linuxtv.org) for all sorts of announcement: dvb-apps, v4l-utils, v4l-dvb.git, fixes.git v4l-dvb(hg). If we're starting to populate the server with other trees, it may be a good idea to split the ML into groups, or eventually into per-tree list. Comments? -- 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: omap2 camera
Hi Viral, > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Viral Mehta > Sent: Monday, March 22, 2010 5:20 AM > To: linux-media@vger.kernel.org > Subject: omap2 camera > > Hi list, > > I am using OMAP2430 board and I wanted to test camera module on that > board. > I am using latest 2.6.33 kernel. However, it looks like camera module is > not supported with latest kernel. > > Anyone is having any idea? Also, do we require to have ex3691 sensor > driver in mainline kernel in order to get omap24xxcam working ? > > These are the steps I followed, > 1. make omap2430_sdp_defconfig > 2. Enable omap2 camera option which is under drivers/media/video > 3. make uImage > > And with this uImage, camera is not working. I would appreciate any help. I'm adding Sakari Ailus to the CC list, which is the owner of the driver. Regards, Sergio > > Thanks, > Viral > > This Email may contain confidential or privileged information for the > intended recipient (s) If you are not the intended recipient, please do > not use or disseminate the information, notify the sender and delete it > from your system. > > __ > -- > 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: [PATCH 5/5] Staging: cx25821: fix coding style issues in cx25821-medusa-video.c
On Sun, Mar 21, 2010 at 08:51:43PM +0200, Olimpiu Pascariu wrote: > >From 24e5efa163c1fa58f694fd8b44dc3488e0cc92d1 Mon Sep 17 00:00:00 2001 > From: Olimpiu Pascariu > Date: Sun, 21 Mar 2010 20:46:26 +0200 > Subject: [PATCH 5/5] Staging: cx25821: fix coding style issues in > cx25821-medusa-video.c > This is a patch to cx25821-medusa-video.c file that fixes up warnings and > errors found by the checkpatch.pl tool > Signed-off-by: Olimpiu Pascariu > [ snip ] > +/* > + * medusa_enable_bluefield_output() > + * > + * Enable the generation of blue filed output if no video > + * > +*/ Missing a space there. Otherwise looks good. Acked-by: Dan Carpenter 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: [REPORT] Brainstorm meeting on V4L2 memory handling
> -Original Message- > From: Pawel Osciak [mailto:p.osc...@samsung.com] > Sent: Monday, March 22, 2010 6:31 PM > To: Hiremath, Vaibhav; linux-media@vger.kernel.org > Subject: RE: [REPORT] Brainstorm meeting on V4L2 memory handling > > Hello! > > >Hiremath, Vaibhav wrote: > >> 1) Memory-to-memory devices > >> > >> Original thread with the proposal from Samsung: > >> > >> http://www.mail-archive.com/linux-samsung- > s...@vger.kernel.org/msg00391.html > >> > >[Hiremath, Vaibhav] Pawel, > > > >I wanted to start prototyping Resizer and Previewer driver to this > framework, > > before starting just wanted to make sure that I start with latest and > > greatest. Is V2 post still holds latest? Did you do any changes after > that? > > > > Only some minor tweaks for v3, which is currently underway. This is the > expected > changelog for it: > > - streamon/off will have to be called on both queues instead of just either > one > - automatic rescheduling for instances if they have more buffers waiting > - addressing comments from Andy Walls > > All in all, I do not expect any other API changes and only minor tweaks > under > the hood. It should be ready this week. > [Hiremath, Vaibhav] In that case I can start with V2 as of now and will migrate to V3 once you post it to list. Thanks, Vaibhav > > >Also, have you validated this with actual hardware module? If not then I > think > >I can now start on this and add resizer driver to it. > > Yes, we have actually been using v2 for several real devices, one of which > was > the previously posted S3C rotator driver: > http://www.mail-archive.com/linux-media@vger.kernel.org/msg13606.html > > And there is always the test device, which was posted along with v2. > > If you come across any problems or have more questions, I would be happy to > help. > > Best regards > -- > Pawel Osciak > Linux Platform Group > Samsung Poland R&D Center > -- 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: [REPORT] Brainstorm meeting on V4L2 memory handling
Hello! >Hiremath, Vaibhav wrote: >> 1) Memory-to-memory devices >> >> Original thread with the proposal from Samsung: >> >> http://www.mail-archive.com/linux-samsung-...@vger.kernel.org/msg00391.html >> >[Hiremath, Vaibhav] Pawel, > >I wanted to start prototyping Resizer and Previewer driver to this framework, > before starting just wanted to make sure that I start with latest and > greatest. Is V2 post still holds latest? Did you do any changes after that? > Only some minor tweaks for v3, which is currently underway. This is the expected changelog for it: - streamon/off will have to be called on both queues instead of just either one - automatic rescheduling for instances if they have more buffers waiting - addressing comments from Andy Walls All in all, I do not expect any other API changes and only minor tweaks under the hood. It should be ready this week. >Also, have you validated this with actual hardware module? If not then I think >I can now start on this and add resizer driver to it. Yes, we have actually been using v2 for several real devices, one of which was the previously posted S3C rotator driver: http://www.mail-archive.com/linux-media@vger.kernel.org/msg13606.html And there is always the test device, which was posted along with v2. If you come across any problems or have more questions, I would be happy to help. Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- 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] cx23885: strcpy() => strlcpy()
cap->driver is a 16 char buffer and dev->name is a 32 char buffer. I don't see an actual problem, but we may as well make the static checkers happy. Signed-off-by: Dan Carpenter diff --git a/drivers/media/video/cx23885/cx23885-417.c b/drivers/media/video/cx23885/cx23885-417.c index 2ab97ad..6fff89d 100644 --- a/drivers/media/video/cx23885/cx23885-417.c +++ b/drivers/media/video/cx23885/cx23885-417.c @@ -1355,7 +1355,7 @@ static int vidioc_querycap(struct file *file, void *priv, struct cx23885_dev *dev = fh->dev; struct cx23885_tsport *tsport = &dev->ts1; - strcpy(cap->driver, dev->name); + strlcpy(cap->driver, dev->name, sizeof(cap->driver)); strlcpy(cap->card, cx23885_boards[tsport->dev->board].name, sizeof(cap->card)); sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci)); -- 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 and Planar YUV422 16 bit camera
Hi Rodolfo
On Wed, 17 Mar 2010, Rodolfo Giometti wrote:
> Hello,
>
> I'm puzzled to know if the pxa_camera driver can manage a data depth
> different from 8 bits.
>
> I'm currently trying to add a camera interface support to my PXA270
> based board with an adv7180 as soc camera device.
>
> For the adv7180 I defined:
>
> static const struct soc_camera_data_format adv7180_colour_formats[] =
> {
> {
> .name = "Planar YUV422 16 bit",
> .depth = 16,
> .fourcc = V4L2_PIX_FMT_YUV422P,
> .colorspace = V4L2_COLORSPACE_JPEG,
> }
> };
first, you're working with an outdated kernel, don't think I'll be able to
help you with that.
> but this is rejected by the pxa_camera driver buswidth_supported().
>
> On the other hands if I set .depth = 8 in above struct I get the
> following:
Please, update your kernel to the current state. YUV422P is not supported
by pxa natively, so, it can only be handled in the pass-through mode.
Further, adv7180 is currently unsuitable for soc-camera, you have to
modify it after updating to the current kernel. Then please show us your
patch for adv7180, then we'll try to help you further.
> debian:~# gst-launch v4l2src ! video/x-raw-yuv,width=320,height=240 !
> filesink location=/tmp/video.raw
> Setting pipeline to PAUSED ...
> Pipeline is live and does not need PREROLL ...
> WARNING: from element /pipeline0/v4l2src0: Could not get parameters on
> device '/dev/video0'
> Additional debug info:
> v4l2src_calls.c(1172): gst_v4l2src_set_capture ():
> /pipeline0/v4l2src0:
> system error: Invalid argument
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> WARNING: from element /pipeline0/v4l2src0: Got unexpected frame size
> of 76800 instead of 153600.
> Additional debug info:
> gstv4l2src.c(1077): gst_v4l2src_get_mmap (): /pipeline0/v4l2src0
> WARNING: from element /pipeline0/v4l2src0: Got unexpected frame size
> of 76800 instead of 153600.
>
> That is the pax_camera device returns 8bits per pixel instead of 16...
>
> Can you please help me in finding what's wrong? :'(
Thanks
Guennadi
---
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
TT s2-3200 does not scan the frequencies <5000
I do not speak English but can understand. This text was translated by google. Do not want to be inconvenient. In December I reported that the board TT s2-3200 does not scan the frequencies <5000. Because there will be issues of more interest was not the case is not resolved, hence my insistence. By doing scan with SymbolRate <5000 I have the following response: My scan: da...@linux-rpr6:~/satelite> scan Feeds scanning Feeds using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' ERROR: invalid enum value '9' initial transponder 10983000 V 4999000 9 >>> tune to: 10983:v:0:4999 DVB-S IF freq is 1233000 __tune_to_transponder:1508: ERROR: Setting frontend parameters failed: 22 Invalid argument >>> tune to: 10983:v:0:4999 DVB-S IF freq is 1233000 __tune_to_transponder:1508: ERROR: Setting frontend parameters failed: 22 Invalid argument ERROR: initial tuning failed dumping lists (0 services) Done. My /log/warn Mar 22 11:09:05 linux-rpr6 kernel: [ 3982.186317] DVB: adapter 0 frontend 0 symbol rate 4999000 out of range (500..4500) Mar 22 11:09:06 linux-rpr6 kernel: [ 3982.399294] DVB: adapter 0 frontend 0 symbol rate 4999000 out of range (500..4500) My lspci -nn 01:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7146 [1131:7146] (rev 01) My lspci -vv 01:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH S2-3200 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html
WG: Tuning very unreliable (Technisat Skystar HD2)
Hello alltogether, I am in the process of switching my home entertainment system from Windows to Linux. The distro of choice is OpenSuse 11.2 . Ultimately, I want to run MythTV with XFCE on it. My TV cards are two pieces of Technisat Skystar HD2. In Windows, my hardware works just fine. Yet, in Linux I have problems that I cannot explain to myself. I have downloaded the latest s2-liplianin drivers, compiled and installed them (make && make install). Then I downloaded and installed scan-s2 from the repository (make). I did this all yesterday night, with cloudy skies and some rain. While scanning with scan-s2 o zap dvb-s/Astra-19.2E I could fine a number of channels, yet I did not save the channel list. As it was quite late, I decided to shutdown the PC and continue this morning. However, now I just get the following response from scan-s2 under blue sky and clear view: media-pc-wz:~/tv/scan-s2 # ./scan-s2 -o zap dvb-s/Astra-19.2E API major 5, minor 1 scanning dvb-s/Astra-19.2E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder DVB-S 12551500 V 2200 5/6 AUTO AUTO initial transponder DVB-S2 12551500 V 2200 5/6 AUTO AUTO --> Using DVB-S >>> tune to: 12551:v:0:22000 DVB-S IF freq is 1951500 WARNING: >>> tuning failed!!! >>> tune to: 12551:v:0:22000 (tuning failed) DVB-S IF freq is 1951500 WARNING: >>> tuning failed!!! --> Using DVB-S2 >>> tune to: 12551:v:0:22000 DVB-S IF freq is 1951500 WARNING: >>> tuning failed!!! >>> tune to: 12551:v:0:22000 (tuning failed) DVB-S IF freq is 1951500 WARNING: >>> tuning failed!!! ERROR: initial tuning failed dumping lists (0 services) Done. My TV cards are detected (lspci-output): 03:05.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01) Subsystem: Device 1ae4:0001 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 1: Proposal to convert V4L1 drivers
On Monday 22 March 2010 10:29:09 Hans de Goede wrote: > Hi, > > On 03/22/2010 01:17 AM, Hans Verkuil wrote: > > On Sunday 21 March 2010 23:45:04 Hans Verkuil wrote: > >> On Saturday 20 March 2010 09:58:49 Hans Verkuil wrote: > >>> These drivers have no hardware to test with: bw-qcam, c-qcam, arv, w9966. > >>> However, all four should be easy to convert to v4l2, even without > >>> hardware. > >>> Volunteers? > >> > >> I've converted these four drivers to V4L2. > > > > I've also removed the V4L1 support from cpia2 and pwc and removed some last > > V4L1 code remnants from meye and zoran. It's all in the same tree. > > > > Hans, could you test the pwc driver for me? > > > > Done, > > And the news is not good I'm afraid, it does not work. I've one interesting > observation though. It does work if I first run it once with the "old" > version of the driver and then load your version (also replacing videodev.ko, > etc with the ones from your tree). But if I plug it in with your driver in > place it does not stream (nothing interesting in dmesg). So it seems like > an initialization problem. When you run it with the old version, are you using the V4L1 API or the V4L2 API? And what program do you use for testing? As far as I can see there should be no difference in the code between the old and the new version if you use the V4L2 API in both cases. It's a fairly straightforward patch. > As said the pwc driver needs some love in general, I've seen the same problem > (not streaming) with the "old" version when used with machines with UHCI usb > controllers (rather then OHCI), such as atom based laptops. > > So maybe this is some timing issues, and your changes have speed up some path? > > Note that I've 3 identical pwc cams, I would be more then happy to give you > one, let me know how to best get it to you. I will have to double check tomorrow whether I have a pwc camera or not. I'll get back to you on this. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
omap2 camera
Hi list, I am using OMAP2430 board and I wanted to test camera module on that board. I am using latest 2.6.33 kernel. However, it looks like camera module is not supported with latest kernel. Anyone is having any idea? Also, do we require to have ex3691 sensor driver in mainline kernel in order to get omap24xxcam working ? These are the steps I followed, 1. make omap2430_sdp_defconfig 2. Enable omap2 camera option which is under drivers/media/video 3. make uImage And with this uImage, camera is not working. I would appreciate any help. Thanks, Viral This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. __ -- 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
Questions to ngene/dvb_frontend driver [Original email was "Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)"]
Hi, I read the problems described in email thread "Problems with ngene based DVB cards (Digital Devices Cine S2 Dual DVB-S2 , Mystique SaTiX S2 Dual)". Unfortunately, I just subscribed to this list so I cannot respond to the original mail directly but it can be found at the end of this mail. For tracking down the described problems with high delays, I tried to understand the dvb_frontend and ngene driver and added some output messages. The added output messages are attached as a ptach to this email. Since this was the first time I read the source code of the module I was not able to find a real problem or bug. However, I found 3 issues that I would like to report. Especially issue 1) could be a problem. Here the irq handler of ngene module is still triggered for 60secs if the last application using the DVB devices terminates. In Issue 2) I describe the methods that need more time when the described problem occur. Unfortunately, I could only determine that these methods need more time but was not able to find a reason. Issue 3) could be related to issue 1). Here I saw that the ngene module is not informed if the DVB frontend device is closed. Again, since I read the source code of a driver for the first time I don't know if the described issues are OK or not. It would be great if some of you could check the described issues. Maybe this information helps to find/solve the problem. Thanks in advance Michael Repplinger Testsystem: -Kernel: 2.6.25.20-0.5-pae (Suse 11.0 distribution) -Driver: following endriss/ngene DVB driver + attached patch *Repository URL : http://linuxtv.org/hg/~endriss/ngene *Revision : 14413:510e37da759e *Issue 1) IRQ handler is triggered for 60 seconds after last application stops using the dvb device:* Reproduce Test: a) load dvb modules as follows: rmmod ngene rmmod dvb_core modprobe dvb_core dvbdev_debug=1 frontend_debug=1 debug=1 cam_debug=1 dvb_demux_tscheck=1 dvb_net_debug=1 modprobe ngene debug=1 one_adapter=0 b) tail -f /var/log/messages c) In parallel to b) start ./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x *Observation 1: * In b) one can see the following output messages: Mar 20 14:18:01 dvb_host kernel: ngene>: irq_handler IRQ 16 Mar 20 14:18:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:18:01 dvb_host kernel: ngene: demux_tasklet Mar 20 14:18:01 dvb_host kernel: ngene: tsin_exchange => The following mehtods of ngene-core.c are called - static irqreturn_t irq_handler(int irq, void *dev_id) ( produces the first two lines of the above output messages) - static void demux_tasklet(unsigned long data) ( produces the third lines of the above output messages) - static void *tsin_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags) (procudes the last output message) => IRQ handler of ngene-core module is periodically triggered as soon as the first application using DVB device has been used *Observation 2: * Exactly 60 seconds after executing c), the IRQ handler is no longer triggered and no more output messages appear in b). Here the last output messages are: Mar 20 14:19:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:19:01 dvb_host kernel: ngene: demux_tasklet Mar 20 14:19:01 dvb_host kernel: ngene: tsin_exchange Mar 20 14:19:01 dvb_host kernel: ngene: ngene_i2c_master_xfer Mar 20 14:19:01 dvb_host kernel: ngene: > ngene_i2x_set_bus Mar 20 14:19:01 dvb_host kernel: ngene: ngene_i2c_set_bus Mar 20 14:19:01 dvb_host kernel: ngene: < ngene_i2x_set_bus Mar 20 14:19:01 dvb_host kernel: ngene: num = 1 ngene_command_i2c_write Mar 20 14:19:01 dvb_host kernel: ngene: ngene_command_i2c_write Mar 20 14:19:01 dvb_host kernel: ngene: ngene_command Mar 20 14:19:01 dvb_host kernel: ngene: ngene_command_mutex Mar 20 14:19:01 dvb_host kernel: ngene>: irq_handler IRQ 16 Mar 20 14:19:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:19:01 dvb_host kernel: ngene>: irq_handler IRQ 16 Mar 20 14:19:01 dvb_host kernel: ngene< : irq_handler return IRQ_HANDLED Mar 20 14:19:01 dvb_host kernel: ngene: ngene_i2c_master_xfer succeeded => In this case, the mehtod ngene_i2c_master_xfer is invoked and successfully processed (additional invoked methods can also be seen from the output). *Conclusion: * Since I dont understand whats going on here, I don't know if this is correct or could cause problems. However, I would expect that the IRQ handler is not triggered, if no application accesses the DVB device. Moreover, after 60 seconds the IRQ trigger is no longer triggered. This looks like the kernel (or any other module) stops the ngene-module. *Issue 2) High delay ~(1.7-18 seconds) when switching the channel * By enabling and adding additional output messages in used dvb modules, I was able to find the mehtod that causes a higher delay. Reproduce Test: a) load dvb modules as follows: rmmod ngene rmmod dvb_core modprobe dvb_core dvbdev_debug=1 frontend_debug=1 debug=
Re: [PATCH] V4L/DVB: saa7146: IRQF_DISABLED causes only trouble
Andy Walls writes: > On Sun, 2010-03-21 at 21:08 +0100, Bjørn Mork wrote: >> As discussed many times, e.g. in http://lkml.org/lkml/2007/7/26/401 >> mixing IRQF_DISABLED with IRQF_SHARED just doesn't make sense. >> >> Remove IRQF_DISABLED to avoid random unexpected behaviour. >> >> Ever since I started using the saa7146 driver, I've had occasional >> soft lockups. I do not have any real evidence that the saa7146 >> driver is the cause, but the lockups are gone after removing the >> IRQF_DISABLED flag from this driver. >> >> On my system, this driver shares an irq17 with the pata_jmicron >> driver: >> >> 17: 2115 1060594228448193902 IO-APIC-fasteoi >> pata_jmicron, saa7146 (0) >> >> This may be a mitigating factor. >> >> Signed-off-by: Bjørn Mork >> Cc: sta...@kernel.org > > And here are some more recent discussions: > > http://lkml.org/lkml/2009/11/30/215 > http://lkml.org/lkml/2009/3/2/33 > http://lkml.org/lkml/2009/3/2/225 > http://www.mail-archive.com/ivtv-de...@ivtvdriver.org/msg06319.html > http://www.mail-archive.com/ivtv-de...@ivtvdriver.org/msg06362.html > > And the ones on the LKML seem prettry inconclusive to me. OK, I don't really feel up to arguing against any of those. But the argument seems to be more along the lines of whether the requirement should be always disabled or always enabled. Most people seem to agree that it should be one or the other, and *not* a mix, and hence that the IRQF_DISABLED should go away (but possibly be replaced by disabled as default behaviour). The discussion about which is correct, always disabled or always enabled, is way out of my league. But I believe that current drivers have to adapt to the current kernel default, and that is always enabled. The patch in http://lkml.org/lkml/2009/3/2/33 might be the correct solution eventually, but attempting to implement this in a handful drivers is not going to work. By using IRQF_DISABLED you are only triggering the bugs which makes Linus hesitate to take that patch, in a very random and rather undebuggable way. That's not good. To quote one of Linus' followups to http://lkml.org/lkml/2009/3/2/33 (in http://lkml.org/lkml/2009/3/2/186): "The whole - and only - point is that there are drivers that are _known_ to require non-IRQF_DISABLED semantics. IDE is one such one." *This* is what makes using IRQF_SHARED || IRQF_DISABLED risky, IMHO. You can't currently guarantee that you don't share the line with one of those drivers. > If the saa7146 driver was registered second, then this change should > have no effect on your system. > > If the saa7146 driver was registered first, then this can cause the > saa7146 driver's interrupt handler to be interrupted. I doubt the > saa7146 driver is prepared for this contingency. > > I doubt that this is the "proper" fix for your problem. No, maybe it's not. But doesn't the fact that you can't predict the actual effect of the IRQF_DISABLED flag tell you that using it is wrong? Removing it will at least provide a predictable outcome. The problem you miss above is how the other drivers sharing this interrupt will deal with the, to them, unexpected occasional disabled interrupts. How the heck do you ensure that they can handle it? I assume the real fix would be to ensure that the saa7146 interrupt handler can be interrupted. I have no idea how to to that. Do you know why it can't be interrupted? It doesn't look particularily uninterruptable to me. And as you say: It will be interrupted even with the IRQF_DISABLED flag. The alternative to making ensure that the saa7146 interrupt handler can be interrupted is really not keeping IRQF_DISABLED, but - making sure that *every* interrupt handler in the kernel can run with interrupts disabled, and - change the default to running with interrupts disabled I believe it's easier to modify the saa7146 driver... > Does the "soft lockup" put an Oops or BUG message in dmesg > or /var/log/messages? > > What precisely do you mean by "soft lockup"? I mean CPU cores getting stuck, like: Mar 20 01:02:56 canardo kernel: [96555.15] BUG: soft lockup - CPU#0 stuck for 61s! [lmcoretemp:7424] Mar 20 01:02:56 canardo kernel: [96603.480497] BUG: soft lockup - CPU#1 stuck for 61s! [kswapd0:47] Mar 20 01:02:56 canardo kernel: [96603.480999] BUG: soft lockup - CPU#2 stuck for 61s! [rndc:9119] Mar 20 01:02:56 canardo kernel: [96620.659996] BUG: soft lockup - CPU#0 stuck for 61s! [lmcoretemp:7424] Mar 20 01:02:56 canardo kernel: [96668.976496] BUG: soft lockup - CPU#1 stuck for 61s! [kswapd0:47] Mar 20 01:02:56 canardo kernel: [96668.976995] BUG: soft lockup - CPU#2 stuck for 61s! [rndc:9119] Mar 20 01:02:56 canardo kernel: [96686.159997] BUG: soft lockup - CPU#0 stuck for 61s! [lmcoretemp:7424] As the syslogging is local, you can't really trust syslog's timestamp. But the kernel timestamps should be accurate. The incident above started with Mar 20 01:02:56 canardo kernel: [96513.561007] saa71
Re: RFC: Phase 1: Proposal to convert V4L1 drivers
Hi, On 03/22/2010 01:17 AM, Hans Verkuil wrote: On Sunday 21 March 2010 23:45:04 Hans Verkuil wrote: On Saturday 20 March 2010 09:58:49 Hans Verkuil wrote: These drivers have no hardware to test with: bw-qcam, c-qcam, arv, w9966. However, all four should be easy to convert to v4l2, even without hardware. Volunteers? I've converted these four drivers to V4L2. I've also removed the V4L1 support from cpia2 and pwc and removed some last V4L1 code remnants from meye and zoran. It's all in the same tree. Hans, could you test the pwc driver for me? Done, And the news is not good I'm afraid, it does not work. I've one interesting observation though. It does work if I first run it once with the "old" version of the driver and then load your version (also replacing videodev.ko, etc with the ones from your tree). But if I plug it in with your driver in place it does not stream (nothing interesting in dmesg). So it seems like an initialization problem. As said the pwc driver needs some love in general, I've seen the same problem (not streaming) with the "old" version when used with machines with UHCI usb controllers (rather then OHCI), such as atom based laptops. So maybe this is some timing issues, and your changes have speed up some path? Note that I've 3 identical pwc cams, I would be more then happy to give you one, let me know how to best get it to you. 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: [PATCH] device_attributes: add sysfs_attr_init() for dynamic attributes
On Sun, Mar 21, 2010 at 11:40:28PM -0700, Dmitry Torokhov wrote: > My standard question - are all of these need to be dynamically > allocated? I have my doubts for a few of them. Still, this would be a more intrusive change than just fixing the BUG appearance, so I'd like to leave that task for those having the proper setup. Regarding thermal_sys.c, which has two bug reports already, it needs to be dynamic as the attribute name depends on the device. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Hi, On 03/22/2010 09:11 AM, Hans Verkuil wrote: On Sunday 21 March 2010 00:14:25 Hans de Goede wrote: Hi, On 03/20/2010 10:21 AM, Hans Verkuil wrote: Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. Yes it can, this for example already happens when using v4l1 apps with uvcvideo (which is not possible without libv4l1). In what way does libv4l1 still depend on the kernel's v4l1 compat layer? It depends on some of the ioctl compatibility stuff, which lives in drivers/media/video/v4l1-compat.c Basically it depends on: v4l_compat_translate_ioctl() From that file and on what that depends on in turn. Note that it does not depend on v4l_compat_translate_ioctl() for all ioctl's. It handles some of them in its own, see: lib/libv4l1/libv4l1.c In v4l-utils git, specifically the v4l1_ioctl() function. Note that simply checking which one are listed in the switch case is not enough to determine which ones are already handled by libv4l, some still call v4l_compat_translate_ioctl() (by doing the v4l1 ioctl) and then munge the results. Currently it is mainly targeted and tested with webcam using apps, so no overlay, input switching, vbi or tuning support. Adding input switching, vbi and tuning support, should be easy I think. Overlay has me worried as the v4l1 API does not clearly separate between overlay and capture. Since overlay does not really work out of the box on any distro's anyways (in my experience), I think the best thing to do would be to just hide the overlay capability for v4l1 apps. Note that the default: case which passes the ioctl through to libv4l2, will end up passing v4l1 ioctl's to the kernel, as libv4l2 will pass unknown ioctl's to the kernel unmodified. > And what is needed to remove that dependency? Someone to: - add emulation of the not yet emulated ioctl's; and - remove the limits of not working on complex devices, see libv4l1.c line 295 (in v4l1_open, marked IMPROVEME */; and - remove the dependency of some already emulated ioctl's on the the kernels v4l_compat_translate_ioctl(), for example the VIDIOCGCAP emulation calls the kernel, then overrides some results. Note that all emulation needs to be re-implemented, not copied from the kernel as the kernel is GPLv2 and libv4l1 LGPLv2+, an alternative approach would be to find out who holds the copyrights and ask them for permission. Because I think that that is the best approach. Ack. 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: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
On Sunday 21 March 2010 00:14:25 Hans de Goede wrote: > Hi, > > On 03/20/2010 10:21 AM, Hans Verkuil wrote: > > Hi all! > > > > The second phase that needs to be done to remove the v4l1 support from the > > kernel is that libv4l1 should replace the v4l1-compat code from the kernel. > > > > I do not know how complete the libv4l1 code is right now. I would like to > > know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in > > libv4l1 if drivers do not support the cgmbuf vidioc call. > > > > Yes it can, this for example already happens when using v4l1 apps with > uvcvideo (which is not possible without libv4l1). In what way does libv4l1 still depend on the kernel's v4l1 compat layer? And what is needed to remove that dependency? Because I think that that is the best approach. > > The third phase that can be done in parallel is to convert V4L1-only apps. > > I strongly suspect that any apps that are V4L1-only are also unmaintained. > > We have discussed before that we should set up git repositories for such > > tools (xawtv being one of the more prominent apps since it contains several > > v4l1-only console apps). Once we have maintainership, then we can convert > > these tools to v4l2 and distros and other interested parties have a place > > to send patches to. > > > > As said before I wouldn't mind maintaining an xawtv git tree @ linuxtv, > assuming this tree were to be based on the 3.95 release. Mauro, do you have any objection to hosting xawtv on linuxtv? We may need another tree later as well if we decide to split off the xawtv console tools into a separate tree. But perhaps they would fit under v4l-utils as well, we'll have to see. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
