date:20110505

Hi Javier,

On Thursday 05 May 2011 12:17:12 Guennadi Liakhovetski wrote:
 On Thu, 5 May 2011, javier Martin wrote:
  Hi,
  as you know I'm currently working on submitting mt9p031 driver to
  mainline, testing it with my Beagleboard xM.
  While I was trying to clean Guennadi's patches I ran into the attached
  patch which changes a call to omap3isp_get(isp); into
  isp_enable_clocks(isp);.
  
  I don't think this is clean since it would unbalance the number of
  omap3isp_get() vs omap3isp_put() and we probably don't want that.
  What seems clear is if we don't apply this patch the clock is not
  actually enabled.
  
  According to my debugging results isp_disable_clocks() is never
  called, so, after the first call to isp_enable_clocks() there
  shouldn't be any need to enable the clocks again.
  
  Guennadi, do you know what is the cause of the problem?
 
 I don't remember exactly, but it didn't work without this patch. I know it
 is not clean and shouldn't be needed, so, if now it works also without it
 - perfect! You can start, stop, and restart streaming without this patch
 and it all works? Then certainly it should be dropped.

And otherwise you can work on a fix ;-) I unfortunately have no sensor module 
for the Beagleboard xM so I can't really test this.

-- 
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: omap3isp clock problems on Beagleboard xM.

2011-05-05 Thread javier Martin

Thank you two guys for your answer.

 I don't remember exactly, but it didn't work without this patch. I know it
 is not clean and shouldn't be needed, so, if now it works also without it
 - perfect! You can start, stop, and restart streaming without this patch
 and it all works? Then certainly it should be dropped.

No, sorry, what I meant is although, according to my debugging results
the patch shouldn't be needed, it still does not work without it.

I'll try to track down the issue and I'll work on a fix myself.



-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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: Patches still pending at linux-media queue (18 patches)

Em 05-05-2011 05:30, Sakari Ailus escreveu:
 Mauro Carvalho Chehab wrote:
  == waiting for Sakari Ailus 
 sakari.ai...@maxwell.research.nokia.com submission == 

 Sakari,

  I'm understanding that you'll be handling this one.

 Feb,19 2011: [RFC/PATCH,1/1] tcm825x: convert driver to V4L2 sub device 
 interface   http://patchwork.kernel.org/patch/574931  David Cohen 
 daco...@gmail.com
 
 Hi Mauro,
 
 This is mine and David's long term task. :-)
 
 The tcm825x is the other user of the old v4l2-int-device framework, the
 one being omap24xxcam. Both are used on the N8[01]0.
 
 Conversion of both of the drivers should go in at the same time. Then
 the v4l2-int-device framework can be removed. I'll work with David on
 this. (Cc David.)

Thanks! I'll mark this as RFC at patchwork, as you may probably need to
do another round on it.

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

Re: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder

Em 05-05-2011 01:25, Manu Abraham escreveu:
 On Wed, May 4, 2011 at 3:16 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Em 13-04-2011 21:05, Lutz Sammer escreveu:
 On 05/04/11 21:07, Steffen Barszus wrote:
 On Tue, 05 Apr 2011 13:00:14 +0200
 Issa Gorissen flop.m@xxx wrote:

 Hi,

 Eutelsat made a recent migration from DVB-S to DVB-S2 (since
 31/3/2011) on two transponders on HB13E

 - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500
 Msymb/s 0.2 Pilot off Polar H

 - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500
 Msymb/s 0.2 Pilot off Polar H


 Before those changes, with my TT S2 3200, I was able to watch TV on
 those transponders. Now, I cannot even tune on those transponders. I
 have tried with scan-s2 and w_scan and the latest drivers from git.
 They both find the transponders but cannot tune onto it.

 Something noteworthy is that my other card, a DuoFlex S2 can tune
 fine on those transponders.

 My question is; can someone try this as well with a TT S2 3200 and
 post the results ?
 i read something about it lately here (german!):
 http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938

 It says in stb0899_drv.c function:
 static void stb0899_set_iterations(struct stb0899_state *state)

 This:
 reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER);
 STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale);
 stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, 
 STB0899_OFF0_MAX_ITER, reg);

 should be replaced with this:

 reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER);
 STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale);
 stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, 
 STB0899_OFF0_MAX_ITER, reg);

 Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines
 affected.

 Kind Regards

 Steffen
 Hi Steffen,

 Unfortunately, it does not help in my case. Thx anyway.

 Try my locking fix. With above patch I can lock the
 channels without problem.

 Can someone confirm that such patch would fix the issue? If so, please
 forward it in a way that it could be applied (patch is currently 
 line-wrapped),
 and submit with some comments/description and your SOB.

 As the patch is currently broken, I'm just marking it as rejected at 
 patchwork.

 Manu,

 Please take a look on this trouble report.

 Thanks!
 Mauro.
 
 
 I am out of station currently. I will take a deeper look at it during
 the weekend or next week.

Ok, thank you!

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

Re: Patches still pending at linux-media queue (18 patches)

Em 05-05-2011 03:24, Hans Verkuil escreveu:
 On Thursday, May 05, 2011 05:58:51 Mauro Carvalho Chehab wrote:
 Hans,
  I believe that want to replace this patch by something else, but better 
 to keep it at the list while you don't
 send us a replacement.

 Mar,26 2011: [media] cpia2: fix typo in variable initialisation  
http://patchwork.kernel.org/patch/665951  Mariusz Kozlowski 
 m...@lab.zgora.pl
 
 Feel free to merge this. It makes a broken driver slightly less broken.
 
 I don't know when I will have time to create a proper patch that fixes this
 driver. I need to get the work I'm doing on the control framework done first,
 and that is taking a lot longer than I would like. But there is no sense in
 keeping this patch back.
 
 While working on the control framework I found a few bugs. I'll try to make
 a pull request fixing them today or tomorrow at the latest.

Ok, thanks for acking on merging this.

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

Re: Patches still pending at linux-media queue (18 patches)

Em 05-05-2011 07:13, Andy Walls escreveu:
 
 Mauro,
 
 Since the original cx18 mmap() patch was commited, the cx18 mmap() cleanup 
 patch is definitely needed: the YUV stream can lose frame alignment without 
 it.
 
 I took a quick look at the cx18 mmap() cleanup patch:
 
 Acked-by: Andy Walls awa...@md.metrocast.net
 
 The cx18 version bump patch is trivial:
 
 Acked-by: Andy Walls awa...@md.metrocast.net

Ok, thank you!

Applied both.

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

Re: [GIT PATCHES FOR 2.6.40] Make the UVC API public (and minor enhancements)

Em 27-04-2011 07:38, Laurent Pinchart escreveu:
 Hi Mauro,
 
 These patches move the uvcvideo.h header file from drivers/media/video/uvc
 to include/linux, making the UVC API public. Support for the old API is kept
 and will be removed in 2.6.42.
 
 The following changes since commit a4761a092fd3b6bf8b5f9cfe361670c86cdcc8ca:
 
   [media] tm6000: fix vbuf may be used uninitialized (2011-04-19 21:13:59 
 -0300)
 
 are available in the git repository at:
   git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next
 
 Laurent Pinchart (5):
   uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
   uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*
   uvcvideo: Make the API public

Why are you declaring this twice:

Index: patchwork/drivers/media/video/uvc/uvcvideo.h

...

+#ifndef __KERNEL__
 #define UVCIOC_CTRL_ADD  _IOW('U', 1, struct uvc_xu_control_info)
#define UVCIOC_CTRL_MAP_OLD  _IOWR('U', 2, struct uvc_xu_control_mapping_old)
 #define UVCIOC_CTRL_MAP  _IOWR('U', 2, struct 
uvc_xu_control_mapping)
 #define UVCIOC_CTRL_GET  _IOWR('U', 3, struct uvc_xu_control)
 #define UVCIOC_CTRL_SET_IOW('U', 4, struct uvc_xu_control)
-#define UVCIOC_CTRL_QUERY_IOWR('U', 5, struct uvc_xu_control_query)
+#else
+#define __UVCIOC_CTRL_ADD_IOW('U', 1, struct uvc_xu_control_info)
+#define __UVCIOC_CTRL_MAP_OLD_IOWR('U', 2, struct 
uvc_xu_control_mapping_old)
+#define __UVCIOC_CTRL_MAP_IOWR('U', 2, struct uvc_xu_control_mapping)
+#define __UVCIOC_CTRL_GET_IOWR('U', 3, struct uvc_xu_control)
+#define __UVCIOC_CTRL_SET_IOW('U', 4, struct uvc_xu_control)
+#endif

You shouldn't need to do that. In fact, the better would be to have two separate
headers: one with just the public API under include/linux, and another with the
extra uvc-internal bits, as we did in the past with videobuf2.h.

As the other patches don't depend on this one, I'm applying the remaining 
patches,
in order to save me the time of review the entire series again.

   uvcvideo: Add support for V4L2_PIX_FMT_RGB565
   uvcvideo: Add support for JMicron USB2.0 XGA WebCam
 
 Martin Rubli (2):
   uvcvideo: Add UVCIOC_CTRL_QUERY ioctl
   uvcvideo: Add driver documentation
 
  Documentation/feature-removal-schedule.txt |   23 ++
  Documentation/ioctl/ioctl-number.txt   |2 +-
  Documentation/video4linux/uvcvideo.txt |  239 
  drivers/media/video/uvc/uvc_ctrl.c |  332 
 +---
  drivers/media/video/uvc/uvc_driver.c   |   14 ++
  drivers/media/video/uvc/uvc_v4l2.c |   51 -
  drivers/media/video/uvc/uvcvideo.h |   57 --
  include/linux/Kbuild   |1 +
  include/linux/uvcvideo.h   |   69 ++
  9 files changed, 625 insertions(+), 163 deletions(-)
  create mode 100644 Documentation/video4linux/uvcvideo.txt
  create mode 100644 include/linux/uvcvideo.h
 

--
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: [GIT PATCHES FOR 2.6.40] Make the UVC API public (and minor enhancements)

Hi Mauro,

On Thursday 05 May 2011 13:33:20 Mauro Carvalho Chehab wrote:
 Em 27-04-2011 07:38, Laurent Pinchart escreveu:
  Hi Mauro,
  
  These patches move the uvcvideo.h header file from
  drivers/media/video/uvc to include/linux, making the UVC API public.
  Support for the old API is kept and will be removed in 2.6.42.
  
  The following changes since commit 
a4761a092fd3b6bf8b5f9cfe361670c86cdcc8ca:
[media] tm6000: fix vbuf may be used uninitialized (2011-04-19 21:13:59
-0300)
  
  are available in the git repository at:
git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next
  
  Laurent Pinchart (5):
uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*
uvcvideo: Make the API public
 
 Why are you declaring this twice:
 
 Index: patchwork/drivers/media/video/uvc/uvcvideo.h
 
 ...
 
+#ifndef __KERNEL__
 #define UVCIOC_CTRL_ADD _IOW('U', 1, struct uvc_xu_control_info)
 #define UVCIOC_CTRL_MAP_OLD _IOWR('U', 2, struct uvc_xu_control_mapping_old)
 #define UVCIOC_CTRL_MAP _IOWR('U', 2, struct uvc_xu_control_mapping)
 #define UVCIOC_CTRL_GET _IOWR('U', 3, struct uvc_xu_control)
 #define UVCIOC_CTRL_SET _IOW('U', 4, struct uvc_xu_control)
-#define UVCIOC_CTRL_QUERY   _IOWR('U', 5, struct uvc_xu_control_query)
+#else
+#define __UVCIOC_CTRL_ADD   _IOW('U', 1, struct uvc_xu_control_info)
+#define __UVCIOC_CTRL_MAP_OLD _IOWR('U', 2, struct 
uvc_xu_control_mapping_old)
+#define __UVCIOC_CTRL_MAP   _IOWR('U', 2, struct uvc_xu_control_mapping)
+#define __UVCIOC_CTRL_GET   _IOWR('U', 3, struct uvc_xu_control)
+#define __UVCIOC_CTRL_SET   _IOW('U', 4, struct uvc_xu_control)
+#endif

For compatibility with existing applications. Applications should now include 
linux/uvcvideo.h instead of drivers/media/video/uvc/uvcvideo.h, but existing 
applications include the later. I want to make sure they will still compile. A 
warning will be printed, and this will be removed in 2.6.42.

 You shouldn't need to do that. In fact, the better would be to have two
 separate headers: one with just the public API under include/linux, and
 another with the extra uvc-internal bits, as we did in the past with
 videobuf2.h.

That's how linux/uvcvideo.h and drivers/media/video/uvc/uvcvideo.h are 
partitioned by this patch set, except that the private header still contains 
userspace API to avoid breaking applications during the transition period.

 As the other patches don't depend on this one, I'm applying the remaining
 patches, in order to save me the time of review the entire series again.
 
uvcvideo: Add support for V4L2_PIX_FMT_RGB565
uvcvideo: Add support for JMicron USB2.0 XGA WebCam
  
  Martin Rubli (2):
uvcvideo: Add UVCIOC_CTRL_QUERY ioctl
uvcvideo: Add driver documentation
   
   Documentation/feature-removal-schedule.txt |   23 ++
   Documentation/ioctl/ioctl-number.txt   |2 +-
   Documentation/video4linux/uvcvideo.txt |  239 
   drivers/media/video/uvc/uvc_ctrl.c |  332
   +--- drivers/media/video/uvc/uvc_driver.c  
   |   14 ++
   drivers/media/video/uvc/uvc_v4l2.c |   51 -
   drivers/media/video/uvc/uvcvideo.h |   57 --
   include/linux/Kbuild   |1 +
   include/linux/uvcvideo.h   |   69 ++
   9 files changed, 625 insertions(+), 163 deletions(-)
   create mode 100644 Documentation/video4linux/uvcvideo.txt
   create mode 100644 include/linux/uvcvideo.h

-- 
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] cx18: Clean up mmap() support for raw YUV

Hi Simon,

Em 04-05-2011 06:32, Simon Farnsworth escreveu:
 On Tuesday 3 May 2011, Andy Walls awa...@md.metrocast.net wrote:
 Simon,

 If these two changes are going in, please also bump the driver version to
 1.5.0 in cx18-version.c.  These changes are significant enough
 perturbation.

 End users are going to look to driver version 1.4.1 as the first version
 for proper analog tuner support of the HVR1600 model 74351.

 Mauro,

 Is cx18 v1.4.1 with HVR1600 model 74351 analog tuner support, without these
 mmap() changes going to be visible in kernel version .39 ?

 
 Mauro,
 
 If you're going to accept these two patches, would you mind bumping the 
 version in cx18-version.c for me as you apply them, or would you prefer me to 
 provide either an incremental patch or a new patch with the bump added?

There are a few new warnings with your code:

drivers/media/video/cx18/cx18-mailbox.c: In function 
‘cx18_mdl_send_to_videobuf’:
drivers/media/video/cx18/cx18-mailbox.c:206: warning: passing argument 1 of 
‘ktime_get_ts’ from incompatible pointer type
include/linux/ktime.h:331: note: expected ‘struct timespec *’ but argument is 
of type ‘struct timeval *’
drivers/media/video/cx18/cx18-mailbox.c:170: warning: unused variable ‘i’
drivers/media/video/cx18/cx18-mailbox.c:167: warning: unused variable ‘u’

Could you please fix them?

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

Re: [GIT PATCHES FOR 2.6.40] Make the UVC API public (and minor enhancements)

Em 05-05-2011 08:40, Laurent Pinchart escreveu:
 Hi Mauro,
 
 On Thursday 05 May 2011 13:33:20 Mauro Carvalho Chehab wrote:
 Em 27-04-2011 07:38, Laurent Pinchart escreveu:
 Hi Mauro,

 These patches move the uvcvideo.h header file from
 drivers/media/video/uvc to include/linux, making the UVC API public.
 Support for the old API is kept and will be removed in 2.6.42.

 The following changes since commit 
 a4761a092fd3b6bf8b5f9cfe361670c86cdcc8ca:
   [media] tm6000: fix vbuf may be used uninitialized (2011-04-19 21:13:59
   -0300)

 are available in the git repository at:
   git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next

 Laurent Pinchart (5):
   uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
   uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*
   uvcvideo: Make the API public

 Why are you declaring this twice:

 Index: patchwork/drivers/media/video/uvc/uvcvideo.h

 ...

 +#ifndef __KERNEL__
 #define UVCIOC_CTRL_ADD _IOW('U', 1, struct uvc_xu_control_info)
 #define UVCIOC_CTRL_MAP_OLD _IOWR('U', 2, struct uvc_xu_control_mapping_old)
 #define UVCIOC_CTRL_MAP _IOWR('U', 2, struct uvc_xu_control_mapping)
 #define UVCIOC_CTRL_GET _IOWR('U', 3, struct uvc_xu_control)
 #define UVCIOC_CTRL_SET _IOW('U', 4, struct uvc_xu_control)
 -#define UVCIOC_CTRL_QUERY   _IOWR('U', 5, struct uvc_xu_control_query)
 +#else
 +#define __UVCIOC_CTRL_ADD   _IOW('U', 1, struct uvc_xu_control_info)
 +#define __UVCIOC_CTRL_MAP_OLD _IOWR('U', 2, struct 
 uvc_xu_control_mapping_old)
 +#define __UVCIOC_CTRL_MAP   _IOWR('U', 2, struct uvc_xu_control_mapping)
 +#define __UVCIOC_CTRL_GET   _IOWR('U', 3, struct uvc_xu_control)
 +#define __UVCIOC_CTRL_SET   _IOW('U', 4, struct uvc_xu_control)
 +#endif
 
 For compatibility with existing applications. Applications should now include 
 linux/uvcvideo.h instead of drivers/media/video/uvc/uvcvideo.h, but existing 
 applications include the later. I want to make sure they will still compile. 
 A 
 warning will be printed, and this will be removed in 2.6.42.
 You shouldn't need to do that. In fact, the better would be to have two
 separate headers: one with just the public API under include/linux, and
 another with the extra uvc-internal bits, as we did in the past with
 videobuf2.h.
 
 That's how linux/uvcvideo.h and drivers/media/video/uvc/uvcvideo.h are 
 partitioned by this patch set, except that the private header still contains 
 userspace API to avoid breaking applications during the transition period.

Ok, so I'm understanding that, on 2.6.42, you'll be removing the checks for
__KERNEL__ from uvcvideo.h, right?


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

Re: [PATCH v4 3/3] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers

Hi Sylwester,

On Thursday 05 May 2011 11:33:27 Sylwester Nawrocki wrote:
 On 05/04/2011 02:00 PM, Laurent Pinchart wrote:
  On Tuesday 03 May 2011 20:07:43 Sylwester Nawrocki wrote:
  On 05/03/2011 11:16 AM, Laurent Pinchart wrote:
  On Thursday 21 April 2011 17:21:04 Sylwester Nawrocki wrote:
  [snip]
  
  +struct media_pad pads[CSIS_PADS_NUM];
  +struct v4l2_subdev sd;
  +struct platform_device *pdev;
  +struct resource *regs_res;
  +void __iomem *regs;
  +struct clk *clock[NUM_CSIS_CLOCKS];
  +int irq;
  +struct regulator *supply;
  +u32 flags;
  +/* Common format for the source and sink pad. */
  +const struct csis_pix_format *csis_fmt;
  +struct v4l2_mbus_framefmt mf[CSIS_NUM_FMTS];
  
  As try formats are stored in the file handle, and as the formats on the
  sink and source pads are identical, a single v4l2_mbus_framefmt will do
  here.
  
  Ok. How about a situation when the caller never provides a file handle?
  Is it not supposed to happen?
  
  Good question :-) The subdev pad-level operations have been designed with
  a userspace interface in mind, so they require a file handle to store
  try the formats (and crop rectangles).
  
  For V4L2_SUBDEV_FORMAT_TRY, should set_fmt just abandon storing the
  format and should get_fmt just return -EINVAL when passed fh == NULL ?
  
  For such a simple subdev, that should work as a workaround, yes. You can
  use it as a temporary solution at least.
  
  Or should the host driver allocate the file handle just for the sake of
  set_fmt/get_fmt calls (assuming that cropping ops are not supported
  by the subdev) ?
  
  That's another solution. We could also pass an internal structure that
  contains formats and crop rectangles to the pad operations handlers,
  instead of passing the whole file handle. Do you think that would be
  better ?
 
 So it would then be an additional argument for the pad-level operations ?

It would replace the file handle argument.

 Perhaps that would make sense when both format and crop information is
 needed at the same time in the subdev driver. However this would only be
 required for TRY formats/crop rectangles which wouldn't be supported anyway
 because of missing file handle.. or I missed something?

The reason why we pass the file handle to the pad operations is to let drivers 
access formats/crop try settings that are stored in the file handle. If we 
moved those settings to a separate structure, and embedded that structure into 
the file handle structure, we could pass fh-settings instead of fh to the 
pad operations. Drivers that want to call pad operations would then need to 
allocate a settings structure, instead of a complete fake fh.

 Furthermore I assume more complex pipelines will be handled in user space

The pad-level API has been designed to get/set formats/crop settings directly 
from userspace, not from inside the kernel, so that would certainly work.

 and the host drivers could store format and crop information locally
 directly from v4l2_subdev_format and v4l2_subdev_crop data structures.

I'm not sure to understand what you mean there.

  Quoting one of your comments below,
  
  x--- FIMC_0 (/dev/video1)
   
   SENSOR - MIPI_CSIS  --|
   
  x--- FIMC_1 (/dev/video3)
  
  How do you expect to configure the MIPI_CSIS block from the FIMC_0 and
  FIMC_1 blocks, without any help from userspace ? Conflicts will need to
  be handled, and the best way to handle them is to have userspace
  configuring the MIPI_CSIS explicitly.
 
 My priority is to make work the configurations without device nodes at
 sensor and MIPI CSIS subdevs.
 
 I agree it would be best to leave the negotiation logic to user space,
 however I need to assure the regular V4L2 application also can use the
 driver.
 
 My idea was to only try format at CSI slave and sensor subdevs when S_FMT
 is called on a video node. So the sensor and CSIS constraints are taken
 into account.

 Then from VIDIOC_STREAMON, formats at pipeline elements would be set on
 subdevs without device node or validated on subdevs providing a device
 node.

For subdevs without device nodes, why don't you set the active format directly 
when S_FMT is called, instead of postponing the operation until 
VIDIOC_STREAMON time ? You wouldn't need to use TRY formats then.

 Another issue is v4l2 controls. The subdevs are now in my case registered
 to a v4l2_device instance embedded in the media device driver. The video
 node drivers (FIMC0...FIMC3) have their own v4l2_device instances. So the
 control inheritance between video node and a subdevs is gone :/, i.e. I
 couldn't find a standard way to remove back from a parent control handler
 the controls which have been added to it with v4l2_ctrl_handler_add().

I think you should expose sensor controls through subdev devices nodes, not 
through the V4L2 device node.
 
 I've had similar issue

Re: [GIT PATCHES FOR 2.6.40] Make the UVC API public (and minor enhancements)

Hi Mauro,

On Thursday 05 May 2011 14:17:39 Mauro Carvalho Chehab wrote:
 Em 05-05-2011 08:40, Laurent Pinchart escreveu:
  On Thursday 05 May 2011 13:33:20 Mauro Carvalho Chehab wrote:
  Em 27-04-2011 07:38, Laurent Pinchart escreveu:
  These patches move the uvcvideo.h header file from
  drivers/media/video/uvc to include/linux, making the UVC API public.
  Support for the old API is kept and will be removed in 2.6.42.
  
  The following changes since commit
  
  a4761a092fd3b6bf8b5f9cfe361670c86cdcc8ca:
[media] tm6000: fix vbuf may be used uninitialized (2011-04-19
21:13:59 -0300)
  
  are available in the git repository at:
git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next
  
  Laurent Pinchart (5):
uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*
uvcvideo: Make the API public
  
  Why are you declaring this twice:
  
  Index: patchwork/drivers/media/video/uvc/uvcvideo.h
  
  ...
  
  +#ifndef __KERNEL__
  #define UVCIOC_CTRL_ADD _IOW('U', 1, struct uvc_xu_control_info)
  #define UVCIOC_CTRL_MAP_OLD _IOWR('U', 2, struct
  uvc_xu_control_mapping_old) #define UVCIOC_CTRL_MAP _IOWR('U', 2,
  struct uvc_xu_control_mapping) #define UVCIOC_CTRL_GET _IOWR('U',
  3, struct uvc_xu_control) #define UVCIOC_CTRL_SET _IOW('U', 4,
  struct uvc_xu_control) -#define UVCIOC_CTRL_QUERY   _IOWR('U', 5,
  struct uvc_xu_control_query) +#else
  +#define __UVCIOC_CTRL_ADD   _IOW('U', 1, struct uvc_xu_control_info)
  +#define __UVCIOC_CTRL_MAP_OLD _IOWR('U', 2, struct
  
  uvc_xu_control_mapping_old)
  
  +#define __UVCIOC_CTRL_MAP   _IOWR('U', 2, struct
  uvc_xu_control_mapping) +#define __UVCIOC_CTRL_GET   _IOWR('U', 3,
  struct uvc_xu_control) +#define __UVCIOC_CTRL_SET   _IOW('U', 4, struct
  uvc_xu_control) +#endif
  
  For compatibility with existing applications. Applications should now
  include linux/uvcvideo.h instead of drivers/media/video/uvc/uvcvideo.h,
  but existing applications include the later. I want to make sure they
  will still compile. A warning will be printed, and this will be removed
  in 2.6.42.
  
  You shouldn't need to do that. In fact, the better would be to have two
  separate headers: one with just the public API under include/linux, and
  another with the extra uvc-internal bits, as we did in the past with
  videobuf2.h.
  
  That's how linux/uvcvideo.h and drivers/media/video/uvc/uvcvideo.h are
  partitioned by this patch set, except that the private header still
  contains userspace API to avoid breaking applications during the
  transition period.
 
 Ok, so I'm understanding that, on 2.6.42, you'll be removing the checks for
 __KERNEL__ from uvcvideo.h, right?

Yes, and I will remove all ioctl definitions from the private header.

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

CX24116 i2c patch

2011-05-05 Thread Steven Toth

Mauro,

 Subject: [media] cx24116: add config option to split firmware download
 Author:  Antti Palosaari cr...@iki.fi
 Date:    Wed Apr 27 21:03:07 2011 -0300

 It is very rare I2C adapter hardware which can provide 32kB I2C write
 as one write. Add .i2c_wr_max option to set desired max packet size.
 Split transaction to smaller pieces according to that option.

This is none-sense. I'm naking this patch, please unqueue, regress or whatever.

The entire point of the i2c message send is that the i2c drivers know
nothing about the host i2c implementation, and they should not need
to. I2C SEND and RECEIVE are abstract and require no knowledge of the
hardware. This is dangerous and generates non-atomic register writes.
You cannot guarantee that another thread isn't reading/writing to
other registers in the part - breaking the driver.

Please fix the host controller to split the i2c messages accordingly
(and thus keeping the entire transaction atomic).

This is the second time I've seen the 'fix' to a problem by patching
the i2c driver. Fix the i2c bridge else we'll see this behavior
spreading to multiple i2c driver. It's just wrong.

Best,

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

[PATCH] cx18: Fix warnings introduced during cleanup

2011-05-05 Thread Simon Farnsworth

I misused the ktime API, and failed to remove some traces of the
in-kernel format conversion. Fix these, so the the driver builds
without warnings.

Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
Mauro,

You may want to squash this in with the cleanup patch itself - it's
plain and simple oversight on my part (I should have seen the compiler
warnings), and I should not have sent the cleanup patch to you without
fixing these errors.

Sorry,

Simon

