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:   Sat Apr  1 05:00:17 CEST 2017
media-tree git hash:c3d4fb0fb41f4b5eafeee51173c14e50be12f839
media_build git hash:   bc4c2a205c087c8deff3cd14ed663c4767dd2016
v4l-utils git hash: 984caeac9a41f8d4f636b933dfba4f29c5257f96
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.9.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: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
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: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH] [media] vcodec: mediatek: Remove double parentheses

[Matthias Kaehlcke]

El Fri, Mar 17, 2017 at 02:01:33PM -0700 Matthias Kaehlcke ha dit:

> The extra pairs of parentheses are not needed and cause clang
> warnings like this:
> 
> drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:158:32: error: equality 
> comparison with extraneous parentheses [-Werror,-Wparentheses-equality]
> if ((inst->work_bufs[i].size == 0))
>  ^~~~
> drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:158:32: note: remove 
> extraneous parentheses around the comparison to silence this warning
> if ((inst->work_bufs[i].size == 0))
> ~^   ~
> drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:158:32: note: use '=' to 
> turn this equality comparison into an assignment
> if ((inst->work_bufs[i].size == 0))
>  ^~
>  =
> 
> Signed-off-by: Matthias Kaehlcke 
> ---
>  drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c 
> b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> index 544f57186243..129cc74b4fe4 100644
> --- a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> @@ -155,7 +155,7 @@ static void vp8_enc_free_work_buf(struct venc_vp8_inst 
> *inst)
>  
>   /* Buffers need to be freed by AP. */
>   for (i = 0; i < VENC_VP8_VPU_WORK_BUF_MAX; i++) {
> - if ((inst->work_bufs[i].size == 0))
> + if (inst->work_bufs[i].size == 0)
>   continue;
>   mtk_vcodec_mem_free(inst->ctx, >work_bufs[i]);
>   }
> @@ -172,7 +172,7 @@ static int vp8_enc_alloc_work_buf(struct venc_vp8_inst 
> *inst)
>   mtk_vcodec_debug_enter(inst);
>  
>   for (i = 0; i < VENC_VP8_VPU_WORK_BUF_MAX; i++) {
> - if ((wb[i].size == 0))
> + if (wb[i].size == 0)
>   continue;
>   /*
>* This 'wb' structure is set by VPU side and shared to AP for

Ping? Any feedback on this patch?

Cheers

Matthias

[PATCH] docs-rst: core_api: move driver-specific stuff to drivers_api

[Mauro Carvalho Chehab]

There are several stuff there that are actually driver-specific.

Move those to the driver_api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/core-api/kernel-api.rst  | 72 --
 Documentation/driver-api/firmware/index.rst|  1 +
 .../driver-api/firmware/other_interfaces.rst   | 15 +
 Documentation/driver-api/index.rst |  2 +
 Documentation/driver-api/misc_devices.rst  |  5 ++
 Documentation/driver-api/pci.rst   | 50 +++
 6 files changed, 73 insertions(+), 72 deletions(-)
 create mode 100644 Documentation/driver-api/firmware/other_interfaces.rst
 create mode 100644 Documentation/driver-api/misc_devices.rst
 create mode 100644 Documentation/driver-api/pci.rst

diff --git a/Documentation/core-api/kernel-api.rst 
b/Documentation/core-api/kernel-api.rst
index 9a3d3597a6b7..9ec8488319dc 100644
--- a/Documentation/core-api/kernel-api.rst
+++ b/Documentation/core-api/kernel-api.rst
@@ -228,72 +228,6 @@ MTRR Handling
 .. kernel-doc:: arch/x86/kernel/cpu/mtrr/main.c
:export:
 
-PCI Support Library

-
-.. kernel-doc:: drivers/pci/pci.c
-   :export:
-
-.. kernel-doc:: drivers/pci/pci-driver.c
-   :export:
-
-.. kernel-doc:: drivers/pci/remove.c
-   :export:
-
-.. kernel-doc:: drivers/pci/search.c
-   :export:
-
-.. kernel-doc:: drivers/pci/msi.c
-   :export:
-
-.. kernel-doc:: drivers/pci/bus.c
-   :export:
-
-.. kernel-doc:: drivers/pci/access.c
-   :export:
-
-.. kernel-doc:: drivers/pci/irq.c
-   :export:
-
-.. kernel-doc:: drivers/pci/htirq.c
-   :export:
-
-.. kernel-doc:: drivers/pci/probe.c
-   :export:
-
-.. kernel-doc:: drivers/pci/slot.c
-   :export:
-
-.. kernel-doc:: drivers/pci/rom.c
-   :export:
-
-.. kernel-doc:: drivers/pci/iov.c
-   :export:
-
-.. kernel-doc:: drivers/pci/pci-sysfs.c
-   :internal:
-
-PCI Hotplug Support Library

-
-.. kernel-doc:: drivers/pci/hotplug/pci_hotplug_core.c
-   :export:
-
-Firmware Interfaces
-===
-
-DMI Interfaces
---
-
-.. kernel-doc:: drivers/firmware/dmi_scan.c
-   :export:
-
-EDD Interfaces
---
-
-.. kernel-doc:: drivers/firmware/edd.c
-   :internal:
-
 Security Framework
 ==
 
@@ -372,12 +306,6 @@ Char devices
 .. kernel-doc:: fs/char_dev.c
:export:
 
-Miscellaneous Devices
-=
-
-.. kernel-doc:: drivers/char/misc.c
-   :export:
-
 Clock Framework
 ===
 
diff --git a/Documentation/driver-api/firmware/index.rst 
b/Documentation/driver-api/firmware/index.rst
index 1abe01793031..29da39ec4b8a 100644
--- a/Documentation/driver-api/firmware/index.rst
+++ b/Documentation/driver-api/firmware/index.rst
@@ -7,6 +7,7 @@ Linux Firmware API
introduction
core
request_firmware
+   other_interfaces
 
 .. only::  subproject and html
 
diff --git a/Documentation/driver-api/firmware/other_interfaces.rst 
b/Documentation/driver-api/firmware/other_interfaces.rst
new file mode 100644
index ..36c47b1e9824
--- /dev/null
+++ b/Documentation/driver-api/firmware/other_interfaces.rst
@@ -0,0 +1,15 @@
+Other Firmware Interfaces
+=
+
+DMI Interfaces
+--
+
+.. kernel-doc:: drivers/firmware/dmi_scan.c
+   :export:
+
+EDD Interfaces
+--
+
+.. kernel-doc:: drivers/firmware/edd.c
+   :internal:
+
diff --git a/Documentation/driver-api/index.rst 
b/Documentation/driver-api/index.rst
index 90e742577dfc..8058a87c1c74 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -27,6 +27,7 @@ available subsections can be seen below.
iio/index
input
usb/index
+   pci
spi
i2c
hsi
@@ -36,6 +37,7 @@ available subsections can be seen below.
80211/index
uio-howto
firmware/index
+   misc_devices
 
 .. only::  subproject and html
 
diff --git a/Documentation/driver-api/misc_devices.rst 
b/Documentation/driver-api/misc_devices.rst
new file mode 100644
index ..c7ee7b02ba88
--- /dev/null
+++ b/Documentation/driver-api/misc_devices.rst
@@ -0,0 +1,5 @@
+Miscellaneous Devices
+=
+
+.. kernel-doc:: drivers/char/misc.c
+   :export:
diff --git a/Documentation/driver-api/pci.rst b/Documentation/driver-api/pci.rst
new file mode 100644
index ..01a6c8b7d3a7
--- /dev/null
+++ b/Documentation/driver-api/pci.rst
@@ -0,0 +1,50 @@
+PCI Support Library
+---
+
+.. kernel-doc:: drivers/pci/pci.c
+   :export:
+
+.. kernel-doc:: drivers/pci/pci-driver.c
+   :export:
+
+.. kernel-doc:: drivers/pci/remove.c
+   :export:
+
+.. kernel-doc:: drivers/pci/search.c
+   :export:
+
+.. kernel-doc:: drivers/pci/msi.c
+   :export:
+
+.. kernel-doc:: drivers/pci/bus.c
+   :export:
+
+.. kernel-doc:: drivers/pci/access.c
+   :export:
+
+.. kernel-doc:: drivers/pci/irq.c
+   :export:
+
+.. kernel-doc:: drivers/pci/htirq.c
+   :export:
+
+.. kernel-doc:: drivers/pci/probe.c
+   

Re: [PATCHv6 01/10] media: add CEC notifier support

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 02:20:27PM +0200, Hans Verkuil wrote:
> +struct cec_notifier *cec_notifier_get(struct device *dev)
> +{
> + struct cec_notifier *n;
> +
> + mutex_lock(_notifiers_lock);
> + list_for_each_entry(n, _notifiers, head) {
> + if (n->dev == dev) {
> + mutex_unlock(_notifiers_lock);
> + kref_get(>kref);

Isn't this racy?  What stops one thread trying to get the notifier
while another thread puts the notifier?

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

Re: build_media compilation issues

[Nigel Terry]

Solved.

Between Centos 3.10.0-378.el7.x86_64 and 3.10.0-514.10.2.el7.x86_64,
the kernel patch to change wait_on_bit
https://github.com/torvalds/linux/commit/743162013d40ca612b4cb53d3a200dff2d9ab26e
was added to Centos7.

Thus the backport v3.16_wait_on_bit.patch is not required. Without
that, it builds just fine.

Nigel

On Thu, Mar 30, 2017 at 3:29 AM, Hans Verkuil  wrote:
> On 30/03/17 00:23, Nigel Terry wrote:
>> I'm trying to use build_media to build the media drivers, specifically
>> usb/em28xx, for Centos7. I'm getting compile errors, see below. Can
>> anyone help me?
>
> I'll try to take a look at this on Friday or Monday.
>
> Regards,
>
> Hans
>
>>
>> Kernel:
>> $ uname -a
>> Linux mythpbx.lan 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05
>> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Errors:
>> ...
>>   CC [M]  /home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.o
>> /home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c: In function
>> 'dvb_usb_start_feed':
>> /home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c:274:2: warning:
>> passing argument 3 of 'wait_on_bit' makes integer from pointer without
>> a cast [enabled by default]
>>   wait_on_bit(>state_bits, ADAP_INIT, wait_schedule,
>> TASK_UNINTERRUPTIBLE);
>>   ^
>> In file included from include/linux/kobject.h:27:0,
>>  from include/linux/device.h:17,
>>  from include/linux/input.h:22,
>>  from /home/mythtv/buildmedia/media_build/v4l/compat.h:10,
>>  from :0:
>> include/linux/wait.h:1044:1: note: expected 'unsigned int' but
>> argument is of type 'int (*)(void *)'
>>  wait_on_bit(void *word, int bit, unsigned mode)
>>  ^
>> /home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c:274:2: error:
>> too many arguments to function 'wait_on_bit'
>>   wait_on_bit(>state_bits, ADAP_INIT, wait_schedule,
>> TASK_UNINTERRUPTIBLE);
>>   ^
>> In file included from include/linux/kobject.h:27:0,
>>  from include/linux/device.h:17,
>>  from include/linux/input.h:22,
>>  from /home/mythtv/buildmedia/media_build/v4l/compat.h:10,
>>  from :0:
>> include/linux/wait.h:1044:1: note: declared here
>>  wait_on_bit(void *word, int bit, unsigned mode)
>>  ^
>> /home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c: In function
>> 'dvb_usb_fe_sleep':
>> /home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c:623:5: warning:
>> passing argument 3 of 'wait_on_bit' makes integer from pointer without
>> a cast [enabled by default]
>>  wait_schedule, TASK_UNINTERRUPTIBLE);
>>  ^
>> In file included from include/linux/kobject.h:27:0,
>>  from include/linux/device.h:17,
>>  from include/linux/input.h:22,
>>  from /home/mythtv/buildmedia/media_build/v4l/compat.h:10,
>>  from :0:
>> include/linux/wait.h:1044:1: note: expected 'unsigned int' but
>> argument is of type 'int (*)(void *)'
>>  wait_on_bit(void *word, int bit, unsigned mode)
>>  ^
>> /home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.c:623:5: error:
>> too many arguments to function 'wait_on_bit'
>>  wait_schedule, TASK_UNINTERRUPTIBLE);
>>  ^
>> In file included from include/linux/kobject.h:27:0,
>>  from include/linux/device.h:17,
>>  from include/linux/input.h:22,
>>  from /home/mythtv/buildmedia/media_build/v4l/compat.h:10,
>>  from :0:
>> include/linux/wait.h:1044:1: note: declared here
>>  wait_on_bit(void *word, int bit, unsigned mode)
>>  ^
>> make[3]: *** [/home/mythtv/buildmedia/media_build/v4l/dvb_usb_core.o] Error 1
>> make[2]: *** [_module_/home/mythtv/buildmedia/media_build/v4l] Error 2
>> make[2]: Leaving directory `/usr/src/kernels/3.10.0-514.10.2.el7.x86_64'
>> make[1]: *** [default] Error 2
>> make[1]: Leaving directory `/home/mythtv/buildmedia/media_build/v4l'
>> make: *** [all] Error 2
>> build failed at ./build line 491.
>>
>

Re: [PATCH 5/9] kernel-api.tmpl: convert it to ReST

[Mauro Carvalho Chehab]

Em Fri, 31 Mar 2017 09:05:37 -0600
Jonathan Corbet  escreveu:

> On Thu, 30 Mar 2017 17:11:32 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > Brainless conversion of genericirq.tmpl book to ReST, via
> > Documentation/sphinx/tmplcvt  
> 
> This one kind of showcases why I'm nervous about bulk conversions.  It's
> a bit of a dumping-ground document, with a bit of everything, and I think
> we can do better.  And, in particular, this one contains a bunch of stuff
> that belongs in the driver-api manual instead.  So, at a minimum, I would
> really like to see this template split across those two manuals.

Yeah, I was in doubt if it should be either at driver-api or core-api
manuals.

> If you promise me a followup patch doing that, maybe I can go ahead and
> merge this series now :)

Surely I can do a patch moving things around.

> (That's mildly complicated by the fact that you didn't send me parts 6,
> 8, and 9; I really would rather get the whole series in cases like this.)

Sorry. Just forwarded those missing parts to your e-mail.

They basically fix some kernel-doc headers that are not properly
parsed by Sphinx.

Thanks,
Mauro

Re: [PATCH 3/9] genericirq.tmpl: convert it to ReST

[Mauro Carvalho Chehab]

Em Fri, 31 Mar 2017 08:57:11 -0600
Jonathan Corbet  escreveu:

> On Thu, 30 Mar 2017 17:11:30 -0300
> Mauro Carvalho Chehab  wrote:
> 
> [Reordering things a bit]
> 
> > +==
> > +Linux generic IRQ handling
> > +==
> > +
> > +:Copyright: |copy| 2005-2010: Thomas Gleixner
> > +:Copyright: |copy| 2005-2006:  Ingo Molnar  
> 
> It seems maybe they should have been CC'd on this one?  Adding them now
> (and leaving the full patch for their amusement).
> 
> > Brainless conversion of genericirq.tmpl book to ReST, via
> > Documentation/sphinx/tmplcvt  
> 
> In general this seems good, but I have to wonder how current this material
> is at this point?  The last substantive change was in 2013 (3.11), and I've
> seen a certain amount of IRQ work going by since then.  I'm not opposed to
> this move at all, but perhaps if it's outdated we should add a note to that
> effect?

Looking on the amount of c:func: references that got solved:
http://www.infradead.org/~mchehab/kernel_docs/core-api/genericirq.html

I'd say that it doesn't seem outdated.

It mentions a __do_IRQ() function, with I was unable to found, but
I was able to find arch-dependent do_IRQ() functions, with seems to
match the concepts explained at the doc. I almost did a
s/__do_IRQ/do_IRQ/
but, as I wasn't 100% sure, I opted to keep it as-is for others to touch.

It also mentions a request_irq() function, with is there, just without
kernel-doc markups.

Finally, it includes several core-api files with kernel-doc markups.

So, IMHO, it is worth merging it. Yet, it would be great if the ones
working on that part of the core could review and update it.

Regards,
Mauro

Re: [PATCHv6 00/10] video/exynos/sti/cec: add CEC notifier & use in drivers

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 03:39:20PM +0100, Russell King - ARM Linux wrote:
> On Fri, Mar 31, 2017 at 02:20:26PM +0200, Hans Verkuil wrote:
> > Comments are welcome. I'd like to get this in for the 4.12 kernel as
> > this is a missing piece needed to integrate CEC drivers.
> 
> First two patches seem fine, and work with dw-hdmi.
> 
> I'll hold dw-hdmi off until after 4.11 - I currently have this stuff
> merged against 4.10, and there's some conflicts with 4.11.
> 
> I also wanted to say that tda998x/tda9950 works, and send you those
> patches, but while trying to test them this afternoon in a tree with
> some of the DRM code that was merged during the last merge window on
> a v4.10 based tree (which I need because of etnaviv), the kernel
> oopses in DRM for god-knows-why.  If/when I get this sorted (don't
> know when) I'll send that stuff as a follow-up to your series.

... and that's looking impossible - the next problem after that seems
to be that the rootfs drive for the box has failed, so I've currently
no way to test tda998x stuff until I get a new drive, filesystem and
so forth rebuilt.

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

Re: [PATCH] dma-buf: fence debugging

[Gustavo Padovan]

Hi Russell,

2017-03-31 Russell King :

> Add debugfs output to report shared and exclusive fences on a dma_buf
> object.  This produces output such as:
> 
> Dma-buf Objects:
> sizeflags   modecount   exp_name
> 0829440000050005drm
> Exclusive fence: etnaviv 134000.gpu signalled
> Attached Devices:
> gpu-subsystem
> Total 1 devices attached
> 
> 
> Total 1 objects, 8294400 bytes
> 
> 
> Signed-off-by: Russell King 
> ---
>  drivers/dma-buf/dma-buf.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletions(-)

Applied to to drm-misc-next.

> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 0007b792827b..f72aaacbe023 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1059,7 +1059,11 @@ static int dma_buf_debug_show(struct seq_file *s, void 
> *unused)
>   int ret;
>   struct dma_buf *buf_obj;
>   struct dma_buf_attachment *attach_obj;
> - int count = 0, attach_count;
> + struct reservation_object *robj;
> + struct reservation_object_list *fobj;
> + struct dma_fence *fence;
> + unsigned seq;

Our maintainer tools warned about this line, so I made it "unsigned
int"

Gustavo

Re: [PATCH 3/9] genericirq.tmpl: convert it to ReST

[Thomas Gleixner]

On Fri, 31 Mar 2017, Jonathan Corbet wrote:
> On Thu, 30 Mar 2017 17:11:30 -0300
> Mauro Carvalho Chehab  wrote:
> 
> [Reordering things a bit]
> 
> > +==
> > +Linux generic IRQ handling
> > +==
> > +
> > +:Copyright: |copy| 2005-2010: Thomas Gleixner
> > +:Copyright: |copy| 2005-2006:  Ingo Molnar
> 
> It seems maybe they should have been CC'd on this one?  Adding them now
> (and leaving the full patch for their amusement).
> 
> > Brainless conversion of genericirq.tmpl book to ReST, via
> > Documentation/sphinx/tmplcvt
> 
> In general this seems good, but I have to wonder how current this material
> is at this point?  The last substantive change was in 2013 (3.11), and I've
> seen a certain amount of IRQ work going by since then.  I'm not opposed to
> this move at all, but perhaps if it's outdated we should add a note to that
> effect?

We should take the opportunity and rewrite it proper. I might have an
intern available in the next couple of weeks, but I need to check with the
folks who are tasked to entertain him :)

Thanks,

tglx

Re: [PATCH 5/9] kernel-api.tmpl: convert it to ReST

[Jonathan Corbet]

On Thu, 30 Mar 2017 17:11:32 -0300
Mauro Carvalho Chehab  wrote:

> Brainless conversion of genericirq.tmpl book to ReST, via
>   Documentation/sphinx/tmplcvt

This one kind of showcases why I'm nervous about bulk conversions.  It's
a bit of a dumping-ground document, with a bit of everything, and I think
we can do better.  And, in particular, this one contains a bunch of stuff
that belongs in the driver-api manual instead.  So, at a minimum, I would
really like to see this template split across those two manuals.

If you promise me a followup patch doing that, maybe I can go ahead and
merge this series now :)

(That's mildly complicated by the fact that you didn't send me parts 6,
8, and 9; I really would rather get the whole series in cases like this.)

Thanks,

jon

Re: [PATCH 3/9] genericirq.tmpl: convert it to ReST

[Jonathan Corbet]

On Thu, 30 Mar 2017 17:11:30 -0300
Mauro Carvalho Chehab  wrote:

[Reordering things a bit]

> +==
> +Linux generic IRQ handling
> +==
> +
> +:Copyright: |copy| 2005-2010: Thomas Gleixner
> +:Copyright: |copy| 2005-2006:  Ingo Molnar

It seems maybe they should have been CC'd on this one?  Adding them now
(and leaving the full patch for their amusement).

> Brainless conversion of genericirq.tmpl book to ReST, via
>   Documentation/sphinx/tmplcvt

In general this seems good, but I have to wonder how current this material
is at this point?  The last substantive change was in 2013 (3.11), and I've
seen a certain amount of IRQ work going by since then.  I'm not opposed to
this move at all, but perhaps if it's outdated we should add a note to that
effect?

Thanks,

jon

> Copyright information inserted manually.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/DocBook/Makefile|   2 +-
>  Documentation/DocBook/genericirq.tmpl | 520 
> --
>  Documentation/core-api/genericirq.rst | 445 +
>  Documentation/core-api/index.rst  |   1 +
>  4 files changed, 447 insertions(+), 521 deletions(-)
>  delete mode 100644 Documentation/DocBook/genericirq.tmpl
>  create mode 100644 Documentation/core-api/genericirq.rst
> 
> diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
> index 7d94db2b53cd..e0c13655f770 100644
> --- a/Documentation/DocBook/Makefile
> +++ b/Documentation/DocBook/Makefile
> @@ -11,7 +11,7 @@ DOCBOOKS := z8530book.xml  \
>   networking.xml \
>   kernel-api.xml filesystems.xml lsm.xml kgdb.xml \
>   libata.xml mtdnand.xml librs.xml rapidio.xml \
> - genericirq.xml s390-drivers.xml scsi.xml \
> + s390-drivers.xml scsi.xml \
>   sh.xml w1.xml
>  
>  ifeq ($(DOCBOOKS),)
> diff --git a/Documentation/DocBook/genericirq.tmpl 
> b/Documentation/DocBook/genericirq.tmpl
> deleted file mode 100644
> index 59fb5c077541..
> --- a/Documentation/DocBook/genericirq.tmpl
> +++ /dev/null
> @@ -1,520 +0,0 @@
> -
> - - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd; []>
> -
> -
> - 
> -  Linux generic IRQ handling
> -
> -  
> -   
> -Thomas
> -Gleixner
> -
> - 
> -  t...@linutronix.de
> - 
> -
> -   
> -   
> -Ingo
> -Molnar
> -
> - 
> -  mi...@elte.hu
> - 
> -
> -   
> -  
> -
> -  
> -   2005-2010
> -   Thomas Gleixner
> -  
> -  
> -   2005-2006
> -   Ingo Molnar
> -  
> -
> -  
> -   
> - This documentation is free software; you can redistribute
> - it and/or modify it under the terms of the GNU General Public
> - License version 2 as published by the Free Software Foundation.
> -   
> -
> -   
> - This program is distributed in the hope that it will be
> - useful, but WITHOUT ANY WARRANTY; without even the implied
> - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> - See the GNU General Public License for more details.
> -   
> -
> -   
> - You should have received a copy of the GNU General Public
> - License along with this program; if not, write to the Free
> - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> - MA 02111-1307 USA
> -   
> -
> -   
> - For more details see the file COPYING in the source
> - distribution of Linux.
> -   
> -  
> - 
> -
> -
> -
> -  
> -Introduction
> -
> - The generic interrupt handling layer is designed to provide a
> - complete abstraction of interrupt handling for device drivers.
> - It is able to handle all the different types of interrupt controller
> - hardware. Device drivers use generic API functions to request, enable,
> - disable and free interrupts. The drivers do not have to know anything
> - about interrupt hardware details, so they can be used on different
> - platforms without code changes.
> -
> -
> - This documentation is provided to developers who want to implement
> - an interrupt subsystem based for their architecture, with the help
> - of the generic IRQ handling layer.
> -
> -  
> -
> -  
> -Rationale
> - 
> - The original implementation of interrupt handling in Linux uses
> - the __do_IRQ() super-handler, which is able to deal with every
> - type of interrupt logic.
> - 
> - 
> - Originally, Russell King identified different types of handlers to
> - build a quite universal set for the ARM interrupt handler
> - implementation in Linux 2.5/2.6. He distinguished between:
> - 
> -   Level type
> -   Edge type
> -   Simple type
> - 
> - During the implementation we identified another type:
> - 
> -   Fast EOI type
> - 
> - In the SMP world of the __do_IRQ() super-handler another type
> - was identified:

Re: [PATCH 02/22] docs-rst: convert usb docbooks to ReST

[Jonathan Corbet]

On Thu, 30 Mar 2017 11:20:14 +0200
Markus Heiser  wrote:

> @Jon: what do you think about a bulk conversion?

I'm a bit leery of it, to tell the truth.  We're trying to create a
better set of kernel docs, and I'm far from convinced that dumping a
bunch of unloved stuff there in a mechanical way will get us there.

Each of those docs needs to be looked at, and, first of all, we need to
decide whether it's worth keeping or not.  Nobody wants to delete docs,
but old and unmaintained stuff doesn't help our users, IMO.  For the
stuff we want to keep, we need to look at how it fits into the new
scheme, probably split it up, etc.

It's a lot slower, but we've been getting rid of 3-6 template files in
each of the last few cycles, so we are getting there.  I don't think we
need to just give up on the rest.

Thanks,

jon

Re: [PATCHv6 00/10] video/exynos/sti/cec: add CEC notifier & use in drivers

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 02:20:26PM +0200, Hans Verkuil wrote:
> Comments are welcome. I'd like to get this in for the 4.12 kernel as
> this is a missing piece needed to integrate CEC drivers.

First two patches seem fine, and work with dw-hdmi.

I'll hold dw-hdmi off until after 4.11 - I currently have this stuff
merged against 4.10, and there's some conflicts with 4.11.

I also wanted to say that tda998x/tda9950 works, and send you those
patches, but while trying to test them this afternoon in a tree with
some of the DRM code that was merged during the last merge window on
a v4.10 based tree (which I need because of etnaviv), the kernel
oopses in DRM for god-knows-why.  If/when I get this sorted (don't
know when) I'll send that stuff as a follow-up to your series.

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

[PATCH v5.1 1/6] drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function

[Neil Armstrong]

From: Laurent Pinchart 

In preparation for adding PHY operations to handle RX SENSE and HPD,
group all the PHY interrupt setup code in a single location and extract
it to a separate function.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
[narmstrong: renamed dw_hdmi_fb_registered to dw_hdmi_setup_i2c]
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 51 ++-
 1 file changed, 23 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 32f02e9..ff1fae3 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1558,8 +1558,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
return 0;
 }
 
-/* Wait until we are registered to enable interrupts */
-static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
+static void dw_hdmi_setup_i2c(struct dw_hdmi *hdmi)
 {
hdmi_writeb(hdmi, HDMI_PHY_I2CM_INT_ADDR_DONE_POL,
HDMI_PHY_I2CM_INT_ADDR);
@@ -1567,15 +1566,6 @@ static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
hdmi_writeb(hdmi, HDMI_PHY_I2CM_CTLINT_ADDR_NAC_POL |
HDMI_PHY_I2CM_CTLINT_ADDR_ARBITRATION_POL,
HDMI_PHY_I2CM_CTLINT_ADDR);
-
-   /* enable cable hot plug irq */
-   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-
-   /* Clear Hotplug interrupts */
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-
-   return 0;
 }
 
 static void initialize_hdmi_ih_mutes(struct dw_hdmi *hdmi)
@@ -1693,6 +1683,26 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
 }
 
