Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver

[Hans Verkuil]

On Tuesday 18 August 2009 08:49:13 Hans Verkuil wrote:
> On Tuesday 18 August 2009 01:23:10 Karicheri, Muralidharan wrote:
> > Hans,
> > 
> > I have re-send vpfe capture patch. I will re-send vpif patches tomorrow.
> 
> These patches apply fine. I'll merge them in my v4l-dvb-dm646x tree tonight.

Oops, wrong tree. It's v4l-dvb-vpif.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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 v1 - 1/5] DaVinci - restructuring code to support vpif capture driver

[Hans Verkuil]

On Tuesday 18 August 2009 01:23:10 Karicheri, Muralidharan wrote:
> Hans,
> 
> I have re-send vpfe capture patch. I will re-send vpif patches tomorrow.

These patches apply fine. I'll merge them in my v4l-dvb-dm646x tree tonight.

Thanks!

Hans

> 
> Murali Karicheri
> Software Design Engineer
> Texas Instruments Inc.
> Germantown, MD 20874
> new phone: 301-407-9583
> Old Phone : 301-515-3736 (will be deprecated)
> email: m-kariche...@ti.com
> 
> >-Original Message-
> >From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> >Sent: Monday, August 17, 2009 4:27 PM
> >To: Karicheri, Muralidharan
> >Cc: linux-media@vger.kernel.org; davinci-linux-open-
> >sou...@linux.davincidsp.com; khil...@deeprootsystems.com
> >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif
> >capture driver
> >
> >On Monday 17 August 2009 22:10:04 Karicheri, Muralidharan wrote:
> >> Hans,
> >>
> >> Would you like the architecture specific changes against v4l-dvb linux-
> >next tree or linux-davinci ? I will rework both the vpfe and vpif patches
> >as per your comment.
> >
> >v4l-dvb linux-next. The current v4l-dvb at least compiles against that one,
> >so
> >that is the most appropriate tree to do the patches against.
> >
> >Regards,
> >
> > Hans
> >
> >--
> >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
> 
> 
> 
> 



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: KWorld UB435-Q support?

[Thomas Fjellstrom]

