Re: Created files in patch comment intended?

2009-12-18 Thread Guennadi Liakhovetski
On Fri, 18 Dec 2009, Mauro Carvalho Chehab wrote:

 Hi Guennadi,
 
 Guennadi Liakhovetski wrote:
  Hi Mauro
  
  Looking at how my mediabus patches got committed into the mainline, I 
  noticed, that the add-mediabus patch contains a list of added files 
  between the patch description and the Sob's:
  
   create mode 100644 drivers/media/video/soc_mediabus.c
   create mode 100644 include/media/soc_mediabus.h
   create mode 100644 include/media/v4l2-mediabus.h
  
  Is this intended, and if yes - why? If not, maybe you'd like to fix this 
  in your hg-git export scripts.
  
 No, this is not intentional. The scripts have a logic to identify the 
 description
 body of a mercurial commit and of a patch received by email. The logic should
 just import whatever description is provided on -hg.
 
 By looking on your commit for this patch on mercurial, we have:
 
 $ hg log -r 13658 -v
 changeset:   13658:2c60bd900a7a
 user:Guennadi Liakhovetski g.liakhovet...@gmx.de
 date:Fri Dec 11 15:41:28 2009 +0100
 files:   linux/drivers/media/video/Makefile 
 linux/drivers/media/video/soc_mediabus.c linux/include/media/soc_mediabus.h 
 linux/include/media/v4l2-mediabus.h linux/include/media/v4l2-subdev.h
 description:
 v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
 From: Guennadi Liakhovetski g.liakhovet...@gmx.de
 
 Video subdevices, like cameras, decoders, connect to video bridges over
 specialised busses. Data is being transferred over these busses in various
 formats, which only loosely correspond to fourcc codes, describing how video
 data is stored in RAM. This is not a one-to-one correspondence, therefore we
 cannot use fourcc codes to configure subdevice output data formats. This patch
 adds codes for several such on-the-bus formats and an API, similar to the
 familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those
 codes. After all users of the old API in struct v4l2_subdev_video_ops are
 converted, it will be removed. Also add helper routines to support generic
 pass-through mode for the soc-camera framework.
 
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 Acked-by: Hans Verkuil hverk...@xs4all.nl
 ---
  drivers/media/video/Makefile   |2 +-
  drivers/media/video/soc_mediabus.c |  157 
 
  include/media/soc_mediabus.h   |   65 +++
  include/media/v4l2-mediabus.h  |   61 ++
  include/media/v4l2-subdev.h|   19 -
  5 files changed, 302 insertions(+), 2 deletions(-)
  create mode 100644 drivers/media/video/soc_mediabus.c
  create mode 100644 include/media/soc_mediabus.h
  create mode 100644 include/media/v4l2-mediabus.h
 
 
 As you see, you added those comments at the end of the patch, together with a 
 diffstat.
 While the script has a logic to remove diffstats, it doesn't contain anything 
 to remove
 the create mode lines that you've added at the end of the patch description.

No, _I_ didn't add those, git did. This is the standard output from git 
format patch. And the patch format for submission to the kernel is 
roughly

subject

description

Sob, ack,...
---
ignored lines
diff -u

So, anything, beginning with ---\n and the patch must be ignored. That's 
also where you provide any comments, that should not be included in the 
commit text.

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


Re: linux-next: Tree for December 17 (media/dvb)

2009-12-18 Thread Mauro Carvalho Chehab
Randy Dunlap wrote:
 On Thu, 17 Dec 2009 16:58:40 +1100 Stephen Rothwell wrote:
 
 Hi all,

 My usual call for calm: please do not put stuff destined for 2.6.34 into
 linux-next trees until after 2.6.33-rc1.

 Changes since 20091216:
 
 
 (repeating:)
 
 drivers/media/dvb/frontends/dib8000.h:104: error: expected expression before 
 '}' token
 drivers/media/dvb/frontends/dib8000.h:104: warning: left-hand operand of 
 comma expression has no effect
 
 return CT_SHUTDOWN,
 
 
 s/,/;/ and fix indentation.

The affect patch went into for 2.6.33. I haven't noticed this issue before, 
since it
appears only if DVB_DIB8000 is not defined.

Anyway, I'm adding today a patch for it.

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


Re: [Fwd: [patch] media video cx23888 driver: ported to new kfifo API]

2009-12-18 Thread Andy Walls
On Fri, 2009-12-18 at 08:14 -0200, Mauro Carvalho Chehab wrote:
 Andy,
 
 Please review. The lack of porting cx23885 to new kfifo is stopping the merge
 of the redesigned kfifo upstream.


Stefani and Mauro,

My comments/concerns are in line:

  Mensagem original 
 Assunto: [patch] media video cx23888 driver: ported to new kfifo API
 Data: Fri, 18 Dec 2009 09:12:34 +0100
 De: Stefani Seibold stef...@seibold.net
 Para: linux-ker...@vger.kernel.org, Andrew Morton 
 a...@linux-foundation.org,  Mauro Carvalho Chehab mche...@infradead.org
 
 This patch will fix the cx23888 driver to use the new kfifo API.
 
 The patch-set is against current mm tree from 11-Dec-2009
 
 Greetings,
 Stefani
 
 Signed-off-by: Stefani Seibold stef...@seibold.net
 ---
  cx23888-ir.c |   35 ++-
  1 file changed, 10 insertions(+), 25 deletions(-)
 
 --- mmotm.orig/drivers/media/video/cx23885/cx23888-ir.c   2009-12-18 
 08:42:53.936778002 +0100
 +++ mmotm/drivers/media/video/cx23885/cx23888-ir.c2009-12-18 
 09:03:04.808703259 +0100
 @@ -124,15 +124,12 @@ struct cx23888_ir_state {
   atomic_t rxclk_divider;
   atomic_t rx_invert;
  
 - struct kfifo *rx_kfifo;
 + struct kfifo rx_kfifo;
   spinlock_t rx_kfifo_lock;
  
   struct v4l2_subdev_ir_parameters tx_params;
   struct mutex tx_params_lock;
   atomic_t txclk_divider;
 -
 - struct kfifo *tx_kfifo;
 - spinlock_t tx_kfifo_lock;
  };
  
  static inline struct cx23888_ir_state *to_state(struct v4l2_subdev *sd)
 @@ -594,8 +591,9 @@ static int cx23888_ir_irq_handler(struct
   if (i == 0)
   break;
   j = i * sizeof(u32);
 - k = kfifo_put(state-rx_kfifo,
 -   (unsigned char *) rx_data, j);
 + k = kfifo_in_locked(state-rx_kfifo,
 +   (unsigned char *) rx_data, j,
 +   state-rx_kfifo_lock);
   if (k != j)
   kror++; /* rx_kfifo over run */
   }
 @@ -631,7 +629,7 @@ static int cx23888_ir_irq_handler(struct
   cx23888_ir_write4(dev, CX23888_IR_CNTRL_REG, cntrl);
   *handled = true;
   }
 - if (kfifo_len(state-rx_kfifo) = CX23888_IR_RX_KFIFO_SIZE / 2)
 + if (kfifo_len(state-rx_kfifo) = CX23888_IR_RX_KFIFO_SIZE / 2)
   events |= V4L2_SUBDEV_IR_RX_FIFO_SERVICE_REQ;
  
   if (events)

I am concerned about reading the kfifo_len() without taking the lock,
since another thread on another CPU may be reading from the kfifo at the
same time.

