Re: [PATCH v2 1/1] media: Use common test pattern menu entries

[Mauro Carvalho Chehab]

Em Tue,  4 Dec 2018 15:40:42 +0200
Sakari Ailus  escreveu:

> While the test pattern menu itself is not standardised, many devices
> support the same test patterns. Aligning the menu entries helps the user
> space to use the interface, and adding macros for the menu entry strings
> helps to keep them aligned.
> 
> Signed-off-by: Sakari Ailus 
> ---
> since v1:
> 
> - Fix indentation of menu strings
> - Remove "8" from the macro names
> 
>  drivers/media/i2c/imx258.c | 10 +-
>  drivers/media/i2c/imx319.c | 10 +-
>  drivers/media/i2c/imx355.c | 10 +-
>  drivers/media/i2c/ov2640.c |  4 ++--
>  drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
>  include/uapi/linux/v4l2-controls.h |  5 +
>  6 files changed, 27 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index f86ae18bc104..df5f016cebd9 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
>  };
>  
>  static const char * const imx258_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
>  };
>  
>  /* Configurations for supported link frequencies */
> diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
> index 17c2e4b41221..d9d4176b9d37 100644
> --- a/drivers/media/i2c/imx319.c
> +++ b/drivers/media/i2c/imx319.c
> @@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] = 
> {
>  };
>  
>  static const char * const imx319_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
>  };
>  
>  /* supported link frequencies */
> diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> index bed293b60e50..99138a291cb8 100644
> --- a/drivers/media/i2c/imx355.c
> +++ b/drivers/media/i2c/imx355.c
> @@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
>  };
>  
>  static const char * const imx355_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
>  };
>  
>  /* supported link frequencies */
> diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
> index 5d2d6735cc78..65058d9a5d51 100644
> --- a/drivers/media/i2c/ov2640.c
> +++ b/drivers/media/i2c/ov2640.c
> @@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
>  }
>  
>  static const char * const ov2640_test_pattern_menu[] = {
> - "Disabled",
> - "Eight Vertical Colour Bars",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
>  };
>  
>  /*
> diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
> b/drivers/media/i2c/smiapp/smiapp-core.c
> index 58a45c353e27..5c9bcc9438ec 100644
> --- a/drivers/media/i2c/smiapp/smiapp-core.c
> +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> @@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct 
> smiapp_sensor *sensor)
>  }
>  
>  static const char * const smiapp_test_patterns[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
>  };
>  
>  static int smiapp

Re: [PATCH 1/1] media: Use common test pattern menu entries

[sakari . ailus]

On Tue, Nov 27, 2018 at 07:19:52PM +0800, Bingbu Cao wrote:
> 
> On 11/27/2018 05:33 PM, Sakari Ailus wrote:
> > diff --git a/include/uapi/linux/v4l2-controls.h 
> > b/include/uapi/linux/v4l2-controls.h
> > index 998983a6e6b7..a74ff6f1ac88 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
> >   #define V4L2_CID_LINK_FREQ
> > (V4L2_CID_IMAGE_PROC_CLASS_BASE + 1)
> >   #define V4L2_CID_PIXEL_RATE   
> > (V4L2_CID_IMAGE_PROC_CLASS_BASE + 2)
> >   #define V4L2_CID_TEST_PATTERN 
> > (V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
> > +#define V4L2_TEST_PATTERN_DISABLED "Disabled"
> > +#define V4L2_TEST_PATTERN_SOLID_COLOUR "Solid Colour"
> > +#define V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS   "Eight Vertical 
> > Colour Bars"
> > +#define V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY "Colour Bars 
> > With Fade to Grey"
> > +#define V4L2_TEST_PATTERN_PN9  "Pseudorandom Sequence 
> > (PN9)"
> More padding here for alignment?

Fixed in v2.

-- 
Sakari Ailus

[PATCH v2 1/1] media: Use common test pattern menu entries

[Sakari Ailus]

While the test pattern menu itself is not standardised, many devices
support the same test patterns. Aligning the menu entries helps the user
space to use the interface, and adding macros for the menu entry strings
helps to keep them aligned.

Signed-off-by: Sakari Ailus 
---
since v1:

- Fix indentation of menu strings
- Remove "8" from the macro names

 drivers/media/i2c/imx258.c | 10 +-
 drivers/media/i2c/imx319.c | 10 +-
 drivers/media/i2c/imx355.c | 10 +-
 drivers/media/i2c/ov2640.c |  4 ++--
 drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
 include/uapi/linux/v4l2-controls.h |  5 +
 6 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index f86ae18bc104..df5f016cebd9 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
 };
 
 static const char * const imx258_test_pattern_menu[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 /* Configurations for supported link frequencies */
diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 17c2e4b41221..d9d4176b9d37 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] = {
 };
 
 static const char * const imx319_test_pattern_menu[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 /* supported link frequencies */
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index bed293b60e50..99138a291cb8 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
 };
 
 static const char * const imx355_test_pattern_menu[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 /* supported link frequencies */
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 5d2d6735cc78..65058d9a5d51 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
 }
 
 static const char * const ov2640_test_pattern_menu[] = {
-   "Disabled",
-   "Eight Vertical Colour Bars",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
 };
 
 /*
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 58a45c353e27..5c9bcc9438ec 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct 
smiapp_sensor *sensor)
 }
 
 static const char * const smiapp_test_patterns[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 998983a6e6b7..acb2a57fa5d6 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
 #define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 1)
 #define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 2)
 #define V4L2_CID_TEST_PATTERN  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 3)
+#define V4L2_TEST_PATTERN_DISABLED   

Re: [RESEND PATCH 1/1] media: Use common test pattern menu entries

[Sakari Ailus]

On Tue, Nov 27, 2018 at 01:11:42PM +0100, Luca Ceresoli wrote:
> Hi Sakari, Bingbu,
> 
> On 27/11/18 10:34, Sakari Ailus wrote:
> > While the test pattern menu itself is not standardised, many devices
> > support the same test patterns. Aligning the menu entries helps the user
> > space to use the interface, and adding macros for the menu entry strings
> > helps to keep them aligned.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> > Fixed Andy's email.
> > 
> >  drivers/media/i2c/imx258.c | 10 +-
> >  drivers/media/i2c/imx319.c | 10 +-
> >  drivers/media/i2c/imx355.c | 10 +-
> >  drivers/media/i2c/ov2640.c |  4 ++--
> >  drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
> >  include/uapi/linux/v4l2-controls.h |  5 +
> >  6 files changed, 27 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> > index f86ae18bc104..c795d4c4c0e4 100644
> > --- a/drivers/media/i2c/imx258.c
> > +++ b/drivers/media/i2c/imx258.c
> > @@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = 
> > {
> >  };
> >  
> >  static const char * const imx258_test_pattern_menu[] = {
> > -   "Disabled",
> > -   "Solid Colour",
> > -   "Eight Vertical Colour Bars",
> > -   "Colour Bars With Fade to Grey",
> > -   "Pseudorandom Sequence (PN9)",
> > +   V4L2_TEST_PATTERN_DISABLED,
> > +   V4L2_TEST_PATTERN_SOLID_COLOUR,
> > +   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> > +   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> > +   V4L2_TEST_PATTERN_PN9,
> >  };
> >  
> >  /* Configurations for supported link frequencies */
> > diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
> > index 17c2e4b41221..eddaf69a67b6 100644
> > --- a/drivers/media/i2c/imx319.c
> > +++ b/drivers/media/i2c/imx319.c
> > @@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] 
> > = {
> >  };
> >  
> >  static const char * const imx319_test_pattern_menu[] = {
> > -   "Disabled",
> > -   "Solid Colour",
> > -   "Eight Vertical Colour Bars",
> > -   "Colour Bars With Fade to Grey",
> > -   "Pseudorandom Sequence (PN9)",
> > +   V4L2_TEST_PATTERN_DISABLED,
> > +   V4L2_TEST_PATTERN_SOLID_COLOUR,
> > +   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> > +   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> > +   V4L2_TEST_PATTERN_PN9,
> >  };
> >  
> >  /* supported link frequencies */
> > diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> > index bed293b60e50..824d07156f9c 100644
> > --- a/drivers/media/i2c/imx355.c
> > +++ b/drivers/media/i2c/imx355.c
> > @@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
> >  };
> >  
> >  static const char * const imx355_test_pattern_menu[] = {
> > -   "Disabled",
> > -   "Solid Colour",
> > -   "Eight Vertical Colour Bars",
> > -   "Colour Bars With Fade to Grey",
> > -   "Pseudorandom Sequence (PN9)",
> > +   V4L2_TEST_PATTERN_DISABLED,
> > +   V4L2_TEST_PATTERN_SOLID_COLOUR,
> > +   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> > +   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> > +   V4L2_TEST_PATTERN_PN9,
> >  };
> >  
> >  /* supported link frequencies */
> > diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
> > index 5d2d6735cc78..507ec7176a7d 100644
> > --- a/drivers/media/i2c/ov2640.c
> > +++ b/drivers/media/i2c/ov2640.c
> > @@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
> >  }
> >  
> >  static const char * const ov2640_test_pattern_menu[] = {
> > -   "Disabled",
> > -   "Eight Vertical Colour Bars",
> > +   V4L2_TEST_PATTERN_DISABLED,
> > +   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> >  };
> >  
> >  /*
> > diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
> > b/drivers/media/i2c/smiapp/smiapp-core.c
> > index 58a45c353e27..f6a92b9f178c 100644
> > --- a/drivers/media/i2c/smiapp/smiapp-core.c
> > +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> > @@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct 
> > smiapp_sensor *sensor)
> >  }
> >  
> >  static const char * const smiapp_test_patterns[] = {
> > -   &q

Re: [RESEND PATCH 1/1] media: Use common test pattern menu entries

[Luca Ceresoli]

Hi Sakari, Bingbu,

On 27/11/18 10:34, Sakari Ailus wrote:
> While the test pattern menu itself is not standardised, many devices
> support the same test patterns. Aligning the menu entries helps the user
> space to use the interface, and adding macros for the menu entry strings
> helps to keep them aligned.
> 
> Signed-off-by: Sakari Ailus 
> ---
> Fixed Andy's email.
> 
>  drivers/media/i2c/imx258.c | 10 +-
>  drivers/media/i2c/imx319.c | 10 +-
>  drivers/media/i2c/imx355.c | 10 +-
>  drivers/media/i2c/ov2640.c |  4 ++--
>  drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
>  include/uapi/linux/v4l2-controls.h |  5 +
>  6 files changed, 27 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index f86ae18bc104..c795d4c4c0e4 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
>  };
>  
>  static const char * const imx258_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
>  };
>  
>  /* Configurations for supported link frequencies */
> diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
> index 17c2e4b41221..eddaf69a67b6 100644
> --- a/drivers/media/i2c/imx319.c
> +++ b/drivers/media/i2c/imx319.c
> @@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] = 
> {
>  };
>  
>  static const char * const imx319_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
>  };
>  
>  /* supported link frequencies */
> diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> index bed293b60e50..824d07156f9c 100644
> --- a/drivers/media/i2c/imx355.c
> +++ b/drivers/media/i2c/imx355.c
> @@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
>  };
>  
>  static const char * const imx355_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
>  };
>  
>  /* supported link frequencies */
> diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
> index 5d2d6735cc78..507ec7176a7d 100644
> --- a/drivers/media/i2c/ov2640.c
> +++ b/drivers/media/i2c/ov2640.c
> @@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
>  }
>  
>  static const char * const ov2640_test_pattern_menu[] = {
> - "Disabled",
> - "Eight Vertical Colour Bars",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
>  };
>  
>  /*
> diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
> b/drivers/media/i2c/smiapp/smiapp-core.c
> index 58a45c353e27..f6a92b9f178c 100644
> --- a/drivers/media/i2c/smiapp/smiapp-core.c
> +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> @@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct 
> smiapp_sensor *sensor)
>  }
>  
>  static const char * const smiapp_test_patterns[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
>  };
>  
>  static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
> diff --git a/include/uapi/linux/v4l2-c

Re: [PATCH 1/1] media: Use common test pattern menu entries

[Bingbu Cao]

On 11/27/2018 05:33 PM, Sakari Ailus wrote:

While the test pattern menu itself is not standardised, many devices
support the same test patterns. Aligning the menu entries helps the user
space to use the interface, and adding macros for the menu entry strings
helps to keep them aligned.

I like this patch.


Signed-off-by: Sakari Ailus 
---
  drivers/media/i2c/imx258.c | 10 +-
  drivers/media/i2c/imx319.c | 10 +-
  drivers/media/i2c/imx355.c | 10 +-
  drivers/media/i2c/ov2640.c |  4 ++--
  drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
  include/uapi/linux/v4l2-controls.h |  5 +
  6 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index f86ae18bc104..c795d4c4c0e4 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
  };
  
  static const char * const imx258_test_pattern_menu[] = {

-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
  };
  
  /* Configurations for supported link frequencies */

diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 17c2e4b41221..eddaf69a67b6 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] = {
  };
  
  static const char * const imx319_test_pattern_menu[] = {

-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
  };
  
  /* supported link frequencies */

diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index bed293b60e50..824d07156f9c 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
  };
  
  static const char * const imx355_test_pattern_menu[] = {

-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
  };
  
  /* supported link frequencies */

diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 5d2d6735cc78..507ec7176a7d 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
  }
  
  static const char * const ov2640_test_pattern_menu[] = {

-   "Disabled",
-   "Eight Vertical Colour Bars",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
  };
  
  /*

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 58a45c353e27..f6a92b9f178c 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct 
smiapp_sensor *sensor)
  }
  
  static const char * const smiapp_test_patterns[] = {

-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
  };
  
  static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)

diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 998983a6e6b7..a74ff6f1ac88 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
  #define V4L2_CID_LINK_FREQ(V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 1)
  #define V4L2_CID_PIXEL_RATE   (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 2)
  #define V4L2_CID_TEST_PATTERN (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+

[RESEND PATCH 1/1] media: Use common test pattern menu entries

[Sakari Ailus]

While the test pattern menu itself is not standardised, many devices
support the same test patterns. Aligning the menu entries helps the user
space to use the interface, and adding macros for the menu entry strings
helps to keep them aligned.

Signed-off-by: Sakari Ailus 
---
Fixed Andy's email.

 drivers/media/i2c/imx258.c | 10 +-
 drivers/media/i2c/imx319.c | 10 +-
 drivers/media/i2c/imx355.c | 10 +-
 drivers/media/i2c/ov2640.c |  4 ++--
 drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
 include/uapi/linux/v4l2-controls.h |  5 +
 6 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index f86ae18bc104..c795d4c4c0e4 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
 };
 
 static const char * const imx258_test_pattern_menu[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 /* Configurations for supported link frequencies */
diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 17c2e4b41221..eddaf69a67b6 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] = {
 };
 
 static const char * const imx319_test_pattern_menu[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 /* supported link frequencies */
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index bed293b60e50..824d07156f9c 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
 };
 
 static const char * const imx355_test_pattern_menu[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 /* supported link frequencies */
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 5d2d6735cc78..507ec7176a7d 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
 }
 
 static const char * const ov2640_test_pattern_menu[] = {
-   "Disabled",
-   "Eight Vertical Colour Bars",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
 };
 
 /*
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 58a45c353e27..f6a92b9f178c 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct 
smiapp_sensor *sensor)
 }
 
 static const char * const smiapp_test_patterns[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 998983a6e6b7..a74ff6f1ac88 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
 #define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 1)
 #define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 2)
 #define V4L2_CID_TEST_PATTERN  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 3)
+#define V4L2_TEST_PATTERN_DISABLED "Disabled"
+#define V4L2_TEST_

[PATCH 1/1] media: Use common test pattern menu entries

[Sakari Ailus]

While the test pattern menu itself is not standardised, many devices
support the same test patterns. Aligning the menu entries helps the user
space to use the interface, and adding macros for the menu entry strings
helps to keep them aligned.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/imx258.c | 10 +-
 drivers/media/i2c/imx319.c | 10 +-
 drivers/media/i2c/imx355.c | 10 +-
 drivers/media/i2c/ov2640.c |  4 ++--
 drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
 include/uapi/linux/v4l2-controls.h |  5 +
 6 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index f86ae18bc104..c795d4c4c0e4 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
 };
 
 static const char * const imx258_test_pattern_menu[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 /* Configurations for supported link frequencies */
diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 17c2e4b41221..eddaf69a67b6 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] = {
 };
 
 static const char * const imx319_test_pattern_menu[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 /* supported link frequencies */
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index bed293b60e50..824d07156f9c 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
 };
 
 static const char * const imx355_test_pattern_menu[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 /* supported link frequencies */
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 5d2d6735cc78..507ec7176a7d 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
 }
 
 static const char * const ov2640_test_pattern_menu[] = {
-   "Disabled",
-   "Eight Vertical Colour Bars",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
 };
 
 /*
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 58a45c353e27..f6a92b9f178c 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct 
smiapp_sensor *sensor)
 }
 
 static const char * const smiapp_test_patterns[] = {
-   "Disabled",
-   "Solid Colour",
-   "Eight Vertical Colour Bars",
-   "Colour Bars With Fade to Grey",
-   "Pseudorandom Sequence (PN9)",
+   V4L2_TEST_PATTERN_DISABLED,
+   V4L2_TEST_PATTERN_SOLID_COLOUR,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+   V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+   V4L2_TEST_PATTERN_PN9,
 };
 
 static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 998983a6e6b7..a74ff6f1ac88 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
 #define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 1)
 #define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 2)
 #define V4L2_CID_TEST_PATTERN  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 3)
+#define V4L2_TEST_PATTERN_DISABLED "Disabled"
+#define V4L2_TEST_PATTERN_SOLID_COLOUR  

Re: [PATCH 2/2] media: imx355: fix wrong order in test pattern menus

[Sakari Ailus]

On Tue, Nov 27, 2018 at 10:45:02AM +0800, Bingbu Cao wrote:
> 
> 
> On 11/26/2018 04:57 PM, Sakari Ailus wrote:
> > Hi Bing Bu,
> > 
> > On Mon, Nov 26, 2018 at 03:43:34PM +0800, bingbu@intel.com wrote:
> > > From: Bingbu Cao 
> > > 
> > > current imx355 test pattern order in ctrl menu
> > > is not correct, this patch fixes it.
> > > 
> > > Signed-off-by: Bingbu Cao 
> > > ---
> > >   drivers/media/i2c/imx355.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> > > index 20c8eea5db4b..9c9559dfd3dd 100644
> > > --- a/drivers/media/i2c/imx355.c
> > > +++ b/drivers/media/i2c/imx355.c
> > > @@ -876,8 +876,8 @@ struct imx355 {
> > >   static const char * const imx355_test_pattern_menu[] = {
> > >   "Disabled",
> > > - "100% color bars",
> > >   "Solid color",
> > > + "100% color bars",
> > >   "Fade to gray color bars",
> > >   "PN9"
> > >   };
> > While at it, could you use the existing test pattern naming as well for the
> > drivers? That could be a separate patch.
> > 
> > >From drivers/media/i2c/smiapp/smiapp-core.c :
> > 
> > static const char * const smiapp_test_patterns[] = {
> > "Disabled",
> > "Solid Colour",
> > "Eight Vertical Colour Bars",
> > "Colour Bars With Fade to Grey",
> > "Pseudorandom Sequence (PN9)",
> > };
> > 
> > It's not strictly necessary from interface point of view, but for the user
> > space it'd be good to align the naming.
> Sakari, ask a question that not really related to this patch.
> I am wondering whether there are some standardization for the camera sensor
> pattern generator.
> Currently there are varied patterns and every vendor has its own pattern 
> types.

Some vendors (and some models) do have their specific patterns, but if you
look at a bunch of drivers, these ones repeat over and over. That's why I
think it'd make sense to have the menu entries aligned.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 2/2] media: imx355: fix wrong order in test pattern menus

[Bingbu Cao]

On 11/26/2018 04:57 PM, Sakari Ailus wrote:

Hi Bing Bu,

On Mon, Nov 26, 2018 at 03:43:34PM +0800, bingbu@intel.com wrote:

From: Bingbu Cao 

current imx355 test pattern order in ctrl menu
is not correct, this patch fixes it.

Signed-off-by: Bingbu Cao 
---
  drivers/media/i2c/imx355.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index 20c8eea5db4b..9c9559dfd3dd 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -876,8 +876,8 @@ struct imx355 {
  
  static const char * const imx355_test_pattern_menu[] = {

"Disabled",
-   "100% color bars",
"Solid color",
+   "100% color bars",
"Fade to gray color bars",
"PN9"
  };

While at it, could you use the existing test pattern naming as well for the
drivers? That could be a separate patch.

>From drivers/media/i2c/smiapp/smiapp-core.c :

static const char * const smiapp_test_patterns[] = {
"Disabled",
"Solid Colour",
"Eight Vertical Colour Bars",
"Colour Bars With Fade to Grey",
"Pseudorandom Sequence (PN9)",
};

It's not strictly necessary from interface point of view, but for the user
space it'd be good to align the naming.

Sakari, ask a question that not really related to this patch.
I am wondering whether there are some standardization for the camera sensor
pattern generator.
Currently there are varied patterns and every vendor has its own pattern types.

Re: [PATCH 2/2] media: imx355: fix wrong order in test pattern menus

[Bingbu Cao]

On 11/26/2018 04:57 PM, Sakari Ailus wrote:

Hi Bing Bu,

On Mon, Nov 26, 2018 at 03:43:34PM +0800, bingbu@intel.com wrote:

From: Bingbu Cao 

current imx355 test pattern order in ctrl menu
is not correct, this patch fixes it.

Signed-off-by: Bingbu Cao 
---
  drivers/media/i2c/imx355.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index 20c8eea5db4b..9c9559dfd3dd 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -876,8 +876,8 @@ struct imx355 {
  
  static const char * const imx355_test_pattern_menu[] = {

"Disabled",
-   "100% color bars",
"Solid color",
+   "100% color bars",
"Fade to gray color bars",
"PN9"
  };

While at it, could you use the existing test pattern naming as well for the
drivers? That could be a separate patch.

Good point, thanks.
I am trying to check whether all the existing Sony camera sensors
use same test pattern definition, I can put them together.


>From drivers/media/i2c/smiapp/smiapp-core.c :

static const char * const smiapp_test_patterns[] = {
"Disabled",
"Solid Colour",
"Eight Vertical Colour Bars",
"Colour Bars With Fade to Grey",
"Pseudorandom Sequence (PN9)",
};

It's not strictly necessary from interface point of view, but for the user
space it'd be good to align the naming.

Re: [PATCH 2/2] media: imx355: fix wrong order in test pattern menus

[Sakari Ailus]

Hi Bing Bu,

On Mon, Nov 26, 2018 at 03:43:34PM +0800, bingbu@intel.com wrote:
> From: Bingbu Cao 
> 
> current imx355 test pattern order in ctrl menu
> is not correct, this patch fixes it.
> 
> Signed-off-by: Bingbu Cao 
> ---
>  drivers/media/i2c/imx355.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> index 20c8eea5db4b..9c9559dfd3dd 100644
> --- a/drivers/media/i2c/imx355.c
> +++ b/drivers/media/i2c/imx355.c
> @@ -876,8 +876,8 @@ struct imx355 {
>  
>  static const char * const imx355_test_pattern_menu[] = {
>   "Disabled",
> - "100% color bars",
>   "Solid color",
> + "100% color bars",
>   "Fade to gray color bars",
>   "PN9"
>  };

While at it, could you use the existing test pattern naming as well for the
drivers? That could be a separate patch.

>From drivers/media/i2c/smiapp/smiapp-core.c :

static const char * const smiapp_test_patterns[] = {
"Disabled",
"Solid Colour",
"Eight Vertical Colour Bars",
"Colour Bars With Fade to Grey",
"Pseudorandom Sequence (PN9)",
};

It's not strictly necessary from interface point of view, but for the user
space it'd be good to align the naming.

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

[PATCH 1/2] media: imx319: fix wrong order in test pattern menus

[bingbu . cao]

From: Bingbu Cao 

current imx319 test pattern order in ctrl menu
is not correct, this patch fixes it.

Signed-off-by: Bingbu Cao 
---
 drivers/media/i2c/imx319.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 0d3e27812b93..acd988d2d7f1 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1648,8 +1648,8 @@ struct imx319 {
 
 static const char * const imx319_test_pattern_menu[] = {
"Disabled",
-   "100% color bars",
"Solid color",
+   "100% color bars",
"Fade to gray color bars",
"PN9"
 };
-- 
1.9.1

[PATCH 2/2] media: imx355: fix wrong order in test pattern menus

[bingbu . cao]

From: Bingbu Cao 

current imx355 test pattern order in ctrl menu
is not correct, this patch fixes it.

Signed-off-by: Bingbu Cao 
---
 drivers/media/i2c/imx355.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index 20c8eea5db4b..9c9559dfd3dd 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -876,8 +876,8 @@ struct imx355 {
 
 static const char * const imx355_test_pattern_menu[] = {
"Disabled",
-   "100% color bars",
"Solid color",
+   "100% color bars",
"Fade to gray color bars",
"PN9"
 };
-- 
1.9.1

[RFCv4 PATCH 3/3] vimc: add property test code

[Hans Verkuil]

From: Hans Verkuil 

Add properties to entities and pads to be able to test the
properties API.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vimc/vimc-common.c | 50 +++
 1 file changed, 50 insertions(+)

diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index dee1b9dfc4f6..2f70e4e64790 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -415,6 +415,7 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
 const unsigned long *pads_flag,
 const struct v4l2_subdev_ops *sd_ops)
 {
+   struct media_prop *prop = NULL;
int ret;
 
/* Allocate the pads */
@@ -452,6 +453,55 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
goto err_clean_m_ent;
}
 
+   ret = media_entity_add_prop_u64(>entity, "u64", ~1);
+   if (!ret)
+   ret = media_entity_add_prop_s64(>entity, "s64", -5);
+   if (!ret)
+   ret = media_entity_add_prop_string(>entity, "string",
+  sd->name);
+   if (!ret) {
+   prop = media_entity_add_prop_group(>entity, "empty-group");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret) {
+   prop = media_entity_add_prop_group(>entity, "group");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret)
+   ret = media_prop_add_prop_u64(prop, "u64", 42);
+   if (!ret)
+   ret = media_prop_add_prop_s64(prop, "s64", -42);
+   if (!ret)
+   ret = media_prop_add_prop_string(prop, "string", "42");
+   if (!ret)
+   ret = media_pad_add_prop_u64(>entity.pads[num_pads - 1],
+"u64", ~1);
+   if (!ret)
+   ret = media_pad_add_prop_s64(>entity.pads[num_pads - 1],
+"s64", -5);
+   if (!ret) {
+   prop = media_pad_add_prop_group(>entity.pads[num_pads - 1],
+   "group");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret)
+   ret = media_prop_add_prop_u64(prop, "u64", 24);
+   if (!ret)
+   ret = media_prop_add_prop_s64(prop, "s64", -24);
+   if (!ret)
+   ret = media_pad_add_prop_string(>entity.pads[0],
+   "string", sd->name);
+   if (!ret)
+   ret = media_prop_add_prop_string(prop, "string", "24");
+   if (!ret) {
+   prop = media_prop_add_prop_group(prop, "subgroup");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret)
+   ret = media_prop_add_prop_string(prop, "string", "substring");
+   if (ret)
+   goto err_clean_m_ent;
+
return 0;
 
 err_clean_m_ent:
-- 
2.19.1

[PATCH v2] v4l2-compliance: test orphaned buffer support

[Philipp Zabel]

Test that V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS is reported equally for
both MMAP and DMABUF memory types. If supported, try to orphan buffers
by calling reqbufs(0) before unmapping or closing DMABUF fds.

Also close exported DMABUF fds and free buffers in testDmaBuf if
orphaned buffers are not supported.

Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Rename has_orphaned_bufs to supports_orphaned_bufs
 - Check that capabilities are independent of memory type
 - Check that orphaned buffer support is independent of queue for M2M
 - Check that reqbufs(0) returns -EBUSY without orphaned buffer support
---
 contrib/freebsd/include/linux/videodev2.h   |  1 +
 include/linux/videodev2.h   |  1 +
 utils/common/v4l2-info.cpp  |  1 +
 utils/v4l2-compliance/v4l2-compliance.h |  1 +
 utils/v4l2-compliance/v4l2-test-buffers.cpp | 51 ++---
 5 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/contrib/freebsd/include/linux/videodev2.h 
