Re: i.MX6 IPU CSI analog video input on Ventana

[Philipp Zabel]

On Wed, May 30, 2018 at 01:56:34PM -0700, Steve Longerbeam wrote:
> 
> 
> On 05/30/2018 11:46 AM, Krzysztof Hałasa wrote:
> > Steve Longerbeam  writes:
> > 
> > > > but it should be possible for the user to explicitly request the field
> > > > order on CSI output (I can make a patch I guess).
> > > If you think that is the correct behavior, I will remove the override
> > > code. I suppose it makes sense to allow user to select field order even
> > > if that order does not make sense given the input standard. I'm fine
> > > either way, Philipp what is your opinion? I'll go with the popular vote :)
> > I think it should be up to the user.
> > Actually, PAL and NTSC aren't valid names in the digital world. Their
> > meaning ends in the ADV7180 (or equivalent). I don't know if PAL and/or
> > NTSC specify the field order in the analog frame (meaningful when
> > someone hooks a camera with progressive sensor and analog, interlaced
> > output), but the digital YUV422 from ADV to CSI isn't NTSC/PAL anymore.
> > It's just WxH @ framerate + possible interlacing, sequential fields,
> > top-bottom or otherwise, etc. The analog standard names could be used
> > here but just as defaults.
> > 
> > If we were strict (and we don't want to force it), then we should set
> > NTSC/PAL thing on ADV7180 input, 720x480@29.97i (or 720x576@50i, or
> > 704x... etc) on the input parts of the CSI/IPU (where there are no video
> > frames yet), and 720x480@29.97i B-T or T-B (or default, or separate
> > fields - whatever suits the user) on the output from CSI.
> > 
> > I remember the reversed field order was sometimes needed - for example,
> > PAL DV (the casette camcorder thing) produced B-T frames (same as NTSC),
> > and to avoid (slight) additional quality loss one had to process it
> > (up to e.g. .MP4, DVD, and then to HDMI, SCART etc) as B-T.
> > It wasn't a problem in otherwise-PAL-centric environment.
> 
> I tend to agree, I've found conflicting info out there regarding
> PAL vs. NTSC field order. And I've never liked having to guess
> at input analog standard based on input # lines. I will go ahead
> and remove the field order override code.

Note that the code in ipu_csi_init_interface currently hard-codes field
order depending on frame size. It could be that selecting opposite field
order is as easy as switching the relevant parts of writes to registers
CCIR_CODE_2 and _3, but we'd have to pass the desired output field order
to this function. I'd welcome if somebody would verify that this works.

regards
Philipp

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:   Thu May 31 05:00:16 CEST 2018
media-tree git hash:a00031c159748f322f771f3c1d5ed944cba4bd30
media_build git hash:   b2f4db1adbe0cb2e42e875c16c009f1fa95d3325
v4l-utils git hash: 2a12796b5c22cd1a549eb8fa25db873ced811ca5
gcc version:i686-linux-gcc (GCC) 8.1.0
sparse version: 0.5.2
smatch version: 0.5.1
host hardware:  x86_64
host os:4.16.0-1-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: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.101-i686: ERRORS
linux-3.0.101-x86_64: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.101-i686: ERRORS
linux-3.2.101-x86_64: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.113-i686: ERRORS
linux-3.4.113-x86_64: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.10-i686: ERRORS
linux-3.7.10-x86_64: ERRORS
linux-3.8.13-i686: ERRORS
linux-3.8.13-x86_64: ERRORS
linux-3.9.11-i686: ERRORS
linux-3.9.11-x86_64: ERRORS
linux-3.10.108-i686: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.56-i686: ERRORS
linux-3.16.56-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.102-i686: ERRORS
linux-3.18.102-x86_64: ERRORS
linux-3.19.8-i686: ERRORS
linux-3.19.8-x86_64: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.51-i686: ERRORS
linux-4.1.51-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.109-i686: ERRORS
linux-4.4.109-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.91-i686: ERRORS
linux-4.9.91-x86_64: ERRORS
linux-4.10.17-i686: OK
linux-4.10.17-x86_64: OK
linux-4.11.12-i686: OK
linux-4.11.12-x86_64: OK
linux-4.12.14-i686: OK
linux-4.12.14-x86_64: OK
linux-4.13.16-i686: OK
linux-4.13.16-x86_64: OK
linux-4.14.42-i686: OK
linux-4.14.42-x86_64: OK
linux-4.15.14-i686: OK
linux-4.15.14-x86_64: OK
linux-4.16.8-i686: OK
linux-4.16.8-x86_64: OK
linux-4.17-rc4-i686: OK
linux-4.17-rc4-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH v2.2 2/2] smiapp: Support the "rotation" property

[Rob Herring]

On Fri, May 25, 2018 at 04:52:35PM +0300, Sakari Ailus wrote:
> Use the "rotation" property to tell that the sensor is mounted upside
> down. This reverses the behaviour of the VFLIP and HFLIP controls as well
> as the pixel order.
> 
> Signed-off-by: Sakari Ailus 
> ---
> since v2.2:
> 
> - Fix property name in code.
> 
>  .../devicetree/bindings/media/i2c/nokia,smia.txt |  2 ++

Acked-by: Rob Herring 

>  drivers/media/i2c/smiapp/smiapp-core.c   | 16 
> 
>  2 files changed, 18 insertions(+)

Re: [PATCH v2 1/2] dt-bindings: media: Define "rotation" property for sensors

[Rob Herring]

On Fri, May 25, 2018 at 03:27:25PM +0300, Sakari Ailus wrote:
> Sensors are occasionally mounted upside down to systems such as mobile
> phones or tablets. In order to use such a sensor without having to turn
> every image upside down, most camera sensors support reversing the readout
> order by setting both horizontal and vertical flipping.
> 
> This patch documents the "rotation" property for camera sensors, mirroring
> what is defined for displays in
> Documentation/devicetree/bindings/display/panel/panel.txt .
> 
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/devicetree/bindings/media/video-interfaces.txt | 4 
>  1 file changed, 4 insertions(+)

Reviewed-by: Rob Herring 

Re: [RESEND PATCH V2 1/2] dt-bindings: Add bindings for AKM ak7375 voice coil lens

[Rob Herring]

On Fri, May 25, 2018 at 05:55:34PM +0800, bingbu@intel.com wrote:
> From: Bingbu Cao 
> 
> Add device tree bindings for AKM ak7375 voice coil lens
> driver. This chip is used to drive a lens in a camera module.
> 
> Signed-off-by: Tianshu Qiu 
> Signed-off-by: Bingbu Cao 
> ---
> Changes since v1:
>  - remove the vendor prefix change
> ---
>  Documentation/devicetree/bindings/media/i2c/ak7375.txt | 8 
>  1 file changed, 8 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ak7375.txt

Reviewed-by: Rob Herring 

[PATCH v3] [media] MAINTAINERS: Update entry for Intel IPU3 cio2 driver

[Yong Zhi]

This patch adds Bingbu as additional maintainer, and both Tian Shu and Jian Xu
as reviewers for IPU3 CIO2 driver.

Signed-off-by: Yong Zhi 
---
Third time's a charm :)

 MAINTAINERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a38e24a..3dd530e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7157,6 +7157,9 @@ F:drivers/dma/iop-adma.c
 INTEL IPU3 CSI-2 CIO2 DRIVER
 M: Yong Zhi 
 M: Sakari Ailus 
+M: Bingbu Cao 
+R: Tian Shu Qiu 
+R: Jian Xu Zheng 
 L: linux-media@vger.kernel.org
 S: Maintained
 F: drivers/media/pci/intel/ipu3/
-- 
2.7.4

RE: [PATCH v2] [media] MAINTAINERS: Update entry for Intel IPU3 cio2 driver

[Mani, Rajmohan]

Hi Yong,

> -Original Message-
> From: Zhi, Yong
> Sent: Wednesday, May 30, 2018 3:10 PM
> To: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com
> Cc: Mani, Rajmohan ; Zheng, Jian Xu
> ; Qiu, Tian Shu ; Cao,
> Bingbu ; Zhi, Yong 
> Subject: [PATCH v2] [media] MAINTAINERS: Update entry for Intel IPU3 cio2
> driver
> 
> This patch adds three more maintainers to the IPU3 CIO2 driver.

nit:  The above line should be changed to reflect this v2 patch.

> 
> Signed-off-by: Yong Zhi 
> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a38e24a..3dd530e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7157,6 +7157,9 @@ F:  drivers/dma/iop-adma.c
>  INTEL IPU3 CSI-2 CIO2 DRIVER
>  M:   Yong Zhi 
>  M:   Sakari Ailus 
> +M:   Bingbu Cao 
> +R:   Tian Shu Qiu 
> +R:   Jian Xu Zheng 
>  L:   linux-media@vger.kernel.org
>  S:   Maintained
>  F:   drivers/media/pci/intel/ipu3/
> --
> 2.7.4

[PATCH v2] [media] MAINTAINERS: Update entry for Intel IPU3 cio2 driver

[Yong Zhi]

This patch adds three more maintainers to the IPU3 CIO2 driver.

Signed-off-by: Yong Zhi 
---
 MAINTAINERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a38e24a..3dd530e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7157,6 +7157,9 @@ F:drivers/dma/iop-adma.c
 INTEL IPU3 CSI-2 CIO2 DRIVER
 M: Yong Zhi 
 M: Sakari Ailus 
+M: Bingbu Cao 
+R: Tian Shu Qiu 
+R: Jian Xu Zheng 
 L: linux-media@vger.kernel.org
 S: Maintained
 F: drivers/media/pci/intel/ipu3/
-- 
2.7.4

mmap permissions failure on Raspberry Pi

[Greg Wilson-Lindberg]

I'm trying to use c++ to open a raspberry pi camera using v4l2. I found several 
examples that follow a standard set of operations:

open up the device (in my case /dev/video0)
using ioctl calls query capabilities and formats
set video format
request a buffer
query the buffer
and finally mmap the buffer

Everything works properly, I can open the device, query all of the capabilities 
and formats, set the format needed, request the buffer and query the buffer.
When I try to mmap the buffer I get permission denied. Here is the call I'm 
using:

buffer = (qint8 *)mmap(NULL, buf.length, PROT_READ | PROT_WRITE, MAP_SHARED, 
camera->handle(), buf.m.offset);

This is the same as the examples that I have seen. Also, I have tried it on 
both the Raspberry Pi camera and on a webcam. 
I've checked the group and permissions for the /dev/video0 and /dev/shm and I 
don't see anything wrong. I even tried running my program as root with the same 
result.

I'm obviously missing something, but I don't see what it could be. Any help 
would be greatly appreciated.

Regards,
Greg Wilson-Lindberg

Re: i.MX6 IPU CSI analog video input on Ventana

[Steve Longerbeam]

On 05/30/2018 11:46 AM, Krzysztof Hałasa wrote:

Steve Longerbeam  writes:


but it should be possible for the user to explicitly request the field
order on CSI output (I can make a patch I guess).

If you think that is the correct behavior, I will remove the override
code. I suppose it makes sense to allow user to select field order even
if that order does not make sense given the input standard. I'm fine
either way, Philipp what is your opinion? I'll go with the popular vote :)

I think it should be up to the user.
Actually, PAL and NTSC aren't valid names in the digital world. Their
meaning ends in the ADV7180 (or equivalent). I don't know if PAL and/or
NTSC specify the field order in the analog frame (meaningful when
someone hooks a camera with progressive sensor and analog, interlaced
output), but the digital YUV422 from ADV to CSI isn't NTSC/PAL anymore.
It's just WxH @ framerate + possible interlacing, sequential fields,
top-bottom or otherwise, etc. The analog standard names could be used
here but just as defaults.

