Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG

[Hans de Goede]

Hi,

On 05-10-18 13:55, Mauro Carvalho Chehab wrote:

Em Mon, 1 Oct 2018 18:19:21 +0100
Dave Stevenson  escreveu:


Hi All,

On Mon, 1 Oct 2018 at 17:32, Ezequiel Garcia  wrote:


Hi Hans,

Thanks for looking into. I remember MJPEG vs. JPEG being a source
of confusion for me a few years ago, so clarification is greatly
welcome :-)

On Mon, 2018-10-01 at 15:03 +0300, Laurent Pinchart wrote:

Hi Hans,

On Monday, 1 October 2018 14:54:29 EEST Hans Verkuil wrote:

On 10/01/2018 01:48 PM, Laurent Pinchart wrote:

On Monday, 1 October 2018 11:43:04 EEST Hans Verkuil wrote:

It turns out that we have both JPEG and Motion-JPEG pixel formats
defined.

Furthermore, some drivers support one, some the other and some both.

These pixelformats both mean the same.


Do they ? I thought MJPEG was JPEG using fixed Huffman tables that were
not included in the JPEG headers.


I'm not aware of any difference. If there is one, then it is certainly not
documented.


What I can tell for sure is that many UVC devices don't include Huffman tables
in their JPEG headers.
  

Ezequiel, since you've been working with this recently, do you know anything
about this?


  


JPEG frames must include huffman and quantization tables, as per the standard.

AFAIK, there's no MJPEG specification per-se and vendors specify its own
way of conveying a Motion JPEG stream.


There is the specfication for MJPEG in Quicktime containers, which
defines the MJPEG-A and MJPEG-B variants [1].
MJPEG-B is not a concatenation of JPEG frames as the framing is
different, so can't really be combined into V4L2_PIX_FMT_JPEG.
Have people encountered devices that produce MJPEG-A or MJPEG-B via
V4L2? I haven't, but I have been forced to support both variants on
decode.


Checking it is not an easy task. I *suspect* that those cameras are all
MJPEG-A, as the libv4l decoder uses tinyjpeg library to handle both
JPEG and MJPEG.

Maybe Hans de Goede knows more about that, and may have actually tested
it with different camera models.


I've tested the JPG path in libv4l with quite a lot of cameras and
sofar it has worked for all of them. There are some non UVC cameras where
the hardware produces raw JPG data, but in that case the kernel driver
prefixes a JPG header to each frame so that it looks like a regular JPG.

Regards,

Hans







On that thought, whilst capture devices generally don't care, is there
a need to differentiate for M2M codec devices which can support
encoding the variants? Or likewise on M2M decoders that support only
JPEG, how do they tell userspace that they don't support MJPEG-A or
MJPEG-B?

   Dave

[1] https://developer.apple.com/standards/qtff-2001.pdf


For instance, omiting the huffman table seems to be a vendor thing. Microsoft
explicitly omits the huffman tables from each frame:

https://www.fileformat.info/format/bmp/spec/b7c72ebab8064da48ae5ed0c053c67a4/view.htm

Others could be following the same things.

Like I mentioned before, Gstreamer always check for missing huffman table
and adds one if missing. Gstreamer has other quirks for missing markers,
e.g. deal with a missing EOI:

https://github.com/GStreamer/gst-plugins-good/commit/10ff3c8e14e8fba9e0a5d696dce0bea27de644d7

I think Hans suggestion of settling on JPEG makes sense and it would
be consistent with Gstreamer. Otherwise, we should specify exactly what we
understand by MJPEG, but I don't think it's worth it.

Thanks,
Ezequiel




Thanks,
Mauro

Re: [PATCH v2] libv4l: Add support for BAYER10P format conversion

[Hans de Goede]

Hi,

On 21-09-18 11:04, Ricardo Ribalda Delgado wrote:

Add support for 10 bit packet Bayer formats:
-V4L2_PIX_FMT_SBGGR10P
-V4L2_PIX_FMT_SGBRG10P
-V4L2_PIX_FMT_SGRBG10P
-V4L2_PIX_FMT_SRGGB10P

These formats pack the 2 LSBs for every 4 pixels in an indeppendent
byte.

Signed-off-by: Ricardo Ribalda Delgado 


Patch looks good to me now:

Acked-by: Hans de Goede 

Regards,

Hans




---
  lib/libv4lconvert/bayer.c  | 21 
  lib/libv4lconvert/libv4lconvert-priv.h |  4 +++
  lib/libv4lconvert/libv4lconvert.c  | 35 ++
  3 files changed, 60 insertions(+)

diff --git a/lib/libv4lconvert/bayer.c b/lib/libv4lconvert/bayer.c
index 4b70ddd9..11af6543 100644
--- a/lib/libv4lconvert/bayer.c
+++ b/lib/libv4lconvert/bayer.c
@@ -631,3 +631,24 @@ void v4lconvert_bayer_to_yuv420(const unsigned char 
*bayer, unsigned char *yuv,
v4lconvert_border_bayer_line_to_y(bayer + stride, bayer, ydst, width,
!start_with_green, !blue_line);
  }
+
+void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
+   unsigned char *bayer8, int width, int height)
+{
+   unsigned long i;
+   unsigned long len = width * height;
+
+   for (i = 0; i < len ; i += 4) {
+   /*
+* Do not use a second loop, hoping that
+* a clever compiler with understand the
+* pattern and will optimize it.
+*/
+   bayer8[0] = bayer10p[0];
+   bayer8[1] = bayer10p[1];
+   bayer8[2] = bayer10p[2];
+   bayer8[3] = bayer10p[3];
+   bayer10p += 5;
+   bayer8 += 4;
+   }
+}
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h 
b/lib/libv4lconvert/libv4lconvert-priv.h
index 9a467e10..3020a39e 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -264,6 +264,10 @@ void v4lconvert_bayer_to_bgr24(const unsigned char *bayer,
  void v4lconvert_bayer_to_yuv420(const unsigned char *bayer, unsigned char 
*yuv,
int width, int height, const unsigned int stride, unsigned int 
src_pixfmt, int yvu);
  
+

+void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
+   unsigned char *bayer8, int width, int height);
+
  void v4lconvert_hm12_to_rgb24(const unsigned char *src,
unsigned char *dst, int width, int height);
  
diff --git a/lib/libv4lconvert/libv4lconvert.c b/lib/libv4lconvert/libv4lconvert.c

index d666bd97..b3dbf5a0 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -133,6 +133,10 @@ static const struct v4lconvert_pixfmt 
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_SRGGB8,   8,  8,  8, 0 },
{ V4L2_PIX_FMT_STV0680,  8,  8,  8, 1 },
{ V4L2_PIX_FMT_SGRBG10, 16,  8,  8, 1 },
+   { V4L2_PIX_FMT_SBGGR10P,10,  8,  8, 1 },
+   { V4L2_PIX_FMT_SGBRG10P,10,  8,  8, 1 },
+   { V4L2_PIX_FMT_SGRBG10P,10,  8,  8, 1 },
+   { V4L2_PIX_FMT_SRGGB10P,10,  8,  8, 1 },
/* compressed bayer */
{ V4L2_PIX_FMT_SPCA561,  0,  9,  9, 1 },
{ V4L2_PIX_FMT_SN9C10X,  0,  9,  9, 1 },
@@ -687,6 +691,10 @@ static int v4lconvert_processing_needs_double_conversion(
case V4L2_PIX_FMT_SGBRG8:
case V4L2_PIX_FMT_SGRBG8:
case V4L2_PIX_FMT_SRGGB8:
+   case V4L2_PIX_FMT_SBGGR10P:
+   case V4L2_PIX_FMT_SGBRG10P:
+   case V4L2_PIX_FMT_SGRBG10P:
+   case V4L2_PIX_FMT_SRGGB10P:
case V4L2_PIX_FMT_STV0680:
return 0;
}
@@ -979,6 +987,33 @@ static int v4lconvert_convert_pixfmt(struct 
v4lconvert_data *data,
}
  
  		/* Raw bayer formats */

+   case V4L2_PIX_FMT_SBGGR10P:
+   case V4L2_PIX_FMT_SGBRG10P:
+   case V4L2_PIX_FMT_SGRBG10P:
+   case V4L2_PIX_FMT_SRGGB10P:
+   if (src_size < ((width * height * 10)/8)) {
+   V4LCONVERT_ERR("short raw bayer10 data frame\n");
+   errno = EPIPE;
+   result = -1;
+   }
+   switch (src_pix_fmt) {
+   case V4L2_PIX_FMT_SBGGR10P:
+   src_pix_fmt = V4L2_PIX_FMT_SBGGR8;
+   break;
+   case V4L2_PIX_FMT_SGBRG10P:
+   src_pix_fmt = V4L2_PIX_FMT_SGBRG8;
+   break;
+   case V4L2_PIX_FMT_SGRBG10P:
+   src_pix_fmt = V4L2_PIX_FMT_SGRBG8;
+   break;
+   case V4L2_PIX_FMT_SRGGB10P:
+   src_pix_fmt = V4L2_PIX_FMT_SRGGB8;
+   break;
+   }
+   v4lconvert_bayer10p_to_bayer8(src, src, width, height);
+   bytesperline = width;
+
+  

Re: [PATCH] libv4l: Add support for BAYER10P format conversion

[Hans de Goede]

Hi,

On 21-09-18 09:40, Ricardo Ribalda Delgado wrote:

Hi Hans

On Fri, Sep 21, 2018 at 9:38 AM Hans de Goede  wrote:


Hi,

On 20-09-18 22:04, Ricardo Ribalda Delgado wrote:

Add support for 10 bit packet Bayer formats:
-V4L2_PIX_FMT_SBGGR10P
-V4L2_PIX_FMT_SGBRG10P
-V4L2_PIX_FMT_SGRBG10P
-V4L2_PIX_FMT_SRGGB10P

These formats pack the 2 LSBs for every 4 pixels in an indeppendent
byte.

Signed-off-by: Ricardo Ribalda Delgado 
---
   lib/libv4lconvert/bayer.c  | 15 +++
   lib/libv4lconvert/libv4lconvert-priv.h |  4 +++
   lib/libv4lconvert/libv4lconvert.c  | 35 ++
   3 files changed, 54 insertions(+)

diff --git a/lib/libv4lconvert/bayer.c b/lib/libv4lconvert/bayer.c
index 4b70ddd9..d7d488f9 100644
--- a/lib/libv4lconvert/bayer.c
+++ b/lib/libv4lconvert/bayer.c
@@ -631,3 +631,18 @@ void v4lconvert_bayer_to_yuv420(const unsigned char 
*bayer, unsigned char *yuv,
   v4lconvert_border_bayer_line_to_y(bayer + stride, bayer, ydst, width,
   !start_with_green, !blue_line);
   }
+
+void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
+ unsigned char *bayer8, int width, int height)
+{
+ long i, len = width * height;
+ uint32_t *src, *dst;
+
+ src = (uint32_t *)bayer10p;
+ dst = (uint32_t *)bayer8;
+ for (i = 0; i < len ; i += 4) {
+ *dst = *src;
+ dst++;
+ src = (uint32_t *)(((uint8_t *)src) + 5);


This will lead to unaligned 32 bit integer accesses which will terminate
the program with an illegal instruction on pretty much all architectures
except for x86.


I see your point, but I am actually using this code on ARM64 with no issues.


That is weird, this is definitely illegal on armv7 perhaps the compiler
recognizes the problem and fixes it in the generated code?


I will change it.


Thanks.



You will need to copy the 4 components 1 by 1 so that you only
use byte accesses.

Also you seem to simply be throwing away the extra 2 bits, although
that will work I wonder if that is the best we can do?


Those are the LSB. If the user want the extra resolution has to use
the bayer mode.


Ok.

Regards,

Hans







Regards,

Hans




+ }
+}





diff --git a/lib/libv4lconvert/libv4lconvert-priv.h 
b/lib/libv4lconvert/libv4lconvert-priv.h
index 9a467e10..3020a39e 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -264,6 +264,10 @@ void v4lconvert_bayer_to_bgr24(const unsigned char *bayer,
   void v4lconvert_bayer_to_yuv420(const unsigned char *bayer, unsigned char 
*yuv,
   int width, int height, const unsigned int stride, unsigned int 
src_pixfmt, int yvu);

+
+void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
+ unsigned char *bayer8, int width, int height);
+
   void v4lconvert_hm12_to_rgb24(const unsigned char *src,
   unsigned char *dst, int width, int height);

