Re: [PATCH v2] [RFC v2] v4l2: add support for colorspace conversion for video capture

[Mauro Carvalho Chehab]

Em Thu, 6 Sep 2018 11:02:28 +0200
Hans Verkuil  escreveu:

> Hi Philipp,
> 
> It is much appreciated that this old RFC of mine is picked up again.
> I always wanted to get this in, but I never had a driver where it would
> make sense to do so.

What's the status of this?

Hans,
As this is an old RFC from you, I'll delegate it to you at patchwork,
for you to track it.

Regards,
Mauro

> 
> On 09/05/2018 07:09 PM, Philipp Zabel wrote:
> > For video capture it is the driver that reports the colorspace,  
> 
> add: "transfer function,"
> 
> > Y'CbCr/HSV encoding and quantization range used by the video, and there
> > is no way to request something different, even though many HDTV
> > receivers have some sort of colorspace conversion capabilities.
> > 
> > For output video this feature already exists since the application
> > specifies this information for the video format it will send out, and
> > the transmitter will enable any available CSC if a format conversion has
> > to be performed in order to match the capabilities of the sink.
> > 
> > For video capture we propose adding new pix_format flags:
> > V4L2_PIX_FMT_FLAG_CSC_COLORSPACE, V4L2_PIX_FMT_FLAG_CSC_YCBCR_ENC,
> > V4L2_PIX_FMT_FLAG_CSC_HSV_ENC, V4L2_PIX_FMT_FLAG_CSC_QUANTIZATION, and
> > V4L2_PIX_FMT_FLAG_CSC_XFER_FUNC. These are set by the driver to indicate
> > its conversion features. When set by the application, the driver will
> > interpret the colorspace, ycbcr_enc/hsv_enc, quantization and xfer_func
> > fields as the requested colorspace information and will attempt to do
> > the conversion it supports.
> > 
> > Drivers do not have to actually look at the flags: if the flags are not
> > set, then the colorspace, ycbcr_enc and quantization fields are set to
> > the default values by the core, i.e. just pass on the received format
> > without conversion.  
> 
> Thinking about this some more, I don't think this is quite the right approach.
> Having userspace set these flags with S_FMT if they want to do explicit
> conversions makes sense, and that part we can keep.
> 
> But to signal the capabilities I think should be done via new flags for
> VIDIOC_ENUM_FMT. Basically the same set of flags, but for the flags field
> of struct v4l2_fmtdesc.
> 
> One thing that's not clear to me is what happens if userspace sets one or
> more flags and calls S_FMT for a driver that doesn't support this. Are the
> flags zeroed in that case upon return? I don't think so, but I think that
> is already true for the existing flag V4L2_PIX_FMT_FLAG_PREMUL_ALPHA.
> 
> I wonder if V4L2_PIX_FMT_FLAG_PREMUL_ALPHA should also get an equivalent
> flag for v4l2_fmtdesc.
> 
> Then we can just document that v4l2_format flags are only valid if they
> are also defined in v4l2_fmtdesc.
> 
> Does anyone have better ideas for this?
> 
> Regards,
> 
>   Hans
> 
> > 
> > Signed-off-by: Hans Verkuil 
> > Signed-off-by: Philipp Zabel 
> > ---
> > Changes since v1 [1]
> >  - convert to rst
> >  - split V4L2_PIX_FMT_FLAG_REQUEST_CSC into four separate flags for
> >colorspace, ycbcr_enc/hsv_enc, quantization, and xfer_func
> >  - let driver set flags to indicate supported features
> > 
> > [1] https://patchwork.linuxtv.org/patch/28847/
> > ---
> >  .../media/uapi/v4l/pixfmt-reserved.rst| 41 +++
> >  .../media/uapi/v4l/pixfmt-v4l2-mplane.rst | 16 ++--
> >  Documentation/media/uapi/v4l/pixfmt-v4l2.rst  | 37 ++---
> >  drivers/media/v4l2-core/v4l2-ioctl.c  | 12 ++
> >  include/uapi/linux/videodev2.h|  5 +++
> >  5 files changed, 94 insertions(+), 17 deletions(-)
> > 
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-reserved.rst 
> > b/Documentation/media/uapi/v4l/pixfmt-reserved.rst
> > index 38af1472a4b4..c1090027626c 100644
> > --- a/Documentation/media/uapi/v4l/pixfmt-reserved.rst
> > +++ b/Documentation/media/uapi/v4l/pixfmt-reserved.rst
> > @@ -261,3 +261,44 @@ please make a proposal on the linux-media mailing list.
> > by RGBA values (128, 192, 255, 128), the same pixel described with
> > premultiplied colors would be described by RGBA values (64, 96,
> > 128, 128)
> > +* - ``V4L2_PIX_FMT_FLAG_CSC_COLORSPACE``
> > +  - 0x0002
> > +  - Set by the driver to indicate colorspace conversion support. Set 
> > by the
> > +   application to request conversion to the specified colorspace. It is
> > +   only used for capture and is ignored for output streams. If set by the
> > +   application, then request the driver to do colorspace conversion from
> > +   the received colorspace to the requested colorspace by setting the
> > +   ``colorspace`` field of struct :c:type:`v4l2_pix_format`.
> > +* - ``V4L2_PIX_FMT_FLAG_CSC_YCBCR_ENC``
> > +  - 0x0004
> > +  - Set by the driver to indicate Y'CbCr encoding conversion support. 
> > Set
> > +   by the application to request conversion to the specified Y'CbCr
> > +   encoding.  It is only used for capture and is ignored for 

Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API

[Mauro Carvalho Chehab]

Em Fri, 7 Dec 2018 11:53:17 -0200
Mauro Carvalho Chehab  escreveu:

> Em Fri, 7 Dec 2018 14:27:48 +0100
> Hans Verkuil  escreveu:
> 
> > On 12/07/2018 01:42 PM, Mauro Carvalho Chehab wrote:
> > > Em Fri, 7 Dec 2018 12:47:24 +0100
> > > Hans Verkuil  escreveu:
> > >   
> > >> On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote:  
> > >>> Em Fri, 7 Dec 2018 10:09:04 +0100
> > >>> Hans Verkuil  escreveu:
> > >>> 
> > >>>> This patch selects MEDIA_CONTROLLER for all camera, analog TV and
> > >>>> digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically.
> > >>>>
> > >>>> This will allow us to simplify drivers that currently have to add
> > >>>> #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API
> > >>>> to their code, since now this will always be available.
> > >>>>
> > >>>> The original intent of allowing these to be configured by the
> > >>>> user was (I think) to save a bit of memory. 
> > >>>
> > >>> No. The original intent was/is to be sure that adding the media
> > >>> controller support won't be breaking existing working drivers.
> > >>
> > >> That doesn't make sense. If enabling this option would break existing
> > >> drivers, then something is really wrong, isn't it?  
> > > 
> > > It is the opposite: disabling it should not break any driver that don't
> > > depend on them to work.
> > >   
> > >>  
> > >>> 
> > >>>> But as more and more
> > >>>> drivers have a media controller and all regular distros already
> > >>>> enable one or more of those drivers, the memory for the MC code is
> > >>>> there anyway.
> > >>>>
> > >>>> Complexity has always been the bane of media drivers, so reducing
> > >>>> complexity at the expense of a bit more memory (which is a rounding
> > >>>> error compared to the amount of video buffer memory needed) is IMHO
> > >>>> a good thing.
> > >>>>
> > >>>> Signed-off-by: Hans Verkuil 
> > >>>> ---
> > >>>> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> > >>>> index 8add62a18293..56eb01cc8bb4 100644
> > >>>> --- a/drivers/media/Kconfig
> > >>>> +++ b/drivers/media/Kconfig
> > >>>> @@ -31,6 +31,7 @@ comment "Multimedia core support"
> > >>>>  #
> > >>>>  config MEDIA_CAMERA_SUPPORT
> > >>>>bool "Cameras/video grabbers support"
> > >>>> +  select MEDIA_CONTROLLER
> > >>>>---help---
> > >>>>  Enable support for webcams and video grabbers.
> > >>>>
> > >>>> @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT
> > >>>>
> > >>>>  config MEDIA_ANALOG_TV_SUPPORT
> > >>>>bool "Analog TV support"
> > >>>> +  select MEDIA_CONTROLLER
> > >>>>---help---
> > >>>>  Enable analog TV support.
> > >>>>
> > >>>> @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT
> > >>>>
> > >>>>  config MEDIA_DIGITAL_TV_SUPPORT
> > >>>>bool "Digital TV support"
> > >>>> +  select MEDIA_CONTROLLER
> > >>>>---help---
> > >>>>  Enable digital TV support.
> > >>>
> > >>> See my comments below.
> > >>> 
> > >>>>
> > >>>> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig"
> > >>>>
> > >>>>  config MEDIA_CONTROLLER
> > >>>>bool "Media Controller API"
> > >>>> -  depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
> > >>>> MEDIA_DIGITAL_TV_SUPPORT
> > >>>>---help---
> > >>>>  Enable the media controller API used to query media devices 
> > >>>> internal
> > >>>>  topology and configure it dynamically.
> > >>>
> > >>> I have split comments with regards to it. Yeah, nowadays media 
> > >>> controller
&g

Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API

[Mauro Carvalho Chehab]

Em Fri, 7 Dec 2018 14:27:48 +0100
Hans Verkuil  escreveu:

> On 12/07/2018 01:42 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 7 Dec 2018 12:47:24 +0100
> > Hans Verkuil  escreveu:
> >   
> >> On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote:  
> >>> Em Fri, 7 Dec 2018 10:09:04 +0100
> >>> Hans Verkuil  escreveu:
> >>> 
> >>>> This patch selects MEDIA_CONTROLLER for all camera, analog TV and
> >>>> digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically.
> >>>>
> >>>> This will allow us to simplify drivers that currently have to add
> >>>> #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API
> >>>> to their code, since now this will always be available.
> >>>>
> >>>> The original intent of allowing these to be configured by the
> >>>> user was (I think) to save a bit of memory. 
> >>>
> >>> No. The original intent was/is to be sure that adding the media
> >>> controller support won't be breaking existing working drivers.
> >>
> >> That doesn't make sense. If enabling this option would break existing
> >> drivers, then something is really wrong, isn't it?  
> > 
> > It is the opposite: disabling it should not break any driver that don't
> > depend on them to work.
> >   
> >>  
> >>> 
> >>>> But as more and more
> >>>> drivers have a media controller and all regular distros already
> >>>> enable one or more of those drivers, the memory for the MC code is
> >>>> there anyway.
> >>>>
> >>>> Complexity has always been the bane of media drivers, so reducing
> >>>> complexity at the expense of a bit more memory (which is a rounding
> >>>> error compared to the amount of video buffer memory needed) is IMHO
> >>>> a good thing.
> >>>>
> >>>> Signed-off-by: Hans Verkuil 
> >>>> ---
> >>>> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> >>>> index 8add62a18293..56eb01cc8bb4 100644
> >>>> --- a/drivers/media/Kconfig
> >>>> +++ b/drivers/media/Kconfig
> >>>> @@ -31,6 +31,7 @@ comment "Multimedia core support"
> >>>>  #
> >>>>  config MEDIA_CAMERA_SUPPORT
> >>>>  bool "Cameras/video grabbers support"
> >>>> +select MEDIA_CONTROLLER
> >>>>  ---help---
> >>>>Enable support for webcams and video grabbers.
> >>>>
> >>>> @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT
> >>>>
> >>>>  config MEDIA_ANALOG_TV_SUPPORT
> >>>>  bool "Analog TV support"
> >>>> +select MEDIA_CONTROLLER
> >>>>  ---help---
> >>>>Enable analog TV support.
> >>>>
> >>>> @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT
> >>>>
> >>>>  config MEDIA_DIGITAL_TV_SUPPORT
> >>>>  bool "Digital TV support"
> >>>> +select MEDIA_CONTROLLER
> >>>>  ---help---
> >>>>Enable digital TV support.
> >>>
> >>> See my comments below.
> >>> 
> >>>>
> >>>> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig"
> >>>>
> >>>>  config MEDIA_CONTROLLER
> >>>>  bool "Media Controller API"
> >>>> -depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
> >>>> MEDIA_DIGITAL_TV_SUPPORT
> >>>>  ---help---
> >>>>Enable the media controller API used to query media devices 
> >>>> internal
> >>>>topology and configure it dynamically.
> >>>
> >>> I have split comments with regards to it. Yeah, nowadays media controller
> >>> has becoming more important. Still, a lot of media drivers work fine
> >>> without them.
> >>>
> >>> Anyway, if we're willing to make it mandatory, better to just remove the
> >>> entire config option or to make it a silent one. 
> >>
> >> Well, that assumes that the media controller will only be used by media
> >> drivers, and not alsa or anyone else who wants to experiment with the MC.
> >&g

Re: [PATCH v2] media: cedrus: don't initialize pointers with zero

[Mauro Carvalho Chehab]

Em Fri, 07 Dec 2018 14:21:44 +0100
Paul Kocialkowski  escreveu:

> Hi,
> 
> On Fri, 2018-12-07 at 08:03 -0500, Mauro Carvalho Chehab wrote:
> > A common mistake is to assume that initializing a var with:
> > struct foo f = { 0 };
> > 
> > Would initialize a zeroed struct. Actually, what this does is
> > to initialize the first element of the struct to zero.
> > 
> > According to C99 Standard 6.7.8.21:
> > 
> > "If there are fewer initializers in a brace-enclosed
> >  list than there are elements or members of an aggregate,
> >  or fewer characters in a string literal used to initialize
> >  an array of known size than there are elements in the array,
> >  the remainder of the aggregate shall be initialized implicitly
> >  the same as objects that have static storage duration."
> > 
> > So, in practice, it could zero the entire struct, but, if the
> > first element is not an integer, it will produce warnings:
> > 
> > 
> > drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
> >   warning: Using plain integer as NULL pointer
> > 
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
> >   warning: Using plain integer as NULL pointer
> > 
> > As the right initialization would be, instead:
> > 
> > struct foo f = { NULL };  
> 
> Thanks for sharing these details, it's definitely interesting and good
> to know :)

Yeah, that's something that was bothering for quite a while, as I've
seen patches using either one of the ways. It took me a while to
do some research, and having it documented at the patch helps, as
we should now handle it the same way for similar stuff :-)

> 
> > Another way to initialize it with gcc is to use:
> > 
> > struct foo f = {};
> > 
> > That seems to be a gcc extension, but clang also does the right thing,
> > and that's a clean way for doing it.
> > 
> > Anyway, I decided to check upstream what's the most commonly pattern.
> > The "= {}" pattern has about 2000 entries:
> > 
> > $ git grep -E "=\s*\{\s*\}"|wc -l
> > 1951
> > 
> > The standard-C compliant pattern has about 2500 entries:
> > 
> > $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
> > 137
> > $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
> > 2323
> > 
> > Meaning that developers have split options on that.
> > 
> > So, let's opt to the simpler form.  
> 
> Acked-by: Paul Kocialkowski 

Applied, thanks!

> 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
> >  drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
> > b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > index b538eb0321d8..b7c918fa5fd1 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, 
> > struct cedrus_ctx *ctx)
> > memset(ctx->ctrls, 0, ctrl_size);
> >  
> > for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> > -   struct v4l2_ctrl_config cfg = { 0 };
> > +   struct v4l2_ctrl_config cfg = {};
> >  
> > cfg.elem_size = cedrus_controls[i].elem_size;
> > cfg.id = cedrus_controls[i].id;
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > index e40180a33951..f10c25f5460e 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
> >  {
> > struct cedrus_ctx *ctx = priv;
> > struct cedrus_dev *dev = ctx->dev;
> > -   struct cedrus_run run = { 0 };
> > +   struct cedrus_run run = {};
> > struct media_request *src_req;
> > unsigned long flags;
> >



Thanks,
Mauro

[PATCH 1/2] media: pxa_camera: don't deferenciate a NULL pointer

[Mauro Carvalho Chehab]

As warned by smatch:
drivers/media/platform/pxa_camera.c:2400 pxa_camera_probe() error: we 
previously assumed 'pcdev->pdata' could be null (see line 2397)

It would be possible that neither DT nor platform data would be
provided. This is a Kernel bug, so warn about that and bail.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/pxa_camera.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/pxa_camera.c 
b/drivers/media/platform/pxa_camera.c
index 5f930560eb30..f91f8fd424c4 100644
--- a/drivers/media/platform/pxa_camera.c
+++ b/drivers/media/platform/pxa_camera.c
@@ -2396,6 +2396,9 @@ static int pxa_camera_probe(struct platform_device *pdev)
pcdev->pdata = pdev->dev.platform_data;
if (pdev->dev.of_node && !pcdev->pdata) {
err = pxa_camera_pdata_from_dt(>dev, pcdev, >asd);
+   } else if (!pcdev->pdata) {
+   WARN_ON(1);
+   return -ENODEV;
} else {
pcdev->platform_flags = pcdev->pdata->flags;
pcdev->mclk = pcdev->pdata->mclk_10khz * 1;
-- 
2.19.2

[PATCH 2/2] media: drxk_hard: check if parameter is not NULL

[Mauro Carvalho Chehab]

There is a smatch warning:
drivers/media/dvb-frontends/drxk_hard.c: 
drivers/media/dvb-frontends/drxk_hard.c:1478 scu_command() error: we previously 
assumed 'parameter' could be null (see line 1467)

Telling that parameter might be NULL. Well, it can't, due to the
way the driver works, but it doesn't hurt to add a check, in order
to shut up smatch.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/drxk_hard.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/drxk_hard.c 
b/drivers/media/dvb-frontends/drxk_hard.c
index 84ac3f73f8fe..8ea1e45be710 100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -1474,9 +1474,11 @@ static int scu_command(struct drxk_state *state,
 
/* assume that the command register is ready
since it is checked afterwards */
-   for (ii = parameter_len - 1; ii >= 0; ii -= 1) {
-   buffer[cnt++] = (parameter[ii] & 0xFF);
-   buffer[cnt++] = ((parameter[ii] >> 8) & 0xFF);
+   if (parameter) {
+   for (ii = parameter_len - 1; ii >= 0; ii -= 1) {
+   buffer[cnt++] = (parameter[ii] & 0xFF);
+   buffer[cnt++] = ((parameter[ii] >> 8) & 0xFF);
+   }
}
buffer[cnt++] = (cmd & 0xFF);
buffer[cnt++] = ((cmd >> 8) & 0xFF);
-- 
2.19.2

[PATCH v2] media: cedrus: don't initialize pointers with zero

[Mauro Carvalho Chehab]

A common mistake is to assume that initializing a var with:
struct foo f = { 0 };

Would initialize a zeroed struct. Actually, what this does is
to initialize the first element of the struct to zero.

According to C99 Standard 6.7.8.21:

"If there are fewer initializers in a brace-enclosed
 list than there are elements or members of an aggregate,
 or fewer characters in a string literal used to initialize
 an array of known size than there are elements in the array,
 the remainder of the aggregate shall be initialized implicitly
 the same as objects that have static storage duration."

So, in practice, it could zero the entire struct, but, if the
first element is not an integer, it will produce warnings:


drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
  warning: Using plain integer as NULL pointer

drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
  warning: Using plain integer as NULL pointer

As the right initialization would be, instead:

struct foo f = { NULL };

Another way to initialize it with gcc is to use:

struct foo f = {};

That seems to be a gcc extension, but clang also does the right thing,
and that's a clean way for doing it.

Anyway, I decided to check upstream what's the most commonly pattern.
The "= {}" pattern has about 2000 entries:

$ git grep -E "=\s*\{\s*\}"|wc -l
1951

The standard-C compliant pattern has about 2500 entries:

$ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
137
$ git grep -E "=\s*\{\s*0\s*\}"|wc -l
2323

Meaning that developers have split options on that.

So, let's opt to the simpler form.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
 drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index b538eb0321d8..b7c918fa5fd1 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct 
cedrus_ctx *ctx)
memset(ctx->ctrls, 0, ctrl_size);
 
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
-   struct v4l2_ctrl_config cfg = { 0 };
+   struct v4l2_ctrl_config cfg = {};
 
cfg.elem_size = cedrus_controls[i].elem_size;
cfg.id = cedrus_controls[i].id;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..f10c25f5460e 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
 {
struct cedrus_ctx *ctx = priv;
struct cedrus_dev *dev = ctx->dev;
-   struct cedrus_run run = { 0 };
+   struct cedrus_run run = {};
struct media_request *src_req;
unsigned long flags;
 
-- 
2.19.2

Re: [PATCH] media: cedrus: don't initialize pointers with zero

[Mauro Carvalho Chehab]

Em Fri, 7 Dec 2018 12:27:09 +
Ian Arkver  escreveu:

> On 07/12/2018 11:37, Hans Verkuil wrote:
> > On 12/07/2018 12:31 PM, Mauro Carvalho Chehab wrote:  
> >> Em Fri, 7 Dec 2018 12:14:50 +0100
> >> Hans Verkuil  escreveu:
> >>  
> >>> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:  
> >>>> A common mistake is to assume that initializing a var with:
> >>>>  struct foo f = { 0 };
> >>>>
> >>>> Would initialize a zeroed struct. Actually, what this does is
> >>>> to initialize the first element of the struct to zero.
> >>>>
> >>>> According to C99 Standard 6.7.8.21:
> >>>>
> >>>>  "If there are fewer initializers in a brace-enclosed
> >>>>   list than there are elements or members of an aggregate,
> >>>>   or fewer characters in a string literal used to initialize
> >>>>   an array of known size than there are elements in the array,
> >>>>   the remainder of the aggregate shall be initialized implicitly
> >>>>   the same as objects that have static storage duration."
> >>>>
> >>>> So, in practice, it could zero the entire struct, but, if the
> >>>> first element is not an integer, it will produce warnings:
> >>>>
> >>>>  
> >>>> drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
> >>>>   warning: Using plain integer as NULL pointer
> >>>>  
> >>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
> >>>>   warning: Using plain integer as NULL pointer
> >>>>
> >>>> A proper way to initialize it with gcc is to use:
> >>>>
> >>>>  struct foo f = { };
> >>>>
> >>>> But that seems to be a gcc extension. So, I decided to check upstream  
> >>>
> >>> No, this is not a gcc extension. It's part of the latest C standard.  
> >>
> >> Sure? Where the C standard spec states that? I've been seeking for
> >> such info for a while, as '= {}' is also my personal preference.  
> > 
> > I believe it was added in C11, but I've loaned the book that stated
> > that to someone else, so I can't check.  
> 
> Sadly I don't see mention of empty initializer lists in section 6.7.9 of
> ISO/IEC 9899:2011, though I've only got a draft version.

Yeah, as far as I checked, this is not really part of the standard.

Depending on how you read:

  "If there are fewer initializers in a brace-enclosed
   list than there are elements or members of an aggregate,
   or fewer characters in a string literal used to initialize
   an array of known size than there are elements in the array,
   the remainder of the aggregate shall be initialized implicitly
   the same as objects that have static storage duration."

One may infere that a brace-enclosed list with zero elements
would fit, and "the remainder of the aggregate shall be
initialized implicitly".

I suspect that this is how gcc people interpreted it.

> I had a play with Compiler Explorer[1] and it seems like clang is OK
> with the {} form though just out of interest msvc isn't.

Yeah, I'm aware that msvc won't support it. Good to know that clang
does the right thing cleaning the struct.

To be realistic, we only really care with gcc at the Kernel side, as
clang upstream versions still can't build upstream Kernels, and
nobody uses any other compiler for the Kernel anymore. Yet, with
regards to clang, there's a push to let it to build the Kernel.
So, it seems wise to add something that would work for both.

Anyway, I'll post a version 2 of this patch using ={} and placing
some rationale on it.

> I didn't try
> exploring other command line options.
> 
> [1] https://gcc.godbolt.org/z/XIDC7W
> 
> Regards,
> Ian
> > 
> > In any case, it's used everywhere:
> > 
> > git grep '= *{ *}' drivers/
> > 
> > So it is really pointless to *not* use it.
> > 
> > Regards,
> > 
> > Hans
> >   
> >> I tried to build the Kernel with clang, just to be sure that this
> >> won't cause issues with the clang support, but, unfortunately, the
> >> clang compiler (not even the upstream version) is able to build
> >> the upstream Kernel yet, as it lacks asm-goto support (there is an
> >> OOT patch for llvm solving it - but it sounds too much effort for
> >> my time to have to build llvm from their sources just for a simple
> &

Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API

[Mauro Carvalho Chehab]

Em Fri, 7 Dec 2018 12:47:24 +0100
Hans Verkuil  escreveu:

> On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 7 Dec 2018 10:09:04 +0100
> > Hans Verkuil  escreveu:
> >   
> >> This patch selects MEDIA_CONTROLLER for all camera, analog TV and
> >> digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically.
> >>
> >> This will allow us to simplify drivers that currently have to add
> >> #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API
> >> to their code, since now this will always be available.
> >>
> >> The original intent of allowing these to be configured by the
> >> user was (I think) to save a bit of memory.   
> > 
> > No. The original intent was/is to be sure that adding the media
> > controller support won't be breaking existing working drivers.  
> 
> That doesn't make sense. If enabling this option would break existing
> drivers, then something is really wrong, isn't it?

It is the opposite: disabling it should not break any driver that don't
depend on them to work.

> 
> >   
> >> But as more and more
> >> drivers have a media controller and all regular distros already
> >> enable one or more of those drivers, the memory for the MC code is
> >> there anyway.
> >>
> >> Complexity has always been the bane of media drivers, so reducing
> >> complexity at the expense of a bit more memory (which is a rounding
> >> error compared to the amount of video buffer memory needed) is IMHO
> >> a good thing.
> >>
> >> Signed-off-by: Hans Verkuil 
> >> ---
> >> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> >> index 8add62a18293..56eb01cc8bb4 100644
> >> --- a/drivers/media/Kconfig
> >> +++ b/drivers/media/Kconfig
> >> @@ -31,6 +31,7 @@ comment "Multimedia core support"
> >>  #
> >>  config MEDIA_CAMERA_SUPPORT
> >>bool "Cameras/video grabbers support"
> >> +  select MEDIA_CONTROLLER
> >>---help---
> >>  Enable support for webcams and video grabbers.
> >>
> >> @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT
> >>
> >>  config MEDIA_ANALOG_TV_SUPPORT
> >>bool "Analog TV support"
> >> +  select MEDIA_CONTROLLER
> >>---help---
> >>  Enable analog TV support.
> >>
> >> @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT
> >>
> >>  config MEDIA_DIGITAL_TV_SUPPORT
> >>bool "Digital TV support"
> >> +  select MEDIA_CONTROLLER
> >>---help---
> >>  Enable digital TV support.  
> > 
> > See my comments below.
> >   
> >>
> >> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig"
> >>
> >>  config MEDIA_CONTROLLER
> >>bool "Media Controller API"
> >> -  depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
> >> MEDIA_DIGITAL_TV_SUPPORT
> >>---help---
> >>  Enable the media controller API used to query media devices internal
> >>  topology and configure it dynamically.  
> > 
> > I have split comments with regards to it. Yeah, nowadays media controller
> > has becoming more important. Still, a lot of media drivers work fine
> > without them.
> > 
> > Anyway, if we're willing to make it mandatory, better to just remove the
> > entire config option or to make it a silent one.   
> 
> Well, that assumes that the media controller will only be used by media
> drivers, and not alsa or anyone else who wants to experiment with the MC.
> 
> I won't object to making it silent (since it does reflect the current
> situation), but since this functionality is not actually specific to media
> drivers I think that is a good case to be made to allow it to be selected
> manually.
> 
> >   
> >> @@ -119,16 +121,11 @@ config VIDEO_DEV
> >>tristate
> >>depends on MEDIA_SUPPORT
> >>depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
> >> MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT
> >> +  select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER
> >>default y
> >>
> >>  config VIDEO_V4L2_SUBDEV_API
> >> -  bool "V4L2 sub-device userspace API"
> >> -  depends on VIDEO_DEV && MEDIA_CONTROLLER
> >> -  ---help---
> >> -Enables the V4L2 sub-device pad-level userspace API used to configure
> >> -video format, size and frame rate between hardware blocks.
> >&

[PATCH] media: imx214: don't de-reference a NULL pointer

[Mauro Carvalho Chehab]

As warned by smatch:
drivers/media/i2c/imx214.c:591 imx214_set_format() warn: variable 
dereferenced before check 'format' (see line 589)

It turns that the code at imx214_set_format() has support for being
called with the format being NULL. I've no idea why, as it is only
called internally with the pointer set, and via subdev API (with
should also set it).

Also, the entire logic there depends on having format != NULL, so
just remove the bogus broken support for a null format.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/imx214.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c
index ec3d1b855f62..b046a26219a4 100644
--- a/drivers/media/i2c/imx214.c
+++ b/drivers/media/i2c/imx214.c
@@ -588,12 +588,10 @@ static int imx214_set_format(struct v4l2_subdev *sd,
 
__crop = __imx214_get_pad_crop(imx214, cfg, format->pad, format->which);
 
-   if (format)
-   mode = v4l2_find_nearest_size(imx214_modes,
-   ARRAY_SIZE(imx214_modes), width, height,
-   format->format.width, format->format.height);
-   else
-   mode = _modes[0];
+   mode = v4l2_find_nearest_size(imx214_modes,
+ ARRAY_SIZE(imx214_modes), width, height,
+ format->format.width,
+ format->format.height);
 
__crop->width = mode->width;
__crop->height = mode->height;
-- 
2.19.2

Re: [PATCH] media: cedrus: don't initialize pointers with zero

[Mauro Carvalho Chehab]

Em Fri, 7 Dec 2018 12:14:50 +0100
Hans Verkuil  escreveu:

> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> > A common mistake is to assume that initializing a var with:
> > struct foo f = { 0 };
> > 
> > Would initialize a zeroed struct. Actually, what this does is
> > to initialize the first element of the struct to zero.
> > 
> > According to C99 Standard 6.7.8.21:
> > 
> > "If there are fewer initializers in a brace-enclosed
> >  list than there are elements or members of an aggregate,
> >  or fewer characters in a string literal used to initialize
> >  an array of known size than there are elements in the array,
> >  the remainder of the aggregate shall be initialized implicitly
> >  the same as objects that have static storage duration."
> > 
> > So, in practice, it could zero the entire struct, but, if the
> > first element is not an integer, it will produce warnings:
> > 
> > 
> > drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
> >   warning: Using plain integer as NULL pointer
> > 
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
> >   warning: Using plain integer as NULL pointer
> > 
> > A proper way to initialize it with gcc is to use:
> > 
> > struct foo f = { };
> > 
> > But that seems to be a gcc extension. So, I decided to check upstream  
> 
> No, this is not a gcc extension. It's part of the latest C standard.

Sure? Where the C standard spec states that? I've been seeking for
such info for a while, as '= {}' is also my personal preference.

I tried to build the Kernel with clang, just to be sure that this
won't cause issues with the clang support, but, unfortunately, the
clang compiler (not even the upstream version) is able to build
the upstream Kernel yet, as it lacks asm-goto support (there is an
OOT patch for llvm solving it - but it sounds too much effort for
my time to have to build llvm from their sources just for a simple
check like this).

> It's used all over in the kernel, so please use {} instead of { NULL }.
> 
> Personally I think {} is a fantastic invention and I wish C++ had it as
> well.

Fully agreed on that.

> 
> Regards,
> 
>   Hans
> 
> > what's the most commonly pattern. The gcc pattern has about 2000 entries:
> > 
> > $ git grep -E "=\s*\{\s*\}"|wc -l
> > 1951
> > 
> > The standard-C compliant pattern has about 2500 entries:
> > 
> > $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
> > 137
> > $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
> > 2323
> > 
> > So, let's initialize those structs with:
> >  = { NULL }
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
> >  drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
> > b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > index b538eb0321d8..44c45c687503 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, 
> > struct cedrus_ctx *ctx)
> > memset(ctx->ctrls, 0, ctrl_size);
> >  
> > for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> > -   struct v4l2_ctrl_config cfg = { 0 };
> > +   struct v4l2_ctrl_config cfg = { NULL };
> >  
> > cfg.elem_size = cedrus_controls[i].elem_size;
> > cfg.id = cedrus_controls[i].id;
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > index e40180a33951..4099a42dba2d 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
> >  {
> > struct cedrus_ctx *ctx = priv;
> > struct cedrus_dev *dev = ctx->dev;
> > -   struct cedrus_run run = { 0 };
> > +   struct cedrus_run run = { NULL };
> > struct media_request *src_req;
> > unsigned long flags;
> >  
> >   
> 



Thanks,
Mauro

Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API

[Mauro Carvalho Chehab]

Em Fri, 7 Dec 2018 10:09:04 +0100
Hans Verkuil  escreveu:

> This patch selects MEDIA_CONTROLLER for all camera, analog TV and
> digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically.
> 
> This will allow us to simplify drivers that currently have to add
> #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API
> to their code, since now this will always be available.
> 
> The original intent of allowing these to be configured by the
> user was (I think) to save a bit of memory. 

No. The original intent was/is to be sure that adding the media
controller support won't be breaking existing working drivers.

> But as more and more
> drivers have a media controller and all regular distros already
> enable one or more of those drivers, the memory for the MC code is
> there anyway.
> 
> Complexity has always been the bane of media drivers, so reducing
> complexity at the expense of a bit more memory (which is a rounding
> error compared to the amount of video buffer memory needed) is IMHO
> a good thing.
> 
> Signed-off-by: Hans Verkuil 
> ---
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index 8add62a18293..56eb01cc8bb4 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -31,6 +31,7 @@ comment "Multimedia core support"
>  #
>  config MEDIA_CAMERA_SUPPORT
>   bool "Cameras/video grabbers support"
> + select MEDIA_CONTROLLER
>   ---help---
> Enable support for webcams and video grabbers.
> 
> @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT
> 
>  config MEDIA_ANALOG_TV_SUPPORT
>   bool "Analog TV support"
> + select MEDIA_CONTROLLER
>   ---help---
> Enable analog TV support.
> 
> @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT
> 
>  config MEDIA_DIGITAL_TV_SUPPORT
>   bool "Digital TV support"
> + select MEDIA_CONTROLLER
>   ---help---
> Enable digital TV support.

See my comments below.

> 
> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig"
> 
>  config MEDIA_CONTROLLER
>   bool "Media Controller API"
> - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
> MEDIA_DIGITAL_TV_SUPPORT
>   ---help---
> Enable the media controller API used to query media devices internal
> topology and configure it dynamically.

I have split comments with regards to it. Yeah, nowadays media controller
has becoming more important. Still, a lot of media drivers work fine
without them.

Anyway, if we're willing to make it mandatory, better to just remove the
entire config option or to make it a silent one. 

> @@ -119,16 +121,11 @@ config VIDEO_DEV
>   tristate
>   depends on MEDIA_SUPPORT
>   depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
> MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT
> + select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER
>   default y
> 
>  config VIDEO_V4L2_SUBDEV_API
> - bool "V4L2 sub-device userspace API"
> - depends on VIDEO_DEV && MEDIA_CONTROLLER
> - ---help---
> -   Enables the V4L2 sub-device pad-level userspace API used to configure
> -   video format, size and frame rate between hardware blocks.
> -
> -   This API is mostly used by camera interfaces in embedded platforms.
> + bool

NACK. 

There is a very good reason why the subdev API is optional: there
are drivers that use camera sensors but are not MC-centric. On those,
the USB bridge driver is responsible to setup the subdevice. 

This options helps to ensure that camera sensors used by such drivers
won't stop working because of the lack of the subdev-API.

> 
>  source "drivers/media/v4l2-core/Kconfig"
> 



Thanks,
Mauro

[PATCH] media: cetrus: return an error if alloc fails

[Mauro Carvalho Chehab]

As warned by smatch:

drivers/staging/media/sunxi/cedrus/cedrus.c: 
drivers/staging/media/sunxi/cedrus/cedrus.c:93 cedrus_init_ctrls() error: 
potential null dereference 'ctx->ctrls'.  (kzalloc returns null)

While here, remove the memset(), as kzalloc() already zeroes the
struct.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/sunxi/cedrus/cedrus.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 44c45c687503..24b89cd2b692 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -72,7 +72,8 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct 
cedrus_ctx *ctx)
ctrl_size = sizeof(ctrl) * CEDRUS_CONTROLS_COUNT + 1;
 
ctx->ctrls = kzalloc(ctrl_size, GFP_KERNEL);
-   memset(ctx->ctrls, 0, ctrl_size);
+   if (!ctx->ctrls)
+   return -ENOMEM;
 
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
struct v4l2_ctrl_config cfg = { NULL };
-- 
2.19.2

[PATCH] media: cedrus: don't initialize pointers with zero

[Mauro Carvalho Chehab]

A common mistake is to assume that initializing a var with:
struct foo f = { 0 };

Would initialize a zeroed struct. Actually, what this does is
to initialize the first element of the struct to zero.

According to C99 Standard 6.7.8.21:

"If there are fewer initializers in a brace-enclosed
 list than there are elements or members of an aggregate,
 or fewer characters in a string literal used to initialize
 an array of known size than there are elements in the array,
 the remainder of the aggregate shall be initialized implicitly
 the same as objects that have static storage duration."

So, in practice, it could zero the entire struct, but, if the
first element is not an integer, it will produce warnings:


drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
  warning: Using plain integer as NULL pointer

drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
  warning: Using plain integer as NULL pointer

A proper way to initialize it with gcc is to use:

struct foo f = { };

But that seems to be a gcc extension. So, I decided to check upstream
what's the most commonly pattern. The gcc pattern has about 2000 entries:

$ git grep -E "=\s*\{\s*\}"|wc -l
1951

The standard-C compliant pattern has about 2500 entries:

$ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
137
$ git grep -E "=\s*\{\s*0\s*\}"|wc -l
2323

So, let's initialize those structs with:
     = { NULL }

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
 drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index b538eb0321d8..44c45c687503 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct 
cedrus_ctx *ctx)
memset(ctx->ctrls, 0, ctrl_size);
 
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
-   struct v4l2_ctrl_config cfg = { 0 };
+   struct v4l2_ctrl_config cfg = { NULL };
 
cfg.elem_size = cedrus_controls[i].elem_size;
cfg.id = cedrus_controls[i].id;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..4099a42dba2d 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
 {
struct cedrus_ctx *ctx = priv;
struct cedrus_dev *dev = ctx->dev;
-   struct cedrus_run run = { 0 };
+   struct cedrus_run run = { NULL };
struct media_request *src_req;
unsigned long flags;
 
-- 
2.19.2

Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

[Mauro Carvalho Chehab]

Em Thu, 6 Dec 2018 17:07:52 -0200
Mauro Carvalho Chehab  escreveu:

> Em Thu, 6 Dec 2018 13:36:24 -0500
> Alex Deucher  escreveu:
> 
> > On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab  
> > wrote:  
> > >
> > > Em Thu, 06 Dec 2018 18:18:23 +0100
> > > Markus Dobel  escreveu:
> > >
> > > > Hi everyone,
> > > >
> > > > I will try if the hack mentioned fixes the issue for me on the weekend 
> > > > (but I assume, as if effectively removes the function).
> > >
> > > It should, but it keeps a few changes. Just want to be sure that what
> > > would be left won't cause issues. If this works, the logic that would
> > > solve Ryzen DMA fixes will be contained into a single point, making
> > > easier to maintain it.
> > >
> > > >
> > > > Just in case this is of interest, I neither have Ryzen nor Intel, but 
> > > > an HP Microserver G7 with an AMD Turion II Neo  N54L, so the machine is 
> > > > more on the slow side.
> > >
> > > Good to know. It would probably worth to check if this Ryzen
> > > bug occors with all versions of it or with just a subset.
> > > I mean: maybe it is only at the first gen or Ryzen and doesn't
> > > affect Ryzen 2 (or vice versa).
> > 
> > The original commit also mentions some Xeons are affected too.  Seems
> > like this is potentially an issue on the device side rather than the
> > platform.  
> 
> Maybe.
> 
> > >
> > > The PCI quirks logic will likely need to detect the PCI ID of
> > > the memory controllers found at the buggy CPUs, in order to enable
> > > the quirk only for the affected ones.
> > >
> > > It could be worth talking with AMD people in order to be sure about
> > > the differences at the DMA engine side.
> > >
> > 
> > It's not clear to me what the pci or platform quirk would do.  The
> > workaround seems to be in the driver, not on the platform.  
> 
> Yeah, the fix should be at the driver, but pci/quirk.c would be able
> to detect memory controllers that would require a hack inside the
> driver, in a similar way to what the media PCI drivers already do
> for DMA controllers that don't support pci2pci transfers.
> 
> There, basically the PCI core (drivers/pci/pci.c and 
> drivers/pci/quirks.c) sets a flag (pci_pci_problems) indicating
> potential issues.
> 
> Then, the driver compares such flag in order to enable the specific quirk.
> 
> Ok, there would be a different way to handle it. The driver could use a 
> logic similar to the one I wrote for drivers/edac/i7core_edac.c. There,
> the logic seeks for some specific PCI device IDs using pci_get_device(),
> adjusting the code accordingly, depending on the detected PCI devices.
> 
> In other words, running something like this (untested), at probe time should
> produce similar results:
> 
>   /*
>* FIXME: It probably makes sense to also be able to identify specific
>* versions of the same PCI ID, just in case a latter stepping got a
>* fix for the issue.
>*/
>   const static struct {
>   int vendor, dev;
>   } broken_dev_id[] = {
>   PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_foo,
>   PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_bar,
>   },
> 
>   bool cx23885_does_dma_require_reset(void) 
>   {
>   int i;
>   struct pci_dev *pdev = NULL;
> 
>   for (i = 0; i < sizeof(broken_dev_id); i++) {
>   pdev = pci_get_device(broken_dev_id[i].vendor, 
> broken_dev_id[i].dev, NULL);
>   if (pdev) {
>   pci_put_device(pdev);
>   return true;
>   }
>   }
>   return false;
>   }
> 
> Should work. In any case, we need to know what memory controllers 
> have problems, and what are their PCI IDs, and add them (if not there yet)
> at include/linux/pci_ids.h
> 
> Thanks,
> Mauro

To be clearer, I'm thinking on something like the (untested)
code below (untested).

PS.: the PCI ID used there may be wrong. I just added one in
order to have a proof of concept.

Thanks,
Mauro

[PATCH] media: cx23885: only reset DMA on problematic CPUs

It is reported that changeset 95f408bbc4e4 ("media: cx23885:
Ryzen DMA related RiSC engine stall fixes") caused regresssions
with other CPUs.

Ensure that the quirk will be applied only for the CPUs that
are known to cause problems.

Fixes: 95f408bbc4e4 ("media: cx23885: Ryzen DMA related RiSC en

Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

[Mauro Carvalho Chehab]

Em Thu, 6 Dec 2018 13:36:24 -0500
Alex Deucher  escreveu:

> On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab  
> wrote:
> >
> > Em Thu, 06 Dec 2018 18:18:23 +0100
> > Markus Dobel  escreveu:
> >  
> > > Hi everyone,
> > >
> > > I will try if the hack mentioned fixes the issue for me on the weekend 
> > > (but I assume, as if effectively removes the function).  
> >
> > It should, but it keeps a few changes. Just want to be sure that what
> > would be left won't cause issues. If this works, the logic that would
> > solve Ryzen DMA fixes will be contained into a single point, making
> > easier to maintain it.
> >  
> > >
> > > Just in case this is of interest, I neither have Ryzen nor Intel, but an 
> > > HP Microserver G7 with an AMD Turion II Neo  N54L, so the machine is more 
> > > on the slow side.  
> >
> > Good to know. It would probably worth to check if this Ryzen
> > bug occors with all versions of it or with just a subset.
> > I mean: maybe it is only at the first gen or Ryzen and doesn't
> > affect Ryzen 2 (or vice versa).  
> 
> The original commit also mentions some Xeons are affected too.  Seems
> like this is potentially an issue on the device side rather than the
> platform.

Maybe.

> >
> > The PCI quirks logic will likely need to detect the PCI ID of
> > the memory controllers found at the buggy CPUs, in order to enable
> > the quirk only for the affected ones.
> >
> > It could be worth talking with AMD people in order to be sure about
> > the differences at the DMA engine side.
> >  
> 
> It's not clear to me what the pci or platform quirk would do.  The
> workaround seems to be in the driver, not on the platform.

Yeah, the fix should be at the driver, but pci/quirk.c would be able
to detect memory controllers that would require a hack inside the
driver, in a similar way to what the media PCI drivers already do
for DMA controllers that don't support pci2pci transfers.

There, basically the PCI core (drivers/pci/pci.c and 
drivers/pci/quirks.c) sets a flag (pci_pci_problems) indicating
potential issues.

Then, the driver compares such flag in order to enable the specific quirk.

Ok, there would be a different way to handle it. The driver could use a 
logic similar to the one I wrote for drivers/edac/i7core_edac.c. There,
the logic seeks for some specific PCI device IDs using pci_get_device(),
adjusting the code accordingly, depending on the detected PCI devices.

In other words, running something like this (untested), at probe time should
produce similar results:

/*
 * FIXME: It probably makes sense to also be able to identify specific
 * versions of the same PCI ID, just in case a latter stepping got a
 * fix for the issue.
 */
const static struct {
int vendor, dev;
} broken_dev_id[] = {
PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_foo,
PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_bar,
},

bool cx23885_does_dma_require_reset(void) 
{
int i;
struct pci_dev *pdev = NULL;

for (i = 0; i < sizeof(broken_dev_id); i++) {
pdev = pci_get_device(broken_dev_id[i].vendor, 
broken_dev_id[i].dev, NULL);
if (pdev) {
pci_put_device(pdev);
return true;
}
}
return false;
}

Should work. In any case, we need to know what memory controllers 
have problems, and what are their PCI IDs, and add them (if not there yet)
at include/linux/pci_ids.h

Thanks,
Mauro

Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

[Mauro Carvalho Chehab]

Em Thu, 06 Dec 2018 18:18:23 +0100
Markus Dobel  escreveu:

> Hi everyone,
> 
> I will try if the hack mentioned fixes the issue for me on the weekend (but I 
> assume, as if effectively removes the function).

It should, but it keeps a few changes. Just want to be sure that what
would be left won't cause issues. If this works, the logic that would
solve Ryzen DMA fixes will be contained into a single point, making
easier to maintain it.

> 
> Just in case this is of interest, I neither have Ryzen nor Intel, but an HP 
> Microserver G7 with an AMD Turion II Neo  N54L, so the machine is more on the 
> slow side. 

Good to know. It would probably worth to check if this Ryzen
bug occors with all versions of it or with just a subset.
I mean: maybe it is only at the first gen or Ryzen and doesn't
affect Ryzen 2 (or vice versa).

The PCI quirks logic will likely need to detect the PCI ID of
the memory controllers found at the buggy CPUs, in order to enable
the quirk only for the affected ones.

It could be worth talking with AMD people in order to be sure about
the differences at the DMA engine side.

Thanks,
Mauro

[PATCH v2] media: rockchip vpu: remove some unused vars

[Mauro Carvalho Chehab]

As complained by gcc:

drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c: In 
function 'rk3288_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10: 
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
  __be32 *chroma_qtable_p;
  ^~~
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10: 
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
  __be32 *luma_qtable_p;
  ^
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c: In 
function 'rk3399_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10: 
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
  __be32 *chroma_qtable_p;
  ^~~
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10: 
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
  __be32 *luma_qtable_p;
  ^
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function 
'rockchip_vpu_queue_setup':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:522:33: warning: 
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
  const struct rockchip_vpu_fmt *vpu_fmt;
 ^~~
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function 
'rockchip_vpu_buf_prepare':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:560:33: warning: 
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
  const struct rockchip_vpu_fmt *vpu_fmt;
 ^~~

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -
 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 5 -
 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c   | 6 --
 3 files changed, 16 deletions(-)

diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c 
b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
index e27c10855de5..5282236d1bb1 100644
--- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
@@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
   unsigned char *luma_qtable,
   unsigned char *chroma_qtable)
 {
-   __be32 *luma_qtable_p;
-   __be32 *chroma_qtable_p;
u32 reg, i;
 
-   luma_qtable_p = (__be32 *)luma_qtable;
-   chroma_qtable_p = (__be32 *)chroma_qtable;
-
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c 
b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
index 5f75e4d11d76..dbc86d95fe3b 100644
--- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
@@ -97,13 +97,8 @@ rk3399_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
   unsigned char *luma_qtable,
   unsigned char *chroma_qtable)
 {
-   __be32 *luma_qtable_p;
-   __be32 *chroma_qtable_p;
u32 reg, i;
 
-   luma_qtable_p = (__be32 *)luma_qtable;
-   chroma_qtable_p = (__be32 *)chroma_qtable;
-
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c 
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
index 038a7136d5d1..ab0fb2053620 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
@@ -519,17 +519,14 @@ rockchip_vpu_queue_setup(struct vb2_queue *vq,
 struct device *alloc_devs[])
 {
struct rockchip_vpu_ctx *ctx = vb2_get_drv_priv(vq);
-   const struct rockchip_vpu_fmt *vpu_fmt;
struct v4l2_pix_format_mplane *pixfmt;
int i;
 
switch (vq->type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
-   vpu_fmt = ctx->vpu_dst_fmt;
pixfmt = >dst_fmt;
break;
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
-   vpu_fmt = ctx->vpu_src_fmt;
pixfmt = >src_fmt;
break;
default:
@@ -557,7 +554,6 @@ static int rockchip_vpu_buf_prepare(struct vb2_buffer *vb)
struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffe

[PATCH] media: rockchip vpu: remove some unused vars

[Mauro Carvalho Chehab]

As complained by gcc:

drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c: In 
function 'rk3288_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10: 
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
  __be32 *chroma_qtable_p;
  ^~~
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10: 
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
  __be32 *luma_qtable_p;
  ^
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c: In 
function 'rk3399_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10: 
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
  __be32 *chroma_qtable_p;
  ^~~
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10: 
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
  __be32 *luma_qtable_p;
  ^
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function 
'rockchip_vpu_queue_setup':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:522:33: warning: 
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
  const struct rockchip_vpu_fmt *vpu_fmt;
 ^~~
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function 
'rockchip_vpu_buf_prepare':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:560:33: warning: 
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
  const struct rockchip_vpu_fmt *vpu_fmt;
 ^~~

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c 
b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
index e27c10855de5..5282236d1bb1 100644
--- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
@@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
   unsigned char *luma_qtable,
   unsigned char *chroma_qtable)
 {
-   __be32 *luma_qtable_p;
-   __be32 *chroma_qtable_p;
u32 reg, i;
 
-   luma_qtable_p = (__be32 *)luma_qtable;
-   chroma_qtable_p = (__be32 *)chroma_qtable;
-
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
-- 
2.19.1

Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver

[Mauro Carvalho Chehab]

Em Wed, 05 Dec 2018 17:02:46 -0300
Ezequiel Garcia  escreveu:

> On Wed, 2018-12-05 at 16:37 -0200, Mauro Carvalho Chehab wrote:
> > Em Wed, 5 Dec 2018 16:34:04 -0200
> > Mauro Carvalho Chehab  escreveu:
> >   
> > > Em Wed, 5 Dec 2018 17:29:38 +0100
> > > Hans Verkuil  escreveu:
> > >   
> > > > Note regarding the first 'Revert' patch: that is this patch:
> > > > 
> > > > https://patchwork.linuxtv.org/patch/52869/
> > > > 
> > > > It is currently pending for 4.20 as a fix, but since it is not merged 
> > > > upstream
> > > > yet, our master branch still has those old bindings.
> > > > 
> > > > I decided to first apply the Revert patch, then add the new patch on 
> > > > top.
> > > > 
> > > > Regards,
> > > > 
> > > > Hans
> > > > 
> > > > The following changes since commit 
> > > > da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> > > > 
> > > >   media: v4l2: async: remove locking when initializing async notifier 
> > > > (2018-12-05 06:51:28 -0500)
> > > > 
> > > > are available in the Git repository at:
> > > > 
> > > >   git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> > > > 
> > > > for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> > > > 
> > > >   media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 
> > > > +0100)
> > > > 
> > > > 
> > > > Tag branch
> > > > 
> > > > 
> > > > Ezequiel Garcia (3):
> > > >   Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> > > >   media: dt-bindings: Document the Rockchip VPU bindings
> > > >   media: add Rockchip VPU JPEG encoder driver
> > > 
> > > Checkpatch produces a few warnings:
> > > 
> > > # CHECK: Alignment should match open parenthesis
> > > # #385: FILE: 
> > > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
> > > # +   rk3288_vpu_jpeg_enc_set_qtable(vpu,
> > > # +   rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > > # 
> > > # CHECK: Alignment should match open parenthesis
> > > # #1124: FILE: 
> > > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
> > > # +   rk3399_vpu_jpeg_enc_set_qtable(vpu,
> > > # +   rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > > # 
> > > # WARNING: DT compatible string "rockchip,rk3399-vpu" appears 
> > > un-documented -- check ./Documentation/devicetree/bindings/
> > > # #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
> > > # +   { .compatible = "rockchip,rk3399-vpu", .data = 
> > > _vpu_variant, },
> > > # 
> > > # WARNING: DT compatible string "rockchip,rk3288-vpu" appears 
> > > un-documented -- check ./Documentation/devicetree/bindings/
> > > # #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
> > > # +   { .compatible = "rockchip,rk3288-vpu", .data = 
> > > _vpu_variant, },
> > > # 
> > > # CHECK: Unnecessary parentheses around 'formats[i].codec_mode != 
> > > RK_VPU_MODE_NONE'
> > > # #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
> > > # +   if (bitstream == (formats[i].codec_mode != 
> > > RK_VPU_MODE_NONE))
> > > # 
> > > # total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
> > >   
> 
> Please note that this last one is a false positive,
> the code needs those parenthesis.

Yes, I know. that "Unnecessary parentheses" warning should always be
taken with caution.

I've seen several cases where it was right, but, for the sake of a
better code readability, it was better to preserve it.

Thanks,
Mauro

Re: [PATCH] media: rockchip/vpu: fix a few alignments

[Mauro Carvalho Chehab]

Em Wed, 5 Dec 2018 19:48:25 +0100
Hans Verkuil  escreveu:

> On 12/05/2018 07:43 PM, Mauro Carvalho Chehab wrote:
> > As reported by checkpatch.pl, some function calls have a wrong
> > alignment.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 4 ++--
> >  drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 4 ++--
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c 
> > b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> > index 8919151e1631..e27c10855de5 100644
> > --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> > +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> > @@ -106,8 +106,8 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx 
> > *ctx)
> > rk3288_vpu_set_src_img_ctrl(vpu, ctx);
> > rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf);
> > rk3288_vpu_jpeg_enc_set_qtable(vpu,
> > -   rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > -   rockchip_vpu_jpeg_get_qtable(_ctx, 1));
> > +  rockchip_vpu_jpeg_get_qtable(_ctx, 
> > 0),
> > +  rockchip_vpu_jpeg_get_qtable(_ctx, 
> > 1));  
> 
> But now you get warnings because this is > 80 columns.
> 
> I think the 'cure' is worse than the disease.
> 
> I see this is already merged, but I don't think this patch improves 
> readability,
> which is more important than a checkpatch warning IMHO.