If we were strict (and we don't want to force it), then we should set
NTSC/PAL thing on ADV7180 input, 720x480@29.97i (or 720x576@50i, or
704x... etc) on the input parts of the CSI/IPU (where there are no video
frames yet), and 720x480@29.97i B-T or T-B (or default, or separate
fields - whatever suits the user) on the output from CSI.

I remember the reversed field order was sometimes needed - for example,
PAL DV (the casette camcorder thing) produced B-T frames (same as NTSC),
and to avoid (slight) additional quality loss one had to process it
(up to e.g. .MP4, DVD, and then to HDMI, SCART etc) as B-T.
It wasn't a problem in otherwise-PAL-centric environment.


I tend to agree, I've found conflicting info out there regarding
PAL vs. NTSC field order. And I've never liked having to guess
at input analog standard based on input # lines. I will go ahead
and remove the field order override code.

Steve

Re: i.MX6 IPU CSI analog video input on Ventana

[Krzysztof Hałasa]

Steve Longerbeam  writes:

>> but it should be possible for the user to explicitly request the field
>> order on CSI output (I can make a patch I guess).
>
> If you think that is the correct behavior, I will remove the override
> code. I suppose it makes sense to allow user to select field order even
> if that order does not make sense given the input standard. I'm fine
> either way, Philipp what is your opinion? I'll go with the popular vote :)

I think it should be up to the user.
Actually, PAL and NTSC aren't valid names in the digital world. Their
meaning ends in the ADV7180 (or equivalent). I don't know if PAL and/or
NTSC specify the field order in the analog frame (meaningful when
someone hooks a camera with progressive sensor and analog, interlaced
output), but the digital YUV422 from ADV to CSI isn't NTSC/PAL anymore.
It's just WxH @ framerate + possible interlacing, sequential fields,
top-bottom or otherwise, etc. The analog standard names could be used
here but just as defaults.

If we were strict (and we don't want to force it), then we should set
NTSC/PAL thing on ADV7180 input, 720x480@29.97i (or 720x576@50i, or
704x... etc) on the input parts of the CSI/IPU (where there are no video
frames yet), and 720x480@29.97i B-T or T-B (or default, or separate
fields - whatever suits the user) on the output from CSI.

I remember the reversed field order was sometimes needed - for example,
PAL DV (the casette camcorder thing) produced B-T frames (same as NTSC),
and to avoid (slight) additional quality loss one had to process it
(up to e.g. .MP4, DVD, and then to HDMI, SCART etc) as B-T.
It wasn't a problem in otherwise-PAL-centric environment.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: i.MX6 IPU CSI analog video input on Ventana

[Steve Longerbeam]

Hi Krzysztof,


On 05/30/2018 01:53 AM, Krzysztof Hałasa wrote:

Steve Longerbeam  writes:


Yes, you'll need to patch adv7180.c to select either
'seq-bt/tb' or 'alternate'. The current version will override
any attempt to set field to anything other than 'interlaced'.
This is in anticipation of getting a patch merged for adv7180
that fixes this.

Right. I've applied the patch from your adv718x-v6 branch (just the
"media: adv7180: fix field type" patch) and now it works.

Also, I have changed "seq-bt" to "alternate" (in the examples in
Documentation/media/v4l-drivers/imx.rst) - the data stream from ADV7180
to CSI consists of separate fields which can then be merged into frames
in any order requested by the user (e.g. in accordance with "digital PAL
/ NTSC" requirements).

The following:
media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:alternate]"
media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480]"
media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x480 field:interlaced]"
now produces:

"adv7180 2-0020":0 [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1_mux":1  [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1_mux":2  [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1":0  [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1":2  [fmt:AYUV32/720x480 field:interlaced-bt]

and it works correctly.

The only issue is that I can't:
media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x480 field:interlaced-tb]"
(it remains fixed in -bt mode since NTSC is the default). I think we may
set TB/BT by default (depending on CSI input geometry or TV standard),


Yes, that's what I've implemented. If the user requests an interlaced
field type ('interlaced', 'interlaced-bt', 'interlaced-tb'), but the field
order is not correct given the input height (480=NTSC, 576=PAL),
then the request field type is overridden with the correct field order.


but it should be possible for the user to explicitly request the field
order on CSI output (I can make a patch I guess).


If you think that is the correct behavior, I will remove the override
code. I suppose it makes sense to allow user to select field order even
if that order does not make sense given the input standard. I'm fine
either way, Philipp what is your opinion? I'll go with the popular vote :)

Steve

Re: [PATCH 4/6] media: imx-csi: Enable interlaced scan for field type alternate

[Philipp Zabel]

On Mon, May 28, 2018 at 09:38:42AM -0700, Steve Longerbeam wrote:
> On 05/28/2018 12:59 AM, Ian Arkver wrote:
> > If your intent here is to de-interweave the two fields back to two
> > sequential fields, I don't believe the IDMAC operation would achieve
> > that. It's basically line stride doubling and a line offset for the
> > lines in the 2nd half of the incoming frame, right?
> 
> I agree, I'm not sure interlaced_scan will perform the inverse (turn an
> interlaced
> buffer into a sequential buffer). If the implementation involves a scan of
> two lines, second line with a memory offset equal to field size, and
> doubling
> the line stride to reach the next set of two lines, then running that
> operation
> on an interlaced buffer would not produce a sequential buffer.

You are both right, of course. What I was thinking of only works
with enabling interlaced_scan on an IDMAC read channel. On an IDMAC
write channel there is no way to turn an interlaced frame back into
consecutive fields.

regards
Philipp

[PATCH 3/3] media: videodev2: get rid of VIDIOC_RESERVED

[Mauro Carvalho Chehab]

While this ioctl is there at least since Kernel 2.6.12-rc2, it
was never used by any upstream driver.

Get rid of it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/videodev2.h.rst.exceptions | 1 -
 include/uapi/linux/videodev2.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index a5cb0a8686ac..ca9f0edc579e 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -517,7 +517,6 @@ ignore define V4L2_CTRL_WHICH_DEF_VAL
 ignore define V4L2_OUT_CAP_CUSTOM_TIMINGS
 ignore define V4L2_CID_MAX_CTRLS
 
