cron job: media_tree daily build: WARNINGS

[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 Nov 18 05:00:19 CET 2017
media-tree git hash:30b4e122d71cbec2944a5f8b558b88936ee42f10
media_build git hash:   097aaf3e4e4bfdeff130db9697dec1befeb3221b
v4l-utils git hash: 58885f8fdd9a7ef5f0b7f0a8ff71f5a4ac0821b8
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: 0.5.1 (Debian: 0.5.1-2)
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.13.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-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: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
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.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12.1-i686: OK
linux-4.13-i686: OK
linux-4.14-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
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.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: OK
linux-4.14-x86_64: OK
apps: OK
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

[PATCH] media: imx: Remove incorrect check for queue state in start_streaming

[Ian Jamison]

It is possible to call STREAMON without the minimum number of
buffers queued. In this case the vb2_queue state will be set to
streaming but the start_streaming vb2_op will not be called.
Later when enough buffers are queued, start_streaming will
be called but vb2_is_streaming will already return true.

Signed-off-by: Ian Jamison 
---
 drivers/staging/media/imx/imx-media-capture.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-capture.c 
b/drivers/staging/media/imx/imx-media-capture.c
index ddab4c249da2..34b492c2419c 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -449,9 +449,6 @@ static int capture_start_streaming(struct vb2_queue *vq, 
unsigned int count)
unsigned long flags;
int ret;
 
-   if (vb2_is_streaming(vq))
-   return 0;
-
ret = imx_media_pipeline_set_stream(priv->md, >src_sd->entity,
true);
if (ret) {
-- 
2.15.0

Re: [PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

[Rob Herring]

On Thu, Nov 16, 2017 at 06:22:49PM +, Fabrizio Castro wrote:
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
> v1->v2:
> * Fixed double "change" in changelog
> 
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Acked-by: Rob Herring 

Re: [PATCH v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list

[Rob Herring]

On Thu, Nov 16, 2017 at 06:22:48PM +, Fabrizio Castro wrote:
> Change the sorting of the part numbers from descending to ascending to
> match with other documentation.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
> v1->v2:
> * new patch triggered by Geert's comment, see the below link for details:
>   https://www.mail-archive.com/linux-media@vger.kernel.org/msg121992.html
> 
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)

Acked-by: Rob Herring 

Grüße an Dich

[Meinze Klaus Peter]

In einer kurzen Einführung

Ich bin ein Rechtsanwalt Meinze Klaus Peter, aus Germany, ich lebe
jetzt in London, ich habe Ihnen eine E-Mail über Ihre verstorbene
Familie geschickt, aber ich habe keine Antwort von Ihnen erhalten, der
Verstorbene ist ein Bürger Ihres Landes mit der gleicher Nachname mit
Ihnen

Er ist ein Goldexporteur hier in London, mein Klient starb vor ein
paar Jahren mit seiner Familie, die sein Geschäft verließ und riesige
Summen hier  £ 5,7 Millionen hier UBS Investment Bank hier in London
deponierte, ich bin der persönliche Anwalt von der verstorbene Kunde,

Ich brauche Ihre volle Zusammenarbeit, damit wir das Geld von der Bank
nehmen können, bevor die Regierung endlich greift, aber

Ich werde mehr Details erklären, wenn ich von Ihnen höre

Re: [PATCH] media: cx231xx: add support for TheImagingSource DFG/USB2pro

[jacopo mondi]

Hi Romain,

On Fri, Nov 17, 2017 at 04:38:55PM +0100, Romain Reignier wrote:
> Hello,
>
> This is my first patch to the kernel so please be indulgent if I have done
> anything wrong and help me produce a better submission.

With this formatting (email text + patch below) applying with 'git am'
results in having the whole email text as commit message, which is not
what you want.

My suggestion is to amend your patch and insert a meaningful commit
message after the commit title (I think you should rework title a bit
as well, eg. captial 'A' on 'Add', space in between 'TheImagingSource'
if needed etc)

Then you can generate patch with 'git format-patch -s' and insert all
text you want -after- the commit message (everything after the
three dashes '---' gets ignored when git applies the patch)

Eg:
~
commit title

multi line commit message:
blah blah blah
blah blah blah

Your sign-off
---
The email text you sent us

---
The actual patch

~

Run checkpatch.pl on the resulting patch and then, once checkpatch is happy,
you can send your v2 with git send-email.

When you'll be sending a series of multiple patches instead, please use
--cover-letter option with 'git format-patch' and place your email text there.

Thanks
  j


>
> This is a patch to add the support for The Imaging Source DFG/USB2pro USB
> capture device. It is based on the Conexant CX23102 chip do the patch only
> consists in adding one entry in the devices list.
>
> Note that the inputs for the Composite and S-Video are inverted in regard to
> most of the other boards.
>
> I could test the Composite input that is working for several months in some of
> our products. But did not have the chance to try the S-Video input because I
> do not own any device with that standard (I have tried a simple Composite to
> S-Video cable but it does not work, even on Windows). So I have applied the
> same settings as the Windows driver.
>
> I have created a page on the Wiki to describe the board:
> https://www.linuxtv.org/wiki/index.php/The_Imaging_Source_DFG-USB2pro
>
> Sincerely,
>
> Romain Reignier
>
> ---
>
> From 13d83af3e6e5c01b43875d67cdcc3312ebbc6c7a Mon Sep 17 00:00:00 2001
> From: Romain Reignier 
> Date: Fri, 17 Nov 2017 15:52:40 +0100
> Subject: [PATCH] media: cx231xx: add support for TheImagingSource DFG/USB2pro
>
> Signed-off-by: Romain Reignier 
> ---
>  drivers/media/usb/cx231xx/cx231xx-cards.c | 28 
>  drivers/media/usb/cx231xx/cx231xx.h   |  1 +
>  2 files changed, 29 insertions(+)
>
> diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
> b/drivers/media/usb/cx231xx/cx231xx-cards.c
> index 54d9d0c..99c8b1a 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-cards.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
> @@ -896,6 +896,32 @@ struct cx231xx_board cx231xx_boards[] = {
>   },
>   },
>   },
> + [CX231XX_BOARD_THE_IMAGING_SOURCE_DFG_USB2_PRO] = {
> + .name = "The Imaging Source DFG/USB2pro",
> + .tuner_type = TUNER_ABSENT,
> + .decoder = CX231XX_AVDECODER,
> + .output_mode = OUT_MODE_VIP11,
> + .demod_xfer_mode = 0,
> + .ctl_pin_status_mask = 0xFFC4,
> + .agc_analog_digital_select_gpio = 0x0c,
> + .gpio_pin_status_mask = 0x4001000,
> + .norm = V4L2_STD_PAL,
> + .no_alt_vanc = 1,
> + .external_av = 1,
> + .input = {{
> + .type = CX231XX_VMUX_COMPOSITE1,
> + .vmux = CX231XX_VIN_1_1,
> + .amux = CX231XX_AMUX_LINE_IN,
> + .gpio = NULL,
> + }, {
> + .type = CX231XX_VMUX_SVIDEO,
> + .vmux = CX231XX_VIN_2_1 |
> + (CX231XX_VIN_2_2 << 8) |
> + CX25840_SVIDEO_ON,
> + .amux = CX231XX_AMUX_LINE_IN,
> + .gpio = NULL,
> + } },
> + },
>  };
>  const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
>
> @@ -967,6 +993,8 @@ struct usb_device_id cx231xx_id_table[] = {
>   .driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
>   {USB_DEVICE(0x15f4, 0x0135),
>   .driver_info = CX231XX_BOARD_ASTROMETA_T2HYBRID},
> + {USB_DEVICE(0x199e, 0x8002),
> +  .driver_info = CX231XX_BOARD_THE_IMAGING_SOURCE_DFG_USB2_PRO},
>   {},
>  };
>
> diff --git a/drivers/media/usb/cx231xx/cx231xx.h 
> b/drivers/media/usb/cx231xx/cx231xx.h
> index 72d5937..65b039c 100644
> --- a/drivers/media/usb/cx231xx/cx231xx.h
> +++ b/drivers/media/usb/cx231xx/cx231xx.h
> @@ -80,6 +80,7 @@
>  #define CX231XX_BOARD_TERRATEC_GRABBY 22
>  #define CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD 23
>  #define 

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Gustavo Padovan]

2017-11-17 Gustavo Padovan :

> 2017-11-17 Hans Verkuil :
> 
> > On 15/11/17 18:10, Gustavo Padovan wrote:
> > > From: Gustavo Padovan 
> > > 
> > > Receive in-fence from userspace and add support for waiting on them
> > > before queueing the buffer to the driver. Buffers can't be queued to the
> > > driver before its fences signal. And a buffer can't be queue to the driver
> > > out of the order they were queued from userspace. That means that even if
> > > it fence signal it must wait all other buffers, ahead of it in the queue,
> > > to signal first.
> > > 
> > > To make that possible we use fence_array to keep that ordering. Basically
> > > we create a fence_array that contains both the current fence and the fence
> > > from the previous buffer (which might be a fence array as well). The base
> > > fence class for the fence_array becomes the new buffer fence, waiting on
> > > that one guarantees that it won't be queued out of order.
> > > 
> > > v6:
> > >   - With fences always keep the order userspace queues the buffers.
> > >   - Protect in_fence manipulation with a lock (Brian Starkey)
> > >   - check if fences have the same context before adding a fence array
> > >   - Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
> > >   - Clean up fence if __set_in_fence() fails (Brian Starkey)
> > >   - treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
> > > 
> > > v5:   - use fence_array to keep buffers ordered in vb2 core when
> > >   needed (Brian Starkey)
> > >   - keep backward compat on the reserved2 field (Brian Starkey)
> > >   - protect fence callback removal with lock (Brian Starkey)
> > > 
> > > v4:
> > >   - Add a comment about dma_fence_add_callback() not returning a
> > >   error (Hans)
> > >   - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
> > >   - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
> > >   - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
> > >   - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
> > >   -  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
> > >   vb2_start_streaming() (Hans)
> > >   - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
> > >   - Queue buffers to the driver as soon as they are ready (Hans)
> > >   - call fill_user_buffer() after queuing the buffer (Hans)
> > >   - add err: label to clean up fence
> > >   - add dma_fence_wait() before calling vb2_start_streaming()
> > > 
> > > v3:   - document fence parameter
> > >   - remove ternary if at vb2_qbuf() return (Mauro)
> > >   - do not change if conditions behaviour (Mauro)
> > > 
> > > v2:
> > >   - fix vb2_queue_or_prepare_buf() ret check
> > >   - remove check for VB2_MEMORY_DMABUF only (Javier)
> > >   - check num of ready buffers to start streaming
> > >   - when queueing, start from the first ready buffer
> > >   - handle queue cancel
> > > 
> > > Signed-off-by: Gustavo Padovan 
> > > ---
> > >  drivers/media/v4l2-core/Kconfig  |   1 +
> > >  drivers/media/v4l2-core/videobuf2-core.c | 202 
> > > ---
> > >  drivers/media/v4l2-core/videobuf2-v4l2.c |  29 -
> > >  include/media/videobuf2-core.h   |  17 ++-
> > >  4 files changed, 231 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/drivers/media/v4l2-core/Kconfig 
> > > b/drivers/media/v4l2-core/Kconfig
> > > index a35c33686abf..3f988c407c80 100644
> > > --- a/drivers/media/v4l2-core/Kconfig
> > > +++ b/drivers/media/v4l2-core/Kconfig
> > > @@ -83,6 +83,7 @@ config VIDEOBUF_DVB
> > >  # Used by drivers that need Videobuf2 modules
> > >  config VIDEOBUF2_CORE
> > >   select DMA_SHARED_BUFFER
> > > + select SYNC_FILE
> > >   tristate
> > >  
> > >  config VIDEOBUF2_MEMOPS
> > > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > > b/drivers/media/v4l2-core/videobuf2-core.c
> > > index 60f8b582396a..26de4c80717d 100644
> > > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > > @@ -23,6 +23,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > >  #include 
> > >  #include 
> > > @@ -346,6 +347,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, 
> > > enum vb2_memory memory,
> > >   vb->index = q->num_buffers + buffer;
> > >   vb->type = q->type;
> > >   vb->memory = memory;
> > > + spin_lock_init(>fence_cb_lock);
> > >   for (plane = 0; plane < num_planes; ++plane) {
> > >   vb->planes[plane].length = plane_sizes[plane];
> > >   vb->planes[plane].min_length = plane_sizes[plane];
> > > @@ -1222,6 +1224,9 @@ static void __enqueue_in_driver(struct vb2_buffer 
> > > *vb)
> > >  {
> > >   struct vb2_queue *q = vb->vb2_queue;
> > >  
> > > + if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> > > + return;
> > > +
> > >   vb->state = 

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

[Matthias Reichl]

On Fri, Nov 17, 2017 at 03:52:50PM +0100, Matthias Reichl wrote:
> Hi Sean!
> 
> On Thu, Nov 16, 2017 at 09:54:51PM +, Sean Young wrote:
> > Since commit d57ea877af38 ("media: rc: per-protocol repeat period"),
> > double keypresses are reported on the ite-cir driver. This is due
> > two factors: that commit reduced the timeout used for some protocols
> > (it became protocol dependant) and the high default IR timeout used
> > by the ite-cir driver.
> > 
> > Some of the IR decoders wait for a trailing space, as that is
> > the only way to know if the bit stream has ended (e.g. rc-6 can be
> > 16, 20 or 32 bits). The longer the IR timeout, the longer it will take
> > to receive the trailing space, delaying decoding and pushing it past the
> > keyup timeout.
> > 
> > So, add the IR timeout to the keyup timeout.
> 
> Thanks a lot for the patch, I've asked the people with ite-cir
> receivers to test it.

Just got the first test results from ite-cir + rc-6 remote back,
events were the same as I was seeing with gpio-ir-recv with 200ms
timeout - key repeat event from input layer.

Kernel 4.14 + your patch:
Event: time 1510938801.797335, type 4 (EV_MSC), code 4 (MSC_SCAN), value 
800f041f
Event: time 1510938801.797335, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1
Event: time 1510938801.797335, -- SYN_REPORT 
Event: time 1510938802.034331, type 4 (EV_MSC), code 4 (MSC_SCAN), value 
800f041f
Event: time 1510938802.034331, -- SYN_REPORT 
Event: time 1510938802.301333, type 1 (EV_KEY), code 108 (KEY_DOWN), value 2
Event: time 1510938802.301333, -- SYN_REPORT 
Event: time 1510938802.408003, type 1 (EV_KEY), code 108 (KEY_DOWN), value 0
Event: time 1510938802.408003, -- SYN_REPORT 

Kernel 4.13.2:
Event: time 1510938637.791450, type 4 (EV_MSC), code 4 (MSC_SCAN), value 
800f041f
Event: time 1510938637.791450, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1
Event: time 1510938637.791450, -- SYN_REPORT 
Event: time 1510938638.028301, type 4 (EV_MSC), code 4 (MSC_SCAN), value 
800f041f
Event: time 1510938638.028301, -- SYN_REPORT 
Event: time 1510938638.292323, type 1 (EV_KEY), code 108 (KEY_DOWN), value 0
Event: time 1510938638.292323, -- SYN_REPORT 

so long,

Hias

> 
> In the meanwhile I ran some tests with gpio-ir-recv and timeout
> set to 200ms with a rc-5 remote (that's as close to the original
> setup as I can test right now).
> 
> While the patch fixes the additional key down/up event on longer
> presses, I still get a repeated key event on a short button
> press - which makes it hard to do a single click with the
> remote.
> 
> Test on kernel 4.14 with your patch:
> 1510927844.292126: event type EV_MSC(0x04): scancode = 0x1015
> 1510927844.292126: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
> 1510927844.292126: event type EV_SYN(0x00).
> 1510927844.498773: event type EV_MSC(0x04): scancode = 0x1015
> 1510927844.498773: event type EV_SYN(0x00).
> 1510927844.795410: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
> 1510927844.795410: event type EV_SYN(0x00).
> 1510927844.875412: event type EV_KEY(0x01) key_up: KEY_ENTER(0x001c)
> 1510927844.875412: event type EV_SYN(0x00).
> 
> Same signal received on kernel 4.9:
> 1510927844.280350: event type EV_MSC(0x04): scancode = 0x1015
> 1510927844.280350: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
> 1510927844.280350: event type EV_SYN(0x00).
> 1510927844.506477: event type EV_MSC(0x04): scancode = 0x1015
> 1510927844.506477: event type EV_SYN(0x00).
> 1510927844.763111: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
> 1510927844.763111: event type EV_SYN(0x00).
> 
> If I understand it correctly it's the input layer repeat (500ms delay)
> kicking in, because time between initial scancode and timeout is
> now signal time + 200ms + 164ms + 200ms (about 570-580ms).
> On older kernels this was signal time + 200ms + 250ms, so typically
> just below the 500ms default repeat delay.
> 
> I'm still trying to wrap my head around the timeout code in the
> rc layer. One problem seems to be that we apply the rather large
> timeout twice. Maybe detecting scancodes generated via timeout
> (sth like timestamp - last_timestamp > protocol_repeat_period)
> and in that case immediately signalling keyup could help? Could well
> be that I'm missing somehting important and this is a bad idea.
> I guess I'd better let you figure something out :)
> 
> so long,
> 
> Hias
> 
> > 
> > Cc:  # 4.14
> > Reported-by: Matthias Reichl 
> > Signed-off-by: Sean Young 
> > ---
> >  drivers/media/rc/rc-main.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> > index 17950e29d4e3..fae721534517 100644
> > --- a/drivers/media/rc/rc-main.c
> > +++ b/drivers/media/rc/rc-main.c
> > @@ 

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Gustavo Padovan]

2017-11-17 Hans Verkuil :

> On 15/11/17 18:10, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers can't be queued to the
> > driver before its fences signal. And a buffer can't be queue to the driver
> > out of the order they were queued from userspace. That means that even if
> > it fence signal it must wait all other buffers, ahead of it in the queue,
> > to signal first.
> > 
> > To make that possible we use fence_array to keep that ordering. Basically
> > we create a fence_array that contains both the current fence and the fence
> > from the previous buffer (which might be a fence array as well). The base
> > fence class for the fence_array becomes the new buffer fence, waiting on
> > that one guarantees that it won't be queued out of order.
> > 
> > v6:
> > - With fences always keep the order userspace queues the buffers.
> > - Protect in_fence manipulation with a lock (Brian Starkey)
> > - check if fences have the same context before adding a fence array
> > - Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
> > - Clean up fence if __set_in_fence() fails (Brian Starkey)
> > - treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
> > 
> > v5: - use fence_array to keep buffers ordered in vb2 core when
> > needed (Brian Starkey)
> > - keep backward compat on the reserved2 field (Brian Starkey)
> > - protect fence callback removal with lock (Brian Starkey)
> > 
> > v4:
> > - Add a comment about dma_fence_add_callback() not returning a
> > error (Hans)
> > - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
> > - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
> > - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
> > - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
> > -  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
> > vb2_start_streaming() (Hans)
> > - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
> > - Queue buffers to the driver as soon as they are ready (Hans)
> > - call fill_user_buffer() after queuing the buffer (Hans)
> > - add err: label to clean up fence
> > - add dma_fence_wait() before calling vb2_start_streaming()
> > 
> > v3: - document fence parameter
> > - remove ternary if at vb2_qbuf() return (Mauro)
> > - do not change if conditions behaviour (Mauro)
> > 
> > v2:
> > - fix vb2_queue_or_prepare_buf() ret check
> > - remove check for VB2_MEMORY_DMABUF only (Javier)
> > - check num of ready buffers to start streaming
> > - when queueing, start from the first ready buffer
> > - handle queue cancel
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/media/v4l2-core/Kconfig  |   1 +
> >  drivers/media/v4l2-core/videobuf2-core.c | 202 
> > ---
> >  drivers/media/v4l2-core/videobuf2-v4l2.c |  29 -
> >  include/media/videobuf2-core.h   |  17 ++-
> >  4 files changed, 231 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/Kconfig 
> > b/drivers/media/v4l2-core/Kconfig
> > index a35c33686abf..3f988c407c80 100644
> > --- a/drivers/media/v4l2-core/Kconfig
> > +++ b/drivers/media/v4l2-core/Kconfig
> > @@ -83,6 +83,7 @@ config VIDEOBUF_DVB
> >  # Used by drivers that need Videobuf2 modules
> >  config VIDEOBUF2_CORE
> > select DMA_SHARED_BUFFER
> > +   select SYNC_FILE
> > tristate
> >  
> >  config VIDEOBUF2_MEMOPS
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 60f8b582396a..26de4c80717d 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -23,6 +23,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -346,6 +347,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
> > vb2_memory memory,
> > vb->index = q->num_buffers + buffer;
> > vb->type = q->type;
> > vb->memory = memory;
> > +   spin_lock_init(>fence_cb_lock);
> > for (plane = 0; plane < num_planes; ++plane) {
> > vb->planes[plane].length = plane_sizes[plane];
> > vb->planes[plane].min_length = plane_sizes[plane];
> > @@ -1222,6 +1224,9 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
> >  {
> > struct vb2_queue *q = vb->vb2_queue;
> >  
> > +   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> > +   return;
> > +
> > vb->state = VB2_BUF_STATE_ACTIVE;
> > atomic_inc(>owned_by_drv_count);
> >  
> > @@ -1273,6 +1278,23 @@ static int __buf_prepare(struct vb2_buffer *vb, 
> > const void *pb)
> > return 0;
> >  }
> >  
> > +static int 

Re: [PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Philippe Ombredanne]

On Fri, Nov 17, 2017 at 6:01 PM, Mauro Carvalho Chehab
 wrote:
> Em Fri, 17 Nov 2017 16:01:41 +0100
> Philippe Ombredanne  escreveu:
>
>> On Fri, Nov 17, 2017 at 3:58 PM, Mauro Carvalho Chehab
>>  wrote:
>> > Em Fri, 17 Nov 2017 15:18:26 +0100
>> > Greg Kroah-Hartman  escreveu:
>> >
>> > Its license is actually GPL 2.0+
>> >
>> > So, I would actually change it to:
>> >
>> > MODULE_LICENSE("GPL v2");
>>
>> Mauro:
>>
>> actually even if it sounds weird the module.h doc [1] is clear on this topic:
>>
>>  * "GPL" [GNU Public License v2 or later]
>>  * "GPL v2" [GNU Public License v2]
>>
>> So it should be "GPL" IMHO.
>>
>>
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h?id=refs/tags/v4.10#n175
>>
>
> Oh! Yeah, you're right. I would add that on the Kernel documentation
> somewhere, perhaps with the new document that Thomas is writing
> about SPFX.
> The Documentation/kernel-hacking/hacking.rst doc mentions
> MODULE_LICENSE, but doesn't define the expected values for it.


Good point!

Thomas:
Is this something that should be taken care of?
If yes, I may be able take a crack at it sometimes next week.

unless...

Mauro:
if you have a docwriter soul and want to make a good deed for the
holidays, may you feel like starting a doc patch? :P

e.g. something along the lines:

"Here are the valid values for MODULE_LICENSE as found in module.h ...
And here are the rules to set a MODULE_LICENSE and how this relates to
the top level SPDX-License-Identifier..."

BTW, I wished we could align the MODULE_LICENSE values with the SPDX
ids for clarity and as this would inject normalized SPDX license tags
in the Elf binaries.

But that 's likely impossible as it would break a truck load of
out-of-tree module macros and out-of-tree module loading command line
tools everywhere (such as busybox and many other) so the (computing)
world would crawl to a halt. *sigh*

-- 
Cordially
Philippe Ombredanne

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Gustavo Padovan]

2017-11-17 Mauro Carvalho Chehab :

> Em Fri, 17 Nov 2017 11:12:48 -0200
> Gustavo Padovan  escreveu:
> 
> > > > /*
> > > >  * If streamon has been called, and we haven't yet called
> > > >  * start_streaming() since not enough buffers were queued, and
> > > >  * we now have reached the minimum number of queued buffers,
> > > >  * then we can finally call start_streaming().
> > > > -*
> > > > -* If already streaming, give the buffer to driver for 
> > > > processing.
> > > > -* If not, the buffer will be given to driver on next streamon.
> > > >  */
> > > > if (q->streaming && !q->start_streaming_called &&
> > > > -   q->queued_count >= q->min_buffers_needed) {
> > > > +   __get_num_ready_buffers(q) >= q->min_buffers_needed) {  
> > > 
> > > I guess the case where fences is not used is not covered here.
> > > 
> > > You probably should add a check at __get_num_ready_buffers(q)
> > > as well, making it just return q->queued_count if fences isn't
> > > used.  
> > 
> > We can't know that beforehand, some buffer ahead may have a fence,
> > but there is already a check for !fence for each buffer. If none of
> > them have fences the return will be equal to q->queued_count.
> 
> Hmm... are we willing to support the case where just some
> buffers have fences? Why?

It may be that some fences are already signaled before the QBUF call
happens, so the app may just pass -1 instead.

> In any case, we should add a notice at the documentation telling
> about what happens if not all buffers have fences, and if fences
> are required to be setup before starting streaming, or if it is
> possible to dynamically change the fances behavior while streaming.

We don't have such thing. The fence behavior is tied to each QBUF call,
the stream can be setup without knowing anything about if fences are
going to be used or not. I think we need a good reason to do otherwise.
Yet, I can add something to the docs saying that fences are exclusively
per QBUF call.

Gustavo

Re: [PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Greg Kroah-Hartman]

On Fri, Nov 17, 2017 at 03:01:02PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Nov 2017 16:01:41 +0100
> Philippe Ombredanne  escreveu:
> 
> > On Fri, Nov 17, 2017 at 3:58 PM, Mauro Carvalho Chehab
> >  wrote:
> > > Em Fri, 17 Nov 2017 15:18:26 +0100
> > > Greg Kroah-Hartman  escreveu:
> > >  
> > >> There is no need to #define the license of the driver, just put it in
> > >> the MODULE_LICENSE() line directly as a text string.
> > >>
> > >> This allows tools that check that the module license matches the source
> > >> code license to work properly, as there is no need to unwind the
> > >> unneeded dereference.
> > >>
> > >> Cc: Hans Verkuil 
> > >> Cc: Mauro Carvalho Chehab 
> > >> Cc: Johan Hovold 
> > >> Cc: Davidlohr Bueso 
> > >> Cc: Sakari Ailus 
> > >> Reported-by: Philippe Ombredanne 
> > >> Signed-off-by: Greg Kroah-Hartman 
> 
> Acked-by: Mauro Carvalho Chehab 
> 
> > >> ---
> > >>  drivers/media/usb/usbvision/usbvision-video.c | 3 +--
> > >>  1 file changed, 1 insertion(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/media/usb/usbvision/usbvision-video.c 
> > >> b/drivers/media/usb/usbvision/usbvision-video.c
> > >> index 960272d3c924..0f5954a1fea2 100644
> > >> --- a/drivers/media/usb/usbvision/usbvision-video.c
> > >> +++ b/drivers/media/usb/usbvision/usbvision-video.c
> > >> @@ -72,7 +72,6 @@
> > >>  #define DRIVER_NAME "usbvision"
> > >>  #define DRIVER_ALIAS "USBVision"
> > >>  #define DRIVER_DESC "USBVision USB Video Device Driver for Linux"
> > >> -#define DRIVER_LICENSE "GPL"
> > >>  #define USBVISION_VERSION_STRING "0.9.11"
> > >>
> > >>  #define  ENABLE_HEXDUMP  0   /* Enable if you need it */
> > >> @@ -141,7 +140,7 @@ MODULE_PARM_DESC(radio_nr, "Set radio device number 
> > >> (/dev/radioX).  Default: -1
> > >>  /* Misc stuff */
> > >>  MODULE_AUTHOR(DRIVER_AUTHOR);
> > >>  MODULE_DESCRIPTION(DRIVER_DESC);
> > >> -MODULE_LICENSE(DRIVER_LICENSE);
> > >> +MODULE_LICENSE("GPL");  
> > >
> > > Makes sense to me, but, if we look at the header of this file:
> > >
> > >  * This program is free software; you can redistribute it and/or modify
> > >  * it under the terms of the GNU General Public License as published by
> > >  * the Free Software Foundation; either version 2 of the License, or
> > >  * (at your option) any later version.
> > >
> > > Its license is actually GPL 2.0+
> > >
> > > So, I would actually change it to:
> > >
> > > MODULE_LICENSE("GPL v2");  
> > 
> > Mauro:
> > 
> > actually even if it sounds weird the module.h doc [1] is clear on this 
> > topic:
> > 
> >  * "GPL" [GNU Public License v2 or later]
> >  * "GPL v2" [GNU Public License v2]
> > 
> > So it should be "GPL" IMHO.
> > 
> > 
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h?id=refs/tags/v4.10#n175
> > 
> 
> Oh! Yeah, you're right. I would add that on the Kernel documentation
> somewhere, perhaps with the new document that Thomas is writing
> about SPFX. 
> 
> The Documentation/kernel-hacking/hacking.rst doc mentions 
> MODULE_LICENSE, but doesn't define the expected values for it.

It's buried in the code comments in include/linux/module.h.  One of
these days I want to just make a #define for the licenses that makes it
a bit more obvious what each should be, but for now, we have lots of
other things to clean up before dealing with this :)

thanks,

greg k-h

Re: [PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Mauro Carvalho Chehab]

Em Fri, 17 Nov 2017 16:01:41 +0100
Philippe Ombredanne  escreveu:

> On Fri, Nov 17, 2017 at 3:58 PM, Mauro Carvalho Chehab
>  wrote:
> > Em Fri, 17 Nov 2017 15:18:26 +0100
> > Greg Kroah-Hartman  escreveu:
> >  
> >> There is no need to #define the license of the driver, just put it in
> >> the MODULE_LICENSE() line directly as a text string.
> >>
> >> This allows tools that check that the module license matches the source
> >> code license to work properly, as there is no need to unwind the
> >> unneeded dereference.
> >>
> >> Cc: Hans Verkuil 
> >> Cc: Mauro Carvalho Chehab 
> >> Cc: Johan Hovold 
> >> Cc: Davidlohr Bueso 
> >> Cc: Sakari Ailus 
> >> Reported-by: Philippe Ombredanne 
> >> Signed-off-by: Greg Kroah-Hartman 

Acked-by: Mauro Carvalho Chehab 

> >> ---
> >>  drivers/media/usb/usbvision/usbvision-video.c | 3 +--
> >>  1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/media/usb/usbvision/usbvision-video.c 
> >> b/drivers/media/usb/usbvision/usbvision-video.c
> >> index 960272d3c924..0f5954a1fea2 100644
> >> --- a/drivers/media/usb/usbvision/usbvision-video.c
> >> +++ b/drivers/media/usb/usbvision/usbvision-video.c
> >> @@ -72,7 +72,6 @@
> >>  #define DRIVER_NAME "usbvision"
> >>  #define DRIVER_ALIAS "USBVision"
> >>  #define DRIVER_DESC "USBVision USB Video Device Driver for Linux"
> >> -#define DRIVER_LICENSE "GPL"
> >>  #define USBVISION_VERSION_STRING "0.9.11"
> >>
> >>  #define  ENABLE_HEXDUMP  0   /* Enable if you need it */
> >> @@ -141,7 +140,7 @@ MODULE_PARM_DESC(radio_nr, "Set radio device number 
> >> (/dev/radioX).  Default: -1
> >>  /* Misc stuff */
> >>  MODULE_AUTHOR(DRIVER_AUTHOR);
> >>  MODULE_DESCRIPTION(DRIVER_DESC);
> >> -MODULE_LICENSE(DRIVER_LICENSE);
> >> +MODULE_LICENSE("GPL");  
> >
> > Makes sense to me, but, if we look at the header of this file:
> >
> >  * This program is free software; you can redistribute it and/or modify
> >  * it under the terms of the GNU General Public License as published by
> >  * the Free Software Foundation; either version 2 of the License, or
> >  * (at your option) any later version.
> >
> > Its license is actually GPL 2.0+
> >
> > So, I would actually change it to:
> >
> > MODULE_LICENSE("GPL v2");  
> 
> Mauro:
> 
> actually even if it sounds weird the module.h doc [1] is clear on this topic:
> 
>  * "GPL" [GNU Public License v2 or later]
>  * "GPL v2" [GNU Public License v2]
> 
> So it should be "GPL" IMHO.
> 
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h?id=refs/tags/v4.10#n175
> 

Oh! Yeah, you're right. I would add that on the Kernel documentation
somewhere, perhaps with the new document that Thomas is writing
about SPFX. 

The Documentation/kernel-hacking/hacking.rst doc mentions 
MODULE_LICENSE, but doesn't define the expected values for it.

Thanks,
Mauro

Re: [PATCH 6/6] media: usb: add SPDX identifiers to some code I wrote

[Laurent Pinchart]

Hi Philippe,

On Friday, 17 November 2017 17:08:51 EET Philippe Ombredanne wrote:
> On Fri, Nov 17, 2017 at 4:01 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 17 Nov 2017 12:54:15 +0100 Philippe Ombredanne escreveu:
> >> On Fri, Nov 17, 2017 at 11:21 AM, Mauro Carvalho Chehab wrote:
> >> > As we're now using SPDX identifiers, on several
> >> > media drivers I wrote, add the proper SPDX, identifying
> >> > the license I meant.
> >> > 
> >> > As we're now using the short license, it doesn't make sense to
> >> > keep the original license text.
> >> > 
> >> > Also, fix MODULE_LICENSE to properly identify GPL v2.
> >> > 
> >> > Signed-off-by: Mauro Carvalho Chehab 
> >> 
> >> Mauro,
> >> Thanks ++  I can now get rid of a special license detection rule I
> >> had added for the specific language of your notices in the
> >> scancode-toolkit!
> >> 
> > :-)
> > 
> > Yeah, I was too lazy to copy the usual GPL preamble on those
> > drivers ;-)
> 
> I guess I built a lazyness checker with scancode to keep you check then ;)
> But FWIW you are not alone there and at least your notices are/were
> consistent across files ... there are still several hundred variations
> of GPL notices in the kernel each with subtle or byzantine changes.
> 
> Some of them are rather funny like Evgeniy's thermal code being under
> the "therms" of the GPL [1]

Isn't that very appropriate for the thermal code ?

https://en.wikipedia.org/wiki/Therm

Sorry, couldn't resist :)

> CC: Evgeniy Polyakov 
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri
> vers/w1/slaves/w1_therm.c?h=v4.14-rc8#n8

-- 
Regards,

Laurent Pinchart

[PATCH v4 9/9] v4l: vsp1: Reduce display list body size

[Kieran Bingham]

The display list originally allocated a body of 256 entries to store all
of the register lists required for each frame.

This has now been separated into fragments for constant stream setup, and
runtime updates.

Empirical testing shows that the body0 now uses a maximum of 41
registers for each frame, for both DRM and Video API pipelines thus a
rounded 64 entries provides a suitable allocation.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 49d88b03d359..278451e8bc4e 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -21,7 +21,7 @@
 #include "vsp1.h"
 #include "vsp1_dl.h"
 
-#define VSP1_DL_NUM_ENTRIES256
+#define VSP1_DL_NUM_ENTRIES64
 
 #define VSP1_DLH_INT_ENABLE(1 << 1)
 #define VSP1_DLH_AUTO_START(1 << 0)
-- 
git-series 0.9.1

[PATCH v4 8/9] v4l: vsp1: Move video configuration to a cached dlb

[Kieran Bingham]

We are now able to configure a pipeline directly into a local display
list body. Take advantage of this fact, and create a cacheable body to
store the configuration of the pipeline in the video object.

vsp1_video_pipeline_run() is now the last user of the pipe->dl object.
Convert this function to use the cached video->config body and obtain a
local display list reference.

Attach the video->config body to the display list when needed before
committing to hardware.

The pipe object is marked as un-configured when resuming from a suspend.
This ensures that when the hardware is reset - our cached configuration
will be re-attached to the next committed DL.

Signed-off-by: Kieran Bingham 
---

v3:
 - 's/fragment/body/', 's/fragments/bodies/'
 - video dlb cache allocation increased from 2 to 3 dlbs

Our video DL usage now looks like the below output:

dl->body0 contains our disposable runtime configuration. Max 41.
dl_child->body0 is our partition specific configuration. Max 12.
dl->bodies shows our constant configuration and LUTs.

  These two are LUT/CLU:
 * dl->bodies[x]->num_entries 256 / max 256
 * dl->bodies[x]->num_entries 4914 / max 4914

Which shows that our 'constant' configuration cache is currently
utilised to a maximum of 64 entries.

trace-cmd report | \
grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq;

  dl->body0->num_entries 13 / max 128
  dl->body0->num_entries 14 / max 128
  dl->body0->num_entries 16 / max 128
  dl->body0->num_entries 20 / max 128
  dl->body0->num_entries 27 / max 128
  dl->body0->num_entries 34 / max 128
  dl->body0->num_entries 41 / max 128
  dl_child->body0->num_entries 10 / max 128
  dl_child->body0->num_entries 12 / max 128
  dl->bodies[x]->num_entries 15 / max 128
  dl->bodies[x]->num_entries 16 / max 128
  dl->bodies[x]->num_entries 17 / max 128
  dl->bodies[x]->num_entries 18 / max 128
  dl->bodies[x]->num_entries 20 / max 128
  dl->bodies[x]->num_entries 21 / max 128
  dl->bodies[x]->num_entries 256 / max 256
  dl->bodies[x]->num_entries 31 / max 128
  dl->bodies[x]->num_entries 32 / max 128
  dl->bodies[x]->num_entries 39 / max 128
  dl->bodies[x]->num_entries 40 / max 128
  dl->bodies[x]->num_entries 47 / max 128
  dl->bodies[x]->num_entries 48 / max 128
  dl->bodies[x]->num_entries 4914 / max 4914
  dl->bodies[x]->num_entries 55 / max 128
  dl->bodies[x]->num_entries 56 / max 128
  dl->bodies[x]->num_entries 63 / max 128
  dl->bodies[x]->num_entries 64 / max 128

v4:
 - Adjust pipe configured flag to be reset on resume rather than suspend
 - rename dl_child, dl_next
---
 drivers/media/platform/vsp1/vsp1_pipe.c  |  7 +++-
 drivers/media/platform/vsp1/vsp1_pipe.h  |  4 +-
 drivers/media/platform/vsp1/vsp1_video.c | 67 -
 drivers/media/platform/vsp1/vsp1_video.h |  2 +-
 4 files changed, 54 insertions(+), 26 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 5012643583b6..fa445b1a2e38 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe)
vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index),
   VI6_CMD_STRCMD);
pipe->state = VSP1_PIPELINE_RUNNING;
+   pipe->configured = true;
}
 
pipe->buffers_ready = 0;
@@ -470,6 +471,12 @@ void vsp1_pipelines_resume(struct vsp1_device *vsp1)
continue;
 
spin_lock_irqsave(>irqlock, flags);
+   /*
+* The hardware may have been reset during a suspend and will
+* need a full reconfiguration
+*/
+   pipe->configured = false;
+
if (vsp1_pipeline_ready(pipe))
vsp1_pipeline_run(pipe);
spin_unlock_irqrestore(>irqlock, flags);
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 90d29492b9b9..e7ad6211b4d0 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -90,6 +90,7 @@ struct vsp1_partition {
  * @irqlock: protects the pipeline state
  * @state: current state
  * @wq: wait queue to wait for state change completion
+ * @configured: flag determining if the hardware has run since reset
  * @frame_end: frame end interrupt handler
  * @lock: protects the pipeline use count and stream count
  * @kref: pipeline reference count
@@ -117,6 +118,7 @@ struct vsp1_pipeline {
spinlock_t irqlock;
enum vsp1_pipeline_state state;
wait_queue_head_t wq;
+   bool configured;
 
void (*frame_end)(struct vsp1_pipeline *pipe, bool completed);
 
@@ -143,8 +145,6 @@ struct vsp1_pipeline {
 */
struct list_head entities;
 
-   struct vsp1_dl_list *dl;
-
unsigned int partitions;
struct 

[PATCH v4 5/9] v4l: vsp1: Use reference counting for bodies

[Kieran Bingham]

Extend the display list body with a reference count, allowing bodies to
be kept as long as a reference is maintained. This provides the ability
to keep a cached copy of bodies which will not change, so that they can
be re-applied to multiple display lists.

Signed-off-by: Kieran Bingham 

---
This could be squashed into the body update code, but it's not a
straightforward squash as the refcounts will affect both:
  v4l: vsp1: Provide a body pool
and
  v4l: vsp1: Convert display lists to use new body pool
therefore, I have kept this separate to prevent breaking bisectability
of the vsp-tests.

v3:
 - 's/fragment/body/'

v4:
 - Fix up reference handling comments.
---
 drivers/media/platform/vsp1/vsp1_clu.c |  7 ++-
 drivers/media/platform/vsp1/vsp1_dl.c  | 15 ++-
 drivers/media/platform/vsp1/vsp1_lut.c |  7 ++-
 3 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 2018144470c5..b2a39a6ef7e4 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -257,8 +257,13 @@ static void clu_configure(struct vsp1_entity *entity,
clu->clu = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-   if (dlb)
+   if (dlb) {
vsp1_dl_list_add_body(dl, dlb);
+
+   /* release our local reference */
+   vsp1_dl_body_put(dlb);
+   }
+
break;
}
 }
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index a64a80f8085f..fb54cbe4c682 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -58,6 +59,8 @@ struct vsp1_dl_body {
struct list_head list;
struct list_head free;
 
+   refcount_t refcnt;
+
struct vsp1_dl_body_pool *pool;
struct vsp1_device *vsp1;
 
@@ -258,6 +261,7 @@ struct vsp1_dl_body *vsp1_dl_body_get(struct 
vsp1_dl_body_pool *pool)
if (!list_empty(>free)) {
dlb = list_first_entry(>free, struct vsp1_dl_body, free);
list_del(>free);
+   refcount_set(>refcnt, 1);
}
 
spin_unlock_irqrestore(>lock, flags);
@@ -278,6 +282,9 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
if (!dlb)
return;
 
+   if (!refcount_dec_and_test(>refcnt))
+   return;
+
dlb->num_entries = 0;
 
spin_lock_irqsave(>pool->lock, flags);
@@ -464,7 +471,11 @@ void vsp1_dl_list_write(struct vsp1_dl_list *dl, u32 reg, 
u32 data)
  * in the order in which bodies are added.
  *
  * Adding a body to a display list passes ownership of the body to the list. 
The
- * caller must not touch the body after this call.
+ * caller retains its reference to the fragment when adding it to the display
+ * list, but is not allowed to add new entries to the body.
+ *
+ * The reference must be explicitly released by a call to vsp1_dl_body_put()
+ * when the body isn't needed anymore.
  *
  * Additional bodies are only usable for display lists in header mode.
  * Attempting to add a body to a header-less display list will return an error.
@@ -476,6 +487,8 @@ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl,
if (dl->dlm->mode != VSP1_DL_MODE_HEADER)
return -EINVAL;
 
+   refcount_inc(>refcnt);
+
list_add_tail(>list, >bodies);
return 0;
 }
diff --git a/drivers/media/platform/vsp1/vsp1_lut.c 
b/drivers/media/platform/vsp1/vsp1_lut.c
index 262cb72139d6..77cf7137a0f2 100644
--- a/drivers/media/platform/vsp1/vsp1_lut.c
+++ b/drivers/media/platform/vsp1/vsp1_lut.c
@@ -213,8 +213,13 @@ static void lut_configure(struct vsp1_entity *entity,
lut->lut = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-   if (dlb)
+   if (dlb) {
vsp1_dl_list_add_body(dl, dlb);
+
+   /* release our local reference */
+   vsp1_dl_body_put(dlb);
+   }
+
break;
}
 }
-- 
git-series 0.9.1

[PATCH v4 3/9] v4l: vsp1: Provide a body pool

[Kieran Bingham]

Each display list allocates a body to store register values in a dma
accessible buffer from a dma_alloc_wc() allocation. Each of these
results in an entry in the TLB, and a large number of display list
allocations adds pressure to this resource.

Reduce TLB pressure on the IPMMUs by allocating multiple display list
bodies in a single allocation, and providing these to the display list
through a 'body pool'. A pool can be allocated by the display list
manager or entities which require their own body allocations.

Signed-off-by: Kieran Bingham 

---
v4:
 - Provide comment explaining extra allocation on body pool
   highlighting area for optimisation later.

v3:
 - s/fragment/body/, s/fragments/bodies/
 - qty -> num_bodies
 - indentation fix
 - s/vsp1_dl_body_pool_{alloc,free}/vsp1_dl_body_pool_{create,destroy}/'
 - Add kerneldoc to non-static functions

v2:
 - assign dlb->dma correctly
---
 drivers/media/platform/vsp1/vsp1_dl.c | 163 +++-
 drivers/media/platform/vsp1/vsp1_dl.h |   8 +-
 2 files changed, 171 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index a45d35aa676e..0047030483e1 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -45,6 +45,8 @@ struct vsp1_dl_entry {
 /**
  * struct vsp1_dl_body - Display list body
  * @list: entry in the display list list of bodies
+ * @free: entry in the pool free body list
+ * @pool: pool to which this body belongs
  * @vsp1: the VSP1 device
  * @entries: array of entries
  * @dma: DMA address of the entries
@@ -54,6 +56,9 @@ struct vsp1_dl_entry {
  */
 struct vsp1_dl_body {
struct list_head list;
+   struct list_head free;
+
+   struct vsp1_dl_body_pool *pool;
struct vsp1_device *vsp1;
 
struct vsp1_dl_entry *entries;
@@ -65,6 +70,30 @@ struct vsp1_dl_body {
 };
 
 /**
+ * struct vsp1_dl_body_pool - display list body pool
+ * @dma: DMA address of the entries
+ * @size: size of the full DMA memory pool in bytes
+ * @mem: CPU memory pointer for the pool
+ * @bodies: Array of DLB structures for the pool
+ * @free: List of free DLB entries
+ * @lock: Protects the pool and free list
+ * @vsp1: the VSP1 device
+ */
+struct vsp1_dl_body_pool {
+   /* DMA allocation */
+   dma_addr_t dma;
+   size_t size;
+   void *mem;
+
+   /* Body management */
+   struct vsp1_dl_body *bodies;
+   struct list_head free;
+   spinlock_t lock;
+
+   struct vsp1_device *vsp1;
+};
+
+/**
  * struct vsp1_dl_list - Display list
  * @list: entry in the display list manager lists
  * @dlm: the display list manager
@@ -104,6 +133,7 @@ enum vsp1_dl_mode {
  * @active: list currently being processed (loaded) by hardware
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
+ * @pool: body pool for the display list bodies
  * @gc_work: bodies garbage collector work struct
  * @gc_bodies: array of display list bodies waiting to be freed
  */
@@ -119,6 +149,8 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *queued;
struct vsp1_dl_list *pending;
 
+   struct vsp1_dl_body_pool *pool;
+
struct work_struct gc_work;
struct list_head gc_bodies;
 };
@@ -127,6 +159,137 @@ struct vsp1_dl_manager {
  * Display List Body Management
  */
 
+/**
+ * vsp1_dl_body_pool_create - Create a pool of bodies from a single allocation
+ * @vsp1: The VSP1 device
+ * @num_bodies: The quantity of bodies to allocate
+ * @num_entries: The maximum number of entries that the body can contain
+ * @extra_size: Extra allocation provided for the bodies
+ *
+ * Allocate a pool of display list bodies each with enough memory to contain 
the
+ * requested number of entries.
+ *
+ * Return a pointer to a pool on success or NULL if memory can't be allocated.
+ */
+struct vsp1_dl_body_pool *
+vsp1_dl_body_pool_create(struct vsp1_device *vsp1, unsigned int num_bodies,
+unsigned int num_entries, size_t extra_size)
+{
+   struct vsp1_dl_body_pool *pool;
+   size_t dlb_size;
+   unsigned int i;
+
+   pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+   if (!pool)
+   return NULL;
+
+   pool->vsp1 = vsp1;
+
+   /*
+* Todo: 'extra_size' is only used by vsp1_dlm_create(), to allocate
+* extra memory for the display list header. We need only one header per
+* display list, not per display list body, thus this allocation is
+* extraneous and should be reworked in the future.
+*/
+   dlb_size = num_entries * sizeof(struct vsp1_dl_entry) + extra_size;
+   pool->size = dlb_size * num_bodies;
+
+   pool->bodies = kcalloc(num_bodies, sizeof(*pool->bodies), GFP_KERNEL);
+   if (!pool->bodies) {
+   kfree(pool);
+   return NULL;
+   }
+
+   pool->mem = 

[PATCH v4 7/9] v4l: vsp1: Adapt entities to configure into a body

[Kieran Bingham]

Currently the entities store their configurations into a display list.
Adapt this such that the code can be configured into a body directly,
allowing greater flexibility and control of the content.

All users of vsp1_dl_list_write() are removed in this process, thus it
too is removed.

A helper, vsp1_dl_list_get_body0() is provided to access the internal body0
from the display list.

Signed-off-by: Kieran Bingham 

---

v4:
 - Rename vsp1_dl_list_get_body() to vsp1_dl_list_get_body0()
   The similarities between vsp1_dl_list_get_body and
   vsp1_dl_list_body_get() were too close

 - body0 could be removed later when the default body is no longer
   needed.
---
 drivers/media/platform/vsp1/vsp1_bru.c| 22 ++--
 drivers/media/platform/vsp1/vsp1_clu.c| 22 ++--
 drivers/media/platform/vsp1/vsp1_dl.c | 12 ++-
 drivers/media/platform/vsp1/vsp1_dl.h |  4 +-
 drivers/media/platform/vsp1/vsp1_drm.c| 14 +---
 drivers/media/platform/vsp1/vsp1_entity.c | 16 -
 drivers/media/platform/vsp1/vsp1_entity.h | 12 ---
 drivers/media/platform/vsp1/vsp1_hgo.c| 16 -
 drivers/media/platform/vsp1/vsp1_hgt.c| 18 +-
 drivers/media/platform/vsp1/vsp1_hsit.c   | 10 +++---
 drivers/media/platform/vsp1/vsp1_lif.c| 13 +++
 drivers/media/platform/vsp1/vsp1_lut.c| 21 ++--
 drivers/media/platform/vsp1/vsp1_pipe.c   |  4 +-
 drivers/media/platform/vsp1/vsp1_pipe.h   |  3 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 43 +++-
 drivers/media/platform/vsp1/vsp1_sru.c| 14 
 drivers/media/platform/vsp1/vsp1_uds.c| 24 +++--
 drivers/media/platform/vsp1/vsp1_uds.h|  2 +-
 drivers/media/platform/vsp1/vsp1_video.c  | 11 --
 drivers/media/platform/vsp1/vsp1_wpf.c| 42 ---
 20 files changed, 169 insertions(+), 154 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index b9ff96f76b3e..60d449d7b135 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -30,10 +30,10 @@
  * Device Access
  */
 
-static inline void vsp1_bru_write(struct vsp1_bru *bru, struct vsp1_dl_list 
*dl,
- u32 reg, u32 data)
+static inline void vsp1_bru_write(struct vsp1_bru *bru,
+ struct vsp1_dl_body *dlb, u32 reg, u32 data)
 {
-   vsp1_dl_list_write(dl, bru->base + reg, data);
+   vsp1_dl_body_write(dlb, bru->base + reg, data);
 }
 
 /* 
-
@@ -287,7 +287,7 @@ static const struct v4l2_subdev_ops bru_ops = {
 
 static void bru_prepare(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
-   struct vsp1_dl_list *dl)
+   struct vsp1_dl_body *dlb)
 {
struct vsp1_bru *bru = to_bru(>subdev);
struct v4l2_mbus_framefmt *format;
@@ -309,7 +309,7 @@ static void bru_prepare(struct vsp1_entity *entity,
 * format at the pipeline output is premultiplied.
 */
flags = pipe->output ? pipe->output->format.flags : 0;
-   vsp1_bru_write(bru, dl, VI6_BRU_INCTRL,
+   vsp1_bru_write(bru, dlb, VI6_BRU_INCTRL,
   flags & V4L2_PIX_FMT_FLAG_PREMUL_ALPHA ?
   0 : VI6_BRU_INCTRL_NRM);
 
@@ -317,12 +317,12 @@ static void bru_prepare(struct vsp1_entity *entity,
 * Set the background position to cover the whole output image and
 * configure its color.
 */
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_SIZE,
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_SIZE,
   (format->width << VI6_BRU_VIRRPF_SIZE_HSIZE_SHIFT) |
   (format->height << VI6_BRU_VIRRPF_SIZE_VSIZE_SHIFT));
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_LOC, 0);
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_LOC, 0);
 
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_COL, bru->bgcolor |
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_COL, bru->bgcolor |
   (0xff << VI6_BRU_VIRRPF_COL_A_SHIFT));
 
/*
@@ -332,7 +332,7 @@ static void bru_prepare(struct vsp1_entity *entity,
 * unit.
 */
if (entity->type == VSP1_ENTITY_BRU)
-   vsp1_bru_write(bru, dl, VI6_BRU_ROP,
+   vsp1_bru_write(bru, dlb, VI6_BRU_ROP,
   VI6_BRU_ROP_DSTSEL_BRUIN(1) |
   VI6_BRU_ROP_CROP(VI6_ROP_NOP) |
   VI6_BRU_ROP_AROP(VI6_ROP_NOP));
@@ -374,7 +374,7 @@ static void bru_prepare(struct vsp1_entity *entity,
if (!(entity->type == VSP1_ENTITY_BRU && i == 1))
ctrl |= VI6_BRU_CTRL_SRCSEL_BRUIN(i);
 
-   vsp1_bru_write(bru, dl, VI6_BRU_CTRL(i), ctrl);
+   vsp1_bru_write(bru, dlb, VI6_BRU_CTRL(i), 

[PATCH v4 6/9] v4l: vsp1: Refactor display list configure operations

[Kieran Bingham]

The entities provide a single .configure operation which configures the
object into the target display list, based on the vsp1_entity_params
selection.

This restricts us to a single function prototype for both static
configuration (the pre-stream INIT stage) and the dynamic runtime stages
for both each frame - and each partition therein.

Split the configure function into two parts, '.prepare()' and
'.configure()', merging both the VSP1_ENTITY_PARAMS_RUNTIME and
VSP1_ENTITY_PARAMS_PARTITION stages into a single call through the
.configure(). The configuration for individual partitions is handled by
passing the partition number to the configure call, and processing any
runtime stage actions on the first partition only.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_bru.c|  12 +-
 drivers/media/platform/vsp1/vsp1_clu.c|  42 +--
 drivers/media/platform/vsp1/vsp1_drm.c|  11 +-
 drivers/media/platform/vsp1/vsp1_entity.c |  15 +-
 drivers/media/platform/vsp1/vsp1_entity.h |  27 +--
 drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
 drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
 drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
 drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
 drivers/media/platform/vsp1/vsp1_lut.c|  24 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 162 ++---
 drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
 drivers/media/platform/vsp1/vsp1_uds.c|  55 ++--
 drivers/media/platform/vsp1/vsp1_video.c  |  24 +--
 drivers/media/platform/vsp1/vsp1_wpf.c| 297 ---
 15 files changed, 358 insertions(+), 371 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index e8fd2ae3b3eb..b9ff96f76b3e 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -285,19 +285,15 @@ static const struct v4l2_subdev_ops bru_ops = {
  * VSP1 Entity Operations
  */
 
-static void bru_configure(struct vsp1_entity *entity,
- struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+static void bru_prepare(struct vsp1_entity *entity,
+   struct vsp1_pipeline *pipe,
+   struct vsp1_dl_list *dl)
 {
struct vsp1_bru *bru = to_bru(>subdev);
struct v4l2_mbus_framefmt *format;
unsigned int flags;
unsigned int i;
 
-   if (params != VSP1_ENTITY_PARAMS_INIT)
-   return;
-
format = vsp1_entity_get_pad_format(>entity, bru->entity.config,
bru->entity.source_pad);
 
@@ -404,7 +400,7 @@ static void bru_configure(struct vsp1_entity *entity,
 }
 
 static const struct vsp1_entity_operations bru_entity_ops = {
-   .configure = bru_configure,
+   .prepare = bru_prepare,
 };
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index b2a39a6ef7e4..be4d7e493746 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -213,37 +213,36 @@ static const struct v4l2_subdev_ops clu_ops = {
 /* 
-
  * VSP1 Entity Operations
  */
+static void clu_prepare(struct vsp1_entity *entity,
+   struct vsp1_pipeline *pipe,
+   struct vsp1_dl_list *dl)
+{
+   struct vsp1_clu *clu = to_clu(>subdev);
+
+   /*
+* The yuv_mode can't be changed during streaming. Cache it internally
+* for future runtime configuration calls.
+*/
+   struct v4l2_mbus_framefmt *format;
+
+   format = vsp1_entity_get_pad_format(>entity,
+   clu->entity.config,
+   CLU_PAD_SINK);
+   clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
+}
 
 static void clu_configure(struct vsp1_entity *entity,
  struct vsp1_pipeline *pipe,
  struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+ unsigned int partition)
 {
struct vsp1_clu *clu = to_clu(>subdev);
struct vsp1_dl_body *dlb;
unsigned long flags;
u32 ctrl = VI6_CLU_CTRL_AAI | VI6_CLU_CTRL_MVS | VI6_CLU_CTRL_EN;
 
-   switch (params) {
-   case VSP1_ENTITY_PARAMS_INIT: {
-   /*
-* The format can't be changed during streaming, only verify it
-* at setup time and store the information internally for future
-* runtime configuration calls.
-*/
-   struct v4l2_mbus_framefmt *format;
-
-   format = vsp1_entity_get_pad_format(>entity,
-

[PATCH v4 2/9] v4l: vsp1: Protect bodies against overflow

[Kieran Bingham]

The body write function relies on the code never asking it to write more
than the entries available in the list.

Currently with each list body containing 256 entries, this is fine, but
we can reduce this number greatly saving memory. In preparation of this
add a level of protection to catch any buffer overflows.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 

---

v3:
 - adapt for new 'body' terminology
 - simplify WARN_ON macro usage
---
 drivers/media/platform/vsp1/vsp1_dl.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 643f7ea3af24..a45d35aa676e 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -50,6 +50,7 @@ struct vsp1_dl_entry {
  * @dma: DMA address of the entries
  * @size: size of the DMA memory in bytes
  * @num_entries: number of stored entries
+ * @max_entries: number of entries available
  */
 struct vsp1_dl_body {
struct list_head list;
@@ -60,6 +61,7 @@ struct vsp1_dl_body {
size_t size;
 
unsigned int num_entries;
+   unsigned int max_entries;
 };
 
 /**
@@ -138,6 +140,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
 
dlb->vsp1 = vsp1;
dlb->size = size;
+   dlb->max_entries = num_entries;
 
dlb->entries = dma_alloc_wc(vsp1->bus_master, dlb->size, >dma,
GFP_KERNEL);
@@ -219,6 +222,10 @@ void vsp1_dl_body_free(struct vsp1_dl_body *dlb)
  */
 void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 reg, u32 data)
 {
+   if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
+ "DLB size exceeded (max %u)", dlb->max_entries))
+   return;
+
dlb->entries[dlb->num_entries].addr = reg;
dlb->entries[dlb->num_entries].data = data;
dlb->num_entries++;
-- 
git-series 0.9.1

[PATCH v4 4/9] v4l: vsp1: Convert display lists to use new body pool

[Kieran Bingham]

Adapt the dl->body0 object to use an object from the body pool. This
greatly reduces the pressure on the TLB for IPMMU use cases, as all of
the lists use a single allocation for the main body.

The CLU and LUT objects pre-allocate a pool containing three bodies,
allowing a userspace update before the hardware has committed a previous
set of tables.

Bodies are no longer 'freed' in interrupt context, but instead released
back to their respective pools. This allows us to remove the garbage
collector in the DLM.

Signed-off-by: Kieran Bingham 

---
v3:
 - 's/fragment/body', 's/fragments/bodies/'
 - CLU/LUT now allocate 3 bodies
 - vsp1_dl_list_fragments_free -> vsp1_dl_list_bodies_put

v2:
 - Use dl->body0->max_entries to determine header offset, instead of the
   global constant VSP1_DL_NUM_ENTRIES which is incorrect.
 - squash updates for LUT, CLU, and fragment cleanup into single patch.
   (Not fully bisectable when separated)
---
 drivers/media/platform/vsp1/vsp1_clu.c |  27 ++-
 drivers/media/platform/vsp1/vsp1_clu.h |   1 +-
 drivers/media/platform/vsp1/vsp1_dl.c  | 223 ++
 drivers/media/platform/vsp1/vsp1_dl.h  |   3 +-
 drivers/media/platform/vsp1/vsp1_lut.c |  27 ++-
 drivers/media/platform/vsp1/vsp1_lut.h |   1 +-
 6 files changed, 101 insertions(+), 181 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 9621afa3658c..2018144470c5 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -23,6 +23,8 @@
 #define CLU_MIN_SIZE   4U
 #define CLU_MAX_SIZE   8190U
 
+#define CLU_SIZE   (17 * 17 * 17)
+
 /* 
-
  * Device Access
  */
@@ -47,19 +49,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct 
v4l2_ctrl *ctrl)
struct vsp1_dl_body *dlb;
unsigned int i;
 
-   dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+   dlb = vsp1_dl_body_get(clu->pool);
if (!dlb)
return -ENOMEM;
 
vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0);
-   for (i = 0; i < 17 * 17 * 17; ++i)
+   for (i = 0; i < CLU_SIZE; ++i)
vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
 
spin_lock_irq(>lock);
swap(clu->clu, dlb);
spin_unlock_irq(>lock);
 
-   vsp1_dl_body_free(dlb);
+   vsp1_dl_body_put(dlb);
return 0;
 }
 
@@ -261,8 +263,16 @@ static void clu_configure(struct vsp1_entity *entity,
}
 }
 
+static void clu_destroy(struct vsp1_entity *entity)
+{
+   struct vsp1_clu *clu = to_clu(>subdev);
+
+   vsp1_dl_body_pool_destroy(clu->pool);
+}
+
 static const struct vsp1_entity_operations clu_entity_ops = {
.configure = clu_configure,
+   .destroy = clu_destroy,
 };
 
 /* 
-
@@ -288,6 +298,17 @@ struct vsp1_clu *vsp1_clu_create(struct vsp1_device *vsp1)
if (ret < 0)
return ERR_PTR(ret);
 
+   /*
+* Pre-allocate a body pool, with 3 bodies allowing a userspace update
+* before the hardware has committed a previous set of tables, handling
+* both the queued and pending dl entries. One extra entry is added to
+* the CLU_SIZE to allow for the VI6_CLU_ADDR header.
+*/
+   clu->pool = vsp1_dl_body_pool_create(clu->entity.vsp1, 3, CLU_SIZE + 1,
+0);
+   if (!clu->pool)
+   return ERR_PTR(-ENOMEM);
+
/* Initialize the control handler. */
v4l2_ctrl_handler_init(>ctrls, 2);
v4l2_ctrl_new_custom(>ctrls, _table_control, NULL);
diff --git a/drivers/media/platform/vsp1/vsp1_clu.h 
b/drivers/media/platform/vsp1/vsp1_clu.h
index 036e0a2f1a42..fa3fe856725b 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.h
+++ b/drivers/media/platform/vsp1/vsp1_clu.h
@@ -36,6 +36,7 @@ struct vsp1_clu {
spinlock_t lock;
unsigned int mode;
struct vsp1_dl_body *clu;
+   struct vsp1_dl_body_pool *pool;
 };
 
 static inline struct vsp1_clu *to_clu(struct v4l2_subdev *subdev)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 0047030483e1..a64a80f8085f 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -110,7 +110,7 @@ struct vsp1_dl_list {
struct vsp1_dl_header *header;
dma_addr_t dma;
 
-   struct vsp1_dl_body body0;
+   struct vsp1_dl_body *body0;
struct list_head bodies;
 
bool has_chain;
@@ -134,8 +134,6 @@ enum vsp1_dl_mode {
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
  * @pool: body pool for the display list bodies
- * 

[PATCH v4 1/9] v4l: vsp1: Reword uses of 'fragment' as 'body'

[Kieran Bingham]

Throughout the codebase, the term 'fragment' is used to represent a
display list body. This term duplicates the 'body' which is already in
use.

The datasheet references these objects as a body, therefore replace all
mentions of a fragment with a body, along with the corresponding
pluralised terms.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_clu.c |  10 +-
 drivers/media/platform/vsp1/vsp1_dl.c  | 107 --
 drivers/media/platform/vsp1/vsp1_dl.h  |  14 +--
 drivers/media/platform/vsp1/vsp1_lut.c |   8 +-
 4 files changed, 69 insertions(+), 70 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index f2fb26e5ab4e..9621afa3658c 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -47,19 +47,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct 
v4l2_ctrl *ctrl)
struct vsp1_dl_body *dlb;
unsigned int i;
 
-   dlb = vsp1_dl_fragment_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+   dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
if (!dlb)
return -ENOMEM;
 
-   vsp1_dl_fragment_write(dlb, VI6_CLU_ADDR, 0);
+   vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0);
for (i = 0; i < 17 * 17 * 17; ++i)
-   vsp1_dl_fragment_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
+   vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
 
spin_lock_irq(>lock);
swap(clu->clu, dlb);
spin_unlock_irq(>lock);
 
-   vsp1_dl_fragment_free(dlb);
+   vsp1_dl_body_free(dlb);
return 0;
 }
 
@@ -256,7 +256,7 @@ static void clu_configure(struct vsp1_entity *entity,
spin_unlock_irqrestore(>lock, flags);
 
if (dlb)
-   vsp1_dl_list_add_fragment(dl, dlb);
+   vsp1_dl_list_add_body(dl, dlb);
break;
}
 }
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 8b5cbb6b7a70..643f7ea3af24 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -69,7 +69,7 @@ struct vsp1_dl_body {
  * @header: display list header, NULL for headerless lists
  * @dma: DMA address for the header
  * @body0: first display list body
- * @fragments: list of extra display list bodies
+ * @bodies: list of extra display list bodies
  * @chain: entry in the display list partition chain
  */
 struct vsp1_dl_list {
@@ -80,7 +80,7 @@ struct vsp1_dl_list {
dma_addr_t dma;
 
struct vsp1_dl_body body0;
-   struct list_head fragments;
+   struct list_head bodies;
 
bool has_chain;
struct list_head chain;
@@ -97,13 +97,13 @@ enum vsp1_dl_mode {
  * @mode: display list operation mode (header or headerless)
  * @singleshot: execute the display list in single-shot mode
  * @vsp1: the VSP1 device
- * @lock: protects the free, active, queued, pending and gc_fragments lists
+ * @lock: protects the free, active, queued, pending and gc_bodies lists
  * @free: array of all free display lists
  * @active: list currently being processed (loaded) by hardware
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
- * @gc_work: fragments garbage collector work struct
- * @gc_fragments: array of display list fragments waiting to be freed
+ * @gc_work: bodies garbage collector work struct
+ * @gc_bodies: array of display list bodies waiting to be freed
  */
 struct vsp1_dl_manager {
unsigned int index;
@@ -118,7 +118,7 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *pending;
 
struct work_struct gc_work;
-   struct list_head gc_fragments;
+   struct list_head gc_bodies;
 };
 
 /* 
-
@@ -156,17 +156,16 @@ static void vsp1_dl_body_cleanup(struct vsp1_dl_body *dlb)
 }
 
 /**
- * vsp1_dl_fragment_alloc - Allocate a display list fragment
+ * vsp1_dl_body_alloc - Allocate a display list body
  * @vsp1: The VSP1 device
- * @num_entries: The maximum number of entries that the fragment can contain
+ * @num_entries: The maximum number of entries that the body can contain
  *
- * Allocate a display list fragment with enough memory to contain the requested
+ * Allocate a display list body with enough memory to contain the requested
  * number of entries.
  *
- * Return a pointer to a fragment on success or NULL if memory can't be
- * allocated.
+ * Return a pointer to a body on success or NULL if memory can't be allocated.
  */
-struct vsp1_dl_body *vsp1_dl_fragment_alloc(struct vsp1_device *vsp1,
+struct vsp1_dl_body *vsp1_dl_body_alloc(struct vsp1_device *vsp1,
unsigned int num_entries)
 {
struct vsp1_dl_body *dlb;
@@ -186,20 +185,20 @@ 

[PATCH v4 0/9] vsp1: TLB optimisation and DL caching

[Kieran Bingham]

Each display list currently allocates an area of DMA memory to store register
settings for the VSP1 to process. Each of these allocations adds pressure to
the IPMMU TLB entries.

We can reduce the pressure by pre-allocating larger areas and dividing the area
across multiple bodies represented as a pool.

With this reconfiguration of bodies, we can adapt the configuration code to
separate out constant hardware configuration and cache it for re-use.

--

The patches provided in this series can be found at:
  git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git  
tags/vsp1/tlb-optimise/v4

This series is currently based on the v4.14 release tag.

Outstanding points remaining:

 v4l: vsp1: Provide a fragment pool:
  - extra_size is over allocated, but a Todo: has been added

 v4l: vsp1: Refactor display list configure operations
  - Determination of naming for prepare()/configure()

 v4l: vsp1: Adapt entities to configure into a body
  - Whether or not to rework to contain 'cached' body in a DL.

Changelog:
--

v4:
 - Rebased to v4.14
 * v4l: vsp1: Use reference counting for bodies
   - Fix up reference handling comments

 * v4l: vsp1: Provide a body pool
   - Provide comment explaining extra allocation on body pool
 highlighting area for optimisation later.

 * v4l: vsp1: Refactor display list configure operations
   - Fix up comment to describe yuv_mode caching rather than format

 * vsp1: Adapt entities to configure into a body
   - Rename vsp1_dl_list_get_body() to vsp1_dl_list_get_body0()

 * v4l: vsp1: Move video configuration to a cached dlb
   - Adjust pipe configured flag to be reset on resume rather than suspend
   - rename dl_child, dl_next

Testing:

The VSP unit tests have been run on this patch set with the following results:

- vsp-unit-test-0001.sh
Testing WPF packing in RGB332: pass
Testing WPF packing in ARGB555: pass
Testing WPF packing in XRGB555: pass
Testing WPF packing in RGB565: pass
Testing WPF packing in BGR24: pass
Testing WPF packing in RGB24: pass
Testing WPF packing in ABGR32: pass
Testing WPF packing in ARGB32: pass
Testing WPF packing in XBGR32: pass
Testing WPF packing in XRGB32: pass
- vsp-unit-test-0002.sh
Testing WPF packing in NV12M: pass
Testing WPF packing in NV16M: pass
Testing WPF packing in NV21M: pass
Testing WPF packing in NV61M: pass
Testing WPF packing in UYVY: pass
Testing WPF packing in VYUY: skip
Testing WPF packing in YUV420M: pass
Testing WPF packing in YUV422M: pass
Testing WPF packing in YUV444M: pass
Testing WPF packing in YVU420M: pass
Testing WPF packing in YVU422M: pass
Testing WPF packing in YVU444M: pass
Testing WPF packing in YUYV: pass
Testing WPF packing in YVYU: pass
- vsp-unit-test-0003.sh
Testing scaling from 640x640 to 640x480 in RGB24: pass
Testing scaling from 1024x768 to 640x480 in RGB24: pass
Testing scaling from 640x480 to 1024x768 in RGB24: pass
Testing scaling from 640x640 to 640x480 in YUV444M: pass
Testing scaling from 1024x768 to 640x480 in YUV444M: pass
Testing scaling from 640x480 to 1024x768 in YUV444M: pass
- vsp-unit-test-0004.sh
Testing histogram in RGB24: pass
Testing histogram in YUV444M: pass
- vsp-unit-test-0005.sh
Testing RPF.0: pass
Testing RPF.1: pass
Testing RPF.2: pass
Testing RPF.3: pass
Testing RPF.4: pass
- vsp-unit-test-0006.sh
Testing invalid pipeline with no RPF: pass
Testing invalid pipeline with no WPF: pass
- vsp-unit-test-0007.sh
Testing BRU in RGB24 with 1 inputs: pass
Testing BRU in RGB24 with 2 inputs: pass
Testing BRU in RGB24 with 3 inputs: pass
Testing BRU in RGB24 with 4 inputs: pass
Testing BRU in RGB24 with 5 inputs: pass
Testing BRU in YUV444M with 1 inputs: pass
Testing BRU in YUV444M with 2 inputs: pass
Testing BRU in YUV444M with 3 inputs: pass
Testing BRU in YUV444M with 4 inputs: pass
Testing BRU in YUV444M with 5 inputs: pass
- vsp-unit-test-0008.sh
Test requires unavailable feature set `bru rpf.0 uds wpf.0': skipped
- vsp-unit-test-0009.sh
Test requires unavailable feature set `rpf.0 wpf.0 wpf.1': skipped
- vsp-unit-test-0010.sh
Testing CLU in RGB24 with zero configuration: pass
Testing CLU in RGB24 with identity configuration: pass
Testing CLU in RGB24 with wave configuration: pass
Testing CLU in YUV444M with zero configuration: pass
Testing CLU in YUV444M with identity configuration: pass
Testing CLU in YUV444M with wave configuration: pass
Testing LUT in RGB24 with zero configuration: pass
Testing LUT in RGB24 with identity configuration: pass
Testing LUT in RGB24 with gamma configuration: pass
Testing LUT in YUV444M with zero configuration: pass
Testing LUT in YUV444M with identity configuration: pass
Testing LUT in YUV444M with gamma configuration: pass
- vsp-unit-test-0011.sh
Testing  hflip=0 vflip=0 rotate=0: pass
Testing  hflip=1 vflip=0 rotate=0: pass
Testing  hflip=0 vflip=1 rotate=0: pass
Testing  hflip=1 vflip=1 rotate=0: pass
Testing  hflip=0 vflip=0 rotate=90: pass
Testing  hflip=1 vflip=0 rotate=90: pass
Testing  hflip=0 vflip=1 rotate=90: pass

[PATCH] media: cx231xx: add support for TheImagingSource DFG/USB2pro

[Romain Reignier]

Hello,

This is my first patch to the kernel so please be indulgent if I have done 
anything wrong and help me produce a better submission.

This is a patch to add the support for The Imaging Source DFG/USB2pro USB 
capture device. It is based on the Conexant CX23102 chip do the patch only 
consists in adding one entry in the devices list.

Note that the inputs for the Composite and S-Video are inverted in regard to 
most of the other boards.

I could test the Composite input that is working for several months in some of 
our products. But did not have the chance to try the S-Video input because I 
do not own any device with that standard (I have tried a simple Composite to 
S-Video cable but it does not work, even on Windows). So I have applied the 
same settings as the Windows driver.

I have created a page on the Wiki to describe the board:
https://www.linuxtv.org/wiki/index.php/The_Imaging_Source_DFG-USB2pro

Sincerely,

Romain Reignier

---

>From 13d83af3e6e5c01b43875d67cdcc3312ebbc6c7a Mon Sep 17 00:00:00 2001
From: Romain Reignier 
Date: Fri, 17 Nov 2017 15:52:40 +0100
Subject: [PATCH] media: cx231xx: add support for TheImagingSource DFG/USB2pro

Signed-off-by: Romain Reignier 
---
 drivers/media/usb/cx231xx/cx231xx-cards.c | 28 
 drivers/media/usb/cx231xx/cx231xx.h   |  1 +
 2 files changed, 29 insertions(+)

diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 54d9d0c..99c8b1a 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -896,6 +896,32 @@ struct cx231xx_board cx231xx_boards[] = {
},
},
},
+   [CX231XX_BOARD_THE_IMAGING_SOURCE_DFG_USB2_PRO] = {
+   .name = "The Imaging Source DFG/USB2pro",
+   .tuner_type = TUNER_ABSENT,
+   .decoder = CX231XX_AVDECODER,
+   .output_mode = OUT_MODE_VIP11,
+   .demod_xfer_mode = 0,
+   .ctl_pin_status_mask = 0xFFC4,
+   .agc_analog_digital_select_gpio = 0x0c,
+   .gpio_pin_status_mask = 0x4001000,
+   .norm = V4L2_STD_PAL,
+   .no_alt_vanc = 1,
+   .external_av = 1,
+   .input = {{
+   .type = CX231XX_VMUX_COMPOSITE1,
+   .vmux = CX231XX_VIN_1_1,
+   .amux = CX231XX_AMUX_LINE_IN,
+   .gpio = NULL,
+   }, {
+   .type = CX231XX_VMUX_SVIDEO,
+   .vmux = CX231XX_VIN_2_1 |
+   (CX231XX_VIN_2_2 << 8) |
+   CX25840_SVIDEO_ON,
+   .amux = CX231XX_AMUX_LINE_IN,
+   .gpio = NULL,
+   } },
+   },
 };
 const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
 
@@ -967,6 +993,8 @@ struct usb_device_id cx231xx_id_table[] = {
.driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
{USB_DEVICE(0x15f4, 0x0135),
.driver_info = CX231XX_BOARD_ASTROMETA_T2HYBRID},
+   {USB_DEVICE(0x199e, 0x8002),
+.driver_info = CX231XX_BOARD_THE_IMAGING_SOURCE_DFG_USB2_PRO},
{},
 };
 
diff --git a/drivers/media/usb/cx231xx/cx231xx.h 
b/drivers/media/usb/cx231xx/cx231xx.h
index 72d5937..65b039c 100644
--- a/drivers/media/usb/cx231xx/cx231xx.h
+++ b/drivers/media/usb/cx231xx/cx231xx.h
@@ -80,6 +80,7 @@
 #define CX231XX_BOARD_TERRATEC_GRABBY 22
 #define CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD 23
 #define CX231XX_BOARD_ASTROMETA_T2HYBRID 24
+#define CX231XX_BOARD_THE_IMAGING_SOURCE_DFG_USB2_PRO 25
 
 /* Limits minimum and default number of buffers */
 #define CX231XX_MIN_BUF 4
-- 
2.7.4

Re: [PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Greg Kroah-Hartman]

On Fri, Nov 17, 2017 at 12:58:47PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Nov 2017 15:18:26 +0100
> Greg Kroah-Hartman  escreveu:
> 
> > There is no need to #define the license of the driver, just put it in
> > the MODULE_LICENSE() line directly as a text string.
> > 
> > This allows tools that check that the module license matches the source
> > code license to work properly, as there is no need to unwind the
> > unneeded dereference.
> > 
> > Cc: Hans Verkuil 
> > Cc: Mauro Carvalho Chehab 
> > Cc: Johan Hovold 
> > Cc: Davidlohr Bueso 
> > Cc: Sakari Ailus 
> > Reported-by: Philippe Ombredanne 
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> >  drivers/media/usb/usbvision/usbvision-video.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/media/usb/usbvision/usbvision-video.c 
> > b/drivers/media/usb/usbvision/usbvision-video.c
> > index 960272d3c924..0f5954a1fea2 100644
> > --- a/drivers/media/usb/usbvision/usbvision-video.c
> > +++ b/drivers/media/usb/usbvision/usbvision-video.c
> > @@ -72,7 +72,6 @@
> >  #define DRIVER_NAME "usbvision"
> >  #define DRIVER_ALIAS "USBVision"
> >  #define DRIVER_DESC "USBVision USB Video Device Driver for Linux"
> > -#define DRIVER_LICENSE "GPL"
> >  #define USBVISION_VERSION_STRING "0.9.11"
> >  
> >  #defineENABLE_HEXDUMP  0   /* Enable if you need it */
> > @@ -141,7 +140,7 @@ MODULE_PARM_DESC(radio_nr, "Set radio device number 
> > (/dev/radioX).  Default: -1
> >  /* Misc stuff */
> >  MODULE_AUTHOR(DRIVER_AUTHOR);
> >  MODULE_DESCRIPTION(DRIVER_DESC);
> > -MODULE_LICENSE(DRIVER_LICENSE);
> > +MODULE_LICENSE("GPL");
> 
> Makes sense to me, but, if we look at the header of this file:
> 
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License as published by
>  * the Free Software Foundation; either version 2 of the License, or
>  * (at your option) any later version.
> 
> Its license is actually GPL 2.0+
> 
> So, I would actually change it to:
> 
> MODULE_LICENSE("GPL v2");

As Philippe points out, the original marking is correct.

Once we get SPDX tags on all of the kernel files, mis-matches, if they
are present, will be obvious to check for and fix up.  Which is why I
have submitted this patch :)

thanks,

greg k-h

Re: [PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

[Simon Horman]

On Thu, Nov 16, 2017 at 06:22:49PM +, Fabrizio Castro wrote:
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Reviewed-by: Simon Horman 

Re: [PATCH v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list

[Simon Horman]

On Thu, Nov 16, 2017 at 06:22:48PM +, Fabrizio Castro wrote:
> Change the sorting of the part numbers from descending to ascending to
> match with other documentation.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Reviewed-by: Simon Horman 

Re: [PATCH 6/6] media: usb: add SPDX identifiers to some code I wrote

[Philippe Ombredanne]

On Fri, Nov 17, 2017 at 4:01 PM, Mauro Carvalho Chehab
 wrote:
> Em Fri, 17 Nov 2017 12:54:15 +0100
> Philippe Ombredanne  escreveu:
>
>> On Fri, Nov 17, 2017 at 11:21 AM, Mauro Carvalho Chehab
>>  wrote:
>> > As we're now using SPDX identifiers, on several
>> > media drivers I wrote, add the proper SPDX, identifying
>> > the license I meant.
>> >
>> > As we're now using the short license, it doesn't make sense to
>> > keep the original license text.
>> >
>> > Also, fix MODULE_LICENSE to properly identify GPL v2.
>> >
>> > Signed-off-by: Mauro Carvalho Chehab 
>>
>> Mauro,
>> Thanks ++  I can now get rid of a special license detection rule I
>> had added for the specific language of your notices in the
>> scancode-toolkit!
>
> :-)
>
> Yeah, I was too lazy to copy the usual GPL preamble on those
> drivers ;-)

I guess I built a lazyness checker with scancode to keep you check then ;)
But FWIW you are not alone there and at least your notices are/were
consistent across files ... there are still several hundred variations
of GPL notices in the kernel each with subtle or byzantine changes.

Some of them are rather funny like Evgeniy's thermal code being under
the "therms" of the GPL [1]

CC: Evgeniy Polyakov 

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/w1/slaves/w1_therm.c?h=v4.14-rc8#n8
-- 
Cordially
Philippe Ombredanne

Re: [PATCH v2 5/8] v4l: vsp1: Refactor display list configure operations

[Kieran Bingham]

Hi Laurent,

Just a query on your bikeshedding here.

Choose your colours wisely :)

--
Kieran

On 12/09/17 20:19, Laurent Pinchart wrote:
> Hi Kieran,
> 
> On Tuesday, 12 September 2017 00:16:50 EEST Kieran Bingham wrote:
>> On 17/08/17 19:13, Laurent Pinchart wrote:
>>> On Monday 14 Aug 2017 16:13:28 Kieran Bingham wrote:
 The entities provide a single .configure operation which configures the
 object into the target display list, based on the vsp1_entity_params
 selection.

 This restricts us to a single function prototype for both static
 configuration (the pre-stream INIT stage) and the dynamic runtime stages
 for both each frame - and each partition therein.

 Split the configure function into two parts, '.prepare()' and
 '.configure()', merging both the VSP1_ENTITY_PARAMS_RUNTIME and
 VSP1_ENTITY_PARAMS_PARTITION stages into a single call through the
 .configure(). The configuration for individual partitions is handled by
 passing the partition number to the configure call, and processing any
 runtime stage actions on the first partition only.

 Signed-off-by: Kieran Bingham 
 ---

  drivers/media/platform/vsp1/vsp1_bru.c|  12 +-
  drivers/media/platform/vsp1/vsp1_clu.c|  43 +--
  drivers/media/platform/vsp1/vsp1_drm.c|  11 +-
  drivers/media/platform/vsp1/vsp1_entity.c |  15 +-
  drivers/media/platform/vsp1/vsp1_entity.h |  27 +--
  drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
  drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
  drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
  drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
  drivers/media/platform/vsp1/vsp1_lut.c|  24 +-
  drivers/media/platform/vsp1/vsp1_rpf.c| 162 ++---
  drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
  drivers/media/platform/vsp1/vsp1_uds.c|  55 ++--
  drivers/media/platform/vsp1/vsp1_video.c  |  24 +--
  drivers/media/platform/vsp1/vsp1_wpf.c| 297 ---
  15 files changed, 359 insertions(+), 371 deletions(-)
>>>
>>> [snip]
>>>
 diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
 b/drivers/media/platform/vsp1/vsp1_clu.c index 175717018e11..5f65ce3ad97f
 100644
 --- a/drivers/media/platform/vsp1/vsp1_clu.c
 +++ b/drivers/media/platform/vsp1/vsp1_clu.c
 @@ -213,37 +213,37 @@ static const struct v4l2_subdev_ops clu_ops = {

  /*
  ---
  -
  
   * VSP1 Entity Operations
   */

 +static void clu_prepare(struct vsp1_entity *entity,
 +  struct vsp1_pipeline *pipe,
 +  struct vsp1_dl_list *dl)
 +{
 +  struct vsp1_clu *clu = to_clu(>subdev);
 +
 +  /*
 +   * The format can't be changed during streaming, only verify it
 +   * at setup time and store the information internally for future
 +   * runtime configuration calls.
 +   */
>>>
>>> I know you're just moving the comment around, but let's fix it at the same
>>> time. There's no verification here (and no "setup time" either). I'd write
>>> it as
>>>
>>> /*
>>> 
>>>  * The format can't be changed during streaming. Cache it internally
>>>  * for future runtime configuration calls.
>>>  */
>>
>> I think I'm ok with that and I've updated the patch - but I'm not sure we
>> are really caching the 'format' here, as much as the yuv_mode ...
> 
> Yes, it's the YUV mode we're caching, feel free to update the comment.

Done.

> 
>> I'll ponder ...
>>
 +  struct v4l2_mbus_framefmt *format;
 +
 +  format = vsp1_entity_get_pad_format(>entity,
 +  clu->entity.config,
 +  CLU_PAD_SINK);
 +  clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
 +}
>>>
>>> [snip]
>>>
 diff --git a/drivers/media/platform/vsp1/vsp1_entity.h
 b/drivers/media/platform/vsp1/vsp1_entity.h index
 408602ebeb97..2f33e343ccc6 100644
 --- a/drivers/media/platform/vsp1/vsp1_entity.h
 +++ b/drivers/media/platform/vsp1/vsp1_entity.h
>>>
>>> [snip]
>>>
 @@ -80,8 +68,10 @@ struct vsp1_route {

  /**
  
   * struct vsp1_entity_operations - Entity operations
   * @destroy:  Destroy the entity.

 - * @configure:Setup the hardware based on the entity state
 (pipeline, formats,
 - *selection rectangles, ...)
 + * @prepare:  Setup the initial hardware parameters for the stream
 (pipeline,
 + *formats)
 + * @configure:Configure the runtime parameters for each partition
 (rectangles,
 + *buffer addresses, ...)
>>>
>>> Now moving to the bikeshedding territory, I'm not sure if prepare and
>>> configure are the best names for those 

Re: [PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Philippe Ombredanne]

On Fri, Nov 17, 2017 at 3:58 PM, Mauro Carvalho Chehab
 wrote:
> Em Fri, 17 Nov 2017 15:18:26 +0100
> Greg Kroah-Hartman  escreveu:
>
>> There is no need to #define the license of the driver, just put it in
>> the MODULE_LICENSE() line directly as a text string.
>>
>> This allows tools that check that the module license matches the source
>> code license to work properly, as there is no need to unwind the
>> unneeded dereference.
>>
>> Cc: Hans Verkuil 
>> Cc: Mauro Carvalho Chehab 
>> Cc: Johan Hovold 
>> Cc: Davidlohr Bueso 
>> Cc: Sakari Ailus 
>> Reported-by: Philippe Ombredanne 
>> Signed-off-by: Greg Kroah-Hartman 
>> ---
>>  drivers/media/usb/usbvision/usbvision-video.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/usb/usbvision/usbvision-video.c 
>> b/drivers/media/usb/usbvision/usbvision-video.c
>> index 960272d3c924..0f5954a1fea2 100644
>> --- a/drivers/media/usb/usbvision/usbvision-video.c
>> +++ b/drivers/media/usb/usbvision/usbvision-video.c
>> @@ -72,7 +72,6 @@
>>  #define DRIVER_NAME "usbvision"
>>  #define DRIVER_ALIAS "USBVision"
>>  #define DRIVER_DESC "USBVision USB Video Device Driver for Linux"
>> -#define DRIVER_LICENSE "GPL"
>>  #define USBVISION_VERSION_STRING "0.9.11"
>>
>>  #define  ENABLE_HEXDUMP  0   /* Enable if you need it */
>> @@ -141,7 +140,7 @@ MODULE_PARM_DESC(radio_nr, "Set radio device number 
>> (/dev/radioX).  Default: -1
>>  /* Misc stuff */
>>  MODULE_AUTHOR(DRIVER_AUTHOR);
>>  MODULE_DESCRIPTION(DRIVER_DESC);
>> -MODULE_LICENSE(DRIVER_LICENSE);
>> +MODULE_LICENSE("GPL");
>
> Makes sense to me, but, if we look at the header of this file:
>
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License as published by
>  * the Free Software Foundation; either version 2 of the License, or
>  * (at your option) any later version.
>
> Its license is actually GPL 2.0+
>
> So, I would actually change it to:
>
> MODULE_LICENSE("GPL v2");

Mauro:

actually even if it sounds weird the module.h doc [1] is clear on this topic:

 * "GPL" [GNU Public License v2 or later]
 * "GPL v2" [GNU Public License v2]

So it should be "GPL" IMHO.


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h?id=refs/tags/v4.10#n175

-- 
Cordially
Philippe Ombredanne

Re: [PATCH 6/6] media: usb: add SPDX identifiers to some code I wrote

[Mauro Carvalho Chehab]

Em Fri, 17 Nov 2017 12:54:15 +0100
Philippe Ombredanne  escreveu:

> On Fri, Nov 17, 2017 at 11:21 AM, Mauro Carvalho Chehab
>  wrote:
> > As we're now using SPDX identifiers, on several
> > media drivers I wrote, add the proper SPDX, identifying
> > the license I meant.
> >
> > As we're now using the short license, it doesn't make sense to
> > keep the original license text.
> >
> > Also, fix MODULE_LICENSE to properly identify GPL v2.
> >
> > Signed-off-by: Mauro Carvalho Chehab   
> 
> Mauro,
> Thanks ++  I can now get rid of a special license detection rule I
> had added for the specific language of your notices in the
> scancode-toolkit!

:-)

Yeah, I was too lazy to copy the usual GPL preamble on those
drivers ;-)

> 
> FWIW for this 6 patch series:
> 
> Reviewed-by: Philippe Ombredanne 

Thanks!
Mauro

Re: [PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Mauro Carvalho Chehab]

Em Fri, 17 Nov 2017 15:18:26 +0100
Greg Kroah-Hartman  escreveu:

> There is no need to #define the license of the driver, just put it in
> the MODULE_LICENSE() line directly as a text string.
> 
> This allows tools that check that the module license matches the source
> code license to work properly, as there is no need to unwind the
> unneeded dereference.
> 
> Cc: Hans Verkuil 
> Cc: Mauro Carvalho Chehab 
> Cc: Johan Hovold 
> Cc: Davidlohr Bueso 
> Cc: Sakari Ailus 
> Reported-by: Philippe Ombredanne 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  drivers/media/usb/usbvision/usbvision-video.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/media/usb/usbvision/usbvision-video.c 
> b/drivers/media/usb/usbvision/usbvision-video.c
> index 960272d3c924..0f5954a1fea2 100644
> --- a/drivers/media/usb/usbvision/usbvision-video.c
> +++ b/drivers/media/usb/usbvision/usbvision-video.c
> @@ -72,7 +72,6 @@
>  #define DRIVER_NAME "usbvision"
>  #define DRIVER_ALIAS "USBVision"
>  #define DRIVER_DESC "USBVision USB Video Device Driver for Linux"
> -#define DRIVER_LICENSE "GPL"
>  #define USBVISION_VERSION_STRING "0.9.11"
>  
>  #define  ENABLE_HEXDUMP  0   /* Enable if you need it */
> @@ -141,7 +140,7 @@ MODULE_PARM_DESC(radio_nr, "Set radio device number 
> (/dev/radioX).  Default: -1
>  /* Misc stuff */
>  MODULE_AUTHOR(DRIVER_AUTHOR);
>  MODULE_DESCRIPTION(DRIVER_DESC);
> -MODULE_LICENSE(DRIVER_LICENSE);
> +MODULE_LICENSE("GPL");

Makes sense to me, but, if we look at the header of this file:

 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.

Its license is actually GPL 2.0+

So, I would actually change it to:

MODULE_LICENSE("GPL v2");

Regard

Thanks,
Mauro

[PATCH v2] media: ABS macro parameter parenthesization

[dgopstein]

From: Dan Gopstein 

Two definitions of the ABS (absolute value) macro fail to parenthesize
their parameter properly. This can lead to a bad expansion for
low-precedence expression arguments. Add parens to protect against
troublesome arguments.

For example: ABS(1-2) currently expands to ((1-2) < 0 ? (-1-2) : (1-2))
which evaluates to -3. But the correct expansion would be
((1-2) < 0 ? -(1-2) : (1-2)) which evaluates to 1.

Signed-off-by: Dan Gopstein 
---
v1->v2:
* unmangled the patch
* added example to commit text

 drivers/media/dvb-frontends/dibx000_common.h | 2 +-
 drivers/media/dvb-frontends/mb86a16.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/dibx000_common.h 
b/drivers/media/dvb-frontends/dibx000_common.h
index 8784af9..ae60f5d 100644
--- a/drivers/media/dvb-frontends/dibx000_common.h
+++ b/drivers/media/dvb-frontends/dibx000_common.h
@@ -223,7 +223,7 @@ struct dvb_frontend_parametersContext {
 
 #define FE_CALLBACK_TIME_NEVER 0x
 
-#define ABS(x) ((x < 0) ? (-x) : (x))
+#define ABS(x) (((x) < 0) ? -(x) : (x))
 
 #define DATA_BUS_ACCESS_MODE_8BIT 0x01
 #define DATA_BUS_ACCESS_MODE_16BIT0x02
diff --git a/drivers/media/dvb-frontends/mb86a16.c 
b/drivers/media/dvb-frontends/mb86a16.c
index dfe322e..2d921c7 100644
--- a/drivers/media/dvb-frontends/mb86a16.c
+++ b/drivers/media/dvb-frontends/mb86a16.c
@@ -31,7 +31,7 @@
 static unsigned int verbose = 5;
 module_param(verbose, int, 0644);
 
-#define ABS(x) ((x) < 0 ? (-x) : (x))
+#define ABS(x) ((x) < 0 ? -(x) : (x))
 
 struct mb86a16_state {
struct i2c_adapter  *i2c_adap;
-- 
2.7.4

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

[Matthias Reichl]

Hi Sean!

On Thu, Nov 16, 2017 at 09:54:51PM +, Sean Young wrote:
> Since commit d57ea877af38 ("media: rc: per-protocol repeat period"),
> double keypresses are reported on the ite-cir driver. This is due
> two factors: that commit reduced the timeout used for some protocols
> (it became protocol dependant) and the high default IR timeout used
> by the ite-cir driver.
> 
> Some of the IR decoders wait for a trailing space, as that is
> the only way to know if the bit stream has ended (e.g. rc-6 can be
> 16, 20 or 32 bits). The longer the IR timeout, the longer it will take
> to receive the trailing space, delaying decoding and pushing it past the
> keyup timeout.
> 
> So, add the IR timeout to the keyup timeout.

Thanks a lot for the patch, I've asked the people with ite-cir
receivers to test it.

In the meanwhile I ran some tests with gpio-ir-recv and timeout
set to 200ms with a rc-5 remote (that's as close to the original
setup as I can test right now).

While the patch fixes the additional key down/up event on longer
presses, I still get a repeated key event on a short button
press - which makes it hard to do a single click with the
remote.

Test on kernel 4.14 with your patch:
1510927844.292126: event type EV_MSC(0x04): scancode = 0x1015
1510927844.292126: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
1510927844.292126: event type EV_SYN(0x00).
1510927844.498773: event type EV_MSC(0x04): scancode = 0x1015
1510927844.498773: event type EV_SYN(0x00).
1510927844.795410: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
1510927844.795410: event type EV_SYN(0x00).
1510927844.875412: event type EV_KEY(0x01) key_up: KEY_ENTER(0x001c)
1510927844.875412: event type EV_SYN(0x00).

Same signal received on kernel 4.9:
1510927844.280350: event type EV_MSC(0x04): scancode = 0x1015
1510927844.280350: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
1510927844.280350: event type EV_SYN(0x00).
1510927844.506477: event type EV_MSC(0x04): scancode = 0x1015
1510927844.506477: event type EV_SYN(0x00).
1510927844.763111: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
1510927844.763111: event type EV_SYN(0x00).

If I understand it correctly it's the input layer repeat (500ms delay)
kicking in, because time between initial scancode and timeout is
now signal time + 200ms + 164ms + 200ms (about 570-580ms).
On older kernels this was signal time + 200ms + 250ms, so typically
just below the 500ms default repeat delay.

I'm still trying to wrap my head around the timeout code in the
rc layer. One problem seems to be that we apply the rather large
timeout twice. Maybe detecting scancodes generated via timeout
(sth like timestamp - last_timestamp > protocol_repeat_period)
and in that case immediately signalling keyup could help? Could well
be that I'm missing somehting important and this is a bad idea.
I guess I'd better let you figure something out :)

so long,

Hias

> 
> Cc:  # 4.14
> Reported-by: Matthias Reichl 
> Signed-off-by: Sean Young 
> ---
>  drivers/media/rc/rc-main.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 17950e29d4e3..fae721534517 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -672,7 +672,8 @@ void rc_repeat(struct rc_dev *dev)
>   input_event(dev->input_dev, EV_MSC, MSC_SCAN, dev->last_scancode);
>   input_sync(dev->input_dev);
>  
> - dev->keyup_jiffies = jiffies + msecs_to_jiffies(timeout);
> + dev->keyup_jiffies = jiffies + msecs_to_jiffies(timeout) +
> + nsecs_to_jiffies(dev->timeout);
>   mod_timer(>timer_keyup, dev->keyup_jiffies);
>  
>  out:
> @@ -744,7 +745,8 @@ void rc_keydown(struct rc_dev *dev, enum rc_proto 
> protocol, u32 scancode,
>  
>   if (dev->keypressed) {
>   dev->keyup_jiffies = jiffies +
> - msecs_to_jiffies(protocols[protocol].repeat_period);
> + msecs_to_jiffies(protocols[protocol].repeat_period) +
> + nsecs_to_jiffies(dev->timeout);
>   mod_timer(>timer_keyup, dev->keyup_jiffies);
>   }
>   spin_unlock_irqrestore(>keylock, flags);
> -- 
> 2.14.3
> 

Re: [PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Philippe Ombredanne]

On Fri, Nov 17, 2017 at 3:18 PM, Greg Kroah-Hartman
 wrote:
> There is no need to #define the license of the driver, just put it in
> the MODULE_LICENSE() line directly as a text string.
>
> This allows tools that check that the module license matches the source
> code license to work properly, as there is no need to unwind the
> unneeded dereference.
>
> Cc: Hans Verkuil 
> Cc: Mauro Carvalho Chehab 
> Cc: Johan Hovold 
> Cc: Davidlohr Bueso 
> Cc: Sakari Ailus 
> Reported-by: Philippe Ombredanne 
> Signed-off-by: Greg Kroah-Hartman 


Reviewed-by: Philippe Ombredanne 
-- 
Cordially
Philippe Ombredanne

Re: [RFCv1 PATCH 1/6] v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev

[Hans Verkuil]

On 17/11/17 14:41, Mauro Carvalho Chehab wrote:
> Em Mon, 13 Nov 2017 15:34:03 +0100
> Hans Verkuil  escreveu:
> 
>> From: Hans Verkuil 
>>
>> Add a 'bool from_other_dev' argument: set to true if the two
>> handlers refer to different devices (e.g. it is true when
>> inheriting controls from a subdev into a main v4l2 bridge
>> driver).
>>
>> This will be used later when implementing support for the
>> request API since we need to skip such controls.
>>
>> TODO: check drivers/staging/media/imx/imx-media-fim.c change.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  drivers/media/dvb-frontends/rtl2832_sdr.c|  5 +--
>>  drivers/media/pci/bt8xx/bttv-driver.c|  2 +-
>>  drivers/media/pci/cx23885/cx23885-417.c  |  2 +-
>>  drivers/media/pci/cx88/cx88-blackbird.c  |  2 +-
>>  drivers/media/pci/cx88/cx88-video.c  |  2 +-
>>  drivers/media/pci/saa7134/saa7134-empress.c  |  4 +--
>>  drivers/media/pci/saa7134/saa7134-video.c|  2 +-
>>  drivers/media/platform/exynos4-is/fimc-capture.c |  2 +-
>>  drivers/media/platform/rcar-vin/rcar-v4l2.c  |  3 +-
>>  drivers/media/platform/rcar_drif.c   |  2 +-
>>  drivers/media/platform/soc_camera/soc_camera.c   |  3 +-
>>  drivers/media/platform/vivid/vivid-ctrls.c   | 42 
>> 
>>  drivers/media/usb/cx231xx/cx231xx-417.c  |  2 +-
>>  drivers/media/usb/cx231xx/cx231xx-video.c|  4 +--
>>  drivers/media/usb/msi2500/msi2500.c  |  2 +-
>>  drivers/media/usb/tm6000/tm6000-video.c  |  2 +-
>>  drivers/media/v4l2-core/v4l2-ctrls.c | 11 ---
>>  drivers/media/v4l2-core/v4l2-device.c|  3 +-
>>  drivers/staging/media/imx/imx-media-dev.c|  2 +-
>>  drivers/staging/media/imx/imx-media-fim.c|  2 +-
>>  include/media/v4l2-ctrls.h   |  4 ++-
> 
> You forgot to update Documentation/media/kapi/v4l2-controls.rst.
> 
>>  21 files changed, 56 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/media/dvb-frontends/rtl2832_sdr.c 
>> b/drivers/media/dvb-frontends/rtl2832_sdr.c
>> index c6e78d870ccd..6064d28224e8 100644
>> --- a/drivers/media/dvb-frontends/rtl2832_sdr.c
>> +++ b/drivers/media/dvb-frontends/rtl2832_sdr.c
>> @@ -1394,7 +1394,8 @@ static int rtl2832_sdr_probe(struct platform_device 
>> *pdev)
>>  case RTL2832_SDR_TUNER_E4000:
>>  v4l2_ctrl_handler_init(>hdl, 9);
>>  if (subdev)
>> -v4l2_ctrl_add_handler(>hdl, subdev->ctrl_handler, 
>> NULL);
>> +v4l2_ctrl_add_handler(>hdl, subdev->ctrl_handler,
>> +  NULL, true);
> 
> Changing all drivers to tell if a control belongs to a subdev or not
> seems weird. I won't doubt that people may get it wrong and fill it
> with a wrong value.
> 
> IMHO, it would be better, instead, to pass some struct to the function
> that would allow the function to check if the device is a subdev
> or not.
> 
> For example, we could do:
> 
> int v4l2_ctrl_subdev_add_handler(struct v4l2_ctrl_handler *hdl,
>struct v4l2_subdev *sd,
>v4l2_ctrl_filter filter);
> 
> That should be used for all subdev controls. Internally, such
> function would be using:
>   sd->control_handler
> as the add parameter for v4l2_ctrl_add_handler().
> 
> I would also try to do the same for devices: have a
> v4l2_ctrl_dev_add_handler() that would take a struct v4l2_dev, and
> make v4l2_ctrl_add_handler() a static function inside v4l2-ctrls.c.
> 
> This way, we should avoid the risk of wrong usages.

You can ignore this patch. I'm not happy with it either, and I'm pretty
sure it is not needed for the stateless codec use-case.

Regards,

Hans

Re: [PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Hans Verkuil]

On 17/11/17 15:18, Greg Kroah-Hartman wrote:
> There is no need to #define the license of the driver, just put it in
> the MODULE_LICENSE() line directly as a text string.
> 
> This allows tools that check that the module license matches the source
> code license to work properly, as there is no need to unwind the
> unneeded dereference.
> 
> Cc: Hans Verkuil 
> Cc: Mauro Carvalho Chehab 
> Cc: Johan Hovold 
> Cc: Davidlohr Bueso 
> Cc: Sakari Ailus 
> Reported-by: Philippe Ombredanne 
> Signed-off-by: Greg Kroah-Hartman 

Acked-by: Hans Verkuil 

Thanks!

Hans

> ---
>  drivers/media/usb/usbvision/usbvision-video.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/media/usb/usbvision/usbvision-video.c 
> b/drivers/media/usb/usbvision/usbvision-video.c
> index 960272d3c924..0f5954a1fea2 100644
> --- a/drivers/media/usb/usbvision/usbvision-video.c
> +++ b/drivers/media/usb/usbvision/usbvision-video.c
> @@ -72,7 +72,6 @@
>  #define DRIVER_NAME "usbvision"
>  #define DRIVER_ALIAS "USBVision"
>  #define DRIVER_DESC "USBVision USB Video Device Driver for Linux"
> -#define DRIVER_LICENSE "GPL"
>  #define USBVISION_VERSION_STRING "0.9.11"
>  
>  #define  ENABLE_HEXDUMP  0   /* Enable if you need it */
> @@ -141,7 +140,7 @@ MODULE_PARM_DESC(radio_nr, "Set radio device number 
> (/dev/radioX).  Default: -1
>  /* Misc stuff */
>  MODULE_AUTHOR(DRIVER_AUTHOR);
>  MODULE_DESCRIPTION(DRIVER_DESC);
> -MODULE_LICENSE(DRIVER_LICENSE);
> +MODULE_LICENSE("GPL");
>  MODULE_VERSION(USBVISION_VERSION_STRING);
>  MODULE_ALIAS(DRIVER_ALIAS);
>  
> 

Re: [RFC v5 06/11] [media] vb2: add explicit fence user API

[Hans Verkuil]

On 17/11/17 14:53, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Nov 2017 14:29:23 +0100
> Hans Verkuil  escreveu:
> 
>> On 15/11/17 18:10, Gustavo Padovan wrote:
>>> From: Gustavo Padovan 
>>>
>>> Turn the reserved2 field into fence_fd that we will use to send
>>> an in-fence to the kernel and return an out-fence from the kernel to
>>> userspace.
>>>
>>> Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
>>> when sending a fence to the kernel to be waited on, and
>>> V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
>>>
>>> v4:
>>> - make it a union with reserved2 and fence_fd (Hans Verkuil)
>>>
>>> v3:
>>> - make the out_fence refer to the current buffer (Hans Verkuil)
>>>
>>> v2: add documentation
>>>
>>> Signed-off-by: Gustavo Padovan 
>>> ---
>>>  Documentation/media/uapi/v4l/buffer.rst   | 15 +++
>>>  drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
>>>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
>>>  drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
>>>  include/uapi/linux/videodev2.h|  7 ++-
>>>  5 files changed, 25 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
>>> b/Documentation/media/uapi/v4l/buffer.rst
>>> index ae6ee73f151c..eeefbd2547e7 100644
>>> --- a/Documentation/media/uapi/v4l/buffer.rst
>>> +++ b/Documentation/media/uapi/v4l/buffer.rst
>>> @@ -648,6 +648,21 @@ Buffer Flags
>>>- Start Of Exposure. The buffer timestamp has been taken when the
>>> exposure of the frame has begun. This is only valid for the
>>> ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
>>> +* .. _`V4L2-BUF-FLAG-IN-FENCE`:
>>> +
>>> +  - ``V4L2_BUF_FLAG_IN_FENCE``
>>> +  - 0x0020
>>> +  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
>>> +   won't be queued to the driver until the fence signals.
>>> +
>>> +* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
>>> +
>>> +  - ``V4L2_BUF_FLAG_OUT_FENCE``
>>> +  - 0x0040
>>> +  - Request a fence to be attached to the buffer. The ``fence_fd``
>>> +   field on
>>> +   :ref:`VIDIOC_QBUF` is used as a return argument to send the out-fence
>>> +   fd to userspace.  
>>
>> How would userspace know if fences are not supported? E.g. any driver that 
>> does
>> not use vb2 will have no support for it.
>>
>> While the driver could clear the flag on return, the problem is that it is a 
>> bit
>> late for applications to discover lack of fence support.
>>
>> Perhaps we do need a capability flag for this? I wonder what others think.
> 
> We're almost running out of flags at v4l2 caps (and at struct v4l2_buffer).

struct v4l2_capability has more than enough room to add a new device_caps2 
field.
So I see no problem there, and it is very useful for applications to know what
features are supported up front and not when you start to use them.

Think about it: you're setting up complete fence support in your application, 
only
to discover when you queue the first buffer that there is no fence support! That
doesn't work.

The reserved[] array wasn't added for nothing to v4l2_capability.

struct v4l2_buffer is indeed very full. But I posted an RFC on October 26 
introducing
a struct v4l2_ext_buffer, designed from scratch. We can switch to a u64 flags 
there.

See here: 
https://www.mail-archive.com/linux-media@vger.kernel.org/msg121215.html

I am waiting for fences and the request API to go in before continuing with that
RFC series, unless we think it is better to only support fences/request API with
this redesign. Let me know and I can pick up development of that RFC.

> 
> So, I would prefer to not add more flags on those structs if there is
> another way.
> 
> As the fences out of order flags should go to ENUM_FMT (and, currently
> there's just one flag defined there), I wander if it would make sense
> to also add CAN_IN_FENCES/CAN_OUT_FENCES flags there, as maybe we
> would want to disable/enable fences based on the format.

I don't see a reason for that. There is no relationship between formats
and fences. Fences apply to buffers, not formats. Whereas the 'ordered'
value can be specific to a format.

Regards,

Hans

[PATCH] media: coda: fix comparision of decoded frames' indexes

[Martin Kepplinger]

At this point the driver looks the currently decoded frame's index
and compares is to VPU-specific state values. Directly before this
if and else statements the indexes are read (index for decoded and
for displayed frame).

Now what is saved in ctx->display_idx is an older value at this point!
During these index checks, the current values apply, so fix this by
taking display_idx instead of ctx->display_idx.

ctx->display_idx is updated later in the same function.

Signed-off-by: Martin Kepplinger 
---

Please review this thoroughly, but in case I am wrong here, this is
at least very strange to read and *should* be accompanied with a
comment about what's going on with that index value!

I don't think it matter that much here because at least playing h264
worked before and works with this change, but I've tested it anyways.

thanks

   martin


 drivers/media/platform/coda/coda-bit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index bfc4ecf6f068..fe38527a90e2 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2089,7 +2089,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
/* no frame was decoded, but we might have a display frame */
if (display_idx >= 0 && display_idx < ctx->num_internal_frames)
ctx->sequence_offset++;
-   else if (ctx->display_idx < 0)
+   else if (display_idx < 0)
ctx->hold = true;
} else if (decoded_idx == -2) {
/* no frame was decoded, we still return remaining buffers */
-- 
2.11.0

Re: [PATCH v1 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

[Simon Horman]

On Wed, Nov 15, 2017 at 11:55:57AM +0100, Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.

Other patches in this series (which are not for my tree) appear
to warrant updating. Accordingly I am marking this patch as
"Changes Requested" and am expecting it to be reposted at some point.

[PATCH] media: usbvision: remove unneeded DRIVER_LICENSE #define

[Greg Kroah-Hartman]

There is no need to #define the license of the driver, just put it in
the MODULE_LICENSE() line directly as a text string.

This allows tools that check that the module license matches the source
code license to work properly, as there is no need to unwind the
unneeded dereference.

Cc: Hans Verkuil 
Cc: Mauro Carvalho Chehab 
Cc: Johan Hovold 
Cc: Davidlohr Bueso 
Cc: Sakari Ailus 
Reported-by: Philippe Ombredanne 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/media/usb/usbvision/usbvision-video.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/usb/usbvision/usbvision-video.c 
b/drivers/media/usb/usbvision/usbvision-video.c
index 960272d3c924..0f5954a1fea2 100644
--- a/drivers/media/usb/usbvision/usbvision-video.c
+++ b/drivers/media/usb/usbvision/usbvision-video.c
@@ -72,7 +72,6 @@
 #define DRIVER_NAME "usbvision"
 #define DRIVER_ALIAS "USBVision"
 #define DRIVER_DESC "USBVision USB Video Device Driver for Linux"
-#define DRIVER_LICENSE "GPL"
 #define USBVISION_VERSION_STRING "0.9.11"
 
 #defineENABLE_HEXDUMP  0   /* Enable if you need it */
@@ -141,7 +140,7 @@ MODULE_PARM_DESC(radio_nr, "Set radio device number 
(/dev/radioX).  Default: -1
 /* Misc stuff */
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
-MODULE_LICENSE(DRIVER_LICENSE);
+MODULE_LICENSE("GPL");
 MODULE_VERSION(USBVISION_VERSION_STRING);
 MODULE_ALIAS(DRIVER_ALIAS);
 
-- 
2.15.0

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Hans Verkuil]

On 15/11/17 18:10, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Receive in-fence from userspace and add support for waiting on them
> before queueing the buffer to the driver. Buffers can't be queued to the
> driver before its fences signal. And a buffer can't be queue to the driver
> out of the order they were queued from userspace. That means that even if
> it fence signal it must wait all other buffers, ahead of it in the queue,
> to signal first.
> 
> To make that possible we use fence_array to keep that ordering. Basically
> we create a fence_array that contains both the current fence and the fence
> from the previous buffer (which might be a fence array as well). The base
> fence class for the fence_array becomes the new buffer fence, waiting on
> that one guarantees that it won't be queued out of order.
> 
> v6:
>   - With fences always keep the order userspace queues the buffers.
>   - Protect in_fence manipulation with a lock (Brian Starkey)
>   - check if fences have the same context before adding a fence array
>   - Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
>   - Clean up fence if __set_in_fence() fails (Brian Starkey)
>   - treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
> 
> v5:   - use fence_array to keep buffers ordered in vb2 core when
>   needed (Brian Starkey)
>   - keep backward compat on the reserved2 field (Brian Starkey)
>   - protect fence callback removal with lock (Brian Starkey)
> 
> v4:
>   - Add a comment about dma_fence_add_callback() not returning a
>   error (Hans)
>   - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
>   - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
>   - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
>   - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
>   -  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
>   vb2_start_streaming() (Hans)
>   - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
>   - Queue buffers to the driver as soon as they are ready (Hans)
>   - call fill_user_buffer() after queuing the buffer (Hans)
>   - add err: label to clean up fence
>   - add dma_fence_wait() before calling vb2_start_streaming()
> 
> v3:   - document fence parameter
>   - remove ternary if at vb2_qbuf() return (Mauro)
>   - do not change if conditions behaviour (Mauro)
> 
> v2:
>   - fix vb2_queue_or_prepare_buf() ret check
>   - remove check for VB2_MEMORY_DMABUF only (Javier)
>   - check num of ready buffers to start streaming
>   - when queueing, start from the first ready buffer
>   - handle queue cancel
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/media/v4l2-core/Kconfig  |   1 +
>  drivers/media/v4l2-core/videobuf2-core.c | 202 
> ---
>  drivers/media/v4l2-core/videobuf2-v4l2.c |  29 -
>  include/media/videobuf2-core.h   |  17 ++-
>  4 files changed, 231 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
> index a35c33686abf..3f988c407c80 100644
> --- a/drivers/media/v4l2-core/Kconfig
> +++ b/drivers/media/v4l2-core/Kconfig
> @@ -83,6 +83,7 @@ config VIDEOBUF_DVB
>  # Used by drivers that need Videobuf2 modules
>  config VIDEOBUF2_CORE
>   select DMA_SHARED_BUFFER
> + select SYNC_FILE
>   tristate
>  
>  config VIDEOBUF2_MEMOPS
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 60f8b582396a..26de4c80717d 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -346,6 +347,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
> vb2_memory memory,
>   vb->index = q->num_buffers + buffer;
>   vb->type = q->type;
>   vb->memory = memory;
> + spin_lock_init(>fence_cb_lock);
>   for (plane = 0; plane < num_planes; ++plane) {
>   vb->planes[plane].length = plane_sizes[plane];
>   vb->planes[plane].min_length = plane_sizes[plane];
> @@ -1222,6 +1224,9 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
>  {
>   struct vb2_queue *q = vb->vb2_queue;
>  
> + if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> + return;
> +
>   vb->state = VB2_BUF_STATE_ACTIVE;
>   atomic_inc(>owned_by_drv_count);
>  
> @@ -1273,6 +1278,23 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
> void *pb)
>   return 0;
>  }
>  
> +static int __get_num_ready_buffers(struct vb2_queue *q)
> +{
> + struct vb2_buffer *vb;
> + int ready_count = 0;
> + unsigned long flags;
> +
> + /* count num of buffers ready in front 

Re: [RFC v5 06/11] [media] vb2: add explicit fence user API

[Mauro Carvalho Chehab]

Em Fri, 17 Nov 2017 14:29:23 +0100
Hans Verkuil  escreveu:

> On 15/11/17 18:10, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Turn the reserved2 field into fence_fd that we will use to send
> > an in-fence to the kernel and return an out-fence from the kernel to
> > userspace.
> > 
> > Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
> > when sending a fence to the kernel to be waited on, and
> > V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
> > 
> > v4:
> > - make it a union with reserved2 and fence_fd (Hans Verkuil)
> > 
> > v3:
> > - make the out_fence refer to the current buffer (Hans Verkuil)
> > 
> > v2: add documentation
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  Documentation/media/uapi/v4l/buffer.rst   | 15 +++
> >  drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
> >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
> >  drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
> >  include/uapi/linux/videodev2.h|  7 ++-
> >  5 files changed, 25 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> > b/Documentation/media/uapi/v4l/buffer.rst
> > index ae6ee73f151c..eeefbd2547e7 100644
> > --- a/Documentation/media/uapi/v4l/buffer.rst
> > +++ b/Documentation/media/uapi/v4l/buffer.rst
> > @@ -648,6 +648,21 @@ Buffer Flags
> >- Start Of Exposure. The buffer timestamp has been taken when the
> > exposure of the frame has begun. This is only valid for the
> > ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
> > +* .. _`V4L2-BUF-FLAG-IN-FENCE`:
> > +
> > +  - ``V4L2_BUF_FLAG_IN_FENCE``
> > +  - 0x0020
> > +  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
> > +   won't be queued to the driver until the fence signals.
> > +
> > +* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
> > +
> > +  - ``V4L2_BUF_FLAG_OUT_FENCE``
> > +  - 0x0040
> > +  - Request a fence to be attached to the buffer. The ``fence_fd``
> > +   field on
> > +   :ref:`VIDIOC_QBUF` is used as a return argument to send the out-fence
> > +   fd to userspace.  
> 
> How would userspace know if fences are not supported? E.g. any driver that 
> does
> not use vb2 will have no support for it.
> 
> While the driver could clear the flag on return, the problem is that it is a 
> bit
> late for applications to discover lack of fence support.
> 
> Perhaps we do need a capability flag for this? I wonder what others think.

We're almost running out of flags at v4l2 caps (and at struct v4l2_buffer).

So, I would prefer to not add more flags on those structs if there is
another way.

As the fences out of order flags should go to ENUM_FMT (and, currently
there's just one flag defined there), I wander if it would make sense
to also add CAN_IN_FENCES/CAN_OUT_FENCES flags there, as maybe we
would want to disable/enable fences based on the format.

> 
> Regards,
> 
>   Hans
> 
> >  
> >  
> >  
> > diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
> > b/drivers/media/usb/cpia2/cpia2_v4l.c
> > index 3dedd83f0b19..6cde686bf44c 100644
> > --- a/drivers/media/usb/cpia2/cpia2_v4l.c
> > +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
> > @@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, 
> > struct v4l2_buffer *buf)
> > buf->sequence = cam->buffers[buf->index].seq;
> > buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
> > buf->length = cam->frame_size;
> > -   buf->reserved2 = 0;
> > +   buf->fence_fd = -1;
> > buf->reserved = 0;
> > memset(>timecode, 0, sizeof(buf->timecode));
> >  
> > diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> > b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > index 821f2aa299ae..3a31d318df2a 100644
> > --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > @@ -370,7 +370,7 @@ struct v4l2_buffer32 {
> > __s32   fd;
> > } m;
> > __u32   length;
> > -   __u32   reserved2;
> > +   __s32   fence_fd;
> > __u32   reserved;
> >  };
> >  
> > @@ -533,7 +533,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, 
> > struct v4l2_buffer32 __user
> > put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
> > copy_to_user(>timecode, >timecode, sizeof(struct 
> > v4l2_timecode)) ||
> > put_user(kp->sequence, >sequence) ||
> > -   put_user(kp->reserved2, >reserved2) ||
> > +   put_user(kp->fence_fd, >fence_fd) ||
> > put_user(kp->reserved, >reserved) ||
> > put_user(kp->length, >length))
> > return -EFAULT;
> > diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> > b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > index 

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Mauro Carvalho Chehab]

Em Fri, 17 Nov 2017 11:12:48 -0200
Gustavo Padovan  escreveu:

> > >   /*
> > >* If streamon has been called, and we haven't yet called
> > >* start_streaming() since not enough buffers were queued, and
> > >* we now have reached the minimum number of queued buffers,
> > >* then we can finally call start_streaming().
> > > -  *
> > > -  * If already streaming, give the buffer to driver for processing.
> > > -  * If not, the buffer will be given to driver on next streamon.
> > >*/
> > >   if (q->streaming && !q->start_streaming_called &&
> > > - q->queued_count >= q->min_buffers_needed) {
> > > + __get_num_ready_buffers(q) >= q->min_buffers_needed) {  
> > 
> > I guess the case where fences is not used is not covered here.
> > 
> > You probably should add a check at __get_num_ready_buffers(q)
> > as well, making it just return q->queued_count if fences isn't
> > used.  
> 
> We can't know that beforehand, some buffer ahead may have a fence,
> but there is already a check for !fence for each buffer. If none of
> them have fences the return will be equal to q->queued_count.

Hmm... are we willing to support the case where just some
buffers have fences? Why?

In any case, we should add a notice at the documentation telling
about what happens if not all buffers have fences, and if fences
are required to be setup before starting streaming, or if it is
possible to dynamically change the fances behavior while streaming.

-- 
Thanks,
Mauro

Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

[Rob Herring]

On Wed, Nov 15, 2017 at 4:58 PM, Niklas Söderlund
 wrote:
> Hi Rob,
>
> Thanks for your feedback, much appreciated!
>
> On 2017-11-15 14:02:26 -0600, Rob Herring wrote:
>> On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
>> > Document the devicetree bindings for the CSI-2 inputs available on Gen3.
>> >
>> > There is a need to add a custom property 'renesas,id' and to define
>> > which CSI-2 input is described in which endpoint under the port@1 node.
>> > This information is needed since there are a set of predefined routes
>> > between each VIN and CSI-2 block. This routing table will be kept
>> > inside the driver but in order for it to act on it it must know which
>> > VIN and CSI-2 is which.
>> >
>> > Signed-off-by: Niklas Söderlund 
>> > ---
>> >  .../devicetree/bindings/media/rcar_vin.txt | 116 
>> > ++---
>> >  1 file changed, 104 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
>> > b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > index 6e4ef8caf759e5d3..df1abd0fb20386f8 100644
>> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
>> >  ---
>> >
>> >  The rcar_vin device provides video input capabilities for the Renesas 
>> > R-Car
>> > -family of devices. The current blocks are always slaves and suppot one 
>> > input
>> > -channel which can be either RGB, YUYV or BT656.
>> > +family of devices.
>> > +
>> > +Each VIN instance has a single parallel input that supports RGB and YUV 
>> > video,
>> > +with both external synchronization and BT.656 synchronization for the 
>> > latter.
>> > +Depending on the instance the VIN input is connected to external SoC 
>> > pins, or
>> > +on Gen3 to a CSI-2 receiver.
>> >
>> >   - compatible: Must be one or more of the following
>> > - "renesas,vin-r8a7795" for the R8A7795 device
>> > @@ -28,21 +32,38 @@ channel which can be either RGB, YUYV or BT656.
>> >  Additionally, an alias named vinX will need to be created to specify
>> >  which video input device this is.
>> >
>> > -The per-board settings:
>> > +The per-board settings Gen2:
>> >   - port sub-node describing a single endpoint connected to the vin
>> > as described in video-interfaces.txt[1]. Only the first one will
>> > be considered as each vin interface has one input port.
>> >
>> > -   These settings are used to work out video input format and widths
>> > -   into the system.
>> > +The per-board settings Gen3:
>> > +
>> > +Gen3 can support both a single connected parallel input source from
>> > +external SoC pins (port0) and/or multiple parallel input sources from
>> > +local SoC CSI-2 receivers (port1) depending on SoC.
>> >
>> > +- renesas,id - ID number of the VIN, VINx in the documentation.
>>
>> Why is this needed? We try to avoid indexes unless that's the only way a
>> device is addressed (and then we use reg).
>
> This is unfortunately needed (or something similar) as there is a
> register in one VIN instance which controls the routing of the incoming
> CSI-2 video streams, not only to itself, but also to other VIN instances
> inside the same SoC.
>
> To be more specific I will try to clarify this using the R-Car H3 as an
> example. On the H3 there are 8 instances of the capture hardware (VIN0 -
> VIN7) and 3 instances off CSI-2 receivers (CSI20, CSI40 and CSI41) which
> receives CSI-2 streams, split the possible multiple virtual channels
> (VC) encoded in CSI-2 streams and forwards it to the VIN's.
>
> The problem is that VIN0 and VIN4 are different from the other VIN's,
> they have one register (CHSEL) which controls the limited number of
> possible routes of video streams between a CSI-2 + VC to a specific VIN.
> The CHSEL register in VIN0 controls the routing for VIN0-3 and the one
> in VIN4 controls VIN4-7 (the two subgroups are similar so lets only
> consider VIN0-3).
>
> There are only a handful of routes possible and the kicker is that
> changing the CHSEL value in VIN0, directly reflects all routes for
> VIN0-VIN3 per this table:
>
> CHSEL reg in VIN0:  0 1 2 3 4
> Video sent to VIN0: CSI40/VC0 CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI20/VC0
> Video sent to VIN1: CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI40/VC1 CSI20/VC1
> Video sent to VIN2: CSI20/VC1 CSI40/VC0 CSI20/VC0 CSI40/VC2 CSI20/VC2
> Video sent to VIN3: CSI40/VC1 CSI20/VC1 CSI20/VC1 CSI40/VC3 CSI20/VC3
>
> So if CHSEL in VIN0 is set to 2 the following routes are active: VIN0:
> CSI40/VC1, VIN1: CSI40/VC0, VIN2: CSI20/VC0, CSI20/VC1. These routing
> tables are different for most SoCs in the R-Car Gen3 family, and are
> kept inside the driver code.
>
> So the renesas,id properly is used so that the rcar-vin driver knows
> which of the driver 

Re: [RFCv1 PATCH 1/6] v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev

[Mauro Carvalho Chehab]

Em Mon, 13 Nov 2017 15:34:03 +0100
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Add a 'bool from_other_dev' argument: set to true if the two
> handlers refer to different devices (e.g. it is true when
> inheriting controls from a subdev into a main v4l2 bridge
> driver).
> 
> This will be used later when implementing support for the
> request API since we need to skip such controls.
> 
> TODO: check drivers/staging/media/imx/imx-media-fim.c change.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/dvb-frontends/rtl2832_sdr.c|  5 +--
>  drivers/media/pci/bt8xx/bttv-driver.c|  2 +-
>  drivers/media/pci/cx23885/cx23885-417.c  |  2 +-
>  drivers/media/pci/cx88/cx88-blackbird.c  |  2 +-
>  drivers/media/pci/cx88/cx88-video.c  |  2 +-
>  drivers/media/pci/saa7134/saa7134-empress.c  |  4 +--
>  drivers/media/pci/saa7134/saa7134-video.c|  2 +-
>  drivers/media/platform/exynos4-is/fimc-capture.c |  2 +-
>  drivers/media/platform/rcar-vin/rcar-v4l2.c  |  3 +-
>  drivers/media/platform/rcar_drif.c   |  2 +-
>  drivers/media/platform/soc_camera/soc_camera.c   |  3 +-
>  drivers/media/platform/vivid/vivid-ctrls.c   | 42 
> 
>  drivers/media/usb/cx231xx/cx231xx-417.c  |  2 +-
>  drivers/media/usb/cx231xx/cx231xx-video.c|  4 +--
>  drivers/media/usb/msi2500/msi2500.c  |  2 +-
>  drivers/media/usb/tm6000/tm6000-video.c  |  2 +-
>  drivers/media/v4l2-core/v4l2-ctrls.c | 11 ---
>  drivers/media/v4l2-core/v4l2-device.c|  3 +-
>  drivers/staging/media/imx/imx-media-dev.c|  2 +-
>  drivers/staging/media/imx/imx-media-fim.c|  2 +-
>  include/media/v4l2-ctrls.h   |  4 ++-

You forgot to update Documentation/media/kapi/v4l2-controls.rst.

>  21 files changed, 56 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/media/dvb-frontends/rtl2832_sdr.c 
> b/drivers/media/dvb-frontends/rtl2832_sdr.c
> index c6e78d870ccd..6064d28224e8 100644
> --- a/drivers/media/dvb-frontends/rtl2832_sdr.c
> +++ b/drivers/media/dvb-frontends/rtl2832_sdr.c
> @@ -1394,7 +1394,8 @@ static int rtl2832_sdr_probe(struct platform_device 
> *pdev)
>   case RTL2832_SDR_TUNER_E4000:
>   v4l2_ctrl_handler_init(>hdl, 9);
>   if (subdev)
> - v4l2_ctrl_add_handler(>hdl, subdev->ctrl_handler, 
> NULL);
> + v4l2_ctrl_add_handler(>hdl, subdev->ctrl_handler,
> +   NULL, true);

Changing all drivers to tell if a control belongs to a subdev or not
seems weird. I won't doubt that people may get it wrong and fill it
with a wrong value.

IMHO, it would be better, instead, to pass some struct to the function
that would allow the function to check if the device is a subdev
or not.

For example, we could do:

int v4l2_ctrl_subdev_add_handler(struct v4l2_ctrl_handler *hdl,
 struct v4l2_subdev *sd,
 v4l2_ctrl_filter filter);

That should be used for all subdev controls. Internally, such
function would be using:
sd->control_handler
as the add parameter for v4l2_ctrl_add_handler().

I would also try to do the same for devices: have a
v4l2_ctrl_dev_add_handler() that would take a struct v4l2_dev, and
make v4l2_ctrl_add_handler() a static function inside v4l2-ctrls.c.

This way, we should avoid the risk of wrong usages.

Thanks,
Mauro

Re: [PATCH v2 6/8] v4l: vsp1: Adapt entities to configure into a body

[Kieran Bingham]

Hi Laurent,

On 12/09/17 20:18, Laurent Pinchart wrote:
> Hi Kieran,
> 
> On Tuesday, 12 September 2017 00:42:09 EEST Kieran Bingham wrote:
>> On 17/08/17 18:58, Laurent Pinchart wrote:
>>> On Monday 14 Aug 2017 16:13:29 Kieran Bingham wrote:
 Currently the entities store their configurations into a display list.
 Adapt this such that the code can be configured into a body fragment
 directly, allowing greater flexibility and control of the content.

 All users of vsp1_dl_list_write() are removed in this process, thus it
 too is removed.

 A helper, vsp1_dl_list_body() is provided to access the internal body0
 from the display list.

 Signed-off-by: Kieran Bingham 
 ---

  drivers/media/platform/vsp1/vsp1_bru.c| 22 ++--
  drivers/media/platform/vsp1/vsp1_clu.c| 22 ++--
  drivers/media/platform/vsp1/vsp1_dl.c | 12 ++-
  drivers/media/platform/vsp1/vsp1_dl.h |  2 +-
  drivers/media/platform/vsp1/vsp1_drm.c| 14 +---
  drivers/media/platform/vsp1/vsp1_entity.c | 16 -
  drivers/media/platform/vsp1/vsp1_entity.h | 12 ---
  drivers/media/platform/vsp1/vsp1_hgo.c| 16 -
  drivers/media/platform/vsp1/vsp1_hgt.c| 18 +-
  drivers/media/platform/vsp1/vsp1_hsit.c   | 10 +++---
  drivers/media/platform/vsp1/vsp1_lif.c| 13 +++
  drivers/media/platform/vsp1/vsp1_lut.c| 21 ++--
  drivers/media/platform/vsp1/vsp1_pipe.c   |  4 +-
  drivers/media/platform/vsp1/vsp1_pipe.h   |  3 +-
  drivers/media/platform/vsp1/vsp1_rpf.c| 43 +++-
  drivers/media/platform/vsp1/vsp1_sru.c| 14 
  drivers/media/platform/vsp1/vsp1_uds.c| 24 +++--
  drivers/media/platform/vsp1/vsp1_uds.h|  2 +-
  drivers/media/platform/vsp1/vsp1_video.c  | 11 --
  drivers/media/platform/vsp1/vsp1_wpf.c| 42 ---
  20 files changed, 168 insertions(+), 153 deletions(-)
>>>
>>> This is quite intrusive, and it bothers me slightly that we need to pass
>>> both the DL and the DLB to the configure function in order to add
>>> fragments to the DL in the CLU and LUT modules. Wouldn't it be simpler to
>>> add a pointer to the current body in the DL structure, and modify
>>> vsp1_dl_list_write() to write to the current fragment ?
>>
>> No doubt about it, 168+, 153- is certainly intrusive.
>>
>> Yes, now I'm looking back at this, I think this does look like this part is
>> not quite the right approach.
>>
>> Which otherwise stalls the series until I have time to reconsider. I will
>> likely repost the work I have done on the earlier patches, including the
>> 's/fragment/body/g' changes and ready myself for a v4 which will contain the
>> heavier reworks.
> 
> Fine with me. Could you make sure to mention the open issues in the cover 
> letter ? I want to avoid commenting on them if you know already that you will 
> rework them later.

I've been trying to tackle this today, but I think I've come up a bit stuck on a
key part.

The reason for this patch, is to allow the functions to configure directly into
a display list body, even when that body *is not part* of a display list.

So - converting vsp1_dl_list_write() to configure into the 'current' body (was
fragment) of a display list would not work for writing to the cached objects -
which do not have a display list. They are simply body objects.

It seems a bit extraneous to create holding display lists to contain a single
body, when the display list itself will never be used, but I can't think of an
alternative.

Would you prefer this 'container display list' approach? or do you have another
idea?

--
Regards

Kieran

Re: [RFC v5 10/11] [media] vb2: add out-fence support to QBUF

[Hans Verkuil]

On 15/11/17 18:10, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
> an out_fence and send its fd to userspace on the fence_fd field as a
> return arg for the QBUF call.
> 
> The fence is signaled on buffer_done(), when the job on the buffer is
> finished.
> 
> With out-fences we do not allow drivers to requeue buffers through vb2,
> instead we flag an error on the buffer, signals it fence with error and
> return it to userspace.
> 
> v6
>   - get rid of the V4L2_EVENT_OUT_FENCE event. We always keep the
>   ordering in vb2 for queueing in the driver, so the event is not
>   necessary anymore and the out_fence_fd is sent back to userspace
>   on QBUF call return arg
>   - do not allow requeueing with out-fences, instead mark the buffer
>   with an error and wake up to userspace.
>   - send the out_fence_fd back to userspace on the fence_fd field
> 
> v5:
>   - delay fd_install to DQ_EVENT (Hans)
>   - if queue is fully ordered send OUT_FENCE event right away
>   (Brian)
>   - rename 'q->ordered' to 'q->ordered_in_driver'
>   - merge change to implement OUT_FENCE event here
> 
> v4:
>   - return the out_fence_fd in the BUF_QUEUED event(Hans)
> 
> v3:   - add WARN_ON_ONCE(q->ordered) on requeueing (Hans)
>   - set the OUT_FENCE flag if there is a fence pending (Hans)
>   - call fd_install() after vb2_core_qbuf() (Hans)
>   - clean up fence if vb2_core_qbuf() fails (Hans)
>   - add list to store sync_file and fence for the next queued buffer
> 
> v2: check if the queue is ordered.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 42 
> +---
>  drivers/media/v4l2-core/videobuf2-v4l2.c | 21 +++-
>  2 files changed, 58 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 8b4f0e9bcb36..2eb5ffa8e028 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -354,6 +354,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
> vb2_memory memory,
>   vb->planes[plane].length = plane_sizes[plane];
>   vb->planes[plane].min_length = plane_sizes[plane];
>   }
> + vb->out_fence_fd = -1;
>   q->bufs[vb->index] = vb;
>  
>   /* Allocate video buffer memory for the MMAP type */
> @@ -934,10 +935,26 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
> vb2_buffer_state state)
>   case VB2_BUF_STATE_QUEUED:
>   return;
>   case VB2_BUF_STATE_REQUEUEING:
> - if (q->start_streaming_called)
> - __enqueue_in_driver(vb);
> - return;
> +
> + if (!vb->out_fence) {
> + if (q->start_streaming_called)
> + __enqueue_in_driver(vb);
> + return;
> + }
> +
> + /* Do not allow requeuing with explicit synchronization,
> +  * report it as an error to userspace */
> + state = VB2_BUF_STATE_ERROR;

No, don't do this. Drivers that use requeueing simply cannot use fences.
I.e., it should be a WARN_ON_ONCE(), then continue with the original
code. The only mainline driver that requeues is the cobalt PCI driver
and it is OK to disable fences there. I maintain that one and I can take
a look later whether I can replace the requeuing with something better.

Regards,

Hans

> +
> + /* fall through */
>   default:
> + if (state == VB2_BUF_STATE_ERROR)
> + dma_fence_set_error(vb->out_fence, -EFAULT);
> + dma_fence_signal(vb->out_fence);
> + dma_fence_put(vb->out_fence);
> + vb->out_fence = NULL;
> + vb->out_fence_fd = -1;
> +
>   /* Inform any processes that may be waiting for buffers */
>   wake_up(>done_wq);
>   break;
> @@ -1325,12 +1342,18 @@ EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
>  int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index)
>  {
>   struct vb2_buffer *vb;
> + u64 context;
>  
>   vb = q->bufs[index];
>  
>   vb->out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
>  
> - vb->out_fence = vb2_fence_alloc(q->out_fence_context);
> + if (q->ordered_in_driver)
> + context = q->out_fence_context;
> + else
> + context = dma_fence_context_alloc(1);
> +
> + vb->out_fence = vb2_fence_alloc(context);
>   if (!vb->out_fence) {
>   put_unused_fd(vb->out_fence_fd);
>   return -ENOMEM;
> @@ -1594,6 +1617,9 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
> index, void *pb,
>   if (pb)
>   

Re: [RFC v5 06/11] [media] vb2: add explicit fence user API

[Hans Verkuil]

On 15/11/17 18:10, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Turn the reserved2 field into fence_fd that we will use to send
> an in-fence to the kernel and return an out-fence from the kernel to
> userspace.
> 
> Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
> when sending a fence to the kernel to be waited on, and
> V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
> 
> v4:
>   - make it a union with reserved2 and fence_fd (Hans Verkuil)
> 
> v3:
>   - make the out_fence refer to the current buffer (Hans Verkuil)
> 
> v2: add documentation
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  Documentation/media/uapi/v4l/buffer.rst   | 15 +++
>  drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
>  include/uapi/linux/videodev2.h|  7 ++-
>  5 files changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> b/Documentation/media/uapi/v4l/buffer.rst
> index ae6ee73f151c..eeefbd2547e7 100644
> --- a/Documentation/media/uapi/v4l/buffer.rst
> +++ b/Documentation/media/uapi/v4l/buffer.rst
> @@ -648,6 +648,21 @@ Buffer Flags
>- Start Of Exposure. The buffer timestamp has been taken when the
>   exposure of the frame has begun. This is only valid for the
>   ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
> +* .. _`V4L2-BUF-FLAG-IN-FENCE`:
> +
> +  - ``V4L2_BUF_FLAG_IN_FENCE``
> +  - 0x0020
> +  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
> + won't be queued to the driver until the fence signals.
> +
> +* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
> +
> +  - ``V4L2_BUF_FLAG_OUT_FENCE``
> +  - 0x0040
> +  - Request a fence to be attached to the buffer. The ``fence_fd``
> + field on
> + :ref:`VIDIOC_QBUF` is used as a return argument to send the out-fence
> + fd to userspace.

How would userspace know if fences are not supported? E.g. any driver that does
not use vb2 will have no support for it.

While the driver could clear the flag on return, the problem is that it is a bit
late for applications to discover lack of fence support.

Perhaps we do need a capability flag for this? I wonder what others think.

Regards,

Hans

>  
>  
>  
> diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
> b/drivers/media/usb/cpia2/cpia2_v4l.c
> index 3dedd83f0b19..6cde686bf44c 100644
> --- a/drivers/media/usb/cpia2/cpia2_v4l.c
> +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
> @@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, 
> struct v4l2_buffer *buf)
>   buf->sequence = cam->buffers[buf->index].seq;
>   buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
>   buf->length = cam->frame_size;
> - buf->reserved2 = 0;
> + buf->fence_fd = -1;
>   buf->reserved = 0;
>   memset(>timecode, 0, sizeof(buf->timecode));
>  
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index 821f2aa299ae..3a31d318df2a 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -370,7 +370,7 @@ struct v4l2_buffer32 {
>   __s32   fd;
>   } m;
>   __u32   length;
> - __u32   reserved2;
> + __s32   fence_fd;
>   __u32   reserved;
>  };
>  
> @@ -533,7 +533,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, 
> struct v4l2_buffer32 __user
>   put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
>   copy_to_user(>timecode, >timecode, sizeof(struct 
> v4l2_timecode)) ||
>   put_user(kp->sequence, >sequence) ||
> - put_user(kp->reserved2, >reserved2) ||
> + put_user(kp->fence_fd, >fence_fd) ||
>   put_user(kp->reserved, >reserved) ||
>   put_user(kp->length, >length))
>   return -EFAULT;
> diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> b/drivers/media/v4l2-core/videobuf2-v4l2.c
> index 0c0669976bdc..110fb45fef6f 100644
> --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> @@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
> void *pb)
>   b->timestamp = ns_to_timeval(vb->timestamp);
>   b->timecode = vbuf->timecode;
>   b->sequence = vbuf->sequence;
> - b->reserved2 = 0;
> + b->fence_fd = -1;
>   b->reserved = 0;
>  
>   if (q->is_multiplanar) {
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index cd6fc1387f47..311c3a331eda 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -925,7 +925,10 @@ 

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Mauro Carvalho Chehab]

Em Fri, 17 Nov 2017 11:08:01 -0200
Gustavo Padovan  escreveu:

> 2017-11-17 Mauro Carvalho Chehab :
> 
> > Em Fri, 17 Nov 2017 15:49:23 +0900
> > Alexandre Courbot  escreveu:
> >   
> > > > @@ -178,6 +179,12 @@ static int vb2_queue_or_prepare_buf(struct 
> > > > vb2_queue *q, struct v4l2_buffer *b,
> > > > return -EINVAL;
> > > > }
> > > >  
> > > > +   if ((b->fence_fd != 0 && b->fence_fd != -1) &&
> > > 
> > > Why do we need to consider both values invalid? Can 0 ever be a valid 
> > > fence 
> > > fd?  
> > 
> > Programs that don't use fences will initialize reserved2/fence_fd field
> > at the uAPI call to zero.
> > 
> > So, I guess using fd=0 here could be a problem. Anyway, I would, instead,
> > do:
> > 
> > if ((b->fence_fd < 1) &&
> > ...
> > 
> > as other negative values are likely invalid as well.  
> 
> We are checking when the fence_fd is set but the flag wasn't. Checking
> for < 1 is exactly the opposite. so we keep as is or do it fence_fd > 0.

Ah, yes. Anyway, I would stick with:
if ((b->fence_fd > 0) &&
...

> 
> Gustavo


-- 
Thanks,
Mauro

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Gustavo Padovan]

2017-11-17 Mauro Carvalho Chehab :

> Em Wed, 15 Nov 2017 15:10:53 -0200
> Gustavo Padovan  escreveu:
> 
> > From: Gustavo Padovan 
> > 
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers can't be queued to the
> > driver before its fences signal. And a buffer can't be queue to the driver
> > out of the order they were queued from userspace. That means that even if
> > it fence signal it must wait all other buffers, ahead of it in the queue,
> > to signal first.
> > 
> > To make that possible we use fence_array to keep that ordering. Basically
> > we create a fence_array that contains both the current fence and the fence
> > from the previous buffer (which might be a fence array as well). The base
> > fence class for the fence_array becomes the new buffer fence, waiting on
> > that one guarantees that it won't be queued out of order.
> > 
> > v6:
> > - With fences always keep the order userspace queues the buffers.
> > - Protect in_fence manipulation with a lock (Brian Starkey)
> > - check if fences have the same context before adding a fence array
> > - Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
> > - Clean up fence if __set_in_fence() fails (Brian Starkey)
> > - treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
> > 
> > v5: - use fence_array to keep buffers ordered in vb2 core when
> > needed (Brian Starkey)
> > - keep backward compat on the reserved2 field (Brian Starkey)
> > - protect fence callback removal with lock (Brian Starkey)
> > 
> > v4:
> > - Add a comment about dma_fence_add_callback() not returning a
> > error (Hans)
> > - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
> > - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
> > - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
> > - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
> > -  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
> > vb2_start_streaming() (Hans)
> > - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
> > - Queue buffers to the driver as soon as they are ready (Hans)
> > - call fill_user_buffer() after queuing the buffer (Hans)
> > - add err: label to clean up fence
> > - add dma_fence_wait() before calling vb2_start_streaming()
> > 
> > v3: - document fence parameter
> > - remove ternary if at vb2_qbuf() return (Mauro)
> > - do not change if conditions behaviour (Mauro)
> > 
> > v2:
> > - fix vb2_queue_or_prepare_buf() ret check
> > - remove check for VB2_MEMORY_DMABUF only (Javier)
> > - check num of ready buffers to start streaming
> > - when queueing, start from the first ready buffer
> > - handle queue cancel
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/media/v4l2-core/Kconfig  |   1 +
> >  drivers/media/v4l2-core/videobuf2-core.c | 202 
> > ---
> >  drivers/media/v4l2-core/videobuf2-v4l2.c |  29 -
> >  include/media/videobuf2-core.h   |  17 ++-
> >  4 files changed, 231 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/Kconfig 
> > b/drivers/media/v4l2-core/Kconfig
> > index a35c33686abf..3f988c407c80 100644
> > --- a/drivers/media/v4l2-core/Kconfig
> > +++ b/drivers/media/v4l2-core/Kconfig
> > @@ -83,6 +83,7 @@ config VIDEOBUF_DVB
> >  # Used by drivers that need Videobuf2 modules
> >  config VIDEOBUF2_CORE
> > select DMA_SHARED_BUFFER
> > +   select SYNC_FILE
> > tristate
> >  
> >  config VIDEOBUF2_MEMOPS
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 60f8b582396a..26de4c80717d 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -23,6 +23,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -346,6 +347,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
> > vb2_memory memory,
> > vb->index = q->num_buffers + buffer;
> > vb->type = q->type;
> > vb->memory = memory;
> > +   spin_lock_init(>fence_cb_lock);
> > for (plane = 0; plane < num_planes; ++plane) {
> > vb->planes[plane].length = plane_sizes[plane];
> > vb->planes[plane].min_length = plane_sizes[plane];
> > @@ -1222,6 +1224,9 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
> >  {
> > struct vb2_queue *q = vb->vb2_queue;
> >  
> > +   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> > +   return;
> > +
> > vb->state = VB2_BUF_STATE_ACTIVE;
> > atomic_inc(>owned_by_drv_count);
> >  
> > @@ -1273,6 +1278,23 @@ static int __buf_prepare(struct vb2_buffer *vb, 
> > const 

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Gustavo Padovan]

2017-11-17 Mauro Carvalho Chehab :

> Em Fri, 17 Nov 2017 15:49:23 +0900
> Alexandre Courbot  escreveu:
> 
> > > @@ -178,6 +179,12 @@ static int vb2_queue_or_prepare_buf(struct 
> > > vb2_queue *q, struct v4l2_buffer *b,
> > >   return -EINVAL;
> > >   }
> > >  
> > > + if ((b->fence_fd != 0 && b->fence_fd != -1) &&  
> > 
> > Why do we need to consider both values invalid? Can 0 ever be a valid fence 
> > fd?
> 
> Programs that don't use fences will initialize reserved2/fence_fd field
> at the uAPI call to zero.
> 
> So, I guess using fd=0 here could be a problem. Anyway, I would, instead,
> do:
> 
>   if ((b->fence_fd < 1) &&
>   ...
> 
> as other negative values are likely invalid as well.

We are checking when the fence_fd is set but the flag wasn't. Checking
for < 1 is exactly the opposite. so we keep as is or do it fence_fd > 0.

Gustavo

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Gustavo Padovan]

2017-11-17 Alexandre Courbot :

> Hi Gustavo,
> 
> I am coming a bit late in this series' review, so apologies if some of my
> comments have already have been discussed in an earlier revision.
> 
> On Thursday, November 16, 2017 2:10:53 AM JST, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers can't be queued to the
> > driver before its fences signal. And a buffer can't be queue to the driver
> > out of the order they were queued from userspace. That means that even if
> > it fence signal it must wait all other buffers, ahead of it in the queue,
> > to signal first.
> > 
> > To make that possible we use fence_array to keep that ordering. Basically
> > we create a fence_array that contains both the current fence and the fence
> > from the previous buffer (which might be a fence array as well). The base
> > fence class for the fence_array becomes the new buffer fence, waiting on
> > that one guarantees that it won't be queued out of order.
> > 
> > v6:
> > - With fences always keep the order userspace queues the buffers.
> > - Protect in_fence manipulation with a lock (Brian Starkey)
> > - check if fences have the same context before adding a fence array
> > - Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
> > - Clean up fence if __set_in_fence() fails (Brian Starkey)
> > - treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
> > 
> > v5: - use fence_array to keep buffers ordered in vb2 core when
> > needed (Brian Starkey)
> > - keep backward compat on the reserved2 field (Brian Starkey)
> > - protect fence callback removal with lock (Brian Starkey)
> > 
> > v4:
> > - Add a comment about dma_fence_add_callback() not returning a
> > error (Hans)
> > - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
> > - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
> > - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
> > - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
> > -  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
> > vb2_start_streaming() (Hans)
> > - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
> > - Queue buffers to the driver as soon as they are ready (Hans)
> > - call fill_user_buffer() after queuing the buffer (Hans)
> > - add err: label to clean up fence
> > - add dma_fence_wait() before calling vb2_start_streaming()
> > 
> > v3: - document fence parameter
> > - remove ternary if at vb2_qbuf() return (Mauro)
> > - do not change if conditions behaviour (Mauro)
> > 
> > v2:
> > - fix vb2_queue_or_prepare_buf() ret check
> > - remove check for VB2_MEMORY_DMABUF only (Javier)
> > - check num of ready buffers to start streaming
> > - when queueing, start from the first ready buffer
> > - handle queue cancel
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/media/v4l2-core/Kconfig  |   1 +
> >  drivers/media/v4l2-core/videobuf2-core.c | 202
> > ---
> >  drivers/media/v4l2-core/videobuf2-v4l2.c |  29 -
> >  include/media/videobuf2-core.h   |  17 ++-
> >  4 files changed, 231 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/Kconfig
> > b/drivers/media/v4l2-core/Kconfig
> > index a35c33686abf..3f988c407c80 100644
> > --- a/drivers/media/v4l2-core/Kconfig
> > +++ b/drivers/media/v4l2-core/Kconfig
> > @@ -83,6 +83,7 @@ config VIDEOBUF_DVB
> >  # Used by drivers that need Videobuf2 modules
> >  config VIDEOBUF2_CORE
> > select DMA_SHARED_BUFFER
> > +   select SYNC_FILE
> > tristate
> >  config VIDEOBUF2_MEMOPS
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 60f8b582396a..26de4c80717d 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -23,6 +23,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> > @@ -346,6 +347,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q,
> > enum vb2_memory memory,
> > vb->index = q->num_buffers + buffer;
> > vb->type = q->type;
> > vb->memory = memory;
> > +   spin_lock_init(>fence_cb_lock);
> > for (plane = 0; plane < num_planes; ++plane) {
> > vb->planes[plane].length = plane_sizes[plane];
> > vb->planes[plane].min_length = plane_sizes[plane];
> > @@ -1222,6 +1224,9 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
> >  {
> > struct vb2_queue *q = vb->vb2_queue;
> > +   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> > +   return;
> > +
> > vb->state = VB2_BUF_STATE_ACTIVE;
> > 

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Mauro Carvalho Chehab]

Em Fri, 17 Nov 2017 15:49:23 +0900
Alexandre Courbot  escreveu:

> > @@ -178,6 +179,12 @@ static int vb2_queue_or_prepare_buf(struct 
> > vb2_queue *q, struct v4l2_buffer *b,
> > return -EINVAL;
> > }
> >  
> > +   if ((b->fence_fd != 0 && b->fence_fd != -1) &&  
> 
> Why do we need to consider both values invalid? Can 0 ever be a valid fence 
> fd?

Programs that don't use fences will initialize reserved2/fence_fd field
at the uAPI call to zero.

So, I guess using fd=0 here could be a problem. Anyway, I would, instead,
do:

if ((b->fence_fd < 1) &&
...

as other negative values are likely invalid as well.

-- 
Thanks,
Mauro

Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF

[Mauro Carvalho Chehab]

Em Wed, 15 Nov 2017 15:10:53 -0200
Gustavo Padovan  escreveu:

> From: Gustavo Padovan 
> 
> Receive in-fence from userspace and add support for waiting on them
> before queueing the buffer to the driver. Buffers can't be queued to the
> driver before its fences signal. And a buffer can't be queue to the driver
> out of the order they were queued from userspace. That means that even if
> it fence signal it must wait all other buffers, ahead of it in the queue,
> to signal first.
> 
> To make that possible we use fence_array to keep that ordering. Basically
> we create a fence_array that contains both the current fence and the fence
> from the previous buffer (which might be a fence array as well). The base
> fence class for the fence_array becomes the new buffer fence, waiting on
> that one guarantees that it won't be queued out of order.
> 
> v6:
>   - With fences always keep the order userspace queues the buffers.
>   - Protect in_fence manipulation with a lock (Brian Starkey)
>   - check if fences have the same context before adding a fence array
>   - Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
>   - Clean up fence if __set_in_fence() fails (Brian Starkey)
>   - treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
> 
> v5:   - use fence_array to keep buffers ordered in vb2 core when
>   needed (Brian Starkey)
>   - keep backward compat on the reserved2 field (Brian Starkey)
>   - protect fence callback removal with lock (Brian Starkey)
> 
> v4:
>   - Add a comment about dma_fence_add_callback() not returning a
>   error (Hans)
>   - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
>   - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
>   - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
>   - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
>   -  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
>   vb2_start_streaming() (Hans)
>   - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
>   - Queue buffers to the driver as soon as they are ready (Hans)
>   - call fill_user_buffer() after queuing the buffer (Hans)
>   - add err: label to clean up fence
>   - add dma_fence_wait() before calling vb2_start_streaming()
> 
> v3:   - document fence parameter
>   - remove ternary if at vb2_qbuf() return (Mauro)
>   - do not change if conditions behaviour (Mauro)
> 
> v2:
>   - fix vb2_queue_or_prepare_buf() ret check
>   - remove check for VB2_MEMORY_DMABUF only (Javier)
>   - check num of ready buffers to start streaming
>   - when queueing, start from the first ready buffer
>   - handle queue cancel
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/media/v4l2-core/Kconfig  |   1 +
>  drivers/media/v4l2-core/videobuf2-core.c | 202 
> ---
>  drivers/media/v4l2-core/videobuf2-v4l2.c |  29 -
>  include/media/videobuf2-core.h   |  17 ++-
>  4 files changed, 231 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
> index a35c33686abf..3f988c407c80 100644
> --- a/drivers/media/v4l2-core/Kconfig
> +++ b/drivers/media/v4l2-core/Kconfig
> @@ -83,6 +83,7 @@ config VIDEOBUF_DVB
>  # Used by drivers that need Videobuf2 modules
>  config VIDEOBUF2_CORE
>   select DMA_SHARED_BUFFER
> + select SYNC_FILE
>   tristate
>  
>  config VIDEOBUF2_MEMOPS
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 60f8b582396a..26de4c80717d 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -346,6 +347,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
> vb2_memory memory,
>   vb->index = q->num_buffers + buffer;
>   vb->type = q->type;
>   vb->memory = memory;
> + spin_lock_init(>fence_cb_lock);
>   for (plane = 0; plane < num_planes; ++plane) {
>   vb->planes[plane].length = plane_sizes[plane];
>   vb->planes[plane].min_length = plane_sizes[plane];
> @@ -1222,6 +1224,9 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
>  {
>   struct vb2_queue *q = vb->vb2_queue;
>  
> + if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> + return;
> +
>   vb->state = VB2_BUF_STATE_ACTIVE;
>   atomic_inc(>owned_by_drv_count);
>  
> @@ -1273,6 +1278,23 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
> void *pb)
>   return 0;
>  }
>  
> +static int __get_num_ready_buffers(struct vb2_queue *q)
> +{
> + struct vb2_buffer *vb;
> + int ready_count = 0;
> + unsigned long flags;
> +
> +   

Re: [RFC v5 03/11] [media] vb2: add 'ordered_in_driver' property to queues

[Gustavo Padovan]

Hi Mauro,

2017-11-17 Mauro Carvalho Chehab :

> Em Wed, 15 Nov 2017 15:10:49 -0200
> Gustavo Padovan  escreveu:
> 
> > From: Gustavo Padovan 
> > 
> > We use ordered_in_driver property to optimize for the case where
> > the driver can deliver the buffers in an ordered fashion. When it
> > is ordered we can use the same fence context for all fences, but
> > when it is not we need to a new context for each out-fence.
> > 
> > So the ordered_in_driver flag will help us with identifying the queues
> > that can be optimized and use the same fence context.
> > 
> > v4: make the property a vector for optimization and not a mandatory thing
> > that drivers need to set if they want to use explicit synchronization.
> > 
> > v3: improve doc (Hans Verkuil)
> > 
> > v2: rename property to 'ordered_in_driver' to avoid confusion
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  include/media/videobuf2-core.h | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> > index ef9b64398c8c..38b9c8dd42c6 100644
> > --- a/include/media/videobuf2-core.h
> > +++ b/include/media/videobuf2-core.h
> > @@ -440,6 +440,12 @@ struct vb2_buf_ops {
> >   * @fileio_read_once:  report EOF after reading the first 
> > buffer
> >   * @fileio_write_immediately:  queue buffer after each write() call
> >   * @allow_zero_bytesused:  allow bytesused == 0 to be passed to the driver
> > + * @ordered_in_driver: if the driver can guarantee that the queue will be
> > + * ordered or not, i.e., the buffers are dequeued from the driver
> > + * in the same order they are queued to the driver. The default
> > + * is not ordered unless the driver sets this flag. Setting it
> > + * when ordering can be guaranted helps to optimize explicit
> > + * fences.
> >   * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when 
> > QBUF
> >   *  has not been called. This is a vb1 idiom that has been 
> > adopted
> >   *  also by vb2.
> > @@ -510,6 +516,7 @@ struct vb2_queue {
> > unsignedfileio_read_once:1;
> > unsignedfileio_write_immediately:1;
> > unsignedallow_zero_bytesused:1;
> > +   unsignedordered_in_driver:1;
> 
> As this may depend on the format, it is probably a good idea to set
> this flag either via a function argument or by a function that
> would be meant to update it, as video format changes.

Right, and maybe I can find a way to store this in only one place,
istead of what I did here (having to set explicitely both the 
ordered_in_driver and the flag separatedly)

Gustavo

Re: [RFC v5 06/11] [media] vb2: add explicit fence user API

[Mauro Carvalho Chehab]

Em Wed, 15 Nov 2017 15:10:52 -0200
Gustavo Padovan  escreveu:

> From: Gustavo Padovan 
> 
> Turn the reserved2 field into fence_fd that we will use to send
> an in-fence to the kernel and return an out-fence from the kernel to
> userspace.
> 
> Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
> when sending a fence to the kernel to be waited on, and
> V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
> 
> v4:
>   - make it a union with reserved2 and fence_fd (Hans Verkuil)
> 
> v3:
>   - make the out_fence refer to the current buffer (Hans Verkuil)
> 
> v2: add documentation
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  Documentation/media/uapi/v4l/buffer.rst   | 15 +++
>  drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
>  include/uapi/linux/videodev2.h|  7 ++-
>  5 files changed, 25 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> b/Documentation/media/uapi/v4l/buffer.rst
> index ae6ee73f151c..eeefbd2547e7 100644
> --- a/Documentation/media/uapi/v4l/buffer.rst
> +++ b/Documentation/media/uapi/v4l/buffer.rst
> @@ -648,6 +648,21 @@ Buffer Flags
>- Start Of Exposure. The buffer timestamp has been taken when the
>   exposure of the frame has begun. This is only valid for the
>   ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
> +* .. _`V4L2-BUF-FLAG-IN-FENCE`:
> +
> +  - ``V4L2_BUF_FLAG_IN_FENCE``
> +  - 0x0020
> +  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
> + won't be queued to the driver until the fence signals.
> +
> +* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
> +
> +  - ``V4L2_BUF_FLAG_OUT_FENCE``
> +  - 0x0040
> +  - Request a fence to be attached to the buffer. The ``fence_fd``
> + field on
> + :ref:`VIDIOC_QBUF` is used as a return argument to send the out-fence
> + fd to userspace.
>  
>  
>  
> diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
> b/drivers/media/usb/cpia2/cpia2_v4l.c
> index 3dedd83f0b19..6cde686bf44c 100644
> --- a/drivers/media/usb/cpia2/cpia2_v4l.c
> +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
> @@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, 
> struct v4l2_buffer *buf)
>   buf->sequence = cam->buffers[buf->index].seq;
>   buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
>   buf->length = cam->frame_size;
> - buf->reserved2 = 0;
> + buf->fence_fd = -1;
>   buf->reserved = 0;
>   memset(>timecode, 0, sizeof(buf->timecode));
>  
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index 821f2aa299ae..3a31d318df2a 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -370,7 +370,7 @@ struct v4l2_buffer32 {
>   __s32   fd;
>   } m;
>   __u32   length;
> - __u32   reserved2;
> + __s32   fence_fd;
>   __u32   reserved;
>  };
>  
> @@ -533,7 +533,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, 
> struct v4l2_buffer32 __user
>   put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
>   copy_to_user(>timecode, >timecode, sizeof(struct 
> v4l2_timecode)) ||
>   put_user(kp->sequence, >sequence) ||
> - put_user(kp->reserved2, >reserved2) ||
> + put_user(kp->fence_fd, >fence_fd) ||
>   put_user(kp->reserved, >reserved) ||
>   put_user(kp->length, >length))
>   return -EFAULT;
> diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> b/drivers/media/v4l2-core/videobuf2-v4l2.c
> index 0c0669976bdc..110fb45fef6f 100644
> --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> @@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
> void *pb)
>   b->timestamp = ns_to_timeval(vb->timestamp);
>   b->timecode = vbuf->timecode;
>   b->sequence = vbuf->sequence;
> - b->reserved2 = 0;
> + b->fence_fd = -1;
>   b->reserved = 0;
>  
>   if (q->is_multiplanar) {
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index cd6fc1387f47..311c3a331eda 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -925,7 +925,10 @@ struct v4l2_buffer {
>   __s32   fd;
>   } m;
>   __u32   length;
> - __u32   reserved2;
> + union {
> + __s32   fence_fd;

You forgot to document the fence_fd at the uAPI book. In particular,
it should be noticed there that a 

Re: [RFC v5 01/11] [media] v4l: add V4L2_CAP_ORDERED to the uapi

[Gustavo Padovan]

2017-11-17 Mauro Carvalho Chehab :

> Em Wed, 15 Nov 2017 15:10:47 -0200
> Gustavo Padovan  escreveu:
> 
> > From: Gustavo Padovan 
> > 
> > When using explicit synchronization userspace needs to know if
> > the queue can deliver everything back in the same order, so we added
> > a new capability that drivers can use to report that they are capable
> > of keeping ordering.
> > 
> > In videobuf2 core when using fences we also make sure to keep the ordering
> > of buffers, so if the driver guarantees it too the whole pipeline inside
> > V4L2 will be ordered and the V4L2_CAP_ORDERED should be used.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 +++
> >  include/uapi/linux/videodev2.h   | 1 +
> >  2 files changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
> > b/Documentation/media/uapi/v4l/vidioc-querycap.rst
> > index 66fb1b3d6e6e..ed3daa814da9 100644
> > --- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
> > +++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
> > @@ -254,6 +254,9 @@ specification the ioctl returns an ``EINVAL`` error 
> > code.
> >  * - ``V4L2_CAP_TOUCH``
> >- 0x1000
> >- This is a touch device.
> > +* - ``V4L2_CAP_ORDERED``
> > +  - 0x2000
> > +  - The device queue is ordered.
> >  * - ``V4L2_CAP_DEVICE_CAPS``
> >- 0x8000
> >- The driver fills the ``device_caps`` field. This capability can
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 185d6a0acc06..cd6fc1387f47 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -459,6 +459,7 @@ struct v4l2_capability {
> >  #define V4L2_CAP_STREAMING  0x0400  /* streaming I/O 
> > ioctls */
> >  
> >  #define V4L2_CAP_TOUCH  0x1000  /* Is a touch device */
> > +#define V4L2_CAP_ORDERED0x2000  /* Is the device queue 
> > ordered */
> 
> I guess we discussed that at the Linux Media summit.
> The problem of making it a global flag is that drivers may support
> ordered formats only for some of the formats. E. g., a driver that
> delivers both MPEG and RGB output formats may deliver ordered
> buffers for RGB, and unordered ones for MPEG.
> 
> So, instead of doing a global format at v4l2_capability, it is probably
> better to use the flags field at struct v4l2_fmtdesc.
> 
> That would allow userspace to know in advance what formats support
> it, by calling VIDIOC_ENUM_FMT.

Thanks for clarifying, Mauro. I'll work on making it part of
v4l2_fmtdesc.

Gustavo

Re: [RFC v5 03/11] [media] vb2: add 'ordered_in_driver' property to queues

[Mauro Carvalho Chehab]

Em Wed, 15 Nov 2017 15:10:49 -0200
Gustavo Padovan  escreveu:

> From: Gustavo Padovan 
> 
> We use ordered_in_driver property to optimize for the case where
> the driver can deliver the buffers in an ordered fashion. When it
> is ordered we can use the same fence context for all fences, but
> when it is not we need to a new context for each out-fence.
> 
> So the ordered_in_driver flag will help us with identifying the queues
> that can be optimized and use the same fence context.
> 
> v4: make the property a vector for optimization and not a mandatory thing
> that drivers need to set if they want to use explicit synchronization.
> 
> v3: improve doc (Hans Verkuil)
> 
> v2: rename property to 'ordered_in_driver' to avoid confusion
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  include/media/videobuf2-core.h | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index ef9b64398c8c..38b9c8dd42c6 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -440,6 +440,12 @@ struct vb2_buf_ops {
>   * @fileio_read_once:report EOF after reading the first 
> buffer
>   * @fileio_write_immediately:queue buffer after each write() call
>   * @allow_zero_bytesused:allow bytesused == 0 to be passed to the driver
> + * @ordered_in_driver: if the driver can guarantee that the queue will be
> + *   ordered or not, i.e., the buffers are dequeued from the driver
> + *   in the same order they are queued to the driver. The default
> + *   is not ordered unless the driver sets this flag. Setting it
> + *   when ordering can be guaranted helps to optimize explicit
> + *   fences.
>   * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when 
> QBUF
>   *  has not been called. This is a vb1 idiom that has been 
> adopted
>   *  also by vb2.
> @@ -510,6 +516,7 @@ struct vb2_queue {
>   unsignedfileio_read_once:1;
>   unsignedfileio_write_immediately:1;
>   unsignedallow_zero_bytesused:1;
> + unsignedordered_in_driver:1;

As this may depend on the format, it is probably a good idea to set
this flag either via a function argument or by a function that
would be meant to update it, as video format changes.

>   unsigned   quirk_poll_must_check_waiting_for_buffers:1;
>  
>   struct mutex*lock;


-- 
Thanks,
Mauro

Re: [RFC v5 01/11] [media] v4l: add V4L2_CAP_ORDERED to the uapi

[Mauro Carvalho Chehab]

Em Wed, 15 Nov 2017 15:10:47 -0200
Gustavo Padovan  escreveu:

> From: Gustavo Padovan 
> 
> When using explicit synchronization userspace needs to know if
> the queue can deliver everything back in the same order, so we added
> a new capability that drivers can use to report that they are capable
> of keeping ordering.
> 
> In videobuf2 core when using fences we also make sure to keep the ordering
> of buffers, so if the driver guarantees it too the whole pipeline inside
> V4L2 will be ordered and the V4L2_CAP_ORDERED should be used.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 +++
>  include/uapi/linux/videodev2.h   | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
> b/Documentation/media/uapi/v4l/vidioc-querycap.rst
> index 66fb1b3d6e6e..ed3daa814da9 100644
> --- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
> @@ -254,6 +254,9 @@ specification the ioctl returns an ``EINVAL`` error code.
>  * - ``V4L2_CAP_TOUCH``
>- 0x1000
>- This is a touch device.
> +* - ``V4L2_CAP_ORDERED``
> +  - 0x2000
> +  - The device queue is ordered.
>  * - ``V4L2_CAP_DEVICE_CAPS``
>- 0x8000
>- The driver fills the ``device_caps`` field. This capability can
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 185d6a0acc06..cd6fc1387f47 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -459,6 +459,7 @@ struct v4l2_capability {
>  #define V4L2_CAP_STREAMING  0x0400  /* streaming I/O ioctls 
> */
>  
>  #define V4L2_CAP_TOUCH  0x1000  /* Is a touch device */
> +#define V4L2_CAP_ORDERED0x2000  /* Is the device queue 
> ordered */

I guess we discussed that at the Linux Media summit.
The problem of making it a global flag is that drivers may support
ordered formats only for some of the formats. E. g., a driver that
delivers both MPEG and RGB output formats may deliver ordered
buffers for RGB, and unordered ones for MPEG.

So, instead of doing a global format at v4l2_capability, it is probably
better to use the flags field at struct v4l2_fmtdesc.

That would allow userspace to know in advance what formats support
it, by calling VIDIOC_ENUM_FMT.

Regards,
Mauro

Re: [PATCH 6/6] media: usb: add SPDX identifiers to some code I wrote

[Philippe Ombredanne]

On Fri, Nov 17, 2017 at 11:21 AM, Mauro Carvalho Chehab
 wrote:
> As we're now using SPDX identifiers, on several
> media drivers I wrote, add the proper SPDX, identifying
> the license I meant.
>
> As we're now using the short license, it doesn't make sense to
> keep the original license text.
>
> Also, fix MODULE_LICENSE to properly identify GPL v2.
>
> Signed-off-by: Mauro Carvalho Chehab 

Mauro,
Thanks ++  I can now get rid of a special license detection rule I
had added for the specific language of your notices in the
scancode-toolkit!

FWIW for this 6 patch series:

Reviewed-by: Philippe Ombredanne 

CC: Thomas Gleixner 
CC: Greg Kroah-Hartman 

-- 
Cordially
Philippe Ombredanne

Re: [PATCH v11 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Hans Verkuil]

On 11/11/17 01:25, Niklas Söderlund wrote:
> A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
> hardware blocks are connected between the video sources and the video
> grabbers (VIN).
> 
> Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
> 
> Signed-off-by: Niklas Söderlund 

I found one small typo (see below). After fixing that you can add my:

Reviewed-by: Hans Verkuil 

I would like to see another Ack before merging this (Sakari?).

Regards,

Hans

> ---
>  drivers/media/platform/rcar-vin/Kconfig |  12 +
>  drivers/media/platform/rcar-vin/Makefile|   1 +
>  drivers/media/platform/rcar-vin/rcar-csi2.c | 896 
> 
>  3 files changed, 909 insertions(+)
>  create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
> 
> diff --git a/drivers/media/platform/rcar-vin/Kconfig 
> b/drivers/media/platform/rcar-vin/Kconfig
> index af4c98b44d2e22cb..6875f30c1ae42631 100644
> --- a/drivers/media/platform/rcar-vin/Kconfig
> +++ b/drivers/media/platform/rcar-vin/Kconfig
> @@ -1,3 +1,15 @@
> +config VIDEO_RCAR_CSI2
> + tristate "R-Car MIPI CSI-2 Receiver"
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
> + depends on ARCH_RENESAS || COMPILE_TEST
> + select V4L2_FWNODE
> + ---help---
> +   Support for Renesas R-Car MIPI CSI-2 receiver.
> +   Supports R-Car Gen3 SoCs.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called rcar-csi2.
> +
>  config VIDEO_RCAR_VIN
>   tristate "R-Car Video Input (VIN) Driver"
>   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
> MEDIA_CONTROLLER
> diff --git a/drivers/media/platform/rcar-vin/Makefile 
> b/drivers/media/platform/rcar-vin/Makefile
> index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
> --- a/drivers/media/platform/rcar-vin/Makefile
> +++ b/drivers/media/platform/rcar-vin/Makefile
> @@ -1,3 +1,4 @@
>  rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
>  
> +obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
>  obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> new file mode 100644
> index ..4202c60b4d0aa7f7
> --- /dev/null
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -0,0 +1,896 @@
> +/*
> + * Driver for Renesas R-Car MIPI CSI-2 Receiver
> + *
> + * Copyright (C) 2017 Renesas Electronics Corp.
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register offsets and bits */
> +
> +/* Control Timing Select */
> +#define TREF_REG 0x00
> +#define TREF_TREFBIT(0)
> +
> +/* Software Reset */
> +#define SRST_REG 0x04
> +#define SRST_SRSTBIT(0)
> +
> +/* PHY Operation Control */
> +#define PHYCNT_REG   0x08
> +#define PHYCNT_SHUTDOWNZ BIT(17)
> +#define PHYCNT_RSTZ  BIT(16)
> +#define PHYCNT_ENABLECLK BIT(4)
> +#define PHYCNT_ENABLE_3  BIT(3)
> +#define PHYCNT_ENABLE_2  BIT(2)
> +#define PHYCNT_ENABLE_1  BIT(1)
> +#define PHYCNT_ENABLE_0  BIT(0)
> +
> +/* Checksum Control */
> +#define CHKSUM_REG   0x0c
> +#define CHKSUM_ECC_ENBIT(1)
> +#define CHKSUM_CRC_ENBIT(0)
> +
> +/*
> + * Channel Data Type Select
> + * VCDT[0-15]:  Channel 1 VCDT[16-31]:  Channel 2
> + * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4
> + */
> +#define VCDT_REG 0x10
> +#define VCDT2_REG0x14
> +#define VCDT_VCDTN_ENBIT(15)
> +#define VCDT_SEL_VC(n)   (((n) & 0x3) << 8)
> +#define VCDT_SEL_DTN_ON  BIT(6)
> +#define VCDT_SEL_DT(n)   (((n) & 0x3f) << 0)
> +
> +/* Frame Data Type Select */
> +#define FRDT_REG 0x18
> +
> +/* Field Detection Control */
> +#define FLD_REG  0x1c
> +#define FLD_FLD_NUM(n)   (((n) & 0xff) << 16)
> +#define FLD_FLD_EN4  BIT(3)
> +#define FLD_FLD_EN3  BIT(2)
> +#define FLD_FLD_EN2  BIT(1)
> +#define FLD_FLD_EN   BIT(0)
> +
> +/* Automatic Standby Control */
> +#define ASTBY_REG

Re: [RFC v5 10/11] [media] vb2: add out-fence support to QBUF

[Gustavo Padovan]

2017-11-17 Alexandre Courbot :

> On Thursday, November 16, 2017 2:10:56 AM JST, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
> > an out_fence and send its fd to userspace on the fence_fd field as a
> > return arg for the QBUF call.
> > 
> > The fence is signaled on buffer_done(), when the job on the buffer is
> > finished.
> > 
> > With out-fences we do not allow drivers to requeue buffers through vb2,
> > instead we flag an error on the buffer, signals it fence with error and
> 
> s/it/its
> 
> > return it to userspace.
> > 
> > v6
> > - get rid of the V4L2_EVENT_OUT_FENCE event. We always keep the
> > ordering in vb2 for queueing in the driver, so the event is not
> > necessary anymore and the out_fence_fd is sent back to userspace
> > on QBUF call return arg
> > - do not allow requeueing with out-fences, instead mark the buffer
> > with an error and wake up to userspace.
> > - send the out_fence_fd back to userspace on the fence_fd field
> > 
> > v5:
> > - delay fd_install to DQ_EVENT (Hans)
> > - if queue is fully ordered send OUT_FENCE event right away
> > (Brian)
> > - rename 'q->ordered' to 'q->ordered_in_driver'
> > - merge change to implement OUT_FENCE event here
> > 
> > v4:
> > - return the out_fence_fd in the BUF_QUEUED event(Hans)
> > 
> > v3: - add WARN_ON_ONCE(q->ordered) on requeueing (Hans)
> > - set the OUT_FENCE flag if there is a fence pending (Hans)
> > - call fd_install() after vb2_core_qbuf() (Hans)
> > - clean up fence if vb2_core_qbuf() fails (Hans)
> > - add list to store sync_file and fence for the next queued buffer
> > 
> > v2: check if the queue is ordered.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/media/v4l2-core/videobuf2-core.c | 42
> > +---
> >  drivers/media/v4l2-core/videobuf2-v4l2.c | 21 +++-
> >  2 files changed, 58 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 8b4f0e9bcb36..2eb5ffa8e028 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -354,6 +354,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q,
> > enum vb2_memory memory,
> > vb->planes[plane].length = plane_sizes[plane];
> > vb->planes[plane].min_length = plane_sizes[plane];
> > }
> > +   vb->out_fence_fd = -1;
> > q->bufs[vb->index] = vb;
> > /* Allocate video buffer memory for the MMAP type */
> > @@ -934,10 +935,26 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
> > vb2_buffer_state state)
> > case VB2_BUF_STATE_QUEUED:
> > return;
> > case VB2_BUF_STATE_REQUEUEING:
> > -   if (q->start_streaming_called)
> > -   __enqueue_in_driver(vb);
> > -   return;
> > +
> > +   if (!vb->out_fence) {
> > +   if (q->start_streaming_called)
> > +   __enqueue_in_driver(vb);
> > +   return;
> > +   }
> > +
> > +   /* Do not allow requeuing with explicit synchronization,
> > +* report it as an error to userspace */
> > +   state = VB2_BUF_STATE_ERROR;
> > +
> > +   /* fall through */
> > default:
> > +   if (state == VB2_BUF_STATE_ERROR)
> > +   dma_fence_set_error(vb->out_fence, -EFAULT);
> > +   dma_fence_signal(vb->out_fence);
> > +   dma_fence_put(vb->out_fence);
> > +   vb->out_fence = NULL;
> > +   vb->out_fence_fd = -1;
> > +
> > /* Inform any processes that may be waiting for buffers */
> > wake_up(>done_wq);
> > break;
> > @@ -1325,12 +1342,18 @@ EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
> >  int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index)
> >  {
> > struct vb2_buffer *vb;
> > +   u64 context;
> > vb = q->bufs[index];
> > vb->out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
> > -   vb->out_fence = vb2_fence_alloc(q->out_fence_context);
> > +   if (q->ordered_in_driver)
> > +   context = q->out_fence_context;
> > +   else
> > +   context = dma_fence_context_alloc(1);
> > +
> > +   vb->out_fence = vb2_fence_alloc(context);
> > if (!vb->out_fence) {
> > put_unused_fd(vb->out_fence_fd);
> > return -ENOMEM;
> > @@ -1594,6 +1617,9 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned
> > int index, void *pb,
> > if (pb)
> > call_void_bufop(q, fill_user_buffer, vb, pb);
> > +   fd_install(vb->out_fence_fd, vb->sync_file->file);
> 
> What happens if the buffer does not have an output fence? Shouldn't this be
> protected by a check on whether the 

Re: [PATCH v7 02/25] rcar-vin: register the video device at probe time

[Hans Verkuil]

On 11/11/17 01:38, Niklas Söderlund wrote:
> The driver registers the video device from the async complete callback
> and unregistered in the async unbind callback. This creates problems if
> if the subdevice is bound, unbound and later rebound. The second time

"unbound and later rebound": that's a manual operation via /sys bind/unbind?

I remain unhappy about this patch. It's a workaround for a more basic problem
IMHO.

Can you move this patch to the end of the series? That way I can decide later
whether to merge it or not without blocking the rest of the series.

Other than this patch the only blocking patch is the bindings patch which hasn't
got an Ack yet.

Regards,

Hans

> video_register_device() is called it fails:
> 
>kobject (eb3be918): tried to init an initialized object, something is 
> seriously wrong.
> 
> To prevent this register the video device at probe time and don't allow
> user-space to open the video device if the subdevice is not bound yet.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 124 
> +++-
>  drivers/media/platform/rcar-vin/rcar-v4l2.c |  47 ++-
>  drivers/media/platform/rcar-vin/rcar-vin.h  |   5 +-
>  3 files changed, 95 insertions(+), 81 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 108d776f32651b27..856df3e407c05d97 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -46,54 +46,18 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int 
> direction)
>   return -EINVAL;
>  }
>  
> -static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
> -{
> - struct v4l2_subdev *sd = entity->subdev;
> - struct v4l2_subdev_mbus_code_enum code = {
> - .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> - };
> -
> - code.index = 0;
> - code.pad = entity->source_pad;
> - while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, )) {
> - code.index++;
> - switch (code.code) {
> - case MEDIA_BUS_FMT_YUYV8_1X16:
> - case MEDIA_BUS_FMT_UYVY8_2X8:
> - case MEDIA_BUS_FMT_UYVY10_2X10:
> - case MEDIA_BUS_FMT_RGB888_1X24:
> - entity->code = code.code;
> - return true;
> - default:
> - break;
> - }
> - }
> -
> - return false;
> -}
> -
>  static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
>  {
>   struct rvin_dev *vin = notifier_to_vin(notifier);
>   int ret;
>  
> - /* Verify subdevices mbus format */
> - if (!rvin_mbus_supported(vin->digital)) {
> - vin_err(vin, "Unsupported media bus format for %s\n",
> - vin->digital->subdev->name);
> - return -EINVAL;
> - }
> -
> - vin_dbg(vin, "Found media bus format for %s: %d\n",
> - vin->digital->subdev->name, vin->digital->code);
> -
>   ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
>   if (ret < 0) {
>   vin_err(vin, "Failed to register subdev nodes\n");
>   return ret;
>   }
>  
> - return rvin_v4l2_probe(vin);
> + return 0;
>  }
>  
>  static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
> @@ -103,8 +67,15 @@ static void rvin_digital_notify_unbind(struct 
> v4l2_async_notifier *notifier,
>   struct rvin_dev *vin = notifier_to_vin(notifier);
>  
>   vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
> - rvin_v4l2_remove(vin);
> +
> + mutex_lock(>lock);
> +
> + vin->vdev.ctrl_handler = NULL;
> + v4l2_ctrl_handler_free(>ctrl_handler);
> +
>   vin->digital->subdev = NULL;
> +
> + mutex_unlock(>lock);
>  }
>  
>  static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
> @@ -112,12 +83,14 @@ static int rvin_digital_notify_bound(struct 
> v4l2_async_notifier *notifier,
>struct v4l2_async_subdev *asd)
>  {
>   struct rvin_dev *vin = notifier_to_vin(notifier);
> + struct v4l2_subdev_mbus_code_enum code = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
>   int ret;
>  
>   v4l2_set_subdev_hostdata(subdev, vin);
>  
>   /* Find source and sink pad of remote subdevice */
> -
>   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
>   if (ret < 0)
>   return ret;
> @@ -126,21 +99,82 @@ static int rvin_digital_notify_bound(struct 
> v4l2_async_notifier *notifier,
>   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
>   vin->digital->sink_pad = ret < 0 ? 0 : ret;
>  
> + /* Find compatible subdevices mbus format */
> + vin->digital->code = 0;
> + code.index = 0;
> + code.pad = vin->digital->source_pad;
> + while (!vin->digital->code &&
> +

Re: [PATCH v7 23/25] rcar-vin: extend {start,stop}_streaming to work with media controller

[Hans Verkuil]

On 11/11/17 01:38, Niklas Söderlund wrote:
> The procedure to start or stop streaming using the non-MC single
> subdevice and the MC graph and multiple subdevices are quite different.
> Create a new function to abstract which method is used based on which
> mode the driver is running in and add logic to start the MC graph.
> 
> Signed-off-by: Niklas Söderlund 

One tiny typo in a comment, see below. After fixing that you can add my:

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 113 
> +++--
>  1 file changed, 106 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index fe1319eb4c5df02d..b16b892a4de876bb 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1087,15 +1087,116 @@ static void rvin_buffer_queue(struct vb2_buffer *vb)
>   spin_unlock_irqrestore(>qlock, flags);
>  }
>  
> +static int rvin_set_stream(struct rvin_dev *vin, int on)
> +{
> + struct v4l2_subdev_format fmt = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> + struct media_pipeline *pipe;
> + struct  v4l2_subdev *sd;
> + struct media_pad *pad;
> + int ret;
> +
> + /* No media controller used, simply pass operation to subdevice */
> + if (!vin->info->use_mc) {
> + ret = v4l2_subdev_call(vin->digital->subdev, video, s_stream,
> +on);
> +
> + return ret == -ENOIOCTLCMD ? 0 : ret;
> + }
> +
> + pad = media_entity_remote_pad(>pad);
> + if (!pad)
> + return -EPIPE;
> +
> + sd = media_entity_to_v4l2_subdev(pad->entity);
> + if (!sd)
> + return -EPIPE;
> +
> + if (!on) {
> + media_pipeline_stop(>vdev.entity);
> + ret = v4l2_subdev_call(sd, video, s_stream, 0);
> + return 0;
> + }
> +
> + fmt.pad = pad->index;
> + if (v4l2_subdev_call(sd, pad, get_fmt, NULL, ))
> + return -EPIPE;
> +
> + switch (fmt.format.code) {
> + case MEDIA_BUS_FMT_YUYV8_1X16:
> + case MEDIA_BUS_FMT_UYVY8_2X8:
> + case MEDIA_BUS_FMT_UYVY10_2X10:
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + vin->code = fmt.format.code;
> + break;
> + default:
> + return -EPIPE;
> + }
> +
> + switch (fmt.format.field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + case V4L2_FIELD_SEQ_TB:
> + case V4L2_FIELD_SEQ_BT:
> + /* Supported nativly */

nativly -> natively

> + break;
> + case V4L2_FIELD_ALTERNATE:
> + switch (vin->format.field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + break;
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + case V4L2_FIELD_SEQ_TB:
> + case V4L2_FIELD_SEQ_BT:
> + /* Use VIN hardware to combine the two fields */
> + fmt.format.height *= 2;
> + break;
> + default:
> + return -EPIPE;
> + }
> + break;
> + default:
> + return -EPIPE;
> + }
> +
> + if (fmt.format.width != vin->format.width ||
> + fmt.format.height != vin->format.height)
> + return -EPIPE;
> +
> + pipe = sd->entity.pipe ? sd->entity.pipe : >vdev.pipe;
> + if (media_pipeline_start(>vdev.entity, pipe))
> + return -EPIPE;
> +
> + ret = v4l2_subdev_call(sd, video, s_stream, 1);
> + if (ret == -ENOIOCTLCMD)
> + ret = 0;
> + if (ret)
> + media_pipeline_stop(>vdev.entity);
> +
> + return ret;
> +}
> +
>  static int rvin_start_streaming(struct vb2_queue *vq, unsigned int count)
>  {
>   struct rvin_dev *vin = vb2_get_drv_priv(vq);
> - struct v4l2_subdev *sd;
>   unsigned long flags;
>   int ret;
>  
> - sd = vin_to_source(vin);
> - v4l2_subdev_call(sd, video, s_stream, 1);
> + ret = rvin_set_stream(vin, 1);
> + if (ret) {
> + spin_lock_irqsave(>qlock, flags);
> + return_all_buffers(vin, VB2_BUF_STATE_QUEUED);
> + spin_unlock_irqrestore(>qlock, flags);
> + return ret;
> + }
>  
>   spin_lock_irqsave(>qlock, flags);
>  
> @@ -1104,7 +1205,7 @@ static int rvin_start_streaming(struct vb2_queue *vq, 
> unsigned int count)
>   ret = rvin_capture_start(vin);
>   if (ret) {
>   return_all_buffers(vin, 

Re: [RFC v5 09/11] [media] vb2: add infrastructure to support out-fences

[Gustavo Padovan]

2017-11-17 Alexandre Courbot :

> On Thursday, November 16, 2017 2:10:55 AM JST, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Add vb2_setup_out_fence() and the needed members to struct vb2_buffer.
> > 
> > v3:
> > - Do not hold yet another ref to the out_fence (Brian Starkey)
> > 
> > v2: - change it to reflect fd_install at DQEVENT
> > - add fence context for out-fences
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/media/v4l2-core/videobuf2-core.c | 28 
> >  include/media/videobuf2-core.h   | 20 
> >  2 files changed, 48 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 26de4c80717d..8b4f0e9bcb36 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -24,8 +24,10 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> > @@ -1320,6 +1322,32 @@ int vb2_core_prepare_buf(struct vb2_queue *q,
> > unsigned int index, void *pb)
> >  }
> >  EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
> > +int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index)
> > +{
> > +   struct vb2_buffer *vb;
> > +
> > +   vb = q->bufs[index];
> > +
> > +   vb->out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
> 
> out_fence_fd is allocated in this patch but not used anywhere for the
> moment.
> For consistency, maybe move its allocation to the next patch, or move the
> call
> to fd_install() here if that is possible? In both cases, the call to
> get_unused_fd() can be moved right before fd_install() so you don't need to
> call put_unused_fd() in the error paths below.
> 
> ... same thing for sync_file too. Maybe this patch can just be merged into
> the next one? The current patch just creates an incomplete version of
> vb2_setup_out_fence() for which no user exist yet.

It turned out that out-fences patch is not big at all, so I can merge
them both. I think it will be cleaner, thanks for the suggestion.

Gustavo

Re: [PATCH v7 22/25] rcar-vin: add link notify for Gen3

[Hans Verkuil]

On 11/11/17 01:38, Niklas Söderlund wrote:
> Add the ability to process media device link change request. Link
> enabling is a bit complicated on Gen3, whether or not it's possible to
> enable a link depends on what other links already are enabled. On Gen3
> the 8 VINs are split into two subgroup's (VIN0-3 and VIN4-7) and from a
> routing perspective these two groups are independent of each other.
> Each subgroup's routing is controlled by the subgroup VIN master
> instance (VIN0 and VIN4).
> 
> There are a limited number of possible route setups available for each
> subgroup and the configuration of each setup is dictated by the
> hardware. On H3 for example there are 6 possible route setups for each
> subgroup to choose from.
> 
> This leads to the media device link notification code being rather large
> since it will find the best routing configuration to try and accommodate
> as many links as possible. When it's not possible to enable a new link
> due to hardware constrains the link_notifier callback will return
> -EMLINK.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 205 
> 
>  1 file changed, 205 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 78a9766eb7114959..79b0334d8c563328 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -27,6 +27,209 @@
>  
>  #include "rcar-vin.h"
>  
> +/* 
> -
> + * Media Controller link notification
> + */
> +
> +static unsigned int rvin_group_csi_pad_to_chan(unsigned int pad)
> +{
> + /*
> +  * The companion CSI-2 receiver driver (rcar-csi2) is known
> +  * and we know it have one source pad (pad 0) and four sink
> +  * pads (pad 1-4). So to translate a pad on the remote
> +  * CSI-2 receiver to the VIN internal channel number simply
> +  * subtract one from the pad number.
> +  */
> + return pad - 1;
> +}
> +
> +/* group lock should be held when calling this function */
> +static int rvin_group_entity_to_vin_num(struct rvin_group *group,
> + struct media_entity *entity)
> +{
> + struct video_device *vdev;
> + int i;
> +
> + if (!is_media_entity_v4l2_video_device(entity))
> + return -ENODEV;
> +
> + vdev = media_entity_to_video_device(entity);
> +
> + for (i = 0; i < RCAR_VIN_NUM; i++) {
> + if (!group->vin[i])
> + continue;
> +
> + if (>vin[i]->vdev == vdev)
> + return i;
> + }
> +
> + return -ENODEV;
> +}
> +
> +/* group lock should be held when calling this function */
> +static int rvin_group_entity_to_csi_num(struct rvin_group *group,
> + struct media_entity *entity)
> +{
> + struct v4l2_subdev *sd;
> + int i;
> +
> + if (!is_media_entity_v4l2_subdev(entity))
> + return -ENODEV;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + for (i = 0; i < RVIN_CSI_MAX; i++)
> + if (group->csi[i].subdev == sd)
> + return i;
> +
> + return -ENODEV;
> +}
> +
> +/* group lock should be held when calling this function */
> +static void __rvin_group_build_link_list(struct rvin_group *group,
> +  struct rvin_group_chsel *map,
> +  int start, int len)
> +{
> + struct media_pad *vin_pad, *remote_pad;
> + unsigned int n;
> +
> + for (n = 0; n < len; n++) {
> + map[n].csi = -1;
> + map[n].chan = -1;
> +
> + if (!group->vin[start + n])
> + continue;
> +
> + vin_pad = >vin[start + n]->vdev.entity.pads[0];
> +
> + remote_pad = media_entity_remote_pad(vin_pad);
> + if (!remote_pad)
> + continue;
> +
> + map[n].csi =
> + rvin_group_entity_to_csi_num(group, remote_pad->entity);
> + map[n].chan = rvin_group_csi_pad_to_chan(remote_pad->index);
> + }
> +}
> +
> +/* group lock should be held when calling this function */
> +static int __rvin_group_try_get_chsel(struct rvin_group *group,
> +   struct rvin_group_chsel *map,
> +   int start, int len)
> +{
> + const struct rvin_group_chsel *sel;
> + unsigned int i, n;
> + int chsel;
> +
> + for (i = 0; i < group->vin[start]->info->num_chsels; i++) {
> + chsel = i;
> + for (n = 0; n < len; n++) {
> +
> + /* If the link is not active it's OK */
> + if (map[n].csi == -1)
> + 

Re: [RFC v5 08/11] [media] vb2: add videobuf2 dma-buf fence helpers

[Gustavo Padovan]

2017-11-17 Alexandre Courbot :

> On Friday, November 17, 2017 4:02:56 PM JST, Alexandre Courbot wrote:
> > On Thursday, November 16, 2017 2:10:54 AM JST, Gustavo Padovan wrote:
> > > From: Javier Martinez Canillas 
> > > 
> > > Add a videobuf2-fence.h header file that contains different helpers
> > > for DMA buffer sharing explicit fence support in videobuf2.
> > > 
> > > v2:   - use fence context provided by the caller in vb2_fence_alloc()
> > > 
> > > Signed-off-by: Javier Martinez Canillas  ...
> > 
> > It is probably not a good idea to define that struct here since it will be
> > deduplicated for every source file that includes it.
> > 
> > Maybe change it to a simple declaration, and move the definition to
> > videobuf2-core.c or a dedicated videobuf2-fence.c file?
> > 
> > > +
> > > +static inline struct dma_fence *vb2_fence_alloc(u64 context)
> > > +{
> > > + struct dma_fence *vb2_fence = kzalloc(sizeof(*vb2_fence), GFP_KERNEL);
> > > + ...
> > 
> > Not sure we gain a lot by having this function static inline, but your call.
> > 
> 
> Looking at the following patch, since it seems that this function is only to
> be
> called from vb2_setup_out_fence() anyway, you may as well make it static in
> videobuf2-core.c or even inline it in vb2_setup_out_fence() - it would only
> add a few extra lines to this function.

Okay, that makes sense, I'll will move everything to videobuf2-core.c 

Re: [PATCH v7 20/25] rcar-vin: add chsel information to rvin_info

[Hans Verkuil]

On 11/11/17 01:38, Niklas Söderlund wrote:
> Each Gen3 SoC has a limited set of predefined routing possibilities for
> which CSI-2 device and virtual channel can be routed to which VIN
> instance. Prepare to store this information in the struct rvin_info.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/platform/rcar-vin/rcar-vin.h | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index a9bd570d6635fd47..41c81b8d9fb8e851 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -35,6 +35,9 @@
>  /* Max number on VIN instances that can be in a system */
>  #define RCAR_VIN_NUM 8
>  
> +/* Max number of CHSEL values for any Gen3 SoC */
> +#define RCAR_CHSEL_MAX 6
> +
>  enum chip_id {
>   RCAR_H1,
>   RCAR_M1,
> @@ -91,6 +94,22 @@ struct rvin_graph_entity {
>  
>  struct rvin_group;
>  
> +/** struct rvin_group_chsel - Map a CSI-2 receiver and channel to a CHSEL 
> value
> + * @csi: VIN internal number for CSI-2 device
> + * @chan:Output channel of the CSI-2 receiver. Each R-Car CSI-2
> + *   receiver has four output channels facing the VIN
> + *   devices, each channel can carry one CSI-2 Virtual
> + *   Channel (VC) and there are no correlation between
> + *   output channel number and CSI-2 VC. It's up to the
> + *   CSI-2 receiver driver to configure which VC is
> + *   outputted on which channel, the VIN devices only
> + *   cares about output channels.
> + */
> +struct rvin_group_chsel {
> + enum rvin_csi_id csi;
> + unsigned int chan;
> +};
> +
>  /**
>   * struct rvin_info - Information about the particular VIN implementation
>   * @chip:type of VIN chip
> @@ -98,6 +117,9 @@ struct rvin_group;
>   *
>   * max_width:max input width the VIN supports
>   * max_height:   max input height the VIN supports
> + *
> + * num_chsels:   number of possible chsel values for this VIN
> + * chsels:   routing table VIN <-> CSI-2 for the chsel values
>   */
>  struct rvin_info {
>   enum chip_id chip;
> @@ -105,6 +127,9 @@ struct rvin_info {
>  
>   unsigned int max_width;
>   unsigned int max_height;
> +
> + unsigned int num_chsels;
> + struct rvin_group_chsel chsels[RCAR_VIN_NUM][RCAR_CHSEL_MAX];
>  };
>  
>  /**
> 

Re: [RFC v5 03/11] [media] vb2: add 'ordered_in_driver' property to queues

[Gustavo Padovan]

2017-11-17 Alexandre Courbot :

> On Thursday, November 16, 2017 2:10:49 AM JST, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > We use ordered_in_driver property to optimize for the case where
> > the driver can deliver the buffers in an ordered fashion. When it
> > is ordered we can use the same fence context for all fences, but
> > when it is not we need to a new context for each out-fence.
> 
> "we need to a new context" looks like it is missing a word.

oh

"we need to create a new context" 

Thanks for reviewing the patches!

Gustavo

Re: [PATCH v7 14/25] rcar-vin: add function to manipulate Gen3 CHSEL value

[Hans Verkuil]

On 11/11/17 01:38, Niklas Söderlund wrote:
> On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
> feature of this register is that it's only present in the VIN0 and VIN4
> instances. The register in VIN0 controls the routing for VIN0-3 and the
> register in VIN4 controls routing for VIN4-7.
> 
> To be able to control routing from a media device this function is need
> to control runtime PM for the subgroup master (VIN0 and VIN4). The
> subgroup master must be switched on before the register is manipulated,
> once the operation is complete it's safe to switch the master off and
> the new routing will still be in effect.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 25 +
>  drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index c4f8e81e88c99e28..463c656b9878be52 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -16,6 +16,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -1228,3 +1229,27 @@ int rvin_dma_probe(struct rvin_dev *vin, int irq)
>  
>   return ret;
>  }
> +
> +/* 
> -
> + * Gen3 CHSEL manipulation
> + */
> +
> +void rvin_set_chsel(struct rvin_dev *vin, u8 chsel)
> +{
> + u32 ifmd, vnmc;
> +
> + pm_runtime_get_sync(vin->dev);
> +
> + /* Make register writes take effect immediately */
> + vnmc = rvin_read(vin, VNMC_REG) & ~VNMC_VUP;
> + rvin_write(vin, vnmc, VNMC_REG);
> +
> + ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
> + VNCSI_IFMD_CSI_CHSEL(chsel);
> +
> + rvin_write(vin, ifmd, VNCSI_IFMD_REG);
> +
> + vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
> +
> + pm_runtime_put(vin->dev);
> +}
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
> b/drivers/media/platform/rcar-vin/rcar-vin.h
> index 1f761518a6cc60b8..8a7c51724a90786c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -164,4 +164,6 @@ int rvin_reset_format(struct rvin_dev *vin);
>  
>  const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
>  
> +void rvin_set_chsel(struct rvin_dev *vin, u8 chsel);
> +
>  #endif
> 

Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Hans Verkuil]

Hi Laurent,

On 16/11/17 01:33, Laurent Pinchart wrote:
> Device unplug being asynchronous, it naturally races with operations
> performed by userspace through ioctls or other file operations on video
> device nodes.
> 
> This leads to potential access to freed memory or to other resources
> during device access if unplug occurs during device access. To solve
> this, we need to wait until all device access completes when unplugging
> the device, and block all further access when the device is being
> unplugged.
> 
> Three new functions are introduced. The video_device_enter() and
> video_device_exit() functions must be used to mark entry and exit from
> all code sections where the device can be accessed. The
> video_device_unplug() function is then used in the unplug handler to
> mark the device as being unplugged and wait for all access to complete.
> 
> As an example mark the ioctl handler as a device access section. Other
> file operations need to be protected too, and blocking ioctls (such as
> VIDIOC_DQBUF) need to be handled as well.

As long as the queue field in struct video_device is filled in properly
this shouldn't be a problem.

This looks pretty good, simple and straightforward.

Do we need something similar for media_device? Other devices?

Regards,

Hans

> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/media/v4l2-core/v4l2-dev.c | 57 
> ++
>  include/media/v4l2-dev.h   | 47 +++
>  2 files changed, 104 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
> b/drivers/media/v4l2-core/v4l2-dev.c
> index c647ba648805..c73c6d49e7cf 100644
> --- a/drivers/media/v4l2-core/v4l2-dev.c
> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> @@ -156,6 +156,52 @@ void video_device_release_empty(struct video_device 
> *vdev)
>  }
>  EXPORT_SYMBOL(video_device_release_empty);
>  
> +int video_device_enter(struct video_device *vdev)
> +{
> + bool unplugged;
> +
> + spin_lock(>unplug_lock);
> + unplugged = vdev->unplugged;
> + if (!unplugged)
> + vdev->access_refcount++;
> + spin_unlock(>unplug_lock);
> +
> + return unplugged ? -ENODEV : 0;
> +}
> +EXPORT_SYMBOL_GPL(video_device_enter);
> +
> +void video_device_exit(struct video_device *vdev)
> +{
> + bool wake_up;
> +
> + spin_lock(>unplug_lock);
> + WARN_ON(--vdev->access_refcount < 0);
> + wake_up = vdev->access_refcount == 0;
> + spin_unlock(>unplug_lock);
> +
> + if (wake_up)
> + wake_up(>unplug_wait);
> +}
> +EXPORT_SYMBOL_GPL(video_device_exit);
> +
> +void video_device_unplug(struct video_device *vdev)
> +{
> + bool unplug_blocked;
> +
> + spin_lock(>unplug_lock);
> + unplug_blocked = vdev->access_refcount > 0;
> + vdev->unplugged = true;
> + spin_unlock(>unplug_lock);
> +
> + if (!unplug_blocked)
> + return;
> +
> + if (!wait_event_timeout(vdev->unplug_wait, !vdev->access_refcount,
> + msecs_to_jiffies(15)))
> + WARN(1, "Timeout waiting for device access to complete\n");
> +}
> +EXPORT_SYMBOL_GPL(video_device_unplug);
> +
>  static inline void video_get(struct video_device *vdev)
>  {
>   get_device(>dev);
> @@ -351,6 +397,10 @@ static long v4l2_ioctl(struct file *filp, unsigned int 
> cmd, unsigned long arg)
>   struct video_device *vdev = video_devdata(filp);
>   int ret = -ENODEV;
>  
> + ret = video_device_enter(vdev);
> + if (ret < 0)
> + return ret;
> +
>   if (vdev->fops->unlocked_ioctl) {
>   struct mutex *lock = v4l2_ioctl_get_lock(vdev, cmd);
>  
> @@ -358,11 +408,14 @@ static long v4l2_ioctl(struct file *filp, unsigned int 
> cmd, unsigned long arg)
>   return -ERESTARTSYS;
>   if (video_is_registered(vdev))
>   ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
> + else
> + ret = -ENODEV;
>   if (lock)
>   mutex_unlock(lock);
>   } else
>   ret = -ENOTTY;
>  
> + video_device_exit(vdev);
>   return ret;
>  }
>  
> @@ -841,6 +894,10 @@ int __video_register_device(struct video_device *vdev, 
> int type, int nr,
>   if (WARN_ON(!vdev->v4l2_dev))
>   return -EINVAL;
>  
> + /* unplug support */
> + spin_lock_init(>unplug_lock);
> + init_waitqueue_head(>unplug_wait);
> +
>   /* v4l2_fh support */
>   spin_lock_init(>fh_lock);
>   INIT_LIST_HEAD(>fh_list);
> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
> index e657614521e3..365a94f91dc9 100644
> --- a/include/media/v4l2-dev.h
> +++ b/include/media/v4l2-dev.h
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -178,6 +179,12 @@ struct v4l2_file_operations {
>   * @pipe:  media_pipeline
>   * @fops: pointer to  

[PATCH 1/6] edac: adjust GPLv2 license and SPDX identifiers at the code I wrote

[Mauro Carvalho Chehab]

As we're now using SPDX identifiers, on the several EDAC drivers
I wrote, add the proper SPDX, identifying the license I meant.

As we're now using the short license, it doesn't make sense to
keep the original license text.

Also, fix MODULE_LICENSE to properly identify GPL v2.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/edac/ghes_edac.c   | 4 +---
 drivers/edac/i5400_edac.c  | 3 ++-
 drivers/edac/i7300_edac.c  | 6 ++
 drivers/edac/i7core_edac.c | 6 ++
 drivers/edac/sb_edac.c | 6 ++
 5 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index 6f80eb65c26c..050c4880d23a 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -1,9 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * GHES/EDAC Linux driver
  *
- * This file may be distributed under the terms of the GNU General Public
- * License version 2.
- *
  * Copyright (c) 2013 by Mauro Carvalho Chehab
  *
  * Red Hat Inc. http://www.redhat.com
diff --git a/drivers/edac/i5400_edac.c b/drivers/edac/i5400_edac.c
index 6f8bcdb9256a..e08276673b92 100644
--- a/drivers/edac/i5400_edac.c
+++ b/drivers/edac/i5400_edac.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Intel 5400 class Memory Controllers kernel module (Seaburg)
  *
@@ -1467,7 +1468,7 @@ static void __exit i5400_exit(void)
 module_init(i5400_init);
 module_exit(i5400_exit);
 
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Ben Woodard ");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
 MODULE_AUTHOR("Red Hat Inc. (http://www.redhat.com)");
diff --git a/drivers/edac/i7300_edac.c b/drivers/edac/i7300_edac.c
index 6b5a554ba8e4..9cc117470718 100644
--- a/drivers/edac/i7300_edac.c
+++ b/drivers/edac/i7300_edac.c
@@ -1,9 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Intel 7300 class Memory Controllers kernel module (Clarksboro)
  *
- * This file may be distributed under the terms of the
- * GNU General Public License version 2 only.
- *
  * Copyright (c) 2010 by:
  *  Mauro Carvalho Chehab
  *
@@ -1207,7 +1205,7 @@ static void __exit i7300_exit(void)
 module_init(i7300_init);
 module_exit(i7300_exit);
 
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
 MODULE_AUTHOR("Red Hat Inc. (http://www.redhat.com)");
 MODULE_DESCRIPTION("MC Driver for Intel I7300 memory controllers - "
diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index c16c3b931b3d..735d8aaed458 100644
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /* Intel i7 core/Nehalem Memory Controller kernel module
  *
  * This driver supports the memory controllers found on the Intel
@@ -5,9 +6,6 @@
  * Xeon 55xx and Xeon 56xx also known as Nehalem, Nehalem-EP, Lynnfield
  * and Westmere-EP.
  *
- * This file may be distributed under the terms of the
- * GNU General Public License version 2 only.
- *
  * Copyright (c) 2009-2010 by:
  *  Mauro Carvalho Chehab
  *
@@ -2377,7 +2375,7 @@ static void __exit i7core_exit(void)
 module_init(i7core_init);
 module_exit(i7core_exit);
 
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
 MODULE_AUTHOR("Red Hat Inc. (http://www.redhat.com)");
 MODULE_DESCRIPTION("MC Driver for Intel i7 Core memory controllers - "
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index dc0591654011..9b0209215f69 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -1,11 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /* Intel Sandy Bridge -EN/-EP/-EX Memory Controller kernel module
  *
  * This driver supports the memory controllers found on the Intel
  * processor family Sandy Bridge.
  *
- * This file may be distributed under the terms of the
- * GNU General Public License version 2 only.
- *
  * Copyright (c) 2011 by:
  *  Mauro Carvalho Chehab
  */
@@ -3445,7 +3443,7 @@ module_exit(sbridge_exit);
 module_param(edac_op_state, int, 0444);
 MODULE_PARM_DESC(edac_op_state, "EDAC Error Reporting state: 0=Poll,1=NMI");
 
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
 MODULE_AUTHOR("Red Hat Inc. (http://www.redhat.com)");
 MODULE_DESCRIPTION("MC Driver for Intel Sandy Bridge and Ivy Bridge memory 
controllers - "
-- 
2.14.3

[PATCH 4/6] media: rc: add SPDX identifiers to the code I wrote

[Mauro Carvalho Chehab]

As we're now using SPDX identifiers, on the several
media drivers I wrote, add the proper SPDX, identifying
the license I meant.

As we're now using the short license, it doesn't make sense to
keep the original license text.

Also, fix MODULE_LICENSE to properly identify GPL v2.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/rc/ir-nec-decoder.c   | 12 ++--
 drivers/media/rc/ir-rc5-decoder.c   | 12 ++--
 drivers/media/rc/ir-sanyo-decoder.c | 12 ++--
 drivers/media/rc/rc-core-priv.h | 10 +-
 drivers/media/rc/rc-ir-raw.c| 10 +-
 drivers/media/rc/rc-main.c  | 12 ++--
 6 files changed, 10 insertions(+), 58 deletions(-)

diff --git a/drivers/media/rc/ir-nec-decoder.c 
b/drivers/media/rc/ir-nec-decoder.c
index 817c18f2ddd1..3b9fc60cc9b8 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -1,15 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
 /* ir-nec-decoder.c - handle NEC IR Pulse/Space protocol
  *
  * Copyright (C) 2010 by Mauro Carvalho Chehab
- *
- * This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation version 2 of the License.
- *
- *  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.
  */
 
 #include 
@@ -277,7 +269,7 @@ static void __exit ir_nec_decode_exit(void)
 module_init(ir_nec_decode_init);
 module_exit(ir_nec_decode_exit);
 
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
 MODULE_AUTHOR("Red Hat Inc. (http://www.redhat.com)");
 MODULE_DESCRIPTION("NEC IR protocol decoder");
diff --git a/drivers/media/rc/ir-rc5-decoder.c 
b/drivers/media/rc/ir-rc5-decoder.c
index 1292f534de43..c97b50425abf 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /* ir-rc5-decoder.c - decoder for RC5(x) and StreamZap protocols
  *
  * Copyright (C) 2010 by Mauro Carvalho Chehab
  * Copyright (C) 2010 by Jarod Wilson 
- *
- * This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation version 2 of the License.
- *
- *  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.
  */
 
 /*
@@ -300,7 +292,7 @@ static void __exit ir_rc5_decode_exit(void)
 module_init(ir_rc5_decode_init);
 module_exit(ir_rc5_decode_exit);
 
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Mauro Carvalho Chehab and Jarod Wilson");
 MODULE_AUTHOR("Red Hat Inc. (http://www.redhat.com)");
 MODULE_DESCRIPTION("RC5(x/sz) IR protocol decoder");
diff --git a/drivers/media/rc/ir-sanyo-decoder.c 
b/drivers/media/rc/ir-sanyo-decoder.c
index 758c60956850..86b8f7bbb6ae 100644
--- a/drivers/media/rc/ir-sanyo-decoder.c
+++ b/drivers/media/rc/ir-sanyo-decoder.c
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /* ir-sanyo-decoder.c - handle SANYO IR Pulse/Space protocol
  *
  * Copyright (C) 2011 by Mauro Carvalho Chehab
  *
- * This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation version 2 of the License.
- *
- *  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.
- *
  * This protocol uses the NEC protocol timings. However, data is formatted as:
  * 13 bits Custom Code
  * 13 bits NOT(Custom Code)
@@ -236,7 +228,7 @@ static void __exit ir_sanyo_decode_exit(void)
 module_init(ir_sanyo_decode_init);
 module_exit(ir_sanyo_decode_exit);
 
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
 MODULE_AUTHOR("Red Hat Inc. (http://www.redhat.com)");
 MODULE_DESCRIPTION("SANYO IR protocol decoder");
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index 7da9c96cb058..f5e2de061930 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Remote Controller core raw events header
  *
  * Copyright (C) 2010 by Mauro Carvalho Chehab
- *
- * This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License 

[PATCH 3/6] media: i2c: add SPDX identifiers to the code I wrote

[Mauro Carvalho Chehab]

As we're now using SPDX identifiers, on the several
media drivers I wrote, add the proper SPDX, identifying
the license I meant.

As we're now using the short license, it doesn't make sense to
keep the original license text.

Also, fix MODULE_LICENSE to properly identify GPL v2.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/mt9v011.c  |  4 ++--
 drivers/media/i2c/saa7115.c  | 13 ++---
 drivers/media/i2c/saa711x_regs.h | 11 +--
 drivers/media/i2c/tvp5150.c  |  3 ++-
 drivers/media/i2c/tvp5150_reg.h  |  1 +
 5 files changed, 8 insertions(+), 24 deletions(-)

diff --git a/drivers/media/i2c/mt9v011.c b/drivers/media/i2c/mt9v011.c
index 9ed1b26b6549..5794b2063add 100644
--- a/drivers/media/i2c/mt9v011.c
+++ b/drivers/media/i2c/mt9v011.c
@@ -1,8 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * mt9v011 -Micron 1/4-Inch VGA Digital Image Sensor
  *
  * Copyright (c) 2009 Mauro Carvalho Chehab
- * This code is placed under the terms of the GNU General Public License v2
  */
 
 #include 
@@ -17,7 +17,7 @@
 
 MODULE_DESCRIPTION("Micron mt9v011 sensor driver");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 
 static int debug;
 module_param(debug, int, 0);
diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
index d863b04aa2a8..8a741ff19006 100644
--- a/drivers/media/i2c/saa7115.c
+++ b/drivers/media/i2c/saa7115.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0+
 /* saa711x - Philips SAA711x video decoder driver
  * This driver can work with saa7111, saa7111a, saa7113, saa7114,
  *  saa7115 and saa7118.
@@ -21,16 +22,6 @@
  *
  * Copyright (c) 2005-2006 Mauro Carvalho Chehab 
  * SAA7111, SAA7113 and SAA7118 support
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * 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.
  */
 
 #include "saa711x_regs.h"
@@ -51,7 +42,7 @@
 MODULE_DESCRIPTION("Philips SAA7111/SAA7113/SAA7114/SAA7115/SAA7118 video 
decoder driver");
 MODULE_AUTHOR(  "Maxim Yevtyushkin, Kevin Thayer, Chris Kennedy, "
"Hans Verkuil, Mauro Carvalho Chehab");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 
 static bool debug;
 module_param(debug, bool, 0644);
diff --git a/drivers/media/i2c/saa711x_regs.h b/drivers/media/i2c/saa711x_regs.h
index 730ca90b30ac..3ec25d06bb5b 100644
--- a/drivers/media/i2c/saa711x_regs.h
+++ b/drivers/media/i2c/saa711x_regs.h
@@ -1,16 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /* saa711x - Philips SAA711x video decoder register specifications
  *
  * Copyright (c) 2006 Mauro Carvalho Chehab 
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * 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.
  */
 
 #define R_00_CHIP_VERSION 0x00
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 7b79a7498751..2ce04c9e41b1 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*
  * tvp5150 - Texas Instruments TVP5150A/AM1 and TVP5151 video decoder driver
  *
@@ -30,7 +31,7 @@
 
 MODULE_DESCRIPTION("Texas Instruments TVP5150A/TVP5150AM1/TVP5151 video 
decoder driver");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 
 
 static int debug;
diff --git a/drivers/media/i2c/tvp5150_reg.h b/drivers/media/i2c/tvp5150_reg.h
index 30a48c28d05a..2141ea932f4f 100644
--- a/drivers/media/i2c/tvp5150_reg.h
+++ b/drivers/media/i2c/tvp5150_reg.h
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * tvp5150 - Texas Instruments TVP5150A/AM1 video decoder registers
  *
-- 
2.14.3

[PATCH 2/6] media: rc keymaps: add SPDX identifiers to the code I wrote

[Mauro Carvalho Chehab]

As we're now using SPDX identifiers, on the several
RC keymap files I wrote, add the proper SPDX, identifying
the license I meant.

As we're now using the short license, it doesn't make sense to
keep the original license text.

Also, fix MODULE_LICENSE to identify GPL v2, as this is the
minimal license requirement for those modles.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/rc/keymaps/rc-adstech-dvb-t-pci.c   | 8 ++--
 drivers/media/rc/keymaps/rc-apac-viewcomp.c   | 8 ++--
 drivers/media/rc/keymaps/rc-asus-pc39.c   | 8 ++--
 drivers/media/rc/keymaps/rc-asus-ps3-100.c| 8 ++--
 drivers/media/rc/keymaps/rc-ati-tv-wonder-hd-600.c| 8 ++--
 drivers/media/rc/keymaps/rc-avermedia-a16d.c  | 8 ++--
 drivers/media/rc/keymaps/rc-avermedia-cardbus.c   | 8 ++--
 drivers/media/rc/keymaps/rc-avermedia-dvbt.c  | 8 ++--
 drivers/media/rc/keymaps/rc-avermedia-m135a.c | 8 ++--
 drivers/media/rc/keymaps/rc-avermedia.c   | 8 ++--
 drivers/media/rc/keymaps/rc-avertv-303.c  | 8 ++--
 drivers/media/rc/keymaps/rc-behold-columbus.c | 8 ++--
 drivers/media/rc/keymaps/rc-behold.c  | 8 ++--
 drivers/media/rc/keymaps/rc-budget-ci-old.c   | 8 ++--
 drivers/media/rc/keymaps/rc-cinergy-1400.c| 8 ++--
 drivers/media/rc/keymaps/rc-cinergy.c | 8 ++--
 drivers/media/rc/keymaps/rc-dib0700-nec.c | 8 ++--
 drivers/media/rc/keymaps/rc-dib0700-rc5.c | 8 ++--
 drivers/media/rc/keymaps/rc-dm1105-nec.c  | 8 ++--
 drivers/media/rc/keymaps/rc-dntv-live-dvb-t.c | 8 ++--
 drivers/media/rc/keymaps/rc-dntv-live-dvbt-pro.c  | 8 ++--
 drivers/media/rc/keymaps/rc-em-terratec.c | 8 ++--
 drivers/media/rc/keymaps/rc-encore-enltv-fm53.c   | 8 ++--
 drivers/media/rc/keymaps/rc-encore-enltv.c| 8 ++--
 drivers/media/rc/keymaps/rc-encore-enltv2.c   | 8 ++--
 drivers/media/rc/keymaps/rc-evga-indtube.c| 8 ++--
 drivers/media/rc/keymaps/rc-eztv.c| 8 ++--
 drivers/media/rc/keymaps/rc-flydvb.c  | 8 ++--
 drivers/media/rc/keymaps/rc-flyvideo.c| 8 ++--
 drivers/media/rc/keymaps/rc-fusionhdtv-mce.c  | 8 ++--
 drivers/media/rc/keymaps/rc-gadmei-rm008z.c   | 8 ++--
 drivers/media/rc/keymaps/rc-genius-tvgo-a11mce.c  | 8 ++--
 drivers/media/rc/keymaps/rc-gotview7135.c | 8 ++--
 drivers/media/rc/keymaps/rc-hauppauge.c   | 8 ++--
 drivers/media/rc/keymaps/rc-iodata-bctv7e.c   | 8 ++--
 drivers/media/rc/keymaps/rc-kaiomy.c  | 8 ++--
 drivers/media/rc/keymaps/rc-kworld-315u.c | 8 ++--
 drivers/media/rc/keymaps/rc-kworld-plus-tv-analog.c   | 8 ++--
 drivers/media/rc/keymaps/rc-manli.c   | 8 ++--
 drivers/media/rc/keymaps/rc-msi-tvanywhere-plus.c | 8 ++--
 drivers/media/rc/keymaps/rc-msi-tvanywhere.c  | 8 ++--
 drivers/media/rc/keymaps/rc-nebula.c  | 8 ++--
 drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c | 8 ++--
 drivers/media/rc/keymaps/rc-norwood.c | 8 ++--
 drivers/media/rc/keymaps/rc-npgtech.c | 8 ++--
 drivers/media/rc/keymaps/rc-pctv-sedna.c  | 8 ++--
 drivers/media/rc/keymaps/rc-pinnacle-color.c  | 8 ++--
 drivers/media/rc/keymaps/rc-pinnacle-grey.c   | 8 ++--
 drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c| 8 ++--
 drivers/media/rc/keymaps/rc-pixelview-002t.c  | 8 ++--
 drivers/media/rc/keymaps/rc-pixelview-mk12.c  | 8 ++--
 drivers/media/rc/keymaps/rc-pixelview-new.c   | 8 ++--
 drivers/media/rc/keymaps/rc-pixelview.c   | 8 ++--
 drivers/media/rc/keymaps/rc-powercolor-real-angel.c   | 8 ++--
 drivers/media/rc/keymaps/rc-proteus-2309.c| 8 ++--
 drivers/media/rc/keymaps/rc-purpletv.c| 8 ++--
 drivers/media/rc/keymaps/rc-pv951.c   | 8 ++--
 drivers/media/rc/keymaps/rc-real-audio-220-32-keys.c  | 8 ++--
 drivers/media/rc/keymaps/rc-tbs-nec.c | 8 ++--
 drivers/media/rc/keymaps/rc-terratec-cinergy-xs.c | 8 ++--
 drivers/media/rc/keymaps/rc-tevii-nec.c   | 8 ++--
 drivers/media/rc/keymaps/rc-tt-1500.c | 8 ++--
 drivers/media/rc/keymaps/rc-videomate-s350.c  | 8 ++--
 drivers/media/rc/keymaps/rc-videomate-tv-pvr.c| 8 ++--
 drivers/media/rc/keymaps/rc-winfast-usbii-deluxe.c| 8 ++--
 drivers/media/rc/keymaps/rc-winfast.c | 8 ++--
 66 files changed, 132 insertions(+), 396 deletions(-)

diff --git 

[PATCH 6/6] media: usb: add SPDX identifiers to some code I wrote

[Mauro Carvalho Chehab]

As we're now using SPDX identifiers, on several
media drivers I wrote, add the proper SPDX, identifying
the license I meant.

As we're now using the short license, it doesn't make sense to
keep the original license text.

Also, fix MODULE_LICENSE to properly identify GPL v2.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/au0828/au0828-input.c| 23 +++
 drivers/media/usb/cx231xx/cx231xx-input.c  | 10 +-
 drivers/media/usb/tm6000/tm6000-alsa.c |  7 ++-
 drivers/media/usb/tm6000/tm6000-cards.c| 12 ++--
 drivers/media/usb/tm6000/tm6000-core.c | 10 +-
 drivers/media/usb/tm6000/tm6000-i2c.c  | 10 +-
 drivers/media/usb/tm6000/tm6000-regs.h | 10 +-
 drivers/media/usb/tm6000/tm6000-stds.c | 10 +-
 drivers/media/usb/tm6000/tm6000-usb-isoc.h | 10 +-
 drivers/media/usb/tm6000/tm6000-video.c| 10 +-
 drivers/media/usb/tm6000/tm6000.h  | 10 +-
 11 files changed, 19 insertions(+), 103 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-input.c 
b/drivers/media/usb/au0828/au0828-input.c
index 7996eb83a54e..f254657dd844 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -1,20 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*
-  handle au0828 IR remotes via linux kernel input layer.
-
-   Copyright (C) 2014 Mauro Carvalho Chehab 
-   Copyright (c) 2014 Samsung Electronics Co., Ltd.
-
-  Based on em28xx-input.c.
-
-  This program is free software; you can redistribute it and/or modify
-  it under the terms of the GNU General Public License as published by
-  the Free Software Foundation; either version 2 of the License, or
-  (at your option) any later version.
-
-  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.
+ * handle au0828 IR remotes via linux kernel input layer.
+ *
+ * Copyright (C) 2014 Mauro Carvalho Chehab 
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * Based on em28xx-input.c.
  */
 
 #include "au0828.h"
diff --git a/drivers/media/usb/cx231xx/cx231xx-input.c 
b/drivers/media/usb/cx231xx/cx231xx-input.c
index 02ebeb16055f..62bbd52bad95 100644
--- a/drivers/media/usb/cx231xx/cx231xx-input.c
+++ b/drivers/media/usb/cx231xx/cx231xx-input.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  *   cx231xx IR glue driver
  *
@@ -7,15 +8,6 @@
  *   however, a few designs are using an external I2C chip for IR, instead
  *   of using the one provided by the chip.
  *   This driver provides support for those extra devices
- *
- *   This program is free software; you can redistribute it and/or
- *   modify it under the terms of the GNU General Public License as
- *   published by the Free Software Foundation version 2.
- *
- *   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.
  */
 
 #include "cx231xx.h"
diff --git a/drivers/media/usb/tm6000/tm6000-alsa.c 
b/drivers/media/usb/tm6000/tm6000-alsa.c
index 3717a6844ea8..3a76d1742f71 100644
--- a/drivers/media/usb/tm6000/tm6000-alsa.c
+++ b/drivers/media/usb/tm6000/tm6000-alsa.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  *
  *  Support for audio capture for tm5600/6000/6010
  *(c) 2007-2008 Mauro Carvalho Chehab
  *
  *  Based on cx88-alsa.c
- *
- *  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.
  */
 
 #include 
@@ -57,7 +54,7 @@ MODULE_PARM_DESC(index, "Index value for tm6000x capture 
interface(s).");
 
 MODULE_DESCRIPTION("ALSA driver module for tm5600/tm6000/tm6010 based TV 
cards");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 
MODULE_SUPPORTED_DEVICE("{{Trident,tm5600},{{Trident,tm6000},{{Trident,tm6010}");
 static unsigned int debug;
 module_param(debug, int, 0644);
diff --git a/drivers/media/usb/tm6000/tm6000-cards.c 
b/drivers/media/usb/tm6000/tm6000-cards.c
index 2537643a1808..27496f085c72 100644
--- a/drivers/media/usb/tm6000/tm6000-cards.c
+++ b/drivers/media/usb/tm6000/tm6000-cards.c
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  *  tm6000-cards.c - driver for TM5600/TM6000/TM6010 USB video capture devices
  *
  *  Copyright (C) 2006-2007 Mauro Carvalho Chehab 
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software 

[PATCH 5/6] media: tuners: add SPDX identifiers to the code I wrote

[Mauro Carvalho Chehab]

As we're now using SPDX identifiers, on the several
media drivers I wrote, add the proper SPDX, identifying
the license I meant.

As we're now using the short license, it doesn't make sense to
keep the original license text.

Also, fix MODULE_LICENSE to properly identify GPL v2.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/tuners/r820t.c  | 14 ++
 drivers/media/tuners/tea5761.c|  5 ++---
 drivers/media/tuners/tea5767.c|  4 ++--
 drivers/media/tuners/tuner-xc2028-types.h |  2 +-
 drivers/media/tuners/tuner-xc2028.c   |  5 ++---
 drivers/media/tuners/tuner-xc2028.h   |  2 +-
 6 files changed, 10 insertions(+), 22 deletions(-)

diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c
index ba80376a3b86..d80297adbf68 100644
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Rafael Micro R820T driver
  *
@@ -19,17 +20,6 @@
  * improve reception. This was not implemented here yet.
  *
  * RF Gain set/get is not implemented.
- *
- *This program is free software; you can redistribute it and/or modify
- *it under the terms of the GNU General Public License as published by
- *the Free Software Foundation; either version 2 of the License, or
- *(at your option) any later version.
- *
- *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.
- *
  */
 
 #include 
@@ -2388,4 +2378,4 @@ EXPORT_SYMBOL_GPL(r820t_attach);
 
 MODULE_DESCRIPTION("Rafael Micro r820t silicon tuner driver");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/tuners/tea5761.c b/drivers/media/tuners/tea5761.c
index a9b1bb134409..455b7dbad6ca 100644
--- a/drivers/media/tuners/tea5761.c
+++ b/drivers/media/tuners/tea5761.c
@@ -1,10 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * For Philips TEA5761 FM Chip
  * I2C address is allways 0x20 (0x10 at 7-bit mode).
  *
  * Copyright (c) 2005-2007 Mauro Carvalho Chehab (mche...@infradead.org)
- * This code is placed under the terms of the GNUv2 General Public License
- *
  */
 
 #include 
@@ -341,4 +340,4 @@ EXPORT_SYMBOL_GPL(tea5761_autodetection);
 
 MODULE_DESCRIPTION("Philips TEA5761 FM tuner driver");
 MODULE_AUTHOR("Mauro Carvalho Chehab ");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/tuners/tea5767.c b/drivers/media/tuners/tea5767.c
index 525b7ab90c80..d89764ad9209 100644
--- a/drivers/media/tuners/tea5767.c
+++ b/drivers/media/tuners/tea5767.c
@@ -1,10 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * For Philips TEA5767 FM Chip used on some TV Cards like Prolink Pixelview
  * I2C address is allways 0xC0.
  *
  *
  * Copyright (c) 2005 Mauro Carvalho Chehab (mche...@infradead.org)
- * This code is placed under the terms of the GNU General Public License
  *
  * tea5767 autodetection thanks to Torsten Seeboth and Atsushi Nakagawa
  * from their contributions on DScaler.
@@ -473,4 +473,4 @@ EXPORT_SYMBOL_GPL(tea5767_autodetection);
 
 MODULE_DESCRIPTION("Philips TEA5767 FM tuner driver");
 MODULE_AUTHOR("Mauro Carvalho Chehab ");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/tuners/tuner-xc2028-types.h 
b/drivers/media/tuners/tuner-xc2028-types.h
index 7e4798783db7..43949ff69e67 100644
--- a/drivers/media/tuners/tuner-xc2028-types.h
+++ b/drivers/media/tuners/tuner-xc2028-types.h
@@ -1,10 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /* tuner-xc2028_types
  *
  * This file includes internal tipes to be used inside tuner-xc2028.
  * Shouldn't be included outside tuner-xc2028
  *
  * Copyright (c) 2007-2008 Mauro Carvalho Chehab (mche...@infradead.org)
- * This code is placed under the terms of the GNU General Public License v2
  */
 
 /* xc3028 firmware types */
diff --git a/drivers/media/tuners/tuner-xc2028.c 
b/drivers/media/tuners/tuner-xc2028.c
index b5b62b08159e..d2870fba4591 100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -1,11 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /* tuner-xc2028
  *
  * Copyright (c) 2007-2008 Mauro Carvalho Chehab (mche...@infradead.org)
  *
  * Copyright (c) 2007 Michel Ludwig (michel.lud...@gmail.com)
  *   - frontend interface
- *
- * This code is placed under the terms of the GNU General Public License v2
  */
 
 #include 
@@ -1521,6 +1520,6 @@ EXPORT_SYMBOL(xc2028_attach);
 MODULE_DESCRIPTION("Xceive xc2028/xc3028 tuner driver");
 MODULE_AUTHOR("Michel Ludwig ");
 MODULE_AUTHOR("Mauro Carvalho Chehab ");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

[jacopo mondi]

Hi Sakari!

On Fri, Nov 17, 2017 at 02:36:51AM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Wed, Nov 15, 2017 at 03:25:11PM +0100, jacopo mondi wrote:
> > Hi Sakari,
> >thanks for review!
>
> You're welcome!
>
> > On Wed, Nov 15, 2017 at 02:45:51PM +0200, Sakari Ailus wrote:
> > > Hi Jacopo,
> > >
> > > Could you remove the original driver and send the patch using git
> > > send-email -C ? That way a single patch would address converting it to a
> > > proper V4L2 driver as well as move it to the correct location. The changes
> > > would be easier to review that way since then, well, it'd be easier to see
> > > the changes. :-)
> >
> > Actually I prefer not to remove the existing driver at the moment. See
> > the cover letter for reasons why not to do so right now...
>
> So it's about testing mostly? Does someone (possibly you) have those boards
> to test? I'd like to see this patchset to remove that last remaining SoC
> camera bridge driver. :-)

Well, we agreed that for most of those platforms, compile testing it
would be enough (let's believe in "if it compiles, it works"). I
personally don't have access to those boards, and frankly I'm not even
sure there are many of them around these days (I guess most of them
are not even produced anymore).

>
> >
> > Also, there's not that much code from the old driver in here, surely
> > less than the default 50% -C and -M options of 'git format-patch' use
> > as a threshold for detecting copies iirc..
>
> Oh, if that's so, then makes sense to review it as a new driver.

thanks :)

>
> >
> > > The same goes for the two V4L2 SoC camera sensor / video decoder drivers 
> > > at
> > > the end of the set.
> > >
> >
> > Also in this case I prefer not to remove existing code, as long as
> > there are platforms using it..
>
> Couldn't they use this driver instead?

Oh, they will eventually, I hope :)

I would like to make sure we're all on the same page with this. My
preference would be:

1) Have renesas-ceu.c driver merged with Migo-R ported to use this new
driver as an 'example'.
2) Do not remove any of the existing soc_camera code at this point
3) Port all other 4 SH users of sh_mobile_ceu_camera to use the now
merged renesas-ceu driver
4) Remove sh_mobile_ceu_camera and soc_camera sensor drivers whose
only users were those 4 SH boards
5) Remove soc_camera completely. For my understanding there are some
PXA platforms still using soc_camera provided utilities somewhere.
Hans knows better, but we can discuss this once we'll get there.

Let me know if this is ok for everyone.

Thanks
   j

Re: [PATCH v1 06/10] sh: sh7722: Rename CEU clock

[jacopo mondi]

Hi Geert,

On Wed, Nov 15, 2017 at 02:13:43PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi
>  wrote:
> > Rename CEU clock to match the new platform driver name used in Migo-R.
> >
> > There are no other sh7722 based devices Migo-R apart, so we can safely
> > rename this.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c 
> > b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> > index 8f07a1a..d85091e 100644
> > --- a/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> > +++ b/arch/sh/kernel/cpu/sh4a/clock-sh7722.c
> > @@ -223,7 +223,7 @@ static struct clk_lookup lookups[] = {
> > CLKDEV_DEV_ID("sh-vou.0", _clks[HWBLK_VOU]),
> > CLKDEV_CON_ID("jpu0", _clks[HWBLK_JPU]),
> > CLKDEV_CON_ID("beu0", _clks[HWBLK_BEU]),
> > -   CLKDEV_DEV_ID("sh_mobile_ceu.0", _clks[HWBLK_CEU]),
> > +   CLKDEV_DEV_ID("renesas-ceu.0", _clks[HWBLK_CEU]),
> > CLKDEV_CON_ID("veu0", _clks[HWBLK_VEU]),
> > CLKDEV_CON_ID("vpu0", _clks[HWBLK_VPU]),
> > CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", _clks[HWBLK_LCDC]),
>
> Shouldn't this be merged with "[PATCH v1 05/10] arch: sh: migor: Use new
> renesas-ceu camera driver", to avoid breaking bisection?

That's a good idea. I will merge these two commits in v2.

Thanks
   j

>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCH v1 08/10] media: i2c: ov772x: Remove soc_camera dependencies

[jacopo mondi]

Hi Sakari!

On Fri, Nov 17, 2017 at 02:43:15AM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Wed, Nov 15, 2017 at 11:56:01AM +0100, Jacopo Mondi wrote:
> >

[snip]

> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -25,8 +26,8 @@
> >  #include 
> >
> >  #include 
> > -#include 
> > -#include 
> > +
> > +#include 
>
> Alphabetical order would be nice.

ups!

>
> >  #include 
> >  #include 
> >  #include 
> > @@ -393,7 +394,7 @@ struct ov772x_win_size {
> >  struct ov772x_priv {
> > struct v4l2_subdevsubdev;
> > struct v4l2_ctrl_handler  hdl;
> > -   struct v4l2_clk  *clk;
> > +   struct clk   *clk;
> > struct ov772x_camera_info*info;
> > const struct ov772x_color_format *cfmt;
> > const struct ov772x_win_size *win;
> > @@ -550,7 +551,7 @@ static int ov772x_reset(struct i2c_client *client)
> >  }
> >
> >  /*
> > - * soc_camera_ops function
> > + * subdev ops
> >   */
> >
> >  static int ov772x_s_stream(struct v4l2_subdev *sd, int enable)
> > @@ -650,13 +651,36 @@ static int ov772x_s_register(struct v4l2_subdev *sd,
> >  }
> >  #endif
> >
> > +static int ov772x_power_on(struct ov772x_priv *priv)
> > +{
> > +   int ret;
> > +
> > +   if (priv->info->platform_enable) {
> > +   ret = priv->info->platform_enable();
> > +   if (ret)
> > +   return ret;
>
> What does this do, enable the regulator?

Well, it depends on what function the platform code stores in
'platform_enable' pointer, doesn't it?

As you can see in [05/10] of this series, for Migo-R it's not about
a regulator, but switching between the two available video inputs
(OV7725 and TW9910) toggling their 'enable' pins.

Thanks
   j

Re: [linux-sunxi] Cedrus driver

[Maxime Ripard]

Hi Nicolas,

On Thu, Nov 16, 2017 at 02:59:55PM -0500, Nicolas Dufresne wrote:
> Le jeudi 16 novembre 2017 à 12:02 +0100, Maxime Ripard a écrit :
> > Assuming that the request API is in, we'd need to:
> >   - Finish the MPEG4 support
> >   - Work on more useful codecs (H264 comes to my mind)
> 
> For which we will have to review the tables and make sure they match
> the spec (the easy part). But as an example, that branch uses a table
> that merge Mpeg4 VOP and VOP Short Header. We need to make sure it does
> not pause problems or split it up. On top of that, ST and Rockchip
> teams should give some help and sync with these tables on their side.
> We also need to consider decoder like Tegra 2. In H264, they don't need
> frame parsing, but just the PPS/SPS data (might just be parsed in the
> driver, like CODA ?). There is other mode of operation, specially in
> H264/HEVC low latency, where the decoder will be similar, but will
> accept and process slices right away, without waiting for the full
> frame.

Sorry if it's a dumb question, but what branches and tables are you
talking about here?

> We also need some doc, to be able to tell the GStreamer and FFMPEG team
> how to detect and handle these decoder. I doubt the libv4l2 proposed
> approach will be used for these two projects since they already have
> their own parser and would like to not parse twice. As an example, we
> need to document that V4L2_PIX_FMT_MPEG2_FRAME implies using the
> Request API and specific CID. We should probably also ping the Chrome
> Devs, which probably have couple of pending branches around this.

We've had a prototype that wasn't based on libv4l but was based on the
VA-API, and it's been working great for us so far.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature