date:20090201

On Tue, 27 Jan 2009, Kuninori Morimoto wrote:

> 
> Signed-off-by: Kuninori Morimoto 

Why is this needed? Do you see any possibility for tw9910 to be called 
with an unsupported format?

Thanks
Guennadi

> ---
>  drivers/media/video/tw9910.c |   13 +
>  1 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
> index 1a9c6fd..57027c0 100644
> --- a/drivers/media/video/tw9910.c
> +++ b/drivers/media/video/tw9910.c
> @@ -647,6 +647,19 @@ static int tw9910_set_fmt(struct soc_camera_device *icd, 
> __u32 pixfmt,
>   struct tw9910_priv *priv = container_of(icd, struct tw9910_priv, icd);
>   int ret  = -EINVAL;
>   u8  val;
> + int i;
> +
> + /*
> +  * check color format
> +  */
> + for (i = 0 ; i < ARRAY_SIZE(tw9910_color_fmt) ; i++) {
> + if (pixfmt == tw9910_color_fmt[i].fourcc) {
> + ret = 0;
> + break;
> + }
> + }
> + if (ret < 0)
> + goto tw9910_set_fmt_error;
>  
>   /*
>* select suitable norm
> -- 
> 1.5.6.3
> 

---
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

Re: [PATCH 1/2] soc_camera: Add FLDPOL flags

On Fri, 30 Jan 2009, Kuninori Morimoto wrote:

> 
> Signed-off-by: Kuninori Morimoto 
> ---
>  include/media/soc_camera.h |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> index 7440d92..2c7ecdf 100644
> --- a/include/media/soc_camera.h
> +++ b/include/media/soc_camera.h
> @@ -231,6 +231,8 @@ static inline struct v4l2_queryctrl const 
> *soc_camera_find_qctrl(
>  #define SOCAM_PCLK_SAMPLE_FALLING(1 << 13)
>  #define SOCAM_DATA_ACTIVE_HIGH   (1 << 14)
>  #define SOCAM_DATA_ACTIVE_LOW(1 << 15)
> +#define SOCAM_FLDPOL_ACTIVE_HIGH (1 << 16)
> +#define SOCAM_FLDPOL_ACTIVE_LOW  (1 << 17)
>  
>  #define SOCAM_DATAWIDTH_MASK (SOCAM_DATAWIDTH_4 | SOCAM_DATAWIDTH_8 | \
> SOCAM_DATAWIDTH_9 | SOCAM_DATAWIDTH_10 | \

"FLDPOL" is the name of a field in the register, and it means "field ID 
polarity," i.e., the polarity of the field ID signal. Hence the name 
you're proposing reads: "field ID polarity active {low,high}," which seems 
redundant to me. What about SOCAM_FIELD_ID_ACTIVE_{HIGH,LOW}? Following 
the scheme "SOCAM__ACTIVE_*."

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

Re: [PATCH 2/2] sh_mobile_ceu: Add FLDPOL operation

On Fri, 30 Jan 2009, Kuninori Morimoto wrote:

> 
> Signed-off-by: Kuninori Morimoto 
> ---
>  drivers/media/video/sh_mobile_ceu_camera.c |7 +++
>  include/media/sh_mobile_ceu.h  |2 ++
>  2 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/sh_mobile_ceu_camera.c 
> b/drivers/media/video/sh_mobile_ceu_camera.c
> index 07b7b4c..366e5f5 100644
> --- a/drivers/media/video/sh_mobile_ceu_camera.c
> +++ b/drivers/media/video/sh_mobile_ceu_camera.c
> @@ -118,6 +118,12 @@ static unsigned long make_bus_param(struct 
> sh_mobile_ceu_dev *pcdev)
>   if (pcdev->pdata->flags & SH_CEU_FLAG_USE_16BIT_BUS)
>   flags |= SOCAM_DATAWIDTH_16;
>  
> + if (pcdev->pdata->flags & SH_CEU_FLAG_USE_FLDPOL_HIGH)
> + flags |= SOCAM_FLDPOL_ACTIVE_HIGH;
> +
> + if (pcdev->pdata->flags & SH_CEU_FLAG_USE_FLDPOL_LOW)
> + flags |= SOCAM_FLDPOL_ACTIVE_LOW;
> +
>   if (flags & SOCAM_DATAWIDTH_MASK)
>   return flags;
>  
> @@ -474,6 +480,7 @@ static int sh_mobile_ceu_set_bus_param(struct 
> soc_camera_device *icd,
>   icd->current_fmt->fourcc == V4L2_PIX_FMT_NV61)
>   value ^= 0x0100; /* swap U, V to change from NV1x->NVx1 */
>  
> + value |= common_flags & SOCAM_FLDPOL_ACTIVE_LOW ? 1 << 16 : 0;
>   value |= common_flags & SOCAM_VSYNC_ACTIVE_LOW ? 1 << 1 : 0;
>   value |= common_flags & SOCAM_HSYNC_ACTIVE_LOW ? 1 << 0 : 0;
>   value |= buswidth == 16 ? 1 << 12 : 0;

Why are you basing your decision to use active low or high level of the 
Field ID signal upon the platform data? Doesn't it depend on the 
configuration of the connected device, and, possibly, an inverter between 
them? So, looks like it should be handled in exactly the same way as all 
other signals - negotiate with the connected device (sensor / decoder / 
...) and apply platform-defined inverters if any?

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

Re: [PATCH] sh_mobile_ceu: SOCAM flags are prepared at itself.

On Fri, 30 Jan 2009, Kuninori Morimoto wrote:

> 
> Signed-off-by: Kuninori Morimoto 
> Signed-off-by: Magnus Damm 
> ---
>  drivers/media/video/sh_mobile_ceu_camera.c |   27 +--
>  include/media/sh_mobile_ceu.h  |5 +++--
>  2 files changed, 28 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/video/sh_mobile_ceu_camera.c 
> b/drivers/media/video/sh_mobile_ceu_camera.c
> index 9cde91a..07b7b4c 100644
> --- a/drivers/media/video/sh_mobile_ceu_camera.c
> +++ b/drivers/media/video/sh_mobile_ceu_camera.c
> @@ -101,6 +101,29 @@ struct sh_mobile_ceu_dev {
>   const struct soc_camera_data_format *camera_fmt;
>  };
>  
> +static unsigned long make_bus_param(struct sh_mobile_ceu_dev *pcdev)
> +{
> + unsigned long flags;
> +
> + flags = SOCAM_SLAVE |

Guys, are you both sure this should be SLAVE, not MASTER? Have you tested 
it? Both tw9910 and ov772x register themselves as MASTER and from the 
datasheet the interface seems to be a typical master parallel to me... I 
think with this patch you would neither be able to use your driver with 
tw9910 nor with ov772x...

Thanks
Guennadi

> + SOCAM_PCLK_SAMPLE_RISING |
> + SOCAM_HSYNC_ACTIVE_HIGH |
> + SOCAM_HSYNC_ACTIVE_LOW |
> + SOCAM_VSYNC_ACTIVE_HIGH |
> + SOCAM_VSYNC_ACTIVE_LOW;
> +
> + if (pcdev->pdata->flags & SH_CEU_FLAG_USE_8BIT_BUS)
> + flags |= SOCAM_DATAWIDTH_8;
> +
> + if (pcdev->pdata->flags & SH_CEU_FLAG_USE_16BIT_BUS)
> + flags |= SOCAM_DATAWIDTH_16;
> +
> + if (flags & SOCAM_DATAWIDTH_MASK)
> + return flags;
> +
> + return 0;
> +}
> +
>  static void ceu_write(struct sh_mobile_ceu_dev *priv,
> unsigned long reg_offs, u32 data)
>  {
> @@ -396,7 +419,7 @@ static int sh_mobile_ceu_set_bus_param(struct 
> soc_camera_device *icd,
>  
>   camera_flags = icd->ops->query_bus_param(icd);
>   common_flags = soc_camera_bus_param_compatible(camera_flags,
> -pcdev->pdata->flags);
> +make_bus_param(pcdev));
>   if (!common_flags)
>   return -EINVAL;
>  
> @@ -517,7 +540,7 @@ static int sh_mobile_ceu_try_bus_param(struct 
> soc_camera_device *icd)
>  
>   camera_flags = icd->ops->query_bus_param(icd);
>   common_flags = soc_camera_bus_param_compatible(camera_flags,
> -pcdev->pdata->flags);
> +make_bus_param(pcdev));
>   if (!common_flags)
>   return -EINVAL;
>  
> diff --git a/include/media/sh_mobile_ceu.h b/include/media/sh_mobile_ceu.h
> index b5dbefe..0f3524c 100644
> --- a/include/media/sh_mobile_ceu.h
> +++ b/include/media/sh_mobile_ceu.h
> @@ -1,10 +1,11 @@
>  #ifndef __ASM_SH_MOBILE_CEU_H__
>  #define __ASM_SH_MOBILE_CEU_H__
>  
> -#include 
> +#define SH_CEU_FLAG_USE_8BIT_BUS (1 << 0) /* use  8bit bus width */
> +#define SH_CEU_FLAG_USE_16BIT_BUS(1 << 1) /* use 16bit bus width */
>  
>  struct sh_mobile_ceu_info {
> - unsigned long flags; /* SOCAM_... */
> + unsigned long flags;
>  };
>  
>  #endif /* __ASM_SH_MOBILE_CEU_H__ */
> -- 
> 1.5.6.3
> 

---
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

[PULL] gspca

2009-02-01 Thread Jean-Francois Moine

Hi Mauro,

Please pull from http://linuxtv.org/hg/~jfrancois/gspca/
for:

changeset:   10391:6cec0a94bb17
gspca - sonixj: Sensor mt9v111 added.

changeset:   10392:7b5675e94f79
gspca - vc032x: Webcam 041e:405b added and mi1310_soc updated.

changeset:   10393:073b78e3a4ef
gspca - documentation: Add the webcam 041e:405b.

changeset:   10407:71c3fb40f5d8
gspca - sonixj: Bad sensor definition of the webcams 0c45:60c0.

changeset:   10408:1adbb71eb3fa
gspca - vc032x: Add resolution 1280x1024 for sensor mi1310_soc.

changeset:   10409:5c1523242c66
gspca - sonixj: Bad initialization of sensor mt9v111.

changeset:   10427:17531f026df3
gspca - sonixj: Sensor sp80708 added for webcam 0c45:6143.

changeset:   10428:6aec7faa8694
gspca - sonixj: Specific gamma tables per sensor.

changeset:   10429:6d39e60bea87
gspca - sonixj: Simplify the probe of the sensors mi0360/mt9v111.

changeset:   10430:829f8b81f759
gspca - sonixj: Adjust some exchanges with the sensor mt9v111.

changeset:   10431:eb45e2126ad1
gspca - vc032x: Bad revision for the webcam 041e:405b.

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

Re: cx88-dvb broken since 2.6.29-rc1

2009-02-01 Thread Mauro Carvalho Chehab


On Sun, 1 Feb 2009, Jean Delvare wrote:


On Sun, 1 Feb 2009 11:42:57 -0200, Mauro Carvalho Chehab wrote:

On Sun, 1 Feb 2009 14:29:27 +0100
Jean Delvare  wrote:


On Thu, 29 Jan 2009 19:24:31 -0200, Mauro Carvalho Chehab wrote:

I have already a pull request almost ready that will fix this issue. I'll
likely send it today or tomorrow.


Did it happen? I've just tested kernel 2.6.29-rc3-git3 and the problem
is still present.


I just sent today a pull request with this fix included:


Great, thanks.


From: Mauro Carvalho Chehab 
To: Linus Torvalds 
Cc: Andrew Morton , linux-ker...@vger.kernel.org, 
linux-me...@vger.linuxtv.org


The last address looks like a typo.


Yes. It were a typo on my patchbomb script. Fixed, thanks!





--
Cheers,
Mauro Carvalho Chehab
http://linuxtv.org
mche...@infradead.org
--
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/~awalls/cx18

Mauro,

Please pull from 

http://linuxtv.org/hg/~awalls/cx18

for the following:

cx18: Fix coding style of a switch statement per checkpatch.pl
cx18: Normalize APU after second APU firmware load
cx18: Smarter verification of CX18_AUDIO_ENABLE register writes
cx18: Defer A/V core initialization until a valid cx18_av_cmd arrives


Note that in my new setup on Fedora 10, kernel 2.6.27.9-159.fc10.x86_64,
the automatic checkpatch doesn't seem to be working.  (I think it's
missing the --no-tree argument.)  Here's what I get on commits:

# WARNING: /lib/modules/`uname -r`/build/scripts/checkpatch.pl version
0.21 returned some errors.
#  Please fix.
#
# Must be run from the top-level dir. of a kernel tree
#

Regards,
Andy


diffstat:
 cx18-audio.c   |3 +--
 cx18-av-core.c |   40 +---
 cx18-av-firmware.c |3 ++-
 cx18-driver.c  |   13 +
 4 files changed, 49 insertions(+), 10 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

Re: PAC7302 disassembly

2009-02-01 Thread Thomas Kaiser


christopherwander...@columbus.rr.com wrote:
Can I get as much disassembly of the PAC7302 drivers with your comments next to 
it? I am trying to improve my webcam and currently disassembling the driver, in 
Vista64 with IDA Pro. (I still have the 32 bit driver files as I upgraded from 
xp32) 
I am helping on the gAIM/Pidgin voice/video chat and this driver isn't where I  
would like it to be. I need better color balance, even after changing alot of 
options I still turn out orange quite a bit. 
I have Assembly expierence, I own the Intel Instruction Manuals, so figuring out 
the actual given driver with a little bit of help based on the current progress 
should not be difficult 
Christopher W. Anderson 
--

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


Hello Christopher

Thanks for posting to linux-me...@vger.kernel.org.

As I wrote you back on the private mail you send me, I don't really 
understand what you try to tell or ask me!


What do you mean with "disassembly"? Converting the binary Windoz drive 
to assemble code? Or looking with a hex editor into the Windowz driver 
and figure out what the opcode is doing?


The PAC7302 Linux driver was develop by re-engineering the Windoz drive 
with the help of usb snoop. Usb snoop 
(http://benoit.papillault.free.fr/usbsnoop/) is a program which can log 
the usb traffic on a Windoz box. By looking at this logs, I could figure 
out how to control the cam (PAC7302 bridge). To find out the compression 
Pixart is using in this chip was a long journey, too.


I suggest you get the newest driver from linuxtv.org or from
Jean-Francois Moine site (http://moinejf.free.fr/).

Don't forget to get the newest libv4l lib from Hans de Geode. After you 
installed this and tested the webcam, please report back how the driver 
is working.


Anyway, when you are able to disassemble the Windowz drive, please post 
your results here. There are some people around here how can comment 
your outcome.


Thomas

--
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: PAC7302 disassembly

2009-02-01 Thread Thomas Kaiser


Thomas Kaiser wrote:

christopherwander...@columbus.rr.com wrote:
Can I get as much disassembly of the PAC7302 drivers with your 
comments next to it? I am trying to improve my webcam and currently 
disassembling the driver, in Vista64 with IDA Pro. (I still have the 
32 bit driver files as I upgraded from xp32) I am helping on the 
gAIM/Pidgin voice/video chat and this driver isn't where I  would like 
it to be. I need better color balance, even after changing alot of 
options I still turn out orange quite a bit. I have Assembly 
expierence, I own the Intel Instruction Manuals, so figuring out the 
actual given driver with a little bit of help based on the current 
progress should not be difficult Christopher W. Anderson --

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


Hello Christopher

Thanks for posting to linux-me...@vger.kernel.org.

As I wrote you back on the private mail you send me, I don't really 
understand what you try to tell or ask me!


What do you mean with "disassembly"? Converting the binary Windoz drive 
to assemble code? Or looking with a hex editor into the Windowz driver 
and figure out what the opcode is doing?


The PAC7302 Linux driver was develop by re-engineering the Windoz drive 
with the help of usb snoop. Usb snoop 
(http://benoit.papillault.free.fr/usbsnoop/) is a program which can log 
the usb traffic on a Windoz box. By looking at this logs, I could figure 
out how to control the cam (PAC7302 bridge). To find out the compression 
Pixart is using in this chip was a long journey, too.


I suggest you get the newest driver from linuxtv.org or from
Jean-Francois Moine site (http://moinejf.free.fr/).

Don't forget to get the newest libv4l lib from Hans de Geode. After you 
installed this and tested the webcam, please report back how the driver 
is working.


Anyway, when you are able to disassemble the Windowz drive, please post 
your results here. There are some people around here how can comment 
your outcome.


Thomas

--
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


Sorry for replying to my own post.

I forgot to tell that there is no documentation available from Pixart. I 
tried to meet them (Pixart) the last time I was in Taiwan but they 
refused to meet me :-( (Looks like they are not interested to have there 
products running with Linux)


Thomas


--
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

Driver for WinTV-NOVA-S-USB2

2009-02-01 Thread Stephen Brooks

Hello all,
Just a quick question to everyone is anyone writing a driver for
WinTV-NOVA-S-USB2? It seems to be made up from already supported
devices so the driver looks straight forward. I'm happy to dive in and
give it a go as long as I'm not treading on any ones toes :)

I see someone wrote the wiki page for the device
(http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-S-USB2) so
I was wondering if anyone got any further?

(I've done C coding for 16 years, this won't be my first kernel
driver, but will be my first Linux kernel driver)

-- 
Stephen Brooks
--
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] Leadtek WinFast DTV-1800H and DTV-2000H

2009-02-01 Thread hermann pitton

Hi,

Am Sonntag, den 01.02.2009, 17:37 +0100 schrieb Miroslav Šustek:
> Hi, few months ago I sent the patch for Leadtek WinFast DTV-1800H card, but 
> it wasn't merged to repository yet.
> Maybe it's because of the merging of mailing lists. I'm sending it again.
> 
> These are the original messages:
> http://linuxtv.org/pipermail/linux-dvb/2008-October/029859.html
> http://linuxtv.org/pipermail/linux-dvb/2008-November/030362.html
> 
> Briefly, patch adds support for analog tv, radio, dvb-t and remote control.
> About three people already confirmed the functionality.
> 
> 
> The second patch I attached (leadtek_winfast_dtv2000h.patch) is from Mirek 
> Slugeň and it adds support for some revisions of Leadtek WinFast DTV-2000H.
> I don't have any of DTV-2000H cards, so I cannot confirm its correctness.
> 
> Here is the original message from Mirek Slugeň:
> http://linuxtv.org/pipermail/linux-dvb/2008-November/030644.html
> 
> (The patch is dependent on 1800H patch.)
> 
> 
> I hope this is the last time I'm bothering you with this thing. ;)
> 
> - Miroslav Šustek
> 

Miroslav, Mirek, looks OK so far,

but biggest problem is that all patches have no Signed-off-by line.
Try README.patches in v4l-dvb and related.

The not at all working radio on the DTV2000H_J could indicate that it is
a FMD1216MEX with different radio IF, which was recently added by Darron
Broad. Good idea how they did expand the antenna input connectors.

Also, for the unsupported XCeive4000 on the DTV2000H_PLUS I guess
TUNER_ABSENT should be used until support for it is ready and all
related ?

There is another patch from Mirek for saa7134 with multiple multi
frontend boards from Nov. 28 2008 where I asked for his SOB, but no
response. It has at least a tested-by from me and an updated version
against recent v4l-dvb can be provided.
http://www.linuxtv.org/pipermail/linux-dvb/2009-January/031217.html

Mauro seems to prefer to have v4l-dvb related e-mails at infradead.org.
Changed to it.

Cheers,
Hermann


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] general protection fault: 0000 [1] SMP with 2.6.27 and 2.6.28

On Sat, 2009-01-31 at 15:01 +, Chris Mayo wrote:
> > I've been seeing general protection fault's with 2.6.27 and 2.6.28
> > (gentoo-sources, amd64) used with vdr. Unfortunately I can't reproduce
> > them on demand.
> > 
> 
> Two more of these with 2.6.28 so I switched back to 2.6.25 and now four
> weeks with no more
> 
> > 
> > 
> > vdr: [5577] switching device 2 to channel 2
> > DVB: frontend 1 frequency limits undefined - fix the driver
> > general protection fault:  [1] SMP
> > CPU 0
> > Modules linked in: snd_pcm_oss snd_mixer_oss it87 hwmon_vid r8169
> > dvb_ttpci saa7146_vv videobuf_dma_sg videobuf_core sp8870 budget l64781
> > ves1x93 budget_ci lnbp21 budget_core saa7146 ttpci_eeprom tda1004x
> > ir_common tda10023 stv0299 k8temp snd_hda_intel snd_pcm snd_timer snd
> > snd_page_alloc forcedeth i2c_nforce2
> > Pid: 5721, comm: kdvb-fe-1 Not tainted 2.6.27-gentoo-r5 #1
> > RIP: 0010:[]  []
> > grundig_29504_401_tuner_set_params+0x39/0x100 [budget]
> > RSP: 0018:88003d3edda0  EFLAGS: 00010202
> > RAX: 88003d3eddb0 RBX: 88003e0de000 RCX: 
> > RDX: 28020004 RSI: 88003efe5808 RDI: 88003efe4010
> > RBP:  R08:  R09: 
> > R10:  R11:  R12: 88003efe5808
> > vdr: [5720] changing pids of channel 30 from 203+203:407=eng,408=und:0:0
> > to 203+203:407=eng,408=und:603=eng:0
> > R13: 88003efe4000 R14: 1d324372 R15: 88003efe59d8
> > FS:  45a17950() GS:80710600() knlGS:
> > CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
> > CR2: 00f86000 CR3: 00201000 CR4: 06e0
> > DR0:  DR1:  DR2: 
> > DR3:  DR6: 0ff0 DR7: 0400
> > Process kdvb-fe-1 (pid: 5721, threadinfo 88003d3ec000, task
> > 88003f2cd890)
> > Stack:  0004 88003d3eddb0 88003f2cd890 7fff
> > 88003efe4010 a00e5660 88003d3edec0 88003efe59d8
> > 88003efe59b0 8059815d  88003efe5800
> > Call Trace:
> > [] apply_frontend_param+0x40/0x3e0 [l64781]
> > [] schedule_timeout+0xad/0xf0
> > [] dvb_frontend_swzigzag_autotune+0xcd/0x220
> > [] __down_interruptible+0x9c/0xd0
> > [] dvb_frontend_swzigzag+0x19a/0x290
> > [] down_interruptible+0x36/0x60
> > [] dvb_frontend_thread+0x408/0x4c0
> > [] autoremove_wake_function+0x0/0x30
> > [] dvb_frontend_thread+0x0/0x4c0
> > [] kthread+0x47/0x80
> > [] schedule_tail+0x27/0x70
> > [] child_rip+0xa/0x11
> > [] kthread+0x0/0x80
> > [] child_rip+0x0/0x11
> > 
> > 
> > Code: 97 d0 02 00 00 48 8b 58 38 48 8d 44 24 10 48 85 d2 48 c7 04 24 00
> > 00 00 00 66 c7 44 24 04 04 00 48 89 44 24 08 0f 84 af 00 00 00 <0f> b6
> > 02 66 89 04 24 8b 0e b8 05 3d 95 0c 44 8d 81 48 39 27 02
> > RIP  [] grundig_29504_401_tuner_set_params+0x39/0x100
> > [budget]
> > RSP 
> > ---[ end trace 33ec88b18fe8a71a ]---

This one and the two other are all suffering from the same error a
derefernce of the %rdx register that points to garbage.

The source code in question is in
linux/drivers/media/dvb/ttpci/budget.c:grundig_29504_401_tuner_set_params():

static int grundig_29504_401_tuner_set_params(struct dvb_frontend* fe, struct 
dvb_frontend_parameters* params)
{
struct budget *budget = fe->dvb->priv;
u8 *tuner_addr = fe->tuner_priv;
u32 div;
u8 cfg, cpump, band_select;
u8 data[4];
struct i2c_msg msg = { .flags = 0, .buf = data, .len = sizeof(data) };

if (tuner_addr)
msg.addr = *tuner_addr;
else
msg.addr = 0x61;

div = (36125000 + params->frequency) / 16;
[...]

The oops code disassembles to this

  13:   48 8b 58 38 mov0x38(%rax),%rbx
  17:   48 8d 44 24 10  lea0x10(%rsp),%rax
  1c:   48 85 d2test   %rdx,%rdx   if (tuner_addr) ...
  1f:   48 c7 04 24 00 00 00movq   $0x0,(%rsp) msg.flags = 0
  26:   00 
  27:   66 c7 44 24 04 04 00movw   $0x4,0x4(%rsp)  msg.len = sizeof(data)
  2e:   48 89 44 24 08  mov%rax,0x8(%rsp)  msg.buf = data
  33:   0f 84 af 00 00 00   je 0xe8if (tuner_addr) ...
  39:   0f b6 02movzbl (%rdx),%eax *tuner_addr  <--- Ooops 
is here  
  3c:   66 89 04 24 mov%ax,(%rsp)
  40:   8b 0e   mov(%rsi),%ecx
  42:   b8 05 3d 95 0c  mov$0xc953d05,%eax1/16 (times 
0x2000)
  47:   44 8d 81 48 39 27 02lea0x2273948(%rcx),%r8d   36125000 + 
params->frequency


So tuner_addr is non-NULL and is not a valid pointer either.

It looks like linux/drivers/media/dvb/ttpci/budget.c:frontend_init() is
setting the pointer up properly.  So something else is trashing the
struct dvb_frontend structure pointed to by the variable fe.  Finding
what's doing that will be difficult.

Without a devi

Driver for WinTV-NOVA-S-USB2

2009-02-01 Thread Stephen Brooks

Hello all,
Just a quick question to everyone is anyone writing a driver for
WinTV-NOVA-S-USB2? It seems to be made up from already supported
devices so the driver looks straight forward. I'm happy to dive in and
give it a go as long as I'm not treading on any ones toes :)

I see someone wrote the wiki page for the device
(http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-NOVA-S-USB2) so
I was wondering if anyone got any further?

(I've done C coding for 16 years, this won't be my first kernel
driver, but will be my first Linux kernel driver)

-- 
Stephen Brooks
--
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] sh_mobile_ceu: SOCAM flags are prepared at itself.

On Sun, 1 Feb 2009, Guennadi Liakhovetski wrote:

> On Fri, 30 Jan 2009, Kuninori Morimoto wrote:
> 
> > 
> > Signed-off-by: Kuninori Morimoto 
> > Signed-off-by: Magnus Damm 
> > ---
> >  drivers/media/video/sh_mobile_ceu_camera.c |   27 
> > +--
> >  include/media/sh_mobile_ceu.h  |5 +++--
> >  2 files changed, 28 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/media/video/sh_mobile_ceu_camera.c 
> > b/drivers/media/video/sh_mobile_ceu_camera.c
> > index 9cde91a..07b7b4c 100644
> > --- a/drivers/media/video/sh_mobile_ceu_camera.c
> > +++ b/drivers/media/video/sh_mobile_ceu_camera.c
> > @@ -101,6 +101,29 @@ struct sh_mobile_ceu_dev {
> > const struct soc_camera_data_format *camera_fmt;
> >  };
> >  
> > +static unsigned long make_bus_param(struct sh_mobile_ceu_dev *pcdev)
> > +{
> > +   unsigned long flags;
> > +
> > +   flags = SOCAM_SLAVE |
> 
> Guys, are you both sure this should be SLAVE, not MASTER? Have you tested 
> it? Both tw9910 and ov772x register themselves as MASTER and from the 
> datasheet the interface seems to be a typical master parallel to me... I 
> think with this patch you would neither be able to use your driver with 
> tw9910 nor with ov772x...

Ok, sorry, you, probably, did test it and it worked, but just because the 
SLAVE / MASTER flag is not tested in soc_camera_bus_param_compatible(), 
which I should fix with the next pull, but this does look wrong. Please, 
fix.

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] DAB: fix typo

2009-02-01 Thread Németh Márton

From: Márton Németh 

Fix typo in "DAB adapters" section in Kconfig.

Signed-off-by: Márton Németh 
---
--- linux-2.6.29-rc3/drivers/media/Kconfig.orig 2008-12-25 00:26:37.0 
+0100
+++ linux-2.6.29-rc3/drivers/media/Kconfig  2009-02-01 13:30:54.0 
+0100
@@ -117,7 +117,7 @@ source "drivers/media/dvb/Kconfig"
 config DAB
boolean "DAB adapters"
---help---
- Allow selecting support for for Digital Audio Broadcasting (DAB)
+ Allow selecting support for Digital Audio Broadcasting (DAB)
  Receiver adapters.

 if DAB
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PXA Quick capture interface with HV7131RP-Camera

On Sat, 31 Jan 2009, Bennet Fischer wrote:

> Hi
> 
> 
> I am trying to get a camera to work together with an PXA270 processor.
> My system has the following specs:
> 
> Platform: Gumstix Verdex Pro
> Camera: HV7131RP
> OS: Linux 2.6.28
> 
> I wrote a simple driver for the camera which omits all the i2c-stuff
> because the camera starts already in a default configuration which
> works fine for me.
> A V4L2-device is generated and everything looks fine. But when i start
> to capture, no data arrives BUT the Quick Capture Interface outputs a
> MCLK and the camera responds with a PCLK, LV and FV (and data of
> couse).
> For getting a bit closer to the origin of the problem I disabled DMA
> in pxa_camera.c and enabled all Interrupts in the CICR0 register. No
> interrupt is generated. Even by disabling DMA and IRQ and looking into
> CISR nothing happens.
> I checked all the CIF registers bitwise. The polarity of the LV and FV
> is correct, the alternate pin functions are correct, the interrupt bit
> is non-masked, the size of the pixel matrix is correct. I'm a bit
> desperate because at the moment I have no idea what to do next. I
> would be thankful for any hint.

Maybe you could post your platform data, i.e., your struct 
pxacamera_platform_data?

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

Re: [linux-dvb] general protection fault: 0000 [1] SMP with 2.6.27 and 2.6.28

2009-02-01 Thread Oliver Endriss

Andy Walls wrote:
> On Sat, 2009-01-31 at 15:01 +, Chris Mayo wrote:
> > > I've been seeing general protection fault's with 2.6.27 and 2.6.28
> > > (gentoo-sources, amd64) used with vdr. Unfortunately I can't reproduce
> > > them on demand.
> > > 
> > 
> > Two more of these with 2.6.28 so I switched back to 2.6.25 and now four
> > weeks with no more
> > 
> > > 
> > > 
> > > vdr: [5577] switching device 2 to channel 2
> > > DVB: frontend 1 frequency limits undefined - fix the driver
> > > general protection fault:  [1] SMP
> > > CPU 0
> > > Modules linked in: snd_pcm_oss snd_mixer_oss it87 hwmon_vid r8169
> > > dvb_ttpci saa7146_vv videobuf_dma_sg videobuf_core sp8870 budget l64781
> > > ves1x93 budget_ci lnbp21 budget_core saa7146 ttpci_eeprom tda1004x
> > > ir_common tda10023 stv0299 k8temp snd_hda_intel snd_pcm snd_timer snd
> > > snd_page_alloc forcedeth i2c_nforce2
> > > Pid: 5721, comm: kdvb-fe-1 Not tainted 2.6.27-gentoo-r5 #1
> > > RIP: 0010:[]  []
> > > grundig_29504_401_tuner_set_params+0x39/0x100 [budget]
> > > RSP: 0018:88003d3edda0  EFLAGS: 00010202
> > > RAX: 88003d3eddb0 RBX: 88003e0de000 RCX: 
> > > RDX: 28020004 RSI: 88003efe5808 RDI: 88003efe4010
> > > RBP:  R08:  R09: 
> > > R10:  R11:  R12: 88003efe5808
> > > vdr: [5720] changing pids of channel 30 from 203+203:407=eng,408=und:0:0
> > > to 203+203:407=eng,408=und:603=eng:0
> > > R13: 88003efe4000 R14: 1d324372 R15: 88003efe59d8
> > > FS:  45a17950() GS:80710600() 
> > > knlGS:
> > > CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
> > > CR2: 00f86000 CR3: 00201000 CR4: 06e0
> > > DR0:  DR1:  DR2: 
> > > DR3:  DR6: 0ff0 DR7: 0400
> > > Process kdvb-fe-1 (pid: 5721, threadinfo 88003d3ec000, task
> > > 88003f2cd890)
> > > Stack:  0004 88003d3eddb0 88003f2cd890 
> > > 7fff
> > > 88003efe4010 a00e5660 88003d3edec0 88003efe59d8
> > > 88003efe59b0 8059815d  88003efe5800
> > > Call Trace:
> > > [] apply_frontend_param+0x40/0x3e0 [l64781]
> > > [] schedule_timeout+0xad/0xf0
> > > [] dvb_frontend_swzigzag_autotune+0xcd/0x220
> > > [] __down_interruptible+0x9c/0xd0
> > > [] dvb_frontend_swzigzag+0x19a/0x290
> > > [] down_interruptible+0x36/0x60
> > > [] dvb_frontend_thread+0x408/0x4c0
> > > [] autoremove_wake_function+0x0/0x30
> > > [] dvb_frontend_thread+0x0/0x4c0
> > > [] kthread+0x47/0x80
> > > [] schedule_tail+0x27/0x70
> > > [] child_rip+0xa/0x11
> > > [] kthread+0x0/0x80
> > > [] child_rip+0x0/0x11
> > > 
> > > 
> > > Code: 97 d0 02 00 00 48 8b 58 38 48 8d 44 24 10 48 85 d2 48 c7 04 24 00
> > > 00 00 00 66 c7 44 24 04 04 00 48 89 44 24 08 0f 84 af 00 00 00 <0f> b6
> > > 02 66 89 04 24 8b 0e b8 05 3d 95 0c 44 8d 81 48 39 27 02
> > > RIP  [] grundig_29504_401_tuner_set_params+0x39/0x100
> > > [budget]
> > > RSP 
> > > ---[ end trace 33ec88b18fe8a71a ]---
> 
> This one and the two other are all suffering from the same error a
> derefernce of the %rdx register that points to garbage.
> 
> The source code in question is in
> linux/drivers/media/dvb/ttpci/budget.c:grundig_29504_401_tuner_set_params():
> 
> static int grundig_29504_401_tuner_set_params(struct dvb_frontend* fe, struct 
> dvb_frontend_parameters* params)
> {
> struct budget *budget = fe->dvb->priv;
> u8 *tuner_addr = fe->tuner_priv;
> u32 div;
> u8 cfg, cpump, band_select;
> u8 data[4];
> struct i2c_msg msg = { .flags = 0, .buf = data, .len = sizeof(data) };
> 
> if (tuner_addr)
> msg.addr = *tuner_addr;
> else
> msg.addr = 0x61;
> 
> div = (36125000 + params->frequency) / 16;
> [...]
> 
> The oops code disassembles to this
> 
>   13: 48 8b 58 38 mov0x38(%rax),%rbx
>   17: 48 8d 44 24 10  lea0x10(%rsp),%rax
>   1c: 48 85 d2test   %rdx,%rdx   if (tuner_addr) ...
>   1f: 48 c7 04 24 00 00 00movq   $0x0,(%rsp) msg.flags = 0
>   26: 00 
>   27: 66 c7 44 24 04 04 00movw   $0x4,0x4(%rsp)  msg.len = sizeof(data)
>   2e: 48 89 44 24 08  mov%rax,0x8(%rsp)  msg.buf = data
>   33: 0f 84 af 00 00 00   je 0xe8if (tuner_addr) ...
>   39: 0f b6 02movzbl (%rdx),%eax *tuner_addr  <--- Ooops 
> is here  
>   3c: 66 89 04 24 mov%ax,(%rsp)
>   40: 8b 0e   mov(%rsi),%ecx
>   42: b8 05 3d 95 0c  mov$0xc953d05,%eax1/16 (times 
> 0x2000)
>   47: 44 8d 81 48 39 27 02lea0x2273948(%rcx),%r8d   36125000 + 
> params->frequency
> 
> 
> So tuner_addr is non-NULL and is not a valid pointer either.
> 
> It looks like linux/drivers/me

Re: [PATCH] tw9910: color format check is added on set_fmt


Dear Guennadi

> > Signed-off-by: Kuninori Morimoto 
> 
> Why is this needed? Do you see any possibility for tw9910 to be called 
> with an unsupported format?

for example,
capture_example -f use V4L2_PIX_FMT_YUYV.
but tw9910 support only V4L2_PIX_FMT_VYUY now.

If you think this patch is unnecessary,
please ignore it.

Best regards
--
Kuninori Morimoto
 
--
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] sh_mobile_ceu: SOCAM flags are prepared at itself.


Dear Guennadi

Thank your for checking patch.

> > Guys, are you both sure this should be SLAVE, not MASTER? Have you tested 
> > it? Both tw9910 and ov772x register themselves as MASTER and from the 

Of course I tested it.

> Ok, sorry, you, probably, did test it and it worked, but just because the 
> SLAVE / MASTER flag is not tested in soc_camera_bus_param_compatible(), 
> which I should fix with the next pull, but this does look wrong. Please, 
> fix.

Hmm. I should have asked you what is MASTER/SLAVE before sending patch.
I suspect it it about who generates the clock signal 
either the camera or the host.
Our CEU does not support any clock generation so it is always SLAVE.
Therefore I didn't support MASTER for CEU.

But it seems wrong understanding...
I would like ask you What MASTER/SLAVE means ?

Best regards
--
Kuninori Morimoto
 
--
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] general protection fault: 0000 [1] SMP with 2.6.27 and 2.6.28

On Sun, 2009-02-01 at 23:38 +0100, Oliver Endriss wrote:
> Andy Walls wrote:
> > On Sat, 2009-01-31 at 15:01 +, Chris Mayo wrote:

> > So tuner_addr is non-NULL and is not a valid pointer either.
> > 
> > It looks like linux/drivers/media/dvb/ttpci/budget.c:frontend_init() is
> > setting the pointer up properly.  So something else is trashing the
> > struct dvb_frontend structure pointed to by the variable fe.  Finding
> > what's doing that will be difficult.
> > 
> > Without a device nor steps to reliably reproduce, that's about all I can
> > help with.
> > 
> > Regards,
> > Andy
> 
> Afaik this bug was fixed in changeset
> http://linuxtv.org/hg/v4l-dvb/rev/f4d7d0b84940
>
> CU
> Oliver

Thanks.  I didn't realize the initialization to NULL was a recent fix.
I was looking at very recent v4l-dvb source code with that change in
place (which is why I thought tracking down the problem would be hard).

I agree that that change likely fixes the problem, if Chris doesn't have
it in place.

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] sh_mobile_ceu: Add FLDPOL operation


Dear Guennadi

> > +   value |= common_flags & SOCAM_FLDPOL_ACTIVE_LOW ? 1 << 16 : 0;
> > value |= common_flags & SOCAM_VSYNC_ACTIVE_LOW ? 1 << 1 : 0;
> > value |= common_flags & SOCAM_HSYNC_ACTIVE_LOW ? 1 << 0 : 0;
> > value |= buswidth == 16 ? 1 << 12 : 0;
> 
> Why are you basing your decision to use active low or high level of the 
> Field ID signal upon the platform data? Doesn't it depend on the 
> configuration of the connected device, and, possibly, an inverter between 
> them? So, looks like it should be handled in exactly the same way as all 
> other signals - negotiate with the connected device (sensor / decoder / 
> ...) and apply platform-defined inverters if any?

Hmmm.

The soc_camera framework supports automatic negotiation
for some type of option.
But it doesn't include board configuration.

When board doesn't support Field ID signal,
we will have to modify driver though camera and host support it. 

This is the reason.

I think bus width and field ID are depend on board configuration.
# May be camera strobe. but I'm not sure

Best regards
--
Kuninori Morimoto
 
--
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

TinyTwin (af9015) - tuner 0 not working

2009-02-01 Thread Lindsay Mathieson

I've had a DigitalNow TinyTwin dual usb tuner working on my
mythbox for a week now (latest v4l-dvb trunk).

A odd problem with the tuner has surfaced. Today Tuner 0
stopped getting a lock on any channel. Signal strength is
95%+, Bit Errors are Zero.

However Tuner 1 is locking on and displaying channels just
fine. Tuner 0 used to work fine. I've rebooted, but the
problem hasn't gone away.

Any suggestions?

Thanks - Lindsay

Lindsay Mathieson
http://members.optusnet.com.au/~blackpaw1/album
--
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

[BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)

2009-02-01 Thread e9hack

Hi,

this change set is wrong. The affected functions cannot be called from an 
interrupt
context, because they may process large buffers. In this case, interrupts are 
disabled for
a long time. Functions, like dvb_dmx_swfilter_packets(), could be called only 
from a
tasklet. This change set does hide some strong design bugs in dm1105.c and 
au0828-dvb.c.

Please revert this change set and do fix the bugs in dm1105.c and au0828-dvb.c 
(and other
files).

Regards,
Hartmut
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

kernel-2.6.28 probs

2009-02-01 Thread Robert Golding

Hi all,

I have been trying to get my box's dvb card working in kernel 2.6.28
and have had only failures so far.

It all works quite well in 2.6.27, just doesn't seem to want lock onto
channels when using updated kernel.  I have tried 2.6.28 with the
inbuilt drivers as well as the latest hg drivers which I use for the
2.6.27 kernel.

My card is the LeadTek WinFast PxDVR3200-H

Here is the relevent dmesg section (ignore the gspa, thats for my cam)
>
cx23885 driver version 0.0.1 loaded
ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16
cx23885 :02:00.0: PCI INT A -> Link[APC5] -> GSI 16 (level, low) -> IRQ 16
CORE cx23885[0]: subsystem: 107d:6681, board: Leadtek Winfast
PxDVR3200 H [card=12,insmod option]
i2c-adapter i2c-2: adapter [cx23885[0]] registered
i2c-dev: adapter [cx23885[0]] registered as minor 2
i2c-adapter i2c-3: adapter [cx23885[0]] registered
i2c-dev: adapter [cx23885[0]] registered as minor 3
i2c-adapter i2c-4: adapter [cx23885[0]] registered
i2c-dev: adapter [cx23885[0]] registered as minor 4
i2c-adapter i2c-2: master_xfer[0] W, addr=0x50, len=1
i2c-adapter i2c-2: master_xfer[0] R, addr=0x50, len=256
firewire_core: created device fw0: GUID 001a4d5600e248b0, S400
i2c-core: driver [cx25840'] registered
i2c-adapter i2c-2: found normal entry for adapter 2, addr 0x44
i2c-adapter i2c-2: master_xfer[0] W, addr=0x44, len=0
i2c-adapter i2c-3: found normal entry for adapter 3, addr 0x44
i2c-adapter i2c-3: master_xfer[0] W, addr=0x44, len=0
i2c-adapter i2c-4: found normal entry for adapter 4, addr 0x44
i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=0
i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=2
i2c-adapter i2c-4: master_xfer[0] R, addr=0x44, len=1
i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=2
i2c-adapter i2c-4: master_xfer[0] R, addr=0x44, len=1
cx25840' 4-0044: cx25  0-21 found @ 0x88 (cx23885[0])
i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=2
i2c-adapter i2c-4: master_xfer[0] R, addr=0x44, len=1
i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=3
i2c-adapter i2c-4: master_xfer[0] W, addr=0x44, len=3
i2c-adapter i2c-4: client [cx25840'] registered with bus id 4-0044
i2c-core: driver [cx25840] registered
cx23885_dvb_register() allocating 1 frontend(s)
cx23885[0]: cx23885 based dvb card
spca561 2-10:1.0: usb_probe_interface
spca561 2-10:1.0: usb_probe_interface - got id
gspca: probing 046d:092f
gspca: probe ok
usbcore: registered new interface driver spca561
spca561: registered
nvidia: module license 'NVIDIA' taints kernel.
ACPI: PCI Interrupt Link [APC6] enabled at IRQ 16
nvidia :03:00.0: PCI INT A -> Link[APC6] -> GSI 16 (level, low) -> IRQ 16
nvidia :03:00.0: setting latency timer to 64
NVRM: loading NVIDIA UNIX x86 Kernel Module  180.27  Tue Jan 27
12:16:07 PST 2009
i2c-adapter i2c-2: master_xfer[0] W, addr=0x0f, len=1
i2c-adapter i2c-2: master_xfer[1] R, addr=0x0f, len=1
xc2028 3-0061: creating new instance
xc2028 3-0061: type set to XCeive xc2028/xc3028 tuner
DVB: registering new adapter (cx23885[0])
DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)...
cx23885_dev_checkrevision() Hardware revision = 0xb0
cx23885[0]/0: found at :02:00.0, rev: 2, irq: 16, latency: 0,
mmio: 0xee00
cx23885 :02:00.0: setting latency timer to 64
>


-- 
Regards,Robert

. Some people can tell what time it is by looking at the sun, but
I have never been able to make out the numbers.
---
Errata: Spelling mistakes are not intentional, however, I don't use
spell checkers because it's too easy to allow the spell checker to
make the decisions and use words that are out of context for that
being written, i.e. their/there, your/you're, threw/through and even
accept/except, not to mention foreign (I'm Australian) English
spelling, i.e. colour/color, socks/sox, etc,.
--
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: [BUG] changeset 9029 (http://linuxtv.org/hg/v4l-dvb/rev/aa3e5cc1d833)

On Mon, 2009-02-02 at 02:46 +0100, e9hack wrote:
> Hi,
> 
> this change set is wrong. The affected functions cannot be called from an 
> interrupt
> context, because they may process large buffers. In this case, interrupts are 
> disabled for
> a long time. Functions, like dvb_dmx_swfilter_packets(), could be called only 
> from a
> tasklet. 

I agree with Hartmut that these functions should not be called from an
interrupt context.

Although for deferrable work, I thought tasklets were deprecated and
that work handlers were the preferred mechanism:
http://lwn.net/Articles/23634/

> This change set does hide some strong design bugs in dm1105.c and 
> au0828-dvb.c.
> 
> Please revert this change set and do fix the bugs in dm1105.c and 
> au0828-dvb.c (and other
> files).

BTW dm1105.c does use a tasklet for IR keypresses.  However, since it is
only imlemented with one "struct infrared", and hence only one
"ir_command", per device and not a queue, it is possible to lose button
presses that happen very close together.  That probably doesn't matter
practically for IR button presses, but the same strategy cannot be used
for TS packets.

Regards,
Andy

> Regards,
> Hartmut

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REVIEW PATCH 13/14] OMAP: CAM: Add DW9710 Lens Driver

2009-02-01 Thread Alexey Klimov

Hello, guys

Sorry me, answering to old letter. May i suggest two small points
described below ?

On Mon, 2009-01-12 at 20:03 -0600, Aguirre Rodriguez, Sergio Alberto
wrote:
> This adds the DW9710 Lens driver
> 
> Signed-off-by: Sergio Aguirre 
> ---
>  drivers/media/video/Kconfig   |8 +
>  drivers/media/video/Makefile  |1 +
>  drivers/media/video/dw9710.c  |  548 
> +
>  drivers/media/video/dw9710_priv.h |   57 
>  include/media/dw9710.h|   35 +++
>  5 files changed, 649 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/media/video/dw9710.c
>  create mode 100644 drivers/media/video/dw9710_priv.h
>  create mode 100644 include/media/dw9710.h
> 
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 1616c32..10075c3 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -313,6 +313,14 @@ config VIDEO_MT9P012
>   MT9P012 camera.  It is currently working with the TI OMAP3
>   camera controller.
> 
> +config VIDEO_DW9710
> +   tristate "Lens driver for DW9710"
> +   depends on I2C && VIDEO_V4L2
> +   ---help---
> + This is a Video4Linux2 lens driver for the Dongwoon
> + DW9710 coil.  It is currently working with the TI OMAP3
> + camera controller and micron MT9P012 sensor.
> +
>  config VIDEO_SAA7110
> tristate "Philips SAA7110 video decoder"
> depends on VIDEO_V4L1 && I2C
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index f73b65c..41c71d5 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -101,6 +101,7 @@ obj-$(CONFIG_VIDEO_OV7670)  += ov7670.o
> 
>  obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
>  obj-$(CONFIG_VIDEO_MT9P012)+= mt9p012.o
> +obj-$(CONFIG_VIDEO_DW9710) += dw9710.o
> 
>  obj-$(CONFIG_VIDEO_OMAP3) += omap34xxcam.o isp/
> 
> diff --git a/drivers/media/video/dw9710.c b/drivers/media/video/dw9710.c
> new file mode 100644
> index 000..362cb0d
> --- /dev/null
> +++ b/drivers/media/video/dw9710.c
> @@ -0,0 +1,548 @@
> +/*
> + * drivers/media/video/dw9710.c
> + *
> + * DW9710 Coil Motor (LENS) driver
> + *
> + * Copyright (C) 2008 Texas Instruments.
> + *
> + * Contributors:
> + * Troy Laramy 
> + * Mohit Jalori 
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "dw9710_priv.h"
> +
> +static struct dw9710_device dw9710 = {
> +   .state = DW9710_LENS_NOT_DETECTED,
> +   .current_lens_posn = DW9710_DEF_LENS_POSN,
> +};
> +
> +static struct vcontrol {
> +   struct v4l2_queryctrl qc;
> +   int current_value;
> +} video_control[] = {
> +   {
> +   {
> +   .id = V4L2_CID_FOCUS_ABSOLUTE,
> +   .type = V4L2_CTRL_TYPE_INTEGER,
> +   .name = "Focus, Absolute",
> +   .minimum = 0,
> +   .maximum = DW9710_MAX_FOCUS_POS,
> +   .step = DW9710_LENS_POSN_STEP,
> +   .default_value = DW9710_DEF_LENS_POSN,
> +   },
> +   .current_value = DW9710_DEF_LENS_POSN,
> +   }
> +};
> +
> +/**
> + * find_vctrl - Finds the requested ID in the video control structure array
> + * @id: ID of control to search the video control array for
> + *
> + * Returns the index of the requested ID from the control structure array
> + */
> +static int find_vctrl(int id)
> +{
> +   int i;
> +
> +   if (id < V4L2_CID_BASE)
> +   return -EDOM;
> +
> +   for (i = (ARRAY_SIZE(video_control) - 1); i >= 0; i--) {
> +   if (video_control[i].qc.id == id)
> +   return i;
> +   }
> +
> +   return -EINVAL;
> +}
> +
> +/**
> + * dw9710_reg_read - Reads a value from a register in DW9710 Coil driver 
> device.
> + * @client: Pointer to structure of I2C client.
> + * @value: Pointer to u16 for returning value of register to read.
> + *
> + * Returns zero if successful, or non-zero otherwise.
> + **/
> +static int dw9710_reg_read(struct i2c_client *client, u16 *value)
> +{
> +   int err;
> +   struct i2c_msg msg[1];
> +   unsigned char data[2];
> +
> +   if (!client->adapter)
> +   return -ENODEV;
> +
> +   msg->addr = client->addr;
> +   msg->flags = I2C_M_RD;
> +   msg->len = 2;
> +   msg->buf = data;
> +
> +   data[0] = 0;
> +   data[1] = 0;
> +
> +   err = i2c_transfer(client->adapter, msg, 1);
> +
> +   if (err >= 0) {
> +   err = ((data[0] & 0xFF) << 8) | (data[1]);
> +   *value = err;
> +   return 0;
> +   }
> +   r

Re: CinergyT2 not working with newer alternative driver

2009-02-01 Thread Thierry Merle

Jason Harvey wrote:
> Thierry Merle wrote:
>> Hi Jason,
>> Jason Harvey wrote:
>>  
>>> I have been successfully using VDR with two CinergyT2s for 18 months.
>>> After adding a Hauppage NOVA-S2-HD I updated my v4l-dvb drivers hoping
>>> to get S2 capability and test a newer VDR for HD reception.
>>>
>>> The CinergyT2s stopped working. The kernel module loads, the blue leds
>>> flash as expected but they don't lock on to a signal for long.
>>> Signal strength shown in femon is erratic and a lock only rarely
>>> achieved.
>>>
>>> I checked through the mercurial tree to see what had changed.
>>> It looks like the following change is the one that stops the CinergyT2s
>>> working on my system.
>>> http://git.kernel.org/?p=linux/kernel/git/mchehab/devel.git;a=commit;h=986bd1e58b18c09b753f797df19251804bfe3e84
>>>
>>>
>>>
>>> I deleted the newer version of the module and replace it with the
>>> previous deleted code.
>>> Make'd and installed the old version works as expected.
>>>
>>> Machine they're plugged into is running Fedora 10,
>>> 2.6.27.12-170.2.5.fc10.i686
>>> I downloaded the current v4l-dvb today (31Jan2009) and tried it all
>>> again before posting this message.
>>>
>>> Not sure where to look next, I did start to capture the USB traffic to
>>> see if I could spot the difference...
>>>
>>> 
>> Please take a look at the message logs (dmesg).
>> You can follow the instructions described here
>> http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device
>> and report where it fails.
>>
>> I use tzap like this: tzap -c $HOME/.tzap/channels.conf -s -t 120 -r
>> -o output.mpg "SomeChannel"
>> I am able to play with mplayer too.
>> Regards,
>> Thierry
>>   
> Hi Thierry,
> 
> Thank you for the quick reply.
> I should have looked in dmesg before...
> Checking dmesg before I used tzap shows a problem. dvb-usb: recv bulk
> message failed: -110
> 
>  Extract of dmesg 
> 
> dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm
> state.
> dvb-usb: will pass the complete MPEG2 transport stream to the software
> demuxer.
> DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T
> Receiver)
> DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0 Highspeed
> DVB-T Receiver)...
> input: IR-receiver inside an USB DVB receiver as
> /devices/pci:00/:00:1a.7/usb1/1-1/input/input8
> dvb-usb: schedule remote query interval to 50 msecs.
> dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully
> initialized and connected.
> dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm
> state.
> dvb-usb: will pass the complete MPEG2 transport stream to the software
> demuxer.
> DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T
> Receiver)
> DVB: registering adapter 1 frontend 0 (TerraTec/qanu USB2.0 Highspeed
> DVB-T Receiver)...
> input: IR-receiver inside an USB DVB receiver as
> /devices/pci:00/:00:1d.7/usb2/2-5/input/input9
> dvb-usb: schedule remote query interval to 50 msecs.
> dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully
> initialized and connected.
> usbcore: registered new interface driver cinergyT2
> 
> dvb-usb: recv bulk message failed: -110
> dvb-usb: recv bulk message failed: -110
> 
> 
> 
> Running tzap fails to tune/lock
> 
> #tzap -a 0 -c channels.conf_dvbt -s -t 120 -r -o output.mpg "BBC ONE"
> 
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> reading channels from file 'channels.conf_dvbt'
> tuning to 50580 Hz
> video pid 0x0258, audio pid 0x0259
> status 01 | signal c11f | snr  | ber  | unc  |
> 
> No more messages in dmesg.
> 
> I shut down the PC, removed all power, unplugged the CinergyT2s, gave it
> twenty seconds and powered back up.
> Once it had booted I plugged in one of the devices and the dmesg output
> below.
> 
> 
> usb 2-5: new high speed USB device using ehci_hcd and address 3
> usb 2-5: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid
> maxpacket 64
> usb 2-5: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has
> invalid maxpacket 64
> usb 2-5: configuration #1 chosen from 1 choice
> usb 2-5: New USB device found, idVendor=0ccd, idProduct=0038
> usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> usb 2-5: Product: Cinergy T?
> usb 2-5: Manufacturer: TerraTec GmbH
> dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm
> state.
> dvb-usb: will pass the complete MPEG2 transport stream to the software
> demuxer.
> DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T
> Receiver)
> DVB: registering adapter 1 frontend 0 (TerraTec/qanu USB2.0 Highspeed
> DVB-T Receiver)...
> input: IR-receiver inside an USB DVB receiver as
> /devices/pci:00/:00:1d.7/usb2/2-5/input/input9
> dvb-usb: schedule remote query interval to 50 msecs.
> dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully
> initialized and connected.
> usbcore: registered new i

Re: CinergyT2 not working with newer alternative driver

2009-02-01 Thread Jason Harvey

Thierry Merle wrote:

Jason Harvey wrote:

Thierry Merle wrote:

Hi Jason,
Jason Harvey wrote:

I deleted the newer version of the module and replace it with the
previous deleted code.
Make'd and installed the old version works as expected.

Machine they're plugged into is running Fedora 10,
2.6.27.12-170.2.5.fc10.i686
I downloaded the current v4l-dvb today (31Jan2009) and tried it all
again before posting this message.

Not sure where to look next, I did start to capture the USB traffic to
see if I could spot the difference...

Please take a look at the message logs (dmesg).
You can follow the instructions described here
http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device
and report where it fails.

I use tzap like this: tzap -c $HOME/.tzap/channels.conf -s -t 120 -r
-o output.mpg "SomeChannel"
I am able to play with mplayer too.
Regards,
Thierry

Hi Thierry,

Thank you for the quick reply.
I should have looked in dmesg before...
Checking dmesg before I used tzap shows a problem. dvb-usb: recv bulk
message failed: -110

Extract of dmesg

dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm
state.
dvb-usb: will pass the complete MPEG2 transport stream to the software
demuxer.
DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T
Receiver)
DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0 Highspeed
DVB-T Receiver)...
input: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:1a.7/usb1/1-1/input/input8
dvb-usb: schedule remote query interval to 50 msecs.
dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully
initialized and connected.
dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm
state.
dvb-usb: will pass the complete MPEG2 transport stream to the software
demuxer.
DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T
Receiver)
DVB: registering adapter 1 frontend 0 (TerraTec/qanu USB2.0 Highspeed
DVB-T Receiver)...
input: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:1d.7/usb2/2-5/input/input9
dvb-usb: schedule remote query interval to 50 msecs.
dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully
initialized and connected.
usbcore: registered new interface driver cinergyT2