-ignore ioctl VIDIOC_RESERVED
 ignore define BASE_VIDIOC_PRIVATE
 
 # Associate ioctls with their counterparts
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 600877be5c22..d0c5fb38677c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2310,7 +2310,6 @@ struct v4l2_create_buffers {
  *
  */
 #define VIDIOC_QUERYCAP _IOR('V',  0, struct v4l2_capability)
-#define VIDIOC_RESERVED  _IO('V',  1)
 #define VIDIOC_ENUM_FMT _IOWR('V',  2, struct v4l2_fmtdesc)
 #define VIDIOC_G_FMT   _IOWR('V',  4, struct v4l2_format)
 #define VIDIOC_S_FMT   _IOWR('V',  5, struct v4l2_format)
-- 
2.17.0

[PATCH 2/3] media: dvb/audio.h: get rid of unused APIs

[Mauro Carvalho Chehab]

There are a number of other ioctls that aren't used anywhere
inside the Kernel tree.

Get rid of them.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/dvb/audio-get-pts.rst  | 65 --
 .../media/uapi/dvb/audio-set-attributes.rst   | 67 ---
 .../media/uapi/dvb/audio-set-ext-id.rst   | 66 --
 .../media/uapi/dvb/audio-set-karaoke.rst  | 66 --
 .../media/uapi/dvb/audio_data_types.rst   | 20 --
 .../media/uapi/dvb/audio_function_calls.rst   |  4 --
 fs/compat_ioctl.c |  3 -
 include/uapi/linux/dvb/audio.h| 37 --
 8 files changed, 328 deletions(-)
 delete mode 100644 Documentation/media/uapi/dvb/audio-get-pts.rst
 delete mode 100644 Documentation/media/uapi/dvb/audio-set-attributes.rst
 delete mode 100644 Documentation/media/uapi/dvb/audio-set-ext-id.rst
 delete mode 100644 Documentation/media/uapi/dvb/audio-set-karaoke.rst

diff --git a/Documentation/media/uapi/dvb/audio-get-pts.rst 
b/Documentation/media/uapi/dvb/audio-get-pts.rst
deleted file mode 100644
index 2d1396b003de..
--- a/Documentation/media/uapi/dvb/audio-get-pts.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _AUDIO_GET_PTS:
-
-=
-AUDIO_GET_PTS
-=
-
-Name
-
-
-AUDIO_GET_PTS
-
-.. attention:: This ioctl is deprecated
-
-Synopsis
-
-
-.. c:function:: int ioctl(int fd, AUDIO_GET_PTS, __u64 *pts)
-:name: AUDIO_GET_PTS
-
-
-Arguments
--
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--
-
-   -  int fd
-
-   -  File descriptor returned by a previous call to open().
-
--
-
-   -  __u64 \*pts
-
-   -  Returns the 33-bit timestamp as defined in ITU T-REC-H.222.0 /
- ISO/IEC 13818-1.
-
- The PTS should belong to the currently played frame if possible,
- but may also be a value close to it like the PTS of the last
- decoded frame or the last PTS extracted by the PES parser.
-
-
-Description

-
-This ioctl is obsolete. Do not use in new drivers. If you need this
-functionality, then please contact the linux-media mailing list
-(`https://linuxtv.org/lists.php `__).
-
-This ioctl call asks the Audio Device to return the current PTS
-timestamp.
-
-
-Return Value
-
-
-On success 0 is returned, on error -1 and the ``errno`` variable is set
-appropriately. The generic error codes are described at the
-:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/dvb/audio-set-attributes.rst 
b/Documentation/media/uapi/dvb/audio-set-attributes.rst
deleted file mode 100644
index f0c6153ca80f..
--- a/Documentation/media/uapi/dvb/audio-set-attributes.rst
+++ /dev/null
@@ -1,67 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _AUDIO_SET_ATTRIBUTES:
-
-
-AUDIO_SET_ATTRIBUTES
-
-
-Name
-
-
-AUDIO_SET_ATTRIBUTES
-
-.. attention:: This ioctl is deprecated
-
-
-Synopsis
-
-
-.. c:function:: int ioctl(fd, AUDIO_SET_ATTRIBUTES, struct audio_attributes 
*attr )
-:name: AUDIO_SET_ATTRIBUTES
-
-Arguments
--
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--
-
-   -  int fd
-
-   -  File descriptor returned by a previous call to open().
-
--
-
-   -  audio_attributes_t attr
-
-   -  audio attributes according to section ??
-
-
-Description

-
-This ioctl is intended for DVD playback and allows you to set certain
-information about the audio stream.
-
-
-Return Value
-
-
-On success 0 is returned, on error -1 and the ``errno`` variable is set
-appropriately. The generic error codes are described at the
-:ref:`Generic Error Codes ` chapter.
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--  .. row 1
-
-   -  ``EINVAL``
-
-   -  attr is not a valid or supported attribute setting.
diff --git a/Documentation/media/uapi/dvb/audio-set-ext-id.rst 
b/Documentation/media/uapi/dvb/audio-set-ext-id.rst
deleted file mode 100644
index 8503c47f26bd..
--- a/Documentation/media/uapi/dvb/audio-set-ext-id.rst
+++ /dev/null
@@ -1,66 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _AUDIO_SET_EXT_ID:
-
-
-AUDIO_SET_EXT_ID
-
-
-Name
-
-
-AUDIO_SET_EXT_ID
-
-.. attention:: This ioctl is deprecated
-
-Synopsis
-
-
-.. c:function:: int  ioctl(fd, AUDIO_SET_EXT_ID, int id)
-:name: AUDIO_SET_EXT_ID
-
-Arguments
--
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--
-
-   -  int fd
-
-   -  File descriptor returned by a previous call to open().
-
--
-
-   -  int id
-
-   -  audio sub_stream_id
-
-
-Description

-
-This ioctl can be used to set the extension id for MPEG streams in DVD
-playback. Only the first 3 bits are recognized.
-
-
-R

[PATCH 1/3] media: dvb/video.h: get rid of unused APIs

[Mauro Carvalho Chehab]

There are a number of other ioctls that aren't used anywhere
inside the Kernel tree.

Get rid of them.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/dvb/video-get-frame-rate.rst   |  61 --
 .../media/uapi/dvb/video-get-navi.rst |  84 -
 .../media/uapi/dvb/video-set-attributes.rst   |  93 --
 .../media/uapi/dvb/video-set-highlight.rst|  86 -
 Documentation/media/uapi/dvb/video-set-id.rst |  75 
 .../media/uapi/dvb/video-set-spu.rst  |  85 -
 .../media/uapi/dvb/video-set-system.rst   |  77 
 .../media/uapi/dvb/video_function_calls.rst   |   6 -
 Documentation/media/uapi/dvb/video_types.rst  | 113 --
 Documentation/media/video.h.rst.exceptions|   2 -
 fs/compat_ioctl.c |   6 -
 include/uapi/linux/dvb/video.h|  51 
 12 files changed, 739 deletions(-)
 delete mode 100644 Documentation/media/uapi/dvb/video-get-frame-rate.rst
 delete mode 100644 Documentation/media/uapi/dvb/video-get-navi.rst
 delete mode 100644 Documentation/media/uapi/dvb/video-set-attributes.rst
 delete mode 100644 Documentation/media/uapi/dvb/video-set-highlight.rst
 delete mode 100644 Documentation/media/uapi/dvb/video-set-id.rst
 delete mode 100644 Documentation/media/uapi/dvb/video-set-spu.rst
 delete mode 100644 Documentation/media/uapi/dvb/video-set-system.rst

diff --git a/Documentation/media/uapi/dvb/video-get-frame-rate.rst 
b/Documentation/media/uapi/dvb/video-get-frame-rate.rst
deleted file mode 100644
index 400042a854cf..
--- a/Documentation/media/uapi/dvb/video-get-frame-rate.rst
+++ /dev/null
@@ -1,61 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _VIDEO_GET_FRAME_RATE:
-
-
-VIDEO_GET_FRAME_RATE
-
-
-Name
-
-
-VIDEO_GET_FRAME_RATE
-
-.. attention:: This ioctl is deprecated.
-
-Synopsis
-
-
-.. c:function:: int ioctl(int fd, VIDEO_GET_FRAME_RATE, unsigned int *rate)
-:name: VIDEO_GET_FRAME_RATE
-
-
-Arguments
--
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--  .. row 1
-
-   -  int fd
-
-   -  File descriptor returned by a previous call to open().
-
--  .. row 2
-
-   -  int request
-
-   -  Equals VIDEO_GET_FRAME_RATE for this command.
-
--  .. row 3
-
-   -  unsigned int \*rate
-
-   -  Returns the framerate in number of frames per 1000 seconds.
-
-
-Description

-
-This ioctl call asks the Video Device to return the current framerate.
-
-
-Return Value
-
-
-On success 0 is returned, on error -1 and the ``errno`` variable is set
-appropriately. The generic error codes are described at the
-:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/dvb/video-get-navi.rst 
b/Documentation/media/uapi/dvb/video-get-navi.rst
deleted file mode 100644
index 114a9ac48b9e..
--- a/Documentation/media/uapi/dvb/video-get-navi.rst
+++ /dev/null
@@ -1,84 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _VIDEO_GET_NAVI:
-
-==
-VIDEO_GET_NAVI
-==
-
-Name
-
-
-VIDEO_GET_NAVI
-
-.. attention:: This ioctl is deprecated.
-
-Synopsis
-
-
-.. c:function:: int ioctl(fd, VIDEO_GET_NAVI , struct video_navi_pack 
*navipack)
-:name: VIDEO_GET_NAVI
-
-
-Arguments
--
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--  .. row 1
-
-   -  int fd
-
-   -  File descriptor returned by a previous call to open().
-
--  .. row 2
-
-   -  int request
-
-   -  Equals VIDEO_GET_NAVI for this command.
-
--  .. row 3
-
-   -  video_navi_pack_t \*navipack
-
-   -  PCI or DSI pack (private stream 2) according to section ??.
-
-
-Description

-
-This ioctl returns navigational information from the DVD stream. This is
-especially needed if an encoded stream has to be decoded by the
-hardware.
-
-.. c:type:: video_navi_pack
-
-.. code-block::c
-
-   typedef struct video_navi_pack {
-   int length;  /* 0 ... 1024 */
-   __u8 data[1024];
-   } video_navi_pack_t;
-
-Return Value
-
-
-On success 0 is returned, on error -1 and the ``errno`` variable is set
-appropriately. The generic error codes are described at the
-:ref:`Generic Error Codes ` chapter.
-
-
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--  .. row 1
-
-   -  ``EFAULT``
-
-   -  driver is not able to return navigational information
diff --git a/Documentation/media/uapi/dvb/video-set-attributes.rst 
b/Documentation/media/uapi/dvb/video-set-attributes.rst
deleted file mode 100644
index b2f11a6746e9..
--- a/Documentation/media/uapi/dvb/video-set-attributes.rst
+++ /dev/null
@@ -1,93 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _VIDEO_SET_ATTRIBUTES:
-
-
-VIDEO_SET_ATTRIBUTES
-
-
-Name
-
-

[PATCH v2] media: dvb: get rid of VIDEO_SET_SPU_PALETTE

[Mauro Carvalho Chehab]

No upstream drivers use it. It doesn't make any sense to have
a compat32 code for something that nobody uses upstream.

Reported-by: Alexander Viro 
Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/dvb/video-set-spu-palette.rst  | 82 ---
 .../media/uapi/dvb/video_function_calls.rst   |  1 -
 Documentation/media/uapi/dvb/video_types.rst  | 18 
 Documentation/media/video.h.rst.exceptions|  1 -
 fs/compat_ioctl.c | 30 ---
 include/uapi/linux/dvb/video.h|  7 --
 6 files changed, 139 deletions(-)
 delete mode 100644 Documentation/media/uapi/dvb/video-set-spu-palette.rst

diff --git a/Documentation/media/uapi/dvb/video-set-spu-palette.rst 
b/Documentation/media/uapi/dvb/video-set-spu-palette.rst
deleted file mode 100644
index 51a1913d21d2..
--- a/Documentation/media/uapi/dvb/video-set-spu-palette.rst
+++ /dev/null
@@ -1,82 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _VIDEO_SET_SPU_PALETTE:
-
-=
-VIDEO_SET_SPU_PALETTE
-=
-
-Name
-
-
-VIDEO_SET_SPU_PALETTE
-
-.. attention:: This ioctl is deprecated.
-
-Synopsis
-
-
-.. c:function:: int ioctl(fd, VIDEO_SET_SPU_PALETTE, struct video_spu_palette 
*palette )
-:name: VIDEO_SET_SPU_PALETTE
-
-
-Arguments
--
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--  .. row 1
-
-   -  int fd
-
-   -  File descriptor returned by a previous call to open().
-
--  .. row 2
-
-   -  int request
-
-   -  Equals VIDEO_SET_SPU_PALETTE for this command.
-
--  .. row 3
-
-   -  video_spu_palette_t \*palette
-
-   -  SPU palette according to section ??.
-
-
-Description

-
-This ioctl sets the SPU color palette.
-
-.. c:type:: video_spu_palette
-
-.. code-block::c
-
-   typedef struct video_spu_palette {  /* SPU Palette information */
-   int length;
-   __u8 __user *palette;
-   } video_spu_palette_t;
-
-Return Value
-
-
-On success 0 is returned, on error -1 and the ``errno`` variable is set
-appropriately. The generic error codes are described at the
-:ref:`Generic Error Codes ` chapter.
-
-
-
-.. flat-table::
-:header-rows:  0
-:stub-columns: 0
-
-
--  .. row 1
-
-   -  ``EINVAL``
-
-   -  input is not a valid palette or driver doesn’t handle SPU.
diff --git a/Documentation/media/uapi/dvb/video_function_calls.rst 
b/Documentation/media/uapi/dvb/video_function_calls.rst
index 68588ac7fecb..8d8383ffaeba 100644
--- a/Documentation/media/uapi/dvb/video_function_calls.rst
+++ b/Documentation/media/uapi/dvb/video_function_calls.rst
@@ -38,6 +38,5 @@ Video Function Calls
 video-set-system
 video-set-highlight
 video-set-spu
-video-set-spu-palette
 video-get-navi
 video-set-attributes
diff --git a/Documentation/media/uapi/dvb/video_types.rst 
b/Documentation/media/uapi/dvb/video_types.rst
index 640a21de6b8a..4cfa00e5c934 100644
--- a/Documentation/media/uapi/dvb/video_types.rst
+++ b/Documentation/media/uapi/dvb/video_types.rst
@@ -320,24 +320,6 @@ to the following format:
  } video_spu_t;
 
 
