date:20110830

On Tuesday, August 23, 2011 08:35:35 Al Viro wrote:
 On Tue, Aug 23, 2011 at 08:33:25AM +0200, Hans Verkuil wrote:
  (and resent again, this time with the correct linux-fsdevel mail address)
  (Resent as requested by Andrew Morton since this is still stuck)
  
  Hi Al, Andrew,
  
  Can you take a look at this patch and send an Ack or review comments?
 
 Not at the moment - I'm half-asleep and tired as hell.  Will do in the
 morning...
 

Any progress on this?

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

Media subsystem workshop 2011

2011-08-30 Thread Jean-Paul Saman

Mauro,

I would like to get invited to the Media Subsystem workshop in Prague.


Kind Regards,

Jean-Paul Saman
--
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: [cron job] v4l-dvb daily build: ERRORS

Hi all,

For some reason these daily messages are suddenly marked as spam by 
vger.kernel.org since Sunday.

I've made a change in how the email is sent, if that doesn't work then
I'll contact the postmaster to get this resolved.

Regards,

Hans

On Saturday, August 27, 2011 21:05:34 Hans Verkuil wrote:
 This message is generated daily by a cron job that builds v4l-dvb for
 the kernels and architectures in the list below.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

On Mon, 29 Aug 2011, Laurent Pinchart wrote:

 Hi Guennadi,
 
 On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
  On Mon, 29 Aug 2011, Laurent Pinchart wrote:
   On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
On Sun, 28 Aug 2011, Laurent Pinchart wrote:

[snip]

  @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev
  *sd,
  
  ov5642_try_fmt(sd, mf);
  
  +   priv-out_size.width= mf-width;
  +   priv-out_size.height   = mf-height;
 
 It looks like to me (but I may be wrong) that you achieve different
 resolutions using cropping, not scaling. If that's correct you should
 implement s_crop support and refuse changing the resolution through
 s_fmt.

As the patch explains (I think) on several occasions, currently only
the 1:1 scale is supported, and it was our deliberate choice to
implement this using the scaling API
   
   If you implement cropping, you should use the crop API, not the scaling
   API
   
   :-)
  
  It's changing both - input and output sizes.
 
 Sure, but it's still cropping.

Why? Isn't it a matter of the PoV? It changes the output window, i.e., 
implements S_FMT. And S_FMT is by far more important / widely used than 
S_CROP. Refusing to change the output window and always just returning the 
== crop size wouldn't be polite, IMHO. Don't think many users would guess 
to use S_CROP. Standard applications a la mplayer don't use S_CROP at all.

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

[GIT PATCHES FOR 3.2] Add VOLATILE flag and change autocluster handling of volatile controls

Acked by Hans de Goede and based on extensive discussions on how to handle 
this. See:

http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/35067
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/36650

So it's time to get this merged.

Regards,

Hans

The following changes since commit 69d232ae8e95a229e7544989d6014e875deeb121:

  [media] omap3isp: ccdc: Use generic frame sync event instead of private 
HS_VS event (2011-08-29 12:38:51 -0300)

are available in the git repository at:
  ssh://linuxtv.org/git/hverkuil/media_tree.git autofoo

Hans Verkuil (8):
  videodev2.h: add V4L2_CTRL_FLAG_VOLATILE.
  v4l2-ctrls: replace is_volatile with V4L2_CTRL_FLAG_VOLATILE.
  v4l2-ctrls: implement new volatile autocluster scheme.
  v4l2-controls.txt: update auto cluster documentation.
  pwc: switch to the new auto-cluster volatile handling.
  vivi: add support for VIDIOC_LOG_STATUS.
  pwc: add support for VIDIOC_LOG_STATUS.
  saa7115: use the new auto cluster support.

 Documentation/DocBook/media/v4l/compat.xml |8 +
 Documentation/DocBook/media/v4l/v4l2.xml   |9 +-
 .../DocBook/media/v4l/vidioc-queryctrl.xml |9 ++
 Documentation/video4linux/v4l2-controls.txt|   43 +++
 drivers/media/radio/radio-wl1273.c |2 +-
 drivers/media/radio/wl128x/fmdrv_v4l2.c|2 +-
 drivers/media/video/adp1653.c  |2 +-
 drivers/media/video/pwc/pwc-v4l.c  |  136 
+---
 drivers/media/video/s5p-mfc/s5p_mfc_dec.c  |4 +-
 drivers/media/video/s5p-mfc/s5p_mfc_enc.c  |2 +-
 drivers/media/video/saa7115.c  |5 +-
 drivers/media/video/v4l2-ctrls.c   |  104 
 drivers/media/video/vivi.c |9 ++
 include/linux/videodev2.h  |1 +
 include/media/v4l2-ctrls.h |   15 +--
 15 files changed, 204 insertions(+), 147 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PATCHES FOR 3.2] Two small fixes and more -ENOTTY fixes

Two small fixes that fix v4l2-compliance errors in vivi and ivtv, and one
larger fix that fixes some remaining v4l2-compliance errors with regards to 
ENOTTY handling.

This has been posted before:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg35415.html

But it received no comments, so it's time to merge this.

Regards,

Hans

The following changes since commit 69d232ae8e95a229e7544989d6014e875deeb121:

  [media] omap3isp: ccdc: Use generic frame sync event instead of private 
HS_VS event (2011-08-29 12:38:51 -0300)

are available in the git repository at:
  ssh://linuxtv.org/git/hverkuil/media_tree.git enottyv2

Hans Verkuil (3):
  vivi: fill in colorspace.
  ivtv: fill in service_set.
  v4l2-ioctl: more -ENOTTY fixes

 drivers/media/video/ivtv/ivtv-ioctl.c |   15 ++-
 drivers/media/video/v4l2-ioctl.c  |  206 
+++--
 drivers/media/video/vivi.c|   10 ++
 3 files changed, 165 insertions(+), 66 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

AVerTV Hybrid Volar MAX (H826) wiki entry

2011-08-30 Thread Brian J. Murrell

Hi,

I was looking at the wiki for the supported status of the AVerMedia
AVerTV Hybrid Volar MAX (H826).  The wiki says it's not supported.  But
the wiki also says it's a PCIe card, which it's clearly not:
http://www.avermedia-usa.com/AVerTV/Product/ProductDetail.aspx?Id=431

Additionally in the AP  Driver tab of that page
(http://www.avermedia-usa.com/AVerTV/Product/ProductDetail.aspx?Id=431tab=APDriver)
there is a Linux driver which appears to have (granted, non-GPL) source
included with it.  But surely given source to a working driver, a
cleanroom GPL driver could be developed and supported, yes?  Maybe that
source is just supporting source for a binary blob.  I didn't look
that closely.

In any case, I am just wondering what the real supported status of that
device is given that the wiki is incorrect about at least some details
of the device.

Even if it's not supported, somebody with more understanding of this
device than I (I've just read a product page) ought to fix the wiki.  In
fixing it, I think it's only fair to point to the vendor supplied
driver, even if it's not open source and/or not a compatible open source
license.

Cheers,
b.




signature.asc
Description: OpenPGP digital signature

Re: AVerTV Hybrid Volar MAX (H826) wiki entry

2011-08-30 Thread Devin Heitmueller

On Tue, Aug 30, 2011 at 7:44 AM, Brian J. Murrell br...@interlinx.bc.ca wrote:
 Hi,

 I was looking at the wiki for the supported status of the AVerMedia
 AVerTV Hybrid Volar MAX (H826).  The wiki says it's not supported.  But
 the wiki also says it's a PCIe card, which it's clearly not:
 http://www.avermedia-usa.com/AVerTV/Product/ProductDetail.aspx?Id=431

 Additionally in the AP  Driver tab of that page
 (http://www.avermedia-usa.com/AVerTV/Product/ProductDetail.aspx?Id=431tab=APDriver)
 there is a Linux driver which appears to have (granted, non-GPL) source
 included with it.  But surely given source to a working driver, a
 cleanroom GPL driver could be developed and supported, yes?  Maybe that
 source is just supporting source for a binary blob.  I didn't look
 that closely.

 In any case, I am just wondering what the real supported status of that
 device is given that the wiki is incorrect about at least some details
 of the device.

 Even if it's not supported, somebody with more understanding of this
 device than I (I've just read a product page) ought to fix the wiki.  In
 fixing it, I think it's only fair to point to the vendor supplied
 driver, even if it's not open source and/or not a compatible open source
 license.

They've got a history of violating the GPL by shipping closed source
binary drivers which link against GPL'd DVB drivers (thereby
leveraging the hard work of the developers who GPL'd drivers, while
not giving any of their stuff back).

I cannot speak for the other developers but I wont' go near this crap
with a ten foot pole.

Devin

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

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

2011-08-30 Thread Sakari Ailus

On Mon, Aug 29, 2011 at 02:18:50PM +0200, Guennadi Liakhovetski wrote:
 Hi Laurent
 
 On Sun, 28 Aug 2011, Laurent Pinchart wrote:
 
 [snip]
 
   @@ -593,8 +639,7 @@ static struct ov5642 *to_ov5642(const struct 
   i2c_client
   *client) }
   
/* Find a data format by a pixel code in an array */
   -static const struct ov5642_datafmt
   - *ov5642_find_datafmt(enum v4l2_mbus_pixelcode code)
   +static const struct ov5642_datafmt *ov5642_find_datafmt(enum
   v4l2_mbus_pixelcode code) {
  
  checkpatch.pl won't be happy.
 
 Since the lift of the hard 80-char limit, I often find lines of 86 characters 
 more acceptable than their split versions.

It's not lifted, and it's still a rule. It's only that exceptions are
nowadays allowed to that rule where they make sense.

   @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev *sd,
   
 ov5642_try_fmt(sd, mf);
   
   + priv-out_size.width= mf-width;
   + priv-out_size.height   = mf-height;
  
  It looks like to me (but I may be wrong) that you achieve different 
  resolutions using cropping, not scaling. If that's correct you should 
  implement s_crop support and refuse changing the resolution through s_fmt.
 
 As the patch explains (I think) on several occasions, currently only the 
 1:1 scale is supported, and it was our deliberate choice to implement this 
 using the scaling API

As there is a subdev op to implement crop (s_crop) it should be used instead.
Otherwise any application thinks that the hardware can actually do scaling
but instead it crops. The above looks like gross misuse of the API to me.

Is there any particular reason why you think it should be implemented this
way?

-- 
Sakari Ailus
sakari.ai...@iki.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: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

Hi Guennadi,

On Tuesday 30 August 2011 10:55:08 Guennadi Liakhovetski wrote:
 On Mon, 29 Aug 2011, Laurent Pinchart wrote:
  On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
   On Mon, 29 Aug 2011, Laurent Pinchart wrote:
On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
 On Sun, 28 Aug 2011, Laurent Pinchart wrote:
 
 [snip]
 
   @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct
   v4l2_subdev *sd,
   
 ov5642_try_fmt(sd, mf);
   
   + priv-out_size.width= mf-width;
   + priv-out_size.height   = mf-height;
  
  It looks like to me (but I may be wrong) that you achieve
  different resolutions using cropping, not scaling. If that's
  correct you should implement s_crop support and refuse changing
  the resolution through s_fmt.
 
 As the patch explains (I think) on several occasions, currently
 only the 1:1 scale is supported, and it was our deliberate choice
 to implement this using the scaling API

If you implement cropping, you should use the crop API, not the
scaling API

:-)
   
   It's changing both - input and output sizes.
  
  Sure, but it's still cropping.
 
 Why? Isn't it a matter of the PoV?

No it isn't. Cropping is cropping, regardless of how you look at it.

 It changes the output window, i.e., implements S_FMT. And S_FMT is by far
 more important / widely used than S_CROP. Refusing to change the output
 window and always just returning the == crop size wouldn't be polite, IMHO.

If your sensor has no scaler the output size is equal to the crop rectangle. 
There's no way around that, and there's no reason to have the driver behave 
otherwise.

 Don't think many users would guess to use S_CROP.

Users who want to crop use S_CROP.

 Standard applications a la mplayer don't use S_CROP at all.

That's because they don't want to crop. mplayer expects the driver to perform 
scaling when it calls S_FMT, and users won't be happy if you crop instead.

-- 
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: Usb digital TV

2011-08-30 Thread Gabriel Sartori

Thank you Allan!

  Did this device that you use works in 1-seg? I think it is just full-seg!

  Using the Siano based device I tried a better antenna and still
cannot scan channels.
  I also tried the patches from Mauro and modified the device firmware
to isdbt_nova_12mhz_b0.inp forcing it to use mode 6!
  But it did not work either.

  In my Windows machine it worked without any problem.

  I really don't have much more options.

Thanks in advance!

2011/8/29 Alan Carvalho de Assis acas...@gmail.com:
 Hi Gabriel,

 On 8/29/11, Gabriel Sartori gabriel.sart...@gmail.com wrote:
 It there some devices that has more chance to work on a 2.6.35 kernel
 version so I can just cross compile the driver to my mx28 board in a
 easier way?

 Thanks in advance.


 I suggest you using a device based on dib0700, I got it working on
 Linux = 2.6.35:
 https://acassis.wordpress.com/2009/09/18/watching-digital-tv-sbtvd-in-the-linux/

 This same device working on i-MXT (Android 2.2 with Linux kernel 2.6.35):
 http://holoscopio.com/misc/androidtv/

 Best Regards,

 Alan

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

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

(also replying to a similar comment by Sakari)

On Tue, 30 Aug 2011, Laurent Pinchart wrote:

 Hi Guennadi,
 
 On Tuesday 30 August 2011 10:55:08 Guennadi Liakhovetski wrote:
  On Mon, 29 Aug 2011, Laurent Pinchart wrote:
   On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
On Mon, 29 Aug 2011, Laurent Pinchart wrote:
 On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
  On Sun, 28 Aug 2011, Laurent Pinchart wrote:
  
  [snip]
  
@@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct
v4l2_subdev *sd,

ov5642_try_fmt(sd, mf);

+   priv-out_size.width= mf-width;
+   priv-out_size.height   = mf-height;
   
   It looks like to me (but I may be wrong) that you achieve
   different resolutions using cropping, not scaling. If that's
   correct you should implement s_crop support and refuse changing
   the resolution through s_fmt.
  
  As the patch explains (I think) on several occasions, currently
  only the 1:1 scale is supported, and it was our deliberate choice
  to implement this using the scaling API
 
 If you implement cropping, you should use the crop API, not the
 scaling API
 
 :-)

It's changing both - input and output sizes.
   
   Sure, but it's still cropping.
  
  Why? Isn't it a matter of the PoV?
 
 No it isn't. Cropping is cropping, regardless of how you look at it.
 
  It changes the output window, i.e., implements S_FMT. And S_FMT is by far
  more important / widely used than S_CROP. Refusing to change the output
  window and always just returning the == crop size wouldn't be polite, IMHO.
 
 If your sensor has no scaler the output size is equal to the crop rectangle. 
 There's no way around that, and there's no reason to have the driver behave 
 otherwise.
 
  Don't think many users would guess to use S_CROP.
 
 Users who want to crop use S_CROP.
 
  Standard applications a la mplayer don't use S_CROP at all.
 
 That's because they don't want to crop. mplayer expects the driver to perform 
 scaling when it calls S_FMT, and users won't be happy if you crop instead.

So, here's my opinion, based on the V4L2 spec. I'm going to base on this 
and pull this patch into my tree and let Mauro decide, unless he expresses 
his negative opinion before that.

The spec defines S_FMT as an operation to set the output (in case of a 
capture device) frame format. Which this driver clearly does. The output 
format should be set, using scaling, however, if the driver or the 
hardware are unable to preserve the exact same input rectangle to satisfy 
the request, the driver is also allowed to change the cropping rectangle 
_as much as necessary_ - S_FMT takes precedence. This has been discussed 
before, and the conclusion was - of the two geometry calls (S_FMT and 
S_CROP) the last call overrides previous setting of the opposite geometry.

It also defines S_CROP as an operation to set the cropping rectangle. The 
driver is also allowed to change the output window, if it cannot be 
preserved. Similarly, the last call wins.

Ideally in this situation I would implement both S_CROP and S_FMT and let 
both change the opposite window as needed, which in this case means set it 
equal to the one, being configured. Since most applications are primarily 
interested in the S_FMT call to configure their user interface, I find it 
a wrong approach to refuse S_FMT and always return the current cropping 
rectangle. In such a case the application will possibly be stuck with some 
default output rectangle, because it certainly will _not_ guess to use 
S_CROP to configure it. Whereas if we implement S_FMT with a constant 1:1 
scale the application will get the required UI size. I agree, that 
changing the view area, while changing the output window, is not exactly 
what the user expects, but it's better than presenting all applications 
with a fixed, possibly completely unsuitable, UI window.

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

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

Hi Mauro,

Could you please comment on this ? In a nutshell (and from my biased point of 
view), the question is can cropping be configured using S_FMT instead of 
S_CROP ?. The answer is of course no :-)

On Tuesday 30 August 2011 15:13:25 Guennadi Liakhovetski wrote:
 On Tue, 30 Aug 2011, Laurent Pinchart wrote:
  On Tuesday 30 August 2011 10:55:08 Guennadi Liakhovetski wrote:
   On Mon, 29 Aug 2011, Laurent Pinchart wrote:
On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
 On Mon, 29 Aug 2011, Laurent Pinchart wrote:
  On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
   On Sun, 28 Aug 2011, Laurent Pinchart wrote:
   
   [snip]
   
 @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct
 v4l2_subdev *sd,
 
   ov5642_try_fmt(sd, mf);
 
 + priv-out_size.width= mf-width;
 + priv-out_size.height   = mf-height;

It looks like to me (but I may be wrong) that you achieve
different resolutions using cropping, not scaling. If that's
correct you should implement s_crop support and refuse
changing the resolution through s_fmt.
   
   As the patch explains (I think) on several occasions, currently
   only the 1:1 scale is supported, and it was our deliberate
   choice to implement this using the scaling API
  
  If you implement cropping, you should use the crop API, not the
  scaling API
  
  :-)
 
 It's changing both - input and output sizes.

Sure, but it's still cropping.
   
   Why? Isn't it a matter of the PoV?
  
  No it isn't. Cropping is cropping, regardless of how you look at it.
  
   It changes the output window, i.e., implements S_FMT. And S_FMT is by
   far more important / widely used than S_CROP. Refusing to change the
   output window and always just returning the == crop size wouldn't be
   polite, IMHO.
  
  If your sensor has no scaler the output size is equal to the crop
  rectangle. There's no way around that, and there's no reason to have the
  driver behave otherwise.
  
   Don't think many users would guess to use S_CROP.
  
  Users who want to crop use S_CROP.
  
   Standard applications a la mplayer don't use S_CROP at all.
  
  That's because they don't want to crop. mplayer expects the driver to
  perform scaling when it calls S_FMT, and users won't be happy if you
  crop instead.
 
 So, here's my opinion, based on the V4L2 spec. I'm going to base on this
 and pull this patch into my tree and let Mauro decide, unless he expresses
 his negative opinion before that.
 
 The spec defines S_FMT as an operation to set the output (in case of a
 capture device) frame format. Which this driver clearly does. The output
 format should be set, using scaling, however, if the driver or the
 hardware are unable to preserve the exact same input rectangle to satisfy
 the request, the driver is also allowed to change the cropping rectangle
 _as much as necessary_ - S_FMT takes precedence. This has been discussed
 before, and the conclusion was - of the two geometry calls (S_FMT and
 S_CROP) the last call overrides previous setting of the opposite geometry.
 
 It also defines S_CROP as an operation to set the cropping rectangle. The
 driver is also allowed to change the output window, if it cannot be
 preserved. Similarly, the last call wins.
 
 Ideally in this situation I would implement both S_CROP and S_FMT and let
 both change the opposite window as needed, which in this case means set it
 equal to the one, being configured. Since most applications are primarily
 interested in the S_FMT call to configure their user interface, I find it
 a wrong approach to refuse S_FMT and always return the current cropping
 rectangle. In such a case the application will possibly be stuck with some
 default output rectangle, because it certainly will _not_ guess to use
 S_CROP to configure it. Whereas if we implement S_FMT with a constant 1:1
 scale the application will get the required UI size. I agree, that
 changing the view area, while changing the output window, is not exactly
 what the user expects, but it's better than presenting all applications
 with a fixed, possibly completely unsuitable, UI window.

-- 
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] media: Add support for arbitrary resolution for the ov5642 camera driver

Hi Guennadi,

On Tuesday 30 August 2011 15:13:25 Guennadi Liakhovetski wrote:
 On Tue, 30 Aug 2011, Laurent Pinchart wrote:
  On Tuesday 30 August 2011 10:55:08 Guennadi Liakhovetski wrote:
   On Mon, 29 Aug 2011, Laurent Pinchart wrote:
On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
 On Mon, 29 Aug 2011, Laurent Pinchart wrote:
  On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
   On Sun, 28 Aug 2011, Laurent Pinchart wrote:
   
   [snip]
   
 @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct
 v4l2_subdev *sd,
 
   ov5642_try_fmt(sd, mf);
 
 + priv-out_size.width= mf-width;
 + priv-out_size.height   = mf-height;

