Re: [PATCH] viafb camera controller driver
On Tuesday, October 19, 2010 05:20:17 Jonathan Corbet wrote: On Sat, 16 Oct 2010 10:44:56 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: drivers/media/video/via-camera.c: In function ‘viacam_open’: drivers/media/video/via-camera.c:651: error: too few arguments to function ‘videobuf_queue_sg_init’ The fix for this one is trivial: drivers/media/video/via-camera.c:651: error: too few arguments to function ‘videobuf_queue_sg_init’ Just add an extra NULL parameter to the function. So I'm looking into this stuff. The extra NULL parameter is a struct mutex, which seems to be used in one place in videobuf_waiton(): is_ext_locked = q-ext_lock mutex_is_locked(q-ext_lock); /* Release vdev lock to prevent this wait from blocking outside access to the device. */ if (is_ext_locked) mutex_unlock(q-ext_lock); I'd be most curious to know what the reasoning behind this code is; to my uneducated eye, it looks like a real hack. How does this function know who locked ext_lock? Can it really just unlock it safely? It seems to me that this is a sign of locking issues which should really be dealt with elsewhere, but, as I said, I'm uneducated, and the changelogs don't help me much. Can somebody educate me? We are working on removing the BKL. As part of that effort it is now possible for drivers to pass a serialization mutex to the v4l core (a mutex pointer was added to struct video_device). If the core sees that mutex then the core will serialize all open/ioctl/read/write/etc. file ops. So all file ops will in that case be called with that mutex held. Which is fine, but if the driver has to do a blocking wait, then you need to unlock the mutex first and lock it again afterwards. And since videobuf does a blocking wait it needs to know about that mutex. Right now we are in the middle of the transition from BKL to using core locks (and some drivers will do their own locking completely). During this transition period we have drivers that provide an external lock and drivers still relying on the BKL in which case videobuf needs to handle its own locking. Hopefully in 1-2 kernel cycles we will have abolished the BKL and we can remove the videobuf internal lock and use the external mutex only. So yes, it is a bit of a hack but there is actually a plan behind it :-) It's a common theme inside the v4l subsystem, I'm afraid. We are still in the process of creating a fully functional v4l core framework that all drivers can use. But for every new piece of core functionality it means a transition period where drivers are one by one converted to use it. That can take a very long time. Add to that mix all the new functionality that is being added to support embedded video hardware and it can get complex indeed. I have a very clear goal in mind, though, and I (and many others!) are steadily moving closer to that goal. Every kernel release has one or more essential building blocks in place. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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: support for AF9035 (not tuner)
On 10/18/10 22:39, Daniel Glöckner wrote: On Mon, Oct 18, 2010 at 09:46:15PM +0200, Hervé Cauwelier wrote: I've uploaded the compressed installer at http://dl.free.fr/p2BTq9BNi The driver mentiones two video decoders: - TI TVP5150 - Trident AVF4900B/AVF4910B If it is the first one, sniffed USB traffic might be enough to write a driver as there already is one for the decoder. The latter one is undocumented. Two months ago I was told by Trident that the device is not supported as it has been phased out from production. Daniel I managed to open it properly. I see two chips: the AF9035B and the other one is labelled AVF 4910BA1. So is it dead? I couldn't find any datasheet, even to sell. I could only find a commercial 2-page PDF presentation. I doubt you can grab any technical information from it. Do I continue searching for a datasheet? Hervé -- 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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() 1) {
pr_err(i810 no longer supports SMP\n);
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
Arnd
--
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 v13 1/1] Documentation: v4l: Add hw_seek spacing and two TUNER_RDS_CAP flags.
Hi. On Mon, 2010-10-18 at 15:57 +0200, ext Hans Verkuil wrote: Em 18-10-2010 11:17, Hans Verkuil escreveu: Just a few very small comments: +For future use the +flag constantV4L2_TUNER_SUB_RDS_CONTROLS/constant has also been +defined. However, a driver for a radio tuner with this capability does +not yet exist, so if you are planning to write such a driver the best +way to start would probably be by opening a discussion about it on +the linux-media mailing list: v4l-ml;. /para Change to: not yet exist, so if you are planning to write such a driver you should discuss this on the linux-media mailing list: v4l-ml;./para No, please. Don't add any API capabilities at the DocBook without having a driver using it. At the time a driver start needing it, we can just add the API bits and doing the needed discussions as you've proposed. This is already implicit. These caps are shared between tuner and modulator. And for the modulator both caps *are* used in Matti's driver. But while RDS_CONTROLS is available for modulators, it is not yet applicable to tuners and for that we need to make this note in the spec. So this is an exception to the rule, I'm afraid. So it's ACK... or NACK? Cheers, Matti 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 v13 1/1] Documentation: v4l: Add hw_seek spacing and two TUNER_RDS_CAP flags.
Hi. On Mon, 2010-10-18 at 15:57 +0200, ext Hans Verkuil wrote: Em 18-10-2010 11:17, Hans Verkuil escreveu: Just a few very small comments: +For future use the +flag constantV4L2_TUNER_SUB_RDS_CONTROLS/constant has also been +defined. However, a driver for a radio tuner with this capability does +not yet exist, so if you are planning to write such a driver the best +way to start would probably be by opening a discussion about it on +the linux-media mailing list: v4l-ml;. /para Change to: not yet exist, so if you are planning to write such a driver you should discuss this on the linux-media mailing list: v4l-ml;./para No, please. Don't add any API capabilities at the DocBook without having a driver using it. At the time a driver start needing it, we can just add the API bits and doing the needed discussions as you've proposed. This is already implicit. These caps are shared between tuner and modulator. And for the modulator both caps *are* used in Matti's driver. But while RDS_CONTROLS is available for modulators, it is not yet applicable to tuners and for that we need to make this note in the spec. So this is an exception to the rule, I'm afraid. So it's ACK... or NACK? ACK from me :-) Regards, Hans Cheers, Matti 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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] viafb camera controller driver
Hi Hans, On Tuesday 19 October 2010 08:54:40 Hans Verkuil wrote: On Tuesday, October 19, 2010 05:20:17 Jonathan Corbet wrote: On Sat, 16 Oct 2010 10:44:56 -0300 Mauro Carvalho Chehab wrote: drivers/media/video/via-camera.c: In function ‘viacam_open’: drivers/media/video/via-camera.c:651: error: too few arguments to function ‘videobuf_queue_sg_init’ The fix for this one is trivial: drivers/media/video/via-camera.c:651: error: too few arguments to function ‘videobuf_queue_sg_init’ Just add an extra NULL parameter to the function. So I'm looking into this stuff. The extra NULL parameter is a struct mutex, which seems to be used in one place in videobuf_waiton(): is_ext_locked = q-ext_lock mutex_is_locked(q-ext_lock); /* Release vdev lock to prevent this wait from blocking outside access to the device. */ if (is_ext_locked) mutex_unlock(q-ext_lock); I'd be most curious to know what the reasoning behind this code is; to my uneducated eye, it looks like a real hack. How does this function know who locked ext_lock? Can it really just unlock it safely? It seems to me that this is a sign of locking issues which should really be dealt with elsewhere, but, as I said, I'm uneducated, and the changelogs don't help me much. Can somebody educate me? We are working on removing the BKL. As part of that effort it is now possible for drivers to pass a serialization mutex to the v4l core (a mutex pointer was added to struct video_device). If the core sees that mutex then the core will serialize all open/ioctl/read/write/etc. file ops. So all file ops will in that case be called with that mutex held. Which is fine, but if the driver has to do a blocking wait, then you need to unlock the mutex first and lock it again afterwards. And since videobuf does a blocking wait it needs to know about that mutex. Right now we are in the middle of the transition from BKL to using core locks (and some drivers will do their own locking completely). During this transition period we have drivers that provide an external lock and drivers still relying on the BKL in which case videobuf needs to handle its own locking. Hopefully in 1-2 kernel cycles we will have abolished the BKL and we can remove the videobuf internal lock and use the external mutex only. So yes, it is a bit of a hack but there is actually a plan behind it :-) I still believe drivers should be encouraged to handle locking on their own. These new big v4l lock (one per device) should be used only to remove the BKL in existing drivers. It's a hack that we should work on getting rid of. It's a common theme inside the v4l subsystem, I'm afraid. We are still in the process of creating a fully functional v4l core framework that all drivers can use. But for every new piece of core functionality it means a transition period where drivers are one by one converted to use it. That can take a very long time. Add to that mix all the new functionality that is being added to support embedded video hardware and it can get complex indeed. I have a very clear goal in mind, though, and I (and many others!) are steadily moving closer to that goal. Every kernel release has one or more essential building blocks in place. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.37] gspca for_2.6.37
The following changes since commit 350df81ebaccc651fa4dfad27738db958e067ded: Revert changeset d455b639c1fb09f8ea888371fb6e04b490e115fb (2010-10-17 19:32:45 -0200) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.37 Jean-François Moine (1): gspca: Fix coding style issues Németh Márton (2): gspca - sonixj: Remove magic numbers for delay gspca - sonixj: Add horizontal and vertical flip for po2030n drivers/media/video/gspca/benq.c |3 +- drivers/media/video/gspca/conex.c |6 +- drivers/media/video/gspca/etoms.c |4 +- drivers/media/video/gspca/gl860/gl860-mi2020.c |6 +- drivers/media/video/gspca/gspca.c |2 +- drivers/media/video/gspca/konica.c |4 +- drivers/media/video/gspca/m5602/m5602_mt9m111.c| 48 drivers/media/video/gspca/m5602/m5602_mt9m111.h| 14 +-- drivers/media/video/gspca/m5602/m5602_ov7660.c | 70 +- drivers/media/video/gspca/m5602/m5602_ov7660.h |9 +- drivers/media/video/gspca/m5602/m5602_ov9650.c | 102 drivers/media/video/gspca/m5602/m5602_ov9650.h | 12 +- drivers/media/video/gspca/m5602/m5602_po1030.c | 136 ++-- drivers/media/video/gspca/m5602/m5602_po1030.h | 13 +- drivers/media/video/gspca/m5602/m5602_s5k4aa.c | 28 ++-- drivers/media/video/gspca/m5602/m5602_s5k4aa.h | 14 +-- drivers/media/video/gspca/m5602/m5602_s5k83a.h | 12 +- drivers/media/video/gspca/ov519.c | 18 +-- drivers/media/video/gspca/pac207.c |2 +- drivers/media/video/gspca/pac7302.c|3 +- drivers/media/video/gspca/pac7311.c|3 +- drivers/media/video/gspca/sn9c20x.c| 13 ++- drivers/media/video/gspca/sonixb.c |9 +- drivers/media/video/gspca/sonixj.c | 111 +++- drivers/media/video/gspca/spca501.c|6 +- drivers/media/video/gspca/spca508.c|3 +- drivers/media/video/gspca/stv06xx/stv06xx.h|2 +- drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c | 19 ++-- drivers/media/video/gspca/stv06xx/stv06xx_hdcs.h |2 +- drivers/media/video/gspca/stv06xx/stv06xx_vv6410.c |2 +- drivers/media/video/gspca/stv06xx/stv06xx_vv6410.h |4 +- drivers/media/video/gspca/sunplus.c|9 +- drivers/media/video/gspca/w996Xcf.c|2 +- drivers/media/video/gspca/zc3xx.c | 14 +-- 34 files changed, 359 insertions(+), 346 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: support for AF9035 (not tuner)
On 10/19/10 09:13, Hervé Cauwelier wrote: Do I continue searching for a datasheet? After a night searching, the only so-called datasheet I find is this commercial presentation: http://www.datasheetarchive.com/pdf-datasheets/Datasheets-13/DSA-256708.html I asked several resellers but those kind enough to reply me sent me the same file. I doubt any of you can find enough technical data to understand how to address the chip. Hervé -- 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] viafb camera controller driver
Em 19-10-2010 05:52, Laurent Pinchart escreveu: Hi Hans, On Tuesday 19 October 2010 08:54:40 Hans Verkuil wrote: On Tuesday, October 19, 2010 05:20:17 Jonathan Corbet wrote: On Sat, 16 Oct 2010 10:44:56 -0300 Mauro Carvalho Chehab wrote: drivers/media/video/via-camera.c: In function ‘viacam_open’: drivers/media/video/via-camera.c:651: error: too few arguments to function ‘videobuf_queue_sg_init’ The fix for this one is trivial: drivers/media/video/via-camera.c:651: error: too few arguments to function ‘videobuf_queue_sg_init’ Just add an extra NULL parameter to the function. So I'm looking into this stuff. The extra NULL parameter is a struct mutex, which seems to be used in one place in videobuf_waiton(): is_ext_locked = q-ext_lock mutex_is_locked(q-ext_lock); /* Release vdev lock to prevent this wait from blocking outside access to the device. */ if (is_ext_locked) mutex_unlock(q-ext_lock); I'd be most curious to know what the reasoning behind this code is; to my uneducated eye, it looks like a real hack. How does this function know who locked ext_lock? Can it really just unlock it safely? It seems to me that this is a sign of locking issues which should really be dealt with elsewhere, but, as I said, I'm uneducated, and the changelogs don't help me much. Can somebody educate me? We are working on removing the BKL. As part of that effort it is now possible for drivers to pass a serialization mutex to the v4l core (a mutex pointer was added to struct video_device). If the core sees that mutex then the core will serialize all open/ioctl/read/write/etc. file ops. So all file ops will in that case be called with that mutex held. Which is fine, but if the driver has to do a blocking wait, then you need to unlock the mutex first and lock it again afterwards. And since videobuf does a blocking wait it needs to know about that mutex. Right now we are in the middle of the transition from BKL to using core locks (and some drivers will do their own locking completely). During this transition period we have drivers that provide an external lock and drivers still relying on the BKL in which case videobuf needs to handle its own locking. Hopefully in 1-2 kernel cycles we will have abolished the BKL and we can remove the videobuf internal lock and use the external mutex only. So yes, it is a bit of a hack but there is actually a plan behind it :-) I still believe drivers should be encouraged to handle locking on their own. These new big v4l lock (one per device) should be used only to remove the BKL in existing drivers. It's a hack that we should work on getting rid of. It is not a big lock: it doesn't stop other CPU's, doesn't affect other hardware, not even another V4L device. Basically, what this new lock does is to serialize access to the hardware and to the hardware-mirrored data. On several cases, if you serialize open, close, ioctl, read, write and mmap, the hardware will be serialized. Of course, this doesn't cover 100% of the cases where a lock is needed. So, if the driver have more fun things like kthreads, alsa, dvb, IR polling, etc, the driver will need to lock on other places as well. A typical V4L driver has lots of functions that need locking: open, close, read, write, mmap and almost all ioctl (depending on the driver, just a very few set of enum ioctl's could eventually not need an ioctl). What we found is that: 1) several developers didn't do the right thing since the beginning; 2) as time goes by, locks got bit roted. 3) some drivers were needing to touch on several locks (videobuf, their internal priv locks, etc), sometimes generating cases where a dead lock would be possible. On the tests we did so far, the v4l-core assisted lock helped to solve some locking issues on the very few drivers that were ported. Also, it caused a regression on a driver where the lock were working ;) There are basically several opinions about this new schema: some that think that this is the right thing to do, others think that think that this is the wrong thing or that this is acceptable only as a transition for BKL-free drivers. IMO, I think that both ways are acceptable: a core-assisted hardware-access lock helps to avoid having lots of lock/unlock code at the driver, making drivers cleaner and easier to review, and reducing the risk of lock degradation with time. On the other hand, some drivers may require more complex locking schemas, like, for example, devices that support several simultaneous independent video streams may have some common parts used by all streams that need to be serialized, and other parts that can (and should) not be serialized. So, a core-assisted locking for some cases may cause unneeded long waits. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
Re: [GIT PATCHES FOR 2.6.36] gspca for_2.6.36
Em 19-10-2010 07:20, Antonio Ospite escreveu: On Fri, 15 Oct 2010 09:41:48 +0200 Antonio Ospite osp...@studenti.unina.it wrote: On Sun, 10 Oct 2010 13:24:47 +0200 Jean-Francois Moine moin...@free.fr wrote: The following changes since commit d65728875a85ac7c8b7d6eb8d51425bacc188980: V4L/DVB: v4l: radio: si470x: fix unneeded free_irq() call (2010-09-30 07:35:12 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.36 Jean-François Moine (1): gspca - main: Fix a regression with the PS3 Eye webcam Hi, this is not in 2.6.36-rc8, any chance we can make it for 2.6.36? Ping. The patch is in the today's linux-next tree. I added it together with another patch for 2.6.36 (they are on a separate brancho on my local tree). If everything wents well, it is likely that we'll have time to add it for 2.6.36. 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: [PATCH 1/1] OMAP3: V4L2: Kconfig changes to enable V4L2 options on OMAP3
-Original Message- From: Hiremath, Vaibhav Sent: Tuesday, October 19, 2010 9:40 AM To: Nilofer, Samreen Cc: linux-media@vger.kernel.org Subject: RE: [PATCH 1/1] OMAP3: V4L2: Kconfig changes to enable V4L2 options on OMAP3 -Original Message- From: Nilofer, Samreen Sent: Monday, October 18, 2010 9:32 AM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org; Nilofer, Samreen Subject: [PATCH 1/1] OMAP3: V4L2: Kconfig changes to enable V4L2 options on OMAP3 The defconfig options for V4L2 are taken in the respective Kconfig to enable V4L2 by default on OMAP3 platforms Signed-off-by: Samreen samr...@ti.com --- drivers/media/Kconfig|2 ++ drivers/media/video/omap/Kconfig |2 +- 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index a28541b..2592d88 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -5,6 +5,7 @@ menuconfig MEDIA_SUPPORT tristate Multimedia support depends on HAS_IOMEM + default y if ARCH_OMAP2 || ARCH_OMAP3 [Hiremath, Vaibhav] I am quite not sure whether this is right approach to do this, I think adding dependency of ARCH_ here will pollute the file. Why not add this definition to omap2plus_defconfig, which is common defconfig file for all OMAP architecture. Thanks, Vaibhav [Samreen] I was not aware of the fact that the defconfig could be modified.. Will incorporate the changes and will post them soon. -Regards, Samreen help If you want to use Video for Linux, DVB for Linux, or DAB adapters, enable this option and other options below. @@ -19,6 +20,7 @@ comment Multimedia core support config VIDEO_DEV tristate Video For Linux + default y if ARCH_OMAP2 || ARCH_OMAP3 ---help--- V4L core support for video capture and overlay devices, webcams and AM/FM radio cards. diff --git a/drivers/media/video/omap/Kconfig b/drivers/media/video/omap/Kconfig index e63233f..f3e33c3 100644 --- a/drivers/media/video/omap/Kconfig +++ b/drivers/media/video/omap/Kconfig @@ -6,6 +6,6 @@ config VIDEO_OMAP2_VOUT select OMAP2_DSS select OMAP2_VRAM select OMAP2_VRFB - default n + default y ---help--- V4L2 Display driver support for OMAP2/3 based boards. -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] OMAP3: V4L2: Kconfig changes to enable V4L2 options on OMAP3
-Original Message- From: Nilofer, Samreen Sent: Tuesday, October 19, 2010 5:38 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org Subject: RE: [PATCH 1/1] OMAP3: V4L2: Kconfig changes to enable V4L2 options on OMAP3 -Original Message- From: Hiremath, Vaibhav Sent: Tuesday, October 19, 2010 9:40 AM To: Nilofer, Samreen Cc: linux-media@vger.kernel.org Subject: RE: [PATCH 1/1] OMAP3: V4L2: Kconfig changes to enable V4L2 options on OMAP3 -Original Message- From: Nilofer, Samreen Sent: Monday, October 18, 2010 9:32 AM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org; Nilofer, Samreen Subject: [PATCH 1/1] OMAP3: V4L2: Kconfig changes to enable V4L2 options on OMAP3 The defconfig options for V4L2 are taken in the respective Kconfig to enable V4L2 by default on OMAP3 platforms Signed-off-by: Samreen samr...@ti.com --- drivers/media/Kconfig|2 ++ drivers/media/video/omap/Kconfig |2 +- 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index a28541b..2592d88 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -5,6 +5,7 @@ menuconfig MEDIA_SUPPORT tristate Multimedia support depends on HAS_IOMEM + default y if ARCH_OMAP2 || ARCH_OMAP3 [Hiremath, Vaibhav] I am quite not sure whether this is right approach to do this, I think adding dependency of ARCH_ here will pollute the file. Why not add this definition to omap2plus_defconfig, which is common defconfig file for all OMAP architecture. Thanks, Vaibhav [Samreen] I was not aware of the fact that the defconfig could be modified.. Will incorporate the changes and will post them soon. [Hiremath, Vaibhav] Please cc linux-omap mailing list, since all arch patches should go through it. Thanks, Vaibhav -Regards, Samreen help If you want to use Video for Linux, DVB for Linux, or DAB adapters, enable this option and other options below. @@ -19,6 +20,7 @@ comment Multimedia core support config VIDEO_DEV tristate Video For Linux + default y if ARCH_OMAP2 || ARCH_OMAP3 ---help--- V4L core support for video capture and overlay devices, webcams and AM/FM radio cards. diff --git a/drivers/media/video/omap/Kconfig b/drivers/media/video/omap/Kconfig index e63233f..f3e33c3 100644 --- a/drivers/media/video/omap/Kconfig +++ b/drivers/media/video/omap/Kconfig @@ -6,6 +6,6 @@ config VIDEO_OMAP2_VOUT select OMAP2_DSS select OMAP2_VRAM select OMAP2_VRFB - default n + default y ---help--- V4L2 Display driver support for OMAP2/3 based boards. -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() 1) {
pr_err(i810 no longer supports SMP\n);
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
I think we also need to cover the PREEMPT case too. But that could be a
compile time check, since you can't boot a preempt kernel and make it
non preempt.
-- Steve
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] stb0899: Removed an extra byte sent at init on DiSEqC bus
On 06/11/2010 06:01 PM, Florent AUDEBERT wrote: I noticed a stray 0x00 at init on DiSEqC bus (KNC1 DVB-S2) with a DiSEqC tool analyzer. I removed the register from initialization table and all seem to go well (at least for my KNC board). Hi, This old small patch had been marked superseded on patchwork[1]. Is there an non-obvious case when patches go superseded ? Perhaps I missed something but it seems to me no other patch replaced it. Regards, [1] https://patchwork.kernel.org/patch/105621/ -- Florent AUDEBERT -- 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] viafb camera controller driver
Hi Mauro, On Tuesday 19 October 2010 12:46:11 Mauro Carvalho Chehab wrote: Em 19-10-2010 05:52, Laurent Pinchart escreveu: On Tuesday 19 October 2010 08:54:40 Hans Verkuil wrote: On Tuesday, October 19, 2010 05:20:17 Jonathan Corbet wrote: On Sat, 16 Oct 2010 10:44:56 -0300 Mauro Carvalho Chehab wrote: drivers/media/video/via-camera.c: In function ‘viacam_open’: drivers/media/video/via-camera.c:651: error: too few arguments to function ‘videobuf_queue_sg_init’ The fix for this one is trivial: drivers/media/video/via-camera.c:651: error: too few arguments to function ‘videobuf_queue_sg_init’ Just add an extra NULL parameter to the function. So I'm looking into this stuff. The extra NULL parameter is a struct mutex, which seems to be used in one place in videobuf_waiton(): is_ext_locked = q-ext_lock mutex_is_locked(q-ext_lock); /* Release vdev lock to prevent this wait from blocking outside access to the device. */ if (is_ext_locked) mutex_unlock(q-ext_lock); I'd be most curious to know what the reasoning behind this code is; to my uneducated eye, it looks like a real hack. How does this function know who locked ext_lock? Can it really just unlock it safely? It seems to me that this is a sign of locking issues which should really be dealt with elsewhere, but, as I said, I'm uneducated, and the changelogs don't help me much. Can somebody educate me? We are working on removing the BKL. As part of that effort it is now possible for drivers to pass a serialization mutex to the v4l core (a mutex pointer was added to struct video_device). If the core sees that mutex then the core will serialize all open/ioctl/read/write/etc. file ops. So all file ops will in that case be called with that mutex held. Which is fine, but if the driver has to do a blocking wait, then you need to unlock the mutex first and lock it again afterwards. And since videobuf does a blocking wait it needs to know about that mutex. Right now we are in the middle of the transition from BKL to using core locks (and some drivers will do their own locking completely). During this transition period we have drivers that provide an external lock and drivers still relying on the BKL in which case videobuf needs to handle its own locking. Hopefully in 1-2 kernel cycles we will have abolished the BKL and we can remove the videobuf internal lock and use the external mutex only. So yes, it is a bit of a hack but there is actually a plan behind it :-) I still believe drivers should be encouraged to handle locking on their own. These new big v4l lock (one per device) should be used only to remove the BKL in existing drivers. It's a hack that we should work on getting rid of. It is not a big lock: it doesn't stop other CPU's, doesn't affect other hardware, not even another V4L device. Basically, what this new lock does is to serialize access to the hardware and to the hardware-mirrored data. The lock serializes all ioctls. That's much more than protecting access to data (both in system memory and in the hardware). On several cases, if you serialize open, close, ioctl, read, write and mmap, the hardware will be serialized. Of course, this doesn't cover 100% of the cases where a lock is needed. So, if the driver have more fun things like kthreads, alsa, dvb, IR polling, etc, the driver will need to lock on other places as well. A typical V4L driver has lots of functions that need locking: open, close, read, write, mmap and almost all ioctl (depending on the driver, just a very few set of enum ioctl's could eventually not need an ioctl). What we found is that: 1) several developers didn't do the right thing since the beginning; That's not a valid reason to push new drivers for a very coarse grain locking scheme. Developers must not get told to be stupid and don't care about locks just because other developers got it wrong in the past. If people don't get locking right we need to educate them, not encourage them to understand even less of it. 2) as time goes by, locks got bit roted. 3) some drivers were needing to touch on several locks (videobuf, their internal priv locks, etc), sometimes generating cases where a dead lock would be possible. On the tests we did so far, the v4l-core assisted lock helped to solve some locking issues on the very few drivers that were ported. Also, it caused a regression on a driver where the lock were working ;) There are basically several opinions about this new schema: some that think that this is the right thing to do, others think that think that this is the wrong thing or that this is acceptable only as a transition for BKL-free drivers. Indeed, and I belong to the second group. IMO, I think that both ways are acceptable: a core-assisted hardware-access lock helps to avoid having lots of
Re: [PATCH] ov7670: fix QVGA visible area
On Mon, 18 Oct 2010 22:07:36 +0100 (BST) Daniel Drake d...@laptop.org wrote: The QVGA mode has a green horizontal line on the left hand side, and a red (or sometimes blue) vertical line at the bottom. Tweak the visible area to remove them. Looks good to me - lots better than removing the mode! Acked-by: Jonathan Corbet cor...@lwn.net jon -- 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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tuesday 19 October 2010, Arnd Bergmann wrote:
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() 1) {
pr_err(i810 no longer supports SMP\n);
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
Some research showed that Intel never support i810/i815 SMP setups,
but there was indeed one company (http://www.acorpusa.com at the time,
now owned by a domain squatter) that made i815E based dual Pentium-III
boards like this one: http://cgi.ebay.com/280319795096
The first person that can send me an authentic log file showing the
use of X.org with DRM on a 2.6.35 kernel with two processors on that
mainboard dated today or earlier gets a free upgrade to an AGP graphics
card of comparable or better 3D performance from me. Please include
the story how why you are running this machine with a new kernel.
i830 is harder, apparently some i865G boards support Pentium 4 with HT
and even later dual-core processors.
Arnd
--
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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 08:39:58AM -0400, Steven Rostedt wrote:
On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
I might be able to find some hardware still lying around here that uses
an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the
user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() 1) {
pr_err(i810 no longer supports SMP\n);
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
I think we also need to cover the PREEMPT case too. But that could be a
compile time check, since you can't boot a preempt kernel and make it
non preempt.
There are enough nameless embedded vendors that have turned a preempt
kernel in to a non-preempt one at run-time by leaking the preempt count,
whether by design or not, so it's certainly possile :-)
--
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] viafb camera controller driver
Hi Laurent, Hi Mauro, On Tuesday 19 October 2010 12:46:11 Mauro Carvalho Chehab wrote: Em 19-10-2010 05:52, Laurent Pinchart escreveu: On Tuesday 19 October 2010 08:54:40 Hans Verkuil wrote: On Tuesday, October 19, 2010 05:20:17 Jonathan Corbet wrote: On Sat, 16 Oct 2010 10:44:56 -0300 Mauro Carvalho Chehab wrote: drivers/media/video/via-camera.c: In function viacam_open: drivers/media/video/via-camera.c:651: error: too few arguments to function videobuf_queue_sg_init The fix for this one is trivial: drivers/media/video/via-camera.c:651: error: too few arguments to function videobuf_queue_sg_init Just add an extra NULL parameter to the function. So I'm looking into this stuff. The extra NULL parameter is a struct mutex, which seems to be used in one place in videobuf_waiton(): is_ext_locked = q-ext_lock mutex_is_locked(q-ext_lock); /* Release vdev lock to prevent this wait from blocking outside access to the device. */ if (is_ext_locked) mutex_unlock(q-ext_lock); I'd be most curious to know what the reasoning behind this code is; to my uneducated eye, it looks like a real hack. How does this function know who locked ext_lock? Can it really just unlock it safely? It seems to me that this is a sign of locking issues which should really be dealt with elsewhere, but, as I said, I'm uneducated, and the changelogs don't help me much. Can somebody educate me? We are working on removing the BKL. As part of that effort it is now possible for drivers to pass a serialization mutex to the v4l core (a mutex pointer was added to struct video_device). If the core sees that mutex then the core will serialize all open/ioctl/read/write/etc. file ops. So all file ops will in that case be called with that mutex held. Which is fine, but if the driver has to do a blocking wait, then you need to unlock the mutex first and lock it again afterwards. And since videobuf does a blocking wait it needs to know about that mutex. Right now we are in the middle of the transition from BKL to using core locks (and some drivers will do their own locking completely). During this transition period we have drivers that provide an external lock and drivers still relying on the BKL in which case videobuf needs to handle its own locking. Hopefully in 1-2 kernel cycles we will have abolished the BKL and we can remove the videobuf internal lock and use the external mutex only. So yes, it is a bit of a hack but there is actually a plan behind it :-) I still believe drivers should be encouraged to handle locking on their own. These new big v4l lock (one per device) should be used only to remove the BKL in existing drivers. It's a hack that we should work on getting rid of. It is not a big lock: it doesn't stop other CPU's, doesn't affect other hardware, not even another V4L device. Basically, what this new lock does is to serialize access to the hardware and to the hardware-mirrored data. The lock serializes all ioctls. That's much more than protecting access to data (both in system memory and in the hardware). Absolutely correct. That's exactly what this lock does. Serializing all this makes it much easier to prove that a driver is correctly locking everything. For 90% of all our drivers this is all that is needed. Yes, it is at a coarser level than the theoretical optimum, but basically, who cares? For that 90% it is simply sufficient and without any performance penalties. On several cases, if you serialize open, close, ioctl, read, write and mmap, the hardware will be serialized. Of course, this doesn't cover 100% of the cases where a lock is needed. So, if the driver have more fun things like kthreads, alsa, dvb, IR polling, etc, the driver will need to lock on other places as well. A typical V4L driver has lots of functions that need locking: open, close, read, write, mmap and almost all ioctl (depending on the driver, just a very few set of enum ioctl's could eventually not need an ioctl). What we found is that: 1) several developers didn't do the right thing since the beginning; That's not a valid reason to push new drivers for a very coarse grain locking scheme. Developers must not get told to be stupid and don't care about locks just because other developers got it wrong in the past. If people don't get locking right we need to educate them, not encourage them to understand even less of it. Locking is hard in complex drivers. Period. 2) as time goes by, locks got bit roted. 3) some drivers were needing to touch on several locks (videobuf, their internal priv locks, etc), sometimes generating cases where a dead lock would be possible. On the tests we did so far, the v4l-core assisted lock helped to solve some locking issues on the very few drivers that were ported. Also, it caused a regression on a driver where the
Re: [PATCH] viafb camera controller driver
Hi Laurent, Hi Mauro, On Tuesday 19 October 2010 12:46:11 Mauro Carvalho Chehab wrote: Em 19-10-2010 05:52, Laurent Pinchart escreveu: On Tuesday 19 October 2010 08:54:40 Hans Verkuil wrote: On Tuesday, October 19, 2010 05:20:17 Jonathan Corbet wrote: On Sat, 16 Oct 2010 10:44:56 -0300 Mauro Carvalho Chehab wrote: drivers/media/video/via-camera.c: In function viacam_open: drivers/media/video/via-camera.c:651: error: too few arguments to function videobuf_queue_sg_init The fix for this one is trivial: drivers/media/video/via-camera.c:651: error: too few arguments to function videobuf_queue_sg_init Just add an extra NULL parameter to the function. So I'm looking into this stuff. The extra NULL parameter is a struct mutex, which seems to be used in one place in videobuf_waiton(): is_ext_locked = q-ext_lock mutex_is_locked(q-ext_lock); /* Release vdev lock to prevent this wait from blocking outside access to the device. */ if (is_ext_locked) mutex_unlock(q-ext_lock); I'd be most curious to know what the reasoning behind this code is; to my uneducated eye, it looks like a real hack. How does this function know who locked ext_lock? Can it really just unlock it safely? It seems to me that this is a sign of locking issues which should really be dealt with elsewhere, but, as I said, I'm uneducated, and the changelogs don't help me much. Can somebody educate me? We are working on removing the BKL. As part of that effort it is now possible for drivers to pass a serialization mutex to the v4l core (a mutex pointer was added to struct video_device). If the core sees that mutex then the core will serialize all open/ioctl/read/write/etc. file ops. So all file ops will in that case be called with that mutex held. Which is fine, but if the driver has to do a blocking wait, then you need to unlock the mutex first and lock it again afterwards. And since videobuf does a blocking wait it needs to know about that mutex. Right now we are in the middle of the transition from BKL to using core locks (and some drivers will do their own locking completely). During this transition period we have drivers that provide an external lock and drivers still relying on the BKL in which case videobuf needs to handle its own locking. Hopefully in 1-2 kernel cycles we will have abolished the BKL and we can remove the videobuf internal lock and use the external mutex only. So yes, it is a bit of a hack but there is actually a plan behind it :-) I still believe drivers should be encouraged to handle locking on their own. These new big v4l lock (one per device) should be used only to remove the BKL in existing drivers. It's a hack that we should work on getting rid of. It is not a big lock: it doesn't stop other CPU's, doesn't affect other hardware, not even another V4L device. Basically, what this new lock does is to serialize access to the hardware and to the hardware-mirrored data. The lock serializes all ioctls. That's much more than protecting access to data (both in system memory and in the hardware). Absolutely correct. That's exactly what this lock does. Serializing all this makes it much easier to prove that a driver is correctly locking everything. For 90% of all our drivers this is all that is needed. Yes, it is at a coarser level than the theoretical optimum, but basically, who cares? For that 90% it is simply sufficient and without any performance penalties. On several cases, if you serialize open, close, ioctl, read, write and mmap, the hardware will be serialized. Of course, this doesn't cover 100% of the cases where a lock is needed. So, if the driver have more fun things like kthreads, alsa, dvb, IR polling, etc, the driver will need to lock on other places as well. A typical V4L driver has lots of functions that need locking: open, close, read, write, mmap and almost all ioctl (depending on the driver, just a very few set of enum ioctl's could eventually not need an ioctl). What we found is that: 1) several developers didn't do the right thing since the beginning; That's not a valid reason to push new drivers for a very coarse grain locking scheme. Developers must not get told to be stupid and don't care about locks just because other developers got it wrong in the past. If people don't get locking right we need to educate them, not encourage them to understand even less of it. Locking is hard in complex drivers. Period. Sorry, I hadn't finished this email. And of course I lost the rest of what I wrote :-( But basically I want to leave the choice of what to use to the driver developer. If he wants to punish himself and do all the locking manually (and prove that it is correct), then by all means, do so. If you want to use the core locking support and so simplify your
Re: [PATCH] viafb camera controller driver
Hi Mauro, On Tuesday 19 October 2010 16:49:25 Mauro Carvalho Chehab wrote: Em 19-10-2010 11:05, Laurent Pinchart escreveu: It is not a big lock: it doesn't stop other CPU's, doesn't affect other hardware, not even another V4L device. Basically, what this new lock does is to serialize access to the hardware and to the hardware-mirrored data. The lock serializes all ioctls. That's much more than protecting access to data (both in system memory and in the hardware). It is not much more. What ioctl's doesn't access the hardware directly nor access some struct that caches the hardware data? None, at the most complex devices. For simpler devices, there are very few VIDIOC*ENUM stuff that may just return a fixed set of values, but the userspace applications that call them serializes the access anyway (as they are the enum ioctls, used during the hardware detection phase of the userspace software). So, in practice, it makes no difference to serialize everything or to remove the lock for the very few ioctls that just return a fixed set of info. That's not correct. There's a difference between taking a lock around read/write operations and around the whole ioctl call stack. There are basically several opinions about this new schema: some that think that this is the right thing to do, others think that think that this is the wrong thing or that this is acceptable only as a transition for BKL-free drivers. Indeed, and I belong to the second group. And Hans belong to the first one. So you're right, there are two groups :-) IMO, I think that both ways are acceptable: a core-assisted hardware-access lock helps to avoid having lots of lock/unlock code at the driver, making drivers cleaner and easier to review, and reducing the risk of lock degradation with time. On the other hand, some drivers may require more complex locking schemas, like, for example, devices that support several simultaneous independent video streams may have some common parts used by all streams that need to be serialized, and other parts that can (and should) not be serialized. So, a core-assisted locking for some cases may cause unneeded long waits. I am in a position between the first and the second group. Reviewing locks is simpler with the new schema, and, if well implemented, it will help to solve a big problem, but I don't believe that this schema is enough to solve all cases, nor that drivers with lots of independent streams should use it. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] viafb camera controller driver
Em 19-10-2010 12:52, Laurent Pinchart escreveu: Hi Mauro, On Tuesday 19 October 2010 16:49:25 Mauro Carvalho Chehab wrote: Em 19-10-2010 11:05, Laurent Pinchart escreveu: It is not a big lock: it doesn't stop other CPU's, doesn't affect other hardware, not even another V4L device. Basically, what this new lock does is to serialize access to the hardware and to the hardware-mirrored data. The lock serializes all ioctls. That's much more than protecting access to data (both in system memory and in the hardware). It is not much more. What ioctl's doesn't access the hardware directly nor access some struct that caches the hardware data? None, at the most complex devices. For simpler devices, there are very few VIDIOC*ENUM stuff that may just return a fixed set of values, but the userspace applications that call them serializes the access anyway (as they are the enum ioctls, used during the hardware detection phase of the userspace software). So, in practice, it makes no difference to serialize everything or to remove the lock for the very few ioctls that just return a fixed set of info. That's not correct. There's a difference between taking a lock around read/write operations and around the whole ioctl call stack. Huh? Even on simpler hardware, there are very few ioctls that don't access hardware. Hardly, this would cause any performance impact. What I said is that, if the userspace does: open() /* Serialized ioctls */ ioctl (...) ioctl (...) ioctl (...) ioctl (...) ioctl (...) ioctl (...) ioctl (...) ... It doesn't matter if kernel is forcing serialization or not. The difference only happens if userspace does things like: fork() /* Or some thread creation function */ ... /* proccess/thread 1 */ ioctl() ... /* proccess/thread 2 */ ioctl() ... /* proccess/thread 3 */ ioctl() ... However, it doesn't make sense to do parallel access to *ENUM ioctls, so I don't know any application doing that during the hardware discover phase, whe. The usage of different process/threads may make sense, from userspace POV, while streaming. There are a few reasons for that, like: - users may want to adjust the bright/contrast (or other video/audio control) while streaming; - if the dqbuf logic is complex (for example, it may have some software processing logic - like de interlacing); - a separate process may be recording the video. On all the above valid use-cases, the ioctl is really accessing the hardware and/or some hardware-cached data. So, a lock is needed anyway. 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: [PATCH] stb0899: Removed an extra byte sent at init on DiSEqC bus
Em 19-10-2010 10:55, Florent AUDEBERT escreveu: On 06/11/2010 06:01 PM, Florent AUDEBERT wrote: I noticed a stray 0x00 at init on DiSEqC bus (KNC1 DVB-S2) with a DiSEqC tool analyzer. I removed the register from initialization table and all seem to go well (at least for my KNC board). Hi, This old small patch had been marked superseded on patchwork[1]. Is there an non-obvious case when patches go superseded ? Perhaps I missed something but it seems to me no other patch replaced it. This is one of the bad things with patchwork: there's no reason field associated to a status change, nor it marks when the status were changed. A search on my linux-media box, showed that this patch were there, waiting for Manu review, at the email I sent on Jul, 6 2010. The patch still applies, and I didn't find any reply from Manu giving any feedback about it. So, I'm re-tagging it as under review. Manu, any comments about this patch (and the other remaining patches that we're waiting fro your review) ? Regards, [1] https://patchwork.kernel.org/patch/105621/ 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
rtl2832u support
Hi, Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb? Realtek published source code under GPL: MODULE_AUTHOR(Realtek); MODULE_DESCRIPTION(Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device); MODULE_VERSION(1.4.2); MODULE_LICENSE(GPL); Thanks, Damjan-- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mceusb: add support for cx231xx-based IR (e. g. Polaris)
On Mon, Oct 18, 2010 at 08:52:57PM -0200, Mauro Carvalho Chehab wrote: For now, it adds support for Conexant EVK and for Pixelview. We should probably find a better way to specify all Conexant Polaris devices, to avoid needing to repeat this setup on both mceusb and cx231xx-cards. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Looks good to me. Reviewed-by: Jarod Wilson ja...@redhat.com -- Jarod Wilson ja...@redhat.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 2/3] cx231xx: Only register USB interface 1
On Mon, Oct 18, 2010 at 08:52:59PM -0200, Mauro Carvalho Chehab wrote: Interface 0 is used by IR. The current driver starts initializing on it, finishing on interface 6. Change the logic to only handle interface 1. This allows another driver (mceusb) to take care of the IR interface. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Looks good. Reviewed-by: Jarod Wilson ja...@redhat.com -- Jarod Wilson ja...@redhat.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: Old patches sent via the Mailing list
On Sun, Oct 17, 2010 at 07:20:31PM -0200, Mauro Carvalho Chehab wrote: Hi, I did a large effort during this weekend to handle the maximum amount of patches, in order to have them ready for 2.6.37. While there are still some patches marked as NEW at patchwork, and a few pending pull requests (mostly related to more kABI changes), there are still a list of patches that are marked as Under review. Except for 4 patches from me, related to Doc (that I'm keeping in this list just to remind me that I'll need to fix them when I have some time - just some automation stuff at DocBook), all other patches marked as Under review are stuff that I basically depend on others. The last time I sent this list, I was about to travel, and I may have missed some comments, or maybe I may just forgot to update. But I suspect that, for the list bellow, most of them are stuff where the driver maintainer just forgot at limbo. From the list of patches under review, we have: ... == Waiting for Jarod Wilson ja...@redhat.com review/ack == Jun,20 2010: drivers/media/IR/imon.c: Use pr_err instead of err http://patchwork.kernel.org/patch/107025 Joe Perches j...@perches.com Acked. -- Jarod Wilson ja...@redhat.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: Hauppauge WinTV-HVR-1120 on Unbuntu 10.04
On Monday 11 October 2010 11:57:14 fabio tirapelle wrote: Hi After upgrading from Ubuntu 9.10 to Ubuntu 10.04 my Hauppauge WinTV-HVR-1120 (sometimes) doesn't work correctly. I get random the following errors: [ 53.216153] DVB: registering new adapter (saa7133[0]) [ 53.216156] DVB: registering adapter 2 frontend 0 (NXP TDA10048HN DVB-T)... [ 53.840013] tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... [ 53.840019] saa7134 :01:06.0: firmware: requesting dvb-fe-tda10048-1.0.fw [ 53.880505] tda10048_firmware_upload: firmware read 24878 bytes. [ 53.880509] tda10048_firmware_upload: firmware uploading [ 58.280136] tda10048_firmware_upload: firmware uploaded [ 59.024537] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 59.024541] tda18271c2_rf_tracking_filters_correction: error -5 on line 264 [ 59.420153] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 59.420157] tda18271_toggle_output: error -5 on line 47 [ 91.004019] Clocksource tsc unstable (delta = -295012684 ns) [ 256.293639] eth0: link up. [ 256.294750] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 263.523498] eth0: link down. [ 265.258740] eth0: link up. [ 266.460026] eth0: no IPv6 routers present [ 9869.636167] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 9869.636178] tda18271_init: error -5 on line 826 [ 9872.636220] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 9872.636232] tda18271_toggle_output: error -5 on line 47 [ 9998.240167] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 9998.240178] tda18271_init: error -5 on line 826 [10001.240179] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [10001.240190] tda18271_toggle_output: error -5 on line 47 Hi, I have the same HVR-1120 TV card and I get the same kind of errors happening on my ArchLinux installation (kernel 2.6.35). However, these errors are not occuring after all boots. Indeed, I can watch TV (DVB-T) with no problem after 3/4 of my reboots. Is your problem happening at all time ? I've started to recompile my own kernel with the v4l module from the hg repository. I'll tell you if it improves the behavior. I don't use Ubuntu on my desktop computer but, as far as you are concerned, you could first try to update your installation to the last Ubuntu 10.10 or to compile the last Linux kernel. And tell us if it improves something ;) Cheers, -- Albin Kauffmann Open Wide - Architecte Open Source -- 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.26 and up: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Oct 19 19:00:07 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15167:abd3aac6644e git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: 350df81ebaccc651fa4dfad27738db958e067ded gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: WARNINGS linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-armv5-davinci: ERRORS linux-2.6.35.3-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-armv5-ixp: ERRORS linux-2.6.35.3-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-armv5-omap2: ERRORS linux-2.6.35.3-armv5-omap2: ERRORS 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-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: WARNINGS linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: 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-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The 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: rtl2832u support
On 10/19/2010 08:42 PM, Damjan Marion wrote: Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb? It is due to lack of developer making driver suitable for Kernel. I have done some work and have knowledge what is needed, but no time nor interest enough currently. It should be implement as one USB-interface driver and two demod drivers (RTL2830, RTL2832) to support for both RTL2831U and RTL2832U. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Mon, 18 Oct 2010 17:40:04 PDT, Greg KH said: I do have access to this hardware, but its on an old single processor laptop, so any work that it would take to help do this development, really wouldn't be able to be tested to be valid at all. The i810 is a graphics chipset embedded on the memory controller, which was designed for the Intel Pentium II, Pentium III, and Celeron CPUs. Page 8 of the datasheet specifically says: Processor/Host Bus Support - Optimized for the Intel Pentium II processor, Intel Pentium III processor, and Intel CeleronTM processor - Supports processor 370-Pin Socket and SC242 connectors - Supports 32-Bit System Bus Addressing - 4 deep in-order queue; 4 or 1 deep request queue - Supports Uni-processor systems only So no need to clean it up for multiprocessor support. http://download.intel.com/design/chipsets/datashts/29067602.pdf http://www.intel.com/design/chipsets/specupdt/29069403.pdf pgp6lpntWr8cp.pgp Description: PGP signature
Re: rtl2832u support
On Oct 19, 2010, at 9:10 PM, Antti Palosaari wrote: On 10/19/2010 08:42 PM, Damjan Marion wrote: Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb? It is due to lack of developer making driver suitable for Kernel. I have done some work and have knowledge what is needed, but no time nor interest enough currently. It should be implement as one USB-interface driver and two demod drivers (RTL2830, RTL2832) to support for both RTL2831U and RTL2832U. Can you share what you done so far? -- 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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 02:24:53PM -0400, valdis.kletni...@vt.edu wrote: On Mon, 18 Oct 2010 17:40:04 PDT, Greg KH said: I do have access to this hardware, but its on an old single processor laptop, so any work that it would take to help do this development, really wouldn't be able to be tested to be valid at all. The i810 is a graphics chipset embedded on the memory controller, which was designed for the Intel Pentium II, Pentium III, and Celeron CPUs. Page 8 of the datasheet specifically says: Processor/Host Bus Support - Optimized for the Intel Pentium II processor, Intel Pentium III processor, and Intel CeleronTM processor - Supports processor 370-Pin Socket and SC242 connectors - Supports 32-Bit System Bus Addressing - 4 deep in-order queue; 4 or 1 deep request queue - Supports Uni-processor systems only So no need to clean it up for multiprocessor support. http://download.intel.com/design/chipsets/datashts/29067602.pdf http://www.intel.com/design/chipsets/specupdt/29069403.pdf Great, we can just drop all calls to lock_kernel() and the like in the driver and be done with it, right? thanks, greg k-h -- 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: rtl2832u support
On 10/19/2010 10:33 PM, Damjan Marion wrote: On Oct 19, 2010, at 9:10 PM, Antti Palosaari wrote: On 10/19/2010 08:42 PM, Damjan Marion wrote: Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb? It is due to lack of developer making driver suitable for Kernel. I have done some work and have knowledge what is needed, but no time nor interest enough currently. It should be implement as one USB-interface driver and two demod drivers (RTL2830, RTL2832) to support for both RTL2831U and RTL2832U. Can you share what you done so far? Look LinuxTV.org HG trees. There is Jan and my trees, both for RTL2831U. I split driver logically correct parts. Also I have some RTL2832U hacks here in my computer, I can give those for the person really continuing development. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH: So no need to clean it up for multiprocessor support. http://download.intel.com/design/chipsets/datashts/29067602.pdf http://www.intel.com/design/chipsets/specupdt/29069403.pdf Great, we can just drop all calls to lock_kernel() and the like in the driver and be done with it, right? No, you still need to switch off preemption. Regards Oliver -- 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: no DVB-T with AVerMedia M115S
is there any additional information i could give to help supporting this card? thanks, daniel Am 15.10.2010 16:00, schrieb Daniel: Hi, i own a mini-PCI card builtin in a Sony Vaio VGN-AR71ZU Notebook. After searching the web it looks like this is a AVerMedia M115S (maybe the S stands for Sony?), which is somehow different to an ordinary M115. Is there any chance to get DVB-T working with this card? It seems, that the tuner is the problem, but i don't know how to find out the type of the tuner. lspci -vvvnn gives this: 08:04.0 Multimedia controller [0480]: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1) Subsystem: Avermedia Technologies Inc Device [1461:e836] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 Interrupt: pin A routed to IRQ 22 Region 0: Memory at fc006800 (32-bit, non-prefetchable) [size=2K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: saa7134 Kernel modules: saa7134 and dmesg with the actual checkout of v4l gives this: saa7130/34: v4l2 driver version 0.2.16 loaded saa7133[0]: found at :08:04.0, rev: 209, irq: 22, latency: 64, mmio: 0xfc006800 saa7133[0]: subsystem: 1461:e836, board: UNKNOWN/GENERIC [card=0,autodetected] saa7133[0]: board init: gpio is eff saa7133[0]/core: hwinit1 saa7133[0]: i2c xfer: a0 00 saa7133[0]: i2c xfer: a1 =61 =14 =36 =e8 =00 =00 =00 =00 =00 =00 =00 =00 =00 =00 =00 =00 =ff =ff =ff =ff =ff =20 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =01 =40 =01 =02 =02 =01 =01 =03 =08 =ff =00 =00 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =65 =00 =ff =c2 =00 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =0d =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff saa7133[0]: i2c eeprom 00: 61 14 36 e8 00 00 00 00 00 00 00 00 00 00 00 00 saa7133[0]: i2c eeprom 10: ff ff ff ff ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 01 03 08 ff 00 00 ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff 65 00 ff c2 00 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: 0d ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c xfer: 01 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 03 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 05 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 07 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 09 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 0b ERROR: NO_DEVICE saa7133[0]: i2c xfer: 0d ERROR: NO_DEVICE saa7133[0]: i2c xfer: 0f ERROR: NO_DEVICE saa7133[0]: i2c xfer: 11 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 13 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 15 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 17 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 19 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 1b ERROR: NO_DEVICE saa7133[0]: i2c xfer: 1d ERROR: NO_DEVICE saa7133[0]: i2c xfer: 1f ERROR: NO_DEVICE saa7133[0]: i2c xfer: 21 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 23 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 25 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 27 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 29 ERROR: NO_DEVICE saa7133[0]: i2c xfer: 2b ERROR: NO_DEVICE saa7133[0]: i2c xfer: 2d ERROR:
Re: Hauppauge WinTV-HVR-1120 on Unbuntu 10.04
Hi Yes, the same behaviour: random (after 3-4 boots) the card works correctly. The WinTV did work correctly with ubuntu 9.10. In Ubuntu 9.10 the package linux-firmware-nonfree didn't include the dvb-fe-tda10048-1.0.fw. I remember that Ubuntu 9.10 used for my card the dvb-fe-tda10046.fw. Now, Ubuntu 10.04 loads for my card the dvb-fe-tda10048-1.0.fw Its seems that with the 9.10 version, the card is recognized as WinTV-HVR-1100 or 1110 and now as WinTV-HVR-1120. I wait until you recompile the kernel with the v4l. Please tell me if this solves the problem Thanks - Messaggio originale - Da: Albin Kauffmann albin.kauffm...@gmail.com A: fabio tirapelle ftirape...@yahoo.it Cc: linux-media@vger.kernel.org Inviato: Mar 19 ottobre 2010, 20:32:50 Oggetto: Re: Hauppauge WinTV-HVR-1120 on Unbuntu 10.04 On Monday 11 October 2010 11:57:14 fabio tirapelle wrote: Hi After upgrading from Ubuntu 9.10 to Ubuntu 10.04 my Hauppauge WinTV-HVR-1120 (sometimes) doesn't work correctly. I get random the following errors: [ 53.216153] DVB: registering new adapter (saa7133[0]) [ 53.216156] DVB: registering adapter 2 frontend 0 (NXP TDA10048HN DVB-T)... [ 53.840013] tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... [ 53.840019] saa7134 :01:06.0: firmware: requesting dvb-fe-tda10048-1.0.fw [ 53.880505] tda10048_firmware_upload: firmware read 24878 bytes. [ 53.880509] tda10048_firmware_upload: firmware uploading [ 58.280136] tda10048_firmware_upload: firmware uploaded [ 59.024537] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 59.024541] tda18271c2_rf_tracking_filters_correction: error -5 on line 264 [ 59.420153] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 59.420157] tda18271_toggle_output: error -5 on line 47 [ 91.004019] Clocksource tsc unstable (delta = -295012684 ns) [ 256.293639] eth0: link up. [ 256.294750] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 263.523498] eth0: link down. [ 265.258740] eth0: link up. [ 266.460026] eth0: no IPv6 routers present [ 9869.636167] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 9869.636178] tda18271_init: error -5 on line 826 [ 9872.636220] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 9872.636232] tda18271_toggle_output: error -5 on line 47 [ 9998.240167] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 9998.240178] tda18271_init: error -5 on line 826 [10001.240179] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [10001.240190] tda18271_toggle_output: error -5 on line 47 Hi, I have the same HVR-1120 TV card and I get the same kind of errors happening on my ArchLinux installation (kernel 2.6.35). However, these errors are not occuring after all boots. Indeed, I can watch TV (DVB-T) with no problem after 3/4 of my reboots. Is your problem happening at all time ? I've started to recompile my own kernel with the v4l module from the hg repository. I'll tell you if it improves the behavior. I don't use Ubuntu on my desktop computer but, as far as you are concerned, you could first try to update your installation to the last Ubuntu 10.10 or to compile the last Linux kernel. And tell us if it improves something ;) Cheers, -- Albin Kauffmann Open Wide - Architecte Open Source -- 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: rtl2832u support
On Tuesday, October 19, 2010 21:26:13 Devin Heitmueller wrote: On Tue, Oct 19, 2010 at 1:42 PM, Damjan Marion damjan.mar...@gmail.com wrote: Hi, Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb? Realtek published source code under GPL: MODULE_AUTHOR(Realtek); MODULE_DESCRIPTION(Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device); MODULE_VERSION(1.4.2); MODULE_LICENSE(GPL); Unfortunately, in most cases much more is required than having a working driver under the GPL in order for it to be accepted upstream. In some cases it can mean a developer spending a few hours cleaning up whitespace and indentation, and in other cases it means significant work to the driver is required. The position the LinuxTV team has taken is that they would rather have no upstream driver at all than to have a driver which doesn't have the right indentation or other aesthetic problems which has no bearing on how well the driver actually works. This is one of the big reasons KernelLabs has tens of thousands of lines of code adding support for a variety of devices with many happy users (who are willing to go through the trouble to compile from source), but the code cannot be accepted upstream. I just cannot find the time to do the idiot work. Bullshit. First of all these rules are those of the kernel community as a whole and *not* linuxtv as such, and secondly you can upstream such drivers in the staging tree. If you want to move it out of staging, then it will take indeed more work since the quality requirements are higher there. Them's the rules for kernel development. I've done my share of coding style cleanups. I never understand why people dislike doing that. In my experience it always greatly improves the code (i.e. I can actually understand it) and it tends to highlight the remaining problematic areas in the driver. Of course, I can also rant for several paragraphs about companies throwing code over the wall without bothering to actually do the remaining work to get it mainlined. The very least they can do is to sponsor someone to do the work for them. But I'll spare you that :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote: Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH: So no need to clean it up for multiprocessor support. http://download.intel.com/design/chipsets/datashts/29067602.pdf http://www.intel.com/design/chipsets/specupdt/29069403.pdf Great, we can just drop all calls to lock_kernel() and the like in the driver and be done with it, right? No, you still need to switch off preemption. Hm, how would you do that from within a driver? thanks, greg k-h -- 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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, 19 Oct 2010, Greg KH wrote: So no need to clean it up for multiprocessor support. http://download.intel.com/design/chipsets/datashts/29067602.pdf http://www.intel.com/design/chipsets/specupdt/29069403.pdf Great, we can just drop all calls to lock_kernel() and the like in the driver and be done with it, right? No, you still need to switch off preemption. Hm, how would you do that from within a driver? preempt_disable() -- Jiri Kosina SUSE Labs, Novell Inc. -- 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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
you still need to switch off preemption. Hm, how would you do that from within a driver? Do we care - unless I misunderstand the current intel DRM driver handles the i810 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
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tuesday 19 October 2010 22:29:12 Greg KH wrote:
On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote:
Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH:
So no need to clean it up for multiprocessor support.
http://download.intel.com/design/chipsets/datashts/29067602.pdf
http://www.intel.com/design/chipsets/specupdt/29069403.pdf
Great, we can just drop all calls to lock_kernel() and the like in the
driver and be done with it, right?
No,
you still need to switch off preemption.
Hm, how would you do that from within a driver?
I think this would do:
---
drm/i810: remove SMP support and BKL
The i810 and i815 chipsets supported by the i810 drm driver were not
officially designed for SMP operation, so the big kernel lock is
only required for kernel preemption. This disables the driver if
preemption is enabled and removes all calls to lock_kernel in it.
If you own an Acorp 6A815EPD mainboard with a i815 chipset and
two Pentium-III sockets, and want to run recent kernels on it,
tell me about it.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b755301..e071bc8 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -73,8 +73,8 @@ source drivers/gpu/drm/radeon/Kconfig
config DRM_I810
tristate Intel I810
- # BKL usage in order to avoid AB-BA deadlocks, may become BROKEN_ON_SMP
- depends on DRM AGP AGP_INTEL BKL
+ # PREEMPT requires BKL support here, which was removed
+ depends on DRM AGP AGP_INTEL !PREEMPT
help
Choose this option if you have an Intel I810 graphics card. If M is
selected, the module will be called i810. AGP support is required
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index ff33e53..8f371e8 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -37,7 +37,6 @@
#include linux/interrupt.h /* For task queue support */
#include linux/delay.h
#include linux/slab.h
-#include linux/smp_lock.h
#include linux/pagemap.h
#define I810_BUF_FREE 2
@@ -94,7 +93,6 @@ static int i810_mmap_buffers(struct file *filp, struct
vm_area_struct *vma)
struct drm_buf *buf;
drm_i810_buf_priv_t *buf_priv;
- lock_kernel();
dev = priv-minor-dev;
dev_priv = dev-dev_private;
buf = dev_priv-mmap_buffer;
@@ -104,7 +102,6 @@ static int i810_mmap_buffers(struct file *filp, struct
vm_area_struct *vma)
vma-vm_file = filp;
buf_priv-currently_mapped = I810_BUF_MAPPED;
- unlock_kernel();
if (io_remap_pfn_range(vma, vma-vm_start,
vma-vm_pgoff,
@@ -116,7 +113,7 @@ static int i810_mmap_buffers(struct file *filp, struct
vm_area_struct *vma)
static const struct file_operations i810_buffer_fops = {
.open = drm_open,
.release = drm_release,
- .unlocked_ioctl = i810_ioctl,
+ .unlocked_ioctl = drm_ioctl,
.mmap = i810_mmap_buffers,
.fasync = drm_fasync,
.llseek = noop_llseek,
@@ -1242,19 +1239,6 @@ int i810_driver_dma_quiescent(struct drm_device *dev)
return 0;
}
-/*
- * call the drm_ioctl under the big kernel lock because
- * to lock against the i810_mmap_buffers function.
- */
-long i810_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
-{
- int ret;
- lock_kernel();
- ret = drm_ioctl(file, cmd, arg);
- unlock_kernel();
- return ret;
-}
-
struct drm_ioctl_desc i810_ioctls[] = {
DRM_IOCTL_DEF_DRV(I810_INIT, i810_dma_init,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I810_VERTEX, i810_dma_vertex, DRM_AUTH|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/i810/i810_drv.c b/drivers/gpu/drm/i810/i810_drv.c
index 88bcd33..9642d3c 100644
--- a/drivers/gpu/drm/i810/i810_drv.c
+++ b/drivers/gpu/drm/i810/i810_drv.c
@@ -57,7 +57,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.unlocked_ioctl = i810_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
@@ -79,6 +79,10 @@ static struct drm_driver driver = {
static int __init i810_init(void)
{
+ if (num_present_cpus() 1) {
+ pr_err(drm/i810 does not support SMP\n);
+ return -EINVAL;
+ }
driver.num_ioctls = i810_max_ioctl;
return drm_init(driver);
}
--
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: rtl2832u support
On Tue, Oct 19, 2010 at 4:27 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Tuesday, October 19, 2010 21:26:13 Devin Heitmueller wrote: On Tue, Oct 19, 2010 at 1:42 PM, Damjan Marion damjan.mar...@gmail.com wrote: Hi, Is there any special reason why driver for rtl2832u DVB-T receiver chipset is not included into v4l-dvb? Realtek published source code under GPL: MODULE_AUTHOR(Realtek); MODULE_DESCRIPTION(Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device); MODULE_VERSION(1.4.2); MODULE_LICENSE(GPL); Unfortunately, in most cases much more is required than having a working driver under the GPL in order for it to be accepted upstream. In some cases it can mean a developer spending a few hours cleaning up whitespace and indentation, and in other cases it means significant work to the driver is required. The position the LinuxTV team has taken is that they would rather have no upstream driver at all than to have a driver which doesn't have the right indentation or other aesthetic problems which has no bearing on how well the driver actually works. This is one of the big reasons KernelLabs has tens of thousands of lines of code adding support for a variety of devices with many happy users (who are willing to go through the trouble to compile from source), but the code cannot be accepted upstream. I just cannot find the time to do the idiot work. Bullshit. First of all these rules are those of the kernel community as a whole and *not* linuxtv as such, and secondly you can upstream such drivers in the staging tree. If you want to move it out of staging, then it will take indeed more work since the quality requirements are higher there. Them's the rules for kernel development. I've done my share of coding style cleanups. I never understand why people dislike doing that. In my experience it always greatly improves the code (i.e. I can actually understand it) and it tends to highlight the remaining problematic areas in the driver. Of course, I can also rant for several paragraphs about companies throwing code over the wall without bothering to actually do the remaining work to get it mainlined. The very least they can do is to sponsor someone to do the work for them. To start, I appreciate the kernel coding style requirements. I think it makes the code much easier to read and more consistent across the kernel tree. But, just to play devil's advocate, it's a fair amount of work to write a driver especially if the hw is complex. It's much easier to share a common codebase between different OSs because to reduces the maintenance burden and makes it easier to support new asic variants. This is especially true if you are a small company with limited resources. It annoys me somewhat when IHVs put in the effort to actually produce a GPLed Linux driver and the community shits on them for not writing it from scratch to match the kernel style requirements. Lets face it, there are a lot of hw specs out there with no driver. A working driver with source is vastly more useful. It would be nice if every company out there had the resources to develop a nice clean native Linux driver, but right now that's not always the case. Alex -- 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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 11:26 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 19 October 2010, Arnd Bergmann wrote:
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
I might be able to find some hardware still lying around here that uses
an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() 1) {
pr_err(i810 no longer supports SMP\n);
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
Some research showed that Intel never support i810/i815 SMP setups,
but there was indeed one company (http://www.acorpusa.com at the time,
now owned by a domain squatter) that made i815E based dual Pentium-III
boards like this one: http://cgi.ebay.com/280319795096
Also that board has no on-board GPU enabled i815EP (P means no on-board GPU).
So I think i810 is fine.
The first person that can send me an authentic log file showing the
use of X.org with DRM on a 2.6.35 kernel with two processors on that
mainboard dated today or earlier gets a free upgrade to an AGP graphics
card of comparable or better 3D performance from me. Please include
the story how why you are running this machine with a new kernel.
i830 is harder, apparently some i865G boards support Pentium 4 with HT
and even later dual-core processors.
Also hyper-threaded 845G boards, however I'm happy to start a proper
deprecation procedure on the i830 ABI,
Its been a few years since a distro shipped with it, I think even
RHEL5 has the i915 driver enabled, so we are
probably talking RHEL4 era.
Dave.
--
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 1/2] ov7670: allow configuration of image size, clock speed, and I/O method
These parameters need to be configurable based on the host system.
They can now be communicated through the s_config call.
The old CONFIG_OLPC_XO_1 selector was not correct; this kind of
arrangement wouldn't allow for a universal kernel that would work on both
laptops.
Certain parts of the probe routine had to be moved later (into s_config),
because we can't do any I/O until we know which I/O method has been
selected through this mechanism.
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers/media/video/ov7670.c | 133 ++
drivers/media/video/ov7670.h | 20 ++
2 files changed, 115 insertions(+), 38 deletions(-)
create mode 100644 drivers/media/video/ov7670.h
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0b78f33..c881a64 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -20,6 +20,7 @@
#include media/v4l2-chip-ident.h
#include media/v4l2-mediabus.h
+#include ov7670.h
MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
MODULE_DESCRIPTION(A low-level driver for OmniVision ov7670 sensors);
@@ -43,11 +44,6 @@ MODULE_PARM_DESC(debug, Debug level (0-1));
#defineQCIF_HEIGHT 144
/*
- * Our nominal (default) frame rate.
- */
-#define OV7670_FRAME_RATE 30
-
-/*
* The 7670 sits on i2c with ID 0x42
*/
#define OV7670_I2C_ADDR 0x42
@@ -198,7 +194,11 @@ struct ov7670_info {
struct ov7670_format_struct *fmt; /* Current format */
unsigned char sat; /* Saturation value */
int hue;/* Hue value */
+ int min_width; /* Filter out smaller sizes */
+ int min_height; /* Filter out smaller sizes */
+ int clock_speed;/* External clock speed (MHz) */
u8 clkrc; /* Clock divider value */
+ bool use_smbus; /* Use smbus I/O instead of I2C */
};
static inline struct ov7670_info *to_state(struct v4l2_subdev *sd)
@@ -415,8 +415,7 @@ static struct regval_list ov7670_fmt_raw[] = {
* ov7670 is not really an SMBUS device, though, so the communication
* is not always entirely reliable.
*/
-#ifdef CONFIG_OLPC_XO_1
-static int ov7670_read(struct v4l2_subdev *sd, unsigned char reg,
+static int ov7670_read_smbus(struct v4l2_subdev *sd, unsigned char reg,
unsigned char *value)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -431,7 +430,7 @@ static int ov7670_read(struct v4l2_subdev *sd, unsigned
char reg,
}
-static int ov7670_write(struct v4l2_subdev *sd, unsigned char reg,
+static int ov7670_write_smbus(struct v4l2_subdev *sd, unsigned char reg,
unsigned char value)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -442,11 +441,10 @@ static int ov7670_write(struct v4l2_subdev *sd, unsigned
char reg,
return ret;
}
-#else /* ! CONFIG_OLPC_XO_1 */
/*
* On most platforms, we'd rather do straight i2c I/O.
*/
-static int ov7670_read(struct v4l2_subdev *sd, unsigned char reg,
+static int ov7670_read_i2c(struct v4l2_subdev *sd, unsigned char reg,
unsigned char *value)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -479,7 +477,7 @@ static int ov7670_read(struct v4l2_subdev *sd, unsigned
char reg,
}
-static int ov7670_write(struct v4l2_subdev *sd, unsigned char reg,
+static int ov7670_write_i2c(struct v4l2_subdev *sd, unsigned char reg,
unsigned char value)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -498,8 +496,26 @@ static int ov7670_write(struct v4l2_subdev *sd, unsigned
char reg,
msleep(5); /* Wait for reset to run */
return ret;
}
-#endif /* CONFIG_OLPC_XO_1 */
+static int ov7670_read(struct v4l2_subdev *sd, unsigned char reg,
+ unsigned char *value)
+{
+ struct ov7670_info *info = to_state(sd);
+ if (info-use_smbus)
+ return ov7670_read_smbus(sd, reg, value);
+ else
+ return ov7670_read_i2c(sd, reg, value);
+}
+
+static int ov7670_write(struct v4l2_subdev *sd, unsigned char reg,
+ unsigned char value)
+{
+ struct ov7670_info *info = to_state(sd);
+ if (info-use_smbus)
+ return ov7670_write_smbus(sd, reg, value);
+ else
+ return ov7670_write_i2c(sd, reg, value);
+}
/*
* Write a list of register settings; ff/ff stops the process.
@@ -854,7 +870,7 @@ static int ov7670_g_parm(struct v4l2_subdev *sd, struct
v4l2_streamparm *parms)
memset(cp, 0, sizeof(struct v4l2_captureparm));
cp-capability = V4L2_CAP_TIMEPERFRAME;
cp-timeperframe.numerator = 1;
- cp-timeperframe.denominator = OV7670_FRAME_RATE;
+ cp-timeperframe.denominator = info-clock_speed;
if ((info-clkrc CLK_EXT) == 0 (info-clkrc CLK_SCALE) 1)
cp-timeperframe.denominator /= (info-clkrc
[PATCH 2/2] cafe_ccic: Configure ov7670 correctly
Force smbus communication, disable QCIF mode, and set the correct
clock speed on the OLPC XO-1.
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers/media/video/cafe_ccic.c | 33 +++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c
index b4f5b3b..4378597 100644
--- a/drivers/media/video/cafe_ccic.c
+++ b/drivers/media/video/cafe_ccic.c
@@ -25,6 +25,7 @@
#include linux/module.h
#include linux/init.h
#include linux/fs.h
+#include linux/dmi.h
#include linux/mm.h
#include linux/pci.h
#include linux/i2c.h
@@ -46,6 +47,7 @@
#include asm/uaccess.h
#include asm/io.h
+#include ov7670.h
#include cafe_ccic-regs.h
#define CAFE_VERSION 0x02
@@ -1974,11 +1976,33 @@ static irqreturn_t cafe_irq(int irq, void *data)
* PCI interface stuff.
*/
+static const struct dmi_system_id olpc_xo1_dmi[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, OLPC),
+ DMI_MATCH(DMI_PRODUCT_NAME, XO),
+ DMI_MATCH(DMI_PRODUCT_VERSION, 1),
+ },
+ },
+ { }
+};
+
static int cafe_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
int ret;
struct cafe_camera *cam;
+ struct ov7670_config sensor_cfg = {
+ /* This controller only does SMBUS */
+ .use_smbus = true,
+
+ /*
+* Exclude QCIF mode, because it only captures a tiny portion
+* of the sensor FOV
+*/
+ .min_width = 320,
+ .min_height = 240,
+ };
/*
* Start putting together one of our big camera structures.
@@ -2036,13 +2060,18 @@ static int cafe_pci_probe(struct pci_dev *pdev,
if (ret)
goto out_freeirq;
+ /* Apply XO-1 clock speed */
+ if (dmi_check_system(olpc_xo1_dmi))
+ sensor_cfg.clock_speed = 45;
+
cam-sensor_addr = 0x42;
- cam-sensor = v4l2_i2c_new_subdev(cam-v4l2_dev, cam-i2c_adapter,
- ov7670, ov7670, cam-sensor_addr, NULL);
+ cam-sensor = v4l2_i2c_new_subdev_cfg(cam-v4l2_dev, cam-i2c_adapter,
+ ov7670, ov7670, 0, sensor_cfg, cam-sensor_addr, NULL);
if (cam-sensor == NULL) {
ret = -ENODEV;
goto out_smbus;
}
+
ret = cafe_cam_init(cam);
if (ret)
goto out_smbus;
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl2832u support
On Tue, Oct 19, 2010 at 4:27 PM, Hans Verkuil hverk...@xs4all.nl wrote: Bullshit. Not exactly the level of mutual respect for your peers that I would expect of you, Hans. First of all these rules are those of the kernel community as a whole and *not* linuxtv as such, and secondly you can upstream such drivers in the staging tree. If you want to move it out of staging, then it will take indeed more work since the quality requirements are higher there. You are correct - while I indeed say it was the position of the LinuxTV developers, I didn't intend to single them out from the rest of the Linux kernel community. The problem I described is systemic to working with the Linux kernel community in general. Them's the rules for kernel development. I've done my share of coding style cleanups. I never understand why people dislike doing that. In my experience it always greatly improves the code (i.e. I can actually understand it) and it tends to highlight the remaining problematic areas in the driver. Because it's additional work. I agree that *sometimes* it can be useful. And yet many times it's a bunch of changes that provide little actual value and only make it harder to keep the Linux driver in sync with the upstream source (in many cases, the GPL driver is derived from some Windows driver or other source). Alex makes a point that I think it's worth expanding on a bit: The Linux kernel developers' goals are different than those of the product/chipset vendor. The product/chipset vendor typically wants consistency across operating systems. This usually involves some sort of OS portability layer to abstract out the OS specific parts (which is usually done as a combination of OS specific header files and C macros). This reduces the maintenance cost for the author as it makes it easier to be confident that changes to the core will basically just work on other operating systems. The Linux kernel developer wants consistency across Linux drivers regardless of who wrote them. This makes sense for the Linux kernel community in that it makes it easier to work on drivers that you didn't necessarily write. However it also means that all of the portability code and macros are seen as crap which has to be stripped out. The net effect is a driver that looks little like the original platform independent driver, making it easier for the Linux kernel community to maintain but harder for the original author to provide updates to. I can appreciate why the Linux development community chose this route, but let's not pretend that it doesn't come at a significant cost. Kind of like how the Git move has resulted in developers who want to build drivers on a known-stable kernel (as opposed to the bleeding edge) being treated as second class citizens. 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: cx23885 module
Hi Dan, Thanks for writing. I can't do one-on-one end user support without copying in the Linux Media mailing list. I'm taking the liberty of doing so. Please reply-all when discussing this issue - so everyone can benefit. [Dan is having issues being up an AverMedia board with a LG demod and a MT2131 tuner via the cx23885 driver] However, I am having some trouble getting the tuner to be recognized. I was It's the GPIO probably holding the tuner in reset, I suspect your gpio configuration is wrong. That's my first guess. What makes you think the gpio settings in your patch are correct? hoping that you might be willing to look over the code a bit to see what I am missing. I have altered the following 3 files: cx23885.h, cx23885-cards.c, and cx23885-dvb.c. I am attaching the 3 files in this email. I have been trying to do 3 things. First, to have the module auto-detect my card which was successful. Second, I wanted to attach the LGDT330X as my frontend which was successful. Third, I wanted to attach the MT2131 tuner. This third step is where I am having my troubles. I feel so close but I am not there yet. I know that you wrote the code a while back but if you would be willing to help me, I'd really appreciate it. Some folks have gotten the ngene module to work with the M780 board which Yeah, I worked on the ngene with Devin as part of our KernelLabs.com projects, we brought up the digital side of the card as a pre-test while investigating ngene analog support. If the 2131 isn't attaching then it's because you think it's on a different I2C bus, or the LG demod has it's I2C gate closed (unlikely) or the tuner is not responding because it's being held in reset. Do you see the tuner if you perform and I2C scan (modprobe i2c_scan=1)? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
soc_camera device
I'm pretty new to Linux video drivers (I do have experience with drivers in general) and am trying to get my head around the driver models. Sorry if this is too basic a question for this forum. I have an OMAP 3530 running Arago Linux (2.6.32 at the moment), and I'm trying to capture images from an Aptina sensor for which there does not seem to be a driver. There seem to be soc_camera, soc_camera-int, v4l2, omap34xxcam drivers at the very least. I'm pretty confused over these and how they do or don't work with V4L2 and/or each other. It seems that some of the driver models are deprecated (but still in use), and that soc_camera is current. Or is it? 2 things in particular at the moment are giving me a hard time: 1. I can't seem to load soc_camera.ko ... I keep getting the error: soc_camera: exports duplicate symbol soc_camera_host_unregister (owned by kernel) I can't seem to resolve this, nor can I find the issue described in any online forum (and so I suspect it's my problem). 2. There are drivers for the Aptina MT9V022 and the MT9M001 (among others). Both of these are sensors, and not SOC, and yet both of these rely on the soc_camera module. I'm willing to create the driver for my Aptina sensor, and the easiest way is generally to look at a known driver as a template, however I can't figure out which to look at. -- 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: soc_camera device
Hi Hal, On Tuesday 19 October 2010 23:58:48 Hal Moroff wrote: I'm pretty new to Linux video drivers (I do have experience with drivers in general) and am trying to get my head around the driver models. Sorry if this is too basic a question for this forum. I have an OMAP 3530 running Arago Linux (2.6.32 at the moment), You should really upgrade to a more recent OMAP3 ISP driver. The driver has been (nearly) completely rewritten and has a new userspace API (still V4L2 compatible of course). If you build your userspace applications for the OMAP3 ISP driver shipped with the 2.6.32 kernel you will be stuck with the old buggy driver. You can find the latest driver in http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/media-0004- omap3isp and I'm trying to capture images from an Aptina sensor for which there does not seem to be a driver. There seem to be soc_camera, soc_camera-int, v4l2, omap34xxcam drivers at the very least. I'm pretty confused over these and how they do or don't work with V4L2 and/or each other. And you're missing isp-mod.ko :-) It seems that some of the driver models are deprecated (but still in use), and that soc_camera is current. Or is it? In recent driver versions isp-mod.ko and omap34xxcam.ko have been merged into omap3-isp.ko. The driver doesn't use the SoC camera framework, so you can forget about soc_camera for now. 2 things in particular at the moment are giving me a hard time: 1. I can't seem to load soc_camera.ko ... I keep getting the error: soc_camera: exports duplicate symbol soc_camera_host_unregister (owned by kernel) I can't seem to resolve this, nor can I find the issue described in any online forum (and so I suspect it's my problem). That's probably caused by soc_camera being built in your kernel image, and then built again as a module. That shouldn't matter as you don't need soc_camera anyway. 2. There are drivers for the Aptina MT9V022 and the MT9M001 (among others). Both of these are sensors, and not SOC, and yet both of these rely on the soc_camera module. I'm willing to create the driver for my Aptina sensor, and the easiest way is generally to look at a known driver as a template, however I can't figure out which to look at. To be compatible with the OMAP3 ISP driver, sensor drivers need to implement the V4L2 subdev pad-level API. Look at the MT9T001 driver in http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/media- mt9t001 for sample code. Please read the http://www.spinics.net/lists/linux-media/msg23744.html mail thread for more information. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AF9013/15 I2C problems
In message 4cbb1982.4050...@iki.fi, Antti Palosaari wrote On 10/17/2010 01:47 PM, dave cunningham wrote: I'm currently on hg version 14319:37581bb7e6f1, on a debian-squeeze system, kernel 2.6.32. I've googled and found various people seeing similar problems but have yet to come across a solution. Would anyone have any suggestions (note if I switch back to firmware 4.65 with just the Tevion stick things are fine - I'd like to use the KWorld stick if possible though)? I have strong feeling this issue is fixed already. Install latest Git master driver from Linuxtv.org I've compiled the git media-master, commit 1c8c51f7413ec522c7b729c8ebc5ce815fb7d4a8 and still have problems. With the Tevion Stick I now see the following at boot (with both firmware 4.65.0 and 4.95.0): [6.257795] DVB: registering adapter 0 frontend 0 (STB0899 Multistandard)... [6.264875] TDA18271HD/C1 detected @ 1-00c0 [6.902293] af9015: command failed:1 [6.902789] tda18271_write_regs: [1-00c0|M] ERROR: idx = 0x0, len = 39, i2c_t ransfer returned: -1 [7.540215] af9015: command failed:1 [7.540707] tda18271_write_regs: [1-00c0|M] ERROR: idx = 0x20, len = 1, i2c_t ransfer returned: -1 [8.178133] af9015: command failed:1 [8.178747] tda18271_write_regs: [1-00c0|M] ERROR: idx = 0x20, len = 1, i2c_t ransfer returned: -1 [8.816417] af9015: command failed:1 [8.817039] tda18271_write_regs: [1-00c0|M] ERROR: idx = 0x20, len = 1, i2c_transfer returned: -1 [9.454467] af9015: command failed:1 [9.455080] tda18271_write_regs: [1-00c0|M] ERROR: idx = 0x20, len = 1, i2c_transfer returned: -1 [ 10.092508] af9015: command failed:1 [ 10.093122] tda18271_write_regs: [1-00c0|M] ERROR: idx = 0x23, len = 1, i2c_transfer returned: -1 [ 10.730542] af9015: command failed:1 ... The KWorld stick comes up OK and can be used but after changing channels/sources a few times in mythtv I get (firmware 4.95.0): Oct 19 23:52:32 beta dhcpd: DHCPACK on 192.168.0.9 to 00:1c:c0:8c:88:7d via eth0 Oct 19 23:58:04 beta kernel: [ 480.140076] af9013: I2C read failed reg:d507 Oct 19 23:58:06 beta kernel: [ 482.152089] af9013: I2C read failed reg:d507 Oct 19 23:58:08 beta kernel: [ 484.164077] af9013: I2C read failed reg:d507 Oct 19 23:58:10 beta kernel: [ 486.176076] af9013: I2C read failed reg:d507 Oct 19 23:58:12 beta kernel: [ 488.188128] af9013: I2C read failed reg:d507 ... -- Dave Cunningham dave at upsilon org uk PGP KEY ID: 0xA78636DC -- 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: cx23888 board setup
Fred,
You should send mail to the linux-media list; the video4linux list is mostly
dead.
Analog support in the cx23885 driver is not complete. You can contact Steve
Toth at kernellabs, if your company needs something in a certain timeframe and
is willing to sponsor getting the functionality you need.
Also the CX23888 itself doesn't do MPEG compression. You'll need a connected
CX23417 (or CX23416) to do the compression. (Maybe you have that, but you
didn't mention it.)
Regards,
Andy
Fred Seward fred.sew...@adiengineering.com wrote:
We have a custom x86 board with:
- A soldered down cx23888
- Four composite inputs feeding the cx23888. No tuner.
We're only looking at the four composite inputs.
- FC13 with a 2.6.33.4 kernel.
The cx23885 driver loads and I get /dev/video0 but when I try to
cat /dev/video0 I get data but it's not an mpeg file.
Can anyone point me to some documentation which tells how to set
up the cx23885_board board structure and what other
initialization might need to be done?
In the cx23885 driver I modified cx23885-cards.c to add an
entry for our hardware.
struct cx23885_board cx23885_boards[] = {
[CX23885_BOARD_ECU] = {
.name = custom board,
.porta = CX23885_ANALOG_VIDEO,
.portb = CX23885_MPEG_ENCODER,
.clk_freq = 5000,
.input = {{
.type = CX23885_VMUX_COMPOSITE1,
.vmux = 0,
}, {
.type = CX23885_VMUX_COMPOSITE2,
.vmux = 1,
}, {
.type = CX23885_VMUX_COMPOSITE3,
.vmux = 2,
}, {
.type = CX23885_VMUX_COMPOSITE4,
.vmux = 3,
} },
},
cx23885_subids
}, {
.subvendor = 0x,
.subdevice = 0x,
.card = CX23885_BOARD_ECU,
}, {
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
[PATCH] V4L/DVB: Add the via framebuffer camera controller driver
OK, here's a new version of the patch, done against the V4L tree. Now
with 100% fewer compiler errors! It took a while to figure out the API
changes, and I'm not convinced I like them all - the controller driver
didn't used to have to worry about format details, but now it does -
but so it goes.
It still has the static device structure; I will fix that soon, I
promise.
Thanks,
jon
---
Add a driver for the video capture port on VIA integrated chipsets. This
version has a remaining OLPCism or two and expects to be talking to an
ov7670; those can be improved as the need arises.
This work was supported by the One Laptop Per Child project.
Thanks to Laurent Pinchart for a number of useful comments.
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/Kconfig | 10 +
drivers/media/video/Makefile |2 +
drivers/media/video/via-camera.c | 1474 ++
drivers/media/video/via-camera.h | 93 +++
drivers/video/via/accel.c|2 +-
drivers/video/via/via-core.c | 16 +-
include/linux/via-core.h |4 +-
include/media/v4l2-chip-ident.h |4 +
8 files changed, 1601 insertions(+), 4 deletions(-)
create mode 100644 drivers/media/video/via-camera.c
create mode 100644 drivers/media/video/via-camera.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 2d42267..0efbb29 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -712,6 +712,16 @@ config VIDEO_SR030PC30
---help---
This driver supports SR030PC30 VGA camera from Siliconfile
+config VIDEO_VIA_CAMERA
+ tristate VIAFB camera controller support
+ depends on FB_VIA
+ select VIDEOBUF_DMA_SG
+ select VIDEO_OV7670
+ help
+ Driver support for the integrated camera controller in VIA
+ Chrome9 chipsets. Currently only tested on OLPC xo-1.5 systems
+ with ov7670 sensors.
+
config SOC_CAMERA
tristate SoC camera support
depends on VIDEO_V4L2 HAS_DMA I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index d5e49dd..af79d47 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -122,6 +122,8 @@ obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
+obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
+
obj-$(CONFIG_USB_DABUSB)+= dabusb.o
obj-$(CONFIG_USB_SE401) += se401.o
obj-$(CONFIG_USB_ZR364XX) += zr364xx.o
diff --git a/drivers/media/video/via-camera.c b/drivers/media/video/via-camera.c
new file mode 100644
index 000..02a21bc
--- /dev/null
+++ b/drivers/media/video/via-camera.c
@@ -0,0 +1,1474 @@
+/*
+ * Driver for the VIA Chrome integrated camera controller.
+ *
+ * Copyright 2009,2010 Jonathan Corbet cor...@lwn.net
+ * Distributable under the terms of the GNU General Public License, version 2
+ *
+ * This work was supported by the One Laptop Per Child project
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/device.h
+#include linux/list.h
+#include linux/pci.h
+#include linux/gpio.h
+#include linux/interrupt.h
+#include linux/pci.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-chip-ident.h
+#include media/videobuf-dma-sg.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/pm_qos_params.h
+#include linux/via-core.h
+#include linux/via-gpio.h
+#include linux/via_i2c.h
+
+#include via-camera.h
+
+MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
+MODULE_DESCRIPTION(VIA framebuffer-based camera controller driver);
+MODULE_LICENSE(GPL);
+
+static int flip_image;
+module_param(flip_image, bool, 0444);
+MODULE_PARM_DESC(flip_image,
+ If set, the sensor will be instructed to flip the image
+ vertically.);
+
+#ifdef CONFIG_OLPC_XO_1_5
+static int override_serial;
+module_param(override_serial, bool, 0444);
+MODULE_PARM_DESC(override_serial,
+ The camera driver will normally refuse to load if
+ the XO 1.5 serial port is enabled. Set this option
+ to force the issue.);
+#endif
+
+/*
+ * Basic window sizes.
+ */
+#define VGA_WIDTH 640
+#define VGA_HEIGHT 480
+#define QCIF_WIDTH 176
+#defineQCIF_HEIGHT 144
+
+/*
+ * The structure describing our camera.
+ */
+enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
+
+struct via_camera {
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ struct v4l2_subdev *sensor;
+ struct platform_device *platdev;
+ struct viafb_dev *viadev;
+ struct mutex lock;
+ enum viacam_opstate opstate;
+ unsigned long flags;
+ struct pm_qos_request_list qos_request;
+ /*
+* GPIO info for power/reset management
+*/
+
Re: [stable] V4L/DVB (13966): DVB-T regression fix for saa7134 cards
On Wed, Sep 29, 2010 at 12:28:00PM -0300, Mauro Carvalho Chehab wrote: Hi, Some users are reporting a regression on 2.6.31 and 2.6.32 that were fixed on 2.6.33, related to DVB reception with saa7134. Could you please cherry-pick this patch to 2.6.32 stable as well? http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.33.y.git;a=commit;h=08be64be3d1e5ecd72e7ba3147aea518e527f08e Now queued up, thanks. greg k-h -- 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: [stable] [PATCH 1/2] V4L/DVB: dib7770: enable the current mirror
On Tue, Sep 07, 2010 at 05:50:45PM +0200, pboettc...@kernellabs.com wrote: From: Olivier Grenie olivier.gre...@dibcom.fr To improve performance on DiB7770-devices enabling the current mirror is needed. This patch adds an option to the dib7000p-driver to do that and it creates a separate device-entry in dib0700-device to use those changes on hardware which is using the DiB7770. Cc: sta...@kernel.org Signed-off-by: Olivier Grenie olivier.gre...@dibcom.fr Signed-off-by: Patrick Boettcher patrick.boettc...@dibcom.fr This does not seem like -stable material, sorry. greg k-h -- 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
Hauppauge WinTV PVR USB2 problems
I have 4 of these tuners, 3 of them are the 24xx series and 1 is a 29xx series, at one time they all worked great and I am not sure what happened to cause this but at some point the 29xx tuner started outputting black and white video. At first I suspected a hardware failure and thought maybe it was in the analog tuner part of the card so I switched it over to using the composite side but this didn't help. As a last resort to chalking it up as a failed piece of hardware I tried it on a windows machine and it works fine there so I am under the impression that this must be a driver/firmware issue. Since my other 3 tuners don't have a problem I assume that there must be some part of the driver/firmware that only affects the 29xx series cards and the problem lies within this, I have no idea where to look for a solution, any help would be appreciated. -- 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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Wed, Oct 20, 2010 at 4:44 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 19 October 2010 22:29:12 Greg KH wrote: On Tue, Oct 19, 2010 at 09:40:47PM +0200, Oliver Neukum wrote: Am Dienstag, 19. Oktober 2010, 21:37:35 schrieb Greg KH: So no need to clean it up for multiprocessor support. http://download.intel.com/design/chipsets/datashts/29067602.pdf http://www.intel.com/design/chipsets/specupdt/29069403.pdf Great, we can just drop all calls to lock_kernel() and the like in the driver and be done with it, right? No, you still need to switch off preemption. Hm, how would you do that from within a driver? I think this would do: --- drm/i810: remove SMP support and BKL The i810 and i815 chipsets supported by the i810 drm driver were not officially designed for SMP operation, so the big kernel lock is only required for kernel preemption. This disables the driver if preemption is enabled and removes all calls to lock_kernel in it. If you own an Acorp 6A815EPD mainboard with a i815 chipset and two Pentium-III sockets, and want to run recent kernels on it, tell me about it. Signed-off-by: Arnd Bergmann a...@arndb.de --- diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b755301..e071bc8 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -73,8 +73,8 @@ source drivers/gpu/drm/radeon/Kconfig config DRM_I810 tristate Intel I810 - # BKL usage in order to avoid AB-BA deadlocks, may become BROKEN_ON_SMP - depends on DRM AGP AGP_INTEL BKL + # PREEMPT requires BKL support here, which was removed + depends on DRM AGP AGP_INTEL !PREEMPT be curious, why can't just fix the lock_kernel logic of i810? Fixing is too hard? Find a i810 hardware should be possible, even if the hardware does not support SMP, can't we test the fix with preemption? -- Regards dave -- 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: Old patches sent via the Mailing list
Am 18.10.2010 08:15, schrieb Mauro Carvalho Chehab: Em 17-10-2010 21:36, Andy Walls escreveu: On Sun, 2010-10-17 at 19:20 -0200, Mauro Carvalho Chehab wrote: Hi, I did a large effort during this weekend to handle the maximum amount of patches, in order to have them ready for 2.6.37. While there are still some patches marked as NEW at patchwork, and a few pending pull requests (mostly related to more kABI changes), there are still a list of patches that are marked as Under review. Except for 4 patches from me, related to Doc (that I'm keeping in this list just to remind me that I'll need to fix them when I have some time - just some automation stuff at DocBook), all other patches marked as Under review are stuff that I basically depend on others. The last time I sent this list, I was about to travel, and I may have missed some comments, or maybe I may just forgot to update. But I suspect that, for the list bellow, most of them are stuff where the driver maintainer just forgot at limbo. From the list of patches under review, we have: Waiting for new patch, signed, from Sven Barthpascaldra...@googlemail.com Apr,25 2010: Problem with cx25840 and Terratec Grabster AV400 http://patchwork.kernel.org/patch/94960 Sven Barthpascaldra...@googlemail.com Sven, We need a Signed-off-by: for your submitted patch: http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Sign_your_work Note, your patch has an obvious, unintentional white space change for if (std == V4L2_STD_NTSC_M_JP), so could you fix that up and send a new signed off version? Mauro, This patch makes obvious sense to me: don't perform audio register updates on a chip that doesn't have an audio processing block. Sven's approach was based on my recommended approach, after his initial discovery on how to get his audio working. Do we really need an S.O.B for something that appears to be common sense, and wouldn't have been implemented any other way, even if I had implemented it? The original patch were in the middle of a discussion, no proper description, bad whitespacing, etc. It is better to let the patch author to fix those issues, as they learn more about how to submit a patch. Anyway, I agree with you, the patch is obvious, and can proceed without the SOB. I did the usual CodingStyle fixups, put part of your above comment as the patch description, together with your ack and moved it forward. One patch less on my queue ;) Cheers, Mauro Eh... I thought I had superseeded it with the patch from 10th July (mail title: [PATCH] Add support for AUX_PLL on cx2583x chips). It included a Signed-of by from me as well as Acked by from Mike and Andy and I also excluded the whitespace change ^^ Regards, Sven -- 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
