cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Fri Feb  3 05:00:16 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: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
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/Friday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.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: ir-keytable: infinite loops, segfaults

[Sean Young]

Hi Vincent,

On Thu, Feb 02, 2017 at 10:18:52PM +1100, Vincent McIntyre wrote:
> On 11/30/16, Vincent McIntyre  wrote:
> > On Sun, Nov 27, 2016 at 07:35:10PM +, Sean Young wrote:
> >>
> >> > I wanted to mention that the IR protocol is still showing as unknown.
> >> > Is there anything that can be done to sort that out?
> >>
> >> It would be nice if that could be sorted out, although that would be
> >> a separate patch.
> >>
> >> So all we know right now is what scancode the IR receiver hardware
> >> produces but we have no idea what IR protocol is being used. In order to
> >> figure this out we need a recording of the IR the remote sends, for which
> >> a different IR receiver is needed. Neither your imon nor your
> >> dvb_usb_af9035 can do this, something like a mce usb IR receiver would
> >> be best. Do you have access to one? One with an IR emitter would be
> >> best.
> >>
> >> So with that we can have a recording of the IR the remote sends, and
> >> with the emitter we can see which IR protocols the IR receiver
> >> understands.
> >
> > Haven't been able to find anything suitable. I would order something
> > but I won't be able to follow up for several weeks.
> > I'll ask on the myth list to see if anyone is up for trying this.
> >
> 
> I bought one of these, but I am not sure how to make the recording:
> 
> # lsusb -d 1934:5168 -v
> 
> Bus 008 Device 003: ID 1934:5168 Feature Integration Technology Inc.
> (Fintek) F71610A or F71612A Consumer Infrared Receiver/Transceiver
-snip-
> Poking around I see lirc has an irrecord program. Is that what I need?

That's great. There are a couple of ways of doing this, and none of them
is straightforward. It's a bit of reading tea leaves (that's one of the
motivations for my lirc-scancodes patches, but I digress).

Method 1:
echo "+rc-5 +nec +rc-6 +jvc +sony +rc-5-sz +sanyo +sharp +xmp" > 
/sys/class/rc/rc3/protocols
echo 1 > /sys/module/rc_core/parameters/debug
journal -f -k 
# press button on remote

Now look for "scancode" somewhere in there.

Method 2:
Either use lirc's mode2 or "ir-ctl -r -d /dev/lircX" (from v4l-utils 1.12),
and post the output here.

Thanks!

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

Hello Forgive My Intrusion From Silvia.

[Silviana Olander]

Hello Friend,
 
I'm Silviana Olander and I'm Swede. I found your email contact while surfing 
the Internet. I don't think you have a clue but my reason for writing you is to 
seek your friendship! Just being adventurous and decided to use this letter as 
a resource tool to get your attention.As a matter of fact, I've been wanting to 
try this a while now to chat, to ask you things, to comment on trivial matters 
or even to talk a bit about each other. But I've been clueless on how to go 
about it. Maybe you find it strange that I'm using something as cold as this 
means to reach you. But this is the best I can do for now.
 
In short: the purpose of this letter is just to ask you if you want to be my 
friend. And if you agree, just say yes and we can take it on from there.
 
I look forward to hear hearing from you.
 
Yours Silvia.
--
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] [media] mce_kbd: add missing keys from UK layout

[Sean Young]

The UK layout of the Microsoft Remote Keyboard has two missing keys:
the hash key, and the messenger key which is sent using rc6 mce.

Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-mce_kbd-decoder.c | 2 +-
 drivers/media/rc/keymaps/rc-rc6-mce.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c 
b/drivers/media/rc/ir-mce_kbd-decoder.c
index d809862..5226d51 100644
--- a/drivers/media/rc/ir-mce_kbd-decoder.c
+++ b/drivers/media/rc/ir-mce_kbd-decoder.c
@@ -71,7 +71,7 @@ static unsigned char kbd_keycodes[256] = {
KEY_6,  KEY_7,  KEY_8,  KEY_9,  KEY_0,
KEY_ENTER,  KEY_ESC,KEY_BACKSPACE,  KEY_TAB,
KEY_SPACE,
KEY_MINUS,  KEY_EQUAL,  KEY_LEFTBRACE,  KEY_RIGHTBRACE, 
KEY_BACKSLASH,
-   KEY_RESERVED,   KEY_SEMICOLON,  KEY_APOSTROPHE, KEY_GRAVE,  
KEY_COMMA,
+   KEY_BACKSLASH,  KEY_SEMICOLON,  KEY_APOSTROPHE, KEY_GRAVE,  
KEY_COMMA,
KEY_DOT,KEY_SLASH,  KEY_CAPSLOCK,   KEY_F1, KEY_F2,
KEY_F3, KEY_F4, KEY_F5, KEY_F6, KEY_F7,
KEY_F8, KEY_F9, KEY_F10,KEY_F11,KEY_F12,
diff --git a/drivers/media/rc/keymaps/rc-rc6-mce.c 
b/drivers/media/rc/keymaps/rc-rc6-mce.c
index ef4006f..5be5675 100644
--- a/drivers/media/rc/keymaps/rc-rc6-mce.c
+++ b/drivers/media/rc/keymaps/rc-rc6-mce.c
@@ -86,6 +86,7 @@ static struct rc_map_table rc6_mce[] = {
{ 0x800f045e, KEY_BLUE },
 
{ 0x800f0465, KEY_POWER2 }, /* TV Power */
+   { 0x800f0469, KEY_MESSENGER },
{ 0x800f046e, KEY_PLAYPAUSE },
{ 0x800f046f, KEY_PLAYER }, /* Start media application (NEW) */
 
-- 
2.9.3

--
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] [media] lirc: cannot read from tx-only device

[Sean Young]

Bail out early, otherwise we follow a null pointer.

Signed-off-by: Sean Young 
---
 drivers/media/rc/lirc_dev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 0030ce0..a54ca53 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -647,6 +647,9 @@ ssize_t lirc_dev_fop_read(struct file *file,
return -ENODEV;
}
 
+   if (!LIRC_CAN_REC(ir->d.features))
+   return -EINVAL;
+
dev_dbg(ir->d.dev, LOGHEAD "read called\n", ir->d.name, ir->d.minor);
 
buf = kzalloc(ir->chunk_size, GFP_KERNEL);
-- 
2.9.3

--
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 16/24] media: Add i.MX media core driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote:
> +/* register an internal subdev as a platform device */
> +static struct imx_media_subdev *
> +add_internal_subdev(struct imx_media_dev *imxmd,
> + const struct internal_subdev *isd,
> + int ipu_id)
> +{
> + struct imx_media_internal_sd_platformdata pdata;
> + struct platform_device_info pdevinfo = {0};
> + struct imx_media_subdev *imxsd;
> + struct platform_device *pdev;
> +
> + switch (isd->id->grp_id) {
> + case IMX_MEDIA_GRP_ID_CAMIF0...IMX_MEDIA_GRP_ID_CAMIF1:
> + pdata.grp_id = isd->id->grp_id +
> + ((2 * ipu_id) << IMX_MEDIA_GRP_ID_CAMIF_BIT);
> + break;
> + default:
> + pdata.grp_id = isd->id->grp_id;
> + break;
> + }
> +
> + /* the id of IPU this subdev will control */
> + pdata.ipu_id = ipu_id;
> +
> + /* create subdev name */
> + imx_media_grp_id_to_sd_name(pdata.sd_name, sizeof(pdata.sd_name),
> + pdata.grp_id, ipu_id);
> +
> + pdevinfo.name = isd->id->name;
> + pdevinfo.id = ipu_id * num_isd + isd->id->index;
> + pdevinfo.parent = imxmd->dev;
> + pdevinfo.data = 
> + pdevinfo.size_data = sizeof(pdata);
> + pdevinfo.dma_mask = DMA_BIT_MASK(32);
> +
> + pdev = platform_device_register_full();
> + if (IS_ERR(pdev))
> + return ERR_CAST(pdev);
> +
> + imxsd = imx_media_add_async_subdev(imxmd, NULL, dev_name(>dev));
> + if (IS_ERR(imxsd))
> + return imxsd;
> +
> + imxsd->num_sink_pads = isd->num_sink_pads;
> + imxsd->num_src_pads = isd->num_src_pads;
> +
> + return imxsd;
> +}

You seem to create platform devices here, but I see nowhere that you
ever remove them - so if you get to the lucky point of being able to
rmmod imx-media and then try to re-insert it, you end up with a load
of kernel warnings, one for each device created this way, and
platform_device_register_full() fails:

WARNING: CPU: 0 PID: 2143 at /home/rmk/git/linux-rmk/fs/sysfs/dir.c:31 
sysfs_warn_dup+0x64/0x80
sysfs: cannot create duplicate filename 
'/devices/soc0/soc/soc:media@0/imx-ipuv3-smfc.2'
Modules linked in: imx_media(C+) rfcomm bnep bluetooth nfsd imx_camif(C) 
imx_ic(C) imx_smfc(C) caam_jr snd_soc_imx_sgtl5000 snd_soc_fsl_asoc_card 
uvcvideo snd_soc_imx_spdif imx_mipi_csi2(C) imx_media_common(C) 
snd_soc_imx_audmux imx219 snd_soc_sgtl5000 video_multiplexer imx_sdma caam 
imx2_wdt rc_cec coda v4l2_mem2mem videobuf2_v4l2 snd_soc_fsl_ssi 
snd_soc_fsl_spdif videobuf2_dma_contig imx_pcm_dma videobuf2_core 
videobuf2_vmalloc videobuf2_memops imx_thermal dw_hdmi_cec dw_hdmi_ahb_audio 
etnaviv fuse rc_pinnacle_pctv_hd [last unloaded: imx_media]
CPU: 0 PID: 2143 Comm: modprobe Tainted: G C  4.10.0-rc6+ #2103
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
 r6:6013 r5: r4: r3:
[] (show_stack) from [] (dump_stack+0xa4/0xdc)
[] (dump_stack) from [] (__warn+0xdc/0x108)
 r6:c08ad998 r5: r4:cf4e9a78 r3:ec984980
[] (__warn) from [] (warn_slowpath_fmt+0x40/0x48)
 r10:e5800010 r8:ef1fa818 r7:ef1fa810 r6:ef202300 r5:e9809000 r4:ee868000
[] (warn_slowpath_fmt) from [] (sysfs_warn_dup+0x64/0x80)
 r3:ee868000 r2:c08ad9c0
[] (sysfs_warn_dup) from [] (sysfs_create_dir_ns+0x90/0x98)
 r6:ffef r5:ef202300 r4:eb5e3418
[] (sysfs_create_dir_ns) from [] 
(kobject_add_internal+0xa4/0x2d8)
 r6:ef1fa818 r5: r4:eb5e3418
[] (kobject_add_internal) from [] (kobject_add+0x50/0x98)
 r8:bf1f9018 r7:ef1fa810 r6:ef1fa818 r5: r4:eb5e3418
[] (kobject_add) from [] (device_add+0xc8/0x538)
 r3:ef1fa834 r2:
 r6:eb5e3418 r5: r4:eb5e3410
[] (device_add) from [] (platform_device_add+0xb0/0x214)
 r10:e5800010 r9: r8:bf1f9018 r7:e5806fd4 r6:eb5e3410 r5:eb5e3400
 r4:
[] (platform_device_add) from [] 
(platform_device_register_full+0xe8/0x110)
 r7:e5806fd4 r6:0002 r5:eb5e3400 r4:cf4e9c18
[] (platform_device_register_full) from [] 
(add_ipu_internal_subdevs+0x128/0x2c8 [imx_media])
 r5:bf1f9000 r4:0918
[] (add_ipu_internal_subdevs [imx_media]) from [] 
(imx_media_add_internal_subdevs+0x2c/0x70 [imx_media])
 r10:0048 r9:f31ceef8 r8:ef7f1d94 r7:e5800230 r6:e5800200 r5:e5800010
 r4:cf4e9c90
[] (imx_media_add_internal_subdevs [imx_media]) from [] 
(imx_media_probe+0xc4/0x1c0 [imx_media])
 r5: r4:e5800010
[] (imx_media_probe [imx_media]) from [] 
(platform_drv_probe+0x58/0xb8)
 r8: r7:bf1fbd48 r6:fdfb r5:ef1fa810 r4:fffe
[] (platform_drv_probe) from [] 
(driver_probe_device+0x204/0x2c8)
 r7:bf1fbd48 r6: r5:c1419de8 r4:ef1fa810
[] (driver_probe_device) from [] (__driver_attach+0xbc/0xc0)
 r10:0124 r8:0001 r7: r6:ef1fa844 r5:bf1fbd48 r4:ef1fa810
[] (__driver_attach) from [] (bus_for_each_dev+0x5c/0x90)
 r6:c0418d54 r5:bf1fbd48 r4: 

Re: [PATCH v3 16/24] media: Add i.MX media core driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote:
> +struct imx_media_dev {
> + struct media_device md;
> + struct v4l2_device  v4l2_dev;

This is similarly buggy.

struct v4l2_device {
struct device *dev;
#if defined(CONFIG_MEDIA_CONTROLLER)
struct media_device *mdev;
#endif
struct list_head subdevs;
spinlock_t lock;
char name[V4L2_DEVICE_NAME_SIZE];
void (*notify)(struct v4l2_subdev *sd,
unsigned int notification, void *arg);
struct v4l2_ctrl_handler *ctrl_handler;
struct v4l2_prio_state prio;
struct kref ref;
void (*release)(struct v4l2_device *v4l2_dev);
};

Notice the kref and release function.  This is the only way the
memory backing "struct v4l2_device" may be released.  If you wish to
embed this structure into another structure, then the lifetime of
that other structure is determined by this one.  IOW, when this
release function is called, only then may you kfree() the memory
backing struct imx_media_dev.

> + struct device *dev;

And... do you need all these struct device pointers?

imxmd->dev = dev;
imxmd->md.dev = dev;

As media_device already contains a pointer, can't you re-use that?

-- 
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 20/24] media: imx: Add Camera Interface subdev driver

