cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Wed Jul 26 05:00:17 CEST 2017
media-tree git hash:0e50e84a11f4854e9a7e3b7f4443ffb99e6be292
media_build git hash:   bc1db0a204a87da86349ea5e64ae0d65e945609d
v4l-utils git hash: 5649bf5343fb7c32f909f92ec07c1bf5b77ff869
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.11.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: WARNINGS
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: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9.26-i686: ERRORS
linux-4.10.14-i686: ERRORS
linux-4.11-i686: ERRORS
linux-4.12.1-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9.26-x86_64: ERRORS
linux-4.10.14-x86_64: ERRORS
linux-4.11-x86_64: ERRORS
linux-4.12.1-x86_64: ERRORS
apps: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Grattis Vinnare

[Robert Croll]

Grattis Vinnare



Din e-post-Adress har precis vunnit € 450,000.00 (Furo hundrafemtiotusen Euro.) 
I Uplift International välgörenhetsprogram. Ref nr: Sp / 229 / 0-01 / 07 / 5-02 
/ ES. Tur nr: 9/11/13/24/40.



För mer information och ansökningsförfarandet kontakta;



CAPITAL CLAIM AGENCY
Mr. John Carlos.
Email: capitalsi...@aol.com
Tel: +34-672-853-656 (talar engelska Endast)



Med ditt fullständiga namn, adress, ålder, yrke, telefonnummer



Skicka ditt svar på detta mail: 
capitalsi...@aol.com



OBS: Detta är ett internationellt lotteri program, så det här meddelandet 
anmälan automatiskt översatt från engelska till svenska



Grattis !!!

Re: [PATCH 04/12] [media] uvc: enable subscriptions to other events

[Gustavo Padovan]

2017-07-10 Gustavo Padovan :

> 2017-07-07 Shuah Khan :
> 
> > On 06/16/2017 01:39 AM, Gustavo Padovan wrote:
> > > From: Gustavo Padovan 
> > > 
> > > Call v4l2_ctrl_subscribe_event to subscribe to more events supported by
> > > v4l.
> > > 
> > > Signed-off-by: Gustavo Padovan 
> > > ---
> > >  drivers/media/usb/uvc/uvc_v4l2.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> > > b/drivers/media/usb/uvc/uvc_v4l2.c
> > > index 3e7e283..dfa0ccd 100644
> > > --- a/drivers/media/usb/uvc/uvc_v4l2.c
> > > +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> > > @@ -1240,7 +1240,7 @@ static int uvc_ioctl_subscribe_event(struct v4l2_fh 
> > > *fh,
> > >   case V4L2_EVENT_CTRL:
> > >   return v4l2_event_subscribe(fh, sub, 0, &uvc_ctrl_sub_ev_ops);
> > >   default:
> > > - return -EINVAL;
> > > + return v4l2_ctrl_subscribe_event(fh, sub);
> > 
> > This looks incorrect. With this change driver will be subscribing to all
> > v4l2 events? Is this the intent?
> 
> The intent was to enable this driver to subscribe to BUF_QUEUED events. 
> It is the only one who can't at the moment. I'll review this.

This change do not enable all events, the only new event added is the
BUF_QUEUED. v4l2_ctrl_subscribe_event() only add V4L2_EVENT_CTRL and
V4L2_EVENT_BUF_QUEUED, but the V4L2_EVENT_CTRL case can't be accessed
tere is this situation.

Gustavo

Re: [PATCH 05/12] [media] vivid: assign the specific device to the vb2_queue->dev

[Gustavo Padovan]

2017-07-07 Shuah Khan :

> On 06/16/2017 01:39 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Instead of assigning the global v4l2 device, assign the specific device.
> > This was causing trouble when using using V4L2 events with vivid
> > devices. The device's queue should be the same we opened in userspace.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/media/platform/vivid/vivid-core.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/media/platform/vivid/vivid-core.c 
> > b/drivers/media/platform/vivid/vivid-core.c
> > index ef344b9..8843170 100644
> > --- a/drivers/media/platform/vivid/vivid-core.c
> > +++ b/drivers/media/platform/vivid/vivid-core.c
> > @@ -1070,7 +1070,7 @@ static int vivid_create_instance(struct 
> > platform_device *pdev, int inst)
> > q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > q->min_buffers_needed = 2;
> > q->lock = &dev->mutex;
> > -   q->dev = dev->v4l2_dev.dev;
> > +   q->dev = &dev->vid_cap_dev.dev;
> 
> Does this work in all cases? My concern is that in some code paths
> q->dev might be used to initiate release perhaps.
> 
> Fore example v4l2_dev.release is vivid_dev_release()
> dev->v4l2_dev.release = vivid_dev_release;
> 
> vid_cap_dev release is video_device_release_empty
> 
> This is one difference, but there might be others and the code paths
> that might depend on q->dev being the v4l2_dev.dev which is the global
> dev.

The release call comes from the v4l2-core as we pass the v4l2 device on
v4l2_register_device(). q->dev is in just one ocasion and setting it to
a different device doesn't change the behavior. That code just check if
it is queued or not.

Gustavo

[SUSPECTED SPAM] Quick Loans

[Sec Capital Loans]

Loan Offer at 3%, Feel Free to REPLY back to us for more info.

Email Asegurado porby Check Point

Re: [PATCH] media: v4l: use WARN_ON(1) instead of __WARN()

[Sakari Ailus]

On Tue, Jul 25, 2017 at 05:39:14PM +0200, Arnd Bergmann wrote:
> __WARN() cannot be used in portable code, since it is only
> available on some architectures and configurations:
> 
> drivers/media/platform/pxa_camera.c: In function 'pxa_mbus_config_compatible':
> drivers/media/platform/pxa_camera.c:642:3: error: implicit declaration of 
> function '__WARN'; did you mean '__WALL'? 
> [-Werror=implicit-function-declaration]
> 
> The common way to express an unconditional warning is WARN_ON(1),
> so let's use that here.
> 
> Fixes: 97bbdf02d905 ("media: v4l: Add support for CSI-1 and CCP2 busses")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/media/platform/pxa_camera.c  | 2 +-
>  drivers/media/platform/soc_camera/soc_mediabus.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/pxa_camera.c 
> b/drivers/media/platform/pxa_camera.c
> index 3898a5cd8664..0d4af6d91ffc 100644
> --- a/drivers/media/platform/pxa_camera.c
> +++ b/drivers/media/platform/pxa_camera.c
> @@ -639,7 +639,7 @@ static unsigned int pxa_mbus_config_compatible(const 
> struct v4l2_mbus_config *cf
>V4L2_MBUS_CSI2_CONTINUOUS_CLOCK);
>   return (!mipi_lanes || !mipi_clock) ? 0 : common_flags;
>   default:
> - __WARN();
> + WARN_ON(1);
>   return -EINVAL;
>   }
>   return 0;
> diff --git a/drivers/media/platform/soc_camera/soc_mediabus.c 
> b/drivers/media/platform/soc_camera/soc_mediabus.c
> index 43192d80beef..0ad4b28266e4 100644
> --- a/drivers/media/platform/soc_camera/soc_mediabus.c
> +++ b/drivers/media/platform/soc_camera/soc_mediabus.c
> @@ -509,7 +509,7 @@ unsigned int soc_mbus_config_compatible(const struct 
> v4l2_mbus_config *cfg,
>V4L2_MBUS_CSI2_CONTINUOUS_CLOCK);
>   return (!mipi_lanes || !mipi_clock) ? 0 : common_flags;
>   default:
> - __WARN();
> + WARN_ON(1);
>   return -EINVAL;
>   }
>   return 0;

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3] [media] v4l2: Add support for go2001 PCI codec driver

[Nicolas Dufresne]