IMHO, it is a way more readable if things got aligned. Very very few
people nowadays (if any) write patches directly at a 80 columns console.

Btw, speaking about 80 cols, usually your commit messages are longer
than that (the limit is actually 80 cols - 4). I keep fixing the
corresponding checkpatch.pl warnings from your patches
(when I have time) :-)

> 
> Regards,
> 
>   Hans
> 
> >  
> > reg = VEPU_REG_AXI_CTRL_OUTPUT_SWAP16
> > | VEPU_REG_AXI_CTRL_INPUT_SWAP16
> > diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c 
> > b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> > index 8afa2162bf9f..5f75e4d11d76 100644
> > --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> > +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> > @@ -137,8 +137,8 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx 
> > *ctx)
> > rk3399_vpu_set_src_img_ctrl(vpu, ctx);
> > rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf);
> > rk3399_vpu_jpeg_enc_set_qtable(vpu,
> > -   rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > -   rockchip_vpu_jpeg_get_qtable(_ctx, 1));
> > +  rockchip_vpu_jpeg_get_qtable(_ctx, 
> > 0),
> > +  rockchip_vpu_jpeg_get_qtable(_ctx, 
> > 1));
> >  
> > reg = VEPU_REG_OUTPUT_SWAP32
> > | VEPU_REG_OUTPUT_SWAP16
> >   
> 



Thanks,
Mauro

Re: [PATCH 2/3] media: stkwebcam: Bugfix for not correctly initialized camera

[Mauro Carvalho Chehab]

Em Wed, 5 Dec 2018 16:56:39 -0200
Mauro Carvalho Chehab  escreveu:

> Em Fri, 30 Nov 2018 15:58:07 +0100
> Andreas Pape  escreveu:
> 
> > Hi Kieran,
> > 
> > thanks for the review.
> > 
> > On Mon, 26 Nov 2018 12:48:08 +
> > Kieran Bingham  wrote:
> > 
> > > This one worries me a little... (but hopefully not too much)
> > >  
> > 
> > As mentioned, I don't have any experience concerning video drivers;-). I 
> > found
> > this patch more or less experimentally
> >  
> > >   
> > > > Signed-off-by: Andreas Pape 
> > > > ---
> > > >  drivers/media/usb/stkwebcam/stk-webcam.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c 
> > > > b/drivers/media/usb/stkwebcam/stk-webcam.c
> > > > index e61427e50525..c64928e36a5a 100644
> > > > --- a/drivers/media/usb/stkwebcam/stk-webcam.c
> > > > +++ b/drivers/media/usb/stkwebcam/stk-webcam.c
> > > > @@ -1155,6 +1155,8 @@ static int stk_vidioc_streamon(struct file *filp,
> > > > if (dev->sio_bufs == NULL)
> > > > return -EINVAL;
> > > > dev->sequence = 0;
> > > > +   stk_initialise(dev);
> > > > +   stk_setup_format(dev);  
> > > 
> > > Glancing through the code base - this seems to imply to me that s_fmt
> > > was not set/called (presumably by cheese) as stk_setup_format() is
> > > called only by stk_vidioc_s_fmt_vid_cap() and stk_camera_resume().
> > > 
> > > Is this an issue?
> > > 
> > > I presume that this means the camera will just operate in a default
> > > configuration until cheese chooses something more specific.
> > >  
> > 
> > Could be. I had a video but colours, sensitivity and possibly other things
> > were crap or at least very "psychedelic". Therefore the idea came up that
> > some kind of initialisation was missing here. 
> > 
> > > Actually - looking further this seems to be the case, as the mode is
> > > simply stored in dev->vsettings.mode, and so this last setup stage will
> > > just ensure the configuration of the hardware matches the driver.
> > > 
> > > So it seems reasonable to me - but should it be set any earlier?
> > > Perhaps not.
> > > 
> > > 
> > > Are there any complaints when running v4l2-compliance on this device node?
> > >   
> > 
> > Here is the output of v4l2-compliance:
> > 
> > v4l2-compliance SHA   : not available
> > 
> > Driver Info:
> > Driver name   : stk
> > Card type : stk
> > Bus info  : usb-:00:1d.7-5
> > Driver version: 4.15.18
> > Capabilities  : 0x8521
> > Video Capture
> > Read/Write
> > Streaming
> > Extended Pix Format
> > Device Capabilities
> > Device Caps   : 0x0521
> > Video Capture
> > Read/Write
> > Streaming
> > Extended Pix Format
> > 
> > Compliance test for device /dev/video0 (not using libv4l2):
> > 
> > Required ioctls:
> > test VIDIOC_QUERYCAP: OK
> > 
> > Allow for multiple opens:
> > test second video open: OK
> > test VIDIOC_QUERYCAP: OK
> > test VIDIOC_G/S_PRIORITY: OK
> > test for unlimited opens: OK
> > 
> > Debug ioctls:
> > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> > 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
> > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > Inputs: 1 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_

Re: [PATCH 2/3] media: stkwebcam: Bugfix for not correctly initialized camera

[Mauro Carvalho Chehab]

Em Fri, 30 Nov 2018 15:58:07 +0100
Andreas Pape  escreveu:

> Hi Kieran,
> 
> thanks for the review.
> 
> On Mon, 26 Nov 2018 12:48:08 +
> Kieran Bingham  wrote:
> 
> > This one worries me a little... (but hopefully not too much)
> >  
> 
> As mentioned, I don't have any experience concerning video drivers;-). I found
> this patch more or less experimentally
>  
> >   
> > > Signed-off-by: Andreas Pape 
> > > ---
> > >  drivers/media/usb/stkwebcam/stk-webcam.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c 
> > > b/drivers/media/usb/stkwebcam/stk-webcam.c
> > > index e61427e50525..c64928e36a5a 100644
> > > --- a/drivers/media/usb/stkwebcam/stk-webcam.c
> > > +++ b/drivers/media/usb/stkwebcam/stk-webcam.c
> > > @@ -1155,6 +1155,8 @@ static int stk_vidioc_streamon(struct file *filp,
> > >   if (dev->sio_bufs == NULL)
> > >   return -EINVAL;
> > >   dev->sequence = 0;
> > > + stk_initialise(dev);
> > > + stk_setup_format(dev);  
> > 
> > Glancing through the code base - this seems to imply to me that s_fmt
> > was not set/called (presumably by cheese) as stk_setup_format() is
> > called only by stk_vidioc_s_fmt_vid_cap() and stk_camera_resume().
> > 
> > Is this an issue?
> > 
> > I presume that this means the camera will just operate in a default
> > configuration until cheese chooses something more specific.
> >  
> 
> Could be. I had a video but colours, sensitivity and possibly other things
> were crap or at least very "psychedelic". Therefore the idea came up that
> some kind of initialisation was missing here. 
> 
> > Actually - looking further this seems to be the case, as the mode is
> > simply stored in dev->vsettings.mode, and so this last setup stage will
> > just ensure the configuration of the hardware matches the driver.
> > 
> > So it seems reasonable to me - but should it be set any earlier?
> > Perhaps not.
> > 
> > 
> > Are there any complaints when running v4l2-compliance on this device node?
> >   
> 
> Here is the output of v4l2-compliance:
> 
> v4l2-compliance SHA   : not available
> 
> Driver Info:
>   Driver name   : stk
>   Card type : stk
>   Bus info  : usb-:00:1d.7-5
>   Driver version: 4.15.18
>   Capabilities  : 0x8521
>   Video Capture
>   Read/Write
>   Streaming
>   Extended Pix Format
>   Device Capabilities
>   Device Caps   : 0x0521
>   Video Capture
>   Read/Write
>   Streaming
>   Extended Pix Format
> 
> Compliance test for device /dev/video0 (not using libv4l2):
> 
> Required ioctls:
>   test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
>   test second video open: OK
>   test VIDIOC_QUERYCAP: OK
>   test VIDIOC_G/S_PRIORITY: OK
>   test for unlimited opens: OK
> 
> Debug ioctls:
>   test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>   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
>   test VIDIOC_G/S_AUDIO: OK (Not Supported)
>   Inputs: 1 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 (Not Supported)
>   test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>   test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Test input 0:
> 
>   Control ioctls:
>   test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
>   test VIDIOC_QUERYCTRL: OK
>   test VIDIOC_G/S_CTRL: OK
>   test VIDIOC_G/S/TRY_EXT_CTRLS: OK
>   test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
>   test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>   Standard Controls: 4 Private Controls: 0
> 
>   Format ioctls:
>   test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>   test VIDIOC_G/S_PARM: OK
>   test VIDIOC_G_FBUF: OK (Not Supported)
>   test VIDIOC_G_FMT: OK
>   warn: v4l2-test-formats.cpp(732): TRY_FMT cannot handle an 
> invalid pixelformat.
>   warn: v4l2-test-formats.cpp(733): This may or may not be a 
> problem. For more information see:
>   warn: v4l2-test-formats.cpp(734): 
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html
>   test 

[PATCH] media: rockchip/vpu: fix a few alignments

[Mauro Carvalho Chehab]

As reported by checkpatch.pl, some function calls have a wrong
alignment.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 4 ++--
 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c 
b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
index 8919151e1631..e27c10855de5 100644
--- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
@@ -106,8 +106,8 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
rk3288_vpu_set_src_img_ctrl(vpu, ctx);
rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf);
rk3288_vpu_jpeg_enc_set_qtable(vpu,
-   rockchip_vpu_jpeg_get_qtable(_ctx, 0),
-   rockchip_vpu_jpeg_get_qtable(_ctx, 1));
+  rockchip_vpu_jpeg_get_qtable(_ctx, 
0),
+  rockchip_vpu_jpeg_get_qtable(_ctx, 
1));
 
reg = VEPU_REG_AXI_CTRL_OUTPUT_SWAP16
| VEPU_REG_AXI_CTRL_INPUT_SWAP16
diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c 
b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
index 8afa2162bf9f..5f75e4d11d76 100644
--- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
@@ -137,8 +137,8 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
rk3399_vpu_set_src_img_ctrl(vpu, ctx);
rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf);
rk3399_vpu_jpeg_enc_set_qtable(vpu,
-   rockchip_vpu_jpeg_get_qtable(_ctx, 0),
-   rockchip_vpu_jpeg_get_qtable(_ctx, 1));
+  rockchip_vpu_jpeg_get_qtable(_ctx, 
0),
+  rockchip_vpu_jpeg_get_qtable(_ctx, 
1));
 
reg = VEPU_REG_OUTPUT_SWAP32
| VEPU_REG_OUTPUT_SWAP16
-- 
2.19.1

Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver

[Mauro Carvalho Chehab]

Em Wed, 5 Dec 2018 16:34:04 -0200
Mauro Carvalho Chehab  escreveu:

> Em Wed, 5 Dec 2018 17:29:38 +0100
> Hans Verkuil  escreveu:
> 
> > Note regarding the first 'Revert' patch: that is this patch:
> > 
> > https://patchwork.linuxtv.org/patch/52869/
> > 
> > It is currently pending for 4.20 as a fix, but since it is not merged 
> > upstream
> > yet, our master branch still has those old bindings.
> > 
> > I decided to first apply the Revert patch, then add the new patch on top.
> > 
> > Regards,
> > 
> > Hans
> > 
> > The following changes since commit da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> > 
> >   media: v4l2: async: remove locking when initializing async notifier 
> > (2018-12-05 06:51:28 -0500)
> > 
> > are available in the Git repository at:
> > 
> >   git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> > 
> > for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> > 
> >   media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100)
> > 
> > 
> > Tag branch
> > 
> > 
> > Ezequiel Garcia (3):
> >   Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> >   media: dt-bindings: Document the Rockchip VPU bindings
> >   media: add Rockchip VPU JPEG encoder driver  
> 
> Checkpatch produces a few warnings:
> 
> # CHECK: Alignment should match open parenthesis
> # #385: FILE: drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
> # +   rk3288_vpu_jpeg_enc_set_qtable(vpu,
> # +   rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> # 
> # CHECK: Alignment should match open parenthesis
> # #1124: FILE: 
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
> # +   rk3399_vpu_jpeg_enc_set_qtable(vpu,
> # +   rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> # 
> # WARNING: DT compatible string "rockchip,rk3399-vpu" appears un-documented 
> -- check ./Documentation/devicetree/bindings/
> # #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
> # +   { .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, },
> # 
> # WARNING: DT compatible string "rockchip,rk3288-vpu" appears un-documented 
> -- check ./Documentation/devicetree/bindings/
> # #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
> # +   { .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, },
> # 
> # CHECK: Unnecessary parentheses around 'formats[i].codec_mode != 
> RK_VPU_MODE_NONE'
> # #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
> # +   if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
> # 
> # total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
> 
> The more weird ones are the ones related to the DT bindings.

Hmm... those were my fault.

/me needs caffeine

> 
> Regards,
> Mauro
> 
> Thanks,
> Mauro



Thanks,
Mauro

Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver

[Mauro Carvalho Chehab]

Em Wed, 5 Dec 2018 17:29:38 +0100
Hans Verkuil  escreveu:

> Note regarding the first 'Revert' patch: that is this patch:
> 
> https://patchwork.linuxtv.org/patch/52869/
> 
> It is currently pending for 4.20 as a fix, but since it is not merged upstream
> yet, our master branch still has those old bindings.
> 
> I decided to first apply the Revert patch, then add the new patch on top.
> 
> Regards,
> 
>   Hans
> 
> The following changes since commit da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> 
>   media: v4l2: async: remove locking when initializing async notifier 
> (2018-12-05 06:51:28 -0500)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> 
> for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> 
>   media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100)
> 
> 
> Tag branch
> 
> 
> Ezequiel Garcia (3):
>   Revert "media: dt-bindings: Document the Rockchip VPU bindings"
>   media: dt-bindings: Document the Rockchip VPU bindings
>   media: add Rockchip VPU JPEG encoder driver

Checkpatch produces a few warnings:

# CHECK: Alignment should match open parenthesis
# #385: FILE: drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
# + rk3288_vpu_jpeg_enc_set_qtable(vpu,
# + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
# 
# CHECK: Alignment should match open parenthesis
# #1124: FILE: drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
# + rk3399_vpu_jpeg_enc_set_qtable(vpu,
# + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
# 
# WARNING: DT compatible string "rockchip,rk3399-vpu" appears un-documented -- 
check ./Documentation/devicetree/bindings/
# #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
# + { .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, },
# 
# WARNING: DT compatible string "rockchip,rk3288-vpu" appears un-documented -- 
check ./Documentation/devicetree/bindings/
# #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
# + { .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, },
# 
# CHECK: Unnecessary parentheses around 'formats[i].codec_mode != 
RK_VPU_MODE_NONE'
# #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
# + if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
# 
# total: 0 errors, 2 warnings, 3 checks, 3469 lines checked

The more weird ones are the ones related to the DT bindings.

Regards,
Mauro

Thanks,
Mauro

Re: [PATCH v2 1/1] media: Add a Kconfig option for the Request API

[Mauro Carvalho Chehab]

Em Wed,  5 Dec 2018 19:23:54 +0200
Sakari Ailus  escreveu:

> The Request API is now merged to the kernel but the confidence on the
> stability of that API is not great, especially regarding the interaction
> with V4L2.
> 
> Add a Kconfig option for the API, with a scary-looking warning.
> 
> The patch itself disables request creation as well as does not advertise
> them as buffer flags. The driver requiring requests (cedrus) now depends
> on the Kconfig option as well.
> 
> Signed-off-by: Sakari Ailus 
> Acked-by: Hans Verkuil 

Looks good to me. I'll apply it.

