Re: [PATCH 05/11] [media] s5p-mfc: Add support for HEVC decoder

2017-02-01 Thread Andrzej Hajda
On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add support for codec definition and corresponding buffer
> requirements for HEVC decoder.
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |3 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|8 
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   18 --
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |5 +
>  6 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index 153ee68..a57009a 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -32,6 +32,9 @@
>  #define MFC_VERSION_V10  0xA0
>  #define MFC_NUM_PORTS_V101
>  
> +/* MFCv10 codec defines*/
> +#define S5P_FIMV_CODEC_HEVC_DEC  17
> +
>  /* Encoder buffer size for MFC v10.0 */
>  #define ENC_V100_H264_ME_SIZE(x, y)  \
>   (((x + 3) * (y + 3) * 8)\
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> index b1b1491..76eca67 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -101,6 +101,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx 
> *ctx)
>   case S5P_MFC_CODEC_VP8_DEC:
>   codec_type = S5P_FIMV_CODEC_VP8_DEC_V6;
>   break;
> + case S5P_MFC_CODEC_HEVC_DEC:
> + codec_type = S5P_FIMV_CODEC_HEVC_DEC;
> + break;
>   case S5P_MFC_CODEC_H264_ENC:
>   codec_type = S5P_FIMV_CODEC_H264_ENC_V6;
>   break;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 998e24b..5c46060 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -79,6 +79,7 @@ static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void 
> *b)
>  #define S5P_MFC_CODEC_H263_DEC   5
>  #define S5P_MFC_CODEC_VC1RCV_DEC 6
>  #define S5P_MFC_CODEC_VP8_DEC7
> +#define S5P_MFC_CODEC_HEVC_DEC   17
>  
>  #define S5P_MFC_CODEC_H264_ENC   20
>  #define S5P_MFC_CODEC_H264_MVC_ENC   21
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 784b28e..9f459b3 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -156,6 +156,14 @@
>   .versions   = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT |
>   MFC_V10_BIT,
>   },
> + {
> + .name   = "HEVC Encoded Stream",
> + .fourcc = V4L2_PIX_FMT_HEVC,
> + .codec_mode = S5P_FIMV_CODEC_HEVC_DEC,
> + .type   = MFC_FMT_DEC,
> + .num_planes = 1,
> + .versions   = MFC_V10_BIT,
> + },
>  };
>  
>  #define NUM_FORMATS ARRAY_SIZE(formats)
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index 369210a..b6cb280 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -220,6 +220,13 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>   S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);
>   ctx->bank1.size = ctx->scratch_buf_size;
>   break;
> + case S5P_MFC_CODEC_HEVC_DEC:
> + mfc_debug(2, "Use min scratch buffer size\n");
> + ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size, 256);

Again alignment of something which should be already aligned, and magic
number instead of S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6.

> + ctx->bank1.size =
> + ctx->scratch_buf_size +
> + (ctx->mv_count * ctx->mv_size);
> + break;
>   case S5P_MFC_CODEC_H264_ENC:
>   if (IS_MFCV10(dev)) {
>   mfc_debug(2, "Use min scratch buffer size\n");
> @@ -322,6 +329,7 @@ static int s5p_mfc_alloc_instance_buffer_v6(struct 
> s5p_mfc_ctx *ctx)
>   switch (ctx->codec_mode) {
>   case S5P_MFC_CODEC_H264_DEC:
>   case S5P_MFC_CODEC_H264_MVC_DEC:
> + case S5P_MFC_CODEC_HEVC_DEC:
>   ctx->ctx.size = buf_size->h264_dec_ctx;
>   break;
>   case S5P_MFC_CODEC_MPEG4_DEC:
> @@ -438,6 +446,10 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct 
> s5p_mfc_ctx *ctx)
>   ctx->img_height);
>   

Re: [PATCH 03/11] [media] s5p-mfc: Use min scratch buffer size

2017-02-01 Thread Andrzej Hajda
On 18.01.2017 11:02, Smitha T Murthy wrote:
> After MFC v8.0, mfc f/w lets the driver know how much scratch buffer
> size is required for decoder. If mfc f/w has the functionality,
> E_MIN_SCRATCH_BUFFER_SIZE, driver can know how much scratch buffer size
> is required for encoder too.

Subject says "Use min scratch buffer size" but it is already used.
Maybe it should be changed to sth like:
Use min scratch buffer size provided by F/W

>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v8.h|2 +
>  drivers/media/platform/s5p-mfc/s5p_mfc.c|2 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|7 ++
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|4 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   68 
> +--
>  6 files changed, 67 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> index 4d1c375..2cd396b 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> @@ -17,6 +17,7 @@
>  
>  /* Additional registers for v8 */
>  #define S5P_FIMV_D_MVC_NUM_VIEWS_V8  0xf104
> +#define S5P_FIMV_D_MIN_SCRATCH_BUFFER_SIZE_V80xf108
>  #define S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8   0xf144
>  #define S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V8  0xf148
>  #define S5P_FIMV_D_MV_BUFFER_SIZE_V8 0xf150
> @@ -84,6 +85,7 @@
>  
>  #define S5P_FIMV_E_VBV_BUFFER_SIZE_V80xf78c
>  #define S5P_FIMV_E_VBV_INIT_DELAY_V8 0xf790
> +#define S5P_FIMV_E_MIN_SCRATCH_BUFFER_SIZE_V8   0xf894
>  
>  #define S5P_FIMV_E_ASPECT_RATIO_V8   0xfb4c
>  #define S5P_FIMV_E_EXTENDED_SAR_V8   0xfb50
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index a043cce..b014038 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -520,6 +520,8 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx 
> *ctx,
>   dev);
>   ctx->mv_count = s5p_mfc_hw_call(dev->mfc_ops, get_mv_count,
>   dev);
> + ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
> + get_min_scratch_buf_size, dev);
>   if (ctx->img_width == 0 || ctx->img_height == 0)
>   ctx->state = MFCINST_ERROR;
>   else
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 1941c63..998e24b 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -724,6 +724,7 @@ struct mfc_control {
>  #define IS_MFCV7_PLUS(dev)   (dev->variant->version >= 0x70 ? 1 : 0)
>  #define IS_MFCV8_PLUS(dev)   (dev->variant->version >= 0x80 ? 1 : 0)
>  #define IS_MFCV10(dev)   (dev->variant->version >= 0xA0 ? 1 : 0)
> +#define FW_HAS_E_MIN_SCRATCH_BUF(dev) (IS_MFCV10(dev))
>  
>  #define MFC_V5_BIT   BIT(0)
>  #define MFC_V6_BIT   BIT(1)
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> index 9042378..ef15831 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> @@ -818,6 +818,13 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
>   get_enc_dpb_count, dev);
>   if (ctx->pb_count < enc_pb_count)
>   ctx->pb_count = enc_pb_count;
> + if (FW_HAS_E_MIN_SCRATCH_BUF(dev)) {
> + ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
> + get_e_min_scratch_buf_size, dev);
> + ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size,
> + S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);

Do we really need to align it here? Does firmware return unaligned value?
Even then the alignment (if necessary) should be moved rather to
get_e_min_scratch_buf_size.

> + ctx->bank1.size += ctx->scratch_buf_size;
> + }
>   ctx->state = MFCINST_HEAD_PRODUCED;
>   }
>  
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> index b6ac417..6478f70 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> @@ -169,6 +169,7 @@ struct s5p_mfc_regs {
>   void __iomem *d_decoded_third_addr;/* only v7 */
>   void __iomem *d_used_dpb_flag_upper;/* v7 and v8 */
>   void __iomem *d_used_dpb_flag_lower;/* v7 and v8 */
> + void __iomem *d_min_scratch_buffer_size; /* v10 */
>  
>   /* encoder registers */
>   

Re: [PATCHv2 08/16] atmel-isi: document device tree bindings

2017-02-01 Thread Sakari Ailus
Hi Rob,

On Wed, Feb 01, 2017 at 10:50:59AM -0600, Rob Herring wrote:
> > +   remote-endpoint = <_0>;
> > +   bus-width = <8>;
> > +   vsync-active = <1>;
> > +   hsync-active = <1>;
> 
> Which side of the connect is supposed to define these?

Today we have endpoint properties at each endpoint independently of the
remote endpoint. I guess you could obtain the endpoint properties from the
remote endpoint as well. There are exceptions though.

The configuration might not always be exactly the same. The parallel
interface is a little bit special: you could conceivably have a transmitter
with 8 wires but a receiver that could only use 10 or more. The wiring could
be such that the two most significant bits of the transmitter would be wired
to the two least significant bits on the receiver side. In this case the
bus-width property would have different values at each endpoint.

If we were to do something like that, it should be done everywhere and such
exceptions be handled somehow.

The CSI-2 lane mapping configuration (where supported by the hardware) is
also specific to an endpoint.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


cron job: media_tree daily build: ERRORS

2017-02-01 Thread 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 Feb  2 05:00:18 CET 2017
media-tree git hash:e7b3a2b22176d01db0c3b31d6389ccf542ba1967
media_build git hash:   3c6ce4ff75f19adf45869e34b376c5b9dee4d50a
v4l-utils git hash: 99306f20cc7e76cf2161e3059de4da245aed2130
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.0-164

linux-git-arm-at91: ERRORS
linux-git-arm-davinci: ERRORS
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: ERRORS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9-i686: ERRORS
linux-4.10-rc3-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9-x86_64: ERRORS
linux-4.10-rc3-x86_64: ERRORS
apps: WARNINGS
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] [media] exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT

2017-02-01 Thread Shuah Khan
On 01/24/2017 02:42 PM, Javier Martinez Canillas wrote:
> There isn't an ioctl to enum the supported field orders, so a user-space
> application can call VIDIOC_TRY_FMT using different field orders to know
> if one is supported. For example, GStreamer does this so during playback
> dozens of the following messages appear in the kernel log buffer:
> 
> [ 442.143393] Not supported field order(4)
> 
> Instead of printing this as an error, just keep it as debug information.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  drivers/media/platform/exynos-gsc/gsc-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 8524fe15fa80..678b600f0500 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -408,7 +408,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   if (pix_mp->field == V4L2_FIELD_ANY)
>   pix_mp->field = V4L2_FIELD_NONE;
>   else if (pix_mp->field != V4L2_FIELD_NONE) {
> - pr_err("Not supported field order(%d)\n", pix_mp->field);
> + pr_debug("Not supported field order(%d)\n", pix_mp->field);

It make sense to leave it as an error, but print only once perhaps.
The down side to making this debug is that it becomes harder to
figure out when we run into this case.

thanks,
-- Shuah

>   return -EINVAL;
>   }
>  
> 

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


Re: [PATCH v3 00/24] i.MX Media Driver

2017-02-01 Thread Steve Longerbeam



On 02/01/2017 01:30 AM, Philipp Zabel wrote:

On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
[...]

# Set pad formats
media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY/1920x1080]"
media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY2X8/1920x1080]"
media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/1920x1080]"
media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/1920x1080]"

v4l2-ctl -d /dev/video4 -V
# This still is configured to 640x480, which is inconsistent with
# the 'ipu1_csi0':2 pad format. The pad set_fmt above should
# have set this, too.

Because you've only configured the source pads,
and not the sink pads. The ipu_csi source format is
dependent on the sink format - output crop window is
limited by max input sensor frame, and since sink pad is
still at 640x480, output is reduced to that.

No, it is set (see below). What happens is that capture_g_fmt_vid_cap
just returns the capture devices' priv->vdev.fmt, even if it is
incompatible with the connected csi subdevice's output pad format.

priv->vdev.fmt was never changed from the default set in
imx_media_capture_device_register, because capture_s/try_fmt_vid_cap
were not called yet.


Ah, yep, this is a bug. Need to modify the capture device's
width/height at .set_fmt() in the subdev's device-node source
pad (csi and prpenc/vf).


Maybe I'm missing something, is it expected behavior that
a source format should be automatically propagated to
the sink?

media-ctl propagates the output pad format to all remote subdevices'
input pads for all enabled links:

https://git.linuxtv.org/v4l-utils.git/tree/utils/media-ctl/libv4l2subdev.c#n693


Ah cool, I wasn't aware media-ctl did this, but it makes sense and
makes it easier on the user.

Steve




v4l2-ctl --list-formats -d /dev/video4
# This lists all the RGB formats, which it shouldn't. There is
# no CSC in this pipeline, so we should be limited to YUV formats
# only.

right, need to fix that. Probably by poking the attached
source subdev (csi or prpenc/vf) for its supported formats.

You are right, in bayer/raw mode only one specific format should be
listed, depending on the CSI output pad format.

regards
Philipp



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


Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

2017-02-01 Thread Steve Longerbeam



On 02/01/2017 03:44 PM, Russell King - ARM Linux wrote:

On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:

+static int imxcsi2_get_fmt(struct v4l2_subdev *sd,
+  struct v4l2_subdev_pad_config *cfg,
+  struct v4l2_subdev_format *sdformat)
+{
+   struct imxcsi2_dev *csi2 = sd_to_dev(sd);
+
+   sdformat->format = csi2->format_mbus;
+
+   return 0;
+}

Hi Steve,

This isn't correct, and I suspect the other get_fmt implementations are
the same - I've just checked imx-csi.c, and that also appears to have
the same issue.

When get_fmt() is called with sdformat->which == V4L2_SUBDEV_FORMAT_TRY,
you need to return the try format rather than the current format.  See
the second paragraph of Documentation/media/uapi/v4l/dev-subdev.rst's
"Format Negotiation" section, where it talks about using
V4L2_SUBDEV_FORMAT_TRY with both VIDIOC_SUBDEV_G_FMT and
VIDIOC_SUBDEV_S_FMT.


Yes that's wrong. I'll fix.

Btw I read over Documentation/media/uapi/v4l/dev-subdev.rst (can't
remember if I ever did!), and it clears up a lot. I do see I'm doing some
other things wrong as well:

-  Formats should be propagated from sink pads to source pads. Modifying
   a format on a source pad should not modify the format on any sink
   pad.

I don't believe I'm affecting the source pad formats during sink pad
negotiation, or vice-versa, yet. But I will, once the pixel width alignment
optimization is implemented based on whether the output format is planar.
And I'll keep this direction-of-propagation rule in mind when I do so.

-  Sub-devices that scale frames using variable scaling factors should
   reset the scale factors to default values when sink pads formats are
   modified. If the 1:1 scaling ratio is supported, this means that
   source pads formats should be reset to the sink pads formats.

I'm not resetting the scaling factors on sink pad format change in
the scaling subdevs (imx-ic-prpenc and imx-ic-prpvf). Will fix that.

Steve

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


Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

2017-02-01 Thread Russell King - ARM Linux
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> +static int imxcsi2_get_fmt(struct v4l2_subdev *sd,
> +struct v4l2_subdev_pad_config *cfg,
> +struct v4l2_subdev_format *sdformat)
> +{
> + struct imxcsi2_dev *csi2 = sd_to_dev(sd);
> +
> + sdformat->format = csi2->format_mbus;
> +
> + return 0;
> +}

Hi Steve,

This isn't correct, and I suspect the other get_fmt implementations are
the same - I've just checked imx-csi.c, and that also appears to have
the same issue.

When get_fmt() is called with sdformat->which == V4L2_SUBDEV_FORMAT_TRY,
you need to return the try format rather than the current format.  See
the second paragraph of Documentation/media/uapi/v4l/dev-subdev.rst's
"Format Negotiation" section, where it talks about using
V4L2_SUBDEV_FORMAT_TRY with both VIDIOC_SUBDEV_G_FMT and
VIDIOC_SUBDEV_S_FMT.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] Documentation: devicetree: meson-ir: "linux,rc-map-name" is supported

2017-02-01 Thread Sean Young
On Wed, Feb 01, 2017 at 11:26:14PM +0100, Martin Blumenstingl wrote:
> On Wed, Feb 1, 2017 at 11:14 PM, Martin Blumenstingl
>  wrote:
> > The driver already parses the "linux,rc-map-name" property. Add this
> > information to the documentation so .dts maintainers don't have to look
> > it up in the source-code.
> >
> > Signed-off-by: Martin Blumenstingl 
> > Acked-by: Rob Herring 
> > ---
> > Changes since v1:
> > - removed character which shows up as whitespace from subject
> I have verified that I really sent this without a whitespace (I'm
> using git send-email, so the patch is not mangled by some webmailer) -
> unfortunately it seems to appear again (maybe one of the receiving
> mail-servers or the mailing-list software does something weird here).
> 
> @Mauro: can you handle this when you merge the patch - or do you want
> me to push this to some git repo from which you can pull?

I'll apply it to my rc-tree and fix up any problems.


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


Re: [PATCH v2] Documentation: devicetree: meson-ir: "linux,rc-map-name" is supported

2017-02-01 Thread Martin Blumenstingl
On Wed, Feb 1, 2017 at 11:14 PM, Martin Blumenstingl
 wrote:
> The driver already parses the "linux,rc-map-name" property. Add this
> information to the documentation so .dts maintainers don't have to look
> it up in the source-code.
>
> Signed-off-by: Martin Blumenstingl 
> Acked-by: Rob Herring 
> ---
> Changes since v1:
> - removed character which shows up as whitespace from subject
I have verified that I really sent this without a whitespace (I'm
using git send-email, so the patch is not mangled by some webmailer) -
unfortunately it seems to appear again (maybe one of the receiving
mail-servers or the mailing-list software does something weird here).

@Mauro: can you handle this when you merge the patch - or do you want
me to push this to some git repo from which you can pull?

> - added Rob Herring's ACK
>
>  Documentation/devicetree/bindings/media/meson-ir.txt | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt 
> b/Documentation/devicetree/bindings/media/meson-ir.txt
> index e7e3f3c4fc8f..efd9d29a8f10 100644
> --- a/Documentation/devicetree/bindings/media/meson-ir.txt
> +++ b/Documentation/devicetree/bindings/media/meson-ir.txt
> @@ -8,6 +8,9 @@ Required properties:
>   - reg : physical base address and length of the device registers
>   - interrupts  : a single specifier for the interrupt from the device
>
> +Optional properties:
> + - linux,rc-map-name:  see rc.txt file in the same directory.
> +
>  Example:
>
> ir-receiver@c8100480 {
> --
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2] Documentation: devicetree: meson-ir: "linux,rc-map-name" is supported

