cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Sat Jan 20 05:00:17 CET 2018
media-tree git hash:e3ee691dbf24096ea51b3200946b11d68ce75361
media_build git hash:   2bd1f1623fbadfdc1026712b3d55141ba164c403
v4l-utils git hash: 7eadec47ff4db4a032612349c362f3337b29d485
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3911-g6f737e1f
smatch version: v0.5.0-3911-g6f737e1f
host hardware:  x86_64
host os:4.13.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9.26-i686: ERRORS
linux-4.10.14-i686: WARNINGS
linux-4.11-i686: WARNINGS
linux-4.12.1-i686: WARNINGS
linux-4.13-i686: WARNINGS
linux-4.14-i686: WARNINGS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9.26-x86_64: ERRORS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: WARNINGS
linux-4.14-x86_64: WARNINGS
apps: OK
spec-git: OK
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH v6 3/9] v4l: platform: Add Renesas CEU driver

[kbuild test robot]

Hi Jacopo,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.15-rc8]
[cannot apply to linuxtv-media/master next-20180119]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jacopo-Mondi/Renesas-Capture-Engine-Unit-CEU-V4L2-driver/20180120-053007
config: mn10300-allmodconfig (attached as .config)
compiler: am33_2.0-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mn10300 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   In file included from include/linux/scatterlist.h:9:0,
from include/linux/dma-mapping.h:11,
from drivers/media/platform/renesas-ceu.c:16:
   drivers/media/platform/renesas-ceu.c: In function 'ceu_start_streaming':
>> arch/mn10300/include/asm/io.h:63:25: warning: 'cdwdr' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 *(volatile u32 *) addr = b;
 ~~~^~~
   drivers/media/platform/renesas-ceu.c:335:27: note: 'cdwdr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
  ^
   In file included from include/linux/scatterlist.h:9:0,
from include/linux/dma-mapping.h:11,
from drivers/media/platform/renesas-ceu.c:16:
>> arch/mn10300/include/asm/io.h:63:25: warning: 'cfzsr' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 *(volatile u32 *) addr = b;
 ~~~^~~
   drivers/media/platform/renesas-ceu.c:335:20: note: 'cfzsr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
   ^
   drivers/media/platform/renesas-ceu.c:415:8: warning: 'camcr' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 camcr |= mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW ? 1 << 0 : 0;
 ~~^~~
   drivers/media/platform/renesas-ceu.c:335:6: note: 'camcr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
 ^
   drivers/media/platform/renesas-ceu.c: In function 'ceu_probe':
   drivers/media/platform/renesas-ceu.c:1621:9: warning: 'ret' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 return ret;
^~~
--
   In file included from include/linux/scatterlist.h:9:0,
from include/linux/dma-mapping.h:11,
from drivers/media//platform/renesas-ceu.c:16:
   drivers/media//platform/renesas-ceu.c: In function 'ceu_start_streaming':
>> arch/mn10300/include/asm/io.h:63:25: warning: 'cdwdr' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 *(volatile u32 *) addr = b;
 ~~~^~~
   drivers/media//platform/renesas-ceu.c:335:27: note: 'cdwdr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
  ^
   In file included from include/linux/scatterlist.h:9:0,
from include/linux/dma-mapping.h:11,
from drivers/media//platform/renesas-ceu.c:16:
>> arch/mn10300/include/asm/io.h:63:25: warning: 'cfzsr' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 *(volatile u32 *) addr = b;
 ~~~^~~
   drivers/media//platform/renesas-ceu.c:335:20: note: 'cfzsr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
   ^
   drivers/media//platform/renesas-ceu.c:415:8: warning: 'camcr' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 camcr |= mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW ? 1 << 0 : 0;
 ~~^~~
   drivers/media//platform/renesas-ceu.c:335:6: note: 'camcr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
 ^
   drivers/media//platform/renesas-ceu.c: In function 'ceu_probe':
   drivers/media//platform/renesas-ceu.c:1621:9: warning: 'ret' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 return ret;
^~~

vim +/cdwdr +63 arch/mn10300/include/asm/io.h

b920de1b include/asm-mn10300/io.h David Howells 2008-02-08  60  
b920de1b include/asm-mn10300/io.h David Howells 2008-02-08  61  static inline 
void writel(u32 b, volatile void __iomem *addr)
b920de1b include/asm-mn10300/io.h David Howells 2008-02-08  62  {
b920de1b include/asm-mn10300/io.h David Howells 2008-02-08 @63  
*(volatile u32 *) addr = b;
b920de1b include/asm-mn10

Re: [PATCH v6 3/4] dt-bindings: media: Add bindings for OV2685

[Rob Herring]

On Tue, Jan 16, 2018 at 05:22:00PM +0800, Shunqian Zheng wrote:
> Add device tree binding documentation for the OV2685 sensor.
> 
> Signed-off-by: Shunqian Zheng 
> Reviewed-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/media/i2c/ov2685.txt   | 41 
> ++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2685.txt

Reviewed-by: Rob Herring 

Re: [PATCH v6 1/4] dt-bindings: media: Add bindings for OV5695

[Rob Herring]

On Tue, Jan 16, 2018 at 05:21:58PM +0800, Shunqian Zheng wrote:
> Add device tree binding documentation for the OV5695 sensor.
> 
> Signed-off-by: Shunqian Zheng 
> Reviewed-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/media/i2c/ov5695.txt   | 41 
> ++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5695.txt

Reviewed-by: Rob Herring 

Fwd: Distro-specific hint for media_build - Linux Mint Sylvia 18.3

[Jason Cameron]

Following error occurred when building media_build on Linux Mint 18.3:

***
Checking if the needed tools for Linux Mint 18.3 Sylvia are available
ERROR: please install "Proc::ProcessTable", otherwise, build won't work.
I don't know distro Linux Mint 18.3 Sylvia. So, I can't provide you a
hint with the package names.
Be welcome to contribute with a patch for media-build, by submitting a
distro-specific hint
to linux-media@vger.kernel.org
Build can't procceed as 1 dependency is missing at ./build line 274.
***

Issue can be resolved by installing libproc-processtable-perl (apt-get
install libproc-processtable-perl).

Cheers.

Jason.

Re: [PATCH v6 3/9] v4l: platform: Add Renesas CEU driver

[kbuild test robot]

Hi Jacopo,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.15-rc8]
[cannot apply to linuxtv-media/master next-20180119]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jacopo-Mondi/Renesas-Capture-Engine-Unit-CEU-V4L2-driver/20180120-053007
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/media/platform/renesas-ceu.c: In function 'ceu_start_streaming':
>> drivers/media/platform/renesas-ceu.c:287:2: warning: 'cdwdr' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 iowrite32(data, priv->base + reg_offs);
 ^~
   drivers/media/platform/renesas-ceu.c:335:27: note: 'cdwdr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
  ^
>> drivers/media/platform/renesas-ceu.c:287:2: warning: 'cfzsr' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 iowrite32(data, priv->base + reg_offs);
 ^~
   drivers/media/platform/renesas-ceu.c:335:20: note: 'cfzsr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
   ^
>> drivers/media/platform/renesas-ceu.c:415:8: warning: 'camcr' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 camcr |= mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW ? 1 << 0 : 0;
 ~~^~~
   drivers/media/platform/renesas-ceu.c:335:6: note: 'camcr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
 ^
   drivers/media/platform/renesas-ceu.c: In function 'ceu_probe':
>> drivers/media/platform/renesas-ceu.c:1621:9: warning: 'ret' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 return ret;
^~~