If the new kfifo implementation has an atomic_read() or something behind
the kfifo_len() call, then OK.


 @@ -657,7 +655,7 @@ static int cx23888_ir_rx_read(struct v4l
   return 0;
   }
  
 - n = kfifo_get(state-rx_kfifo, buf, n);
 + n = kfifo_out_locked(state-rx_kfifo, buf, n, state-rx_kfifo_lock);
  
   n /= sizeof(u32);
   *num = n * sizeof(u32);
 @@ -785,7 +783,7 @@ static int cx23888_ir_rx_s_parameters(st
   o-interrupt_enable = p-interrupt_enable;
   o-enable = p-enable;
   if (p-enable) {
 - kfifo_reset(state-rx_kfifo);
 + kfifo_reset(state-rx_kfifo);
   if (p-interrupt_enable)
   irqenable_rx(dev, IRQEN_RSE | IRQEN_RTE | IRQEN_ROE);
   control_rx_enable(dev, p-enable);

Same concern about kfifo_reset() not taking the lock, and another thread
reading data from the kfifo at the same time.  In the cx23885 module,
this would mostly likely happen only during module unload as things are
being shut down.


 @@ -892,7 +890,6 @@ static int cx23888_ir_tx_s_parameters(st
   o-interrupt_enable = p-interrupt_enable;
   o-enable = p-enable;
   if (p-enable) {
 - kfifo_reset(state-tx_kfifo);
   if (p-interrupt_enable)
   irqenable_tx(dev, IRQEN_TSE);
   control_tx_enable(dev, p-enable);

I don't mind the currently unused tx_kfifo being removed from the
current implementation.  However, could you leave a comment at this line
about reseting a tx_kfifo?  Otherwise, I may forget this one when I go
to implement transmit.


 @@ -1168,19 +1165,9 @@ int cx23888_ir_probe(struct cx23885_dev 
   return -ENOMEM;
  
   spin_lock_init(state-rx_kfifo_lock);
 - state-rx_kfifo = kfifo_alloc(CX23888_IR_RX_KFIFO_SIZE, GFP_KERNEL,
 -   state-rx_kfifo_lock);
 - if (state-rx_kfifo == NULL)
 + if (kfifo_alloc(state-rx_kfifo, CX23888_IR_RX_KFIFO_SIZE, GFP_KERNEL))
   return -ENOMEM;
  
 - spin_lock_init(state-tx_kfifo_lock);
 - state-tx_kfifo = kfifo_alloc(CX23888_IR_TX_KFIFO_SIZE, GFP_KERNEL,
 -   state-tx_kfifo_lock);
 - if (state-tx_kfifo == NULL) {
 - kfifo_free(state-rx_kfifo);
 -   

Re: Created files in patch comment intended?

2009-12-18 Thread Mauro Carvalho Chehab
Guennadi Liakhovetski wrote:
 On Fri, 18 Dec 2009, Mauro Carvalho Chehab wrote:
 
 Hi Guennadi,

 Guennadi Liakhovetski wrote:
 Hi Mauro

 Looking at how my mediabus patches got committed into the mainline, I 
 noticed, that the add-mediabus patch contains a list of added files 
 between the patch description and the Sob's:

  create mode 100644 drivers/media/video/soc_mediabus.c
  create mode 100644 include/media/soc_mediabus.h
  create mode 100644 include/media/v4l2-mediabus.h

 Is this intended, and if yes - why? If not, maybe you'd like to fix this 
 in your hg-git export scripts.

 No, this is not intentional. The scripts have a logic to identify the 
 description
 body of a mercurial commit and of a patch received by email. The logic should
 just import whatever description is provided on -hg.

 By looking on your commit for this patch on mercurial, we have:

 $ hg log -r 13658 -v
 changeset:   13658:2c60bd900a7a
 user:Guennadi Liakhovetski g.liakhovet...@gmx.de
 date:Fri Dec 11 15:41:28 2009 +0100
 files:   linux/drivers/media/video/Makefile 
 linux/drivers/media/video/soc_mediabus.c linux/include/media/soc_mediabus.h 
 linux/include/media/v4l2-mediabus.h linux/include/media/v4l2-subdev.h
 description:
 v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
 From: Guennadi Liakhovetski g.liakhovet...@gmx.de

 Video subdevices, like cameras, decoders, connect to video bridges over
 specialised busses. Data is being transferred over these busses in various
 formats, which only loosely correspond to fourcc codes, describing how video
 data is stored in RAM. This is not a one-to-one correspondence, therefore we
 cannot use fourcc codes to configure subdevice output data formats. This 
 patch
 adds codes for several such on-the-bus formats and an API, similar to the
 familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring 
 those
 codes. After all users of the old API in struct v4l2_subdev_video_ops are
 converted, it will be removed. Also add helper routines to support generic
 pass-through mode for the soc-camera framework.

 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 Acked-by: Hans Verkuil hverk...@xs4all.nl
 ---
  drivers/media/video/Makefile   |2 +-
  drivers/media/video/soc_mediabus.c |  157 
 
  include/media/soc_mediabus.h   |   65 +++
  include/media/v4l2-mediabus.h  |   61 ++
  include/media/v4l2-subdev.h|   19 -
  5 files changed, 302 insertions(+), 2 deletions(-)
  create mode 100644 drivers/media/video/soc_mediabus.c
  create mode 100644 include/media/soc_mediabus.h
  create mode 100644 include/media/v4l2-mediabus.h


 As you see, you added those comments at the end of the patch, together with 
 a diffstat.
 While the script has a logic to remove diffstats, it doesn't contain 
 anything to remove
 the create mode lines that you've added at the end of the patch 
 description.
 
 No, _I_ didn't add those, git did. This is the standard output from git 
 format patch. And the patch format for submission to the kernel is 
 roughly
 
 subject
 
 description
 
 Sob, ack,...
 ---
 ignored lines
 diff -u
 
 So, anything, beginning with ---\n and the patch must be ignored. That's 
 also where you provide any comments, that should not be included in the 
 commit text.

You added it on your -hg tree. See:

http://linuxtv.org/hg/~gliakhovetski/v4l-dvb/rev/2c60bd900a7a

Probably, the scripts you're using to generate your -hg trees are wrong. They
should be discarding anything after ---\n, but they aren't doing it.

Mercurial never adds such comments on their descriptions. For example, this 
patch:

http://linuxtv.org/hg/~gliakhovetski/v4l-dvb/rev/dae3ac9449c8

Also creates a file, but you won't see there any diffstat lines on it.

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


Re: [Fwd: [patch] media video cx23888 driver: ported to new kfifo API]

2009-12-18 Thread Stefani Seibold
Am Freitag, den 18.12.2009, 07:00 -0500 schrieb Andy Walls:
 On Fri, 2009-12-18 at 08:14 -0200, Mauro Carvalho Chehab wrote:
  Andy,
  
  Please review. The lack of porting cx23885 to new kfifo is stopping the 
  merge
  of the redesigned kfifo upstream.
 
 
 Stefani and Mauro,
 
 My comments/concerns are in line:
 
   Mensagem original 
  Assunto: [patch] media video cx23888 driver: ported to new kfifo API
  Data: Fri, 18 Dec 2009 09:12:34 +0100
  De: Stefani Seibold stef...@seibold.net
  Para: linux-ker...@vger.kernel.org, Andrew Morton 
  a...@linux-foundation.org,  Mauro Carvalho Chehab mche...@infradead.org
  
  This patch will fix the cx23888 driver to use the new kfifo API.
  
  The patch-set is against current mm tree from 11-Dec-2009
  
  Greetings,
  Stefani
  
  Signed-off-by: Stefani Seibold stef...@seibold.net
  ---
   cx23888-ir.c |   35 ++-
   1 file changed, 10 insertions(+), 25 deletions(-)
  
  --- mmotm.orig/drivers/media/video/cx23885/cx23888-ir.c 2009-12-18 
  08:42:53.936778002 +0100
  +++ mmotm/drivers/media/video/cx23885/cx23888-ir.c  2009-12-18 
  09:03:04.808703259 +0100
  @@ -124,15 +124,12 @@ struct cx23888_ir_state {
  atomic_t rxclk_divider;
  atomic_t rx_invert;
   
  -   struct kfifo *rx_kfifo;
  +   struct kfifo rx_kfifo;
  spinlock_t rx_kfifo_lock;
   
  struct v4l2_subdev_ir_parameters tx_params;
  struct mutex tx_params_lock;
  atomic_t txclk_divider;
  -
  -   struct kfifo *tx_kfifo;
  -   spinlock_t tx_kfifo_lock;
   };
   
   static inline struct cx23888_ir_state *to_state(struct v4l2_subdev *sd)
  @@ -594,8 +591,9 @@ static int cx23888_ir_irq_handler(struct
  if (i == 0)
  break;
  j = i * sizeof(u32);
  -   k = kfifo_put(state-rx_kfifo,
  - (unsigned char *) rx_data, j);
  +   k = kfifo_in_locked(state-rx_kfifo,
  + (unsigned char *) rx_data, j,
  + state-rx_kfifo_lock);
  if (k != j)
  kror++; /* rx_kfifo over run */
  }
  @@ -631,7 +629,7 @@ static int cx23888_ir_irq_handler(struct
  cx23888_ir_write4(dev, CX23888_IR_CNTRL_REG, cntrl);
  *handled = true;
  }
  -   if (kfifo_len(state-rx_kfifo) = CX23888_IR_RX_KFIFO_SIZE / 2)
  +   if (kfifo_len(state-rx_kfifo) = CX23888_IR_RX_KFIFO_SIZE / 2)
  events |= V4L2_SUBDEV_IR_RX_FIFO_SERVICE_REQ;
   
  if (events)
 
 I am concerned about reading the kfifo_len() without taking the lock,
 since another thread on another CPU may be reading from the kfifo at the
 same time.
 
 If the new kfifo implementation has an atomic_read() or something behind
 the kfifo_len() call, then OK.
 
 
  @@ -657,7 +655,7 @@ static int cx23888_ir_rx_read(struct v4l
  return 0;
  }
   
  -   n = kfifo_get(state-rx_kfifo, buf, n);
  +   n = kfifo_out_locked(state-rx_kfifo, buf, n, state-rx_kfifo_lock);
   
  n /= sizeof(u32);
  *num = n * sizeof(u32);
  @@ -785,7 +783,7 @@ static int cx23888_ir_rx_s_parameters(st
  o-interrupt_enable = p-interrupt_enable;
  o-enable = p-enable;
  if (p-enable) {
  -   kfifo_reset(state-rx_kfifo);
  +   kfifo_reset(state-rx_kfifo);
  if (p-interrupt_enable)
  irqenable_rx(dev, IRQEN_RSE | IRQEN_RTE | IRQEN_ROE);
  control_rx_enable(dev, p-enable);
 
 Same concern about kfifo_reset() not taking the lock, and another thread
 reading data from the kfifo at the same time.  In the cx23885 module,
 this would mostly likely happen only during module unload as things are
 being shut down.
 
 
  @@ -892,7 +890,6 @@ static int cx23888_ir_tx_s_parameters(st
  o-interrupt_enable = p-interrupt_enable;
  o-enable = p-enable;
  if (p-enable) {
  -   kfifo_reset(state-tx_kfifo);
  if (p-interrupt_enable)
  irqenable_tx(dev, IRQEN_TSE);
  control_tx_enable(dev, p-enable);
 
 I don't mind the currently unused tx_kfifo being removed from the
 current implementation.  However, could you leave a comment at this line
 about reseting a tx_kfifo?  Otherwise, I may forget this one when I go
 to implement transmit.
 
 
  @@ -1168,19 +1165,9 @@ int cx23888_ir_probe(struct cx23885_dev 
  return -ENOMEM;
   
  spin_lock_init(state-rx_kfifo_lock);
  -   state-rx_kfifo = kfifo_alloc(CX23888_IR_RX_KFIFO_SIZE, GFP_KERNEL,
  - state-rx_kfifo_lock);
  -   if (state-rx_kfifo == NULL)
  +   if (kfifo_alloc(state-rx_kfifo, CX23888_IR_RX_KFIFO_SIZE, GFP_KERNEL))
  return -ENOMEM;
   
  -   spin_lock_init(state-tx_kfifo_lock);
  -   state-tx_kfifo = kfifo_alloc(CX23888_IR_TX_KFIFO_SIZE, GFP_KERNEL,
  - state-tx_kfifo_lock);
  -   if 

Adaptec VideOh! DVD Media Center

2009-12-18 Thread Paulo Assis
Hi,
I'm currently porting the GPL linux-avc2210k driver (
http://www.freelists.org/archive/linux-avc2210k/ ) to V4L2.
The current version has it's own API that makes it incompatible with
any software except for specific user space apps (avcctrl, avctune)
bundled with the driver.
Since development seems to have halted for some time now, I had no
other choice than get my hands dirty :(
For the most part this task seems quite straight forward it's mostly a
matter of changing ioctls to V4L2 and add some missing support, there
are however a few points that I need some advice on:
For the box to function it needs a firmware upload. Currently this is
managed by a udev script that in turn calls an application (multiload)
that provides for the upload.
What I would like to know is, if this the best way to handle it?
The problem with this process is that it will always require
installing and configuring additional software (multiload and udev
script), besides the firmware.
Is there any simpler/standard way of handling these firmware uploads ?

Regards,
Paulo
--
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: Adaptec VideOh! DVD Media Center

2009-12-18 Thread Devin Heitmueller
On Fri, Dec 18, 2009 at 9:05 AM, Paulo Assis pj.as...@gmail.com wrote:
 Hi,
 I'm currently porting the GPL linux-avc2210k driver (
 http://www.freelists.org/archive/linux-avc2210k/ ) to V4L2.
 The current version has it's own API that makes it incompatible with
 any software except for specific user space apps (avcctrl, avctune)
 bundled with the driver.
 Since development seems to have halted for some time now, I had no
 other choice than get my hands dirty :(
 For the most part this task seems quite straight forward it's mostly a
 matter of changing ioctls to V4L2 and add some missing support, there
 are however a few points that I need some advice on:
 For the box to function it needs a firmware upload. Currently this is
 managed by a udev script that in turn calls an application (multiload)
 that provides for the upload.
 What I would like to know is, if this the best way to handle it?
 The problem with this process is that it will always require
 installing and configuring additional software (multiload and udev
 script), besides the firmware.
 Is there any simpler/standard way of handling these firmware uploads ?

 Regards,
 Paulo

Hi Paulo,

I would start by looking at the request_firmware() function, which is
used by a variety of other v4l cards.

Cheers,

Devin

-- 
Devin J. Heitmueller - 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


Re: Adaptec VideOh! DVD Media Center

2009-12-18 Thread Simon Farnsworth
Paulo Assis wrote:
 For the box to function it needs a firmware upload. Currently this is
 managed by a udev script that in turn calls an application (multiload)
 that provides for the upload.
 What I would like to know is, if this the best way to handle it?
 The problem with this process is that it will always require
 installing and configuring additional software (multiload and udev
 script), besides the firmware.
 Is there any simpler/standard way of handling these firmware uploads ?
 
Look at Documentation/firmware_class/README. There's a mechanism called
request_firmware() that does what you want; it's used in several V4L
drivers if you need an example usage.
-- 
Simon Farnsworth

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


[PATCH 0/4 v13] Support for TVP7002 in DM365

2009-12-18 Thread Santiago Nunez-Corrales

This series of patches provide support for the TVP7002 decoder in DM365.

Support includes:

* Inclusion of the chip in v4l2 definitions
* Definition of TVP7002 specific data structures
* Kconfig and Makefile support

This series corrects many issued pointed out by Snehaprabha Narnakaje,
Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves
testing problems.  Tested on DM365 TI EVM with resolutions 720p,
10...@60, 576P and 480P with video capture application and video
output in 480P, 576P, 720P and 1080I. This driver depends upon
board-dm365-evm.c and vpfe_capture.c to be ready for complete
integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri.
Removed shadow register values. Removed unnecesary power down and up
of the device (tests work fine). Improved readability. Uses Murali's
preset helper function. Last issues resolved.


--
Santiago Nunez-Corrales, Eng.
RidgeRun Engineering, LLC

Guayabos, Curridabat
San Jose, Costa Rica
+(506) 2271 1487
+(506) 8313 0536
http://www.ridgerun.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


[PATCH 1/4 v13] Support for TVP7002 in v4l2 definitions

2009-12-18 Thread santiago . nunez
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides required chip identification definitions
within v4l2. Included only definitions for TVP7002.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 include/media/v4l2-chip-ident.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
index cf16689..7e80c4f 100644
--- a/include/media/v4l2-chip-ident.h
+++ b/include/media/v4l2-chip-ident.h
@@ -129,6 +129,9 @@ enum {
V4L2_IDENT_SAA6752HS = 6752,
V4L2_IDENT_SAA6752HS_AC3 = 6753,
 
+   /* module tvp7002: just ident 7002 */
+   V4L2_IDENT_TVP7002 = 7002,
+
/* module adv7170: just ident 7170 */
V4L2_IDENT_ADV7170 = 7170,
 
-- 
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 2/4 v13] Definitions for TVP7002 in DM365

2009-12-18 Thread santiago . nunez
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides the required definitions for the TVP7002 driver
in DM365.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 drivers/media/video/tvp7002_reg.h |  150 +
 include/media/tvp7002.h   |   56 ++
 2 files changed, 206 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/tvp7002_reg.h
 create mode 100644 include/media/tvp7002.h

diff --git a/drivers/media/video/tvp7002_reg.h 
b/drivers/media/video/tvp7002_reg.h
new file mode 100644
index 000..0e34ca9
--- /dev/null
+++ b/drivers/media/video/tvp7002_reg.h
@@ -0,0 +1,150 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
+ * and the TVP7002 driver in the TI LSP 2.10.00.14
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Naming conventions
+ * --
+ *
+ * FDBK:  Feedback
+ * DIV:   Divider
+ * CTL:   Control
+ * SEL:   Select
+ * IN:Input
+ * OUT:   Output
+ * R: Red
+ * G: Green
+ * B: Blue
+ * OFF:   Offset
+ * THRS:  Threshold
+ * DGTL:  Digital
+ * LVL:   Level
+ * PWR:   Power
+ * MVIS:  Macrovision
+ * W: Width
+ * H: Height
+ * ALGN:  Alignment
+ * CLK:   Clocks
+ * TOL:   Tolerance
+ * BWTH:  Bandwidth
+ * COEF:  Coefficient
+ * STAT:  Status
+ * AUTO:  Automatic
+ * FLD:   Field
+ * L:Line
+ */
+
+#define TVP7002_CHIP_REV   0x00
+#define TVP7002_HPLL_FDBK_DIV_MSBS 0x01
+#define TVP7002_HPLL_FDBK_DIV_LSBS 0x02
+#define TVP7002_HPLL_CRTL  0x03
+#define TVP7002_HPLL_PHASE_SEL 0x04
+#define TVP7002_CLAMP_START0x05
+#define TVP7002_CLAMP_W0x06
+#define TVP7002_HSYNC_OUT_W0x07
+#define TVP7002_B_FINE_GAIN0x08
+#define TVP7002_G_FINE_GAIN0x09
+#define TVP7002_R_FINE_GAIN0x0a
+#define TVP7002_B_FINE_OFF_MSBS0x0b
+#define TVP7002_G_FINE_OFF_MSBS 0x0c
+#define TVP7002_R_FINE_OFF_MSBS 0x0d
+#define TVP7002_SYNC_CTL_1 0x0e
+#define TVP7002_HPLL_AND_CLAMP_CTL 0x0f
+#define TVP7002_SYNC_ON_G_THRS 0x10
+#define TVP7002_SYNC_SEPARATOR_THRS0x11
+#define TVP7002_HPLL_PRE_COAST 0x12
+#define TVP7002_HPLL_POST_COAST0x13
+#define TVP7002_SYNC_DETECT_STAT   0x14
+#define TVP7002_OUT_FORMATTER  0x15
+#define TVP7002_MISC_CTL_1 0x16
+#define TVP7002_MISC_CTL_2  0x17
+#define TVP7002_MISC_CTL_3  0x18
+#define TVP7002_IN_MUX_SEL_1   0x19
+#define TVP7002_IN_MUX_SEL_20x1a
+#define TVP7002_B_AND_G_COARSE_GAIN0x1b
+#define TVP7002_R_COARSE_GAIN  0x1c
+#define TVP7002_FINE_OFF_LSBS  0x1d
+#define TVP7002_B_COARSE_OFF   0x1e
+#define TVP7002_G_COARSE_OFF0x1f
+#define TVP7002_R_COARSE_OFF0x20
+#define TVP7002_HSOUT_OUT_START0x21
+#define TVP7002_MISC_CTL_4 0x22
+#define TVP7002_B_DGTL_ALC_OUT_LSBS0x23
+#define TVP7002_G_DGTL_ALC_OUT_LSBS 0x24
+#define TVP7002_R_DGTL_ALC_OUT_LSBS 0x25
+#define TVP7002_AUTO_LVL_CTL_ENABLE0x26
+#define TVP7002_DGTL_ALC_OUT_MSBS  0x27
+#define TVP7002_AUTO_LVL_CTL_FILTER0x28
+/* Reserved 0x29*/
+#define TVP7002_FINE_CLAMP_CTL 0x2a
+#define TVP7002_PWR_CTL0x2b
+#define TVP7002_ADC_SETUP  0x2c
+#define TVP7002_COARSE_CLAMP_CTL   0x2d
+#define TVP7002_SOG_CLAMP  0x2e
+#define TVP7002_RGB_COARSE_CLAMP_CTL   0x2f
+#define TVP7002_SOG_COARSE_CLAMP_CTL   0x30
+#define TVP7002_ALC_PLACEMENT  0x31
+/* Reserved 0x32 */
+/* Reserved 0x33 */
+#define TVP7002_MVIS_STRIPPER_W0x34
+#define TVP7002_VSYNC_ALGN 0x35
+#define TVP7002_SYNC_BYPASS0x36
+#define TVP7002_L_FRAME_STAT_LSBS  0x37
+#define TVP7002_L_FRAME_STAT_MSBS  0x38
+#define 

[PATCH 3/4 v13] TVP7002 driver for DM365

2009-12-18 Thread santiago . nunez
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides the implementation of the TVP7002 decoder
driver for DM365. Implemented using the V4L2 DV presets API.
Removed shadow register values. Testing shows that the device
needs not to be powered down and up for correct behaviour.
Improved readability. Uses helper function for preset information.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 drivers/media/video/tvp7002.c | 1189 +
 1 files changed, 1189 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/tvp7002.c

diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
new file mode 100644
index 000..058ffda
--- /dev/null
+++ b/drivers/media/video/tvp7002.c
@@ -0,0 +1,1189 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
+ * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
+ * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/tvp7002.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-common.h
+#include tvp7002_reg.h
+
+MODULE_DESCRIPTION(TI TVP7002 Video and Graphics Digitizer driver);
+MODULE_AUTHOR(Santiago Nunez-Corrales santiago.nu...@ridgerun.com);
+MODULE_LICENSE(GPL);
+
+/* Module Name */
+#define TVP7002_MODULE_NAMEtvp7002
+
+/* I2C retry attempts */
+#define I2C_RETRY_COUNT(5)
+
+/* End of registers */
+#define TVP7002_EOR0x5c
+
+/* Read write definition for registers */
+#define TVP7002_READ   0
+#define TVP7002_WRITE  1
+#define TVP7002_RESERVED   2
+
+/* Interlaced vs progressive mask and shift */
+#define TVP7002_IP_SHIFT   5
+#define TVP7002_INPR_MASK  (0x01  TVP7002_IP_SHIFT)
+
+/* Shift for CPL and LPF registers */
+#define TVP7002_CL_SHIFT   8
+#define TVP7002_CL_MASK0x0f
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-2));
+
+/* Structure for register values */
+struct i2c_reg_value {
+   u8 reg;
+   u8 value;
+   u8 type;
+};
+
+/*
+ * Register default values (according to tvp7002 datasheet)
+ * In the case of read-only registers, the value (0xff) is
+ * never written. R/W functionality is controlled by the
+ * writable bit in the register struct definition.
+ */
+static const struct i2c_reg_value tvp7002_init_default[] = {
+   { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
+   { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
+   { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
+   { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
+   { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
+   { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
+   { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
+   { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
+   { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
+   { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
+   { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
+   { TVP7002_SYNC_SEPARATOR_THRS, 0x47, TVP7002_WRITE },
+   { TVP7002_HPLL_PRE_COAST, 0x00, TVP7002_WRITE },
+   { TVP7002_HPLL_POST_COAST, 0x00, TVP7002_WRITE },
+   { TVP7002_SYNC_DETECT_STAT, 0xff, TVP7002_READ },
+   { TVP7002_OUT_FORMATTER, 0x47, TVP7002_WRITE },
+   { TVP7002_MISC_CTL_1, 0x01, TVP7002_WRITE },
+   { TVP7002_MISC_CTL_2, 0x00, TVP7002_WRITE },
+   { TVP7002_MISC_CTL_3, 0x01, TVP7002_WRITE 

patch to support for 0x0802 sensor in t613.c

2009-12-18 Thread Nicolau Werneck
Hello. I am a clueless n00b, and I can't make patches or use any
proper development tools. But I made this modification to t613.c to
support this new sensor. It is working fine with me. I just cleaned
the code up a bit and compiled and tested with the 2.6.32 kernel, and
it seems to be working fine.

If somebody could help me creating a proper patch to submit to the
source tree, I would be most grateful. The code is attached.

Thank you,
  ++nicolau




-- 
Nicolau Werneck nwern...@gmail.com  1AAB 4050 1999 BDFF 4862
http://www.lti.pcs.usp.br/~nwerneck   4A33 D2B5 648B 4789 0327
Linux user #460716

/*
 * V4L2 by Jean-Francois Moine http://moinejf.free.fr
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 *
 *Notes: * t613  + tas5130A
 *	* Focus to light do not balance well as in win.
 *	  Quality in win is not good, but its kinda better.
 *	 * Fix some extraneous bytes, most of apps will show the image anyway
 *	 * Gamma table, is there, but its really doing something?
 *	 * 7~8 Fps, its ok, max on win its 10.
 *			Costantino Leandro
 */

#define MODULE_NAME t613

#include gspca.h

#define V4L2_CID_EFFECTS (V4L2_CID_PRIVATE_BASE + 0)

MODULE_AUTHOR(Leandro Costantino le_costant...@pixartargentina.com.ar);
MODULE_DESCRIPTION(GSPCA/T613 (JPEG Compliance) USB Camera Driver);
MODULE_LICENSE(GPL);

struct sd {
	struct gspca_dev gspca_dev;	/* !! must be the first item */

	u8 brightness;
	u8 contrast;
	u8 colors;
	u8 autogain;
	u8 gamma;
	u8 sharpness;
	u8 freq;
	u8 whitebalance;
	u8 mirror;
	u8 effect;

	u8 sensor;
#define SENSOR_OM6802 0
#define SENSOR_OTHER 1
#define SENSOR_TAS5130A 2
#define SENSOR_LT168G 3 /* must verify if this is the actual model */
};

/* V4L2 controls supported by the driver */
static int sd_setbrightness(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getbrightness(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setcontrast(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getcontrast(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setcolors(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getcolors(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setlowlight(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getlowlight(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setgamma(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getgamma(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setsharpness(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getsharpness(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setfreq(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getfreq(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setwhitebalance(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getwhitebalance(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setflip(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getflip(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_seteffect(struct gspca_dev *gspca_dev, __s32 val);
static int sd_geteffect(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_querymenu(struct gspca_dev *gspca_dev,
			struct v4l2_querymenu *menu);

static struct ctrl sd_ctrls[] = {
	{
	 {
	  .id = V4L2_CID_BRIGHTNESS,
	  .type = V4L2_CTRL_TYPE_INTEGER,
	  .name = Brightness,
	  .minimum = 0,
	  .maximum = 14,
	  .step = 1,
#define BRIGHTNESS_DEF 8
	  .default_value = BRIGHTNESS_DEF,
	  },
	 .set = sd_setbrightness,
	 .get = sd_getbrightness,
	 },
	{
	 {
	  .id = V4L2_CID_CONTRAST,
	  .type = V4L2_CTRL_TYPE_INTEGER,
	  .name = Contrast,
	  .minimum = 0,
	  .maximum = 0x0d,
	  .step = 1,
#define CONTRAST_DEF 0x07
	  .default_value = CONTRAST_DEF,
	  },
	 .set = sd_setcontrast,
	 .get = sd_getcontrast,
	 },
	{
	 {
	  .id = V4L2_CID_SATURATION,
	  .type = V4L2_CTRL_TYPE_INTEGER,
	  .name = Color,
	  .minimum = 0,
	  .maximum = 0x0f,
	  .step = 1,
#define COLORS_DEF 0x05
	  .default_value = COLORS_DEF,
	  },
	 .set = sd_setcolors,
	 .get = sd_getcolors,
	 },
#define GAMMA_MAX 16
#define GAMMA_DEF 10
	{
	 {
	  .id = V4L2_CID_GAMMA,	/* (gamma on win) */
	  .type = V4L2_CTRL_TYPE_INTEGER,
	  .name = Gamma,
	  .minimum = 0,
	  .maximum = GAMMA_MAX - 1,
	  .step = 1,
	  .default_value = GAMMA_DEF,
	  },
	 .set = sd_setgamma,
	 .get = sd_getgamma,
	 },
	{
	 {
	  .id = V4L2_CID_GAIN,	/* here, i activate only the lowlight,
	

Re: missing audio in bttv

2009-12-18 Thread Hans Verkuil
Hi Stefan,

I'm CC-ing both the bttv maintainer and the linux-media list.

On Thursday 17 December 2009 20:08:08 Stefan Tauner wrote:
 On Thu, 26 Nov 2009 21:09:04 +0100
 Hans Verkuil hverk...@xs4all.nl wrote:
 
  You posted this to the wrong mailinglist. The old video4linux
  mailinglist is obsolete and is replaced by the linux-media
  mailinglist.
 
 hello again!
 
 sorry for the long delay, i had lots of stuff to do for university.
 
 i read somewhere, that video4linux is still ok for user-oriented stuff.
 maybe it would be a good idea to close the old one completely.
 
  You wouldn't happen to have the dmesg lines from a 2.6.29 or older
  kernel, would you? That would be very useful.
  
  Can you also look at the card and either make a photo of it or write
  down the names of the chips on the board? I need to know what audio
  chip is actually on it.
 
 i tried to mail to the new list (one time without subscribing, the 2nd
 time after), but it did not go through, no idea why :/
 
 i shot some photos, but the part numbers etc are not really readable,
 i wrote them down though...
 conexant fusion 878a
 an analogue multiplexer hef4052bt
 a 256x8b i2c eeprom 24c02n
 there are no other ics outside the tuner casing
 
 so the 878a is responsible for decoding the audio, right?

This is weird. For both kernels the messages report that there is no audio
chip. To my knowledge you need some chip in other to be able to get audio
from the tuner.

Mauro, do you know anything about this type of card? Basically Stefan reports
that it works for 2.6.29 but no longer with 2.6.31. I thought it might be the
subdev conversion, but based on these kernel logs I do not see anything
different between the kernels. Neither reports the presence of an audio chip.

 
 
 dmesg lines from ubuntu's 2.6.31-15-generic:
 [   42.137099] bttv: driver version 0.9.18 loaded
 [   42.137101] bttv: using 8 buffers with 2080k (520 pages) each for capture
 [   42.138569] bttv: Bt8xx card found (0).
 [   42.138582] bttv :01:00.0: PCI INT A - GSI 21 (level, low) - IRQ 21
 [   42.138591] bttv0: Bt878 (rev 17) at :01:00.0, irq: 21, latency: 32, 
 mmio: 0xbe00
 [   42.138623] bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID 
 is 0070:13eb
 [   42.138625] bttv0: using: Hauppauge (bt878) [card=10,autodetected]
 [   42.138627] IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
 [   42.138650] bttv0: gpio: en=, out= in=00fb [init]
 [   42.141155] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
 [   42.177379] tveeprom 6-0050: Hauppauge model 38104, rev B429, serial# 
 5055952
 [   42.177381] tveeprom 6-0050: tuner model is Temic 4006FH5 (idx 29, type 14)
 [   42.177383] tveeprom 6-0050: TV standards PAL(B/G) (eeprom 0x04)
 [   42.177385] tveeprom 6-0050: audio processor is None (idx 0)
 [   42.177387] tveeprom 6-0050: has no radio
 [   42.177388] bttv0: Hauppauge eeprom indicates model#38104
 [   42.177390] bttv0: tuner type=14
 [   43.239183] bttv0: audio absent, no audio device found!
 [   43.351690]   alloc irq_desc for 22 on node 0
 [   43.351693]   alloc kstat_irqs on node 0
 ...
 [   43.416300] tuner 6-0061: chip found @ 0xc2 (bt878 #0 [sw])
 ...
 [   44.141866] tuner-simple 6-0061: creating new instance
 [   44.141869] tuner-simple 6-0061: type set to 14 (Temic PAL_BG (4006FH5))
 [   44.142579] bttv0: registered device video0
 [   44.142596] bttv0: registered device vbi0
 [   44.142622] bttv0: PLL: 28636363 = 35468950 .. ok
 [   44.191396] Bt87x :01:00.1: PCI INT A - GSI 21 (level, low) - IRQ 21
 [   44.191521] bt87x0: Using board 1, analog, digital (rate 32000 Hz)
 
 
 2.6.29:
 im pretty sure it worked in the past with this kernel, but 2.6.29 does not 
 work with my current
 intel graphics drivers(? trying to open the video device in vlc kills the 
 xserver),
 so it would be a nuisance to test it out to be sure.

Stefan, you should be able to do something like 'cat /dev/video0 /dev/null'.
All we need to know is if you have audio, and since the audio is looped to the
sound input, that should still work.

 [   19.593750] bttv: driver version 0.9.17 loaded
 [   19.593752] bttv: using 8 buffers with 2080k (520 pages) each for capture
 [   19.593808] bttv: Bt8xx card found (0).
 [   19.593817] bttv :01:00.0: PCI INT A - GSI 21 (level, low) - IRQ 21
 [   19.593826] bttv0: Bt878 (rev 17) at :01:00.0, irq: 21, latency: 32, 
 mmio: 0xd070
 [   19.593844] bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID 
 is 0070:13eb
 [   19.593846] bttv0: using: Hauppauge (bt878) [card=10,autodetected]
 [   19.593847] IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
 [   19.593871] bttv0: gpio: en=, out= in=00fb [init]
 [   19.596355] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
 [   19.628999] tveeprom 1-0050: Hauppauge model 38104, rev B429, serial# 
 5055952
 [   19.629001] tveeprom 1-0050: tuner model is Temic 4006FH5 (idx 29, type 14)
 [   

Re: [PATCH 0/4 v13] Support for TVP7002 in DM365

2009-12-18 Thread Hans Verkuil
On Friday 18 December 2009 18:07:07 Santiago Nunez-Corrales wrote:
 This series of patches provide support for the TVP7002 decoder in DM365.
 
 Support includes:
 
 * Inclusion of the chip in v4l2 definitions
 * Definition of TVP7002 specific data structures
 * Kconfig and Makefile support
 
 This series corrects many issued pointed out by Snehaprabha Narnakaje,
 Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves
 testing problems.  Tested on DM365 TI EVM with resolutions 720p,
 10...@60, 576P and 480P with video capture application and video
 output in 480P, 576P, 720P and 1080I. This driver depends upon
 board-dm365-evm.c and vpfe_capture.c to be ready for complete
 integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri.
 Removed shadow register values. Removed unnecesary power down and up
 of the device (tests work fine). Improved readability. Uses Murali's
 preset helper function. Last issues resolved.
 
 

Looks good! Unless someone else finds more issues I'm going to make a tree
with this driver in it and issue a pull request early next week.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: patch to support for 0x0802 sensor in t613.c

2009-12-18 Thread Jean-Francois Moine
On Fri, 18 Dec 2009 16:46:04 -0200
Nicolau Werneck nwern...@gmail.com wrote:

 Hello. I am a clueless n00b, and I can't make patches or use any
 proper development tools. But I made this modification to t613.c to
 support this new sensor. It is working fine with me. I just cleaned
 the code up a bit and compiled and tested with the 2.6.32 kernel, and
 it seems to be working fine.
 
 If somebody could help me creating a proper patch to submit to the
 source tree, I would be most grateful. The code is attached.

Hello Nicolau,

Your code seems fine. To create a patch, just go to the linux tree
root, make a 'diff -u' from the original file to your new t613.c, edit
it, at the head, add a comment and a 'Signed-off-by: your email', and
submit to the mailing-list with subject '[PATCH] gspca - t613: Add new
sensor lt168g'.

BTW, as you know the name of your sensor, do you know the real name of
the sensor '0x803' ('other')? (it should be in some xxx.ini file in a
ms-win driver, but I could not find it - the table n4_other of t613.c
should be a table 'Regxxx' in the xx.ini)

Best regards.

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


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2009-12-18 Thread 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:Fri Dec 18 19:00:09 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13836:9defbd461e5f
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-armv5: OK
linux-2.6.32-armv5-davinci: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-armv5-ixp: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: OK
linux-2.6.32-armv5-omap2: OK
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: ERRORS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: ERRORS
linux-2.6.28-i686: ERRORS
linux-2.6.29.1-i686: ERRORS
linux-2.6.30-i686: ERRORS
linux-2.6.31-i686: ERRORS
linux-2.6.32-i686: ERRORS
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: OK
linux-2.6.32-mips: OK
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-powerpc64: OK
linux-2.6.32-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: ERRORS
linux-2.6.26-x86_64: WARNINGS
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: OK
linux-2.6.31-x86_64: WARNINGS
linux-2.6.32-x86_64: WARNINGS
spec: OK
sparse (linux-2.6.32): ERRORS
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/Friday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2

The V4L-DVB specification from this daily build is here:

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


Re: scan/scan-s2 doesn't tune, but dvbtune does?

2009-12-18 Thread Michael Akey

Steven Toth wrote:

On Tue, Dec 15, 2009 at 4:53 AM, Lou Otway
louis.ot...@tripleplay-services.com wrote:
  

Michael Akey wrote:


I can't get the scan/scan-s2 utilities to lock any transponders (DVB-S).
 My test satellite is AMC1 103W, the Pentagon Channel tp. This is probably
some simple user error on my part, but I can't figure it out.  I have a
Corotor II with polarity changed via serial command to an external IRD.
 C/Ku is switched by 22KHz tone, voltage is always 18V.  Ku is with tone
off, C with tone on.  Speaking of which, is there a way to manually set the
tone from the arguments on the scan utilities?

Here's what I've tried and the results:

$ ./scan-s2 -a 0 -v -o zap -l 10750 INIT
API major 5, minor 0
scanning INIT
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder DVB-S  1210 H 2000 AUTO AUTO AUTO
initial transponder DVB-S2 1210 H 2000 AUTO AUTO AUTO
-- Using DVB-S
  

tune to: 12100:h:0:2


DVB-S IF freq is 135
  

tuning status == 0x03
tuning status == 0x01
tuning status == 0x03
tuning status == 0x01
tuning status == 0x03
tuning status == 0x00
tuning status == 0x01
tuning status == 0x03
tuning status == 0x00
tuning status == 0x00


WARNING:  tuning failed!!!
  

tune to: 12100:h:0:2 (tuning failed)


DVB-S IF freq is 135
  

tuning status == 0x03
tuning status == 0x01
tuning status == 0x00
tuning status == 0x00


...snip...

Same thing happens if I use just 'scan' and not 'scan-s2.'

If I use dvbtune, it works though..

$ dvbtune -f 135 -p H -s 2 -c 0 -tone 0 -m
Using DVB card Conexant CX24116/CX24118
tuning DVB-S to L-Band:0, Pol:H Srate=2000, 22kHz=off
polling
Getting frontend event
FE_STATUS:
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI
FE_HAS_SYNC
Bit error rate: 0
Signal strength: 51648
SNR: 26215
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI
FE_HAS_SYNC
Signal=51648, Verror=0, SNR=26215dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=51776, Verror=0, SNR=26624dB, BlockErrors=0, (S|L|C|V|SY|)

The tuning file 'INIT' contains only the following line:
S 1210 H 2000 AUTO

I'm using v4l-dvb drivers from the main repo as of about a week ago.  I am
running kernel 2.6.32 on Debian testing.  Any help is appreciated ..and
hopefully it's just a simple flub on my part!

--Mike
  

Try using a non-auto FEC and rolloff.

Some devices won't accept auto for these parameters.



Michael,

The silicon in question doesn't do automatic FEC detection. Be sure to
specify which FEC you need for the sat. If in doubt, walk through them
all manually. Pilot auto detect is done in s/w was was added a long
time ago.

- Steve

  

Steve et al,

It would appear that it does in fact do auto FEC since I don't specify 
it with dvbtune and it works just fine (with both my Prof 7300 and 
7301.)  I think it's a tone issue, but then again, why does attempting 
to scan something on both bands C and Ku (tone on, and tone off 
respectively) not work?  I figured if it's a tone issue that only one 
band would work.


I tried setting the FEC and even the delivery system (S1 rather than S) 
and it makes no difference.  I could try the DVB-S2 NBC mux on that 
satellite too.. but I'm not sure why that would make a difference.


If you folks have any other ideas, let me know.  Thanks for your 
responses so far!


--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: [linux-dvb] Hauppauge PVR-150 Vertical sync issue?

2009-12-18 Thread Robert Longfield
Ok so I ran a live CD on my windows box and there were no sync
problems. I installed the latest Ubuntu CD and dual booted my windows
machine and there was no sync problems but there was other issues,
many tiny black lines on edges during fast movement when I did a $ cat
/dev/video0  foo.mpg.
I'm going to reboot into windows and see if this problem persists in Windows.

So it looks like the problem is restricted to my mythbuntu box.

What analog tuner assembly type does the tveeprom module show for your
card in dmesg?

Here is the data from dmesg for tveeprom:

[   27.806567] tveeprom 0-0050: Hauppauge model 26032, rev C199, serial# 8011004
[   27.806571] tveeprom 0-0050: tuner model is TCL 2002N 5H (idx 99, type 50)
[   27.806574] tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
[   27.806576] tveeprom 0-0050: audio processor is CX25841 (idx 35)
[   27.806579] tveeprom 0-0050: decoder processor is CX25841 (idx 28)
[   27.806581] tveeprom 0-0050: has no radio, has IR receiver, has IR
transmitter

Also what video standard are you capturing: NTSC or something else?

I'm capturing NTSC.

On Fri, Dec 11, 2009 at 4:32 AM, Andy Walls awa...@radix.net wrote:
 On Thu, 2009-12-10 at 11:56 -0500, Robert Longfield wrote:
 Ok I've been able to do some troubleshooting with some interesting results.
 I removed the one splitter being used, connected to the main cable
 coming into the house, isolated the grounds with no change in sync
 issues.
 I pulled the pvr-150 card out of the linux machine and put it into my
 window box, hooked it up to the original setup splitter and no ground
 isolation and the video is crystal clear with no sync issues.

 I can only come up with a few possible problems, but I am sure there are 
 more.
 Could this be a driver issue on my linux box?

 Given your results, yes it is most likely a linux driver issue.  The
 suspects would be the cx25840 module, or the modules for the analog
 tuner.

 What analog tuner assembly type does the tveeprom module show for your
 card in dmesg?

 Also what video standard are you capturing: NTSC or something else?


 Could a bad or failing PCI slot cause this problem?

 No.  A *very* busy PCI bus may cause some I2C transactions that set up
 the tuner or CX25843 to fail, but it is more likely simply a suboptimal
 tuner or CX25843 configuration issue.


 However the sync
 problem is not on every channel.

 I'm going to try moving the linux box across the house to see if there
 is a source of EMI near by, but since the windows box doesn't have
 this issue I assume this is a problem with the linux box.

 I suppose you could try a linux liveCD in the Windows box and use

        $ cat /dev/video0  foo.mpg

 to capture video.  Then move foo.mpg to a USB flash disk and play back
 foo.mpg where ever it is convenient.  If foo.mpg shows artifacts then
 you can be somewhat sure of a linux driver issue.


 -Rob

 On Tue, Nov 24, 2009 at 6:43 PM, Andy Walls awa...@radix.net wrote:
  On Tue, 2009-11-24 at 13:05 -0500, Robert Longfield wrote:
  I have a PVR-150 card running on mythbuntu 9 and it appears that my
  card is suffering a vertical (and possibly a horizontal) sync issue.
 
  The video jumps around, shifts from side to side, up and down and when
  it shifts the video wraps. I'm including a link to a screen shot
  showing the vertical sync problem
 
  http://imagebin.ca/view/6fS-14Yi.html
 
  It looks like you have strong singal reflections in your cable due to
  impedance mismatches, a bad splitter, a bad cable or connector, etc.
 
  Please read:
 
  http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality
 
  and take steps to ensure you've got a good cabling plant in your home.
 
  Regards,
  Andy
 
  This is pretty tame to what happens sometimes. I haven't noticed this
  on all channels as we are mostly using this to record shows for my
  son.
 
  Here is my setup. Pentium 4 2 Ghz with a gig of ram. 40 gig OS drive,
  150 gig drive for recording, 250 gig drive for backup and storage, a
  dvd-burner.
  The 150 gig drive is on a Promise Ultra133 TX2 card but exhibits no
  issues on reads or writes.
  I have cable connected to the internal tuner of my PVR-150 card and
  S-video from an Nvidia card (running Nvidea drivers) out to the TV.
 
  I don't know what else I can provide to help out but let me know and
  I'll get it.
 
  Thanks,
  -Rob



--
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] Hauppauge PVR-150 Vertical sync issue?

2009-12-18 Thread Steven Toth
 So it looks like the problem is restricted to my mythbuntu box.

Congrats, that's better news.

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


Re: scan/scan-s2 doesn't tune, but dvbtune does?

2009-12-18 Thread Steven Toth
On Fri, Dec 18, 2009 at 2:23 PM, Michael Akey ak...@onid.orst.edu wrote:
 Steven Toth wrote:

 On Tue, Dec 15, 2009 at 4:53 AM, Lou Otway
 louis.ot...@tripleplay-services.com wrote:


 Michael Akey wrote:


 I can't get the scan/scan-s2 utilities to lock any transponders (DVB-S).
  My test satellite is AMC1 103W, the Pentagon Channel tp. This is
 probably
 some simple user error on my part, but I can't figure it out.  I have a
 Corotor II with polarity changed via serial command to an external IRD.
  C/Ku is switched by 22KHz tone, voltage is always 18V.  Ku is with tone
 off, C with tone on.  Speaking of which, is there a way to manually set
 the
 tone from the arguments on the scan utilities?

 Here's what I've tried and the results:

 $ ./scan-s2 -a 0 -v -o zap -l 10750 INIT
 API major 5, minor 0
 scanning INIT
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 initial transponder DVB-S  1210 H 2000 AUTO AUTO AUTO
 initial transponder DVB-S2 1210 H 2000 AUTO AUTO AUTO
 -- Using DVB-S


 tune to: 12100:h:0:2


 DVB-S IF freq is 135


 tuning status == 0x03
 tuning status == 0x01
 tuning status == 0x03
 tuning status == 0x01
 tuning status == 0x03
 tuning status == 0x00
 tuning status == 0x01
 tuning status == 0x03
 tuning status == 0x00
 tuning status == 0x00


 WARNING:  tuning failed!!!


 tune to: 12100:h:0:2 (tuning failed)


 DVB-S IF freq is 135


 tuning status == 0x03
 tuning status == 0x01
 tuning status == 0x00
 tuning status == 0x00


 ...snip...

 Same thing happens if I use just 'scan' and not 'scan-s2.'

 If I use dvbtune, it works though..

 $ dvbtune -f 135 -p H -s 2 -c 0 -tone 0 -m
 Using DVB card Conexant CX24116/CX24118
 tuning DVB-S to L-Band:0, Pol:H Srate=2000, 22kHz=off
 polling
 Getting frontend event
 FE_STATUS:
 polling
 Getting frontend event
 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI
 FE_HAS_SYNC
 Bit error rate: 0
 Signal strength: 51648
 SNR: 26215
 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI
 FE_HAS_SYNC
 Signal=51648, Verror=0, SNR=26215dB, BlockErrors=0, (S|L|C|V|SY|)
 Signal=51776, Verror=0, SNR=26624dB, BlockErrors=0, (S|L|C|V|SY|)

 The tuning file 'INIT' contains only the following line:
 S 1210 H 2000 AUTO

 I'm using v4l-dvb drivers from the main repo as of about a week ago.  I
 am
 running kernel 2.6.32 on Debian testing.  Any help is appreciated ..and
 hopefully it's just a simple flub on my part!

 --Mike


 Try using a non-auto FEC and rolloff.

 Some devices won't accept auto for these parameters.


 Michael,

 The silicon in question doesn't do automatic FEC detection. Be sure to
 specify which FEC you need for the sat. If in doubt, walk through them
 all manually. Pilot auto detect is done in s/w was was added a long
 time ago.

 - Steve



 Steve et al,

 It would appear that it does in fact do auto FEC since I don't specify it
 with dvbtune and it works just fine (with both my Prof 7300 and 7301.)  I
 think it's a tone issue, but then again, why does attempting to scan
 something on both bands C and Ku (tone on, and tone off respectively) not
 work?  I figured if it's a tone issue that only one band would work.

 I tried setting the FEC and even the delivery system (S1 rather than S) and
 it makes no difference.  I could try the DVB-S2 NBC mux on that satellite
 too.. but I'm not sure why that would make a difference.

 If you folks have any other ideas, let me know.  Thanks for your responses
 so far!

It doesn't do auto FEC in S2 mode, only S mode.

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


Re: [linux-dvb] Hauppauge PVR-150 Vertical sync issue?

2009-12-18 Thread BOUWSMA Barry
On Fri, 18 Dec 2009, Robert Longfield wrote:

 Ok so I ran a live CD on my windows box and there were no sync
 problems. I installed the latest Ubuntu CD and dual booted my windows
 machine and there was no sync problems but there was other issues,
 many tiny black lines on edges during fast movement when I did a $ cat
 /dev/video0  foo.mpg.

This sounds like an interlacing issue -- I suspect you are using
some player that delivers 25 full frames per second to your 
display instead of somehow getting 50 partial fields from them
or interpolating the fields into 50 frames per second.

This is fairly normal when not dealing with progressive material 
(720p HD video, or 1080i HD or even SD video taken from source 
material such as film shot at 24 fps).  Most players have options 
to enable one of any number of deinterlacers, some of which work 
better than others for selected movement.  (There are many 
different commandline options for `mplayer', one of which will 
present the fields of a 576i video as 288-line images which helps 
decipher fast-scrolling text, for example.)

If you are reproducing your video at your display's native 
resolution without zooming it to fullscreen, you can see each
of the jagged lines matching one pixel vertical resolution.


barrry bouwsma
--
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] Hauppauge PVR-150 Vertical sync issue?

2009-12-18 Thread Robert Longfield
Hey Barry,

Well that is certainly could be part of the problem, I was using
mplayer to play back the video recorded onto the computer monitor.
I wasn't too overly concerned with it as I thought it might be a playback issue.
I certainly have a lot more trouble shooting to do before I figure out
where the issue lies with this hardware.

-Rob

On Fri, Dec 18, 2009 at 3:17 PM, BOUWSMA Barry
freebeer.bouw...@gmail.com wrote:
 On Fri, 18 Dec 2009, Robert Longfield wrote:

 Ok so I ran a live CD on my windows box and there were no sync
 problems. I installed the latest Ubuntu CD and dual booted my windows
 machine and there was no sync problems but there was other issues,
 many tiny black lines on edges during fast movement when I did a $ cat
 /dev/video0  foo.mpg.

 This sounds like an interlacing issue -- I suspect you are using
 some player that delivers 25 full frames per second to your
 display instead of somehow getting 50 partial fields from them
 or interpolating the fields into 50 frames per second.

 This is fairly normal when not dealing with progressive material
 (720p HD video, or 1080i HD or even SD video taken from source
 material such as film shot at 24 fps).  Most players have options
 to enable one of any number of deinterlacers, some of which work
 better than others for selected movement.  (There are many
 different commandline options for `mplayer', one of which will
 present the fields of a 576i video as 288-line images which helps
 decipher fast-scrolling text, for example.)

 If you are reproducing your video at your display's native
 resolution without zooming it to fullscreen, you can see each
 of the jagged lines matching one pixel vertical resolution.


 barrry bouwsma

--
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: [Fwd: [patch] media video cx23888 driver: ported to new kfifo API]

2009-12-18 Thread Andy Walls
On Fri, 2009-12-18 at 13:11 +0100, Stefani Seibold wrote:
 Am Freitag, den 18.12.2009, 07:00 -0500 schrieb Andy Walls:
  On Fri, 2009-12-18 at 08:14 -0200, Mauro Carvalho Chehab wrote:

  
  Stefani and Mauro,
  
  My comments/concerns are in line:
  
    Mensagem original 
   Assunto: [patch] media video cx23888 driver: ported to new kfifo API
   Data: Fri, 18 Dec 2009 09:12:34 +0100
   De: Stefani Seibold stef...@seibold.net
   Para: linux-ker...@vger.kernel.org, Andrew Morton 
   a...@linux-foundation.org,  Mauro Carvalho Chehab 
   mche...@infradead.org
   
   This patch will fix the cx23888 driver to use the new kfifo API.
   
   The patch-set is against current mm tree from 11-Dec-2009
   
   Greetings,
   Stefani
   
   Signed-off-by: Stefani Seibold stef...@seibold.net
   ---
cx23888-ir.c |   35 ++-
1 file changed, 10 insertions(+), 25 deletions(-)
   
   --- mmotm.orig/drivers/media/video/cx23885/cx23888-ir.c   2009-12-18 
   08:42:53.936778002 +0100
   +++ mmotm/drivers/media/video/cx23885/cx23888-ir.c2009-12-18 
   09:03:04.808703259 +0100

   @@ -631,7 +629,7 @@ static int cx23888_ir_irq_handler(struct
 cx23888_ir_write4(dev, CX23888_IR_CNTRL_REG, cntrl);
 *handled = true;
 }
   - if (kfifo_len(state-rx_kfifo) = CX23888_IR_RX_KFIFO_SIZE / 2)
   + if (kfifo_len(state-rx_kfifo) = CX23888_IR_RX_KFIFO_SIZE / 2)
 events |= V4L2_SUBDEV_IR_RX_FIFO_SERVICE_REQ;

 if (events)
  
  I am concerned about reading the kfifo_len() without taking the lock,
  since another thread on another CPU may be reading from the kfifo at the
  same time.
  
  If the new kfifo implementation has an atomic_read() or something behind
  the kfifo_len() call, then OK.
  
  
   @@ -657,7 +655,7 @@ static int cx23888_ir_rx_read(struct v4l
 return 0;
 }

   - n = kfifo_get(state-rx_kfifo, buf, n);
   + n = kfifo_out_locked(state-rx_kfifo, buf, n, state-rx_kfifo_lock);

 n /= sizeof(u32);
 *num = n * sizeof(u32);
   @@ -785,7 +783,7 @@ static int cx23888_ir_rx_s_parameters(st
 o-interrupt_enable = p-interrupt_enable;
 o-enable = p-enable;
 if (p-enable) {
   - kfifo_reset(state-rx_kfifo);
   + kfifo_reset(state-rx_kfifo);
 if (p-interrupt_enable)
 irqenable_rx(dev, IRQEN_RSE | IRQEN_RTE | IRQEN_ROE);
 control_rx_enable(dev, p-enable);
  
  Same concern about kfifo_reset() not taking the lock, and another thread
  reading data from the kfifo at the same time.  In the cx23885 module,
  this would mostly likely happen only during module unload as things are
  being shut down.
  

 Sorry, i ported it only to the new API. I did not touch the
 functionality.

Stefani,

Huh?  The new kfifo implementation you wrote removed the locks from
kfifo_len() and kfifo_reset().  By changing those two functions to not
provide locking, you changed the functionality.


  Feel free to fix it and post it.

Please point me to the mmotm tree and I will try to get to this
tonight. 

I have a blizzard coming tonight threatening to leave 16 to 20 inches of
snow and I will likely lose power.  I have to purchase gas for my
generator and go split some wood for the fire.  I might not get the
change done before I lose power.

If you can't wait for me to provide a patch, just add spin locks and
unlocks around the calls to kfifo_len() and kfifo_reset() in addition to
the changes in your current patch.


Regards,
Andy

 Stefani


--
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 to support for 0x0802 sensor in t613.c

2009-12-18 Thread leandro Costantino
Nicolau, if you need help, let me know.
I also, sent you some mails asking for the patch for review some weeks
ago, i thougth you were missing :)
good woork
best regards

On Fri, Dec 18, 2009 at 8:13 PM, Jean-Francois Moine moin...@free.fr wrote:
 On Fri, 18 Dec 2009 16:46:04 -0200
 Nicolau Werneck nwern...@gmail.com wrote:

 Hello. I am a clueless n00b, and I can't make patches or use any
 proper development tools. But I made this modification to t613.c to
 support this new sensor. It is working fine with me. I just cleaned
 the code up a bit and compiled and tested with the 2.6.32 kernel, and
 it seems to be working fine.

 If somebody could help me creating a proper patch to submit to the
 source tree, I would be most grateful. The code is attached.

 Hello Nicolau,

 Your code seems fine. To create a patch, just go to the linux tree
 root, make a 'diff -u' from the original file to your new t613.c, edit
 it, at the head, add a comment and a 'Signed-off-by: your email', and
 submit to the mailing-list with subject '[PATCH] gspca - t613: Add new
 sensor lt168g'.

 BTW, as you know the name of your sensor, do you know the real name of
 the sensor '0x803' ('other')? (it should be in some xxx.ini file in a
 ms-win driver, but I could not find it - the table n4_other of t613.c
 should be a table 'Regxxx' in the xx.ini)

 Best regards.

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

--
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: [Fwd: [patch] media video cx23888 driver: ported to new kfifo API]

2009-12-18 Thread Stefani Seibold
Am Freitag, den 18.12.2009, 16:39 -0500 schrieb Andy Walls:
 On Fri, 2009-12-18 at 13:11 +0100, Stefani Seibold wrote:
  Am Freitag, den 18.12.2009, 07:00 -0500 schrieb Andy Walls:
   On Fri, 2009-12-18 at 08:14 -0200, Mauro Carvalho Chehab wrote:
 
   
   Stefani and Mauro,
   
   My comments/concerns are in line:
   
 Mensagem original 
Assunto: [patch] media video cx23888 driver: ported to new kfifo API
Data: Fri, 18 Dec 2009 09:12:34 +0100
De: Stefani Seibold stef...@seibold.net
Para: linux-ker...@vger.kernel.org, Andrew Morton 
a...@linux-foundation.org,  Mauro Carvalho Chehab 
mche...@infradead.org

This patch will fix the cx23888 driver to use the new kfifo API.

The patch-set is against current mm tree from 11-Dec-2009

Greetings,
Stefani

Signed-off-by: Stefani Seibold stef...@seibold.net
---
 cx23888-ir.c |   35 ++-
 1 file changed, 10 insertions(+), 25 deletions(-)

--- mmotm.orig/drivers/media/video/cx23885/cx23888-ir.c 2009-12-18 
08:42:53.936778002 +0100
+++ mmotm/drivers/media/video/cx23885/cx23888-ir.c  2009-12-18 
09:03:04.808703259 +0100
 
@@ -631,7 +629,7 @@ static int cx23888_ir_irq_handler(struct
cx23888_ir_write4(dev, CX23888_IR_CNTRL_REG, cntrl);
*handled = true;
}
-   if (kfifo_len(state-rx_kfifo) = CX23888_IR_RX_KFIFO_SIZE / 2)
+   if (kfifo_len(state-rx_kfifo) = CX23888_IR_RX_KFIFO_SIZE / 2)
events |= V4L2_SUBDEV_IR_RX_FIFO_SERVICE_REQ;
 
if (events)
   
   I am concerned about reading the kfifo_len() without taking the lock,
   since another thread on another CPU may be reading from the kfifo at the
   same time.
   
   If the new kfifo implementation has an atomic_read() or something behind
   the kfifo_len() call, then OK.
   
   
@@ -657,7 +655,7 @@ static int cx23888_ir_rx_read(struct v4l
return 0;
}
 
-   n = kfifo_get(state-rx_kfifo, buf, n);
+   n = kfifo_out_locked(state-rx_kfifo, buf, n, 
state-rx_kfifo_lock);
 
n /= sizeof(u32);
*num = n * sizeof(u32);
@@ -785,7 +783,7 @@ static int cx23888_ir_rx_s_parameters(st
o-interrupt_enable = p-interrupt_enable;
o-enable = p-enable;
if (p-enable) {
-   kfifo_reset(state-rx_kfifo);
+   kfifo_reset(state-rx_kfifo);
if (p-interrupt_enable)
irqenable_rx(dev, IRQEN_RSE | IRQEN_RTE | 
IRQEN_ROE);
control_rx_enable(dev, p-enable);
   
   Same concern about kfifo_reset() not taking the lock, and another thread
   reading data from the kfifo at the same time.  In the cx23885 module,
   this would mostly likely happen only during module unload as things are
   being shut down.
   
 
  Sorry, i ported it only to the new API. I did not touch the
  functionality.
 
 Stefani,
 
 Huh?  The new kfifo implementation you wrote removed the locks from
 kfifo_len() and kfifo_reset().  By changing those two functions to not
 provide locking, you changed the functionality.

You are right. Brain was temporary switch off. But kfifo_len() did not
requiere a lock in my opinion. It is save to use without a look. 

But the use of kfifo_reset() is without locking dangerous. 

I will write a path to lock your operations and send it to andrew.

Stefani


--
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: [Fwd: [patch] media video cx23888 driver: ported to new kfifo API]

2009-12-18 Thread Andrew Morton
On Fri, 18 Dec 2009 22:57:22 +0100
Stefani Seibold stef...@seibold.net wrote:

 But kfifo_len() did not
 requiere a lock in my opinion. It is save to use without a look. 

What do you mean by this?  Safe in general, or safe in this particular driver?

In either case: why?
--
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: [Fwd: [patch] media video cx23888 driver: ported to new kfifo API]

2009-12-18 Thread Stefani Seibold
Am Freitag, den 18.12.2009, 14:00 -0800 schrieb Andrew Morton:
 On Fri, 18 Dec 2009 22:57:22 +0100
 Stefani Seibold stef...@seibold.net wrote:
 
  But kfifo_len() did not
  requiere a lock in my opinion. It is save to use without a look. 
 
 What do you mean by this?  Safe in general, or safe in this particular driver?
 

Safe until you don't call kfifo_reset(). kfifo_reset() is evil, because
it it the only function which breaks the single read/writer concept. 

This function modifies the in and the out fifo counters. Thats why i
introduced the kfifo_reset_out() function, which set the out to the
value of in, which means the fifo is empty. This function can be call
from the receiver of a fifo without locking.  

Stefani




--
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] media video cx23888 driver: fix possible races using new kfifo_API kfifo_reset()

2009-12-18 Thread Stefani Seibold
Fix the cx23888 driver to use the new kfifo API. Using kfifo_reset() may
result in a possible race conditions. This patch fix it by using
spinlock around the kfifo_reset() function.

The patch-set is against mm tree from 11-Dec-2009

Greetings,
Stefani

Signed-off-by: Stefani Seibold stef...@seibold.net
---
 cx23888-ir.c |9 +
 1 file changed, 9 insertions(+)

--- mmotm.orig/drivers/media/video/cx23885/cx23888-ir.c 2009-12-18 
22:57:13.588337402 +0100
+++ mmotm/drivers/media/video/cx23885/cx23888-ir.c  2009-12-18 
23:15:14.651365720 +0100
@@ -519,6 +519,7 @@ static int cx23888_ir_irq_handler(struct
 {
struct cx23888_ir_state *state = to_state(sd);
struct cx23885_dev *dev = state-dev;
+   unsigned long flags;
 
u32 cntrl = cx23888_ir_read4(dev, CX23888_IR_CNTRL_REG);
u32 irqen = cx23888_ir_read4(dev, CX23888_IR_IRQEN_REG);
@@ -629,8 +630,11 @@ static int cx23888_ir_irq_handler(struct
cx23888_ir_write4(dev, CX23888_IR_CNTRL_REG, cntrl);
*handled = true;
}
+
+   spin_lock_irqsave(state-rx_kfifo_lock, flags);
if (kfifo_len(state-rx_kfifo) = CX23888_IR_RX_KFIFO_SIZE / 2)
events |= V4L2_SUBDEV_IR_RX_FIFO_SERVICE_REQ;
+   spin_unlock_irqrestore(state-rx_kfifo_lock, flags);
 
if (events)
v4l2_subdev_notify(sd, V4L2_SUBDEV_IR_RX_NOTIFY, events);
@@ -783,7 +787,12 @@ static int cx23888_ir_rx_s_parameters(st
o-interrupt_enable = p-interrupt_enable;
o-enable = p-enable;
if (p-enable) {
+   unsigned long flags;
+
+   spin_lock_irqsave(state-rx_kfifo_lock, flags);
kfifo_reset(state-rx_kfifo);
+   /* reset tx_fifo too if there is one... */
+   spin_unlock_irqrestore(state-rx_kfifo_lock, flags);
if (p-interrupt_enable)
irqenable_rx(dev, IRQEN_RSE | IRQEN_RTE | IRQEN_ROE);
control_rx_enable(dev, p-enable);


--
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] media video cx23888 driver: fix possible races using new kfifo_API kfifo_reset()

2009-12-18 Thread Andy Walls
On Fri, 2009-12-18 at 23:21 +0100, Stefani Seibold wrote:
 Fix the cx23888 driver to use the new kfifo API. Using kfifo_reset() may
 result in a possible race conditions. This patch fix it by using
 spinlock around the kfifo_reset() function.
 
 The patch-set is against mm tree from 11-Dec-2009
 
 Greetings,
 Stefani
 
 Signed-off-by: Stefani Seibold stef...@seibold.net

For both this patch together with your previous patch:

Reviewed-by: Andy Walls awa...@radix.net
Acked-by: Andy Walls awa...@radix.net

Thanks Stefani.

Regards,
Andy

 ---
  cx23888-ir.c |9 +
  1 file changed, 9 insertions(+)
 
 --- mmotm.orig/drivers/media/video/cx23885/cx23888-ir.c   2009-12-18 
 22:57:13.588337402 +0100
 +++ mmotm/drivers/media/video/cx23885/cx23888-ir.c2009-12-18 
 23:15:14.651365720 +0100
 @@ -519,6 +519,7 @@ static int cx23888_ir_irq_handler(struct
  {
   struct cx23888_ir_state *state = to_state(sd);
   struct cx23885_dev *dev = state-dev;
 + unsigned long flags;
  
   u32 cntrl = cx23888_ir_read4(dev, CX23888_IR_CNTRL_REG);
   u32 irqen = cx23888_ir_read4(dev, CX23888_IR_IRQEN_REG);
 @@ -629,8 +630,11 @@ static int cx23888_ir_irq_handler(struct
   cx23888_ir_write4(dev, CX23888_IR_CNTRL_REG, cntrl);
   *handled = true;
   }
 +
 + spin_lock_irqsave(state-rx_kfifo_lock, flags);
   if (kfifo_len(state-rx_kfifo) = CX23888_IR_RX_KFIFO_SIZE / 2)
   events |= V4L2_SUBDEV_IR_RX_FIFO_SERVICE_REQ;
 + spin_unlock_irqrestore(state-rx_kfifo_lock, flags);
  
   if (events)
   v4l2_subdev_notify(sd, V4L2_SUBDEV_IR_RX_NOTIFY, events);
 @@ -783,7 +787,12 @@ static int cx23888_ir_rx_s_parameters(st
   o-interrupt_enable = p-interrupt_enable;
   o-enable = p-enable;
   if (p-enable) {
 + unsigned long flags;
 +
 + spin_lock_irqsave(state-rx_kfifo_lock, flags);
   kfifo_reset(state-rx_kfifo);
 + /* reset tx_fifo too if there is one... */
 + spin_unlock_irqrestore(state-rx_kfifo_lock, flags);
   if (p-interrupt_enable)
   irqenable_rx(dev, IRQEN_RSE | IRQEN_RTE | IRQEN_ROE);
   control_rx_enable(dev, p-enable);
 
 

--
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 - v2 5/6] V4L - vpfe capture - build environment for isif driver

2009-12-18 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

updated based on comments against v1 of the patch

Adding Makefile and Kconfig for ISIF driver

Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Reviewed-by: Sergei Shtylyov sshtyl...@ru.mvista.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next tree
 drivers/media/video/Kconfig  |   14 +-
 drivers/media/video/davinci/Makefile |1 +
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 2f83be7..bcf3c17 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -548,7 +548,6 @@ config VIDEO_VPSS_SYSTEM
depends on ARCH_DAVINCI
help
  Support for vpss system module for video driver
-   default y
 
 config VIDEO_VPFE_CAPTURE
tristate VPFE Video Capture Driver
@@ -592,6 +591,19 @@ config VIDEO_DM355_CCDC
   To compile this driver as a module, choose M here: the
   module will be called vpfe.
 
+config VIDEO_ISIF
+   tristate ISIF HW module
+   depends on ARCH_DAVINCI_DM365  VIDEO_VPFE_CAPTURE
+   select VIDEO_VPSS_SYSTEM
+   default y
+   help
+  Enables 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.
+
+  To compile this driver as a module, choose M here: the
+  module will be called vpfe.
+
 source drivers/media/video/bt8xx/Kconfig
 
 config VIDEO_PMS
diff --git a/drivers/media/video/davinci/Makefile 
b/drivers/media/video/davinci/Makefile
index 1a8b8f3..a379557 100644
--- a/drivers/media/video/davinci/Makefile
+++ b/drivers/media/video/davinci/Makefile
@@ -15,3 +15,4 @@ 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_ISIF) += isif.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 - v2 1/6] V4L - vpfe capture - header files for ISIF driver

2009-12-18 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

Updated based on comments against v1 of the patch

This is the header file for ISIF driver on DM365.  ISIF driver is equivalent
to CCDC driver on DM355 and DM644x. This driver is tested for
YUV capture from TVP514x driver. This patch contains the header files required 
for
this driver. The name of the file is changed to reflect the name of IP.

Reviewed-by: Nori, Sekhar nsek...@ti.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl 
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next tree of v4l-dvb
 drivers/media/video/davinci/isif_regs.h |  269 
 include/media/davinci/isif.h|  531 +++
 2 files changed, 800 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/isif_regs.h
 create mode 100644 include/media/davinci/isif.h

diff --git a/drivers/media/video/davinci/isif_regs.h 
b/drivers/media/video/davinci/isif_regs.h
new file mode 100644
index 000..f7b8893
--- /dev/null
+++ b/drivers/media/video/davinci/isif_regs.h
@@ -0,0 +1,269 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#ifndef _ISIF_REGS_H
+#define _ISIF_REGS_H
+
+/* ISIF registers relative offsets */
+#define SYNCEN 0x00
+#define MODESET0x04
+#define HDW0x08
+#define VDW0x0c
+#define PPLN   0x10
+#define LPFR   0x14
+#define SPH0x18
+#define LNH0x1c
+#define SLV0   0x20
+#define SLV1   0x24
+#define LNV0x28
+#define CULH   0x2c
+#define CULV   0x30
+#define HSIZE  0x34
+#define SDOFST 0x38
+#define CADU   0x3c
+#define CADL   0x40
+#define LINCFG00x44
+#define LINCFG10x48
+#define CCOLP  0x4c
+#define CRGAIN 0x50
+#define CGRGAIN0x54
+#define CGBGAIN0x58
+#define CBGAIN 0x5c
+#define COFSTA 0x60
+#define FLSHCFG0   0x64
+#define FLSHCFG1   0x68
+#define FLSHCFG2   0x6c
+#define VDINT0 0x70
+#define VDINT1 0x74
+#define VDINT2 0x78
+#define MISC   0x7c
+#define CGAMMAWD   0x80
+#define REC656IF   0x84
+#define CCDCFG 0x88
+/*
+* Defect Correction registers
+*/
+#define DFCCTL 0x8c
+#define VDFSATLV   0x90
+#define DFCMEMCTL  0x94
+#define DFCMEM00x98
+#define DFCMEM10x9c
+#define DFCMEM20xa0
+#define DFCMEM30xa4
+#define DFCMEM40xa8
+/
+* Black Clamp registers
+/
+#define CLAMPCFG   0xac
+#define CLDCOFST   0xb0
+#define CLSV   0xb4
+#define CLHWIN00xb8
+#define CLHWIN10xbc
+#define CLHWIN20xc0
+#define CLVRV   

[PATCH - v2 6/6] DaVinci - Adding platform code for vpfe capture on DM365

2009-12-18 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

updated based on comments against v1 of the patch

Adding platform code for supporting vpfe capture and ISIF driver on DM365.

Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next of v4l-dvb
 arch/arm/mach-davinci/board-dm365-evm.c|   71 +++
 arch/arm/mach-davinci/dm365.c  |  101 +++-
 arch/arm/mach-davinci/include/mach/dm365.h |2 +
 3 files changed, 173 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index 289fe1b..06f53bf 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -37,6 +37,8 @@
 #include mach/nand.h
 #include mach/keyscan.h
 
+#include media/tvp514x.h
+
 static inline int have_imager(void)
 {
/* REVISIT when it's supported, trigger via Kconfig */
@@ -302,6 +304,73 @@ static void dm365evm_mmc_configure(void)
davinci_cfg_reg(DM365_SD1_DATA0);
 }
 
+static struct tvp514x_platform_data tvp5146_pdata = {
+   .clk_polarity = 0,
+   .hs_polarity = 1,
+   .vs_polarity = 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[] = {
+   {
+   .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,
+   .i2c_adapter_id = 1,
+   .card_name = DM365 EVM,
+   .ccdc = ISIF,
+};
+
 static void __init evm_init_i2c(void)
 {
davinci_init_i2c(i2c_pdata);
@@ -493,6 +562,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 2ec619e..7da8a91 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -459,6 +459,7 @@ static struct davinci_clk dm365_clks[] = {
CLK(davinci-asp.0, NULL, asp0_clk),
CLK(NULL, rto, rto_clk),
CLK(NULL, mjcp, mjcp_clk),
+   CLK(isif, master, vpss_master_clk),
CLK(NULL, NULL, NULL),
 };
 
@@ -1009,6 +1010,97 @@ void __init dm365_init(void)
davinci_common_init(davinci_soc_info_dm365);
 }
 
+static struct resource dm365_vpss_resources[] = {
+   {
+   /* VPSS ISP5 Base address */
+   .name   = isp5,
+   .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,
+   .end= 

[PATCH - v2 4/6] V4L - vpfe_capture - bug fixes and enhancements

2009-12-18 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

Updated based on comments against v1 of the patch

Added a experimental IOCTL, to read the CCDC parameters.
Default handler was not getting the original pointer from the core.
So a wrapper function added to handle the default handler properly.
Also fixed a bug in the probe() in the linux-next tree

Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next of v4l-dvb
 drivers/media/video/davinci/vpfe_capture.c |  120 +---
 include/media/davinci/vpfe_capture.h   |   12 ++-
 2 files changed, 81 insertions(+), 51 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c 
b/drivers/media/video/davinci/vpfe_capture.c
index 9e3a531..99ffc62 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -758,12 +758,83 @@ static unsigned int vpfe_poll(struct file *file, 
poll_table *wait)
return 0;
 }
 
+static long vpfe_param_handler(struct file *file, void *priv,
+   int cmd, void *param)
+{
+   struct vpfe_device *vpfe_dev = video_drvdata(file);
+   int ret = 0;
+
+   v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_param_handler\n);
+
+   if (NULL == param) {
+   v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+   Invalid user ptr\n);
+   return -EINVAL;
+   }
+
+   if (vpfe_dev-started) {
+   /* only allowed if streaming is not started */
+   v4l2_err(vpfe_dev-v4l2_dev, device already started\n);
+   return -EBUSY;
+   }
+
+   switch (cmd) {
+   case VPFE_CMD_S_CCDC_RAW_PARAMS:
+   v4l2_warn(vpfe_dev-v4l2_dev,
+ VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
+   ret = mutex_lock_interruptible(vpfe_dev-lock);
+   if (ret)
+   return ret;
+   ret = ccdc_dev-hw_ops.set_params(param);
+   if (ret) {
+   v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+   Error in setting parameters in CCDC\n);
+   goto unlock_out;
+   }
+
+   if (vpfe_get_ccdc_image_format(vpfe_dev, vpfe_dev-fmt)  0) {
+   v4l2_err(vpfe_dev-v4l2_dev,
+   Invalid image format at CCDC\n);
+   ret = -EINVAL;
+   }
+unlock_out:
+   mutex_unlock(vpfe_dev-lock);
+   break;
+   case VPFE_CMD_G_CCDC_RAW_PARAMS:
+   v4l2_warn(vpfe_dev-v4l2_dev,
+ VPFE_CMD_G_CCDC_RAW_PARAMS: experimental ioctl\n);
+   if (!ccdc_dev-hw_ops.get_params) {
+   ret = -EINVAL;
+   break;
+   }
+   ret = ccdc_dev-hw_ops.get_params(param);
+   if (ret) {
+   v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+   Error in getting parameters from CCDC\n);
+   }
+   break;
+   default:
+   ret = -EINVAL;
+   break;
+   }
+   return ret;
+}
+
+static long vpfe_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+   if (cmd == VPFE_CMD_S_CCDC_RAW_PARAMS ||
+   cmd == VPFE_CMD_G_CCDC_RAW_PARAMS)
+   return vpfe_param_handler(file, file-private_data, cmd,
+(void *)arg);
+   return video_ioctl2(file, cmd, arg);
+}
+
 /* vpfe capture driver file operations */
 static const struct v4l2_file_operations vpfe_fops = {
.owner = THIS_MODULE,
.open = vpfe_open,
.release = vpfe_release,
-   .unlocked_ioctl = video_ioctl2,
+   .unlocked_ioctl = vpfe_ioctl,
.mmap = vpfe_mmap,
.poll = vpfe_poll
 };
@@ -1681,50 +1752,6 @@ unlock_out:
return ret;
 }
 
-
-static long vpfe_param_handler(struct file *file, void *priv,
-   int cmd, void *param)
-{
-   struct vpfe_device *vpfe_dev = video_drvdata(file);
-   int ret = 0;
-
-   v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_param_handler\n);
-
-   if (vpfe_dev-started) {
-   /* only allowed if streaming is not started */
-   v4l2_err(vpfe_dev-v4l2_dev, device already started\n);
-   return -EBUSY;
-   }
-
-   ret = mutex_lock_interruptible(vpfe_dev-lock);
-   if (ret)
-   return ret;
-
-   switch (cmd) {
-   case VPFE_CMD_S_CCDC_RAW_PARAMS:
-   v4l2_warn(vpfe_dev-v4l2_dev,
- VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
-   ret = ccdc_dev-hw_ops.set_params(param);
-   if (ret) {
-   v4l2_err(vpfe_dev-v4l2_dev,
-   Error in setting parameters in CCDC\n);
-   goto unlock_out;
-  

[PATCH - v2 2/6] V4L - vpfe capture - source for ISIF driver on DM365

2009-12-18 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

Updated based on comments against v1 of the patch.

This is the source file for ISIF driver for DM365.  ISIF driver is equivalent
to CCDC driver on DM355 and DM644x. This driver is tested for
YUV capture from TVP514x driver. This patch contains the header files required 
for
this driver. The name of the file is changed to reflect the name of IP.

Reviewed-by: Nori, Sekhar nsek...@ti.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next tree of v4l-dvb 
 drivers/media/video/davinci/isif.c | 1512 
 1 files changed, 1512 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/isif.c

diff --git a/drivers/media/video/davinci/isif.c 
b/drivers/media/video/davinci/isif.c
new file mode 100644
index 000..73eedec
--- /dev/null
+++ b/drivers/media/video/davinci/isif.c
@@ -0,0 +1,1512 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * Image Sensor Interface (ISIF) driver
+ *
+ * This driver is for configuring the ISIF IP available on DM365 or any other
+ * TI SoCs. This is used for capturing yuv or bayer video or image data
+ * from an decoder or sensor. This IP is similar to the CCDC IP on DM355
+ * and DM6446, but with enhanced or additional ip blocks. The driver
+ * configures the ISIF upon commands from the vpfe bridge driver through
+ * ccdc_hw_device interface.
+ *
+ * TODO: 1) Raw bayer parameter settings and bayer capture
+ *  2) Add support for control ioctl
+ */
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include linux/io.h
+#include linux/videodev2.h
+#include linux/clk.h
+
+#include mach/mux.h
+
+#include media/davinci/isif.h
+#include media/davinci/vpss.h
+
+#include isif_regs.h
+#include ccdc_hw_device.h
+
+/* Defaults for module configuration parameters */
+static struct isif_config_params_raw isif_config_defaults = {
+   .linearize = {
+   .en = 0,
+   .corr_shft = ISIF_NO_SHIFT,
+   .scale_fact = {1, 0},
+   },
+   .df_csc = {
+   .df_or_csc = 0,
+   .csc = {
+   .en = 0,
+   },
+   },
+   .dfc = {
+   .en = 0,
+   },
+   .bclamp = {
+   .en = 0,
+   },
+   .gain_offset = {
+   .gain = {
+   .r_ye = {1, 0},
+   .gr_cy = {1, 0},
+   .gb_g = {1, 0},
+   .b_mg = {1, 0},
+   },
+   },
+   .culling = {
+   .hcpat_odd = 0xff,
+   .hcpat_even = 0xff,
+   .vcpat = 0xff,
+   },
+   .compress = {
+   .alg = ISIF_ALAW,
+   },
+};
+
+/* ISIF operation configuration */
+static struct isif_oper_config {
+   struct device *dev;
+   enum vpfe_hw_if_type if_type;
+   struct isif_ycbcr_config ycbcr;
+   struct isif_params_raw bayer;
+   enum isif_data_pack data_pack;
+   /* Master clock */
+   struct clk *mclk;
+   /* ISIF base address */
+   void __iomem *base_addr;
+   /* ISIF Linear Table 0 */
+   void __iomem *linear_tbl0_addr;
+   /* ISIF Linear Table 1 */
+   void __iomem *linear_tbl1_addr;
+} isif_cfg = {
+   .ycbcr = {
+   .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+   .frm_fmt = CCDC_FRMFMT_INTERLACED,
+   .win = ISIF_WIN_NTSC,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .pix_order = CCDC_PIXORDER_CBYCRY,
+   .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED,
+   },
+   .bayer = {
+   .pix_fmt = CCDC_PIXFMT_RAW,
+   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+   .win = ISIF_WIN_VGA,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .gain = {
+   .r_ye = {1, 0},
+   .gr_cy = {1, 0},
+   .gb_g = {1, 0},
+   

[PATCH - v2 3/6] V4L - vpfe capture - vpss driver enhancements for DM365

2009-12-18 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

No change from v1 of the patch

Enhancements to support DM365 ISP5 and VPSS module configuration.
Also cleaned up the driver by removing redundant variables.

Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next v4l-dvb tree
 drivers/media/video/davinci/vpss.c |  289 +---
 include/media/davinci/vpss.h   |   41 +-
 2 files changed, 275 insertions(+), 55 deletions(-)

diff --git a/drivers/media/video/davinci/vpss.c 
b/drivers/media/video/davinci/vpss.c
index 7ee72ec..7918680 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -15,7 +15,7 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  *
- * common vpss driver for all video drivers.
+ * common vpss system module platform driver for all video drivers.
  */
 #include linux/kernel.h
 #include linux/sched.h
@@ -35,12 +35,52 @@ MODULE_AUTHOR(Texas Instruments);
 /* DM644x defines */
 #define DM644X_SBL_PCR_VPSS(4)
 
+#define DM355_VPSSBL_INTSEL0x10
+#define DM355_VPSSBL_EVTSEL0x14
 /* vpss BL register offsets */
 #define DM355_VPSSBL_CCDCMUX   0x1c
 /* vpss CLK register offsets */
 #define DM355_VPSSCLK_CLKCTRL  0x04
 /* masks and shifts */
 #define VPSS_HSSISEL_SHIFT 4
+/*
+ * VDINT0 - vpss_int0, VDINT1 - vpss_int1, H3A - vpss_int4,
+ * IPIPE_INT1_SDR - vpss_int5
+ */
+#define DM355_VPSSBL_INTSEL_DEFAULT0xff83ff10
+/* VENCINT - vpss_int8 */
+#define DM355_VPSSBL_EVTSEL_DEFAULT0x4
+
+#define DM365_ISP5_PCCR0x04
+#define DM365_ISP5_INTSEL1 0x10
+#define DM365_ISP5_INTSEL2 0x14
+#define DM365_ISP5_INTSEL3 0x18
+#define DM365_ISP5_CCDCMUX 0x20
+#define DM365_ISP5_PG_FRAME_SIZE   0x28
+#define DM365_VPBE_CLK_CTRL0x00
+/*
+ * vpss interrupts. VDINT0 - vpss_int0, VDINT1 - vpss_int1,
+ * AF - vpss_int3
+ */
+#define DM365_ISP5_INTSEL1_DEFAULT 0x0b1f0100
+/* AEW - vpss_int6, RSZ_INT_DMA - vpss_int5 */
+#define DM365_ISP5_INTSEL2_DEFAULT 0x1f0a0f1f
+/* VENC - vpss_int8 */
+#define DM365_ISP5_INTSEL3_DEFAULT 0x0015
+
+/* masks and shifts for DM365*/
+#define DM365_CCDC_PG_VD_POL_SHIFT 0
+#define DM365_CCDC_PG_HD_POL_SHIFT 1
+
+#define CCD_SRC_SEL_MASK   (BIT_MASK(5) | BIT_MASK(4))
+#define CCD_SRC_SEL_SHIFT  4
+
+/* Different SoC platforms supported by this driver */
+enum vpss_platform_type {
+   DM644X,
+   DM355,
+   DM365,
+};
 
 /*
  * vpss operations. Depends on platform. Not all functions are available
@@ -59,13 +99,9 @@ struct vpss_hw_ops {
 
 /* vpss configuration */
 struct vpss_oper_config {
-   __iomem void *vpss_bl_regs_base;
-   __iomem void *vpss_regs_base;
-   struct resource *r1;
-   resource_size_t len1;
-   struct resource *r2;
-   resource_size_t len2;
-   char vpss_name[32];
+   __iomem void *vpss_regs_base0;
+   __iomem void *vpss_regs_base1;
+   enum vpss_platform_type platform;
spinlock_t vpss_lock;
struct vpss_hw_ops hw_ops;
 };
@@ -75,22 +111,46 @@ 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 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);
+}
+
+/* For DM365 only */
+static inline u32 isp5_read(u32 offset)
+{
+   return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+/* For DM365 only */
+static inline void isp5_write(u32 val, u32 offset)
+{
+   __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+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);
 }
 
 static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -101,9 +161,9 @@ static void dm355_select_ccdc_source(enum 
vpss_ccdc_source_sel src_sel)
 int 

[PATCH - v2 2/6] V4L - vpfe capture - source for ISIF driver on DM365

2009-12-18 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

Re-sending removing a typo in the source header 

Updated based on comments against v1 of the patch.

This is the source file for ISIF driver for DM365.  ISIF driver is equivalent
to CCDC driver on DM355 and DM644x. This driver is tested for
YUV capture from TVP514x driver. This patch contains the header files required 
for
this driver. The name of the file is changed to reflect the name of IP.

Reviewed-by: Nori, Sekhar nsek...@ti.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next tree of v4l-dvb 
 drivers/media/video/davinci/isif.c | 1512 
 1 files changed, 1512 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/isif.c

diff --git a/drivers/media/video/davinci/isif.c 
b/drivers/media/video/davinci/isif.c
new file mode 100644
index 000..73eedec
--- /dev/null
+++ b/drivers/media/video/davinci/isif.c
@@ -0,0 +1,1512 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * Image Sensor Interface (ISIF) driver
+ *
+ * This driver is for configuring the ISIF IP available on DM365 or any other
+ * TI SoCs. This is used for capturing yuv or bayer video or image data
+ * from a decoder or sensor. This IP is similar to the CCDC IP on DM355
+ * and DM6446, but with enhanced or additional ip blocks. The driver
+ * configures the ISIF upon commands from the vpfe bridge driver through
+ * ccdc_hw_device interface.
+ *
+ * TODO: 1) Raw bayer parameter settings and bayer capture
+ *  2) Add support for control ioctl
+ */
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include linux/io.h
+#include linux/videodev2.h
+#include linux/clk.h
+
+#include mach/mux.h
+
+#include media/davinci/isif.h
+#include media/davinci/vpss.h
+
+#include isif_regs.h
+#include ccdc_hw_device.h
+
+/* Defaults for module configuration parameters */
+static struct isif_config_params_raw isif_config_defaults = {
+   .linearize = {
+   .en = 0,
+   .corr_shft = ISIF_NO_SHIFT,
+   .scale_fact = {1, 0},
+   },
+   .df_csc = {
+   .df_or_csc = 0,
+   .csc = {
+   .en = 0,
+   },
+   },
+   .dfc = {
+   .en = 0,
+   },
+   .bclamp = {
+   .en = 0,
+   },
+   .gain_offset = {
+   .gain = {
+   .r_ye = {1, 0},
+   .gr_cy = {1, 0},
+   .gb_g = {1, 0},
+   .b_mg = {1, 0},
+   },
+   },
+   .culling = {
+   .hcpat_odd = 0xff,
+   .hcpat_even = 0xff,
+   .vcpat = 0xff,
+   },
+   .compress = {
+   .alg = ISIF_ALAW,
+   },
+};
+
+/* ISIF operation configuration */
+static struct isif_oper_config {
+   struct device *dev;
+   enum vpfe_hw_if_type if_type;
+   struct isif_ycbcr_config ycbcr;
+   struct isif_params_raw bayer;
+   enum isif_data_pack data_pack;
+   /* Master clock */
+   struct clk *mclk;
+   /* ISIF base address */
+   void __iomem *base_addr;
+   /* ISIF Linear Table 0 */
+   void __iomem *linear_tbl0_addr;
+   /* ISIF Linear Table 1 */
+   void __iomem *linear_tbl1_addr;
+} isif_cfg = {
+   .ycbcr = {
+   .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+   .frm_fmt = CCDC_FRMFMT_INTERLACED,
+   .win = ISIF_WIN_NTSC,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .pix_order = CCDC_PIXORDER_CBYCRY,
+   .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED,
+   },
+   .bayer = {
+   .pix_fmt = CCDC_PIXFMT_RAW,
+   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+   .win = ISIF_WIN_VGA,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .gain = {
+   .r_ye = {1, 0},
+   .gr_cy = {1, 0},
+  

Re: linux-next: Tree for December 19 (media/mantis)

2009-12-18 Thread Randy Dunlap
On Sat, 19 Dec 2009 11:04:57 +1100 Stephen Rothwell wrote:

 Hi all,
 
 I said:
  News:  there will be no linux-next releases until at least Dec 24 and,
  more likely, Dec 29.  Have a Merry Christmas and take a break.  :-)
 
 Well, I decided I had time for one more so it will be based in -rc1).
 
 This one has not had the build testing *between* merges, but has had all
 the normal build testing at the end.  Since the latter testing showed no
 problems, this just means that there may be more unbisectable points in
 the tree (but that is unlikely).



ERROR: ir_input_register [drivers/media/dvb/mantis/mantis_core.ko] undefined!
ERROR: ir_input_unregister [drivers/media/dvb/mantis/mantis_core.ko] 
undefined!
ERROR: ir_input_init [drivers/media/dvb/mantis/mantis_core.ko] undefined!
ERROR: input_free_device [drivers/media/dvb/mantis/mantis_core.ko] undefined!
ERROR: input_allocate_device [drivers/media/dvb/mantis/mantis_core.ko] 
undefined!



CONFIG_INPUT=n


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