Le mardi 25 juillet 2017 à 19:40 +0200, Thierry Escande a écrit :
> This patch adds support for the go2001 PCI codec driver. This
> hardware
> is present on ChromeOS based devices like the Acer ChromeBox and
> Acer/LG
> ChromeBase 24 devices. This chipset comes on a mini PCI-E card with
> Google as PCI vendor ID (0x1ae0).
> 
> This driver comes from the ChromeOS v3.18 kernel tree and has been
> modified to support vb2_buffer restructuring introduced in Linux
> v4.4.
> 
> The go2001 firmware files can be found in the build tree of the
> Google
> Chromium OS open source project.
> 
> This driver is originally developed by:
>  Pawel Osciak 
>  Ville-Mikko Rautio 
>  henryhsu 
>  Wu-Cheng Li 
> 
> Signed-off-by: Thierry Escande 
> ---
>  drivers/media/pci/Kconfig|2 +
>  drivers/media/pci/Makefile   |1 +
>  drivers/media/pci/go2001/Kconfig |   11 +
>  drivers/media/pci/go2001/Makefile|2 +
>  drivers/media/pci/go2001/go2001.h|  331 
>  drivers/media/pci/go2001/go2001_driver.c | 2525
> ++
>  drivers/media/pci/go2001/go2001_hw.c | 1362 
>  drivers/media/pci/go2001/go2001_hw.h |   55 +
>  drivers/media/pci/go2001/go2001_proto.h  |  359 +
>  9 files changed, 4648 insertions(+)
>  create mode 100644 drivers/media/pci/go2001/Kconfig
>  create mode 100644 drivers/media/pci/go2001/Makefile
>  create mode 100644 drivers/media/pci/go2001/go2001.h
>  create mode 100644 drivers/media/pci/go2001/go2001_driver.c
>  create mode 100644 drivers/media/pci/go2001/go2001_hw.c
>  create mode 100644 drivers/media/pci/go2001/go2001_hw.h
>  create mode 100644 drivers/media/pci/go2001/go2001_proto.h
> 
> diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig
> index da28e68..837681e 100644
> --- a/drivers/media/pci/Kconfig
> +++ b/drivers/media/pci/Kconfig
> @@ -54,5 +54,7 @@ source "drivers/media/pci/smipcie/Kconfig"
>  source "drivers/media/pci/netup_unidvb/Kconfig"
>  endif
>  
> +source "drivers/media/pci/go2001/Kconfig"
> +
>  endif #MEDIA_PCI_SUPPORT
>  endif #PCI
> diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile
> index a7e8af0..58639b7 100644
> --- a/drivers/media/pci/Makefile
> +++ b/drivers/media/pci/Makefile
> @@ -32,3 +32,4 @@ obj-$(CONFIG_STA2X11_VIP) += sta2x11/
>  obj-$(CONFIG_VIDEO_SOLO6X10) += solo6x10/
>  obj-$(CONFIG_VIDEO_COBALT) += cobalt/
>  obj-$(CONFIG_VIDEO_TW5864) += tw5864/
> +obj-$(CONFIG_VIDEO_GO2001) += go2001/
> diff --git a/drivers/media/pci/go2001/Kconfig
> b/drivers/media/pci/go2001/Kconfig
> new file mode 100644
> index 000..c7b5149
> --- /dev/null
> +++ b/drivers/media/pci/go2001/Kconfig
> @@ -0,0 +1,11 @@
> +config VIDEO_GO2001
> + tristate "GO2001 codec driver"
> + depends on VIDEO_V4L2 && PCI
> + select VIDEOBUF2_DMA_SG
> + ---help---
> +   This driver supports the GO2001 PCI hardware codec. This
> codec
> +   is present on ChromeOS based devices like the Acer
> ChromeBox
> +   and ChromeBase 24 and LG ChromeBase as well.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called go2001.
> diff --git a/drivers/media/pci/go2001/Makefile
> b/drivers/media/pci/go2001/Makefile
> new file mode 100644
> index 000..20bad18
> --- /dev/null
> +++ b/drivers/media/pci/go2001/Makefile
> @@ -0,0 +1,2 @@
> +go2001-objs  := go2001_driver.o go2001_hw.o
> +obj-$(CONFIG_VIDEO_GO2001) += go2001.o
> diff --git a/drivers/media/pci/go2001/go2001.h
> b/drivers/media/pci/go2001/go2001.h
> new file mode 100644
> index 000..0e5ccfd
> --- /dev/null
> +++ b/drivers/media/pci/go2001/go2001.h
> @@ -0,0 +1,331 @@
> +/*
> + *  go2001 - GO2001 codec driver.
> + *
> + *  Author : Pawel Osciak 
> + *
> + *  Copyright (C) 2017 Google, Inc.
> + *
> + *  This program is free software; you can redistribute it and/or
> modify
> + *  it under the terms of the GNU General Public License as
> published by
> + *  the Free Software Foundation; either version 2 of the License,
> or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public
> License
> + *  along with this program.  If not, see  es/>.
> + */
> +#ifndef _MEDIA_PCI_GO2001_GO2001_H_
> +#define _MEDIA_PCI_GO2001_GO2001_H_
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "go2001_proto.h"
> +
> +struct go2001_msg {
> + struct list_head list_entry;
> + struct go2001_msg_payload payload;
> +};
> +
> +static inline struct go2001_msg_hdr *msg_to_hdr(struct go2001_msg
> *msg)
> +{
> + return &ms

Dear Talented

[Blue Sky Studio]

Dear Talented,

I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue Sky Studio a Film 
Corporation Located in the United State, is Soliciting for the Right to use 
Your Photo/Face and Personality as One of the Semi -Major Role/ Character in 
our Upcoming ANIMATED Stereoscope 3D Movie-The Story of Anubis (Anubis 2018) 
The Movie is Currently Filming (In Production) Please Note That There Will Be 
No Auditions, Traveling or Any Special / Professional Acting Skills, Since the 
Production of This Movie Will Be Done with our State of Art Computer 
-Generating Imagery Equipment. We Are Prepared to Pay the Total Sum of 
$620,000.00 USD.For More Information/Understanding.

Talent Scout
Kim Sharma

Quick Loans

[Sec Capital Loans]

Loan Offer at 3%, Feel Free to REPLY back to us for more info.

[PATCH v3] [media] v4l2: Add support for go2001 PCI codec driver

[Thierry Escande]

This patch adds support for the go2001 PCI codec driver. This hardware
is present on ChromeOS based devices like the Acer ChromeBox and Acer/LG
ChromeBase 24 devices. This chipset comes on a mini PCI-E card with
Google as PCI vendor ID (0x1ae0).

This driver comes from the ChromeOS v3.18 kernel tree and has been
modified to support vb2_buffer restructuring introduced in Linux v4.4.

The go2001 firmware files can be found in the build tree of the Google
Chromium OS open source project.

This driver is originally developed by:
 Pawel Osciak 
 Ville-Mikko Rautio 
 henryhsu 
 Wu-Cheng Li 

Signed-off-by: Thierry Escande 
---
 drivers/media/pci/Kconfig|2 +
 drivers/media/pci/Makefile   |1 +
 drivers/media/pci/go2001/Kconfig |   11 +
 drivers/media/pci/go2001/Makefile|2 +
 drivers/media/pci/go2001/go2001.h|  331 
 drivers/media/pci/go2001/go2001_driver.c | 2525 ++
 drivers/media/pci/go2001/go2001_hw.c | 1362 
 drivers/media/pci/go2001/go2001_hw.h |   55 +
 drivers/media/pci/go2001/go2001_proto.h  |  359 +
 9 files changed, 4648 insertions(+)
 create mode 100644 drivers/media/pci/go2001/Kconfig
 create mode 100644 drivers/media/pci/go2001/Makefile
 create mode 100644 drivers/media/pci/go2001/go2001.h
 create mode 100644 drivers/media/pci/go2001/go2001_driver.c
 create mode 100644 drivers/media/pci/go2001/go2001_hw.c
 create mode 100644 drivers/media/pci/go2001/go2001_hw.h
 create mode 100644 drivers/media/pci/go2001/go2001_proto.h

diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig
index da28e68..837681e 100644
--- a/drivers/media/pci/Kconfig
+++ b/drivers/media/pci/Kconfig
@@ -54,5 +54,7 @@ source "drivers/media/pci/smipcie/Kconfig"
 source "drivers/media/pci/netup_unidvb/Kconfig"
 endif
 
+source "drivers/media/pci/go2001/Kconfig"
+
 endif #MEDIA_PCI_SUPPORT
 endif #PCI
diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile
index a7e8af0..58639b7 100644
--- a/drivers/media/pci/Makefile
+++ b/drivers/media/pci/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_STA2X11_VIP) += sta2x11/
 obj-$(CONFIG_VIDEO_SOLO6X10) += solo6x10/
 obj-$(CONFIG_VIDEO_COBALT) += cobalt/
 obj-$(CONFIG_VIDEO_TW5864) += tw5864/