[Russell King - ARM Linux]

On Fri, Jan 06, 2017 at 06:11:38PM -0800, Steve Longerbeam wrote:
> +struct camif_priv {
> + struct device *dev;
> + struct video_devicevfd;

You can't do this.

> +static struct video_device camif_videodev = {
> + .fops   = _fops,
> + .ioctl_ops  = _ioctl_ops,
> + .minor  = -1,
> + .release= video_device_release,
> + .vfl_dir= VFL_DIR_RX,
> + .tvnorms= V4L2_STD_NTSC | V4L2_STD_PAL | V4L2_STD_SECAM,
> +};

> +static int camif_probe(struct platform_device *pdev)
> +{
> + struct imx_media_internal_sd_platformdata *pdata;
> + struct camif_priv *priv;
> + struct video_device *vfd;
> + int ret;
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;

You kmalloc this structure, so this structure has the lifetime of
the driver being bound to the platform device.

> + vfd = >vfd;
> + *vfd = camif_videodev;

However, "*vfd" contains a struct device, and you _correctly_ set the
release function for "*vfd" to video_device_release via camif_videodev.

However, if you try to rmmod imx-media, then you end up with a kernel
warning that you're freeing memory containing a held lock, and later
chaos ensues because kmalloc has been corrupted.

The root cause of this is embedding the device structure within the
video_device into the driver's private data.  *Any* structure what so
ever that contains a kref is reference counted, and that includes
struct device, and therefore also includes struct video_device.  What
that means is that its lifetime is _not_ under _your_ control, and
you may not free it except through its release function (which is
video_device_release().)  However, that also tries to kfree (with an
offset of 4) your private data, which results in the warning and the
corrupted kmalloc free lists.

The solution is simple, make "vfd" a pointer in your private data
structure and kmalloc() it separately, letting video_device_release()
kfree() that data when it needs to.

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

[Russell King - ARM Linux]

On Thu, Feb 02, 2017 at 11:12:41AM -0800, Steve Longerbeam wrote:
> Here is the current .queue_setup() op in imx-media-capture.c:
> 
> static int capture_queue_setup(struct vb2_queue *vq,
>unsigned int *nbuffers,
>unsigned int *nplanes,
>unsigned int sizes[],
>struct device *alloc_devs[])
> {
> struct capture_priv *priv = vb2_get_drv_priv(vq);
> struct v4l2_pix_format *pix = >vdev.fmt.fmt.pix;
> unsigned int count = *nbuffers;
> 
> if (vq->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> return -EINVAL;
> 
> if (*nplanes) {
> if (*nplanes != 1 || sizes[0] < pix->sizeimage)
> return -EINVAL;
> count += vq->num_buffers;
> }
> 
> while (pix->sizeimage * count > VID_MEM_LIMIT)
> count--;

That's a weird way of writing:

unsigned int max_num = VID_MEM_LIMIT / pix->sizeimage;
count = max(count, max_num);

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

[Steve Longerbeam]

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

On Thu, Feb 02, 2017 at 10:26:55AM -0800, Steve Longerbeam wrote:

On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote:

and for whatever reason we end up falling out through free_ring.  This
is VERY bad news, because it means that the ring which SMFC took a copy
of is now freed beneath its feet.

Yes, that is bad. That was a bug, if imx_media_dma_buf_queue_from_vb()
returned error, the ring should not have been freed, it should have only
returned the error. And further bad stuff happens from that point on.

But all of this is gone in version 4.

I think there's an error in how you think the queue_setup() works.

camif_queue_setup() always returns the number of buffers between
IMX_MEDIA_MIN_RING_BUFS and IMX_MEDIA_MAX_RING_BUFS.  However, it seems
that, looking through the videobuf2-core.c code, that the value is
passed to __vb2_queue_alloc() to allocate the specified number of
_additional_ buffers over and on-top of the existing q->num_buffers:

static int __vb2_queue_alloc(struct vb2_queue *q, enum vb2_memory memory,
  unsigned int num_buffers, unsigned int num_planes,
  const unsigned plane_sizes[VB2_MAX_PLANES])
{
 for (buffer = 0; buffer < num_buffers; ++buffer) {
...
 vb->index = q->num_buffers + buffer;

and

int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
 unsigned int *count)
{
 unsigned int num_buffers, allocated_buffers, num_planes = 0;
...
 num_buffers = min_t(unsigned int, *count, VB2_MAX_FRAME);
 num_buffers = max_t(unsigned int, num_buffers, q->min_buffers_needed);
...
 /*
  * Ask the driver how many buffers and planes per buffer it requires.
  * Driver also sets the size and allocator context for each plane.
  */
 ret = call_qop(q, queue_setup, q, _buffers, _planes,
plane_sizes, q->alloc_devs);
 if (ret)
 return ret;

 /* Finally, allocate buffers and video memory */
 allocated_buffers =
 __vb2_queue_alloc(q, memory, num_buffers, num_planes, 
plane_sizes);

or:

int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory,
 unsigned int *count, unsigned requested_planes,
 const unsigned requested_sizes[])
{
 unsigned int num_planes = 0, num_buffers, allocated_buffers;
...
 num_buffers = min(*count, VB2_MAX_FRAME - q->num_buffers);
 if (requested_planes && requested_sizes) {
 num_planes = requested_planes;
...
 /*
  * Ask the driver, whether the requested number of buffers, planes per
  * buffer and their sizes are acceptable
  */
 ret = call_qop(q, queue_setup, q, _buffers,
_planes, plane_sizes, q->alloc_devs);
 if (ret)
 return ret;

 /* Finally, allocate buffers and video memory */
 allocated_buffers = __vb2_queue_alloc(q, memory, num_buffers,
 num_planes, plane_sizes);


It seems to me that if you don't take account of the existing queue
size, your camif_queue_setup() has the side effect that each time
either of these are called.  Hence, the vb2 queue increases by the
same amount each time, which is probably what you don't want.

The documentation on queue_setup() leaves much to be desired:

  * @queue_setup:called from VIDIOC_REQBUFS() and VIDIOC_CREATE_BUFS()
  *  handlers before memory allocation. It can be called
  *  twice: if the original number of requested buffers
  *  could not be allocated, then it will be called a
  *  second time with the actually allocated number of
  *  buffers to verify if that is OK.
  *  The driver should return the required number of buffers
  *  in \*num_buffers, the required number of planes per
  *  buffer in \*num_planes, the size of each plane should 
be
  *  set in the sizes\[\] array and optional per-plane
  *  allocator specific device in the alloc_devs\[\] array.
  *  When called from VIDIOC_REQBUFS,() \*num_planes == 0,
  *  the driver has to use the currently configured format 
to
  *  determine the plane sizes and \*num_buffers is the 
total
  *  number of buffers that are being allocated. When called
  *  from VIDIOC_CREATE_BUFS,() \*num_planes != 0 and it
  *  describes the requested number of planes and sizes\[\]
  *  contains the requested plane sizes. If either
  *  \*num_planes or the requested sizes are invalid 
callback
  *  

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

[Russell King - ARM Linux]

On Thu, Feb 02, 2017 at 10:26:55AM -0800, Steve Longerbeam wrote:
> On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote:
> >and for whatever reason we end up falling out through free_ring.  This
> >is VERY bad news, because it means that the ring which SMFC took a copy
> >of is now freed beneath its feet.
> 
> Yes, that is bad. That was a bug, if imx_media_dma_buf_queue_from_vb()
> returned error, the ring should not have been freed, it should have only
> returned the error. And further bad stuff happens from that point on.
> 
> But all of this is gone in version 4.

I think there's an error in how you think the queue_setup() works.

camif_queue_setup() always returns the number of buffers between
IMX_MEDIA_MIN_RING_BUFS and IMX_MEDIA_MAX_RING_BUFS.  However, it seems
that, looking through the videobuf2-core.c code, that the value is
passed to __vb2_queue_alloc() to allocate the specified number of
_additional_ buffers over and on-top of the existing q->num_buffers:

static int __vb2_queue_alloc(struct vb2_queue *q, enum vb2_memory memory,
 unsigned int num_buffers, unsigned int num_planes,
 const unsigned plane_sizes[VB2_MAX_PLANES])
{
for (buffer = 0; buffer < num_buffers; ++buffer) {
...
vb->index = q->num_buffers + buffer;

and

int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
unsigned int *count)
{
unsigned int num_buffers, allocated_buffers, num_planes = 0;
...
num_buffers = min_t(unsigned int, *count, VB2_MAX_FRAME);
num_buffers = max_t(unsigned int, num_buffers, q->min_buffers_needed);
...
/*
 * Ask the driver how many buffers and planes per buffer it requires.
 * Driver also sets the size and allocator context for each plane.
 */
ret = call_qop(q, queue_setup, q, _buffers, _planes,
   plane_sizes, q->alloc_devs);
if (ret)
return ret;

/* Finally, allocate buffers and video memory */
allocated_buffers =
__vb2_queue_alloc(q, memory, num_buffers, num_planes, 
plane_sizes);

or:

int vb2_core_create_bufs(struct vb2_queue *q, enum vb2_memory memory,
unsigned int *count, unsigned requested_planes,
const unsigned requested_sizes[])
{
unsigned int num_planes = 0, num_buffers, allocated_buffers;
...
num_buffers = min(*count, VB2_MAX_FRAME - q->num_buffers);
if (requested_planes && requested_sizes) {
num_planes = requested_planes;
...
/*
 * Ask the driver, whether the requested number of buffers, planes per
 * buffer and their sizes are acceptable
 */
ret = call_qop(q, queue_setup, q, _buffers,
   _planes, plane_sizes, q->alloc_devs);
if (ret)
return ret;

/* Finally, allocate buffers and video memory */
allocated_buffers = __vb2_queue_alloc(q, memory, num_buffers,
num_planes, plane_sizes);


It seems to me that if you don't take account of the existing queue
size, your camif_queue_setup() has the side effect that each time
either of these are called.  Hence, the vb2 queue increases by the
same amount each time, which is probably what you don't want.

The documentation on queue_setup() leaves much to be desired:

 * @queue_setup:called from VIDIOC_REQBUFS() and VIDIOC_CREATE_BUFS()
 *  handlers before memory allocation. It can be called
 *  twice: if the original number of requested buffers
 *  could not be allocated, then it will be called a
 *  second time with the actually allocated number of
 *  buffers to verify if that is OK.
 *  The driver should return the required number of buffers
 *  in \*num_buffers, the required number of planes per
 *  buffer in \*num_planes, the size of each plane should be
 *  set in the sizes\[\] array and optional per-plane
 *  allocator specific device in the alloc_devs\[\] array.
 *  When called from VIDIOC_REQBUFS,() \*num_planes == 0,
 *  the driver has to use the currently configured format to
 *  determine the plane sizes and \*num_buffers is the total
 *  number of buffers that are being allocated. When called
 *  from VIDIOC_CREATE_BUFS,() \*num_planes != 0 and it
 *  describes the requested number of planes and sizes\[\]
 *  contains the requested plane sizes. If either
 *  \*num_planes or the requested sizes are invalid callback
 *  must return %-EINVAL. In this case \*num_buffers are
 *  being allocated 

Re: metadata node

[Guennadi Liakhovetski]

Hi Stanimir,

On Mon, 30 Jan 2017, Stanimir Varbanov wrote:

> Hi Guennadi,
> 
> On 01/11/2017 11:42 AM, Guennadi Liakhovetski wrote:

[snip]

> > In any case, _if_ we do keep the current approach of separate /dev/video* 
> > nodes, we need a way to associate video and metadata nodes. Earlier I 
> > proposed using media controller links for that. In your implementation of 
> 
> I don't think that media controller links is a good idea. This metadata
> api could be used by mem2mem drivers which don't have media controller
> links so we will need a generic v4l2 way to bound image buffer and its
> metadata buffer.

Is there anything, that's preventing mem2mem drivers from using the MC 
API? Arguably, if you need metadata, you cross the line of becoming a 
complex enough device to deserve MC support?

Thanks
Guennadi

> -- 
> regards,
> Stan
> 
--
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

[Steve Longerbeam]

On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote:

On Thu, Feb 02, 2017 at 05:22:46PM +, Russell King - ARM Linux wrote:

I thought, maybe, it's the IPU overwriting past the end of the buffer,
but I've added checks and that doesn't seem to have fired.  I also
wondered if it was some kind of use-after-free of the ring, so I made
imx_media_free_dma_buf_ring() memset the ring to 0x5a5a5a5a before
kfree()ing it... doesn't look like it's that either.  I'm going to
continue poking to see if I can figure out what's going on.

I take that back... here's a use-after-free of that buffer, on the
very first run:

Alignment trap: not handling instruction e1921f9f at []
Unhandled fault: alignment exception (0x001) at 0x5a5a5b5e
pgd = c0004000
[5a5a5b5e] *pgd=
Internal error: : 1 [#1] SMP ARM
Modules linked in: imx_csi(C) rfcomm bnep bluetooth nfsd imx_camif(C) imx_ic(C) 
imx_smfc(C) caam_jr snd_soc_imx_spdif snd_soc_imx_sgtl5000 
snd_soc_fsl_asoc_card imx_media(C) uvcvideo imx_mipi_csi2(C) 
imx_media_common(C) imx219 snd_soc_sgtl5000 snd_soc_imx_audmux caam 
video_multiplexer imx_sdma imx2_wdt coda v4l2_mem2mem videobuf2_v4l2 
videobuf2_dma_contig videobuf2_core rc_cec snd_soc_fsl_ssi snd_soc_fsl_spdif 
videobuf2_vmalloc videobuf2_memops imx_pcm_dma imx_thermal dw_hdmi_ahb_audio 
dw_hdmi_cec etnaviv fuse rc_pinnacle_pctv_hd
CPU: 0 PID: 99 Comm: kworker/0:3 Tainted: G C  4.10.0-rc6+ #2103
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Workqueue: lru-add-drain wq_barrier_func
task: ee4e24c0 task.stack: ee6da000
PC is at __lock_acquire+0xd4/0x17b0
LR is at lock_acquire+0xd8/0x250
pc : []lr : []psr: 20070193
sp : ee6dbb60  ip : 0001  fp : ee6dbbe4
r10: e9efad60  r9 : c0a70384  r8 : 
r7 : c0a38680  r6 :   r5 : ee4e24c0  r4 : c1400408
r3 :   r2 : 5a5a5b5e  r1 :   r0 : 5a5a5a5a
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 3d7ec04a  DAC: 0051
Process kworker/0:3 (pid: 99, stack limit = 0xee6da210)
Stack: (0xee6dbb60 to 0xee6dc000)
bb60: c0a38680 0002 c0b9d8c4 ee4e29a8 ee6dbc04 ee6dbb80 c0089708 c0088d44
bb80: ee6dbb9c 050f c00867fc c0086728 ee6dbbf4 ee6dbba0 87eba239 c035aa2f
bba0: 0001 ee4e29a8 c00c4f84 0001 0026 0560e36b  
bbc0: 60070193 e9efad60   c0a70384  ee6dbc3c ee6dbbe8
bbe0: c008b108 c0089400 0001 0080  bf0d2a8c  
bc00: c008b108 c0089400 0001 c09e04ec  e9efad50 60070193 bf0d2a8c
bc20: 0139  c09e04ec ee6dbcec ee6dbc6c ee6dbc40 c07016f4 c008b03c
bc40: 0001  bf0d2a8c ee6dbcec ee6dbc84 e9efac00 e9efad50 ee9785c4
bc60: ee6dbc84 ee6dbc70 bf0d2a8c c07016b4 ee978410 e9efb400 ee6dbca4 ee6dbc88
bc80: bf1224b8 bf0d2a7c bf122458 ee88d4c0 e9efb400 e9efb410 ee6dbce4 ee6dbca8
bca0: c009f5dc bf122464 0001 c09e04ec  e9efb400 c009f9f8 e9efb400
bcc0: e9efb400 e9efb410  0009 f4001100 ee6dbe38 ee6dbd04 ee6dbce8
bce0: c009f984 c009f544 c0701d10  e9efb400 e9efb460 ee6dbd24 ee6dbd08
bd00: c009fa00 c009f96c c09d0418 e9efb400 e9efb460 e9efb410 ee6dbd44 ee6dbd28
bd20: c00a3174 c009f9cc c00a30c4  ee6dbd90 ee4a3010 ee6dbd54 ee6dbd48
bd40: c009ecf0 c00a30d0 ee6dbd84 ee6dbd58 c0409328 c009ecdc c09d0448 0001
bd60: 0026 ef1efc10 c09e756c ee4a3010 0026 ef008400 ee6dbdcc ee6dbd88
bd80: c0409458 c040928c 0001  0001 0002 0003 000a
bda0: 000b 000c 000d 000e ee6dbdcc c09d52d0  
bdc0: ee6dbddc ee6dbdd0 c009ecf0 c0409408 ee6dbe04 ee6dbde0 c009ee24 c009ecdc
bde0: ee6dbe38 f4000100 f400010c c09e0af0 03eb c0a38a78 ee6dbe34 ee6dbe08
be00: c00094c8 c009edd4 ee4e24c0 c0701d50 20070013  ee6dbe6c ef7be600
be20: ee6da000 c09f5dc6 ee6dbe9c ee6dbe38 c00149f0 c0009488 0001 ee4e2988
be40:  60070093 20070013 ddb9799c 20070013 ee6dbef0 ef7be600 c09e04ec
be60: c09f5dc6 ee6dbe9c 0288 ee6dbe88 c008b60c c0701d50 20070013 
be80: 0051  ddb9799c ddb97998 ee6dbebc ee6dbea0 c0083824 c0701d20
bea0: c004e9c4 ee6e6d80 ddb97978 ef7ba940 ee6dbecc ee6dbec0 c004e9d8 c00837e8
bec0: ee6dbf2c ee6dbed0 c0050958 c004e9d0 0001  c0050898 
bee0: c0701d8c ee4e24c0 000f  c0a73e7c c0bc8834  c08947f8
bf00: 0008 ee6e6d80 ee6e6d98 ee6e6d98 0008 ef7ba940 ef7ba940 c09dd900
bf20: ee6dbf44 ee6dbf30 c0050e78 c0050774 ee6e6d80 ef7ba974 ee6dbf7c ee6dbf48
bf40: c0051094 c0050e54  ee6e8ac0 ee509eb8 ee509e80  ee6e8ac0
bf60: ee509eb8 ee6e6d80 ef0c9e58 c0050e88 ee6dbfac ee6dbf80 c0057b90 c0050e94
bf80: ee6da000 ee6e8ac0 c0057a88     
bfa0:  ee6dbfb0 c000fdf0 c0057a94    
bfc0:        
bfe0:     0013  3fffd861 3fffdc61
Backtrace:
[] 

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

[Russell King - ARM Linux]

On Thu, Feb 02, 2017 at 05:22:46PM +, Russell King - ARM Linux wrote:
> I thought, maybe, it's the IPU overwriting past the end of the buffer,
> but I've added checks and that doesn't seem to have fired.  I also
> wondered if it was some kind of use-after-free of the ring, so I made
> imx_media_free_dma_buf_ring() memset the ring to 0x5a5a5a5a before
> kfree()ing it... doesn't look like it's that either.  I'm going to
> continue poking to see if I can figure out what's going on.

I take that back... here's a use-after-free of that buffer, on the
very first run:

Alignment trap: not handling instruction e1921f9f at []
Unhandled fault: alignment exception (0x001) at 0x5a5a5b5e
pgd = c0004000
[5a5a5b5e] *pgd=
Internal error: : 1 [#1] SMP ARM
Modules linked in: imx_csi(C) rfcomm bnep bluetooth nfsd imx_camif(C) imx_ic(C) 
imx_smfc(C) caam_jr snd_soc_imx_spdif snd_soc_imx_sgtl5000 
snd_soc_fsl_asoc_card imx_media(C) uvcvideo imx_mipi_csi2(C) 
imx_media_common(C) imx219 snd_soc_sgtl5000 snd_soc_imx_audmux caam 
video_multiplexer imx_sdma imx2_wdt coda v4l2_mem2mem videobuf2_v4l2 
videobuf2_dma_contig videobuf2_core rc_cec snd_soc_fsl_ssi snd_soc_fsl_spdif 
videobuf2_vmalloc videobuf2_memops imx_pcm_dma imx_thermal dw_hdmi_ahb_audio 
dw_hdmi_cec etnaviv fuse rc_pinnacle_pctv_hd
CPU: 0 PID: 99 Comm: kworker/0:3 Tainted: G C  4.10.0-rc6+ #2103
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Workqueue: lru-add-drain wq_barrier_func
task: ee4e24c0 task.stack: ee6da000
PC is at __lock_acquire+0xd4/0x17b0
LR is at lock_acquire+0xd8/0x250
pc : []lr : []psr: 20070193
sp : ee6dbb60  ip : 0001  fp : ee6dbbe4
r10: e9efad60  r9 : c0a70384  r8 : 
r7 : c0a38680  r6 :   r5 : ee4e24c0  r4 : c1400408
r3 :   r2 : 5a5a5b5e  r1 :   r0 : 5a5a5a5a
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 3d7ec04a  DAC: 0051
Process kworker/0:3 (pid: 99, stack limit = 0xee6da210)
Stack: (0xee6dbb60 to 0xee6dc000)
bb60: c0a38680 0002 c0b9d8c4 ee4e29a8 ee6dbc04 ee6dbb80 c0089708 c0088d44
bb80: ee6dbb9c 050f c00867fc c0086728 ee6dbbf4 ee6dbba0 87eba239 c035aa2f
bba0: 0001 ee4e29a8 c00c4f84 0001 0026 0560e36b  
bbc0: 60070193 e9efad60   c0a70384  ee6dbc3c ee6dbbe8
bbe0: c008b108 c0089400 0001 0080  bf0d2a8c  
bc00: c008b108 c0089400 0001 c09e04ec  e9efad50 60070193 bf0d2a8c
bc20: 0139  c09e04ec ee6dbcec ee6dbc6c ee6dbc40 c07016f4 c008b03c
bc40: 0001  bf0d2a8c ee6dbcec ee6dbc84 e9efac00 e9efad50 ee9785c4
bc60: ee6dbc84 ee6dbc70 bf0d2a8c c07016b4 ee978410 e9efb400 ee6dbca4 ee6dbc88
bc80: bf1224b8 bf0d2a7c bf122458 ee88d4c0 e9efb400 e9efb410 ee6dbce4 ee6dbca8
bca0: c009f5dc bf122464 0001 c09e04ec  e9efb400 c009f9f8 e9efb400
bcc0: e9efb400 e9efb410  0009 f4001100 ee6dbe38 ee6dbd04 ee6dbce8
bce0: c009f984 c009f544 c0701d10  e9efb400 e9efb460 ee6dbd24 ee6dbd08
bd00: c009fa00 c009f96c c09d0418 e9efb400 e9efb460 e9efb410 ee6dbd44 ee6dbd28
bd20: c00a3174 c009f9cc c00a30c4  ee6dbd90 ee4a3010 ee6dbd54 ee6dbd48
bd40: c009ecf0 c00a30d0 ee6dbd84 ee6dbd58 c0409328 c009ecdc c09d0448 0001
bd60: 0026 ef1efc10 c09e756c ee4a3010 0026 ef008400 ee6dbdcc ee6dbd88
bd80: c0409458 c040928c 0001  0001 0002 0003 000a
bda0: 000b 000c 000d 000e ee6dbdcc c09d52d0  
bdc0: ee6dbddc ee6dbdd0 c009ecf0 c0409408 ee6dbe04 ee6dbde0 c009ee24 c009ecdc
bde0: ee6dbe38 f4000100 f400010c c09e0af0 03eb c0a38a78 ee6dbe34 ee6dbe08
be00: c00094c8 c009edd4 ee4e24c0 c0701d50 20070013  ee6dbe6c ef7be600
be20: ee6da000 c09f5dc6 ee6dbe9c ee6dbe38 c00149f0 c0009488 0001 ee4e2988
be40:  60070093 20070013 ddb9799c 20070013 ee6dbef0 ef7be600 c09e04ec
be60: c09f5dc6 ee6dbe9c 0288 ee6dbe88 c008b60c c0701d50 20070013 
be80: 0051  ddb9799c ddb97998 ee6dbebc ee6dbea0 c0083824 c0701d20
bea0: c004e9c4 ee6e6d80 ddb97978 ef7ba940 ee6dbecc ee6dbec0 c004e9d8 c00837e8
bec0: ee6dbf2c ee6dbed0 c0050958 c004e9d0 0001  c0050898 
bee0: c0701d8c ee4e24c0 000f  c0a73e7c c0bc8834  c08947f8
bf00: 0008 ee6e6d80 ee6e6d98 ee6e6d98 0008 ef7ba940 ef7ba940 c09dd900
bf20: ee6dbf44 ee6dbf30 c0050e78 c0050774 ee6e6d80 ef7ba974 ee6dbf7c ee6dbf48
bf40: c0051094 c0050e54  ee6e8ac0 ee509eb8 ee509e80  ee6e8ac0
bf60: ee509eb8 ee6e6d80 ef0c9e58 c0050e88 ee6dbfac ee6dbf80 c0057b90 c0050e94
bf80: ee6da000 ee6e8ac0 c0057a88     
bfa0:  ee6dbfb0 c000fdf0 c0057a94    
bfc0:        
bfe0:     0013  3fffd861 3fffdc61
Backtrace:
[] (__lock_acquire) from [] (lock_acquire+0xd8/0x250)
 

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

[Steve Longerbeam]

Hi Russell,

I don't recommend spending too much time debugging this
OOPS. The dma buffer ring has been removed completely
in version 4 (which I'm trying to get ready to post hopefully
by end of this week).

Steve


On 02/02/2017 09:22 AM, Russell King - ARM Linux wrote:

I seem to be getting some sort of memory corruption with this driver.

I've had two instances now of uninitialised spinlocks in
imx_media_dma_buf_get_active() which show that the spinlock being
taken in this function is all-zeros.

That very quickly leads to an oops, where I've seen buf->ring is
NULL in imx_media_dma_buf_set_active().

Not quite sure what's going on, but the trigger (at least for me) is
to change my gstreamer pipeline from:

DISPLAY=:0 gst-launch-1.0 -v v4l2src device=/dev/video3 ! bayer2rgbneon ! 
xvimagesink

to

DISPLAY=:0 gst-launch-1.0 -v v4l2src device=/dev/video3 ! queue ! bayer2rgbneon 
! xvimagesink

and it seems to take as little as two or three attempts to provoke the
kernel to totally die.

I've just tried a third time.  I can run the first gstreamer command
five times.  The I ran the second command and immediately got this:

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1008 Comm: Xorg Tainted: G C  4.10.0-rc6+ #2103
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
  r6:600f0193 r5: r4: r3:
[] (show_stack) from [] (dump_stack+0xa4/0xdc)
[] (dump_stack) from [] (register_lock_class+0x1d4/0x554)
  r6:c1400408 r5: r4: r3:ee47a4c0
[] (register_lock_class) from [] 
(__lock_acquire+0x80/0x17b0)
  r10:d995f760 r9:c0a70384 r8: r7:c0a38680 r6: r5:ee47a4c0
  r4:c1400408
[] (__lock_acquire) from [] (lock_acquire+0xd8/0x250)
  r10: r9:c0a70384 r8: r7: r6:d995f760 r5:600f0193
  r4:
[] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x4c/0x60)
  r10:ed501e64 r9:c09e04ec r8: r7:0139 r6:bf0d7a8c r5:600f0193
  r4:d995f750
[] (_raw_spin_lock_irqsave) from [] 
(imx_media_dma_buf_get_active+0x1c/0x94 [imx_media_common])
  r6:e98b2c10 r5:d995f750 r4:d995f600
[] (imx_media_dma_buf_get_active [imx_media_common]) from 
[] (imx_smfc_eof_interrupt+0x60/0x124 [imx_smfc])
  r5:ee935dc4 r4:ee935c10
[] (imx_smfc_eof_interrupt [imx_smfc]) from [] 
(__handle_irq_event_percpu+0xa4/0x428)
  r6:e98b2c10 r5:e98b2c00 r4:ebfb6d40 r3:bf12c458
[] (__handle_irq_event_percpu) from [] 
(handle_irq_event_percpu+0x24/0x60)
  r10:ed501fb0 r9:f4001100 r8:0009 r7: r6:e98b2c10 r5:e98b2c00
  r4:e98b2c00
[] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x40/0x64)
  r5:e98b2c60 r4:e98b2c00
[] (handle_irq_event) from [] (handle_level_irq+0xb0/0x138)
  r6:e98b2c10 r5:e98b2c60 r4:e98b2c00 r3:c09d0418
[] (handle_level_irq) from [] (generic_handle_irq+0x20/0x30)
  r6:ee4a3010 r5:ed501f08 r4: r3:c00a30c4
[] (generic_handle_irq) from [] (ipu_irq_handle+0xa8/0xd8)
[] (ipu_irq_handle) from [] (ipu_irq_handler+0x5c/0xb4)
  r8:ef008400 r7:0026 r6:ee4a3010 r5:c09e756c r4:ef1efc10
[] (ipu_irq_handler) from [] (generic_handle_irq+0x20/0x30)
  r6: r5: r4:c09d52d0
[] (generic_handle_irq) from [] 
(__handle_domain_irq+0x5c/0xb8)
[] (__handle_domain_irq) from [] (gic_handle_irq+0x4c/0x9c)
  r8:c0a38a78 r7:03eb r6:c09e0af0 r5:f400010c r4:f4000100 r3:ed501fb0
[] (gic_handle_irq) from [] (__irq_usr+0x58/0x80)
Exception stack(0xed501fb0 to 0xed501ff8)
1fa0: b698b4e0  0042c000 b698c708
1fc0: 0010 81231b10 81231b18 80e89670 b698b4e0 8114957c 7f79b000 81149438
1fe0: 7f79b248 bee08b98 7f708609 b6904220 600f0030 
  r10:7f79b000 r9:8114957c r8:10c5387d r7:10c5387d r6: r5:600f0030
  r4:b6904220 r3:ee47a4c0
[ cut here ]
WARNING: CPU: 0 PID: 1008 at 
/home/rmk/git/linux-rmk/drivers/staging/media/imx/imx-smfc.c:159 
imx_smfc_eof_interrupt+0x118/0x124 [imx_smfc]
Modules linked in: imx_csi(C) rfcomm bnep bluetooth nfsd imx_camif(C) imx_ic(C) 
imx_smfc(C) caam_jr snd_soc_imx_sgtl5000 uvcvideo snd_soc_fsl_asoc_card 
snd_soc_imx_spdif imx_media(C) imx_mipi_csi2(C) imx_media_common(C) 
snd_soc_imx_audmux imx219 snd_soc_sgtl5000 caam video_multiplexer imx_sdma 
imx2_wdt rc_cec snd_soc_fsl_ssi coda v4l2_mem2mem videobuf2_v4l2 
videobuf2_dma_contig videobuf2_core snd_soc_fsl_spdif imx_pcm_dma 
videobuf2_vmalloc dw_hdmi_ahb_audio dw_hdmi_cec videobuf2_memops imx_thermal 
etnaviv fuse rc_pinnacle_pctv_hd
CPU: 0 PID: 1008 Comm: Xorg Tainted: G C  4.10.0-rc6+ #2103
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
  r6:600f0193 r5: r4: r3:
[] (show_stack) from [] (dump_stack+0xa4/0xdc)
[] (dump_stack) from [] (__warn+0xdc/0x108)
  r6:bf12d004 r5: r4: r3:ee47a4c0
[] 

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

[Russell King - ARM Linux]

I seem to be getting some sort of memory corruption with this driver.

I've had two instances now of uninitialised spinlocks in
imx_media_dma_buf_get_active() which show that the spinlock being
taken in this function is all-zeros.

That very quickly leads to an oops, where I've seen buf->ring is
NULL in imx_media_dma_buf_set_active().

Not quite sure what's going on, but the trigger (at least for me) is
to change my gstreamer pipeline from:

DISPLAY=:0 gst-launch-1.0 -v v4l2src device=/dev/video3 ! bayer2rgbneon ! 
xvimagesink

to

DISPLAY=:0 gst-launch-1.0 -v v4l2src device=/dev/video3 ! queue ! bayer2rgbneon 
! xvimagesink

and it seems to take as little as two or three attempts to provoke the
kernel to totally die.

I've just tried a third time.  I can run the first gstreamer command
five times.  The I ran the second command and immediately got this:

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1008 Comm: Xorg Tainted: G C  4.10.0-rc6+ #2103
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
 r6:600f0193 r5: r4: r3:
[] (show_stack) from [] (dump_stack+0xa4/0xdc)
[] (dump_stack) from [] (register_lock_class+0x1d4/0x554)
 r6:c1400408 r5: r4: r3:ee47a4c0
[] (register_lock_class) from [] 
(__lock_acquire+0x80/0x17b0)
 r10:d995f760 r9:c0a70384 r8: r7:c0a38680 r6: r5:ee47a4c0
 r4:c1400408
[] (__lock_acquire) from [] (lock_acquire+0xd8/0x250)
 r10: r9:c0a70384 r8: r7: r6:d995f760 r5:600f0193
 r4:
[] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x4c/0x60)
 r10:ed501e64 r9:c09e04ec r8: r7:0139 r6:bf0d7a8c r5:600f0193
 r4:d995f750
[] (_raw_spin_lock_irqsave) from [] 
(imx_media_dma_buf_get_active+0x1c/0x94 [imx_media_common])
 r6:e98b2c10 r5:d995f750 r4:d995f600
[] (imx_media_dma_buf_get_active [imx_media_common]) from 
[] (imx_smfc_eof_interrupt+0x60/0x124 [imx_smfc])
 r5:ee935dc4 r4:ee935c10
[] (imx_smfc_eof_interrupt [imx_smfc]) from [] 
(__handle_irq_event_percpu+0xa4/0x428)
 r6:e98b2c10 r5:e98b2c00 r4:ebfb6d40 r3:bf12c458
[] (__handle_irq_event_percpu) from [] 
(handle_irq_event_percpu+0x24/0x60)
 r10:ed501fb0 r9:f4001100 r8:0009 r7: r6:e98b2c10 r5:e98b2c00
 r4:e98b2c00
[] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x40/0x64)
 r5:e98b2c60 r4:e98b2c00
[] (handle_irq_event) from [] (handle_level_irq+0xb0/0x138)
 r6:e98b2c10 r5:e98b2c60 r4:e98b2c00 r3:c09d0418
[] (handle_level_irq) from [] (generic_handle_irq+0x20/0x30)
 r6:ee4a3010 r5:ed501f08 r4: r3:c00a30c4
[] (generic_handle_irq) from [] (ipu_irq_handle+0xa8/0xd8)
[] (ipu_irq_handle) from [] (ipu_irq_handler+0x5c/0xb4)
 r8:ef008400 r7:0026 r6:ee4a3010 r5:c09e756c r4:ef1efc10
[] (ipu_irq_handler) from [] (generic_handle_irq+0x20/0x30)
 r6: r5: r4:c09d52d0
[] (generic_handle_irq) from [] 
(__handle_domain_irq+0x5c/0xb8)
[] (__handle_domain_irq) from [] (gic_handle_irq+0x4c/0x9c)
 r8:c0a38a78 r7:03eb r6:c09e0af0 r5:f400010c r4:f4000100 r3:ed501fb0
[] (gic_handle_irq) from [] (__irq_usr+0x58/0x80)
Exception stack(0xed501fb0 to 0xed501ff8)
1fa0: b698b4e0  0042c000 b698c708
1fc0: 0010 81231b10 81231b18 80e89670 b698b4e0 8114957c 7f79b000 81149438
1fe0: 7f79b248 bee08b98 7f708609 b6904220 600f0030 
 r10:7f79b000 r9:8114957c r8:10c5387d r7:10c5387d r6: r5:600f0030
 r4:b6904220 r3:ee47a4c0
[ cut here ]
WARNING: CPU: 0 PID: 1008 at 
/home/rmk/git/linux-rmk/drivers/staging/media/imx/imx-smfc.c:159 
imx_smfc_eof_interrupt+0x118/0x124 [imx_smfc]
Modules linked in: imx_csi(C) rfcomm bnep bluetooth nfsd imx_camif(C) imx_ic(C) 
imx_smfc(C) caam_jr snd_soc_imx_sgtl5000 uvcvideo snd_soc_fsl_asoc_card 
snd_soc_imx_spdif imx_media(C) imx_mipi_csi2(C) imx_media_common(C) 
snd_soc_imx_audmux imx219 snd_soc_sgtl5000 caam video_multiplexer imx_sdma 
imx2_wdt rc_cec snd_soc_fsl_ssi coda v4l2_mem2mem videobuf2_v4l2 
videobuf2_dma_contig videobuf2_core snd_soc_fsl_spdif imx_pcm_dma 
videobuf2_vmalloc dw_hdmi_ahb_audio dw_hdmi_cec videobuf2_memops imx_thermal 
etnaviv fuse rc_pinnacle_pctv_hd
CPU: 0 PID: 1008 Comm: Xorg Tainted: G C  4.10.0-rc6+ #2103
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
 r6:600f0193 r5: r4: r3:
[] (show_stack) from [] (dump_stack+0xa4/0xdc)
[] (dump_stack) from [] (__warn+0xdc/0x108)
 r6:bf12d004 r5: r4: r3:ee47a4c0
[] (__warn) from [] (warn_slowpath_null+0x28/0x30)
 r10:ed501e64 r8: r7:0139 r6:e98b2c10 r5:ee935dc4 r4:ee935c10
[] (warn_slowpath_null) from [] 
(imx_smfc_eof_interrupt+0x118/0x124 [imx_smfc])
[] (imx_smfc_eof_interrupt [imx_smfc]) from [] 
(__handle_irq_event_percpu+0xa4/0x428)
 

Re: [PATCH v7 2/2] media: Add a driver for the ov5645 camera sensor.

[Todor Tomov]

Hi,

Just to point it here - there is one more one-line correction needed below:

On 11/14/2016 12:24 PM, Todor Tomov wrote:
> The ov5645 sensor from Omnivision supports up to 2592x1944
> and CSI2 interface.
> 
> The driver adds support for the following modes:
> - 1280x960
> - 1920x1080
> - 2592x1944
> 
> Output format is packed 8bit UYVY.
> 
> Signed-off-by: Todor Tomov 
> ---
>  drivers/media/i2c/Kconfig  |   12 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/ov5645.c | 1352 
> 
>  3 files changed, 1365 insertions(+)
>  create mode 100644 drivers/media/i2c/ov5645.c
> 



> diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
> new file mode 100644
> index 000..2b33bc6
> --- /dev/null
> +++ b/drivers/media/i2c/ov5645.c
> @@ -0,0 +1,1352 @@



> +static int ov5645_entity_init_cfg(struct v4l2_subdev *subdev,
> +   struct v4l2_subdev_pad_config *cfg)
> +{
> + struct v4l2_subdev_format fmt = { 0 };
> + struct ov5645 *ov5645 = to_ov5645(subdev);

This variable is unused and should be removed.

> +
> + fmt.which = cfg ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE;
> + fmt.format.width = 1920;
> + fmt.format.height = 1080;
> +
> + ov5645_set_format(subdev, cfg, );
> +
> + return 0;
> +}



-- 
Best regards,
Todor Tomov
--
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

[Hugues FRUCHET]

Hi Peter,

This is now fixed in v7.

Best regards,
Hugues.

On 02/01/2017 07:37 PM, Peter Griffin wrote:
> 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

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

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

Acked-by: Peter Griffin 
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 

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

[Hugues Fruchet]

Adds support of DELTA MJPEG video decoder back-end,
implemented by calling JPEG_DECODER_HW0 firmware
using RPMSG IPC communication layer.

Acked-by: Peter Griffin 
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"
+ 

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

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

Acked-by: Peter Griffin 
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 

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

[Hugues Fruchet]

Helper functions used by decoder back-ends to allocate
physically contiguous memory required by hardware video
decoder.

Acked-by: Peter Griffin 
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 v7 05/10] [media] st-delta: STiH4xx multi-format video decoder v4l2 driver

[Hugues Fruchet]

This V4L2 driver enables DELTA multi-format video decoder
of STMicroelectronics STiH4xx SoC series.

Acked-by: Peter Griffin 
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 

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

[Hugues Fruchet]

Enables support of STMicroelectronics STiH4xx SoC series
DELTA multi-format video decoder V4L2 driver.

Acked-by: Peter Griffin 
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 v7 10/10] [media] st-delta: debug: trace stream/frame information & summary

[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).

Acked-by: Peter Griffin 
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 

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

[Hugues Fruchet]

Add entry for the STMicroelectronics DELTA driver.

Acked-by: Peter Griffin 
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 2/4] [media] em28xx: reduce stack usage in probe functions

[Arnd Bergmann]

The two i2c probe functions use a lot of stack since they put
an i2c_client structure in a local variable:

drivers/media/usb/em28xx/em28xx-camera.c: In function 
'em28xx_probe_sensor_micron':
drivers/media/usb/em28xx/em28xx-camera.c:205:1: error: the frame size of 1256 
bytes is larger than 1152 bytes [-Werror=frame-larger-than=]
drivers/media/usb/em28xx/em28xx-camera.c: In function 
'em28xx_probe_sensor_omnivision':
drivers/media/usb/em28xx/em28xx-camera.c:317:1: error: the frame size of 1248 
bytes is larger than 1152 bytes [-Werror=frame-larger-than=]

This cleans up both of the above by removing the need for those
structures, calling the lower-level i2c function directly.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/em28xx/em28xx-camera.c | 87 ++--
 1 file changed, 50 insertions(+), 37 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-camera.c 
b/drivers/media/usb/em28xx/em28xx-camera.c
index 89c890ba7dd6..e64940f95a91 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -99,6 +99,25 @@ static int em28xx_initialize_mt9m001(struct em28xx *dev)
return 0;
 }
 
+/* NOTE: i2c_smbus_read_word_data() doesn't work with BE data */
+static int em28xx_i2c_read_chip_id(struct em28xx *dev, u16 addr, u8 reg, void 
*buf)
+{
+   struct i2c_client *client = >i2c_client[dev->def_i2c_bus];
+   struct i2c_msg msg[2];
+
+   msg[0].addr = addr;
+   msg[0].flags = client->flags & I2C_M_TEN;
+   msg[0].len = 1;
+   msg[0].buf = 
+   msg[1].addr = addr;
+   msg[1].flags = client->flags & I2C_M_TEN;
+   msg[1].flags |= I2C_M_RD;
+   msg[1].len = 2;
+   msg[1].buf = buf;
+
+   return i2c_transfer(client->adapter, msg, 2);
+}
+
 /*
  * Probes Micron sensors with 8 bit address and 16 bit register width
  */
@@ -106,48 +125,29 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
 {
int ret, i;
char *name;
-   u8 reg;
__be16 id_be;
+   u16 addr;
u16 id;
 
-   struct i2c_client client = dev->i2c_client[dev->def_i2c_bus];
-
dev->em28xx_sensor = EM28XX_NOSENSOR;
for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END; i++) {
-   client.addr = micron_sensor_addrs[i];
-   /* NOTE: i2c_smbus_read_word_data() doesn't work with BE data */
+   addr = micron_sensor_addrs[i];
/* Read chip ID from register 0x00 */
-   reg = 0x00;
-   ret = i2c_master_send(, , 1);
+   ret = em28xx_i2c_read_chip_id(dev, addr, 0x00, _be);
if (ret < 0) {
if (ret != -ENXIO)
dev_err(>intf->dev,
"couldn't read from i2c device 0x%02x: 
error %i\n",
-  client.addr << 1, ret);
-   continue;
-   }
-   ret = i2c_master_recv(, (u8 *)_be, 2);
-   if (ret < 0) {
-   dev_err(>intf->dev,
-   "couldn't read from i2c device 0x%02x: error 
%i\n",
-   client.addr << 1, ret);
+  addr << 1, ret);
continue;
}
id = be16_to_cpu(id_be);
/* Read chip ID from register 0xff */
-   reg = 0xff;
-   ret = i2c_master_send(, , 1);
+   ret = em28xx_i2c_read_chip_id(dev, addr, 0xff, _be);
if (ret < 0) {
dev_err(>intf->dev,
"couldn't read from i2c device 0x%02x: error 
%i\n",
-   client.addr << 1, ret);
-   continue;
-   }
-   ret = i2c_master_recv(, (u8 *)_be, 2);
-   if (ret < 0) {
-   dev_err(>intf->dev,
-   "couldn't read from i2c device 0x%02x: error 
%i\n",
-   client.addr << 1, ret);
+   addr << 1, ret);
continue;
}
/* Validate chip ID to be sure we have a Micron device */
@@ -197,13 +197,26 @@ static int em28xx_probe_sensor_micron(struct em28xx *dev)
dev_info(>intf->dev,
 "sensor %s detected\n", name);
 
-   dev->i2c_client[dev->def_i2c_bus].addr = client.addr;
+   dev->i2c_client[dev->def_i2c_bus].addr = addr;
return 0;
}
 
return -ENODEV;
 }
 
+/* like i2c_smbus_read_byte_data, but allows passing an addr */
+static int em28xx_smbus_read_byte(struct em28xx *dev, u16 addr, u8 command)
+{
+   struct i2c_client *client = >i2c_client[dev->def_i2c_bus];
+   union i2c_smbus_data data;
+   int status;
+
+   status = 

[PATCH 1/4] [media] pvrusb2: reduce stack usage pvr2_eeprom_analyze()

[Arnd Bergmann]

The driver uses a relatively large data structure on the stack, which
showed up on my radar as we get a warning with the "latent entropy"
GCC plugin:

drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 
bytes is larger than 1152 bytes [-Werror=frame-larger-than=]

The warning is usually hidden as we raise the warning limit to 2048
when the plugin is enabled, but I'd like to lower that again in the
future, and making this function smaller helps to do that without
build regressions.

Further analysis shows that putting an 'i2c_client' structure on
the stack is not really supported, as the embedded 'struct device'
is not initialized here, and we are only saved by the fact that
the function that is called here does not use the pointer at all.

Fixes: d855497edbfb ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/pvrusb2/pvrusb2-eeprom.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c 
b/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
index 276b17fb9aad..b8fcd9660094 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
@@ -122,15 +122,10 @@ int pvr2_eeprom_analyze(struct pvr2_hdw *hdw)
memset(,0,sizeof(tvdata));
 
eeprom = pvr2_eeprom_fetch(hdw);
-   if (!eeprom) return -EINVAL;
-
-   {
-   struct i2c_client fake_client;
-   /* Newer version expects a useless client interface */
-   fake_client.addr = hdw->eeprom_addr;
-   fake_client.adapter = >i2c_adap;
-   tveeprom_hauppauge_analog(_client,,eeprom);
-   }
+   if (!eeprom)
+   return -EINVAL;
+
+   tveeprom_hauppauge_analog(NULL, , eeprom);
 
trace_eeprom("eeprom assumed v4l tveeprom module");
trace_eeprom("eeprom direct call results:");
-- 
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] [media] ttpci: address stringop overflow warning

[Arnd Bergmann]

gcc-7.0.1 warns about old code in ttpci:

In file included from drivers/media/pci/ttpci/av7110.c:63:0:
In function 'irdebi.isra.2',
inlined from 'start_debi_dma' at drivers/media/pci/ttpci/av7110.c:376:3,
inlined from 'gpioirq' at drivers/media/pci/ttpci/av7110.c:659:3:
drivers/media/pci/ttpci/av7110_hw.h:406:3: warning: 'memcpy': specified size 
between 18446744071562067968 and 18446744073709551615 exceeds maximum object 
size 9223372036854775807 [-Wstringop-overflow=]
   memcpy(av7110->debi_virt, (char *) , count);
In function 'irdebi.isra.2',
inlined from 'start_debi_dma' at drivers/media/pci/ttpci/av7110.c:376:3,
inlined from 'gpioirq' at drivers/media/pci/ttpci/av7110.c:668:3:
drivers/media/pci/ttpci/av7110_hw.h:406:3: warning: 'memcpy': specified size 
between 18446744071562067968 and 18446744073709551615 exceeds maximum object 
size 9223372036854775807 [-Wstringop-overflow=]
   memcpy(av7110->debi_virt, (char *) , count);

Apparently, 'count' can be negative here, which will then get turned
into a giant size argument for memcpy. Changing the sizes to 'unsigned
int' instead seems safe as we already check for maximum sizes, and it
also simplifies the code a bit.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/pci/ttpci/av7110_hw.c |  8 
 drivers/media/pci/ttpci/av7110_hw.h | 12 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/media/pci/ttpci/av7110_hw.c 
b/drivers/media/pci/ttpci/av7110_hw.c
index 520414cbe087..cf6291b32ee6 100644
--- a/drivers/media/pci/ttpci/av7110_hw.c
+++ b/drivers/media/pci/ttpci/av7110_hw.c
@@ -56,11 +56,11 @@
by Nathan Laredo  */
 
 int av7110_debiwrite(struct av7110 *av7110, u32 config,
-int addr, u32 val, int count)
+int addr, u32 val, unsigned int count)
 {
struct saa7146_dev *dev = av7110->dev;
 
-   if (count <= 0 || count > 32764) {
+   if (count > 32764) {
printk("%s: invalid count %d\n", __func__, count);
return -1;
}
@@ -78,12 +78,12 @@ int av7110_debiwrite(struct av7110 *av7110, u32 config,
return 0;
 }
 
-u32 av7110_debiread(struct av7110 *av7110, u32 config, int addr, int count)
+u32 av7110_debiread(struct av7110 *av7110, u32 config, int addr, unsigned int 
count)
 {
struct saa7146_dev *dev = av7110->dev;
u32 result = 0;
 
-   if (count > 32764 || count <= 0) {
+   if (count > 32764) {
printk("%s: invalid count %d\n", __func__, count);
return 0;
}
diff --git a/drivers/media/pci/ttpci/av7110_hw.h 
b/drivers/media/pci/ttpci/av7110_hw.h
index 1634aba5cb84..ccb148059406 100644
--- a/drivers/media/pci/ttpci/av7110_hw.h
+++ b/drivers/media/pci/ttpci/av7110_hw.h
@@ -377,14 +377,14 @@ extern int av7110_fw_request(struct av7110 *av7110, u16 
*request_buf,
 
 /* DEBI (saa7146 data extension bus interface) access */
 extern int av7110_debiwrite(struct av7110 *av7110, u32 config,
-   int addr, u32 val, int count);
+   int addr, u32 val, unsigned int count);
 extern u32 av7110_debiread(struct av7110 *av7110, u32 config,
-  int addr, int count);
+  int addr, unsigned int count);
 
 
 /* DEBI during interrupt */
 /* single word writes */
-static inline void iwdebi(struct av7110 *av7110, u32 config, int addr, u32 
val, int count)
+static inline void iwdebi(struct av7110 *av7110, u32 config, int addr, u32 
val, unsigned int count)
 {
av7110_debiwrite(av7110, config, addr, val, count);
 }
@@ -397,7 +397,7 @@ static inline void mwdebi(struct av7110 *av7110, u32 
config, int addr,
av7110_debiwrite(av7110, config, addr, 0, count);
 }
 
-static inline u32 irdebi(struct av7110 *av7110, u32 config, int addr, u32 val, 
int count)
+static inline u32 irdebi(struct av7110 *av7110, u32 config, int addr, u32 val, 
unsigned int count)
 {
u32 res;
 
@@ -408,7 +408,7 @@ static inline u32 irdebi(struct av7110 *av7110, u32 config, 
int addr, u32 val, i
 }
 
 /* DEBI outside interrupts, only for count <= 4! */
-static inline void wdebi(struct av7110 *av7110, u32 config, int addr, u32 val, 
int count)
+static inline void wdebi(struct av7110 *av7110, u32 config, int addr, u32 val, 
unsigned int count)
 {
unsigned long flags;
 
@@ -417,7 +417,7 @@ static inline void wdebi(struct av7110 *av7110, u32 config, 
int addr, u32 val, i
spin_unlock_irqrestore(>debilock, flags);
 }
 
-static inline u32 rdebi(struct av7110 *av7110, u32 config, int addr, u32 val, 
int count)
+static inline u32 rdebi(struct av7110 *av7110, u32 config, int addr, u32 val, 
unsigned int count)
 {
unsigned long flags;
u32 res;
-- 
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  

[PATCH v7 02/10] ARM: dts: STiH407-family: add DELTA dt node

[Hugues Fruchet]

This patch adds DT node for STMicroelectronics
DELTA V4L2 video decoder

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

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index c8b2944..c32933a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -1002,5 +1002,15 @@
 
status = "disabled";
};
+
+   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 v7 01/10] Documentation: DT: add bindings for ST DELTA

[Hugues Fruchet]

This patch adds DT binding documentation for STMicroelectronics
DELTA V4L2 video decoder.

Acked-by: Peter Griffin 
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 v7 00/10] Add support for DELTA video decoder of STMicroelectronics STiH4xx SoC series

[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 7
  - update after v6 review:
- devicetree: move delta section from stih410.dtsi to stih407-family.dtsi.
- missing "[media]" prefix in last commit
  - Acked-by: Peter Griffin 

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)

[PATCH 4/4] [media] mxl111sf: reduce stack usage in init function

[Arnd Bergmann]

mxl111sf uses a lot of kernel stack memory as it puts an i2c_client
structure on the stack:

drivers/media/usb/dvb-usb-v2/mxl111sf.c: In function 'mxl111sf_init':
drivers/media/usb/dvb-usb-v2/mxl111sf.c:953:1: error: the frame size of 1248 
bytes is larger than 1152 bytes [-Werror=frame-larger-than=]

We can avoid doing this by open-coding the call to i2c_transfer()
instead of calling tveeprom_read(), and not passing an i2c_client
pointer to tveeprom_hauppauge_analog(), which would ignore that
anyway.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/dvb-usb-v2/mxl111sf.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c 
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index 80c635980526..60bc5cc9a483 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -919,7 +919,12 @@ static int mxl111sf_init(struct dvb_usb_device *d)
struct mxl111sf_state *state = d_to_priv(d);
int ret;
static u8 eeprom[256];
-   struct i2c_client c;
+   u8 reg = 0;
+   struct i2c_msg msg[2] = {
+   { .addr = 0xa0 >> 1, .len = 1, .buf =  },
+   { .addr = 0xa0 >> 1, .flags = I2C_M_RD,
+ .len = sizeof(eeprom), .buf = eeprom },
+   };
 
ret = get_chip_info(state);
if (mxl_fail(ret))
@@ -930,13 +935,10 @@ static int mxl111sf_init(struct dvb_usb_device *d)
if (state->chip_rev > MXL111SF_V6)
mxl111sf_config_pin_mux_modes(state, PIN_MUX_TS_SPI_IN_MODE_1);
 
-   c.adapter = >i2c_adap;
-   c.addr = 0xa0 >> 1;
-
-   ret = tveeprom_read(, eeprom, sizeof(eeprom));
+   ret = i2c_transfer(>i2c_adap, msg, 2);
if (mxl_fail(ret))
return 0;
-   tveeprom_hauppauge_analog(, >tv, (0x84 == eeprom[0xa0]) ?
+   tveeprom_hauppauge_analog(NULL, >tv, (0x84 == eeprom[0xa0]) ?
eeprom + 0xa0 : eeprom + 0x80);
 #if 0
switch (state->tv.model) {
-- 
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 3/4] [media] cx231xx-i2c: reduce stack size in bus scan

[Arnd Bergmann]

The cx231xx_do_i2c_scan function needs a lot of stack because
it puts an i2c_client structure on it:

drivers/media/usb/cx231xx/cx231xx-i2c.c: In function 'cx231xx_do_i2c_scan':
drivers/media/usb/cx231xx/cx231xx-i2c.c:518:1: error: the frame size of 1248 
bytes is larger than 1152 bytes [-Werror=frame-larger-than=]

This changes it to call i2c_transfer() directly instead, avoiding the
need for the structure.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/cx231xx/cx231xx-i2c.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-i2c.c 
b/drivers/media/usb/cx231xx/cx231xx-i2c.c
index 35e9acfe63d3..24e23a06d8c6 100644
--- a/drivers/media/usb/cx231xx/cx231xx-i2c.c
+++ b/drivers/media/usb/cx231xx/cx231xx-i2c.c
@@ -491,20 +491,24 @@ void cx231xx_do_i2c_scan(struct cx231xx *dev, int 
i2c_port)
 {
unsigned char buf;
int i, rc;
-   struct i2c_client client;
+   struct i2c_adapter *adap;
+   struct i2c_msg msg = {
+   .flags = I2C_M_RD,
+   .len = 1,
+   .buf = ,
+   };
 
if (!i2c_scan)
return;
 
/* Don't generate I2C errors during scan */
dev->i2c_scan_running = true;
-
-   memset(, 0, sizeof(client));
-   client.adapter = cx231xx_get_i2c_adap(dev, i2c_port);
+   adap = cx231xx_get_i2c_adap(dev, i2c_port);
 
for (i = 0; i < 128; i++) {
-   client.addr = i;
-   rc = i2c_master_recv(, , 0);
+   msg.addr = i;
+   rc = i2c_transfer(adap, , 1);
+
if (rc < 0)
continue;
dev_info(dev->dev,
-- 
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] [media] dvb-usb-v2: avoid use-after-free

[Arnd Bergmann]

I ran into a stack frame size warning because of the on-stack copy of
the USB device structure:

drivers/media/usb/dvb-usb-v2/dvb_usb_core.c: In function 'dvb_usbv2_disconnect':
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:1029:1: error: the frame size of 
1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

Copying a device structure like this is wrong for a number of other reasons
too aside from the possible stack overflow. One of them is that the
dev_info() call will print the name of the device later, but AFAICT
we have only copied a pointer to the name earlier and the actual name
has been freed by the time it gets printed.

This removes the on-stack copy of the device and instead copies the
device name using kstrdup(). I'm ignoring the possible failure here
as both printk() and kfree() are able to deal with NULL pointers.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c 
b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index a8e6624fbe83..a9bb2dde98ea 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -1013,8 +1013,8 @@ EXPORT_SYMBOL(dvb_usbv2_probe);
 void dvb_usbv2_disconnect(struct usb_interface *intf)
 {
struct dvb_usb_device *d = usb_get_intfdata(intf);
-   const char *name = d->name;
-   struct device dev = d->udev->dev;
+   const char *devname = kstrdup(dev_name(>udev->dev), GFP_KERNEL);
+   const char *drvname = d->name;
 
dev_dbg(>udev->dev, "%s: bInterfaceNumber=%d\n", __func__,
intf->cur_altsetting->desc.bInterfaceNumber);
@@ -1024,8 +1024,9 @@ void dvb_usbv2_disconnect(struct usb_interface *intf)
 
dvb_usbv2_exit(d);
 
-   dev_info(, "%s: '%s' successfully deinitialized and disconnected\n",
-   KBUILD_MODNAME, name);
+   pr_info("%s: '%s:%s' successfully deinitialized and disconnected\n",
+   KBUILD_MODNAME, drvname, devname);
+   kfree(devname);
 }
 EXPORT_SYMBOL(dvb_usbv2_disconnect);
 
-- 
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

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

[Andreas Färber]

Am 01.02.2017 um 23:26 schrieb 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).

Shows up fine here now,

Reviewed-by: Andreas Färber 

Didn't expect a resend for that btw.

Thanks,
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: [PATCH] [media] staging: bcm2835: mark all symbols as 'static'

[Arnd Bergmann]

On Thu, Feb 2, 2017 at 1:22 PM, Greg Kroah-Hartman
 wrote:
> On Thu, Feb 02, 2017 at 01:11:36PM +0100, Arnd Bergmann wrote:
>> On Thu, Feb 2, 2017 at 1:04 PM, Arnd Bergmann  wrote:
>> > On Thu, Feb 2, 2017 at 12:34 PM, Arnd Bergmann  wrote:
>> >> I got a link error in allyesconfig:
>> >> Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera 
>> >> driver.")
>> >> Signed-off-by: Arnd Bergmann 
>> >
>> > Please disregard this patch version, it's broken.
>>
>> Too late, I see it's already applied, I'll send a follow-up to revert
>> the first hunk.
>
> Ah, I could have just dropped your patch (it's a testing branch that I
> can rebase), but I took your newer patch that fixed it up, so all is
> good.
>
> That's what I get for applying patches too quickly :)

I should really have been more careful about testing. I had the first
version in my
working tree while doing randconfig tests. None of the new randconfig builds
ran into the issue (the driver gets rarely enabled because of its dependencies),
and the original failure had already been marked as fixed in my build system
after an earlier patch only changed one of the prototypes.

Arnd
--
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] staging: bcm2835: mark all symbols as 'static'

[Greg Kroah-Hartman]

On Thu, Feb 02, 2017 at 01:11:36PM +0100, Arnd Bergmann wrote:
> On Thu, Feb 2, 2017 at 1:04 PM, Arnd Bergmann  wrote:
> > On Thu, Feb 2, 2017 at 12:34 PM, Arnd Bergmann  wrote:
> >> I got a link error in allyesconfig:
> >> Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera 
> >> driver.")
> >> Signed-off-by: Arnd Bergmann 
> >
> > Please disregard this patch version, it's broken.
> 
> Too late, I see it's already applied, I'll send a follow-up to revert
> the first hunk.

Ah, I could have just dropped your patch (it's a testing branch that I
can rebase), but I took your newer patch that fixed it up, so all is
good.

That's what I get for applying patches too quickly :)

thanks,

greg k-h
--
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

[Javier Martinez Canillas]

Hello Shuah,

On 02/01/2017 11:25 PM, Shuah Khan wrote:
> 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.
>

I disagree. User-space trying different field orders doesn't sound like an
error to me since as mentioned there isn't an ioctl to enum supported ones.

In fact other drivers don't print anything in their try_fmt handler for the
same case, for example [0] and [1].

> thanks,
> -- Shuah
> 

[0]: 
http://lxr.free-electrons.com/source/drivers/media/platform/mx2_emmaprp.c#L496
[1]: 
http://lxr.free-electrons.com/source/drivers/media/platform/exynos4-is/fimc-m2m.c#L297

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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: don't mark 'bcm2835_v4l2_debug' as static

[Arnd Bergmann]

This one unfortunately slipped through my own build testing, my patch
caused a new build error:

bcm2835-camera.c:53:12: error: static declaration of 'bcm2835_v4l2_debug' 
follows non-static declaration

We want the symbol to be global as it is indeed used in more than one
file and declared 'extern' in a header.

Fixes: 757b9bd074 ("staging: bcm2835: mark all symbols as 'static'")
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/media/platform/bcm2835/bcm2835-camera.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c 
b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
index ced8eb5de0f0..ca15a698e018 100644
--- a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
+++ b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
@@ -50,7 +50,7 @@ MODULE_AUTHOR("Vincent Sanders");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(BM2835_MMAL_VERSION);
 
-static int bcm2835_v4l2_debug;
+int bcm2835_v4l2_debug;
 module_param_named(debug, bcm2835_v4l2_debug, int, 0644);
 MODULE_PARM_DESC(bcm2835_v4l2_debug, "Debug level 0-2");
 
-- 
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

Re: [PATCH v7 1/2] media: i2c/ov5645: add the device tree binding document

[Todor Tomov]

Hi Rob,

Could you please take a look again at this patch?

It had received an Ack from you for patch v3. Up to v7 the changes are:
- frequency of the sensor external clock added to DT;
- names of the hardware pins of the gpios are added in the description
  (the -gpios properties are still the same).

Best regards,
Todor


On 11/14/2016 12:24 PM, Todor Tomov wrote:
> Add the document for ov5645 device tree binding.
> 
> Signed-off-by: Todor Tomov 
> ---
>  .../devicetree/bindings/media/i2c/ov5645.txt   | 54 
> ++
>  1 file changed, 54 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5645.txt 
> b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
> new file mode 100644
> index 000..fd7aec9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
> @@ -0,0 +1,54 @@
> +* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
> +
> +The Omnivision OV5645 is a 1/4-Inch CMOS active pixel digital image sensor 
> with
> +an active array size of 2592H x 1944V. It is programmable through a serial 
> I2C
> +interface.
> +
> +Required Properties:
> +- compatible: Value should be "ovti,ov5645".
> +- clocks: Reference to the xclk clock.
> +- clock-names: Should be "xclk".
> +- clock-frequency: Frequency of the xclk clock.
> +- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This 
> corresponds
> +  to the hardware pin PWDNB which is physically active low.
> +- reset-gpios: Chip reset GPIO. Polarity is GPIO_ACTIVE_LOW. This 
> corresponds to
> +  the hardware pin RESETB.
> +- vdddo-supply: Chip digital IO regulator.
> +- vdda-supply: Chip analog regulator.
> +- vddd-supply: Chip digital core regulator.
> +
> +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:
> +
> +  {
> + ...
> +
> + ov5645: ov5645@78 {
> + compatible = "ovti,ov5645";
> + reg = <0x78>;
> +
> + enable-gpios = < 6 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 20 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_rear_default>;
> +
> + clocks = < 200>;
> + clock-names = "xclk";
> + clock-frequency = <2388>;
> +
> + vdddo-supply = <_dovdd_1v8>;
> + vdda-supply = <_avdd_2v8>;
> + vddd-supply = <_dvdd_1v2>;
> +
> + port {
> + ov5645_ep: endpoint {
> + clock-lanes = <1>;
> + data-lanes = <0 2>;
> + remote-endpoint = <_ep>;
> + };
> + };
> + };
> + };
> 

--
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] staging: bcm2835: mark all symbols as 'static'

[Arnd Bergmann]

On Thu, Feb 2, 2017 at 1:04 PM, Arnd Bergmann  wrote:
> On Thu, Feb 2, 2017 at 12:34 PM, Arnd Bergmann  wrote:
>> I got a link error in allyesconfig:
>> Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera 
>> driver.")
>> Signed-off-by: Arnd Bergmann 
>
> Please disregard this patch version, it's broken.

Too late, I see it's already applied, I'll send a follow-up to revert
the first hunk.

Arnd
--
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] staging: bcm2835: mark all symbols as 'static'

[Arnd Bergmann]

On Thu, Feb 2, 2017 at 12:34 PM, Arnd Bergmann  wrote:
> I got a link error in allyesconfig:
>
> drivers/staging/media/platform/bcm2835/bcm2835-camera.o: In function 
> `vidioc_enum_framesizes':
> bcm2835-camera.c:(.text.vidioc_enum_framesizes+0x0): multiple definition of 
> `vidioc_enum_framesizes'
> drivers/media/platform/vivid/vivid-vid-cap.o:vivid-vid-cap.c:(.text.vidioc_enum_framesizes+0x0):
>  first defined here
>
> While both drivers are equally at fault for this problem, the bcm2835 one was
> just added and is easier to fix, as it is only one file, and none of its 
> symbols
> need to be globally visible. This marks the three global symbols as static.
>
> Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera 
> driver.")
> Signed-off-by: Arnd Bergmann 

Please disregard this patch version, it's broken.

> @@ -50,7 +50,7 @@ MODULE_AUTHOR("Vincent Sanders");
>  MODULE_LICENSE("GPL");
>  MODULE_VERSION(BM2835_MMAL_VERSION);
>
> -int bcm2835_v4l2_debug;
> +static int bcm2835_v4l2_debug;
>  module_param_named(debug, bcm2835_v4l2_debug, int, 0644);
>  MODULE_PARM_DESC(bcm2835_v4l2_debug, "Debug level 0-2");
>

This symbol is in fact used in more than one file.

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

[Philipp Zabel]

On Fri, 2017-01-06 at 18:11 -0800, Steve Longerbeam wrote:
> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> for sensors with a MIPI CSI2 interface.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/staging/media/imx/Makefile|   1 +
>  drivers/staging/media/imx/imx-mipi-csi2.c | 501 
> ++
>  2 files changed, 502 insertions(+)
>  create mode 100644 drivers/staging/media/imx/imx-mipi-csi2.c
> 
> diff --git a/drivers/staging/media/imx/Makefile 
> b/drivers/staging/media/imx/Makefile
> index fe9e992..0decef7 100644
> --- a/drivers/staging/media/imx/Makefile
> +++ b/drivers/staging/media/imx/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-ic.o
>  obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
>  obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-smfc.o
>  obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-camif.o
> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-mipi-csi2.o
> diff --git a/drivers/staging/media/imx/imx-mipi-csi2.c 
> b/drivers/staging/media/imx/imx-mipi-csi2.c
> new file mode 100644
> index 000..daa6e1d
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-mipi-csi2.c
> @@ -0,0 +1,501 @@
> +/*
> + * MIPI CSI-2 Receiver Subdev for Freescale i.MX5/6 SOC.
> + *
> + * Copyright (c) 2012-2014 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "imx-media.h"
> +
> +/*
> + * there must be 5 pads: 1 input pad from sensor, and
> + * the 4 virtual channel output pads
> + */
> +#define CSI2_NUM_SINK_PADS  1
> +#define CSI2_NUM_SRC_PADS   4
> +#define CSI2_NUM_PADS   5
> +
> +struct imxcsi2_dev {
> + struct device  *dev;
> + struct imx_media_dev   *md;
> + struct v4l2_subdev  sd;
> + struct media_pad   pad[CSI2_NUM_PADS];
> + struct v4l2_mbus_framefmt format_mbus;
> + struct v4l2_subdev *src_sd;
> + struct v4l2_subdev *sink_sd[CSI2_NUM_SRC_PADS];

I see no reason to store pointers to the remote v4l2_subdevs.

> + intinput_pad;
> + struct clk *dphy_clk;
> + struct clk *cfg_clk;
> + struct clk *pix_clk; /* what is this? */
> + void __iomem   *base;
> + int intr1;
> + int intr2;

The interrupts are not used, I'd remove them and the dead code in
_probe.

> + struct v4l2_of_bus_mipi_csi2 bus;
> + boolon;
> + boolstream_on;
> +};
> +
> +#define DEVICE_NAME "imx6-mipi-csi2"
> +
> +/* Register offsets */
> +#define CSI2_VERSION0x000
> +#define CSI2_N_LANES0x004
> +#define CSI2_PHY_SHUTDOWNZ  0x008
> +#define CSI2_DPHY_RSTZ  0x00c
> +#define CSI2_RESETN 0x010
> +#define CSI2_PHY_STATE  0x014
> +#define CSI2_DATA_IDS_1 0x018
> +#define CSI2_DATA_IDS_2 0x01c
> +#define CSI2_ERR1   0x020
> +#define CSI2_ERR2   0x024
> +#define CSI2_MSK1   0x028
> +#define CSI2_MSK2   0x02c
> +#define CSI2_PHY_TST_CTRL0  0x030
> +#define CSI2_PHY_TST_CTRL1  0x034
> +#define CSI2_SFT_RESET  0xf00
> +
> +static inline struct imxcsi2_dev *sd_to_dev(struct v4l2_subdev *sdev)
> +{
> + return container_of(sdev, struct imxcsi2_dev, sd);
> +}
> +
> +static inline u32 imxcsi2_read(struct imxcsi2_dev *csi2, unsigned int regoff)
> +{
> + return readl(csi2->base + regoff);
> +}
> +
> +static inline void imxcsi2_write(struct imxcsi2_dev *csi2, u32 val,
> +  unsigned int regoff)
> +{
> + writel(val, csi2->base + regoff);
> +}

Do those two wrappers really make the code more readable?

> +static void imxcsi2_set_lanes(struct imxcsi2_dev *csi2)
> +{
> + int lanes = csi2->bus.num_data_lanes;
> +
> + imxcsi2_write(csi2, lanes - 1, CSI2_N_LANES);
> +}
> +
> +static void imxcsi2_enable(struct imxcsi2_dev *csi2, bool enable)
> +{
> + if (enable) {
> + imxcsi2_write(csi2, 0x, CSI2_PHY_SHUTDOWNZ);
> + imxcsi2_write(csi2, 0x, CSI2_DPHY_RSTZ);
> + imxcsi2_write(csi2, 0x, CSI2_RESETN);

Given that these registers only contain a single bit, and bits 31:1 are
documented as reserved, 0, I think these should write 1 instead of
0x.

> + } else {
> + imxcsi2_write(csi2, 0x0, CSI2_PHY_SHUTDOWNZ);
> + imxcsi2_write(csi2, 0x0, CSI2_DPHY_RSTZ);
> + imxcsi2_write(csi2, 0x0, CSI2_RESETN);
> + }
> +}
> +
> +static void imxcsi2_reset(struct imxcsi2_dev *csi2)
> +{
> + 

[PATCH] [media] staging: bcm2835: mark all symbols as 'static'

[Arnd Bergmann]

I got a link error in allyesconfig:

drivers/staging/media/platform/bcm2835/bcm2835-camera.o: In function 
`vidioc_enum_framesizes':
bcm2835-camera.c:(.text.vidioc_enum_framesizes+0x0): multiple definition of 
`vidioc_enum_framesizes'
drivers/media/platform/vivid/vivid-vid-cap.o:vivid-vid-cap.c:(.text.vidioc_enum_framesizes+0x0):
 first defined here

While both drivers are equally at fault for this problem, the bcm2835 one was
just added and is easier to fix, as it is only one file, and none of its symbols
need to be globally visible. This marks the three global symbols as static.

Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera 
driver.")
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/media/platform/bcm2835/bcm2835-camera.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c 
b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
index 105d88102cd9..ced8eb5de0f0 100644
--- a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
+++ b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
@@ -50,7 +50,7 @@ MODULE_AUTHOR("Vincent Sanders");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(BM2835_MMAL_VERSION);
 
-int bcm2835_v4l2_debug;
+static int bcm2835_v4l2_debug;
 module_param_named(debug, bcm2835_v4l2_debug, int, 0644);
 MODULE_PARM_DESC(bcm2835_v4l2_debug, "Debug level 0-2");
 
@@ -1312,7 +1312,7 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
*priv,
return ret;
 }
 
-int vidioc_enum_framesizes(struct file *file, void *fh,
+static int vidioc_enum_framesizes(struct file *file, void *fh,
   struct v4l2_frmsizeenum *fsize)
 {
struct bm2835_mmal_dev *dev = video_drvdata(file);
@@ -1842,7 +1842,7 @@ static int __init bm2835_mmal_init_device(struct 
bm2835_mmal_dev *dev,
return 0;
 }
 
-void bcm2835_cleanup_instance(struct bm2835_mmal_dev *dev)
+static void bcm2835_cleanup_instance(struct bm2835_mmal_dev *dev)
 {
if (!dev)
return;
-- 
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

Re: ir-keytable: infinite loops, segfaults

[Vincent McIntyre]

Hey there

On 11/30/16, Vincent McIntyre  wrote:
> On Sun, Nov 27, 2016 at 07:35:10PM +, Sean Young wrote:
>>
>> > I wanted to mention that the IR protocol is still showing as unknown.
>> > Is there anything that can be done to sort that out?
>>
>> It would be nice if that could be sorted out, although that would be
>> a separate patch.
>>
>> So all we know right now is what scancode the IR receiver hardware
>> produces but we have no idea what IR protocol is being used. In order to
>> figure this out we need a recording of the IR the remote sends, for which
>> a different IR receiver is needed. Neither your imon nor your
>> dvb_usb_af9035 can do this, something like a mce usb IR receiver would
>> be best. Do you have access to one? One with an IR emitter would be
>> best.
>>
>> So with that we can have a recording of the IR the remote sends, and
>> with the emitter we can see which IR protocols the IR receiver
>> understands.
>
> Haven't been able to find anything suitable. I would order something
> but I won't be able to follow up for several weeks.
> I'll ask on the myth list to see if anyone is up for trying this.
>

I bought one of these, but I am not sure how to make the recording:

# lsusb -d 1934:5168 -v

Bus 008 Device 003: ID 1934:5168 Feature Integration Technology Inc.
(Fintek) F71610A or F71612A Consumer Infrared Receiver/Transceiver
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize016
  idVendor   0x1934 Feature Integration Technology Inc. (Fintek)
  idProduct  0x5168 F71610A or F71612A Consumer Infrared
Receiver/Transceiver
  bcdDevice0.01
  iManufacturer   1 FINTEK
  iProduct2 eHome Infrared Transceiver
  iSerial 3 88636562727801
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   1
Device Status: 0x
  (Bus Powered)


# ir-keytable -v
Found device /sys/class/rc/rc0/
Found device /sys/class/rc/rc1/
Found device /sys/class/rc/rc2/
Found device /sys/class/rc/rc3/  < the new device
Input sysfs node is /sys/class/rc/rc0/input8/
Event sysfs node is /sys/class/rc/rc0/input8/event5/
Parsing uevent /sys/class/rc/rc0/input8/event5/uevent
/sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13
/sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69
/sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5
Parsing uevent /sys/class/rc/rc0/uevent
/sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce
/sys/class/rc/rc0/uevent uevent DRV_NAME=imon
input device is /dev/input/event5
/sys/class/rc/rc0/protocols protocol rc-6 (enabled)
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
Driver imon, table rc-imon-mce
Supported protocols: rc-6
Enabled protocols: rc-6
Name: iMON Remote (15c2:ffdc)
bus: 3, vendor/product: 15c2:ffdc, version: 0x
Repeat delay = 500 ms, repeat period = 125 ms
Input sysfs node is /sys/class/rc/rc1/input18/
Event sysfs node is /sys/class/rc/rc1/input18/event15/
Parsing uevent /sys/class/rc/rc1/input18/event15/uevent
/sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13
/sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79
/sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15
Parsing uevent /sys/class/rc/rc1/uevent
/sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
/sys/class/rc/rc1/uevent 

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

[Patrice CHOTARD]

Hi Peter

On 02/01/2017 07:22 PM, Peter Griffin wrote:
> 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.

This mailing list was expected to be disabled on 31th December as 
STMicroelectronics stopped the contract with the service provider but 
. the mailing list is still alive.

We are looking for a replacement solution and then we will update the 
maintainers files

Patrice

>
> 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 
>
> ___
> Kernel mailing list
> ker...@stlinux.com
> http://www.stlinux.com/mailman/listinfo/kernel
>--
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 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver

[Laurent Pinchart]

Hi Steve,

Thank you for the patch. Many of the comments below apply to the ov5642 driver 
too, please take them into account when reworking patch 23/24.

On Friday 06 Jan 2017 18:11:40 Steve Longerbeam wrote:
> This driver is based on ov5640_mipi.c from Freescale imx_3.10.17_1.0.0_beta
> branch, modified heavily to bring forward to latest interfaces and code
> cleanup.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/staging/media/imx/Kconfig   |8 +
>  drivers/staging/media/imx/Makefile  |2 +
>  drivers/staging/media/imx/ov5640-mipi.c | 2348 

You're missing DT bindings.

The driver should go to drivers/media/i2c/ as it should not be specific to the 
i.MX6, and you can just call it ov5640.c.

>  3 files changed, 2358 insertions(+)
>  create mode 100644 drivers/staging/media/imx/ov5640-mipi.c
> 
> diff --git a/drivers/staging/media/imx/Kconfig
> b/drivers/staging/media/imx/Kconfig index ce2d2c8..09f373d 100644
> --- a/drivers/staging/media/imx/Kconfig
> +++ b/drivers/staging/media/imx/Kconfig
> @@ -17,5 +17,13 @@ config VIDEO_IMX_CAMERA
>   ---help---
> A video4linux camera capture driver for i.MX5/6.
> 
> +config IMX_OV5640_MIPI
> +   tristate "OmniVision OV5640 MIPI CSI-2 camera support"
> +   depends on GPIOLIB && VIDEO_IMX_CAMERA

The sensor driver is generic, it shouldn't depend on IMX. It should however 
depend on at least I2C and OF by the look of it.

> +   select IMX_MIPI_CSI2
> +   default y
> +   ---help---
> + MIPI CSI-2 OV5640 Camera support.
> +
>  endmenu
>  endif

[snip]

> diff --git a/drivers/staging/media/imx/ov5640-mipi.c
> b/drivers/staging/media/imx/ov5640-mipi.c new file mode 100644
> index 000..54647a7
> --- /dev/null
> +++ b/drivers/staging/media/imx/ov5640-mipi.c
> @@ -0,0 +1,2348 @@
> +/*
> + * Copyright (c) 2014 Mentor Graphics Inc.
> + * Copyright (C) 2011-2013 Freescale Semiconductor, Inc. All Rights
> Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Pet peeve of mine, please sort the headers alphabetically. It makes it easier 
to locate duplicated.

> +
> +#define OV5640_VOLTAGE_ANALOG   280
> +#define OV5640_VOLTAGE_DIGITAL_CORE 150
> +#define OV5640_VOLTAGE_DIGITAL_IO   180
> +
> +#define MIN_FPS 15
> +#define MAX_FPS 30
> +#define DEFAULT_FPS 30
> +
> +/* min/typical/max system clock (xclk) frequencies */
> +#define OV5640_XCLK_MIN  600
> +#define OV5640_XCLK_TYP 2400
> +#define OV5640_XCLK_MAX 5400
> +
> +/* min/typical/max pixel clock (mclk) frequencies */
> +#define OV5640_MCLK_MIN 4800
> +#define OV5640_MCLK_TYP 4800
> +#define OV5640_MCLK_MAX 9600
> +
> +#define OV5640_CHIP_ID  0x300A
> +#define OV5640_SLAVE_ID 0x3100
> +#define OV5640_DEFAULT_SLAVE_ID 0x3c

You're mixing lower-case and upper-case hex constants. Let's pick one. Kernel 
code usually favours lower-case.

Please define macros for all the other numerical constants you use in the 
driver (register addresses and values). The large registers tables can be an 
exception if you don't have access to the information, but for registers 
written manually, hardcoding numerical values isn't good.

> +
> +#define OV5640_MAX_CONTROLS 64
> +
> +enum ov5640_mode {
> + ov5640_mode_MIN = 0,
> + ov5640_mode_QCIF_176_144 = 0,
> + ov5640_mode_QVGA_320_240,
> + ov5640_mode_VGA_640_480,
> + ov5640_mode_NTSC_720_480,
> + ov5640_mode_PAL_720_576,
> + ov5640_mode_XGA_1024_768,
> + ov5640_mode_720P_1280_720,
> + ov5640_mode_1080P_1920_1080,
> + ov5640_mode_QSXGA_2592_1944,
> + ov5640_num_modes,
> + ov5640_mode_INIT = 0xff, /*only for sensor init*/

Please add spaces after /* and before */.

Enumerated values should be all upper-case.

> +};
> +
> +enum ov5640_frame_rate {
> + ov5640_15_fps,
> + ov5640_30_fps
> +};
> +
> +static int ov5640_framerates[] = {
> + [ov5640_15_fps] = 15,
> + [ov5640_30_fps] = 30,
> +};
> +#define ov5640_num_framerates ARRAY_SIZE(ov5640_framerates)
> +
> +/* image size under 1280 * 960 are SUBSAMPLING
> + * image size upper 1280 * 960 are SCALING
> + */

The kernel multi-line comment style is

/*
 * text
 * text
 */

> +enum ov5640_downsize_mode {
> + SUBSAMPLING,
> + SCALING,
> +};
> +
> +struct reg_value {
> + u16 reg_addr;
> + u8 val;
> + u8 mask;
> + u32 delay_ms;
> +};
> +
> +struct ov5640_mode_info {
> + enum ov5640_mode mode;
> + enum 

Re: [PATCH 09/11] [media] s5p-mfc: Add support for HEVC encoder

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add HEVC encoder support and necessary registers, V4L2 CIDs,
> and hevc encoder parameters
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |   28 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc.c|1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |   55 ++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  595 
> +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|8 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |  200 
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |7 +
>  8 files changed, 895 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 81a0a96..914ffec 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -20,13 +20,35 @@
>  #define S5P_FIMV_MFC_STATE_V10   0x7124
>  #define S5P_FIMV_D_STATIC_BUFFER_ADDR_V100xF570
>  #define S5P_FIMV_D_STATIC_BUFFER_SIZE_V100xF574
> +#define S5P_FIMV_E_NUM_T_LAYER_V10   0xFBAC
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER0_V100xFBB0
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER1_V100xFBB4
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER2_V100xFBB8
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER3_V100xFBBC
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER4_V100xFBC0
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER5_V100xFBC4
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER6_V100xFBC8
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER0_V10  0xFD18
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER1_V10  0xFD1C
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER2_V10  0xFD20
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER3_V10  0xFD24
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER4_V10  0xFD28
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER5_V10  0xFD2C
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER6_V10  0xFD30
> +#define S5P_FIMV_E_HEVC_OPTIONS_V10  0xFDD4
> +#define S5P_FIMV_E_HEVC_REFRESH_PERIOD_V10   0xFDD8
> +#define S5P_FIMV_E_HEVC_CHROMA_QP_OFFSET_V10 0xFDDC
> +#define S5P_FIMV_E_HEVC_LF_BETA_OFFSET_DIV2_V10  0xFDE0
> +#define S5P_FIMV_E_HEVC_LF_TC_OFFSET_DIV2_V100xFDE4
> +#define S5P_FIMV_E_HEVC_NAL_CONTROL_V10  0xFDE8
>  
>  /* MFCv10 Context buffer sizes */
>  #define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)/* 30KB */
>  #define MFC_H264_DEC_CTX_BUF_SIZE_V10(2 * SZ_1M) /* 2MB */
>  #define MFC_OTHER_DEC_CTX_BUF_SIZE_V10   (20 * SZ_1K)/* 20KB */
>  #define MFC_H264_ENC_CTX_BUF_SIZE_V10(100 * SZ_1K)   /* 100KB */
> -#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10   (15 * SZ_1K)/* 15KB */
> +#define MFC_HEVC_ENC_CTX_BUF_SIZE_V10(30 * SZ_1K)/* 30KB */
> +#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10  (15 * SZ_1K) /* 15KB */
>  
>  /* MFCv10 variant defines */
>  #define MAX_FW_SIZE_V10  (SZ_1M) /* 1MB */
> @@ -37,6 +59,7 @@
>  /* MFCv10 codec defines*/
>  #define S5P_FIMV_CODEC_HEVC_DEC  17
>  #define S5P_FIMV_CODEC_VP9_DEC   18
> +#define S5P_FIMV_CODEC_HEVC_ENC 26
>  
>  /* Decoder buffer size for MFC v10 */
>  #define DEC_VP9_STATIC_BUFFER_SIZE   20480
> @@ -53,6 +76,9 @@
>  #define ENC_V100_VP8_ME_SIZE(x, y)   \
>   (((x + 3) * (y + 3) * 8)\
>+ (((y * 64) + 1280) * (x + 7) / 8))
> +#define ENC_V100_HEVC_ME_SIZE(x, y)  \
> + (((x + 3) * (y + 3) * 32)   \
> +  + (((y * 128) + 1280) * (x + 3) / 4))

Use DIV_ROUND_UP.

>  
>  #endif /*_REGS_MFC_V10_H*/
>  
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index b014038..b01c556 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1549,6 +1549,7 @@ static int s5p_mfc_resume(struct device *dev)
>   .h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V10,
>   .other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
>   .h264_enc_ctx   = MFC_H264_ENC_CTX_BUF_SIZE_V10,
> + .hevc_enc_ctx   = MFC_HEVC_ENC_CTX_BUF_SIZE_V10,
>   .other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
>  };
>  
> 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 102b47e..7521fce 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -122,6 +122,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx 
> *ctx)
>   case S5P_MFC_CODEC_VP8_ENC:
>   codec_type = S5P_FIMV_CODEC_VP8_ENC_V7;
>   break;
> + case 

Re: [PATCH 08/11] [media] s5p-mfc: Add VP9 decoder support

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add support for codec definition and corresponding buffer
> requirements for VP9 decoder.
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |6 +
>  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.h|2 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   28 
> +++
>  6 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index a57009a..81a0a96 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -18,6 +18,8 @@
>  /* MFCv10 register definitions*/
>  #define S5P_FIMV_MFC_CLOCK_OFF_V10   0x7120
>  #define S5P_FIMV_MFC_STATE_V10   0x7124
> +#define S5P_FIMV_D_STATIC_BUFFER_ADDR_V100xF570
> +#define S5P_FIMV_D_STATIC_BUFFER_SIZE_V100xF574
>  
>  /* MFCv10 Context buffer sizes */
>  #define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)/* 30KB */
> @@ -34,6 +36,10 @@
>  
>  /* MFCv10 codec defines*/
>  #define S5P_FIMV_CODEC_HEVC_DEC  17
> +#define S5P_FIMV_CODEC_VP9_DEC   18
> +
> +/* Decoder buffer size for MFC v10 */
> +#define DEC_VP9_STATIC_BUFFER_SIZE   20480
>  
>  /* Encoder buffer size for MFC v10.0 */
>  #define ENC_V100_H264_ME_SIZE(x, y)  \
> 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 76eca67..102b47e 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -104,6 +104,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx 
> *ctx)
>   case S5P_MFC_CODEC_HEVC_DEC:
>   codec_type = S5P_FIMV_CODEC_HEVC_DEC;
>   break;
> + case S5P_MFC_CODEC_VP9_DEC:
> + codec_type = S5P_FIMV_CODEC_VP9_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 5c46060..e720ce6 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -80,6 +80,7 @@ static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void 
> *b)
>  #define S5P_MFC_CODEC_VC1RCV_DEC 6
>  #define S5P_MFC_CODEC_VP8_DEC7
>  #define S5P_MFC_CODEC_HEVC_DEC   17
> +#define S5P_MFC_CODEC_VP9_DEC18
>  
>  #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 9f459b3..93626ed 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -164,6 +164,14 @@
>   .num_planes = 1,
>   .versions   = MFC_V10_BIT,
>   },
> + {
> + .name   = "VP9 Encoded Stream",
> + .fourcc = V4L2_PIX_FMT_VP9,
> + .codec_mode = S5P_FIMV_CODEC_VP9_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.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> index 6478f70..565decf 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> @@ -170,6 +170,8 @@ struct s5p_mfc_regs {
>   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 */
> + void __iomem *d_static_buffer_addr; /* v10 */
> + void __iomem *d_static_buffer_size; /* v10 */
>  
>   /* encoder registers */
>   void __iomem *e_frame_width;
> 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 b6cb280..da4202f 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -227,6 +227,13 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>   ctx->scratch_buf_size +
>   (ctx->mv_count * ctx->mv_size);
>   break;
> + case S5P_MFC_CODEC_VP9_DEC:
> + mfc_debug(2, "Use min scratch buffer size\n");
> + ctx->scratch_buf_size = 

Re: [PATCH 06/11] [media] videodev2.h: Add v4l2 definition for HEVC

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add V4L2 definition for HEVC compressed format
>
> Signed-off-by: Smitha T Murthy 
Beside small nitpick.

Reviewed-by: Andrzej Hajda 

> ---
>  include/uapi/linux/videodev2.h |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 46e8a2e3..620e941 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -630,6 +630,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /* SMPTE 
> 421M Annex L compliant stream */
>  #define V4L2_PIX_FMT_VP8  v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
>  #define V4L2_PIX_FMT_VP9  v4l2_fourcc('V', 'P', '9', '0') /* VP9 */
> +#define V4L2_PIX_FMT_HEVC v4l2_fourcc('H', 'E', 'V', 'C') /* HEVC */

I am not sure if it shouldn't be sorted alphabetically in compressed
formats stanza.

--
Regards
Andrzej


>  
>  /*  Vendor-specific formats   */
>  #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */


--
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 04/11] [media] s5p-mfc: Support MFCv10.10 buffer requirements

[Andrzej Hajda]

Hi Smitha,

Ups, I have missed this patch, I hope it wont influence the review :)


On 18.01.2017 11:02, Smitha T Murthy wrote:
> Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> for MFCv10.10.
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |   13 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   97 
> ++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |2 +
>  3 files changed, 91 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index bd671a5..153ee68 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -32,5 +32,18 @@
>  #define MFC_VERSION_V10  0xA0
>  #define MFC_NUM_PORTS_V101
>  
> +/* Encoder buffer size for MFC v10.0 */
> +#define ENC_V100_H264_ME_SIZE(x, y)  \
> + (((x + 3) * (y + 3) * 8)\
> +  + x * y) + 63) / 64) * 32) \
> +  + (((y * 64) + 1280) * (x + 7) / 8))
> +#define ENC_V100_MPEG4_ME_SIZE(x, y) \
> + (((x + 3) * (y + 3) * 8)\
> +  + x * y) + 127) / 128) * 16)   \
> +  + (((y * 64) + 1280) * (x + 7) / 8))
> +#define ENC_V100_VP8_ME_SIZE(x, y)   \
> + (((x + 3) * (y + 3) * 8)\
> +  + (((y * 64) + 1280) * (x + 7) / 8))
> +