It looks like to me (but I may be wrong) that you achieve
different resolutions using cropping, not scaling. If that's
correct you should implement s_crop support and refuse
changing the resolution through s_fmt.
   
   As the patch explains (I think) on several occasions, currently
   only the 1:1 scale is supported, and it was our deliberate
   choice to implement this using the scaling API
  
  If you implement cropping, you should use the crop API, not the
  scaling API
  
  :-)
 
 It's changing both - input and output sizes.

Sure, but it's still cropping.
   
   Why? Isn't it a matter of the PoV?
  
  No it isn't. Cropping is cropping, regardless of how you look at it.
  
   It changes the output window, i.e., implements S_FMT. And S_FMT is by
   far more important / widely used than S_CROP. Refusing to change the
   output window and always just returning the == crop size wouldn't be
   polite, IMHO.
  
  If your sensor has no scaler the output size is equal to the crop
  rectangle. There's no way around that, and there's no reason to have the
  driver behave otherwise.
  
   Don't think many users would guess to use S_CROP.
  
  Users who want to crop use S_CROP.
  
   Standard applications a la mplayer don't use S_CROP at all.
  
  That's because they don't want to crop. mplayer expects the driver to
  perform scaling when it calls S_FMT, and users won't be happy if you
  crop instead.
 
 So, here's my opinion, based on the V4L2 spec. I'm going to base on this
 and pull this patch into my tree and let Mauro decide, unless he expresses
 his negative opinion before that.

I've also made other comments. I expect at least a v2 that addresses them.

-- 
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: Usb digital TV

2011-08-30 Thread Alan Carvalho de Assis

Hi Gabriel,

On 8/30/11, Gabriel Sartori gabriel.sart...@gmail.com wrote:
 Thank you Allan!

   Did this device that you use works in 1-seg? I think it is just full-seg!


Yes, it support both: 1-seg and full-seg.

In our device we use only 1-seg because your processor cannot decode full-seg.

Best Regards,

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

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

On Tue, 30 Aug 2011, Laurent Pinchart wrote:

 Hi Guennadi,
 
 On Tuesday 30 August 2011 15:13:25 Guennadi Liakhovetski wrote:
  On Tue, 30 Aug 2011, Laurent Pinchart wrote:
   On Tuesday 30 August 2011 10:55:08 Guennadi Liakhovetski wrote:
On Mon, 29 Aug 2011, Laurent Pinchart wrote:
 On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
  On Mon, 29 Aug 2011, Laurent Pinchart wrote:
   On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
On Sun, 28 Aug 2011, Laurent Pinchart wrote:

[snip]

  @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct
  v4l2_subdev *sd,
  
  ov5642_try_fmt(sd, mf);
  
  +   priv-out_size.width= mf-width;
  +   priv-out_size.height   = mf-height;
 
 It looks like to me (but I may be wrong) that you achieve
 different resolutions using cropping, not scaling. If that's
 correct you should implement s_crop support and refuse
 changing the resolution through s_fmt.

As the patch explains (I think) on several occasions, currently
only the 1:1 scale is supported, and it was our deliberate
choice to implement this using the scaling API
   
   If you implement cropping, you should use the crop API, not the
   scaling API
   
   :-)
  
  It's changing both - input and output sizes.
 
 Sure, but it's still cropping.

Why? Isn't it a matter of the PoV?
   
   No it isn't. Cropping is cropping, regardless of how you look at it.
   
It changes the output window, i.e., implements S_FMT. And S_FMT is by
far more important / widely used than S_CROP. Refusing to change the
output window and always just returning the == crop size wouldn't be
polite, IMHO.
   
   If your sensor has no scaler the output size is equal to the crop
   rectangle. There's no way around that, and there's no reason to have the
   driver behave otherwise.
   
Don't think many users would guess to use S_CROP.
   
   Users who want to crop use S_CROP.
   
Standard applications a la mplayer don't use S_CROP at all.
   
   That's because they don't want to crop. mplayer expects the driver to
   perform scaling when it calls S_FMT, and users won't be happy if you
   crop instead.
  
  So, here's my opinion, based on the V4L2 spec. I'm going to base on this
  and pull this patch into my tree and let Mauro decide, unless he expresses
  his negative opinion before that.
 
 I've also made other comments. I expect at least a v2 that addresses them.

Of course, (most of) your other comments are valid and they will be 
addressed.

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

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

2011-08-30 Thread Bastian Hecht

Hello Laurent and others,

2011/8/30 Laurent Pinchart laurent.pinch...@ideasonboard.com:
 Hi Guennadi,

 On Tuesday 30 August 2011 15:13:25 Guennadi Liakhovetski wrote:
 On Tue, 30 Aug 2011, Laurent Pinchart wrote:
  On Tuesday 30 August 2011 10:55:08 Guennadi Liakhovetski wrote:
   On Mon, 29 Aug 2011, Laurent Pinchart wrote:
On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
 On Mon, 29 Aug 2011, Laurent Pinchart wrote:
  On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
   On Sun, 28 Aug 2011, Laurent Pinchart wrote:
  
   [snip]
  
 @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct
 v4l2_subdev *sd,

       ov5642_try_fmt(sd, mf);

 +     priv-out_size.width            = mf-width;
 +     priv-out_size.height           = mf-height;
   
It looks like to me (but I may be wrong) that you achieve
different resolutions using cropping, not scaling. If that's
correct you should implement s_crop support and refuse
changing the resolution through s_fmt.
  
   As the patch explains (I think) on several occasions, currently
   only the 1:1 scale is supported, and it was our deliberate
   choice to implement this using the scaling API
 
  If you implement cropping, you should use the crop API, not the
  scaling API
 
  :-)

 It's changing both - input and output sizes.
   
Sure, but it's still cropping.
  
   Why? Isn't it a matter of the PoV?
 
  No it isn't. Cropping is cropping, regardless of how you look at it.
 
   It changes the output window, i.e., implements S_FMT. And S_FMT is by
   far more important / widely used than S_CROP. Refusing to change the
   output window and always just returning the == crop size wouldn't be
   polite, IMHO.
 
  If your sensor has no scaler the output size is equal to the crop
  rectangle. There's no way around that, and there's no reason to have the
  driver behave otherwise.
 
   Don't think many users would guess to use S_CROP.
 
  Users who want to crop use S_CROP.
 
   Standard applications a la mplayer don't use S_CROP at all.
 
  That's because they don't want to crop. mplayer expects the driver to
  perform scaling when it calls S_FMT, and users won't be happy if you
  crop instead.

 So, here's my opinion, based on the V4L2 spec. I'm going to base on this
 and pull this patch into my tree and let Mauro decide, unless he expresses
 his negative opinion before that.

 I've also made other comments. I expect at least a v2 that addresses them.

Being the author I should drop a note too, I guess. Currently I'm
working on all the comments and preparing a new set of patches. I will
of course either implement the suggestion or reply to it in 1 or 2
days.

As far as the cropping/scaling discussion is going on - I wait until
you agreed on something (what is probably not happening though ;)
before adressing it directly in the code. I don't have a real own
opinion here as I am too unexperienced. If the arguments are balanced
I would prefer leaving the code as it is :-)  but I'm open to change
it if necessary.

best regards,

 Bastian


 --
 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: [ANN] Meeting minutes of the Cambourne meeting

2011-08-30 Thread Mark Brown

On Tue, Aug 30, 2011 at 12:20:09AM +0200, Guennadi Liakhovetski wrote:
 On Mon, 29 Aug 2011, Laurent Pinchart wrote:

  My idea was to let the kernel register all devices based on the DT or board 
  code. When the V4L2 host/bridge driver gets registered, it will then call a 
  V4L2 core function with a list of subdevs it needs. The V4L2 core would 
  store 
  that information and react to bus notifier events to notify the V4L2 
  host/bridge driver when all subdevs are present. At that point the 
  host/bridge 
  driver will get hold of all the subdevs and call (probably through the V4L2 
  core) their .registered operation. That's where the subdevs will get access 
  to 
  their clock using clk_get().

 Correct me, if I'm wrong, but this seems to be the case of sensor (and 
 other i2c-client) drivers having to succeed their probe() methods without 
 being able to actually access the hardware?

The events should only be generated after the probe() has succeeded so
if the driver talks to the hardware then it can fail probe() if need be.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

On Tuesday, August 30, 2011 15:13:25 Guennadi Liakhovetski wrote:
 (also replying to a similar comment by Sakari)
 
 On Tue, 30 Aug 2011, Laurent Pinchart wrote:
 
  Hi Guennadi,
  
  On Tuesday 30 August 2011 10:55:08 Guennadi Liakhovetski wrote:
   On Mon, 29 Aug 2011, Laurent Pinchart wrote:
On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
 On Mon, 29 Aug 2011, Laurent Pinchart wrote:
  On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
   On Sun, 28 Aug 2011, Laurent Pinchart wrote:
   
   [snip]
   
 @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct
 v4l2_subdev *sd,
 
   ov5642_try_fmt(sd, mf);
 
 + priv-out_size.width= mf-width;
 + priv-out_size.height   = mf-height;

It looks like to me (but I may be wrong) that you achieve
different resolutions using cropping, not scaling. If that's
correct you should implement s_crop support and refuse 
changing
the resolution through s_fmt.
   
   As the patch explains (I think) on several occasions, currently
   only the 1:1 scale is supported, and it was our deliberate 
choice
   to implement this using the scaling API
  
  If you implement cropping, you should use the crop API, not the
  scaling API
  
  :-)
 
 It's changing both - input and output sizes.

Sure, but it's still cropping.
   
   Why? Isn't it a matter of the PoV?
  
  No it isn't. Cropping is cropping, regardless of how you look at it.
  
   It changes the output window, i.e., implements S_FMT. And S_FMT is by 
far
   more important / widely used than S_CROP. Refusing to change the output
   window and always just returning the == crop size wouldn't be polite, 
IMHO.
  
  If your sensor has no scaler the output size is equal to the crop 
rectangle. 
  There's no way around that, and there's no reason to have the driver 
behave 
  otherwise.
  
   Don't think many users would guess to use S_CROP.
  
  Users who want to crop use S_CROP.
  
   Standard applications a la mplayer don't use S_CROP at all.
  
  That's because they don't want to crop. mplayer expects the driver to 
perform 
  scaling when it calls S_FMT, and users won't be happy if you crop instead.
 
 So, here's my opinion, based on the V4L2 spec. I'm going to base on this 
 and pull this patch into my tree and let Mauro decide, unless he expresses 
 his negative opinion before that.
 
 The spec defines S_FMT as an operation to set the output (in case of a 
 capture device) frame format. Which this driver clearly does. The output 
 format should be set, using scaling, however, if the driver or the 
 hardware are unable to preserve the exact same input rectangle to satisfy 
 the request, the driver is also allowed to change the cropping rectangle 
 _as much as necessary_ - S_FMT takes precedence. This has been discussed 
 before, and the conclusion was - of the two geometry calls (S_FMT and 
 S_CROP) the last call overrides previous setting of the opposite geometry.
 
 It also defines S_CROP as an operation to set the cropping rectangle. The 
 driver is also allowed to change the output window, if it cannot be 
 preserved. Similarly, the last call wins.
 
 Ideally in this situation I would implement both S_CROP and S_FMT and let 
 both change the opposite window as needed, which in this case means set it 
 equal to the one, being configured. Since most applications are primarily 
 interested in the S_FMT call to configure their user interface, I find it 
 a wrong approach to refuse S_FMT and always return the current cropping 
 rectangle. In such a case the application will possibly be stuck with some 
 default output rectangle, because it certainly will _not_ guess to use 
 S_CROP to configure it. Whereas if we implement S_FMT with a constant 1:1 
 scale the application will get the required UI size. I agree, that 
 changing the view area, while changing the output window, is not exactly 
 what the user expects, but it's better than presenting all applications 
 with a fixed, possibly completely unsuitable, UI window.

The problem with S_FMT changing the crop rectangle (and I assume we are not
talking about small pixel tweaks to make the hardware happy) is that the
crop operation actually removes part of the frame. That's not something you
would expect S_FMT to do, ever. Such an operation has to be explicitly
requested by the user.

It's also why properly written applications (e.g. capture-example.c) has
code like this to reset the crop rectangle before starting streaming:

if (0 == xioctl(fd, VIDIOC_CROPCAP, cropcap)) {
crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
crop.c = cropcap.defrect; /* reset to default */

if (-1 == xioctl(fd, VIDIOC_S_CROP, crop)) {
switch (errno) {
case EINVAL:

Re: [ANN] Meeting minutes of the Cambourne meeting

2011-08-30 Thread Grant Likely

On Tue, Aug 30, 2011 at 02:41:48PM +0100, Mark Brown wrote:
 On Tue, Aug 30, 2011 at 12:20:09AM +0200, Guennadi Liakhovetski wrote:
  On Mon, 29 Aug 2011, Laurent Pinchart wrote:
 
   My idea was to let the kernel register all devices based on the DT or 
   board 
   code. When the V4L2 host/bridge driver gets registered, it will then call 
   a 
   V4L2 core function with a list of subdevs it needs. The V4L2 core would 
   store 
   that information and react to bus notifier events to notify the V4L2 
   host/bridge driver when all subdevs are present. At that point the 
   host/bridge 

Sounds a lot like what ASoC is currently doing.

   driver will get hold of all the subdevs and call (probably through the 
   V4L2 
   core) their .registered operation. That's where the subdevs will get 
   access to 
   their clock using clk_get().
 
  Correct me, if I'm wrong, but this seems to be the case of sensor (and 
  other i2c-client) drivers having to succeed their probe() methods without 
  being able to actually access the hardware?

It indeed sounds like that, which also concerns me.  ASoC and other
subsystems have exactly the same problem where the 'device' is
actually an aggregate of multiple devices attached to different
busses.  My personal opinion is that the best way to handle this is to
support deferred probing so that a driver can fail with -EAGAIN if all
the resources that it requires are not available immediately, and have
the driver core retry the probe after other devices have successfully
probed.

I've got prototype code for this, but it needs some more work before
being mainlined.

 The events should only be generated after the probe() has succeeded so
 if the driver talks to the hardware then it can fail probe() if need be.

I'm a bit confused here.  Which events are you referring to, and which
.probe call? (the i2c/spi/whatever probe, or the aggregate v4l2 probe?)

--
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: [ANN] Meeting minutes of the Cambourne meeting

Hi Grant

On Tue, 30 Aug 2011, Grant Likely wrote:

 On Tue, Aug 30, 2011 at 02:41:48PM +0100, Mark Brown wrote:
  On Tue, Aug 30, 2011 at 12:20:09AM +0200, Guennadi Liakhovetski wrote:
   On Mon, 29 Aug 2011, Laurent Pinchart wrote:
  
My idea was to let the kernel register all devices based on the DT or 
board 
code. When the V4L2 host/bridge driver gets registered, it will then 
call a 
V4L2 core function with a list of subdevs it needs. The V4L2 core would 
store 
that information and react to bus notifier events to notify the V4L2 
host/bridge driver when all subdevs are present. At that point the 
host/bridge 
 
 Sounds a lot like what ASoC is currently doing.
 
driver will get hold of all the subdevs and call (probably through the 
V4L2 
core) their .registered operation. That's where the subdevs will get 
access to 
their clock using clk_get().
  
   Correct me, if I'm wrong, but this seems to be the case of sensor (and 
   other i2c-client) drivers having to succeed their probe() methods without 
   being able to actually access the hardware?
 
 It indeed sounds like that, which also concerns me.  ASoC and other
 subsystems have exactly the same problem where the 'device' is
 actually an aggregate of multiple devices attached to different
 busses.  My personal opinion is that the best way to handle this is to
 support deferred probing

Yes, that's also what I think should be done. But I was thinking about a 
slightly different approach - a dependency-based probing. I.e., you should 
be able to register a device, depending on another one (parent?), and only 
after the latter one has successfully probed, the driver core should be 
allowed to probe the child. Of course, devices can depend on multiple 
other devices, so, a single parent might not be enough.

Thanks
Guennadi

 so that a driver can fail with -EAGAIN if all
 the resources that it requires are not available immediately, and have
 the driver core retry the probe after other devices have successfully
 probed.
 
 I've got prototype code for this, but it needs some more work before
 being mainlined.
 
  The events should only be generated after the probe() has succeeded so
  if the driver talks to the hardware then it can fail probe() if need be.
 
 I'm a bit confused here.  Which events are you referring to, and which
 .probe call? (the i2c/spi/whatever probe, or the aggregate v4l2 probe?)
 

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

Re: Getting started with OMAP3 ISP


On 2011-08-29 04:49, Laurent Pinchart wrote:

Hi Gary,

On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background:  I have working video capture drivers based on the
TI PSP codebase from 2.6.32.  In particular, I managed to get
a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver
working with the rewritten ISP code.  Sadly, I'm having a hard
time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works
with the OMAP3 ISP code.  I've updated it to use my decoder device,
but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been
  registered.  I see a full set in /sys/class/video4linux
 # ls /sys/class/video4linux/
 v4l-subdev0  v4l-subdev3  v4l-subdev6  video1   video4
 v4l-subdev1  v4l-subdev4  v4l-subdev7  video2   video5
 v4l-subdev2  v4l-subdev5  video0   video3   video6


It looks like a udev issue. I don't think that's related to the kernel
drivers.


  Indeed, if I create /dev/videoX by hand, I can get somewhere, but
  I don't really understand how this is supposed to work.  e.g.
# v4l2-dbg --info /dev/video3
Driver info:
Driver name   : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info  : media
Driver version: 1
Capabilities  : 0x0402
Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but
  I never see it call down into my driver, e.g. to check the current
  format, etc.  I have some of my own code from before which fails
  miserably (not a big surprise given the hack level of those programs).
  I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning
much about what might be wrong.

Can someone give me some ideas/guidance, please?


In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and
then capture video.

Configuring the pipeline is done through the media controller API and the V4L2
subdev pad-level API. To experiment with those you can use the media-ctl
command line application available at http://git.ideasonboard.org/?p=media-
ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot
-Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a
sensor:

./media-ctl -r -l 'mt9t001 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP
CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP
resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
./media-ctl -f 'mt9t001 3-005d:0[SGRBG10 1024x768], OMAP3 ISP
CCDC:2[SGRBG10 1024x767], OMAP3 ISP preview:1[YUYV 1006x759], OMAP3 ISP
resizer:1[YUYV 800x600]'

After configuring your pipeline you will be able to capture video using the
V4L2 API on the device node at the output of the pipeline.


Thanks for the info.

When I run 'media-ctl -p', I see the various nodes, etc, and they all look
good except that I get lots of messages like this:
  - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
type V4L2 subdev subtype Unknown
pad0: Input v4l2_subdev_open: Failed to open subdev device node

When I try to setup my pipeline using something similar to what you provided, 
the
first step runs and I can see that it does something (some lines on the graph 
went
from dotted to solid), but I still get errors:
  # media-ctl -r -l 'tvp5150m1 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP 
CCDC:1-OMAP3 ISP CCDC output:0[1]'
  Resetting all links to inactive
  Setting up link 16:0 - 5:0 [1]
  Setting up link 5:1 - 6:0 [1]
  # media-ctl -f 'tvp5150m1 2-005c:0[SGRBG12 320x240], OMAP3 ISP CCDC:0[SGRBG8 
320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]'
  Setting up format SGRBG12 320x240 on pad tvp5150m1 2-005c/0
  v4l2_subdev_open: Failed to open subdev device node
  Unable to set format: No such file or directory (-2)

As far as I can tell, none if this is making any callbacks into my driver.

Any ideas what I might be missing?

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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: Getting started with OMAP3 ISP

Hi Gary,

On Tuesday 30 August 2011 16:18:00 Gary Thomas wrote:
 On 2011-08-30 08:08, Gary Thomas wrote:
  On 2011-08-29 04:49, Laurent Pinchart wrote:
  On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
  Background: I have working video capture drivers based on the
  TI PSP codebase from 2.6.32. In particular, I managed to get
  a driver for the TVP5150 (analogue BT656) working with that kernel.
  
  Now I need to update to Linux 3.0, so I'm trying to get a driver
  working with the rewritten ISP code. Sadly, I'm having a hard
  time with this - probably just missing something basic.
  
  I've tried to clone the TVP514x driver which says that it works
  with the OMAP3 ISP code. I've updated it to use my decoder device,
  but I can't even seem to get into that code from user land.
  
  Here are the problems I've had so far:
  * udev doesn't create any video devices although they have been
  registered. I see a full set in /sys/class/video4linux
  # ls /sys/class/video4linux/
  v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
  v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
  v4l-subdev2 v4l-subdev5 video0 video3 video6
  
  It looks like a udev issue. I don't think that's related to the kernel
  drivers.
  
  Indeed, if I create /dev/videoX by hand, I can get somewhere, but
  I don't really understand how this is supposed to work. e.g.
  # v4l2-dbg --info /dev/video3
  Driver info:
  Driver name : ispvideo
  Card type : OMAP3 ISP CCP2 input
  Bus info : media
  Driver version: 1
  Capabilities : 0x0402
  Video Output
  Streaming
  
  * If I try to grab video, the ISP layer gets a ton of warnings, but
  I never see it call down into my driver, e.g. to check the current
  format, etc. I have some of my own code from before which fails
  miserably (not a big surprise given the hack level of those programs).
  I tried something off-the-shelf which also fails pretty bad:
  # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
  junk.mp4
  
  I've read through Documentation/video4linux/omap3isp.txt without
  learning much about what might be wrong.
  
  Can someone give me some ideas/guidance, please?
  
  In a nutshell, you will first have to configure the OMAP3 ISP pipeline,
  and then capture video.
  
  Configuring the pipeline is done through the media controller API and
  the V4L2 subdev pad-level API. To experiment with those you can use the
  media-ctl command line application available at
  http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it
  with --print-dot and pipe the result to dot -Tps to get a postscript
  graphical view of your device.
  
  Here's a sample pipeline configuration to capture scaled-down YUV data
  from a sensor:
  
  ./media-ctl -r -l 'mt9t001 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP
  CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP
  resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
  ./media-ctl -f 'mt9t001 3-005d:0[SGRBG10 1024x768], OMAP3 ISP
  CCDC:2[SGRBG10 1024x767], OMAP3 ISP preview:1[YUYV 1006x759], OMAP3
  ISP resizer:1[YUYV 800x600]'
  
  After configuring your pipeline you will be able to capture video using
  the V4L2 API on the device node at the output of the pipeline.
  
  Thanks for the info.
  
  When I run 'media-ctl -p', I see the various nodes, etc, and they all
  look good except that I get lots of messages like this:
  - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
  type V4L2 subdev subtype Unknown
  pad0: Input v4l2_subdev_open: Failed to open subdev device node
 
 Could this be related to my missing [udev] device nodes?