+static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi)
+{
+   /*
+* Configure the PHY RX SENSE and HPD interrupts polarities and clear
+* any pending interrupt.
+*/
+   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+
+   /* Enable cable hot plug irq. */
+   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+
+   /* Clear and unmute interrupts. */
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
+   HDMI_IH_MUTE_PHY_STAT0);
+}
+
 static enum drm_connector_status
 dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
 {
@@ -2204,29 +2214,14 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
hdmi->ddc = NULL;
}
 
-   /*
-* Configure registers related to HDMI interrupt
-* generation before registering IRQ.
-*/
-   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
-
-   /* Clear Hotplug interrupts */
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-
hdmi->bridge.driver_private = hdmi;
hdmi->bridge.funcs = _hdmi_bridge_funcs;
 #ifdef CONFIG_OF
hdmi->bridge.of_node = pdev->dev.of_node;
 #endif
 
-   ret = dw_hdmi_fb_registered(hdmi);
-   if (ret)
-   goto err_iahb;
-
-   /* Unmute interrupts */
-   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
-   HDMI_IH_MUTE_PHY_STAT0);
+   dw_hdmi_setup_i2c(hdmi);
+   dw_hdmi_phy_setup_hpd(hdmi);
 
memset(, 0, sizeof(pdevinfo));
pdevinfo.parent = dev;
-- 
1.9.1

[PATCH v5.1 2/6] media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX Controller

[Neil Armstrong]

In order to describe the RGB and YUV bus formats used to feed the
Synopsys DesignWare HDMI TX Controller, add missing formats to the
list of Bus Formats.

Documentation for these formats is added in a separate patch.

Reviewed-by: Archit Taneja 
Reviewed-by: Jose Abreu 
Acked-by: Hans Verkuil 
Signed-off-by: Neil Armstrong 
---
 include/uapi/linux/media-bus-format.h | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 2168759..ef6fb30 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -33,7 +33,7 @@
 
 #define MEDIA_BUS_FMT_FIXED0x0001
 
-/* RGB - next is   0x1018 */
+/* RGB - next is   0x101b */
 #define MEDIA_BUS_FMT_RGB444_1X12  0x1016
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
@@ -57,8 +57,11 @@
 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA   0x1012
 #define MEDIA_BUS_FMT_ARGB_1X320x100d
 #define MEDIA_BUS_FMT_RGB888_1X32_PADHI0x100f
+#define MEDIA_BUS_FMT_RGB101010_1X30   0x1018
+#define MEDIA_BUS_FMT_RGB121212_1X36   0x1019
+#define MEDIA_BUS_FMT_RGB161616_1X48   0x101a
 
-/* YUV (including grey) - next is  0x2026 */
+/* YUV (including grey) - next is  0x202c */
 #define MEDIA_BUS_FMT_Y8_1X8   0x2001
 #define MEDIA_BUS_FMT_UV8_1X8  0x2015
 #define MEDIA_BUS_FMT_UYVY8_1_5X8  0x2002
@@ -90,12 +93,18 @@
 #define MEDIA_BUS_FMT_YVYU10_1X20  0x200e
 #define MEDIA_BUS_FMT_VUY8_1X240x2024
 #define MEDIA_BUS_FMT_YUV8_1X240x2025
+#define MEDIA_BUS_FMT_UYYVYY8_0_5X24   0x2026
 #define MEDIA_BUS_FMT_UYVY12_1X24  0x2020
 #define MEDIA_BUS_FMT_VYUY12_1X24  0x2021
 #define MEDIA_BUS_FMT_YUYV12_1X24  0x2022
 #define MEDIA_BUS_FMT_YVYU12_1X24  0x2023
 #define MEDIA_BUS_FMT_YUV10_1X30   0x2016
+#define MEDIA_BUS_FMT_UYYVYY10_0_5X30  0x2027
 #define MEDIA_BUS_FMT_AYUV8_1X32   0x2017
+#define MEDIA_BUS_FMT_UYYVYY12_0_5X36  0x2028
+#define MEDIA_BUS_FMT_YUV12_1X36   0x2029
+#define MEDIA_BUS_FMT_YUV16_1X48   0x202a
+#define MEDIA_BUS_FMT_UYYVYY16_0_5X48  0x202b
 
 /* Bayer - next is 0x3021 */
 #define MEDIA_BUS_FMT_SBGGR8_1X8   0x3001
-- 
1.9.1

[PATCH v5.1 0/6] drm: bridge: dw-hdmi: Add support for Custom PHYs

[Neil Armstrong]

The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
in combination with a very custom PHY.

Thanks to Laurent Pinchart's changes, the HW report the following :
 Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy)

The following differs from common PHY integration as managed in the current
driver :
 - Amlogic PHY is not configured through the internal I2C link
 - Amlogic PHY do not use the ENTMDS, SVSRET, PDDQ, ... signals from the 
controller
 - Amlogic PHY do not export HPD ands RxSense signals to the controller

And finally, concerning the controller integration :
 - the Controller registers are not flat memory-mapped, and uses an
addr+read/write register pair to write all registers.
 - Inputs only YUV444 pixel data

Most of these uses case are implemented in Laurent Pinchart v5.1 patchset merged
in drm-misc-next branch.

This is why the following patchset implements :
 - Configure the Input format from the plat_data
 - Add PHY callback to handle HPD and RxSense out of the dw-hdmi driver

To implement the input format handling, the Synopsys HDMIT TX Controller input
V4L bus formats are used and missing formats + documentation are added.

This patchset makes the Amlogic GX SoCs HDMI output successfully work, and is
also tested on the RK3288 ACT8846 EVB Board.

Changes since v5 at [6] :
 - Small addition in V4L YUV bus formats documentation

Changes since v4 at [5] :
 - Rebased on drm-misc-next at bd283d2f66c2
 - Fix 4:2:0 bus formats naming
 - Renamed function fd_registered to i2c_init in dw-hdmi.c

Changes since v3 at [4] :
 - Fix 4:2:0 bus formats naming
 - Add separate 36bit and 48bit tables for bus formats documentation
 - Added 4:2:0 bus config in hdmi_video_sample
 - Moved dw_hdmi documentation in a "bridge" subdir
 - Rebase on drm-misc-next at 62c58af32c93

Changes since v2 at [3] :
 - Rebase on laurent patch "Extract PHY interrupt setup to a function"
 - Reduce phy operations
 - Switch the V4L bus formats and encodings instead of custom enum

Changes since v1 at [2] :
 - Drop patches submitted by laurent

Changes since RFC at [1] :
 - Regmap fixup for 4bytes register access, tested on RK3288 SoC
 - Move phy callbacks to phy_ops and move Synopsys PHY calls into default ops
 - Move HDMI link data into shared header
 - Move Pixel Encoding enum to shared header

[1] 
http://lkml.kernel.org/r/1484656294-6140-1-git-send-email-narmstr...@baylibre.com
[2] 
http://lkml.kernel.org/r/1485774318-21916-1-git-send-email-narmstr...@baylibre.com
[3] 
http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com
[4] 
http://lkml.kernel.org/r/1488904944-14285-1-git-send-email-narmstr...@baylibre.com
[5] 
http://lkml.kernel.org/r/1490109161-20529-1-git-send-email-narmstr...@baylibre.com
[6] 
http://lkml.kernel.org/r/1490864675-17336-1-git-send-email-narmstr...@baylibre.com

Laurent Pinchart (1):
  drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function

Neil Armstrong (5):
  media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX
Controller
  documentation: media: Add documentation for new RGB and YUV bus
formats
  drm: bridge: dw-hdmi: Switch to V4L bus format and encodings
  drm: bridge: dw-hdmi: Add Documentation on supported input formats
  drm: bridge: dw-hdmi: Move HPD handling to PHY operations

 Documentation/gpu/bridge/dw-hdmi.rst|  15 +
 Documentation/gpu/index.rst |   1 +
 Documentation/media/uapi/v4l/subdev-formats.rst | 874 +++-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 470 -
 include/drm/bridge/dw_hdmi.h|  68 ++
 include/uapi/linux/media-bus-format.h   |  13 +-
 6 files changed, 1268 insertions(+), 173 deletions(-)
 create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst

-- 
1.9.1

[PATCH v5.1 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Neil Armstrong]

Some display pipelines can only provide non-RBG input pixels to the HDMI TX
Controller, this patch takes the pixel format from the plat_data if provided.

Reviewed-by: Jose Abreu 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 326 +-
 include/drm/bridge/dw_hdmi.h  |  63 ++
 2 files changed, 294 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ff1fae3..16d5fff3 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -30,18 +30,15 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include "dw-hdmi.h"
 #include "dw-hdmi-audio.h"
 
 #define DDC_SEGMENT_ADDR   0x30
 #define HDMI_EDID_LEN  512
 
-#define RGB0
-#define YCBCR444   1
-#define YCBCR422_16BITS2
-#define YCBCR422_8BITS 3
-#define XVYCC444   4
-
 enum hdmi_datamap {
RGB444_8B = 0x01,
RGB444_10B = 0x03,
@@ -95,10 +92,10 @@ struct hdmi_vmode {
 };
 
 struct hdmi_data_info {
-   unsigned int enc_in_format;
-   unsigned int enc_out_format;
-   unsigned int enc_color_depth;
-   unsigned int colorimetry;
+   unsigned int enc_in_bus_format;
+   unsigned int enc_out_bus_format;
+   unsigned int enc_in_encoding;
+   unsigned int enc_out_encoding;
unsigned int pix_repet_factor;
unsigned int hdcp_enable;
struct hdmi_vmode video_mode;
@@ -567,6 +564,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
 
+static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   case MEDIA_BUS_FMT_RGB101010_1X30:
+   case MEDIA_BUS_FMT_RGB121212_1X36:
+   case MEDIA_BUS_FMT_RGB161616_1X48:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_YUV8_1X24:
+   case MEDIA_BUS_FMT_YUV10_1X30:
+   case MEDIA_BUS_FMT_YUV12_1X36:
+   case MEDIA_BUS_FMT_YUV16_1X48:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYVY10_1X20:
+   case MEDIA_BUS_FMT_UYVY12_1X24:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
+   case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
+   case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
+   case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
+{
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   case MEDIA_BUS_FMT_YUV8_1X24:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
+   return 8;
+
+   case MEDIA_BUS_FMT_RGB101010_1X30:
+   case MEDIA_BUS_FMT_YUV10_1X30:
+   case MEDIA_BUS_FMT_UYVY10_1X20:
+   case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
+   return 10;
+
+   case MEDIA_BUS_FMT_RGB121212_1X36:
+   case MEDIA_BUS_FMT_YUV12_1X36:
+   case MEDIA_BUS_FMT_UYVY12_1X24:
+   case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
+   return 12;
+
+   case MEDIA_BUS_FMT_RGB161616_1X48:
+   case MEDIA_BUS_FMT_YUV16_1X48:
+   case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
+   return 16;
+
+   default:
+   return 0;
+   }
+}
+
 /*
  * this submodule is responsible for the video data synchronization.
  * for example, for RGB 4:4:4 input, the data map is defined as
@@ -579,37 +662,49 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
int color_format = 0;
u8 val;
 
-   if (hdmi->hdmi_data.enc_in_format == RGB) {
-   if (hdmi->hdmi_data.enc_color_depth == 8)
-   color_format = 0x01;
-   else if (hdmi->hdmi_data.enc_color_depth == 10)
-   color_format = 0x03;
-   else if (hdmi->hdmi_data.enc_color_depth == 12)
-   color_format = 0x05;
-   else if (hdmi->hdmi_data.enc_color_depth == 16)
-   color_format = 0x07;
-   else
-   return;
-   } else if (hdmi->hdmi_data.enc_in_format == YCBCR444) {
-   if (hdmi->hdmi_data.enc_color_depth == 8)
-   color_format = 0x09;
-   else if 

[PATCH v5.1 5/6] drm: bridge: dw-hdmi: Add Documentation on supported input formats

[Neil Armstrong]

This patch adds a new DRM documentation entry and links to the input
format table added in the dw_hdmi header.

Signed-off-by: Neil Armstrong 
---
 Documentation/gpu/bridge/dw-hdmi.rst | 15 +++
 Documentation/gpu/index.rst  |  1 +
 2 files changed, 16 insertions(+)
 create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst

diff --git a/Documentation/gpu/bridge/dw-hdmi.rst 
b/Documentation/gpu/bridge/dw-hdmi.rst
new file mode 100644
index 000..486faad
--- /dev/null
+++ b/Documentation/gpu/bridge/dw-hdmi.rst
@@ -0,0 +1,15 @@
+===
+ drm/bridge/dw-hdmi Synopsys DesignWare HDMI Controller
+===
+
+Synopsys DesignWare HDMI Controller
+===
+
+This section covers everything related to the Synopsys DesignWare HDMI
+Controller implemented as a DRM bridge.
+
+Supported Input Formats and Encodings
+-
+
+.. kernel-doc:: include/drm/bridge/dw_hdmi.h
+   :doc: Supported input formats and encodings
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index e998ee0..d81c6ff 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -15,6 +15,7 @@ Linux GPU Driver Developer's Guide
vc4
vga-switcheroo
vgaarbiter
+   bridge/dw-hdmi
todo
 
 .. only::  subproject and html
-- 
1.9.1

[PATCH v5.1 3/6] documentation: media: Add documentation for new RGB and YUV bus formats

[Neil Armstrong]

Add documentation for added Bus Formats to describe RGB and YUV formats used
as input to the Synopsys DesignWare HDMI TX Controller.

Acked-by: Hans Verkuil 
Signed-off-by: Neil Armstrong 
---
 Documentation/media/uapi/v4l/subdev-formats.rst | 874 +++-
 1 file changed, 859 insertions(+), 15 deletions(-)

diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index d6152c9..371f6eb 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -1258,6 +1258,281 @@ The following tables list existing packed RGB formats.
   - b\ :sub:`2`
   - b\ :sub:`1`
   - b\ :sub:`0`
+* .. _MEDIA-BUS-FMT-RGB101010-1X30:
+
+  - MEDIA_BUS_FMT_RGB101010_1X30
+  - 0x1018
+  -
+  - 0
+  - 0
+  - r\ :sub:`9`
+  - r\ :sub:`8`
+  - r\ :sub:`7`
+  - r\ :sub:`6`
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - g\ :sub:`9`
+  - g\ :sub:`8`
+  - g\ :sub:`7`
+  - g\ :sub:`6`
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - b\ :sub:`9`
+  - b\ :sub:`8`
+  - b\ :sub:`7`
+  - b\ :sub:`6`
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+
+.. raw:: latex
+
+\endgroup
+
+
+The following table list existing packed 36bit wide RGB formats.
+
+.. tabularcolumns:: 
|p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+.. _v4l2-mbus-pixelcode-rgb-36:
+
+.. raw:: latex
+
+\begingroup
+\tiny
+\setlength{\tabcolsep}{2pt}
+
+.. flat-table:: 36bit RGB formats
+:header-rows:  2
+:stub-columns: 0
+:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 
2 2 2 2 2 2 2
+
+* - Identifier
+  - Code
+  -
+  - :cspan:`35` Data organization
+* -
+  -
+  - Bit
+  - 35
+  - 34
+  - 33
+  - 32
+  - 31
+  - 30
+  - 29
+  - 28
+  - 27
+  - 26
+  - 25
+  - 24
+  - 23
+  - 22
+  - 21
+  - 20
+  - 19
+  - 18
+  - 17
+  - 16
+  - 15
+  - 14
+  - 13
+  - 12
+  - 11
+  - 10
+  - 9
+  - 8
+  - 7
+  - 6
+  - 5
+  - 4
+  - 3
+  - 2
+  - 1
+  - 0
+* .. _MEDIA-BUS-FMT-RGB121212-1X36:
+
+  - MEDIA_BUS_FMT_RGB121212_1X36
+  - 0x1019
+  -
+  - r\ :sub:`11`
+  - r\ :sub:`10`
+  - r\ :sub:`9`
+  - r\ :sub:`8`
+  - r\ :sub:`7`
+  - r\ :sub:`6`
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - g\ :sub:`11`
+  - g\ :sub:`10`
+  - g\ :sub:`9`
+  - g\ :sub:`8`
+  - g\ :sub:`7`
+  - g\ :sub:`6`
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - b\ :sub:`11`
+  - b\ :sub:`10`
+  - b\ :sub:`9`
+  - b\ :sub:`8`
+  - b\ :sub:`7`
+  - b\ :sub:`6`
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+
+.. raw:: latex
+
+\endgroup
+
+
+The following table list existing packed 48bit wide RGB formats.
+
+.. tabularcolumns:: 
|p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+.. _v4l2-mbus-pixelcode-rgb-48:
+
+.. raw:: latex
+
+\begingroup
+\tiny
+\setlength{\tabcolsep}{2pt}
+
+.. flat-table:: 48bit RGB formats
+:header-rows:  2
+:stub-columns: 0
+:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
+
+* - Identifier
+  - Code
+  -
+  - :cspan:`47` Data organization
+* -
+  -
+  - Bit
+  - 47
+  - 46
+  - 45
+  - 44
+  - 43
+  - 42
+  - 41
+  - 40
+  - 39
+  - 38
+  - 37
+  - 36
+  - 35
+  - 34
+  - 33
+  - 

[PATCH v5.1 6/6] drm: bridge: dw-hdmi: Move HPD handling to PHY operations

[Neil Armstrong]

The HDMI TX controller support HPD and RXSENSE signaling from the PHY
via it's STAT0 PHY interface, but some vendor PHYs can manage these
signals independently from the controller, thus these STAT0 handling
should be moved to PHY specific operations and become optional.

The existing STAT0 HPD and RXSENSE handling code is refactored into
a supplementaty set of default PHY operations that are used automatically
when the platform glue doesn't provide its own operations.

Reviewed-by: Jose Abreu 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 135 ++
 include/drm/bridge/dw_hdmi.h  |   5 ++
 2 files changed, 86 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 16d5fff3..84cc949 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1229,10 +1229,46 @@ static enum drm_connector_status 
dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
connector_status_connected : connector_status_disconnected;
 }
 
+static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+  bool force, bool disabled, bool rxsense)
+{
+   u8 old_mask = hdmi->phy_mask;
+
+   if (force || disabled || !rxsense)
+   hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
+   else
+   hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
+
+   if (old_mask != hdmi->phy_mask)
+   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+}
+
+static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+{
+   /*
+* Configure the PHY RX SENSE and HPD interrupts polarities and clear
+* any pending interrupt.
+*/
+   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+
+   /* Enable cable hot plug irq. */
+   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+
+   /* Clear and unmute interrupts. */
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
+   HDMI_IH_MUTE_PHY_STAT0);
+}
+
 static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
.init = dw_hdmi_phy_init,
.disable = dw_hdmi_phy_disable,
.read_hpd = dw_hdmi_phy_read_hpd,
+   .update_hpd = dw_hdmi_phy_update_hpd,
+   .setup_hpd = dw_hdmi_phy_setup_hpd,
 };
 
 /* 
-
@@ -1808,35 +1844,10 @@ static void dw_hdmi_update_power(struct dw_hdmi *hdmi)
  */
 static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
 {
-   u8 old_mask = hdmi->phy_mask;
-
-   if (hdmi->force || hdmi->disabled || !hdmi->rxsense)
-   hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
-   else
-   hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
-
-   if (old_mask != hdmi->phy_mask)
-   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-}
-
-static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi)
-{
-   /*
-* Configure the PHY RX SENSE and HPD interrupts polarities and clear
-* any pending interrupt.
-*/
-   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-
-   /* Enable cable hot plug irq. */
-   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-
-   /* Clear and unmute interrupts. */
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
-   HDMI_IH_MUTE_PHY_STAT0);
+   if (hdmi->phy.ops->update_hpd)
+   hdmi->phy.ops->update_hpd(hdmi, hdmi->phy.data,
+ hdmi->force, hdmi->disabled,
+ hdmi->rxsense);
 }
 
 static enum drm_connector_status
@@ -2028,6 +2039,41 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
return ret;
 }
 
+void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
+{
+   mutex_lock(>mutex);
+
+   if (!hdmi->force) {
+   /*
+* If the RX sense status indicates we're disconnected,
+* clear the software rxsense status.
+*/
+   if (!rx_sense)
+   hdmi->rxsense = false;
+
+   /*
+* Only set the software rxsense status when both
+* rxsense and hpd indicates we're connected.
+* This avoids 

Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned

[Alan Stern]

On Thu, 30 Mar 2017, Oliver Neukum wrote:

> Am Donnerstag, den 30.03.2017, 11:55 -0400 schrieb Alan Stern:
> > 
> > I'm pretty sure that usb-storage does not do this, at least, not when 
> > operating in its normal Bulk-Only-Transport mode.  It never tries to 
> > read the results of an earlier transfer after carrying out a later 
> > transfer to any part of the same buffer.
> 
> The storage driver takes buffers as the block layer (or sg) provide
> them, does it not?

Yes.  But it does not read the data from an earlier transfer after 
carrying out a later transfer on the same buffer.

The only possible example would be if the sense buffer for a command 
occupied part of the same block as the data buffer.  But this can't 
happen, because the sense buffer is allocated separately by its own 
kzalloc_node() call in scsi_init_request().

Alan Stern

Dear user

[Postgrado de Odontología]

-- 
Dear user

Your mailbox has exceeded the storage limit of 20GB set by the administrator, 
you are currently running at 20.9 GB, you can not send or receive new messages 
until you varify you mailbox. Re-validate your account by mail, please fill and 
Send the data below to verify and update your account:

(1) email:
(2) Name:
(3) password:
(4) electronic mail:

thank you
system administrator

Re: [PATCH v5 3/6] documentation: media: Add documentation for new RGB and YUV bus formats

[Neil Armstrong]

On 03/31/2017 03:14 PM, Hans Verkuil wrote:
> On 30/03/17 11:04, Neil Armstrong wrote:
>> Add documentation for added Bus Formats to describe RGB and YUV formats used
>> as input to the Synopsys DesignWare HDMI TX Controller.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  Documentation/media/uapi/v4l/subdev-formats.rst | 871 
>> +++-
>>  1 file changed, 857 insertions(+), 14 deletions(-)
> 
> This looks good, but the "Packed YUV Formats" documentation should be updated.
> 
> Currently this says:
> 
> -  The number of bus samples per pixel. Pixels that are wider than the
>bus width must be transferred in multiple samples. Common values are
>1, 1.5 (encoded as 1_5) and 2.
> 
> I propose this change:
> 
> -  The number of bus samples per pixel. Pixels that are wider than the
>bus width must be transferred in multiple samples. Common values are
>0.5 (encoded as 0_5; in this case two pixels are transferred per bus
>sample), 1, 1.5 (encoded as 1_5) and 2.
> 
> With that additional change you can add my:
> 
> Acked-by: Hans Verkuil 
> 
> Regards,
> 
>   Hans
> 

Hi Hans,

Thanks for the hint, I will change this and post a v5.1 with your acks.

Neil

[PATCH 2/2] [media] tvp5150: fix pad format frame height

[Philipp Zabel]

Even if field order is set to V4L2_FIELD_ALTERNATE, the width and height
values in struct v4l2_mbus_framefmt still refer to frame size, not field
size.

Fixes: 4f57d27be2a5 ("[media] tvp5150: fix tvp5150_fill_fmt()")
Signed-off-by: Philipp Zabel 
---
 drivers/media/i2c/tvp5150.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 9390662453b0f..b05a578aef983 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -876,7 +876,7 @@ static int tvp5150_fill_fmt(struct v4l2_subdev *sd,
f = >format;
 
f->width = decoder->rect.width;
-   f->height = decoder->rect.height / 2;
+   f->height = decoder->rect.height;
 
f->code = MEDIA_BUS_FMT_UYVY8_2X8;
f->field = V4L2_FIELD_ALTERNATE;
-- 
2.11.0

[PATCH 1/2] [media] tvp5150: allow get/set_fmt on the video source pad

[Philipp Zabel]

To let userspace propagate formats downstream in a media controller
scenario, the video source pad (now pad 1, DEMOD_PAD_VID_OUT) must allow
setting and getting the format. Incidentally, tvp5150_fill_fmt was
implemented for this pad, not for the new analog input pad (now pad 0,
DEMOD_PAD_IF_INPUT).

Fixes: 55606310e77f ("[media] tvp5150: create the expected number of pads")
Signed-off-by: Philipp Zabel 
---
 drivers/media/i2c/tvp5150.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index d8487d97617ec..9390662453b0f 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -870,7 +870,7 @@ static int tvp5150_fill_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *f;
struct tvp5150 *decoder = to_tvp5150(sd);
 
-   if (!format || format->pad)
+   if (!format || (format->pad != DEMOD_PAD_VID_OUT))
return -EINVAL;
 
f = >format;
-- 
2.11.0

Re: [Patch v3 00/11] Add MFC v10.10 support

[Andrzej Hajda]

Hi Smitha,

On 31.03.2017 11:06, Smitha T Murthy wrote:
> This patch series adds MFC v10.10 support. MFC v10.10 is used in some
> of Exynos7 variants.

Patch does not apply, please rebase on top of:
   

git://linuxtv.org/snawrocki/samsung.git for-v4.12/media/next


Additionally quick test shows you do not handle 
V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_CH in s5p_mfc_enc_s_ctrl.

Regards
Andrzej

>
> This adds support for following:
>
> * Add support for HEVC encoder and decoder
> * Add support for VP9 decoder
> * Update Documentation for control id definitions
> * Update computation of min scratch buffer size requirement for V8 onwards
>
> Changes since v2:
>  - Addressed review comments by Andrzej Hajda.
>  - Rebased on latest krzk/for-next tree.
>  - This patches are tested on top of Marek's patch v2 [1]
>  - Applied acked-by and r-o-b from Andrzej on respective patches.
>  - Applied acked-by from Rob Herring on respective patch.
>
> [1]: http://www.mail-archive.com/linux-media@vger.kernel.org/msg108520.html
>
> Smitha T Murthy (11):
>   [media] s5p-mfc: Rename IS_MFCV8 macro
>   [media] s5p-mfc: Adding initial support for MFC v10.10
>   [media] s5p-mfc: Use min scratch buffer size as provided by F/W
>   [media] s5p-mfc: Support MFCv10.10 buffer requirements
>   [media] videodev2.h: Add v4l2 definition for HEVC
>   [media] s5p-mfc: Add support for HEVC decoder
>   Documentation: v4l: Documentation for HEVC v4l2 definition
>   [media] s5p-mfc: Add VP9 decoder support
>   [media] v4l2: Add v4l2 control IDs for HEVC encoder
>   [media] s5p-mfc: Add support for HEVC encoder
>   Documention: v4l: Documentation for HEVC CIDs
>
>  .../devicetree/bindings/media/s5p-mfc.txt  |   1 +
>  Documentation/media/uapi/v4l/extended-controls.rst | 355 
>  Documentation/media/uapi/v4l/pixfmt-013.rst|   5 +
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h  |  88 +++
>  drivers/media/platform/s5p-mfc/regs-mfc-v8.h   |   2 +
>  drivers/media/platform/s5p-mfc/s5p_mfc.c   |  33 ++
>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c|   9 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h|  71 ++-
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |   6 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |  50 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   | 616 
> -
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h   |  14 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c| 410 --
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|  15 +
>  drivers/media/v4l2-core/v4l2-ctrls.c   | 103 
>  include/uapi/linux/v4l2-controls.h | 133 +
>  include/uapi/linux/videodev2.h |   1 +
>  17 files changed, 1835 insertions(+), 77 deletions(-)
>  create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>

Re: [PATCH v5 3/6] documentation: media: Add documentation for new RGB and YUV bus formats

[Hans Verkuil]

On 30/03/17 11:04, Neil Armstrong wrote:
> Add documentation for added Bus Formats to describe RGB and YUV formats used
> as input to the Synopsys DesignWare HDMI TX Controller.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  Documentation/media/uapi/v4l/subdev-formats.rst | 871 
> +++-
>  1 file changed, 857 insertions(+), 14 deletions(-)

This looks good, but the "Packed YUV Formats" documentation should be updated.

Currently this says:

-  The number of bus samples per pixel. Pixels that are wider than the
   bus width must be transferred in multiple samples. Common values are
   1, 1.5 (encoded as 1_5) and 2.

I propose this change:

-  The number of bus samples per pixel. Pixels that are wider than the
   bus width must be transferred in multiple samples. Common values are
   0.5 (encoded as 0_5; in this case two pixels are transferred per bus
   sample), 1, 1.5 (encoded as 1_5) and 2.

With that additional change you can add my:

Acked-by: Hans Verkuil 

Regards,

Hans

Re: [PATCH v5 2/6] media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX Controller

[Hans Verkuil]

On 30/03/17 11:04, Neil Armstrong wrote:
> In order to describe the RGB and YUV bus formats used to feed the
> Synopsys DesignWare HDMI TX Controller, add missing formats to the
> list of Bus Formats.
> 
> Documentation for these formats is added in a separate patch.
> 
> Reviewed-by: Archit Taneja 
> Reviewed-by: Jose Abreu 
> Signed-off-by: Neil Armstrong 

Acked-by: Hans Verkuil 

Thanks!

Hans

> ---
>  include/uapi/linux/media-bus-format.h | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/include/uapi/linux/media-bus-format.h 
> b/include/uapi/linux/media-bus-format.h
> index 2168759..ef6fb30 100644
> --- a/include/uapi/linux/media-bus-format.h
> +++ b/include/uapi/linux/media-bus-format.h
> @@ -33,7 +33,7 @@
>  
>  #define MEDIA_BUS_FMT_FIXED  0x0001
>  
> -/* RGB - next is 0x1018 */
> +/* RGB - next is 0x101b */
>  #define MEDIA_BUS_FMT_RGB444_1X120x1016
>  #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001
>  #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002
> @@ -57,8 +57,11 @@
>  #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012
>  #define MEDIA_BUS_FMT_ARGB_1X32  0x100d
>  #define MEDIA_BUS_FMT_RGB888_1X32_PADHI  0x100f
> +#define MEDIA_BUS_FMT_RGB101010_1X30 0x1018
> +#define MEDIA_BUS_FMT_RGB121212_1X36 0x1019
> +#define MEDIA_BUS_FMT_RGB161616_1X48 0x101a
>  
> -/* YUV (including grey) - next is0x2026 */
> +/* YUV (including grey) - next is0x202c */
>  #define MEDIA_BUS_FMT_Y8_1X8 0x2001
>  #define MEDIA_BUS_FMT_UV8_1X80x2015
>  #define MEDIA_BUS_FMT_UYVY8_1_5X80x2002
> @@ -90,12 +93,18 @@
>  #define MEDIA_BUS_FMT_YVYU10_1X200x200e
>  #define MEDIA_BUS_FMT_VUY8_1X24  0x2024
>  #define MEDIA_BUS_FMT_YUV8_1X24  0x2025
> +#define MEDIA_BUS_FMT_UYYVYY8_0_5X24 0x2026
>  #define MEDIA_BUS_FMT_UYVY12_1X240x2020
>  #define MEDIA_BUS_FMT_VYUY12_1X240x2021
>  #define MEDIA_BUS_FMT_YUYV12_1X240x2022
>  #define MEDIA_BUS_FMT_YVYU12_1X240x2023
>  #define MEDIA_BUS_FMT_YUV10_1X30 0x2016
> +#define MEDIA_BUS_FMT_UYYVYY10_0_5X300x2027
>  #define MEDIA_BUS_FMT_AYUV8_1X32 0x2017
> +#define MEDIA_BUS_FMT_UYYVYY12_0_5X360x2028
> +#define MEDIA_BUS_FMT_YUV12_1X36 0x2029
> +#define MEDIA_BUS_FMT_YUV16_1X48 0x202a
> +#define MEDIA_BUS_FMT_UYYVYY16_0_5X480x202b
>  
>  /* Bayer - next is   0x3021 */
>  #define MEDIA_BUS_FMT_SBGGR8_1X8 0x3001
> 

Re: [PATCH] [media] docs-rst: clarify field vs frame height in the subdev API

[Hans Verkuil]

On 31/03/17 14:24, Philipp Zabel wrote:
> On Fri, 2017-03-31 at 13:08 +0200, Hans Verkuil wrote:
> [...]
>  Applications are responsible for configuring coherent parameters on the
>  whole pipeline and making sure that connected pads have compatible
> @@ -379,7 +382,10 @@ is supported by the hardware.
> pad for further processing.
>
>  2. Sink pad actual crop selection. The sink pad crop defines the crop
> -   performed to the sink pad format.
> +   performed to the sink pad format. The crop rectangle always refers to
> +   the frame size, even if the sink pad format has field order set to
> +   ``V4L2_FIELD_ALTERNATE`` and the actual processed images are only
> +   field sized.

 I'm not sure to agree with this. I think all selection rectangle 
 coordinates 
 should be expressed relative to the format of the pad they refer to.
>>>
>>> But that's not how I understood Hans yesterday, and it shows that you
>>> were quite on point with your suggestion to extend the docs.
>>
>> Actually, it is a bit different from what I said yesterday. Sorry about that.
>>
>> Whether the top and height fields in struct v4l2_rect are for fields or
>> frames depends on whether it describes memory or video. Historically
>> VIDIOC_CROPCAP and VIDIOC_G/S_CROP used frame coordinates for video
>> capture (crop rectangle) and video output (compose rectangle, i.e. what is
>> composed into the video transmitter).
> 
> Ok.
> 
>> When the selection API was added we could also describe how video is
>> composed into a memory buffer (for capture) or cropped from a memory buffer
>> (for output). Since this deals with memory the v4l2_rect struct contains
>> field coordinates, for the same reason that G/S/TRY_FMT does.
> 
> Ok. This would not apply to subdevices that only handle video streams,
> so that would mean that the v4l2_mbus_framefmt passed to
> VIDIOC_SUBDEV_G/S_FMT also should always contain the frame size, never
> the field size.
> 
>> The vivid driver *should* do all of this correctly. Since this driver
>> supports any combination of cropping/composing/scaler features it gets
>> quite complicated, so it is always possible that there are bugs, but I
>> did a lot of testing at the time.
> 
> I haven't played much with vivid in this regard yet, I've only looked at
> the capture device, and that behaved as I expected after your
> explanation.
> 
 For sink pad crop rectangles, if the sink pad receives alternate (or
 top or bottom only) fields, the rectangle coordinates should be
 relative to the field size. Similarly, if the source pad produces
 alternate/top/bottom fields, the rectangle coordinates should also be
 relative to the field size.
>>>
>>> That's also not how TVP5150 currently implements it. The crop rectangle
>>> is frame sized even though the pad format reports alternating fields,
>>
>> It is undefined today what the subdev selection rectangles should use.
>> I am inclined to *always* use frame coordinates while dealing with hardware
>> (receivers, transmitters, busses) and only use field coordinates when dealing
>> with actual memory buffers.
>>
>> This will avoid having to change any subdev drivers as well, which is a nice
>> bonus. It also is consistent with the way the original API was designed:
>> frame coordinates everywhere, except when dealing with buffers in memory.
> 
> Ok, I'll revise this patch accordingly.
> 
>> For the record: the DV_TIMINGS ioctls also define the height as frame height,
>> not field height. And the height in struct v4l2_mbus_framefmt is also defined
>> as a frame height.
> 
> The v4l2_mbus_framefmt height is defined as "image height", and it
> wasn't clear to me what image meant in this context.

I looked at the header: include/uapi/linux/v4l2-mediabus.h.

There it says "frame height".

> 
>>> the same is true for vivid capture, even though that is not using the
>>> subdev selection API.
>>
>> ??? vivid uses frame height for crop coordinates when FIELD_ALTERNATE is
>> selected. Where did you see a field height when using vivid?
> 
> That's what I meant with "the same": "The crop rectangle is frame sized
> even though the [pad^W] format reports alternating fields".
> 
>> Note: by default vivid implements a scaler and composer. So switching to
>> field_alternate would still show a height of 576.
>>
>> After disabling the scaler and composer:
>>
>> v4l2-ctl -c enable_capture_scaler=0
>> v4l2-ctl -c enable_capture_composing=0
>>
>> it will now be 288.
> 
> So in this case the field size is used because S/G_FMT refer to memory.

Right.

> 
> [...]
>>> Actually, this is exactly the case I want to handle. The CSI receives
>>> FIELD_ALTERNATE frames from the TVP5150 with BT.656 synchronisation, but
>>> it produces SEQ_TB or SEQ_BT (depending on standard) at its output pad.
>>> If the input pad height is 288 lines for example, the output pad height
>>> is 576 lines (in case of no cropping or scaling), and there's a 

Re: [PATCH] [media] docs-rst: clarify field vs frame height in the subdev API

[Philipp Zabel]

On Fri, 2017-03-31 at 13:08 +0200, Hans Verkuil wrote:
[...]
> >>>  Applications are responsible for configuring coherent parameters on the
> >>>  whole pipeline and making sure that connected pads have compatible
> >>> @@ -379,7 +382,10 @@ is supported by the hardware.
> >>> pad for further processing.
> >>>
> >>>  2. Sink pad actual crop selection. The sink pad crop defines the crop
> >>> -   performed to the sink pad format.
> >>> +   performed to the sink pad format. The crop rectangle always refers to
> >>> +   the frame size, even if the sink pad format has field order set to
> >>> +   ``V4L2_FIELD_ALTERNATE`` and the actual processed images are only
> >>> +   field sized.
> >>
> >> I'm not sure to agree with this. I think all selection rectangle 
> >> coordinates 
> >> should be expressed relative to the format of the pad they refer to.
> > 
> > But that's not how I understood Hans yesterday, and it shows that you
> > were quite on point with your suggestion to extend the docs.
> 
> Actually, it is a bit different from what I said yesterday. Sorry about that.
> 
> Whether the top and height fields in struct v4l2_rect are for fields or
> frames depends on whether it describes memory or video. Historically
> VIDIOC_CROPCAP and VIDIOC_G/S_CROP used frame coordinates for video
> capture (crop rectangle) and video output (compose rectangle, i.e. what is
> composed into the video transmitter).

Ok.

> When the selection API was added we could also describe how video is
> composed into a memory buffer (for capture) or cropped from a memory buffer
> (for output). Since this deals with memory the v4l2_rect struct contains
> field coordinates, for the same reason that G/S/TRY_FMT does.

Ok. This would not apply to subdevices that only handle video streams,
so that would mean that the v4l2_mbus_framefmt passed to
VIDIOC_SUBDEV_G/S_FMT also should always contain the frame size, never
the field size.

> The vivid driver *should* do all of this correctly. Since this driver
> supports any combination of cropping/composing/scaler features it gets
> quite complicated, so it is always possible that there are bugs, but I
> did a lot of testing at the time.

I haven't played much with vivid in this regard yet, I've only looked at
the capture device, and that behaved as I expected after your
explanation.

> >> For sink pad crop rectangles, if the sink pad receives alternate (or
> >> top or bottom only) fields, the rectangle coordinates should be
> >> relative to the field size. Similarly, if the source pad produces
> >> alternate/top/bottom fields, the rectangle coordinates should also be
> >> relative to the field size.
> > 
> > That's also not how TVP5150 currently implements it. The crop rectangle
> > is frame sized even though the pad format reports alternating fields,
> 
> It is undefined today what the subdev selection rectangles should use.
> I am inclined to *always* use frame coordinates while dealing with hardware
> (receivers, transmitters, busses) and only use field coordinates when dealing
> with actual memory buffers.
>
> This will avoid having to change any subdev drivers as well, which is a nice
> bonus. It also is consistent with the way the original API was designed:
> frame coordinates everywhere, except when dealing with buffers in memory.

Ok, I'll revise this patch accordingly.

> For the record: the DV_TIMINGS ioctls also define the height as frame height,
> not field height. And the height in struct v4l2_mbus_framefmt is also defined
> as a frame height.

The v4l2_mbus_framefmt height is defined as "image height", and it
wasn't clear to me what image meant in this context.

> > the same is true for vivid capture, even though that is not using the
> > subdev selection API.
> 
> ??? vivid uses frame height for crop coordinates when FIELD_ALTERNATE is
> selected. Where did you see a field height when using vivid?

That's what I meant with "the same": "The crop rectangle is frame sized
even though the [pad^W] format reports alternating fields".

> Note: by default vivid implements a scaler and composer. So switching to
> field_alternate would still show a height of 576.
>
> After disabling the scaler and composer:
> 
> v4l2-ctl -c enable_capture_scaler=0
> v4l2-ctl -c enable_capture_composing=0
> 
> it will now be 288.

So in this case the field size is used because S/G_FMT refer to memory.

[...]
> > Actually, this is exactly the case I want to handle. The CSI receives
> > FIELD_ALTERNATE frames from the TVP5150 with BT.656 synchronisation, but
> > it produces SEQ_TB or SEQ_BT (depending on standard) at its output pad.
> > If the input pad height is 288 lines for example, the output pad height
> > is 576 lines (in case of no cropping or scaling), and there's a sink
> > crop and a sink compose rectangle. Should those refer to the 288 lines
> > per field, or to the 576 lines per frame?
> 
> The output pad of the tvp5150 would say FIELD_ALTERNATE and height 576.

Aha, this didn't occur to me at 

[PATCHv6 05/10] s5p-cec.txt: document the HDMI controller phandle

[Hans Verkuil]

From: Hans Verkuil 

Update the bindings documenting the new hdmi phandle.

Signed-off-by: Hans Verkuil 
Acked-by: Krzysztof Kozlowski 
CC: linux-samsung-...@vger.kernel.org
CC: devicet...@vger.kernel.org
---
 Documentation/devicetree/bindings/media/s5p-cec.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
b/Documentation/devicetree/bindings/media/s5p-cec.txt
index 925ab4d72eaa..4bb08d9d940b 100644
--- a/Documentation/devicetree/bindings/media/s5p-cec.txt
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -15,6 +15,7 @@ Required properties:
   - clock-names : from common clock binding: must contain "hdmicec",
  corresponding to entry in the clocks property.
   - samsung,syscon-phandle - phandle to the PMU system controller
+  - hdmi-phandle - phandle to the HDMI controller
 
 Example:
 
@@ -25,6 +26,7 @@ hdmicec: cec@100B {
clocks = < CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <_system_controller>;
+   hdmi-phandle = <>;
pinctrl-names = "default";
pinctrl-0 = <_cec>;
status = "okay";
-- 
2.11.0

[PATCHv6 01/10] media: add CEC notifier support

[Hans Verkuil]

From: Hans Verkuil 

Add support for CEC notifiers, which is used to convey CEC physical address
information from video drivers to their CEC counterpart driver(s).

Based on an earlier version from Russell King:

https://patchwork.kernel.org/patch/9277043/

The cec_notifier is a reference counted object containing the CEC physical 
address
state of a video device.

When a new notifier is registered the current state will be reported to
that notifier at registration time.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
Tested-by: Benjamin Gaignard 
Acked-by: Daniel Vetter 
---
 MAINTAINERS  |   4 +-
 drivers/media/Kconfig|   4 ++
 drivers/media/Makefile   |   4 ++
 drivers/media/cec-notifier.c | 129 +++
 include/media/cec-notifier.h | 111 +
 5 files changed, 251 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/cec-notifier.c
 create mode 100644 include/media/cec-notifier.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 83a42ef1d1a7..cfb2670aa372 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3066,7 +3066,7 @@ F:drivers/net/ieee802154/cc2520.c
 F: include/linux/spi/cc2520.h
 F: Documentation/devicetree/bindings/net/ieee802154/cc2520.txt
 
-CEC DRIVER
+CEC FRAMEWORK
 M: Hans Verkuil 
 L: linux-media@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
@@ -3076,9 +3076,11 @@ F:   Documentation/media/kapi/cec-core.rst
 F: Documentation/media/uapi/cec
 F: drivers/media/cec/
 F: drivers/media/cec-edid.c
+F: drivers/media/cec-notifier.c
 F: drivers/media/rc/keymaps/rc-cec.c
 F: include/media/cec.h
 F: include/media/cec-edid.h
+F: include/media/cec-notifier.h
 F: include/uapi/linux/cec.h
 F: include/uapi/linux/cec-funcs.h
 
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 3512316e7a46..9e9ded44e8a8 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -99,6 +99,10 @@ config MEDIA_CEC_DEBUG
 config MEDIA_CEC_EDID
bool
 
+config MEDIA_CEC_NOTIFIER
+   bool
+   select MEDIA_CEC_EDID
+
 #
 # Media controller
 #  Selectable only for webcam/grabbers, as other drivers don't use it
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index d87ccb8eeabe..8b36a571d443 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -6,6 +6,10 @@ ifeq ($(CONFIG_MEDIA_CEC_EDID),y)
   obj-$(CONFIG_MEDIA_SUPPORT) += cec-edid.o
 endif
 
+ifeq ($(CONFIG_MEDIA_CEC_NOTIFIER),y)
+  obj-$(CONFIG_MEDIA_SUPPORT) += cec-notifier.o
+endif
+
 ifeq ($(CONFIG_MEDIA_CEC_SUPPORT),y)
   obj-$(CONFIG_MEDIA_SUPPORT) += cec/
 endif
diff --git a/drivers/media/cec-notifier.c b/drivers/media/cec-notifier.c
new file mode 100644
index ..1afeede8071a
--- /dev/null
+++ b/drivers/media/cec-notifier.c
@@ -0,0 +1,129 @@
+/*
+ * cec-notifier.c - notify CEC drivers of physical address changes
+ *
+ * Copyright 2016 Russell King 
+ * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct cec_notifier {
+   struct mutex lock;
+   struct list_head head;
+   struct kref kref;
+   struct device *dev;
+   struct cec_adapter *cec_adap;
+   void (*callback)(struct cec_adapter *adap, u16 pa);
+
+   u16 phys_addr;
+};
+
+static LIST_HEAD(cec_notifiers);
+static DEFINE_MUTEX(cec_notifiers_lock);
+
+struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+   struct cec_notifier *n;
+
+   mutex_lock(_notifiers_lock);
+   list_for_each_entry(n, _notifiers, head) {
+   if (n->dev == dev) {
+   mutex_unlock(_notifiers_lock);
+   kref_get(>kref);
+   return n;
+   }
+   }
+   n = kzalloc(sizeof(*n), GFP_KERNEL);
+   if (!n)
+   goto unlock;
+   n->dev = dev;
+   n->phys_addr = CEC_PHYS_ADDR_INVALID;
+   mutex_init(>lock);
+   kref_init(>kref);
+ 

[PATCHv6 08/10] stih-cec.txt: document new hdmi phandle

[Hans Verkuil]

From: Benjamin Gaignard 

Update the bindings documentation with the new hdmi phandle.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
CC: devicet...@vger.kernel.org
---
 Documentation/devicetree/bindings/media/stih-cec.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt 
b/Documentation/devicetree/bindings/media/stih-cec.txt
index 71c4b2f4bcef..289a08b33651 100644
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ b/Documentation/devicetree/bindings/media/stih-cec.txt
@@ -9,6 +9,7 @@ Required properties:
  - pinctrl-names: Contains only one value - "default"
  - pinctrl-0: Specifies the pin control groups used for CEC hardware.
  - resets: Reference to a reset controller
+ - hdmi-phandle: Phandle to the HDMI controller
 
 Example for STIH407:
 
@@ -22,4 +23,5 @@ sti-cec@094a087c {
pinctrl-names = "default";
pinctrl-0 = <_cec0_default>;
resets = < STIH407_LPM_SOFTRESET>;
+   hdmi-phandle = <>;
 };
-- 
2.11.0

[PATCHv6 07/10] sti: hdmi: add CEC notifier support

[Hans Verkuil]

From: Benjamin Gaignard 

Implement the CEC notifier support to allow CEC drivers to
be informed when there is a new physical address.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 11 +++
 drivers/gpu/drm/sti/sti_hdmi.h |  3 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index ce2dcba679d5..243905b6ae59 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -771,6 +771,8 @@ static void sti_hdmi_disable(struct drm_bridge *bridge)
clk_disable_unprepare(hdmi->clk_pix);
 
hdmi->enabled = false;
+
+   cec_notifier_set_phys_addr(hdmi->notifier, CEC_PHYS_ADDR_INVALID);
 }
 
 /**
@@ -973,6 +975,7 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
DRM_DEBUG_KMS("%s : %dx%d cm\n",
  (hdmi->hdmi_monitor ? "hdmi monitor" : "dvi monitor"),
  edid->width_cm, edid->height_cm);
+   cec_notifier_set_phys_addr_from_edid(hdmi->notifier, edid);
 
count = drm_add_edid_modes(connector, edid);
drm_mode_connector_update_edid_property(connector, edid);
@@ -1035,6 +1038,7 @@ sti_hdmi_connector_detect(struct drm_connector 
*connector, bool force)
}
 
DRM_DEBUG_DRIVER("hdmi cable disconnected\n");
+   cec_notifier_set_phys_addr(hdmi->notifier, CEC_PHYS_ADDR_INVALID);
return connector_status_disconnected;
 }
 
@@ -1423,6 +1427,10 @@ static int sti_hdmi_probe(struct platform_device *pdev)
goto release_adapter;
}
 
+   hdmi->notifier = cec_notifier_get(>dev);
+   if (!hdmi->notifier)
+   goto release_adapter;
+
hdmi->reset = devm_reset_control_get(dev, "hdmi");
/* Take hdmi out of reset */
if (!IS_ERR(hdmi->reset))
@@ -1442,11 +1450,14 @@ static int sti_hdmi_remove(struct platform_device *pdev)
 {
struct sti_hdmi *hdmi = dev_get_drvdata(>dev);
 
+   cec_notifier_set_phys_addr(hdmi->notifier, CEC_PHYS_ADDR_INVALID);
+
i2c_put_adapter(hdmi->ddc_adapt);
if (hdmi->audio_pdev)
platform_device_unregister(hdmi->audio_pdev);
component_del(>dev, _hdmi_ops);
 
+   cec_notifier_put(hdmi->notifier);
return 0;
 }
 
diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
index 407012350f1a..c6469b56ce7e 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.h
+++ b/drivers/gpu/drm/sti/sti_hdmi.h
@@ -11,6 +11,7 @@
 #include 
 
 #include 
+#include 
 
 #define HDMI_STA   0x0010
 #define HDMI_STA_DLL_LCK   BIT(5)
@@ -64,6 +65,7 @@ static const struct drm_prop_enum_list 
colorspace_mode_names[] = {
  * @audio_pdev: ASoC hdmi-codec platform device
  * @audio: hdmi audio parameters.
  * @drm_connector: hdmi connector
+ * @notifier: hotplug detect notifier
  */
 struct sti_hdmi {
struct device dev;
@@ -89,6 +91,7 @@ struct sti_hdmi {
struct platform_device *audio_pdev;
struct hdmi_audio_params audio;
struct drm_connector *drm_connector;
+   struct cec_notifier *notifier;
 };
 
 u32 hdmi_read(struct sti_hdmi *hdmi, int offset);
-- 
2.11.0

[PATCHv6 06/10] s5p-cec: add cec-notifier support, move out of staging

[Hans Verkuil]

From: Hans Verkuil 

By using the CEC notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.

Update the bindings documenting the new hdmi phandle and
update exynos4.dtsi accordingly.

Tested with my Odroid U3.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
Acked-by: Krzysztof Kozlowski 
CC: linux-samsung-...@vger.kernel.org
---
 drivers/media/platform/Kconfig | 18 +++
 drivers/media/platform/Makefile|  1 +
 .../media => media/platform}/s5p-cec/Makefile  |  0
 .../platform}/s5p-cec/exynos_hdmi_cec.h|  0
 .../platform}/s5p-cec/exynos_hdmi_cecctrl.c|  0
 .../media => media/platform}/s5p-cec/regs-cec.h|  0
 .../media => media/platform}/s5p-cec/s5p_cec.c | 35 ++
 .../media => media/platform}/s5p-cec/s5p_cec.h |  3 ++
 drivers/staging/media/Kconfig  |  2 --
 drivers/staging/media/Makefile |  1 -
 drivers/staging/media/s5p-cec/Kconfig  |  9 --
 drivers/staging/media/s5p-cec/TODO |  7 -
 12 files changed, 52 insertions(+), 24 deletions(-)
 rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h 
