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 v9 04/13] media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7

[Rui Miguel Silva]

Hi Sakari,
Thanks for the review.

On Mon 03 Dec 2018 at 12:10, Sakari Ailus wrote:

Hi Rui,

On Thu, Nov 22, 2018 at 03:18:25PM +, Rui Miguel Silva 
wrote:
Adds MIPI CSI-2 subdev for i.MX7 to connect with sensors with a 
MIPI

CSI-2 interface.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/Makefile |1 +
 drivers/staging/media/imx/imx7-mipi-csis.c | 1135 
 

 2 files changed, 1136 insertions(+)
 create mode 100644 drivers/staging/media/imx/imx7-mipi-csis.c

diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile

index 074f016d3519..d2d909a36239 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_VIDEO_IMX_CSI) += 
imx-media-csi.o

 obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o
 
 obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o

+obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-mipi-csis.o
diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c 
b/drivers/staging/media/imx/imx7-mipi-csis.c

new file mode 100644
index ..56963d0c2043
--- /dev/null
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -0,0 +1,1135 @@
+// SPDX-License-Identifier: GPL
+/*
+ * Freescale i.MX7 SoC series MIPI-CSI V3.3 receiver driver
+ *
+ * Copyright (C) 2018 Linaro Ltd
+ * Copyright (C) 2015-2016 Freescale Semiconductor, Inc. All 
Rights Reserved.

+ * Copyright (C) 2011 - 2013 Samsung Electronics Co., Ltd.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "imx-media.h"
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Debug level (0-2)");


Could you rely on dynamic debug instead?


Yeah, I will maybe add some debugfs entry.




+
+#define CSIS_DRIVER_NAME   "imx7-mipi-csis"
+#define CSIS_SUBDEV_NAME   CSIS_DRIVER_NAME
+
+#define CSIS_PAD_SINK  0
+#define CSIS_PAD_SOURCE1
+#define CSIS_PADS_NUM  2
+
+#define MIPI_CSIS_DEF_PIX_WIDTH640
+#define MIPI_CSIS_DEF_PIX_HEIGHT   480
+
+/* Register map definition */
+
+/* CSIS common control */
+#define MIPI_CSIS_CMN_CTRL 0x04
+#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW   BIT(16)
+#define MIPI_CSIS_CMN_CTRL_INTER_MODE  BIT(10)
+#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW_CTRL  BIT(2)
+#define MIPI_CSIS_CMN_CTRL_RESET   BIT(1)
+#define MIPI_CSIS_CMN_CTRL_ENABLE  BIT(0)
+
+#define MIPI_CSIS_CMN_CTRL_LANE_NR_OFFSET  8
+#define MIPI_CSIS_CMN_CTRL_LANE_NR_MASK(3 << 8)
+
+/* CSIS clock control */
+#define MIPI_CSIS_CLK_CTRL 0x08
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH3(x)	((x) << 
28)
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH2(x)	((x) << 
24)
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH1(x)	((x) << 
20)
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH0(x)	((x) << 
16)

+#define MIPI_CSIS_CLK_CTRL_CLKGATE_EN_MSK  (0xf << 4)
+#define MIPI_CSIS_CLK_CTRL_WCLK_SRCBIT(0)
+
+/* CSIS Interrupt mask */
+#define MIPI_CSIS_INTMSK   0x10
+#define MIPI_CSIS_INTMSK_EVEN_BEFORE   BIT(31)
+#define MIPI_CSIS_INTMSK_EVEN_AFTERBIT(30)
+#define MIPI_CSIS_INTMSK_ODD_BEFOREBIT(29)
+#define MIPI_CSIS_INTMSK_ODD_AFTER BIT(28)
+#define MIPI_CSIS_INTMSK_FRAME_START   BIT(24)
+#define MIPI_CSIS_INTMSK_FRAME_END BIT(20)
+#define MIPI_CSIS_INTMSK_ERR_SOT_HSBIT(16)
+#define MIPI_CSIS_INTMSK_ERR_LOST_FS   BIT(12)
+#define MIPI_CSIS_INTMSK_ERR_LOST_FE   BIT(8)
+#define MIPI_CSIS_INTMSK_ERR_OVER  BIT(4)
+#define MIPI_CSIS_INTMSK_ERR_WRONG_CFG BIT(3)
+#define MIPI_CSIS_INTMSK_ERR_ECC   BIT(2)
+#define MIPI_CSIS_INTMSK_ERR_CRC   BIT(1)
+#define MIPI_CSIS_INTMSK_ERR_UNKNOWN   BIT(0)
+
+/* CSIS Interrupt source */
+#define MIPI_CSIS_INTSRC   0x14
+#define MIPI_CSIS_INTSRC_EVEN_BEFORE   BIT(31)
+#define MIPI_CSIS_INTSRC_EVEN_AFTERBIT(30)
+#define MIPI_CSIS_INTSRC_EVEN  BIT(30)
+#define MIPI_CSIS_INTSRC_ODD_BEFOREBIT(29)
+#define MIPI_CSIS_INTSRC_ODD_AFTER BIT(28)
+#define MIPI_CSIS_INTSRC_ODD   (0x3 << 28)
+#define MIPI_CSIS_INTSRC_NON_IMAGE_DATA(0xf << 28)
+#define MIPI_CSIS_INTSRC_FRAME_START   BIT(24)
+#define MIPI_CSIS_INTSRC_FRAME_END BIT(20)
+#define MIPI_CSIS_INTSRC_ERR_SOT_HSBIT(16)
+#define MIPI_CSIS_INTSRC_ERR_LOST_FS   BIT(12)
+#define MIPI_CSIS_INTSRC_ERR_LOST_FE   BIT(8)
+#define MIPI_CSIS_INTSRC_ERR_OVER  BIT(4)
+#define MIPI_CSIS_INTSRC_ERR_WRONG_CFG BIT(3)
+#define MIPI_CSIS_INTSRC_ERR_ECC   BIT(2)
+#define MIPI_CSIS_INTSRC_ERR_CRC   BIT(1)
+#define MIPI_CSIS_INTSRC_ERR_UNKNOWN   BIT(0)
+#define MIPI_CSIS_INTSRC_ERRORS0xf
+
+/* D-PHY status control */
+#define MIPI_CSIS_DPHYSTATUS   0x20
+#define MIPI_CSIS_DPHYSTATUS_ULPS_DAT  BIT(8)
+#define 

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

[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

[PATCHv4 04/10] buffer.rst: document the new buffer tag feature.

[hverkuil-cisco]

From: Hans Verkuil 

Document V4L2_BUF_FLAG_TAG.

Signed-off-by: Hans Verkuil 
Reviewed-by: Paul Kocialkowski 
Reviewed-by: Alexandre Courbot 
---
 Documentation/media/uapi/v4l/buffer.rst | 17 ++---
 Documentation/media/uapi/v4l/vidioc-reqbufs.rst |  4 
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index 2e266d32470a..f83ee00cb30b 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -301,10 +301,13 @@ struct v4l2_buffer
elements in the ``planes`` array. The driver will fill in the
actual number of valid elements in that array.
 * - __u32
-  - ``reserved2``
+  - ``tag``
   -
-  - A place holder for future extensions. Drivers and applications
-   must set this to 0.
+  - When the ``V4L2_BUF_FLAG_TAG`` flag is set in ``flags``, this
+   field contains a user-specified tag value.
+
+   It is used by stateless codecs where this tag can be used to
+   refer to buffers that contain reference frames.
 * - __u32
   - ``request_fd``
   -
@@ -567,6 +570,14 @@ Buffer Flags
when the ``VIDIOC_DQBUF`` ioctl is called. Applications can set
this bit and the corresponding ``timecode`` structure when
``type`` refers to an output stream.
+* .. _`V4L2-BUF-FLAG-TAG`:
+
+  - ``V4L2_BUF_FLAG_TAG``
+  - 0x0200
+  - The ``tag`` field is valid. Applications can set
+   this bit and the corresponding ``tag`` field. If tags are
+   supported then the ``V4L2_BUF_CAP_SUPPORTS_TAGS`` capability
+   is also set.
 * .. _`V4L2-BUF-FLAG-PREPARED`:
 
   - ``V4L2_BUF_FLAG_PREPARED``
diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst 
b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
index e62a15782790..38a7d0aee483 100644
--- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
+++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
@@ -118,6 +118,7 @@ aborting or finishing any DMA in progress, an implicit
 .. _V4L2-BUF-CAP-SUPPORTS-DMABUF:
 .. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
 .. _V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS:
+.. _V4L2-BUF-CAP-SUPPORTS-TAGS:
 
 .. cssclass:: longtable
 
@@ -143,6 +144,9 @@ aborting or finishing any DMA in progress, an implicit
   - The kernel allows calling :ref:`VIDIOC_REQBUFS` while buffers are still
 mapped or exported via DMABUF. These orphaned buffers will be freed
 when they are unmapped or when the exported DMABUF fds are closed.
+* - ``V4L2_BUF_CAP_SUPPORTS_TAGS``
+  - 0x0020
+  - This buffer type supports ``V4L2_BUF_FLAG_TAG``.
 
 Return Value
 
-- 
2.19.1

[PATCHv4 09/10] vicodec: add tag support

[hverkuil-cisco]

From: Hans Verkuil 

Copy tags in vicodec.

Signed-off-by: Hans Verkuil 
Reviewed-by: Paul Kocialkowski 
Reviewed-by: Alexandre Courbot 
---
 drivers/media/platform/vicodec/vicodec-core.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/vicodec/vicodec-core.c 
b/drivers/media/platform/vicodec/vicodec-core.c
index b7bdfe97215b..4d39ea033653 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -190,18 +190,8 @@ static int device_process(struct vicodec_ctx *ctx,
}
 
out_vb->sequence = q_cap->sequence++;
-   out_vb->vb2_buf.timestamp = in_vb->vb2_buf.timestamp;
-
-   if (in_vb->flags & V4L2_BUF_FLAG_TIMECODE)
-   out_vb->timecode = in_vb->timecode;
-   out_vb->field = in_vb->field;
out_vb->flags &= ~V4L2_BUF_FLAG_LAST;
-   out_vb->flags |= in_vb->flags &
-   (V4L2_BUF_FLAG_TIMECODE |
-V4L2_BUF_FLAG_KEYFRAME |
-V4L2_BUF_FLAG_PFRAME |
-V4L2_BUF_FLAG_BFRAME |
-V4L2_BUF_FLAG_TSTAMP_SRC_MASK);
+   v4l2_m2m_buf_copy_data(in_vb, out_vb, !ctx->is_enc);
 
return 0;
 }
@@ -1083,6 +1073,7 @@ static int queue_init(void *priv, struct vb2_queue 
*src_vq,
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
src_vq->lock = ctx->is_enc ? &ctx->dev->enc_mutex :
&ctx->dev->dec_mutex;
+   src_vq->supports_tags = true;
 
ret = vb2_queue_init(src_vq);
if (ret)
@@ -1098,6 +1089,7 @@ static int queue_init(void *priv, struct vb2_queue 
*src_vq,
dst_vq->mem_ops = &vb2_vmalloc_memops;
dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
dst_vq->lock = src_vq->lock;
+   dst_vq->supports_tags = true;
 
return vb2_queue_init(dst_vq);
 }
-- 
2.19.1

[PATCHv4 07/10] vb2: add new supports_tags queue flag

[hverkuil-cisco]

From: Hans Verkuil 

Add new flag to indicate that buffer tags are supported.

Signed-off-by: Hans Verkuil 
Reviewed-by: Paul Kocialkowski 
Reviewed-by: Alexandre Courbot 
---
 drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 ++
 include/media/videobuf2-core.h  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index e0e31e1c67c9..5aa5b1ea90a8 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -659,6 +659,8 @@ static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
*caps |= V4L2_BUF_CAP_SUPPORTS_DMABUF;
if (q->supports_requests)
*caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
+   if (q->supports_tags)
+   *caps |= V4L2_BUF_CAP_SUPPORTS_TAGS;
 }
 
 int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index e86981d615ae..81f2dbfd0094 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -473,6 +473,7 @@ struct vb2_buf_ops {
  *  has not been called. This is a vb1 idiom that has been adopted
  *  also by vb2.
  * @supports_requests: this queue supports the Request API.
+ * @supports_tags: this queue supports tags in struct v4l2_buffer.
  * @uses_qbuf: qbuf was used directly for this queue. Set to 1 the first
  * time this is called. Set to 0 when the queue is canceled.
  * If this is 1, then you cannot queue buffers from a request.
@@ -547,6 +548,7 @@ struct vb2_queue {
unsignedallow_zero_bytesused:1;
unsigned   quirk_poll_must_check_waiting_for_buffers:1;
unsignedsupports_requests:1;
+   unsignedsupports_tags:1;
unsigneduses_qbuf:1;
unsigneduses_requests:1;
 
-- 
2.19.1

[PATCHv4 06/10] v4l2-mem2mem: add v4l2_m2m_buf_copy_data helper function

[hverkuil-cisco]

From: Hans Verkuil 

Memory-to-memory devices should copy various parts of
struct v4l2_buffer from the output buffer to the capture buffer.

Add a helper function that does that to simplify the driver code.

Signed-off-by: Hans Verkuil 
Reviewed-by: Paul Kocialkowski 
Reviewed-by: Alexandre Courbot 
---
 drivers/media/v4l2-core/v4l2-mem2mem.c | 23 +++
 include/media/v4l2-mem2mem.h   | 21 +
 2 files changed, 44 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 5bbdec55b7d7..a9cb1ac33dc0 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -975,6 +975,29 @@ void v4l2_m2m_buf_queue(struct v4l2_m2m_ctx *m2m_ctx,
 }
 EXPORT_SYMBOL_GPL(v4l2_m2m_buf_queue);
 
+void v4l2_m2m_buf_copy_data(const struct vb2_v4l2_buffer *out_vb,
+   struct vb2_v4l2_buffer *cap_vb,
+   bool copy_frame_flags)
+{
+   u32 mask = V4L2_BUF_FLAG_TIMECODE | V4L2_BUF_FLAG_TAG |
+  V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
+
+   if (copy_frame_flags)
+   mask |= V4L2_BUF_FLAG_KEYFRAME | V4L2_BUF_FLAG_PFRAME |
+   V4L2_BUF_FLAG_BFRAME;
+
+   cap_vb->vb2_buf.timestamp = out_vb->vb2_buf.timestamp;
+
+   if (out_vb->flags & V4L2_BUF_FLAG_TAG)
+   cap_vb->tag = out_vb->tag;
+   if (out_vb->flags & V4L2_BUF_FLAG_TIMECODE)
+   cap_vb->timecode = out_vb->timecode;
+   cap_vb->field = out_vb->field;
+   cap_vb->flags &= ~mask;
+   cap_vb->flags |= out_vb->flags & mask;
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_buf_copy_data);
+
 void v4l2_m2m_request_queue(struct media_request *req)
 {
struct media_request_object *obj, *obj_safe;
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index 5467264771ec..bb4feb6969d2 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -622,6 +622,27 @@ v4l2_m2m_dst_buf_remove_by_idx(struct v4l2_m2m_ctx 
*m2m_ctx, unsigned int idx)
return v4l2_m2m_buf_remove_by_idx(&m2m_ctx->cap_q_ctx, idx);
 }
 
+/**
+ * v4l2_m2m_buf_copy_data() - copy buffer data from the output buffer to the
+ * capture buffer
+ *
+ * @out_vb: the output buffer that is the source of the data.
+ * @cap_vb: the capture buffer that will receive the data.
+ * @copy_frame_flags: copy the KEY/B/PFRAME flags as well.
+ *
+ * This helper function copies the timestamp, timecode (if the TIMECODE
+ * buffer flag was set), tag (if the TAG buffer flag was set), field
+ * and the TIMECODE, TAG, KEYFRAME, BFRAME, PFRAME and TSTAMP_SRC_MASK
+ * flags from @out_vb to @cap_vb.
+ *
+ * If @copy_frame_flags is false, then the KEYFRAME, BFRAME and PFRAME
+ * flags are not copied. This is typically needed for encoders that
+ * set this bits explicitly.
+ */
+void v4l2_m2m_buf_copy_data(const struct vb2_v4l2_buffer *out_vb,
+   struct vb2_v4l2_buffer *cap_vb,
+   bool copy_frame_flags);
+
 /* v4l2 request helper */
 
 void v4l2_m2m_request_queue(struct media_request *req);
-- 
2.19.1

[PATCHv4 03/10] v4l2-ioctl.c: log v4l2_buffer tag

[hverkuil-cisco]

From: Hans Verkuil 

When debugging is on, log the new tag field of struct v4l2_buffer
as well.

Signed-off-by: Hans Verkuil 
Reviewed-by: Paul Kocialkowski 
Reviewed-by: Alexandre Courbot 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index b9616b1f227b..07c6c939a23c 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -498,9 +498,12 @@ static void v4l_print_buffer(const void *arg, bool 
write_only)
p->bytesused, p->m.userptr, p->length);
}
 
-   printk(KERN_DEBUG "timecode=%02d:%02d:%02d type=%d, flags=0x%08x, 
frames=%d, userbits=0x%08x\n",
-   tc->hours, tc->minutes, tc->seconds,
-   tc->type, tc->flags, tc->frames, *(__u32 
*)tc->userbits);
+   if (p->flags & V4L2_BUF_FLAG_TAG)
+   printk(KERN_DEBUG "tag=%x\n", p->tag);
+   if (p->flags & V4L2_BUF_FLAG_TIMECODE)
+   printk(KERN_DEBUG "timecode=%02d:%02d:%02d type=%d, 
flags=0x%08x, frames=%d, userbits=0x%08x\n",
+  tc->hours, tc->minutes, tc->seconds,
+  tc->type, tc->flags, tc->frames, *(__u32 *)tc->userbits);
 }
 
 static void v4l_print_exportbuffer(const void *arg, bool write_only)
-- 
2.19.1

[PATCHv4 05/10] buffer.rst: clean up timecode documentation

[hverkuil-cisco]

From: Hans Verkuil 

V4L2_BUF_FLAG_TIMECODE is not video capture specific, so drop that
part.

The 'Timecodes' section was a bit messy, so that's cleaned up.

Signed-off-by: Hans Verkuil 
Reviewed-by: Paul Kocialkowski 
Reviewed-by: Alexandre Courbot 
---
 Documentation/media/uapi/v4l/buffer.rst | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index f83ee00cb30b..359b131a212d 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -223,8 +223,7 @@ struct v4l2_buffer
 * - struct :c:type:`v4l2_timecode`
   - ``timecode``
   -