dvb-usb: recv bulk message failed: -110
dvb-usb: recv bulk message failed: -110

Running tzap fails to tune/lock

#tzap -a 0 -c channels.conf_dvbt -s -t 120 -r -o output.mpg "BBC ONE"

No more messages in dmesg.

I shut down the PC, removed all power, unplugged the CinergyT2s, gave it
twenty seconds and powered back up.
Once it had booted I plugged in one of the devices and the dmesg output
below.

usb 2-5: new high speed USB device using ehci_hcd and address 3
usb 2-5: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid
maxpacket 64
usb 2-5: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has
invalid maxpacket 64
usb 2-5: configuration #1 chosen from 1 choice
usb 2-5: New USB device found, idVendor=0ccd, idProduct=0038
usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-5: Product: Cinergy T?
usb 2-5: Manufacturer: TerraTec GmbH
dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm
state.
dvb-usb: will pass the complete MPEG2 transport stream to the software
demuxer.
DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T
Receiver)
DVB: registering adapter 1 frontend 0 (TerraTec/qanu USB2.0 Highspeed
DVB-T Receiver)...
input: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:1d.7/usb2/2-5/input/input9
dvb-usb: schedule remote query interval to 50 msecs.
dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully
initialized and connected.
usbcore: registered new interface driver cinergyT2
dvb-usb: recv bulk message failed: -110

