[PATCH v3] media: i2c: tda1997: replace codec to component

[Kuninori Morimoto]

From: Kuninori Morimoto 

Now we can replace Codec to Component. Let's do it.

Note:
xxx_codec_xxx() ->  xxx_component_xxx()
.idle_bias_off = 0  ->  .idle_bias_on = 1
.ignore_pmdown_time = 0 ->  .use_pmdown_time = 1
-   ->  .endianness = 1
-   ->  .non_legacy_dai_naming = 1

Signed-off-by: Kuninori Morimoto 
---
Tim, Mauro

This replace patch is needed for ALSA SoC, otherwise it can't probe anymore.
Mark, I think it needs your acked-by ?

v2 -> v3

 - fixup driver name (= tda1997)

 drivers/media/i2c/tda1997x.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
index 3021913..33d7fcf 100644
--- a/drivers/media/i2c/tda1997x.c
+++ b/drivers/media/i2c/tda1997x.c
@@ -2444,7 +2444,7 @@ static int tda1997x_pcm_startup(struct snd_pcm_substream 
*substream,
struct snd_soc_dai *dai)
 {
struct tda1997x_state *state = snd_soc_dai_get_drvdata(dai);
-   struct snd_soc_codec *codec = dai->codec;
+   struct snd_soc_component *component = dai->component;
struct snd_pcm_runtime *rtd = substream->runtime;
int rate, err;
 
@@ -2452,11 +2452,11 @@ static int tda1997x_pcm_startup(struct 
snd_pcm_substream *substream,
err = snd_pcm_hw_constraint_minmax(rtd, SNDRV_PCM_HW_PARAM_RATE,
   rate, rate);
if (err < 0) {
-   dev_err(codec->dev, "failed to constrain samplerate to %dHz\n",
+   dev_err(component->dev, "failed to constrain samplerate to 
%dHz\n",
rate);
return err;
}
-   dev_info(codec->dev, "set samplerate constraint to %dHz\n", rate);
+   dev_info(component->dev, "set samplerate constraint to %dHz\n", rate);
 
return 0;
 }
@@ -2479,20 +2479,22 @@ static int tda1997x_pcm_startup(struct 
snd_pcm_substream *substream,
.ops = _dai_ops,
 };
 
-static int tda1997x_codec_probe(struct snd_soc_codec *codec)
+static int tda1997x_codec_probe(struct snd_soc_component *component)
 {
return 0;
 }
 
-static int tda1997x_codec_remove(struct snd_soc_codec *codec)
+static void tda1997x_codec_remove(struct snd_soc_component *component)
 {
-   return 0;
 }
 
-static struct snd_soc_codec_driver tda1997x_codec_driver = {
-   .probe = tda1997x_codec_probe,
-   .remove = tda1997x_codec_remove,
-   .reg_word_size = sizeof(u16),
+static struct snd_soc_component_driver tda1997x_codec_driver = {
+   .probe  = tda1997x_codec_probe,
+   .remove = tda1997x_codec_remove,
+   .idle_bias_on   = 1,
+   .use_pmdown_time= 1,
+   .endianness = 1,
+   .non_legacy_dai_naming  = 1,
 };
 
 static int tda1997x_probe(struct i2c_client *client,
@@ -2737,7 +2739,7 @@ static int tda1997x_probe(struct i2c_client *client,
else
formats = SNDRV_PCM_FMTBIT_S16_LE;
tda1997x_audio_dai.capture.formats = formats;
-   ret = snd_soc_register_codec(>client->dev,
+   ret = devm_snd_soc_register_component(>client->dev,
 _codec_driver,
 _audio_dai, 1);
if (ret) {
@@ -2782,7 +2784,6 @@ static int tda1997x_remove(struct i2c_client *client)
struct tda1997x_platform_data *pdata = >pdata;
 
if (pdata->audout_format) {
-   snd_soc_unregister_codec(>dev);
mutex_destroy(>audio_lock);
}
 
-- 
1.9.1

[PATCH v7 1/2] media: dt-bindings: Add bindings for panasonic,amg88xx

[Matt Ranostay]

Define the device tree bindings for the panasonic,amg88xx i2c
video driver.

Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring 
Signed-off-by: Matt Ranostay 
---
 .../bindings/media/i2c/panasonic,amg88xx.txt  | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/panasonic,amg88xx.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/panasonic,amg88xx.txt 
b/Documentation/devicetree/bindings/media/i2c/panasonic,amg88xx.txt
new file mode 100644
index ..4a3181a3dd7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/panasonic,amg88xx.txt
@@ -0,0 +1,19 @@
+* Panasonic AMG88xx
+
+The Panasonic family of AMG88xx Grid-Eye sensors allow recording
+8x8 10Hz video which consists of thermal datapoints
+
+Required Properties:
+ - compatible : Must be "panasonic,amg88xx"
+ - reg : i2c address of the device
+
+Example:
+
+   i2c0@1c22000 {
+   ...
+   amg88xx@69 {
+   compatible = "panasonic,amg88xx";
+   reg = <0x69>;
+   };
+   ...
+   };
-- 
2.14.1

[PATCH v7 2/2] media: video-i2c: add video-i2c driver

[Matt Ranostay]

There are several thermal sensors that only have a low-speed bus
interface but output valid video data. This patchset enables support
for the AMG88xx "Grid-Eye" sensor family.

Signed-off-by: Matt Ranostay 
---
 MAINTAINERS   |   6 +
 drivers/media/i2c/Kconfig |  13 +
 drivers/media/i2c/Makefile|   1 +
 drivers/media/i2c/video-i2c.c | 560 ++
 4 files changed, 580 insertions(+)
 create mode 100644 drivers/media/i2c/video-i2c.c

diff --git a/MAINTAINERS b/MAINTAINERS
index dc153da22e8a..928b6a862626 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14880,6 +14880,12 @@ L: linux-media@vger.kernel.org
 S: Maintained
 F: drivers/media/platform/video-mux.c
 
+VIDEO I2C POLLING DRIVER
+M: Matt Ranostay 
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/i2c/video-i2c.c
+
 VIDEOBUF2 FRAMEWORK
 M: Pawel Osciak 
 M: Marek Szyprowski 
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 541f0d28afd8..faaaceb94832 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -974,6 +974,19 @@ config VIDEO_M52790
 
 To compile this driver as a module, choose M here: the
 module will be called m52790.
+
+config VIDEO_I2C
+   tristate "I2C transport video support"
+   depends on VIDEO_V4L2 && I2C
+   select VIDEOBUF2_VMALLOC
+   ---help---
+ Enable the I2C transport video support which supports the
+ following:
+  * Panasonic AMG88xx Grid-Eye Sensors
+
+ To compile this driver as a module, choose M here: the
+ module will be called video-i2c
+
 endmenu
 
 menu "Sensors used on soc_camera driver"
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index ea34aee1a85a..84cc472238ef 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -96,6 +96,7 @@ obj-$(CONFIG_VIDEO_LM3646)+= lm3646.o
 obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
 obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
 obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
+obj-$(CONFIG_VIDEO_I2C)+= video-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)   += tc358743.o
diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
new file mode 100644
index ..42427a724c00
--- /dev/null
+++ b/drivers/media/i2c/video-i2c.c
@@ -0,0 +1,560 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * video-i2c.c - Support for I2C transport video devices
+ *
+ * Copyright (C) 2018 Matt Ranostay 
+ *
+ * Supported:
+ * - Panasonic AMG88xx Grid-Eye Sensors
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define VIDEO_I2C_DRIVER   "video-i2c"
+
+struct video_i2c_chip;
+
+struct video_i2c_buffer {
+   struct vb2_v4l2_buffer vb;
+   struct list_head list;
+};
+
+struct video_i2c_data {
+   struct i2c_client *client;
+   const struct video_i2c_chip *chip;
+   struct mutex lock;
+   spinlock_t slock;
+   unsigned int sequence;
+   struct mutex queue_lock;
+
+   struct v4l2_device v4l2_dev;
+   struct video_device vdev;
+   struct vb2_queue vb_vidq;
+
+   struct task_struct *kthread_vid_cap;
+   struct list_head vid_cap_active;
+};
+
+static struct v4l2_fmtdesc amg88xx_format = {
+   .pixelformat = V4L2_PIX_FMT_Y12,
+};
+
+static struct v4l2_frmsize_discrete amg88xx_size = {
+   .width = 8,
+   .height = 8,
+};
+
+struct video_i2c_chip {
+   /* video dimensions */
+   const struct v4l2_fmtdesc *format;
+   const struct v4l2_frmsize_discrete *size;
+
+   /* max frames per second */
+   unsigned int max_fps;
+
+   /* pixel buffer size */
+   unsigned int buffer_size;
+
+   /* pixel size in bits */
+   unsigned int bpp;
+
+   /* xfer function */
+   int (*xfer)(struct video_i2c_data *data, char *buf);
+};
+
+static int amg88xx_xfer(struct video_i2c_data *data, char *buf)
+{
+   struct i2c_client *client = data->client;
+   struct i2c_msg msg[2];
+   u8 reg = 0x80;
+   int ret;
+
+   msg[0].addr = client->addr;
+   msg[0].flags = 0;
+   msg[0].len = 1;
+   msg[0].buf  = (char *)
+
+   msg[1].addr = client->addr;
+   msg[1].flags = I2C_M_RD;
+   msg[1].len = data->chip->buffer_size;
+   msg[1].buf = (char *)buf;
+
+   ret = i2c_transfer(client->adapter, msg, 2);
+
+   return (ret == 2) ? 0 : -EIO;
+}
+
+#define AMG88XX0
+
+static const struct video_i2c_chip video_i2c_chip[] = {
+   [AMG88XX] = {
+   .size   = _size,
+   .format 

[PATCH v7 0/2] media: video-i2c: add video-i2c driver support

[Matt Ranostay]

Add support for video-i2c polling driver

Changes from v1:
* Switch to SPDX tags versus GPLv2 license text
* Remove unneeded zeroing of data structures
* Add video_i2c_try_fmt_vid_cap call in video_i2c_s_fmt_vid_cap function

Changes from v2:
* Add missing linux/kthread.h include that broke x86_64 build

Changes from v3:
* Add devicetree binding documents
* snprintf check added
* switched to per chip support based on devicetree or i2c client id
* add VB2_DMABUF to io_modes
* added entry to MAINTAINERS file switched to per chip support based on 
devicetree or i2c client id

Changes from v4:
* convert pointer from of_device_get_match_data() to long instead of int to 
avoid compiler warning

Changes from v5:
* fix various issues with v4l2-compliance tool run

Changes from v6:
* fixed minor coding issues on spacing
* changed device tree table pointers to chip struct data
* add more verbose Kconfig documentation
* destroy mutexes on error path and module removal
* fixed MODULE_LICENSE from GPL to GPLv2
* changes some calls to list_last_entry() to avoid touching next pointer
* moved common code to a function from start/stop_streaming()

Matt Ranostay (2):
  media: dt-bindings: Add bindings for panasonic,amg88xx
  media: video-i2c: add video-i2c driver

 .../bindings/media/i2c/panasonic,amg88xx.txt   |  19 +
 MAINTAINERS|   6 +
 drivers/media/i2c/Kconfig  |  13 +
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/video-i2c.c  | 560 +
 5 files changed, 599 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/panasonic,amg88xx.txt
 create mode 100644 drivers/media/i2c/video-i2c.c

-- 
2.14.1

cron job: media_tree daily build: OK

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Fri Apr  6 05:00:16 CEST 2018
media-tree git hash:17dec0a949153d9ac00760ba2f5b78cb583e995f
media_build git hash:   541653bb52fcf7c34b8b83a4c8cc66b09c68ac37
v4l-utils git hash: 47d43b130dc6e9e0edc900759fb37649208371e4
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: v0.5.2-rc1
smatch version: v0.5.0-4419-g3b5bf5c9
host hardware:  x86_64
host os:4.14.0-3-amd64

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-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-i686: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-i686: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-i686: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.101-i686: OK
linux-3.0.101-x86_64: OK
linux-3.1.10-i686: OK
linux-3.1.10-x86_64: OK
linux-3.2.101-i686: OK
linux-3.2.101-x86_64: OK
linux-3.3.8-i686: OK
linux-3.3.8-x86_64: OK
linux-3.4.113-i686: OK
linux-3.4.113-x86_64: OK
linux-3.5.7-i686: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-i686: OK
linux-3.6.11-x86_64: OK
linux-3.7.10-i686: OK
linux-3.7.10-x86_64: OK
linux-3.8.13-i686: OK
linux-3.8.13-x86_64: OK
linux-3.9.11-i686: OK
linux-3.9.11-x86_64: OK
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.56-i686: OK
linux-3.16.56-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.102-i686: OK
linux-3.18.102-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.51-i686: OK
linux-4.1.51-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.109-i686: OK
linux-4.4.109-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.91-i686: OK
linux-4.9.91-x86_64: OK
linux-4.14.31-i686: OK
linux-4.14.31-x86_64: OK
linux-4.15.14-i686: OK
linux-4.15.14-x86_64: OK
linux-4.16-i686: OK
linux-4.16-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

RE: [PATCH v5 02/12] [media] cxd2880-spi: Add support for CXD2880 SPI interface

[Yasunari.Takiguchi]

Hi,　Mauro

> > +   u8 send_data[BURST_WRITE_MAX + 4];
> > +   const u8 *write_data_top = NULL;
> > +   int ret = 0;
> > +
> > +   if (!spi || !data) {
> > +   pr_err("invalid arg\n");
> > +   return -EINVAL;
> > +   }
> > +   if (size > BURST_WRITE_MAX) {
> > +   pr_err("data size > WRITE_MAX\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (sub_address + size > 0x100) {
> > +   pr_err("out of range\n");
> > +   return -EINVAL;
> > +   }
> 
> It is better to use dev_err(spi->dev, ...) instead of pr_err().

I got comment for this previous version patch as below
--
The best would be to se dev_err() & friends for printing messages, as they 
print the device's name as filled at struct device.
If you don't use, please add a define that will print the name at the logs, 
like:

  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

either at the begining of the driver or at some header file.

Btw, I'm noticing that you're also using dev_err() on other places of the code. 
Please standardize. OK, on a few places, you may still need to use pr_err(), if 
you need to print a message before initializing struct device, but I suspect 
that you can init
--

You pointed out here before. Because dev_foo () and pr_foo () were mixed.
We standardize with pr_foo() because the logs is outputted before getting the 
device structure.
Is it better to use dev_foo() where we can use it?

Takiguchi

Re: [RfC PATCH] Add udmabuf misc device

[Matt Roper]

On Thu, Apr 05, 2018 at 10:32:04PM +0200, Daniel Vetter wrote:
> Pulling this out of the shadows again.
> 
> We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff
> from Matt and Dongwong.
> 
> At least from the intel side there seems to be the idea to just have 1
> special device that can handle cross-gues/host sharing for all kinds
> of hypervisors, so I guess you all need to work together :-)
> 
> Or we throw out the idea that hyper dmabuf will be cross-hypervisor
> (not sure how useful/reasonable that is, someone please convince me
> one way or the other).
> 
> Cheers, Daniel

Dongwon (DW) is the one doing all the real work on hyper_dmabuf, but I'm
familiar with the use cases he's trying to address, and I think there
are a couple high-level goals of his work that are worth calling out as
we discuss the various options for sharing buffers produced in one VM
with a consumer running in another VM:

 * We should try to keep the interface/usage separate from the
   underlying hypervisor implementation details.  I.e., in DW's design
   the sink/source drivers that handle the actual buffer passing in the
   two VM's should provide a generic interface that does not depend on a
   specific hypervisor.  Behind the scenes there could be various
   implementations for specific hypervisors (Xen, KVM, ACRN, etc.), and
   some of those backends may have additional restrictions, but it would
   be best if userspace didn't have to know the specific hypervisor
   running on the system and could just query the general capabilities
   available to it.  We've already got projects in flight that are
   wanting this functionality on Xen and ACRN today.

 * The general interface should be able to express sharing from any
   guest:guest, not just guest:host.  Arbitrary G:G sharing might be
   something some hypervisors simply aren't able to support, but the
   userspace API itself shouldn't make assumptions or restrict that.  I
   think ideally the sharing API would include some kind of
   query_targets interface that would return a list of VM's that your
   current OS is allowed to share with; that list would be depend on the
   policy established by the system integrator, but obviously wouldn't
   include targets that the hypervisor itself wouldn't be capable of
   handling.
   
 * A lot of the initial use cases are in the realm of graphics, but this
   shouldn't be a graphics-specific API.  Buffers might contain other
   types of content as well (e.g., audio).  Really the content producer
   could potentially be any driver (or userspace) running in the VM that
   knows how to import/export dma_buf's (or maybe just import given
   danvet's suggestion that we should make the sink driver do all the
   actual memory allocation for any buffers that may be shared).

 * We need to be able to handle cross-VM coordination of buffer usage as
   well, so I think we'd want to include fence forwarding support in the
   API as well to signal back and forth about production/consumption
   completion.  And of course document really well what should happen
   if, for example, the entire VM you're sharing with/from dies.

 * The sharing API could be used to share multiple kinds of content in a
   single system.  The sharing sink driver running in the content
   producer's VM should accept some additional metadata that will be
   passed over to the target VM as well.  The sharing source driver
   running in the content consumer's VM would then be able to use this
   metadata to determine the purpose of a new buffer that arrives and
   filter/dispatch it to the appropriate consumer.


For reference, the terminology I'm using is

 /--\  dma_buf   /--\ HV /\  dma_buf   /--\
 | Producer |--->| Sink | HV | Source |--->| Consumer |
 \--/   ioctls   \--/ HV \/  uevents   \--/



In the realm of graphics, "Producer" could potentially be something like
an EGL client that sends the buffer at context setup and then signals
with fences on each SwapBuffers.  "Consumer" could be a Wayland client
that proxies the buffers into surfaces or dispatches them to other
userspace software that's waiting for buffers.

With the hyper_dmabuf approach, there's a lot of ABI details that need
to be worked out and really clearly documented before we worry too much
about the backend hypervisor-specific stuff.

I'm not super familiar with xen-zcopy and udmabuf, but it sounds like
they're approaching similar problems from slightly different directions,
so we should make sure we can come up with something that satisfies
everyone's requirements. 


Matt

> 
> On Wed, Mar 14, 2018 at 9:03 AM, Gerd Hoffmann  wrote:
> >   Hi,
> >
> >> Either mlock account (because it's mlocked defacto), and get_user_pages
> >> won't do that for you.
> >>
> >> Or you write the full-blown userptr implementation, including mmu_notifier
> >> support (see i915 or amdgpu), but that also requires 

Re: HVR1600 IR Blaster

[Sean Young]

Hi Warren,

On Thu, Apr 05, 2018 at 12:37:05PM -0600, Warren Sturm wrote:
> Is there a way to get the IR Blaster of the HVR1600 card working under
> v4.15+ kernels?
> 
> It seems that lrc_zilog BUGs under 4.15+ and has gone missing in 4.16.

In v4.16, lirc_zilog has been replaced with ir-kbd-i2c, which can now do
IR transmit/blast. Please can you provide dmesg and try IR transmit with
the associated /dev/lirc device (if one exists).

What is the BUG under v4.15?

Thanks

Sean

Re: [PATCH 05/16] media: fsl-viu: allow building it with COMPILE_TEST

[Arnd Bergmann]

On Thu, Apr 5, 2018 at 7:54 PM, Mauro Carvalho Chehab
 wrote:
> There aren't many things that would be needed to allow it
> to build with compile test.

> +/* Allow building this driver with COMPILE_TEST */
> +#ifndef CONFIG_PPC_MPC512x
> +#define NO_IRQ   0

The NO_IRQ usage here really needs to die. The portable way to do this
is the simpler

diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 200c47c69a75..707bda89b4f7 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -1407,7 +1407,7 @@ static int viu_of_probe(struct platform_device *op)
}

viu_irq = irq_of_parse_and_map(op->dev.of_node, 0);
-   if (viu_irq == NO_IRQ) {
+   if (!viu_irq) {
dev_err(>dev, "Error while mapping the irq\n");
return -EINVAL;
}

> +#define out_be32(v, a) writel(a, v)
> +#define in_be32(a) readl(a)

This does get it to compile, but looks confusing because it mixes up the
endianess. I'd suggest doing it like

#ifndef CONFIG_PPC
#define out_be32(v, a) iowrite32be(a, v)
#define in_be32(a) ioread32be(a)
#endif

  Arnd

Re: [PATCH v13 16/33] rcar-vin: simplify how formats are set and reset

[Niklas Söderlund]

Hi Laurent,

Thanks for your feedback.

I have incorporated your suggestions for the next and hopefully last 
version of this patch-set, a few followups on your review bellow.

On 2018-04-04 01:09:29 +0300, Laurent Pinchart wrote:
> Hi Niklas,
> 
> Thank you for the patch.
> 
> On Tuesday, 27 March 2018 00:44:39 EEST Niklas Söderlund wrote:
> > With the recent cleanup of the format code to prepare for Gen3 it's
> > possible to simplify the Gen2 format code path as well. Clean up the
> > process by defining two functions to handle the set format and reset of
> > format when the standard is changed.
> > 
> > While at it replace the driver local struct rvin_source_fmt with a
> > struct v4l2_rect as all it's used for is keep track of the source
> > dimensions.
> 
> I wonder whether we should introduce v4l2_size (or  name 
> here>) when all we need is width and height, as v4l2_rect stores the top and 
> left offsets too. This doesn't have to be fixed here though.

Yes that would have been useful for this change. I have added this to my 
ever growing TODO list :-)

[snip]

> 
> > -   vin->format.bytesperline = rvin_format_bytesperline(>format);
> > -   vin->format.sizeimage = rvin_format_sizeimage(>format);
> > +   vin->source.top = vin->crop.top = 0;
> > +   vin->source.left = vin->crop.left = 0;
> > +   vin->source.width = vin->crop.width = vin->format.width;
> > +   vin->source.height = vin->crop.height = vin->format.height;
> 
> I find multiple assignations on the same line hard to read. How about
> 
>   vin->source.top = 0;
>   vin->source.left = 0;
>   vin->source.width = vin->format.width;
>   vin->source.height = vin->format.height;
> 
>   vin->crop = vin->source;
>   vin->compose = vin->source;

This looks much better and I will use it, thanks !

[snip]

> 
> > +   /*
> > +* If source is ALTERNATE the driver will use the VIN hardware
> > +* to INTERLACE it. The crop height then needs to be doubled.
> > +*/
> > +   if (pix->field == V4L2_FIELD_ALTERNATE)
> > +   crop->height *= 2;
> 
> You're duplicating this logic in rvin_format_align() so it makes me feel that 
> there's still room for some simplification, but that can be done in a 
> separate 
> patch (or I could simply be wrong).

I'm sure someone more clever then me can simplify this more. In this 
particular case rvin_format_align() deals with the video device format 
while here we deal with the crop rectangle. I will keep this in mind for 
future work and see if this can be unified in simpler way.

[snip]

> > -   return __rvin_try_format(vin, V4L2_SUBDEV_FORMAT_TRY, 
> > >fmt.pix,
> > -);
> > +   return rvin_try_format(vin, V4L2_SUBDEV_FORMAT_TRY, >fmt.pix, ,
> > +  );
> 
> How about making crop and compose optional in rvin_try_format() to avoid a 
> need for the two local variables here ?

Great suggestion, I have incorporated this for the next version.

> 
> Apart from these small issues, I think this is a nice simplification,
> 
> Reviewed-by: Laurent Pinchart 

Thanks!

-- 
Regards,
Niklas Söderlund

Re: [PATCH v13 00/33] rcar-vin: Add Gen3 with media controller

[Niklas Söderlund]

Hi Hans,

On 2018-04-04 12:28:30 +0200, Hans Verkuil wrote:
> Hi Niklas,
> 
> It might be a good idea if you can rebase the patch series on the latest
> master (we've just synced to Linus' master tree) and incorporate the few
> comments that Laurent had.

I have now rebased this and incorporate the comments from Laurent. I 
still need to test the rebased work so will post this tomorrow or early 
next week.

> 
> Then once the merge window closes I can make the pull request, probably on
> the 16th.

Thanks for that and thanks again for all your help in my pursuit to get 
this series accepted!

> 
> Regards,
> 
>   Hans
> 
> On 03/04/18 14:30, Hans Verkuil wrote:
> > On 26/03/18 23:44, Niklas Söderlund wrote:
> >> Hi,
> >>
> >> This series adds Gen3 VIN support to rcar-vin driver for Renesas r8a7795,
> >> r8a7796 and r8a77970. It is based on the media-tree and depends on
> >> Fabrizio Castro patches as they touches the order of the compatible
> >> strings in the documentation to reduce merge conflicts. The dependencies
> >> are included in this series.
> > 
> > Laurent, Kieran,
> > 
> > Unless there are any objections I want to make a pull request for this
> > series once 4.17-rc1 has been merged back into our master tree. It all
> > looks good to me, and it will be nice to get this in (finally!).
> > 
> > I don't want to postpone the pull request for small improvements, they
> > can be applied later. But if there are more serious concerns, then let
> > us know.
> > 
> > Regards,
> > 
> > Hans
> > 
> >>
> >> The driver is tested on Renesas H3 (r8a7795, ES2.0),
> >> M3-W (r8a7796) together with the rcar-csi2 driver (posted separately and
> >> not yet upstream) and the Salvator-X onboard ADV7482. It is also tested
> >> on the V3M (r8a77970) on the Eagle board together with its expansion
> >> board with a ADV7482 and out of tree patches for GMSL capture using the
> >> max9286 and rdacm20 drivers.
> >>
> >> It is possible to capture both CVBS and HDMI video streams,
> >> v4l2-compliance passes with no errors and media-ctl can be used to
> >> change the routing and formats for the different entities in the media
> >> graph.
> >>
> >> Gen2 compatibility is verified on Koelsch and no problems where found,
> >> video can be captured just like before and v4l2-compliance passes
> >> without errors or warnings just like before this series.
> >>
> >> For convenience the series can be fetched from:
> >>
> >>   git://git.ragnatech.se/linux rcar/vin/mc-v13
> >>
> >> I have started on a very basic test suite for the VIN driver at:
> >>
> >>   https://git.ragnatech.se/vin-tests
> >>
> >> And as before the state of the driver and information about how to test
> >> it can be found on the elinux wiki:
> >>
> >>   http://elinux.org/R-Car/Tests:rcar-vin
> >>
> >> * Changes from v12
> >> - Rebase to latest media-tree/master changed a 'return ret' to a 'goto
> >>   out' in rvin_start_streaming() to take recent changes to the VIN 
> >>   driver into account.
> >> - Moved field != V4L2_FIELD_ANY in 'rcar-vin: set a default field to  
> >>   fallback on' check from a later commit 'rcar-vin: simplify how formats 
> >>   are set and reset' in the series. This is to avoid ignoring the field 
> >>   returned from the sensor if FIELD_ANY was requested by the user. This 
> >>   was only a problem between this change and a few patches later, but 
> >>   better to fix it now. Reported by Hans, thanks for spotting this.
> >> - Fix spelling.
> >> - Add review tags from Hans.
> >>
> >> * Changes since v11
> >> - Rewrote commit message for '[PATCH v11 22/32] rcar-vin: force default
> >>   colorspace for media centric mode'. Also set fixed values for
> >>   xfer_func, quantization and ycbcr_enc.
> >> - Reorderd filed order in struct rvin_group_route.
> >> - Renamed chan to channel in struct rvin_group_route.
> >> - Rework 'rcar-vin: read subdevice format for crop only when
> >>   needed' into 'rcar-vin: simplify how formats are set and reset'.
> >> - Keep caching the source dimensions and drop all changes to
> >>   rvin_g_selection() and rvin_s_selection().
> >> - Inline rvin_get_vin_format_from_source() into rvin_reset_format()
> >>   which now is the only user left.
> >> - Add patch to cache the video standard instead of reading it at stream
> >>   on.
> >> - Fix error labels in rvin_mc_open().
> >> - Fixed spelling in commit messages and comment, thanks Laurent!
> >> - Added reviewed tags from Laurent, Thanks!
> >>
> >> * Changes since v10
> >> - Corrected spelling in comments and commit messages.
> >> - Reworked 'rcar-vin: read subdevice format for crop only when needed'
> >>   to only get the source format once per operation.
> >> - Moved some patches around to make it easier to review, moved:
> >> - rcar-vin: set a default field to fallback on
> >> - rcar-vin: fix handling of single field frames (top, bottom and 
> >> alternate fields)
> >> - rcar-vin: update bytesperline and sizeimage calculation
> >> - rcar-vin: 

Re: [PATCH v2 17/19] media: omap4iss: make it build with COMPILE_TEST

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Thursday, 5 April 2018 23:29:44 EEST Mauro Carvalho Chehab wrote:
> This driver compile as-is with COMPILE_TEST.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Laurent Pinchart 

I don't have patches pending for the omap4iss driver, could you merge this 
patch as part of the whole series ?

> ---
>  drivers/staging/media/omap4iss/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/omap4iss/Kconfig
> b/drivers/staging/media/omap4iss/Kconfig index 46183464ee79..192ba0829128
> 100644
> --- a/drivers/staging/media/omap4iss/Kconfig
> +++ b/drivers/staging/media/omap4iss/Kconfig
> @@ -1,6 +1,7 @@
>  config VIDEO_OMAP4
>   tristate "OMAP 4 Camera support"
> - depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C
> + depends on ARCH_OMAP4 || COMPILE_TEST
>   depends on HAS_DMA
>   select MFD_SYSCON
>   select VIDEOBUF2_DMA_CONTIG


-- 
Regards,

Laurent Pinchart

Re: [PATCH 00/20] dddvb/ddbridge-0.9.33

[Daniel Scheller]

Am Mon,  2 Apr 2018 20:24:07 +0200
schrieb Daniel Scheller :

> From: Daniel Scheller 
> 
> This series brings all relevant changes from the upstream dddvb-0.9.33
> driver package to the in-kernel ddbridge and stv0910, though a few
> changes were picked up and merged previously already.
> 
> Summary of changes:
> * stv0910: initialisation fixes and fixed CNR reporting (uvalue vs.
>   svalue)
> * ddbridge: general code move, cleanups and fixups
> * ddbridge: fixes and improvements to the IRQ setup and handling, and
>   MSI-X support
> * ddbridge: configurable DMA buffers (via modparam)
> * ddbridge: dummy tuner option, useful for debugging and stress
> testing purposes
> * ddbridge: support for the new MCI card types, and namely the new
> MaxSX8 cards
> 
> Patches were build-tested in their order and are bisect safe. Besides
> the modparam move, everything is picked up from dddvb-0.9.33.
> 
> The series adds the new ddbridge-mci.[c|h] files. Here, SPDX headers
> were already put in place, but until things have been fully sorted
> out, the original GPL boiler plate is kept in place for now.
> 
> Please pick up and merge.
> 
> Daniel Scheller (20):
>   [media] dvb-frontends/stv0910: add init values for TSINSDELM/L
>   [media] dvb-frontends/stv0910: increase parallel TS output speed
>   [media] dvb-frontends/stv0910: fix CNR reporting in read_snr()
>   [media] ddbridge: move modparams to ddbridge-core.c
>   [media] ddbridge: move ddb_wq and the wq+class initialisation to
> -core [media] ddbridge: move MSI IRQ cleanup to a helper function
>   [media] ddbridge: request/free_irq using pci_irq_vector, enable
> MSI-X [media] ddbridge: add helper for IRQ handler setup
>   [media] ddbridge: add macros to handle IRQs in nibble and byte
> blocks [media] ddbridge: improve separated MSI IRQ handling
>   [media] ddbridge: use spin_lock_irqsave() in output_work()
>   [media] ddbridge: fix output buffer check
>   [media] ddbridge: set devid entry for link 0
>   [media] ddbridge: make DMA buffer count and size
> modparam-configurable [media] ddbridge: support dummy tuners with
> 125MByte/s dummy data stream
>   [media] ddbridge: initial support for MCI-based MaxSX8 cards
>   [media] ddbridge/max: implement MCI/MaxSX8 attach function
>   [media] ddbridge: add hardware defs and PCI IDs for MCI cards
>   [media] ddbridge: recognize and attach the MaxSX8 cards
>   [media] ddbridge: set driver version to 0.9.33-integrated
> 
>  drivers/media/dvb-frontends/stv0910.c  |  12 +-
>  drivers/media/pci/ddbridge/Kconfig |   1 +
>  drivers/media/pci/ddbridge/Makefile|   2 +-
>  drivers/media/pci/ddbridge/ddbridge-core.c | 299 +++-
>  drivers/media/pci/ddbridge/ddbridge-hw.c   |  11 +
>  drivers/media/pci/ddbridge/ddbridge-i2c.c  |   5 +-
>  drivers/media/pci/ddbridge/ddbridge-main.c |  91 ++---
>  drivers/media/pci/ddbridge/ddbridge-max.c  |  42 +++
>  drivers/media/pci/ddbridge/ddbridge-max.h  |   1 +
>  drivers/media/pci/ddbridge/ddbridge-mci.c  | 550
> +
> drivers/media/pci/ddbridge/ddbridge-mci.h  | 152 
> drivers/media/pci/ddbridge/ddbridge.h  |  50 +-- 12 files
> changed, 1030 insertions(+), 186 deletions(-) create mode 100644
> drivers/media/pci/ddbridge/ddbridge-mci.c create mode 100644
> drivers/media/pci/ddbridge/ddbridge-mci.h
> 

Please refrain from merging this as it is now. Recently, one issue has
been discovered with one of the stv0910 patches which renders at least
the CineS2 V7A cards (specifically the tuners soldered on them,
extensions will still work fine) unusable. Upstream has this issue
aswell. This is currently under investigation.

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

[PATCH v2 12/19] media: davinci: allow build vpbe_display with COMPILE_TEST

[Mauro Carvalho Chehab]

Except for some includes (with doesn't seem to be used), this
driver builds fine with COMPILE_TEST.

So, add checks there to avoid building it if ARCH_DAVINCI
is not selected.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/davinci/Kconfig| 3 ++-
 drivers/media/platform/davinci/vpbe_display.c | 3 +++
 drivers/media/platform/davinci/vpbe_osd.c | 2 ++
 drivers/media/platform/davinci/vpbe_venc.c| 3 +++
 4 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/davinci/Kconfig 
b/drivers/media/platform/davinci/Kconfig
index babdb4877b3f..b463d1726335 100644
--- a/drivers/media/platform/davinci/Kconfig
+++ b/drivers/media/platform/davinci/Kconfig
@@ -82,7 +82,8 @@ config VIDEO_DM365_ISIF
 
 config VIDEO_DAVINCI_VPBE_DISPLAY
tristate "TI DaVinci VPBE V4L2-Display driver"
-   depends on VIDEO_V4L2 && ARCH_DAVINCI
+   depends on VIDEO_V4L2
+   depends on ARCH_DAVINCI || COMPILE_TEST
depends on HAS_DMA
depends on I2C
select VIDEOBUF2_DMA_CONTIG
diff --git a/drivers/media/platform/davinci/vpbe_display.c 
b/drivers/media/platform/davinci/vpbe_display.c
index 6aabd21fe69f..7b6cd4b3ccc4 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -26,7 +26,10 @@
 #include 
 
 #include 
+
+#ifdef CONFIG_ARCH_DAVINCI
 #include 
+#endif
 
 #include 
 #include 
diff --git a/drivers/media/platform/davinci/vpbe_osd.c 
b/drivers/media/platform/davinci/vpbe_osd.c
index 66449791c70c..10f2bf11edf3 100644
--- a/drivers/media/platform/davinci/vpbe_osd.c
+++ b/drivers/media/platform/davinci/vpbe_osd.c
@@ -24,8 +24,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_ARCH_DAVINCI
 #include 
 #include 
+#endif
 
 #include 
 #include 
diff --git a/drivers/media/platform/davinci/vpbe_venc.c 
b/drivers/media/platform/davinci/vpbe_venc.c
index 3a4e78595149..add72a39ef2d 100644
--- a/drivers/media/platform/davinci/vpbe_venc.c
+++ b/drivers/media/platform/davinci/vpbe_venc.c
@@ -21,8 +21,11 @@
 #include 
 #include 
 
+#ifdef CONFIG_ARCH_DAVINCI
 #include 
 #include 
+#endif
+
 #include 
 
 #include 
-- 
2.14.3

[PATCH v2 16/19] media: omap: allow building it with COMPILE_TEST

[Mauro Carvalho Chehab]

Now that we have stubs for omap FB driver, let it build with
COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/omap/Kconfig | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/omap/Kconfig 
b/drivers/media/platform/omap/Kconfig
index e8e2db181a7a..27343376f557 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -1,15 +1,15 @@
 config VIDEO_OMAP2_VOUT_VRFB
bool
+   default y
+   depends on VIDEO_OMAP2_VOUT && (OMAP2_VRFB || COMPILE_TEST)
 
 config VIDEO_OMAP2_VOUT
tristate "OMAP2/OMAP3 V4L2-Display driver"
-   depends on MMU
-   depends on ARCH_OMAP2 || ARCH_OMAP3
-   depends on FB_OMAP2
+   depends on MMU && FB_OMAP2
+   depends on ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST
select VIDEOBUF_GEN
select VIDEOBUF_DMA_CONTIG
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
-   select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT && OMAP2_VRFB
select FRAME_VECTOR
default n
---help---
-- 
2.14.3

[PATCH v2 08/19] media: mmp-camera.h: add missing platform data

[Mauro Carvalho Chehab]

Those definitions used to be part of the original patch:
https://patchwork.kernel.org/patch/2815221/

But, somehow, nobody ever noticed until today. Years later,
Arnd discovered that mmp-camera driver doesn't build and make
it depend on BROKEN.

Add the missing bits here, in order to remove BROKEN dependency.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/linux/platform_data/media/mmp-camera.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/platform_data/media/mmp-camera.h 
b/include/linux/platform_data/media/mmp-camera.h
index 83804028115c..d2d3a443eedf 100644
--- a/include/linux/platform_data/media/mmp-camera.h
+++ b/include/linux/platform_data/media/mmp-camera.h
@@ -3,8 +3,27 @@
  * Information for the Marvell Armada MMP camera
  */
 
+#include 
+
+enum dphy3_algo {
+   DPHY3_ALGO_DEFAULT = 0,
+   DPHY3_ALGO_PXA910,
+   DPHY3_ALGO_PXA2128
+};
+
 struct mmp_camera_platform_data {
struct platform_device *i2c_device;
int sensor_power_gpio;
int sensor_reset_gpio;
+   enum v4l2_mbus_type bus_type;
+   int mclk_min;   /* The minimal value of MCLK */
+   int mclk_src;   /* which clock source the MCLK derives from */
+   int mclk_div;   /* Clock Divider Value for MCLK */
+   /*
+* MIPI support
+*/
+   int dphy[3];/* DPHY: CSI2_DPHY3, CSI2_DPHY5, CSI2_DPHY6 */
+   enum dphy3_algo dphy3_algo; /* algos for calculate CSI2_DPHY3 */
+   int lane;   /* ccic used lane number; 0 means DVP mode */
+   int lane_clk;
 };
-- 
2.14.3

[PATCH v2 10/19] media: mmp-driver: make two functions static

[Mauro Carvalho Chehab]

Those functions are used only internally:

  CC  drivers/media/platform/marvell-ccic/mmp-driver.o
drivers/media/platform/marvell-ccic/mmp-driver.c:186:6: warning: no previous 
prototype for ‘mcam_ctlr_reset’ [-Wmissing-prototypes]
 void mcam_ctlr_reset(struct mcam_camera *mcam)
  ^~~
drivers/media/platform/marvell-ccic/mmp-driver.c:217:6: warning: no previous 
prototype for ‘mmpcam_calc_dphy’ [-Wmissing-prototypes]
 void mmpcam_calc_dphy(struct mcam_camera *mcam)
  ^~~~

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/marvell-ccic/mmp-driver.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c 
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 816f4b6a7b8e..17d79480e75c 100644
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -183,7 +183,7 @@ static void mmpcam_power_down(struct mcam_camera *mcam)
mcam_clk_disable(mcam);
 }
 
-void mcam_ctlr_reset(struct mcam_camera *mcam)
+static void mcam_ctlr_reset(struct mcam_camera *mcam)
 {
unsigned long val;
struct mmp_camera *cam = mcam_to_cam(mcam);
@@ -214,7 +214,7 @@ void mcam_ctlr_reset(struct mcam_camera *mcam)
  * CSI2_DPHY3 and CSI2_DPHY6 can be set with a default value
  * or be calculated dynamically
  */
-void mmpcam_calc_dphy(struct mcam_camera *mcam)
+static void mmpcam_calc_dphy(struct mcam_camera *mcam)
 {
struct mmp_camera *cam = mcam_to_cam(mcam);
struct mmp_camera_platform_data *pdata = cam->pdev->dev.platform_data;
-- 
2.14.3

[PATCH v2 19/19] media: staging: davinci_vpfe: allow building with COMPILE_TEST

[Mauro Carvalho Chehab]

This is a little bit hashish, but this driver is at staging,
so it won't become worse.

With this small change at Makefile, we can now build it with
COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/davinci_vpfe/Kconfig  | 3 ++-
 drivers/staging/media/davinci_vpfe/Makefile | 5 +
 drivers/staging/media/davinci_vpfe/TODO | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/davinci_vpfe/Kconfig 
b/drivers/staging/media/davinci_vpfe/Kconfig
index f40a06954a92..bcba9a64c514 100644
--- a/drivers/staging/media/davinci_vpfe/Kconfig
+++ b/drivers/staging/media/davinci_vpfe/Kconfig
@@ -1,6 +1,7 @@
 config VIDEO_DM365_VPFE
tristate "DM365 VPFE Media Controller Capture Driver"
-   depends on VIDEO_V4L2 && ARCH_DAVINCI_DM365 && !VIDEO_DM365_ISIF
+   depends on VIDEO_V4L2
+   depends on (ARCH_DAVINCI_DM365 && !VIDEO_DM365_ISIF) || COMPILE_TEST
depends on HAS_DMA
depends on VIDEO_V4L2_SUBDEV_API
depends on VIDEO_DAVINCI_VPBE_DISPLAY
diff --git a/drivers/staging/media/davinci_vpfe/Makefile 
b/drivers/staging/media/davinci_vpfe/Makefile
index 3019c9ecd548..9c57042c877d 100644
--- a/drivers/staging/media/davinci_vpfe/Makefile
+++ b/drivers/staging/media/davinci_vpfe/Makefile
@@ -3,3 +3,8 @@ obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci-vfpe.o
 davinci-vfpe-objs := \
dm365_isif.o dm365_ipipe_hw.o dm365_ipipe.o \
dm365_resizer.o dm365_ipipeif.o vpfe_mc_capture.o vpfe_video.o
+
+# Allow building it with COMPILE_TEST on other archs
+ifndef CONFIG_ARCH_DAVINCI
+ccflags-y += -Iarch/arm/mach-davinci/include/
+endif
diff --git a/drivers/staging/media/davinci_vpfe/TODO 
b/drivers/staging/media/davinci_vpfe/TODO
index 3e5477e8cfa5..cc8bd9306f2a 100644
--- a/drivers/staging/media/davinci_vpfe/TODO
+++ b/drivers/staging/media/davinci_vpfe/TODO
@@ -20,6 +20,7 @@ TODO (general):
 - While replacing the older driver in media folder, provide a compatibility
   layer and compatibility tests that warrants (using the libv4l's LD_PRELOAD
   approach) there is no regression for the users using the older driver.
+- make it independent of arch-specific APIs (mach/mux.h).
 
 Building of uImage and Applications:
 ==
-- 
2.14.3

[PATCH v2 03/19] media: omap3isp/isp: remove an unused static var

[Mauro Carvalho Chehab]

The isp_xclk_init_data const data isn't used anywere.

drivers/media/platform/omap3isp/isp.c:294:35: warning: ‘isp_xclk_init_data’ 
defined but not used [-Wunused-const-variable=]
 static const struct clk_init_data isp_xclk_init_data = {
   ^~

Fixes: 9b28ee3c9122 ("[media] omap3isp: Use the common clock framework")
Reviewed-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/omap3isp/isp.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 2a11a709aa4f..9e4b5fb8a8b5 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -291,13 +291,6 @@ static const struct clk_ops isp_xclk_ops = {
 
 static const char *isp_xclk_parent_name = "cam_mclk";
 
-static const struct clk_init_data isp_xclk_init_data = {
-   .name = "cam_xclk",
-   .ops = _xclk_ops,
-   .parent_names = _xclk_parent_name,
-   .num_parents = 1,
-};
-
 static struct clk *isp_xclk_src_get(struct of_phandle_args *clkspec, void 
*data)
 {
unsigned int idx = clkspec->args[0];
-- 
2.14.3

[PATCH v2 13/19] media: vpbe_venc: don't store return codes if they won't be used

[Mauro Carvalho Chehab]

Fix those two warnings

drivers/media/platform/davinci/vpbe_venc.c: In function ‘venc_set_ntsc’:
drivers/media/platform/davinci/vpbe_venc.c:230:6: warning: variable ‘val’ set 
but not used [-Wunused-but-set-variable]
  u32 val;
  ^~~
drivers/media/platform/davinci/vpbe_venc.c: In function ‘venc_sub_dev_init’:
drivers/media/platform/davinci/vpbe_venc.c:611:6: warning: variable ‘err’ set 
but not used [-Wunused-but-set-variable]
  int err;
  ^~~
  AR  drivers/media/platform/davinci/built-in.a

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/davinci/vpbe_venc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/davinci/vpbe_venc.c 
b/drivers/media/platform/davinci/vpbe_venc.c
index add72a39ef2d..5c255de3b3f8 100644
--- a/drivers/media/platform/davinci/vpbe_venc.c
+++ b/drivers/media/platform/davinci/vpbe_venc.c
@@ -227,7 +227,6 @@ venc_enable_vpss_clock(int venc_type,
  */
 static int venc_set_ntsc(struct v4l2_subdev *sd)
 {
-   u32 val;
struct venc_state *venc = to_state(sd);
struct venc_platform_data *pdata = venc->pdata;
 
@@ -244,7 +243,7 @@ static int venc_set_ntsc(struct v4l2_subdev *sd)
if (venc->venc_type == VPBE_VERSION_3) {
venc_write(sd, VENC_CLKCTL, 0x01);
venc_write(sd, VENC_VIDCTL, 0);
-   val = vdaccfg_write(sd, VDAC_CONFIG_SD_V3);
+   vdaccfg_write(sd, VDAC_CONFIG_SD_V3);
} else if (venc->venc_type == VPBE_VERSION_2) {
venc_write(sd, VENC_CLKCTL, 0x01);
venc_write(sd, VENC_VIDCTL, 0);
@@ -608,9 +607,8 @@ struct v4l2_subdev *venc_sub_dev_init(struct v4l2_device 
*v4l2_dev,
const char *venc_name)
 {
struct venc_state *venc;
-   int err;
 
-   err = bus_for_each_dev(_bus_type, NULL, ,
+   bus_for_each_dev(_bus_type, NULL, ,
venc_device_get);
if (venc == NULL)
return NULL;
-- 
2.14.3

[PATCH v2 02/19] media: omap3isp: allow it to build with COMPILE_TEST

[Mauro Carvalho Chehab]

There aren't much things required for it to build with COMPILE_TEST.
It just needs to provide stub for an arm-dependent include.

Let's replicate the same solution used by ipmmu-vmsa, in order
to allow building omap3 with COMPILE_TEST.

The actual logic here came from this driver:

   drivers/iommu/ipmmu-vmsa.c

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/Kconfig| 8 
 drivers/media/platform/omap3isp/isp.c | 7 +++
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8a1b01..03c9dfeb7781 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -62,12 +62,12 @@ config VIDEO_MUX
 
 config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
-   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
+   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
depends on HAS_DMA && OF
-   depends on OMAP_IOMMU
-   select ARM_DMA_USE_IOMMU
+   depends on ((ARCH_OMAP3 && OMAP_IOMMU) || COMPILE_TEST)
+   select ARM_DMA_USE_IOMMU if OMAP_IOMMU
select VIDEOBUF2_DMA_CONTIG
-   select MFD_SYSCON
+   select MFD_SYSCON if ARCH_OMAP3
select V4L2_FWNODE
---help---
  Driver for an OMAP 3 camera controller.
diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 8eb000e3d8fd..2a11a709aa4f 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -61,7 +61,14 @@
 #include 
 #include 
 
+#if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
 #include 
+#else
+#define arm_iommu_create_mapping(...)  NULL
+#define arm_iommu_attach_device(...)   -ENODEV
+#define arm_iommu_release_mapping(...) do {} while (0)
+#define arm_iommu_detach_device(...)   do {} while (0)
+#endif
 
 #include 
 #include 
-- 
2.14.3

[PATCH v2 09/19] media: marvel-ccic: re-enable mmp-driver build

[Mauro Carvalho Chehab]

This driver was disabled back in 2015 from builds because
of some troubles with the platform_data definition. Now
that this got fixed, re-enable it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/marvell-ccic/Kconfig | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/marvell-ccic/Kconfig 
b/drivers/media/platform/marvell-ccic/Kconfig
index 4bf5bd1e90d6..21dacef7c2fc 100644
--- a/drivers/media/platform/marvell-ccic/Kconfig
+++ b/drivers/media/platform/marvell-ccic/Kconfig
@@ -13,8 +13,9 @@ config VIDEO_CAFE_CCIC
 
 config VIDEO_MMP_CAMERA
tristate "Marvell Armada 610 integrated camera controller support"
-   depends on ARCH_MMP && I2C && VIDEO_V4L2
-   depends on HAS_DMA && BROKEN
+   depends on I2C && VIDEO_V4L2
+   depends on HAS_DMA
+   depends on ARCH_MMP || COMPILE_TEST
select VIDEO_OV7670
select I2C_GPIO
select VIDEOBUF2_DMA_SG
-- 
2.14.3

[PATCH v2 04/19] media: fsl-viu: mark static functions as such

[Mauro Carvalho Chehab]

There are several functions that are used only inside the
driver. Stop exposing that to global symbolspace.

Get rid of the following gcc warnings:

drivers/media/platform/fsl-viu.c:240:17: warning: no previous prototype for 
‘format_by_fourcc’ [-Wmissing-prototypes]
 struct viu_fmt *format_by_fourcc(int fourcc)
 ^~~~
drivers/media/platform/fsl-viu.c:253:6: warning: no previous prototype for 
‘viu_start_dma’ [-Wmissing-prototypes]
 void viu_start_dma(struct viu_dev *dev)
  ^
drivers/media/platform/fsl-viu.c:262:6: warning: no previous prototype for 
‘viu_stop_dma’ [-Wmissing-prototypes]
 void viu_stop_dma(struct viu_dev *dev)
  ^~~~
drivers/media/platform/fsl-viu.c:807:5: warning: no previous prototype for 
‘vidioc_g_fbuf’ [-Wmissing-prototypes]
 int vidioc_g_fbuf(struct file *file, void *priv, struct v4l2_framebuffer *arg)
 ^
drivers/media/platform/fsl-viu.c:818:5: warning: no previous prototype for 
‘vidioc_s_fbuf’ [-Wmissing-prototypes]
 int vidioc_s_fbuf(struct file *file, void *priv, const struct v4l2_framebuffer 
*arg)
 ^
drivers/media/platform/fsl-viu.c: In function ‘viu_open’:
drivers/media/platform/fsl-viu.c:1170:6: warning: variable ‘status_cfg’ set but 
not used [-Wunused-but-set-variable]
  u32 status_cfg;
  ^~
drivers/media/platform/fsl-viu.c: At top level:
drivers/media/platform/fsl-viu.c:1304:6: warning: no previous prototype for 
‘viu_reset’ [-Wmissing-prototypes]
 void viu_reset(struct viu_reg *reg)
  ^

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/fsl-viu.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 200c47c69a75..9abe79779659 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -229,7 +229,7 @@ enum status_config {
 
 static irqreturn_t viu_intr(int irq, void *dev_id);
 
-struct viu_fmt *format_by_fourcc(int fourcc)
+static struct viu_fmt *format_by_fourcc(int fourcc)
 {
int i;
 
@@ -242,7 +242,7 @@ struct viu_fmt *format_by_fourcc(int fourcc)
return NULL;
 }
 
-void viu_start_dma(struct viu_dev *dev)
+static void viu_start_dma(struct viu_dev *dev)
 {
struct viu_reg *vr = dev->vr;
 
@@ -253,7 +253,7 @@ void viu_start_dma(struct viu_dev *dev)
out_be32(>status_cfg, INT_FIELD_EN);
 }
 
-void viu_stop_dma(struct viu_dev *dev)
+static void viu_stop_dma(struct viu_dev *dev)
 {
struct viu_reg *vr = dev->vr;
int cnt = 100;
@@ -802,7 +802,7 @@ static int vidioc_overlay(struct file *file, void *priv, 
unsigned int on)
return 0;
 }
 
-int vidioc_g_fbuf(struct file *file, void *priv, struct v4l2_framebuffer *arg)
+static int vidioc_g_fbuf(struct file *file, void *priv, struct 
v4l2_framebuffer *arg)
 {
struct viu_fh  *fh = priv;
struct viu_dev *dev = fh->dev;
@@ -813,7 +813,7 @@ int vidioc_g_fbuf(struct file *file, void *priv, struct 
v4l2_framebuffer *arg)
return 0;
 }
 
-int vidioc_s_fbuf(struct file *file, void *priv, const struct v4l2_framebuffer 
*arg)
+static int vidioc_s_fbuf(struct file *file, void *priv, const struct 
v4l2_framebuffer *arg)
 {
struct viu_fh  *fh = priv;
struct viu_dev *dev = fh->dev;
@@ -1305,7 +1305,7 @@ static int viu_release(struct file *file)
return 0;
 }
 
-void viu_reset(struct viu_reg *reg)
+static void viu_reset(struct viu_reg *reg)
 {
out_be32(>status_cfg, 0);
out_be32(>luminance, 0x9512a254);
-- 
2.14.3

[PATCH v2 17/19] media: omap4iss: make it build with COMPILE_TEST

[Mauro Carvalho Chehab]

This driver compile as-is with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/omap4iss/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/omap4iss/Kconfig 
b/drivers/staging/media/omap4iss/Kconfig
index 46183464ee79..192ba0829128 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,6 +1,7 @@
 config VIDEO_OMAP4
tristate "OMAP 4 Camera support"
-   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C
+   depends on ARCH_OMAP4 || COMPILE_TEST
depends on HAS_DMA
select MFD_SYSCON
select VIDEOBUF2_DMA_CONTIG
-- 
2.14.3

[PATCH v2 14/19] media: davinci: get rid of lots of kernel-doc warnings

[Mauro Carvalho Chehab]

Driver build produce lots of warnings due to wrong kernel-doc markups:

drivers/media/platform/davinci/vpbe.c:60: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_current_encoder_info'
drivers/media/platform/davinci/vpbe.c:78: warning: Function parameter or 
member 'cfg' not described in 'vpbe_find_encoder_sd_index'
drivers/media/platform/davinci/vpbe.c:78: warning: Function parameter or 
member 'index' not described in 'vpbe_find_encoder_sd_index'
drivers/media/platform/davinci/vpbe.c:105: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_g_cropcap'
drivers/media/platform/davinci/vpbe.c:105: warning: Function parameter or 
member 'cropcap' not described in 'vpbe_g_cropcap'
drivers/media/platform/davinci/vpbe.c:127: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_enum_outputs'
drivers/media/platform/davinci/vpbe.c:127: warning: Function parameter or 
member 'output' not described in 'vpbe_enum_outputs'
drivers/media/platform/davinci/vpbe.c:221: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_set_output'
drivers/media/platform/davinci/vpbe.c:221: warning: Function parameter or 
member 'index' not described in 'vpbe_set_output'
drivers/media/platform/davinci/vpbe.c:316: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_get_output'
drivers/media/platform/davinci/vpbe.c:328: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_s_dv_timings'
drivers/media/platform/davinci/vpbe.c:328: warning: Function parameter or 
member 'dv_timings' not described in 'vpbe_s_dv_timings'
drivers/media/platform/davinci/vpbe.c:380: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_g_dv_timings'
drivers/media/platform/davinci/vpbe.c:380: warning: Function parameter or 
member 'dv_timings' not described in 'vpbe_g_dv_timings'
drivers/media/platform/davinci/vpbe.c:405: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_enum_dv_timings'
drivers/media/platform/davinci/vpbe.c:405: warning: Function parameter or 
member 'timings' not described in 'vpbe_enum_dv_timings'
drivers/media/platform/davinci/vpbe.c:436: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_s_std'
drivers/media/platform/davinci/vpbe.c:436: warning: Function parameter or 
member 'std_id' not described in 'vpbe_s_std'
drivers/media/platform/davinci/vpbe.c:475: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_g_std'
drivers/media/platform/davinci/vpbe.c:475: warning: Function parameter or 
member 'std_id' not described in 'vpbe_g_std'
drivers/media/platform/davinci/vpbe.c:500: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_set_mode'
drivers/media/platform/davinci/vpbe.c:500: warning: Function parameter or 
member 'mode_info' not described in 'vpbe_set_mode'
drivers/media/platform/davinci/vpbe.c:585: warning: Function parameter or 
member 'dev' not described in 'vpbe_initialize'
drivers/media/platform/davinci/vpbe.c:585: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_initialize'
drivers/media/platform/davinci/vpbe.c:779: warning: Function parameter or 
member 'dev' not described in 'vpbe_deinitialize'
drivers/media/platform/davinci/vpbe.c:779: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_deinitialize'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter 
or member 'sd' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter 
or member 'field_inversion' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter 
or member 'fb_base_phys' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter 
or member 'lconfig' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter 
or member 'sd' not described in 'try_layer_config'
drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter 
or member 'layer' not described in 'try_layer_config'
drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter 
or member 'lconfig' not described in 'try_layer_config'
drivers/media/platform/davinci/vpbe_display.c:578: warning: Function 
parameter or member 'disp_dev' not described in 'vpbe_try_format'
drivers/media/platform/davinci/vpbe_display.c:578: warning: Function 
parameter or member 'pixfmt' not described in 'vpbe_try_format'
drivers/media/platform/davinci/vpbe_display.c:578: warning: Function 
parameter or member 'check' not described in 'vpbe_try_format'
drivers/media/platform/davinci/vpbe_display.c:943: warning: Function 
parameter 

[PATCH v2 18/19] media: si470x: allow build both USB and I2C at the same time

[Mauro Carvalho Chehab]

Currently, either USB or I2C is built. Change it to allow
having both enabled at the same time.

The main reason is that COMPILE_TEST all[yes/mod]builds will
now contain all drivers under drivers/media.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/radio/Kconfig  |  4 --
 drivers/media/radio/si470x/Kconfig   | 16 ++-
 drivers/media/radio/si470x/Makefile  |  8 ++--
 drivers/media/radio/si470x/radio-si470x-common.c | 61 +---
 drivers/media/radio/si470x/radio-si470x-i2c.c| 18 ---
 drivers/media/radio/si470x/radio-si470x-usb.c| 18 ---
 drivers/media/radio/si470x/radio-si470x.h| 15 +++---
 7 files changed, 95 insertions(+), 45 deletions(-)

diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 192f36f2f4aa..2ed539f9eb87 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -15,10 +15,6 @@ if RADIO_ADAPTERS && VIDEO_V4L2
 config RADIO_TEA575X
tristate
 
-config RADIO_SI470X
-   bool "Silicon Labs Si470x FM Radio Receiver support"
-   depends on VIDEO_V4L2
-
 source "drivers/media/radio/si470x/Kconfig"
 
 config RADIO_SI4713
diff --git a/drivers/media/radio/si470x/Kconfig 
b/drivers/media/radio/si470x/Kconfig
index a466654ee5c9..a21172e413a9 100644
--- a/drivers/media/radio/si470x/Kconfig
+++ b/drivers/media/radio/si470x/Kconfig
@@ -1,3 +1,17 @@
+config RADIO_SI470X
+tristate "Silicon Labs Si470x FM Radio Receiver support"
+depends on VIDEO_V4L2
+   ---help---
+ This is a driver for devices with the Silicon Labs SI470x
+ chip (either via USB or I2C buses).
+
+ Say Y here if you want to connect this type of radio to your
+ computer's USB port or if it is used by some other driver
+ via I2C bus.
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-si470x-common.
+
 config USB_SI470X
tristate "Silicon Labs Si470x FM Radio Receiver support with USB"
depends on USB && RADIO_SI470X
@@ -25,7 +39,7 @@ config USB_SI470X
 
 config I2C_SI470X
tristate "Silicon Labs Si470x FM Radio Receiver support with I2C"
-   depends on I2C && RADIO_SI470X && !USB_SI470X
+   depends on I2C && RADIO_SI470X
---help---
  This is a driver for I2C devices with the Silicon Labs SI470x
  chip.
diff --git a/drivers/media/radio/si470x/Makefile 
b/drivers/media/radio/si470x/Makefile
index 06964816cfd6..563500823e04 100644
--- a/drivers/media/radio/si470x/Makefile
+++ b/drivers/media/radio/si470x/Makefile
@@ -2,8 +2,6 @@
 # Makefile for radios with Silicon Labs Si470x FM Radio Receivers
 #
 
-radio-usb-si470x-objs  := radio-si470x-usb.o radio-si470x-common.o
-radio-i2c-si470x-objs  := radio-si470x-i2c.o radio-si470x-common.o
-
-obj-$(CONFIG_USB_SI470X) += radio-usb-si470x.o
-obj-$(CONFIG_I2C_SI470X) += radio-i2c-si470x.o
+obj-$(CONFIG_RADIO_SI470X) := radio-si470x-common.o
+obj-$(CONFIG_USB_SI470X) += radio-si470x-usb.o
+obj-$(CONFIG_I2C_SI470X) += radio-si470x-i2c.o
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c 
b/drivers/media/radio/si470x/radio-si470x-common.c
index b94d66e53d4e..23bc50260b85 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -195,7 +195,7 @@ static int si470x_set_band(struct si470x_device *radio, int 
band)
radio->band = band;
radio->registers[SYSCONFIG2] &= ~SYSCONFIG2_BAND;
radio->registers[SYSCONFIG2] |= radio->band << 6;
-   return si470x_set_register(radio, SYSCONFIG2);
+   return radio->set_register(radio, SYSCONFIG2);
 }
 
 /*
@@ -207,7 +207,7 @@ static int si470x_set_chan(struct si470x_device *radio, 
unsigned short chan)
unsigned long time_left;
bool timed_out = false;
 
-   retval = si470x_get_register(radio, POWERCFG);
+   retval = radio->get_register(radio, POWERCFG);
if (retval)
return retval;
 
@@ -219,7 +219,7 @@ static int si470x_set_chan(struct si470x_device *radio, 
unsigned short chan)
/* start tuning */
radio->registers[CHANNEL] &= ~CHANNEL_CHAN;
radio->registers[CHANNEL] |= CHANNEL_TUNE | chan;
-   retval = si470x_set_register(radio, CHANNEL);
+   retval = radio->set_register(radio, CHANNEL);
if (retval < 0)
goto done;
 
@@ -238,7 +238,7 @@ static int si470x_set_chan(struct si470x_device *radio, 
unsigned short chan)
 
/* stop tuning */
radio->registers[CHANNEL] &= ~CHANNEL_TUNE;
-   retval = si470x_set_register(radio, CHANNEL);
+   retval = radio->set_register(radio, CHANNEL);
 
 done:
return retval;
@@ -272,7 +272,7 @@ static int si470x_get_freq(struct si470x_device *radio, 
unsigned int *freq)
int chan, retval;
 
/* read channel */
-   retval = si470x_get_register(radio, READCHAN);

Re: [RfC PATCH] Add udmabuf misc device

[Daniel Vetter]

Pulling this out of the shadows again.

We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff
from Matt and Dongwong.

At least from the intel side there seems to be the idea to just have 1
special device that can handle cross-gues/host sharing for all kinds
of hypervisors, so I guess you all need to work together :-)

Or we throw out the idea that hyper dmabuf will be cross-hypervisor
(not sure how useful/reasonable that is, someone please convince me
one way or the other).

Cheers, Daniel

On Wed, Mar 14, 2018 at 9:03 AM, Gerd Hoffmann  wrote:
>   Hi,
>
>> Either mlock account (because it's mlocked defacto), and get_user_pages
>> won't do that for you.
>>
>> Or you write the full-blown userptr implementation, including mmu_notifier
>> support (see i915 or amdgpu), but that also requires Christian Königs
>> latest ->invalidate_mapping RFC for dma-buf (since atm exporting userptr
>> buffers is a no-go).
>
> I guess I'll look at mlock accounting for starters then.  Easier for
> now, and leaves the door open to switch to userptr later as this should
> be transparent to userspace.
>
>> > Known issue:  Driver API isn't complete yet.  Need add some flags, for
>> > example to support read-only buffers.
>>
>> dma-buf has no concept of read-only. I don't think we can even enforce
>> that (not many iommus can enforce this iirc), so pretty much need to
>> require r/w memory.
>
> Ah, ok.  Just saw the 'write' arg for get_user_pages_fast and figured we
> might support that, but if iommus can't handle that anyway it's
> pointless indeed.
>
>> > Cc: David Airlie 
>> > Cc: Tomeu Vizoso 
>> > Signed-off-by: Gerd Hoffmann 
>>
>> btw there's also the hyperdmabuf stuff from the xen folks, but imo their
>> solution of forwarding the entire dma-buf api is over the top. This here
>> looks _much_ better, pls cc all the hyperdmabuf people on your next
>> version.
>
> Fun fact: googling for "hyperdmabuf" found me your mail and nothing else :-o
> (Trying "hyper dmabuf" instead worked better then).
>
> Yes, will cc them on the next version.  Not sure it'll help much on xen
> though due to the memory management being very different.  Basically xen
> owns the memory, not the kernel of the control domain (dom0), so
> creating dmabufs for guest memory chunks isn't that simple ...
>
> Also it's not clear whenever they really need guest -> guest exports or
> guest -> dom0 exports.
>
>> Overall I like the idea, but too lazy to review.
>
> Cool.  General comments on the idea was all I was looking for for the
> moment.  Spare yor review cycles for the next version ;)
>
>> Oh, some kselftests for this stuff would be lovely.
>
> I'll look into it.
>
> thanks,
>   Gerd
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2 07/19] media: exymos4-is: allow compile test for EXYNOS FIMC-LITE

[Mauro Carvalho Chehab]

There's nothing that prevents building this driver with
COMPILE_TEST. So, enable it.

While here, make the Kconfig dependency cleaner by removing
the unneeded if block.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/exynos4-is/Kconfig | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index 7b2c49e5a592..c8e5ad8f8294 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -41,11 +41,10 @@ config VIDEO_S5P_MIPI_CSIS
  To compile this driver as a module, choose M here: the
  module will be called s5p-csis.
 
-if SOC_EXYNOS4412 || SOC_EXYNOS5250
-
 config VIDEO_EXYNOS_FIMC_LITE
tristate "EXYNOS FIMC-LITE camera interface driver"
depends on I2C
+   depends on SOC_EXYNOS4412 || SOC_EXYNOS5250 || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select VIDEO_EXYNOS4_IS_COMMON
@@ -55,7 +54,6 @@ config VIDEO_EXYNOS_FIMC_LITE
 
  To compile this driver as a module, choose M here: the
  module will be called exynos-fimc-lite.
-endif
 
 config VIDEO_EXYNOS4_FIMC_IS
tristate "EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver"
-- 
2.14.3

[PATCH v2 05/19] media: fsl-viu: allow building it with COMPILE_TEST

[Mauro Carvalho Chehab]

There aren't many things that would be needed to allow it
to build with compile test.

Add the needed bits.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/Kconfig   | 2 +-
 drivers/media/platform/fsl-viu.c | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 03c9dfeb7781..e6eb1eb776e1 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -42,7 +42,7 @@ config VIDEO_SH_VOU
 
 config VIDEO_VIU
tristate "Freescale VIU Video Driver"
-   depends on VIDEO_V4L2 && PPC_MPC512x
+   depends on VIDEO_V4L2 && (PPC_MPC512x || COMPILE_TEST)
select VIDEOBUF_DMA_CONTIG
default y
---help---
diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 9abe79779659..466053e00378 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -36,6 +36,14 @@
 #define DRV_NAME   "fsl_viu"
 #define VIU_VERSION"0.5.1"
 
+/* Allow building this driver with COMPILE_TEST */
+#ifndef CONFIG_PPC_MPC512x
+#define NO_IRQ   0
+
+#define out_be32(v, a) writel(a, v)
+#define in_be32(a) readl(a)
+#endif
+
 #define BUFFER_TIMEOUT msecs_to_jiffies(500)  /* 0.5 seconds */
 
 #defineVIU_VID_MEM_LIMIT   4   /* Video memory limit, in Mb */
-- 
2.14.3

[PATCH v2 15/19] omap2: omapfb: allow building it with COMPILE_TEST

[Mauro Carvalho Chehab]

This driver builds cleanly with COMPILE_TEST, and it is
needed in order to allow building drivers/media omap2
driver.

So, change the logic there to allow building it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/video/fbdev/omap2/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/Kconfig 
b/drivers/video/fbdev/omap2/Kconfig
index 0921c4de8407..82008699d253 100644
--- a/drivers/video/fbdev/omap2/Kconfig
+++ b/drivers/video/fbdev/omap2/Kconfig
@@ -1,4 +1,4 @@
-if ARCH_OMAP2PLUS
+if ARCH_OMAP2PLUS || COMPILE_TEST
 
 source "drivers/video/fbdev/omap2/omapfb/Kconfig"
 
-- 
2.14.3

[PATCH v2 11/19] media: davinci: allow building isif code

[Mauro Carvalho Chehab]

The only reason why this driver doesn't build with COMPILE_TEST
is because it includes mach/mux.h. It turns that none of the
macros defined there are used.

So, get rid of it, in order to allow it to build with
COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/davinci/Kconfig | 3 ++-
 drivers/media/platform/davinci/isif.c  | 2 --
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/davinci/Kconfig 
b/drivers/media/platform/davinci/Kconfig
index 55982e681d77..babdb4877b3f 100644
--- a/drivers/media/platform/davinci/Kconfig
+++ b/drivers/media/platform/davinci/Kconfig
@@ -67,7 +67,8 @@ config VIDEO_DM355_CCDC
 
 config VIDEO_DM365_ISIF
tristate "TI DM365 ISIF video capture driver"
-   depends on VIDEO_V4L2 && ARCH_DAVINCI
+   depends on VIDEO_V4L2
+   depends on ARCH_DAVINCI || COMPILE_TEST
depends on HAS_DMA
depends on I2C
select VIDEOBUF_DMA_CONTIG
diff --git a/drivers/media/platform/davinci/isif.c 
b/drivers/media/platform/davinci/isif.c
index d5ff58494c1e..b14caadcd0df 100644
--- a/drivers/media/platform/davinci/isif.c
+++ b/drivers/media/platform/davinci/isif.c
@@ -31,8 +31,6 @@
 #include 
 #include 
 
-#include 
-
 #include 
 #include 
 
-- 
2.14.3

[PATCH v2 06/19] media: cec_gpio: allow building CEC_GPIO with COMPILE_TEST

[Mauro Carvalho Chehab]

At least on i386, building with allyesconfig doesn't enable
PREEMPT, causing cec_gpio to not build.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index e6eb1eb776e1..e8d8bbc976af 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -558,7 +558,7 @@ config VIDEO_MESON_AO_CEC
 
 config CEC_GPIO
tristate "Generic GPIO-based CEC driver"
-   depends on PREEMPT
+   depends on PREEMPT || COMPILE_TEST
select CEC_CORE
select CEC_PIN
select GPIOLIB
-- 
2.14.3

[PATCH v2 00/19] Make all media drivers build with COMPILE_TEST

[Mauro Carvalho Chehab]

The current media policy has been for a while to only accept new drivers 
that compile with COMPILE_TEST.

However, there are still several drivers under that  doesn't build
with COMPILE_TEST.

So, this series makes the existing ones also compatible with it.

Not building with COMPILE_TEST is a bad thing, for several reasons.

The main ones is that:

1) the licence the Kernel community has for Coverity only builds for 
   x86. So, drivers that don't build on such archtecture were likely 
   never tested by it.

2) That affects my per-patch handling process, with should be quick 
   enough to not delay my patch handling process. So, I only build for one 
   architecture (i386).

3) When appliying a patch, I always run two static code analyzers (W=1, 
   smatch and sparse). Those drivers weren't checked by me. At the end 
   of the day, that leads to a lower quality check for the drivers that 
   don't build on i386.

There are two situations on this patch series that proof the lower 
quality of those drivers:

- There is a case of a driver that was added broken in 2013. Only two 
  years later, someone noticed and "fixed" it by markin it as BROKEN!

- 5 patches in this series (about 1/3) are just to fix build issues on 
  those drivers, most of them due to gcc warnings.

With this patch series, all "config FOO" and "menuconfig FOO"
symbols under media will be built with allyes config.

Tested with:
$ make ARCH=i386 allyesconfig
$ for i in  $(grep "config " $(find drivers/staging/media/ -name 
Kconfig) $(find drivers/media/ -name Kconfig) |grep -v "\#.*Kconfig"|cut -d' ' 
-f 2) ; do if [ "$(grep $i .config)" == "" ]; then echo $i; fi;done

v2:

- did some changes as per Laurent's feedback from the past series;
- added a patch to compile both si470x drivers at the same time;
- added patches to also build all media staging drivers.

I opted to preserve patch 03/16 (omap3isp build) as I don't see
any strong reason why this driver should not be allowed to
build with COMPILE_TEST.

Mauro Carvalho Chehab (19):
  omap: omap-iommu.h: allow building drivers with COMPILE_TEST
  media: omap3isp: allow it to build with COMPILE_TEST
  media: omap3isp/isp: remove an unused static var
  media: fsl-viu: mark static functions as such
  media: fsl-viu: allow building it with COMPILE_TEST
  media: cec_gpio: allow building CEC_GPIO with COMPILE_TEST
  media: exymos4-is: allow compile test for EXYNOS FIMC-LITE
  media: mmp-camera.h: add missing platform data
  media: marvel-ccic: re-enable mmp-driver build
  media: mmp-driver: make two functions static
  media: davinci: allow building isif code
  media: davinci: allow build vpbe_display with COMPILE_TEST
  media: vpbe_venc: don't store return codes if they won't be used
  media: davinci: get rid of lots of kernel-doc warnings
  omap2: omapfb: allow building it with COMPILE_TEST
  media: omap: allow building it with COMPILE_TEST
  media: omap4iss: make it build with COMPILE_TEST
  media: si470x: allow build both USB and I2C at the same time
  media: staging: davinci_vpfe: allow building with COMPILE_TEST

 drivers/media/platform/Kconfig   | 12 ++---
 drivers/media/platform/davinci/Kconfig   |  6 ++-
 drivers/media/platform/davinci/isif.c|  2 -
 drivers/media/platform/davinci/vpbe.c| 38 ---
 drivers/media/platform/davinci/vpbe_display.c| 21 
 drivers/media/platform/davinci/vpbe_osd.c| 16 ---
 drivers/media/platform/davinci/vpbe_venc.c   |  9 ++--
 drivers/media/platform/exynos4-is/Kconfig|  4 +-
 drivers/media/platform/fsl-viu.c | 20 +---
 drivers/media/platform/marvell-ccic/Kconfig  |  5 +-
 drivers/media/platform/marvell-ccic/mmp-driver.c |  4 +-
 drivers/media/platform/omap/Kconfig  |  8 ++--
 drivers/media/platform/omap3isp/isp.c| 14 +++---
 drivers/media/radio/Kconfig  |  4 --
 drivers/media/radio/si470x/Kconfig   | 16 ++-
 drivers/media/radio/si470x/Makefile  |  8 ++--
 drivers/media/radio/si470x/radio-si470x-common.c | 61 +---
 drivers/media/radio/si470x/radio-si470x-i2c.c| 18 ---
 drivers/media/radio/si470x/radio-si470x-usb.c| 18 ---
 drivers/media/radio/si470x/radio-si470x.h| 15 +++---
 drivers/staging/media/davinci_vpfe/Kconfig   |  3 +-
 drivers/staging/media/davinci_vpfe/Makefile  |  5 ++
 drivers/staging/media/davinci_vpfe/TODO  |  1 +
 drivers/staging/media/omap4iss/Kconfig   |  3 +-
 drivers/video/fbdev/omap2/Kconfig|  2 +-
 include/linux/omap-iommu.h   |  5 ++
 include/linux/platform_data/media/mmp-camera.h   | 19 
 27 files changed, 217 insertions(+), 120 deletions(-)

-- 
2.14.3

[PATCH v2 01/19] omap: omap-iommu.h: allow building drivers with COMPILE_TEST

[Mauro Carvalho Chehab]

Drivers that depend on omap-iommu.h (currently, just omap3isp)
need a stub implementation in order to be built with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/linux/omap-iommu.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/omap-iommu.h b/include/linux/omap-iommu.h
index c1aede46718b..0c21fc5b002e 100644
--- a/include/linux/omap-iommu.h
+++ b/include/linux/omap-iommu.h
@@ -13,7 +13,12 @@
 #ifndef _OMAP_IOMMU_H_
 #define _OMAP_IOMMU_H_
 
+#ifdef CONFIG_OMAP_IOMMU
 extern void omap_iommu_save_ctx(struct device *dev);
 extern void omap_iommu_restore_ctx(struct device *dev);
+#else
+static inline void omap_iommu_save_ctx(struct device *dev) {};
+static inline void omap_iommu_restore_ctx(struct device *dev) {};
+#endif
 
 #endif
-- 
2.14.3

Re: [PATCH 02/16] media: omap3isp: allow it to build with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Thu, 05 Apr 2018 21:30:27 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> Thank you for the patch.
> 
> On Thursday, 5 April 2018 20:54:02 EEST Mauro Carvalho Chehab wrote:
> > There aren't much things required for it to build with COMPILE_TEST.
> > It just needs to provide stub for an arm-dependent include.
> > 
> > Let's replicate the same solution used by ipmmu-vmsa, in order
> > to allow building omap3 with COMPILE_TEST.
> > 
> > The actual logic here came from this driver:
> > 
> >drivers/iommu/ipmmu-vmsa.c
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/platform/Kconfig| 8 
> >  drivers/media/platform/omap3isp/isp.c | 7 +++
> >  2 files changed, 11 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index c7a1cf8a1b01..03c9dfeb7781 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -62,12 +62,12 @@ config VIDEO_MUX
> > 
> >  config VIDEO_OMAP3
> > tristate "OMAP 3 Camera support"
> > -   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> > +   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
> > depends on HAS_DMA && OF
> > -   depends on OMAP_IOMMU
> > -   select ARM_DMA_USE_IOMMU
> > +   depends on ((ARCH_OMAP3 && OMAP_IOMMU) || COMPILE_TEST)
> > +   select ARM_DMA_USE_IOMMU if OMAP_IOMMU
> > select VIDEOBUF2_DMA_CONTIG
> > -   select MFD_SYSCON
> > +   select MFD_SYSCON if ARCH_OMAP3
> > select V4L2_FWNODE
> > ---help---
> >   Driver for an OMAP 3 camera controller.
> > diff --git a/drivers/media/platform/omap3isp/isp.c
> > b/drivers/media/platform/omap3isp/isp.c index 8eb000e3d8fd..2a11a709aa4f
> > 100644
> > --- a/drivers/media/platform/omap3isp/isp.c
> > +++ b/drivers/media/platform/omap3isp/isp.c
> > @@ -61,7 +61,14 @@
> >  #include 
> >  #include 
> > 
> > +#if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
> >  #include 
> > +#else
> > +#define arm_iommu_create_mapping(...)  NULL
> > +#define arm_iommu_attach_device(...)   -ENODEV
> > +#define arm_iommu_release_mapping(...) do {} while (0)
> > +#define arm_iommu_detach_device(...)   do {} while (0)
> > +#endif  
> 
> I don't think it's the job of a driver to define those stubs, sorry. 
> Otherwise 
> where do you stop ? If you have half of the code that is architecture-
> dependent, would you stub it ? And what if the stubs you define here generate 
> warnings in static analyzers ?

I agree that we should avoid doing that as a general case, but see
below.

> If you want to make drivers compile for all architectures, the APIs they use 
> must be defined in linux/, not in asm/. They can be stubbed there when not 
> implemented in a particular architecture, but not in the driver.

In this specific case, the same approach taken here is already needed
by the Renesas VMSA-compatible IPMMU driver, with, btw, is inside 
drivers/iommu:

drivers/iommu/ipmmu-vmsa.c

Also, this API is used only by 3 drivers [1]:

drivers/iommu/ipmmu-vmsa.c
drivers/iommu/mtk_iommu_v1.c
drivers/media/platform/omap3isp/isp.c

[1] as blamed by 
git grep -l arm_iommu_create_mapping

That hardly seems to be an arch-specific iommu solution, but, instead, some
hack used by only three drivers or some legacy iommu binding.

The omap3isp is, btw, the only driver outside drivers/iommu that needs it.

So, it sounds that other driver uses some other approach, but hardly
it would be worth to change this driver to use something else.

So, better to stick with the same solution the Renesas driver used.

Thanks,
Mauro

Re: [PATCH v6 2/2] media: video-i2c: add video-i2c driver

[Matt Ranostay]

On Thu, Apr 5, 2018 at 12:39 AM, Sakari Ailus  wrote:
> Hi Matt,
>
> Thanks for the patch. It's a very nicely written, small driver. :-)
>
> Please see more comments below.
>
> On Sat, Mar 31, 2018 at 05:59:26PM -0700, Matt Ranostay wrote:
>> There are several thermal sensors that only have a low-speed bus
>> interface but output valid video data. This patchset enables support
>> for the AMG88xx "Grid-Eye" sensor family.
>>
>> Signed-off-by: Matt Ranostay 
>
> Are there plans to implement support for more of these chips?
>

Nothing on my end. But there are other low resolution thermal cameras
that output i2c that could easily be added.

>> ---
>>  MAINTAINERS   |   6 +
>>  drivers/media/i2c/Kconfig |   9 +
>>  drivers/media/i2c/Makefile|   1 +
>>  drivers/media/i2c/video-i2c.c | 562 
>> ++
>>  4 files changed, 578 insertions(+)
>>  create mode 100644 drivers/media/i2c/video-i2c.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 49236216a871..f0262b751d5b 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -14863,6 +14863,12 @@ L:   linux-media@vger.kernel.org
>>  S:   Maintained
>>  F:   drivers/media/platform/video-mux.c
>>
>> +VIDEO I2C POLLING DRIVER
>> +M:   Matt Ranostay 
>> +L:   linux-media@vger.kernel.org
>> +S:   Maintained
>> +F:   drivers/media/i2c/video-i2c.c
>> +
>>  VIDEOBUF2 FRAMEWORK
>>  M:   Pawel Osciak 
>>  M:   Marek Szyprowski 
>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>> index 541f0d28afd8..122e5047a01e 100644
>> --- a/drivers/media/i2c/Kconfig
>> +++ b/drivers/media/i2c/Kconfig
>> @@ -974,6 +974,15 @@ config VIDEO_M52790
>>
>>To compile this driver as a module, choose M here: the
>>module will be called m52790.
>> +
>> +config VIDEO_I2C
>> + tristate "I2C transport video support"
>> + depends on VIDEO_V4L2 && I2C
>> + select VIDEOBUF2_VMALLOC
>> + ---help---
>> +   Enable the I2C transport video support which supports the
>> +   following:
>> +* Panasonic AMG88xx Grid-Eye Sensors
>
> You could add the name of the module here if it's compiled as a module.
>

Ok

>>  endmenu
>>
>>  menu "Sensors used on soc_camera driver"
>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>> index ea34aee1a85a..84cc472238ef 100644
>> --- a/drivers/media/i2c/Makefile
>> +++ b/drivers/media/i2c/Makefile
>> @@ -96,6 +96,7 @@ obj-$(CONFIG_VIDEO_LM3646)  += lm3646.o
>>  obj-$(CONFIG_VIDEO_SMIAPP_PLL)   += smiapp-pll.o
>>  obj-$(CONFIG_VIDEO_AK881X)   += ak881x.o
>>  obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
>> +obj-$(CONFIG_VIDEO_I2C)  += video-i2c.o
>>  obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
>>  obj-$(CONFIG_VIDEO_OV2659)   += ov2659.o
>>  obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
>> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
>> new file mode 100644
>> index ..9fba8a2767c5
>> --- /dev/null
>> +++ b/drivers/media/i2c/video-i2c.c
>> @@ -0,0 +1,562 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * video-i2c.c - Support for I2C transport video devices
>> + *
>> + * Copyright (C) 2018 Matt Ranostay 
>> + *
>> + * Supported:
>> + * - Panasonic AMG88xx Grid-Eye Sensors
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define VIDEO_I2C_DRIVER "video-i2c"
>> +
>> +struct video_i2c_chip;
>> +
>> +struct video_i2c_buffer {
>> + struct vb2_v4l2_buffer vb;
>> + struct list_head list;
>> +};
>> +
>> +struct video_i2c_data {
>> + struct i2c_client *client;
>> + const struct video_i2c_chip *chip;
>> + struct mutex lock;
>> + spinlock_t slock;
>> + unsigned int sequence;
>> + struct mutex queue_lock;
>> +
>> + struct v4l2_device v4l2_dev;
>> + struct video_device vdev;
>> + struct vb2_queue vb_vidq;
>> +
>> + struct task_struct *kthread_vid_cap;
>> + struct list_head vid_cap_active;
>> +};
>> +
>> +static struct v4l2_fmtdesc amg88xx_format = {
>> + .pixelformat = V4L2_PIX_FMT_Y12,
>> +};
>> +
>> +static struct v4l2_frmsize_discrete amg88xx_size = {
>> + .width = 8,
>> + .height = 8,
>> +};
>> +
>> +struct video_i2c_chip {
>> + /* video dimensions */
>> + const struct v4l2_fmtdesc *format;
>> + const struct v4l2_frmsize_discrete *size;
>> +
>> + /* max frames per second */
>> + unsigned int max_fps;
>> +
>> + /* pixel buffer size */
>> + unsigned int buffer_size;
>> +
>> + /* pixel size in bits */
>> + unsigned int bpp;
>> +
>> + /* xfer function */
>> + int (*xfer)(struct video_i2c_data 

Re: [PATCH 15/16] media: omapfb_dss.h: add stubs to build with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Thu, 05 Apr 2018 21:41:18 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> Thank you for the patch.
> 
> On Thursday, 5 April 2018 20:54:15 EEST Mauro Carvalho Chehab wrote:
> > Add stubs for omapfb_dss.h, in the case it is included by
> > some driver when CONFIG_FB_OMAP2 is not defined.  
> 
> The omapfb driver doesn't include any asm/ header, so it should probably 
> build 
> fine on non-ARM architectures. Instead of adding stubs here, you can enable 
> compilation of the driver on all platforms, in which case the omap_vout 
> driver 
> could keep depending on FB_OMAP2 as it should.

True. The patch for that is simple. 

Patch enclosed. Please notice that, now with W=1, several new warnings
will popup. I'll let to the others to touch there, as I don't have any
clue about what's there under omapfb.

Those are the new warnings:

drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function 
‘omapfb_setup_overlay’:
drivers/video/fbdev/omap2/omapfb/omapfb-main.c:891:6: warning: this statement 
may fall through [-Wimplicit-fallthrough=]
   if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
  ^
drivers/video/fbdev/omap2/omapfb/omapfb-main.c:896:2: note: here
  default:
  ^~~
drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c: In function 
‘tpd_probe’:
drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c:221:26: warning: 
variable ‘in’ set but not used [-Wunused-but-set-variable]
  struct omap_dss_device *in, *dssdev;
  ^~
drivers/video/fbdev/omap2/omapfb/dss/dispc.c: In function 
‘calc_vrfb_rotation_offset’:
drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1905:6: warning: this statement 
may fall through [-Wimplicit-fallthrough=]
   if (color_mode == OMAP_DSS_COLOR_YUV2 ||
  ^
drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1908:2: note: here
  case OMAP_DSS_ROT_90:
  ^~~~
drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1927:6: warning: this statement 
may fall through [-Wimplicit-fallthrough=]
   if (color_mode == OMAP_DSS_COLOR_YUV2 ||
  ^
drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1930:2: note: here
  case OMAP_DSS_ROT_90 + 4:
  ^~~~
drivers/video/fbdev/omap2/omapfb/dss/venc.c:223:33: warning: 
‘venc_config_pal_bdghi’ defined but not used [-Wunused-const-variable=]
 static const struct venc_config venc_config_pal_bdghi = {
 ^
drivers/video/fbdev/omap2/omapfb/dss/dsi.c: In function 
‘_dsi_print_reset_status’:
drivers/video/fbdev/omap2/omapfb/dss/dsi.c:1189:6: warning: variable ‘l’ set 
but not used [-Wunused-but-set-variable]
  u32 l;
  ^
drivers/video/fbdev/omap2/omapfb/dss/dsi.c: In function ‘dsi_proto_timings’:
drivers/video/fbdev/omap2/omapfb/dss/dsi.c:3638:42: warning: variable 
‘tclk_trail’ set but not used [-Wunused-but-set-variable]
  unsigned tlpx, tclk_zero, tclk_prepare, tclk_trail;
  ^~
drivers/video/fbdev/omap2/omapfb/dss/dsi.c: In function ‘dsi_update’:
drivers/video/fbdev/omap2/omapfb/dss/dsi.c:4051:10: warning: variable ‘dh’ set 
but not used [-Wunused-but-set-variable]
  u16 dw, dh;
  ^~
drivers/video/fbdev/omap2/omapfb/dss/dsi.c:4051:6: warning: variable ‘dw’ set 
but not used [-Wunused-but-set-variable]
  u16 dw, dh;
  ^~
drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c: In function 
‘hdmi4_audio_config’:
drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c:693:6: warning: variable 
‘err’ set but not used [-Wunused-but-set-variable]
  int err, n, cts, channel_count;
  ^~~
drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c: In function 
‘hdmi5_audio_config’:
drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c:804:6: warning: variable 
‘err’ set but not used [-Wunused-but-set-variable]
  int err, n, cts, channel_count;
  ^~~

Thanks,
Mauro

---

[PATCH] omap2: omapfb: allow building it with COMPILE_TEST

This driver builds cleanly with COMPILE_TEST, and it is
needed in order to allow building drivers/media omap2
driver.

So, change the logic there to allow building it.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/video/fbdev/omap2/Kconfig 
b/drivers/video/fbdev/omap2/Kconfig
index 0921c4de8407..82008699d253 100644
--- a/drivers/video/fbdev/omap2/Kconfig
+++ b/drivers/video/fbdev/omap2/Kconfig
@@ -1,4 +1,4 @@
-if ARCH_OMAP2PLUS
+if ARCH_OMAP2PLUS || COMPILE_TEST
 
 source "drivers/video/fbdev/omap2/omapfb/Kconfig"
 

Re: [PATCH 15/16] media: omapfb_dss.h: add stubs to build with COMPILE_TEST

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Thursday, 5 April 2018 20:54:15 EEST Mauro Carvalho Chehab wrote:
> Add stubs for omapfb_dss.h, in the case it is included by
> some driver when CONFIG_FB_OMAP2 is not defined.

The omapfb driver doesn't include any asm/ header, so it should probably build 
fine on non-ARM architectures. Instead of adding stubs here, you can enable 
compilation of the driver on all platforms, in which case the omap_vout driver 
could keep depending on FB_OMAP2 as it should.

> That allows building such driver(s) with COMPILE_TEST.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  include/video/omapfb_dss.h | 54 +--
>  1 file changed, 52 insertions(+), 2 deletions(-)
> 
> diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
> index 1d38901d599d..e9775144ff3b 100644
> --- a/include/video/omapfb_dss.h
> +++ b/include/video/omapfb_dss.h
> @@ -774,6 +774,12 @@ struct omap_dss_driver {
>   const struct hdmi_avi_infoframe *avi);
>  };
> 
> +#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) !=
> NULL) +
> +typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
> +
> +#ifdef CONFIG_FB_OMAP2
> +
>  enum omapdss_version omapdss_get_version(void);
>  bool omapdss_is_initialized(void);
> 
> @@ -785,7 +791,6 @@ void omapdss_unregister_display(struct omap_dss_device
> *dssdev);
> 
>  struct omap_dss_device *omap_dss_get_device(struct omap_dss_device
> *dssdev); void omap_dss_put_device(struct omap_dss_device *dssdev);
> -#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) !=
> NULL) struct omap_dss_device *omap_dss_get_next_device(struct
> omap_dss_device *from); struct omap_dss_device *omap_dss_find_device(void
> *data,
>   int (*match)(struct omap_dss_device *dssdev, void *data));
> @@ -826,7 +831,6 @@ int omapdss_default_get_recommended_bpp(struct
> omap_dss_device *dssdev); void omapdss_default_get_timings(struct
> omap_dss_device *dssdev,
>   struct omap_video_timings *timings);
> 
> -typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
>  int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
>  int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
> 
> @@ -856,5 +860,51 @@ omapdss_of_get_first_endpoint(const struct device_node
> *parent);
> 
>  struct omap_dss_device *
>  omapdss_of_find_source_for_first_ep(struct device_node *node);
> +#else
> +
> +static inline enum omapdss_version omapdss_get_version(void)
> +{ return OMAPDSS_VER_UNKNOWN; };
> +
> +static inline bool omapdss_is_initialized(void)
> +{ return false; };
> +
> +static inline int omap_dispc_register_isr(omap_dispc_isr_t isr,
> +   void *arg, u32 mask)
> +{ return 0; };
> +
> +static inline int omap_dispc_unregister_isr(omap_dispc_isr_t isr,
> + void *arg, u32 mask)
> +{ return 0; };
> +
> +static inline struct omap_dss_device
> +*omap_dss_get_device(struct omap_dss_device *dssdev)
> +{ return NULL; };
> +
> +static inline struct omap_dss_device
> +*omap_dss_get_next_device(struct omap_dss_device *from)
> +{return NULL; };
> +
> +static inline void omap_dss_put_device(struct omap_dss_device *dssdev) {};
> +
> +static inline int omapdss_compat_init(void)
> +{ return 0; };
> +
> +static inline void omapdss_compat_uninit(void) {};
> +
> +static inline int omap_dss_get_num_overlay_managers(void)
> +{ return 0; };
> +
> +static inline struct omap_overlay_manager *omap_dss_get_overlay_manager(int
> num) +{ return NULL; };
> +
> +static inline int omap_dss_get_num_overlays(void)
> +{ return 0; };
> +
> +static inline struct omap_overlay *omap_dss_get_overlay(int num)
> +{ return NULL; };
> +
> +
> +#endif /* FB_OMAP2 */
> +
> 
>  #endif /* __OMAPFB_DSS_H */


-- 
Regards,

Laurent Pinchart

HVR1600 IR Blaster

[Warren Sturm]

Is there a way to get the IR Blaster of the HVR1600 card working under
v4.15+ kernels?

It seems that lrc_zilog BUGs under 4.15+ and has gone missing in 4.16.


Thanks.

Re: [PATCH 03/16] media: omap3isp/isp: remove an unused static var

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Thursday, 5 April 2018 20:54:03 EEST Mauro Carvalho Chehab wrote:
> The isp_xclk_init_data const data isn't used anywere.
> 
> drivers/media/platform/omap3isp/isp.c:294:35: warning: ‘isp_xclk_init_data’
> defined but not used [-Wunused-const-variable=] static const struct
> clk_init_data isp_xclk_init_data = {
>^~

I believe you, no need for a compiler warning message to prove this :-)

> Signed-off-by: Mauro Carvalho Chehab 

I really wonder why my compiler has never warned me. The problem has been 
there from the start :-/

You should add a fixes tag:

Fixes: 9b28ee3c9122 ("[media] omap3isp: Use the common clock framework")

Apart from that,

Reviewed-by: Laurent Pinchart 

I think Sakari is planning a pull request for the omap3isp driver so I'll let 
him handle this patch.

> ---
>  drivers/media/platform/omap3isp/isp.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 2a11a709aa4f..9e4b5fb8a8b5
> 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -291,13 +291,6 @@ static const struct clk_ops isp_xclk_ops = {
> 
>  static const char *isp_xclk_parent_name = "cam_mclk";
> 
> -static const struct clk_init_data isp_xclk_init_data = {
> - .name = "cam_xclk",
> - .ops = _xclk_ops,
> - .parent_names = _xclk_parent_name,
> - .num_parents = 1,
> -};
> -
>  static struct clk *isp_xclk_src_get(struct of_phandle_args *clkspec, void
> *data) {
>   unsigned int idx = clkspec->args[0];

-- 
Regards,

Laurent Pinchart

Re: [PATCH 02/16] media: omap3isp: allow it to build with COMPILE_TEST

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Thursday, 5 April 2018 20:54:02 EEST Mauro Carvalho Chehab wrote:
> There aren't much things required for it to build with COMPILE_TEST.
> It just needs to provide stub for an arm-dependent include.
> 
> Let's replicate the same solution used by ipmmu-vmsa, in order
> to allow building omap3 with COMPILE_TEST.
> 
> The actual logic here came from this driver:
> 
>drivers/iommu/ipmmu-vmsa.c
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/platform/Kconfig| 8 
>  drivers/media/platform/omap3isp/isp.c | 7 +++
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c7a1cf8a1b01..03c9dfeb7781 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -62,12 +62,12 @@ config VIDEO_MUX
> 
>  config VIDEO_OMAP3
>   tristate "OMAP 3 Camera support"
> - depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> + depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
>   depends on HAS_DMA && OF
> - depends on OMAP_IOMMU
> - select ARM_DMA_USE_IOMMU
> + depends on ((ARCH_OMAP3 && OMAP_IOMMU) || COMPILE_TEST)
> + select ARM_DMA_USE_IOMMU if OMAP_IOMMU
>   select VIDEOBUF2_DMA_CONTIG
> - select MFD_SYSCON
> + select MFD_SYSCON if ARCH_OMAP3
>   select V4L2_FWNODE
>   ---help---
> Driver for an OMAP 3 camera controller.
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 8eb000e3d8fd..2a11a709aa4f
> 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -61,7 +61,14 @@
>  #include 
>  #include 
> 
> +#if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
>  #include 
> +#else
> +#define arm_iommu_create_mapping(...)NULL
> +#define arm_iommu_attach_device(...) -ENODEV
> +#define arm_iommu_release_mapping(...)   do {} while (0)
> +#define arm_iommu_detach_device(...) do {} while (0)
> +#endif

I don't think it's the job of a driver to define those stubs, sorry. Otherwise 
where do you stop ? If you have half of the code that is architecture-
dependent, would you stub it ? And what if the stubs you define here generate 
warnings in static analyzers ?

If you want to make drivers compile for all architectures, the APIs they use 
must be defined in linux/, not in asm/. They can be stubbed there when not 
implemented in a particular architecture, but not in the driver.

>  #include 
>  #include 

-- 
Regards,

Laurent Pinchart

Re: [PATCH 16/16] media: omap: allow building it with COMPILE_TEST

[Mauro Carvalho Chehab]

Em Thu,  5 Apr 2018 13:54:16 -0400
Mauro Carvalho Chehab  escreveu:

> Now that we have stubs for omap FB driver, let it build with
> COMPILE_TEST.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/platform/omap/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/omap/Kconfig 
> b/drivers/media/platform/omap/Kconfig
> index e8e2db181a7a..e6b486c5ddfc 100644
> --- a/drivers/media/platform/omap/Kconfig
> +++ b/drivers/media/platform/omap/Kconfig
> @@ -4,11 +4,11 @@ config VIDEO_OMAP2_VOUT_VRFB
>  config VIDEO_OMAP2_VOUT
>   tristate "OMAP2/OMAP3 V4L2-Display driver"
>   depends on MMU
> - depends on ARCH_OMAP2 || ARCH_OMAP3
> - depends on FB_OMAP2
> + depends on ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST
> + depends on FB_OMAP2 || COMPILE_TEST
>   select VIDEOBUF_GEN
>   select VIDEOBUF_DMA_CONTIG
> - select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
> + select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST
>   select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT && OMAP2_VRFB
>   select FRAME_VECTOR
>   default n

This actually produces a warning:

WARNING: unmet direct dependencies detected for OMAP2_VRFB
  Depends on [n]: HAS_IOMEM [=y] && ARCH_OMAP2PLUS
  Selected by [y]:
  - VIDEO_OMAP2_VOUT [=y] && MEDIA_SUPPORT [=y] && V4L_PLATFORM_DRIVERS [=y] && 
MMU [=y] && (FB_OMAP2 [=n] || COMPILE_TEST [=y]) && (ARCH_OMAP2 || ARCH_OMAP3 
|| COMPILE_TEST [=y])


I'm folding this one with the enclosed change:


diff --git a/drivers/media/platform/omap/Kconfig 
b/drivers/media/platform/omap/Kconfig
index e6b486c5ddfc..ff051958d675 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -4,11 +4,10 @@ config VIDEO_OMAP2_VOUT_VRFB
 config VIDEO_OMAP2_VOUT
tristate "OMAP2/OMAP3 V4L2-Display driver"
depends on MMU
-   depends on ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST
-   depends on FB_OMAP2 || COMPILE_TEST
+   depends on ((ARCH_OMAP2 || ARCH_OMAP3) && FB_OMAP2) || COMPILE_TEST
select VIDEOBUF_GEN
select VIDEOBUF_DMA_CONTIG
-   select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST
+   select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT && OMAP2_VRFB
select FRAME_VECTOR
default n



Thanks,
Mauro

[PATCH 04/16] media: fsl-viu: mark static functions as such

[Mauro Carvalho Chehab]

There are several functions that are used only inside the
driver. Stop exposing that to global symbolspace.

Get rid of the following gcc warnings:

drivers/media/platform/fsl-viu.c:240:17: warning: no previous prototype for 
‘format_by_fourcc’ [-Wmissing-prototypes]
 struct viu_fmt *format_by_fourcc(int fourcc)
 ^~~~
drivers/media/platform/fsl-viu.c:253:6: warning: no previous prototype for 
‘viu_start_dma’ [-Wmissing-prototypes]
 void viu_start_dma(struct viu_dev *dev)
  ^
drivers/media/platform/fsl-viu.c:262:6: warning: no previous prototype for 
‘viu_stop_dma’ [-Wmissing-prototypes]
 void viu_stop_dma(struct viu_dev *dev)
  ^~~~
drivers/media/platform/fsl-viu.c:807:5: warning: no previous prototype for 
‘vidioc_g_fbuf’ [-Wmissing-prototypes]
 int vidioc_g_fbuf(struct file *file, void *priv, struct v4l2_framebuffer *arg)
 ^
drivers/media/platform/fsl-viu.c:818:5: warning: no previous prototype for 
‘vidioc_s_fbuf’ [-Wmissing-prototypes]
 int vidioc_s_fbuf(struct file *file, void *priv, const struct v4l2_framebuffer 
*arg)
 ^
drivers/media/platform/fsl-viu.c: In function ‘viu_open’:
drivers/media/platform/fsl-viu.c:1170:6: warning: variable ‘status_cfg’ set but 
not used [-Wunused-but-set-variable]
  u32 status_cfg;
  ^~
drivers/media/platform/fsl-viu.c: At top level:
drivers/media/platform/fsl-viu.c:1304:6: warning: no previous prototype for 
‘viu_reset’ [-Wmissing-prototypes]
 void viu_reset(struct viu_reg *reg)
  ^

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/fsl-viu.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 200c47c69a75..9abe79779659 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -229,7 +229,7 @@ enum status_config {
 
 static irqreturn_t viu_intr(int irq, void *dev_id);
 
-struct viu_fmt *format_by_fourcc(int fourcc)
+static struct viu_fmt *format_by_fourcc(int fourcc)
 {
int i;
 
@@ -242,7 +242,7 @@ struct viu_fmt *format_by_fourcc(int fourcc)
return NULL;
 }
 
-void viu_start_dma(struct viu_dev *dev)
+static void viu_start_dma(struct viu_dev *dev)
 {
struct viu_reg *vr = dev->vr;
 
@@ -253,7 +253,7 @@ void viu_start_dma(struct viu_dev *dev)
out_be32(>status_cfg, INT_FIELD_EN);
 }
 
-void viu_stop_dma(struct viu_dev *dev)
+static void viu_stop_dma(struct viu_dev *dev)
 {
struct viu_reg *vr = dev->vr;
int cnt = 100;
@@ -802,7 +802,7 @@ static int vidioc_overlay(struct file *file, void *priv, 
unsigned int on)
return 0;
 }
 
-int vidioc_g_fbuf(struct file *file, void *priv, struct v4l2_framebuffer *arg)
+static int vidioc_g_fbuf(struct file *file, void *priv, struct 
v4l2_framebuffer *arg)
 {
struct viu_fh  *fh = priv;
struct viu_dev *dev = fh->dev;
@@ -813,7 +813,7 @@ int vidioc_g_fbuf(struct file *file, void *priv, struct 
v4l2_framebuffer *arg)
return 0;
 }
 
-int vidioc_s_fbuf(struct file *file, void *priv, const struct v4l2_framebuffer 
*arg)
+static int vidioc_s_fbuf(struct file *file, void *priv, const struct 
v4l2_framebuffer *arg)
 {
struct viu_fh  *fh = priv;
struct viu_dev *dev = fh->dev;
@@ -1305,7 +1305,7 @@ static int viu_release(struct file *file)
return 0;
 }
 
-void viu_reset(struct viu_reg *reg)
+static void viu_reset(struct viu_reg *reg)
 {
out_be32(>status_cfg, 0);
out_be32(>luminance, 0x9512a254);
-- 
2.14.3

[PATCH 01/16] omap: omap-iommu.h: allow building drivers with COMPILE_TEST

[Mauro Carvalho Chehab]

Drivers that depend on omap-iommu.h (currently, just omap3isp)
need a stub implementation in order to be built with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/linux/omap-iommu.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/omap-iommu.h b/include/linux/omap-iommu.h
index c1aede46718b..0c21fc5b002e 100644
--- a/include/linux/omap-iommu.h
+++ b/include/linux/omap-iommu.h
@@ -13,7 +13,12 @@
 #ifndef _OMAP_IOMMU_H_
 #define _OMAP_IOMMU_H_
 
+#ifdef CONFIG_OMAP_IOMMU
 extern void omap_iommu_save_ctx(struct device *dev);
 extern void omap_iommu_restore_ctx(struct device *dev);
+#else
+static inline void omap_iommu_save_ctx(struct device *dev) {};
+static inline void omap_iommu_restore_ctx(struct device *dev) {};
+#endif
 
 #endif
-- 
2.14.3

[PATCH 05/16] media: fsl-viu: allow building it with COMPILE_TEST

[Mauro Carvalho Chehab]

There aren't many things that would be needed to allow it
to build with compile test.

Add the needed bits.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/Kconfig   | 2 +-
 drivers/media/platform/fsl-viu.c | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 03c9dfeb7781..e6eb1eb776e1 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -42,7 +42,7 @@ config VIDEO_SH_VOU
 
 config VIDEO_VIU
tristate "Freescale VIU Video Driver"
-   depends on VIDEO_V4L2 && PPC_MPC512x
+   depends on VIDEO_V4L2 && (PPC_MPC512x || COMPILE_TEST)
select VIDEOBUF_DMA_CONTIG
default y
---help---
diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 9abe79779659..466053e00378 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -36,6 +36,14 @@
 #define DRV_NAME   "fsl_viu"
 #define VIU_VERSION"0.5.1"
 
+/* Allow building this driver with COMPILE_TEST */
+#ifndef CONFIG_PPC_MPC512x
+#define NO_IRQ   0
+
+#define out_be32(v, a) writel(a, v)
+#define in_be32(a) readl(a)
+#endif
+
 #define BUFFER_TIMEOUT msecs_to_jiffies(500)  /* 0.5 seconds */
 
 #defineVIU_VID_MEM_LIMIT   4   /* Video memory limit, in Mb */
-- 
2.14.3

[PATCH 03/16] media: omap3isp/isp: remove an unused static var

[Mauro Carvalho Chehab]

The isp_xclk_init_data const data isn't used anywere.

drivers/media/platform/omap3isp/isp.c:294:35: warning: ‘isp_xclk_init_data’ 
defined but not used [-Wunused-const-variable=]
 static const struct clk_init_data isp_xclk_init_data = {
   ^~

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/omap3isp/isp.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 2a11a709aa4f..9e4b5fb8a8b5 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -291,13 +291,6 @@ static const struct clk_ops isp_xclk_ops = {
 
 static const char *isp_xclk_parent_name = "cam_mclk";
 
-static const struct clk_init_data isp_xclk_init_data = {
-   .name = "cam_xclk",
-   .ops = _xclk_ops,
-   .parent_names = _xclk_parent_name,
-   .num_parents = 1,
-};
-
 static struct clk *isp_xclk_src_get(struct of_phandle_args *clkspec, void 
*data)
 {
unsigned int idx = clkspec->args[0];
-- 
2.14.3

[PATCH 12/16] media: davinci: allow build vpbe_display with COMPILE_TEST

[Mauro Carvalho Chehab]

Except for some includes (with doesn't seem to be used), this
driver builds fine with COMPILE_TEST.

So, add checks there to avoid building it if ARCH_DAVINCI
is not selected.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/davinci/Kconfig| 3 ++-
 drivers/media/platform/davinci/vpbe_display.c | 3 +++
 drivers/media/platform/davinci/vpbe_osd.c | 2 ++
 drivers/media/platform/davinci/vpbe_venc.c| 3 +++
 4 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/davinci/Kconfig 
b/drivers/media/platform/davinci/Kconfig
index babdb4877b3f..b463d1726335 100644
--- a/drivers/media/platform/davinci/Kconfig
+++ b/drivers/media/platform/davinci/Kconfig
@@ -82,7 +82,8 @@ config VIDEO_DM365_ISIF
 
 config VIDEO_DAVINCI_VPBE_DISPLAY
tristate "TI DaVinci VPBE V4L2-Display driver"
-   depends on VIDEO_V4L2 && ARCH_DAVINCI
+   depends on VIDEO_V4L2
+   depends on ARCH_DAVINCI || COMPILE_TEST
depends on HAS_DMA
depends on I2C
select VIDEOBUF2_DMA_CONTIG
diff --git a/drivers/media/platform/davinci/vpbe_display.c 
b/drivers/media/platform/davinci/vpbe_display.c
index 6aabd21fe69f..7b6cd4b3ccc4 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -26,7 +26,10 @@
 #include 
 
 #include 
+
+#ifdef CONFIG_ARCH_DAVINCI
 #include 
+#endif
 
 #include 
 #include 
diff --git a/drivers/media/platform/davinci/vpbe_osd.c 
b/drivers/media/platform/davinci/vpbe_osd.c
index 66449791c70c..10f2bf11edf3 100644
--- a/drivers/media/platform/davinci/vpbe_osd.c
+++ b/drivers/media/platform/davinci/vpbe_osd.c
@@ -24,8 +24,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_ARCH_DAVINCI
 #include 
 #include 
+#endif
 
 #include 
 #include 
diff --git a/drivers/media/platform/davinci/vpbe_venc.c 
b/drivers/media/platform/davinci/vpbe_venc.c
index 3a4e78595149..add72a39ef2d 100644
--- a/drivers/media/platform/davinci/vpbe_venc.c
+++ b/drivers/media/platform/davinci/vpbe_venc.c
@@ -21,8 +21,11 @@
 #include 
 #include 
 
+#ifdef CONFIG_ARCH_DAVINCI
 #include 
 #include 
+#endif
+
 #include 
 
 #include 
-- 
2.14.3

[PATCH 08/16] media: mmp-camera.h: add missing platform data

[Mauro Carvalho Chehab]

Those definitions used to be part of the original patch:
https://patchwork.kernel.org/patch/2815221/

But, somehow, nobody ever noticed until today. Years later,
Arnd discovered that mmp-camera driver doesn't build and make
it depend on BROKEN.

Add the missing bits here, in order to remove BROKEN dependency.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/linux/platform_data/media/mmp-camera.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/platform_data/media/mmp-camera.h 
b/include/linux/platform_data/media/mmp-camera.h
index 83804028115c..d2d3a443eedf 100644
--- a/include/linux/platform_data/media/mmp-camera.h
+++ b/include/linux/platform_data/media/mmp-camera.h
@@ -3,8 +3,27 @@
  * Information for the Marvell Armada MMP camera
  */
 
+#include 
+
+enum dphy3_algo {
+   DPHY3_ALGO_DEFAULT = 0,
+   DPHY3_ALGO_PXA910,
+   DPHY3_ALGO_PXA2128
+};
+
 struct mmp_camera_platform_data {
struct platform_device *i2c_device;
int sensor_power_gpio;
int sensor_reset_gpio;
+   enum v4l2_mbus_type bus_type;
+   int mclk_min;   /* The minimal value of MCLK */
+   int mclk_src;   /* which clock source the MCLK derives from */
+   int mclk_div;   /* Clock Divider Value for MCLK */
+   /*
+* MIPI support
+*/
+   int dphy[3];/* DPHY: CSI2_DPHY3, CSI2_DPHY5, CSI2_DPHY6 */
+   enum dphy3_algo dphy3_algo; /* algos for calculate CSI2_DPHY3 */
+   int lane;   /* ccic used lane number; 0 means DVP mode */
+   int lane_clk;
 };
-- 
2.14.3

[PATCH 10/16] media: mmp-driver: make two functions static

[Mauro Carvalho Chehab]

Those functions are used only internally:

  CC  drivers/media/platform/marvell-ccic/mmp-driver.o
drivers/media/platform/marvell-ccic/mmp-driver.c:186:6: warning: no previous 
prototype for ‘mcam_ctlr_reset’ [-Wmissing-prototypes]
 void mcam_ctlr_reset(struct mcam_camera *mcam)
  ^~~
drivers/media/platform/marvell-ccic/mmp-driver.c:217:6: warning: no previous 
prototype for ‘mmpcam_calc_dphy’ [-Wmissing-prototypes]
 void mmpcam_calc_dphy(struct mcam_camera *mcam)
  ^~~~

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/marvell-ccic/mmp-driver.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c 
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 816f4b6a7b8e..17d79480e75c 100644
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -183,7 +183,7 @@ static void mmpcam_power_down(struct mcam_camera *mcam)
mcam_clk_disable(mcam);
 }
 
-void mcam_ctlr_reset(struct mcam_camera *mcam)
+static void mcam_ctlr_reset(struct mcam_camera *mcam)
 {
unsigned long val;
struct mmp_camera *cam = mcam_to_cam(mcam);
@@ -214,7 +214,7 @@ void mcam_ctlr_reset(struct mcam_camera *mcam)
  * CSI2_DPHY3 and CSI2_DPHY6 can be set with a default value
  * or be calculated dynamically
  */
-void mmpcam_calc_dphy(struct mcam_camera *mcam)
+static void mmpcam_calc_dphy(struct mcam_camera *mcam)
 {
struct mmp_camera *cam = mcam_to_cam(mcam);
struct mmp_camera_platform_data *pdata = cam->pdev->dev.platform_data;
-- 
2.14.3

[PATCH 02/16] media: omap3isp: allow it to build with COMPILE_TEST

[Mauro Carvalho Chehab]

There aren't much things required for it to build with COMPILE_TEST.
It just needs to provide stub for an arm-dependent include.

Let's replicate the same solution used by ipmmu-vmsa, in order
to allow building omap3 with COMPILE_TEST.

The actual logic here came from this driver:

   drivers/iommu/ipmmu-vmsa.c

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/Kconfig| 8 
 drivers/media/platform/omap3isp/isp.c | 7 +++
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8a1b01..03c9dfeb7781 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -62,12 +62,12 @@ config VIDEO_MUX
 
 config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
-   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
+   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
depends on HAS_DMA && OF
-   depends on OMAP_IOMMU
-   select ARM_DMA_USE_IOMMU
+   depends on ((ARCH_OMAP3 && OMAP_IOMMU) || COMPILE_TEST)
+   select ARM_DMA_USE_IOMMU if OMAP_IOMMU
select VIDEOBUF2_DMA_CONTIG
-   select MFD_SYSCON
+   select MFD_SYSCON if ARCH_OMAP3
select V4L2_FWNODE
---help---
  Driver for an OMAP 3 camera controller.
diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 8eb000e3d8fd..2a11a709aa4f 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -61,7 +61,14 @@
 #include 
 #include 
 
+#if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
 #include 
+#else
+#define arm_iommu_create_mapping(...)  NULL
+#define arm_iommu_attach_device(...)   -ENODEV
+#define arm_iommu_release_mapping(...) do {} while (0)
+#define arm_iommu_detach_device(...)   do {} while (0)
+#endif
 
 #include 
 #include 
-- 
2.14.3

[PATCH 07/16] media: exymos4-is: allow compile test for EXYNOS FIMC-LITE

[Mauro Carvalho Chehab]

There's nothing that prevents building this driver with
COMPILE_TEST. So, enable it.

While here, make the Kconfig dependency cleaner by removing
the unneeded if block.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/exynos4-is/Kconfig | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index 7b2c49e5a592..c8e5ad8f8294 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -41,11 +41,10 @@ config VIDEO_S5P_MIPI_CSIS
  To compile this driver as a module, choose M here: the
  module will be called s5p-csis.
 
-if SOC_EXYNOS4412 || SOC_EXYNOS5250
-
 config VIDEO_EXYNOS_FIMC_LITE
tristate "EXYNOS FIMC-LITE camera interface driver"
depends on I2C
+   depends on SOC_EXYNOS4412 || SOC_EXYNOS5250 || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select VIDEO_EXYNOS4_IS_COMMON
@@ -55,7 +54,6 @@ config VIDEO_EXYNOS_FIMC_LITE
 
  To compile this driver as a module, choose M here: the
  module will be called exynos-fimc-lite.
-endif
 
 config VIDEO_EXYNOS4_FIMC_IS
tristate "EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver"
-- 
2.14.3

[PATCH 14/16] media: davinci: get rid of lots of kernel-doc warnings

[Mauro Carvalho Chehab]

Driver build produce lots of warnings due to wrong kernel-doc markups:

drivers/media/platform/davinci/vpbe.c:60: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_current_encoder_info'
drivers/media/platform/davinci/vpbe.c:78: warning: Function parameter or 
member 'cfg' not described in 'vpbe_find_encoder_sd_index'
drivers/media/platform/davinci/vpbe.c:78: warning: Function parameter or 
member 'index' not described in 'vpbe_find_encoder_sd_index'
drivers/media/platform/davinci/vpbe.c:105: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_g_cropcap'
drivers/media/platform/davinci/vpbe.c:105: warning: Function parameter or 
member 'cropcap' not described in 'vpbe_g_cropcap'
drivers/media/platform/davinci/vpbe.c:127: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_enum_outputs'
drivers/media/platform/davinci/vpbe.c:127: warning: Function parameter or 
member 'output' not described in 'vpbe_enum_outputs'
drivers/media/platform/davinci/vpbe.c:221: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_set_output'
drivers/media/platform/davinci/vpbe.c:221: warning: Function parameter or 
member 'index' not described in 'vpbe_set_output'
drivers/media/platform/davinci/vpbe.c:316: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_get_output'
drivers/media/platform/davinci/vpbe.c:328: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_s_dv_timings'
drivers/media/platform/davinci/vpbe.c:328: warning: Function parameter or 
member 'dv_timings' not described in 'vpbe_s_dv_timings'
drivers/media/platform/davinci/vpbe.c:380: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_g_dv_timings'
drivers/media/platform/davinci/vpbe.c:380: warning: Function parameter or 
member 'dv_timings' not described in 'vpbe_g_dv_timings'
drivers/media/platform/davinci/vpbe.c:405: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_enum_dv_timings'
drivers/media/platform/davinci/vpbe.c:405: warning: Function parameter or 
member 'timings' not described in 'vpbe_enum_dv_timings'
drivers/media/platform/davinci/vpbe.c:436: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_s_std'
drivers/media/platform/davinci/vpbe.c:436: warning: Function parameter or 
member 'std_id' not described in 'vpbe_s_std'
drivers/media/platform/davinci/vpbe.c:475: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_g_std'
drivers/media/platform/davinci/vpbe.c:475: warning: Function parameter or 
member 'std_id' not described in 'vpbe_g_std'
drivers/media/platform/davinci/vpbe.c:500: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_set_mode'
drivers/media/platform/davinci/vpbe.c:500: warning: Function parameter or 
member 'mode_info' not described in 'vpbe_set_mode'
drivers/media/platform/davinci/vpbe.c:585: warning: Function parameter or 
member 'dev' not described in 'vpbe_initialize'
drivers/media/platform/davinci/vpbe.c:585: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_initialize'
drivers/media/platform/davinci/vpbe.c:779: warning: Function parameter or 
member 'dev' not described in 'vpbe_deinitialize'
drivers/media/platform/davinci/vpbe.c:779: warning: Function parameter or 
member 'vpbe_dev' not described in 'vpbe_deinitialize'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter 
or member 'sd' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter 
or member 'field_inversion' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter 
or member 'fb_base_phys' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter 
or member 'lconfig' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter 
or member 'sd' not described in 'try_layer_config'
drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter 
or member 'layer' not described in 'try_layer_config'
drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter 
or member 'lconfig' not described in 'try_layer_config'
drivers/media/platform/davinci/vpbe_display.c:578: warning: Function 
parameter or member 'disp_dev' not described in 'vpbe_try_format'
drivers/media/platform/davinci/vpbe_display.c:578: warning: Function 
parameter or member 'pixfmt' not described in 'vpbe_try_format'
drivers/media/platform/davinci/vpbe_display.c:578: warning: Function 
parameter or member 'check' not described in 'vpbe_try_format'
drivers/media/platform/davinci/vpbe_display.c:943: warning: Function 
parameter 

[PATCH 06/16] media: cec_gpio: allow building CEC_GPIO with COMPILE_TEST

[Mauro Carvalho Chehab]

At least on i386, building with allyesconfig doesn't enable
PREEMPT, causing cec_gpio to not build.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index e6eb1eb776e1..e8d8bbc976af 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -558,7 +558,7 @@ config VIDEO_MESON_AO_CEC
 
 config CEC_GPIO
tristate "Generic GPIO-based CEC driver"
-   depends on PREEMPT
+   depends on PREEMPT || COMPILE_TEST
select CEC_CORE
select CEC_PIN
select GPIOLIB
-- 
2.14.3

[PATCH 09/16] media: marvel-ccic: re-enable mmp-driver build

[Mauro Carvalho Chehab]

This driver was disabled back in 2015 from builds because
of some troubles with the platform_data definition. Now
that this got fixed, re-enable it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/marvell-ccic/Kconfig | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/marvell-ccic/Kconfig 
b/drivers/media/platform/marvell-ccic/Kconfig
index 4bf5bd1e90d6..21dacef7c2fc 100644
--- a/drivers/media/platform/marvell-ccic/Kconfig
+++ b/drivers/media/platform/marvell-ccic/Kconfig
@@ -13,8 +13,9 @@ config VIDEO_CAFE_CCIC
 
 config VIDEO_MMP_CAMERA
tristate "Marvell Armada 610 integrated camera controller support"
-   depends on ARCH_MMP && I2C && VIDEO_V4L2
-   depends on HAS_DMA && BROKEN
+   depends on I2C && VIDEO_V4L2
+   depends on HAS_DMA
+   depends on ARCH_MMP || COMPILE_TEST
select VIDEO_OV7670
select I2C_GPIO
select VIDEOBUF2_DMA_SG
-- 
2.14.3

[PATCH 16/16] media: omap: allow building it with COMPILE_TEST

[Mauro Carvalho Chehab]

Now that we have stubs for omap FB driver, let it build with
COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/omap/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/omap/Kconfig 
b/drivers/media/platform/omap/Kconfig
index e8e2db181a7a..e6b486c5ddfc 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -4,11 +4,11 @@ config VIDEO_OMAP2_VOUT_VRFB
 config VIDEO_OMAP2_VOUT
tristate "OMAP2/OMAP3 V4L2-Display driver"
depends on MMU
-   depends on ARCH_OMAP2 || ARCH_OMAP3
-   depends on FB_OMAP2
+   depends on ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST
+   depends on FB_OMAP2 || COMPILE_TEST
select VIDEOBUF_GEN
select VIDEOBUF_DMA_CONTIG
-   select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
+   select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3 || COMPILE_TEST
select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT && OMAP2_VRFB
select FRAME_VECTOR
default n
-- 
2.14.3

[PATCH 00/16] Make all drivers under drivers/media to build with COMPILE_TEST

[Mauro Carvalho Chehab]

The current media policy has been for a while to only accept new drivers 
that compile with COMPILE_TEST.

However, there are still several drivers under drivers/media that 
doesn't build with COMPILE_TEST.

So, this series makes the existing ones also compatible with it.

Not building with COMPILE_TEST is a bad thing, for several reasons.

The main ones is that:

1) the licence the Kernel community has for Coverity only builds for 
   x86. So, drivers that don't build on such archtecture were likely 
   never tested by it.

2) That affects my per-patch handling process, with should be quick 
   enough to not delay my patch handling process. So, I only build for one 
   architecture (i386).

3) When appliying a patch, I always run two static code analyzers (W=1, 
   smatch and sparse). Those drivers weren't checked by me. At the end 
   of the day, that leads to a lower quality check for the drivers that 
   don't build on i386.

There are two situations on this patch series that proof the lower 
quality of those drivers:

- There is a case of a driver that was added broken in 2013. Only two 
  years later, someone noticed and "fixed" it by markin it as BROKEN!

- 5 patches in this series (about 1/3) are just to fix build issues on 
  those drivers, most of them due to gcc warnings.


Mauro Carvalho Chehab (16):
  omap: omap-iommu.h: allow building drivers with COMPILE_TEST
  media: omap3isp: allow it to build with COMPILE_TEST
  media: omap3isp/isp: remove an unused static var
  media: fsl-viu: mark static functions as such
  media: fsl-viu: allow building it with COMPILE_TEST
  media: cec_gpio: allow building CEC_GPIO with COMPILE_TEST
  media: exymos4-is: allow compile test for EXYNOS FIMC-LITE
  media: mmp-camera.h: add missing platform data
  media: marvel-ccic: re-enable mmp-driver build
  media: mmp-driver: make two functions static
  media: davinci: allow building isif code
  media: davinci: allow build vpbe_display with COMPILE_TEST
  media: vpbe_venc: don't store return codes if they won't be used
  media: davinci: get rid of lots of kernel-doc warnings
  media: omapfb_dss.h: add stubs to build with COMPILE_TEST
  media: omap: allow building it with COMPILE_TEST

 drivers/media/platform/Kconfig   | 12 +++---
 drivers/media/platform/davinci/Kconfig   |  6 ++-
 drivers/media/platform/davinci/isif.c|  2 -
 drivers/media/platform/davinci/vpbe.c| 38 +
 drivers/media/platform/davinci/vpbe_display.c| 21 +
 drivers/media/platform/davinci/vpbe_osd.c| 16 ---
 drivers/media/platform/davinci/vpbe_venc.c   |  9 ++--
 drivers/media/platform/exynos4-is/Kconfig|  4 +-
 drivers/media/platform/fsl-viu.c | 20 ++---
 drivers/media/platform/marvell-ccic/Kconfig  |  5 ++-
 drivers/media/platform/marvell-ccic/mmp-driver.c |  4 +-
 drivers/media/platform/omap/Kconfig  |  6 +--
 drivers/media/platform/omap3isp/isp.c| 14 +++---
 include/linux/omap-iommu.h   |  5 +++
 include/linux/platform_data/media/mmp-camera.h   | 19 +
 include/video/omapfb_dss.h   | 54 +++-
 16 files changed, 162 insertions(+), 73 deletions(-)

-- 
2.14.3

[PATCH 11/16] media: davinci: allow building isif code

[Mauro Carvalho Chehab]

The only reason why this driver doesn't build with COMPILE_TEST
is because it includes mach/mux.h. It turns that none of the
macros defined there are used.

So, get rid of it, in order to allow it to build with
COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/davinci/Kconfig | 3 ++-
 drivers/media/platform/davinci/isif.c  | 2 --
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/davinci/Kconfig 
b/drivers/media/platform/davinci/Kconfig
index 55982e681d77..babdb4877b3f 100644
--- a/drivers/media/platform/davinci/Kconfig
+++ b/drivers/media/platform/davinci/Kconfig
@@ -67,7 +67,8 @@ config VIDEO_DM355_CCDC
 
 config VIDEO_DM365_ISIF
tristate "TI DM365 ISIF video capture driver"
-   depends on VIDEO_V4L2 && ARCH_DAVINCI
+   depends on VIDEO_V4L2
+   depends on ARCH_DAVINCI || COMPILE_TEST
depends on HAS_DMA
depends on I2C
select VIDEOBUF_DMA_CONTIG
diff --git a/drivers/media/platform/davinci/isif.c 
b/drivers/media/platform/davinci/isif.c
index d5ff58494c1e..b14caadcd0df 100644
--- a/drivers/media/platform/davinci/isif.c
+++ b/drivers/media/platform/davinci/isif.c
@@ -31,8 +31,6 @@
 #include 
 #include 
 
-#include 
-
 #include 
 #include 
 
-- 
2.14.3

[PATCH 13/16] media: vpbe_venc: don't store return codes if they won't be used

[Mauro Carvalho Chehab]

Fix those two warnings

drivers/media/platform/davinci/vpbe_venc.c: In function ‘venc_set_ntsc’:
drivers/media/platform/davinci/vpbe_venc.c:230:6: warning: variable ‘val’ set 
but not used [-Wunused-but-set-variable]
  u32 val;
  ^~~
drivers/media/platform/davinci/vpbe_venc.c: In function ‘venc_sub_dev_init’:
drivers/media/platform/davinci/vpbe_venc.c:611:6: warning: variable ‘err’ set 
but not used [-Wunused-but-set-variable]
  int err;
  ^~~
  AR  drivers/media/platform/davinci/built-in.a

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/davinci/vpbe_venc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/davinci/vpbe_venc.c 
b/drivers/media/platform/davinci/vpbe_venc.c
index add72a39ef2d..5c255de3b3f8 100644
--- a/drivers/media/platform/davinci/vpbe_venc.c
+++ b/drivers/media/platform/davinci/vpbe_venc.c
@@ -227,7 +227,6 @@ venc_enable_vpss_clock(int venc_type,
  */
 static int venc_set_ntsc(struct v4l2_subdev *sd)
 {
-   u32 val;
struct venc_state *venc = to_state(sd);
struct venc_platform_data *pdata = venc->pdata;
 
@@ -244,7 +243,7 @@ static int venc_set_ntsc(struct v4l2_subdev *sd)
if (venc->venc_type == VPBE_VERSION_3) {
venc_write(sd, VENC_CLKCTL, 0x01);
venc_write(sd, VENC_VIDCTL, 0);
-   val = vdaccfg_write(sd, VDAC_CONFIG_SD_V3);
+   vdaccfg_write(sd, VDAC_CONFIG_SD_V3);
} else if (venc->venc_type == VPBE_VERSION_2) {
venc_write(sd, VENC_CLKCTL, 0x01);
venc_write(sd, VENC_VIDCTL, 0);
@@ -608,9 +607,8 @@ struct v4l2_subdev *venc_sub_dev_init(struct v4l2_device 
*v4l2_dev,
const char *venc_name)
 {
struct venc_state *venc;
-   int err;
 
-   err = bus_for_each_dev(_bus_type, NULL, ,
+   bus_for_each_dev(_bus_type, NULL, ,
venc_device_get);
if (venc == NULL)
return NULL;
-- 
2.14.3

[PATCH 15/16] media: omapfb_dss.h: add stubs to build with COMPILE_TEST

[Mauro Carvalho Chehab]

Add stubs for omapfb_dss.h, in the case it is included by
some driver when CONFIG_FB_OMAP2 is not defined.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/video/omapfb_dss.h | 54 --
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
index 1d38901d599d..e9775144ff3b 100644
--- a/include/video/omapfb_dss.h
+++ b/include/video/omapfb_dss.h
@@ -774,6 +774,12 @@ struct omap_dss_driver {
const struct hdmi_avi_infoframe *avi);
 };
 
+#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
+
+typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
+
+#ifdef CONFIG_FB_OMAP2
+
 enum omapdss_version omapdss_get_version(void);
 bool omapdss_is_initialized(void);
 
@@ -785,7 +791,6 @@ void omapdss_unregister_display(struct omap_dss_device 
*dssdev);
 
 struct omap_dss_device *omap_dss_get_device(struct omap_dss_device *dssdev);
 void omap_dss_put_device(struct omap_dss_device *dssdev);
-#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
 struct omap_dss_device *omap_dss_get_next_device(struct omap_dss_device *from);
 struct omap_dss_device *omap_dss_find_device(void *data,
int (*match)(struct omap_dss_device *dssdev, void *data));
@@ -826,7 +831,6 @@ int omapdss_default_get_recommended_bpp(struct 
omap_dss_device *dssdev);
 void omapdss_default_get_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
 
-typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
 int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 
@@ -856,5 +860,51 @@ omapdss_of_get_first_endpoint(const struct device_node 
*parent);
 
 struct omap_dss_device *
 omapdss_of_find_source_for_first_ep(struct device_node *node);
+#else
+
+static inline enum omapdss_version omapdss_get_version(void)
+{ return OMAPDSS_VER_UNKNOWN; };
+
+static inline bool omapdss_is_initialized(void)
+{ return false; };
+
+static inline int omap_dispc_register_isr(omap_dispc_isr_t isr,
+ void *arg, u32 mask)
+{ return 0; };
+
+static inline int omap_dispc_unregister_isr(omap_dispc_isr_t isr,
+   void *arg, u32 mask)
+{ return 0; };
+
+static inline struct omap_dss_device
+*omap_dss_get_device(struct omap_dss_device *dssdev)
+{ return NULL; };
+
+static inline struct omap_dss_device
+*omap_dss_get_next_device(struct omap_dss_device *from)
+{return NULL; };
+
+static inline void omap_dss_put_device(struct omap_dss_device *dssdev) {};
+
+static inline int omapdss_compat_init(void)
+{ return 0; };
+
+static inline void omapdss_compat_uninit(void) {};
+
+static inline int omap_dss_get_num_overlay_managers(void)
+{ return 0; };
+
+static inline struct omap_overlay_manager *omap_dss_get_overlay_manager(int 
num)
+{ return NULL; };
+
+static inline int omap_dss_get_num_overlays(void)
+{ return 0; };
+
+static inline struct omap_overlay *omap_dss_get_overlay(int num)
+{ return NULL; };
+
+
+#endif /* FB_OMAP2 */
+
 
 #endif /* __OMAPFB_DSS_H */
-- 
2.14.3

Re: IMX6 Media dev node not created

[Fabio Estevam]

Hi Ibtsam,

On Thu, Apr 5, 2018 at 11:52 AM, Ibtsam Ul-Haq
 wrote:

> That worked like a charm! Thanks a lot guys, I would have never thought of 
> that!

Excellent!

If you have a chance, please submit the the dts patch that enables the
camera to the linux-arm-kernel mailing list for review and inclusion
to the mainline kernel.

Re: IMX6 Media dev node not created

[Ibtsam Ul-Haq]

On Thu, Apr 5, 2018 at 4:36 PM, Philipp Zabel  wrote:
> Hi Ibtsam,
>
> On Thu, 2018-04-05 at 16:24 +0200, Ibtsam Ul-Haq wrote:
>> Hi Fabio,
>>
>> Thanks for your reply.
>>
>> On Thu, Apr 5, 2018 at 3:31 PM, Fabio Estevam  wrote:
>> > Hi Ibtsam,
>> >
>> > [Adding Steve and Philipp in case they can provide some suggestions]
>> >
>> > On Thu, Apr 5, 2018 at 9:30 AM, Ibtsam Ul-Haq  
>> > wrote:
>> > > Greetings everyone,
>> > >
>> > > I'm running Linux 4.14.31 on an IMX6 QuadPlus based Phytec board
>> > > (PCM-058). I have connected an mt9p031 sensor to ipu1_csi0. The
>> > > problem is that I am not seeing the /dev/media0 node.
>> >
>> > Can you share your dts?
>> >
>>
>> Certainly. The dts provided by the board manufacturer was meant to
>> work with their own kernel, I tried to modify it to work with the
>> mainline kernel.
>>
>> The sensor related nodes are:
>>
> [...]
>> mt9p031_1: cam1@5d {
>> compatible = "aptina,mt9p031";
>> reg = <0x5d>;
>> status = "okay";
> [...]
>> I intend to use two cameras simultaneously. In my current setup
>> however only one camera is physically connected.
>
> Try disabling this camera as long as it is not present, otherwise the
> imx-media driver will wait forever for it to appear before creating
> /dev/media0.
>

That worked like a charm! Thanks a lot guys, I would have never thought of that!

> regards
> Philipp


Best regards,
Ibtsam Haq

Re: IMX6 Media dev node not created

[Philipp Zabel]

Hi Ibtsam,

On Thu, 2018-04-05 at 16:24 +0200, Ibtsam Ul-Haq wrote:
> Hi Fabio,
> 
> Thanks for your reply.
> 
> On Thu, Apr 5, 2018 at 3:31 PM, Fabio Estevam  wrote:
> > Hi Ibtsam,
> > 
> > [Adding Steve and Philipp in case they can provide some suggestions]
> > 
> > On Thu, Apr 5, 2018 at 9:30 AM, Ibtsam Ul-Haq  
> > wrote:
> > > Greetings everyone,
> > > 
> > > I'm running Linux 4.14.31 on an IMX6 QuadPlus based Phytec board
> > > (PCM-058). I have connected an mt9p031 sensor to ipu1_csi0. The
> > > problem is that I am not seeing the /dev/media0 node.
> > 
> > Can you share your dts?
> > 
> 
> Certainly. The dts provided by the board manufacturer was meant to
> work with their own kernel, I tried to modify it to work with the
> mainline kernel.
> 
> The sensor related nodes are:
> 
[...]
> mt9p031_1: cam1@5d {
> compatible = "aptina,mt9p031";
> reg = <0x5d>;
> status = "okay";
[...]
> I intend to use two cameras simultaneously. In my current setup
> however only one camera is physically connected.

Try disabling this camera as long as it is not present, otherwise the
imx-media driver will wait forever for it to appear before creating
/dev/media0.

regards
Philipp

Re: IMX6 Media dev node not created

[Ibtsam Ul-Haq]

Hi Fabio,

Thanks for your reply.

On Thu, Apr 5, 2018 at 3:31 PM, Fabio Estevam  wrote:
> Hi Ibtsam,
>
> [Adding Steve and Philipp in case they can provide some suggestions]
>
> On Thu, Apr 5, 2018 at 9:30 AM, Ibtsam Ul-Haq  
> wrote:
>> Greetings everyone,
>>
>> I'm running Linux 4.14.31 on an IMX6 QuadPlus based Phytec board
>> (PCM-058). I have connected an mt9p031 sensor to ipu1_csi0. The
>> problem is that I am not seeing the /dev/media0 node.
>
> Can you share your dts?
>

Certainly. The dts provided by the board manufacturer was meant to
work with their own kernel, I tried to modify it to work with the
mainline kernel.

The sensor related nodes are:

 {
pinctrl-names = "default";
pinctrl-0 = <_i2c1>;
clock-frequency = <10>;
status = "okay";

mt9p031_0: cam0@48 {
compatible = "aptina,mt9p031";
reg = <0x48>;
status = "okay";
vdd-supply = <_cam2v8>;
vdd_io-supply = <_cam2v8>;
vaa-supply = <_cam2v8>;

clocks = <_camclk>;

port {
mt9p031_ep0: endpoint {
input-clock-frequency = <2700>;
pixel-clock-frequency = <5400>;
pclk-sample = <1>;
remote-endpoint = <_csi0_mux_from_parallel_sensor>;
};
};
};

mt9p031_1: cam1@5d {
compatible = "aptina,mt9p031";
reg = <0x5d>;
status = "okay";
vdd-supply = <_cam2v8>;
vdd_io-supply = <_cam2v8>;
vaa-supply = <_cam2v8>;

clocks = <_camclk>;

port {
mt9p031_ep1: endpoint {
input-clock-frequency = <2700>;
pixel-clock-frequency = <5400>;
bus-width = <12>;
pclk-sample = <1>;
remote-endpoint = <_csi1_mux_from_parallel_sensor>;
};
};
};
};


And the IPU related stuff:

_csi0_from_ipu1_csi0_mux {
bus-width = <8>;
data-shift = <12>; /* Lines 19:12 used */
hsync-active = <1>;
vsync-active = <1>;
};

_csi0_mux_from_parallel_sensor {
remote-endpoint = <_ep0>;
};

_csi0 {
pinctrl-names = "default";
pinctrl-0 = <
_sensor_cam0_data
_sensor_cam0_ctrl
>;
};

_csi1_from_ipu2_csi1_mux {
bus-width = <8>;
data-shift = <12>; /* Lines 19:12 used */
hsync-active = <1>;
vsync-active = <1>;
};

_csi1_mux_from_parallel_sensor {
remote-endpoint = <_ep1>;
};

_csi1 {
pinctrl-names = "default";
pinctrl-0 = <
_sensor_cam1_data
_sensor_cam1_ctrl
>;
};


>> I have already read the fix mentioned in a previous discussion:
>>
>> https://www.spinics.net/lists/linux-media/msg121965.html
>>
>> and that does not seem to be the problem in my case as I do get the
>> "ipu1_csi0_mux" registered. Running a grep on dmesg I get:
>>
>> [3.235383] imx-media: Registered subdev ipu1_vdic
>> [3.241134] imx-media: Registered subdev ipu2_vdic
>> [3.246830] imx-media: Registered subdev ipu1_ic_prp
>> [3.252115] imx-media: Registered subdev ipu1_ic_prpenc
>> [3.266991] imx-media: Registered subdev ipu1_ic_prpvf
>> [3.280228] imx-media: Registered subdev ipu2_ic_prp
>> [3.285580] imx-media: Registered subdev ipu2_ic_prpenc
>> [3.299335] imx-media: Registered subdev ipu2_ic_prpvf
>> [3.350034] imx-media: Registered subdev ipu1_csi0
>> [3.363017] imx-media: Registered subdev ipu1_csi1
>> [3.375523] imx-media: Registered subdev ipu2_csi0
>> [3.388615] imx-media: Registered subdev ipu2_csi1
>> [3.560351] imx-media: Registered subdev ipu1_csi0_mux
>> [3.566151] imx-media: Registered subdev ipu2_csi1_mux
>> [   10.525497] imx-media: Registered subdev mt9p031 0-0048
>> [   10.530816] imx-media capture-subsystem: Entity type for entity
>> mt9p031 0-0048 was not initialized!
>> [   10.569201] mt9p031 0-0048: MT9P031 detected at address 0x48
>> [   10.582895] imx-media: Registered subdev mt9p031 0-005d
>> [   10.588335] imx-media capture-subsystem: Entity type for entity
>> mt9p031 0-005d was not initialized!
>> [   10.618795] mt9p031 0-005d: MT9P031 not detected, wrong version 0xfffa
>
> Why do you have the camera in two I2C addresses: 0x48 and 0x5d?
>

I intend to use two cameras simultaneously. In my current setup
however only one camera is physically connected.


>> Also my config does appear to have the required options activated;
>> running "zcat /proc/config.gz | egrep 'VIDEO_MUX|MUX_MMIO|VIDEO_IMX'"
>> I get:
>>
>> # CONFIG_MDIO_BUS_MUX_MMIOREG is not set
>> CONFIG_VIDEO_MUX=y
>> CONFIG_VIDEO_IMX_VDOA=m
>> CONFIG_VIDEO_IMX_MEDIA=y
>> CONFIG_VIDEO_IMX_CSI=y
>> CONFIG_MUX_MMIO=y
>>
>> I would really appreciate if anyone could help me trying to find out
>> what went wrong and why the /dev/media0 node is not showing up.
>>
>> Many thanks and best regards,
>> Ibtsam Haq

Dear Good Friend

[Mr.Sawadogo Ahmed]

Dear friend,


I am using this opportunity to inform you that this
multi-million-dollar business has been concluded with the assistance
of another partner from China who financed the transaction to a
logical conclusion.

I thank you for your great effort to our unfinished transfer of fund
into your account due to one reason or the other best known to you.
But I want to inform you that I have successfully transferred the fund
out of my bank to my new partner's account in china that was capable
of assisting me in this great venture and I have sent several massages
to you concerning this issue.

Due to your effort, sincerity, courage and trust worthiness you showed
during the transaction. I want to compensate you and show my gratitude
to you with the sum of $950,000.00, But I have not heard from you ever
since and I hope you will reply this last notice. This is to notify
you that I have deposited the sum of $950,000.00, for your
compensation with agent of western union to be transfer or send to
you.

You were meant to be receiving $10,000.00USD daily until it completes
the correct amount of $950,000.00USD for better understanding of what
I mean, you can visit any western union transfer agent nearest to you
and confirm the following information.

(1) Sender's Name: Vick Omo
MTCN ; 468 851 1169
Amount: - USD $5,000
X

They told me that they will be sending the sum of $10,000.00 to you
everyday until the total sum is completed ($950,000.00).

Once, you pick it you should try to let them know so that they can
send you another payment.

Contact the western union agent Burkina Faso office below on; Name; Mr. Vick Omo
(Foreign Operation Manager) Email: (westerunionagentmoneytrans...@bk.ru)

Thanks,
Mr.Ahmed Sawadogo

Re: IMX6 Media dev node not created

[Fabio Estevam]

Hi Ibtsam,

[Adding Steve and Philipp in case they can provide some suggestions]

On Thu, Apr 5, 2018 at 9:30 AM, Ibtsam Ul-Haq  wrote:
> Greetings everyone,
>
> I'm running Linux 4.14.31 on an IMX6 QuadPlus based Phytec board
> (PCM-058). I have connected an mt9p031 sensor to ipu1_csi0. The
> problem is that I am not seeing the /dev/media0 node.

Can you share your dts?

> I have already read the fix mentioned in a previous discussion:
>
> https://www.spinics.net/lists/linux-media/msg121965.html
>
> and that does not seem to be the problem in my case as I do get the
> "ipu1_csi0_mux" registered. Running a grep on dmesg I get:
>
> [3.235383] imx-media: Registered subdev ipu1_vdic
> [3.241134] imx-media: Registered subdev ipu2_vdic
> [3.246830] imx-media: Registered subdev ipu1_ic_prp
> [3.252115] imx-media: Registered subdev ipu1_ic_prpenc
> [3.266991] imx-media: Registered subdev ipu1_ic_prpvf
> [3.280228] imx-media: Registered subdev ipu2_ic_prp
> [3.285580] imx-media: Registered subdev ipu2_ic_prpenc
> [3.299335] imx-media: Registered subdev ipu2_ic_prpvf
> [3.350034] imx-media: Registered subdev ipu1_csi0
> [3.363017] imx-media: Registered subdev ipu1_csi1
> [3.375523] imx-media: Registered subdev ipu2_csi0
> [3.388615] imx-media: Registered subdev ipu2_csi1
> [3.560351] imx-media: Registered subdev ipu1_csi0_mux
> [3.566151] imx-media: Registered subdev ipu2_csi1_mux
> [   10.525497] imx-media: Registered subdev mt9p031 0-0048
> [   10.530816] imx-media capture-subsystem: Entity type for entity
> mt9p031 0-0048 was not initialized!
> [   10.569201] mt9p031 0-0048: MT9P031 detected at address 0x48
> [   10.582895] imx-media: Registered subdev mt9p031 0-005d
> [   10.588335] imx-media capture-subsystem: Entity type for entity
> mt9p031 0-005d was not initialized!
> [   10.618795] mt9p031 0-005d: MT9P031 not detected, wrong version 0xfffa

Why do you have the camera in two I2C addresses: 0x48 and 0x5d?

> Also my config does appear to have the required options activated;
> running "zcat /proc/config.gz | egrep 'VIDEO_MUX|MUX_MMIO|VIDEO_IMX'"
> I get:
>
> # CONFIG_MDIO_BUS_MUX_MMIOREG is not set
> CONFIG_VIDEO_MUX=y
> CONFIG_VIDEO_IMX_VDOA=m
> CONFIG_VIDEO_IMX_MEDIA=y
> CONFIG_VIDEO_IMX_CSI=y
> CONFIG_MUX_MMIO=y
>
> I would really appreciate if anyone could help me trying to find out
> what went wrong and why the /dev/media0 node is not showing up.
>
> Many thanks and best regards,
> Ibtsam Haq

Re: [PATCH] media: v4l2-dev: use pr_foo() for printing messages

[Sakari Ailus]

Hi Mauro,

On Thu, Apr 05, 2018 at 08:52:02AM -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 5 Apr 2018 14:12:10 +0300
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > On Thu, Apr 05, 2018 at 07:34:39AM -0300, Mauro Carvalho Chehab wrote:
> > > Instead of using printk() directly, use the pr_foo()
> > > macros.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab 
> > > ---
> > >  drivers/media/v4l2-core/v4l2-dev.c | 45 
> > > ++
> > >  1 file changed, 26 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
> > > b/drivers/media/v4l2-core/v4l2-dev.c
> > > index 1d0b2208e8fb..530db8e482fb 100644
> > > --- a/drivers/media/v4l2-core/v4l2-dev.c
> > > +++ b/drivers/media/v4l2-core/v4l2-dev.c
> > > @@ -16,6 +16,8 @@
> > >   *   - Added procfs support
> > >   */
> > >  
> > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > +
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -34,6 +36,12 @@
> > >  #define VIDEO_NUM_DEVICES256
> > >  #define VIDEO_NAME  "video4linux"
> > >  
> > > +#define dprintk(fmt, arg...) do {
> > > \
> > > + printk(KERN_DEBUG pr_fmt("%s: " fmt),   \
> > > +__func__, ##arg);\
> > > +} while (0)  
> > 
> > Any particular reason for introducing a new macro rather than using
> > pr_debug()? I know it's adding the name of the function without requiring
> > to explicitly add that below, but pr_debug("%s: ...", __func__); would be
> > easier to read IMO.
> 
> Yes, there is. Nowadays, most systems are built with CONFIG_DYNAMIC_DEBUG,
> as it is default on most distros.
> 
> It means that, in order to enable a debug message, one has to
> explicitly enable the debug messages via /sys/kernel/debug/dynamic_debug.
> 
> In the case of videodev core, the debug messages are enabled, instead,
> via vdev->dev_debug. It is really messy to have both mechanisms at the
> same time to enable a debug message. We need to use either one or the
> other.
> 
> Also, a change from vdev->dev_debug approach to dynamic_debug approach
> is something that should happen at the entire subsystem.
> 
> Even if this is a good idea (I'm not convinced), this should be
> done on a separate patch series.

Fair enough. Please add:

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

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

[jacopo mondi]

A few corrections,

On Thu, Apr 05, 2018 at 11:10:01AM +0200, jacopo mondi wrote:
> Hi Niklas,
> thanks for the VIN and CSI-2 effort!
>
> On Tue, Feb 13, 2018 at 12:01:32AM +0100, Niklas Söderlund wrote:
> > A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> > supports the 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 
> > Reviewed-by: Hans Verkuil 
> > ---
> >  drivers/media/platform/rcar-vin/Kconfig |  12 +
> >  drivers/media/platform/rcar-vin/Makefile|   1 +
> >  drivers/media/platform/rcar-vin/rcar-csi2.c | 884 
> > 
> >  3 files changed, 897 insertions(+)
> >  create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
> >
>
> [snip]
>
> > +
> > +static const struct rcar_csi2_format rcar_csi2_formats[] = {
> > +   { .code = MEDIA_BUS_FMT_RGB888_1X24,.datatype = 0x24, .bpp = 24 },
> > +   { .code = MEDIA_BUS_FMT_UYVY8_1X16, .datatype = 0x1e, .bpp = 16 },
> > +   { .code = MEDIA_BUS_FMT_UYVY8_2X8,  .datatype = 0x1e, .bpp = 16 },
> > +   { .code = MEDIA_BUS_FMT_YUYV10_2X10,.datatype = 0x1e, .bpp = 16 },
>
> Shouldn't YUYV10_2X10 format have 20 bits per pixel?
>
> > +};
> > +
> > +static const struct rcar_csi2_format *rcar_csi2_code_to_fmt(unsigned int 
> > code)
> > +{
> > +   unsigned int i;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(rcar_csi2_formats); i++)
> > +   if (rcar_csi2_formats[i].code == code)
> > +   return rcar_csi2_formats + i;
> > +
> > +   return NULL;
> > +}
> > +
> > +enum rcar_csi2_pads {
> > +   RCAR_CSI2_SINK,
> > +   RCAR_CSI2_SOURCE_VC0,
> > +   RCAR_CSI2_SOURCE_VC1,
> > +   RCAR_CSI2_SOURCE_VC2,
> > +   RCAR_CSI2_SOURCE_VC3,
> > +   NR_OF_RCAR_CSI2_PAD,
> > +};
> > +
> > +struct rcar_csi2_info {
> > +   const struct phypll_hsfreqrange *hsfreqrange;
> > +   unsigned int csi0clkfreqrange;
> > +   bool clear_ulps;
> > +   bool init_phtw;
> > +};
> > +
> > +struct rcar_csi2 {
> > +   struct device *dev;
> > +   void __iomem *base;
> > +   const struct rcar_csi2_info *info;
> > +
> > +   struct v4l2_subdev subdev;
> > +   struct media_pad pads[NR_OF_RCAR_CSI2_PAD];
> > +
> > +   struct v4l2_async_notifier notifier;
> > +   struct v4l2_async_subdev asd;
> > +   struct v4l2_subdev *remote;
> > +
> > +   struct v4l2_mbus_framefmt mf;
> > +
> > +   struct mutex lock;
> > +   int stream_count;
> > +
> > +   unsigned short lanes;
> > +   unsigned char lane_swap[4];
> > +};
> > +
> > +static inline struct rcar_csi2 *sd_to_csi2(struct v4l2_subdev *sd)
> > +{
> > +   return container_of(sd, struct rcar_csi2, subdev);
> > +}
> > +
> > +static inline struct rcar_csi2 *notifier_to_csi2(struct 
> > v4l2_async_notifier *n)
> > +{
> > +   return container_of(n, struct rcar_csi2, notifier);
> > +}
> > +
> > +static u32 rcar_csi2_read(struct rcar_csi2 *priv, unsigned int reg)
> > +{
> > +   return ioread32(priv->base + reg);
> > +}
> > +
> > +static void rcar_csi2_write(struct rcar_csi2 *priv, unsigned int reg, u32 
> > data)
> > +{
> > +   iowrite32(data, priv->base + reg);
> > +}
> > +
> > +static void rcar_csi2_reset(struct rcar_csi2 *priv)
> > +{
> > +   rcar_csi2_write(priv, SRST_REG, SRST_SRST);
> > +   usleep_range(100, 150);
> > +   rcar_csi2_write(priv, SRST_REG, 0);
> > +}
> > +
> > +static int rcar_csi2_wait_phy_start(struct rcar_csi2 *priv)
> > +{
> > +   int timeout;
> > +
> > +   /* Wait for the clock and data lanes to enter LP-11 state. */
> > +   for (timeout = 100; timeout > 0; timeout--) {
> > +   const u32 lane_mask = (1 << priv->lanes) - 1;
> > +
> > +   if ((rcar_csi2_read(priv, PHCLM_REG) & 1) == 1 &&
>
> Nitpicking:
>   if ((rcar_csi2_read(priv, PHCLM_REG) & 0x01) &&
>
> Don't you prefer to provide defines also for bit fields instead of
> using magic values? In this case something like
> PHCLM_REG_STOPSTATE_CLK would do.
>
> Also, from tables 25.[17-20] it seems to me that for H3 and V3 you
> have to set INSTATE to an hardcoded value after having validated PHDLM.
> Maybe it is not necessary, just pointing it out.
>
> > +   (rcar_csi2_read(priv, PHDLM_REG) & lane_mask) == lane_mask)
> > +   return 0;
> > +
> > +   msleep(20);
> > +   }
> > +
> > +   dev_err(priv->dev, "Timeout waiting for LP-11 state\n");
> > +
> > +   return -ETIMEDOUT;
> > +}
> > +
> > +static int rcar_csi2_calc_phypll(struct rcar_csi2 *priv, unsigned int bpp,
> > +u32 *phypll)
> > +{
> > +   const struct phypll_hsfreqrange *hsfreq;
> > +   struct v4l2_subdev *source;
> > +   struct v4l2_ctrl *ctrl;
> > +   u64 mbps;
> > +
> > +   if (!priv->remote)
> > +   return -ENODEV;
> > +
> > +   source = priv->remote;
> > +
> > +   /* Read the pixel rate control from 

IMX6 Media dev node not created

[Ibtsam Ul-Haq]

Greetings everyone,

I'm running Linux 4.14.31 on an IMX6 QuadPlus based Phytec board
(PCM-058). I have connected an mt9p031 sensor to ipu1_csi0. The
problem is that I am not seeing the /dev/media0 node.

I have already read the fix mentioned in a previous discussion:

https://www.spinics.net/lists/linux-media/msg121965.html

and that does not seem to be the problem in my case as I do get the
"ipu1_csi0_mux" registered. Running a grep on dmesg I get:

[3.235383] imx-media: Registered subdev ipu1_vdic
[3.241134] imx-media: Registered subdev ipu2_vdic
[3.246830] imx-media: Registered subdev ipu1_ic_prp
[3.252115] imx-media: Registered subdev ipu1_ic_prpenc
[3.266991] imx-media: Registered subdev ipu1_ic_prpvf
[3.280228] imx-media: Registered subdev ipu2_ic_prp
[3.285580] imx-media: Registered subdev ipu2_ic_prpenc
[3.299335] imx-media: Registered subdev ipu2_ic_prpvf
[3.350034] imx-media: Registered subdev ipu1_csi0
[3.363017] imx-media: Registered subdev ipu1_csi1
[3.375523] imx-media: Registered subdev ipu2_csi0
[3.388615] imx-media: Registered subdev ipu2_csi1
[3.560351] imx-media: Registered subdev ipu1_csi0_mux
[3.566151] imx-media: Registered subdev ipu2_csi1_mux
[   10.525497] imx-media: Registered subdev mt9p031 0-0048
[   10.530816] imx-media capture-subsystem: Entity type for entity
mt9p031 0-0048 was not initialized!
[   10.569201] mt9p031 0-0048: MT9P031 detected at address 0x48
[   10.582895] imx-media: Registered subdev mt9p031 0-005d
[   10.588335] imx-media capture-subsystem: Entity type for entity
mt9p031 0-005d was not initialized!
[   10.618795] mt9p031 0-005d: MT9P031 not detected, wrong version 0xfffa

Also my config does appear to have the required options activated;
running "zcat /proc/config.gz | egrep 'VIDEO_MUX|MUX_MMIO|VIDEO_IMX'"
I get:

# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
CONFIG_VIDEO_MUX=y
CONFIG_VIDEO_IMX_VDOA=m
CONFIG_VIDEO_IMX_MEDIA=y
CONFIG_VIDEO_IMX_CSI=y
CONFIG_MUX_MMIO=y

I would really appreciate if anyone could help me trying to find out
what went wrong and why the /dev/media0 node is not showing up.

Many thanks and best regards,
Ibtsam Haq

Re: Fw: [PATCH v2] media: v4l2-core: fix size of devnode_nums[] bitarray

[Peter Geis]

Good Morning,

Great Success!
After several reboots and power-off cycles, the issue appears to have 
been solved by this patch.


Excellent work!

Thanks,
Peter Geis

On 04/05/2018 07:09 AM, Mauro Carvalho Chehab wrote:

Please test if this patch solves the issues for you.

Regards,
Mauro

Forwarded message:

Date: Thu,  5 Apr 2018 07:13:41 -0300
From: Mauro Carvalho Chehab 
To: Linux Media Mailing List 
Cc: Mauro Carvalho Chehab , Mauro Carvalho Chehab , Al 
Viro , Hans Verkuil , Laurent Pinchart 
, Sakari Ailus , 
sta...@vger.kernel.org
Subject: [PATCH v2] media: v4l2-core: fix size of devnode_nums[] bitarray


The size of devnode_nums[] bit array is too short to store information
for VFL_TYPE_TOUCH. That causes it to override other memory regions.

Thankfully, on recent reports, it is overriding video_device[] array,
trigging a WARN_ON(). Yet, it just warns about the problem, but let
the code excecuting, with generates an OOPS:

[   43.177394] WARNING: CPU: 1 PID: 711 at 
drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 
[videodev]
[   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d 
hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf 
joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media 
hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl 
snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc 
snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core 
snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl 
snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm 
kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul
[   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq 
aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd 
snd_timer intel_cstate intel_rapl_perf input_leds serio_raw 
intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop 
sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel 
intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me 
intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci 
nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport 
sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj 
hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass 
i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect
[   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video 
pinctrl_sunrisepoint pinctrl_intel
[   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
[   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
[   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
[   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
[   43.177484] RAX:  RBX: 0005 RCX: 
[   43.177485] RDX: c0c44cc0 RSI:  RDI: c0c44cc0
[   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 8eda1a51f018
[   43.177487] R10: 0600 R11: 03b6 R12: 
[   43.177488] R13: 0005 R14: c0c96900 R15: 8eda1d6d91c0
[   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
knlGS:
[   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
[   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 003606e0
[   43.177492] Call Trace:
[   43.177498]  ? devres_add+0x5f/0x70
[   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
[   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
[   43.177507]  driver_probe_device+0x310/0x480
[   43.177509]  __device_attach_driver+0x86/0x100
[   43.177511]  ? __driver_attach+0xf0/0xf0
[   43.177512]  bus_for_each_drv+0x6b/0xb0
[   43.177514]  __device_attach+0xdd/0x160
[   43.177516]  device_initial_probe+0x13/0x20
[   43.177518]  bus_probe_device+0x95/0xa0
[   43.177519]  device_add+0x44b/0x680
[   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
[   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
[   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
[   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
[   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
[   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
[   43.177547]  ? sysfs_create_link+0x25/0x40
[   43.177549]  driver_probe_device+0x310/0x480
[   43.177551]  

Re: [PATCH] media: v4l2-dev: use pr_foo() for printing messages

[Mauro Carvalho Chehab]

Em Thu, 5 Apr 2018 14:12:10 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Thu, Apr 05, 2018 at 07:34:39AM -0300, Mauro Carvalho Chehab wrote:
> > Instead of using printk() directly, use the pr_foo()
> > macros.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/v4l2-core/v4l2-dev.c | 45 
> > ++
> >  1 file changed, 26 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
> > b/drivers/media/v4l2-core/v4l2-dev.c
> > index 1d0b2208e8fb..530db8e482fb 100644
> > --- a/drivers/media/v4l2-core/v4l2-dev.c
> > +++ b/drivers/media/v4l2-core/v4l2-dev.c
> > @@ -16,6 +16,8 @@
> >   * - Added procfs support
> >   */
> >  
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > +
> >  #include 
> >  #include 
> >  #include 
> > @@ -34,6 +36,12 @@
> >  #define VIDEO_NUM_DEVICES  256
> >  #define VIDEO_NAME  "video4linux"
> >  
> > +#define dprintk(fmt, arg...) do {  \
> > +   printk(KERN_DEBUG pr_fmt("%s: " fmt),   \
> > +  __func__, ##arg);\
> > +} while (0)  
> 
> Any particular reason for introducing a new macro rather than using
> pr_debug()? I know it's adding the name of the function without requiring
> to explicitly add that below, but pr_debug("%s: ...", __func__); would be
> easier to read IMO.

Yes, there is. Nowadays, most systems are built with CONFIG_DYNAMIC_DEBUG,
as it is default on most distros.

It means that, in order to enable a debug message, one has to
explicitly enable the debug messages via /sys/kernel/debug/dynamic_debug.

In the case of videodev core, the debug messages are enabled, instead,
via vdev->dev_debug. It is really messy to have both mechanisms at the
same time to enable a debug message. We need to use either one or the
other.

Also, a change from vdev->dev_debug approach to dynamic_debug approach
is something that should happen at the entire subsystem.

Even if this is a good idea (I'm not convinced), this should be
done on a separate patch series.

So, this patch basically preserves the "vdev->dev_debug" debugging
mechanism without regressions.

> 
> > +
> > +
> >  /*
> >   * sysfs stuff
> >   */
> > @@ -309,7 +317,7 @@ static ssize_t v4l2_read(struct file *filp, char __user 
> > *buf,
> > ret = vdev->fops->read(filp, buf, sz, off);
> > if ((vdev->dev_debug & V4L2_DEV_DEBUG_FOP) &&
> > (vdev->dev_debug & V4L2_DEV_DEBUG_STREAMING))
> > -   printk(KERN_DEBUG "%s: read: %zd (%d)\n",
> > +   dprintk("%s: read: %zd (%d)\n",
> > video_device_node_name(vdev), sz, ret);
> > return ret;
> >  }
> > @@ -326,7 +334,7 @@ static ssize_t v4l2_write(struct file *filp, const char 
> > __user *buf,
> > ret = vdev->fops->write(filp, buf, sz, off);
> > if ((vdev->dev_debug & V4L2_DEV_DEBUG_FOP) &&
> > (vdev->dev_debug & V4L2_DEV_DEBUG_STREAMING))
> > -   printk(KERN_DEBUG "%s: write: %zd (%d)\n",
> > +   dprintk("%s: write: %zd (%d)\n",
> > video_device_node_name(vdev), sz, ret);
> > return ret;
> >  }
> > @@ -341,7 +349,7 @@ static __poll_t v4l2_poll(struct file *filp, struct 
> > poll_table_struct *poll)
> > if (video_is_registered(vdev))
> > res = vdev->fops->poll(filp, poll);
> > if (vdev->dev_debug & V4L2_DEV_DEBUG_POLL)
> > -   printk(KERN_DEBUG "%s: poll: %08x\n",
> > +   dprintk("%s: poll: %08x\n",
> > video_device_node_name(vdev), res);
> > return res;
> >  }
> > @@ -382,7 +390,7 @@ static unsigned long v4l2_get_unmapped_area(struct file 
> > *filp,
> > return -ENODEV;
> > ret = vdev->fops->get_unmapped_area(filp, addr, len, pgoff, flags);
> > if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
> > -   printk(KERN_DEBUG "%s: get_unmapped_area (%d)\n",
> > +   dprintk("%s: get_unmapped_area (%d)\n",
> > video_device_node_name(vdev), ret);
> > return ret;
> >  }
> > @@ -398,7 +406,7 @@ static int v4l2_mmap(struct file *filp, struct 
> > vm_area_struct *vm)
> > if (video_is_registered(vdev))
> > ret = vdev->fops->mmap(filp, vm);
> > if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
> > -   printk(KERN_DEBUG "%s: mmap (%d)\n",
> > +   dprintk("%s: mmap (%d)\n",
> > video_device_node_name(vdev), ret);
> > return ret;
> >  }
> > @@ -428,7 +436,7 @@ static int v4l2_open(struct inode *inode, struct file 
> > *filp)
> > }
> >  
> > if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
> > -   printk(KERN_DEBUG "%s: open (%d)\n",
> > +   dprintk("%s: open (%d)\n",
> > video_device_node_name(vdev), ret);
> > /* decrease the refcount in case of an error */
> > if (ret)
> > @@ -445,7 +453,7 @@ static int 

Re: [PATCH v2] media: v4l2-core: fix size of devnode_nums[] bitarray

[Michał Siemek]

Dnia 2018-04-05, o godz. 14:25:51
Jaak Ristioja  napisał(a):

> Yes, it solves the issue for me as far as I can tell. And so did the
> previous version of the patch.
> 
> Regards,
> J
> 
> On 05.04.2018 14:09, Mauro Carvalho Chehab wrote:
> > Please test if this patch solves the issues for you.
> > 
> > Regards,
> > Mauro
> > 
> > Forwarded message:
> > 
> > Date: Thu,  5 Apr 2018 07:13:41 -0300
> > From: Mauro Carvalho Chehab 
> > To: Linux Media Mailing List 
> > Cc: Mauro Carvalho Chehab , Mauro Carvalho
> > Chehab , Al Viro , Hans
> > Verkuil , Laurent Pinchart
> > , Sakari Ailus
> > , sta...@vger.kernel.org Subject: [PATCH
> > v2] media: v4l2-core: fix size of devnode_nums[] bitarray
> > 
> > 
> > The size of devnode_nums[] bit array is too short to store information
> > for VFL_TYPE_TOUCH. That causes it to override other memory regions.
> > 
> > Thankfully, on recent reports, it is overriding video_device[] array,
> > trigging a WARN_ON(). Yet, it just warns about the problem, but let
> > the code excecuting, with generates an OOPS:
> > 
> > [   43.177394] WARNING: CPU: 1 PID: 711 at
> > drivers/media/v4l2-core/v4l2-dev.c:945
> > __video_register_device+0xc99/0x1090 [videodev] [   43.177396] Modules
> > linked in: hid_sensor_custom hid_sensor_als hid_sensor_incl_3d
> > hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d
> > hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer
> > kfifo_buf joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio
> > videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common
> > videodev hid_multitouch media hid_sensor_hub binfmt_misc nls_iso8859_1
> > snd_hda_codec_hdmi arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core
> > snd_soc_sst_dsp snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi
> > snd_hda_codec_generic snd_soc_core snd_compress ac97_bus
> > snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl snd_hda_core
> > x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm
> > kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul
> > [   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211
> > snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd
> > glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds
> > serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore
> > ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad
> > int3400_thermal acpi_thermal_rel intel_pch_thermal
> > processor_thermal_device mac_hid int340x_thermal_zone mei_me
> > intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel
> > vfio_pci nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd
> > grace lp parport sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp
> > hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1
> > vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci
> > sysfillrect [   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid
> > wmi hid video pinctrl_sunrisepoint pinctrl_intel [   43.177474] CPU: 1
> > PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1 [   43.177475]
> > Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016 [   43.177481]
> > RIP: 0010:__video_register_device+0xc99/0x1090 [videodev] [   43.177482]
> > RSP: :a5c5c231b420 EFLAGS: 00010202 [   43.177484] RAX:
> >  RBX: 0005 RCX: 
> > [   43.177485] RDX: c0c44cc0 RSI:  RDI:
> > c0c44cc0 [   43.177486] RBP: a5c5c231b478 R08:
> > c0c96900 R09: 8eda1a51f018 [   43.177487] R10:
> > 0600 R11: 03b6 R12: 
> > [   43.177488] R13: 0005 R14: c0c96900 R15:
> > 8eda1d6d91c0 [   43.177489] FS:  7fd2d8ef2480()
> > GS:8eda3348() knlGS: [   43.177490] CS:  0010
> > DS:  ES:  CR0: 80050033 [   43.177491] CR2:
> > 7ffe0a6ad01c CR3: 000456ae2004 CR4: 003606e0
> > [   43.177492] Call Trace: [   43.177498]  ? devres_add+0x5f/0x70
> > [   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core] [   43.177505]
> > rmi_function_probe+0x25/0x30 [rmi_core] [   43.177507]
> > driver_probe_device+0x310/0x480 [   43.177509]
> > __device_attach_driver+0x86/0x100 [   43.177511]  ?
> > __driver_attach+0xf0/0xf0 [   43.177512]  bus_for_each_drv+0x6b/0xb0
> > [   43.177514]  __device_attach+0xdd/0x160 [   43.177516]
> > device_initial_probe+0x13/0x20 [   43.177518]  bus_probe_device+0x95/0xa0
> > [   43.177519]  device_add+0x44b/0x680 [   43.177522]
> > rmi_register_function+0x62/0xd0 [rmi_core] [   43.177525]
> > rmi_create_function+0x112/0x1a0 [rmi_core] [   43.177527]  ?
> > 

Re: [PATCH v6 2/2] media: video-i2c: add video-i2c driver

[Sakari Ailus]

Hi Hans,

On Thu, Apr 05, 2018 at 10:04:57AM +0200, Hans Verkuil wrote:
...
> >> +static int start_streaming(struct vb2_queue *vq, unsigned int count)
> >> +{
> >> +  struct video_i2c_data *data = vb2_get_drv_priv(vq);
> >> +  struct video_i2c_buffer *buf, *tmp;
> >> +
> >> +  if (data->kthread_vid_cap)
> >> +  return 0;
> >> +
> >> +  data->sequence = 0;
> >> +  data->kthread_vid_cap = kthread_run(video_i2c_thread_vid_cap, data,
> >> +  "%s-vid-cap", data->v4l2_dev.name);
> >> +  if (!IS_ERR(data->kthread_vid_cap))
> >> +  return 0;
> >> +
> >> +  spin_lock(>slock);
> >> +
> >> +  list_for_each_entry_safe(buf, tmp, >vid_cap_active, list) {
> >> +  list_del(>list);
> >> +  vb2_buffer_done(>vb.vb2_buf,
> >> +  VB2_BUF_STATE_QUEUED);
> > 
> > What's the purpose of this?
> 
> This is the error path (kthread_run failed), so all buffers need to be
> returned to vb2.

Ah, I missed that. Then, Matt, please ignore this comment and the one
below.

> 
> > 
> >> +  }
> >> +
> >> +  spin_unlock(>slock);
> >> +
> >> +  return PTR_ERR(data->kthread_vid_cap);
> > 
> > How about 0 instead?
> 
> This is the error path, so the error should be returned here. This code
> is correct.
> 
> > 
> >> +}
> >> +
> >> +static void stop_streaming(struct vb2_queue *vq)
> >> +{
> >> +  struct video_i2c_data *data = vb2_get_drv_priv(vq);
> >> +
> >> +  if (data->kthread_vid_cap == NULL)
> >> +  return;
> >> +
> >> +  kthread_stop(data->kthread_vid_cap);
> >> +
> >> +  spin_lock(>slock);
> >> +
> >> +  while (!list_empty(>vid_cap_active)) {
> >> +  struct video_i2c_buffer *buf;
> >> +
> >> +  buf = list_entry(data->vid_cap_active.next,
> > 
> > list_last_entry(>vid_cap_active, ...)?
> 
> Why? You're deleting the list, so whether you pick the first
> or last element really doesn't matter.

I rather wanted to suggest that there's no need to explicitly access the
linked list related structs, functions such as list_last_entry() (or
list_first_entry()) can be used instead.

It'd be also nice to align the loop construct with error handling path in
start_streaming() function above as they're doing the same things.

> > 
> >> +   struct video_i2c_buffer, list);
> >> +  list_del(>list);
> >> +  vb2_buffer_done(>vb.vb2_buf, VB2_BUF_STATE_ERROR);
> >> +  }
> >> +  spin_unlock(>slock);
> >> +
> >> +  data->kthread_vid_cap = NULL;

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH] media: v4l2-dev: use pr_foo() for printing messages

[Sakari Ailus]

Hi Mauro,

On Thu, Apr 05, 2018 at 07:34:39AM -0300, Mauro Carvalho Chehab wrote:
> Instead of using printk() directly, use the pr_foo()
> macros.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/v4l2-core/v4l2-dev.c | 45 
> ++
>  1 file changed, 26 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
> b/drivers/media/v4l2-core/v4l2-dev.c
> index 1d0b2208e8fb..530db8e482fb 100644
> --- a/drivers/media/v4l2-core/v4l2-dev.c
> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> @@ -16,6 +16,8 @@
>   *   - Added procfs support
>   */
>  
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
>  #include 
>  #include 
>  #include 
> @@ -34,6 +36,12 @@
>  #define VIDEO_NUM_DEVICES256
>  #define VIDEO_NAME  "video4linux"
>  
> +#define dprintk(fmt, arg...) do {\
> + printk(KERN_DEBUG pr_fmt("%s: " fmt),   \
> +__func__, ##arg);\
> +} while (0)

Any particular reason for introducing a new macro rather than using
pr_debug()? I know it's adding the name of the function without requiring
to explicitly add that below, but pr_debug("%s: ...", __func__); would be
easier to read IMO.

> +
> +
>  /*
>   *   sysfs stuff
>   */
> @@ -309,7 +317,7 @@ static ssize_t v4l2_read(struct file *filp, char __user 
> *buf,
>   ret = vdev->fops->read(filp, buf, sz, off);
>   if ((vdev->dev_debug & V4L2_DEV_DEBUG_FOP) &&
>   (vdev->dev_debug & V4L2_DEV_DEBUG_STREAMING))
> - printk(KERN_DEBUG "%s: read: %zd (%d)\n",
> + dprintk("%s: read: %zd (%d)\n",
>   video_device_node_name(vdev), sz, ret);
>   return ret;
>  }
> @@ -326,7 +334,7 @@ static ssize_t v4l2_write(struct file *filp, const char 
> __user *buf,
>   ret = vdev->fops->write(filp, buf, sz, off);
>   if ((vdev->dev_debug & V4L2_DEV_DEBUG_FOP) &&
>   (vdev->dev_debug & V4L2_DEV_DEBUG_STREAMING))
> - printk(KERN_DEBUG "%s: write: %zd (%d)\n",
> + dprintk("%s: write: %zd (%d)\n",
>   video_device_node_name(vdev), sz, ret);
>   return ret;
>  }
> @@ -341,7 +349,7 @@ static __poll_t v4l2_poll(struct file *filp, struct 
> poll_table_struct *poll)
>   if (video_is_registered(vdev))
>   res = vdev->fops->poll(filp, poll);
>   if (vdev->dev_debug & V4L2_DEV_DEBUG_POLL)
> - printk(KERN_DEBUG "%s: poll: %08x\n",
> + dprintk("%s: poll: %08x\n",
>   video_device_node_name(vdev), res);
>   return res;
>  }
> @@ -382,7 +390,7 @@ static unsigned long v4l2_get_unmapped_area(struct file 
> *filp,
>   return -ENODEV;
>   ret = vdev->fops->get_unmapped_area(filp, addr, len, pgoff, flags);
>   if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
> - printk(KERN_DEBUG "%s: get_unmapped_area (%d)\n",
> + dprintk("%s: get_unmapped_area (%d)\n",
>   video_device_node_name(vdev), ret);
>   return ret;
>  }
> @@ -398,7 +406,7 @@ static int v4l2_mmap(struct file *filp, struct 
> vm_area_struct *vm)
>   if (video_is_registered(vdev))
>   ret = vdev->fops->mmap(filp, vm);
>   if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
> - printk(KERN_DEBUG "%s: mmap (%d)\n",
> + dprintk("%s: mmap (%d)\n",
>   video_device_node_name(vdev), ret);
>   return ret;
>  }
> @@ -428,7 +436,7 @@ static int v4l2_open(struct inode *inode, struct file 
> *filp)
>   }
>  
>   if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
> - printk(KERN_DEBUG "%s: open (%d)\n",
> + dprintk("%s: open (%d)\n",
>   video_device_node_name(vdev), ret);
>   /* decrease the refcount in case of an error */
>   if (ret)
> @@ -445,7 +453,7 @@ static int v4l2_release(struct inode *inode, struct file 
> *filp)
>   if (vdev->fops->release)
>   ret = vdev->fops->release(filp);
>   if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
> - printk(KERN_DEBUG "%s: release\n",
> + dprintk("%s: release\n",
>   video_device_node_name(vdev));
>  
>   /* decrease the refcount unconditionally since the release()
> @@ -786,8 +794,7 @@ static int video_register_media_controller(struct 
> video_device *vdev, int type)
>   ret = media_device_register_entity(vdev->v4l2_dev->mdev,
>  >entity);
>   if (ret < 0) {
> - printk(KERN_WARNING
> - "%s: media_device_register_entity failed\n",
> + pr_warn("%s: media_device_register_entity failed\n",
>   __func__);
>   return ret;
>   }
> @@ -869,7 +876,7 @@ int 

Fw: [PATCH v2] media: v4l2-core: fix size of devnode_nums[] bitarray

[Mauro Carvalho Chehab]

Please test if this patch solves the issues for you.

Regards,
Mauro

Forwarded message:

Date: Thu,  5 Apr 2018 07:13:41 -0300
From: Mauro Carvalho Chehab 
To: Linux Media Mailing List 
Cc: Mauro Carvalho Chehab , Mauro Carvalho Chehab 
, Al Viro , Hans Verkuil 
, Laurent Pinchart 
, Sakari Ailus 
, sta...@vger.kernel.org
Subject: [PATCH v2] media: v4l2-core: fix size of devnode_nums[] bitarray


The size of devnode_nums[] bit array is too short to store information
for VFL_TYPE_TOUCH. That causes it to override other memory regions.

Thankfully, on recent reports, it is overriding video_device[] array,
trigging a WARN_ON(). Yet, it just warns about the problem, but let
the code excecuting, with generates an OOPS:

[   43.177394] WARNING: CPU: 1 PID: 711 at 
drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 
[videodev]
[   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d 
hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf 
joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media 
hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl 
snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc 
snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core 
snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl 
snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm 
kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul
[   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq 
aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd 
snd_timer intel_cstate intel_rapl_perf input_leds serio_raw 
intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop 
sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel 
intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me 
intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci 
nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport 
sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj 
hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass 
i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect
[   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video 
pinctrl_sunrisepoint pinctrl_intel
[   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
[   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
[   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
[   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
[   43.177484] RAX:  RBX: 0005 RCX: 
[   43.177485] RDX: c0c44cc0 RSI:  RDI: c0c44cc0
[   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 8eda1a51f018
[   43.177487] R10: 0600 R11: 03b6 R12: 
[   43.177488] R13: 0005 R14: c0c96900 R15: 8eda1d6d91c0
[   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
knlGS:
[   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
[   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 003606e0
[   43.177492] Call Trace:
[   43.177498]  ? devres_add+0x5f/0x70
[   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
[   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
[   43.177507]  driver_probe_device+0x310/0x480
[   43.177509]  __device_attach_driver+0x86/0x100
[   43.177511]  ? __driver_attach+0xf0/0xf0
[   43.177512]  bus_for_each_drv+0x6b/0xb0
[   43.177514]  __device_attach+0xdd/0x160
[   43.177516]  device_initial_probe+0x13/0x20
[   43.177518]  bus_probe_device+0x95/0xa0
[   43.177519]  device_add+0x44b/0x680
[   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
[   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
[   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
[   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
[   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
[   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
[   43.177547]  ? sysfs_create_link+0x25/0x40
[   43.177549]  driver_probe_device+0x310/0x480
[   43.177551]  __device_attach_driver+0x86/0x100
[   43.177553]  ? __driver_attach+0xf0/0xf0
[   43.177554]  bus_for_each_drv+0x6b/0xb0
[   43.177556]  __device_attach+0xdd/0x160
[   43.177558]  device_initial_probe+0x13/0x20
[   43.177560]  

[v4l-utils RFC 4/6] mediatext: Extract list of V4L2 pixel format strings and 4cc codes

[Sakari Ailus]

Extract the list of V4L2 pixel format strings and 4cc codes from
videodev2.h for use in mediatext in order to convert user given format
names to 4cc codes that IOCTLs use.

Signed-off-by: Sakari Ailus 
---
 utils/media-ctl/Makefile.am | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/utils/media-ctl/Makefile.am b/utils/media-ctl/Makefile.am
index ee7dcc9..8fe653d 100644
--- a/utils/media-ctl/Makefile.am
+++ b/utils/media-ctl/Makefile.am
@@ -12,7 +12,12 @@ media-bus-format-codes.h: 
../../include/linux/media-bus-format.h
sed -e '/#define MEDIA_BUS_FMT/ ! d; s/.*#define //; /FIXED/ d; 
s/\t.*//; s/.*/ &,/;' \
< $< > $@
 
-BUILT_SOURCES = media-bus-format-names.h media-bus-format-codes.h
+v4l2-pix-formats.h: ../../include/linux/videodev2.h
+   sed -e '/#define V4L2_PIX_FMT_/ ! d; s/.*FMT_//; s/[\t ].*//; s/.*/{ 
\"&\", V4L2_PIX_FMT_& },/;' \
+   < $< > $@
+
+BUILT_SOURCES = media-bus-format-names.h media-bus-format-codes.h \
+   v4l2-pix-formats.h
 CLEANFILES = $(BUILT_SOURCES)
 
 nodist_libv4l2subdev_la_SOURCES = $(BUILT_SOURCES)
-- 
2.7.4

[v4l-utils RFC 0/6] Mediatext test program for request API tests

[Sakari Ailus]

Hi folks,

Here's a refreshed RFC set to add the mediatext test program. It is well
suited for testing requests, as it can work with multiple devices
simultaneously as well as is easy to control through a bash script.

Only buffers are supported with requests, controls are not yet; still
adding support for controls wouldn't be much of work. I'm posting this as
RFC as the API coverage isn't great. What works now (as in this test
program) is requests with vim2m --- two bash scripts are included in the
last patch for that. The request API set v9 requires some adjusting, I
haven't tested v10 yet.

I'd say this is much closer being a meaningful part of v4l-utils, assuming
more test programs are seen to fit there.

Comments would be welcome.

Sakari Ailus (6):
  Linux kernel header update
  Make v4l-utils compile with request-related changes
  libmediactl: Add open, close and fd to public API
  mediatext: Extract list of V4L2 pixel format strings and 4cc codes
  mediatext: Add library
  mediatext: Add vivid tests

 include/linux/cec-funcs.h|  300 ++--
 include/linux/cec.h  |   40 +-
 include/linux/media.h|8 +
 include/linux/v4l2-dv-timings.h  |  979 
 include/linux/videodev2.h|   14 +-
 lib/libv4l2/libv4l2.c|4 +-
 libmediatext.pc.in   |   10 +
 utils/media-ctl/Makefile.am  |   18 +-
 utils/media-ctl/libmediactl.c|9 +-
 utils/media-ctl/libmediatext.pc.in   |   10 +
 utils/media-ctl/mediactl.h   |4 +
 utils/media-ctl/mediatext-test.c |  127 ++
 utils/media-ctl/mediatext.c  | 2176 ++
 utils/media-ctl/mediatext.h  |   33 +
 utils/media-ctl/tests/test-vivid-mc.bash |   86 +
 utils/media-ctl/tests/test-vivid.bash|   59 +
 utils/v4l2-compliance/v4l2-test-buffers.cpp  |2 +-
 utils/v4l2-compliance/v4l2-test-controls.cpp |4 -
 18 files changed, 3699 insertions(+), 184 deletions(-)
 create mode 100644 include/linux/v4l2-dv-timings.h
 create mode 100644 libmediatext.pc.in
 create mode 100644 utils/media-ctl/libmediatext.pc.in
 create mode 100644 utils/media-ctl/mediatext-test.c
 create mode 100644 utils/media-ctl/mediatext.c
 create mode 100644 utils/media-ctl/mediatext.h
 create mode 100755 utils/media-ctl/tests/test-vivid-mc.bash
 create mode 100755 utils/media-ctl/tests/test-vivid.bash

-- 
2.7.4

[v4l-utils RFC 5/6] mediatext: Add library

[Sakari Ailus]

libmediatext is a helper library for converting configurations (Media
controller links, V4L2 controls and V4L2 sub-device media bus formats and
selections) from text-based form into IOCTLs.

libmediatext depends on libv4l2subdev and libmediactl.

The patch includes a test program, mediatext-test, that can be used to
write tests in interpreted languages such as shell scripts.

Signed-off-by: Sakari Ailus 
Signed-off-by: Teemu Tuominen 
---
 libmediatext.pc.in |   10 +
 utils/media-ctl/Makefile.am|   11 +-
 utils/media-ctl/libmediatext.pc.in |   10 +
 utils/media-ctl/mediatext-test.c   |  127 +++
 utils/media-ctl/mediatext.c| 2176 
 utils/media-ctl/mediatext.h|   33 +
 6 files changed, 2365 insertions(+), 2 deletions(-)
 create mode 100644 libmediatext.pc.in
 create mode 100644 utils/media-ctl/libmediatext.pc.in
 create mode 100644 utils/media-ctl/mediatext-test.c
 create mode 100644 utils/media-ctl/mediatext.c
 create mode 100644 utils/media-ctl/mediatext.h

diff --git a/libmediatext.pc.in b/libmediatext.pc.in
new file mode 100644
index 000..6aa6353
--- /dev/null
+++ b/libmediatext.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libmediatext
+Description: Media controller and V4L2 text-based configuration library
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
+Libs: -L${libdir} -lmediatext
diff --git a/utils/media-ctl/Makefile.am b/utils/media-ctl/Makefile.am
index 8fe653d..ddbc453 100644
--- a/utils/media-ctl/Makefile.am
+++ b/utils/media-ctl/Makefile.am
@@ -1,4 +1,4 @@
-noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la
+noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la libmediatext.la
 
 libmediactl_la_SOURCES = libmediactl.c mediactl-priv.h
 libmediactl_la_CFLAGS = -static $(LIBUDEV_CFLAGS)
@@ -26,9 +26,16 @@ libv4l2subdev_la_LIBADD = libmediactl.la
 libv4l2subdev_la_CFLAGS = -static
 libv4l2subdev_la_LDFLAGS = -static
 
+libmediatext_la_SOURCES = mediatext.c
+libmediatext_la_CFLAGS = -static $(LIBUDEV_CFLAGS)
+libmediatext_la_LDFLAGS = -static $(LIBUDEV_LIBS)
+
 mediactl_includedir=$(includedir)/mediactl
 noinst_HEADERS = mediactl.h v4l2subdev.h
 
-bin_PROGRAMS = media-ctl
+bin_PROGRAMS = media-ctl mediatext
 media_ctl_SOURCES = media-ctl.c options.c options.h tools.h
 media_ctl_LDADD = libmediactl.la libv4l2subdev.la
+mediatext_SOURCES = mediatext-test.c
+mediatext_LDFLAGS = $(STATIC_LDFLAGS)
+mediatext_LDADD = libmediatext.la libmediactl.la libv4l2subdev.la
diff --git a/utils/media-ctl/libmediatext.pc.in 
b/utils/media-ctl/libmediatext.pc.in
new file mode 100644
index 000..6aa6353
--- /dev/null
+++ b/utils/media-ctl/libmediatext.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libmediatext
+Description: Media controller and V4L2 text-based configuration library
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
+Libs: -L${libdir} -lmediatext
diff --git a/utils/media-ctl/mediatext-test.c b/utils/media-ctl/mediatext-test.c
new file mode 100644
index 000..77e8dc7
--- /dev/null
+++ b/utils/media-ctl/mediatext-test.c
@@ -0,0 +1,127 @@
+/*
+ * libmediatext test program
+ *
+ * Copyright (C) 2013--2016 Intel Corporation
+ *
+ * Contact: Sakari Ailus 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; either version 2.1 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 Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mediactl.h"
+#include "mediatext.h"
+
+static const struct option opts[] = {
+   { "device", 1, 0, 'd', },
+   { "coproc", 0, 0, 'c', },
+   { "fd", 1, 0, 'f', },
+   { "help", 0, 0, 'h', },
+   { "verbose", 0, 0, 'v', },
+   { 0 },
+};
+
+void help(char *myname)
+{
+   fprintf(stderr, "usage: %s  \n\n", myname);
+   fprintf(stderr, "\tstring := [ v4l2-ctrl | v4l2-mbus | link-reset | 
link-conf]\n\n");
+   fprintf(stderr, "\tv4l2-ctrl := \"entity\" ctrl_type ctrl_id 
ctrl_value\n");
+   fprintf(stderr, "\tctrl_type := [ int | int64 | bitmask ]\n");
+   fprintf(stderr, "\tctrl_value := [ %%d | %%PRId64 | bitmask_value ]\n");
+   fprintf(stderr, "\tbitmask_value := b\n\n");
+   fprintf(stderr, "\tv4l2-mbus := \n");
+   

[v4l-utils RFC 3/6] libmediactl: Add open, close and fd to public API

[Sakari Ailus]

Add functions to open and close the media device as well as to obtain its
fd.

Signed-off-by: Sakari Ailus 
---
 utils/media-ctl/libmediactl.c | 9 +++--
 utils/media-ctl/mediactl.h| 4 
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index 1fd6525..e20ab97 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -175,7 +175,7 @@ const struct media_entity_desc 
*media_entity_get_info(struct media_entity *entit
  * Open/close
  */
 
-static int media_device_open(struct media_device *media)
+int media_device_open(struct media_device *media)
 {
int ret;
 
@@ -195,7 +195,12 @@ static int media_device_open(struct media_device *media)
return 0;
 }
 
-static void media_device_close(struct media_device *media)
+int media_device_fd(struct media_device *media)
+{
+   return media->fd;
+}
+
+void media_device_close(struct media_device *media)
 {
if (media->fd != -1) {
close(media->fd);
diff --git a/utils/media-ctl/mediactl.h b/utils/media-ctl/mediactl.h
index af36051..5e325c4 100644
--- a/utils/media-ctl/mediactl.h
+++ b/utils/media-ctl/mediactl.h
@@ -59,6 +59,10 @@ struct media_entity;
  */
 struct media_device *media_device_new(const char *devnode);
 
+int media_device_open(struct media_device *media);
+int media_device_fd(struct media_device *media);
+void media_device_close(struct media_device *media);
+
 /**
  * @brief Create a new emulated media device.
  * @param info - device information.
-- 
2.7.4

[v4l-utils RFC 1/6] Linux kernel header update

[Sakari Ailus]

This includes kernel headers up to Hans's request API v9 patchset.

Signed-off-by: Sakari Ailus 
---
 include/linux/cec-funcs.h   | 300 ++--
 include/linux/cec.h |  40 +-
 include/linux/media.h   |   8 +
 include/linux/v4l2-dv-timings.h | 979 
 include/linux/videodev2.h   |  14 +-
 5 files changed, 1169 insertions(+), 172 deletions(-)
 create mode 100644 include/linux/v4l2-dv-timings.h

diff --git a/include/linux/cec-funcs.h b/include/linux/cec-funcs.h
index 8997d50..6daa73d 100644
--- a/include/linux/cec-funcs.h
+++ b/include/linux/cec-funcs.h
@@ -11,7 +11,7 @@
 #include 
 
 /* One Touch Play Feature */
-static inline void cec_msg_active_source(struct cec_msg *msg, __u16 phys_addr)
+static __inline__ void cec_msg_active_source(struct cec_msg *msg, __u16 
phys_addr)
 {
msg->len = 4;
msg->msg[0] |= 0xf; /* broadcast */
@@ -20,19 +20,19 @@ static inline void cec_msg_active_source(struct cec_msg 
*msg, __u16 phys_addr)
msg->msg[3] = phys_addr & 0xff;
 }
 
-static inline void cec_ops_active_source(const struct cec_msg *msg,
+static __inline__ void cec_ops_active_source(const struct cec_msg *msg,
 __u16 *phys_addr)
 {
*phys_addr = (msg->msg[2] << 8) | msg->msg[3];
 }
 
-static inline void cec_msg_image_view_on(struct cec_msg *msg)
+static __inline__ void cec_msg_image_view_on(struct cec_msg *msg)
 {
msg->len = 2;
msg->msg[1] = CEC_MSG_IMAGE_VIEW_ON;
 }
 
-static inline void cec_msg_text_view_on(struct cec_msg *msg)
+static __inline__ void cec_msg_text_view_on(struct cec_msg *msg)
 {
msg->len = 2;
msg->msg[1] = CEC_MSG_TEXT_VIEW_ON;
@@ -40,7 +40,7 @@ static inline void cec_msg_text_view_on(struct cec_msg *msg)
 
 
 /* Routing Control Feature */
-static inline void cec_msg_inactive_source(struct cec_msg *msg,
+static __inline__ void cec_msg_inactive_source(struct cec_msg *msg,
   __u16 phys_addr)
 {
msg->len = 4;
@@ -49,13 +49,13 @@ static inline void cec_msg_inactive_source(struct cec_msg 
*msg,
msg->msg[3] = phys_addr & 0xff;
 }
 
-static inline void cec_ops_inactive_source(const struct cec_msg *msg,
+static __inline__ void cec_ops_inactive_source(const struct cec_msg *msg,
   __u16 *phys_addr)
 {
*phys_addr = (msg->msg[2] << 8) | msg->msg[3];
 }
 
-static inline void cec_msg_request_active_source(struct cec_msg *msg,
+static __inline__ void cec_msg_request_active_source(struct cec_msg *msg,
 int reply)
 {
msg->len = 2;
@@ -64,7 +64,7 @@ static inline void cec_msg_request_active_source(struct 
cec_msg *msg,
msg->reply = reply ? CEC_MSG_ACTIVE_SOURCE : 0;
 }
 
-static inline void cec_msg_routing_information(struct cec_msg *msg,
+static __inline__ void cec_msg_routing_information(struct cec_msg *msg,
   __u16 phys_addr)
 {
msg->len = 4;
@@ -74,13 +74,13 @@ static inline void cec_msg_routing_information(struct 
cec_msg *msg,
msg->msg[3] = phys_addr & 0xff;
 }
 
-static inline void cec_ops_routing_information(const struct cec_msg *msg,
+static __inline__ void cec_ops_routing_information(const struct cec_msg *msg,
   __u16 *phys_addr)
 {
*phys_addr = (msg->msg[2] << 8) | msg->msg[3];
 }
 
-static inline void cec_msg_routing_change(struct cec_msg *msg,
+static __inline__ void cec_msg_routing_change(struct cec_msg *msg,
  int reply,
  __u16 orig_phys_addr,
  __u16 new_phys_addr)
@@ -95,7 +95,7 @@ static inline void cec_msg_routing_change(struct cec_msg *msg,
msg->reply = reply ? CEC_MSG_ROUTING_INFORMATION : 0;
 }
 
-static inline void cec_ops_routing_change(const struct cec_msg *msg,
+static __inline__ void cec_ops_routing_change(const struct cec_msg *msg,
  __u16 *orig_phys_addr,
  __u16 *new_phys_addr)
 {
@@ -103,7 +103,7 @@ static inline void cec_ops_routing_change(const struct 
cec_msg *msg,
*new_phys_addr = (msg->msg[4] << 8) | msg->msg[5];
 }
 
-static inline void cec_msg_set_stream_path(struct cec_msg *msg, __u16 
phys_addr)
+static __inline__ void cec_msg_set_stream_path(struct cec_msg *msg, __u16 
phys_addr)
 {
msg->len = 4;
msg->msg[0] |= 0xf; /* broadcast */
@@ -112,7 +112,7 @@ static inline void cec_msg_set_stream_path(struct cec_msg 
*msg, __u16 phys_addr)
msg->msg[3] = phys_addr & 0xff;
 }
 
-static inline void cec_ops_set_stream_path(const struct cec_msg *msg,
+static __inline__ void cec_ops_set_stream_path(const struct cec_msg *msg,
   __u16 

[v4l-utils RFC 6/6] mediatext: Add vivid tests

[Sakari Ailus]

Add two scripts for vivid tests, with and without using requests.

Signed-off-by: Sakari Ailus 
---
 utils/media-ctl/tests/test-vivid-mc.bash | 86 
 utils/media-ctl/tests/test-vivid.bash| 59 ++
 2 files changed, 145 insertions(+)
 create mode 100755 utils/media-ctl/tests/test-vivid-mc.bash
 create mode 100755 utils/media-ctl/tests/test-vivid.bash

diff --git a/utils/media-ctl/tests/test-vivid-mc.bash 
b/utils/media-ctl/tests/test-vivid-mc.bash
new file mode 100755
index 000..40c2e7d
--- /dev/null
+++ b/utils/media-ctl/tests/test-vivid-mc.bash
@@ -0,0 +1,86 @@
+#!/bin/bash
+
+coproc mediatext -c 2>&1
+
+# read initialisation
+read -ru ${COPROC[0]}; eval $REPLY
+
+cat <&${COPROC[1]}
+verbose true
+
+v4l open entity="vim2m" name=vim
+v4l fmt vdev=vim type=VIDEO_OUTPUT width=480 height=320 \
+   pixelformat=RGB565X bytesperline=0 num_planes=1
+v4l reqbufs vdev=vim type=VIDEO_OUTPUT count=3 memory=MMAP
+v4l fmt vdev=vim type=VIDEO_CAPTURE width=480 height=320 \
+   pixelformat=RGB565X bytesperline=0 num_planes=1
+v4l reqbufs vdev=vim type=VIDEO_CAPTURE count=3 memory=MMAP
+
+media req-create req=foo
+media req-create req=foo1
+media req-create req=foo2
+
+v4l io vdev=vim type=VIDEO_OUTPUT fname=/bin/bash
+v4l io vdev=vim type=VIDEO_OUTPUT fname=/bin/systemctl
+v4l io vdev=vim type=VIDEO_OUTPUT fname=/vmlinuz
+
+v4l qbuf vdev=vim type=VIDEO_OUTPUT req=foo
+v4l qbuf vdev=vim type=VIDEO_OUTPUT req=foo1
+v4l qbuf vdev=vim type=VIDEO_CAPTURE req=foo1
+v4l qbuf vdev=vim type=VIDEO_CAPTURE req=foo
+
+media req-queue req=foo
+
+v4l qbuf vdev=vim type=VIDEO_OUTPUT req=foo2
+v4l qbuf vdev=vim type=VIDEO_CAPTURE req=foo2
+
+v4l streamon vdev=vim type=VIDEO_CAPTURE
+v4l streamon vdev=vim type=VIDEO_OUTPUT
+
+media req-queue req=foo2
+media req-queue req=foo1
+
+EOF
+
+queued=3
+finished=0
+
+while IFS= read -ru ${COPROC[0]}; do
+   unset p; declare -A p
+   eval eval_line $REPLY
+   echo $REPLY
+   #echo ${p[event]}
+   case ${p[event]} in
+   dqbuf)
+   #echo seq ${p[seq]}
+   if [ ${p[type]} == VIDEO_CAPTURE ]; then
+   echo v4l io vdev=vim type=VIDEO_CAPTURE \
+   sequence=${p[seq]} >&${COPROC[1]}
+   fi
+   ;;
+   request-complete)
+   finished=$(($finished+1));
+   if (($queued < 10)); then
+   queued=$(($queued + 1))
+   cat <&${COPROC[1]}
+   media req-create req=${p[req]}
+   v4l io vdev=vim type=VIDEO_OUTPUT fname=/bin/tar
+   v4l qbuf vdev=vim type=VIDEO_OUTPUT 
req=${p[req]}
+   v4l qbuf vdev=vim type=VIDEO_CAPTURE 
req=${p[req]}
+   media req-queue req=${p[req]}
+EOF
+   fi
+   echo $queued requests queued, $finished finished
+   if (($finished == 10)); then
+   cat <&${COPROC[1]}
+   v4l streamoff vdev=vim type=VIDEO_CAPTURE
+   v4l streamoff vdev=vim type=VIDEO_OUTPUT
+   v4l reqbufs vdev=vim type=VIDEO_CAPTURE count=0 
memory=MMAP
+   v4l reqbufs vdev=vim type=VIDEO_OUTPUT count=0 
memory=MMAP
+   quit
+EOF
+   exit 0
+   fi
+   ;;
+   esac;
+done
diff --git a/utils/media-ctl/tests/test-vivid.bash 
b/utils/media-ctl/tests/test-vivid.bash
new file mode 100755
index 000..3c9b2f4
--- /dev/null
+++ b/utils/media-ctl/tests/test-vivid.bash
@@ -0,0 +1,59 @@
+#!/bin/bash
+
+coproc mediatext -c 2>&1
+
+# read initialisation
+read -ru ${COPROC[0]}; eval $REPLY
+
+cat <&${COPROC[1]}
+verbose true
+
+v4l open entity="vim2m" name=vim
+v4l fmt vdev=vim type=VIDEO_OUTPUT width=480 height=320 \
+   pixelformat=RGB565X bytesperline=0 num_planes=1
+v4l reqbufs vdev=vim type=VIDEO_OUTPUT count=3 memory=MMAP
+v4l fmt vdev=vim type=VIDEO_CAPTURE width=480 height=320 \
+   pixelformat=RGB565X bytesperline=0 num_planes=1
+v4l reqbufs vdev=vim type=VIDEO_CAPTURE count=3 memory=MMAP
+
+v4l io vdev=vim type=VIDEO_OUTPUT fname=/bin/bash
+v4l io vdev=vim type=VIDEO_OUTPUT fname=/bin/systemctl
+v4l io vdev=vim type=VIDEO_OUTPUT fname=/vmlinuz
+v4l qbuf vdev=vim type=VIDEO_OUTPUT
+v4l qbuf vdev=vim type=VIDEO_OUTPUT
+v4l qbuf vdev=vim type=VIDEO_CAPTURE
+v4l qbuf vdev=vim type=VIDEO_CAPTURE
+
+v4l streamon vdev=vim type=VIDEO_CAPTURE
+v4l streamon vdev=vim type=VIDEO_OUTPUT
+EOF
+
+while IFS= read -ru ${COPROC[0]} line; do
+   unset p; declare -A p
+   eval eval_line $line
+   echo $line
+   #echo ${p[event]}
+   case ${p[event]} in
+   dqbuf)
+   #echo seq ${p[seq]}
+   if [ ${p[type]} == VIDEO_CAPTURE ]; then
+   echo v4l 

[v4l-utils RFC 2/6] Make v4l-utils compile with request-related changes

[Sakari Ailus]

Mostly remove zero reserved field checks.

Signed-off-by: Sakari Ailus 
---
 lib/libv4l2/libv4l2.c| 4 ++--
 utils/v4l2-compliance/v4l2-test-buffers.cpp  | 2 +-
 utils/v4l2-compliance/v4l2-test-controls.cpp | 4 
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index 2db25d1..47eadda 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -190,7 +190,7 @@ static int v4l2_map_buffers(int index)
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
buf.memory = V4L2_MEMORY_MMAP;
buf.index = i;
-   buf.reserved = buf.reserved2 = 0;
+   buf.reserved = buf.request_fd = 0;
result = devices[index].dev_ops->ioctl(
devices[index].dev_ops_priv,
devices[index].fd, VIDIOC_QUERYBUF, );
@@ -579,7 +579,7 @@ static int v4l2_buffers_mapped(int index)
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
buf.memory = V4L2_MEMORY_MMAP;
buf.index = i;
-   buf.reserved = buf.reserved2 = 0;
+   buf.reserved = buf.request_fd = 0;
if (devices[index].dev_ops->ioctl(
devices[index].dev_ops_priv,
devices[index].fd, VIDIOC_QUERYBUF,
diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp 
b/utils/v4l2-compliance/v4l2-test-buffers.cpp
index 9b0933e..a9e50b4 100644
--- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
+++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
@@ -196,7 +196,7 @@ int buffer::check(unsigned type, unsigned memory, unsigned 
index,
fail_on_test(g_memory() != memory);
fail_on_test(g_index() >= VIDEO_MAX_FRAME);
fail_on_test(g_index() != index);
-   fail_on_test(buf.reserved2 || buf.reserved);
+   fail_on_test(buf.request_fd || buf.reserved);
fail_on_test(timestamp != V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC &&
 timestamp != V4L2_BUF_FLAG_TIMESTAMP_COPY);
fail_on_test(timestamp_src != V4L2_BUF_FLAG_TSTAMP_SRC_SOE &&
diff --git a/utils/v4l2-compliance/v4l2-test-controls.cpp 
b/utils/v4l2-compliance/v4l2-test-controls.cpp
index 508daf0..b9a8978 100644
--- a/utils/v4l2-compliance/v4l2-test-controls.cpp
+++ b/utils/v4l2-compliance/v4l2-test-controls.cpp
@@ -589,8 +589,6 @@ int testExtendedControls(struct node *node)
return fail("field which changed\n");
if (ctrls.count)
return fail("field count changed\n");
-   if (check_0(ctrls.reserved, sizeof(ctrls.reserved)))
-   return fail("reserved not zeroed\n");
 
memset(, 0, sizeof(ctrls));
ret = doioctl(node, VIDIOC_TRY_EXT_CTRLS, );
@@ -602,8 +600,6 @@ int testExtendedControls(struct node *node)
return fail("field which changed\n");
if (ctrls.count)
return fail("field count changed\n");
-   if (check_0(ctrls.reserved, sizeof(ctrls.reserved)))
-   return fail("reserved not zeroed\n");
 
for (iter = node->controls.begin(); iter != node->controls.end(); 
++iter) {
test_query_ext_ctrl  = iter->second;
-- 
2.7.4

Re: [PATCH v2] media: v4l2-core: fix size of devnode_nums[] bitarray

[Mauro Carvalho Chehab]

Em Thu, 5 Apr 2018 12:16:13 +0200
Hans Verkuil  escreveu:

> On 05/04/18 12:13, Mauro Carvalho Chehab wrote:
> > The size of devnode_nums[] bit array is too short to store information
> > for VFL_TYPE_TOUCH. That causes it to override other memory regions.
> > 
> > Thankfully, on recent reports, it is overriding video_device[] array,
> > trigging a WARN_ON(). Yet, it just warns about the problem, but let
> > the code excecuting, with generates an OOPS:
> > 
> > [   43.177394] WARNING: CPU: 1 PID: 711 at 
> > drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 
> > [videodev]
> > [   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
> > hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d 
> > hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger 
> > industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common 
> > hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops 
> > videobuf2_v4l2 videobuf2_common videodev hid_multitouch media 
> > hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 
> > snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp 
> > snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic 
> > snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel 
> > snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep 
> > intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi snd_seq_midi_event 
> > snd_rawmidi crct10dif_pclmul
> > [   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 
> > snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd 
> > glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds 
> > serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore 
> > ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad 
> > int3400_thermal acpi_thermal_rel intel_pch_thermal processor_thermal_device 
> > mac_hid int340x_thermal_zone mei_me intel_soc_dts_iosf mei intel_lpss_pci 
> > shpchp intel_lpss sch_fq_codel vfio_pci nfsd vfio_virqfd parport_pc ppdev 
> > auth_rpcgss nfs_acl lockd grace lp parport sunrpc ip_tables x_tables 
> > autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid kvmgt 
> > vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i915 i2c_algo_bit 
> > drm_kms_helper syscopyarea sdhci_pci sysfillrect
> > [   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video 
> > pinctrl_sunrisepoint pinctrl_intel
> > [   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
> > [   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
> > [   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
> > [   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
> > [   43.177484] RAX:  RBX: 0005 RCX: 
> > 
> > [   43.177485] RDX: c0c44cc0 RSI:  RDI: 
> > c0c44cc0
> > [   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 
> > 8eda1a51f018
> > [   43.177487] R10: 0600 R11: 03b6 R12: 
> > 
> > [   43.177488] R13: 0005 R14: c0c96900 R15: 
> > 8eda1d6d91c0
> > [   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
> > knlGS:
> > [   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
> > [   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 
> > 003606e0
> > [   43.177492] Call Trace:
> > [   43.177498]  ? devres_add+0x5f/0x70
> > [   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
> > [   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
> > [   43.177507]  driver_probe_device+0x310/0x480
> > [   43.177509]  __device_attach_driver+0x86/0x100
> > [   43.177511]  ? __driver_attach+0xf0/0xf0
> > [   43.177512]  bus_for_each_drv+0x6b/0xb0
> > [   43.177514]  __device_attach+0xdd/0x160
> > [   43.177516]  device_initial_probe+0x13/0x20
> > [   43.177518]  bus_probe_device+0x95/0xa0
> > [   43.177519]  device_add+0x44b/0x680
> > [   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
> > [   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
> > [   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
> > [   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
> > [   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
> > [   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
> > [   43.177547]  ? sysfs_create_link+0x25/0x40
> > [   43.177549]  driver_probe_device+0x310/0x480
> > [   43.177551]  __device_attach_driver+0x86/0x100
> > [   43.177553]  ? __driver_attach+0xf0/0xf0
> > [   43.177554]  bus_for_each_drv+0x6b/0xb0
> > [   43.177556]  __device_attach+0xdd/0x160
> > [   43.177558]  device_initial_probe+0x13/0x20
> > [   43.177560]  bus_probe_device+0x95/0xa0
> > [   43.177561]  device_add+0x44b/0x680
> > [   43.177564]  rmi_register_transport_device+0x84/0x100 [rmi_core]
> > [   43.177568]  

[PATCH] media: v4l2-dev: use pr_foo() for printing messages

[Mauro Carvalho Chehab]

Instead of using printk() directly, use the pr_foo()
macros.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-dev.c | 45 ++
 1 file changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index 1d0b2208e8fb..530db8e482fb 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -16,6 +16,8 @@
  * - Added procfs support
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -34,6 +36,12 @@
 #define VIDEO_NUM_DEVICES  256
 #define VIDEO_NAME  "video4linux"
 
+#define dprintk(fmt, arg...) do {  \
+   printk(KERN_DEBUG pr_fmt("%s: " fmt),   \
+  __func__, ##arg);\
+} while (0)
+
+
 /*
  * sysfs stuff
  */
@@ -309,7 +317,7 @@ static ssize_t v4l2_read(struct file *filp, char __user 
*buf,
ret = vdev->fops->read(filp, buf, sz, off);
if ((vdev->dev_debug & V4L2_DEV_DEBUG_FOP) &&
(vdev->dev_debug & V4L2_DEV_DEBUG_STREAMING))
-   printk(KERN_DEBUG "%s: read: %zd (%d)\n",
+   dprintk("%s: read: %zd (%d)\n",
video_device_node_name(vdev), sz, ret);
return ret;
 }
@@ -326,7 +334,7 @@ static ssize_t v4l2_write(struct file *filp, const char 
__user *buf,
ret = vdev->fops->write(filp, buf, sz, off);
if ((vdev->dev_debug & V4L2_DEV_DEBUG_FOP) &&
(vdev->dev_debug & V4L2_DEV_DEBUG_STREAMING))
-   printk(KERN_DEBUG "%s: write: %zd (%d)\n",
+   dprintk("%s: write: %zd (%d)\n",
video_device_node_name(vdev), sz, ret);
return ret;
 }
@@ -341,7 +349,7 @@ static __poll_t v4l2_poll(struct file *filp, struct 
poll_table_struct *poll)
if (video_is_registered(vdev))
res = vdev->fops->poll(filp, poll);
if (vdev->dev_debug & V4L2_DEV_DEBUG_POLL)
-   printk(KERN_DEBUG "%s: poll: %08x\n",
+   dprintk("%s: poll: %08x\n",
video_device_node_name(vdev), res);
return res;
 }
@@ -382,7 +390,7 @@ static unsigned long v4l2_get_unmapped_area(struct file 
*filp,
return -ENODEV;
ret = vdev->fops->get_unmapped_area(filp, addr, len, pgoff, flags);
if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
-   printk(KERN_DEBUG "%s: get_unmapped_area (%d)\n",
+   dprintk("%s: get_unmapped_area (%d)\n",
video_device_node_name(vdev), ret);
return ret;
 }
@@ -398,7 +406,7 @@ static int v4l2_mmap(struct file *filp, struct 
vm_area_struct *vm)
if (video_is_registered(vdev))
ret = vdev->fops->mmap(filp, vm);
if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
-   printk(KERN_DEBUG "%s: mmap (%d)\n",
+   dprintk("%s: mmap (%d)\n",
video_device_node_name(vdev), ret);
return ret;
 }
@@ -428,7 +436,7 @@ static int v4l2_open(struct inode *inode, struct file *filp)
}
 
if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
-   printk(KERN_DEBUG "%s: open (%d)\n",
+   dprintk("%s: open (%d)\n",
video_device_node_name(vdev), ret);
/* decrease the refcount in case of an error */
if (ret)
@@ -445,7 +453,7 @@ static int v4l2_release(struct inode *inode, struct file 
*filp)
if (vdev->fops->release)
ret = vdev->fops->release(filp);
if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
-   printk(KERN_DEBUG "%s: release\n",
+   dprintk("%s: release\n",
video_device_node_name(vdev));
 
/* decrease the refcount unconditionally since the release()
@@ -786,8 +794,7 @@ static int video_register_media_controller(struct 
video_device *vdev, int type)
ret = media_device_register_entity(vdev->v4l2_dev->mdev,
   >entity);
if (ret < 0) {
-   printk(KERN_WARNING
-   "%s: media_device_register_entity failed\n",
+   pr_warn("%s: media_device_register_entity failed\n",
__func__);
return ret;
}
@@ -869,7 +876,7 @@ int __video_register_device(struct video_device *vdev,
name_base = "v4l-touch";
break;
default:
-   printk(KERN_ERR "%s called with unknown type: %d\n",
+   pr_err("%s called with unknown type: %d\n",
   __func__, type);
return -EINVAL;
}
@@ -918,7 +925,7 @@ int __video_register_device(struct video_device *vdev,
if (nr == 

Re: [PATCH v2] media: v4l2-core: fix size of devnode_nums[] bitarray

[Sakari Ailus]

On Thu, Apr 05, 2018 at 12:16:13PM +0200, Hans Verkuil wrote:
> On 05/04/18 12:13, Mauro Carvalho Chehab wrote:
> > The size of devnode_nums[] bit array is too short to store information
> > for VFL_TYPE_TOUCH. That causes it to override other memory regions.
> > 
> > Thankfully, on recent reports, it is overriding video_device[] array,
> > trigging a WARN_ON(). Yet, it just warns about the problem, but let
> > the code excecuting, with generates an OOPS:
> > 
> > [   43.177394] WARNING: CPU: 1 PID: 711 at 
> > drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 
> > [videodev]
> > [   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
> > hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d 
> > hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger 
> > industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common 
> > hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops 
> > videobuf2_v4l2 videobuf2_common videodev hid_multitouch media 
> > hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 
> > snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp 
> > snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic 
> > snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel 
> > snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep 
> > intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi snd_seq_midi_event 
> > snd_rawmidi crct10dif_pclmul
> > [   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 
> > snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd 
> > glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds 
> > serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore 
> > ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad 
> > int3400_thermal acpi_thermal_rel intel_pch_thermal processor_thermal_device 
> > mac_hid int340x_thermal_zone mei_me intel_soc_dts_iosf mei intel_lpss_pci 
> > shpchp intel_lpss sch_fq_codel vfio_pci nfsd vfio_virqfd parport_pc ppdev 
> > auth_rpcgss nfs_acl lockd grace lp parport sunrpc ip_tables x_tables 
> > autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid kvmgt 
> > vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i915 i2c_algo_bit 
> > drm_kms_helper syscopyarea sdhci_pci sysfillrect
> > [   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video 
> > pinctrl_sunrisepoint pinctrl_intel
> > [   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
> > [   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
> > [   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
> > [   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
> > [   43.177484] RAX:  RBX: 0005 RCX: 
> > 
> > [   43.177485] RDX: c0c44cc0 RSI:  RDI: 
> > c0c44cc0
> > [   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 
> > 8eda1a51f018
> > [   43.177487] R10: 0600 R11: 03b6 R12: 
> > 
> > [   43.177488] R13: 0005 R14: c0c96900 R15: 
> > 8eda1d6d91c0
> > [   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
> > knlGS:
> > [   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
> > [   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 
> > 003606e0
> > [   43.177492] Call Trace:
> > [   43.177498]  ? devres_add+0x5f/0x70
> > [   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
> > [   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
> > [   43.177507]  driver_probe_device+0x310/0x480
> > [   43.177509]  __device_attach_driver+0x86/0x100
> > [   43.177511]  ? __driver_attach+0xf0/0xf0
> > [   43.177512]  bus_for_each_drv+0x6b/0xb0
> > [   43.177514]  __device_attach+0xdd/0x160
> > [   43.177516]  device_initial_probe+0x13/0x20
> > [   43.177518]  bus_probe_device+0x95/0xa0
> > [   43.177519]  device_add+0x44b/0x680
> > [   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
> > [   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
> > [   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
> > [   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
> > [   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
> > [   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
> > [   43.177547]  ? sysfs_create_link+0x25/0x40
> > [   43.177549]  driver_probe_device+0x310/0x480
> > [   43.177551]  __device_attach_driver+0x86/0x100
> > [   43.177553]  ? __driver_attach+0xf0/0xf0
> > [   43.177554]  bus_for_each_drv+0x6b/0xb0
> > [   43.177556]  __device_attach+0xdd/0x160
> > [   43.177558]  device_initial_probe+0x13/0x20
> > [   43.177560]  bus_probe_device+0x95/0xa0
> > [   43.177561]  device_add+0x44b/0x680
> > [   43.177564]  rmi_register_transport_device+0x84/0x100 [rmi_core]
> > [   43.177568]  

Re: [v4l-utils PATCH 0/2] v4l-utils fixes

[Mauro Carvalho Chehab]

Em Thu,  5 Apr 2018 13:00:38 +0300
Sakari Ailus  escreveu:

> Hi folks,
> 
> The two patches add instructions for building static binaries as well as
> fix a few warnings in libdvb5.
> 
> Sakari Ailus (2):
>   Add instructions for building static binaries
>   libdvb5: Fix unused local variable warnings
> 
>  INSTALL  | 16 
>  lib/libdvbv5/dvb-dev-local.c |  5 +++--
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 

Both patches look ok on my eyes.


Thanks,
Mauro

Re: [PATCH v2] media: v4l2-core: fix size of devnode_nums[] bitarray

[Hans Verkuil]

On 05/04/18 12:13, Mauro Carvalho Chehab wrote:
> The size of devnode_nums[] bit array is too short to store information
> for VFL_TYPE_TOUCH. That causes it to override other memory regions.
> 
> Thankfully, on recent reports, it is overriding video_device[] array,
> trigging a WARN_ON(). Yet, it just warns about the problem, but let
> the code excecuting, with generates an OOPS:
> 
> [   43.177394] WARNING: CPU: 1 PID: 711 at 
> drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 
> [videodev]
> [   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
> hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d 
> hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf 
> joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio 
> videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev 
> hid_multitouch media hid_sensor_hub binfmt_misc nls_iso8859_1 
> snd_hda_codec_hdmi arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core 
> snd_soc_sst_dsp snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi 
> snd_hda_codec_generic snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine 
> snd_hda_intel snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal 
> snd_hwdep intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi 
> snd_seq_midi_event snd_rawmidi crct10dif_pclmul
> [   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq 
> aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd 
> snd_timer intel_cstate intel_rapl_perf input_leds serio_raw 
> intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop 
> sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal 
> acpi_thermal_rel intel_pch_thermal processor_thermal_device mac_hid 
> int340x_thermal_zone mei_me intel_soc_dts_iosf mei intel_lpss_pci shpchp 
> intel_lpss sch_fq_codel vfio_pci nfsd vfio_virqfd parport_pc ppdev 
> auth_rpcgss nfs_acl lockd grace lp parport sunrpc ip_tables x_tables autofs4 
> hid_logitech_hidpp hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev 
> vfio_iommu_type1 vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper 
> syscopyarea sdhci_pci sysfillrect
> [   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video 
> pinctrl_sunrisepoint pinctrl_intel
> [   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
> [   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
> [   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
> [   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
> [   43.177484] RAX:  RBX: 0005 RCX: 
> 
> [   43.177485] RDX: c0c44cc0 RSI:  RDI: 
> c0c44cc0
> [   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 
> 8eda1a51f018
> [   43.177487] R10: 0600 R11: 03b6 R12: 
> 
> [   43.177488] R13: 0005 R14: c0c96900 R15: 
> 8eda1d6d91c0
> [   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
> knlGS:
> [   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
> [   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 
> 003606e0
> [   43.177492] Call Trace:
> [   43.177498]  ? devres_add+0x5f/0x70
> [   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
> [   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
> [   43.177507]  driver_probe_device+0x310/0x480
> [   43.177509]  __device_attach_driver+0x86/0x100
> [   43.177511]  ? __driver_attach+0xf0/0xf0
> [   43.177512]  bus_for_each_drv+0x6b/0xb0
> [   43.177514]  __device_attach+0xdd/0x160
> [   43.177516]  device_initial_probe+0x13/0x20
> [   43.177518]  bus_probe_device+0x95/0xa0
> [   43.177519]  device_add+0x44b/0x680
> [   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
> [   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
> [   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
> [   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
> [   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
> [   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
> [   43.177547]  ? sysfs_create_link+0x25/0x40
> [   43.177549]  driver_probe_device+0x310/0x480
> [   43.177551]  __device_attach_driver+0x86/0x100
> [   43.177553]  ? __driver_attach+0xf0/0xf0
> [   43.177554]  bus_for_each_drv+0x6b/0xb0
> [   43.177556]  __device_attach+0xdd/0x160
> [   43.177558]  device_initial_probe+0x13/0x20
> [   43.177560]  bus_probe_device+0x95/0xa0
> [   43.177561]  device_add+0x44b/0x680
> [   43.177564]  rmi_register_transport_device+0x84/0x100 [rmi_core]
> [   43.177568]  rmi_input_configured+0xbf/0x1a0 [hid_rmi]
> [   43.177571]  ? input_allocate_device+0xdf/0xf0
> [   43.177574]  hidinput_connect+0x4a9/0x37a0 [hid]
> [   43.177578]  hid_connect+0x326/0x3d0 [hid]
> [   43.177581]  hid_hw_start+0x42/0x70 [hid]
> [   43.177583]  

Re: [v5 2/2] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

[Tomasz Figa]

Hi Sakari,

On Thu, Apr 5, 2018 at 6:26 PM Sakari Ailus 
wrote:

> Hi Tomasz,

> On Thu, Apr 05, 2018 at 08:21:56AM +, Tomasz Figa wrote:
> > On Sat, Mar 3, 2018 at 5:15 AM Sakari Ailus <
sakari.ai...@linux.intel.com>
> > wrote:
> >
> > > On Fri, Mar 02, 2018 at 12:59:00PM -0600, Rob Herring wrote:
> > > > On Wed, Feb 28, 2018 at 03:31:26PM +0200, Sakari Ailus wrote:
> > > > > Hi Rob,
> > > > >
> > > > > Thanks for the review.
> > > > >
> > > > > On Tue, Feb 27, 2018 at 04:10:31PM -0600, Rob Herring wrote:
> > > > > > On Fri, Feb 23, 2018 at 10:13 AM, Andy Yeh 
> > wrote:
> > > > > > > From: Alan Chiang 
> > > > > > >
> > > > > > > Dongwoon DW9807 is a voice coil lens driver.
> > > > > > >
> > > > > > > Also add a vendor prefix for Dongwoon for one did not exist
> > previously.
> > > > > >
> > > > > > Where's that?
> > > > >
> > > > > Added by aece98a912d92444ea9da03b04269407d1308f1f . So that line
isn't
> > > > > relevant indeed and should be removed.
> > > > >
> > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Andy Yeh 
> > > > > > > ---
> > > > > > >
  Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> > | 9 +
> > > > > >
> > > > > > DACs generally go in bindings/iio/dac/
> > > > >
> > > > > We have quite a few lens voice coil drivers under
bindings/media/i2c
> > now. I
> > > > > don't really object to putting this one to bindings/iio/dac but
then
> > the
> > > > > rest should be moved as well.
> > > > >
> > > > > The camera LED flash drivers are under bindings/leds so this would
> > actually
> > > > > be analoguous to that. The lens voice coil drivers are perhaps
still
> > a bit
> > > > > more bound to the domain (camera) than the LED flash drivers.
> > > >
> > > > The h/w is bound to that function or just the s/w?
> >
> > > The hardware. I guess in principle you could use them for other
purposes
> > > --- most devices seem to be current sinks with configurable current
---
> > but
> > > I've never seen that.
> >
> > > The datasheet (dw9714) is here:
> >
> > > 
> >
> > > >
> > > > > I can send a patch if you think the existing bindings should be
> > moved; let
> > > > > me know.
> > > >
> > > > I'm okay if they are separate as long as we're not going to see the
> > > > same device show up in both places. However, "i2c" is not the best
> >
> > > Ack. I wouldn't expect that. The datasheets of such devices clearly
label
> > > the devices voice coil module drivers.
> >
> > > > directory choice. It should be by function, so we can find common
> > > > properties.
> >
> > > I2c devices in the media subsystem tend to be peripherals that are
always
> > > used with another device with access to some system bus. Camera
sensors,
> > lens
> > > devices and tuners can be found there currently. I don't know the
original
> > > reasoning but it most likely is related to that.
> >
> > > In terms of different kinds of devices we have currently at least the
> > > following:
> >
> > >  Camera ISPs and CSI-2 receivers
> > >  Video muxes
> > >  Video codecs
> > >  Camera sensors
> > >  Camera lens drivers (right now only voice coil modules?)
> > >  Tuners (DVB, radio, analogue TV, whatever)
> > >  Radio transmitters
> > >  HDMI CEC
> > >  Remote controllers
> > >  JPEG codecs
> >
> > > Cc Hans, too.
> >
> > Any updates here?
> >
> > To be honest, I'm not sure there is too much to be thinking about here.
> > This particular hardware block is a lens driver, specifically designed
to
> > be used with cameras. Quoting maker's website [1]:
> >
> >"Driver ICs for automatically focus on images of mobile cameras.
> > Dongwoon Anatech's AF driver ICs are optimized mobile cameras
> > with low power, low noise, smallest package, as well as include
> > various lens position control methodology."
> >
> > IMHO putting its bindings under the more general purpose iio/ directory
> > doesn't make much sense and would be actually confusing.
> >
> > [1] http://www.dwanatech.com/eng/sub/sub02_01.php?cat_no=6

> Rob has acked v6 Andy sent some time ago while the driver patch has
> unaddressed comments from Jacopo. I think Andy (unintentionally) missed
> you from cc list:

> 

That's good to hear. Thanks for the pointer.

Best regards,
Tomasz

[PATCH v2] media: v4l2-core: fix size of devnode_nums[] bitarray

[Mauro Carvalho Chehab]

The size of devnode_nums[] bit array is too short to store information
for VFL_TYPE_TOUCH. That causes it to override other memory regions.

Thankfully, on recent reports, it is overriding video_device[] array,
trigging a WARN_ON(). Yet, it just warns about the problem, but let
the code excecuting, with generates an OOPS:

[   43.177394] WARNING: CPU: 1 PID: 711 at 
drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 
[videodev]
[   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d 
hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf 
joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media 
hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl 
snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc 
snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core 
snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl 
snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm 
kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul
[   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq 
aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd 
snd_timer intel_cstate intel_rapl_perf input_leds serio_raw 
intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop 
sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel 
intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me 
intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci 
nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport 
sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj 
hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass 
i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect
[   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video 
pinctrl_sunrisepoint pinctrl_intel
[   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
[   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
[   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
[   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
[   43.177484] RAX:  RBX: 0005 RCX: 
[   43.177485] RDX: c0c44cc0 RSI:  RDI: c0c44cc0
[   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 8eda1a51f018
[   43.177487] R10: 0600 R11: 03b6 R12: 
[   43.177488] R13: 0005 R14: c0c96900 R15: 8eda1d6d91c0
[   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
knlGS:
[   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
[   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 003606e0
[   43.177492] Call Trace:
[   43.177498]  ? devres_add+0x5f/0x70
[   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
[   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
[   43.177507]  driver_probe_device+0x310/0x480
[   43.177509]  __device_attach_driver+0x86/0x100
[   43.177511]  ? __driver_attach+0xf0/0xf0
[   43.177512]  bus_for_each_drv+0x6b/0xb0
[   43.177514]  __device_attach+0xdd/0x160
[   43.177516]  device_initial_probe+0x13/0x20
[   43.177518]  bus_probe_device+0x95/0xa0
[   43.177519]  device_add+0x44b/0x680
[   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
[   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
[   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
[   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
[   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
[   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
[   43.177547]  ? sysfs_create_link+0x25/0x40
[   43.177549]  driver_probe_device+0x310/0x480
[   43.177551]  __device_attach_driver+0x86/0x100
[   43.177553]  ? __driver_attach+0xf0/0xf0
[   43.177554]  bus_for_each_drv+0x6b/0xb0
[   43.177556]  __device_attach+0xdd/0x160
[   43.177558]  device_initial_probe+0x13/0x20
[   43.177560]  bus_probe_device+0x95/0xa0
[   43.177561]  device_add+0x44b/0x680
[   43.177564]  rmi_register_transport_device+0x84/0x100 [rmi_core]
[   43.177568]  rmi_input_configured+0xbf/0x1a0 [hid_rmi]
[   43.177571]  ? input_allocate_device+0xdf/0xf0
[   43.177574]  hidinput_connect+0x4a9/0x37a0 [hid]
[   43.177578]  hid_connect+0x326/0x3d0 [hid]
[   43.177581]  hid_hw_start+0x42/0x70 [hid]
[   43.177583]  rmi_probe+0x115/0x510 [hid_rmi]
[   43.177586]  hid_device_probe+0xd3/0x150 [hid]
[   43.177588]  ? sysfs_create_link+0x25/0x40
[   43.177590]  driver_probe_device+0x310/0x480
[   43.177592]  __driver_attach+0xbf/0xf0
[   43.177593]  ? 

Re: Linux 4.16 Kernel Boot Crash

[Hans Verkuil]

On 05/04/18 11:57, Mauro Carvalho Chehab wrote:
> Em Wed, 4 Apr 2018 16:26:22 +0300
> Jaak Ristioja  escreveu:
> 
>> Hello, all!
>>
>> I experience the same issue with a Lenovo ThinkPad T440p (LENOVO
>> 20AN006VMS/20AN006VMS, BIOS GLET90WW (2.44 ) 09/13/2017). I tried to
>> bisect v4.15..v4.16 but failed.
>>
>> Best regards,
>> J
> 
> The real problem here is that the bit array is too short.
> There's an additional problem at the WARN_ON() check, with lets
> the code to do something that won't work.
> 
> The enclosed patch should fix both issues. Please test.
> 
> Regards,
> Mauro
> 
> [PATCH] media: v4l2-core: fix size of devnode_nums[] bitarray
> 
> The size of devnode_nums[] bit array is too short to store information
> for VFL_TYPE_TOUCH. That causes it to override other memory regions.
> 
> Thankfully, on recent reports, it is overriding video_device[] array,
> trigging a WARN_ON(). Yet, it just warns about the problem, but let
> the code excecuting, with generates an OOPS:
> 
> [   43.177394] WARNING: CPU: 1 PID: 711 at 
> drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 
> [videodev]
> [   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
> hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d 
> hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf 
> joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio 
> videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev 
> hid_multitouch media hid_sensor_hub binfmt_misc nls_iso8859_1 
> snd_hda_codec_hdmi arc4 snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core 
> snd_soc_sst_dsp snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi 
> snd_hda_codec_generic snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine 
> snd_hda_intel snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal 
> snd_hwdep intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi 
> snd_seq_midi_event snd_rawmidi crct10dif_pclmul
> [   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq 
> aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd 
> snd_timer intel_cstate intel_rapl_perf input_leds serio_raw 
> intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop 
> sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal 
> acpi_thermal_rel intel_pch_thermal processor_thermal_device mac_hid 
> int340x_thermal_zone mei_me intel_soc_dts_iosf mei intel_lpss_pci shpchp 
> intel_lpss sch_fq_codel vfio_pci nfsd vfio_virqfd parport_pc ppdev 
> auth_rpcgss nfs_acl lockd grace lp parport sunrpc ip_tables x_tables autofs4 
> hid_logitech_hidpp hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev 
> vfio_iommu_type1 vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper 
> syscopyarea sdhci_pci sysfillrect
> [   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video 
> pinctrl_sunrisepoint pinctrl_intel
> [   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
> [   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
> [   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
> [   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
> [   43.177484] RAX:  RBX: 0005 RCX: 
> 
> [   43.177485] RDX: c0c44cc0 RSI:  RDI: 
> c0c44cc0
> [   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 
> 8eda1a51f018
> [   43.177487] R10: 0600 R11: 03b6 R12: 
> 
> [   43.177488] R13: 0005 R14: c0c96900 R15: 
> 8eda1d6d91c0
> [   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
> knlGS:
> [   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
> [   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 
> 003606e0
> [   43.177492] Call Trace:
> [   43.177498]  ? devres_add+0x5f/0x70
> [   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
> [   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
> [   43.177507]  driver_probe_device+0x310/0x480
> [   43.177509]  __device_attach_driver+0x86/0x100
> [   43.177511]  ? __driver_attach+0xf0/0xf0
> [   43.177512]  bus_for_each_drv+0x6b/0xb0
> [   43.177514]  __device_attach+0xdd/0x160
> [   43.177516]  device_initial_probe+0x13/0x20
> [   43.177518]  bus_probe_device+0x95/0xa0
> [   43.177519]  device_add+0x44b/0x680
> [   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
> [   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
> [   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
> [   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
> [   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
> [   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
> [   43.177547]  ? sysfs_create_link+0x25/0x40
> [   43.177549]  driver_probe_device+0x310/0x480
> [   43.177551]  

Re: Linux 4.16 Kernel Boot Crash

[Mauro Carvalho Chehab]

Em Thu, 5 Apr 2018 06:57:13 -0300
Mauro Carvalho Chehab  escreveu:

> Em Wed, 4 Apr 2018 16:26:22 +0300
> Jaak Ristioja  escreveu:
> 
> > Hello, all!
> > 
> > I experience the same issue with a Lenovo ThinkPad T440p (LENOVO
> > 20AN006VMS/20AN006VMS, BIOS GLET90WW (2.44 ) 09/13/2017). I tried to
> > bisect v4.15..v4.16 but failed.
> > 
> > Best regards,
> > J  
> 
> The real problem here is that the bit array is too short.
> There's an additional problem at the WARN_ON() check, with lets
> the code to do something that won't work.
> 
> The enclosed patch should fix both issues. Please test.
> 
> Regards,
> Mauro

Sorry, wrong patch. The correct one is enclosed.

Regards,
Mauro

[PATCH] media: v4l2-core: fix size of devnode_nums[] bitarray

The size of devnode_nums[] bit array is too short to store information
for VFL_TYPE_TOUCH. That causes it to override other memory regions.

Thankfully, on recent reports, it is overriding video_device[] array,
trigging a WARN_ON(). Yet, it just warns about the problem, but let
the code excecuting, with generates an OOPS:

[   43.177394] WARNING: CPU: 1 PID: 711 at 
drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 
[videodev]
[   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d 
hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf 
joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media 
hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl 
snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc 
snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core 
snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl 
snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm 
kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul
[   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq 
aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd 
snd_timer intel_cstate intel_rapl_perf input_leds serio_raw 
intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop 
sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel 
intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me 
intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci 
nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport 
sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj 
hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass 
i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect
[   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video 
pinctrl_sunrisepoint pinctrl_intel
[   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
[   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
[   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
[   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
[   43.177484] RAX:  RBX: 0005 RCX: 
[   43.177485] RDX: c0c44cc0 RSI:  RDI: c0c44cc0
[   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 8eda1a51f018
[   43.177487] R10: 0600 R11: 03b6 R12: 
[   43.177488] R13: 0005 R14: c0c96900 R15: 8eda1d6d91c0
[   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
knlGS:
[   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
[   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 003606e0
[   43.177492] Call Trace:
[   43.177498]  ? devres_add+0x5f/0x70
[   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
[   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
[   43.177507]  driver_probe_device+0x310/0x480
[   43.177509]  __device_attach_driver+0x86/0x100
[   43.177511]  ? __driver_attach+0xf0/0xf0
[   43.177512]  bus_for_each_drv+0x6b/0xb0
[   43.177514]  __device_attach+0xdd/0x160
[   43.177516]  device_initial_probe+0x13/0x20
[   43.177518]  bus_probe_device+0x95/0xa0
[   43.177519]  device_add+0x44b/0x680
[   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
[   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
[   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
[   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
[   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
[   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
[   43.177547]  ? sysfs_create_link+0x25/0x40
[   43.177549]  driver_probe_device+0x310/0x480
[   43.177551]  __device_attach_driver+0x86/0x100
[   43.177553]  ? __driver_attach+0xf0/0xf0

[PATCH] media: v4l2-core: fix size of devnode_nums[] bitarray

[Mauro Carvalho Chehab]

The size of devnode_nums[] bit array is too short to store information
for VFL_TYPE_TOUCH. That causes it to override other memory regions.

Thankfully, on recent reports, it is overriding video_device[] array,
trigging a WARN_ON(). Yet, it just warns about the problem, but let
the code excecuting, with generates an OOPS:

[   43.177394] WARNING: CPU: 1 PID: 711 at 
drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 
[videodev]
[   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d 
hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf 
joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media 
hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl 
snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc 
snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core 
snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl 
snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm 
kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul
[   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq 
aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd 
snd_timer intel_cstate intel_rapl_perf input_leds serio_raw 
intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop 
sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel 
intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me 
intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci 
nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport 
sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj 
hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass 
i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect
[   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video 
pinctrl_sunrisepoint pinctrl_intel
[   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
[   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
[   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
[   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
[   43.177484] RAX:  RBX: 0005 RCX: 
[   43.177485] RDX: c0c44cc0 RSI:  RDI: c0c44cc0
[   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 8eda1a51f018
[   43.177487] R10: 0600 R11: 03b6 R12: 
[   43.177488] R13: 0005 R14: c0c96900 R15: 8eda1d6d91c0
[   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
knlGS:
[   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
[   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 003606e0
[   43.177492] Call Trace:
[   43.177498]  ? devres_add+0x5f/0x70
[   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
[   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
[   43.177507]  driver_probe_device+0x310/0x480
[   43.177509]  __device_attach_driver+0x86/0x100
[   43.177511]  ? __driver_attach+0xf0/0xf0
[   43.177512]  bus_for_each_drv+0x6b/0xb0
[   43.177514]  __device_attach+0xdd/0x160
[   43.177516]  device_initial_probe+0x13/0x20
[   43.177518]  bus_probe_device+0x95/0xa0
[   43.177519]  device_add+0x44b/0x680
[   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
[   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
[   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
[   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
[   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
[   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
[   43.177547]  ? sysfs_create_link+0x25/0x40
[   43.177549]  driver_probe_device+0x310/0x480
[   43.177551]  __device_attach_driver+0x86/0x100
[   43.177553]  ? __driver_attach+0xf0/0xf0
[   43.177554]  bus_for_each_drv+0x6b/0xb0
[   43.177556]  __device_attach+0xdd/0x160
[   43.177558]  device_initial_probe+0x13/0x20
[   43.177560]  bus_probe_device+0x95/0xa0
[   43.177561]  device_add+0x44b/0x680
[   43.177564]  rmi_register_transport_device+0x84/0x100 [rmi_core]
[   43.177568]  rmi_input_configured+0xbf/0x1a0 [hid_rmi]
[   43.177571]  ? input_allocate_device+0xdf/0xf0
[   43.177574]  hidinput_connect+0x4a9/0x37a0 [hid]
[   43.177578]  hid_connect+0x326/0x3d0 [hid]
[   43.177581]  hid_hw_start+0x42/0x70 [hid]
[   43.177583]  rmi_probe+0x115/0x510 [hid_rmi]
[   43.177586]  hid_device_probe+0xd3/0x150 [hid]
[   43.177588]  ? sysfs_create_link+0x25/0x40
[   43.177590]  driver_probe_device+0x310/0x480
[   43.177592]  __driver_attach+0xbf/0xf0
[   43.177593]  ? 

[v4l-utils PATCH 1/2] Add instructions for building static binaries

[Sakari Ailus]

Static binaries are useful e.g. when copying test binaries to other
systems. Document how to build them.

Signed-off-by: Sakari Ailus 
---
 INSTALL | 16 
 1 file changed, 16 insertions(+)

diff --git a/INSTALL b/INSTALL
index 765fa26..8c98a76 100644
--- a/INSTALL
+++ b/INSTALL
@@ -53,6 +53,22 @@ export PKG_CONFIG_LIBDIR=/path/to/cross/root/lib
 ./configure --host=arm-linux-gnueabihf --without-jpeg
 make
 
+Building static binaries:
+-
+
+Fully static binares can be built by setting LDFLAGS for the configure and
+using an option for disabling shared libraries:
+
+   $ LDFLAGS="--static -static" ./configure --disable-shared
+
+Note that this requires static variants of all the libraries needed for
+linking which may not be available in all systems.
+
+In order to build binaries that are not dependent on libraries contained
+in v4l-utils, simply use the --disable-shared option:
+
+   $ ./configure --disable-shared
+
 Android Cross Compiling and Installing:
 
 
-- 
2.7.4

[v4l-utils PATCH 2/2] libdvb5: Fix unused local variable warnings

[Sakari Ailus]

Some local variables are only needed conditionally depending on available
system support for e.g. pthreads. Put these variables behind same #ifdefs
so that no warnings are produced if these features aren't available.

Signed-off-by: Sakari Ailus 
---
 lib/libdvbv5/dvb-dev-local.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/libdvbv5/dvb-dev-local.c b/lib/libdvbv5/dvb-dev-local.c
index 7a76d65..7ebf2b6 100644
--- a/lib/libdvbv5/dvb-dev-local.c
+++ b/lib/libdvbv5/dvb-dev-local.c
@@ -296,7 +296,6 @@ static int dvb_local_find(struct dvb_device_priv *dvb,
struct udev_enumerate *enumerate;
struct udev_list_entry *devices, *dev_list_entry;
struct udev_device *dev;
-   int ret;
 
/* Free a previous list of devices */
if (dvb->d.num_devices)
@@ -346,6 +345,8 @@ static int dvb_local_find(struct dvb_device_priv *dvb,
/* Begin monitoring udev events */
 #ifdef HAVE_PTHREAD
if (priv->notify_dev_change) {
+   int ret;
+
ret = pthread_create(>dev_change_id, NULL,
 monitor_device_changes, dvb);
if (ret < 0) {
@@ -364,9 +365,9 @@ static int dvb_local_find(struct dvb_device_priv *dvb,
 
 static int dvb_local_stop_monitor(struct dvb_device_priv *dvb)
 {
+#ifdef HAVE_PTHREAD
struct dvb_dev_local_priv *priv = dvb->priv;
 
-#ifdef HAVE_PTHREAD
if (priv->notify_dev_change) {
pthread_cancel(priv->dev_change_id);
udev_unref(priv->udev);
-- 
2.7.4

[v4l-utils PATCH 0/2] v4l-utils fixes

[Sakari Ailus]

Hi folks,

The two patches add instructions for building static binaries as well as
fix a few warnings in libdvb5.

Sakari Ailus (2):
  Add instructions for building static binaries
  libdvb5: Fix unused local variable warnings

 INSTALL  | 16 
 lib/libdvbv5/dvb-dev-local.c |  5 +++--
 2 files changed, 19 insertions(+), 2 deletions(-)

-- 
2.7.4

Re: Linux 4.16 Kernel Boot Crash

[Mauro Carvalho Chehab]

Em Wed, 4 Apr 2018 16:26:22 +0300
Jaak Ristioja  escreveu:

> Hello, all!
> 
> I experience the same issue with a Lenovo ThinkPad T440p (LENOVO
> 20AN006VMS/20AN006VMS, BIOS GLET90WW (2.44 ) 09/13/2017). I tried to
> bisect v4.15..v4.16 but failed.
> 
> Best regards,
> J

The real problem here is that the bit array is too short.
There's an additional problem at the WARN_ON() check, with lets
the code to do something that won't work.

The enclosed patch should fix both issues. Please test.

Regards,
Mauro

[PATCH] media: v4l2-core: fix size of devnode_nums[] bitarray

The size of devnode_nums[] bit array is too short to store information
for VFL_TYPE_TOUCH. That causes it to override other memory regions.

Thankfully, on recent reports, it is overriding video_device[] array,
trigging a WARN_ON(). Yet, it just warns about the problem, but let
the code excecuting, with generates an OOPS:

[   43.177394] WARNING: CPU: 1 PID: 711 at 
drivers/media/v4l2-core/v4l2-dev.c:945 __video_register_device+0xc99/0x1090 
[videodev]
[   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d 
hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf 
joydev hid_sensor_iio_common hid_rmi(+) rmi_core industrialio videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_common videodev hid_multitouch media 
hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 snd_soc_skl 
snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc 
snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic snd_soc_core 
snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec intel_rapl 
snd_hda_core x86_pkg_temp_thermal snd_hwdep intel_powerclamp coretemp snd_pcm 
kvm_intel snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul
[   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 snd_seq 
aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd glue_helper cryptd 
snd_timer intel_cstate intel_rapl_perf input_leds serio_raw 
intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore ideapad_laptop 
sparse_keymap idma64 virt_dma tpm_crb acpi_pad int3400_thermal acpi_thermal_rel 
intel_pch_thermal processor_thermal_device mac_hid int340x_thermal_zone mei_me 
intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel vfio_pci 
nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd grace lp parport 
sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj 
hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass 
i915 i2c_algo_bit drm_kms_helper syscopyarea sdhci_pci sysfillrect
[   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid video 
pinctrl_sunrisepoint pinctrl_intel
[   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
[   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
[   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
[   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
[   43.177484] RAX:  RBX: 0005 RCX: 
[   43.177485] RDX: c0c44cc0 RSI:  RDI: c0c44cc0
[   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 8eda1a51f018
[   43.177487] R10: 0600 R11: 03b6 R12: 
[   43.177488] R13: 0005 R14: c0c96900 R15: 8eda1d6d91c0
[   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
knlGS:
[   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
[   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 003606e0
[   43.177492] Call Trace:
[   43.177498]  ? devres_add+0x5f/0x70
[   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
[   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
[   43.177507]  driver_probe_device+0x310/0x480
[   43.177509]  __device_attach_driver+0x86/0x100
[   43.177511]  ? __driver_attach+0xf0/0xf0
[   43.177512]  bus_for_each_drv+0x6b/0xb0
[   43.177514]  __device_attach+0xdd/0x160
[   43.177516]  device_initial_probe+0x13/0x20
[   43.177518]  bus_probe_device+0x95/0xa0
[   43.177519]  device_add+0x44b/0x680
[   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
[   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
[   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
[   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
[   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
[   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
[   43.177547]  ? sysfs_create_link+0x25/0x40
[   43.177549]  driver_probe_device+0x310/0x480
[   43.177551]  __device_attach_driver+0x86/0x100
[   43.177553]  ? __driver_attach+0xf0/0xf0
[   43.177554]  bus_for_each_drv+0x6b/0xb0
[   43.177556]  __device_attach+0xdd/0x160
[   43.177558]  device_initial_probe+0x13/0x20
[   43.177560]  bus_probe_device+0x95/0xa0
[   43.177561]  

[PATCH] dvb_frontend: fix locking issues at dvb_frontend_get_event()

[Mauro Carvalho Chehab]

As warned by smatch:
drivers/media/dvb-core/dvb_frontend.c:314 dvb_frontend_get_event() 
warn: inconsistent returns 'sem:>sem'.
  Locked on:   line 288
   line 295
   line 306
   line 314
  Unlocked on: line 303

The lock implementation for get event is wrong, as, if an
interrupt occurs, down_interruptible() will fail, and the
routine will call up() twice when userspace calls the ioctl
again.

The bad code is there since when Linux migrated to git, in
2005.

Cc: sta...@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-core/dvb_frontend.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index e33414975065..a4ada1ccf0df 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -275,8 +275,20 @@ static void dvb_frontend_add_event(struct dvb_frontend *fe,
wake_up_interruptible (>wait_queue);
 }
 
+static int dvb_frontend_test_event(struct dvb_frontend_private *fepriv,
+  struct dvb_fe_events *events)
+{
+   int ret;
+
+   up(>sem);
+   ret = events->eventw != events->eventr;
+   down(>sem);
+
+   return ret;
+}
+
 static int dvb_frontend_get_event(struct dvb_frontend *fe,
-   struct dvb_frontend_event *event, int flags)
+ struct dvb_frontend_event *event, int flags)
 {
struct dvb_frontend_private *fepriv = fe->frontend_priv;
struct dvb_fe_events *events = >events;
@@ -294,13 +306,8 @@ static int dvb_frontend_get_event(struct dvb_frontend *fe,
if (flags & O_NONBLOCK)
return -EWOULDBLOCK;
 
-   up(>sem);
-
-   ret = wait_event_interruptible (events->wait_queue,
-   events->eventw != 
events->eventr);
-
-   if (down_interruptible (>sem))
-   return -ERESTARTSYS;
+   ret = wait_event_interruptible(events->wait_queue,
+  dvb_frontend_test_event(fepriv, 
events));
 
if (ret < 0)
return ret;
-- 
2.14.3

Re: [v5 2/2] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

[Sakari Ailus]

Hi Tomasz,

On Thu, Apr 05, 2018 at 08:21:56AM +, Tomasz Figa wrote:
> On Sat, Mar 3, 2018 at 5:15 AM Sakari Ailus 
> wrote:
> 
> > On Fri, Mar 02, 2018 at 12:59:00PM -0600, Rob Herring wrote:
> > > On Wed, Feb 28, 2018 at 03:31:26PM +0200, Sakari Ailus wrote:
> > > > Hi Rob,
> > > >
> > > > Thanks for the review.
> > > >
> > > > On Tue, Feb 27, 2018 at 04:10:31PM -0600, Rob Herring wrote:
> > > > > On Fri, Feb 23, 2018 at 10:13 AM, Andy Yeh 
> wrote:
> > > > > > From: Alan Chiang 
> > > > > >
> > > > > > Dongwoon DW9807 is a voice coil lens driver.
> > > > > >
> > > > > > Also add a vendor prefix for Dongwoon for one did not exist
> previously.
> > > > >
> > > > > Where's that?
> > > >
> > > > Added by aece98a912d92444ea9da03b04269407d1308f1f . So that line isn't
> > > > relevant indeed and should be removed.
> > > >
> > > > >
> > > > > >
> > > > > > Signed-off-by: Andy Yeh 
> > > > > > ---
> > > > > >  Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> | 9 +
> > > > >
> > > > > DACs generally go in bindings/iio/dac/
> > > >
> > > > We have quite a few lens voice coil drivers under bindings/media/i2c
> now. I
> > > > don't really object to putting this one to bindings/iio/dac but then
> the
> > > > rest should be moved as well.
> > > >
> > > > The camera LED flash drivers are under bindings/leds so this would
> actually
> > > > be analoguous to that. The lens voice coil drivers are perhaps still
> a bit
> > > > more bound to the domain (camera) than the LED flash drivers.
> > >
> > > The h/w is bound to that function or just the s/w?
> 
> > The hardware. I guess in principle you could use them for other purposes
> > --- most devices seem to be current sinks with configurable current ---
> but
> > I've never seen that.
> 
> > The datasheet (dw9714) is here:
> 
> > 
> 
> > >
> > > > I can send a patch if you think the existing bindings should be
> moved; let
> > > > me know.
> > >
> > > I'm okay if they are separate as long as we're not going to see the
> > > same device show up in both places. However, "i2c" is not the best
> 
> > Ack. I wouldn't expect that. The datasheets of such devices clearly label
> > the devices voice coil module drivers.
> 
> > > directory choice. It should be by function, so we can find common
> > > properties.
> 
> > I2c devices in the media subsystem tend to be peripherals that are always
> > used with another device with access to some system bus. Camera sensors,
> lens
> > devices and tuners can be found there currently. I don't know the original
> > reasoning but it most likely is related to that.
> 
> > In terms of different kinds of devices we have currently at least the
> > following:
> 
> >  Camera ISPs and CSI-2 receivers
> >  Video muxes
> >  Video codecs
> >  Camera sensors
> >  Camera lens drivers (right now only voice coil modules?)
> >  Tuners (DVB, radio, analogue TV, whatever)
> >  Radio transmitters
> >  HDMI CEC
> >  Remote controllers
> >  JPEG codecs
> 
> > Cc Hans, too.
> 
> Any updates here?
> 
> To be honest, I'm not sure there is too much to be thinking about here.
> This particular hardware block is a lens driver, specifically designed to
> be used with cameras. Quoting maker's website [1]:
> 
>"Driver ICs for automatically focus on images of mobile cameras.
> Dongwoon Anatech's AF driver ICs are optimized mobile cameras
> with low power, low noise, smallest package, as well as include
> various lens position control methodology."
> 
> IMHO putting its bindings under the more general purpose iio/ directory
> doesn't make much sense and would be actually confusing.
> 
> [1] http://www.dwanatech.com/eng/sub/sub02_01.php?cat_no=6

Rob has acked v6 Andy sent some time ago while the driver patch has
unaddressed comments from Jacopo. I think Andy (unintentionally) missed
you from cc list:



-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

[PATCH v2 10/15] v4l: vsp1: Turn frame end completion status into a bitfield

[Laurent Pinchart]

We will soon need to return more than a boolean completion status from
the vsp1_dlm_irq_frame_end() IRQ handler. Turn the return value into a
bitfield to prepare for that. No functional change is introduced here.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c| 22 +-
 drivers/media/platform/vsp1/vsp1_dl.h|  4 +++-
 drivers/media/platform/vsp1/vsp1_drm.c   |  5 +++--
 drivers/media/platform/vsp1/vsp1_pipe.c  |  8 
 drivers/media/platform/vsp1/vsp1_pipe.h  |  2 +-
 drivers/media/platform/vsp1/vsp1_video.c |  4 ++--
 6 files changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 0b86ed01e85d..662fa2a347c9 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -616,14 +616,18 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
  * vsp1_dlm_irq_frame_end - Display list handler for the frame end interrupt
  * @dlm: the display list manager
  *
- * Return true if the previous display list has completed at frame end, or 
false
- * if it has been delayed by one frame because the display list commit raced
- * with the frame end interrupt. The function always returns true in header 
mode
- * as display list processing is then not continuous and races never occur.
+ * Return a set of flags that indicates display list completion status.
+ *
+ * The VSP1_DL_FRAME_END_COMPLETED flag indicates that the previous display 
list
+ * has completed at frame end. If the flag is not returned display list
+ * completion has been delayed by one frame because the display list commit
+ * raced with the frame end interrupt. The function always returns with the 
flag
+ * set in header mode as display list processing is then not continuous and
+ * races never occur.
  */
-bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
+unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 {
-   bool completed = false;
+   unsigned int flags = 0;
 
spin_lock(>lock);
 
@@ -634,7 +638,7 @@ bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
if (dlm->singleshot) {
__vsp1_dl_list_put(dlm->active);
dlm->active = NULL;
-   completed = true;
+   flags |= VSP1_DL_FRAME_END_COMPLETED;
goto done;
}
 
@@ -655,7 +659,7 @@ bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
__vsp1_dl_list_put(dlm->active);
dlm->active = dlm->queued;
dlm->queued = NULL;
-   completed = true;
+   flags |= VSP1_DL_FRAME_END_COMPLETED;
}
 
/*
@@ -672,7 +676,7 @@ bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 done:
spin_unlock(>lock);
 
-   return completed;
+   return flags;
 }
 
 /* Hardware Setup */
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index ee3508172f0a..cbc2fc53e10b 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -20,6 +20,8 @@ struct vsp1_dl_fragment;
 struct vsp1_dl_list;
 struct vsp1_dl_manager;
 
+#define VSP1_DL_FRAME_END_COMPLETEDBIT(0)
+
 void vsp1_dlm_setup(struct vsp1_device *vsp1);
 
 struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device *vsp1,
@@ -27,7 +29,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
unsigned int prealloc);
 void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
-bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
+unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
 
 struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm);
 void vsp1_dl_list_put(struct vsp1_dl_list *dl);
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index a79b05ef..541473b1df67 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -34,12 +34,13 @@
  */
 
 static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe,
-  bool completed)
+  unsigned int completion)
 {
struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
 
if (drm_pipe->du_complete)
-   drm_pipe->du_complete(drm_pipe->du_private, completed);
+   drm_pipe->du_complete(drm_pipe->du_private,
+ completion & VSP1_DL_FRAME_END_COMPLETED);
 }
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 99ccbac3256a..1134f14ed4aa 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ 

[PATCH v2 14/15] v4l: vsp1: Add BRx dynamic assignment debugging messages

[Laurent Pinchart]

Dynamic assignment of the BRU and BRS to pipelines is prone to
regressions, add messages to make debugging easier. Keep it as a
separate commit to ease removal of those messages once the code will
deem to be completely stable.

Signed-off-by: Laurent Pinchart 
Acked-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index f82f83b6d4ff..b43d6dc0d5f5 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -190,6 +190,10 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
 
/* Release our BRU if we have one. */
if (pipe->bru) {
+   dev_dbg(vsp1->dev, "%s: pipe %u: releasing %s\n",
+   __func__, pipe->lif->index,
+   BRU_NAME(pipe->bru));
+
/*
 * The BRU might be acquired by the other pipeline in
 * the next step. We must thus remove it from the list
@@ -219,6 +223,9 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
if (bru->pipe) {
struct vsp1_drm_pipeline *owner_pipe;
 
+   dev_dbg(vsp1->dev, "%s: pipe %u: waiting for %s\n",
+   __func__, pipe->lif->index, BRU_NAME(bru));
+
owner_pipe = to_vsp1_drm_pipeline(bru->pipe);
owner_pipe->force_bru_release = true;
 
@@ -245,6 +252,9 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
  >entities);
 
/* Add the BRU to the pipeline. */
+   dev_dbg(vsp1->dev, "%s: pipe %u: acquired %s\n",
+   __func__, pipe->lif->index, BRU_NAME(bru));
+
pipe->bru = bru;
pipe->bru->pipe = pipe;
pipe->bru->sink = >output->entity;
@@ -548,6 +558,10 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
drm_pipe->du_complete = NULL;
pipe->num_inputs = 0;
 
+   dev_dbg(vsp1->dev, "%s: pipe %u: releasing %s\n",
+   __func__, pipe->lif->index,
+   BRU_NAME(pipe->bru));
+
list_del(>bru->list_pipe);
pipe->bru->pipe = NULL;
pipe->bru = NULL;
-- 
Regards,

Laurent Pinchart

[PATCH v2 13/15] v4l: vsp1: Assign BRU and BRS to pipelines dynamically

[Laurent Pinchart]

The VSPDL variant drives two DU channels through two LIF and two
blenders, BRU and BRS. The DU channels thus share the five available
VSPDL inputs and expose them as five KMS planes.

The current implementation assigns the BRS to the second LIF and thus
artificially limits the number of planes for the second display channel
to two at most.

Lift this artificial limitation by assigning the BRU and BRS to the
display pipelines on demand based on the number of planes used by each
pipeline. When a display pipeline needs more than two inputs and the BRU
is already in use by the other pipeline, this requires reconfiguring the
other pipeline to free the BRU before processing, which can result in
frame drop on both pipelines.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 161 +++--
 drivers/media/platform/vsp1/vsp1_drm.h |   9 ++
 2 files changed, 144 insertions(+), 26 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index a9c53892a9ea..f82f83b6d4ff 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -37,10 +37,15 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe,
   unsigned int completion)
 {
struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
+   bool complete = completion == VSP1_DL_FRAME_END_COMPLETED;
 
if (drm_pipe->du_complete)
-   drm_pipe->du_complete(drm_pipe->du_private,
- completion & VSP1_DL_FRAME_END_COMPLETED);
+   drm_pipe->du_complete(drm_pipe->du_private, complete);
+
+   if (completion & VSP1_DL_FRAME_END_INTERNAL) {
+   drm_pipe->force_bru_release = false;
+   wake_up(_pipe->wait_queue);
+   }
 }
 
 /* 
-
@@ -150,6 +155,10 @@ static int vsp1_du_pipeline_setup_rpf(struct vsp1_device 
*vsp1,
 }
 
 /* Setup the BRU source pad. */
+static int vsp1_du_pipeline_setup_inputs(struct vsp1_device *vsp1,
+struct vsp1_pipeline *pipe);
+static void vsp1_du_pipeline_configure(struct vsp1_pipeline *pipe);
+
 static int vsp1_du_pipeline_setup_bru(struct vsp1_device *vsp1,
  struct vsp1_pipeline *pipe)
 {
@@ -157,8 +166,93 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
+   struct vsp1_entity *bru;
int ret;
 
+   /*
+* Pick a BRU:
+* - If we need more than two inputs, use the main BRU.
+* - Otherwise, if we are not forced to release our BRU, keep it.
+* - Else, use any free BRU (randomly starting with the main BRU).
+*/
+   if (pipe->num_inputs > 2)
+   bru = >bru->entity;
+   else if (pipe->bru && !drm_pipe->force_bru_release)
+   bru = pipe->bru;
+   else if (!vsp1->bru->entity.pipe)
+   bru = >bru->entity;
+   else
+   bru = >brs->entity;
+
+   /* Switch BRU if needed. */
+   if (bru != pipe->bru) {
+   struct vsp1_entity *released_bru = NULL;
+
+   /* Release our BRU if we have one. */
+   if (pipe->bru) {
+   /*
+* The BRU might be acquired by the other pipeline in
+* the next step. We must thus remove it from the list
+* of entities for this pipeline. The other pipeline's
+* hardware configuration will reconfigure the BRU
+* routing.
+*
+* However, if the other pipeline doesn't acquire our
+* BRU, we need to keep it in the list, otherwise the
+* hardware configuration step won't disconnect it from
+* the pipeline. To solve this, store the released BRU
+* pointer to add it back to the list of entities later
+* if it isn't acquired by the other pipeline.
+*/
+   released_bru = pipe->bru;
+
+   list_del(>bru->list_pipe);
+   pipe->bru->sink = NULL;
+   pipe->bru->pipe = NULL;
+   pipe->bru = NULL;
+   }
+
+   /*
+* If the BRU we need is in use, force the owner pipeline to
+* switch to the other BRU and wait until the switch completes.
+*/
+   if (bru->pipe) {
+   struct vsp1_drm_pipeline