(100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c 
(100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
 rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
 delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
 delete mode 100644 drivers/staging/media/s5p-cec/TODO

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ab0bb4879b54..2c449b88fc94 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -460,6 +460,24 @@ config VIDEO_TI_SC
 config VIDEO_TI_CSC
tristate
 
+menuconfig V4L_CEC_DRIVERS
+   bool "Platform HDMI CEC drivers"
+   depends on MEDIA_CEC_SUPPORT
+
+if V4L_CEC_DRIVERS
+
+config VIDEO_SAMSUNG_S5P_CEC
+   tristate "Samsung S5P CEC driver"
+   depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (PLAT_S5P || ARCH_EXYNOS 
|| COMPILE_TEST)
+   select MEDIA_CEC_NOTIFIER
+   ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
+endif #V4L_CEC_DRIVERS
+
 menuconfig V4L_TEST_DRIVERS
bool "Media test drivers"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 8959f6e6692a..2f94d82afa4c 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)  += s5p-jpeg/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
 
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
 
 obj-$(CONFIG_VIDEO_STI_BDISP)  += sti/bdisp/
diff --git a/drivers/staging/media/s5p-cec/Makefile 
b/drivers/media/platform/s5p-cec/Makefile
similarity index 100%
rename from drivers/staging/media/s5p-cec/Makefile
rename to drivers/media/platform/s5p-cec/Makefile
diff --git a/drivers/staging/media/s5p-cec/exynos_hdmi_cec.h 
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
similarity index 100%
rename from drivers/staging/media/s5p-cec/exynos_hdmi_cec.h
rename to drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
diff --git a/drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c 
b/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
similarity index 100%
rename from drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c
rename to drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
diff --git a/drivers/staging/media/s5p-cec/regs-cec.h 
b/drivers/media/platform/s5p-cec/regs-cec.h
similarity index 100%
rename from drivers/staging/media/s5p-cec/regs-cec.h
rename to drivers/media/platform/s5p-cec/regs-cec.h
diff --git a/drivers/staging/media/s5p-cec/s5p_cec.c 
b/drivers/media/platform/s5p-cec/s5p_cec.c
similarity index 89%
rename from drivers/staging/media/s5p-cec/s5p_cec.c
rename to drivers/media/platform/s5p-cec/s5p_cec.c
index 2a07968b5ac6..f7adf61caaa8 100644
--- a/drivers/staging/media/s5p-cec/s5p_cec.c
+++ b/drivers/media/platform/s5p-cec/s5p_cec.c
@@ -19,11 +19,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "exynos_hdmi_cec.h"
 #include "regs-cec.h"
@@ 

[PATCHv6 10/10] ARM: dts: STiH410: update sti-cec for CEC notifier support

[Hans Verkuil]

From: Benjamin Gaignard 

To use CEC notifier sti CEC driver needs to get phandle
of the hdmi device.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
CC: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/stih407-family.dtsi | 12 
 arch/arm/boot/dts/stih410.dtsi| 13 +
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index d753ac36788f..044184580326 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -742,18 +742,6 @@
 <_s_c0_flexgen CLK_ETH_PHY>;
};
 
-   cec: sti-cec@094a087c {
-   compatible = "st,stih-cec";
-   reg = <0x94a087c 0x64>;
-   clocks = <_sysin>;
-   clock-names = "cec-clk";
-   interrupts = ;
-   interrupt-names = "cec-irq";
-   pinctrl-names = "default";
-   pinctrl-0 = <_cec0_default>;
-   resets = < STIH407_LPM_SOFTRESET>;
-   };
-
rng10: rng@08a89000 {
compatible  = "st,rng";
reg = <0x08a89000 0x1000>;
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index 3c9672c5b09f..21fe72b183d8 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -281,5 +281,18 @@
 <_s_c0_flexgen CLK_ST231_DMU>,
 <_s_c0_flexgen CLK_FLASH_PROMIP>;
};
+
+   sti-cec@094a087c {
+   compatible = "st,stih-cec";
+   reg = <0x94a087c 0x64>;
+   clocks = <_sysin>;
+   clock-names = "cec-clk";
+   interrupts = ;
+   interrupt-names = "cec-irq";
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec0_default>;
+   resets = < STIH407_LPM_SOFTRESET>;
+   hdmi-phandle = <_hdmi>;
+   };
};
 };
-- 
2.11.0

[PATCHv6 03/10] exynos_hdmi: add CEC notifier support

[Hans Verkuil]

From: Hans Verkuil 

Implement the CEC notifier support to allow CEC drivers to
be informed when there is a new physical address.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
Acked-by: Daniel Vetter 
Acked-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 88ccc0469316..bc4c8d0a66f4 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -43,6 +43,8 @@
 
 #include 
 
+#include 
+
 #include "exynos_drm_drv.h"
 #include "exynos_drm_crtc.h"
 
@@ -119,6 +121,7 @@ struct hdmi_context {
booldvi_mode;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
+   struct cec_notifier *notifier;
const struct hdmi_driver_data   *drv_data;
 
void __iomem*regs;
@@ -822,6 +825,7 @@ static enum drm_connector_status hdmi_detect(struct 
drm_connector *connector,
if (gpiod_get_value(hdata->hpd_gpio))
return connector_status_connected;
 
+   cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
return connector_status_disconnected;
 }
 
@@ -860,6 +864,7 @@ static int hdmi_get_modes(struct drm_connector *connector)
edid->width_cm, edid->height_cm);
 
drm_mode_connector_update_edid_property(connector, edid);
+   cec_notifier_set_phys_addr_from_edid(hdata->notifier, edid);
 
ret = drm_add_edid_modes(connector, edid);
 
@@ -1503,6 +1508,7 @@ static void hdmi_disable(struct drm_encoder *encoder)
if (funcs && funcs->disable)
(*funcs->disable)(crtc);
 
+   cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
cancel_delayed_work(>hotplug_work);
 
hdmiphy_disable(hdata);
@@ -1878,15 +1884,22 @@ static int hdmi_probe(struct platform_device *pdev)
}
}
 
+   hdata->notifier = cec_notifier_get(>dev);
+   if (hdata->notifier == NULL) {
+   ret = -ENOMEM;
+   goto err_hdmiphy;
+   }
+
pm_runtime_enable(dev);
 
ret = component_add(>dev, _component_ops);
if (ret)
-   goto err_disable_pm_runtime;
+   goto err_notifier_put;
 
return ret;
 
-err_disable_pm_runtime:
+err_notifier_put:
+   cec_notifier_put(hdata->notifier);
pm_runtime_disable(dev);
 
 err_hdmiphy:
@@ -1905,9 +1918,11 @@ static int hdmi_remove(struct platform_device *pdev)
struct hdmi_context *hdata = platform_get_drvdata(pdev);
 
cancel_delayed_work_sync(>hotplug_work);
+   cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
 
component_del(>dev, _component_ops);
 
+   cec_notifier_put(hdata->notifier);
pm_runtime_disable(>dev);
 
if (!IS_ERR(hdata->reg_hdmi_en))
-- 
2.11.0

[PATCHv6 09/10] stih-cec: add CEC notifier support

[Hans Verkuil]

From: Benjamin Gaignard 

By using the CEC notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
CC: devicet...@vger.kernel.org
---
 drivers/media/platform/Kconfig | 10 +++
 drivers/media/platform/Makefile|  1 +
 .../st-cec => media/platform/sti/cec}/Makefile |  0
 .../st-cec => media/platform/sti/cec}/stih-cec.c   | 31 +++---
 drivers/staging/media/Kconfig  |  2 --
 drivers/staging/media/Makefile |  1 -
 drivers/staging/media/st-cec/Kconfig   |  8 --
 drivers/staging/media/st-cec/TODO  |  7 -
 8 files changed, 39 insertions(+), 21 deletions(-)
 rename drivers/{staging/media/st-cec => media/platform/sti/cec}/Makefile (100%)
 rename drivers/{staging/media/st-cec => media/platform/sti/cec}/stih-cec.c 
(93%)
 delete mode 100644 drivers/staging/media/st-cec/Kconfig
 delete mode 100644 drivers/staging/media/st-cec/TODO

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 2c449b88fc94..7321f6123659 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -476,6 +476,16 @@ config VIDEO_SAMSUNG_S5P_CEC
  CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
+config VIDEO_STI_HDMI_CEC
+   tristate "STMicroelectronics STiH4xx HDMI CEC driver"
+   depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (ARCH_STI || COMPILE_TEST)
+   select MEDIA_CEC_NOTIFIER
+   ---help---
+ This is a driver for STIH4xx HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 endif #V4L_CEC_DRIVERS
 
 menuconfig V4L_TEST_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 2f94d82afa4c..940724ab9b70 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC)+= exynos-gsc/
 obj-$(CONFIG_VIDEO_STI_BDISP)  += sti/bdisp/
 obj-$(CONFIG_VIDEO_STI_HVA)+= sti/hva/
 obj-$(CONFIG_DVB_C8SECTPFE)+= sti/c8sectpfe/
+obj-$(CONFIG_VIDEO_STI_HDMI_CEC)   += sti/cec/
 
 obj-$(CONFIG_VIDEO_STI_DELTA)  += sti/delta/
 
diff --git a/drivers/staging/media/st-cec/Makefile 
b/drivers/media/platform/sti/cec/Makefile
similarity index 100%
rename from drivers/staging/media/st-cec/Makefile
rename to drivers/media/platform/sti/cec/Makefile
diff --git a/drivers/staging/media/st-cec/stih-cec.c 
b/drivers/media/platform/sti/cec/stih-cec.c
similarity index 93%
rename from drivers/staging/media/st-cec/stih-cec.c
rename to drivers/media/platform/sti/cec/stih-cec.c
index 3c25638a9610..636281c64c04 100644
--- a/drivers/staging/media/st-cec/stih-cec.c
+++ b/drivers/media/platform/sti/cec/stih-cec.c
@@ -1,6 +1,4 @@
 /*
- * drivers/staging/media/st-cec/stih-cec.c
- *
  * STIH4xx CEC driver
  * Copyright (C) STMicroelectronic SA 2016
  *
@@ -15,9 +13,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
+#include 
 
 #define CEC_NAME   "stih-cec"
 
@@ -129,6 +129,7 @@ struct stih_cec {
void __iomem*regs;
int irq;
u32 irq_status;
+   struct cec_notifier *notifier;
 };
 
 static int stih_cec_adap_enable(struct cec_adapter *adap, bool enable)
@@ -303,12 +304,29 @@ static int stih_cec_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct resource *res;
struct stih_cec *cec;
+   struct device_node *np;
+   struct platform_device *hdmi_dev;
int ret;
 
cec = devm_kzalloc(dev, sizeof(*cec), GFP_KERNEL);
if (!cec)
return -ENOMEM;
 
+   np = of_parse_phandle(pdev->dev.of_node, "hdmi-phandle", 0);
+
+   if (!np) {
+   dev_err(>dev, "Failed to find hdmi node in device 
tree\n");
+   return -ENODEV;
+   }
+
+   hdmi_dev = of_find_device_by_node(np);
+   if (!hdmi_dev)
+   return -EPROBE_DEFER;
+
+   cec->notifier = cec_notifier_get(_dev->dev);
+   if (!cec->notifier)
+   return -ENOMEM;
+
cec->dev = dev;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -335,7 +353,7 @@ static int stih_cec_probe(struct platform_device *pdev)
cec->adap = cec_allocate_adapter(_cec_adap_ops, cec,
CEC_NAME,
CEC_CAP_LOG_ADDRS | CEC_CAP_PASSTHROUGH |
-   CEC_CAP_PHYS_ADDR | 

[PATCHv6 02/10] cec: integrate CEC notifier support

[Hans Verkuil]

From: Hans Verkuil 

Support the CEC notifier framework, simplifying drivers that
depend on this.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
Tested-by: Benjamin Gaignard 
Acked-by: Daniel Vetter 
---
 drivers/media/cec/cec-core.c | 22 ++
 include/media/cec.h  | 10 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 37217e205040..e5070b374276 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -195,6 +195,24 @@ static void cec_devnode_unregister(struct cec_devnode 
*devnode)
put_device(>dev);
 }
 
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+static void cec_cec_notify(struct cec_adapter *adap, u16 pa)
+{
+   cec_s_phys_addr(adap, pa, false);
+}
+
+void cec_register_cec_notifier(struct cec_adapter *adap,
+  struct cec_notifier *notifier)
+{
+   if (WARN_ON(!adap->devnode.registered))
+   return;
+
+   adap->notifier = notifier;
+   cec_notifier_register(adap->notifier, adap, cec_cec_notify);
+}
+EXPORT_SYMBOL_GPL(cec_register_cec_notifier);
+#endif
+
 struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
 void *priv, const char *name, u32 caps,
 u8 available_las)
@@ -343,6 +361,10 @@ void cec_unregister_adapter(struct cec_adapter *adap)
adap->rc = NULL;
 #endif
debugfs_remove_recursive(adap->cec_dir);
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+   if (adap->notifier)
+   cec_notifier_unregister(adap->notifier);
+#endif
cec_devnode_unregister(>devnode);
 }
 EXPORT_SYMBOL_GPL(cec_unregister_adapter);
diff --git a/include/media/cec.h b/include/media/cec.h
index 96a0aa770d61..307f5dcaf034 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * struct cec_devnode - cec device node
@@ -173,6 +174,10 @@ struct cec_adapter {
bool passthrough;
struct cec_log_addrs log_addrs;
 
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+   struct cec_notifier *notifier;
+#endif
+
struct dentry *cec_dir;
struct dentry *status_file;
 
@@ -213,6 +218,11 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
status, u8 arb_lost_cnt,
   u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);
 void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
 
+#ifdef CONFIG_MEDIA_CEC_NOTIFIER
+void cec_register_cec_notifier(struct cec_adapter *adap,
+  struct cec_notifier *notifier);
+#endif
+
 #else
 
 static inline int cec_register_adapter(struct cec_adapter *adap,
-- 
2.11.0

[PATCHv6 00/10] video/exynos/sti/cec: add CEC notifier & use in drivers

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds the CEC physical address notifier code, based on
Russell's code:

https://patchwork.kernel.org/patch/9277043/

It adds support for it to the exynos_hdmi drm driver, adds support for
it to the CEC framework and finally adds support to the s5p-cec driver,
which now can be moved out of staging.

Also included is similar code for the STI platform, contributed by
Benjamin Gaignard.

Tested the exynos code with my Odroid U3 exynos4 devboard.

Comments are welcome. I'd like to get this in for the 4.12 kernel as
this is a missing piece needed to integrate CEC drivers.

Regards,

Hans

Changes since v5:
- Add cec_notifier_set_phys_addr_from_edid(). This maps to an empty
  function if CONFIG_MEDIA_CEC_NOTIFIER is undefined.
- Dropped the first cec-edid patch. It's no longer needed after the
  previous change.

Changes since v4:
- Dropped EDID/ELD/connect/disconnect support. Instead, just report the
  CEC physical address (and use INVALID when disconnecting).
- Since this is now completely CEC specific, move it to drivers/media
  and rename to cec-notifier.
- Drop block_notifier. Instead just set a callback for the notifier.
- Use 'hdmi-phandle' in the bindings for both exynos and sti. So no
  vendor prefix and 'hdmi-phandle' instead of 'hdmi-handle'.
- Make struct cec_notifier opaque. Add a helper function to get the
  physical address from a cec_notifier struct.
- Provide dummy functions in cec-notifier.h so it can be used when
  CONFIG_MEDIA_CEC_NOTIFIER is undefined.
- Don't select the CEC notifier in the HDMI drivers. It should only
  be enabled by actual CEC drivers.

Changes since v3:
- Added the STI patches
- Split the exynos4 binding patches in one for documentation and one
  for the dts change itself, also use the correct subject and CC to
  the correct mailinglists (I hope  )

Changes since v2:
- Split off the dts changes of the s5p-cec patch into a separate patch
- Renamed HPD_NOTIFIERS to HPD_NOTIFIER to be consistent with the name
  of the source.

Changes since v1:

Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is
not HDMI specific, but is interesting for any video source that has to
deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ).
Only the use with CEC adapters is HDMI specific, but the HPD notifier
is more generic.


Benjamin Gaignard (4):
  sti: hdmi: add CEC notifier support
  stih-cec.txt: document new hdmi phandle
  stih-cec: add CEC notifier support
  ARM: dts: STiH410: update sti-cec for CEC notifier support

Hans Verkuil (6):
  media: add CEC notifier support
  cec: integrate CEC notifier support
  exynos_hdmi: add CEC notifier support
  ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
  s5p-cec.txt: document the HDMI controller phandle
  s5p-cec: add cec-notifier support, move out of staging

 .../devicetree/bindings/media/s5p-cec.txt  |   2 +
 .../devicetree/bindings/media/stih-cec.txt |   2 +
 MAINTAINERS|   4 +-
 arch/arm/boot/dts/exynos4.dtsi |   1 +
 arch/arm/boot/dts/stih407-family.dtsi  |  12 --
 arch/arm/boot/dts/stih410.dtsi |  13 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  19 ++-
 drivers/gpu/drm/sti/sti_hdmi.c |  11 ++
 drivers/gpu/drm/sti/sti_hdmi.h |   3 +
 drivers/media/Kconfig  |   4 +
 drivers/media/Makefile |   4 +
 drivers/media/cec-notifier.c   | 129 +
 drivers/media/cec/cec-core.c   |  22 
 drivers/media/platform/Kconfig |  28 +
 drivers/media/platform/Makefile|   2 +
 .../media => media/platform}/s5p-cec/Makefile  |   0
 .../platform}/s5p-cec/exynos_hdmi_cec.h|   0
 .../platform}/s5p-cec/exynos_hdmi_cecctrl.c|   0
 .../media => media/platform}/s5p-cec/regs-cec.h|   0
 .../media => media/platform}/s5p-cec/s5p_cec.c |  35 +-
 .../media => media/platform}/s5p-cec/s5p_cec.h |   3 +
 .../st-cec => media/platform/sti/cec}/Makefile |   0
 .../st-cec => media/platform/sti/cec}/stih-cec.c   |  31 -
 drivers/staging/media/Kconfig  |   4 -
 drivers/staging/media/Makefile |   2 -
 drivers/staging/media/s5p-cec/Kconfig  |   9 --
 drivers/staging/media/s5p-cec/TODO |   7 --
 drivers/staging/media/st-cec/Kconfig   |   8 --
 drivers/staging/media/st-cec/TODO  |   7 --
 include/media/cec-notifier.h   | 111 ++
 include/media/cec.h|  10 ++
 31 files changed, 423 insertions(+), 60 deletions(-)
 create mode 100644 drivers/media/cec-notifier.c
 rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
 rename 

[PATCHv6 04/10] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi

[Hans Verkuil]

From: Hans Verkuil 

Add the new hdmi phandle to exynos4.dtsi. This phandle is needed by the
s5p-cec driver to initialize the CEC notifier framework.

Tested with my Odroid U3.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
CC: linux-samsung-...@vger.kernel.org
CC: devicet...@vger.kernel.org
CC: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 18def1c774d5..84fcdff140ae 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -771,6 +771,7 @@
clocks = < CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <_system_controller>;
+   hdmi-phandle = <>;
pinctrl-names = "default";
pinctrl-0 = <_cec>;
status = "disabled";
-- 
2.11.0

Re: [PATCH] dma-buf: fence debugging

[Christian König]

Am 31.03.2017 um 12:00 schrieb Russell King:

Add debugfs output to report shared and exclusive fences on a dma_buf
object.  This produces output such as:

Dma-buf Objects:
sizeflags   modecount   exp_name
0829440000050005drm
 Exclusive fence: etnaviv 134000.gpu signalled
 Attached Devices:
 gpu-subsystem
Total 1 devices attached


Total 1 objects, 8294400 bytes


Signed-off-by: Russell King 


Reviewed-by: Christian König 


---
  drivers/dma-buf/dma-buf.c | 34 +-
  1 file changed, 33 insertions(+), 1 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 0007b792827b..f72aaacbe023 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1059,7 +1059,11 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
int ret;
struct dma_buf *buf_obj;
struct dma_buf_attachment *attach_obj;
-   int count = 0, attach_count;
+   struct reservation_object *robj;
+   struct reservation_object_list *fobj;
+   struct dma_fence *fence;
+   unsigned seq;
+   int count = 0, attach_count, shared_count, i;
size_t size = 0;
  
  	ret = mutex_lock_interruptible(_list.lock);

@@ -1085,6 +1090,34 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
file_count(buf_obj->file),
buf_obj->exp_name);
  
+		robj = buf_obj->resv;

+   while (true) {
+   seq = read_seqcount_begin(>seq);
+   rcu_read_lock();
+   fobj = rcu_dereference(robj->fence);
+   shared_count = fobj ? fobj->shared_count : 0;
+   fence = rcu_dereference(robj->fence_excl);
+   if (!read_seqcount_retry(>seq, seq))
+   break;
+   rcu_read_unlock();
+   }
+
+   if (fence)
+   seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
+  fence->ops->get_driver_name(fence),
+  fence->ops->get_timeline_name(fence),
+  dma_fence_is_signaled(fence) ? "" : "un");
+   for (i = 0; i < shared_count; i++) {
+   fence = rcu_dereference(fobj->shared[i]);
+   if (!dma_fence_get_rcu(fence))
+   continue;
+   seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
+  fence->ops->get_driver_name(fence),
+  fence->ops->get_timeline_name(fence),
+  dma_fence_is_signaled(fence) ? "" : "un");
+   }
+   rcu_read_unlock();
+
seq_puts(s, "\tAttached Devices:\n");
attach_count = 0;
  

Re: [PATCH] vidioc-enumin/output.rst: improve documentation

[Hans Verkuil]

On 31/03/17 12:05, Mauro Carvalho Chehab wrote:
> Em Fri, 31 Mar 2017 10:58:39 +0200
> Hans Verkuil  escreveu:
> 
>> The V4L2_INPUT_TYPE_CAMERA and V4L2_OUTPUT_TYPE_ANALOG descriptions were
>> hopelessly out of date. Fix this, and also fix a few style issues in these
>> documents. Finally add the missing documentation for 
>> V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY
>> (only used by the zoran driver).
>>
>> Signed-off-by: Hans Verkuil 
>> ---
> 
> Patch looks OK to me, but see below.
> 
>> Question: should we perhaps add _TYPE_VIDEO aliases?
> 
> IMHO, let's rename it to _TYPE_VIDEO (or STREAM, or V_STREAM), and make 
> _TYPE_CAMERA an alias, e. g.:
> 
> #define V4L2_INPUT_TYPE_VIDEO 2
> 
> #define V4L2_INPUT_TYPE_CAMERA V4L2_INPUT_TYPE_VIDEO
> 
> This way, we'll let clearer what's currently preferred. We should also
> change it at the documentation, mentioning that V4L2_INPUT_TYPE_CAMERA
> is an alias, due to historical reasons.

Does this really make sense to do this now? Everyone is used to the old defines,
wouldn't changing this just increase confusion?

Sorry, playing devil's advocate here.

I'm a bit hesitant of doing this. We've done this in the past for APIs that
were very new or rarely used, but this is everywhere.

I feel fixing the spec is sufficient.

If more people think that adding this aliases is a good idea, then I can do 
that.

Regards,

Hans

Re: [PATCH] [media] docs-rst: clarify field vs frame height in the subdev API

[Hans Verkuil]

On 31/03/17 10:55, Philipp Zabel wrote:
> Hi Laurent,
> 
> On Fri, 2017-03-31 at 11:09 +0300, Laurent Pinchart wrote:
>> Hi Philipp,
>>
>> Thank you for the patch.
>>
>> On Thursday 30 Mar 2017 17:38:20 Philipp Zabel wrote:
>>> VIDIOC_SUBDEV_G/S_FMT take the field size if V4L2_FIELD_ALTERNATE field
>>> order is set, but the VIDIOC_SUBDEV_G/S_SELECTION rectangles still refer
>>> to frame size, regardless of the field order setting.
>>> VIDIOC_SUBDEV_ENUM_FRAME_SIZES always returns frame sizes as opposed to
>>> field sizes.
>>>
>>> This was not immediately clear to me when reading the documentation, so
>>> this patch adds some clarifications in the relevant places.
>>>
>>> Suggested-by: Laurent Pinchart 
>>> Signed-off-by: Philipp Zabel 
>>> ---
>>>  Documentation/media/uapi/v4l/dev-subdev.rst  | 16 +
>>>  Documentation/media/uapi/v4l/subdev-formats.rst  |  3 ++-
>>>  .../media/uapi/v4l/vidioc-subdev-enum-frame-size.rst |  4 
>>>  .../media/uapi/v4l/vidioc-subdev-g-selection.rst |  2 ++
>>>  4 files changed, 20 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/media/uapi/v4l/dev-subdev.rst
>>> b/Documentation/media/uapi/v4l/dev-subdev.rst index
>>> cd28701802086..2f0a41f3796f0 100644
>>> --- a/Documentation/media/uapi/v4l/dev-subdev.rst
>>> +++ b/Documentation/media/uapi/v4l/dev-subdev.rst
>>> @@ -82,7 +82,8 @@ Pad-level Formats
>>>  .. note::
>>>
>>>  For the purpose of this section, the term *format* means the
>>> -combination of media bus data format, frame width and frame height.
>>> +combination of media bus data format, frame width and frame height,
>>> +unless otherwise noted.
>>>
>>>  Image formats are typically negotiated on video capture and output
>>>  devices using the format and
>>> @@ -120,7 +121,9 @@ can expose pad-level image format configuration to
>>> applications. When they do, applications can use the
>>>
>>>  :ref:`VIDIOC_SUBDEV_G_FMT ` and
>>>  :ref:`VIDIOC_SUBDEV_S_FMT ` ioctls. to
>>>
>>> -negotiate formats on a per-pad basis.
>>> +negotiate formats on a per-pad basis. Note that when those ioctls are
>>> +called with or return the field order set to ``V4L2_FIELD_ALTERNATE``,
>>> +the format contains the field height, which is half the frame height.
>>
>> Isn't that also the case for the TOP and BOTTOM field orders ?
> 
> Oh, those exist, too. I'll change all occurences to list ALTERNATE, TOP,
> and BOTTOM. I hope this is not going to be too verbose for people that
> don't have to care about interlacing.
> 
>>>  Applications are responsible for configuring coherent parameters on the
>>>  whole pipeline and making sure that connected pads have compatible
>>> @@ -379,7 +382,10 @@ is supported by the hardware.
>>> pad for further processing.
>>>
>>>  2. Sink pad actual crop selection. The sink pad crop defines the crop
>>> -   performed to the sink pad format.
>>> +   performed to the sink pad format. The crop rectangle always refers to
>>> +   the frame size, even if the sink pad format has field order set to
>>> +   ``V4L2_FIELD_ALTERNATE`` and the actual processed images are only
>>> +   field sized.
>>
>> I'm not sure to agree with this. I think all selection rectangle coordinates 
>> should be expressed relative to the format of the pad they refer to.
> 
> But that's not how I understood Hans yesterday, and it shows that you
> were quite on point with your suggestion to extend the docs.

Actually, it is a bit different from what I said yesterday. Sorry about that.

Whether the top and height fields in struct v4l2_rect are for fields or
frames depends on whether it describes memory or video. Historically
VIDIOC_CROPCAP and VIDIOC_G/S_CROP used frame coordinates for video
capture (crop rectangle) and video output (compose rectangle, i.e. what is
composed into the video transmitter).

When the selection API was added we could also describe how video is
composed into a memory buffer (for capture) or cropped from a memory buffer
(for output). Since this deals with memory the v4l2_rect struct contains
field coordinates, for the same reason that G/S/TRY_FMT does.

The vivid driver *should* do all of this correctly. Since this driver
supports any combination of cropping/composing/scaler features it gets
quite complicated, so it is always possible that there are bugs, but I
did a lot of testing at the time.

>> For sink pad crop rectangles, if the sink pad receives alternate (or
>> top or bottom only) fields, the rectangle coordinates should be
>> relative to the field size. Similarly, if the source pad produces
>> alternate/top/bottom fields, the rectangle coordinates should also be
>> relative to the field size.
> 
> That's also not how TVP5150 currently implements it. The crop rectangle
> is frame sized even though the pad format reports alternating fields,

It is undefined today what the subdev selection rectangles should use.
I am inclined to 

Re: [PATCH] treewide: Correct diffrent[iate] and banlance typos

[Mauro Carvalho Chehab]

Em Thu, 30 Mar 2017 20:44:16 -0700
Joe Perches  escreveu:

> Add these misspellings to scripts/spelling.txt too
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/media/dvb-frontends/drx39xyj/drx_dap_fasi.h | 2 +-
>  drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c  | 2 +-
>  drivers/net/ethernet/hisilicon/hns/hns_enet.c   | 2 +-
>  drivers/net/ethernet/qlogic/qed/qed_int.c   | 2 +-
>  drivers/net/ethernet/qlogic/qed/qed_main.c  | 2 +-
>  drivers/net/ethernet/qlogic/qed/qed_sriov.c | 2 +-
>  include/linux/mlx4/device.h | 2 +-
>  scripts/spelling.txt| 3 +++
>  8 files changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/dvb-frontends/drx39xyj/drx_dap_fasi.h 
> b/drivers/media/dvb-frontends/drx39xyj/drx_dap_fasi.h
> index 354ec07eae87..23ae72468025 100644
> --- a/drivers/media/dvb-frontends/drx39xyj/drx_dap_fasi.h
> +++ b/drivers/media/dvb-frontends/drx39xyj/drx_dap_fasi.h
> @@ -70,7 +70,7 @@
>  * (3) both long and short but short preferred and long only when necesarry
>  *
>  * These modes must be selected compile time via compile switches.
> -* Compile switch settings for the diffrent modes:
> +* Compile switch settings for the different modes:
>  * (1) DRXDAPFASI_LONG_ADDR_ALLOWED=0, DRXDAPFASI_SHORT_ADDR_ALLOWED=1
>  * (2) DRXDAPFASI_LONG_ADDR_ALLOWED=1, DRXDAPFASI_SHORT_ADDR_ALLOWED=0
>  * (3) DRXDAPFASI_LONG_ADDR_ALLOWED=1, DRXDAPFASI_SHORT_ADDR_ALLOWED=1
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c 
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
> index cea6bdcde33f..8baf9d3eb4b1 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
> @@ -1591,7 +1591,7 @@ static int __bnx2x_vlan_mac_execute_step(struct bnx2x 
> *bp,
>   if (rc != 0) {
>   __bnx2x_vlan_mac_h_pend(bp, o, *ramrod_flags);
>  
> - /* Calling function should not diffrentiate between this case
> + /* Calling function should not differentiate between this case
>* and the case in which there is already a pending ramrod
>*/
>   rc = 1;


