cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Fri Apr 20 05:00:09 CEST 2018
media-tree git hash:42a182282ea2426d56b2d63be634ee419194c45c
media_build git hash:   4fb7a3cc8d0f56c7cddc3b5b29e35aa1159bc8d9
v4l-utils git hash: af97b81afa1a33bd96381bf2fd2a10a9af8679c2
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: 0.5.2-RC1
smatch version: 0.5.1
host hardware:  x86_64
host os:4.15.0-2-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
Check COMPILE_TEST: WARNINGS: VIDEO_OMAP3 VIDEO_OMAP3_DEBUG
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: WARNINGS
linux-3.10.108-x86_64: WARNINGS
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: OK
smatch: OK

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 v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

[Tomasz Figa]

Hi Paul, Philipp,

On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel 
wrote:

> Hi Paul,

> On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote:
> > This adds a device-tree binding document that specifies the properties
> > used by the Sunxi-Cedurs VPU driver, as well as examples.
> >
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  .../devicetree/bindings/media/sunxi-cedrus.txt | 50
++
> >  1 file changed, 50 insertions(+)
> >  create mode 100644
Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > new file mode 100644
> > index ..71ad3f9c3352
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > @@ -0,0 +1,50 @@
> > +Device-tree bindings for the VPU found in Allwinner SoCs, referred to
as the
> > +Video Engine (VE) in Allwinner literature.
> > +
> > +The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped
starting
> > +from the DRAM base. This requires specific memory allocation and
handling.

And no IOMMU? Brings back memories.