-.. c:type:: video_spu_palette
-
-struct video_spu_palette
-
-
-The following structure is used to set the SPU palette by calling
-VIDEO_SPU_PALETTE:
-
-
-.. code-block:: c
-
- typedef
- struct video_spu_palette {
-int length;
-uint8_t *palette;
- } video_spu_palette_t;
-
-
 .. c:type:: video_navi_pack
 
 struct video_navi_pack
diff --git a/Documentation/media/video.h.rst.exceptions 
b/Documentation/media/video.h.rst.exceptions
index a91aa884ce0e..89d7c3ef2da7 100644
--- a/Documentation/media/video.h.rst.exceptions
+++ b/Documentation/media/video.h.rst.exceptions
@@ -36,5 +36,4 @@ replace typedef video_stream_source_t 
:c:type:`video_stream_source`
 replace typedef video_play_state_t :c:type:`video_play_state`
 replace typedef video_highlight_t :c:type:`video_highlight`
 replace typedef video_spu_t :c:type:`video_spu`
-replace typedef video_spu_palette_t :c:type:`video_spu_palette`
 replace typedef video_navi_pack_t :c:type:`video_navi_pack`
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index ef80085ed564..6c36b931ca90 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -200,34 +200,6 @@ static int do_video_stillpicture(struct file *file,
return err;
 }
 