b/contrib/freebsd/include/linux/videodev2.h
index 9928c00e4b68..33153b53c175 100644
--- a/contrib/freebsd/include/linux/videodev2.h
+++ b/contrib/freebsd/include/linux/videodev2.h
@@ -907,6 +907,7 @@ struct v4l2_requestbuffers {
 #define V4L2_BUF_CAP_SUPPORTS_USERPTR  (1 << 1)
 #define V4L2_BUF_CAP_SUPPORTS_DMABUF   (1 << 2)
 #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
+#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
 
 /**
  * struct v4l2_plane - plane info for multi-planar buffers
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 79418cd39480..a39300cacb6a 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -873,6 +873,7 @@ struct v4l2_requestbuffers {
 #define V4L2_BUF_CAP_SUPPORTS_USERPTR  (1 << 1)
 #define V4L2_BUF_CAP_SUPPORTS_DMABUF   (1 << 2)
 #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
+#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
 
 /**
  * struct v4l2_plane - plane info for multi-planar buffers
diff --git a/utils/common/v4l2-info.cpp b/utils/common/v4l2-info.cpp
index 258e5446f030..3699c35cb9d6 100644
--- a/utils/common/v4l2-info.cpp
+++ b/utils/common/v4l2-info.cpp
@@ -200,6 +200,7 @@ static const flag_def bufcap_def[] = {
{ V4L2_BUF_CAP_SUPPORTS_USERPTR, "userptr" },
{ V4L2_BUF_CAP_SUPPORTS_DMABUF, "dmabuf" },
{ V4L2_BUF_CAP_SUPPORTS_REQUESTS, "requests" },
+   { V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS, "orphaned-bufs" },
{ 0, NULL }
 };
 
diff --git a/utils/v4l2-compliance/v4l2-compliance.h 
b/utils/v4l2-compliance/v4l2-compliance.h
index def185f17261..02d616f0b47c 100644
--- a/utils/v4l2-compliance/v4l2-compliance.h
+++ b/utils/v4l2-compliance/v4l2-compliance.h
@@ -119,6 +119,7 @@ struct base_node {
__u32 valid_buftypes;
__u32 valid_buftype;
__u32 valid_memorytype;
+   bool supports_orphaned_bufs;
 };
 
 struct node : public base_node, public cv4l_fd {
diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp 
b/utils/v4l2-compliance/v4l2-test-buffers.cpp
index a84be0ab799a..42e743fef43b 100644
--- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
+++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
@@ -400,14 +400,18 @@ int testReqBufs(struct node *node)
mmap_valid = !ret;
if (mmap_valid)
caps = q.g_capabilities();
-   if (caps)
+   if (caps) {
fail_on_test(mmap_valid ^ !!(caps & 
V4L2_BUF_CAP_SUPPORTS_MMAP));
+   if (caps & V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS)
+   node->supports_orphaned_bufs = true;
+   }
 
q.init(i, V4L2_MEMORY_USERPTR);
ret = q.reqbufs(node, 0);
fail_on_test(ret && ret != EINVAL);
userptr_valid = !ret;
fail_on_test(!mmap_valid && userptr_valid);
+   fail_on_test(userptr_valid && (caps != q.g_capabilities()));
if (caps)
fail_on_test(userptr_valid ^ !!(caps & 
V4L2_BUF_CAP_SUPPORTS_USERPTR));
 
@@ -416,6 +420,7 @@ int testReqBufs(struct node *node)
fail_on_test(ret && ret != EINVAL);
dmabuf_valid = !ret;
fail_on_test(!mmap_valid && dmabuf_valid);
+   fail_on_test(dmabuf_valid && (caps != q.g_capabilities()));
if (caps)
fail_on_test(dmabuf_valid ^ !!(caps & 
V4L2_BUF_CAP_SUPPORTS_DMABUF));
 
@@ -754,9 +759,13 @@ static int captureBufs(struct node *node, const cv4l_queue 
,
 
 static int setupM2M(struct node *node, cv4l_queue )
 {
+   __u32 caps;
+
last_m2m_seq.init();
 
fail_on_test(q.reqbufs(node, 2));
+   caps = q.g_capabilities();
+   fail_on_test(node->supports_orphaned_bufs ^ !!(ca

Re: [PATCH v4l-utils] v4l2-compliance: test orphaned buffer support

[Hans Verkuil]

On 11/15/18 13:52, Philipp Zabel wrote:
> On Thu, 2018-11-15 at 11:21 +0100, Hans Verkuil wrote:
>> On 11/14/18 15:38, Philipp Zabel wrote:
>>> Test that V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS is reported equally for
>>> both MMAP and DMABUF memory types. If supported, try to orphan buffers
>>> by calling reqbufs(0) before unmapping or closing DMABUF fds.
>>>
>>> Also close exported DMABUF fds and free buffers in testDmaBuf if
>>> orphaned buffers are not supported.
>>>
>>> Signed-off-by: Philipp Zabel 
>>> ---
>>>  contrib/freebsd/include/linux/videodev2.h   |  1 +
>>>  include/linux/videodev2.h   |  1 +
>>>  utils/common/v4l2-info.cpp  |  1 +
>>>  utils/v4l2-compliance/v4l2-compliance.h |  1 +
>>>  utils/v4l2-compliance/v4l2-test-buffers.cpp | 35 +
>>>  5 files changed, 33 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/contrib/freebsd/include/linux/videodev2.h 
>>> b/contrib/freebsd/include/linux/videodev2.h
>>> index 9928c00e4b68..33153b53c175 100644
>>> --- a/contrib/freebsd/include/linux/videodev2.h
>>> +++ b/contrib/freebsd/include/linux/videodev2.h
>>> @@ -907,6 +907,7 @@ struct v4l2_requestbuffers {
>>>  #define V4L2_BUF_CAP_SUPPORTS_USERPTR  (1 << 1)
>>>  #define V4L2_BUF_CAP_SUPPORTS_DMABUF   (1 << 2)
>>>  #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
>>> +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
>>>  
>>>  /**
>>>   * struct v4l2_plane - plane info for multi-planar buffers
>>> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
>>> index 79418cd39480..a39300cacb6a 100644
>>> --- a/include/linux/videodev2.h
>>> +++ b/include/linux/videodev2.h
>>> @@ -873,6 +873,7 @@ struct v4l2_requestbuffers {
>>>  #define V4L2_BUF_CAP_SUPPORTS_USERPTR  (1 << 1)
>>>  #define V4L2_BUF_CAP_SUPPORTS_DMABUF   (1 << 2)
>>>  #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
>>> +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
>>>  
>>>  /**
>>>   * struct v4l2_plane - plane info for multi-planar buffers
>>> diff --git a/utils/common/v4l2-info.cpp b/utils/common/v4l2-info.cpp
>>> index 258e5446f030..3699c35cb9d6 100644
>>> --- a/utils/common/v4l2-info.cpp
>>> +++ b/utils/common/v4l2-info.cpp
>>> @@ -200,6 +200,7 @@ static const flag_def bufcap_def[] = {
>>> { V4L2_BUF_CAP_SUPPORTS_USERPTR, "userptr" },
>>> { V4L2_BUF_CAP_SUPPORTS_DMABUF, "dmabuf" },
>>> { V4L2_BUF_CAP_SUPPORTS_REQUESTS, "requests" },
>>> +   { V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS, "orphaned-bufs" },
>>> { 0, NULL }
>>>  };
>>>  
>>> diff --git a/utils/v4l2-compliance/v4l2-compliance.h 
>>> b/utils/v4l2-compliance/v4l2-compliance.h
>>> index def185f17261..88ec260a9bcc 100644
>>> --- a/utils/v4l2-compliance/v4l2-compliance.h
>>> +++ b/utils/v4l2-compliance/v4l2-compliance.h
>>> @@ -119,6 +119,7 @@ struct base_node {
>>> __u32 valid_buftypes;
>>> __u32 valid_buftype;
>>> __u32 valid_memorytype;
>>> +   bool has_orphaned_bufs;
>>
>> I'd rename that to supports_orphaned_bufs.
> 
> Ok.
> 
>>>  };
>>>  
>>>  struct node : public base_node, public cv4l_fd {
>>> diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp 
>>> b/utils/v4l2-compliance/v4l2-test-buffers.cpp
>>> index c59a56d9ced7..6174015cb4e7 100644
>>> --- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
>>> +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
>>> @@ -400,8 +400,11 @@ int testReqBufs(struct node *node)
>>> mmap_valid = !ret;
>>> if (mmap_valid)
>>> caps = q.g_capabilities();
>>> -   if (caps)
>>> +   if (caps) {
>>> fail_on_test(mmap_valid ^ !!(caps & 
>>> V4L2_BUF_CAP_SUPPORTS_MMAP));
>>> +   if (caps & V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS)
>>> +   node->has_orphaned_bufs = true;
>>> +   }
>>>  
>>> q.init(i, V4L2_MEMORY_USERPTR);
>>> ret = q.reqbufs(node, 0);
>>> @@ -418,8 +421,11 @@ int testReqBufs(struct node *node)
>>> fail_on_test(!mmap_valid && dmabuf_valid);
>>>  

Re: [PATCH v4l-utils] v4l2-compliance: test orphaned buffer support

[Philipp Zabel]

On Thu, 2018-11-15 at 11:21 +0100, Hans Verkuil wrote:
> On 11/14/18 15:38, Philipp Zabel wrote:
> > Test that V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS is reported equally for
> > both MMAP and DMABUF memory types. If supported, try to orphan buffers
> > by calling reqbufs(0) before unmapping or closing DMABUF fds.
> > 
> > Also close exported DMABUF fds and free buffers in testDmaBuf if
> > orphaned buffers are not supported.
> > 
> > Signed-off-by: Philipp Zabel 
> > ---
> >  contrib/freebsd/include/linux/videodev2.h   |  1 +
> >  include/linux/videodev2.h   |  1 +
> >  utils/common/v4l2-info.cpp  |  1 +
> >  utils/v4l2-compliance/v4l2-compliance.h |  1 +
> >  utils/v4l2-compliance/v4l2-test-buffers.cpp | 35 +
> >  5 files changed, 33 insertions(+), 6 deletions(-)
> > 
> > diff --git a/contrib/freebsd/include/linux/videodev2.h 
> > b/contrib/freebsd/include/linux/videodev2.h
> > index 9928c00e4b68..33153b53c175 100644
> > --- a/contrib/freebsd/include/linux/videodev2.h
> > +++ b/contrib/freebsd/include/linux/videodev2.h
> > @@ -907,6 +907,7 @@ struct v4l2_requestbuffers {
> >  #define V4L2_BUF_CAP_SUPPORTS_USERPTR  (1 << 1)
> >  #define V4L2_BUF_CAP_SUPPORTS_DMABUF   (1 << 2)
> >  #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
> > +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
> >  
> >  /**
> >   * struct v4l2_plane - plane info for multi-planar buffers
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index 79418cd39480..a39300cacb6a 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -873,6 +873,7 @@ struct v4l2_requestbuffers {
> >  #define V4L2_BUF_CAP_SUPPORTS_USERPTR  (1 << 1)
> >  #define V4L2_BUF_CAP_SUPPORTS_DMABUF   (1 << 2)
> >  #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
> > +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
> >  
> >  /**
> >   * struct v4l2_plane - plane info for multi-planar buffers
> > diff --git a/utils/common/v4l2-info.cpp b/utils/common/v4l2-info.cpp
> > index 258e5446f030..3699c35cb9d6 100644
> > --- a/utils/common/v4l2-info.cpp
> > +++ b/utils/common/v4l2-info.cpp
> > @@ -200,6 +200,7 @@ static const flag_def bufcap_def[] = {
> > { V4L2_BUF_CAP_SUPPORTS_USERPTR, "userptr" },
> > { V4L2_BUF_CAP_SUPPORTS_DMABUF, "dmabuf" },
> > { V4L2_BUF_CAP_SUPPORTS_REQUESTS, "requests" },
> > +   { V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS, "orphaned-bufs" },
> > { 0, NULL }
> >  };
> >  
> > diff --git a/utils/v4l2-compliance/v4l2-compliance.h 
> > b/utils/v4l2-compliance/v4l2-compliance.h
> > index def185f17261..88ec260a9bcc 100644
> > --- a/utils/v4l2-compliance/v4l2-compliance.h
> > +++ b/utils/v4l2-compliance/v4l2-compliance.h
> > @@ -119,6 +119,7 @@ struct base_node {
> > __u32 valid_buftypes;
> >     __u32 valid_buftype;
> > __u32 valid_memorytype;
> > +   bool has_orphaned_bufs;
> 
> I'd rename that to supports_orphaned_bufs.

Ok.

> >  };
> >  
> >  struct node : public base_node, public cv4l_fd {
> > diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp 
> > b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> > index c59a56d9ced7..6174015cb4e7 100644
> > --- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> > +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> > @@ -400,8 +400,11 @@ int testReqBufs(struct node *node)
> > mmap_valid = !ret;
> > if (mmap_valid)
> > caps = q.g_capabilities();
> > -   if (caps)
> > +   if (caps) {
> > fail_on_test(mmap_valid ^ !!(caps & 
> > V4L2_BUF_CAP_SUPPORTS_MMAP));
> > +   if (caps & V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS)
> > +   node->has_orphaned_bufs = true;
> > +   }
> >  
> > q.init(i, V4L2_MEMORY_USERPTR);
> > ret = q.reqbufs(node, 0);
> > @@ -418,8 +421,11 @@ int testReqBufs(struct node *node)
> > fail_on_test(!mmap_valid && dmabuf_valid);
> > // Note: dmabuf is only supported with vb2, so we can assume a
> > // non-0 caps value if dmabuf is supported.
> > -   if (caps || dmabuf_valid)
> > +   if (caps || dmabuf_valid) {
> > fail_on_test(dmabuf_valid ^ !!(caps & 
> > V4L2_BUF_CAP_S

Re: [PATCH v4l-utils] v4l2-compliance: test orphaned buffer support

[Hans Verkuil]

On 11/14/18 15:38, Philipp Zabel wrote:
> Test that V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS is reported equally for
> both MMAP and DMABUF memory types. If supported, try to orphan buffers
> by calling reqbufs(0) before unmapping or closing DMABUF fds.
> 
> Also close exported DMABUF fds and free buffers in testDmaBuf if
> orphaned buffers are not supported.
> 
> Signed-off-by: Philipp Zabel 
> ---
>  contrib/freebsd/include/linux/videodev2.h   |  1 +
>  include/linux/videodev2.h   |  1 +
>  utils/common/v4l2-info.cpp  |  1 +
>  utils/v4l2-compliance/v4l2-compliance.h     |  1 +
>  utils/v4l2-compliance/v4l2-test-buffers.cpp | 35 +
>  5 files changed, 33 insertions(+), 6 deletions(-)
> 
> diff --git a/contrib/freebsd/include/linux/videodev2.h 
> b/contrib/freebsd/include/linux/videodev2.h
> index 9928c00e4b68..33153b53c175 100644
> --- a/contrib/freebsd/include/linux/videodev2.h
> +++ b/contrib/freebsd/include/linux/videodev2.h
> @@ -907,6 +907,7 @@ struct v4l2_requestbuffers {
>  #define V4L2_BUF_CAP_SUPPORTS_USERPTR(1 << 1)
>  #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
>  #define V4L2_BUF_CAP_SUPPORTS_REQUESTS   (1 << 3)
> +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
>  
>  /**
>   * struct v4l2_plane - plane info for multi-planar buffers
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 79418cd39480..a39300cacb6a 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -873,6 +873,7 @@ struct v4l2_requestbuffers {
>  #define V4L2_BUF_CAP_SUPPORTS_USERPTR(1 << 1)
>  #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
>  #define V4L2_BUF_CAP_SUPPORTS_REQUESTS   (1 << 3)
> +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
>  
>  /**
>   * struct v4l2_plane - plane info for multi-planar buffers
> diff --git a/utils/common/v4l2-info.cpp b/utils/common/v4l2-info.cpp
> index 258e5446f030..3699c35cb9d6 100644
> --- a/utils/common/v4l2-info.cpp
> +++ b/utils/common/v4l2-info.cpp
> @@ -200,6 +200,7 @@ static const flag_def bufcap_def[] = {
>   { V4L2_BUF_CAP_SUPPORTS_USERPTR, "userptr" },
>   { V4L2_BUF_CAP_SUPPORTS_DMABUF, "dmabuf" },
>   { V4L2_BUF_CAP_SUPPORTS_REQUESTS, "requests" },
> + { V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS, "orphaned-bufs" },
>   { 0, NULL }
>  };
>  
> diff --git a/utils/v4l2-compliance/v4l2-compliance.h 
> b/utils/v4l2-compliance/v4l2-compliance.h
> index def185f17261..88ec260a9bcc 100644
> --- a/utils/v4l2-compliance/v4l2-compliance.h
> +++ b/utils/v4l2-compliance/v4l2-compliance.h
> @@ -119,6 +119,7 @@ struct base_node {
>   __u32 valid_buftypes;
>   __u32 valid_buftype;
>   __u32 valid_memorytype;
> + bool has_orphaned_bufs;

I'd rename that to supports_orphaned_bufs.

>  };
>  
>  struct node : public base_node, public cv4l_fd {
> diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp 
> b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> index c59a56d9ced7..6174015cb4e7 100644
> --- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> @@ -400,8 +400,11 @@ int testReqBufs(struct node *node)
>   mmap_valid = !ret;
>   if (mmap_valid)
>   caps = q.g_capabilities();
> - if (caps)
> + if (caps) {
>   fail_on_test(mmap_valid ^ !!(caps & 
> V4L2_BUF_CAP_SUPPORTS_MMAP));
> + if (caps & V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS)
> + node->has_orphaned_bufs = true;
> + }
>  
>   q.init(i, V4L2_MEMORY_USERPTR);
>   ret = q.reqbufs(node, 0);
> @@ -418,8 +421,11 @@ int testReqBufs(struct node *node)
>   fail_on_test(!mmap_valid && dmabuf_valid);
>   // Note: dmabuf is only supported with vb2, so we can assume a
>   // non-0 caps value if dmabuf is supported.
> - if (caps || dmabuf_valid)
> + if (caps || dmabuf_valid) {
>   fail_on_test(dmabuf_valid ^ !!(caps & 
> V4L2_BUF_CAP_SUPPORTS_DMABUF));
> + if (node->has_orphaned_bufs)
> + fail_on_test(userptr_valid ^ !!(caps & 
> V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS));

Huh? I'm not sure what you are testing here.

> + }
>  
>   fail_on_test((can_stream && !is_overlay) && !mmap_valid && 
> !userptr_valid && !dmabuf_valid);
>   fail_on_test((!can_stream || is_overlay) &&

[PATCH v4l-utils] v4l2-compliance: limit acceptable width/height to 65536 in VIDIOC_SUBDEV_G/S_FMT test

[Philipp Zabel]

Fail if the driver returns unrealistically large frame sizes.

Signed-off-by: Philipp Zabel 
---
 utils/v4l2-compliance/v4l2-test-subdevs.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/utils/v4l2-compliance/v4l2-test-subdevs.cpp 
b/utils/v4l2-compliance/v4l2-test-subdevs.cpp
index 031fd6e78c56..29987b310448 100644
--- a/utils/v4l2-compliance/v4l2-test-subdevs.cpp
+++ b/utils/v4l2-compliance/v4l2-test-subdevs.cpp
@@ -308,8 +308,8 @@ int testSubDevFrameInterval(struct node *node, unsigned pad)
 static int checkMBusFrameFmt(struct node *node, struct v4l2_mbus_framefmt )
 {
fail_on_test(check_0(fmt.reserved, sizeof(fmt.reserved)));
-   fail_on_test(fmt.width == 0 || fmt.width == ~0U);
-   fail_on_test(fmt.height == 0 || fmt.height == ~0U);
+   fail_on_test(fmt.width == 0 || fmt.width > 65536);
+   fail_on_test(fmt.height == 0 || fmt.height > 65536);
fail_on_test(fmt.code == 0 || fmt.code == ~0U);
fail_on_test(fmt.field == ~0U);
if (!node->is_passthrough_subdev) {
-- 
2.19.1

[PATCH v4l-utils] v4l2-compliance: test orphaned buffer support

[Philipp Zabel]

Test that V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS is reported equally for
both MMAP and DMABUF memory types. If supported, try to orphan buffers
by calling reqbufs(0) before unmapping or closing DMABUF fds.

Also close exported DMABUF fds and free buffers in testDmaBuf if
orphaned buffers are not supported.

Signed-off-by: Philipp Zabel 
---
 contrib/freebsd/include/linux/videodev2.h   |  1 +
 include/linux/videodev2.h   |  1 +
 utils/common/v4l2-info.cpp  |  1 +
 utils/v4l2-compliance/v4l2-compliance.h |  1 +
 utils/v4l2-compliance/v4l2-test-buffers.cpp | 35 +
 5 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/contrib/freebsd/include/linux/videodev2.h 
b/contrib/freebsd/include/linux/videodev2.h
index 9928c00e4b68..33153b53c175 100644
--- a/contrib/freebsd/include/linux/videodev2.h
+++ b/contrib/freebsd/include/linux/videodev2.h
@@ -907,6 +907,7 @@ struct v4l2_requestbuffers {
 #define V4L2_BUF_CAP_SUPPORTS_USERPTR  (1 << 1)
 #define V4L2_BUF_CAP_SUPPORTS_DMABUF   (1 << 2)
 #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
+#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
 
 /**
  * struct v4l2_plane - plane info for multi-planar buffers
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 79418cd39480..a39300cacb6a 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -873,6 +873,7 @@ struct v4l2_requestbuffers {
 #define V4L2_BUF_CAP_SUPPORTS_USERPTR  (1 << 1)
 #define V4L2_BUF_CAP_SUPPORTS_DMABUF   (1 << 2)
 #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
+#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
 
 /**
  * struct v4l2_plane - plane info for multi-planar buffers
diff --git a/utils/common/v4l2-info.cpp b/utils/common/v4l2-info.cpp
index 258e5446f030..3699c35cb9d6 100644
--- a/utils/common/v4l2-info.cpp
+++ b/utils/common/v4l2-info.cpp
@@ -200,6 +200,7 @@ static const flag_def bufcap_def[] = {
{ V4L2_BUF_CAP_SUPPORTS_USERPTR, "userptr" },
{ V4L2_BUF_CAP_SUPPORTS_DMABUF, "dmabuf" },
{ V4L2_BUF_CAP_SUPPORTS_REQUESTS, "requests" },
+   { V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS, "orphaned-bufs" },
{ 0, NULL }
 };
 
diff --git a/utils/v4l2-compliance/v4l2-compliance.h 
b/utils/v4l2-compliance/v4l2-compliance.h
index def185f17261..88ec260a9bcc 100644
--- a/utils/v4l2-compliance/v4l2-compliance.h
+++ b/utils/v4l2-compliance/v4l2-compliance.h
@@ -119,6 +119,7 @@ struct base_node {
__u32 valid_buftypes;
__u32 valid_buftype;
__u32 valid_memorytype;
+   bool has_orphaned_bufs;
 };
 
 struct node : public base_node, public cv4l_fd {
diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp 
b/utils/v4l2-compliance/v4l2-test-buffers.cpp
index c59a56d9ced7..6174015cb4e7 100644
--- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
+++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
@@ -400,8 +400,11 @@ int testReqBufs(struct node *node)
mmap_valid = !ret;
if (mmap_valid)
caps = q.g_capabilities();
-   if (caps)
+   if (caps) {
fail_on_test(mmap_valid ^ !!(caps & 
V4L2_BUF_CAP_SUPPORTS_MMAP));
+   if (caps & V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS)
+   node->has_orphaned_bufs = true;
+   }
 
q.init(i, V4L2_MEMORY_USERPTR);
ret = q.reqbufs(node, 0);
@@ -418,8 +421,11 @@ int testReqBufs(struct node *node)
fail_on_test(!mmap_valid && dmabuf_valid);
// Note: dmabuf is only supported with vb2, so we can assume a
// non-0 caps value if dmabuf is supported.
-   if (caps || dmabuf_valid)
+   if (caps || dmabuf_valid) {
fail_on_test(dmabuf_valid ^ !!(caps & 
V4L2_BUF_CAP_SUPPORTS_DMABUF));
+   if (node->has_orphaned_bufs)
+   fail_on_test(userptr_valid ^ !!(caps & 
V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS));
+   }
 
fail_on_test((can_stream && !is_overlay) && !mmap_valid && 
!userptr_valid && !dmabuf_valid);
fail_on_test((!can_stream || is_overlay) && (mmap_valid || 
userptr_valid || dmabuf_valid));
@@ -967,12 +973,22 @@ int testMmap(struct node *node, unsigned frame_count)
fail_on_test(captureBufs(node, q, m2m_q, frame_count, true));
fail_on_test(node->streamoff(q.g_type()));
fail_on_test(node->streamoff(q.g_type()));
-   q.munmap_bufs(node);
-   fail_on_test(q.reqbufs(node, 0));
+   if (node->has_orphaned_bufs) {
+   fail_on_test(q.reqbufs(node, 0));
+   q.munmap_bufs(node);
+  

RE: [PATCH] media: imx258: remove test pattern map from driver

[Chen, JasonX Z]

Hi Sakari 

Thanks for your feedback.
I will update to the next patch.

B.R.,
Jason

-Original Message-
From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com] 
Sent: Wednesday, November 7, 2018 6:32 PM
To: Chen, JasonX Z 
Cc: linux-media@vger.kernel.org; Yeh, Andy ; 
tf...@chromium.org
Subject: Re: [PATCH] media: imx258: remove test pattern map from driver

Hi Jason,

Thanks for the patch.

On Wed, Nov 07, 2018 at 03:22:23PM +0800, jasonx.z.c...@intel.com wrote:
> From: "Chen, JasonX Z" 
> 
> Test Pattern mode be picked at HAL instead of driver.
> do a FLIP when userspace use test pattern mode.
> add entity_ops for validating imx258 link.
> 
> Signed-off-by: Chen, JasonX Z 
> ---
>  drivers/media/i2c/imx258.c | 28 
>  1 file changed, 8 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c 
> index 31a1e22..71f9875 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -62,11 +62,6 @@
>  
>  /* Test Pattern Control */
>  #define IMX258_REG_TEST_PATTERN  0x0600
> -#define IMX258_TEST_PATTERN_DISABLE  0
> -#define IMX258_TEST_PATTERN_SOLID_COLOR  1
> -#define IMX258_TEST_PATTERN_COLOR_BARS   2
> -#define IMX258_TEST_PATTERN_GREY_COLOR   3
> -#define IMX258_TEST_PATTERN_PN9  4
>  
>  /* Orientation */
>  #define REG_MIRROR_FLIP_CONTROL  0x0101
> @@ -504,20 +499,12 @@ struct imx258_mode {
>  
>  static const char * const imx258_test_pattern_menu[] = {
>   "Disabled",
> - "Color Bars",
>   "Solid Color",
> + "Color Bars",
>   "Grey Color Bars",
>   "PN9"
>  };
>  
> -static const int imx258_test_pattern_val[] = {
> - IMX258_TEST_PATTERN_DISABLE,
> - IMX258_TEST_PATTERN_COLOR_BARS,
> - IMX258_TEST_PATTERN_SOLID_COLOR,
> - IMX258_TEST_PATTERN_GREY_COLOR,
> - IMX258_TEST_PATTERN_PN9,
> -};
> -
>  /* Configurations for supported link frequencies */
>  #define IMX258_LINK_FREQ_634MHZ  63360ULL
>  #define IMX258_LINK_FREQ_320MHZ  32000ULL
> @@ -752,7 +739,6 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
>   container_of(ctrl->handler, struct imx258, ctrl_handler);
>   struct i2c_client *client = v4l2_get_subdevdata(>sd);
>   int ret = 0;
> -

This seems like an unrelated change, and it's a common (and usually good) 
practice to add an empty line after variable declarations.

>   /*
>* Applying V4L2 control value only happens
>* when power is up for streaming
> @@ -778,13 +764,10 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
>   case V4L2_CID_TEST_PATTERN:
>   ret = imx258_write_reg(imx258, IMX258_REG_TEST_PATTERN,
>   IMX258_REG_VALUE_16BIT,
> - imx258_test_pattern_val[ctrl->val]);
> -
> + ctrl->val);
>   ret = imx258_write_reg(imx258, REG_MIRROR_FLIP_CONTROL,
>   IMX258_REG_VALUE_08BIT,
> - ctrl->val == imx258_test_pattern_val
> - [IMX258_TEST_PATTERN_DISABLE] ?
> - REG_CONFIG_MIRROR_FLIP :
> + !ctrl->val?REG_CONFIG_MIRROR_FLIP :
>   REG_CONFIG_FLIP_TEST_PATTERN);
>   break;
>   default:
> @@ -1105,6 +1088,10 @@ static int imx258_identify_module(struct imx258 
> *imx258)
>   .pad = _pad_ops,
>  };
>  
> +static const struct media_entity_operations imx258_subdev_entity_ops = {
> + .link_validate = v4l2_subdev_link_validate, };
> +

This seems unrelated as well. Do you need the link validation for something?
As far as I understand, the driver exposes a single source pad; therefore the 
link_validate op will never be called.

>  static const struct v4l2_subdev_internal_ops imx258_internal_ops = {
>   .open = imx258_open,
>  };
> @@ -1250,6 +1237,7 @@ static int imx258_probe(struct i2c_client 
> *client)
>  
>   /* Initialize subdev */
>   imx258->sd.internal_ops = _internal_ops;
> + imx258->sd.entity.ops  = _subdev_entity_ops;

Ditto.

>   imx258->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>   imx258->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
>  

--
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com

[PATCH] media: imx258: remove test pattern map from driver

[jasonx . z . chen]

From: "Chen, JasonX Z" 

change bayer order when using test pattern mode.
remove test pattern mapping method

Signed-off-by: Chen, JasonX Z 
---
 drivers/media/i2c/imx258.c | 23 ---
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index 31a1e22..5a72b4a 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -62,11 +62,6 @@
 
 /* Test Pattern Control */
 #define IMX258_REG_TEST_PATTERN0x0600
-#define IMX258_TEST_PATTERN_DISABLE0
-#define IMX258_TEST_PATTERN_SOLID_COLOR1
-#define IMX258_TEST_PATTERN_COLOR_BARS 2
-#define IMX258_TEST_PATTERN_GREY_COLOR 3
-#define IMX258_TEST_PATTERN_PN94
 
 /* Orientation */
 #define REG_MIRROR_FLIP_CONTROL0x0101
@@ -504,20 +499,12 @@ struct imx258_mode {
 
 static const char * const imx258_test_pattern_menu[] = {
"Disabled",
-   "Color Bars",
"Solid Color",
+   "Color Bars",
"Grey Color Bars",
"PN9"
 };
 
-static const int imx258_test_pattern_val[] = {
-   IMX258_TEST_PATTERN_DISABLE,
-   IMX258_TEST_PATTERN_COLOR_BARS,
-   IMX258_TEST_PATTERN_SOLID_COLOR,
-   IMX258_TEST_PATTERN_GREY_COLOR,
-   IMX258_TEST_PATTERN_PN9,
-};
-
 /* Configurations for supported link frequencies */
 #define IMX258_LINK_FREQ_634MHZ63360ULL
 #define IMX258_LINK_FREQ_320MHZ32000ULL
@@ -757,6 +744,7 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
 * Applying V4L2 control value only happens
 * when power is up for streaming
 */
+
if (pm_runtime_get_if_in_use(>dev) == 0)
return 0;
 
@@ -778,13 +766,10 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_TEST_PATTERN:
ret = imx258_write_reg(imx258, IMX258_REG_TEST_PATTERN,
IMX258_REG_VALUE_16BIT,
-   imx258_test_pattern_val[ctrl->val]);
-
+   ctrl->val);
ret = imx258_write_reg(imx258, REG_MIRROR_FLIP_CONTROL,
IMX258_REG_VALUE_08BIT,
-   ctrl->val == imx258_test_pattern_val
-   [IMX258_TEST_PATTERN_DISABLE] ?
-   REG_CONFIG_MIRROR_FLIP :
+   !ctrl->val ? REG_CONFIG_MIRROR_FLIP :
REG_CONFIG_FLIP_TEST_PATTERN);
break;
default:
-- 
1.9.1

Re: [RFC] Create test script(s?) for regression testing

[Shuah Khan]

On 11/07/2018 12:10 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 07 Nov 2018 12:06:55 +0200
> Laurent Pinchart  escreveu:
> 
>> Hi Hans,
>>
>> On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote:
>>> On 11/06/2018 08:58 PM, Laurent Pinchart wrote:  
>>>> On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote:  
>>>>> On 11/06/18 14:12, Laurent Pinchart wrote:  
>>>>>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:  
>>>>>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:  
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> After the media summit (heavy on test discussions) and the V4L2 event
>>>>>>>> regression we just found it is clear we need to do a better job with
>>>>>>>> testing.
>>>>>>>>
>>>>>>>> All the pieces are in place, so what is needed is to combine it and
>>>>>>>> create a script that anyone of us as core developers can run to check
>>>>>>>> for regressions. The same script can be run as part of the kernelci
>>>>>>>> regression testing.  
>>>>>>>
>>>>>>> I'd say that *some* pieces are in place. Of course, the more there is,
>>>>>>> the better.
>>>>>>>
>>>>>>> The more there are tests, the more important it would be they're
>>>>>>> automated, preferrably without the developer having to run them on his/
>>>>>>> her own machine.  
>>>>>>
>>>>>> From my experience with testing, it's important to have both a core set
>>>>>> of tests (a.k.a. smoke tests) that can easily be run on developers'
>>>>>> machines, and extended tests that can be offloaded to a shared testing
>>>>>> infrastructure (but possibly also run locally if desired).  
>>>>>
>>>>> That was my idea as well for the longer term. First step is to do the
>>>>> basic smoke tests (i.e. run compliance tests, do some (limited) streaming
>>>>> test).
>>>>>
>>>>> There are more extensive (and longer running) tests that can be done, but
>>>>> that's something to look at later.
>>>>>   
>>>>>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last
>>>>>>>> one is IMHO not quite good enough yet for testing: it is not fully
>>>>>>>> compliant to the upcoming stateful codec spec. Work for that is
>>>>>>>> planned as part of an Outreachy project.
>>>>>>>>
>>>>>>>> My idea is to create a script that is maintained as part of v4l-utils
>>>>>>>> that loads the drivers and runs v4l2-compliance and possibly other
>>>>>>>> tests against the virtual drivers.  
> 
> (adding Shuah)
> 
> IMO, the best would be to have something like that as part of Kernel
> self test, as this could give a broader covering than just Kernel CI.
> 

I agree with the broader coverage benefit that comes with adding tests to 
kselftest.
It makes it easier for making changes to tests/tools coupled with kernel/driver
changes. Common TAP13 reporting can be taken advantage of without doing any 
additional
work in the tests if author chooses to do so.

Tests can be added such that they don't get run by default if there is a reason 
do so
and Kernel CI and other rings can invoke it as a special case if necessary.

There are very clear advantages to making these tests part of the kernel source 
tree.
We can discuss at the Kernel Summit next week if you are interested.

thanks,
-- Shuah

Re: [RFC] Create test script(s?) for regression testing

[Laurent Pinchart]

Hi Mauro,

On Wednesday, 7 November 2018 21:53:20 EET Mauro Carvalho Chehab wrote:
> Em Wed, 07 Nov 2018 21:35:32 +0200 Laurent Pinchart escreveu:
> > On Wednesday, 7 November 2018 21:10:35 EET Mauro Carvalho Chehab wrote:

[snip]

> >> I'm with Hans on that matter: better to start with an absolute minimum
> >> of dependencies (like just: make, autotools, c, c++, bash),
> > 
> > On a site note, for a new project, we might want to move away from
> > autotools. cmake and meson are possible alternatives that are way less
> > painful.
> 
> Each toolset has advantages or disadvantages. We all know how
> autotools can be painful.
> 
> One bad thing with cmake is that they deprecate stuff. A long-live project
> usually require several" backward" compat stuff at cmake files in order
> to cope with different behaviors that change as cmake evolves.

I don't know how much of a problem that would be. My experience with cmake is 
good so far, but I haven't used it in a large scale project with 10+ years of 
contributions :-)

> I never used mason myself.

It's the build system we picked for libcamera, I expect to provide feedback in 
the not too distant future.

[snip]

-- 
Regards,

Laurent Pinchart

Re: [RFC] Create test script(s?) for regression testing

[Mauro Carvalho Chehab]

Em Wed, 07 Nov 2018 21:35:32 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Wednesday, 7 November 2018 21:10:35 EET Mauro Carvalho Chehab wrote:
> > Em Wed, 07 Nov 2018 12:06:55 +0200 Laurent Pinchart escreveu:  
> > > On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote:  
> > >> On 11/06/2018 08:58 PM, Laurent Pinchart wrote:  
> > >>> On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote:  
> > >>>> On 11/06/18 14:12, Laurent Pinchart wrote:  
> > >>>>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:  
> > >>>>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:  
> > >>>>>>> Hi all,
> > >>>>>>> 
> > >>>>>>> After the media summit (heavy on test discussions) and the V4L2
> > >>>>>>> event regression we just found it is clear we need to do a better
> > >>>>>>> job with testing.
> > >>>>>>> 
> > >>>>>>> All the pieces are in place, so what is needed is to combine it
> > >>>>>>> and create a script that anyone of us as core developers can run to
> > >>>>>>> check for regressions. The same script can be run as part of the
> > >>>>>>> kernelci regression testing.  
> > >>>>>> 
> > >>>>>> I'd say that *some* pieces are in place. Of course, the more there
> > >>>>>> is, the better.
> > >>>>>> 
> > >>>>>> The more there are tests, the more important it would be they're
> > >>>>>> automated, preferrably without the developer having to run them on
> > >>>>>> his/her own machine.  
> > >>>>> 
> > >>>>> From my experience with testing, it's important to have both a core
> > >>>>> set of tests (a.k.a. smoke tests) that can easily be run on
> > >>>>> developers' machines, and extended tests that can be offloaded to a
> > >>>>> shared testing infrastructure (but possibly also run locally if
> > >>>>> desired).  
> > >>>> 
> > >>>> That was my idea as well for the longer term. First step is to do the
> > >>>> basic smoke tests (i.e. run compliance tests, do some (limited)
> > >>>> streaming test).
> > >>>> 
> > >>>> There are more extensive (and longer running) tests that can be done,
> > >>>> but that's something to look at later.
> > >>>>   
> > >>>>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The
> > >>>>>>> last one is IMHO not quite good enough yet for testing: it is not
> > >>>>>>> fully compliant to the upcoming stateful codec spec. Work for that
> > >>>>>>> is planned as part of an Outreachy project.
> > >>>>>>> 
> > >>>>>>> My idea is to create a script that is maintained as part of
> > >>>>>>> v4l-utils that loads the drivers and runs v4l2-compliance and
> > >>>>>>> possibly other tests against the virtual drivers.  
> > 
> > (adding Shuah)
> > 
> > IMO, the best would be to have something like that as part of Kernel
> > self test, as this could give a broader covering than just Kernel CI.
> > 
> > Yeah, I know that one of the concerns is that the *-compliance stuff
> > we have are written in C++ and it is easier to maintain then at
> > v4l-utils, but maybe it would be acceptable at kselftest to have a
> > test bench there with would download the sources from a git tree
> > and then build just the v4l2-compliance stuff, e. g. having a Kernel
> > self test target that would do something like:
> > 
> >     git clone --depth 1 git://linuxtv.org/v4l-utils.git tests && \
> > cd tests && ./autogen.sh && make tests && ./run_tests.sh  
> 
> Let me make sure I understand this properly. Are you proposing to add to 
> kselftest, which is part of the Linux kernel, and as such benefits from the 
> level of trust of Linus' tree, and which is run by a very large number of 
> machines from developer workstations to automated large-scale test 
> infrastructure, a provision to execute locally code that is downloaded at 
> runtime from the internet, with all the security issues this implies ?

Re: [RFC] Create test script(s?) for regression testing

[Ezequiel Garcia]

On Wed, 2018-11-07 at 09:05 +0100, Hans Verkuil wrote:
> On 11/06/2018 08:58 PM, Laurent Pinchart wrote:
> > Hi Hans,
> > 
> > On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote:
> > > On 11/06/18 14:12, Laurent Pinchart wrote:
> > > > On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:
> > > > > On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > After the media summit (heavy on test discussions) and the V4L2 
> > > > > > event
> > > > > > regression we just found it is clear we need to do a better job with
> > > > > > testing.
> > > > > > 
> > > > > > All the pieces are in place, so what is needed is to combine it and
> > > > > > create a script that anyone of us as core developers can run to 
> > > > > > check
> > > > > > for regressions. The same script can be run as part of the kernelci
> > > > > > regression testing.
> > > > > 
> > > > > I'd say that *some* pieces are in place. Of course, the more there is,
> > > > > the better.
> > > > > 
> > > > > The more there are tests, the more important it would be they're
> > > > > automated, preferrably without the developer having to run them on 
> > > > > his/
> > > > > her own machine.
> > > > 
> > > > From my experience with testing, it's important to have both a core set 
> > > > of
> > > > tests (a.k.a. smoke tests) that can easily be run on developers' 
> > > > machines,
> > > > and extended tests that can be offloaded to a shared testing
> > > > infrastructure (but possibly also run locally if desired).
> > > 
> > > That was my idea as well for the longer term. First step is to do the 
> > > basic
> > > smoke tests (i.e. run compliance tests, do some (limited) streaming test).
> > > 
> > > There are more extensive (and longer running) tests that can be done, but
> > > that's something to look at later.
> > > 
> > > > > > We have four virtual drivers: vivid, vim2m, vimc and vicodec. The 
> > > > > > last
> > > > > > one is IMHO not quite good enough yet for testing: it is not fully
> > > > > > compliant to the upcoming stateful codec spec. Work for that is 
> > > > > > planned
> > > > > > as part of an Outreachy project.
> > > > > > 
> > > > > > My idea is to create a script that is maintained as part of 
> > > > > > v4l-utils
> > > > > > that loads the drivers and runs v4l2-compliance and possibly other 
> > > > > > tests
> > > > > > against the virtual drivers.
> > > > > 
> > > > > How about spending a little time to pick a suitable framework for 
> > > > > running
> > > > > the tests? It could be useful to get more informative reports than 
> > > > > just
> > > > > pass / fail.
> > > > 
> > > > We should keep in mind that other tests will be added later, and the 
> > > > test
> > > > framework should make that easy.
> > > 
> > > Since we want to be able to run this on kernelci.org, I think it makes 
> > > sense
> > > to let the kernelci folks (Hi Ezequiel!) decide this.
> > 
> > KernelCI isn't the only test infrastructure out there, so let's not forget 
> > about the other ones.
> 
> True, but they are putting time and money into this, so they get to choose as
> far as I am concerned :-)
> 

Well, we are also resource-constrained, so my idea for the first iteration
is to pick the simplest yet useful setup. We plan to leverage existing
tests only. Currently xxx-compliance tools are what cover more.

I believe that CI and tests should be independent components.

> If others are interested and willing to put up time and money, they should let
> themselves be known.
> 
> I'm not going to work on such an integration, although I happily accept 
> patches.
> 
> > > As a developer all I need is a script to run smoke tests so I can catch 
> > > most
> > > regressions (you never catch all).
> > > 
> > > I'm happy to work with them to make any changes to compliance tools and
> > > scripts so they fit better into their test framework.
> > > 
> > >

Re: [RFC] Create test script(s?) for regression testing

[Laurent Pinchart]

Hi Mauro,

On Wednesday, 7 November 2018 21:10:35 EET Mauro Carvalho Chehab wrote:
> Em Wed, 07 Nov 2018 12:06:55 +0200 Laurent Pinchart escreveu:
> > On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote:
> >> On 11/06/2018 08:58 PM, Laurent Pinchart wrote:
> >>> On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote:
> >>>> On 11/06/18 14:12, Laurent Pinchart wrote:
> >>>>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:
> >>>>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:
> >>>>>>> Hi all,
> >>>>>>> 
> >>>>>>> After the media summit (heavy on test discussions) and the V4L2
> >>>>>>> event regression we just found it is clear we need to do a better
> >>>>>>> job with testing.
> >>>>>>> 
> >>>>>>> All the pieces are in place, so what is needed is to combine it
> >>>>>>> and create a script that anyone of us as core developers can run to
> >>>>>>> check for regressions. The same script can be run as part of the
> >>>>>>> kernelci regression testing.
> >>>>>> 
> >>>>>> I'd say that *some* pieces are in place. Of course, the more there
> >>>>>> is, the better.
> >>>>>> 
> >>>>>> The more there are tests, the more important it would be they're
> >>>>>> automated, preferrably without the developer having to run them on
> >>>>>> his/her own machine.
> >>>>> 
> >>>>> From my experience with testing, it's important to have both a core
> >>>>> set of tests (a.k.a. smoke tests) that can easily be run on
> >>>>> developers' machines, and extended tests that can be offloaded to a
> >>>>> shared testing infrastructure (but possibly also run locally if
> >>>>> desired).
> >>>> 
> >>>> That was my idea as well for the longer term. First step is to do the
> >>>> basic smoke tests (i.e. run compliance tests, do some (limited)
> >>>> streaming test).
> >>>> 
> >>>> There are more extensive (and longer running) tests that can be done,
> >>>> but that's something to look at later.
> >>>> 
> >>>>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The
> >>>>>>> last one is IMHO not quite good enough yet for testing: it is not
> >>>>>>> fully compliant to the upcoming stateful codec spec. Work for that
> >>>>>>> is planned as part of an Outreachy project.
> >>>>>>> 
> >>>>>>> My idea is to create a script that is maintained as part of
> >>>>>>> v4l-utils that loads the drivers and runs v4l2-compliance and
> >>>>>>> possibly other tests against the virtual drivers.
> 
> (adding Shuah)
> 
> IMO, the best would be to have something like that as part of Kernel
> self test, as this could give a broader covering than just Kernel CI.
> 
> Yeah, I know that one of the concerns is that the *-compliance stuff
> we have are written in C++ and it is easier to maintain then at
> v4l-utils, but maybe it would be acceptable at kselftest to have a
> test bench there with would download the sources from a git tree
> and then build just the v4l2-compliance stuff, e. g. having a Kernel
> self test target that would do something like:
> 
>   git clone --depth 1 git://linuxtv.org/v4l-utils.git tests && \
>   cd tests && ./autogen.sh && make tests && ./run_tests.sh

Let me make sure I understand this properly. Are you proposing to add to 
kselftest, which is part of the Linux kernel, and as such benefits from the 
level of trust of Linus' tree, and which is run by a very large number of 
machines from developer workstations to automated large-scale test 
infrastructure, a provision to execute locally code that is downloaded at 
runtime from the internet, with all the security issues this implies ?

> (the actual selftest target would likely be different, as it
>  should take into account make O=)
> 
> If this would be acceptable upstream, then we'll need to stick with the
> output format defined by Kernel Self Test[1].
> 
> [1] I guess it uses the TAP13 format:
>   https://testanything.org/tap-version-13-specification.html
> 
> >>>>>> How about spending a little time to pick

Re: [RFC] Create test script(s?) for regression testing

[Mauro Carvalho Chehab]

Em Wed, 07 Nov 2018 12:06:55 +0200
Laurent Pinchart  escreveu:

> Hi Hans,
> 
> On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote:
> > On 11/06/2018 08:58 PM, Laurent Pinchart wrote:  
> > > On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote:  
> > >> On 11/06/18 14:12, Laurent Pinchart wrote:  
> > >>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:  
> > >>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:  
> > >>>>> Hi all,
> > >>>>> 
> > >>>>> After the media summit (heavy on test discussions) and the V4L2 event
> > >>>>> regression we just found it is clear we need to do a better job with
> > >>>>> testing.
> > >>>>> 
> > >>>>> All the pieces are in place, so what is needed is to combine it and
> > >>>>> create a script that anyone of us as core developers can run to check
> > >>>>> for regressions. The same script can be run as part of the kernelci
> > >>>>> regression testing.  
> > >>>> 
> > >>>> I'd say that *some* pieces are in place. Of course, the more there is,
> > >>>> the better.
> > >>>> 
> > >>>> The more there are tests, the more important it would be they're
> > >>>> automated, preferrably without the developer having to run them on his/
> > >>>> her own machine.  
> > >>> 
> > >>> From my experience with testing, it's important to have both a core set
> > >>> of tests (a.k.a. smoke tests) that can easily be run on developers'
> > >>> machines, and extended tests that can be offloaded to a shared testing
> > >>> infrastructure (but possibly also run locally if desired).  
> > >> 
> > >> That was my idea as well for the longer term. First step is to do the
> > >> basic smoke tests (i.e. run compliance tests, do some (limited) streaming
> > >> test).
> > >> 
> > >> There are more extensive (and longer running) tests that can be done, but
> > >> that's something to look at later.
> > >>   
> > >>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last
> > >>>>> one is IMHO not quite good enough yet for testing: it is not fully
> > >>>>> compliant to the upcoming stateful codec spec. Work for that is
> > >>>>> planned as part of an Outreachy project.
> > >>>>> 
> > >>>>> My idea is to create a script that is maintained as part of v4l-utils
> > >>>>> that loads the drivers and runs v4l2-compliance and possibly other
> > >>>>> tests against the virtual drivers.  

(adding Shuah)

IMO, the best would be to have something like that as part of Kernel
self test, as this could give a broader covering than just Kernel CI.

Yeah, I know that one of the concerns is that the *-compliance stuff
we have are written in C++ and it is easier to maintain then at
v4l-utils, but maybe it would be acceptable at kselftest to have a
test bench there with would download the sources from a git tree
and then build just the v4l2-compliance stuff, e. g. having a Kernel
self test target that would do something like:

git clone --depth 1 git://linuxtv.org/v4l-utils.git tests && \
cd tests && ./autogen.sh && make tests && ./run_tests.sh

(the actual selftest target would likely be different, as it 
 should take into account make O=)

If this would be acceptable upstream, then we'll need to stick with the
output format defined by Kernel Self Test[1].

[1] I guess it uses the TAP13 format:
https://testanything.org/tap-version-13-specification.html

> > >>>> 
> > >>>> How about spending a little time to pick a suitable framework for
> > >>>> running the tests? It could be useful to get more informative reports
> > >>>> than just pass / fail.  
> > >>> 
> > >>> We should keep in mind that other tests will be added later, and the
> > >>> test framework should make that easy.  
> > >> 
> > >> Since we want to be able to run this on kernelci.org, I think it makes
> > >> sense to let the kernelci folks (Hi Ezequiel!) decide this.  
> > > 
> > > KernelCI isn't the only test infrastructure out there, so let's not forget
> > > about the other ones.  
> > 
> > True, but they are putting ti

Re: [PATCH] media: imx258: remove test pattern map from driver

[Sakari Ailus]

Hi Jason,

Thanks for the patch.

On Wed, Nov 07, 2018 at 03:22:23PM +0800, jasonx.z.c...@intel.com wrote:
> From: "Chen, JasonX Z" 
> 
> Test Pattern mode be picked at HAL instead of driver.
> do a FLIP when userspace use test pattern mode.
> add entity_ops for validating imx258 link.
> 
> Signed-off-by: Chen, JasonX Z 
> ---
>  drivers/media/i2c/imx258.c | 28 
>  1 file changed, 8 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index 31a1e22..71f9875 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -62,11 +62,6 @@
>  
>  /* Test Pattern Control */
>  #define IMX258_REG_TEST_PATTERN  0x0600
> -#define IMX258_TEST_PATTERN_DISABLE  0
> -#define IMX258_TEST_PATTERN_SOLID_COLOR  1
> -#define IMX258_TEST_PATTERN_COLOR_BARS   2
> -#define IMX258_TEST_PATTERN_GREY_COLOR   3
> -#define IMX258_TEST_PATTERN_PN9  4
>  
>  /* Orientation */
>  #define REG_MIRROR_FLIP_CONTROL  0x0101
> @@ -504,20 +499,12 @@ struct imx258_mode {
>  
>  static const char * const imx258_test_pattern_menu[] = {
>   "Disabled",
> - "Color Bars",
>   "Solid Color",
> + "Color Bars",
>   "Grey Color Bars",
>   "PN9"
>  };
>  
> -static const int imx258_test_pattern_val[] = {
> - IMX258_TEST_PATTERN_DISABLE,
> - IMX258_TEST_PATTERN_COLOR_BARS,
> - IMX258_TEST_PATTERN_SOLID_COLOR,
> - IMX258_TEST_PATTERN_GREY_COLOR,
> - IMX258_TEST_PATTERN_PN9,
> -};
> -
>  /* Configurations for supported link frequencies */
>  #define IMX258_LINK_FREQ_634MHZ  63360ULL
>  #define IMX258_LINK_FREQ_320MHZ  32000ULL
> @@ -752,7 +739,6 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
>   container_of(ctrl->handler, struct imx258, ctrl_handler);
>   struct i2c_client *client = v4l2_get_subdevdata(>sd);
>   int ret = 0;
> -

This seems like an unrelated change, and it's a common (and usually good)
practice to add an empty line after variable declarations.

>   /*
>* Applying V4L2 control value only happens
>* when power is up for streaming
> @@ -778,13 +764,10 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
>   case V4L2_CID_TEST_PATTERN:
>   ret = imx258_write_reg(imx258, IMX258_REG_TEST_PATTERN,
>   IMX258_REG_VALUE_16BIT,
> - imx258_test_pattern_val[ctrl->val]);
> -
> + ctrl->val);
>   ret = imx258_write_reg(imx258, REG_MIRROR_FLIP_CONTROL,
>   IMX258_REG_VALUE_08BIT,
> - ctrl->val == imx258_test_pattern_val
> - [IMX258_TEST_PATTERN_DISABLE] ?
> - REG_CONFIG_MIRROR_FLIP :
> + !ctrl->val?REG_CONFIG_MIRROR_FLIP :
>   REG_CONFIG_FLIP_TEST_PATTERN);
>   break;
>   default:
> @@ -1105,6 +1088,10 @@ static int imx258_identify_module(struct imx258 
> *imx258)
>   .pad = _pad_ops,
>  };
>  
> +static const struct media_entity_operations imx258_subdev_entity_ops = {
> + .link_validate = v4l2_subdev_link_validate,
> +};
> +

This seems unrelated as well. Do you need the link validation for something?
As far as I understand, the driver exposes a single source pad; therefore
the link_validate op will never be called.

>  static const struct v4l2_subdev_internal_ops imx258_internal_ops = {
>   .open = imx258_open,
>  };
> @@ -1250,6 +1237,7 @@ static int imx258_probe(struct i2c_client *client)
>  
>   /* Initialize subdev */
>   imx258->sd.internal_ops = _internal_ops;
> + imx258->sd.entity.ops  = _subdev_entity_ops;

Ditto.

>   imx258->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>   imx258->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
>  

-- 
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [RFC] Create test script(s?) for regression testing

[Laurent Pinchart]

Hi Hans,

On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote:
> On 11/06/2018 08:58 PM, Laurent Pinchart wrote:
> > On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote:
> >> On 11/06/18 14:12, Laurent Pinchart wrote:
> >>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:
> >>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:
> >>>>> Hi all,
> >>>>> 
> >>>>> After the media summit (heavy on test discussions) and the V4L2 event
> >>>>> regression we just found it is clear we need to do a better job with
> >>>>> testing.
> >>>>> 
> >>>>> All the pieces are in place, so what is needed is to combine it and
> >>>>> create a script that anyone of us as core developers can run to check
> >>>>> for regressions. The same script can be run as part of the kernelci
> >>>>> regression testing.
> >>>> 
> >>>> I'd say that *some* pieces are in place. Of course, the more there is,
> >>>> the better.
> >>>> 
> >>>> The more there are tests, the more important it would be they're
> >>>> automated, preferrably without the developer having to run them on his/
> >>>> her own machine.
> >>> 
> >>> From my experience with testing, it's important to have both a core set
> >>> of tests (a.k.a. smoke tests) that can easily be run on developers'
> >>> machines, and extended tests that can be offloaded to a shared testing
> >>> infrastructure (but possibly also run locally if desired).
> >> 
> >> That was my idea as well for the longer term. First step is to do the
> >> basic smoke tests (i.e. run compliance tests, do some (limited) streaming
> >> test).
> >> 
> >> There are more extensive (and longer running) tests that can be done, but
> >> that's something to look at later.
> >> 
> >>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last
> >>>>> one is IMHO not quite good enough yet for testing: it is not fully
> >>>>> compliant to the upcoming stateful codec spec. Work for that is
> >>>>> planned as part of an Outreachy project.
> >>>>> 
> >>>>> My idea is to create a script that is maintained as part of v4l-utils
> >>>>> that loads the drivers and runs v4l2-compliance and possibly other
> >>>>> tests against the virtual drivers.
> >>>> 
> >>>> How about spending a little time to pick a suitable framework for
> >>>> running the tests? It could be useful to get more informative reports
> >>>> than just pass / fail.
> >>> 
> >>> We should keep in mind that other tests will be added later, and the
> >>> test framework should make that easy.
> >> 
> >> Since we want to be able to run this on kernelci.org, I think it makes
> >> sense to let the kernelci folks (Hi Ezequiel!) decide this.
> > 
> > KernelCI isn't the only test infrastructure out there, so let's not forget
> > about the other ones.
> 
> True, but they are putting time and money into this, so they get to choose
> as far as I am concerned :-)

It's still our responsibility to give V4L2 a good test framework, and to drive 
it in the right direction. We don't accept V4L2 API extensions blindly just 
because a company happens to put time and money into it (there may have been 
one exception, but it's not the rule), we instead review all proposals 
carefully. The same should be true with tests.

> If others are interested and willing to put up time and money, they should
> let themselves be known.
> 
> I'm not going to work on such an integration, although I happily accept
> patches.
> 
> >> As a developer all I need is a script to run smoke tests so I can catch
> >> most regressions (you never catch all).
> >> 
> >> I'm happy to work with them to make any changes to compliance tools and
> >> scripts so they fit better into their test framework.
> >> 
> >> The one key requirement to all this is that you should be able to run
> >> these tests without dependencies to all sorts of external packages/
> >> libraries.
> > 
> > v4l-utils already has a set of dependencies, but those are largely
> > manageable. For v4l2-compliance we'll install libv4l, which depends on
> > libjpeg.
> 
> That's already too much. You can manually build v4l2-compliance wi

Re: [RFC] Create test script(s?) for regression testing

[Hans Verkuil]

On 11/06/2018 08:58 PM, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote:
>> On 11/06/18 14:12, Laurent Pinchart wrote:
>>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:
>>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:
>>>>> Hi all,
>>>>>
>>>>> After the media summit (heavy on test discussions) and the V4L2 event
>>>>> regression we just found it is clear we need to do a better job with
>>>>> testing.
>>>>>
>>>>> All the pieces are in place, so what is needed is to combine it and
>>>>> create a script that anyone of us as core developers can run to check
>>>>> for regressions. The same script can be run as part of the kernelci
>>>>> regression testing.
>>>>
>>>> I'd say that *some* pieces are in place. Of course, the more there is,
>>>> the better.
>>>>
>>>> The more there are tests, the more important it would be they're
>>>> automated, preferrably without the developer having to run them on his/
>>>> her own machine.
>>>
>>> From my experience with testing, it's important to have both a core set of
>>> tests (a.k.a. smoke tests) that can easily be run on developers' machines,
>>> and extended tests that can be offloaded to a shared testing
>>> infrastructure (but possibly also run locally if desired).
>>
>> That was my idea as well for the longer term. First step is to do the basic
>> smoke tests (i.e. run compliance tests, do some (limited) streaming test).
>>
>> There are more extensive (and longer running) tests that can be done, but
>> that's something to look at later.
>>
>>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last
>>>>> one is IMHO not quite good enough yet for testing: it is not fully
>>>>> compliant to the upcoming stateful codec spec. Work for that is planned
>>>>> as part of an Outreachy project.
>>>>>
>>>>> My idea is to create a script that is maintained as part of v4l-utils
>>>>> that loads the drivers and runs v4l2-compliance and possibly other tests
>>>>> against the virtual drivers.
>>>>
>>>> How about spending a little time to pick a suitable framework for running
>>>> the tests? It could be useful to get more informative reports than just
>>>> pass / fail.
>>>
>>> We should keep in mind that other tests will be added later, and the test
>>> framework should make that easy.
>>
>> Since we want to be able to run this on kernelci.org, I think it makes sense
>> to let the kernelci folks (Hi Ezequiel!) decide this.
> 
> KernelCI isn't the only test infrastructure out there, so let's not forget 
> about the other ones.

True, but they are putting time and money into this, so they get to choose as
far as I am concerned :-)

If others are interested and willing to put up time and money, they should let
themselves be known.

I'm not going to work on such an integration, although I happily accept patches.

> 
>> As a developer all I need is a script to run smoke tests so I can catch most
>> regressions (you never catch all).
>>
>> I'm happy to work with them to make any changes to compliance tools and
>> scripts so they fit better into their test framework.
>>
>> The one key requirement to all this is that you should be able to run these
>> tests without dependencies to all sorts of external packages/libraries.
> 
> v4l-utils already has a set of dependencies, but those are largely 
> manageable. 
> For v4l2-compliance we'll install libv4l, which depends on libjpeg.

That's already too much. You can manually build v4l2-compliance with no 
dependencies
whatsoever, but we're missing a Makefile target for that. It's been useful for
embedded systems with poor cross-compile environments.

It is really very useful to be able to compile those core utilities with no
external libraries other than glibc. You obviously will loose some functionality
when you compile it that way.

These utilities are not like a typical application. I really don't care how many
libraries are linked in by e.g. qv4l2, xawtv, etc. But for v4l2-ctl, 
v4l2-compliance,
cec-ctl/follower/compliance (and probably a few others as well) you want a 
minimum
of dependencies so you can run them everywhere, even with the crappiest 
toolchains
or cross-compile environments.

> 
>>> Regarding the test output, many formats exist (see
>>> https://testanything.

[PATCH] media: imx258: remove test pattern map from driver

[jasonx . z . chen]

From: "Chen, JasonX Z" 

Test Pattern mode be picked at HAL instead of driver.
do a FLIP when userspace use test pattern mode.
add entity_ops for validating imx258 link.

Signed-off-by: Chen, JasonX Z 
---
 drivers/media/i2c/imx258.c | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index 31a1e22..71f9875 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -62,11 +62,6 @@
 
 /* Test Pattern Control */
 #define IMX258_REG_TEST_PATTERN0x0600
-#define IMX258_TEST_PATTERN_DISABLE0
-#define IMX258_TEST_PATTERN_SOLID_COLOR1
-#define IMX258_TEST_PATTERN_COLOR_BARS 2
-#define IMX258_TEST_PATTERN_GREY_COLOR 3
-#define IMX258_TEST_PATTERN_PN94
 
 /* Orientation */
 #define REG_MIRROR_FLIP_CONTROL0x0101
@@ -504,20 +499,12 @@ struct imx258_mode {
 
 static const char * const imx258_test_pattern_menu[] = {
"Disabled",
-   "Color Bars",
"Solid Color",
+   "Color Bars",
"Grey Color Bars",
"PN9"
 };
 
-static const int imx258_test_pattern_val[] = {
-   IMX258_TEST_PATTERN_DISABLE,
-   IMX258_TEST_PATTERN_COLOR_BARS,
-   IMX258_TEST_PATTERN_SOLID_COLOR,
-   IMX258_TEST_PATTERN_GREY_COLOR,
-   IMX258_TEST_PATTERN_PN9,
-};
-
 /* Configurations for supported link frequencies */
 #define IMX258_LINK_FREQ_634MHZ63360ULL
 #define IMX258_LINK_FREQ_320MHZ32000ULL
@@ -752,7 +739,6 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
container_of(ctrl->handler, struct imx258, ctrl_handler);
struct i2c_client *client = v4l2_get_subdevdata(>sd);
int ret = 0;
-
/*
 * Applying V4L2 control value only happens
 * when power is up for streaming
@@ -778,13 +764,10 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_TEST_PATTERN:
ret = imx258_write_reg(imx258, IMX258_REG_TEST_PATTERN,
IMX258_REG_VALUE_16BIT,
-   imx258_test_pattern_val[ctrl->val]);
-
+   ctrl->val);
ret = imx258_write_reg(imx258, REG_MIRROR_FLIP_CONTROL,
IMX258_REG_VALUE_08BIT,
-   ctrl->val == imx258_test_pattern_val
-   [IMX258_TEST_PATTERN_DISABLE] ?
-   REG_CONFIG_MIRROR_FLIP :
+   !ctrl->val?REG_CONFIG_MIRROR_FLIP :
REG_CONFIG_FLIP_TEST_PATTERN);
break;
default:
@@ -1105,6 +1088,10 @@ static int imx258_identify_module(struct imx258 *imx258)
.pad = _pad_ops,
 };
 
+static const struct media_entity_operations imx258_subdev_entity_ops = {
+   .link_validate = v4l2_subdev_link_validate,
+};
+
 static const struct v4l2_subdev_internal_ops imx258_internal_ops = {
.open = imx258_open,
 };
@@ -1250,6 +1237,7 @@ static int imx258_probe(struct i2c_client *client)
 
/* Initialize subdev */
imx258->sd.internal_ops = _internal_ops;
+   imx258->sd.entity.ops  = _subdev_entity_ops;
imx258->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
imx258->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
 
-- 
1.9.1

Re: [RFC] Create test script(s?) for regression testing

[Laurent Pinchart]

Hi Hans,

On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote:
> On 11/06/18 14:12, Laurent Pinchart wrote:
> > On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:
> >> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:
> >>> Hi all,
> >>> 
> >>> After the media summit (heavy on test discussions) and the V4L2 event
> >>> regression we just found it is clear we need to do a better job with
> >>> testing.
> >>> 
> >>> All the pieces are in place, so what is needed is to combine it and
> >>> create a script that anyone of us as core developers can run to check
> >>> for regressions. The same script can be run as part of the kernelci
> >>> regression testing.
> >> 
> >> I'd say that *some* pieces are in place. Of course, the more there is,
> >> the better.
> >> 
> >> The more there are tests, the more important it would be they're
> >> automated, preferrably without the developer having to run them on his/
> >> her own machine.
> > 
> > From my experience with testing, it's important to have both a core set of
> > tests (a.k.a. smoke tests) that can easily be run on developers' machines,
> > and extended tests that can be offloaded to a shared testing
> > infrastructure (but possibly also run locally if desired).
> 
> That was my idea as well for the longer term. First step is to do the basic
> smoke tests (i.e. run compliance tests, do some (limited) streaming test).
> 
> There are more extensive (and longer running) tests that can be done, but
> that's something to look at later.
> 
> >>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last
> >>> one is IMHO not quite good enough yet for testing: it is not fully
> >>> compliant to the upcoming stateful codec spec. Work for that is planned
> >>> as part of an Outreachy project.
> >>> 
> >>> My idea is to create a script that is maintained as part of v4l-utils
> >>> that loads the drivers and runs v4l2-compliance and possibly other tests
> >>> against the virtual drivers.
> >> 
> >> How about spending a little time to pick a suitable framework for running
> >> the tests? It could be useful to get more informative reports than just
> >> pass / fail.
> > 
> > We should keep in mind that other tests will be added later, and the test
> > framework should make that easy.
> 
> Since we want to be able to run this on kernelci.org, I think it makes sense
> to let the kernelci folks (Hi Ezequiel!) decide this.

KernelCI isn't the only test infrastructure out there, so let's not forget 
about the other ones.

> As a developer all I need is a script to run smoke tests so I can catch most
> regressions (you never catch all).
> 
> I'm happy to work with them to make any changes to compliance tools and
> scripts so they fit better into their test framework.
> 
> The one key requirement to all this is that you should be able to run these
> tests without dependencies to all sorts of external packages/libraries.

v4l-utils already has a set of dependencies, but those are largely manageable. 
For v4l2-compliance we'll install libv4l, which depends on libjpeg.

> > Regarding the test output, many formats exist (see
> > https://testanything.org/ and
> > https://chromium.googlesource.com/chromium/src/+/master/docs/testing/
> > json_test_results_format.md for instance), we should pick one of the
> > leading industry standards (what those standards are still needs to be
> > researched  :-)).
> > 
> >> Do note that for different hardware the tests would be likely different
> >> as well although there are classes of devices for which the exact same
> >> tests would be applicable.
> > 
> > See http://git.ideasonboard.com/renesas/vsp-tests.git for an example of
> > device-specific tests. I think some of that could be generalized.
> > 
> >>> It should be simple to use and require very little in the way of
> >>> dependencies. Ideally no dependencies other than what is in v4l-utils so
> >>> it can easily be run on an embedded system as well.
> >>> 
> >>> For a 64-bit kernel it should run the tests both with 32-bit and 64-bit
> >>> applications.
> >>> 
> >>> It should also test with both single and multiplanar modes where
> >>> available.
> >>> 
> >>> Since vivid emulates CEC as well, it should run CEC tests too.
> >>> 
> >>> As core developers we should have an environmen

Re: [RFC] Create test script(s?) for regression testing

[Hans Verkuil]

On 11/06/18 14:12, Laurent Pinchart wrote:
> Hello,
> 
> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:
>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:
>>> Hi all,
>>>
>>> After the media summit (heavy on test discussions) and the V4L2 event
>>> regression we just found it is clear we need to do a better job with
>>> testing.
>>>
>>> All the pieces are in place, so what is needed is to combine it and create
>>> a script that anyone of us as core developers can run to check for
>>> regressions. The same script can be run as part of the kernelci
>>> regression testing.
>>
>> I'd say that *some* pieces are in place. Of course, the more there is, the
>> better.
>>
>> The more there are tests, the more important it would be they're automated,
>> preferrably without the developer having to run them on his/her own
>> machine.
> 
> From my experience with testing, it's important to have both a core set of 
> tests (a.k.a. smoke tests) that can easily be run on developers' machines, 
> and 
> extended tests that can be offloaded to a shared testing infrastructure (but 
> possibly also run locally if desired).

That was my idea as well for the longer term. First step is to do the basic
smoke tests (i.e. run compliance tests, do some (limited) streaming test).

There are more extensive (and longer running) tests that can be done, but
that's something to look at later.

>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one
>>> is IMHO not quite good enough yet for testing: it is not fully compliant
>>> to the upcoming stateful codec spec. Work for that is planned as part of
>>> an Outreachy project.
>>>
>>> My idea is to create a script that is maintained as part of v4l-utils that
>>> loads the drivers and runs v4l2-compliance and possibly other tests
>>> against the virtual drivers.
>>
>> How about spending a little time to pick a suitable framework for running
>> the tests? It could be useful to get more informative reports than just
>> pass / fail.
> 
> We should keep in mind that other tests will be added later, and the test 
> framework should make that easy.

Since we want to be able to run this on kernelci.org, I think it makes sense
to let the kernelci folks (Hi Ezequiel!) decide this. As a developer all I
need is a script to run smoke tests so I can catch most regressions (you never
catch all).

I'm happy to work with them to make any changes to compliance tools and scripts
so they fit better into their test framework.

The one key requirement to all this is that you should be able to run these
tests without dependencies to all sorts of external packages/libraries.

> Regarding the test output, many formats exist (see https://testanything.org/ 
> and https://chromium.googlesource.com/chromium/src/+/master/docs/testing/
> json_test_results_format.md for instance), we should pick one of the leading 
> industry standards (what those standards are still needs to be researched 
> :-)).
> 
>> Do note that for different hardware the tests would be likely different as
>> well although there are classes of devices for which the exact same tests
>> would be applicable.
> 
> See http://git.ideasonboard.com/renesas/vsp-tests.git for an example of 
> device-specific tests. I think some of that could be generalized.
> 
>>> It should be simple to use and require very little in the way of
>>> dependencies. Ideally no dependencies other than what is in v4l-utils so
>>> it can easily be run on an embedded system as well.
>>>
>>> For a 64-bit kernel it should run the tests both with 32-bit and 64-bit
>>> applications.
>>>
>>> It should also test with both single and multiplanar modes where
>>> available.
>>>
>>> Since vivid emulates CEC as well, it should run CEC tests too.
>>>
>>> As core developers we should have an environment where we can easily test
>>> our patches with this script (I use a VM for that).
>>>
>>> I think maintaining the script (or perhaps scripts) in v4l-utils is best
>>> since that keeps it in sync with the latest kernel and v4l-utils
>>> developments.
>>
>> Makes sense --- and that can be always changed later on if there's a need
>> to.
> 
> I wonder whether that would be best going forward, especially if we want to 
> add more tests. Wouldn't a v4l-tests project make sense ?
> 

Let's see what happens. The more repos you have, the harder it becomes to keep
everything in sync with the latest kernel code.

My experience is that if you want to have good tests, then writing tests should
be as easy as possible. Keep dependencies at an absolute minimum.

Let's be honest, we (well, mainly me) are doing these tests as a side job, it's
not our main focus. Anything that makes writing tests more painful is bad and
just gets in the way.

Regards,

Hans

Re: [RFC] Create test script(s?) for regression testing

[Ezequiel Garcia]

On Tue, 2018-11-06 at 09:37 +0100, Hans Verkuil wrote:
> Hi all,
> 
> After the media summit (heavy on test discussions) and the V4L2 event 
> regression
> we just found it is clear we need to do a better job with testing.
> 
> All the pieces are in place, so what is needed is to combine it and create a
> script that anyone of us as core developers can run to check for regressions.
> The same script can be run as part of the kernelci regression testing.
> 
> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one
> is IMHO not quite good enough yet for testing: it is not fully compliant to 
> the
> upcoming stateful codec spec. Work for that is planned as part of an Outreachy
> project.
> 
> My idea is to create a script that is maintained as part of v4l-utils that
> loads the drivers and runs v4l2-compliance and possibly other tests against
> the virtual drivers.
> 
> It should be simple to use and require very little in the way of dependencies.
> Ideally no dependencies other than what is in v4l-utils so it can easily be 
> run
> on an embedded system as well.
> 
> For a 64-bit kernel it should run the tests both with 32-bit and 64-bit
> applications.
> 
> It should also test with both single and multiplanar modes where available.
> 
> Since vivid emulates CEC as well, it should run CEC tests too.
> 
> As core developers we should have an environment where we can easily test
> our patches with this script (I use a VM for that).
> 

It's quite trivial to setup a qemu environment for this, e.g. you can
use virtme [1] and set it up so that it runs a script after booting.

> I think maintaining the script (or perhaps scripts) in v4l-utils is best since
> that keeps it in sync with the latest kernel and v4l-utils developments.
> 
> Comments? Ideas?
> 

Sounds great. I think it makes a lot of sense to have a script for CIs
and developers to run.

I guess we can start simple, with just a bash script?

> Regards,
> 
>   Hans

[1] 
https://www.collabora.com/news-and-blog/blog/2018/09/18/virtme-the-kernel-developers-best-friend/

Re: [RFC] Create test script(s?) for regression testing

[Laurent Pinchart]

Hello,

On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:
> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:
> > Hi all,
> > 
> > After the media summit (heavy on test discussions) and the V4L2 event
> > regression we just found it is clear we need to do a better job with
> > testing.
> > 
> > All the pieces are in place, so what is needed is to combine it and create
> > a script that anyone of us as core developers can run to check for
> > regressions. The same script can be run as part of the kernelci
> > regression testing.
> 
> I'd say that *some* pieces are in place. Of course, the more there is, the
> better.
> 
> The more there are tests, the more important it would be they're automated,
> preferrably without the developer having to run them on his/her own
> machine.

>From my experience with testing, it's important to have both a core set of 
tests (a.k.a. smoke tests) that can easily be run on developers' machines, and 
extended tests that can be offloaded to a shared testing infrastructure (but 
possibly also run locally if desired).

> > We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one
> > is IMHO not quite good enough yet for testing: it is not fully compliant
> > to the upcoming stateful codec spec. Work for that is planned as part of
> > an Outreachy project.
> > 
> > My idea is to create a script that is maintained as part of v4l-utils that
> > loads the drivers and runs v4l2-compliance and possibly other tests
> > against the virtual drivers.
> 
> How about spending a little time to pick a suitable framework for running
> the tests? It could be useful to get more informative reports than just
> pass / fail.

We should keep in mind that other tests will be added later, and the test 
framework should make that easy.

Regarding the test output, many formats exist (see https://testanything.org/ 
and https://chromium.googlesource.com/chromium/src/+/master/docs/testing/
json_test_results_format.md for instance), we should pick one of the leading 
industry standards (what those standards are still needs to be researched 
:-)).

> Do note that for different hardware the tests would be likely different as
> well although there are classes of devices for which the exact same tests
> would be applicable.

See http://git.ideasonboard.com/renesas/vsp-tests.git for an example of 
device-specific tests. I think some of that could be generalized.

> > It should be simple to use and require very little in the way of
> > dependencies. Ideally no dependencies other than what is in v4l-utils so
> > it can easily be run on an embedded system as well.
> > 
> > For a 64-bit kernel it should run the tests both with 32-bit and 64-bit
> > applications.
> > 
> > It should also test with both single and multiplanar modes where
> > available.
> > 
> > Since vivid emulates CEC as well, it should run CEC tests too.
> > 
> > As core developers we should have an environment where we can easily test
> > our patches with this script (I use a VM for that).
> > 
> > I think maintaining the script (or perhaps scripts) in v4l-utils is best
> > since that keeps it in sync with the latest kernel and v4l-utils
> > developments.
> 
> Makes sense --- and that can be always changed later on if there's a need
> to.

I wonder whether that would be best going forward, especially if we want to 
add more tests. Wouldn't a v4l-tests project make sense ?

-- 
Regards,

Laurent Pinchart

Re: [RFC] Create test script(s?) for regression testing

[Sakari Ailus]

Hi Hans,

On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:
> Hi all,
> 
> After the media summit (heavy on test discussions) and the V4L2 event 
> regression
> we just found it is clear we need to do a better job with testing.
> 
> All the pieces are in place, so what is needed is to combine it and create a
> script that anyone of us as core developers can run to check for regressions.
> The same script can be run as part of the kernelci regression testing.

I'd say that *some* pieces are in place. Of course, the more there is, the
better.

The more there are tests, the more important it would be they're automated,
preferrably without the developer having to run them on his/her own
machine.

> 
> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one
> is IMHO not quite good enough yet for testing: it is not fully compliant to 
> the
> upcoming stateful codec spec. Work for that is planned as part of an Outreachy
> project.
> 
> My idea is to create a script that is maintained as part of v4l-utils that
> loads the drivers and runs v4l2-compliance and possibly other tests against
> the virtual drivers.

How about spending a little time to pick a suitable framework for running
the tests? It could be useful to get more informative reports than just
pass / fail.

Do note that for different hardware the tests would be likely different as
well although there are classes of devices for which the exact same tests
would be applicable.

> 
> It should be simple to use and require very little in the way of dependencies.
> Ideally no dependencies other than what is in v4l-utils so it can easily be 
> run
> on an embedded system as well.
> 
> For a 64-bit kernel it should run the tests both with 32-bit and 64-bit
> applications.
> 
> It should also test with both single and multiplanar modes where available.
> 
> Since vivid emulates CEC as well, it should run CEC tests too.
> 
> As core developers we should have an environment where we can easily test
> our patches with this script (I use a VM for that).
> 
> I think maintaining the script (or perhaps scripts) in v4l-utils is best since
> that keeps it in sync with the latest kernel and v4l-utils developments.

Makes sense --- and that can be always changed later on if there's a need
to.

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

[RFC] Create test script(s?) for regression testing

[Hans Verkuil]

Hi all,

After the media summit (heavy on test discussions) and the V4L2 event regression
we just found it is clear we need to do a better job with testing.

All the pieces are in place, so what is needed is to combine it and create a
script that anyone of us as core developers can run to check for regressions.
The same script can be run as part of the kernelci regression testing.

We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one
is IMHO not quite good enough yet for testing: it is not fully compliant to the
upcoming stateful codec spec. Work for that is planned as part of an Outreachy
project.

My idea is to create a script that is maintained as part of v4l-utils that
loads the drivers and runs v4l2-compliance and possibly other tests against
the virtual drivers.

It should be simple to use and require very little in the way of dependencies.
Ideally no dependencies other than what is in v4l-utils so it can easily be run
on an embedded system as well.

For a 64-bit kernel it should run the tests both with 32-bit and 64-bit
applications.

It should also test with both single and multiplanar modes where available.

Since vivid emulates CEC as well, it should run CEC tests too.

As core developers we should have an environment where we can easily test
our patches with this script (I use a VM for that).

I think maintaining the script (or perhaps scripts) in v4l-utils is best since
that keeps it in sync with the latest kernel and v4l-utils developments.

Comments? Ideas?

Regards,

Hans

Re: [PATCH] media: rc: self test for IR encoders and decoders

[Sean Young]

Hi Shuah,

On Thu, Nov 01, 2018 at 08:59:39AM -0600, Shuah Khan wrote:
> On 10/16/2018 08:09 AM, Sean Young wrote:
> > ir-loopback can transmit IR on one rc device and check the correct
> > scancode and protocol is decoded on a different rc device. This can be
> > used to check IR transmission between two rc devices. Using rc-loopback,
> > we use it to check the IR encoders and decoders themselves.
> > 
> > No hardware is required for this test.
> > 
> > Signed-off-by: Sean Young 
> > Cc: Shuah Khan 
> 
> Hi Sean,
> 
> This looks good. I will get this into the next release. It will show
> up in linux-kselftest next after 4.20-rc1 comes out.

Great, thank you very much.

Regards,

Sean

Re: [PATCH] media: rc: self test for IR encoders and decoders

[Shuah Khan]

On 10/16/2018 08:09 AM, Sean Young wrote:
> ir-loopback can transmit IR on one rc device and check the correct
> scancode and protocol is decoded on a different rc device. This can be
> used to check IR transmission between two rc devices. Using rc-loopback,
> we use it to check the IR encoders and decoders themselves.
> 
> No hardware is required for this test.
> 
> Signed-off-by: Sean Young 
> Cc: Shuah Khan 

Hi Sean,

This looks good. I will get this into the next release. It will show
up in linux-kselftest next after 4.20-rc1 comes out.

thanks,
-- Shuah

Re: RFC: kernelCI media subsystem pilot (Test results for gtucker/kernelci-media - gtucker-kernelci-media-001-6-g1b2c6e5844d8)

[Ezequiel Garcia]

On Fri, 2018-10-19 at 09:06 +0200, Hans Verkuil wrote:
> On 10/18/2018 09:23 PM, Ezequiel Garcia wrote:
> > Hi everyone,
> > 
> > In Collabora, and as part of our kernelci work, we are doing
> > research on kernel functional testing with kernelci.
> > 
> > For those new to kernelci, see 
> > https://github.com/kernelci/kernelci-doc/wiki/KernelCI 
> > and https://kernelci.org/.
> > 
> > The goal is to lay down the infrastructure required to make
> > automated test coverage an integral part of our feature
> > and bugfix development process.
> > 
> > So, as a first attempt, we've decided to extend kernelci test
> > v4l2 plan support, leading the way to extending
> > other subsystems' test plans.
> > 
> > Currently, kernelci looks for a list of branches every hour and
> > see if anything changed. For any branch that has changed, it triggers
> > builds, boots, tests and reports for each branch that had some changes
> > since last time it ran.
> > 
> > For this pilot, we've decided to target just a few devices:
> > qemu with vivid, rk3399-gru-kevin and rk3288-veyron-jaq
> > with uvc.
> 
> It's running v4l2-compliance, right?
> 

Exactly.

> Looking at the test cases, they appear in the reverse order that 
> v4l2-compliance
> performs them, that's a bit odd.
> 

That's something to check in the parser. I'm sure it's fixable if you
find it annoying.

> And if we include uvc in the testing, then I need to prioritize the work I
> started for uvc to remove the last FAILs.
> 

Well, we can run anything. We decided to go for uvc and vivid, just too pick
two popular examples, but there are really no restrictions.

Thanks,
Ezequiel

Re: RFC: kernelCI media subsystem pilot (Test results for gtucker/kernelci-media - gtucker-kernelci-media-001-6-g1b2c6e5844d8)

[Hans Verkuil]

On 10/18/2018 09:23 PM, Ezequiel Garcia wrote:
> Hi everyone,
> 
> In Collabora, and as part of our kernelci work, we are doing
> research on kernel functional testing with kernelci.
> 
> For those new to kernelci, see 
> https://github.com/kernelci/kernelci-doc/wiki/KernelCI 
> and https://kernelci.org/.
> 
> The goal is to lay down the infrastructure required to make
> automated test coverage an integral part of our feature
> and bugfix development process.
> 
> So, as a first attempt, we've decided to extend kernelci test
> v4l2 plan support, leading the way to extending
> other subsystems' test plans.
> 
> Currently, kernelci looks for a list of branches every hour and
> see if anything changed. For any branch that has changed, it triggers
> builds, boots, tests and reports for each branch that had some changes
> since last time it ran.
> 
> For this pilot, we've decided to target just a few devices:
> qemu with vivid, rk3399-gru-kevin and rk3288-veyron-jaq
> with uvc.

It's running v4l2-compliance, right?

Looking at the test cases, they appear in the reverse order that v4l2-compliance
performs them, that's a bit odd.

And if we include uvc in the testing, then I need to prioritize the work I
started for uvc to remove the last FAILs.

Regards,

Hans

> 
> We'd like to get some early feedback on this, so we are sending
> an example of how a kernelci report would look like, to trigger
> some discussion around
> the direction this should take.
> 
> Thanks!
> 
> ===
> Test results for:
>   Tree:gtucker
>   Branch:  kernelci-media
>   Kernel:  gtucker-kernelci-media-002-2-gaa27eb0392c7
>   URL: https://gitlab.collabora.com/gtucker/linux.git
>   Commit:  aa27eb0392c70adec713e911a9b5267a1d853624
>   Test plans: v4l2
> 
> Summary
> ---
> 3 test groups results
> 
> 1  | v4l2   | rk3399-gru-kevin   | arm64 |  49 total:  17 PASS   4 
> FAIL  28 SKIP
> 2  | v4l2   | rk3288-veyron-jaq  | arm   |  49 total:  17 PASS   4 
> FAIL  28 SKIP
> 3  | v4l2   | qemu   | arm64 | 168 total: 102 PASS   0 
> FAIL  66 SKIP
> 
> 
> Tests
> -
> 
> 1  | v4l2   | rk3399-gru-kevin   | arm64 |  49 total:  17 PASS   4 
> FAIL  28 SKIP
> 
>   Config:  defconfig
>   Lab Name:lab-collabora-dev
>   Date:2018-10-18 18:48:52.426000
>   TXT log: 
> http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm64/defconfig/lab-collabora-dev
> /v4l2-rk3399-gru-kevin.txt
>   HTML log:
> http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm64/defconfig/lab-collabora-dev
> /v4l2-rk3399-gru-kevin.html
>   Rootfs:  
> http://staging-storage.kernelci.org/images/rootfs/debian/stretchv4l2/20181017.1//arm64/rootfs.cpio.gz
>   Test Git:git://linuxtv.org/v4l-utils.git
>   Test Commit: e889b0d56757b9a74eb8c4c8cc2ebd5b18e228b2
> 
> 
>   Test cases:
> 
> * MMAP: FAIL
> * blocking-wait: PASS
> * read/write: SKIP
> * read/write: SKIP
> * read/write: SKIP
> * VIDIOC_EXPBUF: PASS
> * VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: PASS
> * VIDIOC_TRY_DECODER_CMD: SKIP
> * VIDIOC_G_ENC_INDEX: SKIP
> * VIDIOC_TRY_ENCODER_CMD: SKIP
> * Scaling: SKIP
> * Composing: SKIP
> * Cropping: SKIP
> * VIDIOC_G_SLICED_VBI_CAP: SKIP
> * VIDIOC_S_FMT: PASS
> * VIDIOC_TRY_FMT: PASS
> * VIDIOC_G_FMT: PASS
> * VIDIOC_G_FBUF: SKIP
> * VIDIOC_G/S_PARM: FAIL
> * VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: PASS
> * VIDIOC_G/S_JPEGCOMP: SKIP
> * VIDIOC_UNSUBSCRIBE_EVENT/DQEVENT: PASS
> * VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
> * VIDIOC_G/S_CTRL: PASS
> * VIDIOC_QUERYCTRL: PASS
> * VIDIOC_QUERY_EXT_CTRL/QUERYMENU: FAIL
> * VIDIOC_G/S_EDID: SKIP
> * VIDIOC_DV_TIMINGS_CAP: SKIP
> * VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: SKIP
> * VIDIOC_ENUM/G/S/QUERY_STD: SKIP
> * VIDIOC_G/S_AUDOUT: SKIP
> * VIDIOC_G/S/ENUMOUTPUT: SKIP
> * VIDIOC_ENUMAUDOUT: SKIP
> * VIDIOC_G/S_FREQUENCY: SKIP
> * VIDIOC_G/S_MODULATOR: SKIP
> * VIDIOC_G/S_AUDIO: SKIP
> * VIDIOC_G/S/ENUMINPUT: PASS
> * VIDIOC_ENUMAUDIO: SKIP
> * VIDIOC_S_HW_FREQ_SEEK: SKIP
> * VIDIOC_G/S_FREQUENCY: SKIP
> * VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: SKIP
> * VIDIOC_LOG_STATUS: SKIP
> * VIDIOC_DBG_G/S_REGISTER: SKIP
> * for-unlimited-opens: PASS
> * VIDIOC_G/S_PRIORITY: PASS
> * VIDIOC_QUERYCAP: PASS
> * second-/dev/video0-open: PASS
> * VIDIOC_QUERYCAP: PASS
> * MC-information-see-Media-Driver-Info-above: PASS
>

RFC: kernelCI media subsystem pilot (Test results for gtucker/kernelci-media - gtucker-kernelci-media-001-6-g1b2c6e5844d8)

[Ezequiel Garcia]

Hi everyone,

In Collabora, and as part of our kernelci work, we are doing
research on kernel functional testing with kernelci.

For those new to kernelci, see 
https://github.com/kernelci/kernelci-doc/wiki/KernelCI 
and https://kernelci.org/.

The goal is to lay down the infrastructure required to make
automated test coverage an integral part of our feature
and bugfix development process.

So, as a first attempt, we've decided to extend kernelci test
v4l2 plan support, leading the way to extending
other subsystems' test plans.

Currently, kernelci looks for a list of branches every hour and
see if anything changed. For any branch that has changed, it triggers
builds, boots, tests and reports for each branch that had some changes
since last time it ran.

For this pilot, we've decided to target just a few devices:
qemu with vivid, rk3399-gru-kevin and rk3288-veyron-jaq
with uvc.

We'd like to get some early feedback on this, so we are sending
an example of how a kernelci report would look like, to trigger
some discussion around
the direction this should take.

Thanks!

===
Test results for:
  Tree:gtucker
  Branch:  kernelci-media
  Kernel:  gtucker-kernelci-media-002-2-gaa27eb0392c7
  URL: https://gitlab.collabora.com/gtucker/linux.git
  Commit:  aa27eb0392c70adec713e911a9b5267a1d853624
  Test plans: v4l2

Summary
---
3 test groups results

1  | v4l2   | rk3399-gru-kevin   | arm64 |  49 total:  17 PASS   4 FAIL 
 28 SKIP
2  | v4l2   | rk3288-veyron-jaq  | arm   |  49 total:  17 PASS   4 FAIL 
 28 SKIP
3  | v4l2   | qemu   | arm64 | 168 total: 102 PASS   0 FAIL 
 66 SKIP


Tests
-

1  | v4l2   | rk3399-gru-kevin   | arm64 |  49 total:  17 PASS   4 FAIL 
 28 SKIP

  Config:  defconfig
  Lab Name:lab-collabora-dev
  Date:2018-10-18 18:48:52.426000
  TXT log: 
http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm64/defconfig/lab-collabora-dev
/v4l2-rk3399-gru-kevin.txt
  HTML log:
http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm64/defconfig/lab-collabora-dev
/v4l2-rk3399-gru-kevin.html
  Rootfs:  
http://staging-storage.kernelci.org/images/rootfs/debian/stretchv4l2/20181017.1//arm64/rootfs.cpio.gz
  Test Git:git://linuxtv.org/v4l-utils.git
  Test Commit: e889b0d56757b9a74eb8c4c8cc2ebd5b18e228b2


  Test cases:

* MMAP: FAIL
* blocking-wait: PASS
* read/write: SKIP
* read/write: SKIP
* read/write: SKIP
* VIDIOC_EXPBUF: PASS
* VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: PASS
* VIDIOC_TRY_DECODER_CMD: SKIP
* VIDIOC_G_ENC_INDEX: SKIP
* VIDIOC_TRY_ENCODER_CMD: SKIP
* Scaling: SKIP
* Composing: SKIP
* Cropping: SKIP
* VIDIOC_G_SLICED_VBI_CAP: SKIP
* VIDIOC_S_FMT: PASS
* VIDIOC_TRY_FMT: PASS
* VIDIOC_G_FMT: PASS
* VIDIOC_G_FBUF: SKIP
* VIDIOC_G/S_PARM: FAIL
* VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: PASS
* VIDIOC_G/S_JPEGCOMP: SKIP
* VIDIOC_UNSUBSCRIBE_EVENT/DQEVENT: PASS
* VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
* VIDIOC_G/S_CTRL: PASS
* VIDIOC_QUERYCTRL: PASS
* VIDIOC_QUERY_EXT_CTRL/QUERYMENU: FAIL
* VIDIOC_G/S_EDID: SKIP
* VIDIOC_DV_TIMINGS_CAP: SKIP
* VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: SKIP
* VIDIOC_ENUM/G/S/QUERY_STD: SKIP
* VIDIOC_G/S_AUDOUT: SKIP
* VIDIOC_G/S/ENUMOUTPUT: SKIP
* VIDIOC_ENUMAUDOUT: SKIP
* VIDIOC_G/S_FREQUENCY: SKIP
* VIDIOC_G/S_MODULATOR: SKIP
* VIDIOC_G/S_AUDIO: SKIP
* VIDIOC_G/S/ENUMINPUT: PASS
* VIDIOC_ENUMAUDIO: SKIP
* VIDIOC_S_HW_FREQ_SEEK: SKIP
* VIDIOC_G/S_FREQUENCY: SKIP
* VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: SKIP
* VIDIOC_LOG_STATUS: SKIP
* VIDIOC_DBG_G/S_REGISTER: SKIP
* for-unlimited-opens: PASS
* VIDIOC_G/S_PRIORITY: PASS
* VIDIOC_QUERYCAP: PASS
* second-/dev/video0-open: PASS
* VIDIOC_QUERYCAP: PASS
* MC-information-see-Media-Driver-Info-above: PASS



2  | v4l2   | rk3288-veyron-jaq  | arm   |  49 total:  17 PASS   4 FAIL 
 28 SKIP

  Config:  multi_v7_defconfig
  Lab Name:lab-collabora-dev
  Date:2018-10-18 17:00:41.724000
  TXT log: 
http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm/multi_v7_defconfig/lab-collab
ora-dev/v4l2-rk3288-veyron-jaq.txt
  HTML log:
http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm/multi_v7_defconfig/lab-collab
ora-dev/v4l2-rk3288-veyron-jaq.html
  Rootfs:  
http://staging-storage.kernelci.org/images/rootfs/debian/stretchv4l2/20181017.1//armhf/rootfs.cpio.gz
  Test Git:git://linuxtv.org/v4l-utils.git
  Test Commit: e889b0d56757b9a74eb8c4c8cc2ebd5b18e228b2


  Test cases:

* MMAP: FAIL
* blocking-wait: PASS
* read/write: SKIP
* read/write: SKIP
* read/write: SKIP
* VIDIOC_EXPBUF: PASS
* VIDIOC_REQBUFS

[PATCH] media: rc: self test for IR encoders and decoders

[Sean Young]

ir-loopback can transmit IR on one rc device and check the correct
scancode and protocol is decoded on a different rc device. This can be
used to check IR transmission between two rc devices. Using rc-loopback,
we use it to check the IR encoders and decoders themselves.

No hardware is required for this test.

Signed-off-by: Sean Young 
Cc: Shuah Khan 
---
 tools/testing/selftests/Makefile  |   1 +
 tools/testing/selftests/ir/.gitignore |   1 +
 tools/testing/selftests/ir/Makefile   |   5 +
 tools/testing/selftests/ir/ir_loopback.c  | 199 ++
 tools/testing/selftests/ir/ir_loopback.sh |  20 +++
 5 files changed, 226 insertions(+)
 create mode 100644 tools/testing/selftests/ir/.gitignore
 create mode 100644 tools/testing/selftests/ir/Makefile
 create mode 100644 tools/testing/selftests/ir/ir_loopback.c
 create mode 100755 tools/testing/selftests/ir/ir_loopback.sh

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index f1fe492c8e17..995034ea5546 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -15,6 +15,7 @@ TARGETS += futex
 TARGETS += gpio
 TARGETS += intel_pstate
 TARGETS += ipc
+TARGETS += ir
 TARGETS += kcmp
 TARGETS += kvm
 TARGETS += lib
diff --git a/tools/testing/selftests/ir/.gitignore 
b/tools/testing/selftests/ir/.gitignore
new file mode 100644
index ..070ea0c75fb8
--- /dev/null
+++ b/tools/testing/selftests/ir/.gitignore
@@ -0,0 +1 @@
+ir_loopback
diff --git a/tools/testing/selftests/ir/Makefile 
b/tools/testing/selftests/ir/Makefile
new file mode 100644
index ..f4ba8eb84b95
--- /dev/null
+++ b/tools/testing/selftests/ir/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+TEST_PROGS := ir_loopback.sh
+TEST_GEN_PROGS_EXTENDED := ir_loopback
+
+include ../lib.mk
diff --git a/tools/testing/selftests/ir/ir_loopback.c 
b/tools/testing/selftests/ir/ir_loopback.c
new file mode 100644
index ..858c19caf224
--- /dev/null
+++ b/tools/testing/selftests/ir/ir_loopback.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0
+// test ir decoder
+//
+// Copyright (C) 2018 Sean Young 
+
+// When sending LIRC_MODE_SCANCODE, the IR will be encoded. rc-loopback
+// will send this IR to the receiver side, where we try to read the decoded
+// IR. Decoding happens in a separate kernel thread, so we will need to
+// wait until that is scheduled, hence we use poll to check for read
+// readiness.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../kselftest.h"
+
+#define TEST_SCANCODES 10
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+static const struct {
+   enum rc_proto proto;
+   const char *name;
+   unsigned int mask;
+   const char *decoder;
+} protocols[] = {
+   { RC_PROTO_RC5, "rc-5", 0x1f7f, "rc-5" },
+   { RC_PROTO_RC5X_20, "rc-5x-20", 0x1f7f3f, "rc-5" },
+   { RC_PROTO_RC5_SZ, "rc-5-sz", 0x2fff, "rc-5-sz" },
+   { RC_PROTO_JVC, "jvc", 0x, "jvc" },
+   { RC_PROTO_SONY12, "sony-12", 0x1f007f, "sony" },
+   { RC_PROTO_SONY15, "sony-15", 0xff007f, "sony" },
+   { RC_PROTO_SONY20, "sony-20", 0x1fff7f, "sony" },
+   { RC_PROTO_NEC, "nec", 0x, "nec" },
+   { RC_PROTO_NECX, "nec-x", 0xff, "nec" },
+   { RC_PROTO_NEC32, "nec-32", 0x, "nec" },
+   { RC_PROTO_SANYO, "sanyo", 0x1f, "sanyo" },
+   { RC_PROTO_RC6_0, "rc-6-0", 0x, "rc-6" },
+   { RC_PROTO_RC6_6A_20, "rc-6-6a-20", 0xf, "rc-6" },
+   { RC_PROTO_RC6_6A_24, "rc-6-6a-24", 0xff, "rc-6" },
+   { RC_PROTO_RC6_6A_32, "rc-6-6a-32", 0x, "rc-6" },
+   { RC_PROTO_RC6_MCE, "rc-6-mce", 0x7fff, "rc-6" },
+   { RC_PROTO_SHARP, "sharp", 0x1fff, "sharp" },
+};
+
+int lirc_open(const char *rc)
+{
+   struct dirent *dent;
+   char buf[100];
+   DIR *d;
+   int fd;
+
+   snprintf(buf, sizeof(buf), "/sys/class/rc/%s", rc);
+
+   d = opendir(buf);
+   if (!d)
+   ksft_exit_fail_msg("cannot open %s: %m\n", buf);
+
+   while ((dent = readdir(d)) != NULL) {
+   if (!strncmp(dent->d_name, "lirc", 4)) {
+   snprintf(buf, sizeof(buf), "/dev/%s", dent->d_name);
+   break;
+   }
+   }
+
+   if (!dent)
+   ksft_exit_fail_msg("cannot find lirc device for %s\n", rc);
+
+   closedir(d);
+
+   fd = open(buf, O_RDWR | O_NONBLOCK);
+   if

Working test 5

[Judy]

Did you get my email from last week?
Let me know if you have photos for cutting out or retouching?

We are an image team who can do editing for your the web store photos,
industry photos or portrait photos.

Send photos, we will do testing for you to check quality.
Waiting for your reply soon.

Thanks,
Judy

Working test 3

[Judy]

Did you get my email from last week?
Let me know if you have photos for cutting out or retouching?

We are an image team who can do editing for your the web store photos,
industry photos or portrait photos.

Send photos, we will do testing for you to check quality.
Waiting for your reply soon.

Thanks,
Judy

Working test 3

[Judy]

Did you get my email from last week?
Let me know if you have photos for cutting out or retouching?

We are an image team who can do editing for your the web store photos,
industry photos or portrait photos.

Send photos, we will do testing for you to check quality.
Waiting for your reply soon.

Thanks,
Judy

Working test 4

[Judy]

Did you get my email from last week?
Let me know if you have photos for cutting out or retouching?

We are an image team who can do editing for your the web store photos,
industry photos or portrait photos.

Send photos, we will do testing for you to check quality.
Waiting for your reply soon.

Thanks,
Judy

Re: [PATCH 2/2] media: rc: self test for IR encoders and decoders

[Sean Young]

Hi Shuah,

On Thu, Oct 04, 2018 at 02:13:51PM -0600, Shuah Khan wrote:
> Hi Sean,
> 
> Thanks for the patch. I just happened to see this when Mauro sent it to me.
> Doesn't look like linux-ksefltest and I weren't on the patch?

This is true, and that is an oversight on my behalf.

Thank you for your review -- I agree with all your points and thanks for the
helpful tips as well. I will fix for v2.

Thanks again,

Sean

> 
> On 07/17/2018 03:33 PM, Sean Young (by way of Mauro Carvalho Chehab 
> ) wrote:
> > ir-loopback can transmit IR on one rc device and check the correct
> > scancode and protocol is decoded on a different rc device. This can be
> > used to check IR transmission between two rc devices. Using rc-loopback,
> > we use it to check the IR encoders and decoders themselves.
> > 
> > Signed-off-by: Sean Young 
> > ---
> >  tools/testing/selftests/Makefile  |   1 +
> >  tools/testing/selftests/ir/.gitignore |   1 +
> >  tools/testing/selftests/ir/Makefile   |  19 ++
> >  tools/testing/selftests/ir/config |  12 ++
> >  tools/testing/selftests/ir/ir-loopback.c  | 209 ++
> >  tools/testing/selftests/ir/ir-loopback.sh |  28 +++
> >  6 files changed, 270 insertions(+)
> >  create mode 100644 tools/testing/selftests/ir/.gitignore
> >  create mode 100644 tools/testing/selftests/ir/Makefile
> >  create mode 100644 tools/testing/selftests/ir/config
> >  create mode 100644 tools/testing/selftests/ir/ir-loopback.c
> >  create mode 100755 tools/testing/selftests/ir/ir-loopback.sh
> 
> Why not add to the existing media directory? ../selftests/media_tests?
> 
> > 
> > diff --git a/tools/testing/selftests/Makefile 
> > b/tools/testing/selftests/Makefile
> > index f1fe492c8e17..995034ea5546 100644
> > --- a/tools/testing/selftests/Makefile
> > +++ b/tools/testing/selftests/Makefile
> > @@ -15,6 +15,7 @@ TARGETS += futex
> >  TARGETS += gpio
> >  TARGETS += intel_pstate
> >  TARGETS += ipc
> > +TARGETS += ir
> 
> Does this test depend on any hardware being present in the system?
> 
> >  TARGETS += kcmp
> >  TARGETS += kvm
> >  TARGETS += lib
> > diff --git a/tools/testing/selftests/ir/.gitignore 
> > b/tools/testing/selftests/ir/.gitignore
> > new file mode 100644
> > index ..87bf2989b678
> > --- /dev/null
> > +++ b/tools/testing/selftests/ir/.gitignore
> > @@ -0,0 +1 @@
> > +ir-loopback
> > diff --git a/tools/testing/selftests/ir/Makefile 
> > b/tools/testing/selftests/ir/Makefile
> > new file mode 100644
> > index ..501b464e56b5
> > --- /dev/null
> > +++ b/tools/testing/selftests/ir/Makefile
> > @@ -0,0 +1,19 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +uname_M := $(shell uname -m 2>/dev/null || echo not)
> > +ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/)
> > +ifeq ($(ARCH),i386)
> > +ARCH := x86
> > +   CFLAGS := -DCONFIG_X86_32 -D__i386__
> > +endif
> > +ifeq ($(ARCH),x86_64)
> > +   ARCH := x86
> > +   CFLAGS := -DCONFIG_X86_64 -D__x86_64__
> > +endif
> > +
> > +CFLAGS += -I../../../../usr/include/
> > +
> > +TEST_PROGS := ir-loopback.sh
> > +
> > +TEST_GEN_PROGS := ir-loopback
> 
> Looks like ir-loopback get run from ir-loopback.sh. TEST_GEN_PROGS_EXTENDED
> is the right variable to use in this case.
> 
> TEST_GEN_PROGS_EXTENDED := ir-loopback
> 
> > +
> > +include ../lib.mk
> > diff --git a/tools/testing/selftests/ir/config 
> > b/tools/testing/selftests/ir/config
> > new file mode 100644
> > index ..78e041e9319e
> > --- /dev/null
> > +++ b/tools/testing/selftests/ir/config
> > @@ -0,0 +1,12 @@
> > +CONFIG_RC_CORE=y
> > +CONFIG_RC_LOOPBACK=y
> > +CONFIG_IR_NEC_DECODER=m
> > +CONFIG_IR_RC5_DECODER=m
> > +CONFIG_IR_RC6_DECODER=m
> > +CONFIG_IR_JVC_DECODER=m
> > +CONFIG_IR_SONY_DECODER=m
> > +CONFIG_IR_SANYO_DECODER=m
> > +CONFIG_IR_SHARP_DECODER=m
> > +CONFIG_IR_MCE_KBD_DECODER=m
> > +CONFIG_IR_XMP_DECODER=m
> > +CONFIG_IR_IMON_DECODER=m
> > diff --git a/tools/testing/selftests/ir/ir-loopback.c 
> > b/tools/testing/selftests/ir/ir-loopback.c
> > new file mode 100644
> > index ..95b6f0f2f1f5
> > --- /dev/null
> > +++ b/tools/testing/selftests/ir/ir-loopback.c
> > @@ -0,0 +1,209 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// test ir decoder
> > +//
> > +// Copyright (C) 2018 Sean Young 
> > +
> > +// When sending LIRC_MODE_SCANCODE, the IR will 

Re: [PATCH 2/2] media: rc: self test for IR encoders and decoders

[Shuah Khan]

Hi Sean,

Thanks for the patch. I just happened to see this when Mauro sent it to me.
Doesn't look like linux-ksefltest and I weren't on the patch?

On 07/17/2018 03:33 PM, Sean Young (by way of Mauro Carvalho Chehab 
) wrote:
> ir-loopback can transmit IR on one rc device and check the correct
> scancode and protocol is decoded on a different rc device. This can be
> used to check IR transmission between two rc devices. Using rc-loopback,
> we use it to check the IR encoders and decoders themselves.
> 
> Signed-off-by: Sean Young 
> ---
>  tools/testing/selftests/Makefile  |   1 +
>  tools/testing/selftests/ir/.gitignore |   1 +
>  tools/testing/selftests/ir/Makefile   |  19 ++
>  tools/testing/selftests/ir/config |  12 ++
>  tools/testing/selftests/ir/ir-loopback.c  | 209 ++
>  tools/testing/selftests/ir/ir-loopback.sh |  28 +++
>  6 files changed, 270 insertions(+)
>  create mode 100644 tools/testing/selftests/ir/.gitignore
>  create mode 100644 tools/testing/selftests/ir/Makefile
>  create mode 100644 tools/testing/selftests/ir/config
>  create mode 100644 tools/testing/selftests/ir/ir-loopback.c
>  create mode 100755 tools/testing/selftests/ir/ir-loopback.sh

Why not add to the existing media directory? ../selftests/media_tests?

> 
> diff --git a/tools/testing/selftests/Makefile 
> b/tools/testing/selftests/Makefile
> index f1fe492c8e17..995034ea5546 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -15,6 +15,7 @@ TARGETS += futex
>  TARGETS += gpio
>  TARGETS += intel_pstate
>  TARGETS += ipc
> +TARGETS += ir

Does this test depend on any hardware being present in the system?

>  TARGETS += kcmp
>  TARGETS += kvm
>  TARGETS += lib
> diff --git a/tools/testing/selftests/ir/.gitignore 
> b/tools/testing/selftests/ir/.gitignore
> new file mode 100644
> index ..87bf2989b678
> --- /dev/null
> +++ b/tools/testing/selftests/ir/.gitignore
> @@ -0,0 +1 @@
> +ir-loopback
> diff --git a/tools/testing/selftests/ir/Makefile 
> b/tools/testing/selftests/ir/Makefile
> new file mode 100644
> index ..501b464e56b5
> --- /dev/null
> +++ b/tools/testing/selftests/ir/Makefile
> @@ -0,0 +1,19 @@
> +# SPDX-License-Identifier: GPL-2.0
> +uname_M := $(shell uname -m 2>/dev/null || echo not)
> +ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/)
> +ifeq ($(ARCH),i386)
> +ARCH := x86
> + CFLAGS := -DCONFIG_X86_32 -D__i386__
> +endif
> +ifeq ($(ARCH),x86_64)
> + ARCH := x86
> + CFLAGS := -DCONFIG_X86_64 -D__x86_64__
> +endif
> +
> +CFLAGS += -I../../../../usr/include/
> +
> +TEST_PROGS := ir-loopback.sh
> +
> +TEST_GEN_PROGS := ir-loopback

Looks like ir-loopback get run from ir-loopback.sh. TEST_GEN_PROGS_EXTENDED
is the right variable to use in this case.

TEST_GEN_PROGS_EXTENDED := ir-loopback