drivers/media/video/cx18/cx18-mailbox.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/cx18/cx18-mailbox.c 
b/drivers/media/video/cx18/cx18-mailbox.c
index 5ecae93..c07191e 100644
--- a/drivers/media/video/cx18/cx18-mailbox.c
+++ b/drivers/media/video/cx18/cx18-mailbox.c
@@ -164,10 +164,9 @@ static void cx18_mdl_send_to_videobuf(struct cx18_stream 
*s,
 {
struct cx18_videobuf_buffer *vb_buf;
struct cx18_buffer *buf;
-   u8 *p, u;
+   u8 *p;
u32 offset = 0;
int dispatch = 0;
-   int i;
 
if (mdl-bytesused == 0)
return;
@@ -203,7 +202,7 @@ static void cx18_mdl_send_to_videobuf(struct cx18_stream *s,
}
 
if (dispatch) {
-   ktime_get_ts(vb_buf-vb.ts);
+   vb_buf-vb.ts = ktime_to_timeval(ktime_get());
list_del(vb_buf-vb.queue);
vb_buf-vb.state = VIDEOBUF_DONE;
wake_up(vb_buf-vb.done);
-- 
1.7.4

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

Re: [PATCH] cx18: Clean up mmap() support for raw YUV

2011-05-05 Thread Simon Farnsworth

On Thursday 5 May 2011, Mauro Carvalho Chehab mche...@redhat.com wrote:
 There are a few new warnings with your code:
 
 drivers/media/video/cx18/cx18-mailbox.c: In function
 ‘cx18_mdl_send_to_videobuf’: drivers/media/video/cx18/cx18-mailbox.c:206:
 warning: passing argument 1 of ‘ktime_get_ts’ from incompatible pointer
 type include/linux/ktime.h:331: note: expected ‘struct timespec *’ but
 argument is of type ‘struct timeval *’
 drivers/media/video/cx18/cx18-mailbox.c:170: warning: unused variable ‘i’
 drivers/media/video/cx18/cx18-mailbox.c:167: warning: unused variable ‘u’
 
 Could you please fix them?
 
I'm not doing well on the driving git front today, and I've managed to send 
the fix patch with a wrong In-reply-to; it's message ID is 
1304599356-21951-1-git-send-email-simon.farnswo...@onelan.co.uk, and it's 
elsewhere in this thread (in reply to 4dc138f7.5050...@infradead.org)
-- 
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.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: CX24116 i2c patch

Hi Steven,

Em 05-05-2011 09:28, Steven Toth escreveu:
 Mauro,

 Subject: [media] cx24116: add config option to split firmware download
 Author:  Antti Palosaari cr...@iki.fi
 Date:Wed Apr 27 21:03:07 2011 -0300

 It is very rare I2C adapter hardware which can provide 32kB I2C write
 as one write. Add .i2c_wr_max option to set desired max packet size.
 Split transaction to smaller pieces according to that option.

 This is none-sense. I'm naking this patch, please unqueue, regress or 
 whatever.

 The entire point of the i2c message send is that the i2c drivers know
 nothing about the host i2c implementation, and they should not need
 to. I2C SEND and RECEIVE are abstract and require no knowledge of the
 hardware. This is dangerous and generates non-atomic register writes.
 You cannot guarantee that another thread isn't reading/writing to
 other registers in the part - breaking the driver.

 Please fix the host controller to split the i2c messages accordingly
 (and thus keeping the entire transaction atomic).

 This is the second time I've seen the 'fix' to a problem by patching
 the i2c driver. Fix the i2c bridge else we'll see this behavior
 spreading to multiple i2c driver. It's just wrong.

As you pointed, there are two ways of solving this issue: at the I2C device
side, and at the I2C adapter side. By looking on the existing code, you'll
see that some drivers solve this issue at one side, others solve on the other
side, and there are even some cases where both sides implement I2C splits.
On very few places, this is implemented well.

As you pointed, if the I2C split is implemented inside the I2C driver, extra
care is needed to avoid having an I2C transaction from another device in the
middle of an I2C transaction. With the current API, this generally means that
the I2C driver will need to use i2c_transfer() with a large block of 
transactions.

Also, in general, we don't want to use a full I2C transaction with stop and 
start
bits, so an extra flag is generally needed to indicate that should that we're 
using
a fast i2c transaction (I2C_M_NOSTART) - more about this subject bellow.

On the other hand, if the split is done at the I2C adapter, this means that the
adapter code can't be generic anymore, as the way I2C transactions are broken
depend on how the I2C device works. For example, on xc2028/3028, when a 
transaction
is broken, the next transaction needs an I2C header with the register bank
that are being updated. Other devices don't need that. Also, as not all I2C
devices accept to work with I2C_M_NOSTART, the logic is more complicated.

So, the I2C adapter xfer code will end by being something like:

switch(i2c_device) {
case FOO:
use_split_code_foo();
break;
case BAR:
use_splic_code_bar();
break;
...
}

(if you want to see one example of the above, take a look at 
drivers/media/video/cx231xx/cx231xx-i2c.c).

The end result is very bad, due to:

1) this requires a high couple between the I2C subdriver. If the subdriver code 
changes,
   all I2C adapters that use that driver also need changes;
2) the same logic should be replicated for all devices that use an specific I2C 
subdriver;
3) analyzing the code and tracking for troubles is more complex, as the code is 
splitted on
   two parts;
4) the i2c xfer callback become big, confusing and hard to understand.

On the other hand, in order to warrant atomic operations at the I2C driver, we 
would need to do
something like:

struct i2c_msg msg[5] = {
.addr = props-addr, .flags = 0, .buf = buf[0], .len = len[0] },
.addr = props-addr, .flags = I2C_M_NOSTART, .buf = buf[1], .len = 
len[1] },
.addr = props-addr, .flags = I2C_M_NOSTART, .buf = buf[2], .len = 
len[2] },
.addr = props-addr, .flags = I2C_M_NOSTART, .buf = buf[3], .len = 
len[3] },
}
ret = i2c_transfer(props-adap, msg, 5);

While this warrants that the I2C adapter won't have any transaction from the 
other devices, in the
cases like firmware transfers, the above API is not optimal.

For example, assuming a 32768 firmware, on an I2C adapter capable of sending up 
to 16 bytes by each
transaction[1], and on a device that doesn't need to add an I2C header when a 
transaction is broken,
we would need to do something like:

struct i2c_msg *msg = kzalloc(sizeof(struct i2c_msg) * 2048, 
GFP_KERNEL);
for (i = 0; i  2048; i++) {
msg[i].addr = i2c_addr;
msg[i].buf = fw_buf[i * 16];
msg[i].len = 16;
if (i)
msg[i].flags = I2C_M_NOSTART;
}
ret = i2c_transfer(props-adap, msg, 2048);
kfree(msg);

[1] I used fixed values here just to simplify the code. On a real case, the 
static constants should
be calculated by the send function.

So, it should allocating a very big buffer just to comply with the current I2C 
API.

IMHO, the better would be if the I2C

Re: [PATCH] cx18: Clean up mmap() support for raw YUV

Em 05-05-2011 09:44, Simon Farnsworth escreveu:
 On Thursday 5 May 2011, Mauro Carvalho Chehab mche...@redhat.com wrote:
 There are a few new warnings with your code:

 drivers/media/video/cx18/cx18-mailbox.c: In function
 ‘cx18_mdl_send_to_videobuf’: drivers/media/video/cx18/cx18-mailbox.c:206:
 warning: passing argument 1 of ‘ktime_get_ts’ from incompatible pointer
 type include/linux/ktime.h:331: note: expected ‘struct timespec *’ but
 argument is of type ‘struct timeval *’
 drivers/media/video/cx18/cx18-mailbox.c:170: warning: unused variable ‘i’
 drivers/media/video/cx18/cx18-mailbox.c:167: warning: unused variable ‘u’

 Could you please fix them?

 I'm not doing well on the driving git front today, and I've managed to send 
 the fix patch with a wrong In-reply-to; it's message ID is 
 1304599356-21951-1-git-send-email-simon.farnswo...@onelan.co.uk, and it's 
 elsewhere in this thread (in reply to 4dc138f7.5050...@infradead.org)

No problem. I don't rely very much on in-reply-to, as patchwork doesn't care
about it (unfortunately, as it would help to detect patches superseded/grouped).

Mauro.



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

Re: [PATCH] cx18: Fix warnings introduced during cleanup

Em 05-05-2011 09:42, Simon Farnsworth escreveu:
 I misused the ktime API, and failed to remove some traces of the
 in-kernel format conversion. Fix these, so the the driver builds
 without warnings.
 
 Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
 ---
 Mauro,
 
 You may want to squash this in with the cleanup patch itself - it's
 plain and simple oversight on my part (I should have seen the compiler
 warnings), and I should not have sent the cleanup patch to you without
 fixing these errors.
 
It will all depend on how much time I'll have during the next merge window.
I can't do it at the already-applied patches, as other people use it as basis,
and a rebase there would break its clones.

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

Re: [PATCH] cx18: Fix warnings introduced during cleanup

2011-05-05 Thread Simon Farnsworth

On Thursday 5 May 2011, Mauro Carvalho Chehab mche...@infradead.org wrote:
 Em 05-05-2011 09:42, Simon Farnsworth escreveu:
  I misused the ktime API, and failed to remove some traces of the
  in-kernel format conversion. Fix these, so the the driver builds
  without warnings.
  
  Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
  ---
  Mauro,
  
  You may want to squash this in with the cleanup patch itself - it's
  plain and simple oversight on my part (I should have seen the compiler
  warnings), and I should not have sent the cleanup patch to you without
  fixing these errors.
 
 It will all depend on how much time I'll have during the next merge window.
 I can't do it at the already-applied patches, as other people use it as
 basis, and a rebase there would break its clones.
 
 Mauro.

No problem; if it ends up as a separate patch in the tree, it's not going to 
hurt, as the version with warnings functions adequately enough to not break 
bisection.
-- 
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.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] OMAP3: ISP: Fix unbalanced use of omap3isp_get().

Hi Javier,

On Thursday 05 May 2011 15:53:08 Javier Martin wrote:
 Do not use omap3isp_get() when what we really want to do is just
 enable clocks, since omap3isp_get() has additional, unwanted, side
 effects as an increase of the counter.
 
 This prevented omap3isp of working with Beagleboard xM and it has
 been tested only with that platform + mt9p031 sensor.
 
 Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
 ---
  drivers/media/video/omap3isp/isp.c |8 +---
  1 files changed, 5 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/media/video/omap3isp/isp.c
 b/drivers/media/video/omap3isp/isp.c index 472a693..ca0831f 100644
 --- a/drivers/media/video/omap3isp/isp.c
 +++ b/drivers/media/video/omap3isp/isp.c
 @@ -85,9 +85,11 @@ module_param(autoidle, int, 0444);
  MODULE_PARM_DESC(autoidle, Enable OMAP3ISP AUTOIDLE support);
 
  static void isp_save_ctx(struct isp_device *isp);
 -
  static void isp_restore_ctx(struct isp_device *isp);
 
 +static int isp_enable_clocks(struct isp_device *isp);
 +static void isp_disable_clocks(struct isp_device *isp);
 +
  static const struct isp_res_mapping isp_res_maps[] = {
   {
   .isp_rev = ISP_REVISION_2_0,
 @@ -239,10 +241,10 @@ static u32 isp_set_xclk(struct isp_device *isp, u32
 xclk, u8 xclksel)
 
   /* Do we go from stable whatever to clock? */
   if (divisor = 2  isp-xclk_divisor[xclksel - 1]  2)
 - omap3isp_get(isp);
 + isp_enable_clocks(isp);

This won't work. Let's assume the following sequence of events:

- Userspace opens the sensor subdev device node
- The sensor driver calls to board code to turn the sensor clock on
- Board code calls to the ISP driver to turn XCLK on
- The ISP driver calls isp_enable_clocks()
...
- Userspace opens an ISP video device node
- The ISP driver calls isp_get(), incrementing the reference count
- Userspace closes the ISP video device node
- The ISP driver calls isp_put(), decrementing the reference count
- The reference count reaches 0, the ISP driver calls isp_disable_clocks()

The sensor will then loose its clock, even though the sensor subdev device 
node is still opened.

Could you please explain why the existing code doesn't work on your hardware ?

   /* Stopping the clock. */
   else if (divisor  2  isp-xclk_divisor[xclksel - 1] = 2)
 - omap3isp_put(isp);
 + isp_disable_clocks(isp);
 
   isp-xclk_divisor[xclksel - 1] = divisor;

-- 
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 v4 1/1] libv4l: Add plugin support to libv4l

2011-05-05 Thread Hans de Goede


Hi,

Thanks, looks good now!

I'm going to keep this in my inbox before applying for a while though,
as this involves an abi change (of libv4lconvert, which is almost not
used directly but still).

I've a number of important fixes / changes planned which I hope to
be able to do soon, and then I want to do another 0.8.x release, once
that is out the door I'll merge this, and then do a 0.9.x release
pretty soon after that.

Regards,

Hans


On 05/03/2011 05:26 PM, Yordan Kamenov wrote:

A libv4l2 plugin will sit in between libv4l2 itself and the actual
/dev/video device node a fd refers to. It will be called each time
libv4l2 wants to do an operation (read/write/ioctl) on the actual
/dev/video node in question.

Signed-off-by: Yordan Kamenovykame...@mm-sol.com
---
  lib/include/libv4l2-plugin.h   |   36 ++
  lib/include/libv4lconvert.h|5 +-
  lib/libv4l2/Makefile   |6 +-
  lib/libv4l2/libv4l2-priv.h |   10 ++
  lib/libv4l2/libv4l2.c  |   88 ++
  lib/libv4l2/v4l2-plugin.c  |  158 
  lib/libv4l2/v4l2convert.c  |9 --
  lib/libv4lconvert/control/libv4lcontrol-priv.h |4 +
  lib/libv4lconvert/control/libv4lcontrol.c  |   35 --
  lib/libv4lconvert/control/libv4lcontrol.h  |5 +-
  lib/libv4lconvert/libv4lconvert-priv.h |2 +
  lib/libv4lconvert/libv4lconvert.c  |   34 --
  utils/qv4l2/qv4l2.cpp  |   17 +++-
  utils/qv4l2/qv4l2.h|1 +
  14 files changed, 347 insertions(+), 63 deletions(-)
  create mode 100644 lib/include/libv4l2-plugin.h
  create mode 100644 lib/libv4l2/v4l2-plugin.c

diff --git a/lib/include/libv4l2-plugin.h b/lib/include/libv4l2-plugin.h
new file mode 100644
index 000..158c0c2
--- /dev/null
+++ b/lib/include/libv4l2-plugin.h
@@ -0,0 +1,36 @@
+/*
+* Copyright (C) 2010 Nokia Corporationmultime...@maemo.org
+
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU Lesser General Public License as published by
+* the Free Software Foundation; either version 2.1 of the License, or
+* (at your option) any later version.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+*/
+
+#ifndef __LIBV4L2_PLUGIN_H
+#define __LIBV4L2_PLUGIN_H
+
+#includesys/types.h
+
+/* Structure libv4l2_dev_ops holds the calls from libv4ls to video nodes.
+   They can be normal open/close/ioctl etc. or any of them may be replaced
+   with a callback by a loaded plugin.
+*/
+
+struct libv4l2_dev_ops {
+void * (*init)(int fd);
+void (*close)(void *dev_ops_priv);
+int (*ioctl)(void *dev_ops_priv, int fd, unsigned long int request, void 
*arg);
+ssize_t (*read)(void *dev_ops_priv, int fd, void *buffer, size_t n);
+};
+
+#endif
diff --git a/lib/include/libv4lconvert.h b/lib/include/libv4lconvert.h
index 0264290..351142e 100644
--- a/lib/include/libv4lconvert.h
+++ b/lib/include/libv4lconvert.h
@@ -38,6 +38,8 @@

  #includelinux/videodev2.h

+#include libv4l2-plugin.h
+
  #ifdef __cplusplus
  extern C {
  #endif /* __cplusplus */
@@ -50,7 +52,8 @@ extern C {

  struct v4lconvert_data;

-LIBV4L_PUBLIC struct v4lconvert_data *v4lconvert_create(int fd);
+LIBV4L_PUBLIC struct v4lconvert_data *v4lconvert_create(int fd,
+   void *dev_ops_priv, struct libv4l2_dev_ops *dev_ops);
  LIBV4L_PUBLIC void v4lconvert_destroy(struct v4lconvert_data *data);

  /* When doing flipping / rotating / video-processing, only supported
diff --git a/lib/libv4l2/Makefile b/lib/libv4l2/Makefile
index d78632f..f8b3714 100644
--- a/lib/libv4l2/Makefile
+++ b/lib/libv4l2/Makefile
@@ -1,12 +1,12 @@
  override CPPFLAGS += -I../include -fvisibility=hidden

-LIBS_libv4l2  = -lpthread
+LIBS_libv4l2  = -lpthread -ldl

-V4L2_OBJS = libv4l2.o log.o
+V4L2_OBJS = libv4l2.o v4l2-plugin.o log.o
  V4L2CONVERT   = v4l2convert.so
  V4L2CONVERT_O = v4l2convert.o libv4l2.so
  TARGETS   = $(V4L2_LIB) libv4l2.pc
-INCLUDES  = ../include/libv4l2.h
+INCLUDES  = ../include/libv4l2.h ../include/libv4l2-plugin.h

  ifeq ($(LINKTYPE),static)
  V4L2_LIB  = libv4l2.a
diff --git a/lib/libv4l2/libv4l2-priv.h b/lib/libv4l2/libv4l2-priv.h
index 46d6103..d06a508 100644
--- a/lib/libv4l2/libv4l2-priv.h
+++ b/lib/libv4l2/libv4l2-priv.h
@@ -85,8 +85,18 @@ struct v4l2_dev_info {
/* buffer when doing conversion and using read() for read() */
int readbuf_size;
unsigned

Re: [PATCH] Ngene cam device name

2011-05-05 Thread Martin Vidovic


Hi,

Broadly speaking, I could put issues discussed in this thread into 
following categories:


- How devices are named;
- How devices are used;
- How devices relate to one another;
- How devices are enumerated;
- How devices are described;

Mostly we discuss category 1 and 2 with relation to nGENE CI, but 
sometimes we leap to other categories as well.


Andreas Oberritter wrote:

On 05/04/2011 03:35 PM, Martin Vidovic wrote:



I think there is currently no useful API to connect devices. Every few
months there comes a new device which deprecates how I enumerate devices
and determine types of FE's.


Can you describe the most common problems? What do you mean by connecting?


What I mean by connecting devices falls into last 3 categories (above). 
I brought this up because I don't believe this is the actual problem we 
need to solve here since it's not nGENE specific.


Some examples of problems in categories 3-5:

a) Plug two TerraTec Cinergy T RC MKII and try to distinguish between them.

b) Take a Hybrid terrestrial TV tuner. V4L and DVB APIs (may) use shared 
resources, how does one find this out?


c.1) How does one know which frontend device can be used with which 
demux device?