-  - When ``type`` is ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` and the
-   ``V4L2_BUF_FLAG_TIMECODE`` flag is set in ``flags``, this
+  - When the ``V4L2_BUF_FLAG_TIMECODE`` flag is set in ``flags``, this
structure contains a frame timecode. In
:c:type:`V4L2_FIELD_ALTERNATE ` mode the top and
bottom field contain the same timecode. Timecodes are intended to
@@ -715,10 +714,10 @@ enum v4l2_memory
 Timecodes
 =
 
-The struct :c:type:`v4l2_timecode` structure is designed to hold a
-:ref:`smpte12m` or similar timecode. (struct
-struct :c:type:`timeval` timestamps are stored in struct
-:c:type:`v4l2_buffer` field ``timestamp``.)
+The :c:type:`v4l2_buffer_timecode` structure is designed to hold a
+:ref:`smpte12m` or similar timecode.
+(struct :c:type:`timeval` timestamps are stored in the struct
+:c:type:`v4l2_buffer` ``timestamp`` field.)
 
 
 .. c:type:: v4l2_timecode
-- 
2.19.1

[PATCHv4 02/10] vb2: add tag support

[hverkuil-cisco]

From: Hans Verkuil 

Add support for tags to vb2. Besides just storing and setting
the tag this patch also adds the vb2_find_tag() function that
can be used to find a buffer with the given tag.

This function will only look at DEQUEUED and DONE buffers, i.e.
buffers that are already processed.

Signed-off-by: Hans Verkuil 
Reviewed-by: Paul Kocialkowski 
Reviewed-by: Alexandre Courbot 
---
 .../media/common/videobuf2/videobuf2-v4l2.c   | 39 ---
 include/media/videobuf2-v4l2.h| 21 +-
 2 files changed, 53 insertions(+), 7 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 1244c246d0c4..e0e31e1c67c9 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -50,7 +50,8 @@ module_param(debug, int, 0644);
 V4L2_BUF_FLAG_TIMESTAMP_MASK)
 /* Output buffer flags that should be passed on to the driver */
 #define V4L2_BUFFER_OUT_FLAGS  (V4L2_BUF_FLAG_PFRAME | V4L2_BUF_FLAG_BFRAME | \
-V4L2_BUF_FLAG_KEYFRAME | 
V4L2_BUF_FLAG_TIMECODE)
+V4L2_BUF_FLAG_KEYFRAME | \
+V4L2_BUF_FLAG_TIMECODE | V4L2_BUF_FLAG_TAG)
 
 /*
  * __verify_planes_array() - verify that the planes array passed in struct
@@ -144,7 +145,10 @@ static void __copy_timestamp(struct vb2_buffer *vb, const 
void *pb)
 */
if (q->copy_timestamp)
vb->timestamp = timeval_to_ns(&b->timestamp);
-   vbuf->flags |= b->flags & V4L2_BUF_FLAG_TIMECODE;
+   vbuf->flags |= b->flags &
+   (V4L2_BUF_FLAG_TIMECODE | V4L2_BUF_FLAG_TAG);
+   if (b->flags & V4L2_BUF_FLAG_TAG)
+   vbuf->tag = b->tag;
if (b->flags & V4L2_BUF_FLAG_TIMECODE)
vbuf->timecode = b->timecode;
}
@@ -194,6 +198,7 @@ static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer *vb, 
struct v4l2_buffer *b
}
vbuf->sequence = 0;
vbuf->request_fd = -1;
+   vbuf->tag = 0;
 
if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
switch (b->memory) {
@@ -314,12 +319,12 @@ static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer 
*vb, struct v4l2_buffer *b
 
if (V4L2_TYPE_IS_OUTPUT(b->type)) {
/*
-* For output buffers mask out the timecode flag:
-* this will be handled later in vb2_qbuf().
+* For output buffers mask out the timecode and tag flags:
+* these will be handled later in vb2_qbuf().
 * The 'field' is valid metadata for this output buffer
 * and so that needs to be copied here.
 */
-   vbuf->flags &= ~V4L2_BUF_FLAG_TIMECODE;
+   vbuf->flags &= ~(V4L2_BUF_FLAG_TIMECODE | V4L2_BUF_FLAG_TAG);
vbuf->field = b->field;
} else {
/* Zero any output buffer flags as this is a capture buffer */
@@ -460,7 +465,10 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
b->flags = vbuf->flags;
b->field = vbuf->field;
b->timestamp = ns_to_timeval(vb->timestamp);
-   b->timecode = vbuf->timecode;
+   if (b->flags & V4L2_BUF_FLAG_TAG)
+   b->tag = vbuf->tag;
+   if (b->flags & V4L2_BUF_FLAG_TIMECODE)
+   b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
b->reserved2 = 0;
b->request_fd = 0;
@@ -586,6 +594,25 @@ static const struct vb2_buf_ops v4l2_buf_ops = {
.copy_timestamp = __copy_timestamp,
 };
 
+int vb2_find_tag(const struct vb2_queue *q, u32 tag,
+unsigned int start_idx)
+{
+   unsigned int i;
+
+   for (i = start_idx; i < q->num_buffers; i++) {
+   struct vb2_buffer *vb = q->bufs[i];
+   struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+
+   if ((vb->state == VB2_BUF_STATE_DEQUEUED ||
+vb->state == VB2_BUF_STATE_DONE) &&
+   (vbuf->flags & V4L2_BUF_FLAG_TAG) &&
+   vbuf->tag == tag)
+   return i;
+   }
+   return -1;
+}
+EXPORT_SYMBOL_GPL(vb2_find_tag);
+
 /*
  * vb2_querybuf() - query video buffer information
  * @q: videobuf queue
diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
index 727855463838..c2a541af6b2c 100644
--- a/include/media/videobuf2-v4l2.h
+++ b/include/media/videobuf2-v4l2.h
@@ -31,8 +31,9 @@
  * @field: field order of the image in the buffer, as defined by
  * &enum v4l2_field.
  * @timecode:  frame timecode.
+ * @tag:   user specified buffer tag value.
  * @sequence:  sequence count of this frame.
- * @request_fd:the request_fd associated with this buffer
+ * @reques

[PATCHv4 01/10] videodev2.h: add tag support

[hverkuil-cisco]

From: Hans Verkuil 

Add support for 'tags' to struct v4l2_buffer. These can be used
by m2m devices so userspace can set a tag for an output buffer and
this value will then be copied to the capture buffer(s).

This tag can be used to refer to capture buffers, something that
is needed by stateless HW codecs.

The new V4L2_BUF_CAP_SUPPORTS_TAGS capability indicates whether
or not tags are supported.

Signed-off-by: Hans Verkuil 
Reviewed-by: Paul Kocialkowski 
Reviewed-by: Alexandre Courbot 
---
 include/uapi/linux/videodev2.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2db1635de956..9095d7abe10d 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -881,6 +881,7 @@ struct v4l2_requestbuffers {
 #define V4L2_BUF_CAP_SUPPORTS_DMABUF   (1 << 2)
 #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
 #define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
+#define V4L2_BUF_CAP_SUPPORTS_TAGS (1 << 5)
 
 /**
  * struct v4l2_plane - plane info for multi-planar buffers
@@ -940,6 +941,7 @@ struct v4l2_plane {
  * @length:size in bytes of the buffer (NOT its payload) for single-plane
  * buffers (when type != *_MPLANE); number of elements in the
  * planes array for multi-plane buffers
+ * @tag:   buffer tag
  * @request_fd: fd of the request that this buffer should use
  *
  * Contains data exchanged by application and driver using one of the Streaming
@@ -964,7 +966,10 @@ struct v4l2_buffer {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   union {
+   __u32   reserved2;
+   __u32   tag;
+   };
union {
__s32   request_fd;
__u32   reserved;
@@ -990,6 +995,8 @@ struct v4l2_buffer {
 #define V4L2_BUF_FLAG_IN_REQUEST   0x0080
 /* timecode field is valid */
 #define V4L2_BUF_FLAG_TIMECODE 0x0100
+/* tag field is valid */
+#define V4L2_BUF_FLAG_TAG  0x0200
 /* Buffer is prepared for queuing */
 #define V4L2_BUF_FLAG_PREPARED 0x0400
 /* Cache handling flags */
-- 
2.19.1

[PATCHv4 08/10] vim2m: add tag support

[hverkuil-cisco]

From: Hans Verkuil 

Copy tags in vim2m.

Signed-off-by: Hans Verkuil 
Reviewed-by: Paul Kocialkowski 
Reviewed-by: Alexandre Courbot 
---
 drivers/media/platform/vim2m.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index d01821a6906a..be328483a53a 100644
--- a/drivers/media/platform/vim2m.c
+++ b/drivers/media/platform/vim2m.c
@@ -241,17 +241,7 @@ static int device_process(struct vim2m_ctx *ctx,
out_vb->sequence =
get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE)->sequence++;
in_vb->sequence = q_data->sequence++;
-   out_vb->vb2_buf.timestamp = in_vb->vb2_buf.timestamp;
-
-   if (in_vb->flags & V4L2_BUF_FLAG_TIMECODE)
-   out_vb->timecode = in_vb->timecode;
-   out_vb->field = in_vb->field;
-   out_vb->flags = in_vb->flags &
-   (V4L2_BUF_FLAG_TIMECODE |
-V4L2_BUF_FLAG_KEYFRAME |
-V4L2_BUF_FLAG_PFRAME |
-V4L2_BUF_FLAG_BFRAME |
-V4L2_BUF_FLAG_TSTAMP_SRC_MASK);
+   v4l2_m2m_buf_copy_data(out_vb, in_vb, true);
 
switch (ctx->mode) {
case MEM2MEM_HFLIP | MEM2MEM_VFLIP:
@@ -855,6 +845,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, 
struct vb2_queue *ds
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
src_vq->lock = &ctx->dev->dev_mutex;
src_vq->supports_requests = true;
+   src_vq->supports_tags = true;
 
ret = vb2_queue_init(src_vq);
if (ret)
@@ -868,6 +859,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, 
struct vb2_queue *ds
dst_vq->mem_ops = &vb2_vmalloc_memops;
dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
dst_vq->lock = &ctx->dev->dev_mutex;
+   dst_vq->supports_tags = true;
 
return vb2_queue_init(dst_vq);
 }
-- 
2.19.1

[PATCHv4 10/10] cedrus: add tag support

[hverkuil-cisco]

From: Hans Verkuil 

Replace old reference frame indices by new tag method.

Signed-off-by: Hans Verkuil 
Reviewed-by: Paul Kocialkowski 
Reviewed-by: Alexandre Courbot 
---
 drivers/media/v4l2-core/v4l2-ctrls.c  |  9 
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  9 +---
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |  2 ++
 .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 21 ---
 .../staging/media/sunxi/cedrus/cedrus_video.c |  2 ++
 include/uapi/linux/v4l2-controls.h| 14 +
 6 files changed, 24 insertions(+), 33 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 129a986fa7e1..e859496e4e95 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1661,15 +1661,6 @@ static int std_validate(const struct v4l2_ctrl *ctrl, 
u32 idx,
return -EINVAL;
}
 
-   if (p_mpeg2_slice_params->backward_ref_index >= VIDEO_MAX_FRAME 
||
-   p_mpeg2_slice_params->forward_ref_index >= VIDEO_MAX_FRAME)
-   return -EINVAL;
-
-   if (p_mpeg2_slice_params->pad ||
-   p_mpeg2_slice_params->picture.pad ||
-   p_mpeg2_slice_params->sequence.pad)
-   return -EINVAL;
-
return 0;
 
case V4L2_CTRL_TYPE_MPEG2_QUANTIZATION:
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h 
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 3f61248c57ac..781676b55a1b 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -142,11 +142,14 @@ static inline dma_addr_t cedrus_buf_addr(struct 
vb2_buffer *buf,
 }
 
 static inline dma_addr_t cedrus_dst_buf_addr(struct cedrus_ctx *ctx,
-unsigned int index,
-unsigned int plane)
+int index, unsigned int plane)
 {
-   struct vb2_buffer *buf = ctx->dst_bufs[index];
+   struct vb2_buffer *buf;
 
+   if (index < 0)
+   return 0;
+
+   buf = ctx->dst_bufs[index];
return buf ? cedrus_buf_addr(buf, &ctx->dst_fmt, plane) : 0;
 }
 
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..0cfd6036d0cd 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -53,6 +53,8 @@ void cedrus_device_run(void *priv)
break;
}
 
+   v4l2_m2m_buf_copy_data(run.src, run.dst, true);
+
dev->dec_ops[ctx->current_codec]->setup(ctx, &run);
 
spin_unlock_irqrestore(&ctx->dev->irq_lock, flags);
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
index 9abd39cae38c..fdde9a099153 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
@@ -82,7 +82,10 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx, 
struct cedrus_run *run)
dma_addr_t fwd_luma_addr, fwd_chroma_addr;
dma_addr_t bwd_luma_addr, bwd_chroma_addr;
struct cedrus_dev *dev = ctx->dev;
+   struct vb2_queue *cap_q = &ctx->fh.m2m_ctx->cap_q_ctx.q;
const u8 *matrix;
+   int forward_idx;
+   int backward_idx;
unsigned int i;
u32 reg;
 
@@ -156,23 +159,17 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx, 
struct cedrus_run *run)
cedrus_write(dev, VE_DEC_MPEG_PICBOUNDSIZE, reg);
 
/* Forward and backward prediction reference buffers. */
+   forward_idx = vb2_find_tag(cap_q, slice_params->forward_ref_tag, 0);
 
-   fwd_luma_addr = cedrus_dst_buf_addr(ctx,
-   slice_params->forward_ref_index,
-   0);
-   fwd_chroma_addr = cedrus_dst_buf_addr(ctx,
- slice_params->forward_ref_index,
- 1);
+   fwd_luma_addr = cedrus_dst_buf_addr(ctx, forward_idx, 0);
+   fwd_chroma_addr = cedrus_dst_buf_addr(ctx, forward_idx, 1);
 
cedrus_write(dev, VE_DEC_MPEG_FWD_REF_LUMA_ADDR, fwd_luma_addr);
cedrus_write(dev, VE_DEC_MPEG_FWD_REF_CHROMA_ADDR, fwd_chroma_addr);
 
-   bwd_luma_addr = cedrus_dst_buf_addr(ctx,
-   slice_params->backward_ref_index,
-   0);
-   bwd_chroma_addr = cedrus_dst_buf_addr(ctx,
- slice_params->backward_ref_index,
- 1);
+   backward_idx = vb2_find_tag(cap_q, slice_params->backward_ref_tag, 0);
+   bwd_luma_addr = cedrus_dst_buf_addr(ctx, backward_idx, 0);
+   bwd_

[PATCHv4 00/10] As was discussed here (among other places):

[hverkuil-cisco]

From: Hans Verkuil 

https://lkml.org/lkml/2018/10/19/440

using capture queue buffer indices to refer to reference frames is
not a good idea. A better idea is to use a 'tag' where the
application can assign a u32 tag to an output buffer, which is then 
copied to the capture buffer(s) derived from the output buffer.

It has been suggested that the timestamp can be used for this. But
there are a number of reasons why this is a bad idea:

1) the struct timeval is converted to a u64 in vb2. So there can be
   all sorts of unexpected conversion issues. In particular, the
   output of ns_to_timeval(timeval_to_ns(tv)) does not necessarily
   match the input.

2) it gets worse with the y2038 code where userspace either deals
   with a 32 bit tv_sec value or a 64 bit value.

In other words, using timestamp for this is not a good idea.

This implementation adds a new tag field in a union with the reserved2
field. The interpretation of that union depends on the flags field, so
it still can be used for other things as well. In addition, in the previous
patches the tag was in a union with the timecode field (again determined
by the flags field), so if we need to cram additional information in this
struct we can always put it in a union with the timecode field as well.
It worked for the tag, it should work for other things.

But we really need to start looking at a struct v4l2_ext_buffer.

The first three patches add core tag support, the next two patches document
the tag support, then a new helper function is added to v4l2-mem2mem.c
to easily copy data from a source to a destination buffer that drivers
can use.

Next a new supports_tags vb2_queue flag is added to indicate that
the driver supports tags. Ideally this should not be necessary, but
that would require that all m2m drivers are converted to using the
new helper function introduced in the previous patch. That takes more
time then I have now.

Finally the vim2m, vicodec and cedrus drivers are converted to support
tags.

I also removed the 'pad' fields from the mpeg2 control structs (it
should never been added in the first place) and aligned the structs
to a u32 boundary.

Note that this might change further (Paul suggested using bitfields).

Also note that the cedrus code doesn't set the sequence counter, that's
something that should still be added before this driver can be moved
out of staging.

Note: if no buffer is found for a certain tag, then the dma address
is just set to 0. That happened before as well with invalid buffer
indices. This should be checked in the driver!

Regards,

Hans

Changes since v3:

- use reserved2 for the tag
- split the documentation in two: one documenting the tag, one
  cleaning up the timecode documentation.

Changes since v2:

- rebased
- added Reviewed-by tags
- fixed a few remaining references in the documentation to the old
  v4l2_buffer_tag struct that was used in early versions of this
  series.

Changes since v1:

- changed to a u32 tag. Using a 64 bit tag was overly complicated due
  to the bad layout of the v4l2_buffer struct, and there is no real
  need for it by applications.

Main changes since the RFC:

- Added new buffer capability flag
- Added m2m helper to copy data between buffers
- Added documentation
- Added tag logging in v4l2-ioctl.c


Hans Verkuil (10):
  videodev2.h: add tag support
  vb2: add tag support
  v4l2-ioctl.c: log v4l2_buffer tag
  buffer.rst: document the new buffer tag feature.
  buffer.rst: clean up timecode documentation
  v4l2-mem2mem: add v4l2_m2m_buf_copy_data helper function
  vb2: add new supports_tags queue flag
  vim2m: add tag support
  vicodec: add tag support
  cedrus: add tag support

 Documentation/media/uapi/v4l/buffer.rst   | 28 +
 .../media/uapi/v4l/vidioc-reqbufs.rst |  4 ++
 .../media/common/videobuf2/videobuf2-v4l2.c   | 41 ---
 drivers/media/platform/vicodec/vicodec-core.c | 14 ++-
 drivers/media/platform/vim2m.c| 14 ++-
 drivers/media/v4l2-core/v4l2-ctrls.c  |  9 
 drivers/media/v4l2-core/v4l2-ioctl.c  |  9 ++--
 drivers/media/v4l2-core/v4l2-mem2mem.c| 23 +++
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  9 ++--
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |  2 +
 .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 21 --
 .../staging/media/sunxi/cedrus/cedrus_video.c |  2 +
 include/media/v4l2-mem2mem.h  | 21 ++
 include/media/videobuf2-core.h|  2 +
 include/media/videobuf2-v4l2.h| 21 +-
 include/uapi/linux/v4l2-controls.h| 14 +++
 include/uapi/linux/videodev2.h|  9 +++-
 17 files changed, 168 insertions(+), 75 deletions(-)

-- 
2.19.1

[PATCHv4 11/10] extended-controls.rst: update the mpeg2 compound controls

[Hans Verkuil]

The layout of the compound controls has changed to fix
32/64 bit alignment issues and the use of tags instead of
buffer indices to refer to buffers. Note that these controls
are only used by the cedrus staging driver.

Signed-off-by: Hans Verkuil 
---
 .../media/uapi/v4l/extended-controls.rst  | 24 ++-
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index 65a1d873196b..b9e3af29a704 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1528,17 +1528,19 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
   - ``picture``
   - Structure with MPEG-2 picture metadata, merging relevant fields from
the picture header and picture coding extension parts of the bitstream.
-* - __u8
+* - __u32
+  - ``backward_ref_tag``
+  - Tag for the V4L2 buffer to use as backward reference, used with
+   B-coded and P-coded frames. The tag refers to the ``tag`` field in
+   struct :c:type:`v4l2_buffer`.
+* - __u32
+  - ``forward_ref_tag``
+  - Tag for the V4L2 buffer to use as forward reference, used with
+   B-coded frames. The tag refers to the ``tag`` field in
+   struct :c:type:`v4l2_buffer`.
+* - __u32
   - ``quantiser_scale_code``
   - Code used to determine the quantization scale to use for the IDCT.
-* - __u8
-  - ``backward_ref_index``
-  - Index for the V4L2 buffer to use as backward reference, used with
-   B-coded and P-coded frames.
-* - __u8
-  - ``forward_ref_index``
-  - Index for the V4L2 buffer to use as forward reference, used with
-   B-coded frames.

 .. c:type:: v4l2_mpeg2_sequence

@@ -1559,7 +1561,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
   - ``vbv_buffer_size``
   - Used to calculate the required size of the video buffering verifier,
defined (in bits) as: 16 * 1024 * vbv_buffer_size.
-* - __u8
+* - __u16
   - ``profile_and_level_indication``
   - The current profile and level indication as extracted from the
bitstream.
@@ -1617,7 +1619,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
 * - __u8
   - ``repeat_first_field``
   - This flag affects the decoding process of progressive frames.
-* - __u8
+* - __u16
   - ``progressive_frame``
   - Indicates whether the current frame is progressive.

-- 
2.19.1

[GIT PULL for 4.21] More sensor driver patches

[sakari . ailus]

Hi Mauro,

Here are improvements for various sensor drivers for 4.21. There area few
trivial V4L2 fwnode and async framework changes as well, plus DT binding
documentation for mt9m111.

Please pull.


The following changes since commit 9b90dc85c718443a3e573a0ccf55900ff4fa73ae:

  media: seco-cec: add missing header file to fix build (2018-12-03 15:11:00 
-0500)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git tags/for-4.21-4-sign

for you to fetch changes up to bf8da26398f03704bbf7bb10b9c847fd187f4260:

  v4l2: async: remove locking when initializing async notifier (2018-12-05 
12:10:24 +0200)


sensor driver patches and stuff for 4.21


Bingbu Cao (3):
  media: imx319: fix wrong order in test pattern menus
  media: imx355: fix wrong order in test pattern menus
  media: unify some sony camera sensors pattern naming

Enrico Scholz (1):
  media: mt9m111: allow to setup pixclk polarity

Fabio Estevam (1):
  media: v4l2-fwnode: Demote warning to debug level

Jacopo Mondi (1):
  media: ov5640: Fix set format regression

Luca Ceresoli (3):
  media: imx274: fix stack corruption in imx274_read_reg
  media: imx274: declare the correct number of controls
  media: imx274: select REGMAP_I2C

Marco Felsch (3):
  media: mt9m111: add s_stream callback
  dt-bindings: media: mt9m111: adapt documentation to be more clear
  dt-bindings: media: mt9m111: add pclk-sample property

Maxime Ripard (11):
  media: ov5640: Adjust the clock based on the expected rate
  media: ov5640: Remove the clocks registers initialization
  media: ov5640: Remove redundant defines
  media: ov5640: Remove redundant register setup
  media: ov5640: Compute the clock rate at runtime
  media: ov5640: Remove pixel clock rates
  media: ov5640: Enhance FPS handling
  media: ov5640: Make the return rate type more explicit
  media: ov5640: Make the FPS clamping / rounding more extendable
  media: ov5640: Add 60 fps support
  media: ov5640: Remove duplicate auto-exposure setup

Michael Grzeschik (2):
  media: mt9m111: add streaming check to set_fmt
  media: mt9m111: add support to select formats and fps for {Q,SXGA}

Niklas Söderlund (1):
  v4l2: async: remove locking when initializing async notifier

 .../devicetree/bindings/media/i2c/mt9m111.txt  |  13 +-
 drivers/media/i2c/Kconfig  |   2 +
 drivers/media/i2c/imx258.c |   8 +-
 drivers/media/i2c/imx274.c |   9 +-
 drivers/media/i2c/imx319.c |   8 +-
 drivers/media/i2c/imx355.c |   8 +-
 drivers/media/i2c/mt9m111.c| 222 +-
 drivers/media/i2c/ov5640.c | 764 -
 drivers/media/v4l2-core/v4l2-async.c   |   4 -
 drivers/media/v4l2-core/v4l2-fwnode.c  |   2 +-
 10 files changed, 703 insertions(+), 337 deletions(-)

-- 
Regards,

Sakari Ailus

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

[GIT PULL FOR v4.21] vicodec cleanup

[Hans Verkuil]

The following changes since commit b2e9a4eda11fd2cb1e6714e9ad3f455c402568ff:

  media: firewire: Fix app_info parameter type in avc_ca{,_app}_info 
(2018-12-05 05:34:33 -0500)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21h

for you to fetch changes up to a1e9f0504e413d4ae9f7e8879be59253f676f429:

  media: vicodec: Change variable names (2018-12-05 12:44:42 +0100)


Tag branch


Dafna Hirschfeld (1):
  media: vicodec: Change variable names

 drivers/media/platform/vicodec/vicodec-core.c | 94 
---
 1 file changed, 48 insertions(+), 46 deletions(-)

[PATCH for v4.20 2/2] extended-controls.rst: add note to the MPEG2 state controls

[hverkuil-cisco]

From: Hans Verkuil 

Add a note mentioning that these two controls are not part of the
public API while they still stabilizing.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/extended-controls.rst | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index 65a1d873196b..027358b91082 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1505,6 +1505,11 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
 configuring a stateless hardware decoding pipeline for MPEG-2.
 The bitstream parameters are defined according to :ref:`mpeg2part2`.
 
+.. note::
+
+   This compound control is not yet part of the public kernel API and
+   it is expected to change.
+
 .. c:type:: v4l2_ctrl_mpeg2_slice_params
 
 .. cssclass:: longtable
@@ -1625,6 +1630,11 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
 Specifies quantization matrices (as extracted from the bitstream) for the
 associated MPEG-2 slice data.
 
+.. note::
+
+   This compound control is not yet part of the public kernel API and
+   it is expected to change.
+
 .. c:type:: v4l2_ctrl_mpeg2_quantization
 
 .. cssclass:: longtable
-- 
2.19.1

[PATCH for v4.20 0/2] cedrus: move MPEG controls out of the uAPI

[hverkuil-cisco]

From: Hans Verkuil 

The expectation was that the MPEG-2 state controls used by the staging
cedrus driver were stable, or would only require one final change. However,
it turns out that more changes are required, and that means that it is not
such a good idea to have these controls in the public kernel API.

This patch series moves all the MPEG-2 state control data to a new
media/mpeg2-ctrls.h header. So none of this is available from the public
API.

However, v4l2-ctrls.h includes it for now so the kAPI still knows about it
allowing the cedrus driver to use it without changes.

The second patch adds a note to these two controls, mentioning that they
are likely to change.

Moving forward, this allows us to take more time in getting the MPEG-2
(and later H264/5) state controls right.

Regards,

Hans

Hans Verkuil (2):
  mpeg2-ctrls.h: move MPEG2 state controls to non-public header
  extended-controls.rst: add note to the MPEG2 state controls

 .../media/uapi/v4l/extended-controls.rst  | 10 +++
 drivers/media/v4l2-core/v4l2-ctrls.c  |  4 +-
 include/media/mpeg2-ctrls.h   | 86 +++
 include/media/v4l2-ctrls.h|  6 ++
 include/uapi/linux/v4l2-controls.h| 68 ---
 include/uapi/linux/videodev2.h|  4 -
 6 files changed, 104 insertions(+), 74 deletions(-)
 create mode 100644 include/media/mpeg2-ctrls.h

-- 
2.19.1

[PATCH for v4.20 1/2] mpeg2-ctrls.h: move MPEG2 state controls to non-public header

[hverkuil-cisco]

From: Hans Verkuil 

The MPEG2 state controls for the cedrus stateless MPEG2 driver are
not yet stable. Move them out of the public headers into media/mpeg2-ctrls.h.

Eventually, once this has stabilized, they will be moved back to the
public headers.

Unfortunately I had to cast the control type to a u32 in two switch
statements to prevent a compiler warning about a control type define
not being part of the enum.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-ctrls.c |  4 +-
 include/media/mpeg2-ctrls.h  | 86 
 include/media/v4l2-ctrls.h   |  6 ++
 include/uapi/linux/v4l2-controls.h   | 68 --
 include/uapi/linux/videodev2.h   |  4 --
 5 files changed, 94 insertions(+), 74 deletions(-)
 create mode 100644 include/media/mpeg2-ctrls.h

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 5f2b033a7a42..10b8d94edbef 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1563,7 +1563,7 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32 
idx,
u64 offset;
s64 val;
 
-   switch (ctrl->type) {
+   switch ((u32)ctrl->type) {
case V4L2_CTRL_TYPE_INTEGER:
return ROUND_TO_RANGE(ptr.p_s32[idx], u32, ctrl);
case V4L2_CTRL_TYPE_INTEGER64:
@@ -2232,7 +2232,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
v4l2_ctrl_handler *hdl,
is_array = nr_of_dims > 0;
 
/* Prefill elem_size for all types handled by std_type_ops */
-   switch (type) {
+   switch ((u32)type) {
case V4L2_CTRL_TYPE_INTEGER64:
elem_size = sizeof(s64);
break;
diff --git a/include/media/mpeg2-ctrls.h b/include/media/mpeg2-ctrls.h
new file mode 100644
index ..d21f40edc09e
--- /dev/null
+++ b/include/media/mpeg2-ctrls.h
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * These are the MPEG2 state controls for use with stateless MPEG-2
+ * codec drivers.
+ *
+ * It turns out that these structs are not stable yet and will undergo
+ * more changes. So keep them private until they are stable and ready to
+ * become part of the official public API.
+ */
+
+#ifndef _MPEG2_CTRLS_H_
+#define _MPEG2_CTRLS_H_
+
+#define V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (V4L2_CID_MPEG_BASE+250)
+#define V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION (V4L2_CID_MPEG_BASE+251)
+
+/* enum v4l2_ctrl_type type values */
+#define V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS 0x0103
+#defineV4L2_CTRL_TYPE_MPEG2_QUANTIZATION 0x0104
+
+#define V4L2_MPEG2_PICTURE_CODING_TYPE_I   1
+#define V4L2_MPEG2_PICTURE_CODING_TYPE_P   2
+#define V4L2_MPEG2_PICTURE_CODING_TYPE_B   3
+#define V4L2_MPEG2_PICTURE_CODING_TYPE_D   4
+
+struct v4l2_mpeg2_sequence {
+   /* ISO/IEC 13818-2, ITU-T Rec. H.262: Sequence header */
+   __u16   horizontal_size;
+   __u16   vertical_size;
+   __u32   vbv_buffer_size;
+
+   /* ISO/IEC 13818-2, ITU-T Rec. H.262: Sequence extension */
+   __u8profile_and_level_indication;
+   __u8progressive_sequence;
+   __u8chroma_format;
+   __u8pad;
+};
+
+struct v4l2_mpeg2_picture {
+   /* ISO/IEC 13818-2, ITU-T Rec. H.262: Picture header */
+   __u8picture_coding_type;
+
+   /* ISO/IEC 13818-2, ITU-T Rec. H.262: Picture coding extension */
+   __u8f_code[2][2];
+   __u8intra_dc_precision;
+   __u8picture_structure;
+   __u8top_field_first;
+   __u8frame_pred_frame_dct;
+   __u8concealment_motion_vectors;
+   __u8q_scale_type;
+   __u8intra_vlc_format;
+   __u8alternate_scan;
+   __u8repeat_first_field;
+   __u8progressive_frame;
+   __u8pad;
+};
+
+struct v4l2_ctrl_mpeg2_slice_params {
+   __u32   bit_size;
+   __u32   data_bit_offset;
+
+   struct v4l2_mpeg2_sequence sequence;
+   struct v4l2_mpeg2_picture picture;
+
+   /* ISO/IEC 13818-2, ITU-T Rec. H.262: Slice */
+   __u8quantiser_scale_code;
+
+   __u8backward_ref_index;
+   __u8forward_ref_index;
+   __u8pad;
+};
+
+struct v4l2_ctrl_mpeg2_quantization {
+   /* ISO/IEC 13818-2, ITU-T Rec. H.262: Quant matrix extension */
+   __u8load_intra_quantiser_matrix;
+   __u8load_non_intra_quantiser_matrix;
+   __u8load_chroma_intra_quantiser_matrix;
+   __u8load_chroma_non_intra_quantiser_matrix;
+
+   __u8intra_quantiser_matrix[64];
+   __u8non_intra_quantiser_matrix[64];
+   __u8chroma_intra_quantiser_matrix[64];
+   __u8chroma_non_intra_quantiser_matrix[64];
+};
+
+#endif
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 83ce0593b275..d63cf227b0ab 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -22,6 +22,12 @@
 #include 
 #include 
 
+/*
+ * Include the mpeg2 sta

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

[Sakari Ailus]

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 
---
I hope this covers now everything... I was thinking how to make the option
name itself more worrisome but I couldn't come up with a better language
that would be compact enough. The "(EXPERIMENTAL)" notion is a bit too
worn to be effective. :-I

The patch can and should be reverted once we're entirely happy and
confident with the API.

 drivers/media/Kconfig   | 13 +
 drivers/media/common/videobuf2/videobuf2-v4l2.c |  2 ++
 drivers/media/media-device.c|  2 ++
 drivers/staging/media/sunxi/cedrus/Kconfig  |  1 +
 4 files changed, 18 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..2ef114ce38d0 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -381,7 +381,9 @@ 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)
 {
+#ifndef CONFIG_MEDIA_CONTROLLER_REQUEST_API
if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
+#endif
return -ENOTTY;
 
return media_request_alloc(mdev, alloc_fd);
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
-- 
2.11.0

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

[Hans Verkuil]

On 12/05/18 13:24, Sakari Ailus wrote:
> 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 

> ---
> I hope this covers now everything... I was thinking how to make the option
> name itself more worrisome but I couldn't come up with a better language
> that would be compact enough. The "(EXPERIMENTAL)" notion is a bit too
> worn to be effective. :-I
> 
> The patch can and should be reverted once we're entirely happy and
> confident with the API.
> 
>  drivers/media/Kconfig   | 13 +
>  drivers/media/common/videobuf2/videobuf2-v4l2.c |  2 ++
>  drivers/media/media-device.c|  2 ++
>  drivers/staging/media/sunxi/cedrus/Kconfig  |  1 +
>  4 files changed, 18 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..2ef114ce38d0 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -381,7 +381,9 @@ 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)
>  {
> +#ifndef CONFIG_MEDIA_CONTROLLER_REQUEST_API
>   if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
> +#endif
>   return -ENOTTY;
>  
>   return media_request_alloc(mdev, alloc_fd);
> 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
> 

Re: [PATCH for v4.20 0/2] cedrus: move MPEG controls out of the uAPI

[Paul Kocialkowski]

Hi,

On Wed, 2018-12-05 at 13:09 +0100, hverkuil-ci...@xs4all.nl wrote:
> From: Hans Verkuil 
> 
> The expectation was that the MPEG-2 state controls used by the staging
> cedrus driver were stable, or would only require one final change. However,
> it turns out that more changes are required, and that means that it is not
> such a good idea to have these controls in the public kernel API.
> 
> This patch series moves all the MPEG-2 state control data to a new
> media/mpeg2-ctrls.h header. So none of this is available from the public
> API.
> 
> However, v4l2-ctrls.h includes it for now so the kAPI still knows about it
> allowing the cedrus driver to use it without changes.
> 
> The second patch adds a note to these two controls, mentioning that they
> are likely to change.
> 
> Moving forward, this allows us to take more time in getting the MPEG-2
> (and later H264/5) state controls right.

Thanks a lot for this change, I'm glad we can take time to properly
stabilize these controls!

For the whole series:
Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Regards,
> 
>   Hans
> 
> Hans Verkuil (2):
>   mpeg2-ctrls.h: move MPEG2 state controls to non-public header
>   extended-controls.rst: add note to the MPEG2 state controls
> 
>  .../media/uapi/v4l/extended-controls.rst  | 10 +++
>  drivers/media/v4l2-core/v4l2-ctrls.c  |  4 +-
>  include/media/mpeg2-ctrls.h   | 86 +++
>  include/media/v4l2-ctrls.h|  6 ++
>  include/uapi/linux/v4l2-controls.h| 68 ---
>  include/uapi/linux/videodev2.h|  4 -
>  6 files changed, 104 insertions(+), 74 deletions(-)
>  create mode 100644 include/media/mpeg2-ctrls.h
> 
-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

[GIT FIXES FOR v4.20] cedrus: move control definitions to mpeg2-ctrls.h

[Hans Verkuil]

This API is not stable enough yet to be exposed in the uAPI. Move it
to a kAPI header.

Regards,

Hans

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/hverkuil/media_tree.git tags/br-v4.21q2

for you to fetch changes up to f9a88dc4e8703bfa6a40229806fbb496e4111664:

  extended-controls.rst: add note to the MPEG2 state controls (2018-12-05 
13:59:16 +0100)


Tag branch


Hans Verkuil (2):
  mpeg2-ctrls.h: move MPEG2 state controls to non-public header
  extended-controls.rst: add note to the MPEG2 state controls

 Documentation/media/uapi/v4l/extended-controls.rst | 10 +++
 drivers/media/v4l2-core/v4l2-ctrls.c   |  4 +--
 include/media/mpeg2-ctrls.h| 86 
++
 include/media/v4l2-ctrls.h |  6 
 include/uapi/linux/v4l2-controls.h | 68 
--
 include/uapi/linux/videodev2.h |  4 ---
 6 files changed, 104 insertions(+), 74 deletions(-)
 create mode 100644 include/media/mpeg2-ctrls.h

[PATCH 1/1] ipu3-cio2: Allow probe to succeed if there are no sensors connected

[Sakari Ailus]

The device won't be powered off on systems that have no sensors connected
unless it has a driver bound to it. Allow that to happen even if there are
no sensors connected to cio2.

Signed-off-by: Sakari Ailus 
---
 drivers/media/pci/intel/ipu3/ipu3-cio2.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c 
b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
index 447baaebca448..e281e55cdca4a 100644
--- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
+++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
@@ -1810,7 +1810,8 @@ static int cio2_pci_probe(struct pci_dev *pci_dev,
 
/* Register notifier for subdevices we care */
r = cio2_notifier_init(cio2);
-   if (r)
+   /* Proceed without sensors connected to allow the device to suspend. */
+   if (r && r != -ENODEV)
goto fail_cio2_queue_exit;
 
r = devm_request_irq(&pci_dev->dev, pci_dev->irq, cio2_irq,
-- 
2.11.0

Re: [PATCH 1/1] ipu3-cio2: Allow probe to succeed if there are no sensors connected

[Rajneesh Bhardwaj]

On Wed, Dec 05, 2018 at 04:15:17PM +0200, Sakari Ailus wrote:
> The device won't be powered off on systems that have no sensors connected
> unless it has a driver bound to it. Allow that to happen even if there are
> no sensors connected to cio2.

Thanks for sending this. It helps to put the pci device to suspend which
otherwise remains active after the probe for cio2 fails. I have verified it
on HP Elitebook that has BIOS/DSDT more suitable for Windows.

> 
> Signed-off-by: Sakari Ailus 

Reviewed-and-tested-by: Rajneesh Bhardwaj 

> ---
>  drivers/media/pci/intel/ipu3/ipu3-cio2.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c 
> b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> index 447baaebca448..e281e55cdca4a 100644
> --- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> @@ -1810,7 +1810,8 @@ static int cio2_pci_probe(struct pci_dev *pci_dev,
>  
>   /* Register notifier for subdevices we care */
>   r = cio2_notifier_init(cio2);
> - if (r)
> + /* Proceed without sensors connected to allow the device to suspend. */
> + if (r && r != -ENODEV)
>   goto fail_cio2_queue_exit;
>  
>   r = devm_request_irq(&pci_dev->dev, pci_dev->irq, cio2_irq,
> -- 
> 2.11.0
> 

-- 
Best Regards,
Rajneesh

Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver

[Hans Verkuil]

On 11/30/18 18:34, Ezequiel Garcia wrote:
> Add a mem2mem driver for the VPU available on Rockchip SoCs.
> Currently only JPEG encoding is supported, for RK3399 and RK3288
> platforms.
> 
> Signed-off-by: Ezequiel Garcia 
> ---



> diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c 
> b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
> new file mode 100644
> index ..f2752a0c71c0
> --- /dev/null
> +++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
> @@ -0,0 +1,531 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Rockchip VPU codec driver
> + *
> + * Copyright (C) 2018 Collabora, Ltd.
> + * Copyright 2018 Google LLC.
> + *   Tomasz Figa 
> + *
> + * Based on s5p-mfc driver by Samsung Electronics Co., Ltd.
> + * Copyright (C) 2011 Samsung Electronics Co., Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "rockchip_vpu_common.h"
> +#include "rockchip_vpu.h"
> +#include "rockchip_vpu_hw.h"
> +
> +#define DRIVER_NAME "rockchip-vpu"
> +
> +int rockchip_vpu_debug;
> +module_param_named(debug, rockchip_vpu_debug, int, 0644);
> +MODULE_PARM_DESC(debug,
> +  "Debug level - higher value produces more verbose messages");
> +
> +static void rockchip_vpu_job_finish(struct rockchip_vpu_dev *vpu,
> + struct rockchip_vpu_ctx *ctx,
> + unsigned int bytesused,
> + enum vb2_buffer_state result)
> +{
> + struct vb2_v4l2_buffer *src, *dst;
> + size_t avail_size;
> +
> + pm_runtime_mark_last_busy(vpu->dev);
> + pm_runtime_put_autosuspend(vpu->dev);
> + clk_bulk_disable(vpu->variant->num_clocks, vpu->clocks);
> +
> + src = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + dst = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> +
> + if (WARN_ON(!src))
> + return;
> + if (WARN_ON(!dst))
> + return;
> +
> + src->sequence = ctx->sequence_out++;
> + dst->sequence = ctx->sequence_cap++;
> +
> + dst->field = src->field;
> + if (dst->flags & V4L2_BUF_FLAG_TIMECODE)

That should be src->flags

> + dst->timecode = src->timecode;
> + dst->vb2_buf.timestamp = src->vb2_buf.timestamp;
> + dst->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
> + dst->flags |= src->flags & V4L2_BUF_FLAG_TSTAMP_SRC_MASK;

And this should clear and copy V4L2_BUF_FLAG_TIMECODE as well.

> +
> + avail_size = vb2_plane_size(&dst->vb2_buf, 0) -
> +  ctx->vpu_dst_fmt->header_size;
> + if (bytesused <= avail_size) {
> + if (ctx->bounce_buf) {
> + memcpy(vb2_plane_vaddr(&dst->vb2_buf, 0) +
> +ctx->vpu_dst_fmt->header_size,
> +ctx->bounce_buf, bytesused);
> + }
> + dst->vb2_buf.planes[0].bytesused =
> + ctx->vpu_dst_fmt->header_size + bytesused;
> + } else {
> + result = VB2_BUF_STATE_ERROR;
> + }
> +
> + v4l2_m2m_buf_done(src, result);
> + v4l2_m2m_buf_done(dst, result);
> +
> + v4l2_m2m_job_finish(vpu->m2m_dev, ctx->fh.m2m_ctx);
> +}
> +
> +void rockchip_vpu_irq_done(struct rockchip_vpu_dev *vpu,
> +unsigned int bytesused,
> +enum vb2_buffer_state result)
> +{
> + struct rockchip_vpu_ctx *ctx =
> + v4l2_m2m_get_curr_priv(vpu->m2m_dev);
> +
> + /*
> +  * If cancel_delayed_work returns false
> +  * the timeout expired. The watchdog is running,
> +  * and will take care of finishing the job.
> +  */
> + if (cancel_delayed_work(&vpu->watchdog_work))
> + rockchip_vpu_job_finish(vpu, ctx, bytesused, result);
> +}
> +
> +void rockchip_vpu_watchdog(struct work_struct *work)
> +{
> + struct rockchip_vpu_dev *vpu;
> + struct rockchip_vpu_ctx *ctx;
> +
> + vpu = container_of(to_delayed_work(work),
> +struct rockchip_vpu_dev, watchdog_work);
> + ctx = v4l2_m2m_get_curr_priv(vpu->m2m_dev);
> + if (ctx) {
> + vpu_err("frame processing timed out!\n");
> + ctx->codec_ops->reset(ctx);
> + rockchip_vpu_job_finish(vpu, ctx, 0, VB2_BUF_STATE_ERROR);
> + }
> +}
> +
> +static void device_run(void *priv)
> +{
> + struct rockchip_vpu_ctx *ctx = priv;
> + int ret;
> +
> + ret = clk_bulk_enable(ctx->dev->variant->num_clocks, ctx->dev->clocks);
> + if (ret)
> + goto err_cancel_job;
> + ret = pm_runtime_get_sync(ctx->dev->dev);
> + if (ret < 0)
> + goto err_cancel_job;
> +
> + ctx->codec_ops->run(ctx);
> + return;
> +
> +err_cancel_job:
> + rockchip_vpu_job_finish(ctx->dev, ctx, 0, VB2_BUF_STATE_ERROR);
> +}
> +
> +static struct v4l2_m2m_ops vpu_m2m_ops = {
> + .device_run 

Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver

[Ezequiel Garcia]

On Wed, 2018-12-05 at 16:01 +0100, Hans Verkuil wrote:
> Unless something unexpected happens, then v12 should be the final
> version and I'll make a pull request for it. Note that it will
> probably won't make 4.20, unless you manage to do it within the next
> hour :-)

Challenge accepted!

[ragnatech:media-tree 198/228] arch/arm/include/asm/irq.h:35:50: error: unknown type name 'cpumask_t'

[kbuild test robot]

tree:   git://git.ragnatech.se/linux media-tree
head:   da2c94c8f9739e4099ea3cfefc208fc721b22a9c
commit: b6973637c4cc842c1aa7d6c848781b4bdeb4415b [198/228] media: ddbridge: 
remove another duplicate of io.h and sort includes
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b6973637c4cc842c1aa7d6c848781b4bdeb4415b
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from drivers/media/pci/ddbridge/ddbridge.h:22:0,
from drivers/media/pci/ddbridge/ddbridge-hw.c:19:
>> arch/arm/include/asm/irq.h:35:50: error: unknown type name 'cpumask_t'
extern void arch_trigger_cpumask_backtrace(const cpumask_t *mask,
 ^
>> arch/arm/include/asm/irq.h:36:9: error: unknown type name 'bool'; did you 
>> mean '_Bool'?
bool exclude_self);
^~~~
_Bool

vim +/cpumask_t +35 arch/arm/include/asm/irq.h

446616db Russell King  2008-09-06  33  
96f0e003 Russell King  2014-09-03  34  #ifdef CONFIG_SMP
9a01c3ed Chris Metcalf 2016-10-07 @35  extern void 
arch_trigger_cpumask_backtrace(const cpumask_t *mask,
9a01c3ed Chris Metcalf 2016-10-07 @36  bool 
exclude_self);
9a01c3ed Chris Metcalf 2016-10-07  37  #define arch_trigger_cpumask_backtrace 
arch_trigger_cpumask_backtrace
96f0e003 Russell King  2014-09-03  38  #endif
96f0e003 Russell King  2014-09-03  39  

:: The code at line 35 was first introduced by commit
:: 9a01c3ed5cdb35d9004eb92510ee6ea11b4a5f16 nmi_backtrace: add more 
trigger_*_cpu_backtrace() methods

:: TO: Chris Metcalf 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver

[Ezequiel Garcia]

Hi Hans,

On Wed, 2018-12-05 at 16:01 +0100, Hans Verkuil wrote:
> On 11/30/18 18:34, Ezequiel Garcia wrote:
> > Add a mem2mem driver for the VPU available on Rockchip SoCs.
> > Currently only JPEG encoding is supported, for RK3399 and RK3288
> > platforms.
> > 
> > Signed-off-by: Ezequiel Garcia 
> > ---
> 
> 
> 
[..]
> 
> 
> Unless something unexpected happens, then v12 should be the final
> version and I'll make a pull request for it. Note that it will
> probably won't make 4.20, unless you manage to do it within the next
> hour :-)
> 

Thanks for the review. Here are the changes that will be on v12.

Besides your feedback, I found a missing parenthesis issue,
which seems to have sneaked into v11! Apparently, v11 had
last minute changes and I failed to run v4l2-compliance.  

diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c 
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
index f2752a0c71c0..962412c79b91 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
@@ -60,11 +60,13 @@ static void rockchip_vpu_job_finish(struct rockchip_vpu_dev 
*vpu,
dst->sequence = ctx->sequence_cap++;
 
dst->field = src->field;
-   if (dst->flags & V4L2_BUF_FLAG_TIMECODE)
+   if (src->flags & V4L2_BUF_FLAG_TIMECODE)
dst->timecode = src->timecode;
dst->vb2_buf.timestamp = src->vb2_buf.timestamp;
-   dst->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
-   dst->flags |= src->flags & V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
+   dst->flags &= ~(V4L2_BUF_FLAG_TSTAMP_SRC_MASK |
+   V4L2_BUF_FLAG_TIMECODE);
+   dst->flags |= src->flags & (V4L2_BUF_FLAG_TSTAMP_SRC_MASK |
+   V4L2_BUF_FLAG_TIMECODE);
 
avail_size = vb2_plane_size(&dst->vb2_buf, 0) -
 ctx->vpu_dst_fmt->header_size;
@@ -151,6 +153,12 @@ enc_queue_init(void *priv, struct vb2_queue *src_vq, 
struct vb2_queue *dst_vq)
src_vq->drv_priv = ctx;
src_vq->ops = &rockchip_vpu_enc_queue_ops;
src_vq->mem_ops = &vb2_dma_contig_memops;
+
+   /*
+* Driver does mostly sequential access, so sacrifice TLB efficiency
+* for faster allocation. Also, no CPU access on the source queue,
+* so no kernel mapping needed.
+*/
src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES |
DMA_ATTR_NO_KERNEL_MAPPING;
src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
@@ -197,8 +205,6 @@ static int rockchip_vpu_s_ctrl(struct v4l2_ctrl *ctrl)
ctx->jpeg_quality = ctrl->val;
break;
default:
-   vpu_err("Invalid control id = %d, val = %d\n",
-   ctrl->id, ctrl->val);
return -EINVAL;
}
 
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c 
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
index 6aadd194e999..3dbd15d5fabe 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
@@ -142,7 +142,7 @@ rockchip_vpu_get_default_fmt(struct rockchip_vpu_ctx *ctx, 
bool bitstream)
formats = dev->variant->enc_fmts;
num_fmts = dev->variant->num_enc_fmts;
for (i = 0; i < num_fmts; i++) {
-   if (bitstream == formats[i].codec_mode != RK_VPU_MODE_NONE)
+   if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
return &formats[i];
}
return NULL;

[PATCH v12] media: add Rockchip VPU JPEG encoder driver

[Ezequiel Garcia]

Add a mem2mem driver for the VPU available on Rockchip SoCs.
Currently only JPEG encoding is supported, for RK3399 and RK3288
platforms.

Signed-off-by: Ezequiel Garcia 
---
Changes from v11:
  * Fix buffer timecode
  * Add a comment explaining dma attributes
  * Fix wrong parenthesis
  * Remove unneeded error message

 MAINTAINERS   |   7 +
 drivers/staging/media/Kconfig |   2 +
 drivers/staging/media/Makefile|   1 +
 drivers/staging/media/rockchip/vpu/Kconfig|  13 +
 drivers/staging/media/rockchip/vpu/Makefile   |  10 +
 drivers/staging/media/rockchip/vpu/TODO   |  13 +
 .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++
 .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 130 
 .../media/rockchip/vpu/rk3288_vpu_regs.h  | 442 
 .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++
 .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 164 +
 .../media/rockchip/vpu/rk3399_vpu_regs.h  | 600 
 .../staging/media/rockchip/vpu/rockchip_vpu.h | 232 ++
 .../media/rockchip/vpu/rockchip_vpu_common.h  |  29 +
 .../media/rockchip/vpu/rockchip_vpu_drv.c | 537 ++
 .../media/rockchip/vpu/rockchip_vpu_enc.c | 676 ++
 .../media/rockchip/vpu/rockchip_vpu_hw.h  |  58 ++
 .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 290 
 .../media/rockchip/vpu/rockchip_vpu_jpeg.h|  14 +
 19 files changed, 3454 insertions(+)
 create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig
 create mode 100644 drivers/staging/media/rockchip/vpu/Makefile
 create mode 100644 drivers/staging/media/rockchip/vpu/TODO
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 2894fb9893a6..a86a0cd90514 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12748,6 +12748,13 @@ S: Maintained
 F: drivers/media/platform/rockchip/rga/
 F: Documentation/devicetree/bindings/media/rockchip-rga.txt
 
+ROCKCHIP VPU CODEC DRIVER
+M: Ezequiel Garcia 
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/staging/media/platform/rockchip/vpu/
+F: Documentation/devicetree/bindings/media/rockchip-vpu.txt
+
 ROCKER DRIVER
 M: Jiri Pirko 
 L: net...@vger.kernel.org
diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index b3620a8f2d9f..c6f3404dea43 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig"
 
 source "drivers/staging/media/omap4iss/Kconfig"
 
+source "drivers/staging/media/rockchip/vpu/Kconfig"
+
 source "drivers/staging/media/sunxi/Kconfig"
 
 source "drivers/staging/media/tegra-vde/Kconfig"
diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
index 42948f805548..43c7bee1fc8c 100644
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4)   += omap4iss/
 obj-$(CONFIG_VIDEO_SUNXI)  += sunxi/
 obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/
 obj-$(CONFIG_VIDEO_ZORAN)  += zoran/
+obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/
diff --git a/drivers/staging/media/rockchip/vpu/Kconfig 
b/drivers/staging/media/rockchip/vpu/Kconfig
new file mode 100644
index ..9a6fc1378242
--- /dev/null
+++ b/drivers/staging/media/rockchip/vpu/Kconfig
@@ -0,0 +1,13 @@
+config VIDEO_ROCKCHIP_VPU
+   tristate "Rockchip VPU driver"
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
+   depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
+   select VIDEOBUF2_DMA_CONTIG
+   select VIDEOBUF2_VMALLOC
+   select V4L2_MEM2MEM_DEV
+   default n
+   help
+ Support for the Video Processing Unit present on Rockchip SoC,
+ which accelerates video and image encoding and decoding.
+ To compile this driver as a module, choose M here: the module
+ will be called rockchip-vpu.
diff --git a/drivers/staging/media/rockchip/vpu/Makefile 
b/drivers/staging/media/rockchip/vpu/Makefil

[PATCH v3 2/2] media: imx: ask source subdevice for number of active data lanes

[Philipp Zabel]

Temporarily use g_mbus_config() to determine the number of active data
lanes used by the transmitter. If g_mbus_config is not supported or
does not return the number of active lines, default to using all
connected data lines.

Signed-off-by: Philipp Zabel 
Acked-by: Steve Longerbeam 
---
Changes since v2 [1]:
 - Rebased onto media/master

[1] https://patchwork.kernel.org/patch/9964151/
---
 drivers/staging/media/imx/imx6-mipi-csi2.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c 
b/drivers/staging/media/imx/imx6-mipi-csi2.c
index 6a1cee55a49b..ae91f0d138f3 100644
--- a/drivers/staging/media/imx/imx6-mipi-csi2.c
+++ b/drivers/staging/media/imx/imx6-mipi-csi2.c
@@ -135,10 +135,8 @@ static void csi2_enable(struct csi2_dev *csi2, bool enable)
}
 }
 
-static void csi2_set_lanes(struct csi2_dev *csi2)
+static void csi2_set_lanes(struct csi2_dev *csi2, int lanes)
 {
-   int lanes = csi2->bus.num_data_lanes;
-
writel(lanes - 1, csi2->base + CSI2_N_LANES);
 }
 
@@ -301,6 +299,9 @@ static void csi2ipu_gasket_init(struct csi2_dev *csi2)
 
 static int csi2_start(struct csi2_dev *csi2)
 {
+   const u32 mask = V4L2_MBUS_CSI2_LANE_MASK;
+   struct v4l2_mbus_config cfg;
+   int lanes = 0;
int ret;
 
ret = clk_prepare_enable(csi2->pix_clk);
@@ -316,7 +317,10 @@ static int csi2_start(struct csi2_dev *csi2)
goto err_disable_clk;
 
/* Step 4 */
-   csi2_set_lanes(csi2);
+   ret = v4l2_subdev_call(csi2->src_sd, video, g_mbus_config, &cfg);
+   if (ret == 0)
+   lanes = (cfg.flags & mask) >> __ffs(mask);
+   csi2_set_lanes(csi2, lanes ?: csi2->bus.num_data_lanes);
csi2_enable(csi2, true);
 
/* Step 5 */
-- 
2.19.1

[PATCH v3 1/2] media: tc358743: fix connected/active CSI-2 lane reporting

[Philipp Zabel]

g_mbus_config was supposed to indicate all supported lane numbers, not
only the number of those currently in active use. Since the TC358743
can dynamically reduce the number of active lanes if the required
bandwidth allows for it, report all lane numbers up to the connected
number of lanes as supported in pdata mode.
In device tree mode, do not report lane count and clock mode at all, as
the receiver driver can determine these from the device tree.

To allow communicating the number of currently active lanes, add a new
bitfield to the v4l2_mbus_config flags. This is a temporary fix, to be
used only until a better solution is found.

Signed-off-by: Philipp Zabel 
Tested-by: Dave Stevenson 
---
Changes since v2 [1]:
 - Rebased onto media/master

[1] https://patchwork.kernel.org/patch/9964141/
---
 drivers/media/i2c/tc358743.c  | 30 --
 include/media/v4l2-mediabus.h |  9 +
 2 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index 00dc930e049f..b1e1ed4d9e0c 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -1606,28 +1606,29 @@ static int tc358743_g_mbus_config(struct v4l2_subdev 
*sd,
 struct v4l2_mbus_config *cfg)
 {
struct tc358743_state *state = to_state(sd);
+   const u32 mask = V4L2_MBUS_CSI2_LANE_MASK;
+
+   if (state->csi_lanes_in_use > state->bus.num_data_lanes)
+   return -EINVAL;
 
cfg->type = V4L2_MBUS_CSI2_DPHY;
+   cfg->flags = (state->csi_lanes_in_use << __ffs(mask)) & mask;
 
-   /* Support for non-continuous CSI-2 clock is missing in the driver */
-   cfg->flags = V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
+   /* In DT mode, only report the number of active lanes */
+   if (sd->dev->of_node)
+   return 0;
 
-   switch (state->csi_lanes_in_use) {
-   case 1:
+   /* Support for non-continuous CSI-2 clock is missing in pdata mode */
+   cfg->flags |= V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
+
+   if (state->bus.num_data_lanes > 0)
cfg->flags |= V4L2_MBUS_CSI2_1_LANE;
-   break;
-   case 2:
+   if (state->bus.num_data_lanes > 1)
cfg->flags |= V4L2_MBUS_CSI2_2_LANE;
-   break;
-   case 3:
+   if (state->bus.num_data_lanes > 2)
cfg->flags |= V4L2_MBUS_CSI2_3_LANE;
-   break;
-   case 4:
+   if (state->bus.num_data_lanes > 3)
cfg->flags |= V4L2_MBUS_CSI2_4_LANE;
-   break;
-   default:
-   return -EINVAL;
-   }
 
return 0;
 }
@@ -2053,6 +2054,7 @@ static int tc358743_probe(struct i2c_client *client,
if (pdata) {
state->pdata = *pdata;
state->bus.flags = V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
+   state->bus.num_data_lanes = 4;
} else {
err = tc358743_probe_of(state);
if (err == -ENODEV)
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 66cb746ceeb5..e127e3d1740e 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -71,6 +71,15 @@
 V4L2_MBUS_CSI2_CHANNEL_2 | \
 V4L2_MBUS_CSI2_CHANNEL_3)
 
+/*
+ * Number of lanes in use, 0 == use all available lanes (default)
+ *
+ * This is a temporary fix for devices that need to reduce the number of active
+ * lanes for certain modes, until g_mbus_config() can be replaced with a better
+ * solution.
+ */
+#define V4L2_MBUS_CSI2_LANE_MASK(0xf << 10)
+
 /**
  * enum v4l2_mbus_type - media bus type
  * @V4L2_MBUS_UNKNOWN: unknown bus type, no V4L2 mediabus configuration
-- 
2.19.1

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

[Hans Verkuil]

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

 MAINTAINERS |   7 +
 drivers/staging/media/Kconfig   |   2 +
 drivers/staging/media/Makefile  |   1 +
 drivers/staging/media/rockchip/vpu/Kconfig  |  13 +
 drivers/staging/media/rockchip/vpu/Makefile |  10 +
 drivers/staging/media/rockchip/vpu/TODO |  13 +
 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c  | 118 +++
 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 130 
 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h| 442 
++
 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c  | 118 +++
 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 164 ++
 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h| 600 
+++
 drivers/staging/media/rockchip/vpu/rockchip_vpu.h   | 232 
++
 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h|  29 ++
 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c   | 537 
+++
 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c   | 676 

 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h|  58 
 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c  | 290 
+
 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h  |  14 +
 19 files changed, 3454 insertions(+)
 create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig
 create mode 100644 drivers/staging/media/rockchip/vpu/Makefile
 create mode 100644 drivers/staging/media/rockchip/vpu/TODO
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h

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

[Sakari Ailus]

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

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: [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(&jpeg_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(&jpeg_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 = &rk3399_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 = &rk3288_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: [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(&jpeg_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(&jpeg_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 = &rk3399_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 = &rk3288_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

[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(&jpeg_ctx, 0),
-   rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 1));
+  rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
0),
+  rockchip_vpu_jpeg_get_qtable(&jpeg_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(&jpeg_ctx, 0),
-   rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 1));
+  rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
0),
+  rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
1));
 
reg = VEPU_REG_OUTPUT_SWAP32
| VEPU_REG_OUTPUT_SWAP16
-- 
2.19.1

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

[Hans Verkuil]

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(&jpeg_ctx, 0),
> - rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 1));
> +rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
> 0),
> +rockchip_vpu_jpeg_get_qtable(&jpeg_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.

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(&jpeg_ctx, 0),
> - rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 1));
> +rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
> 0),
> +rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
> 1));
>  
>   reg = VEPU_REG_OUTPUT_SWAP32
>   | VEPU_REG_OUTPUT_SWAP16
> 

Re: [PATCH v5] media: imx: add mem2mem device

[Hans Verkuil]

On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
> Hi Hans, Philipp,
> 
> One comment on my side...
> 
> On 12/3/18 7:21 AM, Hans Verkuil wrote:
>> 
>>> +void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
>>> +{
>>> +   struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
>>> +   struct video_device *vfd = priv->vdev.vfd;
>>> +
>>> +   mutex_lock(&priv->mutex);
>>> +
>>> +   if (video_is_registered(vfd)) {
>>> +   video_unregister_device(vfd);
>>> +   media_entity_cleanup(&vfd->entity);
>> Is this needed?
>>
>> If this is to be part of the media controller, then I expect to see a call
>> to v4l2_m2m_register_media_controller() somewhere.
>>
> 
> Yes, I agree there should be a call to 
> v4l2_m2m_register_media_controller(). This driver does not connect with 
> any of the imx-media entities, but calling it will at least make the 
> mem2mem output/capture device entities (and processing entity) visible 
> in the media graph.
> 
> Philipp, can you pick/squash the following from my media-tree github fork?
> 
> 6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
> d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem 
> device")
> 6787a50cdc ("media: imx: mem2mem: Register with media control")
> 
> Steve
> 

Why is this driver part of the imx driver? Since it doesn't connect with
any of the imx-media entities, doesn't that mean that this is really a
stand-alone driver?

Regards,

Hans

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 VIDIOC_

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

[PATCH v2 1/2] media: lmedm04: Add missing usb_free_urb to free interrupt urb.

[Malcolm Priestley]

The interrupt urb is killed but never freed add the function

Signed-off-by: Malcolm Priestley 
---
v2 avoiding stale pointer in usb_free_coherent as per sean

 drivers/media/usb/dvb-usb-v2/lmedm04.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c 
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index e9b149a26ce5..cba782261a6f 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -1229,6 +1229,7 @@ static void lme2510_exit(struct dvb_usb_device *d)
usb_kill_urb(st->lme_urb);
usb_free_coherent(d->udev, 128, st->buffer,
  st->lme_urb->transfer_dma);
+   usb_free_urb(st->lme_urb);
info("Interrupt Service Stopped");
}
 }
-- 
2.19.1

[PATCH v2 2/2] media: lmedm04: Move interrupt buffer to priv buffer.

[Malcolm Priestley]

Interrupt is always present throughout life time of driver and
there is no dma element move this buffer to private area of driver.

Signed-off-by: Malcolm Priestley 
---
v2 removed the need for DMA transfer flags as per Sean 

 drivers/media/usb/dvb-usb-v2/lmedm04.c | 28 +-
 1 file changed, 9 insertions(+), 19 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c 
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index cba782261a6f..602013cf3e69 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -134,7 +134,7 @@ struct lme2510_state {
u8 stream_on;
u8 pid_size;
u8 pid_off;
-   void *buffer;
+   u8 int_buffer[128];
struct urb *lme_urb;
u8 usb_buffer[64];
/* Frontend original calls */
@@ -388,20 +388,14 @@ static int lme2510_int_read(struct dvb_usb_adapter *adap)
if (lme_int->lme_urb == NULL)
return -ENOMEM;
 
-   lme_int->buffer = usb_alloc_coherent(d->udev, 128, GFP_ATOMIC,
-   &lme_int->lme_urb->transfer_dma);
-
-   if (lme_int->buffer == NULL)
-   return -ENOMEM;
-
usb_fill_int_urb(lme_int->lme_urb,
-   d->udev,
-   usb_rcvintpipe(d->udev, 0xa),
-   lme_int->buffer,
-   128,
-   lme2510_int_response,
-   adap,
-   8);
+d->udev,
+usb_rcvintpipe(d->udev, 0xa),
+lme_int->int_buffer,
+sizeof(lme_int->int_buffer),
+lme2510_int_response,
+adap,
+8);
 
/* Quirk of pipe reporting PIPE_BULK but behaves as interrupt */
ep = usb_pipe_endpoint(d->udev, lme_int->lme_urb->pipe);
@@ -409,8 +403,6 @@ static int lme2510_int_read(struct dvb_usb_adapter *adap)
if (usb_endpoint_type(&ep->desc) == USB_ENDPOINT_XFER_BULK)
lme_int->lme_urb->pipe = usb_rcvbulkpipe(d->udev, 0xa),
 
-   lme_int->lme_urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
-
usb_submit_urb(lme_int->lme_urb, GFP_ATOMIC);
info("INT Interrupt Service Started");
 
@@ -1225,10 +1217,8 @@ static void lme2510_exit(struct dvb_usb_device *d)
lme2510_kill_urb(&adap->stream);
}
 
-   if (st->lme_urb != NULL) {
+   if (st->lme_urb) {
usb_kill_urb(st->lme_urb);
-   usb_free_coherent(d->udev, 128, st->buffer,
- st->lme_urb->transfer_dma);
usb_free_urb(st->lme_urb);
info("Interrupt Service Stopped");
}
-- 
2.19.1

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(&jpeg_ctx, 0),
> > -   rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 1));
> > +  rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
> > 0),
> > +  rockchip_vpu_jpeg_get_qtable(&jpeg_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(&jpeg_ctx, 0),
> > -   rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 1));
> > +  rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
> > 0),
> > +  rockchip_vpu_jpeg_get_qtable(&jpeg_ctx, 
> > 1));
> >  
> > reg = VEPU_REG_OUTPUT_SWAP32
> > | VEPU_REG_OUTPUT_SWAP16
> >   
> 



Thanks,
Mauro

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

[Ezequiel Garcia]

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(&jpeg_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(&jpeg_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 = &rk3399_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 = &rk3288_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.

Thanks!
Ezequiel

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(&jpeg_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(&jpeg_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 = 
> > > &rk3399_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 = 
> > > &rk3288_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 v5] media: imx: add mem2mem device

[Steve Longerbeam]

On 12/5/18 10:50 AM, Hans Verkuil wrote:

On 12/05/2018 02:20 AM, Steve Longerbeam wrote:

Hi Hans, Philipp,

One comment on my side...

On 12/3/18 7:21 AM, Hans Verkuil wrote:



+void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
+{
+   struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
+   struct video_device *vfd = priv->vdev.vfd;
+
+   mutex_lock(&priv->mutex);
+
+   if (video_is_registered(vfd)) {
+   video_unregister_device(vfd);
+   media_entity_cleanup(&vfd->entity);

Is this needed?

If this is to be part of the media controller, then I expect to see a call
to v4l2_m2m_register_media_controller() somewhere.


Yes, I agree there should be a call to
v4l2_m2m_register_media_controller(). This driver does not connect with
any of the imx-media entities, but calling it will at least make the
mem2mem output/capture device entities (and processing entity) visible
in the media graph.

Philipp, can you pick/squash the following from my media-tree github fork?

6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
device")
6787a50cdc ("media: imx: mem2mem: Register with media control")

Steve


Why is this driver part of the imx driver? Since it doesn't connect with
any of the imx-media entities, doesn't that mean that this is really a
stand-alone driver?


It is basically a stand-alone m2m driver, but it makes use of some 
imx-media utility functions like imx_media_enum_format(). Also making it 
a true stand-alone driver would require creating a second /dev/mediaN 
device.


Steve

[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(&luma_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
-- 
2.19.1

[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(&luma_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(&luma_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 = &ctx->dst_fmt;
break;
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
-   vpu_fmt = ctx->vpu_src_fmt;
pixfmt = &ctx->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_buffer(vb);
   

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Thu Dec  6 05:00:13 CET 2018
media-tree git hash:3c28b91380dd1183347d32d87d820818031ebecf
media_build git hash:   4b9237c73e29ea969f6a7b3d00030e14be50
v4l-utils git hash: 9f0354c3320f3cc62983f726bfed66e1d0c21f83
edid-decode git hash:   5eeb151a748788666534d6ea3da07f90400d24c2
gcc version:i686-linux-gcc (GCC) 8.2.0
sparse version: 0.5.2
smatch version: 0.5.1
host hardware:  x86_64
host os:4.18.0-2-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: OK
linux-3.10.108-i686: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.57-i686: ERRORS
linux-3.16.57-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.123-i686: ERRORS
linux-3.18.123-x86_64: ERRORS
linux-3.19.8-i686: ERRORS
linux-3.19.8-x86_64: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.52-i686: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.159-i686: ERRORS
linux-4.4.159-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.131-i686: ERRORS
linux-4.9.131-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.74-i686: ERRORS
linux-4.14.74-x86_64: ERRORS
linux-4.15.18-i686: OK
linux-4.15.18-x86_64: OK
linux-4.16.18-i686: OK
linux-4.16.18-x86_64: OK
linux-4.17.19-i686: OK
linux-4.17.19-x86_64: OK
linux-4.18.12-i686: OK
linux-4.18.12-x86_64: OK
linux-4.19.1-i686: OK
linux-4.19.1-x86_64: OK
linux-4.20-rc1-i686: OK
linux-4.20-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

[PATCH 1/1] media: venus: core: Set dma maximum segment size

[Vivek Gautam]

Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:

[  460.308650] [ cut here ]
[  460.313490] qcom-venus aa0.video-codec: DMA-API: mapping sg segment 
longer than device claims to support [len=4194304] [max=65536]
[  460.326017] WARNING: CPU: 3 PID: 3555 at src/kernel/dma/debug.c:1301 
debug_dma_map_sg+0x174/0x254
[  460.33] Modules linked in: venus_dec venus_enc videobuf2_dma_sg 
videobuf2_memops hci_uart btqca bluetooth venus_core v4l2_mem2mem 
videobuf2_v4l2 videobuf2_common ath10k_snoc ath10k_core ath lzo lzo_compress 
zramjoydev
[  460.375811] CPU: 3 PID: 3555 Comm: V4L2DecoderThre Tainted: GW   
  4.19.1 #82
[  460.384223] Hardware name: Google Cheza (rev1) (DT)
[  460.389251] pstate: 6049 (nZCv daif +PAN -UAO)
[  460.394191] pc : debug_dma_map_sg+0x174/0x254
[  460.398680] lr : debug_dma_map_sg+0x174/0x254
[  460.403162] sp : ff80200c37d0
[  460.406583] x29: ff80200c3830 x28: 0001
[  460.412056] x27:  x26: ffc0f785ea80
[  460.417532] x25:  x24: ffc0f4ea1290
[  460.423001] x23: ffc09e700300 x22: ffc0f4ea1290
[  460.428470] x21: ff8009037000 x20: 0001
[  460.433936] x19: ff80091b x18: 
[  460.439411] x17:  x16: f251
[  460.444885] x15: 0006 x14: 0720072007200720
[  460.450354] x13: ff800af536e0 x12: 
[  460.455822] x11:  x10: 
[  460.461288] x9 : 537944d9c6c48d00 x8 : 537944d9c6c48d00
[  460.466758] x7 :  x6 : ffc0f8d98f80
[  460.472230] x5 :  x4 : 
[  460.477703] x3 : 008a x2 : ffc0fdb13948
[  460.483170] x1 : ffc0fdb0b0b0 x0 : 007a
[  460.488640] Call trace:
[  460.491165]  debug_dma_map_sg+0x174/0x254
[  460.495307]  vb2_dma_sg_alloc+0x260/0x2dc [videobuf2_dma_sg]
[  460.501150]  __vb2_queue_alloc+0x164/0x374 [videobuf2_common]
[  460.507076]  vb2_core_reqbufs+0xfc/0x23c [videobuf2_common]
[  460.512815]  vb2_reqbufs+0x44/0x5c [videobuf2_v4l2]
[  460.517853]  v4l2_m2m_reqbufs+0x44/0x78 [v4l2_mem2mem]
[  460.523144]  v4l2_m2m_ioctl_reqbufs+0x1c/0x28 [v4l2_mem2mem]
[  460.528976]  v4l_reqbufs+0x30/0x40
[  460.532480]  __video_do_ioctl+0x36c/0x454
[  460.536610]  video_usercopy+0x25c/0x51c
[  460.540572]  video_ioctl2+0x38/0x48
[  460.544176]  v4l2_ioctl+0x60/0x74
[  460.547602]  do_video_ioctl+0x948/0x3520
[  460.551648]  v4l2_compat_ioctl32+0x60/0x98
[  460.555872]  __arm64_compat_sys_ioctl+0x134/0x20c
[  460.560718]  el0_svc_common+0x9c/0xe4
[  460.564498]  el0_svc_compat_handler+0x2c/0x38
[  460.568982]  el0_svc_compat+0x8/0x18
[  460.572672] ---[ end trace ce209b87b2f3af88 ]---

>From above warning one would deduce that the sg segment will overflow
the device's capacity. In reality, the hardware can accommodate larger
sg segments.
So, initialize the max segment size properly to weed out this warning.

Based on a similar patch sent by Sean Paul for mdss:
https://patchwork.kernel.org/patch/10671457/

Signed-off-by: Vivek Gautam 
---
 drivers/media/platform/qcom/venus/core.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/core.c 
b/drivers/media/platform/qcom/venus/core.c
index bb6add9d340e..5b8350e87e75 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -264,6 +264,14 @@ static int venus_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   if (!dev->dma_parms) {
+   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
+ GFP_KERNEL);
+   if (!dev->dma_parms)
+   return -ENOMEM;
+   }
+   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
+
INIT_LIST_HEAD(&core->instances);
mutex_init(&core->lock);
INIT_DELAYED_WORK(&core->work, venus_sys_error_handler);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v2 02/15] ARM: dts: sun8i: a33: Remove unnecessary reserved memory node

[Paul Kocialkowski]

While we believed that the memory for the video engine had to be kept
in the first 256 MiBs of DRAM, this is no longer true starting with the
A33 and any address can be mapped.

As a result, remove the reserved memory node and let the kernel allocate
the CMA pool wherever it sees fit.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-a33.dtsi | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index c2c10cd4a210..9ac4fae6c10d 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -186,21 +186,6 @@
};
};
 
-   reserved-memory {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
-   default-pool {
-   compatible = "shared-dma-pool";
-   size = <0x600>;
-   alloc-ranges = <0x4a00 0x600>;
-   reusable;
-   linux,cma-default;
-   };
-   };
-
sound: sound {
compatible = "simple-audio-card";
simple-audio-card,name = "sun8i-a33-audio";
-- 
2.19.2

[PATCH v2 15/15] arm64: dts: allwinner: a64: Add Video Engine node

[Paul Kocialkowski]

This adds the Video Engine node for the A64. Since it can map the whole
DRAM range, there is no particular need for a reserved memory node
(unlike platforms preceding the A33).

Signed-off-by: Paul Kocialkowski 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 8557d52c7c99..8d024c10d7cb 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -397,6 +397,17 @@
};
};
 
+   video-codec@1c0e000 {
+   compatible = "allwinner,sun50i-h5-video-engine";
+   reg = <0x01c0e000 0x1000>;
+   clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
+<&ccu CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+   resets = <&ccu RST_BUS_VE>;
+   interrupts = ;
+   allwinner,sram = <&ve_sram 1>;
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun50i-a64-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.19.2

[PATCH v2 11/15] dt-bindings: media: cedrus: Add compatibles for the A64 and H5

[Paul Kocialkowski]

This introduces two new compatibles for the cedrus driver, for the
A64 and H5 platforms.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/media/cedrus.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/cedrus.txt 
b/Documentation/devicetree/bindings/media/cedrus.txt
index 33833a43fff8..bce0705df953 100644
--- a/Documentation/devicetree/bindings/media/cedrus.txt
+++ b/Documentation/devicetree/bindings/media/cedrus.txt
@@ -11,6 +11,8 @@ Required properties:
- "allwinner,sun7i-a20-video-engine"
- "allwinner,sun8i-a33-video-engine"
- "allwinner,sun8i-h3-video-engine"
+   - "allwinner,sun50i-a64-video-engine"
+   - "allwinner,sun50i-h5-video-engine"
 - reg  : register base and length of VE;
 - clocks   : list of clock specifiers, corresponding to entries in
  the clock-names property;
-- 
2.19.2

[PATCH v2 13/15] media: cedrus: Add device-tree compatible and variant for A64 support

[Paul Kocialkowski]

Add the necessary compatible for supporting the A64 SoC along with a
description of the capabilities of this variant.

Signed-off-by: Paul Kocialkowski 
---
 drivers/staging/media/sunxi/cedrus/cedrus.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index f04b9bf23774..a71d8b659f8d 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -388,6 +388,10 @@ static const struct cedrus_variant sun8i_h3_cedrus_variant 
= {
.capabilities   = CEDRUS_CAPABILITY_UNTILED,
 };
 
+static const struct cedrus_variant sun50i_a64_cedrus_variant = {
+   .capabilities   = CEDRUS_CAPABILITY_UNTILED,
+};
+
 static const struct cedrus_variant sun50i_h5_cedrus_variant = {
.capabilities   = CEDRUS_CAPABILITY_UNTILED,
 };
@@ -413,6 +417,10 @@ static const struct of_device_id cedrus_dt_match[] = {
.compatible = "allwinner,sun8i-h3-video-engine",
.data = &sun8i_h3_cedrus_variant,
},
+   {
+   .compatible = "allwinner,sun50i-a64-video-engine",
+   .data = &sun50i_a64_cedrus_variant,
+   },
{
.compatible = "allwinner,sun50i-h5-video-engine",
.data = &sun50i_h5_cedrus_variant,
-- 
2.19.2

[PATCH v2 12/15] media: cedrus: Add device-tree compatible and variant for H5 support

[Paul Kocialkowski]

Add the necessary compatible for supporting the H5 SoC along with a
description of the capabilities of this variant.

Signed-off-by: Paul Kocialkowski 
---
 drivers/staging/media/sunxi/cedrus/cedrus.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 82558455384a..f04b9bf23774 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -388,6 +388,10 @@ static const struct cedrus_variant sun8i_h3_cedrus_variant 
= {
.capabilities   = CEDRUS_CAPABILITY_UNTILED,
 };
 
+static const struct cedrus_variant sun50i_h5_cedrus_variant = {
+   .capabilities   = CEDRUS_CAPABILITY_UNTILED,
+};
+
 static const struct of_device_id cedrus_dt_match[] = {
{
.compatible = "allwinner,sun4i-a10-video-engine",
@@ -409,6 +413,10 @@ static const struct of_device_id cedrus_dt_match[] = {
.compatible = "allwinner,sun8i-h3-video-engine",
.data = &sun8i_h3_cedrus_variant,
},
+   {
+   .compatible = "allwinner,sun50i-h5-video-engine",
+   .data = &sun50i_h5_cedrus_variant,
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, cedrus_dt_match);
-- 
2.19.2

[PATCH v2 14/15] arm64: dts: allwinner: h5: Add Video Engine node

[Paul Kocialkowski]

This adds the Video Engine node for the H5. Since it can map the whole
DRAM range, there is no particular need for a reserved memory node
(unlike platforms preceding the A33).

Signed-off-by: Paul Kocialkowski 
---
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
index 4e9025431e9f..dc7b5a8ef348 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -116,6 +116,17 @@
};
};
 
+   video-codec@1c0e000 {
+   compatible = "allwinner,sun50i-h5-video-engine";
+   reg = <0x01c0e000 0x1000>;
+   clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
+<&ccu CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+   resets = <&ccu RST_BUS_VE>;
+   interrupts = ;
+   allwinner,sram = <&ve_sram 1>;
+   };
+
mali: gpu@1e8 {
compatible = "allwinner,sun50i-h5-mali", "arm,mali-450";
reg = <0x01e8 0x3>;
-- 
2.19.2

[PATCH v2 09/15] dt-bindings: sram: sunxi: Add compatible for the A64 SRAM C1

[Paul Kocialkowski]

This introduces a new compatible for the A64 SRAM C1 section, that is
compatible with the SRAM C1 section as found on the A10.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/sram/sunxi-sram.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt 
b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
index 5c9a54ad3b53..ab5a70bb9a64 100644
--- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -56,6 +56,7 @@ The valid sections compatible for H3 are:
 
 The valid sections compatible for A64 are:
 - allwinner,sun50i-a64-sram-c
+- allwinner,sun50i-a64-sram-c1, allwinner,sun4i-a10-sram-c1
 
 The valid sections compatible for H5 are:
 - allwinner,sun50i-h5-sram-c1, allwinner,sun4i-a10-sram-c1
-- 
2.19.2

[PATCH v2 08/15] ARM/arm64: sunxi: Move H3/H5 syscon label over to soc-specific nodes

[Paul Kocialkowski]

The EMAC driver requires a syscon node to access the EMAC clock
configuration register (that is part of the system-control register
range and controlled). For this purpose, a dummy syscon node was
introduced to let the driver access the register freely.

Recently, the EMAC driver was tuned to get access to the register when
the SRAM driver is registered (as used on the A64). As a result, it is
no longer necessary to have a dummy syscon node for that purpose.

Now that we have a proper system-control node for both the H3 and H5,
we can get rid of that dummy syscon node and have the EMAC driver use
the node corresponding to the proper SRAM driver (by switching the
syscon label over to each dtsi). This way, we no longer have two
separate nodes for the same register space.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-h3.dtsi  | 2 +-
 arch/arm/boot/dts/sunxi-h3-h5.dtsi   | 6 --
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 2 +-
 3 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index e438e54580e1..a858d91dd4c6 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -120,7 +120,7 @@
};
 
soc {
-   system-control@1c0 {
+   syscon: system-control@1c0 {
compatible = "allwinner,sun8i-h3-system-control";
reg = <0x01c0 0x1000>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 0d9e9eac518c..ed5846982685 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -152,12 +152,6 @@
};
};
 
-   syscon: syscon@1c0 {
-   compatible = "allwinner,sun8i-h3-system-controller",
-   "syscon";
-   reg = <0x01c0 0x1000>;
-   };
-
dma: dma-controller@1c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
index 42bfb560b367..4e9025431e9f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -94,7 +94,7 @@
};
 
soc {
-   system-control@1c0 {
+   syscon: system-control@1c0 {
compatible = "allwinner,sun50i-h5-system-control";
reg = <0x01c0 0x1000>;
#address-cells = <1>;
-- 
2.19.2

[PATCH v2 07/15] arm64: dts: allwinner: h5: Add system-control node with SRAM C1

[Paul Kocialkowski]

Add the H5-specific system control node description to its device-tree
with support for the SRAM C1 section, that will be used by the video
codec node later on.

The CPU-side SRAM address was obtained empirically while the size was
taken from the documentation. They may not be entirely accurate.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 22 
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
index b41dc1aab67d..42bfb560b367 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -94,6 +94,28 @@
};
 
soc {
+   system-control@1c0 {
+   compatible = "allwinner,sun50i-h5-system-control";
+   reg = <0x01c0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   sram_c1: sram@1d0 {
+   compatible = "mmio-sram";
+   reg = <0x00018000 0x1c000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x00018000 0x1c000>;
+
+   ve_sram: sram-section@0 {
+   compatible = 
"allwinner,sun50i-h5-sram-c1",
+
"allwinner,sun4i-a10-sram-c1";
+   reg = <0x00 0x1c000>;
+   };
+   };
+   };
+
mali: gpu@1e8 {
compatible = "allwinner,sun50i-h5-mali", "arm,mali-450";
reg = <0x01e8 0x3>;
-- 
2.19.2

[PATCH v2 10/15] arm64: dts: allwinner: a64: Add support for the SRAM C1 section

[Paul Kocialkowski]

Add the description for the SRAM C1 section to the A64 device-tree.

Since there is no entry for this section in the A64 manual, the base
address and size were only verified to be consistent empirically.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 384c417cb7a2..8557d52c7c99 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -301,6 +301,20 @@
reg = <0x 0x28000>;
};
};
+
+   sram_c1: sram@1d0 {
+   compatible = "mmio-sram";
+   reg = <0x01d0 0x4>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x01d0 0x4>;
+
+   ve_sram: sram-section@0 {
+   compatible = 
"allwinner,sun50i-a64-sram-c1",
+
"allwinner,sun4i-a10-sram-c1";
+   reg = <0x00 0x4>;
+   };
+   };
};
 
dma: dma-controller@1c02000 {
-- 
2.19.2

[PATCH v2 06/15] soc: sunxi: sram: Add support for the H5 SoC system control

[Paul Kocialkowski]

This adds the H5 SoC compatible to the list of device-tree matches for
the SRAM driver. Since the variant is the same as the A64 (that precedes
the H5), the same variant description is used.

Signed-off-by: Paul Kocialkowski 
---
 drivers/soc/sunxi/sunxi_sram.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index fd81a3c0db45..1b0d50f36349 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -383,6 +383,10 @@ static const struct of_device_id sunxi_sram_dt_match[] = {
.compatible = "allwinner,sun50i-a64-system-control",
.data = &sun50i_a64_sramc_variant,
},
+   {
+   .compatible = "allwinner,sun50i-h5-system-control",
+   .data = &sun50i_a64_sramc_variant,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, sunxi_sram_dt_match);
-- 
2.19.2

[PATCH v2 03/15] ARM: dts: sun8i: h3: Remove unnecessary reserved memory node

[Paul Kocialkowski]

Just like on the A33, the video engine on the H3 can map any address in
memory, so there is no particular need to have reserved memory at a fixed
address.

As a result, remove the reserved memory node and let the kernel allocate
the CMA pool wherever it sees fit.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 14 --
 1 file changed, 14 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index dbb7e71b6d69..e438e54580e1 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -119,20 +119,6 @@
 ;
};
 
-   reserved-memory {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   default-pool {
-   compatible = "shared-dma-pool";
-   size = <0x600>;
-   alloc-ranges = <0x4a00 0x600>;
-   reusable;
-   linux,cma-default;
-   };
-   };
-
soc {
system-control@1c0 {
compatible = "allwinner,sun8i-h3-system-control";
-- 
2.19.2

[PATCH v2 05/15] dt-bindings: sram: sunxi: Add bindings for the H5 with SRAM C1

[Paul Kocialkowski]

This introduces new bindings for the H5 SoC in the SRAM controller.
Because the SRAM layout is different from other SoCs, no backward
compatibility is assumed with any of them.

However, the C1 SRAM section alone looks similar to previous SoCs,
so it is compatible with the initial A10 binding.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/sram/sunxi-sram.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt 
b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
index 5c84850dd0df..5c9a54ad3b53 100644
--- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -18,6 +18,7 @@ Required properties:
 - "allwinner,sun8i-h3-system-control"
 - "allwinner,sun50i-a64-sram-controller" (deprecated)
 - "allwinner,sun50i-a64-system-control"
+- "allwinner,sun50i-h5-system-control"
 - "allwinner,sun50i-h6-system-control", 
"allwinner,sun50i-a64-system-control"
 - "allwinner,suniv-f1c100s-system-control", 
"allwinner,sun4i-a10-system-control"
 - reg : sram controller register offset + length
@@ -56,6 +57,9 @@ The valid sections compatible for H3 are:
 The valid sections compatible for A64 are:
 - allwinner,sun50i-a64-sram-c
 
+The valid sections compatible for H5 are:
+- allwinner,sun50i-h5-sram-c1, allwinner,sun4i-a10-sram-c1
+
 The valid sections compatible for H6 are:
 - allwinner,sun50i-h6-sram-c, allwinner,sun50i-a64-sram-c
 
-- 
2.19.2

[PATCH v2 04/15] soc: sunxi: sram: Enable EMAC clock access for H3 variant

[Paul Kocialkowski]

Just like the A64 and H5, the H3 SoC uses the system control block
to enable the EMAC clock.

Add a variant structure definition for the H3 and use it over the A10
one. This will allow using the H3-specific binding for the syscon node
attached to the EMAC instead of the generic syscon binding.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Chen-Yu Tsai 
---
 drivers/soc/sunxi/sunxi_sram.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index 71e3ee4a3f19..fd81a3c0db45 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -290,6 +290,10 @@ static const struct sunxi_sramc_variant 
sun4i_a10_sramc_variant = {
/* Nothing special */
 };
 
+static const struct sunxi_sramc_variant sun8i_h3_sramc_variant = {
+   .has_emac_clock = true,
+};
+
 static const struct sunxi_sramc_variant sun50i_a64_sramc_variant = {
.has_emac_clock = true,
 };
@@ -369,7 +373,7 @@ static const struct of_device_id sunxi_sram_dt_match[] = {
},
{
.compatible = "allwinner,sun8i-h3-system-control",
-   .data = &sun4i_a10_sramc_variant,
+   .data = &sun8i_h3_sramc_variant,
},
{
.compatible = "allwinner,sun50i-a64-sram-controller",
-- 
2.19.2

[PATCH v2 01/15] ARM: dts: sun8i: h3: Fix the system-control register range

[Paul Kocialkowski]

Unlike in previous generations, the system-control register range is not
limited to a size of 0x30 on the H3. In particular, the EMAC clock
configuration register (accessed through syscon) is at offset 0x30 in
that range.

Extend the register size to its full range (0x1000) as a result.

Signed-off-by: Paul Kocialkowski 
Acked-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index c2da3a3d373a..dbb7e71b6d69 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -136,7 +136,7 @@
soc {
system-control@1c0 {
compatible = "allwinner,sun8i-h3-system-control";
-   reg = <0x01c0 0x30>;
+   reg = <0x01c0 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
-- 
2.19.2

[PATCH v2 00/15] Cedrus H5 and A64 support with A33 and H3 updates

[Paul Kocialkowski]

This series adds support for the Allwinner H5 and A64 platforms to the
cedrus stateless video codec driver, with minor updates to the A33 and
H3 platforms.

It requires changes to the SRAM driver bindings and driver, to properly
support the H5 and the A64 C1 SRAM section. Because a H5-specific
system-control node is introduced, the dummy syscon node that was shared
between the H3 and H5 is removed in favor of each platform-specific node.
A few fixes are included to ensure that the EMAC clock configuration
register is still accessible through the sunxi SRAM driver (instead of the
dummy syscon node, that was there for this purpose) on the H3 and H5.

The reserved memory nodes for the A33 and H3 are also removed in this
series, since they are not actually necessary.

Changes since v1:
* Removed the reserved-memory nodes for the A64 and H5;
* Removed the reserved-memory nodes for the A33 and H3;
* Corrected the SRAM bases and sizes to the best of our knowledge;
* Dropped cosmetic dt changes already included in the sunxi tree.

Paul Kocialkowski (15):
  ARM: dts: sun8i: h3: Fix the system-control register range
  ARM: dts: sun8i: a33: Remove unnecessary reserved memory node
  ARM: dts: sun8i: h3: Remove unnecessary reserved memory node
  soc: sunxi: sram: Enable EMAC clock access for H3 variant
  dt-bindings: sram: sunxi: Add bindings for the H5 with SRAM C1
  soc: sunxi: sram: Add support for the H5 SoC system control
  arm64: dts: allwinner: h5: Add system-control node with SRAM C1
  ARM/arm64: sunxi: Move H3/H5 syscon label over to soc-specific nodes
  dt-bindings: sram: sunxi: Add compatible for the A64 SRAM C1
  arm64: dts: allwinner: a64: Add support for the SRAM C1 section
  dt-bindings: media: cedrus: Add compatibles for the A64 and H5
  media: cedrus: Add device-tree compatible and variant for H5 support
  media: cedrus: Add device-tree compatible and variant for A64 support
  arm64: dts: allwinner: h5: Add Video Engine node
  arm64: dts: allwinner: a64: Add Video Engine node

 .../devicetree/bindings/media/cedrus.txt  |  2 ++
 .../devicetree/bindings/sram/sunxi-sram.txt   |  5 +++
 arch/arm/boot/dts/sun8i-a33.dtsi  | 15 -
 arch/arm/boot/dts/sun8i-h3.dtsi   | 18 ++
 arch/arm/boot/dts/sunxi-h3-h5.dtsi|  6 
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 25 ++
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi  | 33 +++
 drivers/soc/sunxi/sunxi_sram.c| 10 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   | 16 +
 9 files changed, 92 insertions(+), 38 deletions(-)

-- 
2.19.2

Re: [PATCH] media: s5p-mfc: Fix memdev DMA configuration

[Mauro Carvalho Chehab]

Em Fri, 14 Sep 2018 14:19:29 +0200
Marek Szyprowski  escreveu:

> Hi Robin,
> 
> On 2018-09-12 18:45, Robin Murphy wrote:
> > Having of_reserved_mem_device_init() forcibly reconfigure DMA for all
> > callers, potentially overriding the work done by a bus-specific
> > .dma_configure method earlier, is at best a bad idea and at worst
> > actively harmful. If drivers really need virtual devices to own
> > dma-coherent memory, they should explicitly configure those devices
> > based on the appropriate firmware node as they create them.
> >
> > It looks like the only driver not passing in a proper OF platform device
> > is s5p-mfc, so move the rogue of_dma_configure() call into that driver
> > where it logically belongs.
> >
> > CC: Smitha T Murthy 
> > CC: Marek Szyprowski 
> > CC: Rob Herring 
> > Signed-off-by: Robin Murphy   
> 
> Right, after recent cleanup dma ops initialization, MFC driver is
> a better place for calling of_dma_configure() on virtual devices.
> 
> Reviewed-by: Marek Szyprowski 

This patch seems to fit better via OF/DT tree. Not sure if it was
merged there yet. In any case:

Acked-by: Mauro Carvalho Chehab 

> 
> > ---
> >   drivers/media/platform/s5p-mfc/s5p_mfc.c | 7 +++
> >   drivers/of/of_reserved_mem.c | 4 
> >   2 files changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> > b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> > index 927a1235408d..77eb4a4511c1 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> > @@ -1094,6 +1094,13 @@ static struct device *s5p_mfc_alloc_memdev(struct 
> > device *dev,
> > child->dma_mask = dev->dma_mask;
> > child->release = s5p_mfc_memdev_release;
> >   
> > +   /*
> > +* The memdevs are not proper OF platform devices, so in order for them
> > +* to be treated as valid DMA masters we need a bit of a hack to force
> > +* them to inherit the MFC node's DMA configuration.
> > +*/
> > +   of_dma_configure(child, dev->of_node, true);
> > +
> > if (device_add(child) == 0) {
> > ret = of_reserved_mem_device_init_by_idx(child, dev->of_node,
> >  idx);
> > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> > index 895c83e0c7b6..4ef6f4485335 100644
> > --- a/drivers/of/of_reserved_mem.c
> > +++ b/drivers/of/of_reserved_mem.c
> > @@ -350,10 +350,6 @@ int of_reserved_mem_device_init_by_idx(struct device 
> > *dev,
> > mutex_lock(&of_rmem_assigned_device_mutex);
> > list_add(&rd->list, &of_rmem_assigned_device_list);
> > mutex_unlock(&of_rmem_assigned_device_mutex);
> > -   /* ensure that dma_ops is set for virtual devices
> > -* using reserved memory
> > -*/
> > -   of_dma_configure(dev, np, true);
> >   
> > dev_info(dev, "assigned reserved memory node %s\n", rmem->name);
> > } else {  
> 
> Best regards



Thanks,
Mauro

Re: [PATCH v2 07/15] arm64: dts: allwinner: h5: Add system-control node with SRAM C1

[Paul Kocialkowski]

Hi,

On Wed, 2018-12-05 at 17:45 +0800, Chen-Yu Tsai wrote:
> On Wed, Dec 5, 2018 at 5:25 PM Paul Kocialkowski
>  wrote:
> > Add the H5-specific system control node description to its device-tree
> > with support for the SRAM C1 section, that will be used by the video
> > codec node later on.
> > 
> > The CPU-side SRAM address was obtained empirically while the size was
> > taken from the documentation. They may not be entirely accurate.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 22 
> >  1 file changed, 22 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi 
> > b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > index b41dc1aab67d..42bfb560b367 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > @@ -94,6 +94,28 @@
> > };
> > 
> > soc {
> > +   system-control@1c0 {
> > +   compatible = "allwinner,sun50i-h5-system-control";
> > +   reg = <0x01c0 0x1000>;
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges;
> > +
> > +   sram_c1: sram@1d0 {
> > +   compatible = "mmio-sram";
> > +   reg = <0x00018000 0x1c000>;
> 
> 0x1d0 or 0x18000?

For the H5, I found the VE SRAM area to be mapped to 0x18000 on the CPU
side (when testing with devmem), unlike the A64, H3 and others. I was
rather surprised about this as well!

> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges = <0 0x00018000 0x1c000>;
> 
> Same here.
> 
> > +
> > +   ve_sram: sram-section@0 {
> > +   compatible = 
> > "allwinner,sun50i-h5-sram-c1",
> > +
> > "allwinner,sun4i-a10-sram-c1";
> > +   reg = <0x00 0x1c000>;
> > +   };
> > +   };
> > +   };
> > +
> > mali: gpu@1e8 {
> > compatible = "allwinner,sun50i-h5-mali", 
> > "arm,mali-450";
> > reg = <0x01e8 0x3>;
> > --
> > 2.19.2

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

Re: [PATCH v2 07/15] arm64: dts: allwinner: h5: Add system-control node with SRAM C1

[Paul Kocialkowski]

Hi,

On Wed, 2018-12-05 at 17:49 +0800, Chen-Yu Tsai wrote:
> On Wed, Dec 5, 2018 at 5:48 PM Paul Kocialkowski
>  wrote:
> > Hi,
> > 
> > On Wed, 2018-12-05 at 17:45 +0800, Chen-Yu Tsai wrote:
> > > On Wed, Dec 5, 2018 at 5:25 PM Paul Kocialkowski
> > >  wrote:
> > > > Add the H5-specific system control node description to its device-tree
> > > > with support for the SRAM C1 section, that will be used by the video
> > > > codec node later on.
> > > > 
> > > > The CPU-side SRAM address was obtained empirically while the size was
> > > > taken from the documentation. They may not be entirely accurate.
> > > > 
> > > > Signed-off-by: Paul Kocialkowski 
> > > > ---
> > > >  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 22 
> > > >  1 file changed, 22 insertions(+)
> > > > 
> > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi 
> > > > b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > > index b41dc1aab67d..42bfb560b367 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > > @@ -94,6 +94,28 @@
> > > > };
> > > > 
> > > > soc {
> > > > +   system-control@1c0 {
> > > > +   compatible = 
> > > > "allwinner,sun50i-h5-system-control";
> > > > +   reg = <0x01c0 0x1000>;
> > > > +   #address-cells = <1>;
> > > > +   #size-cells = <1>;
> > > > +   ranges;
> > > > +
> > > > +   sram_c1: sram@1d0 {
> > > > +   compatible = "mmio-sram";
> > > > +   reg = <0x00018000 0x1c000>;
> > > 
> > > 0x1d0 or 0x18000?
> > 
> > For the H5, I found the VE SRAM area to be mapped to 0x18000 on the CPU
> > side (when testing with devmem), unlike the A64, H3 and others. I was
> > rather surprised about this as well!
> 
> I'm actually referring to the node name that still says 1d0.

Oh I totally missed that, sorry. Thanks for pointing it out!

Cheers,

Paul

> ChenYu
> 
> > > > +   #address-cells = <1>;
> > > > +   #size-cells = <1>;
> > > > +   ranges = <0 0x00018000 0x1c000>;
> > > 
> > > Same here.
> > > 
> > > > +
> > > > +   ve_sram: sram-section@0 {
> > > > +   compatible = 
> > > > "allwinner,sun50i-h5-sram-c1",
> > > > +
> > > > "allwinner,sun4i-a10-sram-c1";
> > > > +   reg = <0x00 0x1c000>;
> > > > +   };
> > > > +   };
> > > > +   };
> > > > +
> > > > mali: gpu@1e8 {
> > > > compatible = "allwinner,sun50i-h5-mali", 
> > > > "arm,mali-450";
> > > > reg = <0x01e8 0x3>;
> > > > --
> > > > 2.19.2
> > 
> > Cheers,
> > 
> > Paul
> > 
> > --
> > Paul Kocialkowski, Bootlin (formerly Free Electrons)
> > Embedded Linux and kernel engineering
> > https://bootlin.com
> > 
-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

Re: [PATCH v2 07/15] arm64: dts: allwinner: h5: Add system-control node with SRAM C1

[Chen-Yu Tsai]

On Wed, Dec 5, 2018 at 5:48 PM Paul Kocialkowski
 wrote:
>
> Hi,
>
> On Wed, 2018-12-05 at 17:45 +0800, Chen-Yu Tsai wrote:
> > On Wed, Dec 5, 2018 at 5:25 PM Paul Kocialkowski
> >  wrote:
> > > Add the H5-specific system control node description to its device-tree
> > > with support for the SRAM C1 section, that will be used by the video
> > > codec node later on.
> > >
> > > The CPU-side SRAM address was obtained empirically while the size was
> > > taken from the documentation. They may not be entirely accurate.
> > >
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 22 
> > >  1 file changed, 22 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi 
> > > b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > index b41dc1aab67d..42bfb560b367 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > @@ -94,6 +94,28 @@
> > > };
> > >
> > > soc {
> > > +   system-control@1c0 {
> > > +   compatible = "allwinner,sun50i-h5-system-control";
> > > +   reg = <0x01c0 0x1000>;
> > > +   #address-cells = <1>;
> > > +   #size-cells = <1>;
> > > +   ranges;
> > > +
> > > +   sram_c1: sram@1d0 {
> > > +   compatible = "mmio-sram";
> > > +   reg = <0x00018000 0x1c000>;
> >
> > 0x1d0 or 0x18000?
>
> For the H5, I found the VE SRAM area to be mapped to 0x18000 on the CPU
> side (when testing with devmem), unlike the A64, H3 and others. I was
> rather surprised about this as well!

I'm actually referring to the node name that still says 1d0.

ChenYu

>
> > > +   #address-cells = <1>;
> > > +   #size-cells = <1>;
> > > +   ranges = <0 0x00018000 0x1c000>;
> >
> > Same here.
> >
> > > +
> > > +   ve_sram: sram-section@0 {
> > > +   compatible = 
> > > "allwinner,sun50i-h5-sram-c1",
> > > +
> > > "allwinner,sun4i-a10-sram-c1";
> > > +   reg = <0x00 0x1c000>;
> > > +   };
> > > +   };
> > > +   };
> > > +
> > > mali: gpu@1e8 {
> > > compatible = "allwinner,sun50i-h5-mali", 
> > > "arm,mali-450";
> > > reg = <0x01e8 0x3>;
> > > --
> > > 2.19.2
>
> Cheers,
>
> Paul
>
> --
> Paul Kocialkowski, Bootlin (formerly Free Electrons)
> Embedded Linux and kernel engineering
> https://bootlin.com
>

[PATCH] media: docs-rst: Document m2m stateless video decoder interface

[Alexandre Courbot]

Documents the protocol that user-space should follow when
communicating with stateless video decoders.

The stateless video decoding API makes use of the new request and tags
APIs. While it has been implemented with the Cedrus driver so far, it
should probably still be considered staging for a short while.

Signed-off-by: Alexandre Courbot 
---
Removing the RFC flag this time. Changes since RFCv3:

* Included Tomasz and Hans feedback,
* Expanded the decoding section to better describe the use of requests,
* Use the tags API.

 Documentation/media/uapi/v4l/dev-codec.rst|   5 +
 .../media/uapi/v4l/dev-stateless-decoder.rst  | 399 ++
 2 files changed, 404 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst

diff --git a/Documentation/media/uapi/v4l/dev-codec.rst 
b/Documentation/media/uapi/v4l/dev-codec.rst
index c61e938bd8dc..3e6a3e883f11 100644
--- a/Documentation/media/uapi/v4l/dev-codec.rst
+++ b/Documentation/media/uapi/v4l/dev-codec.rst
@@ -6,6 +6,11 @@
 Codec Interface
 ***
 
+.. toctree::
+:maxdepth: 1
+
+dev-stateless-decoder
+
 A V4L2 codec can compress, decompress, transform, or otherwise convert
 video data from one format into another format, in memory. Typically
 such devices are memory-to-memory devices (i.e. devices with the
diff --git a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst 
b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
new file mode 100644
index ..7a781c89bd59
--- /dev/null
+++ b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst
@@ -0,0 +1,399 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _stateless_decoder:
+
+**
+Memory-to-memory Stateless Video Decoder Interface
+**
+
+A stateless decoder is a decoder that works without retaining any kind of state
+between processing frames. This means that each frame is decoded independently
+of any previous and future frames, and that the client is responsible for
+maintaining the decoding state and providing it to the decoder with each
+decoding request. This is in contrast to the stateful video decoder interface,
+where the hardware and driver maintain the decoding state and all the client
+has to do is to provide the raw encoded stream.
+
+This section describes how user-space ("the client") is expected to communicate
+with such decoders in order to successfully decode an encoded stream. Compared
+to stateful codecs, the decoder/client sequence is simpler, but the cost of
+this simplicity is extra complexity in the client which must maintain a
+consistent decoding state.
+
+Stateless decoders make use of the request API and buffer tags. A stateless
+decoder must thus expose the following capabilities on its queues when
+:c:func:`VIDIOC_REQBUFS` or :c:func:`VIDIOC_CREATE_BUFS` are invoked:
+
+* The ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` capability must be set on the
+  ``OUTPUT`` queue,
+
+* The ``V4L2_BUF_CAP_SUPPORTS_TAGS`` capability must be set on the ``OUTPUT``
+  and ``CAPTURE`` queues,
+
+Querying capabilities
+=
+
+1. To enumerate the set of coded formats supported by the decoder, the client
+   calls :c:func:`VIDIOC_ENUM_FMT` on the ``OUTPUT`` queue.
+
+   * The driver must always return the full set of supported ``OUTPUT`` 
formats,
+ irrespective of the format currently set on the ``CAPTURE`` queue.
+
+   * Simultaneously, the driver must restrain the set of values returned by
+ codec-specific capability controls (such as H.264 profiles) to the set
+ actually supported by the hardware.
+
+2. To enumerate the set of supported raw formats, the client calls
+   :c:func:`VIDIOC_ENUM_FMT` on the ``CAPTURE`` queue.
+
+   * The driver must return only the formats supported for the format currently
+ active on the ``OUTPUT`` queue.
+
+   * Depending on the currently set ``OUTPUT`` format, the set of supported raw
+ formats may depend on the value of some controls (e.g. parsed format
+ headers) which are codec-dependent. The client is responsible for making
+ sure that these controls are set before querying the ``CAPTURE`` queue.
+ Failure to do so will result in the default values for these controls 
being
+ used, and a returned set of formats that may not be usable for the media
+ the client is trying to decode.
+
+3. The client may use :c:func:`VIDIOC_ENUM_FRAMESIZES` to detect supported
+   resolutions for a given format, passing desired pixel format in
+   :c:type:`v4l2_frmsizeenum`'s ``pixel_format``.
+
+4. Supported profiles and levels for the current ``OUTPUT`` format, if
+   applicable, may be queried using their respective controls via
+   :c:func:`VIDIOC_QUERYCTRL`.
+
+Initialization
+==
+
+1. Set the coded format on the ``OUTPUT`` queue via :c:func:`VIDIOC_S_FMT`.
+
+   * **Required fields:**
+
+ ``type``
+ a ``V4L2_BUF_TYPE_*`` enum appropriate