> +
> +include ../lib.mk
> diff --git a/tools/testing/selftests/ir/config 
> b/tools/testing/selftests/ir/config
> new file mode 100644
> index ..78e041e9319e
> --- /dev/null
> +++ b/tools/testing/selftests/ir/config
> @@ -0,0 +1,12 @@
> +CONFIG_RC_CORE=y
> +CONFIG_RC_LOOPBACK=y
> +CONFIG_IR_NEC_DECODER=m
> +CONFIG_IR_RC5_DECODER=m
> +CONFIG_IR_RC6_DECODER=m
> +CONFIG_IR_JVC_DECODER=m
> +CONFIG_IR_SONY_DECODER=m
> +CONFIG_IR_SANYO_DECODER=m
> +CONFIG_IR_SHARP_DECODER=m
> +CONFIG_IR_MCE_KBD_DECODER=m
> +CONFIG_IR_XMP_DECODER=m
> +CONFIG_IR_IMON_DECODER=m
> diff --git a/tools/testing/selftests/ir/ir-loopback.c 
> b/tools/testing/selftests/ir/ir-loopback.c
> new file mode 100644
> index ..95b6f0f2f1f5
> --- /dev/null
> +++ b/tools/testing/selftests/ir/ir-loopback.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// test ir decoder
> +//
> +// Copyright (C) 2018 Sean Young 
> +
> +// When sending LIRC_MODE_SCANCODE, the IR will be encoded. rc-loopback
> +// will send this IR to the receiver side, where we try to read the decoded
> +// IR. Decoding happens in a separate kernel thread, so we will need to
> +// wait until that is scheduled, hence we use poll to check for read
> +// readiness.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TEST_SCANCODES   10
> +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +
> +static const struct {
> + enum rc_proto proto;
> + const char *name;
> + unsigned int mask;
> + const char *decoder;
> +} protocols[] = {
> + { RC_PROTO_RC5, "rc-5", 0x

[RFCv3 PATCH 3/3] vimc: add property test code

[Hans Verkuil]

From: Hans Verkuil 

Add properties to entities and pads to be able to test the
properties API.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vimc/vimc-common.c | 50 +++
 1 file changed, 50 insertions(+)

diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index dee1b9dfc4f6..2f70e4e64790 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -415,6 +415,7 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
 const unsigned long *pads_flag,
 const struct v4l2_subdev_ops *sd_ops)
 {
+   struct media_prop *prop = NULL;
int ret;
 
/* Allocate the pads */
@@ -452,6 +453,55 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
goto err_clean_m_ent;
}
 
+   ret = media_entity_add_prop_u64(>entity, "u64", ~1);
+   if (!ret)
+   ret = media_entity_add_prop_s64(>entity, "s64", -5);
+   if (!ret)
+   ret = media_entity_add_prop_string(>entity, "string",
+  sd->name);
+   if (!ret) {
+   prop = media_entity_add_prop_group(>entity, "empty-group");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret) {
+   prop = media_entity_add_prop_group(>entity, "group");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret)
+   ret = media_prop_add_prop_u64(prop, "u64", 42);
+   if (!ret)
+   ret = media_prop_add_prop_s64(prop, "s64", -42);
+   if (!ret)
+   ret = media_prop_add_prop_string(prop, "string", "42");
+   if (!ret)
+   ret = media_pad_add_prop_u64(>entity.pads[num_pads - 1],
+"u64", ~1);
+   if (!ret)
+   ret = media_pad_add_prop_s64(>entity.pads[num_pads - 1],
+"s64", -5);
+   if (!ret) {
+   prop = media_pad_add_prop_group(>entity.pads[num_pads - 1],
+   "group");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret)
+   ret = media_prop_add_prop_u64(prop, "u64", 24);
+   if (!ret)
+   ret = media_prop_add_prop_s64(prop, "s64", -24);
+   if (!ret)
+   ret = media_pad_add_prop_string(>entity.pads[0],
+   "string", sd->name);
+   if (!ret)
+   ret = media_prop_add_prop_string(prop, "string", "24");
+   if (!ret) {
+   prop = media_prop_add_prop_group(prop, "subgroup");
+   ret = PTR_ERR_OR_ZERO(prop);
+   }
+   if (!ret)
+   ret = media_prop_add_prop_string(prop, "string", "substring");
+   if (ret)
+   goto err_clean_m_ent;
+
return 0;
 
 err_clean_m_ent:
-- 
2.19.0

[RFCv2 PATCH 3/3] vimc: add test properties

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vimc/vimc-common.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index 617415c224fe..db8a8d1eca54 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -452,6 +452,24 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
goto err_clean_m_ent;
}
 
+   ret = media_entity_add_prop_u64(>entity, "u64", ~1);
+   if (!ret)
+   ret = media_entity_add_prop_s64(>entity, "s64", -5);
+   if (!ret)
+   ret = media_entity_add_prop_string(>entity, "string",
+  sd->name);
+   if (!ret)
+   ret = media_pad_add_prop_u64(>entity.pads[num_pads - 1],
+"u64", ~1);
+   if (!ret)
+   ret = media_pad_add_prop_s64(>entity.pads[num_pads - 1],
+"s64", -5);
+   if (!ret)
+   ret = media_pad_add_prop_string(>entity.pads[0],
+   "string", sd->name);
+   if (ret)
+   goto err_clean_m_ent;
+
return 0;
 
 err_clean_m_ent:
-- 
2.18.0

[RFC PATCH 3/3] vimc: add test properties

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/vimc/vimc-common.c | 18 ++
 drivers/media/platform/vimc/vimc-core.c   |  6 +++---
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index 617415c224fe..db8a8d1eca54 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -452,6 +452,24 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
goto err_clean_m_ent;
}
 
+   ret = media_entity_add_prop_u64(>entity, "u64", ~1);
+   if (!ret)
+   ret = media_entity_add_prop_s64(>entity, "s64", -5);
+   if (!ret)
+   ret = media_entity_add_prop_string(>entity, "string",
+  sd->name);
+   if (!ret)
+   ret = media_pad_add_prop_u64(>entity.pads[num_pads - 1],
+"u64", ~1);
+   if (!ret)
+   ret = media_pad_add_prop_s64(>entity.pads[num_pads - 1],
+"s64", -5);
+   if (!ret)
+   ret = media_pad_add_prop_string(>entity.pads[0],
+   "string", sd->name);
+   if (ret)
+   goto err_clean_m_ent;
+
return 0;
 
 err_clean_m_ent:
diff --git a/drivers/media/platform/vimc/vimc-core.c 
b/drivers/media/platform/vimc/vimc-core.c
index 9246f265de31..d8d3803a47f9 100644
--- a/drivers/media/platform/vimc/vimc-core.c
+++ b/drivers/media/platform/vimc/vimc-core.c
@@ -309,13 +309,13 @@ static int vimc_probe(struct platform_device *pdev)
if (!vimc->subdevs)
return -ENOMEM;
 
+   /* Link the media device within the v4l2_device */
+   vimc->v4l2_dev.mdev = >mdev;
+
match = vimc_add_subdevs(vimc);
if (IS_ERR(match))
return PTR_ERR(match);
 
-   /* Link the media device within the v4l2_device */
-   vimc->v4l2_dev.mdev = >mdev;
-
/* Initialize media device */
strlcpy(vimc->mdev.model, VIMC_MDEV_MODEL_NAME,
sizeof(vimc->mdev.model));
-- 
2.18.0

Re: [PATCH v3 4/4] selftests: media_tests: Add a memory-to-memory concurrent stress test

[Guillaume Tucker]

Hi Ezequiel,

On 01/08/18 22:50, Ezequiel Garcia wrote:

Add a test for the memory-to-memory framework, to exercise the
scheduling of concurrent jobs, using multiple contexts.

This test needs to be run using the vim2m virtual driver,
and so needs no hardware.

While here, rework the media_tests suite in order to make it
useful for automatic tools. Those tests that need human intervention
are now separated from those that can run automatically, needing
only virtual drivers to work.

Signed-off-by: Ezequiel Garcia 
---
  .../testing/selftests/media_tests/.gitignore  |   1 +
  tools/testing/selftests/media_tests/Makefile  |   5 +-
  .../selftests/media_tests/m2m_job_test.c  | 287 ++
  .../selftests/media_tests/m2m_job_test.sh |  32 ++
  4 files changed, 324 insertions(+), 1 deletion(-)
  create mode 100644 tools/testing/selftests/media_tests/m2m_job_test.c
  create mode 100755 tools/testing/selftests/media_tests/m2m_job_test.sh

diff --git a/tools/testing/selftests/media_tests/.gitignore 
b/tools/testing/selftests/media_tests/.gitignore
index 8745eba39012..71c6508348ce 100644
--- a/tools/testing/selftests/media_tests/.gitignore
+++ b/tools/testing/selftests/media_tests/.gitignore
@@ -1,3 +1,4 @@
  media_device_test
  media_device_open
  video_device_test
+m2m_job_test
diff --git a/tools/testing/selftests/media_tests/Makefile 
b/tools/testing/selftests/media_tests/Makefile
index 60826d7d37d4..d25d4c3eb7d2 100644
--- a/tools/testing/selftests/media_tests/Makefile
+++ b/tools/testing/selftests/media_tests/Makefile
@@ -1,6 +1,9 @@
  # SPDX-License-Identifier: GPL-2.0
  #
  CFLAGS += -I../ -I../../../../usr/include/
-TEST_GEN_PROGS := media_device_test media_device_open video_device_test
+TEST_GEN_PROGS_EXTENDED := media_device_test media_device_open 
video_device_test m2m_job_test
+TEST_PROGS := m2m_job_test.sh
  
  include ../lib.mk

+
+LDLIBS += -lpthread
diff --git a/tools/testing/selftests/media_tests/m2m_job_test.c 
b/tools/testing/selftests/media_tests/m2m_job_test.c
new file mode 100644
index ..5800269567e6
--- /dev/null
+++ b/tools/testing/selftests/media_tests/m2m_job_test.c
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) Collabora, Ltd.


Add the year (2018), and authors (you).


+
+/*
+ * This file adds a test for the memory-to-memory
+ * framework.
+ *
+ * This test opens a user specified video device and then
+ * queues concurrent jobs. The jobs are totally dummy,
+ * its purpose is only to verify that each of the queued
+ * jobs is run, and is run only once.
+ *
+ * The vim2m driver is needed in order to run the test.
+ *
+ * Usage:
+ *  ./m2m-job-test -d /dev/videoX
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "../kselftest.h"
+
+#define V4L2_CID_TRANS_TIME_MSEC(V4L2_CID_USER_BASE + 0x1000)
+#define V4L2_CID_TRANS_NUM_BUFS (V4L2_CID_USER_BASE + 0x1001)
+
+#define MAX_TRANS_TIME_MSEC 500
+#define MAX_COUNT 50
+#define MAX_BUFFERS 5
+#define W 10
+#define H 10


I like short names, but W and H might be a little bit too short
esp for a macro.


+#ifndef DEBUG
+#define dprintf(fmt, arg...)   \
+   do {\
+   } while (0)
+#else
+#define dprintf(fmt, arg...) printf(fmt, ## arg)
+#endif
+
+static char video_device[256];
+static int thread_count;
+
+struct context {
+   int vfd;
+   unsigned int width;
+   unsigned int height;
+   int buffers;
+};
+
+static int req_src_buf(struct context *ctx, int buffers)
+{
+   struct v4l2_requestbuffers reqbuf;
+   struct v4l2_buffer buf;
+   int i, ret;
+
+   memset(, 0, sizeof(reqbuf));
+   memset(, 0, sizeof(buf));
+
+   reqbuf.count= buffers;
+   reqbuf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   reqbuf.memory   = V4L2_MEMORY_MMAP;
+   ret = ioctl(ctx->vfd, VIDIOC_REQBUFS, );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < buffers; i++) {
+   buf.type= V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   buf.memory  = V4L2_MEMORY_MMAP;
+   buf.index   = i;
+   ret = ioctl(ctx->vfd, VIDIOC_QUERYBUF, );
+   if (ret)
+   return ret;
+   buf.bytesused = W*H*2;


Shouldn't you be using ->width and ->height here rather than W
and H?

In fact, maybe these can actually be set as "static const
unsigned int WIDTH = 10;" in the main function rather than global
macros, since you're parring the context around at runtime.


+   ret = ioctl(ctx->vfd, VIDIOC_QBUF, );
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int req_dst_buf(struct context *ctx, int buffers)
+{
+   struct v4l2_requestbuffers reqbuf;
+   struct v4l2_buffer buf;
+   in

[PATCH v4 6/6] selftests: media_tests: Add a memory-to-memory concurrent stress test

[Ezequiel Garcia]

Add a test for the memory-to-memory framework, to exercise the
scheduling of concurrent jobs, using multiple contexts.

This test needs to be run using the vim2m virtual driver,
and so needs no hardware.

While here, rework the media_tests suite in order to make it
useful for automatic tools. Those tests that need human intervention
are now separated from those that can run automatically, needing
only virtual drivers to work.

Signed-off-by: Ezequiel Garcia 
---
 .../testing/selftests/media_tests/.gitignore  |   1 +
 tools/testing/selftests/media_tests/Makefile  |   5 +-
 .../selftests/media_tests/m2m_job_test.c  | 287 ++
 .../selftests/media_tests/m2m_job_test.sh |  32 ++
 4 files changed, 324 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/media_tests/m2m_job_test.c
 create mode 100755 tools/testing/selftests/media_tests/m2m_job_test.sh

diff --git a/tools/testing/selftests/media_tests/.gitignore 
b/tools/testing/selftests/media_tests/.gitignore
index 8745eba39012..71c6508348ce 100644
--- a/tools/testing/selftests/media_tests/.gitignore
+++ b/tools/testing/selftests/media_tests/.gitignore
@@ -1,3 +1,4 @@
 media_device_test
 media_device_open
 video_device_test
+m2m_job_test
diff --git a/tools/testing/selftests/media_tests/Makefile 
b/tools/testing/selftests/media_tests/Makefile
index 60826d7d37d4..d25d4c3eb7d2 100644
--- a/tools/testing/selftests/media_tests/Makefile
+++ b/tools/testing/selftests/media_tests/Makefile
@@ -1,6 +1,9 @@
 # SPDX-License-Identifier: GPL-2.0
 #
 CFLAGS += -I../ -I../../../../usr/include/
-TEST_GEN_PROGS := media_device_test media_device_open video_device_test
+TEST_GEN_PROGS_EXTENDED := media_device_test media_device_open 
video_device_test m2m_job_test
+TEST_PROGS := m2m_job_test.sh
 
 include ../lib.mk
+
+LDLIBS += -lpthread
diff --git a/tools/testing/selftests/media_tests/m2m_job_test.c 
b/tools/testing/selftests/media_tests/m2m_job_test.c
new file mode 100644
index ..5800269567e6
--- /dev/null
+++ b/tools/testing/selftests/media_tests/m2m_job_test.c
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) Collabora, Ltd.
+
+/*
+ * This file adds a test for the memory-to-memory
+ * framework.
+ *
+ * This test opens a user specified video device and then
+ * queues concurrent jobs. The jobs are totally dummy,
+ * its purpose is only to verify that each of the queued
+ * jobs is run, and is run only once.
+ *
+ * The vim2m driver is needed in order to run the test.
+ *
+ * Usage:
+ *  ./m2m-job-test -d /dev/videoX
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "../kselftest.h"
+
+#define V4L2_CID_TRANS_TIME_MSEC(V4L2_CID_USER_BASE + 0x1000)
+#define V4L2_CID_TRANS_NUM_BUFS (V4L2_CID_USER_BASE + 0x1001)
+
+#define MAX_TRANS_TIME_MSEC 500
+#define MAX_COUNT 50
+#define MAX_BUFFERS 5
+#define W 10
+#define H 10
+
+#ifndef DEBUG
+#define dprintf(fmt, arg...)   \
+   do {\
+   } while (0)
+#else
+#define dprintf(fmt, arg...) printf(fmt, ## arg)
+#endif
+
+static char video_device[256];
+static int thread_count;
+
+struct context {
+   int vfd;
+   unsigned int width;
+   unsigned int height;
+   int buffers;
+};
+
+static int req_src_buf(struct context *ctx, int buffers)
+{
+   struct v4l2_requestbuffers reqbuf;
+   struct v4l2_buffer buf;
+   int i, ret;
+
+   memset(, 0, sizeof(reqbuf));
+   memset(, 0, sizeof(buf));
+
+   reqbuf.count= buffers;
+   reqbuf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   reqbuf.memory   = V4L2_MEMORY_MMAP;
+   ret = ioctl(ctx->vfd, VIDIOC_REQBUFS, );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < buffers; i++) {
+   buf.type= V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   buf.memory  = V4L2_MEMORY_MMAP;
+   buf.index   = i;
+   ret = ioctl(ctx->vfd, VIDIOC_QUERYBUF, );
+   if (ret)
+   return ret;
+   buf.bytesused = W*H*2;
+   ret = ioctl(ctx->vfd, VIDIOC_QBUF, );
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int req_dst_buf(struct context *ctx, int buffers)
+{
+   struct v4l2_requestbuffers reqbuf;
+   struct v4l2_buffer buf;
+   int i, ret;
+
+   memset(, 0, sizeof(reqbuf));
+   memset(, 0, sizeof(buf));
+
+   reqbuf.count= buffers;
+   reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   reqbuf.memory   = V4L2_MEMORY_MMAP;
+
+   ret = ioctl(ctx->vfd, VIDIOC_REQBUFS, );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < buffers; i++) {
+   buf.type= V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   buf.memory  = V4L2_MEMORY_MMA

Re: [PATCH] media: imx258: remove test pattern map from driver

[Sakari Ailus]

Hi Jason,

On Thu, Aug 02, 2018 at 04:17:00PM +0800, jasonx.z.c...@intel.com wrote:
> From: "Chen, JasonX Z" 
> 
> Test Pattern mode be picked at HAL instead of driver.
> do a FLIP when userspace use test pattern mode.
> add entity_ops for validating imx258 link.

Hmm. I think this would be changed based on my comments anyway, but please
explain what you're doing and *why*. HAL is not relevant in this context
I'd say.

> 
> Signed-off-by: Chen, JasonX Z 
> ---
>  drivers/media/i2c/imx258.c | 28 
>  1 file changed, 8 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index 31a1e22..71f9875 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -62,11 +62,6 @@
>  
>  /* Test Pattern Control */
>  #define IMX258_REG_TEST_PATTERN  0x0600
> -#define IMX258_TEST_PATTERN_DISABLE  0
> -#define IMX258_TEST_PATTERN_SOLID_COLOR  1
> -#define IMX258_TEST_PATTERN_COLOR_BARS   2
> -#define IMX258_TEST_PATTERN_GREY_COLOR   3
> -#define IMX258_TEST_PATTERN_PN9  4
>  
>  /* Orientation */
>  #define REG_MIRROR_FLIP_CONTROL  0x0101
> @@ -504,20 +499,12 @@ struct imx258_mode {
>  
>  static const char * const imx258_test_pattern_menu[] = {
>   "Disabled",
> - "Color Bars",
>   "Solid Color",
> + "Color Bars",
>   "Grey Color Bars",
>   "PN9"
>  };
>  
> -static const int imx258_test_pattern_val[] = {
> - IMX258_TEST_PATTERN_DISABLE,
> - IMX258_TEST_PATTERN_COLOR_BARS,
> - IMX258_TEST_PATTERN_SOLID_COLOR,
> - IMX258_TEST_PATTERN_GREY_COLOR,
> - IMX258_TEST_PATTERN_PN9,
> -};
> -
>  /* Configurations for supported link frequencies */
>  #define IMX258_LINK_FREQ_634MHZ  63360ULL
>  #define IMX258_LINK_FREQ_320MHZ  32000ULL
> @@ -752,7 +739,6 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
>   container_of(ctrl->handler, struct imx258, ctrl_handler);
>   struct i2c_client *client = v4l2_get_subdevdata(>sd);
>   int ret = 0;
> -

I think this newline is where it should be.

>   /*
>* Applying V4L2 control value only happens
>* when power is up for streaming
> @@ -778,13 +764,10 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
>   case V4L2_CID_TEST_PATTERN:
>   ret = imx258_write_reg(imx258, IMX258_REG_TEST_PATTERN,
>   IMX258_REG_VALUE_16BIT,
> - imx258_test_pattern_val[ctrl->val]);
> -
> + ctrl->val);
>   ret = imx258_write_reg(imx258, REG_MIRROR_FLIP_CONTROL,
>   IMX258_REG_VALUE_08BIT,
> - ctrl->val == imx258_test_pattern_val
> - [IMX258_TEST_PATTERN_DISABLE] ?
> - REG_CONFIG_MIRROR_FLIP :
> + !ctrl->val?REG_CONFIG_MIRROR_FLIP :

Spaces around "?".

>   REG_CONFIG_FLIP_TEST_PATTERN);
>   break;
>   default:
> @@ -1105,6 +1088,10 @@ static int imx258_identify_module(struct imx258 
> *imx258)
>   .pad = _pad_ops,
>  };
>  
> +static const struct media_entity_operations imx258_subdev_entity_ops = {
> + .link_validate = v4l2_subdev_link_validate,

The sensor only has a source pad while the link validate is only needed for
sink pads.

> +};
> +
>  static const struct v4l2_subdev_internal_ops imx258_internal_ops = {
>   .open = imx258_open,
>  };
> @@ -1250,6 +1237,7 @@ static int imx258_probe(struct i2c_client *client)
>  
>   /* Initialize subdev */
>   imx258->sd.internal_ops = _internal_ops;
> + imx258->sd.entity.ops  = _subdev_entity_ops;
>   imx258->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>   imx258->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
>  

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

[PATCH] media: imx258: remove test pattern map from driver

[jasonx . z . chen]

From: "Chen, JasonX Z" 

Test Pattern mode be picked at HAL instead of driver.
do a FLIP when userspace use test pattern mode.
add entity_ops for validating imx258 link.

Signed-off-by: Chen, JasonX Z 
---
 drivers/media/i2c/imx258.c | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index 31a1e22..71f9875 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -62,11 +62,6 @@
 
 /* Test Pattern Control */
 #define IMX258_REG_TEST_PATTERN0x0600
-#define IMX258_TEST_PATTERN_DISABLE0
-#define IMX258_TEST_PATTERN_SOLID_COLOR1
-#define IMX258_TEST_PATTERN_COLOR_BARS 2
-#define IMX258_TEST_PATTERN_GREY_COLOR 3
-#define IMX258_TEST_PATTERN_PN94
 
 /* Orientation */
 #define REG_MIRROR_FLIP_CONTROL0x0101
@@ -504,20 +499,12 @@ struct imx258_mode {
 
 static const char * const imx258_test_pattern_menu[] = {
"Disabled",
-   "Color Bars",
"Solid Color",
+   "Color Bars",
"Grey Color Bars",
"PN9"
 };
 
-static const int imx258_test_pattern_val[] = {
-   IMX258_TEST_PATTERN_DISABLE,
-   IMX258_TEST_PATTERN_COLOR_BARS,
-   IMX258_TEST_PATTERN_SOLID_COLOR,
-   IMX258_TEST_PATTERN_GREY_COLOR,
-   IMX258_TEST_PATTERN_PN9,
-};
-
 /* Configurations for supported link frequencies */
 #define IMX258_LINK_FREQ_634MHZ63360ULL
 #define IMX258_LINK_FREQ_320MHZ32000ULL
@@ -752,7 +739,6 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
container_of(ctrl->handler, struct imx258, ctrl_handler);
struct i2c_client *client = v4l2_get_subdevdata(>sd);
int ret = 0;
-
/*
 * Applying V4L2 control value only happens
 * when power is up for streaming
@@ -778,13 +764,10 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_TEST_PATTERN:
ret = imx258_write_reg(imx258, IMX258_REG_TEST_PATTERN,
IMX258_REG_VALUE_16BIT,
-   imx258_test_pattern_val[ctrl->val]);
-
+   ctrl->val);
ret = imx258_write_reg(imx258, REG_MIRROR_FLIP_CONTROL,
IMX258_REG_VALUE_08BIT,
-   ctrl->val == imx258_test_pattern_val
-   [IMX258_TEST_PATTERN_DISABLE] ?
-   REG_CONFIG_MIRROR_FLIP :
+   !ctrl->val?REG_CONFIG_MIRROR_FLIP :
REG_CONFIG_FLIP_TEST_PATTERN);
break;
default:
@@ -1105,6 +1088,10 @@ static int imx258_identify_module(struct imx258 *imx258)
.pad = _pad_ops,
 };
 
+static const struct media_entity_operations imx258_subdev_entity_ops = {
+   .link_validate = v4l2_subdev_link_validate,
+};
+
 static const struct v4l2_subdev_internal_ops imx258_internal_ops = {
.open = imx258_open,
 };
@@ -1250,6 +1237,7 @@ static int imx258_probe(struct i2c_client *client)
 
/* Initialize subdev */
imx258->sd.internal_ops = _internal_ops;
+   imx258->sd.entity.ops  = _subdev_entity_ops;
imx258->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
imx258->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
 
-- 
1.9.1

[PATCH v3 4/4] selftests: media_tests: Add a memory-to-memory concurrent stress test

[Ezequiel Garcia]

Add a test for the memory-to-memory framework, to exercise the
scheduling of concurrent jobs, using multiple contexts.

This test needs to be run using the vim2m virtual driver,
and so needs no hardware.

While here, rework the media_tests suite in order to make it
useful for automatic tools. Those tests that need human intervention
are now separated from those that can run automatically, needing
only virtual drivers to work.

Signed-off-by: Ezequiel Garcia 
---
 .../testing/selftests/media_tests/.gitignore  |   1 +
 tools/testing/selftests/media_tests/Makefile  |   5 +-
 .../selftests/media_tests/m2m_job_test.c  | 287 ++
 .../selftests/media_tests/m2m_job_test.sh |  32 ++
 4 files changed, 324 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/media_tests/m2m_job_test.c
 create mode 100755 tools/testing/selftests/media_tests/m2m_job_test.sh

diff --git a/tools/testing/selftests/media_tests/.gitignore 
b/tools/testing/selftests/media_tests/.gitignore
index 8745eba39012..71c6508348ce 100644
--- a/tools/testing/selftests/media_tests/.gitignore
+++ b/tools/testing/selftests/media_tests/.gitignore
@@ -1,3 +1,4 @@
 media_device_test
 media_device_open
 video_device_test
+m2m_job_test
diff --git a/tools/testing/selftests/media_tests/Makefile 
b/tools/testing/selftests/media_tests/Makefile
index 60826d7d37d4..d25d4c3eb7d2 100644
--- a/tools/testing/selftests/media_tests/Makefile
+++ b/tools/testing/selftests/media_tests/Makefile
@@ -1,6 +1,9 @@
 # SPDX-License-Identifier: GPL-2.0
 #
 CFLAGS += -I../ -I../../../../usr/include/
-TEST_GEN_PROGS := media_device_test media_device_open video_device_test
+TEST_GEN_PROGS_EXTENDED := media_device_test media_device_open 
video_device_test m2m_job_test
+TEST_PROGS := m2m_job_test.sh
 
 include ../lib.mk
+
+LDLIBS += -lpthread
diff --git a/tools/testing/selftests/media_tests/m2m_job_test.c 
b/tools/testing/selftests/media_tests/m2m_job_test.c
new file mode 100644
index ..5800269567e6
--- /dev/null
+++ b/tools/testing/selftests/media_tests/m2m_job_test.c
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) Collabora, Ltd.
+
+/*
+ * This file adds a test for the memory-to-memory
+ * framework.
+ *
+ * This test opens a user specified video device and then
+ * queues concurrent jobs. The jobs are totally dummy,
+ * its purpose is only to verify that each of the queued
+ * jobs is run, and is run only once.
+ *
+ * The vim2m driver is needed in order to run the test.
+ *
+ * Usage:
+ *  ./m2m-job-test -d /dev/videoX
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "../kselftest.h"
+
+#define V4L2_CID_TRANS_TIME_MSEC(V4L2_CID_USER_BASE + 0x1000)
+#define V4L2_CID_TRANS_NUM_BUFS (V4L2_CID_USER_BASE + 0x1001)
+
+#define MAX_TRANS_TIME_MSEC 500
+#define MAX_COUNT 50
+#define MAX_BUFFERS 5
+#define W 10
+#define H 10
+
+#ifndef DEBUG
+#define dprintf(fmt, arg...)   \
+   do {\
+   } while (0)
+#else
+#define dprintf(fmt, arg...) printf(fmt, ## arg)
+#endif
+
+static char video_device[256];
+static int thread_count;
+
+struct context {
+   int vfd;
+   unsigned int width;
+   unsigned int height;
+   int buffers;
+};
+
+static int req_src_buf(struct context *ctx, int buffers)
+{
+   struct v4l2_requestbuffers reqbuf;
+   struct v4l2_buffer buf;
+   int i, ret;
+
+   memset(, 0, sizeof(reqbuf));
+   memset(, 0, sizeof(buf));
+
+   reqbuf.count= buffers;
+   reqbuf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   reqbuf.memory   = V4L2_MEMORY_MMAP;
+   ret = ioctl(ctx->vfd, VIDIOC_REQBUFS, );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < buffers; i++) {
+   buf.type= V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   buf.memory  = V4L2_MEMORY_MMAP;
+   buf.index   = i;
+   ret = ioctl(ctx->vfd, VIDIOC_QUERYBUF, );
+   if (ret)
+   return ret;
+   buf.bytesused = W*H*2;
+   ret = ioctl(ctx->vfd, VIDIOC_QBUF, );
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int req_dst_buf(struct context *ctx, int buffers)
+{
+   struct v4l2_requestbuffers reqbuf;
+   struct v4l2_buffer buf;
+   int i, ret;
+
+   memset(, 0, sizeof(reqbuf));
+   memset(, 0, sizeof(buf));
+
+   reqbuf.count= buffers;
+   reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   reqbuf.memory   = V4L2_MEMORY_MMAP;
+
+   ret = ioctl(ctx->vfd, VIDIOC_REQBUFS, );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < buffers; i++) {
+   buf.type= V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   buf.memory  = V4L2_MEMORY_MMA

[PATCH v2 5/5] selftests: media_tests: Add a memory-to-memory concurrent stress test

[Ezequiel Garcia]

Add a test for the memory-to-memory framework, to exercise the
scheduling of concurrent jobs, using multiple contexts.

This test needs to be run using the vim2m virtual driver,
and so needs no hardware.

Signed-off-by: Ezequiel Garcia 
---
 tools/testing/selftests/media_tests/Makefile  |   4 +-
 .../selftests/media_tests/m2m_job_test.c  | 283 ++
 2 files changed, 286 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/media_tests/m2m_job_test.c

diff --git a/tools/testing/selftests/media_tests/Makefile 
b/tools/testing/selftests/media_tests/Makefile
index 60826d7d37d4..d2e8a6b685fb 100644
--- a/tools/testing/selftests/media_tests/Makefile
+++ b/tools/testing/selftests/media_tests/Makefile
@@ -1,6 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 #
 CFLAGS += -I../ -I../../../../usr/include/
-TEST_GEN_PROGS := media_device_test media_device_open video_device_test
+TEST_GEN_PROGS := media_device_test media_device_open video_device_test 
m2m_job_test
 
 include ../lib.mk
+
+LDLIBS += -lpthread
diff --git a/tools/testing/selftests/media_tests/m2m_job_test.c 
b/tools/testing/selftests/media_tests/m2m_job_test.c
new file mode 100644
index ..673e7b5cea3a
--- /dev/null
+++ b/tools/testing/selftests/media_tests/m2m_job_test.c
@@ -0,0 +1,283 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) Collabora, Ltd.
+
+/*
+ * This file adds a test for the memory-to-memory
+ * framework.
+ *
+ * This test opens a user specified video device and then
+ * queues concurrent jobs. The jobs are totally dummy,
+ * its purpose is only to verify that each of the queued
+ * jobs is run, and is run only once.
+ *
+ * The vim2m driver is needed in order to run the test.
+ *
+ * Usage:
+ *  ./m2m-job-test -d /dev/videoX
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define V4L2_CID_TRANS_TIME_MSEC(V4L2_CID_USER_BASE + 0x1000)
+#define V4L2_CID_TRANS_NUM_BUFS (V4L2_CID_USER_BASE + 0x1001)
+
+#define MAX_TRANS_TIME_MSEC 500
+#define MAX_COUNT 300
+#define MAX_BUFFERS 5
+#define W 100
+#define H 100
+
+#ifndef DEBUG
+#define dprintf(fmt, arg...)   \
+   do {\
+   } while (0)
+#else
+#define dprintf(fmt, arg...) printf(fmt, ## arg)
+#endif
+
+static char video_device[256];
+static int thread_count;
+
+struct context {
+   int vfd;
+   unsigned int width;
+   unsigned int height;
+   int buffers;
+};
+
+static int req_src_buf(struct context *ctx, int buffers)
+{
+   struct v4l2_requestbuffers reqbuf;
+   struct v4l2_buffer buf;
+   int i, ret;
+
+   memset(, 0, sizeof(reqbuf));
+   memset(, 0, sizeof(buf));
+
+   reqbuf.count= buffers;
+   reqbuf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   reqbuf.memory   = V4L2_MEMORY_MMAP;
+   ret = ioctl(ctx->vfd, VIDIOC_REQBUFS, );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < buffers; i++) {
+   buf.type= V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   buf.memory  = V4L2_MEMORY_MMAP;
+   buf.index   = i;
+   ret = ioctl(ctx->vfd, VIDIOC_QUERYBUF, );
+   if (ret)
+   return ret;
+   buf.bytesused = W*H*2;
+   ret = ioctl(ctx->vfd, VIDIOC_QBUF, );
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int req_dst_buf(struct context *ctx, int buffers)
+{
+   struct v4l2_requestbuffers reqbuf;
+   struct v4l2_buffer buf;
+   int i, ret;
+
+   memset(, 0, sizeof(reqbuf));
+   memset(, 0, sizeof(buf));
+
+   reqbuf.count= buffers;
+   reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   reqbuf.memory   = V4L2_MEMORY_MMAP;
+
+   ret = ioctl(ctx->vfd, VIDIOC_REQBUFS, );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < buffers; i++) {
+   buf.type= V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   buf.memory  = V4L2_MEMORY_MMAP;
+   buf.index   = i;
+   ret = ioctl(ctx->vfd, VIDIOC_QUERYBUF, );
+   if (ret)
+   return ret;
+   ret = ioctl(ctx->vfd, VIDIOC_QBUF, );
+   if (ret)
+   return ret;
+   }
+   return 0;
+}
+
+static int streamon(struct context *ctx)
+{
+   enum v4l2_buf_type type;
+   int ret;
+
+   type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   ret = ioctl(ctx->vfd, VIDIOC_STREAMON, );
+   if (ret)
+   return ret;
+
+   type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   ret = ioctl(ctx->vfd, VIDIOC_STREAMON, );
+   if (ret)
+   return ret;
+
+   return ret;
+}
+
+static int dqbuf(struct context *ctx)
+{
+   struct v4l2_buffer buf;
+   struct pollfd fds[] = {
+ 

[PATCH 2/2] media: rc: self test for IR encoders and decoders

[Sean Young]

ir-loopback can transmit IR on one rc device and check the correct
scancode and protocol is decoded on a different rc device. This can be
used to check IR transmission between two rc devices. Using rc-loopback,
we use it to check the IR encoders and decoders themselves.

Signed-off-by: Sean Young 
---
 tools/testing/selftests/Makefile  |   1 +
 tools/testing/selftests/ir/.gitignore |   1 +
 tools/testing/selftests/ir/Makefile   |  19 ++
 tools/testing/selftests/ir/config |  12 ++
 tools/testing/selftests/ir/ir-loopback.c  | 209 ++
 tools/testing/selftests/ir/ir-loopback.sh |  28 +++
 6 files changed, 270 insertions(+)
 create mode 100644 tools/testing/selftests/ir/.gitignore
 create mode 100644 tools/testing/selftests/ir/Makefile
 create mode 100644 tools/testing/selftests/ir/config
 create mode 100644 tools/testing/selftests/ir/ir-loopback.c
 create mode 100755 tools/testing/selftests/ir/ir-loopback.sh

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index f1fe492c8e17..995034ea5546 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -15,6 +15,7 @@ TARGETS += futex
 TARGETS += gpio
 TARGETS += intel_pstate
 TARGETS += ipc
+TARGETS += ir
 TARGETS += kcmp
 TARGETS += kvm
 TARGETS += lib
diff --git a/tools/testing/selftests/ir/.gitignore 
b/tools/testing/selftests/ir/.gitignore
new file mode 100644
index ..87bf2989b678
--- /dev/null
+++ b/tools/testing/selftests/ir/.gitignore
@@ -0,0 +1 @@
+ir-loopback
diff --git a/tools/testing/selftests/ir/Makefile 
b/tools/testing/selftests/ir/Makefile
new file mode 100644
index ..501b464e56b5
--- /dev/null
+++ b/tools/testing/selftests/ir/Makefile
@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: GPL-2.0
+uname_M := $(shell uname -m 2>/dev/null || echo not)
+ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/)
+ifeq ($(ARCH),i386)
+ARCH := x86
+   CFLAGS := -DCONFIG_X86_32 -D__i386__
+endif
+ifeq ($(ARCH),x86_64)
+   ARCH := x86
+   CFLAGS := -DCONFIG_X86_64 -D__x86_64__
+endif
+
+CFLAGS += -I../../../../usr/include/
+
+TEST_PROGS := ir-loopback.sh
+
+TEST_GEN_PROGS := ir-loopback
+
+include ../lib.mk
diff --git a/tools/testing/selftests/ir/config 
b/tools/testing/selftests/ir/config
new file mode 100644
index ..78e041e9319e
--- /dev/null
+++ b/tools/testing/selftests/ir/config
@@ -0,0 +1,12 @@
+CONFIG_RC_CORE=y
+CONFIG_RC_LOOPBACK=y
+CONFIG_IR_NEC_DECODER=m
+CONFIG_IR_RC5_DECODER=m
+CONFIG_IR_RC6_DECODER=m
+CONFIG_IR_JVC_DECODER=m
+CONFIG_IR_SONY_DECODER=m
+CONFIG_IR_SANYO_DECODER=m
+CONFIG_IR_SHARP_DECODER=m
+CONFIG_IR_MCE_KBD_DECODER=m
+CONFIG_IR_XMP_DECODER=m
+CONFIG_IR_IMON_DECODER=m
diff --git a/tools/testing/selftests/ir/ir-loopback.c 
b/tools/testing/selftests/ir/ir-loopback.c
new file mode 100644
index ..95b6f0f2f1f5
--- /dev/null
+++ b/tools/testing/selftests/ir/ir-loopback.c
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0
+// test ir decoder
+//
+// Copyright (C) 2018 Sean Young 
+
+// When sending LIRC_MODE_SCANCODE, the IR will be encoded. rc-loopback
+// will send this IR to the receiver side, where we try to read the decoded
+// IR. Decoding happens in a separate kernel thread, so we will need to
+// wait until that is scheduled, hence we use poll to check for read
+// readiness.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TEST_SCANCODES 10
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+static const struct {
+   enum rc_proto proto;
+   const char *name;
+   unsigned int mask;
+   const char *decoder;
+} protocols[] = {
+   { RC_PROTO_RC5, "rc-5", 0x1f7f, "rc-5" },
+   { RC_PROTO_RC5X_20, "rc-5x-20", 0x1f7f3f, "rc-5" },
+   { RC_PROTO_RC5_SZ, "rc-5-sz", 0x2fff, "rc-5-sz" },
+   { RC_PROTO_JVC, "jvc", 0x, "jvc" },
+   { RC_PROTO_SONY12, "sony-12", 0x1f007f, "sony" },
+   { RC_PROTO_SONY15, "sony-15", 0xff007f, "sony" },
+   { RC_PROTO_SONY20, "sony-20", 0x1fff7f, "sony" },
+   { RC_PROTO_NEC, "nec", 0x, "nec" },
+   { RC_PROTO_NECX, "nec-x", 0xff, "nec" },
+   { RC_PROTO_NEC32, "nec-32", 0x, "nec" },
+   { RC_PROTO_SANYO, "sanyo", 0x1f, "sanyo" },
+   { RC_PROTO_RC6_0, "rc-6-0", 0x, "rc-6" },
+   { RC_PROTO_RC6_6A_20, "rc-6-6a-20", 0xf, "rc-6" },
+   { RC_PROTO_RC6_6A_24, "rc-6-6a-24", 0xff, "rc-6" },
+   { RC_PROTO_RC6_6A_32, "rc-6-6a-32", 0x, "rc-6" },
+   { RC_PROTO_RC6_MCE, "rc-6-mc

Re: [PATCH 07/16] media: exymos4-is: allow compile test for EXYNOS FIMC-LITE

[Sylwester Nawrocki]

On 04/05/2018 07:54 PM, Mauro Carvalho Chehab wrote:
> There's nothing that prevents building this driver with
> COMPILE_TEST. So, enable it.
> 
> While here, make the Kconfig dependency cleaner by removing
> the unneeded if block.
> 
> Signed-off-by: Mauro Carvalho Chehab 

With s/exymos4-is/exynos4-is in the subject

Acked-by: Sylwester Nawrocki 

-- 
Regards,
Sylwester

[PATCH v2 07/19] media: exymos4-is: allow compile test for EXYNOS FIMC-LITE

[Mauro Carvalho Chehab]

There's nothing that prevents building this driver with
COMPILE_TEST. So, enable it.

While here, make the Kconfig dependency cleaner by removing
the unneeded if block.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/exynos4-is/Kconfig | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index 7b2c49e5a592..c8e5ad8f8294 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -41,11 +41,10 @@ config VIDEO_S5P_MIPI_CSIS
  To compile this driver as a module, choose M here: the
  module will be called s5p-csis.
 
-if SOC_EXYNOS4412 || SOC_EXYNOS5250
-
 config VIDEO_EXYNOS_FIMC_LITE
tristate "EXYNOS FIMC-LITE camera interface driver"
depends on I2C
+   depends on SOC_EXYNOS4412 || SOC_EXYNOS5250 || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select VIDEO_EXYNOS4_IS_COMMON
@@ -55,7 +54,6 @@ config VIDEO_EXYNOS_FIMC_LITE
 
  To compile this driver as a module, choose M here: the
  module will be called exynos-fimc-lite.
-endif
 
 config VIDEO_EXYNOS4_FIMC_IS
tristate "EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver"
-- 
2.14.3

[PATCH 07/16] media: exymos4-is: allow compile test for EXYNOS FIMC-LITE

[Mauro Carvalho Chehab]

There's nothing that prevents building this driver with
COMPILE_TEST. So, enable it.

While here, make the Kconfig dependency cleaner by removing
the unneeded if block.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/exynos4-is/Kconfig | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index 7b2c49e5a592..c8e5ad8f8294 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -41,11 +41,10 @@ config VIDEO_S5P_MIPI_CSIS
  To compile this driver as a module, choose M here: the
  module will be called s5p-csis.
 
-if SOC_EXYNOS4412 || SOC_EXYNOS5250
-
 config VIDEO_EXYNOS_FIMC_LITE
tristate "EXYNOS FIMC-LITE camera interface driver"
depends on I2C
+   depends on SOC_EXYNOS4412 || SOC_EXYNOS5250 || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select VIDEO_EXYNOS4_IS_COMMON
@@ -55,7 +54,6 @@ config VIDEO_EXYNOS_FIMC_LITE
 
  To compile this driver as a module, choose M here: the
  module will be called exynos-fimc-lite.
-endif
 
 config VIDEO_EXYNOS4_FIMC_IS
tristate "EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver"
-- 
2.14.3

[v4l-utils RFC 0/6] Mediatext test program for request API tests

[Sakari Ailus]

Hi folks,

Here's a refreshed RFC set to add the mediatext test program. It is well
suited for testing requests, as it can work with multiple devices
simultaneously as well as is easy to control through a bash script.

Only buffers are supported with requests, controls are not yet; still
adding support for controls wouldn't be much of work. I'm posting this as
RFC as the API coverage isn't great. What works now (as in this test
program) is requests with vim2m --- two bash scripts are included in the
last patch for that. The request API set v9 requires some adjusting, I
haven't tested v10 yet.

I'd say this is much closer being a meaningful part of v4l-utils, assuming
more test programs are seen to fit there.

Comments would be welcome.

Sakari Ailus (6):
  Linux kernel header update
  Make v4l-utils compile with request-related changes
  libmediactl: Add open, close and fd to public API
  mediatext: Extract list of V4L2 pixel format strings and 4cc codes
  mediatext: Add library
  mediatext: Add vivid tests

 include/linux/cec-funcs.h|  300 ++--
 include/linux/cec.h  |   40 +-
 include/linux/media.h|8 +
 include/linux/v4l2-dv-timings.h  |  979 
 include/linux/videodev2.h|   14 +-
 lib/libv4l2/libv4l2.c|4 +-
 libmediatext.pc.in   |   10 +
 utils/media-ctl/Makefile.am  |   18 +-
 utils/media-ctl/libmediactl.c|9 +-
 utils/media-ctl/libmediatext.pc.in   |   10 +
 utils/media-ctl/mediactl.h   |4 +
 utils/media-ctl/mediatext-test.c |  127 ++
 utils/media-ctl/mediatext.c  | 2176 ++
 utils/media-ctl/mediatext.h  |   33 +
 utils/media-ctl/tests/test-vivid-mc.bash |   86 +
 utils/media-ctl/tests/test-vivid.bash|   59 +
 utils/v4l2-compliance/v4l2-test-buffers.cpp  |2 +-
 utils/v4l2-compliance/v4l2-test-controls.cpp |4 -
 18 files changed, 3699 insertions(+), 184 deletions(-)
 create mode 100644 include/linux/v4l2-dv-timings.h
 create mode 100644 libmediatext.pc.in
 create mode 100644 utils/media-ctl/libmediatext.pc.in
 create mode 100644 utils/media-ctl/mediatext-test.c
 create mode 100644 utils/media-ctl/mediatext.c
 create mode 100644 utils/media-ctl/mediatext.h
 create mode 100755 utils/media-ctl/tests/test-vivid-mc.bash
 create mode 100755 utils/media-ctl/tests/test-vivid.bash

-- 
2.7.4

[PATCH v4l-utils] v4l2-compliance/v4l2-test-formats: fix typo

[Alexandre Courbot]

When using planar formats, we want to check pix_mp, not pix.

Signed-off-by: Alexandre Courbot <acour...@chromium.org>
---
 utils/v4l2-compliance/v4l2-test-formats.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils/v4l2-compliance/v4l2-test-formats.cpp 
b/utils/v4l2-compliance/v4l2-test-formats.cpp
index a336afdd..e9170688 100644
--- a/utils/v4l2-compliance/v4l2-test-formats.cpp
+++ b/utils/v4l2-compliance/v4l2-test-formats.cpp
@@ -452,7 +452,7 @@ static int testFormatsType(struct node *node, int ret,  
unsigned type, struct v4
if (!node->is_m2m)
fail_on_test(testColorspace(pix_mp.pixelformat, 
pix_mp.colorspace, 
 pix_mp.ycbcr_enc, 
pix_mp.quantization));
-   fail_on_test(pix.field == V4L2_FIELD_ANY);
+   fail_on_test(pix_mp.field == V4L2_FIELD_ANY);
ret = check_0(pix_mp.reserved, sizeof(pix_mp.reserved));
if (ret)
return fail("pix_mp.reserved not zeroed\n");
-- 
2.16.2.395.g2e18187dfd-goog

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Tim Harvey]

On Tue, Feb 6, 2018 at 11:05 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> On 02/06/2018 07:48 PM, Tim Harvey wrote:
>> On Mon, Feb 5, 2018 at 11:34 PM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>>> On 02/06/2018 08:16 AM, Tim Harvey wrote:
>>>> On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>> 
>>>>
>>>> With regards to the 3 failures:
>>>>
>>>> 1. test VIDIOC_G/S_EDID: FAIL
>>>> This is a valid catch where I was returning -EINVAL when the caller
>>>> was simply querying the edid - I've fixed it in my driver
>>>>
>>>> 2. test VIDIOC_DV_TIMINGS_CAP: FAIL
>>>> fail: v4l2-test-io-config.cpp(375): doioctl(node,
>>>> VIDIOC_DV_TIMINGS_CAP, ) != EINVAL
>>>> fail: v4l2-test-io-config.cpp(392): EDID check failed for source pad 0.
>>>>
>>>> It looks like the purpose of the test is to do an ioctl with an
>>>> invalid pad setting to ensure -EINVAL is returned. However by the time
>>>> the VIDIOC_DV_TIMINGS_CAP ioctl used here gets routed to a
>>>
>>> No, VIDIOC_SUBDEV_DV_TIMINGS_CAP == VIDIOC_DV_TIMINGS_CAP, i.e. the
>>> v4l-subdev API reuses the same ioctl as is used in the 'main' V4L2 API.
>>> See include/uapi/linux/v4l2-subdev.h at the end for a list of 'alias'
>>> ioctls.
>>
>> Ah... thanks - I realized that was happening somehow but couldn't see how :)
>>
>>>
>>> Looking at v7 your tda1997x_get_dv_timings_cap() function doesn't check
>>> for a valid pad field. Same for tda1997x_enum_dv_timings().
>>
>> Right - I noticed this right off as well - I've added pad validation
>> but that didn't resolve the failure.
>>
>> The test failing is:
>>
>> memset(, 0, sizeof(timingscap));
>> timingscap.pad = node->is_subdev() ? node->entity.pads : 1;
>>  this sets pad=node->entity.pads=1 which is invalid
>> fail_on_test(doioctl(node, VIDIOC_DV_TIMINGS_CAP, )
>> != EINVAL);
>>  tda1997x_get_dv_timings_cap() gets called with cap->pad = 0 which
>> is valid to returns 0. I don't understand how the userspace pad=1 get
>> changed to pad=0 in my handler.
>
> Actually, you don't need to test the pad in the driver, I just looked at
> the code in v4l2-core/v4l2-subdev.c and the pad is tested there already.
>
> And I just found why it is cleared: it's a bug in v4l2-ioctl.c.
>
> Look up VIDIOC_DV_TIMINGS_CAP in the big table and change this:
>
> INFO_FL_CLEAR(v4l2_dv_timings_cap, type)
>
> to this:
>
> INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)
>
> We never noticed this because we never tested this for subdevs. And that's
> why you write compliance tests!

Indeed that fixes it. I'll add that patch to my series.

All of the items on your review of v7 make sense and I'll be posting a
v8 hopefully shortly.

Thanks!

Tim

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/06/2018 07:48 PM, Tim Harvey wrote:
> On Mon, Feb 5, 2018 at 11:34 PM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>> On 02/06/2018 08:16 AM, Tim Harvey wrote:
>>> On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> 
>>>
>>> With regards to the 3 failures:
>>>
>>> 1. test VIDIOC_G/S_EDID: FAIL
>>> This is a valid catch where I was returning -EINVAL when the caller
>>> was simply querying the edid - I've fixed it in my driver
>>>
>>> 2. test VIDIOC_DV_TIMINGS_CAP: FAIL
>>> fail: v4l2-test-io-config.cpp(375): doioctl(node,
>>> VIDIOC_DV_TIMINGS_CAP, ) != EINVAL
>>> fail: v4l2-test-io-config.cpp(392): EDID check failed for source pad 0.
>>>
>>> It looks like the purpose of the test is to do an ioctl with an
>>> invalid pad setting to ensure -EINVAL is returned. However by the time
>>> the VIDIOC_DV_TIMINGS_CAP ioctl used here gets routed to a
>>
>> No, VIDIOC_SUBDEV_DV_TIMINGS_CAP == VIDIOC_DV_TIMINGS_CAP, i.e. the
>> v4l-subdev API reuses the same ioctl as is used in the 'main' V4L2 API.
>> See include/uapi/linux/v4l2-subdev.h at the end for a list of 'alias'
>> ioctls.
> 
> Ah... thanks - I realized that was happening somehow but couldn't see how :)
> 
>>
>> Looking at v7 your tda1997x_get_dv_timings_cap() function doesn't check
>> for a valid pad field. Same for tda1997x_enum_dv_timings().
> 
> Right - I noticed this right off as well - I've added pad validation
> but that didn't resolve the failure.
> 
> The test failing is:
> 
> memset(, 0, sizeof(timingscap));
> timingscap.pad = node->is_subdev() ? node->entity.pads : 1;
>  this sets pad=node->entity.pads=1 which is invalid
> fail_on_test(doioctl(node, VIDIOC_DV_TIMINGS_CAP, )
> != EINVAL);
>  tda1997x_get_dv_timings_cap() gets called with cap->pad = 0 which
> is valid to returns 0. I don't understand how the userspace pad=1 get
> changed to pad=0 in my handler.

Actually, you don't need to test the pad in the driver, I just looked at
the code in v4l2-core/v4l2-subdev.c and the pad is tested there already.

And I just found why it is cleared: it's a bug in v4l2-ioctl.c.

Look up VIDIOC_DV_TIMINGS_CAP in the big table and change this:

INFO_FL_CLEAR(v4l2_dv_timings_cap, type)

to this:

INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)

We never noticed this because we never tested this for subdevs. And that's
why you write compliance tests!

> 
>>
>>> VIDIOC_SUBDEV_DV_TIMINGS_CAP the pad is changed to 0 which is valid.
>>> I'm not following what's going on here.
>>>
>>> 3. test Try VIDIOC_SUBDEV_G/S_FMT: FAIL
>>> fail: v4l2-test-subdevs.cpp(303): fmt.code == 0 || fmt.code == ~0U
>>> fail: v4l2-test-subdevs.cpp(342): checkMBusFrameFmt(node, fmt.format)
>>>
>>> This is reporting that a VIDIOC_SUBDEV_G_FMT with
>>> which=V4L2_SUBDEV_FORMAT_TRY returns format->code = 0. The following
>>> is my set_format:
>>>
>>> static int tda1997x_get_format(struct v4l2_subdev *sd,
>>>struct v4l2_subdev_pad_config *cfg,
>>>struct v4l2_subdev_format *format)
>>> {
>>> struct tda1997x_state *state = to_state(sd);
>>>
>>> v4l_dbg(1, debug, state->client, "%s pad=%d which=%d\n",
>>> __func__, format->pad, format->which);
>>> if (format->pad != TDA1997X_PAD_SOURCE)
>>> return -EINVAL;
>>>
>>> tda1997x_fill_format(state, >format);
>>>
>>> if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
>>> struct v4l2_mbus_framefmt *fmt;
>>>
>>> fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
>>> format->format.code = fmt->code;
>>> } else {
>>> format->format.code = state->mbus_code;
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> I don't at all understand the V4L2_SUBDEV_FORMAT_TRY logic here which
>>> I took from other subdev drivers as boilerplate. Is the test valid?
>>
>> The test is valid, this really shouldn't return a 0 code. But I am not
>> sure what the right logic is. I'll need to do some digging myself.
> 
> I got lost in the v4l2_subdev_get_try_format implementation but closer
> inspection shows me that v4l2_subdev_get_try_format returns the
> try_fmt field of the v4l2_subdev_pad_config used for storing subdev
> pad info. What I'm missing is how that struct/field gets initialized?
> Do I need to implement an init_cfg op?

See my review of v7.

Regards,

Hans

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Tim Harvey]

On Mon, Feb 5, 2018 at 11:34 PM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> On 02/06/2018 08:16 AM, Tim Harvey wrote:
>> On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:

>>
>> With regards to the 3 failures:
>>
>> 1. test VIDIOC_G/S_EDID: FAIL
>> This is a valid catch where I was returning -EINVAL when the caller
>> was simply querying the edid - I've fixed it in my driver
>>
>> 2. test VIDIOC_DV_TIMINGS_CAP: FAIL
>> fail: v4l2-test-io-config.cpp(375): doioctl(node,
>> VIDIOC_DV_TIMINGS_CAP, ) != EINVAL
>> fail: v4l2-test-io-config.cpp(392): EDID check failed for source pad 0.
>>
>> It looks like the purpose of the test is to do an ioctl with an
>> invalid pad setting to ensure -EINVAL is returned. However by the time
>> the VIDIOC_DV_TIMINGS_CAP ioctl used here gets routed to a
>
> No, VIDIOC_SUBDEV_DV_TIMINGS_CAP == VIDIOC_DV_TIMINGS_CAP, i.e. the
> v4l-subdev API reuses the same ioctl as is used in the 'main' V4L2 API.
> See include/uapi/linux/v4l2-subdev.h at the end for a list of 'alias'
> ioctls.

Ah... thanks - I realized that was happening somehow but couldn't see how :)

>
> Looking at v7 your tda1997x_get_dv_timings_cap() function doesn't check
> for a valid pad field. Same for tda1997x_enum_dv_timings().

Right - I noticed this right off as well - I've added pad validation
but that didn't resolve the failure.

The test failing is:

memset(, 0, sizeof(timingscap));
timingscap.pad = node->is_subdev() ? node->entity.pads : 1;
 this sets pad=node->entity.pads=1 which is invalid
fail_on_test(doioctl(node, VIDIOC_DV_TIMINGS_CAP, )
!= EINVAL);
 tda1997x_get_dv_timings_cap() gets called with cap->pad = 0 which
is valid to returns 0. I don't understand how the userspace pad=1 get
changed to pad=0 in my handler.

>
>> VIDIOC_SUBDEV_DV_TIMINGS_CAP the pad is changed to 0 which is valid.
>> I'm not following what's going on here.
>>
>> 3. test Try VIDIOC_SUBDEV_G/S_FMT: FAIL
>> fail: v4l2-test-subdevs.cpp(303): fmt.code == 0 || fmt.code == ~0U
>> fail: v4l2-test-subdevs.cpp(342): checkMBusFrameFmt(node, fmt.format)
>>
>> This is reporting that a VIDIOC_SUBDEV_G_FMT with
>> which=V4L2_SUBDEV_FORMAT_TRY returns format->code = 0. The following
>> is my set_format:
>>
>> static int tda1997x_get_format(struct v4l2_subdev *sd,
>>struct v4l2_subdev_pad_config *cfg,
>>struct v4l2_subdev_format *format)
>> {
>> struct tda1997x_state *state = to_state(sd);
>>
>> v4l_dbg(1, debug, state->client, "%s pad=%d which=%d\n",
>> __func__, format->pad, format->which);
>> if (format->pad != TDA1997X_PAD_SOURCE)
>> return -EINVAL;
>>
>> tda1997x_fill_format(state, >format);
>>
>> if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
>> struct v4l2_mbus_framefmt *fmt;
>>
>> fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
>> format->format.code = fmt->code;
>> } else {
>> format->format.code = state->mbus_code;
>> }
>>
>> return 0;
>> }
>>
>> I don't at all understand the V4L2_SUBDEV_FORMAT_TRY logic here which
>> I took from other subdev drivers as boilerplate. Is the test valid?
>
> The test is valid, this really shouldn't return a 0 code. But I am not
> sure what the right logic is. I'll need to do some digging myself.

I got lost in the v4l2_subdev_get_try_format implementation but closer
inspection shows me that v4l2_subdev_get_try_format returns the
try_fmt field of the v4l2_subdev_pad_config used for storing subdev
pad info. What I'm missing is how that struct/field gets initialized?
Do I need to implement an init_cfg op?

Regards,

Tim

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/06/2018 08:16 AM, Tim Harvey wrote:
> On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>> Hi Tim, Jacopo,
>>
>> I have now finished writing the v4l2-compliance tests for the various 
>> v4l-subdev
>> ioctls. I managed to test some with the vimc driver, but that doesn't 
>> implement all
>> ioctls, so I could use some help testing my test code :-)
>>
>> To test you first need to apply these patches to your kernel:
>>
>> https://patchwork.linuxtv.org/patch/46817/
>> https://patchwork.linuxtv.org/patch/46822/
>>
>> Otherwise the compliance test will fail a lot.
>>
>> Now run v4l2-compliance -u /dev/v4l-subdevX (or -uX as a shortcut) and see 
>> what
>> happens.
>>
> 
> Hans,
> 
> Here's the compliance results for my tda1997x driver:
> 
> v4l2-compliance SHA   : b2f8f9049056eb6f9e028927dacb2c715a062df8
> Media Driver Info:
> Driver name  : imx-media
> Model: imx-media
> Serial   :
> Bus info :
> Media version: 4.15.0
> Hardware revision: 0x (0)
> Driver version   : 4.15.0
> Interface Info:
> ID   : 0x038f
> Type : V4L Sub-Device
> Entity Info:
> ID   : 0x0003 (3)
> Name : tda19971 2-0048
>     Function : Unknown
> Pad 0x0104   : Source
>   Link 0x026f: to remote pad 0x1000063 of entity
> 'ipu1_csi0_mux': Data, Enabled
> 
> Compliance test for device /dev/v4l-subdev1:
> 
> Allow for multiple opens:
> test second /dev/v4l-subdev1 open: OK
> test for unlimited opens: OK
> 
> Debug ioctls:
> test VIDIOC_LOG_STATUS: OK
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 0 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK
> fail: v4l2-test-io-config.cpp(375): doioctl(node,
> VIDIOC_DV_TIMINGS_CAP, ) != EINVAL
> fail: v4l2-test-io-config.cpp(392): EDID check failed
> for source pad 0.
> test VIDIOC_DV_TIMINGS_CAP: FAIL
> fail: v4l2-test-io-config.cpp(454): ret && ret != EINVAL
> fail: v4l2-test-io-config.cpp(533): EDID check failed
> for source pad 0.
> test VIDIOC_G/S_EDID: FAIL
> 
> Sub-Device ioctls (Source Pad 0):
> test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
> fail: v4l2-test-subdevs.cpp(303): fmt.code == 0 ||
> fmt.code == ~0U
> fail: v4l2-test-subdevs.cpp(342):
> checkMBusFrameFmt(node, fmt.format)
> test Try VIDIOC_SUBDEV_G/S_FMT: FAIL
> test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
> test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
> test Active VIDIOC_SUBDEV_G/S_FMT: OK
> test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
> test VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> test VIDIOC_QUERYCTRL: OK (Not Supported)
> test VIDIOC_G/S_CTRL: OK (Not Supported)
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 0 Private Controls: 0
> 
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported)
> root@ventana:~# cat foo
> v4l2-compliance SHA   : b2f8f9049056eb6f9e028927dacb2c715a062df8
> Media Driver Info:
> Driver name  : imx-media
> Model: imx-media
> Serial   :
> Bus info :
> Media version: 4.15.0
> Hardwa

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Tim Harvey]

On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> Hi Tim, Jacopo,
>
> I have now finished writing the v4l2-compliance tests for the various 
> v4l-subdev
> ioctls. I managed to test some with the vimc driver, but that doesn't 
> implement all
> ioctls, so I could use some help testing my test code :-)
>
> To test you first need to apply these patches to your kernel:
>
> https://patchwork.linuxtv.org/patch/46817/
> https://patchwork.linuxtv.org/patch/46822/
>
> Otherwise the compliance test will fail a lot.
>
> Now run v4l2-compliance -u /dev/v4l-subdevX (or -uX as a shortcut) and see 
> what
> happens.
>

Hans,

Here's the compliance results for my tda1997x driver:

v4l2-compliance SHA   : b2f8f9049056eb6f9e028927dacb2c715a062df8
Media Driver Info:
Driver name  : imx-media
Model: imx-media
Serial   :
Bus info :
Media version: 4.15.0
Hardware revision: 0x (0)
Driver version   : 4.15.0
Interface Info:
ID   : 0x038f
Type : V4L Sub-Device
Entity Info:
ID   : 0x0003 (3)
Name : tda19971 2-0048
Function : Unknown
Pad 0x0104   : Source
  Link 0x026f: to remote pad 0x1000063 of entity
'ipu1_csi0_mux': Data, Enabled

Compliance test for device /dev/v4l-subdev1:

Allow for multiple opens:
test second /dev/v4l-subdev1 open: OK
    test for unlimited opens: OK

Debug ioctls:
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
    test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
    test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
    Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
    test VIDIOC_G/S_MODULATOR: OK (Not Supported)
    test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK
fail: v4l2-test-io-config.cpp(375): doioctl(node,
VIDIOC_DV_TIMINGS_CAP, ) != EINVAL
fail: v4l2-test-io-config.cpp(392): EDID check failed
for source pad 0.
    test VIDIOC_DV_TIMINGS_CAP: FAIL
fail: v4l2-test-io-config.cpp(454): ret && ret != EINVAL
fail: v4l2-test-io-config.cpp(533): EDID check failed
for source pad 0.
    test VIDIOC_G/S_EDID: FAIL

Sub-Device ioctls (Source Pad 0):
test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
fail: v4l2-test-subdevs.cpp(303): fmt.code == 0 ||
fmt.code == ~0U
fail: v4l2-test-subdevs.cpp(342):
checkMBusFrameFmt(node, fmt.format)
test Try VIDIOC_SUBDEV_G/S_FMT: FAIL
    test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
test Active VIDIOC_SUBDEV_G/S_FMT: OK
test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
test VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)

Control ioctls:
    test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
    test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
    Standard Controls: 0 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported)
root@ventana:~# cat foo
v4l2-compliance SHA   : b2f8f9049056eb6f9e028927dacb2c715a062df8
Media Driver Info:
Driver name  : imx-media
Model: imx-media
Serial   :
Bus info :
Media version: 4.15.0
Hardware revision: 0x (0)
Driver version   : 4.15.0
Interface Info:
ID   : 0x038f
Type : V4L Sub-Device
Entity Info:
ID   : 0x0003 (3)
Name : tda19971 2-0048
Function : Unknown
Pad 0x0104   : Source
  Link 0x026f: to remote pad 0x163 of entity
'ipu1_csi0_mux': Data, Enabled

Compliance test for device /dev/v4l-subdev1:

Allow for multiple opens:
test second /dev/v4l-subdev1 open: OK
test for unlimited opens: OK

Debug ioctls:

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Mauro Carvalho Chehab]

Em Mon, 5 Feb 2018 18:01:34 +0100
Hans Verkuil  escreveu:

> On 02/05/2018 05:59 PM, Hans Verkuil wrote:
> > On 02/05/2018 05:55 PM, Mauro Carvalho Chehab wrote:  
> >> Em Mon, 5 Feb 2018 14:37:29 -0200
> >> Mauro Carvalho Chehab  escreveu:
> >>  
> >>> Em Mon, 5 Feb 2018 08:21:54 -0800
> >>> Tim Harvey  escreveu:
> >>>  
>  Hans,
> 
>  I'm failing compile (of master 4ee9911) with:
> 
>    CXX  v4l2_compliance-media-info.o
>  media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
>  media-info.cpp:79:39: error: no matching function for call to
>  ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
>    std::ifstream uevent_file(uevent_path);
> ^
> >>>
> >>> Btw, while on it, a few days ago, I noticed several class warnings when
> >>> building v4l-utils on Raspbian, saying that it was using some features
> >>> that future versions of gcc would stop using at qv4l2. See enclosed.
> >>>
> >>> I didn't have time to look on them.  
> >>
> >> FYI, it still happens with today's upstream's version:
> >>
> >>4ee99116d0ec (HEAD, origin/master, origin/HEAD) v4l2-ctl: improve the 
> >> fps calculation when streaming
> >>
> >> $ gcc --version
> >> gcc (Raspbian 6.3.0-18+rpi1) 6.3.0 20170516
> >> Copyright (C) 2016 Free Software Foundation, Inc.
> >> This is free software; see the source for copying conditions.  There is NO
> >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> >> PURPOSE.  
> > 
> > My guess is that it is a bogus message from gcc 6.
> > 
> > Regards,
> > 
> > Hans
> >   
> 
> See: https://gcc.gnu.org/ml/gcc/2017-05/msg00073.html
> 
> Nothing to worry about.

Hmm... as suggested there, it could be worth to add -Wno-psabi at qv4l2
Makefile if arch is arm[1], in order to avoid those warnings there.

[1] from what's said at https://gcc.gnu.org/gcc-7/changes.html, this is
due to a bug on gcc 5 for ARM.

> 
>   Hans



Thanks,
Mauro

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/05/2018 05:59 PM, Hans Verkuil wrote:
> On 02/05/2018 05:55 PM, Mauro Carvalho Chehab wrote:
>> Em Mon, 5 Feb 2018 14:37:29 -0200
>> Mauro Carvalho Chehab  escreveu:
>>
>>> Em Mon, 5 Feb 2018 08:21:54 -0800
>>> Tim Harvey  escreveu:
>>>
 Hans,

 I'm failing compile (of master 4ee9911) with:

   CXX  v4l2_compliance-media-info.o
 media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
 media-info.cpp:79:39: error: no matching function for call to
 ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
   std::ifstream uevent_file(uevent_path);
^  
>>>
>>> Btw, while on it, a few days ago, I noticed several class warnings when
>>> building v4l-utils on Raspbian, saying that it was using some features
>>> that future versions of gcc would stop using at qv4l2. See enclosed.
>>>
>>> I didn't have time to look on them.
>>
>> FYI, it still happens with today's upstream's version:
>>
>>  4ee99116d0ec (HEAD, origin/master, origin/HEAD) v4l2-ctl: improve the 
>> fps calculation when streaming
>>
>> $ gcc --version
>> gcc (Raspbian 6.3.0-18+rpi1) 6.3.0 20170516
>> Copyright (C) 2016 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> My guess is that it is a bogus message from gcc 6.
> 
> Regards,
> 
>   Hans
> 

See: https://gcc.gnu.org/ml/gcc/2017-05/msg00073.html

Nothing to worry about.

Hans

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/05/2018 05:55 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 5 Feb 2018 14:37:29 -0200
> Mauro Carvalho Chehab  escreveu:
> 
>> Em Mon, 5 Feb 2018 08:21:54 -0800
>> Tim Harvey  escreveu:
>>
>>> Hans,
>>>
>>> I'm failing compile (of master 4ee9911) with:
>>>
>>>   CXX  v4l2_compliance-media-info.o
>>> media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
>>> media-info.cpp:79:39: error: no matching function for call to
>>> ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
>>>   std::ifstream uevent_file(uevent_path);
>>>^  
>>
>> Btw, while on it, a few days ago, I noticed several class warnings when
>> building v4l-utils on Raspbian, saying that it was using some features
>> that future versions of gcc would stop using at qv4l2. See enclosed.
>>
>> I didn't have time to look on them.
> 
> FYI, it still happens with today's upstream's version:
> 
>   4ee99116d0ec (HEAD, origin/master, origin/HEAD) v4l2-ctl: improve the 
> fps calculation when streaming
> 
> $ gcc --version
> gcc (Raspbian 6.3.0-18+rpi1) 6.3.0 20170516
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

My guess is that it is a bogus message from gcc 6.

Regards,

Hans

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/05/2018 05:37 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 5 Feb 2018 08:21:54 -0800
> Tim Harvey  escreveu:
> 
>> Hans,
>>
>> I'm failing compile (of master 4ee9911) with:
>>
>>   CXX  v4l2_compliance-media-info.o
>> media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
>> media-info.cpp:79:39: error: no matching function for call to
>> ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
>>   std::ifstream uevent_file(uevent_path);
>>^
> 
> Btw, while on it, a few days ago, I noticed several class warnings when
> building v4l-utils on Raspbian, saying that it was using some features
> that future versions of gcc would stop using at qv4l2. See enclosed.
> 
> I didn't have time to look on them.
> 
> Thanks,
> Mauro
> 
> In file included from /usr/include/c++/6/map:60:0,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
>  from qv4l2.h:25,
>  from ctrl-tab.cpp:20:
> /usr/include/c++/6/bits/stl_tree.h: In member function 
> ‘std::pair 
> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, 
> _Alloc>::_M_get_insert_hint_unique_pos(std::_Rb_tree<_Key, _Val, _KeyOfValue, 
> _Compare, _Alloc>::const_iterator, const key_type&) [with _Key = unsigned 
> int; _Val = std::pair; _KeyOfValue = 
> std::_Select1st; 
> _Compare = std::less; _Alloc = std::allocator >]’:
> /usr/include/c++/6/bits/stl_tree.h:1928:5: note: parameter passing for 
> argument of type ‘std::_Rb_tree v4l2_query_ext_ctrl>, std::_Select1st >, std::less, 
> std::allocator 
> >::const_iterator {aka std::_Rb_tree_const_iterator >}’ will change in GCC 7.1
>  _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
>  ^~~

I've seen it too, but I have no idea what to do with it. I'm not even sure that 
it is in my
code instead of in Qt headers or even c++ header.

It's not exactly an informative message.

Since I compile with g++ version 7.2 it appears that it is just fine since it 
doesn't complain.

Regards,

Hans

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Mauro Carvalho Chehab]

Em Mon, 5 Feb 2018 14:37:29 -0200
Mauro Carvalho Chehab  escreveu:

> Em Mon, 5 Feb 2018 08:21:54 -0800
> Tim Harvey  escreveu:
> 
> > Hans,
> > 
> > I'm failing compile (of master 4ee9911) with:
> > 
> >   CXX  v4l2_compliance-media-info.o
> > media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
> > media-info.cpp:79:39: error: no matching function for call to
> > ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
> >   std::ifstream uevent_file(uevent_path);
> >^  
> 
> Btw, while on it, a few days ago, I noticed several class warnings when
> building v4l-utils on Raspbian, saying that it was using some features
> that future versions of gcc would stop using at qv4l2. See enclosed.
> 
> I didn't have time to look on them.

FYI, it still happens with today's upstream's version:

4ee99116d0ec (HEAD, origin/master, origin/HEAD) v4l2-ctl: improve the 
fps calculation when streaming

$ gcc --version
gcc (Raspbian 6.3.0-18+rpi1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


> 
> Thanks,
> Mauro
> 
> In file included from /usr/include/c++/6/map:60:0,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
>  from qv4l2.h:25,
>  from ctrl-tab.cpp:20:
> /usr/include/c++/6/bits/stl_tree.h: In member function 
> ‘std::pair 
> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, 
> _Alloc>::_M_get_insert_hint_unique_pos(std::_Rb_tree<_Key, _Val, _KeyOfValue, 
> _Compare, _Alloc>::const_iterator, const key_type&) [with _Key = unsigned 
> int; _Val = std::pair; _KeyOfValue = 
> std::_Select1st; 
> _Compare = std::less; _Alloc = std::allocator >]’:
> /usr/include/c++/6/bits/stl_tree.h:1928:5: note: parameter passing for 
> argument of type ‘std::_Rb_tree v4l2_query_ext_ctrl>, std::_Select1st >, std::less, 
> std::allocator 
> >::const_iterator {aka std::_Rb_tree_const_iterator >}’ will change in GCC 7.1
>  _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
>  ^~~
> /usr/include/c++/6/bits/stl_tree.h: In function ‘std::_Rb_tree<_Key, _Val, 
> _KeyOfValue, _Compare, _Alloc>::iterator std::_Rb_tree<_Key, _Val, 
> _KeyOfValue, _Compare, _Alloc>::_M_emplace_hint_unique(std::_Rb_tree<_Key, 
> _Val, _KeyOfValue, _Compare, _Alloc>::const_iterator, _Args&& ...) [with 
> _Args = {const std::piecewise_construct_t&, std::tuple, 
> std::tuple<>}; _Key = unsigned int; _Val = std::pair v4l2_query_ext_ctrl>; _KeyOfValue = std::_Select1st >; _Compare = std::less; _Alloc = 
> std::allocator]’:
> /usr/include/c++/6/bits/stl_tree.h:2193:7: note: parameter passing for 
> argument of type ‘std::_Rb_tree v4l2_query_ext_ctrl>, std::_Select1st >, std::less, 
> std::allocator 
> >::const_iterator {aka std::_Rb_tree_const_iterator >}’ will change in GCC 7.1
>_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
>^~~
> In file included from /usr/include/c++/6/map:61:0,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
>  from qv4l2.h:25,
>  from ctrl-tab.cpp:20:
> /usr/include/c++/6/bits/stl_map.h: In member function ‘void 
> ApplicationWindow::setWhat(QWidget*, unsigned int, const QString&)’:
> /usr/include/c++/6/bits/stl_map.h:483:4: note: parameter passing for argument 
> of type ‘std::_Rb_tree v4l2_query_ext_ctrl>, std::_Select1st >, std::less, 
> std::allocator 
> >::const_iterator {aka std::_Rb_tree_const_iterator >}’ will change in GCC 7.1
> __i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
> ^~~
> 

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Tim Harvey]

On Mon, Feb 5, 2018 at 8:27 AM, Hans Verkuil  wrote:
> On 02/05/2018 05:21 PM, Tim Harvey wrote:
>
> 
>
>>
>> I ran a 'make distclean; ./bootstrap.sh && ./configure && make'
>>
>> last version I built successfully was '1bb8c70 v4l2-ctl: mention that
>> --set-subdev-fps is for testing only'
>
> That's a lot of revisions ago. I've been busy last weekend :-)

right... I was up to date Thursday morning! ;)

>
> Do a new git pull and try again. I remember hitting something similar during
> the weekend where I was missing a C++ include.
>

Yes, I tried that on my x86 dev host - same failure as from my target.

>>
>> I haven't dug into the failure at all. Are you using something new
>> with c++ requiring a new lib or specific version of something that
>> needs to be added to configure?
>
> Nope, bog standard C++. Real C++ pros are probably appalled by the code.
>

Google to the rescue: The ifstream constructor expects a const char*,
so you need to do ifstream file(filename.c_str()); to make it work.

the following patch fixes it:

diff --git a/utils/common/media-info.cpp b/utils/common/media-info.cpp
index eef743e..39da9b8 100644
--- a/utils/common/media-info.cpp
+++ b/utils/common/media-info.cpp
@@ -76,7 +76,7 @@ media_type media_detect_type(const char *device)
uevent_path += num2s(major(sb.st_rdev), false) + ":" +
num2s(minor(sb.st_rdev), false) + "/uevent";

-   std::ifstream uevent_file(uevent_path);
+   std::ifstream uevent_file(uevent_path.c_str());
if (uevent_file.fail())
return MEDIA_TYPE_UNKNOWN;

@@ -117,7 +117,7 @@ std::string media_get_device(__u32 major, __u32 minor)
sprintf(fmt, "%d:%d", major, minor);
uevent_path += std::string(fmt) + "/uevent";

-   std::ifstream uevent_file(uevent_path);
+   std::ifstream uevent_file(uevent_path.c_str());
if (uevent_file.fail())
return "";

Tim

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Mauro Carvalho Chehab]

Em Mon, 5 Feb 2018 08:21:54 -0800
Tim Harvey  escreveu:

> Hans,
> 
> I'm failing compile (of master 4ee9911) with:
> 
>   CXX  v4l2_compliance-media-info.o
> media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
> media-info.cpp:79:39: error: no matching function for call to
> ‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
>   std::ifstream uevent_file(uevent_path);
>^

Btw, while on it, a few days ago, I noticed several class warnings when
building v4l-utils on Raspbian, saying that it was using some features
that future versions of gcc would stop using at qv4l2. See enclosed.

I didn't have time to look on them.

Thanks,
Mauro

In file included from /usr/include/c++/6/map:60:0,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
 from /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
 from qv4l2.h:25,
 from ctrl-tab.cpp:20:
/usr/include/c++/6/bits/stl_tree.h: In member function 
‘std::pair 
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, 
_Alloc>::_M_get_insert_hint_unique_pos(std::_Rb_tree<_Key, _Val, _KeyOfValue, 
_Compare, _Alloc>::const_iterator, const key_type&) [with _Key = unsigned int; 
_Val = std::pair; _KeyOfValue = 
std::_Select1st; _Compare 
= std::less; _Alloc = std::allocator]’:
/usr/include/c++/6/bits/stl_tree.h:1928:5: note: parameter passing for argument 
of type ‘std::_Rb_tree, std::_Select1st, std::less, std::allocator >::const_iterator {aka 
std::_Rb_tree_const_iterator}’ will change in GCC 7.1
 _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
 ^~~
/usr/include/c++/6/bits/stl_tree.h: In function ‘std::_Rb_tree<_Key, _Val, 
_KeyOfValue, _Compare, _Alloc>::iterator std::_Rb_tree<_Key, _Val, _KeyOfValue, 
_Compare, _Alloc>::_M_emplace_hint_unique(std::_Rb_tree<_Key, _Val, 
_KeyOfValue, _Compare, _Alloc>::const_iterator, _Args&& ...) [with _Args = 
{const std::piecewise_construct_t&, std::tuple, 
std::tuple<>}; _Key = unsigned int; _Val = std::pair; _KeyOfValue = std::_Select1st; _Compare = std::less; _Alloc = 
std::allocator]’:
/usr/include/c++/6/bits/stl_tree.h:2193:7: note: parameter passing for argument 
of type ‘std::_Rb_tree, std::_Select1st, std::less, std::allocator >::const_iterator {aka 
std::_Rb_tree_const_iterator}’ will change in GCC 7.1
   _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
   ^~~
In file included from /usr/include/c++/6/map:61:0,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
 from /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
 from qv4l2.h:25,
 from ctrl-tab.cpp:20:
/usr/include/c++/6/bits/stl_map.h: In member function ‘void 
ApplicationWindow::setWhat(QWidget*, unsigned int, const QString&)’:
/usr/include/c++/6/bits/stl_map.h:483:4: note: parameter passing for argument 
of type ‘std::_Rb_tree, std::_Select1st, std::less, std::allocator >::const_iterator {aka 
std::_Rb_tree_const_iterator}’ will change in GCC 7.1
__i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
^~~
/usr/include/c++/6/bits/stl_map.h: In member function ‘void 
ApplicationWindow::setWhat(QWidget*, unsigned int, long long int)’:
/usr/include/c++/6/bits/stl_map.h:483:4: note: parameter passing for argument 
of type ‘std::_Rb_tree, std::_Select1st, std::less, std::allocator >::const_iterator {aka 
std::_Rb_tree_const_iterator}’ will change in GCC 7.1
__i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
^~~
In file included from /usr/include/c++/6/map:60:0,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qmetatype.h:57,
 from /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:54,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qwidget.h:44,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/qmainwindow.h:43,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QMainWindow:1,
 from qv4l2.h:25,
   

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

On 02/05/2018 05:21 PM, Tim Harvey wrote:



> 
> I ran a 'make distclean; ./bootstrap.sh && ./configure && make'
> 
> last version I built successfully was '1bb8c70 v4l2-ctl: mention that
> --set-subdev-fps is for testing only'

That's a lot of revisions ago. I've been busy last weekend :-)

Do a new git pull and try again. I remember hitting something similar during
the weekend where I was missing a C++ include.

> 
> I haven't dug into the failure at all. Are you using something new
> with c++ requiring a new lib or specific version of something that
> needs to be added to configure?

Nope, bog standard C++. Real C++ pros are probably appalled by the code.

Regards,

Hans

Re: Please help test the new v4l-subdev support in v4l2-compliance

[Tim Harvey]

On Sat, Feb 3, 2018 at 7:56 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> Hi Tim, Jacopo,
>
> I have now finished writing the v4l2-compliance tests for the various 
> v4l-subdev
> ioctls. I managed to test some with the vimc driver, but that doesn't 
> implement all
> ioctls, so I could use some help testing my test code :-)
>
> To test you first need to apply these patches to your kernel:
>
> https://patchwork.linuxtv.org/patch/46817/
> https://patchwork.linuxtv.org/patch/46822/
>
> Otherwise the compliance test will fail a lot.
>
> Now run v4l2-compliance -u /dev/v4l-subdevX (or -uX as a shortcut) and see 
> what
> happens.
>
> I have tested the following ioctls with vimc, so they are likely to be 
> correct:
>
> #define VIDIOC_SUBDEV_G_FMT _IOWR('V',  4, struct 
> v4l2_subdev_format)
> #define VIDIOC_SUBDEV_S_FMT _IOWR('V',  5, struct 
> v4l2_subdev_format)
> #define VIDIOC_SUBDEV_ENUM_MBUS_CODE_IOWR('V',  2, struct 
> v4l2_subdev_mbus_code_enum)
> #define VIDIOC_SUBDEV_ENUM_FRAME_SIZE   _IOWR('V', 74, struct 
> v4l2_subdev_frame_size_enum)
>
> All others are untested:
>
> #define VIDIOC_SUBDEV_G_FRAME_INTERVAL  _IOWR('V', 21, struct 
> v4l2_subdev_frame_interval)
> #define VIDIOC_SUBDEV_S_FRAME_INTERVAL  _IOWR('V', 22, struct 
> v4l2_subdev_frame_interval)
> #define VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL   _IOWR('V', 75, struct 
> v4l2_subdev_frame_interval_enum)
> #define VIDIOC_SUBDEV_G_CROP_IOWR('V', 59, struct 
> v4l2_subdev_crop)
> #define VIDIOC_SUBDEV_S_CROP_IOWR('V', 60, struct 
> v4l2_subdev_crop)
> #define VIDIOC_SUBDEV_G_SELECTION   _IOWR('V', 61, struct 
> v4l2_subdev_selection)
> #define VIDIOC_SUBDEV_S_SELECTION   _IOWR('V', 62, struct 
> v4l2_subdev_selection)
> #define VIDIOC_SUBDEV_G_EDID_IOWR('V', 40, struct 
> v4l2_edid)
> #define VIDIOC_SUBDEV_S_EDID_IOWR('V', 41, struct 
> v4l2_edid)
> #define VIDIOC_SUBDEV_S_DV_TIMINGS  _IOWR('V', 87, struct 
> v4l2_dv_timings)
> #define VIDIOC_SUBDEV_G_DV_TIMINGS  _IOWR('V', 88, struct 
> v4l2_dv_timings)
> #define VIDIOC_SUBDEV_ENUM_DV_TIMINGS   _IOWR('V', 98, struct 
> v4l2_enum_dv_timings)
> #define VIDIOC_SUBDEV_QUERY_DV_TIMINGS  _IOR('V', 99, struct 
> v4l2_dv_timings)
> #define VIDIOC_SUBDEV_DV_TIMINGS_CAP_IOWR('V', 100, struct 
> v4l2_dv_timings_cap)
>
> I did the best I could, but there may very well be bugs in the test code.
>
> I will also test the timings and edid ioctls myself later next week at work.
>
> The v4l2-compliance utility can now also test media devices (-m option), 
> although that's
> early days yet. Eventually I want to be able to walk the graph and test each 
> device in
> turn.
>
> I have this idea of making v4l2-compliance, cec-compliance and 
> media-compliance
> frontends that can all share the actual test code. And perhaps that can 
> include a new
> dvb-compliance as well.
>
> However, that's future music, for now I just want to get proper ioctl test 
> coverage
> so driver authors can at least have some confidence in their code by running 
> these
> tests.
>

Hans,

I'm failing compile (of master 4ee9911) with:

  CXX  v4l2_compliance-media-info.o
media-info.cpp: In function ‘media_type media_detect_type(const char*)’:
media-info.cpp:79:39: error: no matching function for call to
‘std::basic_ifstream::basic_ifstream(std::__cxx11::string&)’
  std::ifstream uevent_file(uevent_path);
   ^
In file included from media-info.cpp:35:0:
/usr/include/c++/5/fstream:495:7: note: candidate:
std::basic_ifstream<_CharT, _Traits>::basic_ifstream(const char*,
std::ios_base::openmode) [with _CharT = char; _Traits =
std::char_traits; std::ios_base::openmode = std::_Ios_Openmode]
   basic_ifstream(const char* __s, ios_base::openmode __mode = ios_base::in)
   ^
/usr/include/c++/5/fstream:495:7: note:   no known conversion for
argument 1 from ‘std::__cxx11::string {aka
std::__cxx11::basic_string}’ to ‘const char*’
In file included from media-info.cpp:35:0:
/usr/include/c++/5/fstream:481:7: note: candidate:
std::basic_ifstream<_CharT, _Traits>::basic_ifstream() [with _CharT =
char; _Traits = std::char_traits]
   basic_ifstream() : __istream_type(), _M_filebuf()
   ^
/usr/include/c++/5/fstream:481:7: note:   candidate expects 0
arguments, 1 provided
In file included from media-info.cpp:35:0:
/usr/include/c++/5/fstream:455:11: note: candidate:
std::basic_ifstream::basic_ifstream(const
std::basic_ifstream&)
 class basic_ifstream : public basic_istream<_CharT, _Traits>

Please help test the new v4l-subdev support in v4l2-compliance

[Hans Verkuil]

Hi Tim, Jacopo,

I have now finished writing the v4l2-compliance tests for the various v4l-subdev
ioctls. I managed to test some with the vimc driver, but that doesn't implement 
all
ioctls, so I could use some help testing my test code :-)

To test you first need to apply these patches to your kernel:

https://patchwork.linuxtv.org/patch/46817/
https://patchwork.linuxtv.org/patch/46822/

Otherwise the compliance test will fail a lot.

Now run v4l2-compliance -u /dev/v4l-subdevX (or -uX as a shortcut) and see what
happens.

I have tested the following ioctls with vimc, so they are likely to be correct:

#define VIDIOC_SUBDEV_G_FMT _IOWR('V',  4, struct 
v4l2_subdev_format)
#define VIDIOC_SUBDEV_S_FMT _IOWR('V',  5, struct 
v4l2_subdev_format)
#define VIDIOC_SUBDEV_ENUM_MBUS_CODE_IOWR('V',  2, struct 
v4l2_subdev_mbus_code_enum)
#define VIDIOC_SUBDEV_ENUM_FRAME_SIZE   _IOWR('V', 74, struct 
v4l2_subdev_frame_size_enum)

All others are untested:

#define VIDIOC_SUBDEV_G_FRAME_INTERVAL  _IOWR('V', 21, struct 
v4l2_subdev_frame_interval)
#define VIDIOC_SUBDEV_S_FRAME_INTERVAL  _IOWR('V', 22, struct 
v4l2_subdev_frame_interval)
#define VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL   _IOWR('V', 75, struct 
v4l2_subdev_frame_interval_enum)
#define VIDIOC_SUBDEV_G_CROP_IOWR('V', 59, struct 
v4l2_subdev_crop)
#define VIDIOC_SUBDEV_S_CROP_IOWR('V', 60, struct 
v4l2_subdev_crop)
#define VIDIOC_SUBDEV_G_SELECTION   _IOWR('V', 61, struct 
v4l2_subdev_selection)
#define VIDIOC_SUBDEV_S_SELECTION   _IOWR('V', 62, struct 
v4l2_subdev_selection)
#define VIDIOC_SUBDEV_G_EDID_IOWR('V', 40, struct v4l2_edid)
#define VIDIOC_SUBDEV_S_EDID_IOWR('V', 41, struct v4l2_edid)
#define VIDIOC_SUBDEV_S_DV_TIMINGS  _IOWR('V', 87, struct 
v4l2_dv_timings)
#define VIDIOC_SUBDEV_G_DV_TIMINGS  _IOWR('V', 88, struct 
v4l2_dv_timings)
#define VIDIOC_SUBDEV_ENUM_DV_TIMINGS   _IOWR('V', 98, struct 
v4l2_enum_dv_timings)
#define VIDIOC_SUBDEV_QUERY_DV_TIMINGS  _IOR('V', 99, struct 
v4l2_dv_timings)
#define VIDIOC_SUBDEV_DV_TIMINGS_CAP_IOWR('V', 100, struct 
v4l2_dv_timings_cap)

I did the best I could, but there may very well be bugs in the test code.

I will also test the timings and edid ioctls myself later next week at work.

The v4l2-compliance utility can now also test media devices (-m option), 
although that's
early days yet. Eventually I want to be able to walk the graph and test each 
device in
turn.

I have this idea of making v4l2-compliance, cec-compliance and media-compliance
frontends that can all share the actual test code. And perhaps that can include 
a new
dvb-compliance as well.

However, that's future music, for now I just want to get proper ioctl test 
coverage
so driver authors can at least have some confidence in their code by running 
these
tests.

Regards,

Hans

Re: [PATCH] sh: clk: Relax clk rate match test

[Laurent Pinchart]

Hi Jacopo,

On Friday, 26 January 2018 18:24:54 EET jacopo mondi wrote:
> On Thu, Jan 25, 2018 at 03:39:32PM +0100, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> 
> [snip]
> 
>  ---
>  
>   drivers/sh/clk/core.c | 9 ++---
>   1 file changed, 6 insertions(+), 3 deletions(-)
>  
>  diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
>  index 92863e3..d2cb94c 100644
>  --- a/drivers/sh/clk/core.c
>  +++ b/drivers/sh/clk/core.c
>  @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
>   {
>  struct cpufreq_frequency_table *pos;
>  
>  -   cpufreq_for_each_valid_entry(pos, freq_table)
>  -   if (pos->frequency == rate)
>  -   return pos - freq_table;
>  +   cpufreq_for_each_valid_entry(pos, freq_table) {
>  +   if (pos->frequency > rate)
>  +   continue;
> >>> 
> >>> This assumes all frequency tables are sorted.
> >>> 
> >>> Shouldn't you pick the closest frequency?
> >>> 
> >>> However, that's what clk_rate_table_round() does, which is called from
> >>> 
> >>> sh_clk_div_round_rate(), and thus already used as .round_rate:
> >>> 
> >>> static struct sh_clk_ops sh_clk_div_enable_clk_ops = {
> >>> .recalc = sh_clk_div_recalc,
> >>> .set_rate   = sh_clk_div_set_rate,
> >>> .round_rate = sh_clk_div_round_rate,
> >>> .enable = sh_clk_div_enable,
> >>> .disable= sh_clk_div_disable,
> >>> 
> >>> };
> >> 
> >> Does this implies clock rates should be set using clk_round_rate() and
> >> not clk_set_rate() if I understand this right?
> > 
> > Not necessarily...
> > 
> > Note that both cpg_div6_clock_round_rate() and cpg_div6_clock_set_rate()
> > in the CCF implementation for DIV6 clocks use rounding.
> 
> Yeah but it doesn't seem to me that CCF implementation for DIV6 clocks does
> have to walk static tables like the old sh clock driver does. They
> perform rounding, but on the clock dividers given a requested rate
> and the respective parent clock, if I'm not wrong.

While clk_set_rate() doesn't explicitly document that the rate will be 
rounded, the clk_round_rate() documentation does:

/**
 * clk_round_rate - adjust a rate to the exact rate a clock can provide
 * @clk: clock source
 * @rate: desired clock rate in Hz
 *
 * This answers the question "if I were to pass @rate to clk_set_rate(),
 * what clock rate would I end up with?" without changing the hardware
 * in any way.  In other words:
 *
 *   rate = clk_round_rate(clk, r);
 *
 * and:
 *
 *   clk_set_rate(clk, r);
 *   rate = clk_get_rate(clk);
 *
 * are equivalent except the former does not modify the clock hardware
 * in any way.
 *
 * Returns rounded clock rate in Hz, or negative errno.
 */

So I think the SH implementation of clk_set_rate() should round rates.

(And feel free to send a patch for the clk_set_rate() documentation in 
include/linux/clk.h to state explicitly that the rate will be rounded).

> Anyway, in this case a much simpler:
> clk_set_rate(video_clk, clk_round_rate(video_clk, 1000));
> does the job for Migo-R.
> 
> I will include this in next CEU iterations, since I already have a
> small comment from you to fix there ;)