c.2) Which CA device can be used with which frontend device?

d) How does one list all supported delivery systems for a device 
(FE_GET_INFO is not general, and DTV_DELIVERY_SYSTEM can't be used to 
query available delivery systems).


e) the list could be extended...

These problems are mostly not fatal, they have workarounds. Some of them 
require device/driver specific knowledge.



The most useful way to query devices seems to be using HAL, and I think
this is the correct way in Linux, but DVB-API may be lacking with
providing the necessary information. Maybe this is the direction we
should consider? Device names under /dev seem to be irrelevant nowadays.


I think in the long run we should look closely at how V4L2 is solving
similar problems.


The best would be to create independent adapters for each independent CA 
device (ca0/caio0 pair) - they are independent after all (physically and 
in the way they're used).


What I understand you would like to see, is the ability to do direct 
transfers between independent devices or parts of devices. Is this correct?


Best regards,
Martin Vidovic
--
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: Current status report of mt9p031.

Hi Javier,

On Wednesday 04 May 2011 09:33:49 javier Martin wrote:
 Hi,
 for those interested on mt9p031 working on the Beagleboard xM. I
 attach 2 patches here that must be applied to kernel-2.6.39-rc commit
 e8dad69408a9812d6bb42d03e74d2c314534a4fa
 These patches include a fix for the USB ethernet.
 
 What currently works:
 - Test suggested by Guennadi
 (http://download.open-technology.de/BeagleBoard_xM-MT9P031/).
 
 Known problems:
 1. You might be required to create device node for the sensor manually:
 
 mknod /dev/v4l-subdev8 c 81 15
 chown root:video /dev/v4l-subdev8
 
 2. Images captured seem to be too dull and dark. Values of pixels seem
 always to low, it seems to me like MSB of each pixel were stuck at 0.
 I hope someone can help here.

I've inline the patches for easier review, please send the inline next time.


First 0001-mt9p031.patch. As a general rule, please try to split your patches 
properly. This one contains several unrelated changes. For instance the 
drivers/media/video/Makefile modification should go in the patch that adds the 
mt9p031 driver code.

 diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-
omap2/board-omap3beagle.c
 index 33007fd..eba2235 100644
 --- a/arch/arm/mach-omap2/board-omap3beagle.c
 +++ b/arch/arm/mach-omap2/board-omap3beagle.c

[snip]

 @@ -273,6 +274,44 @@ static struct regulator_consumer_supply
 beagle_vsim_supply = {
  
  static struct gpio_led gpio_leds[];
  
 +static struct regulator_consumer_supply beagle_vaux3_supply = {
 + .supply = cam_1v8,
 +};
 +
 +static struct regulator_consumer_supply beagle_vaux4_supply = {
 + .supply = cam_2v8,

That's a weird name for a supply that is connected to a 1.8V regulator output. 
What about renaming the supplies cam_dig and cam_io ?

 +};

[snip]

 @@ -309,6 +348,15 @@ static int beagle_twl_gpio_setup(struct device *dev,
   pr_err(%s: unable to configure EHCI_nOC\n, __func__);
   }
  
 + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
 + /*
 +  * Power on camera interface - only on pre-production, not
 +  * needed on production boards
 +  */
 + gpio_request(gpio + 2, CAM_EN);
 + gpio_direction_output(gpio + 2, 1);

There's already similar code in 2.6.39-rc6 (but the GPIO is called 
DVI_LDO_EN).

 + }
 +
   /*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)

[snip]

 @@ -472,6 +522,7 @@ static int __init omap3_beagle_i2c_init(void)
  {
   omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
   ARRAY_SIZE(beagle_i2c_boardinfo));
 +//   omap_register_i2c_bus(2, 100, NULL, 0);

Please don't add commented out code.

   /* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
   omap_register_i2c_bus(3, 100, beagle_i2c_eeprom,
   ARRAY_SIZE(beagle_i2c_eeprom));
 @@ -598,6 +649,34 @@ static const struct usbhs_omap_board_data usbhs_bdata 
__initconst = {
  
  #ifdef CONFIG_OMAP_MUX
  static struct omap_board_mux board_mux[] __initdata = {
 +// #if 0

Same here.

Does the boot loader leave the camera interface unconfigured ?

 + /* Camera - Parallel Data */
 + OMAP3_MUX(CAM_D0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_D1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_D2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_D3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_D4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_D5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_D6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_D7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_D8, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_D9, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_D10, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_D11, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 +
 + /* Camera - HS/VS signals */
 + OMAP3_MUX(CAM_HS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 + OMAP3_MUX(CAM_VS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),

What about pull-ups ont the HS/VS and PCLK signals ?

 +
 + /* Camera - Reset GPIO 98 */
 + OMAP3_MUX(CAM_FLD, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
 +
 + /* Camera - XCLK */
 + OMAP3_MUX(CAM_XCLKA, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
 +// #endif
 +//   OMAP3_MUX(I2C2_SCL, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
 +//   OMAP3_MUX(I2C2_SDA, OMAP_MUX_MODE0 | OMAP_PIN_OFF_INPUT_PULLUP |
 OMAP_PIN_INPUT_PULLUP),
   { .reg_offset = OMAP_MUX_TERMINATOR },
  };
  #endif
 @@ -656,6 +735,8 @@ static void __init beagle_opp_init(void)
  
  static void __init omap3_beagle_init(void)
  {
 +//   u32 ctrl;
 +

No commented code.

   omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
   omap3_beagle_init_rev();
   omap3_beagle_i2c_init();
 @@

Re: CX24116 i2c patch

2011-05-05 Thread Jean Delvare

Hi Mauro, Steven,

On Thu, 05 May 2011 10:15:04 -0300, Mauro Carvalho Chehab wrote:
 Hi Steven,
 
 Em 05-05-2011 09:28, Steven Toth escreveu:
  Mauro,
  
  Subject: [media] cx24116: add config option to split firmware download
  Author:  Antti Palosaari cr...@iki.fi
  Date:Wed Apr 27 21:03:07 2011 -0300
 
  It is very rare I2C adapter hardware which can provide 32kB I2C write
  as one write. Add .i2c_wr_max option to set desired max packet size.
  Split transaction to smaller pieces according to that option.
  
  This is none-sense. I'm naking this patch, please unqueue, regress or 
  whatever.
  
  The entire point of the i2c message send is that the i2c drivers know
  nothing about the host i2c implementation, and they should not need
  to. I2C SEND and RECEIVE are abstract and require no knowledge of the
  hardware. This is dangerous and generates non-atomic register writes.
  You cannot guarantee that another thread isn't reading/writing to
  other registers in the part - breaking the driver.
  
  Please fix the host controller to split the i2c messages accordingly
  (and thus keeping the entire transaction atomic).
  
  This is the second time I've seen the 'fix' to a problem by patching
  the i2c driver. Fix the i2c bridge else we'll see this behavior
  spreading to multiple i2c driver. It's just wrong.
 
 As you pointed, there are two ways of solving this issue: at the I2C device
 side, and at the I2C adapter side. By looking on the existing code, you'll
 see that some drivers solve this issue at one side, others solve on the other
 side, and there are even some cases where both sides implement I2C splits.
 On very few places, this is implemented well.
 
 As you pointed, if the I2C split is implemented inside the I2C driver, extra
 care is needed to avoid having an I2C transaction from another device in the
 middle of an I2C transaction.

Really? At least for common EEPROM chips, they keep an internal pointer
up-to-date, and direct access will always restart from where the
previous transaction stopped. It really doesn't matter if another
messages flies on the I2C bus meanwhile, as long as said message is
targeted at another chip. Serializing access to the chip can be
implemented easily in the I2C device driver itself, and this should be
sufficient on single-master topologies if all drivers properly request
each I2C address they talk to (by instantiating real or dummy i2c
clients for them.) An example of this is in drivers/misc/eeprom/at24.c.

I'd expect other I2C devices to behave in a similar way. But I can
imagine that some chips are brain-dead enough to actually be distracted
by traffic not aimed at them :(

 With the current API, this generally means that
 the I2C driver will need to use i2c_transfer() with a large block of 
 transactions.

 Also, in general, we don't want to use a full I2C transaction with stop and 
 start
 bits, so an extra flag is generally needed to indicate that should that we're 
 using
 a fast i2c transaction (I2C_M_NOSTART) - more about this subject bellow.

You lost me here. I2C_M_NOSTART should only be needed to deal with I2C
chips which do not actually comply with the I2C standard and do
arbitrary direction changes (while the I2C standard doesn't allow this
without a repeated start condition.) This is a very rare case, thankfully.

A second use case which is tolerated is when your message is initially
split in multiple buffers and you don't want to waste time merging them
into a single buffer to pass it to i2c_transfer. This is merely a
performance optimization and the same could be achieved without using
I2C_M_NOSTART.

Do you really have a 3rd use case for I2C_M_NOSTART, which I didn't
know about?

 On the other hand, if the split is done at the I2C adapter, this means that 
 the
 adapter code can't be generic anymore, as the way I2C transactions are broken
 depend on how the I2C device works. For example, on xc2028/3028, when a 
 transaction
 is broken, the next transaction needs an I2C header with the register bank
 that are being updated. Other devices don't need that. Also, as not all I2C
 devices accept to work with I2C_M_NOSTART, the logic is more complicated.
 
 
 So, the I2C adapter xfer code will end by being something like:
 
 switch(i2c_device) {
   case FOO:
   use_split_code_foo();
   break;
   case BAR:
   use_splic_code_bar();
   break;
   ...
 }
 
 
 (if you want to see one example of the above, take a look at 
 drivers/media/video/cx231xx/cx231xx-i2c.c).

This is horrible, things should never be implemented that way. I2C
adapter drivers should NEVER replace the transaction they were asked
for by another one. If an I2C adapter driver cannot achieve what an I2C
device driver asked for, it should simply return an error code
(-EOPNOTSUPP according to Documentation/i2c/fault-codes). As Mauro just
explained, there is no single way to rephrase an I2C transaction. It
all depends on the I2C

Re: CX24116 i2c patch

2011-05-05 Thread Devin Heitmueller

On Thu, May 5, 2011 at 8:28 AM, Steven Toth st...@kernellabs.com wrote:
 Mauro,

 Subject: [media] cx24116: add config option to split firmware download
 Author:  Antti Palosaari cr...@iki.fi
 Date:    Wed Apr 27 21:03:07 2011 -0300

 It is very rare I2C adapter hardware which can provide 32kB I2C write
 as one write. Add .i2c_wr_max option to set desired max packet size.
 Split transaction to smaller pieces according to that option.

 This is none-sense. I'm naking this patch, please unqueue, regress or 
 whatever.

 The entire point of the i2c message send is that the i2c drivers know
 nothing about the host i2c implementation, and they should not need
 to. I2C SEND and RECEIVE are abstract and require no knowledge of the
 hardware. This is dangerous and generates non-atomic register writes.
 You cannot guarantee that another thread isn't reading/writing to
 other registers in the part - breaking the driver.

 Please fix the host controller to split the i2c messages accordingly
 (and thus keeping the entire transaction atomic).

 This is the second time I've seen the 'fix' to a problem by patching
 the i2c driver. Fix the i2c bridge else we'll see this behavior
 spreading to multiple i2c driver. It's just wrong.

I tend to agree with Steven on this one.  That said, these sorts of
things usually get introduced in cases where the i2c master is not
well enough understood to know how to split the transactions and still
preserve the repeat start (common with reverse engineered drivers).
It can also occur in cases where there really is a hardware limitation
that prevents the caller from making multiple requests to the chip
while not sending the stop bit (although this is less common).

Do we know this to be the case with the anysee bridge?  Is this a
reverse engineered device?  Is there documentation/datasheets to
reference?

Do we know if this is an issue with the i2c master driver not being
fully baked, or if it's a hardware limitation?

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: CX24116 i2c patch

2011-05-05 Thread Devin Heitmueller

On Thu, May 5, 2011 at 9:15 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 So, the I2C adapter xfer code will end by being something like:

 switch(i2c_device) {
        case FOO:
                use_split_code_foo();
                break;
        case BAR:
                use_splic_code_bar();
                break;
        ...
 }


 (if you want to see one example of the above, take a look at 
 drivers/media/video/cx231xx/cx231xx-i2c.c).

The cx231xx is actually an example of a poor implementation rather
than a deficiency in the chip.  The device does support sending
arbitrarily long sequences, but because of a lack of support for i2c
clock stretching they hacked in their own GPIO based bitbang
implementation which only gets used in certain cases.  If somebody
wanted to clean it up I believe it could be done much more cleanly.
That said, it hasn't happened because the code as-is works and in
reality I don't think there are any shipping products which use
cx231xx and xc5000 (they are all Conexant reference designs).

If somebody really wants to clean this up, they should have a board
profile field which indicates whether to create an i2c adapter which
uses the onboard i2c controller, or alternatively to setup an i2c
adapter which uses the real Linux i2c-bitbang implementation.  That
would make the implementation much easier to understand as well as
eliminating all the crap code which makes decisions based on the
destination i2c address.

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 v4 3/3] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers

2011-05-05 Thread Sylwester Nawrocki

Hi Laurent,

On 05/05/2011 02:25 PM, Laurent Pinchart wrote:
 On Thursday 05 May 2011 11:33:27 Sylwester Nawrocki wrote:
 On 05/04/2011 02:00 PM, Laurent Pinchart wrote:
 On Tuesday 03 May 2011 20:07:43 Sylwester Nawrocki wrote:
 On 05/03/2011 11:16 AM, Laurent Pinchart wrote:
 On Thursday 21 April 2011 17:21:04 Sylwester Nawrocki wrote:
 [snip]

 +struct media_pad pads[CSIS_PADS_NUM];
 +struct v4l2_subdev sd;
 +struct platform_device *pdev;
 +struct resource *regs_res;
 +void __iomem *regs;
 +struct clk *clock[NUM_CSIS_CLOCKS];
 +int irq;
 +struct regulator *supply;
 +u32 flags;
 +/* Common format for the source and sink pad. */
 +const struct csis_pix_format *csis_fmt;
 +struct v4l2_mbus_framefmt mf[CSIS_NUM_FMTS];

 As try formats are stored in the file handle, and as the formats on the
 sink and source pads are identical, a single v4l2_mbus_framefmt will do
 here.

 Ok. How about a situation when the caller never provides a file handle?
 Is it not supposed to happen?

 Good question :-) The subdev pad-level operations have been designed with
 a userspace interface in mind, so they require a file handle to store
 try the formats (and crop rectangles).

 For V4L2_SUBDEV_FORMAT_TRY, should set_fmt just abandon storing the
 format and should get_fmt just return -EINVAL when passed fh == NULL ?

 For such a simple subdev, that should work as a workaround, yes. You can
 use it as a temporary solution at least.

 Or should the host driver allocate the file handle just for the sake of
 set_fmt/get_fmt calls (assuming that cropping ops are not supported
 by the subdev) ?

 That's another solution. We could also pass an internal structure that
 contains formats and crop rectangles to the pad operations handlers,
 instead of passing the whole file handle. Do you think that would be
 better ?

 So it would then be an additional argument for the pad-level operations ?
 
 It would replace the file handle argument.
 
 Perhaps that would make sense when both format and crop information is
 needed at the same time in the subdev driver. However this would only be
 required for TRY formats/crop rectangles which wouldn't be supported anyway
 because of missing file handle.. or I missed something?
 
 The reason why we pass the file handle to the pad operations is to let 
 drivers 
 access formats/crop try settings that are stored in the file handle. If we 
 moved those settings to a separate structure, and embedded that structure 
 into 
 the file handle structure, we could pass fh-settings instead of fh to the 
 pad operations. Drivers that want to call pad operations would then need to 
 allocate a settings structure, instead of a complete fake fh.

I see, that sounds like a cleanest solution of the problem.

 
 Furthermore I assume more complex pipelines will be handled in user space
 
 The pad-level API has been designed to get/set formats/crop settings directly 
 from userspace, not from inside the kernel, so that would certainly work.
 
 and the host drivers could store format and crop information locally
 directly from v4l2_subdev_format and v4l2_subdev_crop data structures.
 
 I'm not sure to understand what you mean there.

I meant that the adjusted format/crop rectangle is still returned in the
pad operations, through the last argument; in struct v4l2_subdev_format::format
or struct v4l2_subdev_crop::rect and these can be queried and interpreted by
a host driver. 
But as you explain purpose of the fh is to aid subdev, not the host drivers.

 
 Quoting one of your comments below,

 x--- FIMC_0 (/dev/video1)
  
  SENSOR - MIPI_CSIS  --|
  
 x--- FIMC_1 (/dev/video3)

 How do you expect to configure the MIPI_CSIS block from the FIMC_0 and
 FIMC_1 blocks, without any help from userspace ? Conflicts will need to
 be handled, and the best way to handle them is to have userspace
 configuring the MIPI_CSIS explicitly.

 My priority is to make work the configurations without device nodes at
 sensor and MIPI CSIS subdevs.

 I agree it would be best to leave the negotiation logic to user space,
 however I need to assure the regular V4L2 application also can use the
 driver.

 My idea was to only try format at CSI slave and sensor subdevs when S_FMT
 is called on a video node. So the sensor and CSIS constraints are taken
 into account.

 Then from VIDIOC_STREAMON, formats at pipeline elements would be set on
 subdevs without device node or validated on subdevs providing a device
 node.
 
 For subdevs without device nodes, why don't you set the active format 
 directly 
 when S_FMT is called, instead of postponing the operation until 
 VIDIOC_STREAMON time ? You wouldn't need to use TRY formats then.

In the configuration with two FIMC devices linked to MIPI CSIS and sensor as 
above,
if one of the FIMC nodes is streaming, in e.g. camera preview mode, it would 
not be
possible to set

Re: CX24116 i2c patch

Em 05-05-2011 12:09, Jean Delvare escreveu:
 Hi Mauro, Steven,
 
 On Thu, 05 May 2011 10:15:04 -0300, Mauro Carvalho Chehab wrote:
 Hi Steven,

 Em 05-05-2011 09:28, Steven Toth escreveu:
 Mauro,

 Subject: [media] cx24116: add config option to split firmware download
 Author:  Antti Palosaari cr...@iki.fi
 Date:Wed Apr 27 21:03:07 2011 -0300

 It is very rare I2C adapter hardware which can provide 32kB I2C write
 as one write. Add .i2c_wr_max option to set desired max packet size.
 Split transaction to smaller pieces according to that option.

 This is none-sense. I'm naking this patch, please unqueue, regress or 
 whatever.

 The entire point of the i2c message send is that the i2c drivers know
 nothing about the host i2c implementation, and they should not need
 to. I2C SEND and RECEIVE are abstract and require no knowledge of the
 hardware. This is dangerous and generates non-atomic register writes.
 You cannot guarantee that another thread isn't reading/writing to
 other registers in the part - breaking the driver.

 Please fix the host controller to split the i2c messages accordingly
 (and thus keeping the entire transaction atomic).

 This is the second time I've seen the 'fix' to a problem by patching
 the i2c driver. Fix the i2c bridge else we'll see this behavior
 spreading to multiple i2c driver. It's just wrong.

 As you pointed, there are two ways of solving this issue: at the I2C device
 side, and at the I2C adapter side. By looking on the existing code, you'll
 see that some drivers solve this issue at one side, others solve on the other
 side, and there are even some cases where both sides implement I2C splits.
 On very few places, this is implemented well.

 As you pointed, if the I2C split is implemented inside the I2C driver, extra
 care is needed to avoid having an I2C transaction from another device in the
 middle of an I2C transaction.
 
 Really? At least for common EEPROM chips, they keep an internal pointer
 up-to-date, and direct access will always restart from where the
 previous transaction stopped. It really doesn't matter if another
 messages flies on the I2C bus meanwhile, as long as said message is
 targeted at another chip. Serializing access to the chip can be
 implemented easily in the I2C device driver itself, and this should be
 sufficient on single-master topologies if all drivers properly request
 each I2C address they talk to (by instantiating real or dummy i2c
 clients for them.) An example of this is in drivers/misc/eeprom/at24.c.
 
 I'd expect other I2C devices to behave in a similar way. But I can
 imagine that some chips are brain-dead enough to actually be distracted
 by traffic not aimed at them :(

Yes, that happens. For example, NXP tda18271 states that certain operations,
like the initialization of a sequence of 16 registers should be done into an
atomic operation, otherwise the net result is not reliable [1].  However, (some 
of) the
I2C bridges found at cx231xx don't support any write with more than 4 data 
bytes of
data. So, the solution is to break it into 4 consecutive I2C packets, properly 
serialized.

The serialization is also needed because of the I2C switches that the device 
may have.

[1] those registers initialize a series of calibration data that, among other 
things,
estimate some parameters based on the current device temperature.

 With the current API, this generally means that
 the I2C driver will need to use i2c_transfer() with a large block of 
 transactions.

 Also, in general, we don't want to use a full I2C transaction with stop and 
 start
 bits, so an extra flag is generally needed to indicate that should that 
 we're using
 a fast i2c transaction (I2C_M_NOSTART) - more about this subject bellow.
 
 You lost me here. I2C_M_NOSTART should only be needed to deal with I2C
 chips which do not actually comply with the I2C standard and do
 arbitrary direction changes (while the I2C standard doesn't allow this
 without a repeated start condition.) This is a very rare case, thankfully.
 
 A second use case which is tolerated is when your message is initially
 split in multiple buffers and you don't want to waste time merging them
 into a single buffer to pass it to i2c_transfer. This is merely a
 performance optimization and the same could be achieved without using
 I2C_M_NOSTART.
 
 Do you really have a 3rd use case for I2C_M_NOSTART, which I didn't
 know about?

Perhaps with a wrong meaning, but some drivers use it to use the repeated-start 
mode.

So, instead of sending:
start + addr + data + stop + start + addr + data + stop
they send:
start + addr + data + stop + data + stop

(see for example saa7134-i2c and dib0700-core).

 On the other hand, if the split is done at the I2C adapter, this means that 
 the
 adapter code can't be generic anymore, as the way I2C transactions are broken
 depend on how the I2C device works. For example, on xc2028/3028, when a 
 transaction
 is broken, the next transaction needs an I2C

Re: CX24116 i2c patch

Em 05-05-2011 12:34, Devin Heitmueller escreveu:
 On Thu, May 5, 2011 at 9:15 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 So, the I2C adapter xfer code will end by being something like:

 switch(i2c_device) {
case FOO:
use_split_code_foo();
break;
case BAR:
use_splic_code_bar();
break;
...
 }


 (if you want to see one example of the above, take a look at 
 drivers/media/video/cx231xx/cx231xx-i2c.c).
 
 The cx231xx is actually an example of a poor implementation

Yes.

 rather
 than a deficiency in the chip.  The device does support sending
 arbitrarily long sequences, but because of a lack of support for i2c
 clock stretching they hacked in their own GPIO based bitbang
 implementation which only gets used in certain cases. 

No. There are two different situations here: they use GPIO bitbang for
one device type, due to clock stretching, but also the hardware doesn't accept
long I2C messages. I've double-checked this with the vendor developers, and
double-checked the sniffed messages from the original driver.

The case I detected troubles were with tda18271 device (that doesn't use
clock stretching), and using the direct hardware support for I2C, at the
I2C bus 2. The Hauppauge devices that you've worked have the tuner connected
to the I2C bus 1. Perhaps bus 2 has a smaller hardware buffer, or perhaps
the chip revision present on the device I tested is more limited.

In any case, every time more than 4 data bytes were sent to tda18271, the
hardware returned an error.

If you take a look at cx231xx-core, you'll see that other types of non-GPIO
messages with more than 4 bytes are broken into smaller messages there.

 If somebody
 wanted to clean it up I believe it could be done much more cleanly.
 That said, it hasn't happened because the code as-is works and in
 reality I don't think there are any shipping products which use
 cx231xx and xc5000 (they are all Conexant reference designs).
 
 If somebody really wants to clean this up, they should have a board
 profile field which indicates whether to create an i2c adapter which
 uses the onboard i2c controller, or alternatively to setup an i2c
 adapter which uses the real Linux i2c-bitbang implementation.  That
 would make the implementation much easier to understand as well as
 eliminating all the crap code which makes decisions based on the
 destination i2c address.

Yes, the code can be cleaned, but this won't solve the issue: messages still
need to be broken to be used by (some) I2C buses on it. 

Also, cx231xx is not an exception: there are very few hardware that would 
accept a 32 KB message to be sent directly via I2C. The hardware were this
is done via bit-bang will support. Also a few other devices like saa7134,
where data is sent byte by byte and kernel waits for the I2C device to indicate
that one byte were sent, and it can then forward the next byte. Yet, on
both cases, I don't think it is a good idea to send a 32 KB data into just
one I2C transaction.

However, on the devices where you pass a buffer to the hardware/firmware
(like all USB devices), the size of the I2C message is limited. The upper
limit is 80 bytes for an I2C control message, but several devices have
a lower limit for it.

Mauro.

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

Re: Current status report of mt9p031.

Hi Javier,

Here's the review of 0002-mt9p031.patch.

 diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c b/arch/arm/mach
 -omap2/board-omap3beagle-camera.c
 new file mode 100644
 index 000..92389dd
 --- /dev/null
 +++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
 @@ -0,0 +1,158 @@

[snip]

(This is clearly proof of concept code given the amount of lines that are 
commented out, so I'll skip the review.)

 +module_init(beagle_camera_init);
 +module_exit(beagle_camera_exit);
 +
 +MODULE_LICENSE(GPL v2);

The OMAP3 ISP isn't supposed to be registered in a loadable module. There have 
been preliminary discussions regarding how to properly achieve this, but not 
decision yet. For now it should be built-in, and you should use the 
omap3_init_camera() function.

 diff --git a/drivers/media/video/mt9p031.c b/drivers/media/video/mt9p031.c
 new file mode 100644
 index 000..d42d783
 --- /dev/null
 +++ b/drivers/media/video/mt9p031.c
 @@ -0,0 +1,884 @@
 +#include linux/delay.h
 +#include linux/device.h
 +#include linux/i2c.h
 +#include linux/log2.h
 +#include linux/pm.h
 +#include linux/regulator/consumer.h
 +#include linux/slab.h
 +#include media/v4l2-subdev.h
 +#include linux/videodev2.h
 +
 +#include media/mt9p031.h
 +#include media/v4l2-chip-ident.h
 +#include media/v4l2-subdev.h
 +#include media/v4l2-device.h
 +
 +/*
 + * mt9p031 i2c address 0x5d (0xBA read, 0xBB write) same as mt9t031
 + * The platform has to define i2c_board_info and link to it from
 + * struct soc_camera_link
 + */
 +
 +/* mt9p031 selected register addresses */
 +#define MT9P031_CHIP_VERSION 0x00
 +#define MT9P031_ROW_START0x01
 +#define MT9P031_COLUMN_START 0x02
 +#define MT9P031_WINDOW_HEIGHT0x03
 +#define MT9P031_WINDOW_WIDTH 0x04
 +#define MT9P031_HORIZONTAL_BLANKING  0x05
 +#define MT9P031_VERTICAL_BLANKING0x06
 +#define MT9P031_OUTPUT_CONTROL   0x07
 +#define MT9P031_SHUTTER_WIDTH_UPPER  0x08
 +#define MT9P031_SHUTTER_WIDTH0x09
 +#define MT9P031_PIXEL_CLOCK_CONTROL  0x0a
 +#define MT9P031_FRAME_RESTART0x0b
 +#define MT9P031_SHUTTER_DELAY0x0c
 +#define MT9P031_RESET0x0d
 +#define MT9P031_READ_MODE_1  0x1e
 +#define MT9P031_READ_MODE_2  0x20
 +//#define MT9T031_READ_MODE_30x21 // NA readmode_2 is 2 bytes

No commented out code please, and C code should be commented with /* ... */ in 
the Linux kernel.

 +#define MT9P031_ROW_ADDRESS_MODE 0x22
 +#define MT9P031_COLUMN_ADDRESS_MODE  0x23
 +#define MT9P031_GLOBAL_GAIN  0x35
 +//#define MT9T031_CHIP_ENABLE0xF8 // PDN is pin signal. no 
 i2c 
register
 +
 +#define MT9P031_MAX_HEIGHT   1944
 +#define MT9P031_MAX_WIDTH2592
 +#define MT9P031_MIN_HEIGHT   2
 +#define MT9P031_MIN_WIDTH18
 +#define MT9P031_HORIZONTAL_BLANK 0
 +#define MT9P031_VERTICAL_BLANK   25
 +#define MT9P031_COLUMN_SKIP  16
 +#define MT9P031_ROW_SKIP 54
 +
 +#define MT9P031_CHIP_VERSION_VALUE   0x1801

Could you move those constants just below the register that uses them, and 
make sure they have names that start with the register name ? Have a look at 
http://git.linuxtv.org/pinchartl/media.git?a=commit;h=d3fd150967a90a99fadd24ad4f5b4c1cce833493
 
for an example.

 +/*
 +#define MT9T031_BUS_PARAM(SOCAM_PCLK_SAMPLE_RISING | \
 + SOCAM_PCLK_SAMPLE_FALLING | SOCAM_HSYNC_ACTIVE_HIGH |   \
 + SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_DATA_ACTIVE_HIGH |  \
 + SOCAM_MASTER | SOCAM_DATAWIDTH_10)
 +*/
 +struct mt9p031 {
 + struct v4l2_subdev subdev;
 +struct media_pad pad;

s//\t/. Please run scripts/checkpatch.pl on your patches and fix the 
reported warnings and errors.

 +
 + struct v4l2_rect rect;  /* Sensor window */
 + struct v4l2_mbus_framefmt format;
 + int model;  /* V4L2_IDENT_MT9P031* codes from v4l2-chip-ident.h */
 + u16 xskip;
 + u16 yskip;
 + struct regulator *reg_1v8, *reg_2v8;
 +};

[snip]

 +static int reg_set(struct i2c_client *client, const u8 reg,
 +const u16 data)
 +{
 + int ret;
 +
 + ret = reg_read(client, reg);
 + if (ret  0)
 + return ret;
 + return reg_write(client, reg, ret | data);

To avoid an unnecessary I2C transaction, I would cache the register value in 
the driver instead of reading it back from the device.

 +}

[snip]

 +static int set_shutter(struct i2c_client *client, const u32 data)

This function isn't used.

 +{
 + int ret;
 +
 + ret = reg_write(client, MT9P031_SHUTTER_WIDTH_UPPER, data  16);
 +
 + if (ret = 0)
 + ret = reg_write(client, MT9P031_SHUTTER_WIDTH, data  0x);
 +
 + return ret;
 +}
 +
 +static int get_shutter(struct i2c_client *client, u32 *data)

And this one isn't used either.

 +{
 + int ret;
 +
 + ret = reg_read(client,

Re: CX24116 i2c patch

Em 05-05-2011 12:25, Devin Heitmueller escreveu:
 On Thu, May 5, 2011 at 8:28 AM, Steven Toth st...@kernellabs.com wrote:
 Mauro,

 Subject: [media] cx24116: add config option to split firmware download
 Author:  Antti Palosaari cr...@iki.fi
 Date:Wed Apr 27 21:03:07 2011 -0300

 It is very rare I2C adapter hardware which can provide 32kB I2C write
 as one write. Add .i2c_wr_max option to set desired max packet size.
 Split transaction to smaller pieces according to that option.

 This is none-sense. I'm naking this patch, please unqueue, regress or 
 whatever.

 The entire point of the i2c message send is that the i2c drivers know
 nothing about the host i2c implementation, and they should not need
 to. I2C SEND and RECEIVE are abstract and require no knowledge of the
 hardware. This is dangerous and generates non-atomic register writes.
 You cannot guarantee that another thread isn't reading/writing to
 other registers in the part - breaking the driver.

 Please fix the host controller to split the i2c messages accordingly
 (and thus keeping the entire transaction atomic).

 This is the second time I've seen the 'fix' to a problem by patching
 the i2c driver. Fix the i2c bridge else we'll see this behavior
 spreading to multiple i2c driver. It's just wrong.

 I tend to agree with Steven on this one.  That said, these sorts of
 things usually get introduced in cases where the i2c master is not
 well enough understood to know how to split the transactions and still
 preserve the repeat start (common with reverse engineered drivers).
 It can also occur in cases where there really is a hardware limitation
 that prevents the caller from making multiple requests to the chip
 while not sending the stop bit (although this is less common).

 Do we know this to be the case with the anysee bridge?  Is this a
 reverse engineered device?  Is there documentation/datasheets to
 reference?

 Do we know if this is an issue with the i2c master driver not being
 fully baked, or if it's a hardware limitation?

I can't tell you how Antti is working, but, since this is a USB device,
and cx24116 is trying to send a 32KB message via one single I2C transfer,
I can tell you for sure that that this won't work.

USB control messages can have, at maximum, 80 bytes of data on it. So,
the message needs to be broken into 80-byte payloads (assuming that
Anysee accepts the maximum size).

Mauro.

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

Re: DM1105: could not attach frontend 195d:1105

2011-05-05 Thread Igor M. Liplianin

В сообщении от 4 мая 2011 00:33:51 автор Mauro Carvalho Chehab написал:
Hi Igor,

Em 23-10-2010 07:20, Igor M. Liplianin escreveu:
В сообщении от 10 марта 2010 14:15:49 автор Hendrik Skarpeid написал:
Igor M. Liplianin skrev:
On 3 марта 2010 18:42:42 Hendrik Skarpeid wrote:
Igor M. Liplianin wrote:
Now to find GPIO's for LNB power control and ... watch TV :)

Yep. No succesful tuning at the moment. There might also be an issue
with the reset signal and writing to GPIOCTR, as the module at the
moment loads succesfully only once.
As far as I can make out, the LNB power control is probably GPIO 16
and 17, not sure which is which, and how they work.
GPIO15 is wired to tuner #reset

New patch to test

I think the LNB voltage may be a little to high on my card, 14.5V and
20V. I would be a little more happy if they were 14 and 19, 13 and 18
would be perfect.
Anyways, as Igor pointet out, I don't have any signal from the LNB,
checked with another tuner card. It's a quad LNB, and the other outputs
are fine. Maybe it's' toasted from to high supply voltage! I little word
of warning then.
Anyways, here's my tweaked driver.

Here is reworked patch for clear GPIO's handling.
It allows to support I2C on GPIO's and per board LNB control through
GPIO's. Also incuded support for Hendrik's card.
I think it is clear how to change and test GPIO's for LNB and other stuff
now.

To Hendrik:
Not shure, but there is maybe GPIO for raise/down LNB voltage a little
(~1v). It is used for long coaxial lines to compensate voltage
dropping.

Signed-off-by: Igor M. Liplianin liplia...@me.by

I'm not sure if this patch is still valid or not, and if it should or not
be applied, as there were several discussions around it. As a reference,
it is stored at patchwork with:
X-Patchwork-Id: 279091

And still applies fine (yet, patchwork lost patch history/comments and
SOB).

Igor, could you please update me if I should apply this patch or if the
patch got rejected/superseeded?

Thanks!
Mauro.
Hi Mauro,
The patch should be applied.
Do I need to do something, it means apply to a tree and send pull request?

Thanks!
Igor
--
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[cron job] v4l-dvb daily build: ERRORS

2011-05-05 Thread Hans Verkuil

This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Thu May  5 19:01:25 CEST 2011
git hash:eba6dfaa97f1424646ee09347f2cc4575ada0bc0
gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

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

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

[RFC v4] V4L2 API for flash devices

2011-05-05 Thread Sakari Ailus

Hi,

This is a fourth proposal for an interface for controlling flash devices
on the V4L2/v4l2_subdev APIs.

I want to thank everyone who have participated to the development of the
flash interface.

Comments and questions are very, very welcome as always.


Changes since v3 [12]
=

- V4L2_CID_FLASH_STROBE changed to button control,
V4L2_CID_FLASH_STROBE_STOP button control added,
V4L2_CID_FLASH_STROBE_STATUS boolean control added.

- No reason to say xenon flashes can't use V4L2_CID_FLASH_STROBE.

- V4L2_CID_FLASH_STROBE_WHENCE changed to V4L2_CID_FLASH_STROBE_MODE.

- V4L2_CID_TORCH_INTENSITY renamed to V4L2_CID_FLASH_TORCH_INTENSITY and
V4L2_CID_INDICATOR_INTENSITY renamed to V4L2_CID_FLASH_INDICATOR_INTENSITY.

- Moved V4L2_CID_FLASH_EXTERNAL_STROBE_MODE under Possible future
extensions.


Changes since v2 [9]


- Rearranged proposed controls. V4L2_CID_FLASH_LED_MODE is now the first
control.

- Added an open question on naming of indicator and torch controls.

- V4L2_CID_FLASH_STROBE_MODE renamed to V4L2_CID_FLASH_STROBE_WHENCE.
V4L2_CID_FLASH_EXTERNAL_STROBE_WHENCE renamed to
V4L2_CID_FLASH_EXTERNAL_STROBE_MODE.

- Removed CID_ from V4L2_CID_FLASH_EXTERNAL_STROBE_MODE values.

- Added a new use case based on [11]: Synchronised LED flash (hardware
strobe, timed exposure).

- Added section on possible future extensions.

- Complemented the open question on units.


Changes since v1 [7]


- V4L2_FLASH_STROBE_MODE_EXT_STROBE renamed to
V4L2_FLASH_STROBE_MODE_EXTERNAL.

- V4L2_CID_FLASH_STROBE control changed from button to bool.

- Removed suggestion of adding V4L2_CID_FLASH_DURATION.
V4L2_CID_FLASH_TIMEOUT is used as hardware timeout.

- Added control access info (ro/rw).

- V4L2_FLASH_MODE_NONE added, V4L2_FLASH_LED_MODE_FLASH no longer forced
as 1 in enum.

- Bits use (1  x) instead of 0x00... format.

- Added an open question on flash LED mode controls.

- Added an open question on a new control:
V4L2_CID_FLASH_EXTERNAL_STROBE_WHENCE.

- Added an open question on control units.


Scope
=

This RFC is focused mostly on the ADP1653 [1] and similar chips [2, 3]
which provides following functionality. [2, 3] mostly differ on the
available faults --- for example, there are faults also for the
indicator LED.

- High power LED output (flash or torch modes)
- Low power indicator LED output (a.k.a. privacy light)
- Programmable flash timeout
- Software and hardware strobe
- Fault detection
- Overvoltage
- Overtemperature
- Short circuit
- Timeout
- Programmable current (both high-power and indicator LEDs)

If anyone else is aware of hardware which significantly differs from
these and does not get served well under the proposed interface, please
tell about it.

This RFC does NOT address the synchronisation of the flash to a given
frame since this task is typically performed by the sensor through a
strobe signal. The host does not have enough information for this ---
exact timing information on the exposure of the sensor pixel array. In
this case the flash synchronisation is visible to the flash controller
as the hardware strobe originating from the sensor.

Flash synchronisation requires

1) flash control capability from the sensor including a strobe output,
2) strobe input in the flash controller,
3) (optionally) ability to program sensor parameters at given frame,
such as flash strobe, and
4) ability to read back metadata produced by the sensor related to a
given frame. This should include whether the frame is exposed with
flash, i.e. the sensor's flash strobe output.

Since we have little examples of both in terms of hardware support,
which is in practice required, it was decided to postpone the interface
specification for now. [6]

Xenon flash controllers exist but I don't have a specific example of
those. Typically the interface is quite simple. Gpio pins for charge and
strobe. The length of the strobe signal determines the strength of the
flash pulse. The strobe is controlled by the sensor as for LED flash if
it is hardware based.

See Possible future extensions section below for more.


Known use cases
===

The use case listed below concentrate on using a flash in a mobile
device, for example in a mobile phone. The use cases could be somewhat
different in devices the primary use of which is camera.

Unsynchronised LED flash (software strobe)
--

Unsynchronised LED flash is controlled directly by the host as the
sensor. The flash must be enabled by the host before the exposure of the
image starts and disabled once it ends. The host is fully responsible
for the timing of the flash.

Example of such device: Nokia N900.

Synchronised LED flash (hardware strobe)


The synchronised LED flash is pre-programmed by the host (power and
timeout) but controlled by the sensor through a strobe signal from the
sensor to the flash.

Re: Patches still pending at linux-media queue (18 patches)

2011-05-05 Thread Jonathan Corbet

On Thu, 05 May 2011 00:58:51 -0300
Mauro Carvalho Chehab mche...@redhat.com wrote:

 Jon,
   One patch for your ack ;)
 
 Apr,29 2011: [media] via-camera: add MODULE_ALIAS 
   http://patchwork.kernel.org/patch/742581  Daniel Drake d...@laptop.org

Sorry...it's just a module alias, figured nobody would worry about it.
It's fine, feel free to toss my Acked-by onto it.

Thanks,

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

Re: [linux-dvb] TeVii S470 (cx23885 / ds3000) makes the machine unstable

2011-05-05 Thread Igor M. Liplianin

В сообщении от 5 мая 2011 20:38:06 автор Andrew Junev написал:
 Hello All,
 
   I'm  trying  to set up a TeVii S470 DVB-S2 card for use in my MythTV
   system  running  on  Fedora 13. I already have a couple of TT S-1401
   cards in that machine, and it works fine.
 
   I  copied   the  firmware for my S470 as described on the Wiki page.
   The  card is detected  and seem to work. I am able to watch existing
   channels, and even found some DVB-S2 transponders.
 
   But  the  machine  is  very  unstable. After a while, I get a lot of
   errors in my /var/log/messages , like:
 
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xb2(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_writereg: writereg error(err ==
 -5, reg == 0x03, value == 0x11) May  3 22:35:51 localhost kernel:
 ds3000_tuner_writereg: writereg error(err == -5, reg == 0x42, value ==
 0x73) May  3 22:35:51 localhost kernel: ds3000_writereg: writereg
 error(err == -5, reg == 0x03, value == 0x11) May  3 22:35:51 localhost
 kernel: ds3000_tuner_writereg: writereg error(err == -5, reg == 0x05,
 value == 0x01) May  3 22:35:51 localhost kernel: ds3000_writereg: writereg
 error(err == -5, reg == 0x03, value == 0x11) May  3 22:35:51 localhost
 kernel: ds3000_tuner_writereg: writereg error(err == -5, reg == 0x62,
 value == 0xf5)
 
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 
 
 There   are   a  lot  of  lines  like  these  in the log (tens or even
 hundreds  per  second).  And  at some point the machine just freezes -
 stops  responding  completely.  It  happens  even  if I'm not watching
 anything.
 
 If I take the S470 out, my machine works just fine again.
 
 
 Some more info from the log - perhaps something could be useful:
 
 May  2 20:39:15 localhost kernel: Linux video capture interface: v2.00
 May  2 20:39:15 localhost kernel: cx23885 driver version 0.0.2 loaded
 May  2 20:39:15 localhost kernel: cx23885 :04:00.0: PCI INT A - GSI 18
 (level, low) - IRQ 18 May  2 20:39:15 localhost kernel: LNBx2x attached
 on addr=8
 May  2 20:39:15 localhost kernel: DVB: registering adapter 0 frontend 0
 (Philips TDA10086 DVB-S)... May  2 20:39:15 localhost kernel: budget dvb
 :06:02.0: PCI INT A - GSI 18 (level, low) - IRQ 18 May  2 20:39:15
 localhost kernel: CORE cx23885[0]: subsystem: d470:9022, board: TeVii S470
 [card=15,autodetected] May  2 20:39:15 localhost kernel: IRQ 18/:
 IRQF_DISABLED is not guaranteed on shared IRQs May  2 20:39:15 localhost
 kernel: saa7146: found saa7146 @ mem fb3f4800 (revision 1, irq 18)
 (0x13c2,0x1018). May  2 20:39:15 localhost kernel: saa7146 (1): dma buffer
 size 192512 May  2 20:39:15 localhost kernel: DVB: registering new adapter
 (TT-Budget-S-1401 PCI) May  2 20:39:15 localhost kernel: adapter has MAC
 addr = 00:d0:5c:0b:01:2d May  2 20:39:15 localhost kernel: LNBx2x attached
 on addr=8
 May  2 20:39:15 localhost kernel: DVB: registering adapter 1 frontend 0
 (Philips TDA10086 DVB-S)... May  2 20:39:15 localhost kernel:
 cx23885_dvb_register() allocating 1 frontend(s) May  2 20:39:15 localhost
 kernel: cx23885[0]: cx23885 based dvb card May  2 20:39:15 localhost
 kernel: DS3000 chip version: 0.192 attached. May  2 20:39:15 localhost
 kernel: DVB: registering new adapter (cx23885[0]) May  2 20:39:15
 localhost kernel: DVB: registering adapter 2 frontend 0 (Montage
 Technology DS3000/TS2020)... May  2 20:39:15 localhost kernel:
 cx23885_dev_checkrevision() Hardware revision = 0xb0 May  2 20:39:15
 localhost kernel: cx23885[0]/0: found at :04:00.0, rev: 2, irq: 18,
 latency: 0, mmio: 0xfe80 May  2 20:39:15 localhost kernel: IRQ
 18/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 
 
 # uname -a
 Linux mythbackend 2.6.34.8-68.fc13.i686.PAE #1 SMP Thu Feb 17 14:54:10 UTC
 2011 i686 i686 i386 GNU/Linux #
 
 
 I searched the Net and found a similar question that was raised some time
 ago, but there was not even a discussion on this topic...
 
 If

Re: DM1105: could not attach frontend 195d:1105

Em 05-05-2011 15:41, Igor M. Liplianin escreveu:
В сообщении от 4 мая 2011 00:33:51 автор Mauro Carvalho Chehab написал:
Hi Igor,

New patch to test

To Hendrik:
Not shure, but there is maybe GPIO for raise/down LNB voltage a little
(~1v). It is used for long coaxial lines to compensate voltage
dropping.

Signed-off-by: Igor M. Liplianin liplia...@me.by

And still applies fine (yet, patchwork lost patch history/comments and
SOB).

Igor, could you please update me if I should apply this patch or if the
patch got rejected/superseeded?

Thanks!
Mauro.
Hi Mauro,
The patch should be applied.
Do I need to do something, it means apply to a tree and send pull request?

I could just apply it, as your email is an ack for it, but, as it is not
properly documented, I prefer if you can send an email to the mailing list
with the patch properly described.

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

[PATCH] dm1105: GPIO handling added, I2C on GPIO added, LNB control through GPIO reworked

2011-05-05 Thread Igor M. Liplianin

Here is patch for GPIO's handling.
It allows to support I2C on GPIO's and per board LNB control through GPIO's.
Also incuded some support for Hendrik Skarpeid card.
For those, who needs to tweak the driver,
I think it is clear how to change and test GPIO's for LNB and other GPIO 
related stuff now.

Signed-off-by: Igor M. Liplianin liplia...@me.by
diff -r abd3aac6644e linux/drivers/media/dvb/dm1105/dm1105.c
--- a/linux/drivers/media/dvb/dm1105/dm1105.c	Fri Jul 02 00:38:54 2010 -0300
+++ b/linux/drivers/media/dvb/dm1105/dm1105.c	Sat Oct 23 11:58:32 2010 +0300
@@ -20,6 +20,7 @@
  */
 
 #include linux/i2c.h
+#include linux/i2c-algo-bit.h
 #include linux/init.h
 #include linux/kernel.h
 #include linux/module.h
@@ -50,11 +51,12 @@
 
 #define UNSET (-1U)
 
-#define DM1105_BOARD_NOAUTO		UNSET
-#define DM1105_BOARD_UNKNOWN		0
-#define DM1105_BOARD_DVBWORLD_2002	1
-#define DM1105_BOARD_DVBWORLD_2004	2
-#define DM1105_BOARD_AXESS_DM05		3
+#define DM1105_BOARD_NOAUTO			UNSET
+#define DM1105_BOARD_UNKNOWN			0
+#define DM1105_BOARD_DVBWORLD_2002		1
+#define DM1105_BOARD_DVBWORLD_2004		2
+#define DM1105_BOARD_AXESS_DM05			3
+#define DM1105_BOARD_UNBRANDED_I2C_ON_GPIO	4
 
 /* --- */
 /*
@@ -158,22 +160,38 @@
 #define DM1105_MAX0x04
 
 #define DRIVER_NAMEdm1105
+#define DM1105_I2C_GPIO_NAME			dm1105-gpio
 
 #define DM1105_DMA_PACKETS			47
 #define DM1105_DMA_PACKET_LENGTH		(128*4)
 #define DM1105_DMA_BYTES			(128 * 4 * DM1105_DMA_PACKETS)
 
+/*  */
+#define GPIO08	(1  8)
+#define GPIO13	(1  13)
+#define GPIO14	(1  14)
+#define GPIO15	(1  15)
+#define GPIO16	(1  16)
+#define GPIO17	(1  17)
+#define GPIO_ALL0x03
+
 /* GPIO's for LNB power control */
-#define DM1105_LNB_MASK0x
-#define DM1105_LNB_OFF0x0002
-#define DM1105_LNB_13V0x00010100
-#define DM1105_LNB_18V0x0100
+#define DM1105_LNB_MASK(GPIO_ALL  ~(GPIO14 | GPIO13))
+#define DM1105_LNB_OFFGPIO17
+#define DM1105_LNB_13V(GPIO16 | GPIO08)
+#define DM1105_LNB_18VGPIO08
 
 /* GPIO's for LNB power control for Axess DM05 */
-#define DM05_LNB_MASK0x
-#define DM05_LNB_OFF0x0002/* actually 13v */
-#define DM05_LNB_13V0x0002
-#define DM05_LNB_18V0x0003
+#define DM05_LNB_MASK(GPIO_ALL  ~(GPIO14 | GPIO13))
+#define DM05_LNB_OFFGPIO17/* actually 13v */
+#define DM05_LNB_13VGPIO17
+#define DM05_LNB_18V(GPIO17 | GPIO16)
+
+/* GPIO's for LNB power control for unbranded with I2C on GPIO */
+#define UNBR_LNB_MASK(GPIO17 | GPIO16)
+#define UNBR_LNB_OFF0
+#define UNBR_LNB_13VGPIO17
+#define UNBR_LNB_18V(GPIO17 | GPIO16)
 
 static unsigned int card[]  = {[0 ... 3] = UNSET };
 module_param_array(card,  int, NULL, 0444);
@@ -188,7 +206,11 @@
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
 struct dm1105_board {
-	char*name;
+	char	*name;
+	struct	{
+		u32	mask, off, v13, v18;
+	} lnb;
+	u32	gpio_scl, gpio_sda;
 };
 
 struct dm1105_subid {
@@ -200,15 +222,50 @@
 static const struct dm1105_board dm1105_boards[] = {
 	[DM1105_BOARD_UNKNOWN] = {
 		.name		= UNKNOWN/GENERIC,
+		.lnb = {
+			.mask = DM1105_LNB_MASK,
+			.off = DM1105_LNB_OFF,
+			.v13 = DM1105_LNB_13V,
+			.v18 = DM1105_LNB_18V,
+		},
 	},
 	[DM1105_BOARD_DVBWORLD_2002] = {
 		.name		= DVBWorld PCI 2002,
+		.lnb = {
+			.mask = DM1105_LNB_MASK,
+			.off = DM1105_LNB_OFF,
+			.v13 = DM1105_LNB_13V,
+			.v18 = DM1105_LNB_18V,
+		},
 	},
 	[DM1105_BOARD_DVBWORLD_2004] = {
 		.name		= DVBWorld PCI 2004,
+		.lnb = {
+			.mask = DM1105_LNB_MASK,
+			.off = DM1105_LNB_OFF,
+			.v13 = DM1105_LNB_13V,
+			.v18 = DM1105_LNB_18V,
+		},
 	},
 	[DM1105_BOARD_AXESS_DM05] = {
 		.name		= Axess/EasyTv DM05,
+		.lnb = {
+			.mask = DM05_LNB_MASK,
+			.off = DM05_LNB_OFF,
+			.v13 = DM05_LNB_13V,
+			.v18 = DM05_LNB_18V,
+		},
+	},
+	[DM1105_BOARD_UNBRANDED_I2C_ON_GPIO] = {
+		.name		= Unbranded DM1105 with i2c on GPIOs,
+		.lnb = {
+			.mask = UNBR_LNB_MASK,
+			.off = UNBR_LNB_OFF,
+			.v13 = UNBR_LNB_13V,
+			.v18 = UNBR_LNB_18V,
+		},
+		.gpio_scl	= GPIO14,
+		.gpio_sda	= GPIO13,
 	},
 };
 
@@ -294,6 +351,8 @@
 
 	/* i2c */
 	struct i2c_adapter i2c_adap;
+	struct i2c_adapter i2c_bb_adap;
+	struct i2c_algo_bit_data i2c_bit;
 
 	/* irq */
 	struct work_struct work;
@@ -329,6 +388,103 @@
 #define dm_setl(reg, bit)	dm_andorl((reg), (bit), (bit))
 #define dm_clearl(reg, bit)	dm_andorl((reg), (bit), 0)
 
+/* The chip has 18 GPIOs. In HOST mode GPIO's used as 15 bit address lines,
+ so we can use only 3 GPIO's from GPIO15 to GPIO17.
+ Here I don't check whether HOST is enebled as it is not implemented yet.
+ */
+static void dm1105_gpio_set(struct dm1105_dev *dev, u32 mask)
+{
+	if (mask  0xfffc)
+		printk(KERN_ERR %s: Only 18 GPIO's are allowed\n, __func__);
+
+	if (mask  0x0003)
+		dm_setl(DM1105_GPIOVAL, mask  0x0003);
+
+}
+
+static void dm1105_gpio_clear(struct dm1105_dev *dev, u32 mask)
+{
+	if (mask  0xfffc)
+

Re: [linux-dvb] TeVii S470 (cx23885 / ds3000) makes the machine unstable

2011/5/5 Andrew Junev a...@a-j.ru:
 Hello All,

  I'm  trying  to set up a TeVii S470 DVB-S2 card for use in my MythTV
  system  running  on  Fedora 13. I already have a couple of TT S-1401
  cards in that machine, and it works fine.

  I  copied   the  firmware for my S470 as described on the Wiki page.
  The  card is detected  and seem to work. I am able to watch existing
  channels, and even found some DVB-S2 transponders.

  But  the  machine  is  very  unstable. After a while, I get a lot of
  errors in my /var/log/messages , like:

 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xb2(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_writereg: writereg error(err == -5, 
 reg == 0x03, value == 0x11)
 May  3 22:35:51 localhost kernel: ds3000_tuner_writereg: writereg error(err 
 == -5, reg == 0x42, value == 0x73)
 May  3 22:35:51 localhost kernel: ds3000_writereg: writereg error(err == -5, 
 reg == 0x03, value == 0x11)
 May  3 22:35:51 localhost kernel: ds3000_tuner_writereg: writereg error(err 
 == -5, reg == 0x05, value == 0x01)
 May  3 22:35:51 localhost kernel: ds3000_writereg: writereg error(err == -5, 
 reg == 0x03, value == 0x11)
 May  3 22:35:51 localhost kernel: ds3000_tuner_writereg: writereg error(err 
 == -5, reg == 0x62, value == 0xf5)

 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)


 There   are   a  lot  of  lines  like  these  in the log (tens or even
 hundreds  per  second).  And  at some point the machine just freezes -
 stops  responding  completely.  It  happens  even  if I'm not watching
 anything.

 If I take the S470 out, my machine works just fine again.


 Some more info from the log - perhaps something could be useful:

 May  2 20:39:15 localhost kernel: Linux video capture interface: v2.00
 May  2 20:39:15 localhost kernel: cx23885 driver version 0.0.2 loaded
 May  2 20:39:15 localhost kernel: cx23885 :04:00.0: PCI INT A - GSI 18 
 (level, low) - IRQ 18
 May  2 20:39:15 localhost kernel: LNBx2x attached on addr=8
 May  2 20:39:15 localhost kernel: DVB: registering adapter 0 frontend 0 
 (Philips TDA10086 DVB-S)...
 May  2 20:39:15 localhost kernel: budget dvb :06:02.0: PCI INT A - GSI 
 18 (level, low) - IRQ 18
 May  2 20:39:15 localhost kernel: CORE cx23885[0]: subsystem: d470:9022, 
 board: TeVii S470 [card=15,autodetected]
 May  2 20:39:15 localhost kernel: IRQ 18/: IRQF_DISABLED is not guaranteed on 
 shared IRQs
 May  2 20:39:15 localhost kernel: saa7146: found saa7146 @ mem fb3f4800 
 (revision 1, irq 18) (0x13c2,0x1018).
 May  2 20:39:15 localhost kernel: saa7146 (1): dma buffer size 192512
 May  2 20:39:15 localhost kernel: DVB: registering new adapter 
 (TT-Budget-S-1401 PCI)
 May  2 20:39:15 localhost kernel: adapter has MAC addr = 00:d0:5c:0b:01:2d
 May  2 20:39:15 localhost kernel: LNBx2x attached on addr=8
 May  2 20:39:15 localhost kernel: DVB: registering adapter 1 frontend 0 
 (Philips TDA10086 DVB-S)...
 May  2 20:39:15 localhost kernel: cx23885_dvb_register() allocating 1 
 frontend(s)
 May  2 20:39:15 localhost kernel: cx23885[0]: cx23885 based dvb card
 May  2 20:39:15 localhost kernel: DS3000 chip version: 0.192 attached.
 May  2 20:39:15 localhost kernel: DVB: registering new adapter (cx23885[0])
 May  2 20:39:15 localhost kernel: DVB: registering adapter 2 frontend 0 
 (Montage Technology DS3000/TS2020)...
 May  2 20:39:15 localhost kernel: cx23885_dev_checkrevision() Hardware 
 revision = 0xb0
 May  2 20:39:15 localhost kernel: cx23885[0]/0: found at :04:00.0, rev: 
 2, irq: 18, latency: 0, mmio: 0xfe80
 May  2 20:39:15 localhost kernel: IRQ 18/cx23885[0]: IRQF_DISABLED is not 
 guaranteed on shared IRQs


 # uname -a
 Linux mythbackend 2.6.34.8-68.fc13.i686.PAE #1 SMP Thu Feb 17 14:54:10 UTC 
 2011 i686 i686 i386 GNU/Linux
 #


 I searched the Net and found a similar question that was raised some time
 ago, but there was not even a discussion on this topic...

 If  someone  else  has  the

Re: [linux-dvb] TeVii S470 (cx23885 / ds3000) makes the machine unstable

2011/5/5 Andrew Junev a...@a-j.ru:
 Hello All,

  I'm  trying  to set up a TeVii S470 DVB-S2 card for use in my MythTV
  system  running  on  Fedora 13. I already have a couple of TT S-1401
  cards in that machine, and it works fine.

  I  copied   the  firmware for my S470 as described on the Wiki page.
  The  card is detected  and seem to work. I am able to watch existing
  channels, and even found some DVB-S2 transponders.

  But  the  machine  is  very  unstable. After a while, I get a lot of
  errors in my /var/log/messages , like:

 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xb2(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_writereg: writereg error(err == -5, 
 reg == 0x03, value == 0x11)
 May  3 22:35:51 localhost kernel: ds3000_tuner_writereg: writereg error(err 
 == -5, reg == 0x42, value == 0x73)
 May  3 22:35:51 localhost kernel: ds3000_writereg: writereg error(err == -5, 
 reg == 0x03, value == 0x11)
 May  3 22:35:51 localhost kernel: ds3000_tuner_writereg: writereg error(err 
 == -5, reg == 0x05, value == 0x01)
 May  3 22:35:51 localhost kernel: ds3000_writereg: writereg error(err == -5, 
 reg == 0x03, value == 0x11)
 May  3 22:35:51 localhost kernel: ds3000_tuner_writereg: writereg error(err 
 == -5, reg == 0x62, value == 0xf5)

 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)


 There   are   a  lot  of  lines  like  these  in the log (tens or even
 hundreds  per  second).  And  at some point the machine just freezes -
 stops  responding  completely.  It  happens  even  if I'm not watching
 anything.

 If I take the S470 out, my machine works just fine again.


 Some more info from the log - perhaps something could be useful:

 May  2 20:39:15 localhost kernel: Linux video capture interface: v2.00
 May  2 20:39:15 localhost kernel: cx23885 driver version 0.0.2 loaded
 May  2 20:39:15 localhost kernel: cx23885 :04:00.0: PCI INT A - GSI 18 
 (level, low) - IRQ 18
 May  2 20:39:15 localhost kernel: LNBx2x attached on addr=8
 May  2 20:39:15 localhost kernel: DVB: registering adapter 0 frontend 0 
 (Philips TDA10086 DVB-S)...
 May  2 20:39:15 localhost kernel: budget dvb :06:02.0: PCI INT A - GSI 
 18 (level, low) - IRQ 18
 May  2 20:39:15 localhost kernel: CORE cx23885[0]: subsystem: d470:9022, 
 board: TeVii S470 [card=15,autodetected]
 May  2 20:39:15 localhost kernel: IRQ 18/: IRQF_DISABLED is not guaranteed on 
 shared IRQs
 May  2 20:39:15 localhost kernel: saa7146: found saa7146 @ mem fb3f4800 
 (revision 1, irq 18) (0x13c2,0x1018).
 May  2 20:39:15 localhost kernel: saa7146 (1): dma buffer size 192512
 May  2 20:39:15 localhost kernel: DVB: registering new adapter 
 (TT-Budget-S-1401 PCI)
 May  2 20:39:15 localhost kernel: adapter has MAC addr = 00:d0:5c:0b:01:2d
 May  2 20:39:15 localhost kernel: LNBx2x attached on addr=8
 May  2 20:39:15 localhost kernel: DVB: registering adapter 1 frontend 0 
 (Philips TDA10086 DVB-S)...
 May  2 20:39:15 localhost kernel: cx23885_dvb_register() allocating 1 
 frontend(s)
 May  2 20:39:15 localhost kernel: cx23885[0]: cx23885 based dvb card
 May  2 20:39:15 localhost kernel: DS3000 chip version: 0.192 attached.
 May  2 20:39:15 localhost kernel: DVB: registering new adapter (cx23885[0])
 May  2 20:39:15 localhost kernel: DVB: registering adapter 2 frontend 0 
 (Montage Technology DS3000/TS2020)...
 May  2 20:39:15 localhost kernel: cx23885_dev_checkrevision() Hardware 
 revision = 0xb0
 May  2 20:39:15 localhost kernel: cx23885[0]/0: found at :04:00.0, rev: 
 2, irq: 18, latency: 0, mmio: 0xfe80
 May  2 20:39:15 localhost kernel: IRQ 18/cx23885[0]: IRQF_DISABLED is not 
 guaranteed on shared IRQs


 # uname -a
 Linux mythbackend 2.6.34.8-68.fc13.i686.PAE #1 SMP Thu Feb 17 14:54:10 UTC 
 2011 i686 i686 i386 GNU/Linux
 #


 I searched the Net and found a similar question that was raised some time
 ago, but there was not even a discussion on this topic...

 If  someone  else  has  the

Re: [linux-dvb] TeVii S470 (cx23885 / ds3000) makes the machine unstable

2011/5/5 Andrew Junev a...@a-j.ru:
 Hello All,

  I'm  trying  to set up a TeVii S470 DVB-S2 card for use in my MythTV
  system  running  on  Fedora 13. I already have a couple of TT S-1401
  cards in that machine, and it works fine.

  I  copied   the  firmware for my S470 as described on the Wiki page.
  The  card is detected  and seem to work. I am able to watch existing
  channels, and even found some DVB-S2 transponders.

  But  the  machine  is  very  unstable. After a while, I get a lot of
  errors in my /var/log/messages , like:

 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xb2(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_writereg: writereg error(err == -5, 
 reg == 0x03, value == 0x11)
 May  3 22:35:51 localhost kernel: ds3000_tuner_writereg: writereg error(err 
 == -5, reg == 0x42, value == 0x73)
 May  3 22:35:51 localhost kernel: ds3000_writereg: writereg error(err == -5, 
 reg == 0x03, value == 0x11)
 May  3 22:35:51 localhost kernel: ds3000_tuner_writereg: writereg error(err 
 == -5, reg == 0x05, value == 0x01)
 May  3 22:35:51 localhost kernel: ds3000_writereg: writereg error(err == -5, 
 reg == 0x03, value == 0x11)
 May  3 22:35:51 localhost kernel: ds3000_tuner_writereg: writereg error(err 
 == -5, reg == 0x62, value == 0xf5)

 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)
 May  3 22:35:51 localhost kernel: ds3000_readreg: reg=0xd(error=-5)


 There   are   a  lot  of  lines  like  these  in the log (tens or even
 hundreds  per  second).  And  at some point the machine just freezes -
 stops  responding  completely.  It  happens  even  if I'm not watching
 anything.

 If I take the S470 out, my machine works just fine again.


 Some more info from the log - perhaps something could be useful:

 May  2 20:39:15 localhost kernel: Linux video capture interface: v2.00
 May  2 20:39:15 localhost kernel: cx23885 driver version 0.0.2 loaded
 May  2 20:39:15 localhost kernel: cx23885 :04:00.0: PCI INT A - GSI 18 
 (level, low) - IRQ 18
 May  2 20:39:15 localhost kernel: LNBx2x attached on addr=8
 May  2 20:39:15 localhost kernel: DVB: registering adapter 0 frontend 0 
 (Philips TDA10086 DVB-S)...
 May  2 20:39:15 localhost kernel: budget dvb :06:02.0: PCI INT A - GSI 
 18 (level, low) - IRQ 18
 May  2 20:39:15 localhost kernel: CORE cx23885[0]: subsystem: d470:9022, 
 board: TeVii S470 [card=15,autodetected]
 May  2 20:39:15 localhost kernel: IRQ 18/: IRQF_DISABLED is not guaranteed on 
 shared IRQs
 May  2 20:39:15 localhost kernel: saa7146: found saa7146 @ mem fb3f4800 
 (revision 1, irq 18) (0x13c2,0x1018).
 May  2 20:39:15 localhost kernel: saa7146 (1): dma buffer size 192512
 May  2 20:39:15 localhost kernel: DVB: registering new adapter 
 (TT-Budget-S-1401 PCI)
 May  2 20:39:15 localhost kernel: adapter has MAC addr = 00:d0:5c:0b:01:2d
 May  2 20:39:15 localhost kernel: LNBx2x attached on addr=8
 May  2 20:39:15 localhost kernel: DVB: registering adapter 1 frontend 0 
 (Philips TDA10086 DVB-S)...
 May  2 20:39:15 localhost kernel: cx23885_dvb_register() allocating 1 
 frontend(s)
 May  2 20:39:15 localhost kernel: cx23885[0]: cx23885 based dvb card
 May  2 20:39:15 localhost kernel: DS3000 chip version: 0.192 attached.
 May  2 20:39:15 localhost kernel: DVB: registering new adapter (cx23885[0])
 May  2 20:39:15 localhost kernel: DVB: registering adapter 2 frontend 0 
 (Montage Technology DS3000/TS2020)...
 May  2 20:39:15 localhost kernel: cx23885_dev_checkrevision() Hardware 
 revision = 0xb0
 May  2 20:39:15 localhost kernel: cx23885[0]/0: found at :04:00.0, rev: 
 2, irq: 18, latency: 0, mmio: 0xfe80
 May  2 20:39:15 localhost kernel: IRQ 18/cx23885[0]: IRQF_DISABLED is not 
 guaranteed on shared IRQs


 # uname -a
 Linux mythbackend 2.6.34.8-68.fc13.i686.PAE #1 SMP Thu Feb 17 14:54:10 UTC 
 2011 i686 i686 i386 GNU/Linux
 #


 I searched the Net and found a similar question that was raised some time
 ago, but there was not even a discussion on this topic...

 If  someone  else  has  the

Re: [PATCH] Fix cx88 remote control input

2011-05-05 Thread Greg KH

On Wed, May 04, 2011 at 11:25:10PM -0300, Mauro Carvalho Chehab wrote:
 Em 04-05-2011 17:36, Greg KH escreveu:
  Yes, as long as .39 is working properly.  We take patches in -stable for
  stuff like this at times, it just needs to be specified exactly like you
  did above.
 
 OK.
 
  Want me to take this patch as-is for .38-stable?
 
 Yes, please. I'm forwarding you bellow with the proper authorship/SOB/ack.
 
 This patch fixes RC for 64 bits kernels. The extra fix for 32 bits kernels,
 (solves a calculus overflow), were sent today to -next. I generally wait 
 for a couple days before asking Linus to pull from it.

Now queued up.

thanks,

greg k-h
--
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] cx88: Fix HVR4000 IR keymap has been added to the 2.6.38-stable tree

2011-05-05 Thread gregkh


This is a note to let you know that I've just added the patch titled

[media] cx88: Fix HVR4000 IR keymap

to the 2.6.38-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 cx88-fix-hvr4000-ir-keymap.patch
and it can be found in the queue-2.6.38 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let sta...@kernel.org know about it.


From mche...@redhat.com  Thu May  5 13:34:25 2011
From: Lawrence Rust l...@softsystem.dot.uk
Date: Wed, 04 May 2011 23:25:10 -0300
Subject: [media] cx88: Fix HVR4000 IR keymap
To: Greg KH g...@kroah.com
Cc: Jarod Wilson ja...@wilsonet.com, Lawrence Rust 
lawre...@softsystem.co.uk, Linux Media Mailing List 
linux-media@vger.kernel.org
Message-ID: 4dc20a86.7010...@redhat.com

From: Lawrence Rust l...@softsystem.dot.uk

[fixed in .39 in a much different way that is too big to backport to
.38 - gregkh]

Fixes the RC key input for Nova-S plus, HVR1100, HVR3000 and HVR4000 in
the 2.6.38 kernel.

Signed-off-by: Lawrence Rust l...@softsystem.dot.uk
Acked-by: Jarod Wilson ja...@wilsonet.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

---
 drivers/media/video/cx88/cx88-input.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/video/cx88/cx88-input.c
+++ b/drivers/media/video/cx88/cx88-input.c
@@ -283,7 +283,7 @@ int cx88_ir_init(struct cx88_core *core,
case CX88_BOARD_PCHDTV_HD3000:
case CX88_BOARD_PCHDTV_HD5500:
case CX88_BOARD_HAUPPAUGE_IRONLY:
-   ir_codes = RC_MAP_HAUPPAUGE_NEW;
+   ir_codes = RC_MAP_RC5_HAUPPAUGE_NEW;
ir-sampling = 1;
break;
case CX88_BOARD_WINFAST_DTV2000H:


Patches currently in stable-queue which might be from l...@softsystem.dot.uk are

queue-2.6.38/cx88-fix-hvr4000-ir-keymap.patch
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] TeVii S470 (cx23885 / ds3000) makes the machine unstable