Acked-by: Mauro Carvalho Chehab 

Thanks,
Mauro

Re: [PATCH] vidioc-enumin/output.rst: improve documentation

[Mauro Carvalho Chehab]

Em Fri, 31 Mar 2017 10:58:39 +0200
Hans Verkuil  escreveu:

> The V4L2_INPUT_TYPE_CAMERA and V4L2_OUTPUT_TYPE_ANALOG descriptions were
> hopelessly out of date. Fix this, and also fix a few style issues in these
> documents. Finally add the missing documentation for 
> V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY
> (only used by the zoran driver).
> 
> Signed-off-by: Hans Verkuil 
> ---

Patch looks OK to me, but see below.

> Question: should we perhaps add _TYPE_VIDEO aliases?

IMHO, let's rename it to _TYPE_VIDEO (or STREAM, or V_STREAM), and make 
_TYPE_CAMERA an alias, e. g.:

#define V4L2_INPUT_TYPE_VIDEO 2

#define V4L2_INPUT_TYPE_CAMERA V4L2_INPUT_TYPE_VIDEO

This way, we'll let clearer what's currently preferred. We should also
change it at the documentation, mentioning that V4L2_INPUT_TYPE_CAMERA
is an alias, due to historical reasons.

Thanks,
Mauro

[PATCH] dma-buf: align debugfs output

[Russell King]

Align the heading with the values output from debugfs.

Signed-off-by: Russell King 
---
 drivers/dma-buf/dma-buf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ebaf1923ad6b..f72aaacbe023 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1072,7 +1072,8 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
return ret;
 
seq_puts(s, "\nDma-buf Objects:\n");
-   seq_puts(s, "size\tflags\tmode\tcount\texp_name\n");
+   seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\n",
+  "size", "flags", "mode", "count");
 
list_for_each_entry(buf_obj, _list.head, list_node) {
ret = mutex_lock_interruptible(_obj->lock);
-- 
2.7.4

[PATCH] dma-buf: fence debugging

[Russell King]

Add debugfs output to report shared and exclusive fences on a dma_buf
object.  This produces output such as:

Dma-buf Objects:
sizeflags   modecount   exp_name
0829440000050005drm
Exclusive fence: etnaviv 134000.gpu signalled
Attached Devices:
gpu-subsystem
Total 1 devices attached


Total 1 objects, 8294400 bytes


Signed-off-by: Russell King 
---
 drivers/dma-buf/dma-buf.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 0007b792827b..f72aaacbe023 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1059,7 +1059,11 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
int ret;
struct dma_buf *buf_obj;
struct dma_buf_attachment *attach_obj;
-   int count = 0, attach_count;
+   struct reservation_object *robj;
+   struct reservation_object_list *fobj;
+   struct dma_fence *fence;
+   unsigned seq;
+   int count = 0, attach_count, shared_count, i;
size_t size = 0;
 
ret = mutex_lock_interruptible(_list.lock);
@@ -1085,6 +1090,34 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
file_count(buf_obj->file),
buf_obj->exp_name);
 
+   robj = buf_obj->resv;
+   while (true) {
+   seq = read_seqcount_begin(>seq);
+   rcu_read_lock();
+   fobj = rcu_dereference(robj->fence);
+   shared_count = fobj ? fobj->shared_count : 0;
+   fence = rcu_dereference(robj->fence_excl);
+   if (!read_seqcount_retry(>seq, seq))
+   break;
+   rcu_read_unlock();
+   }
+
+   if (fence)
+   seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
+  fence->ops->get_driver_name(fence),
+  fence->ops->get_timeline_name(fence),
+  dma_fence_is_signaled(fence) ? "" : "un");
+   for (i = 0; i < shared_count; i++) {
+   fence = rcu_dereference(fobj->shared[i]);
+   if (!dma_fence_get_rcu(fence))
+   continue;
+   seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
+  fence->ops->get_driver_name(fence),
+  fence->ops->get_timeline_name(fence),
+  dma_fence_is_signaled(fence) ? "" : "un");
+   }
+   rcu_read_unlock();
+
seq_puts(s, "\tAttached Devices:\n");
attach_count = 0;
 
-- 
2.7.4

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Mauro Carvalho Chehab]

Em Fri, 31 Mar 2017 10:29:04 +0200
Hans Verkuil  escreveu:

> On 30/03/17 18:02, Helen Koike wrote:
> > Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
> > used when no inputs are available in the device
> > 
> > Signed-off-by: Helen Koike 
> > ---
> >  drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
> >  include/media/v4l2-ioctl.h   | 26 ++
> >  include/uapi/linux/videodev2.h   |  1 +
> >  3 files changed, 54 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 0c3f238..ccaf04b 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct 
> > video_device *vdev, unsigned cmd)
> > return vdev->lock;
> >  }
> >  
> > +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> > + struct v4l2_input *i)
> > +{
> > +   if (i->index > 0)
> > +   return -EINVAL;
> > +
> > +   memset(i, 0, sizeof(*i));
> > +   i->type = V4L2_INPUT_TYPE_DEFAULT;
> > +   strlcpy(i->name, "Default", sizeof(i->name));
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);
> > +
> > +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int 
> > *i)
> > +{
> > +   *i = 0;
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(v4l2_ioctl_g_input_default);
> > +
> > +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int 
> > i)
> > +{
> > +   return i ? -EINVAL : 0;
> > +}
> > +EXPORT_SYMBOL(v4l2_ioctl_s_input_default);
> > +
> >  /* Common ioctl debug function. This function can be used by
> > external ioctl messages as well as internal V4L ioctl */
> >  void v4l_printk_ioctl(const char *prefix, unsigned int cmd)
> > diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
> > index 6cd94e5..accc470 100644
> > --- a/include/media/v4l2-ioctl.h
> > +++ b/include/media/v4l2-ioctl.h
> > @@ -652,6 +652,32 @@ struct video_device;
> >   */
> >  struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev, unsigned int 
> > cmd);
> >  
> > +
> > +/**
> > + * v4l2_ioctl_enum_input_default - v4l2 ioctl helper for VIDIOC_ENUM_INPUT 
> > ioctl
> > + *
> > + * Plug this function in vidioc_enum_input field of the struct 
> > v4l2_ioctl_ops to
> > + * enumerate a single input as V4L2_INPUT_TYPE_DEFAULT
> > + */
> > +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> > + struct v4l2_input *i);
> > +
> > +/**
> > + * v4l2_ioctl_g_input_default - v4l2 ioctl helper for VIDIOC_G_INPUT ioctl
> > + *
> > + * Plug this function in vidioc_g_input field of the struct v4l2_ioctl_ops
> > + * when using v4l2_ioctl_enum_input_default
> > + */
> > +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int 
> > *i);
> > +
> > +/**
> > + * v4l2_ioctl_s_input_default - v4l2 ioctl helper for VIDIOC_S_INPUT ioctl
> > + *
> > + * Plug this function in vidioc_s_input field of the struct v4l2_ioctl_ops
> > + * when using v4l2_ioctl_enum_input_default
> > + */
> > +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int 
> > i);
> > +
> >  /* names for fancy debug output */
> >  extern const char *v4l2_field_names[];
> >  extern const char *v4l2_type_names[];
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 316be62..c10bbde 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -1477,6 +1477,7 @@ struct v4l2_input {
> >  };
> >  
> >  /*  Values for the 'type' field */
> > +#define V4L2_INPUT_TYPE_DEFAULT0  
> 
> I don't think we should add a new type here.

I second that. Just replied the same thing on a comment from Sakari to
patch 2/2.

> The whole point of this exercise is to
> allow existing apps to work, and existing apps expect a TYPE_CAMERA.
> 
> BTW, don't read to much in the term 'CAMERA': it's really a catch all for any 
> video
> stream, whether it is from a sensor, composite input, HDMI, etc.
> 
> The description for V4L2_INPUT_TYPE_CAMERA in the spec is hopelessly out of 
> date :-(

Yeah, we always used "CAMERA" to mean NOT_TUNER.

> Rather than creating a new type I would add a new V4L2_IN_CAP_MC capability 
> that
> indicates that this input is controlled via the media controller. That makes 
> much
> more sense and it wouldn't potentially break applications.
> 
> Exactly the same can be done for outputs as well: add V4L2_OUT_CAP_MC and use
> V4L2_OUTPUT_TYPE_ANALOG as the output type (again, a horrible outdated name 
> and the
> spec is again out of date).

I don't see any sense on distinguishing IN and OUT for MC. I mean: should
we ever allow that any driver to have their inputs controlled via V4L2 API, 
and their outputs controlled via MC (or vice-versa)? I 

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Hans Verkuil]

On 31/03/17 11:42, Mauro Carvalho Chehab wrote:
> Em Fri, 31 Mar 2017 00:55:12 -0300
> Helen Koike  escreveu:
> 
>> On 2017-03-30 11:39 PM, Helen Koike wrote:
>>> Hi Laurent,
>>>
>>> Thanks for reviewing
>>>
>>> On 2017-03-30 04:56 PM, Laurent Pinchart wrote:  
 Hi Helen,

 Thank you for the patch.

 On Thursday 30 Mar 2017 13:02:17 Helen Koike wrote:  
> Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
> used when no inputs are available in the device
>
> Signed-off-by: Helen Koike 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
>  include/media/v4l2-ioctl.h   | 26 ++
>  include/uapi/linux/videodev2.h   |  1 +
>  3 files changed, 54 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c index 0c3f238..ccaf04b 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct
> video_device
> *vdev, unsigned cmd) return vdev->lock;
>  }
>
> +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> +  struct v4l2_input *i)
> +{
> +if (i->index > 0)
> +return -EINVAL;
> +
> +memset(i, 0, sizeof(*i));
> +i->type = V4L2_INPUT_TYPE_DEFAULT;
> +strlcpy(i->name, "Default", sizeof(i->name));
> +
> +return 0;
> +}
> +EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);  

 V4L2 tends to use EXPORT_SYMBOL_GPL.  
>>>
>>> The whole v4l2-ioctl.c file is using EXPORT_SYMBOL instead of
>>> EXPORT_SYMBOL_GPL, should we change it all to EXPORT_SYMBOL_GPL then (in
>>> another patch) ?
>>>  

 What would you think about calling those default functions directly
 from the
 core when the input ioctl handlers are not set ? You wouldn't need to
 modify
 drivers.  
>>>
>>> Sure, I'll add them in ops inside __video_register_device when it
>>> validates the ioctls  
>>
>> I just realize I can not simply override struct v4l2_ioctl_ops as it is 
>> declared as a const inside strut video_device. I'll call those default 
>> functions only when the ioctls are handled to not modify vdev->ops.
> 
> You should not override it, anyway. What you should do, instead, is
> something like:
> 
> static int v4l_ginput(const struct v4l2_ioctl_ops *ops, ...)
> {
>   if (ops->vidioc_ginput)
>   return ops->vidioc_ginput(...);
> 
>   /* default code */
> }
> 
> You should also make sure that the ioctls are alway valid, e. g. by
> calling SET_VALID_IOCTL()

Helen, FYI:

The input ioctls are compulsory for:

V4L2_CAP_VIDEO_CAPTURE
V4L2_CAP_VBI_CAPTURE
V4L2_CAP_VIDEO_CAPTURE_MPLANE
V4L2_CAP_SLICED_VBI_CAPTURE

The output ioctls are compulsory for:

V4L2_CAP_VIDEO_OUTPUT
V4L2_CAP_VBI_OUTPUT
V4L2_CAP_VIDEO_OUTPUT_MPLANE
V4L2_CAP_SLICED_VBI_OUTPUT

If none of these caps are set, then we shouldn't provide these stubs.

Regards,

Hans

> 
> Thanks,
> Mauro
> 

Re: [PATCH 2/2] [media] docs-rst: add V4L2_INPUT_TYPE_DEFAULT

[Mauro Carvalho Chehab]

Em Thu, 30 Mar 2017 23:26:26 +0300
Sakari Ailus  escreveu:

> Hi Helen and others,
> 
> On Thu, Mar 30, 2017 at 01:02:18PM -0300, Helen Koike wrote:
> > add documentation for V4L2_INPUT_TYPE_DEFAULT
> > 
> > Signed-off-by: Helen Koike 
> > ---
> >  Documentation/media/uapi/v4l/vidioc-enuminput.rst | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/Documentation/media/uapi/v4l/vidioc-enuminput.rst 
> > b/Documentation/media/uapi/v4l/vidioc-enuminput.rst
> > index 17aaaf9..0237e10 100644
> > --- a/Documentation/media/uapi/v4l/vidioc-enuminput.rst
> > +++ b/Documentation/media/uapi/v4l/vidioc-enuminput.rst
> > @@ -112,6 +112,9 @@ at index zero, incrementing by one until the driver 
> > returns ``EINVAL``.
> >  :stub-columns: 0
> >  :widths:   3 1 4
> >  
> > +* - ``V4L2_INPUT_TYPE_DEFAULT``
> > +  - 0
> > +  - This is the default value returned when no input is supported.

Input *IS* supported. The device has one input. So, the description is wrong ;)

> >  * - ``V4L2_INPUT_TYPE_TUNER``
> >- 1
> >- This input uses a tuner (RF demodulator).  
> 
> What would you think of calling this input as "unknown" instead of
> "default"? That's what an input which isn't really specified actually is.

Yeah, default seems a bad name to me, too.

Actually, I think that the best here would be to not create a new type.
just use V4L2_INPUT_TYPE_CAMERA. That's actually the default for the
embedded drivers. If a driver is providing input for something else,
then it should implement vidioc_enuminput method.

Thanks,
Mauro

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Mauro Carvalho Chehab]

Em Fri, 31 Mar 2017 00:55:12 -0300
Helen Koike  escreveu:

> On 2017-03-30 11:39 PM, Helen Koike wrote:
> > Hi Laurent,
> >
> > Thanks for reviewing
> >
> > On 2017-03-30 04:56 PM, Laurent Pinchart wrote:  
> >> Hi Helen,
> >>
> >> Thank you for the patch.
> >>
> >> On Thursday 30 Mar 2017 13:02:17 Helen Koike wrote:  
> >>> Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
> >>> used when no inputs are available in the device
> >>>
> >>> Signed-off-by: Helen Koike 
> >>> ---
> >>>  drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
> >>>  include/media/v4l2-ioctl.h   | 26 ++
> >>>  include/uapi/linux/videodev2.h   |  1 +
> >>>  3 files changed, 54 insertions(+)
> >>>
> >>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> >>> b/drivers/media/v4l2-core/v4l2-ioctl.c index 0c3f238..ccaf04b 100644
> >>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> >>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> >>> @@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct
> >>> video_device
> >>> *vdev, unsigned cmd) return vdev->lock;
> >>>  }
> >>>
> >>> +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> >>> +  struct v4l2_input *i)
> >>> +{
> >>> +if (i->index > 0)
> >>> +return -EINVAL;
> >>> +
> >>> +memset(i, 0, sizeof(*i));
> >>> +i->type = V4L2_INPUT_TYPE_DEFAULT;
> >>> +strlcpy(i->name, "Default", sizeof(i->name));
> >>> +
> >>> +return 0;
> >>> +}
> >>> +EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);  
> >>
> >> V4L2 tends to use EXPORT_SYMBOL_GPL.  
> >
> > The whole v4l2-ioctl.c file is using EXPORT_SYMBOL instead of
> > EXPORT_SYMBOL_GPL, should we change it all to EXPORT_SYMBOL_GPL then (in
> > another patch) ?
> >  
> >>
> >> What would you think about calling those default functions directly
> >> from the
> >> core when the input ioctl handlers are not set ? You wouldn't need to
> >> modify
> >> drivers.  
> >
> > Sure, I'll add them in ops inside __video_register_device when it
> > validates the ioctls  
> 
> I just realize I can not simply override struct v4l2_ioctl_ops as it is 
> declared as a const inside strut video_device. I'll call those default 
> functions only when the ioctls are handled to not modify vdev->ops.

You should not override it, anyway. What you should do, instead, is
something like:

static int v4l_ginput(const struct v4l2_ioctl_ops *ops, ...)
{
if (ops->vidioc_ginput)
return ops->vidioc_ginput(...);

/* default code */
}

You should also make sure that the ioctls are alway valid, e. g. by
calling SET_VALID_IOCTL()

Thanks,
Mauro

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Mauro Carvalho Chehab]

Em Fri, 31 Mar 2017 11:41:51 +0300
Laurent Pinchart  escreveu:

> Hi Helen,
> 
> On Thursday 30 Mar 2017 23:39:01 Helen Koike wrote:
> > On 2017-03-30 04:56 PM, Laurent Pinchart wrote:  
> > > On Thursday 30 Mar 2017 13:02:17 Helen Koike wrote:  
> > >> Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
> > >> used when no inputs are available in the device
> > >> 
> > >> Signed-off-by: Helen Koike 
> > >> ---
> > >> 
> > >>  drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
> > >>  include/media/v4l2-ioctl.h   | 26 ++
> > >>  include/uapi/linux/videodev2.h   |  1 +
> > >>  3 files changed, 54 insertions(+)
> > >> 
> > >> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > >> b/drivers/media/v4l2-core/v4l2-ioctl.c index 0c3f238..ccaf04b 100644
> > >> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > >> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > >> @@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct
> > >> video_device *vdev, unsigned cmd) return vdev->lock;
> > >> 
> > >>  }
> > >> 
> > >> +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> > >> +  struct v4l2_input *i)
> > >> +{
> > >> +if (i->index > 0)
> > >> +return -EINVAL;
> > >> +
> > >> +memset(i, 0, sizeof(*i));
> > >> +i->type = V4L2_INPUT_TYPE_DEFAULT;
> > >> +strlcpy(i->name, "Default", sizeof(i->name));
> > >> +
> > >> +return 0;
> > >> +}
> > >> +EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);  
> > > 
> > > V4L2 tends to use EXPORT_SYMBOL_GPL.  
> > 
> > The whole v4l2-ioctl.c file is using EXPORT_SYMBOL instead of
> > EXPORT_SYMBOL_GPL, should we change it all to EXPORT_SYMBOL_GPL then (in
> > another patch) ?  
> 
> You're right, let's leave it as-is then.

At the time V4L2 was written, there was no EXPORT_SYMBOL_GPL(). That's
why there are some parts that aren't explicit about the symbol usage
license.

For newer symbols, we're using EXPORT_SYMBOL_GPL(), in order to let
clear about the licensing for the code.

Thanks,
Mauro

[Patch v3 01/11] [media] s5p-mfc: Rename IS_MFCV8 macro

[Smitha T Murthy]

This patch renames macro IS_MFCV8 to IS_MFCV8_PLUS so that the MFCv8
code can be resued for MFCv10.10 support. Since the MFCv8 specific code
holds good for MFC v10.10 also.

Signed-off-by: Smitha T Murthy 
Acked-by: Andrzej Hajda 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   |  2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|  2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 18 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index ab23236..b45d18c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -722,7 +722,7 @@ void s5p_mfc_cleanup_queue(struct list_head *lh, struct 
vb2_queue *vq);
 #define IS_TWOPORT(dev)(dev->variant->port_num == 2 ? 1 : 0)
 #define IS_MFCV6_PLUS(dev) (dev->variant->version >= 0x60 ? 1 : 0)
 #define IS_MFCV7_PLUS(dev) (dev->variant->version >= 0x70 ? 1 : 0)
-#define IS_MFCV8(dev)  (dev->variant->version >= 0x80 ? 1 : 0)
+#define IS_MFCV8_PLUS(dev) (dev->variant->version >= 0x80 ? 1 : 0)
 
 #define MFC_V5_BIT BIT(0)
 #define MFC_V6_BIT BIT(1)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index cc88871..484af6b 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -427,7 +427,7 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
s5p_mfc_clear_cmds(dev);
s5p_mfc_clean_dev_int_flags(dev);
/* 3. Send MFC wakeup command and wait for completion*/
-   if (IS_MFCV8(dev))
+   if (IS_MFCV8_PLUS(dev))
ret = s5p_mfc_v8_wait_wakeup(dev);
else
ret = s5p_mfc_wait_wakeup(dev);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 367ef8e..0ec2928 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -1177,7 +1177,7 @@ void s5p_mfc_dec_init(struct s5p_mfc_ctx *ctx)
struct v4l2_format f;
f.fmt.pix_mp.pixelformat = V4L2_PIX_FMT_H264;
ctx->src_fmt = find_format(, MFC_FMT_DEC);
-   if (IS_MFCV8(ctx->dev))
+   if (IS_MFCV8_PLUS(ctx->dev))
f.fmt.pix_mp.pixelformat = V4L2_PIX_FMT_NV12M;
else if (IS_MFCV6_PLUS(ctx->dev))
f.fmt.pix_mp.pixelformat = V4L2_PIX_FMT_NV12MT_16X16;
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 d6f207e..7682b0e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -74,7 +74,7 @@ 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(dev))
+   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);
@@ -89,7 +89,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx 
*ctx)
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_MFCV8(dev))
+   if (IS_MFCV8_PLUS(dev))
ctx->me_buffer_size = ALIGN(S5P_FIMV_ME_BUFFER_SIZE_V8(
ctx->img_width, ctx->img_height,
mb_width, mb_height),
@@ -110,7 +110,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
s5p_mfc_ctx *ctx)
switch (ctx->codec_mode) {
case S5P_MFC_CODEC_H264_DEC:
case S5P_MFC_CODEC_H264_MVC_DEC:
-   if (IS_MFCV8(dev))
+   if (IS_MFCV8_PLUS(dev))
ctx->scratch_buf_size =
S5P_FIMV_SCRATCH_BUF_SIZE_H264_DEC_V8(
mb_width,
@@ -167,7 +167,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
s5p_mfc_ctx *ctx)
ctx->bank1.size = ctx->scratch_buf_size;
break;
case S5P_MFC_CODEC_VP8_DEC:
-   if (IS_MFCV8(dev))
+   if (IS_MFCV8_PLUS(dev))
ctx->scratch_buf_size =
S5P_FIMV_SCRATCH_BUF_SIZE_VP8_DEC_V8(
mb_width,
@@ -182,7 +182,7 @@ static int 

[Patch v3 00/11] Add MFC v10.10 support

[Smitha T Murthy]

This patch series adds MFC v10.10 support. MFC v10.10 is used in some
of Exynos7 variants.

This adds support for following:

* Add support for HEVC encoder and decoder
* Add support for VP9 decoder
* Update Documentation for control id definitions
* Update computation of min scratch buffer size requirement for V8 onwards

Changes since v2:
 - Addressed review comments by Andrzej Hajda.
 - Rebased on latest krzk/for-next tree.
 - This patches are tested on top of Marek's patch v2 [1]
 - Applied acked-by and r-o-b from Andrzej on respective patches.
 - Applied acked-by from Rob Herring on respective patch.

[1]: http://www.mail-archive.com/linux-media@vger.kernel.org/msg108520.html

Smitha T Murthy (11):
  [media] s5p-mfc: Rename IS_MFCV8 macro
  [media] s5p-mfc: Adding initial support for MFC v10.10
  [media] s5p-mfc: Use min scratch buffer size as provided by F/W
  [media] s5p-mfc: Support MFCv10.10 buffer requirements
  [media] videodev2.h: Add v4l2 definition for HEVC
  [media] s5p-mfc: Add support for HEVC decoder
  Documentation: v4l: Documentation for HEVC v4l2 definition
  [media] s5p-mfc: Add VP9 decoder support
  [media] v4l2: Add v4l2 control IDs for HEVC encoder
  [media] s5p-mfc: Add support for HEVC encoder
  Documention: v4l: Documentation for HEVC CIDs

 .../devicetree/bindings/media/s5p-mfc.txt  |   1 +
 Documentation/media/uapi/v4l/extended-controls.rst | 355 
 Documentation/media/uapi/v4l/pixfmt-013.rst|   5 +
 drivers/media/platform/s5p-mfc/regs-mfc-v10.h  |  88 +++
 drivers/media/platform/s5p-mfc/regs-mfc-v8.h   |   2 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c   |  33 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c|   9 +
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h|  71 ++-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |   6 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |  50 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   | 616 -
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h   |  14 +
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c| 410 --
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|  15 +
 drivers/media/v4l2-core/v4l2-ctrls.c   | 103 
 include/uapi/linux/v4l2-controls.h | 133 +
 include/uapi/linux/videodev2.h |   1 +
 17 files changed, 1835 insertions(+), 77 deletions(-)
 create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h

-- 
2.7.4

[Patch v3 03/11] [media] s5p-mfc: Use min scratch buffer size as provided by F/W

[Smitha T Murthy]

After MFC v8.0, mfc f/w lets the driver know how much scratch buffer
size is required for decoder. If mfc f/w has the functionality,
E_MIN_SCRATCH_BUFFER_SIZE, driver can know how much scratch buffer size
is required for encoder too.

Signed-off-by: Smitha T Murthy 
Reviewed-by: Andrzej Hajda 
---
 drivers/media/platform/s5p-mfc/regs-mfc-v8.h|  2 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c|  2 +
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  5 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|  4 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 68 ++---
 6 files changed, 65 insertions(+), 17 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h 
b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
index 4d1c375..2cd396b 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
@@ -17,6 +17,7 @@
 
 /* Additional registers for v8 */
 #define S5P_FIMV_D_MVC_NUM_VIEWS_V80xf104
+#define S5P_FIMV_D_MIN_SCRATCH_BUFFER_SIZE_V8  0xf108
 #define S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8 0xf144
 #define S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V80xf148
 #define S5P_FIMV_D_MV_BUFFER_SIZE_V8   0xf150
@@ -84,6 +85,7 @@
 
 #define S5P_FIMV_E_VBV_BUFFER_SIZE_V8  0xf78c
 #define S5P_FIMV_E_VBV_INIT_DELAY_V8   0xf790
+#define S5P_FIMV_E_MIN_SCRATCH_BUFFER_SIZE_V8   0xf894
 
 #define S5P_FIMV_E_ASPECT_RATIO_V8 0xfb4c
 #define S5P_FIMV_E_EXTENDED_SAR_V8 0xfb50
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 443ff7e..399c547 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -520,6 +520,8 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx *ctx,
dev);
ctx->mv_count = s5p_mfc_hw_call(dev->mfc_ops, get_mv_count,
dev);
+   ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
+   get_min_scratch_buf_size, dev);
if (ctx->img_width == 0 || ctx->img_height == 0)
ctx->state = MFCINST_ERROR;
else
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 3a4ca55..8368d5c2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -724,6 +724,7 @@ void s5p_mfc_cleanup_queue(struct list_head *lh, struct 
vb2_queue *vq);
 #define IS_MFCV7_PLUS(dev) (dev->variant->version >= 0x70 ? 1 : 0)
 #define IS_MFCV8_PLUS(dev) (dev->variant->version >= 0x80 ? 1 : 0)
 #define IS_MFCV10(dev) (dev->variant->version >= 0xA0 ? 1 : 0)
+#define FW_HAS_E_MIN_SCRATCH_BUF(dev) (IS_MFCV10(dev))
 
 #define MFC_V5_BIT BIT(0)
 #define MFC_V6_BIT BIT(1)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index e81b359..57a40c0 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -813,6 +813,11 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
get_enc_dpb_count, dev);
if (ctx->pb_count < enc_pb_count)
ctx->pb_count = enc_pb_count;
+   if (FW_HAS_E_MIN_SCRATCH_BUF(dev)) {
+   ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
+   get_e_min_scratch_buf_size, dev);
+   ctx->bank1.size += ctx->scratch_buf_size;
+   }
ctx->state = MFCINST_HEAD_PRODUCED;
}
 
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
index b6ac417..6478f70 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
@@ -169,6 +169,7 @@ struct s5p_mfc_regs {
void __iomem *d_decoded_third_addr;/* only v7 */
void __iomem *d_used_dpb_flag_upper;/* v7 and v8 */
void __iomem *d_used_dpb_flag_lower;/* v7 and v8 */
+   void __iomem *d_min_scratch_buffer_size; /* v10 */
 
/* encoder registers */
void __iomem *e_frame_width;
@@ -268,6 +269,7 @@ struct s5p_mfc_regs {
void __iomem *e_vp8_hierarchical_qp_layer0;/* v7 and v8 */
void __iomem *e_vp8_hierarchical_qp_layer1;/* v7 and v8 */
void __iomem *e_vp8_hierarchical_qp_layer2;/* v7 and v8 */
+   void __iomem *e_min_scratch_buffer_size; /* v10 */
 };
 
 struct s5p_mfc_hw_ops {
@@ -311,6 +313,8 @@ struct s5p_mfc_hw_ops {
unsigned int (*get_pic_type_bot)(struct s5p_mfc_ctx *ctx);
unsigned int (*get_crop_info_h)(struct s5p_mfc_ctx *ctx);
unsigned int 

[Patch v3 02/11] [media] s5p-mfc: Adding initial support for MFC v10.10

[Smitha T Murthy]

Adding the support for MFC v10.10, with new register file and
necessary hw control, decoder, encoder and structural changes.

CC: Rob Herring 
CC: devicet...@vger.kernel.org
Signed-off-by: Smitha T Murthy 
Reviewed-by: Andrzej Hajda 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/s5p-mfc.txt  |  1 +
 drivers/media/platform/s5p-mfc/regs-mfc-v10.h  | 36 ++
 drivers/media/platform/s5p-mfc/s5p_mfc.c   | 30 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h|  9 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |  4 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   | 32 ---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   | 16 --
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c|  9 --
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|  2 ++
 9 files changed, 106 insertions(+), 33 deletions(-)
 create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h

diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 2c90128..b83727b 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -13,6 +13,7 @@ Required properties:
(c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
(d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
(e) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC
+   (f) "samsung,mfc-v10" for MFC v10 present in Exynos7880 SoC
 
   - reg : Physical base address of the IP registers and length of memory
  mapped region.
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
new file mode 100644
index 000..1ca09d6
--- /dev/null
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
@@ -0,0 +1,36 @@
+/*
+ * Register definition file for Samsung MFC V10.x Interface (FIMV) driver
+ *
+ * Copyright (c) 2017 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _REGS_MFC_V10_H
+#define _REGS_MFC_V10_H
+
+#include 
+#include "regs-mfc-v8.h"
+
+/* MFCv10 register definitions*/
+#define S5P_FIMV_MFC_CLOCK_OFF_V10 0x7120
+#define S5P_FIMV_MFC_STATE_V10 0x7124
+
+/* MFCv10 Context buffer sizes */
+#define MFC_CTX_BUF_SIZE_V10   (30 * SZ_1K)
+#define MFC_H264_DEC_CTX_BUF_SIZE_V10  (2 * SZ_1M)
+#define MFC_OTHER_DEC_CTX_BUF_SIZE_V10 (20 * SZ_1K)
+#define MFC_H264_ENC_CTX_BUF_SIZE_V10  (100 * SZ_1K)
+#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K)
+
+/* MFCv10 variant defines */
+#define MAX_FW_SIZE_V10(SZ_1M)
+#define MAX_CPB_SIZE_V10   (3 * SZ_1M)
+#define MFC_VERSION_V100xA0
+#define MFC_NUM_PORTS_V10  1
+
+#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 c6f0754..443ff7e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1547,6 +1547,33 @@ static struct s5p_mfc_variant mfc_drvdata_v8_5433 = {
.num_clocks = 3,
 };
 
+static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
+   .dev_ctx= MFC_CTX_BUF_SIZE_V10,
+   .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,
+   .other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
+};
+
+static struct s5p_mfc_buf_size buf_size_v10 = {
+   .fw = MAX_FW_SIZE_V10,
+   .cpb= MAX_CPB_SIZE_V10,
+   .priv   = _buf_size_v10,
+};
+
+static struct s5p_mfc_buf_align mfc_buf_align_v10 = {
+   .base = 0,
+};
+
+static struct s5p_mfc_variant mfc_drvdata_v10 = {
+   .version= MFC_VERSION_V10,
+   .version_bit= MFC_V10_BIT,
+   .port_num   = MFC_NUM_PORTS_V10,
+   .buf_size   = _size_v10,
+   .buf_align  = _buf_align_v10,
+   .fw_name[0] = "s5p-mfc-v10.fw",
+};
+
 static const struct of_device_id exynos_mfc_match[] = {
{
.compatible = "samsung,mfc-v5",
@@ -1563,6 +1590,9 @@ static const struct of_device_id exynos_mfc_match[] = {
}, {
.compatible = "samsung,exynos5433-mfc",
.data = _drvdata_v8_5433,
+   }, {
+   .compatible = "samsung,mfc-v10",
+   .data = _drvdata_v10,
},
{},
 };
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index b45d18c..3a4ca55 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ 

[Patch v3 06/11] [media] s5p-mfc: Add support for HEVC decoder

[Smitha T Murthy]

Add support for codec definition and corresponding buffer
requirements for HEVC decoder.

Signed-off-by: Smitha T Murthy 
Reviewed-by: Andrzej Hajda 
---
 drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |  1 +
 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 | 17 +++--
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |  3 +++
 6 files changed, 31 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 3f0dab3..953a073 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
@@ -33,6 +33,7 @@
 #define MFC_NUM_PORTS_V10  1
 
 /* MFCv10 codec defines*/
+#define S5P_FIMV_CODEC_HEVC_DEC17
 #define S5P_FIMV_CODEC_HEVC_ENC 26
 
 /* Encoder buffer size for MFC v10.0 */
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 8368d5c2..f49fa34 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -79,6 +79,7 @@ static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void *b)
 #define S5P_MFC_CODEC_H263_DEC 5
 #define S5P_MFC_CODEC_VC1RCV_DEC   6
 #define S5P_MFC_CODEC_VP8_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 db6d9fa..4fdaec2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -144,6 +144,14 @@ static struct s5p_mfc_fmt formats[] = {
.num_planes = 1,
.versions   = MFC_V6PLUS_BITS,
},
+   {
+   .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 cb39484..033d655 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,12 @@ 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->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 +328,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:
@@ -436,6 +443,10 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct 
s5p_mfc_ctx *ctx)
ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V6(ctx->img_width,
ctx->img_height);
}
+   } else if (ctx->codec_mode == S5P_MFC_CODEC_HEVC_DEC) {
+   ctx->mv_size = s5p_mfc_dec_hevc_mv_size(ctx->img_width,
+   ctx->img_height);
+   ctx->mv_size = ALIGN(ctx->mv_size, 32);
} else {
ctx->mv_size = 0;
}
@@ -517,7 +528,8 @@ static int s5p_mfc_set_dec_frame_buffer_v6(struct 
s5p_mfc_ctx *ctx)

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Hans Verkuil]

On 31/03/17 10:41, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Friday 31 Mar 2017 10:29:04 Hans Verkuil wrote:
>> On 30/03/17 18:02, Helen Koike wrote:
>>> Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
>>> used when no inputs are available in the device
>>>
>>> Signed-off-by: Helen Koike 
>>> ---
>>>
>>>  drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
>>>  include/media/v4l2-ioctl.h   | 26 ++
>>>  include/uapi/linux/videodev2.h   |  1 +
>>>  3 files changed, 54 insertions(+)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> b/drivers/media/v4l2-core/v4l2-ioctl.c index 0c3f238..ccaf04b 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> @@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct
>>> video_device *vdev, unsigned cmd)> 
>>> return vdev->lock;
>>>  
>>>  }
>>>
>>> +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
>>> + struct v4l2_input *i)
>>> +{
>>> +   if (i->index > 0)
>>> +   return -EINVAL;
>>> +
>>> +   memset(i, 0, sizeof(*i));
>>> +   i->type = V4L2_INPUT_TYPE_DEFAULT;
>>> +   strlcpy(i->name, "Default", sizeof(i->name));
>>> +
>>> +   return 0;
>>> +}
>>> +EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);
>>> +
>>> +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned
>>> int *i)
>>> +{
>>> +   *i = 0;
>>> +   return 0;
>>> +}
>>> +EXPORT_SYMBOL(v4l2_ioctl_g_input_default);
>>> +
>>> +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned
>>> int i)
>>> +{
>>> +   return i ? -EINVAL : 0;
>>> +}
>>> +EXPORT_SYMBOL(v4l2_ioctl_s_input_default);
>>> +
>>>  /* Common ioctl debug function. This function can be used by
>>> external ioctl messages as well as internal V4L ioctl */
>>>  void v4l_printk_ioctl(const char *prefix, unsigned int cmd)
>>> diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
>>> index 6cd94e5..accc470 100644
>>> --- a/include/media/v4l2-ioctl.h
>>> +++ b/include/media/v4l2-ioctl.h
>>> @@ -652,6 +652,32 @@ struct video_device;
>>>   */
>>>  
>>>  struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev, unsigned int
>>>  cmd);
>>> +
>>> +/**
>>> + * v4l2_ioctl_enum_input_default - v4l2 ioctl helper for
>>> VIDIOC_ENUM_INPUT ioctl + *
>>> + * Plug this function in vidioc_enum_input field of the struct
>>> v4l2_ioctl_ops to + * enumerate a single input as V4L2_INPUT_TYPE_DEFAULT
>>> + */
>>> +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
>>> + struct v4l2_input *i);
>>> +
>>> +/**
>>> + * v4l2_ioctl_g_input_default - v4l2 ioctl helper for VIDIOC_G_INPUT
>>> ioctl
>>> + *
>>> + * Plug this function in vidioc_g_input field of the struct
>>> v4l2_ioctl_ops
>>> + * when using v4l2_ioctl_enum_input_default
>>> + */
>>> +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned
>>> int *i); +
>>> +/**
>>> + * v4l2_ioctl_s_input_default - v4l2 ioctl helper for VIDIOC_S_INPUT
>>> ioctl
>>> + *
>>> + * Plug this function in vidioc_s_input field of the struct
>>> v4l2_ioctl_ops
>>> + * when using v4l2_ioctl_enum_input_default
>>> + */
>>> +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned
>>> int i); +
>>>
>>>  /* names for fancy debug output */
>>>  extern const char *v4l2_field_names[];
>>>  extern const char *v4l2_type_names[];
>>>
>>> diff --git a/include/uapi/linux/videodev2.h
>>> b/include/uapi/linux/videodev2.h index 316be62..c10bbde 100644
>>> --- a/include/uapi/linux/videodev2.h
>>> +++ b/include/uapi/linux/videodev2.h
>>> @@ -1477,6 +1477,7 @@ struct v4l2_input {
>>>
>>>  };
>>>  
>>>  /*  Values for the 'type' field */
>>>
>>> +#define V4L2_INPUT_TYPE_DEFAULT0
>>
>> I don't think we should add a new type here. The whole point of this
>> exercise is to allow existing apps to work, and existing apps expect a
>> TYPE_CAMERA.
>>
>> BTW, don't read to much in the term 'CAMERA': it's really a catch all for
>> any video stream, whether it is from a sensor, composite input, HDMI, etc.
>>
>> The description for V4L2_INPUT_TYPE_CAMERA in the spec is hopelessly out of
>> date :-(
>>
>> Rather than creating a new type I would add a new V4L2_IN_CAP_MC capability
>> that indicates that this input is controlled via the media controller. That
>> makes much more sense and it wouldn't potentially break applications.
>>
>> Exactly the same can be done for outputs as well: add V4L2_OUT_CAP_MC and
>> use V4L2_OUTPUT_TYPE_ANALOG as the output type (again, a horrible outdated
>> name and the spec is again out of date).
> 
> What would those capabilities be used for ? Applications can already know 
> whether the MC API is used by a driver. Furthermore, if we really need such a 
> flag, I wouldn't add it at the input/output level but as a video node 
> capability flag.

I have no objection to adding a V4L2_CAP_MC 

[Patch v3 05/11] [media] videodev2.h: Add v4l2 definition for HEVC

[Smitha T Murthy]

Add V4L2 definition for HEVC compressed format

Signed-off-by: Smitha T Murthy 
Reviewed-by: Andrzej Hajda 
---
 include/uapi/linux/videodev2.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 45184a2..38cf5f1 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -629,6 +629,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 */
 
 /*  Vendor-specific formats   */
 #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
-- 
2.7.4

[Patch v3 04/11] [media] s5p-mfc: Support MFCv10.10 buffer requirements

[Smitha T Murthy]

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   | 19 +
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 95 +++--
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |  2 +
 3 files changed, 95 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 1ca09d6..3f0dab3 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
@@ -32,5 +32,24 @@
 #define MFC_VERSION_V100xA0
 #define MFC_NUM_PORTS_V10  1
 
+/* MFCv10 codec defines*/
+#define S5P_FIMV_CODEC_HEVC_ENC 26
+
+/* Encoder buffer size for MFC v10.0 */
+#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 5f0da0b..cb39484 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 =
+   ALIGN((mb_width * 16), 64)
+   * ALIGN((mb_height * 16), 32)
+   + 64;
+   ctx->chroma_dpb_size =
+   ALIGN((mb_width * 16), 64)
+   * (mb_height * 8)
+   + 64;
+   } else {
+   ctx->luma_dpb_size =
+   ALIGN((lcu_width * 32), 64)
+   * ALIGN((lcu_height * 32), 32)
+   + 64;
+   ctx->chroma_dpb_size =
+   ALIGN((lcu_width * 32), 64)
+   * (lcu_height * 16)
+   + 64;
+   }
+   } else {
+   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,
+   

[Patch v3 09/11] [media] v4l2: Add v4l2 control IDs for HEVC encoder

[Smitha T Murthy]

Add v4l2 controls for HEVC encoder

Signed-off-by: Smitha T Murthy 
Reviewed-by: Andrzej Hajda 
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 103 +++
 include/uapi/linux/v4l2-controls.h   | 133 +++
 2 files changed, 236 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b9e08e3..5fa763b 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -479,6 +479,46 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
NULL,
};
 