That should not be needed, but if the above code is in a board file, I can 
live with that until drivers/sh/clk/ gets fixed.

> >>> (clk_rate_table_find() is called from sh_clk_div_set_rate())
> >>> 
> >>> Or are you supposed to ask for the exact clock rate? Where does the 10
> >>> MHz come from?
> >> 
> >> From board initialization code, in order to provide a valid input
> >> clock to OV7720 sensor.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] sh: clk: Relax clk rate match test

[jacopo mondi]

Hi Geert,

On Thu, Jan 25, 2018 at 03:39:32PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
[snip]
> >> > ---
> >> >  drivers/sh/clk/core.c | 9 ++---
> >> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
> >> > index 92863e3..d2cb94c 100644
> >> > --- a/drivers/sh/clk/core.c
> >> > +++ b/drivers/sh/clk/core.c
> >> > @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
> >> >  {
> >> > struct cpufreq_frequency_table *pos;
> >> >
> >> > -   cpufreq_for_each_valid_entry(pos, freq_table)
> >> > -   if (pos->frequency == rate)
> >> > -   return pos - freq_table;
> >> > +   cpufreq_for_each_valid_entry(pos, freq_table) {
> >> > +   if (pos->frequency > rate)
> >> > +   continue;
> >>
> >> This assumes all frequency tables are sorted.
> >>
> >> Shouldn't you pick the closest frequency?
> >>
> >> However, that's what clk_rate_table_round() does, which is called from
> >> sh_clk_div_round_rate(), and thus already used as .round_rate:
> >>
> >> static struct sh_clk_ops sh_clk_div_enable_clk_ops = {
> >> .recalc = sh_clk_div_recalc,
> >> .set_rate   = sh_clk_div_set_rate,
> >> .round_rate = sh_clk_div_round_rate,
> >> .enable = sh_clk_div_enable,
> >> .disable= sh_clk_div_disable,
> >> };
> >
> > Does this implies clock rates should be set using clk_round_rate() and
> > not clk_set_rate() if I understand this right?
>
> Not necessarily...
>
> Note that both cpg_div6_clock_round_rate() and cpg_div6_clock_set_rate()
> in the CCF implementation for DIV6 clocks use rounding.
>

Yeah but it doesn't seem to me that CCF implementation for DIV6 clocks does
have to walk static tables like the old sh clock driver does. They
perform rounding, but on the clock dividers given a requested rate
and the respective parent clock, if I'm not wrong.

Anyway, in this case a much simpler:
clk_set_rate(video_clk, clk_round_rate(video_clk, 1000));
does the job for Migo-R.

I will include this in next CEU iterations, since I already have a
small comment from you to fix there ;)

Thanks
   j

> >> (clk_rate_table_find() is called from sh_clk_div_set_rate())
> >>
> >> Or are you supposed to ask for the exact clock rate? Where does the 10 MHz
> >> come from?
> >
> > From board initialization code, in order to provide a valid input
> > clock to OV7720 sensor.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCH] sh: clk: Relax clk rate match test

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Jan 25, 2018 at 3:14 PM, jacopo mondi <jac...@jmondi.org> wrote:
> On Thu, Jan 25, 2018 at 02:53:41PM +0100, Geert Uytterhoeven wrote:
>> CC linux-clk (yes I know this is about the legacy SH clock framework, but
>> the public API is/should be the same)
>>
>> On Thu, Jan 25, 2018 at 12:24 PM, Jacopo Mondi
>> <jacopo+rene...@jmondi.org> wrote:
>> > When asking for a clk rate to be set, the sh core clock matches only
>> > exact rate values against the calculated frequency table entries. If the
>> > rate does not match exactly the test fails, and the whole frequency
>> > table is walked, resulting in selection of the last entry, corresponding to
>> > the lowest available clock rate.
>>
>> IIUIC, the code does not select the last entry, but returns an error code,
>> which is propagated all the way up?
>>
>> > Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" 
>> > line),
>> > the calculated clock frequency 10088572 Hz gets ignored, and the clock is
>> > actually set to 5201920 Hz, which is the last available entry of the 
>> > frequencies
>> > table.
>>
>> Perhaps 5201920 is just the default (or old value)?
>>
>> > Relax the clock frequency match test, allowing selection of clock rates
>> > immediately slower than the required one.
>> >
>> > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
>> >
>> > ---
>> > Hello renesas lists,
>> >
>> > I'm now working on handling frame rate for the ov7720 image sensor to have 
>> > that
>> > driver accepted as part of v4l2. The sensor is installed on on Migo-R 
>> > board.
>> > In order to properly calculate pixel clock and the framerate I noticed the
>> > clock signal fed to the sensor from the SH7722 chip was always the lowest
>> > available one.
>> >
>> > This patch fixes the issues and allows me to properly select which clock
>> > frequency supply to the sensor, which according to datasheet does not 
>> > support
>> > input clock frequencies slower than 10MHz (but works anyhow).
>> >
>> > As all patches for SH architecture I wonder where they should be picked up 
>> > from,
>> > as SH seems not maintained at the moment.
>> >
>> > Thanks
>> >j
>> >
>> > ---
>> >  drivers/sh/clk/core.c | 9 ++---
>> >  1 file changed, 6 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
>> > index 92863e3..d2cb94c 100644
>> > --- a/drivers/sh/clk/core.c
>> > +++ b/drivers/sh/clk/core.c
>> > @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
>> >  {
>> > struct cpufreq_frequency_table *pos;
>> >
>> > -   cpufreq_for_each_valid_entry(pos, freq_table)
>> > -   if (pos->frequency == rate)
>> > -   return pos - freq_table;
>> > +   cpufreq_for_each_valid_entry(pos, freq_table) {
>> > +   if (pos->frequency > rate)
>> > +   continue;
>>
>> This assumes all frequency tables are sorted.
>>
>> Shouldn't you pick the closest frequency?
>>
>> However, that's what clk_rate_table_round() does, which is called from
>> sh_clk_div_round_rate(), and thus already used as .round_rate:
>>
>> static struct sh_clk_ops sh_clk_div_enable_clk_ops = {
>> .recalc = sh_clk_div_recalc,
>> .set_rate   = sh_clk_div_set_rate,
>> .round_rate = sh_clk_div_round_rate,
>> .enable = sh_clk_div_enable,
>> .disable= sh_clk_div_disable,
>> };
>
> Does this implies clock rates should be set using clk_round_rate() and
> not clk_set_rate() if I understand this right?

Not necessarily...

Note that both cpg_div6_clock_round_rate() and cpg_div6_clock_set_rate()
in the CCF implementation for DIV6 clocks use rounding.

>> (clk_rate_table_find() is called from sh_clk_div_set_rate())
>>
>> Or are you supposed to ask for the exact clock rate? Where does the 10 MHz
>> come from?
>
> From board initialization code, in order to provide a valid input
> clock to OV7720 sensor.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] sh: clk: Relax clk rate match test

[jacopo mondi]

Hi Geert,

On Thu, Jan 25, 2018 at 02:53:41PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> CC linux-clk (yes I know this is about the legacy SH clock framework, but
> the public API is/should be the same)
>
> On Thu, Jan 25, 2018 at 12:24 PM, Jacopo Mondi
> <jacopo+rene...@jmondi.org> wrote:
> > When asking for a clk rate to be set, the sh core clock matches only
> > exact rate values against the calculated frequency table entries. If the
> > rate does not match exactly the test fails, and the whole frequency
> > table is walked, resulting in selection of the last entry, corresponding to
> > the lowest available clock rate.
>
> IIUIC, the code does not select the last entry, but returns an error code,
> which is propagated all the way up?
>
> > Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" 
> > line),
> > the calculated clock frequency 10088572 Hz gets ignored, and the clock is
> > actually set to 5201920 Hz, which is the last available entry of the 
> > frequencies
> > table.
>
> Perhaps 5201920 is just the default (or old value)?
>
> > Relax the clock frequency match test, allowing selection of clock rates
> > immediately slower than the required one.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> >
> > ---
> > Hello renesas lists,
> >
> > I'm now working on handling frame rate for the ov7720 image sensor to have 
> > that
> > driver accepted as part of v4l2. The sensor is installed on on Migo-R board.
> > In order to properly calculate pixel clock and the framerate I noticed the
> > clock signal fed to the sensor from the SH7722 chip was always the lowest
> > available one.
> >
> > This patch fixes the issues and allows me to properly select which clock
> > frequency supply to the sensor, which according to datasheet does not 
> > support
> > input clock frequencies slower than 10MHz (but works anyhow).
> >
> > As all patches for SH architecture I wonder where they should be picked up 
> > from,
> > as SH seems not maintained at the moment.
> >
> > Thanks
> >j
> >
> > ---
> >  drivers/sh/clk/core.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
> > index 92863e3..d2cb94c 100644
> > --- a/drivers/sh/clk/core.c
> > +++ b/drivers/sh/clk/core.c
> > @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
> >  {
> > struct cpufreq_frequency_table *pos;
> >
> > -   cpufreq_for_each_valid_entry(pos, freq_table)
> > -   if (pos->frequency == rate)
> > -   return pos - freq_table;
> > +   cpufreq_for_each_valid_entry(pos, freq_table) {
> > +   if (pos->frequency > rate)
> > +   continue;
>
> This assumes all frequency tables are sorted.
>
> Shouldn't you pick the closest frequency?
>
> However, that's what clk_rate_table_round() does, which is called from
> sh_clk_div_round_rate(), and thus already used as .round_rate:
>
> static struct sh_clk_ops sh_clk_div_enable_clk_ops = {
> .recalc = sh_clk_div_recalc,
> .set_rate   = sh_clk_div_set_rate,
> .round_rate = sh_clk_div_round_rate,
> .enable = sh_clk_div_enable,
> .disable= sh_clk_div_disable,
> };

Does this implies clock rates should be set using clk_round_rate() and
not clk_set_rate() if I understand this right?

>
> (clk_rate_table_find() is called from sh_clk_div_set_rate())
>
> Or are you supposed to ask for the exact clock rate? Where does the 10 MHz
> come from?
>

>From board initialization code, in order to provide a valid input
clock to OV7720 sensor.

The 10MHz seems like a workaround put in place to remove some
image quality issues, according to the comment:
https://elixir.free-electrons.com/linux/v4.15-rc9/source/arch/sh/boards/mach-migor/setup.c#L311

Thanks
   j

> > +
> > +   return pos - freq_table;
> > +   }
> >
> > return -ENOENT;
> >  }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCH] sh: clk: Relax clk rate match test

[Geert Uytterhoeven]

Hi Jacopo,

CC linux-clk (yes I know this is about the legacy SH clock framework, but
the public API is/should be the same)