2017-02-01 Thread Martin Blumenstingl
The driver already parses the "linux,rc-map-name" property. Add this
information to the documentation so .dts maintainers don't have to look
it up in the source-code.

Signed-off-by: Martin Blumenstingl 
Acked-by: Rob Herring 
---
Changes since v1:
- removed character which shows up as whitespace from subject
- added Rob Herring's ACK

 Documentation/devicetree/bindings/media/meson-ir.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt 
b/Documentation/devicetree/bindings/media/meson-ir.txt
index e7e3f3c4fc8f..efd9d29a8f10 100644
--- a/Documentation/devicetree/bindings/media/meson-ir.txt
+++ b/Documentation/devicetree/bindings/media/meson-ir.txt
@@ -8,6 +8,9 @@ Required properties:
  - reg : physical base address and length of the device registers
  - interrupts  : a single specifier for the interrupt from the device
 
+Optional properties:
+ - linux,rc-map-name:  see rc.txt file in the same directory.
+
 Example:
 
ir-receiver@c8100480 {
-- 
2.11.0

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


[PATCH] add Hama Hybrid DVB-T Stick support

2017-02-01 Thread Piotr Oleszczyk
Adding Hama Hybrid DVB-T Stick support. Technically it's the same
device what Terratec Cinergy HT USB XE is.

Signed-off-by: Piotr Oleszczyk 

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 779f422..c90c344 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -78,6 +78,7 @@
 #define USB_VID_EVOLUTEPC  0x1e59
 #define USB_VID_AZUREWAVE  0x13d3
 #define USB_VID_TECHNISAT  0x14f7
+#define USB_VID_HAMA   0x147f

 /* Product IDs */
 #define USB_PID_ADSTECH_USB2_COLD  0xa333
@@ -413,4 +414,5 @@
 #define USB_PID_TURBOX_DTT_2000 0xd3a4
 #define USB_PID_WINTV_SOLOHD0x0264
 #define USB_PID_EVOLVEO_XTRATV_STICK   0xa115
+#define USB_PID_HAMA_DVBT_HYBRID_STICK 0x2758
 #endif
diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index b29d489..81d7fd4 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -3815,6 +3815,7 @@ struct usb_device_id dib0700_usb_id_table[] = {
{ USB_DEVICE(USB_VID_PCTV,  USB_PID_PCTV_2002E_SE) },
{ USB_DEVICE(USB_VID_PCTV,  USB_PID_DIBCOM_STK8096PVR) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK8096PVR) },
+   { USB_DEVICE(USB_VID_HAMA,  USB_PID_HAMA_DVBT_HYBRID) },
{ 0 }   /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -4379,7 +4380,7 @@ struct dvb_usb_device_properties dib0700_devices[] = {
},
},

-   .num_device_descs = 9,
+   .num_device_descs = 10,
.devices = {
{   "Terratec Cinergy HT USB XE",
{ _usb_id_table[27], NULL },
@@ -4417,6 +4418,10 @@ struct dvb_usb_device_properties dib0700_devices[] = {
{ _usb_id_table[54], NULL },
{ NULL },
},
+   {   "Hama DVB=T Hybrid USB Stick",
+   { _usb_id_table[85], NULL },
+   { NULL },
+   },
},

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


Re: [PATCH] doc-rst: fixed cleandoc target when used with O=dir

2017-02-01 Thread Jonathan Corbet
On Tue, 31 Jan 2017 10:57:41 +0100
Markus Heiser  wrote:

> The cleandocs target won't work if I use a different output folder::
> 
>   $ make O=/tmp/kernel SPHINXDIRS="process" cleandocs
>   make[1]: Entering directory '/tmp/kernel'
>   make[3]: *** No rule to make target 'clean'.  Stop.
>   ... Documentation/Makefile.sphinx:100: recipe for target 'cleandocs' failed

Applied, thanks.

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


[PATCH 2/2] [media] exynos-gsc: Add support for NV{16,21,61}M pixel formats

2017-02-01 Thread Javier Martinez Canillas
From: Thibault Saunier 

Those are useful formats that should be handled.

Signed-off-by: Thibault Saunier 
Signed-off-by: Javier Martinez Canillas 

---

 drivers/media/platform/exynos-gsc/gsc-core.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index a846659ae5c1..eff636d4502b 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -112,6 +112,15 @@ static const struct gsc_fmt gsc_formats[] = {
.num_planes = 1,
.num_comp   = 2,
}, {
+   .name   = "YUV 4:2:2 non-contig, Y/CbCr",
+   .pixelformat= V4L2_PIX_FMT_NV16M,
+   .depth  = { 8, 8 },
+   .color  = GSC_YUV422,
+   .yorder = GSC_LSB_Y,
+   .corder = GSC_CBCR,
+   .num_planes = 2,
+   .num_comp   = 2,
+   }, {
.name   = "YUV 4:2:2 planar, Y/CrCb",
.pixelformat= V4L2_PIX_FMT_NV61,
.depth  = { 16 },
@@ -121,6 +130,15 @@ static const struct gsc_fmt gsc_formats[] = {
.num_planes = 1,
.num_comp   = 2,
}, {
+   .name   = "YUV 4:2:2 non-contig, Y/CrCb",
+   .pixelformat= V4L2_PIX_FMT_NV61M,
+   .depth  = { 8, 8 },
+   .color  = GSC_YUV422,
+   .yorder = GSC_LSB_Y,
+   .corder = GSC_CRCB,
+   .num_planes = 2,
+   .num_comp   = 2,
+   }, {
.name   = "YUV 4:2:0 planar, YCbCr",
.pixelformat= V4L2_PIX_FMT_YUV420,
.depth  = { 12 },
@@ -158,6 +176,15 @@ static const struct gsc_fmt gsc_formats[] = {
.num_planes = 1,
.num_comp   = 2,
}, {
+   .name   = "YUV 4:2:0 non-contig. 2p, Y/CrCb",
+   .pixelformat= V4L2_PIX_FMT_NV21M,
+   .depth  = { 8, 4 },
+   .color  = GSC_YUV420,
+   .yorder = GSC_LSB_Y,
+   .corder = GSC_CRCB,
+   .num_planes = 2,
+   .num_comp   = 2,
+   }, {
.name   = "YUV 4:2:0 non-contig. 2p, Y/CbCr",
.pixelformat= V4L2_PIX_FMT_NV12M,
.depth  = { 8, 4 },
-- 
2.7.4

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


[PATCH 0/2] [media] exynos-gsc: Fix support for NV21 and NV61 formats

2017-02-01 Thread Javier Martinez Canillas
Hello,

Commit 652bb68018a5 ("[media] exynos-gsc: do proper bytesperline and
sizeimage calculation") fixed corrupted frames for most exynos-gsc
formats, but even after that patch two issues were still remaining:

1) Frames were still not correct for NV21 and NV61 formats.
2) Y42B format didn't work when used as output (only as input).

This patch series fixes (1).

Best regards,
Javier


Thibault Saunier (2):
  [media] exynos-gsc: Do not swap cb/cr for semi planar formats
  [media] exynos-gsc: Add support for NV{16,21,61}M pixel formats

 drivers/media/platform/exynos-gsc/gsc-core.c | 29 ++--
 1 file changed, 27 insertions(+), 2 deletions(-)

-- 
2.7.4

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


[PATCH 1/2] [media] exynos-gsc: Do not swap cb/cr for semi planar formats

2017-02-01 Thread Javier Martinez Canillas
From: Thibault Saunier 

In the case of semi planar formats cb and cr are in the same plane
in memory, meaning that will be set to 'cb' whatever the format is,
and whatever the (packed) order of those components are.

Suggested-by: Nicolas Dufresne 
Signed-off-by: Thibault Saunier 
Signed-off-by: Javier Martinez Canillas 
---

 drivers/media/platform/exynos-gsc/gsc-core.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 40aff08dd51d..a846659ae5c1 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -861,9 +861,7 @@ int gsc_prepare_addr(struct gsc_ctx *ctx, struct vb2_buffer 
*vb,
 
if ((frame->fmt->pixelformat == V4L2_PIX_FMT_VYUY) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVYU) ||
-   (frame->fmt->pixelformat == V4L2_PIX_FMT_NV61) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420) ||
-   (frame->fmt->pixelformat == V4L2_PIX_FMT_NV21) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420M))
swap(addr->cb, addr->cr);
 
-- 
2.7.4

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


Re: [PATCH v3 18/24] media: imx: Add SMFC subdev driver

2017-02-01 Thread Steve Longerbeam



On 02/01/2017 10:39 AM, Russell King - ARM Linux wrote:

Hi Steve,

On Fri, Jan 06, 2017 at 06:11:36PM -0800, Steve Longerbeam wrote:

+/*
+ * Min/Max supported width and heights.
+ *
+ * We allow planar output from the SMFC, so we have to align
+ * output width by 16 pixels to meet IDMAC alignment requirements,
+ * which also means input width must have the same alignment.
+ */
+#define MIN_W   176
+#define MIN_H   144
+#define MAX_W  8192
+#define MAX_H  4096
+#define W_ALIGN4 /* multiple of 16 pixels */

Does this only apply to planar formats?

I notice Philipp's driver allows 8 pixel alignment.  If it's only for
planar formats, it ought to determine the alignment based on the
requested format rather than hard-coding it to the maximum alignment
of all the supported formats.


yeah, I got lazy/tired there. I will fix this.

Steve

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


Re: [PATCH v3 18/24] media: imx: Add SMFC subdev driver

2017-02-01 Thread Russell King - ARM Linux
Hi Steve,

On Fri, Jan 06, 2017 at 06:11:36PM -0800, Steve Longerbeam wrote:
> +/*
> + * Min/Max supported width and heights.
> + *
> + * We allow planar output from the SMFC, so we have to align
> + * output width by 16 pixels to meet IDMAC alignment requirements,
> + * which also means input width must have the same alignment.
> + */
> +#define MIN_W   176
> +#define MIN_H   144
> +#define MAX_W  8192
> +#define MAX_H  4096
> +#define W_ALIGN4 /* multiple of 16 pixels */

Does this only apply to planar formats?

I notice Philipp's driver allows 8 pixel alignment.  If it's only for
planar formats, it ought to determine the alignment based on the
requested format rather than hard-coding it to the maximum alignment
of all the supported formats.

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [STLinux Kernel] [PATCH v6 02/10] ARM: dts: STiH410: add DELTA dt node

2017-02-01 Thread Peter Griffin
On Wed, 01 Feb 2017, Hugues Fruchet wrote:

> This patch adds DT node for STMicroelectronics
> DELTA V4L2 video decoder
> 
> Signed-off-by: Hugues Fruchet 
> ---
>  arch/arm/boot/dts/stih410.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
> index 281a124..42e070c 100644
> --- a/arch/arm/boot/dts/stih410.dtsi
> +++ b/arch/arm/boot/dts/stih410.dtsi
> @@ -259,5 +259,15 @@
>   clocks = <_sysin>;
>   interrupts = ;
>   };
> + delta0 {
> + compatible = "st,st-delta";
> + clock-names = "delta",
> +   "delta-st231",
> +   "delta-flash-promip";
> + clocks = <_s_c0_flexgen CLK_VID_DMU>,
> +  <_s_c0_flexgen CLK_ST231_DMU>,
> +  <_s_c0_flexgen CLK_FLASH_PROMIP>;
> + };
> +

I think this node should be in stih407-family.dtsi file?

regards,

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


Re: [STLinux Kernel] [PATCH v6 06/10] [media] st-delta: add memory allocator helper functions

2017-02-01 Thread Peter Griffin
On Wed, 01 Feb 2017, Hugues Fruchet wrote:

> Helper functions used by decoder back-ends to allocate
> physically contiguous memory required by hardware video
> decoder.
> 
> Signed-off-by: Hugues Fruchet 

Acked-by: Peter Griffin 