Re: [PATCH v2 07/15] arm64: dts: allwinner: h5: Add system-control node with SRAM C1

[Chen-Yu Tsai]

On Wed, Dec 5, 2018 at 5:25 PM Paul Kocialkowski
 wrote:
>
> Add the H5-specific system control node description to its device-tree
> with support for the SRAM C1 section, that will be used by the video
> codec node later on.
>
> The CPU-side SRAM address was obtained empirically while the size was
> taken from the documentation. They may not be entirely accurate.
>
> Signed-off-by: Paul Kocialkowski 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 22 
>  1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> index b41dc1aab67d..42bfb560b367 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> @@ -94,6 +94,28 @@
> };
>
> soc {
> +   system-control@1c0 {
> +   compatible = "allwinner,sun50i-h5-system-control";
> +   reg = <0x01c0 0x1000>;
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges;
> +
> +   sram_c1: sram@1d0 {
> +   compatible = "mmio-sram";
> +   reg = <0x00018000 0x1c000>;

0x1d0 or 0x18000?

> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges = <0 0x00018000 0x1c000>;

Same here.

> +
> +   ve_sram: sram-section@0 {
> +   compatible = 
> "allwinner,sun50i-h5-sram-c1",
> +
> "allwinner,sun4i-a10-sram-c1";
> +   reg = <0x00 0x1c000>;
> +   };
> +   };
> +   };
> +
> mali: gpu@1e8 {
> compatible = "allwinner,sun50i-h5-mali", 
> "arm,mali-450";
> reg = <0x01e8 0x3>;
> --
> 2.19.2
>

Re: [PATCH v2 00/15] Cedrus H5 and A64 support with A33 and H3 updates

[Chen-Yu Tsai]

On Wed, Dec 5, 2018 at 5:25 PM Paul Kocialkowski
 wrote:
>
> This series adds support for the Allwinner H5 and A64 platforms to the
> cedrus stateless video codec driver, with minor updates to the A33 and
> H3 platforms.
>
> It requires changes to the SRAM driver bindings and driver, to properly
> support the H5 and the A64 C1 SRAM section. Because a H5-specific
> system-control node is introduced, the dummy syscon node that was shared
> between the H3 and H5 is removed in favor of each platform-specific node.
> A few fixes are included to ensure that the EMAC clock configuration
> register is still accessible through the sunxi SRAM driver (instead of the
> dummy syscon node, that was there for this purpose) on the H3 and H5.
>
> The reserved memory nodes for the A33 and H3 are also removed in this
> series, since they are not actually necessary.
>
> Changes since v1:
> * Removed the reserved-memory nodes for the A64 and H5;
> * Removed the reserved-memory nodes for the A33 and H3;
> * Corrected the SRAM bases and sizes to the best of our knowledge;
> * Dropped cosmetic dt changes already included in the sunxi tree.
>
> Paul Kocialkowski (15):
>   ARM: dts: sun8i: h3: Fix the system-control register range
>   ARM: dts: sun8i: a33: Remove unnecessary reserved memory node
>   ARM: dts: sun8i: h3: Remove unnecessary reserved memory node
>   soc: sunxi: sram: Enable EMAC clock access for H3 variant
>   dt-bindings: sram: sunxi: Add bindings for the H5 with SRAM C1
>   soc: sunxi: sram: Add support for the H5 SoC system control
>   arm64: dts: allwinner: h5: Add system-control node with SRAM C1
>   ARM/arm64: sunxi: Move H3/H5 syscon label over to soc-specific nodes
>   dt-bindings: sram: sunxi: Add compatible for the A64 SRAM C1
>   arm64: dts: allwinner: a64: Add support for the SRAM C1 section
>   dt-bindings: media: cedrus: Add compatibles for the A64 and H5
>   media: cedrus: Add device-tree compatible and variant for H5 support
>   media: cedrus: Add device-tree compatible and variant for A64 support
>   arm64: dts: allwinner: h5: Add Video Engine node
>   arm64: dts: allwinner: a64: Add Video Engine node

Other than the error in patch 7,

Acked-by: Chen-Yu Tsai 

Re: [PATCH 7/8] media: sti/bdisp: don't pass GFP_DMA32 to dma_alloc_attrs

[Mauro Carvalho Chehab]

Em Thu, 18 Oct 2018 14:00:40 +0200
Benjamin Gaignard  escreveu:

> Le mer. 17 oct. 2018 à 09:20, Christoph Hellwig  a écrit :
> >
> > On Mon, Oct 15, 2018 at 11:12:55AM +0200, Benjamin Gaignard wrote:  
> > > Le sam. 13 oct. 2018 à 17:18, Christoph Hellwig  a écrit :  
> > > >
> > > > The DMA API does its own zone decisions based on the coherent_dma_mask.
> > > >
> > > > Signed-off-by: Christoph Hellwig   
> > >
> > > Reviewed-by: Benjamin Gaignard   
> >
> > Can you pick it up through the media tree?  
> 
> No but Mauros or Hans (in CC) can add it.

I'm adding it. Sorry for the delay. All those trips for MS/KS made
harder to handle it earlier.

Thanks,
Mauro

Re: [PATCH 0/5] media/sun6i: Allwinner A64 CSI support

[Jagan Teki]

On Mon, Dec 3, 2018 at 3:44 PM Chen-Yu Tsai  wrote:
>
> On Mon, Dec 3, 2018 at 6:07 PM Jagan Teki  wrote:
> >
> > This series support CSI on Allwinner A64.
> >
> > The CSI controller seems similar to that of in H3, so fallback
> > compatible is used to load the driver.
> >
> > Unlike other SoC's A64 has set of GPIO Pin gropus SDA, SCK intead
> > of dedicated I2C controller, so this series used i2c-gpio bitbanging.
> >
> > Right now the camera is able to detect, but capture images shows
> > sequence of red, blue line. any suggestion please help.
>
> The CSI controller doesn't seem to work properly at the default
> clock rate of 600 MHz. Dropping it down to 300 MHz, the default
> rate used by the BSP, fixes things.
>
> The BSP also tries to use different clock rates (multiples of 108 MHz)
> according to the captured image size. I've not tried this since the
> driver no longer exports sub-device controls, and I currently don't
> know how to handle that to change the resolution.

I saw 1080p@30 capture is not working, but rest 320x240@30,
640x480@30, 640x480@60, 1280x720@30 with UYVY8_2X8 and YUYV8_2X8 seems
working on 300MHz.

I even tried 1080p on 600MHz but kernel seems crashing
[video4linux2,v4l2 @ 0x2eaa9380] ioctl(VIDIOC_G_PARM): Inappropriate
ioctl for device
[video4linux2,v4l2 @ 0x2eaa9380] Time per frame unknown
[video4linux2,v4l2 @ 0x2eaa9380] Stream #0: not enough frames to
estimate rate; consider increasing probesize
Input #0, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, start: 44.934807, bitrate: N/A
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p,
1920x1080, 1000k tbr, 1000k tbn, 1000k tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
Output #0, matroska, to 'output_YUYV8_2X8_1920x1080@1_30-new.mkv':
  Metadata:
encoder : Lavf57.83.100
Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 1920x1080,
q=2-31, 200 kb/s, 65535 fps, 1k tbn, 65535 tbc
Metadata:
  encoder : Lavc57.107.100 mpeg4
Side data:
  cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: -1
[   45.255793] random: ffmpeg: uninitialized urandom read (4 bytes read)
frame=4 fps=0.0 q=10.0 size= 150kB time=00:00:00.10
bitrate=12162.7kbits/s speed=0.17x[   46.115153] [ cut
here ]
[   46.119804] kernel BUG at arch/arm64/kernel/traps.c:426!
[   46.125120] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[   46.130607] Modules linked in:
[   46.133670] CPU: 2 PID: 1630 Comm: ffmpeg Not tainted
4.20.0-rc4-next-20181130-00027-g58d9b3c5c1db-dirty #10
[   46.143497] Hardware name: Amarula A64-Relic (DT)
[   46.148203] pstate: 6085 (nZCv daIf -PAN -UAO)
[   46.153005] pc : do_undefinstr+0x248/0x260
[   46.157103] lr : do_undefinstr+0x13c/0x260
[   46.161198] sp : 08013bb0
[   46.164513] x29: 08013bb0 x28: 800035b30d40
[   46.169827] x27: 0815a758 x26: 0001
[   46.175141] x25:  x24: 
[   46.180454] x23:  x22: 09344140
[   46.185768] x21: 837f8080 x20: 08013c00
[   46.191082] x19: 091dd000 x18: 
[   46.196395] x17:  x16: 
[   46.201709] x15: 0043 x14: 0341
[   46.207022] x13: 0400 x12: 0043
[   46.212336] x11: 0400 x10: 0001234d
[   46.217650] x9 : 0001 x8 : 800037db7900
[   46.222964] x7 : 800037db8380 x6 : 08013bf8
[   46.228278] x5 : 091e8310 x4 : d530
[   46.233592] x3 : 8370 x2 : 
[   46.238906] x1 : 800035b30d40 x0 : 0005
[   46.244222] Process ffmpeg (pid: 1630, stack limit = 0x(ptrval))
[   46.250921] Call trace:
[   46.253371]  do_undefinstr+0x248/0x260
[   46.257125]  el1_undef+0x10/0x70
[   46.260358]  task_tick_fair+0x140/0x548
[   46.264199]  scheduler_tick+0x6c/0x110
[   46.267956]  update_process_times+0x40/0x58
[   46.272144]  tick_sched_handle.isra.5+0x30/0x50
[   46.276677]  tick_sched_timer+0x48/0x98
[   46.280516]  __hrtimer_run_queues+0x11c/0x190
[   46.284875]  hrtimer_interrupt+0xe4/0x240
[   46.288890]  arch_timer_handler_phys+0x30/0x40
[   46.293340]  handle_percpu_devid_irq+0x78/0x130
[   46.297874]  generic_handle_irq+0x24/0x38
[   46.301887]  __handle_domain_irq+0x5c/0xb8
[   46.305986]  gic_handle_irq+0x58/0xb0
[   46.309651]  el0_irq_naked+0x4c/0x54
[   46.313233] Code: b5fff8c0 b94047b5 179e d503201f (d421)
[   46.319338] ---[ end trace 0463ef25f03a52f8 ]---
[   46.323957] Kernel panic - not syncing: Fatal exception in interrupt
[   46.330311] SMP: stopping secondary CPUs
[   46.334240] Kernel Offset: disabled
[   46.337732] CPU features: 0x2,24802004
[   46.341481] Memory Limit: none

Re: [PATCH v2 12/15] media: cedrus: Add device-tree compatible and variant for H5 support

[Maxime Ripard]

On Wed, Dec 05, 2018 at 10:24:41AM +0100, Paul Kocialkowski wrote:
> Add the necessary compatible for supporting the H5 SoC along with a
> description of the capabilities of this variant.
> 
> Signed-off-by: Paul Kocialkowski 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v2 11/15] dt-bindings: media: cedrus: Add compatibles for the A64 and H5

[Maxime Ripard]

On Wed, Dec 05, 2018 at 10:24:40AM +0100, Paul Kocialkowski wrote:
> This introduces two new compatibles for the cedrus driver, for the
> A64 and H5 platforms.
> 
> Signed-off-by: Paul Kocialkowski 
> Reviewed-by: Rob Herring 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v2 13/15] media: cedrus: Add device-tree compatible and variant for A64 support