> > +
> > +Required properties:
> > +- compatible : "allwinner,sun4i-a10-video-engine";
> > +- memory-region : DMA pool for buffers allocation;
> > +- clocks : list of clock specifiers, corresponding to
entries in
> > +  the clock-names property;
> > +- clock-names: should contain "ahb", "mod" and "ram"
entries;
> > +- assigned-clocks   : list of clocks assigned to the VE;
> > +- assigned-clocks-rates : list of clock rates for the clocks assigned
to the VE;
> > +- resets : phandle for reset;
> > +- interrupts : should contain VE interrupt number;
> > +- reg: should contain register base and length
of VE.
> > +
> > +Example:
> > +
> > +reserved-memory {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
> > + ve_memory: cma@4a00 {
> > + compatible = "shared-dma-pool";
> > + reg = <0x4a00 0x600>;
> > + no-map;
> > + linux,cma-default;
> > + };
> > +};
> > +
> > +video-engine@1c0e000 {

> This is not really required by any specification, and not as common as
> gpu@..., but could this reasonably be called "vpu@1c0e000" to follow
> somewhat-common practice?

AFAIR the name is supposed to be somewhat readable for someone that doesn't
know the hardware. To me, "video-engine" sounds more obvious than "vpu",
but we actually use "codec" already, in case of MFC and JPEG codec on
Exynos. If encode/decode is the only functionality of this block, I'd
personally go with "codec". If it can do other things, e.g.
scaling/rotation without encode/decode, I'd probably call it
"video-processor".

Best regards,
Tomasz

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

[Matthias Reichl]

Hi Sean,

On Wed, Apr 18, 2018 at 07:42:29PM +0200, Matthias Reichl wrote:
> Hi Sean,
> 
> On Wed, Apr 18, 2018 at 12:24:29PM +0100, Sean Young wrote:
> > Hello Hias,
> > 
> > On Tue, Apr 17, 2018 at 09:14:57PM +0200, Matthias Reichl wrote:
> > > On Sun, Apr 08, 2018 at 10:19:42PM +0100, Sean Young wrote:
> > > > mceusb devices have a default timeout of 100ms, but this can be changed.
> > > 
> > > We finally added a backport of the v2 series (and also the mce_kbd
> > > series) to LibreELEC yesterday and ratcher quickly received 2 bugreports
> > > from users using mceusb receivers.
> > > 
> > > Local testing on RPi/gpio-ir and Intel NUC/ite-cir was fine, I've
> > > been using the v2 series for over a week without issues on
> > > LibreELEC (RPi with kernel 4.14).
> > > 
> > > Here are the links to the bugreports and logs:
> > > https://forum.kodi.tv/showthread.php?tid=298461=2726684#pid2726684
> > > https://forum.kodi.tv/showthread.php?tid=298462=2726690#pid2726690
> > > 
> > > Both users are using similar mceusb receivers:
> > > 
> > > Log 1:
> > > [6.418218] rc rc0: Media Center Ed. eHome Infrared Remote Transceiver 
> > > (147a:e017) as 
> > > /devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/rc/rc0
> > > [6.418358] input: Media Center Ed. eHome Infrared Remote Transceiver 
> > > (147a:e017) as 
> > > /devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/rc/rc0/input0
> > > [6.419443] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered 
> > > at minor = 0
> > > [6.608114] mceusb 1-1.3:1.0: Registered Formosa21 SnowflakeEmulation 
> > > with mce emulator interface version 1
> > > [6.608125] mceusb 1-1.3:1.0: 0 tx ports (0x0 cabled) and 1 rx sensors 
> > > (0x1 active)
> > > 
> > > Log 2:
> > > [3.023361] rc rc0: Media Center Ed. eHome Infrared Remote Transceiver 
> > > (147a:e03e) as /devices/pci:00/:00:14.0/usb1/1-10/1-10:1.0/rc/rc0
> > > [3.023393] input: Media Center Ed. eHome Infrared Remote Transceiver 
> > > (147a:e03e) as 
> > > /devices/pci:00/:00:14.0/usb1/1-10/1-10:1.0/rc/rc0/input11
> > > [3.023868] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered 
> > > at minor = 0
> > > [3.119384] input: eventlircd as /devices/virtual/input/input21
> > > [3.138625] ip6_tables: (C) 2000-2006 Netfilter Core Team
> > > [3.196830] mceusb 1-10:1.0: Registered Formosa21 eHome Infrared 
> > > Transceiver with mce emulator interface version 2
> > > [3.196836] mceusb 1-10:1.0: 0 tx ports (0x0 cabled) and 1 rx sensors 
> > > (0x1 active)
> > > 
> > > In both cases ir-keytable doesn't report any scancodes and the
> > > ir-ctl -r output contains very odd long space values where I'd expect
> > > a short timeout instead:
> > > 
> > > gap between messages:
> > > space 800
> > > pulse 450
> > > space 16777215
> > > space 25400
> > > pulse 2650
> > > space 800
> > > 
> > > end of last message:
> > > space 800
> > > pulse 450
> > > space 16777215
> > > timeout 31750
> > > 
> > > This patch applied cleanly on 4.14 and the mceusb history from
> > > 4.14 to media/master looked rather unsuspicious. I'm not 100% sure
> > > if I might have missed a dependency when backporting the patch
> > > or if this is indeed an issue of this patch on these particular
> > > (or maybe some more) mceusb receivers.
> > 
> > Thanks again for a great bug report and analysis! So, it seems with the
> > shorter timeout, some mceusb devices add a specific "timeout" code to
> > the IR data stream (0x80) rather than a space. The current mceusb code
> > resets the decoders in this case, causing the IR decoders to reset and
> > lirc to report a space of 0xff.
> > 
> > Turns out that one of my mceusb devices also suffers from this, I don't
> > know how I missed this. Anyway hopefully this will solve the problem.
> 
> Thanks a lot for the quick fix!
> 
> I can't test myself as I don't have the hardware, but we will
> include the patch in tonight's LibreELEC build and I asked the
> users to test it. I'll keep you posted about the outcome.

One of the affected users reported back that the fix worked fine!

I'm keeping an eye on further reports but so far I'd say everything's
working really well.

Great job and thanks a lot for the improvements!

so long,

Hias

> 
> so long,
> 
> Hias
> 
> > 
> > 
> > Thanks
> > 
> > Sean
> > 
> > >>From 92d27b206e51993e927dc0b3aba210a621eef3d0 Mon Sep 17 00:00:00 2001
> > From: Sean Young 
> > Date: Wed, 18 Apr 2018 10:36:25 +0100
> > Subject: [PATCH] media: rc: mceusb: IR of length 0 means IR timeout, not 
> > reset
> > 
> > The last usb packet with IR data will end with 0x80 (MCE_IRDATA_TRAILER).
> > If we reset the decoder state at this point, IR decoding can fail.
> > 
> > Signed-off-by: Sean Young 
> > ---
> >  drivers/media/rc/mceusb.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> > index 

Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data

[Tony Lindgren]

* Wolfram Sang  [180419 20:02]:
> This header only contains platform_data. Move it to the proper directory.

Acked-by: Tony Lindgren 

[PATCH 1/7] i2c: i2c-gpio: move header to platform_data

[Wolfram Sang]

This header only contains platform_data. Move it to the proper directory.

Signed-off-by: Wolfram Sang 
---
 MAINTAINERS  | 2 +-
 arch/arm/mach-ks8695/board-acs5k.c   | 2 +-
 arch/arm/mach-omap1/board-htcherald.c| 2 +-
 arch/arm/mach-pxa/palmz72.c  | 2 +-
 arch/arm/mach-pxa/viper.c| 2 +-
 arch/arm/mach-sa1100/simpad.c| 2 +-
 arch/mips/alchemy/board-gpr.c| 2 +-
 drivers/i2c/busses/i2c-gpio.c| 2 +-
 drivers/media/platform/marvell-ccic/mmp-driver.c | 2 +-
 drivers/mfd/sm501.c  | 2 +-
 include/linux/{ => platform_data}/i2c-gpio.h | 0
 11 files changed, 10 insertions(+), 10 deletions(-)
 rename include/linux/{ => platform_data}/i2c-gpio.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a1410d5a621..7aad64b62102 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5872,7 +5872,7 @@ GENERIC GPIO I2C DRIVER
 M: Haavard Skinnemoen 
 S: Supported
 F: drivers/i2c/busses/i2c-gpio.c
-F: include/linux/i2c-gpio.h
+F: include/linux/platform_data/i2c-gpio.h
 
 GENERIC GPIO I2C MULTIPLEXER DRIVER
 M: Peter Korsgaard 
diff --git a/arch/arm/mach-ks8695/board-acs5k.c 
b/arch/arm/mach-ks8695/board-acs5k.c
index 937eb1d47e7b..ef835d82cdb9 100644
--- a/arch/arm/mach-ks8695/board-acs5k.c
+++ b/arch/arm/mach-ks8695/board-acs5k.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
diff --git a/arch/arm/mach-omap1/board-htcherald.c 
b/arch/arm/mach-omap1/board-htcherald.c
index 67d46690a56e..da8f3fc3180f 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-pxa/palmz72.c b/arch/arm/mach-pxa/palmz72.c
index 5877e547cecd..c053c8ce1586 100644
--- a/arch/arm/mach-pxa/palmz72.c
+++ b/arch/arm/mach-pxa/palmz72.c
@@ -30,7 +30,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index 90d0f277de55..39e05b7008d8 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -35,7 +35,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-sa1100/simpad.c b/arch/arm/mach-sa1100/simpad.c
index ace010479eb6..49a61e6f3c5f 100644
--- a/arch/arm/mach-sa1100/simpad.c
+++ b/arch/arm/mach-sa1100/simpad.c
@@ -37,7 +37,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "generic.h"
 
diff --git a/arch/mips/alchemy/board-gpr.c b/arch/mips/alchemy/board-gpr.c
index 4e79dbd54a33..fa75d75b5ba9 100644
--- a/arch/mips/alchemy/board-gpr.c
+++ b/arch/mips/alchemy/board-gpr.c
@@ -29,7 +29,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index 58abb3eced58..005e6e0330c2 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c 
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 816f4b6a7b8e..d9f0dd0d3525 100644
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index ad774161a22d..66af659b01b2 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/include/linux/i2c-gpio.h b/include/linux/platform_data/i2c-gpio.h
similarity index 100%
rename from include/linux/i2c-gpio.h
rename to include/linux/platform_data/i2c-gpio.h
-- 
2.11.0

[PATCH 0/7] i2c: clean up include/linux/i2c-*

[Wolfram Sang]

Move all plain platform_data includes to the platform_data-dir
(except for i2c-pnx which can be moved into the driver itself).

My preference is to take these patches via the i2c tree. I can provide an
immutable branch if needed. But we can also discuss those going in via
arch-trees if dependencies are against us.

The current branch can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/platform_data

and buildbot had no complaints.

Looking forward to comments or Acks, Revs...

Kind regards,

   Wolfram


Wolfram Sang (7):
  i2c: i2c-gpio: move header to platform_data
  i2c: i2c-mux-gpio: move header to platform_data
  i2c: i2c-ocores: move header to platform_data
  i2c: i2c-omap: move header to platform_data
  i2c: i2c-pca-platform: move header to platform_data
  i2c: i2c-xiic: move header to platform_data
  i2c: pnx: move header into the driver

 Documentation/i2c/busses/i2c-ocores|  2 +-
 Documentation/i2c/muxes/i2c-mux-gpio   |  4 +--
 MAINTAINERS|  8 ++---
 arch/arm/mach-ks8695/board-acs5k.c |  2 +-
 arch/arm/mach-omap1/board-htcherald.c  |  2 +-
 arch/arm/mach-omap1/common.h   |  2 +-
 arch/arm/mach-omap1/i2c.c  |  2 +-
 arch/arm/mach-omap2/common.h   |  2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  2 +-
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |  2 +-
 arch/arm/mach-pxa/palmz72.c|  2 +-
 arch/arm/mach-pxa/viper.c  |  2 +-
 arch/arm/mach-sa1100/simpad.c  |  2 +-
 arch/mips/alchemy/board-gpr.c  |  2 +-
 arch/sh/boards/board-sh7785lcr.c   |  2 +-
 drivers/i2c/busses/i2c-gpio.c  |  2 +-
 drivers/i2c/busses/i2c-i801.c  |  2 +-
 drivers/i2c/busses/i2c-ocores.c|  2 +-
 drivers/i2c/busses/i2c-omap.c  |  2 +-
 drivers/i2c/busses/i2c-pca-platform.c  |  2 +-
 drivers/i2c/busses/i2c-pnx.c   | 21 +++-
 drivers/i2c/busses/i2c-xiic.c  |  2 +-
 drivers/i2c/muxes/i2c-mux-gpio.c   |  2 +-
 drivers/media/platform/marvell-ccic/mmp-driver.c   |  2 +-
 drivers/mfd/sm501.c|  2 +-
 drivers/mfd/timberdale.c   |  4 +--
 include/linux/i2c-pnx.h| 38 --
 include/linux/{ => platform_data}/i2c-gpio.h   |  0
 include/linux/{ => platform_data}/i2c-mux-gpio.h   |  0
 include/linux/{ => platform_data}/i2c-ocores.h |  0
 include/linux/{ => platform_data}/i2c-omap.h   |  0
 .../linux/{ => platform_data}/i2c-pca-platform.h   |  0
 include/linux/{ => platform_data}/i2c-xiic.h   |  0
 38 files changed, 55 insertions(+), 74 deletions(-)
 delete mode 100644 include/linux/i2c-pnx.h
 rename include/linux/{ => platform_data}/i2c-gpio.h (100%)
 rename include/linux/{ => platform_data}/i2c-mux-gpio.h (100%)
 rename include/linux/{ => platform_data}/i2c-ocores.h (100%)
 rename include/linux/{ => platform_data}/i2c-omap.h (100%)
 rename include/linux/{ => platform_data}/i2c-pca-platform.h (100%)
 rename include/linux/{ => platform_data}/i2c-xiic.h (100%)

-- 
2.11.0

Re: [PATCH 2/9] cx231xx: Use board profile values for addresses

[Matthias Schwarzott]

Am 17.04.2018 um 18:39 schrieb Brad Love:
> Replace all usage of hard coded values with
> the proper field from the board profile.
> 

Hi Brad,

will there be any interference with the usage to configure the analog
tuner via the fields tuner_addr and tuner_type?

Regards
Matthias

> Signed-off-by: Brad Love 
> ---
>  drivers/media/usb/cx231xx/cx231xx-dvb.c | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
> b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> index 67ed667..99f1a77 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> @@ -728,7 +728,7 @@ static int dvb_init(struct cx231xx *dev)
>   dvb->frontend[0]->callback = cx231xx_tuner_callback;
>  
>   if (!dvb_attach(tda18271_attach, dev->dvb->frontend[0],
> -0x60, tuner_i2c,
> +dev->board.tuner_addr, tuner_i2c,
>  _rde253s_tunerconfig)) {
>   result = -EINVAL;
>   goto out_free;
> @@ -752,7 +752,7 @@ static int dvb_init(struct cx231xx *dev)
>   dvb->frontend[0]->callback = cx231xx_tuner_callback;
>  
>   if (!dvb_attach(tda18271_attach, dev->dvb->frontend[0],
> -0x60, tuner_i2c,
> +dev->board.tuner_addr, tuner_i2c,
>  _rde253s_tunerconfig)) {
>   result = -EINVAL;
>   goto out_free;
> @@ -779,7 +779,7 @@ static int dvb_init(struct cx231xx *dev)
>   dvb->frontend[0]->callback = cx231xx_tuner_callback;
>  
>   dvb_attach(tda18271_attach, dev->dvb->frontend[0],
> -0x60, tuner_i2c,
> +dev->board.tuner_addr, tuner_i2c,
>  _tda18271_config);
>   break;
>  
> @@ -797,7 +797,7 @@ static int dvb_init(struct cx231xx *dev)
>  
>   memset(, 0, sizeof(struct i2c_board_info));
>   strlcpy(info.type, "si2165", I2C_NAME_SIZE);
> - info.addr = 0x64;
> + info.addr = dev->board.demod_addr;
>   info.platform_data = _pdata;
>   request_module(info.type);
>   client = i2c_new_device(demod_i2c, );
> @@ -822,8 +822,7 @@ static int dvb_init(struct cx231xx *dev)
>   dvb->frontend[0]->callback = cx231xx_tuner_callback;
>  
>   dvb_attach(tda18271_attach, dev->dvb->frontend[0],
> - 0x60,
> - tuner_i2c,
> + dev->board.tuner_addr, tuner_i2c,
>   _tda18271_config);
>  
>   dev->cx231xx_reset_analog_tuner = NULL;
> @@ -844,7 +843,7 @@ static int dvb_init(struct cx231xx *dev)
>  
>   memset(, 0, sizeof(struct i2c_board_info));
>   strlcpy(info.type, "si2165", I2C_NAME_SIZE);
> - info.addr = 0x64;
> + info.addr = dev->board.demod_addr;
>   info.platform_data = _pdata;
>   request_module(info.type);
>   client = i2c_new_device(demod_i2c, );
> @@ -879,7 +878,7 @@ static int dvb_init(struct cx231xx *dev)
>   si2157_config.if_port = 1;
>   si2157_config.inversion = true;
>   strlcpy(info.type, "si2157", I2C_NAME_SIZE);
> - info.addr = 0x60;
> + info.addr = dev->board.tuner_addr;
>   info.platform_data = _config;
>   request_module("si2157");
>  
> @@ -938,7 +937,7 @@ static int dvb_init(struct cx231xx *dev)
>   si2157_config.if_port = 1;
>   si2157_config.inversion = true;
>   strlcpy(info.type, "si2157", I2C_NAME_SIZE);
> - info.addr = 0x60;
> + info.addr = dev->board.tuner_addr;
>   info.platform_data = _config;
>   request_module("si2157");
>  
> @@ -985,7 +984,7 @@ static int dvb_init(struct cx231xx *dev)
>   dvb->frontend[0]->callback = cx231xx_tuner_callback;
>  
>   dvb_attach(tda18271_attach, dev->dvb->frontend[0],
> -0x60, tuner_i2c,
> +dev->board.tuner_addr, tuner_i2c,
>  _tda18271_config);
>   break;
>  
> 

Re: [PATCH 5/9] cx231xx: Switch to using new dvb i2c helpers

[Matthias Schwarzott]

Am 17.04.2018 um 18:39 schrieb Brad Love:
> Mostly very straight forward replace of blocks with equivalent code.
> 
> Cleanup added at end of dvb_init in case of failure.
> 
Hi Brad,

I have some suggestions. See below.

Matthias

> Signed-off-by: Brad Love 
> ---
>  drivers/media/usb/cx231xx/cx231xx-dvb.c | 331 
> 
>  1 file changed, 82 insertions(+), 249 deletions(-)
> 
> diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
> b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> index 681610f..318a6cd 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> @@ -613,23 +613,18 @@ static void unregister_dvb(struct cx231xx_dvb *dvb)
>   dvb_frontend_detach(dvb->frontend[1]);
>   dvb_frontend_detach(dvb->frontend[0]);
>   dvb_unregister_adapter(>adapter);
> +
>   /* remove I2C tuner */
>   client = dvb->i2c_client_tuner;
> - if (client) {
> - module_put(client->dev.driver->owner);
> - i2c_unregister_device(client);
> - }
> - /* remove I2C demod */
> + if (client)
> + dvb_module_release(client);
The pointer check is not needed, dvb_module_release does check itself
for NULL.

Other drivers added code to set the client-pointers to NULL after
releasing it.

I suggest to do it like this:
/* remove I2C tuner */
dvb_module_release(dvb->i2c_client_tuner);
dvb->i2c_client_tuner = NULL;


> + /* remove I2C demod(s) */
>   client = dvb->i2c_client_demod[1];
> - if (client) {
> - module_put(client->dev.driver->owner);
> - i2c_unregister_device(client);
> - }
> + if (client)
> + dvb_module_release(client);
>   client = dvb->i2c_client_demod[0];
> - if (client) {
> - module_put(client->dev.driver->owner);
> - i2c_unregister_device(client);
> - }
> + if (client)
> + dvb_module_release(client);

>  }
>  
>  static int dvb_init(struct cx231xx *dev)
> @@ -638,6 +633,8 @@ static int dvb_init(struct cx231xx *dev)
>   struct cx231xx_dvb *dvb;
>   struct i2c_adapter *tuner_i2c;
>   struct i2c_adapter *demod_i2c;
> + struct i2c_client *client;
> + struct i2c_adapter *adapter;
>  
>   if (!dev->board.has_dvb) {
>   /* This device does not support the extension */
> @@ -785,8 +782,6 @@ static int dvb_init(struct cx231xx *dev)
>  
>   case CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx:
>   {
> - struct i2c_client *client;
> - struct i2c_board_info info;
>   struct si2165_platform_data si2165_pdata = {};
>  
>   /* attach demod */
> @@ -794,25 +789,14 @@ static int dvb_init(struct cx231xx *dev)
>   si2165_pdata.chip_mode = SI2165_MODE_PLL_XTAL;
>   si2165_pdata.ref_freq_hz = 1600;
>  
> - memset(, 0, sizeof(struct i2c_board_info));
> - strlcpy(info.type, "si2165", I2C_NAME_SIZE);
> - info.addr = dev->board.demod_addr;
> - info.platform_data = _pdata;
> - request_module(info.type);
> - client = i2c_new_device(demod_i2c, );
> - if (!client || !client->dev.driver || !dev->dvb->frontend[0]) {
> - dev_err(dev->dev,
> - "Failed to attach SI2165 front end\n");
> - result = -EINVAL;
> - goto out_free;
> - }
> -
> - if (!try_module_get(client->dev.driver->owner)) {
> - i2c_unregister_device(client);
> + /* perform tuner probe/init/attach */
> + client = dvb_module_probe("si2165", NULL, demod_i2c,
> + dev->board.demod_addr,
> + _pdata);
> + if (!client) {
>   result = -ENODEV;
>   goto out_free;
>   }
> -
>   dvb->i2c_client_demod[0] = client;
>  
>   dev->dvb->frontend[0]->ops.i2c_gate_ctrl = NULL;
> @@ -829,8 +813,6 @@ static int dvb_init(struct cx231xx *dev)
>   }
>   case CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx:
>   {
> - struct i2c_client *client;
> - struct i2c_board_info info;
>   struct si2165_platform_data si2165_pdata = {};
>   struct si2157_config si2157_config = {};
>  
> @@ -839,29 +821,16 @@ static int dvb_init(struct cx231xx *dev)
>   si2165_pdata.chip_mode = SI2165_MODE_PLL_EXT;
>   si2165_pdata.ref_freq_hz = 2400;
>  
> - memset(, 0, sizeof(struct i2c_board_info));
> - strlcpy(info.type, "si2165", I2C_NAME_SIZE);
> - info.addr = dev->board.demod_addr;
> - info.platform_data = _pdata;
> - request_module(info.type);
> - client = i2c_new_device(demod_i2c, );
> - if 

Re: imx-media: MT9P031 Capture issues on IMX6

[Fabio Estevam]

On Thu, Apr 19, 2018 at 1:55 PM, Ibtsam Ul-Haq
 wrote:

> I can see by using a logic analyzer that the PIXCLK does not look
> nice. It looks similar to the issue mentioned here:
> https://community.nxp.com/thread/454467
>
> except that in my case it looks pulled up instead of down.
> However I do not yet have a clue what causes this.
> VSYNC and HSYNC waveforms look ok, until the whole capture is stopped
> due to the error, after 14 frames.
> The relevant pinctrl settings in the dts are:
>
> MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK0x4001b0b0
> MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC0x4001b0b0
> MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC0x4001b0b0

Not sure why you are setting the SION bit (bit 30) on the CSI pads.

Does it work better if you do not set it?

For your reference: this is what we do on imx6qdl-sabresd.dtsi:

MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA120x1b0b0
MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA130x1b0b0
MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA140x1b0b0
MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA150x1b0b0
MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA160x1b0b0
MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA170x1b0b0
MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA180x1b0b0
MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA190x1b0b0
MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK   0x1b0b0
MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC  0x1b0b0
MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x1b0b0

Re: imx-media: MT9P031 Capture issues on IMX6

[Ibtsam Ul-Haq]

On Tue, Apr 17, 2018 at 2:33 PM, Philipp Zabel  wrote:
> On Tue, 2018-04-17 at 11:32 +0200, Ibtsam Ul-Haq wrote:
>> On Tue, Apr 17, 2018 at 10:34 AM, Philipp Zabel  
>> wrote:
>> > Hi Ibtsam,
>> >
>> > On Tue, 2018-04-17 at 09:26 +0200, Ibtsam Ul-Haq wrote:
>> > > On Mon, Apr 16, 2018 at 11:30 AM, Philipp Zabel  
>> > > wrote:
>> > > > On Mon, 2018-04-16 at 09:54 +0200, Ibtsam Ul-Haq wrote:
>> > > > [...]
>> > > > > This indeed looks the case. But then, is 'GR16' the FourCC for 
>> > > > > 'SGRBG16'?
>> > > >
>> > > > Yes, see Documentation/media/uapi/v4l/pixfmt-srggb16.rst:
>> > > > https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-srggb16.html
>> > > >
>> > > > > To be honest, I had not seen GR16 as FourCC before.
>> > > > > And the Gstreamer debug logs (I used GST_DEBUG=5) also say that they
>> > > > > do not know this FourCC:
>> > > > > v4l2 gstv4l2object.c:1541:gst_v4l2_object_v4l2fourcc_to_bare_struct: 
>> > > > > [00m
>> > > > > Unsupported fourcc 0x36315247 GR16
>> > > >
>> > > > The GStreamer V4L2 elements currently only support 8-bit per component
>> > > > Bayer formats.
>> > > >
>> > > > > Is there a way we can get by this?
>> > > >
>> > > > There's two ways to handle this correctly, IMHO. One would be adding
>> > > > SGRBG8_1X8 support to the mt9p031 driver. This is the correct way if 
>> > > > the
>> > > > device tree is configured for 8-bit parallel and there are only 8 data
>> > > > lines connected between camera and SoC. As a quick hack, I think you
>> > > > could just:
>> > > >
>> > > >   sed "s/MEDIA_BUS_FMT_SGRBG12_1X12/MEDIA_BUS_FMT_SGRBG8_1X8/" -i 
>> > > > drivers/media/i2c/mt9p031.c
>> > > >
>> > >
>> > >
>> > > I tried that and it works well for my case. All pads in the pipeline
>> > > now report their format as SGRBG8_1X8.
>> > >
>> > > However, now I am getting a Broken Pipe error from STREAMON when I try
>> > > to run the pipeline:
>> > > v4l2bufferpool 
>> > > gstv4l2bufferpool.c:677:gst_v4l2_buffer_pool_streamon:
>> > > [00m
>> > > error with STREAMON 32 (Broken pipe)
>> >
>> > What about format width and height, are they the same throughout the
>> > pipeline? It didn't look that way in your last mail.
>> >
>>
>> Indeed they were not the same. That was probably because the default
>> window width and height were 2592x1944.
>> So when I tried to set resolution to 640x480, it actually became
>> 648x486, and the ipu1_csi0 expanded it to 656x486.
>
> Yes, the CSI currently aligns width to a multiple of 16 pixels to
> simplify handling DMA controller alignment restrictions.
> This should probably be relaxed, especially for non-planar formats.
>
>> I have that changed now, so the pads now look to have the same width and 
>> height:
>>
>> :~# media-ctl --get-v4l2 "'mt9p031 0-0048':0"
>> [fmt:SGRBG8_1X8/640x480 field:none colorspace:srgb
>>  crop:(16,54)/2560x1920]
>>
>> :~# media-ctl --get-v4l2 "'mt9p031 0-0048':0"
>> [fmt:SGRBG8_1X8/640x480 field:none colorspace:srgb
>>  crop:(16,54)/2560x1920]
>>
>> :~# media-ctl --get-v4l2 "'ipu1_csi0_mux':1"
>> [fmt:SGRBG8_1X8/640x480 field:none colorspace:srgb]
>>
>> :~# media-ctl --get-v4l2 "'ipu1_csi0_mux':2"
>> [fmt:SGRBG8_1X8/640x480 field:none colorspace:srgb]
>>
>> :~# media-ctl --get-v4l2 "'ipu1_csi0':0"
>> [fmt:SGRBG8_1X8/640x480@1/30 field:none
>> colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range
>>  crop.bounds:(0,0)/640x480
>>  crop:(0,0)/640x480
>>  compose.bounds:(0,0)/640x480
>>  compose:(0,0)/640x480]
>>
>> :~# media-ctl --get-v4l2 "'ipu1_csi0':2"
>> [fmt:SGRBG8_1X8/640x480@1/30 field:none
>> colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range]
>>
>> But now I am getting:
>> gst_v4l2_buffer_pool_pthe handlingoll ():
>> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
>> poll error 1: Invalid argument (22)
>>
>> This is accompanied by dmesg errors:
>> [ 8056.756841] alloc_contig_range: [80400, 80496) PFNs busy
>
> This is not a memory allocation problem. The above is a harmless info
> message that points out a slight inefficiency in the CMA allocator.
>
>> [ 8057.833501] ipu1_csi0: EOF timeout
>> [ 8058.953717] ipu1_csi0: wait last EOF timeout
>
> This is the problem. The driver believes all is configured correctly.
> It starts the DMA transfer and waits for the End-Of-Frame interrupt.
> The reason that doesn't happen could be the sensor failing to start
> streaming, or the signal not arriving at the CSI properly. Can you
> measure the pixel clock and vsync/hsync signals? Is pinctrl set up
> correctly?
>


I can see by using a logic analyzer that the PIXCLK does not look
nice. It looks similar to the issue mentioned here:
https://community.nxp.com/thread/454467

except that in my case it looks pulled up instead of down.
However I do not yet have a 

Re: [PATCH v2 4/4] media: v4l2-compat-ioctl32: better document the code

[Mauro Carvalho Chehab]

Em Thu, 19 Apr 2018 12:33:32 -0400
Mauro Carvalho Chehab  escreveu:

> This file does a lot of non-trivial struff. Document it using
> kernel-doc markups where needed and improve the comments inside
> do_video_ioctl().

Sent it too fast. It should be merged with this diff:

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 777ed179af5f..c460fbcbc035 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -46,12 +46,12 @@
  * pointer with userspace data that is not tagged with __user.
  *
  * @__x: var where data will be stored
- * @ptr: var were data will be retrieved.
+ * @__ptr: var were data will be retrieved.
  *
  * Sometimes, we need to declare a pointer without __user, because it
  * comes from a pointer struct field that will be retrieved from userspace
  * by the 64-bit native ioctl handler. This function ensures that the
- * @ptr will be casted to __user before calling get_user(), in order to
+ * @__ptr will be casted to __user before calling get_user(), in order to
  * avoid warnings with static code analyzers like smatch.
  */
 #define get_user_cast(__x, __ptr)  \
@@ -64,12 +64,12 @@
  *   into an userspace pointer, removing any __user cast.
  *
  * @__x: var where data will be stored
- * @ptr: var were data will be retrieved.
+ * @__ptr: var were data will be retrieved.
  *
  * As the compat32 code now handles with 32-bits and 64-bits __user
  * structs, sometimes we need to remove the __user atributes from some data,
  * by passing __force macro. This function ensures that the
- * @ptr will be casted with __force before calling put_user(), in order to
+ * @__ptr will be casted with __force before calling put_user(), in order to
  * avoid warnings with static code analyzers like smatch.
  */
 #define put_user_force(__x, __ptr) \

Full patch enclosed.

Thanks,
Mauro

[PATCHv3 4/4] media: v4l2-compat-ioctl32: better document the code

This file does a lot of non-trivial struff. Document it using
kernel-doc markups where needed and improve the comments inside
do_video_ioctl().

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index d2f0268427c2..c460fbcbc035 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -22,7 +22,18 @@
 #include 
 #include 
 
-/* Use the same argument order as copy_in_user */
+/**
+ * assign_in_user() - Copy from one __user var to another one
+ *
+ * @to: __user var where data will be stored
+ * @from: __user var were data will be retrieved.
+ *
+ * As this code very often needs to allocate userspace memory, it is easier
+ * to have a macro that will do both get_user() and put_user() at once.
+ *
+ * This function complements the macros defined at asm-generic/uaccess.h.
+ * It uses the same argument order as copy_in_user()
+ */
 #define assign_in_user(to, from)   \
 ({ \
typeof(*from) __assign_tmp; \
@@ -30,16 +41,57 @@
get_user(__assign_tmp, from) || put_user(__assign_tmp, to); \
 })
 
+/**
+ * get_user_cast() - Stores at a kernelspace local var the contents from a
+ * pointer with userspace data that is not tagged with __user.
+ *
+ * @__x: var where data will be stored
+ * @__ptr: var were data will be retrieved.
+ *
+ * Sometimes, we need to declare a pointer without __user, because it
+ * comes from a pointer struct field that will be retrieved from userspace
+ * by the 64-bit native ioctl handler. This function ensures that the
+ * @__ptr will be casted to __user before calling get_user(), in order to
+ * avoid warnings with static code analyzers like smatch.
+ */
 #define get_user_cast(__x, __ptr)  \
 ({ \
get_user(__x, (typeof(*__ptr) __user *)(__ptr));\
 })
 
+/**
+ * put_user_force() - Stores at the contents of a kernelspace local var
+ *   into an userspace pointer, removing any __user cast.
+ *
+ * @__x: var where data will be stored
+ * @__ptr: var were data will be retrieved.
+ *
+ * As the compat32 code now handles with 32-bits and 64-bits __user
+ * structs, sometimes we need to remove the __user atributes from some data,
+ * by passing __force macro. This function ensures that the
+ * @__ptr will be casted with __force before calling put_user(), in order to
+ * avoid warnings with static code analyzers like smatch.
+ */
 #define put_user_force(__x, __ptr) \
 ({  

[PATCH v2 2/4] media: v4l2-compat-ioctl32: better name userspace pointers

[Mauro Carvalho Chehab]

In the past, "up" were an acronym for "user pointer" and "kp" for
"kernel pointer". However, since a1dfb4c48cc1 ("media:
v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"), both
are now __user pointers.

So, the usage of "kp" is really misleading there. So, rename
both to just "p32" and "p64" everywhere it occurs, in order to
make peace with this file's namespace.

There are two exceptions to "up/kp" nomenclature: at
alloc_userspace() and at do_video_ioctl().

There, a new userspace pointer were allocated, in order to store
the 64 bits version of the ioctl. Those were called as "up_native",
with is, IMHO, an even worse name, as "native" could mislead of
being the arguments that were filled from userspace. I almost
renamed it to just "p64", but, after thinking more about that,
it sounded better to call it as "new_p64", as this makes clearer
that this is the data structure that was allocated inside this
file in order to be used to pass/retrieve data when calling the
64-bit ready file->f_op->unlocked_ioctl() function.

Suggested-by: Sakari Ailus 
Suggested-by: Hans Verkuil 
Reviewed-by: Hans Verkuil 
Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 588 +-
 1 file changed, 294 insertions(+), 294 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 51c7c5ab15ef..680b64c1d69a 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -56,8 +56,8 @@ struct v4l2_window32 {
__u8global_alpha;
 };
 
-static int get_v4l2_window32(struct v4l2_window __user *kp,
-struct v4l2_window32 __user *up,
+static int get_v4l2_window32(struct v4l2_window __user *p64,
+struct v4l2_window32 __user *p32,
 void __user *aux_buf, u32 aux_space)
 {
struct v4l2_clip32 __user *uclips;
@@ -65,26 +65,26 @@ static int get_v4l2_window32(struct v4l2_window __user *kp,
compat_caddr_t p;
u32 clipcount;
 
-   if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
-   copy_in_user(>w, >w, sizeof(up->w)) ||
-   assign_in_user(>field, >field) ||
-   assign_in_user(>chromakey, >chromakey) ||
-   assign_in_user(>global_alpha, >global_alpha) ||
-   get_user(clipcount, >clipcount) ||
-   put_user(clipcount, >clipcount))
+   if (!access_ok(VERIFY_READ, p32, sizeof(*p32)) ||
+   copy_in_user(>w, >w, sizeof(p32->w)) ||
+   assign_in_user(>field, >field) ||
+   assign_in_user(>chromakey, >chromakey) ||
+   assign_in_user(>global_alpha, >global_alpha) ||
+   get_user(clipcount, >clipcount) ||
+   put_user(clipcount, >clipcount))
return -EFAULT;
if (clipcount > 2048)
return -EINVAL;
if (!clipcount)
-   return put_user(NULL, >clips);
+   return put_user(NULL, >clips);
 
-   if (get_user(p, >clips))
+   if (get_user(p, >clips))
return -EFAULT;
uclips = compat_ptr(p);
if (aux_space < clipcount * sizeof(*kclips))
return -EFAULT;
kclips = aux_buf;
-   if (put_user(kclips, >clips))
+   if (put_user(kclips, >clips))
return -EFAULT;
 
while (clipcount--) {
@@ -98,27 +98,27 @@ static int get_v4l2_window32(struct v4l2_window __user *kp,
return 0;
 }
 
-static int put_v4l2_window32(struct v4l2_window __user *kp,
-struct v4l2_window32 __user *up)
+static int put_v4l2_window32(struct v4l2_window __user *p64,
+struct v4l2_window32 __user *p32)
 {
struct v4l2_clip __user *kclips;
struct v4l2_clip32 __user *uclips;
compat_caddr_t p;
u32 clipcount;
 
-   if (copy_in_user(>w, >w, sizeof(kp->w)) ||
-   assign_in_user(>field, >field) ||
-   assign_in_user(>chromakey, >chromakey) ||
-   assign_in_user(>global_alpha, >global_alpha) ||
-   get_user(clipcount, >clipcount) ||
-   put_user(clipcount, >clipcount))
+   if (copy_in_user(>w, >w, sizeof(p64->w)) ||
+   assign_in_user(>field, >field) ||
+   assign_in_user(>chromakey, >chromakey) ||
+   assign_in_user(>global_alpha, >global_alpha) ||
+   get_user(clipcount, >clipcount) ||
+   put_user(clipcount, >clipcount))
return -EFAULT;
if (!clipcount)
return 0;
 
-   if (get_user(kclips, >clips))
+   if (get_user(kclips, >clips))
return -EFAULT;
-   if (get_user(p, >clips))
+   if (get_user(p, >clips))
return -EFAULT;

[PATCH v2 4/4] media: v4l2-compat-ioctl32: better document the code

[Mauro Carvalho Chehab]

This file does a lot of non-trivial struff. Document it using
kernel-doc markups where needed and improve the comments inside
do_video_ioctl().

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 166 +-
 1 file changed, 160 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index d2f0268427c2..777ed179af5f 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -22,7 +22,18 @@
 #include 
 #include 
 
-/* Use the same argument order as copy_in_user */
+/**
+ * assign_in_user() - Copy from one __user var to another one
+ *
+ * @to: __user var where data will be stored
+ * @from: __user var were data will be retrieved.
+ *
+ * As this code very often needs to allocate userspace memory, it is easier
+ * to have a macro that will do both get_user() and put_user() at once.
+ *
+ * This function complements the macros defined at asm-generic/uaccess.h.
+ * It uses the same argument order as copy_in_user()
+ */
 #define assign_in_user(to, from)   \
 ({ \
typeof(*from) __assign_tmp; \
@@ -30,16 +41,57 @@
get_user(__assign_tmp, from) || put_user(__assign_tmp, to); \
 })
 
+/**
+ * get_user_cast() - Stores at a kernelspace local var the contents from a
+ * pointer with userspace data that is not tagged with __user.
+ *
+ * @__x: var where data will be stored
+ * @ptr: var were data will be retrieved.
+ *
+ * Sometimes, we need to declare a pointer without __user, because it
+ * comes from a pointer struct field that will be retrieved from userspace
+ * by the 64-bit native ioctl handler. This function ensures that the
+ * @ptr will be casted to __user before calling get_user(), in order to
+ * avoid warnings with static code analyzers like smatch.
+ */
 #define get_user_cast(__x, __ptr)  \
 ({ \
get_user(__x, (typeof(*__ptr) __user *)(__ptr));\
 })
 
+/**
+ * put_user_force() - Stores at the contents of a kernelspace local var
+ *   into an userspace pointer, removing any __user cast.
+ *
+ * @__x: var where data will be stored
+ * @ptr: var were data will be retrieved.
+ *
+ * As the compat32 code now handles with 32-bits and 64-bits __user
+ * structs, sometimes we need to remove the __user atributes from some data,
+ * by passing __force macro. This function ensures that the
+ * @ptr will be casted with __force before calling put_user(), in order to
+ * avoid warnings with static code analyzers like smatch.
+ */
 #define put_user_force(__x, __ptr) \
 ({ \
put_user((typeof(*__x) __force *)(__x), __ptr); \
 })
 
+/**
+ * assign_in_user_cast() - Copy from one __user var to another one
+ *
+ * @to: __user var where data will be stored
+ * @from: var were data will be retrieved that needs to be cast to __user.
+ *
+ * As this code very often needs to allocate userspace memory, it is easier
+ * to have a macro that will do both get_user_cast() and put_user() at once.
+ *
+ * This function should be used instead of assign_in_user() when the @from
+ * variable was not declared as __user. See get_user_cast() for more details.
+ *
+ * This function complements the macros defined at asm-generic/uaccess.h.
+ * It uses the same argument order as copy_in_user()
+ */
 #define assign_in_user_cast(to, from)  \
 ({ \
typeof(*from) __assign_tmp; \
@@ -47,7 +99,16 @@
get_user_cast(__assign_tmp, from) || put_user(__assign_tmp, to);\
 })
 
-
+/**
+ * native_ioctl - Ancillary function that calls the native 64 bits ioctl
+ * handler.
+ *
+ * @file: pointer to  file with the file handler
+ * @cmd: ioctl to be called
+ * @arg: arguments passed from/to the ioctl handler
+ *
+ * This function calls the native ioctl handler at v4l2-dev, e. g. v4l2_ioctl()
+ */
 static long native_ioctl(struct file *file, unsigned int cmd, unsigned long 
arg)
 {
long ret = -ENOIOCTLCMD;
@@ -59,6 +120,21 @@ static long native_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
 }
 
 
+/*
+ * Per-ioctl data copy handlers.
+ *
+ * Those come in pairs, with a get_v4l2_foo() and a put_v4l2_foo() routine,
+ * where "v4l2_foo" is the name of the V4L2 struct.
+ *
+ * They basically get two __user pointers, one with a 32-bits struct that
+ * came from the userspace call and a 64-bits struct, also allocated as
+ * userspace, but filled 

[PATCH v2 3/4] media: v4l2-compat-ioctl32: simplify casts

[Mauro Carvalho Chehab]

Making the cast right for get_user/put_user is not trivial, as
it needs to ensure that the types are the correct ones.

Improve it by using macros.

Tested with vivid with:
$ sudo modprobe vivid no_error_inj=1
$ v4l2-compliance-32bits -a -s10 >32bits && v4l2-compliance-64bits -a 
-s10 > 64bits && diff -U0 32bits 64bits
--- 32bits  2018-04-17 11:18:29.141240772 -0300
+++ 64bits  2018-04-17 11:18:40.635282341 -0300
@@ -1 +1 @@
-v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 32 
bits
+v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 64 
bits

Using the latest version of v4l-utils with this patch applied:
https://patchwork.linuxtv.org/patch/48746/

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 36 +++
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 680b64c1d69a..d2f0268427c2 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -30,6 +30,24 @@
get_user(__assign_tmp, from) || put_user(__assign_tmp, to); \
 })
 
+#define get_user_cast(__x, __ptr)  \
+({ \
+   get_user(__x, (typeof(*__ptr) __user *)(__ptr));\
+})
+
+#define put_user_force(__x, __ptr) \
+({ \
+   put_user((typeof(*__x) __force *)(__x), __ptr); \
+})
+
+#define assign_in_user_cast(to, from)  \
+({ \
+   typeof(*from) __assign_tmp; \
+   \
+   get_user_cast(__assign_tmp, from) || put_user(__assign_tmp, to);\
+})
+
+
 static long native_ioctl(struct file *file, unsigned int cmd, unsigned long 
arg)
 {
long ret = -ENOIOCTLCMD;
@@ -543,8 +561,7 @@ static int get_v4l2_buffer32(struct v4l2_buffer __user *p64,
return -EFAULT;
 
uplane = aux_buf;
-   if (put_user((__force struct v4l2_plane *)uplane,
->m.planes))
+   if (put_user_force(uplane, >m.planes))
return -EFAULT;
 
while (num_planes--) {
@@ -682,7 +699,7 @@ static int get_v4l2_framebuffer32(struct v4l2_framebuffer 
__user *p64,
 
if (!access_ok(VERIFY_READ, p32, sizeof(*p32)) ||
get_user(tmp, >base) ||
-   put_user((void __force *)compat_ptr(tmp), >base) ||
+   put_user_force(compat_ptr(tmp), >base) ||
assign_in_user(>capability, >capability) ||
assign_in_user(>flags, >flags) ||
copy_in_user(>fmt, >fmt, sizeof(p64->fmt)))
@@ -831,8 +848,7 @@ static int get_v4l2_ext_controls32(struct file *file,
if (aux_space < count * sizeof(*kcontrols))
return -EFAULT;
kcontrols = aux_buf;
-   if (put_user((__force struct v4l2_ext_control *)kcontrols,
->controls))
+   if (put_user_force(kcontrols, >controls))
return -EFAULT;
 
for (n = 0; n < count; n++) {
@@ -898,10 +914,9 @@ static int put_v4l2_ext_controls32(struct file *file,
unsigned int size = sizeof(*ucontrols);
u32 id;
 
-   if (get_user(id, (unsigned int __user *)>id) ||
+   if (get_user_cast(id, >id) ||
put_user(id, >id) ||
-   assign_in_user(>size,
-  (unsigned int __user *)>size) ||
+   assign_in_user_cast(>size, >size) ||
copy_in_user(>reserved2,
 (void __user *)>reserved2,
 sizeof(ucontrols->reserved2)))
@@ -970,10 +985,9 @@ static int get_v4l2_edid32(struct v4l2_edid __user *p64,
if (!access_ok(VERIFY_READ, p32, sizeof(*p32)) ||
assign_in_user(>pad, >pad) ||
assign_in_user(>start_block, >start_block) ||
-   assign_in_user(>blocks,
-  (u32 __user *)>blocks) ||
+   assign_in_user_cast(>blocks, >blocks) ||
get_user(tmp, >edid) ||
-   put_user((void __force *)compat_ptr(tmp), >edid) ||
+   put_user_force(compat_ptr(tmp), >edid) ||
copy_in_user(p64->reserved, p32->reserved, sizeof(p64->reserved)))
return -EFAULT;
return 0;
-- 
2.14.3

[PATCH v2 1/4] media: v4l2-compat-ioctl32: fix several __user annotations

[Mauro Carvalho Chehab]

Smatch report several issues with bad __user annotations:

  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect type 
in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:expected void 
[noderef] *uptr
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:got void *
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: warning: incorrect type 
in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:expected void const 
volatile [noderef] *
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:got struct 
v4l2_plane [noderef] **
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: warning: incorrect type 
in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:expected void 
[noderef] *uptr
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:got void *[assigned] 
base
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: warning: incorrect type 
in assignment (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:expected struct 
v4l2_ext_control [noderef] *kcontrols
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:got struct 
v4l2_ext_control *
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: warning: incorrect type 
in assignment (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:expected unsigned 
char [usertype] *__pu_val
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:got void [noderef] 
*
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: warning: incorrect type 
in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:expected void 
[noderef] *uptr
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:got void *[assigned] 
edid

Fix them.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 51 ++-
 1 file changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index d03a44d89649..51c7c5ab15ef 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -443,8 +443,8 @@ static int put_v4l2_plane32(struct v4l2_plane __user *up,
return -EFAULT;
break;
case V4L2_MEMORY_USERPTR:
-   if (get_user(p, >m.userptr) ||
-   put_user((compat_ulong_t)ptr_to_compat((__force void *)p),
+   if (get_user(p, >m.userptr)||
+   put_user((compat_ulong_t)ptr_to_compat((void __user *)p),
 >m.userptr))
return -EFAULT;
break;
@@ -587,7 +587,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user *kp,
u32 length;
enum v4l2_memory memory;
struct v4l2_plane32 __user *uplane32;
-   struct v4l2_plane __user *uplane;
+   struct v4l2_plane *uplane;
compat_caddr_t p;
int ret;
 
@@ -617,15 +617,22 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
*kp,
 
if (num_planes == 0)
return 0;
-
-   if (get_user(uplane, ((__force struct v4l2_plane __user 
**)>m.planes)))
+   /* We need to define uplane without __user, even though
+* it does point to data in userspace here. The reason is
+* that v4l2-ioctl.c copies it from userspace to kernelspace,
+* so its definition in videodev2.h doesn't have a
+* __user markup. Defining uplane with __user causes
+* smatch warnings, so instead declare it without __user
+* and cast it as a userspace pointer to put_v4l2_plane32().
+*/
+   if (get_user(uplane, >m.planes))
return -EFAULT;
if (get_user(p, >m.planes))
return -EFAULT;
uplane32 = compat_ptr(p);
 
while (num_planes--) {
-   ret = put_v4l2_plane32(uplane, uplane32, memory);
+   ret = put_v4l2_plane32((void __user *)uplane, uplane32, 
memory);
if (ret)
return ret;
++uplane;
@@ -675,7 +682,7 @@ static int get_v4l2_framebuffer32(struct v4l2_framebuffer 
__user *kp,
 
if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
get_user(tmp, >base) ||
-   put_user((__force void *)compat_ptr(tmp), >base) ||
+   put_user((void __force *)compat_ptr(tmp), >base) ||
assign_in_user(>capability, >capability) ||
assign_in_user(>flags, >flags) ||
copy_in_user(>fmt, >fmt, sizeof(kp->fmt)))
@@ -690,7 +697,7 @@ static int 

[PATCH v2 0/4] Improve v4l2-compat-ioctl32 handler getting rid of smatch warnings

[Mauro Carvalho Chehab]

This series correspond to the last 3 patches of my previous patch series:
https://www.spinics.net/lists/linux-media/msg132453.html

It contains the compat32 related bits.

Version 2 addresses some comments from Hans.
It adds a new patch better documenting it.

Mauro Carvalho Chehab (4):
  media: v4l2-compat-ioctl32: fix several __user annotations
  media: v4l2-compat-ioctl32: better name userspace pointers
  media: v4l2-compat-ioctl32: simplify casts
  media: v4l2-compat-ioctl32: better document the code

 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 805 --
 1 file changed, 496 insertions(+), 309 deletions(-)

-- 
2.14.3

Re: [PATCH v2 08/10] media: ov772x: handle nested s_power() calls

[Akinobu Mita]

2018-04-18 21:41 GMT+09:00 jacopo mondi :
> Hi Akinobu,
>
> On Mon, Apr 16, 2018 at 11:51:49AM +0900, Akinobu Mita wrote:
>> Depending on the v4l2 driver, calling s_power() could be nested.  So the
>> actual transitions between power saving mode and normal operation mode
>> should only happen at the first power on and the last power off.
>
> What do you mean with 'nested' ?
>
> My understanding is that:
> - if a sensor driver is mc compliant, it's s_power is called from
>   v4l2_mc.c pipeline_pm_power_one() only when the power state changes
> - if a sensor driver is not mc compliant, the s_power routine is
>   called from the platform driver, and it should not happen that it is
>   called twice with the same power state
> - if a sensor implements subdev's internal operations open and close
>   it may call it's own s_power routines from there, and it can be
>   opened more that once.
>
> My understanding is that this driver s_power routines are only called
> from platform drivers, and they -should- be safe.

For pxa_camera driver, if there are more than two openers for a video
device at the same time, calling s_power() could be nested.  Because
there is nothing to prevent from calling s_power() in
pxac_fops_camera_open().

However, most of other V4L2 drivers use v4l2_fh_is_singular_file() to
prevent from nested s_power() in their open operation.  So we can do
the same for pxa_camera driver.

> Although, I'm not against this protection completely. Others might be,
> though.
>
>>
>> This adds an s_power() nesting counter and updates the power state if the
>> counter is modified from 0 to != 0 or from != 0 to 0.
>>
>> Cc: Jacopo Mondi 
>> Cc: Laurent Pinchart 
>> Cc: Hans Verkuil 
>> Cc: Sakari Ailus 
>> Cc: Mauro Carvalho Chehab 
>> Signed-off-by: Akinobu Mita 
>> ---
>> * v2
>> - New patch
>>
>>  drivers/media/i2c/ov772x.c | 33 +
>>  1 file changed, 29 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
>> index 4245a46..2cd6e85 100644
>> --- a/drivers/media/i2c/ov772x.c
>> +++ b/drivers/media/i2c/ov772x.c
>> @@ -424,6 +424,9 @@ struct ov772x_priv {
>>   /* band_filter = COM8[5] ? 256 - BDBASE : 0 */
>>   unsigned shortband_filter;
>>   unsigned int  fps;
>> + /* lock to protect power_count */
>> + struct mutex  power_lock;
>> + int   power_count;
>>  #ifdef CONFIG_MEDIA_CONTROLLER
>>   struct media_pad pad;
>>  #endif
>> @@ -871,9 +874,25 @@ static int ov772x_power_off(struct ov772x_priv *priv)
>>  static int ov772x_s_power(struct v4l2_subdev *sd, int on)
>>  {
>>   struct ov772x_priv *priv = to_ov772x(sd);
>> + int ret = 0;
>> +
>> + mutex_lock(>power_lock);
>>
>> - return on ? ov772x_power_on(priv) :
>> - ov772x_power_off(priv);
>> + /* If the power count is modified from 0 to != 0 or from != 0 to 0,
>> +  * update the power state.
>> +  */
>> + if (priv->power_count == !on)
>> + ret = on ? ov772x_power_on(priv) : ov772x_power_off(priv);
>
> Just release the mutex and return 0 if (power_count == on)
> The code will be more readable imho.

OK.  Actually, the change in this patch is used like boilerplate in
many subdev drivers.  Also, it's better to print warning when nested
s_power() call is detected as it should not be happened.

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

[Philipp Zabel]

Hi Paul,

On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote:
> This adds a device-tree binding document that specifies the properties
> used by the Sunxi-Cedurs VPU driver, as well as examples.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  .../devicetree/bindings/media/sunxi-cedrus.txt | 50 
> ++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/sunxi-cedrus.txt 
> b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> new file mode 100644
> index ..71ad3f9c3352
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> @@ -0,0 +1,50 @@
> +Device-tree bindings for the VPU found in Allwinner SoCs, referred to as the
> +Video Engine (VE) in Allwinner literature.
> +
> +The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped 
> starting
> +from the DRAM base. This requires specific memory allocation and handling.
> +
> +Required properties:
> +- compatible : "allwinner,sun4i-a10-video-engine";
> +- memory-region : DMA pool for buffers allocation;
> +- clocks : list of clock specifiers, corresponding to entries in
> +  the clock-names property;
> +- clock-names: should contain "ahb", "mod" and "ram" entries;
> +- assigned-clocks   : list of clocks assigned to the VE;
> +- assigned-clocks-rates : list of clock rates for the clocks assigned to the 
> VE;
> +- resets : phandle for reset;
> +- interrupts : should contain VE interrupt number;
> +- reg: should contain register base and length of VE.
> +
> +Example:
> +
> +reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
> + ve_memory: cma@4a00 {
> + compatible = "shared-dma-pool";
> + reg = <0x4a00 0x600>;
> + no-map;
> + linux,cma-default;
> + };
> +};
> +
> +video-engine@1c0e000 {

This is not really required by any specification, and not as common as
gpu@..., but could this reasonably be called "vpu@1c0e000" to follow
somewhat-common practice?

> + compatible = "allwinner,sun4i-a10-video-engine";
> + reg = <0x01c0e000 0x1000>;
> + memory-region = <_memory>;
> +
> + clocks = < CLK_AHB_VE>, < CLK_VE>,
> +  < CLK_DRAM_VE>;
> + clock-names = "ahb", "mod", "ram";
> +
> + assigned-clocks = < CLK_VE>;
> + assigned-clock-rates = <32000>;
> +
> + resets = < RST_VE>;
> +
> + interrupts = ;
> +};

regards
Philipp

[PATCH v2 05/10] media: v4l: Add definitions for MPEG2 frame format and header metadata

[Paul Kocialkowski]

Stateless video decoding engines require both the MPEG slices and
associated metadata from the video stream in order to decode frames.

This introduces definitions for a new pixel format, describing buffers
with MPEG2 slice data, as well as a control structure for passing the
frame header (metadata) to drivers.

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Florent Revest 
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++
 drivers/media/v4l2-core/v4l2-ioctl.c |  1 +
 include/uapi/linux/v4l2-controls.h   | 26 ++
 include/uapi/linux/videodev2.h   |  3 +++
 4 files changed, 40 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index ba05a8b9a095..fcdc12b9a9e0 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -761,6 +761,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: return 
"Vertical MV Search Range";
case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat 
Sequence Header";
case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME:   return "Force 
Key Frame";
+   case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:   return "MPEG2 
Frame Header";
 
/* VPX controls */
case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS:return "VPX 
Number of Partitions";
@@ -1152,6 +1153,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_RDS_TX_ALT_FREQS:
*type = V4L2_CTRL_TYPE_U32;
break;
+   case V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR:
+   *type = V4L2_CTRL_TYPE_MPEG2_FRAME_HDR;
+   break;
default:
*type = V4L2_CTRL_TYPE_INTEGER;
break;
@@ -1472,6 +1476,9 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32 
idx,
return -ERANGE;
return 0;
 
+   case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
+   return 0;
+
default:
return -EINVAL;
}
@@ -2046,6 +2053,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct 
v4l2_ctrl_handler *hdl,
case V4L2_CTRL_TYPE_U32:
elem_size = sizeof(u32);
break;
+   case V4L2_CTRL_TYPE_MPEG2_FRAME_HDR:
+   elem_size = sizeof(struct v4l2_ctrl_mpeg2_frame_hdr);
+   break;
default:
if (type < V4L2_CTRL_COMPOUND_TYPES)
elem_size = sizeof(s32);
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 468c3c65362d..8070203da5d2 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1273,6 +1273,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_VC1_ANNEX_L:  descr = "VC-1 (SMPTE 412M Annex 
L)"; break;
case V4L2_PIX_FMT_VP8:  descr = "VP8"; break;
case V4L2_PIX_FMT_VP9:  descr = "VP9"; break;
+   case V4L2_PIX_FMT_MPEG2_FRAME:  descr = "MPEG2 Frame"; break;
case V4L2_PIX_FMT_CPIA1:descr = "GSPCA CPiA YUV"; break;
case V4L2_PIX_FMT_WNVA: descr = "WNVA"; break;
case V4L2_PIX_FMT_SN9C10X:  descr = "GSPCA SN9C10X"; break;
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index cbbb750d87d1..8431b2a540c7 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -557,6 +557,8 @@ enum v4l2_mpeg_video_mpeg4_profile {
 };
 #define V4L2_CID_MPEG_VIDEO_MPEG4_QPEL (V4L2_CID_MPEG_BASE+407)
 
+#define V4L2_CID_MPEG_VIDEO_MPEG2_FRAME_HDR (V4L2_CID_MPEG_BASE+450)
+
 /*  Control IDs for VP8 streams
  *  Although VP8 is not part of MPEG we add these controls to the MPEG class
  *  as that class is already handling other video compression standards
@@ -985,4 +987,28 @@ enum v4l2_detect_md_mode {
 #define V4L2_CID_DETECT_MD_THRESHOLD_GRID  (V4L2_CID_DETECT_CLASS_BASE + 3)
 #define V4L2_CID_DETECT_MD_REGION_GRID (V4L2_CID_DETECT_CLASS_BASE + 4)
 
+struct v4l2_ctrl_mpeg2_frame_hdr {
+   __u32 slice_len;
+   __u32 slice_pos;
+   enum { MPEG1, MPEG2 } type;
+
+   __u16 width;
+   __u16 height;
+
+   enum { PCT_I = 1, PCT_P, PCT_B, PCT_D } picture_coding_type;
+   __u8 f_code[2][2];
+
+   __u8 intra_dc_precision;
+   __u8 picture_structure;
+   __u8 top_field_first;
+   __u8 frame_pred_frame_dct;
+   __u8 concealment_motion_vectors;
+   __u8 q_scale_type;
+   __u8 intra_vlc_format;
+   __u8 alternate_scan;
+
+   __u8 backward_ref_index;
+   __u8 forward_ref_index;
+};
+
 #endif
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 

[PATCH v2 06/10] media: v4l: Add definition for Allwinner's MB32-tiled NV12 format

[Paul Kocialkowski]

This introduces support for Allwinner's MB32-tiled NV12 format, where
each plane is divided into macroblocks of 32x32 pixels. Hence, the size
of each plane has to be aligned to 32 bytes. The pixels inside each
macroblock are coded as they would be if the macroblock was a single
plane, line after line.

The MB32-tiled NV12 format is used by the video engine on Allwinner
platforms: it is the default format for decoded frames (and the only one
available in the oldest supported platforms).

Signed-off-by: Paul Kocialkowski 
---
 include/uapi/linux/videodev2.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 4b8336f7bcf0..43993a116e2b 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -669,6 +669,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_Z16  v4l2_fourcc('Z', '1', '6', ' ') /* Depth data 
16-bit */
 #define V4L2_PIX_FMT_MT21Cv4l2_fourcc('M', 'T', '2', '1') /* Mediatek 
compressed block mode  */
 #define V4L2_PIX_FMT_INZI v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel Planar 
Greyscale 10-bit and Depth 16-bit */
+#define V4L2_PIX_FMT_MB32_NV12 v4l2_fourcc('M', 'N', '1', '2') /* Allwinner 
NV12 in 32x32 macroblocks */
 
 /* 10bit raw bayer packed, 32 bytes for every 25 pixels, last LSB 6 bits 
unused */
 #define V4L2_PIX_FMT_IPU3_SBGGR10  v4l2_fourcc('i', 'p', '3', 'b') /* IPU3 
packed 10-bit BGGR bayer */
-- 
2.16.3

[PATCH v2 09/10] ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes

[Paul Kocialkowski]

This adds nodes for the Video Engine and the associated reserved memory
for the Allwinner A20. Up to 96 MiB of memory are dedicated to the VPU.

The VPU can only map the first 256 MiB of DRAM, so the reserved memory
pool has to be located in that area. Following Allwinner's decision in
downstream software, the last 96 MiB of the first 256 MiB of RAM are
reserved for this purpose.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index bd0cd3204273..cb6d82065dcf 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -163,6 +163,20 @@
reg = <0x4000 0x8000>;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+   ve_memory: cma@4a00 {
+   compatible = "shared-dma-pool";
+   reg = <0x4a00 0x600>;
+   no-map;
+   linux,cma-default;
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -451,6 +465,23 @@
};
};
 
+   ve: video-engine@1c0e000 {
+   compatible = "allwinner,sun4i-a10-video-engine";
+   reg = <0x01c0e000 0x1000>;
+   memory-region = <_memory>;
+
+   clocks = < CLK_AHB_VE>, < CLK_VE>,
+< CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+
+   assigned-clocks = < CLK_VE>;
+   assigned-clock-rates = <32000>;
+
+   resets = < RST_VE>;
+
+   interrupts = ;
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.16.3

[PATCH v2 10/10] ARM: dts: sun8i-a33: Add Video Engine and reserved memory nodes

[Paul Kocialkowski]

This adds nodes for the Video Engine and the associated reserved memory
for the Allwinner A33. Up to 96 MiB of memory are dedicated to the VPU.

The VPU can only map the first 256 MiB of DRAM, so the reserved memory
pool has to be located in that area. Following Allwinner's decision in
downstream software, the last 96 MiB of the first 256 MiB of RAM are
reserved for this purpose.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-a33.dtsi | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index a21f2ed07a52..308b532aee1d 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -181,6 +181,20 @@
reg = <0x4000 0x8000>;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+   ve_memory: cma@4a00 {
+   compatible = "shared-dma-pool";
+   reg = <0x4a00 0x600>;
+   no-map;
+   linux,cma-default;
+   };
+   };
+
sound: sound {
compatible = "simple-audio-card";
simple-audio-card,name = "sun8i-a33-audio";
@@ -204,6 +218,11 @@
};
 
soc@1c0 {
+   syscon: system-controller@01c0 {
+   compatible = "allwinner,sun8i-a33-syscon", "syscon";
+   reg = <0x01c0 0x1000>;
+   };
+
tcon0: lcd-controller@1c0c000 {
compatible = "allwinner,sun8i-a33-tcon";
reg = <0x01c0c000 0x1000>;
@@ -240,6 +259,25 @@
};
};
 
+   ve: video-engine@01c0e000 {
+   compatible = "allwinner,sun4i-a10-video-engine";
+   memory-region = <_memory>;
+   syscon = <>;
+
+   clocks = < CLK_BUS_VE>, < CLK_VE>,
+< CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+
+   assigned-clocks = < CLK_VE>;
+   assigned-clock-rates = <32000>;
+
+   resets = < RST_BUS_VE>;
+
+   interrupts = ;
+
+   reg = <0x01c0e000 0x1000>;
+   };
+
crypto: crypto-engine@1c15000 {
compatible = "allwinner,sun4i-a10-crypto";
reg = <0x01c15000 0x1000>;
-- 
2.16.3

[PATCH v2 07/10] media: platform: Add Sunxi-Cedrus VPU decoder driver

[Paul Kocialkowski]

This introduces the Sunxi-Cedrus VPU driver that supports the VPU found
in Allwinner SoCs, also known as Video Engine. It is implemented through
a v4l2 m2m decoder device and a media device (used for media requests).
So far, it only supports MPEG2 decoding.

Since this VPU is stateless, synchronization with media requests is
required in order to ensure consistency between frame headers that
contain metadata about the frame to process and the raw slice data that
is used to generate the frame.

This driver was made possible thanks to the long-standing effort
carried out by the linux-sunxi community in the interest of reverse
engineering, documenting and implementing support for Allwinner VPU.

Signed-off-by: Florent Revest 
Signed-off-by: Paul Kocialkowski 
---
 drivers/media/platform/Kconfig |  15 +
 drivers/media/platform/Makefile|   1 +
 drivers/media/platform/sunxi/cedrus/Makefile   |   4 +
 drivers/media/platform/sunxi/cedrus/sunxi_cedrus.c | 292 
 .../platform/sunxi/cedrus/sunxi_cedrus_common.h| 105 +
 .../media/platform/sunxi/cedrus/sunxi_cedrus_dec.c | 228 ++
 .../media/platform/sunxi/cedrus/sunxi_cedrus_dec.h |  36 ++
 .../media/platform/sunxi/cedrus/sunxi_cedrus_hw.c  | 201 +
 .../media/platform/sunxi/cedrus/sunxi_cedrus_hw.h  |  29 ++
 .../platform/sunxi/cedrus/sunxi_cedrus_mpeg2.c | 157 +++
 .../platform/sunxi/cedrus/sunxi_cedrus_mpeg2.h |  33 ++
 .../platform/sunxi/cedrus/sunxi_cedrus_regs.h  | 172 +++
 .../platform/sunxi/cedrus/sunxi_cedrus_video.c | 497 +
 .../platform/sunxi/cedrus/sunxi_cedrus_video.h |  31 ++
 14 files changed, 1801 insertions(+)
 create mode 100644 drivers/media/platform/sunxi/cedrus/Makefile
 create mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus.c
 create mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus_common.h
 create mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus_dec.c
 create mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus_dec.h
 create mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus_hw.c
 create mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus_hw.h
 create mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus_mpeg2.c
 create mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus_mpeg2.h
 create mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus_regs.h
 create mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus_video.c
 create mode 100644 drivers/media/platform/sunxi/cedrus/sunxi_cedrus_video.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 614fbef08ddc..77d89e84ed3b 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -488,6 +488,21 @@ config VIDEO_TI_VPE
  Support for the TI VPE(Video Processing Engine) block
  found on DRA7XX SoC.
 
+config VIDEO_SUNXI_CEDRUS
+   tristate "Sunxi-Cedrus VPU driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on ARCH_SUNXI
+   depends on HAS_DMA
+   select VIDEOBUF2_DMA_CONTIG
+   select MEDIA_REQUEST_API
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ Support for the VPU found in Allwinner SoCs, also known as the Cedar
+ video engine.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sunxi-cedrus.
+
 config VIDEO_TI_VPE_DEBUG
bool "VPE debug messages"
depends on VIDEO_TI_VPE
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 7f3080437be6..a2be170f6dff 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_VIDEO_ROCKCHIP_RGA)  += rockchip/rga/
 obj-y  += omap/
 
 obj-$(CONFIG_VIDEO_AM437X_VPFE)+= am437x/
+obj-$(CONFIG_VIDEO_SUNXI_CEDRUS)   += sunxi/cedrus/
 
 obj-$(CONFIG_VIDEO_XILINX) += xilinx/
 
diff --git a/drivers/media/platform/sunxi/cedrus/Makefile 
b/drivers/media/platform/sunxi/cedrus/Makefile
new file mode 100644
index ..98f30df626a9
--- /dev/null
+++ b/drivers/media/platform/sunxi/cedrus/Makefile
@@ -0,0 +1,4 @@
+obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi-cedrus.o
+
+sunxi-cedrus-y = sunxi_cedrus.o sunxi_cedrus_video.o sunxi_cedrus_hw.o \
+sunxi_cedrus_dec.o sunxi_cedrus_mpeg2.o
diff --git a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus.c 
b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus.c
new file mode 100644
index ..364799c00703
--- /dev/null
+++ b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus.c
@@ -0,0 +1,292 @@
+/*
+ * Sunxi-Cedrus VPU driver
+ *
+ * Copyright (C) 2018 Paul Kocialkowski 
+ * Copyright (C) 2016 Florent Revest 
+ *
+ * Based on the vim2m driver, that 

[PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

[Paul Kocialkowski]

This adds a device-tree binding document that specifies the properties
used by the Sunxi-Cedurs VPU driver, as well as examples.

Signed-off-by: Paul Kocialkowski 
---
 .../devicetree/bindings/media/sunxi-cedrus.txt | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sunxi-cedrus.txt

diff --git a/Documentation/devicetree/bindings/media/sunxi-cedrus.txt 
b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
new file mode 100644
index ..71ad3f9c3352
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
@@ -0,0 +1,50 @@
+Device-tree bindings for the VPU found in Allwinner SoCs, referred to as the
+Video Engine (VE) in Allwinner literature.
+
+The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped starting
+from the DRAM base. This requires specific memory allocation and handling.
+
+Required properties:
+- compatible   : "allwinner,sun4i-a10-video-engine";
+- memory-region : DMA pool for buffers allocation;
+- clocks   : list of clock specifiers, corresponding to entries in
+  the clock-names property;
+- clock-names  : should contain "ahb", "mod" and "ram" entries;
+- assigned-clocks   : list of clocks assigned to the VE;
+- assigned-clocks-rates : list of clock rates for the clocks assigned to the 
VE;
+- resets   : phandle for reset;
+- interrupts   : should contain VE interrupt number;
+- reg  : should contain register base and length of VE.
+
+Example:
+
+reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
+   ve_memory: cma@4a00 {
+   compatible = "shared-dma-pool";
+   reg = <0x4a00 0x600>;
+   no-map;
+   linux,cma-default;
+   };
+};
+
+video-engine@1c0e000 {
+   compatible = "allwinner,sun4i-a10-video-engine";
+   reg = <0x01c0e000 0x1000>;
+   memory-region = <_memory>;
+
+   clocks = < CLK_AHB_VE>, < CLK_VE>,
+< CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+
+   assigned-clocks = < CLK_VE>;
+   assigned-clock-rates = <32000>;
+
+   resets = < RST_VE>;
+
+   interrupts = ;
+};
-- 
2.16.3

[PATCH v2 04/10] media: vim2m: Implement media request complete op to schedule m2m run

[Paul Kocialkowski]

This adds an implementation of the media request complete operation for
the vim2m driver, that ensures that the driver will try to schedule a
m2m run whenever a request was completed. Without this operation, no m2m
device run will be scheduled in many scenarios.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/platform/vim2m.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index 2dcf0ea85705..08c4c5566614 100644
--- a/drivers/media/platform/vim2m.c
+++ b/drivers/media/platform/vim2m.c
@@ -453,6 +453,17 @@ static void device_isr(struct timer_list *t)
schedule_work(_dev->work_run);
 }
 
+static void request_complete(struct media_request *req)
+{
+   struct vim2m_ctx *curr_ctx;
+
+   curr_ctx = (struct vim2m_ctx *) vb2_core_request_find_buffer_priv(req);
+   if (curr_ctx == NULL)
+   return;
+
+   v4l2_m2m_try_schedule(curr_ctx->fh.m2m_ctx);
+}
+
 /*
  * video ioctls
  */
@@ -1025,6 +1036,7 @@ static const struct v4l2_m2m_ops m2m_ops = {
 
 static const struct media_device_ops m2m_media_ops = {
.req_queue = vb2_request_queue,
+   .req_complete = request_complete,
 };
 
 static int vim2m_probe(struct platform_device *pdev)
-- 
2.16.3

[PATCH v2 01/10] media: v4l2-ctrls: Add missing v4l2 ctrl unlock

[Paul Kocialkowski]

This adds a missing v4l2_ctrl_unlock call that is required to avoid
deadlocks.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index f67e9f5531fa..ba05a8b9a095 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -3614,10 +3614,12 @@ void v4l2_ctrl_request_complete(struct media_request 
*req,
continue;
 
v4l2_ctrl_lock(ctrl);
+
if (ref->req)
ptr_to_ptr(ctrl, ref->req->p_req, ref->p_req);
else
ptr_to_ptr(ctrl, ctrl->p_cur, ref->p_req);
+
v4l2_ctrl_unlock(ctrl);
}
 
@@ -3677,8 +3679,11 @@ void v4l2_ctrl_request_setup(struct media_request *req,
}
}
}
-   if (!have_new_data)
+
+   if (!have_new_data) {
+   v4l2_ctrl_unlock(master);
continue;
+   }
 
for (i = 0; i < master->ncontrols; i++) {
if (master->cluster[i]) {
-- 
2.16.3

[PATCH v2 02/10] media-request: Add a request complete operation to allow m2m scheduling

[Paul Kocialkowski]

When using the request API in the context of a m2m driver, the
operations that come with a m2m run scheduling call in their
(m2m-specific) ioctl handler are delayed until the request is queued
(for instance, this includes queuing buffers and streamon).

Thus, the m2m run scheduling calls are not called in due time since the
request AP's internal plumbing will (rightfully) use the relevant core
functions directly instead of the ioctl handler.

This ends up in a situation where nothing happens if there is no
run-scheduling ioctl called after queuing the request.

In order to circumvent the issue, a new media operation is introduced,
called at the time of handling the media request queue ioctl. It gives
m2m drivers a chance to schedule a m2m device run at that time.

The existing req_queue operation cannot be used for this purpose, since
it is called with the request queue mutex held, that is eventually needed
in the device_run call to apply relevant controls.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/media-request.c | 3 +++
 include/media/media-device.h  | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
index 415f7e31019d..28ac5ccfe6a2 100644
--- a/drivers/media/media-request.c
+++ b/drivers/media/media-request.c
@@ -157,6 +157,9 @@ static long media_request_ioctl_queue(struct media_request 
*req)
media_request_get(req);
}
 
+   if (mdev->ops->req_complete)
+   mdev->ops->req_complete(req);
+
return ret;
 }
 
diff --git a/include/media/media-device.h b/include/media/media-device.h
index 07e323c57202..c7dcf2079cc9 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -55,6 +55,7 @@ struct media_entity_notify {
  * @req_alloc: Allocate a request
  * @req_free: Free a request
  * @req_queue: Queue a request
+ * @req_complete: Complete a request
  */
 struct media_device_ops {
int (*link_notify)(struct media_link *link, u32 flags,
@@ -62,6 +63,7 @@ struct media_device_ops {
struct media_request *(*req_alloc)(struct media_device *mdev);
void (*req_free)(struct media_request *req);
int (*req_queue)(struct media_request *req);
+   void (*req_complete)(struct media_request *req);
 };
 
 /**
-- 
2.16.3

[PATCH v2 00/10] Sunxi-Cedrus driver for the Allwinner Video Engine, using media requests

[Paul Kocialkowski]

This presents a second iteration of the updated Sunxi-Cedrus driver,
that supports the Video Engine found in most Allwinner SoCs, starting
with the A10. It was tested on both the A20 and the A33.

The initial version of this driver[0] was originally written and
submitted by Florent Revest using a previous version of the request API
that is necessary to provide coherency between controls and the buffers
they apply to.

The driver was adapted to use the latest version of the media request
API[1], as submitted by Hand Verkuil. Media request API support is a
hard requirement for the Sunxi-Cedrus driver.

This series also contains fixes for issues encountered with the current
version of the request API. If accepted, these should eventually be
squashed into the request API series.

The driver itself currently only supports MPEG2 and more codecs will be
added to the driver eventually. The output frames provided by the
Video Engine are in a multi-planar 32x32-tiled YUV format, with a plane
for luminance (Y) and a plane for chrominance (UV). A specific format is
introduced in the V4L2 API to describe it.

This implementation is based on the significant work that was conducted
by various members of the linux-sunxi community for understanding and
documenting the Video Engine's innards.

Changes since v1:
* use the latest version of the request API for Hans Verkuil;
* added media controller support and dependency
* renamed v4l2 format to the more explicit V4L2_PIX_FMT_MB32_NV12;
* reworked bindings documentation;
* moved driver to drivers/media/platforms/sunxi/cedrus to pair with
  incoming CSI support ;
* added a workqueue and lists to schedule buffer completion, since it
  cannot be done in interrupt context;
* split mpeg2 support into a setup and a trigger function to avoid race
  condition;
* split video-related ops to a dedicated sunxi_cedrus_video file;
* cleaned up the included headers for each file;
* used device PFN offset instead of subtracting PHYS_BASE;
* used reset_control_reset instead of assert+deassert;
* put the device in reset when removing driver;
* changed dt bindings to use the last 96 Mib of the first 256 MiB of
  DRAM;
* made it clear in the mpeg frame header structure that forward and
  backward indexes are used as reference frames for motion vectors;
* lots of small cosmetic and consistency changes, including naming
  harmonization and headers text rework.

Remaining tasks:
* using the dedicated SRAM controller driver;
* cleaning up registers description and documenting the fields used;
* removing the assigned-clocks property and setting the clock rate
  in the driver directly;
* testing on more platforms.

Cheers!

Paul Kocialkowski (10):
  media: v4l2-ctrls: Add missing v4l2 ctrl unlock
  media-request: Add a request complete operation to allow m2m
scheduling
  videobuf2-core: Add helper to get buffer private data from media
request
  media: vim2m: Implement media request complete op to schedule m2m run
  media: v4l: Add definitions for MPEG2 frame format and header metadata
  media: v4l: Add definition for Allwinner's MB32-tiled NV12 format
  media: platform: Add Sunxi-Cedrus VPU decoder driver
  dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver
  ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes
  ARM: dts: sun8i-a33: Add Video Engine and reserved memory nodes

 .../devicetree/bindings/media/sunxi-cedrus.txt |  50 +++
 arch/arm/boot/dts/sun7i-a20.dtsi   |  31 ++
 arch/arm/boot/dts/sun8i-a33.dtsi   |  38 ++
 drivers/media/common/videobuf2/videobuf2-core.c|  15 +
 drivers/media/media-request.c  |   3 +
 drivers/media/platform/Kconfig |  15 +
 drivers/media/platform/Makefile|   1 +
 drivers/media/platform/sunxi/cedrus/Makefile   |   4 +
 drivers/media/platform/sunxi/cedrus/sunxi_cedrus.c | 292 
 .../platform/sunxi/cedrus/sunxi_cedrus_common.h| 105 +
 .../media/platform/sunxi/cedrus/sunxi_cedrus_dec.c | 228 ++
 .../media/platform/sunxi/cedrus/sunxi_cedrus_dec.h |  36 ++
 .../media/platform/sunxi/cedrus/sunxi_cedrus_hw.c  | 201 +
 .../media/platform/sunxi/cedrus/sunxi_cedrus_hw.h  |  29 ++
 .../platform/sunxi/cedrus/sunxi_cedrus_mpeg2.c | 157 +++
 .../platform/sunxi/cedrus/sunxi_cedrus_mpeg2.h |  33 ++
 .../platform/sunxi/cedrus/sunxi_cedrus_regs.h  | 172 +++
 .../platform/sunxi/cedrus/sunxi_cedrus_video.c | 497 +
 .../platform/sunxi/cedrus/sunxi_cedrus_video.h |  31 ++
 drivers/media/platform/vim2m.c |  12 +
 drivers/media/v4l2-core/v4l2-ctrls.c   |  17 +-
 drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
 include/media/media-device.h   |   2 +
 include/media/videobuf2-core.h |   1 +
 include/uapi/linux/v4l2-controls.h |  26 ++
 include/uapi/linux/videodev2.h 

[PATCH v2 03/10] videobuf2-core: Add helper to get buffer private data from media request

[Paul Kocialkowski]

When calling media operation driver callbacks related to media requests,
only a pointer to the request itself is provided, which is insufficient
to retrieve the driver's context. Since the driver context is usually
set as vb2 queue private data and given that the core can determine
which objects attached to the request are buffers, it is possible to
extract the associated private data for the first buffer found.

This is required in order to access the current m2m context from m2m
drivers' private data in the context of media request operation
callbacks. More specifically, this allows scheduling m2m device runs
from the newly-introduced request complete operation.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/common/videobuf2/videobuf2-core.c | 15 +++
 include/media/videobuf2-core.h  |  1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index 13c9d9e243dd..6fa46bfc620f 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1351,6 +1351,21 @@ bool vb2_core_request_has_buffers(struct media_request 
*req)
 }
 EXPORT_SYMBOL_GPL(vb2_core_request_has_buffers);
 
+void *vb2_core_request_find_buffer_priv(struct media_request *req)
+{
+   struct media_request_object *obj;
+   struct vb2_buffer *vb;
+
+   obj = media_request_object_find(req, _core_req_ops, NULL);
+   if (!obj)
+   return NULL;
+
+   vb = container_of(obj, struct vb2_buffer, req_obj);
+
+   return vb2_get_drv_priv(vb->vb2_queue);
+}
+EXPORT_SYMBOL_GPL(vb2_core_request_find_buffer_priv);
+
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb,
 struct media_request *req)
 {
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 032bd1bec555..65c0cf6afb55 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -1153,4 +1153,5 @@ int vb2_verify_memory_type(struct vb2_queue *q,
enum vb2_memory memory, unsigned int type);
 
 bool vb2_core_request_has_buffers(struct media_request *req);
+void *vb2_core_request_find_buffer_priv(struct media_request *req);
 #endif /* _MEDIA_VIDEOBUF2_CORE_H */
-- 
2.16.3

Re: [PATCH RESEND 6/6] media: v4l2-compat-ioctl32: simplify casts

[Mauro Carvalho Chehab]

Em Thu, 19 Apr 2018 13:37:52 +0200
Hans Verkuil  escreveu:

> On 04/19/18 13:15, Mauro Carvalho Chehab wrote:
> > Making the cast right for get_user/put_user is not trivial, as
> > it needs to ensure that the types are the correct ones.
> > 
> > Improve it by using macros.
> > 
> > Tested with vivid with:
> > $ sudo modprobe vivid no_error_inj=1
> > $ v4l2-compliance-32bits -a -s10 >32bits && v4l2-compliance-64bits -a 
> > -s10 > 64bits && diff -U0 32bits 64bits
> > --- 32bits  2018-04-17 11:18:29.141240772 -0300
> > +++ 64bits  2018-04-17 11:18:40.635282341 -0300
> > @@ -1 +1 @@
> > -v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 32 
> > bits
> > +v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 64 
> > bits
> > 
> > Using the latest version of v4l-utils with this patch applied:
> > https://patchwork.linuxtv.org/patch/48746/
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 40 
> > ++-
> >  1 file changed, 27 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> > b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > index 8c05dd9660d3..d2f0268427c2 100644
> > --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > @@ -30,6 +30,24 @@
> > get_user(__assign_tmp, from) || put_user(__assign_tmp, to); \
> >  })
> >  
> > +#define get_user_cast(__x, __ptr)  \
> > +({ \
> > +   get_user(__x, (typeof(*__ptr) __user *)(__ptr));\
> > +})
> > +
> > +#define put_user_force(__x, __ptr) \
> > +({ \
> > +   put_user((typeof(*__x) __force *)(__x), __ptr); \
> > +})
> > +
> > +#define assign_in_user_cast(to, from)  
> > \
> > +({ \
> > +   typeof(*from) __assign_tmp; \
> > +   \
> > +   get_user_cast(__assign_tmp, from) || put_user(__assign_tmp, to);\
> > +})  
> 
> Please add comments for these macros. It's not trivially obvious what they
> do and why they are needed.

Ok. Would the comments below be acceptable?

I may eventually post it as a separate patch, adding documentation to some
other functions (maybe adding it to some .rst file).

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index d2f0268427c2..9530661d9b43 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -22,7 +22,18 @@
 #include 
 #include 
 
-/* Use the same argument order as copy_in_user */
+/**
+ * assign_in_user() - Copy from one __user var to another one
+ *
+ * @to: __user var where data will be stored
+ * @from: __user var were data will be retrieved.
+ *
+ * As this code very often needs to allocate userspace memory, it is easier
+ * to have a macro that will do both get_user() and put_user() at once.
+ *
+ * This function complements the macros defined at asm-generic/uaccess.h.
+ * It uses the same argument order as copy_in_user()
+ */
 #define assign_in_user(to, from)   \
 ({ \
typeof(*from) __assign_tmp; \
@@ -30,16 +41,57 @@
get_user(__assign_tmp, from) || put_user(__assign_tmp, to); \
 })
 
+/**
+ * get_user_cast() - Stores at a kernelspace local var the contents from a
+ * pointer with userspace data that is not tagged with __user.
+ *
+ * @__x: var where data will be stored
+ * @ptr: var were data will be retrieved.
+ *
+ * Sometimes, we need to declare a pointer without __user, because it
+ * comes from a pointer struct field that will be retrieved from userspace
+ * by the 64-bit native ioctl handler. This function ensures that the
+ * @ptr will be casted to __user before calling get_user(), in order to
+ * avoid warnings with static code analyzers like smatch.
+ */
 #define get_user_cast(__x, __ptr)  \
 ({ \
get_user(__x, (typeof(*__ptr) __user *)(__ptr));\
 })
 
+/**
+ * put_user_force() - Stores at the contents of a kernelspace local var
+ *   into an userspace pointer, removing any __user cast.
+ *
+ * @__x: var where data will be stored
+ * @ptr: var were data will be retrieved.
+ *
+ * As the compat32 code now handles with 32-bits and 64-bits __user
+ * structs, sometimes we 

Re: [PATCH 5/9] media: platform: Add Sunxi Cedrus decoder driver

[Paul Kocialkowski]

Hi and thanks for the review,

On Fri, 2018-03-09 at 14:57 +0100, Maxime Ripard wrote:
> On Fri, Mar 09, 2018 at 11:14:41AM +0100, Paul Kocialkowski wrote:
> > +/*
> > + * mem2mem callbacks
> > + */
> > +
> > +void job_abort(void *priv)
> > +{}
> 
> Is that still needed?

v2 contains a proper implementation of job abortion, so yes :)

> > +/*
> > + * device_run() - prepares and starts processing
> > + */
> > +void device_run(void *priv)
> > +{
> 
> This function (and the one above) should probably made static. Or at
> least if you can't, they should have a much more specific name in
> order not to conflict with anything from the core.

Agreed, will fix in v2.

> > +   /*
> > +* The VPU is only able to handle bus addresses so we have
> > to subtract
> > +* the RAM offset to the physcal addresses
> > +*/
> > +   in_buf -= PHYS_OFFSET;
> > +   out_luma   -= PHYS_OFFSET;
> > +   out_chroma -= PHYS_OFFSET;
> 
> You should take care of that by putting it in the dma_pfn_offset field
> of the struct device (at least before we come up with something
> better).
> 
> You'll then be able to use the dma_addr_t directly without modifying
> it.

Ditto.

> > +   vpu->syscon = syscon_regmap_lookup_by_phandle(vpu->dev-
> > >of_node,
> > + "syscon");
> > +   if (IS_ERR(vpu->syscon)) {
> > +   vpu->syscon = NULL;
> > +   } else {
> > +   regmap_write_bits(vpu->syscon,
> > SYSCON_SRAM_CTRL_REG0,
> > + SYSCON_SRAM_C1_MAP_VE,
> > + SYSCON_SRAM_C1_MAP_VE);
> > +   }
> 
> This should be using our SRAM controller driver (and API), see
> Documentation/devicetree/bindings/sram/sunxi-sram.txt
> include/linux/soc/sunxi/sunxi_sram.h

This will require adding support for the VE (and the A33 along the way)
in the SRAM driver, so a dedicated patch series will be sent in this
direction eventually.

> > +   ret = clk_prepare_enable(vpu->ahb_clk);
> > +   if (ret) {
> > +   dev_err(vpu->dev, "could not enable ahb clock\n");
> > +   return -EFAULT;
> > +   }
> > +   ret = clk_prepare_enable(vpu->mod_clk);
> > +   if (ret) {
> > +   clk_disable_unprepare(vpu->ahb_clk);
> > +   dev_err(vpu->dev, "could not enable mod clock\n");
> > +   return -EFAULT;
> > +   }
> > +   ret = clk_prepare_enable(vpu->ram_clk);
> > +   if (ret) {
> > +   clk_disable_unprepare(vpu->mod_clk);
> > +   clk_disable_unprepare(vpu->ahb_clk);
> > +   dev_err(vpu->dev, "could not enable ram clock\n");
> > +   return -EFAULT;
> > +   }
> 
> Ideally, this should be using runtime_pm to manage the device power
> state, and disable it when not used.
> 
> > +   reset_control_assert(vpu->rstc);
> > +   reset_control_deassert(vpu->rstc);
> 
> You can use reset_control_reset here

Will do in v2.

> > +   return 0;
> > +}
> > +
> > +void sunxi_cedrus_hw_remove(struct sunxi_cedrus_dev *vpu)
> > +{
> > +   clk_disable_unprepare(vpu->ram_clk);
> > +   clk_disable_unprepare(vpu->mod_clk);
> > +   clk_disable_unprepare(vpu->ahb_clk);
> 
> The device is not put back into reset here

Good catch!

Cheers,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part

Re: [linux-sunxi] [PATCH 5/9] media: platform: Add Sunxi Cedrus decoder driver

[Paul Kocialkowski]

Hi,

On Mon, 2018-03-12 at 17:15 +, Joonas Kylmälä wrote:
> Paul Kocialkowski:
> > diff --git a/drivers/media/platform/sunxi-cedrus/sunxi_cedrus_regs.h 
> > b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus_regs.h
> > new file mode 100644
> > index ..7384daa94737
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus_regs.h
> > @@ -0,0 +1,170 @@
> > +/*
> > + * Sunxi Cedrus codec driver
> > + *
> > + * Copyright (C) 2016 Florent Revest
> > + * Florent Revest 
> > + *
> > + * Based on Cedrus
> > + *
> > + * Copyright (c) 2013 Jens Kuske 
> > + *
> > + * This software is licensed under the terms of the GNU General
> > Public
> > + * License version 2, as published by the Free Software Foundation,
> > and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef SUNXI_CEDRUS_REGS_H
> > +#define SUNXI_CEDRUS_REGS_H
> > +
> > +/*
> > + * For more information consult http://linux-sunxi.org/VE_Register_
> > guide
> > + */
> > +
> > +/* Special registers values */
> > +
> > +/* VE_CTRL:
> > + * The first 3 bits indicate the engine (0 for MPEG, 1 for H264, b
> > for AVC...)
> > + * The 16th and 17th bits indicate the memory type (3 for DDR3 32
> > bits)
> > + * The 20th bit is unknown but needed
> > + */
> > +#define VE_CTRL_MPEG   0x13
> > +#define VE_CTRL_H264   0x130001
> > +#define VE_CTRL_AVC0x13000b
> > +#define VE_CTRL_REINIT 0x130007
> > +
> > +/* VE_MPEG_CTRL:
> > + * The bit 3 (0x8) is used to enable IRQs
> > + * The other bits are unknown but needed
> > + */
> > +#define VE_MPEG_CTRL_MPEG2 0x81b8
> > +#define VE_MPEG_CTRL_MPEG4 (0x80084118 | BIT(7))
> > +#define VE_MPEG_CTRL_MPEG4_P   (VE_MPEG_CTRL_MPEG4 | BIT(12))
> > +
> > +/* VE_MPEG_VLD_ADDR:
> > + * The bits 27 to 4 are used for the address
> > + * The bits 31 to 28 (0x7) are used to select the MPEG or JPEG
> > engine
> > + */
> > +#define VE_MPEG_VLD_ADDR_VAL(x)((x & 0x0ff0) | (x >>
> > 28) | (0x7 << 28))
> > +
> > +/* VE_MPEG_TRIGGER:
> > + * The first three bits are used to trigger the engine
> > + * The bits 24 to 26 are used to select the input format (1 for
> > MPEG1, 2 for 
> 
> Trailing whitespace.

Will fix in v2, thanks!

Cheers,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part

Re: [linux-sunxi] [PATCH 5/9] media: platform: Add Sunxi Cedrus decoder driver

[Paul Kocialkowski]

Hi,

On Mon, 2018-03-12 at 20:29 +, Joonas Kylmälä wrote:
> Paul Kocialkowski:
> > diff --git a/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
> > b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
> > new file mode 100644
> > index ..88624035e0e3
> > --- /dev/null
> > +++ b/drivers/media/platform/sunxi-cedrus/sunxi_cedrus.c
> > @@ -0,0 +1,313 @@
> > +/*
> > + * Sunxi Cedrus codec driver
> > + *
> > + * Copyright (C) 2016 Florent Revest
> > + * Florent Revest 
> > + *
> > + * Based on vim2m
> > + *
> > + * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
> > + * Pawel Osciak, 
> > + * Marek Szyprowski, 
> > + *
> > + * This software is licensed under the terms of the GNU General
> > Public
> > + * License version 2, as published by the Free Software Foundation,
> > and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include "sunxi_cedrus_common.h"
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> I think that the definitions
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> are not used directly in the sunxi_cedrus.c file. Therefore they
> should be removed.

Thanks for the review, this will be done in v2.

Cheers,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part

Re: [PATCH 6/9] sunxi-cedrus: Add device tree binding document

[Paul Kocialkowski]

Hi,

On Sun, 2018-03-18 at 07:48 -0500, Rob Herring wrote:
> On Fri, Mar 09, 2018 at 11:14:42AM +0100, Paul Kocialkowski wrote:
> > From: Florent Revest 
> 
> "device tree binding document" can all be summarized with the subject 
> prefix "dt-bindings: media: ".

Will do in v2, thanks.

> Also, email should be updated to @bootlin.com?

I will keep the address @free-electrons.com (since there is no matching
@bootlin.com address). Although that address was broken at the time of
sending v1, it should be a valid redirect nowadays.

> > 
> > Device Tree bindings for the Allwinner's video engine
> > 
> > Signed-off-by: Florent Revest 
> > ---
> >  .../devicetree/bindings/media/sunxi-cedrus.txt | 44
> > ++
> >  1 file changed, 44 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/sunxi-
> > cedrus.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/sunxi-
> > cedrus.txt b/Documentation/devicetree/bindings/media/sunxi-
> > cedrus.txt
> > new file mode 100644
> > index ..138581113c49
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt
> > @@ -0,0 +1,44 @@
> > +Device-Tree bindings for SUNXI video engine found in sunXi SoC
> > family
> > +
> > +Required properties:
> > +- compatible   : "allwinner,sun4i-a10-video-engine";
> > +- memory-region : DMA pool for buffers allocation;
> 
> Why do you need this linkage? Many drivers use CMA and don't need
> this.

The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped
starting from the DRAM base. This requires specific memory allocation
and handling. I'll add the information in v2.

> > +- clocks   : list of clock specifiers, corresponding to
> > + entries in clock-names property;
> > +- clock-names  : should contain "ahb", "mod" and "ram"
> > entries;
> > +- resets   : phandle for reset;
> > +- interrupts   : should contain VE interrupt number;
> > +- reg  : should contain register base and length
> > of VE.
> > +
> > +Example:
> > +
> > +reserved-memory {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges;
> > +
> > +   ve_reserved: cma {
> > +   compatible = "shared-dma-pool";
> > +   reg = <0x43d0 0x900>;
> > +   no-map;
> > +   linux,cma-default;
> > +   };
> > +};
> > +
> > +video-engine {
> > +   compatible = "allwinner,sun4i-a10-video-engine";
> > +   memory-region = <_reserved>;
> > +
> > +   clocks = <_gates 32>, < CLK_VE>,
> > +<_gates 0>;
> > +   clock-names = "ahb", "mod", "ram";
> > +
> > +   assigned-clocks = < CLK_VE>;
> > +   assigned-clock-rates = <32000>;
> 
> Not documented.

Will do in v2.

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part

[PATCH 00/61] tree-wide: simplify getting .drvdata

[Wolfram Sang]

I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:

-   struct platform_device *pdev = to_platform_device(dev);
-   struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+   struct ep93xx_keypad *keypad = dev_get_drvdata(dev);

I send this out as one patch per directory per subsystem. I think they should
be applied individually. If you prefer a broken out series per subsystem, I can
provide this as well. Just mail me.

A branch (tested by buildbot; only with all commits squashed into one commit
before) can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
coccinelle/get_drvdata

Open for other comments, suggestions, too, of course.

Here is the cocci-script I created (after  iterations by manually checking
samples):

@@
struct device* d;
identifier pdev;
expression *ptr;
@@
(
-   struct platform_device *pdev = to_platform_device(d);
|
-   struct platform_device *pdev;
...
-   pdev = to_platform_device(d);
)
<... when != pdev
-   >dev
+   d
...>

ptr =
-   platform_get_drvdata(pdev)
+   dev_get_drvdata(d)

<... when != pdev
-   >dev
+   d
...>

Kind regards,

   Wolfram


Wolfram Sang (61):
  ARM: plat-samsung: simplify getting .drvdata
  ata: simplify getting .drvdata
  auxdisplay: simplify getting .drvdata
  bus: simplify getting .drvdata
  clk: samsung: simplify getting .drvdata
  crypto: simplify getting .drvdata
  dma: simplify getting .drvdata
  dmaengine: dw: simplify getting .drvdata
  dmaengine: qcom: simplify getting .drvdata
  gpio: simplify getting .drvdata
  gpu: drm: msm: simplify getting .drvdata
  gpu: drm: msm: adreno: simplify getting .drvdata
  gpu: drm: msm: disp: mdp5: simplify getting .drvdata
  gpu: drm: msm: dsi: simplify getting .drvdata
  gpu: drm: omapdrm: displays: simplify getting .drvdata
  gpu: drm: vc4: simplify getting .drvdata
  hid: simplify getting .drvdata
  iio: common: cros_ec_sensors: simplify getting .drvdata
  iio: common: hid-sensors: simplify getting .drvdata
  input: keyboard: simplify getting .drvdata
  input: misc: simplify getting .drvdata
  input: mouse: simplify getting .drvdata
  input: touchscreen: simplify getting .drvdata
  iommu: simplify getting .drvdata
  media: platform: am437x: simplify getting .drvdata
  media: platform: exynos4-is: simplify getting .drvdata
  media: platform: s5p-mfc: simplify getting .drvdata
  mmc: host: simplify getting .drvdata
  mtd: devices: simplify getting .drvdata
  mtd: nand: onenand: simplify getting .drvdata
  net: dsa: simplify getting .drvdata
  net: ethernet: cadence: simplify getting .drvdata
  net: ethernet: davicom: simplify getting .drvdata
  net: ethernet: smsc: simplify getting .drvdata
  net: ethernet: ti: simplify getting .drvdata
  net: ethernet: wiznet: simplify getting .drvdata
  perf: simplify getting .drvdata
  pinctrl: simplify getting .drvdata
  pinctrl: intel: simplify getting .drvdata
  platform: x86: simplify getting .drvdata
  power: supply: simplify getting .drvdata
  ptp: simplify getting .drvdata
  pwm: simplify getting .drvdata
  rtc: simplify getting .drvdata
  slimbus: simplify getting .drvdata
  spi: simplify getting .drvdata
  staging: greybus: simplify getting .drvdata
  staging: iio: adc: simplify getting .drvdata
  staging: nvec: simplify getting .drvdata
  thermal: simplify getting .drvdata
  thermal: int340x_thermal: simplify getting .drvdata
  thermal: st: simplify getting .drvdata
  tty: serial: simplify getting .drvdata
  uio: simplify getting .drvdata
  usb: mtu3: simplify getting .drvdata
  usb: phy: simplify getting .drvdata
  video: fbdev: simplify getting .drvdata
  video: fbdev: omap2: omapfb: displays: simplify getting .drvdata
  watchdog: simplify getting .drvdata
  net: dsa: simplify getting .drvdata
  ASoC: atmel: simplify getting .drvdata

 arch/arm/plat-samsung/adc.c|  3 +-
 drivers/ata/pata_samsung_cf.c  |  8 ++---
 drivers/auxdisplay/arm-charlcd.c   |  6 ++--
 drivers/bus/brcmstb_gisb.c | 12 +++
 drivers/clk/samsung/clk-s3c2410-dclk.c |  6 ++--
 drivers/crypto/exynos-rng.c|  6 ++--
 drivers/crypto/picoxcell_crypto.c  |  6 ++--
 drivers/dma/at_hdmac.c |  9 ++---
 drivers/dma/at_xdmac.c |  9 ++---
 drivers/dma/dw/platform.c  |  6 ++--
 drivers/dma/fsldma.c   |  6 ++--
 drivers/dma/idma64.c   |  6 ++--
 drivers/dma/qcom/hidma.c   |  3 +-
 drivers/dma/qcom/hidma_mgmt_sys.c  |  6 ++--
 drivers/dma/ste_dma40.c| 12 +++
 drivers/dma/txx9dmac.c |  8 ++---
 

[PATCH 25/61] media: platform: am437x: simplify getting .drvdata

[Wolfram Sang]

We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.

Signed-off-by: Wolfram Sang 
---

Build tested only. buildbot is happy. Please apply individually.

 drivers/media/platform/am437x/am437x-vpfe.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/am437x/am437x-vpfe.c 
b/drivers/media/platform/am437x/am437x-vpfe.c
index 601ae6487617..58ebc2220d0e 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -2662,8 +2662,7 @@ static void vpfe_save_context(struct vpfe_ccdc *ccdc)
 
 static int vpfe_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct vpfe_device *vpfe = platform_get_drvdata(pdev);
+   struct vpfe_device *vpfe = dev_get_drvdata(dev);
struct vpfe_ccdc *ccdc = >ccdc;
 
/* if streaming has not started we don't care */
@@ -2720,8 +2719,7 @@ static void vpfe_restore_context(struct vpfe_ccdc *ccdc)
 
 static int vpfe_resume(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct vpfe_device *vpfe = platform_get_drvdata(pdev);
+   struct vpfe_device *vpfe = dev_get_drvdata(dev);
struct vpfe_ccdc *ccdc = >ccdc;
 
/* if streaming has not started we don't care */
-- 
2.11.0

[PATCH 26/61] media: platform: exynos4-is: simplify getting .drvdata

[Wolfram Sang]

We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.

Signed-off-by: Wolfram Sang 
---

Build tested only. buildbot is happy. Please apply individually.

 drivers/media/platform/exynos4-is/media-dev.c | 6 ++
 drivers/media/platform/exynos4-is/mipi-csis.c | 6 ++
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
b/drivers/media/platform/exynos4-is/media-dev.c
index 78b48a1fa26c..deb499f76412 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -1201,8 +1201,7 @@ static const struct media_device_ops fimc_md_ops = {
 static ssize_t fimc_md_sysfs_show(struct device *dev,
  struct device_attribute *attr, char *buf)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct fimc_md *fmd = platform_get_drvdata(pdev);
+   struct fimc_md *fmd = dev_get_drvdata(dev);
 
if (fmd->user_subdev_api)
return strlcpy(buf, "Sub-device API (sub-dev)\n", PAGE_SIZE);
@@ -1214,8 +1213,7 @@ static ssize_t fimc_md_sysfs_store(struct device *dev,
   struct device_attribute *attr,
   const char *buf, size_t count)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct fimc_md *fmd = platform_get_drvdata(pdev);
+   struct fimc_md *fmd = dev_get_drvdata(dev);
bool subdev_api;
int i;
 
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c 
b/drivers/media/platform/exynos4-is/mipi-csis.c
index cba46a656338..b4e28a299e26 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -891,8 +891,7 @@ static int s5pcsis_probe(struct platform_device *pdev)
 
 static int s5pcsis_pm_suspend(struct device *dev, bool runtime)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct v4l2_subdev *sd = platform_get_drvdata(pdev);
+   struct v4l2_subdev *sd = dev_get_drvdata(dev);
struct csis_state *state = sd_to_csis_state(sd);
int ret = 0;
 
@@ -921,8 +920,7 @@ static int s5pcsis_pm_suspend(struct device *dev, bool 
runtime)
 
 static int s5pcsis_pm_resume(struct device *dev, bool runtime)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct v4l2_subdev *sd = platform_get_drvdata(pdev);
+   struct v4l2_subdev *sd = dev_get_drvdata(dev);
struct csis_state *state = sd_to_csis_state(sd);
int ret = 0;
 
-- 
2.11.0

Re: [PATCH 07/15] media: staging/imx: add 10 bit bayer support

[Rui Miguel Silva]

Hi Philip,
Thanks for the review.

On Thu 19 Apr 2018 at 13:38, Philipp Zabel wrote:

On Thu, 2018-04-19 at 11:18 +0100, Rui Miguel Silva wrote:
Some sensors can only output 10 bit bayer formats, like the 
OV2680. Add support

for that in imx-media.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/imx-media-utils.c | 24 
 +

 1 file changed, 24 insertions(+)

diff --git a/drivers/staging/media/imx/imx-media-utils.c 
b/drivers/staging/media/imx/imx-media-utils.c

index fab98fc0d6a0..99527daba29a 100644
--- a/drivers/staging/media/imx/imx-media-utils.c
+++ b/drivers/staging/media/imx/imx-media-utils.c
@@ -118,6 +118,30 @@ static const struct imx_media_pixfmt 
rgb_formats[] = {

.cs = IPUV3_COLORSPACE_RGB,
.bpp= 8,
.bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SBGGR10,
+   .codes  = {MEDIA_BUS_FMT_SBGGR10_1X10},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SGBRG10,
+   .codes  = {MEDIA_BUS_FMT_SGBRG10_1X10},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SGRBG10,
+   .codes  = {MEDIA_BUS_FMT_SGRBG10_1X10},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SRGGB10,
+   .codes  = {MEDIA_BUS_FMT_SRGGB10_1X10},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,


This will break 10-bit bayer formats on i.MX6, which currently 
stores
them in memory expanded to 16-bit, as listed in the entries 
below:


Oh, I see... i.MX7 also store it expanded, I will change my code 
to use

the format array as it is for i.MX6.

Thanks,
---
Cheers,
Rui

[PATCH 27/61] media: platform: s5p-mfc: simplify getting .drvdata

[Wolfram Sang]

We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.

Signed-off-by: Wolfram Sang 
---

Build tested only. buildbot is happy. Please apply individually.

 drivers/media/platform/s5p-mfc/s5p_mfc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index a80251ed3143..9ca707cb2a42 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1449,8 +1449,7 @@ static int s5p_mfc_remove(struct platform_device *pdev)
 
 static int s5p_mfc_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct s5p_mfc_dev *m_dev = platform_get_drvdata(pdev);
+   struct s5p_mfc_dev *m_dev = dev_get_drvdata(dev);
int ret;
 
if (m_dev->num_inst == 0)
@@ -1484,8 +1483,7 @@ static int s5p_mfc_suspend(struct device *dev)
 
 static int s5p_mfc_resume(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct s5p_mfc_dev *m_dev = platform_get_drvdata(pdev);
+   struct s5p_mfc_dev *m_dev = dev_get_drvdata(dev);
 
if (m_dev->num_inst == 0)
return 0;
-- 
2.11.0

Re: [PATCH 05/15] media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7

[Rui Miguel Silva]

Hi Dan,
On Thu 19 Apr 2018 at 12:45, Dan Carpenter wrote:

+static int mipi_csis_clk_get(struct csi_state *state)
+{
+   struct device *dev = >pdev->dev;
+   int ret = true;


Better to leave ret unitialized.


ack.




+
+   state->mipi_clk = devm_clk_get(dev, "mipi");
+   if (IS_ERR(state->mipi_clk)) {
+   dev_err(dev, "Could not get mipi csi clock\n");
+   return -ENODEV;
+   }
+
+   state->phy_clk = devm_clk_get(dev, "phy");
+   if (IS_ERR(state->phy_clk)) {
+   dev_err(dev, "Could not get mipi phy clock\n");
+   return -ENODEV;
+   }
+
+   /* Set clock rate */
+   if (state->clk_frequency)
+		ret = clk_set_rate(state->mipi_clk, 
state->clk_frequency);

+   else
+   dev_warn(dev, "No clock frequency specified!\n");
+   if (ret < 0) {
+		dev_err(dev, "set rate=%d failed: %d\n", 
state->clk_frequency,

+   ret);
+   return -EINVAL;


Preserve the error code.


agree.




+   }
+
+   return ret;


This could be "return 0;" (let's not return true).  It might be 
nicer

like:

if (!state->clk_frequency) {


looking back again to my code ;), this can never happen, because 
if
clock-frequency is not given by dts I give it a default value. So, 
this

error path will never happen. I will take this in account in v2.


dev_warn(dev, "No clock frequency specified!\n");
return 0;
}

ret = clk_set_rate(state->mipi_clk, state->clk_frequency);
if (ret < 0)
		dev_err(dev, "set rate=%d failed: %d\n", 
state->clk_frequency,

ret);

return ret;



+}
+


[ snip ]

+static irqreturn_t mipi_csis_irq_handler(int irq, void 
*dev_id)

+{
+   struct csi_state *state = dev_id;
+   unsigned long flags;
+   u32 status;
+   int i;
+
+   status = mipi_csis_read(state, MIPI_CSIS_INTSRC);
+
+   spin_lock_irqsave(>slock, flags);
+
+   /* Update the event/error counters */
+   if ((status & MIPI_CSIS_INTSRC_ERRORS) || 1) {

 ^^^
Was this supposed to make it into the published code?


No... ;). Only for my debug purpose... Good catch.

---
Cheers,
Rui

Re: [PATCH 02/15] media: staging/imx7: add imx7 CSI subdev driver

[Rui Miguel Silva]

Hi,
On Thu 19 Apr 2018 at 12:22, Dan Carpenter wrote:
On Thu, Apr 19, 2018 at 11:17:59AM +0100, Rui Miguel Silva 
wrote:

+static int imx7_csi_link_setup(struct media_entity *entity,
+  const struct media_pad *local,
+			   const struct media_pad *remote, u32 
flags)

+{
+	struct v4l2_subdev *sd = 
media_entity_to_v4l2_subdev(entity);

+   struct imx7_csi *csi = v4l2_get_subdevdata(sd);
+   struct v4l2_subdev *remote_sd;
+   int ret = 0;
+
+	dev_dbg(csi->dev, "link setup %s -> %s\n", 
remote->entity->name,

+   local->entity->name);
+
+   mutex_lock(>lock);
+
+   if (local->flags & MEDIA_PAD_FL_SINK) {
+		if (!is_media_entity_v4l2_subdev(remote->entity)) 
{

+   ret = -EINVAL;
+   goto unlock;
+   }
+
+		remote_sd = 
media_entity_to_v4l2_subdev(remote->entity);

+
+   if (flags & MEDIA_LNK_FL_ENABLED) {
+   if (csi->src_sd) {
+   ret = -EBUSY;
+   goto unlock;
+   }
+   csi->src_sd = remote_sd;
+   } else {
+   csi->src_sd = NULL;
+   }
+
+   goto init;
+   }
+
+   /* source pad */
+   if (flags & MEDIA_LNK_FL_ENABLED) {
+   if (csi->sink) {
+   ret = -EBUSY;
+   goto unlock;
+   }
+   csi->sink = remote->entity;
+   } else {
+   v4l2_ctrl_handler_free(>ctrl_hdlr);
+   v4l2_ctrl_handler_init(>ctrl_hdlr, 0);
+   csi->sink = NULL;
+   }
+
+init:
+   if (csi->sink || csi->src_sd)
+   imx7_csi_init(csi);
+   else
+   imx7_csi_deinit(csi);
+
+unlock:
+   mutex_unlock(>lock);
+
+   return 0;


This should be "return ret;" because the failure paths go 
through here

as well.


Agree.




+}
+
+static int imx7_csi_pad_link_validate(struct v4l2_subdev *sd,
+ struct media_link *link,
+  struct v4l2_subdev_format 
*source_fmt,
+  struct v4l2_subdev_format 
*sink_fmt)

+{
+   struct imx7_csi *csi = v4l2_get_subdevdata(sd);
+   struct v4l2_fwnode_endpoint upstream_ep;
+   int ret;
+
+	ret = v4l2_subdev_link_validate_default(sd, link, 
source_fmt, sink_fmt);

+   if (ret)
+   return ret;
+
+	ret = imx7_csi_get_upstream_endpoint(csi, _ep, 
true);

+   if (ret) {
+		v4l2_err(>sd, "failed to find upstream 
endpoint\n");

+   return ret;
+   }
+
+   mutex_lock(>lock);
+
+   csi->upstream_ep = upstream_ep;
+   csi->is_csi2 = (upstream_ep.bus_type == V4L2_MBUS_CSI2);
+
+   mutex_unlock(>lock);
+
+   return ret;


return 0;


ack.




+}
+


[ snip ]


+
+static int imx7_csi_remove(struct platform_device *pdev)
+{
+   return 0;
+}


There is no need for this empty (struct 
platform_driver)->remove()

function.  See platform_drv_remove() for how it's called.


right.



This looks nice, though.


Thanks,
---
Cheers,
Rui

Re: [PATCH 01/15] media: staging/imx: add support to media dev for no IPU systems

[Rui Miguel Silva]

Hi Dan,
Thanks for this and the other reviews.

On Thu 19 Apr 2018 at 12:06, Dan Carpenter wrote:
On Thu, Apr 19, 2018 at 11:17:58AM +0100, Rui Miguel Silva 
wrote:
Some i.MX SoC do not have IPU, like the i.MX7, add to the the 
media device
infrastructure support to be used in this type of systems that 
do not have

internal subdevices besides the CSI.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/imx-media-dev.c| 16 
 +++-

 .../staging/media/imx/imx-media-internal-sd.c|  3 +++
 drivers/staging/media/imx/imx-media.h|  3 +++
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c

index f67ec8e27093..a8afe0ec4134 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -92,6 +92,9 @@ static int imx_media_get_ipu(struct 
imx_media_dev *imxmd,

struct ipu_soc *ipu;
int ipu_id;
 
+	if (imxmd->no_ipu_present)


It's sort of nicer if variables don't have a negative built in 
because
otherwise you get confusing double negatives like "if (!no_ipu) 
{".
It's not hard to invert the varible in this case, because the 
only thing

we need to change is imx_media_probe() to set:

+   imxmd->ipu_present = true;


Yeah, my code was like this till last minute, and I also dislike 
the
double negatives... but since the logic that reset the variable 
would

only be done in a later patch I switched the logic.

But You are right I could just had the initialization here to 
true.

Will take this in account in v2.

---
Cheers,
Rui

Re: [PATCH 07/15] media: staging/imx: add 10 bit bayer support

[Philipp Zabel]

On Thu, 2018-04-19 at 11:18 +0100, Rui Miguel Silva wrote:
> Some sensors can only output 10 bit bayer formats, like the OV2680. Add 
> support
> for that in imx-media.
> 
> Signed-off-by: Rui Miguel Silva 
> ---
>  drivers/staging/media/imx/imx-media-utils.c | 24 +
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/staging/media/imx/imx-media-utils.c 
> b/drivers/staging/media/imx/imx-media-utils.c
> index fab98fc0d6a0..99527daba29a 100644
> --- a/drivers/staging/media/imx/imx-media-utils.c
> +++ b/drivers/staging/media/imx/imx-media-utils.c
> @@ -118,6 +118,30 @@ static const struct imx_media_pixfmt rgb_formats[] = {
>   .cs = IPUV3_COLORSPACE_RGB,
>   .bpp= 8,
>   .bayer  = true,
> + }, {
> + .fourcc = V4L2_PIX_FMT_SBGGR10,
> + .codes  = {MEDIA_BUS_FMT_SBGGR10_1X10},
> + .cs = IPUV3_COLORSPACE_RGB,
> + .bpp= 16,
> + .bayer  = true,
> + }, {
> + .fourcc = V4L2_PIX_FMT_SGBRG10,
> + .codes  = {MEDIA_BUS_FMT_SGBRG10_1X10},
> + .cs = IPUV3_COLORSPACE_RGB,
> + .bpp= 16,
> + .bayer  = true,
> + }, {
> + .fourcc = V4L2_PIX_FMT_SGRBG10,
> + .codes  = {MEDIA_BUS_FMT_SGRBG10_1X10},
> + .cs = IPUV3_COLORSPACE_RGB,
> + .bpp= 16,
> + .bayer  = true,
> + }, {
> + .fourcc = V4L2_PIX_FMT_SRGGB10,
> + .codes  = {MEDIA_BUS_FMT_SRGGB10_1X10},
> + .cs = IPUV3_COLORSPACE_RGB,
> + .bpp= 16,
> + .bayer  = true,

This will break 10-bit bayer formats on i.MX6, which currently stores
them in memory expanded to 16-bit, as listed in the entries below:

>   }, {
>   .fourcc = V4L2_PIX_FMT_SBGGR16,
>   .codes  = {

regards
Philipp

[PATCH v10 1/2] dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings

[Maxime Ripard]

The Cadence MIPI-CSI2 TX controller is a CSI2 bridge that supports up to 4
video streams and can output on up to 4 CSI-2 lanes, depending on the
hardware implementation.

It can operate with an external D-PHY, an internal one or no D-PHY at all
in some configurations.

Acked-by: Rob Herring 
Acked-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cdns,csi2tx.txt | 98 +++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt

diff --git a/Documentation/devicetree/bindings/media/cdns,csi2tx.txt 
b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
new file mode 100644
index ..459c6e332f52
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2tx.txt
@@ -0,0 +1,98 @@
+Cadence MIPI-CSI2 TX controller
+===
+
+The Cadence MIPI-CSI2 TX controller is a CSI-2 bridge supporting up to
+4 CSI lanes in output, and up to 4 different pixel streams in input.
+
+Required properties:
+  - compatible: must be set to "cdns,csi2tx"
+  - reg: base address and size of the memory mapped region
+  - clocks: phandles to the clocks driving the controller
+  - clock-names: must contain:
+* esc_clk: escape mode clock
+* p_clk: register bank clock
+* pixel_if[0-3]_clk: pixel stream output clock, one for each stream
+ implemented in hardware, between 0 and 3
+
+Optional properties
+  - phys: phandle to the D-PHY. If it is set, phy-names need to be set
+  - phy-names: must contain "dphy"
+
+Required subnodes:
+  - ports: A ports node with one port child node per device input and output
+   port, in accordance with the video interface bindings defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt. The
+   port nodes are numbered as follows.
+
+   Port Description
+   -
+   0CSI-2 output
+   1Stream 0 input
+   2Stream 1 input
+   3Stream 2 input
+   4Stream 3 input
+
+   The stream input port nodes are optional if they are not
+   connected to anything at the hardware level or implemented
+   in the design. Since there is only one endpoint per port,
+   the endpoints are not numbered.
+
+Example:
+
+csi2tx: csi-bridge@0d0e1000 {
+   compatible = "cdns,csi2tx";
+   reg = <0x0d0e1000 0x1000>;
+   clocks = <>, <>,
+<>, <>,
+<>, <>;
+   clock-names = "p_clk", "esc_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi2tx_out: endpoint {
+   remote-endpoint = <_in>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi2tx_in_stream0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi2tx_in_stream1: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   csi2tx_in_stream2: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   csi2tx_in_stream3: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
-- 
2.17.0

[PATCH v10 0/2] media: v4l: Add support for the Cadence MIPI-CSI2 TX controller

[Maxime Ripard]

Hi,

Here is an attempt at supporting the MIPI-CSI2 TX block from Cadence.

This IP block is able to receive 4 video streams and stream them over
a MIPI-CSI2 link using up to 4 lanes. Those streams are basically the
interfaces to controllers generating some video signals, like a camera
or a pattern generator.

It is able to map input streams to CSI2 virtual channels and datatypes
dynamically. The streaming devices choose their virtual channels
through an additional signal that is transparent to the CSI2-TX. The
datatypes however are yet another additional input signal, and can be
mapped to any CSI2 datatypes.

Since v4l2 doesn't really allow for that setup at the moment, this
preliminary version is a rather dumb one in order to start the
discussion on how to address this properly.

Let me know what you think!
Maxime

Changes from v9:
  - Prevent the format to be retrieved on the CSI2 pad
  - Set the default format on the pads when the user tries to set an
unsupported format

Changes from v8:
  - Updated the copyright notice
  - Used masks for the device config fields
  - Used the mbus code directly in our format lookup function
  - Removed the pad index check in pads get/set_format
  - Prevent the format to be changed on the CSI2 pad
  - Check for supported formats in set_format
  - Rebased on 4.17-rc1

Changes from v7:
  - Removed unused headers
  - Fixed a function prefix inconsistency
  - Added Niklas' Reviewed-by

Changes from v6:
  - Added Niklas Reviewed-by on the bindings
  - Added MODULE_LICENSE, MODULE_DESCRIPTION and MODULE_AUTHOR

Changes from v5:
  - Changed the return type to void for csi2tx_stop
  - Checked for the pad index in get/set_pad_format
  - Made a comment that the DPHY registers are for the DPHY *interface*
register

Changes from v4:
  - After playing a bit with the pad multiplexing patches, found that it
was making much more sense to have the subdev notifiers for the source
subdev rather for the sink that might even be outside of Linux control.
Removed the notifier for now.

Changes from v3:
  - Added a comment about entity links walk concurrency
  - Changed the default resolution to 1280x720
  - Changed usleep_range calls to udelay
  - Reworked the reference counting mechanism to remove a race
condition by adding a mutex instead of an atomic count
  - Changed the entity function to MEDIA_ENT_F_VID_IF_BRIDGE
  - Changed the name of the reg variable in _get_resources to dev_cfg
  - Removed the redundant error message in the devm_ioremap_resource
error path
  - Moved the subdev s_stream call before enabling the TX bridge
  - Changed some int types to unsigned
  - Init'd the pad formats properly
  - Fixed typo in the CSI2TX_LANES_MAX define name
  - Added Sakari Acked-by

Changes from v2:
  - Use SPDX license header
  - Use the lane mapping from DT

Changes from v1:
  - Add a subdev notifier and start our downstream subdevice in
s_stream  
  - Based the decision to enable the stream or not on the link state
instead of whether a format was being set on the pad
  - Put the controller back in reset when stopping the pipeline
  - Clarified the enpoints number in the DT binding
  - Added a default format for the pads
  - Added some missing const
  - Added more explicit comments
  - Rebased on 4.15

Maxime Ripard (2):
  dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings
  v4l: cadence: Add Cadence MIPI-CSI2 TX driver

 .../devicetree/bindings/media/cdns,csi2tx.txt |  98 
 drivers/media/platform/cadence/Kconfig|  11 +
 drivers/media/platform/cadence/Makefile   |   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c  | 541 ++
 4 files changed, 651 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

-- 
2.17.0

[PATCH v10 2/2] v4l: cadence: Add Cadence MIPI-CSI2 TX driver

[Maxime Ripard]

The Cadence MIPI-CSI2 TX controller is an hardware block meant to be used
as a bridge between pixel interfaces and a CSI-2 bus.

It supports operating with an internal or external D-PHY, with up to 4
lanes, or without any D-PHY. The current code only supports the latter
case.

While the virtual channel input on the pixel interface can be directly
mapped to CSI2, the datatype input is actually a selection signal (3-bits)
mapping to a table of up to 8 preconfigured datatypes/formats (programmed
at start-up)

The block supports up to 8 input datatypes.

Reviewed-by: Niklas Söderlund 
Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/cadence/Kconfig   |  11 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c | 541 +++
 3 files changed, 553 insertions(+)
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

diff --git a/drivers/media/platform/cadence/Kconfig 
b/drivers/media/platform/cadence/Kconfig
index 70c95d79c8f7..3bf0f2454384 100644
--- a/drivers/media/platform/cadence/Kconfig
+++ b/drivers/media/platform/cadence/Kconfig
@@ -20,4 +20,15 @@ config VIDEO_CADENCE_CSI2RX
  To compile this driver as a module, choose M here: the module will be
  called cdns-csi2rx.
 
+config VIDEO_CADENCE_CSI2TX
+   tristate "Cadence MIPI-CSI2 TX Controller"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ Support for the Cadence MIPI CSI2 Transceiver controller.
+
+ To compile this driver as a module, choose M here: the module will be
+ called cdns-csi2tx.
+
 endif
diff --git a/drivers/media/platform/cadence/Makefile 
b/drivers/media/platform/cadence/Makefile
index 99a4086b7448..7fe992273162 100644
--- a/drivers/media/platform/cadence/Makefile
+++ b/drivers/media/platform/cadence/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
+obj-$(CONFIG_VIDEO_CADENCE_CSI2TX) += cdns-csi2tx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2tx.c 
b/drivers/media/platform/cadence/cdns-csi2tx.c
new file mode 100644
index ..028ea87158da
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2tx.c
@@ -0,0 +1,541 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for Cadence MIPI-CSI2 TX Controller
+ *
+ * Copyright (C) 2017-2018 Cadence Design Systems Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2TX_DEVICE_CONFIG_REG   0x00
+#define CSI2TX_DEVICE_CONFIG_STREAMS_MASK  GENMASK(6, 4)
+#define CSI2TX_DEVICE_CONFIG_HAS_DPHY  BIT(3)
+#define CSI2TX_DEVICE_CONFIG_LANES_MASKGENMASK(2, 0)
+
+#define CSI2TX_CONFIG_REG  0x20
+#define CSI2TX_CONFIG_CFG_REQ  BIT(2)
+#define CSI2TX_CONFIG_SRST_REQ BIT(1)
+
+#define CSI2TX_DPHY_CFG_REG0x28
+#define CSI2TX_DPHY_CFG_CLK_RESET  BIT(16)
+#define CSI2TX_DPHY_CFG_LANE_RESET(n)  BIT((n) + 12)
+#define CSI2TX_DPHY_CFG_MODE_MASK  GENMASK(9, 8)
+#define CSI2TX_DPHY_CFG_MODE_LPDT  (2 << 8)
+#define CSI2TX_DPHY_CFG_MODE_HS(1 << 8)
+#define CSI2TX_DPHY_CFG_MODE_ULPS  (0 << 8)
+#define CSI2TX_DPHY_CFG_CLK_ENABLE BIT(4)
+#define CSI2TX_DPHY_CFG_LANE_ENABLE(n) BIT(n)
+
+#define CSI2TX_DPHY_CLK_WAKEUP_REG 0x2c
+#define CSI2TX_DPHY_CLK_WAKEUP_ULPS_CYCLES(n)  ((n) & 0x)
+
+#define CSI2TX_DT_CFG_REG(n)   (0x80 + (n) * 8)
+#define CSI2TX_DT_CFG_DT(n)(((n) & 0x3f) << 2)
+
+#define CSI2TX_DT_FORMAT_REG(n)(0x84 + (n) * 8)
+#define CSI2TX_DT_FORMAT_BYTES_PER_LINE(n) (((n) & 0x) << 16)
+#define CSI2TX_DT_FORMAT_MAX_LINE_NUM(n)   ((n) & 0x)
+
+#define CSI2TX_STREAM_IF_CFG_REG(n)(0x100 + (n) * 4)
+#define CSI2TX_STREAM_IF_CFG_FILL_LEVEL(n) ((n) & 0x1f)
+
+#define CSI2TX_LANES_MAX   4
+#define CSI2TX_STREAMS_MAX 4
+
+enum csi2tx_pads {
+   CSI2TX_PAD_SOURCE,
+   CSI2TX_PAD_SINK_STREAM0,
+   CSI2TX_PAD_SINK_STREAM1,
+   CSI2TX_PAD_SINK_STREAM2,
+   CSI2TX_PAD_SINK_STREAM3,
+   CSI2TX_PAD_MAX,
+};
+
+struct csi2tx_fmt {
+   u32 mbus;
+   u32 dt;
+   u32 bpp;
+};
+
+struct csi2tx_priv {
+   struct device   *dev;
+   unsigned intcount;
+
+   /*
+* Used to prevent race conditions between multiple,
+* concurrent calls to start and stop.
+*/
+   struct mutexlock;
+
+   void __iomem*base;
+
+   struct clk  *esc_clk;
+   struct clk  *p_clk;
+   struct clk  *pixel_clk[CSI2TX_STREAMS_MAX];
+
+   struct 

Re: [PATCH 01/15] media: staging/imx: add support to media dev for no IPU systems

[Dan Carpenter]

On Thu, Apr 19, 2018 at 11:17:58AM +0100, Rui Miguel Silva wrote:
> Some i.MX SoC do not have IPU, like the i.MX7, add to the the media device
> infrastructure support to be used in this type of systems that do not have
> internal subdevices besides the CSI.
> 
> Signed-off-by: Rui Miguel Silva 
> ---
>  drivers/staging/media/imx/imx-media-dev.c| 16 +++-
>  .../staging/media/imx/imx-media-internal-sd.c|  3 +++
>  drivers/staging/media/imx/imx-media.h|  3 +++
>  3 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/media/imx/imx-media-dev.c 
> b/drivers/staging/media/imx/imx-media-dev.c
> index f67ec8e27093..a8afe0ec4134 100644
> --- a/drivers/staging/media/imx/imx-media-dev.c
> +++ b/drivers/staging/media/imx/imx-media-dev.c
> @@ -92,6 +92,9 @@ static int imx_media_get_ipu(struct imx_media_dev *imxmd,
>   struct ipu_soc *ipu;
>   int ipu_id;
>  
> + if (imxmd->no_ipu_present)

It's sort of nicer if variables don't have a negative built in because
otherwise you get confusing double negatives like "if (!no_ipu) {".
It's not hard to invert the varible in this case, because the only thing
we need to change is imx_media_probe() to set:

+   imxmd->ipu_present = true;

regards,
dan carpenter

Re: [PATCH 05/15] media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7

[Dan Carpenter]

> +static int mipi_csis_clk_get(struct csi_state *state)
> +{
> + struct device *dev = >pdev->dev;
> + int ret = true;

Better to leave ret unitialized.

> +
> + state->mipi_clk = devm_clk_get(dev, "mipi");
> + if (IS_ERR(state->mipi_clk)) {
> + dev_err(dev, "Could not get mipi csi clock\n");
> + return -ENODEV;
> + }
> +
> + state->phy_clk = devm_clk_get(dev, "phy");
> + if (IS_ERR(state->phy_clk)) {
> + dev_err(dev, "Could not get mipi phy clock\n");
> + return -ENODEV;
> + }
> +
> + /* Set clock rate */
> + if (state->clk_frequency)
> + ret = clk_set_rate(state->mipi_clk, state->clk_frequency);
> + else
> + dev_warn(dev, "No clock frequency specified!\n");
> + if (ret < 0) {
> + dev_err(dev, "set rate=%d failed: %d\n", state->clk_frequency,
> + ret);
> + return -EINVAL;

Preserve the error code.

> + }
> +
> + return ret;

This could be "return 0;" (let's not return true).  It might be nicer
like:

if (!state->clk_frequency) {
dev_warn(dev, "No clock frequency specified!\n");
return 0;
}

ret = clk_set_rate(state->mipi_clk, state->clk_frequency);
if (ret < 0)
dev_err(dev, "set rate=%d failed: %d\n", state->clk_frequency,
ret);

return ret;


> +}
> +

[ snip ]

> +static irqreturn_t mipi_csis_irq_handler(int irq, void *dev_id)
> +{
> + struct csi_state *state = dev_id;
> + unsigned long flags;
> + u32 status;
> + int i;
> +
> + status = mipi_csis_read(state, MIPI_CSIS_INTSRC);
> +
> + spin_lock_irqsave(>slock, flags);
> +
> + /* Update the event/error counters */
> + if ((status & MIPI_CSIS_INTSRC_ERRORS) || 1) {
 ^^^
Was this supposed to make it into the published code?

> + for (i = 0; i < MIPI_CSIS_NUM_EVENTS; i++) {
> + if (!(status & state->events[i].mask))
> + continue;
> + state->events[i].counter++;
> + }
> + }
> + spin_unlock_irqrestore(>slock, flags);
> +
> + mipi_csis_write(state, MIPI_CSIS_INTSRC, status);
> +
> + return IRQ_HANDLED;
> +}
> +

regards,
dan carpenter

Re: [PATCH v2 00/12] media: ov5640: Misc cleanup and improvements

[Maxime Ripard]

Hi Samuel,

On Wed, Apr 18, 2018 at 04:39:06PM -0700, Samuel Bobrowicz wrote:
> I applied your patches, and they are a big improvement for what I am
> trying to do, but things still aren't working right on my platform.
> 
> How confident are you that the MIPI mode will work with this version
> of the driver?

Not too confident. Like I said, I did all my tests on a parallel
camera with a scope, so I'm pretty confident for the parallel bus. But
I haven't been able to test the MIPI-CSI side of things and tried to
deduce it from the datasheet.

tl; dr: I might very well be wrong.

> I am having issues that I believe are due to incorrect clock
> generation. Our engineers did some reverse engineering of the clock
> tree themselves, and came up with a slightly different model.  I've
> captured their model in a spreadsheet here:
> https://tinyurl.com/pll-calc . Just modify the register and xclk
> values to see the clocks change. Do your tests disagree with this
> potential model?

At least on the parallel side, it looks fairly similar, so I guess we
can come to an agreement :)

There's just the SCLK2x divider that is no longer in the path to PCLK
but has been replaced with BIT Divider that has the same value, so it
should work as well.

> I'm not sure which model is more correct, but my tests suggest the
> high speed MIPI clock is generated directly off the PLL. This means
> the PLL multiplier you are generating in your algorithm is not high
> enough to satisfy the bandwidth. If this is the case, MIPI mode will
> require a different set of parameters that enable some of the
> downstream dividers, so that the PLL multiplier can be higher while
> the PCLK value still matches the needed rate calculated from the
> resolution.
> 
> Any thoughts on this before I dive in and start tweaking the algorithm
> in mipi mode?

Like I said, I did that analysis by plugging the camera to a scope and
look at the PCLK generated for various combinations. Your analysis
seems not too far off for the setup I've tested, so I guess this makes
sense. And let me know how it works for MIPI-CSI2 so that I can update
the patches :)

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH 02/15] media: staging/imx7: add imx7 CSI subdev driver

[Dan Carpenter]

On Thu, Apr 19, 2018 at 11:17:59AM +0100, Rui Miguel Silva wrote:
> +static int imx7_csi_link_setup(struct media_entity *entity,
> +const struct media_pad *local,
> +const struct media_pad *remote, u32 flags)
> +{
> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> + struct imx7_csi *csi = v4l2_get_subdevdata(sd);
> + struct v4l2_subdev *remote_sd;
> + int ret = 0;
> +
> + dev_dbg(csi->dev, "link setup %s -> %s\n", remote->entity->name,
> + local->entity->name);
> +
> + mutex_lock(>lock);
> +
> + if (local->flags & MEDIA_PAD_FL_SINK) {
> + if (!is_media_entity_v4l2_subdev(remote->entity)) {
> + ret = -EINVAL;
> + goto unlock;
> + }
> +
> + remote_sd = media_entity_to_v4l2_subdev(remote->entity);
> +
> + if (flags & MEDIA_LNK_FL_ENABLED) {
> + if (csi->src_sd) {
> + ret = -EBUSY;
> + goto unlock;
> + }
> + csi->src_sd = remote_sd;
> + } else {
> + csi->src_sd = NULL;
> + }
> +
> + goto init;
> + }
> +
> + /* source pad */
> + if (flags & MEDIA_LNK_FL_ENABLED) {
> + if (csi->sink) {
> + ret = -EBUSY;
> + goto unlock;
> + }
> + csi->sink = remote->entity;
> + } else {
> + v4l2_ctrl_handler_free(>ctrl_hdlr);
> + v4l2_ctrl_handler_init(>ctrl_hdlr, 0);
> + csi->sink = NULL;
> + }
> +
> +init:
> + if (csi->sink || csi->src_sd)
> + imx7_csi_init(csi);
> + else
> + imx7_csi_deinit(csi);
> +
> +unlock:
> + mutex_unlock(>lock);
> +
> + return 0;

This should be "return ret;" because the failure paths go through here
as well.

> +}
> +
> +static int imx7_csi_pad_link_validate(struct v4l2_subdev *sd,
> +   struct media_link *link,
> +   struct v4l2_subdev_format *source_fmt,
> +   struct v4l2_subdev_format *sink_fmt)
> +{
> + struct imx7_csi *csi = v4l2_get_subdevdata(sd);
> + struct v4l2_fwnode_endpoint upstream_ep;
> + int ret;
> +
> + ret = v4l2_subdev_link_validate_default(sd, link, source_fmt, sink_fmt);
> + if (ret)
> + return ret;
> +
> + ret = imx7_csi_get_upstream_endpoint(csi, _ep, true);
> + if (ret) {
> + v4l2_err(>sd, "failed to find upstream endpoint\n");
> + return ret;
> + }
> +
> + mutex_lock(>lock);
> +
> + csi->upstream_ep = upstream_ep;
> + csi->is_csi2 = (upstream_ep.bus_type == V4L2_MBUS_CSI2);
> +
> + mutex_unlock(>lock);
> +
> + return ret;

return 0;

> +}
> +

[ snip ]

> +
> +static int imx7_csi_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}

There is no need for this empty (struct platform_driver)->remove()
function.  See platform_drv_remove() for how it's called.

This looks nice, though.

regards,
dan carpenter

Re: [RFC PATCH]: intel-ipu3: Add uAPI documentation

[Mauro Carvalho Chehab]

Em Tue,  3 Apr 2018 19:52:25 -0500
Yong Zhi  escreveu:

> This is a preliminary effort to add documentation for the
> following BNR(bayer noise reduction) structs:
> 
> ipu3_uapi_bnr_static_config_wb_gains_config
> ipu3_uapi_bnr_static_config_wb_gains_thr_config
> ipu3_uapi_bnr_static_config_thr_coeffs_config
> ipu3_uapi_bnr_static_config_thr_ctrl_shd_config
> ipu3_uapi_bnr_static_config_opt_center_sqr_config
> ipu3_uapi_bnr_static_config_bp_ctrl_config
> ipu3_uapi_bnr_static_config_dn_detect_ctrl_config
> ipu3_uapi_bnr_static_config_opt_center_sqr_config
> ipu3_uapi_bnr_static_config_green_disparity
> 
> The feedback on this patch will be used towards the
> documentation of reset of the uAPI in intel-ipu3.h.

I'm assuming that, on the final review, you'll be adding documentation
for all structs, right?

Due to amount of structs and complexity, and, as the IPU3 driver has
seem to be used also on PC products, like on Dell Latitude 5285 detachable
laptop[1], I'm expecting that the documentation will be good enough for people
to be able to develop an Open Source code that will be providing good
quality images from its camera.

It should also receive some sort of logic to make it work as a normal
camera for applications (either via some Kernel support, via libv4l2
or both).

[1] https://www.spinics.net/lists/linux-usb/msg167478.html

> 
> Link to v6 IPU3 ImgU patchset:
> 
> 
> 
> Signed-off-by: Yong Zhi 
> Signed-off-by: Chao C Li 
> ---
>  Documentation/media/media_uapi.rst  |1 +
>  Documentation/media/uapi/intel-ipu3.rst |8 +
>  include/uapi/linux/intel-ipu3.h | 1520 
> +++
>  3 files changed, 1529 insertions(+)
>  create mode 100644 Documentation/media/uapi/intel-ipu3.rst
>  create mode 100644 include/uapi/linux/intel-ipu3.h
> 
> diff --git a/Documentation/media/media_uapi.rst 
> b/Documentation/media/media_uapi.rst
> index 28eb35a1f965..edfa674b49c3 100644
> --- a/Documentation/media/media_uapi.rst
> +++ b/Documentation/media/media_uapi.rst
> @@ -31,3 +31,4 @@ License".
>  uapi/cec/cec-api
>  uapi/gen-errors
>  uapi/fdl-appendix
> +uapi/intel-ipu3
> diff --git a/Documentation/media/uapi/intel-ipu3.rst 
> b/Documentation/media/uapi/intel-ipu3.rst
> new file mode 100644
> index ..d4d9b2806fe9
> --- /dev/null
> +++ b/Documentation/media/uapi/intel-ipu3.rst
> @@ -0,0 +1,8 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _intel-ipu3:
> +
> +Intel IPU3 ImgU uAPI headers
> +
> +
> +.. kernel-doc:: include/uapi/linux/intel-ipu3.h

I'm pretty sure that just the headers are not enough for someone to use
the new uAPI. You need to provide some documentation there that would
be enough for someone to write their own code to use this uAPI.

> diff --git a/include/uapi/linux/intel-ipu3.h b/include/uapi/linux/intel-ipu3.h
> new file mode 100644
> index ..34b071524beb
> --- /dev/null
> +++ b/include/uapi/linux/intel-ipu3.h
> @@ -0,0 +1,1520 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2018 Intel Corporation */
> +
> +#ifndef __IPU3_UAPI_H
> +#define __IPU3_UAPI_H
> +
> +#include 
> +
> +#define IPU3_UAPI_ISP_VEC_ELEMS  64
> +
> +#define IMGU_ABI_PAD __aligned(IPU3_UAPI_ISP_WORD_BYTES)
> +#define IPU3_ALIGN   __attribute__((aligned(IPU3_UAPI_ISP_WORD_BYTES)))
> +
> +#define IPU3_UAPI_ISP_WORD_BYTES 32
> +#define IPU3_UAPI_MAX_STRIPES2
> +
> +/*** ipu3_uapi_stats_3a ***/
> +
> +#define IPU3_UAPI_MAX_BUBBLE_SIZE10
> +
> +#define IPU3_UAPI_AE_COLORS  4
> +#define IPU3_UAPI_AE_BINS256
> +
> +#define IPU3_UAPI_AWB_MD_ITEM_SIZE   8
> +#define IPU3_UAPI_AWB_MAX_SETS   60
> +#define IPU3_UAPI_AWB_SET_SIZE   0x500
> +#define IPU3_UAPI_AWB_SPARE_FOR_BUBBLES \
> + (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \
> +  IPU3_UAPI_AWB_MD_ITEM_SIZE)
> +#define IPU3_UAPI_AWB_MAX_BUFFER_SIZE \
> + (IPU3_UAPI_AWB_MAX_SETS * \
> +  (IPU3_UAPI_AWB_SET_SIZE + IPU3_UAPI_AWB_SPARE_FOR_BUBBLES))
> +
> +#define IPU3_UAPI_AF_MAX_SETS24
> +#define IPU3_UAPI_AF_MD_ITEM_SIZE4
> +#define IPU3_UAPI_AF_SPARE_FOR_BUBBLES \
> + (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \
> +  IPU3_UAPI_AF_MD_ITEM_SIZE)
> +#define IPU3_UAPI_AF_Y_TABLE_SET_SIZE0x80
> +#define IPU3_UAPI_AF_Y_TABLE_MAX_SIZE \
> + (IPU3_UAPI_AF_MAX_SETS * \
> +  (IPU3_UAPI_AF_Y_TABLE_SET_SIZE + IPU3_UAPI_AF_SPARE_FOR_BUBBLES) * \
> +  IPU3_UAPI_MAX_STRIPES)
> +
> +#define IPU3_UAPI_AWB_FR_MAX_SETS24
> +#define 

Re: [PATCH RESEND 6/6] media: v4l2-compat-ioctl32: simplify casts

[Hans Verkuil]

On 04/19/18 13:15, Mauro Carvalho Chehab wrote:
> Making the cast right for get_user/put_user is not trivial, as
> it needs to ensure that the types are the correct ones.
> 
> Improve it by using macros.
> 
> Tested with vivid with:
>   $ sudo modprobe vivid no_error_inj=1
>   $ v4l2-compliance-32bits -a -s10 >32bits && v4l2-compliance-64bits -a 
> -s10 > 64bits && diff -U0 32bits 64bits
>   --- 32bits  2018-04-17 11:18:29.141240772 -0300
>   +++ 64bits  2018-04-17 11:18:40.635282341 -0300
>   @@ -1 +1 @@
>   -v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 32 
> bits
>   +v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 64 
> bits
> 
> Using the latest version of v4l-utils with this patch applied:
>   https://patchwork.linuxtv.org/patch/48746/
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 40 
> ++-
>  1 file changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index 8c05dd9660d3..d2f0268427c2 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -30,6 +30,24 @@
>   get_user(__assign_tmp, from) || put_user(__assign_tmp, to); \
>  })
>  
> +#define get_user_cast(__x, __ptr)\
> +({   \
> + get_user(__x, (typeof(*__ptr) __user *)(__ptr));\
> +})
> +
> +#define put_user_force(__x, __ptr)   \
> +({   \
> + put_user((typeof(*__x) __force *)(__x), __ptr); \
> +})
> +
> +#define assign_in_user_cast(to, from)
> \
> +({   \
> + typeof(*from) __assign_tmp; \
> + \
> + get_user_cast(__assign_tmp, from) || put_user(__assign_tmp, to);\
> +})

Please add comments for these macros. It's not trivially obvious what they
do and why they are needed.

> +
> +
>  static long native_ioctl(struct file *file, unsigned int cmd, unsigned long 
> arg)
>  {
>   long ret = -ENOIOCTLCMD;
> @@ -543,8 +561,7 @@ static int get_v4l2_buffer32(struct v4l2_buffer __user 
> *p64,
>   return -EFAULT;
>  
>   uplane = aux_buf;
> - if (put_user((__force struct v4l2_plane *)uplane,
> -  >m.planes))
> + if (put_user_force(uplane, >m.planes))
>   return -EFAULT;
>  
>   while (num_planes--) {
> @@ -682,7 +699,7 @@ static int get_v4l2_framebuffer32(struct v4l2_framebuffer 
> __user *p64,
>  
>   if (!access_ok(VERIFY_READ, p32, sizeof(*p32)) ||
>   get_user(tmp, >base) ||
> - put_user((void __force *)compat_ptr(tmp), >base) ||
> + put_user_force(compat_ptr(tmp), >base) ||
>   assign_in_user(>capability, >capability) ||
>   assign_in_user(>flags, >flags) ||
>   copy_in_user(>fmt, >fmt, sizeof(p64->fmt)))
> @@ -831,8 +848,7 @@ static int get_v4l2_ext_controls32(struct file *file,
>   if (aux_space < count * sizeof(*kcontrols))
>   return -EFAULT;
>   kcontrols = aux_buf;
> - if (put_user((__force struct v4l2_ext_control *)kcontrols,
> -  >controls))
> + if (put_user_force(kcontrols, >controls))
>   return -EFAULT;
>  
>   for (n = 0; n < count; n++) {
> @@ -898,12 +914,11 @@ static int put_v4l2_ext_controls32(struct file *file,
>   unsigned int size = sizeof(*ucontrols);
>   u32 id;
>  
> - if (get_user(id, (unsigned int __user *)>id) ||
> + if (get_user_cast(id, >id) ||
>   put_user(id, >id) ||
> - assign_in_user(>size,
> -(unsigned int __user *)>size) ||
> + assign_in_user_cast(>size, >size) ||
>   copy_in_user(>reserved2,
> -  (unsigned int __user *)>reserved2,
> +  (void __user *)>reserved2,

I would prefer to see this change merged with patch 4/6 instead. There
is no reason to correct it here.

>sizeof(ucontrols->reserved2)))
>   return -EFAULT;
>  
> @@ -916,7 +931,7 @@ static int put_v4l2_ext_controls32(struct file *file,
>   size -= sizeof(ucontrols->value64);
>  
>   if (copy_in_user(ucontrols,
> -  (unsigned int __user *)kcontrols, size))
> +  (void __user *)kcontrols, size))

Ditto for 

Re: [PATCH RESEND 4/6] media: v4l2-compat-ioctl32: fix several __user annotations

[Hans Verkuil]

On 04/19/18 13:15, Mauro Carvalho Chehab wrote:
> Smatch report several issues with bad __user annotations:
> 
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:expected void 
> [noderef] *uptr
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:got void *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:expected void 
> const volatile [noderef] *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:got struct 
> v4l2_plane [noderef] **
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:expected void 
> [noderef] *uptr
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:got void 
> *[assigned] base
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: warning: incorrect 
> type in assignment (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:expected struct 
> v4l2_ext_control [noderef] *kcontrols
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:got struct 
> v4l2_ext_control *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: warning: incorrect 
> type in assignment (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:expected unsigned 
> char [usertype] *__pu_val
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:got void [noderef] 
> *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:expected void 
> [noderef] *uptr
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:got void 
> *[assigned] edid
> 
> Fix them.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 51 
> ++-
>  1 file changed, 35 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index d03a44d89649..c951ac3faf46 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -443,8 +443,8 @@ static int put_v4l2_plane32(struct v4l2_plane __user *up,
>   return -EFAULT;
>   break;
>   case V4L2_MEMORY_USERPTR:
> - if (get_user(p, >m.userptr) ||
> - put_user((compat_ulong_t)ptr_to_compat((__force void *)p),
> + if (get_user(p, >m.userptr)||
> + put_user((compat_ulong_t)ptr_to_compat((void __user *)p),
>>m.userptr))
>   return -EFAULT;
>   break;
> @@ -587,7 +587,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
> *kp,
>   u32 length;
>   enum v4l2_memory memory;
>   struct v4l2_plane32 __user *uplane32;
> - struct v4l2_plane __user *uplane;
> + struct v4l2_plane *uplane;
>   compat_caddr_t p;
>   int ret;
>  
> @@ -617,15 +617,22 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
> *kp,
>  
>   if (num_planes == 0)
>   return 0;
> -
> - if (get_user(uplane, ((__force struct v4l2_plane __user 
> **)>m.planes)))
> + /* We need to define uplane without __user, even though
> +  * it does point to data in userspace here. The reason is
> +  * that v4l2-ioctl.c copies it from userspace to kernelspace,
> +  * so its definition in videodev2.h doesn't have a
> +  * __user markup. Defining uplane with __user causes
> +  * smatch warnings, so instead declare it without __user
> +  * and cast it as a userspace pointer to put_v4l2_plane32().
> +  */
> + if (get_user(uplane, >m.planes))
>   return -EFAULT;
>   if (get_user(p, >m.planes))
>   return -EFAULT;
>   uplane32 = compat_ptr(p);
>  
>   while (num_planes--) {
> - ret = put_v4l2_plane32(uplane, uplane32, memory);
> + ret = put_v4l2_plane32((void __user *)uplane, uplane32, 
> memory);
>   if (ret)
>   return ret;
>   ++uplane;
> @@ -675,7 +682,7 @@ static int get_v4l2_framebuffer32(struct v4l2_framebuffer 
> __user *kp,
>  
>   if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
>   get_user(tmp, >base) ||
> - put_user((__force void *)compat_ptr(tmp), >base) ||
> + put_user((void __force *)compat_ptr(tmp), >base) ||
>   

Re: [PATCH RESEND 3/6] media: omap3isp: Allow it to build with COMPILE_TEST

[Hans Verkuil]

On 04/19/18 13:15, Mauro Carvalho Chehab wrote:
> From: Arnd Bergmann 
> 
> There aren't much things required for it to build with COMPILE_TEST.
> It just needs to not compile the code that depends on arm-specific
> iommu implementation.
> 
> Signed-off-by: Arnd Bergmann 
> Co-developed-by: Mauro Carvalho Chehab 
> Acked-by: Sakari Ailus 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/platform/Kconfig| 6 ++
>  drivers/media/platform/omap3isp/isp.c | 8 
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 1ee915b794c0..e3229f7baed1 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -63,12 +63,10 @@ config VIDEO_MUX
>  config VIDEO_OMAP3
>   tristate "OMAP 3 Camera support"
>   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
> - depends on ARCH_OMAP3 || COMPILE_TEST
> - depends on ARM
> + depends on (ARCH_OMAP3 && OMAP_IOMMU) || COMPILE_TEST
>   depends on COMMON_CLK
>   depends on HAS_DMA && OF
> - depends on OMAP_IOMMU
> - select ARM_DMA_USE_IOMMU
> + select ARM_DMA_USE_IOMMU if OMAP_IOMMU
>   select VIDEOBUF2_DMA_CONTIG
>   select MFD_SYSCON
>   select V4L2_FWNODE
> diff --git a/drivers/media/platform/omap3isp/isp.c 
> b/drivers/media/platform/omap3isp/isp.c
> index 16c50099cccd..b8c8761a76b6 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -61,7 +61,9 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_ARM_DMA_USE_IOMMU
>  #include 
> +#endif
>  
>  #include 
>  #include 
> @@ -1938,12 +1940,15 @@ static int isp_initialize_modules(struct isp_device 
> *isp)
>  
>  static void isp_detach_iommu(struct isp_device *isp)
>  {
> +#ifdef CONFIG_ARM_DMA_USE_IOMMU
>   arm_iommu_release_mapping(isp->mapping);
>   isp->mapping = NULL;
> +#endif
>  }
>  
>  static int isp_attach_iommu(struct isp_device *isp)
>  {
> +#ifdef CONFIG_ARM_DMA_USE_IOMMU
>   struct dma_iommu_mapping *mapping;
>   int ret;
>  
> @@ -1972,6 +1977,9 @@ static int isp_attach_iommu(struct isp_device *isp)
>  error:
>   isp_detach_iommu(isp);
>   return ret;
> +#else
> + return -ENODEV;
> +#endif
>  }
>  
>  /*
> 

Re: [PATCH RESEND 2/6] media: omap3isp: Enable driver compilation on ARM with COMPILE_TEST

[Hans Verkuil]

On 04/19/18 13:15, Mauro Carvalho Chehab wrote:
> From: Laurent Pinchart 
> 
> The omap3isp driver can't be compiled on non-ARM platforms but has no
> compile-time dependency on OMAP. It however requires common clock
> framework support, which isn't provided by all ARM platforms.
> 
> Drop the OMAP dependency when COMPILE_TEST is set and add ARM and
> COMMON_CLK dependencies.
> 
> Signed-off-by: Laurent Pinchart 
> Acked-by: Sakari Ailus 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/platform/Kconfig | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 91b0c7324afb..1ee915b794c0 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -62,7 +62,10 @@ 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 ARCH_OMAP3 || COMPILE_TEST
> + depends on ARM
> + depends on COMMON_CLK
>   depends on HAS_DMA && OF
>   depends on OMAP_IOMMU
>   select ARM_DMA_USE_IOMMU
> 

Re: [PATCH RESEND 1/6] omap: omap-iommu.h: allow building drivers with COMPILE_TEST

[Hans Verkuil]

On 04/19/18 13:15, Mauro Carvalho Chehab wrote:
> Drivers that depend on omap-iommu.h (currently, just omap3isp)
> need a stub implementation in order to be built with COMPILE_TEST.
> 
> Cc: Tony Lindgren 
> Cc: Arnd Bergmann 
> Acked-by: Sakari Ailus 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

Regards,

Hans

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

[PATCH RESEND 4/6] media: v4l2-compat-ioctl32: fix several __user annotations

[Mauro Carvalho Chehab]

Smatch report several issues with bad __user annotations:

  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect type 
in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:expected void 
[noderef] *uptr
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:got void *
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: warning: incorrect type 
in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:expected void const 
volatile [noderef] *
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:got struct 
v4l2_plane [noderef] **
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: warning: incorrect type 
in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:expected void 
[noderef] *uptr
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:got void *[assigned] 
base
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: warning: incorrect type 
in assignment (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:expected struct 
v4l2_ext_control [noderef] *kcontrols
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:got struct 
v4l2_ext_control *
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: warning: incorrect type 
in assignment (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:expected unsigned 
char [usertype] *__pu_val
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:got void [noderef] 
*
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: warning: incorrect type 
in argument 1 (different address spaces)
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:expected void 
[noderef] *uptr
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:got void *[assigned] 
edid

Fix them.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 51 ++-
 1 file changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index d03a44d89649..c951ac3faf46 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -443,8 +443,8 @@ static int put_v4l2_plane32(struct v4l2_plane __user *up,
return -EFAULT;
break;
case V4L2_MEMORY_USERPTR:
-   if (get_user(p, >m.userptr) ||
-   put_user((compat_ulong_t)ptr_to_compat((__force void *)p),
+   if (get_user(p, >m.userptr)||
+   put_user((compat_ulong_t)ptr_to_compat((void __user *)p),
 >m.userptr))
return -EFAULT;
break;
@@ -587,7 +587,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user *kp,
u32 length;
enum v4l2_memory memory;
struct v4l2_plane32 __user *uplane32;
-   struct v4l2_plane __user *uplane;
+   struct v4l2_plane *uplane;
compat_caddr_t p;
int ret;
 
@@ -617,15 +617,22 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
*kp,
 
if (num_planes == 0)
return 0;
-
-   if (get_user(uplane, ((__force struct v4l2_plane __user 
**)>m.planes)))
+   /* We need to define uplane without __user, even though
+* it does point to data in userspace here. The reason is
+* that v4l2-ioctl.c copies it from userspace to kernelspace,
+* so its definition in videodev2.h doesn't have a
+* __user markup. Defining uplane with __user causes
+* smatch warnings, so instead declare it without __user
+* and cast it as a userspace pointer to put_v4l2_plane32().
+*/
+   if (get_user(uplane, >m.planes))
return -EFAULT;
if (get_user(p, >m.planes))
return -EFAULT;
uplane32 = compat_ptr(p);
 
while (num_planes--) {
-   ret = put_v4l2_plane32(uplane, uplane32, memory);
+   ret = put_v4l2_plane32((void __user *)uplane, uplane32, 
memory);
if (ret)
return ret;
++uplane;
@@ -675,7 +682,7 @@ static int get_v4l2_framebuffer32(struct v4l2_framebuffer 
__user *kp,
 
if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
get_user(tmp, >base) ||
-   put_user((__force void *)compat_ptr(tmp), >base) ||
+   put_user((void __force *)compat_ptr(tmp), >base) ||
assign_in_user(>capability, >capability) ||
assign_in_user(>flags, >flags) ||
copy_in_user(>fmt, >fmt, sizeof(kp->fmt)))
@@ -690,7 +697,7 @@ static int 

[PATCH RESEND 5/6] media: v4l2-compat-ioctl32: better name userspace pointers

[Mauro Carvalho Chehab]

In the past, "up" were an acronym for "user pointer" and "kp" for
"kernel pointer". However, since a1dfb4c48cc1 ("media:
v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"), both
are now __user pointers.

So, the usage of "kp" is really misleading there. So, rename
both to just "p32" and "p64" everywhere it occurs, in order to
make peace with this file's namespace.

There are two exceptions to "up/kp" nomenclature: at
alloc_userspace() and at do_video_ioctl().

There, a new userspace pointer were allocated, in order to store
the 64 bits version of the ioctl. Those were called as "up_native",
with is, IMHO, an even worse name, as "native" could mislead of
being the arguments that were filled from userspace. I almost
renamed it to just "p64", but, after thinking more about that,
it sounded better to call it as "new_p64", as this makes clearer
that this is the data structure that was allocated inside this
file in order to be used to pass/retrieve data when calling the
64-bit ready file->f_op->unlocked_ioctl() function.

Suggested-by: Sakari Ailus 
Suggested-by: Hans Verkuil 
Reviewed-by: Hans Verkuil 
Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 588 +-
 1 file changed, 294 insertions(+), 294 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index c951ac3faf46..8c05dd9660d3 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -56,8 +56,8 @@ struct v4l2_window32 {
__u8global_alpha;
 };
 
-static int get_v4l2_window32(struct v4l2_window __user *kp,
-struct v4l2_window32 __user *up,
+static int get_v4l2_window32(struct v4l2_window __user *p64,
+struct v4l2_window32 __user *p32,
 void __user *aux_buf, u32 aux_space)
 {
struct v4l2_clip32 __user *uclips;
@@ -65,26 +65,26 @@ static int get_v4l2_window32(struct v4l2_window __user *kp,
compat_caddr_t p;
u32 clipcount;
 
-   if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
-   copy_in_user(>w, >w, sizeof(up->w)) ||
-   assign_in_user(>field, >field) ||
-   assign_in_user(>chromakey, >chromakey) ||
-   assign_in_user(>global_alpha, >global_alpha) ||
-   get_user(clipcount, >clipcount) ||
-   put_user(clipcount, >clipcount))
+   if (!access_ok(VERIFY_READ, p32, sizeof(*p32)) ||
+   copy_in_user(>w, >w, sizeof(p32->w)) ||
+   assign_in_user(>field, >field) ||
+   assign_in_user(>chromakey, >chromakey) ||
+   assign_in_user(>global_alpha, >global_alpha) ||
+   get_user(clipcount, >clipcount) ||
+   put_user(clipcount, >clipcount))
return -EFAULT;
if (clipcount > 2048)
return -EINVAL;
if (!clipcount)
-   return put_user(NULL, >clips);
+   return put_user(NULL, >clips);
 
-   if (get_user(p, >clips))
+   if (get_user(p, >clips))
return -EFAULT;
uclips = compat_ptr(p);
if (aux_space < clipcount * sizeof(*kclips))
return -EFAULT;
kclips = aux_buf;
-   if (put_user(kclips, >clips))
+   if (put_user(kclips, >clips))
return -EFAULT;
 
while (clipcount--) {
@@ -98,27 +98,27 @@ static int get_v4l2_window32(struct v4l2_window __user *kp,
return 0;
 }
 
-static int put_v4l2_window32(struct v4l2_window __user *kp,
-struct v4l2_window32 __user *up)
+static int put_v4l2_window32(struct v4l2_window __user *p64,
+struct v4l2_window32 __user *p32)
 {
struct v4l2_clip __user *kclips;
struct v4l2_clip32 __user *uclips;
compat_caddr_t p;
u32 clipcount;
 
-   if (copy_in_user(>w, >w, sizeof(kp->w)) ||
-   assign_in_user(>field, >field) ||
-   assign_in_user(>chromakey, >chromakey) ||
-   assign_in_user(>global_alpha, >global_alpha) ||
-   get_user(clipcount, >clipcount) ||
-   put_user(clipcount, >clipcount))
+   if (copy_in_user(>w, >w, sizeof(p64->w)) ||
+   assign_in_user(>field, >field) ||
+   assign_in_user(>chromakey, >chromakey) ||
+   assign_in_user(>global_alpha, >global_alpha) ||
+   get_user(clipcount, >clipcount) ||
+   put_user(clipcount, >clipcount))
return -EFAULT;
if (!clipcount)
return 0;
 
-   if (get_user(kclips, >clips))
+   if (get_user(kclips, >clips))
return -EFAULT;
-   if (get_user(p, >clips))
+   if (get_user(p, >clips))
return -EFAULT;

[PATCH RESEND 2/6] media: omap3isp: Enable driver compilation on ARM with COMPILE_TEST

[Mauro Carvalho Chehab]

From: Laurent Pinchart 

The omap3isp driver can't be compiled on non-ARM platforms but has no
compile-time dependency on OMAP. It however requires common clock
framework support, which isn't provided by all ARM platforms.

Drop the OMAP dependency when COMPILE_TEST is set and add ARM and
COMMON_CLK dependencies.

Signed-off-by: Laurent Pinchart 
Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/Kconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 91b0c7324afb..1ee915b794c0 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -62,7 +62,10 @@ 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 ARCH_OMAP3 || COMPILE_TEST
+   depends on ARM
+   depends on COMMON_CLK
depends on HAS_DMA && OF
depends on OMAP_IOMMU
select ARM_DMA_USE_IOMMU
-- 
2.14.3

[PATCH RESEND 1/6] 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.

Cc: Tony Lindgren 
Cc: Arnd Bergmann 
Acked-by: Sakari Ailus 
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..ce1b7c6283ee 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 RESEND 3/6] media: omap3isp: Allow it to build with COMPILE_TEST

[Mauro Carvalho Chehab]

From: Arnd Bergmann 

There aren't much things required for it to build with COMPILE_TEST.
It just needs to not compile the code that depends on arm-specific
iommu implementation.

Signed-off-by: Arnd Bergmann 
Co-developed-by: Mauro Carvalho Chehab 
Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/Kconfig| 6 ++
 drivers/media/platform/omap3isp/isp.c | 8 
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 1ee915b794c0..e3229f7baed1 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -63,12 +63,10 @@ config VIDEO_MUX
 config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
-   depends on ARCH_OMAP3 || COMPILE_TEST
-   depends on ARM
+   depends on (ARCH_OMAP3 && OMAP_IOMMU) || COMPILE_TEST
depends on COMMON_CLK
depends on HAS_DMA && OF
-   depends on OMAP_IOMMU
-   select ARM_DMA_USE_IOMMU
+   select ARM_DMA_USE_IOMMU if OMAP_IOMMU
select VIDEOBUF2_DMA_CONTIG
select MFD_SYSCON
select V4L2_FWNODE
diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 16c50099cccd..b8c8761a76b6 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -61,7 +61,9 @@
 #include 
 #include 
 
+#ifdef CONFIG_ARM_DMA_USE_IOMMU
 #include 
+#endif
 
 #include 
 #include 
@@ -1938,12 +1940,15 @@ static int isp_initialize_modules(struct isp_device 
*isp)
 
 static void isp_detach_iommu(struct isp_device *isp)
 {
+#ifdef CONFIG_ARM_DMA_USE_IOMMU
arm_iommu_release_mapping(isp->mapping);
isp->mapping = NULL;
+#endif
 }
 
 static int isp_attach_iommu(struct isp_device *isp)
 {
+#ifdef CONFIG_ARM_DMA_USE_IOMMU
struct dma_iommu_mapping *mapping;
int ret;
 
@@ -1972,6 +1977,9 @@ static int isp_attach_iommu(struct isp_device *isp)
 error:
isp_detach_iommu(isp);
return ret;
+#else
+   return -ENODEV;
+#endif
 }
 
 /*
-- 
2.14.3

[PATCH RESEND 6/6] media: v4l2-compat-ioctl32: simplify casts

[Mauro Carvalho Chehab]

Making the cast right for get_user/put_user is not trivial, as
it needs to ensure that the types are the correct ones.

Improve it by using macros.

Tested with vivid with:
$ sudo modprobe vivid no_error_inj=1
$ v4l2-compliance-32bits -a -s10 >32bits && v4l2-compliance-64bits -a 
-s10 > 64bits && diff -U0 32bits 64bits
--- 32bits  2018-04-17 11:18:29.141240772 -0300
+++ 64bits  2018-04-17 11:18:40.635282341 -0300
@@ -1 +1 @@
-v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 32 
bits
+v4l2-compliance SHA   : bc71e4a67c6fbc5940062843bc41e7c8679634ce, 64 
bits

Using the latest version of v4l-utils with this patch applied:
https://patchwork.linuxtv.org/patch/48746/

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 40 ++-
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 8c05dd9660d3..d2f0268427c2 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -30,6 +30,24 @@
get_user(__assign_tmp, from) || put_user(__assign_tmp, to); \
 })
 
+#define get_user_cast(__x, __ptr)  \
+({ \
+   get_user(__x, (typeof(*__ptr) __user *)(__ptr));\
+})
+
+#define put_user_force(__x, __ptr) \
+({ \
+   put_user((typeof(*__x) __force *)(__x), __ptr); \
+})
+
+#define assign_in_user_cast(to, from)  \
+({ \
+   typeof(*from) __assign_tmp; \
+   \
+   get_user_cast(__assign_tmp, from) || put_user(__assign_tmp, to);\
+})
+
+
 static long native_ioctl(struct file *file, unsigned int cmd, unsigned long 
arg)
 {
long ret = -ENOIOCTLCMD;
@@ -543,8 +561,7 @@ static int get_v4l2_buffer32(struct v4l2_buffer __user *p64,
return -EFAULT;
 
uplane = aux_buf;
-   if (put_user((__force struct v4l2_plane *)uplane,
->m.planes))
+   if (put_user_force(uplane, >m.planes))
return -EFAULT;
 
while (num_planes--) {
@@ -682,7 +699,7 @@ static int get_v4l2_framebuffer32(struct v4l2_framebuffer 
__user *p64,
 
if (!access_ok(VERIFY_READ, p32, sizeof(*p32)) ||
get_user(tmp, >base) ||
-   put_user((void __force *)compat_ptr(tmp), >base) ||
+   put_user_force(compat_ptr(tmp), >base) ||
assign_in_user(>capability, >capability) ||
assign_in_user(>flags, >flags) ||
copy_in_user(>fmt, >fmt, sizeof(p64->fmt)))
@@ -831,8 +848,7 @@ static int get_v4l2_ext_controls32(struct file *file,
if (aux_space < count * sizeof(*kcontrols))
return -EFAULT;
kcontrols = aux_buf;
-   if (put_user((__force struct v4l2_ext_control *)kcontrols,
->controls))
+   if (put_user_force(kcontrols, >controls))
return -EFAULT;
 
for (n = 0; n < count; n++) {
@@ -898,12 +914,11 @@ static int put_v4l2_ext_controls32(struct file *file,
unsigned int size = sizeof(*ucontrols);
u32 id;
 
-   if (get_user(id, (unsigned int __user *)>id) ||
+   if (get_user_cast(id, >id) ||
put_user(id, >id) ||
-   assign_in_user(>size,
-  (unsigned int __user *)>size) ||
+   assign_in_user_cast(>size, >size) ||
copy_in_user(>reserved2,
-(unsigned int __user *)>reserved2,
+(void __user *)>reserved2,
 sizeof(ucontrols->reserved2)))
return -EFAULT;
 
@@ -916,7 +931,7 @@ static int put_v4l2_ext_controls32(struct file *file,
size -= sizeof(ucontrols->value64);
 
if (copy_in_user(ucontrols,
-(unsigned int __user *)kcontrols, size))
+(void __user *)kcontrols, size))
return -EFAULT;
 
ucontrols++;
@@ -970,10 +985,9 @@ static int get_v4l2_edid32(struct v4l2_edid __user *p64,
if (!access_ok(VERIFY_READ, p32, sizeof(*p32)) ||
assign_in_user(>pad, >pad) ||
assign_in_user(>start_block, >start_block) ||
-   assign_in_user(>blocks,
-  (unsigned char 

[PATCH RESEND 0/6] Remaining COMPILE_TEST and smatch cleanups

[Mauro Carvalho Chehab]

I'm re-sending this patch series, because I forgot to add a C/C on the first
patch of this series. Also, the last patch was sent in separate. So, better
to repost this series.

-

There were several interactions at the COMPILE_TEST and smatch
patch series. While I applied most of them, there are 5 patches that
I kept out of it. The omap3 patch that were in my tree was the old
one. So, I'm re-posting it.

The ioctl32 patches are the latest version. Let's repost it to get some
acks, as this patch touches at V4L2 core, so a careful review is
always a good idea.

Arnd Bergmann (1):
  media: omap3isp: Allow it to build with COMPILE_TEST

Laurent Pinchart (1):
  media: omap3isp: Enable driver compilation on ARM with COMPILE_TEST

Mauro Carvalho Chehab (4):
  omap: omap-iommu.h: allow building drivers with COMPILE_TEST
  media: v4l2-compat-ioctl32: fix several __user annotations
  media: v4l2-compat-ioctl32: better name userspace pointers
  media: v4l2-compat-ioctl32: simplify casts

 drivers/media/platform/Kconfig|   7 +-
 drivers/media/platform/omap3isp/isp.c |   8 +
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 641 ++
 include/linux/omap-iommu.h|   5 +
 4 files changed, 354 insertions(+), 307 deletions(-)

-- 
2.14.3

[PATCH v5 0/2] media: Introduce Omnivision OV2680 driver

[Rui Miguel Silva]

Add driver and bindings for the OV2680 2 megapixel CMOS 1/5" sensor, which has
a single MIPI lane interface and output format of 10-bit Raw RGB.

Features supported are described in PATCH 2/2.

v4->v5:
Fixes for v4l2-compliance tests:
- add init_cfg
- add some input arguments validations
- fix format_try set

v3->v4:
Sakari Ailus:
   - remove auto_{exposure|gain}_enable and direct call the set functions
   - add separe control sets to gain and exposure
   - fix number of controls allocated
   - check the exact frequency that it is supported

v2->v3:
Rob Herring:
- add Reviewed-by tag to dts PATCH 1/1

Sakari Ailus:
- align register values with bracket
- redone the {write|read}_reg i2c functions
- add bayer order handling with flip and mirror controls
- fix error path in probe release resources
- remove i2c_device_id and use probe_new

Myself:
- remove ; at the end of macros

v1->v2:
Fabio Estevam:
- s/OV5640/OV2680 in PATCH 1/2 changelog

Sakari Ailus:
- add description on endpoint properties in bindings
- add single endpoint in bindings
- drop OF dependency
- cleanup includes
- fix case in Color Bars
- remove frame rate selection
- 8/16/24 bit register access in the same transaction
- merge _reset and _soft_reset to _enable and rename it to power_on
- _gain_set use only the gain value (drop & 0x7ff)
- _gain_get remove the (0x377)
- single write/read at _exposure_set/get use write_reg24/read_reg24
- move mode_set_direct to _mode_set
- _mode_set set auto exposure/gain based on ctrl value
- s_frame_interval equal to g_frame_interval
- use closest match from: v4l: common: Add a function to obtain best size 
from a list
- check v4l2_ctrl_new_std return in _init

- fix gain manual value in auto_cluster

Cheers,
Rui


Rui Miguel Silva (2):
  media: ov2680: dt: Add bindings for OV2680
  media: ov2680: Add Omnivision OV2680 sensor driver

 .../devicetree/bindings/media/i2c/ov2680.txt  |   40 +
 drivers/media/i2c/Kconfig |   12 +
 drivers/media/i2c/Makefile|1 +
 drivers/media/i2c/ov2680.c| 1134 +
 4 files changed, 1187 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2680.txt
 create mode 100644 drivers/media/i2c/ov2680.c

-- 
2.17.0

[PATCH v5 1/2] media: ov2680: dt: Add bindings for OV2680

[Rui Miguel Silva]

Add device tree binding documentation for the OV2680 camera sensor.

Reviewed-by: Rob Herring 
CC: devicet...@vger.kernel.org
Signed-off-by: Rui Miguel Silva 
---
 .../devicetree/bindings/media/i2c/ov2680.txt  | 40 +++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2680.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov2680.txt 
b/Documentation/devicetree/bindings/media/i2c/ov2680.txt
new file mode 100644
index ..0e29f1a113c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2680.txt
@@ -0,0 +1,40 @@
+* Omnivision OV2680 MIPI CSI-2 sensor
+
+Required Properties:
+- compatible: should be "ovti,ov2680".
+- clocks: reference to the xvclk input clock.
+- clock-names: should be "xvclk".
+
+Optional Properties:
+- powerdown-gpios: reference to the GPIO connected to the powerdown pin,
+if any. This is an active high signal to the OV2680.
+
+The device node must contain one 'port' child node for its digital output
+video port, and this port must have a single endpoint in accordance with
+ the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Endpoint node required properties for CSI-2 connection are:
+- remote-endpoint: a phandle to the bus receiver's endpoint node.
+- clock-lanes: should be set to <0> (clock lane on hardware lane 0).
+- data-lanes: should be set to <1> (one CSI-2 lane supported).
+ 
+Example:
+
+ {
+   ov2680: camera-sensor@36 {
+   compatible = "ovti,ov2680";
+   reg = <0x36>;
+   clocks = <>;
+   clock-names = "xvclk";
+   powerdown-gpios = < 3 GPIO_ACTIVE_HIGH>;
+
+   port {
+   ov2680_mipi_ep: endpoint {
+   remote-endpoint = <_sensor_ep>;
+   clock-lanes = <0>;
+   data-lanes = <1>;
+   };
+   };
+   };
+};
-- 
2.17.0

[PATCH v5 2/2] media: ov2680: Add Omnivision OV2680 sensor driver

[Rui Miguel Silva]

This patch adds V4L2 sub-device driver for OV2680 image sensor.
The OV2680 is a 1/5" CMOS color sensor from Omnivision.
Supports output format: 10-bit Raw RGB.
The OV2680 has a single lane MIPI interface.

The driver exposes following V4L2 controls:
- auto/manual exposure,
- exposure,
- auto/manual gain,
- gain,
- horizontal/vertical flip,
- test pattern menu.
Supported resolution are only: QUXGA, 720P, UXGA.

Signed-off-by: Rui Miguel Silva 
---
 drivers/media/i2c/Kconfig  |   12 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov2680.c | 1134 
 3 files changed, 1147 insertions(+)
 create mode 100644 drivers/media/i2c/ov2680.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 541f0d28afd8..3a815825ad1b 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -606,6 +606,18 @@ config VIDEO_OV2659
  To compile this driver as a module, choose M here: the
  module will be called ov2659.
 
+config VIDEO_OV2680
+   tristate "OmniVision OV2680 sensor support"
+   depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
+   depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2680 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2680.
+
 config VIDEO_OV2685
tristate "OmniVision OV2685 sensor support"
depends on VIDEO_V4L2 && I2C && MEDIA_CONTROLLER
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index ea34aee1a85a..9539c0855e63 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
 obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
 obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
 obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
+obj-$(CONFIG_VIDEO_OV2680) += ov2680.o
 obj-$(CONFIG_VIDEO_OV2685) += ov2685.o
 obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
diff --git a/drivers/media/i2c/ov2680.c b/drivers/media/i2c/ov2680.c
new file mode 100644
index ..cc3d06096d51
--- /dev/null
+++ b/drivers/media/i2c/ov2680.c
@@ -0,0 +1,1134 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Omnivision OV2680 CMOS Image Sensor driver
+ *
+ * Copyright (C) 2018 Linaro Ltd
+ *
+ * Based on OV5640 Sensor Driver
+ * Copyright (C) 2011-2013 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright (C) 2014-2017 Mentor Graphics Inc.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define OV2680_XVCLK_VALUE 2400
+
+#define OV2680_CHIP_ID 0x2680
+
+#define OV2680_REG_STREAM_CTRL 0x0100
+#define OV2680_REG_SOFT_RESET  0x0103
+
+#define OV2680_REG_CHIP_ID_HIGH0x300a
+#define OV2680_REG_CHIP_ID_LOW 0x300b
+
+#define OV2680_REG_R_MANUAL0x3503
+#define OV2680_REG_GAIN_PK 0x350a
+#define OV2680_REG_EXPOSURE_PK_HIGH0x3500
+#define OV2680_REG_TIMING_HTS  0x380c
+#define OV2680_REG_TIMING_VTS  0x380e
+#define OV2680_REG_FORMAT1 0x3820
+#define OV2680_REG_FORMAT2 0x3821
+
+#define OV2680_REG_ISP_CTRL00  0x5080
+
+#define OV2680_FRAME_RATE  30
+
+#define OV2680_REG_VALUE_8BIT  1
+#define OV2680_REG_VALUE_16BIT 2
+#define OV2680_REG_VALUE_24BIT 3
+
+#define OV2680_WIDTH_MAX   1600
+#define OV2680_HEIGHT_MAX  1200
+
+enum ov2680_mode_id {
+   OV2680_MODE_QUXGA_800_600,
+   OV2680_MODE_720P_1280_720,
+   OV2680_MODE_UXGA_1600_1200,
+   OV2680_MODE_MAX,
+};
+
+struct reg_value {
+   u16 reg_addr;
+   u8 val;
+};
+
+struct ov2680_mode_info {
+   const char *name;
+   enum ov2680_mode_id id;
+   u32 width;
+   u32 height;
+   const struct reg_value *reg_data;
+   u32 reg_data_size;
+};
+
+struct ov2680_ctrls {
+   struct v4l2_ctrl_handler handler;
+   struct {
+   struct v4l2_ctrl *auto_exp;
+   struct v4l2_ctrl *exposure;
+   };
+   struct {
+   struct v4l2_ctrl *auto_gain;
+   struct v4l2_ctrl *gain;
+   };
+
+   struct v4l2_ctrl *hflip;
+   struct v4l2_ctrl *vflip;
+   struct v4l2_ctrl *test_pattern;
+};
+
+struct ov2680_dev {
+   struct i2c_client   *i2c_client;
+   struct v4l2_subdev  sd;
+
+   struct media_padpad;
+   struct clk  *xvclk;
+   u32 xvclk_freq;
+
+   struct gpio_desc*pwdn_gpio;
+   struct mutexlock; /* protect members */
+
+   boolmode_pending_changes;
+   bool

Re: [PATCH 0/5] Remaining COMPILE_TEST and smatch cleanups

[Mauro Carvalho Chehab]

Em Wed, 18 Apr 2018 12:04:14 +0300
Sakari Ailus  escreveu:

> On Tue, Apr 17, 2018 at 06:20:10AM -0400, Mauro Carvalho Chehab wrote:
> > There were several interactions at the COMPILE_TEST and smatch
> > patch series. While I applied most of them, there are 5 patches that
> > I kept out of it. The omap3 patch that were in my tree was the old
> > one. So, I'm re-posting it.
> > 
> > The ioctl32 patches are the latest version. Let's repost it to get some
> > acks, as this patch touches at V4L2 core, so a careful review is
> > always a good idea.
> > 
> > Arnd Bergmann (1):
> >   media: omap3isp: allow it to build with COMPILE_TEST
> > 
> > Laurent Pinchart (1):
> >   media: omap3isp: Enable driver compilation on ARM with COMPILE_TEST
> > 
> > Mauro Carvalho Chehab (3):
> >   omap: omap-iommu.h: allow building drivers with COMPILE_TEST
> >   media: v4l2-compat-ioctl32: fix several __user annotations
> >   media: v4l2-compat-ioctl32: better name userspace pointers
> > 
> >  drivers/media/platform/Kconfig|   7 +-
> >  drivers/media/platform/omap3isp/isp.c |   8 +
> >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 623 
> > +-
> >  include/linux/omap-iommu.h|   5 +
> >  4 files changed, 338 insertions(+), 305 deletions(-)  
> 
> For patches 1 and 2:
> 
> Acked-by: Sakari Ailus 

What about patch 3?

> 
> I'd like to see a new versions of patches 4 and 5; I agree on the naming
> change.

With what changes?

> Could you set the To: header to a valid value going forward? It's not a
> valid e-mail address but still contains "<" character which causes trouble
> when replying to the patches.

I've no idea how to fix it. When I submit patches, I don't add any To:
header (as the "to" is meant to be the one that will apply the patches...
sending an e-mail to myself seems too mad for my taste). Somewhere
between git-send-email, my SMTP local host or the SMTP smart gateway,
or something afterwards, a "fake" To: gets introduced.


Thanks,
Mauro

Re: [PATCH v2 01/12] media: ov5640: Add auto-focus feature

[Laurent Pinchart]

Hi Maxime,

Thank you for the patch.

On Monday, 16 April 2018 15:36:50 EEST Maxime Ripard wrote:
> From: Mylène Josserand 
> 
> Add the auto-focus ENABLE/DISABLE feature as V4L2 control.
> Disabled by default.
> 
> Signed-off-by: Mylène Josserand 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/media/i2c/ov5640.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 852026baa2e7..a33e45f8e2b0 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -82,8 +82,9 @@
>  #define OV5640_REG_POLARITY_CTRL00   0x4740
>  #define OV5640_REG_MIPI_CTRL00   0x4800
>  #define OV5640_REG_DEBUG_MODE0x4814
> -#define OV5640_REG_ISP_FORMAT_MUX_CTRL   0x501f
> +#define OV5640_REG_ISP_CTRL030x5003
>  #define OV5640_REG_PRE_ISP_TEST_SET1 0x503d
> +#define OV5640_REG_ISP_FORMAT_MUX_CTRL   0x501f
>  #define OV5640_REG_SDE_CTRL0 0x5580
>  #define OV5640_REG_SDE_CTRL1 0x5581
>  #define OV5640_REG_SDE_CTRL3 0x5583
> @@ -186,6 +187,7 @@ struct ov5640_ctrls {
>   struct v4l2_ctrl *auto_gain;
>   struct v4l2_ctrl *gain;
>   };
> + struct v4l2_ctrl *auto_focus;
>   struct v4l2_ctrl *brightness;
>   struct v4l2_ctrl *saturation;
>   struct v4l2_ctrl *contrast;
> @@ -2155,6 +2157,12 @@ static int ov5640_set_ctrl_test_pattern(struct
> ov5640_dev *sensor, int value) 0xa4, value ? 0xa4 : 0);
>  }
> 
> +static int ov5640_set_ctrl_focus(struct ov5640_dev *sensor, int value)
> +{
> + return ov5640_mod_reg(sensor, OV5640_REG_ISP_CTRL03,
> +   BIT(1), value ? BIT(1) : 0);

According to the datasheet, bit 1 in register 0x5003 is "Draw window for AFC 
enable". The draw window module is further documented as being "used to 
display a window on top of live video. It is usually used by autofocus to 
display a focus window". Are you sure the bit controls the autofocus itself ?

Furthermore, do all 0V5640 camera modules include a VCM ?

> +}
> +
>  static int ov5640_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
>  {
>   struct v4l2_subdev *sd = ctrl_to_sd(ctrl);
> @@ -2223,6 +2231,9 @@ static int ov5640_s_ctrl(struct v4l2_ctrl *ctrl)
>   case V4L2_CID_TEST_PATTERN:
>   ret = ov5640_set_ctrl_test_pattern(sensor, ctrl->val);
>   break;
> + case V4L2_CID_FOCUS_AUTO:
> + ret = ov5640_set_ctrl_focus(sensor, ctrl->val);
> + break;
>   default:
>   ret = -EINVAL;
>   break;
> @@ -2285,6 +2296,9 @@ static int ov5640_init_controls(struct ov5640_dev
> *sensor) ARRAY_SIZE(test_pattern_menu) - 1,
>0, 0, test_pattern_menu);
> 
> + ctrls->auto_focus = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_AUTO,
> +   0, 1, 1, 0);
> +
>   if (hdl->error) {
>   ret = hdl->error;
>   goto free_ctrls;

-- 
Regards,

Laurent Pinchart

[PATCH 01/15] media: staging/imx: add support to media dev for no IPU systems

[Rui Miguel Silva]

Some i.MX SoC do not have IPU, like the i.MX7, add to the the media device
infrastructure support to be used in this type of systems that do not have
internal subdevices besides the CSI.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/imx-media-dev.c| 16 +++-
 .../staging/media/imx/imx-media-internal-sd.c|  3 +++
 drivers/staging/media/imx/imx-media.h|  3 +++
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
index f67ec8e27093..a8afe0ec4134 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -92,6 +92,9 @@ static int imx_media_get_ipu(struct imx_media_dev *imxmd,
struct ipu_soc *ipu;
int ipu_id;
 
+   if (imxmd->no_ipu_present)
+   return 0;
+
ipu = dev_get_drvdata(csi_sd->dev->parent);
if (!ipu) {
v4l2_err(>v4l2_dev,
@@ -481,16 +484,19 @@ static int imx_media_probe(struct platform_device *pdev)
goto notifier_cleanup;
}
 
-   ret = imx_media_add_internal_subdevs(imxmd);
-   if (ret) {
-   v4l2_err(>v4l2_dev,
-"add_internal_subdevs failed with %d\n", ret);
-   goto notifier_cleanup;
+   if (!imxmd->no_ipu_present) {
+   ret = imx_media_add_internal_subdevs(imxmd);
+   if (ret) {
+   v4l2_err(>v4l2_dev,
+"add_internal_subdevs failed with %d\n", ret);
+   goto notifier_cleanup;
+   }
}
 
/* no subdevs? just bail */
if (imxmd->notifier.num_subdevs == 0) {
ret = -ENODEV;
+   v4l2_err(>v4l2_dev, "no subdevs\n");
goto notifier_cleanup;
}
 
diff --git a/drivers/staging/media/imx/imx-media-internal-sd.c 
b/drivers/staging/media/imx/imx-media-internal-sd.c
index 0fdc45dbfb76..4a246813b4e1 100644
--- a/drivers/staging/media/imx/imx-media-internal-sd.c
+++ b/drivers/staging/media/imx/imx-media-internal-sd.c
@@ -238,6 +238,9 @@ int imx_media_create_internal_links(struct imx_media_dev 
*imxmd,
struct media_pad *pad;
int i, j, ret;
 
+   if (imxmd->no_ipu_present)
+   return 0;
+
intsd = find_intsd_by_grp_id(sd->grp_id);
if (!intsd)
return -ENODEV;
diff --git a/drivers/staging/media/imx/imx-media.h 
b/drivers/staging/media/imx/imx-media.h
index 44532cd5b812..0c63132861a0 100644
--- a/drivers/staging/media/imx/imx-media.h
+++ b/drivers/staging/media/imx/imx-media.h
@@ -147,6 +147,9 @@ struct imx_media_dev {
 
/* for async subdev registration */
struct v4l2_async_notifier notifier;
+
+   /* indicator to if the system lack IPU */
+   bool no_ipu_present;
 };
 
 enum codespace_sel {
-- 
2.17.0

[PATCH 15/15] media: staging/imx: add i.MX7 entries to TODO file

[Rui Miguel Silva]

Add some i.MX7 related entries to TODO file.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/TODO | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/staging/media/imx/TODO b/drivers/staging/media/imx/TODO
index aeeb15494a49..6f29b5ca5324 100644
--- a/drivers/staging/media/imx/TODO
+++ b/drivers/staging/media/imx/TODO
@@ -45,3 +45,12 @@
 
  Which means a port must not contain mixed-use endpoints, they
  must all refer to media links between V4L2 subdevices.
+
+- i.MX7: all of the above, since it uses the imx media core
+
+- i.MX7: use Frame Interval Monitor
+
+- i.MX7: runtime testing with parallel sensor, links setup and streaming
+
+- i.MX7: runtime testing with different formats, for the time only 10-bit bayer
+  is tested
-- 
2.17.0

[PATCH 02/15] media: staging/imx7: add imx7 CSI subdev driver

[Rui Miguel Silva]

This add the media entity subdevice and control driver for the i.MX7 CMOS Sensor
Interface.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/Kconfig  |9 +-
 drivers/staging/media/imx/Makefile |2 +
 drivers/staging/media/imx/imx7-media-csi.c | 1327 
 3 files changed, 1337 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/media/imx/imx7-media-csi.c

diff --git a/drivers/staging/media/imx/Kconfig 
b/drivers/staging/media/imx/Kconfig
index bfc17de56b17..40a11f988fc6 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -11,7 +11,7 @@ config VIDEO_IMX_MEDIA
  driver for the i.MX5/6 SOC.
 
 if VIDEO_IMX_MEDIA
-menu "i.MX5/6 Media Sub devices"
+menu "i.MX5/6/7 Media Sub devices"
 
 config VIDEO_IMX_CSI
tristate "i.MX5/6 Camera Sensor Interface driver"
@@ -20,5 +20,12 @@ config VIDEO_IMX_CSI
---help---
  A video4linux camera sensor interface driver for i.MX5/6.
 
+config VIDEO_IMX7_CSI
+   tristate "i.MX7 Camera Sensor Interface driver"
+   depends on VIDEO_IMX_MEDIA && VIDEO_DEV && I2C
+   default y
+   ---help---
+ A video4linux camera sensor interface driver for i.MX7.
+
 endmenu
 endif
diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index 698a4210316e..771846717146 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-ic.o
 
 obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
 obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o
+
+obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o
diff --git a/drivers/staging/media/imx/imx7-media-csi.c 
b/drivers/staging/media/imx/imx7-media-csi.c
new file mode 100644
index ..167043869419
--- /dev/null
+++ b/drivers/staging/media/imx/imx7-media-csi.c
@@ -0,0 +1,1327 @@
+// SPDX-License-Identifier: GPL
+/*
+ * V4L2 Capture CSI Subdev for Freescale i.MX7 SOC
+ *
+ * Copyright (c) 2018 Linaro Ltd
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "imx-media.h"
+
+#define IMX7_CSI_PAD_SINK  0
+#define IMX7_CSI_PAD_SRC   1
+#define IMX7_CSI_PADS_NUM  2
+
+/* reset values */
+#define CSICR1_RESET_VAL   0x4800
+#define CSICR2_RESET_VAL   0x0
+#define CSICR3_RESET_VAL   0x0
+
+/* csi control reg 1 */
+#define BIT_SWAP16_EN  BIT(31)
+#define BIT_EXT_VSYNC  BIT(30)
+#define BIT_EOF_INT_EN BIT(29)
+#define BIT_PRP_IF_EN  BIT(28)
+#define BIT_CCIR_MODE  BIT(27)
+#define BIT_COF_INT_EN BIT(26)
+#define BIT_SF_OR_INTENBIT(25)
+#define BIT_RF_OR_INTENBIT(24)
+#define BIT_SFF_DMA_DONE_INTEN  BIT(22)
+#define BIT_STATFF_INTEN   BIT(21)
+#define BIT_FB2_DMA_DONE_INTEN  BIT(20)
+#define BIT_FB1_DMA_DONE_INTEN  BIT(19)
+#define BIT_RXFF_INTEN BIT(18)
+#define BIT_SOF_POLBIT(17)
+#define BIT_SOF_INTEN  BIT(16)
+#define BIT_MCLKDIV(0xF << 12)
+#define BIT_HSYNC_POL  BIT(11)
+#define BIT_CCIR_ENBIT(10)
+#define BIT_MCLKEN BIT(9)
+#define BIT_FCCBIT(8)
+#define BIT_PACK_DIR   BIT(7)
+#define BIT_CLR_STATFIFO   BIT(6)
+#define BIT_CLR_RXFIFO BIT(5)
+#define BIT_GCLK_MODE  BIT(4)
+#define BIT_INV_DATA   BIT(3)
+#define BIT_INV_PCLK   BIT(2)
+#define BIT_REDGE  BIT(1)
+#define BIT_PIXEL_BIT  BIT(0)
+
+#define SHIFT_MCLKDIV  12
+
+/* control reg 3 */
+#define BIT_FRMCNT (0x << 16)
+#define BIT_FRMCNT_RST BIT(15)
+#define BIT_DMA_REFLASH_RFFBIT(14)
+#define BIT_DMA_REFLASH_SFFBIT(13)
+#define BIT_DMA_REQ_EN_RFF BIT(12)
+#define BIT_DMA_REQ_EN_SFF BIT(11)
+#define BIT_STATFF_LEVEL   (0x7 << 8)
+#define BIT_HRESP_ERR_EN   BIT(7)
+#define BIT_RXFF_LEVEL (0x7 << 4)
+#define BIT_TWO_8BIT_SENSORBIT(3)
+#define BIT_ZERO_PACK_EN   BIT(2)
+#define BIT_ECC_INT_EN BIT(1)
+#define BIT_ECC_AUTO_ENBIT(0)
+
+#define SHIFT_FRMCNT   16
+#define SHIFT_RXFIFO_LEVEL 4
+
+/* csi status reg */
+#define BIT_ADDR_CH_ERR_INTBIT(28)
+#define BIT_FIELD0_INT BIT(27)
+#define BIT_FIELD1_INT BIT(26)
+#define BIT_SFF_OR_INT BIT(25)
+#define BIT_RFF_OR_INT BIT(24)
+#define BIT_DMA_TSF_DONE_SFF   BIT(22)
+#define BIT_STATFF_INT BIT(21)
+#define BIT_DMA_TSF_DONE_FB2   BIT(20)
+#define BIT_DMA_TSF_DONE_FB1   BIT(19)
+#define BIT_RXFF_INT   BIT(18)
+#define BIT_EOF_INTBIT(17)
+#define BIT_SOF_INTBIT(16)
+#define BIT_F2_INT BIT(15)
+#define BIT_F1_INT BIT(14)
+#define 

[PATCH 10/15] ARM: dts: imx7s: add mipi phy power domain

[Rui Miguel Silva]

Add power domain index 0 related with mipi-phy to imx7s.

Signed-off-by: Rui Miguel Silva 
---
 arch/arm/boot/dts/imx7s.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 142ea709d296..d913c3f9c284 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -650,6 +650,12 @@
#address-cells = <1>;
#size-cells = <0>;
 
+   pgc_mipi_phy: pgc-power-domain@0 {
+   #power-domain-cells = <0>;
+   reg = <0>;
+   power-supply = <_1p0d>;
+   };
+
pgc_pcie_phy: pgc-power-domain@1 {
#power-domain-cells = <0>;
reg = <1>;
-- 
2.17.0

[PATCH 04/15] clk: imx7d: reset parent for mipi csi root

[Rui Miguel Silva]

To guarantee that we do not get Overflow in image FIFO the outer bandwidth has
to be faster than inputer bandwidth. For that it must be possible to set a
faster frequency clock. So set new parent to sys_pfd3 clock for the mipi csi
block.

Signed-off-by: Rui Miguel Silva 
---
 drivers/clk/imx/clk-imx7d.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index f7f4db2e6fa6..9a1a18ceb132 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -891,6 +891,9 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clk_set_parent(clks[IMX7D_PLL_AUDIO_MAIN_BYPASS], 
clks[IMX7D_PLL_AUDIO_MAIN]);
clk_set_parent(clks[IMX7D_PLL_VIDEO_MAIN_BYPASS], 
clks[IMX7D_PLL_VIDEO_MAIN]);
 
+   clk_set_parent(clks[IMX7D_MIPI_CSI_ROOT_SRC],
+  clks[IMX7D_PLL_SYS_PFD3_CLK]);
+
/* use old gpt clk setting, gpt1 root clk must be twice as gpt counter 
freq */
clk_set_parent(clks[IMX7D_GPT1_ROOT_SRC], clks[IMX7D_OSC_24M_CLK]);
 
-- 
2.17.0

[PATCH 06/15] media: staging/imx: add imx7 capture subsystem

[Rui Miguel Silva]

Add imx7 capture subsystem to imx-media core to allow the use some of the
existing modules for i.MX5/6 with i.MX7 SoC.

Since i.MX7 does not have an IPU set the no_ipu_present flag to differentiate
some runtime behaviors.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/imx-media-dev.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
index a8afe0ec4134..967d172f1447 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -484,6 +484,9 @@ static int imx_media_probe(struct platform_device *pdev)
goto notifier_cleanup;
}
 
+   if (of_device_is_compatible(node, "fsl,imx7-capture-subsystem"))
+   imxmd->no_ipu_present = true;
+
if (!imxmd->no_ipu_present) {
ret = imx_media_add_internal_subdevs(imxmd);
if (ret) {
@@ -541,6 +544,7 @@ static int imx_media_remove(struct platform_device *pdev)
 
 static const struct of_device_id imx_media_dt_ids[] = {
{ .compatible = "fsl,imx-capture-subsystem" },
+   { .compatible = "fsl,imx7-capture-subsystem" },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, imx_media_dt_ids);
-- 
2.17.0

[PATCH 11/15] ARM: dts: imx7s: add multiplexer controls

[Rui Miguel Silva]

The IOMUXC General Purpose Register has bitfield to control video bus
multiplexer to control the CSI input between the MIPI-CSI2 and parallel
interface. Add that register and mask.

Signed-off-by: Rui Miguel Silva 
---
 arch/arm/boot/dts/imx7s.dtsi | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index d913c3f9c284..3027d6a62021 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -534,8 +534,15 @@
 
gpr: iomuxc-gpr@3034 {
compatible = "fsl,imx7d-iomuxc-gpr",
-   "fsl,imx6q-iomuxc-gpr", "syscon";
+   "fsl,imx6q-iomuxc-gpr", "syscon", 
"simple-mfd";
reg = <0x3034 0x1>;
+
+   mux: mux-controller {
+   compatible = "mmio-mux";
+   #mux-control-cells = <1>;
+
+   mux-reg-masks = <0x14 0x0010>;
+   };
};
 
ocotp: ocotp-ctrl@3035 {
-- 
2.17.0

[PATCH 05/15] media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7

[Rui Miguel Silva]

Adds MIPI CSI-2 subdev for i.MX7 to connect with sensors with a MIPI CSI-2
interface.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/Makefile |1 +
 drivers/staging/media/imx/imx7-mipi-csis.c | 1154 
 2 files changed, 1155 insertions(+)
 create mode 100644 drivers/staging/media/imx/imx7-mipi-csis.c

diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index 771846717146..c11d51259af1 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
 obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o
 
 obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o
+obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-mipi-csis.o
diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c 
b/drivers/staging/media/imx/imx7-mipi-csis.c
new file mode 100644
index ..45c5f442ac8e
--- /dev/null
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -0,0 +1,1154 @@
+// SPDX-License-Identifier: GPL
+/*
+ * Freescale i.MX7 SoC series MIPI-CSI V3.3 receiver driver
+ *
+ * Copyright (C) 2018 Linaro Ltd
+ * Copyright (C) 2015-2016 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright (C) 2011 - 2013 Samsung Electronics Co., Ltd.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "imx-media.h"
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Debug level (0-2)");
+
+#define CSIS_DRIVER_NAME   "imx7-mipi-csis"
+#define CSIS_SUBDEV_NAME   CSIS_DRIVER_NAME
+
+#define CSIS_PAD_SINK  0
+#define CSIS_PAD_SOURCE1
+#define CSIS_PADS_NUM  2
+
+#define MIPI_CSIS_DEF_PIX_WIDTH640
+#define MIPI_CSIS_DEF_PIX_HEIGHT   480
+
+/* Register map definition */
+
+/* CSIS common control */
+#define MIPI_CSIS_CMN_CTRL 0x04
+#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW   BIT(16)
+#define MIPI_CSIS_CMN_CTRL_INTER_MODE  BIT(10)
+#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW_CTRL  BIT(2)
+#define MIPI_CSIS_CMN_CTRL_RESET   BIT(1)
+#define MIPI_CSIS_CMN_CTRL_ENABLE  BIT(0)
+
+#define MIPI_CSIS_CMN_CTRL_LANE_NR_OFFSET  8
+#define MIPI_CSIS_CMN_CTRL_LANE_NR_MASK(3 << 8)
+
+/* CSIS clock control */
+#define MIPI_CSIS_CLK_CTRL 0x08
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH3(x)(x << 28)
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH2(x)(x << 24)
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH1(x)(x << 20)
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH0(x)(x << 16)
+#define MIPI_CSIS_CLK_CTRL_CLKGATE_EN_MSK  (0xf << 4)
+#define MIPI_CSIS_CLK_CTRL_WCLK_SRCBIT(0)
+
+/* CSIS Interrupt mask */
+#define MIPI_CSIS_INTMSK   0x10
+#define MIPI_CSIS_INTMSK_EVEN_BEFORE   BIT(31)
+#define MIPI_CSIS_INTMSK_EVEN_AFTERBIT(30)
+#define MIPI_CSIS_INTMSK_ODD_BEFOREBIT(29)
+#define MIPI_CSIS_INTMSK_ODD_AFTER BIT(28)
+#define MIPI_CSIS_INTMSK_FRAME_START   BIT(24)
+#define MIPI_CSIS_INTMSK_FRAME_END BIT(20)
+#define MIPI_CSIS_INTMSK_ERR_SOT_HSBIT(16)
+#define MIPI_CSIS_INTMSK_ERR_LOST_FS   BIT(12)
+#define MIPI_CSIS_INTMSK_ERR_LOST_FE   BIT(8)
+#define MIPI_CSIS_INTMSK_ERR_OVER  BIT(4)
+#define MIPI_CSIS_INTMSK_ERR_WRONG_CFG BIT(3)
+#define MIPI_CSIS_INTMSK_ERR_ECC   BIT(2)
+#define MIPI_CSIS_INTMSK_ERR_CRC   BIT(1)
+#define MIPI_CSIS_INTMSK_ERR_UNKNOWN   BIT(0)
+
+/* CSIS Interrupt source */
+#define MIPI_CSIS_INTSRC   0x14
+#define MIPI_CSIS_INTSRC_EVEN_BEFORE   BIT(31)
+#define MIPI_CSIS_INTSRC_EVEN_AFTERBIT(30)
+#define MIPI_CSIS_INTSRC_EVEN  BIT(30)
+#define MIPI_CSIS_INTSRC_ODD_BEFOREBIT(29)
+#define MIPI_CSIS_INTSRC_ODD_AFTER BIT(28)
+#define MIPI_CSIS_INTSRC_ODD   (0x3 << 28)
+#define MIPI_CSIS_INTSRC_NON_IMAGE_DATA(0xf << 28)
+#define MIPI_CSIS_INTSRC_FRAME_START   BIT(24)
+#define MIPI_CSIS_INTSRC_FRAME_END BIT(20)
+#define MIPI_CSIS_INTSRC_ERR_SOT_HSBIT(16)
+#define MIPI_CSIS_INTSRC_ERR_LOST_FS   BIT(12)
+#define MIPI_CSIS_INTSRC_ERR_LOST_FE   BIT(8)
+#define MIPI_CSIS_INTSRC_ERR_OVER  BIT(4)
+#define MIPI_CSIS_INTSRC_ERR_WRONG_CFG BIT(3)
+#define MIPI_CSIS_INTSRC_ERR_ECC   BIT(2)
+#define MIPI_CSIS_INTSRC_ERR_CRC   BIT(1)
+#define MIPI_CSIS_INTSRC_ERR_UNKNOWN   BIT(0)
+#define MIPI_CSIS_INTSRC_ERRORS0xf
+
+/* D-PHY status control */
+#define MIPI_CSIS_DPHYSTATUS   0x20
+#define MIPI_CSIS_DPHYSTATUS_ULPS_DAT  BIT(8)
+#define MIPI_CSIS_DPHYSTATUS_STOPSTATE_DAT BIT(4)
+#define MIPI_CSIS_DPHYSTATUS_ULPS_CLK  BIT(1)
+#define MIPI_CSIS_DPHYSTATUS_STOPSTATE_CLK BIT(0)
+
+/* D-PHY common control */
+#define MIPI_CSIS_DPHYCTRL

[PATCH 13/15] ARM: dts: imx7s: add capture subsystem

[Rui Miguel Silva]

Add media capture subsystem device to i.MX7 definitions.

Signed-off-by: Rui Miguel Silva 
---
 arch/arm/boot/dts/imx7s.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 6b49b73053f9..333d9fe6b989 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -1189,4 +1189,9 @@
assigned-clock-parents = < 
IMX7D_PLL_ENET_MAIN_500M_CLK>;
};
};
+
+   capture-subsystem {
+   compatible = "fsl,imx7-capture-subsystem";
+   ports = <>;
+   };
 };
-- 
2.17.0

[PATCH 09/15] media: dt-bindings: add bindings for i.MX7 media driver

[Rui Miguel Silva]

Add bindings documentation for i.MX7 media drivers.

Signed-off-by: Rui Miguel Silva 
---
 .../devicetree/bindings/media/imx7.txt| 158 ++
 1 file changed, 158 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/imx7.txt

diff --git a/Documentation/devicetree/bindings/media/imx7.txt 
b/Documentation/devicetree/bindings/media/imx7.txt
new file mode 100644
index ..7e058ea25102
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx7.txt
@@ -0,0 +1,158 @@
+Freescale i.MX7 Media Video Device
+==
+
+Video Media Controller node
+---
+
+This is the media controller node for video capture support. It is a
+virtual device that lists the camera serial interface nodes that the
+media device will control.
+
+Required properties:
+- compatible : "fsl,imx7-capture-subsystem";
+- ports  : Should contain a list of phandles pointing to camera
+   sensor interface port of CSI
+
+example:
+
+capture-subsystem {
+   compatible = "fsl,imx7-capture-subsystem";
+   ports = <>;
+};
+
+
+mipi_csi2 node
+--
+
+This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
+compatible with previous version of Samsung D-phy.
+
+Required properties:
+
+- compatible: "fsl,imx7-mipi-csi2";
+- reg   : base address and length of the register set for the device;
+- interrupts: should contain MIPI CSIS interrupt;
+- clocks: list of clock specifiers, see
+Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
+- clock-names   : must contain "mipi" and "phy" entries, matching entries in 
the
+  clock property;
+- power-domains : a phandle to the power domain, see
+  Documentation/devicetree/bindings/power/power_domain.txt for details.
+- reset-names   : should include following entry "mrst";
+- resets: a list of phandle, should contain reset entry of
+  reset-names;
+- phy-supply: from the generic phy bindings, a phandle to a regulator that
+ provides power to VBUS;
+- bus-width : maximum number of data lanes supported (SoC specific);
+
+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
+   value when this property is not specified is 166 MHz;
+
+port node
+-
+
+- reg: (required) can take the values 0 or 1, where 0 is the
+ related sink port and port 1 should be the source one;
+
+endpoint node
+-
+
+- data-lanes: (required) an array specifying active physical MIPI-CSI2
+   data input lanes and their mapping to logical lanes; the
+   array's content is unused, only its length is meaningful;
+
+- csis-hs-settle : (optional) differential receiver (HS-RX) settle time;
+- csis-clk-settle : (optional) D-PHY control register;
+- csis-wclk : CSI-2 wrapper clock selection. If this property is present
+ external clock from CMU will be used, or the bus clock if
+ if it's not specified.
+
+example:
+
+   mipi_csi: mipi-csi@3075 {
+clock-frequency = <16600>;
+status = "okay";
+#address-cells = <1>;
+#size-cells = <0>;
+
+   compatible = "fsl,imx7-mipi-csi2";
+   reg = <0x3075 0x1>;
+   interrupts = ;
+   clocks = < IMX7D_MIPI_CSI_ROOT_CLK>,
+   < IMX7D_MIPI_DPHY_ROOT_CLK>;
+   clock-names = "mipi", "phy";
+   power-domains = <_mipi_phy>;
+   phy-supply = <_1p0d>;
+   resets = < IMX7_RESET_MIPI_PHY_MRST>;
+   reset-names = "mrst";
+   bus-width = <4>;
+   status = "disabled";
+
+port@0 {
+reg = <0>;
+
+mipi_from_sensor: endpoint {
+remote-endpoint = <_to_mipi>;
+data-lanes = <1>;
+csis-hs-settle = <3>;
+csis-clk-settle = <0>;
+csis-wclk;
+};
+};
+
+port@1 {
+reg = <1>;
+
+mipi_vc0_to_csi_mux: endpoint {
+remote-endpoint = <_mux_from_mipi_vc0>;
+};
+};
+   };
+
+
+csi node
+
+
+This is device node for the CMOS Sensor Interface (CSI) which enables the chip
+to connect directly to external CMOS image sensors.
+
+Required properties:
+
+- compatible: "fsl,imx7-csi";
+- reg   : base address and length of the register set for the device;
+- interrupts: should contain CSI interrupt;
+- clocks: list 

[PATCH 08/15] ARM: dts: increase default cma size to 40MB

[Rui Miguel Silva]

To support camera in i.MX7 the cma heap is used to allocate frame buffers. The
default size of CMA is 16MB which is not enough for higher resolutions (ex:
1600x1200).

So, increase the default CMA size to 40MB.

Signed-off-by: Rui Miguel Silva 
---
 arch/arm/boot/dts/imx7s.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 4d42335c0dee..142ea709d296 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -182,6 +182,20 @@
 ;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   /* global autoconfigured region for contiguous allocations */
+   linux,cma {
+   compatible = "shared-dma-pool";
+   reusable;
+   size = <0x280>;
+   linux,cma-default;
+   };
+   };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
-- 
2.17.0

[PATCH 00/15] media: staging/imx7: add i.MX7 media driver

[Rui Miguel Silva]

*** BLURB HERE ***
Hi,
This series introduces the Media driver to work with the i.MX7 SoC. it uses the
already existing imx media core drivers but since the i.MX7, contrary to
i.MX5/6, do not have an IPU and because of that some changes in the imx media
core are made along this series to make it support that case.

This patches adds CSI and MIPI-CSI2 drivers for i.MX7, along with several
configurations changes for this to work as a capture subsystem. Some bugs are
also fixed along the line. And necessary documentation.

For a more detailed view of the capture paths, pads links in the i.MX7 please
take a look at the documentation in PATCH 14.

The system used to test and develop this was the Warp7 board with an OV2680
sensor, which output format is 10-bit bayer. So, only MIPI interface was
tested, a scenario with an parallel input would nice to have.

*Important note*, this code depends on Steve Longerbeam series [0]:
[PATCH v3 00/13] media: imx: Switch to subdev notifiers
which the merging status is not clear to me, but the changes in there make
senses to this series

Bellow goes an example of the output of the pads and links and the output of
v4l2-compliance testing.

The v4l-utils version used is:
v4l2-compliance SHA   : 47d43b130dc6e9e0edc900759fb37649208371e4 from Apr 4th.

The Media Driver fail some tests but this failures are coming from code out of
scope of this series (video-mux, imx-capture), and some from the sensor OV2680
but that I think not related with the sensor driver but with the testing and
core.

The csi and mipi-csi entities pass all compliance tests.

Cheers,
Rui
[0]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg128015.html

 media-ctl -p
Media controller API version 4.17.0

Media device information

driver  imx-media
model   imx-media
serial  
bus info
hw revision 0x0
driver version  4.17.0

Device topology
- entity 1: csi (2 pads, 2 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
pad0: Sink
[fmt:SBGGR10_1X10/800x600 field:none]
<- "csi_mux":2 [ENABLED]
pad1: Source
[fmt:SBGGR10_1X10/800x600 field:none]
-> "csi capture":0 [ENABLED]

- entity 4: csi capture (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "csi":1 [ENABLED]

- entity 10: csi_mux (3 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev1
pad0: Sink
[fmt:unknown/0x0]
pad1: Sink
[fmt:SBGGR10_1X10/800x600 field:none]
<- "imx7-mipi-csis.0":1 [ENABLED]
pad2: Source
[fmt:SBGGR10_1X10/800x600 field:none]
-> "csi":0 [ENABLED]

- entity 14: imx7-mipi-csis.0 (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev2
pad0: Sink
[fmt:SBGGR10_1X10/800x600 field:none]
<- "ov2680 1-0036":0 [ENABLED]
pad1: Source
[fmt:SBGGR10_1X10/800x600 field:none]
-> "csi_mux":1 [ENABLED]

- entity 17: ov2680 1-0036 (1 pad, 1 link)
 type V4L2 subdev subtype Sensor flags 0
 device node name /dev/v4l-subdev3
pad0: Source
[fmt:SBGGR10_1X10/800x600 field:none]
-> "imx7-mipi-csis.0":0 [ENABLED]

compliance tests:
v4l2-compliance SHA   : 47d43b130dc6e9e0edc900759fb37649208371e4

Compliance test for device /dev/media0:

Media Driver Info:
Driver name  : imx-media
Model: imx-media
Serial   : 
Bus info : 
Media version: 4.17.0
Hardware revision: 0x (0)
Driver version   : 4.17.0

Required ioctls:
test MEDIA_IOC_DEVICE_INFO: OK

Allow for multiple opens:
test second /dev/media0 open: OK
test MEDIA_IOC_DEVICE_INFO: OK
test for unlimited opens: OK

Media Controller ioctls:
Entity: 0x0001 (Name: 'csi', Function: 0x5002)
Entity: 0x0004 (Name: 'csi capture', Function: 0x00010001)
Entity: 0x000a (Name: 'csi_mux', Function: 0x5001)
Entity: 0x000e (Name: 'imx7-mipi-csis.0', Function: 
0x5002)
Entity: 0x0011 (Name: 'ov2680 1-0036', Function: 0x00020001)
Interface: 0x0305 (Type: 0x0200)
Interface: 0x0319 (Type: 0x0203)
Interface: 0x031b (Type: 0x0203)
Interface: 0x031d (Type: 0x0203)
Interface: 0x031f (Type: 0x0203)
Pad: 0x0102
Pad: 0x0103
Pad: 0x0107
Pad: 0x010b

[PATCH 03/15] clk: imx7d: fix mipi dphy div parent

[Rui Miguel Silva]

Fix the mipi dphy root divider to mipi_dphy_pre_div, this would remove a orphan
clock and set the correct parent.

before:
cat clk_orphan_summary
 enable  prepare  protect
   clock  countcountcountrate   
accuracy   phase

 mipi_dphy_post_div   110   0  
0 0
mipi_dphy_root_clk110   0  
0 0

cat clk_dump | grep mipi_dphy
mipi_dphy_post_div110   0  
0 0
mipi_dphy_root_clk110   0  
0 0

after:
cat clk_dump | grep mipi_dphy
   mipi_dphy_src 1102400  0 0
   mipi_dphy_cg  1102400  0 0
  mipi_dphy_pre_div  1102400  0 0
 mipi_dphy_post_div  1102400  0 0
mipi_dphy_root_clk   1102400  0 0

Signed-off-by: Rui Miguel Silva 

Signed-off-by: Rui Miguel Silva 
---
 drivers/clk/imx/clk-imx7d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 975a20d3cc94..f7f4db2e6fa6 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -729,7 +729,7 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clks[IMX7D_LCDIF_PIXEL_ROOT_DIV] = 
imx_clk_divider2("lcdif_pixel_post_div", "lcdif_pixel_pre_div", base + 0xa300, 
0, 6);
clks[IMX7D_MIPI_DSI_ROOT_DIV] = imx_clk_divider2("mipi_dsi_post_div", 
"mipi_dsi_pre_div", base + 0xa380, 0, 6);
clks[IMX7D_MIPI_CSI_ROOT_DIV] = imx_clk_divider2("mipi_csi_post_div", 
"mipi_csi_pre_div", base + 0xa400, 0, 6);
-   clks[IMX7D_MIPI_DPHY_ROOT_DIV] = imx_clk_divider2("mipi_dphy_post_div", 
"mipi_csi_dphy_div", base + 0xa480, 0, 6);
+   clks[IMX7D_MIPI_DPHY_ROOT_DIV] = imx_clk_divider2("mipi_dphy_post_div", 
"mipi_dphy_pre_div", base + 0xa480, 0, 6);
clks[IMX7D_SAI1_ROOT_DIV] = imx_clk_divider2("sai1_post_div", 
"sai1_pre_div", base + 0xa500, 0, 6);
clks[IMX7D_SAI2_ROOT_DIV] = imx_clk_divider2("sai2_post_div", 
"sai2_pre_div", base + 0xa580, 0, 6);
clks[IMX7D_SAI3_ROOT_DIV] = imx_clk_divider2("sai3_post_div", 
"sai3_pre_div", base + 0xa600, 0, 6);
-- 
2.17.0

[PATCH 07/15] media: staging/imx: add 10 bit bayer support

[Rui Miguel Silva]

Some sensors can only output 10 bit bayer formats, like the OV2680. Add support
for that in imx-media.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/imx-media-utils.c | 24 +
 1 file changed, 24 insertions(+)

diff --git a/drivers/staging/media/imx/imx-media-utils.c 
b/drivers/staging/media/imx/imx-media-utils.c
index fab98fc0d6a0..99527daba29a 100644
--- a/drivers/staging/media/imx/imx-media-utils.c
+++ b/drivers/staging/media/imx/imx-media-utils.c
@@ -118,6 +118,30 @@ static const struct imx_media_pixfmt rgb_formats[] = {
.cs = IPUV3_COLORSPACE_RGB,
.bpp= 8,
.bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SBGGR10,
+   .codes  = {MEDIA_BUS_FMT_SBGGR10_1X10},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SGBRG10,
+   .codes  = {MEDIA_BUS_FMT_SGBRG10_1X10},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SGRBG10,
+   .codes  = {MEDIA_BUS_FMT_SGRBG10_1X10},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SRGGB10,
+   .codes  = {MEDIA_BUS_FMT_SRGGB10_1X10},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,
}, {
.fourcc = V4L2_PIX_FMT_SBGGR16,
.codes  = {
-- 
2.17.0

[PATCH 14/15] media: imx7.rst: add documentation for i.MX7 media driver

[Rui Miguel Silva]

Add rst document to describe the i.MX7 media driver and also a working example
from the Warp7 board usage with a OV2680 sensor.

Signed-off-by: Rui Miguel Silva 
---
 Documentation/media/v4l-drivers/imx7.rst  | 157 ++
 Documentation/media/v4l-drivers/index.rst |   1 +
 2 files changed, 158 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/imx7.rst

diff --git a/Documentation/media/v4l-drivers/imx7.rst 
b/Documentation/media/v4l-drivers/imx7.rst
new file mode 100644
index ..64b97b442277
--- /dev/null
+++ b/Documentation/media/v4l-drivers/imx7.rst
@@ -0,0 +1,157 @@
+i.MX7 Video Capture Driver
+==
+
+Introduction
+
+
+The i.MX7 contrary to the i.MX5/6 family does not contain an Image Processing
+Unit (IPU), because of that the capabilities to perform operations or
+manipulation of the capture frames is less feature rich.
+
+For image capture the i.MX7 have three units:
+- CMOS Sensor Interface (CSI)
+- Video Multiplexer
+- MIPI CSI-2 Receiver
+
+::
+   |\
+   MIPI Camera Input ---> MIPI CSI-2 --- > | \
+   |  \
+   | M |
+   | U | -->  CSI ---> Capture
+   | X |
+   |  /
+   Parallel Camera Input > | /
+   |/
+
+For additional information, please refer to the latest versions of the i.MX7
+reference manual [#f1]_.
+
+Entities
+
+
+imx7-mipi-csi2
+--
+
+This is the MIPI CSI-2 recevier entity. It has one sink pad to receive the 
pixel
+data from MIPI CSI-2 camera sensor. It has one source pad, corresponding to the
+virtual channel 0. This module is compliant to previous version of Samsung
+D-phy, and support two D-PHY Rx Data lanes.
+
+csi_mux
+---
+
+This is the video multiplexer. It has two sink pads to select from either 
camera
+sensors with a parallel interface or from MIPI CSI-2 virtual channel 0.  It has
+a single source pad that routes to the CSI.
+
+csi
+---
+
+The CSI enables the chip to connect directly to external CMOS image sensor. CSI
+can interfaces directly with Parallel and MIPI CSI-2 buses. It has 256 x 64 
FIFO
+to store received image pixel data and embedded DMA controllers to transfer 
data
+from the FIFO through AHB bus.
+
+This entity has one sink pad that receive from the csi_mux entity and a single
+source pad that route video frames directly to memory buffers, this pad is
+routed to a capture device node.
+
+Usage Notes
+---
+
+To aid in configuration and for backward compatibility with V4L2 applications
+that access controls only from video device nodes, the capture device 
interfaces
+inherit controls from the active entities in the current pipeline, so controls
+can be accessed either directly from the subdev or from the active capture
+device interface. For example, the sensor controls are available either from 
the
+sensor subdevs or from the active capture device.
+
+Warp7 with OV2680
+-
+
+On this platform an OV2680 MIPI CSI-2 module is connected to the internal MIPI
+CSI-2 receiver. The following example configures a video capture pipeline with
+an output of 800x600, and BGGR 10 bit bayer format:
+
+.. code-block:: none
+   # Setup links
+   media-ctl -l "'ov2680 1-0036':0 -> 'imx7-mipi-csis.0':0[1]"
+   media-ctl -l "'imx7-mipi-csis.0':1 -> 'csi_mux':1[1]"
+   media-ctl -l "'csi_mux':2 -> 'csi':0[1]"
+   media-ctl -l "'csi':1 -> 'csi capture':0[1]"
+
+   # Configure pads for pipeline
+   media-ctl -V "'ov2680 1-0036':0 [fmt:SBGGR10_1X10/800x600 field:none]"
+   media-ctl -V "'csi_mux':1 [fmt:SBGGR10_1X10/800x600 field:none]"
+   media-ctl -V "'csi_mux':2 [fmt:SBGGR10_1X10/800x600 field:none]"
+   media-ctl -V "'imx7-mipi-csis.0':0 [fmt:SBGGR10_1X10/800x600 field:none]"
+   media-ctl -V "'csi':0 [fmt:SBGGR10_1X10/800x600 field:none]"
+
+After this streaming can start, the v4l2-ctl tool can be used to select any of
+the resolutions supported by the sensor.
+
+.. code-block:: none
+root@imx7s-warp:~# media-ctl -p
+Media controller API version 4.17.0
+
+Media device information
+
+driver  imx-media
+model   imx-media
+serial
+bus info
+hw revision 0x0
+driver version  4.17.0
+
+Device topology
+- entity 1: csi (2 pads, 2 links)
+   type V4L2 subdev subtype Unknown flags 0
+   device node name /dev/v4l-subdev0
+   pad0: Sink
+   [fmt:SBGGR10_1X10/800x600 field:none]
+   <- "csi_mux":2 [ENABLED]
+   pad1: Source
+   [fmt:SBGGR10_1X10/800x600 field:none]
+   -> "csi capture":0 [ENABLED]
+
+- entity 4: csi capture (1 pad, 1 link)
+ 

[PATCH 12/15] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections

[Rui Miguel Silva]

This patch adds the device tree nodes for csi, video multiplexer and mipi-csi
besides the graph connecting the necessary endpoints to make the media capture
entities to work in imx7 Warp board.

Also add the pin control related with the mipi_csi in that board.

Signed-off-by: Rui Miguel Silva 
---
 arch/arm/boot/dts/imx7s-warp.dts | 80 
 arch/arm/boot/dts/imx7s.dtsi | 27 +++
 2 files changed, 107 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index 8a30b148534d..91d06adf7c24 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -310,6 +310,79 @@
status = "okay";
 };
 
+ {
+   csi_mux {
+   compatible = "video-mux";
+   mux-controls = < 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi_mux_from_parallel_sensor: endpoint {
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi_mux_from_mipi_vc0: endpoint {
+   remote-endpoint = <_vc0_to_csi_mux>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi_mux_to_csi: endpoint {
+   remote-endpoint = <_from_csi_mux>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi_from_csi_mux: endpoint {
+   remote-endpoint = <_mux_to_csi>;
+   };
+   };
+};
+
+_csi {
+   clock-frequency = <16600>;
+   status = "okay";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   mipi_from_sensor: endpoint {
+   remote-endpoint = <_to_mipi>;
+   data-lanes = <1>;
+   csis-hs-settle = <3>;
+   csis-clk-settle = <0>;
+   csis-wclk;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   mipi_vc0_to_csi_mux: endpoint {
+   remote-endpoint = <_mux_from_mipi_vc0>;
+   };
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_wdog>;
@@ -357,6 +430,13 @@
>;
};
 
+   pinctrl_mipi_csi: mipi_csi {
+   fsl,pins = <
+   MX7D_PAD_LPSR_GPIO1_IO03__GPIO1_IO3 0x14
+   MX7D_PAD_ENET1_RGMII_TD0__GPIO7_IO6 0x14
+   >;
+   };
+
pinctrl_sai1: sai1grp {
fsl,pins = <
MX7D_PAD_SAI1_RX_DATA__SAI1_RX_DATA00x1f
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 3027d6a62021..6b49b73053f9 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "imx7d-pinfunc.h"
 
 / {
@@ -753,6 +754,17 @@
status = "disabled";
};
 
+   csi: csi@3071 {
+   compatible = "fsl,imx7-csi";
+   reg = <0x3071 0x1>;
+   interrupts = ;
+   clocks = < IMX7D_CLK_DUMMY>,
+   < IMX7D_CSI_MCLK_ROOT_CLK>,
+   < IMX7D_CLK_DUMMY>;
+   clock-names = "axi", "mclk", "dcic";
+   status = "disabled";
+   };
+
lcdif: lcdif@3073 {
compatible = "fsl,imx7d-lcdif", 
"fsl,imx28-lcdif";
reg = <0x3073 0x1>;
@@ -762,6 +774,21 @@
clock-names = "pix", "axi";
status = "disabled";
};
+
+   mipi_csi: mipi-csi@3075 {
+   compatible = "fsl,imx7-mipi-csi2";
+   reg = <0x3075 0x1>;
+   interrupts = ;
+   clocks = < IMX7D_MIPI_CSI_ROOT_CLK>,
+   < 
IMX7D_MIPI_DPHY_ROOT_CLK>;
+   clock-names = "mipi", "phy";
+   power-domains = <_mipi_phy>;
+   phy-supply = <_1p0d>;
+   resets = < IMX7_RESET_MIPI_PHY_MRST>;
+   reset-names = "mrst";
+   

Re: [PATCH v2 02/12] media: ov5640: Add light frequency control

[Laurent Pinchart]

Hi Maxime,

Thank you for the patch.

On Monday, 16 April 2018 15:36:51 EEST Maxime Ripard wrote:
> From: Mylène Josserand 
> 
> Add the light frequency control to be able to set the frequency
> to manual (50Hz or 60Hz) or auto.
> 
> Signed-off-by: Mylène Josserand 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/media/i2c/ov5640.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index a33e45f8e2b0..28122341fc35 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -189,6 +189,7 @@ struct ov5640_ctrls {
>   };
>   struct v4l2_ctrl *auto_focus;
>   struct v4l2_ctrl *brightness;
> + struct v4l2_ctrl *light_freq;
>   struct v4l2_ctrl *saturation;
>   struct v4l2_ctrl *contrast;
>   struct v4l2_ctrl *hue;
> @@ -2163,6 +2164,21 @@ static int ov5640_set_ctrl_focus(struct ov5640_dev
> *sensor, int value) BIT(1), value ? BIT(1) : 0);
>  }
> 
> +static int ov5640_set_ctl_light_freq(struct ov5640_dev *sensor, int value)

To stay consistent with the other functions, I propose calling this 
ov5640_set_ctrl_light_freq().

Apart from that,

Reviewed-by: Laurent Pinchart 

> +{
> + int ret;
> +
> + ret = ov5640_mod_reg(sensor, OV5640_REG_HZ5060_CTRL01, BIT(7),
> +  (value == V4L2_CID_POWER_LINE_FREQUENCY_AUTO) ?
> +  0: BIT(7));
> + if (ret)
> + return ret;
> +
> + return ov5640_mod_reg(sensor, OV5640_REG_HZ5060_CTRL00, BIT(2),
> +   (value == V4L2_CID_POWER_LINE_FREQUENCY_50HZ) ?
> +   BIT(2): 0);
> +}
> +
>  static int ov5640_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
>  {
>   struct v4l2_subdev *sd = ctrl_to_sd(ctrl);
> @@ -2234,6 +2250,9 @@ static int ov5640_s_ctrl(struct v4l2_ctrl *ctrl)
>   case V4L2_CID_FOCUS_AUTO:
>   ret = ov5640_set_ctrl_focus(sensor, ctrl->val);
>   break;
> + case V4L2_CID_POWER_LINE_FREQUENCY:
> + ret = ov5640_set_ctl_light_freq(sensor, ctrl->val);
> + break;
>   default:
>   ret = -EINVAL;
>   break;
> @@ -2298,6 +2317,11 @@ static int ov5640_init_controls(struct ov5640_dev
> *sensor)
> 
>   ctrls->auto_focus = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_AUTO,
> 0, 1, 1, 0);
> + ctrls->light_freq =
> + v4l2_ctrl_new_std_menu(hdl, ops,
> +V4L2_CID_POWER_LINE_FREQUENCY,
> +V4L2_CID_POWER_LINE_FREQUENCY_AUTO, 0,
> +V4L2_CID_POWER_LINE_FREQUENCY_50HZ);
> 
>   if (hdl->error) {
>   ret = hdl->error;

-- 
Regards,

Laurent Pinchart

[PATCH 0/8] drm: bridge: Add support for static image formats

[Jacopo Mondi]

Hello DRM list,
  cc media-list for the mbus format extension
  cc renesas-soc and devicetree for Eagle DTS patch

This series adds support for static image formats to DRM bridges, mimicking
what display_info.bus_formats represents for DRM connectors.

The main use case of this series is the R-Car DU LVDS encoder. This component
can output LVDS streams compatible with JEIDA or SPWG specification, and so far
it has only been possible to decide which one to output if the next component
in the DRM pipeline was a panel, equipped with a DRM connector where to inspect
the accepted input image format from.

With the introduction of the transparent THC63LVD1024 LVDS decoder driver, the
next component in the pipeline is now a bridge, and the DU LVDS encoder needs
to inspect which media bus image formats it accepts and set its LVDS output
mode accordingly.

The series implements -static- image format supports for bridges. As a result
of the discussion on Peter Rosin's patch series:
[PATCH v2 0/5] allow override of bus format in bridges
https://lkml.org/lkml/2018/3/26/610
my understanding is that the accepted image formats can be 'dynamic' (or
'atomic') if depends on the configured DRM mode, or 'static' as in the
THC63LVD1024 case, where an external pin configuration decides which LVDS
mapping mode the encoder accepts (which implies it comes from DT, as in Peter's
use case).

For dynamic formats Daniel already suggested a possible implementation:
https://lkml.org/lkml/2018/3/28/57
while for static image formats I am proposing an implementation that
copies what we have for connectors at the moment.

One more detail: the DU LVDS encoder supports 'mirroring' of LVDS modes, and
that was handled through a set of flags (DRM_BUS_FLAG_DATA_*) defined for
connectors only, and added for that specific purpose, if I got this right.
Instead of replicating the same flags for bridges, or moving them to some shared
header which I had trouble to identify, I have introduced the _LE version of
mbus formats used to describe LVDS streams. While 'little endian' is not
*technically* exact for those mirrored formats, it is my opinion they represent
a good description anyhow of the reversed component ordering.

As a result, the connector specific DRM_BUS_FLAG_DATA_* have been removed as
all their user have been ported to use the new _LE formats.

The series depends on THC63LVD1024 support, implemented by the following
in-review series:
 [PATCH v9 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge
 [PATCH v3 0/5] V3M-Eagle HDMI output enablement

available for the interested at:
git://jmondi.org/linux lvds-bridge/linus-master/v9-eagle-v3

Thanks for comments
   j

Jacopo Mondi (8):
  drm: bridge: Add support for static image formats
  dt-bindings: display: bridge: thc63lvd1024: Add lvds map property
  drm: bridge: thc63lvd1024: Add support for LVDS mode map
  arm64: dts: renesas: eagle: Add thc63 LVDS map
  media: Add LE version of RGB LVDS formats
  drm: rcar-du: rcar-lvds: Add bridge format support
  drm: panel: Use _LE LVDS formats for data mirroring
  drm: connector: Remove DRM_BUS_FLAG_DATA_* flags

 .../bindings/display/bridge/thine,thc63lvd1024.txt |   3 +
 Documentation/media/uapi/v4l/subdev-formats.rst| 174 +
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts |   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c  |  41 +
 drivers/gpu/drm/drm_bridge.c   |  30 
 drivers/gpu/drm/panel/panel-lvds.c |  21 +--
 drivers/gpu/drm/rcar-du/rcar_lvds.c|  64 +---
 include/drm/drm_bridge.h   |   8 +
 include/drm/drm_connector.h|   4 -
 include/uapi/linux/media-bus-format.h  |   5 +-
 10 files changed, 317 insertions(+), 34 deletions(-)

--
2.7.4

[PATCH 2/8] dt-bindings: display: bridge: thc63lvd1024: Add lvds map property

[Jacopo Mondi]

The THC63LVD1024 LVDS to RGB bridge supports two different input mapping
modes, selectable by means of an external pin.

Describe the LVDS mode map through a newly defined mandatory property in
device tree bindings.

Signed-off-by: Jacopo Mondi 
---
 .../devicetree/bindings/display/bridge/thine,thc63lvd1024.txt  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
index 37f0c04..0937595 100644
--- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -12,6 +12,8 @@ Required properties:
 - compatible: Shall be "thine,thc63lvd1024"
 - vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input,
   PPL and digital circuitry
+- thine,map: LVDS mapping mode selection signal, pin name "MAP". Shall be <1>
+  for mapping mode 1, <0> for mapping mode 2
 
 Optional properties:
 - powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
@@ -36,6 +38,7 @@ Example:
 
vcc-supply = <_lvds_vcc>;
powerdown-gpios = < 15 GPIO_ACTIVE_LOW>;
+   thine,map = <1>;
 
ports {
#address-cells = <1>;
-- 
2.7.4

[PATCH 3/8] drm: bridge: thc63lvd1024: Add support for LVDS mode map

[Jacopo Mondi]

The THC63LVD1024 LVDS to RGB bridge supports two different LVDS mapping
modes, selectable by means of an external pin.

Add support for configurable LVDS input mapping modes, using the newly
introduced support for bridge input image formats.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/bridge/thc63lvd1024.c | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
b/drivers/gpu/drm/bridge/thc63lvd1024.c
index 48527f8..a3071a1 100644
--- a/drivers/gpu/drm/bridge/thc63lvd1024.c
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -10,9 +10,15 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
+enum thc63_lvds_mapping_mode {
+   THC63_LVDS_MAP_MODE2,
+   THC63_LVDS_MAP_MODE1,
+};
+
 enum thc63_ports {
THC63_LVDS_IN0,
THC63_LVDS_IN1,
@@ -116,6 +122,37 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
return 0;
 }
 
+static int thc63_set_bus_fmt(struct thc63_dev *thc63)
+{
+   u32 bus_fmt;
+   u32 map;
+   int ret;
+
+   ret = of_property_read_u32(thc63->dev->of_node, "thine,map", );
+   if (ret) {
+   dev_err(thc63->dev,
+   "Unable to parse property \"thine,map\": %d\n", ret);
+   return ret;
+   }
+
+   switch (map) {
+   case THC63_LVDS_MAP_MODE1:
+   bus_fmt = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
+   break;
+   case THC63_LVDS_MAP_MODE2:
+   bus_fmt = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
+   break;
+   default:
+   dev_err(thc63->dev,
+   "Invalid value for property \"thine,map\": %u\n", map);
+   return -EINVAL;
+   }
+
+   drm_bridge_set_bus_formats(>bridge, _fmt, 1);
+
+   return 0;
+}
+
 static int thc63_gpio_init(struct thc63_dev *thc63)
 {
thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
@@ -166,6 +203,10 @@ static int thc63_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   ret = thc63_set_bus_fmt(thc63);
+   if (ret)
+   return ret;
+
thc63->bridge.driver_private = thc63;
thc63->bridge.of_node = pdev->dev.of_node;
thc63->bridge.funcs = _bridge_func;
-- 
2.7.4

[PATCH 1/8] drm: bridge: Add support for static image formats

[Jacopo Mondi]

Add support for storing image format information in DRM bridges with
associated helper function.

This patch replicates for bridges what 'drm_display_info_set_bus_formats()'
is for connectors.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/drm_bridge.c | 30 ++
 include/drm/drm_bridge.h |  8 
 2 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1638bfe..e2ad098 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -157,6 +157,36 @@ void drm_bridge_detach(struct drm_bridge *bridge)
 }
 
 /**
+ * drm_bridge_set_bus_formats() - set bridge supported image formats
+ * @bridge: the bridge to set image formats in
+ * @formats: array of MEDIA_BUS_FMT\_ supported image formats
+ * @num_formats: number of elements in the @formats array
+ *
+ * Store a list of supported image formats in a bridge.
+ * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for
+ * a full list of available formats.
+ */
+int drm_bridge_set_bus_formats(struct drm_bridge *bridge, const u32 *formats,
+  unsigned int num_formats)
+{
+   u32 *fmts;
+
+   if (!formats || !num_formats)
+   return -EINVAL;
+
+   fmts = kmemdup(formats, sizeof(*formats) * num_formats, GFP_KERNEL);
+   if (!fmts)
+   return -ENOMEM;
+
+   kfree(bridge->bus_formats);
+   bridge->bus_formats = fmts;
+   bridge->num_bus_formats = num_formats;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_bridge_set_bus_formats);
+
+/**
  * DOC: bridge callbacks
  *
  * The _bridge_funcs ops are populated by the bridge driver. The DRM
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3270fec..6b3648c 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -258,6 +258,9 @@ struct drm_bridge_timings {
  * @encoder: encoder to which this bridge is connected
  * @next: the next bridge in the encoder chain
  * @of_node: device node pointer to the bridge
+ * @bus_formats: wire image formats. Array of @num_bus_formats MEDIA_BUS_FMT\_
+ * elements
+ * @num_bus_formats: size of @bus_formats array
  * @list: to keep track of all added bridges
  * @timings: the timing specification for the bridge, if any (may
  * be NULL)
@@ -271,6 +274,9 @@ struct drm_bridge {
 #ifdef CONFIG_OF
struct device_node *of_node;
 #endif
+   const u32 *bus_formats;
+   unsigned int num_bus_formats;
+
struct list_head list;
const struct drm_bridge_timings *timings;
 
@@ -296,6 +302,8 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
struct drm_display_mode *adjusted_mode);
 void drm_bridge_pre_enable(struct drm_bridge *bridge);
 void drm_bridge_enable(struct drm_bridge *bridge);
+int drm_bridge_set_bus_formats(struct drm_bridge *bridge, const u32 *fmts,
+  unsigned int num_fmts);
 
 #ifdef CONFIG_DRM_PANEL_BRIDGE
 struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
-- 
2.7.4

[PATCH 4/8] arm64: dts: renesas: eagle: Add thc63 LVDS map

[Jacopo Mondi]

Add LVDS map mode description property to THC63LVD1024 LVDS decoder in
R-Car V3M-Eagle board device tree.

Signed-off-by: Jacopo Mondi 
---
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts 
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index ebfbb51..2609fa3 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -56,6 +56,7 @@
compatible = "thine,thc63lvd1024";
 
vcc-supply = <>;
+   thine,map = <1>;
 
ports {
#address-cells = <1>;
-- 
2.7.4

[PATCH 6/8] drm: rcar-du: rcar-lvds: Add bridge format support

[Jacopo Mondi]

With the introduction of static input image format enumeration in DRM
bridges, add support to retrieve the format in rcar-lvds LVDS encoder
from both panel or bridge, to set the desired LVDS mode.

Do not rely on 'DRM_BUS_FLAG_DATA_LSB_TO_MSB' flag to mirror the LVDS
format, as it is only defined for drm connectors, but use the newly
introduced _LE version of LVDS mbus image formats.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/rcar-du/rcar_lvds.c | 64 +
 1 file changed, 44 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 3d2d3bb..2fa875f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -280,41 +280,65 @@ static bool rcar_lvds_mode_fixup(struct drm_bridge 
*bridge,
return true;
 }
 
-static void rcar_lvds_get_lvds_mode(struct rcar_lvds *lvds)
+static int rcar_lvds_get_lvds_mode_from_connector(struct rcar_lvds *lvds,
+ unsigned int *bus_fmt)
 {
struct drm_display_info *info = >connector.display_info;
-   enum rcar_lvds_mode mode;
-
-   /*
-* There is no API yet to retrieve LVDS mode from a bridge, only panels
-* are supported.
-*/
-   if (!lvds->panel)
-   return;
 
if (!info->num_bus_formats || !info->bus_formats) {
dev_err(lvds->dev, "no LVDS bus format reported\n");
-   return;
+   return -EINVAL;
+   }
+
+   *bus_fmt = info->bus_formats[0];
+
+   return 0;
+}
+
+static int rcar_lvds_get_lvds_mode_from_bridge(struct rcar_lvds *lvds,
+  unsigned int *bus_fmt)
+{
+   if (!lvds->next_bridge->num_bus_formats ||
+   !lvds->next_bridge->bus_formats) {
+   dev_err(lvds->dev, "no LVDS bus format reported\n");
+   return -EINVAL;
}
 
-   switch (info->bus_formats[0]) {
+   *bus_fmt = lvds->next_bridge->bus_formats[0];
+
+   return 0;
+}
+
+static void rcar_lvds_get_lvds_mode(struct rcar_lvds *lvds)
+{
+   unsigned int bus_fmt;
+   int ret;
+
+   if (lvds->panel)
+   ret = rcar_lvds_get_lvds_mode_from_connector(lvds, _fmt);
+   else
+   ret = rcar_lvds_get_lvds_mode_from_bridge(lvds, _fmt);
+   if (ret)
+   return;
+
+   switch (bus_fmt) {
+   case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG_LE:
+   case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA_LE:
+   lvds->mode |= RCAR_LVDS_MODE_MIRROR;
case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
-   mode = RCAR_LVDS_MODE_JEIDA;
+   lvds->mode = RCAR_LVDS_MODE_JEIDA;
break;
+
+   case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG_LE:
+   lvds->mode |= RCAR_LVDS_MODE_MIRROR;
case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
-   mode = RCAR_LVDS_MODE_VESA;
+   lvds->mode = RCAR_LVDS_MODE_VESA;
break;
default:
dev_err(lvds->dev, "unsupported LVDS bus format 0x%04x\n",
-   info->bus_formats[0]);
-   return;
+   bus_fmt);
}
-
-   if (info->bus_flags & DRM_BUS_FLAG_DATA_LSB_TO_MSB)
-   mode |= RCAR_LVDS_MODE_MIRROR;
-
-   lvds->mode = mode;
 }
 
 static void rcar_lvds_mode_set(struct drm_bridge *bridge,
-- 
2.7.4

[PATCH 5/8] media: Add LE version of RGB LVDS formats

[Jacopo Mondi]

Some LVDS controller can output swapped versions of LVDS RGB formats.
Define and document them in the list of supported media bus formats

Signed-off-by: Jacopo Mondi 
---
 Documentation/media/uapi/v4l/subdev-formats.rst | 174 
 include/uapi/linux/media-bus-format.h   |   5 +-
 2 files changed, 178 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index 9fcabe7..9a5263c 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -1669,6 +1669,64 @@ JEIDA defined bit mapping will be named
   - b\ :sub:`2`
   - g\ :sub:`1`
   - r\ :sub:`0`
+* .. _MEDIA-BUS-FMT-RGB666-1X7X3-SPWG_LE:
+
+  - MEDIA_BUS_FMT_RGB666_1X7X3_SPWG_LE
+  - 0x101b
+  - 0
+  -
+  -
+  - b\ :sub:`2`
+  - g\ :sub:`1`
+  - r\ :sub:`0`
+* -
+  -
+  - 1
+  -
+  -
+  - b\ :sub:`3`
+  - g\ :sub:`2`
+  - r\ :sub:`1`
+* -
+  -
+  - 2
+  -
+  -
+  - b\ :sub:`4`
+  - g\ :sub:`3`
+  - r\ :sub:`2`
+* -
+  -
+  - 3
+  -
+  -
+  - b\ :sub:`5`
+  - g\ :sub:`4`
+  - r\ :sub:`3`
+* -
+  -
+  - 4
+  -
+  -
+  - d
+  - g\ :sub:`5`
+  - r\ :sub:`4`
+* -
+  -
+  - 5
+  -
+  -
+  - d
+  - b\ :sub:`0`
+  - r\ :sub:`5`
+* -
+  -
+  - 6
+  -
+  -
+  - d
+  - b\ :sub:`1`
+  - g\ :sub:`0`
 * .. _MEDIA-BUS-FMT-RGB888-1X7X4-SPWG:
 
   - MEDIA_BUS_FMT_RGB888_1X7X4_SPWG
@@ -1727,6 +1785,64 @@ JEIDA defined bit mapping will be named
   - b\ :sub:`2`
   - g\ :sub:`1`
   - r\ :sub:`0`
+* .. _MEDIA-BUS-FMT-RGB888-1X7X4-SPWG_LE:
+
+  - MEDIA_BUS_FMT_RGB888_1X7X4_SPWG_LE
+  - 0x101c
+  - 0
+  -
+  - r\ :sub:`6`
+  - b\ :sub:`2`
+  - g\ :sub:`1`
+  - r\ :sub:`0`
+* -
+  -
+  - 1
+  -
+  - r\ :sub:`7`
+  - b\ :sub:`3`
+  - g\ :sub:`2`
+  - r\ :sub:`1`
+* -
+  -
+  - 2
+  -
+  - g\ :sub:`6`
+  - b\ :sub:`4`
+  - g\ :sub:`3`
+  - r\ :sub:`2`
+* -
+  -
+  - 3
+  -
+  - g\ :sub:`7`
+  - b\ :sub:`5`
+  - g\ :sub:`4`
+  - r\ :sub:`3`
+* -
+  -
+  - 4
+  -
+  - b\ :sub:`6`
+  - d
+  - g\ :sub:`5`
+  - r\ :sub:`4`
+* -
+  -
+  - 5
+  -
+  - b\ :sub:`7`
+  - d
+  - b\ :sub:`0`
+  - r\ :sub:`5`
+* -
+  -
+  - 6
+  -
+  - d
+  - d
+  - b\ :sub:`1`
+  - g\ :sub:`0`
 * .. _MEDIA-BUS-FMT-RGB888-1X7X4-JEIDA:
 
   - MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA
@@ -1785,6 +1901,64 @@ JEIDA defined bit mapping will be named
   - b\ :sub:`4`
   - g\ :sub:`3`
   - r\ :sub:`2`
+* .. _MEDIA-BUS-FMT-RGB888-1X7X4-JEIDA_LE:
+
+  - MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA_LE
+  - 0x101d
+  - 0
+  -
+  - r\ :sub:`0`
+  - b\ :sub:`4`
+  - g\ :sub:`3`
+  - r\ :sub:`2`
+* -
+  -
+  - 1
+  -
+  - r\ :sub:`1`
+  - b\ :sub:`5`
+  - g\ :sub:`4`
+  - r\ :sub:`3`
+* -
+  -
+  - 2
+  -
+  - g\ :sub:`0`
+  - b\ :sub:`6`
+  - g\ :sub:`5`
+  - r\ :sub:`4`
+* -
+  -
+  - 3
+  -
+  - g\ :sub:`1`
+  - b\ :sub:`7`
+  - g\ :sub:`6`
+  - r\ :sub:`5`
+* -
+  -
+  - 4
+  -
+  - b\ :sub:`0`
+  - d
+  - g\ :sub:`7`
+  - r\ :sub:`6`
+* -
+  -
+  - 5
+  -
+  - b\ :sub:`1`
+  - d
+  - b\ :sub:`2`
+  - r\ :sub:`7`
+* -
+  -
+  - 6
+  -
+  - d
+  - d
+  - b\ :sub:`3`
+  - g\ :sub:`2`
 
 .. raw:: latex
 
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 9e35117..5bea7c0 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -34,7 +34,7 @@
 
 #define MEDIA_BUS_FMT_FIXED0x0001
 
-/* RGB - next is   0x101b */
+/* RGB - next is   0x101f */
 #define MEDIA_BUS_FMT_RGB444_1X12  0x1016
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
@@ -49,13 +49,16 @@
 #define MEDIA_BUS_FMT_RBG888_1X24  0x100e
 #define MEDIA_BUS_FMT_RGB666_1X24_CPADHI   0x1015
 #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG0x1010
+#define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG_LE 0x101b
 #define MEDIA_BUS_FMT_BGR888_1X24  0x1013
 #define MEDIA_BUS_FMT_GBR888_1X24  0x1014
 #define MEDIA_BUS_FMT_RGB888_1X24  0x100a
 #define MEDIA_BUS_FMT_RGB888_2X12_BE   0x100b
 #define MEDIA_BUS_FMT_RGB888_2X12_LE   0x100c
 #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG0x1011
+#define 

[PATCH 7/8] drm: panel: Use _LE LVDS formats for data mirroring

[Jacopo Mondi]

As now both bridges and panels report supported image formats,
use the newly introduced _LE version of LVDS media bus formats in place
of the DRM_BUS_FLAG_DATA_ flags defined in drm_connector.h

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/panel/panel-lvds.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
b/drivers/gpu/drm/panel/panel-lvds.c
index 5185819..ac03eab 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -37,7 +37,6 @@ struct panel_lvds {
unsigned int height;
struct videomode video_mode;
unsigned int bus_format;
-   bool data_mirror;
 
struct backlight_device *backlight;
struct regulator *supply;
@@ -129,9 +128,6 @@ static int panel_lvds_get_modes(struct drm_panel *panel)
connector->display_info.height_mm = lvds->height;
drm_display_info_set_bus_formats(>display_info,
 >bus_format, 1);
-   connector->display_info.bus_flags = lvds->data_mirror
- ? DRM_BUS_FLAG_DATA_LSB_TO_MSB
- : DRM_BUS_FLAG_DATA_MSB_TO_LSB;
 
return 1;
 }
@@ -149,6 +145,7 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
struct device_node *np = lvds->dev->of_node;
struct display_timing timing;
const char *mapping;
+   bool data_mirror;
int ret;
 
ret = of_get_display_timing(np, "panel-timing", );
@@ -179,20 +176,26 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
return -ENODEV;
}
 
+   data_mirror = of_property_read_bool(np, "data-mirror");
+
if (!strcmp(mapping, "jeida-18")) {
-   lvds->bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
+   lvds->bus_format = data_mirror ?
+  MEDIA_BUS_FMT_RGB666_1X7X3_SPWG_LE :
+  MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
} else if (!strcmp(mapping, "jeida-24")) {
-   lvds->bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
+   lvds->bus_format = data_mirror ?
+  MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA_LE :
+  MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
} else if (!strcmp(mapping, "vesa-24")) {
-   lvds->bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
+   lvds->bus_format = data_mirror ?
+  MEDIA_BUS_FMT_RGB888_1X7X4_SPWG_LE :
+  MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
} else {
dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
np, "data-mapping");
return -EINVAL;
}
 
-   lvds->data_mirror = of_property_read_bool(np, "data-mirror");
-
return 0;
 }
 
-- 
2.7.4

[PATCH 8/8] drm: connector: Remove DRM_BUS_FLAG_DATA_* flags

[Jacopo Mondi]

DRM_BUS_FLAG_DATA_* flags, defined in drm_connector.h header file are
used to swap ordering of LVDS RGB format to accommodate DRM objects
that need to handle LVDS components ordering.

Now that the only 2 users of DRM_BUS_FLAG_DATA_* flags have been ported
to use the newly introduced MEDIA_BUS_FMT_RGB888_1X7X*_LE media bus
formats, remove them.

Signed-off-by: Jacopo Mondi 
---
 include/drm/drm_connector.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 675cc3f..9e0d6d5 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -286,10 +286,6 @@ struct drm_display_info {
 #define DRM_BUS_FLAG_PIXDATA_POSEDGE   (1<<2)
 /* drive data on neg. edge */
 #define DRM_BUS_FLAG_PIXDATA_NEGEDGE   (1<<3)
-/* data is transmitted MSB to LSB on the bus */
-#define DRM_BUS_FLAG_DATA_MSB_TO_LSB   (1<<4)
-/* data is transmitted LSB to MSB on the bus */
-#define DRM_BUS_FLAG_DATA_LSB_TO_MSB   (1<<5)
 
/**
 * @bus_flags: Additional information (like pixel signal polarity) for
-- 
2.7.4

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:
> We've broken that assumption in i915 years ago. Not struct page backed
> gpu memory is very real.
> 
> Of course we'll never feed such a strange sg table to a driver which
> doesn't understand it, but allowing sg_page == NULL works perfectly
> fine. At least for gpu drivers.

For GPU drivers on x86 with no dma coherency problems, sure.  But not
all the world is x86.  We already have problems due to dmabugs use
of the awkward get_sgtable interface (see the common on
arm_dma_get_sgtable that I fully agree with), and doing this for memory
that doesn't have a struct page at all will make things even worse.

> If that's not acceptable then I guess we could go over the entire tree
> and frob all the gpu related code to switch over to a new struct
> sg_table_might_not_be_struct_page_backed, including all the other
> functions we added over the past few years to iterate over sg tables.
> But seems slightly silly, given that sg tables seem to do exactly what
> we need.

It isn't silly.  We will have to do some surgery like that anyway
because the current APIs don't work.  So relax, sit back and come up
with an API that solves the existing issues and serves us well in
the future.

Re: [RFCv11 PATCH 00/29] Request API

[Paul Kocialkowski]

Hi,

On Wed, 2018-04-18 at 02:06 +, Alexandre Courbot wrote:
> On Tue, Apr 17, 2018 at 8:41 PM Paul Kocialkowski <
> paul.kocialkow...@bootlin.com> wrote:
> On Tue, 2018-04-17 at 06:17 +, Alexandre Courbot wrote:
> > > On Tue, Apr 17, 2018 at 3:12 PM Hans Verkuil 
> > > wrote:
> > > 
> > > > On 04/17/2018 06:33 AM, Alexandre Courbot wrote:
> > > > > On Mon, Apr 9, 2018 at 11:20 PM Hans Verkuil  > > > > nl>
> > > > > wrote:
> > > > > 
> > > > > > From: Hans Verkuil 
> > > > > > Hi all,
> > > > > > This is a cleaned up version of the v10 series (never posted
> > > > > > to
> > > > > > the list since it was messy).
> > > > > 
> > > > > Hi Hans,
> > > > > 
> > > > > It took me a while to test and review this, but finally have
> > > > > been
> > > > > able
> > > 
> > > to
> > > > > do it.
> > > > > 
> > > > > First the result of the test: I have tried porting my dummy
> > > > > vim2m
> > > > > test
> > > > > program
> > > > > (https://gist.github.com/Gnurou/34c35f1f8e278dad454b51578d239a
> > > > > 42
> > > > > for
> > > > > reference),
> > > > > and am getting a hang when trying to queue the second OUTPUT
> > > > > buffer
> > > 
> > > (right
> > > > > after
> > > > > queuing the first request). If I move the calls the
> > > > > VIDIOC_STREAMON
> > > 
> > > after
> > > > > the
> > > > > requests are queued, the hang seems to happen at that moment.
> > > > > Probably a
> > > > > deadlock, haven't looked in detail yet.
> > > > > 
> > > > > I have a few other comments, will follow up per-patch.
> > > > > 
> > > > 
> > > > I had a similar/same (?) report about this from Paul:
> > > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg1291
> > > > 77.h
> > > > tml
> > > 
> > > I saw this and tried to move the call to STREAMON to after the
> > > requests are queued in my example program, but it then hanged
> > > there.
> > > So there is probably something more intricate taking place.
> > I figured out the issue (but forgot to report back to the list):
> > Hans'
> > version of the request API doesn't set the POLLIN bit but POLLPRI
> > instead, so you need to select for expect_fds instead of read_fds in
> > the
> > select call. That's pretty much all there is to it.
> 
> I am not using select() but poll() in my test program (see the gist
> link
> above) and have set POLLPRI as the event to poll for. I may be missing
> something but this looks correct to me?

You're right, I overlooked your email and assumed you were hitting the
same issue that I had at first.

Anyway, I also had a similar issue when calling the STREAMON ioctl
*before* enqueuing the request. What happens here is that
v4l2_m2m_streamon (called from the ioctl) will also try to schedule a
device run (v4l2_m2m_try_schedule). When the ioctl is called and the
request was not queued yet, the lack of buffers will delay the streamon
call. Then, when the request is later submitted, vb2_streamon is called
with the queue directly, and there is no m2m-specific provision there,
so no device run is scheduled and nothing happens. If the STREAMON ioctl
happens after queuing the request, then things should be fine (but
that's definitely not what we want userspace to be doing) since
the vb2_streamon call from the ioctl handler will take effect
and v4l2_m2m_try_schedule will be called.

The way that I have solved this with the Sunxi-Cedrus driver is to add a
req_complete callback function pointer (holding a call
to v4l2_m2m_try_schedule) in media_device_ops and call it (if available)
from media_request_ioctl_queue. I initially put this in req_queue
directly, but since it is wrapped by the request queue mutex lock and
provided that device_run needs to access the request queue, we need an
extra op called out of this lock, before completing the ioctl handler.

I will be sending v2 of my driver with preliminary patches to fix this
(perhaps I should also fix vim2m that way along the way).

Cheers,

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc
Description: This is a digitally signed message part