+obj-$(CONFIG_VIDEO_GO2001) += go2001/
diff --git a/drivers/media/pci/go2001/Kconfig b/drivers/media/pci/go2001/Kconfig
new file mode 100644
index 000..c7b5149
--- /dev/null
+++ b/drivers/media/pci/go2001/Kconfig
@@ -0,0 +1,11 @@
+config VIDEO_GO2001
+   tristate "GO2001 codec driver"
+   depends on VIDEO_V4L2 && PCI
+   select VIDEOBUF2_DMA_SG
+   ---help---
+ This driver supports the GO2001 PCI hardware codec. This codec
+ is present on ChromeOS based devices like the Acer ChromeBox
+ and ChromeBase 24 and LG ChromeBase as well.
+
+ To compile this driver as a module, choose M here: the
+ module will be called go2001.
diff --git a/drivers/media/pci/go2001/Makefile 
b/drivers/media/pci/go2001/Makefile
new file mode 100644
index 000..20bad18
--- /dev/null
+++ b/drivers/media/pci/go2001/Makefile
@@ -0,0 +1,2 @@
+go2001-objs:= go2001_driver.o go2001_hw.o
+obj-$(CONFIG_VIDEO_GO2001) += go2001.o
diff --git a/drivers/media/pci/go2001/go2001.h 
b/drivers/media/pci/go2001/go2001.h
new file mode 100644
index 000..0e5ccfd
--- /dev/null
+++ b/drivers/media/pci/go2001/go2001.h
@@ -0,0 +1,331 @@
+/*
+ *  go2001 - GO2001 codec driver.
+ *
+ *  Author : Pawel Osciak 
+ *
+ *  Copyright (C) 2017 Google, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program.  If not, see .
+ */
+#ifndef _MEDIA_PCI_GO2001_GO2001_H_
+#define _MEDIA_PCI_GO2001_GO2001_H_
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "go2001_proto.h"
+
+struct go2001_msg {
+   struct list_head list_entry;
+   struct go2001_msg_payload payload;
+};
+
+static inline struct go2001_msg_hdr *msg_to_hdr(struct go2001_msg *msg)
+{
+   return &msg->payload.hdr;
+}
+
+static inline void *msg_to_param(struct go2001_msg *msg)
+{
+   return msg->payload.param;
+}
+
+struct go2001_msg_ring {
+   struct go2001_msg_ring_desc desc;
+   void __iomem *desc_iomem;
+   void __iomem *data_iomem;
+   spinlock_t lock;
+};
+
+struct go2001_hw_inst {
+   struct list_head 

[PATCH v3] go2001 hardware codec support

[Thierry Escande]

Hi,

This patch introduces the go2001 hardware codec driver.

Changes in v3:
- Replace crop iotcl with selection ones
- Use video dev device_caps field
- Return v4l2_ctrl_subscribe_event() for default case
- Fix start_streaming error handling
- Remove empty ctrl ops callbacks
- Avoid use of private ctrl structures
- Remove VB2_USERPTR support
- Remove format description strings

Changes in v2:
- Remove unneeded call to dma_cache_sync() on coherent dma buffer.

Following are the results of v4l2-compliance utility execution for both
/dev/video0 and /dev/video1 devices.

Note that the failing tests are due to un-initialized internal
structures of the driver not done through these unit tests.

$ ./utils/v4l2-compliance/v4l2-compliance -d /dev/video0
v4l2-compliance SHA   : 1ae9a7adea3766879935dfede90d5aefd954c786

Driver Info:
Driver name   : go2001
Card type : GO2001 PCIe codec
Bus info  : PCI::03:00.0
Driver version: 4.12.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

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

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

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

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 2 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
fail: v4l2-test-formats.cpp(590): Video Capture Multiplanar cap 
set, but no Video Capture Multiplanar formats defined
test VIDIOC_G_FMT: FAIL
test VIDIOC_TRY_FMT: OK (Not Supported)
test VIDIOC_S_FMT: OK (Not Supported)
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
fail: v4l2-test-formats.cpp(1670): doioctl(node, VIDIOC_G_FMT, 
&fmt)
test Scaling: FAIL

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
fail: v4l2-test-buffers.cpp(574): VIDIOC_EXPBUF is supported, 
but the V4L2_MEMORY_MMAP support is missing, probably due to earlier failing 
format tests.
test VIDIOC_EXPBUF: OK (Not Supported)

Test input 0:

Total: 43, Succeeded: 41, Failed: 2, Warnings: 0

$ ./utils/v4l2-compliance/v4l2-compliance -d /dev/video1
v4l2-compliance SHA   : 1ae9a7adea3766879935dfede90d5aefd954c786

Driver Info:
Driver name   : go2001
Card type : GO2001 PCIe codec
Bus info  : PCI::03:00.0
Driver version: 4.12.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory 

Re: [PATCH RESEND 00/14] ddbridge: bump to ddbridge-0.9.29

[Daniel Scheller]

Am Tue, 25 Jul 2017 07:36:12 +0200
schrieb Philipp Hahn :

> > Stripped functionality compared to dddvb:
> > 
> >  - DVB-C modulator card support removed (requires DVB core API)  
> 
> Since I'm in DVB-C land, what is required to get that working as well?
> I only know myself around in general Linux Kernel land and I'm not a
> DVB expert, but if there is anything I can help with, please send me
> a note. (I only have one ddbridge system, which is running my
> "production" MythTV system, so testing is limited to the times were
> my house does not need it).

When speaking of MythTV and "regular" tuner cards, there's nothing you
need to do in this regard, DVB-C/C2/T/T2 tunercard support for all
currently available DD hardware is done already and merged into
linux-media. With modulator cards, these ([1]) are meant, used to set
up private cable networks, fed by ie. streams received via DVB-S.

[1] https://digitaldevices.de/produkte/modulatoren/

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

[PATCH] media: v4l: use WARN_ON(1) instead of __WARN()

[Arnd Bergmann]

__WARN() cannot be used in portable code, since it is only
available on some architectures and configurations:

drivers/media/platform/pxa_camera.c: In function 'pxa_mbus_config_compatible':
drivers/media/platform/pxa_camera.c:642:3: error: implicit declaration of 
function '__WARN'; did you mean '__WALL'? 
[-Werror=implicit-function-declaration]

The common way to express an unconditional warning is WARN_ON(1),
so let's use that here.

Fixes: 97bbdf02d905 ("media: v4l: Add support for CSI-1 and CCP2 busses")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/platform/pxa_camera.c  | 2 +-
 drivers/media/platform/soc_camera/soc_mediabus.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/pxa_camera.c 
b/drivers/media/platform/pxa_camera.c
index 3898a5cd8664..0d4af6d91ffc 100644
--- a/drivers/media/platform/pxa_camera.c
+++ b/drivers/media/platform/pxa_camera.c
@@ -639,7 +639,7 @@ static unsigned int pxa_mbus_config_compatible(const struct 
v4l2_mbus_config *cf
 V4L2_MBUS_CSI2_CONTINUOUS_CLOCK);
return (!mipi_lanes || !mipi_clock) ? 0 : common_flags;
default:
-   __WARN();
+   WARN_ON(1);
return -EINVAL;
}
return 0;
diff --git a/drivers/media/platform/soc_camera/soc_mediabus.c 
b/drivers/media/platform/soc_camera/soc_mediabus.c
index 43192d80beef..0ad4b28266e4 100644
--- a/drivers/media/platform/soc_camera/soc_mediabus.c
+++ b/drivers/media/platform/soc_camera/soc_mediabus.c
@@ -509,7 +509,7 @@ unsigned int soc_mbus_config_compatible(const struct 
v4l2_mbus_config *cfg,
 V4L2_MBUS_CSI2_CONTINUOUS_CLOCK);
return (!mipi_lanes || !mipi_clock) ? 0 : common_flags;
default:
-   __WARN();
+   WARN_ON(1);
return -EINVAL;
}
return 0;
-- 
2.9.0

[PATCH] media: i2c: add KConfig dependencies

[Arnd Bergmann]

The new ov5670 driver fails to build when VIDEO_V4L2_SUBDEV_API
or MEDIA_CONTROLLER are disabled:

drivers/media/i2c/ov5670.c: In function 'ov5670_open':
drivers/media/i2c/ov5670.c:1917:5: error: implicit declaration of function 
'v4l2_subdev_get_try_format'; did you mean 'v4l2_subdev_notify_event'? 
[-Werror=implicit-function-declaration]
 v4l2_subdev_get_try_format(sd, fh->pad, 0);
 ^~
 v4l2_subdev_notify_event
drivers/media/i2c/ov5670.c:1917:38: error: 'struct v4l2_subdev_fh' has no 
member named 'pad'
 v4l2_subdev_get_try_format(sd, fh->pad, 0);
  ^~
drivers/media/i2c/ov5670.c: In function 'ov5670_do_get_pad_format':
drivers/media/i2c/ov5670.c:2198:17: error: invalid type argument of unary '*' 
(have 'int')
   fmt->format = *v4l2_subdev_get_try_format(&ov5670->sd, cfg,
 ^
  fmt->pad);
  ~
drivers/media/i2c/ov5670.c: At top level:
drivers/media/i2c/ov5670.c:2444:19: error: 'v4l2_subdev_link_validate' 
undeclared here (not in a function); did you mean 'v4l2_subdev_init'?
  .link_validate = v4l2_subdev_link_validate,
   ^
   v4l2_subdev_init
drivers/media/i2c/ov5670.c: In function 'ov5670_probe':
drivers/media/i2c/ov5670.c:2492:12: error: 'struct v4l2_subdev' has no member 
named 'entity'

This adds both to the Kconfig entry.

Fixes: 5de35c9b8dcd ("media: i2c: Add Omnivision OV5670 5M sensor support")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/i2c/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index a05e40ecba7c..94153895fcd4 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -618,8 +618,9 @@ config VIDEO_OV6650
 
 config VIDEO_OV5670