On Mon August 17 2009, Jarod Wilson wrote:
> On Aug 17, 2009, at 3:28 PM, Thomas Fjellstrom wrote:
> > Yeah, I've had absolutely no luck with it so far, and have returned
> > it :(
> > given your experience, and mine combined, I don't think its worth
> > the time to
> > fix it. Especially since I can't even tune a channel on the darn
> > thing in any
> > OS I have access to.
>
> Now, did you try it with some other OS before trying it under Linux,
> and it failed to work, or did you only try other OS after trying under
> Linux w/that tree? There's some concern that perhaps the stick might
> be getting neutered on the Linux side by an incorrect gpio setting or
> something... But my stick worked (flaky usb connection aside) for
> quite some time before it stopped working, even with lots of
> unplugging and replugging over several days while working on the
> driver...

I may have plugged it in in linux before windows, but at that point I didn't 
have the drivers for linux installed, so I doubt incorrect gpio settings could 
have damaged it.

> > It did indeed have trouble keeping a connection, but when ever it lost
> > connection, I got that message. And the driver is pretty much stuck.
> > can't
> > rmmod it, and it won't redetect the stick, so every single time it
> > looses
> > connection, I have to reboot. Hardly a good way to work.
>
> Indeed. I wonder if there are bad solder joints in these, or what?...
> Mine's dead, yours is dead, Mike Krufky had to RMA his first one and
> his second one seems it might be dead too... :\

I dunno, but I'm thinking of just getting a HVR 1800 or similar. Go with my 
two PVR 150's that work flawlessly.

-- 
Thomas Fjellstrom
tfjellst...@shaw.ca
--
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: KWorld UB435-Q support?

[Jarod Wilson]

On Aug 17, 2009, at 3:28 PM, Thomas Fjellstrom wrote:

Yeah, I've had absolutely no luck with it so far, and have returned  
it :(
given your experience, and mine combined, I don't think its worth  
the time to
fix it. Especially since I can't even tune a channel on the darn  
thing in any

OS I have access to.


Now, did you try it with some other OS before trying it under Linux,  
and it failed to work, or did you only try other OS after trying under  
Linux w/that tree? There's some concern that perhaps the stick might  
be getting neutered on the Linux side by an incorrect gpio setting or  
something... But my stick worked (flaky usb connection aside) for  
quite some time before it stopped working, even with lots of  
unplugging and replugging over several days while working on the  
driver...



It did indeed have trouble keeping a connection, but when ever it lost
connection, I got that message. And the driver is pretty much stuck.  
can't
rmmod it, and it won't redetect the stick, so every single time it  
looses

connection, I have to reboot. Hardly a good way to work.


Indeed. I wonder if there are bad solder joints in these, or what?...  
Mine's dead, yours is dead, Mike Krufky had to RMA his first one and  
his second one seems it might be dead too... :\


--
Jarod Wilson
ja...@wilsonet.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: Pinnacle 300i antenna power kernel oops

[hermann pitton]

Hi Martin,

Am Sonntag, den 16.08.2009, 11:53 +0200 schrieb Martin Konopka:
> Hi,
> 
> after my failed attempts to activate the external antenna power on an 
> Pinnacle 
> 310i, I bought a 300i. When I load the module saa7134_dvb with the option 
> antenna_pwr = 1 I can indeed measure a voltage at the HF-Socket. But when my 
> tv application tries to access the DVB device, I get a kernel oops. I have 
> attached the log messages below. I'm using kernel 2.6.28-11-generic SMP 
> i686 .
> 
> The card works perfectly when the antenna power is disabled.
> 
> Thanks for your help!
> 
> Martin


did not try to analyze the oops yet, but since the driver code for this
card is unchanged since years, I suspect it happens on a higher level.

You might try, if it still happens with recent v4l-dvb stuff.

In that case, Michael Krufky eventually can confirm it, since he is the
only one active on the lists currently having such a card.

Depending on what other stuff he is working on, this might be still time
consuming and an annoyance for him, but maybe he will have a look ;)

Btw, I received an used Pinnacle 310i this afternoon, since I'm a little
bit stuffed with mysteries on such.

First impression on recent:

The massive silver remote works, sometimes the driver fails to read the
eeprom on load. Else, it has 100% the same reception quality for analog
TV and DVB-T like all my other cards with tda8275a and without LNA
support and is totally stable.

I suspect now, that it is like on the HVR1110s currently, that we might
have already different models with and without LNA there too.

Cheers,
Hermann

> 
> [   22.556260] BUG: unable to handle kernel paging request at f84b92d0
> [   22.556349] IP: [] pinnacle_antenna_pwr+0xda/0x140 [saa7134_dvb]
> [   22.556412] *pde = 35d3f067 *pte = 
> [   22.556416] Oops:  [#1] SMP
> [   22.556500] last sysfs file: /sys/devices/virtual/net/pan0/flags
> [   22.556532] Dumping ftrace buffer:
> [   22.556563](ftrace buffer empty)
> [   22.556592] Modules linked in: bridge stp bnep video output input_polldev 
> nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc xfs it87 hwmon_vid lp 
> mt352 saa7134_dvb videobuf_dvb dvb_core saa7134_alsa mt20xx tea5767 tda9887 
> tda8290 tuner snd_seq_dummy snd_seq_oss snd_hda_intel snd_seq_midi saa7134 
> snd_rawmidi snd_seq_midi_event snd_pcm_oss snd_mixer_oss ir_common snd_pcm 
> videodev snd_seq fglrx(P) v4l1_compat compat_ioctl32 agpgart snd_seq_device 
> snd_timer ppdev pcspkr i2c_piix4 v4l2_common videobuf_dma_sg videobuf_core 
> tveeprom shpchp snd soundcore snd_page_alloc parport_pc parport usbhid floppy 
> ohci1394 r8169 mii ieee1394 fbcon tileblit font bitblit softcursor
> [   22.558582]
> [   22.558612] Pid: 3361, comm: kdvb-ad-0-fe-0 Tainted: P   
> (2.6.28-11-generic #42-Ubuntu) System Product Name
> [   22.558646] EIP: 0060:[] EFLAGS: 00010282 CPU: 1
> [   22.558678] EIP is at pinnacle_antenna_pwr+0xda/0x140 [saa7134_dvb]
> [   22.558710] EAX: f84b92d0 EBX: f5dd3000 ECX: 0165f000 EDX: 001b
> [   22.558741] ESI: f5dd3000 EDI: f5dd3140 EBP: f5f4fe9c ESP: f5f4fe84
> [   22.558772]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
> [   22.558803] Process kdvb-ad-0-fe-0 (pid: 3361, ti=f5f4e000 task=f5a0d7f0 
> task.ti=f5f4e000)
> [   22.558837] Stack:
> [   22.558867]  c03e7a3d 0001 f5f4fed0 f5c4d404 f5c4d404 f5dd3000 
> f5f4feec 
> f7e837af
> [   22.559090]   0003 25a0 c012888f f5a0d7f0 f5b48c90 
> f5f4fee4 
> c0102ab7
> [   22.559369]  f5a0db2c c1e18280 f5f4feec 0043 c1e10002 f5f4fedc 
> f1007100 
> f1cc
> [   22.559677] Call Trace:
> [   22.559707]  [] ? i2c_transfer+0x6d/0x90
> [   22.559770]  [] ? mt352_pinnacle_tuner_set_params+0xcf/0xe0 
> [saa7134_dvb]
> [   22.559834]  [] ? dequeue_task+0xcf/0x130
> [   22.559894]  [] ? __switch_to+0xb7/0x1a0
> [   22.559954]  [] ? mt352_set_parameters+0x2d8/0x410 [mt352]
> [   22.560020]  [] ? default_spin_lock_flags+0x8/0x10
> [   22.560081]  [] ? _spin_lock_irqsave+0x2e/0x40
> [   22.560142]  [] ? dvb_frontend_swzigzag_autotune+0xc1/0x240 
> [dvb_core]
> [   22.560202]  [] ? schedule_timeout+0x86/0xe0
> [   22.560202]  [] ? process_timeout+0x0/0x10
> [   22.560202]  [] ? dvb_frontend_swzigzag+0x221/0x270 [dvb_core]
> [   22.560202]  [] ? dvb_frontend_thread+0x397/0x440 [dvb_core]
> [   22.560202]  [] ? autoremove_wake_function+0x0/0x50
> [   22.560202]  [] ? dvb_frontend_thread+0x0/0x440 [dvb_core]
> [   22.560202]  [] ? kthread+0x3c/0x70
> [   22.560202]  [] ? kthread+0x0/0x70
> [   22.560202]  [] ? kernel_thread_helper+0x7/0x10
> [   22.560202] Code: c8 8b 93 20 01 00 00 81 c2 b4 01 00 00 8b 02 0d 00 00 00 
> 10 89 02 b8 c6 a7 00 00 e8 91 96 44 c8 8b 83 20 01 00 00 05 d0 06 00 00 <8b> 
> 30 a1 88 7f e8 f7 81 e6 00 00 00 08 85 c0 75 22 85 f6 75 15
> [   22.560202] EIP: [] pinnacle_antenna_pwr+0xda/0x140 
> [saa7134_dvb] 
> SS:ESP 0068:f5f4fe84


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majo

RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver

[Karicheri, Muralidharan]

Hans,

I have re-send vpfe capture patch. I will re-send vpif patches tomorrow.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com

>-Original Message-
>From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>Sent: Monday, August 17, 2009 4:27 PM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; davinci-linux-open-
>sou...@linux.davincidsp.com; khil...@deeprootsystems.com
>Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif
>capture driver
>
>On Monday 17 August 2009 22:10:04 Karicheri, Muralidharan wrote:
>> Hans,
>>
>> Would you like the architecture specific changes against v4l-dvb linux-
>next tree or linux-davinci ? I will rework both the vpfe and vpif patches
>as per your comment.
>
>v4l-dvb linux-next. The current v4l-dvb at least compiles against that one,
>so
>that is the most appropriate tree to do the patches against.
>
>Regards,
>
>   Hans
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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 - v3] Adding new fields to add the vpfe capture enhancements

[Karicheri, Muralidharan]

Please ignore this since v4l prefix is missing in the subject.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com

>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Monday, August 17, 2009 7:19 PM
>To: linux-media@vger.kernel.org
>Cc: davinci-linux-open-sou...@linux.davincidsp.com; hverk...@xs4all.nl;
>Karicheri, Muralidharan
>Subject: [PATCH 1/5 - v3] Adding new fields to add the vpfe capture
>enhancements
>
>From: Muralidharan Karicheri 
>
>Restructured the patch to apply cleanly. This will allow compilation after
>applying each patch. To do this existing fields in the header files are
>retained and removed later when the new fields are used.
>
>Reviewed-by: Hans Verkuil 
>
>Signed-off-by: Muralidharan Karicheri 
>---
>Applies to V4L-DVB linux-next repository
> include/media/davinci/vpfe_capture.h |   27 ---
> 1 files changed, 24 insertions(+), 3 deletions(-)
>
>diff --git a/include/media/davinci/vpfe_capture.h
>b/include/media/davinci/vpfe_capture.h
>index 71d8982..196245e 100644
>--- a/include/media/davinci/vpfe_capture.h
>+++ b/include/media/davinci/vpfe_capture.h
>@@ -47,6 +47,8 @@ struct vpfe_pixel_format {
>   struct v4l2_fmtdesc fmtdesc;
>   /* bytes per pixel */
>   int bpp;
>+  /* decoder format */
>+  u32 subdev_pix_fmt;
> };
>
> struct vpfe_std_info {
>@@ -61,9 +63,16 @@ struct vpfe_route {
>   u32 output;
> };
>
>+enum vpfe_subdev_id {
>+  VPFE_SUBDEV_TVP5146 = 1,
>+  VPFE_SUBDEV_MT9T031 = 2
>+};
>+
> struct vpfe_subdev_info {
>-  /* Sub device name */
>+  /* Deprecated. Will be removed in the next patch */
>   char name[32];
>+  /* Sub device module name */
>+  char module_name[32];
>   /* Sub device group id */
>   int grp_id;
>   /* Number of inputs supported */
>@@ -72,12 +81,16 @@ struct vpfe_subdev_info {
>   struct v4l2_input *inputs;
>   /* Sub dev routing information for each input */
>   struct vpfe_route *routes;
>-  /* check if sub dev supports routing */
>-  int can_route;
>   /* ccdc bus/interface configuration */
>   struct vpfe_hw_if_param ccdc_if_params;
>   /* i2c subdevice board info */
>   struct i2c_board_info board_info;
>+  /* Is this a camera sub device ? */
>+  unsigned is_camera:1;
>+  /* check if sub dev supports routing */
>+  unsigned can_route:1;
>+  /* registered ? */
>+  unsigned registered:1;
> };
>
> struct vpfe_config {
>@@ -92,6 +105,12 @@ struct vpfe_config {
>   /* vpfe clock */
>   struct clk *vpssclk;
>   struct clk *slaveclk;
>+  /* setup function for the input path */
>+  int (*setup_input)(enum vpfe_subdev_id id);
>+  /* number of clocks */
>+  int num_clocks;
>+  /* clocks used for vpfe capture */
>+  char *clocks[];
> };
>
> struct vpfe_device {
>@@ -102,6 +121,8 @@ struct vpfe_device {
>   struct v4l2_subdev **sd;
>   /* vpfe cfg */
>   struct vpfe_config *cfg;
>+  /* clock ptrs for vpfe capture */
>+  struct clk **clks;
>   /* V4l2 device */
>   struct v4l2_device v4l2_dev;
>   /* parent device */
>--
>1.6.0.4

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

[PATCH 1/5 - v3]V4L: vpfe capture - adding new fields for vpfe capture enhancements

[m-karicheri2]

From: Muralidharan Karicheri 

Resending with V4L prefix.

Restructured the patch to apply cleanly. This will allow compilation after
applying each patch. To do this existing fields in the header files are
retained and removed later when the new fields are used.

Reviewed-by: Hans Verkuil 

Signed-off-by: Muralidharan Karicheri 
---
Applies to V4L-DVB linux-next repository
 include/media/davinci/vpfe_capture.h |   27 ---
 1 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/include/media/davinci/vpfe_capture.h 
b/include/media/davinci/vpfe_capture.h
index 71d8982..196245e 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -47,6 +47,8 @@ struct vpfe_pixel_format {
struct v4l2_fmtdesc fmtdesc;
/* bytes per pixel */
int bpp;
+   /* decoder format */
+   u32 subdev_pix_fmt;
 };
 
 struct vpfe_std_info {
@@ -61,9 +63,16 @@ struct vpfe_route {
u32 output;
 };
 
+enum vpfe_subdev_id {
+   VPFE_SUBDEV_TVP5146 = 1,
+   VPFE_SUBDEV_MT9T031 = 2
+};
+
 struct vpfe_subdev_info {
-   /* Sub device name */
+   /* Deprecated. Will be removed in the next patch */
char name[32];
+   /* Sub device module name */
+   char module_name[32];
/* Sub device group id */
int grp_id;
/* Number of inputs supported */
@@ -72,12 +81,16 @@ struct vpfe_subdev_info {
struct v4l2_input *inputs;
/* Sub dev routing information for each input */
struct vpfe_route *routes;
-   /* check if sub dev supports routing */
-   int can_route;
/* ccdc bus/interface configuration */
struct vpfe_hw_if_param ccdc_if_params;
/* i2c subdevice board info */
struct i2c_board_info board_info;
+   /* Is this a camera sub device ? */
+   unsigned is_camera:1;
+   /* check if sub dev supports routing */
+   unsigned can_route:1;
+   /* registered ? */
+   unsigned registered:1;
 };
 
 struct vpfe_config {
@@ -92,6 +105,12 @@ struct vpfe_config {
/* vpfe clock */
struct clk *vpssclk;
struct clk *slaveclk;
+   /* setup function for the input path */
+   int (*setup_input)(enum vpfe_subdev_id id);
+   /* number of clocks */
+   int num_clocks;
+   /* clocks used for vpfe capture */
+   char *clocks[];
 };
 
 struct vpfe_device {
@@ -102,6 +121,8 @@ struct vpfe_device {
struct v4l2_subdev **sd;
/* vpfe cfg */
struct vpfe_config *cfg;
+   /* clock ptrs for vpfe capture */
+   struct clk **clks;
/* V4l2 device */
struct v4l2_device v4l2_dev;
/* parent device */
-- 
1.6.0.4

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

[PATCH 5/5 - v3] V4L: ccdc driver - adding support for camera capture

[m-karicheri2]

From: Muralidharan Karicheri 

Recreating this to apply cleanly and compile

There was no comment against v1 of the patch. So no change in this file

Reviewed-by: Hans Verkuil 

Signed-off-by: Muralidharan Karicheri 
---
Applies to V4L-DVB linux-next repository
 drivers/media/video/davinci/dm355_ccdc.c  |   16 +++-
 drivers/media/video/davinci/dm644x_ccdc.c |   13 +
 include/media/davinci/dm355_ccdc.h|2 +-
 include/media/davinci/dm644x_ccdc.h   |2 +-
 4 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/media/video/davinci/dm355_ccdc.c 
b/drivers/media/video/davinci/dm355_ccdc.c
index 4629cab..4efffc2 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -92,7 +92,7 @@ static struct ccdc_params_raw ccdc_hw_params_raw = {
 
 /* Object for CCDC ycbcr mode */
 static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
-   .win = CCDC_WIN_PAL,
+   .win = CCDC_WIN_NTSC,
.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
.frm_fmt = CCDC_FRMFMT_INTERLACED,
.fid_pol = VPFE_PINPOL_POSITIVE,
@@ -548,7 +548,7 @@ static int ccdc_config_vdfc(struct ccdc_vertical_dft *dfc)
  */
 static void ccdc_config_csc(struct ccdc_csc *csc)
 {
-   u32 val1, val2;
+   u32 val1 = 0, val2;
int i;
 
if (!csc->enable)
@@ -925,8 +925,11 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param 
*params)
ccdc_hw_params_ycbcr.vd_pol = params->vdpol;
ccdc_hw_params_ycbcr.hd_pol = params->hdpol;
break;
+   case VPFE_RAW_BAYER:
+   ccdc_hw_params_raw.vd_pol = params->vdpol;
+   ccdc_hw_params_raw.hd_pol = params->hdpol;
+   break;
default:
-   /* TODO add support for raw bayer here */
return -EINVAL;
}
return 0;
@@ -961,9 +964,12 @@ static struct ccdc_hw_device ccdc_hw_dev = {
 
 static int dm355_ccdc_init(void)
 {
+   int ret;
+
printk(KERN_NOTICE "dm355_ccdc_init\n");
-   if (vpfe_register_ccdc_device(&ccdc_hw_dev) < 0)
-   return -1;
+   ret = vpfe_register_ccdc_device(&ccdc_hw_dev);
+   if (ret < 0)
+   return ret;
printk(KERN_NOTICE "%s is registered with vpfe.\n",
ccdc_hw_dev.name);
return 0;
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c 
b/drivers/media/video/davinci/dm644x_ccdc.c
index 2f19a91..5dff8d9 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -65,7 +65,7 @@ static struct ccdc_params_raw ccdc_hw_params_raw = {
 static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
.frm_fmt = CCDC_FRMFMT_INTERLACED,
-   .win = CCDC_WIN_PAL,
+   .win = CCDC_WIN_NTSC,
.fid_pol = VPFE_PINPOL_POSITIVE,
.vd_pol = VPFE_PINPOL_POSITIVE,
.hd_pol = VPFE_PINPOL_POSITIVE,
@@ -825,8 +825,10 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param 
*params)
ccdc_hw_params_ycbcr.vd_pol = params->vdpol;
ccdc_hw_params_ycbcr.hd_pol = params->hdpol;
break;
+   case VPFE_RAW_BAYER:
+   ccdc_hw_params_raw.vd_pol = params->vdpol;
+   ccdc_hw_params_raw.hd_pol = params->hdpol;
default:
-   /* TODO add support for raw bayer here */
return -EINVAL;
}
return 0;
@@ -861,9 +863,12 @@ static struct ccdc_hw_device ccdc_hw_dev = {
 
 static int dm644x_ccdc_init(void)
 {
+   int ret;
+
printk(KERN_NOTICE "dm644x_ccdc_init\n");
-   if (vpfe_register_ccdc_device(&ccdc_hw_dev) < 0)
-   return -1;
+   ret = vpfe_register_ccdc_device(&ccdc_hw_dev);
+   if (ret < 0)
+   return ret;
printk(KERN_NOTICE "%s is registered with vpfe.\n",
ccdc_hw_dev.name);
return 0;
diff --git a/include/media/davinci/dm355_ccdc.h 
b/include/media/davinci/dm355_ccdc.h
index df8a7b1..9395900 100644
--- a/include/media/davinci/dm355_ccdc.h
+++ b/include/media/davinci/dm355_ccdc.h
@@ -254,7 +254,7 @@ struct ccdc_config_params_raw {
 #ifdef __KERNEL__
 #include 
 
-#define CCDC_WIN_PAL   {0, 0, 720, 576}
+#define CCDC_WIN_NTSC  {0, 0, 720, 480}
 #define CCDC_WIN_VGA   {0, 0, 640, 480}
 
 struct ccdc_params_ycbcr {
diff --git a/include/media/davinci/dm644x_ccdc.h 
b/include/media/davinci/dm644x_ccdc.h
index 3e178eb..e34a54a 100644
--- a/include/media/davinci/dm644x_ccdc.h
+++ b/include/media/davinci/dm644x_ccdc.h
@@ -131,7 +131,7 @@ struct ccdc_config_params_raw {
 #define NUM_EXTRALINES 8
 
 /* settings for commonly used video formats */
-#define CCDC_WIN_PAL {0, 0, 720, 576}
+#define CCDC_WIN_NTSC {0, 0, 720, 480}
 /* ntsc square pixel */
 #define CCDC_WIN_VGA   {0, 0, (640 + NUM_EXTRAPIXELS), (480 + NUM_EXTRALINES)}
 
-- 
1.6.0.4

--
To unsubscribe from this list: sen

[PATCH 4/5 - v3] V4L-vpfe capture driver - adding support for camera capture

[m-karicheri2]

From: Muralidharan Karicheri 

Recreating this patch to apply cleanly and compile.

v2 of the patch incorporated following comments received against v1 patch 
series. 
1) retained vpfe_g_std() since for vbi support g_std handling in v4l2 
framework
   is not sufficient.
2) rename name field in vpfe_subdev_info to module_name and camera to 
is_camera.
   also grouped bit field variables

Additional features added on top v1 patch:-
2) vpfe_enable/disable_clock restructered to allow configuration of 
required
   clocks in vpfe_capture configuration. This is required for upcoming 
DM365
   support.

Reviewed-by: Hans Verkuil 
Signed-off-by: Muralidharan Karicheri 
---
Applies to V4L-DVB linux-next repository
 drivers/media/video/davinci/vpfe_capture.c |  545 +---
 include/media/davinci/vpfe_capture.h   |5 -
 2 files changed, 413 insertions(+), 137 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c 
b/drivers/media/video/davinci/vpfe_capture.c
index 402ce43..ff43446 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -59,10 +59,8 @@
  *TODO list
  * - Support multiple REQBUF after open
  * - Support for de-allocating buffers through REQBUF
- * - Support for Raw Bayer RGB capture
  * - Support for chaining Image Processor
  * - Support for static allocation of buffers
- * - Support for USERPTR IO
  * - Support for STREAMON before QBUF
  * - Support for control ioctls
  */
@@ -79,11 +77,24 @@
 static int debug;
 static u32 numbuffers = 3;
 static u32 bufsize = (720 * 576 * 2);
+static int interface;
 
+module_param(interface, bool, S_IRUGO);
 module_param(numbuffers, uint, S_IRUGO);
 module_param(bufsize, uint, S_IRUGO);
-module_param(debug, int, 0644);
-
+module_param(debug, bool, 0644);
+
+/**
+ * VPFE capture can be used for capturing video such as from TVP5146 or TVP7002
+ * and for capture raw bayer data from camera sensors such as MT9T031. At this
+ * point there is problem in co-existence of mt9t031 and tvp5146 due to i2c
+ * address collision. So set the variable below from bootargs to do either 
video
+ * capture or camera capture.
+ * interface = 0 - video capture (from TVP514x or such),
+ * interface = 1 - Camera capture (from MT9T031 or such)
+ * Re-visit this when we fix the co-existence issue
+ */
+MODULE_PARM_DESC(interface, "interface 0-1 (default:0)");
 MODULE_PARM_DESC(numbuffers, "buffer count (default:3)");
 MODULE_PARM_DESC(bufsize, "buffer size in bytes (default:720 x 576 x 2)");
 MODULE_PARM_DESC(debug, "Debug level 0-1");
@@ -143,6 +154,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR8,
},
.bpp = 1,
+   .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -152,6 +164,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR16,
},
.bpp = 2,
+   .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -161,6 +174,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SGRBG10DPCM8,
},
.bpp = 1,
+   .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -170,6 +184,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_UYVY,
},
.bpp = 2,
+   .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -179,6 +194,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_YUYV,
},
.bpp = 2,
+   .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -188,12 +204,15 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_NV12,
},
.bpp = 1,
+   .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
 };
 
-/*
- * vpfe_lookup_pix_format()
- * lookup an entry in the vpfe pix format table based on pix_format
+/**
+ * vpfe_lookup_pix_format() - lookup an entry in the vpfe pix format table
+ * @pix_format: v4l pix format
+ * This function lookup an entry in the vpfe pix format table based on
+ * pix_format
  */
 static const struct vpfe_pixel_format *vpfe_lookup_pix_format(u32 pix_format)
 {
@@ -241,19 +260,19 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
 * walk through it during vpfe probe
 */

[PATCH 3/5 - v3] DaVinci: platform changes to support vpfe camera capture Signed-off-by: Muralidharan Karicheri

[m-karicheri2]

From: Muralidharan Karicheri 

Recreating the patch to apply cleanly and compile.

There were no comments against v1 of this patch. So no change from v1/v2 of 
this patch

Reviewed-by: Hans Verkuil 

Signed-off-by: Muralidharan Karicheri 
---
Applies to V4L-DVB linux-next repository
 arch/arm/mach-davinci/board-dm355-evm.c  |  140 +-
 arch/arm/mach-davinci/board-dm644x-evm.c |6 +-
 2 files changed, 140 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index 605bf03..8f2842a 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -136,14 +137,58 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
 }
 
+#define PCA9543A_I2C_ADDR   (0x73)
+
+static struct i2c_client *pca9543a;
+
+static int pca9543a_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   pca9543a = client;
+   return 0;
+}
+
+static int pca9543a_remove(struct i2c_client *client)
+{
+   pca9543a = NULL;
+   return 0;
+}
+
+static const struct i2c_device_id pca9543a_ids[] = {
+   { "PCA9543A", 0, },
+   { /* end of list */ },
+};
+
+/* This is for i2c driver for the MT9T031 header i2c switch */
+static struct i2c_driver pca9543a_driver = {
+   .driver.name= "PCA9543A",
+   .id_table   = pca9543a_ids,
+   .probe  = pca9543a_probe,
+   .remove = pca9543a_remove,
+};
+
 static struct i2c_board_info dm355evm_i2c_info[] = {
{   I2C_BOARD_INFO("dm355evm_msp", 0x25),
.platform_data = dm355evm_mmcsd_gpios,
},
+   {
+   I2C_BOARD_INFO("PCA9543A", 0x73),
+   },
/* { plus irq  }, */
/* { I2C_BOARD_INFO("tlv320aic3x", 0x1b), }, */
 };
 
+/* have_sensor() - Check if we have support for sensor interface */
+static inline int have_sensor(void)
+{
+#if defined(CONFIG_SOC_CAMERA_MT9T031) || \
+defined(CONFIG_SOC_CAMERA_MT9T031_MODULE)
+   return 1;
+#else
+   return 0;
+#endif
+}
+
 static void __init evm_init_i2c(void)
 {
davinci_init_i2c(&i2c_pdata);
@@ -151,7 +196,8 @@ static void __init evm_init_i2c(void)
gpio_request(5, "dm355evm_msp");
gpio_direction_input(5);
dm355evm_i2c_info[0].irq = gpio_to_irq(5);
-
+   if (have_sensor())
+   i2c_add_driver(&pca9543a_driver);
i2c_register_board_info(1, dm355evm_i2c_info,
ARRAY_SIZE(dm355evm_i2c_info));
 }
@@ -180,6 +226,72 @@ static struct platform_device dm355evm_dm9000 = {
.num_resources  = ARRAY_SIZE(dm355evm_dm9000_rsrc),
 };
 
+/**
+ * dm355_enable_i2c_switch() - Enable/Disable I2C switch PCA9543A for sensor
+ * @en: enable/disbale flag
+ */
+static int dm355evm_enable_i2c_switch(int en)
+{
+   static char val = 1;
+   int status;
+   struct i2c_msg msg = {
+   .flags = 0,
+   .len = 1,
+   .buf = &val,
+   };
+
+   if (!en)
+   val = 0;
+
+   if (!pca9543a)
+   return -ENXIO;
+
+   msg.addr = pca9543a->addr;
+   /* turn i2c switch, pca9543a, on/off */
+   status = i2c_transfer(pca9543a->adapter, &msg, 1);
+   return status;
+}
+
+/**
+ * dm355evm_setup_video_input() - setup video data path and i2c
+ * @id: sub device id
+ */
+static int dm355evm_setup_video_input(enum vpfe_subdev_id id)
+{
+   int ret;
+
+   switch (id) {
+   case VPFE_SUBDEV_MT9T031:
+   {
+   ret = dm355evm_msp_write(MSP_VIDEO_IMAGER,
+DM355EVM_MSP_VIDEO_IN);
+   if (ret >= 0)
+   ret = dm355evm_enable_i2c_switch(1);
+   else
+   /* switch off i2c switch since we failed */
+   ret = dm355evm_enable_i2c_switch(0);
+   break;
+   }
+   case VPFE_SUBDEV_TVP5146:
+   {
+   ret = dm355evm_msp_write(0, DM355EVM_MSP_VIDEO_IN);
+   break;
+   }
+   default:
+   return -EINVAL;
+   }
+   return (ret >= 0 ? 0 : ret);
+}
+
+/* Input available at the mt9t031 */
+static struct v4l2_input mt9t031_inputs[] = {
+   {
+   .index = 0,
+   .name = "Camera",
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   }
+};
+
 static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -203,7 +315,7 @@ static struct v4l2_input tvp5146_inputs[] = {
},
 };
 
-/*
+/**
  * this is the route info for connecting each input to decoder
  * ouput that goes to vpfe. There is a one to one correspondence
  * with tvp5146_inputs
@@ -221,8 +333,8 @@ static struct vpfe_route tvp5146_routes[] = {
 
 static st

[PATCH 2/5 - v3] V4L: ccdc driver - select MSP driver for CCDC input selection

[m-karicheri2]

From: Muralidharan Karicheri 

Just being recreated to apply cleanly and compile.

There were no comments against v1 of this patch. So no change from v1/v2 of the 
patch

Reviewed-by: Hans Verkuil 

Signed-off-by: Muralidharan Karicheri 
---
Applies to V4L-DVB linux-next repository
 drivers/media/video/Kconfig |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index e8a6e4d..1fa3c87 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -565,13 +565,15 @@ config VIDEO_DM355_CCDC
tristate "DM355 CCDC HW module"
depends on ARCH_DAVINCI_DM355 && VIDEO_VPFE_CAPTURE
select VIDEO_VPSS_SYSTEM
+   select MFD_DM355EVM_MSP
default y
help
   Enables DM355 CCD hw module. DM355 CCDC hw interfaces
   with decoder modules such as TVP5146 over BT656 or
   sensor module such as MT9T001 over a raw interface. This
   module configures the interface and CCDC/ISIF to do
-  video frame capture from a slave decoders
+  video frame capture from a slave decoders. MFD_DM355EVM_MSP
+  is enabled to select input to CCDC at run time.
 
   To compile this driver as a module, choose M here: the
   module will be called vpfe.
-- 
1.6.0.4

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

[PATCH 1/5 - v3] Adding new fields to add the vpfe capture enhancements

[m-karicheri2]

From: Muralidharan Karicheri 

Restructured the patch to apply cleanly. This will allow compilation after
applying each patch. To do this existing fields in the header files are
retained and removed later when the new fields are used.

Reviewed-by: Hans Verkuil 

Signed-off-by: Muralidharan Karicheri 
---
Applies to V4L-DVB linux-next repository
 include/media/davinci/vpfe_capture.h |   27 ---
 1 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/include/media/davinci/vpfe_capture.h 
b/include/media/davinci/vpfe_capture.h
index 71d8982..196245e 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -47,6 +47,8 @@ struct vpfe_pixel_format {
struct v4l2_fmtdesc fmtdesc;
/* bytes per pixel */
int bpp;
+   /* decoder format */
+   u32 subdev_pix_fmt;
 };
 
 struct vpfe_std_info {
@@ -61,9 +63,16 @@ struct vpfe_route {
u32 output;
 };
 
+enum vpfe_subdev_id {
+   VPFE_SUBDEV_TVP5146 = 1,
+   VPFE_SUBDEV_MT9T031 = 2
+};
+
 struct vpfe_subdev_info {
-   /* Sub device name */
+   /* Deprecated. Will be removed in the next patch */
char name[32];
+   /* Sub device module name */
+   char module_name[32];
/* Sub device group id */
int grp_id;
/* Number of inputs supported */
@@ -72,12 +81,16 @@ struct vpfe_subdev_info {
struct v4l2_input *inputs;
/* Sub dev routing information for each input */
struct vpfe_route *routes;
-   /* check if sub dev supports routing */
-   int can_route;
/* ccdc bus/interface configuration */
struct vpfe_hw_if_param ccdc_if_params;
/* i2c subdevice board info */
struct i2c_board_info board_info;
+   /* Is this a camera sub device ? */
+   unsigned is_camera:1;
+   /* check if sub dev supports routing */
+   unsigned can_route:1;
+   /* registered ? */
+   unsigned registered:1;
 };
 
 struct vpfe_config {
@@ -92,6 +105,12 @@ struct vpfe_config {
/* vpfe clock */
struct clk *vpssclk;
struct clk *slaveclk;
+   /* setup function for the input path */
+   int (*setup_input)(enum vpfe_subdev_id id);
+   /* number of clocks */
+   int num_clocks;
+   /* clocks used for vpfe capture */
+   char *clocks[];
 };
 
 struct vpfe_device {
@@ -102,6 +121,8 @@ struct vpfe_device {
struct v4l2_subdev **sd;
/* vpfe cfg */
struct vpfe_config *cfg;
+   /* clock ptrs for vpfe capture */
+   struct clk **clks;
/* V4l2 device */
struct v4l2_device v4l2_dev;
/* parent device */
-- 
1.6.0.4

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

Re: [PATCH] quickcam_messenger.c: add support for all quickcam Messengers of the same family

[Brandon Philips]

On 21:33 Sun 16 Aug 2009, Mauro Carvalho Chehab wrote:
> Could you please check if stv06xx.c is properly working with those devices?
> Feel free to submit patches improving it, if needed.

Alright, I asked the two users who reported the bug to test
gspca_stv06xx.ko also. I will let you know how that goes.

Cheers,

Brandon
--
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] au0828: experimental support for Syntek Teledongle [05e1:0400]

[Malcolm Lewis]

On Mon, Aug 17, 2009 at 3:59 PM, Michael Krufky wrote:
> On Mon, Aug 17, 2009 at 4:25 PM, Malcolm Lewis wrote:
>> Hi
>> I've been using the patches from
>> http://linuxtv.org/hg/~mkrufky/teledongle/rev/676e2f4475ed
>> on a Sabrent device in openSuSE and SLED, during testing with the
>> milestone 5 release of
>> 11.2 and kernel version 2.6.31-rc5-git3-2-desktop there needs to be
>> some changes to the
>> au0828-cards.c patch to enable building a kmp module;
>>
>> --- au0828-cards.c    2009-08-12 18:16:39.435886920 -0500
>> +++ au0828-cards.c.orig    2009-08-12 18:28:22.176126368 -0500
>> @@ -116,6 +116,12 @@
>>      .tuner_addr = ADDR_UNSET,
>>      .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
>>  },
>> +    [AU0828_BOARD_SYNTEK_TELEDONGLE] = {
>> +        .name = "Syntek Teledongle [EXPERIMENTAL]",
>> +     .tuner_type = UNSET,
>> +        .tuner_addr = ADDR_UNSET,
>> +        .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
>> +    },
>>  };
>>
>>  /* Tuner callback function for au0828 boards. Currently only needed
>> @@ -248,6 +254,7 @@
>>  case AU0828_BOARD_HAUPPAUGE_HVR950Q:
>>  case AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL:
>>  case AU0828_BOARD_HAUPPAUGE_WOODBURY:
>> +    case AU0828_BOARD_SYNTEK_TELEDONGLE: /* FIXME */
>>      /* GPIO's
>>       * 4 - CS5340
>>       * 5 - AU8522 Demodulator
>> @@ -325,6 +332,8 @@
>>      .driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
>>  { USB_DEVICE(0x2040, 0x8200),
>>      .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
>> +    { USB_DEVICE(0x05e1, 0x0400),
>> +    .driver_info = AU0828_BOARD_SYNTEK_TELEDONGLE },
>>  { },
>>  };
>>
>>
>> There are two versions I'm building and src for both can be found here;
>> http://download.opensuse.org/repositories/home:/malcolmlewis/
>
>
> Malcolm,
>
> I would strongly advise against distributing packages based on these
> patches... This code was never merged into the master branch because
> it has potential to break devices at the hardware level, and it will
> create a support nightmare, based on the fact that there are multiple
> UNLIKE devices that use the same USB ID but actually contain different
> hardware components.  As the patch may enable support for ONE of the
> variations, nobody has ever verified that the GPIO programming is safe
> to use, and there is no way to prevent the potentially harmful code
> from running on the wrong device.
>
> I, personally, do not want the responsibility of explaining to users
> that their usb sticks may be damaged because of code that got merged
> into the kernel -- that's why the code is in a separate repository
> until the issues can be dealt with.  In general, users know that if
> they have to manually apply patches themselves, that they are doing so
> at their own risk.
>
> If you succeed in getting your device to work, please let me know -- I
> will be very interested to hear about it.
>
> Good Luck,
>
> Mike
>
> ___
> linux-dvb users mailing list
> For V4L/DVB development, please use instead linux-media@vger.kernel.org
> linux-...@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>
Hi Mike
Ahh, OK :) I can confirm I've had no issues using it with smplayer on
openSuSE 11.0, openSuSE 11.1 and openSuSE 11.2 M5 i586 (ViA Artigo and
ASUS 1000HE) and SLED 11 x86_64 (home build AMD 4400 X2 system).
System tunes into FTA HDTV great, have scan in different areas and all
scanned channels found have worked. (I'm in Mississippi)

I'm happy to do further testing if you can advise on what is required.

-- 
Cheers
Malcolm
--
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] au0828: experimental support for Syntek Teledongle [05e1:0400]

[Michael Krufky]

On Mon, Aug 17, 2009 at 4:25 PM, Malcolm Lewis wrote:
> Hi
> I've been using the patches from
> http://linuxtv.org/hg/~mkrufky/teledongle/rev/676e2f4475ed
> on a Sabrent device in openSuSE and SLED, during testing with the
> milestone 5 release of
> 11.2 and kernel version 2.6.31-rc5-git3-2-desktop there needs to be
> some changes to the
> au0828-cards.c patch to enable building a kmp module;
>
> --- au0828-cards.c    2009-08-12 18:16:39.435886920 -0500
> +++ au0828-cards.c.orig    2009-08-12 18:28:22.176126368 -0500
> @@ -116,6 +116,12 @@
>      .tuner_addr = ADDR_UNSET,
>      .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
>  },
> +    [AU0828_BOARD_SYNTEK_TELEDONGLE] = {
> +        .name = "Syntek Teledongle [EXPERIMENTAL]",
> +     .tuner_type = UNSET,
> +        .tuner_addr = ADDR_UNSET,
> +        .i2c_clk_divider = AU0828_I2C_CLK_250KHZ,
> +    },
>  };
>
>  /* Tuner callback function for au0828 boards. Currently only needed
> @@ -248,6 +254,7 @@
>  case AU0828_BOARD_HAUPPAUGE_HVR950Q:
>  case AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL:
>  case AU0828_BOARD_HAUPPAUGE_WOODBURY:
> +    case AU0828_BOARD_SYNTEK_TELEDONGLE: /* FIXME */
>      /* GPIO's
>       * 4 - CS5340
>       * 5 - AU8522 Demodulator
> @@ -325,6 +332,8 @@
>      .driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
>  { USB_DEVICE(0x2040, 0x8200),
>      .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
> +    { USB_DEVICE(0x05e1, 0x0400),
> +    .driver_info = AU0828_BOARD_SYNTEK_TELEDONGLE },
>  { },
>  };
>
>
> There are two versions I'm building and src for both can be found here;
> http://download.opensuse.org/repositories/home:/malcolmlewis/


Malcolm,

I would strongly advise against distributing packages based on these
patches... This code was never merged into the master branch because
it has potential to break devices at the hardware level, and it will
create a support nightmare, based on the fact that there are multiple
UNLIKE devices that use the same USB ID but actually contain different
hardware components.  As the patch may enable support for ONE of the
variations, nobody has ever verified that the GPIO programming is safe
to use, and there is no way to prevent the potentially harmful code
from running on the wrong device.

I, personally, do not want the responsibility of explaining to users
that their usb sticks may be damaged because of code that got merged
into the kernel -- that's why the code is in a separate repository
until the issues can be dealt with.  In general, users know that if
they have to manually apply patches themselves, that they are doing so
at their own risk.

If you succeed in getting your device to work, please let me know -- I
will be very interested to hear about it.

Good Luck,

Mike
--
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 v1 - 1/5] DaVinci - restructuring code to support vpif capture driver

[Hans Verkuil]

On Monday 17 August 2009 22:10:04 Karicheri, Muralidharan wrote:
> Hans,
> 
> Would you like the architecture specific changes against v4l-dvb linux-next 
> tree or linux-davinci ? I will rework both the vpfe and vpif patches as per 
> your comment.

v4l-dvb linux-next. The current v4l-dvb at least compiles against that one, so
that is the most appropriate tree to do the patches against.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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 v1 - 1/5] DaVinci - restructuring code to support vpif capture driver

[Karicheri, Muralidharan]

Hans,

Would you like the architecture specific changes against v4l-dvb linux-next 
tree or linux-davinci ? I will rework both the vpfe and vpif patches as per 
your comment.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com

>-Original Message-
>From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>Sent: Monday, August 17, 2009 2:47 PM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; davinci-linux-open-
>sou...@linux.davincidsp.com; khil...@deeprootsystems.com
>Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif
>capture driver
>
>On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote:
>> Hans,
>>
>> They are applied against davinci tree (also mentioned in the patch).
>General procedure what I follow is to create platform code against davinci
>tree and v4l patches against v4l-dvb linux-next tree. The architecture part
>of linux-next is not up to date.
>>
>> Davinci tree is at
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
>
>I must have missed the mention of this tree.
>
>I have a problem, though, as the current v4l-dvb repository doesn't compile
>against the linux-davinci git tree. And the only way I can get it to
>compile
>is to apply all five patches first.
>
>However, the whole tree should still compile after each patch is applied.
>And
>that goes wrong with your second patch where the Kconfig and Makefile are
>modified when the new sources aren't even added yet!
>
>What I would like to see is a patch series that starts with one patch that
>makes the current v4l-dvb tree compile again, then the arch patch is added,
>then a series of v4l-dvb patches in such an order that everything compiles
>after each step.
>
>Merging this is already complicated enough without breaking compilation in
>this way.
>
>Regards,
>
>   Hans
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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 v1 4/4] Build system support for DM365 CCDC

[neilsikka]

From: Neil Sikka 

This patch sets up the build system for DM365 VPFE support

Reviewed-by: Muralidharan Karicheri 
Mandatory-Reviewer: Hans Verkuil 
Signed-off-by: Neil Sikka 
---
Applies to v4l-dvb linux-next repository
 drivers/media/video/Kconfig  |9 +
 drivers/media/video/davinci/Makefile |3 ++-
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 1fa3c87..e0dd402 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -578,6 +578,15 @@ config VIDEO_DM355_CCDC
   To compile this driver as a module, choose M here: the
   module will be called vpfe.
 
+config VIDEO_DM365_ISIF
+   tristate "DM365 CCDC/ISIF HW module"
+   depends on ARCH_DAVINCI_DM365 && VIDEO_VPFE_CAPTURE
+   default y
+   help
+  Enables DM365 ISIF hw module. This is the hardware module for
+  configuring ISIF in VPFE to capture Raw Bayer RGB data  from
+  a image sensor or YUV data from a YUV source.
+
 source "drivers/media/video/bt8xx/Kconfig"
 
 config VIDEO_PMS
diff --git a/drivers/media/video/davinci/Makefile 
b/drivers/media/video/davinci/Makefile
index f44cad2..5f4c830 100644
--- a/drivers/media/video/davinci/Makefile
+++ b/drivers/media/video/davinci/Makefile
@@ -8,8 +8,9 @@ obj-$(CONFIG_VIDEO_DAVINCI_VPIF) += vpif.o
 #DM646x EVM Display driver
 obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o
 
-# Capture: DM6446 and DM355
+# Capture: DM6446, DM355, DM365
 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o
 obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o
 obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o
 obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o
+obj-$(CONFIG_VIDEO_DM365_ISIF) += dm365_ccdc.o
-- 
1.6.0.4

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

[PATCH v1 1/4] DM365 Platform support for VPFE

[neilsikka]

From: Neil Sikka 

This has platform and board setup changes to support the vpfe capture
driver for DM365 EVMs.

Reviewed-by: Muralidharan Karicheri 
Mandatory-Reviewer: Hans Verkuil 
Mandatory-Reviewer: Kevin Hilman 
Signed-off-by: Neil Sikka 
---
Applies to Kevin Hilman's linux-davinci repository
 arch/arm/mach-davinci/board-dm365-evm.c|   71 
 arch/arm/mach-davinci/dm365.c  |   68 ++
 arch/arm/mach-davinci/include/mach/dm365.h |2 +
 3 files changed, 141 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..757ad13 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 
 static inline int have_imager(void)
@@ -98,6 +100,11 @@ static inline int have_tvp7002(void)
 
 static void __iomem *cpld;
 
+static struct tvp514x_platform_data tvp5146_pdata = {
+   .clk_polarity = 0,
+   .hs_polarity = 1,
+   .vs_polarity = 1
+};
 
 /* NOTE:  this is geared for the standard config, with a socketed
  * 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors.  If you
@@ -210,6 +217,68 @@ static int cpld_mmc_get_ro(int module)
return !!(__raw_readb(cpld + CPLD_CARDSTAT) & BIT(module ? 5 : 1));
 }
 
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+   {
+   .index = 0,
+   .name = "Composite",
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+   {
+   .index = 1,
+   .name = "S-Video",
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+   {
+   .input = INPUT_CVBS_VI2B,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+{
+   .input = INPUT_SVIDEO_VI2C_VI1C,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+{
+   .module_name = "tvp5146",
+   .grp_id = 0,
+   .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+   .inputs = tvp5146_inputs,
+   .routes = tvp5146_routes,
+   .can_route = 1,
+   .ccdc_if_params = {
+   .if_type = VPFE_BT656,
+   .hdpol = VPFE_PINPOL_POSITIVE,
+   .vdpol = VPFE_PINPOL_POSITIVE,
+   },
+   .board_info = {
+   I2C_BOARD_INFO("tvp5146", 0x5d),
+   .platform_data = &tvp5146_pdata,
+   },
+   }
+};
+
+static struct vpfe_config vpfe_cfg = {
+   .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+   .sub_devs = vpfe_sub_devs,
+   .card_name = "DM365 EVM",
+   .ccdc = "DM365 ISIF",
+   .num_clocks = 1,
+   .clocks = {"vpss_master"},
+};
+
 static struct davinci_mmc_config dm365evm_mmc_config = {
.get_cd = cpld_mmc_get_cd,
.get_ro = cpld_mmc_get_ro,
@@ -461,6 +530,8 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm365_evm_map_io(void)
 {
+   /* setup input configuration for VPFE input devices */
+   dm365_set_vpfe_config(&vpfe_cfg);
dm365_init();
 }
 
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f8bac94..aa432d4 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -904,6 +904,62 @@ void __init dm365_init(void)
davinci_common_init(&davinci_soc_info_dm365);
 }
 
+static struct resource dm365_vpss_resources[] = {
+   {
+   /* VPSS ISP5 Base address */
+   .name   = "vpss",
+   .start  = 0x01c7,
+   .end= 0x01c7 + 0xff,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   /* VPSS CLK Base address */
+   .name   = "vpss",
+   .start  = 0x01c70200,
+   .end= 0x01c70200 + 0xff,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device dm365_vpss_device = {
+   .name   = "vpss",
+   .id = -1,
+   .dev.platform_data  = "dm365_vpss",
+   .num_resources  = ARRAY_SIZE(dm365_vpss_resources),
+   .resource   = dm365_vpss_resources,
+};
+
+static struct resource vpfe_resources[] = {
+   {
+   .start  = IRQ_VDINT0,
+   .e

[PATCH v1 2/4] DM365 VPSS support

[neilsikka]

From: Neil Sikka 

This patch adds support for DM365 VPSS

Reviewed-by: Muralidharan Karicheri 
Mandatory-Reviewer: Hans Verkuil 
Signed-off-by: Neil Sikka 
---
Applies to v4l-dvb linux-next repository
 drivers/media/video/davinci/vpss.c |  232 
 include/media/davinci/vpss.h   |   59 +-
 2 files changed, 268 insertions(+), 23 deletions(-)

diff --git a/drivers/media/video/davinci/vpss.c 
b/drivers/media/video/davinci/vpss.c
index 6d709ca..83dac1b 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -42,9 +42,12 @@ MODULE_AUTHOR("Texas Instruments");
 /* masks and shifts */
 #define VPSS_HSSISEL_SHIFT 4
 
-/*
+/* lock to write into common register */
+static spinlock_t vpss_lock;
+
+/**
  * vpss operations. Depends on platform. Not all functions are available
- * on all platforms. The api, first check if a functio is available before
+ * on all platforms. The api, first check if a function is available before
  * invoking it. In the probe, the function ptrs are intialized based on
  * vpss name. vpss name can be "dm355_vpss", "dm644x_vpss" etc.
  */
@@ -53,14 +56,19 @@ struct vpss_hw_ops {
int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
/* select input to ccdc */
void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
-   /* clear wbl overlflow bit */
+   /* clear wbl overflow bit */
int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+   /*set sync polarity */
+   void (*set_sync_pol)(struct vpss_sync_pol);
+   /*set the PG_FRAME_SIZE register*/
+   void (*set_pg_frame_size)(struct vpss_pg_frame_size);
 };
 
 /* vpss configuration */
 struct vpss_oper_config {
-   __iomem void *vpss_bl_regs_base;
-   __iomem void *vpss_regs_base;
+   __iomem void *vpss_regs_base0;
+   __iomem void *vpss_regs_base1;
+   resource_size_t *vpss_regs_base2;
struct resource *r1;
resource_size_t len1;
struct resource *r2;
@@ -75,22 +83,32 @@ static struct vpss_oper_config oper_cfg;
 /* register access routines */
 static inline u32 bl_regr(u32 offset)
 {
-   return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+   return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
 }
 
 static inline void bl_regw(u32 val, u32 offset)
 {
-   __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+   __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline u32 isp5_read(u32 offset)
+{
+   return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline void isp5_write(u32 val, u32 offset)
+{
+   __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
 }
 
 static inline u32 vpss_regr(u32 offset)
 {
-   return __raw_readl(oper_cfg.vpss_regs_base + offset);
+   return __raw_readl(oper_cfg.vpss_regs_base1 + offset);
 }
 
 static inline void vpss_regw(u32 val, u32 offset)
 {
-   __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+   __raw_writel(val, oper_cfg.vpss_regs_base1 + offset);
 }
 
 static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -98,12 +116,25 @@ static void dm355_select_ccdc_source(enum 
vpss_ccdc_source_sel src_sel)
bl_regw(src_sel << VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
 }
 
+static void dm365_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+   u32 temp = isp5_read(DM365_ISP5_CCDCMUX) & ~CCD_SRC_SEL_MASK;
+
+   /* if we are using pattern generator, enable it */
+   if (src_sel == VPSS_PGLPBK || src_sel == VPSS_CCDCPG)
+   temp |= 0x08;
+
+   temp |= (src_sel << CCD_SRC_SEL_SHIFT);
+   isp5_write(temp, DM365_ISP5_CCDCMUX);
+}
+
 int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
 {
if (!oper_cfg.hw_ops.select_ccdc_source)
return -1;
 
-   dm355_select_ccdc_source(src_sel);
+   oper_cfg.hw_ops.select_ccdc_source(src_sel);
+
return 0;
 }
 EXPORT_SYMBOL(vpss_select_ccdc_source);
@@ -120,9 +151,56 @@ static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel 
wbl_sel)
mask = ~(mask << wbl_sel);
val = bl_regr(DM644X_SBL_PCR_VPSS) & mask;
bl_regw(val, DM644X_SBL_PCR_VPSS);
+
return 0;
 }
 
+static void dm365_enable_irq(void)
+{
+   u32 current_val = isp5_read(DM365_VPSS_INTSEL1);
+   /*just enable INTSEL0 and INTSEL1 and leave everything else as is*/
+   current_val &= ~(CCD_INT_SEL_MASK);
+   current_val |= BIT_MASK(8);
+   isp5_write(current_val, DM365_VPSS_INTSEL1);
+}
+
+void dm365_set_sync_pol(struct vpss_sync_pol sync)
+{
+   int val = 0;
+   val = isp5_read(DM365_ISP5_CCDCMUX);
+
+   val |= (sync.ccdpg_hdpol << DM365_CCDC_PG_HD_POL_SHIFT);
+   val |= (sync.ccdpg_vdpol << DM365_CCDC_PG_VD_POL_SHIFT);
+
+   isp5_write(val, DM365_ISP5_CCDCMUX);
+}
+
+void vpss_set_sync_pol(struct vpss_sync_pol sync)
+{
+   if (!oper_cfg.hw_ops

[PATCH v1 0/4] Adding capture support for DM365 device

[neilsikka]

From: Neil Sikka 

This patch series adds support for the VPSS capture on the DM365 SOC.
Specifically, it supports the CCDC/ISIF module. This code has been tested and
works with the TVP5146 decoder (using the tvp514x driver). During testing of
this code, the NTSC capture format was used. This patch depends on previous
other patches contributed by Muralidharan Karicheri. Please see the individual
patch notes for dependency details. The patches contained in this patch set are:

1) DM365 Platform support for VPFE-additions to the DM365 SOC files
2) DM365 VPSS support-additions to the VPSS.h and VPSS.c files
3) CCDC support on DM365-the actual DM365 CCDC driver and its supporting files

NOTE: All patches are to be applied before build.

Mandatory reviewers:
Hans Verkuil  for V4L tree
Kevin Hilman  for DaVinci tree

Reviewed-by: Muralidharan Karicheri 
Signed-off-by: Neil Sikka 
--
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 v1 0/4] Adding capture support for DM365 device

[Sikka, Neil]

Please disregard the previous patch. I am sending one with corrected Subject 
fields.

-Original Message-
From: Sikka, Neil 
Sent: Monday, August 17, 2009 3:35 PM
To: linux-media@vger.kernel.org; davinci-linux-open-sou...@linux.davincidsp.com
Cc: khil...@deeprootsystems.com; hverk...@xs4all.nl; Sikka, Neil
Subject: [PATCH v1 0/4] Adding capture support for DM365 device

From: Neil Sikka 

This patch series adds support for the VPSS capture on the DM365 SOC.
Specifically, it supports the CCDC/ISIF module. This code has been tested and
works with the TVP5146 decoder (using the tvp514x driver). During testing of
this code, the NTSC capture format was used. This patch depends on previous
other patches contributed by Muralidharan Karicheri. Please see the individual
patch notes for dependency details. The patches contained in this patch set are:

1) DM365 Platform support for VPFE-additions to the DM365 SOC files
2) DM365 VPSS support-additions to the VPSS.h and VPSS.c files
3) CCDC support on DM365-the actual DM365 CCDC driver and its supporting files

NOTE: All patches are to be applied before build.

Mandatory reviewers:
Hans Verkuil  for V4L tree
Kevin Hilman  for DaVinci tree

Reviewed-by: Muralidharan Karicheri 
Signed-off-by: Neil Sikka 
--
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 v1 - 1/5] DaVinci - restructuring code to support vpif capture driver

[Karicheri, Muralidharan]

Hans,

Ok. I will rework the patch and send you the same.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com

>-Original Message-
>From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>Sent: Monday, August 17, 2009 2:47 PM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; davinci-linux-open-
>sou...@linux.davincidsp.com; khil...@deeprootsystems.com
>Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif
>capture driver
>
>On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote:
>> Hans,
>>
>> They are applied against davinci tree (also mentioned in the patch).
>General procedure what I follow is to create platform code against davinci
>tree and v4l patches against v4l-dvb linux-next tree. The architecture part
>of linux-next is not up to date.
>>
>> Davinci tree is at
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
>
>I must have missed the mention of this tree.
>
>I have a problem, though, as the current v4l-dvb repository doesn't compile
>against the linux-davinci git tree. And the only way I can get it to
>compile
>is to apply all five patches first.
>
>However, the whole tree should still compile after each patch is applied.
>And
>that goes wrong with your second patch where the Kconfig and Makefile are
>modified when the new sources aren't even added yet!
>
>What I would like to see is a patch series that starts with one patch that
>makes the current v4l-dvb tree compile again, then the arch patch is added,
>then a series of v4l-dvb patches in such an order that everything compiles
>after each step.
>
>Merging this is already complicated enough without breaking compilation in
>this way.
>
>Regards,
>
>   Hans
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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 v1 0/4] Adding capture support for DM365 device

[neilsikka]

From: Neil Sikka 

This patch series adds support for the VPSS capture on the DM365 SOC.
Specifically, it supports the CCDC/ISIF module. This code has been tested and
works with the TVP5146 decoder (using the tvp514x driver). During testing of
this code, the NTSC capture format was used. This patch depends on previous
other patches contributed by Muralidharan Karicheri. Please see the individual
patch notes for dependency details. The patches contained in this patch set are:

1) DM365 Platform support for VPFE-additions to the DM365 SOC files
2) DM365 VPSS support-additions to the VPSS.h and VPSS.c files
3) CCDC support on DM365-the actual DM365 CCDC driver and its supporting files

NOTE: All patches are to be applied before build.

Mandatory reviewers:
Hans Verkuil  for V4L tree
Kevin Hilman  for DaVinci tree

Reviewed-by: Muralidharan Karicheri 
Signed-off-by: Neil Sikka 
--
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] DM365 VPSS support

[neilsikka]

From: Neil Sikka 

This patch adds support for DM365 VPSS

Reviewed-by: Muralidharan Karicheri 
Mandatory-Reviewer: Hans Verkuil 
Signed-off-by: Neil Sikka 
---
Applies to v4l-dvb linux-next repository
 drivers/media/video/davinci/vpss.c |  232 
 include/media/davinci/vpss.h   |   59 +-
 2 files changed, 268 insertions(+), 23 deletions(-)

diff --git a/drivers/media/video/davinci/vpss.c 
b/drivers/media/video/davinci/vpss.c
index 6d709ca..83dac1b 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -42,9 +42,12 @@ MODULE_AUTHOR("Texas Instruments");
 /* masks and shifts */
 #define VPSS_HSSISEL_SHIFT 4
 
-/*
+/* lock to write into common register */
+static spinlock_t vpss_lock;
+
+/**
  * vpss operations. Depends on platform. Not all functions are available
- * on all platforms. The api, first check if a functio is available before
+ * on all platforms. The api, first check if a function is available before
  * invoking it. In the probe, the function ptrs are intialized based on
  * vpss name. vpss name can be "dm355_vpss", "dm644x_vpss" etc.
  */
@@ -53,14 +56,19 @@ struct vpss_hw_ops {
int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
/* select input to ccdc */
void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
-   /* clear wbl overlflow bit */
+   /* clear wbl overflow bit */
int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+   /*set sync polarity */
+   void (*set_sync_pol)(struct vpss_sync_pol);
+   /*set the PG_FRAME_SIZE register*/
+   void (*set_pg_frame_size)(struct vpss_pg_frame_size);
 };
 
 /* vpss configuration */
 struct vpss_oper_config {
-   __iomem void *vpss_bl_regs_base;
-   __iomem void *vpss_regs_base;
+   __iomem void *vpss_regs_base0;
+   __iomem void *vpss_regs_base1;
+   resource_size_t *vpss_regs_base2;
struct resource *r1;
resource_size_t len1;
struct resource *r2;
@@ -75,22 +83,32 @@ static struct vpss_oper_config oper_cfg;
 /* register access routines */
 static inline u32 bl_regr(u32 offset)
 {
-   return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+   return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
 }
 
 static inline void bl_regw(u32 val, u32 offset)
 {
-   __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+   __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline u32 isp5_read(u32 offset)
+{
+   return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline void isp5_write(u32 val, u32 offset)
+{
+   __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
 }
 
 static inline u32 vpss_regr(u32 offset)
 {
-   return __raw_readl(oper_cfg.vpss_regs_base + offset);
+   return __raw_readl(oper_cfg.vpss_regs_base1 + offset);
 }
 
 static inline void vpss_regw(u32 val, u32 offset)
 {
-   __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+   __raw_writel(val, oper_cfg.vpss_regs_base1 + offset);
 }
 
 static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -98,12 +116,25 @@ static void dm355_select_ccdc_source(enum 
vpss_ccdc_source_sel src_sel)
bl_regw(src_sel << VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
 }
 
+static void dm365_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+   u32 temp = isp5_read(DM365_ISP5_CCDCMUX) & ~CCD_SRC_SEL_MASK;
+
+   /* if we are using pattern generator, enable it */
+   if (src_sel == VPSS_PGLPBK || src_sel == VPSS_CCDCPG)
+   temp |= 0x08;
+
+   temp |= (src_sel << CCD_SRC_SEL_SHIFT);
+   isp5_write(temp, DM365_ISP5_CCDCMUX);
+}
+
 int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
 {
if (!oper_cfg.hw_ops.select_ccdc_source)
return -1;
 
-   dm355_select_ccdc_source(src_sel);
+   oper_cfg.hw_ops.select_ccdc_source(src_sel);
+
return 0;
 }
 EXPORT_SYMBOL(vpss_select_ccdc_source);
@@ -120,9 +151,56 @@ static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel 
wbl_sel)
mask = ~(mask << wbl_sel);
val = bl_regr(DM644X_SBL_PCR_VPSS) & mask;
bl_regw(val, DM644X_SBL_PCR_VPSS);
+
return 0;
 }
 
+static void dm365_enable_irq(void)
+{
+   u32 current_val = isp5_read(DM365_VPSS_INTSEL1);
+   /*just enable INTSEL0 and INTSEL1 and leave everything else as is*/
+   current_val &= ~(CCD_INT_SEL_MASK);
+   current_val |= BIT_MASK(8);
+   isp5_write(current_val, DM365_VPSS_INTSEL1);
+}
+
+void dm365_set_sync_pol(struct vpss_sync_pol sync)
+{
+   int val = 0;
+   val = isp5_read(DM365_ISP5_CCDCMUX);
+
+   val |= (sync.ccdpg_hdpol << DM365_CCDC_PG_HD_POL_SHIFT);
+   val |= (sync.ccdpg_vdpol << DM365_CCDC_PG_VD_POL_SHIFT);
+
+   isp5_write(val, DM365_ISP5_CCDCMUX);
+}
+
+void vpss_set_sync_pol(struct vpss_sync_pol sync)
+{
+   if (!oper_cfg.hw_ops

[PATCH] Build system support for DM365 CCDC

[neilsikka]

From: Neil Sikka 

This patch sets up the build system for DM365 VPFE support

Reviewed-by: Muralidharan Karicheri 
Mandatory-Reviewer: Hans Verkuil 
Signed-off-by: Neil Sikka 
---
Applies to v4l-dvb linux-next repository
 drivers/media/video/Kconfig  |9 +
 drivers/media/video/davinci/Makefile |3 ++-
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 1fa3c87..e0dd402 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -578,6 +578,15 @@ config VIDEO_DM355_CCDC
   To compile this driver as a module, choose M here: the
   module will be called vpfe.
 
+config VIDEO_DM365_ISIF
+   tristate "DM365 CCDC/ISIF HW module"
+   depends on ARCH_DAVINCI_DM365 && VIDEO_VPFE_CAPTURE
+   default y
+   help
+  Enables DM365 ISIF hw module. This is the hardware module for
+  configuring ISIF in VPFE to capture Raw Bayer RGB data  from
+  a image sensor or YUV data from a YUV source.
+
 source "drivers/media/video/bt8xx/Kconfig"
 
 config VIDEO_PMS
diff --git a/drivers/media/video/davinci/Makefile 
b/drivers/media/video/davinci/Makefile
index f44cad2..5f4c830 100644
--- a/drivers/media/video/davinci/Makefile
+++ b/drivers/media/video/davinci/Makefile
@@ -8,8 +8,9 @@ obj-$(CONFIG_VIDEO_DAVINCI_VPIF) += vpif.o
 #DM646x EVM Display driver
 obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o
 
-# Capture: DM6446 and DM355
+# Capture: DM6446, DM355, DM365
 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o
 obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o
 obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o
 obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o
+obj-$(CONFIG_VIDEO_DM365_ISIF) += dm365_ccdc.o
-- 
1.6.0.4

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

[PATCH] DM365 Platform support for VPFE

[neilsikka]

From: Neil Sikka 

This has platform and board setup changes to support the vpfe capture
driver for DM365 EVMs.

Reviewed-by: Muralidharan Karicheri 
Mandatory-Reviewer: Hans Verkuil 
Mandatory-Reviewer: Kevin Hilman 
Signed-off-by: Neil Sikka 
---
Applies to Kevin Hilman's linux-davinci repository
 arch/arm/mach-davinci/board-dm365-evm.c|   71 
 arch/arm/mach-davinci/dm365.c  |   68 ++
 arch/arm/mach-davinci/include/mach/dm365.h |2 +
 3 files changed, 141 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..757ad13 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 
 static inline int have_imager(void)
@@ -98,6 +100,11 @@ static inline int have_tvp7002(void)
 
 static void __iomem *cpld;
 
+static struct tvp514x_platform_data tvp5146_pdata = {
+   .clk_polarity = 0,
+   .hs_polarity = 1,
+   .vs_polarity = 1
+};
 
 /* NOTE:  this is geared for the standard config, with a socketed
  * 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors.  If you
@@ -210,6 +217,68 @@ static int cpld_mmc_get_ro(int module)
return !!(__raw_readb(cpld + CPLD_CARDSTAT) & BIT(module ? 5 : 1));
 }
 
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+   {
+   .index = 0,
+   .name = "Composite",
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+   {
+   .index = 1,
+   .name = "S-Video",
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+   {
+   .input = INPUT_CVBS_VI2B,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+{
+   .input = INPUT_SVIDEO_VI2C_VI1C,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+{
+   .module_name = "tvp5146",
+   .grp_id = 0,
+   .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+   .inputs = tvp5146_inputs,
+   .routes = tvp5146_routes,
+   .can_route = 1,
+   .ccdc_if_params = {
+   .if_type = VPFE_BT656,
+   .hdpol = VPFE_PINPOL_POSITIVE,
+   .vdpol = VPFE_PINPOL_POSITIVE,
+   },
+   .board_info = {
+   I2C_BOARD_INFO("tvp5146", 0x5d),
+   .platform_data = &tvp5146_pdata,
+   },
+   }
+};
+
+static struct vpfe_config vpfe_cfg = {
+   .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+   .sub_devs = vpfe_sub_devs,
+   .card_name = "DM365 EVM",
+   .ccdc = "DM365 ISIF",
+   .num_clocks = 1,
+   .clocks = {"vpss_master"},
+};
+
 static struct davinci_mmc_config dm365evm_mmc_config = {
.get_cd = cpld_mmc_get_cd,
.get_ro = cpld_mmc_get_ro,
@@ -461,6 +530,8 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm365_evm_map_io(void)
 {
+   /* setup input configuration for VPFE input devices */
+   dm365_set_vpfe_config(&vpfe_cfg);
dm365_init();
 }
 
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f8bac94..aa432d4 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -904,6 +904,62 @@ void __init dm365_init(void)
davinci_common_init(&davinci_soc_info_dm365);
 }
 
+static struct resource dm365_vpss_resources[] = {
+   {
+   /* VPSS ISP5 Base address */
+   .name   = "vpss",
+   .start  = 0x01c7,
+   .end= 0x01c7 + 0xff,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   /* VPSS CLK Base address */
+   .name   = "vpss",
+   .start  = 0x01c70200,
+   .end= 0x01c70200 + 0xff,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device dm365_vpss_device = {
+   .name   = "vpss",
+   .id = -1,
+   .dev.platform_data  = "dm365_vpss",
+   .num_resources  = ARRAY_SIZE(dm365_vpss_resources),
+   .resource   = dm365_vpss_resources,
+};
+
+static struct resource vpfe_resources[] = {
+   {
+   .start  = IRQ_VDINT0,
+   .e

[PATCH] Build system support for DM365 CCDC

[neilsikka]

From: Neil Sikka 

This patch sets up the build system for DM365 VPFE support

Reviewed-by: Muralidharan Karicheri 
Mandatory-Reviewer: Hans Verkuil 
Signed-off-by: Neil Sikka 
---
Applies to v4l-dvb linux-next repository
 drivers/media/video/Kconfig  |9 +
 drivers/media/video/davinci/Makefile |3 ++-
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 1fa3c87..e0dd402 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -578,6 +578,15 @@ config VIDEO_DM355_CCDC
   To compile this driver as a module, choose M here: the
   module will be called vpfe.
 
+config VIDEO_DM365_ISIF
+   tristate "DM365 CCDC/ISIF HW module"
+   depends on ARCH_DAVINCI_DM365 && VIDEO_VPFE_CAPTURE
+   default y
+   help
+  Enables DM365 ISIF hw module. This is the hardware module for
+  configuring ISIF in VPFE to capture Raw Bayer RGB data  from
+  a image sensor or YUV data from a YUV source.
+
 source "drivers/media/video/bt8xx/Kconfig"
 
 config VIDEO_PMS
diff --git a/drivers/media/video/davinci/Makefile 
b/drivers/media/video/davinci/Makefile
index f44cad2..5f4c830 100644
--- a/drivers/media/video/davinci/Makefile
+++ b/drivers/media/video/davinci/Makefile
@@ -8,8 +8,9 @@ obj-$(CONFIG_VIDEO_DAVINCI_VPIF) += vpif.o
 #DM646x EVM Display driver
 obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o
 
-# Capture: DM6446 and DM355
+# Capture: DM6446, DM355, DM365
 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o
 obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o
 obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o
 obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o
+obj-$(CONFIG_VIDEO_DM365_ISIF) += dm365_ccdc.o
-- 
1.6.0.4

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

[PATCH] DM365 VPSS support

[neilsikka]

From: Neil Sikka 

This patch adds support for DM365 VPSS

Reviewed-by: Muralidharan Karicheri 
Mandatory-Reviewer: Hans Verkuil 
Signed-off-by: Neil Sikka 
---
Applies to v4l-dvb linux-next repository
 drivers/media/video/davinci/vpss.c |  232 
 include/media/davinci/vpss.h   |   59 +-
 2 files changed, 268 insertions(+), 23 deletions(-)

diff --git a/drivers/media/video/davinci/vpss.c 
b/drivers/media/video/davinci/vpss.c
index 6d709ca..83dac1b 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -42,9 +42,12 @@ MODULE_AUTHOR("Texas Instruments");
 /* masks and shifts */
 #define VPSS_HSSISEL_SHIFT 4
 
-/*
+/* lock to write into common register */
+static spinlock_t vpss_lock;
+
+/**
  * vpss operations. Depends on platform. Not all functions are available
- * on all platforms. The api, first check if a functio is available before
+ * on all platforms. The api, first check if a function is available before
  * invoking it. In the probe, the function ptrs are intialized based on
  * vpss name. vpss name can be "dm355_vpss", "dm644x_vpss" etc.
  */
@@ -53,14 +56,19 @@ struct vpss_hw_ops {
int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
/* select input to ccdc */
void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
-   /* clear wbl overlflow bit */
+   /* clear wbl overflow bit */
int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+   /*set sync polarity */
+   void (*set_sync_pol)(struct vpss_sync_pol);
+   /*set the PG_FRAME_SIZE register*/
+   void (*set_pg_frame_size)(struct vpss_pg_frame_size);
 };
 
 /* vpss configuration */
 struct vpss_oper_config {
-   __iomem void *vpss_bl_regs_base;
-   __iomem void *vpss_regs_base;
+   __iomem void *vpss_regs_base0;
+   __iomem void *vpss_regs_base1;
+   resource_size_t *vpss_regs_base2;
struct resource *r1;
resource_size_t len1;
struct resource *r2;
@@ -75,22 +83,32 @@ static struct vpss_oper_config oper_cfg;
 /* register access routines */
 static inline u32 bl_regr(u32 offset)
 {
-   return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+   return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
 }
 
 static inline void bl_regw(u32 val, u32 offset)
 {
-   __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+   __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline u32 isp5_read(u32 offset)
+{
+   return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline void isp5_write(u32 val, u32 offset)
+{
+   __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
 }
 
 static inline u32 vpss_regr(u32 offset)
 {
-   return __raw_readl(oper_cfg.vpss_regs_base + offset);
+   return __raw_readl(oper_cfg.vpss_regs_base1 + offset);
 }
 
 static inline void vpss_regw(u32 val, u32 offset)
 {
-   __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+   __raw_writel(val, oper_cfg.vpss_regs_base1 + offset);
 }
 
 static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -98,12 +116,25 @@ static void dm355_select_ccdc_source(enum 
vpss_ccdc_source_sel src_sel)
bl_regw(src_sel << VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
 }
 
+static void dm365_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+   u32 temp = isp5_read(DM365_ISP5_CCDCMUX) & ~CCD_SRC_SEL_MASK;
+
+   /* if we are using pattern generator, enable it */
+   if (src_sel == VPSS_PGLPBK || src_sel == VPSS_CCDCPG)
+   temp |= 0x08;
+
+   temp |= (src_sel << CCD_SRC_SEL_SHIFT);
+   isp5_write(temp, DM365_ISP5_CCDCMUX);
+}
+
 int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
 {
if (!oper_cfg.hw_ops.select_ccdc_source)
return -1;
 
-   dm355_select_ccdc_source(src_sel);
+   oper_cfg.hw_ops.select_ccdc_source(src_sel);
+
return 0;
 }
 EXPORT_SYMBOL(vpss_select_ccdc_source);
@@ -120,9 +151,56 @@ static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel 
wbl_sel)
mask = ~(mask << wbl_sel);
val = bl_regr(DM644X_SBL_PCR_VPSS) & mask;
bl_regw(val, DM644X_SBL_PCR_VPSS);
+
return 0;
 }
 
+static void dm365_enable_irq(void)
+{
+   u32 current_val = isp5_read(DM365_VPSS_INTSEL1);
+   /*just enable INTSEL0 and INTSEL1 and leave everything else as is*/
+   current_val &= ~(CCD_INT_SEL_MASK);
+   current_val |= BIT_MASK(8);
+   isp5_write(current_val, DM365_VPSS_INTSEL1);
+}
+
+void dm365_set_sync_pol(struct vpss_sync_pol sync)
+{
+   int val = 0;
+   val = isp5_read(DM365_ISP5_CCDCMUX);
+
+   val |= (sync.ccdpg_hdpol << DM365_CCDC_PG_HD_POL_SHIFT);
+   val |= (sync.ccdpg_vdpol << DM365_CCDC_PG_VD_POL_SHIFT);
+
+   isp5_write(val, DM365_ISP5_CCDCMUX);
+}
+
+void vpss_set_sync_pol(struct vpss_sync_pol sync)
+{
+   if (!oper_cfg.hw_ops

[PATCH] DM365 Platform support for VPFE

[neilsikka]

From: Neil Sikka 

This has platform and board setup changes to support the vpfe capture
driver for DM365 EVMs.

Reviewed-by: Muralidharan Karicheri 
Mandatory-Reviewer: Hans Verkuil 
Mandatory-Reviewer: Kevin Hilman 
Signed-off-by: Neil Sikka 
---
Applies to Kevin Hilman's linux-davinci repository
 arch/arm/mach-davinci/board-dm365-evm.c|   71 
 arch/arm/mach-davinci/dm365.c  |   68 ++
 arch/arm/mach-davinci/include/mach/dm365.h |2 +
 3 files changed, 141 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..757ad13 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 
 static inline int have_imager(void)
@@ -98,6 +100,11 @@ static inline int have_tvp7002(void)
 
 static void __iomem *cpld;
 
+static struct tvp514x_platform_data tvp5146_pdata = {
+   .clk_polarity = 0,
+   .hs_polarity = 1,
+   .vs_polarity = 1
+};
 
 /* NOTE:  this is geared for the standard config, with a socketed
  * 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors.  If you
@@ -210,6 +217,68 @@ static int cpld_mmc_get_ro(int module)
return !!(__raw_readb(cpld + CPLD_CARDSTAT) & BIT(module ? 5 : 1));
 }
 
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+   {
+   .index = 0,
+   .name = "Composite",
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+   {
+   .index = 1,
+   .name = "S-Video",
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+   {
+   .input = INPUT_CVBS_VI2B,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+{
+   .input = INPUT_SVIDEO_VI2C_VI1C,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+{
+   .module_name = "tvp5146",
+   .grp_id = 0,
+   .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+   .inputs = tvp5146_inputs,
+   .routes = tvp5146_routes,
+   .can_route = 1,
+   .ccdc_if_params = {
+   .if_type = VPFE_BT656,
+   .hdpol = VPFE_PINPOL_POSITIVE,
+   .vdpol = VPFE_PINPOL_POSITIVE,
+   },
+   .board_info = {
+   I2C_BOARD_INFO("tvp5146", 0x5d),
+   .platform_data = &tvp5146_pdata,
+   },
+   }
+};
+
+static struct vpfe_config vpfe_cfg = {
+   .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+   .sub_devs = vpfe_sub_devs,
+   .card_name = "DM365 EVM",
+   .ccdc = "DM365 ISIF",
+   .num_clocks = 1,
+   .clocks = {"vpss_master"},
+};
+
 static struct davinci_mmc_config dm365evm_mmc_config = {
.get_cd = cpld_mmc_get_cd,
.get_ro = cpld_mmc_get_ro,
@@ -461,6 +530,8 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm365_evm_map_io(void)
 {
+   /* setup input configuration for VPFE input devices */
+   dm365_set_vpfe_config(&vpfe_cfg);
dm365_init();
 }
 
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f8bac94..aa432d4 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -904,6 +904,62 @@ void __init dm365_init(void)
davinci_common_init(&davinci_soc_info_dm365);
 }
 
+static struct resource dm365_vpss_resources[] = {
+   {
+   /* VPSS ISP5 Base address */
+   .name   = "vpss",
+   .start  = 0x01c7,
+   .end= 0x01c7 + 0xff,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   /* VPSS CLK Base address */
+   .name   = "vpss",
+   .start  = 0x01c70200,
+   .end= 0x01c70200 + 0xff,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device dm365_vpss_device = {
+   .name   = "vpss",
+   .id = -1,
+   .dev.platform_data  = "dm365_vpss",
+   .num_resources  = ARRAY_SIZE(dm365_vpss_resources),
+   .resource   = dm365_vpss_resources,
+};
+
+static struct resource vpfe_resources[] = {
+   {
+   .start  = IRQ_VDINT0,
+   .e

Re: KWorld UB435-Q support?

[Thomas Fjellstrom]

On Mon August 17 2009, Jarod Wilson wrote:
> On Aug 14, 2009, at 11:03 AM, Thomas Fjellstrom wrote:
> > On Fri August 14 2009, Jarod Wilson wrote:
> >> On Aug 14, 2009, at 1:12 AM, Thomas Fjellstrom wrote:
> >>> On Thu August 13 2009, Jarod Wilson wrote:
>  On Aug 13, 2009, at 12:53 AM, Thomas Fjellstrom wrote:
> > I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it
> > was
> > supported
> > under linux, and it turns out it isn't. I'm wondering what it
> > would
> > take to
> > get it supported. It seems like all of the main chips it uses are
> > supported,
> > but the glue code is missing.
> >
> > I have some C (10 years) programming experience, and have wanted
> > to
> > contribute
> > to the linux kernel for quite a while, now I have a good excuse ;)
> >
> > Would anyone be willing to point me in the right direction?
> 
>  The UB435-Q is a rebadge of the revision B 340U, which is an em2870
>  bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its
>  got
>  the same device ID and everything. I've got a rev A 340U, the only
>  difference being that it has an nxp tda18271hd/c1 tuner (also same
>  device ID). I *had* it working just fine until the stick up and
>  died
>  on me, before I could push the code for merge, but its still
>  floating
>  about. It wasn't quite working with a c2 device, but that could
>  have
>  been a device problem (these are quite franky, cheap and poorly
>  made
>  devices, imo). It could also be that the code ate both sticks and
>  will
>  pickle yours as well.
> 
>  With that caveat emptor, here's where the tree that should at least
>  get you 95% of the way there with that stick resides:
> 
>  http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/
> 
>  The last two patches are the relevant ones. They add lgdt3304 demod
>  support to the lgdt3305 driver (because the current lgdt3304 driver
>  is, um, lacking) and then add the bits to wire up the stick.
> >>>
> >>> Hi, thanks for the tips. I've applied the last two patches to v4l
> >>> "tip", a few
> >>> hunks failed, but I managed to apply them by hand, though possibly
> >>> not
> >>> correctly as I can't seem to find a program that thinks the /dev/
> >>> video0 device
> >>> that pops up is valid. One app claims there is no input on /dev/
> >>> video0, and
> >>> others just get "select timeouts" and such (also errors regarding
> >>> formats and
> >>> whatnot).
> >>
> >> These sticks are digital-only. Its a driver shortcoming that the
> >> *analog* /dev/video0 device is being created. You need to be
> >> hitting /
> >> dev/dvb/adapterX/*, not /dev/video0. See
> >> http://linuxtv.org/wiki/index.php/Testing_your_DVB_device
> >
> > Ah, thanks for that.
> >
> > So far I've noticed the lgdt driver is very NOT robust, or maybe its
> > one of
> > the other drivers (em28xx?) causing it to die, but if the stick looses
> > connection with usb at all, the driver locks up, spews a BUNCH of
> > errors to
> > dmesg, and eventually the kernel complains:
> >
> > [  840.552148] INFO: task khubd:170 blocked for more than 120 seconds.
> > [  840.552155] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> > disables
> > this message.
> > [  840.552162] khubd D 8800010220c0 0   170  2
> > [  840.552172]  88003793a500 0046 88007bd2f600
> > 0286
> > [  840.552182]  88007a011900 000120c0 e250
> > 88007d13a3c0
> > [  840.552191]  88007d13a6b0 8034e421 88007bd3d800
> > a046a7c8
> > [  840.552200] Call Trace:
> > [  840.552220]  [] ? schedule+0x9/0x1d
> > [  840.552243]  [] ? dvb_dmxdev_release+0xd8/0x119
> > [dvb_core]
> > [  840.552253]  [] ? autoremove_wake_function
> > +0x0/0x2e
> > [  840.552265]  [] ? dvb_fini+0x5b/0x91 [em28xx_dvb]
> > [  840.552289]  [] ? em28xx_close_extension
> > +0x35/0x56
> > [em28xx]
> > [  840.552308]  [] ? em28xx_usb_disconnect
> > +0xf4/0x120
> > [em28xx]
> > [  840.552319]  [] ? usb_unbind_interface+0x5b/0xe1
> > [  840.552329]  [] ? __device_release_driver
> > +0x77/0x9e
> > [  840.552336]  [] ? device_release_driver+0x1e/0x2a
> > [  840.552344]  [] ? bus_remove_device+0x8d/0xac
> > [  840.552352]  [] ? device_del+0x130/0x198
> > [  840.552359]  [] ? usb_disable_device+0x6c/0xe4
> > [  840.552370]  [] ? usb_disconnect+0x8c/0x10a
> > [  840.552378]  [] ? hub_thread+0x625/0x1040
> > [  840.552387]  [] ? dequeue_entity+0xf/0x11f
> > [  840.552395]  [] ? autoremove_wake_function
> > +0x0/0x2e
> > [  840.552403]  [] ? hub_thread+0x0/0x1040
> > [  840.552410]  [] ? hub_thread+0x0/0x1040
> > [  840.552418]  [] ? hub_thread+0x0/0x1040
> > [  840.552427]  [] ? kthread+0x54/0x80
> > [  840.552435]  [] ? child_rip+0xa/0x20
> > [  840.552444]  [] ? kthread+0x0/0x80
> > [  840.552450]  [] ? child_rip+0x0/0x20
> >
> > I'm assuming the only way t

Re: [Q] sensors, corrupting the top line

[Hans Verkuil]

On Monday 17 August 2009 12:09:12 Guennadi Liakhovetski wrote:
> Hi Hans, all
> 
> In soc-camera since its first version we have a parameter "y_skip_top", 
> which the sensor uses to tell the host (bridge) driver "I am sending you 
> that many lines more than what is requested, and you should drop those 
> lines from the top of the image." I never investigated this in detail, 
> originally this was a "strong tip" that the top line is always corrupted. 
> Now I did investigate it a bit by setting this parameter to 0 and looking 
> what the sensors actually produce. I am working with four sensor: mt9m001, 
> mt9v022, mt9t031 and ov7725, of which only the first two had that 
> parameter set to 1 from the beginning, the others didn't have it and also 
> showed no signs of a problem. mt9m001 (monochrome) doesn't have the 
> problem either, but mt9v022 does. It does indeed deliver the first line 
> with "randomly" coloured pixels. Notice - this is not the top line of the 
> sensor, this is the first read-out line, independent of the cropping 
> position. So, it seems we do indeed need a way to handle such sensors. Do 
> you have a suggestion for a meaningful v4l2-subdev API for this?

Hmm, I think that the best way is to make a struct v4l2_subdev_sensor_ops,
move the enum_framesizes/intervals from the video_ops to the sensor_ops
(since these are only used by sensors AFAIK), and add a new op to
sensor_ops: int (*skip_top_lines)(struct v4l2_subdev *sd, u32 *lines).

When we add the op to set the bus_params, then that can be added to
sensor_ops as well. I've always thought that we need sensor-specifc ops
eventually and this is a good reason to do so.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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 v1 - 1/5] DaVinci - restructuring code to support vpif capture driver

[Hans Verkuil]

On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote:
> Hans,
> 
> They are applied against davinci tree (also mentioned in the patch). General 
> procedure what I follow is to create platform code against davinci tree and 
> v4l patches against v4l-dvb linux-next tree. The architecture part of 
> linux-next is not up to date.
> 
> Davinci tree is at
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git

I must have missed the mention of this tree.

I have a problem, though, as the current v4l-dvb repository doesn't compile
against the linux-davinci git tree. And the only way I can get it to compile
is to apply all five patches first.

However, the whole tree should still compile after each patch is applied. And
that goes wrong with your second patch where the Kconfig and Makefile are
modified when the new sources aren't even added yet!

What I would like to see is a patch series that starts with one patch that
makes the current v4l-dvb tree compile again, then the arch patch is added,
then a series of v4l-dvb patches in such an order that everything compiles
after each step.

Merging this is already complicated enough without breaking compilation in
this way.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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

[Hans Verkuil]

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:Mon Aug 17 19:00:05 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   12458:3f7e382dfae5
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-armv5: OK
linux-2.6.31-rc5-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-armv5-ixp: OK
linux-2.6.31-rc5-armv5-ixp: OK
linux-2.6.28-armv5-omap2: OK
linux-2.6.29.1-armv5-omap2: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-rc5-armv5-omap2: OK
linux-2.6.22.19-i686: ERRORS
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: WARNINGS
linux-2.6.30-i686: WARNINGS
linux-2.6.31-rc5-i686: OK
linux-2.6.23.12-m32r: ERRORS
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-m32r: OK
linux-2.6.31-rc5-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-rc5-mips: OK
linux-2.6.27-powerpc64: OK
linux-2.6.28-powerpc64: OK
linux-2.6.29.1-powerpc64: WARNINGS
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-rc5-powerpc64: OK
linux-2.6.22.19-x86_64: ERRORS
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: WARNINGS
linux-2.6.30-x86_64: WARNINGS
linux-2.6.31-rc5-x86_64: OK
sparse (linux-2.6.30): OK
sparse (linux-2.6.31-rc5): 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: ERRORS
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: ERRORS
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/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.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 v1 - 4/5] V4L : vpif updates for DM6467 vpif capture driver

[Karicheri, Muralidharan]

Yes. I will send another patch later to fix the static variables.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com

>-Original Message-
>From: Hiremath, Vaibhav
>Sent: Monday, August 17, 2009 12:35 PM
>To: Karicheri, Muralidharan; linux-media@vger.kernel.org
>Cc: davinci-linux-open-sou...@linux.davincidsp.com; hverk...@xs4all.nl
>Subject: RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif capture
>driver
>
>H Murali,
>
>> -Original Message-
>> From: Karicheri, Muralidharan
>> Sent: Monday, August 17, 2009 9:38 PM
>> To: Hiremath, Vaibhav; linux-media@vger.kernel.org
>> Cc: davinci-linux-open-sou...@linux.davincidsp.com;
>> hverk...@xs4all.nl
>> Subject: RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif
>> capture driver
>>
>> Vaibhav,
>>
>> I don't see any serious issues raised here. I can send another patch
>> to fix this if needed.
>[Hiremath, Vaibhav] yes most of them are editorial, as I mentioned I just
>reviewed it quickly.
>
>But as far as static variables are concerned I still think we can avoid
>them completely, again it's not critical though.
>
>As I mentioned I will have to look for extern variables, how they have been
>used and stuff like that.
>As of now, I am ok if it gets merged.
>
>>
>> Regards,
>> Murali
>> >> +#include 
>> >>  #include 
>> >> +#include 
>> >[Hiremath, Vaibhav] You may want to put one line gap here.
>> Ok. Just editorial.
>> >> +#include 
>> >>
>> >>  #include "vpif.h"
>> >>
>> >> @@ -31,6 +35,12 @@ MODULE_LICENSE("GPL");
>> >>  #define VPIF_CH2_MAX_MODES   (15)
>> >>  #define VPIF_CH3_MAX_MODES   (02)
>> >>
>> >> +static resource_size_t   res_len;
>> >> +static struct resource   *res;
>> >[Hiremath, Vaibhav] Do we really require this to be static
>> variable?
>> >I think we can manage it to be local variable.
>> Yes. We could. Probably change it with a new patch. Don't want to
>> hold up merge because of this.
>> >
>> >> +spinlock_t vpif_lock;
>> >> +
>> >> +void __iomem *vpif_base;
>> >> +
>> >>  static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
>> >>  {
>> >>   if (val)
>> >> @@ -151,17 +161,17 @@ static void config_vpif_params(struct
>> >> vpif_params *vpifparams,
>> >>   else if (config->capture_format) {
>> >>   /* Set the polarity of various pins */
>> >>   vpif_wr_bit(reg, VPIF_CH_FID_POLARITY_BIT,
>> >> - vpifparams-
>> >> >params.raw_params.fid_pol);
>> >> + vpifparams->iface.fid_pol);
>> >>   vpif_wr_bit(reg, VPIF_CH_V_VALID_POLARITY_BIT,
>> >> - vpifparams->params.raw_params.vd_pol);
>> >> + vpifparams->iface.vd_pol);
>> >>   vpif_wr_bit(reg, VPIF_CH_H_VALID_POLARITY_BIT,
>> >> - vpifparams->params.raw_params.hd_pol);
>> >> + vpifparams->iface.hd_pol);
>> >>
>> >>   value = regr(reg);
>> >>   /* Set data width */
>> >>   value &= ((~(unsigned int)(0x3)) <<
>> >>   VPIF_CH_DATA_WIDTH_BIT);
>> >> - value |= ((vpifparams->params.raw_params.data_sz)
>> >> <<
>> >> + value |= ((vpifparams->params.data_sz) <<
>> >>VPIF_CH_DATA_WIDTH_BIT);
>> >>   regw(value, reg);
>> >>   }
>> >> @@ -227,8 +237,60 @@ int vpif_channel_getfid(u8 channel_id)
>> >>  }
>> >>  EXPORT_SYMBOL(vpif_channel_getfid);
>> >>
>> >> -void vpif_base_addr_init(void __iomem *base)
>> >> +static int __init vpif_probe(struct platform_device *pdev)
>> >> +{
>> >> + int status = 0;
>> >> +
>> >> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> >> + if (!res)
>> >> + return -ENOENT;
>> >> +
>> >> + res_len = res->end - res->start + 1;
>> >> +
>> >> + res = request_mem_region(res->start, res_len, res->name);
>> >> + if (!res)
>> >> + return -EBUSY;
>> >> +
>> >> + vpif_base = ioremap(res->start, res_len);
>> >> + if (!vpif_base) {
>> >> + status = -EBUSY;
>> >> + goto fail;
>> >> + }
>> >> +
>> >> + spin_lock_init(&vpif_lock);
>> >> + dev_info(&pdev->dev, "vpif probe success\n");
>> >> + return 0;
>> >> +
>> >> +fail:
>> >> + release_mem_region(res->start, res_len);
>> >> + return status;
>> >> +}
>> >> +
>> >> +static int vpif_remove(struct platform_device *pdev)
>> >>  {
>> >> - vpif_base = base;
>> >> + iounmap(vpif_base);
>> >> + release_mem_region(res->start, res_len);
>> >> + return 0;
>> >>  }
>> >> -EXPORT_SYMBOL(vpif_base_addr_init);
>> >> +
>> >> +static struct platform_driver vpif_driver = {
>> >> + .driver = {
>> >> + .name   = "vpif",
>> >> + .owner = THIS_MODULE,
>> >> + },
>> >> + .remove = __devexit_p(vpif_remove),
>> >> 

Re: ov534 + ov772x (playstation eye) broken in 2.6.30

[Jean-Francois Moine]

On Mon, 17 Aug 2009 13:47:44 -0400
Jim Paris  wrote:

> Hi,
> 
> Commit 84fbdf87ab8eaa4eaefb317a7eb437cd4d3d0ebf:
>   "V4L/DVB (11105): gspca - ov534: Adjust the packet scan function"
> broke the gspca ov534 driver for the Playstation Eye in 2.6.30.
> 
> Commit c874f3aa7e66158dccb2b9f3cfc46c65af6c223d:
>   "V4L/DVB (11973): gspca - ov534: Do the ov772x work again."
> fixes it for 2.6.31, but this leaves 2.6.30 users out in the cold.
> 
> I'd like to submit the fix to the -stable team in hopes that it can
> get included in 2.6.30.6.  Unfortunately 84fbdf87 depends on earlier
> patches.  The below patch is similar to 84fbdf87 but applies to
> 2.6.30.5.  Does this look acceptable?
> 
> -jim
> 
> From 8dc9e3749ccb3f500fb8597454561ce18bf39cec Mon Sep 17 00:00:00 2001
> From: Jim Paris 
> Date: Mon, 17 Aug 2009 13:45:00 -0400
> Subject: [PATCH] gspca - ov534: Fix ov772x
> 
> The scan of the image packets of the sensor ov772x was broken when
> the sensor ov965x was added.
> 
> [ Based on upstream 84fbdf87, reworked for v2.6.30.5 ]
> 
> Signed-off-by: Jim Paris 
> ---
>  drivers/media/video/gspca/ov534.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/video/gspca/ov534.c
> b/drivers/media/video/gspca/ov534.c index 19e0bc6..504f849 100644
> --- a/drivers/media/video/gspca/ov534.c
> +++ b/drivers/media/video/gspca/ov534.c
> @@ -832,9 +832,11 @@ static void sd_pkt_scan(struct gspca_dev
> *gspca_dev, struct gspca_frame *frame, __u32 this_pts;
>   u16 this_fid;
>   int remaining_len = len;
> + int payload_len;
>  
> + payload_len = (sd->sensor == SENSOR_OV772X) ? 2048 : 2040;
>   do {
> - len = min(remaining_len,
> 2040);/*fixme: was 2048*/
> + len = min(remaining_len, payload_len);
>  
>   /* Payloads are prefixed with a UVC-style header.  We
>  consider a frame to start when the FID toggles,
> or the PTS

It's OK for me.

Acked-by: Jean-Francois Moine 

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

error with dvb-bt8xx needing a rmmod -f and a modprobe again

[Darren Wilkinson]

I've got a bt8xx based dvb card and have had problems with the card in
multiple distros all with kernels >=2.6.28. The 2.6.27 or less also
worked on all distros that had them available.

My card is a Nebula Electronics Digitv pci card using the dvb-bt8xx and
nxt6000 modules. The problem I have is that when I boot up any linux
distro the card won't work in mythtv until I rmmod -r dvb-bt8xx &
modprobe dvb-bt8xx. The correct entries are created in /dev/dvb/ and the
card is detected correctly by dvb software but won't actually scan or
tune to anything.

I've searched the internet and looked at the mailing list archives and
only found the following reference to my problem:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/368215 (the digitv
card with the zarlink module is reported as having the same problem in
this page. Also the post by "chipsugar" is mine)
I don't have kaffeine or mandriva installed any more but can confirm
this is an issue with mythbuntu and gentoo with mythtv and dvbscan and
tzap. Building the modules into the kernel also fail obviously.

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

ov534 + ov772x (playstation eye) broken in 2.6.30

[Jim Paris]

Hi,

Commit 84fbdf87ab8eaa4eaefb317a7eb437cd4d3d0ebf:
  "V4L/DVB (11105): gspca - ov534: Adjust the packet scan function"
broke the gspca ov534 driver for the Playstation Eye in 2.6.30.

Commit c874f3aa7e66158dccb2b9f3cfc46c65af6c223d:
  "V4L/DVB (11973): gspca - ov534: Do the ov772x work again."
fixes it for 2.6.31, but this leaves 2.6.30 users out in the cold.

I'd like to submit the fix to the -stable team in hopes that it can
get included in 2.6.30.6.  Unfortunately 84fbdf87 depends on earlier
patches.  The below patch is similar to 84fbdf87 but applies to
2.6.30.5.  Does this look acceptable?

-jim

>From 8dc9e3749ccb3f500fb8597454561ce18bf39cec Mon Sep 17 00:00:00 2001
From: Jim Paris 
Date: Mon, 17 Aug 2009 13:45:00 -0400
Subject: [PATCH] gspca - ov534: Fix ov772x

The scan of the image packets of the sensor ov772x was broken when
the sensor ov965x was added.

[ Based on upstream 84fbdf87, reworked for v2.6.30.5 ]

Signed-off-by: Jim Paris 
---
 drivers/media/video/gspca/ov534.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/gspca/ov534.c 
b/drivers/media/video/gspca/ov534.c
index 19e0bc6..504f849 100644
--- a/drivers/media/video/gspca/ov534.c
+++ b/drivers/media/video/gspca/ov534.c
@@ -832,9 +832,11 @@ static void sd_pkt_scan(struct gspca_dev *gspca_dev, 
struct gspca_frame *frame,
__u32 this_pts;
u16 this_fid;
int remaining_len = len;
+   int payload_len;
 
+   payload_len = (sd->sensor == SENSOR_OV772X) ? 2048 : 2040;
do {
-   len = min(remaining_len, 2040); /*fixme: was 2048*/
+   len = min(remaining_len, payload_len);
 
/* Payloads are prefixed with a UVC-style header.  We
   consider a frame to start when the FID toggles, or the PTS
-- 
1.5.6.5
--
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 v1 - 4/5] V4L : vpif updates for DM6467 vpif capture driver

[Hiremath, Vaibhav]

H Murali,

> -Original Message-
> From: Karicheri, Muralidharan
> Sent: Monday, August 17, 2009 9:38 PM
> To: Hiremath, Vaibhav; linux-media@vger.kernel.org
> Cc: davinci-linux-open-sou...@linux.davincidsp.com;
> hverk...@xs4all.nl
> Subject: RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif
> capture driver
> 
> Vaibhav,
> 
> I don't see any serious issues raised here. I can send another patch
> to fix this if needed.
[Hiremath, Vaibhav] yes most of them are editorial, as I mentioned I just 
reviewed it quickly.

But as far as static variables are concerned I still think we can avoid them 
completely, again it's not critical though.

As I mentioned I will have to look for extern variables, how they have been 
used and stuff like that. 
As of now, I am ok if it gets merged.

> 
> Regards,
> Murali
> >> +#include 
> >>  #include 
> >> +#include 
> >[Hiremath, Vaibhav] You may want to put one line gap here.
> Ok. Just editorial.
> >> +#include 
> >>
> >>  #include "vpif.h"
> >>
> >> @@ -31,6 +35,12 @@ MODULE_LICENSE("GPL");
> >>  #define VPIF_CH2_MAX_MODES(15)
> >>  #define VPIF_CH3_MAX_MODES(02)
> >>
> >> +static resource_size_tres_len;
> >> +static struct resource*res;
> >[Hiremath, Vaibhav] Do we really require this to be static
> variable?
> >I think we can manage it to be local variable.
> Yes. We could. Probably change it with a new patch. Don't want to
> hold up merge because of this.
> >
> >> +spinlock_t vpif_lock;
> >> +
> >> +void __iomem *vpif_base;
> >> +
> >>  static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
> >>  {
> >>if (val)
> >> @@ -151,17 +161,17 @@ static void config_vpif_params(struct
> >> vpif_params *vpifparams,
> >>else if (config->capture_format) {
> >>/* Set the polarity of various pins */
> >>vpif_wr_bit(reg, VPIF_CH_FID_POLARITY_BIT,
> >> -  vpifparams-
> >> >params.raw_params.fid_pol);
> >> +  vpifparams->iface.fid_pol);
> >>vpif_wr_bit(reg, VPIF_CH_V_VALID_POLARITY_BIT,
> >> -  vpifparams->params.raw_params.vd_pol);
> >> +  vpifparams->iface.vd_pol);
> >>vpif_wr_bit(reg, VPIF_CH_H_VALID_POLARITY_BIT,
> >> -  vpifparams->params.raw_params.hd_pol);
> >> +  vpifparams->iface.hd_pol);
> >>
> >>value = regr(reg);
> >>/* Set data width */
> >>value &= ((~(unsigned int)(0x3)) <<
> >>VPIF_CH_DATA_WIDTH_BIT);
> >> -  value |= ((vpifparams->params.raw_params.data_sz)
> >> <<
> >> +  value |= ((vpifparams->params.data_sz) <<
> >> VPIF_CH_DATA_WIDTH_BIT);
> >>regw(value, reg);
> >>}
> >> @@ -227,8 +237,60 @@ int vpif_channel_getfid(u8 channel_id)
> >>  }
> >>  EXPORT_SYMBOL(vpif_channel_getfid);
> >>
> >> -void vpif_base_addr_init(void __iomem *base)
> >> +static int __init vpif_probe(struct platform_device *pdev)
> >> +{
> >> +  int status = 0;
> >> +
> >> +  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> +  if (!res)
> >> +  return -ENOENT;
> >> +
> >> +  res_len = res->end - res->start + 1;
> >> +
> >> +  res = request_mem_region(res->start, res_len, res->name);
> >> +  if (!res)
> >> +  return -EBUSY;
> >> +
> >> +  vpif_base = ioremap(res->start, res_len);
> >> +  if (!vpif_base) {
> >> +  status = -EBUSY;
> >> +  goto fail;
> >> +  }
> >> +
> >> +  spin_lock_init(&vpif_lock);
> >> +  dev_info(&pdev->dev, "vpif probe success\n");
> >> +  return 0;
> >> +
> >> +fail:
> >> +  release_mem_region(res->start, res_len);
> >> +  return status;
> >> +}
> >> +
> >> +static int vpif_remove(struct platform_device *pdev)
> >>  {
> >> -  vpif_base = base;
> >> +  iounmap(vpif_base);
> >> +  release_mem_region(res->start, res_len);
> >> +  return 0;
> >>  }
> >> -EXPORT_SYMBOL(vpif_base_addr_init);
> >> +
> >> +static struct platform_driver vpif_driver = {
> >> +  .driver = {
> >> +  .name   = "vpif",
> >> +  .owner = THIS_MODULE,
> >> +  },
> >> +  .remove = __devexit_p(vpif_remove),
> >> +  .probe = vpif_probe,
> >> +};
> >> +
> >> +static void vpif_exit(void)
> >> +{
> >> +  platform_driver_unregister(&vpif_driver);
> >> +}
> >> +
> >> +static int __init vpif_init(void)
> >> +{
> >> +  return platform_driver_register(&vpif_driver);
> >> +}
> >> +subsys_initcall(vpif_init);
> >> +module_exit(vpif_exit);
> >> +
> >> diff --git a/drivers/media/video/davinci/vpif.h
> >> b/drivers/media/video/davinci/vpif.h
> >> index fca26dc..188841b 100644
> >> --- a/drivers/media/video/davinci/vpif.h
> >> +++ b/drivers/media/video/davinci/vpif.h
> >> @@ -19,6 +19,7 @@
> >>  #include 
> >>  #include 
> >[Hiremath, Vaibhav] o

RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif capture driver

[Karicheri, Muralidharan]

Vaibhav,

I don't see any serious issues raised here. I can send another patch to fix 
this if needed. 

Regards,
Murali
>> +#include 
>>  #include 
>> +#include 
>[Hiremath, Vaibhav] You may want to put one line gap here.
Ok. Just editorial.
>> +#include 
>>
>>  #include "vpif.h"
>>
>> @@ -31,6 +35,12 @@ MODULE_LICENSE("GPL");
>>  #define VPIF_CH2_MAX_MODES  (15)
>>  #define VPIF_CH3_MAX_MODES  (02)
>>
>> +static resource_size_t  res_len;
>> +static struct resource  *res;
>[Hiremath, Vaibhav] Do we really require this to be static variable?
>I think we can manage it to be local variable.
Yes. We could. Probably change it with a new patch. Don't want to hold up merge 
because of this.
>
>> +spinlock_t vpif_lock;
>> +
>> +void __iomem *vpif_base;
>> +
>>  static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
>>  {
>>  if (val)
>> @@ -151,17 +161,17 @@ static void config_vpif_params(struct
>> vpif_params *vpifparams,
>>  else if (config->capture_format) {
>>  /* Set the polarity of various pins */
>>  vpif_wr_bit(reg, VPIF_CH_FID_POLARITY_BIT,
>> -vpifparams-
>> >params.raw_params.fid_pol);
>> +vpifparams->iface.fid_pol);
>>  vpif_wr_bit(reg, VPIF_CH_V_VALID_POLARITY_BIT,
>> -vpifparams->params.raw_params.vd_pol);
>> +vpifparams->iface.vd_pol);
>>  vpif_wr_bit(reg, VPIF_CH_H_VALID_POLARITY_BIT,
>> -vpifparams->params.raw_params.hd_pol);
>> +vpifparams->iface.hd_pol);
>>
>>  value = regr(reg);
>>  /* Set data width */
>>  value &= ((~(unsigned int)(0x3)) <<
>>  VPIF_CH_DATA_WIDTH_BIT);
>> -value |= ((vpifparams->params.raw_params.data_sz)
>> <<
>> +value |= ((vpifparams->params.data_sz) <<
>>   VPIF_CH_DATA_WIDTH_BIT);
>>  regw(value, reg);
>>  }
>> @@ -227,8 +237,60 @@ int vpif_channel_getfid(u8 channel_id)
>>  }
>>  EXPORT_SYMBOL(vpif_channel_getfid);
>>
>> -void vpif_base_addr_init(void __iomem *base)
>> +static int __init vpif_probe(struct platform_device *pdev)
>> +{
>> +int status = 0;
>> +
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +if (!res)
>> +return -ENOENT;
>> +
>> +res_len = res->end - res->start + 1;
>> +
>> +res = request_mem_region(res->start, res_len, res->name);
>> +if (!res)
>> +return -EBUSY;
>> +
>> +vpif_base = ioremap(res->start, res_len);
>> +if (!vpif_base) {
>> +status = -EBUSY;
>> +goto fail;
>> +}
>> +
>> +spin_lock_init(&vpif_lock);
>> +dev_info(&pdev->dev, "vpif probe success\n");
>> +return 0;
>> +
>> +fail:
>> +release_mem_region(res->start, res_len);
>> +return status;
>> +}
>> +
>> +static int vpif_remove(struct platform_device *pdev)
>>  {
>> -vpif_base = base;
>> +iounmap(vpif_base);
>> +release_mem_region(res->start, res_len);
>> +return 0;
>>  }
>> -EXPORT_SYMBOL(vpif_base_addr_init);
>> +
>> +static struct platform_driver vpif_driver = {
>> +.driver = {
>> +.name   = "vpif",
>> +.owner = THIS_MODULE,
>> +},
>> +.remove = __devexit_p(vpif_remove),
>> +.probe = vpif_probe,
>> +};
>> +
>> +static void vpif_exit(void)
>> +{
>> +platform_driver_unregister(&vpif_driver);
>> +}
>> +
>> +static int __init vpif_init(void)
>> +{
>> +return platform_driver_register(&vpif_driver);
>> +}
>> +subsys_initcall(vpif_init);
>> +module_exit(vpif_exit);
>> +
>> diff --git a/drivers/media/video/davinci/vpif.h
>> b/drivers/media/video/davinci/vpif.h
>> index fca26dc..188841b 100644
>> --- a/drivers/media/video/davinci/vpif.h
>> +++ b/drivers/media/video/davinci/vpif.h
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>[Hiremath, Vaibhav] one line gap here.
Again editorial.
>>  #include 
>> +#include 
>>
>>  /* Maximum channel allowed */
>>  #define VPIF_NUM_CHANNELS   (4)
>> @@ -26,7 +27,9 @@
>>  #define VPIF_DISPLAY_NUM_CHANNELS   (2)
>>
>>  /* Macros to read/write registers */
>> -static void __iomem *vpif_base;
>> +extern void __iomem *vpif_base;
>> +extern spinlock_t vpif_lock;
>[Hiremath, Vaibhav] I think I would want to check compete driver. How these
>extern variables have been used.
>
Let me know if you find some thing wrong in the driver. At this time, I just 
don't see any issues with this.
>> +
>>  #define regr(reg)   readl((reg) + vpif_base)
>>  #define regw(value, reg)writel(value, (reg + vpif_base))
>>
>> @@ -280,6 +283,10 @@ static inline void enable_channel1(int enable)
>>  /* inline function to enable interrupt for channel0 */
>>  static

RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver

[Karicheri, Muralidharan]

Hans,

They are applied against davinci tree (also mentioned in the patch). General 
procedure what I follow is to create platform code against davinci tree and v4l 
patches against v4l-dvb linux-next tree. The architecture part of linux-next is 
not up to date.

Davinci tree is at

git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com

>-Original Message-
>From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>Sent: Saturday, August 15, 2009 8:10 AM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; davinci-linux-open-
>sou...@linux.davincidsp.com; khil...@deeprootsystems.com
>Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif
>capture driver
>
>On Friday 14 August 2009 23:01:41 m-kariche...@ti.com wrote:
>> From: Muralidharan Karicheri 
>>
>> This patch makes the following changes:-
>>  1) Modify vpif_subdev_info to add board_info, routing information
>> and vpif interface configuration. Remove addr since it is
>> part of board_info
>>
>>  2) Add code to setup channel mode and input decoder path for
>> vpif capture driver
>>
>> Also incorporated comments against version v0 of the patch series and
>> added a spinlock to protect writes to common registers
>
>A quick question: against which git tree are these arch changes applied?
>I've lost track of that :-)
>
>Regards,
>
>   Hans
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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: framebuffer overlay

[Ryan Raasch]

I have another question.

Has there been any discussion on any type of generic framebuffer v4l2 
device (output device), like a gstreamer sink (like the soc_camera)?


From this perspective, when the frame buffer registers itself, it could 
just *add* the capabilities, and allow the fb.c to handle many of the 
logistics.


I am developing for a system where we do not use X and use the 
framebuffer directly (E17). It would be nice to fit any of the 
framebuffers into a *neat* v4l2 package for any app to use (gstreamer, 
mplayer).


And with our camera, gstreamer, etc. could just be a command line away 
from live streaming :)




Thanks,
Ryan

Dongsoo, Nathaniel Kim wrote:

On Wed, Aug 12, 2009 at 5:56 PM, Ryan Raasch wrote:

Thanks for the reply!

Dongsoo, Nathaniel Kim wrote:

On Wed, Aug 12, 2009 at 5:25 PM, Ryan Raasch wrote:

Hello,

I am trying to write a driver for a camera using the new soc_camera in
the
mainline kernel the output is the overlay framebuffer (pxa270) and i
would
like to use the overlay output feature of v4l2 framework, but the
framebuffer does not expose itself as a output device (not yet).


Hi Ryan,

As far as I know the framebuffer of PXA2 even PXA3 can't be
categorized in a overlay device.

