Re: tcm825x.c: migrating to sub-device framework?

2009-06-15 Thread Sakari Ailus

Hans Verkuil wrote:

On Sunday 14 June 2009 14:44:53 Hans Verkuil wrote:

On Sunday 14 June 2009 12:14:38 Hans Verkuil wrote:

On Wednesday 06 May 2009 20:31:33 hvaib...@ti.com wrote:

From: Vaibhav Hiremath hvaib...@ti.com

This patch converts TVP514x driver to sub-device framework
from V4L2-int framework.


Now that tvp514x is converted to using v4l2_subdev (pending a few small final
tweaks) there is only one driver left that uses the v4l2-int-device.h API:
tcm825x.c.


There's also the OMAP 2 camera driver (master), 
drivers/media/video/omap24xxcam.c. The tcm825x is the slave driver that 
is used in conjunction with omap24xxcam on N800 and N810.


--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: dib3000mc.c and dib7000p.c compiler warnings

2009-06-15 Thread Patrick Boettcher

Hi Hans,
On Sun, 14 Jun 2009, Hans Verkuil wrote:


Hi Patrick,

The daily build reports these warnings for dib3000mc.c and dib7000p.c:

/marune/build/v4l-dvb-master/v4l/dib3000mc.c: In
function 'dib3000mc_i2c_enumeration':
/marune/build/v4l-dvb-master/v4l/dib3000mc.c:863: warning: the frame size of
1508 bytes is larger than 1024 bytes

/marune/build/v4l-dvb-master/v4l/dib7000p.c: In
function 'dib7000p_i2c_enumeration':
/marune/build/v4l-dvb-master/v4l/dib7000p.c:1341: warning: the frame size of
1568 bytes is larger than 1024 bytes

In both cases a big state struct is allocated on the stack. Would it be
possible to optimize that?


I agree that this is ugly and in fact I already have a solution for that. 
But it's not ready as a patch nor can it published :(.


I won't be able to work on it before mid-July. But then I will provide a 
solution.


thanks for raising this important problem,
Patrick.
--
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 2/2] uvc: Added two webcams with 'No FID' quirk.

2009-06-15 Thread Laurent Pinchart
On Friday 12 June 2009 18:53:29 Robert Krakora wrote:
 From: Robert Krakora rob.krak...@messagenetsystems.com

 Added two webcams with 'No FID' quirk.

 Priority: normal

 Signed-off-by: Robert Krakora rob.krak...@messagenetsystems.com

 diff -r bff77ec33116 linux/drivers/media/video/uvc/uvc_driver.c
 --- a/linux/drivers/media/video/uvc/uvc_driver.cThu Jun 11
 18:44:23 2009 -0300
 +++ b/linux/drivers/media/video/uvc/uvc_driver.cFri Jun 12
 11:35:04 2009 -0400
 @@ -1919,6 +1919,24 @@
   .bInterfaceSubClass   = 1,
   .bInterfaceProtocol   = 0,
   .driver_info  = UVC_QUIRK_STREAM_NO_FID },
 +   /* Suyin Corp. HP Webcam */
 +   { .match_flags  = USB_DEVICE_ID_MATCH_DEVICE
 +   | USB_DEVICE_ID_MATCH_INT_INFO,
 + .idVendor = 0x064e,
 + .idProduct= 0xa110,
 + .bInterfaceClass  = USB_CLASS_VIDEO,
 + .bInterfaceSubClass   = 1,
 + .bInterfaceProtocol   = 0,
 + .driver_info  = UVC_QUIRK_STREAM_NO_FID },
 +   /* Creative Live! Cam Optia AF */
 +   { .match_flags  = USB_DEVICE_ID_MATCH_DEVICE
 +   | USB_DEVICE_ID_MATCH_INT_INFO,
 + .idVendor = 0x041e,
 + .idProduct= 0x406d,
 + .bInterfaceClass  = USB_CLASS_VIDEO,
 + .bInterfaceSubClass   = 1,
 + .bInterfaceProtocol   = 0,
 + .driver_info  = UVC_QUIRK_STREAM_NO_FID },

NAK. Those cameras have been reported to work without the FID quirk. Please 
double-check. If the quirk is required on your side I'd like to see logs.

Best regards,

Laurent Pinchart

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


Re: [PATCH 1/2] uvc: Fix for no return value check of uvc_ctrl_set() which calls mutex_lock_interruptible()

2009-06-15 Thread Laurent Pinchart
On Friday 12 June 2009 18:51:03 Robert Krakora wrote:
 From: Robert Krakora rob.krak...@messagenetsystems.com

 Fix for no return value check of uvc_ctrl_set() which calls
 mutex_lock_interruptible().

 Priority: normal

 Signed-off-by: Robert Krakora rob.krak...@messagenetsystems.com

Acked-by: Laurent Pinchart laurent.pinch...@skynet.be

I'd appreciate if you would at least CC me when submitting patches related to 
the Linux UVC driver in the future.

Regards,

Laurent Pinchart

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


RFC: remove video_register_device_index, add video_register_device_range

2009-06-15 Thread Hans Verkuil
Hi all,

While looking at the video_register_device changes that broke ov511 I realized
that the video_register_device_index function is never called from drivers. It
will always assign a default index number. I also don't see a good use-case
for giving it an explicit index. My proposal is to remove this API. Since it
is never called, nothing will change effectively. I'm never happy with unused
functions.

However, I think we do need a new video_register_device_range function. This
would be identical to video_register_device, but with an additional count
argument: this allows drivers to select a kernel number in the range of
nr to nr + count - 1. If cnt == -1, then the maximum is the compiled-in
maximum.

So video_register_device would call video_register_device_range(...nr, 1),
thus restoring the original behavior, while ivtv and cx18 can call
video_register_device_range(...nr, -1), thus keeping the current behavior.

Comments?

Regards,

Hans

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


Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc

2009-06-15 Thread Hans Verkuil
On Sunday 14 June 2009 12:15:34 Hans Verkuil wrote:
 On Sunday 14 June 2009 11:50:51 Hans Verkuil wrote:
  Hi Mauro,
  
  Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the 
  following:
  
  - ivtv/cx18: fix regression: class controls are no longer seen
  - v4l2-ctl: add modulator get/set options.
  - v4l2-spec: update VIDIOC_G/S_MODULATOR section.
  - compat: fix __fls check for the arm architecture.
  - smscoreapi: fix compile warning
  
  The first one is a high prio bug as it is a 2.6.30 regression. Mike, once 
  this is merged in the git tree this one can be queued for the 2.6.30 stable 
  series.
  
  The other changes are small stuff.
 
 Added one more minor change:
 
 - v4l2-i2c-drv.h: add comment describing when not to use this header.

And added this one as well:

- v4l2-dev: fix some confusing variable names and comments

Regards,

Hans


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


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

2009-06-15 Thread Mauro Carvalho Chehab
Em Thu, 11 Jun 2009 15:35:14 -0700 (PDT)
Trent Piepho xy...@speakeasy.org escreveu:

 On Thu, 11 Jun 2009, Patrick Boettcher wrote:
  On Wed, 27 May 2009, Trent Piepho wrote:
   On Tue, 26 May 2009, Patrick Boettcher wrote:
   Does this patch to fix these problems look ok?
 
  In fact, everything looks correct in my eyes. I'll ask Mauro to pull any
  minute from now.
 
  I even have an explaination why the failing attach of the itd1000 was
  not errored out: when I did the development I was using a userspace
  proprietary driver to validate, for that I needed the demod to be
  attached...
 
  Thanks for cleaning up this mess.
 
 Now that that patch is done, here is the rest of the series with dvb-pll
 conversions.  There is an additional patch to the flexcop card detecting
 code.  The #if defined(CONFIG_...) stuff didn't take into account code
 being compiled into the kernel.
 
 Here's the series:
 
 01/08: dvb-pll: Add Samsung TDTC9251DH0 DVB-T NIM
 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=3d148fee550b
 
 02/08: dvb-pll: Add support for Samsung TBDU18132 DVB-S NIM
 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=5a8e32e94aa7
 
 03/08: dvb-pll: Add support for Samsung TBMU24112 DVB-S NIM
 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c28394056a5a
 
 04/08: dvb-pll: Add support for Alps TDEE4 DVB-C NIM
 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=90f54e498f90
 
 05/08: b2c2: fix frontends compiled into kernel
 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=748c762fcf3e
 
 06/08: b2c2: Use dvb-pll for AirStar DVB-T's tuner
 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=fcacc65753f1
 
 07/08: b2c2: Use dvb-pll for Skystar2 rev 2.3 and rev 2.6
 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=8ef37f1432e6
 
 08/08: b2c2: Use dvb-pll for Cablestar2
 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=01fd4e3bd1c0

Nice patches. Are those tested with real cards?

In particular, I loved this:

+/* Can we use the specified front-end?  Remember that if we are compiled
+ * into the kernel we can't call code that's in modules.  */
+#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
+   (defined(CONFIG_DVB_##fe##_MODULE)  defined(MODULE)))

IMO, you should add it on a dvb core header. Then, a cleanup patch would be to
simplify all those frontend tests all over all the dvb drivers code.

Patrick, 

I think you have some skystar boards. I'd appreciate if you can review
those patches before applying 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: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/

2009-06-15 Thread Patrick Boettcher

Hi Mauro,

On Mon, 15 Jun 2009, Mauro Carvalho Chehab wrote:


Em Thu, 11 Jun 2009 15:35:14 -0700 (PDT)
Trent Piepho xy...@speakeasy.org escreveu:


On Thu, 11 Jun 2009, Patrick Boettcher wrote:

On Wed, 27 May 2009, Trent Piepho wrote:

On Tue, 26 May 2009, Patrick Boettcher wrote:
Does this patch to fix these problems look ok?


In fact, everything looks correct in my eyes. I'll ask Mauro to pull any
minute from now.

I even have an explaination why the failing attach of the itd1000 was
not errored out: when I did the development I was using a userspace
proprietary driver to validate, for that I needed the demod to be
attached...

Thanks for cleaning up this mess.


Now that that patch is done, here is the rest of the series with dvb-pll
conversions.  There is an additional patch to the flexcop card detecting
code.  The #if defined(CONFIG_...) stuff didn't take into account code
being compiled into the kernel.

Here's the series:

01/08: dvb-pll: Add Samsung TDTC9251DH0 DVB-T NIM
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=3d148fee550b

02/08: dvb-pll: Add support for Samsung TBDU18132 DVB-S NIM
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=5a8e32e94aa7

03/08: dvb-pll: Add support for Samsung TBMU24112 DVB-S NIM
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c28394056a5a

04/08: dvb-pll: Add support for Alps TDEE4 DVB-C NIM
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=90f54e498f90

05/08: b2c2: fix frontends compiled into kernel
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=748c762fcf3e

06/08: b2c2: Use dvb-pll for AirStar DVB-T's tuner
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=fcacc65753f1

07/08: b2c2: Use dvb-pll for Skystar2 rev 2.3 and rev 2.6
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=8ef37f1432e6

08/08: b2c2: Use dvb-pll for Cablestar2
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=01fd4e3bd1c0


Nice patches. Are those tested with real cards?

In particular, I loved this:

+/* Can we use the specified front-end?  Remember that if we are compiled
+ * into the kernel we can't call code that's in modules.  */
+#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
+   (defined(CONFIG_DVB_##fe##_MODULE)  defined(MODULE)))

IMO, you should add it on a dvb core header. Then, a cleanup patch would be to
simplify all those frontend tests all over all the dvb drivers code.

Patrick,

I think you have some skystar boards. I'd appreciate if you can review
those patches before applying it.


The only card I use which is using DVB_PLL (now) is the Airstar DVB-T. So 
we need to take some risks and apply to force users to test :). I will ask 
some users I know.


However I won't be able to commit nor test anything before 3.5 weeks 
from now.


regards,
Patrick.

--
  Mail: patrick.boettc...@desy.de
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
--
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 V2] poll method lose race condition

2009-06-15 Thread Figo.zhang

hi Mauro,

 is it ok for this v2?

Best Regards,
Figo.zhang

 2009/6/1 Figo.zhang figo1...@gmail.com
  bttv-driver.c,cx23885-video.c,cx88-video.c: poll method lose
 race condition for capture video.
 
  In v2, use the clear logic.Thanks to Trent Piepho's help.
 
 Signed-off-by: Figo.zhang figo1...@gmail.com
 ---
  drivers/media/video/bt8xx/bttv-driver.c |   20
 
  drivers/media/video/cx23885/cx23885-video.c |   15
 +++
  drivers/media/video/cx88/cx88-video.c   |   15
 +++
  3 files changed, 34 insertions(+), 16 deletions(-)
 
 diff --git a/drivers/media/video/bt8xx/bttv-driver.c
 b/drivers/media/video/bt8xx/bttv-driver.c
 index 23b7499..8d20528 100644
 --- a/drivers/media/video/bt8xx/bttv-driver.c
 +++ b/drivers/media/video/bt8xx/bttv-driver.c
 @@ -3152,6 +3152,7 @@ static unsigned int bttv_poll(struct
 file *file, poll_table *wait)
struct bttv_fh *fh = file-private_data;
struct bttv_buffer *buf;
enum v4l2_field field;
 +   unsigned int rc = POLLERR;
 
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type) {
if (!
 check_alloc_btres(fh-btv,fh,RESOURCE_VBI))
 @@ -3160,9 +3161,10 @@ static unsigned int bttv_poll(struct
 file *file, poll_table *wait)
}
 
if (check_btres(fh,RESOURCE_VIDEO_STREAM)) {
 +   mutex_lock(fh-cap.vb_lock);
/* streaming capture */
if (list_empty(fh-cap.stream))
 -   return POLLERR;
 +   return done;
buf = list_entry(fh-cap.stream.next,struct
 bttv_buffer,vb.stream);
} else {
/* read() capture */
 @@ -3170,16 +3172,16 @@ static unsigned int bttv_poll(struct
 file *file, poll_table *wait)
if (NULL == fh-cap.read_buf) {
/* need to capture a new frame */
if
 (locked_btres(fh-btv,RESOURCE_VIDEO_STREAM))
 -   goto err;
 +   goto done;
fh-cap.read_buf =
 videobuf_sg_alloc(fh-cap.msize);
if (NULL == fh-cap.read_buf)
 -   goto err;
 +   goto done;
fh-cap.read_buf-memory =
 V4L2_MEMORY_USERPTR;
field = videobuf_next_field(fh-cap);
if (0 !=
 fh-cap.ops-buf_prepare(fh-cap,fh-cap.read_buf,field)) {
kfree (fh-cap.read_buf);
fh-cap.read_buf = NULL;
 -   goto err;
 +   goto done;
}
 
  fh-cap.ops-buf_queue(fh-cap,fh-cap.read_buf);
fh-cap.read_off = 0;
 @@ -3191,11 +3193,13 @@ static unsigned int bttv_poll(struct
 file *file, poll_table *wait)
poll_wait(file, buf-vb.done, wait);
if (buf-vb.state == VIDEOBUF_DONE ||
buf-vb.state == VIDEOBUF_ERROR)
 -   return POLLIN|POLLRDNORM;
 -   return 0;
 -err:
 +   rc =  POLLIN|POLLRDNORM;
 +   else
 +   rc = 0;
 +
 +done:
mutex_unlock(fh-cap.vb_lock);
 -   return POLLERR;
 +   return rc;
  }
 
  static int bttv_open(struct file *file)
 diff --git a/drivers/media/video/cx23885/cx23885-video.c
 b/drivers/media/video/cx23885/cx23885-video.c
 index 68068c6..f542493 100644
 --- a/drivers/media/video/cx23885/cx23885-video.c
 +++ b/drivers/media/video/cx23885/cx23885-video.c
 @@ -796,6 +796,7 @@ static unsigned int video_poll(struct file
 *file,
  {
struct cx23885_fh *fh = file-private_data;
struct cx23885_buffer *buf;
 +   unsigned int rc = POLLERR;
 
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type) {
if (!res_get(fh-dev, fh, RESOURCE_VBI))
 @@ -803,23 +804,29 @@ static unsigned int video_poll(struct
 file *file,
return videobuf_poll_stream(file, fh-vbiq,
 wait);
}
 
 +   mutex_lock(fh-vidq.vb_lock);
if (res_check(fh, RESOURCE_VIDEO)) {
 

Re: RFC: remove video_register_device_index, add video_register_device_range

2009-06-15 Thread Mauro Carvalho Chehab
Em Mon, 15 Jun 2009 13:25:28 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:

 Hi all,
 
 While looking at the video_register_device changes that broke ov511 I realized
 that the video_register_device_index function is never called from drivers. It
 will always assign a default index number. I also don't see a good use-case
 for giving it an explicit index. My proposal is to remove this API. Since it
 is never called, nothing will change effectively. I'm never happy with unused
 functions.

It sounds ok to me.

 However, I think we do need a new video_register_device_range function. This
 would be identical to video_register_device, but with an additional count
 argument: this allows drivers to select a kernel number in the range of
 nr to nr + count - 1. If cnt == -1, then the maximum is the compiled-in
 maximum.
 
 So video_register_device would call video_register_device_range(...nr, 1),
 thus restoring the original behavior, while ivtv and cx18 can call
 video_register_device_range(...nr, -1), thus keeping the current behavior.

I don't think that this is needed. The issue with ov511 is that it was using
the error condition of video_register to identify how much ov511 devices were
already registered.

I already fixed it by adding an explicit device number count on it, just like
all the other drivers. With this, ov511 will behave like the other drivers.

With the current implementation, it should honor the explicit minor order
passed via modprobe parameter, as before.

There's one small change on the behavior that it is also present on all other
devices that allow users to explicit the desired minor order: instead of
failing if that device is already used, it will get the next available one.
IMO, this is better than just failing. So, the only remaining issue is that
video_register should print a warning if it had to get a different minor than
specified.

In other words, the enclosed patch seems to be a good approach to close this
issue



Cheers,
Mauro

---

v4l2-dev: Print a warning if need to use a different minor than specified

From: Mauro Carvalho Chehab mche...@redhat.com

video_register_device has two behaviors: dynamic minor attribution or 
forced minor attribution. The latter mode is used to allow users to 
force probing a device using a certain minor order. Even for the last 
case, video_register_device won't fail if that minor is already used 
but, instead, it will seek for the next available minor, without warning 
users about that.

While don't fail due to a busy minor seems the better behavior, it 
should be printing a warning when this happen.

While here, let's remove video_register_device_index(), since no driver 
is using it.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

---
 linux/drivers/media/video/v4l2-dev.c |   31 ---
 linux/include/media/v4l2-dev.h   |5 ++---
 2 files changed, 18 insertions(+), 18 deletions(-)

--- master.orig/linux/drivers/media/video/v4l2-dev.c
+++ master/linux/drivers/media/video/v4l2-dev.c
@@ -384,23 +384,18 @@ static int get_index(struct video_device
return i == VIDEO_NUM_DEVICES ? -ENFILE : i;
 }
 
-int video_register_device(struct video_device *vdev, int type, int nr)
-{
-   return video_register_device_index(vdev, type, nr, -1);
-}
-EXPORT_SYMBOL(video_register_device);
 
 /**
- * video_register_device_index - register video4linux devices
+ * video_register_device - register video4linux devices
  * @vdev: video device structure we want to register
  * @type: type of device to register
  * @nr:   which device number (0 == /dev/video0, 1 == /dev/video1, ...
  * -1 == first free)
- * @index: stream number based on parent device;
- * -1 if auto assign, requested number otherwise
  *
  * The registration code assigns minor numbers based on the type
- * requested. -ENFILE is returned in all the device slots for this
+ * requested. If the requested one is already used, get the next
+ * available one and prints a warning.
+ * -ENFILE is returned in all the device slots for this
  * category are full. If not then the minor field is set and the
  * driver initialize function is called (if non %NULL).
  *
@@ -416,10 +411,10 @@ EXPORT_SYMBOL(video_register_device);
  *
  * %VFL_TYPE_RADIO - A radio card
  */
-int video_register_device_index(struct video_device *vdev, int type, int nr,
-   int index)
+int video_register_device(struct video_device *vdev, const int type,
+ const int desirednr)
 {
-   int i = 0;
+   int i = 0, nr;
int ret;
int minor_offset = 0;
int minor_cnt = VIDEO_NUM_DEVICES;
@@ -493,7 +488,8 @@ int video_register_device_index(struct v
 
/* Pick a minor number */
mutex_lock(videodev_lock);
-   nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr);
+   nr = 

Re: RFC: remove video_register_device_index, add video_register_device_range

2009-06-15 Thread Hans Verkuil
On Monday 15 June 2009 15:44:21 Mauro Carvalho Chehab wrote:
 Em Mon, 15 Jun 2009 13:25:28 +0200
 Hans Verkuil hverk...@xs4all.nl escreveu:
 
  Hi all,
  
  While looking at the video_register_device changes that broke ov511 I 
  realized
  that the video_register_device_index function is never called from drivers. 
  It
  will always assign a default index number. I also don't see a good use-case
  for giving it an explicit index. My proposal is to remove this API. Since it
  is never called, nothing will change effectively. I'm never happy with 
  unused
  functions.
 
 It sounds ok to me.
 
  However, I think we do need a new video_register_device_range function. This
  would be identical to video_register_device, but with an additional count
  argument: this allows drivers to select a kernel number in the range of
  nr to nr + count - 1. If cnt == -1, then the maximum is the compiled-in
  maximum.
  
  So video_register_device would call video_register_device_range(...nr, 1),
  thus restoring the original behavior, while ivtv and cx18 can call
  video_register_device_range(...nr, -1), thus keeping the current behavior.
 
 I don't think that this is needed. The issue with ov511 is that it was using
 the error condition of video_register to identify how much ov511 devices were
 already registered.
 
 I already fixed it by adding an explicit device number count on it, just like
 all the other drivers. With this, ov511 will behave like the other drivers.
 
 With the current implementation, it should honor the explicit minor order
 passed via modprobe parameter, as before.
 
 There's one small change on the behavior that it is also present on all other
 devices that allow users to explicit the desired minor order: instead of
 failing if that device is already used, it will get the next available one.
 IMO, this is better than just failing. So, the only remaining issue is that
 video_register should print a warning if it had to get a different minor than
 specified.

The sticking point for me is that warning since for cx18/ivtv it is OK if you
get something else then you specified (since it is a starting index meant to
distinguish mpeg encoders from raw video inputs, from mpeg decoders, etc.).

So generating a warning for those two drivers is not correct.

Perhaps we should add a V4L2_FL_KNUM_OFFSET flag for the struct video_device
flags field that tell the register function that 'nr' should be interpreted
as a kernel number offset, and not as a preferred number. In the latter case
you generate a warning, in the first case you don't.

I think it isn't a bad idea to use a flag. It reflects the two possible use
cases: one for drivers that create multiple video (or vbi) devices and use the
kernel number to reflect the purpose of each video device, and the other where
the user wants a specific kernel number. In the latter case the driver creates
a single video device.

I don't want to see a lot of kernel warnings each time an ivtv or cx18 driver
is loaded. Those warnings do not apply to those drivers.

BTW: please note that my v4l-dvb-misc tree contains a patch to clean up the
comments/variable names in v4l2-dev.c. You might want to pull that in first.

Regards,

Hans

 
 In other words, the enclosed patch seems to be a good approach to close this
 issue
 
 
 
 Cheers,
 Mauro
 
 ---
 
 v4l2-dev: Print a warning if need to use a different minor than specified
 
 From: Mauro Carvalho Chehab mche...@redhat.com
 
 video_register_device has two behaviors: dynamic minor attribution or 
 forced minor attribution. The latter mode is used to allow users to 
 force probing a device using a certain minor order. Even for the last 
 case, video_register_device won't fail if that minor is already used 
 but, instead, it will seek for the next available minor, without warning 
 users about that.
 
 While don't fail due to a busy minor seems the better behavior, it 
 should be printing a warning when this happen.
 
 While here, let's remove video_register_device_index(), since no driver 
 is using it.
 
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 
 ---
  linux/drivers/media/video/v4l2-dev.c |   31 ---
  linux/include/media/v4l2-dev.h   |5 ++---
  2 files changed, 18 insertions(+), 18 deletions(-)
 
 --- master.orig/linux/drivers/media/video/v4l2-dev.c
 +++ master/linux/drivers/media/video/v4l2-dev.c
 @@ -384,23 +384,18 @@ static int get_index(struct video_device
   return i == VIDEO_NUM_DEVICES ? -ENFILE : i;
  }
  
 -int video_register_device(struct video_device *vdev, int type, int nr)
 -{
 - return video_register_device_index(vdev, type, nr, -1);
 -}
 -EXPORT_SYMBOL(video_register_device);
  
  /**
 - *   video_register_device_index - register video4linux devices
 + *   video_register_device - register video4linux devices
   *   @vdev: video device structure we want to register
   *   @type: type of device to register
   *   @nr:   which device number (0 == 

[PATCH] soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev

2009-06-15 Thread Jonathan Cameron
From: Jonathan Cameron ji...@cam.ac.uk

OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet,
Darius Augulis and Jonathan Cameron

Signed-off-by: Jonathan Cameron ji...@cam.ac.uk
---

This is my first cut at a merge of the various ov7670 drivers to work
with Guennadi Liakhovetski's work on moving soc-camera over to v4l2-subdev
framework.

Thanks to Darius Augulis for many of the register settings, though a few
sets marked as untested in his driver don't seem to work.

I'm not entirely happy with the mapping of various parameters onto
the standard v4l controls and would greatly appreciate any suggestions
about these.

There are still a lot of magic numbers in here but I've tried to identify
the purposes of as many as possible.

At the moment I've deliberately kept it separate in naming etc from the
in tree ov7670 driver as I don't want to go breaking that driver. Is there
anyone out there who has the hardware and would consider doing the relevant
board support code and testing?

All comments welcome.


 drivers/media/video/Kconfig  |6 +
 drivers/media/video/Makefile |1 +
 drivers/media/video/ov7670_soc.c | 1475 ++
 include/media/ov7670_soc.h   |   21 +
 4 files changed, 1503 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9ff760c..4580d7a 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -746,6 +746,12 @@ config SOC_CAMERA_OV772X
help
  This is a ov772x camera driver
 
+config SOC_CAMERA_OV7670_SOC
+   tristate ov7670 soc camera support
+   depends on SOC_CAMERA  I2C
+   help
+ This is an ov7670 soc camera driver
+
 config MX1_VIDEO
bool
 
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 7aefac6..1249326 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -141,6 +141,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111)+= mt9m111.o
 obj-$(CONFIG_SOC_CAMERA_MT9T031)   += mt9t031.o
 obj-$(CONFIG_SOC_CAMERA_MT9V022)   += mt9v022.o
 obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o
+obj-$(CONFIG_SOC_CAMERA_OV7670_SOC)+= ov7670_soc.o
 obj-$(CONFIG_SOC_CAMERA_PLATFORM)  += soc_camera_platform.o
 obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o
 # soc-camera host drivers have to be linked after camera drivers
diff --git a/drivers/media/video/ov7670_soc.c b/drivers/media/video/ov7670_soc.c
new file mode 100644
index 000..5494427
--- /dev/null
+++ b/drivers/media/video/ov7670_soc.c
@@ -0,0 +1,1475 @@
+/*
+ * A V4L2 driver for OmniVision OV7670 cameras via soc interface
+ *
+ * Copyright 2006 One Laptop Per Child Association, Inc.  Written
+ * by Jonathan Corbet with substantial inspiration from Mark
+ * McClelland's ovcamchip code.
+ *
+ * Copyright 2006-7 Jonathan Corbet cor...@lwn.net
+ *
+ * Copyright 2008-9 Jonathan Cameron ji...@cam.ac.uk
+ *
+ * Copyright 2008 Darius Augulis augulis.dar...@gmail.com
+ *
+ * This file may be distributed under the terms of the GNU General
+ * Public License, version 2.
+ *
+ * Todo: Add control for auto saturation control
+ *   Inversion of sync signals etc.
+ *   Driver 2 had a qqvga mode, but register settings don't seem to
+ *   be right so I've removed it.
+ *
+ * Queries for review:
+ * 1) Here I'm using brightness controls for what are effectively shutter
+ * timings.  How should this be done?
+ */
+#include linux/init.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/videodev2.h
+#include media/v4l2-common.h
+#include media/v4l2-chip-ident.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+#include media/soc_camera.h
+#include media/ov7670_soc.h
+
+#define MAX_WIDTH  640
+#define MAX_HEIGHT 480
+
+/* Registers */
+#defineREG_GAIN0x00/* Gain lower 8 bits (rest in vref) */
+#define REG_BLUE   0x01/* blue gain */
+#define REG_RED0x02/* red gain */
+#define REG_VREF   0x03/* Pieces of GAIN, VSTART, VSTOP */
+#define REG_COM1   0x04/* Control 1 */
+#defineCOM1_CCIR656  0x40  /* CCIR656 enable */
+
+#define REG_AECHH  0x07/* AEC MS 5 bits */
+
+#define REG_COM2   0x09/* Control 2 */
+#defineCOM2_SSLEEP   0x10  /* Soft sleep mode */
+#define REG_PID0x0a/* Product ID MSB */
+#define REG_VER0x0b/* Product ID LSB */
+#define REG_COM3   0x0c/* Control 3 */
+#defineCOM3_SWAP 0x40/* Byte swap */
+#defineCOM3_SCALEEN  0x08/* Enable scaling */
+#defineCOM3_DCWEN0x04/* Enable 
downsamp/crop/window */
+#define REG_COM4   0x0d/* Control 4 */
+#define REG_COM5   0x0e/* All reserved */
+#define REG_COM6   0x0f/* Control 6 */
+#define REG_AECH   0x10/* More bits of AEC value */

Re: s5h1411_readreg: readreg error (ret == -5)

2009-06-15 Thread Steven Toth

hermann pitton wrote:

[snip]

The most undiscovered configurations seem to be such ones about antenna
inputs and their switching. Again according to Hartmut, and he did not
know exactly what is going on here, some for us and him at this point
unknown checksums are used to derive even that information :(

For what I can see, and I might be of course still wrong, we can also
not determine plain digital tuner types, digital demodulator types of
any kind and the type of possibly present second and third tuners, but
at least their addresses, regularly shared by multiple chips, become
often visible. (some OEMs have only 0xff still for all that)


forgot, and not any LNB supplies behind some i2c bridges, shared or not
on whatever.


The use of Hauppauge eeproms I consider advisory at best. Yes, they have 
reasonably good fields to identify tuners, IR but a number of recent silicon 
additions (last 3 years) to the product line is not fully implemented in the 
eeproms. Some of the important feature decisions is done purely in software 
based on sub id for example.


In general I agree with Hermann's comments, that is,  where possible making 
maximum use of the eeprom.


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


[RESEND][PATCH] video: Initial support for ADV7180

2009-06-15 Thread Richard Röjfors
This is an initial driver for Analog Devices ADV7180 Video Decoder.

So far it only supports query standard.

Signed-off-by: Richard Röjfors richard.rojfors@mocean-labs.com
---
Index: linux-2.6.30-rc7/drivers/media/video/adv7180.c
===
--- linux-2.6.30-rc7/drivers/media/video/adv7180.c  (revision 0)
+++ linux-2.6.30-rc7/drivers/media/video/adv7180.c  (revision 867)
@@ -0,0 +1,221 @@
+/*
+ * adv7180.c Analog Devices ADV7180 video decoder driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include linux/i2c-id.h
+#include media/v4l2-ioctl.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+
+
+#define ADV7180_INPUT_CONTROL_REG  0x00
+#define ADV7180_INPUT_CONTROL_PAL_BG_NTSC_J_SECAM  0x00
+#define ADV7180_AUTODETECT_ENABLE_REG  0x07
+#define ADV7180_AUTODETECT_DEFAULT 0x7f
+
+
+#define ADV7180_STATUS1_REG 0x10
+#define ADV7180_STATUS1_AUTOD_MASK 0x70
+#define ADV7180_STATUS1_AUTOD_NTSM_M_J 0x00
+#define ADV7180_STATUS1_AUTOD_NTSC_4_43 0x10
+#define ADV7180_STATUS1_AUTOD_PAL_M0x20
+#define ADV7180_STATUS1_AUTOD_PAL_60   0x30
+#define ADV7180_STATUS1_AUTOD_PAL_B_G  0x40
+#define ADV7180_STATUS1_AUTOD_SECAM0x50
+#define ADV7180_STATUS1_AUTOD_PAL_COMB 0x60
+#define ADV7180_STATUS1_AUTOD_SECAM_5250x70
+
+#define ADV7180_IDENT_REG 0x11
+#define ADV7180_ID_7180 0x18
+
+
+static unsigned short normal_i2c[] = { 0x42  1, I2C_CLIENT_END };
+
+I2C_CLIENT_INSMOD;
+
+struct adv7180_state {
+   struct v4l2_subdev sd;
+};
+
+static v4l2_std_id determine_norm(struct i2c_client *client)
+{
+   u8 status1 = i2c_smbus_read_byte_data(client, ADV7180_STATUS1_REG);
+
+   switch (status1  ADV7180_STATUS1_AUTOD_MASK) {
+   case ADV7180_STATUS1_AUTOD_NTSM_M_J:
+   return V4L2_STD_NTSC_M_JP;
+   case ADV7180_STATUS1_AUTOD_NTSC_4_43:
+   return V4L2_STD_NTSC_443;
+   case ADV7180_STATUS1_AUTOD_PAL_M:
+   return V4L2_STD_PAL_M;
+   case ADV7180_STATUS1_AUTOD_PAL_60:
+   return V4L2_STD_PAL_60;
+   case ADV7180_STATUS1_AUTOD_PAL_B_G:
+   return V4L2_STD_PAL;
+   case ADV7180_STATUS1_AUTOD_SECAM:
+   return V4L2_STD_SECAM;
+   case ADV7180_STATUS1_AUTOD_PAL_COMB:
+   return V4L2_STD_PAL_Nc | V4L2_STD_PAL_N;
+   case ADV7180_STATUS1_AUTOD_SECAM_525:
+   return V4L2_STD_SECAM;
+   default:
+   return V4L2_STD_UNKNOWN;
+   }
+}
+
+static inline struct adv7180_state *to_state(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct adv7180_state, sd);
+}
+
+static int adv7180_querystd(struct v4l2_subdev *sd, v4l2_std_id *std)
+{
+   struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+   *(v4l2_std_id *)std = determine_norm(client);
+   return 0;
+}
+
+static int adv7180_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
+{
+   return -EINVAL;
+}
+
+static int adv7180_s_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
+{
+   return -EINVAL;
+}
+
+static int adv7180_g_chip_ident(struct v4l2_subdev *sd,
+   struct v4l2_dbg_chip_ident *chip)
+{
+   struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+   return v4l2_chip_ident_i2c_client(client, chip, V4L2_IDENT_ADV7180, 0);
+}
+
+static int adv7180_log_status(struct v4l2_subdev *sd)
+{
+   v4l2_info(sd, Normal operation\n);
+   return 0;
+}
+
+static irqreturn_t adv7180_irq(int irq, void *devid)
+{
+   return IRQ_NONE;
+}
+
+static const struct v4l2_subdev_video_ops adv7180_video_ops = {
+   .querystd = adv7180_querystd,
+};
+
+static const struct v4l2_subdev_core_ops adv7180_core_ops = {
+   .log_status = adv7180_log_status,
+   .g_chip_ident = adv7180_g_chip_ident,
+   .g_ctrl = adv7180_g_ctrl,
+   .s_ctrl = adv7180_s_ctrl,
+};
+
+static const struct v4l2_subdev_ops adv7180_ops = {
+   .core = adv7180_core_ops,
+   .video = adv7180_video_ops,
+};
+
+/*
+ * Generic i2c probe
+ * concerning the addresses: i2c wants 7 bit (without the r/w bit), so '1'
+ */
+
+static int 

Re: [PULL] http://linuxtv.org/hg/~dougsland/em28xx/

2009-06-15 Thread Franklin Meng

Just wanted to thank Douglas Landgraf for the help he provided me with getting 
the em28xx driver working with the Kworld 315U tuner device (digital only at 
this time).  As time permits, I hope to get the analog inputs and tuner to work 
too (if anyone want to help please let me know). 

Thanks,
Franklin Meng

--- On Sat, 6/6/09, Douglas Schilling Landgraf dougsl...@gmail.com wrote:

 From: Douglas Schilling Landgraf dougsl...@gmail.com
 Subject: [PULL] http://linuxtv.org/hg/~dougsland/em28xx/
 To: linux-media@vger.kernel.org
 Cc: Mauro Carvalho Chehab mche...@infradead.org, fmeng2...@yahoo.com
 Date: Saturday, June 6, 2009, 1:11 PM
 Hello Mauro,
 
    Please pull from http://www.linuxtv.org/hg/~dougsland/em28xx for
 the following:
 
    - em28xx: Add Kworld 315 entry
    - em28xx: set up tda9887_conf in
 em28xx_card_setup()
 
 Thanks,
 Douglas
 


  
--
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 RFC] adding support for setting bus parameters in sub device

2009-06-15 Thread Karicheri, Muralidharan
 +
 +struct v4l2_subdev_bus {
 +       enum v4l2_subdev_bus_type type;
 +       u8 width;
 +       /* 0 - active low, 1 - active high */
 +       unsigned pol_vsync:1;
 +       /* 0 - active low, 1 - active high */
 +       unsigned pol_hsync:1;
 +       /* 0 - low to high , 1 - high to low */
 +       unsigned pol_field:1;
 +       /* 0 - sample at falling edge , 1 - sample at rising edge */
 +       unsigned pol_pclock:1;
 +       /* 0 - active low , 1 - active high */
 +       unsigned pol_data:1;
 +};

As for the pins/signals, I wonder if per-signal polarity/edge is
enough. If this is going to be used by/replace the soc_camera
interface then we also need to know if the signal is present or not.
For instance, I have a SuperH board using my CEU driver together with
one OV7725 camera or one TW9910 video decoder. Some revisions of the
board do not route the field signal between the SuperH on-chip CEU and
the TW9910. Both the CEU and the TW9910 support this signal, it just
happen to be missing. 

[MK]In that case can't the driver just ignore the field polarity? I assume that 
drivers implement the parameter that has support in hardware. So it is not an 
issue.

I think we need a way to include this board
specific property somehow.


/ magnus

--
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] zr364xx.c: vfree does its own NULL check

2009-06-15 Thread Figo.zhang
hi Mauro,
is it ok for this patch?

Best Regards,

Figo.zhang


On Sat, 2009-06-06 at 17:16 +0800, Figo.zhang wrote:
 vfree() does it's own NULL checking, no need for explicit check before
 calling it.
 
 Signed-off-by: Figo.zhang figo1...@gmail.com
 --- 
  drivers/media/video/zr364xx.c |6 --
  1 files changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/video/zr364xx.c b/drivers/media/video/zr364xx.c
 index ac169c9..fc976f4 100644
 --- a/drivers/media/video/zr364xx.c
 +++ b/drivers/media/video/zr364xx.c
 @@ -882,9 +882,11 @@ static void zr364xx_disconnect(struct usb_interface 
 *intf)
   video_unregister_device(cam-vdev);
   cam-vdev = NULL;
   kfree(cam-buffer);
 - if (cam-framebuf)
 - vfree(cam-framebuf);
 + cam-buffer = NULL;
 + vfree(cam-framebuf);
 + cam-framebuf = NULL;
   kfree(cam);
 + cam = NULL;
  }
  
 
 
 
 
 
 
 

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


[PATCH] soc_camera: Fix debug output of supported formats count

2009-06-15 Thread Stefan Herbrechtsmeier
The supported formats count must be set to 0 after debug output
right before the second pass.

Signed-off-by: Stefan Herbrechtsmeier hbme...@hni.uni-paderborn.de

diff --git a/linux/drivers/media/video/soc_camera.c 
b/linux/drivers/media/video/soc_camera.c
--- a/linux/drivers/media/video/soc_camera.c
+++ b/linux/drivers/media/video/soc_camera.c
@@ -238,11 +238,11 @@ static int soc_camera_init_user_formats(
return -ENOMEM;
 
icd-num_user_formats = fmts;
-   fmts = 0;
 
dev_dbg(icd-dev, Found %d supported formats.\n, fmts);
 
/* Second pass - actually fill data formats */
+   fmts = 0;
for (i = 0; i  icd-num_formats; i++)
if (!ici-ops-get_formats) {
icd-user_formats[i].host_fmt = icd-formats + i;
--
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: Did I miss any other patches or RFCs that need to be reviewed?

2009-06-15 Thread Karicheri, Muralidharan
Hans,

Thanks for your review. I will get back to you if I need more
information on your comments.

You have reviewed the following patches in this series...
1,7,8,10

Following are part of this series which requires review as well.

[PATCH 2/10 - v2] ccdc hw device header file for vpfe capture
[PATCH 3/10 - v2] dm355 ccdc module for vpfe capture driver
[PATCH 4/10 - v2] dm644x ccdc module for vpfe capture driver
[PATCH 5/10 - v2] ccdc types used across ccdc modules for vpfe capture driver

(not much to review in the below patch )

PATCH 6/10 - v2] Makefile and config files for vpfe capture driver 

regards,

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com

-Original Message-
From: davinci-linux-open-source-bounces+m-
karicheri2=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-
bounces+m-karicheri2=ti@linux.davincidsp.com] On Behalf Of Hans Verkuil
Sent: Sunday, June 14, 2009 10:37 AM
To: linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-
o...@vger.kernel.org
Subject: Did I miss any other patches or RFCs that need to be reviewed?

Hi all,

I think I've finally finished reviewing all the pending patches.

Are there any that I've missed? Or are there other postings that need my
attention?

Please let me know, otherwise I assume that I'm (finally!) up to date.

Regards,

   Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


RE: [PATCH 1/10 - v2] vpfe capture bridge driver for DM355 and DM6446

2009-06-15 Thread Karicheri, Muralidharan
 +       /* set the default image parameters in the device */
 +       ret = vpfe_config_image_format(vpfe_dev,
 +                               vpfe_standards[vpfe_dev-
std_index].std_id);
 +       if (ret)
 +               goto unlock_out;

Why you check ret value and go to label below?
Probably you can remove if-check and goto here.

Ok.
 +
 +unlock_out:
 +       mutex_unlock(vpfe_dev-lock);
;

return -EIO?

Ok.
--
Best regards, Klimov Alexey

--
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 10/10 - v2] common vpss module for video drivers

2009-06-15 Thread Karicheri, Muralidharan

=
dm644x_clear_wbl_overflow;
 +       else
 +               return -ENODEV;

Do you need clean up procedure if you return error here? I mean -
calls to release_mem_region, release_mem_region, etc

Oops! I need to add that. Thanks.
 +       spin_lock_init(oper_cfg.vpss_lock);
 +       dev_info(pdev-dev, %s vpss probe success\n,
oper_cfg.vpss_name);
 +       return 0;
 +fail3:
 +       release_mem_region(oper_cfg.r2-start, oper_cfg.len2);
 +fail2:
 +       iounmap(oper_cfg.vpss_bl_regs_base);
 +fail1:
 +       release_mem_region(oper_cfg.r1-start, oper_cfg.len1);
 +       return status;
 +}


--
Best regards, Klimov Alexey

--
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: Did I miss any other patches or RFCs that need to be reviewed?

2009-06-15 Thread Hans Verkuil
On Monday 15 June 2009 18:24:53 Karicheri, Muralidharan wrote:
 Hans,
 
 Thanks for your review. I will get back to you if I need more
 information on your comments.
 
 You have reviewed the following patches in this series...
 1,7,8,10

Those were the only ones I had any comments on. So I'm happy with the
others.

Regards,

Hans

 
 Following are part of this series which requires review as well.
 
 [PATCH 2/10 - v2] ccdc hw device header file for vpfe capture
 [PATCH 3/10 - v2] dm355 ccdc module for vpfe capture driver
 [PATCH 4/10 - v2] dm644x ccdc module for vpfe capture driver
 [PATCH 5/10 - v2] ccdc types used across ccdc modules for vpfe capture driver
 
 (not much to review in the below patch )
 
 PATCH 6/10 - v2] Makefile and config files for vpfe capture driver 
 
 regards,
 
 Murali Karicheri
 Software Design Engineer
 Texas Instruments Inc.
 Germantown, MD 20874
 email: m-kariche...@ti.com
 
 -Original Message-
 From: davinci-linux-open-source-bounces+m-
 karicheri2=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-
 bounces+m-karicheri2=ti@linux.davincidsp.com] On Behalf Of Hans Verkuil
 Sent: Sunday, June 14, 2009 10:37 AM
 To: linux-media@vger.kernel.org
 Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-
 o...@vger.kernel.org
 Subject: Did I miss any other patches or RFCs that need to be reviewed?
 
 Hi all,
 
 I think I've finally finished reviewing all the pending patches.
 
 Are there any that I've missed? Or are there other postings that need my
 attention?
 
 Please let me know, otherwise I assume that I'm (finally!) up to date.
 
 Regards,
 
  Hans
 
 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
 
 ___
 Davinci-linux-open-source mailing list
 davinci-linux-open-sou...@linux.davincidsp.com
 http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
 {.n�+���+%�ݶ��w��{.n�+{��g��^n�r���z���hz��z�ޗ�+��+zf���h���~i�z_���j:+v���)ߣ�m
 
 
 



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


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

2009-06-15 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:Mon Jun 15 19:00:04 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   11975:144d8d0cebc5
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: OK
linux-2.6.23.12-armv5: OK
linux-2.6.24.7-armv5: OK
linux-2.6.25.11-armv5: OK
linux-2.6.26-armv5: OK
linux-2.6.27-armv5: WARNINGS
linux-2.6.28-armv5: WARNINGS
linux-2.6.29.1-armv5: OK
linux-2.6.30-armv5: OK
linux-2.6.27-armv5-ixp: WARNINGS
linux-2.6.28-armv5-ixp: WARNINGS
linux-2.6.29.1-armv5-ixp: WARNINGS
linux-2.6.30-armv5-ixp: WARNINGS
linux-2.6.28-armv5-omap2: WARNINGS
linux-2.6.29.1-armv5-omap2: WARNINGS
linux-2.6.30-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: OK
linux-2.6.23.12-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.11-i686: WARNINGS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: WARNINGS
linux-2.6.28-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: WARNINGS
linux-2.6.23.12-m32r: OK
linux-2.6.24.7-m32r: OK
linux-2.6.25.11-m32r: OK
linux-2.6.26-m32r: OK
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29.1-m32r: OK
linux-2.6.30-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.27-powerpc64: WARNINGS
linux-2.6.28-powerpc64: WARNINGS
linux-2.6.29.1-powerpc64: WARNINGS
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: OK
linux-2.6.23.12-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.11-x86_64: OK
linux-2.6.26-x86_64: OK
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: OK
linux-2.6.30-x86_64: WARNINGS
sparse (linux-2.6.30): OK
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: OK
linux-2.6.20.21-i686: OK
linux-2.6.21.7-i686: OK
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: OK
linux-2.6.20.21-x86_64: OK
linux-2.6.21.7-x86_64: OK

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

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

The V4L2 specification failed to build, but the last compiled spec is here:

http://www.xs4all.nl/~hverkuil/spec/v4l2.html

The DVB API specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf

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


RE: Did I miss any other patches or RFCs that need to be reviewed?

2009-06-15 Thread Karicheri, Muralidharan
Hans,

That is great!

Once I change the code based on the comments, do you think there is a chance to 
get the driver to be merged to 2.6.31 (If so, how soon should I be ready with 
the next version, v3 of the patch) or do we need to wait until 2.6.32?

Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com

-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, June 15, 2009 1:56 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com; linux-o...@vger.kernel.org
Subject: Re: Did I miss any other patches or RFCs that need to be reviewed?

On Monday 15 June 2009 18:24:53 Karicheri, Muralidharan wrote:
 Hans,

 Thanks for your review. I will get back to you if I need more
 information on your comments.

 You have reviewed the following patches in this series...
 1,7,8,10

Those were the only ones I had any comments on. So I'm happy with the
others.

Regards,

   Hans


 Following are part of this series which requires review as well.

 [PATCH 2/10 - v2] ccdc hw device header file for vpfe capture
 [PATCH 3/10 - v2] dm355 ccdc module for vpfe capture driver
 [PATCH 4/10 - v2] dm644x ccdc module for vpfe capture driver
 [PATCH 5/10 - v2] ccdc types used across ccdc modules for vpfe capture
driver

 (not much to review in the below patch )

 PATCH 6/10 - v2] Makefile and config files for vpfe capture driver

 regards,

 Murali Karicheri
 Software Design Engineer
 Texas Instruments Inc.
 Germantown, MD 20874
 email: m-kariche...@ti.com

 -Original Message-
 From: davinci-linux-open-source-bounces+m-
 karicheri2=ti@linux.davincidsp.com [mailto:davinci-linux-open-
source-
 bounces+m-karicheri2=ti@linux.davincidsp.com] On Behalf Of Hans
Verkuil
 Sent: Sunday, June 14, 2009 10:37 AM
 To: linux-media@vger.kernel.org
 Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-
 o...@vger.kernel.org
 Subject: Did I miss any other patches or RFCs that need to be reviewed?
 
 Hi all,
 
 I think I've finally finished reviewing all the pending patches.
 
 Are there any that I've missed? Or are there other postings that need my
 attention?
 
 Please let me know, otherwise I assume that I'm (finally!) up to date.
 
 Regards,
 
 Hans
 
 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
 
 ___
 Davinci-linux-open-source mailing list
 davinci-linux-open-sou...@linux.davincidsp.com
 http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

���{.n�+���+%�ݶ��w��{.n�+{��g�^n�r���z���h���z��z�ޗ�
+��+zf���h���~iz_��j:+v���)ߣ�m






--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom



Re: [PATCH] zl10353 and qt1010: fix stack corruption bug

2009-06-15 Thread Antti Palosaari

Hei Jan,

On 06/10/2009 09:21 AM, Jan Nikitenko wrote:

This patch fixes stack corruption bug present in dump_regs function of
zl10353 and qt1010 drivers:
the buffer buf is one byte smaller than required - there is 4 chars
for address prefix, 16*3 chars for dump of 16 eeprom bytes per line
and 1 byte for zero ending the string required, i.e. 53 bytes, but
only 52 were provided.
The one byte missing in stack based buffer buf can cause stack
corruption possibly leading to kernel oops, as discovered originally
with af9015 driver.

Signed-off-by: Jan Nikitenko jan.nikite...@gmail.com

---

Antti Palosaari wrote:
  On 06/10/2009 01:39 AM, Jan Nikitenko wrote:
  Solved with [PATCH] af9015: fix stack corruption bug.
 
  This error leads to the zl10353.c and there it was copied to qt1010.c
  and af9015.c.
 
Antti, thanks for pointing out that the same problem was also in
zl10353.c and qt1010.c. Include your Sign-off-by, please.


I tried to test that patch (from patchwork) to ensure it is OK before 
ack, but I found it does not apply for reason or other. It looks correct 
for my eyes. Please check what's wrong and apply new patch.


[cr...@localhost v4l-dvb]$ patch -p1  
af9015-fix-stack-corruption-bug.patch

patching file linux/drivers/media/dvb/dvb-usb/af9015.c
[cr...@localhost v4l-dvb]$ patch -p1  
zl10353-and-qt1010-fix-stack-corruption-bug.patch

patching file linux/drivers/media/common/tuners/qt1010.c
Hunk #1 FAILED at 65.
1 out of 1 hunk FAILED -- saving rejects to file 
linux/drivers/media/common/tuners/qt1010.c.rej

patching file linux/drivers/media/dvb/frontends/zl10353.c
Hunk #1 FAILED at 102.
1 out of 1 hunk FAILED -- saving rejects to file 
linux/drivers/media/dvb/frontends/zl10353.c.rej

[cr...@localhost v4l-dvb]$ hg diff
diff -r 148b4c93a728 linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c	Mon Jun 15 14:15:33 2009 
-0300
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c	Mon Jun 15 21:55:55 2009 
+0300

@@ -541,7 +541,7 @@
 /* dump eeprom */
 static int af9015_eeprom_dump(struct dvb_usb_device *d)
 {
-   char buf[52], buf2[4];
+   char buf[4+3*16+1], buf2[4];
u8 reg, val;

for (reg = 0; ; reg++) {
[cr...@localhost v4l-dvb]$ hg head
changeset:   11978:148b4c93a728
tag: tip
parent:  11975:144d8d0cebc5
parent:  11977:8b416ba3ac89
user:Mauro Carvalho Chehab mche...@redhat.com
date:Mon Jun 15 14:15:33 2009 -0300
summary: merge: http://www.linuxtv.org/hg/~dougsland/em28xx

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


Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc

2009-06-15 Thread Mauro Carvalho Chehab
Hi Hans,

Em Mon, 15 Jun 2009 13:27:42 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:

 On Sunday 14 June 2009 12:15:34 Hans Verkuil wrote:
  On Sunday 14 June 2009 11:50:51 Hans Verkuil wrote:
   Hi Mauro,
   
   Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the 
   following:
   
   - ivtv/cx18: fix regression: class controls are no longer seen
   - v4l2-ctl: add modulator get/set options.
   - v4l2-spec: update VIDIOC_G/S_MODULATOR section.
   - compat: fix __fls check for the arm architecture.
   - smscoreapi: fix compile warning
   
   The first one is a high prio bug as it is a 2.6.30 regression. Mike, once 
   this is merged in the git tree this one can be queued for the 2.6.30 
   stable 
   series.
   
   The other changes are small stuff.
  
  Added one more minor change:
  
  - v4l2-i2c-drv.h: add comment describing when not to use this header.

The above patches seem ok.

 
 And added this one as well:
 
 - v4l2-dev: fix some confusing variable names and comments
 
 # HG changeset patch
 # User Hans Verkuil hverk...@xs4all.nl
 # Date 1245063581 -7200
 # Node ID 083bb5ad197e4c49430de2b26f3115743fe5cc27
 # Parent 743225159afab6d79a0d6095bc302f9922305c33
 v4l2-dev: fix some confusing variable names and comments
 
 From: Hans Verkuil hverk...@xs4all.nl
 
 Some variable names and comments were rather misleading when it came
 to the distinction between kernel numbers and minor numbers. This should
 clarify things.
 
 Priority: normal
 
 Signed-off-by: Hans Verkuil hverk...@xs4all.nl
 
 --- a/linux/drivers/media/video/v4l2-dev.cSun Jun 14 12:12:11 2009 +0200
 +++ b/linux/drivers/media/video/v4l2-dev.cMon Jun 15 12:59:41 2009 +0200
 @@ -419,10 +419,10 @@ int video_register_device_index(struct v
  int video_register_device_index(struct video_device *vdev, int type, int nr,
   int index)
  {
 - int i = 0;
 + int minor;
   int ret;
   int minor_offset = 0;
 - int minor_cnt = VIDEO_NUM_DEVICES;
 + int kernel_nrs = VIDEO_NUM_DEVICES;
   const char *name_base;
   void *priv = video_get_drvdata(vdev);
  
 @@ -470,52 +470,52 @@ int video_register_device_index(struct v
   switch (type) {
   case VFL_TYPE_GRABBER:
   minor_offset = 0;
 - minor_cnt = 64;
 + kernel_nrs = 64;
   break;
   case VFL_TYPE_RADIO:
   minor_offset = 64;
 - minor_cnt = 64;
 + kernel_nrs = 64;
   break;
   case VFL_TYPE_VTX:
   minor_offset = 192;
 - minor_cnt = 32;
 + kernel_nrs = 32;
   break;
   case VFL_TYPE_VBI:
   minor_offset = 224;
 - minor_cnt = 32;
 + kernel_nrs = 32;
   break;
   default:
   minor_offset = 128;
 - minor_cnt = 64;
 - break;
 - }
 -#endif
 -
 - /* Pick a minor number */
 + kernel_nrs = 64;
 + break;
 + }
 +#endif
 +
 + /* Pick a kernel number */
   mutex_lock(videodev_lock);
 - nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr);
 - if (nr == minor_cnt)
 - nr = find_first_zero_bit(video_nums[type], minor_cnt);
 - if (nr == minor_cnt) {
 + nr = find_next_zero_bit(video_nums[type], kernel_nrs, nr == -1 ? 0 : 
 nr);
 + if (nr == kernel_nrs)
 + nr = find_first_zero_bit(video_nums[type], kernel_nrs);
 + if (nr == kernel_nrs) {
   printk(KERN_ERR could not get a free kernel number\n);
   mutex_unlock(videodev_lock);
   return -ENFILE;
   }
  #ifdef CONFIG_VIDEO_FIXED_MINOR_RANGES
   /* 1-on-1 mapping of kernel number to minor number */
 - i = nr;
 + minor = nr;
  #else
   /* The kernel number and minor numbers are independent */
 - for (i = 0; i  VIDEO_NUM_DEVICES; i++)
 - if (video_device[i] == NULL)
 + for (minor = 0; minor  VIDEO_NUM_DEVICES; minor++)
 + if (video_device[minor] == NULL)
   break;
 - if (i == VIDEO_NUM_DEVICES) {
 + if (minor == VIDEO_NUM_DEVICES) {
   mutex_unlock(videodev_lock);
   printk(KERN_ERR could not get a free minor\n);
   return -ENFILE;
   }
  #endif
 - vdev-minor = i + minor_offset;
 + vdev-minor = minor + minor_offset;
   vdev-num = nr;
   set_bit(nr, video_nums[type]);
   /* Should not happen since we thought this minor was free */
 

The progressive changes at video_register_device() created a mess on this
function, that reflected on ov511 driver, but it is also present on the others.

By looking on this patch, it is obfuscating the function even more. Creating 
more
confusion on it, due to some reasons:

1) The name kernel number doesn't seem much appropriate. Any number used in
kernel can be called as a kernel number.

2) minor and major devices are 

Re: RFC: remove video_register_device_index, add video_register_device_range

2009-06-15 Thread Mauro Carvalho Chehab
Em Mon, 15 Jun 2009 16:02:40 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:


 The sticking point for me is that warning since for cx18/ivtv it is OK if you
 get something else then you specified (since it is a starting index meant to
 distinguish mpeg encoders from raw video inputs, from mpeg decoders, etc.).
 
 So generating a warning for those two drivers is not correct.
Ok.

 Perhaps we should add a V4L2_FL_KNUM_OFFSET flag for the struct video_device
 flags field that tell the register function that 'nr' should be interpreted
 as a kernel number offset, and not as a preferred number. In the latter case
 you generate a warning, in the first case you don't.

Hmm... V4L2_FL_KNUM_OFFSET seems a too obfuscated name. Also, such flag would
be needed by just the register function, so, IMO, a parameter would work better.

Also, am I wrong or is there anything wrong with the flags?

The only place I'm seeing this being used is here:

$ grep 'vdev-flags' v4l/*.[ch]
v4l/v4l2-dev.c: set_bit(V4L2_FL_UNREGISTERED, vdev-flags);

It is being set, but no code seems to actually test for it. So, IMO, we can
just remove this field.

One alternative would be to implement it as something like:

+int __must_check __video_register_device(struct video_device *vdev,
+  const int type, const int nr, int 
warn_if_skip);

#define video_register_device(vdev, type, nr) __video_register_device(vdev, 
type, nr, 0)

 
 I think it isn't a bad idea to use a flag. It reflects the two possible use
 cases: one for drivers that create multiple video (or vbi) devices and use the
 kernel number to reflect the purpose of each video device, and the other where
 the user wants a specific kernel number. In the latter case the driver creates
 a single video device.
 
 I don't want to see a lot of kernel warnings each time an ivtv or cx18 driver
 is loaded. Those warnings do not apply to those drivers.
 
 BTW: please note that my v4l-dvb-misc tree contains a patch to clean up the
 comments/variable names in v4l2-dev.c. You might want to pull that in first.

Please see my comments for your v4l-dvb-misc tree pull request. Let's first
work on that changeset, and then we can discuss better about the warning issue.

 Regards,
 
   Han



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


TT-S1500 budget-ci registeration

2009-06-15 Thread Thomas Kernen


Hello to all,

I'm currently testing a TT-S1500 budget card with the TT budget CI 
adapter with vl4 tree and kernel 2.6.28.


When I modprobe budget_ci, the CI adapter seems to be detected but not 
registered in /dev/dvb/adapter3/ca0 as I would have expected it to be.


Instead I see the following output:

[  148.664846] input: Budget-CI dvb ir receiver saa7146 (0) as 
/devices/pci:00/:00:1e.0/:11:09.0/input/input5


Any suggestions/ideas what the cause may be and how I can attempt to 
solve this?


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


Re: GPL code for Omnivision USB video camera available.

2009-06-15 Thread Hans de Goede



On 06/15/2009 03:01 AM, Erik de Castro Lopo wrote:

On Sat, 13 Jun 2009 18:12:10 +1000
Hans de Goedehdego...@redhat.com  wrote:


Getting ovfx2 support into the mainline kernel sounds like a good idea!

I'm not such a big fan of merging the driver as is though, as it does
its own buffer management (and ioctl handling, usb interrupt handling,
locking, etc).


I understand completely.



Good!


For adding the ovfx2 driver, you could start by copying ov519.c, which
already has setup and control code fro most ov sensors and then rewrite
the bridge part to be ovfx2 code, then later we can try to move the
sensor code to a shared c file for the ov519 and ovfx2 driver, depending
on how much you needed to change the sensor code. Or you could add
support for the ovfx2 to the ov519 driver.

Note I've recently being doing quite a bit of work on the ov519 driver,
adding support for the ov511 and ov518 and adding more controls. I'll
make a mercurial tree available with my latest code in it asap.


Ok, there's the rub. I am simply way too busy at the moment to push this
through myself.

I was hoping I could contract someone to take the existing code and
massage it into shape ready for merging. I would prefer it if that
someone was already a V4L hacker, but if I can't find anyone with
pre-existing V4L experience I'll find someone local with general
Linux kernel/driver experience.



Well I can't offer you contracting, as I simply do not have the spare time
to make such promises, but as any good hacker: will work for hardware
on a I'll do my best but no promises made basis.

I'm actually spending quite a bit of time lately on v4l stuff again,
and I'm sure willing to spend some time on this. I can even promise you
I'll bump it to the top of the list of my v4l projects.

For a general idea how deep I'm involved in v4l webcam support see:
https://fedoraproject.org/wiki/Features/BetterWebcamSupport

Regards,

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


Re: RFC: remove video_register_device_index, add video_register_device_range

2009-06-15 Thread Hans Verkuil
On Monday 15 June 2009 21:51:13 Mauro Carvalho Chehab wrote:
 Em Mon, 15 Jun 2009 16:02:40 +0200
 Hans Verkuil hverk...@xs4all.nl escreveu:
 
 
  The sticking point for me is that warning since for cx18/ivtv it is OK if 
  you
  get something else then you specified (since it is a starting index meant to
  distinguish mpeg encoders from raw video inputs, from mpeg decoders, etc.).
  
  So generating a warning for those two drivers is not correct.
 Ok.
 
  Perhaps we should add a V4L2_FL_KNUM_OFFSET flag for the struct video_device
  flags field that tell the register function that 'nr' should be interpreted
  as a kernel number offset, and not as a preferred number. In the latter case
  you generate a warning, in the first case you don't.
 
 Hmm... V4L2_FL_KNUM_OFFSET seems a too obfuscated name. Also, such flag would
 be needed by just the register function, so, IMO, a parameter would work 
 better.

That was the idea with the video_register_device_range() proposal. I don't want
to modify all existing video_register_device() calls.

 Also, am I wrong or is there anything wrong with the flags?
 
 The only place I'm seeing this being used is here:
 
 $ grep 'vdev-flags' v4l/*.[ch]
 v4l/v4l2-dev.c: set_bit(V4L2_FL_UNREGISTERED, vdev-flags);
 
 It is being set, but no code seems to actually test for it. So, IMO, we can
 just remove this field.

No, it is used a lot through the video_is_unregistered() inline in
media/v4l2-dev.h.

 
 One alternative would be to implement it as something like:
 
 +int __must_check __video_register_device(struct video_device *vdev,
 +  const int type, const int nr, int 
 warn_if_skip);
 
 #define video_register_device(vdev, type, nr) __video_register_device(vdev, 
 type, nr, 0)

Hmm, that's an option. Although I'd make it a static inline:

static inline int __must_check video_register_device(...)
{
return __video_register_device(vdev, type, nr, 1);
}

Regards,

Hans

 
  
  I think it isn't a bad idea to use a flag. It reflects the two possible use
  cases: one for drivers that create multiple video (or vbi) devices and use 
  the
  kernel number to reflect the purpose of each video device, and the other 
  where
  the user wants a specific kernel number. In the latter case the driver 
  creates
  a single video device.
  
  I don't want to see a lot of kernel warnings each time an ivtv or cx18 
  driver
  is loaded. Those warnings do not apply to those drivers.
  
  BTW: please note that my v4l-dvb-misc tree contains a patch to clean up the
  comments/variable names in v4l2-dev.c. You might want to pull that in first.
 
 Please see my comments for your v4l-dvb-misc tree pull request. Let's first
 work on that changeset, and then we can discuss better about the warning 
 issue.
 
  Regards,
  
  Han
 
 
 
 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
 
 



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


Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc

2009-06-15 Thread Hans Verkuil
On Monday 15 June 2009 21:48:32 Mauro Carvalho Chehab wrote:
 Hi Hans,
 
 Em Mon, 15 Jun 2009 13:27:42 +0200
 Hans Verkuil hverk...@xs4all.nl escreveu:
 
  On Sunday 14 June 2009 12:15:34 Hans Verkuil wrote:
   On Sunday 14 June 2009 11:50:51 Hans Verkuil wrote:
Hi Mauro,

Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for 
the 
following:

- ivtv/cx18: fix regression: class controls are no longer seen
- v4l2-ctl: add modulator get/set options.
- v4l2-spec: update VIDIOC_G/S_MODULATOR section.
- compat: fix __fls check for the arm architecture.
- smscoreapi: fix compile warning

The first one is a high prio bug as it is a 2.6.30 regression. Mike, 
once 
this is merged in the git tree this one can be queued for the 2.6.30 
stable 
series.

The other changes are small stuff.
   
   Added one more minor change:
   
   - v4l2-i2c-drv.h: add comment describing when not to use this header.
 
 The above patches seem ok.
 
  
  And added this one as well:
  
  - v4l2-dev: fix some confusing variable names and comments
  
  # HG changeset patch
  # User Hans Verkuil hverk...@xs4all.nl
  # Date 1245063581 -7200
  # Node ID 083bb5ad197e4c49430de2b26f3115743fe5cc27
  # Parent 743225159afab6d79a0d6095bc302f9922305c33
  v4l2-dev: fix some confusing variable names and comments
  
  From: Hans Verkuil hverk...@xs4all.nl
  
  Some variable names and comments were rather misleading when it came
  to the distinction between kernel numbers and minor numbers. This should
  clarify things.
  
  Priority: normal
  
  Signed-off-by: Hans Verkuil hverk...@xs4all.nl
  
  --- a/linux/drivers/media/video/v4l2-dev.c  Sun Jun 14 12:12:11 2009 +0200
  +++ b/linux/drivers/media/video/v4l2-dev.c  Mon Jun 15 12:59:41 2009 +0200
  @@ -419,10 +419,10 @@ int video_register_device_index(struct v
   int video_register_device_index(struct video_device *vdev, int type, int 
  nr,
  int index)
   {
  -   int i = 0;
  +   int minor;
  int ret;
  int minor_offset = 0;
  -   int minor_cnt = VIDEO_NUM_DEVICES;
  +   int kernel_nrs = VIDEO_NUM_DEVICES;
  const char *name_base;
  void *priv = video_get_drvdata(vdev);
   
  @@ -470,52 +470,52 @@ int video_register_device_index(struct v
  switch (type) {
  case VFL_TYPE_GRABBER:
  minor_offset = 0;
  -   minor_cnt = 64;
  +   kernel_nrs = 64;
  break;
  case VFL_TYPE_RADIO:
  minor_offset = 64;
  -   minor_cnt = 64;
  +   kernel_nrs = 64;
  break;
  case VFL_TYPE_VTX:
  minor_offset = 192;
  -   minor_cnt = 32;
  +   kernel_nrs = 32;
  break;
  case VFL_TYPE_VBI:
  minor_offset = 224;
  -   minor_cnt = 32;
  +   kernel_nrs = 32;
  break;
  default:
  minor_offset = 128;
  -   minor_cnt = 64;
  -   break;
  -   }
  -#endif
  -
  -   /* Pick a minor number */
  +   kernel_nrs = 64;
  +   break;
  +   }
  +#endif
  +
  +   /* Pick a kernel number */
  mutex_lock(videodev_lock);
  -   nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr);
  -   if (nr == minor_cnt)
  -   nr = find_first_zero_bit(video_nums[type], minor_cnt);
  -   if (nr == minor_cnt) {
  +   nr = find_next_zero_bit(video_nums[type], kernel_nrs, nr == -1 ? 0 : 
  nr);
  +   if (nr == kernel_nrs)
  +   nr = find_first_zero_bit(video_nums[type], kernel_nrs);
  +   if (nr == kernel_nrs) {
  printk(KERN_ERR could not get a free kernel number\n);
  mutex_unlock(videodev_lock);
  return -ENFILE;
  }
   #ifdef CONFIG_VIDEO_FIXED_MINOR_RANGES
  /* 1-on-1 mapping of kernel number to minor number */
  -   i = nr;
  +   minor = nr;
   #else
  /* The kernel number and minor numbers are independent */
  -   for (i = 0; i  VIDEO_NUM_DEVICES; i++)
  -   if (video_device[i] == NULL)
  +   for (minor = 0; minor  VIDEO_NUM_DEVICES; minor++)
  +   if (video_device[minor] == NULL)
  break;
  -   if (i == VIDEO_NUM_DEVICES) {
  +   if (minor == VIDEO_NUM_DEVICES) {
  mutex_unlock(videodev_lock);
  printk(KERN_ERR could not get a free minor\n);
  return -ENFILE;
  }
   #endif
  -   vdev-minor = i + minor_offset;
  +   vdev-minor = minor + minor_offset;
  vdev-num = nr;
  set_bit(nr, video_nums[type]);
  /* Should not happen since we thought this minor was free */
  
 
 The progressive changes at video_register_device() created a mess on this
 function, that reflected on ov511 driver, but it is also present on the 
 others.
 
 By looking on this patch, it is obfuscating the function even more. Creating 
 more
 confusion on it, due to some reasons:
 
 1) The name kernel number doesn't seem much appropriate. Any number used in
 

Re: Did I miss any other patches or RFCs that need to be reviewed?

2009-06-15 Thread Hans Verkuil
On Monday 15 June 2009 20:44:15 Karicheri, Muralidharan wrote:
 Hans,

 That is great!

 Once I change the code based on the comments, do you think there is a
 chance to get the driver to be merged to 2.6.31 (If so, how soon should I
 be ready with the next version, v3 of the patch) or do we need to wait
 until 2.6.32?

If you want to have a chance to get this in 2.6.31 then you have to be 
quick, and even then I can't guarantee anything. It will depend on Mauro to 
a large extent. The 2.6.31 merge window is now open but will close in 1-2 
weeks. After that it depends on Mauro whether he will allow it to be 
merged.

It's a pretty tight schedule, I'm afraid.

Regards,

Hans

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


RE: [PATCH 1/10 - v2] vpfe capture bridge driver for DM355 and DM6446

2009-06-15 Thread Karicheri, Muralidharan
Hans,

I am not clear about some of your comments. Please see below with a [MK] prefix.

 +static int debug;
 +static u32 numbuffers = 3;
 +static u32 bufsize = (720 * 576 * 2);
 +
 +module_param(numbuffers, uint, S_IRUGO);
 +module_param(bufsize, uint, S_IRUGO);
 +module_param(debug, int, 0644);
 +
 +
 +/* Set interface params based on client interface */
 +static int vpfe_set_hw_if_params(struct vpfe_device *vpfe_dev)
 +{
 +struct vpfe_subdev_info *subdev = vpfe_dev-current_subdev;
 +struct v4l2_routing *route =
 +(subdev-routes[vpfe_dev-current_input]);
 +
 +switch (route-output) {
 +case OUTPUT_10BIT_422_EMBEDDED_SYNC:
 +vpfe_dev-vpfe_if_params.if_type = VPFE_BT656;
 +break;
 +case OUTPUT_20BIT_422_SEPERATE_SYNC:
 +vpfe_dev-vpfe_if_params.if_type = VPFE_YCBCR_SYNC_16;
 +break;
 +case OUTPUT_10BIT_422_SEPERATE_SYNC:
 +vpfe_dev-vpfe_if_params.if_type = VPFE_YCBCR_SYNC_8;
 +break;
 +default:
 +v4l2_err(vpfe_dev-v4l2_dev, decoder output
 + not supported, %d\n, route-output);
 +return -EINVAL;
 +}
 +
 +/* set if client specific interface param is available */
 +if (subdev-pdata) {
 +/* each client will have different interface requirements */
 +if (!strcmp(subdev-name, tvp5146)) {
 +struct tvp514x_platform_data *pdata = subdev-pdata;
 +
 +if (pdata-hs_polarity)
 +vpfe_dev-vpfe_if_params.hdpol =
 +VPFE_PINPOL_POSITIVE;
 +else
 +vpfe_dev-vpfe_if_params.hdpol =
 +VPFE_PINPOL_NEGATIVE;
 +
 +if (pdata-vs_polarity)
 +vpfe_dev-vpfe_if_params.vdpol =
 +VPFE_PINPOL_POSITIVE;
 +else
 +vpfe_dev-vpfe_if_params.hdpol =
 +VPFE_PINPOL_NEGATIVE;

This won't work. Instead this should be data associated with the
platform_data.
I.e. the platform_data for the dm355/dm6446 contains not only the subdev
information, but for each subdev also the information on how to setup the
vpfe
polarities. You cannot derive that information from what subdevs are used
since
the board designer might have added e.g. inverters or something like that.
Such
information can only come from the platform_data.

[MK] I know this code is not correct. But I was waiting for the discussion on 
my bus parameter patch to make this change. Currently TVP514x driver that you 
have reviewed configure output bus based on route-output parameter set by 
s_route(). This doesn't make sense. The input param make sense since 
application can choose between Composite and S-Video inputs. There is only one 
bus going out of the sub device to vpfe. So the output selection @ sub device 
is redundant. I think the output is part of as the bus parameter structure I 
added in the bus parameter patch which is under review. It can be read by 
TVP514x from the platform data (using the structure added by my patch) and can 
be overridden by s_bus(). Do you expect the bridge driver and sub devices 
having platform data for bus type (For example, BT.656)? It appears to be 
required only for sub device and bridge driver can configure the ccdc based on 
sub device bus type.  But for polarities I need to define them for both sides. 
comments?

 +} else {
 +v4l2_err(vpfe_dev-v4l2_dev, No interface params
 + defined for subdevice, %d\n, route-output);
 +return -EFAULT;
 +}
 +}
 +return ccdc_dev-hw_ops.set_hw_if_params(vpfe_dev-vpfe_if_params);
 +}
 +
 +/*
 +
 +struct vpfe_fh *fh;
 +
 +v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_open\n);
 +
 +if (!vpfe_dev-cfg-num_subdevs) {
 +v4l2_err(vpfe_dev-v4l2_dev, No decoder registered\n);
 +return -ENODEV;
 +}

Why would this be an error? I might have an FPGA connected instead or some
other non-i2c device that doesn't require any setup from this driver.

[MK] What you mean by this? Are you saying an FPGA logic will implement the 
decoder hardware? That is quite possible, so also it could be non-i2c. But my 
understanding was that sub device can be anything that basically implement the 
sub device API and need not always be an i2c device. So for FPGA or some other 
bus based device, the bridge device doesn't care how the command to change 
input, detect standard etc are communicated by the sub device driver to its 
hardware. It could be writing into some FPGA register or sending a proprietary 
protocol command. Is my understanding correct? In that case each of the above 
(FPGA or non-i2c) is a sub device and at least one sub device should be 
available before application can do 

RE: Did I miss any other patches or RFCs that need to be reviewed?

2009-06-15 Thread Karicheri, Muralidharan
Hans,

I will do my best to push v3 of this patch this week.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com

-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, June 15, 2009 5:46 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; davinci-linux-open-
sou...@linux.davincidsp.com; linux-o...@vger.kernel.org
Subject: Re: Did I miss any other patches or RFCs that need to be reviewed?

On Monday 15 June 2009 20:44:15 Karicheri, Muralidharan wrote:
 Hans,

 That is great!

 Once I change the code based on the comments, do you think there is a
 chance to get the driver to be merged to 2.6.31 (If so, how soon should I
 be ready with the next version, v3 of the patch) or do we need to wait
 until 2.6.32?

If you want to have a chance to get this in 2.6.31 then you have to be
quick, and even then I can't guarantee anything. It will depend on Mauro to
a large extent. The 2.6.31 merge window is now open but will close in 1-2
weeks. After that it depends on Mauro whether he will allow it to be
merged.

It's a pretty tight schedule, I'm afraid.

Regards,

   Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w*jg����ݢj/���z�ޖ��2�ޙ�)ߡ�a�����G���h��j:+v���w��٥

Re: TT-S1500 budget-ci registeration

2009-06-15 Thread Thomas Kernen

Thomas Kernen wrote:


Hello to all,

I'm currently testing a TT-S1500 budget card with the TT budget CI 
adapter with vl4 tree and kernel 2.6.28.


When I modprobe budget_ci, the CI adapter seems to be detected but not 
registered in /dev/dvb/adapter3/ca0 as I would have expected it to be.


Instead I see the following output:

[  148.664846] input: Budget-CI dvb ir receiver saa7146 (0) as 
/devices/pci:00/:00:1e.0/:11:09.0/input/input5


Any suggestions/ideas what the cause may be and how I can attempt to 
solve this?


Thanks
Thomas
--


And I realised I cut and pasted the wrong line: I was expecting to see 
budget_ci: CI interface initialised after the other line but nothing 
of the like did appear. Nor any line indicating an error.


As one can see from the lspci the drivers claim to be in use:

11:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH Device 1017
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-

Latency: 123 (3750ns min, 9500ns max)
Interrupt: pin A routed to IRQ 23
Region 0: Memory at d022 (32-bit, non-prefetchable) [size=512]
Kernel driver in use: budget_ci dvb
Kernel modules: budget-ci

Am I missing a point here? I can't find anything that addresses this in 
the LinuxTV wiki or in the archives of the mailing list.


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


Re: [PATCH 7/10 - v2] DM355 platform changes for vpfe capture driver

2009-06-15 Thread Hans Verkuil
On Tuesday 16 June 2009 00:24:34 Karicheri, Muralidharan wrote:
 Hans,

 Please see my response below.

snip

 A general remark: currently you link your inputs directly to a subdev.
  This approach has two disadvantages:
 
 1) It doesn't work if there are no subdevs at all (e.g. because
  everything goes through an fpga).

 [MK] Not sure what you mean here. If there is an FPGA, there should be
 something to make a selection between FPGA vs the rest of the decoders.
 FPGA will have an input and there should be some way it reports the
 detected standard etc. So why can't it be implemented by a sub device
 (may be less configuration since most of the logic is in FPGA).

Hopefully my previous reply explains what I meant. I wasn't clear here 
either.

 2) It fixes the reported order of the inputs to the order of the
  subdevs.

 [MK]Is that an issue? I don't see why.

It's a minor issue. But applications typically enumerate inputs to present a 
list to the user which inputs there are. And if there are a lot then it can 
be useful to have them in a specific order. Either to group the inputs 
based on some criterium or to reflect the labeling on the box. It's a 
nice-to-have, I admit.

 I think it is better to have a separate array of input descriptions that
 refer to a subdev when an input is associated with that subdev.

 [MK] Are suggesting an link from input array entry into sub device entry
 input index?

Yes.

 How do you translate the input from application to a sub 
 device or FPGA input? What if there are two composite inputs on two
 different sub devices?

A Composite 1 input would point to subdev 1 and the Composite 2 input 
would point to subdev 2. Or do you mean something else? (I'm not sure I 
entirely understand your question)


 flexible that way, and I actually think that the vpfe driver will be
 simplified as well.

 [MK], Not sure at this point.

The advantage is that the ENUMINPUT and S/G_INPUT functions can do a simple 
lookup in the input array and immediately find the subdev index. Rather 
than iterating over all subdevs and counting the number of inputs in order 
to find which input belongs to which subdev.

This is probably a stronger argument than my others are :-)

Regards,

Hans


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



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


Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc

2009-06-15 Thread hermann pitton
Hi,

Am Montag, den 15.06.2009, 23:35 +0200 schrieb Hans Verkuil:
 On Monday 15 June 2009 21:48:32 Mauro Carvalho Chehab wrote:
  Hi Hans,
  
  Em Mon, 15 Jun 2009 13:27:42 +0200
  Hans Verkuil hverk...@xs4all.nl escreveu:
  
   On Sunday 14 June 2009 12:15:34 Hans Verkuil wrote:
On Sunday 14 June 2009 11:50:51 Hans Verkuil wrote:
 Hi Mauro,
 
 Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for 
 the 
 following:
 
 - ivtv/cx18: fix regression: class controls are no longer seen
 - v4l2-ctl: add modulator get/set options.
 - v4l2-spec: update VIDIOC_G/S_MODULATOR section.
 - compat: fix __fls check for the arm architecture.
 - smscoreapi: fix compile warning
 
 The first one is a high prio bug as it is a 2.6.30 regression. Mike, 
 once 
 this is merged in the git tree this one can be queued for the 2.6.30 
 stable 
 series.
 
 The other changes are small stuff.

Added one more minor change:

- v4l2-i2c-drv.h: add comment describing when not to use this header.
  
  The above patches seem ok.
  
   
   And added this one as well:
   
   - v4l2-dev: fix some confusing variable names and comments
   
   # HG changeset patch
   # User Hans Verkuil hverk...@xs4all.nl
   # Date 1245063581 -7200
   # Node ID 083bb5ad197e4c49430de2b26f3115743fe5cc27
   # Parent 743225159afab6d79a0d6095bc302f9922305c33
   v4l2-dev: fix some confusing variable names and comments
   
   From: Hans Verkuil hverk...@xs4all.nl
   
   Some variable names and comments were rather misleading when it came
   to the distinction between kernel numbers and minor numbers. This should
   clarify things.
   
   Priority: normal
   
   Signed-off-by: Hans Verkuil hverk...@xs4all.nl
   
   --- a/linux/drivers/media/video/v4l2-dev.cSun Jun 14 12:12:11 
   2009 +0200
   +++ b/linux/drivers/media/video/v4l2-dev.cMon Jun 15 12:59:41 
   2009 +0200
   @@ -419,10 +419,10 @@ int video_register_device_index(struct v
int video_register_device_index(struct video_device *vdev, int type, int 
   nr,
 int index)
{
   - int i = 0;
   + int minor;
 int ret;
 int minor_offset = 0;
   - int minor_cnt = VIDEO_NUM_DEVICES;
   + int kernel_nrs = VIDEO_NUM_DEVICES;
 const char *name_base;
 void *priv = video_get_drvdata(vdev);

   @@ -470,52 +470,52 @@ int video_register_device_index(struct v
 switch (type) {
 case VFL_TYPE_GRABBER:
 minor_offset = 0;
   - minor_cnt = 64;
   + kernel_nrs = 64;
 break;
 case VFL_TYPE_RADIO:
 minor_offset = 64;
   - minor_cnt = 64;
   + kernel_nrs = 64;
 break;
 case VFL_TYPE_VTX:
 minor_offset = 192;
   - minor_cnt = 32;
   + kernel_nrs = 32;
 break;
 case VFL_TYPE_VBI:
 minor_offset = 224;
   - minor_cnt = 32;
   + kernel_nrs = 32;
 break;
 default:
 minor_offset = 128;
   - minor_cnt = 64;
   - break;
   - }
   -#endif
   -
   - /* Pick a minor number */
   + kernel_nrs = 64;
   + break;
   + }
   +#endif
   +
   + /* Pick a kernel number */
 mutex_lock(videodev_lock);
   - nr = find_next_zero_bit(video_nums[type], minor_cnt, nr == -1 ? 0 : nr);
   - if (nr == minor_cnt)
   - nr = find_first_zero_bit(video_nums[type], minor_cnt);
   - if (nr == minor_cnt) {
   + nr = find_next_zero_bit(video_nums[type], kernel_nrs, nr == -1 ? 0 : 
   nr);
   + if (nr == kernel_nrs)
   + nr = find_first_zero_bit(video_nums[type], kernel_nrs);
   + if (nr == kernel_nrs) {
 printk(KERN_ERR could not get a free kernel number\n);
 mutex_unlock(videodev_lock);
 return -ENFILE;
 }
#ifdef CONFIG_VIDEO_FIXED_MINOR_RANGES
 /* 1-on-1 mapping of kernel number to minor number */
   - i = nr;
   + minor = nr;
#else
 /* The kernel number and minor numbers are independent */
   - for (i = 0; i  VIDEO_NUM_DEVICES; i++)
   - if (video_device[i] == NULL)
   + for (minor = 0; minor  VIDEO_NUM_DEVICES; minor++)
   + if (video_device[minor] == NULL)
 break;
   - if (i == VIDEO_NUM_DEVICES) {
   + if (minor == VIDEO_NUM_DEVICES) {
 mutex_unlock(videodev_lock);
 printk(KERN_ERR could not get a free minor\n);
 return -ENFILE;
 }
#endif
   - vdev-minor = i + minor_offset;
   + vdev-minor = minor + minor_offset;
 vdev-num = nr;
 set_bit(nr, video_nums[type]);
 /* Should not happen since we thought this minor was free */
   
  
  The progressive changes at video_register_device() created a mess on this
  function, that reflected on ov511 driver, but it is also present on the 
  others.
  
  By looking on this patch, it is obfuscating the function even more. 
  Creating more
  confusion on it, due to 

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc

2009-06-15 Thread Mauro Carvalho Chehab
Em Mon, 15 Jun 2009 23:35:59 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:

  By looking on this patch, it is obfuscating the function even more. 
  Creating more
  confusion on it, due to some reasons:
  
  1) The name kernel number doesn't seem much appropriate. Any number used 
  in
  kernel can be called as a kernel number.
 
 Actually, that is apparently what the number X is called in a node like
 /dev/videoX. I didn't make up that term, it's what I found when reading
 'man udev'. Since udev deals extensively with these concepts I borrowed the
 udev terminology for this. If someone knows a better word, then I'm happy
 to use that.

Ah, now I see where you got this. Yet, this is what man udev says:

   $number, %n
  The kernel number for this device. For example, ’sda3’ has
  kernel number of ’3’

   $major, %M
  The kernel major number for the device.

   $minor %m
  The kernel minor number for the device.

See, on all all tree is calls kernel [something] number. Seems confusing
enough to avoid those names at the V4L2 core. Also, even the man needed to give
an example, showing that this nomenclature may not be widely understood.

Maybe we can just call it as dev_number and properly explain its meaning.

  That's said, the logic of when minor range is not fixed seems broken, as it
  will change only an internal representation of the device. So the module
  parameters that reflect at nr var won't work as expected.
 
 No, they work exactly as expected: if you set nr to 1 then you get a 
 /dev/video1
 node no matter what the FIXED_MINOR_RANGES setting is (provided there isn't
 already a /dev/video1 node, in which case it will find the next available
 kernel number).
 
  So, the current code seems too complex and broken.
 
 No, it's neither too complex nor broken, although it clearly needs still more
 comments.

The code is complex. For example, take a look at this:

#ifdef CONFIG_VIDEO_FIXED_MINOR_RANGES
...
#else
/* The kernel number and minor numbers are independent */
for (i = 0; i  VIDEO_NUM_DEVICES; i++)
if (video_device[i] == NULL)
break;
if (i == VIDEO_NUM_DEVICES) {
..
return -ENFILE;
}

#endif

vdev-minor = i + minor_offset;
...
/* Should not happen since we thought this minor was free */
WARN_ON(video_device[vdev-minor] != NULL);

when !FIXED_MINOR_RANGES, you're return if all video_device[i] are used. Then,
you do a WARN_ON(video_device[i + minor_offset]) instead of video_device[i].

People need to look back at the code to identify that minor_offset is equal to
0 when !FIXED_MINOR_RANGES.

Also, by letting the function to allocate a device even when video_device !=
NULL seems broken. It should instead call WARN and return with -EINVAL.

The presence of the #if's, plus the high number of phases at the same
function make it harder to read and understand. The code will be more readable
if we break it into a few static functions (that will be inline anyway, due to
gcc optimizer).

 
  Just as reference, the behavior before changeset 9133 is:
  
  switch (type) {
  case VFL_TYPE_GRABBER:
 base = MINOR_VFL_TYPE_GRABBER_MIN;
  ...
  }
  
  i = base + nr;
  vfd-minor = i;
  
  
  where nr is auto-selected for negative values, or just used above otherwise.
  
  That's said, IMO, we need to rework at the function, making it simpler, and
  fixing the behavior where the user wants to select a minor.
 
 The user doesn't select a minor number, the user selects a kernel number.
 With udev minor numbers have become completely uninteresting and unless
 FIXED_MINOR_RANGES is set each node will be assigned the first free minor
 number.

OK, now I see what you're meaning.

With respect to the code, I still think it does too much into just one
function. It may make sense to break the code into more functions to allow an
easier understanding.



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


[PATCH] FM1216MK5 FM radio patch

2009-06-15 Thread Dmitri Belimov
Hi

Next code for implement Philips FM1216MK5.

1. Implement get_stereo function.
2. Add correct data byte for FM radio mode.

diff -r bff77ec33116 linux/drivers/media/common/tuners/tuner-simple.c
--- a/linux/drivers/media/common/tuners/tuner-simple.c  Thu Jun 11 18:44:23 
2009 -0300
+++ b/linux/drivers/media/common/tuners/tuner-simple.c  Tue Jun 16 05:27:52 
2009 +1000
@@ -145,6 +145,8 @@
case TUNER_LG_NTSC_TAPE:
case TUNER_TCL_MF02GIP_5N:
return ((status  TUNER_SIGNAL) == TUNER_STEREO_MK3);
+   case TUNER_PHILIPS_FM1216MK5:
+   return status | TUNER_STEREO;
default:
return status  TUNER_STEREO;
}
@@ -514,6 +516,10 @@
case TUNER_PHILIPS_FM1256_IH3:
case TUNER_TCL_MF02GIP_5N:
buffer[3] = 0x19;
+   break;
+   case TUNER_PHILIPS_FM1216MK5:
+   buffer[2] = 0x88;
+   buffer[3] = 0x09;
break;
case TUNER_TNF_5335MF:
buffer[3] = 0x11;

Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com


With my best regards, Dmitry.diff -r bff77ec33116 linux/drivers/media/common/tuners/tuner-simple.c
--- a/linux/drivers/media/common/tuners/tuner-simple.c	Thu Jun 11 18:44:23 2009 -0300
+++ b/linux/drivers/media/common/tuners/tuner-simple.c	Tue Jun 16 05:27:52 2009 +1000
@@ -145,6 +145,8 @@
 	case TUNER_LG_NTSC_TAPE:
 	case TUNER_TCL_MF02GIP_5N:
 		return ((status  TUNER_SIGNAL) == TUNER_STEREO_MK3);
+	case TUNER_PHILIPS_FM1216MK5:
+		return status | TUNER_STEREO;
 	default:
 		return status  TUNER_STEREO;
 	}
@@ -514,6 +516,10 @@
 	case TUNER_PHILIPS_FM1256_IH3:
 	case TUNER_TCL_MF02GIP_5N:
 		buffer[3] = 0x19;
+		break;
+	case TUNER_PHILIPS_FM1216MK5:
+		buffer[2] = 0x88;
+		buffer[3] = 0x09;
 		break;
 	case TUNER_TNF_5335MF:
 		buffer[3] = 0x11;

Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com


Re: [PULL] http://kernellabs.com/hg/~dheitmueller/em28xx-no-audio

2009-06-15 Thread Mauro Carvalho Chehab
Em Sun, 14 Jun 2009 20:30:18 -0400
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:

 Hello Mauro,
 
 Please pull from
 http://kernellabs.com/hg/~dheitmueller/em28xx-no-audio for the
 following:
 
 - em28xx: don't create audio device if not supported
 
 This should correct the problems you noticed with the previous patch
 in the misc-fixes tree.

Applied, thanks.

 Tested with Kworld 2800d and HVR-950.  Would be useful if somebody who
 had an em28xx device with the USB audio class could test as well.

Tested with a Hauppauge WinTV USB2, with msp3445-bg i2s chip, no AC97:

[ 6680.635866] em28xx: New device WinTV USB2 @ 480 Mbps (2040:4200, interface 
0, class 0)
[ 6680.635894] em28xx #0: Identified as Hauppauge WinTV USB 2 (card=4)
[ 6680.636116] em28xx #0: chip ID is em2840
[ 6680.755380] em28xx #0: i2c eeprom 00: 1a eb 67 95 40 20 00 42 20 00 1c 03 82 
18 6a 18
[ 6680.755410] em28xx #0: i2c eeprom 10: 00 00 24 57 6e 00 00 00 60 00 00 00 02 
00 00 00
[ 6680.755436] em28xx #0: i2c eeprom 20: 1e 00 10 10 00 00 00 00 00 00 00 00 00 
00 00 00
[ 6680.755463] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 01 01 00 
00 00 00
[ 6680.755489] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 6680.755515] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 6680.755540] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 18 03 30 
00 30 00
[ 6680.755566] em28xx #0: i2c eeprom 70: 30 00 32 00 38 00 31 00 39 00 33 00 34 
00 38 00
[ 6680.755592] em28xx #0: i2c eeprom 80: 00 00 18 03 57 00 69 00 6e 00 54 00 56 
00 20 00
[ 6680.755618] em28xx #0: i2c eeprom 90: 55 00 53 00 42 00 32 00 00 00 00 00 00 
00 00 00
[ 6680.755644] em28xx #0: i2c eeprom a0: 84 12 00 00 05 50 1a 7f 08 56 23 1c a4 
16 16 8d
[ 6680.755670] em28xx #0: i2c eeprom b0: ff 00 00 00 04 84 0a 00 01 01 20 77 00 
40 14 05
[ 6680.755697] em28xx #0: i2c eeprom c0: 2b 00 74 02 01 0c 03 79 d5 00 00 00 00 
00 00 00
[ 6680.755723] em28xx #0: i2c eeprom d0: 84 12 00 00 05 50 1a 7f 08 56 23 1c a4 
16 16 8d
[ 6680.755749] em28xx #0: i2c eeprom e0: ff 00 00 00 04 84 0a 00 01 01 20 77 00 
40 14 05
[ 6680.755775] em28xx #0: i2c eeprom f0: 2b 00 74 02 01 0c 03 79 d5 00 00 00 00 
00 00 00
[ 6680.755803] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xf44042ea
[ 6680.755808] em28xx #0: EEPROM info:
[ 6680.755811] em28xx #0:   I2S audio, sample rate=32k
[ 6680.755815] em28xx #0:   500mA max power
[ 6680.755820] em28xx #0:   Table at 0x24, strings=0x1882, 0x186a, 0x
[ 6680.775332] tveeprom 1-0050: Hauppauge model 42012, rev C186, serial# 2819348
[ 6680.775341] tveeprom 1-0050: tuner model is Philips FQ1236 MK3 (idx 86, type 
43)
[ 6680.775347] tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
[ 6680.775353] tveeprom 1-0050: audio processor is MSP3445 (idx 12)
[ 6680.775358] tveeprom 1-0050: has radio
[ 6680.856348] msp3400 1-0044: MSP3445G-B8 found @ 0x88 (em28xx #0)
[ 6680.856355] msp3400 1-0044: msp3400 supports radio, mode is autodetect and 
autoselect
[ 6680.875282] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0)
[ 6680.938362] tuner 1-0043: chip found @ 0x86 (em28xx #0)
[ 6680.969181] tda9887 1-0043: creating new instance
[ 6680.969188] tda9887 1-0043: tda988[5/6/7] found
[ 6680.969194] tuner 1-0043: type set to tda9887
[ 6680.969199] tuner 1-0043: tv freq set to 0.00
[ 6680.969205] tuner 1-0043: TV freq (0.00) out of range (44-958)
[ 6680.980394] tuner 1-0043: em28xx #0 tuner I2C addr 0x86 with type 74 used 
for 0x0e
[ 6680.998131] tuner 1-0063: Setting mode_mask to 0x0e
[ 6680.998139] tuner 1-0063: chip found @ 0xc6 (em28xx #0)
[ 6680.998144] tuner 1-0063: tuner 0x63: Tuner type absent
[ 6680.998159] tuner 1-0043: Calling set_type_addr for type=43, addr=0x63, 
mode=0x06, config=0x00
[ 6680.998166] tuner 1-0043: set addr discarded for type 74, mask e. Asked to 
change tuner at addr 0x63, with mask 6
[ 6680.998174] tuner 1-0063: Calling set_type_addr for type=43, addr=0x63, 
mode=0x06, config=0x00
[ 6680.998179] tuner 1-0063: defining GPIO callback
[ 6681.031219] tuner-simple 1-0063: creating new instance
[ 6681.031228] tuner-simple 1-0063: type set to 43 (Philips NTSC MK3 (FM1236MK3 
or FM1236/F))
[ 6681.031236] tuner 1-0063: type set to Philips NTSC MK3 (FM1236MK3 or 
FM1236/F)
[ 6681.031242] tuner 1-0063: tv freq set to 400.00
[ 6681.050237] tuner 1-0063: em28xx #0 tuner I2C addr 0xc6 with type 43 used 
for 0x0e
[ 6681.060247] tuner 1-0043: switching to v4l2
[ 6681.060255] tuner 1-0043: tv freq set to 567.25
[ 6681.070203] tuner 1-0063: switching to v4l2
[ 6681.070210] tuner 1-0063: tv freq set to 567.25
[ 6681.090443] em28xx #0: Config register raw data: 0x20
[ 6681.090448] em28xx #0: I2S Audio (3 sample rates)
[ 6681.090452] em28xx #0: No AC97 audio processor
[ 6681.261112] tvp5150 1-005c: tvp5150am1 detected.
[ 6683.142855] em28xx #0: v4l2 driver version 0.1.2
[ 6683.560549] em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0
[ 6683.560560] tuner 1-0043: Putting 

Re: [RESEND][PATCH] video: Initial support for ADV7180

2009-06-15 Thread Mauro Carvalho Chehab
Em Mon, 15 Jun 2009 17:13:28 +0200
Richard Röjfors  richard.rojfors@mocean-labs.com escreveu:

 This is an initial driver for Analog Devices ADV7180 Video Decoder.
 
 So far it only supports query standard.

Hmm... it seems too preliminar for merging. Also, as this is an i2c ancillary
driver, it would be interesting if you could send it together with the bridge
or platform driver that uses it.

Cheers,
Mauro.

 
 Signed-off-by: Richard Röjfors richard.rojfors@mocean-labs.com
 ---
 Index: linux-2.6.30-rc7/drivers/media/video/adv7180.c
 ===
 --- linux-2.6.30-rc7/drivers/media/video/adv7180.c(revision 0)
 +++ linux-2.6.30-rc7/drivers/media/video/adv7180.c(revision 867)
 @@ -0,0 +1,221 @@
 +/*
 + * adv7180.c Analog Devices ADV7180 video decoder driver
 + * Copyright (c) 2009 Intel Corporation
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * 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/module.h
 +#include linux/init.h
 +#include linux/errno.h
 +#include linux/kernel.h
 +#include linux/interrupt.h
 +#include linux/i2c.h
 +#include linux/i2c-id.h
 +#include media/v4l2-ioctl.h
 +#include linux/videodev2.h
 +#include media/v4l2-device.h
 +#include media/v4l2-chip-ident.h
 +#include media/v4l2-i2c-drv.h
 +
 +
 +#define ADV7180_INPUT_CONTROL_REG0x00
 +#define ADV7180_INPUT_CONTROL_PAL_BG_NTSC_J_SECAM0x00
 +#define ADV7180_AUTODETECT_ENABLE_REG0x07
 +#define ADV7180_AUTODETECT_DEFAULT   0x7f
 +
 +
 +#define ADV7180_STATUS1_REG 0x10
 +#define ADV7180_STATUS1_AUTOD_MASK 0x70
 +#define ADV7180_STATUS1_AUTOD_NTSM_M_J   0x00
 +#define ADV7180_STATUS1_AUTOD_NTSC_4_43 0x10
 +#define ADV7180_STATUS1_AUTOD_PAL_M  0x20
 +#define ADV7180_STATUS1_AUTOD_PAL_60 0x30
 +#define ADV7180_STATUS1_AUTOD_PAL_B_G0x40
 +#define ADV7180_STATUS1_AUTOD_SECAM  0x50
 +#define ADV7180_STATUS1_AUTOD_PAL_COMB   0x60
 +#define ADV7180_STATUS1_AUTOD_SECAM_525  0x70
 +
 +#define ADV7180_IDENT_REG 0x11
 +#define ADV7180_ID_7180 0x18
 +
 +
 +static unsigned short normal_i2c[] = { 0x42  1, I2C_CLIENT_END };
 +
 +I2C_CLIENT_INSMOD;
 +
 +struct adv7180_state {
 + struct v4l2_subdev sd;
 +};
 +
 +static v4l2_std_id determine_norm(struct i2c_client *client)
 +{
 + u8 status1 = i2c_smbus_read_byte_data(client, ADV7180_STATUS1_REG);
 +
 + switch (status1  ADV7180_STATUS1_AUTOD_MASK) {
 + case ADV7180_STATUS1_AUTOD_NTSM_M_J:
 + return V4L2_STD_NTSC_M_JP;
 + case ADV7180_STATUS1_AUTOD_NTSC_4_43:
 + return V4L2_STD_NTSC_443;
 + case ADV7180_STATUS1_AUTOD_PAL_M:
 + return V4L2_STD_PAL_M;
 + case ADV7180_STATUS1_AUTOD_PAL_60:
 + return V4L2_STD_PAL_60;
 + case ADV7180_STATUS1_AUTOD_PAL_B_G:
 + return V4L2_STD_PAL;
 + case ADV7180_STATUS1_AUTOD_SECAM:
 + return V4L2_STD_SECAM;
 + case ADV7180_STATUS1_AUTOD_PAL_COMB:
 + return V4L2_STD_PAL_Nc | V4L2_STD_PAL_N;
 + case ADV7180_STATUS1_AUTOD_SECAM_525:
 + return V4L2_STD_SECAM;
 + default:
 + return V4L2_STD_UNKNOWN;
 + }
 +}
 +
 +static inline struct adv7180_state *to_state(struct v4l2_subdev *sd)
 +{
 + return container_of(sd, struct adv7180_state, sd);
 +}
 +
 +static int adv7180_querystd(struct v4l2_subdev *sd, v4l2_std_id *std)
 +{
 + struct i2c_client *client = v4l2_get_subdevdata(sd);
 +
 + *(v4l2_std_id *)std = determine_norm(client);
 + return 0;
 +}
 +
 +static int adv7180_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
 +{
 + return -EINVAL;
 +}
 +
 +static int adv7180_s_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
 +{
 + return -EINVAL;
 +}
 +
 +static int adv7180_g_chip_ident(struct v4l2_subdev *sd,
 + struct v4l2_dbg_chip_ident *chip)
 +{
 + struct i2c_client *client = v4l2_get_subdevdata(sd);
 +
 + return v4l2_chip_ident_i2c_client(client, chip, V4L2_IDENT_ADV7180, 0);
 +}
 +
 +static int adv7180_log_status(struct v4l2_subdev *sd)
 +{
 + v4l2_info(sd, Normal operation\n);
 + return 0;
 +}
 +
 +static irqreturn_t adv7180_irq(int irq, void *devid)
 +{
 + return IRQ_NONE;
 +}
 +
 +static const struct v4l2_subdev_video_ops adv7180_video_ops = {
 + .querystd = adv7180_querystd,
 +};
 +
 +static const struct v4l2_subdev_core_ops adv7180_core_ops = {
 + .log_status = 

[PATCH 43/64] media: remove driver_data direct access of struct device

2009-06-15 Thread Greg Kroah-Hartman
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device.  Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used.  These functions
have been around since the beginning, so are backwards compatible with
all older kernel versions.


Cc: Mauro Carvalho Chehab mche...@infradead.org
Acked-by: Mike Isely is...@pobox.com
Cc: linux-media@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
 drivers/media/dvb/firewire/firedtv-1394.c   |4 ++--
 drivers/media/dvb/firewire/firedtv-dvb.c|2 +-
 drivers/media/video/pvrusb2/pvrusb2-sysfs.c |   22 +++---
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/media/dvb/firewire/firedtv-1394.c 
b/drivers/media/dvb/firewire/firedtv-1394.c
index 4e20765..2b6eeea 100644
--- a/drivers/media/dvb/firewire/firedtv-1394.c
+++ b/drivers/media/dvb/firewire/firedtv-1394.c
@@ -225,7 +225,7 @@ fail_free:
 
 static int node_remove(struct device *dev)
 {
-   struct firedtv *fdtv = dev-driver_data;
+   struct firedtv *fdtv = dev_get_drvdata(dev);
 
fdtv_dvb_unregister(fdtv);
 
@@ -242,7 +242,7 @@ static int node_remove(struct device *dev)
 
 static int node_update(struct unit_directory *ud)
 {
-   struct firedtv *fdtv = ud-device.driver_data;
+   struct firedtv *fdtv = dev_get_drvdata(ud-device);
 
if (fdtv-isochannel = 0)
cmp_establish_pp_connection(fdtv, fdtv-subunit,
diff --git a/drivers/media/dvb/firewire/firedtv-dvb.c 
b/drivers/media/dvb/firewire/firedtv-dvb.c
index 9d308dd..5742fde 100644
--- a/drivers/media/dvb/firewire/firedtv-dvb.c
+++ b/drivers/media/dvb/firewire/firedtv-dvb.c
@@ -268,7 +268,7 @@ struct firedtv *fdtv_alloc(struct device *dev,
if (!fdtv)
return NULL;
 
-   dev-driver_data= fdtv;
+   dev_set_drvdata(dev, fdtv);
fdtv-device= dev;
fdtv-isochannel= -1;
fdtv-voltage   = 0xff;
diff --git a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c 
b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
index 299c1cb..6c23456 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
@@ -539,7 +539,7 @@ static void class_dev_destroy(struct pvr2_sysfs *sfp)
 sfp-attr_unit_number);
}
pvr2_sysfs_trace(Destroying class_dev id=%p,sfp-class_dev);
-   sfp-class_dev-driver_data = NULL;
+   dev_set_drvdata(sfp-class_dev, NULL);
device_unregister(sfp-class_dev);
sfp-class_dev = NULL;
 }
@@ -549,7 +549,7 @@ static ssize_t v4l_minor_number_show(struct device 
*class_dev,
 struct device_attribute *attr, char *buf)
 {
struct pvr2_sysfs *sfp;
-   sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+   sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
 pvr2_hdw_v4l_get_minor_number(sfp-channel.hdw,
@@ -561,7 +561,7 @@ static ssize_t bus_info_show(struct device *class_dev,
 struct device_attribute *attr, char *buf)
 {
struct pvr2_sysfs *sfp;
-   sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+   sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
 pvr2_hdw_get_bus_info(sfp-channel.hdw));
@@ -572,7 +572,7 @@ static ssize_t hdw_name_show(struct device *class_dev,
 struct device_attribute *attr, char *buf)
 {
struct pvr2_sysfs *sfp;
-   sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+   sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
 pvr2_hdw_get_type(sfp-channel.hdw));
@@ -583,7 +583,7 @@ static ssize_t hdw_desc_show(struct device *class_dev,
 struct device_attribute *attr, char *buf)
 {
struct pvr2_sysfs *sfp;
-   sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+   sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%s\n,
 pvr2_hdw_get_desc(sfp-channel.hdw));
@@ -595,7 +595,7 @@ static ssize_t v4l_radio_minor_number_show(struct device 
*class_dev,
   char *buf)
 {
struct pvr2_sysfs *sfp;
-   sfp = (struct pvr2_sysfs *)class_dev-driver_data;
+   sfp = dev_get_drvdata(class_dev);
if (!sfp) return -EINVAL;
return scnprintf(buf,PAGE_SIZE,%d\n,
 pvr2_hdw_v4l_get_minor_number(sfp-channel.hdw,
@@ -607,7 +607,7 @@ static ssize_t unit_number_show(struct device *class_dev,
struct device_attribute *attr, char *buf)
 {
struct pvr2_sysfs *sfp;
-   sfp =