On Thu, Jan 25, 2018 at 12:24 PM, Jacopo Mondi
<jacopo+rene...@jmondi.org> wrote:
> When asking for a clk rate to be set, the sh core clock matches only
> exact rate values against the calculated frequency table entries. If the
> rate does not match exactly the test fails, and the whole frequency
> table is walked, resulting in selection of the last entry, corresponding to
> the lowest available clock rate.

IIUIC, the code does not select the last entry, but returns an error code,
which is propagated all the way up?

> Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" line),
> the calculated clock frequency 10088572 Hz gets ignored, and the clock is
> actually set to 5201920 Hz, which is the last available entry of the 
> frequencies
> table.

Perhaps 5201920 is just the default (or old value)?

> Relax the clock frequency match test, allowing selection of clock rates
> immediately slower than the required one.
>
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
>
> ---
> Hello renesas lists,
>
> I'm now working on handling frame rate for the ov7720 image sensor to have 
> that
> driver accepted as part of v4l2. The sensor is installed on on Migo-R board.
> In order to properly calculate pixel clock and the framerate I noticed the
> clock signal fed to the sensor from the SH7722 chip was always the lowest
> available one.
>
> This patch fixes the issues and allows me to properly select which clock
> frequency supply to the sensor, which according to datasheet does not support
> input clock frequencies slower than 10MHz (but works anyhow).
>
> As all patches for SH architecture I wonder where they should be picked up 
> from,
> as SH seems not maintained at the moment.
>
> Thanks
>j
>
> ---
>  drivers/sh/clk/core.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
> index 92863e3..d2cb94c 100644
> --- a/drivers/sh/clk/core.c
> +++ b/drivers/sh/clk/core.c
> @@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
>  {
> struct cpufreq_frequency_table *pos;
>
> -   cpufreq_for_each_valid_entry(pos, freq_table)
> -   if (pos->frequency == rate)
> -   return pos - freq_table;
> +   cpufreq_for_each_valid_entry(pos, freq_table) {
> +   if (pos->frequency > rate)
> +   continue;

This assumes all frequency tables are sorted.

Shouldn't you pick the closest frequency?

However, that's what clk_rate_table_round() does, which is called from
sh_clk_div_round_rate(), and thus already used as .round_rate:

static struct sh_clk_ops sh_clk_div_enable_clk_ops = {
.recalc = sh_clk_div_recalc,
.set_rate   = sh_clk_div_set_rate,
.round_rate = sh_clk_div_round_rate,
.enable = sh_clk_div_enable,
.disable= sh_clk_div_disable,
};

(clk_rate_table_find() is called from sh_clk_div_set_rate())

Or are you supposed to ask for the exact clock rate? Where does the 10 MHz
come from?

> +
> +   return pos - freq_table;
> +   }
>
> return -ENOENT;
>  }

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] sh: clk: Relax clk rate match test

[Jacopo Mondi]

When asking for a clk rate to be set, the sh core clock matches only
exact rate values against the calculated frequency table entries. If the
rate does not match exactly the test fails, and the whole frequency
table is walked, resulting in selection of the last entry, corresponding to
the lowest available clock rate.

Ie. when asking for a 10MHz clock rate on div6 clocks (ie. "video_clk" line),
the calculated clock frequency 10088572 Hz gets ignored, and the clock is
actually set to 5201920 Hz, which is the last available entry of the frequencies
table.

Relax the clock frequency match test, allowing selection of clock rates
immediately slower than the required one.

Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>

---
Hello renesas lists,

I'm now working on handling frame rate for the ov7720 image sensor to have that
driver accepted as part of v4l2. The sensor is installed on on Migo-R board.
In order to properly calculate pixel clock and the framerate I noticed the
clock signal fed to the sensor from the SH7722 chip was always the lowest
available one.

This patch fixes the issues and allows me to properly select which clock
frequency supply to the sensor, which according to datasheet does not support
input clock frequencies slower than 10MHz (but works anyhow).

As all patches for SH architecture I wonder where they should be picked up from,
as SH seems not maintained at the moment.

Thanks
   j

---
 drivers/sh/clk/core.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
index 92863e3..d2cb94c 100644
--- a/drivers/sh/clk/core.c
+++ b/drivers/sh/clk/core.c
@@ -198,9 +198,12 @@ int clk_rate_table_find(struct clk *clk,
 {
struct cpufreq_frequency_table *pos;

-   cpufreq_for_each_valid_entry(pos, freq_table)
-   if (pos->frequency == rate)
-   return pos - freq_table;
+   cpufreq_for_each_valid_entry(pos, freq_table) {
+   if (pos->frequency > rate)
+   continue;
+
+   return pos - freq_table;
+   }

return -ENOENT;
 }
--
2.7.4

Re: [patch] libv4l2: SDL test application

[Pavel Machek]

On Mon 2017-10-30 17:30:53, Hans Verkuil wrote:
> Hi Pavel,
> 
> On 10/28/2017 09:57 PM, Pavel Machek wrote:
> > Add support for simple SDL test application. Allows taking jpeg
> > snapshots, and is meant to run on phone with touchscreen. Not
> > particulary useful on PC with webcam, but should work.
> 
> When I try to build this I get:
> 
> make[3]: Entering directory '/home/hans/work/src/v4l/v4l-utils/contrib/test'
>   CCLD sdlcam
> /usr/bin/ld: sdlcam-sdlcam.o: undefined reference to symbol 
> 'log2@@GLIBC_2.2.5'
> //lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from 
> command line
> collect2: error: ld returned 1 exit status
> Makefile:561: recipe for target 'sdlcam' failed
> make[3]: *** [sdlcam] Error 1
> make[3]: Leaving directory '/home/hans/work/src/v4l/v4l-utils/contrib/test'
> Makefile:475: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory '/home/hans/work/src/v4l/v4l-utils/contrib'
> Makefile:589: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/hans/work/src/v4l/v4l-utils'
> Makefile:516: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> I had to add -lm -ldl -lrt to sdlcam_LDFLAGS. Is that correct?

Yes, that should be correct. I had that problem, too, but I thought I
solved it with simpler configure.ac.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [patch] libv4l2: SDL test application

[Hans Verkuil]

On 10/30/2017 05:41 PM, Pali Rohár wrote:
> On Monday 30 October 2017 17:30:53 Hans Verkuil wrote:
>> Hi Pavel,
>>
>> On 10/28/2017 09:57 PM, Pavel Machek wrote:
>>> Add support for simple SDL test application. Allows taking jpeg
>>> snapshots, and is meant to run on phone with touchscreen. Not
>>> particulary useful on PC with webcam, but should work.
>>
>> When I try to build this I get:
>>
>> make[3]: Entering directory '/home/hans/work/src/v4l/v4l-utils/contrib/test'
>>   CCLD sdlcam
>> /usr/bin/ld: sdlcam-sdlcam.o: undefined reference to symbol 
>> 'log2@@GLIBC_2.2.5'
>> //lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from 
>> command line
>> collect2: error: ld returned 1 exit status
>> Makefile:561: recipe for target 'sdlcam' failed
>> make[3]: *** [sdlcam] Error 1
>> make[3]: Leaving directory '/home/hans/work/src/v4l/v4l-utils/contrib/test'
>> Makefile:475: recipe for target 'all-recursive' failed
>> make[2]: *** [all-recursive] Error 1
>> make[2]: Leaving directory '/home/hans/work/src/v4l/v4l-utils/contrib'
>> Makefile:589: recipe for target 'all-recursive' failed
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory '/home/hans/work/src/v4l/v4l-utils'
>> Makefile:516: recipe for target 'all' failed
>> make: *** [all] Error 2
>>
>> I had to add -lm -ldl -lrt to sdlcam_LDFLAGS. Is that correct?
> 
> Is not for <> needed
> just -lm? log2 should be in mathematical library.
> 

Sorry, I was unclear: after adding -lm I got an unresolved for dl_open, after
adding -ldl I got an unresolved on shm_open.

Only after using all three did it compile.

Regards,

Hans

Re: [patch] libv4l2: SDL test application

[Pali Rohár]

On Monday 30 October 2017 17:30:53 Hans Verkuil wrote:
> Hi Pavel,
> 
> On 10/28/2017 09:57 PM, Pavel Machek wrote:
> > Add support for simple SDL test application. Allows taking jpeg
> > snapshots, and is meant to run on phone with touchscreen. Not
> > particulary useful on PC with webcam, but should work.
> 
> When I try to build this I get:
> 
> make[3]: Entering directory '/home/hans/work/src/v4l/v4l-utils/contrib/test'
>   CCLD sdlcam
> /usr/bin/ld: sdlcam-sdlcam.o: undefined reference to symbol 
> 'log2@@GLIBC_2.2.5'
> //lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from 
> command line
> collect2: error: ld returned 1 exit status
> Makefile:561: recipe for target 'sdlcam' failed
> make[3]: *** [sdlcam] Error 1
> make[3]: Leaving directory '/home/hans/work/src/v4l/v4l-utils/contrib/test'
> Makefile:475: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory '/home/hans/work/src/v4l/v4l-utils/contrib'
> Makefile:589: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/hans/work/src/v4l/v4l-utils'
> Makefile:516: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> I had to add -lm -ldl -lrt to sdlcam_LDFLAGS. Is that correct?

Is not for <> needed
just -lm? log2 should be in mathematical library.

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [patch] libv4l2: SDL test application

[Hans Verkuil]

Hi Pavel,

On 10/28/2017 09:57 PM, Pavel Machek wrote:
> Add support for simple SDL test application. Allows taking jpeg
> snapshots, and is meant to run on phone with touchscreen. Not
> particulary useful on PC with webcam, but should work.

When I try to build this I get:

make[3]: Entering directory '/home/hans/work/src/v4l/v4l-utils/contrib/test'
  CCLD sdlcam
/usr/bin/ld: sdlcam-sdlcam.o: undefined reference to symbol 'log2@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status
Makefile:561: recipe for target 'sdlcam' failed
make[3]: *** [sdlcam] Error 1
make[3]: Leaving directory '/home/hans/work/src/v4l/v4l-utils/contrib/test'
Makefile:475: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/hans/work/src/v4l/v4l-utils/contrib'
Makefile:589: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/hans/work/src/v4l/v4l-utils'
Makefile:516: recipe for target 'all' failed
make: *** [all] Error 2

I had to add -lm -ldl -lrt to sdlcam_LDFLAGS. Is that correct?

Regards,

Hans

> 
> Signed-off-by: Pavel Machek <pa...@ucw.cz>
> 
> diff --git a/configure.ac b/configure.ac
> index f3691be..f6540c2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -439,6 +439,9 @@ AC_ARG_ENABLE(gconv,
> esac]
>  )
>  
> +PKG_CHECK_MODULES([SDL2], [sdl2 SDL2_image], [sdl_pc=yes], [sdl_pc=no])
> +AM_CONDITIONAL([HAVE_SDL], [test x$sdl_pc = xyes])
> +
>  # Check if backtrace functions are defined
>  AC_SEARCH_LIBS([backtrace], [execinfo], [
>AC_DEFINE(HAVE_BACKTRACE, [1], [glibc has functions to provide stack 
> backtrace])
> @@ -507,6 +510,7 @@ compile time options summary
>  pthread: $have_pthread
>  QT version : $QT_VERSION
>  ALSA support   : $USE_ALSA
> +SDL support : $sdl_pc
>  
>  build dynamic libs : $enable_shared
>  build static libs  : $enable_static
> diff --git a/contrib/test/Makefile.am b/contrib/test/Makefile.am
> index 4641e21..0f97ce2 100644
> --- a/contrib/test/Makefile.am
> +++ b/contrib/test/Makefile.am
> @@ -16,6 +16,10 @@ if HAVE_GLU
>  noinst_PROGRAMS += v4l2gl
>  endif
>  
> +if HAVE_SDL
> +noinst_PROGRAMS += sdlcam
> +endif
> +
>  driver_test_SOURCES = driver-test.c
>  driver_test_LDADD = ../../utils/libv4l2util/libv4l2util.la
>  
> @@ -31,6 +35,10 @@ v4l2gl_SOURCES = v4l2gl.c
>  v4l2gl_LDFLAGS = $(X11_LIBS) $(GL_LIBS) $(GLU_LIBS) $(ARGP_LIBS)
>  v4l2gl_LDADD = ../../lib/libv4l2/libv4l2.la 
> ../../lib/libv4lconvert/libv4lconvert.la
>  
> +sdlcam_LDFLAGS = $(JPEG_LIBS) $(SDL2_LIBS)
> +sdlcam_CFLAGS = -I../.. $(SDL2_CFLAGS)
> +sdlcam_LDADD = ../../lib/libv4l2/.libs/libv4l2.a  
> ../../lib/libv4lconvert/.libs/libv4lconvert.a
> +
>  mc_nextgen_test_CFLAGS = $(LIBUDEV_CFLAGS)
>  mc_nextgen_test_LDFLAGS = $(LIBUDEV_LIBS)
>  
> diff --git a/contrib/test/sdlcam.c b/contrib/test/sdlcam.c
> new file mode 100644
> index 000..cc43a10
> --- /dev/null
> +++ b/contrib/test/sdlcam.c
> @@ -0,0 +1,1250 @@
> +/*
> +   Digital still camera.
> +
> +   SDL based, suitable for camera phone such as Nokia N900. In
> +   particular, we support focus, gain and exposure control, but not
> +   aperture control or lens zoom.
> +
> +   Copyright 2017 Pavel Machek, LGPL
> +
> +   Needs sdl2, sdl2_image libraries. sudo aptitude install libsdl2-dev
> +   libsdl2-image-dev on Debian systems.
> +*/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "libv4l2.h"
> +#include 
> +#include "libv4l-plugin.h"
> +
> +#include 
> +#include 
> +
> +#define PICDIR "."
> +#define SX 2592
> +#define SY 1968
> +#define SIZE SX*SY*3
> +
> +static void fmt_print(struct v4l2_format *fmt)
> +{
> + int f;
> + printf("Format: %dx%d. ", fmt->fmt.pix.width, fmt->fmt.pix.height);
> + printf("%x ", fmt->fmt.pix.pixelformat);
> + f = fmt->fmt.pix.pixelformat;
> + for (int i=0; i<4; i++) {
> + printf("%c", f & 0xff);
> + f >>= 8;
> + }
> + printf("\n");
> +}
> +
> +static double dtime(void)
> +{
> + static double start = 0.0;
> + struct timeval now;
> +
> + gettimeofday(, NULL);
> +
> + double n = now.tv_sec + n

[patch] libv4l2: SDL test application

[Pavel Machek]

Add support for simple SDL test application. Allows taking jpeg
snapshots, and is meant to run on phone with touchscreen. Not
particulary useful on PC with webcam, but should work.

Signed-off-by: Pavel Machek <pa...@ucw.cz>

diff --git a/configure.ac b/configure.ac
index f3691be..f6540c2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -439,6 +439,9 @@ AC_ARG_ENABLE(gconv,
esac]
 )
 
+PKG_CHECK_MODULES([SDL2], [sdl2 SDL2_image], [sdl_pc=yes], [sdl_pc=no])
+AM_CONDITIONAL([HAVE_SDL], [test x$sdl_pc = xyes])
+
 # Check if backtrace functions are defined
 AC_SEARCH_LIBS([backtrace], [execinfo], [
   AC_DEFINE(HAVE_BACKTRACE, [1], [glibc has functions to provide stack 
backtrace])
@@ -507,6 +510,7 @@ compile time options summary
 pthread: $have_pthread
 QT version : $QT_VERSION
 ALSA support   : $USE_ALSA
+SDL support   : $sdl_pc
 
 build dynamic libs : $enable_shared
 build static libs  : $enable_static
diff --git a/contrib/test/Makefile.am b/contrib/test/Makefile.am
index 4641e21..0f97ce2 100644
--- a/contrib/test/Makefile.am
+++ b/contrib/test/Makefile.am
@@ -16,6 +16,10 @@ if HAVE_GLU
 noinst_PROGRAMS += v4l2gl
 endif
 
+if HAVE_SDL
+noinst_PROGRAMS += sdlcam
+endif
+
 driver_test_SOURCES = driver-test.c
 driver_test_LDADD = ../../utils/libv4l2util/libv4l2util.la
 
@@ -31,6 +35,10 @@ v4l2gl_SOURCES = v4l2gl.c
 v4l2gl_LDFLAGS = $(X11_LIBS) $(GL_LIBS) $(GLU_LIBS) $(ARGP_LIBS)
 v4l2gl_LDADD = ../../lib/libv4l2/libv4l2.la 
../../lib/libv4lconvert/libv4lconvert.la
 
+sdlcam_LDFLAGS = $(JPEG_LIBS) $(SDL2_LIBS)
+sdlcam_CFLAGS = -I../.. $(SDL2_CFLAGS)
+sdlcam_LDADD = ../../lib/libv4l2/.libs/libv4l2.a  
../../lib/libv4lconvert/.libs/libv4lconvert.a
+
 mc_nextgen_test_CFLAGS = $(LIBUDEV_CFLAGS)
 mc_nextgen_test_LDFLAGS = $(LIBUDEV_LIBS)
 
diff --git a/contrib/test/sdlcam.c b/contrib/test/sdlcam.c
new file mode 100644
index 000..cc43a10
--- /dev/null
+++ b/contrib/test/sdlcam.c
@@ -0,0 +1,1250 @@
+/*
+   Digital still camera.
+
+   SDL based, suitable for camera phone such as Nokia N900. In
+   particular, we support focus, gain and exposure control, but not
+   aperture control or lens zoom.
+
+   Copyright 2017 Pavel Machek, LGPL
+
+   Needs sdl2, sdl2_image libraries. sudo aptitude install libsdl2-dev
+   libsdl2-image-dev on Debian systems.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "libv4l2.h"
+#include 
+#include "libv4l-plugin.h"
+
+#include 
+#include 
+
+#define PICDIR "."
+#define SX 2592
+#define SY 1968
+#define SIZE SX*SY*3
+
+static void fmt_print(struct v4l2_format *fmt)
+{
+   int f;
+   printf("Format: %dx%d. ", fmt->fmt.pix.width, fmt->fmt.pix.height);
+   printf("%x ", fmt->fmt.pix.pixelformat);
+   f = fmt->fmt.pix.pixelformat;
+   for (int i=0; i<4; i++) {
+   printf("%c", f & 0xff);
+   f >>= 8;
+   }
+   printf("\n");
+}
+
+static double dtime(void)
+{
+   static double start = 0.0;
+   struct timeval now;
+
+   gettimeofday(, NULL);
+
+   double n = now.tv_sec + now.tv_usec / 100.;
+   if (!start)
+   start = n;
+   return n - start;
+}
+
+static long v4l2_g_ctrl(int fd, long id)
+{
+   int res;
+   struct v4l2_control ctrl;
+   ctrl.id = id;
+   ctrl.value = 0;
+   res = v4l2_ioctl(fd, VIDIOC_G_CTRL, );
+   if (res < 0)
+   printf("Get control %lx failed\n", id);
+   return ctrl.value;
+}
+
+static int v4l2_s_ctrl(int fd, long id, long value)
+{
+   int res;
+   struct v4l2_control ctrl;
+   ctrl.id = id;
+   ctrl.value = value;
+   res = v4l2_ioctl(fd, VIDIOC_S_CTRL, );
+   if (res < 0)
+   printf("Set control %lx %ld failed\n", id, value);
+   return res;
+}
+
+static int v4l2_set_focus(int fd, int diopt)
+{
+   if (v4l2_s_ctrl(fd, V4L2_CID_FOCUS_ABSOLUTE, diopt) < 0) {
+   printf("Could not set focus\n");
+   }
+   return 0;
+}
+
+struct dev_info {
+   int fd;
+   struct v4l2_format fmt;
+
+   unsigned char buf[SIZE];
+   int debug;
+#define D_TIMING 1
+};
+
+struct sdl {
+   SDL_Window *window;
+   SDL_Surface *screen, *liveview;
+
+   int wx, wy; /* Window size */
+   int sx, sy; /* Live view size */
+   int bx, by; /* Border size */
+   int nx, ny; /* Number of buttons */
+   float factor;
+
+   /* These should go separately */
+   int do_focus, do_exposure, do_flash, do_white, do_big, do_full;
+   double zoom;
+   double focus_min;
+
+   int slider_mode;
+#define M_BIAS 0
+#define M_EXPOSURE 1
+#define M_GAIN 2
+#define M

[PATCH 5/5] keytable: show lirc device and make test show lirc scancodes

[Sean Young]

case RC_PROTO_RC6_6A_32: p = "rc6_6a_32"; break;
+   case RC_PROTO_RC6_MCE: p = "rc6_mce"; break;
+   case RC_PROTO_SHARP: p = "sharp"; break;
+   case RC_PROTO_XMP: p = "xmp"; break;
+   case RC_PROTO_CEC: p = "cec"; break;
+   default: p = NULL; break;
+   }
+   printf(_("%llu.%06llu: "),
+   scancodes[i].timestamp / 10ull,
+   (scancodes[i].timestamp % 10ull) / 1000ull);
+
+   if (p)
+   printf(_("lirc protocol(%s): scancode = 0x%llx"),
+   p, scancodes[i].scancode);
+   else
+   printf(_("lirc protocol(%d): scancode = 0x%llx"),
+   scancodes[i].rc_proto, scancodes[i].scancode);
+
+   if (scancodes[i].flags & LIRC_SCANCODE_FLAG_REPEAT)
+   printf(_(" repeat"));
+   if (scancodes[i].flags & LIRC_SCANCODE_FLAG_TOGGLE)
+   printf(_(" toggle=1"));
+
+   printf("\n");
+   }
+}
+
+static void test_event(struct rc_device *rc_dev, int fd)
 {
struct input_event ev[64];
-   int rd, i;
+   struct lirc_scancode sc[64];
+   int rd, i, lircfd = -1;
+
+   if (rc_dev->lirc_name) {
+   lircfd = open(rc_dev->lirc_name, O_RDONLY | O_NONBLOCK);
+   if (lircfd == -1) {
+   perror(_("Can't open lirc device"));
+   return;
+   }
+   unsigned features;
+   if (ioctl(lircfd, LIRC_GET_FEATURES, )) {
+   perror(_("Can't get lirc features"));
+   return;
+   }
+
+   if (!(features & LIRC_CAN_REC_SCANCODE)) {
+   close(lircfd);
+   lircfd = -1;
+   }
+   else {
+   unsigned mode = LIRC_MODE_SCANCODE;
+   if (ioctl(lircfd, LIRC_SET_REC_MODE, )) {
+   perror(_("Can't set lirc mode"));
+   return;
+   }
+
+   mode = CLOCK_MONOTONIC;
+   ioctl(fd, EVIOCSCLOCKID, );
+   }
+   }
+
 
printf (_("Testing events. Please, press CTRL-C to abort.\n"));
while (1) {
+   struct pollfd pollstruct[2] = {
+   { .fd = fd, .events = POLLIN },
+   { .fd = lircfd, .events = POLLIN },
+   };
+
+   poll(pollstruct, lircfd != -1 ? 2 : 1, -1);
+
+   if (lircfd != -1) {
+   rd = read(lircfd, sc, sizeof(sc));
+
+   if (rd != -1) {
+   print_scancodes(sc, rd / sizeof(struct 
lirc_scancode));
+   } else if (errno != EAGAIN) {
+   perror(_("Error reading lirc scancode"));
+   return;
+   }
+   }
+
rd = read(fd, ev, sizeof(ev));
 
if (rd < (int) sizeof(struct input_event)) {
+   if (errno == EAGAIN)
+   continue;
+
perror(_("Error reading event"));
return;
}
@@ -1455,6 +1580,9 @@ static int show_sysfs_attribs(struct rc_device *rc_dev, 
char *name)
fprintf(stderr, _("\tDriver %s, table %s\n"),
rc_dev->drv_name,
rc_dev->keytable_name);
+   if (rc_dev->lirc_name)
+   fprintf(stderr, _("\tLirc device: %s\n"),
+   rc_dev->lirc_name);
fprintf(stderr, _("\tSupported protocols: "));
write_sysfs_protocols(rc_dev->supported, stderr, "%s ");
fprintf(stderr, "\n\t");
@@ -1585,7 +1713,7 @@ int main(int argc, char *argv[])
 
if (debug)
fprintf(stderr, _("Opening %s\n"), devicename);
-   fd = open(devicename, O_RDONLY);
+   fd = open(devicename, O_RDONLY | O_NONBLOCK);
if (fd < 0) {
perror(devicename);
return -1;
@@ -1644,7 +1772,7 @@ int main(int argc, char *argv[])
}
 
if (test)
-   test_event(fd);
+   test_event(_dev, fd);
 
return 0;
 }
-- 
2.13.5

[PATCH 3/4] venus: fix compile-test build on non-qcom ARM platform

[Stanimir Varbanov]

From: Arnd Bergmann <a...@arndb.de>

If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into
a build error:

ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko] 
undefined!
ERROR: "qcom_mdt_get_size" [drivers/media/platform/qcom/venus/venus-core.ko] 
undefined!

This changes the 'select' statement again, so we only try to enable
those symbols when the drivers will actually get built, and explicitly
test for QCOM_MDT_LOADER to be enabled before calling into it.

Fixes: 76724b30f222 ("[media] media: venus: enable building with COMPILE_TEST")
Signed-off-by: Arnd Bergmann <a...@arndb.de>
Reviewed-by: Stanimir Varbanov <stanimir.varba...@linaro.org>
---
 drivers/media/platform/Kconfig   | 4 ++--
 drivers/media/platform/qcom/venus/firmware.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 1313cd533436..fb1fa0b82077 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -475,8 +475,8 @@ config VIDEO_QCOM_VENUS
tristate "Qualcomm Venus V4L2 encoder/decoder driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
-   select QCOM_MDT_LOADER if (ARM || ARM64)
-   select QCOM_SCM if (ARM || ARM64)
+   select QCOM_MDT_LOADER if ARCH_QCOM
+   select QCOM_SCM if ARCH_QCOM
select VIDEOBUF2_DMA_SG
select V4L2_MEM2MEM_DEV
---help---
diff --git a/drivers/media/platform/qcom/venus/firmware.c 
b/drivers/media/platform/qcom/venus/firmware.c
index d6d9560c1c19..521d4b36c090 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -38,7 +38,7 @@ int venus_boot(struct device *dev, const char *fwname)
void *mem_va;
int ret;
 
-   if (!qcom_scm_is_available())
+   if (!IS_ENABLED(CONFIG_QCOM_MDT_LOADER) || !qcom_scm_is_available())
return -EPROBE_DEFER;
 
node = of_parse_phandle(dev->of_node, "memory-region", 0);
-- 
2.11.0

[PATCH v2] [media] venus: fix compile-test build on non-qcom ARM platform

[Arnd Bergmann]

If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into
a build error:

ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko] 
undefined!
ERROR: "qcom_mdt_get_size" [drivers/media/platform/qcom/venus/venus-core.ko] 
undefined!

This changes the 'select' statement again, so we only try to enable
those symbols when the drivers will actually get built, and explicitly
test for QCOM_MDT_LOADER to be enabled before calling into it.

Fixes: 76724b30f222 ("[media] media: venus: enable building with COMPILE_TEST")
Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
v2: add required IS_ENABLED() check
---
 drivers/media/platform/Kconfig   | 4 ++--
 drivers/media/platform/qcom/venus/firmware.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 1313cd533436..fb1fa0b82077 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -475,8 +475,8 @@ config VIDEO_QCOM_VENUS
tristate "Qualcomm Venus V4L2 encoder/decoder driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
-   select QCOM_MDT_LOADER if (ARM || ARM64)
-   select QCOM_SCM if (ARM || ARM64)
+   select QCOM_MDT_LOADER if ARCH_QCOM
+   select QCOM_SCM if ARCH_QCOM
select VIDEOBUF2_DMA_SG
select V4L2_MEM2MEM_DEV
---help---
diff --git a/drivers/media/platform/qcom/venus/firmware.c 
b/drivers/media/platform/qcom/venus/firmware.c
index 76edb9f60311..3794b9e3250b 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -40,7 +40,7 @@ int venus_boot(struct device *parent, struct device *fw_dev, 
const char *fwname)
void *mem_va;
int ret;
 
-   if (!qcom_scm_is_available())
+   if (!IS_ENABLED(CONFIG_QCOM_MDT_LOADER) || !qcom_scm_is_available())
return -EPROBE_DEFER;
 
fw_dev->parent = parent;
-- 
2.9.0

Re: [PATCH 3/3] [media] venus: fix compile-test build on non-qcom ARM platform

[Arnd Bergmann]

On Tue, Jun 27, 2017 at 9:45 PM, Stanimir Varbanov
<stanimir.varba...@linaro.org> wrote:
> Hi Arnd,
>
> On 27.06.2017 18:02, Arnd Bergmann wrote:
>>
>> If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into
>> a build error:
>>
>> ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko]
>> undefined!
>> ERROR: "qcom_mdt_get_size"
>> [drivers/media/platform/qcom/venus/venus-core.ko] undefined!
>
>
> Ahh, thanks for the fix, these two will also pursuing me in my dreams.

I just came after me as well, as I hit another corner case, we need this
fixup on top, I'll send a replacement:

Subject: [PATCH] fixup! [media] venus: fix compile-test  build on
non-qcom ARM platform

Signed-off-by: Arnd Bergmann <a...@arndb.de>

diff --git a/drivers/media/platform/qcom/venus/firmware.c
b/drivers/media/platform/qcom/venus/firmware.c
index 76edb9f60311..3794b9e3250b 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -40,7 +40,7 @@ int venus_boot(struct device *parent, struct device
*fw_dev, const char *fwname)
  void *mem_va;
  int ret;

- if (!qcom_scm_is_available())
+ if (!IS_ENABLED(CONFIG_QCOM_MDT_LOADER) || !qcom_scm_is_available())
  return -EPROBE_DEFER;

  fw_dev->parent = parent;

Re: [PATCH 3/3] [media] venus: fix compile-test build on non-qcom ARM platform

[Stanimir Varbanov]

Hi Arnd,

On 27.06.2017 18:02, Arnd Bergmann wrote:

If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into
a build error:

ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko] 
undefined!
ERROR: "qcom_mdt_get_size" [drivers/media/platform/qcom/venus/venus-core.ko] 
undefined!


Ahh, thanks for the fix, these two will also pursuing me in my dreams.



This changes the 'select' statement again, so we only try to enable
those symbols when the drivers will actually get built.

Fixes: 76724b30f222 ("[media] media: venus: enable building with COMPILE_TEST")
Signed-off-by: Arnd Bergmann 


Reviewed-by: Stanimir Varbanov 


---
  drivers/media/platform/Kconfig | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index cb2f31cd0088..635c53e61f8a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -475,8 +475,8 @@ config VIDEO_QCOM_VENUS
tristate "Qualcomm Venus V4L2 encoder/decoder driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
-   select QCOM_MDT_LOADER if (ARM || ARM64)
-   select QCOM_SCM if (ARM || ARM64)
+   select QCOM_MDT_LOADER if ARCH_QCOM
+   select QCOM_SCM if ARCH_QCOM
select VIDEOBUF2_DMA_SG
select V4L2_MEM2MEM_DEV
---help---



regards,
Stan

[PATCH 3/3] [media] venus: fix compile-test build on non-qcom ARM platform

[Arnd Bergmann]

If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into
a build error:

ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko] 
undefined!
ERROR: "qcom_mdt_get_size" [drivers/media/platform/qcom/venus/venus-core.ko] 
undefined!

This changes the 'select' statement again, so we only try to enable
those symbols when the drivers will actually get built.

Fixes: 76724b30f222 ("[media] media: venus: enable building with COMPILE_TEST")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/platform/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index cb2f31cd0088..635c53e61f8a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -475,8 +475,8 @@ config VIDEO_QCOM_VENUS
tristate "Qualcomm Venus V4L2 encoder/decoder driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
-   select QCOM_MDT_LOADER if (ARM || ARM64)
-   select QCOM_SCM if (ARM || ARM64)
+   select QCOM_MDT_LOADER if ARCH_QCOM
+   select QCOM_SCM if ARCH_QCOM
select VIDEOBUF2_DMA_SG
select V4L2_MEM2MEM_DEV
---help---
-- 
2.9.0

Re: [[media] rc] e662671619: BUG: kernel hang in test stage

[Sean Young]

On Mon, May 08, 2017 at 08:13:37PM +0800, kernel test robot wrote:
> Greetings,
> 
> 0day kernel testing robot got the below dmesg and the first bad commit is
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> 
> commit e66267161971155a8b4756b4e17f2f2f82b9f842
> Author: Sean Young <s...@mess.org>
> AuthorDate: Tue Mar 7 17:07:59 2017 -0300
> Commit: Mauro Carvalho Chehab <mche...@s-opensource.com>
> CommitDate: Wed Apr 5 14:50:57 2017 -0300
> 
> [media] rc: promote lirc_sir out of staging
> 
> Rename lirc_sir to sir_ir in the process.
> 
> Signed-off-by: Sean Young <s...@mess.org>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Here the sir_ir gets in an infinite loop in its interrupt handler, since the
hardware is different from what it expects.

I was looking in all the wrong places so it took too long to find this. :/

I'll send a patch as a reply to this email.

Thanks,

Sean

Re: [PATCH 2/4] [media] pxa_camera: Fix incorrect test in the image size generation

[Petr Cvek]

Dne 2.5.2017 v 16:43 Robert Jarzmik napsal(a):
> Petr Cvek <petr.c...@tul.cz> writes:
> 
>> During the transfer from the soc_camera a test in pxa_mbus_image_size()
>> got removed. Without it any PXA_MBUS_LAYOUT_PACKED format causes either
>> the return of a wrong value (PXA_MBUS_PACKING_2X8_PADHI doubles
>> the correct value) or EINVAL (PXA_MBUS_PACKING_NONE and
>> PXA_MBUS_PACKING_EXTEND16). This was observed in an error from the ffmpeg
>> (for some of the YUYV subvariants).
>>
>> This patch re-adds the same test as in soc_camera version.
>>
>> Signed-off-by: Petr Cvek <petr.c...@tul.cz>
> Did you test that with YUV422P format ?
> If yes, then you can have my ack.
> 

I was trying to add RGB888 and then I've noticed that "YVYU 16bit" formats (and 
permutation) and "Bayer 12" formats have incorrect values in the 
bits_per_sample field. I didn't notice it in the patch creation, because it 
doesn't affect the computations of the image size. And later in the code it 
just defaults to 8.

A comment for a switch in the pxa_camera_setup_cicr() function:

"Datawidth is now guaranteed to be equal to one of the three values..."

Values are 10, 9 and 8 and they describe a bit-vector length of the interface 
for a sensor.

So I will include a fix for the patchset v2 for this. I will test the YUYV 
formats, but my sensor does not support the Bayer 12 formats. 

In the addition I propose a patch for an enum type (or define) of the interface 
configuration field. Something like:
#define PXA_MBUS_BUSWIDTH_8 8
#define PXA_MBUS_BUSWIDTH_9 9
#define PXA_MBUS_BUSWIDTH_1010
and a patch for something like:
s/bits_per_sample/buswidth/g
and a formatting patch for excessive tabulators in the mbus_fmt structure 
initialization ;-).

Petr