tristate "OmniVision OV5670 sensor support"
-   depends on I2C && VIDEO_V4L2
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
+   depends on MEDIA_CONTROLLER
select V4L2_FWNODE
---help---
  This is a Video4Linux2 sensor-level driver for the OmniVision
-- 
2.9.0

Re: [PATCH v3 17/23] camss: vfe: Add interface for scaling

[Todor Tomov]

Hi Sakari,

Thank you for review.

On 20.07.2017 18:20, Sakari Ailus wrote:
> Hi Todor,
> 
> On Mon, Jul 17, 2017 at 01:33:43PM +0300, Todor Tomov wrote:
>> Add compose selection ioctls to handle scaling configuration.
>>
>> Signed-off-by: Todor Tomov 
>> ---
>>  drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 189 
>> -
>>  drivers/media/platform/qcom/camss-8x16/camss-vfe.h |   1 +
>>  2 files changed, 188 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c 
>> b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
>> index 327f158..8ec6ce7 100644
>> --- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
>> +++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
>> @@ -211,6 +211,8 @@
>>  #define CAMIF_TIMEOUT_SLEEP_US 1000
>>  #define CAMIF_TIMEOUT_ALL_US 100
>>  
>> +#define SCALER_RATIO_MAX 16
>> +
>>  static const u32 vfe_formats[] = {
>>  MEDIA_BUS_FMT_UYVY8_2X8,
>>  MEDIA_BUS_FMT_VYUY8_2X8,
>> @@ -1905,6 +1907,25 @@ __vfe_get_format(struct vfe_line *line,
>>  return &line->fmt[pad];
>>  }
>>  
>> +/*
>> + * __vfe_get_compose - Get pointer to compose selection structure
>> + * @line: VFE line
>> + * @cfg: V4L2 subdev pad configuration
>> + * @which: TRY or ACTIVE format
>> + *
>> + * Return pointer to TRY or ACTIVE compose rectangle structure
>> + */
>> +static struct v4l2_rect *
>> +__vfe_get_compose(struct vfe_line *line,
>> +  struct v4l2_subdev_pad_config *cfg,
>> +  enum v4l2_subdev_format_whence which)
>> +{
>> +if (which == V4L2_SUBDEV_FORMAT_TRY)
>> +return v4l2_subdev_get_try_compose(&line->subdev, cfg,
>> +   MSM_VFE_PAD_SINK);
>> +
>> +return &line->compose;
>> +}
>>  
>>  /*
>>   * vfe_try_format - Handle try format by pad subdev method
>> @@ -1951,7 +1972,14 @@ static void vfe_try_format(struct vfe_line *line,
>>  *fmt = *__vfe_get_format(line, cfg, MSM_VFE_PAD_SINK,
>>   which);
>>  
>> -if (line->id == VFE_LINE_PIX)
>> +if (line->id == VFE_LINE_PIX) {
>> +struct v4l2_rect *rect;
>> +
>> +rect = __vfe_get_compose(line, cfg, which);
>> +
>> +fmt->width = rect->width;
>> +fmt->height = rect->height;
>> +
>>  switch (fmt->code) {
>>  case MEDIA_BUS_FMT_YUYV8_2X8:
>>  if (code == MEDIA_BUS_FMT_YUYV8_1_5X8)
>> @@ -1979,6 +2007,7 @@ static void vfe_try_format(struct vfe_line *line,
>>  fmt->code = MEDIA_BUS_FMT_VYUY8_2X8;
>>  break;
>>  }
>> +}
>>  
>>  break;
>>  }
>> @@ -1987,6 +2016,50 @@ static void vfe_try_format(struct vfe_line *line,
>>  }
>>  
>>  /*
>> + * vfe_try_compose - Handle try compose selection by pad subdev method
>> + * @line: VFE line
>> + * @cfg: V4L2 subdev pad configuration
>> + * @rect: pointer to v4l2 rect structure
>> + * @which: wanted subdev format
>> + */
>> +static void vfe_try_compose(struct vfe_line *line,
>> +struct v4l2_subdev_pad_config *cfg,
>> +struct v4l2_rect *rect,
>> +enum v4l2_subdev_format_whence which)
>> +{
>> +struct v4l2_mbus_framefmt *fmt;
>> +
>> +rect->width = rect->width - rect->left;
>> +rect->left = 0;
> 
> This is the compose rectangle i.e. left and top should be zero (unless it's
> about composing on e.g. a frame buffer). No need to decrement from width;
> similarly for height below.

Yes, it is not composing, but does the user know that? If left and top are
set, it makes sense to keep the rectangle size unchanged I think - actually
decrement width and height (and then clear left and top).

> 
>> +rect->height = rect->height - rect->top;
>> +rect->top = 0;
>> +
>> +fmt = __vfe_get_format(line, cfg, MSM_VFE_PAD_SINK, which);
>> +
>> +if (rect->width > fmt->width)
>> +rect->width = fmt->width;
>> +
>> +if (rect->height > fmt->height)
>> +rect->height = fmt->height;
>> +
>> +if (fmt->width > rect->width * SCALER_RATIO_MAX)
>> +rect->width = (fmt->width + SCALER_RATIO_MAX - 1) /
>> +SCALER_RATIO_MAX;
>> +
>> +rect->width &= ~0x1;
>> +
>> +if (fmt->height > rect->height * SCALER_RATIO_MAX)
>> +rect->height = (fmt->height + SCALER_RATIO_MAX - 1) /
>> +SCALER_RATIO_MAX;
>> +
>> +if (rect->width < 16)
>> +rect->width = 16;
>> +
>> +if (rect->height < 4)
>> +rect->height = 4;
>> +}
>> +



-- 
Best regards,
Todor Tomov

Re: [PATCH v3 10/23] media: camss: Add VFE files

[Todor Tomov]

Hi Sakari,

Thank you for the review.

On 20.07.2017 17:59, Sakari Ailus wrote:
> Hi Todor,
> 
> On Mon, Jul 17, 2017 at 01:33:36PM +0300, Todor Tomov wrote:
>> These files control the VFE module. The VFE has different input interfaces.
>> The PIX input interface feeds the input data to an image processing pipeline.
>> Three RDI input interfaces bypass the image processing pipeline. The VFE also
>> contains the AXI bus interface which writes the output data to memory.
>>
>> RDI interfaces are supported in this version. PIX interface is not supported.
>>
>> Signed-off-by: Todor Tomov 
>> ---
>>  drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 1913 
>> 
>>  drivers/media/platform/qcom/camss-8x16/camss-vfe.h |  114 ++
>>  2 files changed, 2027 insertions(+)
>>  create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-vfe.c
>>  create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-vfe.h
>>
>> diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c 
>> b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
>> new file mode 100644
>> index 000..b6dd29b
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
>> @@ -0,0 +1,1913 @@



>> +
>> +static void vfe_set_qos(struct vfe_device *vfe)
>> +{
>> +u32 val = 0xaaa5aaa5;
>> +u32 val7 = 0x0001aaa5;
> 
> Huh. What do these mean? :-)

For these here I don't have understanding of the values. I'll remove the magic
values here and on all the other places but these here I'll just move to a 
#define.

> 
>> +
>> +writel_relaxed(val, vfe->base + VFE_0_BUS_BDG_QOS_CFG_0);
>> +writel_relaxed(val, vfe->base + VFE_0_BUS_BDG_QOS_CFG_1);
>> +writel_relaxed(val, vfe->base + VFE_0_BUS_BDG_QOS_CFG_2);
>> +writel_relaxed(val, vfe->base + VFE_0_BUS_BDG_QOS_CFG_3);
>> +writel_relaxed(val, vfe->base + VFE_0_BUS_BDG_QOS_CFG_4);
>> +writel_relaxed(val, vfe->base + VFE_0_BUS_BDG_QOS_CFG_5);
>> +writel_relaxed(val, vfe->base + VFE_0_BUS_BDG_QOS_CFG_6);
>> +writel_relaxed(val7, vfe->base + VFE_0_BUS_BDG_QOS_CFG_7);
>> +}
>> +