> ---
> since v1:
> 
> - Write out the #ifdef's in request creation
> 
> - The option's functionality was reversed in request creation, fixed that
> 
>  drivers/media/Kconfig   | 13 +
>  drivers/media/common/videobuf2/videobuf2-v4l2.c |  2 ++
>  drivers/media/media-device.c|  4 
>  drivers/staging/media/sunxi/cedrus/Kconfig  |  1 +
>  4 files changed, 20 insertions(+)
> 
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index 8add62a18293..102eb35fcf3f 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -110,6 +110,19 @@ config MEDIA_CONTROLLER_DVB
>  
> This is currently experimental.
>  
> +config MEDIA_CONTROLLER_REQUEST_API
> + bool "Enable Media controller Request API (EXPERIMENTAL)"
> + depends on MEDIA_CONTROLLER && STAGING_MEDIA
> + default n
> + ---help---
> +   DO NOT ENABLE THIS OPTION UNLESS YOU KNOW WHAT YOU'RE DOING.
> +
> +   This option enables the Request API for the Media controller and V4L2
> +   interfaces. It is currently needed by a few stateless codec drivers.
> +
> +   There is currently no intention to provide API or ABI stability for
> +   this new API as of yet.
> +
>  #
>  # Video4Linux support
>  #Only enables if one of the V4L2 types (ATV, webcam, radio) is selected
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 1244c246d0c4..83c3c0c49e56 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -630,8 +630,10 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
>   *caps |= V4L2_BUF_CAP_SUPPORTS_USERPTR;
>   if (q->io_modes & VB2_DMABUF)
>   *caps |= V4L2_BUF_CAP_SUPPORTS_DMABUF;
> +#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
>   if (q->supports_requests)
>   *caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
> +#endif
>  }
>  
>  int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index bed24372e61f..b8ec88612df7 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -381,10 +381,14 @@ static long media_device_get_topology(struct 
> media_device *mdev, void *arg)
>  static long media_device_request_alloc(struct media_device *mdev,
>  int *alloc_fd)
>  {
> +#ifdef CONFIG_MEDIA_CONTROLLER_REQUEST_API
>   if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
>   return -ENOTTY;
>  
>   return media_request_alloc(mdev, alloc_fd);
> +#else
> + return -ENOTTY;
> +#endif
>  }
>  
>  static long copy_arg_from_user(void *karg, void __user *uarg, unsigned int 
> cmd)
> diff --git a/drivers/staging/media/sunxi/cedrus/Kconfig 
> b/drivers/staging/media/sunxi/cedrus/Kconfig
> index a7a34e89c42d..3252efa422f9 100644
> --- a/drivers/staging/media/sunxi/cedrus/Kconfig
> +++ b/drivers/staging/media/sunxi/cedrus/Kconfig
> @@ -3,6 +3,7 @@ config VIDEO_SUNXI_CEDRUS
>   depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
>   depends on HAS_DMA
>   depends on OF
> + depends on MEDIA_CONTROLLER_REQUEST_API
>   select SUNXI_SRAM
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_MEM2MEM_DEV



Thanks,
Mauro

Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

[Mauro Carvalho Chehab]

Em Sun, 21 Oct 2018 15:45:39 +0200
Markus Dobel  escreveu:

> The original commit (the one reverted in this patch) introduced a 
> regression,
> making a previously flawless adapter unresponsive after running a few 
> hours
> to days. Since I never experienced the problems that the original commit 
> is
> supposed to fix, I propose to revert the change until a regression-free
> variant is found.
> 
> Before submitting this, I've been running a system 24x7 with this revert 
> for
> several weeks now, and it's running stable again.
> 
> It's not a pure revert, as the original commit does not revert cleanly
> anymore due to other changes, but content-wise it is.
> 
> Signed-off-by: Markus Dobel 
> ---
>   drivers/media/pci/cx23885/cx23885-core.c | 60 
>   drivers/media/pci/cx23885/cx23885-reg.h  | 14 --
>   2 files changed, 74 deletions(-)
> 
> diff --git a/drivers/media/pci/cx23885/cx23885-core.c 
> b/drivers/media/pci/cx23885/cx23885-core.c
> index 39804d830305..606f6fc0e68b 100644
> --- a/drivers/media/pci/cx23885/cx23885-core.c
> +++ b/drivers/media/pci/cx23885/cx23885-core.c
> @@ -601,25 +601,6 @@ static void cx23885_risc_disasm(struct 
> cx23885_tsport *port,

Patch was mangled by your e-mailer: it broke longer lines, causing
it to not apply.

Also, before just reverting the entire thing, could you please check
if the enclosed hack would solve it?

If so, it should be easy to add a quirk at drivers/pci/quirks.c
in order to detect the Ryzen models with a bad DMA engine that
require periodic resets, and then make cx23885 to use it.

We did similar tricks before with some broken DMA engines, at
the time we had overlay support on drivers and AMD controllers
didn't support PCI2PCI DMA transfers.

Brad,

Could you please address this issue?


diff --git a/drivers/media/pci/cx23885/cx23885-core.c 
b/drivers/media/pci/cx23885/cx23885-core.c
index 39804d830305..8b012bee6b32 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -603,8 +603,14 @@ static void cx23885_risc_disasm(struct cx23885_tsport 
*port,
 
 static void cx23885_clear_bridge_error(struct cx23885_dev *dev)
 {
-   uint32_t reg1_val = cx_read(TC_REQ); /* read-only */
-   uint32_t reg2_val = cx_read(TC_REQ_SET);
+   uint32_t reg1_val, reg2_val;
+
+   /* TODO: check for Ryzen quirk */
+   if (1)
+   return;
+
+   reg1_val = cx_read(TC_REQ); /* read-only */
+   reg2_val = cx_read(TC_REQ_SET);
 
if (reg1_val && reg2_val) {
cx_write(TC_REQ, reg1_val);



Thanks,
Mauro

[PATCH] media: ddbridge: remove another duplicate of io.h and sort includes

[Mauro Carvalho Chehab]

The io.h was still included twice. Having a large number of
includes like that unsorted is likely the reason why we ended
by having 3 includes of io.h and two includes of interrupt.h
at the first place.

So, let's reorder the includes on alphabetic order. That would
make easier to maintain it.

Fixes: 12645e0655e4 ("media: ddbridge: remove some duplicated include file")
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/pci/ddbridge/ddbridge.h | 52 +--
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge.h 
b/drivers/media/pci/ddbridge/ddbridge.h
index 27b46fe704cd..0be6ed216e65 100644
--- a/drivers/media/pci/ddbridge/ddbridge.h
+++ b/drivers/media/pci/ddbridge/ddbridge.h
@@ -18,45 +18,43 @@
 #ifndef _DDBRIDGE_H_
 #define _DDBRIDGE_H_
 
-#include 
-#include 
+#include 
+#include 
+
+#include 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
+#include 
+#include 
 #include 
-#include 
-#include 
-
+#include 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
-
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
 
 #include 
-#include 
+#include 
 #include 
+#include 
 #include 
-#include 
-#include 
 #include 
+#include 
 
 #define DDBRIDGE_VERSION "0.9.33-integrated"
 
-- 
2.19.1

Re: [PATCH v3 0/9] TVP5150 fixes and new features

[Mauro Carvalho Chehab]

Hi Marco,

Em Fri, 9 Nov 2018 14:46:24 +0100
Marco Felsch  escreveu:

> Hi Mauro,
> 
> I don't want to spam you. Can you give me some feedback? I know the
> merge window is a busy time, so maybe you have some time now.

Sorry for taking so long on looking into it... has been really busy
those days :-(

I applied patch 2/9. Patch 3 doesn't apply. Would you mind
rebasing it on the top of upstream? there are some non-trivial
conflicts (perhaps I just missed some other preparation patch?).

I suspect that it would be easier if you could rebase your tree
on the top of the latest upstream one, e. g.:

git://linuxtv.org/media_tree.git

(master branch)

Regards,
Mauro
> 
> Regards,
> Marco
> 
> On 18-10-29 19:41, Marco Felsch wrote:
> > Hi Mauro,
> > 
> > just a reminder, Rob already added his ack/rev-by tags.
> > 
> > Thanks,
> > Marco
> > 
> > On 18-09-18 15:14, Marco Felsch wrote:  
> > > Hi,
> > > 
> > > this is my v3 with the integrated reviews from my v2 [1]. This serie
> > > applies to Mauro's experimental.git [2].
> > > 
> > > @Mauro:
> > > Patch ("media: tvp5150: fix irq_request error path during probe") is new
> > > in this series. Maybe you can squash them with ("media: tvp5150: Add sync 
> > > lock
> > > interrupt handling"), thanks.
> > > 
> > > I've tested this series on a customer dt-based board. Unfortunately I
> > > haven't a device which use the em28xx driver. So other tester a welcome :)
> > > 
> > > [1] https://www.spinics.net/lists/devicetree/msg244129.html
> > > [2] https://git.linuxtv.org/mchehab/experimental.git/log/?h=tvp5150-4
> > > 
> > > Javier Martinez Canillas (1):
> > >   partial revert of "[media] tvp5150: add HW input connectors support"
> > > 
> > > Marco Felsch (7):
> > >   media: tvp5150: fix irq_request error path during probe
> > >   media: tvp5150: add input source selection of_graph support
> > >   media: dt-bindings: tvp5150: Add input port connectors DT bindings
> > >   media: v4l2-subdev: add stubs for v4l2_subdev_get_try_*
> > >   media: v4l2-subdev: fix v4l2_subdev_get_try_* dependency
> > >   media: tvp5150: add FORMAT_TRY support for get/set selection handlers
> > >   media: tvp5150: add s_power callback
> > > 
> > > Michael Tretter (1):
> > >   media: tvp5150: initialize subdev before parsing device tree
> > > 
> > >  .../devicetree/bindings/media/i2c/tvp5150.txt |  92 ++-
> > >  drivers/media/i2c/tvp5150.c   | 657 +-
> > >  include/dt-bindings/media/tvp5150.h   |   2 -
> > >  include/media/v4l2-subdev.h   |  15 +-
> > >  4 files changed, 584 insertions(+), 182 deletions(-)
> > > 
> > > -- 
> > > 2.19.0
> > > 
> > > 
> > >   
> > 
> > -- 
> > Pengutronix e.K.   | |
> > Industrial Linux Solutions | http://www.pengutronix.de/  |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> > Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
> > 
> >   
> 



Thanks,
Mauro

Re: [PATCH 1/4] libdvbv5: do not adjust DVB time daylight saving

[Mauro Carvalho Chehab]

Em Sat,  7 Jul 2018 13:20:54 +0200
André Roth  escreveu:

> This makes dvb_time available outside of EIT parsing, and
> struct tm to reflect the actual values received from DVB.
> 
> Signed-off-by: André Roth 
> ---
>  lib/include/libdvbv5/descriptors.h | 11 +++
>  lib/include/libdvbv5/eit.h | 10 --
>  lib/libdvbv5/descriptors.c | 37 +
>  lib/libdvbv5/tables/eit.c  | 28 
>  4 files changed, 48 insertions(+), 38 deletions(-)
> 
> diff --git a/lib/include/libdvbv5/descriptors.h 
> b/lib/include/libdvbv5/descriptors.h
> index cb21470c..31f4c73f 100644
> --- a/lib/include/libdvbv5/descriptors.h
> +++ b/lib/include/libdvbv5/descriptors.h
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /**
>   * @brief Maximum size of a table session to be parsed
> @@ -159,6 +160,16 @@ uint32_t dvb_bcd(uint32_t bcd);
>  void dvb_hexdump(struct dvb_v5_fe_parms *parms, const char *prefix,
>const unsigned char *buf, int len);
>  
> +/**
> + * @brief Converts a DVB formatted timestamp into struct tm
> + * @ingroup dvb_table
> + *
> + * @param data   event on DVB time format
> + * @param tm pointer to struct tm where the converted timestamp will
> + *   be stored.
> + */
> +void dvb_time(const uint8_t data[5], struct tm *tm);
> +
>  /**
>   * @brief parse MPEG-TS descriptors
>   * @ingroup dvb_table
> diff --git a/lib/include/libdvbv5/eit.h b/lib/include/libdvbv5/eit.h
> index 9129861e..5af266b1 100644
> --- a/lib/include/libdvbv5/eit.h
> +++ b/lib/include/libdvbv5/eit.h
> @@ -209,16 +209,6 @@ void dvb_table_eit_free(struct dvb_table_eit *table);
>  void dvb_table_eit_print(struct dvb_v5_fe_parms *parms,
>struct dvb_table_eit *table);
>  
> -/**
> - * @brief Converts a DVB EIT formatted timestamp into struct tm
> - * @ingroup dvb_table
> - *
> - * @param data   event on DVB EIT time format
> - * @param tm pointer to struct tm where the converted timestamp will
> - *   be stored.
> - */
> -void dvb_time(const uint8_t data[5], struct tm *tm);
> -

This seems to break the existing ABI.

>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/lib/libdvbv5/descriptors.c b/lib/libdvbv5/descriptors.c
> index 0683dc1b..ccec503c 100644
> --- a/lib/libdvbv5/descriptors.c
> +++ b/lib/libdvbv5/descriptors.c
> @@ -56,6 +56,14 @@
>  #include 
>  #include 
>  
> +#ifdef ENABLE_NLS
> +# include "gettext.h"
> +# include 
> +# define _(string) dgettext(LIBDVBV5_DOMAIN, string)
> +#else
> +# define _(string) string
> +#endif
> +
>  static void dvb_desc_init(uint8_t type, uint8_t length, struct dvb_desc 
> *desc)
>  {
>   desc->type   = type;
> @@ -1391,3 +1399,32 @@ void dvb_hexdump(struct dvb_v5_fe_parms *parms, const 
> char *prefix, const unsign
>   dvb_loginfo("%s%s %s %s", prefix, hex, spaces, ascii);
>   }
>  }
> +
> +void dvb_time(const uint8_t data[5], struct tm *tm)
> +{
> +  /* ETSI EN 300 468 V1.4.1 */
> +  int year, month, day, hour, min, sec;
> +  int k = 0;
> +  uint16_t mjd;
> +
> +  mjd   = *(uint16_t *) data;
> +  hour  = dvb_bcd(data[2]);
> +  min   = dvb_bcd(data[3]);
> +  sec   = dvb_bcd(data[4]);
> +  year  = ((mjd - 15078.2) / 365.25);
> +  month = ((mjd - 14956.1 - (int) (year * 365.25)) / 30.6001);
> +  day   = mjd - 14956 - (int) (year * 365.25) - (int) (month * 30.6001);
> +  if (month == 14 || month == 15) k = 1;
> +  year += k;
> +  month = month - 1 - k * 12;
> +
> +  tm->tm_sec   = sec;
> +  tm->tm_min   = min;
> +  tm->tm_hour  = hour;
> +  tm->tm_mday  = day;
> +  tm->tm_mon   = month - 1;
> +  tm->tm_year  = year;
> +  tm->tm_isdst = -1; /* do not adjust */

It seems that the only real change here is that you replaced 1 by -1 here,
in order for the mktime() to not handle daylight saving time.

Why are you also moving this out of eit.c/eit.h?

> +  mktime( tm );
> +}
> +
> diff --git a/lib/libdvbv5/tables/eit.c b/lib/libdvbv5/tables/eit.c
> index a6ba566a..799e4c9a 100644
> --- a/lib/libdvbv5/tables/eit.c
> +++ b/lib/libdvbv5/tables/eit.c
> @@ -154,34 +154,6 @@ void dvb_table_eit_print(struct dvb_v5_fe_parms *parms, 
> struct dvb_table_eit *ei
>   dvb_loginfo("|_  %d events", events);
>  }
>  
> -void dvb_time(const uint8_t data[5], struct tm *tm)
> -{
> -  /* ETSI EN 300 468 V1.4.1 */
> -  int year, month, day, hour, min, sec;
> -  int k = 0;
> -  uint16_t mjd;
> -
> -  mjd   = *(uint16_t *) data;
> -  hour  = dvb_bcd(data[2]);
> -  min   = dvb_bcd(data[3]);
> -  sec   = dvb_bcd(data[4]);
> -  year  = ((mjd - 15078.2) / 365.25);
> -  month = ((mjd - 14956.1 - (int) (year * 365.25)) / 30.6001);
> -  day   = mjd - 14956 - (int) (year * 365.25) - (int) (month * 30.6001);
> -  if (month == 14 || month == 15) k = 1;
> -  year += k;
> -  month = month - 1 - k * 12;
> -
> -  tm->tm_sec   = sec;
> -  tm->tm_min   = min;
> -  tm->tm_hour  = hour;
> -  tm->tm_mday  = 

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

Re: [PATCH 1/1] v4l uapi: Make "Vertical Colour Bars" menu item a little more generic

[Mauro Carvalho Chehab]

Em Tue, 4 Dec 2018 12:32:32 -0200
Mauro Carvalho Chehab  escreveu:

> Em Tue,  4 Dec 2018 15:45:06 +0200
> Sakari Ailus  escreveu:
> 
> > The test pattern could contain a different number of colour bars than
> > eight, make the entry more useful by removing "Eight " from the name.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  include/uapi/linux/v4l2-controls.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/uapi/linux/v4l2-controls.h 
> > b/include/uapi/linux/v4l2-controls.h
> > index acb2a57fa5d6..88f2759c2ce4 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -1016,7 +1016,7 @@ enum v4l2_jpeg_chroma_subsampling {
> >  #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_VERT_COLOUR_BARS "Eight Vertical Colour Bars"
> > +#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS "Vertical Colour Bars"
> 
> No, we can't do that. This is on an uAPI file.
> 
> We should, instead, create another #define for non-eight vertical
> color bars.
> 
> Before you say, yeah, I agree that we messed this one, as the defined
> name doesn't mention 8 bars...
> 
> I would, instead, do something like:
> 
> -#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS   "Eight Vertical Colour Bars"
> +#define V4L2_TEST_PATTERN_VERT_8_COLOUR_BARS "Eight Vertical Colour Bars"
> +#define V4L2_TEST_PATTERN_VERT_N_COLOUR_BARS "Vertical Colour Bars"
> +
> + /* Kept for backward-compatibility */
> +#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS   
> V4L2_TEST_PATTERN_VERT_8_COLOUR_BARS
> 
> And, of course, update the documentation accordingly.

Please ignore this comment. I didn't realize that those definitions
don't exist yet at the uAPI file, and that this is a follow up for
another patch:

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

Next time, please put them into a patch series, as it makes easier for
reviewers.

Thanks,
Mauro

Re: [PATCH 1/1] v4l uapi: Make "Vertical Colour Bars" menu item a little more generic

[Mauro Carvalho Chehab]

Em Tue,  4 Dec 2018 15:45:06 +0200
Sakari Ailus  escreveu:

> The test pattern could contain a different number of colour bars than
> eight, make the entry more useful by removing "Eight " from the name.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  include/uapi/linux/v4l2-controls.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/v4l2-controls.h 
> b/include/uapi/linux/v4l2-controls.h
> index acb2a57fa5d6..88f2759c2ce4 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -1016,7 +1016,7 @@ enum v4l2_jpeg_chroma_subsampling {
>  #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_VERT_COLOUR_BARS   "Eight Vertical Colour Bars"
> +#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS   "Vertical Colour Bars"

No, we can't do that. This is on an uAPI file.

We should, instead, create another #define for non-eight vertical
color bars.

Before you say, yeah, I agree that we messed this one, as the defined
name doesn't mention 8 bars...

I would, instead, do something like:

-#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS "Eight Vertical Colour Bars"
+#define V4L2_TEST_PATTERN_VERT_8_COLOUR_BARS   "Eight Vertical Colour Bars"
+#define V4L2_TEST_PATTERN_VERT_N_COLOUR_BARS   "Vertical Colour Bars"
+
+ /* Kept for backward-compatibility */
+#define V4L2_TEST_PATTERN_VERT_COLOUR_BARS 
V4L2_TEST_PATTERN_VERT_8_COLOUR_BARS

And, of course, update the documentation accordingly.

>  #define V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY "Colour Bars With 
> Fade to Grey"
>  #define V4L2_TEST_PATTERN_PN9"Pseudorandom Sequence 
> (PN9)"
>  #define V4L2_CID_DEINTERLACING_MODE  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
> + 4)



Thanks,
Mauro

Re: [GIT PULL FOR v4.21] dvb fixes

[Mauro Carvalho Chehab]

Em Wed, 28 Nov 2018 19:40:30 +
Sean Young  escreveu:

> Hi Mauro,
> 
> So I've gone through the outstanding DVB patches and picked up the easier
> ones to deal with first. Please scrutinise.

Thanks! Just one note. See below.


> 
> Thanks,
> 
> Sean
> 
> The following changes since commit 708d75fe1c7c6e9abc5381b6fcc32b49830383d0:
> 
>   media: dvb-pll: don't re-validate tuner frequencies (2018-11-23 12:27:18 
> -0500)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/syoung/media_tree.git for-v4.21b
> 
> for you to fetch changes up to b2d148f755fc60840fbaec52388152896f8339be:
> 
>   media: sony-cxd2880: add optional vcc regulator to bindings (2018-11-27 
> 16:04:16 +)
> 
> 
> Colin Ian King (1):
>   media: dib0700: fix spelling mistake "Amplifyer" -> "Amplifier"
> 
> Hans Verkuil (1):
>   media: dib0900: fix smatch warnings
> 
> Julia Lawall (1):
>   media: mxl5xx: constify dvb_frontend_ops structure
> 
> Malcolm Priestley (1):
>   media: dvb-usb-v2: Fix incorrect use of transfer_flags URB_FREE_BUFFER
> 


> Neil Armstrong (3):
>   media: cxd2880-spi: fix probe when dvb_attach fails
>   media: cxd2880-spi: Add optional vcc regulator

Looks fine. You only forgot to add a:
Acked-by: Yasunari Takiguchi 

To the above patches. The Acked was written to patch 0/2. Patchwork
doesn't automatically handle replies to patch 0/x, so you need to
add the ack yourself ;-)

I added it myself and merged.

>   media: sony-cxd2880: add optional vcc regulator to bindings
> 
> Sean Young (1):
>   media: saa7134: rc-core maintains users count, no need to duplicate
> 
> Victor Toso (2):
>   media: af9033: Remove duplicated switch statement
>   media: dvb: Use WARM definition from identify_state()
> 
> zhong jiang (2):
>   media: usb: Use kmemdup instead of duplicating its function.
>   media: dvb-frontends: Use kmemdup instead of duplicating its function
> 
>  .../devicetree/bindings/media/spi/sony-cxd2880.txt |  4 ++
>  drivers/media/dvb-frontends/af9033.c   | 12 +---
>  drivers/media/dvb-frontends/dib0090.c  | 32 +-
>  drivers/media/dvb-frontends/lgdt3306a.c|  6 +-
>  drivers/media/dvb-frontends/mxl5xx.c   |  2 +-
>  drivers/media/pci/saa7134/saa7134-core.c   |  8 +--
>  drivers/media/pci/saa7134/saa7134-input.c  | 68 
> --
>  drivers/media/pci/saa7134/saa7134.h|  9 ++-
>  drivers/media/spi/cxd2880-spi.c| 17 ++
>  drivers/media/usb/dvb-usb-v2/dvb_usb_core.c|  6 +-
>  drivers/media/usb/dvb-usb-v2/gl861.c   |  3 +-
>  drivers/media/usb/dvb-usb-v2/usb_urb.c |  5 +-
>  drivers/media/usb/dvb-usb/dib0700_devices.c|  2 +-
>  13 files changed, 66 insertions(+), 108 deletions(-)



Thanks,
Mauro

[PATCH] dvb-sat: rename Astra 1E to Astra 19.2 E and move it to beginning

[Mauro Carvalho Chehab]

The "European Universal" LNBf was now replaced by the model with
also supports the Astra satellites in almost all EU. We're keeping
seeing people reporting problems on Kaffeine and other digital TV
software due to that.

So, in order to make easier for new people that just want to make
their Satellite-based TV to work in Europe, let's move the Astra
entry to be the first one and giving it a better name, as the
Astra 1E satellite was retired a long time ago, and, since 2008,
the satellites that replaced it are known as "Astra 19.2 E",
in order to reflect their orbital position.

Signed-off-by: Mauro Carvalho Chehab 
---
 lib/libdvbv5/dvb-sat.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/lib/libdvbv5/dvb-sat.c b/lib/libdvbv5/dvb-sat.c
index 8c04f66f973b..18e2359c053b 100644
--- a/lib/libdvbv5/dvb-sat.c
+++ b/lib/libdvbv5/dvb-sat.c
@@ -53,7 +53,24 @@ struct dvb_sat_lnb_priv {
 static const struct dvb_sat_lnb_priv lnb_array[] = {
{
.desc = {
-   .name = N_("Universal, Europe"),
+   .name = N_("Astra 19.2E, European Universal Ku 
(extended)"),
+   .alias = "EXTENDED",
+   // Legacy fields - kept just to avoid API/ABI breakages
+   .lowfreq = 9750,
+   .highfreq = 10600,
+   .rangeswitch = 11700,
+   .freqrange = {
+   { 10700, 11700 },
+   { 11700, 12750 },
+   },
+   },
+   .freqrange = {
+   { 10700, 11700, 9750, 11700},
+   { 11700, 12750, 10600, 0 },
+   }
+   }, {
+   .desc = {
+   .name = N_("Old European Universal. Nowadays mostly 
replaced by Astra 19.2E"),
.alias = "UNIVERSAL",
// Legacy fields - kept just to avoid API/ABI breakages
.lowfreq = 9750,
@@ -81,23 +98,6 @@ static const struct dvb_sat_lnb_priv lnb_array[] = {
.freqrange = {
{ 12200, 12700, 11250 }
}
-   }, {
-   .desc = {
-   .name = N_("Astra 1E, European Universal Ku 
(extended)"),
-   .alias = "EXTENDED",
-   // Legacy fields - kept just to avoid API/ABI breakages
-   .lowfreq = 9750,
-   .highfreq = 10600,
-   .rangeswitch = 11700,
-   .freqrange = {
-   { 10700, 11700 },
-   { 11700, 12750 },
-   },
-   },
-   .freqrange = {
-   { 10700, 11700, 9750, 11700},
-   { 11700, 12750, 10600, 0 },
-   }
}, {
.desc = {
.name = N_("Standard"),
-- 
2.19.1

[PATCH 6/6] media: pixfmt-meta-d4xx.rst: Add a license to it

[Mauro Carvalho Chehab]

This file is a recent addition to media docs, and it is now the
only one without any license.

While the best is to dual-license with GFDL and GPL, it is,
at least, compatible with GFDL, as this is a requirement to be
part of the media uAPI docs.

So, add such license to it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst 
b/Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst
index 63bf1a2c9116..862e1f327150 100644
--- a/Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-meta-d4xx.rst
@@ -1,4 +1,11 @@
-.. -*- coding: utf-8; mode: rst -*-
+.. Permission is granted to copy, distribute and/or modify this
+.. document under the terms of the GNU Free Documentation License,
+.. Version 1.1 or any later version published by the Free Software
+.. Foundation, with no Invariant Sections, no Front-Cover Texts
+.. and no Back-Cover Texts. A copy of the license is included at
+.. Documentation/media/uapi/fdl-appendix.rst.
+..
+.. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections
 
 .. _v4l2-meta-fmt-d4xx:
 
-- 
2.19.1

[PATCH 4/6] media: svg files: dual-licence some files with GPL and GFDL

[Mauro Carvalho Chehab]

Along the time, several image files got replaced by me by
new ones with similar contents.

As those were not simple conversions, dual-license them.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/dvbstb.svg   | 33 ++-
 Documentation/media/uapi/v4l/bayer.svg| 33 ++-
 Documentation/media/uapi/v4l/constraints.svg  | 33 ++-
 Documentation/media/uapi/v4l/nv12mt.svg   | 33 ++-
 .../media/uapi/v4l/nv12mt_example.svg | 33 ++-
 Documentation/media/uapi/v4l/selection.svg| 33 ++-
 6 files changed, 150 insertions(+), 48 deletions(-)

diff --git a/Documentation/media/uapi/dvb/dvbstb.svg 
b/Documentation/media/uapi/dvb/dvbstb.svg
index 3fe083b3b410..9700c864d3c3 100644
--- a/Documentation/media/uapi/dvb/dvbstb.svg
+++ b/Documentation/media/uapi/dvb/dvbstb.svg
@@ -1,13 +1,30 @@
 
 
 http://www.w3.org/2000/svg; xmlns:cc="http://creativecommons.org/ns#; 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;>image/svg+xmlhttp://purl.org/dc/dcmitype/StillImage"/>
 
 http://www.w3.org/2000/svg; xmlns:cc="http://creativecommons.org/ns#; 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;>image/svg+xmlhttp://purl.org/dc/dcmitype/StillImage"/>B
diff --git a/Documentation/media/uapi/v4l/constraints.svg 
b/Documentation/media/uapi/v4l/constraints.svg
index 3e3887629389..18e314c60757 100644
--- a/Documentation/media/uapi/v4l/constraints.svg
+++ b/Documentation/media/uapi/v4l/constraints.svg
@@ -1,13 +1,30 @@
 
 
 http://www.w3.org/2000/svg; xmlns:cc="http://creativecommons.org/ns#; 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;>image/svg+xmlhttp://purl.org/dc/dcmitype/StillImage"/>
 
 http://purl.org/dc/elements/1.1/;
diff --git a/Documentation/media/uapi/v4l/nv12mt_example.svg 
b/Documentation/media/uapi/v4l/nv12mt_example.svg
index 4dd9cbf7c72e..5eb8bcacc56c 100644
--- a/Documentation/media/uapi/v4l/nv12mt_example.svg
+++ b/Documentation/media/uapi/v4l/nv12mt_example.svg
@@ -1,13 +1,30 @@
 
 
 http://purl.org/dc/elements/1.1/;
diff --git a/Documentation/media/uapi/v4l/selection.svg 
b/Documentation/media/uapi/v4l/selection.svg
index fa97217f1195..eeb195744e60 100644
--- a/Documentation/media/uapi/v4l/selection.svg
+++ b/Documentation/media/uapi/v4l/selection.svg
@@ -1,13 +1,30 @@
 
 
 http://www.w3.org/2000/svg; xmlns:xlink="http://www.w3.org/1999/xlink;>
  
-- 
2.19.1

[PATCH 1/6] Documentation/media: uapi: Explicitly say there are no Invariant Sections

[Mauro Carvalho Chehab]

From: Ben Hutchings 

The GNU Free Documentation License allows for a work to specify
Invariant Sections that are not allowed to be modified.  (Debian
considers that this makes such works non-free.)

The Linux Media Infrastructure userspace API documentation does not
specify any such sections, but it also doesn't say there are none (as
is recommended by the license text).  Make it explicit that there are
none.

References: https://bugs.debian.org/698668
Signed-off-by: Ben Hutchings 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Hans Verkuil 
Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Johannes Stezenbach 
Signed-off-by: Ralph Metzler 
Signed-off-by: Marcus Metzler 
Signed-off-by: Sean Young 
Signed-off-by: Michael Ira Krufky 
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/media_uapi.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/media/media_uapi.rst 
b/Documentation/media/media_uapi.rst
index 28eb35a1f965..5198ff24a094 100644
--- a/Documentation/media/media_uapi.rst
+++ b/Documentation/media/media_uapi.rst
@@ -10,9 +10,9 @@ Linux Media Infrastructure userspace API
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.1 or
-any later version published by the Free Software Foundation. A copy of
-the license is included in the chapter entitled "GNU Free Documentation
-License".
+any later version published by the Free Software Foundation, with no
+Invariant Sections. A copy of the license is included in the chapter
+entitled "GNU Free Documentation License".
 
 .. only:: html
 
-- 
2.19.1

[PATCH 0/6] Add license tags/texts to all media documentation files

[Mauro Carvalho Chehab]

Right now, almost every file under Documentation/media don't contain any
licensing text. That's bad, specially uAPI documents  are licensed under 
GFDL[1].

[1] This is due to historical reasons: by the time they were written, it was
believed that the best license for documents would be GFDL.

Also, as Ben pointed, for a document under GFDL to be considered as free,
it requires to explicitly say that it doesn't contain invariant sections, in 
order
to be compliant with GFDL 1.1 explanation notes.

This series makes clear that no media document under GFDL contain 
invariant sections and add a proper license to each file. This was never
the intent, and we never had any patch proposing to make anything
invariant. So, the changes made by Ben is just to make it explicit.

>From my side, I'm OK with licensing all documentation material I have 
at the Kernel tree with dual-licenses: GPL or GFDL. So, I'm taking one
step further and doing such change on the *.svg files that I created myself
(instead of just converting from other formats).

Hopefully, other media authors will take it as an incentive to also dual-license
their work with under either GPL or GFDL.

>From now on, all new uAPI documents should be dual-licensed GPL/GFDL.
All other documents should be at least GPL.

Ben Hutchings (1):
  Documentation/media: uapi: Explicitly say there are no Invariant
Sections

Mauro Carvalho Chehab (5):
  media: remove text encoding from rst files
  media: add SPDX header to media uAPI files
  media: svg files: dual-licence some files with GPL and GFDL
  media: docs: brainless mass add SPDX headers to all media files
  media: pixfmt-meta-d4xx.rst: Add a license to it

 Documentation/media/.gitignore|  2 ++
 Documentation/media/Makefile  |  2 ++
 Documentation/media/audio.h.rst.exceptions|  2 ++
 Documentation/media/ca.h.rst.exceptions   |  2 ++
 Documentation/media/cec-drivers/index.rst |  2 +-
 .../media/cec-drivers/pulse8-cec.rst  |  2 ++
 Documentation/media/cec.h.rst.exceptions  |  2 ++
 Documentation/media/conf.py   |  2 ++
 Documentation/media/conf_nitpick.py   |  2 ++
 Documentation/media/dmx.h.rst.exceptions  |  2 ++
 Documentation/media/dvb-drivers/avermedia.rst |  2 ++
 Documentation/media/dvb-drivers/bt8xx.rst |  2 ++
 Documentation/media/dvb-drivers/cards.rst |  2 ++
 Documentation/media/dvb-drivers/ci.rst|  2 ++
 .../media/dvb-drivers/contributors.rst|  2 ++
 Documentation/media/dvb-drivers/dvb-usb.rst   |  2 ++
 Documentation/media/dvb-drivers/faq.rst   |  2 ++
 Documentation/media/dvb-drivers/frontends.rst |  2 ++
 Documentation/media/dvb-drivers/index.rst |  2 +-
 Documentation/media/dvb-drivers/intro.rst |  2 ++
 Documentation/media/dvb-drivers/lmedm04.rst   |  2 ++
 .../media/dvb-drivers/opera-firmware.rst  |  2 ++
 Documentation/media/dvb-drivers/technisat.rst |  2 ++
 Documentation/media/dvb-drivers/ttusb-dec.rst |  2 ++
 Documentation/media/dvb-drivers/udev.rst  |  2 ++
 Documentation/media/frontend.h.rst.exceptions |  2 ++
 Documentation/media/index.rst |  2 ++
 Documentation/media/intro.rst |  2 +-
 Documentation/media/kapi/cec-core.rst |  2 ++
 Documentation/media/kapi/csi2.rst |  2 ++
 Documentation/media/kapi/dtv-ca.rst   |  2 ++
 Documentation/media/kapi/dtv-common.rst   |  2 ++
 Documentation/media/kapi/dtv-core.rst |  2 ++
 Documentation/media/kapi/dtv-demux.rst|  2 ++
 Documentation/media/kapi/dtv-frontend.rst |  2 ++
 Documentation/media/kapi/dtv-net.rst  |  2 ++
 Documentation/media/kapi/mc-core.rst  |  2 ++
 Documentation/media/kapi/rc-core.rst  |  2 ++
 Documentation/media/kapi/v4l2-async.rst   |  2 ++
 Documentation/media/kapi/v4l2-clocks.rst  |  2 ++
 Documentation/media/kapi/v4l2-common.rst  |  2 ++
 Documentation/media/kapi/v4l2-controls.rst|  2 ++
 Documentation/media/kapi/v4l2-core.rst|  2 ++
 Documentation/media/kapi/v4l2-dev.rst |  2 ++
 Documentation/media/kapi/v4l2-device.rst  |  2 ++
 Documentation/media/kapi/v4l2-dv-timings.rst  |  2 ++
 Documentation/media/kapi/v4l2-event.rst   |  1 +
 Documentation/media/kapi/v4l2-fh.rst  |  2 ++
 .../media/kapi/v4l2-flash-led-class.rst   |  2 ++
 Documentation/media/kapi/v4l2-fwnode.rst  |  2 ++
 Documentation/media/kapi/v4l2-intro.rst   |  2 ++
 Documentation/media/kapi/v4l2-mc.rst  |  2 ++
 Documentation/media/kapi/v4l2-mediabus.rst|  2 ++
 Documentation/media/kapi/v4l2-mem2mem.rst |  2 ++
 Documentation/media/kapi/v4l2-rect.rst|  2 ++
 Documentation/media/kapi/v4l2-subdev.rst  |  2 ++
 Documentation/media/kapi/v4l2-tuner.rst   |  2 ++
 Documentation/media/kapi/v4l2-tveeprom.rst|  2 ++
 Documentation/media/kapi/v4l2-videobuf.rst|  2 ++
 Documentation/media/kapi/v4l2-videobuf2.rst   |  2 ++
 Documen

[PATCH] media: dvb-pll: don't re-validate tuner frequencies

[Mauro Carvalho Chehab]

The dvb_frontend core already checks for the frequencies. No
need for any additional check inside the driver.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/dvb-pll.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/dvb-pll.c 
b/drivers/media/dvb-frontends/dvb-pll.c
index fff5816f6ec4..29836c1a40e9 100644
--- a/drivers/media/dvb-frontends/dvb-pll.c
+++ b/drivers/media/dvb-frontends/dvb-pll.c
@@ -610,9 +610,6 @@ static int dvb_pll_configure(struct dvb_frontend *fe, u8 
*buf,
u32 div;
int i;
 
-   if (frequency && (frequency < desc->min || frequency > desc->max))
-   return -EINVAL;
-
for (i = 0; i < desc->count; i++) {
if (frequency > desc->entries[i].limit)
continue;
-- 
2.19.1

[PATCH] media: vb2: be sure to free on errors

[Mauro Carvalho Chehab]

As reported by smatch:
drivers/media/common/videobuf2/videobuf2-core.c: 
drivers/media/common/videobuf2/videobuf2-core.c:2159 vb2_mmap() warn: 
inconsistent returns 'mutex:>mmap_lock'.
  Locked on:   line 2148
  Unlocked on: line 2100
   line 2108
   line 2113
   line 2118
   line 2156
   line 2159

There is one error condition that doesn't unlock a mutex.

Fixes: cd26d1c4d1bc ("media: vb2: vb2_mmap: move lock up")
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/common/videobuf2/videobuf2-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index 04d1250747cf..0ca81d495bda 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -2145,7 +2145,8 @@ int vb2_mmap(struct vb2_queue *q, struct vm_area_struct 
*vma)
if (length < (vma->vm_end - vma->vm_start)) {
dprintk(1,
"MMAP invalid, as it would overflow buffer length\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto unlock;
}
 
ret = call_memop(vb, mmap, vb->planes[plane].mem_priv, vma);
-- 
2.19.1

[PATCH] media: seco-cec: declare ops as static const

[Mauro Carvalho Chehab]

As warned by smatch:

drivers/media/platform/seco-cec/seco-cec.c:338:21:  warning: symbol 
'secocec_cec_adap_ops' was not declared. Should it be static?

This struct should be static. Also, it is const, so declare it
as such.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/seco-cec/seco-cec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/seco-cec/seco-cec.c 
b/drivers/media/platform/seco-cec/seco-cec.c
index 8308873c53ab..01ada99de723 100644
--- a/drivers/media/platform/seco-cec/seco-cec.c
+++ b/drivers/media/platform/seco-cec/seco-cec.c
@@ -335,7 +335,7 @@ static void secocec_rx_done(struct cec_adapter *adap, u16 
status_val)
smb_wr16(SECOCEC_STATUS, status_val);
 }
 
-struct cec_adap_ops secocec_cec_adap_ops = {
+static const struct cec_adap_ops secocec_cec_adap_ops = {
/* Low-level callbacks */
.adap_enable = secocec_adap_enable,
.adap_log_addr = secocec_adap_log_addr,
-- 
2.19.1

[PATCH 1/2] media: sum6i-csi: Fix a few coding style issues

[Mauro Carvalho Chehab]

Make checkpatch.pl happier by running it on strict mode and
using the --fix-inline to solve some issues.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c |  9 -
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h |  2 +-
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h |  2 +-
 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c   | 10 +-
 4 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index 7af55ad142dc..89fe2c1e21a8 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -279,7 +279,6 @@ static enum csi_output_fmt get_csi_output_format(struct 
sun6i_csi_dev *sdev,
 static enum csi_input_seq get_csi_input_seq(struct sun6i_csi_dev *sdev,
u32 mbus_code, u32 pixformat)
 {
-
switch (pixformat) {
case V4L2_PIX_FMT_HM12:
case V4L2_PIX_FMT_NV12:
@@ -543,7 +542,7 @@ int sun6i_csi_update_config(struct sun6i_csi *csi,
 {
struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
 
-   if (config == NULL)
+   if (!config)
return -EINVAL;
 
memcpy(>config, config, sizeof(csi->config));
@@ -644,7 +643,7 @@ static int sun6i_subdev_notify_complete(struct 
v4l2_async_notifier *notifier)
dev_dbg(csi->dev, "notify complete, all subdevs registered\n");
 
sd = list_first_entry(_dev->subdevs, struct v4l2_subdev, list);
-   if (sd == NULL)
+   if (!sd)
return -EINVAL;
 
ret = sun6i_csi_link_entity(csi, >entity, sd->fwnode);
@@ -810,7 +809,7 @@ static int sun6i_csi_resource_request(struct sun6i_csi_dev 
*sdev,
return PTR_ERR(io_base);
 
sdev->regmap = devm_regmap_init_mmio_clk(>dev, "bus", io_base,
-   _csi_regmap_config);
+_csi_regmap_config);
if (IS_ERR(sdev->regmap)) {
dev_err(>dev, "Failed to init register map\n");
return PTR_ERR(sdev->regmap);
@@ -853,7 +852,7 @@ static int sun6i_csi_resource_request(struct sun6i_csi_dev 
*sdev,
 
 /*
  * PHYS_OFFSET isn't available on all architectures. In order to
- * accomodate for COMPILE_TEST, let's define it to something dumb.
+ * accommodate for COMPILE_TEST, let's define it to something dumb.
  */
 #if defined(CONFIG_COMPILE_TEST) && !defined(PHYS_OFFSET)
 #define PHYS_OFFSET 0
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
index bd9be36aabfe..0bb000712c33 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
@@ -55,7 +55,7 @@ struct sun6i_csi {
  * @mbus_code: media bus format code (MEDIA_BUS_FMT_*)
  */
 bool sun6i_csi_is_format_supported(struct sun6i_csi *csi, u32 pixformat,
-u32 mbus_code);
+  u32 mbus_code);
 
 /**
  * sun6i_csi_set_power() - power on/off the csi
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
index 3a55836a5a4d..d9b6d89f1927 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
@@ -37,7 +37,7 @@
 #define CSI_IF_CFG_IF_DATA_WIDTH_12BIT ((2 << 8) & 
CSI_IF_CFG_IF_DATA_WIDTH_MASK)
 #define CSI_IF_CFG_MIPI_IF_MASKBIT(7)
 #define CSI_IF_CFG_MIPI_IF_CSI (0 << 7)
-#define CSI_IF_CFG_MIPI_IF_MIPI(1 << 7)
+#define CSI_IF_CFG_MIPI_IF_MIPIBIT(7)
 #define CSI_IF_CFG_CSI_IF_MASK GENMASK(4, 0)
 #define CSI_IF_CFG_CSI_IF_YUV422_INTLV ((0 << 0) & 
CSI_IF_CFG_CSI_IF_MASK)
 #define CSI_IF_CFG_CSI_IF_YUV422_16BIT ((1 << 0) & 
CSI_IF_CFG_CSI_IF_MASK)
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
index e1901a38726f..306b9d2aeafb 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
@@ -86,9 +86,9 @@ sun6i_video_remote_subdev(struct sun6i_video *video, u32 *pad)
 }
 
 static int sun6i_video_queue_setup(struct vb2_queue *vq,
-unsigned int *nbuffers, unsigned int *nplanes,
-unsigned int sizes[],
-struct device *alloc_devs[])
+  unsigned int *nbuffers, unsigned int 
*nplanes,
+  unsigned int sizes[],
+  st

[PATCH 2/2] media: sun6i-csi: manually fix other coding style issues

[Mauro Carvalho Chehab]

There are a few other coding style issues reported by checkpatch
while in --strict mode. Fix the ones that make sense.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  |  9 +++
 .../platform/sunxi/sun6i-csi/sun6i_csi_reg.h  | 24 +--
 .../platform/sunxi/sun6i-csi/sun6i_video.c|  3 ++-
 3 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index 89fe2c1e21a8..9c8a98d78c97 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -57,7 +57,7 @@ bool sun6i_csi_is_format_supported(struct sun6i_csi *csi,
 * Identify the media bus format from device tree.
 */
if ((sdev->csi.v4l2_ep.bus_type == V4L2_MBUS_PARALLEL
- || sdev->csi.v4l2_ep.bus_type == V4L2_MBUS_BT656)
+|| sdev->csi.v4l2_ep.bus_type == V4L2_MBUS_BT656)
 && sdev->csi.v4l2_ep.bus.parallel.bus_width == 16) {
switch (pixformat) {
case V4L2_PIX_FMT_HM12:
@@ -726,9 +726,10 @@ static int sun6i_csi_v4l2_init(struct sun6i_csi *csi)
if (ret)
goto unreg_v4l2;
 
-   ret = v4l2_async_notifier_parse_fwnode_endpoints(
-   csi->dev, >notifier, sizeof(struct v4l2_async_subdev),
-   sun6i_csi_fwnode_parse);
+   ret = v4l2_async_notifier_parse_fwnode_endpoints(csi->dev,
+>notifier,
+sizeof(struct 
v4l2_async_subdev),
+
sun6i_csi_fwnode_parse);
if (ret)
goto clean_video;
 
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
index d9b6d89f1927..703fa14bb313 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
@@ -46,7 +46,7 @@
 
 #define CSI_CAP_REG0x8
 #define CSI_CAP_CH0_CAP_MASK_MASK  GENMASK(5, 2)
-#define CSI_CAP_CH0_CAP_MASK(count)((count << 2) & 
CSI_CAP_CH0_CAP_MASK_MASK)
+#define CSI_CAP_CH0_CAP_MASK(count)(((count) << 2) & 
CSI_CAP_CH0_CAP_MASK_MASK)
 #define CSI_CAP_CH0_VCAP_ONBIT(1)
 #define CSI_CAP_CH0_SCAP_ONBIT(0)
 
@@ -59,9 +59,9 @@
 
 #define CSI_CH_CFG_REG 0x44
 #define CSI_CH_CFG_INPUT_FMT_MASK  GENMASK(23, 20)
-#define CSI_CH_CFG_INPUT_FMT(fmt)  ((fmt << 20) & 
CSI_CH_CFG_INPUT_FMT_MASK)
+#define CSI_CH_CFG_INPUT_FMT(fmt)  (((fmt) << 20) & 
CSI_CH_CFG_INPUT_FMT_MASK)
 #define CSI_CH_CFG_OUTPUT_FMT_MASK GENMASK(19, 16)
-#define CSI_CH_CFG_OUTPUT_FMT(fmt) ((fmt << 16) & 
CSI_CH_CFG_OUTPUT_FMT_MASK)
+#define CSI_CH_CFG_OUTPUT_FMT(fmt) (((fmt) << 16) & 
CSI_CH_CFG_OUTPUT_FMT_MASK)
 #define CSI_CH_CFG_VFLIP_ENBIT(13)
 #define CSI_CH_CFG_HFLIP_ENBIT(12)
 #define CSI_CH_CFG_FIELD_SEL_MASK  GENMASK(11, 10)
@@ -69,7 +69,7 @@
 #define CSI_CH_CFG_FIELD_SEL_FIELD1((1 << 10) & 
CSI_CH_CFG_FIELD_SEL_MASK)
 #define CSI_CH_CFG_FIELD_SEL_BOTH  ((2 << 10) & 
CSI_CH_CFG_FIELD_SEL_MASK)
 #define CSI_CH_CFG_INPUT_SEQ_MASK  GENMASK(9, 8)
-#define CSI_CH_CFG_INPUT_SEQ(seq)  ((seq << 8) & 
CSI_CH_CFG_INPUT_SEQ_MASK)
+#define CSI_CH_CFG_INPUT_SEQ(seq)  (((seq) << 8) & 
CSI_CH_CFG_INPUT_SEQ_MASK)
 
 #define CSI_CH_SCALE_REG   0x4c
 #define CSI_CH_SCALE_QUART_EN  BIT(0)
@@ -111,27 +111,27 @@
 
 #define CSI_CH_HSIZE_REG   0x80
 #define CSI_CH_HSIZE_HOR_LEN_MASK  GENMASK(28, 16)
-#define CSI_CH_HSIZE_HOR_LEN(len)  ((len << 16) & 
CSI_CH_HSIZE_HOR_LEN_MASK)
+#define CSI_CH_HSIZE_HOR_LEN(len)  (((len) << 16) & 
CSI_CH_HSIZE_HOR_LEN_MASK)
 #define CSI_CH_HSIZE_HOR_START_MASKGENMASK(12, 0)
-#define CSI_CH_HSIZE_HOR_START(start)  ((start << 0) & 
CSI_CH_HSIZE_HOR_START_MASK)
+#define CSI_CH_HSIZE_HOR_START(start)  (((start) << 0) & 
CSI_CH_HSIZE_HOR_START_MASK)
 
 #define CSI_CH_VSIZE_REG   0x84
 #define CSI_CH_VSIZE_VER_LEN_MASK  GENMASK(28, 16)
-#define CSI_CH_VSIZE_VER_LEN(len)  ((len << 16) & 
CSI_CH_VSIZE_VER_LEN_MASK)
+#define CSI_CH_VSIZE_VER_LEN(len)  (((len) << 16) & 
CSI_CH_VSIZE_VER_LEN_MASK)
 #define CSI_CH_VSIZE_VER_START_MASKGENMASK(12, 0)
-#define CSI_CH_VSIZE_VER_START(start)  ((sta

Re: [GIT PULL FOR v4.18] v2: Various fixes/improvements

[Mauro Carvalho Chehab]

Hi Hans,

Em Thu, 22 Nov 2018 23:26:07 +0100
Hans Verkuil  escreveu:

> On 11/22/2018 09:52 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 8 May 2018 12:48:45 +0200
> > Hans Verkuil  escreveu:
> >   
> >> Fixes/improvements all over the place.
> >>
> >> Changes since v1:
> >>
> >> Replaced "media: media-device: fix ioctl function types" with the v2 
> >> version
> >> of that patch. My fault, I missed Sakari's request for a change of v1.  
> > 
> > You should seriously review how you're adding SOBs... there are
> > even some like:
> > 
> > Signed-off-by Hans Verkuil 
> > Reported-by: syzbot+69780d144754b8071...@syzkaller.appspotmail.com
> > Cc:   # for v4.20 and up
> > Signed-off-by Hans Verkuil   
> 
> You seem to have replied to a different git pull request (v4.18?!) then
> what these lines above indicate, but it appears that this refers to patch
> "vim2m: use cancel_delayed_work_sync instead of flush_schedule_work".
> 
> It looks like I just completely mistyped the SoB in that patch. Nothing to do
> with the xs4all vs cisco SoBs and AFAICS it is an issue just with that patch.
> 
> Regarding those, the core problem is that I want to show that what I'm doing 
> is
> paid for by Cisco, but I don't want to use the cisco email address to actually
> send patches, pull requests, etc., since that requires a vpn which is really 
> annoying.
> 
> I've made a new email alias hverkuil-ci...@xs4all.nl (I'm not allowed to use 
> a '+'
> unfortunately) and I think I will use that as my git email address to avoid
> cisco.com entirely.

Yeah, I know the drill. I had to do about the same in order to mark
that my work is sponsored by Samsung.

> Regarding the outstanding pull requests with SoB/Author mismatches: should I 
> redo
> those and repost? It's a pain, but if you want it I'll do that tomorrow.

Yes, please.

If it was just to remove a duplicated SoB from another e-mail (or a typo
outside the e-mail part), I would gladly do when merging (probably using git
filter or something scripteable tooling), but I don't feel comfortable to
replace an e-mail address on commits.

Thanks,
Mauro

Re: [GIT PULL FOR v4.18] v2: Various fixes/improvements

[Mauro Carvalho Chehab]

Em Tue, 8 May 2018 12:48:45 +0200
Hans Verkuil  escreveu:

> Fixes/improvements all over the place.
> 
> Changes since v1:
> 
> Replaced "media: media-device: fix ioctl function types" with the v2 version
> of that patch. My fault, I missed Sakari's request for a change of v1.

You should seriously review how you're adding SOBs... there are
even some like:

Signed-off-by Hans Verkuil 
Reported-by: syzbot+69780d144754b8071...@syzkaller.appspotmail.com
Cc:   # for v4.20 and up
Signed-off-by Hans Verkuil 

On this series. Again, none matching the Author's email.

PS.: one quick way to fix it is by using git filter.

You could do something like:

$ git filter-branch -f --msg-filter 'cat|grep -v "Signed-off-by: Your Name"; 
echo "Signed-off-by: Your Name "' origin/master..

And fix all of them with a single command.

> 
> Regards,
> 
>   Hans
> 
> The following changes since commit f10379aad39e9da8bc7d1822e251b5f0673067ef:
> 
>   media: include/video/omapfb_dss.h: use IS_ENABLED() (2018-05-05 11:45:51 
> -0400)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git for-v4.18b
> 
> for you to fetch changes up to 171d364998d1e2373c12b93924fe63cc71586101:
> 
>   media: media-device: fix ioctl function types (2018-05-08 12:40:23 +0200)
> 
> 
> Arvind Yadav (2):
>   platform: Use gpio_is_valid()
>   sta2x11: Use gpio_is_valid() and remove unnecessary check
> 
> Brad Love (4):
>   em28xx: Fix DualHD broken second tuner
>   intel-ipu3: Kconfig coding style issue
>   cec: Kconfig coding style issue
>   saa7164: Fix driver name in debug output
> 
> Colin Ian King (1):
>   media/usbvision: fix spelling mistake: "compresion" -> "compression"
> 
> Dan Carpenter (1):
>   media: vpbe_venc: potential uninitialized variable in ven_sub_dev_init()
> 
> Fengguang Wu (1):
>   media: vcodec: fix ptr_ret.cocci warnings
> 
> Hans Verkuil (2):
>   cec-gpio: use GPIOD_OUT_HIGH_OPEN_DRAIN
>   v4l2-dev.h: fix doc warning
> 
> Jacopo Mondi (1):
>   media: renesas-ceu: Set mbus_fmt on subdev operations
> 
> Jan Luebbe (1):
>   media: imx-csi: fix burst size for 16 bit
> 
> Jasmin Jessich (2):
>   media: Use ktime_set() in pt1.c
>   media: Revert cleanup ktime_set() usage
> 
> Julia Lawall (1):
>   pvrusb2: delete unneeded include
> 
> Niklas Söderlund (1):
>   media: entity: fix spelling for media_entity_get_fwnode_pad()
> 
> Philipp Zabel (4):
>   media: coda: reuse coda_s_fmt_vid_cap to propagate format in 
> coda_s_fmt_vid_out
>   media: coda: do not try to propagate format if capture queue busy
>   media: coda: set colorimetry on coded queue
>   media: imx: add 16-bit grayscale support
> 
> Robin Murphy (1):
>   media: videobuf-dma-sg: Fix dma_{sync,unmap}_sg() calls
> 
> Sami Tolvanen (1):
>   media: media-device: fix ioctl function types
> 
> Simon Que (1):
>   v4l2-core: Rename array 'video_driver' to 'video_drivers'
> 
> Souptick Joarder (1):
>   videobuf: Change return type to vm_fault_t
> 
> Wolfram Sang (1):
>   media: platform: am437x: simplify getting .drvdata
> 
>  drivers/media/Kconfig   | 12 ++--
>  drivers/media/dvb-core/dmxdev.c |  2 +-
>  drivers/media/media-device.c| 21 +++--
>  drivers/media/pci/cx88/cx88-input.c |  6 --
>  drivers/media/pci/intel/ipu3/Kconfig| 12 ++--
>  drivers/media/pci/pt1/pt1.c |  2 +-
>  drivers/media/pci/pt3/pt3.c |  2 +-
>  drivers/media/pci/saa7164/saa7164-fw.c  |  3 ++-
>  drivers/media/pci/sta2x11/sta2x11_vip.c | 31 
> +++
>  drivers/media/platform/am437x/am437x-vpfe.c |  6 ++
>  drivers/media/platform/cec-gpio/cec-gpio.c  |  2 +-
>  drivers/media/platform/coda/coda-common.c   | 45 
> +++--
>  drivers/media/platform/davinci/vpbe_venc.c  |  2 +-
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c |  5 +
>  drivers/media/platform/renesas-ceu.c| 20 +++-
>  drivers/media/platform/via-camera.c |  2 +-
>  drivers/media/usb/em28xx/em28xx-dvb.c   |  2 +-
>  drivers/media/usb/pvrusb2/pvrusb2-cx2584x-v4l.c |  1 -
>  drivers/media/usb/usbvision/usbvision-core.c|  2 +-
>  drivers/media/v4l2-core/v4l2-dev.c  | 22 +++---
>  drivers/media/v4l2-core/videobuf-dma-sg.c   |  6 +++---
>  drivers/staging/media/imx/imx-media-csi.c   |  3 ++-
>  drivers/staging/media/imx/imx-media-utils.c |  9 +
>  include/media/media-entity.h|  2 +-
>  include/media/v4l2-dev.h|  1 +
>  25 files changed, 128 insertions(+), 93 deletions(-)



Thanks,
Mauro

Re: [GIT PULL FOR v4.21] Various fixes

[Mauro Carvalho Chehab]

Hi Hans,

Em Wed, 7 Nov 2018 11:31:14 +0100
Hans Verkuil  escreveu:

> Just one note: the "cec: keep track of outstanding transmits" is CC-ed to 
> stable
> for v4.18 and up, but I prefer to wait until v4.21 before merging it to give 
> it
> more test time. It is not something that happens in normal usage, so delaying
> this isn't a problem.

Could you please check your trees? 

Checkpatch is complaining with:

WARNING: Missing Signed-off-by: line by nominal patch author 'Hans 
Verkuil '

This particular tree has two of your emails as signatures, but it misses
the one you're actually using for the Author: tag:

Signed-off-by:  Hans Verkuil 
Signed-off-by:  Hans Verkuil 

I ended by merging another of your trees that had the same issue.
We should receive some e-mails when this hits linux-next, due to that :-)

> 
> Regards,
> 
>   Hans
> 
> The following changes since commit fbe57dde7126d1b2712ab5ea93fb9d15f89de708:
> 
>   media: ov7740: constify structures stored in fields of v4l2_subdev_ops 
> structure (2018-11-06 07:17:02 -0500)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21a
> 
> for you to fetch changes up to b6f3defe272a97ea65f4352cdc9c0b943164a75e:
> 
>   vivid: fill in media_device bus_info (2018-11-07 11:15:12 +0100)
> 
> 
> Tag branch
> 
> 
> Hans Verkuil (7):
>   adv7604: add CEC support for adv7611/adv7612
>   cec: report Vendor ID after initialization
>   cec: add debug_phys_addr module option
>   cec: keep track of outstanding transmits
>   vivid: fix error handling of kthread_run
>   vivid: set min width/height to a value > 0
>   vivid: fill in media_device bus_info
> 
> Julia Lawall (4):
>   media: vicodec: constify v4l2_ctrl_ops structure
>   media: rockchip/rga: constify v4l2_m2m_ops structure
>   media: vimc: constify structures stored in fields of v4l2_subdev_ops 
> structure
>   media: rockchip/rga: constify video_device structure
> 
> Sean Young (1):
>   media: v4l uapi docs: few minor corrections and typos
> 
>  Documentation/media/uapi/v4l/app-pri.rst |  2 +-
>  Documentation/media/uapi/v4l/audio.rst   |  2 +-
>  Documentation/media/uapi/v4l/dev-capture.rst |  2 +-
>  Documentation/media/uapi/v4l/dev-teletext.rst|  2 +-
>  Documentation/media/uapi/v4l/format.rst  |  2 +-
>  Documentation/media/uapi/v4l/mmap.rst| 22 ++---
>  Documentation/media/uapi/v4l/open.rst|  2 +-
>  Documentation/media/uapi/v4l/tuner.rst   |  4 ++--
>  Documentation/media/uapi/v4l/userp.rst   |  8 
>  Documentation/media/uapi/v4l/video.rst   |  4 ++--
>  drivers/media/cec/cec-adap.c | 34 
> +++-
>  drivers/media/cec/cec-core.c |  6 ++
>  drivers/media/i2c/adv7604.c  | 63 
> ++--
>  drivers/media/platform/rockchip/rga/rga.c|  4 ++--
>  drivers/media/platform/vicodec/vicodec-core.c|  2 +-
>  drivers/media/platform/vimc/vimc-sensor.c|  2 +-
>  drivers/media/platform/vivid/vivid-core.c|  2 ++
>  drivers/media/platform/vivid/vivid-kthread-cap.c |  5 -
>  drivers/media/platform/vivid/vivid-kthread-out.c |  5 -
>  drivers/media/platform/vivid/vivid-vid-common.c  |  2 +-
>  include/media/cec.h  |  1 +
>  21 files changed, 125 insertions(+), 51 deletions(-



Thanks,
Mauro

Re: [PATCH v2 for v4.4 1/1] v4l: event: Add subscription to list before calling "add" operation

[Mauro Carvalho Chehab]

Em Tue, 20 Nov 2018 12:49:46 +0200
Sakari Ailus  escreveu:

> Hi Greg,
> 
> On Mon, Nov 19, 2018 at 06:46:21PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Nov 19, 2018 at 07:03:54PM +0200, Sakari Ailus wrote:  
> > > Hi Greg,
> > > 
> > > On Mon, Nov 19, 2018 at 04:14:00PM +0100, Greg Kroah-Hartman wrote:  
> > > > On Wed, Nov 14, 2018 at 11:37:46AM +0200, Sakari Ailus wrote:  
> > > > > [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ]  
> > > > 
> > > > There is no such git commit id in Linus's tree :(  
> > > 
> > > Right. At the moment it's in the media tree only. I expect it'll end up to
> > > Linus's tree once Mauro will send the next pull request from the media 
> > > tree
> > > to Linus.  
> > 
> > Ok, please do not send requests for stable tree inclusion until _AFTER_
> > the patch is in Linus's tree, otherwise it just wastes the stable tree
> > maintainer's time :(  
> 
> Apologies for the noise. I'll send you a note once the patches are in
> Linus's tree.

Btw, just sent a pull request with this patch. 

I wanted to send this two weeks ago, but I had to do two trips 
(the final one to be at KS/LPC). This ended by delaying the pull request.

Thanks,
Mauro

[PATCH 1/3] media: dvb_frontend: don't print function names twice

[Mauro Carvalho Chehab]

The dvb_frontend dprintk() macro already prints __func__. So,
we don't need to add it again at the printed message.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-core/dvb_frontend.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 961207cf09eb..2a26f9210394 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2587,8 +2587,8 @@ static int dvb_frontend_handle_ioctl(struct file *file,
u8 last = 1;
 
if (dvb_frontend_debug)
-   dprintk("%s switch command: 0x%04lx\n",
-   __func__, swcmd);
+   dprintk("switch command: 0x%04lx\n",
+   swcmd);
nexttime = ktime_get_boottime();
if (dvb_frontend_debug)
tv[0] = nexttime;
@@ -2611,8 +2611,8 @@ static int dvb_frontend_handle_ioctl(struct file *file,
dvb_frontend_sleep_until(, 
8000);
}
if (dvb_frontend_debug) {
-   dprintk("%s(%d): switch delay (should be 32k 
followed by all 8k)\n",
-   __func__, fe->dvb->num);
+   dprintk("(adapter %d): switch delay (should be 
32k followed by all 8k)\n",
+   fe->dvb->num);
for (i = 1; i < 10; i++)
pr_info("%d: %d\n", i,
(int)ktime_us_delta(tv[i], tv[i 
- 1]));
-- 
2.19.1

[PATCH 2/3] media: dvb_frontend: add debug message for frequency intervals

[Mauro Carvalho Chehab]

As we did an internal change inside the subsystem to always
represent min/max frequencies in Hz, add a debug message, as this
would help to discover bugs on drivers, if any.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-core/dvb_frontend.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 2a26f9210394..27a1d4a98d73 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -917,6 +917,9 @@ static void dvb_frontend_get_frequency_limits(struct 
dvb_frontend *fe,
 "DVB: adapter %i frontend %u frequency limits 
undefined - fix the driver\n",
 fe->dvb->num, fe->id);
 
+   dprintk("frequency interval: tuner: %u...%u, frontend: %u...%u",
+   tuner_min, tuner_max, frontend_min, frontend_max);
+
/* If the standard is for satellite, convert frequencies to kHz */
switch (c->delivery_system) {
case SYS_DVBS:
-- 
2.19.1

[PATCH 3/3] media: dvb-pll: fix tuner frequency ranges

[Mauro Carvalho Chehab]

Tuners should report frequencies in Hz. That works fine on most
drivers, but, in the case of dvb-pll, some settings are for
satellite tuners, while others are for terrestrial/cable ones.

The code was trying to solve it at probing time, but that doesn't
work, as, when _attach is called, the delivery system may be wrong.

Fix it by ensuring that all frequencies are in Hz at the per-tuner
max/min values.

While here, add a debug message, as this would help to debug any
issues there.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/dvb-pll.c | 103 --
 1 file changed, 48 insertions(+), 55 deletions(-)

diff --git a/drivers/media/dvb-frontends/dvb-pll.c 
b/drivers/media/dvb-frontends/dvb-pll.c
index 6d4b2eec67b4..fff5816f6ec4 100644
--- a/drivers/media/dvb-frontends/dvb-pll.c
+++ b/drivers/media/dvb-frontends/dvb-pll.c
@@ -80,8 +80,8 @@ struct dvb_pll_desc {
 
 static const struct dvb_pll_desc dvb_pll_thomson_dtt7579 = {
.name  = "Thomson dtt7579",
-   .min   = 17700,
-   .max   = 85800,
+   .min   = 177 * MHz,
+   .max   = 858 * MHz,
.iffreq= 3617,
.sleepdata = (u8[]){ 2, 0xb4, 0x03 },
.count = 4,
@@ -102,8 +102,8 @@ static void thomson_dtt759x_bw(struct dvb_frontend *fe, u8 
*buf)
 
 static const struct dvb_pll_desc dvb_pll_thomson_dtt759x = {
.name  = "Thomson dtt759x",
-   .min   = 17700,
-   .max   = 89600,
+   .min   = 177 * MHz,
+   .max   = 896 * MHz,
.set   = thomson_dtt759x_bw,
.iffreq= 3617,
.sleepdata = (u8[]){ 2, 0x84, 0x03 },
@@ -126,8 +126,8 @@ static void thomson_dtt7520x_bw(struct dvb_frontend *fe, u8 
*buf)
 
 static const struct dvb_pll_desc dvb_pll_thomson_dtt7520x = {
.name  = "Thomson dtt7520x",
-   .min   = 18500,
-   .max   = 9,
+   .min   = 185 * MHz,
+   .max   = 900 * MHz,
.set   = thomson_dtt7520x_bw,
.iffreq = 3617,
.count = 7,
@@ -144,8 +144,8 @@ static const struct dvb_pll_desc dvb_pll_thomson_dtt7520x = 
{
 
 static const struct dvb_pll_desc dvb_pll_lg_z201 = {
.name  = "LG z201",
-   .min   = 17400,
-   .max   = 86200,
+   .min   = 174 * MHz,
+   .max   = 862 * MHz,
.iffreq= 3617,
.sleepdata = (u8[]){ 2, 0xbc, 0x03 },
.count = 5,
@@ -160,8 +160,8 @@ static const struct dvb_pll_desc dvb_pll_lg_z201 = {
 
 static const struct dvb_pll_desc dvb_pll_unknown_1 = {
.name  = "unknown 1", /* used by dntv live dvb-t */
-   .min   = 17400,
-   .max   = 86200,
+   .min   = 174 * MHz,
+   .max   = 862 * MHz,
.iffreq= 3617,
.count = 9,
.entries = {
@@ -182,8 +182,8 @@ static const struct dvb_pll_desc dvb_pll_unknown_1 = {
  */
 static const struct dvb_pll_desc dvb_pll_tua6010xs = {
.name  = "Infineon TUA6010XS",
-   .min   =  4425,
-   .max   = 85800,
+   .min   = 44250 * kHz,
+   .max   = 858 * MHz,
.iffreq= 36125000,
.count = 3,
.entries = {
@@ -196,8 +196,8 @@ static const struct dvb_pll_desc dvb_pll_tua6010xs = {
 /* Panasonic env57h1xd5 (some Philips PLL ?) */
 static const struct dvb_pll_desc dvb_pll_env57h1xd5 = {
.name  = "Panasonic ENV57H1XD5",
-   .min   =  4425,
-   .max   = 85800,
+   .min   = 44250 * kHz,
+   .max   = 858 * MHz,
.iffreq= 36125000,
.count = 4,
.entries = {
@@ -220,8 +220,8 @@ static void tda665x_bw(struct dvb_frontend *fe, u8 *buf)
 
 static const struct dvb_pll_desc dvb_pll_tda665x = {
.name  = "Philips TDA6650/TDA6651",
-   .min   =  4425,
-   .max   = 85800,
+   .min   = 44250 * kHz,
+   .max   = 858 * MHz,
.set   = tda665x_bw,
.iffreq= 3617,
.initdata = (u8[]){ 4, 0x0b, 0xf5, 0x85, 0xab },
@@ -254,8 +254,8 @@ static void tua6034_bw(struct dvb_frontend *fe, u8 *buf)
 
 static const struct dvb_pll_desc dvb_pll_tua6034 = {
.name  = "Infineon TUA6034",
-   .min   =  4425,
-   .max   = 85800,
+   .min   = 44250 * kHz,
+   .max   = 858 * MHz,
.iffreq= 3617,
.count = 3,
.set   = tua6034_bw,
@@ -278,8 +278,8 @@ static void tded4_bw(struct dvb_frontend *fe, u8 *buf)
 
 static const struct dvb_pll_desc dvb_pll_tded4 = {
.name = "ALPS TDED4",
-   .min = 4700,
-   .max = 86300,
+   .min =  47 * MHz,
+   .max = 863 * MHz,
.iffreq= 3617,
.set   = tded4_bw,
.count = 4,
@@ -296,8 +296,8 @@ static const struct dvb_pll_desc dvb_pll_tded4 = {
  */
 static const struct dvb_pll_desc dvb_pll_tdhu2 = {
.name = "ALPS TDHU2",
-   .min = 5400,
-   .max = 86400,
+   .min =  54 * MHz,
+   .max = 864 * MHz,
.i

raw notes from the Media summit

[Mauro Carvalho Chehab]

In order to help writing a media summit report, I'm sending the raw notes
that were at Etherpad after the end of the meeting.

Thanks,
Mauro


Media summit 25-10-2018

Edinburgh
https://www.spinics.net/lists/linux-media/msg141095.html

Attendees

Brad Love

Ezequiel Garcia

Gustavo Padovan

Hans Verkuil

Helen Koike

Hidenori Yamaji

Ivan Kalinin

Jacopo Mondi

Kieran Bingham

Laurent Pinchart

Mauro Chebab

Maxime Ripard

Michael Grzeschik

Michael Ira Krufky

Niklas Söderlund

Patrick Lai

Paul Elder

Peter Griffin

Ralph Clark

Ricardo Ribalda

Sakari Ailus

Sean Young

Seung-Woo Kim

Stefan Klug

Vinod Koul



Topics

CEC (Hans Verkuil)

1 pin bus, cec-gpio error injection support
Tda998x (including BeagleBoard Bone support)
ChromeOS CEC support
DisplayPort CEC Tunneling over AUX for i915, nouveau, amdgpu
Still lots of work happening around CEC utilities, the compliance test is in 
continuous use at cisco.
URL to CEC status: https://hverkuil.home.xs4all.nl/cec-status.txt

CISCO using CEC in their products, and pushing for development of CEC 
upstream.

Automated test pipelines in place utilising cec-compliance


1.4 spec can be found quite easily online 
(http://d1.amobbs.com/bbs_upload782111/files_51/ourdev_716302E34B9Q.pdf) - Hans 
will tell us diff to 2.0



RC-Core progress report (Sean Young)

Ported/removed all staging lirc drivers

BPF IR decoding support.

rc-core protocol decoders only support the most common protocols

old lirc userspace rarely required


Linux supports more IR hardware than any other operating system.

Future/TODO

Some driver work needed (mostly for older hardware)

Build dvb without rc-core

More BPF protocol decoders

Support 2.4ghz remotes

Needs automated testing


Support with gpio and simple ir led is available

Persistent storage of controls (Ricardo Ribalda - Qtec)

Sensors usually come with some calibration data from the manufacturer about 
dead pixels etc.
How to get this calibration data into the sensor.

proposal: 
- new vid interface /dev/videoX /dev/v4l-subX

- s_ext_ctrls - write array of ctrls

- s_ctrl - replace specfific ctrl

- dt - locate ctrl vals

- (reuse v4l2 ioctls for save/restore/get value(s))
- implementation in two parts: main driver intf, storage

why not set sensor vals from userspace? - user might impl wrong

- if part of driver can make sure they work for specific sensor


no get_min/max coz storage might not have space to save all ctrls

NVMEM might be good for storage rw
 - Is it a filesystem (or is that more overhead)
 - controls validate the data in the same way as they are validated by the 
device sensor.


Maintenance process tools - DIM (Laurent Pinchart - Ideas on Board)

DRM have switched to co-maintainer model
 - Burden is shared
 - Increased commit rights to the mainline (multi-maintaner model)
 - no enforeced maintainer process (each their own) - multi-comitter means each 
has to do checks - need to standardize tools -> DIM

- DIM wrapper for git kindaish

 - DRM inglorious maintenance tool : 
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html 
 - conflict resolution by commiter, not maintainer
 - DIM uses conflict resoultion system in git to pre-prepare the merge 
conflicts in a shared cache.
 - tool enforces quality checks

drawbacks
- pushing = testing = rebuilding :/ -> becomes a burden for the committers

- Patches are integrated from a patchwork instance, and the commits then 
reference the history of the patch upstream
- Adds an extra tool that must be used, and then an extra delay.

- eg. takes time/difficult to ack


easyish to get commit rights
 - Responsibility to perform correctly
 - spreads the review workload (creates review-economics)

 - trading rb tags -> lower quality :/


- "please submit patches" "also please merge conflict resolution and rebuild"
- If automated testing can validate the process, it can simplify commit process 
for multi-commiters.

- auto testing on test/build farm


had this model in media for a few years
- somebody merged 9k lines and lost a handful of devs
- probably exception, model fine
- many comitters but few maintainers - problem could be technically resolved

too few ppl reviewing patches - wait time measured in months :)
- multi-commiter model try to solve this problem

incentive to get more maintainers
- commit rights
- responsilibity - get attached to code :)


Automated testing (Ezequiel Garcia, Gustavo Padovan, Sakari Ailus)

Testing only one config, one version, one patch application, one hardware (one 
test to rule them all). Sometimes testing is omitted altogether by a developer, 
or it has been done before making changes to a patch. A lot of problems will 
only be found in the additional validation steps Mauro now performs, or when 
the patches already have reached the 

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

[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 time and money into this, so they get to choose
> > as far as I am concerned :-)  

Surely, but no matter who is paying, if one wants to merge things upstream,
he/she has to stick with upstream ruleset.

That's said, we should try to not make life harder than it should be for
it, but some things should be standardized, if we want future contributions
there. At very minimal, from my side, I'd like it to be as much compatible
with Kernel selftest infrastructure as possible.

I would try to avoid placing KernelCI-specific stuff (like adding LAVA code)
inside v4l-utils tree. With regards to that, one alternative would be to
split KernelCI specific code on a different tree and use "git subtree".

> 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 

[PATCH] cedrus: check if kzalloc() fails

[Mauro Carvalho Chehab]

As warned by static code analizer checkers:
drivers/staging/media/sunxi/cedrus/cedrus.c: 
drivers/staging/media/sunxi/cedrus/cedrus.c:93 cedrus_init_ctrls() error: 
potential null dereference 'ctx->ctrls'.  (kzalloc returns null)

The problem is that it assumes that kzalloc() will always
succeed.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/sunxi/cedrus/cedrus.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index dd121f66fa2d..6a73a7841303 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -72,6 +72,8 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct 
cedrus_ctx *ctx)
ctrl_size = sizeof(ctrl) * CEDRUS_CONTROLS_COUNT + 1;
 
ctx->ctrls = kzalloc(ctrl_size, GFP_KERNEL);
+   if (!ctx->ctrls)
+   return -ENOMEM;
memset(ctx->ctrls, 0, ctrl_size);
 
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
-- 
2.19.1

[PATCH] media: dm365_ipipeif: better annotate a fall though

[Mauro Carvalho Chehab]

Shut up this warning:

drivers/staging/media/davinci_vpfe/dm365_ipipeif.c: In function 
'ipipeif_hw_setup':
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:298:3: warning: this 
statement may fall through [-Wimplicit-fallthrough=]
   switch (isif_port_if) {
   ^~
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:314:2: note: here
  case IPIPEIF_SDRAM_YUV:
  ^~~~

By annotating a fall though case at the right place.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
index a53231b08d30..e3425bf082ae 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
@@ -310,6 +310,7 @@ static int ipipeif_hw_setup(struct v4l2_subdev *sd)
ipipeif_write(val, ipipeif_base_addr, IPIPEIF_CFG2);
break;
}
+   /* fall through */
 
case IPIPEIF_SDRAM_YUV:
/* Set clock divider */
-- 
2.19.1

[PATCH] davinci_vpfe: add a missing break

[Mauro Carvalho Chehab]

As warned by gcc:

drivers/staging/media/davinci_vpfe/dm365_ipipeif.c: In function 
'ipipeif_hw_setup':
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:298:3: warning: this 
statement may fall through [-Wimplicit-fallthrough=]
   switch (isif_port_if) {
   ^~
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c:314:2: note: here
  case IPIPEIF_SDRAM_YUV:
  ^~~~

There is a missing break for the raw format.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
index a53231b08d30..975272bcf8ca 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
@@ -310,6 +310,7 @@ static int ipipeif_hw_setup(struct v4l2_subdev *sd)
ipipeif_write(val, ipipeif_base_addr, IPIPEIF_CFG2);
break;
}
+   break;
 
case IPIPEIF_SDRAM_YUV:
/* Set clock divider */
-- 
2.19.1

Re: [PATCH v7 03/16] v4l: Add Intel IPU3 meta data uAPI

[Mauro Carvalho Chehab]

Em Mon, 29 Oct 2018 15:22:57 -0700
Yong Zhi  escreveu:

> These meta formats are used on Intel IPU3 ImgU video queues
> to carry 3A statistics and ISP pipeline parameters.

Just minor things. See below.

> 
> V4L2_META_FMT_IPU3_3A
> V4L2_META_FMT_IPU3_PARAMS
> 
> Signed-off-by: Yong Zhi 
> Signed-off-by: Chao C Li 
> Signed-off-by: Rajmohan Mani 
> ---
>  Documentation/media/uapi/v4l/meta-formats.rst  |1 +
>  .../media/uapi/v4l/pixfmt-meta-intel-ipu3.rst  |  181 ++

I would actually prefer to have those two changes merged together with
patch 1, as it makes easier for review.

>  include/uapi/linux/intel-ipu3.h| 2819 
> 

This one makes sense to have a separate patch.

>  3 files changed, 3001 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
>  create mode 100644 include/uapi/linux/intel-ipu3.h
> 
> diff --git a/Documentation/media/uapi/v4l/meta-formats.rst 
> b/Documentation/media/uapi/v4l/meta-formats.rst
> index cf971d5..eafc534 100644
> --- a/Documentation/media/uapi/v4l/meta-formats.rst
> +++ b/Documentation/media/uapi/v4l/meta-formats.rst
> @@ -12,6 +12,7 @@ These formats are used for the :ref:`metadata` interface 
> only.
>  .. toctree::
>  :maxdepth: 1
>  
> +pixfmt-meta-intel-ipu3
>  pixfmt-meta-d4xx
>  pixfmt-meta-uvc
>  pixfmt-meta-vsp1-hgo
> diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst 
> b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> new file mode 100644
> index 000..23b945b
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> @@ -0,0 +1,181 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _intel-ipu3:
> +
> +**
> +V4L2_META_FMT_IPU3_PARAMS ('ip3p'), V4L2_META_FMT_IPU3_3A ('ip3s')
> +**
> +
> +.. c:type:: ipu3_uapi_stats_3a
> +
> +3A statistics
> +=
> +
> +For IPU3 ImgU, the 3A statistics accelerators collect different statistics 
> over
> +an input bayer frame. Those statistics, defined in data struct
> +:c:type:`ipu3_uapi_stats_3a`, are meta output obtained from "ipu3-imgu 3a 
> stat"
> +video node, which are then passed to user space for statistics analysis
> +using :c:type:`v4l2_meta_format` interface.
> +
> +The statistics collected are AWB (Auto-white balance) RGBS (Red, Green, Blue 
> and 
> +Saturation measure) cells, AWB filter response, AF (Auto-focus) filter 
> response,
> +and AE (Auto-exposure) histogram.
> +
> +struct :c:type:`ipu3_uapi_4a_config` saves configurable parameters for all 
> above.
> +
> +
> +.. code-block:: c
> +
> +
> + struct ipu3_uapi_stats_3a {
> + struct ipu3_uapi_awb_raw_buffer awb_raw_buffer
> +  __attribute__((aligned(32)));
> + struct ipu3_uapi_ae_raw_buffer_aligned
> + ae_raw_buffer[IPU3_UAPI_MAX_STRIPES];
> + struct ipu3_uapi_af_raw_buffer af_raw_buffer;
> + struct ipu3_uapi_awb_fr_raw_buffer awb_fr_raw_buffer;
> + struct ipu3_uapi_4a_config stats_4a_config;
> + __u32 ae_join_buffers;
> + __u8 padding[28];
> + struct ipu3_uapi_stats_3a_bubble_info_per_stripe
> + stats_3a_bubble_per_stripe;
> + struct ipu3_uapi_ff_status stats_3a_status;
> + } __packed;
> +
> +
> +.. c:type:: ipu3_uapi_params
> +
> +Pipeline parameters
> +===
> +
> +IPU3 pipeline has a number of image processing stages, each of which takes a
> +set of parameters as input. The major stages of pipelines are shown here:
> +
> +Raw pixels -> Bayer Downscaling -> Optical Black Correction ->
> +
> +Linearization -> Lens Shading Correction -> White Balance / Exposure /
> +
> +Focus Apply -> Bayer Noise Reduction -> ANR -> Demosaicing -> Color
> +
> +Correction Matrix -> Gamma correction -> Color Space Conversion ->
> +
> +Chroma Down Scaling -> Chromatic Noise Reduction -> Total Color
> +
> +Correction -> XNR3 -> TNR -> DDR
> +
> +The table below presents a description of the above algorithms.
> +
> + 
> ===
> +Name  Description
> + 
> ===
> +Optical Black Correction Optical Black Correction block subtracts a 
> pre-defined
> +  value from the respective pixel values to obtain better
> +  image quality.
> +  Defined in :c:type:`ipu3_uapi_obgrid_param`.
> +Linearization This algo block uses linearization parameters 
> to
> +  address non-linearity sensor effects. The Lookup table
> +  table is defined in
> +  :c:type:`ipu3_uapi_isp_lin_vmem_params`.
> +SHD   Lens shading correction is used to correct spatial
> +  non-uniformity of 

Re: [PATCH v7 01/16] v4l: Add Intel IPU3 meta buffer formats

[Mauro Carvalho Chehab]

Em Fri, 2 Nov 2018 09:59:31 -0300
Mauro Carvalho Chehab  escreveu:

> Hi Zhi-san,
> 
> Em Mon, 29 Oct 2018 15:22:55 -0700
> Yong Zhi  escreveu:
> 
> > Add IPU3-specific meta formats for parameter
> > processing and 3A, DVS statistics:
> > 
> >   V4L2_META_FMT_IPU3_PARAMS
> >   V4L2_META_FMT_IPU3_STAT_3A
> > 
> > Signed-off-by: Yong Zhi 
> > ---
> >  drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
> >  include/uapi/linux/videodev2.h   | 4 
> >  2 files changed, 6 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 6489f25..abff64b 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1299,6 +1299,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> > case V4L2_META_FMT_VSP1_HGO:descr = "R-Car VSP1 1-D Histogram"; 
> > break;
> > case V4L2_META_FMT_VSP1_HGT:descr = "R-Car VSP1 2-D Histogram"; 
> > break;
> > case V4L2_META_FMT_UVC: descr = "UVC payload header metadata"; 
> > break;
> > +   case V4L2_META_FMT_IPU3_PARAMS: descr = "IPU3 processing parameters"; 
> > break;
> > +   case V4L2_META_FMT_IPU3_STAT_3A:descr = "IPU3 3A statistics"; 
> > break;
> >  
> > default:
> > /* Compressed formats */
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index f0a968a..bdccd7a 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -718,6 +718,10 @@ struct v4l2_pix_format {
> >  #define V4L2_META_FMT_UVC v4l2_fourcc('U', 'V', 'C', 'H') /* UVC 
> > Payload Header metadata */
> >  #define V4L2_META_FMT_D4XXv4l2_fourcc('D', '4', 'X', 'X') /* D4XX 
> > Payload Header metadata */
> >  
> > +/* Vendor specific - used for IPU3 camera sub-system */
> > +#define V4L2_META_FMT_IPU3_PARAMS  v4l2_fourcc('i', 'p', '3', 'p') /* IPU3 
> > params */
> > +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') /* IPU3 
> > 3A statistics */
> 
> Where's the documentation for those two new formats? The best is to
> always add the documentation bits for V4L2 uAPI stuff at the same
> patch, as it makes easier for us to review.

Found it. It is at patch 3.

> 
> > +
> >  /* priv field value to indicates that subsequent fields are valid. */
> >  #define V4L2_PIX_FMT_PRIV_MAGIC0xfeedcafe
> >  
> 
> 
> 
> Thanks,
> Mauro



Thanks,
Mauro

Re: [PATCH v7 01/16] v4l: Add Intel IPU3 meta buffer formats

[Mauro Carvalho Chehab]

Hi Zhi-san,

Em Mon, 29 Oct 2018 15:22:55 -0700
Yong Zhi  escreveu:

> Add IPU3-specific meta formats for parameter
> processing and 3A, DVS statistics:
> 
>   V4L2_META_FMT_IPU3_PARAMS
>   V4L2_META_FMT_IPU3_STAT_3A
> 
> Signed-off-by: Yong Zhi 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
>  include/uapi/linux/videodev2.h   | 4 
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 6489f25..abff64b 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1299,6 +1299,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>   case V4L2_META_FMT_VSP1_HGO:descr = "R-Car VSP1 1-D Histogram"; 
> break;
>   case V4L2_META_FMT_VSP1_HGT:descr = "R-Car VSP1 2-D Histogram"; 
> break;
>   case V4L2_META_FMT_UVC: descr = "UVC payload header metadata"; 
> break;
> + case V4L2_META_FMT_IPU3_PARAMS: descr = "IPU3 processing parameters"; 
> break;
> + case V4L2_META_FMT_IPU3_STAT_3A:descr = "IPU3 3A statistics"; 
> break;
>  
>   default:
>   /* Compressed formats */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index f0a968a..bdccd7a 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -718,6 +718,10 @@ struct v4l2_pix_format {
>  #define V4L2_META_FMT_UVC v4l2_fourcc('U', 'V', 'C', 'H') /* UVC 
> Payload Header metadata */
>  #define V4L2_META_FMT_D4XXv4l2_fourcc('D', '4', 'X', 'X') /* D4XX 
> Payload Header metadata */
>  
> +/* Vendor specific - used for IPU3 camera sub-system */
> +#define V4L2_META_FMT_IPU3_PARAMSv4l2_fourcc('i', 'p', '3', 'p') /* IPU3 
> params */
> +#define V4L2_META_FMT_IPU3_STAT_3A   v4l2_fourcc('i', 'p', '3', 's') /* IPU3 
> 3A statistics */

Where's the documentation for those two new formats? The best is to
always add the documentation bits for V4L2 uAPI stuff at the same
patch, as it makes easier for us to review.

> +
>  /* priv field value to indicates that subsequent fields are valid. */
>  #define V4L2_PIX_FMT_PRIV_MAGIC  0xfeedcafe
>  



Thanks,
Mauro

[PATCH] v4l2-controls: add a missing include

[Mauro Carvalho Chehab]

As warned by "make headers_check", the definition for the linux-specific
integer types is missing:

./usr/include/linux/v4l2-controls.h:1105: found __[us]{8,16,32,64} type 
without #include 

Fixes: c27bb30e7b6d ("media: v4l: Add definitions for MPEG-2 slice format and 
metadata")
Reported-by: Linus Torvalds 
Reported-by: Stephen Rothwell 
Signed-off-by: Mauro Carvalho Chehab 
---
 include/uapi/linux/v4l2-controls.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 51b095898f4b..86a54916206f 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -47,6 +47,8 @@
  *  videodev2.h.
  */
 
+#include 
+
 #ifndef __LINUX_V4L2_CONTROLS_H
 #define __LINUX_V4L2_CONTROLS_H
 
-- 
2.19.1

Re: [PATCH 4/4] SoC camera: Tidy the header

[Mauro Carvalho Chehab]

Em Wed, 31 Oct 2018 11:00:22 +0100
Hans Verkuil  escreveu:

> On 10/31/2018 10:40 AM, Mauro Carvalho Chehab wrote:
> > Em Wed, 31 Oct 2018 11:29:45 +0200
> > Sakari Ailus  escreveu:
> >   
> >> Hi Mauro,
> >>
> >> On Tue, Oct 30, 2018 at 09:06:18AM -0300, Mauro Carvalho Chehab wrote:  
> >>> Em Tue, 30 Oct 2018 01:00:29 +0200
> >>> Sakari Ailus  escreveu:
> >>> 
> >>>> Clean up the SoC camera framework header. It only exists now to keep 
> >>>> board
> >>>> code compiling. The header can be removed once the board code 
> >>>> dependencies
> >>>> to it has been removed.
> >>>>
> >>>> Signed-off-by: Sakari Ailus 
> >>>> ---
> >>>>  include/media/soc_camera.h | 335 
> >>>> -
> >>>>  1 file changed, 335 deletions(-)
> >>>>
> >>>> diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> >>>> index b7e42a1b0910..14d19da6052a 100644
> >>>> --- a/include/media/soc_camera.h
> >>>> +++ b/include/media/soc_camera.h
> >>>> @@ -22,172 +22,6 @@
> >>>>  #include 
> >>>>  #include 
> >>>
> >>> That doesn't make any sense. soc_camera.h should have the same fate
> >>> as the entire soc_camera infrastructure: either be removed or moved
> >>> to staging, and everything else that doesn't have the same fate
> >>> should get rid of this header.
> >>
> >> We can't just remove this; there is board code that depends on it.
> >>
> >> The intent is to remove the board code as well but presuming that the board
> >> code would be merged through a different tree, it'd be less hassle to wait
> >> a bit; hence the patch removing any unnecessary stuff here.  
> > 
> > Then we need *first* to remove board code, wait for those changes to be
> > applied and *then* remove soc_camera (and not the opposite).  
> 
> Please note that the camera support for all the remaining boards using
> soc_camera has been dead for years. The soc_camera drivers that they depended
> on have been removed a long time ago.
> 
> So all they depend on are the header. We can safely remove soc_camera without
> loss of functionality (and thus prevent others from basing new drivers on
> soc_camera), while we work to update the board files so we can remove this 
> last
> header.
> 
> I have modified some board files here:
> 
> https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=rm-soc-camera=d7ae2fcf6e447022f0780bb86a2b63d5c7cf4d35

Good! the arch-specific mach-* changes should likely be on separate
patches, though.

> Only arch/arm/mach-imx/mach-imx27_visstrim_m10.c hasn't been fixed yet in that
> patch (ENOTIME).

So, the code we don't manage seems to be just 3 archs, right (mach-omap1,
mach-pxa and mach-imx)?

Btw, the soc_camera dependent code at mach-imx27_visstrim_m10.c is:

static struct soc_camera_link iclink_tvp5150 = {
.bus_id = 0,
.board_info = _i2c_camera,
.i2c_adapter_id = 0,
.power = visstrim_camera_power,
.reset = visstrim_camera_reset,
};

...
platform_device_register_resndata(NULL, "soc-camera-pdrv", 0, NULL, 0,
  _tvp5150, sizeof(iclink_tvp5150));


As tvp5150 is not actually a soc_camera driver, I suspect that
the conversion here would be to make it to use the tvp5150 driver
directly, instead of doing it via soc_camera.

> The problem is just lack of time to clean this up and figure out who should
> take these board patches.

No need to rush it.

> So I think it is a nice solution to just replace the header with a dummy 
> version
> so the board files still compile, and then we can delete the dead soc_camera
> driver. It's probably easier as well to push through the board file changes 
> once
> soc_camera is removed since you can just point out that the framework it 
> depended
> on is gone.

I still think that reverting the order and rushing the removal is not the
way to go.

For example, on that specific imx.27 board above mentioned, it may
still be working with the tvp5150 driver[1] and replacing the soc_camera.h 
by a dummy version would just break for no good reason.

[1] I don't have such board to test, nor I checked if what's left from
soc_camera still allows the tvp5150 driver to register.


Thanks,
Mauro

Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers

[Mauro Carvalho Chehab]

Em Wed, 31 Oct 2018 11:32:02 +0200
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Tue, Oct 30, 2018 at 05:35:23PM -0300, Mauro Carvalho Chehab wrote:
> > Em Tue, 30 Oct 2018 21:28:57 +0100
> > jacopo mondi  escreveu:
> >   
> > > Hi Mauro,
> > > 
> > > On Tue, Oct 30, 2018 at 09:14:09AM -0300, Mauro Carvalho Chehab wrote:  
> > > > Em Tue, 30 Oct 2018 01:21:34 +0200
> > > > Sakari Ailus  escreveu:
> > > >
> > > > > The SoC camera framework has been obsolete for some time and it is no
> > > > > longer functional. A few drivers have been converted to the V4L2
> > > > > sub-device API but for the rest the conversion has not taken place 
> > > > > yet.
> > > > >
> > > > > In order to keep the tree clean and to avoid keep maintaining
> > > > > non-functional and obsolete code, remove the SoC camera framework as 
> > > > > well
> > > > > as the drivers that depend on it.
> > > > >
> > > > > Signed-off-by: Sakari Ailus 
> > > > > ---
> > > > > Resending, this time with git format-patch -D .
> > > > >
> > > > >  MAINTAINERS|8 -
> > > > >  drivers/media/i2c/Kconfig  |8 -
> > > > >  drivers/media/i2c/Makefile |1 -
> > > > >  drivers/media/i2c/soc_camera/Kconfig   |   66 -
> > > > >  drivers/media/i2c/soc_camera/Makefile  |   10 -
> > > > >  drivers/media/i2c/soc_camera/ov9640.h  |  208 --
> > > > >  drivers/media/i2c/soc_camera/soc_mt9m001.c |  757 ---
> > > > >  drivers/media/i2c/soc_camera/soc_mt9t112.c | 1157 ---
> > > > >  drivers/media/i2c/soc_camera/soc_mt9v022.c | 1012 -
> > > > >  drivers/media/i2c/soc_camera/soc_ov5642.c  | 1087 --
> > > > >  drivers/media/i2c/soc_camera/soc_ov772x.c  | 1123 --
> > > > >  drivers/media/i2c/soc_camera/soc_ov9640.c  |  738 ---
> > > > >  drivers/media/i2c/soc_camera/soc_ov9740.c  |  996 -
> > > > >  drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c  | 1415 
> > > > > -
> > > > >  drivers/media/i2c/soc_camera/soc_tw9910.c  |  999 -  
> > > > >   
> > > >
> > > > I don't see why we should remove those. I mean, Jacopo is
> > > > actually converting those drivers to not depend on soc_camera,
> > > > and it is a way better to review those patches with the old
> > > > code in place.
> > > 
> > > I have converted a few drivers used by some SH boards where I dropped
> > > dependencies on soc_camera, not to remove camera support from those. For
> > > others I don't have cameras to test with, nor I know about boards in
> > > mainline using them.
> > > 
> > > From my side, driver conversion is done.
> > >   
> > > >
> > > > So, at least while Jacopo is keep doing this work, I would keep
> > > > at Kernel tree, as it helps to see a diff when the driver changes
> > > > when getting rid of soc_camera dependencies.
> > > >
> > > > So, IMO, the best would be to move those to /staging, eventually
> > > > depending on BROKEN.
> > > 
> > > However, somebody with a (rather old) development setup using those camera
> > > sensor may wants to see if mainline supports them. We actually had a
> > > few patches coming lately (for ov. I understand Sakari's argument that 
> > > those
> > > could be retrieved from git history, but a few people will notice imo.
> > > I also understand the additional maintainership burden of keeping them
> > > around, so I'm fine with either ways ;)
> > > 
> > > This is a list of the current situation in mainline, to have a better
> > > idea:
> > > 
> > > $for i in `seq 1 9`; do CAM=$(head -n $i /tmp/soc_cams | tail -n 1); echo 
> > >  $CAM; find drivers/media/ -name  $CAM; done
> > > t9m001.c
> > > drivers/media/i2c/soc_camera/mt9m001.c
> > > mt9t112.c
> > > drivers/media/i2c/mt9t112.c
> > > drivers/media/i2c/soc_camera/mt9t112.c
> > > mt9v022.c
> > > drivers/media/i2c/soc_camera/mt9v022.c
> > > ov5642.c
> > > drivers/media/i2c/soc_c

Re: [PATCH 4/4] SoC camera: Tidy the header

[Mauro Carvalho Chehab]

Em Wed, 31 Oct 2018 11:29:45 +0200
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Tue, Oct 30, 2018 at 09:06:18AM -0300, Mauro Carvalho Chehab wrote:
> > Em Tue, 30 Oct 2018 01:00:29 +0200
> > Sakari Ailus  escreveu:
> >   
> > > Clean up the SoC camera framework header. It only exists now to keep board
> > > code compiling. The header can be removed once the board code dependencies
> > > to it has been removed.
> > > 
> > > Signed-off-by: Sakari Ailus 
> > > ---
> > >  include/media/soc_camera.h | 335 
> > > -
> > >  1 file changed, 335 deletions(-)
> > > 
> > > diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> > > index b7e42a1b0910..14d19da6052a 100644
> > > --- a/include/media/soc_camera.h
> > > +++ b/include/media/soc_camera.h
> > > @@ -22,172 +22,6 @@
> > >  #include 
> > >  #include   
> > 
> > That doesn't make any sense. soc_camera.h should have the same fate
> > as the entire soc_camera infrastructure: either be removed or moved
> > to staging, and everything else that doesn't have the same fate
> > should get rid of this header.  
> 
> We can't just remove this; there is board code that depends on it.
> 
> The intent is to remove the board code as well but presuming that the board
> code would be merged through a different tree, it'd be less hassle to wait
> a bit; hence the patch removing any unnecessary stuff here.

Then we need *first* to remove board code, wait for those changes to be
applied and *then* remove soc_camera (and not the opposite).

Thanks,
Mauro

Re: [PATCH 4/4] SoC camera: Tidy the header

[Mauro Carvalho Chehab]

Em Tue, 30 Oct 2018 01:00:29 +0200
Sakari Ailus  escreveu:

> Clean up the SoC camera framework header. It only exists now to keep board
> code compiling. The header can be removed once the board code dependencies
> to it has been removed.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  include/media/soc_camera.h | 335 
> -
>  1 file changed, 335 deletions(-)
> 
> diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> index b7e42a1b0910..14d19da6052a 100644
> --- a/include/media/soc_camera.h
> +++ b/include/media/soc_camera.h
> @@ -22,172 +22,6 @@
>  #include 
>  #include 

That doesn't make any sense. soc_camera.h should have the same fate
as the entire soc_camera infrastructure: either be removed or moved
to staging, and everything else that doesn't have the same fate
should get rid of this header.

Regards,
Mauro

>  
> -struct file;
> -struct soc_camera_desc;
> -struct soc_camera_async_client;
> -
> -struct soc_camera_device {
> - struct list_head list;  /* list of all registered devices */
> - struct soc_camera_desc *sdesc;
> - struct device *pdev;/* Platform device */
> - struct device *parent;  /* Camera host device */
> - struct device *control; /* E.g., the i2c client */
> - s32 user_width;
> - s32 user_height;
> - u32 bytesperline;   /* for padding, zero if unused */
> - u32 sizeimage;
> - enum v4l2_colorspace colorspace;
> - unsigned char iface;/* Host number */
> - unsigned char devnum;   /* Device number per host */
> - struct soc_camera_sense *sense; /* See comment in struct definition */
> - struct video_device *vdev;
> - struct v4l2_ctrl_handler ctrl_handler;
> - const struct soc_camera_format_xlate *current_fmt;
> - struct soc_camera_format_xlate *user_formats;
> - int num_user_formats;
> - enum v4l2_field field;  /* Preserve field over close() */
> - void *host_priv;/* Per-device host private data */
> - /* soc_camera.c private count. Only accessed with .host_lock held */
> - int use_count;
> - struct file *streamer;  /* stream owner */
> - struct v4l2_clk *clk;
> - /* Asynchronous subdevice management */
> - struct soc_camera_async_client *sasc;
> - /* video buffer queue */
> - struct vb2_queue vb2_vidq;
> -};
> -
> -/* Host supports programmable stride */
> -#define SOCAM_HOST_CAP_STRIDE(1 << 0)
> -
> -enum soc_camera_subdev_role {
> - SOCAM_SUBDEV_DATA_SOURCE = 1,
> - SOCAM_SUBDEV_DATA_SINK,
> - SOCAM_SUBDEV_DATA_PROCESSOR,
> -};
> -
> -struct soc_camera_async_subdev {
> - struct v4l2_async_subdev asd;
> - enum soc_camera_subdev_role role;
> -};
> -
> -struct soc_camera_host {
> - struct v4l2_device v4l2_dev;
> - struct list_head list;
> - struct mutex host_lock; /* Main synchronisation lock */
> - struct mutex clk_lock;  /* Protect pipeline modifications */
> - unsigned char nr;   /* Host number */
> - u32 capabilities;
> - struct soc_camera_device *icd;  /* Currently attached client */
> - void *priv;
> - const char *drv_name;
> - struct soc_camera_host_ops *ops;
> - struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
> - unsigned int *asd_sizes;/* 0-terminated array of asd group 
> sizes */
> -};
> -
> -struct soc_camera_host_ops {
> - struct module *owner;
> - int (*add)(struct soc_camera_device *);
> - void (*remove)(struct soc_camera_device *);
> - int (*clock_start)(struct soc_camera_host *);
> - void (*clock_stop)(struct soc_camera_host *);
> - /*
> -  * .get_formats() is called for each client device format, but
> -  * .put_formats() is only called once. Further, if any of the calls to
> -  * .get_formats() fail, .put_formats() will not be called at all, the
> -  * failing .get_formats() must then clean up internally.
> -  */
> - int (*get_formats)(struct soc_camera_device *, unsigned int,
> -struct soc_camera_format_xlate *);
> - void (*put_formats)(struct soc_camera_device *);
> - int (*get_selection)(struct soc_camera_device *, struct v4l2_selection 
> *);
> - int (*set_selection)(struct soc_camera_device *, struct v4l2_selection 
> *);
> - /*
> -  * The difference to .set_selection() is, that .set_liveselection is 
> not allowed
> -  * to change the output sizes
> -  */
> - int (*set_liveselection)(struct soc_camera_device *, struct 
> v4l2_selection *);
> - int (*set_fmt)(struct soc_camera_device *, struct v4l2_format *);
> - int (*try_fmt)(struct soc_camera_device *, struct v4l2_format *);
> - int (*init_videobuf2)(struct vb2_queue *,
> -   struct soc_camera_device *);
> - int (*querycap)(struct soc_camera_host *, struct 

Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers

[Mauro Carvalho Chehab]

Em Tue, 30 Oct 2018 01:21:34 +0200
Sakari Ailus  escreveu:

> The SoC camera framework has been obsolete for some time and it is no
> longer functional. A few drivers have been converted to the V4L2
> sub-device API but for the rest the conversion has not taken place yet.
> 
> In order to keep the tree clean and to avoid keep maintaining
> non-functional and obsolete code, remove the SoC camera framework as well
> as the drivers that depend on it.
> 
> Signed-off-by: Sakari Ailus 
> ---
> Resending, this time with git format-patch -D .
> 
>  MAINTAINERS|8 -
>  drivers/media/i2c/Kconfig  |8 -
>  drivers/media/i2c/Makefile |1 -
>  drivers/media/i2c/soc_camera/Kconfig   |   66 -
>  drivers/media/i2c/soc_camera/Makefile  |   10 -
>  drivers/media/i2c/soc_camera/ov9640.h  |  208 --
>  drivers/media/i2c/soc_camera/soc_mt9m001.c |  757 ---
>  drivers/media/i2c/soc_camera/soc_mt9t112.c | 1157 ---
>  drivers/media/i2c/soc_camera/soc_mt9v022.c | 1012 -
>  drivers/media/i2c/soc_camera/soc_ov5642.c  | 1087 --
>  drivers/media/i2c/soc_camera/soc_ov772x.c  | 1123 --
>  drivers/media/i2c/soc_camera/soc_ov9640.c  |  738 ---
>  drivers/media/i2c/soc_camera/soc_ov9740.c  |  996 -
>  drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c  | 1415 -
>  drivers/media/i2c/soc_camera/soc_tw9910.c  |  999 -

I don't see why we should remove those. I mean, Jacopo is
actually converting those drivers to not depend on soc_camera,
and it is a way better to review those patches with the old
code in place.

IMHO, the best would be to move those to /staging, eventually
depending on BROKEN.

>  drivers/media/platform/Kconfig |1 -
>  drivers/media/platform/Makefile|2 -
>  drivers/media/platform/soc_camera/Kconfig  |   26 -
>  drivers/media/platform/soc_camera/Makefile |9 -
>  .../platform/soc_camera/sh_mobile_ceu_camera.c | 1810 
>  drivers/media/platform/soc_camera/soc_camera.c | 2169 
> 
>  .../platform/soc_camera/soc_camera_platform.c  |  188 --
>  drivers/media/platform/soc_camera/soc_mediabus.c   |  533 -
>  drivers/media/platform/soc_camera/soc_scale_crop.c |  426 
>  drivers/media/platform/soc_camera/soc_scale_crop.h |   47 -
>  drivers/staging/media/Kconfig  |4 -
>  drivers/staging/media/Makefile |2 -
>  drivers/staging/media/imx074/Kconfig   |5 -
>  drivers/staging/media/imx074/Makefile  |1 -
>  drivers/staging/media/imx074/TODO  |5 -
>  drivers/staging/media/imx074/imx074.c  |  496 -
>  drivers/staging/media/mt9t031/Kconfig  |5 -
>  drivers/staging/media/mt9t031/Makefile |1 -
>  drivers/staging/media/mt9t031/TODO |5 -
>  drivers/staging/media/mt9t031/mt9t031.c|  857 
>  35 files changed, 16177 deletions(-)
>  delete mode 100644 drivers/media/i2c/soc_camera/Kconfig
>  delete mode 100644 drivers/media/i2c/soc_camera/Makefile
>  delete mode 100644 drivers/media/i2c/soc_camera/ov9640.h
>  delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9m001.c
>  delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9t112.c
>  delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9v022.c
>  delete mode 100644 drivers/media/i2c/soc_camera/soc_ov5642.c
>  delete mode 100644 drivers/media/i2c/soc_camera/soc_ov772x.c
>  delete mode 100644 drivers/media/i2c/soc_camera/soc_ov9640.c
>  delete mode 100644 drivers/media/i2c/soc_camera/soc_ov9740.c
>  delete mode 100644 drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c
>  delete mode 100644 drivers/media/i2c/soc_camera/soc_tw9910.c
>  delete mode 100644 drivers/media/platform/soc_camera/Kconfig
>  delete mode 100644 drivers/media/platform/soc_camera/Makefile
>  delete mode 100644 drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
>  delete mode 100644 drivers/media/platform/soc_camera/soc_camera.c
>  delete mode 100644 drivers/media/platform/soc_camera/soc_camera_platform.c
>  delete mode 100644 drivers/media/platform/soc_camera/soc_mediabus.c
>  delete mode 100644 drivers/media/platform/soc_camera/soc_scale_crop.c
>  delete mode 100644 drivers/media/platform/soc_camera/soc_scale_crop.h
>  delete mode 100644 drivers/staging/media/imx074/Kconfig
>  delete mode 100644 drivers/staging/media/imx074/Makefile
>  delete mode 100644 drivers/staging/media/imx074/TODO
>  delete mode 100644 drivers/staging/media/imx074/imx074.c
>  delete mode 100644 drivers/staging/media/mt9t031/Kconfig
>  delete mode 100644 drivers/staging/media/mt9t031/Makefile
>  delete mode 100644 drivers/staging/media/mt9t031/TODO
>  delete mode 100644 

Re: Adding to input-event-codes.h - feedback welcome

[Mauro Carvalho Chehab]

Em Tue, 23 Oct 2018 06:55:13 -0700
VDR User  escreveu:

> Hi,
> 
> I've noticed a lot of common & useful remote control buttons are
> missing. I'd like to suggest or submit patches to add some of them
> since Linux is so wildly used for media playback (via remote
> controls). I've spoken to Sean Young (and cc'ed him here), who does a
> ton with Linux rc, and he agrees it would be good to add them. Once
> added to input-event-codes.h, we could then start adding/updating rc
> keymaps accordingly.

As those keys are related to remote controllers, better to c/c the
Linux Media mailing list.

Btw, I agree with you here with regards to the idea: there are several
keys that are commonly found on remote controllers and are not easy
to map into the ones defined by input-event-codes.h.

We even had to add a table at media documentation, in order to
describe how each key should be mapped:

Documentation/media/uapi/rc/rc-tables.rst

IMHO, nowadays I would actually try to review such documentation
and eventually move it to Documentation/input, as there are several
cases where it is not trivial to map an specific key to the
Linux key code.

Still, I think that this discussion could be more productive if
you submit it as a patch (or a patch series).

> 
> The following is a list of (common) keys I'd like to propose be added. Please
> let us know what you think.
> 
> KEY_LIVE_TV: Jump directly to live tv view (from watching recordings,
> menus, VOD, etc). KEY_TV exists but only to select a "TV" input device
> but not related to the actual content being watched.
> 
> KEY_PIP: Toggle Picture-In-Picture on/off.
> 
> KEY_PIP_POSITION: Used to change PIP window position (typically upper left,
> lower left, lower right, upper right)
> 
> KEY_PIP_SWAP: Used to swap the main & PIP windows contents. (KEY_AB
> exists but is broad and could already be used for another function
> such as swapping audio outputs.)

Yeah, those seem to be missing.

> 
> KEY_USER1...KEY_USER16: Provide user-defined keys for special buttons
> that a remote control may have that are usable but may not be labeled
> to a specific common action. For example, we use Dish Network remote
> controls with our Linux-based htpc's - There's "DISH" and "Dish On
> Demand" buttons that are usable but not related to a common action.
> With KEY_USER* they could be mapped and used however the user wants.
> 16 user keys may be a lot, and 8 could be a better number, but any
> less than that is too limiting.

There are actually KEY_RED & friends that are normally used for
user-defined keys.

Not sure if I like the idea of a KEY_USER?, as it may mean that the
same key would be mapped different on different remote controllers.

We might be using KEY_FN?? or BTN_* for those, but I guess that
this is also not a good idea.

> 
> Any feedback or suggestions is appreciated.
> 
> Best regards,
> Derek



Thanks,
Mauro

Re: [PATCH] dvb: Allow MAC addresses to be mapped to stable device names with udev

[Mauro Carvalho Chehab]

Em Mon, 24 Sep 2018 11:10:31 +0100
David Howells  escreveu:

> Some devices, such as the DVBSky S952 and T982 cards, are dual port cards
> that provide two cx23885 devices on the same PCI device, which means the
> attributes available for writing udev rules are exactly the same, apart
> from the adapter number.  Unfortunately, the adapter numbers are dependent
> on the order in which things are initialised, so this can change over
> different releases of the kernel.
> 
> Devices have a MAC address available, which is printed during boot:
> 
>   [   10.951517] DVBSky T982 port 1 MAC address: 00:11:22:33:44:55
>   ...
>   [   10.984875] DVBSky T982 port 2 MAC address: 00:11:22:33:44:56
> 
> To make it possible to distinguish these in udev, provide sysfs attributes
> to make the MAC address, adapter number and type available.  There are
> other fields that could perhaps be exported also.  In particular, it would
> be nice to provide the port number, but somehow that doesn't manage to
> propagate through the labyrinthine initialisation process.
> 
> The new sysfs attributes can be seen from userspace as:
> 
>   [root@deneb ~]# ls /sys/class/dvb/dvb0.frontend0/
>   dev  device  dvb_adapter  dvb_mac  dvb_type
>   power  subsystem  uevent
>   [root@deneb ~]# cat /sys/class/dvb/dvb0.frontend0/dvb_*
>   0
>   00:11:22:33:44:55
>   frontend
> 
> They can be used in udev rules:
> 
>   SUBSYSTEM=="dvb", ATTRS{vendor}=="0x14f1", ATTRS{device}=="0x8852", 
> ATTRS{subsystem_device}=="0x0982", ATTR{dvb_mac}=="00:11:22:33:44:55", 
> PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter9820/%%s 
> $${K#*.}'", SYMLINK+="%c"
>   SUBSYSTEM=="dvb", ATTRS{vendor}=="0x14f1", ATTRS{device}=="0x8852", 
> ATTRS{subsystem_device}=="0x0982", ATTR{dvb_mac}=="00:11.22.33.44.56", 
> PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter9821/%%s 
> $${K#*.}'", SYMLINK+="%c"
> 
> where the match is made with ATTR{dvb_mac} or similar.  The rules above
> make symlinks from /dev/dvb/adapter982/* to /dev/dvb/adapterXX/*.
> 
> Note that binding the dvb-net device to a network interface and changing it
> there does not reflect back into the the dvb_adapter struct and doesn't
> change the MAC address here.  This means that a system with two identical
> cards in it may need to distinguish them by some other means than MAC
> address.
> 
> Signed-off-by: David Howells 

Looks OK to me.

Michael/Sean/Brad,

Any comments? If not, I'll probably submit it this week upstream.


> ---
> 
>  Documentation/ABI/testing/sysfs-class-dvb |   29 +++
>  Documentation/media/dvb-drivers/udev.rst  |   29 +++
>  Documentation/media/uapi/dvb/intro.rst|7 +++
>  Documentation/media/uapi/dvb/stable_names.rst |   66 
> +
>  drivers/media/dvb-core/dvbdev.c   |   36 ++
>  5 files changed, 167 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-dvb
>  create mode 100644 Documentation/media/uapi/dvb/stable_names.rst
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-dvb 
> b/Documentation/ABI/testing/sysfs-class-dvb
> new file mode 100644
> index ..09e3be329c92
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-dvb
> @@ -0,0 +1,29 @@
> +What:/sys/class/dvb/.../dvb_adapter
> +Date:September 2018
> +KernelVersion:   4.20
> +Contact: David Howells 
> +Description:
> + This displays the assigned adapter number of a DVB device.
> +
> +What:/sys/class/dvb/.../dvb_mac
> +Date:September 2018
> +KernelVersion:   4.20
> +Contact: David Howells 
> +Description:
> + This displays the mac address of a DVB device.  This can be
> + used by udev to name stable device files for DVB devices and
> + avoid problems with changes in the order of device
> + initialisation changing the assigned device numbers.  See:
> +
> + Documentation/media/dvb-drivers/udev.rst
> + Documentation/media/uapi/dvb/stable_names.rst
> +
> + for information on how to actually do this.
> +
> +What:/sys/class/dvb/.../dvb_type
> +Date:September 2018
> +KernelVersion:   4.20
> +Contact: David Howells 
> +Description:
> + This displays the object type of a DVB device interface, such
> + as "frontend" or "demux".
> diff --git a/Documentation/media/dvb-drivers/udev.rst 
> b/Documentation/media/dvb-drivers/udev.rst
> index 7d7d5d82108a..df754312f1f4 100644
> --- a/Documentation/media/dvb-drivers/udev.rst
> +++ b/Documentation/media/dvb-drivers/udev.rst
> @@ -59,3 +59,32 @@ have a look at "man udev".
>  For every device that registers to the sysfs subsystem with a "dvb" prefix,
>  the helper script /etc/udev/scripts/dvb.sh is invoked, which will then
>  create the proper device node in 

Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers

[Mauro Carvalho Chehab]

Em Tue, 30 Oct 2018 09:06:08 -0300
Mauro Carvalho Chehab  escreveu:

> Em Tue, 30 Oct 2018 06:43:41 -0300
> Mauro Carvalho Chehab  escreveu:

Please ignore this e-mail. I'm experiencing some e-mail troubles today.

Will resend it properly.

Regards,
Mauro

Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers

[Mauro Carvalho Chehab]

Em Tue, 30 Oct 2018 06:43:41 -0300
Mauro Carvalho Chehab  escreveu:

> Em Tue, 30 Oct 2018 01:21:34 +0200
> Sakari Ailus  escreveu:
> 
> > The SoC camera framework has been obsolete for some time and it is no
> > longer functional. A few drivers have been converted to the V4L2
> > sub-device API but for the rest the conversion has not taken place yet.
> > 
> > In order to keep the tree clean and to avoid keep maintaining
> > non-functional and obsolete code, remove the SoC camera framework as well
> > as the drivers that depend on it.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> > Resending, this time with git format-patch -D .
> > 
> >  MAINTAINERS|8 -
> >  drivers/media/i2c/Kconfig  |8 -
> >  drivers/media/i2c/Makefile |1 -
> >  drivers/media/i2c/soc_camera/Kconfig   |   66 -
> >  drivers/media/i2c/soc_camera/Makefile  |   10 -
> >  drivers/media/i2c/soc_camera/ov9640.h  |  208 --
> >  drivers/media/i2c/soc_camera/soc_mt9m001.c |  757 ---
> >  drivers/media/i2c/soc_camera/soc_mt9t112.c | 1157 ---
> >  drivers/media/i2c/soc_camera/soc_mt9v022.c | 1012 -
> >  drivers/media/i2c/soc_camera/soc_ov5642.c  | 1087 --
> >  drivers/media/i2c/soc_camera/soc_ov772x.c  | 1123 --
> >  drivers/media/i2c/soc_camera/soc_ov9640.c  |  738 ---
> >  drivers/media/i2c/soc_camera/soc_ov9740.c  |  996 -
> >  drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c  | 1415 -
> >  drivers/media/i2c/soc_camera/soc_tw9910.c  |  999 -  
> 
> I don't see why we should remove those. I mean, Jacopo is
> actually converting those drivers to not depend on soc_camera,
> and it is a way better to review those patches with the old
> code in place.
> 
> IMHO, the best would be to move those to /staging, eventually
> depending on BROKEN.
> 
> >  drivers/media/platform/Kconfig |1 -
> >  drivers/media/platform/Makefile|2 -
> >  drivers/media/platform/soc_camera/Kconfig  |   26 -
> >  drivers/media/platform/soc_camera/Makefile |9 -
> >  .../platform/soc_camera/sh_mobile_ceu_camera.c | 1810 
> >  drivers/media/platform/soc_camera/soc_camera.c | 2169 
> > 
> >  .../platform/soc_camera/soc_camera_platform.c  |  188 --
> >  drivers/media/platform/soc_camera/soc_mediabus.c   |  533 -
> >  drivers/media/platform/soc_camera/soc_scale_crop.c |  426 
> >  drivers/media/platform/soc_camera/soc_scale_crop.h |   47 -
> >  drivers/staging/media/Kconfig  |4 -
> >  drivers/staging/media/Makefile |2 -
> >  drivers/staging/media/imx074/Kconfig   |5 -
> >  drivers/staging/media/imx074/Makefile  |1 -
> >  drivers/staging/media/imx074/TODO  |5 -
> >  drivers/staging/media/imx074/imx074.c  |  496 -
> >  drivers/staging/media/mt9t031/Kconfig  |5 -
> >  drivers/staging/media/mt9t031/Makefile |1 -
> >  drivers/staging/media/mt9t031/TODO |5 -
> >  drivers/staging/media/mt9t031/mt9t031.c|  857 
> >  35 files changed, 16177 deletions(-)
> >  delete mode 100644 drivers/media/i2c/soc_camera/Kconfig
> >  delete mode 100644 drivers/media/i2c/soc_camera/Makefile
> >  delete mode 100644 drivers/media/i2c/soc_camera/ov9640.h
> >  delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9m001.c
> >  delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9t112.c
> >  delete mode 100644 drivers/media/i2c/soc_camera/soc_mt9v022.c
> >  delete mode 100644 drivers/media/i2c/soc_camera/soc_ov5642.c
> >  delete mode 100644 drivers/media/i2c/soc_camera/soc_ov772x.c
> >  delete mode 100644 drivers/media/i2c/soc_camera/soc_ov9640.c
> >  delete mode 100644 drivers/media/i2c/soc_camera/soc_ov9740.c
> >  delete mode 100644 drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c
> >  delete mode 100644 drivers/media/i2c/soc_camera/soc_tw9910.c
> >  delete mode 100644 drivers/media/platform/soc_camera/Kconfig
> >  delete mode 100644 drivers/media/platform/soc_camera/Makefile
> >  delete mode 100644 drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
> >  delete mode 100644 drivers/media/platform/soc_camera/soc_camera.c
> >  delete mode 100644 drivers/media/platform/soc_camera/soc_camera_platform.c
> >  delete

Re: [PATCH 4/4] SoC camera: Tidy the header

[Mauro Carvalho Chehab]

Em Tue, 30 Oct 2018 01:00:29 +0200
Sakari Ailus  escreveu:

> Clean up the SoC camera framework header. It only exists now to keep board
> code compiling. The header can be removed once the board code dependencies
> to it has been removed.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  include/media/soc_camera.h | 335 
> -
>  1 file changed, 335 deletions(-)
> 
> diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> index b7e42a1b0910..14d19da6052a 100644
> --- a/include/media/soc_camera.h
> +++ b/include/media/soc_camera.h
> @@ -22,172 +22,6 @@
>  #include 
>  #include 

That doesn't make any sense. soc_camera.h should have the same fate
as the entire soc_camera infrastructure: either be removed or moved
to staging, and everything else that doesn't have the same fate
should get rid of this header.

Regards,
Mauro

>  
> -struct file;
> -struct soc_camera_desc;
> -struct soc_camera_async_client;
> -
> -struct soc_camera_device {
> - struct list_head list;  /* list of all registered devices */
> - struct soc_camera_desc *sdesc;
> - struct device *pdev;/* Platform device */
> - struct device *parent;  /* Camera host device */
> - struct device *control; /* E.g., the i2c client */
> - s32 user_width;
> - s32 user_height;
> - u32 bytesperline;   /* for padding, zero if unused */
> - u32 sizeimage;
> - enum v4l2_colorspace colorspace;
> - unsigned char iface;/* Host number */
> - unsigned char devnum;   /* Device number per host */
> - struct soc_camera_sense *sense; /* See comment in struct definition */
> - struct video_device *vdev;
> - struct v4l2_ctrl_handler ctrl_handler;
> - const struct soc_camera_format_xlate *current_fmt;
> - struct soc_camera_format_xlate *user_formats;
> - int num_user_formats;
> - enum v4l2_field field;  /* Preserve field over close() */
> - void *host_priv;/* Per-device host private data */
> - /* soc_camera.c private count. Only accessed with .host_lock held */
> - int use_count;
> - struct file *streamer;  /* stream owner */
> - struct v4l2_clk *clk;
> - /* Asynchronous subdevice management */
> - struct soc_camera_async_client *sasc;
> - /* video buffer queue */
> - struct vb2_queue vb2_vidq;
> -};
> -
> -/* Host supports programmable stride */
> -#define SOCAM_HOST_CAP_STRIDE(1 << 0)
> -
> -enum soc_camera_subdev_role {
> - SOCAM_SUBDEV_DATA_SOURCE = 1,
> - SOCAM_SUBDEV_DATA_SINK,
> - SOCAM_SUBDEV_DATA_PROCESSOR,
> -};
> -
> -struct soc_camera_async_subdev {
> - struct v4l2_async_subdev asd;
> - enum soc_camera_subdev_role role;
> -};
> -
> -struct soc_camera_host {
> - struct v4l2_device v4l2_dev;
> - struct list_head list;
> - struct mutex host_lock; /* Main synchronisation lock */
> - struct mutex clk_lock;  /* Protect pipeline modifications */
> - unsigned char nr;   /* Host number */
> - u32 capabilities;
> - struct soc_camera_device *icd;  /* Currently attached client */
> - void *priv;
> - const char *drv_name;
> - struct soc_camera_host_ops *ops;
> - struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
> - unsigned int *asd_sizes;/* 0-terminated array of asd group 
> sizes */
> -};
> -
> -struct soc_camera_host_ops {
> - struct module *owner;
> - int (*add)(struct soc_camera_device *);
> - void (*remove)(struct soc_camera_device *);
> - int (*clock_start)(struct soc_camera_host *);
> - void (*clock_stop)(struct soc_camera_host *);
> - /*
> -  * .get_formats() is called for each client device format, but
> -  * .put_formats() is only called once. Further, if any of the calls to
> -  * .get_formats() fail, .put_formats() will not be called at all, the
> -  * failing .get_formats() must then clean up internally.
> -  */
> - int (*get_formats)(struct soc_camera_device *, unsigned int,
> -struct soc_camera_format_xlate *);
> - void (*put_formats)(struct soc_camera_device *);
> - int (*get_selection)(struct soc_camera_device *, struct v4l2_selection 
> *);
> - int (*set_selection)(struct soc_camera_device *, struct v4l2_selection 
> *);
> - /*
> -  * The difference to .set_selection() is, that .set_liveselection is 
> not allowed
> -  * to change the output sizes
> -  */
> - int (*set_liveselection)(struct soc_camera_device *, struct 
> v4l2_selection *);
> - int (*set_fmt)(struct soc_camera_device *, struct v4l2_format *);
> - int (*try_fmt)(struct soc_camera_device *, struct v4l2_format *);
> - int (*init_videobuf2)(struct vb2_queue *,
> -   struct soc_camera_device *);
> - int (*querycap)(struct soc_camera_host *, struct 

Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers

[Mauro Carvalho Chehab]

Em Tue, 30 Oct 2018 01:21:34 +0200
Sakari Ailus  escreveu:

> The SoC camera framework has been obsolete for some time and it is no
> longer functional. A few drivers have been converted to the V4L2
> sub-device API but for the rest the conversion has not taken place yet.
> 
> In order to keep the tree clean and to avoid keep maintaining
> non-functional and obsolete code, remove the SoC camera framework as well
> as the drivers that depend on it.
> 
> Signed-off-by: Sakari Ailus 
> ---
> Resending, this time with git format-patch -D .
> 
>  MAINTAINERS|8 -
>  drivers/media/i2c/Kconfig  |8 -
>  drivers/media/i2c/Makefile |1 -
>  drivers/media/i2c/soc_camera/Kconfig   |   66 -
>  drivers/media/i2c/soc_camera/Makefile  |   10 -
>  drivers/media/i2c/soc_camera/ov9640.h  |  208 --
>  drivers/media/i2c/soc_camera/soc_mt9m001.c |  757 ---
>  drivers/media/i2c/soc_camera/soc_mt9t112.c | 1157 ---
>  drivers/media/i2c/soc_camera/soc_mt9v022.c | 1012 -
>  drivers/media/i2c/soc_camera/soc_ov5642.c  | 1087 --
>  drivers/media/i2c/soc_camera/soc_ov772x.c  | 1123 --
>  drivers/media/i2c/soc_camera/soc_ov9640.c  |  738 ---
>  drivers/media/i2c/soc_camera/soc_ov9740.c  |  996 -
>  drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c  | 1415 -
>  drivers/media/i2c/soc_camera/soc_tw9910.c  |  999 -  

I don't see why we should remove those. I mean, Jacopo is
actually converting those drivers to not depend on soc_camera,
and it is a way better to review those patches with the old
code in place.

So, at least while Jacopo is keep doing this work, I would keep
at Kernel tree, as it helps to see a diff when the driver changes
when getting rid of soc_camera dependencies.

So, IMO, the best would be to move those to /staging, eventually
depending on BROKEN.

Thanks,
Mauro

Re: Kaffeine: cool pull request in GitHub

[Mauro Carvalho Chehab]

Hi Antoni,

Em Sun, 28 Oct 2018 01:02:39 +0200
Antoni Bella Pérez  escreveu:

>   Hi
> 
>   I found three pull request in GitHub and this code has not been included in 
> the master branch.
> 
>   
> 
>   * Fix audio CD playing
> #3 by mrandybu was closed a day ago 
> 
>   * Add support for parallel instant records
> #2 by kochstefan was closed on 17 Feb 
> 
>   * Fix compile on FreeBSD
> uest in GitHu#1 by arvedarved was closed on 3 May 2016
> 
>   I think that would be interesting include it to https://cgit.kde.org/
> kaffeine.git for next release. After your review... ;-)

Thank you for pointing it to me. That audio CD was broken for a long
time. Good to have it fixed.

I applied all 3 series. Not sure if the FreeBSD is really useful, as
AFAIKT the Linux DVB API is specific to Linux, but maybe someone 
backported it.

Anyway, it doesn't hurt applying it. 

Thanks,
Mauro

Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs

[Mauro Carvalho Chehab]

Em Mon, 22 Oct 2018 22:21:04 +0100
Hans Verkuil  escreveu:

> On 10/22/2018 10:17 PM, Hans Verkuil wrote:
> > A quick update:
> > 
> > As said in my previous email: we'll meet at 11 am at the registration desk.
> > From there we go to the Platform 5 Cafe. If that's too crowded/noisy, then
> > we'll try the Sheraton hotel.
> > 
> > Tomasz, I'll ping you on irc when we found a good spot and we can setup the
> > Hangouts meeting.

I'll be a little late to the meeting.

Still at hotel finishing my today's presentation.

Should be heading to EICC soon.

> 
> I forgot to mention: the spec with the Request API and the stateful+stateless
> codec API specification (latest patches from Tomasz and Alexandre) are 
> available
> here:
> 
> https://hverkuil.home.xs4all.nl/request-api/
> 
> Also CC-ed Alexandre and Phillip.
> 
> Regards,
> 
>   Hans
> 
> > 
> > Hope to see you all tomorrow,
> > 
> > Regards,
> > 
> > Hans
> > 
> > On 10/10/2018 07:55 AM, Hans Verkuil wrote:
> >> On 10/08/2018 01:53 PM, Hans Verkuil wrote:
> >>> Hi all,
> >>>
> >>> I would like to meet up somewhere during the ELCE to discuss userspace 
> >>> support
> >>> for stateless (and perhaps stateful as well?) codecs.
> >>>
> >>> It is also planned as a topic during the summit, but I would prefer to 
> >>> prepare
> >>> for that in advance, esp. since I myself do not have any experience 
> >>> writing
> >>> userspace SW for such devices.
> >>>
> >>> Nicolas, it would be really great if you can participate in this meeting
> >>> since you probably have the most experience with this by far.
> >>>
> >>> Looking through the ELCE program I found two timeslots that are likely to 
> >>> work
> >>> for most of us (because the topics in the program appear to be boring for 
> >>> us
> >>> media types!):
> >>>
> >>> Tuesday from 10:50-15:50
> >>
> >> Let's do this Tuesday. Let's meet at the Linux Foundation Registration
> >> Desk at 11:00. I'll try to figure out where we can sit the day before.
> >> Please check your email Tuesday morning for any last minute changes.
> >>
> >> Tomasz, it would be nice indeed if we can get you and Paul in as well
> >> using Hangouts on my laptop.
> >>
> >> I would very much appreciate it if those who have experience with the
> >> userspace support think about this beforehand and make some requirements
> >> list of what you would like to see.
> >>
> >> Regards,
> >>
> >>Hans
> >>
> >>>
> >>> or:
> >>>
> >>> Monday from 15:45 onward
> >>>
> >>> My guess is that we need 2-3 hours or so. Hard to predict.
> >>>
> >>> The basic question that I would like to have answered is what the 
> >>> userspace
> >>> component should look like? libv4l-like plugin or a library that 
> >>> userspace can
> >>> link with? Do we want more general support for stateful codecs as well 
> >>> that deals
> >>> with resolution changes and the more complex parts of the codec API?
> >>>
> >>> I've mailed this directly to those that I expect are most interested in 
> >>> this,
> >>> but if someone want to join in let me know.
> >>>
> >>> I want to keep the group small though, so you need to bring relevant 
> >>> experience
> >>> to the table.
> >>>
> >>> Regards,
> >>>
> >>>   Hans
> >>>
> >>
> > 
> 




Cheers,
Mauro

Re: [PATCH] media: rename soc_camera I2C drivers

[Mauro Carvalho Chehab]

Em Fri, 19 Oct 2018 13:45:32 +0200
Hans Verkuil  escreveu:

> On 10/19/18 13:43, Mauro Carvalho Chehab wrote:
> > Those drivers are part of the legacy SoC camera framework.
> > They're being converted to not use it, but sometimes we're
> > keeping both legacy any new driver.
> > 
> > This time, for example, we have two drivers on media with
> > the same name: ov772x. That's bad.
> > 
> > So, in order to prevent that to happen, let's prepend the SoC
> > legacy drivers with soc_.
> > 
> > No functional changes.
> > 
> > Signed-off-by: Mauro Carvalho Chehab   
> 
> Acked-by: Hans Verkuil 

For now, let's just avoid the conflict if one builds both modules and
do a modprobe ov772x.

> Let's kill all of these in the next kernel. I see no reason for keeping
> them around.

While people are doing those SoC conversions, I would keep it. We
could move it to staging, to let it clear that those drivers require
conversion, and give people some time to work on it.

In the specific case of ov772x, as we have already a driver that doesn't
require soc_camera, we can strip it for -next.

> 
> Regards,
> 
>   Hans
> 
> > ---
> >  drivers/media/i2c/soc_camera/Makefile  | 18 +-
> >  .../soc_camera/{mt9m001.c => soc_mt9m001.c}|  0
> >  .../soc_camera/{mt9t112.c => soc_mt9t112.c}|  0
> >  .../soc_camera/{mt9v022.c => soc_mt9v022.c}|  0
> >  .../i2c/soc_camera/{ov5642.c => soc_ov5642.c}  |  0
> >  .../i2c/soc_camera/{ov772x.c => soc_ov772x.c}  |  0
> >  .../i2c/soc_camera/{ov9640.c => soc_ov9640.c}  |  0
> >  .../i2c/soc_camera/{ov9740.c => soc_ov9740.c}  |  0
> >  .../{rj54n1cb0c.c => soc_rj54n1cb0c.c} |  0
> >  .../i2c/soc_camera/{tw9910.c => soc_tw9910.c}  |  0
> >  10 files changed, 9 insertions(+), 9 deletions(-)
> >  rename drivers/media/i2c/soc_camera/{mt9m001.c => soc_mt9m001.c} (100%)
> >  rename drivers/media/i2c/soc_camera/{mt9t112.c => soc_mt9t112.c} (100%)
> >  rename drivers/media/i2c/soc_camera/{mt9v022.c => soc_mt9v022.c} (100%)
> >  rename drivers/media/i2c/soc_camera/{ov5642.c => soc_ov5642.c} (100%)
> >  rename drivers/media/i2c/soc_camera/{ov772x.c => soc_ov772x.c} (100%)
> >  rename drivers/media/i2c/soc_camera/{ov9640.c => soc_ov9640.c} (100%)
> >  rename drivers/media/i2c/soc_camera/{ov9740.c => soc_ov9740.c} (100%)
> >  rename drivers/media/i2c/soc_camera/{rj54n1cb0c.c => soc_rj54n1cb0c.c} 
> > (100%)
> >  rename drivers/media/i2c/soc_camera/{tw9910.c => soc_tw9910.c} (100%)
> > 
> > diff --git a/drivers/media/i2c/soc_camera/Makefile 
> > b/drivers/media/i2c/soc_camera/Makefile
> > index 8c7770f62997..09ae483b96ef 100644
> > --- a/drivers/media/i2c/soc_camera/Makefile
> > +++ b/drivers/media/i2c/soc_camera/Makefile
> > @@ -1,10 +1,10 @@
> >  # SPDX-License-Identifier: GPL-2.0
> > -obj-$(CONFIG_SOC_CAMERA_MT9M001)   += mt9m001.o
> > -obj-$(CONFIG_SOC_CAMERA_MT9T112)   += mt9t112.o
> > -obj-$(CONFIG_SOC_CAMERA_MT9V022)   += mt9v022.o
> > -obj-$(CONFIG_SOC_CAMERA_OV5642)+= ov5642.o
> > -obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o
> > -obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o
> > -obj-$(CONFIG_SOC_CAMERA_OV9740)+= ov9740.o
> > -obj-$(CONFIG_SOC_CAMERA_RJ54N1)+= rj54n1cb0c.o
> > -obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o
> > +obj-$(CONFIG_SOC_CAMERA_MT9M001)   += soc_mt9m001.o
> > +obj-$(CONFIG_SOC_CAMERA_MT9T112)   += soc_mt9t112.o
> > +obj-$(CONFIG_SOC_CAMERA_MT9V022)   += soc_mt9v022.o
> > +obj-$(CONFIG_SOC_CAMERA_OV5642)+= soc_ov5642.o
> > +obj-$(CONFIG_SOC_CAMERA_OV772X)+= soc_ov772x.o
> > +obj-$(CONFIG_SOC_CAMERA_OV9640)+= soc_ov9640.o
> > +obj-$(CONFIG_SOC_CAMERA_OV9740)+= soc_ov9740.o
> > +obj-$(CONFIG_SOC_CAMERA_RJ54N1)+= soc_rj54n1cb0c.o
> > +obj-$(CONFIG_SOC_CAMERA_TW9910)+= soc_tw9910.o
> > diff --git a/drivers/media/i2c/soc_camera/mt9m001.c 
> > b/drivers/media/i2c/soc_camera/soc_mt9m001.c
> > similarity index 100%
> > rename from drivers/media/i2c/soc_camera/mt9m001.c
> > rename to drivers/media/i2c/soc_camera/soc_mt9m001.c
> > diff --git a/drivers/media/i2c/soc_camera/mt9t112.c 
> > b/drivers/media/i2c/soc_camera/soc_mt9t112.c
> > similarity index 100%
> > rename from drivers/media/i2c/soc_camera/mt9t112.c
> > rename to drivers/media/i2c/soc_camera/soc_mt9t112.c
> > diff --git a/drivers/media/i2c/soc_camera/mt9v022.c 
> > b/drivers/media/i2c/soc_camera/soc_mt9v022.c
> > similarit

[PATCH] media: rename soc_camera I2C drivers

[Mauro Carvalho Chehab]

Those drivers are part of the legacy SoC camera framework.
They're being converted to not use it, but sometimes we're
keeping both legacy any new driver.

This time, for example, we have two drivers on media with
the same name: ov772x. That's bad.

So, in order to prevent that to happen, let's prepend the SoC
legacy drivers with soc_.

No functional changes.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/soc_camera/Makefile  | 18 +-
 .../soc_camera/{mt9m001.c => soc_mt9m001.c}|  0
 .../soc_camera/{mt9t112.c => soc_mt9t112.c}|  0
 .../soc_camera/{mt9v022.c => soc_mt9v022.c}|  0
 .../i2c/soc_camera/{ov5642.c => soc_ov5642.c}  |  0
 .../i2c/soc_camera/{ov772x.c => soc_ov772x.c}  |  0
 .../i2c/soc_camera/{ov9640.c => soc_ov9640.c}  |  0
 .../i2c/soc_camera/{ov9740.c => soc_ov9740.c}  |  0
 .../{rj54n1cb0c.c => soc_rj54n1cb0c.c} |  0
 .../i2c/soc_camera/{tw9910.c => soc_tw9910.c}  |  0
 10 files changed, 9 insertions(+), 9 deletions(-)
 rename drivers/media/i2c/soc_camera/{mt9m001.c => soc_mt9m001.c} (100%)
 rename drivers/media/i2c/soc_camera/{mt9t112.c => soc_mt9t112.c} (100%)
 rename drivers/media/i2c/soc_camera/{mt9v022.c => soc_mt9v022.c} (100%)
 rename drivers/media/i2c/soc_camera/{ov5642.c => soc_ov5642.c} (100%)
 rename drivers/media/i2c/soc_camera/{ov772x.c => soc_ov772x.c} (100%)
 rename drivers/media/i2c/soc_camera/{ov9640.c => soc_ov9640.c} (100%)
 rename drivers/media/i2c/soc_camera/{ov9740.c => soc_ov9740.c} (100%)
 rename drivers/media/i2c/soc_camera/{rj54n1cb0c.c => soc_rj54n1cb0c.c} (100%)
 rename drivers/media/i2c/soc_camera/{tw9910.c => soc_tw9910.c} (100%)

diff --git a/drivers/media/i2c/soc_camera/Makefile 
b/drivers/media/i2c/soc_camera/Makefile
index 8c7770f62997..09ae483b96ef 100644
--- a/drivers/media/i2c/soc_camera/Makefile
+++ b/drivers/media/i2c/soc_camera/Makefile
@@ -1,10 +1,10 @@
 # SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_SOC_CAMERA_MT9M001)   += mt9m001.o
-obj-$(CONFIG_SOC_CAMERA_MT9T112)   += mt9t112.o
-obj-$(CONFIG_SOC_CAMERA_MT9V022)   += mt9v022.o
-obj-$(CONFIG_SOC_CAMERA_OV5642)+= ov5642.o
-obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o
-obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o
-obj-$(CONFIG_SOC_CAMERA_OV9740)+= ov9740.o
-obj-$(CONFIG_SOC_CAMERA_RJ54N1)+= rj54n1cb0c.o
-obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o
+obj-$(CONFIG_SOC_CAMERA_MT9M001)   += soc_mt9m001.o
+obj-$(CONFIG_SOC_CAMERA_MT9T112)   += soc_mt9t112.o
+obj-$(CONFIG_SOC_CAMERA_MT9V022)   += soc_mt9v022.o
+obj-$(CONFIG_SOC_CAMERA_OV5642)+= soc_ov5642.o
+obj-$(CONFIG_SOC_CAMERA_OV772X)+= soc_ov772x.o
+obj-$(CONFIG_SOC_CAMERA_OV9640)+= soc_ov9640.o
+obj-$(CONFIG_SOC_CAMERA_OV9740)+= soc_ov9740.o
+obj-$(CONFIG_SOC_CAMERA_RJ54N1)+= soc_rj54n1cb0c.o
+obj-$(CONFIG_SOC_CAMERA_TW9910)+= soc_tw9910.o
diff --git a/drivers/media/i2c/soc_camera/mt9m001.c 
b/drivers/media/i2c/soc_camera/soc_mt9m001.c
similarity index 100%
rename from drivers/media/i2c/soc_camera/mt9m001.c
rename to drivers/media/i2c/soc_camera/soc_mt9m001.c
diff --git a/drivers/media/i2c/soc_camera/mt9t112.c 
b/drivers/media/i2c/soc_camera/soc_mt9t112.c
similarity index 100%
rename from drivers/media/i2c/soc_camera/mt9t112.c
rename to drivers/media/i2c/soc_camera/soc_mt9t112.c
diff --git a/drivers/media/i2c/soc_camera/mt9v022.c 
b/drivers/media/i2c/soc_camera/soc_mt9v022.c
similarity index 100%
rename from drivers/media/i2c/soc_camera/mt9v022.c
rename to drivers/media/i2c/soc_camera/soc_mt9v022.c
diff --git a/drivers/media/i2c/soc_camera/ov5642.c 
b/drivers/media/i2c/soc_camera/soc_ov5642.c
similarity index 100%
rename from drivers/media/i2c/soc_camera/ov5642.c
rename to drivers/media/i2c/soc_camera/soc_ov5642.c
diff --git a/drivers/media/i2c/soc_camera/ov772x.c 
b/drivers/media/i2c/soc_camera/soc_ov772x.c
similarity index 100%
rename from drivers/media/i2c/soc_camera/ov772x.c
rename to drivers/media/i2c/soc_camera/soc_ov772x.c
diff --git a/drivers/media/i2c/soc_camera/ov9640.c 
b/drivers/media/i2c/soc_camera/soc_ov9640.c
similarity index 100%
rename from drivers/media/i2c/soc_camera/ov9640.c
rename to drivers/media/i2c/soc_camera/soc_ov9640.c
diff --git a/drivers/media/i2c/soc_camera/ov9740.c 
b/drivers/media/i2c/soc_camera/soc_ov9740.c
similarity index 100%
rename from drivers/media/i2c/soc_camera/ov9740.c
rename to drivers/media/i2c/soc_camera/soc_ov9740.c
diff --git a/drivers/media/i2c/soc_camera/rj54n1cb0c.c 
b/drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c
similarity index 100%
rename from drivers/media/i2c/soc_camera/rj54n1cb0c.c
rename to drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c
diff --git a/drivers/media/i2c/soc_camera/tw9910.c 
b/drivers/media/i2c/soc_camera/soc_tw9910.c
similarity index 100%
rename from drivers/med

Re: [ANN] Agenda for the media summit on Thursday Oct 25th in Edinburgh

[Mauro Carvalho Chehab]

Em Mon, 15 Oct 2018 13:36:08 +0200
Hans Verkuil  escreveu:

> Hi all,
> 
> We are organizing a media mini-summit on Thursday October 25th in
> Edinburgh, Edinburgh International Conference Centre.
> 
> If you plan to attend, please register on the ELCE/OSS site since we're
> using there tracking system:
> 
> https://events.linuxfoundation.org/events/elc-openiot-europe-2018/register/
> 
> Name of the room for the summit: Tinto, Level 0 of the EICC
> 
> We had 75 people sign up for the summit as of a week ago, which is quite
> amazing. I'm not listing all of them here, just those that I know are active
> media developers:

...

> Mauro Carvalho Chehab 

On a side note, please always use my @kernel.org e-mail,
e. g:
Mauro Carvalho Chehab 

(with is the canonical e-mail it is set at Kernel tree)
or
Mauro Carvalho Chehab 

(with also has my employer's name on it [1] that
 sponsors my work upstream)

I stopped using the s-opensource a while ago, and the server handling
it was even decommissioned those days.

Thanks,
Mauro

[1] Also, please notice that, except if I say otherwise, all
opinions, comments, etc. I post with such e-mail don't represent
my employer's opinion. It is just my way to thank Samsung for
sponsoring my upstream's work.

Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs

[Mauro Carvalho Chehab]

Em Mon, 8 Oct 2018 13:53:29 +0200
Hans Verkuil  escreveu:

> Hi all,
> 
> I would like to meet up somewhere during the ELCE to discuss userspace support
> for stateless (and perhaps stateful as well?) codecs.
> 
> It is also planned as a topic during the summit, but I would prefer to prepare
> for that in advance, esp. since I myself do not have any experience writing
> userspace SW for such devices.
> 
> Nicolas, it would be really great if you can participate in this meeting
> since you probably have the most experience with this by far.
> 
> Looking through the ELCE program I found two timeslots that are likely to work
> for most of us (because the topics in the program appear to be boring for us
> media types!):
> 
> Tuesday from 10:50-15:50

Should work. There's an speech from Julia that could be interesting,
related to the usage of AI for improving the quality of patches
that could be interesting.

> 
> or:
> 
> Monday from 15:45 onward

I won't be able to attend on Monday.

> 
> My guess is that we need 2-3 hours or so. Hard to predict.
> 
> The basic question that I would like to have answered is what the userspace
> component should look like? libv4l-like plugin or a library that userspace can
> link with? Do we want more general support for stateful codecs as well that 
> deals
> with resolution changes and the more complex parts of the codec API?
> 
> I've mailed this directly to those that I expect are most interested in this,
> but if someone want to join in let me know.
> 
> I want to keep the group small though, so you need to bring relevant 
> experience
> to the table.
> 
> Regards,
> 
>   Hans



Thanks,
Mauro

Re: [GIT PULL for 4.20] Lens driver fixes, imx214 sensor driver

[Mauro Carvalho Chehab]

Em Sun, 7 Oct 2018 16:05:57 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> This last pull for 4.20 contains dw9714 and dw9807 lens driver probe error
> handling fixes and the Sony imx214 sensor driver. In other words, patches
> that have roughly nil changes of breaking something.
> 
> Compile tested with and without both subdev uAPI and MC on x86-64, plus on
> arm as well.
> 
> Please pull.
> 
> 
> The following changes since commit 557c97b5133669297be561e6091da9ab6e488e65:
> 
>   media: cec: name for RC passthrough device does not need 'RC for' 
> (2018-10-05 11:28:13 -0400)
> 
> are available in the git repository at:
> 
>   ssh://linuxtv.org/git/sailus/media_tree.git tags/for-4.20-11-sign
> 
> for you to fetch changes up to a8f772a119afcc1dfabf4d8b7e258b9f90d2c561:
> 
>   imx214: Add imx214 camera sensor driver (2018-10-06 21:20:40 +0300)
> 
> 
> dw9714 and dw9807 fixes; imx214 driver
> 
> 
> Rajmohan Mani (1):
>   media: dw9714: Fix error handling in probe function
> 
> Ricardo Ribalda Delgado (2):
>   imx214: device tree binding
>   imx214: Add imx214 camera sensor driver

I'm missing the ack from Rob on the DT patch. Will apply the
remaining ones from this series as they're independent.


> 
> Sakari Ailus (2):
>   dw9714: Remove useless error message
>   dw9807-vcm: Fix probe error handling

> 
>  .../devicetree/bindings/media/i2c/sony,imx214.txt  |   53 +
>  MAINTAINERS|8 +
>  drivers/media/i2c/Kconfig  |   12 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/dw9714.c |5 +-
>  drivers/media/i2c/dw9807-vcm.c |3 +-
>  drivers/media/i2c/imx214.c | 1118 
> 
>  7 files changed, 1197 insertions(+), 3 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
>  create mode 100644 drivers/media/i2c/imx214.c
> 

Thanks,
Mauro

Re: [PATCH] MAINTAINERS: Remove stale file entry for the Atmel ISI driver

[Mauro Carvalho Chehab]

Em Thu, 04 Oct 2018 23:06:02 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Thursday, 4 October 2018 21:45:05 EEST Mauro Carvalho Chehab wrote:
> > Em Tue, 2 Oct 2018 08:35:47 +0200 Ludovic Desroches escreveu:  
> > > On Mon, Oct 01, 2018 at 01:51:01PM -0300, Mauro Carvalho Chehab wrote:  
> > > > Em Sun, 30 Sep 2018 02:40:35 -0700 Joe Perches escreveu:  
> > > > > On Sun, 2018-09-30 at 06:30 -0300, Mauro Carvalho Chehab wrote:  
> > > > > > Em Sun, 30 Sep 2018 09:54:48 +0300 Laurent Pinchart escreveu:  
> > > > > > > include/media/atmel-isi got removed three years ago without the
> > > > > > > MAINTAINERS file being updated. Remove the stale entry.
> > > > > > > 
> > > > > > > Fixes: 40a78f36fc92 ("[media] v4l: atmel-isi: Remove support for
> > > > > > > platform data") Reported-by: Joe Perches 
> > > > > > > Signed-off-by: Laurent Pinchart
> > > > > > > 
> > > > > > > ---
> > > > > > > 
> > > > > > >  MAINTAINERS | 1 -
> > > > > > >  1 file changed, 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS  
> > > > > 
> > > > > []
> > > > >   
> > > > > > > @@ -2497,7 +2497,6 @@ M:  Ludovic Desroches
> > > > > > > > > > > > 
> > > > > > >  L:   linux-media@vger.kernel.org
> > > > > > >  S:   Supported
> > > > > > >  F:   drivers/media/platform/atmel/atmel-isi.c
> > > > > > > 
> > > > > > > -F:   include/media/atmel-isi.h  
> > > > > > 
> > > > > > I guess the right fix would be to replace it by:
> > > > > > 
> > > > > > F: drivers/media/platform/atmel/atmel-isi.h  
> > > > > 
> > > > > Or replace both F entries with:
> > > > > 
> > > > > F:drivers/media/platform/atmel/atmel-isi.*
> > > > > 
> > > > > Or combine the 2 MICROCHIP sections into one
> > > > > 
> > > > > MICROCHIP ISC DRIVER
> > > > > M:Eugen Hristev 
> > > > > L:linux-media@vger.kernel.org
> > > > > S:Supported
> > > > > F:drivers/media/platform/atmel/atmel-isc.c
> > > > > F:drivers/media/platform/atmel/atmel-isc-regs.h
> > > > > F:devicetree/bindings/media/atmel-isc.txt
> > > > > 
> > > > > MICROCHIP ISI DRIVER
> > > > > M:Eugen Hristev 
> > > > > L:linux-media@vger.kernel.org
> > > > > S:Supported
> > > > > F:drivers/media/platform/atmel/atmel-isi.c
> > > > > F:include/media/atmel-isi.h
> > > > > 
> > > > > and maybe use something like:
> > > > > 
> > > > > MICROCHIP MEDIA DRIVERS
> > > > > M:Eugen Hristev 
> > > > > L:
> > > > > linux-media@vger.kernel.org
> > > > > S:Supported
> > > > > F:drivers/media/platform/atmel/
> > > > > F:devicetree/bindings/media/atmel-isc.txt  
> > > > 
> > > > Yeah, combining both of them seems a good alternative to me.
> > > > 
> > > > Eugen/Ludovic/Josh,
> > > > 
> > > > Comments?  
> > > 
> > > I have no strong opinion about it. The devices are different but usually
> > > there is one person per topic so combining them makes sense.  
> > 
> > Hmm... At media tree, currently, MAINTAINERS entry is different:
> > 
> > MICROCHIP / ATMEL ISC DRIVER
> > M:  Songjun Wu 
> > L:  linux-media@vger.kernel.org
> > S:  Supported
> > F:  drivers/media/platform/atmel/atmel-isc.c
> > F:  drivers/media/platform/atmel/atmel-isc-regs.h
> > F:  devicetree/bindings/media/atmel-isc.txt
> > 
> > ATMEL ISI DRIVER
> > M:  Ludovic Desroches 
> > L:  linux-media@vger.kernel.org
> > S:  Supported
> > F:  drivers/media/platform/atmel/atmel-isi.c
> > F:  include/media/atmel-isi.h
> > 
> > Maybe some patch upstream did some recent changes on it via another
> > tree.
> > 
> > So, in order to avoid conflicts upstream, for now I would just correct
> > the location for the ISI file.
> > 
&

Re: [PATCH v6 0/6] Add Rockchip VPU JPEG encoder

[Mauro Carvalho Chehab]

Em Fri, 05 Oct 2018 12:37:43 -0300
Ezequiel Garcia  escreveu:

> On Fri, 2018-10-05 at 09:10 -0300, Mauro Carvalho Chehab wrote:
> > Em Thu, 04 Oct 2018 20:39:31 -0300
> > Ezequiel Garcia  escreveu:
> >   
> > > On Mon, 2018-10-01 at 14:54 -0300, Ezequiel Garcia wrote:  
> > > > On Fri, 2018-09-28 at 14:33 +0200, Hans Verkuil wrote:
> > > > > On 09/17/2018 07:30 PM, Ezequiel Garcia wrote:
> > > > > > This series adds support for JPEG encoding via the VPU block
> > > > > > present in Rockchip platforms. Currently, support for RK3288
> > > > > > and RK3399 is included.
> > > > > > 
> > > > > > Please, see the previous versions of this cover letter for
> > > > > > more information.
> > > > > > 
> > > > > > Compared to v5, the only change is in the V4L2_CID_JPEG_QUANTIZATION
> > > > > > control. We've decided to support only baseline profile,
> > > > > > and only add 8-bit luma and chroma tables.
> > > > > > 
> > > > > > struct v4l2_ctrl_jpeg_quantization {
> > > > > >__u8luma_quantization_matrix[64];
> > > > > >__u8chroma_quantization_matrix[64];
> > > > > > };
> > > > > > 
> > > > > > By doing this, it's clear that we don't currently support anything
> > > > > > but baseline.
> > > > > > 
> > > > > > This series should apply cleanly on top of
> > > > > > 
> > > > > >   git://linuxtv.org/hverkuil/media_tree.git br-cedrus tag.
> > > > > > 
> > > > > > If everyone is happy with this series, I'd like to route the 
> > > > > > devicetree
> > > > > > changes through the rockchip tree, and the rest via the media 
> > > > > > subsystem.
> > > > > 
> > > > > OK, so I have what is no doubt an annoying question: do we really need
> > > > > a JPEG_RAW format?
> > > > > 
> > > > 
> > > > Not annoying, as it helps clarify a few things :-)
> > > > I think we do need the JPEG_RAW format. The way I see it, using
> > > > JPEG opens a can of worms...
> > > > 
> > > > > The JPEG header is really easy to parse for a decoder and really easy 
> > > > > to
> > > > > prepend to the compressed image for the encoder.
> > > > > 
> > > > > The only reason I can see for a JPEG_RAW is if the image must start at
> > > > > some specific address alignment. Although even then you can just pad 
> > > > > the
> > > > > JPEG header that you will add according to the alignment requirements.
> > > > > 
> > > > > I know I am very late with this question, but I never looked all that
> > > > > closely at what a JPEG header looks like. But this helped:
> > > > > 
> > > > > https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format
> > > > > 
> > > > > and it doesn't seem difficult at all to parse or create the header.
> > > > > 
> > > > > 
> > > > 
> > > > ... I think that having JPEG_RAW as the compressed format
> > > > is much more clear for userspace, as it explicitly specifies
> > > > what is expected.
> > > > 
> > > > This way, for a stateless encoder, applications are required
> > > > to set quantization and/or entropy tables, and are then in
> > > > charge of using the compressed JPEG_RAW payload in whatever form
> > > > they want. Stupid simple.
> > > > 
> > > > On the other side, if the stateless encoder driver supports
> > > > JPEG (creating headers in-kernel), it means that:
> > > > 
> > > > *) applications should pass a quality control, if supported,
> > > > and the driver will use hardcoded tables or...
> > > > 
> > > > *) applications pass quantization control and, if supported,
> > > > entropy control. The kernel uses them to create the JPEG frame.
> > > > But also, some drivers (e.g. Rockchip), use default entropy
> > > > tables, which should now be in the kernel.
> > > > 
> > > > So the application would have to query controls to find out
> > > > what to do. Not exactly hard, but I think having the J

Re: [PATCH RESEND] Revert "media: dvbsky: use just one mutex for serializing device R/W ops"

[Mauro Carvalho Chehab]

Em Fri, 5 Oct 2018 16:34:28 +0200
Oliver Freyermuth  escreveu:

> Dear Mauro,
> 
> thanks! Just to clarify, the issue I described in 
> https://bugzilla.kernel.org/show_bug.cgi?id=199323
> was on an Intel x86_64 system, with an onboard USB Controller handled by the 
> standard xhci driver,
> so this does not affect RPi alone. 

That's weird... I tested such patch here before applying (and it was
tested by someone else, as far as I know), and it worked fine.

Perhaps the x86 bug is related to some recent changes at the USB
subsystem. Dunno.

Anyway, patch revert applied upstream.

Regards,
Mauro

[PATCH RESEND] Revert "media: dvbsky: use just one mutex for serializing device R/W ops"

[Mauro Carvalho Chehab]

As pointed at:
https://bugzilla.kernel.org/show_bug.cgi?id=199323

This patch causes a bad effect on RPi. I suspect that the root
cause is at the USB RPi driver, with uses high priority
interrupts instead of normal ones. Anyway, as this patch
is mostly a cleanup, better to revert it.

This reverts commit 7d95fb746c4eece67308f1642a666ea1ebdbd2cc.

Cc: sta...@vger.kernel.org # For Kernel 4.18
Signed-off-by: Mauro Carvalho Chehab 
---

Re-sending it with the right message ID

 drivers/media/usb/dvb-usb-v2/dvbsky.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index 1aa88d94e57f..e28bd8836751 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -31,6 +31,7 @@ MODULE_PARM_DESC(disable_rc, "Disable inbuilt IR receiver.");
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
 struct dvbsky_state {
+   struct mutex stream_mutex;
u8 ibuf[DVBSKY_BUF_LEN];
u8 obuf[DVBSKY_BUF_LEN];
u8 last_lock;
@@ -67,17 +68,18 @@ static int dvbsky_usb_generic_rw(struct dvb_usb_device *d,
 
 static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8 onoff)
 {
+   struct dvbsky_state *state = d_to_priv(d);
int ret;
-   static u8 obuf_pre[3] = { 0x37, 0, 0 };
-   static u8 obuf_post[3] = { 0x36, 3, 0 };
+   u8 obuf_pre[3] = { 0x37, 0, 0 };
+   u8 obuf_post[3] = { 0x36, 3, 0 };
 
-   mutex_lock(>usb_mutex);
-   ret = dvb_usbv2_generic_rw_locked(d, obuf_pre, 3, NULL, 0);
+   mutex_lock(>stream_mutex);
+   ret = dvbsky_usb_generic_rw(d, obuf_pre, 3, NULL, 0);
if (!ret && onoff) {
msleep(20);
-   ret = dvb_usbv2_generic_rw_locked(d, obuf_post, 3, NULL, 0);
+   ret = dvbsky_usb_generic_rw(d, obuf_post, 3, NULL, 0);
}
-   mutex_unlock(>usb_mutex);
+   mutex_unlock(>stream_mutex);
return ret;
 }
 
@@ -606,6 +608,8 @@ static int dvbsky_init(struct dvb_usb_device *d)
if (ret)
return ret;
*/
+   mutex_init(>stream_mutex);
+
state->last_lock = 0;
 
return 0;
-- 
2.17.1

[PATCH] Revert "media: dvbsky: use just one mutex for serializing device R/W ops"

[Mauro Carvalho Chehab]

As pointed at:
https://bugzilla.kernel.org/show_bug.cgi?id=199323

This patch causes a bad effect on RPi. I suspect that the root
cause is at the USB RPi driver, with uses high priority
interrupts instead of normal ones. Anyway, as this patch
is mostly a cleanup, better to revert it.

This reverts commit 7d95fb746c4eece67308f1642a666ea1ebdbd2cc.

Cc: sta...@vger.kernel.org # For Kernel 4.18
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index 1aa88d94e57f..e28bd8836751 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -31,6 +31,7 @@ MODULE_PARM_DESC(disable_rc, "Disable inbuilt IR receiver.");
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
 struct dvbsky_state {
+   struct mutex stream_mutex;
u8 ibuf[DVBSKY_BUF_LEN];
u8 obuf[DVBSKY_BUF_LEN];
u8 last_lock;
@@ -67,17 +68,18 @@ static int dvbsky_usb_generic_rw(struct dvb_usb_device *d,
 
 static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8 onoff)
 {
+   struct dvbsky_state *state = d_to_priv(d);
int ret;
-   static u8 obuf_pre[3] = { 0x37, 0, 0 };
-   static u8 obuf_post[3] = { 0x36, 3, 0 };
+   u8 obuf_pre[3] = { 0x37, 0, 0 };
+   u8 obuf_post[3] = { 0x36, 3, 0 };
 
-   mutex_lock(>usb_mutex);
-   ret = dvb_usbv2_generic_rw_locked(d, obuf_pre, 3, NULL, 0);
+   mutex_lock(>stream_mutex);
+   ret = dvbsky_usb_generic_rw(d, obuf_pre, 3, NULL, 0);
if (!ret && onoff) {
msleep(20);
-   ret = dvb_usbv2_generic_rw_locked(d, obuf_post, 3, NULL, 0);
+   ret = dvbsky_usb_generic_rw(d, obuf_post, 3, NULL, 0);
}
-   mutex_unlock(>usb_mutex);
+   mutex_unlock(>stream_mutex);
return ret;
 }
 
@@ -606,6 +608,8 @@ static int dvbsky_init(struct dvb_usb_device *d)
if (ret)
return ret;
*/
+   mutex_init(>stream_mutex);
+
state->last_lock = 0;
 
return 0;
-- 
2.17.1

[PATCH] media: imx355: fix a few coding style issues

[Mauro Carvalho Chehab]

Function alignments are off by 1 space, as reported by
checkpatch.pl --strict.

Fix those.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/imx355.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index 803df2a014bb..20c8eea5db4b 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -1136,7 +1136,7 @@ static int imx355_write_reg(struct imx355 *imx355, u16 
reg, u32 len, u32 val)
 
 /* Write a list of registers */
 static int imx355_write_regs(struct imx355 *imx355,
- const struct imx355_reg *regs, u32 len)
+const struct imx355_reg *regs, u32 len)
 {
struct i2c_client *client = v4l2_get_subdevdata(>sd);
int ret;
@@ -1248,8 +1248,8 @@ static const struct v4l2_ctrl_ops imx355_ctrl_ops = {
 };
 
 static int imx355_enum_mbus_code(struct v4l2_subdev *sd,
- struct v4l2_subdev_pad_config *cfg,
- struct v4l2_subdev_mbus_code_enum *code)
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_mbus_code_enum *code)
 {
struct imx355 *imx355 = to_imx355(sd);
 
@@ -1264,8 +1264,8 @@ static int imx355_enum_mbus_code(struct v4l2_subdev *sd,
 }
 
 static int imx355_enum_frame_size(struct v4l2_subdev *sd,
-  struct v4l2_subdev_pad_config *cfg,
-  struct v4l2_subdev_frame_size_enum *fse)
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_size_enum *fse)
 {
struct imx355 *imx355 = to_imx355(sd);
 
@@ -1298,8 +1298,8 @@ static void imx355_update_pad_format(struct imx355 
*imx355,
 }
 
 static int imx355_do_get_pad_format(struct imx355 *imx355,
-struct v4l2_subdev_pad_config *cfg,
-struct v4l2_subdev_format *fmt)
+   struct v4l2_subdev_pad_config *cfg,
+   struct v4l2_subdev_format *fmt)
 {
struct v4l2_mbus_framefmt *framefmt;
struct v4l2_subdev *sd = >sd;
@@ -1315,8 +1315,8 @@ static int imx355_do_get_pad_format(struct imx355 *imx355,
 }
 
 static int imx355_get_pad_format(struct v4l2_subdev *sd,
- struct v4l2_subdev_pad_config *cfg,
- struct v4l2_subdev_format *fmt)
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_format *fmt)
 {
struct imx355 *imx355 = to_imx355(sd);
int ret;
@@ -1330,8 +1330,8 @@ static int imx355_get_pad_format(struct v4l2_subdev *sd,
 
 static int
 imx355_set_pad_format(struct v4l2_subdev *sd,
-  struct v4l2_subdev_pad_config *cfg,
-  struct v4l2_subdev_format *fmt)
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
 {
struct imx355 *imx355 = to_imx355(sd);
const struct imx355_mode *mode;
@@ -1680,7 +1680,7 @@ static struct imx355_hwcfg *imx355_get_hwcfg(struct 
device *dev)
goto out_err;
 
ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
-   >ext_clk);
+  >ext_clk);
if (ret) {
dev_err(dev, "can't get clock frequency");
goto out_err;
@@ -1689,7 +1689,7 @@ static struct imx355_hwcfg *imx355_get_hwcfg(struct 
device *dev)
dev_dbg(dev, "ext clk: %d", cfg->ext_clk);
if (cfg->ext_clk != IMX355_EXT_CLK) {
dev_err(dev, "external clock %d is not supported",
-cfg->ext_clk);
+   cfg->ext_clk);
goto out_err;
}
 
@@ -1700,9 +1700,9 @@ static struct imx355_hwcfg *imx355_get_hwcfg(struct 
device *dev)
}
 
cfg->nr_of_link_freqs = bus_cfg.nr_of_link_frequencies;
-   cfg->link_freqs = devm_kcalloc(
-   dev, bus_cfg.nr_of_link_frequencies + 1,
-   sizeof(*cfg->link_freqs), GFP_KERNEL);
+   cfg->link_freqs = devm_kcalloc(dev,
+  bus_cfg.nr_of_link_frequencies + 1,
+  sizeof(*cfg->link_freqs), GFP_KERNEL);
if (!cfg->link_freqs)
goto out_err;
 
-- 
2.17.1

[PATCH] media: imx319: fix a few coding style issues

[Mauro Carvalho Chehab]

Function alignments are off by 1 space, as reported by
checkpatch.pl --strict.

Fix those.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/imx319.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 329049f7e64d..0d3e27812b93 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1836,7 +1836,7 @@ static int imx319_write_reg(struct imx319 *imx319, u16 
reg, u32 len, u32 val)
 
 /* Write a list of registers */
 static int imx319_write_regs(struct imx319 *imx319,
- const struct imx319_reg *regs, u32 len)
+const struct imx319_reg *regs, u32 len)
 {
struct i2c_client *client = v4l2_get_subdevdata(>sd);
int ret;
@@ -1947,8 +1947,8 @@ static const struct v4l2_ctrl_ops imx319_ctrl_ops = {
 };
 
 static int imx319_enum_mbus_code(struct v4l2_subdev *sd,
- struct v4l2_subdev_pad_config *cfg,
- struct v4l2_subdev_mbus_code_enum *code)
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_mbus_code_enum *code)
 {
struct imx319 *imx319 = to_imx319(sd);
 
@@ -1963,8 +1963,8 @@ static int imx319_enum_mbus_code(struct v4l2_subdev *sd,
 }
 
 static int imx319_enum_frame_size(struct v4l2_subdev *sd,
-  struct v4l2_subdev_pad_config *cfg,
-  struct v4l2_subdev_frame_size_enum *fse)
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_size_enum *fse)
 {
struct imx319 *imx319 = to_imx319(sd);
 
@@ -1997,8 +1997,8 @@ static void imx319_update_pad_format(struct imx319 
*imx319,
 }
 
 static int imx319_do_get_pad_format(struct imx319 *imx319,
-struct v4l2_subdev_pad_config *cfg,
-struct v4l2_subdev_format *fmt)
+   struct v4l2_subdev_pad_config *cfg,
+   struct v4l2_subdev_format *fmt)
 {
struct v4l2_mbus_framefmt *framefmt;
struct v4l2_subdev *sd = >sd;
@@ -2014,8 +2014,8 @@ static int imx319_do_get_pad_format(struct imx319 *imx319,
 }
 
 static int imx319_get_pad_format(struct v4l2_subdev *sd,
- struct v4l2_subdev_pad_config *cfg,
- struct v4l2_subdev_format *fmt)
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_format *fmt)
 {
struct imx319 *imx319 = to_imx319(sd);
int ret;
@@ -2029,8 +2029,8 @@ static int imx319_get_pad_format(struct v4l2_subdev *sd,
 
 static int
 imx319_set_pad_format(struct v4l2_subdev *sd,
-  struct v4l2_subdev_pad_config *cfg,
-  struct v4l2_subdev_format *fmt)
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
 {
struct imx319 *imx319 = to_imx319(sd);
const struct imx319_mode *mode;
@@ -2380,7 +2380,7 @@ static struct imx319_hwcfg *imx319_get_hwcfg(struct 
device *dev)
goto out_err;
 
ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
-   >ext_clk);
+  >ext_clk);
if (ret) {
dev_err(dev, "can't get clock frequency");
goto out_err;
@@ -2389,7 +2389,7 @@ static struct imx319_hwcfg *imx319_get_hwcfg(struct 
device *dev)
dev_dbg(dev, "ext clk: %d", cfg->ext_clk);
if (cfg->ext_clk != IMX319_EXT_CLK) {
dev_err(dev, "external clock %d is not supported",
-cfg->ext_clk);
+   cfg->ext_clk);
goto out_err;
}
 
@@ -2400,9 +2400,9 @@ static struct imx319_hwcfg *imx319_get_hwcfg(struct 
device *dev)
}
 
cfg->nr_of_link_freqs = bus_cfg.nr_of_link_frequencies;
-   cfg->link_freqs = devm_kcalloc(
-   dev, bus_cfg.nr_of_link_frequencies + 1,
-   sizeof(*cfg->link_freqs), GFP_KERNEL);
+   cfg->link_freqs = devm_kcalloc(dev,
+  bus_cfg.nr_of_link_frequencies + 1,
+  sizeof(*cfg->link_freqs), GFP_KERNEL);
if (!cfg->link_freqs)
goto out_err;
 
-- 
2.17.1

Re: [PATCH v7 4/6] media: Add JPEG_RAW format

[Mauro Carvalho Chehab]

Em Fri, 05 Oct 2018 08:53:14 -0300
Ezequiel Garcia  escreveu:

> On Fri, 2018-10-05 at 08:09 -0300, Mauro Carvalho Chehab wrote:
> > Em Thu,  4 Oct 2018 21:12:24 -0300
> > Ezequiel Garcia  escreveu:
> >   
> > > From: Shunqian Zheng 
> > > 
> > > Add V4L2_PIX_FMT_JPEG_RAW format that does not contain
> > > JPEG header in the output frame.
> > > 
> > > Signed-off-by: Shunqian Zheng 
> > > Signed-off-by: Ezequiel Garcia 
> > > ---
> > >  Documentation/media/uapi/v4l/pixfmt-compressed.rst | 9 +
> > >  drivers/media/v4l2-core/v4l2-ioctl.c   | 1 +
> > >  include/uapi/linux/videodev2.h | 1 +
> > >  3 files changed, 11 insertions(+)
> > > 
> > > diff --git a/Documentation/media/uapi/v4l/pixfmt-compressed.rst 
> > > b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
> > > index ba0f6c49d9bf..ad73076276ec 100644
> > > --- a/Documentation/media/uapi/v4l/pixfmt-compressed.rst
> > > +++ b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
> > > @@ -23,6 +23,15 @@ Compressed Formats
> > >- 'JPEG'
> > >- TBD. See also :ref:`VIDIOC_G_JPEGCOMP `,
> > >   :ref:`VIDIOC_S_JPEGCOMP `.
> > > +* .. _V4L2-PIX-FMT-JPEG-RAW:
> > > +
> > > +  - ``V4L2_PIX_FMT_JPEG_RAW``
> > > +  - 'Raw JPEG'
> > > +  - Raw JPEG bitstream, containing a compressed payload. This format
> > > +contains an image scan, i.e. without any metadata or headers.
> > > +The user is expected to set the needed metadata such as
> > > +quantization and entropy encoding tables, via ``V4L2_CID_JPEG``
> > > +controls, see :ref:`jpeg-control-id`.  
> > 
> > IMO, it is not very clear when someone should use V4L2_CID_JPEG or
> > V4L2_PIX_FMT_JPEG_RAW. Some drivers do add a JPEG header internally.
> >   
> 
> For device drivers, if the hardware can parse JPEG frames, then
> V4L2_PIX_FMT_JPEG should be used. Otherwise, if the hardware can
> only accept a parsed JPEG (i.e. payload and tables), then
> only V4L2_PIX_FMT_JPEG_RAW should be supported.

It seems you're talking here about V4L2 output devices. I'm more
concerned about its usage on V4L2 capture devices.

Yet, it should be possible to use it with both, as formats should
be generic enough to work on both directions.

> Parsing headers in the driver is discouraged by the stateful codec
> API specification.

True, but we do parsing/adding headers for some formats in Kernel
space, as this is a way to abstract the hardware for applications.

That's specially true for MPEG and JPEG formats.

> With the Request API in place, and the stateful and stateless specs,
> device driver writers should be now using the right model for each
> type of hardware.
> 
> There are exceptions, though. If the hardware handles full JPEG frames,
> but requires some extra parsing on the OS side, then the driver
> should be using V4L2_PIX_FMT_JPEG, and doing some extra parsing.
> For instance, mtk-jpeg seems to work like this.

Actually, all existing drivers do this.

I'm not saying that this the right/best model, but it is the way
it is. Changing it is possible, but only if it can be done in
a driver-independent way and userspace code inside a library
exists to support it.


> 
> > Also, if we're now starting to accept headerless JPEG images, you should
> > very patch libv4l as well, in order to accept this new format.
> >   
> 
> Right.
> 
> Thanks,
> Eze



Thanks,
Mauro

Re: [PATCH v6 0/6] Add Rockchip VPU JPEG encoder

[Mauro Carvalho Chehab]

Em Thu, 04 Oct 2018 20:39:31 -0300
Ezequiel Garcia  escreveu:

> On Mon, 2018-10-01 at 14:54 -0300, Ezequiel Garcia wrote:
> > On Fri, 2018-09-28 at 14:33 +0200, Hans Verkuil wrote:  
> > > On 09/17/2018 07:30 PM, Ezequiel Garcia wrote:  
> > > > This series adds support for JPEG encoding via the VPU block
> > > > present in Rockchip platforms. Currently, support for RK3288
> > > > and RK3399 is included.
> > > > 
> > > > Please, see the previous versions of this cover letter for
> > > > more information.
> > > > 
> > > > Compared to v5, the only change is in the V4L2_CID_JPEG_QUANTIZATION
> > > > control. We've decided to support only baseline profile,
> > > > and only add 8-bit luma and chroma tables.
> > > > 
> > > > struct v4l2_ctrl_jpeg_quantization {
> > > >__u8luma_quantization_matrix[64];
> > > >__u8chroma_quantization_matrix[64];
> > > > };
> > > > 
> > > > By doing this, it's clear that we don't currently support anything
> > > > but baseline.
> > > > 
> > > > This series should apply cleanly on top of
> > > > 
> > > >   git://linuxtv.org/hverkuil/media_tree.git br-cedrus tag.
> > > > 
> > > > If everyone is happy with this series, I'd like to route the devicetree
> > > > changes through the rockchip tree, and the rest via the media 
> > > > subsystem.  
> > > 
> > > OK, so I have what is no doubt an annoying question: do we really need
> > > a JPEG_RAW format?
> > >   
> > 
> > Not annoying, as it helps clarify a few things :-)
> > I think we do need the JPEG_RAW format. The way I see it, using
> > JPEG opens a can of worms...
> >   
> > > The JPEG header is really easy to parse for a decoder and really easy to
> > > prepend to the compressed image for the encoder.
> > > 
> > > The only reason I can see for a JPEG_RAW is if the image must start at
> > > some specific address alignment. Although even then you can just pad the
> > > JPEG header that you will add according to the alignment requirements.
> > > 
> > > I know I am very late with this question, but I never looked all that
> > > closely at what a JPEG header looks like. But this helped:
> > > 
> > > https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format
> > > 
> > > and it doesn't seem difficult at all to parse or create the header.
> > > 
> > >   
> > 
> > ... I think that having JPEG_RAW as the compressed format
> > is much more clear for userspace, as it explicitly specifies
> > what is expected.
> > 
> > This way, for a stateless encoder, applications are required
> > to set quantization and/or entropy tables, and are then in
> > charge of using the compressed JPEG_RAW payload in whatever form
> > they want. Stupid simple.
> > 
> > On the other side, if the stateless encoder driver supports
> > JPEG (creating headers in-kernel), it means that:
> > 
> > *) applications should pass a quality control, if supported,
> > and the driver will use hardcoded tables or...
> > 
> > *) applications pass quantization control and, if supported,
> > entropy control. The kernel uses them to create the JPEG frame.
> > But also, some drivers (e.g. Rockchip), use default entropy
> > tables, which should now be in the kernel.
> > 
> > So the application would have to query controls to find out
> > what to do. Not exactly hard, but I think having the JPEG_RAW
> > is much simpler and more clear.
> > 
> > Now, for stateless decoders, supporting JPEG_RAW means
> > the application has to pass quantization and entropy
> > controls, probably using the Request API.
> > Given the application has parsed the JPEG,
> > it knows the width and height and can request
> > buffers accordingly.
> > 
> > The hardware is stateless, and so is the driver.
> > 
> > On the other hand, supporting JPEG would mean that
> > drivers will have to parse the image, extracting
> > the quantization and entropy tables.
> > 
> > Format negotiation is now more complex,
> > either we follow the stateful spec, introducing a little
> > state machine in the driver... or we use the Request API,
> > but that means parsing on both sides kernel and application.
> > 
> > Either way, using JPEG_RAW is just waaay simpler and puts
> > things where they belong. 
> >   
> 
> As discussed on IRC, I'm sending a v7 for this series,
> fixing only the checkpatch issues and the extra line in the
> binding document.
> 
> We've agreed to move forward with JPEG_RAW, for the reasons
> stated above.
> 
> Plus, we've agreed to keep this in staging until the userspace
> support for JPEG_RAW format is clear.

The problem is that a new format is actually a V4L2 core change, and
not something for staging.

IMHO, it is prudent to wait for an userspace code before hushing
merging this upstream.

-

I'm concerned about adding a JPEG_RAW format. We had this discussion
in the past. On that time, it was opted to add a code inside the
drivers that will be adding the jpeg headers, on the cases where
the hardware was providing headerless frames.

Among the reasons, different drivers may be 

Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG

[Mauro Carvalho Chehab]

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

> Hi All,
> 
> On Mon, 1 Oct 2018 at 17:32, Ezequiel Garcia  wrote:
> >
> > Hi Hans,
> >
> > Thanks for looking into. I remember MJPEG vs. JPEG being a source
> > of confusion for me a few years ago, so clarification is greatly
> > welcome :-)
> >
> > On Mon, 2018-10-01 at 15:03 +0300, Laurent Pinchart wrote:  
> > > Hi Hans,
> > >
> > > On Monday, 1 October 2018 14:54:29 EEST Hans Verkuil wrote:  
> > > > On 10/01/2018 01:48 PM, Laurent Pinchart wrote:  
> > > > > On Monday, 1 October 2018 11:43:04 EEST Hans Verkuil wrote:  
> > > > > > It turns out that we have both JPEG and Motion-JPEG pixel formats
> > > > > > defined.
> > > > > >
> > > > > > Furthermore, some drivers support one, some the other and some both.
> > > > > >
> > > > > > These pixelformats both mean the same.  
> > > > >
> > > > > Do they ? I thought MJPEG was JPEG using fixed Huffman tables that 
> > > > > were
> > > > > not included in the JPEG headers.  
> > > >
> > > > I'm not aware of any difference. If there is one, then it is certainly 
> > > > not
> > > > documented.  
> > >
> > > What I can tell for sure is that many UVC devices don't include Huffman 
> > > tables
> > > in their JPEG headers.
> > >  
> > > > Ezequiel, since you've been working with this recently, do you know 
> > > > anything
> > > > about this?  
> > >
> > >  
> >
> > JPEG frames must include huffman and quantization tables, as per the 
> > standard.
> >
> > AFAIK, there's no MJPEG specification per-se and vendors specify its own
> > way of conveying a Motion JPEG stream.  
> 
> There is the specfication for MJPEG in Quicktime containers, which
> defines the MJPEG-A and MJPEG-B variants [1].
> MJPEG-B is not a concatenation of JPEG frames as the framing is
> different, so can't really be combined into V4L2_PIX_FMT_JPEG.
> Have people encountered devices that produce MJPEG-A or MJPEG-B via
> V4L2? I haven't, but I have been forced to support both variants on
> decode.

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

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

> 
> On that thought, whilst capture devices generally don't care, is there
> a need to differentiate for M2M codec devices which can support
> encoding the variants? Or likewise on M2M decoders that support only
> JPEG, how do they tell userspace that they don't support MJPEG-A or
> MJPEG-B?
> 
>   Dave
> 
> [1] https://developer.apple.com/standards/qtff-2001.pdf
> 
> > For instance, omiting the huffman table seems to be a vendor thing. 
> > Microsoft
> > explicitly omits the huffman tables from each frame:
> >
> > https://www.fileformat.info/format/bmp/spec/b7c72ebab8064da48ae5ed0c053c67a4/view.htm
> >
> > Others could be following the same things.
> >
> > Like I mentioned before, Gstreamer always check for missing huffman table
> > and adds one if missing. Gstreamer has other quirks for missing markers,
> > e.g. deal with a missing EOI:
> >
> > https://github.com/GStreamer/gst-plugins-good/commit/10ff3c8e14e8fba9e0a5d696dce0bea27de644d7
> >
> > I think Hans suggestion of settling on JPEG makes sense and it would
> > be consistent with Gstreamer. Otherwise, we should specify exactly what we
> > understand by MJPEG, but I don't think it's worth it.
> >
> > Thanks,
> > Ezequiel  



Thanks,
Mauro

Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG

[Mauro Carvalho Chehab]

Em Mon, 01 Oct 2018 08:42:56 -0400
Nicolas Dufresne  escreveu:

> Hello Hans,
> 
> Le lundi 01 octobre 2018 à 10:43 +0200, Hans Verkuil a écrit :
> > It turns out that we have both JPEG and Motion-JPEG pixel formats defined.
> > 
> > Furthermore, some drivers support one, some the other and some both.
> > 
> > These pixelformats both mean the same.
> > 
> > I propose that we settle on JPEG (since it seems to be used most often) and
> > add JPEG support to those drivers that currently only use MJPEG.  
> 
> Thanks for looking into this. As per GStreamer code, I see 3 alias for
> JPEG. V4L2_PIX_FMT_MJPEG/JPEG/PJPG. I don't know the context, this code
> was written before I knew GStreamer existed. It's possible there is a
> subtle difference, I have never looked at it, but clearly all our JPEG
> decoder handle these as being the same.
> 
> https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2/gstv4l2object.c#n956

The code at libv4l handles both MJPEG and JPEG the same way. PJPG is
handled somewhat differently (although it uses the same code). There is a
code there that cleanups some Pixart-specific headers.

Thanks,
Mauro

Re: [PATCH v7 4/6] media: Add JPEG_RAW format

[Mauro Carvalho Chehab]

Em Thu,  4 Oct 2018 21:12:24 -0300
Ezequiel Garcia  escreveu:

> From: Shunqian Zheng 
> 
> Add V4L2_PIX_FMT_JPEG_RAW format that does not contain
> JPEG header in the output frame.
> 
> Signed-off-by: Shunqian Zheng 
> Signed-off-by: Ezequiel Garcia 
> ---
>  Documentation/media/uapi/v4l/pixfmt-compressed.rst | 9 +
>  drivers/media/v4l2-core/v4l2-ioctl.c   | 1 +
>  include/uapi/linux/videodev2.h | 1 +
>  3 files changed, 11 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/pixfmt-compressed.rst 
> b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
> index ba0f6c49d9bf..ad73076276ec 100644
> --- a/Documentation/media/uapi/v4l/pixfmt-compressed.rst
> +++ b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
> @@ -23,6 +23,15 @@ Compressed Formats
>- 'JPEG'
>- TBD. See also :ref:`VIDIOC_G_JPEGCOMP `,
>   :ref:`VIDIOC_S_JPEGCOMP `.
> +* .. _V4L2-PIX-FMT-JPEG-RAW:
> +
> +  - ``V4L2_PIX_FMT_JPEG_RAW``
> +  - 'Raw JPEG'
> +  - Raw JPEG bitstream, containing a compressed payload. This format
> +contains an image scan, i.e. without any metadata or headers.
> +The user is expected to set the needed metadata such as
> +quantization and entropy encoding tables, via ``V4L2_CID_JPEG``
> +controls, see :ref:`jpeg-control-id`.

IMO, it is not very clear when someone should use V4L2_CID_JPEG or
V4L2_PIX_FMT_JPEG_RAW. Some drivers do add a JPEG header internally.

Also, if we're now starting to accept headerless JPEG images, you should
very patch libv4l as well, in order to accept this new format.

Regards,

Thanks,
Mauro

Re: [PATCH 2/3] media: v4l2-fwnode: cleanup functions that parse endpoints

[Mauro Carvalho Chehab]

Em Fri, 5 Oct 2018 13:08:25 +0300
Sakari Ailus  escreveu:

> > > This is still over 80 here. I think we could think of abbreviating what's
> > > in the function name, not limiting to the endpoint. I think I'd prefer to
> > > leave that for 4.21 as there's not much time anymore.  
> > 
> > Yes, I know. Renaming the function is the only way to get rid of
> > those remaining warnings. If you're ok with renaming, IMHO it is best
> > do do it right now, as we are already churning a lot of fwnode-related
> > code, avoiding the need of touching it again for 4.21.  
> 
> This will presumably continue in v4.21 (or later). As noted in the cover
> page of the fwnode patchset:
> 
>   This patchset does not address remaining issues such as supporting
>   setting defaults for e.g. bridge drivers with multiple ports, but
>   with Steve Longerbeam's patchset we're much closer to that goal.

OK! Feel free to rename them when you feel ready. My suggestion is
to do it at the end of a media merging cycle, as makes easier to
avoid conflicts.

I don't care that much about 80 cols. Yet, here it makes a point: we
should be more spartan when naming functions :-)


Thanks,
Mauro

Re: [PATCH 3/3] media: v4l2-fwnode: simplify v4l2_fwnode_reference_parse_int_props() call

[Mauro Carvalho Chehab]

Em Fri, 5 Oct 2018 13:06:04 +0300
Sakari Ailus  escreveu:

> > > > -   unsigned int i;
> > > 
> > > I'd like to keep this here.  
> > 
> > Why? IMHO, it makes harder to read (yet, if you insist, I'm ok with 
> > both ways).  
> 
> Generally loop, temporary, return etc. variables are nice to declare as
> last. That is the practice in this file and generally in kernel code,
> albeit with variable degree of application.

I've seen more than one practice of ordering arguments at the Kernel :-)

Anyway, I kept it there on the version I just sent.


Thanks,
Mauro

[PATCH v2 1/3] media: v4l2-core: cleanup coding style at V4L2 async/fwnode

[Mauro Carvalho Chehab]

There are several coding style issues at those definitions,
and the previous patchset added even more.

Address the trivial ones by first calling:

./scripts/checkpatch.pl --strict --fix-inline 
include/media/v4l2-async.h include/media/v4l2-fwnode.h 
include/media/v4l2-mediabus.h drivers/media/v4l2-core/v4l2-async.c 
drivers/media/v4l2-core/v4l2-fwnode.c

and then manually adjusting the style where needed.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-async.c  |  45 ---
 drivers/media/v4l2-core/v4l2-fwnode.c | 185 +++---
 include/media/v4l2-async.h|  12 +-
 include/media/v4l2-fwnode.h   |  46 ---
 include/media/v4l2-mediabus.h |  32 +++--
 5 files changed, 179 insertions(+), 141 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 70adbd9a01a2..a6d91370838d 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -57,6 +57,7 @@ static bool match_i2c(struct v4l2_subdev *sd, struct 
v4l2_async_subdev *asd)
 {
 #if IS_ENABLED(CONFIG_I2C)
struct i2c_client *client = i2c_verify_client(sd->dev);
+
return client &&
asd->match.i2c.adapter_id == client->adapter->nr &&
asd->match.i2c.address == client->addr;
@@ -89,10 +90,11 @@ static LIST_HEAD(subdev_list);
 static LIST_HEAD(notifier_list);
 static DEFINE_MUTEX(list_lock);
 
-static struct v4l2_async_subdev *v4l2_async_find_match(
-   struct v4l2_async_notifier *notifier, struct v4l2_subdev *sd)
+static struct v4l2_async_subdev *
+v4l2_async_find_match(struct v4l2_async_notifier *notifier,
+ struct v4l2_subdev *sd)
 {
-   bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
+   bool (*match)(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd);
struct v4l2_async_subdev *asd;
 
list_for_each_entry(asd, >waiting, list) {
@@ -150,8 +152,8 @@ static bool asd_equal(struct v4l2_async_subdev *asd_x,
 }
 
 /* Find the sub-device notifier registered by a sub-device driver. */
-static struct v4l2_async_notifier *v4l2_async_find_subdev_notifier(
-   struct v4l2_subdev *sd)
+static struct v4l2_async_notifier *
+v4l2_async_find_subdev_notifier(struct v4l2_subdev *sd)
 {
struct v4l2_async_notifier *n;
 
@@ -163,8 +165,8 @@ static struct v4l2_async_notifier 
*v4l2_async_find_subdev_notifier(
 }
 
 /* Get v4l2_device related to the notifier if one can be found. */
-static struct v4l2_device *v4l2_async_notifier_find_v4l2_dev(
-   struct v4l2_async_notifier *notifier)
+static struct v4l2_device *
+v4l2_async_notifier_find_v4l2_dev(struct v4l2_async_notifier *notifier)
 {
while (notifier->parent)
notifier = notifier->parent;
@@ -175,8 +177,8 @@ static struct v4l2_device 
*v4l2_async_notifier_find_v4l2_dev(
 /*
  * Return true if all child sub-device notifiers are complete, false otherwise.
  */
-static bool v4l2_async_notifier_can_complete(
-   struct v4l2_async_notifier *notifier)
+static bool
+v4l2_async_notifier_can_complete(struct v4l2_async_notifier *notifier)
 {
struct v4l2_subdev *sd;
 
@@ -199,8 +201,8 @@ static bool v4l2_async_notifier_can_complete(
  * Complete the master notifier if possible. This is done when all async
  * sub-devices have been bound; v4l2_device is also available then.
  */
-static int v4l2_async_notifier_try_complete(
-   struct v4l2_async_notifier *notifier)
+static int
+v4l2_async_notifier_try_complete(struct v4l2_async_notifier *notifier)
 {
/* Quick check whether there are still more sub-devices here. */
if (!list_empty(>waiting))
@@ -221,8 +223,8 @@ static int v4l2_async_notifier_try_complete(
return v4l2_async_notifier_call_complete(notifier);
 }
 
-static int v4l2_async_notifier_try_all_subdevs(
-   struct v4l2_async_notifier *notifier);
+static int
+v4l2_async_notifier_try_all_subdevs(struct v4l2_async_notifier *notifier);
 
 static int v4l2_async_match_notify(struct v4l2_async_notifier *notifier,
   struct v4l2_device *v4l2_dev,
@@ -268,8 +270,8 @@ static int v4l2_async_match_notify(struct 
v4l2_async_notifier *notifier,
 }
 
 /* Test all async sub-devices in a notifier for a match. */
-static int v4l2_async_notifier_try_all_subdevs(
-   struct v4l2_async_notifier *notifier)
+static int
+v4l2_async_notifier_try_all_subdevs(struct v4l2_async_notifier *notifier)
 {
struct v4l2_device *v4l2_dev =
v4l2_async_notifier_find_v4l2_dev(notifier);
@@ -306,14 +308,17 @@ static int v4l2_async_notifier_try_all_subdevs(
 static void v4l2_async_cleanup(struct v4l2_subdev *sd)
 {
v4l2_device_unregister_subdev(sd);
-   /* Subdevice driver will reprobe and put the subdev back onto the list 
*/
+   /*
+* Subdevice driver will reprobe an

[PATCH v2 0/3] Coding style cleanups after the fwnode patchset

[Mauro Carvalho Chehab]

The fwnode patchset added a several new warnings, as identified by
checkpatch.pl --strict.

Those are at the core stuff, and makes harder to review patches there.

In order to fully address checkpatch.pl, we still need to:

- Add SPDX headers;
- Rename functions.

Let's do those on some future change.

-

v2:
   - fixed a weird line break at patch 1/3;
   - kept the order of arguments inside a function at patch 3/3.

Mauro Carvalho Chehab (3):
  media: v4l2-core: cleanup coding style at V4L2 async/fwnode
  media: v4l2-fwnode: cleanup functions that parse endpoints
  media: v4l2-fwnode: simplify v4l2_fwnode_reference_parse_int_props()
call

 drivers/media/v4l2-core/v4l2-async.c  |  45 +++---
 drivers/media/v4l2-core/v4l2-fwnode.c | 188 ++
 include/media/v4l2-async.h|  12 +-
 include/media/v4l2-fwnode.h   |  45 +++---
 include/media/v4l2-mediabus.h |  32 +++--
 5 files changed, 176 insertions(+), 146 deletions(-)

-- 
2.17.1

[PATCH v2 3/3] media: v4l2-fwnode: simplify v4l2_fwnode_reference_parse_int_props() call

[Mauro Carvalho Chehab]

The v4l2_fwnode_reference_parse_int_props() has a big name, causing
it to cause coding style warnings. Also, it depends on a const
struct embedded indide a function.

Rearrange the logic in order to move the struct declaration out
of such function and use it inside this function.

That cleans up some coding style issues.

Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-fwnode.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index a7c2487154a4..218f0da0ce76 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -1006,6 +1006,12 @@ v4l2_fwnode_reference_get_int_prop(struct fwnode_handle 
*fwnode,
return fwnode;
 }
 
+struct v4l2_fwnode_int_props {
+   const char *name;
+   const char * const *props;
+   unsigned int nprops;
+};
+
 /*
  * v4l2_fwnode_reference_parse_int_props - parse references for async
  *sub-devices
@@ -1032,13 +1038,14 @@ v4l2_fwnode_reference_get_int_prop(struct fwnode_handle 
*fwnode,
 static int
 v4l2_fwnode_reference_parse_int_props(struct device *dev,
  struct v4l2_async_notifier *notifier,
- const char *prop,
- const char * const *props,
- unsigned int nprops)
+ const struct v4l2_fwnode_int_props *p)
 {
struct fwnode_handle *fwnode;
unsigned int index;
int ret;
+   const char *prop = p->name;
+   const char * const *props = p->props;
+   unsigned int nprops = p->nprops;
 
index = 0;
do {
@@ -1093,11 +1100,7 @@ int 
v4l2_async_notifier_parse_fwnode_sensor_common(struct device *dev,
   struct v4l2_async_notifier 
*notifier)
 {
static const char * const led_props[] = { "led" };
-   static const struct {
-   const char *name;
-   const char * const *props;
-   unsigned int nprops;
-   } props[] = {
+   static const struct v4l2_fwnode_int_props props[] = {
{ "flash-leds", led_props, ARRAY_SIZE(led_props) },
{ "lens-focus", NULL, 0 },
};
@@ -1109,9 +1112,7 @@ int v4l2_async_notifier_parse_fwnode_sensor_common(struct 
device *dev,
if (props[i].props && is_acpi_node(dev_fwnode(dev)))
ret = v4l2_fwnode_reference_parse_int_props(dev,
notifier,
-   
props[i].name,
-   
props[i].props,
-   
props[i].nprops);
+   [i]);
else
ret = v4l2_fwnode_reference_parse(dev, notifier,
  props[i].name);
-- 
2.17.1

[PATCH v2 2/3] media: v4l2-fwnode: cleanup functions that parse endpoints

[Mauro Carvalho Chehab]

There is already a typedef for the parse endpoint function.
However, instead of using it, it is redefined at the C file
(and on one of the function headers).

Replace them by the function typedef, in order to cleanup
several related coding style warnings.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-fwnode.c | 64 ---
 include/media/v4l2-fwnode.h   | 19 
 2 files changed, 37 insertions(+), 46 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index 4e518d5fddd8..a7c2487154a4 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -596,12 +596,10 @@ EXPORT_SYMBOL_GPL(v4l2_fwnode_put_link);
 
 static int
 v4l2_async_notifier_fwnode_parse_endpoint(struct device *dev,
-   struct v4l2_async_notifier *notifier,
-   struct fwnode_handle *endpoint,
-   unsigned int asd_struct_size,
-   int (*parse_endpoint)(struct device *dev,
- struct v4l2_fwnode_endpoint *vep,
- struct v4l2_async_subdev *asd))
+ struct v4l2_async_notifier *notifier,
+ struct fwnode_handle *endpoint,
+ unsigned int asd_struct_size,
+ parse_endpoint_func parse_endpoint)
 {
struct v4l2_fwnode_endpoint vep = { .bus_type = 0 };
struct v4l2_async_subdev *asd;
@@ -657,13 +655,12 @@ v4l2_async_notifier_fwnode_parse_endpoint(struct device 
*dev,
 }
 
 static int
-__v4l2_async_notifier_parse_fwnode_endpoints(struct device *dev,
-   struct v4l2_async_notifier *notifier,
-   size_t asd_struct_size,
-   unsigned int port, bool has_port,
-   int (*parse_endpoint)(struct device *dev,
- struct v4l2_fwnode_endpoint *vep,
- struct v4l2_async_subdev *asd))
+__v4l2_async_notifier_parse_fwnode_ep(struct device *dev,
+ struct v4l2_async_notifier *notifier,
+ size_t asd_struct_size,
+ unsigned int port,
+ bool has_port,
+ parse_endpoint_func parse_endpoint)
 {
struct fwnode_handle *fwnode;
int ret = 0;
@@ -708,31 +705,27 @@ __v4l2_async_notifier_parse_fwnode_endpoints(struct 
device *dev,
 
 int
 v4l2_async_notifier_parse_fwnode_endpoints(struct device *dev,
-   struct v4l2_async_notifier *notifier,
-   size_t asd_struct_size,
-   int (*parse_endpoint)(struct device *dev,
- struct v4l2_fwnode_endpoint *vep,
- struct v4l2_async_subdev *asd))
+  struct v4l2_async_notifier *notifier,
+  size_t asd_struct_size,
+  parse_endpoint_func parse_endpoint)
 {
-   return __v4l2_async_notifier_parse_fwnode_endpoints(dev, notifier,
-   asd_struct_size, 0,
-   false,
-   parse_endpoint);
+   return __v4l2_async_notifier_parse_fwnode_ep(dev, notifier,
+asd_struct_size, 0,
+false, parse_endpoint);
 }
 EXPORT_SYMBOL_GPL(v4l2_async_notifier_parse_fwnode_endpoints);
 
 int
 v4l2_async_notifier_parse_fwnode_endpoints_by_port(struct device *dev,
-   struct v4l2_async_notifier *notifier,
-   size_t asd_struct_size, unsigned int port,
-   int (*parse_endpoint)(struct device *dev,
- struct v4l2_fwnode_endpoint *vep,
- struct v4l2_async_subdev *asd))
+  struct v4l2_async_notifier 
*notifier,
+  size_t asd_struct_size,
+  unsigned int port,
+  parse_endpoint_func 
parse_endpoint)
 {
-   return __v4l2_async_notifier_parse_fwnode_endpoints(dev, notifier,
-   asd_struct_size,
-   port, true,
-   parse_endpoint);
+   return __v4l2_async_notifier_parse_fwnode_ep(dev, notifier

Re: [PATCH 1/3] media: v4l2-core: cleanup coding style at V4L2 async/fwnode

[Mauro Carvalho Chehab]

Em Fri, 5 Oct 2018 10:55:58 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Thu, Oct 04, 2018 at 06:13:46PM -0400, Mauro Carvalho Chehab wrote:
> > There are several coding style issues at those definitions,
> > and the previous patchset added even more.
> > 
> > Address the trivial ones by first calling:
> > 
> > ./scripts/checkpatch.pl --strict --fix-inline 
> > include/media/v4l2-async.h include/media/v4l2-fwnode.h 
> > include/media/v4l2-mediabus.h drivers/media/v4l2-core/v4l2-async.c 
> > drivers/media/v4l2-core/v4l2-fwnode.c
> > 
> > and then manually adjusting the style where needed.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/v4l2-core/v4l2-async.c  |  45 ---
> >  drivers/media/v4l2-core/v4l2-fwnode.c | 185 +++---
> >  include/media/v4l2-async.h|  12 +-
> >  include/media/v4l2-fwnode.h   |  46 ---
> >  include/media/v4l2-mediabus.h |  32 +++--
> >  5 files changed, 179 insertions(+), 141 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> > b/drivers/media/v4l2-core/v4l2-async.c
> > index 70adbd9a01a2..6fdda745a1da 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -57,6 +57,7 @@ static bool match_i2c(struct v4l2_subdev *sd, struct 
> > v4l2_async_subdev *asd)
> >  {
> >  #if IS_ENABLED(CONFIG_I2C)
> > struct i2c_client *client = i2c_verify_client(sd->dev);
> > +
> > return client &&
> > asd->match.i2c.adapter_id == client->adapter->nr &&
> > asd->match.i2c.address == client->addr;
> > @@ -89,10 +90,11 @@ static LIST_HEAD(subdev_list);
> >  static LIST_HEAD(notifier_list);
> >  static DEFINE_MUTEX(list_lock);
> >  
> > -static struct v4l2_async_subdev *v4l2_async_find_match(
> > -   struct v4l2_async_notifier *notifier, struct v4l2_subdev *sd)
> > +static struct
> > +v4l2_async_subdev *v4l2_async_find_match(struct v4l2_async_notifier 
> > *notifier,  
> 
> This looks odd. If you want to rewrap it, then I'd put the stuff before and
> including the first asterisk on the first line.

Yeah, makes sense.

> 
> > +struct v4l2_subdev *sd)
> >  {
> > -   bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
> > +   bool (*match)(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd);
> > struct v4l2_async_subdev *asd;
> >  
> > list_for_each_entry(asd, >waiting, list) {
> > @@ -150,8 +152,8 @@ static bool asd_equal(struct v4l2_async_subdev *asd_x,
> >  }
> >  
> >  /* Find the sub-device notifier registered by a sub-device driver. */
> > -static struct v4l2_async_notifier *v4l2_async_find_subdev_notifier(
> > -   struct v4l2_subdev *sd)
> > +static struct v4l2_async_notifier *
> > +v4l2_async_find_subdev_notifier(struct v4l2_subdev *sd)  
> 
> It's better here. Below, too.
> 
> >  {
> > struct v4l2_async_notifier *n;
> >  
> > @@ -163,8 +165,8 @@ static struct v4l2_async_notifier 
> > *v4l2_async_find_subdev_notifier(
> >  }
> >  
> >  /* Get v4l2_device related to the notifier if one can be found. */
> > -static struct v4l2_device *v4l2_async_notifier_find_v4l2_dev(
> > -   struct v4l2_async_notifier *notifier)
> > +static struct v4l2_device *
> > +v4l2_async_notifier_find_v4l2_dev(struct v4l2_async_notifier *notifier)
> >  {
> > while (notifier->parent)
> > notifier = notifier->parent;
> > @@ -175,8 +177,8 @@ static struct v4l2_device 
> > *v4l2_async_notifier_find_v4l2_dev(
> >  /*
> >   * Return true if all child sub-device notifiers are complete, false 
> > otherwise.
> >   */
> > -static bool v4l2_async_notifier_can_complete(
> > -   struct v4l2_async_notifier *notifier)
> > +static bool
> > +v4l2_async_notifier_can_complete(struct v4l2_async_notifier *notifier)
> >  {
> > struct v4l2_subdev *sd;
> >  
> > @@ -199,8 +201,8 @@ static bool v4l2_async_notifier_can_complete(
> >   * Complete the master notifier if possible. This is done when all async
> >   * sub-devices have been bound; v4l2_device is also available then.
> >   */
> > -static int v4l2_async_notifier_try_complete(
> > -   struct v4l2_async_notifier *notifier)
> > +static int
> > +v4l2_async_notifier_try_complete(struct v4l2_async_notifier *notifier)
> >  {
> > /* Quick check whether there are

Re: [PATCH 3/3] media: v4l2-fwnode: simplify v4l2_fwnode_reference_parse_int_props() call

[Mauro Carvalho Chehab]

Em Fri, 5 Oct 2018 11:03:10 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Thu, Oct 04, 2018 at 06:13:48PM -0400, Mauro Carvalho Chehab wrote:
> > The v4l2_fwnode_reference_parse_int_props() has a big name, causing
> > it to cause coding style warnings. Also, it depends on a const
> > struct embedded indide a function.
> > 
> > Rearrange the logic in order to move the struct declaration out
> > of such function and use it inside this function.
> > 
> > That cleans up some coding style issues.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/v4l2-core/v4l2-fwnode.c | 25 +
> >  1 file changed, 13 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> > b/drivers/media/v4l2-core/v4l2-fwnode.c
> > index a7c2487154a4..e0cd119d6f5c 100644
> > --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> > +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> > @@ -1006,6 +1006,12 @@ v4l2_fwnode_reference_get_int_prop(struct 
> > fwnode_handle *fwnode,
> > return fwnode;
> >  }
> >  
> > +struct v4l2_fwnode_int_props {
> > +   const char *name;
> > +   const char * const *props;
> > +   unsigned int nprops;
> > +};
> > +
> >  /*
> >   * v4l2_fwnode_reference_parse_int_props - parse references for async
> >   *sub-devices
> > @@ -1032,13 +1038,14 @@ v4l2_fwnode_reference_get_int_prop(struct 
> > fwnode_handle *fwnode,
> >  static int
> >  v4l2_fwnode_reference_parse_int_props(struct device *dev,
> >   struct v4l2_async_notifier *notifier,
> > - const char *prop,
> > - const char * const *props,
> > - unsigned int nprops)
> > + const struct v4l2_fwnode_int_props *p)
> >  {
> > struct fwnode_handle *fwnode;
> > unsigned int index;
> > int ret;
> > +   const char *prop = p->name;
> > +   const char * const *props = p->props;
> > +   unsigned int nprops = p->nprops;
> >  
> > index = 0;
> > do {
> > @@ -1092,16 +1099,12 @@ v4l2_fwnode_reference_parse_int_props(struct device 
> > *dev,
> >  int v4l2_async_notifier_parse_fwnode_sensor_common(struct device *dev,
> >struct v4l2_async_notifier 
> > *notifier)
> >  {
> > +   unsigned int i;
> > static const char * const led_props[] = { "led" };
> > -   static const struct {
> > -   const char *name;
> > -   const char * const *props;
> > -   unsigned int nprops;
> > -   } props[] = {
> > +   static const struct v4l2_fwnode_int_props props[] = {
> > { "flash-leds", led_props, ARRAY_SIZE(led_props) },
> > { "lens-focus", NULL, 0 },
> > };
> > -   unsigned int i;  
> 
> I'd like to keep this here.

Why? IMHO, it makes harder to read (yet, if you insist, I'm ok with 
both ways).

> Apart from that,
> 
> Acked-by: Sakari Ailus 
> 
> >  
> > for (i = 0; i < ARRAY_SIZE(props); i++) {
> > int ret;
> > @@ -1109,9 +1112,7 @@ int 
> > v4l2_async_notifier_parse_fwnode_sensor_common(struct device *dev,
> > if (props[i].props && is_acpi_node(dev_fwnode(dev)))
> > ret = v4l2_fwnode_reference_parse_int_props(dev,
> > notifier,
> > -   
> > props[i].name,
> > -   
> > props[i].props,
> > -   
> > props[i].nprops);
> > +   [i]);
> > else
> > ret = v4l2_fwnode_reference_parse(dev, notifier,
> >   props[i].name);  
> 



Thanks,
Mauro