+   static const char * const hevc_profile[] = {
+   "Main",
+   "Main still picture",
+   NULL,
+   };
+   static const char * const hevc_level[] = {
+   "1",
+   "2",
+   "2.1",
+   "3",
+   "3.1",
+   "4",
+   "4.1",
+   "5",
+   "5.1",
+   "5.2",
+   "6",
+   "6.1",
+   "6.2",
+   NULL,
+   };
+   static const char * const hevc_hierarchial_coding_type[] = {
+   "B",
+   "P",
+   NULL,
+   };
+   static const char * const hevc_refresh_type[] = {
+   "None",
+   "CRA",
+   "IDR",
+   NULL,
+   };
+   static const char * const hevc_size_of_length_field[] = {
+   "0",
+   "1",
+   "2",
+   "4",
+   NULL,
+   };
+
 
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -574,6 +614,16 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return dv_it_content_type;
case V4L2_CID_DETECT_MD_MODE:
return detect_md_mode;
+   case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
+   return hevc_profile;
+   case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
+   return hevc_level;
+   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_TYPE:
+   return hevc_hierarchial_coding_type;
+   case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE:
+   return hevc_refresh_type;
+   case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:
+   return hevc_size_of_length_field;
 
default:
return NULL;
@@ -775,6 +825,54 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX 
P-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:   return "VPX 
Profile";
 
+   /* HEVC controls */
+   case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:   return "HEVC I 
frame QP value";
+   case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP:   return "HEVC P 
frame QP value";
+   case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP:   return "HEVC B 
frame QP value";
+   case V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP:   return "HEVC 
Minimum QP value";
+   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP:   return "HEVC 
Maximum QP value";
+   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_DARK: return "HEVC 
Dark reg adaptive rc";
+   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_SMOOTH:   return "HEVC 
Smooth reg adaptive rc";
+   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_STATIC:   return "HEVC 
Static reg adaptive rc";
+   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_ACTIVITY: return "HEVC 
activity reg adaptive rc";
+   case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:  return "HEVC 
Profile";
+   case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:return "HEVC 
Level";
+   case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:return "HEVC 
tier_flag";
+   case V4L2_CID_MPEG_VIDEO_HEVC_FRAME_RATE_RESOLUTION:return "HEVC 
Frame rate resolution";
+   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH:  return "HEVC 
Maximum coding unit depth";
+   case V4L2_CID_MPEG_VIDEO_HEVC_REF_NUMBER_FOR_PFRAMES:   return "HEVC 
Number of reference frames";
+   case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE: return "HEVC 
Refresh type";
+   case V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED: return "HEVC 
Constant intra prediction";
+   case V4L2_CID_MPEG_VIDEO_HEVC_LOSSLESS_CU:  return "HEVC 
Lossless encoding";
+   case V4L2_CID_MPEG_VIDEO_HEVC_WAVEFRONT:return "HEVC 
Wavefront";
+   case V4L2_CID_MPEG_VIDEO_HEVC_LF:   return "HEVC 
Loop filter";
+   case V4L2_CID_MPEG_VIDEO_HEVC_LF_SLICE_BOUNDARY:return "HEVC LF 
across slice boundary or not";
+   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_QP:  return "HEVC QP 
values";
+   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_TYPE: return "HEVC 
Hierarchical Coding Type";
+   case 

[Patch v3 08/11] [media] s5p-mfc: Add VP9 decoder support

[Smitha T Murthy]

Add support for codec definition and corresponding buffer
requirements for VP9 decoder.

Signed-off-by: Smitha T Murthy 
Reviewed-by: Andrzej Hajda 
---
 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 | 27 +
 6 files changed, 47 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
index 953a073..6754477 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_V10  0xF570
+#define S5P_FIMV_D_STATIC_BUFFER_SIZE_V10  0xF574
 
 /* MFCv10 Context buffer sizes */
 #define MFC_CTX_BUF_SIZE_V10   (30 * SZ_1K)
@@ -34,8 +36,12 @@
 
 /* MFCv10 codec defines*/
 #define S5P_FIMV_CODEC_HEVC_DEC17
+#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
+
 /* Encoder buffer size for MFC v10.0 */
 #define ENC_V100_BASE_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 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 f49fa34..4082079 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_DEC  7
 #define S5P_MFC_CODEC_HEVC_DEC 17
+#define S5P_MFC_CODEC_VP9_DEC  18
 
 #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 4fdaec2..8e2f477 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -152,6 +152,14 @@ static struct s5p_mfc_fmt formats[] = {
.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 033d655..ae5b871 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -226,6 +226,12 @@ 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->bank1.size =
+   ctx->scratch_buf_size +
+   DEC_VP9_STATIC_BUFFER_SIZE;
+  

[Patch v3 10/11] [media] s5p-mfc: Add support for HEVC encoder

[Smitha T Murthy]

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 |  57 ++-
 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 | 194 
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |   8 +
 8 files changed, 892 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 6754477..7065b9d 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_V10  0xF570
 #define S5P_FIMV_D_STATIC_BUFFER_SIZE_V10  0xF574
+#define S5P_FIMV_E_NUM_T_LAYER_V10 0xFBAC
+#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER0_V10  0xFBB0
+#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER1_V10  0xFBB4
+#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER2_V10  0xFBB8
+#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER3_V10  0xFBBC
+#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER4_V10  0xFBC0
+#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER5_V10  0xFBC4
+#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER6_V10  0xFBC8
+#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER0_V100xFD18
+#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER1_V100xFD1C
+#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER2_V100xFD20
+#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER3_V100xFD24
+#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER4_V100xFD28
+#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER5_V100xFD2C
+#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER6_V100xFD30
+#define S5P_FIMV_E_HEVC_OPTIONS_V100xFDD4
+#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_V100xFDE0
+#define S5P_FIMV_E_HEVC_LF_TC_OFFSET_DIV2_V10  0xFDE4
+#define S5P_FIMV_E_HEVC_NAL_CONTROL_V100xFDE8
 
 /* MFCv10 Context buffer sizes */
 #define MFC_CTX_BUF_SIZE_V10   (30 * SZ_1K)
 #define MFC_H264_DEC_CTX_BUF_SIZE_V10  (2 * SZ_1M)
 #define MFC_OTHER_DEC_CTX_BUF_SIZE_V10 (20 * SZ_1K)
 #define MFC_H264_ENC_CTX_BUF_SIZE_V10  (100 * SZ_1K)
-#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K)
+#define MFC_HEVC_ENC_CTX_BUF_SIZE_V10  (30 * SZ_1K)
+#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10  (15 * SZ_1K)
 
 /* MFCv10 variant defines */
 #define MAX_FW_SIZE_V10(SZ_1M)
@@ -58,5 +80,9 @@
 #define ENC_V100_VP8_ME_SIZE(x, y) \
ENC_V100_BASE_SIZE(x, y)
 
+#define ENC_V100_HEVC_ME_SIZE(x, y)\
+   (((x + 3) * (y + 3) * 32)   \
++ ((y * 128) + 1280) * DIV_ROUND_UP(x, 4))
+
 #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 399c547..b3862d1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1554,6 +1554,7 @@ static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
.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 S5P_MFC_CODEC_HEVC_ENC:
+   codec_type = S5P_FIMV_CODEC_HEVC_ENC;
+   break;
default:
codec_type = S5P_FIMV_CODEC_NONE_V6;
}
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 4082079..ad06e45 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -68,7 +68,7 @@ static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void *b)
 #define MFC_ENC_CAP_PLANE_COUNT1
 #define MFC_ENC_OUT_PLANE_COUNT2
 #define STUFF_BYTE 4
-#define MFC_MAX_CTRLS  77
+#define MFC_MAX_CTRLS  128
 
 #define 

[Patch v3 11/11] Documention: v4l: Documentation for HEVC CIDs

[Smitha T Murthy]

Added V4l2 controls for HEVC encoder

Signed-off-by: Smitha T Murthy 
---
 Documentation/media/uapi/v4l/extended-controls.rst | 355 +
 1 file changed, 355 insertions(+)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index abb1057..c2f3c5e 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1960,6 +1960,361 @@ enum v4l2_vp8_golden_frame_sel -
 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
 
 
+HEVC Control Reference
+-
+
+The HEVC controls include controls for encoding parameters of HEVC video
+codec.
+
+
+.. _hevc-control-id:
+
+HEVC Control IDs
+^^^
+
+``V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP``
+Minimum quantization parameter for HEVC.
+
+``V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP``
+Maximum quantization parameter for HEVC.
+
+``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP``
+Quantization parameter for an I frame for HEVC.
+
+``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP``
+Quantization parameter for a P frame for HEVC.
+
+``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP``
+Quantization parameter for a B frame for HEVC.
+
+``V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_QP``
+HIERARCHICAL_QP allows host to specify the quantization parameter values
+for each temporal layer through HIERARCHICAL_QP_LAYER. This is valid only
+if HIERARCHICAL_CODING_LAYER is greater than 1.
+
+.. _v4l2-hevc-hierarchical-coding-type:
+
+``V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_TYPE``
+(enum)
+
+enum v4l2_mpeg_video_hevc_hier_coding_type -
+Selects the hierarchical coding type for encoding. Possible values are:
+
+.. raw:: latex
+
+\begin{adjustbox}{width=\columnwidth}
+
+.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_B``
+  - Use the B frame for hierarchical coding.
+* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_P``
+  - Use the P frame for hierarchical coding.
+
+.. raw:: latex
+
+\end{adjustbox}
+
+
+``V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER``
+Selects the hierarchical coding layer. In normal encoding
+(non-hierarchial coding), it should be zero. Possible values are 0 ~ 6.
+0 indicates HIERARCHICAL CODING LAYER 0, 1 indicates HIERARCHICAL CODING
+LAYER 1 and so on.
+
+``V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_QP``
+Indicates the hierarchical coding layer quantization parameter.
+For HEVC it can have a value of 0-51. Hence in the control value passed
+the LSB 16 bits will indicate the quantization parameter. The MSB 16 bit
+will pass the layer(0-6) it is meant for.
+
+.. _v4l2-hevc-profile:
+
+``V4L2_CID_MPEG_VIDEO_HEVC_PROFILE``
+(enum)
+
+enum v4l2_mpeg_video_hevc_profile -
+Select the desired profile for HEVC encoder.
+
+.. raw:: latex
+
+\begin{adjustbox}{width=\columnwidth}
+
+.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN``
+  - Main profile.
+* - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE``
+  - Main still picture profile.
+
+.. raw:: latex
+
+\end{adjustbox}
+
+
+.. _v4l2-hevc-level:
+
+``V4L2_CID_MPEG_VIDEO_HEVC_LEVEL``
+(enum)
+
+enum v4l2_mpeg_video_hevc_level -
+Select the desired level for HEVC encoder.
+
+.. raw:: latex
+
+\begin{adjustbox}{width=\columnwidth}
+
+.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
+
+.. flat-table::
+   :header-rows:  0
+:stub-columns: 0
+
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_1``
+  - Level 1.0
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_2``
+  - Level 2.0
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_2_1``
+  - Level 2.1
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_3``
+  - Level 3.0
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_3_1``
+  - Level 3.1
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_4``
+  - Level 4.0
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_4_1``
+  - Level 4.1
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_5``
+  - Level 5.0
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_5_1``
+  - Level 5.1
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_5_2``
+  - Level 5.2
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_6``
+  - Level 6.0
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_6_1``
+  - Level 6.1
+* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_6_2``
+  - Level 6.2
+
+.. raw:: latex
+
+\end{adjustbox}
+
+
+``V4L2_CID_MPEG_VIDEO_HEVC_FRAME_RATE_RESOLUTION``
+Indicates the number of evenly spaced subintervals, called ticks, within
+one modulo time. One modulo time represents the fixed interval of one
+second. This is a 16bit unsigned integer and has a maximum value upto
+0x.
+
+``V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG``
+TIER_FLAG specifies tier information of the HEVC encoded picture. Tier were
+made to deal with applications 

[Patch v3 07/11] Documentation: v4l: Documentation for HEVC v4l2 definition

[Smitha T Murthy]

Add V4L2 definition for HEVC compressed format

Signed-off-by: Smitha T Murthy 
Reviewed-by: Andrzej Hajda 
---
 Documentation/media/uapi/v4l/pixfmt-013.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/media/uapi/v4l/pixfmt-013.rst 
b/Documentation/media/uapi/v4l/pixfmt-013.rst
index 728d7ed..ff4cac2 100644
--- a/Documentation/media/uapi/v4l/pixfmt-013.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-013.rst
@@ -90,3 +90,8 @@ Compressed Formats
   - ``V4L2_PIX_FMT_VP9``
   - 'VP90'
   - VP9 video elementary stream.
+* .. _V4L2-PIX-FMT-HEVC:
+
+  - ``V4L2_PIX_FMT_HEVC``
+  - 'HEVC'
+  - HEVC video elementary stream.
-- 
2.7.4

Re: [PATCH 3/3] [media] cobalt: Use v4l2_calc_timeperframe helper

[Jose Abreu]

Hi Hans,


On 30-03-2017 14:42, Hans Verkuil wrote:
> Hi Jose,
>
> On 21/03/17 12:49, Jose Abreu wrote:
>> Currently, cobalt driver always returns 60fps in g_parm.
>> This patch uses the new v4l2_calc_timeperframe helper to
>> calculate the time per frame value.
> I can verify that g_parm works, so:
>
> Tested-by: Hans Verkuil 
>
> However, the adv7604 pixelclock detection resolution is only 0.25 MHz, so it
> can't tell the difference between 24 and 23.97 Hz. I can't set the new
> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS flag there.
>
> It might be possible to implement this for the adv7842 receiver, I think that
> that hardware is much more precise.
>
> I would have to try this, but that will have to wait until Friday next week.

Thanks! Yes, maybe its better to test with a different receiver,
if it has more precision then its great. Let me know if you need
any help :)

Best regards,
Jose Miguel Abreu

>
> Regards,
>
>   Hans
>
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: Mauro Carvalho Chehab 
>> Cc: Hans Verkuil 
>> Cc: linux-media@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org
>> ---
>>  drivers/media/pci/cobalt/cobalt-v4l2.c | 9 +++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/pci/cobalt/cobalt-v4l2.c 
>> b/drivers/media/pci/cobalt/cobalt-v4l2.c
>> index def4a3b..25532ae 100644
>> --- a/drivers/media/pci/cobalt/cobalt-v4l2.c
>> +++ b/drivers/media/pci/cobalt/cobalt-v4l2.c
>> @@ -1076,10 +1076,15 @@ static int cobalt_subscribe_event(struct v4l2_fh *fh,
>>  
>>  static int cobalt_g_parm(struct file *file, void *fh, struct 
>> v4l2_streamparm *a)
>>  {
>> +struct cobalt_stream *s = video_drvdata(file);
>> +struct v4l2_fract fps;
>> +
>>  if (a->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
>>  return -EINVAL;
>> -a->parm.capture.timeperframe.numerator = 1;
>> -a->parm.capture.timeperframe.denominator = 60;
>> +
>> +fps = v4l2_calc_timeperframe(>timings);
>> +a->parm.capture.timeperframe.numerator = fps.numerator;
>> +a->parm.capture.timeperframe.denominator = fps.denominator;
>>  a->parm.capture.readbuffers = 3;
>>  return 0;
>>  }
>>

[PATCH] vidioc-enumin/output.rst: improve documentation

[Hans Verkuil]

The V4L2_INPUT_TYPE_CAMERA and V4L2_OUTPUT_TYPE_ANALOG descriptions were
hopelessly out of date. Fix this, and also fix a few style issues in these
documents. Finally add the missing documentation for 
V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY
(only used by the zoran driver).

Signed-off-by: Hans Verkuil 
---
Question: should we perhaps add _TYPE_VIDEO aliases?
---
diff --git a/Documentation/media/uapi/v4l/vidioc-enuminput.rst 
b/Documentation/media/uapi/v4l/vidioc-enuminput.rst
index 17aaaf939757..266e48ab237f 100644
--- a/Documentation/media/uapi/v4l/vidioc-enuminput.rst
+++ b/Documentation/media/uapi/v4l/vidioc-enuminput.rst
@@ -33,7 +33,7 @@ Description

 To query the attributes of a video input applications initialize the
 ``index`` field of struct :c:type:`v4l2_input` and call the
-:ref:`VIDIOC_ENUMINPUT` ioctl with a pointer to this structure. Drivers
+:ref:`VIDIOC_ENUMINPUT` with a pointer to this structure. Drivers
 fill the rest of the structure or return an ``EINVAL`` error code when the
 index is out of bounds. To enumerate all inputs applications shall begin
 at index zero, incrementing by one until the driver returns ``EINVAL``.
@@ -117,8 +117,9 @@ at index zero, incrementing by one until the driver returns 
``EINVAL``.
   - This input uses a tuner (RF demodulator).
 * - ``V4L2_INPUT_TYPE_CAMERA``
   - 2
-  - Analog baseband input, for example CVBS / Composite Video,
-   S-Video, RGB.
+  - Any non-tuner video input, for example Composite Video,
+   S-Video, HDMI, camera sensor. The naming as ``_TYPE_CAMERA`` is 
historical,
+   today we would have called it ``_TYPE_VIDEO``.
 * - ``V4L2_INPUT_TYPE_TOUCH``
   - 3
   - This input is a touch device for capturing raw touch data.
@@ -209,11 +210,11 @@ at index zero, incrementing by one until the driver 
returns ``EINVAL``.
 * - ``V4L2_IN_CAP_DV_TIMINGS``
   - 0x0002
   - This input supports setting video timings by using
-   VIDIOC_S_DV_TIMINGS.
+   ``VIDIOC_S_DV_TIMINGS``.
 * - ``V4L2_IN_CAP_STD``
   - 0x0004
   - This input supports setting the TV standard by using
-   VIDIOC_S_STD.
+   ``VIDIOC_S_STD``.
 * - ``V4L2_IN_CAP_NATIVE_SIZE``
   - 0x0008
   - This input supports setting the native size using the
diff --git a/Documentation/media/uapi/v4l/vidioc-enumoutput.rst 
b/Documentation/media/uapi/v4l/vidioc-enumoutput.rst
index d7dd2742475a..93a2cf3b310c 100644
--- a/Documentation/media/uapi/v4l/vidioc-enumoutput.rst
+++ b/Documentation/media/uapi/v4l/vidioc-enumoutput.rst
@@ -33,11 +33,11 @@ Description

 To query the attributes of a video outputs applications initialize the
 ``index`` field of struct :c:type:`v4l2_output` and call
-the :ref:`VIDIOC_ENUMOUTPUT` ioctl with a pointer to this structure.
+the :ref:`VIDIOC_ENUMOUTPUT` with a pointer to this structure.
 Drivers fill the rest of the structure or return an ``EINVAL`` error code
 when the index is out of bounds. To enumerate all outputs applications
 shall begin at index zero, incrementing by one until the driver returns
-EINVAL.
+``EINVAL``.


 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
@@ -112,11 +112,12 @@ EINVAL.
   - This output is an analog TV modulator.
 * - ``V4L2_OUTPUT_TYPE_ANALOG``
   - 2
-  - Analog baseband output, for example Composite / CVBS, S-Video,
-   RGB.
+  - Any non-modulator video output, for example Composite Video,
+   S-Video, HDMI. The naming as ``_TYPE_ANALOG`` is historical,
+   today we would have called it ``_TYPE_VIDEO``.
 * - ``V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY``
   - 3
-  - [?]
+  - The video output will be copied to a :ref:`video overlay `.



@@ -132,11 +133,11 @@ EINVAL.
 * - ``V4L2_OUT_CAP_DV_TIMINGS``
   - 0x0002
   - This output supports setting video timings by using
-   VIDIOC_S_DV_TIMINGS.
+   ``VIDIOC_S_DV_TIMINGS``.
 * - ``V4L2_OUT_CAP_STD``
   - 0x0004
   - This output supports setting the TV standard by using
-   VIDIOC_S_STD.
+   ``VIDIOC_S_STD``.
 * - ``V4L2_OUT_CAP_NATIVE_SIZE``
   - 0x0008
   - This output supports setting the native size using the

Re: [Patch v2 10/11] s5p-mfc: Add support for HEVC encoder

[Smitha T Murthy]

On Tue, 2017-03-28 at 10:15 +0530, Smitha T Murthy wrote:
> On Mon, 2017-03-27 at 14:09 +0200, Andrzej Hajda wrote:
> > Hi Smitha,
> > 
> > Sorry for late reply, it seems I have missed this email.
> > 
> > 
> > On 14.03.2017 12:41, Smitha T Murthy wrote:
> > > On Tue, 2017-03-07 at 12:33 +0100, Andrzej Hajda wrote: 
> > >> On 03.03.2017 10:07, 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 |8 +
> > >>>  8 files changed, 896 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 846dcf5..caf02ff 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_V10  0xF570
> > >>>  #define S5P_FIMV_D_STATIC_BUFFER_SIZE_V10  0xF574
> > >>> +#define S5P_FIMV_E_NUM_T_LAYER_V10 0xFBAC
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER0_V10  0xFBB0
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER1_V10  0xFBB4
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER2_V10  0xFBB8
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER3_V10  0xFBBC
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER4_V10  0xFBC0
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER5_V10  0xFBC4
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER6_V10  0xFBC8
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER0_V100xFD18
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER1_V100xFD1C
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER2_V100xFD20
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER3_V100xFD24
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER4_V100xFD28
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER5_V100xFD2C
> > >>> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER6_V100xFD30
> > >>> +#define S5P_FIMV_E_HEVC_OPTIONS_V100xFDD4
> > >>> +#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_V100xFDE0
> > >>> +#define S5P_FIMV_E_HEVC_LF_TC_OFFSET_DIV2_V10  0xFDE4
> > >>> +#define S5P_FIMV_E_HEVC_NAL_CONTROL_V100xFDE8
> > >>>  
> > >>>  /* 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 */
> > >>> @@ -58,5 +80,9 @@
> > >>>  #define ENC_V100_VP8_ME_SIZE(x, y) \
> > >>> ENC_V100_BASE_SIZE(x, y)
> > >>>  
> > >>> +#define ENC_V100_HEVC_ME_SIZE(x, y)\
> > >>> +   (((x + 3) * (y + 3) * 32)   \
> > >>> ++ ((y * 128) + 1280) * DIV_ROUND_UP(x, 4))
> > >>> +
> > >>>  #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 

Re: [PATCH] [media] docs-rst: clarify field vs frame height in the subdev API

[Philipp Zabel]

Hi Laurent,

On Fri, 2017-03-31 at 11:09 +0300, Laurent Pinchart wrote:
> Hi Philipp,
> 
> Thank you for the patch.
> 
> On Thursday 30 Mar 2017 17:38:20 Philipp Zabel wrote:
> > VIDIOC_SUBDEV_G/S_FMT take the field size if V4L2_FIELD_ALTERNATE field
> > order is set, but the VIDIOC_SUBDEV_G/S_SELECTION rectangles still refer
> > to frame size, regardless of the field order setting.
> > VIDIOC_SUBDEV_ENUM_FRAME_SIZES always returns frame sizes as opposed to
> > field sizes.
> > 
> > This was not immediately clear to me when reading the documentation, so
> > this patch adds some clarifications in the relevant places.
> > 
> > Suggested-by: Laurent Pinchart 
> > Signed-off-by: Philipp Zabel 
> > ---
> >  Documentation/media/uapi/v4l/dev-subdev.rst  | 16 +
> >  Documentation/media/uapi/v4l/subdev-formats.rst  |  3 ++-
> >  .../media/uapi/v4l/vidioc-subdev-enum-frame-size.rst |  4 
> >  .../media/uapi/v4l/vidioc-subdev-g-selection.rst |  2 ++
> >  4 files changed, 20 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/media/uapi/v4l/dev-subdev.rst
> > b/Documentation/media/uapi/v4l/dev-subdev.rst index
> > cd28701802086..2f0a41f3796f0 100644
> > --- a/Documentation/media/uapi/v4l/dev-subdev.rst
> > +++ b/Documentation/media/uapi/v4l/dev-subdev.rst
> > @@ -82,7 +82,8 @@ Pad-level Formats
> >  .. note::
> > 
> >  For the purpose of this section, the term *format* means the
> > -combination of media bus data format, frame width and frame height.
> > +combination of media bus data format, frame width and frame height,
> > +unless otherwise noted.
> > 
> >  Image formats are typically negotiated on video capture and output
> >  devices using the format and
> > @@ -120,7 +121,9 @@ can expose pad-level image format configuration to
> > applications. When they do, applications can use the
> > 
> >  :ref:`VIDIOC_SUBDEV_G_FMT ` and
> >  :ref:`VIDIOC_SUBDEV_S_FMT ` ioctls. to
> > 
> > -negotiate formats on a per-pad basis.
> > +negotiate formats on a per-pad basis. Note that when those ioctls are
> > +called with or return the field order set to ``V4L2_FIELD_ALTERNATE``,
> > +the format contains the field height, which is half the frame height.
> 
> Isn't that also the case for the TOP and BOTTOM field orders ?

Oh, those exist, too. I'll change all occurences to list ALTERNATE, TOP,
and BOTTOM. I hope this is not going to be too verbose for people that
don't have to care about interlacing.

> >  Applications are responsible for configuring coherent parameters on the
> >  whole pipeline and making sure that connected pads have compatible
> > @@ -379,7 +382,10 @@ is supported by the hardware.
> > pad for further processing.
> > 
> >  2. Sink pad actual crop selection. The sink pad crop defines the crop
> > -   performed to the sink pad format.
> > +   performed to the sink pad format. The crop rectangle always refers to
> > +   the frame size, even if the sink pad format has field order set to
> > +   ``V4L2_FIELD_ALTERNATE`` and the actual processed images are only
> > +   field sized.
> 
> I'm not sure to agree with this. I think all selection rectangle coordinates 
> should be expressed relative to the format of the pad they refer to.

But that's not how I understood Hans yesterday, and it shows that you
were quite on point with your suggestion to extend the docs.

> For sink pad crop rectangles, if the sink pad receives alternate (or
> top or bottom only) fields, the rectangle coordinates should be
> relative to the field size. Similarly, if the source pad produces
> alternate/top/bottom fields, the rectangle coordinates should also be
> relative to the field size.

That's also not how TVP5150 currently implements it. The crop rectangle
is frame sized even though the pad format reports alternating fields,
the same is true for vivid capture, even though that is not using the
subdev selection API.

Personally, I don't care whether the selection rectangles refer to frame
size or to the field size depending on the respective pad's field order
setting, but I'd really like to have it clearly spelled out in the
places this patch modifies.

> If the subdev transforms alternate fields to progressive or interlaced
> frames, then the sink crop rectangle should be relative to the frame
> size.

I'm confused. The sink pad is set to alternate fields in this case,
didn't you just argue that the sink crop/compose rectangles should refer
to field size?

Actually, this is exactly the case I want to handle. The CSI receives
FIELD_ALTERNATE frames from the TVP5150 with BT.656 synchronisation, but
it produces SEQ_TB or SEQ_BT (depending on standard) at its output pad.
If the input pad height is 288 lines for example, the output pad height
is 576 lines (in case of no cropping or scaling), and there's a sink
crop and a sink compose rectangle. Should those refer to the 288 lines
per field, or to the 

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Laurent Pinchart]

Hi Helen,

On Thursday 30 Mar 2017 23:39:01 Helen Koike wrote:
> On 2017-03-30 04:56 PM, Laurent Pinchart wrote:
> > On Thursday 30 Mar 2017 13:02:17 Helen Koike wrote:
> >> Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
> >> used when no inputs are available in the device
> >> 
> >> Signed-off-by: Helen Koike 
> >> ---
> >> 
> >>  drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
> >>  include/media/v4l2-ioctl.h   | 26 ++
> >>  include/uapi/linux/videodev2.h   |  1 +
> >>  3 files changed, 54 insertions(+)
> >> 
> >> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> >> b/drivers/media/v4l2-core/v4l2-ioctl.c index 0c3f238..ccaf04b 100644
> >> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> >> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> >> @@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct
> >> video_device *vdev, unsigned cmd) return vdev->lock;
> >> 
> >>  }
> >> 
> >> +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> >> +struct v4l2_input *i)
> >> +{
> >> +  if (i->index > 0)
> >> +  return -EINVAL;
> >> +
> >> +  memset(i, 0, sizeof(*i));
> >> +  i->type = V4L2_INPUT_TYPE_DEFAULT;
> >> +  strlcpy(i->name, "Default", sizeof(i->name));
> >> +
> >> +  return 0;
> >> +}
> >> +EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);
> > 
> > V4L2 tends to use EXPORT_SYMBOL_GPL.
> 
> The whole v4l2-ioctl.c file is using EXPORT_SYMBOL instead of
> EXPORT_SYMBOL_GPL, should we change it all to EXPORT_SYMBOL_GPL then (in
> another patch) ?