>> +
>> +/*
>> + * msm_vfe_subdev_init - Initialize VFE device structure and resources
>> + * @vfe: VFE device
>> + * @res: VFE module resources table
>> + *
>> + * Return 0 on success or a negative error code otherwise
>> + */
>> +int msm_vfe_subdev_init(struct vfe_device *vfe, const struct resources *res)
>> +{
>> +struct device *dev = to_device(vfe);
>> +struct platform_device *pdev = to_platform_device(dev);
>> +struct resource *r;
>> +struct camss *camss = to_camss(vfe);
>> +
>> +int i;
>> +int ret;
>> +
>> +mutex_init(&vfe->power_lock);
>> +vfe->power_count = 0;
>> +
>> +mutex_init(&vfe->stream_lock);
>> +vfe->stream_count = 0;
>> +
>> +spin_lock_init(&vfe->output_lock);
>> +
>> +vfe->id = 0;
>> +vfe->reg_update = 0;
>> +
>> +for (i = VFE_LINE_RDI0; i <= VFE_LINE_RDI2; i++) {
>> +vfe->line[i].video_out.type =
>> +V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
>> +vfe->line[i].video_out.camss = camss;
>> +vfe->line[i].id = i;
>> +}
>> +
>> +/* Memory */
>> +
>> +r = platform_get_resource_byname(pdev, IORESOURCE_MEM, res->reg[0]);
>> +vfe->base = devm_ioremap_resource(dev, r);
>> +if (IS_ERR(vfe->base)) {
>> +dev_err(dev, "could not map memory\n");
> 
> mutex_destroy() for bothof the mutexes. The same below.
> 
> Do you have a corresponding cleanup function?

msm_vfe_subdev_init() and msm_vfe_register_entities() are called on probe().
msm_vfe_unregister_entities() is called on remove() - this is the cleanup
function. The mutexes are destroyed there. Is there something else that you
are concerned about?

> 
>> +return PTR_ERR(vfe->base);
>> +}
>> +
>> +/* Interrupt */
>> +
>> +r = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
>> + res->interrupt[0]);
>> +if (!r) {
>> +dev_err(dev, "missing IRQ\n");
>> +return -EINVAL;
>> +}
>> +
>> +vfe->irq = r->start;
>> +snprintf(vfe->irq_name, sizeof(vfe->irq_name), "%s_%s%d",
>> + dev_name(dev), MSM_VFE_NAME, vfe->id);
>> +ret = devm_request_irq(dev, vfe->irq, vfe_isr,
>> +   IRQF_TRIGGER_RISING, vfe->irq_name, vfe);
>> +if (ret < 0) {
>> +dev_err(dev, "request_irq failed: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +/* Clocks */
>> +
>> +vfe->nclocks = 0;
>> +while (res->clock[vfe->nclocks])
>> +vfe->nclocks++;
>> +
>> +vfe->clock = devm_kzalloc(dev, vfe->nclocks * sizeof(*vfe->clock),
>> +  GFP_KERNEL);
>> +if (!vfe->clock)
>> +return -ENOMEM;
>> +
>> +for (i = 0; i < vfe->nclocks; i++) {
>> +vfe->clock[i] = devm_clk_get(dev, res->clock[i]);
>> +if (IS_ERR(vfe->clock[i]))
>> +   

Re: [PATCH v2 1/2] platform: Add Amlogic Meson AO CEC Controller driver

[Hans Verkuil]

On 07/25/17 14:34, Neil Armstrong wrote:
> Hi Hans,

>>> +static int meson_ao_cec_probe(struct platform_device *pdev)
>>> +{
>>> +   struct meson_ao_cec_device *ao_cec;
>>> +   struct platform_device *hdmi_dev;
>>> +   struct device_node *np;
>>> +   struct resource *res;
>>> +   int ret, irq;
>>> +
>>> +   np = of_parse_phandle(pdev->dev.of_node, "hdmi-phandle", 0);
>>> +   if (!np) {
>>> +   dev_err(&pdev->dev, "Failed to find hdmi node\n");
>>> +   return -ENODEV;
>>> +   }
>>> +
>>> +   hdmi_dev = of_find_device_by_node(np);
>>> +   if (hdmi_dev == NULL)
>>> +   return -EPROBE_DEFER;
>>> +
>>> +   ao_cec = devm_kzalloc(&pdev->dev, sizeof(*ao_cec), GFP_KERNEL);
>>> +   if (!ao_cec)
>>> +   return -ENOMEM;
>>> +
>>> +   spin_lock_init(&ao_cec->cec_reg_lock);
>>> +
>>> +   ao_cec->notify = cec_notifier_get(&hdmi_dev->dev);
>>> +   if (!ao_cec->notify)
>>> +   return -ENOMEM;
>>> +
>>> +   ao_cec->adap = cec_allocate_adapter(&meson_ao_cec_ops, ao_cec,
>>> +   "meson_ao_cec",
>>> +   CEC_CAP_LOG_ADDRS |
>>> +   CEC_CAP_TRANSMIT |
>>> +   CEC_CAP_RC |
>>> +   CEC_CAP_PASSTHROUGH,
>>> +   1); /* Use 1 for now */
>>
>> I recommend that you add support for 2 logical addresses. More isn't allowed
>> by the CEC 2.0 spec anyway (no such restriction for CEC 1.4, but more than
>> two really isn't needed).
> 
> I know, but in the "communication" register with the suspend/poweroff firmware
> that  handles the wake up, only a single logical address is supported...
> 
> What should I do in this case ? Which logical adress should I pass to the 
> firmware when implementing ir ?

Ah, OK. Interesting.

>From cec-adap.c:

if (log_addrs->num_log_addrs == 2) {
if (!(type_mask & ((1 << CEC_LOG_ADDR_TYPE_AUDIOSYSTEM) 
|
   (1 << CEC_LOG_ADDR_TYPE_TV {
dprintk(1, "two LAs is only allowed for 
audiosystem and TV\n");
return -EINVAL;
}
if (!(type_mask & ((1 << CEC_LOG_ADDR_TYPE_PLAYBACK) |
   (1 << CEC_LOG_ADDR_TYPE_RECORD {
dprintk(1, "an audiosystem/TV can only be 
combined with record or playback\n");
return -EINVAL;
}
}

So you would store the TV or AUDIOSYSTEM logical address in the firmware, since 
those
describe the system best.

I.e. it is a TV/Audiosystem with recording/playback capabilities.

The problem is that for CEC 1.4 no such restriction is imposed (the test above 
is
specific to CEC 2.0). But I think it makes sense to just check if TV/Audiosystem
is selected and pick that as the LA to store in the firmware, and otherwise just
pick the first LA (log_addr[0]).

Regards,

Hans

[PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

[Christian König]

From: Christian König 

With hardware resets in mind it is possible that all shared fences are
signaled, but the exlusive isn't. Fix waiting for everything in this situation.

v2: make sure we always wait for the exclusive fence

Signed-off-by: Christian König 
---
 drivers/dma-buf/reservation.c | 33 +++--
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 393817e..9d4316d 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -373,12 +373,25 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
long ret = timeout ? timeout : 1;
 
 retry:
-   fence = NULL;
shared_count = 0;
seq = read_seqcount_begin(&obj->seq);
rcu_read_lock();
 
-   if (wait_all) {
+   fence = rcu_dereference(obj->fence_excl);
+   if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
+   if (!dma_fence_get_rcu(fence))
+   goto unlock_retry;
+
+   if (dma_fence_is_signaled(fence)) {
+   dma_fence_put(fence);
+   fence = NULL;
+   }
+
+   } else {
+   fence = NULL;
+   }
+
+   if (!fence && wait_all) {
struct reservation_object_list *fobj =
rcu_dereference(obj->fence);
 
@@ -405,22 +418,6 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
}
}
 
-   if (!shared_count) {
-   struct dma_fence *fence_excl = rcu_dereference(obj->fence_excl);
-
-   if (fence_excl &&
-   !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
- &fence_excl->flags)) {
-   if (!dma_fence_get_rcu(fence_excl))
-   goto unlock_retry;
-
-   if (dma_fence_is_signaled(fence_excl))
-   dma_fence_put(fence_excl);
-   else
-   fence = fence_excl;
-   }
-   }
-
rcu_read_unlock();
if (fence) {
if (read_seqcount_retry(&obj->seq, seq)) {
-- 
2.7.4

Re: [PATCH v4] uvcvideo: add a metadata device node

[Guennadi Liakhovetski]

Hi Laurent,

Thanks for your comments!

On Fri, 21 Jul 2017, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> Thank you for the patch.
> 
> > Some UVC video cameras contain metadata in their payload headers. This
> > patch extracts that data, adding more clock synchronisation information,
> > on both bulk and isochronous endpoints and makes it available to the
> > user space on a separate video node, using the V4L2_CAP_META_CAPTURE
> > capability and the V4L2_BUF_TYPE_META_CAPTURE buffer queue type. Even
> > though different cameras will have different metadata formats, we use
> > the same V4L2_META_FMT_UVC pixel format for all of them. Users have to
> > parse data, based on the specific camera model information.
> 
> The issue we still haven't addressed is how to ensure that vendors will
> document their metadata format :-S

Uhm, add a black list of offending vendors and drop 60% of their frames? 
;-)

> > This version of the patch only creates such metadata nodes for cameras,
> > specifying a UVC_QUIRK_METADATA_NODE quirk flag.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> > 
> > v4:
> > - add support for isochronous cameras. Metadata is now collected from as 
> > many payloads as they fit in the buffer
> > - add a USB Start Of Frame and a system timestamp to each metadata block 
> > for user-space clock synchronisation
> > - use a default buffer size of 1024 bytes
> > 
> > Thanks to Laurent for patient long discussions and to everybody, who 
> > helped me conduct all the investigation into various past, present and 
> > future UVC cameras :-)
> > 
> >  drivers/media/usb/uvc/Makefile   |   2 +-
> >  drivers/media/usb/uvc/uvc_driver.c   |   4 +
> >  drivers/media/usb/uvc/uvc_isight.c   |   2 +-
> >  drivers/media/usb/uvc/uvc_metadata.c | 158 +++
> >  drivers/media/usb/uvc/uvc_queue.c|  68 ++-
> >  drivers/media/usb/uvc/uvc_video.c| 101 +++---
> >  drivers/media/usb/uvc/uvcvideo.h |  23 -
> >  drivers/media/v4l2-core/v4l2-ioctl.c |   1 +
> >  include/uapi/linux/uvcvideo.h|  19 +
> >  include/uapi/linux/videodev2.h   |   3 +
> >  10 files changed, 347 insertions(+), 34 deletions(-)
> >  create mode 100644 drivers/media/usb/uvc/uvc_metadata.c
> 
> [snip]
> 
> > diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > b/drivers/media/usb/uvc/uvc_driver.c
> > index 70842c5..9f23dcf 100644
> > --- a/drivers/media/usb/uvc/uvc_driver.c
> > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > @@ -1880,6 +1880,7 @@ static void uvc_unregister_video(struct uvc_device
> > *dev)
> > continue;
> >  
> > video_unregister_device(&stream->vdev);
> > +   video_unregister_device(&stream->meta.vdev);
> >  
> > uvc_debugfs_cleanup_stream(stream);
> > }
> > @@ -1941,6 +1942,9 @@ static int uvc_register_video(struct uvc_device *dev,
> > return ret;
> > }
> >  
> > +   /* Register a metadata node. */
> > +   uvc_meta_register(stream);
> 
> This can fail, you should handle errors.

Yes, this is in a way deliberate. If metadata node registration fails, the 
driver continues without one. Would you prefer to fail and unregister the 
main node in this case?

> > if (stream->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> > stream->chain->caps |= V4L2_CAP_VIDEO_CAPTURE;
> > else
> 
> [snip]
> 
> > diff --git a/drivers/media/usb/uvc/uvc_metadata.c 
> b/drivers/media/usb/uvc/uvc_metadata.c
> > new file mode 100644
> > index 000..876badd
> > --- /dev/null
> > +++ b/drivers/media/usb/uvc/uvc_metadata.c
> > @@ -0,0 +1,158 @@
> > +/*
> > + *  uvc_metadata.c  --  USB Video Class driver - Metadata handling
> > + *
> > + *  Copyright (C) 2016
> > + *  Guennadi Liakhovetski (guennadi.liakhovet...@intel.com)
> > + *
> > + *  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 "uvcvideo.h"
> > +
> > +/* ---
> > + * videobuf2 Queue Operations
> > + */
> > +
> > +static struct vb2_ops uvc_meta_queue_ops = {
> > +   .queue_setup = uvc_queue_setup,
> > +   .buf_prepare = uvc_buffer_prepare,
> > +   .buf_queue = uvc_buffer_queue,
> > +   .wait_prepare = vb2_ops_wait_prepare,
> > +   .wait_finish = vb2_ops_wait_finish,
> > +   .stop_streaming = uvc_stop_streaming,
> 
> This looks unbalanced without a start_streaming operation. I know that
> you've modified the uvc_stop_streaming() function to not stop the video
> stream for metadata video nodes, but I think the code would be clearer
> if you implemented a uvc

Re: [PATCH v2 1/2] platform: Add Amlogic Meson AO CEC Controller driver

[Neil Armstrong]

Hi Hans,

On 07/17/2017 10:01 AM, Hans Verkuil wrote:
> On 10/07/17 10:01, Neil Armstrong wrote:
>> The Amlogic SoC embeds a standalone CEC controller, this patch adds a driver
>> for such controller.
>> The controller does not need HPD to be active, and could support up to max
>> 5 logical addresses, but only 1 is handled since the Suspend firmware can
>> make use of this unique logical address to wake up the device.
>>
>> The Suspend firmware configuration will be added in an other patchset.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/media/platform/Kconfig|  11 +
>>  drivers/media/platform/Makefile   |   2 +
>>  drivers/media/platform/meson/Makefile |   1 +
>>  drivers/media/platform/meson/ao-cec.c | 781 
>> ++
>>  4 files changed, 795 insertions(+)
>>  create mode 100644 drivers/media/platform/meson/Makefile
>>  create mode 100644 drivers/media/platform/meson/ao-cec.c
>>
>> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
>> index 1313cd5..1e67381 100644
>> --- a/drivers/media/platform/Kconfig
>> +++ b/drivers/media/platform/Kconfig
>> @@ -536,6 +536,17 @@ menuconfig CEC_PLATFORM_DRIVERS
>>  
>>  if CEC_PLATFORM_DRIVERS
>>  
>> +config VIDEO_MESON_AO_CEC
>> +tristate "Amlogic Meson AO CEC driver"
>> +depends on ARCH_MESON || COMPILE_TEST
>> +select CEC_CORE
>> +select CEC_NOTIFIER
>> +---help---
>> +  This is a driver for Amlogic Meson SoCs AO CEC interface. It uses the
>> +  generic CEC framework interface.
>> +  CEC bus is present in the HDMI connector and enables communication
>> +  between compatible devices.
>> +
>>  config VIDEO_SAMSUNG_S5P_CEC
>> tristate "Samsung S5P CEC driver"
>> depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
>> diff --git a/drivers/media/platform/Makefile 
>> b/drivers/media/platform/Makefile
>> index 9beadc7..a52d7b6 100644
>> --- a/drivers/media/platform/Makefile
>> +++ b/drivers/media/platform/Makefile
>> @@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
>>  obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)   += mtk-jpeg/
>>  
>>  obj-$(CONFIG_VIDEO_QCOM_VENUS)  += qcom/venus/
>> +
>> +obj-y   += meson/
>> diff --git a/drivers/media/platform/meson/Makefile 
>> b/drivers/media/platform/meson/Makefile
>> new file mode 100644
>> index 000..597beb8
>> --- /dev/null
>> +++ b/drivers/media/platform/meson/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_VIDEO_MESON_AO_CEC)+= ao-cec.o
>> diff --git a/drivers/media/platform/meson/ao-cec.c 
>> b/drivers/media/platform/meson/ao-cec.c
>> new file mode 100644
>> index 000..cdc1f61
>> --- /dev/null
>> +++ b/drivers/media/platform/meson/ao-cec.c
>> @@ -0,0 +1,781 @@
>> +/*
>> + * Driver for Amlogic Meson AO CEC Controller
>> + *
>> + * Copyright (C) 2015 Amlogic, Inc. All rights reserved
>> + * Copyright (C) 2017 BayLibre, SAS
>> + * Author: Neil Armstrong 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* CEC Registers */
>> +
>> +/*
>> + * [2:1] cntl_clk
>> + *  - 0 = Disable clk (Power-off mode)
>> + *  - 1 = Enable gated clock (Normal mode)
>> + *  - 2 = Enable free-run clk (Debug mode)
>> + */
>> +#define CEC_GEN_CNTL_REG0x00
>> +
>> +#define CEC_GEN_CNTL_RESET  BIT(0)
>> +#define CEC_GEN_CNTL_CLK_DISABLE0
>> +#define CEC_GEN_CNTL_CLK_ENABLE 1
>> +#define CEC_GEN_CNTL_CLK_ENABLE_DBG 2
>> +#define CEC_GEN_CNTL_CLK_CTRL_MASK  GENMASK(2, 1)
>> +
>> +/*
>> + * [7:0] cec_reg_addr
>> + * [15:8] cec_reg_wrdata
>> + * [16] cec_reg_wr
>> + *  - 0 = Read
>> + *  - 1 = Write
>> + * [23] bus free
>> + * [31:24] cec_reg_rddata
>> + */
>> +#define CEC_RW_REG  0x04
>> +
>> +#define CEC_RW_ADDR GENMASK(7, 0)
>> +#define CEC_RW_WR_DATA  GENMASK(15, 8)
>> +#define CEC_RW_WRITE_EN BIT(16)
>> +#define CEC_RW_BUS_BUSY BIT(23)
>> +#define CEC_RW_RD_DATA  GENMASK(31, 24)
>> +
>> +/*
>> + * [1] tx intr
>> + * [2] rx intr
>> + */
>> +#define CEC_INTR_MASKN_REG  0x08
>> +#define CEC_INTR_CLR_REG0x0c
>> +#define CEC_INTR_STAT_REG   0x10
>> +
>> +#define CEC_INTR_TX BIT(1)
>> +#define CEC_INTR_RX BIT(2)
>> +
>> +/* CEC Commands */
>> +
>> +#define CEC_TX_MSG_0_HEADER 0x00
>> +#define CEC_TX_MSG_1_OPCODE 0x01
>> +#define CEC_TX_MSG_2_OP10x02
>> +#define CEC_TX_MSG_3_OP20x03
>> +#define CEC_TX_MSG_4_OP30x04
>> +#define CEC_TX_MSG_5_OP40x05
>> +#define CEC_TX_MSG_6_OP50x06
>> +#define CEC_TX_MSG_7_OP60x07
>> +#define CEC_TX_MSG_8_OP70x08
>> +

Re: [PATCH 1/2] staging: greybus: light: Don't leak memory for no gain

[Johan Hovold]

[ +CC: Rui and Greg ]

On Tue, Jul 18, 2017 at 09:41:06PM +0300, Sakari Ailus wrote:
> Memory for struct v4l2_flash_config is allocated in
> gb_lights_light_v4l2_register() for no gain and yet the allocated memory is
> leaked; the struct isn't used outside the function. Fix this.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/staging/greybus/light.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c
> index 129ceed39829..b25c117ec41a 100644
> --- a/drivers/staging/greybus/light.c
> +++ b/drivers/staging/greybus/light.c
> @@ -534,25 +534,21 @@ static int gb_lights_light_v4l2_register(struct 
> gb_light *light)
>  {
>   struct gb_connection *connection = get_conn_from_light(light);
>   struct device *dev = &connection->bundle->dev;
> - struct v4l2_flash_config *sd_cfg;
> + struct v4l2_flash_config sd_cfg = { 0 };
>   struct led_classdev_flash *fled;
>   struct led_classdev *iled = NULL;
>   struct gb_channel *channel_torch, *channel_ind, *channel_flash;
>   int ret = 0;
>  
> - sd_cfg = kcalloc(1, sizeof(*sd_cfg), GFP_KERNEL);
> - if (!sd_cfg)
> - return -ENOMEM;
> -
>   channel_torch = get_channel_from_mode(light, GB_CHANNEL_MODE_TORCH);
>   if (channel_torch)
>   __gb_lights_channel_v4l2_config(&channel_torch->intensity_uA,
> - &sd_cfg->torch_intensity);
> + &sd_cfg.torch_intensity);
>  
>   channel_ind = get_channel_from_mode(light, GB_CHANNEL_MODE_INDICATOR);
>   if (channel_ind) {
>   __gb_lights_channel_v4l2_config(&channel_ind->intensity_uA,
> - &sd_cfg->indicator_intensity);
> + &sd_cfg.indicator_intensity);
>   iled = &channel_ind->fled.led_cdev;
>   }
>  
> @@ -561,17 +557,17 @@ static int gb_lights_light_v4l2_register(struct 
> gb_light *light)
>  
>   fled = &channel_flash->fled;
>  
> - snprintf(sd_cfg->dev_name, sizeof(sd_cfg->dev_name), "%s", light->name);
> + snprintf(sd_cfg.dev_name, sizeof(sd_cfg.dev_name), "%s", light->name);
>  
>   /* Set the possible values to faults, in our case all faults */
> - sd_cfg->flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
> + sd_cfg.flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
>   LED_FAULT_OVER_TEMPERATURE | LED_FAULT_SHORT_CIRCUIT |
>   LED_FAULT_OVER_CURRENT | LED_FAULT_INDICATOR |
>   LED_FAULT_UNDER_VOLTAGE | LED_FAULT_INPUT_VOLTAGE |
>   LED_FAULT_LED_OVER_TEMPERATURE;
>  
>   light->v4l2_flash = v4l2_flash_init(dev, NULL, fled, iled,
> - &v4l2_flash_ops, sd_cfg);
> + &v4l2_flash_ops, &sd_cfg);
>   if (IS_ERR_OR_NULL(light->v4l2_flash)) {
>   ret = PTR_ERR(light->v4l2_flash);
>   goto out_free;
> @@ -580,7 +576,6 @@ static int gb_lights_light_v4l2_register(struct gb_light 
> *light)
>   return ret;
>  
>  out_free:
> - kfree(sd_cfg);

This looks a bit lazy, even if I just noticed that you repurpose this
error label (without renaming it) in you second patch.


>   return ret;
>  }

And while it's fine to take this through linux-media, it would still be
good to keep the maintainers on CC.

Thanks,
Johan

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly

[Daniel Vetter]

On Tue, Jul 25, 2017 at 11:11:35AM +0200, Christian König wrote:
> Am 24.07.2017 um 13:57 schrieb Daniel Vetter:
> > On Mon, Jul 24, 2017 at 11:51 AM, Christian König
> >  wrote:
> > > Am 24.07.2017 um 10:33 schrieb Daniel Vetter:
> > > > On Fri, Jul 21, 2017 at 06:20:01PM +0200, Christian König wrote:
> > > > > From: Christian König 
> > > > > 
> > > > > With hardware resets in mind it is possible that all shared fences are
> > > > > signaled, but the exlusive isn't. Fix waiting for everything in this
> > > > > situation.
> > > > How did you end up with both shared and exclusive fences on the same
> > > > reservation object? At least I thought the point of exclusive was that
> > > > it's exclusive (and has an implicit barrier on all previous shared
> > > > fences). Same for shared fences, they need to wait for the exclusive one
> > > > (and replace it).
> > > > 
> > > > Is this fallout from the amdgpu trickery where by default you do all
> > > > shared fences? I thought we've aligned semantics a while back ...
> > > 
> > > No, that is perfectly normal even for other drivers. Take a look at the
> > > reservation code.
> > > 
> > > The exclusive fence replaces all shared fences, but adding a shared fence
> > > doesn't replace the exclusive fence. That actually makes sense, cause when
> > > you want to add move shared fences those need to wait for the last 
> > > exclusive
> > > fence as well.
> > Hm right.
> > 
> > > Now normally I would agree that when you have shared fences it is 
> > > sufficient
> > > to wait for all of them cause those operations can't start before the
> > > exclusive one finishes. But with GPU reset and/or the ability to abort
> > > already submitted operations it is perfectly possible that you end up with
> > > an exclusive fence which isn't signaled and a shared fence which is 
> > > signaled
> > > in the same reservation object.
> > How does that work? The batch(es) with the shared fence are all
> > supposed to wait for the exclusive fence before they start, which
> > means even if you gpu reset and restart/cancel certain things, they
> > shouldn't be able to complete out of order.
> 
> Assume the following:
> 1. The exclusive fence is some move operation by the kernel which executes
> on a DMA engine.
> 2. The shared fence is a 3D operation submitted by userspace which executes
> on the 3D engine.
> 
> Now we found the 3D engine to be hung and needs a reset, all currently
> submitted jobs are aborted, marked with an error code and their fences put
> into the signaled state.
> 
> Since we only reset the 3D engine, the move operation (fortunately) isn't
> affected by this.
> 
> I think this applies to all drivers and isn't something amdgpu specific.

Not i915 because:
- At first we only had system wide gpu reset that killed everything, which
  means all requests will be completed, not just on a single engine.

- Now we have per-engine reset, but combined with replaying them (the
  offending one gets a no-op batch to avoid re-hanging), to make sure the
  depency tree doesn't fall apart.

Now I see that doing this isn't all that simple, and either way we still
have the case where one driver resets but not the other (in multi-gpu),
but I'm not exactly sure how to best handle this.

What exactly is the downside of not dropping this assumption, i.e. why do
you want this patch? What blows up?
-Daniel


> 
> Regards,
> Christian.
> 
> > 
> > If you outright cancel a fence then you're supposed to first call
> > dma_fence_set_error(-EIO) and then complete it. Note that atm that
> > part might be slightly overengineered and I'm not sure about how we
> > expose stuff to userspace, e.g. dma_fence_set_error(-EAGAIN) is (or
> > soon, has been) used by i915 for it's internal book-keeping, which
> > might not be the best to leak to other consumers. But completing
> > fences (at least exported ones, where userspace or other drivers can
> > get at them) shouldn't be possible.
> > -Daniel
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: linux and sony pregius cmos sensors

[Hans Verkuil]

On 07/25/17 10:36, Philippe De Muyter wrote:
> Hi all,
> 
> I currently investigate using sony pregius cmos sensor (imx264, e.g.)
> on a imx (tegra or imx6) board.  I see that many camera vendors already
> sell USB3 or IP cameras based on such chips, but is there support (or
> currently in development drivers) in linux kernel for those chips ?

Not in the mainline kernel. However, you might want to google this since
it may be supported by third-party (android) kernels.

Usually the code quality of those is awful, but it can be a starting point.

Regards,

Hans

> 
> IIRC, they don't have a MIPI-CSI2 interface but a LVDS interface.
> Fortunately there is ia chip from a FPGA vendor that can convert LVDS
> to MIPI-CSI2.
> 
> Any advice or info ?
> 
> TIA
> 
> Philippe
> 

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly

[Christian König]

Am 24.07.2017 um 13:57 schrieb Daniel Vetter:

On Mon, Jul 24, 2017 at 11:51 AM, Christian König
 wrote:

Am 24.07.2017 um 10:33 schrieb Daniel Vetter:

On Fri, Jul 21, 2017 at 06:20:01PM +0200, Christian König wrote:

From: Christian König 

With hardware resets in mind it is possible that all shared fences are
signaled, but the exlusive isn't. Fix waiting for everything in this
situation.

How did you end up with both shared and exclusive fences on the same
reservation object? At least I thought the point of exclusive was that
it's exclusive (and has an implicit barrier on all previous shared
fences). Same for shared fences, they need to wait for the exclusive one
(and replace it).

Is this fallout from the amdgpu trickery where by default you do all
shared fences? I thought we've aligned semantics a while back ...


No, that is perfectly normal even for other drivers. Take a look at the
reservation code.

The exclusive fence replaces all shared fences, but adding a shared fence
doesn't replace the exclusive fence. That actually makes sense, cause when
you want to add move shared fences those need to wait for the last exclusive
fence as well.

Hm right.


Now normally I would agree that when you have shared fences it is sufficient
to wait for all of them cause those operations can't start before the
exclusive one finishes. But with GPU reset and/or the ability to abort
already submitted operations it is perfectly possible that you end up with
an exclusive fence which isn't signaled and a shared fence which is signaled
in the same reservation object.

How does that work? The batch(es) with the shared fence are all
supposed to wait for the exclusive fence before they start, which
means even if you gpu reset and restart/cancel certain things, they
shouldn't be able to complete out of order.


Assume the following:
1. The exclusive fence is some move operation by the kernel which 
executes on a DMA engine.
2. The shared fence is a 3D operation submitted by userspace which 
executes on the 3D engine.


Now we found the 3D engine to be hung and needs a reset, all currently 
submitted jobs are aborted, marked with an error code and their fences 
put into the signaled state.


Since we only reset the 3D engine, the move operation (fortunately) 
isn't affected by this.


I think this applies to all drivers and isn't something amdgpu specific.

Regards,
Christian.



If you outright cancel a fence then you're supposed to first call
dma_fence_set_error(-EIO) and then complete it. Note that atm that
part might be slightly overengineered and I'm not sure about how we
expose stuff to userspace, e.g. dma_fence_set_error(-EAGAIN) is (or
soon, has been) used by i915 for it's internal book-keeping, which
might not be the best to leak to other consumers. But completing
fences (at least exported ones, where userspace or other drivers can
get at them) shouldn't be possible.
-Daniel

linux and sony pregius cmos sensors

[Philippe De Muyter]

Hi all,

I currently investigate using sony pregius cmos sensor (imx264, e.g.)
on a imx (tegra or imx6) board.  I see that many camera vendors already
sell USB3 or IP cameras based on such chips, but is there support (or
currently in development drivers) in linux kernel for those chips ?

IIRC, they don't have a MIPI-CSI2 interface but a LVDS interface.
Fortunately there is ia chip from a FPGA vendor that can convert LVDS
to MIPI-CSI2.

Any advice or info ?

TIA

Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly

[zhoucm1]

On 2017年07月25日 15:02, Daniel Vetter wrote:

On Tue, Jul 25, 2017 at 02:55:14PM +0800, zhoucm1 wrote:


On 2017年07月25日 14:50, Daniel Vetter wrote:

On Tue, Jul 25, 2017 at 02:16:55PM +0800, zhoucm1 wrote:

On 2017年07月24日 19:57, Daniel Vetter wrote:

On Mon, Jul 24, 2017 at 11:51 AM, Christian König
 wrote:

Am 24.07.2017 um 10:33 schrieb Daniel Vetter:

On Fri, Jul 21, 2017 at 06:20:01PM +0200, Christian König wrote:

From: Christian König 

With hardware resets in mind it is possible that all shared fences are
signaled, but the exlusive isn't. Fix waiting for everything in this
situation.

How did you end up with both shared and exclusive fences on the same
reservation object? At least I thought the point of exclusive was that
it's exclusive (and has an implicit barrier on all previous shared
fences). Same for shared fences, they need to wait for the exclusive one
(and replace it).

Is this fallout from the amdgpu trickery where by default you do all
shared fences? I thought we've aligned semantics a while back ...

No, that is perfectly normal even for other drivers. Take a look at the
reservation code.

The exclusive fence replaces all shared fences, but adding a shared fence
doesn't replace the exclusive fence. That actually makes sense, cause when
you want to add move shared fences those need to wait for the last exclusive
fence as well.

Hm right.


Now normally I would agree that when you have shared fences it is sufficient
to wait for all of them cause those operations can't start before the
exclusive one finishes. But with GPU reset and/or the ability to abort
already submitted operations it is perfectly possible that you end up with
an exclusive fence which isn't signaled and a shared fence which is signaled
in the same reservation object.

How does that work? The batch(es) with the shared fence are all
supposed to wait for the exclusive fence before they start, which
means even if you gpu reset and restart/cancel certain things, they
shouldn't be able to complete out of order.

Hi Daniel,

Do you mean exclusive fence must be signalled before any shared fence? Where
could I find this restriction?

Yes, Christian also described it above. Could be that we should have
better kerneldoc to document this ...

Is that a known assumption? if that way, it doesn't matter even that we
always wait exclusive fence, right? Just one more line checking.

The problem is that amdgpu breaks that assumption over gpu reset, and that
might have implications _everywhere_, not just in this code here. Are you
sure this case won't pull the i915 driver over the table when sharing
dma-bufs with it?
Ah, I finally got your mean. So as you mentioned before, we at least 
should have better describe for this assumption, the best place is 
comments in reservation.c, every newer would know it when reading code 
first time.


Thanks,
David Zhou

Did you audit the code (plus all the other drivers too
ofc).
-Daniel

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly

[Daniel Vetter]

On Tue, Jul 25, 2017 at 02:55:14PM +0800, zhoucm1 wrote:
> 
> 
> On 2017年07月25日 14:50, Daniel Vetter wrote:
> > On Tue, Jul 25, 2017 at 02:16:55PM +0800, zhoucm1 wrote:
> > > 
> > > On 2017年07月24日 19:57, Daniel Vetter wrote:
> > > > On Mon, Jul 24, 2017 at 11:51 AM, Christian König
> > > >  wrote:
> > > > > Am 24.07.2017 um 10:33 schrieb Daniel Vetter:
> > > > > > On Fri, Jul 21, 2017 at 06:20:01PM +0200, Christian König wrote:
> > > > > > > From: Christian König 
> > > > > > > 
> > > > > > > With hardware resets in mind it is possible that all shared 
> > > > > > > fences are
> > > > > > > signaled, but the exlusive isn't. Fix waiting for everything in 
> > > > > > > this
> > > > > > > situation.
> > > > > > How did you end up with both shared and exclusive fences on the same
> > > > > > reservation object? At least I thought the point of exclusive was 
> > > > > > that
> > > > > > it's exclusive (and has an implicit barrier on all previous shared
> > > > > > fences). Same for shared fences, they need to wait for the 
> > > > > > exclusive one
> > > > > > (and replace it).
> > > > > > 
> > > > > > Is this fallout from the amdgpu trickery where by default you do all
> > > > > > shared fences? I thought we've aligned semantics a while back ...
> > > > > No, that is perfectly normal even for other drivers. Take a look at 
> > > > > the
> > > > > reservation code.
> > > > > 
> > > > > The exclusive fence replaces all shared fences, but adding a shared 
> > > > > fence
> > > > > doesn't replace the exclusive fence. That actually makes sense, cause 
> > > > > when
> > > > > you want to add move shared fences those need to wait for the last 
> > > > > exclusive
> > > > > fence as well.
> > > > Hm right.
> > > > 
> > > > > Now normally I would agree that when you have shared fences it is 
> > > > > sufficient
> > > > > to wait for all of them cause those operations can't start before the
> > > > > exclusive one finishes. But with GPU reset and/or the ability to abort
> > > > > already submitted operations it is perfectly possible that you end up 
> > > > > with
> > > > > an exclusive fence which isn't signaled and a shared fence which is 
> > > > > signaled
> > > > > in the same reservation object.
> > > > How does that work? The batch(es) with the shared fence are all
> > > > supposed to wait for the exclusive fence before they start, which
> > > > means even if you gpu reset and restart/cancel certain things, they
> > > > shouldn't be able to complete out of order.
> > > Hi Daniel,
> > > 
> > > Do you mean exclusive fence must be signalled before any shared fence? 
> > > Where
> > > could I find this restriction?
> > Yes, Christian also described it above. Could be that we should have
> > better kerneldoc to document this ...
> Is that a known assumption? if that way, it doesn't matter even that we
> always wait exclusive fence, right? Just one more line checking.

The problem is that amdgpu breaks that assumption over gpu reset, and that
might have implications _everywhere_, not just in this code here. Are you
sure this case won't pull the i915 driver over the table when sharing
dma-bufs with it? Did you audit the code (plus all the other drivers too
ofc).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch