Re: [PATCH] media: uvcvideo: Support realtek's UVC 1.5 device

[Kai Heng Feng]

On May 23, 2018, at 4:32 AM, Laurent Pinchart  
 wrote:


Hello,

Thank you for the patch.

On Wednesday, 9 May 2018 05:13:08 EEST ming_q...@realsil.com.cn wrote:

From: ming_qian 

The length of UVC 1.5 video control is 48, and it id 34 for UVC 1.1.
Change it to 48 for UVC 1.5 device,
and the UVC 1.5 device can be recognized.

More changes to the driver are needed for full UVC 1.5 compatibility.
However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have
been reported to work well.


This patch is however not specific to Realtek devices, so I think we should
make the subject line more generic. It's fine mentioning in the commit  
message
itself that the Realtek RTS5847/RTS5852 cameras have been successfully  
tested.



Signed-off-by: ming_qian 
---
 drivers/media/usb/uvc/uvc_video.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c index aa0082f..32dfb32 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -171,6 +171,8 @@ static int uvc_get_video_ctrl(struct uvc_streaming
*stream, int ret;

size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
+   if (stream->dev->uvc_version >= 0x0150)
+   size = 48;
if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) &&
query == UVC_GET_DEF)
return -EIO;
@@ -259,6 +261,8 @@ static int uvc_set_video_ctrl(struct uvc_streaming
*stream, int ret;

size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
+   if (stream->dev->uvc_version >= 0x0150)
+   size = 48;
data = kzalloc(size, GFP_KERNEL);
if (data == NULL)
return -ENOMEM;


Instead of duplicating the computation in both functions, I think we should
move the code to a helper function.

Furthermore there are equality checks further down both functions that  
compare

the size to 34, they should be updated to also support UVC 1.5.

I propose the following updated patch. If you're fine with it there's no  
need

to resubmit, I'll queue it for v4.19.

I have dropped the Reviewed-by and Tested-by tags as the patch has changed.

commit a9c002732695eab2096580a0d1a1687bc2f95928
Author: ming_qian 
Date:   Wed May 9 10:13:08 2018 +0800

media: uvcvideo: Support UVC 1.5 video probe & commit controls

The length of UVC 1.5 video control is 48, and it is 34 for UVC 1.1.
Change it to 48 for UVC 1.5 device, and the UVC 1.5 device can be
recognized.

More changes to the driver are needed for full UVC 1.5 compatibility.
However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have been
reported to work well.

Cc: sta...@vger.kernel.org
Signed-off-by: ming_qian 
[Factor out code to helper function, update size checks]
Signed-off-by: Laurent Pinchart 


I tested this new patch and it works well.

Tested-by: Kai-Heng Feng 



diff --git a/drivers/media/usb/uvc/uvc_video.c  
b/drivers/media/usb/uvc/uvc_video.c

index eb9e04a59427..285b0e813b9d 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -207,14 +207,27 @@ static void uvc_fixup_video_ctrl(struct  
uvc_streaming *stream,

}
 }