The pxa2 and pxa3 both have 3 framebuffers (4 if hardware curser included).
There is the main fb, and 2 overlay framebuffers.

The overlay 2 has hardware accelerated ycbcr decoding (which i use now with
a camera using dma). And the overlay 1 can be used only with the various
types of RGB.

We have a solution which uses dma to copy the captured video from the camera
sensor (mmap'd), directly to the mmap'd memory of the overlay. All occuring
without user intervention.



To be able to get used as overlay device by camera interface, I think
there should be a direct FIFO between camera and framebuffer which
means there is no need to copy memory from camera to fb. But
unfortunately PXA architecture is not supporting this kind of feature.

With the above there is no need for FIFO, the dma is directly copying the
received camera data to the selected framebuffer.

Ryan



Cool.
So, that means you need a SoC hardware based reference code right?
(because pxa is also a SoC)
I think there is not so many choices that you can put on the table.
In my experience, OMP3 camera interface is supporting overlay feature
through omap_vout I guess. I think it is not obvious in SoC H/W
platform about *what is overlay device* and *how to use* them.

And about omap3 camera interface driver, it is not in the mainline
kernel yet. For the camera interface code you need to look into
Sakari's gitorious repository and for omap_vout you need to look for
Hardik's repository or any repository he is working on..I guess.
I'm also trying to figure out the best way to use overlay feature on
samsung's new cpu named S5PC1XX.

The most complicated part of this job is the whole thing is happening
in a single piece of chip and need to figure out the standardized way
for compatibility. I wish you luck :-)
Cheers,

Nate


Cheers,




Nate


Are there any fb that i can use as an example for this?

From looking at the driver code, it seems like the generic code of
fbmem.c
needs a v4l2 device. Is this in the right ballpark?

Thanks,
Ryan

--
video4linux-list mailing list
Unsubscribe
mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list









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

VPFE (v2) and VPIF capture patches for merge

[Karicheri, Muralidharan]

Hans,

Last week, I had sent vpfe capture (v2) and vpif capture(v1) patches for 
review. If they look good, please merge them to your tree and send a pull 
request to Mauro at your earliest convenience.

Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.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: KWorld UB435-Q support?

[Jarod Wilson]

On Aug 14, 2009, at 11:03 AM, Thomas Fjellstrom wrote:


On Fri August 14 2009, Jarod Wilson wrote:

On Aug 14, 2009, at 1:12 AM, Thomas Fjellstrom wrote:

On Thu August 13 2009, Jarod Wilson wrote:

On Aug 13, 2009, at 12:53 AM, Thomas Fjellstrom wrote:
I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it  
was

supported
under linux, and it turns out it isn't. I'm wondering what it  
would

take to
get it supported. It seems like all of the main chips it uses are
supported,
but the glue code is missing.

I have some C (10 years) programming experience, and have wanted  
to

contribute
to the linux kernel for quite a while, now I have a good excuse ;)

Would anyone be willing to point me in the right direction?


The UB435-Q is a rebadge of the revision B 340U, which is an em2870
bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its  
got

the same device ID and everything. I've got a rev A 340U, the only
difference being that it has an nxp tda18271hd/c1 tuner (also same
device ID). I *had* it working just fine until the stick up and  
died
on me, before I could push the code for merge, but its still  
floating
about. It wasn't quite working with a c2 device, but that could  
have
been a device problem (these are quite franky, cheap and poorly  
made

devices, imo). It could also be that the code ate both sticks and
will
pickle yours as well.

With that caveat emptor, here's where the tree that should at least
get you 95% of the way there with that stick resides:

http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/

The last two patches are the relevant ones. They add lgdt3304 demod
support to the lgdt3305 driver (because the current lgdt3304 driver
is, um, lacking) and then add the bits to wire up the stick.


Hi, thanks for the tips. I've applied the last two patches to v4l
"tip", a few
hunks failed, but I managed to apply them by hand, though possibly  
not

correctly as I can't seem to find a program that thinks the /dev/
video0 device
that pops up is valid. One app claims there is no input on /dev/
video0, and
others just get "select timeouts" and such (also errors regarding
formats and
whatnot).


These sticks are digital-only. Its a driver shortcoming that the
*analog* /dev/video0 device is being created. You need to be  
hitting /

dev/dvb/adapterX/*, not /dev/video0. See
http://linuxtv.org/wiki/index.php/Testing_your_DVB_device


Ah, thanks for that.

So far I've noticed the lgdt driver is very NOT robust, or maybe its  
one of

the other drivers (em28xx?) causing it to die, but if the stick looses
connection with usb at all, the driver locks up, spews a BUNCH of  
errors to

dmesg, and eventually the kernel complains:

[  840.552148] INFO: task khubd:170 blocked for more than 120 seconds.
[  840.552155] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"  
disables

this message.
[  840.552162] khubd D 8800010220c0 0   170  2
[  840.552172]  88003793a500 0046 88007bd2f600
0286
[  840.552182]  88007a011900 000120c0 e250
88007d13a3c0
[  840.552191]  88007d13a6b0 8034e421 88007bd3d800
a046a7c8
[  840.552200] Call Trace:
[  840.552220]  [] ? schedule+0x9/0x1d
[  840.552243]  [] ? dvb_dmxdev_release+0xd8/0x119
[dvb_core]
[  840.552253]  [] ? autoremove_wake_function 
+0x0/0x2e

[  840.552265]  [] ? dvb_fini+0x5b/0x91 [em28xx_dvb]
[  840.552289]  [] ? em28xx_close_extension 
+0x35/0x56

[em28xx]
[  840.552308]  [] ? em28xx_usb_disconnect 
+0xf4/0x120

[em28xx]
[  840.552319]  [] ? usb_unbind_interface+0x5b/0xe1
[  840.552329]  [] ? __device_release_driver 
+0x77/0x9e

[  840.552336]  [] ? device_release_driver+0x1e/0x2a
[  840.552344]  [] ? bus_remove_device+0x8d/0xac
[  840.552352]  [] ? device_del+0x130/0x198
[  840.552359]  [] ? usb_disable_device+0x6c/0xe4
[  840.552370]  [] ? usb_disconnect+0x8c/0x10a
[  840.552378]  [] ? hub_thread+0x625/0x1040
[  840.552387]  [] ? dequeue_entity+0xf/0x11f
[  840.552395]  [] ? autoremove_wake_function 
+0x0/0x2e

[  840.552403]  [] ? hub_thread+0x0/0x1040
[  840.552410]  [] ? hub_thread+0x0/0x1040
[  840.552418]  [] ? hub_thread+0x0/0x1040
[  840.552427]  [] ? kthread+0x54/0x80
[  840.552435]  [] ? child_rip+0xa/0x20
[  840.552444]  [] ? kthread+0x0/0x80
[  840.552450]  [] ? child_rip+0x0/0x20

I'm assuming the only way to restore any kind of function is to reboot
(rmmoding em28xx_dbv hangs, and rmmod is unkillable).

I'll try working with this a bit more tomorrow (if I can figure out  
why its

hanging), as it is I'm off for some sleep :)



Huh, that looks nothing like anything I ever saw with my stick.  
However, I will note that mine seemed to have major issues keeping a  
solid physical connection to the usb bus, but it only manifested as  
huge amounts of packet loss. These are cheaply made devices that I  
have little faith in now...


--
Jarod Wilson
ja...@wilsonet.com



--
To unsubscribe from this list: send the line "unsubscribe 

Re: usb dvb-c tuner status

[Bert Haverkamp]

Hello all,

Can anyone confirm that the TT-connectR CT-3650 works with dvb-c with
the current linux kernel?

Regards,

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

Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/

[Patrick Boettcher]

Hi,

in addition there is now:

DiB0070: Update to latest internal release
DiB0070: Indenting driver with indent -linux
DiB8000: added support for DiBcom ISDB-T/ISDB-Tsb demodulator DiB8000
DiB0700: add support for STK807XP and STK807XPVR

regards,
--

Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/


On Fri, 14 Aug 2009, Patrick Boettcher wrote:


Hi Mauro,

can you please pull from

http://linuxtv.org/hg/~pb/v4l-dvb/

for
- ISDB-T: add mapping of LAYER_ENABLED to frontend-cache
- ISDB-T: added reference to ARIB TR-B14
- ISDB-T: added bandwidth as an optional parameter
- ISDB-T: Added note about DTV_FREQUENCY
- DVB-API: add support for ISDB-T and ISDB-Tsb (version 5.1)

In addition to that I have an ISDB-T demodulator driver ready (including 
device-support of course) and have modified 'scan' in dvb-apps to use the 
interface to scan for ISDB-T channels (can be used as an example showing how 
to tune ISDB-T)


I'm looking forward to issue a pull request for that as well, but first I 
would like to have the API merged.


I'm aware that the RFC was quite silent (thanks to Mike and Akihiro for 
commenting) - I'm taking that as a "no-objection" on the current 
implementation.


I think binary compatibity is not broken, so applications compiled for DVB 
API 5.0 will continue to work without problems.


I think that the 3 months from now on are enough time to fix up possibly bad 
things before a next kernel release (2.6.32). A pull would also widen the 
testers range, which I'm strongly depending on.


thanks,
--

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


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

[Q] sensors, corrupting the top line

[Guennadi Liakhovetski]

Hi Hans, all

In soc-camera since its first version we have a parameter "y_skip_top", 
which the sensor uses to tell the host (bridge) driver "I am sending you 
that many lines more than what is requested, and you should drop those 
lines from the top of the image." I never investigated this in detail, 
originally this was a "strong tip" that the top line is always corrupted. 
Now I did investigate it a bit by setting this parameter to 0 and looking 
what the sensors actually produce. I am working with four sensor: mt9m001, 
mt9v022, mt9t031 and ov7725, of which only the first two had that 
parameter set to 1 from the beginning, the others didn't have it and also 
showed no signs of a problem. mt9m001 (monochrome) doesn't have the 
problem either, but mt9v022 does. It does indeed deliver the first line 
with "randomly" coloured pixels. Notice - this is not the top line of the 
sensor, this is the first read-out line, independent of the cropping 
position. So, it seems we do indeed need a way to handle such sensors. Do 
you have a suggestion for a meaningful v4l2-subdev API for this?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hauppauge 2250 - second tuner is only half working

[seth]

Hello,

 I've run into a problem with my capture card and wanted to solicit
ideas on how to further pinpoint the problem and/or hopefully correct
it.  At the risk of being to presumptious/terse - my problem is the
second tuner on the card is unable to lock on any frequency between
609mhz and 693mhz (while the first tuner does just fine).

 I recently purchased a bunch of hardware and assembled a HTPC.  I'm
running a fairly vanilla mythbuntu on it.  I have only the one
capture card installed, and i'm using comcast cable for input.  Other
than a handful of various apt packages i've added, i've compiled from
source saa7164-dev branch (was on the -stable at one point),
lcdproc-0.5.2 w/ imonlcd-0.3.patch, lirc (trunk), scte65scan, and a
couple other tools.  Unfortunately for me, I ran across the problem
right after I did a big db merge on my mythtv's channel &
dtv_multiplex tables (I was joining schedules direct, scte65scan
results, and dvb-app scan results).  Naturally, i started
troubleshooting from that point under the assumption i screwed up the
tables.  I eventually worked my way down to where i'm stuck at now -
the second tuner mysteriously is unable to lock into some
frequencies.

 I ran full scans (us-Cable-Standard-center-frequencies-QAM256) on
both adapters - then sort -t : -k 2n -k 6n the output on both and
diffed and ended up with the 609 and 693mhz numbers from above - all
frequencies in that range are not tuneable for adapter1.  It
represents 109 tunable channels on adapter0 that just don't seem to
work on adapter1 (there are about 250 that do work on both adapters
properly).  I spot checked at least a dozen channels in both the
problem frequency range and in the good range (i used mythtv live tv
and azap w/ dvbtraffic).  dvbtraffic showed hundreds of lines of
small bandwidth channels on the problem frequency range on adapter1

(For brevity sake, i simplified my scan list down to two channels to make
it easier to test)

channels.conf contains:
KOMO:55500:QAM_256:1984:1985:3
SYFY:66900:QAM_256:2112:2113:7

s...@dh101:~/development/dvb-apps/dvb-apps_hg_co/util/szap$ ./azap -a 1 -c
channels.conf komo
using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
tuning to 55500 Hz
video pid 0x07c0, audio pid 0x07c1
status 00 | signal  | snr  | ber  | unc  |
status 1f | signal 0186 | snr 0186 | ber  | unc  |
FE_HAS_LOCK
status 1f | signal 0186 | snr 0186 | ber  | unc  |
FE_HAS_LOCK
^C
s...@dh101:~/development/dvb-apps/dvb-apps_hg_co/util/szap$ ./azap -a 0 -c
channels.conf komo
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 55500 Hz
video pid 0x07c0, audio pid 0x07c1
status 00 | signal  | snr  | ber  | unc  |
status 1f | signal 0190 | snr 0190 | ber  | unc  |
FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber  | unc  |
FE_HAS_LOCK
^C
s...@dh101:~/development/dvb-apps/dvb-apps_hg_co/util/szap$ ./azap -a 1 -c
channels.conf syfy
using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
tuning to 66900 Hz
video pid 0x0840, audio pid 0x0841
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |
status 00 | signal  | snr  | ber  | unc  |  
I've let it sit for 5+ min without lock
^C
s...@dh101:~/development/dvb-apps/dvb-apps_hg_co/util/szap$ ./azap -a 0 -c
channels.conf syfy
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 66900 Hz
video pid 0x0840, audio pid 0x0841
status 00 | signal  | snr  | ber  | unc  |
status 1f | signal 0190 | snr 0190 | ber 0147 | unc 0147 |
FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber  | unc  |
FE_HAS_LOCK

dmesg output:
[74217.307056] saa7164 driver loaded
[74217.307106] saa7164 :03:00.0: PCI INT A -> Link[AE3A] -> GSI 16
(level, low) -> IRQ 16
[74217.307944] CORE saa7164[0]: subsystem: 0070:8891, board: Hauppauge
WinTV-HVR2250 [card=7,autodetected]
[74217.307950] saa7164[0]/0: found at :03:00.0, rev: 129, irq: 16,
latency: 0, mmio: 0xe500
[74217.307957] saa7164 :03:00.0: setting latency timer to 64
[74217.308710] saa7164[0]: i2c bus 0 registered
[74217.308886] saa7164[0]: i2c bus 1 registered
[74217.309069] saa7164[0]: i2c bus 2 registered
[74217.343459] tveeprom 0-: Hauppauge model 88061, rev C3F2, serial#
6254250
[74217.343462] tveeprom 0-: MAC address is 00-0D-FE-5F-6E-AA
[74217.343464] tveeprom 0-: tuner model is NXP 18271C2_716x (idx 152,
type 4)
[74217.343466] tveeprom 0-: TV standards NTSC(M) ATSC/DVB Digital
(eeprom 0x88)
[74217.343468] tveeprom 0-: audio processor is SAA7164 (idx 43)
[74217.343470] tveeprom 0-: decoder pr