diff --git a/lib/libv4lconvert/libv4lconvert.c 
b/lib/libv4lconvert/libv4lconvert.c
index d666bd97..b3dbf5a0 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -133,6 +133,10 @@ static const struct v4lconvert_pixfmt 
supported_src_pixfmts[] = {
   { V4L2_PIX_FMT_SRGGB8,   8,  8,  8, 0 },
   { V4L2_PIX_FMT_STV0680,  8,  8,  8, 1 },
   { V4L2_PIX_FMT_SGRBG10, 16,  8,  8, 1 },
+ { V4L2_PIX_FMT_SBGGR10P,10,  8,  8, 1 },
+ { V4L2_PIX_FMT_SGBRG10P,10,  8,  8, 1 },
+ { V4L2_PIX_FMT_SGRBG10P,10,  8,  8, 1 },
+ { V4L2_PIX_FMT_SRGGB10P,10,  8,  8, 1 },
   /* compressed bayer */
   { V4L2_PIX_FMT_SPCA561,  0,  9,  9, 1 },
   { V4L2_PIX_FMT_SN9C10X,  0,  9,  9, 1 },
@@ -687,6 +691,10 @@ static int v4lconvert_processing_needs_double_conversion(
   case V4L2_PIX_FMT_SGBRG8:
   case V4L2_PIX_FMT_SGRBG8:
   case V4L2_PIX_FMT_SRGGB8:
+ case V4L2_PIX_FMT_SBGGR10P:
+ case V4L2_PIX_FMT_SGBRG10P:
+ case V4L2_PIX_FMT_SGRBG10P:
+ case V4L2_PIX_FMT_SRGGB10P:
   case V4L2_PIX_FMT_STV0680:
   return 0;
   }
@@ -979,6 +987,33 @@ static int v4lconvert_convert_pixfmt(struct 
v4lconvert_data *data,
   }

   /* Raw bayer formats */
+ case V4L2_PIX_FMT_SBGGR10P:
+ case V4L2_PIX_FMT_SGBRG10P:
+ case V4L2_PIX_FMT_SGRBG10P:
+ case V4L2_PIX_FMT_SRGGB10P:
+ if (src_size < ((width * height * 10)/8)) {
+ V4LCONVERT_ERR("short raw bayer10 data frame\n");
+ errno = EPIPE;
+ result = -1;
+ }
+ switch (src_pix_fmt) {
+ case V4L2_PIX_FMT_SBGGR10P:
+ src_pix_fmt = V4L2_PIX_FMT_SBGGR8;
+ break;
+ case V4L2_PIX_FMT_SGBRG10P:
+

Re: [PATCH] libv4l: Add support for BAYER10P format conversion

[Hans de Goede]

Hi,

On 20-09-18 22:04, Ricardo Ribalda Delgado wrote:

Add support for 10 bit packet Bayer formats:
-V4L2_PIX_FMT_SBGGR10P
-V4L2_PIX_FMT_SGBRG10P
-V4L2_PIX_FMT_SGRBG10P
-V4L2_PIX_FMT_SRGGB10P

These formats pack the 2 LSBs for every 4 pixels in an indeppendent
byte.

Signed-off-by: Ricardo Ribalda Delgado 
---
  lib/libv4lconvert/bayer.c  | 15 +++
  lib/libv4lconvert/libv4lconvert-priv.h |  4 +++
  lib/libv4lconvert/libv4lconvert.c  | 35 ++
  3 files changed, 54 insertions(+)

diff --git a/lib/libv4lconvert/bayer.c b/lib/libv4lconvert/bayer.c
index 4b70ddd9..d7d488f9 100644
--- a/lib/libv4lconvert/bayer.c
+++ b/lib/libv4lconvert/bayer.c
@@ -631,3 +631,18 @@ void v4lconvert_bayer_to_yuv420(const unsigned char 
*bayer, unsigned char *yuv,
v4lconvert_border_bayer_line_to_y(bayer + stride, bayer, ydst, width,
!start_with_green, !blue_line);
  }
+
+void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
+   unsigned char *bayer8, int width, int height)
+{
+   long i, len = width * height;
+   uint32_t *src, *dst;
+
+   src = (uint32_t *)bayer10p;
+   dst = (uint32_t *)bayer8;
+   for (i = 0; i < len ; i += 4) {
+   *dst = *src;
+   dst++;
+   src = (uint32_t *)(((uint8_t *)src) + 5);


This will lead to unaligned 32 bit integer accesses which will terminate
the program with an illegal instruction on pretty much all architectures
except for x86.

You will need to copy the 4 components 1 by 1 so that you only
use byte accesses.

Also you seem to simply be throwing away the extra 2 bits, although
that will work I wonder if that is the best we can do?

Regards,

Hans




+   }
+}





diff --git a/lib/libv4lconvert/libv4lconvert-priv.h 
b/lib/libv4lconvert/libv4lconvert-priv.h
index 9a467e10..3020a39e 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -264,6 +264,10 @@ void v4lconvert_bayer_to_bgr24(const unsigned char *bayer,
  void v4lconvert_bayer_to_yuv420(const unsigned char *bayer, unsigned char 
*yuv,
int width, int height, const unsigned int stride, unsigned int 
src_pixfmt, int yvu);
  
+

+void v4lconvert_bayer10p_to_bayer8(unsigned char *bayer10p,
+   unsigned char *bayer8, int width, int height);
+
  void v4lconvert_hm12_to_rgb24(const unsigned char *src,
unsigned char *dst, int width, int height);
  
diff --git a/lib/libv4lconvert/libv4lconvert.c b/lib/libv4lconvert/libv4lconvert.c

index d666bd97..b3dbf5a0 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -133,6 +133,10 @@ static const struct v4lconvert_pixfmt 
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_SRGGB8,   8,  8,  8, 0 },
{ V4L2_PIX_FMT_STV0680,  8,  8,  8, 1 },
{ V4L2_PIX_FMT_SGRBG10, 16,  8,  8, 1 },
+   { V4L2_PIX_FMT_SBGGR10P,10,  8,  8, 1 },
+   { V4L2_PIX_FMT_SGBRG10P,10,  8,  8, 1 },
+   { V4L2_PIX_FMT_SGRBG10P,10,  8,  8, 1 },
+   { V4L2_PIX_FMT_SRGGB10P,10,  8,  8, 1 },
/* compressed bayer */
{ V4L2_PIX_FMT_SPCA561,  0,  9,  9, 1 },
{ V4L2_PIX_FMT_SN9C10X,  0,  9,  9, 1 },
@@ -687,6 +691,10 @@ static int v4lconvert_processing_needs_double_conversion(
case V4L2_PIX_FMT_SGBRG8:
case V4L2_PIX_FMT_SGRBG8:
case V4L2_PIX_FMT_SRGGB8:
+   case V4L2_PIX_FMT_SBGGR10P:
+   case V4L2_PIX_FMT_SGBRG10P:
+   case V4L2_PIX_FMT_SGRBG10P:
+   case V4L2_PIX_FMT_SRGGB10P:
case V4L2_PIX_FMT_STV0680:
return 0;
}
@@ -979,6 +987,33 @@ static int v4lconvert_convert_pixfmt(struct 
v4lconvert_data *data,
}
  
  		/* Raw bayer formats */

+   case V4L2_PIX_FMT_SBGGR10P:
+   case V4L2_PIX_FMT_SGBRG10P:
+   case V4L2_PIX_FMT_SGRBG10P:
+   case V4L2_PIX_FMT_SRGGB10P:
+   if (src_size < ((width * height * 10)/8)) {
+   V4LCONVERT_ERR("short raw bayer10 data frame\n");
+   errno = EPIPE;
+   result = -1;
+   }
+   switch (src_pix_fmt) {
+   case V4L2_PIX_FMT_SBGGR10P:
+   src_pix_fmt = V4L2_PIX_FMT_SBGGR8;
+   break;
+   case V4L2_PIX_FMT_SGBRG10P:
+   src_pix_fmt = V4L2_PIX_FMT_SGBRG8;
+   break;
+   case V4L2_PIX_FMT_SGRBG10P:
+   src_pix_fmt = V4L2_PIX_FMT_SGRBG8;
+   break;
+   case V4L2_PIX_FMT_SRGGB10P:
+   src_pix_fmt = V4L2_PIX_FMT_SRGGB8;
+   break;
+   }
+   v4lconvert_bayer10p_to_bayer8(src, src, width, height);
+   

Re: Devices with a front and back webcam represented as a single UVC device

[Hans de Goede]

Hi,

On 18-07-18 13:53, Carlos Garnacho wrote:

Hey,

On Wed, Jul 11, 2018 at 9:51 PM, Hans de Goede  wrote:

Hi,


On 11-07-18 20:26, Carlos Garnacho wrote:


Hi!,

On Wed, Jul 11, 2018 at 7:41 PM, Hans de Goede 
wrote:


Hi,


On 11-07-18 18:07, Carlos Garnacho wrote:



Hi!,

On Wed, Jul 11, 2018 at 2:41 PM, Hans de Goede 
wrote:



HI,


On 11-07-18 14:08, Laurent Pinchart wrote:




Hi Carlos,

On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:




On Wed, Jul 11, 2018 at 1:00 PM, Laurent Pinchart wrote:




On Wednesday, 11 July 2018 11:37:14 EEST Hans de Goede wrote:




Hi Laurent,

At Guadec Carlos (in the Cc) told me that on his Acer 2-in-1 only
the frontcam is working and it seems both are represented by a
single UVC USB device. I've told him to check for some v4l control
to flip between front and back.

Carlos, as I mentioned you can try gtk-v4l
("sudo dnf install gtk-v4l") or qv4l2
("sudo dnf install qv4l2") these will both show
you various controls for the camera. One of those might do the
trick.

But I recently bought a 2nd second hand Cherry Trail based HP
X2 2-in-1 and much to my surprise that is actually using an UVC
cam, rather then the usual ATOMISP crap and it has the same issue.

This device does not seem to have a control to flip between the
2 cams, instead it registers 2 /dev/video? nodes but the second
node does not work





The second node is there to expose metadata to userspace, not image
data.
That's a recent addition to the uvcvideo driver.


and dmesg contains:

[   26.079868] uvcvideo: Found UVC 1.00 device HP TrueVision HD
(05c8:03a3)
[   26.095485] uvcvideo 1-4.2:1.0: Entity type for entity Extension
4
was
not initialized!
[   26.095492] uvcvideo 1-4.2:1.0: Entity type for entity
Processing
2
was
not initialized!
[   26.095496] uvcvideo 1-4.2:1.0: Entity type for entity Camera 1
was
not
initialized!





You can safely ignore those messages. I need to submit a patch to
get
rid
of them.


Laurent, I've attached lsusb -v output so that you can check the
descriptors.





Thank you.

It's funny how UVC specifies a standard way to describe a device
with
two
camera sensors with dynamic selection of one of them at runtime, and
vendors instead implement vendor-specific crap :-(

The interesting part in the descriptors is

  VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype  6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0)  2
bControlSize2
bmControls( 0)   0x00
bmControls( 1)   0x06
iExtension  0

The extension unit exposes two controls (bmControls is a bitmask).
They
can be accessed from userspace through the UVCIOC_CTRL_QUERY ioctl,
or
mapped to V4L2 controls through the UVCIOC_CTRL_MAP ioctl, in which
case
they will be exposed to standard V4L2 applications.

If you want to experiment with this, I would advise querying both
controls
with UVCIOC_CTRL_QUERY. You can use the UVC_GET_CUR, UVC_GET_MIN,
UVC_GET_MAX, UVC_GET_DEF and UVC_GET_RES requests to get the control
current, minimum, maximum, default and resolution values, and
UVC_GET_LEN
and UVC_GET_INFO to get the control size (in bytes) and flags. Based
on
that you can start experimenting with UVC_SET_CUR to set semi-random
values.

I'm however worried that those two controls would be a register
address
and a register value, for indirect access to all hardware registers
in
the device. In that case, you would likely need information from the
device vendor, or possibly a USB traffic dump from a Windows machine
when
switching between the front and back cameras.


Carlos, it might be good to get Laurent your descriptors too, to do
this do "lsusb", note what is the : for your camera and
then
run:

sudo lsusb -v -d :  > lsusb.log

And send Laurent a mail with the generated lsusb





That would be appreciated, but I expect the same issue :-(





Please find it attached. IIUC your last email, it might not be the
exact same issue, but you can definitely judge better.





Your device is similar in the sense that it doesn't use the standard
UVC
support for multiple camera sensors. It instead exposes two extension
units:

  VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype  6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0)  2
bControlSize2
bmControls( 0)   0x00
bmControls( 1) 

Re: Devices with a front and back webcam represented as a single UVC device

[Hans de Goede]

Hi,

On 11-07-18 20:26, Carlos Garnacho wrote:

Hi!,

On Wed, Jul 11, 2018 at 7:41 PM, Hans de Goede  wrote:

Hi,


On 11-07-18 18:07, Carlos Garnacho wrote:


Hi!,

On Wed, Jul 11, 2018 at 2:41 PM, Hans de Goede 
wrote:


HI,


On 11-07-18 14:08, Laurent Pinchart wrote:



Hi Carlos,

On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:



On Wed, Jul 11, 2018 at 1:00 PM, Laurent Pinchart wrote:



On Wednesday, 11 July 2018 11:37:14 EEST Hans de Goede wrote:



Hi Laurent,

At Guadec Carlos (in the Cc) told me that on his Acer 2-in-1 only
the frontcam is working and it seems both are represented by a
single UVC USB device. I've told him to check for some v4l control
to flip between front and back.

Carlos, as I mentioned you can try gtk-v4l
("sudo dnf install gtk-v4l") or qv4l2
("sudo dnf install qv4l2") these will both show
you various controls for the camera. One of those might do the trick.

But I recently bought a 2nd second hand Cherry Trail based HP
X2 2-in-1 and much to my surprise that is actually using an UVC
cam, rather then the usual ATOMISP crap and it has the same issue.

This device does not seem to have a control to flip between the
2 cams, instead it registers 2 /dev/video? nodes but the second
node does not work




The second node is there to expose metadata to userspace, not image
data.
That's a recent addition to the uvcvideo driver.


and dmesg contains:

[   26.079868] uvcvideo: Found UVC 1.00 device HP TrueVision HD
(05c8:03a3)
[   26.095485] uvcvideo 1-4.2:1.0: Entity type for entity Extension 4
was
not initialized!
[   26.095492] uvcvideo 1-4.2:1.0: Entity type for entity Processing
2
was
not initialized!
[   26.095496] uvcvideo 1-4.2:1.0: Entity type for entity Camera 1
was
not
initialized!




You can safely ignore those messages. I need to submit a patch to get
rid
of them.


Laurent, I've attached lsusb -v output so that you can check the
descriptors.




Thank you.

It's funny how UVC specifies a standard way to describe a device with
two
camera sensors with dynamic selection of one of them at runtime, and
vendors instead implement vendor-specific crap :-(

The interesting part in the descriptors is

 VideoControl Interface Descriptor:
   bLength27
   bDescriptorType36
   bDescriptorSubtype  6 (EXTENSION_UNIT)
   bUnitID 4
   guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
   bNumControl 2
   bNrPins 1
   baSourceID( 0)  2
   bControlSize2
   bmControls( 0)   0x00
   bmControls( 1)   0x06
   iExtension  0

The extension unit exposes two controls (bmControls is a bitmask).
They
can be accessed from userspace through the UVCIOC_CTRL_QUERY ioctl, or
mapped to V4L2 controls through the UVCIOC_CTRL_MAP ioctl, in which
case
they will be exposed to standard V4L2 applications.

If you want to experiment with this, I would advise querying both
controls
with UVCIOC_CTRL_QUERY. You can use the UVC_GET_CUR, UVC_GET_MIN,
UVC_GET_MAX, UVC_GET_DEF and UVC_GET_RES requests to get the control
current, minimum, maximum, default and resolution values, and
UVC_GET_LEN
and UVC_GET_INFO to get the control size (in bytes) and flags. Based
on
that you can start experimenting with UVC_SET_CUR to set semi-random
values.

I'm however worried that those two controls would be a register
address
and a register value, for indirect access to all hardware registers in
the device. In that case, you would likely need information from the
device vendor, or possibly a USB traffic dump from a Windows machine
when
switching between the front and back cameras.


Carlos, it might be good to get Laurent your descriptors too, to do
this do "lsusb", note what is the : for your camera and
then
run:

sudo lsusb -v -d :  > lsusb.log

And send Laurent a mail with the generated lsusb




That would be appreciated, but I expect the same issue :-(




Please find it attached. IIUC your last email, it might not be the
exact same issue, but you can definitely judge better.




Your device is similar in the sense that it doesn't use the standard UVC
support for multiple camera sensors. It instead exposes two extension
units:

 VideoControl Interface Descriptor:
   bLength27
   bDescriptorType36
   bDescriptorSubtype  6 (EXTENSION_UNIT)
   bUnitID 4
   guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
   bNumControl 2
   bNrPins 1
   baSourceID( 0)  2
   bControlSize2
   bmControls( 0)   0x00
   bmControls( 1)   0x06
   iExtension  0
 VideoControl Interface Descriptor:
   bLength29
   

Re: Devices with a front and back webcam represented as a single UVC device

[Hans de Goede]

Hi,

On 11-07-18 18:07, Carlos Garnacho wrote:

Hi!,

On Wed, Jul 11, 2018 at 2:41 PM, Hans de Goede  wrote:

HI,


On 11-07-18 14:08, Laurent Pinchart wrote:


Hi Carlos,

On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:


On Wed, Jul 11, 2018 at 1:00 PM, Laurent Pinchart wrote:


On Wednesday, 11 July 2018 11:37:14 EEST Hans de Goede wrote:


Hi Laurent,

At Guadec Carlos (in the Cc) told me that on his Acer 2-in-1 only
the frontcam is working and it seems both are represented by a
single UVC USB device. I've told him to check for some v4l control
to flip between front and back.

Carlos, as I mentioned you can try gtk-v4l
("sudo dnf install gtk-v4l") or qv4l2
("sudo dnf install qv4l2") these will both show
you various controls for the camera. One of those might do the trick.

But I recently bought a 2nd second hand Cherry Trail based HP
X2 2-in-1 and much to my surprise that is actually using an UVC
cam, rather then the usual ATOMISP crap and it has the same issue.

This device does not seem to have a control to flip between the
2 cams, instead it registers 2 /dev/video? nodes but the second
node does not work



The second node is there to expose metadata to userspace, not image
data.
That's a recent addition to the uvcvideo driver.


and dmesg contains:

[   26.079868] uvcvideo: Found UVC 1.00 device HP TrueVision HD
(05c8:03a3)
[   26.095485] uvcvideo 1-4.2:1.0: Entity type for entity Extension 4
was
not initialized!
[   26.095492] uvcvideo 1-4.2:1.0: Entity type for entity Processing 2
was
not initialized!
[   26.095496] uvcvideo 1-4.2:1.0: Entity type for entity Camera 1 was
not
initialized!



You can safely ignore those messages. I need to submit a patch to get
rid
of them.


Laurent, I've attached lsusb -v output so that you can check the
descriptors.



Thank you.

It's funny how UVC specifies a standard way to describe a device with
two
camera sensors with dynamic selection of one of them at runtime, and
vendors instead implement vendor-specific crap :-(

The interesting part in the descriptors is

VideoControl Interface Descriptor:
  bLength27
  bDescriptorType36
  bDescriptorSubtype  6 (EXTENSION_UNIT)
  bUnitID 4
  guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
  bNumControl 2
  bNrPins 1
  baSourceID( 0)  2
  bControlSize2
  bmControls( 0)   0x00
  bmControls( 1)   0x06
  iExtension  0

The extension unit exposes two controls (bmControls is a bitmask). They
can be accessed from userspace through the UVCIOC_CTRL_QUERY ioctl, or
mapped to V4L2 controls through the UVCIOC_CTRL_MAP ioctl, in which case
they will be exposed to standard V4L2 applications.

If you want to experiment with this, I would advise querying both
controls
with UVCIOC_CTRL_QUERY. You can use the UVC_GET_CUR, UVC_GET_MIN,
UVC_GET_MAX, UVC_GET_DEF and UVC_GET_RES requests to get the control
current, minimum, maximum, default and resolution values, and
UVC_GET_LEN
and UVC_GET_INFO to get the control size (in bytes) and flags. Based on
that you can start experimenting with UVC_SET_CUR to set semi-random
values.

I'm however worried that those two controls would be a register address
and a register value, for indirect access to all hardware registers in
the device. In that case, you would likely need information from the
device vendor, or possibly a USB traffic dump from a Windows machine
when
switching between the front and back cameras.


Carlos, it might be good to get Laurent your descriptors too, to do
this do "lsusb", note what is the : for your camera and then
run:

sudo lsusb -v -d :  > lsusb.log

And send Laurent a mail with the generated lsusb



That would be appreciated, but I expect the same issue :-(



Please find it attached. IIUC your last email, it might not be the
exact same issue, but you can definitely judge better.



Your device is similar in the sense that it doesn't use the standard UVC
support for multiple camera sensors. It instead exposes two extension
units:

VideoControl Interface Descriptor:
  bLength27
  bDescriptorType36
  bDescriptorSubtype  6 (EXTENSION_UNIT)
  bUnitID 4
  guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
  bNumControl 2
  bNrPins 1
  baSourceID( 0)  2
  bControlSize2
  bmControls( 0)   0x00
  bmControls( 1)   0x06
  iExtension  0
VideoControl Interface Descriptor:
  bLength29
  bDescriptorType36
  bDescriptorSubtype  6 (EXTENSION_UNIT)
  bUnitID 6
  guidExtensionCode {26b

Re: Devices with a front and back webcam represented as a single UVC device

[Hans de Goede]

HI,

On 11-07-18 14:08, Laurent Pinchart wrote:

Hi Carlos,

On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:

On Wed, Jul 11, 2018 at 1:00 PM, Laurent Pinchart wrote:

On Wednesday, 11 July 2018 11:37:14 EEST Hans de Goede wrote:

Hi Laurent,

At Guadec Carlos (in the Cc) told me that on his Acer 2-in-1 only
the frontcam is working and it seems both are represented by a
single UVC USB device. I've told him to check for some v4l control
to flip between front and back.

Carlos, as I mentioned you can try gtk-v4l
("sudo dnf install gtk-v4l") or qv4l2
("sudo dnf install qv4l2") these will both show
you various controls for the camera. One of those might do the trick.

But I recently bought a 2nd second hand Cherry Trail based HP
X2 2-in-1 and much to my surprise that is actually using an UVC
cam, rather then the usual ATOMISP crap and it has the same issue.

This device does not seem to have a control to flip between the
2 cams, instead it registers 2 /dev/video? nodes but the second
node does not work


The second node is there to expose metadata to userspace, not image data.
That's a recent addition to the uvcvideo driver.


and dmesg contains:

[   26.079868] uvcvideo: Found UVC 1.00 device HP TrueVision HD
(05c8:03a3)
[   26.095485] uvcvideo 1-4.2:1.0: Entity type for entity Extension 4 was
not initialized!
[   26.095492] uvcvideo 1-4.2:1.0: Entity type for entity Processing 2
was
not initialized!
[   26.095496] uvcvideo 1-4.2:1.0: Entity type for entity Camera 1 was
not
initialized!


You can safely ignore those messages. I need to submit a patch to get rid
of them.


Laurent, I've attached lsusb -v output so that you can check the
descriptors.


Thank you.

It's funny how UVC specifies a standard way to describe a device with two
camera sensors with dynamic selection of one of them at runtime, and
vendors instead implement vendor-specific crap :-(

The interesting part in the descriptors is

   VideoControl Interface Descriptor:
 bLength27
 bDescriptorType36
 bDescriptorSubtype  6 (EXTENSION_UNIT)
 bUnitID 4
 guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
 bNumControl 2
 bNrPins 1
 baSourceID( 0)  2
 bControlSize2
 bmControls( 0)   0x00
 bmControls( 1)   0x06
 iExtension  0

The extension unit exposes two controls (bmControls is a bitmask). They
can be accessed from userspace through the UVCIOC_CTRL_QUERY ioctl, or
mapped to V4L2 controls through the UVCIOC_CTRL_MAP ioctl, in which case
they will be exposed to standard V4L2 applications.

If you want to experiment with this, I would advise querying both controls
with UVCIOC_CTRL_QUERY. You can use the UVC_GET_CUR, UVC_GET_MIN,
UVC_GET_MAX, UVC_GET_DEF and UVC_GET_RES requests to get the control
current, minimum, maximum, default and resolution values, and UVC_GET_LEN
and UVC_GET_INFO to get the control size (in bytes) and flags. Based on
that you can start experimenting with UVC_SET_CUR to set semi-random
values.

I'm however worried that those two controls would be a register address
and a register value, for indirect access to all hardware registers in
the device. In that case, you would likely need information from the
device vendor, or possibly a USB traffic dump from a Windows machine when
switching between the front and back cameras.


Carlos, it might be good to get Laurent your descriptors too, to do
this do "lsusb", note what is the : for your camera and then
run:

sudo lsusb -v -d :  > lsusb.log

And send Laurent a mail with the generated lsusb


That would be appreciated, but I expect the same issue :-(


Please find it attached. IIUC your last email, it might not be the
exact same issue, but you can definitely judge better.


Your device is similar in the sense that it doesn't use the standard UVC
support for multiple camera sensors. It instead exposes two extension units:

   VideoControl Interface Descriptor:
 bLength27
 bDescriptorType36
 bDescriptorSubtype  6 (EXTENSION_UNIT)
 bUnitID 4
 guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
 bNumControl 2
 bNrPins 1
 baSourceID( 0)  2
 bControlSize2
 bmControls( 0)   0x00
 bmControls( 1)   0x06
 iExtension  0
   VideoControl Interface Descriptor:
 bLength29
 bDescriptorType36
 bDescriptorSubtype  6 (EXTENSION_UNIT)
 bUnitID 6
 guidExtensionCode {26b8105a-0713-4870-979d-da79444bb68e}
 bNumControl 9
 bNrPins 1
 baSourceID( 0)  4
 

Devices with a front and back webcam represented as a single UVC device

[Hans de Goede]

Hi Laurent,

At Guadec Carlos (in the Cc) told me that on his Acer 2-in-1 only
the frontcam is working and it seems both are represented by a
single UVC USB device. I've told him to check for some v4l control
to flip between front and back.

Carlos, as I mentioned you can try gtk-v4l
("sudo dnf install gtk-v4l") or qv4l2
("sudo dnf install qv4l2") these will both show
you various controls for the camera. One of those might do the trick.

But I recently bought a 2nd second hand Cherry Trail based HP
X2 2-in-1 and much to my surprise that is actually using an UVC
cam, rather then the usual ATOMISP crap and it has the same issue.

This device does not seem to have a control to flip between the
2 cams, instead it registers 2 /dev/video? nodes but the second
node does not work and dmesg contains:

[   26.079868] uvcvideo: Found UVC 1.00 device HP TrueVision HD (05c8:03a3)
[   26.095485] uvcvideo 1-4.2:1.0: Entity type for entity Extension 4 was not 
initialized!
[   26.095492] uvcvideo 1-4.2:1.0: Entity type for entity Processing 2 was not 
initialized!
[   26.095496] uvcvideo 1-4.2:1.0: Entity type for entity Camera 1 was not 
initialized!

Laurent, I've attached lsusb -v output so that you can check the
descriptors.

Carlos, it might be good to get Laurent your descriptors too, to do
this do "lsusb", note what is the : for your camera and then
run:

sudo lsusb -v -d :  > lsusb.log

And send Laurent a mail with the generated lsusb

Regards,

Hans

Bus 001 Device 005: ID 05c8:03a3 Cheng Uei Precision Industry Co., Ltd (Foxlink) 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x05c8 Cheng Uei Precision Industry Co., Ltd (Foxlink)
  idProduct  0x03a3 
  bcdDevice1.01
  iManufacturer   3 Generic
  iProduct1 HP TrueVision HD
  iSerial 2 200901010001
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  722
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  4 USB Camera
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface 0
  bInterfaceCount 2
  bFunctionClass 14 Video
  bFunctionSubClass   3 Video Interface Collection
  bFunctionProtocol   0 
  iFunction   5 HP TrueVision HD
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass14 Video
  bInterfaceSubClass  1 Video Control
  bInterfaceProtocol  0 
  iInterface  5 HP TrueVision HD
  VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype  1 (HEADER)
bcdUVC   1.00
wTotalLength   78
dwClockFrequency   15.00MHz
bInCollection   1
baInterfaceNr( 0)   1
  VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype  2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType  0x0201 Camera Sensor
bAssocTerminal  0
iTerminal   0 
wObjectiveFocalLengthMin  0
wObjectiveFocalLengthMax  0
wOcularFocalLength0
bControlSize  3
bmControls   0x000e
  Auto-Exposure Mode
  Auto-Exposure Priority
  Exposure Time (Absolute)
  VideoControl Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype  5 (PROCESSING_UNIT)
  Warning: Descriptor too short
bUnitID 2
bSourceID   1
wMaxMultiplier  0
bControlSize2
bmControls 0x177f
  Brightness
  Contrast
  Hue
  Saturation
  Sharpness
  Gamma
  White Balance Temperature
  Backlight Compensation
  Gain
  Power Line Frequency
  White Balance Temperature, Auto
iProcessing 0 
bmVideoStandards 0x09
  None
  SECAM - 625/50
  VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType  0x0101 USB 

Re: [PATCH] [media] gspca: Stop using GFP_DMA for buffers for USB bulk transfers

[Hans de Goede]

Hi,

On 05/13/2018 07:54 PM, Adam Baker wrote:

On 05/05/18 09:22, Hans de Goede wrote:

The recent "x86 ZONE_DMA love" discussion at LSF/MM pointed out that some
gspca sub-drivvers are using GFP_DMA to allocate buffers which are used
for USB bulk transfers, there is absolutely no need for this, drop it.



The documentation for kmalloc() says
   GFP_DMA - Allocation suitable for DMA.

end at least in sq905.c the allocation is passed to the USB stack that
then uses it for DMA.

Looking a bit closer the "suitable for DMA" label that GFP_DMA promises
is not really a sensible thing for kmalloc() to determine as it is
dependent on the DMA controller in question. The USB stack now ensures
that everything works correctly as long as the memory is allocated with
kmalloc() so acked by me for sq905.c but, is anyone taking care of
fixing the kmalloc() documentation?


The whole GFP_DMA flag use in the kernel is a mess and fixing the
doucmentation is not easy and likely also not the solution, see:

https://lwn.net/Articles/753273/

Note this article is currently only available to LWN subscribers
(it will become freely available in a week).

I'll send you a private mail with a link which will allow you
to read it.

Regards,

Hans

Re: [PATCH 1/4] gspca: convert to vb2

[Hans de Goede]

Hi,

On 05/13/2018 11:32 AM, Hans Verkuil wrote:

On 05/12/2018 08:00 PM, Hans de Goede wrote:

Hi Hans,

Overall looks good, 1 comment inline.


-   if (ret == 0 && gspca_dev->sd_desc->dq_callback) {
-   mutex_lock(_dev->usb_lock);
-   gspca_dev->usb_err = 0;
-   if (gspca_dev->present)
-   gspca_dev->sd_desc->dq_callback(gspca_dev);
-   mutex_unlock(_dev->usb_lock);
-   }
+   if (!gspca_dev->sd_desc->dq_callback)
+   return;
   
-	return ret;

+   gspca_dev->usb_err = 0;
+   gspca_dev->sd_desc->dq_callback(gspca_dev);
   }



You are loosing the "if (gspca_dev->present)" check around
the dq_callback here, this may causes issues if the
buffer_finish method gets called after the device has
been unplugged.


Good catch, I've added the 'if' here.


Ok, with that change you may add my rev-by to the entire
series.

Regards,

Hans






If the vb2 code takes care that the buffer_finish method
doesn't get called then you may add my:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

To this patch.

Patch 2-4 look good to and you may add my:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

To those too.


Thanks!



Regards,

Hans


p.s.

If the v4l2-ctl + vb2 frameworks take care of not having
any driver callbacks called after disconnect, perhaps
the present flag can be removed?


I actually tried that (using the video_is_registered() function
instead), but it is used all over in gspca subdrivers, and I didn't
want to change them all. It's easier to just keep the field.

The same is true for the streaming field, for that matter. It could
be replaced by a vb2 function, but it would require lots of changes
in gspca subdrivers as well.

Regards,

Hans






-/*
- * queue a video buffer
- *
- * Attempting to queue a buffer that has already been
- * queued will return -EINVAL.
- */
-static int vidioc_qbuf(struct file *file, void *priv,
-   struct v4l2_buffer *v4l2_buf)
+static void gspca_buffer_queue(struct vb2_buffer *vb)
   {
-   struct gspca_dev *gspca_dev = video_drvdata(file);
-   struct gspca_frame *frame;
-   int i, index, ret;
-
-   gspca_dbg(gspca_dev, D_FRAM, "qbuf %d\n", v4l2_buf->index);
-
-   if (mutex_lock_interruptible(_dev->queue_lock))
-   return -ERESTARTSYS;
-
-   index = v4l2_buf->index;
-   if ((unsigned) index >= gspca_dev->nframes) {
-   gspca_dbg(gspca_dev, D_FRAM,
- "qbuf idx %d >= %d\n", index, gspca_dev->nframes);
-   ret = -EINVAL;
-   goto out;
-   }
-   if (v4l2_buf->memory != gspca_dev->memory) {
-   gspca_dbg(gspca_dev, D_FRAM, "qbuf bad memory type\n");
-   ret = -EINVAL;
-   goto out;
-   }
-
-   frame = _dev->frame[index];
-   if (frame->v4l2_buf.flags & BUF_ALL_FLAGS) {
-   gspca_dbg(gspca_dev, D_FRAM, "qbuf bad state\n");
-   ret = -EINVAL;
-   goto out;
-   }
-
-   frame->v4l2_buf.flags |= V4L2_BUF_FLAG_QUEUED;
-
-   if (frame->v4l2_buf.memory == V4L2_MEMORY_USERPTR) {
-   frame->v4l2_buf.m.userptr = v4l2_buf->m.userptr;
-   frame->v4l2_buf.length = v4l2_buf->length;
-   }
-
-   /* put the buffer in the 'queued' queue */
-   i = atomic_read(_dev->fr_q);
-   gspca_dev->fr_queue[i] = index;
-   atomic_set(_dev->fr_q, (i + 1) % GSPCA_MAX_FRAMES);
+   struct gspca_dev *gspca_dev = vb2_get_drv_priv(vb->vb2_queue);
+   struct gspca_buffer *buf = to_gspca_buffer(vb);
+   unsigned long flags;
   
-	v4l2_buf->flags |= V4L2_BUF_FLAG_QUEUED;

-   v4l2_buf->flags &= ~V4L2_BUF_FLAG_DONE;
-   ret = 0;
-out:
-   mutex_unlock(_dev->queue_lock);
-   return ret;
+   spin_lock_irqsave(_dev->qlock, flags);
+   list_add_tail(>list, _dev->buf_list);
+   spin_unlock_irqrestore(_dev->qlock, flags);
   }
   
-/*

- * allocate the resources for read()
- */
-static int read_alloc(struct gspca_dev *gspca_dev,
-   struct file *file)
+static void gspca_return_all_buffers(struct gspca_dev *gspca_dev,
+enum vb2_buffer_state state)
   {
-   struct v4l2_buffer v4l2_buf;
-   int i, ret;
-
-   gspca_dbg(gspca_dev, D_STREAM, "read alloc\n");
+   struct gspca_buffer *buf, *node;
+   unsigned long flags;
   
-	if (mutex_lock_interruptible(_dev->usb_lock))

-   return -ERESTARTSYS;
-
-   if (gspca_dev->nframes == 0) {
-   struct v4l2_requestbuffers rb;
-
-   memset(, 0, sizeof rb);
-   rb.count = gspca_dev->nbufread;
-   rb.type = V4L2_BUF_TYPE_VIDE

Re: [PATCH 1/4] gspca: convert to vb2

[Hans de Goede]

int gspca_buffer_prepare(struct vb2_buffer *vb)
  {
-   int ret;
+   struct gspca_dev *gspca_dev = vb2_get_drv_priv(vb->vb2_queue);
+   unsigned long size = gspca_dev->pixfmt.sizeimage;
  
-	if (mutex_lock_interruptible(_dev->queue_lock))

-   return -ERESTARTSYS;
-   ret = frame_ready_nolock(gspca_dev, file, memory);
-   mutex_unlock(_dev->queue_lock);
-   return ret;
+   if (vb2_plane_size(vb, 0) < size) {
+   gspca_err(gspca_dev, "buffer too small (%lu < %lu)\n",
+vb2_plane_size(vb, 0), size);
+   return -EINVAL;
+   }
+   return 0;
  }
  
-/*

- * dequeue a video buffer
- *
- * If nonblock_ing is false, block until a buffer is available.
- */
-static int vidioc_dqbuf(struct file *file, void *priv,
-   struct v4l2_buffer *v4l2_buf)
+static void gspca_buffer_finish(struct vb2_buffer *vb)
  {
-   struct gspca_dev *gspca_dev = video_drvdata(file);
-   struct gspca_frame *frame;
-   int i, j, ret;
-
-   gspca_dbg(gspca_dev, D_FRAM, "dqbuf\n");
-
-   if (mutex_lock_interruptible(_dev->queue_lock))
-   return -ERESTARTSYS;
-
-   for (;;) {
-   ret = frame_ready_nolock(gspca_dev, file, v4l2_buf->memory);
-   if (ret < 0)
-   goto out;
-   if (ret > 0)
-   break;
-
-   mutex_unlock(_dev->queue_lock);
-
-   if (file->f_flags & O_NONBLOCK)
-   return -EAGAIN;
-
-   /* wait till a frame is ready */
-   ret = wait_event_interruptible_timeout(gspca_dev->wq,
-   frame_ready(gspca_dev, file, v4l2_buf->memory),
-   msecs_to_jiffies(3000));
-   if (ret < 0)
-   return ret;
-   if (ret == 0)
-   return -EIO;
-
-   if (mutex_lock_interruptible(_dev->queue_lock))
-   return -ERESTARTSYS;
-   }
+   struct gspca_dev *gspca_dev = vb2_get_drv_priv(vb->vb2_queue);
  
-	i = gspca_dev->fr_o;

-   j = gspca_dev->fr_queue[i];
-   frame = _dev->frame[j];
-
-   gspca_dev->fr_o = (i + 1) % GSPCA_MAX_FRAMES;
-
-   frame->v4l2_buf.flags &= ~V4L2_BUF_FLAG_DONE;
-   memcpy(v4l2_buf, >v4l2_buf, sizeof *v4l2_buf);
-   gspca_dbg(gspca_dev, D_FRAM, "dqbuf %d\n", j);
-   ret = 0;
-
-   if (gspca_dev->memory == V4L2_MEMORY_USERPTR) {
-       if (copy_to_user((__u8 __user *) frame->v4l2_buf.m.userptr,
-frame->data,
-    frame->v4l2_buf.bytesused)) {
-   gspca_err(gspca_dev, "dqbuf cp to user failed\n");
-   ret = -EFAULT;
-   }
-   }
-out:
-   mutex_unlock(_dev->queue_lock);
-
-   if (ret == 0 && gspca_dev->sd_desc->dq_callback) {
-   mutex_lock(_dev->usb_lock);
-   gspca_dev->usb_err = 0;
-   if (gspca_dev->present)
-   gspca_dev->sd_desc->dq_callback(gspca_dev);
-   mutex_unlock(_dev->usb_lock);
-   }
+   if (!gspca_dev->sd_desc->dq_callback)
+   return;
  
-	return ret;

+   gspca_dev->usb_err = 0;
+   gspca_dev->sd_desc->dq_callback(gspca_dev);
  }



You are loosing the "if (gspca_dev->present)" check around
the dq_callback here, this may causes issues if the
buffer_finish method gets called after the device has
been unplugged.

If the vb2 code takes care that the buffer_finish method
doesn't get called then you may add my:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

To this patch.

Patch 2-4 look good to and you may add my:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

To those too.

Regards,

Hans


p.s.

If the v4l2-ctl + vb2 frameworks take care of not having
any driver callbacks called after disconnect, perhaps
the present flag can be removed?




-/*
- * queue a video buffer
- *
- * Attempting to queue a buffer that has already been
- * queued will return -EINVAL.
- */
-static int vidioc_qbuf(struct file *file, void *priv,
-   struct v4l2_buffer *v4l2_buf)
+static void gspca_buffer_queue(struct vb2_buffer *vb)
  {
-   struct gspca_dev *gspca_dev = video_drvdata(file);
-   struct gspca_frame *frame;
-   int i, index, ret;
-
-   gspca_dbg(gspca_dev, D_FRAM, "qbuf %d\n", v4l2_buf->index);
-
-   if (mutex_lock_interruptible(_dev->queue_lock))
-   return -ERESTARTSYS;
-
-   index = v4l2_buf->index;
-   if ((unsigned) index >= gspca_dev->nframes) {
-   gspca_dbg(gspca_dev, D_FRAM,
- "qbuf idx %d >= %d\n", index

Re: media: uvcvideo: Support realtek's UVC 1.5 device

[Hans de Goede]

Hi,

On 09-05-18 04:13, ming_q...@realsil.com.cn wrote:

From: ming_qian <ming_q...@realsil.com.cn>

The length of UVC 1.5 video control is 48, and it id 34 for UVC 1.1.
Change it to 48 for UVC 1.5 device,
and the UVC 1.5 device can be recognized.

More changes to the driver are needed for full UVC 1.5 compatibility.
However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have
been reported to work well.

Signed-off-by: ming_qian <ming_q...@realsil.com.cn>
Tested-by: Kai-Heng Feng <kai.heng.f...@canonical.com>


Looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans




---
  drivers/media/usb/uvc/uvc_video.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index aa0082f..32dfb32 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -171,6 +171,8 @@ static int uvc_get_video_ctrl(struct uvc_streaming *stream,
int ret;
  
  	size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;

+   if (stream->dev->uvc_version >= 0x0150)
+   size = 48;
if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) &&
query == UVC_GET_DEF)
return -EIO;
@@ -259,6 +261,8 @@ static int uvc_set_video_ctrl(struct uvc_streaming *stream,
int ret;
  
  	size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;

+   if (stream->dev->uvc_version >= 0x0150)
+   size = 48;
data = kzalloc(size, GFP_KERNEL);
if (data == NULL)
return -ENOMEM;

[PATCH] [media] gspca: Stop using GFP_DMA for buffers for USB bulk transfers

[Hans de Goede]

The recent "x86 ZONE_DMA love" discussion at LSF/MM pointed out that some
gspca sub-drivvers are using GFP_DMA to allocate buffers which are used
for USB bulk transfers, there is absolutely no need for this, drop it.

Cc: "Luis R. Rodriguez" <mcg...@kernel.org>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/media/usb/gspca/jl2005bcd.c | 2 +-
 drivers/media/usb/gspca/sq905.c | 2 +-
 drivers/media/usb/gspca/sq905c.c| 2 +-
 drivers/media/usb/gspca/vicam.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/gspca/jl2005bcd.c 
b/drivers/media/usb/gspca/jl2005bcd.c
index d668589598d6..c40245950553 100644
--- a/drivers/media/usb/gspca/jl2005bcd.c
+++ b/drivers/media/usb/gspca/jl2005bcd.c
@@ -321,7 +321,7 @@ static void jl2005c_dostream(struct work_struct *work)
int ret;
u8 *buffer;
 
-   buffer = kmalloc(JL2005C_MAX_TRANSFER, GFP_KERNEL | GFP_DMA);
+   buffer = kmalloc(JL2005C_MAX_TRANSFER, GFP_KERNEL);
if (!buffer) {
pr_err("Couldn't allocate USB buffer\n");
goto quit_stream;
diff --git a/drivers/media/usb/gspca/sq905.c b/drivers/media/usb/gspca/sq905.c
index cc8ff41b8ab3..ffea9c35b0a0 100644
--- a/drivers/media/usb/gspca/sq905.c
+++ b/drivers/media/usb/gspca/sq905.c
@@ -217,7 +217,7 @@ static void sq905_dostream(struct work_struct *work)
u8 *data;
u8 *buffer;
 
-   buffer = kmalloc(SQ905_MAX_TRANSFER, GFP_KERNEL | GFP_DMA);
+   buffer = kmalloc(SQ905_MAX_TRANSFER, GFP_KERNEL);
if (!buffer) {
pr_err("Couldn't allocate USB buffer\n");
goto quit_stream;
diff --git a/drivers/media/usb/gspca/sq905c.c b/drivers/media/usb/gspca/sq905c.c
index 5e1269eb7c50..274921c0bb46 100644
--- a/drivers/media/usb/gspca/sq905c.c
+++ b/drivers/media/usb/gspca/sq905c.c
@@ -138,7 +138,7 @@ static void sq905c_dostream(struct work_struct *work)
int ret;
u8 *buffer;
 
-   buffer = kmalloc(SQ905C_MAX_TRANSFER, GFP_KERNEL | GFP_DMA);
+   buffer = kmalloc(SQ905C_MAX_TRANSFER, GFP_KERNEL);
if (!buffer) {
pr_err("Couldn't allocate USB buffer\n");
goto quit_stream;
diff --git a/drivers/media/usb/gspca/vicam.c b/drivers/media/usb/gspca/vicam.c
index 554b90ef2200..8562bda0ef88 100644
--- a/drivers/media/usb/gspca/vicam.c
+++ b/drivers/media/usb/gspca/vicam.c
@@ -182,7 +182,7 @@ static void vicam_dostream(struct work_struct *work)
 
frame_sz = gspca_dev->cam.cam_mode[gspca_dev->curr_mode].sizeimage +
   HEADER_SIZE;
-   buffer = kmalloc(frame_sz, GFP_KERNEL | GFP_DMA);
+   buffer = kmalloc(frame_sz, GFP_KERNEL);
if (!buffer) {
pr_err("Couldn't allocate USB buffer\n");
goto exit;
-- 
2.17.0

Wrong use of GFP_DMA32 in drivers/media/platform/vivid/vivid-osd.c

[Hans de Goede]

Hi Hans, et. al.,

While debugging another GFP_DMA32 problem I did a quick
grep for GFP_DMA32 on the kernel, this result stood out:

drivers/media/platform/vivid/vivid-osd.c
373:dev->video_vbase = kzalloc(dev->video_buffer_size, GFP_KERNEL | 
GFP_DMA32);

Because it is making the same mistake as I was, you cannot use
GDP_DMA32 with kmalloc and friends, it will end up being
ignored. If you need memory below 4G you must call alloc_pages
for get_free_pages with GFP_DMA32 to get it.

Regards,

Hans

[PATCH] libv4lconvert: We support more then 32 bit src fmts now, so use 64 bit bitmasks

[Hans de Goede]

We support more then 32 bit src fmts now, so we can no longer re-use
struct v4l2_frmsizeenum.pixel_format to store a bitmask of all the
supported src-formats for a given frame-size.

This fixes a subtile bug where we would try to use SE401 as src fmt
instead of YUYV under certain circumstances.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1508706
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 lib/libv4lconvert/libv4lconvert-priv.h | 2 ++
 lib/libv4lconvert/libv4lconvert.c  | 9 -
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/lib/libv4lconvert/libv4lconvert-priv.h 
b/lib/libv4lconvert/libv4lconvert-priv.h
index e2389347..9a467e10 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -66,6 +66,8 @@ struct v4lconvert_data {
int cinfo_initialized;
 #endif // HAVE_JPEG
struct v4l2_frmsizeenum framesizes[V4LCONVERT_MAX_FRAMESIZES];
+   /* Bitmask of all supported src_formats which can do for a size */
+   int64_t framesize_supported_src_formats[V4LCONVERT_MAX_FRAMESIZES];
unsigned int no_framesizes;
int bandwidth;
int fps;
diff --git a/lib/libv4lconvert/libv4lconvert.c 
b/lib/libv4lconvert/libv4lconvert.c
index 1a5ccec2..d666bd97 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -434,7 +434,8 @@ static int v4lconvert_do_try_format_uvc(struct 
v4lconvert_data *data,
 
for (i = 0; i < ARRAY_SIZE(supported_src_pixfmts); i++) {
/* is this format supported? */
-   if (!(data->framesizes[best_framesize].pixel_format & (1 << i)))
+   if (!(data->framesize_supported_src_formats[best_framesize] &
+ (1ULL << i)))
continue;
 
/* Note the hardcoded use of discrete is based on this function
@@ -1647,9 +1648,7 @@ static void v4lconvert_get_framesizes(struct 
v4lconvert_data *data,
return;
}
data->framesizes[data->no_framesizes].type = 
frmsize.type;
-   /* We use the pixel_format member to store a bitmask of 
all
-  supported src_formats which can do this size */
-   data->framesizes[data->no_framesizes].pixel_format = 1 
<< index;
+   
data->framesize_supported_src_formats[data->no_framesizes] = 1ULL << index;
 
switch (frmsize.type) {
case V4L2_FRMSIZE_TYPE_DISCRETE:
@@ -1662,7 +1661,7 @@ static void v4lconvert_get_framesizes(struct 
v4lconvert_data *data,
}
data->no_framesizes++;
} else {
-   data->framesizes[j].pixel_format |= 1 << index;
+   data->framesize_supported_src_formats[j] |= 1ULL << 
index;
}
}
 }
-- 
2.14.3

[PATCH] stagin: atomisp: Fix oops by unbalanced clk enable/disable call

[Hans de Goede]

The common-clk core expects clk consumers to always call enable/disable
in a balanced manner. The atomisp driver does not call gmin_flisclk_ctrl()
in a balanced manner, so add a clock_on bool and skip redundant calls.

This fixes kernel oops like this one:

[   19.811613] gc0310_s_config S
[   19.811655] [ cut here ]
[   19.811664] WARNING: CPU: 1 PID: 720 at drivers/clk/clk.c:594 clk_core_disabl
[   19.811666] Modules linked in: tpm_crb(+) snd_soc_sst_atom_hifi2_platform tpm
[   19.811744] CPU: 1 PID: 720 Comm: systemd-udevd Tainted: G C OE   4.1
[   19.811746] Hardware name: Insyde T701/T701, BIOS BYT70A.YNCHENG.WIN.007 08/2
[   19.811749] task: 988df7ab2500 task.stack: ac1400474000
[   19.811752] RIP: 0010:clk_core_disable+0xc0/0x130
...
[   19.811775] Call Trace:
[   19.811783]  clk_core_disable_lock+0x1f/0x30
[   19.811788]  clk_disable+0x1f/0x30
[   19.811794]  gmin_flisclk_ctrl+0x87/0xf0
[   19.811801]  0xc0528512
[   19.811805]  0xc05295e2
[   19.811811]  ? acpi_device_wakeup_disable+0x50/0x60
[   19.811815]  ? acpi_dev_pm_attach+0x8e/0xd0
[   19.811818]  ? 0xc05294d0
[   19.811823]  i2c_device_probe+0x1cd/0x280
[   19.811828]  driver_probe_device+0x2ff/0x450

Fixes: "staging: atomisp: use clock framework for camera clocks"
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 .../media/atomisp/platform/intel-mid/atomisp_gmin_platform.c   | 7 +++
 1 file changed, 7 insertions(+)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 828fe5abd832..6671ebe4ecc9 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -29,6 +29,7 @@ struct gmin_subdev {
struct v4l2_subdev *subdev;
int clock_num;
int clock_src;
+   bool clock_on;
struct clk *pmc_clk;
struct gpio_desc *gpio0;
struct gpio_desc *gpio1;
@@ -583,6 +584,9 @@ static int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, 
int on)
struct gmin_subdev *gs = find_gmin_subdev(subdev);
struct i2c_client *client = v4l2_get_subdevdata(subdev);
 
+   if (gs->clock_on == !!on)
+   return 0;
+
if (on) {
ret = clk_set_rate(gs->pmc_clk, gs->clock_src);
 
@@ -591,8 +595,11 @@ static int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, 
int on)
gs->clock_src);
 
ret = clk_prepare_enable(gs->pmc_clk);
+   if (ret == 0)
+   gs->clock_on = true;
} else {
clk_disable_unprepare(gs->pmc_clk);
+   gs->clock_on = false;
}
 
return ret;
-- 
2.14.2

Re: Firmware for staging atomisp driver

[Hans de Goede]

Hi,

On 05/28/2017 02:30 PM, Hans de Goede wrote:

Hi All,

I've been trying to get the atomisp driver from staging to work
on a couple of devices I have.

I started with an Asus T100TA after fixing 2 oopses in the sensor
driver there I found out that the BIOS does not allow to put the
ISP in PCI mode and that there is no code to drive it in ACPI
enumerated mode.

So I moved to a generic Insyde T701 tablet which does allow
this. After fixing some more sensor driver issues there I was
ready to actually load the atomisp driver, but I could not
find the exact firmware required, I did find a version which
is close: "irci_stable_candrpv_0415_20150423_1753"
and tried that but that causes the atomisp driver to explode
in a backtrace which contains atomisp_load_firmware() so that
one seems no good.


Ok, so it turns out that the explosion was not a probem with
a wrong firmware version, but rather another atomisp code
bug. According to this patch:

https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/cam-0418-atomisp2-css2401-and-2401_legacy-irci_stable_candrpv.patch

The irci_stable_candrpv_0415_20150423_1753 version I
have and the irci_stable_candrpv_0415_20150521_0458
version expected are fully compatible.

So I'e focussed on fixing the crash and that was easy, see
the patch I just send.

Then I hit another bunch of crashes which all turn out to
be due to races with udev opening /dev/video# nodes for probing
before the driver is ready to handle this because the driver
registers the v4l2 devices too soon. I've hacked around this
for now:

https://github.com/jwrdegoede/linux-sunxi/commit/88c9c248e6e0f86d547ea8441e16b0e8b4c951c8

And with this hack the driver loads without issues, giving
me 10 /dev/video# devices. So I tried this app:

https://github.com/jfwells/linux-asus-t100ta/tree/master/webcam/atomisp_testapp

On a number of the v4l devices which leads to yet more oopses.

So I'm starting to wonder, does anyone have this driver working
(in its current form in 4.12-rc3 drivers/staging) at all ?

I'm asking  because that is hard to believe given e.g. the recursion bug
I've just fixed.

Can someone provide step-by-step instructions for how to get this
driver working?

I'm not expecting all userspace apps to just work, but at least a userspace 
example
given a picture from the camera would be very helpful in further developing
this driver.

Regards,

Hans

[PATCH] staging: atomisp: Fix endless recursion in hmm_init

[Hans de Goede]

hmm_init calls hmm_alloc to set dummy_ptr, hmm_alloc calls
hmm_init when dummy_ptr is not yet set, which is the case in
the call from hmm_init, so it calls hmm_init again, this continues
until we have a stack overflow due to the recursion.

This commit fixes this by adding a separate flag for tracking if
hmm_init has been called. Not pretty, but it gets the job done,
eventually we should be able to remove the hmm_init call from
hmm_alloc.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index 5729539..e79ca3c 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -43,6 +43,7 @@ struct hmm_bo_device bo_device;
 struct hmm_pooldynamic_pool;
 struct hmm_poolreserved_pool;
 static ia_css_ptr dummy_ptr;
+static bool hmm_initialized;
 struct _hmm_mem_stat hmm_mem_stat;
 
 /* p: private
@@ -186,6 +187,8 @@ int hmm_init(void)
if (ret)
dev_err(atomisp_dev, "hmm_bo_device_init failed.\n");
 
+   hmm_initialized = true;
+
/*
 * As hmm use NULL to indicate invalid ISP virtual address,
 * and ISP_VM_START is defined to 0 too, so we allocate
@@ -217,6 +220,7 @@ void hmm_cleanup(void)
dummy_ptr = 0;
 
hmm_bo_device_exit(_device);
+   hmm_initialized = false;
 }
 
 ia_css_ptr hmm_alloc(size_t bytes, enum hmm_bo_type type,
@@ -229,7 +233,7 @@ ia_css_ptr hmm_alloc(size_t bytes, enum hmm_bo_type type,
/* Check if we are initialized. In the ideal world we wouldn't need
   this but we can tackle it once the driver is a lot cleaner */
 
-   if (!dummy_ptr)
+   if (!hmm_initialized)
hmm_init();
/*Get page number from size*/
pgnr = size_to_pgnr_ceil(bytes);
-- 
2.9.4

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

[Hans de Goede]

Hi,

On 28-05-17 19:08, Alan Cox wrote:

On Sun, 28 May 2017 14:30:35 +0200
Hans de Goede <hdego...@redhat.com> wrote:


Do not call dev_warn with a NULL device, this silence the following 2
warnings:

[   14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO
[   14.392257] (NULL device *): Failed to find gmin variable gmin_V1P8GPIO

We could switch to using pr_warn for dev == NULL instead, but as comments
in the source indicate, the check for these 2 special gmin variables with
a NULL device is a workaround for 2 specific evaluation boards, so
completely silencing the missing warning for these actually is a good
thing.


At which point real missing variables won't get reported so NAK. I think
the right fix is to make the offending callers pass

subdev->dev


The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on
a global v2p8_gpio value rather then storing info in the gmin_subdev struct,
as such passing the subdev->dev pointer would be simply wrong. AFAICT the
v1p8 / v2p8 gpio code is the only caller passing in a NULL pointer and
as said since thisv1p8 / v2p8 gpio code is only for some special evaluation
boards, silencing the error when these variables are not present actually
is the right thing to do.


which if my understanding of the subdevices is correct should pass the
right valid device field from the atomisp.

Please also cc me if you are proposing patches this driver - and also
linux-media.


Sorry about that, I messed up my git send-email foo and send this to
a wrong set of addresses (and also added v5 in the subject which should
not be there) I did send out a fresh-copy with the full 7 patch patch-set
directly after CTRL+c-ing this wrong send-email (which only got the
first 3 patches send).

Regards,

Hans

[PATCH 7/7] staging: atomisp: Make ov2680 driver less chatty

[Hans de Goede]

There is no reason for all this printk spamming and certainly
not at an error log level.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/staging/media/atomisp/i2c/ov2680.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c 
b/drivers/staging/media/atomisp/i2c/ov2680.c
index 6dd466558701..3cabfe54c669 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.c
+++ b/drivers/staging/media/atomisp/i2c/ov2680.c
@@ -1191,9 +1191,8 @@ static int ov2680_detect(struct i2c_client *client)
OV2680_SC_CMMN_SUB_ID, );
revision = (u8) high & 0x0f;
 
-   dev_err(>dev, "sensor_revision id  = 0x%x\n", id);
-   dev_err(>dev, "detect ov2680 success\n");
-   dev_err(>dev, "5##\n");
+   dev_info(>dev, "sensor_revision id = 0x%x\n", id);
+
return 0;
 }
 
@@ -1448,8 +1447,6 @@ static int ov2680_probe(struct i2c_client *client,
void *pdata;
unsigned int i;
 
-   printk("ov2680_probe\n");
-   dev_info(>dev, "ov2680_probe\n");
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev) {
dev_err(>dev, "out of memory\n");
-- 
2.13.0

[PATCH 6/7] staging: atomisp: Ignore errors from second gpio in ov2680 driver

[Hans de Goede]

As the existing comment in the driver indicates the sensor has only 1 pin,
but some boards may have 2 gpios defined and we toggle both as we we don't
know which one is the right one. However if the ACPI resources table
defines only 1 gpio (as expected) the gpio1_ctrl call will always fail,
causing the probing of the driver to file.

This commit ignore the return value of the gpio1_ctrl call, fixing this.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/staging/media/atomisp/i2c/ov2680.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c 
b/drivers/staging/media/atomisp/i2c/ov2680.c
index 449aa2aa276f..6dd466558701 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.c
+++ b/drivers/staging/media/atomisp/i2c/ov2680.c
@@ -885,11 +885,12 @@ static int gpio_ctrl(struct v4l2_subdev *sd, bool flag)
if (flag) {
ret = dev->platform_data->gpio0_ctrl(sd, 1);
usleep_range(1, 15000);
-   ret |= dev->platform_data->gpio1_ctrl(sd, 1);
+   /* Ignore return from second gpio, it may not be there */
+   dev->platform_data->gpio1_ctrl(sd, 1);
usleep_range(1, 15000);
} else {
-   ret = dev->platform_data->gpio1_ctrl(sd, 0);
-   ret |= dev->platform_data->gpio0_ctrl(sd, 0);
+   dev->platform_data->gpio1_ctrl(sd, 0);
+   ret = dev->platform_data->gpio0_ctrl(sd, 0);
}
return ret;
 }
-- 
2.13.0

[PATCH 1/7] staging: atomisp: Fix calling efivar_entry_get() with unaligned arguments

[Hans de Goede]

efivar_entry_get has certain alignment requirements and the atomisp
platform code was not honoring these, causing an oops by triggering the
WARN_ON in arch/x86/platform/efi/efi_64.c: virt_to_phys_or_null_size().

This commit fixes this by using the members of the efivar struct embedded
in the efivar_entry struct we kzalloc as arguments to efivar_entry_get(),
which is how all the other callers of efivar_entry_get() do this.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 .../atomisp/platform/intel-mid/atomisp_gmin_platform.c  | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a71126..104fea2f8697 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -623,9 +623,7 @@ int gmin_get_config_var(struct device *dev, const char 
*var, char *out, size_t *
char var8[CFG_VAR_NAME_MAX];
efi_char16_t var16[CFG_VAR_NAME_MAX];
struct efivar_entry *ev;
-   u32 efiattr_dummy;
int i, j, ret;
-   unsigned long efilen;
 
 if (dev && ACPI_COMPANION(dev))
 dev = _COMPANION(dev)->dev;
@@ -684,15 +682,18 @@ int gmin_get_config_var(struct device *dev, const char 
*var, char *out, size_t *
return -ENOMEM;
memcpy(>var.VariableName, var16, sizeof(var16));
ev->var.VendorGuid = GMIN_CFG_VAR_EFI_GUID;
+   ev->var.DataSize = *out_len;
 
-   efilen = *out_len;
-   ret = efivar_entry_get(ev, _dummy, , out);
+   ret = efivar_entry_get(ev, >var.Attributes,
+  >var.DataSize, ev->var.Data);
+   if (ret == 0) {
+   memcpy(out, ev->var.Data, ev->var.DataSize);
+   *out_len = ev->var.DataSize;
+   } else {
+   dev_warn(dev, "Failed to find gmin variable %s\n", var8);
+   }
 
kfree(ev);
-   *out_len = efilen;
-
-   if (ret)
-   dev_warn(dev, "Failed to find gmin variable %s\n", var8);
 
return ret;
 }
-- 
2.13.0

[PATCH 2/7] staging: atomisp: Do not call dev_warn with a NULL device

[Hans de Goede]

Do not call dev_warn with a NULL device, this silence the following 2
warnings:

[   14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO
[   14.392257] (NULL device *): Failed to find gmin variable gmin_V1P8GPIO

We could switch to using pr_warn for dev == NULL instead, but as comments
in the source indicate, the check for these 2 special gmin variables with
a NULL device is a workaround for 2 specific evaluation boards, so
completely silencing the missing warning for these actually is a good
thing.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 104fea2f8697..3fea81ea5dbd 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -689,7 +689,7 @@ int gmin_get_config_var(struct device *dev, const char 
*var, char *out, size_t *
if (ret == 0) {
memcpy(out, ev->var.Data, ev->var.DataSize);
*out_len = ev->var.DataSize;
-   } else {
+   } else if (dev) {
dev_warn(dev, "Failed to find gmin variable %s\n", var8);
}
 
-- 
2.13.0

[PATCH 3/7] staging: atomisp: Set step to 0 for mt9m114 menu control

[Hans de Goede]

menu controls are not allowed to have a step size, set step to 0 to
fix an oops from the WARN_ON in v4l2_ctrl_new_custom() triggering
because of this.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/staging/media/atomisp/i2c/mt9m114.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.c 
b/drivers/staging/media/atomisp/i2c/mt9m114.c
index ced175c268d1..3fa915313e53 100644
--- a/drivers/staging/media/atomisp/i2c/mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/mt9m114.c
@@ -1499,7 +1499,7 @@ static struct v4l2_ctrl_config mt9m114_controls[] = {
 .type = V4L2_CTRL_TYPE_MENU,
 .min = 0,
 .max = 3,
-.step = 1,
+.step = 0,
 .def = 1,
 .flags = 0,
 },
-- 
2.13.0

[PATCH 5/7] staging: atomisp: Add OVTI2680 ACPI id to ov2680 driver

[Hans de Goede]

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/staging/media/atomisp/i2c/ov2680.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c 
b/drivers/staging/media/atomisp/i2c/ov2680.c
index 566091035c64..449aa2aa276f 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.c
+++ b/drivers/staging/media/atomisp/i2c/ov2680.c
@@ -1521,6 +1521,7 @@ static int ov2680_probe(struct i2c_client *client,
 
 static struct acpi_device_id ov2680_acpi_match[] = {
{"XXOV2680"},
+   {"OVTI2680"},
{},
 };
 MODULE_DEVICE_TABLE(acpi, ov2680_acpi_match);
-- 
2.13.0

[PATCH 4/7] staging: atomisp: Add INT0310 ACPI id to gc0310 driver

[Hans de Goede]

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/staging/media/atomisp/i2c/gc0310.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c 
b/drivers/staging/media/atomisp/i2c/gc0310.c
index 1ec616a15086..350fd7fd5b86 100644
--- a/drivers/staging/media/atomisp/i2c/gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/gc0310.c
@@ -1455,6 +1455,7 @@ static int gc0310_probe(struct i2c_client *client,
 
 static struct acpi_device_id gc0310_acpi_match[] = {
{"XXGC0310"},
+   {"INT0310"},
{},
 };
 
-- 
2.13.0

Firmware for staging atomisp driver

[Hans de Goede]

Hi All,

I've been trying to get the atomisp driver from staging to work
on a couple of devices I have.

I started with an Asus T100TA after fixing 2 oopses in the sensor
driver there I found out that the BIOS does not allow to put the
ISP in PCI mode and that there is no code to drive it in ACPI
enumerated mode.

So I moved to a generic Insyde T701 tablet which does allow
this. After fixing some more sensor driver issues there I was
ready to actually load the atomisp driver, but I could not
find the exact firmware required, I did find a version which
is close: "irci_stable_candrpv_0415_20150423_1753"
and tried that but that causes the atomisp driver to explode
in a backtrace which contains atomisp_load_firmware() so that
one seems no good.

Can someone help me to get the right firmware ?

The TODO says: "can also be extracted from the upgrade kit"
about the firmware files, but it is not clear to me what /
where the "upgrade kit" is.

More in general it would be a good idea if someone inside Intel
would try to get permission to add the firmware to linux-firmware.

Anyways I will send out the patches I've currently, once I've
the right firmware I will continue working on this.

Regards,

Hans

[PATCH] staging: atomisp: Fix -Werror=int-in-bool-context compile errors

[Hans de Goede]

With gcc-7.1.1 I was getting the following compile error:

error: ‘*’ in boolean context, suggest ‘&&’ instead

The problem is the definition of CEIL_DIV:
 #define CEIL_DIV(a, b)   ((b) ? ((a) + (b) - 1) / (b) : 0)

Which when called as: CEIL_DIV(x, y * z) triggers this error, note
we cannot do as the error suggests since b is evaluated multiple times.

This commit fixes these compile errors.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c   | 1 -
 .../pci/atomisp2/css2400/hive_isp_css_include/math_support.h| 6 +++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
index b830b241e2e6..ad2c610d2ce3 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
@@ -2506,7 +2506,6 @@ static void __configure_capture_pp_input(struct 
atomisp_sub_device *asd,
struct ia_css_pipe_extra_config *pipe_extra_configs =
_env->pipe_extra_configs[pipe_id];
unsigned int hor_ds_factor = 0, ver_ds_factor = 0;
-#define CEIL_DIV(a, b)   ((b) ? ((a) + (b) - 1) / (b) : 0)
 
if (width == 0 && height == 0)
return;
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
index 48d84bc0ad9e..f74b405b0f39 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
@@ -62,15 +62,15 @@
 #define MAX(a, b)(((a) > (b)) ? (a) : (b))
 #define MIN(a, b)(((a) < (b)) ? (a) : (b))
 #ifdef ISP2401
-#define ROUND_DIV(a, b)  ((b) ? ((a) + ((b) >> 1)) / (b) : 0)
+#define ROUND_DIV(a, b)  (((b) != 0) ? ((a) + ((b) >> 1)) / (b) : 0)
 #endif
-#define CEIL_DIV(a, b)   ((b) ? ((a) + (b) - 1) / (b) : 0)
+#define CEIL_DIV(a, b)   (((b) != 0) ? ((a) + (b) - 1) / (b) : 0)
 #define CEIL_MUL(a, b)   (CEIL_DIV(a, b) * (b))
 #define CEIL_MUL2(a, b)  (((a) + (b) - 1) & ~((b) - 1))
 #define CEIL_SHIFT(a, b) (((a) + (1 << (b)) - 1)>>(b))
 #define CEIL_SHIFT_MUL(a, b) (CEIL_SHIFT(a, b) << (b))
 #ifdef ISP2401
-#define ROUND_HALF_DOWN_DIV(a, b)  ((b) ? ((a) + (b / 2) - 1) / (b) : 0)
+#define ROUND_HALF_DOWN_DIV(a, b)  (((b) != 0) ? ((a) + (b / 2) - 1) / (b) 
: 0)
 #define ROUND_HALF_DOWN_MUL(a, b)  (ROUND_HALF_DOWN_DIV(a, b) * (b))
 #endif
 
-- 
2.12.2

Re: [PATCH] MAINTAINERS: change maintainer for gscpa/pwc/radio-shark

[Hans de Goede]

Hi,

On 04-07-16 15:20, Hans Verkuil wrote:

Hans de Goede has no more time to work on those, so I'll take over.
For gspca/pwc I'll do 'Odd Fixes', for radio-shark I'll be a
full maintainer.

Signed-off-by: Hans Verkuil <hans.verk...@cisco.com>


Thanks!

Acked-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 MAINTAINERS | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 02299fd..9499b8e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5163,10 +5163,10 @@ S:  Maintained
 F: drivers/media/usb/gspca/m5602/

 GSPCA PAC207 SONIXB SUBDRIVER
-M: Hans de Goede <hdego...@redhat.com>
+M: Hans Verkuil <hverk...@xs4all.nl>
 L: linux-media@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
-S: Maintained
+S: Odd Fixes
 F: drivers/media/usb/gspca/pac207.c

 GSPCA SN9C20X SUBDRIVER
@@ -5184,10 +5184,10 @@ S:  Maintained
 F: drivers/media/usb/gspca/t613.c

 GSPCA USB WEBCAM DRIVER
-M: Hans de Goede <hdego...@redhat.com>
+M: Hans Verkuil <hverk...@xs4all.nl>
 L: linux-media@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
-S: Maintained
+S: Odd Fixes
 F: drivers/media/usb/gspca/

 GUID PARTITION TABLE (GPT)
@@ -9237,10 +9237,10 @@ F:  Documentation/video4linux/README.pvrusb2
 F: drivers/media/usb/pvrusb2/

 PWC WEBCAM DRIVER
-M: Hans de Goede <hdego...@redhat.com>
+M: Hans Verkuil <hverk...@xs4all.nl>
 L: linux-media@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
-S: Maintained
+S: Odd Fixes
 F: drivers/media/usb/pwc/*

 PWM FAN DRIVER
@@ -9455,14 +9455,14 @@ F:  drivers/video/fbdev/aty/radeon*
 F: include/uapi/linux/radeonfb.h

 RADIOSHARK RADIO DRIVER
-M: Hans de Goede <hdego...@redhat.com>
+M: Hans Verkuil <hverk...@xs4all.nl>
 L: linux-media@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/radio/radio-shark.c

 RADIOSHARK2 RADIO DRIVER
-M: Hans de Goede <hdego...@redhat.com>
+M: Hans Verkuil <hverk...@xs4all.nl>
 L: linux-media@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
 S: Maintained


--
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: Stepping down as gspca and pwc maintainer

[Hans de Goede]

Hi,

On 04-07-16 09:36, Hans Verkuil wrote:

Hi Hans,

On 07/03/2016 11:31 PM, Hans de Goede wrote:

Hi All,

Admittedly I've not been all that active as gspca and pwc
maintainer lately, but officially I'm still the maintainer
for both.

Between my $dayjob, other foss projects and last but not
least spending time with my wife and children I'm way too busy
lately.

So I'm hereby officially stepping down as gspca and pwc maintainer,
I know this means MAINTAINERS needs updating, but I'm hoping to
find a volunteer to take them over who can then directly replace my
name in MAINTAINERS.


I can take over as "Odd Fixes" maintainer. I have a pwc webcam and several
gspca webcams, so I can at least test some webcams if needed.


Cool, thanks!


Both are currently in descent shape, one thing which needs
doing (for a long time now) is converting gspca to videobuf2.

Other then that the following patches are pending in
patchwork (and are all ready to be merged I just never
got around to it):

1 actual bug-fix which should really be merged asap


Merged for 4.7-rcX or 4.8?


I guess not many people have 10 Gbps usb-3.1 ports
yet, and even fewer will plug an old webcam into such
a port, so 4.8 is fine I think.


(Mauro can you pick this one up directly ?):

https://patchwork.linuxtv.org/patch/34155/

1 compiler warning:
https://patchwork.linuxtv.org/patch/32726/

A couple of v4l-compliance fixes:
https://patchwork.linuxtv.org/patch/33408/
https://patchwork.linuxtv.org/patch/33412/
https://patchwork.linuxtv.org/patch/33411/
https://patchwork.linuxtv.org/patch/33410/
https://patchwork.linuxtv.org/patch/33409/


I'll make a pull request for these today.



And last there is this patch which need someone to review it:
https://patchwork.linuxtv.org/patch/34986/


I can take care of that.


Thanks.

On 04-07-16 09:38, Hans Verkuil wrote:
>
> What about the two radio-shark drivers?

Ah yes, if you could take over those 2 too that would be
great. Can you send a patch to update MAINTAINERS ?

Regards,

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

Stepping down as gspca and pwc maintainer

[Hans de Goede]

Hi All,

Admittedly I've not been all that active as gspca and pwc
maintainer lately, but officially I'm still the maintainer
for both.

Between my $dayjob, other foss projects and last but not
least spending time with my wife and children I'm way too busy
lately.

So I'm hereby officially stepping down as gspca and pwc maintainer,
I know this means MAINTAINERS needs updating, but I'm hoping to
find a volunteer to take them over who can then directly replace my
name in MAINTAINERS.

Both are currently in descent shape, one thing which needs
doing (for a long time now) is converting gspca to videobuf2.

Other then that the following patches are pending in
patchwork (and are all ready to be merged I just never
got around to it):

1 actual bug-fix which should really be merged asap
(Mauro can you pick this one up directly ?):

https://patchwork.linuxtv.org/patch/34155/

1 compiler warning:
https://patchwork.linuxtv.org/patch/32726/

A couple of v4l-compliance fixes:
https://patchwork.linuxtv.org/patch/33408/
https://patchwork.linuxtv.org/patch/33412/
https://patchwork.linuxtv.org/patch/33411/
https://patchwork.linuxtv.org/patch/33410/
https://patchwork.linuxtv.org/patch/33409/

And last there is this patch which need someone to review it:
https://patchwork.linuxtv.org/patch/34986/

Regards,

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

Re: [3/7,media] gspca: avoid unused variable warnings

[Hans de Goede]

Hi Arnd,

On 26-01-16 15:09, Arnd Bergmann wrote:

When CONFIG_INPUT is disabled, multiple gspca backend drivers
print compile-time warnings about unused variables:

media/usb/gspca/cpia1.c: In function 'sd_stopN':
media/usb/gspca/cpia1.c:1627:13: error: unused variable 'sd' 
[-Werror=unused-variable]
media/usb/gspca/konica.c: In function 'sd_stopN':
media/usb/gspca/konica.c:246:13: error: unused variable 'sd' 
[-Werror=unused-variable]

This encloses the declarations in #ifdef CONFIG_INPUT, just like
the code using them is.

Signed-off-by: Arnd Bergmann 
Fixes: ee186fd96a5f ("[media] gscpa_t613: Add support for the camera button")
Fixes: c2f644aeeba3 ("[media] gspca_cpia1: Add support for button")
Fixes: b517af722860 ("V4L/DVB: gspca_konica: New gspca subdriver for konica chipset 
using cams")


Sorry for being super slow to respond to this patch, can you
please do a new version using __maybe_unused instead of adding
#ifdef-s ?

Thanks,

Hans



---
 drivers/media/usb/gspca/cpia1.c  | 2 ++
 drivers/media/usb/gspca/konica.c | 2 ++
 drivers/media/usb/gspca/t613.c   | 3 ++-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/gspca/cpia1.c b/drivers/media/usb/gspca/cpia1.c
index f23df4a9d8c5..e2264dc5d64d 100644
--- a/drivers/media/usb/gspca/cpia1.c
+++ b/drivers/media/usb/gspca/cpia1.c
@@ -1624,7 +1624,9 @@ static int sd_start(struct gspca_dev *gspca_dev)

 static void sd_stopN(struct gspca_dev *gspca_dev)
 {
+#if IS_ENABLED(CONFIG_INPUT)
struct sd *sd = (struct sd *) gspca_dev;
+#endif

command_pause(gspca_dev);

diff --git a/drivers/media/usb/gspca/konica.c b/drivers/media/usb/gspca/konica.c
index 39c96bb4c985..21c52655ef28 100644
--- a/drivers/media/usb/gspca/konica.c
+++ b/drivers/media/usb/gspca/konica.c
@@ -243,7 +243,9 @@ static int sd_start(struct gspca_dev *gspca_dev)

 static void sd_stopN(struct gspca_dev *gspca_dev)
 {
+#if IS_ENABLED(CONFIG_INPUT)
struct sd *sd = (struct sd *) gspca_dev;
+#endif

konica_stream_off(gspca_dev);
 #if IS_ENABLED(CONFIG_INPUT)
diff --git a/drivers/media/usb/gspca/t613.c b/drivers/media/usb/gspca/t613.c
index e2cc4e5a0ccb..d918c2d31502 100644
--- a/drivers/media/usb/gspca/t613.c
+++ b/drivers/media/usb/gspca/t613.c
@@ -837,11 +837,12 @@ static void sd_pkt_scan(struct gspca_dev *gspca_dev,
u8 *data,   /* isoc packet */
int len)/* iso packet length */
 {
-   struct sd *sd = (struct sd *) gspca_dev;
int pkt_type;

if (data[0] == 0x5a) {
 #if IS_ENABLED(CONFIG_INPUT)
+   struct sd *sd = (struct sd *) gspca_dev;
+
if (len > 20) {
u8 state = (data[20] & 0x80) ? 1 : 0;
if (sd->button_pressed != state) {


--
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: ov519.c - allow setting i2c_detect_tries

[Hans de Goede]

Hi,

On 16-07-15 00:51, valdis.kletni...@vt.edu wrote:

I encountered a user who was having troubles getting a PlayStation EyeToy
(USB ID 054c:0155) working as a webcam. They reported that repeated attempts
would often make it work.  Looking at the code, there was support for
repeated attempts at I2C transactions - but only if you rebuilt the
module from source.

Added module parameter support so that users running a distro kernel
can tune it for recalcitrant devices.


That is not necessary, this should be fixed by this commit:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/media/usb/gspca?id=f7c7ac480d246f2f625a70f56ea6650710c23f30

Regards,

Hans




While we're at it, fix the comment to reflect the error message actually issued.

Testing:

[/usr/src/linux-next] insmod drivers/media/usb/gspca/gspca_ov519.ko
[/usr/src/linux-next] cat /sys/module/gspca_ov519/parameters/i2c_detect_tries
10
[/usr/src/linux-next] rmmod gspca_ov519
[/usr/src/linux-next] insmod drivers/media/usb/gspca/gspca_ov519.ko 
i2c_detect_tries=50
[/usr/src/linux-next] cat /sys/module/gspca_ov519/parameters/i2c_detect_tries
50
[/usr/src/linux-next] modinfo drivers/media/usb/gspca/gspca_ov519.ko | grep parm
parm:   i2c_detect_tries:Number of times to try to init I2C (default 
10) (int)
parm:   frame_rate:Frame rate (5, 10, 15, 20 or 30 fps) (int)

Reported-By: Demhlyr 
Signed-Off-By: Valdis Kletnieks 
---
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

--- a/drivers/media/usb/gspca/ov519.c   2014-10-21 10:06:09.359806243 -0400
+++ b/drivers/media/usb/gspca/ov519.c   2015-07-15 18:35:21.063790541 -0400
@@ -57,8 +57,10 @@ MODULE_LICENSE("GPL");
 static int frame_rate;

 /* Number of times to retry a failed I2C transaction. Increase this if you
- * are getting "Failed to read sensor ID..." */
+ * are getting "Can't determine sensor slave IDs" */
 static int i2c_detect_tries = 10;
+module_param(i2c_detect_tries, int, 0644);
+MODULE_PARM_DESC(i2c_detect_tries,"Number of times to try to init I2C (default 
10)");

 /* ov519 device descriptor */
 struct sd {


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

Re: USB xHCI regression after upgrading from kernel 3.19.0-51 to 4.2.0-34.

[Hans de Goede]

Hi,

It is probably best to resend this mail to
linux-usb 
since this is more of a usb problem then a v4l2 problem,
and all the usb experts are subscribed to that list.

Regards,

Hans



On 07-04-16 17:36, Matthew Giassa wrote:

Good day,

I maintain an SDK for USB2.0 and USB3.0 U3V machine vision cameras, and
several of my customers have reported severe issues since upgrading from
kernel 3.19.0-51 (Ubuntu 14.04.3 LTS) to kernel 4.2.0-34 (Ubuntu 14.04.4
LTS). I've received helpful advice from members of the libusb and
linux-usb mailing list and development groups on how to generate useful
logs to help diagnose the issue, and have filed a bug to track this
issue at:

   https://bugzilla.kernel.org/show_bug.cgi?id=115961

It seems that with kernels newer than the 3.19 series (I've tested on
4.2.0-34, and just repeated the tests on the latest 4.5.0 release), the
cameras lock up, and cannot stream image data to the user application. I
am able to resolve the issue on 4.2.0-34 by disabling USB power
management by adding "usbcore.autosuspend=-1". On the 4.5 kernel, this
"trick" doesn't work at all, and I have no way to get the cameras to
stream data. I can do simple USB control requests to query things like
register values and serial numbers, but that's it. Asynchronous bulk
transfers never succeed.

Special Cases:
  * The issue does not occur when using USB2.0 cameras on a USB2.0 port,
regardless of the kernel in use.
  * The issues occur only on Intel 8 Series and Intel 9 Series USB3.0
host controllers with 4.x kernels.
  * Intel 10 Series host controllers have not yet been tested.
  * The issues never occur on Fresco or Renesas host controllers,
regardless of the kernel in use.
  * From visual inspection of lsusb output, the issue only appears to
happen when the U1 and U2 options are available to the device.

I would like to request assistance with diagnosing and resolving the
issue, as it requires our customers to either not use Intel host
controllers, or sticking to older kernel releases.

Thank you for your time and assistance.


Matthew Giassa, MASc, BASc, EIT
Security and Embedded Systems Specialist
linkedin: https://ca.linkedin.com/in/giassa
e-mail:   matt...@giassa.net
website:  www.giassa.net

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


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

Re: [PATCH 6/7] [media] gspca: fix a v4l2-compliance failure during VIDIOC_REQBUFS

[Hans de Goede]

Hi,

On 14-03-16 16:02, Antonio Ospite wrote:

On Thu, 10 Mar 2016 15:54:37 +0100
Hans de Goede <hdego...@redhat.com> wrote:


Hi,

On 09-03-16 17:03, Antonio Ospite wrote:

When calling VIDIOC_REQBUFS v4l2-compliance fails with this message:

fail: v4l2-test-buffers.cpp(476): q.reqbufs(node, 1)
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL

By looking at the v4l2-compliance code the failure happens when trying
to request V4L2_MEMORY_USERPTR buffers without freeing explicitly the
previously allocated V4L2_MEMORY_MMAP buffers.

This would suggest that when changing the memory field in struct
v4l2_requestbuffers the driver is supposed to free automatically any
previous allocated buffers, and looking for inspiration at the code in
drivers/media/v4l2-core/videobuf2-core.c::vb2_core_reqbufs() seems to
confirm this interpretation; however gspca is just returning -EBUSY in
this case.

Removing the special handling for the case of a different memory value
fixes the compliance failure.

Signed-off-by: Antonio Ospite <a...@ao2.it>
---

This should be safe, but I'd really like a comment from someone with a more
global knowledge of v4l2.

If my interpretation about how drivers should behave when the value of the
memory field changes is correct, I could send also a documentation update for
Documentation/DocBook/media/v4l/vidioc-reqbufs.xml

Just let me know.

Thanks,
 Antonio


   drivers/media/usb/gspca/gspca.c | 7 ---
   1 file changed, 7 deletions(-)

diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index 84b0d6a..915b6c7 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -1402,13 +1402,6 @@ static int vidioc_reqbufs(struct file *file, void *priv,
if (mutex_lock_interruptible(_dev->queue_lock))
return -ERESTARTSYS;

-   if (gspca_dev->memory != GSPCA_MEMORY_NO
-   && gspca_dev->memory != GSPCA_MEMORY_READ
-   && gspca_dev->memory != rb->memory) {
-   ret = -EBUSY;
-   goto out;
-   }
-


reqbufs is used internally and this change will allow changing
gspca_dev->memory from USERPTR / MMAP to GSPCA_MEMORY_READ
please replace this check with a check to only allow
rb->memory to be GSPCA_MEMORY_READ when coming from GSPCA_MEMORY_NO
or GSPCA_MEMORY_READ



OK, thanks, I'll take a look again later this week.

In the meantime, if patches from 1 to 5 are OK, can we have them merged
so I will just resubmit the last two in the set?


Not sure when I'll have time to do this, I would prefer to also take
v2 of patch 6 and 7 while at it. But I agree that there is no need
to pick op patches 1 - 5. I'll pick them up from patchwork when I've
time.

Regards,

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

Re: [v4l-utils PATCHv2] libv4lconvert: Add support for V4L2_PIX_FMT_{NV16,NV61}

[Hans de Goede]

Hi,

On 12-03-16 01:45, Niklas Söderlund wrote:

NV16 and NV61 are two-plane versions of the YUV 4:2:2 formats YUYV and
YVYU. Support both formats by merging the two planes into a one and
falling through to the V4L2_PIX_FMT_{YUYV,YVYU} code path.

Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
---

I'm sorry this is a bit of a hack. The support for NV16 are scarce and
this allowed me use it in qv4l2 so I thought it might help someone else.
I'm not to sure about the entry in supported_src_pixfmts[] is it correct
to set 'needs conversion' for my use case?


needs_conversion is set on formats which apps are unlikely to support
natively, so yes it is correct to set it.

Patch looks good to me:

Acked-by: Hans de Goede <hdego...@redhat.com>

Hans Verkuil, if you're happy with this version feel free to push it.

Regards,

Hans





Changes since v1
- Add NV61 support
- Fixed s/YUVU/YUYV/g in commit message


  lib/libv4lconvert/libv4lconvert-priv.h |  3 +++
  lib/libv4lconvert/libv4lconvert.c  | 31 +++
  lib/libv4lconvert/rgbyuv.c | 15 +++
  3 files changed, 49 insertions(+)

diff --git a/lib/libv4lconvert/libv4lconvert-priv.h 
b/lib/libv4lconvert/libv4lconvert-priv.h
index b77e3d3..1740efc 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -129,6 +129,9 @@ void v4lconvert_yuyv_to_bgr24(const unsigned char *src, 
unsigned char *dst,
  void v4lconvert_yuyv_to_yuv420(const unsigned char *src, unsigned char *dst,
int width, int height, int stride, int yvu);

+void v4lconvert_nv16_to_yuyv(const unsigned char *src, unsigned char *dest,
+   int width, int height);
+
  void v4lconvert_yvyu_to_rgb24(const unsigned char *src, unsigned char *dst,
int width, int height, int stride);

diff --git a/lib/libv4lconvert/libv4lconvert.c 
b/lib/libv4lconvert/libv4lconvert.c
index f62aea1..d3d8936 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -98,6 +98,8 @@ static const struct v4lconvert_pixfmt supported_src_pixfmts[] 
= {
{ V4L2_PIX_FMT_YUYV,16,  5,  4, 0 },
{ V4L2_PIX_FMT_YVYU,16,  5,  4, 0 },
{ V4L2_PIX_FMT_UYVY,16,  5,  4, 0 },
+   { V4L2_PIX_FMT_NV16,16,  5,  4, 1 },
+   { V4L2_PIX_FMT_NV61,16,  5,  4, 1 },
/* yuv 4:2:0 formats */
{ V4L2_PIX_FMT_SPCA501, 12,  6,  3, 1 },
{ V4L2_PIX_FMT_SPCA505, 12,  6,  3, 1 },
@@ -1229,6 +1231,20 @@ static int v4lconvert_convert_pixfmt(struct 
v4lconvert_data *data,
}
break;

+   case V4L2_PIX_FMT_NV16: {
+   unsigned char *tmpbuf;
+
+   tmpbuf = v4lconvert_alloc_buffer(width * height * 2,
+   >convert_pixfmt_buf, 
>convert_pixfmt_buf_size);
+   if (!tmpbuf)
+   return v4lconvert_oom_error(data);
+
+   v4lconvert_nv16_to_yuyv(src, tmpbuf, width, height);
+   src_pix_fmt = V4L2_PIX_FMT_YUYV;
+   src = tmpbuf;
+   bytesperline = bytesperline * 2;
+   /* fall through */
+   }
case V4L2_PIX_FMT_YUYV:
if (src_size < (width * height * 2)) {
V4LCONVERT_ERR("short yuyv data frame\n");
@@ -1251,6 +1267,21 @@ static int v4lconvert_convert_pixfmt(struct 
v4lconvert_data *data,
}
break;

+   case V4L2_PIX_FMT_NV61: {
+   unsigned char *tmpbuf;
+
+   tmpbuf = v4lconvert_alloc_buffer(width * height * 2,
+   >convert_pixfmt_buf, 
>convert_pixfmt_buf_size);
+   if (!tmpbuf)
+   return v4lconvert_oom_error(data);
+
+   /* Note NV61 is NV16 with U and V swapped so this becomes yvyu. 
*/
+   v4lconvert_nv16_to_yuyv(src, tmpbuf, width, height);
+   src_pix_fmt = V4L2_PIX_FMT_YVYU;
+   src = tmpbuf;
+   bytesperline = bytesperline * 2;
+   /* fall through */
+   }
case V4L2_PIX_FMT_YVYU:
if (src_size < (width * height * 2)) {
V4LCONVERT_ERR("short yvyu data frame\n");
diff --git a/lib/libv4lconvert/rgbyuv.c b/lib/libv4lconvert/rgbyuv.c
index 695255a..a0f8256 100644
--- a/lib/libv4lconvert/rgbyuv.c
+++ b/lib/libv4lconvert/rgbyuv.c
@@ -295,6 +295,21 @@ void v4lconvert_yuyv_to_yuv420(const unsigned char *src, 
unsigned char *dest,
}
  }

+void v4lconvert_nv16_to_yuyv(const unsigned char *src, unsigned char *dest,
+   int width, int height)
+{
+   const unsigned char *y, *cbcr;
+   int count = 0;
+
+   y = src;
+   cbcr = src + wid

Re: [PATCH 7/7] [media] gspca: fix a v4l2-compliance failure during read()

[Hans de Goede]

Hi,

On 09-03-16 17:03, Antonio Ospite wrote:

v4l2-compliance fails with this message:

   fail: v4l2-test-buffers.cpp(512): Expected EBUSY, got 22
   test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL

Looking at the v4l2-compliance code reveals that this failure is about
the read() callback.

In gspca, dev_read() is calling vidioc_dqbuf() which calls
frame_ready_nolock() but the latter returns -EINVAL in a case when
v4l2-compliance expects -EBUSY.

Fix the failure by changing the return value in frame_ready_nolock().

Signed-off-by: Antonio Ospite 
---
  drivers/media/usb/gspca/gspca.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index 915b6c7..de7e300 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -1664,7 +1664,7 @@ static int frame_ready_nolock(struct gspca_dev 
*gspca_dev, struct file *file,
return -ENODEV;
if (gspca_dev->capt_file != file || gspca_dev->memory != memory ||
!gspca_dev->streaming)
-   return -EINVAL;
+   return -EBUSY;

/* check if a frame is ready */
return gspca_dev->fr_o != atomic_read(_dev->fr_i);


I'm not sure that this is the right fix:


1) !gspca_dev->streaming should result in -EINVAL, this is the same as what 
videobuf2 is doing
2) gspca_dev->memory != memory should result in -EINVAL
3) gspca_dev->capt_file != file means calling dqbuf without having done reqbufs 
(through the same fd)
   which certainly seemes like -EINVAL to me.

The actual problem is that dev_read() is not catching that mmap is being in use:

static ssize_t dev_read(struct file *file, char __user *data,
size_t count, loff_t *ppos)
{
...
if (gspca_dev->memory == GSPCA_MEMORY_NO) { /* first time ? */
ret = read_alloc(gspca_dev, file);
if (ret != 0)
return ret;
}

It will skip the read_alloc since gspca_dev->memory is USERPTR or MMAP
and then do a dqbuf with memory == GSPCA_MEMORY_READ, triggering the
gspca_dev->memory != memory check.

There are a couple of issues here:

1) gspca_dev->memory check without holding usb_lock, the taking and
releasing of usb_lock should be moved from read_alloc() into dev_read()
itself.

2) dev_read() should not assume that reading is ok if
   gspca_dev->memory == GSPCA_MEMORY_NO, it needs a:

if (gspca_dev->memory != GSPCA_MEMORY_NO &&
gspca_dev->memory != GSPCA_MEMORY_READ)
return -EBUSY;

(while holding the usb_lock so the above is wrong)

3) If gspca_dev->memory == GSPCA_MEMORY_READ already the
   stream could have been stopped. so we need to check
   gspca_dev->streaming (while holding the usb_lock)
   and do a streamon if it is not set (and then we can
   remove the streamon from read_alloc())

So TL;DR: dev_read needs some love.

Regards,

Hans


p.s.

If you've time to work on v4l2 stuff what gspca really needs
is to just have its buffer handling ripped out and be rewritten
to use videobuf2. I would certainly love to see a patch for that.

--
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 6/7] [media] gspca: fix a v4l2-compliance failure during VIDIOC_REQBUFS

[Hans de Goede]

Hi,

On 09-03-16 17:03, Antonio Ospite wrote:

When calling VIDIOC_REQBUFS v4l2-compliance fails with this message:

   fail: v4l2-test-buffers.cpp(476): q.reqbufs(node, 1)
   test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL

By looking at the v4l2-compliance code the failure happens when trying
to request V4L2_MEMORY_USERPTR buffers without freeing explicitly the
previously allocated V4L2_MEMORY_MMAP buffers.

This would suggest that when changing the memory field in struct
v4l2_requestbuffers the driver is supposed to free automatically any
previous allocated buffers, and looking for inspiration at the code in
drivers/media/v4l2-core/videobuf2-core.c::vb2_core_reqbufs() seems to
confirm this interpretation; however gspca is just returning -EBUSY in
this case.

Removing the special handling for the case of a different memory value
fixes the compliance failure.

Signed-off-by: Antonio Ospite 
---

This should be safe, but I'd really like a comment from someone with a more
global knowledge of v4l2.

If my interpretation about how drivers should behave when the value of the
memory field changes is correct, I could send also a documentation update for
Documentation/DocBook/media/v4l/vidioc-reqbufs.xml

Just let me know.

Thanks,
Antonio


  drivers/media/usb/gspca/gspca.c | 7 ---
  1 file changed, 7 deletions(-)

diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index 84b0d6a..915b6c7 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -1402,13 +1402,6 @@ static int vidioc_reqbufs(struct file *file, void *priv,
if (mutex_lock_interruptible(_dev->queue_lock))
return -ERESTARTSYS;

-   if (gspca_dev->memory != GSPCA_MEMORY_NO
-   && gspca_dev->memory != GSPCA_MEMORY_READ
-   && gspca_dev->memory != rb->memory) {
-   ret = -EBUSY;
-   goto out;
-   }
-


reqbufs is used internally and this change will allow changing
gspca_dev->memory from USERPTR / MMAP to GSPCA_MEMORY_READ
please replace this check with a check to only allow
rb->memory to be GSPCA_MEMORY_READ when coming from GSPCA_MEMORY_NO
or GSPCA_MEMORY_READ

Regards,

Hans


/* only one file may do the capture */
if (gspca_dev->capt_file != NULL
&& gspca_dev->capt_file != file) {


--
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 0/2] [media] gspca_kinect: enable both video and depth streams

[Hans de Goede]

Hi Ulrik,

On 06-03-16 14:50, Ulrik de Muelenaere wrote:

Hello,

The Kinect produces both a video and depth stream, but the current 
implementation of the
gspca_kinect subdriver requires a depth_mode parameter at probe time to select 
one of
the streams which will be exposed as a v4l device. This patchset allows both 
streams to
be accessed as separate video nodes.

A possible solution which has been discussed in the past is to call 
gspca_dev_probe()
multiple times in order to create multiple video nodes. See the following mails:

http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/26194/focus=26213
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/76715/focus=78344

In the second mail linked above, it was mentioned that gspca_dev_probe() cannot 
be
called multiple times for the same USB interface, since gspca_dev_probe2() 
stores a
pointer to the new gspca_dev as the interface's private data. This is required 
for
gspca_disconnect(), gspca_suspend() and gspca_resume(). As far as I can tell, 
this is
the only reason gspca_dev_probe() cannot be called multiple times.

The first patch fixes this by storing other devices linked to the same 
interface as a
linked list. The second patch then calls gspca_dev_probe() twice in the 
gspca_kinect
subdriver, to create a video node for each stream.

Some notes on error handling, which I think should be reviewed:

* I could not test the gspca_suspend() and gspca_resume() functions. From my 
evaluation
   of the code, it seems that the only effect of returning an error code from
   gspca_resume() is that a message is logged. Therefore I decided to attempt 
to resume
   each gspca_dev when the interface is resumed, even if one fails. Bitwise OR 
seems
   like the best way to combine potentially multiple error codes.

* In the gspca_kinect subdriver, if the second call to gspca_dev_probe() fails, 
the
   first video node will still be available. I handle this case by calling
   gspca_disconnect(), which worked when I was testing, but I am not sure if 
this is the
   correct way to handle it.


Thanks for the patch-set overall I like it, one thing which worries is me is
that sd_start_video and sd_start_depth may race, which is esp. problematic
taking into account that both start/stop the depth stream (see the comment
about this in sd_start_video()) this will require some coordination,
so you like need to do something a bit more advanced and create a shared
data struct somewhere for coordination (and with a lock in it).

Likewise the v4l2 core is designed to have only one struct v4l2_device per
struct device, so you need to modify probe2 to not call
v4l2_device_register when it is called a second time for the same intf,
and to make gspca_dev->vdev.v4l2_dev point to the v4l2_dev of the
first gspca_dev registered.

You will also need some changes for this in gspca_disconnect, as you will
need to do all the calls on _dev->v4l2_dev only for the
first registered device there, and you will need to do all the
calls in gspca_release except for the v4l2_device_unregister() in
a loop like you're using in disconnect.

Note since you need a shared data struct anyways it might be easier to
just use that (add some shared pointer to struct gspca_dev) for the array
of gspca_devs rather then using the linked list, as for disconnect /
release you will want to use the first registered gspca_dev to get
the v4l2_dev address, and your linked approach gives you the last.

Regards,

Hans




Regards,
Ulrik

Ulrik de Muelenaere (2):
   [media] gspca: allow multiple probes per USB interface
   [media] gspca_kinect: enable both video and depth streams

  drivers/media/usb/gspca/gspca.c  | 129 +++
  drivers/media/usb/gspca/gspca.h  |   1 +
  drivers/media/usb/gspca/kinect.c |  28 +
  3 files changed, 91 insertions(+), 67 deletions(-)


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

Re: [PATCH 0/1] v4lconvert: Add "PEGATRON CORPORATION" to asus_board_vendor

[Hans de Goede]

Hans de Goede  redhat.com> writes:

> 
> Hi Gregor,
> 
> Here is a patch to add "PEGATRON CORPORATION" to asus_board_vendor,
> to fix an upside down bug reported to Fedora:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1311545
> 
> I'm not 100% sure this is a good idea, it might cause a bunch of false
> positives, but looking at the existing static PEGATRON entries in the
> v4l_control_flags list, it seems that it really is just another vendor
> string for Asus and that adding it to asus_board_vendor is best, so
> I'm say 95% sure :)
> 
> Anyways your input on this is much appreciated. In the mean time I'll
> kick of a scratch-build of the Fedora v4l-utils pkg with this patch
> applied for the reporter to test.

After sleeping a few days on this, I've decided that this is indeed
the best way to deal with this, and given that I've not had any comments
on the patch I've just pushed it to v4l-utils master
 
Regards,
 
Hans


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

Re: [PATCH] [media] rc: sunxi-cir: Initialize the spinlock properly

[Hans de Goede]

Hi,

On 22-12-15 05:27, Chen-Yu Tsai wrote:

The driver allocates the spinlock but fails to initialize it correctly.
The kernel reports a BUG indicating bad spinlock magic when spinlock
debugging is enabled.

Call spin_lock_init() on it to initialize it correctly.

Fixes: b4e3e59fb59c ("[media] rc: add sunxi-ir driver")
Signed-off-by: Chen-Yu Tsai <w...@csie.org>


Good catch:

Acked-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
  drivers/media/rc/sunxi-cir.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 7830aef3db45..40f77685cc4a 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -153,6 +153,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (!ir)
return -ENOMEM;

+   spin_lock_init(>ir_lock);
+
if (of_device_is_compatible(dn, "allwinner,sun5i-a13-ir"))
ir->fifo_size = 64;
else


--
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: sn9c20x: incorrect support for 0c45:6270 MT9V011/MT9V111 ?

[Hans de Goede]

Hi TJ,

On 12/18/2015 12:48 PM, TJ wrote:

I've been trying to get the 0c45:6270 Vehoh VMS-001 'Discovery' Microscope to 
work correctly and discovered what seem to be differences in the bridge_init 
and other control commands. The most obvious difference currently is the LEDs 
do not turn on, but there seem to be other problems with empty frames, 
bad/unrecognised formats, and resolutions, although vlc is able to render a 
usable JPEG stream.

I've installed the Windows XP Sonix driver package in a Qemu virtual machine 
guest and used wireshark on the host (Kubuntu 15.10, kernel v4.2) to capture 
and analyse the control commands.

https://iam.tj/projects/misc/usbmon-0c45-6270.pcapng

That seems to show the bridge_init, and possibly some of the i2c_init, byte 
sequences are different. It being the first time I've sniffed a USB driver 
though, I'm not yet 100% confident I'm identifying the correct starting point 
of the control command flow or the relationships between code and what is on 
the wire.

The Windows .inf seems to indicate the chipset is MT9V111:

%USBPCamDesc% = SN.USBPCam,USB\VID_0c45_6270 ; SN9C201 + MI0360\MT9V111

but the sn9c20x is matching as the MT9V011 (I've copied the module to a DKMS 
build location and named the clone sn9c20x_vehoh, matching only on 0c45_6270, 
to make testing easier):


Right, so it likely actually is an MT9V011, at least we are successfully 
reading the sensor-id,
and it has the id of an MT9V011, reading the id is more reliable then relying 
on the windows
inf file :)


  gspca_main: v2.14.0 registered
  gspca_main: sn9c20x_vehoh-2.14.0 probing 0c45:6270
  sn9c20x_vehoh: MT9V011 sensor detected
  sn9c20x_vehoh: MT9VPRB sensor detected
  input: sn9c20x_vehoh as 
/devices/pci:00/:00:1d.7/usb2/2-3/input/input34
  sn9c20x_vehoh 2-3:1.0: video1 created

I'd like to know the best way to add the correct command support in this 
situation where the existing Linux driver's control data is different to that 
in use by the Windows driver?


The best way I can think of to do this is to add a "#define SENSOR_MT9V011_ALT" 
to the list
of sensor defines which uses the correct init sequences for your cam, and add a 
module
option to override the sd->sensor value from the cmdline, so you would get 
something like
this in sd_config():

if (sensor_override != -1)
sd->sensor = sensor_override;
else
sd->sensor = id->driver_info >> 8;

And then you can set the sensor_override module option to SENSOR_MT9V011_ALT 
when loading
the module to work with your cam. I realize that this is not ideal, but I'm 
afraid it is
the best I can come up with, this at least will allow you to develop support 
for your cam,
once we have that we can see if we can find some way to autodetect it.

Regards,

Hans





Do I somehow create another profile in the driver, or directly modify the 
existing data and command sequences (this latter would seem to risk regressions 
for other users) ?

If creating another profile, how would they differentiate seeing as the device 
IDs are identical (I've not seen any sign of obvious version responses so far) ?

My first attempt to add the correct command values for controlling the LEDs 
failed, and seems to indicate that more than 1 command is sent to control the 
LEDs, unlike the sn9c20x driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH] m5602: correctly check failed thread creation

[Hans de Goede]

Hi,

On 19-10-15 17:24, Insu Yun wrote:

Since thread creation can be failed, check return value of
kthread_create and handle an error.

Signed-off-by: Insu Yun 
---
  drivers/media/usb/gspca/m5602/m5602_s5k83a.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/gspca/m5602/m5602_s5k83a.c 
b/drivers/media/usb/gspca/m5602/m5602_s5k83a.c
index bf6b215..76b40d1 100644
--- a/drivers/media/usb/gspca/m5602/m5602_s5k83a.c
+++ b/drivers/media/usb/gspca/m5602/m5602_s5k83a.c
@@ -221,6 +221,10 @@ int s5k83a_start(struct sd *sd)
   to assume that there is no better way of accomplishing this */
sd->rotation_thread = kthread_create(rotation_thread_function,
 sd, "rotation thread");
+   if (IS_ERR(sd->rotation_thread)) {
+   err = PTR_ERR(sd->rotation_thread);
+   goto fail;
+   }


There is no need to use a goto here you can simply directly return
the error.


wake_up_process(sd->rotation_thread);

/* Preinit the sensor */
@@ -234,9 +238,11 @@ int s5k83a_start(struct sd *sd)
data[0]);
}
if (err < 0)
-   return err;
+   goto fail;


No need for introducing a goto here either.



return s5k83a_set_led_indication(sd, 1);
+fail:
+   return err;
  }

  int s5k83a_stop(struct sd *sd)


Regards,

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

Re: [PATCH] gspca: correctly checked failed allocation

[Hans de Goede]

Hi,

On 19-10-15 18:43, Insu Yun wrote:

create_singlethread_workqueue can be failed in memory pressue.
So, check return value and return -ENOMEM

Signed-off-by: Insu Yun 
---
  drivers/media/usb/gspca/sq905.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/gspca/sq905.c b/drivers/media/usb/gspca/sq905.c
index a7ae0ec..b1c25d9a 100644
--- a/drivers/media/usb/gspca/sq905.c
+++ b/drivers/media/usb/gspca/sq905.c
@@ -392,6 +392,8 @@ static int sd_start(struct gspca_dev *gspca_dev)
}
/* Start the workqueue function to do the streaming */
dev->work_thread = create_singlethread_workqueue(MODULE_NAME);
+   if (!dev->work_thread)
+   return -ENOMEM;
queue_work(dev->work_thread, >work_struct);

return 0;


If the thread creation fails we should not send the start command,
so the create_singlethread_workqueue call should be moved
up in the function, while keeping the queue_work at the end.

And if the sq905_command fails then the workqueue should
be destroyed and dev->work_thread should be set to NULL
before returning the sq905_command failure to the caller.

Regards,

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

Re: [PATCH] [media] gspca: ov534/topro: prevent a division by 0

[Hans de Goede]

Hi,

On 02-10-15 22:33, Antonio Ospite wrote:

v4l2-compliance sends a zeroed struct v4l2_streamparm in
v4l2-test-formats.cpp::testParmType(), and this results in a division by
0 in some gspca subdrivers:

   divide error:  [#1] SMP
   Modules linked in: gspca_ov534 gspca_main ...
   CPU: 0 PID: 17201 Comm: v4l2-compliance Not tainted 4.3.0-rc2-ao2 #1
   Hardware name: System manufacturer System Product Name/M2N-E SLI, BIOS
 ASUS M2N-E SLI ACPI BIOS Revision 1301 09/16/2010
   task: 8800818306c0 ti: 880095c4c000 task.ti: 880095c4c000
   RIP: 0010:[]  [] 
sd_set_streamparm+0x12/0x60 [gspca_ov534]
   RSP: 0018:880095c4fce8  EFLAGS: 00010296
   RAX:  RBX: 8800c9522000 RCX: a077a140
   RDX:  RSI: 880095e0c100 RDI: 8800c9522000
   RBP: 880095e0c100 R08: a077a100 R09: 00cc
   R10: 880067ec7740 R11: 0016 R12: a07bb400
   R13:  R14: 880081b6a800 R15: 
   FS:  7fda0de78740() GS:88012fc0() knlGS:
   CS:  0010 DS:  ES:  CR0: 80050033
   CR2: 014630f8 CR3: cf349000 CR4: 06f0
   Stack:
a07a6431 8800c9522000 a077656e c0cc5616
8800c9522000 a07a5e20 880095e0c100 
880067ec7740 a077a140 880067ec7740 0016
   Call Trace:
[] ? v4l_s_parm+0x21/0x50 [videodev]
[] ? vidioc_s_parm+0x4e/0x60 [gspca_main]
[] ? __video_do_ioctl+0x280/0x2f0 [videodev]
[] ? video_ioctl2+0x20/0x20 [videodev]
[] ? video_usercopy+0x319/0x4e0 [videodev]
[] ? page_add_new_anon_rmap+0x71/0xa0
[] ? mem_cgroup_commit_charge+0x52/0x90
[] ? handle_mm_fault+0xc18/0x1680
[] ? v4l2_ioctl+0xac/0xd0 [videodev]
[] ? do_vfs_ioctl+0x28f/0x480
[] ? SyS_ioctl+0x74/0x80
[] ? entry_SYSCALL_64_fastpath+0x16/0x75
   Code: c7 93 d9 79 a0 5b 5d e9 f1 f3 9a e0 0f 1f 00 66 2e 0f 1f 84 00
 00 00 00 00 66 66 66 66 90 53 31 d2 48 89 fb 48 83 ec 08 8b 46 10 
 76 0c 80 bf ac 0c 00 00 00 88 87 4e 0e 00 00 74 09 80 bf 4f
   RIP  [] sd_set_streamparm+0x12/0x60 [gspca_ov534]
RSP 
   ---[ end trace 279710c2c6c72080 ]---

Following what the doc says about a zeroed timeperframe (see
http://www.linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-parm.html):

   ...
   To reset manually applications can just set this field to zero.

fix the issue by resetting the frame rate to a default value in case of
an unusable timeperframe.

The fix is done in the subdrivers instead of gspca.c because only the
subdrivers have notion of a default frame rate to reset the camera to.

Signed-off-by: Antonio Ospite <a...@ao2.it>
Cc: sta...@vger.kernel.org


Good catch:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Mauro can you pick this one up directly, and include it in your
next pull-req for 4.3 please ?

Regards,

Hans



---

Hi,

I think the problem in the gspca subdrivers has always been there, so the
patch could be applied to any relevant stable releases.

After the fix, v4l2-compliance runs fine but it gets two failures, I'll send
another mail about those.

After this change gets merged I will also send a patch to use defines for the
default framerates used below as the same value is used in multiple places.

Ah, I ran the patch through scripts/checkpatch.pl from 4.3-rc2 and it
complained about the commit message but I think it may be a false positive.

Ciao ciao,
Antonio


  drivers/media/usb/gspca/ov534.c | 9 +++--
  drivers/media/usb/gspca/topro.c | 6 +-
  2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/gspca/ov534.c b/drivers/media/usb/gspca/ov534.c
index 146071b..bfff1d1 100644
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -1491,8 +1491,13 @@ static void sd_set_streamparm(struct gspca_dev 
*gspca_dev,
struct v4l2_fract *tpf = >timeperframe;
struct sd *sd = (struct sd *) gspca_dev;

-   /* Set requested framerate */
-   sd->frame_rate = tpf->denominator / tpf->numerator;
+   if (tpf->numerator == 0 || tpf->denominator == 0)
+   /* Set default framerate */
+   sd->frame_rate = 30;
+   else
+   /* Set requested framerate */
+   sd->frame_rate = tpf->denominator / tpf->numerator;
+
if (gspca_dev->streaming)
set_frame_rate(gspca_dev);

diff --git a/drivers/media/usb/gspca/topro.c b/drivers/media/usb/gspca/topro.c
index c70ff40..c028a5c 100644
--- a/drivers/media/usb/gspca/topro.c
+++ b/drivers/media/usb/gspca/topro.c
@@ -4802,7 +4802,11 @@ static void sd_set_streamparm(struct gspca_dev 
*gspca_dev,
struct v4l2_fract *tpf = >timeperframe;
int fr, i;

-   sd->framerate = tpf->denominator / tpf->numerator;
+   if (tpf->numerator == 0 || tpf->den

Re: [PATCH v1] media: uvcvideo: handle urb completion in a work queue

[Hans de Goede]

Hi,

On 08-09-15 16:36, Alan Stern wrote:

On Tue, 8 Sep 2015, Hans de Goede wrote:


Hi,

On 09/07/2015 06:23 PM, Mian Yousaf Kaukab wrote:

urb completion callback is executed in host controllers interrupt
context. To keep preempt disable time short, add urbs to a list on
completion and schedule work to process the list.

Moreover, save timestamp and sof number in the urb completion callback
to avoid any delays.


Erm, I thought that we had already moved to using threaded interrupt
handling for the urb completion a while (1-2 years ?) back. Is this then
still needed ?


We moved to handling URB completions in a tasklet, not a threaded
handler.


Right.


(Similar idea, though.)  And the change was made in only one
or two HCDs, not in all of them.


Ah, I was under the impression this was a core change, not a per
hcd change.

Regards,

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

Re: [PATCH v1] media: uvcvideo: handle urb completion in a work queue

[Hans de Goede]

Hi,

On 09/07/2015 06:23 PM, Mian Yousaf Kaukab wrote:

urb completion callback is executed in host controllers interrupt
context. To keep preempt disable time short, add urbs to a list on
completion and schedule work to process the list.

Moreover, save timestamp and sof number in the urb completion callback
to avoid any delays.


Erm, I thought that we had already moved to using threaded interrupt
handling for the urb completion a while (1-2 years ?) back. Is this then
still needed ?

Regards,

Hans




Signed-off-by: Mian Yousaf Kaukab 
---
History:
v1:
  - Use global work queue instead of creating ordered queue.
  - Add completed urbs to a list and process all on the list when work
is scheduled
  - Save timestamp and sof number in urb completion callback and use
in uvc_video_clock_decode() and uvc_video_decode_start()
  - Fix race between usb_submit_urb() from uvc_video_complete() and
usb_kill_urb() from uvc_uninit_video()

  drivers/media/usb/uvc/uvc_isight.c |   3 +-
  drivers/media/usb/uvc/uvc_video.c  | 132 +++--
  drivers/media/usb/uvc/uvcvideo.h   |  17 -
  3 files changed, 113 insertions(+), 39 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_isight.c 
b/drivers/media/usb/uvc/uvc_isight.c
index 8510e725..7f93d09 100644
--- a/drivers/media/usb/uvc/uvc_isight.c
+++ b/drivers/media/usb/uvc/uvc_isight.c
@@ -99,9 +99,10 @@ static int isight_decode(struct uvc_video_queue *queue, 
struct uvc_buffer *buf,
return 0;
  }

-void uvc_video_decode_isight(struct urb *urb, struct uvc_streaming *stream,
+void uvc_video_decode_isight(struct uvc_urb *uu, struct uvc_streaming *stream,
struct uvc_buffer *buf)
  {
+   struct urb *urb = uu->urb;
int ret, i;

for (i = 0; i < urb->number_of_packets; ++i) {
diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index f839654..71354ec 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -379,15 +379,14 @@ static inline void uvc_video_get_ts(struct timespec *ts)

  static void
  uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
-  const __u8 *data, int len)
+  const __u8 *data, int len, u16 host_sof,
+  struct timespec *ts)
  {
struct uvc_clock_sample *sample;
unsigned int header_size;
bool has_pts = false;
bool has_scr = false;
unsigned long flags;
-   struct timespec ts;
-   u16 host_sof;
u16 dev_sof;

switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
@@ -435,9 +434,6 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct 
uvc_buffer *buf,

stream->clock.last_sof = dev_sof;

-   host_sof = usb_get_current_frame_number(stream->dev->udev);
-   uvc_video_get_ts();
-
/* The UVC specification allows device implementations that can't obtain
 * the USB frame number to keep their own frame counters as long as they
 * match the size and frequency of the frame number associated with USB
@@ -473,7 +469,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct 
uvc_buffer *buf,
sample->dev_stc = get_unaligned_le32([header_size - 6]);
sample->dev_sof = dev_sof;
sample->host_sof = host_sof;
-   sample->host_ts = ts;
+   sample->host_ts = *ts;

/* Update the sliding window head and count. */
stream->clock.head = (stream->clock.head + 1) % stream->clock.size;
@@ -964,7 +960,8 @@ static void uvc_video_stats_stop(struct uvc_streaming 
*stream)
   * uvc_video_decode_end will never be called with a NULL buffer.
   */
  static int uvc_video_decode_start(struct uvc_streaming *stream,
-   struct uvc_buffer *buf, const __u8 *data, int len)
+   struct uvc_buffer *buf, const __u8 *data, int len,
+   u16 host_sof, struct timespec *ts)
  {
__u8 fid;

@@ -989,7 +986,7 @@ static int uvc_video_decode_start(struct uvc_streaming 
*stream,
uvc_video_stats_update(stream);
}

-   uvc_video_clock_decode(stream, buf, data, len);
+   uvc_video_clock_decode(stream, buf, data, len, host_sof, ts);
uvc_video_stats_decode(stream, data, len);

/* Store the payload FID bit and return immediately when the buffer is
@@ -1016,8 +1013,6 @@ static int uvc_video_decode_start(struct uvc_streaming 
*stream,
 * when the EOF bit is set to force synchronisation on the next packet.
 */
if (buf->state != UVC_BUF_STATE_ACTIVE) {
-   struct timespec ts;
-
if (fid == stream->last_fid) {
uvc_trace(UVC_TRACE_FRAME, "Dropping payload (out of "
"sync).\n");
@@ -1027,13 +1022,11 @@ static int uvc_video_decode_start(struct uvc_streaming 
*stream,
return -ENODATA;
   

[PULL fixes for 4.3]: gspca minor fixes

[Hans de Goede]

Hi Mauro,

Here are 2 minor fixes for gspca for 4.3.

The following changes since commit 77a3c6fd90c94f635edb00d4a65f485687538791:

  [media] vb2: Don't WARN when v4l2_buffer.bytesused is 0 for multiplanar 
buffers (2015-06-22 09:52:58 -0300)

are available in the git repository at:

  git://linuxtv.org/hgoede/gspca.git media-for_v4.3

for you to fetch changes up to 08cf79c93ec8568738b8e7db5e63278e43721850:

  gscpa_m5602: use msecs_to_jiffies for conversions (2015-06-23 11:50:27 +0200)


Dan Carpenter (1):
  gspca: sn9c2028: remove an unneeded condition

Nicholas Mc Guire (1):
  gscpa_m5602: use msecs_to_jiffies for conversions

 drivers/media/usb/gspca/m5602/m5602_s5k83a.c | 2 +-
 drivers/media/usb/gspca/sn9c2028.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Thanks  Regards,

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

Re: [PATCH] [media] gscpa_m5602: use msecs_to_jiffies for conversions

[Hans de Goede]

Hi,

On 07-06-15 16:34, Nicholas Mc Guire wrote:

API compliance scanning with coccinelle flagged:
./drivers/media/usb/gspca/m5602/m5602_s5k83a.c:180:9-25:
 WARNING: timeout (100) seems HZ dependent

Numeric constants passed to schedule_timeout() make the effective
timeout HZ dependent which makes little sense in a polling loop for
the cameras rotation state.
Fixed up by converting the constant to jiffies with msecs_to_jiffies()

Signed-off-by: Nicholas Mc Guire hof...@osadl.org


Thanks I've queued this up for merging into 4.3

Regards,

Hans



---

Patch was compile tested with i386_defconfig +

Patch is against 4.1-rc6 (localversion-next is -next-20150605)

  drivers/media/usb/gspca/m5602/m5602_s5k83a.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/gspca/m5602/m5602_s5k83a.c 
b/drivers/media/usb/gspca/m5602/m5602_s5k83a.c
index 7cbc3a0..bf6b215 100644
--- a/drivers/media/usb/gspca/m5602/m5602_s5k83a.c
+++ b/drivers/media/usb/gspca/m5602/m5602_s5k83a.c
@@ -177,7 +177,7 @@ static int rotation_thread_function(void *data)
__s32 vflip, hflip;

set_current_state(TASK_INTERRUPTIBLE);
-   while (!schedule_timeout(100)) {
+   while (!schedule_timeout(msecs_to_jiffies(100))) {
if (mutex_lock_interruptible(sd-gspca_dev.usb_lock))
break;



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

Re: [patch] [media] gspca: sn9c2028: remove an unneeded condition

[Hans de Goede]

Hi,

On 04-06-15 10:52, Dan Carpenter wrote:

We already know status is negative because of the earlier check so there
is no need to check again.

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com


Makes sense:

Acked-by: Hans de Goede hdego...@redhat.com

Mauro, can you pick this one up directly please?

Regards,

Hans




diff --git a/drivers/media/usb/gspca/sn9c2028.c 
b/drivers/media/usb/gspca/sn9c2028.c
index c75b738..4f2050a 100644
--- a/drivers/media/usb/gspca/sn9c2028.c
+++ b/drivers/media/usb/gspca/sn9c2028.c
@@ -140,7 +140,7 @@ static int sn9c2028_long_command(struct gspca_dev 
*gspca_dev, u8 *command)
status = sn9c2028_read1(gspca_dev);
if (status  0) {
pr_err(long command status read error %d\n, status);
-   return (status  0) ? status : -EIO;
+   return status;
}

memset(reading, 0, 4);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

[PULL patches for 4.2]: New camera support for gspca sn9c2028 driver (v2)

[Hans de Goede]

Hi Mauro,

Here is a new pull-req for the new camera support for the gspca sn9c2028 
driver, now with
my S-o-b added and the copyright change dropped.

The following changes since commit 2a80f296422a01178d0a993479369e94f5830127:

  [media] dvb-core: fix 32-bit overflow during bandwidth calculation 
(2015-05-20 14:01:46 -0300)

are available in the git repository at:

  git://linuxtv.org/hgoede/gspca.git media-for_v4.2

for you to fetch changes up to b4ede115fd1a37714e05e1180c399169e0e8d680:

  gspca: sn9c2028: Add gain and autogain controls Genius Videocam Live v2 
(2015-05-20 19:47:11 +0200)


Vasily Khoruzhick (2):
  gspca: sn9c2028: Add support for Genius Videocam Live v2
  gspca: sn9c2028: Add gain and autogain controls Genius Videocam Live v2

 drivers/media/usb/gspca/sn9c2028.c | 241 -
 drivers/media/usb/gspca/sn9c2028.h |  18 ++-
 2 files changed, 255 insertions(+), 4 deletions(-)

Thanks  Regards,

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

Re: [PATCH v2 1/2] gspca: sn9c2028: Add support for Genius Videocam Live v2

[Hans de Goede]

Hi,

On 20-05-15 14:12, Mauro Carvalho Chehab wrote:

Em Fri, 24 Apr 2015 10:04:03 +0300
Vasily Khoruzhick anars...@gmail.com escreveu:


This cam seems to return different values on long commands, so make status check
in sn9c2028_long_command() more tolerant. Anyway, read value isn't used anywhere
later.

Signed-off-by: Vasily Khoruzhick anars...@gmail.com


Hans,

You forgot to add your SOB on those two patches on your pull request.


Weird I always use git am -s, ah well. I'll send a new pull-req fixing this.

Regards,

Hans





---
v2: update commit message to explain change in sn9c2028_long_command()

  drivers/media/usb/gspca/sn9c2028.c | 120 -
  1 file changed, 119 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/gspca/sn9c2028.c 
b/drivers/media/usb/gspca/sn9c2028.c
index 39b6b2e..317b02c 100644
--- a/drivers/media/usb/gspca/sn9c2028.c
+++ b/drivers/media/usb/gspca/sn9c2028.c
@@ -2,6 +2,7 @@
   * SN9C2028 library
   *
   * Copyright (C) 2009 Theodore Kilgore kilg...@auburn.edu
+ * Copyright (C) 2015 Vasily Khoruzhick anars...@gmail.com


Hmm... adding a new copyright driver-wide only justifies if you changed 30%
or more of the code. The copyright of your changes will be preserved at
the git history.


   *
   * This program is free software; you can redistribute it and/or modify
   * it under the terms of the GNU General Public License as published by
@@ -128,7 +129,7 @@ static int sn9c2028_long_command(struct gspca_dev 
*gspca_dev, u8 *command)
status = -1;
for (i = 0; i  256  status  2; i++)
status = sn9c2028_read1(gspca_dev);
-   if (status != 2) {
+   if (status  0) {
pr_err(long command status read error %d\n, status);
return (status  0) ? status : -EIO;
}
@@ -178,6 +179,9 @@ static int sd_config(struct gspca_dev *gspca_dev,
case 0x7005:
PDEBUG(D_PROBE, Genius Smart 300 camera);
break;
+   case 0x7003:
+   PDEBUG(D_PROBE, Genius Videocam Live v2);
+   break;
case 0x8000:
PDEBUG(D_PROBE, DC31VC);
break;
@@ -530,6 +534,116 @@ static int start_genius_cam(struct gspca_dev *gspca_dev)
  ARRAY_SIZE(genius_start_commands));
  }

+static int start_genius_videocam_live(struct gspca_dev *gspca_dev)
+{
+   int r;
+   struct sd *sd = (struct sd *) gspca_dev;
+   struct init_command genius_vcam_live_start_commands[] = {
+   {{0x0c, 0x01, 0x00, 0x00, 0x00, 0x00}, 0},
+   {{0x16, 0x01, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x10, 0x00, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+   {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+
+   {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+   {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+   {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+   {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+   {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+   {{0x11, 0x20, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x21, 0x2d, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x22, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x23, 0x03, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x10, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x11, 0x64, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x12, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x13, 0x91, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x14, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x15, 0x20, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x16, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x17, 0x60, 0x00, 0x00, 0x00}, 4},
+   {{0x1c, 0x20, 0x00, 0x2d, 0x00, 0x00}, 4},
+   {{0x13, 0x20, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x21, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x22, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x23, 0x01, 0x01, 0x00, 0x00}, 4},
+   {{0x13, 0x24, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+   {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+   {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+   {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+   {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+   {{0x13, 0x2a, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x2b, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+   {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+   {{0x12, 0x34, 0x01, 

[PULL patches for 4.2]: New camera support for gspca sn9c2028 driver

[Hans de Goede]

Hi Mauro,

Please pull from my tree for new camera support for the gspca sn9c2028 driver.

The following changes since commit 0fae1997f09796aca8ada5edc028aef587f6716c:

  [media] dib0700: avoid the risk of forgetting to add the adapter's size 
(2015-05-14 19:31:34 -0300)

are available in the git repository at:

  git://linuxtv.org/hgoede/gspca.git media-for_v4.2

for you to fetch changes up to ddf065746e4dc97ffc974ceeb031825164e6f39f:

  gspca: sn9c2028: Add gain and autogain controls Genius Videocam Live v2 
(2015-05-18 14:23:56 +0200)


Vasily Khoruzhick (2):
  gspca: sn9c2028: Add support for Genius Videocam Live v2
  gspca: sn9c2028: Add gain and autogain controls Genius Videocam Live v2

 drivers/media/usb/gspca/sn9c2028.c | 242 -
 drivers/media/usb/gspca/sn9c2028.h |  18 ++-
 2 files changed, 256 insertions(+), 4 deletions(-)

Thanks  Regards,

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

Re: [PATCH v2 1/2] gspca: sn9c2028: Add support for Genius Videocam Live v2

[Hans de Goede]

Hi Vasily

On 15-05-15 17:55, Vasily Khoruzhick wrote:

Ping?


Sorry for being a bit slow on this one, v2 looks good. I'll queue it up for
merging into 4.2 as soon as I find some time to work on this,

Regards,

Hans



On Fri, Apr 24, 2015 at 10:04 AM, Vasily Khoruzhick anars...@gmail.com wrote:

This cam seems to return different values on long commands, so make status check
in sn9c2028_long_command() more tolerant. Anyway, read value isn't used anywhere
later.

Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
v2: update commit message to explain change in sn9c2028_long_command()

  drivers/media/usb/gspca/sn9c2028.c | 120 -
  1 file changed, 119 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/gspca/sn9c2028.c 
b/drivers/media/usb/gspca/sn9c2028.c
index 39b6b2e..317b02c 100644
--- a/drivers/media/usb/gspca/sn9c2028.c
+++ b/drivers/media/usb/gspca/sn9c2028.c
@@ -2,6 +2,7 @@
   * SN9C2028 library
   *
   * Copyright (C) 2009 Theodore Kilgore kilg...@auburn.edu
+ * Copyright (C) 2015 Vasily Khoruzhick anars...@gmail.com
   *
   * This program is free software; you can redistribute it and/or modify
   * it under the terms of the GNU General Public License as published by
@@ -128,7 +129,7 @@ static int sn9c2028_long_command(struct gspca_dev 
*gspca_dev, u8 *command)
 status = -1;
 for (i = 0; i  256  status  2; i++)
 status = sn9c2028_read1(gspca_dev);
-   if (status != 2) {
+   if (status  0) {
 pr_err(long command status read error %d\n, status);
 return (status  0) ? status : -EIO;
 }
@@ -178,6 +179,9 @@ static int sd_config(struct gspca_dev *gspca_dev,
 case 0x7005:
 PDEBUG(D_PROBE, Genius Smart 300 camera);
 break;
+   case 0x7003:
+   PDEBUG(D_PROBE, Genius Videocam Live v2);
+   break;
 case 0x8000:
 PDEBUG(D_PROBE, DC31VC);
 break;
@@ -530,6 +534,116 @@ static int start_genius_cam(struct gspca_dev *gspca_dev)
   ARRAY_SIZE(genius_start_commands));
  }

+static int start_genius_videocam_live(struct gspca_dev *gspca_dev)
+{
+   int r;
+   struct sd *sd = (struct sd *) gspca_dev;
+   struct init_command genius_vcam_live_start_commands[] = {
+   {{0x0c, 0x01, 0x00, 0x00, 0x00, 0x00}, 0},
+   {{0x16, 0x01, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x10, 0x00, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+   {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+
+   {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+   {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+   {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+   {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+   {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+   {{0x11, 0x20, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x21, 0x2d, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x22, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x23, 0x03, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x10, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x11, 0x64, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x12, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x13, 0x91, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x14, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x15, 0x20, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x16, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x17, 0x60, 0x00, 0x00, 0x00}, 4},
+   {{0x1c, 0x20, 0x00, 0x2d, 0x00, 0x00}, 4},
+   {{0x13, 0x20, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x21, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x22, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x23, 0x01, 0x01, 0x00, 0x00}, 4},
+   {{0x13, 0x24, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+   {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+   {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+   {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+   {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+   {{0x13, 0x2a, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x2b, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+   {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+   {{0x12, 0x34, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x34, 0x01, 0xa1, 0x00, 0x00}, 4},
+   {{0x13, 0x35, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x01, 

Re: [PATCHv3 0/4] add devm_of_phy_get_by_index and update platform drivers

[Hans de Goede]

Hi,

On 23-04-15 01:04, Arun Ramamurthy wrote:

This patch set adds a new API to get phy by index when multiple
phys are present. This patch is based on discussion with Arnd Bergmann
about dt bindings for multiple phys.

History:
v1:
 - Removed null pointers on Dmitry's suggestion
 - Improved documentation in commit messages
 - Exported new phy api
v2:
 - EHCI and OHCI platform Kconfigs select Generic Phy
   to fix build errors in certain configs.
v3:
 - Made GENERIC_PHY an invisible option so
 that other configs can select it
 - Added stubs for devm_of_phy_get_by_index
 - Reformated code

Arun Ramamurthy (4):
   phy: phy-core: Make GENERIC_PHY an invisible option
   phy: core: Add devm_of_phy_get_by_index to phy-core
   usb: ehci-platform: Use devm_of_phy_get_by_index
   usb: ohci-platform: Use devm_of_phy_get_by_index

  Documentation/phy.txt |  7 +++-
  drivers/ata/Kconfig   |  1 -
  drivers/media/platform/exynos4-is/Kconfig |  2 +-
  drivers/phy/Kconfig   |  4 +-
  drivers/phy/phy-core.c| 32 ++
  drivers/usb/host/Kconfig  |  4 +-
  drivers/usb/host/ehci-platform.c  | 69 +++
  drivers/usb/host/ohci-platform.c  | 69 +++
  drivers/video/fbdev/exynos/Kconfig|  2 +-
  include/linux/phy/phy.h   |  8 
  10 files changed, 100 insertions(+), 98 deletions(-)



Patch set looks good to me:

Acked-by: Hans de Goede hdego...@redhat.com

Regards,

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

Re: [PATCH 1/2] gspca: sn9c2028: Add support for Genius Videocam Live v2

[Hans de Goede]

Hi Vasily,

Thanks for the patches.

On 19-04-15 20:52, Vasily Khoruzhick wrote:

Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
  drivers/media/usb/gspca/sn9c2028.c | 120 -
  1 file changed, 119 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/gspca/sn9c2028.c 
b/drivers/media/usb/gspca/sn9c2028.c
index 39b6b2e..317b02c 100644
--- a/drivers/media/usb/gspca/sn9c2028.c
+++ b/drivers/media/usb/gspca/sn9c2028.c
@@ -2,6 +2,7 @@
   * SN9C2028 library
   *
   * Copyright (C) 2009 Theodore Kilgore kilg...@auburn.edu
+ * Copyright (C) 2015 Vasily Khoruzhick anars...@gmail.com
   *
   * This program is free software; you can redistribute it and/or modify
   * it under the terms of the GNU General Public License as published by
@@ -128,7 +129,7 @@ static int sn9c2028_long_command(struct gspca_dev 
*gspca_dev, u8 *command)
status = -1;
for (i = 0; i  256  status  2; i++)
status = sn9c2028_read1(gspca_dev);
-   if (status != 2) {
+   if (status  0) {
pr_err(long command status read error %d\n, status);
return (status  0) ? status : -EIO;
}


Do you really need this change ? sn9c2028_read1 returns either a negative
error code, or the byte read from the sn9c2028 chip. This functions wait for
the sn9c2028 to return a read value of 2. I admit that the check in the for
vs the check in the error reporting is not chosen well, both should probably
be != 2. But checking for status  0 is not good as this does not catch
a successful read from the chip not returning 2.


@@ -178,6 +179,9 @@ static int sd_config(struct gspca_dev *gspca_dev,
case 0x7005:
PDEBUG(D_PROBE, Genius Smart 300 camera);
break;
+   case 0x7003:
+   PDEBUG(D_PROBE, Genius Videocam Live v2);
+   break;
case 0x8000:
PDEBUG(D_PROBE, DC31VC);
break;
@@ -530,6 +534,116 @@ static int start_genius_cam(struct gspca_dev *gspca_dev)
  ARRAY_SIZE(genius_start_commands));
  }

+static int start_genius_videocam_live(struct gspca_dev *gspca_dev)
+{
+   int r;
+   struct sd *sd = (struct sd *) gspca_dev;
+   struct init_command genius_vcam_live_start_commands[] = {
+   {{0x0c, 0x01, 0x00, 0x00, 0x00, 0x00}, 0},
+   {{0x16, 0x01, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x10, 0x00, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+   {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+
+   {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+   {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+   {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+   {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+   {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+   {{0x11, 0x20, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x21, 0x2d, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x22, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x23, 0x03, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x10, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x11, 0x64, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x12, 0x00, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x13, 0x91, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x14, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x15, 0x20, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x16, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x17, 0x60, 0x00, 0x00, 0x00}, 4},
+   {{0x1c, 0x20, 0x00, 0x2d, 0x00, 0x00}, 4},
+   {{0x13, 0x20, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x21, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x22, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x23, 0x01, 0x01, 0x00, 0x00}, 4},
+   {{0x13, 0x24, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+   {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+   {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+   {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+   {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+   {{0x13, 0x2a, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x2b, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+   {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+   {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+   {{0x12, 0x34, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x13, 0x34, 0x01, 0xa1, 0x00, 0x00}, 4},
+   {{0x13, 0x35, 0x01, 0x00, 0x00, 0x00}, 4},
+   {{0x11, 0x01, 0x04, 0x00, 0x00, 0x00}, 4},
+   

Re: [PATCH 2/2] gspca: sn9c2028: Add gain and autogain controls Genius Videocam Live v2

[Hans de Goede]

Hi,

On 19-04-15 20:52, Vasily Khoruzhick wrote:

Autogain algorithm is very simple, if average luminance is low - increase gain,
if it's high - decrease gain. Gain granularity is low enough for this algo to
stabilize quickly.

Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
  drivers/media/usb/gspca/sn9c2028.c | 121 +
  drivers/media/usb/gspca/sn9c2028.h |  20 +-
  2 files changed, 138 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/gspca/sn9c2028.c 
b/drivers/media/usb/gspca/sn9c2028.c
index 317b02c..0ff390f 100644
--- a/drivers/media/usb/gspca/sn9c2028.c
+++ b/drivers/media/usb/gspca/sn9c2028.c
@@ -34,6 +34,16 @@ struct sd {
struct gspca_dev gspca_dev;  /* !! must be the first item */
u8 sof_read;
u16 model;
+
+#define MIN_AVG_LUM 8500
+#define MAX_AVG_LUM 1
+   int avg_lum;
+   u8 avg_lum_l;
+
+   struct { /* autogain and gain control cluster */
+   struct v4l2_ctrl *autogain;
+   struct v4l2_ctrl *gain;
+   };
  };

  struct init_command {
@@ -252,6 +262,77 @@ static int run_start_commands(struct gspca_dev *gspca_dev,
return 0;
  }

+static void set_gain(struct gspca_dev *gspca_dev, s32 g)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+
+   struct init_command genius_vcam_live_gain_cmds[] = {
+   {{0x1d, 0x25, 0x10, 0x20, 0xab, 0x00}, 0},
+   };
+   if (!gspca_dev-streaming)
+   return;
+
+   switch (sd-model) {
+   case 0x7003:
+   genius_vcam_live_gain_cmds[0].instruction[2] = g;
+   run_start_commands(gspca_dev, genius_vcam_live_gain_cmds,
+  ARRAY_SIZE(genius_vcam_live_gain_cmds));
+   break;
+   default:
+   break;
+   }
+}
+
+static int sd_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct gspca_dev *gspca_dev =
+   container_of(ctrl-handler, struct gspca_dev, ctrl_handler);
+   struct sd *sd = (struct sd *)gspca_dev;
+
+   gspca_dev-usb_err = 0;
+
+   if (!gspca_dev-streaming)
+   return 0;
+
+   switch (ctrl-id) {
+   /* standalone gain control */
+   case V4L2_CID_GAIN:
+   set_gain(gspca_dev, ctrl-val);
+   break;
+   /* autogain */
+   case V4L2_CID_AUTOGAIN:
+   set_gain(gspca_dev, sd-gain-val);
+   break;
+   }
+   return gspca_dev-usb_err;
+}
+
+static const struct v4l2_ctrl_ops sd_ctrl_ops = {
+   .s_ctrl = sd_s_ctrl,
+};
+
+
+static int sd_init_controls(struct gspca_dev *gspca_dev)
+{
+   struct v4l2_ctrl_handler *hdl = gspca_dev-ctrl_handler;
+   struct sd *sd = (struct sd *)gspca_dev;
+
+   gspca_dev-vdev.ctrl_handler = hdl;
+   v4l2_ctrl_handler_init(hdl, 2);
+
+   switch (sd-model) {
+   case 0x7003:
+   sd-gain = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
+   V4L2_CID_GAIN, 0, 20, 1, 0);
+   sd-autogain = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
+   V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
  static int start_spy_cam(struct gspca_dev *gspca_dev)
  {
struct init_command spy_start_commands[] = {
@@ -641,6 +722,9 @@ static int start_genius_videocam_live(struct gspca_dev 
*gspca_dev)
if (r  0)
return r;

+   if (sd-gain)
+   set_gain(gspca_dev, v4l2_ctrl_g_ctrl(sd-gain));
+
return r;
  }

@@ -757,6 +841,8 @@ static int sd_start(struct gspca_dev *gspca_dev)
return -ENXIO;
}

+   sd-avg_lum = -1;
+
return err_code;
  }

@@ -776,6 +862,39 @@ static void sd_stopN(struct gspca_dev *gspca_dev)
PERR(Camera Stop command failed);
  }

+static void do_autogain(struct gspca_dev *gspca_dev, int avg_lum)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+   s32 cur_gain = v4l2_ctrl_g_ctrl(sd-gain);
+
+   if (avg_lum == -1)
+   return;
+
+   if (avg_lum  MIN_AVG_LUM) {
+   if (cur_gain == sd-gain-maximum)
+   return;
+   cur_gain++;
+   v4l2_ctrl_s_ctrl(sd-gain, cur_gain);
+   }
+   if (avg_lum  MAX_AVG_LUM) {
+   if (cur_gain == sd-gain-minimum)
+   return;
+   cur_gain--;
+   v4l2_ctrl_s_ctrl(sd-gain, cur_gain);
+   }
+
+}
+
+static void sd_dqcallback(struct gspca_dev *gspca_dev)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+
+   if (sd-autogain == NULL || !v4l2_ctrl_g_ctrl(sd-autogain))
+   return;
+
+   do_autogain(gspca_dev, sd-avg_lum);
+}
+
  /* Include sn9c2028 sof detection functions */
  #include sn9c2028.h

@@ -810,8 +929,10 @@ static const struct sd_desc sd_desc = {
.name = MODULE_NAME,
.config = sd_config,
.init = sd_init,
+   

Re: [PATCH] libv4lconvert: Fix support for Y16 pixel format

[Hans de Goede]

Hi,

On 26-03-15 17:17, Ricardo Ribalda Delgado wrote:

Y16 is a little-endian format. The original implementation assumed that
it was big-endian.

Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com


Thanks merged upstream, both into master and stable-1.6 branches.

Regards,

Hans


---
  lib/libv4lconvert/rgbyuv.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/lib/libv4lconvert/rgbyuv.c b/lib/libv4lconvert/rgbyuv.c
index 0f30192..75c42aa 100644
--- a/lib/libv4lconvert/rgbyuv.c
+++ b/lib/libv4lconvert/rgbyuv.c
@@ -591,6 +591,9 @@ void v4lconvert_y16_to_rgb24(const unsigned char *src, 
unsigned char *dest,
int width, int height)
  {
int j;
+
+   src++; /*Y16 is little endian*/
+
while (--height = 0) {
for (j = 0; j  width; j++) {
*dest++ = *src;
@@ -606,6 +609,8 @@ void v4lconvert_y16_to_yuv420(const unsigned char *src, 
unsigned char *dest,
  {
int x, y;

+   src++; /*Y16 is little endian*/
+
/* Y */
for (y = 0; y  src_fmt-fmt.pix.height; y++)
for (x = 0; x  src_fmt-fmt.pix.width; x++){


--
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] add Android makefile for libv4l2 and libv4lconvert

[Hans de Goede]

Hi,

On 27-03-15 09:29, Benjamin Gaignard wrote:

Hello,

On behalf of Paramanand, I would have to have your opinion on this patch.
The goal is to enable more v4l2 lib features on Android to be able to
do video decoding using v4l2 devices.


This looks fine to me, you say that
I would have to have your opinion on this patch.

So I've not merged it yet, let me know if you want to have this patch merged
upstream.

Regards,

Hans






Regards,
Benjamin

commit 85f40dcc5248b5fb03464fe25fd2d1acb30f9722
Author: Paramanand SINGH paramanand.si...@linaro.org
Date:   Wed Mar 11 15:41:28 2015 +0530

 libv4l2: Changes for compilation in Android 5.0

 Added Android makefiles for libv4l2 and
 libv4lconvert. Minor changes to include
 android-config.h. Changed the plugin
 loading mechanism to avoid using
 unsupported glob.h header. Current mechanism
 supports a list of plugin search paths
 including /system/lib and /vendor/lib.

 Signed-off-by: Paramanand Singh paramanand.si...@linaro.org

diff --git a/android-config.h b/android-config.h
index f474330..9f12b8f 100644
--- a/android-config.h
+++ b/android-config.h
@@ -1,3 +1,5 @@
+#ifndef __V4L_ANDROID_CONFIG_H__
+#define __V4L_ANDROID_CONFIG_H__
  /* config.h.  Generated from config.h.in by configure.  */
  /* config.h.in.  Generated from configure.ac by autoheader.  */

@@ -358,3 +360,4 @@ getsubopt (char **optionp, char *const *tokens,
char **valuep)

return -1;
  }
+#endif
diff --git a/lib/Android.mk b/lib/Android.mk
new file mode 100644
index 000..2e43120
--- /dev/null
+++ b/lib/Android.mk
@@ -0,0 +1,4 @@
+LOCAL_PATH:= $(call my-dir)
+include $(CLEAR_VARS)
+
+include $(call all-makefiles-under,$(LOCAL_PATH))
diff --git a/lib/libv4l2/Android.mk b/lib/libv4l2/Android.mk
new file mode 100644
index 000..7d723fb
--- /dev/null
+++ b/lib/libv4l2/Android.mk
@@ -0,0 +1,31 @@
+LOCAL_PATH:= $(call my-dir)
+
+include $(CLEAR_VARS)
+
+LOCAL_SRC_FILES := \
+log.c \
+libv4l2.c \
+v4l2convert.c \
+v4l2-plugin-android.c
+
+LOCAL_CFLAGS += -Wno-missing-field-initializers
+LOCAL_CFLAGS += -Wno-sign-compare
+
+LOCAL_C_INCLUDES := \
+$(LOCAL_PATH)/../include \
+$(LOCAL_PATH)/../../include \
+$(LOCAL_PATH)/../.. \
+ $(TOP)/bionic/libc/upstream-openbsd/lib/libc/gen
+
+LOCAL_SHARED_LIBRARIES := \
+libutils \
+libcutils \
+libdl \
+libssl \
+libz
+
+LOCAL_STATIC_LIBRARIES := libv4l_convert
+LOCAL_MODULE := libv4l2
+LOCAL_MODULE_TAGS := optional
+
+include $(BUILD_SHARED_LIBRARY)
diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index 966a000..70a6fd2 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -55,7 +55,11 @@
 When modifications are made, one should be careful that this behavior is
 preserved.
   */
+#ifdef ANDROID
+#include android-config.h
+#else
  #include config.h
+#endif
  #include errno.h
  #include stdarg.h
  #include stdio.h
diff --git a/lib/libv4l2/log.c b/lib/libv4l2/log.c
index d1042ed..9d3eab1 100644
--- a/lib/libv4l2/log.c
+++ b/lib/libv4l2/log.c
@@ -18,7 +18,11 @@
  # Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA  02110-1335  USA
   */

+#ifdef ANDROID
+#include android-config.h
+#else
  #include config.h
+#endif
  #include stdio.h
  #include stdlib.h
  #include string.h
diff --git a/lib/libv4l2/v4l2-plugin-android.c
b/lib/libv4l2/v4l2-plugin-android.c
new file mode 100644
index 000..af7f4ae
--- /dev/null
+++ b/lib/libv4l2/v4l2-plugin-android.c
@@ -0,0 +1,153 @@
+/*
+* Copyright (C) 2010 Nokia Corporation multime...@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
+*/
+
+#ifdef ANDROID
+#include android-config.h
+#else
+#include config.h
+#endif
+#include stdarg.h
+#include dlfcn.h
+#include fcntl.h
+#include glob.h
+#include sys/stat.h
+#include sys/mman.h
+#include sys/types.h
+#include dirent.h
+#include stdlib.h
+#include string.h
+#include libv4l2.h
+#include libv4l2-priv.h
+#include libv4l-plugin.h
+
+/* libv4l plugin support:
+   it is provided by functions v4l2_plugin_[open,close,etc].
+
+   When open() is called libv4l dlopens files in /usr/lib[64]/libv4l/plugins
+   1 at a time and call open callback passing through the applications
+   parameters unmodified.
+
+   If a plugin is relevant for the specified device node, it can 

[PULL fixes for 4.0]: gspca build fixes

[Hans de Goede]

Hi Mauro,

Here is a small build-fix for gspca for 4.0.

The following changes since commit a3dfc6d925ca1bbd1a228253acb93f08657bad25:

  [media] dvb-usb: create one media_dev per adapter (2015-02-26 09:52:26 -0300)

are available in the git repository at:

  git://linuxtv.org/hgoede/gspca.git media-for_v4.0

for you to fetch changes up to 4bc25799cb52f3e5f3084adb7be8cd2186905282:

  media: fix gspca drivers build dependencies (2015-03-02 14:23:49 +0100)


Randy Dunlap (1):
  media: fix gspca drivers build dependencies

 drivers/media/usb/gspca/Kconfig | 1 +
 1 file changed, 1 insertion(+)

Thanks  Regards,

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

Re: divide error: 0000 in the gspca_topro

[Hans de Goede]

Hi,

On 09-02-15 16:56, Mauro Carvalho Chehab wrote:

Em Mon, 09 Feb 2015 10:23:48 +
Luis de Bethencourt l...@debethencourt.com escreveu:


On Sun, Feb 08, 2015 at 06:07:45PM -0800, Linus Torvalds wrote:

I got this, and it certainly seems relevant,.

It would seem that that whole 'quality' thing needs some range
checking, it should presumably be in the range [1..100] in order to
avoid negative 'sc' values or the divide-by-zero.

Hans, Mauro?

   Linus


Hello Linus,

The case of quality being set to 0 is correctly handled in
drivers/media/usb/gspca/jpeg.h [0], so I have sent a patch to do the same
in topro.c.


Patch looks good to me.

I'll double check if some other driver has the same bad handling for
quality set and give a couple days for Hans to take a look.

If he's fine with this approach, I'll add it on a separate pull request.


Luis' patch for this looks good to me and is:

Acked-by: Hans de Goede hdego...@redhat.com

Mauro, thanks for picking this one up.

Regards,

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

Re: [PATCH] [media] gspca/touptek: Fix a few CodingStyle issues

[Hans de Goede]

Hi,

On 01/29/2015 09:25 PM, Mauro Carvalho Chehab wrote:
 Checkpatch complained about a few issues, like FSF address. Also,
 multi-line comments are not following the Kernel CodingStyle.
 
 While not too late, let's fix those issues.
 
 Cc: John McMaster johndmcmas...@gmail.com
 Cc: Hans de Goede hdego...@redhat.com
 Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

Looks good, thanks for fixing this up, and sorry for missing this.

Acked-by: Hans de Goede hdego...@redhat.com

Regards,

Hans

 
 diff --git a/drivers/media/usb/gspca/touptek.c 
 b/drivers/media/usb/gspca/touptek.c
 index 8b7c01e4b772..7bac6bc96063 100644
 --- a/drivers/media/usb/gspca/touptek.c
 +++ b/drivers/media/usb/gspca/touptek.c
 @@ -17,10 +17,6 @@
   * but WITHOUT ANY WARRANTY; without even the implied warranty of
   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
   * GNU General Public License for more details.
 - *
 - * You should have received a copy of the GNU General Public License
 - * along with this program; if not, write to the Free Software
 - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
   */
  
  #include gspca.h
 @@ -32,80 +28,80 @@ MODULE_DESCRIPTION(ToupTek UCMOS / Amscope MU microscope 
 camera driver);
  MODULE_LICENSE(GPL);
  
  /*
 -Exposure reg is linear with exposure time
 -Exposure (sec), E (reg)
 -0.000400, 0x0002
 -0.001000, 0x0005
 -0.005000, 0x0019
 -0.02, 0x0064
 -0.08, 0x0190
 -0.40, 0x07D0
 -1.00, 0x1388
 -2.00, 0x2710
 -
 -Three gain stages
 -0x1000: master channel enable bit
 -0x007F: low gain bits
 -0x0080: medium gain bit
 -0x0100: high gain bit
 -gain = enable * (1 + regH) * (1 + regM) * z * regL
 -
 -Gain implementation
 -Want to do something similar to mt9v011.c's set_balance
 -
 -Gain does not vary with resolution (checked 640x480 vs 1600x1200)
 -
 -Constant derivation:
 -
 -Raw data:
 -Gain,   GTOP,   B, R,  GBOT
 -1.00,   0x105C, 0x1068, 0x10C8, 0x105C
 -1.20,   0x106E, 0x107E, 0x10D6, 0x106E
 -1.40,   0x10C0, 0x10CA, 0x10E5, 0x10C0
 -1.60,   0x10C9, 0x10D4, 0x10F3, 0x10C9
 -1.80,   0x10D2, 0x10DE, 0x11C1, 0x10D2
 -2.00,   0x10DC, 0x10E9, 0x11C8, 0x10DC
 -2.20,   0x10E5, 0x10F3, 0x11CF, 0x10E5
 -2.40,   0x10EE, 0x10FE, 0x11D7, 0x10EE
 -2.60,   0x10F7, 0x11C4, 0x11DE, 0x10F7
 -2.80,   0x11C0, 0x11CA, 0x11E5, 0x11C0
 -3.00,   0x11C5, 0x11CF, 0x11ED, 0x11C5
 -
 -zR = 0.0069605943152454778
 - about 3/431 = 0.0069605568445475635
 -zB = 0.0095695970695970703
 - about 6/627 = 0.0095693779904306216
 -zG = 0.010889328063241107
 - about 6/551 = 0.010889292196007259
 -about 10 bits for constant + 7 bits for value = at least 17 bit intermediate
 -with 32 bit ints should be fine for overflow etc
 -Essentially gains are in range 0-0x001FF
 -
 -However, V4L expects a main gain channel + R and B balance
 -To keep things simple for now saturate the values of balance is too high/low
 -This isn't really ideal but easy way to fit the Linux model
 -
 -Converted using gain model turns out to be quite linear:
 -Gain, GTOP, B, R, GBOT
 -1.00, 92, 104, 144, 92
 -1.20, 110, 126, 172, 110
 -1.40, 128, 148, 202, 128
 -1.60, 146, 168, 230, 146
 -1.80, 164, 188, 260, 164
 -2.00, 184, 210, 288, 184
 -2.20, 202, 230, 316, 202
 -2.40, 220, 252, 348, 220
 -2.60, 238, 272, 376, 238
 -2.80, 256, 296, 404, 256
 -3.00, 276, 316, 436, 276
 -
 -Maximum gain is 0x7FF * 2 * 2 = 0x1FFC (8188)
 -or about 13 effective bits of gain
 -The highest the commercial driver goes in my setup 436
 -However, because could *maybe* damage circuits
 -limit the gain until have a reason to go higher
 -Solution: gain clipped and warning emitted
 -*/
 + * Exposure reg is linear with exposure time
 + * Exposure (sec), E (reg)
 + * 0.000400, 0x0002
 + * 0.001000, 0x0005
 + * 0.005000, 0x0019
 + * 0.02, 0x0064
 + * 0.08, 0x0190
 + * 0.40, 0x07D0
 + * 1.00, 0x1388
 + * 2.00, 0x2710
 + *
 + * Three gain stages
 + * 0x1000: master channel enable bit
 + * 0x007F: low gain bits
 + * 0x0080: medium gain bit
 + * 0x0100: high gain bit
 + * gain = enable * (1 + regH) * (1 + regM) * z * regL
 + *
 + * Gain implementation
 + * Want to do something similar to mt9v011.c's set_balance
 + *
 + * Gain does not vary with resolution (checked 640x480 vs 1600x1200)
 + *
 + * Constant derivation:
 + *
 + * Raw data:
 + * Gain,   GTOP,   B,  R,  GBOT
 + * 1.00,   0x105C, 0x1068, 0x10C8, 0x105C
 + * 1.20,   0x106E, 0x107E, 0x10D6, 0x106E
 + * 1.40,   0x10C0, 0x10CA, 0x10E5, 0x10C0
 + * 1.60,   0x10C9, 0x10D4, 0x10F3, 0x10C9
 + * 1.80,   0x10D2, 0x10DE, 0x11C1, 0x10D2
 + * 2.00,   0x10DC, 0x10E9, 0x11C8, 0x10DC
 + * 2.20,   0x10E5, 0x10F3, 0x11CF, 0x10E5
 + * 2.40,   0x10EE, 0x10FE, 0x11D7, 0x10EE
 + * 2.60,   0x10F7, 0x11C4, 0x11DE, 0x10F7
 + * 2.80,   0x11C0, 0x11CA, 0x11E5, 0x11C0
 + * 3.00,   0x11C5, 0x11CF, 0x11ED, 0x11C5
 + *
 + * zR = 0.0069605943152454778
 + *   about 3/431 = 0.0069605568445475635
 + * zB = 0.0095695970695970703
 + *   about 6/627

Re: [PULL patches for 3.20]: New gspca touptek driver, gspca fixes and sunxi-cir driver improvments

[Hans de Goede]

Hi,

On 01/29/2015 09:36 PM, Mauro Carvalho Chehab wrote:
 Em Thu, 15 Jan 2015 11:52:14 +0100
 Hans de Goede hdego...@redhat.com escreveu:
 
 Hi Mauro,

 Note this pull-req superseeds my previous pull-req for 3.20 .
 
 Hmm... I ended by applying the previous pull request. I was unable to see
 what's new on this one. Please check if everything went fine.

I used the same branch for both, so everything went fine.

Thanks,

Hans

 
 Thanks!
 Mauro
 

 Please pull from my tree for a new gspca touptek driver, various
 gspca fixes and some sunxi-cir driver improvments.

 The following changes since commit 99f3cd52aee21091ce62442285a68873e3be833f:

[media] vb2-vmalloc: Protect DMA-specific code by #ifdef CONFIG_HAS_DMA 
 (2014-12-23 16:28:09 -0200)

 are available in the git repository at:

git://linuxtv.org/hgoede/gspca.git media-for_v3.20

 for you to fetch changes up to e6a734195e2fbd9386aa58fe8931dd30c013f23e:

gspca: Fix underflow in vidioc_s_parm() (2015-01-15 11:46:17 +0100)

 
 Antonio Ospite (1):
gspca_stv06xx: enable button found on some Quickcam Express variant

 Hans Verkuil (1):
pwc: fix WARN_ON

 Hans de Goede (3):
rc: sunxi-cir: Add support for an optional reset controller
rc: sunxi-cir: Add support for the larger fifo found on sun5i and 
 sun6i
gspca: Fix underflow in vidioc_s_parm()

 Joe Howse (1):
gspca: Add high-speed modes for PS3 Eye camera

 John McMaster (1):
gspca_touptek: Add support for ToupTek UCMOS series USB cameras

   .../devicetree/bindings/media/sunxi-ir.txt |   4 +-
   drivers/media/rc/sunxi-cir.c   |  46 +-
   drivers/media/usb/gspca/Kconfig|  10 +
   drivers/media/usb/gspca/Makefile   |   2 +
   drivers/media/usb/gspca/gspca.c|   2 +-
   drivers/media/usb/gspca/ov534.c|  10 +-
   drivers/media/usb/gspca/stv06xx/stv06xx.c  |   4 +-
   drivers/media/usb/gspca/touptek.c  | 732 
 +
   drivers/media/usb/pwc/pwc-if.c |  12 +-
   9 files changed, 800 insertions(+), 22 deletions(-)
   create mode 100644 drivers/media/usb/gspca/touptek.c

 Thanks  Regards,

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

Re: [PATCH] media: gspca_vc032x - wrong bytesperline

[Hans de Goede]

Hi,

On 26-01-15 11:38, Luca Bonissi wrote:

Hi!

I found a problem on vc032x gspca usb webcam subdriver: bytesperline property 
is wrong for YUYV and YVYU formats.
With recent v4l-utils library (=0.9.1), that uses bytesperline for pixel 
format conversion, the result is a wrong jerky image.

Patch tested on my laptop (USB webcam Logitech Orbicam 046d:0892).


Thanks, I've added this patch to my gspca tree, and send a pull-req to
Mauro to get it added to 3.20 .

Regards,

Hans



--- drivers/media/usb/gspca/vc032x.c.orig   2014-08-04 00:25:02.0 
+0200
+++ drivers/media/usb/gspca/vc032x.c2015-01-12 00:28:39.423311693 +0100
@@ -68,12 +68,12 @@

  static const struct v4l2_pix_format vc0321_mode[] = {
 {320, 240, V4L2_PIX_FMT_YVYU, V4L2_FIELD_NONE,
-   .bytesperline = 320,
+   .bytesperline = 320 * 2,
 .sizeimage = 320 * 240 * 2,
 .colorspace = V4L2_COLORSPACE_SRGB,
 .priv = 1},
 {640, 480, V4L2_PIX_FMT_YVYU, V4L2_FIELD_NONE,
-   .bytesperline = 640,
+   .bytesperline = 640 * 2,
 .sizeimage = 640 * 480 * 2,
 .colorspace = V4L2_COLORSPACE_SRGB,
 .priv = 0},
@@ -97,12 +97,12 @@
  };
  static const struct v4l2_pix_format bi_mode[] = {
 {320, 240, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
-   .bytesperline = 320,
+   .bytesperline = 320 * 2,
 .sizeimage = 320 * 240 * 2,
 .colorspace = V4L2_COLORSPACE_SRGB,
 .priv = 2},
 {640, 480, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
-   .bytesperline = 640,
+   .bytesperline = 640 * 2,
 .sizeimage = 640 * 480 * 2,
 .colorspace = V4L2_COLORSPACE_SRGB,
 .priv = 1},

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

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

[PULL patches for 3.20]: New gspca touptek driver, gspca fixes and sunxi-cir driver improvments

[Hans de Goede]

Hi Mauro,

Note this pull-req superseeds my previous pull-req for 3.20, and
now includes one more gspca bugfix.

Please pull from my tree for a new gspca touptek driver, various
gspca fixes and some sunxi-cir driver improvments.

The following changes since commit 8d44aeefcd79e9be3b6db4f37efc7544995b619e:

  [media] rtl28xxu: change module unregister order (2015-01-27 10:57:58 -0200)

are available in the git repository at:

  git://linuxtv.org/hgoede/gspca.git media-for_v3.20

for you to fetch changes up to 161afd98bd7bff0456cef6fc79b9f0909d244f5e:

  gspca_vc032x: Fix wrong bytesperline (2015-01-28 09:06:50 +0100)


Antonio Ospite (1):
  gspca_stv06xx: enable button found on some Quickcam Express variant

Hans Verkuil (1):
  pwc: fix WARN_ON

Hans de Goede (3):
  rc: sunxi-cir: Add support for an optional reset controller
  rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i
  gspca: Fix underflow in vidioc_s_parm()

Joe Howse (1):
  gspca: Add high-speed modes for PS3 Eye camera

John McMaster (1):
  gspca_touptek: Add support for ToupTek UCMOS series USB cameras

Luca Bonissi (1):
  gspca_vc032x: Fix wrong bytesperline

 .../devicetree/bindings/media/sunxi-ir.txt |   4 +-
 drivers/media/rc/sunxi-cir.c   |  46 +-
 drivers/media/usb/gspca/Kconfig|  10 +
 drivers/media/usb/gspca/Makefile   |   2 +
 drivers/media/usb/gspca/gspca.c|   2 +-
 drivers/media/usb/gspca/ov534.c|  10 +-
 drivers/media/usb/gspca/stv06xx/stv06xx.c  |   4 +-
 drivers/media/usb/gspca/touptek.c  | 732 +
 drivers/media/usb/gspca/vc032x.c   |  10 +-
 drivers/media/usb/pwc/pwc-if.c |  12 +-
 10 files changed, 805 insertions(+), 27 deletions(-)
 create mode 100644 drivers/media/usb/gspca/touptek.c

Thanks  Regards,

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

Re: [linux-sunxi] [PATCH v2 04/13] rc: sunxi-cir: Add support for an optional reset controller

[Hans de Goede]

Hi,

On 19-01-15 15:10, Chen-Yu Tsai wrote:

Hi,

On Sat, Dec 20, 2014 at 6:20 PM, Hans de Goede hdego...@redhat.com wrote:

Hi,


On 19-12-14 19:17, Maxime Ripard wrote:


Hi,

On Thu, Dec 18, 2014 at 09:50:26AM +0100, Hans de Goede wrote:


Hi,

On 18-12-14 03:48, Chen-Yu Tsai wrote:


Hi,

On Thu, Dec 18, 2014 at 1:18 AM, Hans de Goede hdego...@redhat.com
wrote:


On sun6i the cir block is attached to the reset controller, add support
for de-asserting the reset if a reset controller is specified in dt.

Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
Acked-by: Maxime Ripard maxime.rip...@free-electrons.com
---
   .../devicetree/bindings/media/sunxi-ir.txt |  2 ++
   drivers/media/rc/sunxi-cir.c   | 25
--
   2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 23dd5ad..6b70b9b 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -10,6 +10,7 @@ Required properties:

   Optional properties:
   - linux,rc-map-name : Remote control map name.
+- resets : phandle + reset specifier pair



Should it be optional? Or should we use a sun6i compatible with
a mandatory reset phandle? I mean, the driver/hardware is not
going to work with the reset missing on sun6i.

Seems we are doing it one way for some of our drivers, and
the other (optional) way for more generic ones, like USB.



I do not believe that we should add a new compatible just because
the reset line of a block is hooked up differently. It is the
exact same ip-block. Only now the reset is not controlled
through the apb-gate, but controlled separately.



He has a point though. Your driver might very well probe nicely and
everything, but still wouldn't be functional at all because the reset
line wouldn't have been specified in the DT.



Right, just like other drivers we've, see e.g.:

Documentation/devicetree/bindings/mmc/sunxi-mmc.txt

Which is dealing with this in the same way.


The easiest way to deal with that would be in the bindings doc to
update it with a compatible for the A31, and mentionning that the
reset property is mandatory there.



No the easiest way to deal with this is to expect people writing
the dts to know what they are doing, just like we do for a lot
of the other blocks in sun6i.

Maybe put a generic note somewhere that sun6i has a reset controller,
and that for all the blocks with optional resets property it should
be considered mandatory on sun6i ?

I'm sorry but I'm not going to make this change for the ir bindings
given that we've the same situation in a lot of other places.

Consistency is important. Moreover I believe that having a sun6i
specific compatible string is just wrong, since it is the exact
same hardware block as on sun5i, just with its reset line routed
differently, just like e.g. the mmc controller, the uarts or the gmac
all of which also do not have a sun6i specific compatible to enforce
reset controller usage.

Regards,

Hans





Note that the code itself might not change at all though. I'd just
like to avoid any potential breaking of the DT bindings themselves. If
we further want to refine the code, we can do that however we want.

I have a slight preference for a clean error if reset is missing, but
I won't get in the way just for that.


Seems this patch and the following patch were overlooked after the
discussion. Any chance we could get this in?


I'm a linux/media sub-maintainer, so I've already send a pull-req for
these 2 to the linux/media maintainer, iow this is taken care of :)

Regards,

Hans


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

Re: [3/5, media] pwc-if: fix build warning when !CONFIG_USB_PWC_INPUT_EVDEV

[Hans de Goede]

Hi,

On 02-10-14 01:10, Luis Henriques wrote:

Label err_video_unreg in function usb_pwc_probe() is only used when
CONFIG_USB_PWC_INPUT_EVDEV is defined.

drivers/media/usb/pwc/pwc-if.c:1104:1: warning: label 'err_video_unreg' defined 
but not used [-Wunused-label]

Signed-off-by: Luis Henriques luis.henriq...@canonical.com


Sorry for the slow reaction, I somehow missed this patch and just found it in my
patchwork TODO.

I understand what you're trying to achieve here, but NAK to the implementation,
this is breaking the code flow wrt error handling, making it much harder
to double check that everything is being cleaned up properly.

Regards,

Hans




---
drivers/media/usb/pwc/pwc-if.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
index 15b754da4a2c..e6b7e63b0b8e 100644
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -1078,7 +1078,8 @@ static int usb_pwc_probe(struct usb_interface *intf, 
const struct usb_device_id
pdev-button_dev = input_allocate_device();
if (!pdev-button_dev) {
rc = -ENOMEM;
-   goto err_video_unreg;
+   video_unregister_device(pdev-vdev);
+   goto err_unregister_v4l2_dev;
}

usb_make_path(udev, pdev-button_phys, sizeof(pdev-button_phys));
@@ -1095,14 +1096,13 @@ static int usb_pwc_probe(struct usb_interface *intf, 
const struct usb_device_id
if (rc) {
input_free_device(pdev-button_dev);
pdev-button_dev = NULL;
-   goto err_video_unreg;
+   video_unregister_device(pdev-vdev);
+   goto err_unregister_v4l2_dev;
}
  #endif

return 0;

-err_video_unreg:
-   video_unregister_device(pdev-vdev);
  err_unregister_v4l2_dev:
v4l2_device_unregister(pdev-v4l2_dev);
  err_free_controls:


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

Re: [PATCH 1/1] gspca: Add high-speed modes for PS3 Eye camera

[Hans de Goede]

Hi,

On 04-01-15 16:29, Antonio Ospite wrote:

On Mon, 29 Dec 2014 11:00:03 -0400
Joe Howse josephho...@nummist.com wrote:


Add support in the PS3 Eye driver for QVGA capture at higher
frame rates: 187, 150, and 137 FPS. This functionality is valuable
because the PS3 Eye is popular for computer vision projects and no
other camera in its price range supports such high frame rates.

Correct a QVGA mode that was listed as 40 FPS. It is really 37 FPS
(half of 75 FPS).

Tests confirm that the nominal frame rates are achieved.

Signed-off-by: Joe Howse josephho...@nummist.com


Tested-by: Antonio Ospite a...@ao2.it


Joe, thanks for the patch, Antonio, thanks for testing, I've queued
this up in my gspca tree for merging into the 3.20 kernel

Regards,

Hans



Thanks Joe.

I noticed that qv4l2 displays max 60fps even though from the video I can
perceive the higher framerate, and same happens in guvcview.

gst-inspect-1.0 won't even let me set framerates higher than 75 so
I didn't test with GStreamer.

I know that the camera is also able to stream raw Bayer data which
requires less bandwidth than the default YUYV, although the driver does
not currently expose that; maybe some higher framerates can be achieved
also at VGA with Bayer output.

In case you wanted to explore that remember to set supported framerates
appropriately in ov772x_framerates for the 4 combinations of formats and
resolutions (i.e. Bayer outputs will support more framerates).

Ciao,
Antonio


---
  drivers/media/usb/gspca/ov534.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/gspca/ov534.c b/drivers/media/usb/gspca/ov534.c
index 90f0d63..a9c866d 100644
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -12,6 +12,8 @@
   * PS3 Eye camera enhanced by Richard Kaswy http://kaswy.free.fr
   * PS3 Eye camera - brightness, contrast, awb, agc, aec controls
   *  added by Max Thrun bear2...@gmail.com
+ * PS3 Eye camera - FPS range extended by Joseph Howse
+ *  josephho...@nummist.com http://nummist.com
   *
   * This program is free software; you can redistribute it and/or modify
   * it under the terms of the GNU General Public License as published by
@@ -116,7 +118,7 @@ static const struct v4l2_pix_format ov767x_mode[] = {
.colorspace = V4L2_COLORSPACE_JPEG},
  };

-static const u8 qvga_rates[] = {125, 100, 75, 60, 50, 40, 30};
+static const u8 qvga_rates[] = {187, 150, 137, 125, 100, 75, 60, 50, 37, 30};
  static const u8 vga_rates[] = {60, 50, 40, 30, 15};

  static const struct framerates ov772x_framerates[] = {
@@ -769,12 +771,16 @@ static void set_frame_rate(struct gspca_dev *gspca_dev)
{15, 0x03, 0x41, 0x04},
};
static const struct rate_s rate_1[] = { /* 320x240 */
+/* {205, 0x01, 0xc1, 0x02},  * 205 FPS: video is partly corrupt */
+   {187, 0x01, 0x81, 0x02}, /* 187 FPS or below: video is valid */
+   {150, 0x01, 0xc1, 0x04},
+   {137, 0x02, 0xc1, 0x02},
{125, 0x02, 0x81, 0x02},
{100, 0x02, 0xc1, 0x04},
{75, 0x03, 0xc1, 0x04},
{60, 0x04, 0xc1, 0x04},
{50, 0x02, 0x41, 0x04},
-   {40, 0x03, 0x41, 0x04},
+   {37, 0x03, 0x41, 0x04},
{30, 0x04, 0x41, 0x04},
};

--
1.9.1

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




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

Re: [PATCH] gspca_stv06xx: enable button found on some Quickcam Express variant

[Hans de Goede]

Hi,

On 06-01-15 21:59, Antonio Ospite wrote:

On Tue, 28 Oct 2014 15:39:41 +0100
Antonio Ospite a...@ao2.it wrote:


On Mon, 14 Jul 2014 12:27:57 +0200
Hans de Goede hdego...@redhat.com wrote:


Hi,

On 07/11/2014 02:56 PM, Antonio Ospite wrote:

Signed-off-by: Antonio Ospite a...@ao2.it


Thanks, I've added this to my tree and send a pull-req for it
to Mauro.



Hi Hans, I still don't see the change in 3.18-rc2, maybe it got lost.

Here is the patchwork link in case you want to pick the change for 3.19:
https://patchwork.linuxtv.org/patch/24732/



Ping.

Still missing in 3.19-rc3.


Yes, weird, I had it in a pull-req for 3.17:

http://git.linuxtv.org/cgit.cgi/hgoede/gspca.git/log/?h=media-for_v3.17

Anyways I've queued it up for 3.20 now.

Regards,

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

[PULL patches for 3.20]: New gspca touptek driver, gspca fixes and sunxi-cir driver improvments

[Hans de Goede]

Hi Mauro,

Note this pull-req superseeds my previous pull-req for 3.20 .

Please pull from my tree for a new gspca touptek driver, various
gspca fixes and some sunxi-cir driver improvments.

The following changes since commit 99f3cd52aee21091ce62442285a68873e3be833f:

  [media] vb2-vmalloc: Protect DMA-specific code by #ifdef CONFIG_HAS_DMA 
(2014-12-23 16:28:09 -0200)

are available in the git repository at:

  git://linuxtv.org/hgoede/gspca.git media-for_v3.20

for you to fetch changes up to e6a734195e2fbd9386aa58fe8931dd30c013f23e:

  gspca: Fix underflow in vidioc_s_parm() (2015-01-15 11:46:17 +0100)


Antonio Ospite (1):
  gspca_stv06xx: enable button found on some Quickcam Express variant

Hans Verkuil (1):
  pwc: fix WARN_ON

Hans de Goede (3):
  rc: sunxi-cir: Add support for an optional reset controller
  rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i
  gspca: Fix underflow in vidioc_s_parm()

Joe Howse (1):
  gspca: Add high-speed modes for PS3 Eye camera

John McMaster (1):
  gspca_touptek: Add support for ToupTek UCMOS series USB cameras

 .../devicetree/bindings/media/sunxi-ir.txt |   4 +-
 drivers/media/rc/sunxi-cir.c   |  46 +-
 drivers/media/usb/gspca/Kconfig|  10 +
 drivers/media/usb/gspca/Makefile   |   2 +
 drivers/media/usb/gspca/gspca.c|   2 +-
 drivers/media/usb/gspca/ov534.c|  10 +-
 drivers/media/usb/gspca/stv06xx/stv06xx.c  |   4 +-
 drivers/media/usb/gspca/touptek.c  | 732 +
 drivers/media/usb/pwc/pwc-if.c |  12 +-
 9 files changed, 800 insertions(+), 22 deletions(-)
 create mode 100644 drivers/media/usb/gspca/touptek.c

Thanks  Regards,

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

Re: [patch] [media] gspca: underflow in vidioc_s_parm()

[Hans de Goede]

Hi,

On 07-01-15 12:04, Dan Carpenter wrote:

n is a user controlled integer.  The code here doesn't handle the case
where n is negative and this causes a static checker warning.

drivers/media/usb/gspca/gspca.c:1571 vidioc_s_parm()
warn: no lower bound on 'n'

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
I haven't followed through to see if this is a real problem.


Thanks for the report, it is a real problem, but since
parm-parm.capture.readbuffers is unsigned I've chosen to fix it
by making n unsigned too instead.

Regards,

Hans



diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index 43d6505..27f7da1 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -1565,6 +1565,8 @@ static int vidioc_s_parm(struct file *filp, void *priv,
int n;

n = parm-parm.capture.readbuffers;
+   if (n  0)
+   return -EINVAL;
if (n == 0 || n = GSPCA_MAX_FRAMES)
parm-parm.capture.readbuffers = gspca_dev-nbufread;
else


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

Re: [PATCH v2 12/13] ARM: dts: sun6i: Add sun6i-a31s.dtsi

[Hans de Goede]

Hi,

On 05-01-15 10:08, Maxime Ripard wrote:

Hi,

On Mon, Dec 22, 2014 at 02:46:12PM +0100, Hans de Goede wrote:

On 21-12-14 23:39, Maxime Ripard wrote:

On Sat, Dec 20, 2014 at 11:24:55AM +0100, Hans de Goede wrote:


snip


Given your previous changes, you should also update the enable-method.


I've not added a new compatible for the enable-method, given that
this is the exact same die, so the 2 are 100?% compatible, just like you
insisted that allwinner,sun4i-a10-mod0-clk should be used for the ir-clk
since it was 100% compatible to that I believe that the enable method
should use the existing compatible and not invent a new one for something
which is 100% compatible.


Yeah, you have a point and I agree, but your patch 3 does add a
CPU_METHOD_OF_DECLARE for the A31s.


Ah right, it does, my bad.


Since I was going to push the branch now that 3.19-rc1 is out, do you
want me to edit your patch before doing so?


Yes, please drop the addition of the extra CPU_METHOD_OF_DECLARE, or let
me know if you want a new version instead.


I just modified it, and pushed it, no need to resend it.


Thanks, while looking at your dt-for-3.20 branch I noticed that you've
merged v2 of ARM: dts: sun6i: Add ir node, I did a v3 adding an ir:
label to the node, which I noticed was missing because you asked me to
move the a31s dt stuff to moving label references, can you fix this up, or
do you want me to do a follow up patch ?

Note that having this fixed is a pre-req for the csq-cs908 dts patch.

Regards,

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

[PULL patches for 3.20]: New gspca touptek driver and sunxi-cir driver improvments

[Hans de Goede]

Hi Mauro,

Please pull from my tree for a new gspca touptek driver and some
sunxi-cir driver improvments.

The following changes since commit 99f3cd52aee21091ce62442285a68873e3be833f:

  [media] vb2-vmalloc: Protect DMA-specific code by #ifdef CONFIG_HAS_DMA 
(2014-12-23 16:28:09 -0200)

are available in the git repository at:

  git://linuxtv.org/hgoede/gspca.git media-for_v3.20

for you to fetch changes up to bb729335790614dab96fab6dbed979a711955bdd:

  rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i 
(2015-01-05 13:43:33 +0100)


Hans de Goede (2):
  rc: sunxi-cir: Add support for an optional reset controller
  rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i

John McMaster (1):
  gspca_touptek: Add support for ToupTek UCMOS series USB cameras

 .../devicetree/bindings/media/sunxi-ir.txt |   4 +-
 drivers/media/rc/sunxi-cir.c   |  46 +-
 drivers/media/usb/gspca/Kconfig|  10 +
 drivers/media/usb/gspca/Makefile   |   2 +
 drivers/media/usb/gspca/touptek.c  | 732 +
 5 files changed, 782 insertions(+), 12 deletions(-)
 create mode 100644 drivers/media/usb/gspca/touptek.c

Thanks  Regards,

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

Re: [PATCH] [media] gspca_touptek: Add support for ToupTek UCMOS series USB cameras

[Hans de Goede]

Hi John,

On 01-12-14 03:27, John McMaster wrote:

Adds support for AmScope MU800 / ToupTek UCMOS08000KPB USB microscope camera.

Signed-off-by: John McMaster johndmcmas...@gmail.com


Thanks, I've added this driver to my gspca tree, and asked Mauro to
queue it up for 3.20.

Regards,

Hans


---
  drivers/media/usb/gspca/Kconfig   |   10 +
  drivers/media/usb/gspca/Makefile  |2 +
  drivers/media/usb/gspca/touptek.c |  729 +
  3 files changed, 741 insertions(+)
  create mode 100644 drivers/media/usb/gspca/touptek.c

diff --git a/drivers/media/usb/gspca/Kconfig b/drivers/media/usb/gspca/Kconfig
index eed10d7..60af3b1 100644
--- a/drivers/media/usb/gspca/Kconfig
+++ b/drivers/media/usb/gspca/Kconfig
@@ -395,6 +395,16 @@ config USB_GSPCA_TOPRO
  To compile this driver as a module, choose M here: the
  module will be called gspca_topro.

+config USB_GSPCA_TOUPTEK
+   tristate Touptek USB Camera Driver
+   depends on VIDEO_V4L2  USB_GSPCA
+   help
+ Say Y here if you want support for cameras based on the ToupTek UCMOS
+ / AmScope MU series camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gspca_touptek.
+
  config USB_GSPCA_TV8532
tristate TV8532 USB Camera Driver
depends on VIDEO_V4L2  USB_GSPCA
diff --git a/drivers/media/usb/gspca/Makefile b/drivers/media/usb/gspca/Makefile
index f46975e..9f5ccec 100644
--- a/drivers/media/usb/gspca/Makefile
+++ b/drivers/media/usb/gspca/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_USB_GSPCA_STK1135)  += gspca_stk1135.o
  obj-$(CONFIG_USB_GSPCA_STV0680)  += gspca_stv0680.o
  obj-$(CONFIG_USB_GSPCA_T613) += gspca_t613.o
  obj-$(CONFIG_USB_GSPCA_TOPRO)+= gspca_topro.o
+obj-$(CONFIG_USB_GSPCA_TOUPTEK)  += gspca_touptek.o
  obj-$(CONFIG_USB_GSPCA_TV8532)   += gspca_tv8532.o
  obj-$(CONFIG_USB_GSPCA_VC032X)   += gspca_vc032x.o
  obj-$(CONFIG_USB_GSPCA_VICAM)+= gspca_vicam.o
@@ -86,6 +87,7 @@ gspca_stv0680-objs  := stv0680.o
  gspca_sunplus-objs  := sunplus.o
  gspca_t613-objs := t613.o
  gspca_topro-objs:= topro.o
+gspca_touptek-objs  := touptek.o
  gspca_tv8532-objs   := tv8532.o
  gspca_vc032x-objs   := vc032x.o
  gspca_vicam-objs:= vicam.o
diff --git a/drivers/media/usb/gspca/touptek.c 
b/drivers/media/usb/gspca/touptek.c
new file mode 100644
index 000..2fd876c
--- /dev/null
+++ b/drivers/media/usb/gspca/touptek.c
@@ -0,0 +1,729 @@
+/*
+ * ToupTek UCMOS / AmScope MU series camera driver
+ * TODO: contrast with ScopeTek / AmScope MDC cameras
+ *
+ * Copyright (C) 2012-2014 John McMaster johndmcmas...@gmail.com
+ *
+ * Special thanks to Bushing for helping with the decrypt algorithm and
+ * Sean O'Sullivan / the Rensselaer Center for Open Source
+ * Software (RCOS) for helping me learn kernel development
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include gspca.h
+
+#define MODULE_NAME touptek
+
+MODULE_AUTHOR(John McMaster);
+MODULE_DESCRIPTION(ToupTek UCMOS / Amscope MU microscope camera driver);
+MODULE_LICENSE(GPL);
+
+/*
+Exposure reg is linear with exposure time
+Exposure (sec), E (reg)
+0.000400, 0x0002
+0.001000, 0x0005
+0.005000, 0x0019
+0.02, 0x0064
+0.08, 0x0190
+0.40, 0x07D0
+1.00, 0x1388
+2.00, 0x2710
+
+Three gain stages
+0x1000: master channel enable bit
+0x007F: low gain bits
+0x0080: medium gain bit
+0x0100: high gain bit
+gain = enable * (1 + regH) * (1 + regM) * z * regL
+
+Gain implementation
+Want to do something similar to mt9v011.c's set_balance
+
+Gain does not vary with resolution (checked 640x480 vs 1600x1200)
+
+Constant derivation:
+
+Raw data:
+Gain,   GTOP,   B,   R,  GBOT
+1.00,   0x105C, 0x1068, 0x10C8, 0x105C
+1.20,   0x106E, 0x107E, 0x10D6, 0x106E
+1.40,   0x10C0, 0x10CA, 0x10E5, 0x10C0
+1.60,   0x10C9, 0x10D4, 0x10F3, 0x10C9
+1.80,   0x10D2, 0x10DE, 0x11C1, 0x10D2
+2.00,   0x10DC, 0x10E9, 0x11C8, 0x10DC
+2.20,   0x10E5, 0x10F3, 0x11CF, 0x10E5
+2.40,   0x10EE, 0x10FE, 0x11D7, 0x10EE
+2.60,   0x10F7, 0x11C4, 0x11DE, 0x10F7
+2.80,   0x11C0, 0x11CA, 0x11E5, 0x11C0
+3.00,   0x11C5, 0x11CF, 0x11ED, 0x11C5
+
+zR = 0.0069605943152454778
+   about 3/431 = 0.0069605568445475635
+zB = 0.0095695970695970703
+   about 6/627 = 0.0095693779904306216
+zG = 0.010889328063241107
+   

Re: [PATCH v2 12/13] ARM: dts: sun6i: Add sun6i-a31s.dtsi

[Hans de Goede]

Hi,

On 21-12-14 23:39, Maxime Ripard wrote:

On Sat, Dec 20, 2014 at 11:24:55AM +0100, Hans de Goede wrote:

Hi,

On 19-12-14 19:34, Maxime Ripard wrote:

On Wed, Dec 17, 2014 at 06:18:23PM +0100, Hans de Goede wrote:

Add a dtsi file for A31s based boards.

Since the  A31s is the same die as the A31 in a different package, this dtsi
simply includes sun6i-a31.dtsi and then overrides the pinctrl compatible to
reflect the different package, everything else is identical.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-include sun6i-a31.dtsi and override the pinctrl compatible, rather then
  copying everything
---
  arch/arm/boot/dts/sun6i-a31s.dtsi | 62 +++
  1 file changed, 62 insertions(+)
  create mode 100644 arch/arm/boot/dts/sun6i-a31s.dtsi

diff --git a/arch/arm/boot/dts/sun6i-a31s.dtsi 
b/arch/arm/boot/dts/sun6i-a31s.dtsi
new file mode 100644
index 000..d0bd2b9
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31s.dtsi
@@ -0,0 +1,62 @@
+/*
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * The A31s is the same die as the A31 in a different package, this is
+ * reflected by it having different pinctrl compatible everything else is
+ * identical.
+ */
+
+/include/ sun6i-a31.dtsi
+
+/ {
+   soc@01c0 {
+   pio: pinctrl@01c20800 {
+   compatible = allwinner,sun6i-a31s-pinctrl;
+   };
+   };
+};


Given your previous changes, you should also update the enable-method.


I've not added a new compatible for the enable-method, given that
this is the exact same die, so the 2 are 100?% compatible, just like you
insisted that allwinner,sun4i-a10-mod0-clk should be used for the ir-clk
since it was 100% compatible to that I believe that the enable method
should use the existing compatible and not invent a new one for something
which is 100% compatible.


Yeah, you have a point and I agree, but your patch 3 does add a
CPU_METHOD_OF_DECLARE for the A31s.


Ah right, it does, my bad.


Since I was going to push the branch now that 3.19-rc1 is out, do you
want me to edit your patch before doing so?


Yes, please drop the addition of the extra CPU_METHOD_OF_DECLARE, or let
me know if you want a new version instead.


Also, for this patch and the next one, Arnd just warned me that we
shouldn't duplicate the DT path, and that we should switch to the new
trend on using label references (like what TI or Amlogic does for
example).


Ok, so something like this, right ?  :

pio {
compatible = allwinner,sun6i-a31s-pinctrl;
};


Yep.


Regards,

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

Re: [linux-sunxi] [PATCH v2 04/13] rc: sunxi-cir: Add support for an optional reset controller

[Hans de Goede]

Hi,

On 19-12-14 19:17, Maxime Ripard wrote:

Hi,

On Thu, Dec 18, 2014 at 09:50:26AM +0100, Hans de Goede wrote:

Hi,

On 18-12-14 03:48, Chen-Yu Tsai wrote:

Hi,

On Thu, Dec 18, 2014 at 1:18 AM, Hans de Goede hdego...@redhat.com wrote:

On sun6i the cir block is attached to the reset controller, add support
for de-asserting the reset if a reset controller is specified in dt.

Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
Acked-by: Maxime Ripard maxime.rip...@free-electrons.com
---
  .../devicetree/bindings/media/sunxi-ir.txt |  2 ++
  drivers/media/rc/sunxi-cir.c   | 25 --
  2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt 
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 23dd5ad..6b70b9b 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -10,6 +10,7 @@ Required properties:

  Optional properties:
  - linux,rc-map-name : Remote control map name.
+- resets : phandle + reset specifier pair


Should it be optional? Or should we use a sun6i compatible with
a mandatory reset phandle? I mean, the driver/hardware is not
going to work with the reset missing on sun6i.

Seems we are doing it one way for some of our drivers, and
the other (optional) way for more generic ones, like USB.


I do not believe that we should add a new compatible just because
the reset line of a block is hooked up differently. It is the
exact same ip-block. Only now the reset is not controlled
through the apb-gate, but controlled separately.


He has a point though. Your driver might very well probe nicely and
everything, but still wouldn't be functional at all because the reset
line wouldn't have been specified in the DT.


Right, just like other drivers we've, see e.g.:

Documentation/devicetree/bindings/mmc/sunxi-mmc.txt

Which is dealing with this in the same way.


The easiest way to deal with that would be in the bindings doc to
update it with a compatible for the A31, and mentionning that the
reset property is mandatory there.


No the easiest way to deal with this is to expect people writing
the dts to know what they are doing, just like we do for a lot
of the other blocks in sun6i.

Maybe put a generic note somewhere that sun6i has a reset controller,
and that for all the blocks with optional resets property it should
be considered mandatory on sun6i ?

I'm sorry but I'm not going to make this change for the ir bindings
given that we've the same situation in a lot of other places.

Consistency is important. Moreover I believe that having a sun6i
specific compatible string is just wrong, since it is the exact
same hardware block as on sun5i, just with its reset line routed
differently, just like e.g. the mmc controller, the uarts or the gmac
all of which also do not have a sun6i specific compatible to enforce
reset controller usage.

Regards,

Hans




Note that the code itself might not change at all though. I'd just
like to avoid any potential breaking of the DT bindings themselves. If
we further want to refine the code, we can do that however we want.

I have a slight preference for a clean error if reset is missing, but
I won't get in the way just for that.

Maxime


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

Re: [PATCH v2 12/13] ARM: dts: sun6i: Add sun6i-a31s.dtsi

[Hans de Goede]

Hi,

On 19-12-14 19:34, Maxime Ripard wrote:

On Wed, Dec 17, 2014 at 06:18:23PM +0100, Hans de Goede wrote:

Add a dtsi file for A31s based boards.

Since the  A31s is the same die as the A31 in a different package, this dtsi
simply includes sun6i-a31.dtsi and then overrides the pinctrl compatible to
reflect the different package, everything else is identical.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-include sun6i-a31.dtsi and override the pinctrl compatible, rather then
  copying everything
---
  arch/arm/boot/dts/sun6i-a31s.dtsi | 62 +++
  1 file changed, 62 insertions(+)
  create mode 100644 arch/arm/boot/dts/sun6i-a31s.dtsi

diff --git a/arch/arm/boot/dts/sun6i-a31s.dtsi 
b/arch/arm/boot/dts/sun6i-a31s.dtsi
new file mode 100644
index 000..d0bd2b9
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31s.dtsi
@@ -0,0 +1,62 @@
+/*
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * The A31s is the same die as the A31 in a different package, this is
+ * reflected by it having different pinctrl compatible everything else is
+ * identical.
+ */
+
+/include/ sun6i-a31.dtsi
+
+/ {
+   soc@01c0 {
+   pio: pinctrl@01c20800 {
+   compatible = allwinner,sun6i-a31s-pinctrl;
+   };
+   };
+};


Given your previous changes, you should also update the enable-method.


I've not added a new compatible for the enable-method, given that
this is the exact same die, so the 2 are 100?% compatible, just like you
insisted that allwinner,sun4i-a10-mod0-clk should be used for the ir-clk
since it was 100% compatible to that I believe that the enable method
should use the existing compatible and not invent a new one for something
which is 100% compatible.


Also, for this patch and the next one, Arnd just warned me that we
shouldn't duplicate the DT path, and that we should switch to the new
trend on using label references (like what TI or Amlogic does for
example).


Ok, so something like this, right ?  :

pio {
compatible = allwinner,sun6i-a31s-pinctrl;
};

Once we've agreement on the enable-method I'll respin this patch and
the CSQ CS908 board patch.

Regards,

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

Re: [PATCH v2 06/13] clk: sunxi: Make the mod0 clk driver also a platform driver

[Hans de Goede]

Hi,

On 19-12-14 19:24, Maxime Ripard wrote:

Hi,

On Wed, Dec 17, 2014 at 06:18:17PM +0100, Hans de Goede wrote:

With the prcm in sun6i (and some later SoCs) some mod0 clocks are instantiated
through the mfd framework, and as such do not work with of_clk_declare, since
they do not have registers assigned to them yet at of_clk_declare init time.

Silence the error on not finding registers in the of_clk_declare mod0 clk
setup method, and also register mod0-clk support as a platform driver to work
properly with mfd instantiated mod0 clocks.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
  drivers/clk/sunxi/clk-mod0.c | 41 -
  1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/sunxi/clk-mod0.c b/drivers/clk/sunxi/clk-mod0.c
index 658d74f..7ddab6f 100644
--- a/drivers/clk/sunxi/clk-mod0.c
+++ b/drivers/clk/sunxi/clk-mod0.c
@@ -17,6 +17,7 @@
  #include linux/clk-provider.h
  #include linux/clkdev.h
  #include linux/of_address.h
+#include linux/platform_device.h

  #include clk-factors.h

@@ -67,7 +68,7 @@ static struct clk_factors_config sun4i_a10_mod0_config = {
.pwidth = 2,
  };

-static const struct factors_data sun4i_a10_mod0_data __initconst = {
+static const struct factors_data sun4i_a10_mod0_data = {
.enable = 31,
.mux = 24,
.muxmask = BIT(1) | BIT(0),
@@ -82,17 +83,47 @@ static void __init sun4i_a10_mod0_setup(struct device_node 
*node)
void __iomem *reg;

reg = of_iomap(node, 0);
-   if (!reg) {
-   pr_err(Could not get registers for mod0-clk: %s\n,
-  node-name);
+   if (!reg)
return;
-   }


A comment here would be nice to mention that this is intentional.


Ok, I'll respin this patch adding such a comment.

Regards,

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

Re: [linux-sunxi] [PATCH v2 04/13] rc: sunxi-cir: Add support for an optional reset controller

[Hans de Goede]

Hi,

On 18-12-14 03:48, Chen-Yu Tsai wrote:

Hi,

On Thu, Dec 18, 2014 at 1:18 AM, Hans de Goede hdego...@redhat.com wrote:

On sun6i the cir block is attached to the reset controller, add support
for de-asserting the reset if a reset controller is specified in dt.

Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
Acked-by: Maxime Ripard maxime.rip...@free-electrons.com
---
  .../devicetree/bindings/media/sunxi-ir.txt |  2 ++
  drivers/media/rc/sunxi-cir.c   | 25 --
  2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt 
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 23dd5ad..6b70b9b 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -10,6 +10,7 @@ Required properties:

  Optional properties:
  - linux,rc-map-name : Remote control map name.
+- resets : phandle + reset specifier pair


Should it be optional? Or should we use a sun6i compatible with
a mandatory reset phandle? I mean, the driver/hardware is not
going to work with the reset missing on sun6i.

Seems we are doing it one way for some of our drivers, and
the other (optional) way for more generic ones, like USB.


I do not believe that we should add a new compatible just because
the reset line of a block is hooked up differently. It is the
exact same ip-block. Only now the reset is not controlled
through the apb-gate, but controlled separately.

Regards,

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

Re: [PATCH v2 07/13] mfd: sun6i-prcm: Add support for the ir-clk

[Hans de Goede]

Hi,

On 18-12-14 09:41, Lee Jones wrote:

On Wed, 17 Dec 2014, Hans de Goede wrote:


Add support for the ir-clk which is part of the sun6i SoC prcm module.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
  drivers/mfd/sun6i-prcm.c | 14 ++
  1 file changed, 14 insertions(+)


Pretty standard stuff (


diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
index 2f2e9f0..1911731 100644
--- a/drivers/mfd/sun6i-prcm.c
+++ b/drivers/mfd/sun6i-prcm.c
@@ -41,6 +41,14 @@ static const struct resource sun6i_a31_apb0_gates_clk_res[] 
= {
},
  };

+static const struct resource sun6i_a31_ir_clk_res[] = {
+   {
+   .start = 0x54,
+   .end = 0x57,
+   .flags = IORESOURCE_MEM,
+   },
+};


I'm still unkeen on this registers not being defined -- but whateveer!


  static const struct resource sun6i_a31_apb0_rstc_res[] = {
{
.start = 0xb0,
@@ -69,6 +77,12 @@ static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
.resources = sun6i_a31_apb0_gates_clk_res,
},
{
+   .name = sun6i-a31-ir-clk,
+   .of_compatible = allwinner,sun4i-a10-mod0-clk,
+   .num_resources = ARRAY_SIZE(sun6i_a31_ir_clk_res),
+   .resources = sun6i_a31_ir_clk_res,
+   },
+   {
.name = sun6i-a31-apb0-clock-reset,
.of_compatible = allwinner,sun6i-a31-clock-reset,
.num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),


This is all pretty standard stuff:

For my own reference:

Acked-by: Lee Jones lee.jo...@linaro.org

Do you do  you expect this patch to be handled?


I've no preference for how this goes upstream. There are no compile time deps
and runtime the ir will not work (but not explode) until all the bits are
in place.

Regards,

Hans





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

[PATCH v2 01/13] pinctrl: sun6i: Add some missing functions

[Hans de Goede]

While working on pinctrl for the A31s, I noticed that function 4 of
PA15 - PA18 was missing, add these.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Drop the changes to the muxing of i2c3 this was based on
 A31s Datasheet v1.40.pdf, but all other A31 related info puts them at the
 pins where we already have them, so leave this as is
---
 drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c 
b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c
index f42858e..18038f0 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c
@@ -134,24 +134,28 @@ static const struct sunxi_desc_pin sun6i_a31_pins[] = {
  SUNXI_FUNCTION(0x1, gpio_out),
  SUNXI_FUNCTION(0x2, gmac),  /* RXD4 */
  SUNXI_FUNCTION(0x3, lcd1),  /* D15 */
+ SUNXI_FUNCTION(0x4, clk_out_a),
  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 15)), /* PA_EINT15 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 16),
  SUNXI_FUNCTION(0x0, gpio_in),
  SUNXI_FUNCTION(0x1, gpio_out),
  SUNXI_FUNCTION(0x2, gmac),  /* RXD5 */
  SUNXI_FUNCTION(0x3, lcd1),  /* D16 */
+ SUNXI_FUNCTION(0x4, dmic),  /* CLK */
  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 16)), /* PA_EINT16 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 17),
  SUNXI_FUNCTION(0x0, gpio_in),
  SUNXI_FUNCTION(0x1, gpio_out),
  SUNXI_FUNCTION(0x2, gmac),  /* RXD6 */
  SUNXI_FUNCTION(0x3, lcd1),  /* D17 */
+ SUNXI_FUNCTION(0x4, dmic),  /* DIN */
  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 17)), /* PA_EINT17 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 18),
  SUNXI_FUNCTION(0x0, gpio_in),
  SUNXI_FUNCTION(0x1, gpio_out),
  SUNXI_FUNCTION(0x2, gmac),  /* RXD7 */
  SUNXI_FUNCTION(0x3, lcd1),  /* D18 */
+ SUNXI_FUNCTION(0x4, clk_out_b),
  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 18)), /* PA_EINT18 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 19),
  SUNXI_FUNCTION(0x0, gpio_in),
@@ -207,6 +211,7 @@ static const struct sunxi_desc_pin sun6i_a31_pins[] = {
  SUNXI_FUNCTION(0x1, gpio_out),
  SUNXI_FUNCTION(0x2, gmac),  /* MDC */
  SUNXI_FUNCTION(0x3, lcd1),  /* HSYNC */
+ SUNXI_FUNCTION(0x4, clk_out_c),
  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 26)), /* PA_EINT26 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 27),
  SUNXI_FUNCTION(0x0, gpio_in),
-- 
2.1.0

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

[PATCH v2 00/13] sun6i: Add A31s and ir support

[Hans de Goede]

Hi All,

Here is v2 of my patch series to add sun6i A31s and ir support.

Changes in v2:

-pinctrl: sun6i: Add some missing functions, fix i2c3 muxing:
 -Drop the changes to the muxing of i2c3 this was based on 
  A31s Datasheet v1.40.pdf, but all other A31 related info puts them at the
  pins where we already have them, so leave this as is
-pinctrl: sun6i: Add A31s pinctrl support
 -Sync i2c3 muxing with v2 of pinctrl: sun6i: Add some missing functions
 -Add myself to the copyright header
-clk: sunxi: Make the mod0 clk driver also a platform driver
 -New patch in v2 of the set
-mfd: sun6i-prcm: Add support for the ir-clk
 -New patch in v2 of the set
-ARM: dts: sun6i: Add sun6i-a31s.dtsi
 -include sun6i-a31.dtsi and override the pinctrl compatible, rather then
  copying everything
-ARM: dts: sun6i: Add ir_clk node
 -Use allwinner,sun4i-a10-mod0-clk as compatible, rather then a prcm
  specific compatible

Please queue this up for 3.20 .

Thanks,

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

[PATCH v2 03/13] ARM: sunxi: Add allwinner,sun6i-a31s to mach-sunxi

[Hans de Goede]

So far the A31s is 100% compatible with the A31, still lets do the same
as what we've done for the A13 / A10s and give it its own compatible string,
in case we need to differentiate later.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 Documentation/arm/sunxi/README | 1 -
 arch/arm/mach-sunxi/platsmp.c  | 3 ++-
 arch/arm/mach-sunxi/sunxi.c| 1 +
 drivers/clk/sunxi/clk-sunxi.c  | 1 +
 4 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index e68d163..1fe2d7f 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -50,7 +50,6 @@ SunXi family
   
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20user%20manual%20V1.1%2020130630.pdf
 
   - Allwinner A31s (sun6i)
-+ Not Supported
 + Datasheet
   
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20datasheet%20V1.3%2020131106.pdf
 + User Manual
diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
index e44d028..b1b5b7c 100644
--- a/arch/arm/mach-sunxi/platsmp.c
+++ b/arch/arm/mach-sunxi/platsmp.c
@@ -120,4 +120,5 @@ static struct smp_operations sun6i_smp_ops __initdata = {
.smp_prepare_cpus   = sun6i_smp_prepare_cpus,
.smp_boot_secondary = sun6i_smp_boot_secondary,
 };
-CPU_METHOD_OF_DECLARE(sun6i_smp, allwinner,sun6i-a31, sun6i_smp_ops);
+CPU_METHOD_OF_DECLARE(sun6i_a31_smp, allwinner,sun6i-a31, sun6i_smp_ops);
+CPU_METHOD_OF_DECLARE(sun6i_a31s_smp, allwinner,sun6i-a31s, sun6i_smp_ops);
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 1f98675..d4bb239 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -29,6 +29,7 @@ MACHINE_END
 
 static const char * const sun6i_board_dt_compat[] = {
allwinner,sun6i-a31,
+   allwinner,sun6i-a31s,
NULL,
 };
 
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index a9d10b9..ee9d7f2 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -1235,6 +1235,7 @@ static void __init sun6i_init_clocks(struct device_node 
*node)
  ARRAY_SIZE(sun6i_critical_clocks));
 }
 CLK_OF_DECLARE(sun6i_a31_clk_init, allwinner,sun6i-a31, sun6i_init_clocks);
+CLK_OF_DECLARE(sun6i_a31s_clk_init, allwinner,sun6i-a31s, sun6i_init_clocks);
 CLK_OF_DECLARE(sun8i_a23_clk_init, allwinner,sun8i-a23, sun6i_init_clocks);
 
 static void __init sun9i_init_clocks(struct device_node *node)
-- 
2.1.0

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

[PATCH v2 06/13] clk: sunxi: Make the mod0 clk driver also a platform driver

[Hans de Goede]

With the prcm in sun6i (and some later SoCs) some mod0 clocks are instantiated
through the mfd framework, and as such do not work with of_clk_declare, since
they do not have registers assigned to them yet at of_clk_declare init time.

Silence the error on not finding registers in the of_clk_declare mod0 clk
setup method, and also register mod0-clk support as a platform driver to work
properly with mfd instantiated mod0 clocks.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 drivers/clk/sunxi/clk-mod0.c | 41 -
 1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/sunxi/clk-mod0.c b/drivers/clk/sunxi/clk-mod0.c
index 658d74f..7ddab6f 100644
--- a/drivers/clk/sunxi/clk-mod0.c
+++ b/drivers/clk/sunxi/clk-mod0.c
@@ -17,6 +17,7 @@
 #include linux/clk-provider.h
 #include linux/clkdev.h
 #include linux/of_address.h
+#include linux/platform_device.h
 
 #include clk-factors.h
 
@@ -67,7 +68,7 @@ static struct clk_factors_config sun4i_a10_mod0_config = {
.pwidth = 2,
 };
 
-static const struct factors_data sun4i_a10_mod0_data __initconst = {
+static const struct factors_data sun4i_a10_mod0_data = {
.enable = 31,
.mux = 24,
.muxmask = BIT(1) | BIT(0),
@@ -82,17 +83,47 @@ static void __init sun4i_a10_mod0_setup(struct device_node 
*node)
void __iomem *reg;
 
reg = of_iomap(node, 0);
-   if (!reg) {
-   pr_err(Could not get registers for mod0-clk: %s\n,
-  node-name);
+   if (!reg)
return;
-   }
 
sunxi_factors_register(node, sun4i_a10_mod0_data,
   sun4i_a10_mod0_lock, reg);
 }
 CLK_OF_DECLARE(sun4i_a10_mod0, allwinner,sun4i-a10-mod0-clk, 
sun4i_a10_mod0_setup);
 
+static int sun4i_a10_mod0_clk_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev-dev.of_node;
+   struct resource *r;
+   void __iomem *reg;
+
+   if (!np)
+   return -ENODEV;
+
+   r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   reg = devm_ioremap_resource(pdev-dev, r);
+   if (IS_ERR(reg))
+   return PTR_ERR(reg);
+
+   sunxi_factors_register(np, sun4i_a10_mod0_data,
+  sun4i_a10_mod0_lock, reg);
+   return 0;
+}
+
+static const struct of_device_id sun4i_a10_mod0_clk_dt_ids[] = {
+   { .compatible = allwinner,sun4i-a10-mod0-clk },
+   { /* sentinel */ }
+};
+
+static struct platform_driver sun4i_a10_mod0_clk_driver = {
+   .driver = {
+   .name = sun4i-a10-mod0-clk,
+   .of_match_table = sun4i_a10_mod0_clk_dt_ids,
+   },
+   .probe = sun4i_a10_mod0_clk_probe,
+};
+module_platform_driver(sun4i_a10_mod0_clk_driver);
+
 static DEFINE_SPINLOCK(sun5i_a13_mbus_lock);
 
 static void __init sun5i_a13_mbus_setup(struct device_node *node)
-- 
2.1.0

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

[PATCH v2 10/13] ARM: dts: sun6i: Add pinmux settings for the ir pins

[Hans de Goede]

Add pinmux settings for the ir receive pin of the A31.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 85c6365..9e9504c 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -918,6 +918,13 @@
#interrupt-cells = 2;
#size-cells = 0;
#gpio-cells = 3;
+
+   ir_pins_a: ir@0 {
+   allwinner,pins = PL4;
+   allwinner,function = s_ir;
+   allwinner,drive = 0;
+   allwinner,pull = 0;
+   };
};
};
 };
-- 
2.1.0

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

[PATCH v2 08/13] ARM: dts: sun6i: Add ir_clk node

[Hans de Goede]

Add an ir_clk sub-node to the prcm node.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Use allwinner,sun4i-a10-mod0-clk as compatible, rather then a prcm specific
 compatible
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index f47156b..1c1d255 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -878,6 +878,13 @@
apb0_i2c;
};
 
+   ir_clk: ir_clk {
+   #clock-cells = 0;
+   compatible = allwinner,sun4i-a10-mod0-clk;
+   clocks = osc32k, osc24M;
+   clock-output-names = ir;
+   };
+
apb0_rst: apb0_rst {
compatible = allwinner,sun6i-a31-clock-reset;
#reset-cells = 1;
-- 
2.1.0

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

[PATCH v2 13/13] ARM: dts: sun6i: Add dts file for CSQ CS908 board

[Hans de Goede]

The CSQ CS908 is an A31s based top-set box, with 1G RAM, 8G NAND,
rtl8188etv usb wifi, 2 USB A receptacles (1 connected through the OTG
controller), ethernet, 3.5 mm jack with a/v out and hdmi out.

Note it has no sdcard slot and therefore can only be fel booted.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/boot/dts/Makefile |   3 +-
 arch/arm/boot/dts/sun6i-a31s-cs908.dts | 109 +
 2 files changed, 111 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun6i-a31s-cs908.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bc58ac3..28506ab 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -459,7 +459,8 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-app4-evb1.dtb \
sun6i-a31-colombus.dtb \
sun6i-a31-hummingbird.dtb \
-   sun6i-a31-m9.dtb
+   sun6i-a31-m9.dtb \
+   sun6i-a31s-cs908.dtb
 dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-bananapi.dtb \
sun7i-a20-cubieboard2.dtb \
diff --git a/arch/arm/boot/dts/sun6i-a31s-cs908.dts 
b/arch/arm/boot/dts/sun6i-a31s-cs908.dts
new file mode 100644
index 000..48d3a70
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31s-cs908.dts
@@ -0,0 +1,109 @@
+/*
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ sun6i-a31s.dtsi
+
+/ {
+   model = CSQ CS908 top set box;
+   compatible = csq,cs908, allwinner,sun6i-a31s;
+
+   chosen {
+   bootargs = earlyprintk console=ttyS0,115200;
+   };
+
+   soc@01c0 {
+   usbphy: phy@01c19400 {
+   status = okay;
+   };
+
+   ehci0: usb@01c1a000 {
+   status = okay;
+   };
+
+   ehci1: usb@01c1b000 {
+   status = okay;
+   };
+
+   ohci1: usb@01c1b400 {
+   status = okay;
+   };
+
+   pio: pinctrl@01c20800 {
+   usb1_vbus_pin_csq908: usb1_vbus_pin@0 {
+   allwinner,pins = PC27;
+   allwinner,function = gpio_out;
+   allwinner,drive = 0;
+   allwinner,pull = 0;
+   };
+   };
+
+   uart0: serial@01c28000 {
+   pinctrl-names = default;
+   pinctrl-0 = uart0_pins_a;
+   status = okay;
+   };
+
+   gmac: ethernet@01c3 {
+   pinctrl-names = default;
+   pinctrl-0 = gmac_pins_mii_a;
+   phy = phy1;
+   phy-mode = mii

[PATCH v2 12/13] ARM: dts: sun6i: Add sun6i-a31s.dtsi

[Hans de Goede]

Add a dtsi file for A31s based boards.

Since the  A31s is the same die as the A31 in a different package, this dtsi
simply includes sun6i-a31.dtsi and then overrides the pinctrl compatible to
reflect the different package, everything else is identical.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-include sun6i-a31.dtsi and override the pinctrl compatible, rather then
 copying everything
---
 arch/arm/boot/dts/sun6i-a31s.dtsi | 62 +++
 1 file changed, 62 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun6i-a31s.dtsi

diff --git a/arch/arm/boot/dts/sun6i-a31s.dtsi 
b/arch/arm/boot/dts/sun6i-a31s.dtsi
new file mode 100644
index 000..d0bd2b9
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31s.dtsi
@@ -0,0 +1,62 @@
+/*
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * The A31s is the same die as the A31 in a different package, this is
+ * reflected by it having different pinctrl compatible everything else is
+ * identical.
+ */
+
+/include/ sun6i-a31.dtsi
+
+/ {
+   soc@01c0 {
+   pio: pinctrl@01c20800 {
+   compatible = allwinner,sun6i-a31s-pinctrl;
+   };
+   };
+};
-- 
2.1.0

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

[PATCH v2 11/13] ARM: dts: sun6i: Enable ir receiver on the Mele M9

[Hans de Goede]

The Mele M9 has an ir receiver, enable it.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/boot/dts/sun6i-a31-m9.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31-m9.dts 
b/arch/arm/boot/dts/sun6i-a31-m9.dts
index 3ab544f..fccf709 100644
--- a/arch/arm/boot/dts/sun6i-a31-m9.dts
+++ b/arch/arm/boot/dts/sun6i-a31-m9.dts
@@ -121,6 +121,12 @@
reg = 1;
};
};
+
+   ir@01f02000 {
+   pinctrl-names = default;
+   pinctrl-0 = ir_pins_a;
+   status = okay;
+   };
};
 
leds {
-- 
2.1.0

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

[PATCH v2 05/13] rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i

[Hans de Goede]

Add support for the larger fifo found on sun5i and sun6i, having a separate
compatible for the ir found on sun5i  sun6i also is useful if we ever want
to add ir transmit support, because the sun5i  sun6i version do not have
transmit support.

Note this commits also adds checking for the end-of-packet interrupt flag
(which was already enabled), as the fifo-data-available interrupt flag only
gets set when the trigger-level is exceeded. So far we've been getting away
with not doing this because of the low trigger-level, but this is something
which we should have done since day one.

Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
Acked-by: Maxime Ripard maxime.rip...@free-electrons.com
---
 .../devicetree/bindings/media/sunxi-ir.txt  |  2 +-
 drivers/media/rc/sunxi-cir.c| 21 -
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt 
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 6b70b9b..1811a06 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -1,7 +1,7 @@
 Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
 
 Required properties:
-- compatible   : should be allwinner,sun4i-a10-ir;
+- compatible   : allwinner,sun4i-a10-ir or allwinner,sun5i-a13-ir
 - clocks   : list of clock specifiers, corresponding to
  entries in clock-names property;
 - clock-names  : should contain apb and ir entries;
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 06170e0..7830aef 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -56,12 +56,12 @@
 #define REG_RXINT_RAI_EN   BIT(4)
 
 /* Rx FIFO available byte level */
-#define REG_RXINT_RAL(val)(((val)  8)  (GENMASK(11, 8)))
+#define REG_RXINT_RAL(val)((val)  8)
 
 /* Rx Interrupt Status */
 #define SUNXI_IR_RXSTA_REG0x30
 /* RX FIFO Get Available Counter */
-#define REG_RXSTA_GET_AC(val) (((val)  8)  (GENMASK(5, 0)))
+#define REG_RXSTA_GET_AC(val) (((val)  8)  (ir-fifo_size * 2 - 1))
 /* Clear all interrupt status value */
 #define REG_RXSTA_CLEARALL0xff
 
@@ -72,10 +72,6 @@
 /* CIR_REG register idle threshold */
 #define REG_CIR_ITHR(val)(((val)  8)  (GENMASK(15, 8)))
 
-/* Hardware supported fifo size */
-#define SUNXI_IR_FIFO_SIZE16
-/* How many messages in FIFO trigger IRQ */
-#define TRIGGER_LEVEL 8
 /* Required frequency for IR0 or IR1 clock in CIR mode */
 #define SUNXI_IR_BASE_CLK 800
 /* Frequency after IR internal divider  */
@@ -94,6 +90,7 @@ struct sunxi_ir {
struct rc_dev   *rc;
void __iomem*base;
int irq;
+   int fifo_size;
struct clk  *clk;
struct clk  *apb_clk;
struct reset_control *rst;
@@ -115,11 +112,11 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
/* clean all pending statuses */
writel(status | REG_RXSTA_CLEARALL, ir-base + SUNXI_IR_RXSTA_REG);
 
-   if (status  REG_RXINT_RAI_EN) {
+   if (status  (REG_RXINT_RAI_EN | REG_RXINT_RPEI_EN)) {
/* How many messages in fifo */
rc  = REG_RXSTA_GET_AC(status);
/* Sanity check */
-   rc = rc  SUNXI_IR_FIFO_SIZE ? SUNXI_IR_FIFO_SIZE : rc;
+   rc = rc  ir-fifo_size ? ir-fifo_size : rc;
/* If we have data */
for (cnt = 0; cnt  rc; cnt++) {
/* for each bit in fifo */
@@ -156,6 +153,11 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (!ir)
return -ENOMEM;
 
+   if (of_device_is_compatible(dn, allwinner,sun5i-a13-ir))
+   ir-fifo_size = 64;
+   else
+   ir-fifo_size = 16;
+
/* Clock */
ir-apb_clk = devm_clk_get(dev, apb);
if (IS_ERR(ir-apb_clk)) {
@@ -271,7 +273,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
 * level
 */
writel(REG_RXINT_ROI_EN | REG_RXINT_RPEI_EN |
-  REG_RXINT_RAI_EN | REG_RXINT_RAL(TRIGGER_LEVEL - 1),
+  REG_RXINT_RAI_EN | REG_RXINT_RAL(ir-fifo_size / 2 - 1),
   ir-base + SUNXI_IR_RXINT_REG);
 
/* Enable IR Module */
@@ -319,6 +321,7 @@ static int sunxi_ir_remove(struct platform_device *pdev)
 
 static const struct of_device_id sunxi_ir_match[] = {
{ .compatible = allwinner,sun4i-a10-ir, },
+   { .compatible = allwinner,sun5i-a13-ir, },
{},
 };
 
-- 
2.1.0

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

[PATCH v2 09/13] ARM: dts: sun6i: Add ir node

[Hans de Goede]

Add a node for the ir receiver found on the A31.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 1c1d255..85c6365 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -896,6 +896,16 @@
reg = 0x01f01c00 0x300;
};
 
+   ir@01f02000 {
+   compatible = allwinner,sun5i-a13-ir;
+   clocks = apb0_gates 1, ir_clk;
+   clock-names = apb, ir;
+   resets = apb0_rst 1;
+   interrupts = 0 37 4;
+   reg = 0x01f02000 0x40;
+   status = disabled;
+   };
+
r_pio: pinctrl@01f02c00 {
compatible = allwinner,sun6i-a31-r-pinctrl;
reg = 0x01f02c00 0x400;
-- 
2.1.0

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

[PATCH v2 07/13] mfd: sun6i-prcm: Add support for the ir-clk

[Hans de Goede]

Add support for the ir-clk which is part of the sun6i SoC prcm module.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 drivers/mfd/sun6i-prcm.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
index 2f2e9f0..1911731 100644
--- a/drivers/mfd/sun6i-prcm.c
+++ b/drivers/mfd/sun6i-prcm.c
@@ -41,6 +41,14 @@ static const struct resource sun6i_a31_apb0_gates_clk_res[] 
= {
},
 };
 
+static const struct resource sun6i_a31_ir_clk_res[] = {
+   {
+   .start = 0x54,
+   .end = 0x57,
+   .flags = IORESOURCE_MEM,
+   },
+};
+
 static const struct resource sun6i_a31_apb0_rstc_res[] = {
{
.start = 0xb0,
@@ -69,6 +77,12 @@ static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
.resources = sun6i_a31_apb0_gates_clk_res,
},
{
+   .name = sun6i-a31-ir-clk,
+   .of_compatible = allwinner,sun4i-a10-mod0-clk,
+   .num_resources = ARRAY_SIZE(sun6i_a31_ir_clk_res),
+   .resources = sun6i_a31_ir_clk_res,
+   },
+   {
.name = sun6i-a31-apb0-clock-reset,
.of_compatible = allwinner,sun6i-a31-clock-reset,
.num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),
-- 
2.1.0

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

[PATCH v2 02/13] pinctrl: sun6i: Add A31s pinctrl support

[Hans de Goede]

The A31s is a stripped down version of the A31, as such it is missing some
pins and some functions on some pins.

The new pinctrl-sun6i-a31s.c this commit adds is a copy of pinctrl-sun6i-a31s.c
with the missing pins and functions removed.

Note there is no a31s specific version of pinctrl-sun6i-a31-r.c, as the
prcm pins are identical between the A31 and the A31s.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Sync i2c3 muxing with v2 of pinctrl: sun6i: Add some missing functions
-Add myself to the copyright header
---
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 drivers/pinctrl/sunxi/Kconfig  |   4 +
 drivers/pinctrl/sunxi/Makefile |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun6i-a31s.c | 815 +
 4 files changed, 821 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun6i-a31s.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 93ce12e..fdd8046 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -11,6 +11,7 @@ Required properties:
   allwinner,sun5i-a10s-pinctrl
   allwinner,sun5i-a13-pinctrl
   allwinner,sun6i-a31-pinctrl
+  allwinner,sun6i-a31s-pinctrl
   allwinner,sun6i-a31-r-pinctrl
   allwinner,sun7i-a20-pinctrl
   allwinner,sun8i-a23-pinctrl
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 230a952..2eb893e 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -21,6 +21,10 @@ config PINCTRL_SUN6I_A31
def_bool MACH_SUN6I
select PINCTRL_SUNXI_COMMON
 
+config PINCTRL_SUN6I_A31S
+   def_bool MACH_SUN6I
+   select PINCTRL_SUNXI_COMMON
+
 config PINCTRL_SUN6I_A31_R
def_bool MACH_SUN6I
depends on RESET_CONTROLLER
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index c7d92e4..b796d57 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_PINCTRL_SUN4I_A10) += pinctrl-sun4i-a10.o
 obj-$(CONFIG_PINCTRL_SUN5I_A10S)   += pinctrl-sun5i-a10s.o
 obj-$(CONFIG_PINCTRL_SUN5I_A13)+= pinctrl-sun5i-a13.o
 obj-$(CONFIG_PINCTRL_SUN6I_A31)+= pinctrl-sun6i-a31.o
+obj-$(CONFIG_PINCTRL_SUN6I_A31S)   += pinctrl-sun6i-a31s.o
 obj-$(CONFIG_PINCTRL_SUN6I_A31_R)  += pinctrl-sun6i-a31-r.o
 obj-$(CONFIG_PINCTRL_SUN7I_A20)+= pinctrl-sun7i-a20.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23)+= pinctrl-sun8i-a23.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun6i-a31s.c 
b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31s.c
new file mode 100644
index 000..9b5a91f
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31s.c
@@ -0,0 +1,815 @@
+/*
+ * Allwinner A31s SoCs pinctrl driver.
+ *
+ * Copyright (C) 2014 Hans de Goede hdego...@redhat.com
+ *
+ * Based on pinctrl-sun6i-a31.c, which is:
+ * Copyright (C) 2014 Maxime Ripard maxime.rip...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/pinctrl/pinctrl.h
+
+#include pinctrl-sunxi.h
+
+static const struct sunxi_desc_pin sun6i_a31s_pins[] = {
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
+ SUNXI_FUNCTION(0x0, gpio_in),
+ SUNXI_FUNCTION(0x1, gpio_out),
+ SUNXI_FUNCTION(0x2, gmac),  /* TXD0 */
+ SUNXI_FUNCTION(0x4, uart1), /* DTR */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),  /* PA_EINT0 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
+ SUNXI_FUNCTION(0x0, gpio_in),
+ SUNXI_FUNCTION(0x1, gpio_out),
+ SUNXI_FUNCTION(0x2, gmac),  /* TXD1 */
+ SUNXI_FUNCTION(0x4, uart1), /* DSR */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),  /* PA_EINT1 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
+ SUNXI_FUNCTION(0x0, gpio_in),
+ SUNXI_FUNCTION(0x1, gpio_out),
+ SUNXI_FUNCTION(0x2, gmac),  /* TXD2 */
+ SUNXI_FUNCTION(0x4, uart1), /* DCD */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),  /* PA_EINT2 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
+ SUNXI_FUNCTION(0x0, gpio_in),
+ SUNXI_FUNCTION(0x1, gpio_out),
+ SUNXI_FUNCTION(0x2, gmac),  /* TXD3 */
+ SUNXI_FUNCTION(0x4, uart1), /* RING */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),  /* PA_EINT3 */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4

[PATCH v2 04/13] rc: sunxi-cir: Add support for an optional reset controller

[Hans de Goede]

On sun6i the cir block is attached to the reset controller, add support
for de-asserting the reset if a reset controller is specified in dt.

Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
Acked-by: Maxime Ripard maxime.rip...@free-electrons.com
---
 .../devicetree/bindings/media/sunxi-ir.txt |  2 ++
 drivers/media/rc/sunxi-cir.c   | 25 --
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt 
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 23dd5ad..6b70b9b 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -10,6 +10,7 @@ Required properties:
 
 Optional properties:
 - linux,rc-map-name : Remote control map name.
+- resets : phandle + reset specifier pair
 
 Example:
 
@@ -17,6 +18,7 @@ ir0: ir@01c21800 {
compatible = allwinner,sun4i-a10-ir;
clocks = apb0_gates 6, ir0_clk;
clock-names = apb, ir;
+   resets = apb0_rst 1;
interrupts = 0 5 1;
reg = 0x01C21800 0x40;
linux,rc-map-name = rc-rc6-mce;
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 340f7f5..06170e0 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -23,6 +23,7 @@
 #include linux/interrupt.h
 #include linux/module.h
 #include linux/of_platform.h
+#include linux/reset.h
 #include media/rc-core.h
 
 #define SUNXI_IR_DEV sunxi-ir
@@ -95,6 +96,7 @@ struct sunxi_ir {
int irq;
struct clk  *clk;
struct clk  *apb_clk;
+   struct reset_control *rst;
const char  *map_name;
 };
 
@@ -166,15 +168,29 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return PTR_ERR(ir-clk);
}
 
+   /* Reset (optional) */
+   ir-rst = devm_reset_control_get_optional(dev, NULL);
+   if (IS_ERR(ir-rst)) {
+   ret = PTR_ERR(ir-rst);
+   if (ret == -EPROBE_DEFER)
+   return ret;
+   ir-rst = NULL;
+   } else {
+   ret = reset_control_deassert(ir-rst);
+   if (ret)
+   return ret;
+   }
+
ret = clk_set_rate(ir-clk, SUNXI_IR_BASE_CLK);
if (ret) {
dev_err(dev, set ir base clock failed!\n);
-   return ret;
+   goto exit_reset_assert;
}
 
if (clk_prepare_enable(ir-apb_clk)) {
dev_err(dev, try to enable apb_ir_clk failed\n);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto exit_reset_assert;
}
 
if (clk_prepare_enable(ir-clk)) {
@@ -271,6 +287,9 @@ exit_clkdisable_clk:
clk_disable_unprepare(ir-clk);
 exit_clkdisable_apb_clk:
clk_disable_unprepare(ir-apb_clk);
+exit_reset_assert:
+   if (ir-rst)
+   reset_control_assert(ir-rst);
 
return ret;
 }
@@ -282,6 +301,8 @@ static int sunxi_ir_remove(struct platform_device *pdev)
 
clk_disable_unprepare(ir-clk);
clk_disable_unprepare(ir-apb_clk);
+   if (ir-rst)
+   reset_control_assert(ir-rst);
 
spin_lock_irqsave(ir-ir_lock, flags);
/* disable IR IRQ */
-- 
2.1.0

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

Re: LibV4L2 and CREATE_BUFS issues

[Hans de Goede]

Hi,

On 14-12-14 15:24, Nicolas Dufresne wrote:


Le 2014-12-14 04:49, Hans de Goede a écrit :

Ah yes I see, so I assume that if libv4l where to return a failure for
CREATE_BUFS when conversion is used, that gstreamer will then fallback to
a regular REQUEST_BUFS call ?

Then that indeed seems the best solution, can you submit patch for this ?


Exactly, that should work. My concern with application side workaround would 
that the day someone implements CREATE_BUF support in v4l2 this application 
won't benefit without patching. I'll see if I can find time, disabling it seems 
faster then implementing support for it, specially that current experiment show 
that the jpeg code is really fragile. Current state is that libv4l2 is causing 
a buffer overflow, so it is harmful library in that sense.


Hmm, is that jpeg overflow still there with my recent (aprok 2-3 weeks ago) fix
for this?


This raise a concern, it would mean that USERPTR, DMABUF, CREATE_BUFS will now 
be lost (in most cases) when enabling libv4l2.


Yes, which is not good.


This is getting a bit annoying. Specially that we are pushing forward having 
m2m decoders to only be usable through libv4l2 (HW specific parsers). Is there 
a long term plan or are we simply pushing the dust toward libv4l2 ?


I think that trying to bold support for all of this into libv4l2 is not 
necessarily
a good idea. Then again if we're going to use libv4l2 plugins to do things like
media-controller pipeline setups for apps which are not media-controller aware,
maybe it is ...

libv4l2 was mostly created to get the then current generation of v4l2 apps to 
work
with webcams which have funky formats without pushing fmt conversion into the 
kernel
as several out of tree drivers were doing.

It may be better to come up with a better API for libv4lconvert, and let apps 
which
want to do advanced stuff deal with conversion themselves, while keeping all the
conversion code in a central place, but that does leave the media-controller 
issue.

Note that I've aprox. 0 time to work on libv4l now a days ...

What we really need is an active libv4l maintainer. Do not get me wrong, Gregor
has been doing a great job at maintaining it, but if we want to do some 
architectural
rework (or just a complete rewrite) I think we need someone who knows the v4l2 
API,
media-controller, etc. a lot better.

Regards,

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

Re: LibV4L2 and CREATE_BUFS issues

[Hans de Goede]

Hi,

On 13-12-14 17:15, Nicolas Dufresne wrote:


Le 2014-12-13 05:41, Hans de Goede a écrit :

I think making CREATE_BUFS fail when doing conversion is probably best,
note that gstreamer should be able to tell which formats will lead to doing
conversion, and that it can try to avoid those.


Those format indeed have a flag. The problem is for HW specific format, like 
few bayers format, which we can't avoid if we need to use such camera.


Ah yes I see, so I assume that if libv4l where to return a failure for
CREATE_BUFS when conversion is used, that gstreamer will then fallback to
a regular REQUEST_BUFS call ?

Then that indeed seems the best solution, can you submit patch for this ?

Regards,

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

Re: LibV4L2 and CREATE_BUFS issues

[Hans de Goede]

Hi,

On 10-12-14 17:27, Nicolas Dufresne wrote:

Hi,

we recently fixed our CREATE_BUFS support in GStreamer master. It works
nicely with UVC drivers. The problem is that libv4l2 isn't aware of it,
and endup taking terribly decision the least quickly lead to crash.

I'm not sure what that right approach. It seems non-trivial to support
it, at least it would require a bit more knowledge of the converter code
and memory model. Maybe we should at least make sure that CREATE_BUF
fails if we are doing conversion ? Some input on that would be appreciated.


I think making CREATE_BUFS fail when doing conversion is probably best,
note that gstreamer should be able to tell which formats will lead to doing
conversion, and that it can try to avoid those.

Regards,

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

Re: [PATCH 3/9] clk: sunxi: Add prcm mod0 clock driver

[Hans de Goede]

Hi,

On 07-12-14 19:08, Maxime Ripard wrote:

On Wed, Dec 03, 2014 at 10:49:20AM +0100, Hans de Goede wrote:


snip


So it should not have a simple-bus compatible either, and as such we cannot
simply change the mod0 driver from of_clk_define to a platform driver because
then we need to instantiate platform devs for the mod0 clock nodes, which
means making the clock node a simple-bus.


I guess we can do that as a temporary measure until we get things
right on that front. I'm totally open to doing that work, so I'm not
asking you to do it.


I can see your logic in wanting the ir_clk prcm sub-node to use the
mod0 compatible string, so how about we make the mod0 driver both
register through of_declare and as a platform driver. Note this means
that it will try to bind twice to the ir_clk node, since of_clk_declare
will cause it to try and bind there too AFAIK.


Hmmm, I could live with that for a while too. That shouldn't even
require too much work, since the first thing we check in the mod0 code
is that we actually have something in reg, which will not be the case
in the OF_CLK_DECLARE case.


The of_clk_declare bind will fail though because there is no regs
property, so this double bind is not an issue as long as we do not
log errors on the first bind failure.


Yep, exactly.


Note that the ir_clk node will still need an ir-clk compatible as
well for the MFD to find it and assign the proper resources to it.


No, it really doesn't. At least for now, we have a single mod0 clock
under the PRCM MFD. If (and only if) one day, we find ourselves in a
position where we have two mod0 clocks under the PRCM, then we'll fix
the MFD code to deal with that, because it really should deal with it.


Ok, using only the mod0 compat string works for me. I'll respin my
patch-set (minus the one patch you've already merged) to make the modo
clk driver use both of_clk_declare and make it a platfrom driver, and
use the mod0 compat string for the ir-clk node.

Not sure when I'll get this done exactly though, but we still have
a while before 3.20 :)

Regards,

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

Re: [PATCH 3/9] clk: sunxi: Add prcm mod0 clock driver

[Hans de Goede]

Hi,

On 12/02/2014 04:45 PM, Maxime Ripard wrote:

 Ok, so thinking more about this, I'm still convinced that the MFD

framework is only getting in the way here.


You still haven't said of what exactly it's getting in the way of.


Of using of_clk_define to bind to the mod0 clk in the prcm, because the
ir_clk node does not have its own reg property when the mfd framework is
used and of_clk_define requires the node to have its own reg property.


But I can see having things represented in devicetree properly, with
the clocks, etc. as child nodes of the prcm being something which we
want.


Clocks and reset are the only thing set so far, because we need
reference to them from the DT itself, nothing more.

We could very much have more devices instatiated from the MFD itself.


So since all we are using the MFD for is to instantiate platform
devices under the prcm nodes, and assign an io resource for the regs
to them, why not simply make the prcm node itself a simple-bus.


No, this is really not a bus. It shouldn't be described at all as
such. It is a device, that has multiple functionnalities in the system
= MFD. It really is that simple.


Ok, I can live with that, but likewise the clocks node is not a bus either!

So it should not have a simple-bus compatible either, and as such we cannot
simply change the mod0 driver from of_clk_define to a platform driver because
then we need to instantiate platform devs for the mod0 clock nodes, which
means making the clock node a simple-bus.

I can see your logic in wanting the ir_clk prcm sub-node to use the
mod0 compatible string, so how about we make the mod0 driver both
register through of_declare and as a platform driver. Note this means
that it will try to bind twice to the ir_clk node, since of_clk_declare
will cause it to try and bind there too AFAIK.

The of_clk_declare bind will fail though because there is no regs
property, so this double bind is not an issue as long as we do not
log errors on the first bind failure.

Note that the ir_clk node will still need an ir-clk compatible as
well for the MFD to find it and assign the proper resources to it.

But this way we will have the clk driver binding to the mod0 clk compatible,
which is what you want, while having the MFD assign resources on the
fact that it is the ir-clk node, so that things will still work if
there are multiple mod0 clks in the prcm.


This does everything the MFD prcm driver currently does, without
actually needing a specific kernel driver, and as added bonus this
will move the definition of the mfd function reg offsets out of the
kernel and into the devicetree where they belong in the first place.


Which was nacked in the first place because such offsets are not
supposed to be in the DT.

Really, we have something that work here, there's no need to refactor
it.


Ok, but that does bring us back to the original problem wrt the ir-clk,
see above for how I think we should solve this then. If you agree I
can implement the proposed fix.

Regards,

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