> ---
>  drivers/media/platform/sti/delta/Makefile|  2 +-
>  drivers/media/platform/sti/delta/delta-mem.c | 51 
> 
>  drivers/media/platform/sti/delta/delta-mem.h | 14 
>  drivers/media/platform/sti/delta/delta.h |  8 +
>  4 files changed, 74 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/platform/sti/delta/delta-mem.c
>  create mode 100644 drivers/media/platform/sti/delta/delta-mem.h
> 
> diff --git a/drivers/media/platform/sti/delta/Makefile 
> b/drivers/media/platform/sti/delta/Makefile
> index 467519e..93a3037 100644
> --- a/drivers/media/platform/sti/delta/Makefile
> +++ b/drivers/media/platform/sti/delta/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_VIDEO_STI_DELTA_DRIVER) := st-delta.o
> -st-delta-y := delta-v4l2.o
> +st-delta-y := delta-v4l2.o delta-mem.o
> diff --git a/drivers/media/platform/sti/delta/delta-mem.c 
> b/drivers/media/platform/sti/delta/delta-mem.c
> new file mode 100644
> index 000..d7b53d3
> --- /dev/null
> +++ b/drivers/media/platform/sti/delta/delta-mem.c
> @@ -0,0 +1,51 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2015
> + * Author: Hugues Fruchet  for STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#include "delta.h"
> +#include "delta-mem.h"
> +
> +int hw_alloc(struct delta_ctx *ctx, u32 size, const char *name,
> +  struct delta_buf *buf)
> +{
> + struct delta_dev *delta = ctx->dev;
> + dma_addr_t dma_addr;
> + void *addr;
> + unsigned long attrs = DMA_ATTR_WRITE_COMBINE;
> +
> + addr = dma_alloc_attrs(delta->dev, size, _addr,
> +GFP_KERNEL | __GFP_NOWARN, attrs);
> + if (!addr) {
> + dev_err(delta->dev,
> + "%s hw_alloc:dma_alloc_coherent failed for %s 
> (size=%d)\n",
> + ctx->name, name, size);
> + ctx->sys_errors++;
> + return -ENOMEM;
> + }
> +
> + buf->size = size;
> + buf->paddr = dma_addr;
> + buf->vaddr = addr;
> + buf->name = name;
> + buf->attrs = attrs;
> +
> + dev_dbg(delta->dev,
> + "%s allocate %d bytes of HW memory @(virt=0x%p, phy=0x%pad): 
> %s\n",
> + ctx->name, size, buf->vaddr, >paddr, buf->name);
> +
> + return 0;
> +}
> +
> +void hw_free(struct delta_ctx *ctx, struct delta_buf *buf)
> +{
> + struct delta_dev *delta = ctx->dev;
> +
> + dev_dbg(delta->dev,
> + "%s free %d bytes of HW memory @(virt=0x%p, phy=0x%pad): 
> %s\n",
> + ctx->name, buf->size, buf->vaddr, >paddr, buf->name);
> +
> + dma_free_attrs(delta->dev, buf->size,
> +buf->vaddr, buf->paddr, buf->attrs);
> +}
> diff --git a/drivers/media/platform/sti/delta/delta-mem.h 
> b/drivers/media/platform/sti/delta/delta-mem.h
> new file mode 100644
> index 000..f8ca109
> --- /dev/null
> +++ b/drivers/media/platform/sti/delta/delta-mem.h
> @@ -0,0 +1,14 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2015
> + * Author: Hugues Fruchet  for STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#ifndef DELTA_MEM_H
> +#define DELTA_MEM_H
> +
> +int hw_alloc(struct delta_ctx *ctx, u32 size, const char *name,
> +  struct delta_buf *buf);
> +void hw_free(struct delta_ctx *ctx, struct delta_buf *buf);
> +
> +#endif /* DELTA_MEM_H */
> diff --git a/drivers/media/platform/sti/delta/delta.h 
> b/drivers/media/platform/sti/delta/delta.h
> index 74a4240..9e26525 100644
> --- a/drivers/media/platform/sti/delta/delta.h
> +++ b/drivers/media/platform/sti/delta/delta.h
> @@ -191,6 +191,14 @@ struct delta_dts {
>   u64 val;
>  };
>  
> +struct delta_buf {
> + u32 size;
> + void *vaddr;
> + dma_addr_t paddr;
> + const char *name;
> + unsigned long attrs;
> +};
> +
>  struct delta_ctx;
>  
>  /*
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [STLinux Kernel] [PATCH v6 08/10] [media] st-delta: EOS (End Of Stream) support

2017-02-01 Thread Peter Griffin
On Wed, 01 Feb 2017, Hugues Fruchet wrote:

> EOS (End Of Stream) support allows user to get
> all the potential decoded frames remaining in decoder
> pipeline after having reached the end of video bitstream.
> To do so, user calls VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP)
> which will drain the decoder and get the drained frames
> that are then returned to user.
> User is informed of EOS completion in two ways:
>  - dequeue of an empty frame flagged to V4L2_BUF_FLAG_LAST
>  - reception of a V4L2_EVENT_EOS event.
> If, unfortunately, no buffer is available on CAPTURE queue
> to return the empty frame, EOS is delayed till user queue
> one CAPTURE buffer.
> 
> Signed-off-by: Hugues Fruchet 

Acked-by: Peter Griffin 

> ---
>  drivers/media/platform/sti/delta/delta-v4l2.c | 146 
> +-
>  drivers/media/platform/sti/delta/delta.h  |  23 
>  2 files changed, 168 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/sti/delta/delta-v4l2.c 
> b/drivers/media/platform/sti/delta/delta-v4l2.c
> index 237a938..c959614 100644
> --- a/drivers/media/platform/sti/delta/delta-v4l2.c
> +++ b/drivers/media/platform/sti/delta/delta-v4l2.c
> @@ -106,7 +106,8 @@ static void delta_frame_done(struct delta_ctx *ctx, 
> struct delta_frame *frame,
>   vbuf->sequence = ctx->frame_num++;
>   v4l2_m2m_buf_done(vbuf, err ? VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
>  
> - ctx->output_frames++;
> + if (frame->info.size) /* ignore EOS */
> + ctx->output_frames++;
>  }
>  
>  static void requeue_free_frames(struct delta_ctx *ctx)
> @@ -762,6 +763,135 @@ static int delta_g_selection(struct file *file, void 
> *fh,
>   return 0;
>  }
>  
> +static void delta_complete_eos(struct delta_ctx *ctx,
> +struct delta_frame *frame)
> +{
> + struct delta_dev *delta = ctx->dev;
> + const struct v4l2_event ev = {.type = V4L2_EVENT_EOS};
> +
> + /*
> +  * Send EOS to user:
> +  * - by returning an empty frame flagged to V4L2_BUF_FLAG_LAST
> +  * - and then send EOS event
> +  */
> +
> + /* empty frame */
> + frame->info.size = 0;
> +
> + /* set the last buffer flag */
> + frame->flags |= V4L2_BUF_FLAG_LAST;
> +
> + /* release frame to user */
> + delta_frame_done(ctx, frame, 0);
> +
> + /* send EOS event */
> + v4l2_event_queue_fh(>fh, );
> +
> + dev_dbg(delta->dev, "%s EOS completed\n", ctx->name);
> +}
> +
> +static int delta_try_decoder_cmd(struct file *file, void *fh,
> +  struct v4l2_decoder_cmd *cmd)
> +{
> + if (cmd->cmd != V4L2_DEC_CMD_STOP)
> + return -EINVAL;
> +
> + if (cmd->flags & V4L2_DEC_CMD_STOP_TO_BLACK)
> + return -EINVAL;
> +
> + if (!(cmd->flags & V4L2_DEC_CMD_STOP_IMMEDIATELY) &&
> + (cmd->stop.pts != 0))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int delta_decoder_stop_cmd(struct delta_ctx *ctx, void *fh)
> +{
> + const struct delta_dec *dec = ctx->dec;
> + struct delta_dev *delta = ctx->dev;
> + struct delta_frame *frame = NULL;
> + int ret = 0;
> +
> + dev_dbg(delta->dev, "%s EOS received\n", ctx->name);
> +
> + if (ctx->state != DELTA_STATE_READY)
> + return 0;
> +
> + /* drain the decoder */
> + call_dec_op(dec, drain, ctx);
> +
> + /* release to user drained frames */
> + while (1) {
> + frame = NULL;
> + ret = call_dec_op(dec, get_frame, ctx, );
> + if (ret == -ENODATA) {
> + /* no more decoded frames */
> + break;
> + }
> + if (frame) {
> + dev_dbg(delta->dev, "%s drain frame[%d]\n",
> + ctx->name, frame->index);
> +
> + /* pop timestamp and mark frame with it */
> + delta_pop_dts(ctx, >dts);
> +
> + /* release decoded frame to user */
> + delta_frame_done(ctx, frame, 0);
> + }
> + }
> +
> + /* try to complete EOS */
> + ret = delta_get_free_frame(ctx, );
> + if (ret)
> + goto delay_eos;
> +
> + /* new frame available, EOS can now be completed */
> + delta_complete_eos(ctx, frame);
> +
> + ctx->state = DELTA_STATE_EOS;
> +
> + return 0;
> +
> +delay_eos:
> + /*
> +  * EOS completion from driver is delayed because
> +  * we don't have a free empty frame available.
> +  * EOS completion is so delayed till next frame_queue() call
> +  * to be sure to have a free empty frame available.
> +  */
> + ctx->state = DELTA_STATE_WF_EOS;
> + dev_dbg(delta->dev, "%s EOS delayed\n", ctx->name);
> +
> + return 0;
> +}
> +
> +static int delta_decoder_cmd(struct file *file, void *fh,
> +  struct v4l2_decoder_cmd *cmd)
> +{
> + struct 

Re: [STLinux Kernel] [PATCH v6 05/10] [media] st-delta: STiH4xx multi-format video decoder v4l2 driver

2017-02-01 Thread Peter Griffin
On Wed, 01 Feb 2017, Hugues Fruchet wrote:

> This V4L2 driver enables DELTA multi-format video decoder
> of STMicroelectronics STiH4xx SoC series.
> 
> Signed-off-by: Hugues Fruchet 

Acked-by: Peter Griffin 

> ---
>  drivers/media/platform/Kconfig|   28 +
>  drivers/media/platform/Makefile   |2 +
>  drivers/media/platform/sti/delta/Makefile |2 +
>  drivers/media/platform/sti/delta/delta-cfg.h  |   61 +
>  drivers/media/platform/sti/delta/delta-v4l2.c | 1813 
> +
>  drivers/media/platform/sti/delta/delta.h  |  514 +++
>  6 files changed, 2420 insertions(+)
>  create mode 100644 drivers/media/platform/sti/delta/Makefile
>  create mode 100644 drivers/media/platform/sti/delta/delta-cfg.h
>  create mode 100644 drivers/media/platform/sti/delta/delta-v4l2.c
>  create mode 100644 drivers/media/platform/sti/delta/delta.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index d944421..2247d9d 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -298,6 +298,34 @@ config VIDEO_STI_HVA
> To compile this driver as a module, choose M here:
> the module will be called st-hva.
>  
> +config VIDEO_STI_DELTA
> + tristate "STMicroelectronics DELTA multi-format video decoder V4L2 
> driver"
> + depends on VIDEO_DEV && VIDEO_V4L2
> + depends on ARCH_STI || COMPILE_TEST
> + depends on HAS_DMA
> + help
> + This V4L2 driver enables DELTA multi-format video decoder
> + of STMicroelectronics STiH4xx SoC series allowing hardware
> + decoding of various compressed video bitstream format in
> + raw uncompressed format.
> +
> + Use this option to see the decoders available for such
> + hardware.
> +
> + Please notice that the driver will only be built if
> + at least one of the DELTA decoder below is selected.
> +
> +if VIDEO_STI_DELTA
> +
> +config VIDEO_STI_DELTA_DRIVER
> + tristate
> + depends on VIDEO_STI_DELTA
> + default n
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_MEM2MEM_DEV
> +
> +endif # VIDEO_STI_DELTA
> +
>  config VIDEO_SH_VEU
>   tristate "SuperH VEU mem2mem video processing driver"
>   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 5b3cb27..349ddf6 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -39,6 +39,8 @@ obj-$(CONFIG_VIDEO_STI_BDISP)   += sti/bdisp/
>  obj-$(CONFIG_VIDEO_STI_HVA)  += sti/hva/
>  obj-$(CONFIG_DVB_C8SECTPFE)  += sti/c8sectpfe/
>  
> +obj-$(CONFIG_VIDEO_STI_DELTA)+= sti/delta/
> +
>  obj-$(CONFIG_BLACKFIN)  += blackfin/
>  
>  obj-$(CONFIG_ARCH_DAVINCI)   += davinci/
> diff --git a/drivers/media/platform/sti/delta/Makefile 
> b/drivers/media/platform/sti/delta/Makefile
> new file mode 100644
> index 000..467519e
> --- /dev/null
> +++ b/drivers/media/platform/sti/delta/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_VIDEO_STI_DELTA_DRIVER) := st-delta.o
> +st-delta-y := delta-v4l2.o
> diff --git a/drivers/media/platform/sti/delta/delta-cfg.h 
> b/drivers/media/platform/sti/delta/delta-cfg.h
> new file mode 100644
> index 000..f6674f6
> --- /dev/null
> +++ b/drivers/media/platform/sti/delta/delta-cfg.h
> @@ -0,0 +1,61 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2015
> + * Author: Hugues Fruchet  for STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#ifndef DELTA_CFG_H
> +#define DELTA_CFG_H
> +
> +#define DELTA_FW_VERSION "21.1-3"
> +
> +#define DELTA_MIN_WIDTH  32
> +#define DELTA_MAX_WIDTH  4096
> +#define DELTA_MIN_HEIGHT 32
> +#define DELTA_MAX_HEIGHT 2400
> +
> +/* DELTA requires a 32x32 pixels alignment for frames */
> +#define DELTA_WIDTH_ALIGNMENT32
> +#define DELTA_HEIGHT_ALIGNMENT   32
> +
> +#define DELTA_DEFAULT_WIDTH  DELTA_MIN_WIDTH
> +#define DELTA_DEFAULT_HEIGHT DELTA_MIN_HEIGHT
> +#define DELTA_DEFAULT_FRAMEFORMAT  V4L2_PIX_FMT_NV12
> +#define DELTA_DEFAULT_STREAMFORMAT V4L2_PIX_FMT_MJPEG
> +
> +#define DELTA_MAX_RESO (DELTA_MAX_WIDTH * DELTA_MAX_HEIGHT)
> +
> +/* guard value for number of access units */
> +#define DELTA_MAX_AUS 10
> +
> +/* IP perf dependent, can be tuned */
> +#define DELTA_PEAK_FRAME_SMOOTHING 2
> +
> +/*
> + * guard output frame count:
> + * - at least 1 frame needed for display
> + * - at worst 21
> + *   ( max h264 dpb (16) +
> + * decoding peak smoothing (2) +
> + * user display pipeline (3) )
> + */
> +#define DELTA_MIN_FRAME_USER1
> +#define DELTA_MAX_DPB   16
> +#define DELTA_MAX_FRAME_USER3 /* platform/use-case dependent */
> +#define DELTA_MAX_FRAMES (DELTA_MAX_DPB + DELTA_PEAK_FRAME_SMOOTHING +\
> 

Re: [STLinux Kernel] [PATCH v6 04/10] [media] MAINTAINERS: add st-delta driver

2017-02-01 Thread Peter Griffin
Hi Hugues,

On Wed, 01 Feb 2017, Hugues Fruchet wrote:

> Add entry for the STMicroelectronics DELTA driver.
> 
> Signed-off-by: Hugues Fruchet 
> ---
>  MAINTAINERS | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cfff2c9..38cc652 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2429,6 +2429,14 @@ W: https://linuxtv.org
>  S:   Supported
>  F:   drivers/media/platform/sti/bdisp
>  
> +DELTA ST MEDIA DRIVER
> +M:   Hugues Fruchet 
> +L:   linux-media@vger.kernel.org

Would be useful to also include ker...@stlinux.com mailing list.

Apart from that:

Acked-by: Peter Griffin 

> +T:   git git://linuxtv.org/media_tree.git
> +W:   https://linuxtv.org
> +S:   Supported
> +F:   drivers/media/platform/sti/delta
> +
>  BEFS FILE SYSTEM
>  M:   Luis de Bethencourt 
>  M:   Salah Triki 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Documentation: devicetree: meson-ir: "linux, rc-map-name" is supported

2017-02-01 Thread Andreas Färber
Am 01.02.2017 um 18:47 schrieb Rob Herring:
> On Tue, Jan 31, 2017 at 10:21:12PM +0100, Martin Blumenstingl wrote:
>> The driver already parses the "linux,rc-map-name" property. Add this
>> information to the documentation so .dts maintainers don't have to look
>> it up in the source-code.
>>
>> Signed-off-by: Martin Blumenstingl 
>> ---
>>  Documentation/devicetree/bindings/media/meson-ir.txt | 3 +++
>>  1 file changed, 3 insertions(+)
> 
> Acked-by: Rob Herring 

Note that the subject has a space in the property name that should be
dropped before applying.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [STLinux Kernel] [PATCH v6 03/10] ARM: multi_v7_defconfig: enable STMicroelectronics DELTA Support

2017-02-01 Thread Peter Griffin
On Wed, 01 Feb 2017, Hugues Fruchet wrote:

> Enables support of STMicroelectronics STiH4xx SoC series
> DELTA multi-format video decoder V4L2 driver.
> 
> Signed-off-by: Hugues Fruchet 

Acked-by: Peter Griffin 

> ---
>  arch/arm/configs/multi_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index b01a438..5dff8fe 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -569,6 +569,7 @@ CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
>  CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
>  CONFIG_VIDEO_STI_BDISP=m
>  CONFIG_VIDEO_STI_HVA=m
> +CONFIG_VIDEO_STI_DELTA=m
>  CONFIG_VIDEO_RENESAS_JPU=m
>  CONFIG_VIDEO_RENESAS_VSP1=m
>  CONFIG_V4L_TEST_DRIVERS=y
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [STLinux Kernel] [PATCH v6 07/10] [media] st-delta: rpmsg ipc support

2017-02-01 Thread Peter Griffin
On Wed, 01 Feb 2017, Hugues Fruchet wrote:

> IPC (Inter Process Communication) support for communication with
> DELTA coprocessor firmware using rpmsg kernel framework.
> Based on 4 services open/set_stream/decode/close and their associated
> rpmsg messages.
> The messages structures are duplicated on both host and firmware
> side and are packed (use only of 32 bits size fields in messages
> structures to ensure packing).
> Each service is synchronous; service returns only when firmware
> acknowledges the associated command message.
> Due to significant parameters size exchanged from host to copro,
> parameters are not inserted in rpmsg messages. Instead, parameters are
> stored in physical memory shared between host and coprocessor.
> Memory is non-cacheable, so no special operation is required
> to ensure memory coherency on host and on coprocessor side.
> Multi-instance support and re-entrance are ensured using host_hdl and
> copro_hdl in message header exchanged between both host and coprocessor.
> This avoids to manage tables on both sides to get back the running context
> of each instance.
> 
> Signed-off-by: Hugues Fruchet 

Acked-by: Peter Griffin 

> ---
>  drivers/media/platform/Kconfig|   1 +
>  drivers/media/platform/sti/delta/Makefile |   2 +-
>  drivers/media/platform/sti/delta/delta-ipc.c  | 594 
> ++
>  drivers/media/platform/sti/delta/delta-ipc.h  |  76 
>  drivers/media/platform/sti/delta/delta-v4l2.c |  11 +
>  drivers/media/platform/sti/delta/delta.h  |  21 +
>  6 files changed, 704 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/platform/sti/delta/delta-ipc.c
>  create mode 100644 drivers/media/platform/sti/delta/delta-ipc.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 2247d9d..2e82ec6 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -323,6 +323,7 @@ config VIDEO_STI_DELTA_DRIVER
>   default n
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_MEM2MEM_DEV
> + select RPMSG
>  
>  endif # VIDEO_STI_DELTA
>  
> diff --git a/drivers/media/platform/sti/delta/Makefile 
> b/drivers/media/platform/sti/delta/Makefile
> index 93a3037..b791ba0 100644
> --- a/drivers/media/platform/sti/delta/Makefile
> +++ b/drivers/media/platform/sti/delta/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_VIDEO_STI_DELTA_DRIVER) := st-delta.o
> -st-delta-y := delta-v4l2.o delta-mem.o
> +st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o
> diff --git a/drivers/media/platform/sti/delta/delta-ipc.c 
> b/drivers/media/platform/sti/delta/delta-ipc.c
> new file mode 100644
> index 000..41e4a4c
> --- /dev/null
> +++ b/drivers/media/platform/sti/delta/delta-ipc.c
> @@ -0,0 +1,594 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2015
> + * Author: Hugues Fruchet  for STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#include 
> +
> +#include "delta.h"
> +#include "delta-ipc.h"
> +#include "delta-mem.h"
> +
> +#define IPC_TIMEOUT 100
> +#define IPC_SANITY_TAG 0xDEADBEEF
> +
> +enum delta_ipc_fw_command {
> + DELTA_IPC_OPEN,
> + DELTA_IPC_SET_STREAM,
> + DELTA_IPC_DECODE,
> + DELTA_IPC_CLOSE
> +};
> +
> +#define to_rpmsg_driver(__drv) container_of(__drv, struct rpmsg_driver, drv)
> +#define to_delta(__d) container_of(__d, struct delta_dev, rpmsg_driver)
> +
> +#define to_ctx(hdl) ((struct delta_ipc_ctx *)hdl)
> +#define to_pctx(ctx) container_of(ctx, struct delta_ctx, ipc_ctx)
> +
> +struct delta_ipc_header_msg {
> + u32 tag;
> + void *host_hdl;
> + u32 copro_hdl;
> + u32 command;
> +};
> +
> +#define to_host_hdl(ctx) ((void *)ctx)
> +
> +#define msg_to_ctx(msg) ((struct delta_ipc_ctx *)(msg)->header.host_hdl)
> +#define msg_to_copro_hdl(msg) ((msg)->header.copro_hdl)
> +
> +static inline dma_addr_t to_paddr(struct delta_ipc_ctx *ctx, void *vaddr)
> +{
> + return (ctx->ipc_buf->paddr + (vaddr - ctx->ipc_buf->vaddr));
> +}
> +
> +static inline bool is_valid_data(struct delta_ipc_ctx *ctx,
> +  void *data, u32 size)
> +{
> + return ((data >= ctx->ipc_buf->vaddr) &&
> + ((data + size) <= (ctx->ipc_buf->vaddr + ctx->ipc_buf->size)));
> +}
> +
> +/*
> + * IPC shared memory (@ipc_buf_size, @ipc_buf_paddr) is sent to copro
> + * at each instance opening. This memory is allocated by IPC client
> + * and given through delta_ipc_open(). All messages parameters
> + * (open, set_stream, decode) will have their phy address within
> + * this IPC shared memory, avoiding de-facto recopies inside delta-ipc.
> + * All the below messages structures are used on both host and firmware
> + * side and are packed (use only of 32 bits size fields in messages
> + * structures to ensure packing):
> + * - struct delta_ipc_open_msg
> + * - struct delta_ipc_set_stream_msg
> + * - struct 

Re: [STLinux Kernel] [PATCH v6 09/10] [media] st-delta: add mjpeg support

2017-02-01 Thread Peter Griffin
On Wed, 01 Feb 2017, Hugues Fruchet wrote:

> Adds support of DELTA MJPEG video decoder back-end,
> implemented by calling JPEG_DECODER_HW0 firmware
> using RPMSG IPC communication layer.
> 
> Signed-off-by: Hugues Fruchet 

Acked-by: Peter Griffin 

> ---
>  drivers/media/platform/Kconfig |  12 +-
>  drivers/media/platform/sti/delta/Makefile  |   4 +
>  drivers/media/platform/sti/delta/delta-cfg.h   |   3 +
>  drivers/media/platform/sti/delta/delta-mjpeg-dec.c | 455 
> +
>  drivers/media/platform/sti/delta/delta-mjpeg-fw.h  | 225 ++
>  drivers/media/platform/sti/delta/delta-mjpeg-hdr.c | 149 +++
>  drivers/media/platform/sti/delta/delta-mjpeg.h |  35 ++
>  drivers/media/platform/sti/delta/delta-v4l2.c  |   3 +
>  8 files changed, 885 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg-dec.c
>  create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg-fw.h
>  create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg-hdr.c
>  create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 2e82ec6..20b26ea 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -317,10 +317,20 @@ config VIDEO_STI_DELTA
>  
>  if VIDEO_STI_DELTA
>  
> +config VIDEO_STI_DELTA_MJPEG
> + bool "STMicroelectronics DELTA MJPEG support"
> + default y
> + help
> + Enables DELTA MJPEG hardware support.
> +
> + To compile this driver as a module, choose M here:
> + the module will be called st-delta.
> +
>  config VIDEO_STI_DELTA_DRIVER
>   tristate
>   depends on VIDEO_STI_DELTA
> - default n
> + depends on VIDEO_STI_DELTA_MJPEG
> + default VIDEO_STI_DELTA_MJPEG
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_MEM2MEM_DEV
>   select RPMSG
> diff --git a/drivers/media/platform/sti/delta/Makefile 
> b/drivers/media/platform/sti/delta/Makefile
> index b791ba0..b268df6 100644
> --- a/drivers/media/platform/sti/delta/Makefile
> +++ b/drivers/media/platform/sti/delta/Makefile
> @@ -1,2 +1,6 @@
>  obj-$(CONFIG_VIDEO_STI_DELTA_DRIVER) := st-delta.o
>  st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o
> +
> +# MJPEG support
> +st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-hdr.o
> +st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-dec.o
> diff --git a/drivers/media/platform/sti/delta/delta-cfg.h 
> b/drivers/media/platform/sti/delta/delta-cfg.h
> index f6674f6..c6388f5 100644
> --- a/drivers/media/platform/sti/delta/delta-cfg.h
> +++ b/drivers/media/platform/sti/delta/delta-cfg.h
> @@ -57,5 +57,8 @@
>  #define DELTA_HW_AUTOSUSPEND_DELAY_MS 5
>  
>  #define DELTA_MAX_DECODERS 10
> +#ifdef CONFIG_VIDEO_STI_DELTA_MJPEG
> +extern const struct delta_dec mjpegdec;
> +#endif
>  
>  #endif /* DELTA_CFG_H */
> diff --git a/drivers/media/platform/sti/delta/delta-mjpeg-dec.c 
> b/drivers/media/platform/sti/delta/delta-mjpeg-dec.c
> new file mode 100644
> index 000..e79bdc6
> --- /dev/null
> +++ b/drivers/media/platform/sti/delta/delta-mjpeg-dec.c
> @@ -0,0 +1,455 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2013
> + * Author: Hugues Fruchet  for STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#include 
> +
> +#include "delta.h"
> +#include "delta-ipc.h"
> +#include "delta-mjpeg.h"
> +#include "delta-mjpeg-fw.h"
> +
> +#define DELTA_MJPEG_MAX_RESO DELTA_MAX_RESO
> +
> +struct delta_mjpeg_ctx {
> + /* jpeg header */
> + struct mjpeg_header header_struct;
> + struct mjpeg_header *header;
> +
> + /* ipc */
> + void *ipc_hdl;
> + struct delta_buf *ipc_buf;
> +
> + /* decoded output frame */
> + struct delta_frame *out_frame;
> +
> + unsigned char str[3000];
> +};
> +
> +#define to_ctx(ctx) ((struct delta_mjpeg_ctx *)(ctx)->priv)
> +
> +static char *ipc_open_param_str(struct jpeg_video_decode_init_params_t *p,
> + char *str, unsigned int len)
> +{
> + char *b = str;
> +
> + if (!p)
> + return "";
> +
> + b += snprintf(b, len,
> +   "jpeg_video_decode_init_params_t\n"
> +   "circular_buffer_begin_addr_p 0x%x\n"
> +   "circular_buffer_end_addr_p   0x%x\n",
> +   p->circular_buffer_begin_addr_p,
> +   p->circular_buffer_end_addr_p);
> +
> + return str;
> +}
> +
> +static char *ipc_decode_param_str(struct jpeg_decode_params_t *p,
> +   char *str, unsigned int len)
> +{
> + char *b = str;
> +
> + if (!p)
> + return "";
> +
> + b += snprintf(b, len,
> +   "jpeg_decode_params_t\n"
> +   "picture_start_addr_p  0x%x\n"
> +  

Re: [STLinux Kernel] [PATCH v6 10/10] st-delta: debug: trace stream/frame information & summary

2017-02-01 Thread Peter Griffin
On Wed, 01 Feb 2017, Hugues Fruchet wrote:

> Adds some trace points showing input compressed stream or
> output decoded frame information.
> Adds an unconditional trace point when streaming starts showing
> the compressed stream and the decoded frame information.
> Adds an unconditional trace point at instance closure summarizing
> into a single line the decoding process (stream information, decoded
> and output frames number, potential errors observed).
> 
> Signed-off-by: Hugues Fruchet 

Acked-by: Peter Griffin 

> ---
>  drivers/media/platform/sti/delta/Makefile  |  2 +-
>  drivers/media/platform/sti/delta/delta-debug.c | 72 
> ++
>  drivers/media/platform/sti/delta/delta-debug.h | 18 +++
>  drivers/media/platform/sti/delta/delta-v4l2.c  | 30 +--
>  4 files changed, 117 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/media/platform/sti/delta/delta-debug.c
>  create mode 100644 drivers/media/platform/sti/delta/delta-debug.h
> 
> diff --git a/drivers/media/platform/sti/delta/Makefile 
> b/drivers/media/platform/sti/delta/Makefile
> index b268df6..8d032508 100644
> --- a/drivers/media/platform/sti/delta/Makefile
> +++ b/drivers/media/platform/sti/delta/Makefile
> @@ -1,5 +1,5 @@
>  obj-$(CONFIG_VIDEO_STI_DELTA_DRIVER) := st-delta.o
> -st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o
> +st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o delta-debug.o
>  
>  # MJPEG support
>  st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-hdr.o
> diff --git a/drivers/media/platform/sti/delta/delta-debug.c 
> b/drivers/media/platform/sti/delta/delta-debug.c
> new file mode 100644
> index 000..a7ebf2c
> --- /dev/null
> +++ b/drivers/media/platform/sti/delta/delta-debug.c
> @@ -0,0 +1,72 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2015
> + * Authors: Hugues Fruchet 
> + *  Fabrice Lecoultre 
> + *  for STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#include "delta.h"
> +#include "delta-debug.h"
> +
> +char *delta_streaminfo_str(struct delta_streaminfo *s, char *str,
> +unsigned int len)
> +{
> + if (!s)
> + return NULL;
> +
> + snprintf(str, len,
> +  "%4.4s %dx%d %s %s dpb=%d %s %s %s%dx%d@(%d,%d) %s%d/%d",
> +  (char *)>streamformat, s->width, s->height,
> +  s->profile, s->level, s->dpb,
> +  (s->field == V4L2_FIELD_NONE) ? "progressive" : "interlaced",
> +  s->other,
> +  s->flags & DELTA_STREAMINFO_FLAG_CROP ? "crop=" : "",
> +  s->crop.width, s->crop.height,
> +  s->crop.left, s->crop.top,
> +  s->flags & DELTA_STREAMINFO_FLAG_PIXELASPECT ? "par=" : "",
> +  s->pixelaspect.numerator,
> +  s->pixelaspect.denominator);
> +
> + return str;
> +}
> +
> +char *delta_frameinfo_str(struct delta_frameinfo *f, char *str,
> +   unsigned int len)
> +{
> + if (!f)
> + return NULL;
> +
> + snprintf(str, len,
> +  "%4.4s %dx%d aligned %dx%d %s %s%dx%d@(%d,%d) %s%d/%d",
> +  (char *)>pixelformat, f->width, f->height,
> +  f->aligned_width, f->aligned_height,
> +  (f->field == V4L2_FIELD_NONE) ? "progressive" : "interlaced",
> +  f->flags & DELTA_STREAMINFO_FLAG_CROP ? "crop=" : "",
> +  f->crop.width, f->crop.height,
> +  f->crop.left, f->crop.top,
> +  f->flags & DELTA_STREAMINFO_FLAG_PIXELASPECT ? "par=" : "",
> +  f->pixelaspect.numerator,
> +  f->pixelaspect.denominator);
> +
> + return str;
> +}
> +
> +void delta_trace_summary(struct delta_ctx *ctx)
> +{
> + struct delta_dev *delta = ctx->dev;
> + struct delta_streaminfo *s = >streaminfo;
> + unsigned char str[100] = "";
> +
> + if (!(ctx->flags & DELTA_FLAG_STREAMINFO))
> + return;
> +
> + dev_dbg(delta->dev, "%s %s, %d frames decoded, %d frames output, %d 
> frames dropped, %d stream errors, %d decode errors",
> + ctx->name,
> + delta_streaminfo_str(s, str, sizeof(str)),
> + ctx->decoded_frames,
> + ctx->output_frames,
> + ctx->dropped_frames,
> + ctx->stream_errors,
> + ctx->decode_errors);
> +}
> diff --git a/drivers/media/platform/sti/delta/delta-debug.h 
> b/drivers/media/platform/sti/delta/delta-debug.h
> new file mode 100644
> index 000..955c158
> --- /dev/null
> +++ b/drivers/media/platform/sti/delta/delta-debug.h
> @@ -0,0 +1,18 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2015
> + * Authors: Hugues Fruchet 
> + *  Fabrice Lecoultre 
> + *  for STMicroelectronics.
> + * License terms:  GNU General Public 

Re: [PATCH] Documentation: devicetree: meson-ir: "linux,rc-map-name" is supported

2017-02-01 Thread Rob Herring
On Tue, Jan 31, 2017 at 10:21:12PM +0100, Martin Blumenstingl wrote:
> The driver already parses the "linux,rc-map-name" property. Add this
> information to the documentation so .dts maintainers don't have to look
> it up in the source-code.
> 
> Signed-off-by: Martin Blumenstingl 
> ---
>  Documentation/devicetree/bindings/media/meson-ir.txt | 3 +++
>  1 file changed, 3 insertions(+)

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


Re: [PATCH] Documentation: devicetree: add the RC map name of the geekbox remote

2017-02-01 Thread Rob Herring
On Tue, Jan 31, 2017 at 10:13:42PM +0100, Martin Blumenstingl wrote:
> Signed-off-by: Martin Blumenstingl 
> ---
> The geekbox keymap was added while the documentation patch was not
> applied yet (and I wasn't aware of this pending patch). This ensures
> that the documentation is in sync with the actual keymaps.
> 
>  Documentation/devicetree/bindings/media/rc.txt | 1 +
>  1 file changed, 1 insertion(+)

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


Re: rtl2832_sdr and /dev/swradio0

2017-02-01 Thread Antti Palosaari

On 01/31/2017 07:50 PM, Russel Winder wrote:

Hi,

Is anyone actively working on the rtl2832_sdr driver?

I am particularly interested in anyone who has code for turning the
byte stream from /dev/swradio0 into an ETI stream. Or failing that
getting enough data about the API for using /dev/swradio0 so as to
write a byte sequence to ETI driver based on the dab2eti program in
DABtool (which uses the librtlsdr mechanism instead of the
/dev/swradio0 one).



Easiest way to test it just use v4l2-ctl to configure device and then 
read data from device file.


$ #set ADC 2M
$ v4l2-ctl -d /dev/swradio0 --tuner=0 --set-freq=2.000
Frequency for tuner 0 set to 200 (2.00 MHz)
$ #set rf tuner 98.1MHz
$ v4l2-ctl -d /dev/swradio0 --tuner=1 --set-freq=98.1
Frequency for tuner 1 set to 9810 (98.10 MHz)
$ # dump 32 I/Q samples
$ cat /dev/swradio0 |hexdump -n 64 -C
  80 80 7e 7d 84 84 70 71  a8 5f 74 9f 6e 53 b4 9d 
|..~}..pq._t.nS..|
0010  53 8f 9e 4c 71 b8 75 28  a1 8a 57 8c 9d 46 73 c7 
|S..Lq.u(..W..Fs.|
0020  79 60 a6 ae 36 82 94 60  6c bf 7e 6a a7 9e 55 73 
|y`..6..`l.~j..Us|
0030  a8 72 5c a6 7f 35 a2 a2  61 54 ce 8a 57 b3 8e 50 
|.r\..5..aT..W..P|

0040
$

Looking v4l2-ctl code could give some ideas how to use control IOCTLs. 
Data can be read both read() or mmap() method.



regards
Antti

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


Re: [STLinux Kernel] [PATCH v6 01/10] Documentation: DT: add bindings for ST DELTA

2017-02-01 Thread Peter Griffin
On Wed, 01 Feb 2017, Hugues Fruchet wrote:

> This patch adds DT binding documentation for STMicroelectronics
> DELTA V4L2 video decoder.
> 
> Signed-off-by: Hugues Fruchet 

Acked-by: Peter Griffin 

> ---
>  Documentation/devicetree/bindings/media/st,st-delta.txt | 17 
> +
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/st,st-delta.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/st,st-delta.txt 
> b/Documentation/devicetree/bindings/media/st,st-delta.txt
> new file mode 100644
> index 000..a538ab3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/st,st-delta.txt
> @@ -0,0 +1,17 @@
> +* STMicroelectronics DELTA multi-format video decoder
> +
> +Required properties:
> +- compatible: should be "st,st-delta".
> +- clocks: from common clock binding: handle hardware IP needed clocks, the
> +  number of clocks may depend on the SoC type.
> +  See ../clock/clock-bindings.txt for details.
> +- clock-names: names of the clocks listed in clocks property in the same 
> order.
> +
> +Example:
> + delta0 {
> + compatible = "st,st-delta";
> + clock-names = "delta", "delta-st231", "delta-flash-promip";
> + clocks = <_s_c0_flexgen CLK_VID_DMU>,
> +  <_s_c0_flexgen CLK_ST231_DMU>,
> +  <_s_c0_flexgen CLK_FLASH_PROMIP>;
> + };
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv2 13/16] ov2640: update bindings

2017-02-01 Thread Rob Herring
On Mon, Jan 30, 2017 at 03:06:25PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Update the bindings for this device based on a working DT example.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  .../devicetree/bindings/media/i2c/ov2640.txt   | 22 
> ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov2640.txt 
> b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
> index c429b5b..5e6c445 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ov2640.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
> @@ -1,8 +1,8 @@
>  * Omnivision OV2640 CMOS sensor
>  
> -The Omnivision OV2640 sensor support multiple resolutions output, such as
> -CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
> -output format.
> +The Omnivision OV2640 sensor supports multiple resolutions output, such as
> +CIF, SVGA, UXGA. It also can support the YUV422/420, RGB565/555 or raw RGB
> +output formats.
>  
>  Required Properties:
>  - compatible: should be "ovti,ov2640"
> @@ -20,20 +20,18 @@ 
> Documentation/devicetree/bindings/media/video-interfaces.txt.
>  Example:
>  
>   i2c1: i2c@f0018000 {
> + status = "okay";

There's no point in showing status in examples.

> +
>   ov2640: camera@0x30 {

Drop the '0x' while here.

With that,

Acked-by: Rob Herring 


>   compatible = "ovti,ov2640";
>   reg = <0x30>;
> -
>   pinctrl-names = "default";
> - pinctrl-0 = <_pck1 _ov2640_pwdn 
> _ov2640_resetb>;
> -
> - resetb-gpios = < 24 GPIO_ACTIVE_LOW>;
> - pwdn-gpios = < 29 GPIO_ACTIVE_HIGH>;
> -
> - clocks = <>;
> + pinctrl-0 = <_pck0_as_isi_mck 
> _sensor_power _sensor_reset>;
> + resetb-gpios = < 11 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = < 13 GPIO_ACTIVE_HIGH>;
> + clocks = <>;
>   clock-names = "xvclk";
> -
> - assigned-clocks = <>;
> + assigned-clocks = <>;
>   assigned-clock-rates = <2500>;
>  
>   port {
> -- 
> 2.10.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PULL 4.11] drop unused hd29l2 driver

2017-02-01 Thread Antti Palosaari

The following changes since commit d183e4efcae8d88a2f252e546978658ca6d273cc:

  [media] v4l: tvp5150: Add missing break in set control handler 
(2016-12-12 07:49:58 -0200)


are available in the git repository at:

  git://linuxtv.org/anttip/media_tree.git hdic

for you to fetch changes up to aacb6916b411c17d8372a5da46f94b39c5fd297a:

  hd29l2: remove unused driver (2017-01-27 19:25:19 +0200)


Antti Palosaari (2):
  MAINTAINERS: remove hd29l2
  hd29l2: remove unused driver

 MAINTAINERS   |  10 --
 drivers/media/dvb-frontends/Kconfig   |   7 --
 drivers/media/dvb-frontends/Makefile  |   1 -
 drivers/media/dvb-frontends/hd29l2.c  | 870 


 drivers/media/dvb-frontends/hd29l2.h  |  65 ---
 drivers/media/dvb-frontends/hd29l2_priv.h | 301 
-

 6 files changed, 1254 deletions(-)
 delete mode 100644 drivers/media/dvb-frontends/hd29l2.c
 delete mode 100644 drivers/media/dvb-frontends/hd29l2.h
 delete mode 100644 drivers/media/dvb-frontends/hd29l2_priv.h

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


Re: [PATCHv2 08/16] atmel-isi: document device tree bindings

2017-02-01 Thread Rob Herring
On Mon, Jan 30, 2017 at 03:06:20PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Document the device tree bindings for this driver.

Bindings document h/w not drivers.

> 
> Mostly copied from the atmel-isc bindings.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  .../devicetree/bindings/media/atmel-isi.txt| 91 
> +-
>  1 file changed, 56 insertions(+), 35 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt 
> b/Documentation/devicetree/bindings/media/atmel-isi.txt
> index 251f008..d1934b4 100644
> --- a/Documentation/devicetree/bindings/media/atmel-isi.txt
> +++ b/Documentation/devicetree/bindings/media/atmel-isi.txt
> @@ -1,51 +1,72 @@
> -Atmel Image Sensor Interface (ISI) SoC Camera Subsystem
> ---
> +Atmel Image Sensor Interface (ISI)
> +--
>  
> -Required properties:
> -- compatible: must be "atmel,at91sam9g45-isi"
> -- reg: physical base address and length of the registers set for the device;
> -- interrupts: should contain IRQ line for the ISI;
> -- clocks: list of clock specifiers, corresponding to entries in
> -  the clock-names property;
> -- clock-names: must contain "isi_clk", which is the isi peripherial clock.
> +Required properties for ISI:
> +- compatible
> + Must be "atmel,at91sam9g45-isi".
> +- reg
> + Physical base address and length of the registers set for the device.
> +- interrupts
> + Should contain IRQ line for the ISI.
> +- clocks
> + List of clock specifiers, corresponding to entries in
> + the clock-names property;
> + Please refer to clock-bindings.txt.
> +- clock-names
> + Required elements: "isi_clk".
> +- #clock-cells
> + Should be 0.

This reformatting is unrelated and the old form was more standard for 
bindings (not that we have any real standard).

> +- pinctrl-names, pinctrl-0
> + Please refer to pinctrl-bindings.txt.
>  
>  ISI supports a single port node with parallel bus. It should contain one
>  'port' child node with child 'endpoint' node. Please refer to the bindings
>  defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
>  
>  Example:
> - isi: isi@f0034000 {
> - compatible = "atmel,at91sam9g45-isi";
> - reg = <0xf0034000 0x4000>;
> - interrupts = <37 IRQ_TYPE_LEVEL_HIGH 5>;
>  
> - clocks = <_clk>;
> - clock-names = "isi_clk";
> +isi: isi@f0034000 {
> + compatible = "atmel,at91sam9g45-isi";
> + reg = <0xf0034000 0x4000>;
> + interrupts = <37 IRQ_TYPE_LEVEL_HIGH 5>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_isi_data_0_7>;
> + clocks = <_clk>;
> + clock-names = "isi_clk";
> + status = "ok";
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + isi_0: endpoint {
> + reg = <0>;

Drop reg.

> + remote-endpoint = <_0>;
> + bus-width = <8>;
> + vsync-active = <1>;
> + hsync-active = <1>;

Which side of the connect is supposed to define these?

> + };
> + };
> +};
> +
> +i2c1: i2c@f0018000 {
> + status = "okay";
>  
> + ov2640: camera@0x30 {

Drop the '0x'.

> + compatible = "ovti,ov2640";
> + reg = <0x30>;
>   pinctrl-names = "default";
> - pinctrl-0 = <_isi>;
> + pinctrl-0 = <_pck0_as_isi_mck _sensor_power 
> _sensor_reset>;
> + resetb-gpios = < 11 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = < 13 GPIO_ACTIVE_HIGH>;
> + clocks = <>;
> + clock-names = "xvclk";
> + assigned-clocks = <>;
> + assigned-clock-rates = <2500>;
>  
>   port {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - isi_0: endpoint {
> - remote-endpoint = <_0>;
> + ov2640_0: endpoint {
> + remote-endpoint = <_0>;
>   bus-width = <8>;

It is pointless to define bus-width at both ends.

>   };
>   };
>   };
> -
> - i2c1: i2c@f0018000 {
> - ov2640: camera@0x30 {
> - compatible = "ovti,ov2640";
> - reg = <0x30>;
> -
> - port {
> - ov2640_0: endpoint {
> - remote-endpoint = <_0>;
> - bus-width = <8>;
> - };
> - };
> - };
> - };
> +};
> -- 
> 2.10.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  

[GIT PULL 4.11] zd1301 usb interface + dvb-t demod driver

2017-02-01 Thread Antti Palosaari

The following changes since commit c739c0a7c3c2472d7562b8f802cdce44d2597c8b:

  [media] s5k4ecgx: select CRC32 helper (2016-12-21 07:33:40 -0200)

are available in the git repository at:

  git://linuxtv.org/anttip/media_tree.git zd1301

for you to fetch changes up to 3b58fcff6d2578f83be4eb018274d6e82fcef426:

  mt2060: implement sleep (2017-01-27 18:44:37 +0200)


Antti Palosaari (7):
  mt2060: add i2c bindings
  mt2060: add param to split long i2c writes
  zd1301_demod: ZyDAS ZD1301 DVB-T demodulator driver
  MAINTAINERS: add zd1301_demod driver
  zd1301: ZyDAS ZD1301 DVB USB interface driver
  MAINTAINERS: add zd1301 DVB USB interface driver
  mt2060: implement sleep

 MAINTAINERS|  18 +
 drivers/media/dvb-core/dvb-usb-ids.h   |   1 +
 drivers/media/dvb-frontends/Kconfig|   7 ++
 drivers/media/dvb-frontends/Makefile   |   1 +
 drivers/media/dvb-frontends/zd1301_demod.c | 551 
+++

 drivers/media/dvb-frontends/zd1301_demod.h |  55 ++
 drivers/media/tuners/mt2060.c  | 125 
++--

 drivers/media/tuners/mt2060.h  |  23 ++
 drivers/media/tuners/mt2060_priv.h |  11 +++
 drivers/media/usb/dvb-usb-v2/Kconfig   |   8 +++
 drivers/media/usb/dvb-usb-v2/Makefile  |   3 +
 drivers/media/usb/dvb-usb-v2/zd1301.c  | 294 
++

 12 files changed, 1093 insertions(+), 4 deletions(-)
 create mode 100644 drivers/media/dvb-frontends/zd1301_demod.c
 create mode 100644 drivers/media/dvb-frontends/zd1301_demod.h
 create mode 100644 drivers/media/usb/dvb-usb-v2/zd1301.c

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


Re: [PATCHv2 05/16] ov7670: document device tree bindings

2017-02-01 Thread Rob Herring
On Mon, Jan 30, 2017 at 03:06:17PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add binding documentation and add that file to the MAINTAINERS entry.

This should come before the driver support.

> Signed-off-by: Hans Verkuil 
> ---
>  .../devicetree/bindings/media/i2c/ov7670.txt   | 44 
> ++
>  MAINTAINERS|  1 +
>  2 files changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7670.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov7670.txt 
> b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> new file mode 100644
> index 000..a014694
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> @@ -0,0 +1,44 @@
> +* Omnivision OV7670 CMOS sensor
> +
> +The Omnivision OV7670 sensor supports multiple resolutions output, such as
> +CIF, SVGA, UXGA. It also can support the YUV422/420, RGB565/555 or raw RGB
> +output formats.
> +
> +Required Properties:
> +- compatible: should be "ovti,ov7670"
> +- clocks: reference to the xclk input clock.
> +- clock-names: should be "xclk".
> +
> +Optional Properties:
> +- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.

We've somewhat standardized naming for reset gpios to "reset-gpios" even 
if that doesn't quite match the pin name.

> +- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.

Same here with "powerdown-gpios".

> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +
> + i2c1: i2c@f0018000 {
> + status = "okay";
> +
> + ov7670: camera@0x21 {

Drop the '0x'.

> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pck0_as_isi_mck 
> _sensor_power _sensor_reset>;
> + resetb-gpios = < 11 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = < 13 GPIO_ACTIVE_HIGH>;
> + clocks = <>;
> + clock-names = "xclk";
> + assigned-clocks = <>;
> + assigned-clock-rates = <2500>;
> +
> + port {
> + ov7670_0: endpoint {
> + remote-endpoint = <_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cfff2c9..67df205 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9101,6 +9101,7 @@ L:  linux-media@vger.kernel.org
>  T:   git git://linuxtv.org/media_tree.git
>  S:   Maintained
>  F:   drivers/media/i2c/ov7670.c
> +F:   Documentation/devicetree/bindings/media/i2c/ov7670.txt
>  
>  ONENAND FLASH DRIVER
>  M:   Kyungmin Park 
> -- 
> 2.10.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] staging: bcm2835-v4l: remove incorrect include path

2017-02-01 Thread Arnd Bergmann
The driver introduces a new instance of the missing-include-dirs warning that
is enabled at the "make W=1" level but has no other output:

cc1: error: drivers/staging/vc04_services/interface/vcos/linuxkernel: No such 
file or directory [-Werror=missing-include-dirs]
cc1: all warnings being treated as errors
scripts/Makefile.build:307: recipe for target 
'drivers/staging/media/platform/bcm2835/bcm2835-camera.o' failed

In order to let us enable the warning by default in the future, we should
just remove the incorrect argument here.

Fixes: 97b35807cc4d ("staging: bcm2835-v4l2: Add a build system for the 
module.")
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/media/platform/bcm2835/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/media/platform/bcm2835/Makefile 
b/drivers/staging/media/platform/bcm2835/Makefile
index d7900a5951a8..8307f30517d5 100644
--- a/drivers/staging/media/platform/bcm2835/Makefile
+++ b/drivers/staging/media/platform/bcm2835/Makefile
@@ -7,5 +7,4 @@ obj-$(CONFIG_VIDEO_BCM2835) += bcm2835-v4l2.o
 
 ccflags-y += \
-Idrivers/staging/vc04_services \
-   -Idrivers/staging/vc04_services/interface/vcos/linuxkernel \
-D__VCCOREVER__=0x0400
-- 
2.9.0

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


[PATCH v6 04/10] [media] MAINTAINERS: add st-delta driver

2017-02-01 Thread Hugues Fruchet
Add entry for the STMicroelectronics DELTA driver.

Signed-off-by: Hugues Fruchet 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cfff2c9..38cc652 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2429,6 +2429,14 @@ W:   https://linuxtv.org
 S: Supported
 F: drivers/media/platform/sti/bdisp
 
+DELTA ST MEDIA DRIVER
+M: Hugues Fruchet 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: https://linuxtv.org
+S: Supported
+F: drivers/media/platform/sti/delta
+
 BEFS FILE SYSTEM
 M: Luis de Bethencourt 
 M: Salah Triki 
-- 
1.9.1

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


[PATCH v6 01/10] Documentation: DT: add bindings for ST DELTA

2017-02-01 Thread Hugues Fruchet
This patch adds DT binding documentation for STMicroelectronics
DELTA V4L2 video decoder.

Signed-off-by: Hugues Fruchet 
---
 Documentation/devicetree/bindings/media/st,st-delta.txt | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,st-delta.txt

diff --git a/Documentation/devicetree/bindings/media/st,st-delta.txt 
b/Documentation/devicetree/bindings/media/st,st-delta.txt
new file mode 100644
index 000..a538ab3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,st-delta.txt
@@ -0,0 +1,17 @@
+* STMicroelectronics DELTA multi-format video decoder
+
+Required properties:
+- compatible: should be "st,st-delta".
+- clocks: from common clock binding: handle hardware IP needed clocks, the
+  number of clocks may depend on the SoC type.
+  See ../clock/clock-bindings.txt for details.
+- clock-names: names of the clocks listed in clocks property in the same order.
+
+Example:
+   delta0 {
+   compatible = "st,st-delta";
+   clock-names = "delta", "delta-st231", "delta-flash-promip";
+   clocks = <_s_c0_flexgen CLK_VID_DMU>,
+<_s_c0_flexgen CLK_ST231_DMU>,
+<_s_c0_flexgen CLK_FLASH_PROMIP>;
+   };
-- 
1.9.1

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


[PATCH v6 05/10] [media] st-delta: STiH4xx multi-format video decoder v4l2 driver

2017-02-01 Thread Hugues Fruchet
This V4L2 driver enables DELTA multi-format video decoder
of STMicroelectronics STiH4xx SoC series.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/Kconfig|   28 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/sti/delta/Makefile |2 +
 drivers/media/platform/sti/delta/delta-cfg.h  |   61 +
 drivers/media/platform/sti/delta/delta-v4l2.c | 1813 +
 drivers/media/platform/sti/delta/delta.h  |  514 +++
 6 files changed, 2420 insertions(+)
 create mode 100644 drivers/media/platform/sti/delta/Makefile
 create mode 100644 drivers/media/platform/sti/delta/delta-cfg.h
 create mode 100644 drivers/media/platform/sti/delta/delta-v4l2.c
 create mode 100644 drivers/media/platform/sti/delta/delta.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421..2247d9d 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -298,6 +298,34 @@ config VIDEO_STI_HVA
  To compile this driver as a module, choose M here:
  the module will be called st-hva.
 
+config VIDEO_STI_DELTA
+   tristate "STMicroelectronics DELTA multi-format video decoder V4L2 
driver"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_STI || COMPILE_TEST
+   depends on HAS_DMA
+   help
+   This V4L2 driver enables DELTA multi-format video decoder
+   of STMicroelectronics STiH4xx SoC series allowing hardware
+   decoding of various compressed video bitstream format in
+   raw uncompressed format.
+
+   Use this option to see the decoders available for such
+   hardware.
+
+   Please notice that the driver will only be built if
+   at least one of the DELTA decoder below is selected.
+
+if VIDEO_STI_DELTA
+
+config VIDEO_STI_DELTA_DRIVER
+   tristate
+   depends on VIDEO_STI_DELTA
+   default n
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+
+endif # VIDEO_STI_DELTA
+
 config VIDEO_SH_VEU
tristate "SuperH VEU mem2mem video processing driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 5b3cb27..349ddf6 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -39,6 +39,8 @@ obj-$(CONFIG_VIDEO_STI_BDISP) += sti/bdisp/
 obj-$(CONFIG_VIDEO_STI_HVA)+= sti/hva/
 obj-$(CONFIG_DVB_C8SECTPFE)+= sti/c8sectpfe/
 
+obj-$(CONFIG_VIDEO_STI_DELTA)  += sti/delta/
+
 obj-$(CONFIG_BLACKFIN)  += blackfin/
 
 obj-$(CONFIG_ARCH_DAVINCI) += davinci/
diff --git a/drivers/media/platform/sti/delta/Makefile 
b/drivers/media/platform/sti/delta/Makefile
new file mode 100644
index 000..467519e
--- /dev/null
+++ b/drivers/media/platform/sti/delta/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_VIDEO_STI_DELTA_DRIVER) := st-delta.o
+st-delta-y := delta-v4l2.o
diff --git a/drivers/media/platform/sti/delta/delta-cfg.h 
b/drivers/media/platform/sti/delta/delta-cfg.h
new file mode 100644
index 000..f6674f6
--- /dev/null
+++ b/drivers/media/platform/sti/delta/delta-cfg.h
@@ -0,0 +1,61 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Author: Hugues Fruchet  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#ifndef DELTA_CFG_H
+#define DELTA_CFG_H
+
+#define DELTA_FW_VERSION "21.1-3"
+
+#define DELTA_MIN_WIDTH  32
+#define DELTA_MAX_WIDTH  4096
+#define DELTA_MIN_HEIGHT 32
+#define DELTA_MAX_HEIGHT 2400
+
+/* DELTA requires a 32x32 pixels alignment for frames */
+#define DELTA_WIDTH_ALIGNMENT32
+#define DELTA_HEIGHT_ALIGNMENT   32
+
+#define DELTA_DEFAULT_WIDTH  DELTA_MIN_WIDTH
+#define DELTA_DEFAULT_HEIGHT DELTA_MIN_HEIGHT
+#define DELTA_DEFAULT_FRAMEFORMAT  V4L2_PIX_FMT_NV12
+#define DELTA_DEFAULT_STREAMFORMAT V4L2_PIX_FMT_MJPEG
+
+#define DELTA_MAX_RESO (DELTA_MAX_WIDTH * DELTA_MAX_HEIGHT)
+
+/* guard value for number of access units */
+#define DELTA_MAX_AUS 10
+
+/* IP perf dependent, can be tuned */
+#define DELTA_PEAK_FRAME_SMOOTHING 2
+
+/*
+ * guard output frame count:
+ * - at least 1 frame needed for display
+ * - at worst 21
+ *   ( max h264 dpb (16) +
+ * decoding peak smoothing (2) +
+ * user display pipeline (3) )
+ */
+#define DELTA_MIN_FRAME_USER1
+#define DELTA_MAX_DPB   16
+#define DELTA_MAX_FRAME_USER3 /* platform/use-case dependent */
+#define DELTA_MAX_FRAMES (DELTA_MAX_DPB + DELTA_PEAK_FRAME_SMOOTHING +\
+ DELTA_MAX_FRAME_USER)
+
+#if DELTA_MAX_FRAMES > VIDEO_MAX_FRAME
+#undef DELTA_MAX_FRAMES
+#define DELTA_MAX_FRAMES (VIDEO_MAX_FRAME)
+#endif
+
+/* extra space to be allocated to store codec specific data per frame */
+#define DELTA_MAX_FRAME_PRIV_SIZE 100
+
+/* PM runtime auto power-off after 5ms 

[PATCH v6 06/10] [media] st-delta: add memory allocator helper functions

2017-02-01 Thread Hugues Fruchet
Helper functions used by decoder back-ends to allocate
physically contiguous memory required by hardware video
decoder.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/sti/delta/Makefile|  2 +-
 drivers/media/platform/sti/delta/delta-mem.c | 51 
 drivers/media/platform/sti/delta/delta-mem.h | 14 
 drivers/media/platform/sti/delta/delta.h |  8 +
 4 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/sti/delta/delta-mem.c
 create mode 100644 drivers/media/platform/sti/delta/delta-mem.h

diff --git a/drivers/media/platform/sti/delta/Makefile 
b/drivers/media/platform/sti/delta/Makefile
index 467519e..93a3037 100644
--- a/drivers/media/platform/sti/delta/Makefile
+++ b/drivers/media/platform/sti/delta/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_VIDEO_STI_DELTA_DRIVER) := st-delta.o
-st-delta-y := delta-v4l2.o
+st-delta-y := delta-v4l2.o delta-mem.o
diff --git a/drivers/media/platform/sti/delta/delta-mem.c 
b/drivers/media/platform/sti/delta/delta-mem.c
new file mode 100644
index 000..d7b53d3
--- /dev/null
+++ b/drivers/media/platform/sti/delta/delta-mem.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Author: Hugues Fruchet  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include "delta.h"
+#include "delta-mem.h"
+
+int hw_alloc(struct delta_ctx *ctx, u32 size, const char *name,
+struct delta_buf *buf)
+{
+   struct delta_dev *delta = ctx->dev;
+   dma_addr_t dma_addr;
+   void *addr;
+   unsigned long attrs = DMA_ATTR_WRITE_COMBINE;
+
+   addr = dma_alloc_attrs(delta->dev, size, _addr,
+  GFP_KERNEL | __GFP_NOWARN, attrs);
+   if (!addr) {
+   dev_err(delta->dev,
+   "%s hw_alloc:dma_alloc_coherent failed for %s 
(size=%d)\n",
+   ctx->name, name, size);
+   ctx->sys_errors++;
+   return -ENOMEM;
+   }
+
+   buf->size = size;
+   buf->paddr = dma_addr;
+   buf->vaddr = addr;
+   buf->name = name;
+   buf->attrs = attrs;
+
+   dev_dbg(delta->dev,
+   "%s allocate %d bytes of HW memory @(virt=0x%p, phy=0x%pad): 
%s\n",
+   ctx->name, size, buf->vaddr, >paddr, buf->name);
+
+   return 0;
+}
+
+void hw_free(struct delta_ctx *ctx, struct delta_buf *buf)
+{
+   struct delta_dev *delta = ctx->dev;
+
+   dev_dbg(delta->dev,
+   "%s free %d bytes of HW memory @(virt=0x%p, phy=0x%pad): 
%s\n",
+   ctx->name, buf->size, buf->vaddr, >paddr, buf->name);
+
+   dma_free_attrs(delta->dev, buf->size,
+  buf->vaddr, buf->paddr, buf->attrs);
+}
diff --git a/drivers/media/platform/sti/delta/delta-mem.h 
b/drivers/media/platform/sti/delta/delta-mem.h
new file mode 100644
index 000..f8ca109
--- /dev/null
+++ b/drivers/media/platform/sti/delta/delta-mem.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Author: Hugues Fruchet  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#ifndef DELTA_MEM_H
+#define DELTA_MEM_H
+
+int hw_alloc(struct delta_ctx *ctx, u32 size, const char *name,
+struct delta_buf *buf);
+void hw_free(struct delta_ctx *ctx, struct delta_buf *buf);
+
+#endif /* DELTA_MEM_H */
diff --git a/drivers/media/platform/sti/delta/delta.h 
b/drivers/media/platform/sti/delta/delta.h
index 74a4240..9e26525 100644
--- a/drivers/media/platform/sti/delta/delta.h
+++ b/drivers/media/platform/sti/delta/delta.h
@@ -191,6 +191,14 @@ struct delta_dts {
u64 val;
 };
 
+struct delta_buf {
+   u32 size;
+   void *vaddr;
+   dma_addr_t paddr;
+   const char *name;
+   unsigned long attrs;
+};
+
 struct delta_ctx;
 
 /*
-- 
1.9.1

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


[PATCH v6 00/10] Add support for DELTA video decoder of STMicroelectronics STiH4xx SoC series

2017-02-01 Thread Hugues Fruchet
This patchset introduces a basic support for DELTA multi-format video
decoder of STMicroelectronics STiH4xx SoC series.

DELTA hardware IP is controlled by a remote firmware loaded in a ST231
coprocessor. Communication with firmware is done within an IPC layer
using rpmsg kernel framework and a shared memory for messages handling.
This driver is compatible with firmware version 21.1-3.
While a single firmware is loaded in ST231 coprocessor, it is composed
of several firmwares, one per video format family.

This DELTA V4L2 driver is designed around files:
  - delta-v4l2.c   : handles V4L2 APIs using M2M framework and calls decoder ops
  - delta-* : implements  decoder calling its associated
 video firmware (for ex. MJPEG) using IPC layer
  - delta-ipc.c: IPC layer which handles communication with firmware using 
rpmsg

This first basic support implements only MJPEG hardware acceleration but
the driver structure is in place to support all the features of the
DELTA video decoder hardware IP.

This driver depends on:
  - ST remoteproc/rpmsg:
- https://lkml.org/lkml/2017/1/31/389: remoteproc: st: add virtio_rpmsg 
support
- https://lkml.org/lkml/2017/1/31/415: virtio_rpmsg: make rpmsg channel 
configurable
  - ST DELTA firmware: its license is under review. When available,
pull request will be done on linux-firmware.

===
= history =
===
version 6
  - update after v5 review:
- rework configuration in order to build driver only if at least
  one decoder is selected.

version 5
  - update after v4 review:
- fixed warning in case of no decoder selected in config
- fixed multiple lines comments
  - dev_info changed to dev_dbg for summary trace (from HVA driver review)

version 4
  - update after v3 review:
- "select" RPMSG instead "depends on"
- v4l2-compliance S_SELECTION is no more failed
  till sync on latest v4l2-compliance codebase
  - sparse warnings fixes

version 3
  - update after v2 review:
- fixed m2m_buf_done missing on start_streaming error case
- fixed q->dev missing in queue_init()
- removed unsupported s_selection
- refactored string namings in delta-debug.c
- fixed space before comment
- all commits have commit messages
- reword memory allocator helper commit

version 2
  - update after v1 review:
- simplified tracing
- G_/S_SELECTION reworked to fit COMPOSE(CAPTURE)
- fixed m2m_buf_done missing on start_streaming error case
- fixed q->dev missing in queue_init()
  - switch to kernel-4.9 rpmsg API
  - DELTA support added in multi_v7_defconfig
  - minor typo fixes & code cleanup

version 1:
  - Initial submission

===
= v4l2-compliance =
===
Below is the v4l2-compliance report for the version 4 of the DELTA video
decoder driver. v4l2-compliance has been build from SHA1:
003f31e59f353b4aecc82e8fb1c7555964da7efa (v4l2-compliance: allow S_SELECTION to 
return ENOTTY)

root@sti-4:~# v4l2-compliance -d /dev/video0
v4l2-compliance SHA   : 003f31e59f353b4aecc82e8fb1c7555964da7efa

Driver Info:
Driver name   : st-delta
Card type : st-delta-21.1-3
Bus info  : platform:soc:delta0
Driver version: 4.9.0
Capabilities  : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04208000
Video Memory-to-Memory
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 (Not Supported)

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

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

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test 

[PATCH v6 02/10] ARM: dts: STiH410: add DELTA dt node

2017-02-01 Thread Hugues Fruchet
This patch adds DT node for STMicroelectronics
DELTA V4L2 video decoder

Signed-off-by: Hugues Fruchet 
---
 arch/arm/boot/dts/stih410.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index 281a124..42e070c 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -259,5 +259,15 @@
clocks = <_sysin>;
interrupts = ;
};
+   delta0 {
+   compatible = "st,st-delta";
+   clock-names = "delta",
+ "delta-st231",
+ "delta-flash-promip";
+   clocks = <_s_c0_flexgen CLK_VID_DMU>,
+<_s_c0_flexgen CLK_ST231_DMU>,
+<_s_c0_flexgen CLK_FLASH_PROMIP>;
+   };
+
};
 };
-- 
1.9.1

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


[PATCH v6 03/10] ARM: multi_v7_defconfig: enable STMicroelectronics DELTA Support

2017-02-01 Thread Hugues Fruchet
Enables support of STMicroelectronics STiH4xx SoC series
DELTA multi-format video decoder V4L2 driver.

Signed-off-by: Hugues Fruchet 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index b01a438..5dff8fe 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -569,6 +569,7 @@ CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
 CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
 CONFIG_VIDEO_STI_BDISP=m
 CONFIG_VIDEO_STI_HVA=m
+CONFIG_VIDEO_STI_DELTA=m
 CONFIG_VIDEO_RENESAS_JPU=m
 CONFIG_VIDEO_RENESAS_VSP1=m
 CONFIG_V4L_TEST_DRIVERS=y
-- 
1.9.1

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


[PATCH v6 08/10] [media] st-delta: EOS (End Of Stream) support

2017-02-01 Thread Hugues Fruchet
EOS (End Of Stream) support allows user to get
all the potential decoded frames remaining in decoder
pipeline after having reached the end of video bitstream.
To do so, user calls VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP)
which will drain the decoder and get the drained frames
that are then returned to user.
User is informed of EOS completion in two ways:
 - dequeue of an empty frame flagged to V4L2_BUF_FLAG_LAST
 - reception of a V4L2_EVENT_EOS event.
If, unfortunately, no buffer is available on CAPTURE queue
to return the empty frame, EOS is delayed till user queue
one CAPTURE buffer.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/sti/delta/delta-v4l2.c | 146 +-
 drivers/media/platform/sti/delta/delta.h  |  23 
 2 files changed, 168 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/delta/delta-v4l2.c 
b/drivers/media/platform/sti/delta/delta-v4l2.c
index 237a938..c959614 100644
--- a/drivers/media/platform/sti/delta/delta-v4l2.c
+++ b/drivers/media/platform/sti/delta/delta-v4l2.c
@@ -106,7 +106,8 @@ static void delta_frame_done(struct delta_ctx *ctx, struct 
delta_frame *frame,
vbuf->sequence = ctx->frame_num++;
v4l2_m2m_buf_done(vbuf, err ? VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
 
-   ctx->output_frames++;
+   if (frame->info.size) /* ignore EOS */
+   ctx->output_frames++;
 }
 
 static void requeue_free_frames(struct delta_ctx *ctx)
@@ -762,6 +763,135 @@ static int delta_g_selection(struct file *file, void *fh,
return 0;
 }
 
+static void delta_complete_eos(struct delta_ctx *ctx,
+  struct delta_frame *frame)
+{
+   struct delta_dev *delta = ctx->dev;
+   const struct v4l2_event ev = {.type = V4L2_EVENT_EOS};
+
+   /*
+* Send EOS to user:
+* - by returning an empty frame flagged to V4L2_BUF_FLAG_LAST
+* - and then send EOS event
+*/
+
+   /* empty frame */
+   frame->info.size = 0;
+
+   /* set the last buffer flag */
+   frame->flags |= V4L2_BUF_FLAG_LAST;
+
+   /* release frame to user */
+   delta_frame_done(ctx, frame, 0);
+
+   /* send EOS event */
+   v4l2_event_queue_fh(>fh, );
+
+   dev_dbg(delta->dev, "%s EOS completed\n", ctx->name);
+}
+
+static int delta_try_decoder_cmd(struct file *file, void *fh,
+struct v4l2_decoder_cmd *cmd)
+{
+   if (cmd->cmd != V4L2_DEC_CMD_STOP)
+   return -EINVAL;
+
+   if (cmd->flags & V4L2_DEC_CMD_STOP_TO_BLACK)
+   return -EINVAL;
+
+   if (!(cmd->flags & V4L2_DEC_CMD_STOP_IMMEDIATELY) &&
+   (cmd->stop.pts != 0))
+   return -EINVAL;
+
+   return 0;
+}
+
+static int delta_decoder_stop_cmd(struct delta_ctx *ctx, void *fh)
+{
+   const struct delta_dec *dec = ctx->dec;
+   struct delta_dev *delta = ctx->dev;
+   struct delta_frame *frame = NULL;
+   int ret = 0;
+
+   dev_dbg(delta->dev, "%s EOS received\n", ctx->name);
+
+   if (ctx->state != DELTA_STATE_READY)
+   return 0;
+
+   /* drain the decoder */
+   call_dec_op(dec, drain, ctx);
+
+   /* release to user drained frames */
+   while (1) {
+   frame = NULL;
+   ret = call_dec_op(dec, get_frame, ctx, );
+   if (ret == -ENODATA) {
+   /* no more decoded frames */
+   break;
+   }
+   if (frame) {
+   dev_dbg(delta->dev, "%s drain frame[%d]\n",
+   ctx->name, frame->index);
+
+   /* pop timestamp and mark frame with it */
+   delta_pop_dts(ctx, >dts);
+
+   /* release decoded frame to user */
+   delta_frame_done(ctx, frame, 0);
+   }
+   }
+
+   /* try to complete EOS */
+   ret = delta_get_free_frame(ctx, );
+   if (ret)
+   goto delay_eos;
+
+   /* new frame available, EOS can now be completed */
+   delta_complete_eos(ctx, frame);
+
+   ctx->state = DELTA_STATE_EOS;
+
+   return 0;
+
+delay_eos:
+   /*
+* EOS completion from driver is delayed because
+* we don't have a free empty frame available.
+* EOS completion is so delayed till next frame_queue() call
+* to be sure to have a free empty frame available.
+*/
+   ctx->state = DELTA_STATE_WF_EOS;
+   dev_dbg(delta->dev, "%s EOS delayed\n", ctx->name);
+
+   return 0;
+}
+
+static int delta_decoder_cmd(struct file *file, void *fh,
+struct v4l2_decoder_cmd *cmd)
+{
+   struct delta_ctx *ctx = to_ctx(fh);
+   int ret = 0;
+
+   ret = delta_try_decoder_cmd(file, fh, cmd);
+   if (ret)
+   return ret;
+
+   return delta_decoder_stop_cmd(ctx, fh);
+}
+
+static int 

[PATCH v6 09/10] [media] st-delta: add mjpeg support

2017-02-01 Thread Hugues Fruchet
Adds support of DELTA MJPEG video decoder back-end,
implemented by calling JPEG_DECODER_HW0 firmware
using RPMSG IPC communication layer.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/Kconfig |  12 +-
 drivers/media/platform/sti/delta/Makefile  |   4 +
 drivers/media/platform/sti/delta/delta-cfg.h   |   3 +
 drivers/media/platform/sti/delta/delta-mjpeg-dec.c | 455 +
 drivers/media/platform/sti/delta/delta-mjpeg-fw.h  | 225 ++
 drivers/media/platform/sti/delta/delta-mjpeg-hdr.c | 149 +++
 drivers/media/platform/sti/delta/delta-mjpeg.h |  35 ++
 drivers/media/platform/sti/delta/delta-v4l2.c  |   3 +
 8 files changed, 885 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg-dec.c
 create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg-fw.h
 create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg-hdr.c
 create mode 100644 drivers/media/platform/sti/delta/delta-mjpeg.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 2e82ec6..20b26ea 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -317,10 +317,20 @@ config VIDEO_STI_DELTA
 
 if VIDEO_STI_DELTA
 
+config VIDEO_STI_DELTA_MJPEG
+   bool "STMicroelectronics DELTA MJPEG support"
+   default y
+   help
+   Enables DELTA MJPEG hardware support.
+
+   To compile this driver as a module, choose M here:
+   the module will be called st-delta.
+
 config VIDEO_STI_DELTA_DRIVER
tristate
depends on VIDEO_STI_DELTA
-   default n
+   depends on VIDEO_STI_DELTA_MJPEG
+   default VIDEO_STI_DELTA_MJPEG
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
select RPMSG
diff --git a/drivers/media/platform/sti/delta/Makefile 
b/drivers/media/platform/sti/delta/Makefile
index b791ba0..b268df6 100644
--- a/drivers/media/platform/sti/delta/Makefile
+++ b/drivers/media/platform/sti/delta/Makefile
@@ -1,2 +1,6 @@
 obj-$(CONFIG_VIDEO_STI_DELTA_DRIVER) := st-delta.o
 st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o
+
+# MJPEG support
+st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-hdr.o
+st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-dec.o
diff --git a/drivers/media/platform/sti/delta/delta-cfg.h 
b/drivers/media/platform/sti/delta/delta-cfg.h
index f6674f6..c6388f5 100644
--- a/drivers/media/platform/sti/delta/delta-cfg.h
+++ b/drivers/media/platform/sti/delta/delta-cfg.h
@@ -57,5 +57,8 @@
 #define DELTA_HW_AUTOSUSPEND_DELAY_MS 5
 
 #define DELTA_MAX_DECODERS 10
+#ifdef CONFIG_VIDEO_STI_DELTA_MJPEG
+extern const struct delta_dec mjpegdec;
+#endif
 
 #endif /* DELTA_CFG_H */
diff --git a/drivers/media/platform/sti/delta/delta-mjpeg-dec.c 
b/drivers/media/platform/sti/delta/delta-mjpeg-dec.c
new file mode 100644
index 000..e79bdc6
--- /dev/null
+++ b/drivers/media/platform/sti/delta/delta-mjpeg-dec.c
@@ -0,0 +1,455 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2013
+ * Author: Hugues Fruchet  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+
+#include "delta.h"
+#include "delta-ipc.h"
+#include "delta-mjpeg.h"
+#include "delta-mjpeg-fw.h"
+
+#define DELTA_MJPEG_MAX_RESO DELTA_MAX_RESO
+
+struct delta_mjpeg_ctx {
+   /* jpeg header */
+   struct mjpeg_header header_struct;
+   struct mjpeg_header *header;
+
+   /* ipc */
+   void *ipc_hdl;
+   struct delta_buf *ipc_buf;
+
+   /* decoded output frame */
+   struct delta_frame *out_frame;
+
+   unsigned char str[3000];
+};
+
+#define to_ctx(ctx) ((struct delta_mjpeg_ctx *)(ctx)->priv)
+
+static char *ipc_open_param_str(struct jpeg_video_decode_init_params_t *p,
+   char *str, unsigned int len)
+{
+   char *b = str;
+
+   if (!p)
+   return "";
+
+   b += snprintf(b, len,
+ "jpeg_video_decode_init_params_t\n"
+ "circular_buffer_begin_addr_p 0x%x\n"
+ "circular_buffer_end_addr_p   0x%x\n",
+ p->circular_buffer_begin_addr_p,
+ p->circular_buffer_end_addr_p);
+
+   return str;
+}
+
+static char *ipc_decode_param_str(struct jpeg_decode_params_t *p,
+ char *str, unsigned int len)
+{
+   char *b = str;
+
+   if (!p)
+   return "";
+
+   b += snprintf(b, len,
+ "jpeg_decode_params_t\n"
+ "picture_start_addr_p  0x%x\n"
+ "picture_end_addr_p0x%x\n"
+ "decoding_mode%d\n"
+ "display_buffer_addr.display_decimated_luma_p   0x%x\n"
+ "display_buffer_addr.display_decimated_chroma_p 0x%x\n"
+   

[PATCH v6 07/10] [media] st-delta: rpmsg ipc support

2017-02-01 Thread Hugues Fruchet
IPC (Inter Process Communication) support for communication with
DELTA coprocessor firmware using rpmsg kernel framework.
Based on 4 services open/set_stream/decode/close and their associated
rpmsg messages.
The messages structures are duplicated on both host and firmware
side and are packed (use only of 32 bits size fields in messages
structures to ensure packing).
Each service is synchronous; service returns only when firmware
acknowledges the associated command message.
Due to significant parameters size exchanged from host to copro,
parameters are not inserted in rpmsg messages. Instead, parameters are
stored in physical memory shared between host and coprocessor.
Memory is non-cacheable, so no special operation is required
to ensure memory coherency on host and on coprocessor side.
Multi-instance support and re-entrance are ensured using host_hdl and
copro_hdl in message header exchanged between both host and coprocessor.
This avoids to manage tables on both sides to get back the running context
of each instance.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/Kconfig|   1 +
 drivers/media/platform/sti/delta/Makefile |   2 +-
 drivers/media/platform/sti/delta/delta-ipc.c  | 594 ++
 drivers/media/platform/sti/delta/delta-ipc.h  |  76 
 drivers/media/platform/sti/delta/delta-v4l2.c |  11 +
 drivers/media/platform/sti/delta/delta.h  |  21 +
 6 files changed, 704 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/sti/delta/delta-ipc.c
 create mode 100644 drivers/media/platform/sti/delta/delta-ipc.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 2247d9d..2e82ec6 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -323,6 +323,7 @@ config VIDEO_STI_DELTA_DRIVER
default n
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
+   select RPMSG
 
 endif # VIDEO_STI_DELTA
 
diff --git a/drivers/media/platform/sti/delta/Makefile 
b/drivers/media/platform/sti/delta/Makefile
index 93a3037..b791ba0 100644
--- a/drivers/media/platform/sti/delta/Makefile
+++ b/drivers/media/platform/sti/delta/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_VIDEO_STI_DELTA_DRIVER) := st-delta.o
-st-delta-y := delta-v4l2.o delta-mem.o
+st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o
diff --git a/drivers/media/platform/sti/delta/delta-ipc.c 
b/drivers/media/platform/sti/delta/delta-ipc.c
new file mode 100644
index 000..41e4a4c
--- /dev/null
+++ b/drivers/media/platform/sti/delta/delta-ipc.c
@@ -0,0 +1,594 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Author: Hugues Fruchet  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+
+#include "delta.h"
+#include "delta-ipc.h"
+#include "delta-mem.h"
+
+#define IPC_TIMEOUT 100
+#define IPC_SANITY_TAG 0xDEADBEEF
+
+enum delta_ipc_fw_command {
+   DELTA_IPC_OPEN,
+   DELTA_IPC_SET_STREAM,
+   DELTA_IPC_DECODE,
+   DELTA_IPC_CLOSE
+};
+
+#define to_rpmsg_driver(__drv) container_of(__drv, struct rpmsg_driver, drv)
+#define to_delta(__d) container_of(__d, struct delta_dev, rpmsg_driver)
+
+#define to_ctx(hdl) ((struct delta_ipc_ctx *)hdl)
+#define to_pctx(ctx) container_of(ctx, struct delta_ctx, ipc_ctx)
+
+struct delta_ipc_header_msg {
+   u32 tag;
+   void *host_hdl;
+   u32 copro_hdl;
+   u32 command;
+};
+
+#define to_host_hdl(ctx) ((void *)ctx)
+
+#define msg_to_ctx(msg) ((struct delta_ipc_ctx *)(msg)->header.host_hdl)
+#define msg_to_copro_hdl(msg) ((msg)->header.copro_hdl)
+
+static inline dma_addr_t to_paddr(struct delta_ipc_ctx *ctx, void *vaddr)
+{
+   return (ctx->ipc_buf->paddr + (vaddr - ctx->ipc_buf->vaddr));
+}
+
+static inline bool is_valid_data(struct delta_ipc_ctx *ctx,
+void *data, u32 size)
+{
+   return ((data >= ctx->ipc_buf->vaddr) &&
+   ((data + size) <= (ctx->ipc_buf->vaddr + ctx->ipc_buf->size)));
+}
+
+/*
+ * IPC shared memory (@ipc_buf_size, @ipc_buf_paddr) is sent to copro
+ * at each instance opening. This memory is allocated by IPC client
+ * and given through delta_ipc_open(). All messages parameters
+ * (open, set_stream, decode) will have their phy address within
+ * this IPC shared memory, avoiding de-facto recopies inside delta-ipc.
+ * All the below messages structures are used on both host and firmware
+ * side and are packed (use only of 32 bits size fields in messages
+ * structures to ensure packing):
+ * - struct delta_ipc_open_msg
+ * - struct delta_ipc_set_stream_msg
+ * - struct delta_ipc_decode_msg
+ * - struct delta_ipc_close_msg
+ * - struct delta_ipc_cb_msg
+ */
+struct delta_ipc_open_msg {
+   struct delta_ipc_header_msg header;
+   u32 ipc_buf_size;
+   dma_addr_t ipc_buf_paddr;
+   char name[32];
+   u32 param_size;
+   dma_addr_t param_paddr;
+};
+
+struct 

[PATCH v6 10/10] st-delta: debug: trace stream/frame information & summary

2017-02-01 Thread Hugues Fruchet
Adds some trace points showing input compressed stream or
output decoded frame information.
Adds an unconditional trace point when streaming starts showing
the compressed stream and the decoded frame information.
Adds an unconditional trace point at instance closure summarizing
into a single line the decoding process (stream information, decoded
and output frames number, potential errors observed).

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/sti/delta/Makefile  |  2 +-
 drivers/media/platform/sti/delta/delta-debug.c | 72 ++
 drivers/media/platform/sti/delta/delta-debug.h | 18 +++
 drivers/media/platform/sti/delta/delta-v4l2.c  | 30 +--
 4 files changed, 117 insertions(+), 5 deletions(-)
 create mode 100644 drivers/media/platform/sti/delta/delta-debug.c
 create mode 100644 drivers/media/platform/sti/delta/delta-debug.h

diff --git a/drivers/media/platform/sti/delta/Makefile 
b/drivers/media/platform/sti/delta/Makefile
index b268df6..8d032508 100644
--- a/drivers/media/platform/sti/delta/Makefile
+++ b/drivers/media/platform/sti/delta/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_VIDEO_STI_DELTA_DRIVER) := st-delta.o
-st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o
+st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o delta-debug.o
 
 # MJPEG support
 st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-hdr.o
diff --git a/drivers/media/platform/sti/delta/delta-debug.c 
b/drivers/media/platform/sti/delta/delta-debug.c
new file mode 100644
index 000..a7ebf2c
--- /dev/null
+++ b/drivers/media/platform/sti/delta/delta-debug.c
@@ -0,0 +1,72 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Authors: Hugues Fruchet 
+ *  Fabrice Lecoultre 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include "delta.h"
+#include "delta-debug.h"
+
+char *delta_streaminfo_str(struct delta_streaminfo *s, char *str,
+  unsigned int len)
+{
+   if (!s)
+   return NULL;
+
+   snprintf(str, len,
+"%4.4s %dx%d %s %s dpb=%d %s %s %s%dx%d@(%d,%d) %s%d/%d",
+(char *)>streamformat, s->width, s->height,
+s->profile, s->level, s->dpb,
+(s->field == V4L2_FIELD_NONE) ? "progressive" : "interlaced",
+s->other,
+s->flags & DELTA_STREAMINFO_FLAG_CROP ? "crop=" : "",
+s->crop.width, s->crop.height,
+s->crop.left, s->crop.top,
+s->flags & DELTA_STREAMINFO_FLAG_PIXELASPECT ? "par=" : "",
+s->pixelaspect.numerator,
+s->pixelaspect.denominator);
+
+   return str;
+}
+
+char *delta_frameinfo_str(struct delta_frameinfo *f, char *str,
+ unsigned int len)
+{
+   if (!f)
+   return NULL;
+
+   snprintf(str, len,
+"%4.4s %dx%d aligned %dx%d %s %s%dx%d@(%d,%d) %s%d/%d",
+(char *)>pixelformat, f->width, f->height,
+f->aligned_width, f->aligned_height,
+(f->field == V4L2_FIELD_NONE) ? "progressive" : "interlaced",
+f->flags & DELTA_STREAMINFO_FLAG_CROP ? "crop=" : "",
+f->crop.width, f->crop.height,
+f->crop.left, f->crop.top,
+f->flags & DELTA_STREAMINFO_FLAG_PIXELASPECT ? "par=" : "",
+f->pixelaspect.numerator,
+f->pixelaspect.denominator);
+
+   return str;
+}
+
+void delta_trace_summary(struct delta_ctx *ctx)
+{
+   struct delta_dev *delta = ctx->dev;
+   struct delta_streaminfo *s = >streaminfo;
+   unsigned char str[100] = "";
+
+   if (!(ctx->flags & DELTA_FLAG_STREAMINFO))
+   return;
+
+   dev_dbg(delta->dev, "%s %s, %d frames decoded, %d frames output, %d 
frames dropped, %d stream errors, %d decode errors",
+   ctx->name,
+   delta_streaminfo_str(s, str, sizeof(str)),
+   ctx->decoded_frames,
+   ctx->output_frames,
+   ctx->dropped_frames,
+   ctx->stream_errors,
+   ctx->decode_errors);
+}
diff --git a/drivers/media/platform/sti/delta/delta-debug.h 
b/drivers/media/platform/sti/delta/delta-debug.h
new file mode 100644
index 000..955c158
--- /dev/null
+++ b/drivers/media/platform/sti/delta/delta-debug.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Authors: Hugues Fruchet 
+ *  Fabrice Lecoultre 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#ifndef DELTA_DEBUG_H
+#define DELTA_DEBUG_H
+
+char *delta_streaminfo_str(struct delta_streaminfo *s, char *str,
+  unsigned int len);
+char *delta_frameinfo_str(struct delta_frameinfo *f, char *str,
+   

Re: [GIT PULL FOR v4.11] New st-delta driver

2017-02-01 Thread Hugues FRUCHET


On 02/01/2017 11:39 AM, Mauro Carvalho Chehab wrote:
> Em Tue, 31 Jan 2017 15:16:10 +
> Hugues FRUCHET  escreveu:
>
>> On 01/30/2017 08:18 PM, Mauro Carvalho Chehab wrote:
>>> Em Mon, 30 Jan 2017 17:15:36 -0200
>>> Mauro Carvalho Chehab  escreveu:
>>>
 Em Mon, 9 Jan 2017 14:23:33 +0100
 Hans Verkuil  escreveu:

> See the v4 series for details:
>
> https://www.spinics.net/lists/linux-media/msg108737.html
>
> Regards,
>
>   Hans
>
> The following changes since commit 
> 40eca140c404505c09773d1c6685d818cb55ab1a:
>
>   [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)
>
> are available in the git repository at:
>
>   git://linuxtv.org/hverkuil/media_tree.git delta
>
> for you to fetch changes up to e6f199d01e7b8bc4436738b6c666fda31b9f3340:
>
>   st-delta: debug: trace stream/frame information & summary (2017-01-09 
> 14:16:45 +0100)
>
> 
> Hugues Fruchet (10):
>   Documentation: DT: add bindings for ST DELTA
>   ARM: dts: STiH410: add DELTA dt node
>   ARM: multi_v7_defconfig: enable STMicroelectronics DELTA Support
>   MAINTAINERS: add st-delta driver
>   st-delta: STiH4xx multi-format video decoder v4l2 driver
>   st-delta: add memory allocator helper functions
>   st-delta: rpmsg ipc support
>   st-delta: EOS (End Of Stream) support
>   st-delta: add mjpeg support
>   st-delta: debug: trace stream/frame information & summary

 There is something wrong on this driver... even after applying all
 patches, it complains that there's a for there that does nothing:

 drivers/media/platform/sti/delta/delta-v4l2.c:322 register_decoders() 
 warn: we never enter this loop
 drivers/media/platform/sti/delta/delta-v4l2.c: In function 
 'register_decoders':
 drivers/media/platform/sti/delta/delta-v4l2.c:322:16: warning: comparison 
 of unsigned expression < 0 is always false [-Wtype-limits]
   for (i = 0; i < ARRAY_SIZE(delta_decoders); i++) {
 ^
>>
>> Hi Mauro,
>>
>> It's strange that you face this warning, code is like that:
>> /* registry of available decoders */
>> static const struct delta_dec *delta_decoders[] = {
>> #ifdef CONFIG_VIDEO_STI_DELTA_MJPEG
>>  ,
>> #endif
>> };
>>
>> and MJPEG config is enabled by default:
>> config VIDEO_STI_DELTA_MJPEG
>>  bool "STMicroelectronics DELTA MJPEG support"
>>  default y
>>
>> so you should not encounter this warning.
>>
>> On the other hand, you face issue on line 322 of delta-v4l2.c but in my
>> codebase, and also in Hans' git tree
>> (git://linuxtv.org/hverkuil/media_tree.git delta), this code is at line 323.
>
> Well, here I compile everything patch per patch.
>
>>
>> Anyway, in order to prevent such warning even if no decoder are selected
>> in config, I have reworked the code in v5 adding a "NULL"
>> element at the end of decoder array out of any config switch:
>> static const struct delta_dec *delta_decoders[] = {
>> #ifdef CONFIG_VIDEO_STI_DELTA_MJPEG
>>  ,
>> #endif
>>  NULL,
>> };
>
> That just hides the warning. The real problem here is that, if
> someone compiles just the main driver with no decoder drivers, it
> will get an useless driver.
>
> It only makes sense to build VIDEO_STI_DELTA if at least one of
> the "daughter" drivers is built.
>
> Assuming that, on some future, you add a MPEG decoder, I guess the
> best way to address it would be to have something like this at the
> Kconfig:
>
> config VIDEO_STI_DELTA
>   tristate "STMicroelectronics STiH4xx DELTA multi-format video decoder 
> V4L2 driver options"
>   depends on VIDEO_DEV && VIDEO_V4L2
>   depends on ARCH_STI || COMPILE_TEST
>   depends on HAS_DMA
>   help
>   This V4L2 DELTA multi-format video decoder driver
>   of STMicroelectronics STiH4xx SoC series allow hardware
>   decoding of various compressed video bitstream format in
>   raw uncompressed format.
>
>   Use this option to see the decoders available for
>   such hardware.
>
>   Please notice that the driver will only be built if
>   at least one of the delta codecs below is selected.
>
> if VIDEO_STI_DELTA
>
> config VIDEO_STI_DELTA_MJPEG
>   bool "STMicroelectronics DELTA MJPEG support"
>   help
>   Enables the DELTA driver with MJPEG hardware support.
>
>   To compile this driver as a module, choose M here:
>   the module will be called st-delta.
>
> config VIDEO_STI_DELTA_MPEG
>   bool "STMicroelectronics DELTA MPEG support"
>   help
>   Enables the DELTA driver with MPEG hardware support.
>
>   To compile this driver as a 

[PATCH 1/1] et8ek8: Fix compiler / Coccinelle warnings

2017-02-01 Thread Sakari Ailus
Fix a compiler warning due to an unused but assigned variable. Also remove
an extra semicolon found by Coccinelle script
scripts/coccinelle/misc/semicolon.cocci.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/et8ek8/et8ek8_driver.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c 
b/drivers/media/i2c/et8ek8/et8ek8_driver.c
index 2df3ff4..bec4a56 100644
--- a/drivers/media/i2c/et8ek8/et8ek8_driver.c
+++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
@@ -1109,7 +1109,7 @@ static int et8ek8_g_priv_mem(struct v4l2_subdev *subdev)
if (!(status & 0x08))
break;
usleep_range(1000, 2000);
-   };
+   }
 
if (i == 1000)
return -EIO;
@@ -1259,7 +1259,6 @@ et8ek8_registered(struct v4l2_subdev *subdev)
 {
struct et8ek8_sensor *sensor = to_et8ek8_sensor(subdev);
struct i2c_client *client = v4l2_get_subdevdata(subdev);
-   struct v4l2_mbus_framefmt *format;
int rval;
 
dev_dbg(>dev, "registered!");
@@ -1280,8 +1279,8 @@ et8ek8_registered(struct v4l2_subdev *subdev)
goto err_file;
}
 
-   format = __et8ek8_get_pad_format(sensor, NULL, 0,
-V4L2_SUBDEV_FORMAT_ACTIVE);
+   __et8ek8_get_pad_format(sensor, NULL, 0, V4L2_SUBDEV_FORMAT_ACTIVE);
+
return 0;
 
 err_file:
-- 
2.1.4

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


Re: [GIT PULL FOR v4.11] Add et8ek8 driver

2017-02-01 Thread Sakari Ailus
Hi Mauro,

On Tue, Jan 31, 2017 at 11:01:11AM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 31 Jan 2017 14:45:34 +0200
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > On Tue, Jan 31, 2017 at 10:42:48AM -0200, Mauro Carvalho Chehab wrote:
> > > That added a new warning:
> > > 
> > > drivers/media/i2c/et8ek8/et8ek8_driver.c: In function 'et8ek8_registered':
> > > drivers/media/i2c/et8ek8/et8ek8_driver.c:1262:29: warning: variable 
> > > 'format' set but not used [-Wunused-but-set-variable]
> > >   struct v4l2_mbus_framefmt *format;
> > >  ^~
> > > compilation succeeded
> > > 
> > > 
> > > The driver is calling this function and storing it on a var
> > > that is not used:
> > > 
> > > format = __et8ek8_get_pad_format(sensor, NULL, 0,
> > >  V4L2_SUBDEV_FORMAT_ACTIVE);
> > > return 0;
> > > 
> > > Please send a fixup patch.  
> > 
> > I compiled it, too, but I guess I had a GCC version that didn't complain
> > about this particular matter. I'll send you a fix.
> 
> I run make with "W=1", to enable a few extra warnings that are usually
> troubles, like the above. W=2 would point some other things, but
> IMHO, it is not worth trying to fix the extra warnings, as it will enable
> a lot of signed/unsigned errors with are usually OK.

I couldn't reproduce the warnings but I'm providing a patch nonetheless,
also removing the extra semicolon.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv2] v4l: of: check for unique lanes in data-lanes and clock-lanes

2017-02-01 Thread Laurent Pinchart
Hi Niklas,

Thank you for the patch.

By the way, you can use

git format-patch -v2

to automatically add "v2" to the subject line.

On Tuesday 31 Jan 2017 13:08:31 Niklas Söderlund wrote:
> All lanes in data-lanes and clock-lanes properties should be unique. Add
> a check for this in v4l2_of_parse_csi_bus() and print a warning if
> duplicated lanes are found.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
> 
> Changes since v1:
> 
> - Do not return -EINVAL if a duplicate is found. Sakari pointed out
>   there are drivers where the number of lanes matter but not the actual
>   lane numbers. Updated commit message to highlight that only a warning
>   is printed.
> - Switched to a bitmask to track lanes used instead of a nested loop,
>   thanks Laurent for the suggestion.
> 
> 
>  drivers/media/v4l2-core/v4l2-of.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-of.c
> b/drivers/media/v4l2-core/v4l2-of.c index
> 93b33681776ca427..4f59f442dd0a64c9 100644
> --- a/drivers/media/v4l2-core/v4l2-of.c
> +++ b/drivers/media/v4l2-core/v4l2-of.c
> @@ -26,7 +26,7 @@ static int v4l2_of_parse_csi_bus(const struct device_node
> *node, struct v4l2_of_bus_mipi_csi2 *bus = >bus.mipi_csi2;
>   struct property *prop;
>   bool have_clk_lane = false;
> - unsigned int flags = 0;
> + unsigned int flags = 0, lanes_used = 0;
>   u32 v;
> 
>   prop = of_find_property(node, "data-lanes", NULL);
> @@ -38,6 +38,12 @@ static int v4l2_of_parse_csi_bus(const struct device_node
> *node, lane = of_prop_next_u32(prop, lane, );
>   if (!lane)
>   break;
> +
> + if (lanes_used & BIT(v))
> + pr_warn("%s: duplicated lane %u in data-
lanes\n",
> + node->full_name, v);
> + lanes_used |= BIT(v);
> +
>   bus->data_lanes[i] = v;
>   }
>   bus->num_data_lanes = i;
> @@ -63,6 +69,11 @@ static int v4l2_of_parse_csi_bus(const struct device_node
> *node, }
> 
>   if (!of_property_read_u32(node, "clock-lanes", )) {
> + if (lanes_used & BIT(v))
> + pr_warn("%s: duplicated lane %u in clock-lanes\n",
> + node->full_name, v);
> + lanes_used |= BIT(v);
> +
>   bus->clock_lane = v;
>   have_clk_lane = true;
>   }

-- 
Regards,

Laurent Pinchart

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


Bitte kontaktieren Sie mich für weitere Details!

2017-02-01 Thread Miss Marbell
Sehr geehrte Damen und Herren,

Ich brauche Ihre Unterstützung in Ihrem Land zu verlagern und zu 
investieren.Ich bitte Sie um Hilfe, weil ich nicht das Wissen über
Geschäft und die Regeln, die Ihr Land für eine sichere Investition führen.

Werden Sie versprechen, mit mir aufrichtig zu sein?

Bitte kontaktieren Sie mich für weitere Details!

Mit freundlichen Grüßen,
Fräulein Marbell.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 00/24] i.MX Media Driver

2017-02-01 Thread Russell King - ARM Linux
On Wed, Feb 01, 2017 at 11:42:31AM +0100, Philipp Zabel wrote:
> On Wed, 2017-02-01 at 10:11 +, Russell King - ARM Linux wrote:
> Right, it's just that in the latest version there is no v4l2_subdev for
> fifos and idmac. There is the capture interface entity that represents
> one of the IDMAC write channels, but that doesn't have a pad and format
> configuration.
> The SMFC entity was removed because the fifo can be considered part of
> the link between CSI and IDMAC. There is no manual configuration
> necessary as the SMFC itself can't do anything to the data that flows
> through it. There is no reason to present it to userspace as a no-op
> entity.
> So in the direct CSI -> SMFC -> IDMAC case, the CSI source pad now is
> the nearest neighbor pad to the IDMAC capture video device.

Ok, that sounds fine then.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 00/24] i.MX Media Driver

2017-02-01 Thread Philipp Zabel
On Wed, 2017-02-01 at 10:11 +, Russell King - ARM Linux wrote:
> On Wed, Feb 01, 2017 at 10:30:57AM +0100, Philipp Zabel wrote:
> > On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
> > [...]
> > > right, need to fix that. Probably by poking the attached
> > > source subdev (csi or prpenc/vf) for its supported formats.
> > 
> > You are right, in bayer/raw mode only one specific format should be
> > listed, depending on the CSI output pad format.
> 
> It depends what Steve means by "source subdev".
> 
> It should be the next sub-device below the bridge - if we have this
> setup of subdev's:
> 
> ---> CSI ---> SMFC ---> IDMAC
> 
> then the format configured at the SMFC's output pad is what matters,
> not what was configured at CSI.

Right, it's just that in the latest version there is no v4l2_subdev for
fifos and idmac. There is the capture interface entity that represents
one of the IDMAC write channels, but that doesn't have a pad and format
configuration.
The SMFC entity was removed because the fifo can be considered part of
the link between CSI and IDMAC. There is no manual configuration
necessary as the SMFC itself can't do anything to the data that flows
through it. There is no reason to present it to userspace as a no-op
entity.
So in the direct CSI -> SMFC -> IDMAC case, the CSI source pad now is
the nearest neighbor pad to the IDMAC capture video device.

> It's the responsibility of SMFC and CSI to make sure that their source
> pads are configured with a compatible format for their corresponding
> source pad, and it's also the sink subdev's responsibility to check
> that the configuration across a link is valid (possibly via
> v4l2_subdev_link_validate(), or a more intensive or relaxed test if
> required.)
> 
> For example:
> 
> - when CSI's source pad is configured with a RGGB output format,
>   userspace media-ctl will also set that on SMFC's sink pad.
> - when SMFC's sink pad is configured, SMFC should configure it's
>   source pad with an identical format (RGGB).
> - when SMFC's source pad is configured, it should refuse to change
>   the format, because SMFC can't modify pixel the format - it's
>   just a buffer.
>
> When starting to stream (Documentation/media/kapi/v4l2-subdev.rst) the
> link validation function is called, and:
> 
> - the SMFC driver's link_validate function will be called to validate
>   the CSI -> SMFC link.  This allows the SMFC to be sure that there's
>   a compatible configuration - and, since the link does not allow
>   format conversion, it should verify that the format on the CSI's
>   source pad is the same as SMFC's sink pad.
> 
> Not only does this match what the hardware's doing, it also means that,
> because there's no format conversion between the CSI's hardware output
> and IDMAC, we don't need to care about trying to fetch the CSI's source
> pad configuration from the IDMAC end - we can fetch that information
> from our neighbour's SMFC's source pad _or_ our own sink pad if we have
> one.

See above. All this is correct for the remaining entities, just the CSI
source pad now takes the role of the SMFC source pad as nearest neighbor
to the IDMAC capture video device.

> To see why this is an important, consider what the effect would be if
> SMFC did have the capability to change the pixel format.  That means the
> format presented to the IDMAC block would depend on the configuration of
> SMFC, and the CSI's source pad format is no longer relevant to IDMAC.

Yes, this is exactly the case for the CSI -> IC PRP -> IC PRPVF -> IDMAC
route, as the IC can do color space conversion. Here, (only) the IC
PRPVF source pad should determine the capture video device's format, and
the negotiation between CSI->IC PRP and between IC PRP->IC PRPVF should
happen as you say.

regards
Philipp

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


Re: [GIT PULL FOR v4.11] New st-delta driver

2017-02-01 Thread Mauro Carvalho Chehab
Em Tue, 31 Jan 2017 15:16:10 +
Hugues FRUCHET  escreveu:

> On 01/30/2017 08:18 PM, Mauro Carvalho Chehab wrote:
> > Em Mon, 30 Jan 2017 17:15:36 -0200
> > Mauro Carvalho Chehab  escreveu:
> >  
> >> Em Mon, 9 Jan 2017 14:23:33 +0100
> >> Hans Verkuil  escreveu:
> >>  
> >>> See the v4 series for details:
> >>>
> >>> https://www.spinics.net/lists/linux-media/msg108737.html
> >>>
> >>> Regards,
> >>>
> >>>   Hans
> >>>
> >>> The following changes since commit 
> >>> 40eca140c404505c09773d1c6685d818cb55ab1a:
> >>>
> >>>   [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)
> >>>
> >>> are available in the git repository at:
> >>>
> >>>   git://linuxtv.org/hverkuil/media_tree.git delta
> >>>
> >>> for you to fetch changes up to e6f199d01e7b8bc4436738b6c666fda31b9f3340:
> >>>
> >>>   st-delta: debug: trace stream/frame information & summary (2017-01-09 
> >>> 14:16:45 +0100)
> >>>
> >>> 
> >>> Hugues Fruchet (10):
> >>>   Documentation: DT: add bindings for ST DELTA
> >>>   ARM: dts: STiH410: add DELTA dt node
> >>>   ARM: multi_v7_defconfig: enable STMicroelectronics DELTA Support
> >>>   MAINTAINERS: add st-delta driver
> >>>   st-delta: STiH4xx multi-format video decoder v4l2 driver
> >>>   st-delta: add memory allocator helper functions
> >>>   st-delta: rpmsg ipc support
> >>>   st-delta: EOS (End Of Stream) support
> >>>   st-delta: add mjpeg support
> >>>   st-delta: debug: trace stream/frame information & summary  
> >>
> >> There is something wrong on this driver... even after applying all
> >> patches, it complains that there's a for there that does nothing:
> >>
> >> drivers/media/platform/sti/delta/delta-v4l2.c:322 register_decoders() 
> >> warn: we never enter this loop
> >> drivers/media/platform/sti/delta/delta-v4l2.c: In function 
> >> 'register_decoders':
> >> drivers/media/platform/sti/delta/delta-v4l2.c:322:16: warning: comparison 
> >> of unsigned expression < 0 is always false [-Wtype-limits]
> >>   for (i = 0; i < ARRAY_SIZE(delta_decoders); i++) {
> >> ^  
> 
> Hi Mauro,
> 
> It's strange that you face this warning, code is like that:
> /* registry of available decoders */
> static const struct delta_dec *delta_decoders[] = {
> #ifdef CONFIG_VIDEO_STI_DELTA_MJPEG
>   ,
> #endif
> };
> 
> and MJPEG config is enabled by default:
> config VIDEO_STI_DELTA_MJPEG
>   bool "STMicroelectronics DELTA MJPEG support"
>   default y
> 
> so you should not encounter this warning.
> 
> On the other hand, you face issue on line 322 of delta-v4l2.c but in my 
> codebase, and also in Hans' git tree 
> (git://linuxtv.org/hverkuil/media_tree.git delta), this code is at line 323.

Well, here I compile everything patch per patch.

> 
> Anyway, in order to prevent such warning even if no decoder are selected 
> in config, I have reworked the code in v5 adding a "NULL"
> element at the end of decoder array out of any config switch:
> static const struct delta_dec *delta_decoders[] = {
> #ifdef CONFIG_VIDEO_STI_DELTA_MJPEG
>   ,
> #endif
>   NULL,
> };

That just hides the warning. The real problem here is that, if
someone compiles just the main driver with no decoder drivers, it
will get an useless driver.

It only makes sense to build VIDEO_STI_DELTA if at least one of
the "daughter" drivers is built.

Assuming that, on some future, you add a MPEG decoder, I guess the
best way to address it would be to have something like this at the
Kconfig:

config VIDEO_STI_DELTA
tristate "STMicroelectronics STiH4xx DELTA multi-format video decoder 
V4L2 driver options"
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_STI || COMPILE_TEST
depends on HAS_DMA
help
This V4L2 DELTA multi-format video decoder driver
of STMicroelectronics STiH4xx SoC series allow hardware
decoding of various compressed video bitstream format in
raw uncompressed format.

Use this option to see the decoders available for
such hardware.

Please notice that the driver will only be built if
at least one of the delta codecs below is selected.

if VIDEO_STI_DELTA

config VIDEO_STI_DELTA_MJPEG
bool "STMicroelectronics DELTA MJPEG support"
help
Enables the DELTA driver with MJPEG hardware support.

To compile this driver as a module, choose M here:
the module will be called st-delta.

config VIDEO_STI_DELTA_MPEG
bool "STMicroelectronics DELTA MPEG support"
help
Enables the DELTA driver with MPEG hardware support.

To compile this driver as a module, choose M here:
the module will be called st-delta.

config VIDEO_STI_DELTA_DRIVER

Re: [PATCH v3 00/24] i.MX Media Driver

2017-02-01 Thread Russell King - ARM Linux
On Wed, Feb 01, 2017 at 10:30:57AM +0100, Philipp Zabel wrote:
> On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
> [...]
> > right, need to fix that. Probably by poking the attached
> > source subdev (csi or prpenc/vf) for its supported formats.
> 
> You are right, in bayer/raw mode only one specific format should be
> listed, depending on the CSI output pad format.

It depends what Steve means by "source subdev".

It should be the next sub-device below the bridge - if we have this
setup of subdev's:

---> CSI ---> SMFC ---> IDMAC

then the format configured at the SMFC's output pad is what matters,
not what was configured at CSI.

It's the responsibility of SMFC and CSI to make sure that their source
pads are configured with a compatible format for their corresponding
source pad, and it's also the sink subdev's responsibility to check
that the configuration across a link is valid (possibly via
v4l2_subdev_link_validate(), or a more intensive or relaxed test if
required.)

For example:

- when CSI's source pad is configured with a RGGB output format,
  userspace media-ctl will also set that on SMFC's sink pad.
- when SMFC's sink pad is configured, SMFC should configure it's
  source pad with an identical format (RGGB).
- when SMFC's source pad is configured, it should refuse to change
  the format, because SMFC can't modify pixel the format - it's
  just a buffer.

When starting to stream (Documentation/media/kapi/v4l2-subdev.rst) the
link validation function is called, and:

- the SMFC driver's link_validate function will be called to validate
  the CSI -> SMFC link.  This allows the SMFC to be sure that there's
  a compatible configuration - and, since the link does not allow
  format conversion, it should verify that the format on the CSI's
  source pad is the same as SMFC's sink pad.

Not only does this match what the hardware's doing, it also means that,
because there's no format conversion between the CSI's hardware output
and IDMAC, we don't need to care about trying to fetch the CSI's source
pad configuration from the IDMAC end - we can fetch that information
from our neighbour's SMFC's source pad _or_ our own sink pad if we have
one.

To see why this is an important, consider what the effect would be if
SMFC did have the capability to change the pixel format.  That means the
format presented to the IDMAC block would depend on the configuration of
SMFC, and the CSI's source pad format is no longer relevant to IDMAC.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 00/24] i.MX Media Driver

2017-02-01 Thread Philipp Zabel
On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
[...]
> > # Set pad formats
> > media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY/1920x1080]"
> > media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY2X8/1920x1080]"
> > media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/1920x1080]"
> > media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/1920x1080]"
> >
> > v4l2-ctl -d /dev/video4 -V
> > # This still is configured to 640x480, which is inconsistent with
> > # the 'ipu1_csi0':2 pad format. The pad set_fmt above should
> > # have set this, too.
> 
> Because you've only configured the source pads,
> and not the sink pads. The ipu_csi source format is
> dependent on the sink format - output crop window is
> limited by max input sensor frame, and since sink pad is
> still at 640x480, output is reduced to that.

No, it is set (see below). What happens is that capture_g_fmt_vid_cap
just returns the capture devices' priv->vdev.fmt, even if it is
incompatible with the connected csi subdevice's output pad format.

priv->vdev.fmt was never changed from the default set in
imx_media_capture_device_register, because capture_s/try_fmt_vid_cap
were not called yet.

> Maybe I'm missing something, is it expected behavior that
> a source format should be automatically propagated to
> the sink?

media-ctl propagates the output pad format to all remote subdevices'
input pads for all enabled links:

https://git.linuxtv.org/v4l-utils.git/tree/utils/media-ctl/libv4l2subdev.c#n693

> > v4l2-ctl --list-formats -d /dev/video4
> > # This lists all the RGB formats, which it shouldn't. There is
> > # no CSC in this pipeline, so we should be limited to YUV formats
> > # only.
> 
> right, need to fix that. Probably by poking the attached
> source subdev (csi or prpenc/vf) for its supported formats.

You are right, in bayer/raw mode only one specific format should be
listed, depending on the CSI output pad format.

regards
Philipp

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


Re: [PATCH v3 00/24] i.MX Media Driver

2017-02-01 Thread Russell King - ARM Linux
On Tue, Jan 31, 2017 at 05:54:52PM -0800, Steve Longerbeam wrote:
> On 01/31/2017 04:23 PM, Russell King - ARM Linux wrote:
> First, thank you for the explanation, it clears up a lot.
> 
> But of_parse_subdev() is used to parse the OF graph starting
> from the CSI ports, to discover all the nodes to add to subdev
> async registration. It also forms the media link info to be used
> later to create the media graph, after all discovered subdevs
> have come online (registered themselves). This happens at
> driver load time, it doesn't have anything to do with pad
> negotiation.

Right, but I'm discussing why you need to know which is the sensor
subdev, and why you need to get parameters from the sensor subdev.

> >   I think the
> >issue here is how you're going about dealing with the subdevs.
> >Here's the subdev setup:
> >
> >+-camera+
> >| pixel array -> binner |---> csi2 --> ipu1csi0 mux --> csi0 --> smfc --> 
> >idmac
> >+---+
> >
> >How the subdevs are supposed to work is that you start from the first
> >subdev in sequence (in this case the pixel array) and negotiate with
> >the driver through the TRY formats on its source pad, as well as
> >negotiating with the sink pad of the directly neighbouring subdev.
> >
> >The neighbouring subdev propagates the configuration in a driver
> >specific manner from its source pad to the sink pad, giving a default
> >configuration at its source.
> 
> Let me try to re-phrase. You mean the subdev's set_fmt(), when
> configured  its source pad(s), should call set_fmt() at the connected
> sink subdev to automatically propagate the format to the sink's pad?

No.  For any individual subdev, if you configure it's _sink_ then it
should propagate the configuration to its _source_, potentially
modifying the configuration according to its function.  It should
never forward the configuration to the other side of any links.

The responsibility for setting up the neighbours source pad is the
userspace media application.

See Documentation/media/uapi/v4l/dev-subdev.rst and the section
named "Format Negotiation".

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html