Crazy, cryptic math here, I guess you can make it more readable by using
DIV_ROUND_UP macro and abstracting out common parts, for example:

#define ENC_V100_BASE_SIZE(x, y) \
(((x + 3) * (y + 3) * 8) \
+  ((y * 64) + 1280) * DIV_ROUND_UP(x, 8))

#define ENC_V100_H264_ME_SIZE(x, y) \
(ENC_V100_BASE_SIZE(x, y)
+ DIV_ROUND_UP(x * y, 64) * 32)

#define ENC_V100_MPEG4_ME_SIZE(x, y) \
(ENC_V100_BASE_SIZE(x, y)
+ DIV_ROUND_UP(x * y, 128) * 16)

#define ENC_V100_VP8_ME_SIZE(x, y)  \
ENC_V100_BASE_SIZE(x, y)
 

>  #endif /*_REGS_MFC_V10_H*/
>  
> 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 faceee6..369210a 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -64,6 +64,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>  {
>   struct s5p_mfc_dev *dev = ctx->dev;
>   unsigned int mb_width, mb_height;
> + unsigned int lcu_width = 0, lcu_height = 0;
>   int ret;
>  
>   mb_width = MB_WIDTH(ctx->img_width);
> @@ -74,7 +75,9 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
> ctx->luma_size, ctx->chroma_size, ctx->mv_size);
>   mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
>   } else if (ctx->type == MFCINST_ENCODER) {
> - if (IS_MFCV8_PLUS(dev))
> + if (IS_MFCV10(dev)) {
> + ctx->tmv_buffer_size = 0;
> + } else if (IS_MFCV8_PLUS(dev))
>   ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
>   ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width, mb_height),
>   S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> @@ -82,13 +85,36 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>   ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
>   ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, mb_height),
>   S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> -
> - ctx->luma_dpb_size = ALIGN((mb_width * mb_height) *
> - S5P_FIMV_LUMA_MB_TO_PIXEL_V6,
> - S5P_FIMV_LUMA_DPB_BUFFER_ALIGN_V6);
> - ctx->chroma_dpb_size = ALIGN((mb_width * mb_height) *
> - S5P_FIMV_CHROMA_MB_TO_PIXEL_V6,
> - S5P_FIMV_CHROMA_DPB_BUFFER_ALIGN_V6);
> + if (IS_MFCV10(dev)) {
> + lcu_width = enc_lcu_width(ctx->img_width);
> + lcu_height = enc_lcu_height(ctx->img_height);
> + if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
> + ctx->luma_dpb_size =
> + ALIGNmb_width * 16) + 63) / 64)
> + * 64 * (((mb_height * 16) + 31)
> + / 32) * 32 + 64, 64);
> + ctx->chroma_dpb_size =
> + ALIGNmb_width * 16) + 63) / 64)
> + * 64 * (mb_height * 8)
> + + 64, 64);
> + } else {
> + ctx->luma_dpb_size =
> + ALIGNlcu_width * 32) + 63) / 64)
> + 

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

[Andrzej Hajda]

On 02.02.2017 08:58, Andrzej Hajda wrote:
> 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_V10   1
>>  
>> +/* 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_DEC6
>>  #define S5P_MFC_CODEC_VP8_DEC   7
>> +#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 
>>