vim +/cdwdr +287 drivers/media/platform/renesas-ceu.c

   284  
   285  static void ceu_write(struct ceu_device *priv, unsigned int reg_offs, 
u32 data)
   286  {
 > 287  iowrite32(data, priv->base + reg_offs);
   288  }
   289  
   290  static u32 ceu_read(struct ceu_device *priv, unsigned int reg_offs)
   291  {
   292  return ioread32(priv->base + reg_offs);
   293  }
   294  
   295  /*
   296   * ceu_soft_reset() - Software reset the CEU interface.
   297   * @ceu_device: CEU device.
   298   *
   299   * Returns 0 for success, -EIO for error.
   300   */
   301  static int ceu_soft_reset(struct ceu_device *ceudev)
   302  {
   303  unsigned int i;
   304  
   305  ceu_write(ceudev, CEU_CAPSR, CEU_CAPSR_CPKIL);
   306  
   307  for (i = 0; i < 100; i++) {
   308  if (!(ceu_read(ceudev, CEU_CSTSR) & CEU_CSTRST_CPTON))
   309  break;
   310  udelay(1);
   311  }
   312  
   313  if (i == 100) {
   314  dev_err(ceudev->dev, "soft reset time out\n");
   315  return -EIO;
   316  }
   317  
   318  for (i = 0; i < 100; i++) {
   319  if (!(ceu_read(ceudev, CEU_CAPSR) & CEU_CAPSR_CPKIL))
   320  return 0;
   321  udelay(1);
   322  }
   323  
   324  /* If we get here, CEU has not reset properly. */
   325  return -EIO;
   326  }
   327  
   328  /* --- CEU Capture Operations --- */
   329  
   330  /*
   331   * ceu_hw_config() - Configure CEU interface registers.
   332   */
   333  static int ceu_hw_config(struct ceu_device *ceudev)
   334  {
 > 335  u32 camcr, cdocr, cfzsr, cdwdr, capwr;
   336  struct v4l2_pix_format_mplane *pix = >v4l2_pix;
   337  struct ceu_subdev *ceu_sd = ceudev->sd;
   338  struct ceu_mbus_fmt *mbus_fmt = _sd->mbus_fmt;
   339  unsigned int mbus_flags = ceu_sd->mbus_flags;
   340  
   341  /* Start configuring CEU registers */
   342  ceu_write(ceudev, CEU_CAIFR, 0);
   343  ceu_write(ceudev, CEU_CFWCR, 0);
   344  ceu_write(ceudev, CEU_CRCNTR, 0);
   345  ceu_write(ceudev, CEU_CRCMPR, 0);
   346  
   347  /* Set the frame capture period for both image capture and data 
sync. */
   348  capwr = (pix->height << 16) | pix->width * mbus_fmt->bpp / 8;
   349

Re: [PATCH v5 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

[Randy Dunlap]

On 01/19/2018 01:17 PM, Icenowy Zheng wrote:
> 在 2018年1月20日星期六 CST 上午5:14:09，Rob Herring 写道：
>> On Thu, Jan 11, 2018 at 11:03:43AM +0800, Yong Deng wrote:
>>> Add binding documentation for Allwinner V3s CSI.
>>>
>>> Signed-off-by: Yong Deng 
>>> ---
>>>
>>>  .../devicetree/bindings/media/sun6i-csi.txt| 59
>>>  ++ 1 file changed, 59 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
>>
>> Reviewed-by: Rob Herring 
> 
> I think other subsystem's maintainer may expect a Acked-by from you here.
> 
> Why do you use Reviewed-by here instead?

The Reviewed-by: tag is a stronger ACK than the Acked-by: tag, so this
should be sufficient for other subsystem maintainers.

Please see Documentation/process/submitting-patches.rst, section 13.


-- 
~Randy

Re: [PATCH v6 0/9] Renesas Capture Engine Unit (CEU) V4L2 driver

[Randy Dunlap]

On 01/16/2018 01:44 PM, Jacopo Mondi wrote:
> Hello,
>new version of CEU after Hans' review.
> 
> Added his Acked-by to most patches and closed review comments.
> Running v4l2-compliance, I noticed a new failure introduced by the way I now
> calculate the plane sizes in set/try_fmt.

I would expect that you have already seen this, but I get a build error
in renesas-ceu.c.  Here is a small patch for it.

---
From: Randy Dunlap <rdun...@infradead.org>

Fix build error (on x86 with COMPILE_TEST):

../drivers/media/platform/renesas-ceu.c: In function 'ceu_parse_dt':
../drivers/media/platform/renesas-ceu.c:1497:27: error: request for member 
'fwnode' in something not a structure or union
   ceu_sd->asd.match.fwnode.fwnode =

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---
 drivers/media/platform/renesas-ceu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20180119.orig/drivers/media/platform/renesas-ceu.c
+++ linux-next-20180119/drivers/media/platform/renesas-ceu.c
@@ -1494,7 +1494,7 @@ static int ceu_parse_dt(struct ceu_devic
 
ceu_sd->mbus_flags = fw_ep.bus.parallel.flags;
ceu_sd->asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
-   ceu_sd->asd.match.fwnode.fwnode =
+   ceu_sd->asd.match.fwnode =
fwnode_graph_get_remote_port_parent(
of_fwnode_handle(ep));
 

Re: [PATCH v5 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

[Icenowy Zheng]

在 2018年1月20日星期六 CST 上午5:14:09，Rob Herring 写道：
> On Thu, Jan 11, 2018 at 11:03:43AM +0800, Yong Deng wrote:
> > Add binding documentation for Allwinner V3s CSI.
> > 
> > Signed-off-by: Yong Deng 
> > ---
> > 
> >  .../devicetree/bindings/media/sun6i-csi.txt| 59
> >  ++ 1 file changed, 59 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> 
> Reviewed-by: Rob Herring 

I think other subsystem's maintainer may expect a Acked-by from you here.

Why do you use Reviewed-by here instead?

> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

[Rob Herring]

On Thu, Jan 11, 2018 at 11:03:43AM +0800, Yong Deng wrote:
> Add binding documentation for Allwinner V3s CSI.
> 
> Signed-off-by: Yong Deng 
> ---
>  .../devicetree/bindings/media/sun6i-csi.txt| 59 
> ++
>  1 file changed, 59 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt

Reviewed-by: Rob Herring 

Re: [PATCH] media: v4l: omap_vout: vrfb: Use the wrapper for prep_interleaved_dma()

[Sakari Ailus]

Hi, Peter! :-)

How do you do?

On Fri, Jan 19, 2018 at 03:34:34PM +0200, Peter Ujfalusi wrote:
> Instead of directly accessing to dmadev->device_prep_interleaved_dma() use
> the dmaengine_prep_interleaved_dma() wrapper instead.
> 
> Signed-off-by: Peter Ujfalusi 

Acked-by: Sakari Ailus 

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

Re: SAA716x DVB driver

[Jemma Denson]

Hi Tycho,

On 19/01/18 13:59, Tycho Lürsen wrote:
> Hi Jemma,
>
> I'm with you: let's get merged at least something!
>
> Did you find  a maintainer for this driver?
> I can do simple stuff like in my fork of Soeren Moch's repo, but thats
> where it ends. I dont have the knowledge needed to maintain a driver.

Not yet, but I can't really say I've been looking - unfortunately real
life got in the way of anything over christmas. I'm not sure I do
either, but it really depends on what's required. From what I can see
from maintaining another driver then as long as the driver is working
there's not a whole lot to do.

>
> I think that your proposal to use a stripped version of Luis Alves
> repo is a no go, since it contains a couple of demod/tuner drivers
> that are not upstreamed yet. That complicates the upstreaming process
> too much, I think.

Oh, I would have stripped it *right* down and removed every card except
my TBS6280. The end result would probably be pretty close to Soeren's at
that point anyway, so I was starting to think like what you've done and
base it on that instead.

> I used a stripped version of Soeren Moch's repo to prove its stability
> instead, adding the drivers I need so I can test it. You can see what
> I did at :
> https://github.com/bas-t/linux-saa716x/commits/for-media-stripped
>
> This has been tested with linux 4.9.77, 4.14.14 and 4.15-rc8.
> Works like a charm for me.
>

Looks like a good start, I'd be tempted to remove all the other cards
though unless you have them available to test with. Keeps the submission
simpler and less to worry about, they can be added back in later if
someone has an itch to scratch (and hardware to test with!).

I do have a few other tbs 716x cards available here at work so might be
able to test some others out, but we're a bit busy at the moment so
would have to be on my own time and there's not much of that available
at the moment either :(


Jemma.

Re: [PATCH] media: intel-ipu3: cio2: fixup off-by-one bug in cio2_vb2_buf_init

[Sakari Ailus]

Hi Yong,

Thanks for the patch.

On Fri, Jan 19, 2018 at 12:27:34AM -0600, Yong Zhi wrote:
> With "pages" initialized to vb length + 1 pages, the condition
> check if(!pages--) will break at one more page than intended,
> this can result in out-of-bound access to b->lop[i][j] when setting
> the last dummy page.
> 
> Fix: commit c7cbef1fdb54 ("media: intel-ipu3: cio2: fix a crash with 
> out-of-bounds access")

Fixes: c7cbef1fdb54 ("media: intel-ipu3: cio2: fix a crash with out-of-bounds 
access")

I've applied the patch with that change.

> Signed-off-by: Yong Zhi 
> Signed-off-by: Cao Bing Bu 
> ---
>  drivers/media/pci/intel/ipu3/ipu3-cio2.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c 
> b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> index 9db752a7f363..8c9f8f56f5df 100644
> --- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> @@ -839,9 +839,8 @@ static int cio2_vb2_buf_init(struct vb2_buffer *vb)
>   container_of(vb, struct cio2_buffer, vbb.vb2_buf);
>   static const unsigned int entries_per_page =
>   CIO2_PAGE_SIZE / sizeof(u32);
> - unsigned int pages = DIV_ROUND_UP(vb->planes[0].length,
> -   CIO2_PAGE_SIZE) + 1;
> - unsigned int lops = DIV_ROUND_UP(pages, entries_per_page);
> + unsigned int pages = DIV_ROUND_UP(vb->planes[0].length, CIO2_PAGE_SIZE);
> + unsigned int lops = DIV_ROUND_UP(pages + 1, entries_per_page);
>   struct sg_table *sg;
>   struct sg_page_iter sg_iter;
>   int i, j;

-- 
Regards,

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

SAA716x DVB driver

[Tycho Lürsen]

Hi Jemma,

I'm with you: let's get merged at least something!

Did you find  a maintainer for this driver?
I can do simple stuff like in my fork of Soeren Moch's repo, but thats 
where it ends. I dont have the knowledge needed to maintain a driver.


I think that your proposal to use a stripped version of Luis Alves repo 
is a no go, since it contains a couple of demod/tuner drivers that are 
not upstreamed yet. That complicates the upstreaming process too much, I 
think.


I used a stripped version of Soeren Moch's repo to prove its stability 
instead, adding the drivers I need so I can test it. You can see what I 
did at : https://github.com/bas-t/linux-saa716x/commits/for-media-stripped


This has been tested with linux 4.9.77, 4.14.14 and 4.15-rc8.
Works like a charm for me.

[GIT PULL for 4.16] Last minute CIO2 fixes

[Sakari Ailus]

Hi Mauro,

Here are a couple of fixes for the Intel IPU3 CIO2 driver. One is
functional, another fixes a compiler warning.

Please pull.


The following changes since commit e3ee691dbf24096ea51b3200946b11d68ce75361:

  media: ov5640: add support of RGB565 and YUYV formats (2018-01-05 12:54:14 
-0500)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git ipu3

for you to fetch changes up to 8d677b031a4f5d7a5ead85b1ad2486721b4039c5:

  media: intel-ipu3: cio2: fixup off-by-one bug in cio2_vb2_buf_init 
(2018-01-19 15:49:16 +0200)


Arnd Bergmann (1):
  media: intel-ipu3: cio2: mark more PM functions as __maybe_unused

Yong Zhi (1):
  media: intel-ipu3: cio2: fixup off-by-one bug in cio2_vb2_buf_init

 drivers/media/pci/intel/ipu3/ipu3-cio2.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

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

Re: [PATCH v7 5/6] [media] vb2: add out-fence support to QBUF

[Gustavo Padovan]

2018-01-15 Alexandre Courbot :

> On Thu, Jan 11, 2018 at 1:07 AM, Gustavo Padovan  wrote:
> >  /*
> >   * vb2_start_streaming() - Attempt to start streaming.
> >   * @q: videobuf2 queue
> > @@ -1489,18 +1562,16 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
> > index, void *pb,
> > if (vb->in_fence) {
> > ret = dma_fence_add_callback(vb->in_fence, >fence_cb,
> >  vb2_qbuf_fence_cb);
> > -   if (ret == -EINVAL) {
> > +   /* is the fence signaled? */
> > +   if (ret == -ENOENT) {
> > +   dma_fence_put(vb->in_fence);
> > +   vb->in_fence = NULL;
> > +   } else if (ret) {
> > spin_unlock_irqrestore(>fence_cb_lock, flags);
> > goto err;
> > -   } else if (!ret) {
> > -   goto fill;
> > }
> > -
> > -   dma_fence_put(vb->in_fence);
> > -   vb->in_fence = NULL;
> 
> This chunk seems to deal with input fences, shouldn't it be part of
> the previous patch instead of this one?
> 
> >
> > -   if ((b->fence_fd != 0 && b->fence_fd != -1) &&
> > -   !(b->flags & V4L2_BUF_FLAG_IN_FENCE)) {
> > +   if (b->fence_fd > 0 && !(b->flags & V4L2_BUF_FLAG_IN_FENCE)) {
> > dprintk(1, "%s: fence_fd set without IN_FENCE flag\n", 
> > opname);
> > return -EINVAL;
> > }
> >
> > +   if (b->fence_fd == -1 && (b->flags & V4L2_BUF_FLAG_IN_FENCE)) {
> > +   dprintk(1, "%s: IN_FENCE flag set but no fence_fd\n", 
> > opname);
> > +   return -EINVAL;
> > +   }
> > +
> 
> Same here?
> 
> > return __verify_planes_array(q->bufs[b->index], b);
> >  }
> >
> > @@ -212,7 +216,12 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
> > void *pb)
> > b->sequence = vbuf->sequence;
> > b->reserved = 0;
> >
> > -   b->fence_fd = 0;
> > +   if (b->flags & V4L2_BUF_FLAG_OUT_FENCE) {
> > +   b->fence_fd = vb->out_fence_fd;
> > +   } else {
> > +   b->fence_fd = 0;
> > +   }
> 
> Sorry if this has already been discussed, but I don't remember the
> outcome if it has.
> 
> I wonder if doing this here could not make out_fence_fd leak in
> situations where we don't need/want it to. Let's take for instance a
> multi-process user program. One process queues a buffer with an
> OUT_FENCE and gets a valid fd in fence_fd upon return. Then the other
> process performs a QUERYBUF and gets the same fence_fd - which is
> invalid in its context. Would it not be preferable fill the out fence
> information only when queuing buffers, since it is the only time where
> we are guaranteed it will be usable by the caller?
> 
> Similarly, when a buffer is processed and user-space performs a DQBUF,
> the V4L2_BUF_FLAG_OUT_FENCE will be set but fence_fd will be 0. Again,
> limiting the return of out fence information to QBUF would prevent
> this.

Right. So in summary as this is something Hans commented on another
e-mail in this thread.

Your proposal is to only return the out_fence fd number on QBUF, right?
And DQBUF and QUERYBUF would only return -1 in the fence_fd field.

What I understood from Hans comment is that he is okay with sharing the
fd in such cases and v4l2 already does that for dmabuf fds.

I believe sharing is okay, as it will be either the same process or a
process we gave the device fd in the first place.

I'm not invested in any particular approach here. Thoughts?

> 
> If we go that route, out_fence_fd could maybe become a local variable
> of vb2_qbuf() instead of being a member of vb2_buffer, and would be
> returned by vb2_setup_out_fence(). This would guarantee it does not
> leak anywhere else.


Gustavo

[PATCH] media: v4l: omap_vout: vrfb: Use the wrapper for prep_interleaved_dma()

[Peter Ujfalusi]

Instead of directly accessing to dmadev->device_prep_interleaved_dma() use
the dmaengine_prep_interleaved_dma() wrapper instead.

Signed-off-by: Peter Ujfalusi 
---
 drivers/media/platform/omap/omap_vout_vrfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c 
b/drivers/media/platform/omap/omap_vout_vrfb.c
index 123c2b26a933..72c0ac2cbf3d 100644
--- a/drivers/media/platform/omap/omap_vout_vrfb.c
+++ b/drivers/media/platform/omap/omap_vout_vrfb.c
@@ -271,7 +271,7 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
xt->dst_sgl = true;
xt->dst_inc = true;
 
-   tx = dmadev->device_prep_interleaved_dma(chan, xt, flags);
+   tx = dmaengine_prep_interleaved_dma(chan, xt, flags);
if (tx == NULL) {
pr_err("%s: DMA interleaved prep error\n", __func__);
return -EINVAL;
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v7 5/6] [media] vb2: add out-fence support to QBUF

[Gustavo Padovan]

2018-01-12 Hans Verkuil :

> On 01/10/18 17:07, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
> > an out_fence and send its fd to userspace on the fence_fd field as a
> > return arg for the QBUF call.
> > 
> > The fence is signaled on buffer_done(), when the job on the buffer is
> > finished.
> > 
> > v8:
> > - return 0 as fence_fd if OUT_FENCE flag not used (Mauro)
> > - fix crash when checking not using fences in vb2_buffer_done()
> > 
> > v7:
> > - merge patch that add the infrastructure to out-fences into
> > this one (Alex Courbot)
> > - Do not install the fd if there is no fence. (Alex Courbot)
> > - do not report error on requeueing, just WARN_ON_ONCE() (Hans)
> > 
> > v6
> > - get rid of the V4L2_EVENT_OUT_FENCE event. We always keep the
> > ordering in vb2 for queueing in the driver, so the event is not
> > necessary anymore and the out_fence_fd is sent back to userspace
> > on QBUF call return arg
> > - do not allow requeueing with out-fences, instead mark the buffer
> > with an error and wake up to userspace.
> > - send the out_fence_fd back to userspace on the fence_fd field
> > 
> > v5:
> > - delay fd_install to DQ_EVENT (Hans)
> > - if queue is fully ordered send OUT_FENCE event right away
> > (Brian)
> > - rename 'q->ordered' to 'q->ordered_in_driver'
> > - merge change to implement OUT_FENCE event here
> > 
> > v4:
> > - return the out_fence_fd in the BUF_QUEUED event(Hans)
> > 
> > v3: - add WARN_ON_ONCE(q->ordered) on requeueing (Hans)
> > - set the OUT_FENCE flag if there is a fence pending (Hans)
> > - call fd_install() after vb2_core_qbuf() (Hans)
> > - clean up fence if vb2_core_qbuf() fails (Hans)
> > - add list to store sync_file and fence for the next queued buffer
> > 
> > v2: check if the queue is ordered.
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/media/common/videobuf/videobuf2-core.c | 101 
> > +++--
> >  drivers/media/common/videobuf/videobuf2-v4l2.c |  28 ++-
> >  include/media/videobuf2-core.h |  22 ++
> >  3 files changed, 140 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/media/common/videobuf/videobuf2-core.c 
> > b/drivers/media/common/videobuf/videobuf2-core.c
> > index 777e3a2bc746..1f30d9efb7c8 100644
> > --- a/drivers/media/common/videobuf/videobuf2-core.c
> > +++ b/drivers/media/common/videobuf/videobuf2-core.c
> > @@ -25,6 +25,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -357,6 +358,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
> > vb2_memory memory,
> > vb->planes[plane].length = plane_sizes[plane];
> > vb->planes[plane].min_length = plane_sizes[plane];
> > }
> > +   vb->out_fence_fd = -1;
> > q->bufs[vb->index] = vb;
> >  
> > /* Allocate video buffer memory for the MMAP type */
> > @@ -939,10 +941,22 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
> > vb2_buffer_state state)
> > case VB2_BUF_STATE_QUEUED:
> > break;
> > case VB2_BUF_STATE_REQUEUEING:
> > +   /* Requeuing with explicit synchronization, spit warning */
> > +   WARN_ON_ONCE(vb->out_fence);
> > +
> > if (q->start_streaming_called)
> > __enqueue_in_driver(vb);
> > -   return;
> > +   break;
> > default:
> > +   if (vb->out_fence) {
> > +   if (state == VB2_BUF_STATE_ERROR)
> > +   dma_fence_set_error(vb->out_fence, -EFAULT);
> > +   dma_fence_signal(vb->out_fence);
> > +   dma_fence_put(vb->out_fence);
> > +   vb->out_fence = NULL;
> > +   vb->out_fence_fd = -1;
> > +   }
> > +
> > /* Inform any processes that may be waiting for buffers */
> > wake_up(>done_wq);
> > break;
> > @@ -1341,6 +1355,65 @@ int vb2_core_prepare_buf(struct vb2_queue *q, 
> > unsigned int index, void *pb)
> >  }
> >  EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
> >  
> > +static inline const char *vb2_fence_get_driver_name(struct dma_fence 
> > *fence)
> > +{
> > +   return "vb2_fence";
> > +}
> > +
> > +static inline const char *vb2_fence_get_timeline_name(struct dma_fence 
> > *fence)
> > +{
> > +   return "vb2_fence_timeline";
> > +}
> > +
> > +static inline bool vb2_fence_enable_signaling(struct dma_fence *fence)
> > +{
> > +   return true;
> > +}
> > +
> > +static const struct dma_fence_ops vb2_fence_ops = {
> > +   .get_driver_name = vb2_fence_get_driver_name,
> > +   .get_timeline_name = vb2_fence_get_timeline_name,
> > +   .enable_signaling = vb2_fence_enable_signaling,
> > +   .wait = 

Re: [PATCH v6 3/9] v4l: platform: Add Renesas CEU driver

[Hans Verkuil]

On 01/19/18 13:20, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Friday, 19 January 2018 13:20:19 EET Hans Verkuil wrote:
>> On 01/16/18 22:44, Jacopo Mondi wrote:
>>> Add driver for Renesas Capture Engine Unit (CEU).
>>>
>>> The CEU interface supports capturing 'data' (YUV422) and 'images'
>>> (NV[12|21|16|61]).
>>>
>>> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
>>>
>>> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
>>> platform GR-Peach.
>>>
>>> Tested with ov7725 camera sensor on SH4 platform Migo-R.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Laurent Pinchart 
>>> ---
>>>
>>>  drivers/media/platform/Kconfig   |9 +
>>>  drivers/media/platform/Makefile  |1 +
>>>  drivers/media/platform/renesas-ceu.c | 1659 +
>>>  3 files changed, 1669 insertions(+)
>>>  create mode 100644 drivers/media/platform/renesas-ceu.c
> 
> [snip]
> 
>>> diff --git a/drivers/media/platform/renesas-ceu.c
>>> b/drivers/media/platform/renesas-ceu.c new file mode 100644
>>> index 000..1b8f0ef
>>> --- /dev/null
>>> +++ b/drivers/media/platform/renesas-ceu.c
> 
> [snip]
> 
>>> +static void ceu_update_plane_sizes(struct v4l2_plane_pix_format *plane,
>>> +  unsigned int bpl, unsigned int szimage)
>>> +{
>>> +   if (plane->bytesperline < bpl)
>>> +   plane->bytesperline = bpl;
>>> +   if (plane->sizeimage < szimage)
>>> +   plane->sizeimage = szimage;
>>
>> As mentioned in your cover letter, you do need to check for invalid
>> bytesperline values. The v4l2-compliance test is to see what happens
>> when userspace gives insane values, so yes, drivers need to be able
>> to handle that.
> 
> What limit would you set, what is an acceptable large value versus an invalid 
> large value ? I think we should have rules for this at the API level (or at 
> least, if not part of the API, rules that are consistent across drivers).

I would expect this to be the max of what the hardware can support. If
that's really high, then this can be, say, 4 times the width.

Note that there are very few drivers that can handle a user-specified
stride.

>> plane->sizeimage is set by the driver, so drop the 'if' before the
>> assignment.
> 
> I don't think that's correct. Userspace should be able to control padding 
> lines at the end of the image, the same way it controls padding pixels at the 
> end of lines.

If userspace wants larger buffers, then it should use VIDIOC_CREATE_BUFS.

sizeimage is exclusively set by the driver, applications rely on that.

> 
>>> +}
> 
> [snip]
> 
>>> +static const struct v4l2_ioctl_ops ceu_ioctl_ops = {
>>> +   .vidioc_querycap= ceu_querycap,
>>> +
>>> +   .vidioc_enum_fmt_vid_cap_mplane = ceu_enum_fmt_vid_cap,
>>> +   .vidioc_try_fmt_vid_cap_mplane  = ceu_try_fmt_vid_cap,
>>> +   .vidioc_s_fmt_vid_cap_mplane= ceu_s_fmt_vid_cap,
>>> +   .vidioc_g_fmt_vid_cap_mplane= ceu_g_fmt_vid_cap,
>>> +
>>> +   .vidioc_enum_input  = ceu_enum_input,
>>> +   .vidioc_g_input = ceu_g_input,
>>> +   .vidioc_s_input = ceu_s_input,
>>> +
>>> +   .vidioc_reqbufs = vb2_ioctl_reqbufs,
>>> +   .vidioc_querybuf= vb2_ioctl_querybuf,
>>> +   .vidioc_qbuf= vb2_ioctl_qbuf,
>>> +   .vidioc_expbuf  = vb2_ioctl_expbuf,
>>> +   .vidioc_dqbuf   = vb2_ioctl_dqbuf,
>>> +   .vidioc_create_bufs = vb2_ioctl_create_bufs,
>>> +   .vidioc_prepare_buf = vb2_ioctl_prepare_buf,
>>> +   .vidioc_streamon= vb2_ioctl_streamon,
>>> +   .vidioc_streamoff   = vb2_ioctl_streamoff,
>>> +
>>> +   .vidioc_g_parm  = ceu_g_parm,
>>> +   .vidioc_s_parm  = ceu_s_parm,
>>> +   .vidioc_enum_framesizes = ceu_enum_framesizes,
>>> +   .vidioc_enum_frameintervals = ceu_enum_frameintervals,
>>
>> You're missing these ioctls:
>>
>> .vidioc_log_status  = v4l2_ctrl_log_status,
> 
> Is log status mandatory ?

No, but it doesn't hurt to add this one. It comes for free.

> 
>> .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
>> .vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
>>
>> These missing _event ops are the reason for this compliance failure:
>>
>> fail: v4l2-test-controls.cpp(782): subscribe event for control 'User
>> Controls' failed
>>> +};
> 
> [snip]
> 

Regards,

Hans

Re: [PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies

[Laurent Pinchart]

Hello,

On Friday, 19 January 2018 13:19:18 EET Sakari Ailus wrote:
> On Fri, Jan 19, 2018 at 11:47:33AM +0100, Hans Verkuil wrote:
> > On 01/19/18 11:24, Hans Verkuil wrote:
> >> On 01/16/18 22:44, Jacopo Mondi wrote:
> >>> Remove soc_camera framework dependencies from ov772x sensor driver.
> >>> - Handle clock and gpios
> >>> - Register async subdevice
> >>> - Remove soc_camera specific g/s_mbus_config operations
> >>> - Change image format colorspace from JPEG to SRGB as the two use the
> >>>   same colorspace information but JPEG makes assumptions on color
> >>>   components quantization that do not apply to the sensor
> >>> - Remove sizes crop from get_selection as driver can't scale
> >>> - Add kernel doc to driver interface header file
> >>> - Adjust build system
> >>> 
> >>> This commit does not remove the original soc_camera based driver as
> >>> long as other platforms depends on soc_camera-based CEU driver.
> >>> 
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Laurent Pinchart 
> >> 
> >> Acked-by: Hans Verkuil 
> > 
> > Un-acked.
> > 
> > I just noticed that this sensor driver has no enum_frame_interval and
> > g/s_parm support. How would a driver ever know the frame rate of the
> > sensor without that?
> 
> s/_parm/_frame_interval/ ?
> 
> We should have wrappers for this or rather to convert g/s_parm users to
> g/s_frame_interval so drivers don't need to implement both.

There are two ways to set the frame interval, either explicitly through the 
s_frame_interval operation, or implicitly through control of the pixel clock, 
horizontal blanking and vertical blanking (which in turn can be influenced by 
the exposure time).

Having two ways to perform the same operation seems sub-optimal to me, but I 
could understand if they covered different use cases. As far as I know we 
don't document the use cases for those methods. What's your opinion on that ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH v6 3/9] v4l: platform: Add Renesas CEU driver

[Laurent Pinchart]

Hi Hans,

On Friday, 19 January 2018 13:20:19 EET Hans Verkuil wrote:
> On 01/16/18 22:44, Jacopo Mondi wrote:
> > Add driver for Renesas Capture Engine Unit (CEU).
> > 
> > The CEU interface supports capturing 'data' (YUV422) and 'images'
> > (NV[12|21|16|61]).
> > 
> > This driver aims to replace the soc_camera-based sh_mobile_ceu one.
> > 
> > Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> > platform GR-Peach.
> > 
> > Tested with ov7725 camera sensor on SH4 platform Migo-R.
> > 
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Laurent Pinchart 
> > ---
> > 
> >  drivers/media/platform/Kconfig   |9 +
> >  drivers/media/platform/Makefile  |1 +
> >  drivers/media/platform/renesas-ceu.c | 1659 +
> >  3 files changed, 1669 insertions(+)
> >  create mode 100644 drivers/media/platform/renesas-ceu.c

[snip]

> > diff --git a/drivers/media/platform/renesas-ceu.c
> > b/drivers/media/platform/renesas-ceu.c new file mode 100644
> > index 000..1b8f0ef
> > --- /dev/null
> > +++ b/drivers/media/platform/renesas-ceu.c

[snip]

> > +static void ceu_update_plane_sizes(struct v4l2_plane_pix_format *plane,
> > +  unsigned int bpl, unsigned int szimage)
> > +{
> > +   if (plane->bytesperline < bpl)
> > +   plane->bytesperline = bpl;
> > +   if (plane->sizeimage < szimage)
> > +   plane->sizeimage = szimage;
> 
> As mentioned in your cover letter, you do need to check for invalid
> bytesperline values. The v4l2-compliance test is to see what happens
> when userspace gives insane values, so yes, drivers need to be able
> to handle that.

What limit would you set, what is an acceptable large value versus an invalid 
large value ? I think we should have rules for this at the API level (or at 
least, if not part of the API, rules that are consistent across drivers).

> plane->sizeimage is set by the driver, so drop the 'if' before the
> assignment.

I don't think that's correct. Userspace should be able to control padding 
lines at the end of the image, the same way it controls padding pixels at the 
end of lines.

> > +}

[snip]

> > +static const struct v4l2_ioctl_ops ceu_ioctl_ops = {
> > +   .vidioc_querycap= ceu_querycap,
> > +
> > +   .vidioc_enum_fmt_vid_cap_mplane = ceu_enum_fmt_vid_cap,
> > +   .vidioc_try_fmt_vid_cap_mplane  = ceu_try_fmt_vid_cap,
> > +   .vidioc_s_fmt_vid_cap_mplane= ceu_s_fmt_vid_cap,
> > +   .vidioc_g_fmt_vid_cap_mplane= ceu_g_fmt_vid_cap,
> > +
> > +   .vidioc_enum_input  = ceu_enum_input,
> > +   .vidioc_g_input = ceu_g_input,
> > +   .vidioc_s_input = ceu_s_input,
> > +
> > +   .vidioc_reqbufs = vb2_ioctl_reqbufs,
> > +   .vidioc_querybuf= vb2_ioctl_querybuf,
> > +   .vidioc_qbuf= vb2_ioctl_qbuf,
> > +   .vidioc_expbuf  = vb2_ioctl_expbuf,
> > +   .vidioc_dqbuf   = vb2_ioctl_dqbuf,
> > +   .vidioc_create_bufs = vb2_ioctl_create_bufs,
> > +   .vidioc_prepare_buf = vb2_ioctl_prepare_buf,
> > +   .vidioc_streamon= vb2_ioctl_streamon,
> > +   .vidioc_streamoff   = vb2_ioctl_streamoff,
> > +
> > +   .vidioc_g_parm  = ceu_g_parm,
> > +   .vidioc_s_parm  = ceu_s_parm,
> > +   .vidioc_enum_framesizes = ceu_enum_framesizes,
> > +   .vidioc_enum_frameintervals = ceu_enum_frameintervals,
> 
> You're missing these ioctls:
> 
> .vidioc_log_status  = v4l2_ctrl_log_status,

Is log status mandatory ?

> .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
> .vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
> 
> These missing _event ops are the reason for this compliance failure:
> 
> fail: v4l2-test-controls.cpp(782): subscribe event for control 'User
> Controls' failed
> > +};

[snip]

-- 
Regards,

Laurent Pinchart

Re: pull request: linux-firmware: Update Mediatek MT8173 VPU firmware

[Josh Boyer]

On Wed, Jan 17, 2018 at 8:35 AM,   wrote:
> The following changes since commit 65b1c68c63f974d72610db38dfae49861117cae2:
>
>   wl18xx: update firmware file 8.9.0.0.76 (2018-01-04 10:06:01 -0500)
>
> are available in the git repository at:
>
>   https://github.com/pochun-lin/linux_fw_vpu_v1.0.8.git v1.0.8
>
> for you to fetch changes up to e72c23c9ff2ceeb3509cb6441cc81f0227edf06d:
>
>   mediatek: update MT8173 VPU firmware to 1.0.8 (2018-01-17 20:19:56 +0800)
>
> 
> pochun.lin (1):
>   mediatek: update MT8173 VPU firmware to 1.0.8

Pulled and pushed out.  If the firmware is versioned, perhaps that
version should be listed in the WHENCE file?  You might want to add
that in a future patch.

josh

Investment opportunity

[Yi Tan]

Greetings,

Please find the content of this mail very confidential. my name is Yi 
Tan, I work with a Bank here in Hong Kong. I decided to contact you for 
an

opportunity to invest in any lucrative business in your country.

We also offer a quick loan at low interest rate if you are interested 
please reply me for more information on my private e-mail: 
yitanelectro...@gmail.com


Sincerely: Yi Tan

Re: [PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies

[Hans Verkuil]

On 01/19/18 12:19, Sakari Ailus wrote:
> Hi Hans,
> 
> On Fri, Jan 19, 2018 at 11:47:33AM +0100, Hans Verkuil wrote:
>> On 01/19/18 11:24, Hans Verkuil wrote:
>>> On 01/16/18 22:44, Jacopo Mondi wrote:
 Remove soc_camera framework dependencies from ov772x sensor driver.
 - Handle clock and gpios
 - Register async subdevice
 - Remove soc_camera specific g/s_mbus_config operations
 - Change image format colorspace from JPEG to SRGB as the two use the
   same colorspace information but JPEG makes assumptions on color
   components quantization that do not apply to the sensor
 - Remove sizes crop from get_selection as driver can't scale
 - Add kernel doc to driver interface header file
 - Adjust build system

 This commit does not remove the original soc_camera based driver as long
 as other platforms depends on soc_camera-based CEU driver.

 Signed-off-by: Jacopo Mondi 
 Reviewed-by: Laurent Pinchart 
>>>
>>> Acked-by: Hans Verkuil 
>>
>> Un-acked.
>>
>> I just noticed that this sensor driver has no enum_frame_interval and
>> g/s_parm support. How would a driver ever know the frame rate of the
>> sensor without that?
> 
> s/_parm/_frame_interval/ ?

Yes.

> 
> We should have wrappers for this or rather to convert g/s_parm users to
> g/s_frame_interval so drivers don't need to implement both.

We should convert them. I wonder why we didn't?

Regards,

Hans

Re: [PATCH v6 0/9] Renesas Capture Engine Unit (CEU) V4L2 driver

[Hans Verkuil]

Hi Jacopo,

On 01/16/18 22:44, Jacopo Mondi wrote:
> Hello,
>new version of CEU after Hans' review.
> 
> Added his Acked-by to most patches and closed review comments.
> Running v4l2-compliance, I noticed a new failure introduced by the way I now
> calculate the plane sizes in set/try_fmt.
> 
> This is the function used to update per-plane bytesperline and sizeimage:
> 
> static void ceu_update_plane_sizes(struct v4l2_plane_pix_format *plane,
>  unsigned int bpl, unsigned int szimage)
> {
>   if (plane->bytesperline < bpl)
>   plane->bytesperline = bpl;
>   if (plane->sizeimage < szimage)
>   plane->sizeimage = szimage;
> }
> 
> I'm seeing a failure as v4l2-compliance requires buffers with both 
> bytesperline
> and sizeimage set to MAX_INT . Hans, is this expected from v4l2-compliance?
> How should I handle this, if that has to be handled by the single drivers?

I commented on this in my review of patch 3/9.

> 
> Apart from that, here it is the output of v4l2-compliance, with the last tests
> failing due to the above stated reason, and two errors in try/set format due 
> to
> the fact the driver is not setting ycbcr encoding after it receives an invalid

Which driver? The CEU driver or the sensor driver? I don't actually see where
it fails.

> format. I would set those, but I'm not sure what it the correct value and not
> all mainline drivers do that.

In any case, the default for ycbcr_enc, xfer_func and quantization is 0.

> 
> ---
> v4l2-compliance SHA   : 1d3c611dee82090d9456730e24af368b51dcb4a9

I can't find this SHA in the v4l-utils repo. You should always compile
v4l2-compliance from the master branch.

Also test with 'v4l2-compliance -f': this tests streaming in all formats.

> 
> Driver Info:
>   Driver name   : renesas-ceu
>   Card type : Renesas CEU e821.ceu
>   Bus info  : platform:renesas-ceu-e821.c
>   Driver version: 4.14.0
>   Capabilities  : 0x84201000
>   Video Capture Multiplanar
>   Streaming
>   Extended Pix Format
>   Device Capabilities
>   Device Caps   : 0x04201000
>   Video Capture Multiplanar
>   Streaming
>   Extended Pix Format
> 
> Compliance test for device /dev/video0 (not using libv4l2):
> 
> Required ioctls:
>   test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
>   test second video open: OK
>   test VIDIOC_QUERYCAP: OK
>   test VIDIOC_G/S_PRIORITY: OK
>   test for unlimited opens: OK
> 
> Debug ioctls:
>   test VIDIOC_DBG_G/S_REGISTER: OK
>   test VIDIOC_LOG_STATUS: OK (Not Supported)
> 
> Input ioctls:
>   test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>   test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>   test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>   test VIDIOC_ENUMAUDIO: OK (Not Supported)
>   test VIDIOC_G/S/ENUMINPUT: OK
>   test VIDIOC_G/S_AUDIO: OK (Not Supported)
>   Inputs: 1 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
>   test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>   test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>   test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>   test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>   test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>   Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
>   test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>   test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>   test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>   test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Test input 0:
> 
>   Control ioctls:
>   test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
>   test VIDIOC_QUERYCTRL: OK
>   test VIDIOC_G/S_CTRL: OK
>   test VIDIOC_G/S/TRY_EXT_CTRLS: OK
>   fail: v4l2-test-controls.cpp(782): subscribe event for control 
> 'User Controls' failed
>   test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
>   test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>   Standard Controls: 12 Private Controls: 0
> 
>   Format ioctls:
>   test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>   fail: v4l2-test-formats.cpp(1162): ret && node->has_frmintervals
>   test VIDIOC_G/S_PARM: FAIL
>   test VIDIOC_G_FBUF: OK (Not Supported)
>   test VIDIOC_G_FMT: OK
>   fail: v4l2-test-formats.cpp(335): ycbcr_enc >= 0xff
>   fail: v4l2-test-formats.cpp(451): 
> testColorspace(pix_mp.pixelformat, pix_mp.colorspace, pix_mp.ycbcr_enc, 
> pix_mp.quantization)
>   fail: v4l2-test-formats.cpp(736): Video Capture Multiplanar is 
> valid, but TRY_FMT failed to return a format
>   test VIDIOC_TRY_FMT: FAIL
>   fail: 

Re: [PATCH v6 3/9] v4l: platform: Add Renesas CEU driver

[Hans Verkuil]

Some more comments:

On 01/16/18 22:44, Jacopo Mondi wrote:
> Add driver for Renesas Capture Engine Unit (CEU).
> 
> The CEU interface supports capturing 'data' (YUV422) and 'images'
> (NV[12|21|16|61]).
> 
> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
> 
> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> platform GR-Peach.
> 
> Tested with ov7725 camera sensor on SH4 platform Migo-R.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Laurent Pinchart 
> ---
>  drivers/media/platform/Kconfig   |9 +
>  drivers/media/platform/Makefile  |1 +
>  drivers/media/platform/renesas-ceu.c | 1659 
> ++
>  3 files changed, 1669 insertions(+)
>  create mode 100644 drivers/media/platform/renesas-ceu.c
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index fd0c998..fe7bd26 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
> To compile this driver as a module, choose M here: the module
> will be called stm32-dcmi.
>  
> +config VIDEO_RENESAS_CEU
> + tristate "Renesas Capture Engine Unit (CEU) driver"
> + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> + depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_FWNODE
> + ---help---
> +   This is a v4l2 driver for the Renesas CEU Interface
> +
>  source "drivers/media/platform/soc_camera/Kconfig"
>  source "drivers/media/platform/exynos4-is/Kconfig"
>  source "drivers/media/platform/am437x/Kconfig"
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 003b0bb..6580a6b 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -62,6 +62,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)  += sh_vou.o
>  obj-$(CONFIG_SOC_CAMERA) += soc_camera/
>  
>  obj-$(CONFIG_VIDEO_RCAR_DRIF)+= rcar_drif.o
> +obj-$(CONFIG_VIDEO_RENESAS_CEU)  += renesas-ceu.o
>  obj-$(CONFIG_VIDEO_RENESAS_FCP)  += rcar-fcp.o
>  obj-$(CONFIG_VIDEO_RENESAS_FDP1) += rcar_fdp1.o
>  obj-$(CONFIG_VIDEO_RENESAS_JPU)  += rcar_jpu.o
> diff --git a/drivers/media/platform/renesas-ceu.c 
> b/drivers/media/platform/renesas-ceu.c
> new file mode 100644
> index 000..1b8f0ef
> --- /dev/null
> +++ b/drivers/media/platform/renesas-ceu.c
> @@ -0,0 +1,1659 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
> + * Copyright (C) 2017-2018 Jacopo Mondi 
> + *
> + * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
> + * Copyright (C) 2008 Magnus Damm
> + *
> + * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
> + * Copyright (C) 2006, Sascha Hauer, Pengutronix
> + * Copyright (C) 2008, Guennadi Liakhovetski 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define DRIVER_NAME  "renesas-ceu"
> +
> +/* CEU registers offsets and masks. */
> +#define CEU_CAPSR0x00 /* Capture start register  */
> +#define CEU_CAPCR0x04 /* Capture control register*/
> +#define CEU_CAMCR0x08 /* Capture interface control register  */
> +#define CEU_CAMOR0x10 /* Capture interface offset register   */
> +#define CEU_CAPWR0x14 /* Capture interface width register*/
> +#define CEU_CAIFR0x18 /* Capture interface input format register */
> +#define CEU_CRCNTR   0x28 /* CEU register control register   */
> +#define CEU_CRCMPR   0x2c /* CEU register forcible control register  */
> +#define CEU_CFLCR0x30 /* Capture filter control register */
> +#define CEU_CFSZR0x34 /* Capture filter size clip register   */
> +#define CEU_CDWDR0x38 /* Capture destination width register  */
> +#define CEU_CDAYR0x3c /* Capture data address Y register */
> +#define CEU_CDACR0x40 /* Capture data address C register */
> +#define CEU_CFWCR0x5c /* Firewall operation control register */
> +#define CEU_CDOCR0x64 /* Capture data output control register*/
> +#define CEU_CEIER0x70 /* Capture event interrupt enable register */
> +#define CEU_CETCR0x74 /* Capture event flag clear register   */
> +#define CEU_CSTSR0x7c /* Capture status register */
> +#define CEU_CSRTR0x80 /* Capture software reset register */
> +
> +/* Data synchronous fetch mode. */
> +#define 

Re: [PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies

[Sakari Ailus]

Hi Hans,

On Fri, Jan 19, 2018 at 11:47:33AM +0100, Hans Verkuil wrote:
> On 01/19/18 11:24, Hans Verkuil wrote:
> > On 01/16/18 22:44, Jacopo Mondi wrote:
> >> Remove soc_camera framework dependencies from ov772x sensor driver.
> >> - Handle clock and gpios
> >> - Register async subdevice
> >> - Remove soc_camera specific g/s_mbus_config operations
> >> - Change image format colorspace from JPEG to SRGB as the two use the
> >>   same colorspace information but JPEG makes assumptions on color
> >>   components quantization that do not apply to the sensor
> >> - Remove sizes crop from get_selection as driver can't scale
> >> - Add kernel doc to driver interface header file
> >> - Adjust build system
> >>
> >> This commit does not remove the original soc_camera based driver as long
> >> as other platforms depends on soc_camera-based CEU driver.
> >>
> >> Signed-off-by: Jacopo Mondi 
> >> Reviewed-by: Laurent Pinchart 
> > 
> > Acked-by: Hans Verkuil 
> 
> Un-acked.
> 
> I just noticed that this sensor driver has no enum_frame_interval and
> g/s_parm support. How would a driver ever know the frame rate of the
> sensor without that?

s/_parm/_frame_interval/ ?

We should have wrappers for this or rather to convert g/s_parm users to
g/s_frame_interval so drivers don't need to implement both.

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

[PATCH 1/1] ov2685: Assign ret in default case in s_ctrl callback

[Sakari Ailus]

Assign ret in the default case for s_ctrl callback. This can't happen but
still may result in compiler warnings.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/ov2685.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/i2c/ov2685.c b/drivers/media/i2c/ov2685.c
index df4abecd8d74..904ac305d499 100644
--- a/drivers/media/i2c/ov2685.c
+++ b/drivers/media/i2c/ov2685.c
@@ -574,6 +574,7 @@ static int ov2685_set_ctrl(struct v4l2_ctrl *ctrl)
default:
dev_warn(>dev, "%s Unhandled id:0x%x, val:0x%x\n",
 __func__, ctrl->id, ctrl->val);
+   ret = -EINVAL;
break;
};
 
-- 
2.11.0

Re: [PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies

[Hans Verkuil]

On 01/19/18 11:24, Hans Verkuil wrote:
> On 01/16/18 22:44, Jacopo Mondi wrote:
>> Remove soc_camera framework dependencies from ov772x sensor driver.
>> - Handle clock and gpios
>> - Register async subdevice
>> - Remove soc_camera specific g/s_mbus_config operations
>> - Change image format colorspace from JPEG to SRGB as the two use the
>>   same colorspace information but JPEG makes assumptions on color
>>   components quantization that do not apply to the sensor
>> - Remove sizes crop from get_selection as driver can't scale
>> - Add kernel doc to driver interface header file
>> - Adjust build system
>>
>> This commit does not remove the original soc_camera based driver as long
>> as other platforms depends on soc_camera-based CEU driver.
>>
>> Signed-off-by: Jacopo Mondi 
>> Reviewed-by: Laurent Pinchart 
> 
> Acked-by: Hans Verkuil 

Un-acked.

I just noticed that this sensor driver has no enum_frame_interval and
g/s_parm support. How would a driver ever know the frame rate of the
sensor without that?

This looks like a bug to me.

Regards,

Hans

Re: [PATCH v6 6/9] media: i2c: ov772x: Remove soc_camera dependencies

[Hans Verkuil]

On 01/16/18 22:44, Jacopo Mondi wrote:
> Remove soc_camera framework dependencies from ov772x sensor driver.
> - Handle clock and gpios
> - Register async subdevice
> - Remove soc_camera specific g/s_mbus_config operations
> - Change image format colorspace from JPEG to SRGB as the two use the
>   same colorspace information but JPEG makes assumptions on color
>   components quantization that do not apply to the sensor
> - Remove sizes crop from get_selection as driver can't scale
> - Add kernel doc to driver interface header file
> - Adjust build system
> 
> This commit does not remove the original soc_camera based driver as long
> as other platforms depends on soc_camera-based CEU driver.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Laurent Pinchart 

Acked-by: Hans Verkuil 

Regards,

Hans

[PATCH 1/1] imx258: Fix sparse warnings

[Sakari Ailus]

Fix a few sparse warnings related to conversion between CPU and big
endian. Also simplify the code in the process.

Signed-off-by: Sakari Ailus 
---
Hi Andy,

There were a few issues Sparse found in the imx258 driver. Could you
test the patch, please?

 drivers/media/i2c/imx258.c | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index a7e58bd23de7..b73c25ae8725 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -440,10 +440,10 @@ static int imx258_read_reg(struct imx258 *imx258, u16 
reg, u32 len, u32 *val)
 {
struct i2c_client *client = v4l2_get_subdevdata(>sd);
struct i2c_msg msgs[2];
+   __be16 reg_addr_be = cpu_to_be16(reg);
+   __be32 data_be = 0;
u8 *data_be_p;
int ret;
-   u32 data_be = 0;
-   u16 reg_addr_be = cpu_to_be16(reg);
 
if (len > 4)
return -EINVAL;
@@ -474,22 +474,17 @@ static int imx258_read_reg(struct imx258 *imx258, u16 
reg, u32 len, u32 *val)
 static int imx258_write_reg(struct imx258 *imx258, u16 reg, u32 len, u32 val)
 {
struct i2c_client *client = v4l2_get_subdevdata(>sd);
-   int buf_i, val_i;
-   u8 buf[6], *val_p;
+   u8 __buf[6], *buf = __buf;
+   int i;
 
if (len > 4)
return -EINVAL;
 
-   buf[0] = reg >> 8;
-   buf[1] = reg & 0xff;
+   *buf++ = reg >> 8;
+   *buf++ = reg & 0xff;
 
-   val = cpu_to_be32(val);
-   val_p = (u8 *)
-   buf_i = 2;
-   val_i = 4 - len;
-
-   while (val_i < 4)
-   buf[buf_i++] = val_p[val_i++];
+   for (i = len - 1; i >= 0; i++)
+   *buf++ = (u8)(val >> (i << 3));
 
if (i2c_master_send(client, buf, len + 2) != len + 2)
return -EIO;
-- 
2.11.0

Re: [PATCH v4] media: imx258: Add imx258 camera sensor driver

[Sakari Ailus]

Hi Andy,

On Fri, Jan 19, 2018 at 07:29:46AM +, Yeh, Andy wrote:
> Thanks Tomasz,
> 
> Agree with your point, if so, we could just change as below with a simple 
> check of streaming flag.
> And for Sakari, do you agree with Tomasz's comment?
> 
> Kindly review and I would send v5 with the change.
> 
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index a7e58bd2..cf1c5ee 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -561,10 +561,13 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
> 
> /*
>  * Applying V4L2 control value only happens
> -* when power is up for qstreaming
> +* when streaming flag is on
>  */
> -   if (pm_runtime_get_if_in_use(>dev) <= 0)
> +   if (imx258->streaming == 0)

This doesn't address the problem yet. I think we'll need one more field in
the device specific struct to convey this to the driver. Please see the
smiapp driver, and its use of "active" field.

It's a little different implementation, you could well put the check here
rather than the function performing the writes.

This isn't a severe issue though, in practice it'll be unlikely to be
noticed as it hasn't been noticed in some other drivers that use the same
pattern. IMO this could be addressed later on, possibly together with other
drivers with similar issues.

> return 0;
> 
> switch (ctrl->id) {
> case V4L2_CID_ANALOGUE_GAIN:
> @@ -590,8 +593,6 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
> break;
> }
> 
> -   pm_runtime_put(>dev);
> -
> return ret;
>  }

-- 
Kind regards,

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

ITS ALL ABOUT FACEBOOK

[Facebook Int'l]

Hello ,

It’s hard to believe it right??? Facebook celebrates its 14th year anniversary. 
That means 14-years ago, I, Mark Zuckerberg and my pals were in our Harvard 
dorm rooms making history, 
launching what would become the largest social network of all time, now rolling 
in billions of dollars via 
commercials, with company worth of over a hundred billion dollars
To help commemorate this occasion, we are giving back to 14,000 users 
$14,000.00USD (Fourteen Thousand Dollars) 
and a grand prize of 14,000,000.USD (Fourteen Million Dollars) to 14 lucky 
users and has launched a new feature called 
‘Look Back’, where each user's "Look Back" compilation contains 15 or so of 
your most-liked photos, statuses, and 
life events set to a catchy tune. Find yours at https://facebook.com/lookback/ 
. It's all about 14.
Please, get back for the verification of your details for prompt payment by 
sending Your Unique Code (FB/BF14-13M5250UD) 
using your registration email, to the Verification Department at; 
dustinmoskovitz.faceb...@gmail.com

Dustin Moskovitz
Facebook Team
Copyright © 2018 Facebook Int'l

Facebook Celebrates its 14th Year Anniversary

[PATCH v2 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 
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 ..acbbd625a75f
--- /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 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.14.3

[PATCH v2 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 former
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.

Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/cadence/Kconfig   |   6 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c | 586 +++
 3 files changed, 593 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 d1b6bbb6a0eb..db49328ee8b2 100644
--- a/drivers/media/platform/cadence/Kconfig
+++ b/drivers/media/platform/cadence/Kconfig
@@ -9,4 +9,10 @@ config VIDEO_CADENCE_CSI2RX
depends on VIDEO_V4L2_SUBDEV_API
select V4L2_FWNODE
 
+config VIDEO_CADENCE_CSI2TX
+   tristate "Cadence MIPI-CSI2 TX Controller"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+
 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 ..850701020836
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2tx.c
@@ -0,0 +1,586 @@
+/*
+ * Driver for Cadence MIPI-CSI2 TX Controller
+ *
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2TX_DEVICE_CONFIG_REG   0x00
+
+#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_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;
+   atomic_tcount;
+
+   void __iomem*base;
+
+   struct clk  *esc_clk;
+   struct clk  *p_clk;
+   struct clk  *pixel_clk[CSI2TX_STREAMS_MAX];
+
+   struct v4l2_subdev  subdev;
+   struct v4l2_async_notifier  notifier;
+   struct media_padpads[CSI2TX_PAD_MAX];
+   struct v4l2_mbus_framefmt   pad_fmts[CSI2TX_PAD_MAX];
+
+   boolhas_internal_dphy;
+   unsigned intlanes;
+   unsigned intmax_lanes;
+   unsigned intmax_streams;
+
+   /* Remote source */
+  

[PATCH v2 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 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 |   6 +
 drivers/media/platform/cadence/Makefile|   1 +
 drivers/media/platform/cadence/cdns-csi2tx.c   | 586 +
 4 files changed, 691 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2tx.txt
 create mode 100644 drivers/media/platform/cadence/cdns-csi2tx.c

-- 
2.14.3

[PATCH v5 2/2] v4l: cadence: Add Cadence MIPI-CSI2 RX driver

[Maxime Ripard]

The Cadence CSI-2 RX Controller is an hardware block meant to be used as a
bridge between a CSI-2 bus and pixel grabbers.

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

It also support dynamic mapping of the CSI-2 virtual channels to the
associated pixel grabbers, but that isn't allowed at the moment either.

Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/cadence/Kconfig   |  12 +
 drivers/media/platform/cadence/Makefile  |   1 +
 drivers/media/platform/cadence/cdns-csi2rx.c | 463 +++
 5 files changed, 479 insertions(+)
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index fd0c99859d6f..6e790a317fbc 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -26,6 +26,7 @@ config VIDEO_VIA_CAMERA
 #
 # Platform multimedia device configuration
 #
+source "drivers/media/platform/cadence/Kconfig"
 
 source "drivers/media/platform/davinci/Kconfig"
 
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 003b0bb2cddf..1cd2984c55d1 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -3,6 +3,8 @@
 # Makefile for the video capture/playback device drivers.
 #
 
+obj-$(CONFIG_VIDEO_CADENCE)+= cadence/
+
 obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
 
 obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
diff --git a/drivers/media/platform/cadence/Kconfig 
b/drivers/media/platform/cadence/Kconfig
new file mode 100644
index ..d1b6bbb6a0eb
--- /dev/null
+++ b/drivers/media/platform/cadence/Kconfig
@@ -0,0 +1,12 @@
+config VIDEO_CADENCE
+   bool "Cadence Video Devices"
+
+if VIDEO_CADENCE
+
+config VIDEO_CADENCE_CSI2RX
+   tristate "Cadence MIPI-CSI2 RX Controller v1.3"
+   depends on MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+
+endif
diff --git a/drivers/media/platform/cadence/Makefile 
b/drivers/media/platform/cadence/Makefile
new file mode 100644
index ..99a4086b7448
--- /dev/null
+++ b/drivers/media/platform/cadence/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
new file mode 100644
index ..ce042b9d403c
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -0,0 +1,463 @@
+/*
+ * Driver for Cadence MIPI-CSI2 RX Controller v1.3
+ *
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define CSI2RX_DEVICE_CFG_REG  0x000
+
+#define CSI2RX_SOFT_RESET_REG  0x004
+#define CSI2RX_SOFT_RESET_PROTOCOL BIT(1)
+#define CSI2RX_SOFT_RESET_FRONTBIT(0)
+
+#define CSI2RX_STATIC_CFG_REG  0x008
+#define CSI2RX_STATIC_CFG_DLANE_MAP(llane, plane)  ((plane) << (16 + 
(llane) * 4))
+#define CSI2RX_STATIC_CFG_LANES_MASK   GENMASK(11, 8)
+
+#define CSI2RX_STREAM_BASE(n)  (((n) + 1) * 0x100)
+
+#define CSI2RX_STREAM_CTRL_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x000)
+#define CSI2RX_STREAM_CTRL_START   BIT(0)
+
+#define CSI2RX_STREAM_DATA_CFG_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x008)
+#define CSI2RX_STREAM_DATA_CFG_EN_VC_SELECTBIT(31)
+#define CSI2RX_STREAM_DATA_CFG_VC_SELECT(n)BIT((n) + 16)
+
+#define CSI2RX_STREAM_CFG_REG(n)   (CSI2RX_STREAM_BASE(n) + 0x00c)
+#define CSI2RX_STREAM_CFG_FIFO_MODE_LARGE_BUF  (1 << 8)
+
+#define CSI2RX_LANES_MAX   4
+#define CSI2RX_STREAMS_MAX 4
+
+enum csi2rx_pads {
+   CSI2RX_PAD_SINK,
+   CSI2RX_PAD_SOURCE_STREAM0,
+   CSI2RX_PAD_SOURCE_STREAM1,
+   CSI2RX_PAD_SOURCE_STREAM2,
+   CSI2RX_PAD_SOURCE_STREAM3,
+   CSI2RX_PAD_MAX,
+};
+
+struct csi2rx_priv {
+   struct device   *dev;
+   atomic_tcount;
+
+   void __iomem*base;
+   struct clk  *sys_clk;
+   struct clk  *p_clk;
+   struct clk  

[PATCH v5 0/2] media: v4l: Add support for the Cadence MIPI-CSI2 RX

[Maxime Ripard]

Hi,

Here is the fifth attempt at supporting the MIPI-CSI2 RX block from
Cadence.

This IP block is able to receive CSI data over up to 4 lanes, and
split it to over 4 streams. Those streams are basically the interfaces
to the video grabbers that will perform the capture.

It is able to map streams to both CSI datatypes and virtual channels,
dynamically. This is unclear at this point what the right way to
support it would be, so the driver only uses a static mapping between
the virtual channels and streams, and ignores the data types.

Let me know what you think!
Maxime

Changes from v4:
  - Rebased on top of 4.15
  - Fixed a lane mapping issue that prevented the CSI2-RX device to operate
properly.
  - Reworded the output endpoints documentation in the binding

Changes from v3:
  - Removed stale printk
  - Propagate start/stop functions error code to s_stream
  - Renamed the DT bindings files
  - Clarified the output ports wording in the DT binding doc
  - Added a define for the maximum number of lanes
  - Rebased on top of Sakari's serie
  - Gathered tags based on the reviews

Changes from v2:
  - Added reference counting for the controller initialisation
  - Fixed checkpatch warnings
  - Moved the sensor initialisation after the DPHY configuration
  - Renamed the sensor fields to source for consistency
  - Defined some variables
  - Renamed a few structures variables
  - Added internal and external phy errors messages
  - Reworked the binding slighty by making the external D-PHY optional
  - Moved the notifier registration in the probe function
  - Removed some clocks that are not system clocks
  - Added clocks enabling where needed
  - Added the code to remap the data lanes
  - Changed the memory allocator for the non-devm function, and a
comment explaining why
  - Reworked the binding wording

Changes from v1:
  - Amended the DT bindings as suggested by Rob
  - Rebase on top of 4.13-rc1 and latest Niklas' serie iteration

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

 .../devicetree/bindings/media/cdns,csi2rx.txt  | 100 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cadence/Kconfig |  12 +
 drivers/media/platform/cadence/Makefile|   1 +
 drivers/media/platform/cadence/cdns-csi2rx.c   | 463 +
 6 files changed, 579 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt
 create mode 100644 drivers/media/platform/cadence/Kconfig
 create mode 100644 drivers/media/platform/cadence/Makefile
 create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c

-- 
2.14.3

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

[Maxime Ripard]

The Cadence MIPI-CSI2 RX controller is a CSI2RX bridge that supports up to
4 CSI-2 lanes, and can route the frames to up to 4 streams, 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: Benoit Parrot 
Acked-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/media/cdns,csi2rx.txt  | 100 +
 1 file changed, 100 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cdns,csi2rx.txt

diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt 
b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
new file mode 100644
index ..56d51902b2eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
@@ -0,0 +1,100 @@
+Cadence MIPI-CSI2 RX controller
+===
+
+The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
+lanes in input, and 4 different pixel streams in output.
+
+Required properties:
+  - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
+  - reg: base address and size of the memory mapped region
+  - clocks: phandles to the clocks driving the controller
+  - clock-names: must contain:
+* sys_clk: main 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 external D-PHY, phy-names must be provided
+  - phy-names: must contain dphy, if the implementation uses an
+   external D-PHY
+
+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 numbered as follows.
+
+   Port Description
+   -
+   0CSI-2 input
+   1Stream 0 output
+   2Stream 1 output
+   3Stream 2 output
+   4Stream 3 output
+
+   The stream output 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:
+
+csi2rx: csi-bridge@0d06 {
+   compatible = "cdns,csi2rx";
+   reg = <0x0d06 0x1000>;
+   clocks = <>, <>
+<>, <>,
+<>, <>;
+   clock-names = "sys_clk", "p_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   csi2rx_in_sensor: endpoint {
+   remote-endpoint = <_out_csi2rx>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   csi2rx_out_grabber0: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi2rx_out_grabber1: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   csi2rx_out_grabber2: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   csi2rx_out_grabber3: endpoint {
+   remote-endpoint = <_in_csi2rx>;
+   };
+   };
+   };
+};
-- 
2.14.3