-struct compat_video_spu_palette {
-   int length;
-   compat_uptr_t palette;
-};
-
-static int do_video_set_spu_palette(struct file *file,
-   unsigned int cmd, struct compat_video_spu_palette __user *up)
-{
-   struct video_spu_palette __user *up_native;
-   compat_uptr_t palp;
-   int length, err;
-
-   err  = get_user(palp, &up->palette);
-   err |= get_user(length, &up->length);
-   if (err)
-   return -EFAULT;
-
-   up_native = compat_alloc_user_space(sizeof(struct video_spu_palette));
-   err 

[GIT PULL for 4.18] More ov772x patches

[Sakari Ailus]

Hi Mauro,

Here are the rest of the ov772x patches that were missed the last time.

I've dropped the patch avoiding I2C_FUNC_PROTOCOL_MANGLING as discussed.

Please pull.


The following changes since commit a00031c159748f322f771f3c1d5ed944cba4bd30:

  media: ddbridge: conditionally enable fast TS for stv0910-equipped bridges 
(2018-05-28 17:47:05 -0400)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git for-4.18-5.1

for you to fetch changes up to 457ed65306ca41dd664c16c27e939971827b7421:

  media: ov772x: create subdevice device node (2018-05-30 09:57:32 +0300)


Akinobu Mita (11):
  media: ov772x: add checks for register read errors
  media: ov772x: add media controller support
  media: ov772x: use generic names for reset and powerdown gpios
  media: ov772x: omit consumer ID when getting clock reference
  media: ov772x: support device tree probing
  media: ov772x: handle nested s_power() calls
  media: ov772x: reconstruct s_frame_interval()
  media: ov772x: use v4l2_ctrl to get current control value
  media: ov772x: avoid accessing registers under power saving mode
  media: ov772x: make set_fmt() and s_frame_interval() return -EBUSY while 
streaming
  media: ov772x: create subdevice device node

 arch/sh/boards/mach-migor/setup.c |   7 +-
 drivers/media/i2c/ov772x.c| 333 --
 2 files changed, 250 insertions(+), 90 deletions(-)

-- 
Kind regards,

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

Re: Hello

[Mirta Vera Robert]

Bitte können Sie mir einen Gefallen tun?

Durch Überweisung mein Erbe in deine Sorge für ein gutes Projekt in deinem Land
Obwohl diese Kommunikation erstaunt aussehen kann, bin ich sehr verzweifelt, 
dass diese Vermächtnis sofort sofort wegen meiner bösen Verwandten, die nach 
meinem Leben ist, nur wegen dieses Erbes, das ist Grund Ich brauche Ihre Hilfe, 
um diese Geldüberweisung auf ein sicheres Konto in haben Ihr Land für 
Investitionsprojekt jeglicher Art, das Sie am besten kennen, werde ich auch 
gerne meine Ausbildung fortsetzen und in Ihrem Land friedlich und sicher sein. 
Hier ist ein wenig über mich.Ich bin ein Weibchen, genannt Mariam Single nie 
verheiratet, Alter 22 Jahre, meine Hobbys sind: Lesen, Reisen, Handball spielen 
mit Tischtennis und Pflege für Menschen

Ich bin ein Christ, aber ich respektiere den Glauben und die Religion anderer 
Leute

Der Betrag, den mein verstorbener Vater hinterlegt hat, ist sieben Millionen 
und fünfhunderttausend Dollar Ich bin bereit, Ihnen 20 Prozent der Gesamtmenge 
anzubieten, die ich Ihre Unterstützung benötige, um dieses Geld zu haben, das 
zu Ihrem Land sofort für eine rentable Investition herausgeht, die Sie 
verwaltet werden, bis ich meine Ausbildung in Ihrem Land beende, wenn es 
irgendeine Frage gibt,
Fühlen Sie sich bitte frei, mich zu fragen

Grüße
Mariam
___
Please can you do me a favor?

By transferrine my inheritance into your care for a good project in your country
Although this communication may look astonished I am very desperate to have 
this legacy transfer out immediately because of my wicked relative who is after 
my life just because of this legacy, this is reason I need your assistance to 
have this money transfer to a safe account in your country for investment 
project of any kind that you knew best, I will also like to continue my 
education and be living peaceful and safe in your country. Here is a little 
about me.I am a female, named Meriam single never married, age 22 years, my 
hobbies are: Reading, travelling, playing handball with table tennis and care 
for people

I am a Christian but I respect other people’s belief and  religion

The amount deposited by my late father is Seven  million and five hundred 
thousand dollars
I am willing to offer you 20 percent of the total amount I need your assistance 
to have this money transfer out to your country immediately for a profitable 
investment you will be managing until I finish my education in your countryIf 
there is any question,
please feel free to ask me

Regards

Mariam 

Re: i.MX6 IPU CSI analog video input on Ventana

[Krzysztof Hałasa]

Steve Longerbeam  writes:

> Yes, you'll need to patch adv7180.c to select either
> 'seq-bt/tb' or 'alternate'. The current version will override
> any attempt to set field to anything other than 'interlaced'.
> This is in anticipation of getting a patch merged for adv7180
> that fixes this.

Right. I've applied the patch from your adv718x-v6 branch (just the
"media: adv7180: fix field type" patch) and now it works.