[Maxime Ripard]

65;5402;1c
On Wed, Dec 05, 2018 at 10:24:42AM +0100, Paul Kocialkowski wrote:
> Add the necessary compatible for supporting the A64 SoC along with a
> description of the capabilities of this variant.
> 
> Signed-off-by: Paul Kocialkowski 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v2 00/15] Cedrus H5 and A64 support with A33 and H3 updates

[Maxime Ripard]

On Wed, Dec 05, 2018 at 05:48:34PM +0800, Chen-Yu Tsai wrote:
> On Wed, Dec 5, 2018 at 5:25 PM Paul Kocialkowski
>  wrote:
> >
> > This series adds support for the Allwinner H5 and A64 platforms to the
> > cedrus stateless video codec driver, with minor updates to the A33 and
> > H3 platforms.
> >
> > It requires changes to the SRAM driver bindings and driver, to properly
> > support the H5 and the A64 C1 SRAM section. Because a H5-specific
> > system-control node is introduced, the dummy syscon node that was shared
> > between the H3 and H5 is removed in favor of each platform-specific node.
> > A few fixes are included to ensure that the EMAC clock configuration
> > register is still accessible through the sunxi SRAM driver (instead of the
> > dummy syscon node, that was there for this purpose) on the H3 and H5.
> >
> > The reserved memory nodes for the A33 and H3 are also removed in this
> > series, since they are not actually necessary.
> >
> > Changes since v1:
> > * Removed the reserved-memory nodes for the A64 and H5;
> > * Removed the reserved-memory nodes for the A33 and H3;
> > * Corrected the SRAM bases and sizes to the best of our knowledge;
> > * Dropped cosmetic dt changes already included in the sunxi tree.
> >
> > Paul Kocialkowski (15):
> >   ARM: dts: sun8i: h3: Fix the system-control register range
> >   ARM: dts: sun8i: a33: Remove unnecessary reserved memory node
> >   ARM: dts: sun8i: h3: Remove unnecessary reserved memory node
> >   soc: sunxi: sram: Enable EMAC clock access for H3 variant
> >   dt-bindings: sram: sunxi: Add bindings for the H5 with SRAM C1
> >   soc: sunxi: sram: Add support for the H5 SoC system control
> >   arm64: dts: allwinner: h5: Add system-control node with SRAM C1
> >   ARM/arm64: sunxi: Move H3/H5 syscon label over to soc-specific nodes
> >   dt-bindings: sram: sunxi: Add compatible for the A64 SRAM C1
> >   arm64: dts: allwinner: a64: Add support for the SRAM C1 section
> >   dt-bindings: media: cedrus: Add compatibles for the A64 and H5
> >   media: cedrus: Add device-tree compatible and variant for H5 support
> >   media: cedrus: Add device-tree compatible and variant for A64 support
> >   arm64: dts: allwinner: h5: Add Video Engine node
> >   arm64: dts: allwinner: a64: Add Video Engine node
> 
> Other than the error in patch 7,
> 
> Acked-by: Chen-Yu Tsai 