+static size_t uvc_video_ctrl_size(struct uvc_streaming *stream)
+{
+   /*
+* Return the size of the video probe and commit controls, which depends
+* on the protocol version.
+*/
+   if (stream->dev->uvc_version < 0x0110)
+   return 26;
+   else if (stream->dev->uvc_version < 0x0150)
+   return 34;
+   else
+   return 48;
+}
+
 static int uvc_get_video_ctrl(struct uvc_streaming *stream,
struct uvc_streaming_control *ctrl, int probe, u8 query)
 {
+   u16 size = uvc_video_ctrl_size(stream);
u8 *data;
-   u16 size;
int ret;

-   size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) &&
query == UVC_GET_DEF)
return -EIO;
@@ -271,7 +284,7 @@ static int uvc_get_video_ctrl(struct uvc_streaming  
*stream,

ctrl->dwMaxVideoFrameSize = get_unaligned_le32([18]);
ctrl->dwMaxPayloadTransferSize = get_unaligned_le32([22]);

-   if (size == 34) {
+   if (size >= 34) {
ctrl->dwClockFrequency = get_unaligned_le32([26]);
ctrl->bmFramingInfo = data[30];
ctrl->bPreferedVersion = data[31];
@@ -300,11 +313,10 @@ static int uvc_get_video_ctrl(struct uvc_streaming  
*stream,

 static int uvc_set_video_ctrl(struct uvc_streaming *stream,
struct uvc_streaming_control *ctrl, int probe)
 {
+   u16 size = uvc_video_ctrl_size(stream);
u8 *data;
-   u16 size;
 

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Wed May 23 05:00:14 CEST 2018
media-tree git hash:8ed8bba70b4355b1ba029b151ade84475dd12991
media_build git hash:   a82350b68483a130e5c5993dcedf7201c4e3757d
v4l-utils git hash: e2038ec6451293787b929338c2a671c732b8693d
gcc version:i686-linux-gcc (GCC) 8.1.0
sparse version: 0.5.2-RC1
smatch version: 0.5.1
host hardware:  x86_64
host os:4.16.0-1-amd64

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: OK
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: WARNINGS
linux-git-arm-stm32: OK
linux-git-arm64: WARNINGS
linux-git-i686: WARNINGS
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-sh: OK
linux-git-x86_64: WARNINGS
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-i686: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-i686: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-i686: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.101-i686: OK
linux-3.0.101-x86_64: OK
linux-3.1.10-i686: OK
linux-3.1.10-x86_64: OK
linux-3.2.101-i686: OK
linux-3.2.101-x86_64: OK
linux-3.3.8-i686: OK
linux-3.3.8-x86_64: OK
linux-3.4.113-i686: OK
linux-3.4.113-x86_64: OK
linux-3.5.7-i686: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-i686: OK
linux-3.6.11-x86_64: OK
linux-3.7.10-i686: OK
linux-3.7.10-x86_64: OK
linux-3.8.13-i686: OK
linux-3.8.13-x86_64: OK
linux-3.9.11-i686: OK
linux-3.9.11-x86_64: OK
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.56-i686: OK
linux-3.16.56-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.102-i686: OK
linux-3.18.102-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.51-i686: OK
linux-4.1.51-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.109-i686: OK
linux-4.4.109-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: WARNINGS
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: WARNINGS
linux-4.9.91-i686: OK
linux-4.9.91-x86_64: WARNINGS
linux-4.10.17-i686: OK
linux-4.10.17-x86_64: WARNINGS
linux-4.11.12-i686: OK
linux-4.11.12-x86_64: WARNINGS
linux-4.12.14-i686: OK
linux-4.12.14-x86_64: WARNINGS
linux-4.13.16-i686: WARNINGS
linux-4.13.16-x86_64: WARNINGS
linux-4.14.42-i686: WARNINGS
linux-4.14.42-x86_64: WARNINGS
linux-4.15.14-i686: WARNINGS
linux-4.15.14-x86_64: WARNINGS
linux-4.16.8-i686: WARNINGS
linux-4.16.8-x86_64: WARNINGS
linux-4.17-rc4-i686: WARNINGS
linux-4.17-rc4-x86_64: WARNINGS
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH 3/4] venus: add check to make scm calls

[Vikash Garodia]

Hi Stan,

On 2018-05-23 02:27, Stanimir Varbanov wrote:

Hi Jordan,

On 22.05.2018 22:50, Jordan Crouse wrote:

On Tue, May 22, 2018 at 04:04:51PM +0300, Stanimir Varbanov wrote:

Hi Vikash,

On 05/17/2018 02:32 PM, Vikash Garodia wrote:

In order to invoke scm calls, ensure that the platform
has the required support to invoke the scm calls in
secure world. This code is in preparation to add PIL
functionality in venus driver.

Signed-off-by: Vikash Garodia 
---
  drivers/media/platform/qcom/venus/hfi_venus.c | 26 
+++---

  1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
b/drivers/media/platform/qcom/venus/hfi_venus.c

index f61d34b..9bcce94 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus.c
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -27,6 +27,7 @@
  #include "hfi_msgs.h"
  #include "hfi_venus.h"
  #include "hfi_venus_io.h"
+#include "firmware.h"
#define HFI_MASK_QHDR_TX_TYPE   0xff00
  #define HFI_MASK_QHDR_RX_TYPE 0x00ff
@@ -570,13 +571,19 @@ static int venus_halt_axi(struct 
venus_hfi_device *hdev)

  static int venus_power_off(struct venus_hfi_device *hdev)
  {
int ret;
+   void __iomem *reg_base;
if (!hdev->power_enabled)
return 0;
  - ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
-   if (ret)
-   return ret;
+   if (qcom_scm_is_available()) {
+   ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);


I think it will be clearer if we abstract qcom_scm_set_remote_state 
to
something like venus_set_state(SUSPEND|RESUME) in firmware.c and 
export

the functions to be used here.


This specific function is a little odd because the SCM function got 
overloaded

and used as a hardware workaround for the adreno a5xx zap shader.

When we added it for the GPU we knew the day would come that we would 
need it
for Venus so we kept the name purposely generic. You can wrap if if 
you want
but just know that there are other non video entities out there using 
it.


Sorry I wasn't clear, by abstract it I meant to introduce a new
venus_set_state function in venus/firmware.c where we'll select
tz/non-tz functions for suspend / resume depending on the
configuration.


Yes, that's a good idea to abstract the decision to use tz or non-tz way 
as much

as possible to firmware.c. Will add this in my next patch.


regards,
Stan

[PATCH 3/6] media: staging: atomisp: Remove useless "ifndef ISP2401"

[Pankaj Bharadiya]

In atomisp_csi2_set_ffmt(), there is no reason to have
"#ifndef ISP2401" condition since code is identical in ifndef and
else sections. Hence remove redudent checks.

Signed-off-by: Pankaj Bharadiya 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_csi2.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_csi2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_csi2.c
index fa03b78..606ebdb 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_csi2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_csi2.c
@@ -90,11 +90,7 @@ int atomisp_csi2_set_ffmt(struct v4l2_subdev *sd,
 {
struct atomisp_mipi_csi2_device *csi2 = v4l2_get_subdevdata(sd);
struct v4l2_mbus_framefmt *actual_ffmt =
-#ifndef ISP2401
__csi2_get_format(csi2, cfg, which, pad);
-#else
-   __csi2_get_format(csi2, cfg, which, pad);
-#endif
 
if (pad == CSI2_PAD_SINK) {
const struct atomisp_in_fmt_conv *ic;
@@ -121,11 +117,7 @@ int atomisp_csi2_set_ffmt(struct v4l2_subdev *sd,
 
/* FIXME: DPCM decompression */
*actual_ffmt = *ffmt =
-#ifndef ISP2401
*__csi2_get_format(csi2, cfg, which, CSI2_PAD_SINK);
-#else
-   *__csi2_get_format(csi2, cfg, which, CSI2_PAD_SINK);
-#endif
 
return 0;
 }
-- 
2.7.4

[PATCH 1/6] media: staging: atomisp: remove redundent check

[Pankaj Bharadiya]

Assignment asd = >asd[i] can never be null hence remove
redundent check.

Signed-off-by: Pankaj Bharadiya 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
index f668c68..7a9f3c9 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
@@ -4592,8 +4592,6 @@ int atomisp_css_isr_thread(struct atomisp_device *isp,
 * delete wdt timer. */
for (i = 0; i < isp->num_of_streams; i++) {
asd = >asd[i];
-   if (!asd)
-   continue;
if (asd->streaming != ATOMISP_DEVICE_STREAMING_ENABLED)
continue;
if (!atomisp_buffers_queued(asd))
-- 
2.7.4

[PATCH 6/6] media: staging: atomisp: Fix potential NULL pointer dereference

[Pankaj Bharadiya]

In verify_copy_out_frame_format(), "pipe" is being dereferenced before
it is null checked.
Fix it by moving the "pipe" pointer dereference after it has been
properly null checked.

Signed-off-by: Pankaj Bharadiya 
---
 drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
index eb84d51..487e768 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
@@ -455,12 +455,14 @@ static enum ia_css_frame_format yuv422_copy_formats[] = {
 static enum ia_css_err
 verify_copy_out_frame_format(struct ia_css_pipe *pipe)
 {
-   enum ia_css_frame_format out_fmt = pipe->output_info[0].format;
+   enum ia_css_frame_format out_fmt;
unsigned int i, found = 0;
 
assert(pipe != NULL);
assert(pipe->stream != NULL);
 
+   out_fmt = pipe->output_info[0].format;
+
switch (pipe->stream->config.input_config.format) {
case ATOMISP_INPUT_FORMAT_YUV420_8_LEGACY:
case ATOMISP_INPUT_FORMAT_YUV420_8:
-- 
2.7.4

[PATCH 2/6] media: staging: atomisp: Remove useless if statement

[Pankaj Bharadiya]

Local variable "requeue" is assigned only once to a constant "false"
value so "if(requeue)" condition will never be true.
Thus remove it.

Signed-off-by: Pankaj Bharadiya 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index fa6ea50..c8c4d1d 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -883,7 +883,6 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, int 
error,
struct videobuf_buffer *vb = NULL;
struct atomisp_video_pipe *pipe = NULL;
struct atomisp_css_buffer buffer;
-   bool requeue = false;
int err;
unsigned long irqflags;
struct atomisp_css_frame *frame = NULL;
@@ -1223,19 +1222,6 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, 
int error,
 #ifdef ISP2401
atomic_set(>wdt_count, 0);
 #endif
-   /*
-* Requeue should only be done for 3a and dis buffers.
-* Queue/dequeue order will change if driver recycles image buffers.
-*/
-   if (requeue) {
-   err = atomisp_css_queue_buffer(asd,
-  stream_id, css_pipe_id,
-  buf_type, );
-   if (err)
-   dev_err(isp->dev, "%s, q to css fails: %d\n",
-   __func__, err);
-   return;
-   }
if (!error && q_buffers)
atomisp_qbuffers_to_css(asd);
 #ifdef ISP2401
-- 
2.7.4

[PATCH 4/6] media: staging: atomisp: Fix potential NULL pointer dereference

[Pankaj Bharadiya]

In ia_css_pipe_get_primary_binarydesc(), "pipe" is being dereferenced
before it is null checked.
Fix it by moving the "pipe" pointer dereference after it has been
properly null checked.

Signed-off-by: Pankaj Bharadiya 
---
 .../atomisp/pci/atomisp2/css2400/camera/pipe/src/pipe_binarydesc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/camera/pipe/src/pipe_binarydesc.c
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/camera/pipe/src/pipe_binarydesc.c
index 98a2a3e..ca86157 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/camera/pipe/src/pipe_binarydesc.c
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/camera/pipe/src/pipe_binarydesc.c
@@ -554,7 +554,7 @@ void ia_css_pipe_get_primary_binarydesc(
struct ia_css_frame_info *vf_info,
unsigned int stage_idx)
 {
-   enum ia_css_pipe_version pipe_version = pipe->config.isp_pipe_version;
+   enum ia_css_pipe_version pipe_version;
int mode;
unsigned int i;
struct ia_css_frame_info *out_infos[IA_CSS_BINARY_MAX_OUTPUT_PORTS];
@@ -567,6 +567,7 @@ void ia_css_pipe_get_primary_binarydesc(
/*assert(vf_info != NULL);*/
IA_CSS_ENTER_PRIVATE("");
 
+   pipe_version = pipe->config.isp_pipe_version;
if (pipe_version == IA_CSS_PIPE_VERSION_2_6_1)
mode = primary_hq_binary_modes[stage_idx];
else
-- 
2.7.4

[PATCH 5/6] media: staging: atomisp: Fix potential NULL pointer dereference

[Pankaj Bharadiya]

In sh_css_config_input_network(), "stream" is being dereferenced
before it is null checked.
Fix it by moving the "stream" pointer dereference after it has been
properly null checked.

Signed-off-by: Pankaj Bharadiya 
---
 drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
index c771e4b..eb84d51 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
@@ -529,11 +529,12 @@ static enum ia_css_err
 sh_css_config_input_network(struct ia_css_stream *stream)
 {
unsigned int fmt_type;
-   struct ia_css_pipe *pipe = stream->last_pipe;
+   struct ia_css_pipe *pipe;
struct ia_css_binary *binary = NULL;
enum ia_css_err err = IA_CSS_SUCCESS;
 
assert(stream != NULL);
+   pipe = stream->last_pipe;
assert(pipe != NULL);
 
ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE_PRIVATE,
-- 
2.7.4

[PATCH 0/6] Fix issues reported by static analysis tool.

[Pankaj Bharadiya]

This patch series fixes some of the issues reported by static analysis
tool.

Pankaj Bharadiya (6):
  media: staging: atomisp: remove redundent check
  media: staging: atomisp: Remove useless if statement
  media: staging: atomisp: Remove useless "ifndef ISP2401"
  media: staging: atomisp: Fix potential NULL pointer dereference
  media: staging: atomisp: Fix potential NULL pointer dereference
  media: staging: atomisp: Fix potential NULL pointer dereference

 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c   | 14 --
 .../media/atomisp/pci/atomisp2/atomisp_compat_css20.c  |  2 --
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_csi2.c  |  8 
 .../pci/atomisp2/css2400/camera/pipe/src/pipe_binarydesc.c |  3 ++-
 .../staging/media/atomisp/pci/atomisp2/css2400/sh_css.c|  7 +--
 5 files changed, 7 insertions(+), 27 deletions(-)

-- 
2.7.4

[PATCH v3 2/2] media: helene: support IF frequency of ISDB-S

[Katsuhiro Suzuki]

This patch enhances maximum IF frequency to 2.072GHz of this tuner
for supporting ISDB-S in Japan.

Maimum RF center frequency of ISDB-S for right-handed circularly
polarized.
  BSAT
BS-23 12.14944GHz
  N-SAT-110
ND-24 12.731GHz

Local frequency of BS/CS converter is typically 10.678GHz.

---

Changes since v2:
  - Newly added

Signed-off-by: Katsuhiro Suzuki 
---
 drivers/media/dvb-frontends/helene.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/helene.c 
b/drivers/media/dvb-frontends/helene.c
index 04033f0c278b..7d02a9ea7d95 100644
--- a/drivers/media/dvb-frontends/helene.c
+++ b/drivers/media/dvb-frontends/helene.c
@@ -874,7 +874,7 @@ static const struct dvb_tuner_ops helene_tuner_ops_s = {
.info = {
.name = "Sony HELENE Sat tuner",
.frequency_min = 50,
-   .frequency_max = 250,
+   .frequency_max = 207200,
.frequency_step = 1000,
},
.init = helene_init,
@@ -888,7 +888,7 @@ static const struct dvb_tuner_ops helene_tuner_ops = {
.info = {
.name = "Sony HELENE Sat/Ter tuner",
.frequency_min = 50,
-   .frequency_max = 12,
+   .frequency_max = 207200,
.frequency_step = 1000,
},
.init = helene_init,
-- 
2.17.0

[PATCH v3 1/2] media: helene: add I2C device probe function

[Katsuhiro Suzuki]

This patch adds I2C probe function to use dvb_module_probe()
with this driver.

Signed-off-by: Katsuhiro Suzuki 

---

Changes since v2:
  - Nothing

Changes since v1:
  - Add documents for dvb_frontend member of helene_config
---
 drivers/media/dvb-frontends/helene.c | 88 ++--
 drivers/media/dvb-frontends/helene.h |  3 +
 2 files changed, 87 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-frontends/helene.c 
b/drivers/media/dvb-frontends/helene.c
index a0d0b53c91d7..04033f0c278b 100644
--- a/drivers/media/dvb-frontends/helene.c
+++ b/drivers/media/dvb-frontends/helene.c
@@ -666,7 +666,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
return 0;
 }
 
-static int helene_set_params(struct dvb_frontend *fe)
+static int helene_set_params_t(struct dvb_frontend *fe)
 {
u8 data[MAX_WRITE_REGSIZE];
u32 frequency;
@@ -835,6 +835,19 @@ static int helene_set_params(struct dvb_frontend *fe)
return 0;
 }
 
+static int helene_set_params(struct dvb_frontend *fe)
+{
+   struct dtv_frontend_properties *p = >dtv_property_cache;
+
+   if (p->delivery_system == SYS_DVBT ||
+   p->delivery_system == SYS_DVBT2 ||
+   p->delivery_system == SYS_ISDBT ||
+   p->delivery_system == SYS_DVBC_ANNEX_A)
+   return helene_set_params_t(fe);
+
+   return helene_set_params_s(fe);
+}
+
 static int helene_get_frequency(struct dvb_frontend *fe, u32 *frequency)
 {
struct helene_priv *priv = fe->tuner_priv;
@@ -843,7 +856,7 @@ static int helene_get_frequency(struct dvb_frontend *fe, 
u32 *frequency)
return 0;
 }
 
-static const struct dvb_tuner_ops helene_tuner_ops = {
+static const struct dvb_tuner_ops helene_tuner_ops_t = {
.info = {
.name = "Sony HELENE Ter tuner",
.frequency_min = 100,
@@ -853,7 +866,7 @@ static const struct dvb_tuner_ops helene_tuner_ops = {
.init = helene_init,
.release = helene_release,
.sleep = helene_sleep,
-   .set_params = helene_set_params,
+   .set_params = helene_set_params_t,
.get_frequency = helene_get_frequency,
 };
 
@@ -871,6 +884,20 @@ static const struct dvb_tuner_ops helene_tuner_ops_s = {
.get_frequency = helene_get_frequency,
 };
 
+static const struct dvb_tuner_ops helene_tuner_ops = {
+   .info = {
+   .name = "Sony HELENE Sat/Ter tuner",
+   .frequency_min = 50,
+   .frequency_max = 12,
+   .frequency_step = 1000,
+   },
+   .init = helene_init,
+   .release = helene_release,
+   .sleep = helene_sleep,
+   .set_params = helene_set_params,
+   .get_frequency = helene_get_frequency,
+};
+
 /* power-on tuner
  * call once after reset
  */
@@ -1032,7 +1059,7 @@ struct dvb_frontend *helene_attach(struct dvb_frontend 
*fe,
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
 
-   memcpy(>ops.tuner_ops, _tuner_ops,
+   memcpy(>ops.tuner_ops, _tuner_ops_t,
sizeof(struct dvb_tuner_ops));
fe->tuner_priv = priv;
dev_info(>i2c->dev,
@@ -1042,6 +1069,59 @@ struct dvb_frontend *helene_attach(struct dvb_frontend 
*fe,
 }
 EXPORT_SYMBOL(helene_attach);
 
+static int helene_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct helene_config *config = client->dev.platform_data;
+   struct dvb_frontend *fe = config->fe;
+   struct device *dev = >dev;
+   struct helene_priv *priv;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   priv->i2c_address = client->addr;
+   priv->i2c = client->adapter;
+   priv->set_tuner_data = config->set_tuner_priv;
+   priv->set_tuner = config->set_tuner_callback;
+   priv->xtal = config->xtal;
+
+   if (fe->ops.i2c_gate_ctrl)
+   fe->ops.i2c_gate_ctrl(fe, 1);
+
+   if (helene_x_pon(priv) != 0)
+   return -EINVAL;
+
+   if (fe->ops.i2c_gate_ctrl)
+   fe->ops.i2c_gate_ctrl(fe, 0);
+
+   memcpy(>ops.tuner_ops, _tuner_ops,
+  sizeof(struct dvb_tuner_ops));
+   fe->tuner_priv = priv;
+   i2c_set_clientdata(client, priv);
+
+   dev_info(dev, "Sony HELENE attached on addr=%x at I2C adapter %p\n",
+priv->i2c_address, priv->i2c);
+
+   return 0;
+}
+
+static const struct i2c_device_id helene_id[] = {
+   { "helene", },
+   {}
+};
+MODULE_DEVICE_TABLE(i2c, helene_id);
+
+static struct i2c_driver helene_driver = {
+   .driver = {
+   .name = "helene",
+   },
+   .probe= helene_probe,
+   .id_table = helene_id,
+};
+module_i2c_driver(helene_driver);
+
 MODULE_DESCRIPTION("Sony HELENE Sat/Ter tuner driver");
 MODULE_AUTHOR("Abylay Ospan ");
 MODULE_LICENSE("GPL");
diff --git 

Re: [PATCH] media: dt-bindings: media: rcar_vin: add support for r8a77965

[Rob Herring]

On Sun, May 13, 2018 at 08:58:18PM +0200, Niklas Söderlund wrote:
> Signed-off-by: Niklas Söderlund 
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1c669eb35..c2c57dcf73f4851b 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -21,6 +21,7 @@ on Gen3 platforms to a CSI-2 receiver.
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7796" for the R8A7796 device
> +   - "renesas,vin-r8a77965" for the R8A77965 device
> - "renesas,vin-r8a77970" for the R8A77970 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
>   device.
> -- 
> 2.17.0
> 

Re: [PATCH 3/4] venus: add check to make scm calls

[Stanimir Varbanov]

Hi Jordan,

On 22.05.2018 22:50, Jordan Crouse wrote:

On Tue, May 22, 2018 at 04:04:51PM +0300, Stanimir Varbanov wrote:

Hi Vikash,

On 05/17/2018 02:32 PM, Vikash Garodia wrote:

In order to invoke scm calls, ensure that the platform
has the required support to invoke the scm calls in
secure world. This code is in preparation to add PIL
functionality in venus driver.

Signed-off-by: Vikash Garodia 
---
  drivers/media/platform/qcom/venus/hfi_venus.c | 26 +++---
  1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
b/drivers/media/platform/qcom/venus/hfi_venus.c
index f61d34b..9bcce94 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus.c
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -27,6 +27,7 @@
  #include "hfi_msgs.h"
  #include "hfi_venus.h"
  #include "hfi_venus_io.h"
+#include "firmware.h"
  
  #define HFI_MASK_QHDR_TX_TYPE		0xff00

  #define HFI_MASK_QHDR_RX_TYPE 0x00ff
@@ -570,13 +571,19 @@ static int venus_halt_axi(struct venus_hfi_device *hdev)
  static int venus_power_off(struct venus_hfi_device *hdev)
  {
int ret;
+   void __iomem *reg_base;
  
  	if (!hdev->power_enabled)

return 0;
  
-	ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);

-   if (ret)
-   return ret;
+   if (qcom_scm_is_available()) {
+   ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);


I think it will be clearer if we abstract qcom_scm_set_remote_state to
something like venus_set_state(SUSPEND|RESUME) in firmware.c and export
the functions to be used here.


This specific function is a little odd because the SCM function got overloaded
and used as a hardware workaround for the adreno a5xx zap shader.

When we added it for the GPU we knew the day would come that we would need it
for Venus so we kept the name purposely generic. You can wrap if if you want
but just know that there are other non video entities out there using it.


Sorry I wasn't clear, by abstract it I meant to introduce a new 
venus_set_state function in venus/firmware.c where we'll select 
tz/non-tz functions for suspend / resume depending on the configuration.


regards,
Stan

Re: [PATCH] media: rcar-vin: Drop unnecessary register properties from example vin port

[Rob Herring]

On Wed, May 09, 2018 at 08:45:58PM +0200, Simon Horman wrote:
> The example vin port node does not have an address and thus does not
> need address-cells or address size-properties.
> 
> Signed-off-by: Simon Horman 
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 3 ---
>  1 file changed, 3 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH] media: uvcvideo: Support realtek's UVC 1.5 device

[Laurent Pinchart]

Hello,

Thank you for the patch.

On Wednesday, 9 May 2018 05:13:08 EEST ming_q...@realsil.com.cn wrote:
> From: ming_qian 
> 
> The length of UVC 1.5 video control is 48, and it id 34 for UVC 1.1.
> Change it to 48 for UVC 1.5 device,
> and the UVC 1.5 device can be recognized.
> 
> More changes to the driver are needed for full UVC 1.5 compatibility.
> However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have
> been reported to work well.

This patch is however not specific to Realtek devices, so I think we should
make the subject line more generic. It's fine mentioning in the commit message
itself that the Realtek RTS5847/RTS5852 cameras have been successfully tested.

> Signed-off-by: ming_qian 
> ---
>  drivers/media/usb/uvc/uvc_video.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c index aa0082f..32dfb32 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -171,6 +171,8 @@ static int uvc_get_video_ctrl(struct uvc_streaming
> *stream, int ret;
> 
>   size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
> + if (stream->dev->uvc_version >= 0x0150)
> + size = 48;
>   if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) &&
>   query == UVC_GET_DEF)
>   return -EIO;
> @@ -259,6 +261,8 @@ static int uvc_set_video_ctrl(struct uvc_streaming
> *stream, int ret;
> 
>   size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
> + if (stream->dev->uvc_version >= 0x0150)
> + size = 48;
>   data = kzalloc(size, GFP_KERNEL);
>   if (data == NULL)
>   return -ENOMEM;

Instead of duplicating the computation in both functions, I think we should
move the code to a helper function.

Furthermore there are equality checks further down both functions that compare
the size to 34, they should be updated to also support UVC 1.5.

I propose the following updated patch. If you're fine with it there's no need
to resubmit, I'll queue it for v4.19.

I have dropped the Reviewed-by and Tested-by tags as the patch has changed.

commit a9c002732695eab2096580a0d1a1687bc2f95928
Author: ming_qian 
Date:   Wed May 9 10:13:08 2018 +0800

media: uvcvideo: Support UVC 1.5 video probe & commit controls

The length of UVC 1.5 video control is 48, and it is 34 for UVC 1.1.
Change it to 48 for UVC 1.5 device, and the UVC 1.5 device can be
recognized.

More changes to the driver are needed for full UVC 1.5 compatibility.
However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have been
reported to work well.

Cc: sta...@vger.kernel.org
Signed-off-by: ming_qian 
[Factor out code to helper function, update size checks]
Signed-off-by: Laurent Pinchart 

diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index eb9e04a59427..285b0e813b9d 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -207,14 +207,27 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming 
*stream,
}
 }
 
+static size_t uvc_video_ctrl_size(struct uvc_streaming *stream)
+{
+   /*
+* Return the size of the video probe and commit controls, which depends
+* on the protocol version.
+*/
+   if (stream->dev->uvc_version < 0x0110)
+   return 26;
+   else if (stream->dev->uvc_version < 0x0150)
+   return 34;
+   else
+   return 48;
+}
+
 static int uvc_get_video_ctrl(struct uvc_streaming *stream,
struct uvc_streaming_control *ctrl, int probe, u8 query)
 {
+   u16 size = uvc_video_ctrl_size(stream);
u8 *data;
-   u16 size;
int ret;
 
-   size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) &&
query == UVC_GET_DEF)
return -EIO;
@@ -271,7 +284,7 @@ static int uvc_get_video_ctrl(struct uvc_streaming *stream,
ctrl->dwMaxVideoFrameSize = get_unaligned_le32([18]);
ctrl->dwMaxPayloadTransferSize = get_unaligned_le32([22]);
 
-   if (size == 34) {
+   if (size >= 34) {
ctrl->dwClockFrequency = get_unaligned_le32([26]);
ctrl->bmFramingInfo = data[30];
ctrl->bPreferedVersion = data[31];
@@ -300,11 +313,10 @@ static int uvc_get_video_ctrl(struct uvc_streaming 
*stream,
 static int uvc_set_video_ctrl(struct uvc_streaming *stream,
struct uvc_streaming_control *ctrl, int probe)
 {
+   u16 size = uvc_video_ctrl_size(stream);
u8 *data;
-   u16 size;
int ret;
 
-   size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
data = kzalloc(size, GFP_KERNEL);
if (data == NULL)

Re: [PATCH v3] media: imx319: Add imx319 camera sensor driver

[jacopo mondi]

Hello Bingbu,
   thanks for the patch

On Tue, May 22, 2018 at 12:33:01PM +0800, bingbu@intel.com wrote:
> From: Bingbu Cao 
>
> Add a V4L2 sub-device driver for the Sony IMX319 image sensor.
> This is a camera sensor using the I2C bus for control and the
> CSI-2 bus for data.

Could you please provide a changelog between versions? Also, I know
using the --in-reply-to option is tempting to keep all patch version
in a single thread, but most people finds it confusing and I rarely
see that.

>
> Signed-off-by: Bingbu Cao 
> Signed-off-by: Tianshu Qiu 
> ---
>  MAINTAINERS|7 +
>  drivers/media/i2c/Kconfig  |   11 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/imx319.c | 2434 
> 
>  4 files changed, 2453 insertions(+)
>  create mode 100644 drivers/media/i2c/imx319.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e73a55a6a855..87b6c338d827 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13084,6 +13084,13 @@ S:   Maintained
>  F:   drivers/media/i2c/imx274.c
>  F:   Documentation/devicetree/bindings/media/i2c/imx274.txt
>
> +SONY IMX319 SENSOR DRIVER
> +M:   Bingbu Cao 
> +L:   linux-media@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Maintained
> +F:   drivers/media/i2c/imx319.c
> +
>  SONY MEMORYSTICK CARD SUPPORT
>  M:   Alex Dubov 
>  W:   http://tifmxx.berlios.de/
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 1f9d7c6aa31a..c3d279cc293e 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -604,6 +604,17 @@ config VIDEO_IMX274
> This is a V4L2 sensor-level driver for the Sony IMX274
> CMOS image sensor.
>
> +config VIDEO_IMX319
> + tristate "Sony IMX319 sensor support"
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CAMERA_SUPPORT
> + help
> +   This is a Video4Linux2 sensor driver for the Sony
> +   IMX319 camera.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called imx319.
> +
>  config VIDEO_OV2640
>   tristate "OmniVision OV2640 sensor support"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 16fc34eda5cc..3adb3be4a486 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -104,5 +104,6 @@ obj-$(CONFIG_VIDEO_OV2659)+= ov2659.o
>  obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
>  obj-$(CONFIG_VIDEO_IMX258)   += imx258.o
>  obj-$(CONFIG_VIDEO_IMX274)   += imx274.o
> +obj-$(CONFIG_VIDEO_IMX319)   += imx319.o
>
>  obj-$(CONFIG_SDR_MAX2175) += max2175.o

This hunk does not apply nor on media tree master nor on Linus'
master. Could you please mention on which branch the patch is meant to
be applied in the cover letter? Maybe it's obvious for most people here,
but I failed to find it.

> diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
> new file mode 100644
> index ..706bbafc75ec
> --- /dev/null
> +++ b/drivers/media/i2c/imx319.c
> @@ -0,0 +1,2434 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2018 Intel Corporation
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IMX319_REG_MODE_SELECT   0x0100
> +#define IMX319_MODE_STANDBY  0x00
> +#define IMX319_MODE_STREAMING0x01
> +
> +/* Chip ID */
> +#define IMX319_REG_CHIP_ID   0x0016
> +#define IMX319_CHIP_ID   0x0319
> +
> +/* V_TIMING internal */
> +#define IMX319_REG_FLL   0x0340
> +#define IMX319_FLL_MAX   0x
> +
> +/* Exposure control */
> +#define IMX319_REG_EXPOSURE  0x0202
> +#define IMX319_EXPOSURE_MIN  1
> +#define IMX319_EXPOSURE_STEP 1
> +#define IMX319_EXPOSURE_DEFAULT  0x04ee
> +
> +/* Analog gain control */
> +#define IMX319_REG_ANALOG_GAIN   0x0204
> +#define IMX319_ANA_GAIN_MIN  0
> +#define IMX319_ANA_GAIN_MAX  960
> +#define IMX319_ANA_GAIN_STEP 1
> +#define IMX319_ANA_GAIN_DEFAULT  0
> +
> +/* Digital gain control */
> +#define IMX319_REG_DPGA_USE_GLOBAL_GAIN  0x3ff9
> +#define IMX319_REG_DIG_GAIN_GLOBAL   0x020e
> +#define IMX319_DGTL_GAIN_MIN 256
> +#define IMX319_DGTL_GAIN_MAX 4095
> +#define IMX319_DGTL_GAIN_STEP1
> +#define IMX319_DGTL_GAIN_DEFAULT 256
> +
> +/* Test Pattern Control */
> +#define IMX319_REG_TEST_PATTERN  0x0600
> +#define IMX319_TEST_PATTERN_DISABLED 0
> +#define IMX319_TEST_PATTERN_SOLID_COLOR  1
> +#define IMX319_TEST_PATTERN_COLOR_BARS   2
> +#define IMX319_TEST_PATTERN_GRAY_COLOR_BARS  3
> +#define IMX319_TEST_PATTERN_PN9  4
> +
> +/* 

Re: [PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization

[Maxime Ripard]

On Mon, May 21, 2018 at 09:39:02AM +0200, Maxime Ripard wrote:
> On Fri, May 18, 2018 at 07:42:34PM -0700, Sam Bobrowicz wrote:
> > On Fri, May 18, 2018 at 3:35 AM, Daniel Mack  wrote:
> > > On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote:
> > >>
> > >> Part of the hardcoded initialization sequence is to set up the proper
> > >> clock
> > >> dividers. However, this is now done dynamically through proper code and 
> > >> as
> > >> such, the static one is now redundant.
> > >>
> > >> Let's remove it.
> > >>
> > >> Signed-off-by: Maxime Ripard 
> > >> ---
> > >
> > >
> > > [...]
> > >
> > >> @@ -625,8 +623,8 @@ static const struct reg_value
> > >> ov5640_setting_30fps_1080P_1920_1080[] = {
> > >> {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
> > >> {0x4001, 0x02, 0, 0}, {0x4004, 0x06, 0, 0}, {0x4713, 0x03, 0, 0},
> > >> {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
> > >> -   {0x3824, 0x02, 0, 0}, {0x5001, 0x83, 0, 0}, {0x3035, 0x11, 0, 0},
> > >> -   {0x3036, 0x54, 0, 0}, {0x3c07, 0x07, 0, 0}, {0x3c08, 0x00, 0, 0},
> > >> +   {0x3824, 0x02, 0, 0}, {0x5001, 0x83, 0, 0},
> > >> +   {0x3c07, 0x07, 0, 0}, {0x3c08, 0x00, 0, 0},
> > >
> > >
> > > This is the mode that I'm testing with. Previously, the hard-coded 
> > > registers
> > > here were:
> > >
> > >  OV5640_REG_SC_PLL_CTRL1 (0x3035) = 0x11
> > >  OV5640_REG_SC_PLL_CTRL2 (0x3036) = 0x54
> > >  OV5640_REG_SC_PLL_CTRL3 (0x3037) = 0x07
> > >
> > > Your new code that calculates the clock rates dynamically ends up with
> > > different values however:
> > >
> > >  OV5640_REG_SC_PLL_CTRL1 (0x3035) = 0x11
> > >  OV5640_REG_SC_PLL_CTRL2 (0x3036) = 0xa8
> > >  OV5640_REG_SC_PLL_CTRL3 (0x3037) = 0x03
> > >
> > > Interestingly, leaving the hard-coded values in the array *and* letting
> > > ov5640_set_mipi_pclk() do its thing later still works. So again it seems
> > > that writes to registers after 0x3035/0x3036/0x3037 seem to depend on the
> > > values of these timing registers. You might need to leave these values as
> > > dummies in the array. Confusing.
> > >
> > > Any idea?
> > >
> > >
> > > Thanks,
> > > Daniel
> > 
> > This set of patches is also not working for my MIPI platform (mine has
> > a 12 MHz external clock). I am pretty sure is isn't working because it
> > does not include the following, which my tests have found to be
> > necessary:
> > 
> > 1) Setting pclk period reg in order to correct DPHY timing.
> > 2) Disabling of MIPI lanes when streaming not enabled.
> > 3) setting mipi_div to 1 when the scaler is disabled
> > 4) Doubling ADC clock on faster resolutions.
> 
> Yeah, I left them out because I didn't think this was relevant to this
> patchset but should come as future improvements. However, given that
> it works with the parallel bus, maybe the two first are needed when
> adjusting the rate.

I've checked for the pclk period, and it's hardcoded to the same value
all the time, so I guess this is not the reason it doesn't work on
MIPI CSI anymore.

Daniel, could you test:
http://code.bulix.org/ki6kgz-339327?raw

And let us know the results?

Thanks!
Maxime

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

Re: [PATCH 3/4] venus: add check to make scm calls

[Jordan Crouse]

On Tue, May 22, 2018 at 04:04:51PM +0300, Stanimir Varbanov wrote:
> Hi Vikash,
> 
> On 05/17/2018 02:32 PM, Vikash Garodia wrote:
> > In order to invoke scm calls, ensure that the platform
> > has the required support to invoke the scm calls in
> > secure world. This code is in preparation to add PIL
> > functionality in venus driver.
> > 
> > Signed-off-by: Vikash Garodia 
> > ---
> >  drivers/media/platform/qcom/venus/hfi_venus.c | 26 
> > +++---
> >  1 file changed, 19 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
> > b/drivers/media/platform/qcom/venus/hfi_venus.c
> > index f61d34b..9bcce94 100644
> > --- a/drivers/media/platform/qcom/venus/hfi_venus.c
> > +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
> > @@ -27,6 +27,7 @@
> >  #include "hfi_msgs.h"
> >  #include "hfi_venus.h"
> >  #include "hfi_venus_io.h"
> > +#include "firmware.h"
> >  
> >  #define HFI_MASK_QHDR_TX_TYPE  0xff00
> >  #define HFI_MASK_QHDR_RX_TYPE  0x00ff
> > @@ -570,13 +571,19 @@ static int venus_halt_axi(struct venus_hfi_device 
> > *hdev)
> >  static int venus_power_off(struct venus_hfi_device *hdev)
> >  {
> > int ret;
> > +   void __iomem *reg_base;
> >  
> > if (!hdev->power_enabled)
> > return 0;
> >  
> > -   ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
> > -   if (ret)
> > -   return ret;
> > +   if (qcom_scm_is_available()) {
> > +   ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
> 
> I think it will be clearer if we abstract qcom_scm_set_remote_state to
> something like venus_set_state(SUSPEND|RESUME) in firmware.c and export
> the functions to be used here.

This specific function is a little odd because the SCM function got overloaded
and used as a hardware workaround for the adreno a5xx zap shader.

When we added it for the GPU we knew the day would come that we would need it
for Venus so we kept the name purposely generic. You can wrap if if you want
but just know that there are other non video entities out there using it.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] media: uvcvideo: Fix driver reference counting

[Laurent Pinchart]

Hi Philipp,

Thank you for the patch.

On Monday, 21 May 2018 13:24:58 EEST Philipp Zabel wrote:
> kref_init initializes the reference count to 1, not 0. This additional
> reference is never released since the conversion to reference counters.
> As a result, uvc_delete is not called anymore when UVC cameras are
> disconnected.
> Fix this by adding an additional kref_put in uvc_disconnect and in the
> probe error path. This also allows to remove the temporary additional
> reference in uvc_unregister_video.

Good catch !

> Fixes: 9d15cd958c17 ("media: uvcvideo: Convert from using an atomic variable
> to a reference count")
> Signed-off-by: Philipp Zabel 

Reviewed-by: Laurent Pinchart 

This is a serious issue so I'd like to get the patch merged in v4.18, but it 
could be argued that it's getting late for that, especially given that the bug 
has been there since v4.14.

Mauro, would you be OK merging this in v4.18 ? If so could you pick it up, or 
would you like me to send a pull request ?

> ---
>  drivers/media/usb/uvc/uvc_driver.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index 2469b49b2b30..8e138201330f
> 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1871,13 +1871,6 @@ static void uvc_unregister_video(struct uvc_device
> *dev) {
>   struct uvc_streaming *stream;
> 
> - /* Unregistering all video devices might result in uvc_delete() being
> -  * called from inside the loop if there's no open file handle. To avoid
> -  * that, increment the refcount before iterating over the streams and
> -  * decrement it when done.
> -  */
> - kref_get(>ref);
> -
>   list_for_each_entry(stream, >streams, list) {
>   if (!video_is_registered(>vdev))
>   continue;
> @@ -1887,8 +1880,6 @@ static void uvc_unregister_video(struct uvc_device
> *dev)
> 
>   uvc_debugfs_cleanup_stream(stream);
>   }
> -
> - kref_put(>ref, uvc_delete);
>  }
> 
>  int uvc_register_video_device(struct uvc_device *dev,
> @@ -2184,6 +2175,7 @@ static int uvc_probe(struct usb_interface *intf,
> 
>  error:
>   uvc_unregister_video(dev);
> + kref_put(>ref, uvc_delete);
>   return -ENODEV;
>  }
> 
> @@ -2201,6 +2193,7 @@ static void uvc_disconnect(struct usb_interface *intf)
> return;
> 
>   uvc_unregister_video(dev);
> + kref_put(>ref, uvc_delete);
>  }
> 
>  static int uvc_suspend(struct usb_interface *intf, pm_message_t message)

-- 
Regards,

Laurent Pinchart

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

[Boris Ostrovsky]

On 05/22/2018 02:27 PM, Oleksandr Andrushchenko wrote:
> On 05/22/2018 09:02 PM, Boris Ostrovsky wrote:
>> On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote:
>>> On 05/22/2018 05:33 PM, Boris Ostrovsky wrote:
 On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:
>> On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote:
>>> On 05/21/2018 09:53 PM, Boris Ostrovsky wrote:
 On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 07:35 PM, Boris Ostrovsky wrote:
>> On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote:
>>> On 05/19/2018 01:04 AM, Boris Ostrovsky wrote:
 On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
> 
 A commit message would be useful.
>>> Sure, v1 will have it
> Signed-off-by: Oleksandr Andrushchenko
> 
>
>    for (i = 0; i < nr_pages; i++) {
> -    page = alloc_page(gfp);
> -    if (page == NULL) {
> -    nr_pages = i;
> -    state = BP_EAGAIN;
> -    break;
> +    if (ext_pages) {
> +    page = ext_pages[i];
> +    } else {
> +    page = alloc_page(gfp);
> +    if (page == NULL) {
> +    nr_pages = i;
> +    state = BP_EAGAIN;
> +    break;
> +    }
>    }
>    scrub_page(page);
>    list_add(>lru, );
> @@ -529,7 +565,7 @@ static enum bp_state
> decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>    i = 0;
>    list_for_each_entry_safe(page, tmp, , lru) {
>    /* XENMEM_decrease_reservation requires a
> GFN */
> -    frame_list[i++] = xen_page_to_gfn(page);
> +    frames[i++] = xen_page_to_gfn(page);
>      #ifdef CONFIG_XEN_HAVE_PVMMU
>    /*
> @@ -552,18 +588,22 @@ static enum bp_state
> decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>    #endif
>    list_del(>lru);
>    -    balloon_append(page);
> +    if (!ext_pages)
> +    balloon_append(page);
 So what you are proposing is not really ballooning. You are
 just
 piggybacking on existing interfaces, aren't you?
>>> Sort of. Basically I need to
>>> {increase|decrease}_reservation, not
>>> actually
>>> allocating ballooned pages.
>>> Do you think I can simply EXPORT_SYMBOL for
>>> {increase|decrease}_reservation?
>>> Any other suggestion?
>> I am actually wondering how much of that code you end up
>> reusing.
>> You
>> pretty much create new code paths in both routines and common
>> code
>> ends
>> up being essentially the hypercall.
> Well, I hoped that it would be easier to maintain if I modify
> existing
> code
> to support both use-cases, but I am also ok to create new
> routines if
> this
> seems to be reasonable - please let me know
>>   So the question is --- would it make
>> sense to do all of this separately from the balloon driver?
> This can be done, but which driver will host this code then?
> If we
> move from
> the balloon driver, then this could go to either gntdev or
> grant-table.
> What's your preference?
 A separate module?
 Is there any use for this feature outside of your zero-copy DRM
 driver?
>>> Intel's hyper dma-buf (Dongwon/Matt CC'ed), V4L/GPU at least.
>>>
>>> At the time I tried to upstream zcopy driver it was discussed and
>>> decided that
>>> it would be better if I remove all DRM specific code and move it to
>>> Xen drivers.
>>> Thus, this RFC.
>>>
>>> But it can also be implemented as a dedicated Xen dma-buf driver
>>> which
>>> will have all the
>>> code from this RFC + a bit more (char/misc device handling at
>>> least).
>>> This will also require a dedicated user-space library, just like
>>> libxengnttab.so
>>> for gntdev (now I have all new IOCTLs covered there).
>>>
>>> If the idea of a dedicated Xen dma-buf driver seems to be more
>>> attractive we
>>> can work toward this solution. BTW, I do support this idea, but
>>> was not
>>> sure if Xen 

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

[Oleksandr Andrushchenko]

On 05/22/2018 09:02 PM, Boris Ostrovsky wrote:

On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote:

On 05/22/2018 05:33 PM, Boris Ostrovsky wrote:

On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:

On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:

On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote:

On 05/21/2018 09:53 PM, Boris Ostrovsky wrote:

On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote:

On 05/21/2018 07:35 PM, Boris Ostrovsky wrote:

On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote:

On 05/19/2018 01:04 AM, Boris Ostrovsky wrote:

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko


A commit message would be useful.

Sure, v1 will have it

Signed-off-by: Oleksandr Andrushchenko


   for (i = 0; i < nr_pages; i++) {
-    page = alloc_page(gfp);
-    if (page == NULL) {
-    nr_pages = i;
-    state = BP_EAGAIN;
-    break;
+    if (ext_pages) {
+    page = ext_pages[i];
+    } else {
+    page = alloc_page(gfp);
+    if (page == NULL) {
+    nr_pages = i;
+    state = BP_EAGAIN;
+    break;
+    }
   }
   scrub_page(page);
   list_add(>lru, );
@@ -529,7 +565,7 @@ static enum bp_state
decrease_reservation(unsigned long nr_pages, gfp_t gfp)
   i = 0;
   list_for_each_entry_safe(page, tmp, , lru) {
   /* XENMEM_decrease_reservation requires a GFN */
-    frame_list[i++] = xen_page_to_gfn(page);
+    frames[i++] = xen_page_to_gfn(page);
     #ifdef CONFIG_XEN_HAVE_PVMMU
   /*
@@ -552,18 +588,22 @@ static enum bp_state
decrease_reservation(unsigned long nr_pages, gfp_t gfp)
   #endif
   list_del(>lru);
   -    balloon_append(page);
+    if (!ext_pages)
+    balloon_append(page);

So what you are proposing is not really ballooning. You are just
piggybacking on existing interfaces, aren't you?

Sort of. Basically I need to {increase|decrease}_reservation, not
actually
allocating ballooned pages.
Do you think I can simply EXPORT_SYMBOL for
{increase|decrease}_reservation?
Any other suggestion?

I am actually wondering how much of that code you end up reusing.
You
pretty much create new code paths in both routines and common code
ends
up being essentially the hypercall.

Well, I hoped that it would be easier to maintain if I modify
existing
code
to support both use-cases, but I am also ok to create new
routines if
this
seems to be reasonable - please let me know

  So the question is --- would it make
sense to do all of this separately from the balloon driver?

This can be done, but which driver will host this code then? If we
move from
the balloon driver, then this could go to either gntdev or
grant-table.
What's your preference?

A separate module?
Is there any use for this feature outside of your zero-copy DRM
driver?

Intel's hyper dma-buf (Dongwon/Matt CC'ed), V4L/GPU at least.

At the time I tried to upstream zcopy driver it was discussed and
decided that
it would be better if I remove all DRM specific code and move it to
Xen drivers.
Thus, this RFC.

But it can also be implemented as a dedicated Xen dma-buf driver
which
will have all the
code from this RFC + a bit more (char/misc device handling at least).
This will also require a dedicated user-space library, just like
libxengnttab.so
for gntdev (now I have all new IOCTLs covered there).

If the idea of a dedicated Xen dma-buf driver seems to be more
attractive we
can work toward this solution. BTW, I do support this idea, but
was not
sure if Xen community accepts yet another driver which duplicates
quite some code
of the existing gntdev/balloon/grant-table. And now after this RFC I
hope that all cons
and pros of both dedicated driver and gntdev/balloon/grant-table
extension are
clearly seen and we can make a decision.

IIRC the objection for a separate module was in the context of gntdev
was discussion, because (among other things) people didn't want to
have
yet another file in /dev/xen/

Here we are talking about (a new) balloon-like module which doesn't
create any new user-visible interfaces. And as for duplicating code
---
as I said, I am not convinced there is much of duplication.

I might even argue that we should add a new config option for this
module.

I am not quite sure I am fully following you here: so, you suggest
that we have balloon.c unchanged, but instead create a new
module (namely a file under the same folder as balloon.c, e.g.
dma-buf-reservation.c) and move those {increase|decrease}_reservation
routines (specific to dma-buf) to that new file? And make it selectable
via Kconfig? If so, then how about the changes to grant-table and
gntdev?
Those will look inconsistent then.

Inconsistent with what? The changes to grant code will also be under the
new config option.

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

[Boris Ostrovsky]

On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote:
> On 05/22/2018 05:33 PM, Boris Ostrovsky wrote:
>> On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:
>>> On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:
 On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 09:53 PM, Boris Ostrovsky wrote:
>> On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote:
>>> On 05/21/2018 07:35 PM, Boris Ostrovsky wrote:
 On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote:
> On 05/19/2018 01:04 AM, Boris Ostrovsky wrote:
>> On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>> 
>> A commit message would be useful.
> Sure, v1 will have it
>>> Signed-off-by: Oleksandr Andrushchenko
>>> 
>>>
>>>   for (i = 0; i < nr_pages; i++) {
>>> -    page = alloc_page(gfp);
>>> -    if (page == NULL) {
>>> -    nr_pages = i;
>>> -    state = BP_EAGAIN;
>>> -    break;
>>> +    if (ext_pages) {
>>> +    page = ext_pages[i];
>>> +    } else {
>>> +    page = alloc_page(gfp);
>>> +    if (page == NULL) {
>>> +    nr_pages = i;
>>> +    state = BP_EAGAIN;
>>> +    break;
>>> +    }
>>>   }
>>>   scrub_page(page);
>>>   list_add(>lru, );
>>> @@ -529,7 +565,7 @@ static enum bp_state
>>> decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>>>   i = 0;
>>>   list_for_each_entry_safe(page, tmp, , lru) {
>>>   /* XENMEM_decrease_reservation requires a GFN */
>>> -    frame_list[i++] = xen_page_to_gfn(page);
>>> +    frames[i++] = xen_page_to_gfn(page);
>>>     #ifdef CONFIG_XEN_HAVE_PVMMU
>>>   /*
>>> @@ -552,18 +588,22 @@ static enum bp_state
>>> decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>>>   #endif
>>>   list_del(>lru);
>>>   -    balloon_append(page);
>>> +    if (!ext_pages)
>>> +    balloon_append(page);
>> So what you are proposing is not really ballooning. You are just
>> piggybacking on existing interfaces, aren't you?
> Sort of. Basically I need to {increase|decrease}_reservation, not
> actually
> allocating ballooned pages.
> Do you think I can simply EXPORT_SYMBOL for
> {increase|decrease}_reservation?
> Any other suggestion?
 I am actually wondering how much of that code you end up reusing.
 You
 pretty much create new code paths in both routines and common code
 ends
 up being essentially the hypercall.
>>> Well, I hoped that it would be easier to maintain if I modify
>>> existing
>>> code
>>> to support both use-cases, but I am also ok to create new
>>> routines if
>>> this
>>> seems to be reasonable - please let me know
  So the question is --- would it make
 sense to do all of this separately from the balloon driver?
>>> This can be done, but which driver will host this code then? If we
>>> move from
>>> the balloon driver, then this could go to either gntdev or
>>> grant-table.
>>> What's your preference?
>> A separate module?
>> Is there any use for this feature outside of your zero-copy DRM
>> driver?
> Intel's hyper dma-buf (Dongwon/Matt CC'ed), V4L/GPU at least.
>
> At the time I tried to upstream zcopy driver it was discussed and
> decided that
> it would be better if I remove all DRM specific code and move it to
> Xen drivers.
> Thus, this RFC.
>
> But it can also be implemented as a dedicated Xen dma-buf driver
> which
> will have all the
> code from this RFC + a bit more (char/misc device handling at least).
> This will also require a dedicated user-space library, just like
> libxengnttab.so
> for gntdev (now I have all new IOCTLs covered there).
>
> If the idea of a dedicated Xen dma-buf driver seems to be more
> attractive we
> can work toward this solution. BTW, I do support this idea, but
> was not
> sure if Xen community accepts yet another driver which duplicates
> quite some code
> of the existing gntdev/balloon/grant-table. And now after this RFC I
> hope that all cons
> and pros of both dedicated driver and gntdev/balloon/grant-table
> extension are
> clearly seen and we can make a decision.
 IIRC the objection for a separate module was in the context of gntdev
 was discussion, 

Re: [media] duplicate code in media drivers

[Gustavo A. R. Silva]

On 05/21/2018 03:44 PM, Devin Heitmueller wrote:

diff -u -p drivers/media/dvb-frontends/au8522_decoder.c 
/tmp/nothing/media/dvb-frontends/au8522_decoder.c
--- drivers/media/dvb-frontends/au8522_decoder.c
+++ /tmp/nothing/media/dvb-frontends/au8522_decoder.c
@@ -280,14 +280,9 @@ static void setup_decoder_defaults(struc
 AU8522_TOREGAAGC_REG0E5H_CVBS);
 au8522_writereg(state, AU8522_REG016H, AU8522_REG016H_CVBS);

-   if (is_svideo) {
 /* Despite what the table says, for the HVR-950q we still need
to be in CVBS mode for the S-Video input (reason unknown). 
*/
 /* filter_coef_type = 3; */
-   filter_coef_type = 5;
-   } else {
-   filter_coef_type = 5;
-   }


Better ask Devin about this (c/c).


This was a case where the implementation didn't match the datasheet,
and it wasn't clear why the filter coefficients weren't working
properly.  Essentially I should have labeled that as a TODO or FIXME
when I disabled the "right" value and forced it to always be five.  It
was also likely that the filter coefficients would need to differ if
taking video over the IF interface as opposed to CVBS/S-video, which
is why I didn't want to get rid of the logic entirely.  That said, the
only product I've ever seen with the tda18271 mated to the au8522 will
likely never be supported for analog video under Linux for unrelated
reasons.

That said, it's worked "good enough" since I wrote the code nine years
ago, so if somebody wants to submit a patch to either get rid of the
if() statement or mark it as a FIXME that will likely never actually
get fixed, I wouldn't have an objection to either.



Devin,

I've sent a patch based on your feedback.

Thanks!
--
Gustavo

Re: [PATCH] media: video-mux: fix compliance failures

[Hans Verkuil]

On 22/05/18 18:29, Philipp Zabel wrote:
> Limit frame sizes to the [1, UINT_MAX-1] interval, media bus formats to
> the available list of formats, and initialize pad and try formats.
> 
> Reported-by: Rui Miguel Silva 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/media/platform/video-mux.c | 110 +
>  1 file changed, 110 insertions(+)
> 
> diff --git a/drivers/media/platform/video-mux.c 
> b/drivers/media/platform/video-mux.c
> index 1fb887293337..ade1dae706aa 100644
> --- a/drivers/media/platform/video-mux.c
> +++ b/drivers/media/platform/video-mux.c
> @@ -180,6 +180,87 @@ static int video_mux_set_format(struct v4l2_subdev *sd,
>   if (!source_mbusformat)
>   return -EINVAL;
>  
> + /* No size limitations except V4L2 compliance requirements */
> + v4l_bound_align_image(>format.width, 1, UINT_MAX - 1, 0,
> +   >format.height, 1, UINT_MAX - 1, 0, 0);

This is a bit dubious. I would pick more realistic min/max values like 16 and
65536. UINT_MAX - 1 will overflow whenever code increments/multiplies it for 
some
reason, which can cause all sorts of weird issues.

> +
> + /* All formats except LVDS and vendor specific formats are acceptable */
> + switch (sdformat->format.code) {
> + case MEDIA_BUS_FMT_RGB444_1X12:
> + case MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE:
> + case MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE:
> + case MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE:
> + case MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE:
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + case MEDIA_BUS_FMT_BGR565_2X8_BE:
> + case MEDIA_BUS_FMT_BGR565_2X8_LE:
> + case MEDIA_BUS_FMT_RGB565_2X8_BE:
> + case MEDIA_BUS_FMT_RGB565_2X8_LE:
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + case MEDIA_BUS_FMT_RBG888_1X24:
> + case MEDIA_BUS_FMT_RGB666_1X24_CPADHI:
> + case MEDIA_BUS_FMT_BGR888_1X24:
> + case MEDIA_BUS_FMT_GBR888_1X24:
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + case MEDIA_BUS_FMT_RGB888_2X12_BE:
> + case MEDIA_BUS_FMT_RGB888_2X12_LE:
> + case MEDIA_BUS_FMT_ARGB_1X32:
> + case MEDIA_BUS_FMT_RGB888_1X32_PADHI:
> + case MEDIA_BUS_FMT_RGB101010_1X30:
> + case MEDIA_BUS_FMT_RGB121212_1X36:
> + case MEDIA_BUS_FMT_RGB161616_1X48:
> + case MEDIA_BUS_FMT_Y8_1X8:
> + case MEDIA_BUS_FMT_UV8_1X8:
> + case MEDIA_BUS_FMT_UYVY8_1_5X8:
> + case MEDIA_BUS_FMT_VYUY8_1_5X8:
> + case MEDIA_BUS_FMT_YUYV8_1_5X8:
> + case MEDIA_BUS_FMT_YVYU8_1_5X8:
> + case MEDIA_BUS_FMT_UYVY8_2X8:
> + case MEDIA_BUS_FMT_VYUY8_2X8:
> + case MEDIA_BUS_FMT_YUYV8_2X8:
> + case MEDIA_BUS_FMT_YVYU8_2X8:
> + case MEDIA_BUS_FMT_Y10_1X10:
> + case MEDIA_BUS_FMT_UYVY10_2X10:
> + case MEDIA_BUS_FMT_VYUY10_2X10:
> + case MEDIA_BUS_FMT_YUYV10_2X10:
> + case MEDIA_BUS_FMT_YVYU10_2X10:
> + case MEDIA_BUS_FMT_Y12_1X12:
> + case MEDIA_BUS_FMT_UYVY12_2X12:
> + case MEDIA_BUS_FMT_VYUY12_2X12:
> + case MEDIA_BUS_FMT_YUYV12_2X12:
> + case MEDIA_BUS_FMT_YVYU12_2X12:
> + case MEDIA_BUS_FMT_UYVY8_1X16:
> + case MEDIA_BUS_FMT_VYUY8_1X16:
> + case MEDIA_BUS_FMT_YUYV8_1X16:
> + case MEDIA_BUS_FMT_YVYU8_1X16:
> + case MEDIA_BUS_FMT_YDYUYDYV8_1X16:
> + case MEDIA_BUS_FMT_UYVY10_1X20:
> + case MEDIA_BUS_FMT_VYUY10_1X20:
> + case MEDIA_BUS_FMT_YUYV10_1X20:
> + case MEDIA_BUS_FMT_YVYU10_1X20:
> + case MEDIA_BUS_FMT_VUY8_1X24:
> + case MEDIA_BUS_FMT_YUV8_1X24:
> + case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
> + case MEDIA_BUS_FMT_UYVY12_1X24:
> + case MEDIA_BUS_FMT_VYUY12_1X24:
> + case MEDIA_BUS_FMT_YUYV12_1X24:
> + case MEDIA_BUS_FMT_YVYU12_1X24:
> + case MEDIA_BUS_FMT_YUV10_1X30:
> + case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
> + case MEDIA_BUS_FMT_AYUV8_1X32:
> + case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
> + case MEDIA_BUS_FMT_YUV12_1X36:
> + case MEDIA_BUS_FMT_YUV16_1X48:
> + case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
> + case MEDIA_BUS_FMT_JPEG_1X8:
> + case MEDIA_BUS_FMT_AHSV_1X32:
> + break;
> + default:
> + sdformat->format.code = MEDIA_BUS_FMT_Y8_1X8;

Add a break here.

> + }
> + if (sdformat->format.field == V4L2_FIELD_ANY)
> + sdformat->format.field = V4L2_FIELD_NONE;
> +
>   mutex_lock(>lock);
>  
>   /* Source pad mirrors active sink pad, no limitations on sink pads */
> @@ -197,11 +278,33 @@ static int video_mux_set_format(struct v4l2_subdev *sd,
>   return 0;
>  }
>  
> +static int video_mux_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> +{
> + struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
> + struct v4l2_mbus_framefmt *mbusformat;
> + int i;
> +
> + mutex_lock(>lock);
> +
> + for (i = 0; i < sd->entity.num_pads; i++) {
> + mbusformat = v4l2_subdev_get_try_format(sd, fh->pad, i);
> + *mbusformat = vmux->format_mbus[i];
> + }
> +

Re: [PATCH v10 12/16] vb2: add in-fence support to QBUF

[Ezequiel Garcia]

On Tue, 2018-05-22 at 18:48 +0200, Hans Verkuil wrote:
> On 22/05/18 18:22, Ezequiel Garcia wrote:
> > > > @@ -1615,7 +1762,12 @@ static void __vb2_dqbuf(struct vb2_buffer *vb)
> > > > return;
> > > >  
> > > > vb->state = VB2_BUF_STATE_DEQUEUED;
> > > > -
> > > > +   if (vb->in_fence) {
> > > > +   if (dma_fence_remove_callback(vb->in_fence, 
> > > > >fence_cb))
> > > > +   __vb2_buffer_put(vb);
> > > > +   dma_fence_put(vb->in_fence);
> > > > +   vb->in_fence = NULL;
> > > > +   }
> > > > /* unmap DMABUF buffer */
> > > > if (q->memory == VB2_MEMORY_DMABUF)
> > > > for (i = 0; i < vb->num_planes; ++i) {
> > > > @@ -1653,7 +1805,7 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned 
> > > > int *pindex, void *pb,
> > > > if (pindex)
> > > > *pindex = vb->index;
> > > >  
> > > > -   /* Fill buffer information for the userspace */
> > > > +   /* Fill buffer information for userspace */
> > > > if (pb)
> > > > call_void_bufop(q, fill_user_buffer, vb, pb);
> > > >  
> > > > @@ -1700,8 +1852,8 @@ static void __vb2_queue_cancel(struct vb2_queue 
> > > > *q)
> > > > if (WARN_ON(atomic_read(>owned_by_drv_count))) {
> > > > for (i = 0; i < q->num_buffers; ++i)
> > > > if (q->bufs[i]->state == VB2_BUF_STATE_ACTIVE) {
> > > > -   pr_warn("driver bug: stop_streaming 
> > > > operation is leaving buf %p in active
> > > > state\n",
> > > > -   q->bufs[i]);
> > > > +   pr_warn("driver bug: stop_streaming 
> > > > operation is leaving buf[%d] 0x%p in active
> > > > state\n",
> > > > +   q->bufs[i]->index, q->bufs[i]);
> > > > vb2_buffer_done(q->bufs[i], 
> > > > VB2_BUF_STATE_ERROR);
> > > > }
> > > 
> > > Shouldn't any pending fences be canceled here?
> > > 
> > 
> > No, we don't have to flush -- that's the reason of the refcount :)
> > The qbuf_work won't do anything if all the buffers are returned
> > by the driver (with error or done state), and if !streaming.
> > 
> > Also, note that's why qbuf_work checks for the queued state, and not
> > for the error state.
> > 
> > > I feel uncomfortable with the refcounting of buffers, I'd rather that 
> > > when we
> > > cancel the queue all fences for buffers are removed/canceled/whatever.
> > > 
> > > Is there any reason for refcounting if we cancel all pending fences here?
> > > 
> > > Note that besides canceling fences you also need to cancel/flush 
> > > __qbuf_work.
> > > 
> > > 
> > 
> > Like I said above, I'm trying to avoid cancel/flushing the workqueue.
> > Currently, I believe it works fine without any flushing, provided we 
> > refcount
> > the buffers.
> > 
> > The problem with cancelling the workqueue, is that you need to unlock the 
> > queue
> > lock, to avoid a deadlock. It seemed to me that having a refcount is more 
> > natural.
> > 
> > Thoughts?
> > 
> 
> I'll take another look tomorrow morning. Do you have a public git tree 
> containing
> this series that I can browse?
> 
> 

Sure, there you go 
http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/fences_v10_v4.17-rc1

Re: [PATCH v4 0/3] IR decoding using BPF

[VDR User]

Sean, I'd like to echo Matthias's appreciation for your work with this
BPF project. I'm very much looking forward to the possibility of using
my remotes directly with decoders generated from the existing
lircd.conf's. Excited seeing your work progress!

Cheers,
Derek

On Tue, May 22, 2018 at 6:50 AM, Matthias Reichl  wrote:
> Hi Sean,
>
> On Fri, May 18, 2018 at 03:07:27PM +0100, Sean Young wrote:
>> The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most
>> widely used IR protocols, but there are many protocols which are not
>> supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes,
>> many of which are not supported by rc-core. There is a "long tail" of
>> unsupported IR protocols, for which lircd is need to decode the IR .
>>
>> IR encoding is done in such a way that some simple circuit can decode it;
>> therefore, bpf is ideal.
>>
>> In order to support all these protocols, here we have bpf based IR decoding.
>> The idea is that user-space can define a decoder in bpf, attach it to
>> the rc device through the lirc chardev.
>>
>> Separate work is underway to extend ir-keytable to have an extensive library
>> of bpf-based decoders, and a much expanded library of rc keymaps.
>>
>> Another future application would be to compile IRP[3] to a IR BPF program, 
>> and
>> so support virtually every remote without having to write a decoder for each.
>> It might also be possible to support non-button devices such as analog
>> directional pads or air conditioning remote controls and decode the target
>> temperature in bpf, and pass that to an input device.
>
> Thanks a lot, this looks like a very interesting feature to me!
>
> Unfortunately I don't have time to test it ATM, but please keep
> me posted - also on ir-keytable progress - I'm rather excited
> to give it a try.
>
> so long & thanks,
>
> Hias
>
>>
>> Thanks,
>>
>> Sean Young
>>
>> [1] http://www.hifi-remote.com/wiki/index.php?title=DecodeIR
>> [2] https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/
>> [3] http://www.hifi-remote.com/wiki/index.php?title=IRP_Notation
>>
>> Changes since v3:
>>  - Implemented review comments from Quentin Monnet and Y Song (thanks!)
>>  - More helpful and better formatted bpf helper documentation
>>  - Changed back to bpf_prog_array rather than open-coded implementation
>>  - scancodes can be 64 bit
>>  - bpf gets passed values in microseconds, not nanoseconds.
>>microseconds is more than than enough (IR receivers support carriers upto
>>70kHz, at which point a single period is already 14 microseconds). Also,
>>this makes it much more consistent with lirc mode2.
>>  - Since it looks much more like lirc mode2, rename the program type to
>>BPF_PROG_TYPE_LIRC_MODE2.
>>  - Rebased on bpf-next
>>
>> Changes since v2:
>>  - Fixed locking issues
>>  - Improved self-test to cover more cases
>>  - Rebased on bpf-next again
>>
>> Changes since v1:
>>  - Code review comments from Y Song  and
>>Randy Dunlap 
>>  - Re-wrote sample bpf to be selftest
>>  - Renamed RAWIR_DECODER -> RAWIR_EVENT (Kconfig, context, bpf prog type)
>>  - Rebase on bpf-next
>>  - Introduced bpf_rawir_event context structure with simpler access checking
>>
>> Sean Young (3):
>>   bpf: bpf_prog_array_copy() should return -ENOENT if exclude_prog not
>> found
>>   media: rc: introduce BPF_PROG_LIRC_MODE2
>>   bpf: add selftest for lirc_mode2 type program
>>
>>  drivers/media/rc/Kconfig  |  13 +
>>  drivers/media/rc/Makefile |   1 +
>>  drivers/media/rc/bpf-lirc.c   | 308 ++
>>  drivers/media/rc/lirc_dev.c   |  30 ++
>>  drivers/media/rc/rc-core-priv.h   |  22 ++
>>  drivers/media/rc/rc-ir-raw.c  |  12 +-
>>  include/linux/bpf_rcdev.h |  30 ++
>>  include/linux/bpf_types.h |   3 +
>>  include/uapi/linux/bpf.h  |  53 ++-
>>  kernel/bpf/core.c |  11 +-
>>  kernel/bpf/syscall.c  |   7 +
>>  kernel/trace/bpf_trace.c  |   2 +
>>  tools/bpf/bpftool/prog.c  |   1 +
>>  tools/include/uapi/linux/bpf.h|  53 ++-
>>  tools/include/uapi/linux/lirc.h   | 217 
>>  tools/lib/bpf/libbpf.c|   1 +
>>  tools/testing/selftests/bpf/Makefile  |   8 +-
>>  tools/testing/selftests/bpf/bpf_helpers.h |   6 +
>>  .../testing/selftests/bpf/test_lirc_mode2.sh  |  28 ++
>>  .../selftests/bpf/test_lirc_mode2_kern.c  |  23 ++
>>  .../selftests/bpf/test_lirc_mode2_user.c  | 154 +
>>  21 files changed, 974 insertions(+), 9 deletions(-)
>>  create mode 100644 drivers/media/rc/bpf-lirc.c
>>  create mode 100644 include/linux/bpf_rcdev.h
>>  create mode 100644 tools/include/uapi/linux/lirc.h
>>  create mode 100755 

Re: [PATCH] au8522: remove duplicate code

[Devin Heitmueller]

Reviewed-by: Devin Heitmueller 

Devin

On Tue, May 22, 2018 at 1:09 PM, Gustavo A. R. Silva
 wrote:
> This code has been there for nine years now, and it has been
> working "good enough" since then [1].
>
> Remove duplicate code by getting rid of the if-else statement.
>
> [1] https://marc.info/?l=linux-kernel=152693550225081=2
>
> Cc: Devin Heitmueller 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/media/dvb-frontends/au8522_decoder.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/au8522_decoder.c 
> b/drivers/media/dvb-frontends/au8522_decoder.c
> index 343dc92..f285096 100644
> --- a/drivers/media/dvb-frontends/au8522_decoder.c
> +++ b/drivers/media/dvb-frontends/au8522_decoder.c
> @@ -280,14 +280,12 @@ static void setup_decoder_defaults(struct au8522_state 
> *state, bool is_svideo)
> AU8522_TOREGAAGC_REG0E5H_CVBS);
> au8522_writereg(state, AU8522_REG016H, AU8522_REG016H_CVBS);
>
> -   if (is_svideo) {
> -   /* Despite what the table says, for the HVR-950q we still need
> -  to be in CVBS mode for the S-Video input (reason unknown). 
> */
> -   /* filter_coef_type = 3; */
> -   filter_coef_type = 5;
> -   } else {
> -   filter_coef_type = 5;
> -   }
> +   /*
> +* Despite what the table says, for the HVR-950q we still need
> +* to be in CVBS mode for the S-Video input (reason unknown).
> +*/
> +   /* filter_coef_type = 3; */
> +   filter_coef_type = 5;
>
> /* Load the Video Decoder Filter Coefficients */
> for (i = 0; i < NUM_FILTER_COEF; i++) {
> --
> 2.7.4
>



-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

[PATCH] au8522: remove duplicate code

[Gustavo A. R. Silva]

This code has been there for nine years now, and it has been
working "good enough" since then [1].

Remove duplicate code by getting rid of the if-else statement.

[1] https://marc.info/?l=linux-kernel=152693550225081=2

Cc: Devin Heitmueller 
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/dvb-frontends/au8522_decoder.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/media/dvb-frontends/au8522_decoder.c 
b/drivers/media/dvb-frontends/au8522_decoder.c
index 343dc92..f285096 100644
--- a/drivers/media/dvb-frontends/au8522_decoder.c
+++ b/drivers/media/dvb-frontends/au8522_decoder.c
@@ -280,14 +280,12 @@ static void setup_decoder_defaults(struct au8522_state 
*state, bool is_svideo)
AU8522_TOREGAAGC_REG0E5H_CVBS);
au8522_writereg(state, AU8522_REG016H, AU8522_REG016H_CVBS);
 
-   if (is_svideo) {
-   /* Despite what the table says, for the HVR-950q we still need
-  to be in CVBS mode for the S-Video input (reason unknown). */
-   /* filter_coef_type = 3; */
-   filter_coef_type = 5;
-   } else {
-   filter_coef_type = 5;
-   }
+   /*
+* Despite what the table says, for the HVR-950q we still need
+* to be in CVBS mode for the S-Video input (reason unknown).
+*/
+   /* filter_coef_type = 3; */
+   filter_coef_type = 5;
 
/* Load the Video Decoder Filter Coefficients */
for (i = 0; i < NUM_FILTER_COEF; i++) {
-- 
2.7.4

Re: [media] duplicate code in media drivers

[Gustavo A. R. Silva]

Mauro,

I already sent some patches based on your comments.

Thanks!
--
Gustavo

On 05/21/2018 03:14 PM, Mauro Carvalho Chehab wrote:

Em Mon, 21 May 2018 14:39:51 -0500
"Gustavo A. R. Silva"  escreveu:


Hi Mauro,

I found some duplicate code with the help of Coccinelle and Coverity. Notice 
that these are not code patches, they only point out the duplicate code in some 
media drivers:

diff -u -p drivers/media/pci/bt8xx/dvb-bt8xx.c 
/tmp/nothing/media/pci/bt8xx/dvb-bt8xx.c
--- drivers/media/pci/bt8xx/dvb-bt8xx.c
+++ /tmp/nothing/media/pci/bt8xx/dvb-bt8xx.c
@@ -389,9 +389,7 @@ static int advbt771_samsung_tdtc9251dh0_
 else if (c->frequency < 6)
 bs = 0x08;
 else if (c->frequency < 73000)
-   bs = 0x08;
 else
-   bs = 0x08;

 pllbuf[0] = 0x61;
 pllbuf[1] = div >> 8;



Hmm... I *suspect* that "bs" here controls the frequency range for the
tuner. Analog tuners have separate frequency regions that are controlled
via a register, into a 4 or 5 bytes I2C sequence. They're all somewhat
a clone of an old Philips design.

It should be safe to convert the "BS" sequence on something like:

if (c->frequency < 17300)
 bs = 0x01;
 else if (c->frequency < 47000)
 bs = 0x02;
 else
 bs = 0x08;




diff -u -p drivers/media/usb/dvb-usb/dib0700_devices.c 
/tmp/nothing/media/usb/dvb-usb/dib0700_devices.c
--- drivers/media/usb/dvb-usb/dib0700_devices.c
+++ /tmp/nothing/media/usb/dvb-usb/dib0700_devices.c
@@ -1741,13 +1741,6 @@ static int dib809x_tuner_attach(struct d
 struct dib0700_adapter_state *st = adap->priv;
 struct i2c_adapter *tun_i2c = 
st->dib8000_ops.get_i2c_master(adap->fe_adap[0].fe, 
DIBX000_I2C_INTERFACE_TUNER, 1);

-   if (adap->id == 0) {
-   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
-   return -ENODEV;
-   } else {
-   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
-   return -ENODEV;
-   }


I'm almost sure that, on the second if, it should be adap->fe_adap[1].fe.
I tried in the past to check this, but didn't got an answer from the one
that wrote the code.

Maybe we could add a /* FIXME: check if it is fe_adap[1] */ on the
second clause.



 st->set_param_save = adap->fe_adap[0].fe->ops.tuner_ops.set_params;
 adap->fe_adap[0].fe->ops.tuner_ops.set_params = 
dib8096_set_param_override;
diff -u -p drivers/media/dvb-frontends/mb86a16.c 
/tmp/nothing/media/dvb-frontends/mb86a16.c
--- drivers/media/dvb-frontends/mb86a16.c
+++ /tmp/nothing/media/dvb-frontends/mb86a16.c
@@ -1466,9 +1466,7 @@ static int mb86a16_set_fe(struct mb86a16
 wait_t = (1572864 + 
state->srate / 2) / state->srate;
 if (state->srate < 5000)
 /* FIXME ! , should be 
a long wait ! */
-   
msleep_interruptible(wait_t);
 else
-   
msleep_interruptible(wait_t);


I suspect that the goal here is to point that sleeping for
(1572864 + state->srate / 2) / state->srate when srate is low will mean
that it will take a lot of time to converge (probably causing timeout at
userspace).

Basically, if srate is < 5000, the sleep time will be between
314 and 1575364 ms. The worse case scenario - although not realistic,
in practice - is to wait up to 26 seconds. This is a very long time!

Probably, the right fix here would be to check if wait_t is bigger than
a certain amount of time. If so, return an error.

I'm not against removing the if, but, if so, better to add a /* FIXME */
block explaining that.

That's said, this is an old device. I doubt anyone would fix it.




 if (sync_chk(state, ) == 
0) {
 iq_vt_set(state, 1);
diff -u -p drivers/media/dvb-frontends/au8522_decoder.c 
/tmp/nothing/media/dvb-frontends/au8522_decoder.c
--- drivers/media/dvb-frontends/au8522_decoder.c
+++ /tmp/nothing/media/dvb-frontends/au8522_decoder.c
@@ -280,14 +280,9 @@ static void setup_decoder_defaults(struc
 AU8522_TOREGAAGC_REG0E5H_CVBS);
 au8522_writereg(state, AU8522_REG016H, AU8522_REG016H_CVBS);

-   if (is_svideo) {
 /* Despite what the table says, for the HVR-950q we still need
to be in CVBS mode for the S-Video input (reason unknown). 
*/
 /* filter_coef_type = 3; */
-   filter_coef_type = 5;
-   } else {
-   filter_coef_type = 5;
-   }


Better ask Devin 

Re: [PATCH v10 12/16] vb2: add in-fence support to QBUF

[Hans Verkuil]

On 22/05/18 18:22, Ezequiel Garcia wrote:
>>> @@ -1615,7 +1762,12 @@ static void __vb2_dqbuf(struct vb2_buffer *vb)
>>> return;
>>>  
>>> vb->state = VB2_BUF_STATE_DEQUEUED;
>>> -
>>> +   if (vb->in_fence) {
>>> +   if (dma_fence_remove_callback(vb->in_fence, >fence_cb))
>>> +   __vb2_buffer_put(vb);
>>> +   dma_fence_put(vb->in_fence);
>>> +   vb->in_fence = NULL;
>>> +   }
>>> /* unmap DMABUF buffer */
>>> if (q->memory == VB2_MEMORY_DMABUF)
>>> for (i = 0; i < vb->num_planes; ++i) {
>>> @@ -1653,7 +1805,7 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int 
>>> *pindex, void *pb,
>>> if (pindex)
>>> *pindex = vb->index;
>>>  
>>> -   /* Fill buffer information for the userspace */
>>> +   /* Fill buffer information for userspace */
>>> if (pb)
>>> call_void_bufop(q, fill_user_buffer, vb, pb);
>>>  
>>> @@ -1700,8 +1852,8 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
>>> if (WARN_ON(atomic_read(>owned_by_drv_count))) {
>>> for (i = 0; i < q->num_buffers; ++i)
>>> if (q->bufs[i]->state == VB2_BUF_STATE_ACTIVE) {
>>> -   pr_warn("driver bug: stop_streaming operation 
>>> is leaving buf %p in active state\n",
>>> -   q->bufs[i]);
>>> +   pr_warn("driver bug: stop_streaming operation 
>>> is leaving buf[%d] 0x%p in active
>>> state\n",
>>> +   q->bufs[i]->index, q->bufs[i]);
>>> vb2_buffer_done(q->bufs[i], 
>>> VB2_BUF_STATE_ERROR);
>>> }
>>
>> Shouldn't any pending fences be canceled here?
>>
> 
> No, we don't have to flush -- that's the reason of the refcount :)
> The qbuf_work won't do anything if all the buffers are returned
> by the driver (with error or done state), and if !streaming.
> 
> Also, note that's why qbuf_work checks for the queued state, and not
> for the error state.
> 
>> I feel uncomfortable with the refcounting of buffers, I'd rather that when we
>> cancel the queue all fences for buffers are removed/canceled/whatever.
>>
>> Is there any reason for refcounting if we cancel all pending fences here?
>>
>> Note that besides canceling fences you also need to cancel/flush __qbuf_work.
>>
>>
> 
> Like I said above, I'm trying to avoid cancel/flushing the workqueue.
> Currently, I believe it works fine without any flushing, provided we refcount
> the buffers.
> 
> The problem with cancelling the workqueue, is that you need to unlock the 
> queue
> lock, to avoid a deadlock. It seemed to me that having a refcount is more 
> natural.
> 
> Thoughts?
> 

I'll take another look tomorrow morning. Do you have a public git tree 
containing
this series that I can browse?

Regards,

Hans

[PATCH] media: dib0700: add code comment

[Gustavo A. R. Silva]

Add FIXME code comment:
/* FIXME: check if it is fe_adap[1] */

It is likely that it should be adap->fe_adap[1].fe in the second clause,
but this has never been verified.

Suggested-by: Mauro Carvalho Chehab 
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/usb/dvb-usb/dib0700_devices.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c 
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index c53a969..091389f 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -1745,6 +1745,7 @@ static int dib809x_tuner_attach(struct dvb_usb_adapter 
*adap)
if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
return -ENODEV;
} else {
+   /* FIXME: check if it is fe_adap[1] */
if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
return -ENODEV;
}
-- 
2.7.4

[PATCH] media: video-mux: fix compliance failures

[Philipp Zabel]

Limit frame sizes to the [1, UINT_MAX-1] interval, media bus formats to
the available list of formats, and initialize pad and try formats.

Reported-by: Rui Miguel Silva 
Signed-off-by: Philipp Zabel 
---
 drivers/media/platform/video-mux.c | 110 +
 1 file changed, 110 insertions(+)

diff --git a/drivers/media/platform/video-mux.c 
b/drivers/media/platform/video-mux.c
index 1fb887293337..ade1dae706aa 100644
--- a/drivers/media/platform/video-mux.c
+++ b/drivers/media/platform/video-mux.c
@@ -180,6 +180,87 @@ static int video_mux_set_format(struct v4l2_subdev *sd,
if (!source_mbusformat)
return -EINVAL;
 
+   /* No size limitations except V4L2 compliance requirements */
+   v4l_bound_align_image(>format.width, 1, UINT_MAX - 1, 0,
+ >format.height, 1, UINT_MAX - 1, 0, 0);
+
+   /* All formats except LVDS and vendor specific formats are acceptable */
+   switch (sdformat->format.code) {
+   case MEDIA_BUS_FMT_RGB444_1X12:
+   case MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE:
+   case MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE:
+   case MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE:
+   case MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE:
+   case MEDIA_BUS_FMT_RGB565_1X16:
+   case MEDIA_BUS_FMT_BGR565_2X8_BE:
+   case MEDIA_BUS_FMT_BGR565_2X8_LE:
+   case MEDIA_BUS_FMT_RGB565_2X8_BE:
+   case MEDIA_BUS_FMT_RGB565_2X8_LE:
+   case MEDIA_BUS_FMT_RGB666_1X18:
+   case MEDIA_BUS_FMT_RBG888_1X24:
+   case MEDIA_BUS_FMT_RGB666_1X24_CPADHI:
+   case MEDIA_BUS_FMT_BGR888_1X24:
+   case MEDIA_BUS_FMT_GBR888_1X24:
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   case MEDIA_BUS_FMT_RGB888_2X12_BE:
+   case MEDIA_BUS_FMT_RGB888_2X12_LE:
+   case MEDIA_BUS_FMT_ARGB_1X32:
+   case MEDIA_BUS_FMT_RGB888_1X32_PADHI:
+   case MEDIA_BUS_FMT_RGB101010_1X30:
+   case MEDIA_BUS_FMT_RGB121212_1X36:
+   case MEDIA_BUS_FMT_RGB161616_1X48:
+   case MEDIA_BUS_FMT_Y8_1X8:
+   case MEDIA_BUS_FMT_UV8_1X8:
+   case MEDIA_BUS_FMT_UYVY8_1_5X8:
+   case MEDIA_BUS_FMT_VYUY8_1_5X8:
+   case MEDIA_BUS_FMT_YUYV8_1_5X8:
+   case MEDIA_BUS_FMT_YVYU8_1_5X8:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_VYUY8_2X8:
+   case MEDIA_BUS_FMT_YUYV8_2X8:
+   case MEDIA_BUS_FMT_YVYU8_2X8:
+   case MEDIA_BUS_FMT_Y10_1X10:
+   case MEDIA_BUS_FMT_UYVY10_2X10:
+   case MEDIA_BUS_FMT_VYUY10_2X10:
+   case MEDIA_BUS_FMT_YUYV10_2X10:
+   case MEDIA_BUS_FMT_YVYU10_2X10:
+   case MEDIA_BUS_FMT_Y12_1X12:
+   case MEDIA_BUS_FMT_UYVY12_2X12:
+   case MEDIA_BUS_FMT_VYUY12_2X12:
+   case MEDIA_BUS_FMT_YUYV12_2X12:
+   case MEDIA_BUS_FMT_YVYU12_2X12:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
+   case MEDIA_BUS_FMT_VYUY8_1X16:
+   case MEDIA_BUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_YVYU8_1X16:
+   case MEDIA_BUS_FMT_YDYUYDYV8_1X16:
+   case MEDIA_BUS_FMT_UYVY10_1X20:
+   case MEDIA_BUS_FMT_VYUY10_1X20:
+   case MEDIA_BUS_FMT_YUYV10_1X20:
+   case MEDIA_BUS_FMT_YVYU10_1X20:
+   case MEDIA_BUS_FMT_VUY8_1X24:
+   case MEDIA_BUS_FMT_YUV8_1X24:
+   case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
+   case MEDIA_BUS_FMT_UYVY12_1X24:
+   case MEDIA_BUS_FMT_VYUY12_1X24:
+   case MEDIA_BUS_FMT_YUYV12_1X24:
+   case MEDIA_BUS_FMT_YVYU12_1X24:
+   case MEDIA_BUS_FMT_YUV10_1X30:
+   case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
+   case MEDIA_BUS_FMT_AYUV8_1X32:
+   case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
+   case MEDIA_BUS_FMT_YUV12_1X36:
+   case MEDIA_BUS_FMT_YUV16_1X48:
+   case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
+   case MEDIA_BUS_FMT_JPEG_1X8:
+   case MEDIA_BUS_FMT_AHSV_1X32:
+   break;
+   default:
+   sdformat->format.code = MEDIA_BUS_FMT_Y8_1X8;
+   }
+   if (sdformat->format.field == V4L2_FIELD_ANY)
+   sdformat->format.field = V4L2_FIELD_NONE;
+
mutex_lock(>lock);
 
/* Source pad mirrors active sink pad, no limitations on sink pads */
@@ -197,11 +278,33 @@ static int video_mux_set_format(struct v4l2_subdev *sd,
return 0;
 }
 
+static int video_mux_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+   struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+   struct v4l2_mbus_framefmt *mbusformat;
+   int i;
+
+   mutex_lock(>lock);
+
+   for (i = 0; i < sd->entity.num_pads; i++) {
+   mbusformat = v4l2_subdev_get_try_format(sd, fh->pad, i);
+   *mbusformat = vmux->format_mbus[i];
+   }
+
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
 static const struct v4l2_subdev_pad_ops video_mux_pad_ops = {
.get_fmt = video_mux_get_format,
.set_fmt = video_mux_set_format,
 };
 
+static const struct v4l2_subdev_internal_ops video_mux_internal_ops = {
+   .open = video_mux_open,
+};
+
 static 

Re: [PATCH v10 12/16] vb2: add in-fence support to QBUF

[Ezequiel Garcia]

On Tue, 2018-05-22 at 14:37 +0200, Hans Verkuil wrote:
> On 21/05/18 18:59, Ezequiel Garcia wrote:
> > From: Gustavo Padovan 
> > 
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers can't be queued to the
> > driver before its fences signal. And a buffer can't be queued to the driver
> > out of the order they were queued from userspace. That means that even if
> > its fence signals it must wait for all other buffers, ahead of it in the 
> > queue,
> > to signal first.
> > 
> > If the fence for some buffer fails we do not queue it to the driver,
> > instead we mark it as error and wait until the previous buffer is done
> > to notify userspace of the error. We wait here to deliver the buffers back
> > to userspace in order.
> > 
> > v13: - cleanup implementation.
> >  - remove wrong Kconfig changes.
> >  - print noisy warning on unexpected enqueue conditioin
> >  - schedule a vb2_start_streaming work from the fence callback
> > 
> > v12: fixed dvb_vb2.c usage of vb2_core_qbuf.
> > 
> > v11: - minor doc/comments fixes (Hans Verkuil)
> >  - reviewed the in-fence path at __fill_v4l2_buffer()
> > 
> > v10: - rename fence to in_fence in many places
> >  - handle fences signalling with error better (Hans Verkuil)
> > 
> > v9: - improve comments and docs (Hans Verkuil)
> > - fix unlocking of vb->fence_cb_lock on vb2_core_qbuf (Hans Verkuil)
> > - move in-fences code that was in the out-fences patch here (Alex)
> > 
> > v8: - improve comments about fences with errors
> > 
> > v7: - get rid of the fence array stuff for ordering and just use
> >   get_num_buffers_ready() (Hans)
> > - fix issue of queuing the buffer twice (Hans)
> > - avoid the dma_fence_wait() in core_qbuf() (Alex)
> > - merge preparation commit in
> > 
> > v6: - With fences always keep the order userspace queues the buffers.
> > - Protect in_fence manipulation with a lock (Brian Starkey)
> > - check if fences have the same context before adding a fence array
> > - Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
> > - Clean up fence if __set_in_fence() fails (Brian Starkey)
> > - treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
> > 
> > v5: - use fence_array to keep buffers ordered in vb2 core when
> >   needed (Brian Starkey)
> > - keep backward compat on the reserved2 field (Brian Starkey)
> > - protect fence callback removal with lock (Brian Starkey)
> > 
> > v4: - Add a comment about dma_fence_add_callback() not returning a
> >   error (Hans)
> > - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
> > - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
> > - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
> > - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
> > - Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
> >   vb2_start_streaming() (Hans)
> > - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
> > - Queue buffers to the driver as soon as they are ready (Hans)
> > - call fill_user_buffer() after queuing the buffer (Hans)
> > - add err: label to clean up fence
> > - add dma_fence_wait() before calling vb2_start_streaming()
> > 
> > v3: - document fence parameter
> > - remove ternary if at vb2_qbuf() return (Mauro)
> > - do not change if conditions behaviour (Mauro)
> > 
> > v2: - fix vb2_queue_or_prepare_buf() ret check
> > - remove check for VB2_MEMORY_DMABUF only (Javier)
> > - check num of ready buffers to start streaming
> > - when queueing, start from the first ready buffer
> > - handle queue cancel
> > 
> > Signed-off-by: Gustavo Padovan 
> > Signed-off-by: Ezequiel Garcia 
> > ---
> >  drivers/media/common/videobuf2/Kconfig  |   1 +
> >  drivers/media/common/videobuf2/videobuf2-core.c | 224 
> > 
> >  drivers/media/common/videobuf2/videobuf2-v4l2.c |  37 +++-
> >  drivers/media/dvb-core/dvb_vb2.c|   2 +-
> >  include/media/videobuf2-core.h  |  19 +-
> >  5 files changed, 242 insertions(+), 41 deletions(-)
> > 
> > diff --git a/drivers/media/common/videobuf2/Kconfig 
> > b/drivers/media/common/videobuf2/Kconfig
> > index 17c32ea58395..27ad9e8a268b 100644
> > --- a/drivers/media/common/videobuf2/Kconfig
> > +++ b/drivers/media/common/videobuf2/Kconfig
> > @@ -1,6 +1,7 @@
> >  # Used by drivers that need Videobuf2 modules
> >  config VIDEOBUF2_CORE
> > select DMA_SHARED_BUFFER
> > +   select SYNC_FILE
> > tristate
> >  
> >  config VIDEOBUF2_V4L2
> > diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> > b/drivers/media/common/videobuf2/videobuf2-core.c
> > index a9a0a9d1decb..86b5ebe25263 100644
> > --- a/drivers/media/common/videobuf2/videobuf2-core.c
> > +++ 

[PATCH] media: dvb-bt8xx: remove duplicate code

[Gustavo A. R. Silva]

The same code is executed regardless of whether c->frequency < 6
or c->frequency < 73000 is true.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/pci/bt8xx/dvb-bt8xx.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/media/pci/bt8xx/dvb-bt8xx.c 
b/drivers/media/pci/bt8xx/dvb-bt8xx.c
index 5ef6e20..6b2a9e6 100644
--- a/drivers/media/pci/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/pci/bt8xx/dvb-bt8xx.c
@@ -386,10 +386,6 @@ static int 
advbt771_samsung_tdtc9251dh0_tuner_calc_regs(struct dvb_frontend *fe,
bs = 0x02;
else if (c->frequency < 47000)
bs = 0x02;
-   else if (c->frequency < 6)
-   bs = 0x08;
-   else if (c->frequency < 73000)
-   bs = 0x08;
else
bs = 0x08;
 
-- 
2.7.4

Re: [PATCH v6 07/13] media: dt-bindings: add bindings for i.MX7 media driver

[Rob Herring]

On Tue, May 22, 2018 at 03:52:39PM +0100, Rui Miguel Silva wrote:
> Add bindings documentation for i.MX7 media drivers.
> The imx7 MIPI CSI2 and imx7 CMOS Sensor Interface.
> 
> Signed-off-by: Rui Miguel Silva 
> ---
>  .../devicetree/bindings/media/imx7-csi.txt| 44 ++
>  .../bindings/media/imx7-mipi-csi2.txt | 82 +++
>  2 files changed, 126 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/imx7-csi.txt
>  create mode 100644 Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt

Reviewed-by: Rob Herring 

Re: [PATCH v10 11/16] vb2: add explicit fence user API

[Ezequiel Garcia]

On Tue, 2018-05-22 at 14:05 +0200, Hans Verkuil wrote:
> On 21/05/18 18:59, Ezequiel Garcia wrote:
> > From: Gustavo Padovan 
> > 
> > Turn the reserved2 field into fence_fd that we will use to send
> > an in-fence to the kernel or return an out-fence from the kernel to
> > userspace.
> > 
> > Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
> > when sending an in-fence to the kernel to be waited on, and
> > V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
> > 
> > v8: return -1 if new flags are set.
> > v7: minor fixes on the Documentation (Hans Verkuil)
> > 
> > v6: big improvement on doc (Hans Verkuil)
> > 
> > v5: - keep using reserved2 field for cpia2
> > - set fence_fd to 0 for now, for compat with userspace(Mauro)
> > 
> > v4: make it a union with reserved2 and fence_fd (Hans Verkuil)
> > 
> > v3: make the out_fence refer to the current buffer (Hans Verkuil)
> > 
> > v2: add documentation
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  Documentation/media/uapi/v4l/buffer.rst | 48 
> > ++---
> >  drivers/media/common/videobuf2/videobuf2-v4l2.c |  6 +++-
> >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c   |  4 +--
> >  include/uapi/linux/videodev2.h  |  8 -
> >  4 files changed, 58 insertions(+), 8 deletions(-)
> > 
> > diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> > b/Documentation/media/uapi/v4l/buffer.rst
> > index e2c85ddc990b..971b7453040c 100644
> > --- a/Documentation/media/uapi/v4l/buffer.rst
> > +++ b/Documentation/media/uapi/v4l/buffer.rst
> > @@ -300,11 +300,23 @@ struct v4l2_buffer
> > multi-planar API the application sets this to the number of
> > elements in the ``planes`` array. The driver will fill in the
> > actual number of valid elements in that array.
> > -* - __u32
> > -  - ``reserved2``
> > +* - __s32
> > +  - ``fence_fd``
> >-
> > -  - A place holder for future extensions. Drivers and applications
> > -   must set this to 0.
> > +  - Used to communicate a fence file descriptor from userspace to 
> > kernel
> > +   and vice-versa. On :ref:`VIDIOC_QBUF ` when sending
> > +   an in-fence for V4L2 to wait on, the ``V4L2_BUF_FLAG_IN_FENCE`` flag 
> > must
> > +   be used and this field set to the fence file descriptor of the in-fence.
> > +   If the in-fence is not valid ` VIDIOC_QBUF`` returns an error.
> > +
> > +To get an out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE``
> > +   must be set, the kernel will return the out-fence file descriptor in
> > +   this field. If it fails to create the out-fence ``VIDIOC_QBUF` returns
> > +an error.
> > +
> > +   For all other ioctls V4L2 sets this field to -1 if
> > +   ``V4L2_BUF_FLAG_IN_FENCE`` and/or ``V4L2_BUF_FLAG_OUT_FENCE`` are set,
> > +   otherwise this field is set to 0 for backward compatibility.
> >  * - __u32
> >- ``reserved``
> >-
> > @@ -648,6 +660,34 @@ Buffer Flags
> >- Start Of Exposure. The buffer timestamp has been taken when the
> > exposure of the frame has begun. This is only valid for the
> > ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
> > +* .. _`V4L2-BUF-FLAG-IN-FENCE`:
> > +
> > +  - ``V4L2_BUF_FLAG_IN_FENCE``
> > +  - 0x0020
> > +  - Ask V4L2 to wait on the fence passed in the ``fence_fd`` field. The
> > +   buffer won't be queued to the driver until the fence signals. The order
> > +   in which buffers are queued is guaranteed to be preserved, so any
> > +   buffers queued after this buffer will also be blocked until this fence
> > +   signals. This flag must be set before calling ``VIDIOC_QBUF``. For
> > +   other ioctls the driver just reports the value of the flag.
> > +
> > +If the fence signals the flag is cleared and not reported anymore.
> > +   If the fence is not valid ``VIDIOC_QBUF`` returns an error.
> > +* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
> > +
> > +  - ``V4L2_BUF_FLAG_OUT_FENCE``
> > +  - 0x0040
> > +  - Request for a fence to be attached to the buffer. The driver will 
> > fill
> > +   in the out-fence fd in the ``fence_fd`` field when :ref:`VIDIOC_QBUF
> > +   ` returns. This flag must be set before calling
> > +   ``VIDIOC_QBUF``. This flag is only an input, and is not set by the 
> > kernel.
> > +
> > +If the creation of the out-fence fails ``VIDIOC_QBUF`` returns an
> > +   error.
> > +
> > +Note that it is valid to set both ``V4L2_BUF_FLAG_IN_FENCE`` and
> > +`V4L2_BUF_FLAG_OUT_FENCE`` flags. In such case, the ``fence_fd``
> > +field is used to both set the in-fence and return the out-fence.
> >  
> >  
> >  
> > diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
> > b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > index 64503615d00b..8312f61adfa6 100644
> > --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > +++ 

Re: [PATCH 4/4] media: venus: add PIL support

[Stanimir Varbanov]

Hi,

On 05/22/2018 04:02 PM, Stanimir Varbanov wrote:
> Hi Vikash,
> 
> On 05/17/2018 02:32 PM, Vikash Garodia wrote:
>> This adds support to load the video firmware
>> and bring ARM9 out of reset. This is useful
>> for platforms which does not have trustzone
>> to reset the ARM9.
>>
>> Signed-off-by: Vikash Garodia 
>> ---
>>  .../devicetree/bindings/media/qcom,venus.txt   |   8 +-
>>  drivers/media/platform/qcom/venus/core.c   |  67 +++--
>>  drivers/media/platform/qcom/venus/core.h   |   6 +
>>  drivers/media/platform/qcom/venus/firmware.c   | 163 
>> +
>>  drivers/media/platform/qcom/venus/firmware.h   |  10 +-
>>  5 files changed, 217 insertions(+), 37 deletions(-)
>>



>>  
>> -int venus_shutdown(struct device *dev)
>> +int venus_boot_noTZ(struct venus_core *core, phys_addr_t mem_phys,
>> +size_t mem_size)
>>  {
>> -return qcom_scm_pas_shutdown(VENUS_PAS_ID);
>> +struct iommu_domain *iommu;
>> +struct device *dev;
>> +int ret;
>> +
>> +if (!core->fw.dev)
>> +return -EPROBE_DEFER;
>> +
>> +dev = core->fw.dev;
>> +
>> +iommu = iommu_domain_alloc(_bus_type);
>> +if (!iommu) {
>> +dev_err(dev, "Failed to allocate iommu domain\n");
>> +return -ENOMEM;
>> +}
>> +
>> +iommu->geometry.aperture_start = 0x0;
>> +iommu->geometry.aperture_end = VENUS_FW_MEM_SIZE;
> 
> The same comment for geometry params as for venus_probe is valid here.

Infact aperture_end will be overwritten by arm-smmu driver in the next
call to iommu_attach_device(), and by chance geometry.force_aperture
will become true.

I wonder is that geometry params are supposed to be used by drivers or
by iommu drivers?

> 
>> +
>> +ret = iommu_attach_device(iommu, dev);
>> +if (ret) {
>> +dev_err(dev, "could not attach device\n");
>> +goto err_attach;
>> +}
>> +
>> +ret = iommu_map(iommu, core->fw.iova, mem_phys, mem_size,
>> +IOMMU_READ|IOMMU_WRITE|IOMMU_PRIV);
> 
> iova is not initialized and is zero, maybe we don't need that variable
> in the venus_firmware structure?
> 
>> +if (ret) {
>> +dev_err(dev, "could not map video firmware region\n");
>> +goto err_map;
>> +}
>> +core->fw.iommu_domain = iommu;
>> +venus_reset_hw(core);
>> +
>> +return 0;
>> +
>> +err_map:
>> +iommu_detach_device(iommu, dev);
>> +err_attach:
>> +iommu_domain_free(iommu);
>> +return ret;
>>  }
>> +



-- 
regards,
Stan

Re: [PATCH v2 3/4] media: rcar-vin: Handle CLOCKENB pin polarity

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch.

On 2018-05-21 19:27:42 +0200, Jacopo Mondi wrote:
> Handle CLOCKENB pin polarity, or use HSYNC in its place if polarity is
> not specified and we're running on parallel data bus with explicit
> synchronism signals.
> 
> While at there, simplify the media bus handling flags logic, inspecting
> flags only if the system is running on parallel media bus type and ignore
> flags when on CSI-2. Also change comments style to remove un-necessary
> camel case and add a full stop at the end of sentences.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 34 
> ++
>  1 file changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 17f291f..ffd3d62 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -123,6 +123,8 @@
>  /* Video n Data Mode Register 2 bits */
>  #define VNDMR2_VPS   (1 << 30)
>  #define VNDMR2_HPS   (1 << 29)
> +#define VNDMR2_CES   (1 << 28)
> +#define VNDMR2_CHS   (1 << 23)
>  #define VNDMR2_FTEV  (1 << 17)
>  #define VNDMR2_VLV(n)((n & 0xf) << 12)
>  
> @@ -684,21 +686,35 @@ static int rvin_setup(struct rvin_dev *vin)
>   break;
>   }
>  
> - /* Enable VSYNC Field Toogle mode after one VSYNC input */
> + /* Enable VSYNC field toggle mode after one VSYNC input. */
>   if (vin->info->model == RCAR_GEN3)
>   dmr2 = VNDMR2_FTEV;
>   else
>   dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
>  
> - /* Hsync Signal Polarity Select */
> - if (!vin->is_csi &&
> - !(vin->parallel->mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
> - dmr2 |= VNDMR2_HPS;
> + /* Synchronism signal polarities: only for parallel data bus. */
> + if (!vin->is_csi) {
> + /* Hsync signal polarity select. */
> + if (!(vin->parallel->mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
> + dmr2 |= VNDMR2_HPS;
>  
> - /* Vsync Signal Polarity Select */
> - if (!vin->is_csi &&
> - !(vin->parallel->mbus_flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
> - dmr2 |= VNDMR2_VPS;
> + /* Vsync signal polarity select. */
> + if (!(vin->parallel->mbus_flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
> + dmr2 |= VNDMR2_VPS;
> +
> + /*
> +  * Data enable signal polarity select.
> +  * Use HSYNC as data-enable if not specified and running
> +  * with explicit synchronizations; otherwise default 'high'
> +  * is selected.
> +  */
> + if (vin->parallel->mbus_flags & V4L2_MBUS_DATA_ACTIVE_LOW)
> + dmr2 |= VNDMR2_CES;
> + else if (!(vin->parallel->mbus_flags &
> +  V4L2_MBUS_DATA_ACTIVE_HIGH) &&
> +  vin->parallel->mbus_type == V4L2_MBUS_PARALLEL)
> + dmr2 |= VNDMR2_CHS;

As I stated in v1, I think this expression is more complex then is relly
needed here. Would not something like this be much more readable?

/* Clock Enable signal polarity select. */
if (vin->parallel->mbus_flags & V4L2_MBUS_DATA_ACTIVE_LOW)
dmr2 |= VNDMR2_CES;

/* Use HSYNC as clock enable if VIn_CLKENB is not available. */
if (!(vin->parallel->mbus_flags & (V4L2_MBUS_DATA_ACTIVE_LOW | 
V4L2_MBUS_DATA_ACTIVE_HIGH)))
dmr2 |= VNDMR2_CHS;


> + }
>  
>   /*
>* Output format
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH v2 2/4] dt-bindings: media: rcar-vin: Document data-active

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch.

On 2018-05-21 19:27:41 +0200, Jacopo Mondi wrote:
> Document 'data-active' property in R-Car VIN device tree bindings.
> 
> Signed-off-by: Jacopo Mondi 
> 
> v1 -> v2:
> - HSYNC is used in place of data enable signal only when running with
>   explicit synchronizations.
> - The property is no more mandatory when running with embedded
>   synchronizations, and default is selected.
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index dab3118..2c144b4 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -64,6 +64,12 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>   If both HSYNC and VSYNC polarities are not specified, embedded
>   synchronization is selected.
>  
> +- data-active: data enable signal line polarity (CLKENB pin).
> +  0/1 for LOW/HIGH respectively. If not specified and running with
> +   embedded synchronization, the default is active high. If not
> +   specified and running with explicit synchronization, HSYNC is used
> +   as data enable signal.

This indentation looks funny :-)

If you check the rest of the rcar_vin.txt file only spaces are used for
indentation.

> +
>  - port 1 - sub-nodes describing one or more endpoints connected to
>the VIN from local SoC CSI-2 receivers. The endpoint numbers must
>use the following schema.
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH v2 1/4] dt-bindings: media: rcar-vin: Describe optional ep properties

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch.

On 2018-05-21 19:27:40 +0200, Jacopo Mondi wrote:
> Describe the optional properties for endpoint nodes of port@0
> and port@1 of the R-Car VIN driver device tree bindings documentation.
> 
> Signed-off-by: Jacopo Mondi 
> Acked-by: Niklas Söderlund 
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 5c6f2a7..dab3118 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -54,6 +54,16 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>from external SoC pins described in video-interfaces.txt[1].
>Describing more then one endpoint in port 0 is invalid. Only VIN
>instances that are connected to external pins should have port 0.
> +
> +  - Optional properties for endpoint nodes of port@0:
> +- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
> +   respectively. Default is active high.
> +- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
> +   respectively. Default is active high.
> +
> + If both HSYNC and VSYNC polarities are not specified, embedded
> + synchronization is selected.
> +
>  - port 1 - sub-nodes describing one or more endpoints connected to
>the VIN from local SoC CSI-2 receivers. The endpoint numbers must
>use the following schema.
> @@ -63,6 +73,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>  - Endpoint 2 - sub-node describing the endpoint connected to CSI40
>  - Endpoint 3 - sub-node describing the endpoint connected to CSI41
>  
> +  Endpoint nodes of port@1 do not support any optional endpoint property.
> +
>  Device node example for Gen2 platforms
>  --
>  
> @@ -113,7 +125,6 @@ Board setup example for Gen2 platforms (vin1 composite 
> video input)
>  
>  vin1ep0: endpoint {
>  remote-endpoint = <>;
> -bus-width = <8>;

Until we have figured out if we should document or remove the bus-width 
parameter maybe move this to 4/4 ?


>  };
>  };
>  };
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

[Oleksandr Andrushchenko]

On 05/22/2018 05:33 PM, Boris Ostrovsky wrote:

On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:

On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:

On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote:

On 05/21/2018 09:53 PM, Boris Ostrovsky wrote:

On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote:

On 05/21/2018 07:35 PM, Boris Ostrovsky wrote:

On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote:

On 05/19/2018 01:04 AM, Boris Ostrovsky wrote:

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

A commit message would be useful.

Sure, v1 will have it

Signed-off-by: Oleksandr Andrushchenko


  for (i = 0; i < nr_pages; i++) {
-    page = alloc_page(gfp);
-    if (page == NULL) {
-    nr_pages = i;
-    state = BP_EAGAIN;
-    break;
+    if (ext_pages) {
+    page = ext_pages[i];
+    } else {
+    page = alloc_page(gfp);
+    if (page == NULL) {
+    nr_pages = i;
+    state = BP_EAGAIN;
+    break;
+    }
  }
  scrub_page(page);
  list_add(>lru, );
@@ -529,7 +565,7 @@ static enum bp_state
decrease_reservation(unsigned long nr_pages, gfp_t gfp)
  i = 0;
  list_for_each_entry_safe(page, tmp, , lru) {
  /* XENMEM_decrease_reservation requires a GFN */
-    frame_list[i++] = xen_page_to_gfn(page);
+    frames[i++] = xen_page_to_gfn(page);
    #ifdef CONFIG_XEN_HAVE_PVMMU
  /*
@@ -552,18 +588,22 @@ static enum bp_state
decrease_reservation(unsigned long nr_pages, gfp_t gfp)
  #endif
  list_del(>lru);
  -    balloon_append(page);
+    if (!ext_pages)
+    balloon_append(page);

So what you are proposing is not really ballooning. You are just
piggybacking on existing interfaces, aren't you?

Sort of. Basically I need to {increase|decrease}_reservation, not
actually
allocating ballooned pages.
Do you think I can simply EXPORT_SYMBOL for
{increase|decrease}_reservation?
Any other suggestion?

I am actually wondering how much of that code you end up reusing.
You
pretty much create new code paths in both routines and common code
ends
up being essentially the hypercall.

Well, I hoped that it would be easier to maintain if I modify
existing
code
to support both use-cases, but I am also ok to create new routines if
this
seems to be reasonable - please let me know

     So the question is --- would it make
sense to do all of this separately from the balloon driver?

This can be done, but which driver will host this code then? If we
move from
the balloon driver, then this could go to either gntdev or
grant-table.
What's your preference?

A separate module?
Is there any use for this feature outside of your zero-copy DRM
driver?

Intel's hyper dma-buf (Dongwon/Matt CC'ed), V4L/GPU at least.

At the time I tried to upstream zcopy driver it was discussed and
decided that
it would be better if I remove all DRM specific code and move it to
Xen drivers.
Thus, this RFC.

But it can also be implemented as a dedicated Xen dma-buf driver which
will have all the
code from this RFC + a bit more (char/misc device handling at least).
This will also require a dedicated user-space library, just like
libxengnttab.so
for gntdev (now I have all new IOCTLs covered there).

If the idea of a dedicated Xen dma-buf driver seems to be more
attractive we
can work toward this solution. BTW, I do support this idea, but was not
sure if Xen community accepts yet another driver which duplicates
quite some code
of the existing gntdev/balloon/grant-table. And now after this RFC I
hope that all cons
and pros of both dedicated driver and gntdev/balloon/grant-table
extension are
clearly seen and we can make a decision.

IIRC the objection for a separate module was in the context of gntdev
was discussion, because (among other things) people didn't want to have
yet another file in /dev/xen/

Here we are talking about (a new) balloon-like module which doesn't
create any new user-visible interfaces. And as for duplicating code ---
as I said, I am not convinced there is much of duplication.

I might even argue that we should add a new config option for this
module.

I am not quite sure I am fully following you here: so, you suggest
that we have balloon.c unchanged, but instead create a new
module (namely a file under the same folder as balloon.c, e.g.
dma-buf-reservation.c) and move those {increase|decrease}_reservation
routines (specific to dma-buf) to that new file? And make it selectable
via Kconfig? If so, then how about the changes to grant-table and gntdev?
Those will look inconsistent then.

Inconsistent with what? The changes to grant code will also be under the
new config option.

Ah, ok.

Option 1. We will have Kconfig option which will cover dma-buf
changes in balloon, grant-table and gntdev. 

[PATCH v6 09/13] ARM: dts: imx7s: add multiplexer controls

[Rui Miguel Silva]

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

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

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

[PATCH v6 11/13] ARM: dts: imx7s-warp: add ov2680 sensor node

[Rui Miguel Silva]

Warp7 comes with a Omnivision OV2680 sensor, add the node here to make complete
the camera data path for this system. Add the needed regulator to the analog
voltage supply, the port and endpoints in mipi_csi node and the pinctrl for the
reset gpio.

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

diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index cb175ee2fc9d..bf04e13afd02 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -91,6 +91,14 @@
regulator-always-on;
};
 
+   reg_peri_3p15v: regulator-peri-3p15v {
+   compatible = "regulator-fixed";
+   regulator-name = "peri_3p15v_reg";
+   regulator-min-microvolt = <315>;
+   regulator-max-microvolt = <315>;
+   regulator-always-on;
+   };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,name = "imx7-sgtl5000";
@@ -218,6 +226,27 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c2>;
status = "okay";
+
+   ov2680: camera@36 {
+   compatible = "ovti,ov2680";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ov2680>;
+   reg = <0x36>;
+   clocks = <>;
+   clock-names = "xvclk";
+   reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+   DOVDD-supply = <_reg>;
+   DVDD-supply = <_reg>;
+   AVDD-supply = <_peri_3p15v>;
+
+   port {
+   ov2680_to_mipi: endpoint {
+   remote-endpoint = <_from_sensor>;
+   clock-lanes = <0>;
+   data-lanes = <1>;
+   };
+   };
+   };
 };
 
  {
@@ -352,6 +381,15 @@
#size-cells = <0>;
fsl,csis-hs-settle = <3>;
 
+   port@0 {
+   reg = <0>;
+
+   mipi_from_sensor: endpoint {
+   remote-endpoint = <_to_mipi>;
+   data-lanes = <1>;
+   };
+   };
+
port@1 {
reg = <1>;
 
@@ -408,6 +446,12 @@
>;
};
 
+   pinctrl_ov2680: ov2660grp {
+   fsl,pins = <
+   MX7D_PAD_LPSR_GPIO1_IO03__GPIO1_IO3 0x14
+   >;
+   };
+
pinctrl_sai1: sai1grp {
fsl,pins = <
MX7D_PAD_SAI1_RX_DATA__SAI1_RX_DATA00x1f
-- 
2.17.0

[PATCH v6 12/13] media: imx7.rst: add documentation for i.MX7 media driver

[Rui Miguel Silva]

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

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

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

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

[Rui Miguel Silva]

Add some i.MX7 related entries to TODO file.

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

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

[PATCH v6 10/13] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections

[Rui Miguel Silva]

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

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

diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index 8a30b148534d..cb175ee2fc9d 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -310,6 +310,57 @@
status = "okay";
 };
 
+ {
+   csi_mux {
+   compatible = "video-mux";
+   mux-controls = < 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   csi_mux_from_mipi_vc0: endpoint {
+   remote-endpoint = <_vc0_to_csi_mux>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   csi_mux_to_csi: endpoint {
+   remote-endpoint = <_from_csi_mux>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   port {
+   csi_from_csi_mux: endpoint {
+   remote-endpoint = <_mux_to_csi>;
+   };
+   };
+};
+
+_csi {
+   clock-frequency = <16600>;
+   status = "okay";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   fsl,csis-hs-settle = <3>;
+
+   port@1 {
+   reg = <1>;
+
+   mipi_vc0_to_csi_mux: endpoint {
+   remote-endpoint = <_mux_from_mipi_vc0>;
+   };
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_wdog>;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 0b0b85438869..4fce2f46c766 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "imx7d-pinfunc.h"
 
 / {
@@ -738,6 +739,17 @@
status = "disabled";
};
 
+   csi: csi@3071 {
+   compatible = "fsl,imx7-csi";
+   reg = <0x3071 0x1>;
+   interrupts = ;
+   clocks = < IMX7D_CLK_DUMMY>,
+   < IMX7D_CSI_MCLK_ROOT_CLK>,
+   < IMX7D_CLK_DUMMY>;
+   clock-names = "axi", "mclk", "dcic";
+   status = "disabled";
+   };
+
lcdif: lcdif@3073 {
compatible = "fsl,imx7d-lcdif", 
"fsl,imx28-lcdif";
reg = <0x3073 0x1>;
@@ -747,6 +759,21 @@
clock-names = "pix", "axi";
status = "disabled";
};
+
+   mipi_csi: mipi-csi@3075 {
+   compatible = "fsl,imx7-mipi-csi2";
+   reg = <0x3075 0x1>;
+   interrupts = ;
+   clocks = < IMX7D_IPG_ROOT_CLK>,
+   < IMX7D_MIPI_CSI_ROOT_CLK>,
+   < 
IMX7D_MIPI_DPHY_ROOT_CLK>;
+   clock-names = "pclk", "wrap", "phy";
+   power-domains = <_mipi_phy>;
+   phy-supply = <_1p0d>;
+   resets = < IMX7_RESET_MIPI_PHY_MRST>;
+   reset-names = "mrst";
+   status = "disabled";
+   };
};
 
aips3: aips-bus@3080 {
-- 
2.17.0

[PATCH v6 07/13] media: dt-bindings: add bindings for i.MX7 media driver

[Rui Miguel Silva]

Add bindings documentation for i.MX7 media drivers.
The imx7 MIPI CSI2 and imx7 CMOS Sensor Interface.

Signed-off-by: Rui Miguel Silva 
---
 .../devicetree/bindings/media/imx7-csi.txt| 44 ++
 .../bindings/media/imx7-mipi-csi2.txt | 82 +++
 2 files changed, 126 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/imx7-csi.txt
 create mode 100644 Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt

diff --git a/Documentation/devicetree/bindings/media/imx7-csi.txt 
b/Documentation/devicetree/bindings/media/imx7-csi.txt
new file mode 100644
index ..aab4f5d72390
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx7-csi.txt
@@ -0,0 +1,44 @@
+Freescale i.MX7 CMOS Sensor Interface
+=
+
+csi node
+
+
+This is device node for the CMOS Sensor Interface (CSI) which enables the chip
+to connect directly to external CMOS image sensors.
+
+Required properties:
+
+- compatible: "fsl,imx7-csi";
+- reg   : base address and length of the register set for the device;
+- interrupts: should contain CSI interrupt;
+- clocks: list of clock specifiers, see
+Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
+- clock-names   : must contain "axi", "mclk" and "dcic" entries, matching
+ entries in the clock property;
+
+The device node should contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in Documentation/devicetree/bindings/
+media/video-interfaces.txt. In the following example a remote endpoint is a
+video multiplexer.
+
+example:
+
+csi: csi@3071 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+compatible = "fsl,imx7-csi";
+reg = <0x3071 0x1>;
+interrupts = ;
+clocks = < IMX7D_CLK_DUMMY>,
+< IMX7D_CSI_MCLK_ROOT_CLK>,
+< IMX7D_CLK_DUMMY>;
+clock-names = "axi", "mclk", "dcic";
+
+port {
+csi_from_csi_mux: endpoint {
+remote-endpoint = <_mux_to_csi>;
+};
+};
+};
diff --git a/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt 
b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
new file mode 100644
index ..7c5f20863724
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
@@ -0,0 +1,82 @@
+Freescale i.MX7 Mipi CSI2
+=
+
+mipi_csi2 node
+--
+
+This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
+compatible with previous version of Samsung D-phy.
+
+Required properties:
+
+- compatible: "fsl,imx7-mipi-csi2";
+- reg   : base address and length of the register set for the device;
+- interrupts: should contain MIPI CSIS interrupt;
+- clocks: list of clock specifiers, see
+Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
+- clock-names   : must contain "pclk", "wrap" and "phy" entries, matching
+  entries in the clock property;
+- power-domains : a phandle to the power domain, see
+  Documentation/devicetree/bindings/power/power_domain.txt for details.
+- reset-names   : should include following entry "mrst";
+- resets: a list of phandle, should contain reset entry of
+  reset-names;
+- phy-supply: from the generic phy bindings, a phandle to a regulator that
+ provides power to MIPI CSIS core;
+
+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
+   value when this property is not specified is 166 MHz;
+- fsl,csis-hs-settle : differential receiver (HS-RX) settle time;
+
+port node
+-
+
+- reg: (required) can take the values 0 or 1, where 0 is the
+ related sink port and port 1 should be the source one;
+
+endpoint node
+-
+
+- data-lanes: (required) an array specifying active physical MIPI-CSI2
+   data input lanes and their mapping to logical lanes; the
+   array's content is unused, only its length is meaningful;
+
+example:
+
+mipi_csi: mipi-csi@3075 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+compatible = "fsl,imx7-mipi-csi2";
+reg = <0x3075 0x1>;
+interrupts = ;
+clocks = < IMX7D_IPG_ROOT_CLK>,
+< IMX7D_MIPI_CSI_ROOT_CLK>,
+< IMX7D_MIPI_DPHY_ROOT_CLK>;
+  

[PATCH v6 08/13] ARM: dts: imx7s: add mipi phy power domain

[Rui Miguel Silva]

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

While at it rename pcie power-domain node to remove pgc prefix.

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

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 4d42335c0dee..5e6d2063b143 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -636,7 +636,13 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   pgc_pcie_phy: pgc-power-domain@1 {
+   pgc_mipi_phy: power-domain@0 {
+   #power-domain-cells = <0>;
+   reg = <0>;
+   power-supply = <_1p0d>;
+   };
+
+   pgc_pcie_phy: power-domain@1 {
#power-domain-cells = <0>;
reg = <1>;
power-supply = <_1p0d>;
-- 
2.17.0

[PATCH v6 06/13] media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7

[Rui Miguel Silva]

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

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

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

[PATCH v6 05/13] clk: imx7d: reset parent for mipi csi root

[Rui Miguel Silva]

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

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

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

[PATCH v6 03/13] media: staging/imx7: add imx7 CSI subdev driver

[Rui Miguel Silva]

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

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

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

[PATCH v6 04/13] clk: imx7d: fix mipi dphy div parent

[Rui Miguel Silva]

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

before:
cat clk_orphan_summary
 enable  prepare  protect
   clock  countcountcountrate   
accuracy   phase

 mipi_dphy_post_div   110   0  
0 0
mipi_dphy_root_clk110   0  
0 0

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

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

Fixes: 8f6d8094b215 ("ARM: imx: add imx7d clk tree support")
Acked-by: Dong Aisheng 
Signed-off-by: Rui Miguel Silva 
---
 drivers/clk/imx/clk-imx7d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

[PATCH v6 02/13] media: staging/imx: rearrange group id to take in account IPU

[Rui Miguel Silva]

Some imx system do not have IPU, so prepare the imx media drivers to support
this kind of devices. Rename the group ids to include an _IPU_ prefix, add a new
group id to support systems with only a CSI without IPU, and also
rename the create internal links to make it clear that only systems with IPU
have internal subdevices.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/imx-ic-common.c |  6 ++---
 drivers/staging/media/imx/imx-ic-prp.c| 14 +--
 drivers/staging/media/imx/imx-media-csi.c |  6 ++---
 drivers/staging/media/imx/imx-media-dev.c | 22 ++
 .../staging/media/imx/imx-media-internal-sd.c | 20 
 drivers/staging/media/imx/imx-media-utils.c   | 12 +-
 drivers/staging/media/imx/imx-media.h | 23 ++-
 7 files changed, 54 insertions(+), 49 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-common.c 
b/drivers/staging/media/imx/imx-ic-common.c
index cfdd4900a3be..765919487a73 100644
--- a/drivers/staging/media/imx/imx-ic-common.c
+++ b/drivers/staging/media/imx/imx-ic-common.c
@@ -41,13 +41,13 @@ static int imx_ic_probe(struct platform_device *pdev)
pdata = priv->dev->platform_data;
priv->ipu_id = pdata->ipu_id;
switch (pdata->grp_id) {
-   case IMX_MEDIA_GRP_ID_IC_PRP:
+   case IMX_MEDIA_GRP_ID_IPU_IC_PRP:
priv->task_id = IC_TASK_PRP;
break;
-   case IMX_MEDIA_GRP_ID_IC_PRPENC:
+   case IMX_MEDIA_GRP_ID_IPU_IC_PRPENC:
priv->task_id = IC_TASK_ENCODER;
break;
-   case IMX_MEDIA_GRP_ID_IC_PRPVF:
+   case IMX_MEDIA_GRP_ID_IPU_IC_PRPVF:
priv->task_id = IC_TASK_VIEWFINDER;
break;
default:
diff --git a/drivers/staging/media/imx/imx-ic-prp.c 
b/drivers/staging/media/imx/imx-ic-prp.c
index 98923fc844ce..795ca61f7cea 100644
--- a/drivers/staging/media/imx/imx-ic-prp.c
+++ b/drivers/staging/media/imx/imx-ic-prp.c
@@ -77,7 +77,7 @@ static int prp_start(struct prp_priv *priv)
priv->ipu = priv->md->ipu[ic_priv->ipu_id];
 
/* set IC to receive from CSI or VDI depending on source */
-   src_is_vdic = !!(priv->src_sd->grp_id & IMX_MEDIA_GRP_ID_VDIC);
+   src_is_vdic = !!(priv->src_sd->grp_id & IMX_MEDIA_GRP_ID_IPU_VDIC);
 
ipu_set_ic_src_mux(priv->ipu, priv->csi_id, src_is_vdic);
 
@@ -238,7 +238,7 @@ static int prp_link_setup(struct media_entity *entity,
goto out;
}
if (priv->sink_sd_prpenc && (remote_sd->grp_id &
-IMX_MEDIA_GRP_ID_VDIC)) {
+
IMX_MEDIA_GRP_ID_IPU_VDIC)) {
ret = -EINVAL;
goto out;
}
@@ -259,7 +259,7 @@ static int prp_link_setup(struct media_entity *entity,
goto out;
}
if (priv->src_sd && (priv->src_sd->grp_id &
-IMX_MEDIA_GRP_ID_VDIC)) {
+IMX_MEDIA_GRP_ID_IPU_VDIC)) {
ret = -EINVAL;
goto out;
}
@@ -309,13 +309,13 @@ static int prp_link_validate(struct v4l2_subdev *sd,
return ret;
 
csi = imx_media_find_upstream_subdev(priv->md, _priv->sd.entity,
-IMX_MEDIA_GRP_ID_CSI);
+IMX_MEDIA_GRP_ID_IPU_CSI);
if (IS_ERR(csi))
csi = NULL;
 
mutex_lock(>lock);
 
-   if (priv->src_sd->grp_id & IMX_MEDIA_GRP_ID_VDIC) {
+   if (priv->src_sd->grp_id & IMX_MEDIA_GRP_ID_IPU_VDIC) {
/*
 * the ->PRPENC link cannot be enabled if the source
 * is the VDIC
@@ -334,10 +334,10 @@ static int prp_link_validate(struct v4l2_subdev *sd,
 
if (csi) {
switch (csi->grp_id) {
-   case IMX_MEDIA_GRP_ID_CSI0:
+   case IMX_MEDIA_GRP_ID_IPU_CSI0:
priv->csi_id = 0;
break;
-   case IMX_MEDIA_GRP_ID_CSI1:
+   case IMX_MEDIA_GRP_ID_IPU_CSI1:
priv->csi_id = 1;
break;
default:
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 436f3b8a141b..8a86d111e935 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -981,10 +981,10 @@ static int csi_link_setup(struct media_entity *entity,
 
remote_sd = media_entity_to_v4l2_subdev(remote->entity);
switch (remote_sd->grp_id) {
-   case 

[PATCH v6 01/13] media: staging/imx: refactor imx media device probe

[Rui Miguel Silva]

Refactor and move media device initialization code to a new common module, so it
can be used by other devices, this will allow for example a near to introduce
imx7 CSI driver, to use this media device.

Signed-off-by: Rui Miguel Silva 
---
 drivers/staging/media/imx/Makefile|   1 +
 .../staging/media/imx/imx-media-dev-common.c  | 100 ++
 drivers/staging/media/imx/imx-media-dev.c |  86 ---
 drivers/staging/media/imx/imx-media-of.c  |   6 +-
 drivers/staging/media/imx/imx-media.h |  15 +++
 5 files changed, 139 insertions(+), 69 deletions(-)
 create mode 100644 drivers/staging/media/imx/imx-media-dev-common.c

diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index 698a4210316e..a30b3033f9a3 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o
+imx-media-objs += imx-media-dev-common.o
 imx-media-common-objs := imx-media-utils.o imx-media-fim.o
 imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o
 
diff --git a/drivers/staging/media/imx/imx-media-dev-common.c 
b/drivers/staging/media/imx/imx-media-dev-common.c
new file mode 100644
index ..98aea5f94174
--- /dev/null
+++ b/drivers/staging/media/imx/imx-media-dev-common.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL
+/*
+ * V4L2 Media Controller Driver for Freescale common i.MX5/6/7 SOC
+ *
+ * Copyright (c) 2018 Linaro Ltd
+ * Copyright (c) 2016 Mentor Graphics Inc.
+ */
+
+#include 
+#include 
+#include "imx-media.h"
+
+static const struct v4l2_async_notifier_operations imx_media_subdev_ops = {
+   .bound = imx_media_subdev_bound,
+   .complete = imx_media_probe_complete,
+};
+
+static const struct media_device_ops imx_media_md_ops = {
+   .link_notify = imx_media_link_notify,
+};
+
+struct imx_media_dev *imx_media_dev_init(struct device *dev)
+{
+   struct imx_media_dev *imxmd;
+   int ret;
+
+   imxmd = devm_kzalloc(dev, sizeof(*imxmd), GFP_KERNEL);
+   if (!imxmd)
+   return ERR_PTR(-ENOMEM);
+
+   dev_set_drvdata(dev, imxmd);
+
+   strlcpy(imxmd->md.model, "imx-media", sizeof(imxmd->md.model));
+   imxmd->md.ops = _media_md_ops;
+   imxmd->md.dev = dev;
+
+   mutex_init(>mutex);
+
+   imxmd->v4l2_dev.mdev = >md;
+   strlcpy(imxmd->v4l2_dev.name, "imx-media",
+   sizeof(imxmd->v4l2_dev.name));
+
+   media_device_init(>md);
+
+   ret = v4l2_device_register(dev, >v4l2_dev);
+   if (ret < 0) {
+   v4l2_err(>v4l2_dev,
+"Failed to register v4l2_device: %d\n", ret);
+   goto cleanup;
+   }
+
+   dev_set_drvdata(imxmd->v4l2_dev.dev, imxmd);
+
+   INIT_LIST_HEAD(>vdev_list);
+
+   return imxmd;
+
+cleanup:
+   media_device_cleanup(>md);
+
+   return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(imx_media_dev_init);
+
+int imx_media_dev_notifier_register(struct imx_media_dev *imxmd)
+{
+   int ret;
+
+   /* no subdevs? just bail */
+   if (imxmd->notifier.num_subdevs == 0) {
+   v4l2_err(>v4l2_dev, "no subdevs\n");
+   return -ENODEV;
+   }
+
+   /* prepare the async subdev notifier and register it */
+   imxmd->notifier.ops = _media_subdev_ops;
+   ret = v4l2_async_notifier_register(>v4l2_dev,
+  >notifier);
+   if (ret) {
+   v4l2_err(>v4l2_dev,
+"v4l2_async_notifier_register failed with %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(imx_media_dev_notifier_register);
+
+void imx_media_dev_cleanup(struct imx_media_dev *imxmd)
+{
+   v4l2_device_unregister(>v4l2_dev);
+   media_device_cleanup(>md);
+}
+EXPORT_SYMBOL_GPL(imx_media_dev_cleanup);
+
+void imx_media_dev_notifier_unregister(struct imx_media_dev *imxmd)
+{
+   v4l2_async_notifier_cleanup(>notifier);
+}
+EXPORT_SYMBOL_GPL(imx_media_dev_notifier_unregister);
diff --git a/drivers/staging/media/imx/imx-media-dev.c 
b/drivers/staging/media/imx/imx-media-dev.c
index 7e7bd1c6c81b..70fcaf2d358a 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -107,9 +107,9 @@ static int imx_media_get_ipu(struct imx_media_dev *imxmd,
 }
 
 /* async subdev bound notifier */
-static int imx_media_subdev_bound(struct v4l2_async_notifier *notifier,
- struct v4l2_subdev *sd,
- struct v4l2_async_subdev *asd)
+int imx_media_subdev_bound(struct v4l2_async_notifier *notifier,
+  struct v4l2_subdev *sd,
+  struct v4l2_async_subdev *asd)
 {
struct imx_media_dev *imxmd = notifier2dev(notifier);
int ret = 0;
@@ -293,7 

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

[Rui Miguel Silva]

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

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

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

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

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

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

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

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

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

Cheers,
Rui

[0]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg131186.html

v5->v6:
Rob Herring:
 - rename power-domain node name from: pgc-power-domain to power-domain
 - change mux-control-cells to 0
 - remove bus-width from mipi bindings and dts
 - remove err... regarding clock names line
 - remove clk-settle from example
 - split mipi-csi2 and csi bindings per file
 - add OF graph description to CSI

Philipp Zabel:
 - rework group IDs and rename them with an _IPU_ prefix, this allowed to remove
   the ipu_present flag need.

v4->v5:
Sakari Ailus:
 - fix remove of the capture entries in dts bindings in the right patch

Stephen Boyd:
 - Send all series to clk list

v3->v4:
Philipp Zabel:
 - refactor initialization code from media device probe to be possible to used
   from other modules
 - Remove index of csi from all accurrencs (dts, code, documentation)
 - Remove need for capture node for imx7
 - fix pinctrl for ov2680
 - add reviewed tag to add multiplexer controls patch

Fabio Estevam:
 - remove always on from new regulator

Randy Dunlap:
 - several text editing fixes in documentation

Myself:
 - rebase on top of v4 of Steve series
 - change CSI probe to initialize imx media device
 - remove csi mux parallel endpoint from mux to avoid warning message

v2->v3:
Philipp Zabel:
 - use of_match_device in imx-media-dev instead of of_device_match
 - fix number of data lanes from 4 to 2
 - change the clock definitions and use of mipi
 - move hs-settle from endpoint

Rob Herring:
 - fix phy-supply description
 - add vendor properties
 - fix examples indentations

Stephen Boyd: patch 3/14
 - fix double sign-off
 - add fixes tag

Dong Aisheng: patch 3/14
 - fix double sign-off
 - add Acked-by tag

Shawn Guo:
patch 4/14
 - remove line breakage in parent redifiniton
 - added Acked-by tag

 - dropped CMA area increase and add more verbose information in case of
   dma allocation failure
patch 9/14
 - remove extra line between cells and reg masks

Myself:
 - rework on frame end in csi
 - add rxcount in csi driver
 - add power supplies to ov2680 node and fix gpio polarity

v1->v2:
Dan Carpenter:
 - fix return paths and codes;
 - fix clk_frequency validation and return code;
 - handle the csi remove (release resources that was missing)
 - revert the logic arround the ipu_present flag

Philipp Zabel:
 - drop patch that changed the rgb formats and address the pixel/bus format in
   mipi_csis code.

MySelf:
 - add patch that add ov2680 node to the warp7 dts, so the all data path is
   complete.
 - add linux-clk mailing list to the clock patches cc:

 media-ctl -p
Media controller API version 4.17.0

Media device information

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

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

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

- entity 10: csi_mux (3 pads, 2 links)
  

Re: cron job: media_tree daily build: ERRORS

[Hans Verkuil]

On 22/05/18 16:26, Jasmin J. wrote:
> Hello Hans!
> 
>> linux-4.9.91-x86_64: ERRORS
>> /home/hans/work/build/media_build/v4l/dw9807.c:321:3: error
> The build works in my tree ... ?!?
> I can't find the file in media_tree:
>find . -name "*9807*"
> 
> Can you please check if there is something wrong with your
> media_tree version which is used for the daily build.
> I have 8ed8bba70b43 as top commit.

Hmm, I wonder if Mauro rebased the tree. Anyway, I've fixed this.

> 
> And another thing:
>  ./prepare_kernel.sh 3.2 x86_64
> fails with
>  fatal error: linux/compiler-gcc8.h: No such file or directory
> this leads to a build error in the daily build also.

Copied compiler-gcc7.h to compiler-gcc8.h, so be OK now.

Regards,

Hans

> 
> BR,
>Jasmin
> 

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

[Boris Ostrovsky]

On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:
>> On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote:
>>> On 05/21/2018 09:53 PM, Boris Ostrovsky wrote:
 On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 07:35 PM, Boris Ostrovsky wrote:
>> On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote:
>>> On 05/19/2018 01:04 AM, Boris Ostrovsky wrote:
 On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
 A commit message would be useful.
>>> Sure, v1 will have it
> Signed-off-by: Oleksandr Andrushchenko
> 
>
>  for (i = 0; i < nr_pages; i++) {
> -    page = alloc_page(gfp);
> -    if (page == NULL) {
> -    nr_pages = i;
> -    state = BP_EAGAIN;
> -    break;
> +    if (ext_pages) {
> +    page = ext_pages[i];
> +    } else {
> +    page = alloc_page(gfp);
> +    if (page == NULL) {
> +    nr_pages = i;
> +    state = BP_EAGAIN;
> +    break;
> +    }
>  }
>  scrub_page(page);
>  list_add(>lru, );
> @@ -529,7 +565,7 @@ static enum bp_state
> decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  i = 0;
>  list_for_each_entry_safe(page, tmp, , lru) {
>  /* XENMEM_decrease_reservation requires a GFN */
> -    frame_list[i++] = xen_page_to_gfn(page);
> +    frames[i++] = xen_page_to_gfn(page);
>    #ifdef CONFIG_XEN_HAVE_PVMMU
>  /*
> @@ -552,18 +588,22 @@ static enum bp_state
> decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  #endif
>  list_del(>lru);
>  -    balloon_append(page);
> +    if (!ext_pages)
> +    balloon_append(page);
 So what you are proposing is not really ballooning. You are just
 piggybacking on existing interfaces, aren't you?
>>> Sort of. Basically I need to {increase|decrease}_reservation, not
>>> actually
>>> allocating ballooned pages.
>>> Do you think I can simply EXPORT_SYMBOL for
>>> {increase|decrease}_reservation?
>>> Any other suggestion?
>> I am actually wondering how much of that code you end up reusing.
>> You
>> pretty much create new code paths in both routines and common code
>> ends
>> up being essentially the hypercall.
> Well, I hoped that it would be easier to maintain if I modify
> existing
> code
> to support both use-cases, but I am also ok to create new routines if
> this
> seems to be reasonable - please let me know
>>     So the question is --- would it make
>> sense to do all of this separately from the balloon driver?
> This can be done, but which driver will host this code then? If we
> move from
> the balloon driver, then this could go to either gntdev or
> grant-table.
> What's your preference?
 A separate module?
 Is there any use for this feature outside of your zero-copy DRM
 driver?
>>> Intel's hyper dma-buf (Dongwon/Matt CC'ed), V4L/GPU at least.
>>>
>>> At the time I tried to upstream zcopy driver it was discussed and
>>> decided that
>>> it would be better if I remove all DRM specific code and move it to
>>> Xen drivers.
>>> Thus, this RFC.
>>>
>>> But it can also be implemented as a dedicated Xen dma-buf driver which
>>> will have all the
>>> code from this RFC + a bit more (char/misc device handling at least).
>>> This will also require a dedicated user-space library, just like
>>> libxengnttab.so
>>> for gntdev (now I have all new IOCTLs covered there).
>>>
>>> If the idea of a dedicated Xen dma-buf driver seems to be more
>>> attractive we
>>> can work toward this solution. BTW, I do support this idea, but was not
>>> sure if Xen community accepts yet another driver which duplicates
>>> quite some code
>>> of the existing gntdev/balloon/grant-table. And now after this RFC I
>>> hope that all cons
>>> and pros of both dedicated driver and gntdev/balloon/grant-table
>>> extension are
>>> clearly seen and we can make a decision.
>>
>> IIRC the objection for a separate module was in the context of gntdev
>> was discussion, because (among other things) people didn't want to have
>> yet another file in /dev/xen/
>>
>> Here we are talking about (a new) balloon-like module which doesn't
>> create any new user-visible interfaces. And as for duplicating code ---
>> as I said, I am not convinced there is much of duplication.
>>
>> I might even argue that we should add a new 

Re: cron job: media_tree daily build: ERRORS

[Jasmin J.]

Hello Hans!

> linux-4.9.91-x86_64: ERRORS
> /home/hans/work/build/media_build/v4l/dw9807.c:321:3: error
The build works in my tree ... ?!?
I can't find the file in media_tree:
   find . -name "*9807*"

Can you please check if there is something wrong with your
media_tree version which is used for the daily build.
I have 8ed8bba70b43 as top commit.

And another thing:
 ./prepare_kernel.sh 3.2 x86_64
fails with
 fatal error: linux/compiler-gcc8.h: No such file or directory
this leads to a build error in the daily build also.

BR,
   Jasmin

Re: [PATCH v4 06/12] media: dt-bindings: add bindings for i.MX7 media driver

[Sakari Ailus]

On Tue, May 22, 2018 at 02:19:21PM +0100, Rui Miguel Silva wrote:
> Hi Sakari,
> On Fri 18 May 2018 at 22:13, Sakari Ailus wrote:
> > On Fri, May 18, 2018 at 09:27:58AM +0100, Rui Miguel Silva wrote:
> > > > > +endpoint node
> > > > > +-
> > > > > +
> > > > > +- data-lanes: (required) an array specifying active > >
> > > physical
> > > > > MIPI-CSI2
> > > > > + data input lanes and their mapping to > > logical 
> > > > > lanes;
> > > the
> > > > > + array's content is unused, only its > > length is
> > > meaningful;
> > 
> > Btw. do note that you may get a warning due to this from the CSI-2 bus
> > property parsing code if the lane numbers are wrong.
> > 
> > > > > +
> > > > > +- fsl,csis-hs-settle : (optional) differential receiver > >
> > > (HS-RX)
> > > > > settle time;
> > > > > Could you calculate this, as other drivers do? It probably >
> > > changes
> > > > depending on the device runtime configuration.
> > > 
> > > The only reference to possible values to this parameter is given by
> > > table in [0], can you point me out the formula for imx7 in the
> > > documentation?
> > 
> > I don't know imx7 but the other CSI-2 drivers need no such system
> > specific
> > configuration.
> 
> Hum, I think there is at least one more (which this is compliant) that
> also use this configuration parameter. [0]

Ah, that's where it then probably comes from, if the two hardware blocks share 
some bits.

I guess it's fine to keep it if you think it's really necessary.

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

Re: [PATCH] media: pxa_camera: avoid duplicate s_power calls

[Sakari Ailus]

Dear Mita-san,

On Mon, May 21, 2018 at 12:40:38AM +0900, Akinobu Mita wrote:
> The open() operation for the pxa_camera driver always calls s_power()
> operation to put its subdevice sensor in normal operation mode, and the
> release() operation always call s_power() operation to put the subdevice
> in power saving mode.
> 
> This requires the subdevice sensor driver to keep track of its power
> state in order to avoid putting the subdevice in power saving mode while
> the device is still opened by some users.
> 
> Many subdevice drivers handle it by the boilerplate code that increments
> and decrements an internal counter in s_power() like below:
> 
>   /*
>* If the power count is modified from 0 to != 0 or from != 0 to 0,
>* update the power state.
>*/
>   if (sensor->power_count == !on) {
>   ret = ov5640_set_power(sensor, !!on);
>   if (ret)
>   goto out;
>   }
> 
>   /* Update the power count. */
>   sensor->power_count += on ? 1 : -1;
> 
> However, some subdevice drivers don't handle it and may cause a problem
> with the pxa_camera driver if the video device is opened by more than
> two users at the same time.
> 
> Instead of propagating the boilerplate code for each subdevice driver
> that implement s_power, this introduces an trick that many V4L2 drivers
> are using with v4l2_fh_is_singular_file().

I'd rather like that the sub-device drivers would move to use runtime PM
instead of depending on the s_power() callback. It's much cleaner that way.

It's not a near-term solution though. The approach seems fine, please see
comments below though.

> 
> Cc: Sakari Ailus 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Akinobu Mita 
> ---
>  drivers/media/platform/pxa_camera.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/pxa_camera.c 
> b/drivers/media/platform/pxa_camera.c
> index c71a007..c792cb1 100644
> --- a/drivers/media/platform/pxa_camera.c
> +++ b/drivers/media/platform/pxa_camera.c
> @@ -2040,6 +2040,9 @@ static int pxac_fops_camera_open(struct file *filp)
>   if (ret < 0)
>   goto out;
>  
> + if (!v4l2_fh_is_singular_file(filp))
> + goto out;
> +
>   ret = sensor_call(pcdev, core, s_power, 1);
>   if (ret)
>   v4l2_fh_release(filp);
> @@ -2052,13 +2055,17 @@ static int pxac_fops_camera_release(struct file *filp)
>  {
>   struct pxa_camera_dev *pcdev = video_drvdata(filp);
>   int ret;
> -
> - ret = vb2_fop_release(filp);
> - if (ret < 0)
> - return ret;
> + bool fh_singular;
>  
>   mutex_lock(>mlock);
> - ret = sensor_call(pcdev, core, s_power, 0);
> +
> + fh_singular = v4l2_fh_is_singular_file(filp);
> +
> + ret = _vb2_fop_release(filp, NULL);

I'm not sure whether using the return value to return an error from release
is really useful. If you want to use it, I'd shout loud instead.

> +
> + if (fh_singular)

ret assigned previously is overwritten here without checking.

> + ret = sensor_call(pcdev, core, s_power, 0);
> +
>   mutex_unlock(>mlock);
>  
>   return ret;

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

Re: [PATCH v4 0/3] IR decoding using BPF

[Matthias Reichl]

Hi Sean,

On Fri, May 18, 2018 at 03:07:27PM +0100, Sean Young wrote:
> The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most
> widely used IR protocols, but there are many protocols which are not
> supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes,
> many of which are not supported by rc-core. There is a "long tail" of
> unsupported IR protocols, for which lircd is need to decode the IR .
> 
> IR encoding is done in such a way that some simple circuit can decode it;
> therefore, bpf is ideal.
> 
> In order to support all these protocols, here we have bpf based IR decoding.
> The idea is that user-space can define a decoder in bpf, attach it to
> the rc device through the lirc chardev.
> 
> Separate work is underway to extend ir-keytable to have an extensive library
> of bpf-based decoders, and a much expanded library of rc keymaps.
> 
> Another future application would be to compile IRP[3] to a IR BPF program, and
> so support virtually every remote without having to write a decoder for each.
> It might also be possible to support non-button devices such as analog
> directional pads or air conditioning remote controls and decode the target
> temperature in bpf, and pass that to an input device.

Thanks a lot, this looks like a very interesting feature to me!

Unfortunately I don't have time to test it ATM, but please keep
me posted - also on ir-keytable progress - I'm rather excited
to give it a try.

so long & thanks,

Hias

> 
> Thanks,
> 
> Sean Young
> 
> [1] http://www.hifi-remote.com/wiki/index.php?title=DecodeIR
> [2] https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/
> [3] http://www.hifi-remote.com/wiki/index.php?title=IRP_Notation
> 
> Changes since v3:
>  - Implemented review comments from Quentin Monnet and Y Song (thanks!)
>  - More helpful and better formatted bpf helper documentation
>  - Changed back to bpf_prog_array rather than open-coded implementation
>  - scancodes can be 64 bit
>  - bpf gets passed values in microseconds, not nanoseconds.
>microseconds is more than than enough (IR receivers support carriers upto
>70kHz, at which point a single period is already 14 microseconds). Also,
>this makes it much more consistent with lirc mode2.
>  - Since it looks much more like lirc mode2, rename the program type to
>BPF_PROG_TYPE_LIRC_MODE2.
>  - Rebased on bpf-next
> 
> Changes since v2:
>  - Fixed locking issues
>  - Improved self-test to cover more cases
>  - Rebased on bpf-next again
> 
> Changes since v1:
>  - Code review comments from Y Song  and
>Randy Dunlap 
>  - Re-wrote sample bpf to be selftest
>  - Renamed RAWIR_DECODER -> RAWIR_EVENT (Kconfig, context, bpf prog type)
>  - Rebase on bpf-next
>  - Introduced bpf_rawir_event context structure with simpler access checking
> 
> Sean Young (3):
>   bpf: bpf_prog_array_copy() should return -ENOENT if exclude_prog not
> found
>   media: rc: introduce BPF_PROG_LIRC_MODE2
>   bpf: add selftest for lirc_mode2 type program
> 
>  drivers/media/rc/Kconfig  |  13 +
>  drivers/media/rc/Makefile |   1 +
>  drivers/media/rc/bpf-lirc.c   | 308 ++
>  drivers/media/rc/lirc_dev.c   |  30 ++
>  drivers/media/rc/rc-core-priv.h   |  22 ++
>  drivers/media/rc/rc-ir-raw.c  |  12 +-
>  include/linux/bpf_rcdev.h |  30 ++
>  include/linux/bpf_types.h |   3 +
>  include/uapi/linux/bpf.h  |  53 ++-
>  kernel/bpf/core.c |  11 +-
>  kernel/bpf/syscall.c  |   7 +
>  kernel/trace/bpf_trace.c  |   2 +
>  tools/bpf/bpftool/prog.c  |   1 +
>  tools/include/uapi/linux/bpf.h|  53 ++-
>  tools/include/uapi/linux/lirc.h   | 217 
>  tools/lib/bpf/libbpf.c|   1 +
>  tools/testing/selftests/bpf/Makefile  |   8 +-
>  tools/testing/selftests/bpf/bpf_helpers.h |   6 +
>  .../testing/selftests/bpf/test_lirc_mode2.sh  |  28 ++
>  .../selftests/bpf/test_lirc_mode2_kern.c  |  23 ++
>  .../selftests/bpf/test_lirc_mode2_user.c  | 154 +
>  21 files changed, 974 insertions(+), 9 deletions(-)
>  create mode 100644 drivers/media/rc/bpf-lirc.c
>  create mode 100644 include/linux/bpf_rcdev.h
>  create mode 100644 tools/include/uapi/linux/lirc.h
>  create mode 100755 tools/testing/selftests/bpf/test_lirc_mode2.sh
>  create mode 100644 tools/testing/selftests/bpf/test_lirc_mode2_kern.c
>  create mode 100644 tools/testing/selftests/bpf/test_lirc_mode2_user.c
> 
> -- 
> 2.17.0
> 

Re: [PATCH v4 06/12] media: dt-bindings: add bindings for i.MX7 media driver

[Rui Miguel Silva]

Hi Sakari,
On Fri 18 May 2018 at 22:13, Sakari Ailus wrote:
On Fri, May 18, 2018 at 09:27:58AM +0100, Rui Miguel Silva 
wrote:

> > +endpoint node
> > +-
> > +
> > +- data-lanes: (required) an array specifying active 
> > physical

> > MIPI-CSI2
> > +		data input lanes and their mapping to 
> > logical lanes; the
> > +		array's content is unused, only its 
> > length is meaningful;


Btw. do note that you may get a warning due to this from the 
CSI-2 bus

property parsing code if the lane numbers are wrong.


> > +
> > +- fsl,csis-hs-settle : (optional) differential receiver 
> > (HS-RX)

> > settle time;
> 
> Could you calculate this, as other drivers do? It probably 
> changes

> depending on the device runtime configuration.

The only reference to possible values to this parameter is 
given by

table in [0], can you point me out the formula for imx7 in the
documentation?


I don't know imx7 but the other CSI-2 drivers need no such 
system specific

configuration.


Hum, I think there is at least one more (which this is compliant) 
that

also use this configuration parameter. [0]

---
Cheers,
Rui

[0]: 
https://github.com/torvalds/linux/blob/a048a07d7f4535baa4cbad6bc024f175317ab938/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt#L46

Re: [PATCH 3/4] venus: add check to make scm calls

[Stanimir Varbanov]

Hi Vikash,

On 05/17/2018 02:32 PM, Vikash Garodia wrote:
> In order to invoke scm calls, ensure that the platform
> has the required support to invoke the scm calls in
> secure world. This code is in preparation to add PIL
> functionality in venus driver.
> 
> Signed-off-by: Vikash Garodia 
> ---
>  drivers/media/platform/qcom/venus/hfi_venus.c | 26 +++---
>  1 file changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
> b/drivers/media/platform/qcom/venus/hfi_venus.c
> index f61d34b..9bcce94 100644
> --- a/drivers/media/platform/qcom/venus/hfi_venus.c
> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
> @@ -27,6 +27,7 @@
>  #include "hfi_msgs.h"
>  #include "hfi_venus.h"
>  #include "hfi_venus_io.h"
> +#include "firmware.h"
>  
>  #define HFI_MASK_QHDR_TX_TYPE0xff00
>  #define HFI_MASK_QHDR_RX_TYPE0x00ff
> @@ -570,13 +571,19 @@ static int venus_halt_axi(struct venus_hfi_device *hdev)
>  static int venus_power_off(struct venus_hfi_device *hdev)
>  {
>   int ret;
> + void __iomem *reg_base;
>  
>   if (!hdev->power_enabled)
>   return 0;
>  
> - ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
> - if (ret)
> - return ret;
> + if (qcom_scm_is_available()) {
> + ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);

I think it will be clearer if we abstract qcom_scm_set_remote_state to
something like venus_set_state(SUSPEND|RESUME) in firmware.c and export
the functions to be used here.

-- 
regards,
Stan

Re: [PATCH 4/4] media: venus: add PIL support

[Stanimir Varbanov]

Hi Vikash,

On 05/17/2018 02:32 PM, Vikash Garodia wrote:
> This adds support to load the video firmware
> and bring ARM9 out of reset. This is useful
> for platforms which does not have trustzone
> to reset the ARM9.
> 
> Signed-off-by: Vikash Garodia 
> ---
>  .../devicetree/bindings/media/qcom,venus.txt   |   8 +-
>  drivers/media/platform/qcom/venus/core.c   |  67 +++--
>  drivers/media/platform/qcom/venus/core.h   |   6 +
>  drivers/media/platform/qcom/venus/firmware.c   | 163 
> +
>  drivers/media/platform/qcom/venus/firmware.h   |  10 +-
>  5 files changed, 217 insertions(+), 37 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt 
> b/Documentation/devicetree/bindings/media/qcom,venus.txt
> index 00d0d1b..0ff0f2d 100644
> --- a/Documentation/devicetree/bindings/media/qcom,venus.txt
> +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt

for this change in DT binding you have to cc devicetree ML. And probably
it could be separate patch.

> @@ -53,7 +53,7 @@
>  
>  * Subnodes
>  The Venus video-codec node must contain two subnodes representing
> -video-decoder and video-encoder.
> +video-decoder and video-encoder, one optional firmware subnode.
>  
>  Every of video-encoder or video-decoder subnode should have:
>  
> @@ -79,6 +79,8 @@ Every of video-encoder or video-decoder subnode should have:
>   power domain which is responsible for collapsing
>   and restoring power to the subcore.
>  
> +The firmware sub node must contain the iommus specifiers for ARM9.
> +
>  * An Example
>   video-codec@1d0 {
>   compatible = "qcom,msm8916-venus";
> @@ -105,4 +107,8 @@ Every of video-encoder or video-decoder subnode should 
> have:
>   clock-names = "core";
>   power-domains = < VENUS_CORE1_GDSC>;
>   };
> + firmware {

venus-firmware

> + compatible = "qcom,venus-pil-no-tz";

this should be following the other subnodes compatible names:

compatible = "venus-firmware";

> + iommus = <_smmu 0x10b2 0x0>;
> + }
>   };
> diff --git a/drivers/media/platform/qcom/venus/core.c 
> b/drivers/media/platform/qcom/venus/core.c
> index 1308488..16910558 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -30,6 +31,7 @@
>  #include "vdec.h"
>  #include "venc.h"
>  #include "firmware.h"
> +#include "hfi_venus.h"
>  
>  static void venus_event_notify(struct venus_core *core, u32 event)
>  {
> @@ -76,7 +78,7 @@ static void venus_sys_error_handler(struct work_struct 
> *work)
>   hfi_core_deinit(core, true);
>   hfi_destroy(core);
>   mutex_lock(>lock);
> - venus_shutdown(core->dev);
> + venus_shutdown(core);
>  
>   pm_runtime_put_sync(core->dev);
>  
> @@ -84,7 +86,7 @@ static void venus_sys_error_handler(struct work_struct 
> *work)
>  
>   pm_runtime_get_sync(core->dev);
>  
> - ret |= venus_boot(core->dev, core->res->fwname);
> + ret |= venus_boot(core);
>  
>   ret |= hfi_core_resume(core, true);
>  
> @@ -179,6 +181,20 @@ static u32 to_v4l2_codec_type(u32 codec)
>   }
>  }
>  
> +static int store_firmware_dev(struct device *dev, void *data)
> +{
> + struct venus_core *core;
> +
> + core = (struct venus_core *)data;
> + if (!core)
> + return -EINVAL;
> +
> + if (of_device_is_compatible(dev->of_node, "qcom,venus-pil-no-tz"))
> + core->fw.dev = dev;
> +
> + return 0;
> +}
> +
>  static int venus_enumerate_codecs(struct venus_core *core, u32 type)
>  {
>   const struct hfi_inst_ops dummy_ops = {};
> @@ -229,6 +245,7 @@ static int venus_probe(struct platform_device *pdev)
>   struct device *dev = >dev;
>   struct venus_core *core;
>   struct resource *r;
> + struct iommu_domain *iommu_domain;
>   int ret;
>  
>   core = devm_kzalloc(dev, sizeof(*core), GFP_KERNEL);
> @@ -279,7 +296,14 @@ static int venus_probe(struct platform_device *pdev)
>   if (ret < 0)
>   goto err_runtime_disable;
>  
> - ret = venus_boot(dev, core->res->fwname);
> + ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
> + if (ret)
> + goto err_runtime_disable;
> +
> + /* Attempt to register child devices */

This comment is wrong, the child devices are created by
of_platform_populate above.

> + ret = device_for_each_child(dev, core, store_firmware_dev);

Why we need these complex gymnastics to get struct device pointer when
that could be done in venus_firmware .probe method?

I think the answer is because you want to avoid having venus-firmware.ko
(because you have to have separate struct device for iommu SID). In that
case it would 

Re: [PATCH v10 13/16] vb2: add out-fence support to QBUF

[Hans Verkuil]

On 21/05/18 18:59, Ezequiel Garcia 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 in 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.
> 
> v12: - Pass the fence_fd in vb2_qbuf for clarity.
>  - Increase fence seqno if fence context if shared
>  - Check get_unused_fd return

v12 while this this PATCH v10? That's a bit confusing.

> 
> v11: - Return fence_fd to userpace only in the QBUF ioctl.
>  - Rework implementation to avoid storing the sync_file
>as state, which is not really needed.
> 
> v10: - use -EIO for fence error (Hans Verkuil)
>  - add comment around fence context creation (Hans Verkuil)
> 
> v9: - remove in-fences changes from this patch (Alex Courbot)
> - improve fence context creation (Hans Verkuil)
> - clean up out fences if vb2_core_qbuf() fails (Hans Verkuil)
> 
> 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 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/media/common/videobuf2/videobuf2-core.c | 113 
> +++-
>  drivers/media/common/videobuf2/videobuf2-v4l2.c |  10 ++-
>  drivers/media/dvb-core/dvb_vb2.c|   2 +-
>  include/media/videobuf2-core.h  |  20 -
>  4 files changed, 136 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index 86b5ebe25263..edc2fdaf56de 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -380,6 +381,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 */
> @@ -976,10 +978,22 @@ static void vb2_process_buffer_done(struct vb2_buffer 
> *vb, enum vb2_buffer_state
>   case VB2_BUF_STATE_QUEUED:
>   return;
>   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;
>   default:
> + if (vb->out_fence) {
> + if (state == VB2_BUF_STATE_ERROR)
> + dma_fence_set_error(vb->out_fence, -EIO);
> + 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;
> @@ -1406,6 +1420,76 @@ 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)
> 

Re: [PATCH v10 12/16] vb2: add in-fence support to QBUF

[Hans Verkuil]

On 21/05/18 18:59, Ezequiel Garcia wrote:
> From: Gustavo Padovan 
> 
> Receive in-fence from userspace and add support for waiting on them
> before queueing the buffer to the driver. Buffers can't be queued to the
> driver before its fences signal. And a buffer can't be queued to the driver
> out of the order they were queued from userspace. That means that even if
> its fence signals it must wait for all other buffers, ahead of it in the 
> queue,
> to signal first.
> 
> If the fence for some buffer fails we do not queue it to the driver,
> instead we mark it as error and wait until the previous buffer is done
> to notify userspace of the error. We wait here to deliver the buffers back
> to userspace in order.
> 
> v13: - cleanup implementation.
>  - remove wrong Kconfig changes.
>  - print noisy warning on unexpected enqueue conditioin
>  - schedule a vb2_start_streaming work from the fence callback
> 
> v12: fixed dvb_vb2.c usage of vb2_core_qbuf.
> 
> v11: - minor doc/comments fixes (Hans Verkuil)
>  - reviewed the in-fence path at __fill_v4l2_buffer()
> 
> v10: - rename fence to in_fence in many places
>  - handle fences signalling with error better (Hans Verkuil)
> 
> v9: - improve comments and docs (Hans Verkuil)
> - fix unlocking of vb->fence_cb_lock on vb2_core_qbuf (Hans Verkuil)
> - move in-fences code that was in the out-fences patch here (Alex)
> 
> v8: - improve comments about fences with errors
> 
> v7: - get rid of the fence array stuff for ordering and just use
>   get_num_buffers_ready() (Hans)
> - fix issue of queuing the buffer twice (Hans)
> - avoid the dma_fence_wait() in core_qbuf() (Alex)
> - merge preparation commit in
> 
> v6: - With fences always keep the order userspace queues the buffers.
> - Protect in_fence manipulation with a lock (Brian Starkey)
> - check if fences have the same context before adding a fence array
> - Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
> - Clean up fence if __set_in_fence() fails (Brian Starkey)
> - treat -EINVAL from dma_fence_add_callback() (Brian Starkey)
> 
> v5: - use fence_array to keep buffers ordered in vb2 core when
>   needed (Brian Starkey)
> - keep backward compat on the reserved2 field (Brian Starkey)
> - protect fence callback removal with lock (Brian Starkey)
> 
> v4: - Add a comment about dma_fence_add_callback() not returning a
>   error (Hans)
> - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
> - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
> - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
> - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
> - Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
>   vb2_start_streaming() (Hans)
> - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
> - Queue buffers to the driver as soon as they are ready (Hans)
> - call fill_user_buffer() after queuing the buffer (Hans)
> - add err: label to clean up fence
> - add dma_fence_wait() before calling vb2_start_streaming()
> 
> v3: - document fence parameter
> - remove ternary if at vb2_qbuf() return (Mauro)
> - do not change if conditions behaviour (Mauro)
> 
> v2: - fix vb2_queue_or_prepare_buf() ret check
> - remove check for VB2_MEMORY_DMABUF only (Javier)
> - check num of ready buffers to start streaming
> - when queueing, start from the first ready buffer
> - handle queue cancel
> 
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/media/common/videobuf2/Kconfig  |   1 +
>  drivers/media/common/videobuf2/videobuf2-core.c | 224 
> 
>  drivers/media/common/videobuf2/videobuf2-v4l2.c |  37 +++-
>  drivers/media/dvb-core/dvb_vb2.c|   2 +-
>  include/media/videobuf2-core.h  |  19 +-
>  5 files changed, 242 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/media/common/videobuf2/Kconfig 
> b/drivers/media/common/videobuf2/Kconfig
> index 17c32ea58395..27ad9e8a268b 100644
> --- a/drivers/media/common/videobuf2/Kconfig
> +++ b/drivers/media/common/videobuf2/Kconfig
> @@ -1,6 +1,7 @@
>  # Used by drivers that need Videobuf2 modules
>  config VIDEOBUF2_CORE
>   select DMA_SHARED_BUFFER
> + select SYNC_FILE
>   tristate
>  
>  config VIDEOBUF2_V4L2
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index a9a0a9d1decb..86b5ebe25263 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -27,6 +27,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -189,6 +190,7 @@ module_param(debug, int, 0644);
>  
>  static void __vb2_queue_cancel(struct vb2_queue *q);
>  static void 

Re: [PATCH v10 11/16] vb2: add explicit fence user API

[Hans Verkuil]

On 21/05/18 18:59, Ezequiel Garcia wrote:
> From: Gustavo Padovan 
> 
> Turn the reserved2 field into fence_fd that we will use to send
> an in-fence to the kernel or return an out-fence from the kernel to
> userspace.
> 
> Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
> when sending an in-fence to the kernel to be waited on, and
> V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
> 
> v8: return -1 if new flags are set.
> v7: minor fixes on the Documentation (Hans Verkuil)
> 
> v6: big improvement on doc (Hans Verkuil)
> 
> v5: - keep using reserved2 field for cpia2
> - set fence_fd to 0 for now, for compat with userspace(Mauro)
> 
> v4: make it a union with reserved2 and fence_fd (Hans Verkuil)
> 
> v3: make the out_fence refer to the current buffer (Hans Verkuil)
> 
> v2: add documentation
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  Documentation/media/uapi/v4l/buffer.rst | 48 
> ++---
>  drivers/media/common/videobuf2/videobuf2-v4l2.c |  6 +++-
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c   |  4 +--
>  include/uapi/linux/videodev2.h  |  8 -
>  4 files changed, 58 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> b/Documentation/media/uapi/v4l/buffer.rst
> index e2c85ddc990b..971b7453040c 100644
> --- a/Documentation/media/uapi/v4l/buffer.rst
> +++ b/Documentation/media/uapi/v4l/buffer.rst
> @@ -300,11 +300,23 @@ struct v4l2_buffer
>   multi-planar API the application sets this to the number of
>   elements in the ``planes`` array. The driver will fill in the
>   actual number of valid elements in that array.
> -* - __u32
> -  - ``reserved2``
> +* - __s32
> +  - ``fence_fd``
>-
> -  - A place holder for future extensions. Drivers and applications
> - must set this to 0.
> +  - Used to communicate a fence file descriptor from userspace to kernel
> + and vice-versa. On :ref:`VIDIOC_QBUF ` when sending
> + an in-fence for V4L2 to wait on, the ``V4L2_BUF_FLAG_IN_FENCE`` flag 
> must
> + be used and this field set to the fence file descriptor of the in-fence.
> + If the in-fence is not valid ` VIDIOC_QBUF`` returns an error.
> +
> +To get an out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE``
> + must be set, the kernel will return the out-fence file descriptor in
> + this field. If it fails to create the out-fence ``VIDIOC_QBUF` returns
> +an error.
> +
> + For all other ioctls V4L2 sets this field to -1 if
> + ``V4L2_BUF_FLAG_IN_FENCE`` and/or ``V4L2_BUF_FLAG_OUT_FENCE`` are set,
> + otherwise this field is set to 0 for backward compatibility.
>  * - __u32
>- ``reserved``
>-
> @@ -648,6 +660,34 @@ Buffer Flags
>- Start Of Exposure. The buffer timestamp has been taken when the
>   exposure of the frame has begun. This is only valid for the
>   ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
> +* .. _`V4L2-BUF-FLAG-IN-FENCE`:
> +
> +  - ``V4L2_BUF_FLAG_IN_FENCE``
> +  - 0x0020
> +  - Ask V4L2 to wait on the fence passed in the ``fence_fd`` field. The
> + buffer won't be queued to the driver until the fence signals. The order
> + in which buffers are queued is guaranteed to be preserved, so any
> + buffers queued after this buffer will also be blocked until this fence
> + signals. This flag must be set before calling ``VIDIOC_QBUF``. For
> + other ioctls the driver just reports the value of the flag.
> +
> +If the fence signals the flag is cleared and not reported anymore.
> + If the fence is not valid ``VIDIOC_QBUF`` returns an error.
> +* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
> +
> +  - ``V4L2_BUF_FLAG_OUT_FENCE``
> +  - 0x0040
> +  - Request for a fence to be attached to the buffer. The driver will 
> fill
> + in the out-fence fd in the ``fence_fd`` field when :ref:`VIDIOC_QBUF
> + ` returns. This flag must be set before calling
> + ``VIDIOC_QBUF``. This flag is only an input, and is not set by the 
> kernel.
> +
> +If the creation of the out-fence fails ``VIDIOC_QBUF`` returns an
> + error.
> +
> +Note that it is valid to set both ``V4L2_BUF_FLAG_IN_FENCE`` and
> +`V4L2_BUF_FLAG_OUT_FENCE`` flags. In such case, the ``fence_fd``
> +field is used to both set the in-fence and return the out-fence.
>  
>  
>  
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 64503615d00b..8312f61adfa6 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -203,9 +203,13 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
> void *pb)
>   b->timestamp = ns_to_timeval(vb->timestamp);
>   b->timecode = vbuf->timecode;
>   

Re: [PATCH v10 09/16] cobalt: add .is_unordered() for cobalt

[Hans Verkuil]

On 21/05/18 18:59, Ezequiel Garcia wrote:
> From: Gustavo Padovan 
> 
> The cobalt driver may reorder the capture buffers so we need to report
> it as such.
> 
> v3: set formats as unordered
> v2: use vb2_ops_set_unordered() helper
> 
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/media/pci/cobalt/cobalt-v4l2.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/media/pci/cobalt/cobalt-v4l2.c 
> b/drivers/media/pci/cobalt/cobalt-v4l2.c
> index e2a4c705d353..ccca1a96df90 100644
> --- a/drivers/media/pci/cobalt/cobalt-v4l2.c
> +++ b/drivers/media/pci/cobalt/cobalt-v4l2.c
> @@ -430,6 +430,7 @@ static const struct vb2_ops cobalt_qops = {
>   .stop_streaming = cobalt_stop_streaming,
>   .wait_prepare = vb2_ops_wait_prepare,
>   .wait_finish = vb2_ops_wait_finish,
> + .is_unordered = vb2_ops_is_unordered,
>  };
>  
>  /* V4L2 ioctls */
> @@ -695,14 +696,17 @@ static int cobalt_enum_fmt_vid_cap(struct file *file, 
> void *priv_fh,
>   case 0:
>   strlcpy(f->description, "YUV 4:2:2", sizeof(f->description));
>   f->pixelformat = V4L2_PIX_FMT_YUYV;
> + f->flags |= V4L2_FMT_FLAG_UNORDERED;
>   break;
>   case 1:
>   strlcpy(f->description, "RGB24", sizeof(f->description));
>   f->pixelformat = V4L2_PIX_FMT_RGB24;
> + f->flags |= V4L2_FMT_FLAG_UNORDERED;
>   break;
>   case 2:
>   strlcpy(f->description, "RGB32", sizeof(f->description));
>   f->pixelformat = V4L2_PIX_FMT_BGR32;
> + f->flags |= V4L2_FMT_FLAG_UNORDERED;

Rather than adding this for every case, just move it out of the switch and
set it just before the 'return 0'.

Regards,

Hans

>   break;
>   default:
>   return -EINVAL;
> 

Re: [PATCH v10 08/16] v4l: mark unordered formats

[Hans Verkuil]

On 21/05/18 18:59, Ezequiel Garcia wrote:
> From: Gustavo Padovan 
> 
> Now that we've introduced the V4L2_FMT_FLAG_UNORDERED flag,
> mark the appropriate formats.
> 
> v2: Set unordered flag before calling the driver callback.
> 
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 74 
> +++-
>  1 file changed, 57 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index f48c505550e0..2135ac235a96 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1102,6 +1102,27 @@ static int v4l_enumoutput(const struct v4l2_ioctl_ops 
> *ops,
>   return ops->vidioc_enum_output(file, fh, p);
>  }
>  
> +static void v4l_fill_unordered_fmtdesc(struct v4l2_fmtdesc *fmt)
> +{
> + switch (fmt->pixelformat) {
> + case V4L2_PIX_FMT_MPEG:
> + case V4L2_PIX_FMT_H264:
> + case V4L2_PIX_FMT_H264_NO_SC:
> + case V4L2_PIX_FMT_H264_MVC:
> + case V4L2_PIX_FMT_H263:
> + case V4L2_PIX_FMT_MPEG1:
> + case V4L2_PIX_FMT_MPEG2:
> + case V4L2_PIX_FMT_MPEG4:
> + case V4L2_PIX_FMT_XVID:
> + case V4L2_PIX_FMT_VC1_ANNEX_G:
> + case V4L2_PIX_FMT_VC1_ANNEX_L:
> + case V4L2_PIX_FMT_VP8:
> + case V4L2_PIX_FMT_VP9:
> + case V4L2_PIX_FMT_HEVC:
> + fmt->flags |= V4L2_FMT_FLAG_UNORDERED;

Please add a break here. This prevents potential future errors if new cases
are added below this line.

> + }
> +}
> +
>  static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>  {
>   const unsigned sz = sizeof(fmt->description);
> @@ -1310,61 +1331,80 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
>  
>   if (descr)
>   WARN_ON(strlcpy(fmt->description, descr, sz) >= sz);
> - fmt->flags = flags;
> + fmt->flags |= flags;
>  }
>  
> -static int v4l_enum_fmt(const struct v4l2_ioctl_ops *ops,
> - struct file *file, void *fh, void *arg)
> -{
> - struct v4l2_fmtdesc *p = arg;
> - int ret = check_fmt(file, p->type);
>  
> - if (ret)
> - return ret;
> - ret = -EINVAL;
> +static int __vidioc_enum_fmt(const struct v4l2_ioctl_ops *ops,
> +  struct v4l2_fmtdesc *p,
> +  struct file *file, void *fh)
> +{
> + int ret = 0;
>  
>   switch (p->type) {
>   case V4L2_BUF_TYPE_VIDEO_CAPTURE:
>   if (unlikely(!ops->vidioc_enum_fmt_vid_cap))
>   break;
> - ret = ops->vidioc_enum_fmt_vid_cap(file, fh, arg);
> + ret = ops->vidioc_enum_fmt_vid_cap(file, fh, p);
>   break;
>   case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
>   if (unlikely(!ops->vidioc_enum_fmt_vid_cap_mplane))
>   break;
> - ret = ops->vidioc_enum_fmt_vid_cap_mplane(file, fh, arg);
> + ret = ops->vidioc_enum_fmt_vid_cap_mplane(file, fh, p);
>   break;
>   case V4L2_BUF_TYPE_VIDEO_OVERLAY:
>   if (unlikely(!ops->vidioc_enum_fmt_vid_overlay))
>   break;
> - ret = ops->vidioc_enum_fmt_vid_overlay(file, fh, arg);
> + ret = ops->vidioc_enum_fmt_vid_overlay(file, fh, p);
>   break;
>   case V4L2_BUF_TYPE_VIDEO_OUTPUT:
>   if (unlikely(!ops->vidioc_enum_fmt_vid_out))
>   break;
> - ret = ops->vidioc_enum_fmt_vid_out(file, fh, arg);
> + ret = ops->vidioc_enum_fmt_vid_out(file, fh, p);
>   break;
>   case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
>   if (unlikely(!ops->vidioc_enum_fmt_vid_out_mplane))
>   break;
> - ret = ops->vidioc_enum_fmt_vid_out_mplane(file, fh, arg);
> + ret = ops->vidioc_enum_fmt_vid_out_mplane(file, fh, p);
>   break;
>   case V4L2_BUF_TYPE_SDR_CAPTURE:
>   if (unlikely(!ops->vidioc_enum_fmt_sdr_cap))
>   break;
> - ret = ops->vidioc_enum_fmt_sdr_cap(file, fh, arg);
> + ret = ops->vidioc_enum_fmt_sdr_cap(file, fh, p);
>   break;
>   case V4L2_BUF_TYPE_SDR_OUTPUT:
>   if (unlikely(!ops->vidioc_enum_fmt_sdr_out))
>   break;
> - ret = ops->vidioc_enum_fmt_sdr_out(file, fh, arg);
> + ret = ops->vidioc_enum_fmt_sdr_out(file, fh, p);
>   break;
>   case V4L2_BUF_TYPE_META_CAPTURE:
>   if (unlikely(!ops->vidioc_enum_fmt_meta_cap))
>   break;
> - ret = ops->vidioc_enum_fmt_meta_cap(file, fh, arg);
> + ret = ops->vidioc_enum_fmt_meta_cap(file, fh, p);
>   break;
>   }
> + return ret;
> +}
> +
> +static int v4l_enum_fmt(const 

Re: [PATCH 2/2] adv7511: fix incorrect clear of CEC receive interrupt

[Hans Verkuil]

On 22/05/18 13:33, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> If a CEC message was received and the RX interrupt was set, but
> not yet processed, and a new transmit was issues, then the

issues -> issued

> transmit code would inadvertently clear the RX interrupt and
> after that no new messages would ever be received.
> 
> Instead it should only clear TX interrupts since register 0x97
> is a clear-on-write register.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/i2c/adv7511.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
> index d23505a411ee..554261291e78 100644
> --- a/drivers/media/i2c/adv7511.c
> +++ b/drivers/media/i2c/adv7511.c
> @@ -831,8 +831,8 @@ static int adv7511_cec_adap_transmit(struct cec_adapter 
> *adap, u8 attempts,
>*/
>   adv7511_cec_write_and_or(sd, 0x12, ~0x70, max(1, attempts - 1) << 4);
>  
> - /* blocking, clear cec tx irq status */
> - adv7511_wr_and_or(sd, 0x97, 0xc7, 0x38);
> + /* clear cec tx irq status */
> + adv7511_wr(sd, 0x97, 0x38);
>  
>   /* write data */
>   for (i = 0; i < len; i++)
> 

[PATCH 0/2] cec: two CEC bugs, one in core, one in adv7511

[Hans Verkuil]

From: Hans Verkuil 

The first patch fixes an inconsistency in the cec core code where
wrong status information could be returned if a cec message was
canceled.

The second patch fixes a CEC adv7511 bug.

Regards,

Hans

Hans Verkuil (2):
  cec: fix wrong tx/rx_status values when canceling a msg
  adv7511: fix incorrect clear of CEC receive interrupt

 drivers/media/cec/cec-adap.c | 19 +--
 drivers/media/i2c/adv7511.c  |  4 ++--
 2 files changed, 15 insertions(+), 8 deletions(-)

-- 
2.17.0

[PATCH 2/2] adv7511: fix incorrect clear of CEC receive interrupt

[Hans Verkuil]

From: Hans Verkuil 

If a CEC message was received and the RX interrupt was set, but
not yet processed, and a new transmit was issues, then the
transmit code would inadvertently clear the RX interrupt and
after that no new messages would ever be received.

Instead it should only clear TX interrupts since register 0x97
is a clear-on-write register.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/adv7511.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index d23505a411ee..554261291e78 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -831,8 +831,8 @@ static int adv7511_cec_adap_transmit(struct cec_adapter 
*adap, u8 attempts,
 */
adv7511_cec_write_and_or(sd, 0x12, ~0x70, max(1, attempts - 1) << 4);
 
-   /* blocking, clear cec tx irq status */
-   adv7511_wr_and_or(sd, 0x97, 0xc7, 0x38);
+   /* clear cec tx irq status */
+   adv7511_wr(sd, 0x97, 0x38);
 
/* write data */
for (i = 0; i < len; i++)
-- 
2.17.0

[PATCH 1/2] cec: fix wrong tx/rx_status values when canceling a msg

[Hans Verkuil]

From: Hans Verkuil 

When a message was canceled it could return tx_status with
both OK and MAX_RETRIES set, which is illegal.

If a canceled message was waiting for a reply, then rx_status
wasn't updated, so set that as well.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 002ed4c90371..b7fad0ec5710 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -339,12 +339,19 @@ static void cec_data_cancel(struct cec_data *data)
data->adap->transmit_queue_sz--;
}
 
-   /* Mark it as an error */
-   data->msg.tx_ts = ktime_get_ns();
-   data->msg.tx_status |= CEC_TX_STATUS_ERROR |
-  CEC_TX_STATUS_MAX_RETRIES;
-   data->msg.tx_error_cnt++;
-   data->attempts = 0;
+   if (data->msg.tx_status & CEC_TX_STATUS_OK) {
+   /* Mark the canceled RX as a timeout */
+   data->msg.rx_ts = ktime_get_ns();
+   data->msg.rx_status = CEC_RX_STATUS_TIMEOUT;
+   } else {
+   /* Mark the canceled TX as an error */
+   data->msg.tx_ts = ktime_get_ns();
+   data->msg.tx_status |= CEC_TX_STATUS_ERROR |
+  CEC_TX_STATUS_MAX_RETRIES;
+   data->msg.tx_error_cnt++;
+   data->attempts = 0;
+   }
+
/* Queue transmitted message for monitoring purposes */
cec_queue_msg_monitor(data->adap, >msg, 1);
 
-- 
2.17.0

Re: [PATCH] gpu: ipu-v3: Fix BT1120 interlaced CCIR codes

[Philipp Zabel]

Hi Marek,

On Fri, 2018-05-18 at 18:21 +0200, Marek Vasut wrote:
> On 05/18/2018 05:51 PM, Philipp Zabel wrote:
> > Hi Marek,
> > 
> > On Sat, 2018-04-07 at 15:04 +0200, Marek Vasut wrote:
> > > The BT1120 interlaced CCIR codes are the same as BT656 ones
> > > and different than BT656 progressive CCIR codes, fix this.
> > 
> > thank you for the patch, and sorry for the delay.
> > 
> > > Signed-off-by: Marek Vasut 
> > > Cc: Steve Longerbeam 
> > > Cc: Philipp Zabel 
> > > ---
> > >  drivers/gpu/ipu-v3/ipu-csi.c | 8 ++--
> > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
> > > index caa05b0702e1..301a729581ce 100644
> > > --- a/drivers/gpu/ipu-v3/ipu-csi.c
> > > +++ b/drivers/gpu/ipu-v3/ipu-csi.c
> > > @@ -435,12 +435,16 @@ int ipu_csi_init_interface(struct ipu_csi *csi,
> > >   break;
> > >   case IPU_CSI_CLK_MODE_CCIR1120_PROGRESSIVE_DDR:
> > >   case IPU_CSI_CLK_MODE_CCIR1120_PROGRESSIVE_SDR:
> > > - case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_DDR:
> > > - case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_SDR:
> > >   ipu_csi_write(csi, 0x40030 | CSI_CCIR_ERR_DET_EN,
> > >  CSI_CCIR_CODE_1);
> > >   ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
> > >   break;
> > > + case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_DDR:
> > > + case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_SDR:
> > > + ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN, 
> > > CSI_CCIR_CODE_1);
> > > + ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
> > > + ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
> > 
> > If these are the same as BT656 codes (so this case would be for PAL?),
> > could this just be moved up into the IPU_CSI_CLK_MODE_CCIR656_INTERLACED
> > case? Would the NTSC CCIR codes be the same as well?
> 
> Dunno, I don't have any NTSC device to test. But the above was tested
> with a PAL device I had.
> 
> I think the CCIR codes are different from BT656, although I might be wrong.

The driver currently has:

case IPU_CSI_CLK_MODE_CCIR656_INTERLACED:
if (mbus_fmt->width == 720 && mbus_fmt->height == 576) {
/*
 * PAL case
 *
 * Field0BlankEnd = 0x6, Field0BlankStart = 0x2,
 * Field0ActiveEnd = 0x4, Field0ActiveStart = 0
 * Field1BlankEnd = 0x7, Field1BlankStart = 0x3,
 * Field1ActiveEnd = 0x5, Field1ActiveStart = 0x1
 */
height = 625; /* framelines for PAL */

ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
  CSI_CCIR_CODE_1);
ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
} else if (mbus_fmt->width == 720 && mbus_fmt->height == 480) { 
  
/*
 * NTSC case
 *
 * Field0BlankEnd = 0x7, Field0BlankStart = 0x3,
 * Field0ActiveEnd = 0x5, Field0ActiveStart = 0x1
 * Field1BlankEnd = 0x6, Field1BlankStart = 0x2,
 * Field1ActiveEnd = 0x4, Field1ActiveStart = 0
 */
height = 525; /* framelines for NTSC */

ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
  CSI_CCIR_CODE_1);
ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
} else {
dev_err(csi->ipu->dev,
"Unsupported CCIR656 interlaced video mode\n");
spin_unlock_irqrestore(>lock, flags);
return -EINVAL;
}
break;

The PAL codes are exactly the same as in your patch. That's why I wonder
whether we should just move
case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_DDR:
case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_SDR:
up before
case IPU_CSI_CLK_MODE_CCIR656_INTERLACED:
as follows:

--8<--
diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index caa05b0702e1..7e96382f9cb1 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -396,6 +396,8 @@ int ipu_csi_init_interface(struct ipu_csi *csi,
ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
break;
case IPU_CSI_CLK_MODE_CCIR656_INTERLACED:
+   case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_DDR:
+   case IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_SDR:
if 

Re: [PATCH v2] v4l: vsp1: Fix vsp1_regs.h license header

[Geert Uytterhoeven]

Hi Simon,

On Tue, May 22, 2018 at 11:05 AM, Simon Horman  wrote:
>> --- a/drivers/media/platform/vsp1/vsp1_regs.h
>> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
>> @@ -1,4 +1,4 @@
>> -/* SPDX-License-Identifier: GPL-2.0 */
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>
> While you are changing this line, I believe the correct format is
> to use a '//' comment.
>
> i.e.:
>
> // SPDX-License-Identifier: GPL-2.0+

Not for C header files, only for C source files.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Krzysztof Hałasa]

Hi,

Steve Longerbeam  writes:

> Hi Krzysztof, I've been on vacation, just returned today. I will
> find the time this week to attempt to reproduce your results on
> a SabreAuto quad with the adv7180.

Great. Please let me know if I can assist you somehow.

> Btw, if you just need to capture an interlaced frame (lines 0,1,2,...)
> without motion compensation, there is no need to use the VDIC
> path. Capturing directly from ipu2_csi1 should work, I've tested
> this many times on a SabreAuto. But I will try to reproduce your
> results.

That's what I was thinking. Thanks a lot.
-- 
Krzysztof Halasa

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

[GIT PULL for 4.18] More sensor driver patches

[Sakari Ailus]

Hi Mauro,

Here's another set of sensro driver patches for 4.18. There's DT support
for the ov772x sensors as well as a new driver for imx258.

Please pull.


The following changes since commit 8ed8bba70b4355b1ba029b151ade84475dd12991:

  media: imx274: remove non-indexed pointers from mode_table (2018-05-17 
06:22:08 -0400)

are available in the git repository at:

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

for you to fetch changes up to 3c42c667c9bf0857a25d829d4535db605de685ab:

  media: ov772x: create subdevice device node (2018-05-21 17:51:09 +0300)


Akinobu Mita (14):
  media: dt-bindings: ov772x: add device tree binding
  media: ov772x: correct setting of banding filter
  media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING
  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

Jason Chen (1):
  media: imx258: Add imx258 camera sensor driver

 .../devicetree/bindings/media/i2c/ov772x.txt   |   40 +
 MAINTAINERS|8 +
 arch/sh/boards/mach-migor/setup.c  |7 +-
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/imx258.c | 1320 
 drivers/media/i2c/ov772x.c |  355 --
 7 files changed, 1645 insertions(+), 97 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov772x.txt
 create mode 100644 drivers/media/i2c/imx258.c

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

Re: [PATCHv3 1/5] videobuf2-core: don't call memop 'finish' when queueing

[Hans Verkuil]

On 22/05/18 11:35, Sakari Ailus wrote:
> Hi Hans,
> 
> On Tue, May 22, 2018 at 10:14:47AM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> When a buffer is queued or requeued in vb2_buffer_done, then don't
>> call the finish memop. In this case the buffer is only returned to vb2,
>> not to userspace.
>>
>> Calling 'finish' here will cause an unbalance when the queue is
>> canceled, since the core will call the same memop again.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  drivers/media/common/videobuf2/videobuf2-core.c | 9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
>> b/drivers/media/common/videobuf2/videobuf2-core.c
>> index d3f7bb33a54d..f32ec7342ef0 100644
>> --- a/drivers/media/common/videobuf2/videobuf2-core.c
>> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
>> @@ -916,9 +916,12 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
>> vb2_buffer_state state)
>>  dprintk(4, "done processing on buffer %d, state: %d\n",
>>  vb->index, state);
>>  
>> -/* sync buffers */
>> -for (plane = 0; plane < vb->num_planes; ++plane)
>> -call_void_memop(vb, finish, vb->planes[plane].mem_priv);
>> +if (state != VB2_BUF_STATE_QUEUED &&
>> +state != VB2_BUF_STATE_REQUEUEING) {
>> +/* sync buffers */
>> +for (plane = 0; plane < vb->num_planes; ++plane)
>> +call_void_memop(vb, finish, vb->planes[plane].mem_priv);
>> +}
>>  
>>  spin_lock_irqsave(>done_lock, flags);
>>  if (state == VB2_BUF_STATE_QUEUED ||
> 
> How long do you think this problem has existed? Would this be worth fixing
> in the stable series as well?
> 
> 
> Could it be related to either of these two:
> 
> commit 03703ed1debf777ea845aa9b50ba2e80a5e7dd3c
> Author: Sakari Ailus 
> Date:   Fri Feb 2 05:08:59 2018 -0500
> 
> media: vb2: core: Finish buffers at the end of the stream
> 
> If buffers were prepared or queued and the buffers were released without
> starting the queue, the finish mem op (corresponding to the prepare mem
> op) was never called to the buffers.
> 
> Before commit a136f59c0a1f there was no need to do this as in such a case
> the prepare mem op had not been called yet. Address the problem by
> explicitly calling finish mem op when the queue is stopped if the buffer
> is in either prepared or queued state.
> 
> Fixes: a136f59c0a1f ("[media] vb2: Move buffer cache synchronisation to 
> prepare from queue")
> 
> Cc: sta...@vger.kernel.org # for v4.13 and up
> Signed-off-by: Sakari Ailus 
> Tested-by: Devin Heitmueller 
> Signed-off-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> commit a136f59c0a1f1b09eb203951975e3fc5e8d3e722
> Author: Sakari Ailus 
> Date:   Wed May 31 11:17:26 2017 -0300
> 
> [media] vb2: Move buffer cache synchronisation to prepare from queue
> 
> The buffer cache should be synchronised in buffer preparation, not when
> the buffer is queued to the device. Fix this.
> 
> Mmap buffers do not need cache synchronisation since they are always
> coherent.
> 
> Signed-off-by: Sakari Ailus 
> Acked-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 
> 

I think it is this last commit that introduced this.

It should definitely be applied to 4.16, but probably also to 4.14 (longterm
kernel), although that will first need your "vb2: core: Finish buffers at the
end of the stream" patch.

Regards,

Hans

Re: ir-keytable protocol setup broken and no ir events

[Sean Young]

On Mon, May 21, 2018 at 11:37:10AM +0300, just me wrote:
> Package: ir-keytable
> Version: 1.14.2-1, 1.12.3-1
> System:
>   Host: ryzenpc Kernel: 4.16.0-rc7+ x86_64 bits: 64 Desktop: Xfce
> 4.12.4 Distro: Debian GNU/Linux buster/sid
> 
> I have 3 usb dvb-t sticks: Alink DTU ( driver dvb_usb_af9035), MSI
> DigiVox mini II (driver dvb_usb_af9015) and Realtek RTL2832U (driver
> dvb_usb_rtl28xx)
> 
> None of the remote controllers does not work. They did work with Debian
> Jessie a couple of years ago. I tested the remote controller of Alink
> DTU with a programmable remote control and I can record events with it.
> 
> With ir-keytable the protocal can not be set and it shows no protocols
> although the protocol is defined in the keytable file.
> 
> xfce@ryzenpc:~$ sudo ir-keytable
> Found /sys/class/rc/rc1/ (/dev/input/event19) with:
> Name: Realtek RTL2832U reference design
> Driver: dvb_usb_rtl28xxu, table: rc-empty
> Supported protocols: rc-5 rc-5-sz jvc sony nec sanyo mce_kbd
> rc-6 sharp xmp Enabled protocols:

No lirc? Would you mind posting the kernel config and dmesg please.

> bus: 3, vendor/product: 0bda:2838, version: 0x0100
> Repeat delay = 500 ms, repeat period = 125 ms

> Found /sys/class/rc/rc0/ (/dev/input/event18) with:
> Name: ITE 9135(9006) Generic
> Driver: dvb_usb_af9035, table: rc-it913x-v1
> Supported protocols:
> Enabled protocols:

Very strange, it's like it hasn't detected the IR on line:

https://github.com/torvalds/linux/blob/master/drivers/media/usb/dvb-usb-v2/af9035.c?utf8=%E2%9C%93#L1880

> bus: 3, vendor/product: 048d:9006, version: 0x0200
> Repeat delay = 500 ms, repeat period = 125 ms
> 
> 
> xfce@ryzenpc:~$ sudo ir-keytable -p NEC -d /dev/input/event18
> Invalid protocols selected
> Couldn't change the IR protocols
> 
> xfce@ryzenpc:~$ sudo ir-keytable -p NEC -d /dev/input/event19
> Invalid protocols selected
> Couldn't change the IR protocols

Would you mind retrying that with "sudo ir-keytable -s rc0 -p nec" (or rc1),
I'm not sure it will work by selecting input device.

> No events shown with evtest and ir-keytable -t.
> 
> I am using the amd-staging-drm-next kernel.  I tested also with the
> stock Debian  kernel 4.15. I tested also with the latest Manjaro Linux.

A git bisect would be ideal. I did not spot anything from looking at the
code.

Thanks,

Sean

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

[Franz Melchior]

Hey,

* Krzysztof Hałasa, 2018-05-21 10:09:
> I wonder... perhaps to get an interlaced frame I need to route the data
> through VDIC (ipu2_vdic, the deinterlacer)?

I have the same problem here, though not investigated nearly as
thoroughly as you did, down to the IPU register values. But I also
get the images stable (PAL and NTSC) with every other line green
when de-interlacing via PRPVF/IDMAC. Unfortunately, de-interlacing
via VDIC doesn't work much better:

While the image seems properly de-interlaced and colored then, it
keeps jumping up an down a few times per second, because the first
line isn't always included in the image. (The pipeline is the same
as Tim showed under "using VDIC to deinterlace").

That's with the adv7180 and an iMX6Q with kernel 4.14.35.

m.

-- 
Melchior Franz | Entwicklung Software

GINZINGER ELECTRONIC SYSTEMS GMBH

Tel.: +43 7723 5422 156
Mail: melchior.fr...@ginzinger.com
Web: www.ginzinger.com

Re: [PATCHv3 1/5] videobuf2-core: don't call memop 'finish' when queueing

[Sakari Ailus]

Hi Hans,

On Tue, May 22, 2018 at 10:14:47AM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> When a buffer is queued or requeued in vb2_buffer_done, then don't
> call the finish memop. In this case the buffer is only returned to vb2,
> not to userspace.
> 
> Calling 'finish' here will cause an unbalance when the queue is
> canceled, since the core will call the same memop again.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/common/videobuf2/videobuf2-core.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index d3f7bb33a54d..f32ec7342ef0 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -916,9 +916,12 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
> vb2_buffer_state state)
>   dprintk(4, "done processing on buffer %d, state: %d\n",
>   vb->index, state);
>  
> - /* sync buffers */
> - for (plane = 0; plane < vb->num_planes; ++plane)
> - call_void_memop(vb, finish, vb->planes[plane].mem_priv);
> + if (state != VB2_BUF_STATE_QUEUED &&
> + state != VB2_BUF_STATE_REQUEUEING) {
> + /* sync buffers */
> + for (plane = 0; plane < vb->num_planes; ++plane)
> + call_void_memop(vb, finish, vb->planes[plane].mem_priv);
> + }
>  
>   spin_lock_irqsave(>done_lock, flags);
>   if (state == VB2_BUF_STATE_QUEUED ||

How long do you think this problem has existed? Would this be worth fixing
in the stable series as well?


Could it be related to either of these two:

commit 03703ed1debf777ea845aa9b50ba2e80a5e7dd3c
Author: Sakari Ailus 
Date:   Fri Feb 2 05:08:59 2018 -0500

media: vb2: core: Finish buffers at the end of the stream

If buffers were prepared or queued and the buffers were released without
starting the queue, the finish mem op (corresponding to the prepare mem
op) was never called to the buffers.

Before commit a136f59c0a1f there was no need to do this as in such a case
the prepare mem op had not been called yet. Address the problem by
explicitly calling finish mem op when the queue is stopped if the buffer
is in either prepared or queued state.

Fixes: a136f59c0a1f ("[media] vb2: Move buffer cache synchronisation to 
prepare from queue")

Cc: sta...@vger.kernel.org # for v4.13 and up
Signed-off-by: Sakari Ailus 
Tested-by: Devin Heitmueller 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

commit a136f59c0a1f1b09eb203951975e3fc5e8d3e722
Author: Sakari Ailus 
Date:   Wed May 31 11:17:26 2017 -0300

[media] vb2: Move buffer cache synchronisation to prepare from queue

The buffer cache should be synchronised in buffer preparation, not when
the buffer is queued to the device. Fix this.

Mmap buffers do not need cache synchronisation since they are always
coherent.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

-- 
Kind regards,

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

Re: [PATCH 06/20] omap4iss: Add video_device and vb2_queue locks

[Hans Verkuil]

On 18/05/18 20:51, Ezequiel Garcia wrote:
> video_device and vb2_queue locks are now both
> mandatory. Add them, remove driver ad-hoc locks,
> and implement wait_{prepare, finish}.
> 
> To stay on the safe side, this commit uses a single mutex
> for both locks. Better latency can be obtained by separating
> these if needed.
> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/staging/media/omap4iss/iss_video.c | 32 
> +++---
>  drivers/staging/media/omap4iss/iss_video.h |  2 +-
>  2 files changed, 8 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss_video.c 
> b/drivers/staging/media/omap4iss/iss_video.c
> index a3a83424a926..380cfd230262 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -260,10 +260,7 @@ __iss_video_get_format(struct iss_video *video,
>   fmt.pad = pad;
>   fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
>  
> - mutex_lock(>mutex);
>   ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, );
> - mutex_unlock(>mutex);
> -
>   if (ret)
>   return ret;
>  
> @@ -411,6 +408,8 @@ static const struct vb2_ops iss_video_vb2ops = {
>   .buf_prepare= iss_video_buf_prepare,
>   .buf_queue  = iss_video_buf_queue,
>   .buf_cleanup= iss_video_buf_cleanup,
> + .wait_prepare   = vb2_ops_wait_prepare,
> + .wait_finish= vb2_ops_wait_finish,
>  };
>  
>  /*
> @@ -592,9 +591,7 @@ iss_video_get_format(struct file *file, void *fh, struct 
> v4l2_format *format)
>   if (format->type != video->type)
>   return -EINVAL;
>  
> - mutex_lock(>mutex);
>   *format = vfh->format;
> - mutex_unlock(>mutex);
>  
>   return 0;
>  }
> @@ -609,8 +606,6 @@ iss_video_set_format(struct file *file, void *fh, struct 
> v4l2_format *format)
>   if (format->type != video->type)
>   return -EINVAL;
>  
> - mutex_lock(>mutex);
> -
>   /*
>* Fill the bytesperline and sizeimage fields by converting to media bus
>* format and back to pixel format.
> @@ -620,7 +615,6 @@ iss_video_set_format(struct file *file, void *fh, struct 
> v4l2_format *format)
>  
>   vfh->format = *format;
>  
> - mutex_unlock(>mutex);
>   return 0;
>  }
>  
> @@ -741,9 +735,7 @@ iss_video_set_selection(struct file *file, void *fh, 
> struct v4l2_selection *sel)
>   return -EINVAL;
>  
>   sdsel.pad = pad;
> - mutex_lock(>mutex);
>   ret = v4l2_subdev_call(subdev, pad, set_selection, NULL, );
> - mutex_unlock(>mutex);
>   if (!ret)
>   sel->r = sdsel.r;
>  
> @@ -873,8 +865,6 @@ iss_video_streamon(struct file *file, void *fh, enum 
> v4l2_buf_type type)
>   if (type != video->type)
>   return -EINVAL;
>  
> - mutex_lock(>stream_lock);
> -
>   /*
>* Start streaming on the pipeline. No link touching an entity in the
>* pipeline can be activated or deactivated once streaming is started.
> @@ -978,8 +968,6 @@ iss_video_streamon(struct file *file, void *fh, enum 
> v4l2_buf_type type)
>  
>   media_graph_walk_cleanup();
>  
> - mutex_unlock(>stream_lock);
> -
>   return 0;
>  
>  err_omap4iss_set_stream:
> @@ -996,8 +984,6 @@ iss_video_streamon(struct file *file, void *fh, enum 
> v4l2_buf_type type)
>  err_graph_walk_init:
>   media_entity_enum_cleanup(>ent_enum);
>  
> - mutex_unlock(>stream_lock);
> -
>   return ret;
>  }
>  
> @@ -1013,10 +999,8 @@ iss_video_streamoff(struct file *file, void *fh, enum 
> v4l2_buf_type type)
>   if (type != video->type)
>   return -EINVAL;
>  
> - mutex_lock(>stream_lock);
> -
>   if (!vb2_is_streaming(>queue))
> - goto done;
> + return 0;
>  
>   /* Update the pipeline state. */
>   if (video->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> @@ -1041,8 +1025,6 @@ iss_video_streamoff(struct file *file, void *fh, enum 
> v4l2_buf_type type)
>   video->iss->pdata->set_constraints(video->iss, false);
>   media_pipeline_stop(>video.entity);
>  
> -done:
> - mutex_unlock(>stream_lock);
>   return 0;
>  }
>  
> @@ -1137,6 +1119,7 @@ static int iss_video_open(struct file *file)
>   q->buf_struct_size = sizeof(struct iss_buffer);
>   q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>   q->dev = video->iss->dev;
> + q->lock = >v4l_lock;

I feel too much is changed in this driver (and also the omap3isp driver in the
next patch). Why not just set q->lock to stream_lock (queue_lock for omap3isp)?

There is no need to set video->video.lock at all, that's not compulsory.

Regards,

Hans

>  
>   ret = vb2_queue_init(q);
>   if (ret) {
> @@ -1238,12 +1221,11 @@ int omap4iss_video_init(struct iss_video *video, 
> const char *name)
>   if (ret < 0)
>   return ret;
>  
> + mutex_init(>v4l_lock);
>   spin_lock_init(>qlock);
> -   

Re: [PATCH v2] v4l: vsp1: Fix vsp1_regs.h license header

[Simon Horman]

On Sun, May 20, 2018 at 10:24:37AM +0300, Laurent Pinchart wrote:
> All source files of the vsp1 driver are licensed under the GPLv2+ except
> for vsp1_regs.h which is licensed under GPLv2. This is caused by a bad
> copy that dates back from the initial version of the driver. Fix
> it.
> 
> Cc: Nobuhiro Iwamatsu 
> Acked-by: Kieran Bingham 
> Acked-by: Sergei Shtylyov
> Acked-by: Niklas Söderlund 
> Acked-by: Wolfram Sang 
> Signed-off-by: Laurent Pinchart 
> ---
> Iwamatsu-san,
> 
> While working on the VSP1 driver I noticed that all source files are
> licensed under the GPLv2+ except for vsp1_regs.h which is licensed under
> GPLv2. I'd like to fix this inconsistency. As you have contributed to
> that file, could you please provide your explicit ack if you agree to
> this change ?
> ---
>  drivers/media/platform/vsp1/vsp1_regs.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_regs.h 
> b/drivers/media/platform/vsp1/vsp1_regs.h
> index 0d249ff9f564..e82661216c1d 100644
> --- a/drivers/media/platform/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> +/* SPDX-License-Identifier: GPL-2.0+ */

While you are changing this line, I believe the correct format is
to use a '//' comment.

i.e.:

// SPDX-License-Identifier: GPL-2.0+

>  /*
>   * vsp1_regs.h  --  R-Car VSP1 Registers Definitions
>   *
> -- 
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH v4 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

[Enric Balletbo Serra]

Hi Neil,

2018-05-21 16:21 GMT+02:00 Neil Armstrong :
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
>
> Signed-off-by: Stefan Adolfsson 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/platform/chrome/cros_ec_proto.c |  40 ++---
>  include/linux/mfd/cros_ec.h |   2 +-
>  include/linux/mfd/cros_ec_commands.h| 103 
> 
>  3 files changed, 135 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..c4f6c44 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device 
> *ec_dev,
>  }
>  EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +  struct cros_ec_command *msg,
> +  int version, uint32_t size)
> +{
> +   int ret;
> +
> +   msg->version = version;
> +   msg->command = EC_CMD_GET_NEXT_EVENT;
> +   msg->insize = size;
> +   msg->outsize = 0;
> +
> +   ret = cros_ec_cmd_xfer(ec_dev, msg);
> +   if (ret > 0) {
> +   ec_dev->event_size = ret - 1;
> +   memcpy(_dev->event_data, msg->data, ec_dev->event_size);
> +   }
> +
> +   return ret;
> +}
> +
>  static int get_next_event(struct cros_ec_device *ec_dev)
>  {
> u8 buffer[sizeof(struct cros_ec_command) + 
> sizeof(ec_dev->event_data)];
> struct cros_ec_command *msg = (struct cros_ec_command *)
> +   static int cmd_version = 1;
> int ret;
>
> if (ec_dev->suspended) {
> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
> return -EHOSTDOWN;
> }
>
> -   msg->version = 0;
> -   msg->command = EC_CMD_GET_NEXT_EVENT;
> -   msg->insize = sizeof(ec_dev->event_data);
> -   msg->outsize = 0;
> +   if (cmd_version == 1) {
> +   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> +   sizeof(struct ec_response_get_next_event_v1));
> +   if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> +   return ret;
>

Thinking a bit more, there is a command to ask supported command
versions (EC_CMD_GET_CMD_VERSION). So, i theory you should be able to
ask for the versions supported by the command, see for example what is
done in [1], [2] and [3]. Anyway I am fine with this for now, and
after do some test seems that nothing breaks, so

Tested-by: Enric Balletbo i Serra 

Thanks,
 Enric

[1] 
https://chromium.googlesource.com/chromiumos/platform/ec/+/master/util/misc_util.c#98
[2] 
https://chromium.googlesource.com/chromiumos/platform/ec/+/master/util/misc_util.c#131
[3] 
https://chromium.googlesource.com/chromiumos/platform/ec/+/master/util/ectool.c#786


> -   ret = cros_ec_cmd_xfer(ec_dev, msg);
> -   if (ret > 0) {
> -   ec_dev->event_size = ret - 1;
> -   memcpy(_dev->event_data, msg->data,
> -  sizeof(ec_dev->event_data));
> +   /* Fallback to version 0 for future send attempts */
> +   cmd_version = 0;
> }
>
> +   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event));
> +
> return ret;
>  }
>
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index f36125e..32caef3 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
> bool mkbp_event_supported;
> struct blocking_notifier_head event_notifier;
>
> -   struct ec_response_get_next_event event_data;
> +   struct ec_response_get_next_event_v1 event_data;
> int event_size;
> u32 host_event_wake_mask;
>  };
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..9b8bc4a 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -804,6 +804,8 @@ enum ec_feature_code {
> EC_FEATURE_MOTION_SENSE_FIFO = 24,
> /* EC has RTC feature that can be controlled by host commands */
> EC_FEATURE_RTC = 27,
> +   /* EC supports CEC commands */
> +   EC_FEATURE_CEC = 35,
>  };
>
>  #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
> /* EC sent a sysrq command */
> 

Re: [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties

[Simon Horman]

On Thu, May 17, 2018 at 11:01:10AM +0200, jacopo mondi wrote:
> Hi Niklas,
> 
> On Thu, May 17, 2018 at 12:13:07AM +0200, Niklas Söderlund wrote:
> > Hi Jacopo,
> >
> > Thanks for your work.
> >
> > On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> > > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > > driver and only confuse users. Remove them in all Gen2 SoC that used
> > > them.
> > >
> > > Signed-off-by: Jacopo Mondi 
> > > ---
> > >  arch/arm/boot/dts/r8a7790-lager.dts   | 3 ---
> > >  arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> > >  arch/arm/boot/dts/r8a7791-porter.dts  | 1 -
> > >  arch/arm/boot/dts/r8a7793-gose.dts| 3 ---
> > >  arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> > >  arch/arm/boot/dts/r8a7794-silk.dts| 1 -
> > >  6 files changed, 12 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
> > > b/arch/arm/boot/dts/r8a7790-lager.dts
> > > index 063fdb6..b56b309 100644
> > > --- a/arch/arm/boot/dts/r8a7790-lager.dts
> > > +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> > > @@ -873,10 +873,8 @@
> > >   port {
> > >   vin0ep2: endpoint {
> > >   remote-endpoint = <_out>;
> > > - bus-width = <24>;
> >
> > I can't really make up my mind if this is a good thing or not. Device
> > tree describes the hardware and not what the drivers make use of. And
> > the fact is that this bus is 24 bits wide. So I'm not sure we should
> > remove these properties. But I would love to hear what others think
> > about this.
> >
> 
> Just to point out those properties are not even documented in rcar-vin
> bindings (actually, none of them was).
> 
> I feel it's wrong to have them here, as someone may think that
> changing their value should actually change the VIN interface behavior,
> which it's not true, leading to massive confusion and quite some code
> digging for no reason (and they will get mad at us at some point, probably :)

I think its fine that the driver doesn't implement something described in
DT - we are describing the hardware not the implementation. But I think its
not fine that DT includes properties not described in the binding.

So I think we should either
a) Fix the binding documentation, but perhaps it is already correct
   in which case we should;
b) Apply this patch

Once we have decided what is the correct description of the hardware we
can consider implications on the driver implementation.

Re: [PATCHv2 0/4] gspca: convert to vb2gspca: convert to vb2

[Hans Verkuil]

On 18/05/18 19:51, Ezequiel Garcia wrote:
> On 13 May 2018 at 06:47, Hans Verkuil  wrote:
>> From: Hans Verkuil 
>>
>> The first patch converts the gspca driver to the vb2 framework.
>> It was much easier to do than I expected and it saved almost 600
>> lines of gspca driver code.
>>
>> The second patch fixes v4l2-compliance warnings for g/s_parm.
>>
>> The third patch clears relevant fields in v4l2_streamparm in
>> v4l_s_parm(). This was never done before since v4l2-compliance
>> didn't check this.
>>
>> The final patch deletes the now unused v4l2_disable_ioctl_locking()
>> function.
>>
>> Tested with three different gspca webcams, and tested suspend/resume
>> as well.
>>
>> I'll test with a few more webcams next week and if those tests all
>> succeed then I'll post a pull request.
>>
>> Regards,
>>
>> Hans
>>
>> Changes since v1:
>>
>> - Re-added 'if (gspca_dev->present)' before the dq_callback call.
>> - Added Reviewed-by tags from Hans de Goede.
>>
>> Hans Verkuil (4):
>>   gspca: convert to vb2
>>   gspca: fix g/s_parm handling
>>   v4l2-ioctl: clear fields in s_parm
>>   v4l2-ioctl: delete unused v4l2_disable_ioctl_locking
>>
>>  drivers/media/usb/gspca/Kconfig|   1 +
>>  drivers/media/usb/gspca/gspca.c| 925 -
>>  drivers/media/usb/gspca/gspca.h|  38 +-
>>  drivers/media/usb/gspca/m5602/m5602_core.c |   4 +-
>>  drivers/media/usb/gspca/ov534.c|   1 -
>>  drivers/media/usb/gspca/topro.c|   1 -
>>  drivers/media/usb/gspca/vc032x.c   |   2 +-
>>  drivers/media/v4l2-core/v4l2-ioctl.c   |  19 +-
>>  include/media/v4l2-dev.h   |  15 -
>>  9 files changed, 210 insertions(+), 796 deletions(-)
>>
> 
> Got a NULL pointer testing this series. However, I don't think
> the problem is with this series per-se, but more of a long-standing
> race.
> 
> [ 1133.771530] BUG: unable to handle kernel NULL pointer dereference
> at 00c4
> [ 1133.779354] PGD 0 P4D 0
> [ 1133.781885] Oops:  [#1] PREEMPT SMP PTI
> [ 1133.786065] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
> 4.17.0-rc3-next-20180503-ARCH-00029-gb14b92b054cc-dirty #11
> [ 1133.796306] Hardware name: ASUS All Series/H81M-D R2.0, BIOS 0504 
> 05/14/2015
> [ 1133.803346] RIP: 0010:sd_pkt_scan+0x246/0x350 [gspca_sonixj]
> [ 1133.808994] Code: 00 89 d9 4c 89 e2 be 03 00 00 00 4c 89 ef e8 f1
> 06 c9 ff 49 8b 95 30 05 00 00 41 6b 85 d0 08 00 00 64 41 0f b7 8d d4
> 08 00 00 <0f> af 8a c4 00 00 00 31 d2 f7 f1 83 f8 54 0f 8f a6 00 00 00
> 83 f8
> [ 1133.827845] RSP: 0018:88011fa83c78 EFLAGS: 00010002
> [ 1133.833061] RAX: 00282d8c RBX: 02ee RCX: 
> 0027
> [ 1133.840204] RDX:  RSI: 0003 RDI: 
> 8800c10b97e0
> [ 1133.847343] RBP: 88011fa83ca0 R08: 000241a0 R09: 
> a021d45e
> [ 1133.854469] R10: 032c R11: 880115938700 R12: 
> 8800c765b840
> [ 1133.861591] R13: 8800c10b9000 R14: 032c R15: 
> 032c
> [ 1133.868726] FS:  () GS:88011fa8()
> knlGS:
> [ 1133.876802] CS:  0010 DS:  ES:  CR0: 80050033
> [ 1133.882540] CR2: 00c4 CR3: 0200a004 CR4: 
> 001606e0
> [ 1133.889663] DR0:  DR1:  DR2: 
> 
> [ 1133.896788] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [ 1133.903920] Call Trace:
> [ 1133.906365]  
> [ 1133.908376]  ? sd_stop0+0x40/0x40 [gspca_sonixj]
> [ 1133.912988]  isoc_irq+0xb8/0x130 [gspca_main]
> [ 1133.917340]  __usb_hcd_giveback_urb+0x64/0xe0 [usbcore]
> [ 1133.922565]  usb_hcd_giveback_urb+0x11f/0x130 [usbcore]
> [ 1133.927782]  xhci_giveback_urb_in_irq.isra.20+0x84/0x100 [xhci_hcd]
> [ 1133.934038]  ? handle_cmd_completion+0x2cd/0x1100 [xhci_hcd]
> [ 1133.939689]  xhci_td_cleanup+0xfb/0x170 [xhci_hcd]
> [ 1133.944490]  finish_td+0xb3/0xf0 [xhci_hcd]
> [ 1133.948669]  xhci_irq+0x1532/0x2130 [xhci_hcd]
> [ 1133.953106]  ? handle_irq_event+0x47/0x5b
> [ 1133.957110]  xhci_msi_irq+0x11/0x20 [xhci_hcd]
> [ 1133.961546]  __handle_irq_event_percpu+0x42/0x1b0
> [ 1133.966243]  handle_irq_event_percpu+0x32/0x80
> [ 1133.970681]  handle_irq_event+0x3c/0x5b
> [ 1133.974511]  handle_edge_irq+0x7f/0x1b0
> [ 1133.978342]  handle_irq+0x1a/0x30
> [ 1133.981654]  do_IRQ+0x46/0xd0
> [ 1133.984617]  common_interrupt+0xf/0xf
> [ 1133.988274]  
> 
> Common sense tells me that the gspca_dev->urb[0] is
> set to NULL in destroy_urbs() and then accessed:
> 
> static void sd_pkt_scan(struct gspca_dev *gspca_dev,
> u8 *data,   /* isoc packet */
> int len)/* iso packet length 
> */
> {
> [..]
> r = (sd->pktsz * 100) /
> (sd->npkt *
> 

[PATCHv3 2/5] gspca: convert to vb2

[Hans Verkuil]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
Reviewed-by: Hans de Goede 
---
 drivers/media/usb/gspca/Kconfig|   1 +
 drivers/media/usb/gspca/gspca.c| 906 -
 drivers/media/usb/gspca/gspca.h|  38 +-
 drivers/media/usb/gspca/m5602/m5602_core.c |   4 +-
 drivers/media/usb/gspca/vc032x.c   |   2 +-
 5 files changed, 182 insertions(+), 769 deletions(-)

diff --git a/drivers/media/usb/gspca/Kconfig b/drivers/media/usb/gspca/Kconfig
index bc9a439745aa..d3b6665c342d 100644
--- a/drivers/media/usb/gspca/Kconfig
+++ b/drivers/media/usb/gspca/Kconfig
@@ -2,6 +2,7 @@ menuconfig USB_GSPCA
tristate "GSPCA based webcams"
depends on VIDEO_V4L2
depends on INPUT || INPUT=n
+   select VIDEOBUF2_VMALLOC
default m
---help---
  Say Y here if you want to enable selecting webcams based
diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index d29773b8f696..ff229d3aae0f 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -82,32 +82,6 @@ static void PDEBUG_MODE(struct gspca_dev *gspca_dev, int 
debug, char *txt,
 #define GSPCA_MEMORY_NO 0  /* V4L2_MEMORY_xxx starts from 1 */
 #define GSPCA_MEMORY_READ 7
 
-#define BUF_ALL_FLAGS (V4L2_BUF_FLAG_QUEUED | V4L2_BUF_FLAG_DONE)
-
-/*
- * VMA operations.
- */
-static void gspca_vm_open(struct vm_area_struct *vma)
-{
-   struct gspca_frame *frame = vma->vm_private_data;
-
-   frame->vma_use_count++;
-   frame->v4l2_buf.flags |= V4L2_BUF_FLAG_MAPPED;
-}
-
-static void gspca_vm_close(struct vm_area_struct *vma)
-{
-   struct gspca_frame *frame = vma->vm_private_data;
-
-   if (--frame->vma_use_count <= 0)
-   frame->v4l2_buf.flags &= ~V4L2_BUF_FLAG_MAPPED;
-}
-
-static const struct vm_operations_struct gspca_vm_ops = {
-   .open   = gspca_vm_open,
-   .close  = gspca_vm_close,
-};
-
 /*
  * Input and interrupt endpoint handling functions
  */
@@ -356,7 +330,7 @@ static void isoc_irq(struct urb *urb)
struct gspca_dev *gspca_dev = (struct gspca_dev *) urb->context;
 
gspca_dbg(gspca_dev, D_PACK, "isoc irq\n");
-   if (!gspca_dev->streaming)
+   if (!vb2_start_streaming_called(_dev->queue))
return;
fill_frame(gspca_dev, urb);
 }
@@ -370,7 +344,7 @@ static void bulk_irq(struct urb *urb)
int st;
 
gspca_dbg(gspca_dev, D_PACK, "bulk irq\n");
-   if (!gspca_dev->streaming)
+   if (!vb2_start_streaming_called(_dev->queue))
return;
switch (urb->status) {
case 0:
@@ -417,25 +391,24 @@ void gspca_frame_add(struct gspca_dev *gspca_dev,
const u8 *data,
int len)
 {
-   struct gspca_frame *frame;
-   int i, j;
+   struct gspca_buffer *buf;
+   unsigned long flags;
 
gspca_dbg(gspca_dev, D_PACK, "add t:%d l:%d\n", packet_type, len);
 
-   if (packet_type == FIRST_PACKET) {
-   i = atomic_read(_dev->fr_i);
+   spin_lock_irqsave(_dev->qlock, flags);
+   buf = list_first_entry_or_null(_dev->buf_list,
+  typeof(*buf), list);
+   spin_unlock_irqrestore(_dev->qlock, flags);
 
-   /* if there are no queued buffer, discard the whole frame */
-   if (i == atomic_read(_dev->fr_q)) {
+   if (packet_type == FIRST_PACKET) {
+   /* if there is no queued buffer, discard the whole frame */
+   if (!buf) {
gspca_dev->last_packet_type = DISCARD_PACKET;
gspca_dev->sequence++;
return;
}
-   j = gspca_dev->fr_queue[i];
-   frame = _dev->frame[j];
-   v4l2_get_timestamp(>v4l2_buf.timestamp);
-   frame->v4l2_buf.sequence = gspca_dev->sequence++;
-   gspca_dev->image = frame->data;
+   gspca_dev->image = vb2_plane_vaddr(>vb.vb2_buf, 0);
gspca_dev->image_len = 0;
} else {
switch (gspca_dev->last_packet_type) {
@@ -453,10 +426,10 @@ void gspca_frame_add(struct gspca_dev *gspca_dev,
 
/* append the packet to the frame buffer */
if (len > 0) {
-   if (gspca_dev->image_len + len > gspca_dev->frsz) {
+   if (gspca_dev->image_len + len > gspca_dev->pixfmt.sizeimage) {
gspca_err(gspca_dev, "frame overflow %d > %d\n",
  gspca_dev->image_len + len,
- gspca_dev->frsz);
+ gspca_dev->pixfmt.sizeimage);
packet_type = DISCARD_PACKET;
} else {
 /* !! image is NULL only when last pkt is LAST or DISCARD
@@ -476,80 +449,23 @@ void gspca_frame_add(struct gspca_dev 

[PATCHv3 4/5] v4l2-ioctl: clear fields in s_parm

[Hans Verkuil]

From: Hans Verkuil 

Zero the reserved capture/output array.

Zero the extendedmode (it is never used in drivers).

Clear all flags in capture/outputmode except for V4L2_MODE_HIGHQUALITY,
as that is the only valid flag.

Signed-off-by: Hans Verkuil 
Reviewed-by: Hans de Goede 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index a40dbec271f1..212aac1d22c1 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1952,7 +1952,22 @@ static int v4l_s_parm(const struct v4l2_ioctl_ops *ops,
struct v4l2_streamparm *p = arg;
int ret = check_fmt(file, p->type);
 
-   return ret ? ret : ops->vidioc_s_parm(file, fh, p);
+   if (ret)
+   return ret;
+
+   /* Note: extendedmode is never used in drivers */
+   if (V4L2_TYPE_IS_OUTPUT(p->type)) {
+   memset(p->parm.output.reserved, 0,
+  sizeof(p->parm.output.reserved));
+   p->parm.output.extendedmode = 0;
+   p->parm.output.outputmode &= V4L2_MODE_HIGHQUALITY;
+   } else {
+   memset(p->parm.capture.reserved, 0,
+  sizeof(p->parm.capture.reserved));
+   p->parm.capture.extendedmode = 0;
+   p->parm.capture.capturemode &= V4L2_MODE_HIGHQUALITY;
+   }
+   return ops->vidioc_s_parm(file, fh, p);
 }
 
 static int v4l_queryctrl(const struct v4l2_ioctl_ops *ops,
-- 
2.17.0

[PATCHv3 3/5] gspca: fix g/s_parm handling

[Hans Verkuil]

From: Hans Verkuil 

Fix v4l2-compliance error: s_parm never set V4L2_CAP_TIMEPERFRAME.
Also various g/s_parm-related cleanups.

Signed-off-by: Hans Verkuil 
Reviewed-by: Hans de Goede 
---
 drivers/media/usb/gspca/gspca.c | 29 -
 drivers/media/usb/gspca/ov534.c |  1 -
 drivers/media/usb/gspca/topro.c |  1 -
 3 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index ff229d3aae0f..a72799666417 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -1256,14 +1256,15 @@ static int vidioc_g_parm(struct file *filp, void *priv,
 {
struct gspca_dev *gspca_dev = video_drvdata(filp);
 
-   parm->parm.capture.readbuffers = 2;
+   parm->parm.capture.readbuffers = gspca_dev->queue.min_buffers_needed;
 
-   if (gspca_dev->sd_desc->get_streamparm) {
-   gspca_dev->usb_err = 0;
-   gspca_dev->sd_desc->get_streamparm(gspca_dev, parm);
-   return gspca_dev->usb_err;
-   }
-   return 0;
+   if (!gspca_dev->sd_desc->get_streamparm)
+   return 0;
+
+   parm->parm.capture.capability = V4L2_CAP_TIMEPERFRAME;
+   gspca_dev->usb_err = 0;
+   gspca_dev->sd_desc->get_streamparm(gspca_dev, parm);
+   return gspca_dev->usb_err;
 }
 
 static int vidioc_s_parm(struct file *filp, void *priv,
@@ -1271,15 +1272,17 @@ static int vidioc_s_parm(struct file *filp, void *priv,
 {
struct gspca_dev *gspca_dev = video_drvdata(filp);
 
-   parm->parm.capture.readbuffers = 2;
+   parm->parm.capture.readbuffers = gspca_dev->queue.min_buffers_needed;
 
-   if (gspca_dev->sd_desc->set_streamparm) {
-   gspca_dev->usb_err = 0;
-   gspca_dev->sd_desc->set_streamparm(gspca_dev, parm);
-   return gspca_dev->usb_err;
+   if (!gspca_dev->sd_desc->set_streamparm) {
+   parm->parm.capture.capability = 0;
+   return 0;
}
 
-   return 0;
+   parm->parm.capture.capability = V4L2_CAP_TIMEPERFRAME;
+   gspca_dev->usb_err = 0;
+   gspca_dev->sd_desc->set_streamparm(gspca_dev, parm);
+   return gspca_dev->usb_err;
 }
 
 static int gspca_queue_setup(struct vb2_queue *vq,
diff --git a/drivers/media/usb/gspca/ov534.c b/drivers/media/usb/gspca/ov534.c
index f293921a1f2b..d06dc0755b9a 100644
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -1476,7 +1476,6 @@ static void sd_get_streamparm(struct gspca_dev *gspca_dev,
struct v4l2_fract *tpf = >timeperframe;
struct sd *sd = (struct sd *) gspca_dev;
 
-   cp->capability |= V4L2_CAP_TIMEPERFRAME;
tpf->numerator = 1;
tpf->denominator = sd->frame_rate;
 }
diff --git a/drivers/media/usb/gspca/topro.c b/drivers/media/usb/gspca/topro.c
index 82e2be14cad8..6f3ec0366a2f 100644
--- a/drivers/media/usb/gspca/topro.c
+++ b/drivers/media/usb/gspca/topro.c
@@ -4780,7 +4780,6 @@ static void sd_get_streamparm(struct gspca_dev *gspca_dev,
struct v4l2_fract *tpf = >timeperframe;
int fr, i;
 
-   cp->capability |= V4L2_CAP_TIMEPERFRAME;
tpf->numerator = 1;
i = get_fr_idx(gspca_dev);
if (i & 0x80) {
-- 
2.17.0

[PATCHv3 0/5] gspca: convert to vb2gspca: convert to vb2

[Hans Verkuil]

From: Hans Verkuil 

The first patch fixes a bug in videobuf2-core.c: the finish memop
should not be called when vb2_buffer_done is called with state
QUEUED or REQUEUEING. Doing so leads to one finish too many and
an 'UNBALANCED' error is logged. Discovered since some of these
gspca webcams are flaky and fail during start_streaming.

The second patch converts the gspca driver to the vb2 framework.
It was much easier to do than I expected and it saved almost 600
lines of gspca driver code.

The third patch fixes v4l2-compliance warnings for g/s_parm.

The fourth patch clears relevant fields in v4l2_streamparm in
v4l_s_parm(). This was never done before since v4l2-compliance
didn't check this.

The final patch deletes the now unused v4l2_disable_ioctl_locking()
function.

Tested with many gspca webcams, and tested suspend/resume as well.

Regards,

Hans

Changes since v2:

- Added first videobuf2-core.c patch
- Improve disconnect code to no longer destroy URBs, instead leave
  that to gspca_release(). This avoids a NULL pointer bug if the
  gspca subdriver was still processing URBs at disconnect time.
- A spinlock in gspca_frame_add() didn't disable irqs, which it
  should since it can be called from non-irq context.

Changes since v1:

- Re-added 'if (gspca_dev->present)' before the dq_callback call.
- Added Reviewed-by tags from Hans de Goede.

Hans Verkuil (5):
  videobuf2-core: don't call memop 'finish' when queueing
  gspca: convert to vb2
  gspca: fix g/s_parm handling
  v4l2-ioctl: clear fields in s_parm
  v4l2-ioctl: delete unused v4l2_disable_ioctl_locking

 .../media/common/videobuf2/videobuf2-core.c   |   9 +-
 drivers/media/usb/gspca/Kconfig   |   1 +
 drivers/media/usb/gspca/gspca.c   | 931 --
 drivers/media/usb/gspca/gspca.h   |  38 +-
 drivers/media/usb/gspca/m5602/m5602_core.c|   4 +-
 drivers/media/usb/gspca/ov534.c   |   1 -
 drivers/media/usb/gspca/topro.c   |   1 -
 drivers/media/usb/gspca/vc032x.c  |   2 +-
 drivers/media/v4l2-core/v4l2-ioctl.c  |  19 +-
 include/media/v4l2-dev.h  |  15 -
 10 files changed, 218 insertions(+), 803 deletions(-)

-- 
2.17.0

[PATCHv3 1/5] videobuf2-core: don't call memop 'finish' when queueing

[Hans Verkuil]

From: Hans Verkuil 

When a buffer is queued or requeued in vb2_buffer_done, then don't
call the finish memop. In this case the buffer is only returned to vb2,
not to userspace.

Calling 'finish' here will cause an unbalance when the queue is
canceled, since the core will call the same memop again.

Signed-off-by: Hans Verkuil 
---
 drivers/media/common/videobuf2/videobuf2-core.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index d3f7bb33a54d..f32ec7342ef0 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -916,9 +916,12 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
dprintk(4, "done processing on buffer %d, state: %d\n",
vb->index, state);
 
-   /* sync buffers */
-   for (plane = 0; plane < vb->num_planes; ++plane)
-   call_void_memop(vb, finish, vb->planes[plane].mem_priv);
+   if (state != VB2_BUF_STATE_QUEUED &&
+   state != VB2_BUF_STATE_REQUEUEING) {
+   /* sync buffers */
+   for (plane = 0; plane < vb->num_planes; ++plane)
+   call_void_memop(vb, finish, vb->planes[plane].mem_priv);
+   }
 
spin_lock_irqsave(>done_lock, flags);
if (state == VB2_BUF_STATE_QUEUED ||
-- 
2.17.0

[PATCHv3 5/5] v4l2-ioctl: delete unused v4l2_disable_ioctl_locking

[Hans Verkuil]

From: Hans Verkuil 

The last user of this 'feature' was the gspca driver. Now that
that driver has been converted to vb2 we can delete this code.

Signed-off-by: Hans Verkuil 
Reviewed-by: Hans de Goede 
---
 drivers/media/v4l2-core/v4l2-ioctl.c |  2 --
 include/media/v4l2-dev.h | 15 ---
 2 files changed, 17 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 212aac1d22c1..c23fbfe90a9e 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2666,8 +2666,6 @@ struct mutex *v4l2_ioctl_get_lock(struct video_device 
*vdev, unsigned cmd)
 {
if (_IOC_NR(cmd) >= V4L2_IOCTLS)
return vdev->lock;
-   if (test_bit(_IOC_NR(cmd), vdev->disable_locking))
-   return NULL;
if (vdev->queue && vdev->queue->lock &&
(v4l2_ioctls[_IOC_NR(cmd)].flags & INFO_FL_QUEUE))
return vdev->queue->lock;
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 73073f6ee48c..30423aefe7c5 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -238,7 +238,6 @@ struct v4l2_file_operations {
  * @ioctl_ops: pointer to  v4l2_ioctl_ops with ioctl callbacks
  *
  * @valid_ioctls: bitmap with the valid ioctls for this device
- * @disable_locking: bitmap with the ioctls that don't require locking
  * @lock: pointer to  mutex serialization lock
  *
  * .. note::
@@ -291,7 +290,6 @@ struct video_device
const struct v4l2_ioctl_ops *ioctl_ops;
DECLARE_BITMAP(valid_ioctls, BASE_VIDIOC_PRIVATE);
 
-   DECLARE_BITMAP(disable_locking, BASE_VIDIOC_PRIVATE);
struct mutex *lock;
 };
 
@@ -446,19 +444,6 @@ void video_device_release_empty(struct video_device *vdev);
  */
 bool v4l2_is_known_ioctl(unsigned int cmd);
 
-/** v4l2_disable_ioctl_locking - mark that a given command
- * shouldn't use core locking
- *
- * @vdev: pointer to  video_device
- * @cmd: ioctl command
- */
-static inline void v4l2_disable_ioctl_locking(struct video_device *vdev,
- unsigned int cmd)
-{
-   if (_IOC_NR(cmd) < BASE_VIDIOC_PRIVATE)
-   set_bit(_IOC_NR(cmd), vdev->disable_locking);
-}
-
 /**
  * v4l2_disable_ioctl- mark that a given command isn't implemented.
  * shouldn't use core locking
-- 
2.17.0