Re: [libv4l-mcplugin PATCH 0/3] Media controller plugin for libv4l2
Hi, So judging from the directory layout, this is supposed to be a separate project, and not part of v4l-utils / libv4l, right? WRT my merging plans for libv4l. I've recently done some much needed work to better support high-res usb cameras. I plan to do a 0.8.4 release with that work included real soon. Once that is done I'll change the version in the Make.rules to 0.9.0-test and merge the plugin. Then we'll have some 0.9.x releases followed by some 0.9.9x release (all testing releases) followed by a 0.10.0 which should be the first stable release with plugin support. Regards, Hans On 05/19/2011 02:36 PM, Yordan Kamenov wrote: Hi, This is the Media Controller plugin for libv4l. It uses libv4l2 plugin support which is accepted by Hans De Goede, but not yet included in mainline libv4l2: http://www.spinics.net/lists/linux-media/msg32017.html The plugin allows a traditional v4l2 applications to work with Media Controller framework. The plugin is loaded when application opens /dev/video0 and it configures the media controller and then all ioctl's by the applicatin are handled by the plugin. The plugin implements init, close and ioctl callbacks. The init callback checks it's input file descriptor and if it coresponds to /dev/video0, then the media controller is initialized and appropriate pipeline is created. The close callback deinitializes the pipeline, and closes the media device. The ioctl callback is responsible to handle ioctl calls from application by using the media controller pipeline. The plugin uses media-ctl library for media controller operations: http://git.ideasonboard.org/?p=media-ctl.git;a=summary The plugin is divided in three separate patches: * Media Controller pipelines initialization, configuration and destruction * v4l operations - uses some functionality from the first one * Plugin interface operations (init, close and ioctl) - uses functionality from first two Yordan Kamenov (3): Add files for media controller pipelines Add files for v4l operations Add libv4l2 media controller plugin interface files -- 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: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
Hi Laurent,
On 05/19/2011 08:34 PM, Laurent Pinchart wrote:
The new v4l2_new_subdev_board() function creates and register a subdev
based on generic board information. The board information structure
includes a bus type and bus type-specific information.
Only I2C and SPI busses are currently supported.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-common.c | 70
+
drivers/media/video/v4l2-device.c |8
include/media/v4l2-common.h | 28 +++
include/media/v4l2-subdev.h |3 ++
4 files changed, 109 insertions(+), 0 deletions(-)
Hi everybody,
This approach has been briefly discussed during the Warsaw V4L meeting. Now
that support for platform subdevs has been requested, I'd like to move bus
type
handling to the V4L2 core instead of duplicating the logic in every driver. As
usual, comments will be appreciated.
Thanks for taking care of this.
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 06b9f9f..46aee94 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -474,6 +474,76 @@ EXPORT_SYMBOL_GPL(v4l2_spi_new_subdev);
#endif /* defined(CONFIG_SPI) */
+/*
+ * v4l2_new_subdev_board - Register a subdevice based on board information
+ * @v4l2_dev: Parent V4L2 device
+ * @info: I2C subdevs board information array
info doesn't appear to be a (I2C subdevs) array.
+ *
+ * Register a subdevice identified by a geenric board information structure.
The
s/geenric/generic ?
+ * structure contains the bus type and bus type-specific information.
+ *
+ * Return a pointer to the subdevice if registration was successful, or NULL
+ * otherwise.
+ */
+struct v4l2_subdev *v4l2_new_subdev_board(struct v4l2_device *v4l2_dev,
+ struct v4l2_subdev_board_info *info)
+{
+ struct v4l2_subdev *subdev;
+
+ switch (info-type) {
+#if defined(CONFIG_I2C)
+ case V4L2_SUBDEV_BUS_TYPE_I2C: {
+ struct i2c_adapter *adapter;
+
+ adapter = i2c_get_adapter(info-info.i2c.i2c_adapter_id);
+ if (adapter == NULL) {
+ printk(KERN_ERR %s: Unable to get I2C adapter %d for
+ device %s/%u\n, __func__,
+ info-info.i2c.i2c_adapter_id,
+ info-info.i2c.board_info-type,
+ info-info.i2c.board_info-addr);
+ return NULL;
+ }
+
+ subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adapter,
+ info-info.i2c.board_info, NULL);
+ if (subdev == NULL) {
+ i2c_put_adapter(adapter);
+ return NULL;
+ }
+
+ subdev-flags |= V4L2_SUBDEV_FL_RELEASE_ADAPTER;
+ break;
+ }
+#endif /* defined(CONFIG_I2C) */
+#if defined(CONFIG_SPI)
+ case V4L2_SUBDEV_BUS_TYPE_SPI: {
+ struct spi_master *master;
+
+ master = spi_busnum_to_master(info-info.spi-bus_num);
+ if (master == NULL) {
+ printk(KERN_ERR %s: Unable to get SPI master %u for
+ device %s/%u\n, __func__,
+ info-info.spi-bus_num,
+ info-info.spi-modalias,
+ info-info.spi-chip_select);
+ return NULL;
+ }
+
+ subdev = v4l2_spi_new_subdev(v4l2_dev, master, info-info.spi);
+ spi_master_put(master);
+ break;
+ }
+#endif /* defined(CONFIG_SPI) */
+ default:
+ subdev = NULL;
+ break;
+ }
+
+ return subdev;
+}
+EXPORT_SYMBOL_GPL(v4l2_new_subdev_board);
I'm just wondering, while we are at it, if it would be worth to try to make
v4l2_i2c_new_subdev_board() and v4l2_spi_new_subdev() race-free. There has
been an attempt from Guennadi side to solve this issue,
http://thread.gmane.org/gmane.linux.kernel/1069603
After request_module there is nothing preventing subdev's driver module to be
unloaded and thus it is not safe to dereference dev-driver-owner.
+
/* Clamp x to be between min and max, aligned to a multiple of 2^align. min
* and max don't have to be aligned, but there must be at least one valid
* value. E.g., min=17,max=31,align=4 is not allowed as there are no
multiples
diff --git a/drivers/media/video/v4l2-device.c
b/drivers/media/video/v4l2-device.c
index 4aae501..cfd9caf 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -246,5 +246,13 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev
*sd)
#endif
video_unregister_device(sd-devnode);
module_put(sd-owner);
+
+#if defined(CONFIG_I2C) || (defined(CONFIG_I2C_MODULE)
Re: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
Hi Sylwester,
On Friday 20 May 2011 09:14:36 Sylwester Nawrocki wrote:
On 05/19/2011 08:34 PM, Laurent Pinchart wrote:
The new v4l2_new_subdev_board() function creates and register a subdev
based on generic board information. The board information structure
includes a bus type and bus type-specific information.
Only I2C and SPI busses are currently supported.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-common.c | 70
+ drivers/media/video/v4l2-device.c
|8
include/media/v4l2-common.h | 28 +++
include/media/v4l2-subdev.h |3 ++
4 files changed, 109 insertions(+), 0 deletions(-)
Hi everybody,
This approach has been briefly discussed during the Warsaw V4L meeting.
Now that support for platform subdevs has been requested, I'd like to
move bus type handling to the V4L2 core instead of duplicating the logic
in every driver. As usual, comments will be appreciated.
Thanks for taking care of this.
You're welcome. Thanks for the review.
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c index 06b9f9f..46aee94 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -474,6 +474,76 @@ EXPORT_SYMBOL_GPL(v4l2_spi_new_subdev);
#endif /* defined(CONFIG_SPI) */
+/*
+ * v4l2_new_subdev_board - Register a subdevice based on board
information + * @v4l2_dev: Parent V4L2 device
+ * @info: I2C subdevs board information array
info doesn't appear to be a (I2C subdevs) array.
Oops, I'll fix it.
+ *
+ * Register a subdevice identified by a geenric board information
structure. The
s/geenric/generic ?
Ditto.
+ * structure contains the bus type and bus type-specific information.
+ *
+ * Return a pointer to the subdevice if registration was successful, or
NULL + * otherwise.
+ */
+struct v4l2_subdev *v4l2_new_subdev_board(struct v4l2_device *v4l2_dev,
+ struct v4l2_subdev_board_info *info)
+{
+ struct v4l2_subdev *subdev;
+
+ switch (info-type) {
+#if defined(CONFIG_I2C)
+ case V4L2_SUBDEV_BUS_TYPE_I2C: {
+ struct i2c_adapter *adapter;
+
+ adapter = i2c_get_adapter(info-info.i2c.i2c_adapter_id);
+ if (adapter == NULL) {
+ printk(KERN_ERR %s: Unable to get I2C adapter %d for
+ device %s/%u\n, __func__,
+ info-info.i2c.i2c_adapter_id,
+ info-info.i2c.board_info-type,
+ info-info.i2c.board_info-addr);
+ return NULL;
+ }
+
+ subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adapter,
+ info-info.i2c.board_info, NULL);
+ if (subdev == NULL) {
+ i2c_put_adapter(adapter);
+ return NULL;
+ }
+
+ subdev-flags |= V4L2_SUBDEV_FL_RELEASE_ADAPTER;
+ break;
+ }
+#endif /* defined(CONFIG_I2C) */
+#if defined(CONFIG_SPI)
+ case V4L2_SUBDEV_BUS_TYPE_SPI: {
+ struct spi_master *master;
+
+ master = spi_busnum_to_master(info-info.spi-bus_num);
+ if (master == NULL) {
+ printk(KERN_ERR %s: Unable to get SPI master %u for
+ device %s/%u\n, __func__,
+ info-info.spi-bus_num,
+ info-info.spi-modalias,
+ info-info.spi-chip_select);
+ return NULL;
+ }
+
+ subdev = v4l2_spi_new_subdev(v4l2_dev, master, info-info.spi);
+ spi_master_put(master);
+ break;
+ }
+#endif /* defined(CONFIG_SPI) */
+ default:
+ subdev = NULL;
+ break;
+ }
+
+ return subdev;
+}
+EXPORT_SYMBOL_GPL(v4l2_new_subdev_board);
I'm just wondering, while we are at it, if it would be worth to try to make
v4l2_i2c_new_subdev_board() and v4l2_spi_new_subdev() race-free. There has
been an attempt from Guennadi side to solve this issue,
http://thread.gmane.org/gmane.linux.kernel/1069603
After request_module there is nothing preventing subdev's driver module to
be unloaded and thus it is not safe to dereference dev-driver-owner.
Please see below.
+
/* Clamp x to be between min and max, aligned to a multiple of 2^align.
min
* and max don't have to be aligned, but there must be at least one
valid * value. E.g., min=17,max=31,align=4 is not allowed as there
are no multiples
diff --git a/drivers/media/video/v4l2-device.c
b/drivers/media/video/v4l2-device.c index 4aae501..cfd9caf 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -246,5 +246,13 @@ void
Re: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
On 05/20/2011 09:29 AM, Laurent Pinchart wrote: [snip] I had an issue when tried to call request_module, to register subdev of platform device type, in probe() of other platform device. Driver's probe() for devices belonging same bus type cannot be nested as the bus lock is taken by the driver core before entering probe(), so this would lead to a deadlock. That exactly happens in __driver_attach(). For the same reason v4l2_new_subdev_board could not be called from probe() of devices belonging to I2C or SPI bus, as request_module is called inside of it. I'm not sure how to solve it, yet:) Ouch. I wasn't aware of that issue. Looks like it's indeed time to fix the subdev registration issue, including the module load race condition. Michael, you said you have a patch to add platform subdev support, how have you avoided the race condition ? I spoke too soon. This deadlock is staring me in the face right now, too. Ouch, indeed. [snip] MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] soc-camera for 2.6.40
Hi Mauro, Sorry, a bit late again... Here go patches for 2.6.40: The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-2.6.40 Guennadi Liakhovetski (9): V4L: sh_mobile_ceu_camera: implement .stop_streaming() V4L: mx3_camera: implement .stop_streaming() V4L: soc-camera: add a livecrop host operation V4L: sh_mobile_ceu_camera: implement live cropping V4L: soc-camera: avoid huge arrays, caused by changed format codes V4L: omap1-camera: fix huge lookup array V4L: soc-camera: add a new packing for YUV 4:2:0 type formats V4L: soc-camera: add more format look-up entries V4L: soc-camera: a missing mediabus code - fourcc translation is not critical Kassey Li (2): V4L: soc-camera: add JPEG support V4L: soc-camera: add MIPI bus flags Sergio Aguirre (1): V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c Sylwester Nawrocki (1): V4L: Add V4L2_MBUS_FMT_JPEG_1X8 media bus format Teresa Gámez (2): V4L: mt9v022: fix pixel clock V4L: mt9m111: fix pixel clock Documentation/DocBook/v4l/subdev-formats.xml | 46 + drivers/media/video/mt9m111.c| 14 ++- drivers/media/video/mt9v022.c|2 +- drivers/media/video/mx3_camera.c | 60 +-- drivers/media/video/omap1_camera.c | 43 +++-- drivers/media/video/pxa_camera.c |8 +- drivers/media/video/sh_mobile_ceu_camera.c | 148 +-- drivers/media/video/soc_camera.c | 77 ++-- drivers/media/video/soc_mediabus.c | 265 +++--- include/linux/v4l2-mediabus.h|3 + include/media/soc_camera.h | 15 ++- include/media/soc_mediabus.h | 25 +++- 12 files changed, 608 insertions(+), 98 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libv4l-mcplugin PATCH 0/3] Media controller plugin for libv4l2
Hans de Goede wrote: Hi, Hi Hans, So judging from the directory layout, this is supposed to be a separate project, and not part of v4l-utils / libv4l, right? It is separate now, but I guess that at some point it would be good to have 'plugins' directory containing some generic plugins as part of libv4l. Regards Yordan WRT my merging plans for libv4l. I've recently done some much needed work to better support high-res usb cameras. I plan to do a 0.8.4 release with that work included real soon. Once that is done I'll change the version in the Make.rules to 0.9.0-test and merge the plugin. Then we'll have some 0.9.x releases followed by some 0.9.9x release (all testing releases) followed by a 0.10.0 which should be the first stable release with plugin support. Regards, Hans On 05/19/2011 02:36 PM, Yordan Kamenov wrote: Hi, This is the Media Controller plugin for libv4l. It uses libv4l2 plugin support which is accepted by Hans De Goede, but not yet included in mainline libv4l2: http://www.spinics.net/lists/linux-media/msg32017.html The plugin allows a traditional v4l2 applications to work with Media Controller framework. The plugin is loaded when application opens /dev/video0 and it configures the media controller and then all ioctl's by the applicatin are handled by the plugin. The plugin implements init, close and ioctl callbacks. The init callback checks it's input file descriptor and if it coresponds to /dev/video0, then the media controller is initialized and appropriate pipeline is created. The close callback deinitializes the pipeline, and closes the media device. The ioctl callback is responsible to handle ioctl calls from application by using the media controller pipeline. The plugin uses media-ctl library for media controller operations: http://git.ideasonboard.org/?p=media-ctl.git;a=summary The plugin is divided in three separate patches: * Media Controller pipelines initialization, configuration and destruction * v4l operations - uses some functionality from the first one * Plugin interface operations (init, close and ioctl) - uses functionality from first two Yordan Kamenov (3): Add files for media controller pipelines Add files for v4l operations Add libv4l2 media controller plugin interface files -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
On Friday, May 20, 2011 09:29:32 Laurent Pinchart wrote:
Hi Sylwester,
On Friday 20 May 2011 09:14:36 Sylwester Nawrocki wrote:
On 05/19/2011 08:34 PM, Laurent Pinchart wrote:
The new v4l2_new_subdev_board() function creates and register a subdev
based on generic board information. The board information structure
includes a bus type and bus type-specific information.
Only I2C and SPI busses are currently supported.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-common.c | 70
+ drivers/media/video/v4l2-device.c
|8
include/media/v4l2-common.h | 28 +++
include/media/v4l2-subdev.h |3 ++
4 files changed, 109 insertions(+), 0 deletions(-)
Hi everybody,
This approach has been briefly discussed during the Warsaw V4L meeting.
Now that support for platform subdevs has been requested, I'd like to
move bus type handling to the V4L2 core instead of duplicating the logic
in every driver. As usual, comments will be appreciated.
Thanks for taking care of this.
You're welcome. Thanks for the review.
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c index 06b9f9f..46aee94 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -474,6 +474,76 @@ EXPORT_SYMBOL_GPL(v4l2_spi_new_subdev);
#endif /* defined(CONFIG_SPI) */
+/*
+ * v4l2_new_subdev_board - Register a subdevice based on board
information + * @v4l2_dev: Parent V4L2 device
+ * @info: I2C subdevs board information array
info doesn't appear to be a (I2C subdevs) array.
Oops, I'll fix it.
+ *
+ * Register a subdevice identified by a geenric board information
structure. The
s/geenric/generic ?
Ditto.
+ * structure contains the bus type and bus type-specific information.
+ *
+ * Return a pointer to the subdevice if registration was successful, or
NULL + * otherwise.
+ */
+struct v4l2_subdev *v4l2_new_subdev_board(struct v4l2_device *v4l2_dev,
+ struct v4l2_subdev_board_info *info)
+{
+ struct v4l2_subdev *subdev;
+
+ switch (info-type) {
+#if defined(CONFIG_I2C)
+ case V4L2_SUBDEV_BUS_TYPE_I2C: {
+ struct i2c_adapter *adapter;
+
+ adapter = i2c_get_adapter(info-info.i2c.i2c_adapter_id);
+ if (adapter == NULL) {
+ printk(KERN_ERR %s: Unable to get I2C adapter %d for
+ device %s/%u\n, __func__,
+ info-info.i2c.i2c_adapter_id,
+ info-info.i2c.board_info-type,
+ info-info.i2c.board_info-addr);
+ return NULL;
+ }
+
+ subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adapter,
+ info-info.i2c.board_info, NULL);
+ if (subdev == NULL) {
+ i2c_put_adapter(adapter);
+ return NULL;
+ }
+
+ subdev-flags |= V4L2_SUBDEV_FL_RELEASE_ADAPTER;
+ break;
+ }
+#endif /* defined(CONFIG_I2C) */
+#if defined(CONFIG_SPI)
+ case V4L2_SUBDEV_BUS_TYPE_SPI: {
+ struct spi_master *master;
+
+ master = spi_busnum_to_master(info-info.spi-bus_num);
+ if (master == NULL) {
+ printk(KERN_ERR %s: Unable to get SPI master %u for
+ device %s/%u\n, __func__,
+ info-info.spi-bus_num,
+ info-info.spi-modalias,
+ info-info.spi-chip_select);
+ return NULL;
+ }
+
+ subdev = v4l2_spi_new_subdev(v4l2_dev, master, info-info.spi);
+ spi_master_put(master);
+ break;
+ }
+#endif /* defined(CONFIG_SPI) */
+ default:
+ subdev = NULL;
+ break;
+ }
+
+ return subdev;
+}
+EXPORT_SYMBOL_GPL(v4l2_new_subdev_board);
I'm just wondering, while we are at it, if it would be worth to try to
make
v4l2_i2c_new_subdev_board() and v4l2_spi_new_subdev() race-free. There has
been an attempt from Guennadi side to solve this issue,
http://thread.gmane.org/gmane.linux.kernel/1069603
After request_module there is nothing preventing subdev's driver module to
be unloaded and thus it is not safe to dereference dev-driver-owner.
Please see below.
+
/* Clamp x to be between min and max, aligned to a multiple of 2^align.
min
* and max don't have to be aligned, but there must be at least one
valid * value. E.g., min=17,max=31,align=4 is not allowed as there
are no multiples
diff --git a/drivers/media/video/v4l2-device.c
b/drivers/media/video/v4l2-device.c index 4aae501..cfd9caf 100644
---
Re: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
Hi Hans, On Friday 20 May 2011 10:53:32 Hans Verkuil wrote: On Friday, May 20, 2011 09:29:32 Laurent Pinchart wrote: On Friday 20 May 2011 09:14:36 Sylwester Nawrocki wrote: On 05/19/2011 08:34 PM, Laurent Pinchart wrote: The new v4l2_new_subdev_board() function creates and register a subdev based on generic board information. The board information structure includes a bus type and bus type-specific information. Only I2C and SPI busses are currently supported. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com [snip] I had an issue when tried to call request_module, to register subdev of platform device type, in probe() of other platform device. Driver's probe() for devices belonging same bus type cannot be nested as the bus lock is taken by the driver core before entering probe(), so this would lead to a deadlock. That exactly happens in __driver_attach(). For the same reason v4l2_new_subdev_board could not be called from probe() of devices belonging to I2C or SPI bus, as request_module is called inside of it. I'm not sure how to solve it, yet:) Ouch. I wasn't aware of that issue. Looks like it's indeed time to fix the subdev registration issue, including the module load race condition. Michael, you said you have a patch to add platform subdev support, how have you avoided the race condition ? I've been thinking for some time now about removing the module load code completely. I2C, SPI and platform subdevs would be registered either by board code (possibly through the device tree on platforms that suppport it) for embedded platforms, and by host drivers for pluggable hardware (PCI and USB). Module loading would be handled automatically by the kernel module auto loader, but asynchronously instead of synchronously. Bus notifiers would then be used by host drivers to wait for all subdevs to be registered. I'm not sure yet if this approach is viable. Hans, I think we've briefly discussed this (possible quite a long time ago), do you have any opinion ? Guennadi, based on your previous experience trying to use bus notifiers to solve the module load race, what do you think about the idea ? Others, please comment as well :-) It's definitely viable (I believe the required bus notification has been added some time ago), but I am not sure how to implement it in an efficient manner. My initial idea would be to just wait in v4l2_new_subdev_board until you get the notification on the bus (with a timeout, of course). However, I suspect that that does not solve the deadlock, although it would solve the race. As an aside: note that if the module is unloaded right after the request_module, then that will be detected by the code and it will just return an error. It won't oops or anything like that. Personally I don't believe it is worth the effort just to solve this race, since it is highly theoretical. The problem of loading another bus module when in a bus probe function is a separate issue. My initial reaction is: why do you want to do this? Even if you use delayed module loads, you probably still have to wait for them to succeed at a higher-level function. For example: in the probe function of module A it will attempt to load module B. That probably can't succeed as long as you are in A's probe function due to the bus lock. So you can't check for a successful load of B until you return from that probe function and a higher- level function (that likely loaded module A in the first place) does that check. That's all pretty tricky code, and my suggestion would be to simply not do nested module loads from the same bus. That's unfortunately not an option. Most bridge/host devices in embedded systems are platform devices, and they will need to load platform subdevs. We need to fix that. My idea was to use bus notifiers to delay the bridge/host device initialization. The bridge probe() function would pre-initialize the bridge and register notifiers. The driver would then wait until all subdevs are properly registered, and then proceed from to register V4L2 devices from the bus notifier callback (or possible a work queue). There would be no nested probe() calls. -- 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: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
On Friday, May 20, 2011 11:05:00 Laurent Pinchart wrote: Hi Hans, On Friday 20 May 2011 10:53:32 Hans Verkuil wrote: On Friday, May 20, 2011 09:29:32 Laurent Pinchart wrote: On Friday 20 May 2011 09:14:36 Sylwester Nawrocki wrote: On 05/19/2011 08:34 PM, Laurent Pinchart wrote: The new v4l2_new_subdev_board() function creates and register a subdev based on generic board information. The board information structure includes a bus type and bus type-specific information. Only I2C and SPI busses are currently supported. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com [snip] I had an issue when tried to call request_module, to register subdev of platform device type, in probe() of other platform device. Driver's probe() for devices belonging same bus type cannot be nested as the bus lock is taken by the driver core before entering probe(), so this would lead to a deadlock. That exactly happens in __driver_attach(). For the same reason v4l2_new_subdev_board could not be called from probe() of devices belonging to I2C or SPI bus, as request_module is called inside of it. I'm not sure how to solve it, yet:) Ouch. I wasn't aware of that issue. Looks like it's indeed time to fix the subdev registration issue, including the module load race condition. Michael, you said you have a patch to add platform subdev support, how have you avoided the race condition ? I've been thinking for some time now about removing the module load code completely. I2C, SPI and platform subdevs would be registered either by board code (possibly through the device tree on platforms that suppport it) for embedded platforms, and by host drivers for pluggable hardware (PCI and USB). Module loading would be handled automatically by the kernel module auto loader, but asynchronously instead of synchronously. Bus notifiers would then be used by host drivers to wait for all subdevs to be registered. I'm not sure yet if this approach is viable. Hans, I think we've briefly discussed this (possible quite a long time ago), do you have any opinion ? Guennadi, based on your previous experience trying to use bus notifiers to solve the module load race, what do you think about the idea ? Others, please comment as well :-) It's definitely viable (I believe the required bus notification has been added some time ago), but I am not sure how to implement it in an efficient manner. My initial idea would be to just wait in v4l2_new_subdev_board until you get the notification on the bus (with a timeout, of course). However, I suspect that that does not solve the deadlock, although it would solve the race. As an aside: note that if the module is unloaded right after the request_module, then that will be detected by the code and it will just return an error. It won't oops or anything like that. Personally I don't believe it is worth the effort just to solve this race, since it is highly theoretical. The problem of loading another bus module when in a bus probe function is a separate issue. My initial reaction is: why do you want to do this? Even if you use delayed module loads, you probably still have to wait for them to succeed at a higher-level function. For example: in the probe function of module A it will attempt to load module B. That probably can't succeed as long as you are in A's probe function due to the bus lock. So you can't check for a successful load of B until you return from that probe function and a higher- level function (that likely loaded module A in the first place) does that check. That's all pretty tricky code, and my suggestion would be to simply not do nested module loads from the same bus. That's unfortunately not an option. Most bridge/host devices in embedded systems are platform devices, and they will need to load platform subdevs. We need to fix that. Good point. My idea was to use bus notifiers to delay the bridge/host device initialization. The bridge probe() function would pre-initialize the bridge and register notifiers. The driver would then wait until all subdevs are properly registered, and then proceed from to register V4L2 devices from the bus notifier callback (or possible a work queue). There would be no nested probe() calls. Would it be an option to create a new platform bus for the subdevs? That would have its own lock. It makes sense from a hierarchical point of view, but I'm not certain about the amount of work involved. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
Hi Hans, On Friday 20 May 2011 11:19:48 Hans Verkuil wrote: On Friday, May 20, 2011 11:05:00 Laurent Pinchart wrote: On Friday 20 May 2011 10:53:32 Hans Verkuil wrote: On Friday, May 20, 2011 09:29:32 Laurent Pinchart wrote: On Friday 20 May 2011 09:14:36 Sylwester Nawrocki wrote: On 05/19/2011 08:34 PM, Laurent Pinchart wrote: The new v4l2_new_subdev_board() function creates and register a subdev based on generic board information. The board information structure includes a bus type and bus type-specific information. Only I2C and SPI busses are currently supported. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com [snip] I had an issue when tried to call request_module, to register subdev of platform device type, in probe() of other platform device. Driver's probe() for devices belonging same bus type cannot be nested as the bus lock is taken by the driver core before entering probe(), so this would lead to a deadlock. That exactly happens in __driver_attach(). For the same reason v4l2_new_subdev_board could not be called from probe() of devices belonging to I2C or SPI bus, as request_module is called inside of it. I'm not sure how to solve it, yet:) Ouch. I wasn't aware of that issue. Looks like it's indeed time to fix the subdev registration issue, including the module load race condition. Michael, you said you have a patch to add platform subdev support, how have you avoided the race condition ? I've been thinking for some time now about removing the module load code completely. I2C, SPI and platform subdevs would be registered either by board code (possibly through the device tree on platforms that suppport it) for embedded platforms, and by host drivers for pluggable hardware (PCI and USB). Module loading would be handled automatically by the kernel module auto loader, but asynchronously instead of synchronously. Bus notifiers would then be used by host drivers to wait for all subdevs to be registered. I'm not sure yet if this approach is viable. Hans, I think we've briefly discussed this (possible quite a long time ago), do you have any opinion ? Guennadi, based on your previous experience trying to use bus notifiers to solve the module load race, what do you think about the idea ? Others, please comment as well :-) It's definitely viable (I believe the required bus notification has been added some time ago), but I am not sure how to implement it in an efficient manner. My initial idea would be to just wait in v4l2_new_subdev_board until you get the notification on the bus (with a timeout, of course). However, I suspect that that does not solve the deadlock, although it would solve the race. As an aside: note that if the module is unloaded right after the request_module, then that will be detected by the code and it will just return an error. It won't oops or anything like that. Personally I don't believe it is worth the effort just to solve this race, since it is highly theoretical. The problem of loading another bus module when in a bus probe function is a separate issue. My initial reaction is: why do you want to do this? Even if you use delayed module loads, you probably still have to wait for them to succeed at a higher-level function. For example: in the probe function of module A it will attempt to load module B. That probably can't succeed as long as you are in A's probe function due to the bus lock. So you can't check for a successful load of B until you return from that probe function and a higher- level function (that likely loaded module A in the first place) does that check. That's all pretty tricky code, and my suggestion would be to simply not do nested module loads from the same bus. That's unfortunately not an option. Most bridge/host devices in embedded systems are platform devices, and they will need to load platform subdevs. We need to fix that. Good point. My idea was to use bus notifiers to delay the bridge/host device initialization. The bridge probe() function would pre-initialize the bridge and register notifiers. The driver would then wait until all subdevs are properly registered, and then proceed from to register V4L2 devices from the bus notifier callback (or possible a work queue). There would be no nested probe() calls. Would it be an option to create a new platform bus for the subdevs? That would have its own lock. It makes sense from a hierarchical point of view, but I'm not certain about the amount of work involved. Do you mean a subdev-platform bus for platform subdevs, or a V4L2 subdev bus for all subdevs ? The first option is possible, but it looks more like a hack to me. If the subdev really is a platform device, it
Re: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
On Friday, May 20, 2011 11:37:24 Laurent Pinchart wrote: Hi Hans, On Friday 20 May 2011 11:19:48 Hans Verkuil wrote: On Friday, May 20, 2011 11:05:00 Laurent Pinchart wrote: On Friday 20 May 2011 10:53:32 Hans Verkuil wrote: On Friday, May 20, 2011 09:29:32 Laurent Pinchart wrote: On Friday 20 May 2011 09:14:36 Sylwester Nawrocki wrote: On 05/19/2011 08:34 PM, Laurent Pinchart wrote: The new v4l2_new_subdev_board() function creates and register a subdev based on generic board information. The board information structure includes a bus type and bus type-specific information. Only I2C and SPI busses are currently supported. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com [snip] I had an issue when tried to call request_module, to register subdev of platform device type, in probe() of other platform device. Driver's probe() for devices belonging same bus type cannot be nested as the bus lock is taken by the driver core before entering probe(), so this would lead to a deadlock. That exactly happens in __driver_attach(). For the same reason v4l2_new_subdev_board could not be called from probe() of devices belonging to I2C or SPI bus, as request_module is called inside of it. I'm not sure how to solve it, yet:) Ouch. I wasn't aware of that issue. Looks like it's indeed time to fix the subdev registration issue, including the module load race condition. Michael, you said you have a patch to add platform subdev support, how have you avoided the race condition ? I've been thinking for some time now about removing the module load code completely. I2C, SPI and platform subdevs would be registered either by board code (possibly through the device tree on platforms that suppport it) for embedded platforms, and by host drivers for pluggable hardware (PCI and USB). Module loading would be handled automatically by the kernel module auto loader, but asynchronously instead of synchronously. Bus notifiers would then be used by host drivers to wait for all subdevs to be registered. I'm not sure yet if this approach is viable. Hans, I think we've briefly discussed this (possible quite a long time ago), do you have any opinion ? Guennadi, based on your previous experience trying to use bus notifiers to solve the module load race, what do you think about the idea ? Others, please comment as well :-) It's definitely viable (I believe the required bus notification has been added some time ago), but I am not sure how to implement it in an efficient manner. My initial idea would be to just wait in v4l2_new_subdev_board until you get the notification on the bus (with a timeout, of course). However, I suspect that that does not solve the deadlock, although it would solve the race. As an aside: note that if the module is unloaded right after the request_module, then that will be detected by the code and it will just return an error. It won't oops or anything like that. Personally I don't believe it is worth the effort just to solve this race, since it is highly theoretical. The problem of loading another bus module when in a bus probe function is a separate issue. My initial reaction is: why do you want to do this? Even if you use delayed module loads, you probably still have to wait for them to succeed at a higher-level function. For example: in the probe function of module A it will attempt to load module B. That probably can't succeed as long as you are in A's probe function due to the bus lock. So you can't check for a successful load of B until you return from that probe function and a higher- level function (that likely loaded module A in the first place) does that check. That's all pretty tricky code, and my suggestion would be to simply not do nested module loads from the same bus. That's unfortunately not an option. Most bridge/host devices in embedded systems are platform devices, and they will need to load platform subdevs. We need to fix that. Good point. My idea was to use bus notifiers to delay the bridge/host device initialization. The bridge probe() function would pre-initialize the bridge and register notifiers. The driver would then wait until all subdevs are properly registered, and then proceed from to register V4L2 devices from the bus notifier callback (or possible a work queue). There would be no nested probe() calls. Would it be an option to create a new platform bus for the subdevs? That would have its own lock. It makes sense from a hierarchical point of view, but I'm not certain about the amount of work involved. Do you mean a subdev-platform bus for platform subdevs,
Re: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
Hi Hans, On Friday 20 May 2011 11:52:17 Hans Verkuil wrote: On Friday, May 20, 2011 11:37:24 Laurent Pinchart wrote: On Friday 20 May 2011 11:19:48 Hans Verkuil wrote: On Friday, May 20, 2011 11:05:00 Laurent Pinchart wrote: [snip] My idea was to use bus notifiers to delay the bridge/host device initialization. The bridge probe() function would pre-initialize the bridge and register notifiers. The driver would then wait until all subdevs are properly registered, and then proceed from to register V4L2 devices from the bus notifier callback (or possible a work queue). There would be no nested probe() calls. Would it be an option to create a new platform bus for the subdevs? That would have its own lock. It makes sense from a hierarchical point of view, but I'm not certain about the amount of work involved. Do you mean a subdev-platform bus for platform subdevs, or a V4L2 subdev bus for all subdevs ? The first option is possible, but it looks more like a hack to me. If the subdev really is a platform device, it should be handled by the platform bus. The first. So you have a 'top-level' platform device that wants to load platform subdevs (probably representing internal IP blocks). So it would create its own platform bus that is used to probe those platform subdevs. It is similar to e.g. an I2C device that has internal I2C busses: you would also create nested busses there. BTW, why do these platform subdevs have to be on the platform bus? Why not have standalone subdev drivers that are not on any bus? That's for example what ivtv does for the internal GPIO audio subdev. There's some misunderstanging here. Internal IP blocks don't need to sit on any bus. The host/bridge driver can create subdevs for those blocks directly, as it doesn't need to load a separate driver. The issue comes from external subdevs that offer little control or even none at all. The best example is an FPGA that will feed video data to the bridge in a fixed format without any mean of control, or with just an on/off control through a GPIO. Support for such subdevices need to be handled by a separate driver, so we need a way to load it at runtime. I'm not sure on what bus that driver should sit. I don't think the second option is possible, I2C and SPI subdevs need to sit on an I2C or SPI bus (I could be mistaken though, there's at least one example of a logical bus type in the kernel with the HID bus). Let's also not forget about sub-sub-devices. We need to handle them at some point as well. Sub-sub-devices are not a problem by themselves. They are only a problem if they on the same bus. This being said, I think that the use of platform devices to solve the initial problem can also be considered a hack as well. What we really need is a way to handle subdevs that can't be controlled at all (a video source that continuously delivers data for instance), or that can be controlled through GPIO. What bus should we use for a bus-less subdev ? And for GPIO-based subdevs, should we create a GPIO bus ? It is perfectly possible to have bus-less subdevs. See ivtv (I think there are one or two other examples as well). But how can we handle bus-less subdevs for embedded devices, where the host (e.g. OMAP3 ISP) doesn't know about the external subdevs (e.g. FPGA controlled by a couple of GPIOs) ? -- 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: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
Hi Hans, On 05/20/2011 11:52 AM, Hans Verkuil wrote: On Friday, May 20, 2011 11:37:24 Laurent Pinchart wrote: Hi Hans, On Friday 20 May 2011 11:19:48 Hans Verkuil wrote: On Friday, May 20, 2011 11:05:00 Laurent Pinchart wrote: On Friday 20 May 2011 10:53:32 Hans Verkuil wrote: On Friday, May 20, 2011 09:29:32 Laurent Pinchart wrote: On Friday 20 May 2011 09:14:36 Sylwester Nawrocki wrote: On 05/19/2011 08:34 PM, Laurent Pinchart wrote: The new v4l2_new_subdev_board() function creates and register a subdev based on generic board information. The board information structure includes a bus type and bus type-specific information. Only I2C and SPI busses are currently supported. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com [snip] I had an issue when tried to call request_module, to register subdev of platform device type, in probe() of other platform device. Driver's probe() for devices belonging same bus type cannot be nested as the bus lock is taken by the driver core before entering probe(), so this would lead to a deadlock. That exactly happens in __driver_attach(). For the same reason v4l2_new_subdev_board could not be called from probe() of devices belonging to I2C or SPI bus, as request_module is called inside of it. I'm not sure how to solve it, yet:) Ouch. I wasn't aware of that issue. Looks like it's indeed time to fix the subdev registration issue, including the module load race condition. Michael, you said you have a patch to add platform subdev support, how have you avoided the race condition ? I've been thinking for some time now about removing the module load code completely. I2C, SPI and platform subdevs would be registered either by board code (possibly through the device tree on platforms that suppport it) for embedded platforms, and by host drivers for pluggable hardware (PCI and USB). Module loading would be handled automatically by the kernel module auto loader, but asynchronously instead of synchronously. Bus notifiers would then be used by host drivers to wait for all subdevs to be registered. I'm not sure yet if this approach is viable. Hans, I think we've briefly discussed this (possible quite a long time ago), do you have any opinion ? Guennadi, based on your previous experience trying to use bus notifiers to solve the module load race, what do you think about the idea ? Others, please comment as well :-) It's definitely viable (I believe the required bus notification has been added some time ago), but I am not sure how to implement it in an efficient manner. My initial idea would be to just wait in v4l2_new_subdev_board until you get the notification on the bus (with a timeout, of course). However, I suspect that that does not solve the deadlock, although it would solve the race. As an aside: note that if the module is unloaded right after the request_module, then that will be detected by the code and it will just return an error. It won't oops or anything like that. Personally I don't believe it is worth the effort just to solve this race, since it is highly theoretical. The problem of loading another bus module when in a bus probe function is a separate issue. My initial reaction is: why do you want to do this? Even if you use delayed module loads, you probably still have to wait for them to succeed at a higher-level function. For example: in the probe function of module A it will attempt to load module B. That probably can't succeed as long as you are in A's probe function due to the bus lock. So you can't check for a successful load of B until you return from that probe function and a higher- level function (that likely loaded module A in the first place) does that check. That's all pretty tricky code, and my suggestion would be to simply not do nested module loads from the same bus. That's unfortunately not an option. Most bridge/host devices in embedded systems are platform devices, and they will need to load platform subdevs. We need to fix that. Good point. My idea was to use bus notifiers to delay the bridge/host device initialization. The bridge probe() function would pre-initialize the bridge and register notifiers. The driver would then wait until all subdevs are properly registered, and then proceed from to register V4L2 devices from the bus notifier callback (or possible a work queue). There would be no nested probe() calls. Would it be an option to create a new platform bus for the subdevs? That would have its own lock. It makes sense from a hierarchical point of view, but I'm not certain about the amount of work involved. Do you mean a subdev-platform bus for platform subdevs, or a V4L2 subdev bus for all subdevs ? The first option is possible, but it looks more like a hack to me. If the subdev really is a platform device, it should be handled by the platform bus. The first. So you have a 'top-level' platform device that wants to
Re: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
On Friday, May 20, 2011 12:12:23 Laurent Pinchart wrote: Hi Hans, On Friday 20 May 2011 11:52:17 Hans Verkuil wrote: On Friday, May 20, 2011 11:37:24 Laurent Pinchart wrote: On Friday 20 May 2011 11:19:48 Hans Verkuil wrote: On Friday, May 20, 2011 11:05:00 Laurent Pinchart wrote: [snip] My idea was to use bus notifiers to delay the bridge/host device initialization. The bridge probe() function would pre-initialize the bridge and register notifiers. The driver would then wait until all subdevs are properly registered, and then proceed from to register V4L2 devices from the bus notifier callback (or possible a work queue). There would be no nested probe() calls. Would it be an option to create a new platform bus for the subdevs? That would have its own lock. It makes sense from a hierarchical point of view, but I'm not certain about the amount of work involved. Do you mean a subdev-platform bus for platform subdevs, or a V4L2 subdev bus for all subdevs ? The first option is possible, but it looks more like a hack to me. If the subdev really is a platform device, it should be handled by the platform bus. The first. So you have a 'top-level' platform device that wants to load platform subdevs (probably representing internal IP blocks). So it would create its own platform bus that is used to probe those platform subdevs. It is similar to e.g. an I2C device that has internal I2C busses: you would also create nested busses there. BTW, why do these platform subdevs have to be on the platform bus? Why not have standalone subdev drivers that are not on any bus? That's for example what ivtv does for the internal GPIO audio subdev. There's some misunderstanging here. Internal IP blocks don't need to sit on any bus. The host/bridge driver can create subdevs for those blocks directly, as it doesn't need to load a separate driver. The issue comes from external subdevs that offer little control or even none at all. The best example is an FPGA that will feed video data to the bridge in a fixed format without any mean of control, or with just an on/off control through a GPIO. Support for such subdevices need to be handled by a separate driver, so we need a way to load it at runtime. I'm not sure on what bus that driver should sit. I don't think the second option is possible, I2C and SPI subdevs need to sit on an I2C or SPI bus (I could be mistaken though, there's at least one example of a logical bus type in the kernel with the HID bus). Let's also not forget about sub-sub-devices. We need to handle them at some point as well. Sub-sub-devices are not a problem by themselves. They are only a problem if they on the same bus. This being said, I think that the use of platform devices to solve the initial problem can also be considered a hack as well. What we really need is a way to handle subdevs that can't be controlled at all (a video source that continuously delivers data for instance), or that can be controlled through GPIO. What bus should we use for a bus-less subdev ? And for GPIO-based subdevs, should we create a GPIO bus ? It is perfectly possible to have bus-less subdevs. See ivtv (I think there are one or two other examples as well). But how can we handle bus-less subdevs for embedded devices, where the host (e.g. OMAP3 ISP) doesn't know about the external subdevs (e.g. FPGA controlled by a couple of GPIOs) ? -- Regards, Laurent Pinchart I remembered that we had to do something similar and I found the patch below. This was the result of some private discussions with Vaibhav Hiremath from TI. It almost certainly doesn't apply to the current kernel, but it is clear what happens. We are actually using this with the dm6467 capture driver. Hope this might at least give some ideas. Regards, Hans From: Mats Randgaard mats.randga...@cisco.com Subject: [PATCH 6/6] FPGA subdevice driver Date: Thu, 2 Dec 2010 08:40:10 +0100 This subdevice driver can be used with custom made subdevices (e.g. FPGA's) that need some or no configuration. The driver calls functions specified in the board definition file. Signed-off-by: Mats Randgaard mats.randga...@cisco.com --- arch/arm/mach-davinci/board-dm646x-evm.c | 38 +++ drivers/media/video/Kconfig|8 ++ drivers/media/video/Makefile |1 + drivers/media/video/davinci/vpif_capture.c | 21 -- drivers/media/video/fpga_subdev.c | 97 include/media/fpga_subdev.h| 44 + 6 files changed, 203 insertions(+), 6 deletions(-) create mode 100644 drivers/media/video/fpga_subdev.c create mode 100644 include/media/fpga_subdev.h diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index f6ac9ba..458f593 100644 ---
Re: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
On Fri, 20 May 2011, Laurent Pinchart wrote: Hi Sylwester, On Friday 20 May 2011 09:14:36 Sylwester Nawrocki wrote: [snip] I had an issue when tried to call request_module, to register subdev of platform device type, in probe() of other platform device. Driver's probe() for devices belonging same bus type cannot be nested as the bus lock is taken by the driver core before entering probe(), so this would lead to a deadlock. That exactly happens in __driver_attach(). For the same reason v4l2_new_subdev_board could not be called from probe() of devices belonging to I2C or SPI bus, as request_module is called inside of it. I'm not sure how to solve it, yet:) Ouch. I wasn't aware of that issue. Looks like it's indeed time to fix the subdev registration issue, including the module load race condition. Michael, you said you have a patch to add platform subdev support, how have you avoided the race condition ? I've been thinking for some time now about removing the module load code completely. I2C, SPI and platform subdevs would be registered either by board code (possibly through the device tree on platforms that suppport it) for embedded platforms, and by host drivers for pluggable hardware (PCI and USB). Module loading would be handled automatically by the kernel module auto loader, but asynchronously instead of synchronously. Bus notifiers would then be used by host drivers to wait for all subdevs to be registered. Sorry, I'm probably missing something. The reason for this module loading was, that you cannot probe i2c sensors before the host is initialised and has turned the master clock on. If you want to go back to the traditional platform-based I2C device registration, you'll have to wait in your sensor (subdev) probe function for host registration, which wouldn't be a good thing to do, IMHO. I'm not sure yet if this approach is viable. Hans, I think we've briefly discussed this (possible quite a long time ago), do you have any opinion ? Guennadi, based on your previous experience trying to use bus notifiers to solve the module load race, what do you think about the idea ? Others, please comment as well :-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: Remote control not working for Terratec Cinergy C (2.6.37 Mantis driver)
Hello Chris
This applies fine against 2.6.39 stable, but the Twinhan VP-1041 uses the
keymap of Twinhan DTV CAB CI, so it's not a perfect fit for the Terratec
Cinergy S2 HD keymap. I assume from earlier postings in vdr-portal [1] Cinergy
S2 HD and Skystar 2 HD do share the same keymappings.
Here's a paste of the VP-1041 keymap, as it used to work with s2-liplianin:
/* Twinhan VP-1041 */
static struct ir_scancode ir_codes_mantis_vp1041[] = {
{ 0x29, KEY_POWER},
{ 0x28, KEY_FAVORITES},
{ 0x30, KEY_TEXT},
{ 0x17, KEY_INFO}, /* Preview */
{ 0x23, KEY_EPG},
{ 0x3b, KEY_F22}, /* Record List */
{ 0x3c, KEY_1},
{ 0x3e, KEY_2},
{ 0x39, KEY_3},
{ 0x36, KEY_4},
{ 0x22, KEY_5},
{ 0x20, KEY_6},
{ 0x32, KEY_7},
{ 0x26, KEY_8},
{ 0x24, KEY_9},
{ 0x2a, KEY_0},
{ 0x33, KEY_CANCEL},
{ 0x2c, KEY_BACK},
{ 0x15, KEY_CLEAR},
{ 0x3f, KEY_TAB},
{ 0x10, KEY_ENTER},
{ 0x14, KEY_UP},
{ 0x0d, KEY_RIGHT},
{ 0x0e, KEY_DOWN},
{ 0x11, KEY_LEFT},
{ 0x21, KEY_VOLUMEUP},
{ 0x35, KEY_VOLUMEDOWN},
{ 0x3d, KEY_CHANNELDOWN},
{ 0x3a, KEY_CHANNELUP},
{ 0x2e, KEY_RECORD},
{ 0x2b, KEY_PLAY},
{ 0x13, KEY_PAUSE},
{ 0x25, KEY_STOP},
{ 0x1f, KEY_REWIND},
{ 0x2d, KEY_FASTFORWARD},
{ 0x1e, KEY_PREVIOUS}, /* Replay | */
{ 0x1d, KEY_NEXT}, /* Skip | */
{ 0x0b, KEY_CAMERA},/* Capture */
{ 0x0f, KEY_LANGUAGE}, /* SAP */
{ 0x18, KEY_MODE}, /* PIP */
{ 0x12, KEY_ZOOM}, /* Full screen */
{ 0x1c, KEY_SUBTITLE},
{ 0x2f, KEY_MUTE},
{ 0x16, KEY_F20}, /* L/R */
{ 0x38, KEY_F21}, /* Hibernate */
{ 0x37, KEY_SWITCHVIDEOMODE}, /* A/V */
{ 0x31, KEY_AGAIN}, /* Recall */
{ 0x1a, KEY_KPPLUS},/* Zoom+ */
{ 0x19, KEY_KPMINUS}, /* Zoom- */
{ 0x27, KEY_RED},
{ 0x0C, KEY_GREEN},
{ 0x01, KEY_YELLOW},
{ 0x00, KEY_BLUE},
};
struct ir_scancode_table ir_codes_mantis_vp1041_table = {
.scan = ir_codes_mantis_vp1041,
.size = ARRAY_SIZE(ir_codes_mantis_vp1041),
};
EXPORT_SYMBOL_GPL(ir_codes_mantis_vp1041_table);
Maybe someone else can confirm this?
Regards
Lou@vdr-portal
[1] http://www.vdr-portal.de/board18-vdr-hardware/board13-
fernbedienungen/95304-falsches-mapping-mit-fb-von-skystar-hd2-unter-linux/
Hello,
This patch is a rework of a old patch I've posted some time ago.
It adds support for Remote-Control in the mantis driver and implements the
new rc-API.
The patch enables rc for the cards
- vp1041
- vp2033
- vp2040
It's only tested with a Terratec Cinergy S2 HD.
Would be nice to get some Feedback.
Regards
Chris
--
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 v17 0/6] davinci vpbe: dm6446 v4l2 driver
version17 : Fixed Laurent Pinchart's comments for: 1.ISR reorganization 2.probe function cleanup 3.try_format cleanup 4.Minor fixes s Hadli (6): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: Build infrastructure for VPBE driver davinci vpbe: Readme text for Dm6446 vpbe Documentation/video4linux/README.davinci-vpbe | 93 ++ drivers/media/video/davinci/Kconfig | 22 + drivers/media/video/davinci/Makefile |2 + drivers/media/video/davinci/vpbe.c| 864 drivers/media/video/davinci/vpbe_display.c| 1861 + drivers/media/video/davinci/vpbe_osd.c| 1231 drivers/media/video/davinci/vpbe_osd_regs.h | 364 + drivers/media/video/davinci/vpbe_venc.c | 566 drivers/media/video/davinci/vpbe_venc_regs.h | 177 +++ include/media/davinci/vpbe.h | 184 +++ include/media/davinci/vpbe_display.h | 147 ++ include/media/davinci/vpbe_osd.h | 394 ++ include/media/davinci/vpbe_types.h| 91 ++ include/media/davinci/vpbe_venc.h | 45 + 14 files changed, 6041 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.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
[PATCH v17 2/6] davinci vpbe: VPBE display driver
This patch implements the core functionality of the display driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the main V4L2 driver. This implements
the core of each of the V4L2 IOCTLs.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/davinci/vpbe.c | 864
include/media/davinci/vpbe.h | 184
2 files changed, 1048 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe.c
create mode 100644 include/media/davinci/vpbe.h
diff --git a/drivers/media/video/davinci/vpbe.c
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..d773d30
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,864 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/wait.h
+#include linux/time.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/err.h
+
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe.h
+#include media/davinci/vpss.h
+#include media/davinci/vpbe_venc.h
+
+#define VPBE_DEFAULT_OUTPUTComposite
+#define VPBE_DEFAULT_MODE ntsc
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, vpbe output name (default:Composite));
+MODULE_PARM_DESC(def_mode, vpbe output mode name (default:ntsc);
+MODULE_PARM_DESC(debug, Debug level 0-1);
+
+MODULE_DESCRIPTION(TI DMXXX VPBE Display controller);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Texas Instruments);
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+ struct vpbe_config *cfg = vpbe_dev-cfg;
+ int index = vpbe_dev-current_sd_index;
+
+ return ((index == 0) ? cfg-venc :
+ cfg-ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_config *cfg,
+int index)
+{
+ char *encoder_name = cfg-outputs[index].subdev_name;
+ int i;
+
+ /* Venc is always first */
+ if (!strcmp(encoder_name, cfg-venc.module_name))
+ return 0;
+
+ for (i = 0; i cfg-num_ext_encoders; i++) {
+ if (!strcmp(encoder_name,
+cfg-ext_encoders[i].module_name))
+ return i+1;
+ }
+
+ return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+ struct v4l2_cropcap *cropcap)
+{
+ if (NULL == cropcap)
+ return -EINVAL;
+ cropcap-bounds.left = 0;
+ cropcap-bounds.top = 0;
+ cropcap-bounds.width = vpbe_dev-current_timings.xres;
+ cropcap-bounds.height = vpbe_dev-current_timings.yres;
+ cropcap-defrect = cropcap-bounds;
+
+ return 0;
+}
+
+/**
+ * vpbe_enum_outputs - enumerate outputs
+ * @vpbe_dev - vpbe device ptr
+ * @output - ptr to v4l2_output structure
+ *
+ * Enumerates the outputs available at the vpbe display
+ * returns the status, -EINVAL if end of output list
+ */
+static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev,
+struct v4l2_output *output)
+{
+ struct vpbe_config *cfg = vpbe_dev-cfg;
+ int temp_index = output-index;
+
+ if
[PATCH v2 1/2] MT9P031: Add support for Aptina mt9p031 sensor.
This driver adds basic support for Aptina mt9p031 sensor.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9p031.c | 751 +
include/media/mt9p031.h | 11 +
4 files changed, 771 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mt9p031.c
create mode 100644 include/media/mt9p031.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 00f51dd..5c96b89 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -329,6 +329,14 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_MT9P031
+ tristate Aptina MT9P031 support
+ depends on I2C VIDEO_V4L2
+ ---help---
+ This driver supports MT9P031 cameras from Micron
+ This is a Video4Linux2 sensor-level driver for the Micron
+ mt0p031 5 Mpixel camera.
+
config VIDEO_MT9V011
tristate Micron mt9v011 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..912b29b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
+obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
new file mode 100644
index 000..e406b64
--- /dev/null
+++ b/drivers/media/video/mt9p031.c
@@ -0,0 +1,751 @@
+/*
+ * Driver for MT9P031 CMOS Image Sensor from Aptina
+ *
+ * Copyright (C) 2011, Javier Martin javier.mar...@vista-silicon.com
+ *
+ * Copyright (C) 2011, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on the MT9V032 driver and Bastian Hecht's code.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include media/v4l2-subdev.h
+#include linux/videodev2.h
+
+#include media/mt9p031.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+#include media/v4l2-device.h
+
+/* mt9p031 selected register addresses */
+#define MT9P031_CHIP_VERSION 0x00
+#defineMT9P031_CHIP_VERSION_VALUE 0x1801
+#define MT9P031_ROW_START 0x01
+#defineMT9P031_ROW_START_SKIP 54
+#define MT9P031_COLUMN_START 0x02
+#defineMT9P031_COLUMN_START_SKIP 16
+#define MT9P031_WINDOW_HEIGHT 0x03
+#define MT9P031_WINDOW_WIDTH 0x04
+#define MT9P031_H_BLANKING 0x05
+#defineMT9P031_H_BLANKING_VALUE0
+#define MT9P031_V_BLANKING 0x06
+#defineMT9P031_V_BLANKING_VALUE25
+#define MT9P031_OUTPUT_CONTROL 0x07
+#defineMT9P031_OUTPUT_CONTROL_CEN 2
+#defineMT9P031_OUTPUT_CONTROL_SYN 1
+#define MT9P031_SHUTTER_WIDTH_UPPER0x08
+#define MT9P031_SHUTTER_WIDTH 0x09
+#define MT9P031_PIXEL_CLOCK_CONTROL0x0a
+#define MT9P031_FRAME_RESTART 0x0b
+#define MT9P031_SHUTTER_DELAY 0x0c
+#define MT9P031_RST0x0d
+#defineMT9P031_RST_ENABLE 1
+#defineMT9P031_RST_DISABLE 0
+#define MT9P031_READ_MODE_10x1e
+#define MT9P031_READ_MODE_20x20
+#defineMT9P031_READ_MODE_2_ROW_MIR 0x8000
+#defineMT9P031_READ_MODE_2_COL_MIR 0x4000
+#define MT9P031_ROW_ADDRESS_MODE 0x22
+#define MT9P031_COLUMN_ADDRESS_MODE0x23
+#define MT9P031_GLOBAL_GAIN0x35
+
+#define MT9P031_MAX_HEIGHT 1944
+#define MT9P031_MAX_WIDTH 2592
+#define MT9P031_MIN_HEIGHT 2
+#define MT9P031_MIN_WIDTH 18
+
+struct mt9p031 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_rect rect; /* Sensor window */
+ struct v4l2_mbus_framefmt format;
+ struct mt9p031_platform_data *pdata;
+ struct mutex power_lock;
+ int power_count;
+ u16 xskip;
+ u16 yskip;
+ u16 output_control;
+
[PATCH v2 2/2] OMAP3BEAGLE: Add support for mt9p031 sensor driver.
isp.h file has to be included as a temporal measure
since clocks of the isp are not exposed yet.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 127 ++-
1 files changed, 123 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..f52e6ae 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,15 +24,20 @@
#include linux/input.h
#include linux/gpio_keys.h
#include linux/opp.h
+#include linux/i2c.h
+#include linux/mm.h
+#include linux/videodev2.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/mmc/host.h
-
+#include linux/gpio.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
+#include media/mt9p031.h
+
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -47,12 +52,17 @@
#include plat/nand.h
#include plat/usb.h
#include plat/omap_device.h
+#include plat/i2c.h
#include mux.h
#include hsmmc.h
#include timer-gp.h
#include pm.h
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+#define MT9P031_RESET_GPIO 98
+#define MT9P031_XCLK ISP_XCLK_A
#define NAND_BLOCK_SIZESZ_128K
/*
@@ -273,6 +283,44 @@ static struct regulator_consumer_supply beagle_vsim_supply
= {
static struct gpio_led gpio_leds[];
+static struct regulator_consumer_supply beagle_vaux3_supply = {
+ .supply = cam_1v8,
+};
+
+static struct regulator_consumer_supply beagle_vaux4_supply = {
+ .supply = cam_2v8,
+};
+
+/* VAUX3 for CAM_1V8 */
+static struct regulator_init_data beagle_vaux3 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux3_supply,
+};
+
+/* VAUX4 for CAM_2V8 */
+static struct regulator_init_data beagle_vaux4 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vaux4_supply,
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -309,6 +357,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ /*
+* Power on camera interface - only on pre-production, not
+* needed on production boards
+*/
+ gpio_request(gpio + 2, CAM_EN);
+ gpio_direction_output(gpio + 2, 1);
+ }
+
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
@@ -451,6 +508,8 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = beagle_vsim,
.vdac = beagle_vdac,
.vpll2 = beagle_vpll2,
+ .vaux3 = beagle_vaux3,
+ .vaux4 = beagle_vaux4,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
@@ -463,15 +522,16 @@ static struct i2c_board_info __initdata
beagle_i2c_boardinfo[] = {
};
static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
- {
- I2C_BOARD_INFO(eeprom, 0x50),
- },
+ {
+ I2C_BOARD_INFO(eeprom, 0x50),
+ },
};
static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
+ omap_register_i2c_bus(2, 100, NULL, 0); /* Enable I2C2 for camera */
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
ARRAY_SIZE(beagle_i2c_eeprom));
@@ -654,6 +714,60 @@ static void __init beagle_opp_init(void)
return;
}
+static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+{
+ struct isp_device *isp =
[PATCH v17 3/6] davinci vpbe: OSD(On Screen Display) block
This patch implements the functionality of the OSD block
of the VPBE. The OSD in total supports 4 planes or Video
sources - 2 mainly RGB and 2 Video. The patch implements general
handling of all the planes, with specific emphasis on the Video
plane capabilities as the Video planes are supported through the
V4L2 driver.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/davinci/vpbe_osd.c | 1231 +++
drivers/media/video/davinci/vpbe_osd_regs.h | 364
include/media/davinci/vpbe_osd.h| 394 +
3 files changed, 1989 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_osd.c
create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
create mode 100644 include/media/davinci/vpbe_osd.h
diff --git a/drivers/media/video/davinci/vpbe_osd.c
b/drivers/media/video/davinci/vpbe_osd.c
new file mode 100644
index 000..5352884
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_osd.c
@@ -0,0 +1,1231 @@
+/*
+ * Copyright (C) 2007-2010 Texas Instruments Inc
+ * Copyright (C) 2007 MontaVista Software, Inc.
+ *
+ * Andy Lowe (al...@mvista.com), MontaVista Software
+ * - Initial version
+ * Murali Karicheri (mkarich...@gmail.com), Texas Instruments Ltd.
+ * - ported to sub device interface
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/slab.h
+
+#include mach/io.h
+#include mach/cputype.h
+#include mach/hardware.h
+
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_osd.h
+
+#include linux/io.h
+#include vpbe_osd_regs.h
+
+#define MODULE_NAMEVPBE_OSD_SUBDEV_NAME
+
+/* register access routines */
+static inline u32 osd_read(struct osd_state *sd, u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ return readl(osd-osd_base + offset);
+}
+
+static inline u32 osd_write(struct osd_state *sd, u32 val, u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ writel(val, osd-osd_base + offset);
+
+ return val;
+}
+
+static inline u32 osd_set(struct osd_state *sd, u32 mask, u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ u32 addr = osd-osd_base + offset;
+ u32 val = readl(addr) | mask;
+
+ writel(val, addr);
+
+ return val;
+}
+
+static inline u32 osd_clear(struct osd_state *sd, u32 mask, u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ u32 addr = osd-osd_base + offset;
+ u32 val = readl(addr) ~mask;
+
+ writel(val, addr);
+
+ return val;
+}
+
+static inline u32 osd_modify(struct osd_state *sd, u32 mask, u32 val,
+u32 offset)
+{
+ struct osd_state *osd = sd;
+
+ u32 addr = osd-osd_base + offset;
+ u32 new_val = (readl(addr) ~mask) | (val mask);
+
+ writel(new_val, addr);
+
+ return new_val;
+}
+
+/* define some macros for layer and pixfmt classification */
+#define is_osd_win(layer) (((layer) == WIN_OSD0) || ((layer) == WIN_OSD1))
+#define is_vid_win(layer) (((layer) == WIN_VID0) || ((layer) == WIN_VID1))
+#define is_rgb_pixfmt(pixfmt) \
+ (((pixfmt) == PIXFMT_RGB565) || ((pixfmt) == PIXFMT_RGB888))
+#define is_yc_pixfmt(pixfmt) \
+ (((pixfmt) == PIXFMT_YCbCrI) || ((pixfmt) == PIXFMT_YCrCbI) || \
+ ((pixfmt) == PIXFMT_NV12))
+#define MAX_WIN_SIZE OSD_VIDWIN0XP_V0X
+#define MAX_LINE_LENGTH (OSD_VIDWIN0OFST_V0LO 5)
+
+/**
+ * _osd_dm6446_vid0_pingpong() - field inversion fix for DM6446
+ * @sd - ptr to struct osd_state
+ * @field_inversion - inversion flag
+ * @fb_base_phys - frame buffer address
+ * @lconfig - ptr to layer config
+ *
+ * This routine implements a workaround for the field signal inversion silicon
+ * erratum described in Advisory 1.3.8 for the DM6446. The fb_base_phys and
+ * lconfig parameters apply to the vid0 window. This routine should be called
+ * whenever the vid0 layer configuration or start address is modified, or when
+ * the OSD field inversion setting is modified.
+ * Returns: 1 if the ping-pong buffers need to be toggled in the vsync isr, or
+ * 0 otherwise
+ */
+static int
[PATCH v17 4/6] davinci vpbe: VENC( Video Encoder) implementation
This patch adds the VENC or the Video encoder, which is responsible
for the blending of all source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the analog DACs. The venc block is implemented
as a subdevice, allowing for additional external and internal encoders
of other kind to plug-in.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/davinci/vpbe_venc.c | 566 ++
drivers/media/video/davinci/vpbe_venc_regs.h | 177
include/media/davinci/vpbe_venc.h| 45 ++
3 files changed, 788 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_venc.c
create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
create mode 100644 include/media/davinci/vpbe_venc.h
diff --git a/drivers/media/video/davinci/vpbe_venc.c
b/drivers/media/video/davinci/vpbe_venc.c
new file mode 100644
index 000..03a3e5c
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -0,0 +1,566 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/ctype.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include linux/slab.h
+
+#include mach/hardware.h
+#include mach/mux.h
+#include mach/io.h
+#include mach/i2c.h
+
+#include linux/io.h
+
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_venc.h
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+
+#include vpbe_venc_regs.h
+
+#define MODULE_NAMEVPBE_VENC_SUBDEV_NAME
+
+static int debug = 2;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, Debug level 0-2);
+
+struct venc_state {
+ struct v4l2_subdev sd;
+ struct venc_callback *callback;
+ struct venc_platform_data *pdata;
+ struct device *pdev;
+ u32 output;
+ v4l2_std_id std;
+ spinlock_t lock;
+ void __iomem *venc_base;
+ void __iomem *vdaccfg_reg;
+};
+
+static inline struct venc_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct venc_state, sd);
+}
+
+static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset)
+{
+ struct venc_state *venc = to_state(sd);
+
+ return readl(venc-venc_base + offset);
+}
+
+static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+
+ writel(val, (venc-venc_base + offset));
+
+ return val;
+}
+
+static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset,
+u32 val, u32 mask)
+{
+ u32 new_val = (venc_read(sd, offset) ~mask) | (val mask);
+
+ venc_write(sd, offset, new_val);
+
+ return new_val;
+}
+
+static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+
+ writel(val, venc-vdaccfg_reg);
+
+ val = readl(venc-vdaccfg_reg);
+
+ return val;
+}
+
+/* This function sets the dac of the VPBE for various outputs
+ */
+static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
+{
+ switch (out_index) {
+ case 0:
+ v4l2_dbg(debug, 1, sd, Setting output to Composite\n);
+ venc_write(sd, VENC_DACSEL, 0);
+ break;
+ case 1:
+ v4l2_dbg(debug, 1, sd, Setting output to S-Video\n);
+ venc_write(sd, VENC_DACSEL, 0x210);
+ break;
+ case 2:
+ venc_write(sd, VENC_DACSEL, 0x543);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
+{
+ v4l2_dbg(debug, 2, sd, venc_enabledigitaloutput\n);
+
+ if (benable) {
+ venc_write(sd, VENC_VMOD, 0);
+ venc_write(sd, VENC_CVBS, 0);
+ venc_write(sd, VENC_LCDOUT, 0);
+ venc_write(sd, VENC_HSPLS, 0);
+ venc_write(sd,
[PATCH v17 5/6] davinci vpbe: Build infrastructure for VPBE driver
This patch adds the build infra-structure for Davinci VPBE dislay driver. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl --- drivers/media/video/davinci/Kconfig | 22 ++ drivers/media/video/davinci/Makefile |2 ++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..a7f11e7 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -91,3 +91,25 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. + +config VIDEO_DM644X_VPBE + tristate DM644X VPBE HW module + select VIDEO_VPSS_SYSTEM + select VIDEOBUF_DMA_CONTIG + help + Enables VPBE modules used for display on a DM644x + SoC. + + To compile this driver as a module, choose M here: the + module will be called vpbe. + + +config VIDEO_VPBE_DISPLAY + tristate VPBE V4L2 Display driver + select VIDEO_DM644X_VPBE + default y + help + Enables VPBE V4L2 Display driver on a DMXXX device + + To compile this driver as a module, choose M here: the + module will be called vpbe_display. diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index a379557..ae7dafb 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -16,3 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o obj-$(CONFIG_VIDEO_ISIF) += isif.o +obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o +obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v17 6/6] davinci vpbe: Readme text for Dm6446 vpbe
Please refer to this file for detailed documentation of davinci vpbe v4l2 driver. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl --- Documentation/video4linux/README.davinci-vpbe | 93 + 1 files changed, 93 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe diff --git a/Documentation/video4linux/README.davinci-vpbe b/Documentation/video4linux/README.davinci-vpbe new file mode 100644 index 000..7a460b0 --- /dev/null +++ b/Documentation/video4linux/README.davinci-vpbe @@ -0,0 +1,93 @@ + +VPBE V4L2 driver design + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of the following (in the same order as the list under file + partitioning):- + + 1. V4L2 display driver +Implements creation of video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up VENC, OSD and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the VENC or external sub devices. It also provides +a device object to access the services from OSD subdevice +using sub device ops. The connection of external encoders to VENC LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connected to an external encoder, vpbe controller is also responsible +for setting up the interface between VENC and external encoders based on +board specific settings (specified in board-xxx-evm.c). This allows +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in VENC for a specific display resolution. As of this +patch series, the interconnection and enabling and setting of the external +encoders is not present, and would be a part of the next patch series. + + 3. VENC subdevice module +Responsible for setting outputs provided through internal DACs and also +setting timings at LCD controller port when external encoders are connected +at the port or LCD panel timings required. When external encoder/LCD panel +is connected, the timings for a specific standard/preset is retrieved from +the board specific table and the values are used to set the timings in +venc using non-standard timing mode. + +Support LCD Panel displays using the VENC. For example to support a Logic +PD display, it requires setting up the LCD controller port with a set of +timings for the resolution supported and setting the dot clock. So we could +add the available outputs as a board specific entry (i.e add the LogicPD +output name to board-xxx-evm.c). A table of timings for various LCDs +supported can be maintained in the board specific setup file to support +various LCD displays.As of this patch a basic driver is present, and this +support for external encoders and displays forms a part of the next +patch series. + + 4. OSD module +OSD module implements all OSD layer management and hardware specific +features. The VPBE module interacts with the OSD for enabling and +disabling appropriate features of the OSD. + + Current status:- + + A fully functional working version of the V4L2 driver is available. This + driver has been tested with NTSC and PAL standards and buffer streaming. + + Following are TBDs. + + vpbe display controller +- Add support for external encoders. +- add support for selecting external encoder as default at probe time. + + vpbe venc sub device +- add timings for supporting ths8200 +- add support for LogicPD LCD. + + FB drivers +- Add support for fbdev drivers.- Ready and part of subsequent patches. -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] davinci: dm646x: move vpif related code to driver core header from platform
move vpif related code for capture and display drivers
from dm646x platform header file to vpif.h as these definitions
are related to driver code more than the platform or board.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
---
arch/arm/mach-davinci/include/mach/dm646x.h | 53 +---
drivers/media/video/davinci/vpif.h |1 +
drivers/media/video/davinci/vpif_capture.h |2 +-
drivers/media/video/davinci/vpif_display.h |1 +
include/media/davinci/vpif.h| 73 +++
5 files changed, 77 insertions(+), 53 deletions(-)
create mode 100644 include/media/davinci/vpif.h
diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h
b/arch/arm/mach-davinci/include/mach/dm646x.h
index 7a27f3f..245a1c0 100644
--- a/arch/arm/mach-davinci/include/mach/dm646x.h
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -17,6 +17,7 @@
#include linux/videodev2.h
#include linux/clk.h
#include linux/davinci_emac.h
+#include media/davinci/vpif.h
#define DM646X_EMAC_BASE (0x01C8)
#define DM646X_EMAC_MDIO_BASE (DM646X_EMAC_BASE + 0x4000)
@@ -36,58 +37,6 @@ int __init dm646x_init_edma(struct edma_rsv_info *rsv);
void dm646x_video_init(void);
-enum vpif_if_type {
- VPIF_IF_BT656,
- VPIF_IF_BT1120,
- VPIF_IF_RAW_BAYER
-};
-
-struct vpif_interface {
- enum vpif_if_type if_type;
- unsigned hd_pol:1;
- unsigned vd_pol:1;
- unsigned fid_pol:1;
-};
-
-struct vpif_subdev_info {
- const char *name;
- struct i2c_board_info board_info;
- u32 input;
- u32 output;
- unsigned can_route:1;
- struct vpif_interface vpif_if;
-};
-
-struct vpif_display_config {
- int (*set_clock)(int, int);
- struct vpif_subdev_info *subdevinfo;
- int subdev_count;
- const char **output;
- int output_count;
- const char *card_name;
-};
-
-struct vpif_input {
- struct v4l2_input input;
- const char *subdev_name;
-};
-
-#define VPIF_CAPTURE_MAX_CHANNELS 2
-
-struct vpif_capture_chan_config {
- const struct vpif_input *inputs;
- int input_count;
-};
-
-struct vpif_capture_config {
- int (*setup_input_channel_mode)(int);
- int (*setup_input_path)(int, const char *);
- struct vpif_capture_chan_config chan_config[VPIF_CAPTURE_MAX_CHANNELS];
- struct vpif_subdev_info *subdev_info;
- int subdev_count;
- const char *card_name;
-};
-
void dm646x_setup_vpif(struct vpif_display_config *,
struct vpif_capture_config *);
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index 10550bd..e76dded 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -20,6 +20,7 @@
#include linux/videodev2.h
#include mach/hardware.h
#include mach/dm646x.h
+#include media/davinci/vpif.h
/* Maximum channel allowed */
#define VPIF_NUM_CHANNELS (4)
diff --git a/drivers/media/video/davinci/vpif_capture.h
b/drivers/media/video/davinci/vpif_capture.h
index 7a4196d..fa50b6b 100644
--- a/drivers/media/video/davinci/vpif_capture.h
+++ b/drivers/media/video/davinci/vpif_capture.h
@@ -28,7 +28,7 @@
#include media/v4l2-device.h
#include media/videobuf-core.h
#include media/videobuf-dma-contig.h
-#include mach/dm646x.h
+#include media/davinci/vpif.h
#include vpif.h
diff --git a/drivers/media/video/davinci/vpif_display.h
b/drivers/media/video/davinci/vpif_display.h
index b53aaa8..b531a01 100644
--- a/drivers/media/video/davinci/vpif_display.h
+++ b/drivers/media/video/davinci/vpif_display.h
@@ -23,6 +23,7 @@
#include media/v4l2-device.h
#include media/videobuf-core.h
#include media/videobuf-dma-contig.h
+#include media/davinci/vpif.h
#include vpif.h
diff --git a/include/media/davinci/vpif.h b/include/media/davinci/vpif.h
new file mode 100644
index 000..e4a4dc1
--- /dev/null
+++ b/include/media/davinci/vpif.h
@@ -0,0 +1,73 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef _VPIF_INC_H
+#define _VPIF_INC_H
+
+#include linux/i2c.h
+
+#define VPIF_CAPTURE_MAX_CHANNELS 2
+
+enum vpif_if_type {
+ VPIF_IF_BT656,
+ VPIF_IF_BT1120,
+ VPIF_IF_RAW_BAYER
+};
+
+struct vpif_interface {
+ enum vpif_if_type
Re: [PATCH v17 5/6] davinci vpbe: Build infrastructure for VPBE driver
Hello. Manjunath Hadli wrote: This patch adds the build infra-structure for Davinci VPBE dislay driver. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl [...] diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..a7f11e7 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -91,3 +91,25 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. + +config VIDEO_DM644X_VPBE + tristate DM644X VPBE HW module BTW, as this seems DM644x specific, shouldn't this depend on CONFIG_ARCH_DAVINCI_DM644x? + select VIDEO_VPSS_SYSTEM + select VIDEOBUF_DMA_CONTIG + help + Enables VPBE modules used for display on a DM644x + SoC. + + To compile this driver as a module, choose M here: the + module will be called vpbe. + + +config VIDEO_VPBE_DISPLAY + tristate VPBE V4L2 Display driver + select VIDEO_DM644X_VPBE Or this one, if it selects VIDEO_DM644X_VPBE? + default y Hm, y shouldn't be the default. WBR, Sergei -- 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: [GIT PATCHES FOR 2.6.40] gspca for_v2.6.40
Em 17-05-2011 06:36, Antonio Ospite escreveu: On Tue, 17 May 2011 10:54:17 +0200 Jean-Francois Moine moin...@free.fr wrote: The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v2.6.40 [...] Hi Jean-Francois, sometimes it is useful to add also a why section to commit messages so others can follow your thoughts, and even learn from them. I have this very simple scheme: a summary of the what goes into the short commit message and the why and how go into the long commit message when they are not immediately trivial from the code; for instance the why of the USB trace changes in this series wasn't trivial to me. Yeah, providing a good documentation is important to allow the others to know what's happening at the driver. Jean-Francois, Could you please add more comments to your patch series? I'll discard this pull request from my queue. So, feel free to re-base your tree if you need. Thanks, 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: [PULL] soc-camera for 2.6.40
Em 20-05-2011 05:34, Guennadi Liakhovetski escreveu: Hi Mauro, Sorry, a bit late again... Here go patches for 2.6.40: The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-2.6.40 ... Sergio Aguirre (1): V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c This patch didn't apply. Weren't it already applied at 2.6.39? Sylwester Nawrocki (1): V4L: Add V4L2_MBUS_FMT_JPEG_1X8 media bus format Already applied via snawrocki's tree. Thanks, 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: [GIT PATCH FOR 2.6.40] uvcvideo patches
Em 15-05-2011 04:48, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next They replace the git pull request I've sent on Thursday with the same subject. Bob Liu (2): Revert V4L/DVB: v4l2-dev: remove get_unmapped_area uvcvideo: Add support for NOMMU arch IMO, such fixes should happen inside the arch bits, and not on each driver. If this fix is needed for uvc video, the same fix should probably needed to all other USB drivers, in order to work on NOMMU arch. For now, I'm accepting this as a workaround, but please work on a generic solution for it. Hans de Goede (2): v4l: Add M420 format definition uvcvideo: Add M420 format support OK. Laurent Pinchart (4): v4l: Release module if subdev registration fails uvcvideo: Register a v4l2_device uvcvideo: Register subdevices for each entity uvcvideo: Connect video devices to media entities We've discussed already about using the media controller for uvcvideo, but I can't remember anymore what where your aguments in favor of merging it (and, even if I've remembered it right now, the #irc channel log is not the proper way to document the rationale to apply a patch). The thing is: it is clear that SoC embedded devices need the media controller, as they have IP blocks that do weird things, and userspace may need to access those, as it is not possible to control such IP blocks using the V4L2 API. However, I have serious concerns about media_controller API usage on generic drivers, as it is required that all drivers should be fully configurable via V4L2 API alone, otherwise we'll have regressions, as no generic applications use the media_controller. In other words, if you have enough arguments about why we should add media_controller support at the uvcvideo, please clearly provide them at the patch descriptions, as this is not obvious. It would equally important do document, at the uvcvideo doc, what kind of information is provided via the media_controller and why an userspace application should care to use it. Thanks, 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: [GIT PATCH FOR 2.6.40] uvcvideo patches
Hi Mauro, Thanks for handling the pull request. On Friday 20 May 2011 17:32:45 Mauro Carvalho Chehab wrote: Em 15-05-2011 04:48, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next They replace the git pull request I've sent on Thursday with the same subject. Bob Liu (2): Revert V4L/DVB: v4l2-dev: remove get_unmapped_area uvcvideo: Add support for NOMMU arch IMO, such fixes should happen inside the arch bits, and not on each driver. If this fix is needed for uvc video, the same fix should probably needed to all other USB drivers, in order to work on NOMMU arch. For now, I'm accepting this as a workaround, but please work on a generic solution for it. A fix at the arch/ level isn't possible, as drivers need to implement the get_unmapped_area file operation in order to support NOMMU architectures. The proper fix is of course to port uvcvideo to videobuf2, and implement support for NOMMU in videobuf2. Modifications to individual drivers will still be needed to fill the get_unmapped_area operation pointer with a videobuf2 handler though. Hans de Goede (2): v4l: Add M420 format definition uvcvideo: Add M420 format support OK. Laurent Pinchart (4): v4l: Release module if subdev registration fails uvcvideo: Register a v4l2_device uvcvideo: Register subdevices for each entity uvcvideo: Connect video devices to media entities We've discussed already about using the media controller for uvcvideo, but I can't remember anymore what where your aguments in favor of merging it (and, even if I've remembered it right now, the #irc channel log is not the proper way to document the rationale to apply a patch). The thing is: it is clear that SoC embedded devices need the media controller, as they have IP blocks that do weird things, and userspace may need to access those, as it is not possible to control such IP blocks using the V4L2 API. However, I have serious concerns about media_controller API usage on generic drivers, as it is required that all drivers should be fully configurable via V4L2 API alone, otherwise we'll have regressions, as no generic applications use the media_controller. In other words, if you have enough arguments about why we should add media_controller support at the uvcvideo, please clearly provide them at the patch descriptions, as this is not obvious. It would equally important do document, at the uvcvideo doc, what kind of information is provided via the media_controller and why an userspace application should care to use it. First of all, the uvcvideo driver doesn't require application to use the media controller API to operate. All configuration is handled through a V4L2 video device node, and these patches do not modify that. No change is required to applications to use the uvcvideo driver. There's however a reason why I want to add support for the media controller API to the uvcvideo driver (I wouldn't have submitted the patches otherwise :-)). UVC-compliant devices are modeled as a connected graph of entities (called terminals and units in the UVC world). The device topology can be arbitrarily complex (or simple, which is fortunately often the case) and is exported by the device to the host through USB descriptors. The uvcvideo driver parses the descriptor, creates an internal representation of the device internal topology, and maps V4L2 operations to the various entities that the device contains. The UVC specification standardizes a couple of entities (camera terminal, processing unit, ...) and allows device vendors to create vendor-specific entities called extension units (XUs in short). Those XUs are usually used to expose controls that are not standardized by UVC to the host. These controls can be anything from an activity LED to a firmware update system. The uvcvideo tries to map those XU controls to V4L2 controls when it makes sense (and when the controls are documented by the device manufacturer, which is unfortunately often not the case). If an XU control can't be mapped to a V4L2 control, it can be accessed through uvcvideo-specific (documented) ioctls. In order to access those XU controls, device-specific applications (such as a firmware update application for instance) need to know what XUs are present in the device and possibly how they are connected. That information can't be exported through V4L2. That's why I'm adding media controller support to the uvcvideo driver. The media controller has been designed to export the device internal topology to userspace and to make it configurable. That makes it an ideal candidate for the task at hand, which is exporting
Re: [PULL] soc-camera for 2.6.40
Hi Mauro Thanks for an express pull!:-) On Fri, 20 May 2011, Mauro Carvalho Chehab wrote: Em 20-05-2011 05:34, Guennadi Liakhovetski escreveu: Hi Mauro, Sorry, a bit late again... Here go patches for 2.6.40: The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-2.6.40 ... Sergio Aguirre (1): V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c This patch didn't apply. Weren't it already applied at 2.6.39? Sylwester Nawrocki (1): V4L: Add V4L2_MBUS_FMT_JPEG_1X8 media bus format Already applied via snawrocki's tree. Right, must have overlooked both, sorry. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH FOR 2.6.40] uvcvideo patches
Le vendredi 20 mai 2011 18:32:45 Mauro Carvalho Chehab, vous avez écrit : However, I have serious concerns about media_controller API usage on generic drivers, as it is required that all drivers should be fully configurable via V4L2 API alone, otherwise we'll have regressions, as no generic applications use the media_controller. If VLC counts as a generic application, I'd be more than API to use the media_controller (or whatever else) if only to find which ALSA (sub)device, if any, corresponds to the V4L2 node of a given USB webcam or such. I don't know any solution at the moment, and this is a major inconvenience on Linux desktop compared to DirectShow. -- Rémi Denis-Courmont http://www.remlab.info/ http://fi.linkedin.com/in/remidenis -- 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: [beagleboard] [PATCH v2 2/2] OMAP3BEAGLE: Add support for mt9p031 sensor driver.
Op 20 mei 2011, om 15:47 heeft Javier Martin het volgende geschreven: isp.h file has to be included as a temporal measure since clocks of the isp are not exposed yet. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- arch/arm/mach-omap2/board-omap3beagle.c | 127 ++- Javier, In previous patch sets we put that in a seperate file (omap3beagle-camera.c) so we don't clutter up the board file with all the different sensor drivers. Would it make sense to do the same with the current patches? It looks like MCF cuts down a lot on the boilerplace needed already. regards, Koen-- 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
[DVB] In research of chip's datasheets
Dear all, I'm in research of datasheets of the following chips: - tuner STV6110A from ST - dual demodulator STV0900B from ST - CI interface CXD2099AR from SONY The main goal is first to understand how all these parts are working and then to provide (if possible) some improvements. The source code associated with these drivers is released under GPL terms, but without any comments or descriptions in the code, so it's nearly useless for people other than the original developers to understand and contribute (that is basically the goal of the GPL spirit). What is our advice regarding the procedure to have access to these documents? Best regards, Sebastien. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/2] v4l: Add generic board subdev registration function
Hi Guennadi, On Friday 20 May 2011 15:08:00 Guennadi Liakhovetski wrote: On Fri, 20 May 2011, Laurent Pinchart wrote: On Friday 20 May 2011 09:14:36 Sylwester Nawrocki wrote: [snip] I had an issue when tried to call request_module, to register subdev of platform device type, in probe() of other platform device. Driver's probe() for devices belonging same bus type cannot be nested as the bus lock is taken by the driver core before entering probe(), so this would lead to a deadlock. That exactly happens in __driver_attach(). For the same reason v4l2_new_subdev_board could not be called from probe() of devices belonging to I2C or SPI bus, as request_module is called inside of it. I'm not sure how to solve it, yet:) Ouch. I wasn't aware of that issue. Looks like it's indeed time to fix the subdev registration issue, including the module load race condition. Michael, you said you have a patch to add platform subdev support, how have you avoided the race condition ? I've been thinking for some time now about removing the module load code completely. I2C, SPI and platform subdevs would be registered either by board code (possibly through the device tree on platforms that suppport it) for embedded platforms, and by host drivers for pluggable hardware (PCI and USB). Module loading would be handled automatically by the kernel module auto loader, but asynchronously instead of synchronously. Bus notifiers would then be used by host drivers to wait for all subdevs to be registered. Sorry, I'm probably missing something. The reason for this module loading was, that you cannot probe i2c sensors before the host is initialised and has turned the master clock on. Only when the subdev clock is provided by the host. And worse than that, when clock configuration needs to go through board code, you often need to wait until the host has registered the subdev before the board code can be executed. That's why many subdev drivers only initialize a couple of structures in their probe() function, and don't access the hardware until the registered() callback is called. If you want to go back to the traditional platform-based I2C device registration, you'll have to wait in your sensor (subdev) probe function for host registration, which wouldn't be a good thing to do, IMHO. Waiting for host initialization in the subdev probe function is definitely not a good option. There are various dependencies between the host and the subdevs. The host can't obviously proceed before all subdevs are ready, and subdevs often depend on the host to provide clocks and power. Initializing the host first, making the host register the subdev devices and waiting synchronously for them to be initialized is the option we went for. Unfortunately this brings several issues, such as deadlocks when the host and the subdevs sit on the same bus. Another option I'm proposing is to let Linux load modules and initialize devices without interfering with that. Host drivers would be notified that all subdevs are ready through bus notifiers, and subdev drivers would be notified that they can access host resources through the registered callback. This splits initialization in two parts. I'm of course open to other options. I'm not sure yet if this approach is viable. Hans, I think we've briefly discussed this (possible quite a long time ago), do you have any opinion ? Guennadi, based on your previous experience trying to use bus notifiers to solve the module load race, what do you think about the idea ? Others, please comment as well :-) -- 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.40] v4l subdev driver for M-5MOLS camera
Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung m5mols HeungJun, Kim (1): Add support for M-5MOLS 8 Mega Pixel camera ISP drivers/media/video/Kconfig |2 + drivers/media/video/Makefile |1 + drivers/media/video/m5mols/Kconfig |5 + drivers/media/video/m5mols/Makefile |3 + drivers/media/video/m5mols/m5mols.h | 296 drivers/media/video/m5mols/m5mols_capture.c | 191 + drivers/media/video/m5mols/m5mols_controls.c | 299 drivers/media/video/m5mols/m5mols_core.c | 1004 ++ drivers/media/video/m5mols/m5mols_reg.h | 399 ++ include/media/m5mols.h | 35 + 10 files changed, 2235 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/m5mols/Kconfig create mode 100644 drivers/media/video/m5mols/Makefile create mode 100644 drivers/media/video/m5mols/m5mols.h create mode 100644 drivers/media/video/m5mols/m5mols_capture.c create mode 100644 drivers/media/video/m5mols/m5mols_controls.c create mode 100644 drivers/media/video/m5mols/m5mols_core.c create mode 100644 drivers/media/video/m5mols/m5mols_reg.h create mode 100644 include/media/m5mols.h Regards, -- Sylwester Nawrocki Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DVB] In research of chip's datasheets
On 20/05/2011 18:01, Sébastien RAILLARD (COEXSI) wrote: I'm in research of datasheets of the following chips: - tuner STV6110A from ST - dual demodulator STV0900B from ST - CI interface CXD2099AR from SONY Hi Sebastien, If you're targeting the ngene based cards, I think you will also need the spec for the ngene chip and my guess is that it has been programmed (not generic like the 3 other chips). So as Ralph is already in contact with digital devices, I wonder if you will get this information. For the cxd2099ar, talk to sony europe CXD2099_supporteu./sony/.com -- Issa -- 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 PULL REQ] Initial IR updates for 2.6.40
Here's what I've got that's been stewing in my IR tree for a bit. There's more I'm working on and/or planning to work on for 2.6.40, but these should be good to go right now. The new redrat3 driver still has some quirks, at least when used with lirc userspace decoding, but I'm working with the folks at RedRat to sort them out. The following changes since commit 7225a1dcc38f28fcc6178258b2072d12742f68d9: [media] uvcvideo: Add M420 format support (2011-05-20 12:18:24 -0300) are available in the git repository at: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jarod/linux-2.6-ir.git/ for-2.6.40 Devin Heitmueller (1): [media] saa7134: enable IR support for Hauppauge HVR-1150/1120 Jarod Wilson (9): [media] nuvoton-cir: minor tweaks to rc dev init [media] imon: clean up disconnect routine [media] ite-cir: make IR receive work after resume [media] ite-cir: clean up odd spacing in ite8709 bits [media] ite-cir: finish tx before suspending [media] rc-winfast: fix inverted left/right key mappings [media] mceusb: passing ep to request_packet is redundant [media] rc: add locking to fix register/show race [media] redrat3: new rc-core IR transceiver device driver Julia Lawall (1): [media] imon: Correct call to input_free_device drivers/media/rc/Kconfig| 11 + drivers/media/rc/Makefile |1 + drivers/media/rc/imon.c | 36 +- drivers/media/rc/ite-cir.c | 60 +- drivers/media/rc/keymaps/rc-winfast.c |4 +- drivers/media/rc/mceusb.c | 18 +- drivers/media/rc/nuvoton-cir.c | 13 +- drivers/media/rc/rc-main.c | 47 +- drivers/media/rc/redrat3.c | 1344 +++ drivers/media/video/saa7134/saa7134-cards.c |1 + drivers/media/video/saa7134/saa7134-input.c |8 + include/media/rc-core.h |7 +- 12 files changed, 1462 insertions(+), 88 deletions(-) create mode 100644 drivers/media/rc/redrat3.c -- 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
[cron job] v4l-dvb daily build: 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:Fri May 20 19:00:46 CEST 2011 git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS 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.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS 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 linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The 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: [GIT PATCH FOR 2.6.40] uvcvideo patches
Em 20-05-2011 12:55, Rémi Denis-Courmont escreveu: Le vendredi 20 mai 2011 18:32:45 Mauro Carvalho Chehab, vous avez écrit : However, I have serious concerns about media_controller API usage on generic drivers, as it is required that all drivers should be fully configurable via V4L2 API alone, otherwise we'll have regressions, as no generic applications use the media_controller. If VLC counts as a generic application, I'd be more than API to use the media_controller (or whatever else) if only to find which ALSA (sub)device, if any, corresponds to the V4L2 node of a given USB webcam or such. I don't know any solution at the moment, and this is a major inconvenience on Linux desktop compared to DirectShow. You don't need the media controller for it. The proper solution for it is to use the sysfs to identify the alsa sub-device. For example, I have this on one of my machines: $ lspci |grep Multimedia 1c:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 04) 37:09.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1) $ $ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 004: ID 0409:005a NEC Corp. HighSpeed Hub Bus 001 Device 005: ID 0ac8:3330 Z-Star Microelectronics Corp. Bus 008 Device 002: ID 2101:020f ActionStar Bus 001 Device 003: ID 2040:4200 Hauppauge Bus 001 Device 006: ID 0d8c:0126 C-Media Electronics, Inc. I wrote an utility in the past that dig into the sysfs stuff to identify it, but I'm not sure if it is still working fine, as some changes at sysfs might affect it, as I never intended to maintain such utility. I'll seek for some time to re-write it with another approach and add it as a library, inside v4l2-utils, eventually together with libv4l. Basically, all V4L devices are under video4linux class: $ tree /sys/class/video4linux/ /sys/class/video4linux/ ├── vbi0 - ../../devices/pci:00/:00:1e.0/:37:09.0/video4linux/vbi0 ├── video0 - ../../devices/pci:00/:00:1c.0/:1c:00.0/video4linux/video0 ├── video1 - ../../devices/pci:00/:00:1a.7/usb1/1-5/1-5:1.0/video4linux/video1 ├── video2 - ../../devices/pci:00/:00:1e.0/:37:09.0/video4linux/video2 └── video3 - ../../devices/pci:00/:00:1a.7/usb1/1-6/1-6.2/1-6.2:1.0/video4linux/video3 And all alsa devices are under sound class: $ tree /sys/class/sound/ /sys/class/sound/ ├── card0 - ../../devices/pci:00/:00:1b.0/sound/card0 ├── card1 - ../../devices/pci:00/:00:1a.7/usb1/1-5/1-5:1.1/sound/card1 ├── card2 - ../../devices/pci:00/:00:1e.0/:37:09.0/sound/card2 ├── card3 - ../../devices/pci:00/:00:1a.7/usb1/1-6/1-6.3/1-6.3:1.0/sound/card3 ├── controlC0 - ../../devices/pci:00/:00:1b.0/sound/card0/controlC0 ├── controlC1 - ../../devices/pci:00/:00:1a.7/usb1/1-5/1-5:1.1/sound/card1/controlC1 ├── controlC2 - ../../devices/pci:00/:00:1e.0/:37:09.0/sound/card2/controlC2 ├── controlC3 - ../../devices/pci:00/:00:1a.7/usb1/1-6/1-6.3/1-6.3:1.0/sound/card3/controlC3 ├── hwC0D0 - ../../devices/pci:00/:00:1b.0/sound/card0/hwC0D0 ├── pcmC0D0c - ../../devices/pci:00/:00:1b.0/sound/card0/pcmC0D0c ├── pcmC0D0p - ../../devices/pci:00/:00:1b.0/sound/card0/pcmC0D0p ├── pcmC1D0c - ../../devices/pci:00/:00:1a.7/usb1/1-5/1-5:1.1/sound/card1/pcmC1D0c ├── pcmC2D0c - ../../devices/pci:00/:00:1e.0/:37:09.0/sound/card2/pcmC2D0c ├── pcmC3D0p - ../../devices/pci:00/:00:1a.7/usb1/1-6/1-6.3/1-6.3:1.0/sound/card3/pcmC3D0p ├── seq - ../../devices/virtual/sound/seq └── timer - ../../devices/virtual/sound/timer All that such library/utility/function needs do to is to parse the two above sysfs directories and associate the devices based on the provided aliases. For example, on the above, we have 4 V4L cards: PCI card (in this case, a saa7134-based card) ├── vbi0 - ../../devices/pci:00/:00:1e.0/:37:09.0/video4linux/vbi0 ├── video2 - ../../devices/pci:00/:00:1e.0/:37:09.0/video4linux/video2 └── card2 - ../../devices/pci:00/:00:1e.0/:37:09.0/sound/card2 All tree are at the PCI device :37:09.0. USB card (in this example, an em28xx-based card, that uses snd-usb-audio for alsa) ├── video1 - ../../devices/pci:00/:00:1a.7/usb1/1-5/1-5:1.0/video4linux/video1 └── card1 - ../../devices/pci:00/:00:1a.7/usb1/1-5/1-5:1.1/sound/card1 All two are at the USB 1-5 device.
RE: [DVB] In research of chip's datasheets
-Original Message- From: Issa Gorissen [mailto:flo...@usa.net] Sent: vendredi 20 mai 2011 19:26 To: Sébastien RAILLARD (COEXSI) Cc: linux-media@vger.kernel.org Subject: Re: [DVB] In research of chip's datasheets On 20/05/2011 18:01, Sébastien RAILLARD (COEXSI) wrote: I'm in research of datasheets of the following chips: - tuner STV6110A from ST - dual demodulator STV0900B from ST - CI interface CXD2099AR from SONY Hi Sebastien, If you're targeting the ngene based cards, I think you will also need the spec for the ngene chip and my guess is that it has been programmed (not generic like the 3 other chips). So as Ralph is already in contact with digital devices, I wonder if you will get this information. For the cxd2099ar, talk to sony europe CXD2099_supporteu./sony/.com I sent them an email at the beginning of the week, I still have no answer yet, I hope they will answer. Did you personally manage to get access to the CXD2099 datasheet ? -- Issa -- 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: [GIT PATCH FOR 2.6.40] uvcvideo patches
Em 20-05-2011 12:49, Laurent Pinchart escreveu: Hi Mauro, Thanks for handling the pull request. On Friday 20 May 2011 17:32:45 Mauro Carvalho Chehab wrote: Em 15-05-2011 04:48, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next They replace the git pull request I've sent on Thursday with the same subject. Bob Liu (2): Revert V4L/DVB: v4l2-dev: remove get_unmapped_area uvcvideo: Add support for NOMMU arch IMO, such fixes should happen inside the arch bits, and not on each driver. If this fix is needed for uvc video, the same fix should probably needed to all other USB drivers, in order to work on NOMMU arch. For now, I'm accepting this as a workaround, but please work on a generic solution for it. A fix at the arch/ level isn't possible, as drivers need to implement the get_unmapped_area file operation in order to support NOMMU architectures. The proper fix is of course to port uvcvideo to videobuf2, and implement support for NOMMU in videobuf2. Modifications to individual drivers will still be needed to fill the get_unmapped_area operation pointer with a videobuf2 handler though. This doesn't sound nice, as most people test their drivers only on an specific architecture. If the driver can work on more then one architecture (e. g. if it is not part of the IP block of some SoC chip, but, instead, uses some generic bus like USB or PCI), the driver itself shouldn't contain any arch-specific bits. IMO, the proper fix should be either at the DMA stuff or somewhere inside the bus driver implementation. Hans de Goede (2): v4l: Add M420 format definition uvcvideo: Add M420 format support OK. Laurent Pinchart (4): v4l: Release module if subdev registration fails uvcvideo: Register a v4l2_device uvcvideo: Register subdevices for each entity uvcvideo: Connect video devices to media entities We've discussed already about using the media controller for uvcvideo, but I can't remember anymore what where your aguments in favor of merging it (and, even if I've remembered it right now, the #irc channel log is not the proper way to document the rationale to apply a patch). The thing is: it is clear that SoC embedded devices need the media controller, as they have IP blocks that do weird things, and userspace may need to access those, as it is not possible to control such IP blocks using the V4L2 API. However, I have serious concerns about media_controller API usage on generic drivers, as it is required that all drivers should be fully configurable via V4L2 API alone, otherwise we'll have regressions, as no generic applications use the media_controller. In other words, if you have enough arguments about why we should add media_controller support at the uvcvideo, please clearly provide them at the patch descriptions, as this is not obvious. It would equally important do document, at the uvcvideo doc, what kind of information is provided via the media_controller and why an userspace application should care to use it. First of all, the uvcvideo driver doesn't require application to use the media controller API to operate. All configuration is handled through a V4L2 video device node, and these patches do not modify that. No change is required to applications to use the uvcvideo driver. There's however a reason why I want to add support for the media controller API to the uvcvideo driver (I wouldn't have submitted the patches otherwise :-)). UVC-compliant devices are modeled as a connected graph of entities (called terminals and units in the UVC world). The device topology can be arbitrarily complex (or simple, which is fortunately often the case) and is exported by the device to the host through USB descriptors. The uvcvideo driver parses the descriptor, creates an internal representation of the device internal topology, and maps V4L2 operations to the various entities that the device contains. The UVC specification standardizes a couple of entities (camera terminal, processing unit, ...) and allows device vendors to create vendor-specific entities called extension units (XUs in short). Those XUs are usually used to expose controls that are not standardized by UVC to the host. These controls can be anything from an activity LED to a firmware update system. The uvcvideo tries to map those XU controls to V4L2 controls when it makes sense (and when the controls are documented by the device manufacturer, which is unfortunately often not the case). If an XU control can't be mapped to a V4L2 control, it can be accessed through uvcvideo-specific (documented) ioctls. In order to access those XU controls,
Re: [GIT PATCH FOR 2.6.40] uvcvideo patches
Hi Mauro, On Friday 20 May 2011 21:16:49 Mauro Carvalho Chehab wrote: Em 20-05-2011 12:49, Laurent Pinchart escreveu: On Friday 20 May 2011 17:32:45 Mauro Carvalho Chehab wrote: Em 15-05-2011 04:48, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next They replace the git pull request I've sent on Thursday with the same subject. Bob Liu (2): Revert V4L/DVB: v4l2-dev: remove get_unmapped_area uvcvideo: Add support for NOMMU arch IMO, such fixes should happen inside the arch bits, and not on each driver. If this fix is needed for uvc video, the same fix should probably needed to all other USB drivers, in order to work on NOMMU arch. For now, I'm accepting this as a workaround, but please work on a generic solution for it. A fix at the arch/ level isn't possible, as drivers need to implement the get_unmapped_area file operation in order to support NOMMU architectures. The proper fix is of course to port uvcvideo to videobuf2, and implement support for NOMMU in videobuf2. Modifications to individual drivers will still be needed to fill the get_unmapped_area operation pointer with a videobuf2 handler though. This doesn't sound nice, as most people test their drivers only on an specific architecture. If the driver can work on more then one architecture (e. g. if it is not part of the IP block of some SoC chip, but, instead, uses some generic bus like USB or PCI), the driver itself shouldn't contain any arch-specific bits. IMO, the proper fix should be either at the DMA stuff or somewhere inside the bus driver implementation. It might not sound nice, but that's how NOMMU works. It needs get_unmapped_area. If you can get rid of that requirement I'll be happy to remove NOMMU-specific support from the driver :-) Hans de Goede (2): v4l: Add M420 format definition uvcvideo: Add M420 format support OK. Laurent Pinchart (4): v4l: Release module if subdev registration fails uvcvideo: Register a v4l2_device uvcvideo: Register subdevices for each entity uvcvideo: Connect video devices to media entities We've discussed already about using the media controller for uvcvideo, but I can't remember anymore what where your aguments in favor of merging it (and, even if I've remembered it right now, the #irc channel log is not the proper way to document the rationale to apply a patch). The thing is: it is clear that SoC embedded devices need the media controller, as they have IP blocks that do weird things, and userspace may need to access those, as it is not possible to control such IP blocks using the V4L2 API. However, I have serious concerns about media_controller API usage on generic drivers, as it is required that all drivers should be fully configurable via V4L2 API alone, otherwise we'll have regressions, as no generic applications use the media_controller. In other words, if you have enough arguments about why we should add media_controller support at the uvcvideo, please clearly provide them at the patch descriptions, as this is not obvious. It would equally important do document, at the uvcvideo doc, what kind of information is provided via the media_controller and why an userspace application should care to use it. First of all, the uvcvideo driver doesn't require application to use the media controller API to operate. All configuration is handled through a V4L2 video device node, and these patches do not modify that. No change is required to applications to use the uvcvideo driver. There's however a reason why I want to add support for the media controller API to the uvcvideo driver (I wouldn't have submitted the patches otherwise :-)). UVC-compliant devices are modeled as a connected graph of entities (called terminals and units in the UVC world). The device topology can be arbitrarily complex (or simple, which is fortunately often the case) and is exported by the device to the host through USB descriptors. The uvcvideo driver parses the descriptor, creates an internal representation of the device internal topology, and maps V4L2 operations to the various entities that the device contains. The UVC specification standardizes a couple of entities (camera terminal, processing unit, ...) and allows device vendors to create vendor-specific entities called extension units (XUs in short). Those XUs are usually used to expose controls that are not standardized by UVC to the host. These controls can be anything from an activity LED to a firmware update system. The uvcvideo tries to map those XU controls to V4L2 controls
Re: [GIT PATCH FOR 2.6.40] uvcvideo patches
Em 20-05-2011 16:47, Laurent Pinchart escreveu: Hi Mauro, On Friday 20 May 2011 21:16:49 Mauro Carvalho Chehab wrote: Em 20-05-2011 12:49, Laurent Pinchart escreveu: On Friday 20 May 2011 17:32:45 Mauro Carvalho Chehab wrote: Em 15-05-2011 04:48, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next They replace the git pull request I've sent on Thursday with the same subject. Bob Liu (2): Revert V4L/DVB: v4l2-dev: remove get_unmapped_area uvcvideo: Add support for NOMMU arch IMO, such fixes should happen inside the arch bits, and not on each driver. If this fix is needed for uvc video, the same fix should probably needed to all other USB drivers, in order to work on NOMMU arch. For now, I'm accepting this as a workaround, but please work on a generic solution for it. A fix at the arch/ level isn't possible, as drivers need to implement the get_unmapped_area file operation in order to support NOMMU architectures. The proper fix is of course to port uvcvideo to videobuf2, and implement support for NOMMU in videobuf2. Modifications to individual drivers will still be needed to fill the get_unmapped_area operation pointer with a videobuf2 handler though. This doesn't sound nice, as most people test their drivers only on an specific architecture. If the driver can work on more then one architecture (e. g. if it is not part of the IP block of some SoC chip, but, instead, uses some generic bus like USB or PCI), the driver itself shouldn't contain any arch-specific bits. IMO, the proper fix should be either at the DMA stuff or somewhere inside the bus driver implementation. It might not sound nice, but that's how NOMMU works. It needs get_unmapped_area. If you can get rid of that requirement I'll be happy to remove NOMMU-specific support from the driver :-) As I said, the patches were added, but we need to work on a better solution than polluting every driver with #if CONFIG_NOMMU just because arm arch is crappy. Hans de Goede (2): v4l: Add M420 format definition uvcvideo: Add M420 format support OK. Laurent Pinchart (4): v4l: Release module if subdev registration fails uvcvideo: Register a v4l2_device uvcvideo: Register subdevices for each entity uvcvideo: Connect video devices to media entities We've discussed already about using the media controller for uvcvideo, but I can't remember anymore what where your aguments in favor of merging it (and, even if I've remembered it right now, the #irc channel log is not the proper way to document the rationale to apply a patch). The thing is: it is clear that SoC embedded devices need the media controller, as they have IP blocks that do weird things, and userspace may need to access those, as it is not possible to control such IP blocks using the V4L2 API. However, I have serious concerns about media_controller API usage on generic drivers, as it is required that all drivers should be fully configurable via V4L2 API alone, otherwise we'll have regressions, as no generic applications use the media_controller. In other words, if you have enough arguments about why we should add media_controller support at the uvcvideo, please clearly provide them at the patch descriptions, as this is not obvious. It would equally important do document, at the uvcvideo doc, what kind of information is provided via the media_controller and why an userspace application should care to use it. First of all, the uvcvideo driver doesn't require application to use the media controller API to operate. All configuration is handled through a V4L2 video device node, and these patches do not modify that. No change is required to applications to use the uvcvideo driver. There's however a reason why I want to add support for the media controller API to the uvcvideo driver (I wouldn't have submitted the patches otherwise :-)). UVC-compliant devices are modeled as a connected graph of entities (called terminals and units in the UVC world). The device topology can be arbitrarily complex (or simple, which is fortunately often the case) and is exported by the device to the host through USB descriptors. The uvcvideo driver parses the descriptor, creates an internal representation of the device internal topology, and maps V4L2 operations to the various entities that the device contains. The UVC specification standardizes a couple of entities (camera terminal, processing unit, ...) and allows device vendors to create vendor-specific entities called extension units (XUs in short). Those XUs are usually used to expose controls that are not standardized by UVC to the host. These controls can be anything from an
Re: [GIT PATCH FOR 2.6.40] uvcvideo patches
Hi Mauro, On Friday 20 May 2011 23:01:18 Mauro Carvalho Chehab wrote: Em 20-05-2011 16:47, Laurent Pinchart escreveu: On Friday 20 May 2011 21:16:49 Mauro Carvalho Chehab wrote: Em 20-05-2011 12:49, Laurent Pinchart escreveu: On Friday 20 May 2011 17:32:45 Mauro Carvalho Chehab wrote: Em 15-05-2011 04:48, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next They replace the git pull request I've sent on Thursday with the same subject. Bob Liu (2): Revert V4L/DVB: v4l2-dev: remove get_unmapped_area uvcvideo: Add support for NOMMU arch IMO, such fixes should happen inside the arch bits, and not on each driver. If this fix is needed for uvc video, the same fix should probably needed to all other USB drivers, in order to work on NOMMU arch. For now, I'm accepting this as a workaround, but please work on a generic solution for it. A fix at the arch/ level isn't possible, as drivers need to implement the get_unmapped_area file operation in order to support NOMMU architectures. The proper fix is of course to port uvcvideo to videobuf2, and implement support for NOMMU in videobuf2. Modifications to individual drivers will still be needed to fill the get_unmapped_area operation pointer with a videobuf2 handler though. This doesn't sound nice, as most people test their drivers only on an specific architecture. If the driver can work on more then one architecture (e. g. if it is not part of the IP block of some SoC chip, but, instead, uses some generic bus like USB or PCI), the driver itself shouldn't contain any arch-specific bits. IMO, the proper fix should be either at the DMA stuff or somewhere inside the bus driver implementation. It might not sound nice, but that's how NOMMU works. It needs get_unmapped_area. If you can get rid of that requirement I'll be happy to remove NOMMU-specific support from the driver :-) As I said, the patches were added, but we need to work on a better solution than polluting every driver with #if CONFIG_NOMMU just because arm arch is crappy. There might be some misunderstanding here (not that ARM doesn't bring its share of issues, we both agree on that :-)). NOMMU has nothing to do with ARM, it's for architectures that have no system MMU. Everything lives in the same address space, so some support is needed from drivers when mapping memory to userspace. I'll answer the MC part over the weekend, I need to sleep now :-) -- 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: [GIT PATCH FOR 2.6.40] uvcvideo patches
Em 20-05-2011 18:29, Laurent Pinchart escreveu: Hi Mauro, On Friday 20 May 2011 23:01:18 Mauro Carvalho Chehab wrote: Em 20-05-2011 16:47, Laurent Pinchart escreveu: On Friday 20 May 2011 21:16:49 Mauro Carvalho Chehab wrote: Em 20-05-2011 12:49, Laurent Pinchart escreveu: On Friday 20 May 2011 17:32:45 Mauro Carvalho Chehab wrote: Em 15-05-2011 04:48, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next They replace the git pull request I've sent on Thursday with the same subject. Bob Liu (2): Revert V4L/DVB: v4l2-dev: remove get_unmapped_area uvcvideo: Add support for NOMMU arch IMO, such fixes should happen inside the arch bits, and not on each driver. If this fix is needed for uvc video, the same fix should probably needed to all other USB drivers, in order to work on NOMMU arch. For now, I'm accepting this as a workaround, but please work on a generic solution for it. A fix at the arch/ level isn't possible, as drivers need to implement the get_unmapped_area file operation in order to support NOMMU architectures. The proper fix is of course to port uvcvideo to videobuf2, and implement support for NOMMU in videobuf2. Modifications to individual drivers will still be needed to fill the get_unmapped_area operation pointer with a videobuf2 handler though. This doesn't sound nice, as most people test their drivers only on an specific architecture. If the driver can work on more then one architecture (e. g. if it is not part of the IP block of some SoC chip, but, instead, uses some generic bus like USB or PCI), the driver itself shouldn't contain any arch-specific bits. IMO, the proper fix should be either at the DMA stuff or somewhere inside the bus driver implementation. It might not sound nice, but that's how NOMMU works. It needs get_unmapped_area. If you can get rid of that requirement I'll be happy to remove NOMMU-specific support from the driver :-) As I said, the patches were added, but we need to work on a better solution than polluting every driver with #if CONFIG_NOMMU just because arm arch is crappy. There might be some misunderstanding here (not that ARM doesn't bring its share of issues, we both agree on that :-)). NOMMU has nothing to do with ARM, it's for architectures that have no system MMU. Everything lives in the same address space, so some support is needed from drivers when mapping memory to userspace. I see. Well, having this inside videobuf2 will hide it from the drivers that use it so, it is better than having the same code duplicated into all drivers. Yet, we have several streaming stuff spread. Just naming the most used non-legacy drivers, we have: gspca, videobuf1, videobuf2 and uvcvideo. There are the other drivers that are currently unmaintained with their own streaming implementations. If UVC is broken if no MMU, all the other drivers are also broken. Maybe we should just make all other drivers, for now, dependent of !NOMMU, to avoid showing them to the architectures were they won't work. Or, if the solution given for UVC is generic enough, to just apply it to the other drivers. Yet, the better is to have a NOMMU-dependent code inside the arch-specific bits (or at least having a default handler that would take care of it for NOMMU, that would work for most drivers), to avoid code duplication or having generic drivers dependent of !NOMMU. I'll answer the MC part over the weekend, I need to sleep now :-) OK. 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
Medion CTX1921 - why does the driver is not in the kernel yet?
Hello everybody. First of all - this post is not meant as the flame starter, nor is it I DEMAND kind of post - I just would like to know what is the policy with driver patches. I bought Medion CTX1921 USB DVB-T stick, since I saw patches for kernel 2.6.32: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19938/match=1921 so,I thought everything above that, will support this card out of the box, however I tried it on kernel 2.6.38 and it still required manual patching, after minor driver modification it works OK. So... the question is, why isn't this tuner supported yet, even though patches were aviable nearly a year ago (and where minor)? What is the policy here? When can we expect support? Thanks in advance for the answers. Best Regards P.S Sorry for my English ;] -- 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] xc5000, fix fw upload crash
Em 20-05-2011 10:04, Devin Heitmueller escreveu: On Friday, May 20, 2011, Dmitri Belimov d.beli...@gmail.com wrote: Hi Devin snip NACK! I don't think this patch is correct. Concurrency problems are expected to be handled in the upper layers, as there are usually much more significant problems than just this case. For example, if this is a race between V4L2 and DVB, it is the responsibility of bridge driver to provide proper locking. ... I see two different way add mutex to function where firmware is loaded or to xc5000_set_analog_params Both of this is working I already test it. What you think about it?? ... [ 110.010686] [f81cb6d8] ? set_mode_freq+0xe4/0xff [tuner] [ 110.010689] [f81cb8d4] ? tuner_s_std+0x26/0x5aa [tuner] [ 110.010692] [f81cb8ae] ? tuner_s_std+0x0/0x5aa [tuner] Hmm... this is probably caused by the BKL removal patches. Basically, tuner_s_std is being called without holding dev-lock. The fix is simple, but requires some care: we need either to convert saa7134 to the v4l2 core support (probably not an easy task) or to review all places where dev-lock should be used, e. g. at (almost all) ioctls, and at the other file ops (open, close, mmap, etc). This driver is complex, due to the mpeg optional module used on some devices. So, maybe the in-core locking schema is not the proper way to fix it. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Standardize YUV support in the fbdev API
Hi Laurent,
On 05/17/2011 10:07 PM, Laurent Pinchart wrote:
Hi everybody,
I need to implement support for a YUV frame buffer in an fbdev driver. As the
fbdev API doesn't support this out of the box, I've spent a couple of days
reading fbdev (and KMS) code and thinking about how we could cleanly add YUV
support to the API. I'd like to share my findings and thoughts, and hopefully
receive some comments back.
Thanks. I think you did already a good job, hope we can get it done this time.
Given the overlap between the KMS, V4L2 and fbdev APIs, the need to share data
and buffers between those subsystems, and the planned use of V4L2 FCCs in the
KMS overlay API, I believe using V4L2 FCCs to identify fbdev formats would be
a wise decision.
I agree.
To select a frame buffer YUV format, the fb_var_screeninfo structure will need
to be extended with a format field. The fbdev API and ABI must not be broken,
which prevents us from changing the current structure layout and replacing the
existing format selection mechanism (through the red, green, blue and alpha
bitfields) completely.
I agree.
- Other solutions are possible, such as adding new ioctls. Those solutions are
more intrusive, and require larger changes to both userspace and kernelspace
code.
I'm against (ab)using the nonstd field (probably the only sane thing we can do
with it is declare it non-standard which interpretation is completely dependent
on the specific driver) or requiring previously unused fields to have a special
value so I'd like to suggest a different method:
I remembered an earlier discussion:
[ http://marc.info/?l=linux-fbdevm=129896686208130w=2 ]
On 03/01/2011 08:07 AM, Geert Uytterhoeven wrote:
On Tue, Mar 1, 2011 at 04:13, Damiandhobs...@igel.co.jp wrote:
On 2011/02/24 15:05, Geert Uytterhoeven wrote:
For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new
FB_VISUAL_*
type instead, which indicates the fb_var_screeninfo.{red,green,blue}
fields are
YCbCr instead of RGB.
Depending on the frame buffer organization, you also need new
FB_TYPE_*/FB_AUX_*
types.
I just wanted to clarify here. Is your comment about these new flags in
specific reference to this patch or to Magnus' going forward comment? It
About new flags.
seems like the beginnings of a method to standardize YCbCr support in fbdev
across all platforms.
Also, do I understand correctly that FB_VISUAL_ would specify the colorspace
FB_VISUAL_* specifies how pixel values (which may be tuples) are mapped to
colors on the screen, so to me it looks like the sensible way to set up YCbCr.
(RGB, YCbCr), FB_TYPE_* would be a format specifier (i.e. planar,
semiplanar, interleaved, etc)? I'm not really sure what you are referring
to with the FB_AUX_* however.
Yep, FB_TYPE_* specifies how pixel values/tuples are laid out in frame buffer
memory.
FB_AUX_* is only used if a specific value of FB_TYPE_* needs an additional
parameter (e.g. the interleave value for interleaved bitplanes).
Adding new standard values for these fb_fix_screeninfo fields would solve the
issue for framebuffers which only support a single format. If you have the need
to switch I guess it would be a good idea to add a new flag to the vmode
bitfield in fb_var_screeninfo which looks like a general purpose modifier for
the videomode. You could than reuse any RGB-specific field you like to pass more
information.
Maybe we should also use this chance to declare one of the fix_screeninfo
reserved fields to be used for capability flags or an API version as we can
assume that those are 0 (at least in sane drivers).
Good luck,
Florian Tobias Schandinat
--
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 14/16] tm6000: add pts logging
Em 09-05-2011 16:54, stefan.rin...@arcor.de escreveu:
From: Stefan Ringel stefan.rin...@arcor.de
add pts logging
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-video.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
index 2d83204..4802396 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -355,10 +355,14 @@ static int copy_streams(u8 *data, unsigned long len,
case TM6000_URB_MSG_VBI:
/* Need some code to copy vbi buffer */
break;
- case TM6000_URB_MSG_PTS:
+ case TM6000_URB_MSG_PTS: {
/* Need some code to copy pts */
+ u32 pts;
+ pts = *(u32 *)ptr;
+ printk(KERN_INFO %s: field %d, PTS %x,
dev-name, field, pts);
Hmm... field may be unititialized... Please fix.
drivers/staging/tm6000/tm6000-video.c: In function ‘copy_streams’:
drivers/staging/tm6000/tm6000-video.c:231: warning: ‘field’ may be used
uninitialized in this function
Also, it is not a good idea of just logging it. Instead, use enable logging
only if debug is enabled
seems more appropriate.
Please send a patch fixing it.
Thanks,
Mauro.
break;
}
+ }
}
if (ptr + pktsize endp) {
/* End of URB packet, but cmd processing is not
--
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] cx18: Move spinlock and vb_type initialisation into stream_init
Em 10-05-2011 10:49, Simon Farnsworth escreveu: The initialisation of vb_type in serialized_open was preventing REQBUFS from working reliably. Remove it, and move the spinlock into stream_init for good measure - it's only used when we have a stream that supports videobuf anyway. Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk --- Mauro, This fixes a bug I introduced, and noticed while trying to work out how videobuf works and interacts with the rest of the driver, in preparation for working out how to port this code to videobuf2. Briefly, if you open a device node at the wrong time, you lose videobuf support forever. Please consider this for 2.6.40, /me is assuming that Andy is ok with it. Ok, I'm adding this to my series, as it is part of the code you added. Thanks, 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: AW: Remote control not working for Terratec Cinergy C (2.6.37 Mantis driver)
On Fri, 13 May 2011, Christoph Pinkl wrote: Would be nice to get some Feedback. Hello, thanks for the patch. I've been waiting for 2.6.39 to hit the testing repository of my distribution before testing. Should happen any day. I need that version because of sound driver fixes. I have the SS2 HD2, will report how it goes. -- Adrian C. (anrxc) | anrxc..sysphere.org | PGP ID: D20A0618 PGP FP: 02A5 628A D8EE 2A93 996E 929F D5CB 31B7 D20A 0618 -- 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] tm6000: fix uninitialized field, change prink to dprintk
From: Stefan Ringel stefan.rin...@arcor.de fix uninitialized field, change prink to dprintk Signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- drivers/staging/tm6000/tm6000-video.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/tm6000/tm6000-video.c b/drivers/staging/tm6000/tm6000-video.c index 4802396..3baee84 100644 --- a/drivers/staging/tm6000/tm6000-video.c +++ b/drivers/staging/tm6000/tm6000-video.c @@ -228,7 +228,7 @@ static int copy_streams(u8 *data, unsigned long len, u8 *ptr = data, *endp = data+len, c; unsigned long header = 0; int rc = 0; - unsigned int cmd, cpysize, pktsize, size, field, block, line, pos = 0; + unsigned int cmd, cpysize, pktsize, size, field = 0, block, line, pos = 0; struct tm6000_buffer *vbuf = NULL; char *voutp = NULL; unsigned int linewidth; @@ -359,7 +359,8 @@ static int copy_streams(u8 *data, unsigned long len, /* Need some code to copy pts */ u32 pts; pts = *(u32 *)ptr; - printk(KERN_INFO %s: field %d, PTS %x, dev-name, field, pts); + dprintk(dev, V4L2_DEBUG_ISOC, field %d, PTS %x, + field, pts); break; } } -- 1.7.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