Applied all the patches but 11-13, with the changes discussed on patch 7 fixed.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [LKP] [mm] 19717e78a0: stderr.if(target_node==NUMA_NO_NODE){

[Anshuman Khandual]

On 12/05/2018 10:30 AM, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
> 
> commit: 19717e78a04d51512cf0e7b9b09c61f06b2af071 ("[PATCH V2] mm: Replace all 
> open encodings for NUMA_NO_NODE")
> url: 
> https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-Replace-all-open-encodings-for-NUMA_NO_NODE/20181126-203831
> 
> 
> in testcase: perf-sanity-tests
> with following parameters:
> 
>   perf_compiler: gcc
>   ucode: 0x713
> 
> 
> 
> on test machine: 16 threads Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 8G 
> memory
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):

The fix (in Andrew's staging tree) from Stephen Rothwell which adds 

definitions to  should fix this.

Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE

[Anshuman Khandual]

On 12/05/2018 02:56 AM, Lubomir Rintel wrote:
> On Mon, 2018-11-26 at 17:56 +0530, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in there. Replace these open encodings for an invalid node number with the
>> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
>> 'invalid node' from various places redirecting them to a common definition.
>>
>> Signed-off-by: Anshuman Khandual 
>> ---
>> Changes in V2:
>>
>> - Added inclusion of 'numa.h' header at various places per Andrew
>> - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod
>>
>> Changes in V1: (https://lkml.org/lkml/2018/11/23/485)
>>
>> - Dropped OCFS2 changes per Joseph
>> - Dropped media/video drivers changes per Hans
>>
>> RFC - https://patchwork.kernel.org/patch/10678035/
>>
>> Build tested this with multiple cross compiler options like alpha, sparc,
>> arm64, x86, powerpc, powerpc64le etc with their default config which might
>> not have compiled tested all driver related changes. I will appreciate
>> folks giving this a test in their respective build environment.
>>
>> All these places for replacement were found by running the following grep
>> patterns on the entire kernel code. Please let me know if this might have
>> missed some instances. This might also have replaced some false positives.
>> I will appreciate suggestions, inputs and review.
>>
>> 1. git grep "nid == -1"
>> 2. git grep "node == -1"
>> 3. git grep "nid = -1"
>> 4. git grep "node = -1"
>>
>>  arch/alpha/include/asm/topology.h |  3 ++-
>>  arch/ia64/kernel/numa.c   |  2 +-
>>  arch/ia64/mm/discontig.c  |  6 +++---
>>  arch/ia64/sn/kernel/io_common.c   |  3 ++-
>>  arch/powerpc/include/asm/pci-bridge.h |  3 ++-
>>  arch/powerpc/kernel/paca.c|  3 ++-
>>  arch/powerpc/kernel/pci-common.c  |  3 ++-
>>  arch/powerpc/mm/numa.c| 14 +++---
>>  arch/powerpc/platforms/powernv/memtrace.c |  5 +++--
>>  arch/sparc/kernel/auxio_32.c  |  3 ++-
>>  arch/sparc/kernel/pci_fire.c  |  3 ++-
>>  arch/sparc/kernel/pci_schizo.c|  3 ++-
>>  arch/sparc/kernel/pcic.c  |  7 ---
>>  arch/sparc/kernel/psycho_common.c |  3 ++-
>>  arch/sparc/kernel/sbus.c  |  3 ++-
>>  arch/sparc/mm/init_64.c   |  6 +++---
>>  arch/sparc/prom/init_32.c |  3 ++-
>>  arch/sparc/prom/init_64.c |  5 +++--
>>  arch/sparc/prom/tree_32.c | 13 +++--
>>  arch/sparc/prom/tree_64.c | 19 ++-
>>  arch/x86/include/asm/pci.h|  3 ++-
>>  arch/x86/kernel/apic/x2apic_uv_x.c|  7 ---
>>  arch/x86/kernel/smpboot.c |  3 ++-
>>  arch/x86/platform/olpc/olpc_dt.c  | 17 +
>>  drivers/block/mtip32xx/mtip32xx.c |  5 +++--
>>  drivers/dma/dmaengine.c   |  4 +++-
>>  drivers/infiniband/hw/hfi1/affinity.c |  3 ++-
>>  drivers/infiniband/hw/hfi1/init.c |  3 ++-
>>  drivers/iommu/dmar.c  |  5 +++--
>>  drivers/iommu/intel-iommu.c   |  3 ++-
>>  drivers/misc/sgi-xp/xpc_uv.c  |  3 ++-
>>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |  5 +++--
>>  include/linux/device.h|  2 +-
>>  init/init_task.c  |  3 ++-
>>  kernel/kthread.c  |  3 ++-
>>  kernel/sched/fair.c   | 15 ---
>>  lib/cpumask.c |  3 ++-
>>  mm/huge_memory.c  | 13 +++--
>>  mm/hugetlb.c  |  3 ++-
>>  mm/ksm.c  |  2 +-
>>  mm/memory.c   |  7 ---
>>  mm/memory_hotplug.c   | 12 ++--
>>  mm/mempolicy.c|  2 +-
>>  mm/page_alloc.c   |  4 ++--
>>  mm/page_ext.c |  2 +-
>>  net/core/pktgen.c |  3 ++-
>>  net/qrtr/qrtr.c   |  3 ++-
>>  tools/perf/bench/numa.c   |  6 +++---
>>  48 files changed, 146 insertions(+), 108 deletions(-)
> Thanks for the patch. It seems to me that you've got a fairly large
> amount of it wrong though -- perhaps relying just on "git grep" alone
> is not the best idea.

Hmm, okay.

> 
> The diffstat is not all that big, it is entirely plausible to just
> review each hunk manually: just do a "git show -U20" to get some
> context.
> 
> You get a NAK from me for the OLPC DT part, but I th

Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE

[Lubomir Rintel]

On Wed, 2018-12-05 at 17:01 +0530, Anshuman Khandual wrote:
> 
> On 12/05/2018 02:56 AM, Lubomir Rintel wrote:
> > On Mon, 2018-11-26 at 17:56 +0530, Anshuman Khandual wrote:
> > > At present there are multiple places where invalid node number is encoded
> > > as -1. Even though implicitly understood it is always better to have 
> > > macros
> > > in there. Replace these open encodings for an invalid node number with the
> > > global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
> > > 'invalid node' from various places redirecting them to a common 
> > > definition.
> > > 
> > > Signed-off-by: Anshuman Khandual 
> > > ---
> > > Changes in V2:
> > > 
> > > - Added inclusion of 'numa.h' header at various places per Andrew
> > > - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod
> > > 
> > > Changes in V1: (https://lkml.org/lkml/2018/11/23/485)
> > > 
> > > - Dropped OCFS2 changes per Joseph
> > > - Dropped media/video drivers changes per Hans
> > > 
> > > RFC - https://patchwork.kernel.org/patch/10678035/
> > > 
> > > Build tested this with multiple cross compiler options like alpha, sparc,
> > > arm64, x86, powerpc, powerpc64le etc with their default config which might
> > > not have compiled tested all driver related changes. I will appreciate
> > > folks giving this a test in their respective build environment.
> > > 
> > > All these places for replacement were found by running the following grep
> > > patterns on the entire kernel code. Please let me know if this might have
> > > missed some instances. This might also have replaced some false positives.
> > > I will appreciate suggestions, inputs and review.
> > > 
> > > 1. git grep "nid == -1"
> > > 2. git grep "node == -1"
> > > 3. git grep "nid = -1"
> > > 4. git grep "node = -1"
> > > 
> > >  arch/alpha/include/asm/topology.h |  3 ++-
> > >  arch/ia64/kernel/numa.c   |  2 +-
> > >  arch/ia64/mm/discontig.c  |  6 +++---
> > >  arch/ia64/sn/kernel/io_common.c   |  3 ++-
> > >  arch/powerpc/include/asm/pci-bridge.h |  3 ++-
> > >  arch/powerpc/kernel/paca.c|  3 ++-
> > >  arch/powerpc/kernel/pci-common.c  |  3 ++-
> > >  arch/powerpc/mm/numa.c| 14 +++---
> > >  arch/powerpc/platforms/powernv/memtrace.c |  5 +++--
> > >  arch/sparc/kernel/auxio_32.c  |  3 ++-
> > >  arch/sparc/kernel/pci_fire.c  |  3 ++-
> > >  arch/sparc/kernel/pci_schizo.c|  3 ++-
> > >  arch/sparc/kernel/pcic.c  |  7 ---
> > >  arch/sparc/kernel/psycho_common.c |  3 ++-
> > >  arch/sparc/kernel/sbus.c  |  3 ++-
> > >  arch/sparc/mm/init_64.c   |  6 +++---
> > >  arch/sparc/prom/init_32.c |  3 ++-
> > >  arch/sparc/prom/init_64.c |  5 +++--
> > >  arch/sparc/prom/tree_32.c | 13 +++--
> > >  arch/sparc/prom/tree_64.c | 19 ++-
> > >  arch/x86/include/asm/pci.h|  3 ++-
> > >  arch/x86/kernel/apic/x2apic_uv_x.c|  7 ---
> > >  arch/x86/kernel/smpboot.c |  3 ++-
> > >  arch/x86/platform/olpc/olpc_dt.c  | 17 +
> > >  drivers/block/mtip32xx/mtip32xx.c |  5 +++--
> > >  drivers/dma/dmaengine.c   |  4 +++-
> > >  drivers/infiniband/hw/hfi1/affinity.c |  3 ++-
> > >  drivers/infiniband/hw/hfi1/init.c |  3 ++-
> > >  drivers/iommu/dmar.c  |  5 +++--
> > >  drivers/iommu/intel-iommu.c   |  3 ++-
> > >  drivers/misc/sgi-xp/xpc_uv.c  |  3 ++-
> > >  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |  5 +++--
> > >  include/linux/device.h|  2 +-
> > >  init/init_task.c  |  3 ++-
> > >  kernel/kthread.c  |  3 ++-
> > >  kernel/sched/fair.c   | 15 ---
> > >  lib/cpumask.c |  3 ++-
> > >  mm/huge_memory.c  | 13 +++--
> > >  mm/hugetlb.c  |  3 ++-
> > >  mm/ksm.c  |  2 +-
> > >  mm/memory.c   |  7 ---
> > >  mm/memory_hotplug.c   | 12 ++--
> > >  mm/mempolicy.c|  2 +-
> > >  mm/page_alloc.c   |  4 ++--
> > >  mm/page_ext.c |  2 +-
> > >  net/core/pktgen.c |  3 ++-
> > >  net/qrtr/qrtr.c   |  3 ++-
> > >  tools/perf/bench/numa.c   |  6 +++---
> > >  48 files changed, 146 insertions(+), 108 deletions(-)
> > Thanks for the patch. It seems to me that y

Re: [PATCH v2 1/2] media: uapi: Add H264 low-level decoder API compound controls.

[Hans Verkuil]

On 11/15/18 15:56, Maxime Ripard wrote:
> From: Pawel Osciak 
> 
> Stateless video codecs will require both the H264 metadata and slices in
> order to be able to decode frames.
> 
> This introduces the definitions for a new pixel format for H264 slices that
> have been parsed, as well as the structures used to pass the metadata from
> the userspace to the kernel.
> 
> Co-Developed-by: Maxime Ripard 
> Signed-off-by: Pawel Osciak 
> Signed-off-by: Guenter Roeck 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/media/uapi/v4l/biblio.rst   |   9 +
>  .../media/uapi/v4l/extended-controls.rst  | 364 ++
>  .../media/uapi/v4l/pixfmt-compressed.rst  |  20 +
>  .../media/uapi/v4l/vidioc-queryctrl.rst   |  30 ++
>  .../media/videodev2.h.rst.exceptions  |   5 +
>  drivers/media/v4l2-core/v4l2-ctrls.c  |  42 ++
>  drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
>  include/media/v4l2-ctrls.h|  10 +
>  include/uapi/linux/v4l2-controls.h| 166 
>  include/uapi/linux/videodev2.h|  11 +
>  10 files changed, 658 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/biblio.rst 
> b/Documentation/media/uapi/v4l/biblio.rst
> index 386d6cf83e9c..73aeb7ce47d2 100644
> --- a/Documentation/media/uapi/v4l/biblio.rst
> +++ b/Documentation/media/uapi/v4l/biblio.rst
> @@ -115,6 +115,15 @@ ITU BT.1119
>  
>  :author:International Telecommunication Union (http://www.itu.ch)
>  
> +.. _h264:
> +
> +ITU H.264
> +=
> +
> +:title: ITU-T Recommendation H.264 "Advanced Video Coding for Generic 
> Audiovisual Services"
> +
> +:author:International Telecommunication Union (http://www.itu.ch)
> +
>  .. _jfif:
>  
>  JFIF
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> b/Documentation/media/uapi/v4l/extended-controls.rst
> index 65a1d873196b..87c0d151577f 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -1674,6 +1674,370 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>   non-intra-coded frames, in zigzag scanning order. Only relevant for
>   non-4:2:0 YUV formats.
>  
> +.. _v4l2-mpeg-h264:
> +
> +``V4L2_CID_MPEG_VIDEO_H264_SPS (struct)``
> +Specifies the sequence parameter set (as extracted from the
> +bitstream) for the associated H264 slice data. This includes the
> +necessary parameters for configuring a stateless hardware decoding
> +pipeline for H264.  The bitstream parameters are defined according
> +to :ref:`h264`. Unless there's a specific comment, refer to the
> +specification for the documentation of these fields.

If possible, please refer to the corresponding section(s) in the h264 spec
where this is documented. Same for the other controls.

> +
> +.. c:type:: v4l2_ctrl_h264_sps
> +
> +.. cssclass:: longtable
> +
> +.. flat-table:: struct v4l2_ctrl_h264_sps
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 1 2
> +
> +* - __u8
> +  - ``profile_idc``
> +  -
> +* - __u8
> +  - ``constraint_set_flags``
> +  - TODO
> +* - __u8
> +  - ``level_idc``
> +  -
> +* - __u8
> +  - ``seq_parameter_set_id``
> +  -
> +* - __u8
> +  - ``chroma_format_idc``
> +  -
> +* - __u8
> +  - ``bit_depth_luma_minus8``
> +  -
> +* - __u8
> +  - ``bit_depth_chroma_minus8``
> +  -
> +* - __u8
> +  - ``log2_max_frame_num_minus4``
> +  -
> +* - __u8
> +  - ``pic_order_cnt_type``
> +  -
> +* - __u8
> +  - ``log2_max_pic_order_cnt_lsb_minus4``
> +  -
> +* - __u8
> +  - ``max_num_ref_frames``
> +  -
> +* - __u8
> +  - ``num_ref_frames_in_pic_order_cnt_cycle``
> +  -
> +* - __s32
> +  - ``offset_for_ref_frame[255]``
> +  -
> +* - __s32
> +  - ``offset_for_non_ref_pic``
> +  -
> +* - __s32
> +  - ``offset_for_top_to_bottom_field``
> +  -
> +* - __u16
> +  - ``pic_width_in_mbs_minus1``
> +  -
> +* - __u16
> +  - ``pic_height_in_map_units_minus1``
> +  -
> +* - __u8
> +  - ``flags``
> +  - TODO
> +
> +``V4L2_CID_MPEG_VIDEO_H264_PPS (struct)``
> +Specifies the picture parameter set (as extracted from the
> +bitstream) for the associated H264 slice data. This includes the
> +necessary parameters for configuring a stateless hardware decoding
> +pipeline for H264.  The bitstream parameters are defined according
> +to :ref:`h264`. Unless there's a specific comment, refer to the
> +specification for the documentation of these fields.
> +
> +.. c:type:: v4l2_ctrl_h264_pps
> +
> +.. cssclass:: longtable
> +
> +.. flat-table:: struct v4l2_ctrl_h264_pps
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 1 2
> +
> +* - __u8
> +  - ``pic_parameter_set_id``
> +  -
> +* - __u8
> +  - ``seq_parameter_set_id``
>

Re: [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls

[Hans Verkuil]

On 11/23/18 14:02, Paul Kocialkowski wrote:
> This introduces the required definitions for HEVC decoding support with
> stateless VPUs. The controls associated to the HEVC slice format provide
> the required meta-data for decoding slices extracted from the bitstream.
> 
> This interface comes with the following limitations:
> * No custom quantization matrices (scaling lists);
> * Support for a single temporal layer only;
> * No slice entry point offsets support;
> * No conformance window support;
> * No VUI parameters support;
> * No support for SPS extensions: range, multilayer, 3d, scc, 4 bits;
> * No support for PPS extensions: range, multilayer, 3d, scc, 4 bits.

So if support for one or more of these items would have to be added,
would that be just new controls, or would it affect existing controls?

> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  Documentation/media/uapi/v4l/biblio.rst   |   9 +
>  .../media/uapi/v4l/extended-controls.rst  | 417 ++
>  .../media/uapi/v4l/pixfmt-compressed.rst  |  15 +
>  .../media/uapi/v4l/vidioc-queryctrl.rst   |  18 +
>  .../media/videodev2.h.rst.exceptions  |   3 +
>  drivers/media/v4l2-core/v4l2-ctrls.c  |  26 ++
>  drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
>  include/media/v4l2-ctrls.h|   6 +
>  include/uapi/linux/v4l2-controls.h| 155 +++
>  include/uapi/linux/v4l2-controls.h.rej| 187 

Huh? .rej?

>  include/uapi/linux/videodev2.h|   7 +
>  11 files changed, 657 insertions(+), 187 deletions(-)
>  delete mode 100644 include/uapi/linux/v4l2-controls.h.rej
> 
> diff --git a/Documentation/media/uapi/v4l/biblio.rst 
> b/Documentation/media/uapi/v4l/biblio.rst
> index 73aeb7ce47d2..59a98feca3a1 100644
> --- a/Documentation/media/uapi/v4l/biblio.rst
> +++ b/Documentation/media/uapi/v4l/biblio.rst
> @@ -124,6 +124,15 @@ ITU H.264
>  
>  :author:International Telecommunication Union (http://www.itu.ch)
>  
> +.. _hevc:
> +
> +ITU H.265/HEVC
> +==
> +
> +:title: ITU-T Rec. H.265 | ISO/IEC 23008-2 "High Efficiency Video Coding"
> +
> +:author:International Telecommunication Union (http://www.itu.ch), 
> International Organisation for Standardisation (http://www.iso.ch)
> +
>  .. _jfif:
>  
>  JFIF
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> b/Documentation/media/uapi/v4l/extended-controls.rst
> index 87c0d151577f..906ff4f32634 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -2038,6 +2038,423 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>- ``flags``
>-
>  
> +.. _v4l2-mpeg-hevc:
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_SPS (struct)``
> +Specifies the Sequence Parameter Set fields (as extracted from the
> +bitstream) for the associated HEVC slice data.
> +These bitstream parameters are defined according to :ref:`hevc`.
> +Refer to the specification for the documentation of these fields.

Same as for h264: if possible, refer to the section(s) in the spec that deal
with these fields.

> +
> +.. c:type:: v4l2_ctrl_hevc_sps
> +
> +.. cssclass:: longtable
> +
> +.. flat-table:: struct v4l2_ctrl_hevc_sps
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 1 2
> +
> +* - __u8
> +  - ``chroma_format_idc``
> +  -
> +* - __u8
> +  - ``separate_colour_plane_flag``
> +  -
> +* - __u16
> +  - ``pic_width_in_luma_samples``
> +  -
> +* - __u16
> +  - ``pic_height_in_luma_samples``
> +  -
> +* - __u8
> +  - ``bit_depth_luma_minus8``
> +  -
> +* - __u8
> +  - ``bit_depth_chroma_minus8``
> +  -
> +* - __u8
> +  - ``log2_max_pic_order_cnt_lsb_minus4``
> +  -
> +* - __u8
> +  - ``sps_max_dec_pic_buffering_minus1``
> +  -
> +* - __u8
> +  - ``sps_max_num_reorder_pics``
> +  -
> +* - __u8
> +  - ``sps_max_latency_increase_plus1``
> +  -
> +* - __u8
> +  - ``log2_min_luma_coding_block_size_minus3``
> +  -
> +* - __u8
> +  - ``log2_diff_max_min_luma_coding_block_size``
> +  -
> +* - __u8
> +  - ``log2_min_luma_transform_block_size_minus2``
> +  -
> +* - __u8
> +  - ``log2_diff_max_min_luma_transform_block_size``
> +  -
> +* - __u8
> +  - ``max_transform_hierarchy_depth_inter``
> +  -
> +* - __u8
> +  - ``max_transform_hierarchy_depth_intra``
> +  -
> +* - __u8
> +  - ``scaling_list_enabled_flag``
> +  -
> +* - __u8
> +  - ``amp_enabled_flag``
> +  -
> +* - __u8
> +  - ``sample_adaptive_offset_enabled_flag``
> +  -
> +* - __u8
> +  - ``pcm_enabled_flag``
> +  -
> +* - __u8
> +  - ``pcm_sample_bit_depth_luma_minus1``
> +  -
> +* - __u8
> +  - ``pcm_sample_bit_depth_chroma_minus1``
> +  -
> +* - __u8
> +  - ``log2_min_pcm_lum

[PATCH 4/5] si470x-i2c: Add optional reset-gpio support

[Paweł Chmiel]

If reset-gpio is defined, use it to bring device out of reset.
Without this, it's not possible to access si470x registers.

Signed-off-by: Paweł Chmiel 
---
 drivers/media/radio/si470x/radio-si470x-i2c.c | 15 +++
 drivers/media/radio/si470x/radio-si470x.h |  1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c 
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index a7ac09c55188..15eea2b2c90f 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "radio-si470x.h"
@@ -392,6 +393,17 @@ static int si470x_i2c_probe(struct i2c_client *client,
radio->videodev.release = video_device_release_empty;
video_set_drvdata(&radio->videodev, radio);
 
+   radio->gpio_reset = devm_gpiod_get_optional(&client->dev, "reset",
+   GPIOD_OUT_LOW);
+   if (IS_ERR(radio->gpio_reset)) {
+   retval = PTR_ERR(radio->gpio_reset);
+   dev_err(&client->dev, "Failed to request gpio: %d\n", retval);
+   goto err_all;
+   }
+
+   if (radio->gpio_reset)
+   gpiod_set_value(radio->gpio_reset, 1);
+
/* power up : need 110ms */
radio->registers[POWERCFG] = POWERCFG_ENABLE;
if (si470x_set_register(radio, POWERCFG) < 0) {
@@ -478,6 +490,9 @@ static int si470x_i2c_remove(struct i2c_client *client)
 
video_unregister_device(&radio->videodev);
 
+   if (radio->gpio_reset)
+   gpiod_set_value(radio->gpio_reset, 0);
+
return 0;
 }
 
diff --git a/drivers/media/radio/si470x/radio-si470x.h 
b/drivers/media/radio/si470x/radio-si470x.h
index 35fa0f3bbdd2..6fd6a399cb77 100644
--- a/drivers/media/radio/si470x/radio-si470x.h
+++ b/drivers/media/radio/si470x/radio-si470x.h
@@ -189,6 +189,7 @@ struct si470x_device {
 
 #if IS_ENABLED(CONFIG_I2C_SI470X)
struct i2c_client *client;
+   struct gpio_desc *gpio_reset;
 #endif
 };
 
-- 
2.17.1

[PATCH 5/5] media: dt-bindings: si470x: Document new reset-gpios property

[Paweł Chmiel]

Add information about new reset-gpios property to driver documentation

Signed-off-by: Paweł Chmiel 
---
 Documentation/devicetree/bindings/media/si470x.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/si470x.txt 
b/Documentation/devicetree/bindings/media/si470x.txt
index 9294fdfd3aae..a9403558362e 100644
--- a/Documentation/devicetree/bindings/media/si470x.txt
+++ b/Documentation/devicetree/bindings/media/si470x.txt
@@ -10,6 +10,7 @@ Required Properties:
 
 Optional Properties:
 - interrupts : The interrupt number
+- reset-gpios: GPIO specifier for the chips reset line
 
 Example:
 
@@ -20,5 +21,6 @@ Example:
 
 interrupt-parent = <&gpj2>;
 interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+reset-gpios = <&gpj2 5 GPIO_ACTIVE_HIGH>;
 };
 };
-- 
2.17.1

[PATCH 1/5] si470x-i2c: Add device tree support

[Paweł Chmiel]

This commit enables device tree support adding simple of_match table.

Signed-off-by: Paweł Chmiel 
---
 drivers/media/radio/si470x/radio-si470x-i2c.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c 
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index 9751ea1d80be..250828ddb5fa 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -527,6 +527,13 @@ static int si470x_i2c_resume(struct device *dev)
 static SIMPLE_DEV_PM_OPS(si470x_i2c_pm, si470x_i2c_suspend, si470x_i2c_resume);
 #endif
 
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id si470x_of_match[] = {
+   { .compatible = "silabs,si470x" },
+   { },
+};
+MODULE_DEVICE_TABLE(of, si470x_of_match);
+#endif
 
 /*
  * si470x_i2c_driver - i2c driver interface
@@ -534,6 +541,7 @@ static SIMPLE_DEV_PM_OPS(si470x_i2c_pm, si470x_i2c_suspend, 
si470x_i2c_resume);
 static struct i2c_driver si470x_i2c_driver = {
.driver = {
.name   = "si470x",
+   .of_match_table = of_match_ptr(si470x_of_match),
 #ifdef CONFIG_PM_SLEEP
.pm = &si470x_i2c_pm,
 #endif
-- 
2.17.1

[PATCH 2/5] media: dt-bindings: Add binding for si470x radio

[Paweł Chmiel]

Add device tree bindings for si470x family radio receiver driver.

Signed-off-by: Paweł Chmiel 
---
 .../devicetree/bindings/media/si470x.txt  | 24 +++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/si470x.txt

diff --git a/Documentation/devicetree/bindings/media/si470x.txt 
b/Documentation/devicetree/bindings/media/si470x.txt
new file mode 100644
index ..9294fdfd3aae
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/si470x.txt
@@ -0,0 +1,24 @@
+* Silicon Labs FM Radio receiver
+
+The Silicon Labs Si470x is family of FM radio receivers with receive power scan
+supporting 76-108 MHz, programmable through an I2C interface.
+Some of them includes an RDS encoder.
+
+Required Properties:
+- compatible: Should contain "silabs,si470x"
+- reg: the I2C address of the device
+
+Optional Properties:
+- interrupts : The interrupt number
+
+Example:
+
+&i2c2 {
+si470x@63 {
+compatible = "silabs,si470x";
+reg = <0x63>;
+
+interrupt-parent = <&gpj2>;
+interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+};
+};
-- 
2.17.1

[PATCH 3/5] si470x-i2c: Use managed resource helpers

[Paweł Chmiel]

Simplify cleanup of failures by using managed resource helpers

Signed-off-by: Paweł Chmiel 
---
 drivers/media/radio/si470x/radio-si470x-i2c.c | 29 +++
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c 
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index 250828ddb5fa..a7ac09c55188 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -350,7 +350,7 @@ static int si470x_i2c_probe(struct i2c_client *client,
unsigned char version_warning = 0;
 
/* private data allocation and initialization */
-   radio = kzalloc(sizeof(struct si470x_device), GFP_KERNEL);
+   radio = devm_kzalloc(&client->dev, sizeof(*radio), GFP_KERNEL);
if (!radio) {
retval = -ENOMEM;
goto err_initial;
@@ -370,7 +370,7 @@ static int si470x_i2c_probe(struct i2c_client *client,
retval = v4l2_device_register(&client->dev, &radio->v4l2_dev);
if (retval < 0) {
dev_err(&client->dev, "couldn't register v4l2_device\n");
-   goto err_radio;
+   goto err_initial;
}
 
v4l2_ctrl_handler_init(&radio->hdl, 2);
@@ -396,14 +396,14 @@ static int si470x_i2c_probe(struct i2c_client *client,
radio->registers[POWERCFG] = POWERCFG_ENABLE;
if (si470x_set_register(radio, POWERCFG) < 0) {
retval = -EIO;
-   goto err_ctrl;
+   goto err_all;
}
msleep(110);
 
/* get device and chip versions */
if (si470x_get_all_registers(radio) < 0) {
retval = -EIO;
-   goto err_ctrl;
+   goto err_all;
}
dev_info(&client->dev, "DeviceID=0x%4.4hx ChipID=0x%4.4hx\n",
radio->registers[DEVICEID], 
radio->registers[SI_CHIPID]);
@@ -430,10 +430,10 @@ static int si470x_i2c_probe(struct i2c_client *client,
 
/* rds buffer allocation */
radio->buf_size = rds_buf * 3;
-   radio->buffer = kmalloc(radio->buf_size, GFP_KERNEL);
+   radio->buffer = devm_kmalloc(&client->dev, radio->buf_size, GFP_KERNEL);
if (!radio->buffer) {
retval = -EIO;
-   goto err_ctrl;
+   goto err_all;
}
 
/* rds buffer configuration */
@@ -441,12 +441,13 @@ static int si470x_i2c_probe(struct i2c_client *client,
radio->rd_index = 0;
init_waitqueue_head(&radio->read_queue);
 
-   retval = request_threaded_irq(client->irq, NULL, si470x_i2c_interrupt,
-   IRQF_TRIGGER_FALLING | IRQF_ONESHOT, DRIVER_NAME,
-   radio);
+   retval = devm_request_threaded_irq(&client->dev, client->irq, NULL,
+  si470x_i2c_interrupt,
+  IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+  DRIVER_NAME, radio);
if (retval) {
dev_err(&client->dev, "Failed to register interrupt\n");
-   goto err_rds;
+   goto err_all;
}
 
/* register video device */
@@ -460,15 +461,9 @@ static int si470x_i2c_probe(struct i2c_client *client,
 
return 0;
 err_all:
-   free_irq(client->irq, radio);
-err_rds:
-   kfree(radio->buffer);
-err_ctrl:
v4l2_ctrl_handler_free(&radio->hdl);
 err_dev:
v4l2_device_unregister(&radio->v4l2_dev);
-err_radio:
-   kfree(radio);
 err_initial:
return retval;
 }
@@ -481,9 +476,7 @@ static int si470x_i2c_remove(struct i2c_client *client)
 {
struct si470x_device *radio = i2c_get_clientdata(client);
 
-   free_irq(client->irq, radio);
video_unregister_device(&radio->videodev);
-   kfree(radio);
 
return 0;
 }
-- 
2.17.1

[PATCH 0/5] media: radio-si470x-i2c: Add device tree and reset gpio support

[Paweł Chmiel]

This patchset adds support for device tree and reset-gpios
to si470x i2c radio driver.

First two patches adds and documents device tree support.
Third patch simplifies code by using managed resource helpers.
Last two patches adds and documents new optional reset gpios support.

It was tested on Samsung Galaxy S (i9000) phone.

Paweł Chmiel (5):
  si470x-i2c: Add device tree support
  media: dt-bindings: Add binding for si470x radio
  si470x-i2c: Use managed resource helpers
  si470x-i2c: Add optional reset-gpio support
  media: dt-bindings: si470x: Document new reset-gpios property

 .../devicetree/bindings/media/si470x.txt  | 26 ++
 drivers/media/radio/si470x/radio-si470x-i2c.c | 52 ---
 drivers/media/radio/si470x/radio-si470x.h |  1 +
 3 files changed, 61 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/si470x.txt

-- 
2.17.1

[PATCH] media: imx274: fix wrong order in test pattern menus

[Luca Ceresoli]

The description of test patterns 11 and 12 are swapped.

Checked against the live sensor.

Signed-off-by: Luca Ceresoli 
---
 drivers/media/i2c/imx274.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
index 5fac7fd32634..95e3d90309e8 100644
--- a/drivers/media/i2c/imx274.c
+++ b/drivers/media/i2c/imx274.c
@@ -207,8 +207,8 @@ static const char * const tp_qmenu[] = {
"Vertical Stripe (555h / 000h)",
"Vertical Stripe (000h / FFFh)",
"Vertical Stripe (FFFh / 000h)",
-   "Horizontal Color Bars",
"Vertical Color Bars",
+   "Horizontal Color Bars",
 };
 
 /*
-- 
2.17.1

[PATCH] media: v4l2-subdev: document controls need _FL_HAS_DEVNODE

[Luca Ceresoli]

Control events can be subscribed and received by the user. Therefore
drivers that support controls must expose the
V4L2_SUBDEV_FL_HAS_EVENTS flag.

[As discussed in https://lkml.org/lkml/2018/11/27/637]
Reported-by: Sakari Ailus 
Signed-off-by: Luca Ceresoli 
---
 include/media/v4l2-subdev.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 9102d6ca566e..47af609dc8f1 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -776,7 +776,11 @@ struct v4l2_subdev_internal_ops {
 #define V4L2_SUBDEV_FL_IS_SPI  (1U << 1)
 /* Set this flag if this subdev needs a device node. */
 #define V4L2_SUBDEV_FL_HAS_DEVNODE (1U << 2)
-/* Set this flag if this subdev generates events. */
+/*
+ * Set this flag if this subdev generates events.
+ * Note controls can send events, thus drivers exposing controls
+ * should set this flag.
+ */
 #define V4L2_SUBDEV_FL_HAS_EVENTS  (1U << 3)
 
 struct regulator_bulk_data;
-- 
2.17.1

Re: [PATCH] media: Kconfig: Add configuration entry for MEDIA_MEM2MEM_SUPPORT

[Mauro Carvalho Chehab]

Em Mon, 26 Nov 2018 18:38:44 +0200
Priit Laes  escreveu:

> Currently there is no easy way to enable mem2mem based video
> processor drivers (cedrus for example). Simplify this by adding
> separate category to media support.
> 
> Signed-off-by: Priit Laes 
> ---
>  drivers/media/Kconfig | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index 8add62a18293..f2a773896dcf 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -56,6 +56,14 @@ config MEDIA_DIGITAL_TV_SUPPORT
> Say Y when you have a board with digital support or a board with
> hybrid digital TV and analog TV.
>  
> +config MEDIA_MEM2MEM_SUPPORT
> +bool "Mem2mem devices (stateless media decoders/encoders support)"
> +---help---
> +   Enable support for mem2mem / stateless media decoders/encoders.
> +
> +   Say Y when you have a system with stateless media encoder/decoder
> +   support.
> +
>  config MEDIA_RADIO_SUPPORT
>   bool "AM/FM radio receivers/transmitters support"
>   ---help---
> @@ -95,7 +103,7 @@ 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
> + depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
> MEDIA_DIGITAL_TV_SUPPORT || MEDIA_MEM2MEM_SUPPORT
>   ---help---
> Enable the media controller API used to query media devices internal
> topology and configure it dynamically.
> @@ -118,7 +126,7 @@ config MEDIA_CONTROLLER_DVB
>  config VIDEO_DEV
>   tristate
>   depends on MEDIA_SUPPORT
> - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
> MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT
> + depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || 
> MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT || MEDIA_MEM2MEM_SUPPORT
>   default y
>  
>  config VIDEO_V4L2_SUBDEV_API

Hmm... this patch looks incomplete. I mean, the main goal of those
MEDIA_*_SUPPORT is to make simpler for the users to select a
subset of the drivers. Those options actually make visible
the corresponding entries for pci/usb/... drivers. So,
for example, drivers/media/usb/Kconfig contains:

if MEDIA_CAMERA_SUPPORT
comment "Webcam devices"
source "drivers/media/usb/uvc/Kconfig"
source "drivers/media/usb/gspca/Kconfig"
source "drivers/media/usb/pwc/Kconfig"
source "drivers/media/usb/cpia2/Kconfig"
source "drivers/media/usb/zr364xx/Kconfig"
source "drivers/media/usb/stkwebcam/Kconfig"
source "drivers/media/usb/s2255/Kconfig"
source "drivers/media/usb/usbtv/Kconfig"
endif

If we'll be adding it, I would expect a corresponding change at
drivers/media/platform/Kconfig.

Thanks,
Mauro

[PATCH] staging: media: imx: Use of_node_name_eq for node name comparisons

[Rob Herring]

Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.

For instances using of_node_cmp, this has the side effect of now using
case sensitive comparisons. This should not matter for any FDT based
system which this is.

Cc: Steve Longerbeam 
Cc: Philipp Zabel 
Cc: Mauro Carvalho Chehab 
Cc: Greg Kroah-Hartman 
Cc: linux-media@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Rob Herring 
---
 drivers/staging/media/imx/imx-media-of.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/imx/imx-media-of.c 
b/drivers/staging/media/imx/imx-media-of.c
index b2e840f96c50..a01327f6e045 100644
--- a/drivers/staging/media/imx/imx-media-of.c
+++ b/drivers/staging/media/imx/imx-media-of.c
@@ -162,7 +162,7 @@ int imx_media_create_csi_of_links(struct imx_media_dev 
*imxmd,
fwnode_property_read_u32(fwnode, "reg", &link.remote_port);
fwnode = fwnode_get_next_parent(fwnode);
if (is_of_node(fwnode) &&
-   of_node_cmp(to_of_node(fwnode)->name, "ports") == 0)
+   of_node_name_eq(to_of_node(fwnode), "ports"))
fwnode = fwnode_get_next_parent(fwnode);
link.remote_node = fwnode;
 
-- 
2.19.1

[PATCH] media: Use of_node_name_eq for node name comparisons

[Rob Herring]

Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.

Cc: Kyungmin Park 
Cc: Sylwester Nawrocki 
Cc: Mauro Carvalho Chehab 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Benoit Parrot 
Cc: Hyun Kwon 
Cc: Laurent Pinchart 
Cc: Michal Simek 
Cc: linux-media@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Rob Herring 
---
 drivers/media/platform/exynos4-is/media-dev.c | 12 ++--
 drivers/media/platform/ti-vpe/cal.c   |  4 ++--
 drivers/media/platform/xilinx/xilinx-tpg.c|  2 +-
 drivers/media/v4l2-core/v4l2-fwnode.c |  6 ++
 4 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
b/drivers/media/platform/exynos4-is/media-dev.c
index 870501b0f351..ced14af56606 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -445,7 +445,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
 */
np = of_get_parent(rem);
 
-   if (np && !of_node_cmp(np->name, "i2c-isp"))
+   if (of_node_name_eq(np, "i2c-isp"))
pd->fimc_bus_type = FIMC_BUS_TYPE_ISP_WRITEBACK;
else
pd->fimc_bus_type = pd->sensor_bus_type;
@@ -495,7 +495,7 @@ static int fimc_md_register_sensor_entities(struct fimc_md 
*fmd)
for_each_available_child_of_node(parent, node) {
struct device_node *port;
 
-   if (of_node_cmp(node->name, "csis"))
+   if (!of_node_name_eq(node, "csis"))
continue;
/* The csis node can have only port subnode. */
port = of_get_next_child(node, NULL);
@@ -720,13 +720,13 @@ static int fimc_md_register_platform_entities(struct 
fimc_md *fmd,
continue;
 
/* If driver of any entity isn't ready try all again later. */
-   if (!strcmp(node->name, CSIS_OF_NODE_NAME))
+   if (of_node_name_eq(node, CSIS_OF_NODE_NAME))
plat_entity = IDX_CSIS;
-   else if (!strcmp(node->name, FIMC_IS_OF_NODE_NAME))
+   else if (of_node_name_eq(node, FIMC_IS_OF_NODE_NAME))
plat_entity = IDX_IS_ISP;
-   else if (!strcmp(node->name, FIMC_LITE_OF_NODE_NAME))
+   else if (of_node_name_eq(node, FIMC_LITE_OF_NODE_NAME))
plat_entity = IDX_FLITE;
-   else if (!strcmp(node->name, FIMC_OF_NODE_NAME) &&
+   else if (of_node_name_eq(node, FIMC_OF_NODE_NAME) &&
 !of_property_read_bool(node, "samsung,lcd-wb"))
plat_entity = IDX_FIMC;
 
diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
index 95a093f41905..fc3c212b96e1 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -1615,7 +1615,7 @@ of_get_next_port(const struct device_node *parent,
return NULL;
}
prev = port;
-   } while (of_node_cmp(port->name, "port") != 0);
+   } while (!of_node_name_eq(port, "port"));
}
 
return port;
@@ -1635,7 +1635,7 @@ of_get_next_endpoint(const struct device_node *parent,
if (!ep)
return NULL;
prev = ep;
-   } while (of_node_cmp(ep->name, "endpoint") != 0);
+   } while (!of_node_name_eq(ep, "endpoint"));
 
return ep;
 }
diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c 
b/drivers/media/platform/xilinx/xilinx-tpg.c
index 851d20dcd550..ce686b8d6cff 100644
--- a/drivers/media/platform/xilinx/xilinx-tpg.c
+++ b/drivers/media/platform/xilinx/xilinx-tpg.c
@@ -725,7 +725,7 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
const struct xvip_video_format *format;
struct device_node *endpoint;
 
-   if (!port->name || of_node_cmp(port->name, "port"))
+   if (!of_node_name_eq(port, "port"))
continue;
 
format = xvip_of_get_format(port);
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index 218f0da0ce76..849326241b17 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -564,8 +564,7 @@ int v4l2_fwnode_parse_link(struct fwnode_handle *__fwnode,
fwnode = fwnode_get_parent(__fwnode);
fwnode_property_read_u32(fwnode, port_prop, &link->local_port);
fwnode = fwnode_get_next_parent(fwnode);
-   if (is_of_node(fwnode) &&
-   of_node_cmp(to_of_node(fwnode)->name, "ports") == 0)
+   if (is_of_node(fwnode) && of_node_name_eq(to_of_node(fwnode), "ports"))
fwnode = fwnode_get_next_parent(fwnode);
link