DViCO FusionHDTV7 Dual Express remote driver
Which module needs to be loaded to get the remote for the FusionHDTV7 dual express working? -- 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] drivers: move media after i2c
Currently drivers/media drivers are linked very early - directly after base, block, misc, and mfd and before ata, scsi, ide, input, firewire, usb, and i2c. This breaks static build of video4linux drivers, that use generic CPU i2c adapter drivers and the v4l2-subdev subsystem, because during video4linux probing the v4l2-subdev core requires a struct i2c_adapter context, which cannot be satisfied before the i2c subsystem is initialised. Moving drivers/media after drivers/i2c fixes this problem. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- The best way to trigger action is by submitting a patch:-) So, let's see what comes out of it - on the one hand I don't see any reason why media has to be linked this early, and nobody was able to give me one yesterday as this problem has been discussed on linux-media, OTOH, maybe indeed it would be better to move i2c the whole way up above media, but that'd be much bigger of a change, I think. diff --git a/drivers/Makefile b/drivers/Makefile index 2618a61..1266ead 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -36,7 +36,7 @@ obj-$(CONFIG_FB_INTEL) += video/intelfb/ obj-y += serial/ obj-$(CONFIG_PARPORT) += parport/ -obj-y += base/ block/ misc/ mfd/ media/ +obj-y += base/ block/ misc/ mfd/ obj-$(CONFIG_NUBUS)+= nubus/ obj-y += macintosh/ obj-$(CONFIG_IDE) += ide/ @@ -71,7 +71,7 @@ obj-$(CONFIG_GAMEPORT)+= input/gameport/ obj-$(CONFIG_INPUT)+= input/ obj-$(CONFIG_I2O) += message/ obj-$(CONFIG_RTC_LIB) += rtc/ -obj-y += i2c/ +obj-y += i2c/ media/ obj-$(CONFIG_W1) += w1/ obj-$(CONFIG_POWER_SUPPLY) += power/ obj-$(CONFIG_HWMON)+= hwmon/ -- 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] soc-camera: link host drivers after clients
With the transition of soc-camera to become a platform driver and to the v4l2-subdev framework the initialisation order becomes important. In case of a static build clients (i2c) drivers have to be available when host drivers are probed. Moving host drivers down in the Makefile achieves the desired order. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 7c0bd6e..400bbd5 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -134,10 +134,6 @@ obj-$(CONFIG_VIDEO_CX18) += cx18/ obj-$(CONFIG_VIDEO_VIVI) += vivi.o obj-$(CONFIG_VIDEO_CX23885) += cx23885/ -obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o -obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o -obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o -obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o obj-$(CONFIG_SOC_CAMERA) += soc_camera.o obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o @@ -147,6 +143,11 @@ obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o +# soc-camera host drivers have to be linked after camera drivers +obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o +obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o +obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o +obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o obj-$(CONFIG_VIDEO_AU0828) += au0828/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ for: changeset: 11570:ccddae0f5d8f gspca - zc3xx: Bad debug level in i2c_read. changeset: 11571:c3ae07c7c476 gspca - tp6800: New subdriver with webcam 06a2:0003. changeset: 11572:b7b10bc9ad67 tag: tip gspca - main: Version change. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Nova-TD usb dual tuner issue
Hi, When I connect my Nova-TD dual tuner usb stick to my debian/sid box with 2.6.29.1 kernel I can only use the second tuner (mplayer dvb://2@tvchannel). When trying to use the first one (dvb://1...@...) tuning is extremely bad and an image barely appears with many errors. I tried switching the antennas to no avail, the problem persists. Is this a know problem, or do I just have a bad stick ? Thanks, PS: here is the syslog output when connecting the stick: usb 2-2: new high speed USB device using ehci_hcd and address 3 Apr 19 15:33:50 delos kernel: usb 2-2: configuration #1 chosen from 1 choice Apr 19 15:33:50 delos kernel: dvb-usb: found a 'Hauppauge Nova-TD Stick (52009)' in cold state, will try to load a firmware Apr 19 15:33:50 delos kernel: usb 2-2: firmware: requesting dvb-usb-dib0700-1.20.fw Apr 19 15:33:50 delos kernel: dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' Apr 19 15:33:50 delos kernel: dib0700: firmware started successfully. Apr 19 15:33:51 delos kernel: dvb-usb: found a 'Hauppauge Nova-TD Stick (52009)' in warm state. Apr 19 15:33:51 delos kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Apr 19 15:33:51 delos kernel: DVB: registering new adapter (Hauppauge Nova-TD Stick (52009)) Apr 19 15:33:51 delos kernel: DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... Apr 19 15:33:51 delos kernel: DiB0070: successfully identified Apr 19 15:33:51 delos kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Apr 19 15:33:51 delos kernel: DVB: registering new adapter (Hauppauge Nova-TD Stick (52009)) Apr 19 15:33:51 delos kernel: DVB: registering adapter 1 frontend 0 (DiBcom 7000PC)... Apr 19 15:33:52 delos kernel: DiB0070: successfully identified -- 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] v4l2-subdev: add a v4l2_i2c_new_dev_subdev() function
Video (sub)devices, connecting to SoCs over generic i2c busses cannot
provide a pointer to struct v4l2_device in i2c-adapter driver_data, and
provide their own i2c_board_info data, including a platform_data field.
Add a v4l2_i2c_new_dev_subdev() API function that does exactly the same as
v4l2_i2c_new_subdev() but uses different parameters, and make
v4l2_i2c_new_subdev() a wrapper around it.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 1da8cb8..c55fc99 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -783,8 +783,6 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct
i2c_client *client,
}
EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_init);
-
-
/* Load an i2c sub-device. It assumes that i2c_get_adapdata(adapter)
returns the v4l2_device and that i2c_get_clientdata(client)
returns the v4l2_subdev. */
@@ -792,23 +790,34 @@ struct v4l2_subdev *v4l2_i2c_new_subdev(struct
i2c_adapter *adapter,
const char *module_name, const char *client_type, u8 addr)
{
struct v4l2_device *dev = i2c_get_adapdata(adapter);
- struct v4l2_subdev *sd = NULL;
- struct i2c_client *client;
struct i2c_board_info info;
- BUG_ON(!dev);
-
- if (module_name)
- request_module(module_name);
-
/* Setup the i2c board info with the device type and
the device address. */
memset(info, 0, sizeof(info));
strlcpy(info.type, client_type, sizeof(info.type));
info.addr = addr;
+ return v4l2_i2c_new_dev_subdev(adapter, module_name, info, dev);
+}
+EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
+
+/* Load an i2c sub-device. It assumes that i2c_get_clientdata(client)
+ returns the v4l2_subdev. */
+struct v4l2_subdev *v4l2_i2c_new_dev_subdev(struct i2c_adapter *adapter,
+ const char *module_name, const struct i2c_board_info *info,
+ struct v4l2_device *dev)
+{
+ struct v4l2_subdev *sd = NULL;
+ struct i2c_client *client;
+
+ BUG_ON(!dev);
+
+ if (module_name)
+ request_module(module_name);
+
/* Create the i2c client */
- client = i2c_new_device(adapter, info);
+ client = i2c_new_device(adapter, info);
/* Note: it is possible in the future that
c-driver is NULL if the driver is still being loaded.
We need better support from the kernel so that we
@@ -835,7 +844,7 @@ error:
i2c_unregister_device(client);
return sd;
}
-EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
+EXPORT_SYMBOL_GPL(v4l2_i2c_new_dev_subdev);
/* Probe and load an i2c sub-device. It assumes that i2c_get_adapdata(adapter)
returns the v4l2_device and that i2c_get_clientdata(client)
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 3a69056..0722b00 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -131,6 +131,7 @@ struct i2c_driver;
struct i2c_adapter;
struct i2c_client;
struct i2c_device_id;
+struct i2c_board_info;
struct v4l2_device;
struct v4l2_subdev;
struct v4l2_subdev_ops;
@@ -144,6 +145,10 @@ int v4l2_i2c_attach(struct i2c_adapter *adapter, int
address, struct i2c_driver
The client_type argument is the name of the chip that's on the adapter. */
struct v4l2_subdev *v4l2_i2c_new_subdev(struct i2c_adapter *adapter,
const char *module_name, const char *client_type, u8 addr);
+/* Same as above but uses user-provided v4l2_device and i2c_board_info */
+struct v4l2_subdev *v4l2_i2c_new_dev_subdev(struct i2c_adapter *adapter,
+ const char *module_name, const struct i2c_board_info *info,
+ struct v4l2_device *dev);
/* Probe and load an i2c module and return an initialized v4l2_subdev struct.
Only call request_module if module_name != NULL.
The client_type argument is the name of the chip that's on the adapter. */
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: move media after i2c
On Tue, 21 Apr 2009 09:22:38 +0200 (CEST), Guennadi Liakhovetski wrote: Currently drivers/media drivers are linked very early - directly after base, block, misc, and mfd and before ata, scsi, ide, input, firewire, usb, and i2c. This breaks static build of video4linux drivers, that use generic CPU i2c adapter drivers and the v4l2-subdev subsystem, because during video4linux probing the v4l2-subdev core requires a struct i2c_adapter context, which cannot be satisfied before the i2c subsystem is initialised. Moving drivers/media after drivers/i2c fixes this problem. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Looks good to me. Acked-by: Jean Delvare kh...@linux-fr.org --- The best way to trigger action is by submitting a patch:-) So, let's see what comes out of it - on the one hand I don't see any reason why media has to be linked this early, and nobody was able to give me one yesterday as this problem has been discussed on linux-media, OTOH, maybe indeed it would be better to move i2c the whole way up above media, but that'd be much bigger of a change, I think. diff --git a/drivers/Makefile b/drivers/Makefile index 2618a61..1266ead 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -36,7 +36,7 @@ obj-$(CONFIG_FB_INTEL) += video/intelfb/ obj-y+= serial/ obj-$(CONFIG_PARPORT)+= parport/ -obj-y+= base/ block/ misc/ mfd/ media/ +obj-y+= base/ block/ misc/ mfd/ obj-$(CONFIG_NUBUS) += nubus/ obj-y+= macintosh/ obj-$(CONFIG_IDE)+= ide/ @@ -71,7 +71,7 @@ obj-$(CONFIG_GAMEPORT) += input/gameport/ obj-$(CONFIG_INPUT) += input/ obj-$(CONFIG_I2O)+= message/ obj-$(CONFIG_RTC_LIB)+= rtc/ -obj-y+= i2c/ +obj-y+= i2c/ media/ obj-$(CONFIG_W1) += w1/ obj-$(CONFIG_POWER_SUPPLY) += power/ obj-$(CONFIG_HWMON) += hwmon/ -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2-subdev: add a v4l2_i2c_new_dev_subdev() function
Video (sub)devices, connecting to SoCs over generic i2c busses cannot
provide a pointer to struct v4l2_device in i2c-adapter driver_data, and
provide their own i2c_board_info data, including a platform_data field.
Add a v4l2_i2c_new_dev_subdev() API function that does exactly the same as
v4l2_i2c_new_subdev() but uses different parameters, and make
v4l2_i2c_new_subdev() a wrapper around it.
Huh? Against what repository are you compiling? The v4l2_device pointer
has already been added!
Regards,
Hans
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 1da8cb8..c55fc99 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -783,8 +783,6 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd,
struct i2c_client *client,
}
EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_init);
-
-
/* Load an i2c sub-device. It assumes that i2c_get_adapdata(adapter)
returns the v4l2_device and that i2c_get_clientdata(client)
returns the v4l2_subdev. */
@@ -792,23 +790,34 @@ struct v4l2_subdev *v4l2_i2c_new_subdev(struct
i2c_adapter *adapter,
const char *module_name, const char *client_type, u8 addr)
{
struct v4l2_device *dev = i2c_get_adapdata(adapter);
- struct v4l2_subdev *sd = NULL;
- struct i2c_client *client;
struct i2c_board_info info;
- BUG_ON(!dev);
-
- if (module_name)
- request_module(module_name);
-
/* Setup the i2c board info with the device type and
the device address. */
memset(info, 0, sizeof(info));
strlcpy(info.type, client_type, sizeof(info.type));
info.addr = addr;
+ return v4l2_i2c_new_dev_subdev(adapter, module_name, info, dev);
+}
+EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
+
+/* Load an i2c sub-device. It assumes that i2c_get_clientdata(client)
+ returns the v4l2_subdev. */
+struct v4l2_subdev *v4l2_i2c_new_dev_subdev(struct i2c_adapter *adapter,
+ const char *module_name, const struct i2c_board_info *info,
+ struct v4l2_device *dev)
+{
+ struct v4l2_subdev *sd = NULL;
+ struct i2c_client *client;
+
+ BUG_ON(!dev);
+
+ if (module_name)
+ request_module(module_name);
+
/* Create the i2c client */
- client = i2c_new_device(adapter, info);
+ client = i2c_new_device(adapter, info);
/* Note: it is possible in the future that
c-driver is NULL if the driver is still being loaded.
We need better support from the kernel so that we
@@ -835,7 +844,7 @@ error:
i2c_unregister_device(client);
return sd;
}
-EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
+EXPORT_SYMBOL_GPL(v4l2_i2c_new_dev_subdev);
/* Probe and load an i2c sub-device. It assumes that
i2c_get_adapdata(adapter)
returns the v4l2_device and that i2c_get_clientdata(client)
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 3a69056..0722b00 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -131,6 +131,7 @@ struct i2c_driver;
struct i2c_adapter;
struct i2c_client;
struct i2c_device_id;
+struct i2c_board_info;
struct v4l2_device;
struct v4l2_subdev;
struct v4l2_subdev_ops;
@@ -144,6 +145,10 @@ int v4l2_i2c_attach(struct i2c_adapter *adapter, int
address, struct i2c_driver
The client_type argument is the name of the chip that's on the
adapter. */
struct v4l2_subdev *v4l2_i2c_new_subdev(struct i2c_adapter *adapter,
const char *module_name, const char *client_type, u8 addr);
+/* Same as above but uses user-provided v4l2_device and i2c_board_info */
+struct v4l2_subdev *v4l2_i2c_new_dev_subdev(struct i2c_adapter *adapter,
+ const char *module_name, const struct i2c_board_info *info,
+ struct v4l2_device *dev);
/* Probe and load an i2c module and return an initialized v4l2_subdev
struct.
Only call request_module if module_name != NULL.
The client_type argument is the name of the chip that's on the
adapter. */
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2-subdev: add a v4l2_i2c_new_dev_subdev() function
On Tue, 21 Apr 2009, Hans Verkuil wrote:
Video (sub)devices, connecting to SoCs over generic i2c busses cannot
provide a pointer to struct v4l2_device in i2c-adapter driver_data, and
provide their own i2c_board_info data, including a platform_data field.
Add a v4l2_i2c_new_dev_subdev() API function that does exactly the same as
v4l2_i2c_new_subdev() but uses different parameters, and make
v4l2_i2c_new_subdev() a wrapper around it.
Huh? Against what repository are you compiling? The v4l2_device pointer
has already been added!
Ok, have to rebase then. I guess, it still would be better to do the way I
propose in this patch - to add a new function, with i2c_board_info as a
parameter and convert v4l2_i2c_new_subdev() to a wrapper around it, than
to convert all existing users, agree? Do you also agree with the name?
Thanks
Guennadi
Regards,
Hans
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 1da8cb8..c55fc99 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -783,8 +783,6 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd,
struct i2c_client *client,
}
EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_init);
-
-
/* Load an i2c sub-device. It assumes that i2c_get_adapdata(adapter)
returns the v4l2_device and that i2c_get_clientdata(client)
returns the v4l2_subdev. */
@@ -792,23 +790,34 @@ struct v4l2_subdev *v4l2_i2c_new_subdev(struct
i2c_adapter *adapter,
const char *module_name, const char *client_type, u8 addr)
{
struct v4l2_device *dev = i2c_get_adapdata(adapter);
- struct v4l2_subdev *sd = NULL;
- struct i2c_client *client;
struct i2c_board_info info;
- BUG_ON(!dev);
-
- if (module_name)
- request_module(module_name);
-
/* Setup the i2c board info with the device type and
the device address. */
memset(info, 0, sizeof(info));
strlcpy(info.type, client_type, sizeof(info.type));
info.addr = addr;
+ return v4l2_i2c_new_dev_subdev(adapter, module_name, info, dev);
+}
+EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
+
+/* Load an i2c sub-device. It assumes that i2c_get_clientdata(client)
+ returns the v4l2_subdev. */
+struct v4l2_subdev *v4l2_i2c_new_dev_subdev(struct i2c_adapter *adapter,
+ const char *module_name, const struct i2c_board_info *info,
+ struct v4l2_device *dev)
+{
+ struct v4l2_subdev *sd = NULL;
+ struct i2c_client *client;
+
+ BUG_ON(!dev);
+
+ if (module_name)
+ request_module(module_name);
+
/* Create the i2c client */
- client = i2c_new_device(adapter, info);
+ client = i2c_new_device(adapter, info);
/* Note: it is possible in the future that
c-driver is NULL if the driver is still being loaded.
We need better support from the kernel so that we
@@ -835,7 +844,7 @@ error:
i2c_unregister_device(client);
return sd;
}
-EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
+EXPORT_SYMBOL_GPL(v4l2_i2c_new_dev_subdev);
/* Probe and load an i2c sub-device. It assumes that
i2c_get_adapdata(adapter)
returns the v4l2_device and that i2c_get_clientdata(client)
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 3a69056..0722b00 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -131,6 +131,7 @@ struct i2c_driver;
struct i2c_adapter;
struct i2c_client;
struct i2c_device_id;
+struct i2c_board_info;
struct v4l2_device;
struct v4l2_subdev;
struct v4l2_subdev_ops;
@@ -144,6 +145,10 @@ int v4l2_i2c_attach(struct i2c_adapter *adapter, int
address, struct i2c_driver
The client_type argument is the name of the chip that's on the
adapter. */
struct v4l2_subdev *v4l2_i2c_new_subdev(struct i2c_adapter *adapter,
const char *module_name, const char *client_type, u8 addr);
+/* Same as above but uses user-provided v4l2_device and i2c_board_info */
+struct v4l2_subdev *v4l2_i2c_new_dev_subdev(struct i2c_adapter *adapter,
+ const char *module_name, const struct i2c_board_info *info,
+ struct v4l2_device *dev);
/* Probe and load an i2c module and return an initialized v4l2_subdev
struct.
Only call request_module if module_name != NULL.
The client_type argument is the name of the chip that's on the
adapter. */
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
---
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: [PATCH] v4l2-subdev: add a v4l2_i2c_new_dev_subdev() function
On Tue, 21 Apr 2009, Hans Verkuil wrote: On Tue, 21 Apr 2009, Hans Verkuil wrote: Video (sub)devices, connecting to SoCs over generic i2c busses cannot provide a pointer to struct v4l2_device in i2c-adapter driver_data, and provide their own i2c_board_info data, including a platform_data field. Add a v4l2_i2c_new_dev_subdev() API function that does exactly the same as v4l2_i2c_new_subdev() but uses different parameters, and make v4l2_i2c_new_subdev() a wrapper around it. Huh? Against what repository are you compiling? The v4l2_device pointer has already been added! Ok, have to rebase then. I guess, it still would be better to do the way I propose in this patch - to add a new function, with i2c_board_info as a parameter and convert v4l2_i2c_new_subdev() to a wrapper around it, than to convert all existing users, agree? Do you also agree with the name? I like the idea of passing in a board_info struct instead of an addr/client_type. And converting v4l2_i2c_new_subdev() to a wrapper is ok too? Just make sure when preparing a patch for the v4l-dvb repo that this new function is for kernels = 2.6.26 only. Why and how? I am not adding any new structs or fields with this patch, am I? So it should build with all kernels, with which the current v4l2_i2c_new_subdev() builds. I prefer a name like v4l2_i2c_subdev_board(). I will probably at some stage remove that '_new' part of the existing functions anyway as that doesn't add anything to the name. Ok, will do. 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: [PATCH] v4l2-subdev: add a v4l2_i2c_new_dev_subdev() function
On Tue, 21 Apr 2009, Agustin wrote: Hi, --- On 21/4/09, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Video (sub)devices, connecting to SoCs over generic i2c busses cannot provide a pointer to struct v4l2_device in i2c-adapter driver_data, and provide their own i2c_board_info data, including a platform_data field. Add a v4l2_i2c_new_dev_subdev() API function that does exactly the same as v4l2_i2c_new_subdev() but uses different parameters, and make v4l2_i2c_new_subdev() a wrapper around it. [snip] I am wondering about this ongoing effort and its pursued goal: is it to hierarchize the v4l architecture, adding new abstraction levels? If so, what for? Driver-reuse. soc-camera framework will be able to use all available and new v4l2-subdev drivers, and vice versa. To me, as an eventual driver developer, this makes it harder to integrate my own drivers, as I use I2C and V4L in my system but I don't want them to be tightly coupled. This conversion shouldn't make the coupling any tighter. Of course I can ignore this subdev stuff and just link against soc-camera which is what I need, and manage I2C without V4L knowing about it. Which is what I do. You won't be able to. The only link to woc-camera will be the v4l2-subdev link. Already now with this patch many essential soc-camera API operations are gone. 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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
-Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Monday, April 20, 2009 4:15 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 00X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. [Hiremath, Vaibhav] Hi Kim, I went through the document and below are some observations and questions I have - - If I compare it with OMAP then there is nothing application needs to configure specific to hardware. All the parameters supported through v4l2_format one with TYPE_VIDEO_OUTPUT and another with TYPE_VIDEO_CAPTURE except the parameter offset (If driver is supporting it) - I wanted to understand how are you configuring offset register? How are you exporting it to user application? Rest everything we can handle in driver once input source and output destination format receives from application. From OMAP Point of view - --- The extra configuration is coefficients, which if we don't export to user application then I think we are very close to your IP. Extra configuration required other than coeff. RSZ_YENH - which takes 4 params - Algo - Gain - Slope - Core All are part of one register so we can make use of priv field for this configuration. Thanks, Vaibhav Hiremath Cheers, Nate On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: Thanks, Vaibhav Hiremath -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Dongsoo Kim Sent: Sunday, April 19, 2009 12:06 PM To: Hans Verkuil Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Hans and Hiremath, One of my recent job is making S3C64XX camera interface driver (even though other jobs of mine are not finished yet...;-() And, what a incident! S3C64XX has also similar H/W block in camera interface. Resizer in S3C camera interface can be used in system wide like the one in Omap3. [Hiremath, Vaibhav] Can you share the spec for the same; I wanted to verify the configuration part of it? What all configuration is exported to the user? But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT. I thought that is was enough. Actually I took omap video out (vout?) for reference :-) [Hiremath, Vaibhav] I have also implemented the driver is the same way and also working with Hans to get it reviewed. But there are some configuration like coeff., luma enhancement, etc... need to export to the user, where we need to add mechanism in V4L2 framework. Since we have one more device where we are demanding for M-to-M operation, I think it is important to go through it. Can you share some documents of your IP for better understanding. Cheers, Nate 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be
Re: [PATCH] v4l2-subdev: add a v4l2_i2c_new_dev_subdev() function
On Tue, 21 Apr 2009, Hans Verkuil wrote: The board_info struct didn't appear until 2.6.22, so that's certainly a cut-off point. Since the probe version of this call does not work on kernels 2.6.26 the autoprobing mechanism is still used for those older kernels. I think it makes life much easier to require that everything that uses board_info needs kernel 2.6.26 at the minimum. I don't think that is an issue anyway for soc-camera. Unless there is a need to use soc-camera from v4l-dvb with kernels 2.6.26? No, most definitely ultimately undoubtedly NOT. 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: [PATCH] v4l2-subdev: add a v4l2_i2c_new_dev_subdev() function
On Tue, 21 Apr 2009, Hans Verkuil wrote:
Video (sub)devices, connecting to SoCs over generic i2c busses cannot
provide a pointer to struct v4l2_device in i2c-adapter driver_data,
and
provide their own i2c_board_info data, including a platform_data
field.
Add a v4l2_i2c_new_dev_subdev() API function that does exactly the
same as
v4l2_i2c_new_subdev() but uses different parameters, and make
v4l2_i2c_new_subdev() a wrapper around it.
Huh? Against what repository are you compiling? The v4l2_device pointer
has already been added!
Ok, have to rebase then. I guess, it still would be better to do the way I
propose in this patch - to add a new function, with i2c_board_info as a
parameter and convert v4l2_i2c_new_subdev() to a wrapper around it, than
to convert all existing users, agree? Do you also agree with the name?
I like the idea of passing in a board_info struct instead of an
addr/client_type. Just make sure when preparing a patch for the v4l-dvb
repo that this new function is for kernels = 2.6.26 only.
I prefer a name like v4l2_i2c_subdev_board(). I will probably at some
stage remove that '_new' part of the existing functions anyway as that
doesn't add anything to the name.
Regards,
Hans
Thanks
Guennadi
Regards,
Hans
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 1da8cb8..c55fc99 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -783,8 +783,6 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd,
struct i2c_client *client,
}
EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_init);
-
-
/* Load an i2c sub-device. It assumes that i2c_get_adapdata(adapter)
returns the v4l2_device and that i2c_get_clientdata(client)
returns the v4l2_subdev. */
@@ -792,23 +790,34 @@ struct v4l2_subdev *v4l2_i2c_new_subdev(struct
i2c_adapter *adapter,
const char *module_name, const char *client_type, u8 addr)
{
struct v4l2_device *dev = i2c_get_adapdata(adapter);
- struct v4l2_subdev *sd = NULL;
- struct i2c_client *client;
struct i2c_board_info info;
- BUG_ON(!dev);
-
- if (module_name)
- request_module(module_name);
-
/* Setup the i2c board info with the device type and
the device address. */
memset(info, 0, sizeof(info));
strlcpy(info.type, client_type, sizeof(info.type));
info.addr = addr;
+ return v4l2_i2c_new_dev_subdev(adapter, module_name, info, dev);
+}
+EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
+
+/* Load an i2c sub-device. It assumes that i2c_get_clientdata(client)
+ returns the v4l2_subdev. */
+struct v4l2_subdev *v4l2_i2c_new_dev_subdev(struct i2c_adapter
*adapter,
+ const char *module_name, const struct i2c_board_info *info,
+ struct v4l2_device *dev)
+{
+ struct v4l2_subdev *sd = NULL;
+ struct i2c_client *client;
+
+ BUG_ON(!dev);
+
+ if (module_name)
+ request_module(module_name);
+
/* Create the i2c client */
- client = i2c_new_device(adapter, info);
+ client = i2c_new_device(adapter, info);
/* Note: it is possible in the future that
c-driver is NULL if the driver is still being loaded.
We need better support from the kernel so that we
@@ -835,7 +844,7 @@ error:
i2c_unregister_device(client);
return sd;
}
-EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
+EXPORT_SYMBOL_GPL(v4l2_i2c_new_dev_subdev);
/* Probe and load an i2c sub-device. It assumes that
i2c_get_adapdata(adapter)
returns the v4l2_device and that i2c_get_clientdata(client)
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 3a69056..0722b00 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -131,6 +131,7 @@ struct i2c_driver;
struct i2c_adapter;
struct i2c_client;
struct i2c_device_id;
+struct i2c_board_info;
struct v4l2_device;
struct v4l2_subdev;
struct v4l2_subdev_ops;
@@ -144,6 +145,10 @@ int v4l2_i2c_attach(struct i2c_adapter *adapter,
int
address, struct i2c_driver
The client_type argument is the name of the chip that's on the
adapter. */
struct v4l2_subdev *v4l2_i2c_new_subdev(struct i2c_adapter *adapter,
const char *module_name, const char *client_type, u8 addr);
+/* Same as above but uses user-provided v4l2_device and
i2c_board_info */
+struct v4l2_subdev *v4l2_i2c_new_dev_subdev(struct i2c_adapter
*adapter,
+ const char *module_name, const struct i2c_board_info *info,
+ struct v4l2_device *dev);
/* Probe and load an i2c module and return an initialized v4l2_subdev
struct.
Only call request_module if module_name != NULL.
The client_type argument is the name of the chip that's on the
adapter. */
--
Hans Verkuil - video4linux developer -
Re: [PATCH/RFC v1] soc-camera: (partially) convert to v4l2-(sub)dev API
...as promised, my current stack is at http://download.open-technology.de/20090421/. To encourage you to test it now without waiting for my rebase - the functionality shall be exactly the same after the rebase, it really shouldn't change much, or so I hope at least... 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: Applying SoC camera framework on multi-functional camera interface
On Tue, 21 Apr 2009, Hans Verkuil wrote: Well, you might look at drivers/media/video/soc_camera_platform.c for an example of a simple pseudo camera driver. Of course, with your two additional devices you don't want to add extra platform devices and extra probing. In fact, you can do this with the old (currently in the mainline) soc-camera model, where client drivers actively report themselves to the soc-camera core using soc_camera_device_register() / soc_camera_device_unregister() and the core doesn't care about the nature of those drivers. This is not going to be the case with the new platform / v4l2-subdev infrastructure, which is pretty tightly bound to i2c... So, we'll have to extend it too. Not true. v4l2-device and v4l2-subdev are bus-independent. Only the v4l2-i2c-* helper functions in v4l2-common.c are i2c dependent. For example, ivtv uses v4l2_subdev to control devices connected via gpio, while cx18 uses it for a logical video decoder block on the main asic. Other than initialization and possibly cleanup there should be NO bus-dependencies. Sorry, what I wrote above wasn't clear enough. By platform / v4l2-subdev infrastructure I meant the current (as of my patch from a couple of hours ago) soc-camera - platform stack linked to v4l2-subdev the way it is implemented there. In that patch soc-camera uses the i2c interface of v4l2-subdev directly and is thus rather i2c-centric. So, we will have to extend soc-camera to also support the bus-neutral v4l2-subdev API. 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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
-Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Tuesday, April 21, 2009 3:44 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello, Vaibhav, On Tue, Apr 21, 2009 at 7:01 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Hiremath, Vaibhav Sent: Tuesday, April 21, 2009 3:16 PM To: 'Dongsoo, Nathaniel Kim' Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Monday, April 20, 2009 4:15 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 00X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. [Hiremath, Vaibhav] Hi Kim, I went through the document and below are some observations and questions I have - - If I compare it with OMAP then there is nothing application needs to configure specific to hardware. All the parameters supported through v4l2_format one with TYPE_VIDEO_OUTPUT and another with TYPE_VIDEO_CAPTURE except the parameter offset (If driver is supporting it) I'm not sure whether I'm following your question, but S3C64XX camera interface is obviously simpler than OMAP. So there is no wonder that user doesn't need to configure H/W specific things. And I don't get the question about offset parameter. Can you explain me more specifically? [Hiremath, Vaibhav] Please refer to the section 16.5.1 (Page no 532 (16-11)) 16.7.11 and 16.7.16. You can specify offset from the input image to start, so that you can have part of image for scaling. - I wanted to understand how are you configuring offset register? How are you exporting it to user application? Again, I don't get the point. Sorry. Rest everything we can handle in driver once input source and output destination format receives from application. [Hiremath, Vaibhav] Missed one point in last draft, about buffer handling. How are you handling buffers? Are you supporting both USER_POINTER and MMAP buffers? What is the size of buffers, is that different for input and output? If yes, then how are you managing it? If no, don't you see requirement for it? Sorry, my driver work is not that stage yet. It's just still in designing level, because of some special H/W features (like MSDMA, scaler and so) I'm totally stuck and can't go further. But your buffer theory seems to make sense and I suppose that is necessary if we have that kind of device. [Hiremath, Vaibhav] I am talking to Mauro, and will keep you updated on this. Thanks, Vaibhav Hiremath Thanks, Vaibhav From OMAP Point of view - --- The extra configuration is coefficients, which if we don't export to user application then I think we are very close to your IP. Extra configuration required other than coeff. RSZ_YENH - which takes 4 params - Algo - Gain - Slope - Core All are part of one register so we can make use of priv field for this configuration. I get it. But S3C64XX is not that much configurable. As you see in user manual, it's a quite simple device. For now I'm still designing my driver, so I'll let you know if I face those issues in my driver. Cheers, Nate Thanks, Vaibhav Hiremath Cheers, Nate On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com
dib0700 Nova-TD-Stick problem
For a few weeks I use a Nova-TD-Stick and was annoyed with dvb stream
errors, although the demod bit-error-rate (BER/UNC) was zero.
I could track down this problem to dib0700_streaming_ctrl:
When one channel is streaming and the other channel is switched on,
the stream of the already running channel gets broken.
I think this is a firmware bug and should be fixed there, but I attach
a driver patch, which solved the problem for me. (Kernel 2.6.29.1, FW
1.20, Nova-T-Stick + Nova-TD-Stick used together). Since I had to
reduce the urb count to 1, I consider this patch as quick hack, not a
real solution.
Probably the same problem exists with other dib0700 diversity/dual
devices, without a firmware fix a similar driver patch may be helpful.
Regards,
Soeren
--- drivers/media/dvb/dvb-usb/dib0700_devices.c.orig 2009-04-18 16:45:12.0 +0200
+++ drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-04-18 18:58:54.0 +0200
@@ -290,6 +290,9 @@ static int stk7700d_frontend_attach(stru
adap-fe = dvb_attach(dib7000p_attach, adap-dev-i2c_adap,0x80+(adap-id 1),
stk7700d_dib7000p_mt2266_config[adap-id]);
+adap-props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
return adap-fe == NULL ? -ENODEV : 0;
}
@@ -1414,7 +1417,7 @@ MODULE_DEVICE_TABLE(usb, dib0700_usb_id_
.streaming_ctrl = dib0700_streaming_ctrl, \
.stream = { \
.type = USB_BULK, \
- .count = 4, \
+ .count = 1, \
.endpoint = ep, \
.u = { \
.bulk = { \
Re: Applying SoC camera framework on multi-functional camera interface
On Tue, 21 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hello, One of my recent work is making S3C64XX camera interface driver with SoC camera framework. Thanks to Guennadi, SoC camera framework is so clear and easy to follow. Actually I didn't need to worry about my whole driver structure, the framework almost has everything that I need. But here is a problem that I couldn't make up my mind while implementing some of the features of S3C64XX camera IP. As you know, S3C64XX camera IP has scaler and rotator capability on it's own which can be used standalone even memory to memory scaling and rotating jobs. If you want to know in detail please take a look at the user manual (just remind if you have already seen this) : http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C6400X_UserManual_rev1-0_2008-02_661558um.pdf Telling you about the driver concept that I wanted to make is like following: (I want to select inputs like external camera and MSDMA using S_INPUT'/G_INPUT but we don't have them in SoC camera framework. So this should be the version of design with current SoC camera framework.) 1. S3C64XX has preview and codec path 2. Each preview and codec path can have external camera and MSDMA for input 3. make external camera and MSDMA device nodes for each preview and codec. = Let's assume that we have camera A and B, then it should go like this /dev/video0 (camera A on preview device) /dev/video1 (camera B on preview device) /dev/video2 (MSDMA on preview device) /dev/video3 (camera A on codec device) /dev/video4 (camera B on codec device) /dev/video5 (MSDMA on codec device) My proposal was a bit different. You don't need two different output devices per camera - video3 and video4. I suggested to make preview a pure output device, without the ability to select the input. So, if you activate (open) video1, video3 will get data from the first camera. If you activate video2, video3 will preview camera 2. Also, you can have a look at arch/sh/boards/mach-migor/setup.c for an example of handling two cameras on one interface. The only difference to what I have proposed is that they block on open(video1) if video0 is in use and the other way round. Whereas I suggested to return -EBUSY. You can choose. 4. Those device nodes are device in SoC camera framework (and S3C camera interface should be host device) = External camera devices can be made in SoC camera device. Fair enough. But MSMDA? what should I do If I want to make it as a device driver in SoC camera framework? Any reference that I could have? because I can't find any device drivers besides camera sensor,isp drivers. Please let me know if there is any. Actually, last time we talked about it I didn't realise, that you can configure the preview path to read data from memory while your codec path processes data from the camera, is this really the case? I didn't study the datasheet in enough detail. Well, you might look at drivers/media/video/soc_camera_platform.c for an example of a simple pseudo camera driver. Of course, with your two additional devices you don't want to add extra platform devices and extra probing. In fact, you can do this with the old (currently in the mainline) soc-camera model, where client drivers actively report themselves to the soc-camera core using soc_camera_device_register() / soc_camera_device_unregister() and the core doesn't care about the nature of those drivers. This is not going to be the case with the new platform / v4l2-subdev infrastructure, which is pretty tightly bound to i2c... So, we'll have to extend it too. Not true. v4l2-device and v4l2-subdev are bus-independent. Only the v4l2-i2c-* helper functions in v4l2-common.c are i2c dependent. For example, ivtv uses v4l2_subdev to control devices connected via gpio, while cx18 uses it for a logical video decoder block on the main asic. Other than initialization and possibly cleanup there should be NO bus-dependencies. Regards, Hans I would suggest you reserve slots for those two from-memory video devices in your design, base your design on latest patches on this list (see the patches I just submitted) and concentrate on camera-devices for now. Then we shall see how to add non-i2c video data-sources to the framework. -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA)
The patch works perfectly. No indicator light, but 28 channels with stronger signal than mce! Thanks again! Ben -- 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] v4l2-subdev: add a v4l2_i2c_new_dev_subdev() function
On 21/4/09, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Tue, 21 Apr 2009, Agustin wrote: Hi, On 21/4/09, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Video (sub)devices, connecting to SoCs over generic i2c busses cannot provide a pointer to struct v4l2_device in i2c-adapter driver_data, and provide their own i2c_board_info data, including a platform_data field. Add a v4l2_i2c_new_dev_subdev() API function that does exactly the same as v4l2_i2c_new_subdev() but uses different parameters, and make v4l2_i2c_new_subdev() a wrapper around it. [snip] I am wondering about this ongoing effort and its pursued goal: is it to hierarchize the v4l architecture, adding new abstraction levels? If so, what for? Driver-reuse. soc-camera framework will be able to use all available and new v4l2-subdev drivers, and vice versa. Well, Driver reuse. sounds more as a mantra than a reason for me. Then I can't find any available v4l2-subdev driver in 2.6.29. I assume this subdev stuff plays a mayor role in current V4L2 architecture refactorization. Then we probably should take this opportunity to relieve V4L APIs from all its explicit I2C mangling, because... To me, as an eventual driver developer, this makes it harder to integrate my own drivers, as I use I2C and V4L in my system but I don't want them to be tightly coupled. This conversion shouldn't make the coupling any tighter. But still I think V4L system should not be aware of I2C at all. To me, V4L is a kernel subsystem in charge of moving multimedia data from/to userspace/hardware, and the APIs should reflect just that. If one V4L driver uses I2C for device control, what does V4L have to say about that, really? Or why V4L would never care about usb or SPI links? I2C and V4L should stay cleanly and clearly apart. Of course I can ignore this subdev stuff and just link against soc-camera which is what I need, and manage I2C without V4L knowing about it. Which is what I do. You won't be able to. The only link to woc-camera will be the v4l2-subdev link. Already now with this patch many essential soc-camera API operations are gone. I guess you mean that I will have to use v4l2-subdev interface to connect to soc-camera, and not to surrender my I2C management to an I2C-extraneous subsystem. Is that right? (Sorry for arriving this late to the discussion just to critizise your good efforts.) Regards, --Agustín. -- 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] v4l2-subdev: add a v4l2_i2c_new_dev_subdev() function
On 21/4/09, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Tue, 21 Apr 2009, Agustin wrote: Hi, On 21/4/09, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Video (sub)devices, connecting to SoCs over generic i2c busses cannot provide a pointer to struct v4l2_device in i2c-adapter driver_data, and provide their own i2c_board_info data, including a platform_data field. Add a v4l2_i2c_new_dev_subdev() API function that does exactly the same as v4l2_i2c_new_subdev() but uses different parameters, and make v4l2_i2c_new_subdev() a wrapper around it. [snip] I am wondering about this ongoing effort and its pursued goal: is it to hierarchize the v4l architecture, adding new abstraction levels? If so, what for? Driver-reuse. soc-camera framework will be able to use all available and new v4l2-subdev drivers, and vice versa. Well, Driver reuse. sounds more as a mantra than a reason for me. Then I can't find any available v4l2-subdev driver in 2.6.29. Look in 2.6.30. Also look in Documentation/video4linux/v4l2-framework.txt which documents the new framework. I assume this subdev stuff plays a mayor role in current V4L2 architecture refactorization. Then we probably should take this opportunity to relieve V4L APIs from all its explicit I2C mangling, because... That is the case if you use v4l2_subdev. That's completely bus independent. To me, as an eventual driver developer, this makes it harder to integrate my own drivers, as I use I2C and V4L in my system but I don't want them to be tightly coupled. This conversion shouldn't make the coupling any tighter. But still I think V4L system should not be aware of I2C at all. To me, V4L is a kernel subsystem in charge of moving multimedia data from/to userspace/hardware, and the APIs should reflect just that. If one V4L driver uses I2C for device control, what does V4L have to say about that, really? Or why V4L would never care about usb or SPI links? I2C and V4L should stay cleanly and clearly apart. Again, that's what v4l2_subdev does. And in fact it is used like that already in the ivtv and cx18 drivers. Of course I can ignore this subdev stuff and just link against soc-camera which is what I need, and manage I2C without V4L knowing about it. Which is what I do. You won't be able to. The only link to woc-camera will be the v4l2-subdev link. Already now with this patch many essential soc-camera API operations are gone. I guess you mean that I will have to use v4l2-subdev interface to connect to soc-camera, and not to surrender my I2C management to an I2C-extraneous subsystem. Is that right? (Sorry for arriving this late to the discussion just to critizise your good efforts.) All i2c v4l drivers should use v4l2_subdev so that they can be reused in other PCI/USB/platform/whatever drivers. Currently sensor drivers such as mt9m111 are tied to soc-camera and are impossible to reuse in e.g. a USB webcam driver. In 2.6.30 all i2c v4l drivers used by PCI and USB drivers are converted to v4l2_subdev. By 2.6.31 I hope that the soc-camera i2c drivers and the i2c drivers based on v4l2-int-device.h are also converted, thus making the i2c v4l drivers completely reusable. In addition, the flexibility of v4l2_subdev allows it to be used for other non-i2c devices as well. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hello Vaibhav, On Tue, Apr 21, 2009 at 9:08 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Tuesday, April 21, 2009 3:44 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello, Vaibhav, On Tue, Apr 21, 2009 at 7:01 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Hiremath, Vaibhav Sent: Tuesday, April 21, 2009 3:16 PM To: 'Dongsoo, Nathaniel Kim' Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Monday, April 20, 2009 4:15 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 00X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. [Hiremath, Vaibhav] Hi Kim, I went through the document and below are some observations and questions I have - - If I compare it with OMAP then there is nothing application needs to configure specific to hardware. All the parameters supported through v4l2_format one with TYPE_VIDEO_OUTPUT and another with TYPE_VIDEO_CAPTURE except the parameter offset (If driver is supporting it) I'm not sure whether I'm following your question, but S3C64XX camera interface is obviously simpler than OMAP. So there is no wonder that user doesn't need to configure H/W specific things. And I don't get the question about offset parameter. Can you explain me more specifically? [Hiremath, Vaibhav] Please refer to the section 16.5.1 (Page no 532 (16-11)) 16.7.11 and 16.7.16. You can specify offset from the input image to start, so that you can have part of image for scaling. Oh! sorry I made you get confused. What I'm working on is not the TV scaler of S3C64XX but scaler and rotator in camera interface. Please take a look at 20-1 camera interface This scaler/rotator feature can be used in general purpose. - I wanted to understand how are you configuring offset register? How are you exporting it to user application? Again, I don't get the point. Sorry. Rest everything we can handle in driver once input source and output destination format receives from application. [Hiremath, Vaibhav] Missed one point in last draft, about buffer handling. How are you handling buffers? Are you supporting both USER_POINTER and MMAP buffers? What is the size of buffers, is that different for input and output? If yes, then how are you managing it? If no, don't you see requirement for it? Sorry, my driver work is not that stage yet. It's just still in designing level, because of some special H/W features (like MSDMA, scaler and so) I'm totally stuck and can't go further. But your buffer theory seems to make sense and I suppose that is necessary if we have that kind of device. [Hiremath, Vaibhav] I am talking to Mauro, and will keep you updated on this. Thank you. I appreciate it. Nate Thanks, Vaibhav Hiremath Thanks, Vaibhav From OMAP Point of view - --- The extra configuration is coefficients, which if we don't export to user application then I think we are very close to your IP. Extra configuration required other than coeff. RSZ_YENH - which takes 4 params - Algo - Gain - Slope - Core All are part of one register so we can make use of priv field for this
Re: need help for omap3 isp-camera interface
Weng, Wending wrote: Hi All, I'm working on video image capture(omap3 isp) interface(PSP 1.0.2), and have met many difficulties. At the camera side, the 8 bits BT656 signal are connected to cam_d[0-7], which looks OK. The cam_fld, cam_hs and cam_vs are also connected, At the omap3 side, I use saMmapLoopback.c, it runs, however, it receives only HS_VS_IRQ, but no any image data. I checked FLDSTAT(CCDC_SYN_MODE), it's never changed. Right now, I don't know what to check, if you can give some suggestions, your help will be greatly appreciated. Thanks in advance. I haven't been using the parallel interface nor I know anyone else who would have. Sergio, any idea? Anyway, this sounds like a problem in the parallel receiver side. You could try also configuring the VD1 IRQ to happen much earlier, say on 10th line. See ISPCCDC_VDINT handling in ispccdc.c. I'm going to update the patchset as soon as I get linux-omap booting again. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA)
Thomas Nicolai wrote: I tried updating it just a few minutes ago. After a restart, I tried using the card. I still get no lights on the card and get no lock on any channels. with MCE in windows I get about 6 channels at my location, all with very good signal strength. Here is my output from lspci -vnn followed by the out put from dmesg. I am sorry it is so long, I wanted to include it all in case you see something I missed. snip Date: Mon, 20 Apr 2009 21:51:27 -0400 From: st...@linuxtv.org Subject: Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA) To: pgh...@yahoo.com CC: linux-media@vger.kernel.org; mche...@infradead.org If there is anything I can do that will help you find the bug, please let me know.. The issue is fixed. http://linuxtv.org/hg/~stoth/cx23885-hvr1500/rev/7853c00870e1 It's locking OK for me now. If you can clone, built and test - thus confirm the fix - that would be great. Build instructions on the wiki: http://linuxtv.org/wiki/index.php/How_to_Obtain%2C_Build_and_Install_V4L-DVB_Device_Drivers Thanks, - Steve Don't top-post. The protocol is to reply underneath the previous email. Ben confirm the patch works correctly for him also, so I suspect you have some kind of build or installation problem. Maybe your missing firmware? Your lspci and dmesg output looked good, I see no issues with this. - Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA)
Benster Jeremy wrote: The patch works perfectly. No indicator light, but 28 channels with stronger signal than mce! Good, thanks for the feedback. Ignore the light, it's a visual indicator only. At some point we'll get back to fixing that. Regards, - Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Hauppauge HVR-1500 (aka HP RM436AA#ABA)
Steve, still haven't figured out how not to top post with Hotmail, Sorry. :-) too much of a newb at this. When I get your update below do I pull with the normal method or do I need to pull just from that link? What is the proper procedure for this? Tom Date: Mon, 20 Apr 2009 21:51:27 -0400 From: st...@linuxtv.org Subject: Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA) To: pgh...@yahoo.com CC: linux-media@vger.kernel.org; mche...@infradead.org If there is anything I can do that will help you find the bug, please let me know.. The issue is fixed. http://linuxtv.org/hg/~stoth/cx23885-hvr1500/rev/7853c00870e1 It's locking OK for me now. If you can clone, built and test - thus confirm the fix - that would be great. Build instructions on the wiki: http://linuxtv.org/wiki/index.php/How_to_Obtain%2C_Build_and_Install_V4L-DVB_Device_Drivers Thanks, - Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html _ Rediscover Hotmail®: Now available on your iPhone or BlackBerry http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Mobile2_042009-- 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: Nova-TD usb dual tuner issue
When I connect my Nova-TD dual tuner usb stick to my debian/sid box with 2.6.29.1 kernel I can only use the second tuner (mplayer dvb://2@tvchannel). When trying to use the first one (dvb://1...@...) tuning is extremely bad and an image barely appears with many errors. I tried switching the antennas to no avail, the problem persists. Is this a know problem, or do I just have a bad stick ? Due to my experience the gain and frequency response of the internal amplifiers at both antenna inputs is different, so the same antenna can work fine at one port and not so good at the other, at least for some channel. I had problems with strong antenna signals, so I used an attenuator to improve reception. HTH, Soeren -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA)
Benster Jeremy wrote: The patch works perfectly. No indicator light, but 28 channels with stronger signal than mce! Thanks again! Ben -- 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 Can you pls give some hint wether w_scan now also works with your card? --winfried -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA)
Thomas Nicolai wrote: Steve, still haven't figured out how not to top post with Hotmail, Sorry. :-) too much of a newb at this. Can't you scroll to the end of the email and insert your message? When I get your update below do I pull with the normal method or do I need to pull just from that link? What is the proper procedure for this? See below. Tom Date: Mon, 20 Apr 2009 21:51:27 -0400 From: st...@linuxtv.org Subject: Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA) To: pgh...@yahoo.com CC: linux-media@vger.kernel.org; mche...@infradead.org If there is anything I can do that will help you find the bug, please let me know.. The issue is fixed. http://linuxtv.org/hg/~stoth/cx23885-hvr1500/rev/7853c00870e1 It's locking OK for me now. If you can clone, built and test - thus confirm the fix - that would be great. Build instructions on the wiki: http://linuxtv.org/wiki/index.php/How_to_Obtain%2C_Build_and_Install_V4L-DVB_Device_Drivers Thanks, - Steve Hey Tom, I spoke with Ben off-list. He has kindly offered to walk you through the clone, build and install mechanisms off-list, in other words a little one-to-one help. Rather than repeat his email address here, exposing his address, please look back through the mailing list and contact him directly. In the spirit of 'one good turn', if you can spend a few minutes to update the hvr-1500 product page on the linuxtv.org wiki (http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1500) then you'd be helping another user in the future :) - Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
-Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Tuesday, April 21, 2009 6:34 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, On Tue, Apr 21, 2009 at 9:08 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Tuesday, April 21, 2009 3:44 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello, Vaibhav, On Tue, Apr 21, 2009 at 7:01 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Hiremath, Vaibhav Sent: Tuesday, April 21, 2009 3:16 PM To: 'Dongsoo, Nathaniel Kim' Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Monday, April 20, 2009 4:15 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 00X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. [Hiremath, Vaibhav] Hi Kim, I went through the document and below are some observations and questions I have - - If I compare it with OMAP then there is nothing application needs to configure specific to hardware. All the parameters supported through v4l2_format one with TYPE_VIDEO_OUTPUT and another with TYPE_VIDEO_CAPTURE except the parameter offset (If driver is supporting it) I'm not sure whether I'm following your question, but S3C64XX camera interface is obviously simpler than OMAP. So there is no wonder that user doesn't need to configure H/W specific things. And I don't get the question about offset parameter. Can you explain me more specifically? [Hiremath, Vaibhav] Please refer to the section 16.5.1 (Page no 532 (16-11)) 16.7.11 and 16.7.16. You can specify offset from the input image to start, so that you can have part of image for scaling. Oh! sorry I made you get confused. What I'm working on is not the TV scaler of S3C64XX but scaler and rotator in camera interface. Please take a look at 20-1 camera interface This scaler/rotator feature can be used in general purpose. - I wanted to understand how are you configuring offset register? How are you exporting it to user application? Again, I don't get the point. Sorry. Rest everything we can handle in driver once input source and output destination format receives from application. [Hiremath, Vaibhav] Missed one point in last draft, about buffer handling. How are you handling buffers? Are you supporting both USER_POINTER and MMAP buffers? What is the size of buffers, is that different for input and output? If yes, then how are you managing it? If no, don't you see requirement for it? Sorry, my driver work is not that stage yet. It's just still in designing level, because of some special H/W features (like MSDMA, scaler and so) I'm totally stuck and can't go further. But your buffer theory seems to make sense and I suppose that is
[PATCH] pwc : do not pass stack allocated buffers to USB core.
This is causes problems on platforms that have alignment requirements for DMA
transfers.
Signed-off-by: Martin Fuzzey mfuz...@gmail.com
---
drivers/media/video/pwc/pwc-ctrl.c | 238 +---
1 files changed, 164 insertions(+), 74 deletions(-)
diff --git a/drivers/media/video/pwc/pwc-ctrl.c
b/drivers/media/video/pwc/pwc-ctrl.c
index f9fbe02..50b415e 100644
--- a/drivers/media/video/pwc/pwc-ctrl.c
+++ b/drivers/media/video/pwc/pwc-ctrl.c
@@ -159,35 +159,67 @@ static void pwc_set_image_buffer_size(struct pwc_device
*pdev);
//
+static int _send_control_msg(struct pwc_device *pdev,
+ u8 request, u16 value, int index, void *buf, int buflen, int timeout)
+{
+ int rc;
+ void *kbuf = NULL;
+
+ if (buflen) {
+ kbuf = kmalloc(buflen, GFP_KERNEL); /* not allowed on stack */
+ if (kbuf == NULL)
+ return -ENOMEM;
+ memcpy(kbuf, buf, buflen);
+ }
-#define SendControlMsg(request, value, buflen) \
- usb_control_msg(pdev-udev, usb_sndctrlpipe(pdev-udev, 0), \
- request, \
- USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, \
- value, \
- pdev-vcinterface, \
- buf, buflen, 500)
+ rc = usb_control_msg(pdev-udev, usb_sndctrlpipe(pdev-udev, 0),
+ request,
+ USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ value,
+ index,
+ kbuf, buflen, timeout);
-#define RecvControlMsg(request, value, buflen) \
- usb_control_msg(pdev-udev, usb_rcvctrlpipe(pdev-udev, 0), \
- request, \
- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE, \
- value, \
- pdev-vcinterface, \
- buf, buflen, 500)
+ kfree(kbuf);
+ return rc;
+}
+static int recv_control_msg(struct pwc_device *pdev,
+ u8 request, u16 value, void *buf, int buflen)
+{
+ int rc;
+ void *kbuf = kmalloc(buflen, GFP_KERNEL); /* not allowed on stack */
+
+ if (kbuf == NULL)
+ return -ENOMEM;
+
+ rc = usb_control_msg(pdev-udev, usb_rcvctrlpipe(pdev-udev, 0),
+ request,
+ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ value,
+ pdev-vcinterface,
+ kbuf, buflen, 500);
+ memcpy(buf, kbuf, buflen);
+ kfree(kbuf);
+ return rc;
+}
-static int send_video_command(struct usb_device *udev, int index, void *buf,
int buflen)
+static inline int send_video_command(struct pwc_device *pdev,
+ int index, void *buf, int buflen)
{
- return usb_control_msg(udev,
- usb_sndctrlpipe(udev, 0),
+ return _send_control_msg(pdev,
SET_EP_STREAM_CTL,
- USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
VIDEO_OUTPUT_CONTROL_FORMATTER,
index,
buf, buflen, 1000);
}
+static inline int send_control_msg(struct pwc_device *pdev,
+ u8 request, u16 value, void *buf, int buflen)
+{
+ return _send_control_msg(pdev,
+ request, value, pdev-vcinterface, buf, buflen, 500);
+}
+
static int set_video_mode_Nala(struct pwc_device *pdev, int size, int frames)
@@ -224,7 +256,7 @@ static int set_video_mode_Nala(struct pwc_device *pdev, int
size, int frames)
return -EINVAL;
memcpy(buf, pEntry-mode, 3);
- ret = send_video_command(pdev-udev, pdev-vendpoint, buf, 3);
+ ret = send_video_command(pdev, pdev-vendpoint, buf, 3);
if (ret 0) {
PWC_DEBUG_MODULE(Failed to send video command... %d\n, ret);
return ret;
@@ -285,7 +317,7 @@ static int set_video_mode_Timon(struct pwc_device *pdev,
int size, int frames, i
memcpy(buf, pChoose-mode, 13);
if (snapshot)
buf[0] |= 0x80;
- ret = send_video_command(pdev-udev, pdev-vendpoint, buf, 13);
+ ret = send_video_command(pdev, pdev-vendpoint, buf, 13);
if (ret 0)
return ret;
@@ -358,7 +390,7 @@ static int set_video_mode_Kiara(struct pwc_device *pdev,
int size, int frames, i
buf[0] |= 0x80;
/* Firmware bug: video endpoint is 5, but commands are sent to endpoint
4 */
- ret = send_video_command(pdev-udev, 4 /* pdev-vendpoint */, buf, 12);
+ ret = send_video_command(pdev, 4 /* pdev-vendpoint */, buf, 12);
if (ret 0)
return ret;
@@ -530,7 +562,8 @@ int pwc_get_brightness(struct pwc_device *pdev)
char buf;
int ret;
- ret = RecvControlMsg(GET_LUM_CTL, BRIGHTNESS_FORMATTER, 1);
+ ret = recv_control_msg(pdev,
+ GET_LUM_CTL, BRIGHTNESS_FORMATTER, buf, sizeof(buf));
if (ret 0)
return ret;
return buf;
@@
Problem with pinnacle pctv 72e usb stick (dib0700 - based)
Hi, ive got a problem with my dib0700-based usb dvb-t stick. I'm currently using firmware 1.20 with module parameter force_lna_activation=1. Actually, when i set the long filter timeout option, i can use w_scan and successfully find 8 channels. But i do not get any output from the card when accessing /dev/dvb/adapter1/dvr0. The tzap output is the following: Code: using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' reading channels from file 'dvbt_channels.conf' tuning to 76200 Hz video pid 0x012d, audio pid 0x012e status 1e | signal | snr | ber 001f | unc 0256 | FE_HAS_LOCK status 1e | signal | snr | ber 0180 | unc 2aa3 | FE_HAS_LOCK status 1e | signal | snr | ber 0a20 | unc 2b2d | FE_HAS_LOCK status 1e | signal | snr | ber 4af0 | unc 2b7c | FE_HAS_LOCK status 1e | signal | snr | ber 0900 | unc 2c5b | FE_HAS_LOCK status 1e | signal | snr | ber 7a90 | unc 2c31 | FE_HAS_LOCK status 1e | signal | snr | ber 5ba0 | unc 2c9c | FE_HAS_LOCK status 1e | signal | snr | ber 03a0 | unc 2df8 | FE_HAS_LOCK status 1e | signal | snr | ber 01c0 | unc 2d80 | FE_HAS_LOCK status 1e | signal | snr | ber 2870 | unc 2efd | FE_HAS_LOCK But the strange thing is, when i boot the system into windows and reboot it into linux again (thus letting the windows driver download the firmware to the stick so linux finds it in warm state and doesnt download it again) it works flawlessy with exactly the same commands. The status of tzap then changes from 1e as above to 1f. I would really appreciate any help for this problem, if any other information is needed, i'll be glad to post it here! P.S.: i also tried with different (older) firmware versions and also tried to compile the newest drivers from the linuxtv mercurial repo with no luck... _ Chiama gratis dal tuo PC! Parla su Messenger http://clk.atdmt.com/GBL/go/140630369/direct/01/-- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Mauro, Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/ for the following 3 changesets: uvcvideo: Prevent invormation loss with removing implicit casting uvcvideo: fill reserved fields with zero of VIDIOC_QUERYMENU uvcvideo: fix uvc resume failed uvc_v4l2.c | 10 -- uvc_video.c |2 +- 2 files changed, 9 insertions(+), 3 deletions(-) Thanks, 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: + drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505.patch added to -mm tree
Hello!
Am Montag, den 20.04.2009, 13:21 -0700 schrieb
a...@linux-foundation.org:
The patch titled
drivers/media/video/saa7134: add tuner support for AverMedia Studio 505
has been added to the -mm tree. Its filename is
drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505.patch
Before you just go and hit reply, please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
--
Subject: drivers/media/video/saa7134: add tuner support for AverMedia Studio
505
From: Vasiliy Temnikov v...@newmail.ru
Add tuner support AverMedia AverTV Studio 505.
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hermann Pitton hermann-pit...@arcor.de
Cc: Michael Krufky mkru...@linuxtv.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
Documentation/video4linux/CARDLIST.saa7134 |1
drivers/media/video/saa7134/saa7134-cards.c | 43 ++
drivers/media/video/saa7134/saa7134-input.c |1
drivers/media/video/saa7134/saa7134-video.c |2
drivers/media/video/saa7134/saa7134.h |1
5 files changed, 47 insertions(+), 1 deletion(-)
diff -puN
Documentation/video4linux/CARDLIST.saa7134~drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505
Documentation/video4linux/CARDLIST.saa7134
---
a/Documentation/video4linux/CARDLIST.saa7134~drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505
+++ a/Documentation/video4linux/CARDLIST.saa7134
@@ -156,3 +156,4 @@
155 - Hauppauge WinTV-HVR1120 ATSC/QAM-Hybrid [0070:6706,0070:6708]
156 - Hauppauge WinTV-HVR1110r3
[0070:6707,0070:6709,0070:670a]
157 - Avermedia AVerTV Studio 507UA[1461:a11b]
+158 - AverMedia AverTV Studio 505 [1461:a115]
diff -puN
drivers/media/video/saa7134/saa7134-cards.c~drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505
drivers/media/video/saa7134/saa7134-cards.c
---
a/drivers/media/video/saa7134/saa7134-cards.c~drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505
+++ a/drivers/media/video/saa7134/saa7134-cards.c
@@ -1364,6 +1364,42 @@ struct saa7134_board saa7134_boards[] =
.amux = LINE1,
},
},
+ [SAA7134_BOARD_AVERMEDIA_STUDIO_505] = {
+ /* Vasiliy Temnikov v...@newmail.ru */
+ .name = AverMedia AverTV Studio 505,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tda9887_conf = TDA9887_PRESENT,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = LINE2,
+ .tv = 1,
+ },{
+ .name = name_comp1,
+ .vmux = 0,
+ .amux = LINE2,
+ },{
+ .name = name_comp2,
+ .vmux = 3,
+ .amux = LINE2,
+ },{
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE2,
+ }},
+ .radio = {
+ .name = name_radio,
+ .amux = LINE2,
+ },
+ .mute = {
+ .name = name_mute,
+ .amux = LINE1,
+ },
+ },
[SAA7134_BOARD_UPMOST_PURPLE_TV] = {
.name = UPMOST PURPLE TV,
.audio_clock= 0x00187de7,
@@ -5049,6 +5085,12 @@ struct pci_device_id saa7134_pci_tbl[] =
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7130,
.subvendor= 0x1461, /* Avermedia Technologies Inc */
+ .subdevice= 0xa115,
+ .driver_data = SAA7134_BOARD_AVERMEDIA_STUDIO_505,
+ },{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7130,
+ .subvendor= 0x1461, /* Avermedia Technologies Inc */
.subdevice= 0x2108,
.driver_data = SAA7134_BOARD_AVERMEDIA_305,
},{
@@ -6144,6 +6186,7 @@ int saa7134_board_init1(struct saa7134_d
case SAA7134_BOARD_KWORLD_VSTREAM_XPERT:
case
[RFC] Updated 3430SDP and LDP camera drivers
Hi all, I have created a gitorious account for storing latest progress on 3430SDP and LDP camera sensor drivers. (MT9P012 and OV3640 for SDP, and OV3640 for LDP) This patchset can be pulled with the following command: git pull git://git.gitorious.org/omap3-linux-camera-driver/mainline.git omap3camerabase 3430sdp_and_ldp_sensor_drivers It is based on 2.6.30-rc2 Notes: - omap3camerabase branch contains a snapshot of almost all the commits shared through Sakari's gitorious repository (http://www.gitorious.org/projects/omap3camera). The only commits lacking are the ones that had been accepted already on mainline/linux-omap. - 3430sdp_and_ldp_sensor_drivers: Contains the patches I have been sharing during the past months but with some fixes done already based on the comments many of you have provided (Thanks a lot for that) Known TODOs: - v4l2_subdev conversion! - ISP xclk exported to Clock API - Memory 2 memory device conversion - Syncup with latest internal tree fixes - Use regulator framework - Fix OV3640 (at least on SDP doesn't work now somehow) As soon as I update them, will let you know. Any comment on those, is completely welcome. Regards, Sergio -- 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: + drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505.patch added to -mm tree
On Wed, 22 Apr 2009 01:21:18 +0200 hermann pitton hermann-pit...@arcor.de wrote: Hmm, do we try to fix/improve it on Andrew's tree or take it over to mercurial v4l-dvb and send back from there? I'll drop the patch which I have. Please don't lose it! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: + drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505.patch added to -mm tree
On Wed, 22 Apr 2009 01:21:18 +0200
hermann pitton hermann-pit...@arcor.de wrote:
Vasily, your change in saa7134-video.c has broken support for all other
SECAM standards and users can't change them from the applications
anymore.
After years of trouble, it has very good reasons that we have it as it
is and it was a lot of work to make it usable for all, since different
Secam auto detection through the tvaudio kernelthread turned out to be
impossible.
Here is Hartmut's original patch, on which you touch, after working for
a weekend with a signal generator to find a resolution suitable for all.
http://linuxtv.org/hg/v4l-dvb/rev/84a832a5ffc9
The trouble pointed by Hermann is caused by this hunk:
diff -puN
drivers/media/video/saa7134/saa7134-video.c~drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505
drivers/media/video/saa7134/saa7134-video.c
---
a/drivers/media/video/saa7134/saa7134-video.c~drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505
+++ a/drivers/media/video/saa7134/saa7134-video.c
@@ -39,7 +39,7 @@ static unsigned int gbuffers = 8;
static unsigned int noninterlaced; /* 0 */
static unsigned int gbufsize = 720*576*4;
static unsigned int gbufsize_max = 720*576*4;
-static char secam[] = --;
+static char secam[] = dk;
module_param(video_debug, int, 0644);
MODULE_PARM_DESC(video_debug,enable debug messages [video]);
module_param(gbuffers, int, 0444);
This disables SECAM autodetection, forcing the driver to use SECAM/DK. Just
removing this will fix this issue.
Also please don't jump around with the card #define in saa7134.h.
We keep it there like they historically do appear.
---
a/drivers/media/video/saa7134/saa7134.h~drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505
+++ a/drivers/media/video/saa7134/saa7134.h
@@ -159,6 +159,7 @@ struct saa7134_format {
#define SAA7134_BOARD_AVERMEDIA_DVD_EZMAKER 33
#define SAA7134_BOARD_NOVAC_PRIMETV7133 34
#define SAA7134_BOARD_AVERMEDIA_STUDIO_305 35
+#define SAA7134_BOARD_AVERMEDIA_STUDIO_505 158
#define SAA7134_BOARD_UPMOST_PURPLE_TV 36
#define SAA7134_BOARD_ITEMS_MTV005 37
#define SAA7134_BOARD_CINERGY200 38
Agreed. The boards are ordered by number, not by name. Since the board number
should be unique, ordering by something else will likely create duplicate
numbers.
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: Hauppauge HVR-1500 (aka HP RM436AA#ABA)
I got it compiled and can tune channels. Now i just need to get the frontend working. Thanks for checking into this Steve. Tom PS Let me know when the patch gets committed and I will update the page you requested. Date: Tue, 21 Apr 2009 12:12:38 -0400 From: st...@linuxtv.org Subject: Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA) To: nicko...@hotmail.com CC: linux-media@vger.kernel.org Thomas Nicolai wrote: Steve, still haven't figured out how not to top post with Hotmail, Sorry. :-) too much of a newb at this. Can't you scroll to the end of the email and insert your message? When I get your update below do I pull with the normal method or do I need to pull just from that link? What is the proper procedure for this? See below. Tom Date: Mon, 20 Apr 2009 21:51:27 -0400 From: st...@linuxtv.org Subject: Re: Hauppauge HVR-1500 (aka HP RM436AA#ABA) To: pgh...@yahoo.com CC: linux-media@vger.kernel.org; mche...@infradead.org If there is anything I can do that will help you find the bug, please let me know.. The issue is fixed. http://linuxtv.org/hg/~stoth/cx23885-hvr1500/rev/7853c00870e1 It's locking OK for me now. If you can clone, built and test - thus confirm the fix - that would be great. Build instructions on the wiki: http://linuxtv.org/wiki/index.php/How_to_Obtain%2C_Build_and_Install_V4L-DVB_Device_Drivers Thanks, - Steve Hey Tom, I spoke with Ben off-list. He has kindly offered to walk you through the clone, build and install mechanisms off-list, in other words a little one-to-one help. Rather than repeat his email address here, exposing his address, please look back through the mailing list and contact him directly. In the spirit of 'one good turn', if you can spend a few minutes to update the hvr-1500 product page on the linuxtv.org wiki (http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1500) then you'd be helping another user in the future :) - Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html _ Rediscover Hotmail®: Get quick friend updates right in your inbox. http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates2_042009-- 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: [Review PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Hans,
My comments inlined.
Hardik,
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Tuesday, April 21, 2009 5:30 PM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R;
Hiremath, Vaibhav
Subject: RE: [Review PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Hardik,
Just a few comments on your comments :-)
Hi Hans,
My Comments inlined,
Most of the comments are taken care off.
Thanks for review.
Hardik,
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Saturday, April 18, 2009 7:29 PM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav,
Brijesh R;
Hiremath, Vaibhav
Subject: Re: [Review PATCH 3/3] OMAP2/3 V4L2 Display Driver
+config VID2_LCD_MANAGER
+ bool Use LCD Managaer
+ help
+ Select this option if you want VID2 pipeline on LCD Overlay
manager
+endchoice
+
+choice
+prompt TV Mode
+depends on VID2_TV_MANAGER || VID1_TV_MANAGER
+default NTSC_M
+
+config NTSC_M
+bool Use NTSC_M mode
+help
+ Select this option if you want NTSC_M mode on TV
+
+config PAL_BDGHI
+bool Use PAL_BDGHI mode
+help
+ Select this option if you want PAL_BDGHI mode on TV
Terminology: PAL and NTSC etc. refer to broadcast standards. That is no
generally applicable to omap. When it comes to streaming digital video
there is only the 50 and 60 Hz SDTV standards. For output over a
Composite
or S-Video connector you can also choose between PAL and SECAM. There
are some differences between the two, although I'm not sure about the
details. The common saa7128 i2c device definitely has support for both.
In this particular case you probably mean 50 or 60 Hz SDTV rather than
NTSC/PAL.
[Shah, Hardik] OMAP DSS is having the internal video encoder for
converting the digital to analog standards like NTSC and PAL with a
s-video and composite output. Currently DSS does not support changing of
the TV standards dynamically so I have made it as a compile time option.
Once DSS will support that I will add the S_STD and G_STD for standards.
Internally it will call the DSS2 library APIs to change the standard.
I don't have a problem with these config options, it's more the names
NTSC_M and PAL_BDGHI that are misleading IMHO, since it's really a matter
of 50Hz vs 60Hz and not of NTSC vs PAL.
[Shah, Hardik] Video Encoder of the DSS2 supports number of PAL and NTSC
standards out of them only two are supported to I just tried to be specific as
50Hz may mean any PAL standards other than PAL_BDGHI and 60 may mean any NTSC
standard other than NTSC_M. Any way this is not going to be permanent.
+ if (1 == vout-mirror vout-rotation = 0) {
+ rotation_deg = (vout-rotation == 1) ?
+ 3 : (vout-rotation == 3) ?
+ 1 : (vout-rotation == 2) ?
+ 0 : 2;
Or: rotation = (4 - vout-rotation) % 4;
[Shah, Hardik] It will not work when rotation will be 0 and I want 2
because of mirroring. (4-0) % 2 is 0 I want 2 here. So not changing it.
You are right. Sorry about that.
+static int vidioc_s_ctrl(struct file *file, void *fh, struct
v4l2_control
*a)
+{
+ struct omap_vout_device *vout = ((struct omap_vout_fh *)
fh)-vout;
+
+ switch (a-id) {
+ case V4L2_CID_ROTATE:
+ {
+ int rotation = a-value;
+
+ if (vout-pix.pixelformat == V4L2_PIX_FMT_RGB24
+ rotation != -1)
Huh? Shouldn't this be rotation != 0?
[Shah, Hardik] Rotation 0 means the rotation using Virtual Frame Buffer
Rotation (VRFB) engine. It does not support rotation with packed RGB24
format. -1 means VRFB is not used. So it should be -1;
This really isn't right. a-value is the rotate control value. And that's
defined as 0, 90, 180 or 270 according to queryctrl. Not -1. The value -1
is a purely internal value which is also why I am opposed to its use. It
is very confusing.
[Shah, Hardik] Agreed,
I will change that.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