Also, I have changed "seq-bt" to "alternate" (in the examples in
Documentation/media/v4l-drivers/imx.rst) - the data stream from ADV7180
to CSI consists of separate fields which can then be merged into frames
in any order requested by the user (e.g. in accordance with "digital PAL
/ NTSC" requirements).

The following:
media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:alternate]"
media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480]"
media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x480 field:interlaced]"
now produces:

"adv7180 2-0020":0 [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1_mux":1  [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1_mux":2  [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1":0  [fmt:UYVY2X8/720x480 field:alternate]
"ipu2_csi1":2  [fmt:AYUV32/720x480 field:interlaced-bt]

and it works correctly.

The only issue is that I can't:
media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x480 field:interlaced-tb]"
(it remains fixed in -bt mode since NTSC is the default). I think we may
set TB/BT by default (depending on CSI input geometry or TV standard),
but it should be possible for the user to explicitly request the field
order on CSI output (I can make a patch I guess).
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: camera control interface

[Laurent Pinchart]

Hi Vinod,

On Wednesday, 30 May 2018 10:40:56 EEST Vinod wrote:
> On 30-05-18, 10:31, Laurent Pinchart wrote:
> > On Wednesday, 30 May 2018 10:28:58 EEST Vinod wrote:
> >> On 30-05-18, 10:04, Laurent Pinchart wrote:
>  I am writing a driver for camera control inteface which is an i2c
>  controller. So looking up the code I think it can be a v4l subdev,
>  right? Can it be an independent i2c master and not v4l subdev?
> >>> 
> >>> What do you mean by "camera control interface" here ? A hardware
> >> device handling communication with camera sensors ? I assume the
> >>> communication bus is I2C ? Is that "camera control interface" plain
> >>> I2C or does it have additional features ?
> >>> 
> >>> If we're talking about an I2C controller a V4L2 subdev is not only
> >>> unneeded, but it wouldn't help. You need an I2C master.
> >> 
> >> Sorry if I wasn't quite right in description, the control interface is
> >> indeed i2c master and gpio. The camera sensors are i2c slaves connected
> >> to this i2c master and gpio for sensors are connected to this as well.
> > 
> > No worries. This clarifies the context.
> > 
>  Second the control sports GPIOs. It can support  a set of
>  synchronization primitives so it's possible to drive I2C clients and
>  GPIOs with hardware controlled timing to allow for sync control of
>  sensors hooked and also for fancy strobe. How would we represent
>  these gpios in v4l2 and allow the control, any ideas on that.
> >>> 
> >>> Even if your main use case it related to camera, synchronization of
> >>> I2C and GPIO doesn't seem to be a V4L2 feature to me. It sounds that
> >>> you need to implement that int he I2C and GPIO subsystems.
> >> 
> >> Well if a user wants to capture multiple cameras and synchronise,
> >> wouldn't that need sync of i2c and gpio. I understand it may not be
> >> supported but the question is would it be a nice feature for v4l, if so
> >> how to go about it?
> > 
> > You need two parts to implement this in my opinion. First, you need a
> > synchronized I2C + GPIO mechanism on which to base the implementation.
> > That's not V4L2-specific and should I believe be handled in the I2C and
> > GPIO subsystems. Then, you need to expose the concept of camera
> > synchronization in V4L2. That part will likely require API extensions,
> > both inside the kernel and towards userspace.
> 
> Okay thanks. So should I do a v4l subdev for i2c master or leave it in
> i2c subsystem. Does subdev make sense for gpio too..

A V4L2 subdev doesn't make sense for any of these. Roughly speaking, a subdev 
represent an entity in a video data pipeline (with the notable exception of 
lens and flash controllers). I2C, GPIO and other resources (such as clocks) 
are not part of the video data pipeline (unless video data itself transits on 
I2C, but that's another story).

> How does one go about 'linking' the two?

That's what you have to invent :-)

> Btw where is v4l userspace located?

There's no official "V4L2 userspace". V4L2 is a kernel to userspace API. Lots 
of applications then use that API, either directly, or through a framework as 
GStreamer.

-- 
Regards,

Laurent Pinchart

Re: camera control interface

[Vinod]

Hi Laurent,

On 30-05-18, 10:31, Laurent Pinchart wrote:
> On Wednesday, 30 May 2018 10:28:58 EEST Vinod wrote:
> > On 30-05-18, 10:04, Laurent Pinchart wrote:
> > >> I am writing a driver for camera control inteface which is an i2c
> > >> controller. So looking up the code I think it can be a v4l subdev,
> > >> right? Can it be an independent i2c master and not v4l subdev?
> > > 
> > > What do you mean by "camera control interface" here ? A hardware device
> > > handling communication with camera sensors ? I assume the communication
> > > bus is I2C ? Is that "camera control interface" plain I2C or does it have
> > > additional features ?
> > > 
> > > If we're talking about an I2C controller a V4L2 subdev is not only
> > > unneeded, but it wouldn't help. You need an I2C master.
> > 
> > Sorry if I wasn't quite right in description, the control interface is
> > indeed i2c master and gpio. The camera sensors are i2c slaves connected to
> > this i2c master and gpio for sensors are connected to this as well.
> 
> No worries. This clarifies the context.
> 
> > >> Second the control sports GPIOs. It can support  a set of
> > >> synchronization primitives so it's possible to drive I2C clients and
> > >> GPIOs with hardware controlled timing to allow for sync control of
> > >> sensors hooked and also for fancy strobe. How would we represent these
> > >> gpios in v4l2 and allow the control, any ideas on that.
> > > 
> > > Even if your main use case it related to camera, synchronization of I2C
> > > and GPIO doesn't seem to be a V4L2 feature to me. It sounds that you need
> > > to implement that int he I2C and GPIO subsystems.
> > 
> > Well if a user wants to capture multiple cameras and synchronise,
> > wouldn't that need sync of i2c and gpio. I understand it may not be
> > supported but the question is would it be a nice feature for v4l, if so
> > how to go about it?
> 
> You need two parts to implement this in my opinion. First, you need a 
> synchronized I2C + GPIO mechanism on which to base the implementation. That's 
> not V4L2-specific and should I believe be handled in the I2C and GPIO 
> subsystems. Then, you need to expose the concept of camera synchronization in 
> V4L2. That part will likely require API extensions, both inside the kernel 
> and 
> towards userspace.

Okay thanks. So should I do a v4l subdev for i2c master or leave it in
i2c subsystem. Does subdev make sense for gpio too.. How does one go
about 'linking' the two?

Btw where is v4l userspace located?

-- 
~Vinod

Re: camera control interface

[Laurent Pinchart]

Hi Vinod,

On Wednesday, 30 May 2018 10:28:58 EEST Vinod wrote:
> On 30-05-18, 10:04, Laurent Pinchart wrote:
> >> I am writing a driver for camera control inteface which is an i2c
> >> controller. So looking up the code I think it can be a v4l subdev,
> >> right? Can it be an independent i2c master and not v4l subdev?
> > 
> > What do you mean by "camera control interface" here ? A hardware device
> > handling communication with camera sensors ? I assume the communication
> > bus is I2C ? Is that "camera control interface" plain I2C or does it have
> > additional features ?
> > 
> > If we're talking about an I2C controller a V4L2 subdev is not only
> > unneeded, but it wouldn't help. You need an I2C master.
> 
> Sorry if I wasn't quite right in description, the control interface is
> indeed i2c master and gpio. The camera sensors are i2c slaves connected to
> this i2c master and gpio for sensors are connected to this as well.

No worries. This clarifies the context.

> >> Second the control sports GPIOs. It can support  a set of
> >> synchronization primitives so it's possible to drive I2C clients and
> >> GPIOs with hardware controlled timing to allow for sync control of
> >> sensors hooked and also for fancy strobe. How would we represent these
> >> gpios in v4l2 and allow the control, any ideas on that.
> > 
> > Even if your main use case it related to camera, synchronization of I2C
> > and GPIO doesn't seem to be a V4L2 feature to me. It sounds that you need
> > to implement that int he I2C and GPIO subsystems.
> 
> Well if a user wants to capture multiple cameras and synchronise,
> wouldn't that need sync of i2c and gpio. I understand it may not be
> supported but the question is would it be a nice feature for v4l, if so
> how to go about it?

You need two parts to implement this in my opinion. First, you need a 
synchronized I2C + GPIO mechanism on which to base the implementation. That's 
not V4L2-specific and should I believe be handled in the I2C and GPIO 
subsystems. Then, you need to expose the concept of camera synchronization in 
V4L2. That part will likely require API extensions, both inside the kernel and 
towards userspace.

-- 
Regards,

Laurent Pinchart

Re: camera control interface

[Vinod]

Hey Laurent,

On 30-05-18, 10:04, Laurent Pinchart wrote:
> > 
> > I am writing a driver for camera control inteface which is an i2c
> > controller. So looking up the code I think it can be a v4l subdev,
> > right? Can it be an independent i2c master and not v4l subdev?
> 
> What do you mean by "camera control interface" here ? A hardware device 
> handling communication with camera sensors ? I assume the communication bus 
> is 
> I2C ? Is that "camera control interface" plain I2C or does it have additional 
> features ?
> 
> If we're talking about an I2C controller a V4L2 subdev is not only unneeded, 
> but it wouldn't help. You need an I2C master.

Sorry if I wasn't quite right in description, the control interface is
indeed i2c master and gpio. The camera sensors are i2c slaves connected to
this i2c master and gpio for sensors are connected to this as well.

> > Second the control sports GPIOs. It can support  a set of
> > synchronization primitives so it's possible to drive I2C clients and
> > GPIOs with hardware controlled timing to allow for sync control of
> > sensors hooked and also for fancy strobe. How would we represent these
> > gpios in v4l2 and allow the control, any ideas on that.
> 
> Even if your main use case it related to camera, synchronization of I2C and 
> GPIO doesn't seem to be a V4L2 feature to me. It sounds that you need to 
> implement that int he I2C and GPIO subsystems.

Well if a user wants to capture multiple cameras and synchronise,
wouldn't that need sync of i2c and gpio. I understand it may not be
supported but the question is would it be a nice feature for v4l, if so
how to go about it?

Thanks
-- 
~Vinod

Re: camera control interface

[Laurent Pinchart]

Hi Vinod,

On Tuesday, 29 May 2018 11:29:32 EEST Vinod wrote:
> Hi folks,
> 
> I am writing a driver for camera control inteface which is an i2c
> controller. So looking up the code I think it can be a v4l subdev,
> right? Can it be an independent i2c master and not v4l subdev?

What do you mean by "camera control interface" here ? A hardware device 
handling communication with camera sensors ? I assume the communication bus is 
I2C ? Is that "camera control interface" plain I2C or does it have additional 
features ?

If we're talking about an I2C controller a V4L2 subdev is not only unneeded, 
but it wouldn't help. You need an I2C master.

> Second the control sports GPIOs. It can support  a set of
> synchronization primitives so it's possible to drive I2C clients and
> GPIOs with hardware controlled timing to allow for sync control of
> sensors hooked and also for fancy strobe. How would we represent these
> gpios in v4l2 and allow the control, any ideas on that.

Even if your main use case it related to camera, synchronization of I2C and 
GPIO doesn't seem to be a V4L2 feature to me. It sounds that you need to 
implement that int he I2C and GPIO subsystems.

-- 
Regards,

Laurent Pinchart