You're right, let's leave it as-is then.

> > What would you think about calling those default functions directly from
> > the core when the input ioctl handlers are not set ? You wouldn't need to
> > modify drivers.
> 
> Sure, I'll add them in ops inside __video_register_device when it
> validates the ioctls
> 
> >> +
> >> +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned
> >> int
> >> *i) +{
> >> +  *i = 0;
> >> +  return 0;
> >> +}
> >> +EXPORT_SYMBOL(v4l2_ioctl_g_input_default);
> >> +
> >> +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned
> >> int
> >> i) +{
> >> +  return i ? -EINVAL : 0;
> >> +}
> >> +EXPORT_SYMBOL(v4l2_ioctl_s_input_default);
> >> +
> >> 
> >>  /* Common ioctl debug function. This function can be used by
> >>  
> >> external ioctl messages as well as internal V4L ioctl */
> >>  
> >>  void v4l_printk_ioctl(const char *prefix, unsigned int cmd)
> >> 
> >> diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
> >> index 6cd94e5..accc470 100644
> >> --- a/include/media/v4l2-ioctl.h
> >> +++ b/include/media/v4l2-ioctl.h
> >> @@ -652,6 +652,32 @@ struct video_device;
> >> 
> >>   */
> >>  
> >>  struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev, unsigned
> >>  int
> >> 
> >> cmd);
> >> 
> >> +
> >> +/**
> >> + * v4l2_ioctl_enum_input_default - v4l2 ioctl helper for
> >> VIDIOC_ENUM_INPUT
> >> ioctl + *
> >> + * Plug this function in vidioc_enum_input field of the struct
> >> v4l2_ioctl_ops to + * enumerate a single input as V4L2_INPUT_TYPE_DEFAULT
> >> + */
> >> +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> >> +struct v4l2_input *i);
> >> +
> >> +/**
> >> + * v4l2_ioctl_g_input_default - v4l2 ioctl helper for VIDIOC_G_INPUT
> >> ioctl
> >> + *
> >> + * Plug this function in vidioc_g_input field of the struct
> >> v4l2_ioctl_ops
> >> + * when using v4l2_ioctl_enum_input_default
> >> + */
> >> +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned
> >> int
> >> *i); +
> >> +/**
> >> + * v4l2_ioctl_s_input_default - v4l2 ioctl helper for VIDIOC_S_INPUT
> >> ioctl
> >> + *
> >> + * Plug this function in vidioc_s_input field of the struct
> >> v4l2_ioctl_ops
> >> + * when using v4l2_ioctl_enum_input_default
> >> + */
> >> +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned
> >> int
> >> i); +
> >> 
> >>  /* names for fancy debug output */
> >>  extern const char *v4l2_field_names[];
> >>  extern const char *v4l2_type_names[];
> >> 
> >> diff --git a/include/uapi/linux/videodev2.h
> >> b/include/uapi/linux/videodev2.h index 316be62..c10bbde 100644
> >> --- a/include/uapi/linux/videodev2.h
> >> +++ b/include/uapi/linux/videodev2.h
> >> @@ -1477,6 +1477,7 @@ struct v4l2_input {
> >> 
> >>  };
> >>  
> >>  /*  Values for the 'type' field */
> >> 
> >> +#define V4L2_INPUT_TYPE_DEFAULT   0
> >> 
> >>  #define V4L2_INPUT_TYPE_TUNER 1
> >>  #define V4L2_INPUT_TYPE_CAMERA2
> >>  #define V4L2_INPUT_TYPE_TOUCH 3
> 
> Helen

-- 
Regards,

Laurent Pinchart

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Laurent Pinchart]

Hi Hans,

On Friday 31 Mar 2017 10:29:04 Hans Verkuil wrote:
> On 30/03/17 18:02, Helen Koike wrote:
> > Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
> > used when no inputs are available in the device
> > 
> > Signed-off-by: Helen Koike 
> > ---
> > 
> >  drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
> >  include/media/v4l2-ioctl.h   | 26 ++
> >  include/uapi/linux/videodev2.h   |  1 +
> >  3 files changed, 54 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c index 0c3f238..ccaf04b 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct
> > video_device *vdev, unsigned cmd)> 
> > return vdev->lock;
> >  
> >  }
> > 
> > +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> > + struct v4l2_input *i)
> > +{
> > +   if (i->index > 0)
> > +   return -EINVAL;
> > +
> > +   memset(i, 0, sizeof(*i));
> > +   i->type = V4L2_INPUT_TYPE_DEFAULT;
> > +   strlcpy(i->name, "Default", sizeof(i->name));
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);
> > +
> > +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned
> > int *i)
> > +{
> > +   *i = 0;
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(v4l2_ioctl_g_input_default);
> > +
> > +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned
> > int i)
> > +{
> > +   return i ? -EINVAL : 0;
> > +}
> > +EXPORT_SYMBOL(v4l2_ioctl_s_input_default);
> > +
> >  /* Common ioctl debug function. This function can be used by
> > external ioctl messages as well as internal V4L ioctl */
> >  void v4l_printk_ioctl(const char *prefix, unsigned int cmd)
> > diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
> > index 6cd94e5..accc470 100644
> > --- a/include/media/v4l2-ioctl.h
> > +++ b/include/media/v4l2-ioctl.h
> > @@ -652,6 +652,32 @@ struct video_device;
> >   */
> >  
> >  struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev, unsigned int
> >  cmd);
> > +
> > +/**
> > + * v4l2_ioctl_enum_input_default - v4l2 ioctl helper for
> > VIDIOC_ENUM_INPUT ioctl + *
> > + * Plug this function in vidioc_enum_input field of the struct
> > v4l2_ioctl_ops to + * enumerate a single input as V4L2_INPUT_TYPE_DEFAULT
> > + */
> > +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> > + struct v4l2_input *i);
> > +
> > +/**
> > + * v4l2_ioctl_g_input_default - v4l2 ioctl helper for VIDIOC_G_INPUT
> > ioctl
> > + *
> > + * Plug this function in vidioc_g_input field of the struct
> > v4l2_ioctl_ops
> > + * when using v4l2_ioctl_enum_input_default
> > + */
> > +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned
> > int *i); +
> > +/**
> > + * v4l2_ioctl_s_input_default - v4l2 ioctl helper for VIDIOC_S_INPUT
> > ioctl
> > + *
> > + * Plug this function in vidioc_s_input field of the struct
> > v4l2_ioctl_ops
> > + * when using v4l2_ioctl_enum_input_default
> > + */
> > +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned
> > int i); +
> > 
> >  /* names for fancy debug output */
> >  extern const char *v4l2_field_names[];
> >  extern const char *v4l2_type_names[];
> > 
> > diff --git a/include/uapi/linux/videodev2.h
> > b/include/uapi/linux/videodev2.h index 316be62..c10bbde 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -1477,6 +1477,7 @@ struct v4l2_input {
> > 
> >  };
> >  
> >  /*  Values for the 'type' field */
> > 
> > +#define V4L2_INPUT_TYPE_DEFAULT0
> 
> I don't think we should add a new type here. The whole point of this
> exercise is to allow existing apps to work, and existing apps expect a
> TYPE_CAMERA.
> 
> BTW, don't read to much in the term 'CAMERA': it's really a catch all for
> any video stream, whether it is from a sensor, composite input, HDMI, etc.
> 
> The description for V4L2_INPUT_TYPE_CAMERA in the spec is hopelessly out of
> date :-(
> 
> Rather than creating a new type I would add a new V4L2_IN_CAP_MC capability
> that indicates that this input is controlled via the media controller. That
> makes much more sense and it wouldn't potentially break applications.
> 
> Exactly the same can be done for outputs as well: add V4L2_OUT_CAP_MC and
> use V4L2_OUTPUT_TYPE_ANALOG as the output type (again, a horrible outdated
> name and the spec is again out of date).

What would those capabilities be used for ? Applications can already know 
whether the MC API is used by a driver. Furthermore, if we really need such a 
flag, I wouldn't add it at the input/output level but as a video node 
capability flag.

> Regarding the name: should we use the name stored in struct video_device
> instead? That might be more 

Re: [PATCH RFC 1/2] [media] v4l2: add V4L2_INPUT_TYPE_DEFAULT

[Hans Verkuil]

On 30/03/17 18:02, Helen Koike wrote:
> Add V4L2_INPUT_TYPE_DEFAULT and helpers functions for input ioctls to be
> used when no inputs are available in the device
> 
> Signed-off-by: Helen Koike 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 27 +++
>  include/media/v4l2-ioctl.h   | 26 ++
>  include/uapi/linux/videodev2.h   |  1 +
>  3 files changed, 54 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 0c3f238..ccaf04b 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -2573,6 +2573,33 @@ struct mutex *v4l2_ioctl_get_lock(struct video_device 
> *vdev, unsigned cmd)
>   return vdev->lock;
>  }
>  
> +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> +   struct v4l2_input *i)
> +{
> + if (i->index > 0)
> + return -EINVAL;
> +
> + memset(i, 0, sizeof(*i));
> + i->type = V4L2_INPUT_TYPE_DEFAULT;
> + strlcpy(i->name, "Default", sizeof(i->name));
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(v4l2_ioctl_enum_input_default);
> +
> +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int 
> *i)
> +{
> + *i = 0;
> + return 0;
> +}
> +EXPORT_SYMBOL(v4l2_ioctl_g_input_default);
> +
> +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int i)
> +{
> + return i ? -EINVAL : 0;
> +}
> +EXPORT_SYMBOL(v4l2_ioctl_s_input_default);
> +
>  /* Common ioctl debug function. This function can be used by
> external ioctl messages as well as internal V4L ioctl */
>  void v4l_printk_ioctl(const char *prefix, unsigned int cmd)
> diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
> index 6cd94e5..accc470 100644
> --- a/include/media/v4l2-ioctl.h
> +++ b/include/media/v4l2-ioctl.h
> @@ -652,6 +652,32 @@ struct video_device;
>   */
>  struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev, unsigned int 
> cmd);
>  
> +
> +/**
> + * v4l2_ioctl_enum_input_default - v4l2 ioctl helper for VIDIOC_ENUM_INPUT 
> ioctl
> + *
> + * Plug this function in vidioc_enum_input field of the struct 
> v4l2_ioctl_ops to
> + * enumerate a single input as V4L2_INPUT_TYPE_DEFAULT
> + */
> +int v4l2_ioctl_enum_input_default(struct file *file, void *priv,
> +   struct v4l2_input *i);
> +
> +/**
> + * v4l2_ioctl_g_input_default - v4l2 ioctl helper for VIDIOC_G_INPUT ioctl
> + *
> + * Plug this function in vidioc_g_input field of the struct v4l2_ioctl_ops
> + * when using v4l2_ioctl_enum_input_default
> + */
> +int v4l2_ioctl_g_input_default(struct file *file, void *priv, unsigned int 
> *i);
> +
> +/**
> + * v4l2_ioctl_s_input_default - v4l2 ioctl helper for VIDIOC_S_INPUT ioctl
> + *
> + * Plug this function in vidioc_s_input field of the struct v4l2_ioctl_ops
> + * when using v4l2_ioctl_enum_input_default
> + */
> +int v4l2_ioctl_s_input_default(struct file *file, void *priv, unsigned int 
> i);
> +
>  /* names for fancy debug output */
>  extern const char *v4l2_field_names[];
>  extern const char *v4l2_type_names[];
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 316be62..c10bbde 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -1477,6 +1477,7 @@ struct v4l2_input {
>  };
>  
>  /*  Values for the 'type' field */
> +#define V4L2_INPUT_TYPE_DEFAULT  0

I don't think we should add a new type here. The whole point of this exercise 
is to
allow existing apps to work, and existing apps expect a TYPE_CAMERA.

BTW, don't read to much in the term 'CAMERA': it's really a catch all for any 
video
stream, whether it is from a sensor, composite input, HDMI, etc.

The description for V4L2_INPUT_TYPE_CAMERA in the spec is hopelessly out of 
date :-(

Rather than creating a new type I would add a new V4L2_IN_CAP_MC capability that
indicates that this input is controlled via the media controller. That makes 
much
more sense and it wouldn't potentially break applications.

Exactly the same can be done for outputs as well: add V4L2_OUT_CAP_MC and use
V4L2_OUTPUT_TYPE_ANALOG as the output type (again, a horrible outdated name and 
the
spec is again out of date).

Regarding the name: should we use the name stored in struct video_device 
instead?
That might be more descriptive. Alternatively use something like "Media 
Controller Input".

More helpful (perhaps) than just "Default" or "Unknown".

I'll make a patch to update the input/output type description in the spec.

Regards,

Hans

>  #define V4L2_INPUT_TYPE_TUNER1
>  #define V4L2_INPUT_TYPE_CAMERA   2
>  #define V4L2_INPUT_TYPE_TOUCH3
> 

Re: [PATCH] [media] docs-rst: clarify field vs frame height in the subdev API

[Laurent Pinchart]

Hi Philipp,

Thank you for the patch.

On Thursday 30 Mar 2017 17:38:20 Philipp Zabel wrote:
> VIDIOC_SUBDEV_G/S_FMT take the field size if V4L2_FIELD_ALTERNATE field
> order is set, but the VIDIOC_SUBDEV_G/S_SELECTION rectangles still refer
> to frame size, regardless of the field order setting.
> VIDIOC_SUBDEV_ENUM_FRAME_SIZES always returns frame sizes as opposed to
> field sizes.
> 
> This was not immediately clear to me when reading the documentation, so
> this patch adds some clarifications in the relevant places.
> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Philipp Zabel 
> ---
>  Documentation/media/uapi/v4l/dev-subdev.rst  | 16 +
>  Documentation/media/uapi/v4l/subdev-formats.rst  |  3 ++-
>  .../media/uapi/v4l/vidioc-subdev-enum-frame-size.rst |  4 
>  .../media/uapi/v4l/vidioc-subdev-g-selection.rst |  2 ++
>  4 files changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/dev-subdev.rst
> b/Documentation/media/uapi/v4l/dev-subdev.rst index
> cd28701802086..2f0a41f3796f0 100644
> --- a/Documentation/media/uapi/v4l/dev-subdev.rst
> +++ b/Documentation/media/uapi/v4l/dev-subdev.rst
> @@ -82,7 +82,8 @@ Pad-level Formats
>  .. note::
> 
>  For the purpose of this section, the term *format* means the
> -combination of media bus data format, frame width and frame height.
> +combination of media bus data format, frame width and frame height,
> +unless otherwise noted.
> 
>  Image formats are typically negotiated on video capture and output
>  devices using the format and
> @@ -120,7 +121,9 @@ can expose pad-level image format configuration to
> applications. When they do, applications can use the
> 
>  :ref:`VIDIOC_SUBDEV_G_FMT ` and
>  :ref:`VIDIOC_SUBDEV_S_FMT ` ioctls. to
> 
> -negotiate formats on a per-pad basis.
> +negotiate formats on a per-pad basis. Note that when those ioctls are
> +called with or return the field order set to ``V4L2_FIELD_ALTERNATE``,
> +the format contains the field height, which is half the frame height.

Isn't that also the case for the TOP and BOTTOM field orders ?

>  Applications are responsible for configuring coherent parameters on the
>  whole pipeline and making sure that connected pads have compatible
> @@ -379,7 +382,10 @@ is supported by the hardware.
> pad for further processing.
> 
>  2. Sink pad actual crop selection. The sink pad crop defines the crop
> -   performed to the sink pad format.
> +   performed to the sink pad format. The crop rectangle always refers to
> +   the frame size, even if the sink pad format has field order set to
> +   ``V4L2_FIELD_ALTERNATE`` and the actual processed images are only
> +   field sized.

I'm not sure to agree with this. I think all selection rectangle coordinates 
should be expressed relative to the format of the pad they refer to. For sink 
pad crop rectangles, if the sink pad receives alternate (or top or bottom 
only) fields, the rectangle coordinates should be relative to the field size. 
Similarly, if the source pad produces alternate/top/bottom fields, the 
rectangle coordinates should also be relative to the field size. If the subdev 
transforms alternate fields to progressive or interlaced frames, then the sink 
crop rectangle should be relative to the frame size.

The rationale behind this is that a subdev that receives and outputs alternate 
fields should only care about fields and shouldn't be aware about the full 
frame size.

>  3. Sink pad actual compose selection. The size of the sink pad compose
> rectangle defines the scaling ratio compared to the size of the sink
> @@ -393,7 +399,9 @@ is supported by the hardware.
>  5. Source pad format. The source pad format defines the output pixel
> format of the subdev, as well as the other parameters with the
> exception of the image width and height. Width and height are defined
> -   by the size of the source pad actual crop selection.
> +   by the size of the source pad actual crop selection. If the source pad
> +   format has field order set to ``V4L2_FIELD_ALTERNATE``, the source pad
> +   field height is half the source pad crop selection height.
> 
>  Accessing any of the above rectangles not supported by the subdev will
>  return ``EINVAL``. Any rectangle referring to a previous unsupported
> diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst
> b/Documentation/media/uapi/v4l/subdev-formats.rst index
> d6152c907b8ba..f7195e5ee6e78 100644
> --- a/Documentation/media/uapi/v4l/subdev-formats.rst
> +++ b/Documentation/media/uapi/v4l/subdev-formats.rst
> @@ -19,7 +19,8 @@ Media Bus Formats
>- Image width, in pixels.
>  * - __u32
>- ``height``
> -  - Image height, in pixels.
> +  - Image height, in pixels. This is the field height for
> +``V4L2_FIELD_ALTERNATE`` field order, or the frame height
> otherwise.
>  * - __u32
>- 

Re: [PATCHv5 04/11] exynos_hdmi: add CEC notifier support

[Hans Verkuil]

On 31/03/17 00:35, Russell King - ARM Linux wrote:
> On Wed, Mar 29, 2017 at 04:15:36PM +0200, Hans Verkuil wrote:
>> +cec_notifier_set_phys_addr(hdata->notifier,
>> +   cec_get_edid_phys_addr(edid));
> 
> This pattern causes problems - can we have the notifier taking the EDID
> please, and stubs in cec-notifier.h to stub that out?
> 
> Maybe something like cec_notifier_set_phys_addr_from_edid(edid) ?

Good point. I've added this, and as an extra bonus this allowed me to drop
the first cec-edid patch.

> 
> Having converted the tda998x code over to your new notifier, the 0-day
> builder reported this tonight:
> 
>>> ERROR: "cec_get_edid_phys_addr" [drivers/gpu/drm/i2c/tda998x.ko] undefined!
> 
> which is caused exactly by this problem.  I can add #ifdefs into the
> tda998x driver, but as you're already stubbing out
> cec_notifier_set_phys_addr() in cec-notifier.h, it would be stupid to
> have to resort to #ifdefs in driver code to solve this issue.

Will post a new series today. Thanks for pointing this out.

A general note: I am considering merging cec-notifier and cec-edid into the
CEC module itself. However, I want to get this series in first before I start
moving things around. It's been delayed long enough already.

Regards,

Hans