It could be. You need the /dev/video* and /dev/v4l-subdev* device nodes.

 I can see media-ctl get confused and try to open a nonsense device name. 
 Here's what I see when I run
# strace media-ctl -p | grep open
open(/dev/media0, O_RDWR) = 3
open(, O_RDWR)= -1 ENOENT (No such file or
 directory) write(1, \tpad0: Input v4l2_subdev_open: F..., 66) = 66
 
  When I try to setup my pipeline using something similar to what you
  provided, the first step runs and I can see that it does something (some
  lines on the graph went from dotted to solid), but I still get errors:
  # media-ctl -r -l 'tvp5150m1 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3
  ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to
  inactive
  Setting up link 16:0 - 5:0 [1]
  Setting up link 5:1 - 6:0 [1]
  # media-ctl -f 'tvp5150m1 2-005c:0[SGRBG12 320x240], OMAP3 ISP
  CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' Setting up
  format SGRBG12 320x240 on pad tvp5150m1 2-005c/0
  v4l2_subdev_open: Failed to open subdev device node
  Unable to set format: No such file or directory (-2)
  
  As far as I can tell, none if this is making any callbacks into my
  driver.
  
  Any ideas what I might be missing?
  
  Thanks

-- 
Regards,

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

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

Hi Hans

On Tue, 30 Aug 2011, Hans Verkuil wrote:

 On Tuesday, August 30, 2011 15:13:25 Guennadi Liakhovetski wrote:
  (also replying to a similar comment by Sakari)
  
  On Tue, 30 Aug 2011, Laurent Pinchart wrote:
  
   Hi Guennadi,
   
   On Tuesday 30 August 2011 10:55:08 Guennadi Liakhovetski wrote:
On Mon, 29 Aug 2011, Laurent Pinchart wrote:
 On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
  On Mon, 29 Aug 2011, Laurent Pinchart wrote:
   On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
On Sun, 28 Aug 2011, Laurent Pinchart wrote:

[snip]

  @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct
  v4l2_subdev *sd,
  
  ov5642_try_fmt(sd, mf);
  
  +   priv-out_size.width= mf-width;
  +   priv-out_size.height   = mf-height;
 
 It looks like to me (but I may be wrong) that you achieve
 different resolutions using cropping, not scaling. If that's
 correct you should implement s_crop support and refuse 
 changing
 the resolution through s_fmt.

As the patch explains (I think) on several occasions, currently
only the 1:1 scale is supported, and it was our deliberate 
 choice
to implement this using the scaling API
   
   If you implement cropping, you should use the crop API, not the
   scaling API
   
   :-)
  
  It's changing both - input and output sizes.
 
 Sure, but it's still cropping.

Why? Isn't it a matter of the PoV?
   
   No it isn't. Cropping is cropping, regardless of how you look at it.
   
It changes the output window, i.e., implements S_FMT. And S_FMT is by 
 far
more important / widely used than S_CROP. Refusing to change the output
window and always just returning the == crop size wouldn't be polite, 
 IMHO.
   
   If your sensor has no scaler the output size is equal to the crop 
 rectangle. 
   There's no way around that, and there's no reason to have the driver 
 behave 
   otherwise.
   
Don't think many users would guess to use S_CROP.
   
   Users who want to crop use S_CROP.
   
Standard applications a la mplayer don't use S_CROP at all.
   
   That's because they don't want to crop. mplayer expects the driver to 
 perform 
   scaling when it calls S_FMT, and users won't be happy if you crop instead.
  
  So, here's my opinion, based on the V4L2 spec. I'm going to base on this 
  and pull this patch into my tree and let Mauro decide, unless he expresses 
  his negative opinion before that.
  
  The spec defines S_FMT as an operation to set the output (in case of a 
  capture device) frame format. Which this driver clearly does. The output 
  format should be set, using scaling, however, if the driver or the 
  hardware are unable to preserve the exact same input rectangle to satisfy 
  the request, the driver is also allowed to change the cropping rectangle 
  _as much as necessary_ - S_FMT takes precedence. This has been discussed 
  before, and the conclusion was - of the two geometry calls (S_FMT and 
  S_CROP) the last call overrides previous setting of the opposite geometry.
  
  It also defines S_CROP as an operation to set the cropping rectangle. The 
  driver is also allowed to change the output window, if it cannot be 
  preserved. Similarly, the last call wins.
  
  Ideally in this situation I would implement both S_CROP and S_FMT and let 
  both change the opposite window as needed, which in this case means set it 
  equal to the one, being configured. Since most applications are primarily 
  interested in the S_FMT call to configure their user interface, I find it 
  a wrong approach to refuse S_FMT and always return the current cropping 
  rectangle. In such a case the application will possibly be stuck with some 
  default output rectangle, because it certainly will _not_ guess to use 
  S_CROP to configure it. Whereas if we implement S_FMT with a constant 1:1 
  scale the application will get the required UI size. I agree, that 
  changing the view area, while changing the output window, is not exactly 
  what the user expects, but it's better than presenting all applications 
  with a fixed, possibly completely unsuitable, UI window.
 
 The problem with S_FMT changing the crop rectangle (and I assume we are not
 talking about small pixel tweaks to make the hardware happy) is that the
 crop operation actually removes part of the frame. That's not something you
 would expect S_FMT to do, ever. Such an operation has to be explicitly
 requested by the user.
 
 It's also why properly written applications (e.g. capture-example.c) has
 code like this to reset the crop rectangle before starting streaming:
 
 if (0 == xioctl(fd, VIDIOC_CROPCAP, cropcap)) {
 crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 crop.c = cropcap.defrect; /* reset to default

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

On Tuesday, August 30, 2011 16:24:55 Guennadi Liakhovetski wrote:
 Hi Hans
 
 On Tue, 30 Aug 2011, Hans Verkuil wrote:
 
  On Tuesday, August 30, 2011 15:13:25 Guennadi Liakhovetski wrote:
   (also replying to a similar comment by Sakari)
   
   On Tue, 30 Aug 2011, Laurent Pinchart wrote:
   
Hi Guennadi,

On Tuesday 30 August 2011 10:55:08 Guennadi Liakhovetski wrote:
 On Mon, 29 Aug 2011, Laurent Pinchart wrote:
  On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
   On Mon, 29 Aug 2011, Laurent Pinchart wrote:
On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
 On Sun, 28 Aug 2011, Laurent Pinchart wrote:
 
 [snip]
 
   @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct
   v4l2_subdev *sd,
   
 ov5642_try_fmt(sd, mf);
   
   + priv-out_size.width= mf-width;
   + priv-out_size.height   = mf-height;
  
  It looks like to me (but I may be wrong) that you achieve
  different resolutions using cropping, not scaling. If 
that's
  correct you should implement s_crop support and refuse 
  changing
  the resolution through s_fmt.
 
 As the patch explains (I think) on several occasions, 
currently
 only the 1:1 scale is supported, and it was our deliberate 
  choice
 to implement this using the scaling API

If you implement cropping, you should use the crop API, not 
the
scaling API

:-)
   
   It's changing both - input and output sizes.
  
  Sure, but it's still cropping.
 
 Why? Isn't it a matter of the PoV?

No it isn't. Cropping is cropping, regardless of how you look at it.

 It changes the output window, i.e., implements S_FMT. And S_FMT is 
by 
  far
 more important / widely used than S_CROP. Refusing to change the 
output
 window and always just returning the == crop size wouldn't be 
polite, 
  IMHO.

If your sensor has no scaler the output size is equal to the crop 
  rectangle. 
There's no way around that, and there's no reason to have the driver 
  behave 
otherwise.

 Don't think many users would guess to use S_CROP.

Users who want to crop use S_CROP.

 Standard applications a la mplayer don't use S_CROP at all.

That's because they don't want to crop. mplayer expects the driver to 
  perform 
scaling when it calls S_FMT, and users won't be happy if you crop 
instead.
   
   So, here's my opinion, based on the V4L2 spec. I'm going to base on this 
   and pull this patch into my tree and let Mauro decide, unless he 
expresses 
   his negative opinion before that.
   
   The spec defines S_FMT as an operation to set the output (in case of a 
   capture device) frame format. Which this driver clearly does. The output 
   format should be set, using scaling, however, if the driver or the 
   hardware are unable to preserve the exact same input rectangle to 
satisfy 
   the request, the driver is also allowed to change the cropping rectangle 
   _as much as necessary_ - S_FMT takes precedence. This has been discussed 
   before, and the conclusion was - of the two geometry calls (S_FMT and 
   S_CROP) the last call overrides previous setting of the opposite 
geometry.
   
   It also defines S_CROP as an operation to set the cropping rectangle. 
The 
   driver is also allowed to change the output window, if it cannot be 
   preserved. Similarly, the last call wins.
   
   Ideally in this situation I would implement both S_CROP and S_FMT and 
let 
   both change the opposite window as needed, which in this case means set 
it 
   equal to the one, being configured. Since most applications are 
primarily 
   interested in the S_FMT call to configure their user interface, I find 
it 
   a wrong approach to refuse S_FMT and always return the current cropping 
   rectangle. In such a case the application will possibly be stuck with 
some 
   default output rectangle, because it certainly will _not_ guess to use 
   S_CROP to configure it. Whereas if we implement S_FMT with a constant 
1:1 
   scale the application will get the required UI size. I agree, that 
   changing the view area, while changing the output window, is not exactly 
   what the user expects, but it's better than presenting all applications 
   with a fixed, possibly completely unsuitable, UI window.
  
  The problem with S_FMT changing the crop rectangle (and I assume we are 
not
  talking about small pixel tweaks to make the hardware happy) is that the
  crop operation actually removes part of the frame. That's not something 
you
  would expect S_FMT to do, ever. Such an operation has to be explicitly
  requested by the user.
  
  It's also why properly written applications (e.g. capture-example.c) has
  code like this to reset the crop rectangle before starting

Re: Getting started with OMAP3 ISP


On 2011-08-30 08:20, Laurent Pinchart wrote:

Hi Gary,

On Tuesday 30 August 2011 16:18:00 Gary Thomas wrote:

On 2011-08-30 08:08, Gary Thomas wrote:

On 2011-08-29 04:49, Laurent Pinchart wrote:

On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background: I have working video capture drivers based on the
TI PSP codebase from 2.6.32. In particular, I managed to get
a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver
working with the rewritten ISP code. Sadly, I'm having a hard
time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works
with the OMAP3 ISP code. I've updated it to use my decoder device,
but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been
registered. I see a full set in /sys/class/video4linux
# ls /sys/class/video4linux/
v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4
v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5
v4l-subdev2 v4l-subdev5 video0 video3 video6


It looks like a udev issue. I don't think that's related to the kernel
drivers.


Indeed, if I create /dev/videoX by hand, I can get somewhere, but
I don't really understand how this is supposed to work. e.g.
# v4l2-dbg --info /dev/video3
Driver info:
Driver name : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info : media
Driver version: 1
Capabilities : 0x0402
Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but
I never see it call down into my driver, e.g. to check the current
format, etc. I have some of my own code from before which fails
miserably (not a big surprise given the hack level of those programs).
I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without
learning much about what might be wrong.

Can someone give me some ideas/guidance, please?


In a nutshell, you will first have to configure the OMAP3 ISP pipeline,
and then capture video.

Configuring the pipeline is done through the media controller API and
the V4L2 subdev pad-level API. To experiment with those you can use the
media-ctl command line application available at
http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it
with --print-dot and pipe the result to dot -Tps to get a postscript
graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data
from a sensor:

./media-ctl -r -l 'mt9t001 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP
CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP
resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
./media-ctl -f 'mt9t001 3-005d:0[SGRBG10 1024x768], OMAP3 ISP
CCDC:2[SGRBG10 1024x767], OMAP3 ISP preview:1[YUYV 1006x759], OMAP3
ISP resizer:1[YUYV 800x600]'

After configuring your pipeline you will be able to capture video using
the V4L2 API on the device node at the output of the pipeline.


Thanks for the info.

When I run 'media-ctl -p', I see the various nodes, etc, and they all
look good except that I get lots of messages like this:
- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
type V4L2 subdev subtype Unknown
pad0: Input v4l2_subdev_open: Failed to open subdev device node


Could this be related to my missing [udev] device nodes?


It could be. You need the /dev/video* and /dev/v4l-subdev* device nodes.


Yes, that helped a lot.  When I create the devices by hand, I can now see
my driver starting to be accessed (right now it's very much an empty stub)

Any ideas why udev (version 164) is not making these nodes automatically?




I can see media-ctl get confused and try to open a nonsense device name.
Here's what I see when I run
# strace media-ctl -p | grep open
open(/dev/media0, O_RDWR) = 3
open(, O_RDWR)= -1 ENOENT (No such file or
directory) write(1, \tpad0: Input v4l2_subdev_open: F..., 66) = 66


When I try to setup my pipeline using something similar to what you
provided, the first step runs and I can see that it does something (some
lines on the graph went from dotted to solid), but I still get errors:
# media-ctl -r -l 'tvp5150m1 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to
inactive
Setting up link 16:0 -  5:0 [1]
Setting up link 5:1 -  6:0 [1]
# media-ctl -f 'tvp5150m1 2-005c:0[SGRBG12 320x240], OMAP3 ISP
CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]' Setting up
format SGRBG12 320x240 on pad tvp5150m1 2-005c/0
v4l2_subdev_open: Failed to open subdev device node
Unable to set format: No such file or directory (-2)

As far as I can tell, none if this is making any callbacks into my
driver.

Any ideas what I might be missing?

Thanks




--

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

On Tue, 30 Aug 2011, Hans Verkuil wrote:

 On Tuesday, August 30, 2011 16:24:55 Guennadi Liakhovetski wrote:
  Hi Hans
  
  On Tue, 30 Aug 2011, Hans Verkuil wrote:

[snip]

   The problem with S_FMT changing the crop rectangle (and I assume we are 
   not
   talking about small pixel tweaks to make the hardware happy) is that the
   crop operation actually removes part of the frame. That's not something 
   you
   would expect S_FMT to do, ever. Such an operation has to be explicitly
   requested by the user.
   
   It's also why properly written applications (e.g. capture-example.c) has
   code like this to reset the crop rectangle before starting streaming:
   
   if (0 == xioctl(fd, VIDIOC_CROPCAP, cropcap)) {
   crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
   crop.c = cropcap.defrect; /* reset to default */
   
   if (-1 == xioctl(fd, VIDIOC_S_CROP, crop)) {
   switch (errno) {
   case EINVAL:
   /* Cropping not supported. */
   break;
   default:
   /* Errors ignored. */
   break;
   }
   }
   }
   
   (Hmm, capture-example.c should also test for ENOTTY since we changed the
   error code).
  
  I agree, that preserving input rectangle == output rectangle in reply to 
  S_FMT is not nice, and should be avoided, wherever possible. Still, I 
  prefer this to sticking with just one fixed output geometry, especially 
  since (1) the spec doesn't prohibit this behaviour,
 
 Hmm, I think it should be prohibited. Few drivers actually implement crop,
 and fewer applications use it. So I'm not surprised the spec doesn't go into 
 much detail.
 
  (2) there are already 
  precedents in the mainline.
 
 Which precedents? My guess is that any driver that does this was either not
 (or poorly) reviewed, or everyone just missed it.

My first two sensor drivers mt9m001 and mt9v022 do this, but, I suspect, I 
didn't invent it at that time, I think, I copied it from somewhere, cannot 
say for sure though anymore.

  Maybe, a bit of hardware background would help: the sensor is actually 
  supposed to be able to both crop and scale, and we did try to implement 
  scales other than 1:1, but the chip just refused to produce anything 
  meaningful.
 
 I still don't see any reason why S_FMT would suddenly crop on such a sensor.
 It's completely unexpected and the user does not get what he expects.

Good, let's make it simple for all (except Bastian) then: Bastian, sorry 
for having misguided you, please, switch to .s_crop().

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

[PATCH v4] s5p-fimc: Add runtime PM support in the mem-to-mem driver

2011-08-30 Thread Sylwester Nawrocki

Add runtime PM and system sleep support in the memory-to-memory driver.
This is required to enable the device operation on Exynos4 SoCs. This patch
prevents system boot failure when the driver is compiled in, as it now
tries to access its I/O memory without first enabling the corresponding
power domain.

The camera capture device suspend/resume is not fully covered,
the capture device is just powered on/off during the video node
open/close. However this enables it's normal operation on Exynos4 SoCs.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---

I'm resending this patch after few minor changes since v3:
 - added the driver dependency on PM_RUNTIME
 - corrected the error path in probe() 
 - s/*_in_use/_busy
 - edited the commit message

---
 drivers/media/video/Kconfig |2 +-
 drivers/media/video/s5p-fimc/fimc-capture.c |   18 ++
 drivers/media/video/s5p-fimc/fimc-core.c|  279 ---
 drivers/media/video/s5p-fimc/fimc-core.h|   16 +-
 drivers/media/video/s5p-fimc/fimc-reg.c |2 +-
 5 files changed, 237 insertions(+), 80 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f574dc0..14326d7 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -950,7 +950,7 @@ config VIDEO_MX2
 
 config  VIDEO_SAMSUNG_S5P_FIMC
tristate Samsung S5P and EXYNOS4 camera host interface driver
-   depends on VIDEO_DEV  VIDEO_V4L2  PLAT_S5P
+   depends on VIDEO_V4L2  PLAT_S5P  PM_RUNTIME
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
---help---
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c 
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 0d730e5..ea74e4b 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -17,6 +17,7 @@
 #include linux/interrupt.h
 #include linux/device.h
 #include linux/platform_device.h
+#include linux/pm_runtime.h
 #include linux/list.h
 #include linux/slab.h
 #include linux/clk.h
@@ -196,6 +197,16 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
return 0;
 }
 
+int fimc_capture_suspend(struct fimc_dev *fimc)
+{
+   return -EBUSY;
+}
+
+int fimc_capture_resume(struct fimc_dev *fimc)
+{
+   return 0;
+}
+
 static int start_streaming(struct vb2_queue *q)
 {
struct fimc_ctx *ctx = q-drv_priv;
@@ -381,9 +392,14 @@ static int fimc_capture_open(struct file *file)
if (fimc_m2m_active(fimc))
return -EBUSY;
 
+   ret = pm_runtime_get_sync(fimc-pdev-dev);
+   if (ret)
+   return ret;
+
if (++fimc-vid_cap.refcnt == 1) {
ret = fimc_isp_subdev_init(fimc, 0);
if (ret) {
+   pm_runtime_put_sync(fimc-pdev-dev);
fimc-vid_cap.refcnt--;
return -EIO;
}
@@ -411,6 +427,8 @@ static int fimc_capture_close(struct file *file)
fimc_subdev_unregister(fimc);
}
 
+   pm_runtime_put_sync(fimc-pdev-dev);
+
return 0;
 }
 
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c 
b/drivers/media/video/s5p-fimc/fimc-core.c
index aa55066..7ca8091 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -18,6 +18,7 @@
 #include linux/interrupt.h
 #include linux/device.h
 #include linux/platform_device.h
+#include linux/pm_runtime.h
 #include linux/list.h
 #include linux/io.h
 #include linux/slab.h
@@ -301,7 +302,6 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx)
 static void fimc_m2m_job_finish(struct fimc_ctx *ctx, int vb_state)
 {
struct vb2_buffer *src_vb, *dst_vb;
-   struct fimc_dev *fimc = ctx-fimc_dev;
 
if (!ctx || !ctx-m2m_ctx)
return;
@@ -312,39 +312,48 @@ static void fimc_m2m_job_finish(struct fimc_ctx *ctx, int 
vb_state)
if (src_vb  dst_vb) {
v4l2_m2m_buf_done(src_vb, vb_state);
v4l2_m2m_buf_done(dst_vb, vb_state);
-   v4l2_m2m_job_finish(fimc-m2m.m2m_dev, ctx-m2m_ctx);
+   v4l2_m2m_job_finish(ctx-fimc_dev-m2m.m2m_dev,
+   ctx-m2m_ctx);
}
 }
 
 /* Complete the transaction which has been scheduled for execution. */
-static void fimc_m2m_shutdown(struct fimc_ctx *ctx)
+static int fimc_m2m_shutdown(struct fimc_ctx *ctx)
 {
struct fimc_dev *fimc = ctx-fimc_dev;
int ret;
 
if (!fimc_m2m_pending(fimc))
-   return;
+   return 0;
 
fimc_ctx_state_lock_set(FIMC_CTX_SHUT, ctx);
 
ret = wait_event_timeout(fimc-irq_queue,
   !fimc_ctx_state_is_set(FIMC_CTX_SHUT, ctx),
   FIMC_SHUTDOWN_TIMEOUT);
-   /*
-* In case of a timeout the buffers are not released in the interrupt
-* handler so return them here with

Re: [ANN] Meeting minutes of the Cambourne meeting

2011-08-30 Thread Grant Likely

On Tue, Aug 30, 2011 at 8:03 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 Hi Grant

 On Tue, 30 Aug 2011, Grant Likely wrote:

 On Tue, Aug 30, 2011 at 02:41:48PM +0100, Mark Brown wrote:
  On Tue, Aug 30, 2011 at 12:20:09AM +0200, Guennadi Liakhovetski wrote:
   On Mon, 29 Aug 2011, Laurent Pinchart wrote:
 
My idea was to let the kernel register all devices based on the DT or 
board
code. When the V4L2 host/bridge driver gets registered, it will then 
call a
V4L2 core function with a list of subdevs it needs. The V4L2 core 
would store
that information and react to bus notifier events to notify the V4L2
host/bridge driver when all subdevs are present. At that point the 
host/bridge

 Sounds a lot like what ASoC is currently doing.

driver will get hold of all the subdevs and call (probably through the 
V4L2
core) their .registered operation. That's where the subdevs will get 
access to
their clock using clk_get().
 
   Correct me, if I'm wrong, but this seems to be the case of sensor (and
   other i2c-client) drivers having to succeed their probe() methods without
   being able to actually access the hardware?

 It indeed sounds like that, which also concerns me.  ASoC and other
 subsystems have exactly the same problem where the 'device' is
 actually an aggregate of multiple devices attached to different
 busses.  My personal opinion is that the best way to handle this is to
 support deferred probing

 Yes, that's also what I think should be done. But I was thinking about a
 slightly different approach - a dependency-based probing. I.e., you should
 be able to register a device, depending on another one (parent?), and only
 after the latter one has successfully probed, the driver core should be
 allowed to probe the child. Of course, devices can depend on multiple
 other devices, so, a single parent might not be enough.

Yes, a dependency system would be lovely... but it gets really complex
in a hurry, especially when faced with heterogeneous device
registrations.  A deferral system ends up being really simple to
implement and probably work just as well.

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

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

2011-08-30 Thread Bastian Hecht

2011/8/30 Guennadi Liakhovetski g.liakhovet...@gmx.de:
 On Tue, 30 Aug 2011, Hans Verkuil wrote:

 On Tuesday, August 30, 2011 16:24:55 Guennadi Liakhovetski wrote:
  Hi Hans
 
  On Tue, 30 Aug 2011, Hans Verkuil wrote:

 [snip]

   The problem with S_FMT changing the crop rectangle (and I assume we are 
   not
   talking about small pixel tweaks to make the hardware happy) is that the
   crop operation actually removes part of the frame. That's not something 
   you
   would expect S_FMT to do, ever. Such an operation has to be explicitly
   requested by the user.
  
   It's also why properly written applications (e.g. capture-example.c) has
   code like this to reset the crop rectangle before starting streaming:
  
           if (0 == xioctl(fd, VIDIOC_CROPCAP, cropcap)) {
                   crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
                   crop.c = cropcap.defrect; /* reset to default */
  
                   if (-1 == xioctl(fd, VIDIOC_S_CROP, crop)) {
                           switch (errno) {
                           case EINVAL:
                                   /* Cropping not supported. */
                                   break;
                           default:
                                   /* Errors ignored. */
                                   break;
                           }
                   }
           }
  
   (Hmm, capture-example.c should also test for ENOTTY since we changed the
   error code).
 
  I agree, that preserving input rectangle == output rectangle in reply to
  S_FMT is not nice, and should be avoided, wherever possible. Still, I
  prefer this to sticking with just one fixed output geometry, especially
  since (1) the spec doesn't prohibit this behaviour,

 Hmm, I think it should be prohibited. Few drivers actually implement crop,
 and fewer applications use it. So I'm not surprised the spec doesn't go into
 much detail.

  (2) there are already
  precedents in the mainline.

 Which precedents? My guess is that any driver that does this was either not
 (or poorly) reviewed, or everyone just missed it.

 My first two sensor drivers mt9m001 and mt9v022 do this, but, I suspect, I
 didn't invent it at that time, I think, I copied it from somewhere, cannot
 say for sure though anymore.

  Maybe, a bit of hardware background would help: the sensor is actually
  supposed to be able to both crop and scale, and we did try to implement
  scales other than 1:1, but the chip just refused to produce anything
  meaningful.

 I still don't see any reason why S_FMT would suddenly crop on such a sensor.
 It's completely unexpected and the user does not get what he expects.

 Good, let's make it simple for all (except Bastian) then: Bastian, sorry
 for having misguided you, please, switch to .s_crop().

Sure, no problem. So s_fmt() shall be not available at all then,
right? Instead the cropping rectangle can be changed and the output
rectangle is adjusted accordingly.

best regards,

 Bastian

 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/

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

Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver

On Tue, 30 Aug 2011, Bastian Hecht wrote:

 2011/8/30 Guennadi Liakhovetski g.liakhovet...@gmx.de:
  On Tue, 30 Aug 2011, Hans Verkuil wrote:
 
  On Tuesday, August 30, 2011 16:24:55 Guennadi Liakhovetski wrote:
   Hi Hans
  
   On Tue, 30 Aug 2011, Hans Verkuil wrote:
 
  [snip]
 
The problem with S_FMT changing the crop rectangle (and I assume we 
are not
talking about small pixel tweaks to make the hardware happy) is that 
the
crop operation actually removes part of the frame. That's not 
something you
would expect S_FMT to do, ever. Such an operation has to be explicitly
requested by the user.
   
It's also why properly written applications (e.g. capture-example.c) 
has
code like this to reset the crop rectangle before starting streaming:
   
        if (0 == xioctl(fd, VIDIOC_CROPCAP, cropcap)) {
                crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
                crop.c = cropcap.defrect; /* reset to default */
   
                if (-1 == xioctl(fd, VIDIOC_S_CROP, crop)) {
                        switch (errno) {
                        case EINVAL:
                                /* Cropping not supported. */
                                break;
                        default:
                                /* Errors ignored. */
                                break;
                        }
                }
        }
   
(Hmm, capture-example.c should also test for ENOTTY since we changed 
the
error code).
  
   I agree, that preserving input rectangle == output rectangle in reply to
   S_FMT is not nice, and should be avoided, wherever possible. Still, I
   prefer this to sticking with just one fixed output geometry, especially
   since (1) the spec doesn't prohibit this behaviour,
 
  Hmm, I think it should be prohibited. Few drivers actually implement crop,
  and fewer applications use it. So I'm not surprised the spec doesn't go 
  into
  much detail.
 
   (2) there are already
   precedents in the mainline.
 
  Which precedents? My guess is that any driver that does this was either not
  (or poorly) reviewed, or everyone just missed it.
 
  My first two sensor drivers mt9m001 and mt9v022 do this, but, I suspect, I
  didn't invent it at that time, I think, I copied it from somewhere, cannot
  say for sure though anymore.
 
   Maybe, a bit of hardware background would help: the sensor is actually
   supposed to be able to both crop and scale, and we did try to implement
   scales other than 1:1, but the chip just refused to produce anything
   meaningful.
 
  I still don't see any reason why S_FMT would suddenly crop on such a 
  sensor.
  It's completely unexpected and the user does not get what he expects.
 
  Good, let's make it simple for all (except Bastian) then: Bastian, sorry
  for having misguided you, please, switch to .s_crop().
 
 Sure, no problem. So s_fmt() shall be not available at all then,
 right? Instead the cropping rectangle can be changed and the output
 rectangle is adjusted accordingly.

I would keep .s_fmt() and just return the current configuration from it.

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

Re: videobuf2 user pointer vma release seqeuence

2011-08-30 Thread Tang, Yu

Marek,

Thanks for the quick response and confirmation!  Will submit the patch tomorrow.

Regards,
Yu Tang
--
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: [ANN] Meeting minutes of the Cambourne meeting

On Tuesday 30 August 2011 17:18:31 Grant Likely wrote:
 On Tue, Aug 30, 2011 at 8:03 AM, Guennadi Liakhovetski
 
 g.liakhovet...@gmx.de wrote:
  Hi Grant
  
  On Tue, 30 Aug 2011, Grant Likely wrote:
  On Tue, Aug 30, 2011 at 02:41:48PM +0100, Mark Brown wrote:
   On Tue, Aug 30, 2011 at 12:20:09AM +0200, Guennadi Liakhovetski wrote:
On Mon, 29 Aug 2011, Laurent Pinchart wrote:
 My idea was to let the kernel register all devices based on the DT
 or board code. When the V4L2 host/bridge driver gets registered,
 it will then call a V4L2 core function with a list of subdevs it
 needs. The V4L2 core would store that information and react to
 bus notifier events to notify the V4L2 host/bridge driver when
 all subdevs are present. At that point the host/bridge
  
  Sounds a lot like what ASoC is currently doing.
  
 driver will get hold of all the subdevs and call (probably through
 the V4L2 core) their .registered operation. That's where the
 subdevs will get access to their clock using clk_get().

Correct me, if I'm wrong, but this seems to be the case of sensor
(and other i2c-client) drivers having to succeed their probe()
methods without being able to actually access the hardware?
  
  It indeed sounds like that, which also concerns me.  ASoC and other
  subsystems have exactly the same problem where the 'device' is
  actually an aggregate of multiple devices attached to different
  busses.  My personal opinion is that the best way to handle this is to
  support deferred probing
  
  Yes, that's also what I think should be done. But I was thinking about a
  slightly different approach - a dependency-based probing. I.e., you
  should be able to register a device, depending on another one (parent?),
  and only after the latter one has successfully probed, the driver core
  should be allowed to probe the child. Of course, devices can depend on
  multiple other devices, so, a single parent might not be enough.
 
 Yes, a dependency system would be lovely... but it gets really complex
 in a hurry, especially when faced with heterogeneous device
 registrations.  A deferral system ends up being really simple to
 implement and probably work just as well.

The core issue is that physical device trees, clock trees, power trees and 
logical device tress are not always aligned. Instanciating devices based on 
the parent-child device relationships will always lead to situations where a 
device probe() method will be called with clocks or power sources not 
available yet.

A dependency system is tempting but will be very complex to implement 
properly, especially when faced with cyclic dependencies. For instance the 
OMAP3 ISP driver requires the camera sensor device to be present to proceed, 
and the camera sensor requires a clock provided by the OMAP3 ISP. To solve 
this we need to probe the OMAP3 ISP first, have it register its clock devices, 
and then wait until all sensors become available.

A probe deferral system is probably simpler, but it will have its share of 
problems as well. In the above example, if the sensor is probed first, the 
driver can return -EAGAIN in the probe() method as the clock isn't available 
yet (I'm not sure how to differentiate between not available yet and not 
present in the system though). However, if the OMAP3 ISP is probed first, 
returning -EAGAIN in its probe() method won't really help, as we need to 
register the clock before waiting for the sensor.

-- 
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] media: Add support for arbitrary resolution for the ov5642 camera driver

Hi Guennadi,

On Tuesday 30 August 2011 17:34:05 Guennadi Liakhovetski wrote:
 On Tue, 30 Aug 2011, Bastian Hecht wrote:
  2011/8/30 Guennadi Liakhovetski g.liakhovet...@gmx.de:
   On Tue, 30 Aug 2011, Hans Verkuil wrote:
   On Tuesday, August 30, 2011 16:24:55 Guennadi Liakhovetski wrote:
Hi Hans
   
On Tue, 30 Aug 2011, Hans Verkuil wrote:
   [snip]
   
 The problem with S_FMT changing the crop rectangle (and I assume
 we are not talking about small pixel tweaks to make the hardware
 happy) is that the crop operation actually removes part of the
 frame. That's not something you would expect S_FMT to do, ever.
 Such an operation has to be explicitly requested by the user.
 
 It's also why properly written applications (e.g.
 capture-example.c) has code like this to reset the crop rectangle
 before starting streaming:
 
 if (0 == xioctl(fd, VIDIOC_CROPCAP, cropcap)) {
 crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 crop.c = cropcap.defrect; /* reset to default */
 
 if (-1 == xioctl(fd, VIDIOC_S_CROP, crop)) {
 switch (errno) {
 case EINVAL:
 /* Cropping not supported. */
 break;
 default:
 /* Errors ignored. */
 break;
 }
 }
 }
 
 (Hmm, capture-example.c should also test for ENOTTY since we
 changed the error code).

I agree, that preserving input rectangle == output rectangle in
reply to S_FMT is not nice, and should be avoided, wherever
possible. Still, I prefer this to sticking with just one fixed
output geometry, especially since (1) the spec doesn't prohibit
this behaviour,
   
   Hmm, I think it should be prohibited. Few drivers actually implement
   crop, and fewer applications use it. So I'm not surprised the spec
   doesn't go into much detail.
   
(2) there are already
precedents in the mainline.
   
   Which precedents? My guess is that any driver that does this was
   either not (or poorly) reviewed, or everyone just missed it.
   
   My first two sensor drivers mt9m001 and mt9v022 do this, but, I
   suspect, I didn't invent it at that time, I think, I copied it from
   somewhere, cannot say for sure though anymore.
   
Maybe, a bit of hardware background would help: the sensor is
actually supposed to be able to both crop and scale, and we did try
to implement scales other than 1:1, but the chip just refused to
produce anything meaningful.
   
   I still don't see any reason why S_FMT would suddenly crop on such a
   sensor. It's completely unexpected and the user does not get what he
   expects.
   
   Good, let's make it simple for all (except Bastian) then: Bastian,
   sorry for having misguided you, please, switch to .s_crop().
  
  Sure, no problem. So s_fmt() shall be not available at all then,
  right? Instead the cropping rectangle can be changed and the output
  rectangle is adjusted accordingly.
 
 I would keep .s_fmt() and just return the current configuration from it.

That's what I would do as well. Having no .s_fmt() would be very confusing for 
applications and/or bridges.

-- 
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: [ANN] Meeting minutes of the Cambourne meeting

2011-08-30 Thread Mark Brown

On Tue, Aug 30, 2011 at 05:42:55PM +0200, Laurent Pinchart wrote:

 A dependency system is tempting but will be very complex to implement 
 properly, especially when faced with cyclic dependencies. For instance the 
 OMAP3 ISP driver requires the camera sensor device to be present to proceed, 
 and the camera sensor requires a clock provided by the OMAP3 ISP. To solve 
 this we need to probe the OMAP3 ISP first, have it register its clock 
 devices, 
 and then wait until all sensors become available.

With composite devices like that where the borad has sufficient
interesting stuff on it representing the board itself as a device (this
is what ASoC does).

 A probe deferral system is probably simpler, but it will have its share of 
 problems as well. In the above example, if the sensor is probed first, the 
 driver can return -EAGAIN in the probe() method as the clock isn't available 
 yet (I'm not sure how to differentiate between not available yet and not 
 present in the system though). However, if the OMAP3 ISP is probed first, 
 returning -EAGAIN in its probe() method won't really help, as we need to 
 register the clock before waiting for the sensor.

Having a device for the camera subsystem as a whole breaks this loop as
the probe of that device triggers the overall system probe.
--
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: Getting started with OMAP3 ISP

Hi Gary,

On Tuesday 30 August 2011 16:56:11 Gary Thomas wrote:
 On 2011-08-30 08:20, Laurent Pinchart wrote:
  On Tuesday 30 August 2011 16:18:00 Gary Thomas wrote:
  On 2011-08-30 08:08, Gary Thomas wrote:

[snip]

  When I run 'media-ctl -p', I see the various nodes, etc, and they all
  look good except that I get lots of messages like this:
  - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
  type V4L2 subdev subtype Unknown
  pad0: Input v4l2_subdev_open: Failed to open subdev device node
  
  Could this be related to my missing [udev] device nodes?
  
  It could be. You need the /dev/video* and /dev/v4l-subdev* device nodes.
 
 Yes, that helped a lot.  When I create the devices by hand, I can now see
 my driver starting to be accessed (right now it's very much an empty stub)
 
 Any ideas why udev (version 164) is not making these nodes automatically?

I'm sorry, I don't. You're not the first person to report this though. It 
would be nice if you could explain how you solved the issue when you'll find 
the solution.

-- 
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: [ANN] Meeting minutes of the Cambourne meeting

On Tue, 30 Aug 2011, Laurent Pinchart wrote:

 A dependency system is tempting but will be very complex to implement 
 properly, especially when faced with cyclic dependencies. For instance the 
 OMAP3 ISP driver requires the camera sensor device to be present to proceed, 

Switching to a notifier instead of waiting in probe() might be a good idea 
(TM).

 and the camera sensor requires a clock provided by the OMAP3 ISP. To solve 
 this we need to probe the OMAP3 ISP first, have it register its clock 
 devices, 
 and then wait until all sensors become available.

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

Re: Getting started with OMAP3 ISP

2011-08-30 Thread Enrico

On Tue, Aug 30, 2011 at 4:56 PM, Gary Thomas g...@mlbassoc.com wrote:
 Yes, that helped a lot.  When I create the devices by hand, I can now see
 my driver starting to be accessed (right now it's very much an empty stub)

From your logs it seems you are using a tvp5150, i've posted a patch
[1] for tvp5150 that makes it very close to work, it could be faster
to debug it instead of starting from scratch.

Enrico

[1] http://www.spinics.net/lists/linux-media/msg37116.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Getting started with OMAP3 ISP


On 2011-08-30 10:07, Enrico wrote:

On Tue, Aug 30, 2011 at 4:56 PM, Gary Thomasg...@mlbassoc.com  wrote:

Yes, that helped a lot.  When I create the devices by hand, I can now see
my driver starting to be accessed (right now it's very much an empty stub)



From your logs it seems you are using a tvp5150, i've posted a patch

[1] for tvp5150 that makes it very close to work, it could be faster
to debug it instead of starting from scratch.

Enrico

[1] http://www.spinics.net/lists/linux-media/msg37116.html


Thanks, I'll give it a look.

Your note says that /dev/video* is properly registered.  Does this
mean that udev created them for you on boot as well?  If so, what
version of udev are you using?  What's your root file system setup?
n.b. I'm using an OpenEmbedded variant, Poky

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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: Getting started with OMAP3 ISP

2011-08-30 Thread Enrico

On Tue, Aug 30, 2011 at 6:23 PM, Gary Thomas g...@mlbassoc.com wrote:
 Thanks, I'll give it a look.

 Your note says that /dev/video* is properly registered.  Does this
 mean that udev created them for you on boot as well?  If so, what
 version of udev are you using?  What's your root file system setup?
 n.b. I'm using an OpenEmbedded variant, Poky

They are not created on boot but when i modprobe omap3-isp (and
tvp5150 gets automatically loaded).

Udev is version 173 and i'm using Angstrom, an OpenEmbedded (core) variant too.

Anyway when developing the patch it happened to me too that i had
those subdev open errors, but if i remember correctly only for tvp5150
so it was something wrong in my code.

And if i continue to remember correctly it was because you had to set
the V4L2_SUBDEV_FL_HAS_DEVNODE after calling v4l2_i2c_subdev_init.
Seems nonsense but this is what i remember, actually this is what the
mt9v032 driver does.

Enrico
--
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: Usb digital TV

2011-08-30 Thread Gabriel Sartori

Thank you Allan!

I tried that device and it worked fine in my workstation.
Now I will try this at my mx28 based board!!!

Best regards,

Gabriel Sartori

2011/8/30 Alan Carvalho de Assis acas...@gmail.com:
 Hi Gabriel,

 On 8/30/11, Gabriel Sartori gabriel.sart...@gmail.com wrote:
 Thank you Allan!

   Did this device that you use works in 1-seg? I think it is just full-seg!


 Yes, it support both: 1-seg and full-seg.

 In our device we use only 1-seg because your processor cannot decode full-seg.

 Best Regards,

 Alan

--
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: Getting started with OMAP3 ISP


On 2011-08-30 10:36, Enrico wrote:

On Tue, Aug 30, 2011 at 6:23 PM, Gary Thomasg...@mlbassoc.com  wrote:

Thanks, I'll give it a look.

Your note says that /dev/video* is properly registered.  Does this
mean that udev created them for you on boot as well?  If so, what
version of udev are you using?  What's your root file system setup?
n.b. I'm using an OpenEmbedded variant, Poky


They are not created on boot but when i modprobe omap3-isp (and
tvp5150 gets automatically loaded).

Udev is version 173 and i'm using Angstrom, an OpenEmbedded (core) variant too.

Anyway when developing the patch it happened to me too that i had
those subdev open errors, but if i remember correctly only for tvp5150
so it was something wrong in my code.

And if i continue to remember correctly it was because you had to set
the V4L2_SUBDEV_FL_HAS_DEVNODE after calling v4l2_i2c_subdev_init.
Seems nonsense but this is what i remember, actually this is what the
mt9v032 driver does.


Yes, without that setting, the tvp device doesn't register a proper v4l_subdev 
node.

I'm getting the devices created, i.e. they exist in /sys, but just
not in /dev.  I'll see if I can run a new udev - maybe that will fix it.

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[PATCH] media: none of the drivers should be enabled by default

None of the media drivers are compulsory, let users select which drivers
they want to build, instead of having to unselect them one by one.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/common/tuners/Kconfig |   23 +--
 drivers/media/radio/Kconfig |1 -
 drivers/media/rc/Kconfig|   16 +---
 drivers/media/rc/keymaps/Kconfig|1 -
 drivers/media/video/Kconfig |7 ++-
 5 files changed, 4 insertions(+), 44 deletions(-)

diff --git a/drivers/media/common/tuners/Kconfig 
b/drivers/media/common/tuners/Kconfig
index 996302a..1e53057 100644
--- a/drivers/media/common/tuners/Kconfig
+++ b/drivers/media/common/tuners/Kconfig
@@ -33,7 +33,7 @@ config MEDIA_TUNER
select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE
 
 config MEDIA_TUNER_CUSTOMISE
-   bool Customize analog and hybrid tuner modules to build
+   bool Select analog and hybrid tuner modules to build
depends on MEDIA_TUNER
default y if EXPERT
help
@@ -52,7 +52,6 @@ config MEDIA_TUNER_SIMPLE
tristate Simple tuner support
depends on VIDEO_MEDIA  I2C
select MEDIA_TUNER_TDA9887
-   default m if MEDIA_TUNER_CUSTOMISE
help
  Say Y here to include support for various simple tuners.
 
@@ -61,28 +60,24 @@ config MEDIA_TUNER_TDA8290
depends on VIDEO_MEDIA  I2C
select MEDIA_TUNER_TDA827X
select MEDIA_TUNER_TDA18271
-   default m if MEDIA_TUNER_CUSTOMISE
help
  Say Y here to include support for Philips TDA8290+8275(a) tuner.
 
 config MEDIA_TUNER_TDA827X
tristate Philips TDA827X silicon tuner
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  A DVB-T silicon tuner module. Say Y when you want to support this 
tuner.
 
 config MEDIA_TUNER_TDA18271
tristate NXP TDA18271 silicon tuner
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  A silicon tuner module. Say Y when you want to support this tuner.
 
 config MEDIA_TUNER_TDA9887
tristate TDA 9885/6/7 analog IF demodulator
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  Say Y here to include support for Philips TDA9885/6/7
  analog IF demodulator.
@@ -91,63 +86,54 @@ config MEDIA_TUNER_TEA5761
tristate TEA 5761 radio tuner (EXPERIMENTAL)
depends on VIDEO_MEDIA  I2C
depends on EXPERIMENTAL
-   default m if MEDIA_TUNER_CUSTOMISE
help
  Say Y here to include support for the Philips TEA5761 radio tuner.
 
 config MEDIA_TUNER_TEA5767
tristate TEA 5767 radio tuner
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  Say Y here to include support for the Philips TEA5767 radio tuner.
 
 config MEDIA_TUNER_MT20XX
tristate Microtune 2032 / 2050 tuners
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  Say Y here to include support for the MT2032 / MT2050 tuner.
 
 config MEDIA_TUNER_MT2060
tristate Microtune MT2060 silicon IF tuner
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  A driver for the silicon IF tuner MT2060 from Microtune.
 
 config MEDIA_TUNER_MT2266
tristate Microtune MT2266 silicon tuner
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  A driver for the silicon baseband tuner MT2266 from Microtune.
 
 config MEDIA_TUNER_MT2131
tristate Microtune MT2131 silicon tuner
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  A driver for the silicon baseband tuner MT2131 from Microtune.
 
 config MEDIA_TUNER_QT1010
tristate Quantek QT1010 silicon tuner
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  A driver for the silicon tuner QT1010 from Quantek.
 
 config MEDIA_TUNER_XC2028
tristate XCeive xc2028/xc3028 tuners
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  Say Y here to include support for the xc2028/xc3028 tuners.
 
 config MEDIA_TUNER_XC5000
tristate Xceive XC5000 silicon tuner
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  A driver for the silicon tuner XC5000 from Xceive.
  This device is only used inside a SiP called together with a
@@ -156,7 +142,6 @@ config MEDIA_TUNER_XC5000
 config MEDIA_TUNER_XC4000
tristate Xceive XC4000 silicon tuner
depends on VIDEO_MEDIA  I2C
-   default m if MEDIA_TUNER_CUSTOMISE
help
  A driver for the silicon tuner XC4000 from Xceive.
  This device is only used inside a SiP called together with a
@@

Re: [PATCH] media: none of the drivers should be enabled by default

On Tue, Aug 30, 2011 at 1:22 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 None of the media drivers are compulsory, let users select which drivers
 they want to build, instead of having to unselect them one by one.

 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de

I would be against this particular patch.  When MEDIA_TUNER_CUSTOMISE
is DISABLED, Kconfig automatically selects the required tuners.  When
MEDIA_TUNER_CUSTOMISE is *ENABLED*, the menu opens up with everything
selected by default, users can choose which modules not to build.  I
believe that your patch will create a new user-support nightmare.  Is
there any way to justify a need for this type of change?  Can't you
just leave MEDIA_TUNER_CUSTOMISE disabled?  If MEDIA_TUNER_CUSTOMISE
is disabled and you are not building any drivers that require a tuner
module, then the tuner modules will not be built -- if that isn't
functioning properly, then let's fix that, instead.

Regards,

Michael Krufky


 ---
  drivers/media/common/tuners/Kconfig |   23 +--
  drivers/media/radio/Kconfig         |    1 -
  drivers/media/rc/Kconfig            |   16 +---
  drivers/media/rc/keymaps/Kconfig    |    1 -
  drivers/media/video/Kconfig         |    7 ++-
  5 files changed, 4 insertions(+), 44 deletions(-)

 diff --git a/drivers/media/common/tuners/Kconfig 
 b/drivers/media/common/tuners/Kconfig
 index 996302a..1e53057 100644
 --- a/drivers/media/common/tuners/Kconfig
 +++ b/drivers/media/common/tuners/Kconfig
 @@ -33,7 +33,7 @@ config MEDIA_TUNER
        select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE

  config MEDIA_TUNER_CUSTOMISE
 -       bool Customize analog and hybrid tuner modules to build
 +       bool Select analog and hybrid tuner modules to build
        depends on MEDIA_TUNER
        default y if EXPERT
        help
 @@ -52,7 +52,6 @@ config MEDIA_TUNER_SIMPLE
        tristate Simple tuner support
        depends on VIDEO_MEDIA  I2C
        select MEDIA_TUNER_TDA9887
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for various simple tuners.

 @@ -61,28 +60,24 @@ config MEDIA_TUNER_TDA8290
        depends on VIDEO_MEDIA  I2C
        select MEDIA_TUNER_TDA827X
        select MEDIA_TUNER_TDA18271
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for Philips TDA8290+8275(a) tuner.

  config MEDIA_TUNER_TDA827X
        tristate Philips TDA827X silicon tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          A DVB-T silicon tuner module. Say Y when you want to support this 
 tuner.

  config MEDIA_TUNER_TDA18271
        tristate NXP TDA18271 silicon tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          A silicon tuner module. Say Y when you want to support this tuner.

  config MEDIA_TUNER_TDA9887
        tristate TDA 9885/6/7 analog IF demodulator
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for Philips TDA9885/6/7
          analog IF demodulator.
 @@ -91,63 +86,54 @@ config MEDIA_TUNER_TEA5761
        tristate TEA 5761 radio tuner (EXPERIMENTAL)
        depends on VIDEO_MEDIA  I2C
        depends on EXPERIMENTAL
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for the Philips TEA5761 radio tuner.

  config MEDIA_TUNER_TEA5767
        tristate TEA 5767 radio tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for the Philips TEA5767 radio tuner.

  config MEDIA_TUNER_MT20XX
        tristate Microtune 2032 / 2050 tuners
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for the MT2032 / MT2050 tuner.

  config MEDIA_TUNER_MT2060
        tristate Microtune MT2060 silicon IF tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          A driver for the silicon IF tuner MT2060 from Microtune.

  config MEDIA_TUNER_MT2266
        tristate Microtune MT2266 silicon tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          A driver for the silicon baseband tuner MT2266 from Microtune.

  config MEDIA_TUNER_MT2131
        tristate Microtune MT2131 silicon tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          A driver for the silicon baseband tuner MT2131 from Microtune.

  config MEDIA_TUNER_QT1010
        tristate Quantek QT1010 silicon tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          A driver for the silicon tuner QT1010 from Quantek.

  config MEDIA_TUNER_XC2028
        tristate XCeive

Re: [PATCH] media: none of the drivers should be enabled by default

On Tue, Aug 30, 2011 at 1:32 PM, Michael Krufky mkru...@linuxtv.org wrote:
 On Tue, Aug 30, 2011 at 1:22 PM, Guennadi Liakhovetski
 g.liakhovet...@gmx.de wrote:
 None of the media drivers are compulsory, let users select which drivers
 they want to build, instead of having to unselect them one by one.

 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de

 I would be against this particular patch.  When MEDIA_TUNER_CUSTOMISE
 is DISABLED, Kconfig automatically selects the required tuners.  When
 MEDIA_TUNER_CUSTOMISE is *ENABLED*, the menu opens up with everything
 selected by default, users can choose which modules not to build.  I
 believe that your patch will create a new user-support nightmare.  Is
 there any way to justify a need for this type of change?  Can't you
 just leave MEDIA_TUNER_CUSTOMISE disabled?  If MEDIA_TUNER_CUSTOMISE
 is disabled and you are not building any drivers that require a tuner
 module, then the tuner modules will not be built -- if that isn't
 functioning properly, then let's fix that, instead.

I see now that this applies to decoders and such as well -- not only
tuners.  I see this patch as a step backwards, where the current state
is user friendly enough to automatically select required module
dependencies while still allowing customization.


Michael Krufky


 ---
  drivers/media/common/tuners/Kconfig |   23 +--
  drivers/media/radio/Kconfig         |    1 -
  drivers/media/rc/Kconfig            |   16 +---
  drivers/media/rc/keymaps/Kconfig    |    1 -
  drivers/media/video/Kconfig         |    7 ++-
  5 files changed, 4 insertions(+), 44 deletions(-)

 diff --git a/drivers/media/common/tuners/Kconfig 
 b/drivers/media/common/tuners/Kconfig
 index 996302a..1e53057 100644
 --- a/drivers/media/common/tuners/Kconfig
 +++ b/drivers/media/common/tuners/Kconfig
 @@ -33,7 +33,7 @@ config MEDIA_TUNER
        select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE

  config MEDIA_TUNER_CUSTOMISE
 -       bool Customize analog and hybrid tuner modules to build
 +       bool Select analog and hybrid tuner modules to build
        depends on MEDIA_TUNER
        default y if EXPERT
        help
 @@ -52,7 +52,6 @@ config MEDIA_TUNER_SIMPLE
        tristate Simple tuner support
        depends on VIDEO_MEDIA  I2C
        select MEDIA_TUNER_TDA9887
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for various simple tuners.

 @@ -61,28 +60,24 @@ config MEDIA_TUNER_TDA8290
        depends on VIDEO_MEDIA  I2C
        select MEDIA_TUNER_TDA827X
        select MEDIA_TUNER_TDA18271
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for Philips TDA8290+8275(a) tuner.

  config MEDIA_TUNER_TDA827X
        tristate Philips TDA827X silicon tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          A DVB-T silicon tuner module. Say Y when you want to support this 
 tuner.

  config MEDIA_TUNER_TDA18271
        tristate NXP TDA18271 silicon tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          A silicon tuner module. Say Y when you want to support this tuner.

  config MEDIA_TUNER_TDA9887
        tristate TDA 9885/6/7 analog IF demodulator
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for Philips TDA9885/6/7
          analog IF demodulator.
 @@ -91,63 +86,54 @@ config MEDIA_TUNER_TEA5761
        tristate TEA 5761 radio tuner (EXPERIMENTAL)
        depends on VIDEO_MEDIA  I2C
        depends on EXPERIMENTAL
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for the Philips TEA5761 radio tuner.

  config MEDIA_TUNER_TEA5767
        tristate TEA 5767 radio tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for the Philips TEA5767 radio tuner.

  config MEDIA_TUNER_MT20XX
        tristate Microtune 2032 / 2050 tuners
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          Say Y here to include support for the MT2032 / MT2050 tuner.

  config MEDIA_TUNER_MT2060
        tristate Microtune MT2060 silicon IF tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          A driver for the silicon IF tuner MT2060 from Microtune.

  config MEDIA_TUNER_MT2266
        tristate Microtune MT2266 silicon tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          A driver for the silicon baseband tuner MT2266 from Microtune.

  config MEDIA_TUNER_MT2131
        tristate Microtune MT2131 silicon tuner
        depends on VIDEO_MEDIA  I2C
 -       default m if MEDIA_TUNER_CUSTOMISE
        help
          A driver for the

Re: [PATCH 1/5] [media] v4l: add support for selection api

2011-08-30 Thread Tomasz Stanislawski


On 08/26/2011 05:01 PM, Laurent Pinchart wrote:

Hi Tomasz,

On Friday 26 August 2011 15:06:03 Tomasz Stanislawski wrote:

This patch introduces new api for a precise control of cropping and
composing features for video devices. The new ioctls are
VIDIOC_S_SELECTION and VIDIOC_G_SELECTION.

Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
  drivers/media/video/v4l2-compat-ioctl32.c |2 ++
  drivers/media/video/v4l2-ioctl.c  |   28
 include/linux/videodev2.h |
27 +++ include/media/v4l2-ioctl.h|
4 
  4 files changed, 61 insertions(+), 0 deletions(-)


[snip]


diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..fad4fb3 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -738,6 +738,29 @@ struct v4l2_crop {
struct v4l2_rectc;
  };

+/* Hints for adjustments of selection rectangle */
+#define V4L2_SEL_SIZE_GE   0x0001
+#define V4L2_SEL_SIZE_LE   0x0002
+
+enum v4l2_sel_target {
+   V4L2_SEL_CROP_ACTIVE  = 0,
+   V4L2_SEL_CROP_DEFAULT = 1,
+   V4L2_SEL_CROP_BOUNDS  = 2,
+   V4L2_SEL_COMPOSE_ACTIVE  = 256 + 0,
+   V4L2_SEL_COMPOSE_DEFAULT = 256 + 1,
+   V4L2_SEL_COMPOSE_BOUNDS  = 256 + 2,
+   V4L2_SEL_COMPOSE_PADDED  = 256 + 3,
+};
+
+struct v4l2_selection {
+   enum v4l2_buf_type  type;
+   enum v4l2_sel_targettarget;
+   __u32   flags;
+   struct v4l2_rectr;

Maybe rect instead of r ? Lines such as

p-c = s.r;

in patch 3/5 look a bit cryptic.

Notice that struct v4l2_crop contains field c of struct v4l2_rect type.
I wanted to keep this name as short as possible because it is obvious 
that selection is a rectangle,

so its coordinates should be accessed in the shortest possible way :)

+   __u32   reserved[9];
+};
+
+
  /*
   *  A N A L O G   V I D E O   S T A N D A R D
   */

[snip]


diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index dd9f1e7..2c0396b 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -194,6 +194,10 @@ struct v4l2_ioctl_ops {
struct v4l2_crop *a);
int (*vidioc_s_crop)   (struct file *file, void *fh,
struct v4l2_crop *a);
+   int (*vidioc_g_selection)  (struct file *file, void *fh,
+   struct v4l2_selection *a);
+   int (*vidioc_s_selection)  (struct file *file, void *fh,
+   struct v4l2_selection *a);

Why 'a' ? Don't blindly copy past mistakes :-) 'sel' would be a more
descriptive parameter name.

Maybe just 's' is good enough. It keeps naming used by other ops.

/* Compression ioctls */
int (*vidioc_g_jpegcomp)   (struct file *file, void *fh,
struct v4l2_jpegcompression *a);


--
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: Usb digital TV

2011-08-30 Thread Gabriel Sartori

Hi,

  It worked in my i.mx28 based board also!
  In my intel pc I used VLC to play video but I do not have a port of
VLC to my platform.

  Is it possible to use gstreamer to play it?

Thanks a lot!

Gabriel Sartori

2011/8/30 Gabriel Sartori gabriel.sart...@gmail.com:
 Thank you Allan!

  Did this device that you use works in 1-seg? I think it is just full-seg!

  Using the Siano based device I tried a better antenna and still
 cannot scan channels.
  I also tried the patches from Mauro and modified the device firmware
 to isdbt_nova_12mhz_b0.inp forcing it to use mode 6!
  But it did not work either.

  In my Windows machine it worked without any problem.

  I really don't have much more options.

 Thanks in advance!

 2011/8/29 Alan Carvalho de Assis acas...@gmail.com:
 Hi Gabriel,

 On 8/29/11, Gabriel Sartori gabriel.sart...@gmail.com wrote:
 It there some devices that has more chance to work on a 2.6.35 kernel
 version so I can just cross compile the driver to my mx28 board in a
 easier way?

 Thanks in advance.


 I suggest you using a device based on dib0700, I got it working on
 Linux = 2.6.35:
 https://acassis.wordpress.com/2009/09/18/watching-digital-tv-sbtvd-in-the-linux/

 This same device working on i-MXT (Android 2.2 with Linux kernel 2.6.35):
 http://holoscopio.com/misc/androidtv/

 Best Regards,

 Alan


--
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: [media-ctl][PATCHv2 3/4] libmediactl: use udev conditionally to get a devname

Hi Andy,

Thanks for the patch, and sorry for the late reply.

On Tuesday 16 August 2011 12:28:04 Andy Shevchenko wrote:
 Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
 ---
  configure.in|   22 ++
  src/Makefile.am |2 ++
  src/media.c |   50 ++
  3 files changed, 74 insertions(+), 0 deletions(-)
 
 diff --git a/configure.in b/configure.in
 index fd4c70c..45e0663 100644
 --- a/configure.in
 +++ b/configure.in
 @@ -13,6 +13,28 @@ AC_PROG_LIBTOOL
 
  # Checks for libraries.
 
 +AC_ARG_WITH([libudev],
 +AS_HELP_STRING([--without-libudev],
 +[Ignore presence of libudev and disable it]))
 +
 +AS_IF([test x$with_libudev != xno],
 +[PKG_CHECK_MODULES(libudev, libudev, have_libudev=yes,
 have_libudev=no)], +[have_libudev=no])
 +
 +AS_IF([test x$have_libudev = xyes],
 +[
 +AC_DEFINE([HAVE_LIBUDEV], [], [Use libudev])
 +LIBUDEV_CFLAGS=$lbudev_CFLAGS
 +LIBUDEV_LIBS=$libudev_LIBS
 +AC_SUBST(LIBUDEV_CFLAGS)
 +AC_SUBST(LIBUDEV_LIBS)
 +],
 +[AS_IF([test x$with_libudev = xyes],
 +[AC_MSG_ERROR([libudev requested but not found])
 +])
 +])
 +
 +
  # Kernel headers path.
  AC_ARG_WITH(kernel-headers,
  [AC_HELP_STRING([--with-kernel-headers=DIR],
 diff --git a/src/Makefile.am b/src/Makefile.am
 index 267ea83..52628d2 100644
 --- a/src/Makefile.am
 +++ b/src/Makefile.am
 @@ -5,6 +5,8 @@ mediactl_includedir=$(includedir)/mediactl
  mediactl_include_HEADERS = media.h subdev.h
 
  bin_PROGRAMS = media-ctl
 +media_ctl_CFLAGS = $(LIBUDEV_CFLAGS)
 +media_ctl_LDFLAGS = $(LIBUDEV_LIBS)
  media_ctl_SOURCES = main.c options.c options.h tools.h
  media_ctl_LDADD = libmediactl.la libv4l2subdev.la
 
 diff --git a/src/media.c b/src/media.c
 index fc05a86..e159526 100644
 --- a/src/media.c
 +++ b/src/media.c
 @@ -17,6 +17,8 @@
   * with this program; if not, write to the Free Software Foundation, Inc.,
   */
 
 +#include config.h
 +
  #include sys/ioctl.h
  #include sys/stat.h
  #include sys/types.h
 @@ -31,6 +33,10 @@
  #include linux/videodev2.h
  #include linux/media.h
 
 +#ifdef HAVE_LIBUDEV
 +#include libudev.h
 +#endif   /* HAVE_LIBUDEV */
 +
  #include media.h
  #include tools.h
 
 @@ -245,6 +251,37 @@ static int media_enum_links(struct media_device
 *media) return ret;
  }
 
 +#ifdef HAVE_LIBUDEV
 +
 +static struct udev *udev;

I would move this to media_enum_entities() and pass the variable explicitly to 
media_get_devname(). I will make the change unless you want to resubmit the 
patch yourself.

 +
 +static int media_get_devname(struct media_entity *entity)
 +{
 + dev_t devnum;
 + struct udev_device *device;
 + const char *p;
 + int ret = -ENODEV;
 +
 + if (media_entity_type(entity) != MEDIA_ENT_T_DEVNODE 
 + media_entity_type(entity) != MEDIA_ENT_T_V4L2_SUBDEV)
 + return 0;
 +
 + devnum = makedev(entity-info.v4l.major, entity-info.v4l.minor);
 + printf(looking up device: %u:%u\n, major(devnum), minor(devnum));
 + device = udev_device_new_from_devnum(udev, 'c', devnum);
 + if (device) {
 + p = udev_device_get_devnode(device);
 + if (p)
 + snprintf(entity-devname, sizeof(entity-devname), 
 %s, p);
 + ret = 0;
 + }
 +
 + udev_device_unref(device);
 + return ret;
 +}
 +
 +#else/* HAVE_LIBUDEV */
 +
  static int media_get_devname(struct media_entity *entity)
  {
   struct stat devstat;
 @@ -284,6 +321,7 @@ static int media_get_devname(struct media_entity
 *entity)
 
   return 0;
  }
 +#endif   /* HAVE_LIBUDEV */
 
  static int media_enum_entities(struct media_device *media)
  {
 @@ -292,6 +330,14 @@ static int media_enum_entities(struct media_device
 *media) __u32 id;
   int ret = 0;
 
 +#ifdef HAVE_LIBUDEV
 + udev = udev_new();
 + if (udev == NULL) {
 + printf(unable to allocate memory for context\n);
 + return -ENOMEM;
 + }
 +#endif   /* HAVE_LIBUDEV */
 +

If the code is compiled with libudev support enabled, but the target system 
has no udev, runtime failures will be experienced. Do you think it would be 
useful to fall back to the sysfs-based approach in that case ? Do you know 
which udev-related call would then fail ?

   for (id = 0; ; id = entity-info.id) {
   size = (media-entities_count + 1) * sizeof(*media-entities);
   media-entities = realloc(media-entities, size);
 @@ -327,6 +373,10 @@ static int media_enum_entities(struct media_device
 *media) media_get_devname(entity);
   }
 
 +#ifdef HAVE_LIBUDEV
 + udev_unref(udev);
 + udev = NULL;
 +#endif
   return ret;
  }

-- 
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: [media-ctl][PATCHv2 3/4] libmediactl: use udev conditionally to get a devname

Hi Andy,

On Tuesday 16 August 2011 12:28:04 Andy Shevchenko wrote:
 Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
 ---
  configure.in|   22 ++
  src/Makefile.am |2 ++
  src/media.c |   50 ++
  3 files changed, 74 insertions(+), 0 deletions(-)
 
 diff --git a/configure.in b/configure.in
 index fd4c70c..45e0663 100644
 --- a/configure.in
 +++ b/configure.in
 @@ -13,6 +13,28 @@ AC_PROG_LIBTOOL
 
  # Checks for libraries.
 
 +AC_ARG_WITH([libudev],
 +AS_HELP_STRING([--without-libudev],
 +[Ignore presence of libudev and disable it]))
 +
 +AS_IF([test x$with_libudev != xno],
 +[PKG_CHECK_MODULES(libudev, libudev, have_libudev=yes,
 have_libudev=no)],
 +[have_libudev=no])

I don't think this works when cross-compiling.

 +
 +AS_IF([test x$have_libudev = xyes],
 +[
 +AC_DEFINE([HAVE_LIBUDEV], [], [Use libudev])
 +LIBUDEV_CFLAGS=$lbudev_CFLAGS
 +LIBUDEV_LIBS=$libudev_LIBS
 +AC_SUBST(LIBUDEV_CFLAGS)
 +AC_SUBST(LIBUDEV_LIBS)
 +],
 +[AS_IF([test x$with_libudev = xyes],
 +[AC_MSG_ERROR([libudev requested but not found])
 +])
 +])
 +
 +
  # Kernel headers path.
  AC_ARG_WITH(kernel-headers,
  [AC_HELP_STRING([--with-kernel-headers=DIR],

-- 
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] media: none of the drivers should be enabled by default

On Tuesday, August 30, 2011 19:22:00 Guennadi Liakhovetski wrote:
 None of the media drivers are compulsory, let users select which drivers
 they want to build, instead of having to unselect them one by one.

I disagree with this: while this is fine for SoCs, for a generic kernel I
think it is better to build it all. Even expert users can have a hard time
figuring out what chip is in a particular device.

Regards,

Hans

 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
  drivers/media/common/tuners/Kconfig |   23 +--
  drivers/media/radio/Kconfig |1 -
  drivers/media/rc/Kconfig|   16 +---
  drivers/media/rc/keymaps/Kconfig|1 -
  drivers/media/video/Kconfig |7 ++-
  5 files changed, 4 insertions(+), 44 deletions(-)
 
 diff --git a/drivers/media/common/tuners/Kconfig 
 b/drivers/media/common/tuners/Kconfig
 index 996302a..1e53057 100644
 --- a/drivers/media/common/tuners/Kconfig
 +++ b/drivers/media/common/tuners/Kconfig
 @@ -33,7 +33,7 @@ config MEDIA_TUNER
   select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE
  
  config MEDIA_TUNER_CUSTOMISE
 - bool Customize analog and hybrid tuner modules to build
 + bool Select analog and hybrid tuner modules to build
   depends on MEDIA_TUNER
   default y if EXPERT
   help
 @@ -52,7 +52,6 @@ config MEDIA_TUNER_SIMPLE
   tristate Simple tuner support
   depends on VIDEO_MEDIA  I2C
   select MEDIA_TUNER_TDA9887
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 Say Y here to include support for various simple tuners.
  
 @@ -61,28 +60,24 @@ config MEDIA_TUNER_TDA8290
   depends on VIDEO_MEDIA  I2C
   select MEDIA_TUNER_TDA827X
   select MEDIA_TUNER_TDA18271
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 Say Y here to include support for Philips TDA8290+8275(a) tuner.
  
  config MEDIA_TUNER_TDA827X
   tristate Philips TDA827X silicon tuner
   depends on VIDEO_MEDIA  I2C
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 A DVB-T silicon tuner module. Say Y when you want to support this 
 tuner.
  
  config MEDIA_TUNER_TDA18271
   tristate NXP TDA18271 silicon tuner
   depends on VIDEO_MEDIA  I2C
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 A silicon tuner module. Say Y when you want to support this tuner.
  
  config MEDIA_TUNER_TDA9887
   tristate TDA 9885/6/7 analog IF demodulator
   depends on VIDEO_MEDIA  I2C
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 Say Y here to include support for Philips TDA9885/6/7
 analog IF demodulator.
 @@ -91,63 +86,54 @@ config MEDIA_TUNER_TEA5761
   tristate TEA 5761 radio tuner (EXPERIMENTAL)
   depends on VIDEO_MEDIA  I2C
   depends on EXPERIMENTAL
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 Say Y here to include support for the Philips TEA5761 radio tuner.
  
  config MEDIA_TUNER_TEA5767
   tristate TEA 5767 radio tuner
   depends on VIDEO_MEDIA  I2C
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 Say Y here to include support for the Philips TEA5767 radio tuner.
  
  config MEDIA_TUNER_MT20XX
   tristate Microtune 2032 / 2050 tuners
   depends on VIDEO_MEDIA  I2C
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 Say Y here to include support for the MT2032 / MT2050 tuner.
  
  config MEDIA_TUNER_MT2060
   tristate Microtune MT2060 silicon IF tuner
   depends on VIDEO_MEDIA  I2C
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 A driver for the silicon IF tuner MT2060 from Microtune.
  
  config MEDIA_TUNER_MT2266
   tristate Microtune MT2266 silicon tuner
   depends on VIDEO_MEDIA  I2C
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 A driver for the silicon baseband tuner MT2266 from Microtune.
  
  config MEDIA_TUNER_MT2131
   tristate Microtune MT2131 silicon tuner
   depends on VIDEO_MEDIA  I2C
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 A driver for the silicon baseband tuner MT2131 from Microtune.
  
  config MEDIA_TUNER_QT1010
   tristate Quantek QT1010 silicon tuner
   depends on VIDEO_MEDIA  I2C
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 A driver for the silicon tuner QT1010 from Quantek.
  
  config MEDIA_TUNER_XC2028
   tristate XCeive xc2028/xc3028 tuners
   depends on VIDEO_MEDIA  I2C
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 Say Y here to include support for the xc2028/xc3028 tuners.
  
  config MEDIA_TUNER_XC5000
   tristate Xceive XC5000 silicon tuner
   depends on VIDEO_MEDIA  I2C
 - default m if MEDIA_TUNER_CUSTOMISE
   help
 A driver for the silicon tuner XC5000 from Xceive.
 This device is only used inside a SiP called together with a
 @@ -156,7 +142,6 @@ config MEDIA_TUNER_XC5000
  config MEDIA_TUNER_XC4000
   tristate

Re: [ANN] Meeting minutes of the Cambourne meeting

Hi Mark,

On Tuesday 30 August 2011 17:46:42 Mark Brown wrote:
 On Tue, Aug 30, 2011 at 05:42:55PM +0200, Laurent Pinchart wrote:
  A dependency system is tempting but will be very complex to implement
  properly, especially when faced with cyclic dependencies. For instance
  the OMAP3 ISP driver requires the camera sensor device to be present to
  proceed, and the camera sensor requires a clock provided by the OMAP3
  ISP. To solve this we need to probe the OMAP3 ISP first, have it
  register its clock devices, and then wait until all sensors become
  available.
 
 With composite devices like that where the borad has sufficient
 interesting stuff on it representing the board itself as a device (this
 is what ASoC does).
 
  A probe deferral system is probably simpler, but it will have its share
  of problems as well. In the above example, if the sensor is probed
  first, the driver can return -EAGAIN in the probe() method as the clock
  isn't available yet (I'm not sure how to differentiate between not
  available yet and not present in the system though). However, if the
  OMAP3 ISP is probed first, returning -EAGAIN in its probe() method won't
  really help, as we need to register the clock before waiting for the
  sensor.
 
 Having a device for the camera subsystem as a whole breaks this loop as
 the probe of that device triggers the overall system probe.

The exact same idea crossed my mind after hitting the Send button :-)

Would such a device be included in the DT ? My understanding is that the DT 
should only describe the hardware.

-- 
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] media: none of the drivers should be enabled by default

On Tue, 30 Aug 2011, Hans Verkuil wrote:

 On Tuesday, August 30, 2011 19:22:00 Guennadi Liakhovetski wrote:
  None of the media drivers are compulsory, let users select which drivers
  they want to build, instead of having to unselect them one by one.
 
 I disagree with this: while this is fine for SoCs, for a generic kernel I
 think it is better to build it all. Even expert users can have a hard time
 figuring out what chip is in a particular device.

Then could someone, please, explain to me, why I don't find this 
convenience in any other kernel driver class? Wireless, ALSA, USB, I2C - 
you name them. Is there something special about media, that I'm missing, 
or are all others just user-unfriendly? Why are distro-kernels, 
allmodconfig, allyesconfig not enough for media and we think it's 
necessary to build everything just in case?

Thanks
Guennadi

 
 Regards,
 
   Hans
 
  Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
  ---
   drivers/media/common/tuners/Kconfig |   23 +--
   drivers/media/radio/Kconfig |1 -
   drivers/media/rc/Kconfig|   16 +---
   drivers/media/rc/keymaps/Kconfig|1 -
   drivers/media/video/Kconfig |7 ++-
   5 files changed, 4 insertions(+), 44 deletions(-)
  
  diff --git a/drivers/media/common/tuners/Kconfig 
  b/drivers/media/common/tuners/Kconfig
  index 996302a..1e53057 100644
  --- a/drivers/media/common/tuners/Kconfig
  +++ b/drivers/media/common/tuners/Kconfig
  @@ -33,7 +33,7 @@ config MEDIA_TUNER
  select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE
   
   config MEDIA_TUNER_CUSTOMISE
  -   bool Customize analog and hybrid tuner modules to build
  +   bool Select analog and hybrid tuner modules to build
  depends on MEDIA_TUNER
  default y if EXPERT
  help
  @@ -52,7 +52,6 @@ config MEDIA_TUNER_SIMPLE
  tristate Simple tuner support
  depends on VIDEO_MEDIA  I2C
  select MEDIA_TUNER_TDA9887
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
Say Y here to include support for various simple tuners.
   
  @@ -61,28 +60,24 @@ config MEDIA_TUNER_TDA8290
  depends on VIDEO_MEDIA  I2C
  select MEDIA_TUNER_TDA827X
  select MEDIA_TUNER_TDA18271
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
Say Y here to include support for Philips TDA8290+8275(a) tuner.
   
   config MEDIA_TUNER_TDA827X
  tristate Philips TDA827X silicon tuner
  depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
A DVB-T silicon tuner module. Say Y when you want to support this 
  tuner.
   
   config MEDIA_TUNER_TDA18271
  tristate NXP TDA18271 silicon tuner
  depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
A silicon tuner module. Say Y when you want to support this tuner.
   
   config MEDIA_TUNER_TDA9887
  tristate TDA 9885/6/7 analog IF demodulator
  depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
Say Y here to include support for Philips TDA9885/6/7
analog IF demodulator.
  @@ -91,63 +86,54 @@ config MEDIA_TUNER_TEA5761
  tristate TEA 5761 radio tuner (EXPERIMENTAL)
  depends on VIDEO_MEDIA  I2C
  depends on EXPERIMENTAL
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
Say Y here to include support for the Philips TEA5761 radio tuner.
   
   config MEDIA_TUNER_TEA5767
  tristate TEA 5767 radio tuner
  depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
Say Y here to include support for the Philips TEA5767 radio tuner.
   
   config MEDIA_TUNER_MT20XX
  tristate Microtune 2032 / 2050 tuners
  depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
Say Y here to include support for the MT2032 / MT2050 tuner.
   
   config MEDIA_TUNER_MT2060
  tristate Microtune MT2060 silicon IF tuner
  depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
A driver for the silicon IF tuner MT2060 from Microtune.
   
   config MEDIA_TUNER_MT2266
  tristate Microtune MT2266 silicon tuner
  depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
A driver for the silicon baseband tuner MT2266 from Microtune.
   
   config MEDIA_TUNER_MT2131
  tristate Microtune MT2131 silicon tuner
  depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
A driver for the silicon baseband tuner MT2131 from Microtune.
   
   config MEDIA_TUNER_QT1010
  tristate Quantek QT1010 silicon tuner
  depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
A driver for the silicon tuner QT1010 from Quantek.
   
   config MEDIA_TUNER_XC2028
  tristate XCeive xc2028/xc3028 tuners
  depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
  help
Say Y here to

Re: [PATCH] gspca_sn9c20x: device 0c45:62b3: fix status LED

2011-08-30 Thread Frank Schäfer


Am 27.08.2011 13:55, schrieb Hans de Goede:

Hi,

On 08/22/2011 11:27 PM, Frank Schäfer wrote:

Ping ... what happened to this patch ? ;-)


I think it has fallen through the cracks. I've added it
to my tree for 3.1 / 3.2 (more likely will be 3.2)

Regards,

Hans


Thank you Hans. I will check if it has reached mainline in a few weeks. ;)

Regards,
Frank






Am 01.07.2011 12:19, schrieb Frank Schaefer:

gspca_sn9c20x: device 0c45:62b3: fix status LED

Tested with webcam SilverCrest WC2130.

Signed-off-by: Frank Schaeferfschaefer@googlemail.com

Cc: sta...@kernel.org
---
drivers/media/video/gspca/sn9c20x.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/gspca/sn9c20x.c 
b/drivers/media/video/gspca/sn9c20x.c

index c431900..af9cd50 100644
--- a/drivers/media/video/gspca/sn9c20x.c
+++ b/drivers/media/video/gspca/sn9c20x.c
@@ -2513,7 +2513,7 @@ static const struct usb_device_id 
device_table[] = {

{USB_DEVICE(0x0c45, 0x628f), SN9C20X(OV9650, 0x30, 0)},
{USB_DEVICE(0x0c45, 0x62a0), SN9C20X(OV7670, 0x21, 0)},
{USB_DEVICE(0x0c45, 0x62b0), SN9C20X(MT9VPRB, 0x00, 0)},
- {USB_DEVICE(0x0c45, 0x62b3), SN9C20X(OV9655, 0x30, 0)},
+ {USB_DEVICE(0x0c45, 0x62b3), SN9C20X(OV9655, 0x30, LED_REVERSE)},
{USB_DEVICE(0x0c45, 0x62bb), SN9C20X(OV7660, 0x21, LED_REVERSE)},
{USB_DEVICE(0x0c45, 0x62bc), SN9C20X(HV7131R, 0x11, 0)},
{USB_DEVICE(0x045e, 0x00f4), SN9C20X(OV9650, 0x30, 0)},


--
To unsubscribe from this list: send the line unsubscribe 
linux-media in

the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html


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

Re: [ANN] Meeting minutes of the Cambourne meeting

2011-08-30 Thread Mark Brown

On Tue, Aug 30, 2011 at 10:12:30PM +0200, Laurent Pinchart wrote:

 Would such a device be included in the DT ? My understanding is that the DT 
 should only describe the hardware.

For ASoC they will be, the view is that the schematic for the board is
sufficiently interesting to count as hardware.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media: none of the drivers should be enabled by default

On Tuesday, August 30, 2011 22:12:09 Guennadi Liakhovetski wrote:
 On Tue, 30 Aug 2011, Hans Verkuil wrote:
 
  On Tuesday, August 30, 2011 19:22:00 Guennadi Liakhovetski wrote:
   None of the media drivers are compulsory, let users select which drivers
   they want to build, instead of having to unselect them one by one.
  
  I disagree with this: while this is fine for SoCs, for a generic kernel I
  think it is better to build it all. Even expert users can have a hard time
  figuring out what chip is in a particular device.
 
 Then could someone, please, explain to me, why I don't find this 
 convenience in any other kernel driver class? Wireless, ALSA, USB, I2C - 
 you name them. Is there something special about media, that I'm missing, 
 or are all others just user-unfriendly? Why are distro-kernels, 
 allmodconfig, allyesconfig not enough for media and we think it's 
 necessary to build everything just in case?

That's actually a good question. I certainly think that the more obscure
drivers can be disabled by default. But I also think that you want to keep
a certain subset of commonly used drivers enabled. I'm thinking bttv, uvc,
perhaps gspca.

As far as I can see, alsa enables for example HD Audio, which almost all
modern hw supports. We should do something similar for v4l.

And we should really reorder some of the entries in the menu: one of the
first drivers you see are parallel port webcams and other very obscure
devices.

Regards,

Hans

 
 Thanks
 Guennadi
 
  
  Regards,
  
  Hans
  
   Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
   ---
drivers/media/common/tuners/Kconfig |   23 +--
drivers/media/radio/Kconfig |1 -
drivers/media/rc/Kconfig|   16 +---
drivers/media/rc/keymaps/Kconfig|1 -
drivers/media/video/Kconfig |7 ++-
5 files changed, 4 insertions(+), 44 deletions(-)
   
   diff --git a/drivers/media/common/tuners/Kconfig 
   b/drivers/media/common/tuners/Kconfig
   index 996302a..1e53057 100644
   --- a/drivers/media/common/tuners/Kconfig
   +++ b/drivers/media/common/tuners/Kconfig
   @@ -33,7 +33,7 @@ config MEDIA_TUNER
 select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE

config MEDIA_TUNER_CUSTOMISE
   - bool Customize analog and hybrid tuner modules to build
   + bool Select analog and hybrid tuner modules to build
 depends on MEDIA_TUNER
 default y if EXPERT
 help
   @@ -52,7 +52,6 @@ config MEDIA_TUNER_SIMPLE
 tristate Simple tuner support
 depends on VIDEO_MEDIA  I2C
 select MEDIA_TUNER_TDA9887
   - default m if MEDIA_TUNER_CUSTOMISE
 help
   Say Y here to include support for various simple tuners.

   @@ -61,28 +60,24 @@ config MEDIA_TUNER_TDA8290
 depends on VIDEO_MEDIA  I2C
 select MEDIA_TUNER_TDA827X
 select MEDIA_TUNER_TDA18271
   - default m if MEDIA_TUNER_CUSTOMISE
 help
   Say Y here to include support for Philips TDA8290+8275(a) tuner.

config MEDIA_TUNER_TDA827X
 tristate Philips TDA827X silicon tuner
 depends on VIDEO_MEDIA  I2C
   - default m if MEDIA_TUNER_CUSTOMISE
 help
   A DVB-T silicon tuner module. Say Y when you want to support this 
   tuner.

config MEDIA_TUNER_TDA18271
 tristate NXP TDA18271 silicon tuner
 depends on VIDEO_MEDIA  I2C
   - default m if MEDIA_TUNER_CUSTOMISE
 help
   A silicon tuner module. Say Y when you want to support this tuner.

config MEDIA_TUNER_TDA9887
 tristate TDA 9885/6/7 analog IF demodulator
 depends on VIDEO_MEDIA  I2C
   - default m if MEDIA_TUNER_CUSTOMISE
 help
   Say Y here to include support for Philips TDA9885/6/7
   analog IF demodulator.
   @@ -91,63 +86,54 @@ config MEDIA_TUNER_TEA5761
 tristate TEA 5761 radio tuner (EXPERIMENTAL)
 depends on VIDEO_MEDIA  I2C
 depends on EXPERIMENTAL
   - default m if MEDIA_TUNER_CUSTOMISE
 help
   Say Y here to include support for the Philips TEA5761 radio tuner.

config MEDIA_TUNER_TEA5767
 tristate TEA 5767 radio tuner
 depends on VIDEO_MEDIA  I2C
   - default m if MEDIA_TUNER_CUSTOMISE
 help
   Say Y here to include support for the Philips TEA5767 radio tuner.

config MEDIA_TUNER_MT20XX
 tristate Microtune 2032 / 2050 tuners
 depends on VIDEO_MEDIA  I2C
   - default m if MEDIA_TUNER_CUSTOMISE
 help
   Say Y here to include support for the MT2032 / MT2050 tuner.

config MEDIA_TUNER_MT2060
 tristate Microtune MT2060 silicon IF tuner
 depends on VIDEO_MEDIA  I2C
   - default m if MEDIA_TUNER_CUSTOMISE
 help
   A driver for the silicon IF tuner MT2060 from Microtune.

config MEDIA_TUNER_MT2266
 tristate Microtune MT2266 silicon tuner
 depends on VIDEO_MEDIA  I2C
   - default m if MEDIA_TUNER_CUSTOMISE
 help
   A driver for the silicon baseband tuner MT2266 from Microtune.

config

Re: [media-ctl][PATCH] libmediactl: engage udev to get devname

2011-08-30 Thread L. Hanisch


Hi,

Am 15.08.2011 14:20, schrieb Andy Shevchenko:

Signed-off-by: Andy Shevchenkoandriy.shevche...@linux.intel.com
---
  configure.in|   10 
  src/Makefile.am |2 +
  src/media.c |   66 ++
  3 files changed, 44 insertions(+), 34 deletions(-)

diff --git a/configure.in b/configure.in
index fd4c70c..63432ba 100644
--- a/configure.in
+++ b/configure.in
@@ -12,6 +12,16 @@ AC_PROG_CC
  AC_PROG_LIBTOOL

  # Checks for libraries.
+PKG_CHECK_MODULES(libudev, libudev, have_libudev=yes, have_libudev=no)
+
+if test x$have_libudev = xyes; then
+LIBUDEV_CFLAGS=$lbudev_CFLAGS


 Just reading it, shouldn't it be
 LIBUDEV_CFLAGS=$libudev_CFLAGS

Regards,
Lars.


+LIBUDEV_LIBS=$libudev_LIBS
+AC_SUBST(LIBUDEV_CFLAGS)
+AC_SUBST(LIBUDEV_LIBS)
+else
+AC_MSG_ERROR([libudev is required])
+fi

  # Kernel headers path.
  AC_ARG_WITH(kernel-headers,
diff --git a/src/Makefile.am b/src/Makefile.am
index 267ea83..52628d2 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -5,6 +5,8 @@ mediactl_includedir=$(includedir)/mediactl
  mediactl_include_HEADERS = media.h subdev.h

  bin_PROGRAMS = media-ctl
+media_ctl_CFLAGS = $(LIBUDEV_CFLAGS)
+media_ctl_LDFLAGS = $(LIBUDEV_LIBS)
  media_ctl_SOURCES = main.c options.c options.h tools.h
  media_ctl_LDADD = libmediactl.la libv4l2subdev.la

diff --git a/src/media.c b/src/media.c
index e3cab86..000d750 100644
--- a/src/media.c
+++ b/src/media.c
@@ -31,6 +31,8 @@
  #includelinux/videodev2.h
  #includelinux/media.h

+#includelibudev.h
+
  #include media.h
  #include tools.h

@@ -247,15 +249,20 @@ static int media_enum_links(struct media_device *media)

  static int media_enum_entities(struct media_device *media)
  {
+   struct udev *udev;
+   dev_t devnum;
+   struct udev_device *device;
struct media_entity *entity;
-   struct stat devstat;
unsigned int size;
-   char devname[32];
-   char sysname[32];
-   char target[1024];
-   char *p;
+   const char *p;
__u32 id;
-   int ret;
+   int ret = 0;
+
+   udev = udev_new();
+   if (udev == NULL) {
+   printf(unable to allocate memory for context\n);
+   return -ENOMEM;
+   }

for (id = 0; ; id = entity-info.id) {
size = (media-entities_count + 1) * sizeof(*media-entities);
@@ -268,9 +275,9 @@ static int media_enum_entities(struct media_device *media)

ret = ioctl(media-fd, MEDIA_IOC_ENUM_ENTITIES,entity-info);
if (ret  0) {
-   if (errno == EINVAL)
-   break;
-   return -errno;
+   if (errno != EINVAL)
+   ret = -errno;
+   break;
}

/* Number of links (for outbound links) plus number of pads (for
@@ -281,8 +288,10 @@ static int media_enum_entities(struct media_device *media)

entity-pads = malloc(entity-info.pads * 
sizeof(*entity-pads));
entity-links = malloc(entity-max_links * 
sizeof(*entity-links));
-   if (entity-pads == NULL || entity-links == NULL)
-   return -ENOMEM;
+   if (entity-pads == NULL || entity-links == NULL) {
+   ret = -ENOMEM;
+   break;
+   }

media-entities_count++;

@@ -291,32 +300,21 @@ static int media_enum_entities(struct media_device *media)
media_entity_type(entity) != MEDIA_ENT_T_V4L2_SUBDEV)
continue;

-   sprintf(sysname, /sys/dev/char/%u:%u, entity-info.v4l.major,
-   entity-info.v4l.minor);
-   ret = readlink(sysname, target, sizeof(target));
-   if (ret  0)
-   continue;
-
-   target[ret] = '\0';
-   p = strrchr(target, '/');
-   if (p == NULL)
-   continue;
-
-   sprintf(devname, /dev/%s, p + 1);
-   ret = stat(devname,devstat);
-   if (ret  0)
-   continue;
+   devnum = makedev(entity-info.v4l.major, 
entity-info.v4l.minor);
+   printf(looking up device: %u:%u\n, major(devnum), 
minor(devnum));
+   device = udev_device_new_from_devnum(udev, 'c', devnum);
+   if (device) {
+   p = udev_device_get_devnode(device);
+   if (p)
+   snprintf(entity-devname, 
sizeof(entity-devname),
+%s, p);
+   }

-   /* Sanity check: udev might have reordered the device nodes.
-* Make sure the major/minor match. We should really use
-* libudev.
-*/
-   if (major(devstat.st_rdev) == entity-info.v4l.major
-

Re: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates

2011-08-30 Thread Sakari Ailus

Hi Mauro,

On Thu, Aug 25, 2011 at 09:43:56AM -0300, Mauro Carvalho Chehab wrote:
Em 24-08-2011 19:29, Sakari Ailus escreveu:
Hi Mauro,

On Sat, Aug 20, 2011 at 05:12:56AM -0700, Mauro Carvalho Chehab wrote:
Em 20-08-2011 04:27, Sylwester Nawrocki escreveu:
Hi Mauro,

On 08/17/2011 08:13 AM, Mauro Carvalho Chehab wrote:
It seems that there are too many miss understandings or maybe we're just
talking the same thing on different ways.

So, instead of answering again, let's re-start this discussion on a
different way.

One of the requirements that it was discussed a lot on both mailing
lists and on the Media Controllers meetings that we had (or, at least
in the ones where I've participated) is that:

A pure V4L2 userspace application, knowing about video device
nodes only, can still use the driver. Not all advanced features
will be available.

What does a term a pure V4L2 userspace application mean here ?

The above quotation are exactly the Laurent's words that I took from one
of his replies.

I would define this as an application which uses V4L2 but does not use Media
controller or the V4L2 subdev interfaces nor is aware of any particular
hardware device.

As a general rule, applications should not be aware of any particular
hardware.
That's why we provide standard ways of doing things. Experience shows that
hardware
aware applications become obsolete very fast. If you seek at the net, you'll
see
application-aware tools for bttv, zoran, etc. I doubt that they would still
work today, as they were dependent on some particular special case driver
behavior that has changed among the time. Also, if you look of the updates
timeline for those, you'll see that they were kept maintained for a short
period of time.

I agree.

So, I think that all hardware aware dependency should be at the driver and
at the libv4l only. As the proper usage of the MC API requires a hardware
aware knowledge, I don't think that a generic application should bother
to implement the MC API at all.

At least for link configuration, no. But for device discovery, I'd say
perhaps, as this was one of the MC API's original goals. But that's a
separate discussion from this one. I think the question is how the user
should discover devices, e.g. that which audio source is connected to a
video source.

It should be noticed, however, that having a hardware/driver aware libv4l
also implies that libv4l should be dependent on an specific kernel version,
at the distributions.

I think a difference needs to be made between libv4l and libv4l plugins.

The plugin interface was added with plugins performing MC link setup etc. in
mind, but whether the libv4l proper should do something specific in embedded
system other than loading a plugin hasn't been discussed yet.

I could imagine this might be part of the libv4l core eventually.

This already happens somehow there, but, currently, a new version of libv4l
can work with an older kernel (as all we currently have there is support for
new FOURCC formats and quirk lists of sensors mounted upside down).

So, a version made to work with kernel 3.0 will for sure support all webcams
found at kernel 2.39.

As features are standardised this is easy. However, often standardising
something requires creating a few implementations privately. If one writes a
libv4l plugin using such private interfaces, it will break once the feature
is standardised.

A good, simple example of this could be the FRAME_SYNC event:

URL:http://git.linuxtv.org/sailus/media_tree.git/shortlog/refs/heads/media-for-3.2-frame-sync-event-1

I don't think this is an actual problem right now since there haven't been
many generic users of these interfaces but I think this is worth keeping in
mind.

Does it also account an application which is linked to libv4l2 and uses
calls specific to a particular hardware which are included there?

That's a good question. We need to properly define what it means, to avoid
having libv4l abuses.

In other words, it seems ok to use libv4l to set pipelines via the MC API
at open(), but it isn't ok to have an open() binary only libv4l plugin that
will hook open and do the complete device initialization on userspace
(I remember that one vendor once proposed a driver like that).

Also, from my side, I'd like to see both libv4l and kernel drivers being
submitted together, if the new driver depends on a special libv4l support
for it to work.

I agree with the above.

I do favour using libv4l to do the pipeline setup using MC and V4L2 subdev
interfaces. This has the benefit that the driver provides just one interface
to access different aspects of it, be it pipeline setup (Media controller),
a control to change exposure time (V4L2 subdev) or queueing video buffer
(V4L2). This means more simple and more maintainable drivers and less bugs
in general.

I agree.

Apart from what the drivers

Re: [PATCH] media: none of the drivers should be enabled by default

On Tue, Aug 30, 2011 at 4:12 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 On Tue, 30 Aug 2011, Hans Verkuil wrote:

 On Tuesday, August 30, 2011 19:22:00 Guennadi Liakhovetski wrote:
  None of the media drivers are compulsory, let users select which drivers
  they want to build, instead of having to unselect them one by one.

 I disagree with this: while this is fine for SoCs, for a generic kernel I
 think it is better to build it all. Even expert users can have a hard time
 figuring out what chip is in a particular device.

 Then could someone, please, explain to me, why I don't find this
 convenience in any other kernel driver class? Wireless, ALSA, USB, I2C -
 you name them. Is there something special about media, that I'm missing,
 or are all others just user-unfriendly? Why are distro-kernels,
 allmodconfig, allyesconfig not enough for media and we think it's
 necessary to build everything just in case?


This isn't a matter of building all drivers by default -- it is a
matter of building component dependency drivers that are needed by the
bridge drivers, and allowing users to not build drivers that they
don't need.  The customization options are there to allow you to
disable the helper chips / tuners etc from all being built if that
is your choice.  If you disable the customization options, then
Kconfig automatically selects the dependencies of the bridge drivers
that you've selected and does NOT build those that are irrelevant to
you.  At first, users were forced to build everything without being
able to disable these modules.  We added this mechanism to allow such
modules to be disabled from a build, but we enable them by default
because anything else would become a user-support nightmare, as I
stated earlier.  If you refer to the mailing list archives from about
four or five years ago, you'll may find that this was discussed at
length on the video4linux and linux-dvb mailing lists.  In the end I
believe this is the solution that satisfied everybody the best.

-Mike Krufky

 Thanks
 Guennadi


 Regards,

       Hans

  Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
  ---
   drivers/media/common/tuners/Kconfig |   23 +--
   drivers/media/radio/Kconfig         |    1 -
   drivers/media/rc/Kconfig            |   16 +---
   drivers/media/rc/keymaps/Kconfig    |    1 -
   drivers/media/video/Kconfig         |    7 ++-
   5 files changed, 4 insertions(+), 44 deletions(-)
 
  diff --git a/drivers/media/common/tuners/Kconfig 
  b/drivers/media/common/tuners/Kconfig
  index 996302a..1e53057 100644
  --- a/drivers/media/common/tuners/Kconfig
  +++ b/drivers/media/common/tuners/Kconfig
  @@ -33,7 +33,7 @@ config MEDIA_TUNER
      select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE
 
   config MEDIA_TUNER_CUSTOMISE
  -   bool Customize analog and hybrid tuner modules to build
  +   bool Select analog and hybrid tuner modules to build
      depends on MEDIA_TUNER
      default y if EXPERT
      help
  @@ -52,7 +52,6 @@ config MEDIA_TUNER_SIMPLE
      tristate Simple tuner support
      depends on VIDEO_MEDIA  I2C
      select MEDIA_TUNER_TDA9887
  -   default m if MEDIA_TUNER_CUSTOMISE
      help
        Say Y here to include support for various simple tuners.
 
  @@ -61,28 +60,24 @@ config MEDIA_TUNER_TDA8290
      depends on VIDEO_MEDIA  I2C
      select MEDIA_TUNER_TDA827X
      select MEDIA_TUNER_TDA18271
  -   default m if MEDIA_TUNER_CUSTOMISE
      help
        Say Y here to include support for Philips TDA8290+8275(a) tuner.
 
   config MEDIA_TUNER_TDA827X
      tristate Philips TDA827X silicon tuner
      depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
      help
        A DVB-T silicon tuner module. Say Y when you want to support this 
  tuner.
 
   config MEDIA_TUNER_TDA18271
      tristate NXP TDA18271 silicon tuner
      depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
      help
        A silicon tuner module. Say Y when you want to support this tuner.
 
   config MEDIA_TUNER_TDA9887
      tristate TDA 9885/6/7 analog IF demodulator
      depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
      help
        Say Y here to include support for Philips TDA9885/6/7
        analog IF demodulator.
  @@ -91,63 +86,54 @@ config MEDIA_TUNER_TEA5761
      tristate TEA 5761 radio tuner (EXPERIMENTAL)
      depends on VIDEO_MEDIA  I2C
      depends on EXPERIMENTAL
  -   default m if MEDIA_TUNER_CUSTOMISE
      help
        Say Y here to include support for the Philips TEA5761 radio tuner.
 
   config MEDIA_TUNER_TEA5767
      tristate TEA 5767 radio tuner
      depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
      help
        Say Y here to include support for the Philips TEA5767 radio tuner.
 
   config MEDIA_TUNER_MT20XX
      tristate Microtune 2032 / 2050 tuners
      depends on VIDEO_MEDIA  I2C
  -   default m if MEDIA_TUNER_CUSTOMISE
      help
        Say Y here to

Re: [PATCH 1/2] omap3: ISP: Fix the failure of CCDC capture during suspend/resume

Hi,

On Wednesday 10 August 2011 16:03:12 Deepthy Ravi wrote:
 From: Abhilash K V abhilash...@ti.com
 
 While resuming from the suspended to memory state,
 occasionally CCDC fails to get enabled and thus fails
 to capture frames any more till the next suspend/resume
 is issued.
 This is a race condition which happens only when a CCDC
 frame-completion ISR is pending even as ISP device's
 isp_pm_prepare() is getting called and only one buffer
 is left on the DMA queue.
 The DMA queue buffers are thus depleted which results in
 its underrun.So when ISP resumes there are no buffers on
 the queue (as the application which can issue buffers is
 yet to resume) to start video capture.
 This fix addresses this issue by dequeuing and enqueing
 the last buffer in isp_pm_prepare() after its DMA gets
 completed. Thus,when ISP resumes it always finds atleast
 one buffer on the DMA queue - this is true if application
 uses only 3 buffers.

How is that problem specific to the CCDC ? Can't it be reproduce at the 
preview engine or resizer output as well ?

-- 
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/5] [media] v4l: add support for selection api

2011-08-30 Thread Sakari Ailus

Hi Thomaas,

Thanks for the patch.

On Fri, Aug 26, 2011 at 03:06:03PM +0200, Tomasz Stanislawski wrote:
 This patch introduces new api for a precise control of cropping and composing
 features for video devices. The new ioctls are VIDIOC_S_SELECTION and
 VIDIOC_G_SELECTION.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/video/v4l2-compat-ioctl32.c |2 ++
  drivers/media/video/v4l2-ioctl.c  |   28 
  include/linux/videodev2.h |   27 +++
  include/media/v4l2-ioctl.h|4 
  4 files changed, 61 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/media/video/v4l2-compat-ioctl32.c 
 b/drivers/media/video/v4l2-compat-ioctl32.c
 index 61979b7..f3b9d15 100644
 --- a/drivers/media/video/v4l2-compat-ioctl32.c
 +++ b/drivers/media/video/v4l2-compat-ioctl32.c
 @@ -927,6 +927,8 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int 
 cmd, unsigned long arg)
   case VIDIOC_CROPCAP:
   case VIDIOC_G_CROP:
   case VIDIOC_S_CROP:
 + case VIDIOC_G_SELECTION:
 + case VIDIOC_S_SELECTION:
   case VIDIOC_G_JPEGCOMP:
   case VIDIOC_S_JPEGCOMP:
   case VIDIOC_QUERYSTD:
 diff --git a/drivers/media/video/v4l2-ioctl.c 
 b/drivers/media/video/v4l2-ioctl.c
 index 002ce13..6e02b45 100644
 --- a/drivers/media/video/v4l2-ioctl.c
 +++ b/drivers/media/video/v4l2-ioctl.c
 @@ -225,6 +225,8 @@ static const char *v4l2_ioctls[] = {
   [_IOC_NR(VIDIOC_CROPCAP)]  = VIDIOC_CROPCAP,
   [_IOC_NR(VIDIOC_G_CROP)]   = VIDIOC_G_CROP,
   [_IOC_NR(VIDIOC_S_CROP)]   = VIDIOC_S_CROP,
 + [_IOC_NR(VIDIOC_G_SELECTION)]  = VIDIOC_G_SELECTION,
 + [_IOC_NR(VIDIOC_S_SELECTION)]  = VIDIOC_S_SELECTION,
   [_IOC_NR(VIDIOC_G_JPEGCOMP)]   = VIDIOC_G_JPEGCOMP,
   [_IOC_NR(VIDIOC_S_JPEGCOMP)]   = VIDIOC_S_JPEGCOMP,
   [_IOC_NR(VIDIOC_QUERYSTD)] = VIDIOC_QUERYSTD,
 @@ -1714,6 +1716,32 @@ static long __video_do_ioctl(struct file *file,
   ret = ops-vidioc_s_crop(file, fh, p);
   break;
   }
 + case VIDIOC_G_SELECTION:
 + {
 + struct v4l2_selection *p = arg;
 +
 + if (!ops-vidioc_g_selection)
 + break;
 +
 + dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
 +
 + ret = ops-vidioc_g_selection(file, fh, p);
 + if (!ret)
 + dbgrect(vfd, , p-r);
 + break;
 + }
 + case VIDIOC_S_SELECTION:
 + {
 + struct v4l2_selection *p = arg;
 +
 + if (!ops-vidioc_s_selection)
 + break;
 + dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
 + dbgrect(vfd, , p-r);
 +
 + ret = ops-vidioc_s_selection(file, fh, p);
 + break;
 + }
   case VIDIOC_CROPCAP:
   {
   struct v4l2_cropcap *p = arg;
 diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
 index fca24cc..fad4fb3 100644
 --- a/include/linux/videodev2.h
 +++ b/include/linux/videodev2.h
 @@ -738,6 +738,29 @@ struct v4l2_crop {
   struct v4l2_rectc;
  };
  
 +/* Hints for adjustments of selection rectangle */
 +#define V4L2_SEL_SIZE_GE 0x0001
 +#define V4L2_SEL_SIZE_LE 0x0002
 +
 +enum v4l2_sel_target {
 + V4L2_SEL_CROP_ACTIVE  = 0,
 + V4L2_SEL_CROP_DEFAULT = 1,
 + V4L2_SEL_CROP_BOUNDS  = 2,
 + V4L2_SEL_COMPOSE_ACTIVE  = 256 + 0,
 + V4L2_SEL_COMPOSE_DEFAULT = 256 + 1,
 + V4L2_SEL_COMPOSE_BOUNDS  = 256 + 2,
 + V4L2_SEL_COMPOSE_PADDED  = 256 + 3,

What about defining V4L2_SEL_COMPOSE_BASE, for exmaple, and using that
instead of plain 256?

Also, as you change rhe enum to __u32 as Laurent suggested already, the enum
no longer needs a name. Whether it should have nde is another question. I
don't see a reason to have one.

 +};
 +
 +struct v4l2_selection {
 + enum v4l2_buf_type  type;
 + enum v4l2_sel_targettarget;
 + __u32   flags;
 + struct v4l2_rectr;
 + __u32   reserved[9];
 +};
 +
 +
  /*
   *  A N A L O G   V I D E O   S T A N D A R D
   */
 @@ -2182,6 +2205,10 @@ struct v4l2_dbg_chip_ident {
  #define  VIDIOC_SUBSCRIBE_EVENT   _IOW('V', 90, struct 
 v4l2_event_subscription)
  #define  VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct 
 v4l2_event_subscription)
  
 +/* Experimental crop/compose API */
 +#define VIDIOC_G_SELECTION   _IOWR('V', 92, struct v4l2_selection)
 +#define VIDIOC_S_SELECTION   _IOWR('V', 93, struct v4l2_selection)
 +
  /* Reminder: when adding new ioctls please add support for them to
 drivers/media/video/v4l2-compat-ioctl32.c as well! */
  
 diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
 index dd9f1e7..2c0396b 100644
 --- a/include/media/v4l2-ioctl.h
 +++

Re: [PATCH] media: none of the drivers should be enabled by default

On Tue, 30 Aug 2011, Hans Verkuil wrote:

 On Tuesday, August 30, 2011 22:12:09 Guennadi Liakhovetski wrote:
  On Tue, 30 Aug 2011, Hans Verkuil wrote:
  
   On Tuesday, August 30, 2011 19:22:00 Guennadi Liakhovetski wrote:
None of the media drivers are compulsory, let users select which drivers
they want to build, instead of having to unselect them one by one.
   
   I disagree with this: while this is fine for SoCs, for a generic kernel I
   think it is better to build it all. Even expert users can have a hard time
   figuring out what chip is in a particular device.
  
  Then could someone, please, explain to me, why I don't find this 
  convenience in any other kernel driver class? Wireless, ALSA, USB, I2C - 
  you name them. Is there something special about media, that I'm missing, 
  or are all others just user-unfriendly? Why are distro-kernels, 
  allmodconfig, allyesconfig not enough for media and we think it's 
  necessary to build everything just in case?
 
 That's actually a good question. I certainly think that the more obscure
 drivers can be disabled by default. But I also think that you want to keep
 a certain subset of commonly used drivers enabled. I'm thinking bttv, uvc,
 perhaps gspca.

Good, this is a good beginning! It was actually the purpose of my patch - 
to make us actually consider which drivers we need enabled per default, 
and which we don't, instead of just enabling all.

 As far as I can see, alsa enables for example HD Audio, which almost all
 modern hw supports. We should do something similar for v4l.

Yes, agree.

 And we should really reorder some of the entries in the menu: one of the
 first drivers you see are parallel port webcams and other very obscure
 devices.

Ok.

So, how should we proceed? What I certainly would like to disable 
completely or to 99% are remote controls and tuners. The rest are actually 
disabled by default, which is great. Or at least I would like to have a 
single switch disable all, ideally active by default. One of the 
possibilities would be to take the patch as is and _then_ begin to think, 
which drivers we want enabled by default. I just think, that the correct 
approach is to think, which drivers we need enabled by default - as 
exceptions, instead of - which drivers we can afford to disable.

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

Re: [PATCH] media: none of the drivers should be enabled by default

On Tue, 30 Aug 2011, Michael Krufky wrote:

 On Tue, Aug 30, 2011 at 4:12 PM, Guennadi Liakhovetski
 g.liakhovet...@gmx.de wrote:
  On Tue, 30 Aug 2011, Hans Verkuil wrote:
 
  On Tuesday, August 30, 2011 19:22:00 Guennadi Liakhovetski wrote:
   None of the media drivers are compulsory, let users select which drivers
   they want to build, instead of having to unselect them one by one.
 
  I disagree with this: while this is fine for SoCs, for a generic kernel I
  think it is better to build it all. Even expert users can have a hard time
  figuring out what chip is in a particular device.
 
  Then could someone, please, explain to me, why I don't find this
  convenience in any other kernel driver class? Wireless, ALSA, USB, I2C -
  you name them. Is there something special about media, that I'm missing,
  or are all others just user-unfriendly? Why are distro-kernels,
  allmodconfig, allyesconfig not enough for media and we think it's
  necessary to build everything just in case?
 
 
 This isn't a matter of building all drivers by default -- it is a
 matter of building component dependency drivers that are needed by the
 bridge drivers, and allowing users to not build drivers that they
 don't need.

I would understand, if in the beginning all was empty (all drivers 
disabled), then the user goes to his or her card entry, enables it. And 
since that card has a 100 of variations, and we don't know exactly which 
of them the user has, we enable all components, possibly present on this 
card. This would make sense. Howevre, this is not what we currently have.

 The customization options are there to allow you to
 disable the helper chips / tuners etc from all being built if that
 is your choice.  If you disable the customization options, then
 Kconfig automatically selects the dependencies of the bridge drivers
 that you've selected and does NOT build those that are irrelevant to
 you.

Hm, that's not what I see. I just tried the following: made a default 
x86_64 .config, it had media disabled. Then I enabled media and alreay a 
bunch of IR remotes has been enabled. Then I enabled V4L, and all tuners 
got enabled. Switching on customize allowed me to kill them selectively. 
So, I don't see what you described above: how those tuners only get to 
build, if I enable respective bridges. Or have I misunderstood you?

Thanks
Guennadi

 At first, users were forced to build everything without being
 able to disable these modules.  We added this mechanism to allow such
 modules to be disabled from a build, but we enable them by default
 because anything else would become a user-support nightmare, as I
 stated earlier.  If you refer to the mailing list archives from about
 four or five years ago, you'll may find that this was discussed at
 length on the video4linux and linux-dvb mailing lists.  In the end I
 believe this is the solution that satisfied everybody the best.
 
 -Mike Krufky
 
  Thanks
  Guennadi
 
 
  Regards,
 
        Hans
 
   Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
   ---
    drivers/media/common/tuners/Kconfig |   23 +--
    drivers/media/radio/Kconfig         |    1 -
    drivers/media/rc/Kconfig            |   16 +---
    drivers/media/rc/keymaps/Kconfig    |    1 -
    drivers/media/video/Kconfig         |    7 ++-
    5 files changed, 4 insertions(+), 44 deletions(-)
  
   diff --git a/drivers/media/common/tuners/Kconfig 
   b/drivers/media/common/tuners/Kconfig
   index 996302a..1e53057 100644
   --- a/drivers/media/common/tuners/Kconfig
   +++ b/drivers/media/common/tuners/Kconfig
   @@ -33,7 +33,7 @@ config MEDIA_TUNER
       select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE
  
    config MEDIA_TUNER_CUSTOMISE
   -   bool Customize analog and hybrid tuner modules to build
   +   bool Select analog and hybrid tuner modules to build
       depends on MEDIA_TUNER
       default y if EXPERT
       help
   @@ -52,7 +52,6 @@ config MEDIA_TUNER_SIMPLE
       tristate Simple tuner support
       depends on VIDEO_MEDIA  I2C
       select MEDIA_TUNER_TDA9887
   -   default m if MEDIA_TUNER_CUSTOMISE
       help
         Say Y here to include support for various simple tuners.
  
   @@ -61,28 +60,24 @@ config MEDIA_TUNER_TDA8290
       depends on VIDEO_MEDIA  I2C
       select MEDIA_TUNER_TDA827X
       select MEDIA_TUNER_TDA18271
   -   default m if MEDIA_TUNER_CUSTOMISE
       help
         Say Y here to include support for Philips TDA8290+8275(a) tuner.
  
    config MEDIA_TUNER_TDA827X
       tristate Philips TDA827X silicon tuner
       depends on VIDEO_MEDIA  I2C
   -   default m if MEDIA_TUNER_CUSTOMISE
       help
         A DVB-T silicon tuner module. Say Y when you want to support this 
   tuner.
  
    config MEDIA_TUNER_TDA18271
       tristate NXP TDA18271 silicon tuner
       depends on VIDEO_MEDIA  I2C
   -   default m if MEDIA_TUNER_CUSTOMISE
       help
         A silicon tuner module. Say Y when you want to support this tuner.

Re: [PATCH] media: none of the drivers should be enabled by default

On Tue, Aug 30, 2011 at 5:47 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 On Tue, 30 Aug 2011, Michael Krufky wrote:

 On Tue, Aug 30, 2011 at 4:12 PM, Guennadi Liakhovetski
 g.liakhovet...@gmx.de wrote:
  On Tue, 30 Aug 2011, Hans Verkuil wrote:
 
  On Tuesday, August 30, 2011 19:22:00 Guennadi Liakhovetski wrote:
   None of the media drivers are compulsory, let users select which drivers
   they want to build, instead of having to unselect them one by one.
 
  I disagree with this: while this is fine for SoCs, for a generic kernel I
  think it is better to build it all. Even expert users can have a hard time
  figuring out what chip is in a particular device.
 
  Then could someone, please, explain to me, why I don't find this
  convenience in any other kernel driver class? Wireless, ALSA, USB, I2C -
  you name them. Is there something special about media, that I'm missing,
  or are all others just user-unfriendly? Why are distro-kernels,
  allmodconfig, allyesconfig not enough for media and we think it's
  necessary to build everything just in case?


 This isn't a matter of building all drivers by default -- it is a
 matter of building component dependency drivers that are needed by the
 bridge drivers, and allowing users to not build drivers that they
 don't need.

 I would understand, if in the beginning all was empty (all drivers
 disabled), then the user goes to his or her card entry, enables it. And
 since that card has a 100 of variations, and we don't know exactly which
 of them the user has, we enable all components, possibly present on this
 card. This would make sense. Howevre, this is not what we currently have.

 The customization options are there to allow you to
 disable the helper chips / tuners etc from all being built if that
 is your choice.  If you disable the customization options, then
 Kconfig automatically selects the dependencies of the bridge drivers
 that you've selected and does NOT build those that are irrelevant to
 you.

 Hm, that's not what I see. I just tried the following: made a default
 x86_64 .config, it had media disabled. Then I enabled media and alreay a
 bunch of IR remotes has been enabled. Then I enabled V4L, and all tuners
 got enabled. Switching on customize allowed me to kill them selectively.
 So, I don't see what you described above: how those tuners only get to
 build, if I enable respective bridges. Or have I misunderstood you?

You understood me correctly -- your experience described above reveals
to us that the dependency system somehow got broken and now we're
building too much by default.

Maybe we should make the VIDEO_TUNER symbol as well as VIDEO_IR etc
visible options so that those only looking to build webcams can turn
them off all at once.

I'd like to hear Mauro's comments on this.

-Mike

 At first, users were forced to build everything without being
 able to disable these modules.  We added this mechanism to allow such
 modules to be disabled from a build, but we enable them by default
 because anything else would become a user-support nightmare, as I
 stated earlier.  If you refer to the mailing list archives from about
 four or five years ago, you'll may find that this was discussed at
 length on the video4linux and linux-dvb mailing lists.  In the end I
 believe this is the solution that satisfied everybody the best.

 -Mike Krufky
 
  Thanks
  Guennadi
 
 
  Regards,
 
        Hans
 
   Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
   ---
    drivers/media/common/tuners/Kconfig |   23 +--
    drivers/media/radio/Kconfig         |    1 -
    drivers/media/rc/Kconfig            |   16 +---
    drivers/media/rc/keymaps/Kconfig    |    1 -
    drivers/media/video/Kconfig         |    7 ++-
    5 files changed, 4 insertions(+), 44 deletions(-)
  
   diff --git a/drivers/media/common/tuners/Kconfig 
   b/drivers/media/common/tuners/Kconfig
   index 996302a..1e53057 100644
   --- a/drivers/media/common/tuners/Kconfig
   +++ b/drivers/media/common/tuners/Kconfig
   @@ -33,7 +33,7 @@ config MEDIA_TUNER
       select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE
  
    config MEDIA_TUNER_CUSTOMISE
   -   bool Customize analog and hybrid tuner modules to build
   +   bool Select analog and hybrid tuner modules to build
       depends on MEDIA_TUNER
       default y if EXPERT
       help
   @@ -52,7 +52,6 @@ config MEDIA_TUNER_SIMPLE
       tristate Simple tuner support
       depends on VIDEO_MEDIA  I2C
       select MEDIA_TUNER_TDA9887
   -   default m if MEDIA_TUNER_CUSTOMISE
       help
         Say Y here to include support for various simple tuners.
  
   @@ -61,28 +60,24 @@ config MEDIA_TUNER_TDA8290
       depends on VIDEO_MEDIA  I2C
       select MEDIA_TUNER_TDA827X
       select MEDIA_TUNER_TDA18271
   -   default m if MEDIA_TUNER_CUSTOMISE
       help
         Say Y here to include support for Philips TDA8290+8275(a) tuner.
  
    config MEDIA_TUNER_TDA827X
       tristate

Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)

Hi,

On Monday 29 August 2011 22:48:46 Sitsofe Wheeler wrote:
 Hi,
 
 I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a
 USB webcam.

Thanks for the report. Can you reproduce this on v3.0 ? What were the exact 
steps that led to the crash ?

-- 
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: Getting started with OMAP3 ISP


On 2011-08-29 04:49, Laurent Pinchart wrote:

Hi Gary,

On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:

Background:  I have working video capture drivers based on the
TI PSP codebase from 2.6.32.  In particular, I managed to get
a driver for the TVP5150 (analogue BT656) working with that kernel.

Now I need to update to Linux 3.0, so I'm trying to get a driver
working with the rewritten ISP code.  Sadly, I'm having a hard
time with this - probably just missing something basic.

I've tried to clone the TVP514x driver which says that it works
with the OMAP3 ISP code.  I've updated it to use my decoder device,
but I can't even seem to get into that code from user land.

Here are the problems I've had so far:
* udev doesn't create any video devices although they have been
  registered.  I see a full set in /sys/class/video4linux
 # ls /sys/class/video4linux/
 v4l-subdev0  v4l-subdev3  v4l-subdev6  video1   video4
 v4l-subdev1  v4l-subdev4  v4l-subdev7  video2   video5
 v4l-subdev2  v4l-subdev5  video0   video3   video6


It looks like a udev issue. I don't think that's related to the kernel
drivers.


  Indeed, if I create /dev/videoX by hand, I can get somewhere, but
  I don't really understand how this is supposed to work.  e.g.
# v4l2-dbg --info /dev/video3
Driver info:
Driver name   : ispvideo
Card type : OMAP3 ISP CCP2 input
Bus info  : media
Driver version: 1
Capabilities  : 0x0402
Video Output
Streaming

* If I try to grab video, the ISP layer gets a ton of warnings, but
  I never see it call down into my driver, e.g. to check the current
  format, etc.  I have some of my own code from before which fails
  miserably (not a big surprise given the hack level of those programs).
  I tried something off-the-shelf which also fails pretty bad:
# ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
junk.mp4

I've read through Documentation/video4linux/omap3isp.txt without learning
much about what might be wrong.

Can someone give me some ideas/guidance, please?


In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and
then capture video.

Configuring the pipeline is done through the media controller API and the V4L2
subdev pad-level API. To experiment with those you can use the media-ctl
command line application available at http://git.ideasonboard.org/?p=media-
ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot
-Tps to get a postscript graphical view of your device.

Here's a sample pipeline configuration to capture scaled-down YUV data from a
sensor:

./media-ctl -r -l 'mt9t001 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP
CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP
resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
./media-ctl -f 'mt9t001 3-005d:0[SGRBG10 1024x768], OMAP3 ISP
CCDC:2[SGRBG10 1024x767], OMAP3 ISP preview:1[YUYV 1006x759], OMAP3 ISP
resizer:1[YUYV 800x600]'

After configuring your pipeline you will be able to capture video using the
V4L2 API on the device node at the output of the pipeline.


Getting somewhere now, thanks.  When I use this full pipeline, I can get all
the way into my driver where it's trying to start the data.

What if I want to use less of the pipeline?  For example, I'd normally be
happy with just the CCDC output.  How would I do that?  What pixel format
would I use with ffmpeg?

n.b. I know most of these are pretty n00b questions - I'd look up the
answers for myself, but I've had precious little success finding any
documentation, especially on media-ctl and/or the OMAP3 ISP setups.

Thanks again

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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: Getting started with OMAP3 ISP

Hi Gary,

On Wednesday 31 August 2011 00:45:39 Gary Thomas wrote:
 On 2011-08-29 04:49, Laurent Pinchart wrote:
  On Thursday 25 August 2011 18:07:38 Gary Thomas wrote:
  Background:  I have working video capture drivers based on the
  TI PSP codebase from 2.6.32.  In particular, I managed to get
  a driver for the TVP5150 (analogue BT656) working with that kernel.
  
  Now I need to update to Linux 3.0, so I'm trying to get a driver
  working with the rewritten ISP code.  Sadly, I'm having a hard
  time with this - probably just missing something basic.
  
  I've tried to clone the TVP514x driver which says that it works
  with the OMAP3 ISP code.  I've updated it to use my decoder device,
  but I can't even seem to get into that code from user land.
  
  Here are the problems I've had so far:
  * udev doesn't create any video devices although they have been
  
registered.  I see a full set in /sys/class/video4linux

   # ls /sys/class/video4linux/
   v4l-subdev0  v4l-subdev3  v4l-subdev6  video1   video4
   v4l-subdev1  v4l-subdev4  v4l-subdev7  video2   video5
   v4l-subdev2  v4l-subdev5  video0   video3   video6
  
  It looks like a udev issue. I don't think that's related to the kernel
  drivers.
  
Indeed, if I create /dev/videoX by hand, I can get somewhere, but
I don't really understand how this is supposed to work.  e.g.

  # v4l2-dbg --info /dev/video3
  
  Driver info:
  Driver name   : ispvideo
  Card type : OMAP3 ISP CCP2 input
  Bus info  : media
  Driver version: 1
  Capabilities  : 0x0402
  
  Video Output
  Streaming
  
  * If I try to grab video, the ISP layer gets a ton of warnings, but
  
I never see it call down into my driver, e.g. to check the current
format, etc.  I have some of my own code from before which fails
miserably (not a big surprise given the hack level of those
programs).

I tried something off-the-shelf which also fails pretty bad:
  # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2
  
  junk.mp4
  
  I've read through Documentation/video4linux/omap3isp.txt without
  learning much about what might be wrong.
  
  Can someone give me some ideas/guidance, please?
  
  In a nutshell, you will first have to configure the OMAP3 ISP pipeline,
  and then capture video.
  
  Configuring the pipeline is done through the media controller API and the
  V4L2 subdev pad-level API. To experiment with those you can use the
  media-ctl command line application available at
  http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it
  with --print-dot and pipe the result to dot -Tps to get a postscript
  graphical view of your device.
  
  Here's a sample pipeline configuration to capture scaled-down YUV data
  from a sensor:
  
  ./media-ctl -r -l 'mt9t001 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP
  CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP
  resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
  ./media-ctl -f 'mt9t001 3-005d:0[SGRBG10 1024x768], OMAP3 ISP
  CCDC:2[SGRBG10 1024x767], OMAP3 ISP preview:1[YUYV 1006x759], OMAP3
  ISP resizer:1[YUYV 800x600]'
  
  After configuring your pipeline you will be able to capture video using
  the V4L2 API on the device node at the output of the pipeline.
 
 Getting somewhere now, thanks.  When I use this full pipeline, I can get
 all the way into my driver where it's trying to start the data.
 
 What if I want to use less of the pipeline?  For example, I'd normally be
 happy with just the CCDC output.  How would I do that?

Then connect CCDC's pad 1 to the CCDC output video node and capture on that 
video node.

 What pixel format would I use with ffmpeg?

What does your subdev deliver ?

 n.b. I know most of these are pretty n00b questions - I'd look up the
 answers for myself, but I've had precious little success finding any
 documentation, especially on media-ctl and/or the OMAP3 ISP setups.

-- 
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: Afatech AF9013

2011-08-30 Thread Malcolm Priestley

On Mon, 2011-08-29 at 20:40 +0200, Josu Lazkano wrote:
2011/8/23 Jason Hecker jwhec...@gmail.com:
Damn, this patch didn't help so maybe forget this patch. Tuner A is
still messed up.

Hello, thanks all to reply this post. I have no idea how to apply the
patch on my Debian Squeeze. Can you help to apply the patch?

Thanks your all your help.
It is best applied using media_build and using a copy from the patchwork
server. You can just copy the raw email to a text file, but sometimes it
is malformed.

Since you originally used s2-liplianin you just need patchutils to apply
it to that. However, since it is older, I doubt it will apply cleanly.

https://patchwork.kernel.org/patch/1090012/

For media build, check if the required packages for Debian Squeeze are
the same as Ubuntu.

But, it appears the patch makes no difference.

Regards

Malcolm

MEDIA BUILD INSTALL (Instructions here are for Ubuntu)

Using Terminal install git, patchutils and perl with
sudo apt-get install git(or git-core)
sudo apt-get install patchutils
sudo apt-get install libdigest-sha1-perl
sudo apt-get install libproc-processtable-perl

Always build somewhere in your home directory with local user rights.
Only use super user rights to install.

git clone git://linuxtv.org/media_build.git

cd media_build

---NO PATCH---

./build

sudo make install

---PATCH TO BE APPLIED---

Download any patch and place in the media_build directory and apply in
the following way.

./build (skip this if already built)

Wait for download and start to build. If you are confident that the
build will complete without errors break the build with CTRL C

Apply the patch. Make sure if applying multipliable patches they are
applied oldest first.

Just test the patch.
patch -d linux -p1 --dry-run the_patch_name.patch

If okay apply it.
patch -d linux -p1 the_patch_name.patch

make distclean

make

sudo make install

More in depth instructions here
http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers

--
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: Getting started with OMAP3 ISP