Cannot tzap or scan.

With the old version of the driver I don't have any trouble at all.

I do have this bulk message error too, sometimes (this is a timeout on recv).
I can tune channel

Re: [PATCH 2/2] sh_mobile_ceu: Add FLDPOL operation

On Mon, 2 Feb 2009, morimoto.kunin...@renesas.com wrote:

> > > + value |= common_flags & SOCAM_FLDPOL_ACTIVE_LOW ? 1 << 16 : 0;
> > >   value |= common_flags & SOCAM_VSYNC_ACTIVE_LOW ? 1 << 1 : 0;
> > >   value |= common_flags & SOCAM_HSYNC_ACTIVE_LOW ? 1 << 0 : 0;
> > >   value |= buswidth == 16 ? 1 << 12 : 0;
> > 
> > Why are you basing your decision to use active low or high level of the 
> > Field ID signal upon the platform data? Doesn't it depend on the 
> > configuration of the connected device, and, possibly, an inverter between 
> > them? So, looks like it should be handled in exactly the same way as all 
> > other signals - negotiate with the connected device (sensor / decoder / 
> > ...) and apply platform-defined inverters if any?
> 
> Hmmm.
> 
> The soc_camera framework supports automatic negotiation
> for some type of option.
> But it doesn't include board configuration.
> 
> When board doesn't support Field ID signal,
> we will have to modify driver though camera and host support it. 

Aha, I didn't realise that the Field ID signal was optional. If it is so, 
then yes, you need a platform flag for it, but not for polarity, but for 
availability. And if it is available, connected, and used, then you should 
negotiate its polarity with the camera driver. Makes sense?

> This is the reason.
> 
> I think bus width and field ID are depend on board configuration.
> # May be camera strobe. but I'm not sure

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

Re: [PATCH] sh_mobile_ceu: SOCAM flags are prepared at itself.

On Mon, 2 Feb 2009, morimoto.kunin...@renesas.com wrote:

> > > Guys, are you both sure this should be SLAVE, not MASTER? Have you tested 
> > > it? Both tw9910 and ov772x register themselves as MASTER and from the 
> 
> Of course I tested it.

Yes, as I said, I have overseen the fact, that soc-camera doesn't 
currently check for master / slave mode, so it would work for you even 
with a wrong setting. Sorry again.

> > Ok, sorry, you, probably, did test it and it worked, but just because the 
> > SLAVE / MASTER flag is not tested in soc_camera_bus_param_compatible(), 
> > which I should fix with the next pull, but this does look wrong. Please, 
> > fix.
> 
> Hmm. I should have asked you what is MASTER/SLAVE before sending patch.
> I suspect it it about who generates the clock signal 
> either the camera or the host.
> Our CEU does not support any clock generation so it is always SLAVE.
> Therefore I didn't support MASTER for CEU.
> 
> But it seems wrong understanding...
> I would like ask you What MASTER/SLAVE means ?

