Re: [RFC] White Balance control for digital camera
Hello Hans,
On Tue, Apr 14, 2009 at 11:50 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On Tuesday 14 April 2009 13:54:02 Mauro Carvalho Chehab wrote:
On Fri, 10 Apr 2009 06:50:32 +0900
Dongsoo, Nathaniel Kim dongsoo@gmail.com wrote:
Hello everyone,
I'm posting this RFC one more time because it seems to everyone has
been forgot this, and I'll be appreciated if any of you who is reading
this mailing list give me comment.
I'm adding some choices for you to make it easier. (even the option
for that this is a pointless discussion)
I've got a big question popping up handling white balance with
V4L2_CID_WHITE_BALANCE_TEMPERATURE CID.
Because in digital camera we generally control over user interface
with pre-defined white balance name. I mean, user controls white
balance with presets not with kelvin number.
I'm very certain that TEMPERATURE CID is needed in many of video
capture devices, but also 100% sure that white balance preset control
is also necessary for digital cameras.
How can we control white balance through preset name with existing V4L2
API?
For now, I define preset names in user space with supported color
temperature preset in driver like following.
#define MANUAL_WB_TUNGSTEN 3000
#define MANUAL_WB_FLUORESCENT 4000
#define MANUAL_WB_SUNNY 5500
#define MANUAL_WB_CLOUDY 6000
and make driver to handle those presets like this. (I split in several
ranges to make driver pretend to be generic)
case V4L2_CID_WHITE_BALANCE_TEMPERATURE:
if (vc-value 3500) {
/* tungsten */
err = ce131f_cmds(c, ce131f_wb_tungsten);
} else if (vc-value 4100) {
/* fluorescent */
err = ce131f_cmds(c, ce131f_wb_fluorescent);
} else if (vc-value 6000) {
/* sunny */
err = ce131f_cmds(c, ce131f_wb_sunny);
} else if (vc-value 6500) {
/* cloudy */
err = ce131f_cmds(c, ce131f_wb_cloudy);
} else {
printk(KERN_INFO %s: unsupported kelvin
range\n, __func__);
}
..
I think this way seems to be ugly. Don't you think that another CID is
necessary to handle WB presets?
Because most of mobile camera modules can't make various color
temperatures in expecting kelvin number with user parameter.
So, here you are some options you can chose to give your opinion.(or
you can make your own opinion)
(A). Make a new CID to handle well known white balance presets
Like V4L2_CID_WHITE_BALANCE_PRESET for CID and enum values like
following for value
enum v4l2_whitebalance_presets {
V4L2_WHITEBALANCE_TUNGSTEN = 0,
V4L2_WHITEBALANCE_FLUORESCENT,
V4L2_WHITEBALANCE_SUNNY,
V4L2_WHITEBALANCE_CLOUDY,
(B). Define well known kelvin number in videodev2.h as preset name and
share with user space
Like following
#define V4L2_WHITEBALANCE_TUNGSTEN 3000
#define V4L2_WHITEBALANCE_FLUORESCENT 4000
#define V4L2_WHITEBALANCE_SUNNY 5500
#define V4L2_WHITEBALANCE_CLOUDY 6000
and use those defined values with V4L2_CID_WHITE_BALANCE_TEMPERATURE
urgh.
(C). Leave it alone. It's a pointless discussion. we are good with
existing WB API.
(really?)
I'm very surprised about this kind of needs were not issued yet.
I vote for (B). This is better than creating another user control for
something that were already defined. The drivers that don't support
specifying the color temperature, in Kelvin should round to the closest
supported value, and return the proper configured value when questioned.
I'm going with A. My reasoning is that presets 1) differ per device, 2) will
normally be better tested than a random temperature value.
I totally agree with you.
Remember that the control API is meant to export the options that the device
supports to the application. So the presets cannot be defined as macros but
must really come from the device driver. An application can then show the
available presets to the user.
I wonder if these two aren't mutually exclusive: you either can use any
value, or only use presets.
Don't worry about that. Generally, it is possible to use both of them
if they are supported by device. I mean, if device supports kelvin,
you can control WB with kelvin value. And if device is supports
presets, you can control WB with them also.
Difference between them should be a optimization in quality of WB
controlled Image. Because even though kelvin temperature is the key of
controlling white balance, there could be another factor to make a
batter white balance for some specific circumstances.
So, white balance presets are containing a optimized white balance
control from sensor manufacturer.
One thing should be taken carefully when we are
Re: [RFC] White Balance control for digital camera
On Wednesday 15 April 2009 08:10:58 Dongsoo, Nathaniel Kim wrote:
Hello Hans,
On Tue, Apr 14, 2009 at 11:50 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On Tuesday 14 April 2009 13:54:02 Mauro Carvalho Chehab wrote:
On Fri, 10 Apr 2009 06:50:32 +0900
Dongsoo, Nathaniel Kim dongsoo@gmail.com wrote:
Hello everyone,
I'm posting this RFC one more time because it seems to everyone has
been forgot this, and I'll be appreciated if any of you who is
reading this mailing list give me comment.
I'm adding some choices for you to make it easier. (even the option
for that this is a pointless discussion)
I've got a big question popping up handling white balance with
V4L2_CID_WHITE_BALANCE_TEMPERATURE CID.
Because in digital camera we generally control over user interface
with pre-defined white balance name. I mean, user controls white
balance with presets not with kelvin number.
I'm very certain that TEMPERATURE CID is needed in many of video
capture devices, but also 100% sure that white balance preset
control is also necessary for digital cameras.
How can we control white balance through preset name with existing
V4L2 API?
For now, I define preset names in user space with supported color
temperature preset in driver like following.
#define MANUAL_WB_TUNGSTEN 3000
#define MANUAL_WB_FLUORESCENT 4000
#define MANUAL_WB_SUNNY 5500
#define MANUAL_WB_CLOUDY 6000
and make driver to handle those presets like this. (I split in
several ranges to make driver pretend to be generic)
case V4L2_CID_WHITE_BALANCE_TEMPERATURE:
if (vc-value 3500) {
/* tungsten */
err = ce131f_cmds(c, ce131f_wb_tungsten);
} else if (vc-value 4100) {
/* fluorescent */
err = ce131f_cmds(c, ce131f_wb_fluorescent);
} else if (vc-value 6000) {
/* sunny */
err = ce131f_cmds(c, ce131f_wb_sunny);
} else if (vc-value 6500) {
/* cloudy */
err = ce131f_cmds(c, ce131f_wb_cloudy);
} else {
printk(KERN_INFO %s: unsupported kelvin
range\n, __func__);
}
..
I think this way seems to be ugly. Don't you think that another CID
is necessary to handle WB presets?
Because most of mobile camera modules can't make various color
temperatures in expecting kelvin number with user parameter.
So, here you are some options you can chose to give your opinion.(or
you can make your own opinion)
(A). Make a new CID to handle well known white balance presets
Like V4L2_CID_WHITE_BALANCE_PRESET for CID and enum values like
following for value
enum v4l2_whitebalance_presets {
V4L2_WHITEBALANCE_TUNGSTEN = 0,
V4L2_WHITEBALANCE_FLUORESCENT,
V4L2_WHITEBALANCE_SUNNY,
V4L2_WHITEBALANCE_CLOUDY,
(B). Define well known kelvin number in videodev2.h as preset name
and share with user space
Like following
#define V4L2_WHITEBALANCE_TUNGSTEN 3000
#define V4L2_WHITEBALANCE_FLUORESCENT 4000
#define V4L2_WHITEBALANCE_SUNNY 5500
#define V4L2_WHITEBALANCE_CLOUDY 6000
and use those defined values with V4L2_CID_WHITE_BALANCE_TEMPERATURE
urgh.
(C). Leave it alone. It's a pointless discussion. we are good with
existing WB API.
(really?)
I'm very surprised about this kind of needs were not issued yet.
I vote for (B). This is better than creating another user control for
something that were already defined. The drivers that don't support
specifying the color temperature, in Kelvin should round to the
closest supported value, and return the proper configured value when
questioned.
I'm going with A. My reasoning is that presets 1) differ per device, 2)
will normally be better tested than a random temperature value.
I totally agree with you.
Remember that the control API is meant to export the options that the
device supports to the application. So the presets cannot be defined as
macros but must really come from the device driver. An application can
then show the available presets to the user.
I wonder if these two aren't mutually exclusive: you either can use any
value, or only use presets.
Don't worry about that. Generally, it is possible to use both of them
if they are supported by device. I mean, if device supports kelvin,
you can control WB with kelvin value. And if device is supports
presets, you can control WB with them also.
Difference between them should be a optimization in quality of WB
controlled Image. Because even though kelvin temperature is the key of
controlling white balance, there could be another factor to make a
batter white
Re: [RFC] White Balance control for digital camera
Thank you Hans.
I'll see how to use V4L2_CTRL_FLAG_UPDATE and _INACTIVE.
Cheers,
Nate
On Wed, Apr 15, 2009 at 3:24 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On Wednesday 15 April 2009 08:10:58 Dongsoo, Nathaniel Kim wrote:
Hello Hans,
On Tue, Apr 14, 2009 at 11:50 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On Tuesday 14 April 2009 13:54:02 Mauro Carvalho Chehab wrote:
On Fri, 10 Apr 2009 06:50:32 +0900
Dongsoo, Nathaniel Kim dongsoo@gmail.com wrote:
Hello everyone,
I'm posting this RFC one more time because it seems to everyone has
been forgot this, and I'll be appreciated if any of you who is
reading this mailing list give me comment.
I'm adding some choices for you to make it easier. (even the option
for that this is a pointless discussion)
I've got a big question popping up handling white balance with
V4L2_CID_WHITE_BALANCE_TEMPERATURE CID.
Because in digital camera we generally control over user interface
with pre-defined white balance name. I mean, user controls white
balance with presets not with kelvin number.
I'm very certain that TEMPERATURE CID is needed in many of video
capture devices, but also 100% sure that white balance preset
control is also necessary for digital cameras.
How can we control white balance through preset name with existing
V4L2 API?
For now, I define preset names in user space with supported color
temperature preset in driver like following.
#define MANUAL_WB_TUNGSTEN 3000
#define MANUAL_WB_FLUORESCENT 4000
#define MANUAL_WB_SUNNY 5500
#define MANUAL_WB_CLOUDY 6000
and make driver to handle those presets like this. (I split in
several ranges to make driver pretend to be generic)
case V4L2_CID_WHITE_BALANCE_TEMPERATURE:
if (vc-value 3500) {
/* tungsten */
err = ce131f_cmds(c, ce131f_wb_tungsten);
} else if (vc-value 4100) {
/* fluorescent */
err = ce131f_cmds(c, ce131f_wb_fluorescent);
} else if (vc-value 6000) {
/* sunny */
err = ce131f_cmds(c, ce131f_wb_sunny);
} else if (vc-value 6500) {
/* cloudy */
err = ce131f_cmds(c, ce131f_wb_cloudy);
} else {
printk(KERN_INFO %s: unsupported kelvin
range\n, __func__);
}
..
I think this way seems to be ugly. Don't you think that another CID
is necessary to handle WB presets?
Because most of mobile camera modules can't make various color
temperatures in expecting kelvin number with user parameter.
So, here you are some options you can chose to give your opinion.(or
you can make your own opinion)
(A). Make a new CID to handle well known white balance presets
Like V4L2_CID_WHITE_BALANCE_PRESET for CID and enum values like
following for value
enum v4l2_whitebalance_presets {
V4L2_WHITEBALANCE_TUNGSTEN = 0,
V4L2_WHITEBALANCE_FLUORESCENT,
V4L2_WHITEBALANCE_SUNNY,
V4L2_WHITEBALANCE_CLOUDY,
(B). Define well known kelvin number in videodev2.h as preset name
and share with user space
Like following
#define V4L2_WHITEBALANCE_TUNGSTEN 3000
#define V4L2_WHITEBALANCE_FLUORESCENT 4000
#define V4L2_WHITEBALANCE_SUNNY 5500
#define V4L2_WHITEBALANCE_CLOUDY 6000
and use those defined values with V4L2_CID_WHITE_BALANCE_TEMPERATURE
urgh.
(C). Leave it alone. It's a pointless discussion. we are good with
existing WB API.
(really?)
I'm very surprised about this kind of needs were not issued yet.
I vote for (B). This is better than creating another user control for
something that were already defined. The drivers that don't support
specifying the color temperature, in Kelvin should round to the
closest supported value, and return the proper configured value when
questioned.
I'm going with A. My reasoning is that presets 1) differ per device, 2)
will normally be better tested than a random temperature value.
I totally agree with you.
Remember that the control API is meant to export the options that the
device supports to the application. So the presets cannot be defined as
macros but must really come from the device driver. An application can
then show the available presets to the user.
I wonder if these two aren't mutually exclusive: you either can use any
value, or only use presets.
Don't worry about that. Generally, it is possible to use both of them
if they are supported by device. I mean, if device supports kelvin,
you can control WB with kelvin value. And if device is supports
presets, you can control WB with them also.
Difference between them should be a optimization in quality of
[PATCH] uvc: Add Microsoft VX 500 webcam
Hello Laurent, Attached patch for the following: Added Microsoft VX 500 webcam to uvc driver. Signed-off-by: Douglas Schilling Landgraf dougsl...@redhat.com Thanks, Douglas uvc-microsoft-vx500.diff Description: Binary data
Re: [PATCH] uvc: Add Microsoft VX 500 webcam
Hi Douglas, On Wednesday 15 April 2009 09:03:45 Douglas Schilling Landgraf wrote: Hello Laurent, Attached patch for the following: Added Microsoft VX 500 webcam to uvc driver. Signed-off-by: Douglas Schilling Landgraf dougsl...@redhat.com Could you please send me the output of lsusb -v -d 045e:074a using usbutils 0.72 or newer (0.73+ preferred) ? Have you tried the latest driver ? The MINMAX quirk isn't required anymore for most cameras (although the two supported Microsoft webcams still need it, so I doubt it will work as-is). Best regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] technisat skystar usb 2.0
Dominik Sito wrote: Monday 13 April 2009 17:31:29 nizar napisał(a): Please help needed. I have skystar usb 2.0 (13d0:2282) i have also the log of usbsnoop (300 Mo) . What are steps to : 1- know if a firmware is needed. 2- if yes how to extract it. thank you Nizar ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux- me...@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Just give `lspci -vvv` and `lsusb -vvv` result. Regards. -- Thank you for reply. lspci -vvv lsusb -vvv in attachement. In lsusb i have this error with 13d0:2282 : cannot read device status, Broken pipe (32). 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 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Subsystem: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR+ INTx- Latency: 8 Region 0: Memory at f000 (32-bit, prefetchable) [size=128M] Capabilities: [80] AGP version 3.5 Status: RQ=8 Iso- ArqSz=0 Cal=2 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3+ Rate=x4,x8 Command: RQ=1 ArqSz=0 Cal=2 SBA+ AGP+ GART64- 64bit- FW- Rate=x8 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: agpgart-via Kernel modules: windrvr6, via-agp 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Kernel modules: windrvr6 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Kernel modules: windrvr6 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Kernel modules: windrvr6, via-agp 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Kernel modules: windrvr6 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Kernel modules: windrvr6 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: a000-afff Memory behind bridge: fb00-fcff Prefetchable memory behind bridge: e800-efff Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR+ PERR+ BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [70] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel modules: windrvr6, shpchp 00:07.0 Multimedia audio controller: ESS Technology ES1969 Solo-1 Audiodrive (rev 01) Subsystem: ESS Technology Solo-1 Audio Adapter Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+
Bug fix for drivers/media/dvb/dvb-usb/cxusb.c
Hi! I'm new to the list, mostly joining to report a bug (with fix)
for the DViCO dual digital card, using the XC3028 tuner.
I'm using suse kernels, which is currently 2.6.27.21. I downloaded
the 2.6.29.1 kernel, and the relevant pieces of code have not
changed. This driver worked fine in the 2.6.25.16 kernel.
Symptom: card detects carrier, but does not lock onto it.
Cause: the driver was NOT loading the SCODE for the card.
PATCH (against 2.6.29.1):
lind...@chesty:/working/build/linux-2.6.29.1/drivers/media/dvb/dvb-usb
diff -u cxusb.c FIXED-cxusb.c
--- cxusb.c 2009-04-03 07:55:27.0 +1100
+++ FIXED-cxusb.c 2009-04-15 21:01:15.0 +1000
@@ -34,6 +34,7 @@
#include mt352_priv.h
#include zl10353.h
#include tuner-xc2028.h
+#include tuner-xc2028-types.h
#include tuner-simple.h
#include mxl5005s.h
#include dib7000p.h
@@ -775,7 +776,7 @@
static struct xc2028_ctrl ctl = {
.fname = XC2028_DEFAULT_FIRMWARE,
.max_len = 64,
- .demod = XC3028_FE_ZARLINK456,
+ .scode_table = ZARLINK456,
};
/* FIXME: generalize move to common area */
Explanation: Setting the .demod element above results in
the int_freq parameter to load_scode()
(drivers/media/common/tuners/tuner-xc2028.c) being non-zero (value is
derived from the .demod line above). The first if() is false, and
it's all downhill from there.
The above patch puts things back to the state of the 2.6.25.16 kernel.
Tested on both IA32 and AMD 64 systems.
Thanks,
Lindsay
--
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 0/5] soc-camera: convert to platform device
This patch series is a preparation for the v4l2-subdev conversion. Please, review and test. My current patch-stack in the form of a (manually-created) quilt-series is at http://www.open-technology.de/download/20090415/ based on linux-next history branch, commit ID in -base file. Don't be surprised, that patch-set also contains a few not directly related patches. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] soc-camera: add a free_bus method to struct soc_camera_link
Currently pcm990 camera bus-width management functions request a GPIO and never
free it again. With this approach the GPIO extender driver cannot be unloaded
once camera drivers have been loaded, also unloading theb i2c-pxa bus driver
produces errors, because the GPIO extender driver cannot unregister properly.
Another problem is, that if camera drivers are once loaded before the GPIO
extender driver, the platform code marks the GPIO unavailable and only a reboot
helps to recover. Adding an explicit free_bus method and using it in mt9m001
and mt9v022 drivers fixes these problems.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Eric, need your ack for the arch/arm/mach-pxa part. Sascha's wouldn't hurt
either:-)
arch/arm/mach-pxa/pcm990-baseboard.c | 23 ---
drivers/media/video/mt9m001.c|3 +++
drivers/media/video/mt9v022.c|3 +++
include/media/soc_camera.h |1 +
4 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index 6c12b5a..9ce1ef2 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -380,12 +380,12 @@ static struct pca953x_platform_data pca9536_data = {
.gpio_base = NR_BUILTIN_GPIO,
};
-static int gpio_bus_switch;
+static int gpio_bus_switch = -EINVAL;
static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
- unsigned long flags)
+ unsigned long flags)
{
- if (gpio_bus_switch = 0) {
+ if (gpio_bus_switch 0) {
if (flags == SOCAM_DATAWIDTH_10)
return 0;
else
@@ -404,25 +404,34 @@ static unsigned long pcm990_camera_query_bus_param(struct
soc_camera_link *link)
{
int ret;
- if (!gpio_bus_switch) {
+ if (gpio_bus_switch 0) {
ret = gpio_request(NR_BUILTIN_GPIO, camera);
if (!ret) {
gpio_bus_switch = NR_BUILTIN_GPIO;
gpio_direction_output(gpio_bus_switch, 0);
- } else
- gpio_bus_switch = -EINVAL;
+ }
}
- if (gpio_bus_switch 0)
+ if (gpio_bus_switch = 0)
return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
else
return SOCAM_DATAWIDTH_10;
}
+static void pcm990_camera_free_bus(struct soc_camera_link *link)
+{
+ if (gpio_bus_switch 0)
+ return;
+
+ gpio_free(gpio_bus_switch);
+ gpio_bus_switch = -EINVAL;
+}
+
static struct soc_camera_link iclink = {
.bus_id = 0, /* Must match with the camera ID above */
.query_bus_param = pcm990_camera_query_bus_param,
.set_bus_param = pcm990_camera_set_bus_param,
+ .free_bus = pcm990_camera_free_bus,
};
/* Board I2C devices. */
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index 684f62f..3838ff7 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -604,10 +604,13 @@ ei2c:
static void mt9m001_video_remove(struct soc_camera_device *icd)
{
struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd);
+ struct soc_camera_link *icl = mt9m001-client-dev.platform_data;
dev_dbg(icd-dev, Video %x removed: %p, %p\n, mt9m001-client-addr,
icd-dev.parent, icd-vdev);
soc_camera_video_stop(icd);
+ if (icl-free_bus)
+ icl-free_bus(icl);
}
static int mt9m001_probe(struct i2c_client *client,
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index 4d3b481..412b399 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -735,10 +735,13 @@ ei2c:
static void mt9v022_video_remove(struct soc_camera_device *icd)
{
struct mt9v022 *mt9v022 = container_of(icd, struct mt9v022, icd);
+ struct soc_camera_link *icl = mt9v022-client-dev.platform_data;
dev_dbg(icd-dev, Video %x removed: %p, %p\n, mt9v022-client-addr,
icd-dev.parent, icd-vdev);
soc_camera_video_stop(icd);
+ if (icl-free_bus)
+ icl-free_bus(icl);
}
static int mt9v022_probe(struct i2c_client *client,
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 3701368..396c325 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -107,6 +107,7 @@ struct soc_camera_link {
*/
int (*set_bus_param)(struct soc_camera_link *, unsigned long flags);
unsigned long (*query_bus_param)(struct soc_camera_link *);
+ void (*free_bus)(struct soc_camera_link *);
};
static inline struct soc_camera_device *to_soc_camera_dev(struct device *dev)
--
1.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH 2/5] soc-camera: host-driver cleanup
Embed struct soc_camera_host in platform-specific per host instance objects
instead of allocating them statically in drivers, use platform_[gs]et_drvdata
consistently, use resource_size().
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mx1_camera.c | 21 ---
drivers/media/video/mx3_camera.c |2 +-
drivers/media/video/pxa_camera.c | 29 ---
drivers/media/video/sh_mobile_ceu_camera.c |6 ++--
4 files changed, 26 insertions(+), 32 deletions(-)
diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c
index 86fab56..48dd984 100644
--- a/drivers/media/video/mx1_camera.c
+++ b/drivers/media/video/mx1_camera.c
@@ -102,6 +102,7 @@ struct mx1_buffer {
* Interface. If anyone ever builds hardware to enable more than
* one camera, they will have to modify this driver too */
struct mx1_camera_dev {
+ struct soc_camera_host soc_host;
struct soc_camera_device*icd;
struct mx1_camera_pdata *pdata;
struct mx1_buffer *active;
@@ -633,12 +634,6 @@ static struct soc_camera_host_ops mx1_soc_camera_host_ops
= {
.querycap = mx1_camera_querycap,
};
-/* Should be allocated dynamically too, but we have only one. */
-static struct soc_camera_host mx1_soc_camera_host = {
- .drv_name = DRIVER_NAME,
- .ops= mx1_soc_camera_host_ops,
-};
-
static struct fiq_handler fh = {
.name = csi_sof
};
@@ -673,7 +668,7 @@ static int __init mx1_camera_probe(struct platform_device
*pdev)
goto exit_put_clk;
}
- dev_set_drvdata(pdev-dev, pcdev);
+ platform_set_drvdata(pdev, pcdev);
pcdev-res = res;
pcdev-clk = clk;
@@ -746,10 +741,12 @@ static int __init mx1_camera_probe(struct platform_device
*pdev)
mxc_set_irq_fiq(irq, 1);
enable_fiq(irq);
- mx1_soc_camera_host.priv= pcdev;
- mx1_soc_camera_host.dev.parent = pdev-dev;
- mx1_soc_camera_host.nr = pdev-id;
- err = soc_camera_host_register(mx1_soc_camera_host);
+ pcdev-soc_host.drv_name= DRIVER_NAME;
+ pcdev-soc_host.ops = mx1_soc_camera_host_ops;
+ pcdev-soc_host.priv= pcdev;
+ pcdev-soc_host.dev.parent = pdev-dev;
+ pcdev-soc_host.nr = pdev-id;
+ err = soc_camera_host_register(pcdev-soc_host);
if (err)
goto exit_free_irq;
@@ -787,7 +784,7 @@ static int __exit mx1_camera_remove(struct platform_device
*pdev)
clk_put(pcdev-clk);
- soc_camera_host_unregister(mx1_soc_camera_host);
+ soc_camera_host_unregister(pcdev-soc_host);
iounmap(pcdev-base);
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index c462b81..22c58dc 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -1106,7 +1106,7 @@ static int mx3_camera_probe(struct platform_device *pdev)
goto eclkget;
}
- dev_set_drvdata(pdev-dev, mx3_cam);
+ platform_set_drvdata(pdev, mx3_cam);
mx3_cam-pdata = pdev-dev.platform_data;
mx3_cam-platform_flags = mx3_cam-pdata-flags;
diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index c639845..ad0d58c 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -202,6 +202,7 @@ struct pxa_buffer {
};
struct pxa_camera_dev {
+ struct soc_camera_host soc_host;
struct device *dev;
/* PXA27x is only supposed to handle one camera on its Quick Capture
* interface. If anyone ever builds hardware to enable more than
@@ -1552,12 +1553,6 @@ static struct soc_camera_host_ops
pxa_soc_camera_host_ops = {
.set_bus_param = pxa_camera_set_bus_param,
};
-/* Should be allocated dynamically too, but we have only one. */
-static struct soc_camera_host pxa_soc_camera_host = {
- .drv_name = PXA_CAM_DRV_NAME,
- .ops= pxa_soc_camera_host_ops,
-};
-
static int pxa_camera_probe(struct platform_device *pdev)
{
struct pxa_camera_dev *pcdev;
@@ -1586,7 +1581,7 @@ static int pxa_camera_probe(struct platform_device *pdev)
goto exit_kfree;
}
- dev_set_drvdata(pdev-dev, pcdev);
+ platform_set_drvdata(pdev, pcdev);
pcdev-res = res;
pcdev-pdata = pdev-dev.platform_data;
@@ -1616,13 +1611,13 @@ static int pxa_camera_probe(struct platform_device
*pdev)
/*
* Request the regions.
*/
- if (!request_mem_region(res-start, res-end - res-start + 1,
+ if (!request_mem_region(res-start, resource_size(res),
PXA_CAM_DRV_NAME)) {
err = -EBUSY;
goto exit_clk;
}
-
[PATCH 3/5] soc-camera: remove an extra device generation from struct soc_camera_host
Make camera devices direct children of host platform devices, move the
inheritance management into the soc_camera.c core driver.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mx1_camera.c | 35 +-
drivers/media/video/mx3_camera.c | 40 ++--
drivers/media/video/pxa_camera.c | 97 ++--
drivers/media/video/sh_mobile_ceu_camera.c | 21 +++---
drivers/media/video/soc_camera.c | 35 +++---
include/media/soc_camera.h |4 +-
6 files changed, 107 insertions(+), 125 deletions(-)
diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c
index 48dd984..2d07520 100644
--- a/drivers/media/video/mx1_camera.c
+++ b/drivers/media/video/mx1_camera.c
@@ -106,7 +106,6 @@ struct mx1_camera_dev {
struct soc_camera_device*icd;
struct mx1_camera_pdata *pdata;
struct mx1_buffer *active;
- struct device *dev;
struct resource *res;
struct clk *clk;
struct list_headcapture;
@@ -220,7 +219,7 @@ static int mx1_camera_setup_dma(struct mx1_camera_dev
*pcdev)
int ret;
if (unlikely(!pcdev-active)) {
- dev_err(pcdev-dev, DMA End IRQ with no active buffer\n);
+ dev_err(pcdev-soc_host.dev, DMA End IRQ with no active
buffer\n);
return -EFAULT;
}
@@ -230,7 +229,7 @@ static int mx1_camera_setup_dma(struct mx1_camera_dev
*pcdev)
vbuf-size, pcdev-res-start +
CSIRXR, DMA_MODE_READ);
if (unlikely(ret))
- dev_err(pcdev-dev, Failed to setup DMA sg list\n);
+ dev_err(pcdev-soc_host.dev, Failed to setup DMA sg list\n);
return ret;
}
@@ -339,14 +338,14 @@ static void mx1_camera_dma_irq(int channel, void *data)
imx_dma_disable(channel);
if (unlikely(!pcdev-active)) {
- dev_err(pcdev-dev, DMA End IRQ with no active buffer\n);
+ dev_err(pcdev-soc_host.dev, DMA End IRQ with no active
buffer\n);
goto out;
}
vb = pcdev-active-vb;
buf = container_of(vb, struct mx1_buffer, vb);
WARN_ON(buf-inwork || list_empty(vb-queue));
- dev_dbg(pcdev-dev, %s (vb=0x%p) 0x%08lx %d\n, __func__,
+ dev_dbg(pcdev-soc_host.dev, %s (vb=0x%p) 0x%08lx %d\n, __func__,
vb, vb-baddr, vb-bsize);
mx1_camera_wakeup(pcdev, vb, buf);
@@ -367,7 +366,7 @@ static void mx1_camera_init_videobuf(struct videobuf_queue
*q,
struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
struct mx1_camera_dev *pcdev = ici-priv;
- videobuf_queue_dma_contig_init(q, mx1_videobuf_ops, pcdev-dev,
+ videobuf_queue_dma_contig_init(q, mx1_videobuf_ops, ici-dev,
pcdev-lock,
V4L2_BUF_TYPE_VIDEO_CAPTURE,
V4L2_FIELD_NONE,
@@ -386,7 +385,7 @@ static int mclk_get_divisor(struct mx1_camera_dev *pcdev)
* they get a nice Oops */
div = (lcdclk + 2 * mclk - 1) / (2 * mclk) - 1;
- dev_dbg(pcdev-dev, System clock %lukHz, target freq %dkHz,
+ dev_dbg(pcdev-soc_host.dev, System clock %lukHz, target freq %dkHz,
divisor %lu\n, lcdclk / 1000, mclk / 1000, div);
return div;
@@ -396,7 +395,7 @@ static void mx1_camera_activate(struct mx1_camera_dev
*pcdev)
{
unsigned int csicr1 = CSICR1_EN;
- dev_dbg(pcdev-dev, Activate device\n);
+ dev_dbg(pcdev-soc_host.dev, Activate device\n);
clk_enable(pcdev-clk);
@@ -412,7 +411,7 @@ static void mx1_camera_activate(struct mx1_camera_dev
*pcdev)
static void mx1_camera_deactivate(struct mx1_camera_dev *pcdev)
{
- dev_dbg(pcdev-dev, Deactivate device\n);
+ dev_dbg(pcdev-soc_host.dev, Deactivate device\n);
/* Disable all CSI interface */
__raw_writel(0x00, pcdev-base + CSICR1);
@@ -551,7 +550,7 @@ static int mx1_camera_set_fmt(struct soc_camera_device *icd,
xlate = soc_camera_xlate_by_fourcc(icd, pix-pixelformat);
if (!xlate) {
- dev_warn(ici-dev, Format %x not found\n, pix-pixelformat);
+ dev_warn(ici-dev, Format %x not found\n, pix-pixelformat);
return -EINVAL;
}
@@ -668,7 +667,6 @@ static int __init mx1_camera_probe(struct platform_device
*pdev)
goto exit_put_clk;
}
- platform_set_drvdata(pdev, pcdev);
pcdev-res = res;
pcdev-clk = clk;
@@ -702,16 +700,15 @@ static int __init mx1_camera_probe(struct platform_device
*pdev)
}
pcdev-irq = irq;
pcdev-base = base;
- pcdev-dev = pdev-dev;
/* request dma */
pcdev-dma_chan =
[PATCH 4/5] soc-camera: simplify register access routines in multiple sensor drivers
Register access routines only need the I2C client, not the soc-camera device
context.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9m001.c | 105 +---
drivers/media/video/mt9m111.c | 73 --
drivers/media/video/mt9t031.c | 135 +---
drivers/media/video/mt9v022.c | 135 +
4 files changed, 236 insertions(+), 212 deletions(-)
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index 3838ff7..459c04c 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -75,53 +75,50 @@ struct mt9m001 {
unsigned char autoexposure;
};
-static int reg_read(struct soc_camera_device *icd, const u8 reg)
+static int reg_read(struct i2c_client *client, const u8 reg)
{
- struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd);
- struct i2c_client *client = mt9m001-client;
s32 data = i2c_smbus_read_word_data(client, reg);
return data 0 ? data : swab16(data);
}
-static int reg_write(struct soc_camera_device *icd, const u8 reg,
+static int reg_write(struct i2c_client *client, const u8 reg,
const u16 data)
{
- struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd);
- return i2c_smbus_write_word_data(mt9m001-client, reg, swab16(data));
+ return i2c_smbus_write_word_data(client, reg, swab16(data));
}
-static int reg_set(struct soc_camera_device *icd, const u8 reg,
+static int reg_set(struct i2c_client *client, const u8 reg,
const u16 data)
{
int ret;
- ret = reg_read(icd, reg);
+ ret = reg_read(client, reg);
if (ret 0)
return ret;
- return reg_write(icd, reg, ret | data);
+ return reg_write(client, reg, ret | data);
}
-static int reg_clear(struct soc_camera_device *icd, const u8 reg,
+static int reg_clear(struct i2c_client *client, const u8 reg,
const u16 data)
{
int ret;
- ret = reg_read(icd, reg);
+ ret = reg_read(client, reg);
if (ret 0)
return ret;
- return reg_write(icd, reg, ret ~data);
+ return reg_write(client, reg, ret ~data);
}
static int mt9m001_init(struct soc_camera_device *icd)
{
- struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd);
- struct soc_camera_link *icl = mt9m001-client-dev.platform_data;
+ struct i2c_client *client = to_i2c_client(icd-control);
+ struct soc_camera_link *icl = client-dev.platform_data;
int ret;
dev_dbg(icd-vdev-parent, %s\n, __func__);
if (icl-power) {
- ret = icl-power(mt9m001-client-dev, 1);
+ ret = icl-power(client-dev, 1);
if (ret 0) {
dev_err(icd-vdev-parent,
Platform failed to power-on the camera.\n);
@@ -131,49 +128,53 @@ static int mt9m001_init(struct soc_camera_device *icd)
/* The camera could have been already on, we reset it additionally */
if (icl-reset)
- ret = icl-reset(mt9m001-client-dev);
+ ret = icl-reset(client-dev);
else
ret = -ENODEV;
if (ret 0) {
/* Either no platform reset, or platform reset failed */
- ret = reg_write(icd, MT9M001_RESET, 1);
+ ret = reg_write(client, MT9M001_RESET, 1);
if (!ret)
- ret = reg_write(icd, MT9M001_RESET, 0);
+ ret = reg_write(client, MT9M001_RESET, 0);
}
/* Disable chip, synchronous option update */
if (!ret)
- ret = reg_write(icd, MT9M001_OUTPUT_CONTROL, 0);
+ ret = reg_write(client, MT9M001_OUTPUT_CONTROL, 0);
return ret;
}
static int mt9m001_release(struct soc_camera_device *icd)
{
- struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd);
- struct soc_camera_link *icl = mt9m001-client-dev.platform_data;
+ struct i2c_client *client = to_i2c_client(icd-control);
+ struct soc_camera_link *icl = client-dev.platform_data;
/* Disable the chip */
- reg_write(icd, MT9M001_OUTPUT_CONTROL, 0);
+ reg_write(client, MT9M001_OUTPUT_CONTROL, 0);
if (icl-power)
- icl-power(mt9m001-client-dev, 0);
+ icl-power(client-dev, 0);
return 0;
}
static int mt9m001_start_capture(struct soc_camera_device *icd)
{
+ struct i2c_client *client = to_i2c_client(icd-control);
+
/* Switch to master normal mode */
- if (reg_write(icd, MT9M001_OUTPUT_CONTROL, 2) 0)
+ if (reg_write(client, MT9M001_OUTPUT_CONTROL, 2) 0)
return -EIO;
return 0;
}
static int mt9m001_stop_capture(struct soc_camera_device *icd)
{
+ struct
RE: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, April 06, 2009 8:27 PM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R;
Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
Hi Hans,
Please find my comments inline. Most of the comments are taken care of.
2. In DSS rotation is accomplished by some memory algorithm but its quite
costly so -1 is essentially same as 0 degree but with out the overhead.
But if mirroring is on then we have to do the 0 degree rotation with
overhead using some memory techniques. So from user point of view he will
only be setting 0 but internally driver will take it as -1 or 0 depending
upon the mirroring selected.
Hi Hardik,
I just looked over these comments and I'll do a full review in the weekend
when I'm back from San Francisco. But just one quick remark regarding this
magic -1 number: wouldn't it be better to write a small inline function
like this:
/* return true if we need to rotate or mirror, return false if we
don't have to do anything here. */
static inline int needs_rotate(struct foo *foo)
{
return foo-rotate != 0 || foo-mirror;
}
I think this is much more understandable. It's up to you, though.
Regards,
[Shah, Hardik] Hi All,
Any comment on this series of patches will be appreciated.
Hans,
Did you get a chance to look at it?
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: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, April 06, 2009 8:27 PM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav,
Brijesh R;
Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS.
Hi Hans,
Please find my comments inline. Most of the comments are taken care
of.
2. In DSS rotation is accomplished by some memory algorithm but its
quite
costly so -1 is essentially same as 0 degree but with out the
overhead.
But if mirroring is on then we have to do the 0 degree rotation with
overhead using some memory techniques. So from user point of view he
will
only be setting 0 but internally driver will take it as -1 or 0
depending
upon the mirroring selected.
Hi Hardik,
I just looked over these comments and I'll do a full review in the
weekend
when I'm back from San Francisco. But just one quick remark regarding
this
magic -1 number: wouldn't it be better to write a small inline function
like this:
/* return true if we need to rotate or mirror, return false if we
don't have to do anything here. */
static inline int needs_rotate(struct foo *foo)
{
return foo-rotate != 0 || foo-mirror;
}
I think this is much more understandable. It's up to you, though.
Regards,
[Shah, Hardik] Hi All,
Any comment on this series of patches will be appreciated.
Hans,
Did you get a chance to look at it?
No, but I hope to go through it this weekend.
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: [PATCH] uvc: Add Microsoft VX 500 webcam
Hello Laurent,
On Wed, 15 Apr 2009 11:46:52 +0200
Laurent Pinchart laurent.pinch...@skynet.be wrote:
Hi Douglas,
On Wednesday 15 April 2009 09:03:45 Douglas Schilling Landgraf wrote:
Hello Laurent,
Attached patch for the following:
Added Microsoft VX 500 webcam to uvc driver.
Signed-off-by: Douglas Schilling Landgraf dougsl...@redhat.com
Could you please send me the output of
lsusb -v -d 045e:074a
using usbutils 0.72 or newer (0.73+ preferred) ?
usbutils-0.73-2
Have you tried the latest driver ?
Yes
The MINMAX quirk isn't required
anymore for most cameras (although the two supported Microsoft
webcams still need it, so I doubt it will work as-is).
Indeed, attached new patch.
Thanks,
Douglas
Bus 002 Device 015: ID 045e:074a Microsoft Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x045e Microsoft Corp.
idProduct 0x074a
bcdDevice1.01
iManufacturer 2 Microsoft
iProduct1 Microsoft LifeCam
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 569
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 150mA
Interface Association:
bLength 8
bDescriptorType11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 1 Microsoft LifeCam
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 1 Microsoft LifeCam
VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 103
dwClockFrequency 15.00MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 5
iTerminal 0
VideoControl Interface Descriptor:
bLength26
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {7033f028-1163-2e4a-ba2c-6890eb334016}
bNumControl 8
bNrPins 1
baSourceID( 0) 3
bControlSize1
bmControls( 0) 0x0f
iExtension 0
VideoControl Interface Descriptor:
bLength26
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 5
guidExtensionCode {3fae1228-d7bc-114e-a357-6f1edef7d61d}
bNumControl 8
bNrPins 1
baSourceID( 0) 4
bControlSize1
bmControls( 0) 0x00
iExtension 0
VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength0
bControlSize 3
bmControls 0x
VideoControl Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 1
wMaxMultiplier 0
bControlSize2
bmControls 0x053f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
Backlight Compensation
Power Line Frequency
iProcessing 0
[PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jean-Francois, Please pull http://linuxtv.org/hg/~eandren/v4l-dvb/ for updates to be added to the next major kernel release. Regards, Erik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknmCVwACgkQN7qBt+4UG0G6YwCeMr2vKhnp62Ikl3+2WdiGINk5 wQAAnRpZYRoBV5ondz1nrN+bxW3Eswz6 =46QI -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Apr 15 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11516:6ce311bdeee0 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-rc1-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-rc1-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: OK linux-2.6.30-rc1-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc1-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29.1-mips: OK linux-2.6.30-rc1-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: OK linux-2.6.30-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-rc1-x86_64: WARNINGS fw/apps: OK sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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 4/5] soc-camera: simplify register access routines in multiple sensor drivers
Guennadi Liakhovetski g.liakhovet...@gmx.de writes: Register access routines only need the I2C client, not the soc-camera device context. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de For mt9m111.c : Acked-by: Robert Jarzmik robert.jarz...@free.fr Cheers. -- Robert -- 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 0/5] soc-camera: convert to platform device
Guennadi Liakhovetski g.liakhovet...@gmx.de writes: This patch series is a preparation for the v4l2-subdev conversion. Please, review and test. My current patch-stack in the form of a (manually-created) quilt-series is at http://www.open-technology.de/download/20090415/ based on linux-next history branch, commit ID in -base file. Don't be surprised, that patch-set also contains a few not directly related patches. Right, apart from a few comments, the bright side is your serie resists my full test campaign. I need to make some additionnal tests with I2C loading/unloading, but otherwise it works perfectly for (soc_camera / pxa_camera /mt9m111 combination). Cheers. -- Robert -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
Guennadi Liakhovetski g.liakhovet...@gmx.de writes:
Convert soc-camera core to a platform driver. With this approach I2C
devices are no longer statically registered in platform code, instead they
are registered dynamically by the soc-camera core, when a match with a
host driver is found. With this patch all platforms and all soc-camera
device drivers are converted too. This is a preparatory step for the
v4l-subdev conversion.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Ok, here goes the bad guy. Hit it hard, hit it as hard as you can.
Robert, I addressed your wishes from your previous comments, but kept the
semicolon rearrangement hunk. I think, it is better not to terminate a
define with a semicolon, if you like, we can make this a separate patch.
Yep, I'd like to. That's because of merge conflict with current patches through
arm tree. It will be easier for Eric or me to handle that other patch conflict,
thus letting the true v4l patch through.
@@ -754,20 +756,21 @@ static struct platform_device var = {
\
.platform_data = pdata, \
.parent = tparent, \
}, \
-};
+}
#define MIO_SIMPLE_DEV(var, strname, pdata) \
MIO_PARENT_DEV(var, strname, NULL, pdata)
-MIO_SIMPLE_DEV(mioa701_gpio_keys, gpio-keys,
mioa701_gpio_keys_data)
+MIO_SIMPLE_DEV(mioa701_gpio_keys, gpio-keys,
mioa701_gpio_keys_data);
MIO_PARENT_DEV(mioa701_backlight, pwm-backlight, pxa27x_device_pwm0.dev,
mioa701_backlight_data);
-MIO_SIMPLE_DEV(mioa701_led,leds-gpio, gpio_led_info)
-MIO_SIMPLE_DEV(pxa2xx_pcm, pxa2xx-pcm, NULL)
-MIO_SIMPLE_DEV(pxa2xx_ac97,pxa2xx-ac97,NULL)
-MIO_PARENT_DEV(mio_wm9713_codec, wm9713-codec, pxa2xx_ac97.dev, NULL)
-MIO_SIMPLE_DEV(mioa701_sound, mioa701-wm9713, NULL)
-MIO_SIMPLE_DEV(mioa701_board, mioa701-board, NULL)
+MIO_SIMPLE_DEV(mioa701_led,leds-gpio, gpio_led_info);
+MIO_SIMPLE_DEV(pxa2xx_pcm, pxa2xx-pcm, NULL);
+MIO_SIMPLE_DEV(pxa2xx_ac97,pxa2xx-ac97,NULL);
+MIO_PARENT_DEV(mio_wm9713_codec, wm9713-codec, pxa2xx_ac97.dev, NULL);
+MIO_SIMPLE_DEV(mioa701_sound, mioa701-wm9713, NULL);
+MIO_SIMPLE_DEV(mioa701_board, mioa701-board, NULL);
MIO_SIMPLE_DEV(gpio_vbus, gpio-vbus, gpio_vbus_data);
+MIO_SIMPLE_DEV(mioa701_camera, soc-camera-pdrv,iclink[0]);
\
- still broken
(should be iclink)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
@@ -917,6 +921,11 @@ static int mt9m111_video_probe(struct soc_camera_device
*icd)
to_soc_camera_host(icd-dev.parent)-nr != icd-iface)
return -ENODEV;
+ /* Switch master clock on */
+ ret = soc_camera_video_start(icd, client-dev);
+ if (ret)
+ return ret;
+
Well, I'd wish to keep only out return point where return value is given back
by another function (ie. have goto evid).
The reason behind is when debuggin, it's easier to put one printk(%d, ret),
and see what happened.
As the legacy mt9m111 style is :
- either return immediate value
- or if single occurence return func(foo)
- or error path with gotos
I'd like that return ret to be transformed into goto evid or the like.
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
@@ -794,103 +791,70 @@ static void scan_add_host(struct soc_camera_host *ici)
list_for_each_entry(icd, devices, list) {
if (icd-iface == ici-nr) {
+ int ret;
icd-dev.parent = ici-dev;
- device_register_link(icd);
- }
- }
-
- mutex_unlock(list_lock);
-}
-
-/* return: 0 if no match found or a match found and
- * device_register() successful, error code otherwise */
-static int scan_add_device(struct soc_camera_device *icd)
-{
- struct soc_camera_host *ici;
- int ret = 0;
-
- mutex_lock(list_lock);
-
- list_add_tail(icd-list, devices);
-
- /* Watch out for class_for_each_device / class_find_device API by
- * Dave Young hidave.darks...@gmail.com */
- list_for_each_entry(ici, hosts, list) {
- if (icd-iface == ici-nr) {
- ret = 1;
- icd-dev.parent = ici-dev;
- break;
+ dev_set_name(icd-dev, %u-%u, icd-iface,
+ icd-devnum);
+ ret = device_register(icd-dev);
+ if (ret 0) {
+ icd-dev.parent = NULL;
+ dev_err(icd-dev,
+
Re: Kernel 2.6.29 breaks DVB-T ASUSTeK Tiger LNA Hybrid Capture Device
Hi, just a short update. Am Dienstag, den 14.04.2009, 23:33 +0200 schrieb hermann pitton: Hi, Am Dienstag, den 14.04.2009, 17:30 +0800 schrieb David Wong: On Tue, Apr 14, 2009 at 11:23 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: On Sun, 05 Apr 2009 20:22:33 +0200 hermann pitton hermann-pit...@arcor.de wrote: Hi, Am Samstag, den 04.04.2009, 17:20 +0200 schrieb Ra.M.: hermann pitton ha scritto: Am Samstag, den 04.04.2009, 02:45 +0200 schrieb hermann pitton: Hi Ralph, Am Freitag, den 03.04.2009, 20:49 + schrieb Ralph: ASUSTeK Tiger LNA Hybrid Capture Device PCI - Analog/DVB-T card Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1) Works perfectly with kernel 2.6.28.4 (or older). Recently, I have switched to 2.6.29 (same .config as 2.6.28.4) and now, at boot time, I get the message: IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs Signal strength is very low and Kaffeine is unable to tune in any channel. Same problem with kernel 2.6.29.1 - Messages from /var/log/dmesg saa7134 :03:0a.0: PCI INT A - Link[APC3] - GSI 18 (level, low) - \ IRQ 18 saa7133[0]: found at :03:0a.0, rev: 209, irq: 18, latency: 32, mmio: \ 0xfdefe000 saa7133[0]: subsystem: 1043:4871, board: ASUS P7131 4871 \ [card=111,autodetected] saa7133[0]: board init: gpio is 0 IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]: i2c eeprom 00: 43 10 71 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 02 03 00 01 03 08 ff 00 cf ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 22 15 50 ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner' 2-004b: chip found @ 0x96 (saa7133[0]) tda829x 2-004b: setting tuner address to 61 tda829x 2-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[0]) DVB: registering adapter 0 frontend -32769 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: timeout waiting for DSP ready tda1004x: found firmware revision 0 -- invalid tda1004x: trying to boot from eeprom tda1004x: timeout waiting for DSP ready tda1004x: found firmware revision 0 -- invalid tda1004x: waiting for firmware upload... saa7134 :03:0a.0: firmware: requesting dvb-fe-tda10046.fw tda1004x: found firmware revision 29 -- ok saa7134 ALSA driver for DMA sound loaded IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]/alsa: saa7133[0] at 0xfdefe000 irq 18 registered as card -1 thanks for your report, as announced previously, I unfortunately did not have time to run with latest always ... (guess why ...) The driver always worked with shared IRQs, if not, it was always a limitation of certain hardware or mostly in some combination with binary only drivers. If the above should be the case in general now, and not only caused by some blacklist, no print out in that direction, the driver is pretty broken again. The problem seems to be limited to only some cards. I for sure don't have all for last months, but that IRQF_DISABLED is not guaranteed on shared IRQs for sure does not come from us here. Do use something unusual like pollirq or something? We only have in saa7134-core.c /* initialize hardware #1 */
[PULL] http://linuxtv.org/hg/~awalls/cx18-perf
Mauro, Please pull from: http://linuxtv.org/hg/~awalls/cx18-perf for the following: cx18: Increment version due to significant buffer handling changes cx18: Simplify the work handler for outgoing mailbox commands cx18: Convert per stream mutex locks to per queue spin locks cx18: Set up to wait for a one-shot response before sending a firmware cmd cx18: Add a work queue for deferring empty buffer handoffs to the firmware cx18: Rename the work queue to in_work_queue These are a series of patches to improve latency of incoming capture buffer handling from the time of firmware notification of DMA done, to the applications reading the data, by removing all possible sleeps in that processing. The sleeps, that can happen when trying to send empty buffers back to the firmware, now happen in an out_work_handler set of workqueue threads. Regards, Andy diffstat cx18-driver.c | 117 +++- cx18-driver.h | 17 +--- cx18-dvb.c |1 cx18-mailbox.c | 118 ++--- cx18-mailbox.h |4 - cx18-queue.c | 83 cx18-streams.c | 46 ++ cx18-streams.h | 24 ++- cx18-version.h |2 9 files changed, 278 insertions(+), 134 deletions(-) -- 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
Some questions about mr97310 controls (continuing previous thread on mr97310a.c)
Thomas, A few questions in the text below. On Thu, 5 Mar 2009, Thomas Kaiser wrote: Hello Theodore kilg...@banach.math.auburn.edu wrote: On Wed, 4 Mar 2009, Thomas Kaiser wrote: As to the actual contents of the header, as you describe things, 0. Do you have any idea how to account for the discrepancy between From usb snoop. FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 and In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 (I am referring to the 00 00 as opposed to F0 00)? Or could this have happened somehow just because these were not two identical sessions? In case I did not answer this one, I suspect it was probably different sessions. I can think of no other explanation which makes sense to me. Doesn't remember what the differences was. The first is from Windoz (usbsnoop) and the second is from Linux. 1. xx: don't know but value is changing between 0x00 to 0x07 as I said, this signifies the image format, qua compression algorithm in use, or if 00 then no compression. On the PAC207, the compression can be controlled with a register called Compression Balance size. So, I guess, depending on the value set in the register this value in the header will show what compression level is set. One of my questions: Just how does it work to set the Compression Balance size? Is this some kind of special command sequence? Are we able to set this to whatever we want? 2. xx: this is the actual pixel clock So there is a control setting for this? Yes, in the PAC207, register 2. (12 MHz divided by the value set). 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (center) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (edge) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Varying some old questions: Precisely what is meant by the value of Digital Gain for XX where XX is one of Red, Green, or Blue? On what scale is this measured? Is is some kind of standardized scale? Or is it something which is camera-specific? Also what is does set mean in this context? This last in view of the fact that this is data which the camera provides for our presumed information, not something which we are sending to the camera? Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] DVB-T USB dib0700 device recomendations?
Hi Heinrich,
Am Mittwoch, den 15.04.2009, 12:06 +0200 schrieb Heinrich Langos:
Hi Lars,
On Tue, Apr 14, 2009 at 05:49:14PM +0200, Lars Buerding wrote:
Hello Hendrik,
out in the street and buying the first dib0700 device I'd like to know
if
there are any devices that are
- especially good (sensitive reception, fast switch time, sensible tuner
data (usable for comparing different antennas) and so on)
or
- especially bad (invers of the above plus hardware bugs, annoyances and
so
on..)
I bought this model a while ago:
{ Hauppauge Nova-TD Stick/Elgato Eye-TV Diversity,
This is the Nova-TD equipped with one standard and one small RF Connector
(Adapter Small - Standard is included). There is another model with two
small RF-Connectors, I dont know anything about this one.
positive:
- standard Hauppauge remote-control (until now, I did not find a better
one for my VDR)
Did you take a look at the Terratec remotes? They look quite good to me,too
with color buttons and so on.. It looks a little cheaper than the
HAuppauge's remote but hopefully that's just due to the choice of colors..
Even the XXS seems to come with the full 48 buttons remote.
http://www.terratec.net/en/products/pictures/produkt_bilder_en_9706.html
- 2 seperate tuners
negative:
- I have massive problems receiving weak signals. If you dont live directly
beneath the radio tower, just dont buy it. For me, this is the main reason
why I just cant use it at home.
I do live close to the radio tower but some receivers have problem with some
channels when using a stick antenna. Thats why I switched to a cheapo do it
yourself double quad. Here's the link to the instructions in German:
http://www.cnet.de/praxis/wochenend/41001557/die+beste+eigenbau_dvb_t_antenne+doppelquad+fuer+5+euro+basteln.htm
I really like that kind of input.
Especially for the follow up version, with dedicated antennas for each
transponder frequency.
I do confirm, that it has the potential to replace two amplifiers, one
external and one on the card under bad reception conditions, not to talk
about the antenna itself and about what all that might cost else
installed by an expert on light-speed coming into your home ...
And here's the google translation:
http://translate.google.com/translate?hl=ensl=deu=http://www.cnet.de/praxis/wochenend/41001557/die%2Bbeste%2Beigenbau_dvb_t_antenne%2Bdoppelquad%2Bfuer%2B5%2Beuro%2Bbasteln.htmei=mKLlScbqIMGPsAam-KWtCwsa=Xoi=translateresnum=1ct=resultprev=/search%3Fq%3Dhttp://www.cnet.de/praxis/wochenend/41001557/die%252Bbeste%252Beigenbau_dvb_t_antenne%252Bdoppelquad%252Bfuer%252B5%252Beuro%252Bbasteln.htm%26hl%3Den%26client%3Diceweasel-a%26rls%3Dorg.debian:en-US:unofficial
- it does not work with my AMD-Board (SB700-Chipset), I have no problems
using it on my Laptop (Intel-Chipset) and another AMD-Desktop
(Nvidia-Chipset).
I have found several reports in Mailinglists mentioning the same problems.
Thats wierd. So the usb controler on the Nova-TD and the host controler on
the SB700 are incompatible?
I also have a Hauppauge Nova-T USB-2 (dib3000, large metal case) and a
Hauppauge WinTV Ministick (Siano sms1xx-Chipset), the RF-Part of both
devices is a far better one compared to the Nova-TD.
Is there a way to truely compare different receiver's quality? The
information that femon and tzap report (SNR, BER, UNC) are only what the
receiver itself says.
Not yet and hard to come by, also lots of different antennas and
amplification.
Cheers,
Hermann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Making Samsung S3C64XX camera interface driver in SoC camera subsystem
Hello, I'm planing to make a new camera interface driver for S3C64XX from Samsung. Even if it already has a driver, it seems to be re-designed for some reasons. If you are interested in, take a look at following repository (http://git.kernel.org/?p=linux/kernel/git/eyryu_ap/samsung-ap-2.6.24.git;a=summary) drivers/media/video/s3c_* files Before beginning to implement a new driver for that, I need to clarify some of features about how to implement in driver. Please take a look at the diagram on page 610 of following user manual of s3c6400. http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C6400X_UserManual_rev1-0_2008-02_661558um.pdf It seems to have a couple of path for camera data named codec and preview, and they could be used at the same time. It means that it has no problem making those two paths into independent device nodes like /dev/video0 and /dev/video1 But there is a limit of size using both of paths at the same time. I mean, If you are using preview path and camera sensor is running with 1280*720 resolution (which seems to be the max resolution could be handled by preview path), codec path can't use resolution bigger than 1280*720 at the same time because camera sensor can't produce different resolution at a time. And also we should face a big problem when we are making dual camera system with s3c64xx. Dual camera with single camera interface has some restriction using clock and data path, because they have to be shared between both of cameras. I suppose to handle them with VIDIOC_S_INPUT and G_INPUT. And with those, we can handle dual camera with single camera interface in a decent way. But the thing is that there should be a problem using dual camera with preview and codec path of s3c64xx. Even if we have each preview, and codec device node and can't open them concurrently when user is attempting to open each camera sensor like camera A with preview node and camera B with codec node. Because both of those camera sensors are sharing same data path and clock source, and s3c64xx camera interface only can handle one camera at a time. So, what I am concerned is how to make it a elegant driver which has two device nodes handling multiple sensors as input devices. Sounds complicated but I'm asking you to help me with any opinion about designing this driver. Any opinion about these issues will be greatly helpful to me. Cheers, Nate -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] soc-camera: add a free_bus method to struct soc_camera_link
On Wed, Apr 15, 2009 at 8:17 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Currently pcm990 camera bus-width management functions request a GPIO and never free it again. With this approach the GPIO extender driver cannot be unloaded once camera drivers have been loaded, also unloading theb i2c-pxa bus driver produces errors, because the GPIO extender driver cannot unregister properly. Another problem is, that if camera drivers are once loaded before the GPIO extender driver, the platform code marks the GPIO unavailable and only a reboot helps to recover. Adding an explicit free_bus method and using it in mt9m001 and mt9v022 drivers fixes these problems. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Eric, need your ack for the arch/arm/mach-pxa part. Sascha's wouldn't hurt either:-) Yes, the mach-pxa/ part looks OK to me. Acked-by: Eric Miao eric.m...@marvell.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: RFC on proposed patches to mr97310a.c for gspca and v4l
On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote: Hello Theodore kilg...@banach.math.auburn.edu wrote: Also, after the byte indicator for the compression algorithm there are some more bytes, and these almost definitely contain information which could be valuable while doing image processing on the output. If they are already kept and passed out of the module over to libv4lconvert, then it would be very easy to do something with those bytes if it is ever figured out precisely what they mean. But if it is not done now it would have to be done then and would cause even more trouble. I sent it already in private mail to you. Here is the observation I made for the PAC207 SOF some years ago: From usb snoop. FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 1. xx: looks like random value 2. xx: changed from 0x03 to 0x0b 3. xx: changed from 0x06 to 0x49 4. xx: changed from 0x07 to 0x55 5. xx: static 0x96 6. xx: static 0x80 7. xx: static 0xa0 And I did play in Linux and could identify some fields :-) . In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 1. xx: don't know but value is changing between 0x00 to 0x07 2. xx: this is the actual pixel clock 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (center) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (edge) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Thomas I've been looking through the frame headers sent by the MR97310A (the Aiptek PenCam VGA+, 08ca:0111). Here are my observations. FF FF 00 FF 96 6x x0 xx xx xx xx xx In binary that looks something like this: 10010110 011001aa a101 All of the values look to be MSbit first. A looks like a 3-bit frame sequence number that seems to start with 1 and increments for each frame. B, C, and D might be brightness and contrast; minimum and maximum values for these vary with the image size. For 640x480, 320x240, and 160x120: dark scene (all black): B: near 0 C: 0x000 D: 0xC60 bright scene (all white): B: usually 0xC15C C: 0xC60 D: 0x000 For 352x288 and 176x144: dark scene (all black): B: near 0 C: 0x000 D: 0xB5B bright scene (all white): B: usually 0xB0FE C: 0xB53 D: 0x007 B increases with increasing brightness. C increases with more white pixels and D increases with more black pixels. A gray image has C and D near zero, while a high-contrast image (half black, half white) has C and D around 0x600 or so. The sum of C and D is not a constant. I don't know how brightness and contrast are handled in V4L. Hopefully someone can put this to use. -Kyle -- 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