MASTER / SLAVE means not the role of the respective device, but the mode. 
Master mode means the camera sensor / decoder / whatever other client is 
the master, i.e., generates the pixel clock and sync signals, the slave 
mode means, that the host generates all sync signals.

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

Re: [PATCH] tw9910: color format check is added on set_fmt

On Mon, 2 Feb 2009, morimoto.kunin...@renesas.com wrote:

> > > Signed-off-by: Kuninori Morimoto 
> > 
> > Why is this needed? Do you see any possibility for tw9910 to be called 
> > with an unsupported format?
> 
> for example,
> capture_example -f use V4L2_PIX_FMT_YUYV.
> but tw9910 support only V4L2_PIX_FMT_VYUY now.

But are you actually getting this set_fmt(V4L2_PIX_FMT_YUYV) in your 
tw9910 driver? If yes, then this is a bug elsewhere. It shouldn't get this 
far. It should be caught earlier along the path

soc_camera_s_fmt_vid_cap()
soc_camera_try_fmt_vid_cap()
sh_mobile_ceu_try_fmt()
soc_camera_xlate_by_fourcc()

> If you think this patch is unnecessary,
> please ignore it.

Could you please test whether you indeed can get an unsupported format in 
your driver. If so, this is a bug at a higher level and we'll have to fix 
it there. I'll drop this patch for now.

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

Re: [PATCH] tw9910: color format check is added on set_fmt