Re: [PATCH] media: ov13858: select V4L2_FWNODE

[Sakari Ailus]

On Tue, Nov 28, 2017 at 11:38:00AM +0100, Arnd Bergmann wrote:
> v4l2_async_register_subdev_sensor_common() is only provided when
> CONFIG_V4L2_FWNODE is enabled, otherwise we get a link failure:
> 
> drivers/media/i2c/ov13858.o: In function `ov13858_probe':
> ov13858.c:(.text+0xf74): undefined reference to 
> `v4l2_async_register_subdev_sensor_common'
> 
> This adds a Kconfig 'select' statement like all the other users of
> this interface have.
> 
> Fixes: 2e8a9fbb7950 ("media: ov13858: Add support for flash and lens devices")
> Signed-off-by: Arnd Bergmann 
> ---
> This is the same patch I submitted for et8ek8 earlier. Both
> are needed for 4.15.

Hi Arnd,

Thanks for the patch. There's already a patch with the same change queued
up, so I'll use that instead.

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

Re: [PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

[Mauro Carvalho Chehab]

Em Wed, 22 Nov 2017 13:17:14 +0900
"Takiguchi, Yasunari"  escreveu:

Hi Takiguchi-san,

> Hi, all
> 
> I sent the patch series of Sony CXD2880 DVB-T2/T tuner + demodulator driver 
> version 4 on 13th/Oct.
> I'd like to get better understanding of current review status for our codes.
> 
> Are there any comments, advices and review results for them?

October was a month crowded of trips for everybody. I had some trips in
November too, and a merge window to take care of, with ended by delaying
patch reviews. We didn't even had the time yet to finish the summit report.
Anyway, now Sean and Michael are helping with DVB patch review. 

Michael/Sean, could you please take a look on this patch series?

I'll try to take a look on it myself next week.

Thanks,
Mauro

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 Nov 29 05:00:19 CET 2017
media-tree git hash:04226916d2360f56d57ad00bc48d2d1854d1e0b0
media_build git hash:   320b9b80ebbf318a67a9479c18a0e4be244c8409
v4l-utils git hash: 45722ce368eec47123e3e7a16bdeeb50dadcc00a
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: 0.5.1 (Debian: 0.5.1-2)
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.13.0-164

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

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 v2 1/3] media: staging: atomisp: fix for sparse "using plain integer as NULL pointer" warnings.

[Dan Carpenter]

On Tue, Nov 28, 2017 at 11:33:37PM +, Jeremy Sowden wrote:
> On 2017-11-28, at 17:15:24 +0300, Dan Carpenter wrote:
> > On Mon, Nov 27, 2017 at 12:44:48PM +, Jeremy Sowden wrote:
> > > The "address" member of struct ia_css_host_data is a
> > > pointer-to-char, so define default as NULL.
> > >
> > > --- 
> > > a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
> > > +++ 
> > > b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
> > > @@ -95,7 +95,7 @@ union ia_css_all_memory_offsets {
> > >  };
> > >
> > >  #define IA_CSS_DEFAULT_ISP_MEM_PARAMS \
> > > - { { { { 0, 0 } } } }
> > > + { { { { NULL, 0 } } } }
> >
> > This define is way ugly and instead of making superficial changes, you
> > should try to eliminate it.
> >
> > People look at warnings as a bad thing but they are actually a
> > valuable resource which call attention to bad code.  By making this
> > change you're kind of wasting the warning.  The bad code is still
> > there, it's just swept under the rug but like a dead mouse carcass
> > it's still stinking up the living room.  We should leave the warning
> > there until it irritates someone enough to fix it properly.
> 
> Tracking down the offending initializer was definitely a pain.
> 
> Compound literals with designated initializers would make this macro
> (and a number of others) easier to understand and more type-safe:
> 
>#define IA_CSS_DEFAULT_ISP_MEM_PARAMS \
>   -   { { { { 0, 0 } } } }
>   +   (struct ia_css_isp_param_host_segments) { \
>   +   .params = { { \
>   +   (struct ia_css_host_data) { \
>   +   .address = NULL, \
>   +   .size = 0 \
>   +   } \
>   +   } } \
>   +   }

Using designated initializers is good, yes.  Can't we just use an
empty initializer since this is all zeroed memory anyway?

(struct ia_css_isp_param_host_segments) { }

I haven't tried it.

> 
> Unfortunately this default value is one end of a chain of default values


Yeah.  A really long chain...


> used to initialize members of default values of enclosing structs where
> the outermost values are used to initialize some static variables:
> 
>   static enum ia_css_err
>   init_pipe_defaults(enum ia_css_pipe_mode mode,
>struct ia_css_pipe *pipe,
>bool copy_pipe)
>   {
> static struct ia_css_pipe default_pipe = IA_CSS_DEFAULT_PIPE;
> static struct ia_css_preview_settings prev  = 
> IA_CSS_DEFAULT_PREVIEW_SETTINGS;
> static struct ia_css_capture_settings capt  = 
> IA_CSS_DEFAULT_CAPTURE_SETTINGS;
> static struct ia_css_video_settings   video = 
> IA_CSS_DEFAULT_VIDEO_SETTINGS;
> static struct ia_css_yuvpp_settings   yuvpp = 
> IA_CSS_DEFAULT_YUVPP_SETTINGS;
> 
> if (pipe == NULL) {
>   IA_CSS_ERROR("NULL pipe parameter");
>   return IA_CSS_ERR_INVALID_ARGUMENTS;
> }
> 
> /* Initialize pipe to pre-defined defaults */
> *pipe = default_pipe;
> 
> /* TODO: JB should not be needed, but temporary backward reference */
> switch (mode) {
> case IA_CSS_PIPE_MODE_PREVIEW:
>   pipe->mode = IA_CSS_PIPE_ID_PREVIEW;
>   pipe->pipe_settings.preview = prev;
>   break;
> case IA_CSS_PIPE_MODE_CAPTURE:
>   if (copy_pipe) {
>   pipe->mode = IA_CSS_PIPE_ID_COPY;
>   } else {
>   pipe->mode = IA_CSS_PIPE_ID_CAPTURE;
>   }
>   pipe->pipe_settings.capture = capt;
>   break;
> case IA_CSS_PIPE_MODE_VIDEO:
>   pipe->mode = IA_CSS_PIPE_ID_VIDEO;
>   pipe->pipe_settings.video = video;
>   break;
> case IA_CSS_PIPE_MODE_ACC:
>   pipe->mode = IA_CSS_PIPE_ID_ACC;
>   break;
> case IA_CSS_PIPE_MODE_COPY:
>   pipe->mode = IA_CSS_PIPE_ID_CAPTURE;
>   break;
> case IA_CSS_PIPE_MODE_YUVPP:
>   pipe->mode = IA_CSS_PIPE_ID_YUVPP;
>   pipe->pipe_settings.yuvpp = yuvpp;
>   break;
> default:
>   return IA_CSS_ERR_INVALID_ARGUMENTS;
> }
> 
> return IA_CSS_SUCCESS;
>   }
> 
> and GCC's limited support for using compound literals to initialize
> static variables doesn't stretch this far.
> 
> I'm not convinced, however, that those variables actually achieve very
> much.  If I change the code to assign the defaults directly, the problem
> goes away:
> 
>   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 f92b6a9f77eb..671b2c732a46 100644
>   --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
>   +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
>   @@ -2291,25 +2291,19 @@ init_pipe_defaults(enum ia_css_pipe_mode mode,
>struct ia_css_pipe *pipe,
>bool copy_pipe)
>{
>   -   static struct ia_css_pipe default_pipe = IA_CSS_DEFAULT_PIPE;

Re: [PATCH v2 1/3] media: staging: atomisp: fix for sparse "using plain integer as NULL pointer" warnings.

[Jeremy Sowden]

On 2017-11-28, at 17:15:24 +0300, Dan Carpenter wrote:
> On Mon, Nov 27, 2017 at 12:44:48PM +, Jeremy Sowden wrote:
> > The "address" member of struct ia_css_host_data is a
> > pointer-to-char, so define default as NULL.
> >
> > --- 
> > a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
> > +++ 
> > b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
> > @@ -95,7 +95,7 @@ union ia_css_all_memory_offsets {
> >  };
> >
> >  #define IA_CSS_DEFAULT_ISP_MEM_PARAMS \
> > -   { { { { 0, 0 } } } }
> > +   { { { { NULL, 0 } } } }
>
> This define is way ugly and instead of making superficial changes, you
> should try to eliminate it.
>
> People look at warnings as a bad thing but they are actually a
> valuable resource which call attention to bad code.  By making this
> change you're kind of wasting the warning.  The bad code is still
> there, it's just swept under the rug but like a dead mouse carcass
> it's still stinking up the living room.  We should leave the warning
> there until it irritates someone enough to fix it properly.

Tracking down the offending initializer was definitely a pain.

Compound literals with designated initializers would make this macro
(and a number of others) easier to understand and more type-safe:

   #define IA_CSS_DEFAULT_ISP_MEM_PARAMS \
  - { { { { 0, 0 } } } }
  + (struct ia_css_isp_param_host_segments) { \
  + .params = { { \
  + (struct ia_css_host_data) { \
  + .address = NULL, \
  + .size = 0 \
  + } \
  + } } \
  + }

Unfortunately this default value is one end of a chain of default values
used to initialize members of default values of enclosing structs where
the outermost values are used to initialize some static variables:

  static enum ia_css_err
  init_pipe_defaults(enum ia_css_pipe_mode mode,
 struct ia_css_pipe *pipe,
 bool copy_pipe)
  {
static struct ia_css_pipe default_pipe = IA_CSS_DEFAULT_PIPE;
static struct ia_css_preview_settings prev  = 
IA_CSS_DEFAULT_PREVIEW_SETTINGS;
static struct ia_css_capture_settings capt  = 
IA_CSS_DEFAULT_CAPTURE_SETTINGS;
static struct ia_css_video_settings   video = IA_CSS_DEFAULT_VIDEO_SETTINGS;
static struct ia_css_yuvpp_settings   yuvpp = IA_CSS_DEFAULT_YUVPP_SETTINGS;

if (pipe == NULL) {
  IA_CSS_ERROR("NULL pipe parameter");
  return IA_CSS_ERR_INVALID_ARGUMENTS;
}

/* Initialize pipe to pre-defined defaults */
*pipe = default_pipe;

/* TODO: JB should not be needed, but temporary backward reference */
switch (mode) {
case IA_CSS_PIPE_MODE_PREVIEW:
  pipe->mode = IA_CSS_PIPE_ID_PREVIEW;
  pipe->pipe_settings.preview = prev;
  break;
case IA_CSS_PIPE_MODE_CAPTURE:
  if (copy_pipe) {
pipe->mode = IA_CSS_PIPE_ID_COPY;
  } else {
pipe->mode = IA_CSS_PIPE_ID_CAPTURE;
  }
  pipe->pipe_settings.capture = capt;
  break;
case IA_CSS_PIPE_MODE_VIDEO:
  pipe->mode = IA_CSS_PIPE_ID_VIDEO;
  pipe->pipe_settings.video = video;
  break;
case IA_CSS_PIPE_MODE_ACC:
  pipe->mode = IA_CSS_PIPE_ID_ACC;
  break;
case IA_CSS_PIPE_MODE_COPY:
  pipe->mode = IA_CSS_PIPE_ID_CAPTURE;
  break;
case IA_CSS_PIPE_MODE_YUVPP:
  pipe->mode = IA_CSS_PIPE_ID_YUVPP;
  pipe->pipe_settings.yuvpp = yuvpp;
  break;
default:
  return IA_CSS_ERR_INVALID_ARGUMENTS;
}

return IA_CSS_SUCCESS;
  }

and GCC's limited support for using compound literals to initialize
static variables doesn't stretch this far.

I'm not convinced, however, that those variables actually achieve very
much.  If I change the code to assign the defaults directly, the problem
goes away:

  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 f92b6a9f77eb..671b2c732a46 100644
  --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
  +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
  @@ -2291,25 +2291,19 @@ init_pipe_defaults(enum ia_css_pipe_mode mode,
 struct ia_css_pipe *pipe,
 bool copy_pipe)
   {
  -   static struct ia_css_pipe default_pipe = IA_CSS_DEFAULT_PIPE;
  -   static struct ia_css_preview_settings prev  = 
IA_CSS_DEFAULT_PREVIEW_SETTINGS;
  -   static struct ia_css_capture_settings capt  = 
IA_CSS_DEFAULT_CAPTURE_SETTINGS;
  -   static struct ia_css_video_settings   video = 
IA_CSS_DEFAULT_VIDEO_SETTINGS;
  -   static struct ia_css_yuvpp_settings   yuvpp = 
IA_CSS_DEFAULT_YUVPP_SETTINGS;
  -
  if (pipe == NULL) {
  IA_CSS_ERROR("NULL pipe parameter");
  return IA_CSS_ERR_INVALID_ARGUMENTS;
   

[PATCHv2 1/4] staging: add missing blank line after declarations in atomisp-ov5693

[Riccardo Schirone]

Fix "Missing a blank line after declarations" warning reported by
checkpatch.

Signed-off-by: Riccardo Schirone 
---
 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c 
b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
index 3e7c3851280f..387c65be10f4 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
@@ -82,6 +82,7 @@ static int ad5823_i2c_write(struct i2c_client *client, u8 
reg, u8 val)
 {
struct i2c_msg msg;
u8 buf[2];
+
buf[0] = reg;
buf[1] = val;
msg.addr = AD5823_VCM_ADDR;
@@ -98,6 +99,7 @@ static int ad5823_i2c_read(struct i2c_client *client, u8 reg, 
u8 *val)
 {
struct i2c_msg msg[2];
u8 buf[2];
+
buf[0] = reg;
buf[1] = 0;
 
@@ -228,6 +230,7 @@ static int vcm_detect(struct i2c_client *client)
int i, ret;
struct i2c_msg msg;
u16 data0 = 0, data;
+
for (i = 0; i < 4; i++) {
msg.addr = VCM_ADDR;
msg.flags = I2C_M_RD;
@@ -690,6 +693,7 @@ static long ov5693_s_exposure(struct v4l2_subdev *sd,
/* we should not accept the invalid value below */
if (analog_gain == 0) {
struct i2c_client *client = v4l2_get_subdevdata(sd);
+
v4l2_err(client, "%s: invalid value\n", __func__);
return -EINVAL;
}
@@ -722,6 +726,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8 
*buf)
int ret;
int i;
u8 *b = buf;
+
dev->otp_size = 0;
for (i = 1; i < OV5693_OTP_BANK_MAX; i++) {
/*set bank NO and OTP read mode. */
@@ -984,6 +989,7 @@ static int ov5693_t_focus_abs(struct v4l2_subdev *sd, s32 
value)
 static int ov5693_t_focus_rel(struct v4l2_subdev *sd, s32 value)
 {
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
return ov5693_t_focus_abs(sd, dev->focus + value);
 }
 
@@ -1033,6 +1039,7 @@ static int ov5693_q_focus_abs(struct v4l2_subdev *sd, s32 
*value)
 static int ov5693_t_vcm_slew(struct v4l2_subdev *sd, s32 value)
 {
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
dev->number_of_steps = value;
dev->vcm_update = true;
return 0;
@@ -1041,6 +1048,7 @@ static int ov5693_t_vcm_slew(struct v4l2_subdev *sd, s32 
value)
 static int ov5693_t_vcm_timing(struct v4l2_subdev *sd, s32 value)
 {
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
dev->number_of_steps = value;
dev->vcm_update = true;
return 0;
@@ -1563,6 +1571,7 @@ static int ov5693_set_fmt(struct v4l2_subdev *sd,
struct camera_mipi_info *ov5693_info = NULL;
int ret = 0;
int idx;
+
if (format->pad)
return -EINVAL;
if (!fmt)
@@ -1599,6 +1608,7 @@ static int ov5693_set_fmt(struct v4l2_subdev *sd,
ret = startup(sd);
if (ret) {
int i = 0;
+
dev_err(>dev, "ov5693 startup err, retry to power 
up\n");
for (i = 0; i < OV5693_POWER_UP_RETRY_NUM; i++) {
dev_err(>dev,
@@ -1655,6 +1665,7 @@ static int ov5693_get_fmt(struct v4l2_subdev *sd,
 {
struct v4l2_mbus_framefmt *fmt = >format;
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
if (format->pad)
return -EINVAL;
 
@@ -1818,6 +1829,7 @@ static int ov5693_s_parm(struct v4l2_subdev *sd,
struct v4l2_streamparm *param)
 {
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
dev->run_mode = param->parm.capture.capturemode;
 
mutex_lock(>input_lock);
@@ -1907,6 +1919,7 @@ static int ov5693_remove(struct i2c_client *client)
 {
struct v4l2_subdev *sd = i2c_get_clientdata(client);
struct ov5693_device *dev = to_ov5693_sensor(sd);
+
dev_dbg(>dev, "ov5693_remove...\n");
 
dev->platform_data->csi_cfg(sd, 0);
-- 
2.14.3

[PATCHv2 0/4] fix some checkpatch style issues in atomisp driver

[Riccardo Schirone]

This patch series fixes some coding style issues in atomisp driver
reported by checkpatch, like: missing blank lines after declarations,
comments style, comparisons and indentation.

It is based on next-20171128.

Changes since v1:
 - Add commit message to first patch as reported by Jacopo Mondi
   <jac...@jmondi.org>

Riccardo Schirone (4):
  staging: add missing blank line after declarations in atomisp-ov5693
  staging: improve comments usage in atomisp-ov5693
  staging: improves comparisons readability in atomisp-ov5693
  staging: fix indentation in atomisp-ov5693

 .../media/atomisp/i2c/ov5693/atomisp-ov5693.c  | 63 +++---
 1 file changed, 44 insertions(+), 19 deletions(-)

-- 
2.14.3

[PATCHv2 4/4] staging: fix indentation in atomisp-ov5693

[Riccardo Schirone]

Fix "suspect code indent for conditional statements" checkpatch issue

Signed-off-by: Riccardo Schirone 
---
 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c 
b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
index 4eeb478ae84b..6eb6afdc730e 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
@@ -776,7 +776,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8 
*buf)
if ((*b) == 0) {
dev->otp_size = 32;
break;
-   } else {
+   } else {
b = buf;
continue;
}
-- 
2.14.3

[PATCHv2 2/4] staging: improve comments usage in atomisp-ov5693

[Riccardo Schirone]

- Fix "Block comments use a trailing */ on a separate line" checkpatch
  issue
- Fix "Block comments use * on subsequent lines" checkpatch issue

Signed-off-by: Riccardo Schirone 
---
 .../media/atomisp/i2c/ov5693/atomisp-ov5693.c  | 38 ++
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c 
b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
index 387c65be10f4..ecd607b7b005 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
@@ -213,7 +213,8 @@ static int vcm_dw_i2c_write(struct i2c_client *client, u16 
data)
return ret == num_msg ? 0 : -EIO;
 }
 
-/* Theory: per datasheet, the two VCMs both allow for a 2-byte read.
+/*
+ * Theory: per datasheet, the two VCMs both allow for a 2-byte read.
  * The DW9714 doesn't actually specify what this does (it has a
  * two-byte write-only protocol, but specifies the read sequence as
  * legal), but it returns the same data (zeroes) always, after an
@@ -224,7 +225,8 @@ static int vcm_dw_i2c_write(struct i2c_client *client, u16 
data)
  * these) in AD5823 are not pairwise repetitions of the same 16 bit
  * word.  So all we have to do is sequentially read two bytes at a
  * time and see if we detect a difference in any of the first four
- * pairs.  */
+ * pairs.
+ */
 static int vcm_detect(struct i2c_client *client)
 {
int i, ret;
@@ -238,8 +240,10 @@ static int vcm_detect(struct i2c_client *client)
msg.buf = (u8 *)
ret = i2c_transfer(client->adapter, , 1);
 
-   /* DW9714 always fails the first read and returns
-* zeroes for subsequent ones */
+   /*
+* DW9714 always fails the first read and returns
+* zeroes for subsequent ones
+*/
if (i == 0 && ret == -EREMOTEIO) {
data0 = 0;
continue;
@@ -533,9 +537,11 @@ static long __ov5693_set_exposure(struct v4l2_subdev *sd, 
int coarse_itg,
 
hts = ov5693_res[dev->fmt_idx].pixels_per_line;
vts = ov5693_res[dev->fmt_idx].lines_per_frame;
-   /*If coarse_itg is larger than 1<<15, can not write to reg directly.
- The way is to write coarse_itg/2 to the reg, meanwhile write 2*hts
- to the reg. */
+   /*
+* If coarse_itg is larger than 1<<15, can not write to reg directly.
+* The way is to write coarse_itg/2 to the reg, meanwhile write 2*hts
+* to the reg.
+*/
if (coarse_itg > (1 << 15)) {
hts = hts * 2;
coarse_itg = (int)coarse_itg / 2;
@@ -880,8 +886,10 @@ static long ov5693_ioctl(struct v4l2_subdev *sd, unsigned 
int cmd, void *arg)
return 0;
 }
 
-/* This returns the exposure time being used. This should only be used
-   for filling in EXIF data, not for actual image processing. */
+/*
+ * This returns the exposure time being used. This should only be used
+ * for filling in EXIF data, not for actual image processing.
+ */
 static int ov5693_q_exposure(struct v4l2_subdev *sd, s32 *value)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -1301,11 +1309,13 @@ static int power_ctrl(struct v4l2_subdev *sd, bool flag)
if (!dev || !dev->platform_data)
return -ENODEV;
 
-   /* This driver assumes "internal DVDD, PWDNB tied to DOVDD".
+   /*
+* This driver assumes "internal DVDD, PWDNB tied to DOVDD".
 * In this set up only gpio0 (XSHUTDN) should be available
 * but in some products (for example ECS) gpio1 (PWDNB) is
 * also available. If gpio1 is available we emulate it being
-* tied to DOVDD here. */
+* tied to DOVDD here.
+*/
if (flag) {
ret = dev->platform_data->v2p8_ctrl(sd, 1);
dev->platform_data->gpio1_ctrl(sd, 1);
@@ -1944,10 +1954,12 @@ static int ov5693_probe(struct i2c_client *client)
struct acpi_device *adev;
unsigned int i;
 
-   /* Firmware workaround: Some modules use a "secondary default"
+   /*
+* Firmware workaround: Some modules use a "secondary default"
 * address of 0x10 which doesn't appear on schematics, and
 * some BIOS versions haven't gotten the memo.  Work around
-* via config. */
+* via config.
+*/
i2c = gmin_get_var_int(>dev, "I2CAddr", -1);
if (i2c != -1) {
dev_info(>dev,
-- 
2.14.3

[PATCHv2 3/4] staging: improves comparisons readability in atomisp-ov5693

[Riccardo Schirone]

Fix "Comparisons should place the constant on the right side of the
test" checkpatch issue.

Signed-off-by: Riccardo Schirone 
---
 drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c 
b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
index ecd607b7b005..4eeb478ae84b 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
@@ -764,7 +764,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8 
*buf)
//pr_debug("BANK[%2d] %02x %02x %02x %02x %02x %02x %02x %02x 
%02x %02x %02x %02x %02x %02x %02x %02x\n", i, *b, *(b+1), *(b+2), *(b+3), 
*(b+4), *(b+5), *(b+6), *(b+7), *(b+8), *(b+9), *(b+10), *(b+11), *(b+12), 
*(b+13), *(b+14), *(b+15));
 
//Intel OTP map, try to read 320byts first.
-   if (21 == i) {
+   if (i == 21) {
if ((*b) == 0) {
dev->otp_size = 320;
break;
@@ -772,7 +772,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8 
*buf)
b = buf;
continue;
}
-   } else if (24 == i) {   //if the first 320bytes data 
doesn't not exist, try to read the next 32bytes data.
+   } else if (i == 24) {   //if the first 320bytes data 
doesn't not exist, try to read the next 32bytes data.
if ((*b) == 0) {
dev->otp_size = 32;
break;
@@ -780,7 +780,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8 
*buf)
b = buf;
continue;
}
-   } else if (27 == i) {   //if the prvious 32bytes data 
doesn't exist, try to read the next 32bytes data again.
+   } else if (i == 27) {   //if the prvious 32bytes data 
doesn't exist, try to read the next 32bytes data again.
if ((*b) == 0) {
dev->otp_size = 32;
break;
@@ -1351,7 +1351,7 @@ static int __power_up(struct v4l2_subdev *sd)
struct i2c_client *client = v4l2_get_subdevdata(sd);
int ret;
 
-   if (NULL == dev->platform_data) {
+   if (!dev->platform_data) {
dev_err(>dev,
"no camera_sensor_platform_data");
return -ENODEV;
@@ -1399,7 +1399,7 @@ static int power_down(struct v4l2_subdev *sd)
int ret = 0;
 
dev->focus = OV5693_INVALID_CONFIG;
-   if (NULL == dev->platform_data) {
+   if (!dev->platform_data) {
dev_err(>dev,
"no camera_sensor_platform_data");
return -ENODEV;
-- 
2.14.3

Re: [GIT PULL] SAA716x DVB driver

[Mauro Carvalho Chehab]

Em Mon, 25 Sep 2017 00:17:00 +0200
Soeren Moch  escreveu:

> >  What I'm saying is that,
> > if we're adding it on staging, we need to have a plan to reimplement
> > it to whatever API replaces the DVB video API, as this API likely
> > won't stay upstream much longer.  
> AFAIK it is not usual linux policy to remove existing drivers
> with happy users and even someone who volunteered to
> maintain this.

The usual Linux policy doesn't apply to staging. The goal of staging is
to add drivers that have problems, but are fixable, and whose someone
is working to solve those issues. 

The staging policies include adding a TODO file describing the problems
that should be solved for the driver to be promoted. If such problems
aren't solved, the driver can be removed.

For example, this year, we removed some lirc staging drivers because
no developers were interested (and/or had the hardware) to convert
them to use the RC core (with is a Kernel's internal API).

In the case of saa716x, the issue is that it uses a deprecated
and undocumented userspace API, with is a way more serious issue.

I'm ok to add this driver to staging if we can agree on what
should be fixed, and if someone commits to try fixing it, knowing,
in advance, that, if it doesn't get fixed on a reasonable time, it
can be removed on later Kernel versions.

Thanks,
Mauro

[PATCH Resend] staging: media: lirc: style fix - replace hard-coded function names

[Martin Homuth]

This patch fixes the remaining coding style warnings in the lirc module.
Instead of hard coding the function name the __func__ variable
should be used.

It fixes the following checkpatch.pl warning:

WARNING: Prefer using '"%s...", __func__' to using 'read', this
function's name, in a string

Signed-off-by: Martin Homuth 
---
 drivers/staging/media/lirc/lirc_zilog.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
index 6bd0717bf76e..be68ee652071 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -888,9 +888,9 @@ static ssize_t read(struct file *filep, char __user
*outbuf, size_t n,
unsigned int m;
DECLARE_WAITQUEUE(wait, current);

-   dev_dbg(ir->dev, "read called\n");
+   dev_dbg(ir->dev, "%s called\n", __func__);
if (n % rbuf->chunk_size) {
-   dev_dbg(ir->dev, "read result = -EINVAL\n");
+   dev_dbg(ir->dev, "%s result = -EINVAL\n", __func__);
return -EINVAL;
}

@@ -949,7 +949,7 @@ static ssize_t read(struct file *filep, char __user
*outbuf, size_t n,
retries++;
}
if (retries >= 5) {
-   dev_err(ir->dev, "Buffer read failed!\n");
+   dev_err(ir->dev, "%s failed!\n", __func__);
ret = -EIO;
}
}
@@ -959,7 +959,7 @@ static ssize_t read(struct file *filep, char __user
*outbuf, size_t n,
put_ir_rx(rx, false);
set_current_state(TASK_RUNNING);

-   dev_dbg(ir->dev, "read result = %d (%s)\n", ret,
+   dev_dbg(ir->dev, "%s result = %d (%s)\n", __func__, ret,
ret ? "Error" : "OK");

return ret ? ret : written;
-- 
2.13.6

Re: [PATCH 2/3 v7] uvcvideo: add extensible device information

[Guennadi Liakhovetski]

Hi Laurent,

Thanks for reviewing.

On Tue, 28 Nov 2017, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> Thank you for the patch.
> 
> On Wednesday, 8 November 2017 18:00:13 EET Guennadi Liakhovetski wrote:
> > From: Guennadi Liakhovetski 
> > 
> > Currently the UVC driver assigns a quirk bitmask to the .driver_info
> > field of struct usb_device_id. This patch instroduces a struct to store
> > quirks and possibly other per-device parameters in the future.
> 
> I'd drop the "possibly" as I'm fairly certain we will have other parameters 
> in 
> the future. Otherwise the patch would be a bit pointless :-)
> 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> > 
> > v7: this is a new patch in the series. Needed to enable specifying
> > private camera metadata formats
> > 
> >  drivers/media/usb/uvc/uvc_driver.c | 127 --
> >  1 file changed, 78 insertions(+), 49 deletions(-)
> > 
> > diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > b/drivers/media/usb/uvc/uvc_driver.c index 6d22b22..cbf79b9 100644
> > --- a/drivers/media/usb/uvc/uvc_driver.c
> > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > @@ -2001,11 +2001,18 @@ static int uvc_register_chains(struct uvc_device
> > *dev) * USB probe, disconnect, suspend and resume
> >   */
> > 
> > +struct uvc_device_info {
> > +   u32 quirks;
> > +};
> > +
> >  static int uvc_probe(struct usb_interface *intf,
> >  const struct usb_device_id *id)
> >  {
> > struct usb_device *udev = interface_to_usbdev(intf);
> > struct uvc_device *dev;
> > +   const struct uvc_device_info *info =
> > +   (const struct uvc_device_info *)id->driver_info;
> > +   u32 quirks = info ? info->quirks : 0;
> > int function;
> > int ret;
> > 
> > @@ -2032,7 +2039,7 @@ static int uvc_probe(struct usb_interface *intf,
> > dev->intf = usb_get_intf(intf);
> > dev->intfnum = intf->cur_altsetting->desc.bInterfaceNumber;
> > dev->quirks = (uvc_quirks_param == -1)
> > -   ? id->driver_info : uvc_quirks_param;
> > +   ? quirks : uvc_quirks_param;
> > 
> > if (udev->product != NULL)
> > strlcpy(dev->name, udev->product, sizeof dev->name);
> > @@ -2073,7 +2080,7 @@ static int uvc_probe(struct usb_interface *intf,
> > le16_to_cpu(udev->descriptor.idVendor),
> > le16_to_cpu(udev->descriptor.idProduct));
> > 
> > -   if (dev->quirks != id->driver_info) {
> > +   if (dev->quirks != quirks) {
> > uvc_printk(KERN_INFO, "Forcing device quirks to 0x%x by module "
> > "parameter for testing purpose.\n", dev->quirks);
> > uvc_printk(KERN_INFO, "Please report required quirks to the "
> > @@ -2271,6 +2278,28 @@ static int uvc_clock_param_set(const char *val,
> > struct kernel_param *kp) * Driver initialization and cleanup
> >   */
> > 
> > +static struct uvc_device_info uvc_quirk_probe_minmax = {
> > +   .quirks = UVC_QUIRK_PROBE_MINMAX,
> > +};
> > +
> > +static struct uvc_device_info uvc_quirk_fix_bandwidth = {
> > +   .quirks = UVC_QUIRK_FIX_BANDWIDTH,
> > +};
> > +
> > +static struct uvc_device_info uvc_quirk_probe_def = {
> > +   .quirks = UVC_QUIRK_PROBE_DEF,
> > +};
> > +
> > +static struct uvc_device_info uvc_quirk_stream_no_fid = {
> > +   .quirks = UVC_QUIRK_STREAM_NO_FID,
> > +};
> > +
> > +static struct uvc_device_info uvc_quirk_force_y8 = {
> > +   .quirks = UVC_QUIRK_FORCE_Y8,
> > +};
> 
> You can make all of these static const.
> 
> > +#define UVC_QUIRK_INFO(q) (kernel_ulong_t)&(struct uvc_device_info){.quirks
> > = q}
> > +
> >  /*
> >   * The Logitech cameras listed below have their interface class set to
> >   * VENDOR_SPEC because they don't announce themselves as UVC devices, even
> > @@ -2285,7 +2314,7 @@ static int uvc_clock_param_set(const char *val, struct
> > kernel_param *kp) .bInterfaceClass  = USB_CLASS_VIDEO,
> >   .bInterfaceSubClass   = 1,
> >   .bInterfaceProtocol   = 0,
> > - .driver_info  = UVC_QUIRK_PROBE_MINMAX },
> > + .driver_info  = (kernel_ulong_t)_quirk_probe_minmax },
> > /* Genius eFace 2025 */
> > { .match_flags  = USB_DEVICE_ID_MATCH_DEVICE
> > 
> > | USB_DEVICE_ID_MATCH_INT_INFO,
> > 
> > @@ -2294,7 +2323,7 @@ static int uvc_clock_param_set(const char *val, struct
> > kernel_param *kp) .bInterfaceClass  = USB_CLASS_VIDEO,
> >   .bInterfaceSubClass   = 1,
> >   .bInterfaceProtocol   = 0,
> > - .driver_info  = UVC_QUIRK_PROBE_MINMAX },
> > + .driver_info  = (kernel_ulong_t)_quirk_probe_minmax },
> > /* Microsoft Lifecam NX-6000 */
> > { .match_flags  = USB_DEVICE_ID_MATCH_DEVICE
> > 
> > | USB_DEVICE_ID_MATCH_INT_INFO,
> > 
> > @@ -2303,7 +2332,7 @@ static int uvc_clock_param_set(const char *val, struct
> > kernel_param *kp) .bInterfaceClass  = USB_CLASS_VIDEO,
> >   

Re: [PATCH v1 3/4] media: ov5640: add support of DVP parallel interface

[Hugues FRUCHET]

Thanks Sakari for review,

On 11/24/2017 03:06 PM, Sakari Ailus wrote:
> Hi Hugues,
> 
> On Thu, Nov 16, 2017 at 02:41:41PM +0100, Hugues Fruchet wrote:
>> @@ -2185,7 +2262,11 @@ static int ov5640_s_stream(struct v4l2_subdev *sd, 
>> int enable)
>>  goto out;
>>  }
>>   
>> -ret = ov5640_set_stream(sensor, enable);
>> +if (sensor->ep.bus_type == V4L2_MBUS_CSI2)
>> +ret = ov5640_set_stream_mipi(sensor, enable);
>> +else
>> +ret = ov5640_set_stream_dvp(sensor);
> 
> Hmm. Do you want to configure it even when you're disabling streaming?
> 
I will fix this by only setting stream when enabling streaming.

Best regards,
Hugues.

Re: [PATCH 2/3 v7] uvcvideo: add extensible device information

[Laurent Pinchart]

Hi Guennadi,

Thank you for the patch.

On Wednesday, 8 November 2017 18:00:13 EET Guennadi Liakhovetski wrote:
> From: Guennadi Liakhovetski 
> 
> Currently the UVC driver assigns a quirk bitmask to the .driver_info
> field of struct usb_device_id. This patch instroduces a struct to store
> quirks and possibly other per-device parameters in the future.

I'd drop the "possibly" as I'm fairly certain we will have other parameters in 
the future. Otherwise the patch would be a bit pointless :-)

> Signed-off-by: Guennadi Liakhovetski 
> ---
> 
> v7: this is a new patch in the series. Needed to enable specifying
> private camera metadata formats
> 
>  drivers/media/usb/uvc/uvc_driver.c | 127 --
>  1 file changed, 78 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index 6d22b22..cbf79b9 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -2001,11 +2001,18 @@ static int uvc_register_chains(struct uvc_device
> *dev) * USB probe, disconnect, suspend and resume
>   */
> 
> +struct uvc_device_info {
> + u32 quirks;
> +};
> +
>  static int uvc_probe(struct usb_interface *intf,
>const struct usb_device_id *id)
>  {
>   struct usb_device *udev = interface_to_usbdev(intf);
>   struct uvc_device *dev;
> + const struct uvc_device_info *info =
> + (const struct uvc_device_info *)id->driver_info;
> + u32 quirks = info ? info->quirks : 0;
>   int function;
>   int ret;
> 
> @@ -2032,7 +2039,7 @@ static int uvc_probe(struct usb_interface *intf,
>   dev->intf = usb_get_intf(intf);
>   dev->intfnum = intf->cur_altsetting->desc.bInterfaceNumber;
>   dev->quirks = (uvc_quirks_param == -1)
> - ? id->driver_info : uvc_quirks_param;
> + ? quirks : uvc_quirks_param;
> 
>   if (udev->product != NULL)
>   strlcpy(dev->name, udev->product, sizeof dev->name);
> @@ -2073,7 +2080,7 @@ static int uvc_probe(struct usb_interface *intf,
>   le16_to_cpu(udev->descriptor.idVendor),
>   le16_to_cpu(udev->descriptor.idProduct));
> 
> - if (dev->quirks != id->driver_info) {
> + if (dev->quirks != quirks) {
>   uvc_printk(KERN_INFO, "Forcing device quirks to 0x%x by module "
>   "parameter for testing purpose.\n", dev->quirks);
>   uvc_printk(KERN_INFO, "Please report required quirks to the "
> @@ -2271,6 +2278,28 @@ static int uvc_clock_param_set(const char *val,
> struct kernel_param *kp) * Driver initialization and cleanup
>   */
> 
> +static struct uvc_device_info uvc_quirk_probe_minmax = {
> + .quirks = UVC_QUIRK_PROBE_MINMAX,
> +};
> +
> +static struct uvc_device_info uvc_quirk_fix_bandwidth = {
> + .quirks = UVC_QUIRK_FIX_BANDWIDTH,
> +};
> +
> +static struct uvc_device_info uvc_quirk_probe_def = {
> + .quirks = UVC_QUIRK_PROBE_DEF,
> +};
> +
> +static struct uvc_device_info uvc_quirk_stream_no_fid = {
> + .quirks = UVC_QUIRK_STREAM_NO_FID,
> +};
> +
> +static struct uvc_device_info uvc_quirk_force_y8 = {
> + .quirks = UVC_QUIRK_FORCE_Y8,
> +};

You can make all of these static const.

> +#define UVC_QUIRK_INFO(q) (kernel_ulong_t)&(struct uvc_device_info){.quirks
> = q}
> +
>  /*
>   * The Logitech cameras listed below have their interface class set to
>   * VENDOR_SPEC because they don't announce themselves as UVC devices, even
> @@ -2285,7 +2314,7 @@ static int uvc_clock_param_set(const char *val, struct
> kernel_param *kp) .bInterfaceClass= USB_CLASS_VIDEO,
> .bInterfaceSubClass   = 1,
> .bInterfaceProtocol   = 0,
> -   .driver_info  = UVC_QUIRK_PROBE_MINMAX },
> +   .driver_info  = (kernel_ulong_t)_quirk_probe_minmax },
>   /* Genius eFace 2025 */
>   { .match_flags  = USB_DEVICE_ID_MATCH_DEVICE
> 
>   | USB_DEVICE_ID_MATCH_INT_INFO,
> 
> @@ -2294,7 +2323,7 @@ static int uvc_clock_param_set(const char *val, struct
> kernel_param *kp) .bInterfaceClass= USB_CLASS_VIDEO,
> .bInterfaceSubClass   = 1,
> .bInterfaceProtocol   = 0,
> -   .driver_info  = UVC_QUIRK_PROBE_MINMAX },
> +   .driver_info  = (kernel_ulong_t)_quirk_probe_minmax },
>   /* Microsoft Lifecam NX-6000 */
>   { .match_flags  = USB_DEVICE_ID_MATCH_DEVICE
> 
>   | USB_DEVICE_ID_MATCH_INT_INFO,
> 
> @@ -2303,7 +2332,7 @@ static int uvc_clock_param_set(const char *val, struct
> kernel_param *kp) .bInterfaceClass= USB_CLASS_VIDEO,
> .bInterfaceSubClass   = 1,
> .bInterfaceProtocol   = 0,
> -   .driver_info  = UVC_QUIRK_PROBE_MINMAX },
> +   .driver_info  = (kernel_ulong_t)_quirk_probe_minmax },
>   /* Microsoft Lifecam NX-3000 */

Re: [PATCH v1 4/4] media: ov5640: add support of RGB565 and YUYV formats

[Hugues FRUCHET]

Thanks for review Sakari,

On 11/24/2017 03:09 PM, Sakari Ailus wrote:
> Hi Hugues,
> 
> On Thu, Nov 16, 2017 at 02:41:42PM +0100, Hugues Fruchet wrote:
>> Add RGB565 (LE & BE) and YUV422 YUYV format in addition
>> to existing YUV422 UYVY format.
>>
>> Signed-off-by: Hugues Fruchet 
>> ---
>>   drivers/media/i2c/ov5640.c | 79 
>> +-
>>   1 file changed, 71 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
>> index fb519ad..086a451 100644
>> --- a/drivers/media/i2c/ov5640.c
>> +++ b/drivers/media/i2c/ov5640.c
>> @@ -77,8 +77,10 @@
>>   #define OV5640_REG_HZ5060_CTRL01   0x3c01
>>   #define OV5640_REG_SIGMADELTA_CTRL0C   0x3c0c
>>   #define OV5640_REG_FRAME_CTRL010x4202
>> +#define OV5640_REG_FORMAT_CONTROL00 0x4300
>>   #define OV5640_REG_MIPI_CTRL00 0x4800
>>   #define OV5640_REG_DEBUG_MODE  0x4814
>> +#define OV5640_REG_ISP_FORMAT_MUX_CTRL  0x501f
>>   #define OV5640_REG_PRE_ISP_TEST_SET1   0x503d
>>   #define OV5640_REG_SDE_CTRL0   0x5580
>>   #define OV5640_REG_SDE_CTRL1   0x5581
>> @@ -106,6 +108,18 @@ enum ov5640_frame_rate {
>>  OV5640_NUM_FRAMERATES,
>>   };
>>   
>> +struct ov5640_pixfmt {
>> +u32 code;
>> +u32 colorspace;
>> +};
>> +
>> +static const struct ov5640_pixfmt ov5640_formats[] = {
>> +{ MEDIA_BUS_FMT_UYVY8_2X8, V4L2_COLORSPACE_SRGB, },
>> +{ MEDIA_BUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_SRGB, },
>> +{ MEDIA_BUS_FMT_RGB565_2X8_LE, V4L2_COLORSPACE_SRGB, },
>> +{ MEDIA_BUS_FMT_RGB565_2X8_BE, V4L2_COLORSPACE_SRGB, },
>> +};
>> +
>>   /*
>>* FIXME: remove this when a subdev API becomes available
>>* to set the MIPI CSI-2 virtual channel.
>> @@ -1798,17 +1812,23 @@ static int ov5640_try_fmt_internal(struct 
>> v4l2_subdev *sd,
>>   {
>>  struct ov5640_dev *sensor = to_ov5640_dev(sd);
>>  const struct ov5640_mode_info *mode;
>> +int i;
>>   
>>  mode = ov5640_find_mode(sensor, fr, fmt->width, fmt->height, true);
>>  if (!mode)
>>  return -EINVAL;
>> -
>>  fmt->width = mode->width;
>>  fmt->height = mode->height;
>> -fmt->code = sensor->fmt.code;
>>   
>>  if (new_mode)
>>  *new_mode = mode;
>> +
>> +for (i = 0; i < ARRAY_SIZE(ov5640_formats); i++)
>> +if (ov5640_formats[i].code == fmt->code)
>> +break;
>> +if (i >= ARRAY_SIZE(ov5640_formats))
>> +fmt->code = ov5640_formats[0].code;
>> +
>>  return 0;
>>   }
>>   
>> @@ -1851,6 +1871,49 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
>>  return ret;
>>   }
>>   
>> +static int ov5640_set_framefmt(struct ov5640_dev *sensor,
>> +   struct v4l2_mbus_framefmt *format)
>> +{
>> +int ret = 0;
>> +bool is_rgb = false;
>> +u8 val;
>> +
>> +switch (format->code) {
>> +case MEDIA_BUS_FMT_UYVY8_2X8:
>> +/* YUV422, UYVY */
>> +val = 0x3f;
>> +break;
>> +case MEDIA_BUS_FMT_YUYV8_2X8:
>> +/* YUV422, YUYV */
>> +val = 0x30;
>> +break;
>> +case MEDIA_BUS_FMT_RGB565_2X8_LE:
>> +/* RGB565 {g[2:0],b[4:0]},{r[4:0],g[5:3]} */
>> +val = 0x6F;
>> +is_rgb = true;
>> +break;
>> +case MEDIA_BUS_FMT_RGB565_2X8_BE:
>> +/* RGB565 {r[4:0],g[5:3]},{g[2:0],b[4:0]} */
>> +val = 0x61;
>> +is_rgb = true;
>> +break;
>> +default:
>> +return -EINVAL;
>> +}
>> +
>> +/* FORMAT CONTROL00: YUV and RGB formatting */
>> +ret = ov5640_write_reg(sensor, OV5640_REG_FORMAT_CONTROL00, val);
>> +if (ret)
>> +return ret;
>> +
>> +/* FORMAT MUX CONTROL: ISP YUV or RGB */
>> +ret = ov5640_write_reg(sensor, OV5640_REG_ISP_FORMAT_MUX_CTRL,
>> +   is_rgb ? 0x01 : 0x00);
> 
> return ov5640...;
> 
OK.

>> +if (ret)
>> +return ret;
>> +
>> +return ret;
>> +}
>>   
>>   /*
>>* Sensor Controls.
>> @@ -2236,15 +2299,12 @@ static int ov5640_enum_mbus_code(struct v4l2_subdev 
>> *sd,
>>struct v4l2_subdev_pad_config *cfg,
>>struct v4l2_subdev_mbus_code_enum *code)
>>   {
>> -struct ov5640_dev *sensor = to_ov5640_dev(sd);
>> -
>>  if (code->pad != 0)
>>  return -EINVAL;
>> -if (code->index != 0)
>> +if (code->index >= ARRAY_SIZE(ov5640_formats))
>>  return -EINVAL;
>>   
>> -code->code = sensor->fmt.code;
>> -
>> +code->code = ov5640_formats[code->index].code;
>>  return 0;
>>   }
>>   
>> @@ -2254,12 +2314,15 @@ static int ov5640_s_stream(struct v4l2_subdev *sd, 
>> int enable)
>>  int ret = 0;
>>   
>>  mutex_lock(>lock);
>> -
> 
> I rather liked this newline!
> 
OK.

>>  if (sensor->streaming == !enable) {
>>   

Re: [linux-sunxi] Cedrus driver

[Maxime Ripard]

Hi,

On Tue, Nov 28, 2017 at 03:51:14PM +0100, Thomas van Kleef wrote:
> On 28-11-17 13:26, Maxime Ripard wrote:
> > On Tue, Nov 28, 2017 at 12:20:59PM +0100, Thomas van Kleef wrote:
> >>> So, I have been rebasing to 4.14.0 and have the cedrus driver working.
> >> I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from 
> >> Hans
> >> Verkuil's media_tree. I have a patch available of the merge between these 2
> >> branches.
> >> After this I pulled the sunxi-cedrus repository from Florent Revests 
> >> github. I
> >> believe this one is the same as the ones you are cloning right now.
> >> I have merged this and have a patch available for this as well.
> >>
> >> So to summarize:
> >>  o pulled linux 4.14 from:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> >>  o pulled requests2 from:
> >> https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2
> >> will be replaced with the work, when it is done, in:
> >>  https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2
> >>  o pulled linux-sunxi-cedrus from:
> >> https://github.com/FlorentRevest/linux-sunxi-cedrus
> >>
> >>  o merged and made patch between linux4.14 and requests2
> >>  o merged and made patch with linux-sunxi-cedrus
> >>  o Verified that the video-engine is decofing mpeg-2 on the Allwinner A20.
> >>
> >> So maybe if someone is interested in this, I could place the patches 
> >> somewhere?
> >> Just let me know.
> > 
> > Please create a pull request on the github repo. The point we set it
> > up was to share code. Forking repos and so on is kind of pointless.
> > 
> So, I started with linux-mainline 4.14 and created a pull request with that 
> commit.
> Never made one before so if I did something wrong tell me.
> 
> The following changes since commit e1d1ea549b57790a3d8cf6300e6ef86118d692a3:
> 
>   Merge tag 'fbdev-v4.15' of git://github.com/bzolnier/linux (2017-11-20 
> 21:50:24 -1000)
> 
> are available in the git repository at:
> 
>   https://github.com/thomas-vitsch/linux-a20-cedrus.git 
> 
> for you to fetch changes up to 508ad12eb737fde07f4a25446ed941a01480d6dc:
> 
>   Merge branch 'master' of https://github.com/thomas-vitsch/linux-a20-cedrus 
> into linux-sunxi-cedrus-a20 (2017-11-28 15:28:18 +0100)
> 
> 
> Bob Ham (1):
>   sunxi-cedrus: Fix compilation errors from bad types under GCC 6.2
> 
> Florent Revest (8):
>   cherry-pick sunxi_cedrus
>   cherry-pick sunxi_cedrus
>   v4l: Add MPEG4 low-level decoder API control
>   media: platform: Add Sunxi Cedrus decoder driver
>   sunxi-cedrus: Add a MPEG 2 codec
>   sunxi-cedrus: Add a MPEG 4 codec
>   sunxi-cedrus: Add device tree binding document
>   cherry-pick sunxi_cedrus
> 
> Hans Verkuil (15):
>   videodev2.h: add max_reqs to struct v4l2_query_ext_ctrl
>   videodev2.h: add request to v4l2_ext_controls
>   videodev2.h: add request field to v4l2_buffer.
>   vb2: add allow_requests flag
>   v4l2-ctrls: add request support
>   v4l2-ctrls: add function to apply a request.
>   v4l2-ctrls: implement delete request(s)
>   v4l2-ctrls: add VIDIOC_REQUEST_CMD
>   v4l2: add initial V4L2_REQ_CMD_QUEUE support
>   vb2: add helper function to queue request-specific buffer.
>   v4l2-device: keep track of registered video_devices
>   v4l2-device: add v4l2_device_req_queue
>   vivid: add request support for video capture.
>   v4l2-ctrls: add REQ_KEEP flag
>   Documentation: add v4l2-requests.txt
> 
> Icenowy Zheng (2):
>   sunxi-cedrus: add syscon support
>   cherry-pick sunxi_cedrus
> 
> Thomas van Kleef (11):
>   Appears that the requests2 API is currently based on linux 3.9 :(. Made 
> some changes that needed to be merged manually, let's hope I did not make to 
> many errors
>   Fixed last missing calls for a buildable kernel with the requests2 API. 
> Tested with a mock mem2mem device which selects the VIDEOBUF2_CORE.
>   Kconfig option used to enable the VIDEOBUF2_CORE
>   Fix sun5i-a13 merge errors. Mainline has moved some device nodes which 
> resulted in nodes existing multiple times in device trees.
>   o Added reserved memory region for the video-engine. o Added device 
> node for the video engine.
>   style commit
>   Apply patch which adds requests2 branch from media-tree: 
> https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2
>   Apply patch which adds linux-sunxi-cedrus from: 
> https://github.com/FlorentRevest/sunxi-cedrus-drv-video
>   Add reserved region and video-engine node to sun7i.dtsi
>   Merge branch 'master' of 
> https://github.com/thomas-vitsch/linux-a20-cedrus into linux-a20-cedrus
>   Merge branch 'master' of 
> https://github.com/thomas-vitsch/linux-a20-cedrus into linux-sunxi-cedrus-a20
> 
> Vitsch Electronics (1):
>   Update README

So there's a couple of issues with those 

Re: [PATCH v6 0/9] i2c: document DMA handling and add helpers for it

[Mark Brown]

On Mon, Nov 27, 2017 at 07:51:16PM +0100, Wolfram Sang wrote:
> On Wed, Nov 08, 2017 at 10:50:37PM +, Mark Brown wrote:

> > We pretty much assume everything is DMA safe already, the majority of
> > transfers go to/from kmalloc()ed scratch buffers so actually are DMA
> > safe but for bulk transfers we use the caller buffer and there might be
> > some problem users.

> So, pretty much the situation I2C was in before this patch set: we
> pretty much assume DMA safety but there might be problem users.

It's a bit different in that it's much more likely that a SPI controller
will actually do DMA than an I2C one since the speeds are higher and
there's frequent applications that do large transfers so it's more
likely that people will do the right thing as issues would tend to come
up if they don't.

> > I can't really think of a particularly good way of
> > handling it off the top of my head, obviously not setting the flag is
> > easy but doesn't get the benefit while always using a bounce buffer
> > would involve lots of unneeded memcpy().  Doing _dmasafe() isn't
> > particularly appealing either but might be what we end up with.

> Okay. That sounds you are fine with the approach taken here, in general?

It's hard to summon enthusiasm but yes, without changes to the DMA stuff
it's probably as good as we can do.


signature.asc
Description: PGP signature

Re: [PATCH 1/3 v7] V4L: Add a UVC Metadata format

[Guennadi Liakhovetski]

Hi Laurent,

Thanks for the review.

On Tue, 28 Nov 2017, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> Thank you for the patch.
> 
> Overall this looks good to me. Please see below for one small comment.

Yes, looks good to me, feel free to use your wording.

Thanks
Guennadi

> On Wednesday, 8 November 2017 18:00:12 EET Guennadi Liakhovetski wrote:
> > From: Guennadi Liakhovetski 
> > 
> > Add a pixel format, used by the UVC driver to stream metadata.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> > 
> > v7: alphabetic order, update documentation.
> > 
> >  Documentation/media/uapi/v4l/meta-formats.rst|  1 +
> >  Documentation/media/uapi/v4l/pixfmt-meta-uvc.rst | 50 +
> >  include/uapi/linux/videodev2.h   |  1 +
> >  3 files changed, 52 insertions(+)
> >  create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-uvc.rst
> > 
> > diff --git a/Documentation/media/uapi/v4l/meta-formats.rst
> > b/Documentation/media/uapi/v4l/meta-formats.rst index 01e24e3..0c4e1ec
> > 100644
> > --- a/Documentation/media/uapi/v4l/meta-formats.rst
> > +++ b/Documentation/media/uapi/v4l/meta-formats.rst
> > @@ -12,5 +12,6 @@ These formats are used for the :ref:`metadata` interface
> > only.
> >  .. toctree::
> >  :maxdepth: 1
> > 
> > +pixfmt-meta-uvc
> >  pixfmt-meta-vsp1-hgo
> >  pixfmt-meta-vsp1-hgt
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-uvc.rst
> > b/Documentation/media/uapi/v4l/pixfmt-meta-uvc.rst new file mode 100644
> > index 000..06f603c
> > --- /dev/null
> > +++ b/Documentation/media/uapi/v4l/pixfmt-meta-uvc.rst
> > @@ -0,0 +1,50 @@
> > +.. -*- coding: utf-8; mode: rst -*-
> > +
> > +.. _v4l2-meta-fmt-uvc:
> > +
> > +***
> > +V4L2_META_FMT_UVC ('UVCH')
> > +***
> > +
> > +UVC Payload Header Data
> > +
> > +
> > +Description
> > +===
> > +
> > +This format describes standard UVC metadata, extracted from UVC packet
> > headers +and provided by the UVC driver through metadata video nodes. That
> > data includes +exact copies of the standard part of UVC Payload Header
> > contents and auxiliary +timing information, required for precise
> > interpretation of timestamps, contained +in those headers. See section
> > "2.4.3.3 Video and Still Image Payload Headers" of +the "UVC 1.5 Class
> > specification" for details.
> > +
> > +Each UVC payload header can be between 2 and 12 bytes large. Buffers can
> > contain +multiple headers, if multiple such headers have been transmitted
> > by the camera +for the respective frame. However, headers, containing no
> > useful information, +e.g. those without the SCR field or with that field
> > identical to the previous +header, will be dropped by the driver.
> 
> If the driver receives too many headers with different SCR (more than the 
> buffer can hold for instance) it will have to drop some of them. The simplest 
> implementation would be to start dropping them when the buffer is full, but 
> I'd like to leave room for the driver to be a bit more clever and drop 
> headers 
> that have a SCR too close to the previous one for instance. I propose wording 
> the above paragraph as follows.
> 
> "Each UVC payload header can be between 2 and 12 bytes large. Buffers can
> contain multiple headers, if multiple such headers have been transmitted
> by the camera for the respective frame. However, the driver may drop headers 
> when the buffer is full, when they contain no useful information (e.g. those 
> without the SCR field or with that field identical to the previous header), 
> or 
> generally to perform rate limiting when the device sends a large number of 
> headers".
> 
> If you're fine with this there's no need to resent, I can update the 
> documentation when applying, and
> 
> Reviewed-by: Laurent Pinchart 
> 
> > +Each individual block contains the following fields:
> > +
> > +.. flat-table:: UVC Metadata Block
> > +:widths: 1 4
> > +:header-rows:  1
> > +:stub-columns: 0
> > +
> > +* - Field
> > +  - Description
> > +* - __u64 ts;
> > +  - system timestamp in host byte order, measured by the driver upon
> > +reception of the payload
> > +* - __u16 sof;
> > +  - USB Frame Number in host byte order, also obtained by the driver as
> > +close as possible to the above timestamp to enable correlation
> > between +them
> > +* - :cspan:`1` *The rest is an exact copy of the UVC payload header:*
> > +* - __u8 length;
> > +  - length of the rest of the block, including this field
> > +* - __u8 flags;
> > +  - Flags, indicating presence of other standard UVC fields
> > +* - __u8 buf[];
> > +  - The rest of the header, possibly including UVC PTS and SCR fields
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 

Re: [PATCH 1/3 v7] V4L: Add a UVC Metadata format

[Laurent Pinchart]

Hi Guennadi,

Thank you for the patch.

Overall this looks good to me. Please see below for one small comment.

On Wednesday, 8 November 2017 18:00:12 EET Guennadi Liakhovetski wrote:
> From: Guennadi Liakhovetski 
> 
> Add a pixel format, used by the UVC driver to stream metadata.
> 
> Signed-off-by: Guennadi Liakhovetski 
> ---
> 
> v7: alphabetic order, update documentation.
> 
>  Documentation/media/uapi/v4l/meta-formats.rst|  1 +
>  Documentation/media/uapi/v4l/pixfmt-meta-uvc.rst | 50 +
>  include/uapi/linux/videodev2.h   |  1 +
>  3 files changed, 52 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-uvc.rst
> 
> diff --git a/Documentation/media/uapi/v4l/meta-formats.rst
> b/Documentation/media/uapi/v4l/meta-formats.rst index 01e24e3..0c4e1ec
> 100644
> --- a/Documentation/media/uapi/v4l/meta-formats.rst
> +++ b/Documentation/media/uapi/v4l/meta-formats.rst
> @@ -12,5 +12,6 @@ These formats are used for the :ref:`metadata` interface
> only.
>  .. toctree::
>  :maxdepth: 1
> 
> +pixfmt-meta-uvc
>  pixfmt-meta-vsp1-hgo
>  pixfmt-meta-vsp1-hgt
> diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-uvc.rst
> b/Documentation/media/uapi/v4l/pixfmt-meta-uvc.rst new file mode 100644
> index 000..06f603c
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-meta-uvc.rst
> @@ -0,0 +1,50 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _v4l2-meta-fmt-uvc:
> +
> +***
> +V4L2_META_FMT_UVC ('UVCH')
> +***
> +
> +UVC Payload Header Data
> +
> +
> +Description
> +===
> +
> +This format describes standard UVC metadata, extracted from UVC packet
> headers +and provided by the UVC driver through metadata video nodes. That
> data includes +exact copies of the standard part of UVC Payload Header
> contents and auxiliary +timing information, required for precise
> interpretation of timestamps, contained +in those headers. See section
> "2.4.3.3 Video and Still Image Payload Headers" of +the "UVC 1.5 Class
> specification" for details.
> +
> +Each UVC payload header can be between 2 and 12 bytes large. Buffers can
> contain +multiple headers, if multiple such headers have been transmitted
> by the camera +for the respective frame. However, headers, containing no
> useful information, +e.g. those without the SCR field or with that field
> identical to the previous +header, will be dropped by the driver.

If the driver receives too many headers with different SCR (more than the 
buffer can hold for instance) it will have to drop some of them. The simplest 
implementation would be to start dropping them when the buffer is full, but 
I'd like to leave room for the driver to be a bit more clever and drop headers 
that have a SCR too close to the previous one for instance. I propose wording 
the above paragraph as follows.

"Each UVC payload header can be between 2 and 12 bytes large. Buffers can
contain multiple headers, if multiple such headers have been transmitted
by the camera for the respective frame. However, the driver may drop headers 
when the buffer is full, when they contain no useful information (e.g. those 
without the SCR field or with that field identical to the previous header), or 
generally to perform rate limiting when the device sends a large number of 
headers".

If you're fine with this there's no need to resent, I can update the 
documentation when applying, and

Reviewed-by: Laurent Pinchart 

> +Each individual block contains the following fields:
> +
> +.. flat-table:: UVC Metadata Block
> +:widths: 1 4
> +:header-rows:  1
> +:stub-columns: 0
> +
> +* - Field
> +  - Description
> +* - __u64 ts;
> +  - system timestamp in host byte order, measured by the driver upon
> +reception of the payload
> +* - __u16 sof;
> +  - USB Frame Number in host byte order, also obtained by the driver as
> +close as possible to the above timestamp to enable correlation
> between +them
> +* - :cspan:`1` *The rest is an exact copy of the UVC payload header:*
> +* - __u8 length;
> +  - length of the rest of the block, including this field
> +* - __u8 flags;
> +  - Flags, indicating presence of other standard UVC fields
> +* - __u8 buf[];
> +  - The rest of the header, possibly including UVC PTS and SCR fields
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 185d6a0..0d07b2d 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -687,6 +687,7 @@ struct v4l2_pix_format {
>  /* Meta-data formats */
>  #define V4L2_META_FMT_VSP1_HGOv4l2_fourcc('V', 'S', 'P', 'H') /* R-Car
> VSP1 1-D Histogram */ #define V4L2_META_FMT_VSP1_HGTv4l2_fourcc('V',
> 'S', 'P', 'T') /* R-Car VSP1 2-D Histogram */ +#define 

Re: [linux-sunxi] Cedrus driver

[Giulio Benetti]

Il 28/11/2017 16:17, Maxime Ripard ha scritto:

On Tue, Nov 28, 2017 at 02:12:31PM +0100, Giulio Benetti wrote:

And really, just develop against 4.14. sunxi-next is rebased, and it's
just not something you can base some work on.


Where do we can work on then?
Should Thomas setup his own github repo?
What about the one you’ve set up @free-electrons?


I already said that, please make pull requests to that repo.


Sorry I can't understand which repo,
do you mean https://github.com/free-electrons/linux-cedrus?


Yes.


Ok




And sorry for dumb question,
but which branch do I have to use if I want to develop a project with sunxi?
Directly mainline patched with sunxi-next branch,
or another branch @linux-sunxi?


Use 4.14.


Ok,

thanks again.
Best regards



Maxime




--
Giulio Benetti
R Manager &
Advanced Research

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642

Re: [linux-sunxi] Cedrus driver

[Maxime Ripard]

On Tue, Nov 28, 2017 at 02:12:31PM +0100, Giulio Benetti wrote:
> > > > And really, just develop against 4.14. sunxi-next is rebased, and it's
> > > > just not something you can base some work on.
> > > 
> > > Where do we can work on then?
> > > Should Thomas setup his own github repo?
> > > What about the one you’ve set up @free-electrons?
> > 
> > I already said that, please make pull requests to that repo.
> 
> Sorry I can't understand which repo,
> do you mean https://github.com/free-electrons/linux-cedrus?

Yes.

> And sorry for dumb question,
> but which branch do I have to use if I want to develop a project with sunxi?
> Directly mainline patched with sunxi-next branch,
> or another branch @linux-sunxi?

Use 4.14.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [linux-sunxi] Cedrus driver

[Thomas van Kleef]

On 28-11-17 13:26, Maxime Ripard wrote:
> On Tue, Nov 28, 2017 at 12:20:59PM +0100, Thomas van Kleef wrote:
>>> So, I have been rebasing to 4.14.0 and have the cedrus driver working.
>> I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from 
>> Hans
>> Verkuil's media_tree. I have a patch available of the merge between these 2
>> branches.
>> After this I pulled the sunxi-cedrus repository from Florent Revests github. 
>> I
>> believe this one is the same as the ones you are cloning right now.
>> I have merged this and have a patch available for this as well.
>>
>> So to summarize:
>>  o pulled linux 4.14 from:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>  o pulled requests2 from:
>> https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2
>> will be replaced with the work, when it is done, in:
>>  https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2
>>  o pulled linux-sunxi-cedrus from:
>> https://github.com/FlorentRevest/linux-sunxi-cedrus
>>
>>  o merged and made patch between linux4.14 and requests2
>>  o merged and made patch with linux-sunxi-cedrus
>>  o Verified that the video-engine is decofing mpeg-2 on the Allwinner A20.
>>
>> So maybe if someone is interested in this, I could place the patches 
>> somewhere?
>> Just let me know.
> 
> Please create a pull request on the github repo. The point we set it
> up was to share code. Forking repos and so on is kind of pointless.
> 
So, I started with linux-mainline 4.14 and created a pull request with that 
commit.
Never made one before so if I did something wrong tell me.

The following changes since commit e1d1ea549b57790a3d8cf6300e6ef86118d692a3:

  Merge tag 'fbdev-v4.15' of git://github.com/bzolnier/linux (2017-11-20 
21:50:24 -1000)

are available in the git repository at:

  https://github.com/thomas-vitsch/linux-a20-cedrus.git 

for you to fetch changes up to 508ad12eb737fde07f4a25446ed941a01480d6dc:

  Merge branch 'master' of https://github.com/thomas-vitsch/linux-a20-cedrus 
into linux-sunxi-cedrus-a20 (2017-11-28 15:28:18 +0100)


Bob Ham (1):
  sunxi-cedrus: Fix compilation errors from bad types under GCC 6.2

Florent Revest (8):
  cherry-pick sunxi_cedrus
  cherry-pick sunxi_cedrus
  v4l: Add MPEG4 low-level decoder API control
  media: platform: Add Sunxi Cedrus decoder driver
  sunxi-cedrus: Add a MPEG 2 codec
  sunxi-cedrus: Add a MPEG 4 codec
  sunxi-cedrus: Add device tree binding document
  cherry-pick sunxi_cedrus

Hans Verkuil (15):
  videodev2.h: add max_reqs to struct v4l2_query_ext_ctrl
  videodev2.h: add request to v4l2_ext_controls
  videodev2.h: add request field to v4l2_buffer.
  vb2: add allow_requests flag
  v4l2-ctrls: add request support
  v4l2-ctrls: add function to apply a request.
  v4l2-ctrls: implement delete request(s)
  v4l2-ctrls: add VIDIOC_REQUEST_CMD
  v4l2: add initial V4L2_REQ_CMD_QUEUE support
  vb2: add helper function to queue request-specific buffer.
  v4l2-device: keep track of registered video_devices
  v4l2-device: add v4l2_device_req_queue
  vivid: add request support for video capture.
  v4l2-ctrls: add REQ_KEEP flag
  Documentation: add v4l2-requests.txt

Icenowy Zheng (2):
  sunxi-cedrus: add syscon support
  cherry-pick sunxi_cedrus

Thomas van Kleef (11):
  Appears that the requests2 API is currently based on linux 3.9 :(. Made 
some changes that needed to be merged manually, let's hope I did not make to 
many errors
  Fixed last missing calls for a buildable kernel with the requests2 API. 
Tested with a mock mem2mem device which selects the VIDEOBUF2_CORE.
  Kconfig option used to enable the VIDEOBUF2_CORE
  Fix sun5i-a13 merge errors. Mainline has moved some device nodes which 
resulted in nodes existing multiple times in device trees.
  o Added reserved memory region for the video-engine. o Added device 
node for the video engine.
  style commit
  Apply patch which adds requests2 branch from media-tree: 
https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2
  Apply patch which adds linux-sunxi-cedrus from: 
https://github.com/FlorentRevest/sunxi-cedrus-drv-video
  Add reserved region and video-engine node to sun7i.dtsi
  Merge branch 'master' of 
https://github.com/thomas-vitsch/linux-a20-cedrus into linux-a20-cedrus
  Merge branch 'master' of 
https://github.com/thomas-vitsch/linux-a20-cedrus into linux-sunxi-cedrus-a20

Vitsch Electronics (1):
  Update README

 .../devicetree/bindings/media/sunxi-cedrus.txt |   44 +
 Documentation/video4linux/v4l2-requests.txt|  233 ++
 README |   18 +-
 arch/arm/boot/dts/sun5i-a13-difrnce-dit4350.dts|   50 -
 arch/arm/boot/dts/sun5i-a13.dtsi   |   30 +
 

Re: [PATCH v2 1/3] media: staging: atomisp: fix for sparse "using plain integer as NULL pointer" warnings.

[Dan Carpenter]

On Mon, Nov 27, 2017 at 12:44:48PM +, Jeremy Sowden wrote:
> The "address" member of struct ia_css_host_data is a pointer-to-char, so 
> define default as NULL.
> 
> Signed-off-by: Jeremy Sowden 
> ---
>  .../css2400/runtime/isp_param/interface/ia_css_isp_param_types.h| 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
>  
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
> index 8e651b80345a..6fee3f7fd184 100644
> --- 
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
> +++ 
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
> @@ -95,7 +95,7 @@ union ia_css_all_memory_offsets {
>  };
>  
>  #define IA_CSS_DEFAULT_ISP_MEM_PARAMS \
> - { { { { 0, 0 } } } }
> + { { { { NULL, 0 } } } }

This define is way ugly and instead of making superficial changes, you
should try to eliminate it.

People look at warnings as a bad thing but they are actually a valuable
resource which call attention to bad code.  By making this change you're
kind of wasting the warning.  The bad code is still there, it's just
swept under the rug but like a dead mouse carcass it's still stinking up
the living room.  We should leave the warning there until it irritates
someone enough to fix it properly.

regards,
dan carpenter

Re: [PATCH] media: i2c: adv748x: Restore full DT paths in kernel messages

[Kieran Bingham]

Hi Geert,

Thanks for the patch.

On 28/11/17 13:01, Geert Uytterhoeven wrote:
> As of_node_full_name() now returns only the basename, the endpoint
> information printed became useless:
> 
> adv748x 4-0070: Endpoint endpoint on port 7
> adv748x 4-0070: Endpoint endpoint on port 8
> adv748x 4-0070: Endpoint endpoint on port 10
> adv748x 4-0070: Endpoint endpoint on port 11
> 
> Restore the old behavior by using "%pOF" instead:
> 
> adv748x 4-0070: Endpoint 
> /soc/i2c@e66d8000/video-receiver@70/port@7/endpoint on port 7
> adv748x 4-0070: Endpoint 
> /soc/i2c@e66d8000/video-receiver@70/port@8/endpoint on port 8
> adv748x 4-0070: Endpoint 
> /soc/i2c@e66d8000/video-receiver@70/port@10/endpoint on port 10
> adv748x 4-0070: Endpoint 
> /soc/i2c@e66d8000/video-receiver@70/port@11/endpoint on port 11
> 
> Fixes: a7e4cfb0a7ca4773 ("of/fdt: only store the device node basename in 
> full_name")
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Kieran Bingham 

> ---
>  drivers/media/i2c/adv748x/adv748x-core.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
> b/drivers/media/i2c/adv748x/adv748x-core.c
> index 5ee14f2c27478e3a..c1001db6a172e256 100644
> --- a/drivers/media/i2c/adv748x/adv748x-core.c
> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> @@ -646,14 +646,12 @@ static int adv748x_parse_dt(struct adv748x_state *state)
>  
>   for_each_endpoint_of_node(state->dev->of_node, ep_np) {
>   of_graph_parse_endpoint(ep_np, );
> - adv_info(state, "Endpoint %s on port %d",
> - of_node_full_name(ep.local_node),
> - ep.port);
> + adv_info(state, "Endpoint %pOF on port %d", ep.local_node,
> +  ep.port);
>  
>   if (ep.port >= ADV748X_PORT_MAX) {
> - adv_err(state, "Invalid endpoint %s on port %d",
> - of_node_full_name(ep.local_node),
> - ep.port);
> + adv_err(state, "Invalid endpoint %pOF on port %d",
> + ep.local_node, ep.port);
>  
>   continue;
>   }
> 

Re: [PATCH v5 1/2] media: ov7740: Document device tree bindings

[Rob Herring]

On Tue, Nov 28, 2017 at 01:22:58PM +0800, Wenyou Yang wrote:
> Add the device tree binding documentation for the ov7740 sensor driver.
> 
> Signed-off-by: Wenyou Yang 
> ---
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
>  - Explicitly document the "remote-endpoint" property.
> 
> Changes in v2: None
> 
>  .../devicetree/bindings/media/i2c/ov7740.txt   | 47 
> ++
>  1 file changed, 47 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt

Acked-by: Rob Herring 

Re: [PATCH] media: i2c: adv748x: Restore full DT paths in kernel messages

[Niklas Söderlund]

Hi Geert,

Thanks for your patch.

On 2017-11-28 14:01:24 +0100, Geert Uytterhoeven wrote:
> As of_node_full_name() now returns only the basename, the endpoint
> information printed became useless:
> 
> adv748x 4-0070: Endpoint endpoint on port 7
> adv748x 4-0070: Endpoint endpoint on port 8
> adv748x 4-0070: Endpoint endpoint on port 10
> adv748x 4-0070: Endpoint endpoint on port 11
> 
> Restore the old behavior by using "%pOF" instead:
> 
> adv748x 4-0070: Endpoint 
> /soc/i2c@e66d8000/video-receiver@70/port@7/endpoint on port 7
> adv748x 4-0070: Endpoint 
> /soc/i2c@e66d8000/video-receiver@70/port@8/endpoint on port 8
> adv748x 4-0070: Endpoint 
> /soc/i2c@e66d8000/video-receiver@70/port@10/endpoint on port 10
> adv748x 4-0070: Endpoint 
> /soc/i2c@e66d8000/video-receiver@70/port@11/endpoint on port 11
> 
> Fixes: a7e4cfb0a7ca4773 ("of/fdt: only store the device node basename in 
> full_name")
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Niklas Söderlund 

> ---
>  drivers/media/i2c/adv748x/adv748x-core.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
> b/drivers/media/i2c/adv748x/adv748x-core.c
> index 5ee14f2c27478e3a..c1001db6a172e256 100644
> --- a/drivers/media/i2c/adv748x/adv748x-core.c
> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> @@ -646,14 +646,12 @@ static int adv748x_parse_dt(struct adv748x_state *state)
>  
>   for_each_endpoint_of_node(state->dev->of_node, ep_np) {
>   of_graph_parse_endpoint(ep_np, );
> - adv_info(state, "Endpoint %s on port %d",
> - of_node_full_name(ep.local_node),
> - ep.port);
> + adv_info(state, "Endpoint %pOF on port %d", ep.local_node,
> +  ep.port);
>  
>   if (ep.port >= ADV748X_PORT_MAX) {
> - adv_err(state, "Invalid endpoint %s on port %d",
> - of_node_full_name(ep.local_node),
> - ep.port);
> + adv_err(state, "Invalid endpoint %pOF on port %d",
> + ep.local_node, ep.port);
>  
>   continue;
>   }
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

[Niklas Söderlund]

On 2017-11-16 18:22:49 +, Fabrizio Castro wrote:
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Acked-by: Niklas Söderlund 

> ---
> v1->v2:
> * Fixed double "change" in changelog
> 
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 98931f5..ff9697e 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -6,6 +6,8 @@ family of devices. The current blocks are always slaves and 
> suppot one input
>  channel which can be either RGB, YUYV or BT656.
>  
>   - compatible: Must be one or more of the following
> +   - "renesas,vin-r8a7743" for the R8A7743 device
> +   - "renesas,vin-r8a7745" for the R8A7745 device
> - "renesas,vin-r8a7778" for the R8A7778 device
> - "renesas,vin-r8a7779" for the R8A7779 device
> - "renesas,vin-r8a7790" for the R8A7790 device
> @@ -14,7 +16,8 @@ channel which can be either RGB, YUYV or BT656.
> - "renesas,vin-r8a7793" for the R8A7793 device
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> -   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
> +   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> + device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
>  
> When compatible with the generic version nodes must list the
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list

[Niklas Söderlund]

On 2017-11-16 18:22:48 +, Fabrizio Castro wrote:
> Change the sorting of the part numbers from descending to ascending to
> match with other documentation.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Acked-by: Niklas Söderlund 

> ---
> v1->v2:
> * new patch triggered by Geert's comment, see the below link for details:
>   https://www.mail-archive.com/linux-media@vger.kernel.org/msg121992.html
> 
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 6e4ef8c..98931f5 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -6,14 +6,14 @@ family of devices. The current blocks are always slaves and 
> suppot one input
>  channel which can be either RGB, YUYV or BT656.
>  
>   - compatible: Must be one or more of the following
> -   - "renesas,vin-r8a7795" for the R8A7795 device
> -   - "renesas,vin-r8a7794" for the R8A7794 device
> -   - "renesas,vin-r8a7793" for the R8A7793 device
> -   - "renesas,vin-r8a7792" for the R8A7792 device
> -   - "renesas,vin-r8a7791" for the R8A7791 device
> -   - "renesas,vin-r8a7790" for the R8A7790 device
> -   - "renesas,vin-r8a7779" for the R8A7779 device
> - "renesas,vin-r8a7778" for the R8A7778 device
> +   - "renesas,vin-r8a7779" for the R8A7779 device
> +   - "renesas,vin-r8a7790" for the R8A7790 device
> +   - "renesas,vin-r8a7791" for the R8A7791 device
> +   - "renesas,vin-r8a7792" for the R8A7792 device
> +   - "renesas,vin-r8a7793" for the R8A7793 device
> +   - "renesas,vin-r8a7794" for the R8A7794 device
> +   - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
>  
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH] staging/media: lirc: style fix - replace hard-coded function names

[Greg KH]

On Sun, Nov 26, 2017 at 08:49:42PM +0100, Martin Homuth wrote:
> This patch fixes the remaining coding style warnings in the lirc module.
> 
> It fixes the following checkpatch.pl warning:
> 
> WARNING: Prefer using '"%s...", __func__' to using 'read', this
> function's name, in a string

> >From f11f24667ba6696cb71ac33a67fc0c7d3b4cd542 Mon Sep 17 00:00:00 2001
> From: Martin Homuth 
> Date: Sun, 26 Nov 2017 20:14:33 +0100
> Subject: [PATCH] lirc: style fix - replace hard-coded function names
> 
> Instead of hard coding the function name the __func__ variable
> should be used.
> 
> Signed-off-by: Martin Homuth 
> ---
>  drivers/staging/media/lirc/lirc_zilog.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
> b/drivers/staging/media/lirc/lirc_zilog.c
> index 6bd0717bf76e..be68ee652071 100644
> --- a/drivers/staging/media/lirc/lirc_zilog.c
> +++ b/drivers/staging/media/lirc/lirc_zilog.c
> @@ -888,9 +888,9 @@ static ssize_t read(struct file *filep, char __user 
> *outbuf, size_t n,
>   unsigned int m;
>   DECLARE_WAITQUEUE(wait, current);
>  
> - dev_dbg(ir->dev, "read called\n");
> + dev_dbg(ir->dev, "%s called\n", __func__);
>   if (n % rbuf->chunk_size) {
> - dev_dbg(ir->dev, "read result = -EINVAL\n");
> + dev_dbg(ir->dev, "%s result = -EINVAL\n", __func__);
>   return -EINVAL;
>   }
>  
> @@ -949,7 +949,7 @@ static ssize_t read(struct file *filep, char __user 
> *outbuf, size_t n,
>   retries++;
>   }
>   if (retries >= 5) {
> - dev_err(ir->dev, "Buffer read failed!\n");
> + dev_err(ir->dev, "%s failed!\n", __func__);
>   ret = -EIO;
>   }
>   }
> @@ -959,7 +959,7 @@ static ssize_t read(struct file *filep, char __user 
> *outbuf, size_t n,
>   put_ir_rx(rx, false);
>   set_current_state(TASK_RUNNING);
>  
> - dev_dbg(ir->dev, "read result = %d (%s)\n", ret,
> + dev_dbg(ir->dev, "%s result = %d (%s)\n", __func__, ret,
>   ret ? "Error" : "OK");
>  
>   return ret ? ret : written;
> -- 
> 2.13.6
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch was attached, please place it inline so that it can be
  applied directly from the email message itself.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [linux-sunxi] Cedrus driver

[Giulio Benetti]

Il 28/11/2017 14:07, Maxime Ripard ha scritto:

On Tue, Nov 28, 2017 at 02:03:43PM +0100, Giulio Benetti wrote:

Hi,


Il giorno 28 nov 2017, alle ore 13:52, Maxime Ripard 
 ha scritto:

On Tue, Nov 28, 2017 at 12:54:08PM +0100, Giulio Benetti wrote:

Should I be working in sunxi-next I wonder?


Yes, this is the best way, cedrus is very specific to sunxi.
So before working on mainline, I think the best is to work un sunxi-next branch.


Is the requests2 api in sunxi-next?


It should be there,
take a look at latest commit of yesterday:
https://github.com/linux-sunxi/linux-sunxi/commit/df7cacd062cd84c551d7e72f15b1af6d71abc198


No, it shouldn't. sunxi-next is about patches that are related to
sunxi that have been accepted in their respective maintainers'
branches.

While we could argue about the first criteria, the second one is not
respected.

And really, just develop against 4.14. sunxi-next is rebased, and it's
just not something you can base some work on.


Where do we can work on then?
Should Thomas setup his own github repo?
What about the one you’ve set up @free-electrons?


I already said that, please make pull requests to that repo.


Sorry I can't understand which repo,
do you mean https://github.com/free-electrons/linux-cedrus?

And sorry for dumb question,
but which branch do I have to use if I want to develop a project with sunxi?
Directly mainline patched with sunxi-next branch,
or another branch @linux-sunxi?

Thank you for you patience.



Maxime




--
Giulio Benetti
R Manager &
Advanced Research

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642

Re: [linux-sunxi] Cedrus driver

[Maxime Ripard]

On Tue, Nov 28, 2017 at 02:03:43PM +0100, Giulio Benetti wrote:
> Hi,
> 
> > Il giorno 28 nov 2017, alle ore 13:52, Maxime Ripard 
> >  ha scritto:
> > 
> > On Tue, Nov 28, 2017 at 12:54:08PM +0100, Giulio Benetti wrote:
> > Should I be working in sunxi-next I wonder?
>  
>  Yes, this is the best way, cedrus is very specific to sunxi.
>  So before working on mainline, I think the best is to work un sunxi-next 
>  branch.
> >>> 
> >>> Is the requests2 api in sunxi-next?
> >> 
> >> It should be there,
> >> take a look at latest commit of yesterday:
> >> https://github.com/linux-sunxi/linux-sunxi/commit/df7cacd062cd84c551d7e72f15b1af6d71abc198
> > 
> > No, it shouldn't. sunxi-next is about patches that are related to
> > sunxi that have been accepted in their respective maintainers'
> > branches.
> > 
> > While we could argue about the first criteria, the second one is not
> > respected.
> > 
> > And really, just develop against 4.14. sunxi-next is rebased, and it's
> > just not something you can base some work on.
> 
> Where do we can work on then?
> Should Thomas setup his own github repo?
> What about the one you’ve set up @free-electrons?

I already said that, please make pull requests to that repo.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [linux-sunxi] Cedrus driver

[Giulio Benetti]

Hi,

> Il giorno 28 nov 2017, alle ore 13:52, Maxime Ripard 
>  ha scritto:
> 
> On Tue, Nov 28, 2017 at 12:54:08PM +0100, Giulio Benetti wrote:
> Should I be working in sunxi-next I wonder?
 
 Yes, this is the best way, cedrus is very specific to sunxi.
 So before working on mainline, I think the best is to work un sunxi-next 
 branch.
>>> 
>>> Is the requests2 api in sunxi-next?
>> 
>> It should be there,
>> take a look at latest commit of yesterday:
>> https://github.com/linux-sunxi/linux-sunxi/commit/df7cacd062cd84c551d7e72f15b1af6d71abc198
> 
> No, it shouldn't. sunxi-next is about patches that are related to
> sunxi that have been accepted in their respective maintainers'
> branches.
> 
> While we could argue about the first criteria, the second one is not
> respected.
> 
> And really, just develop against 4.14. sunxi-next is rebased, and it's
> just not something you can base some work on.

Where do we can work on then?
Should Thomas setup his own github repo?
What about the one you’ve set up @free-electrons?

> 
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

[PATCH] media: i2c: adv748x: Restore full DT paths in kernel messages

[Geert Uytterhoeven]

As of_node_full_name() now returns only the basename, the endpoint
information printed became useless:

adv748x 4-0070: Endpoint endpoint on port 7
adv748x 4-0070: Endpoint endpoint on port 8
adv748x 4-0070: Endpoint endpoint on port 10
adv748x 4-0070: Endpoint endpoint on port 11

Restore the old behavior by using "%pOF" instead:

adv748x 4-0070: Endpoint 
/soc/i2c@e66d8000/video-receiver@70/port@7/endpoint on port 7
adv748x 4-0070: Endpoint 
/soc/i2c@e66d8000/video-receiver@70/port@8/endpoint on port 8
adv748x 4-0070: Endpoint 
/soc/i2c@e66d8000/video-receiver@70/port@10/endpoint on port 10
adv748x 4-0070: Endpoint 
/soc/i2c@e66d8000/video-receiver@70/port@11/endpoint on port 11

Fixes: a7e4cfb0a7ca4773 ("of/fdt: only store the device node basename in 
full_name")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/media/i2c/adv748x/adv748x-core.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
b/drivers/media/i2c/adv748x/adv748x-core.c
index 5ee14f2c27478e3a..c1001db6a172e256 100644
--- a/drivers/media/i2c/adv748x/adv748x-core.c
+++ b/drivers/media/i2c/adv748x/adv748x-core.c
@@ -646,14 +646,12 @@ static int adv748x_parse_dt(struct adv748x_state *state)
 
for_each_endpoint_of_node(state->dev->of_node, ep_np) {
of_graph_parse_endpoint(ep_np, );
-   adv_info(state, "Endpoint %s on port %d",
-   of_node_full_name(ep.local_node),
-   ep.port);
+   adv_info(state, "Endpoint %pOF on port %d", ep.local_node,
+ep.port);
 
if (ep.port >= ADV748X_PORT_MAX) {
-   adv_err(state, "Invalid endpoint %s on port %d",
-   of_node_full_name(ep.local_node),
-   ep.port);
+   adv_err(state, "Invalid endpoint %pOF on port %d",
+   ep.local_node, ep.port);
 
continue;
}
-- 
2.7.4

Re: [linux-sunxi] Cedrus driver

[Maxime Ripard]

On Tue, Nov 28, 2017 at 12:54:08PM +0100, Giulio Benetti wrote:
> > > > Should I be working in sunxi-next I wonder?
> > > 
> > > Yes, this is the best way, cedrus is very specific to sunxi.
> > > So before working on mainline, I think the best is to work un sunxi-next 
> > > branch.
> >
> > Is the requests2 api in sunxi-next?
> 
> It should be there,
> take a look at latest commit of yesterday:
> https://github.com/linux-sunxi/linux-sunxi/commit/df7cacd062cd84c551d7e72f15b1af6d71abc198

No, it shouldn't. sunxi-next is about patches that are related to
sunxi that have been accepted in their respective maintainers'
branches.

While we could argue about the first criteria, the second one is not
respected.

And really, just develop against 4.14. sunxi-next is rebased, and it's
just not something you can base some work on.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [linux-sunxi] Cedrus driver

[Thomas van Kleef]

Hi Giulio

On 28-11-17 12:54, Giulio Benetti wrote:
> Hi Thomas,
> 
> Il 28/11/2017 12:29, Thomas van Kleef ha scritto:
>> Hi,
>>
>> On 28-11-17 12:26, Giulio Benetti wrote:
>>> Hi Thomas,
>>>
>>> Il 28/11/2017 12:20, Thomas van Kleef ha scritto:
 On 28-11-17 10:50, Giulio Benetti wrote:
> Hi Maxime,
>
> Il 28/11/2017 09:35, Maxime Ripard ha scritto:
>> On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote:
>>> Hi Maxime,
>>>
>>> Il 16/11/2017 14:42, Giulio Benetti ha scritto:
 Hi,

 Il 16/11/2017 14:39, Maxime Ripard ha scritto:
> On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote:
>> Hi Hans,
>>
>> Il 16/11/2017 14:12, Hans Verkuil ha scritto:
>>> On 16/11/17 13:57, Giulio Benetti wrote:
 Il 16/11/2017 13:53, Maxime Ripard ha scritto:
> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote:
>>> On Thu, Nov 16, 2017 at 11:37:30AM +0100, Giulio Benetti wrote:
 Il 16/11/2017 11:31, Andreas Baierl ha scritto:
> Am 16.11.2017 um 11:13 schrieb Giulio Benetti:
>> Hello,
>>
> Hello,
>> I'm wondering why cedrus
>> https://github.com/FlorentRevest/linux-sunxi-cedrus
>> has never been
>> merged with linux-sunxi sunxi-next.
>>
> Because it is not ready to be
> merged. It depends on the v4l2
> request
> API, which was not merged and which is re-worked atm.
> Also, sunxi-cedrus itself is not in
> a finished state and is not as
> feature-complete to be merged. Anyway it might be something 
> for
> staging... Has there been a [RFC] on the mailing list at all?

 Where can I find a list of TODOs to get it ready to be merged?
>>>
>>> Assuming that the request API is in, we'd need to:
>>>  - Finish the MPEG4 support
>>>  - Work on more useful codecs (H264 comes to my mind)
>>>  - Implement the DRM planes support for
>>> the custom frame format
>>>  - Implement the DRM planes support for scaling
>>>  - Test it on more SoCs
>>>
>>> Or something along those lines.
>>
>> Lot of work to do
>
> Well... If it was fast and easy it would have been done already :)

 :))

>
>> I see it seems to be dead, no commit in 1 year.
>
> Yes, because the author did this
> during an internship, which ended
> ...
> Afaik nobody picked up his work yet.
>>>
>>> That's not entirely true. Some work has been
>>> done by Thomas (in CC),
>>> especially on the display engine side, but last time we talked 
>>> his
>>> work was not really upstreamable.
>>>
>>> We will also resume that effort starting next march.
>>
>> Is it possible a preview on a separate
>> Reporitory to start working on now?
>> Expecially to start porting everything done by
>> FlorentRevest to mainline,
>> admitted you've not already done.
>
> I'm not sure what you're asking for. Florent's work
> *was* on mainline.

 and then they took it off because it was unmantained?
 You've spoken about Thomas(in CC) not ready,
 maybe I could help on that if it's public to accelerate.
 If I'm able to of course, this is my primary concern.

 Otherwise, in which way can I help improving it to make
 it accept to linux-sunxi?
 Starting from Florent's work and porting it to sunxi-next to begin?
 And after that adding all features you've listed?
 Tell me what I can do(I repeat, if I'm able to).
>>>
>>> The bottleneck is that the Request API is not mainlined. We
>>> restarted work
>>> on it after a meeting a few weeks back where we all agreed
>>> on the roadmap
>>> so hopefully it will go into mainline Q1 or Q2 next year.
>>>
>>> That said, you can use Florent's patch series for further 
>>> development.
>>> It should be relatively easy to convert it to the final version of 
>>> the
>>> Request API. Just note that the public API of the final
>>> Request API will
>>> be somewhat different from the old version Florent's patch

[PATCH v3 1/2] media: staging: atomisp: fix for sparse "using plain integer as NULL pointer" warnings.

[Jeremy Sowden]

The "address" member of struct ia_css_host_data is a pointer-to-char, so define 
default as NULL.

Signed-off-by: Jeremy Sowden 
---
 .../css2400/runtime/isp_param/interface/ia_css_isp_param_types.h| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
index 8e651b80345a..6fee3f7fd184 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/isp_param/interface/ia_css_isp_param_types.h
@@ -95,7 +95,7 @@ union ia_css_all_memory_offsets {
 };
 
 #define IA_CSS_DEFAULT_ISP_MEM_PARAMS \
-   { { { { 0, 0 } } } }
+   { { { { NULL, 0 } } } }
 
 #define IA_CSS_DEFAULT_ISP_CSS_PARAMS \
{ { { { 0, 0 } } } }
-- 
2.15.0

[PATCH v2 0/3] Sparse fixes for the Atom ISP Staging Driver

[Jeremy Sowden]

Fixed some sparse warnings in the Atom ISP staging driver.

This time with longer commit messages. :)

I've chosen to ignore checkpatch.pl's suggestion to change the types of
the arrays in the second patch from int16_t to s16.

Jeremy Sowden (2):
  media: staging: atomisp: fix for sparse "using plain integer as NULL
pointer" warnings.
  media: staging: atomisp: fixes for "symbol was not declared. Should it
be static?" sparse warnings.

 .../isp/kernels/eed1_8/ia_css_eed1_8.host.c| 24 +++---
 .../isp_param/interface/ia_css_isp_param_types.h   |  2 +-
 2 files changed, 13 insertions(+), 13 deletions(-)


base-commit: 844056fd74ebdd826bd23a7d989597e15f478acb
-- 
2.15.0

Re: [linux-sunxi] Cedrus driver

[Maxime Ripard]

On Tue, Nov 28, 2017 at 12:20:59PM +0100, Thomas van Kleef wrote:
> > So, I have been rebasing to 4.14.0 and have the cedrus driver working.
> I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from 
> Hans
> Verkuil's media_tree. I have a patch available of the merge between these 2
> branches.
> After this I pulled the sunxi-cedrus repository from Florent Revests github. I
> believe this one is the same as the ones you are cloning right now.
> I have merged this and have a patch available for this as well.
> 
> So to summarize:
>  o pulled linux 4.14 from:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>  o pulled requests2 from:
> https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2
> will be replaced with the work, when it is done, in:
>  https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2
>  o pulled linux-sunxi-cedrus from:
> https://github.com/FlorentRevest/linux-sunxi-cedrus
> 
>  o merged and made patch between linux4.14 and requests2
>  o merged and made patch with linux-sunxi-cedrus
>  o Verified that the video-engine is decofing mpeg-2 on the Allwinner A20.
> 
> So maybe if someone is interested in this, I could place the patches 
> somewhere?
> Just let me know.

Please create a pull request on the github repo. The point we set it
up was to share code. Forking repos and so on is kind of pointless.

> It would be nice to be able to play a file, so I would have to prepare our
> custom player and make a patch between the current sunxi-cedrus-drv-video and
> the one on https://github.com/FlorentRevest/sunxi-cedrus-drv-video.
> So I will start with this if there is any interest.
> 
> Should I be working in sunxi-next I wonder?

I'd rather stick on 4.14. sunxi-next wouldn't bring any benefit, and
we want to provide something that works first, and always merging next
will always distract us from the actual code.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v5 2/2] media: i2c: Add the ov7740 image sensor driver

[Sakari Ailus]

Hi Wenyou,

Thanks for the patch. Some comments below.

On Tue, Nov 28, 2017 at 01:22:59PM +0800, Wenyou Yang wrote:
> The ov7740 (color) image sensor is a high performance VGA CMOS
> image snesor, which supports for output formats: RAW RGB and YUV
> and image sizes: VGA, and QVGA, CIF and any size smaller.
> 
> Signed-off-by: Songjun Wu 
> Signed-off-by: Wenyou Yang 
> ---
> 
> Changes in v5:
>  - Squash the driver and MAINTAINERS entry patches to one.
>  - Precede the driver patch with the bindings patch.
> 
> Changes in v4:
>  - Assign 'val' a initial value to avoid warning: 'val' may be
>used uninitialized.
>  - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.
> 
> Changes in v3:
>  - Put the MAINTAINERS change to a separate patch.
> 
> Changes in v2:
>  - Split off the bindings into a separate patch.
>  - Add a new entry to the MAINTAINERS file.
> 
>  MAINTAINERS|8 +
>  drivers/media/i2c/Kconfig  |8 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/ov7740.c | 1220 
> 
>  4 files changed, 1237 insertions(+)
>  create mode 100644 drivers/media/i2c/ov7740.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index aa71ab52fd76..19086a073ae9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10053,6 +10053,14 @@ S:   Maintained
>  F:   drivers/media/i2c/ov7670.c
>  F:   Documentation/devicetree/bindings/media/i2c/ov7670.txt
>  
> +OMNIVISION OV7740 SENSOR DRIVER
> +M:   Wenyou Yang 
> +L:   linux-media@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Maintained
> +F:   drivers/media/i2c/ov7740.c
> +F:   Documentation/devicetree/bindings/media/i2c/ov7740.txt
> +
>  ONENAND FLASH DRIVER
>  M:   Kyungmin Park 
>  L:   linux-...@lists.infradead.org
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 3c6d6428f525..ac484bb82fae 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -665,6 +665,14 @@ config VIDEO_OV7670
> OV7670 VGA camera.  It currently only works with the M88ALP01
> controller.
>  
> +config VIDEO_OV7740
> + tristate "OmniVision OV7740 sensor support"
> + depends on I2C && VIDEO_V4L2
> + depends on MEDIA_CAMERA_SUPPORT
> + ---help---
> +   This is a Video4Linux2 sensor-level driver for the OmniVision
> +   OV7740 VGA camera sensor.
> +
>  config VIDEO_OV9650
>   tristate "OmniVision OV9650/OV9652 sensor support"
>   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 548a9efce966..9b19ec7fcaf4 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
>  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
>  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
>  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
> +obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
>  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
>  obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
>  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
> diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
> new file mode 100644
> index ..b2ec015bf3f6
> --- /dev/null
> +++ b/drivers/media/i2c/ov7740.c
> @@ -0,0 +1,1220 @@
> +/*
> + * Copyright (c) 2017 Microchip Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Do you need init.h?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define REG_OUTSIZE_LSB 0x34
> +
> +/* OV7740 register tables */
> +#define REG_GAIN 0x00/* Gain lower 8 bits (rest in vref) */
> +#define REG_BGAIN0x01/* blue gain */
> +#define REG_RGAIN0x02/* red gain */
> +#define REG_GGAIN0x03/* green gain */
> +#define REG_REG040x04/* analog setting, dont change*/
> +#define REG_BAVG 0x05/* b channel average */
> +#define REG_GAVG 0x06/* g channel average */
> +#define REG_RAVG 0x07/* r channel average */
> +
> +#define REG_REG0C0x0C/* filp enable */
> +#define REG0C_IMG_FLIP   0x80
> +#define REG0C_IMG_MIRROR 0x40
> +
> +#define REG_REG0E0x0E/* blc line */
> +#define REG_HAEC 0x0F/* auto exposure cntrl */
> +#define REG_AEC  0x10/* auto exposure cntrl */
> +
> +#define REG_CLK  0x11/* Clock control */
> +#define 

[PATCH] media: ov13858: select V4L2_FWNODE

[Arnd Bergmann]

v4l2_async_register_subdev_sensor_common() is only provided when
CONFIG_V4L2_FWNODE is enabled, otherwise we get a link failure:

drivers/media/i2c/ov13858.o: In function `ov13858_probe':
ov13858.c:(.text+0xf74): undefined reference to 
`v4l2_async_register_subdev_sensor_common'

This adds a Kconfig 'select' statement like all the other users of
this interface have.

Fixes: 2e8a9fbb7950 ("media: ov13858: Add support for flash and lens devices")
Signed-off-by: Arnd Bergmann 
---
This is the same patch I submitted for et8ek8 earlier. Both
are needed for 4.15.
---
 drivers/media/i2c/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 3c6d6428f525..cb5d7ff82915 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -676,6 +676,7 @@ config VIDEO_OV13858
tristate "OmniVision OV13858 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
+   select V4L2_FWNODE
---help---
  This is a Video4Linux2 sensor-level driver for the OmniVision
  OV13858 camera.
-- 
2.9.0

Re: [linux-sunxi] Cedrus driver

[Giulio Benetti]

Hi Thomas,

Il 28/11/2017 12:29, Thomas van Kleef ha scritto:

Hi,

On 28-11-17 12:26, Giulio Benetti wrote:

Hi Thomas,

Il 28/11/2017 12:20, Thomas van Kleef ha scritto:

On 28-11-17 10:50, Giulio Benetti wrote:

Hi Maxime,

Il 28/11/2017 09:35, Maxime Ripard ha scritto:

On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote:

Hi Maxime,

Il 16/11/2017 14:42, Giulio Benetti ha scritto:

Hi,

Il 16/11/2017 14:39, Maxime Ripard ha scritto:

On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote:

Hi Hans,

Il 16/11/2017 14:12, Hans Verkuil ha scritto:

On 16/11/17 13:57, Giulio Benetti wrote:

Il 16/11/2017 13:53, Maxime Ripard ha scritto:

On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote:

On Thu, Nov 16, 2017 at 11:37:30AM +0100, Giulio Benetti wrote:

Il 16/11/2017 11:31, Andreas Baierl ha scritto:

Am 16.11.2017 um 11:13 schrieb Giulio Benetti:

Hello,


Hello,

I'm wondering why cedrus
https://github.com/FlorentRevest/linux-sunxi-cedrus
has never been
merged with linux-sunxi sunxi-next.


Because it is not ready to be
merged. It depends on the v4l2
request
API, which was not merged and which is re-worked atm.
Also, sunxi-cedrus itself is not in
a finished state and is not as
feature-complete to be merged. Anyway it might be something for
staging... Has there been a [RFC] on the mailing list at all?


Where can I find a list of TODOs to get it ready to be merged?


Assuming that the request API is in, we'd need to:
     - Finish the MPEG4 support
     - Work on more useful codecs (H264 comes to my mind)
     - Implement the DRM planes support for
the custom frame format
     - Implement the DRM planes support for scaling
     - Test it on more SoCs

Or something along those lines.


Lot of work to do


Well... If it was fast and easy it would have been done already :)


:))




I see it seems to be dead, no commit in 1 year.


Yes, because the author did this
during an internship, which ended
...
Afaik nobody picked up his work yet.


That's not entirely true. Some work has been
done by Thomas (in CC),
especially on the display engine side, but last time we talked his
work was not really upstreamable.

We will also resume that effort starting next march.


Is it possible a preview on a separate
Reporitory to start working on now?
Expecially to start porting everything done by
FlorentRevest to mainline,
admitted you've not already done.


I'm not sure what you're asking for. Florent's work
*was* on mainline.


and then they took it off because it was unmantained?
You've spoken about Thomas(in CC) not ready,
maybe I could help on that if it's public to accelerate.
If I'm able to of course, this is my primary concern.

Otherwise, in which way can I help improving it to make
it accept to linux-sunxi?
Starting from Florent's work and porting it to sunxi-next to begin?
And after that adding all features you've listed?
Tell me what I can do(I repeat, if I'm able to).


The bottleneck is that the Request API is not mainlined. We
restarted work
on it after a meeting a few weeks back where we all agreed
on the roadmap
so hopefully it will go into mainline Q1 or Q2 next year.

That said, you can use Florent's patch series for further development.
It should be relatively easy to convert it to the final version of the
Request API. Just note that the public API of the final
Request API will
be somewhat different from the old version Florent's patch
series is using.


So I'm going to try soon to :
1) adapt that patchset to sunxi-next
2) add A20 support
3) add A33 support
4) after mainlined APIs, merge


That sounds good. Thomas already has the support for the A20, and as I
was saying, there is someone that is going to work full time on this
in a couple monthes on our side.

I'll set up a git repo on github so that we can collaborate until the
request API is ready.


Any news about git repo?
When do you plan to do it more or less?


I started to do it yesterday.

https://github.com/free-electrons/linux-cedrus
https://github.com/free-electrons/libva-cedrus


Great, I'm cloning.
1st: have it working with A20 with kernel as is and libva as buildroot package
2nd: porting to sunxi-next branch of linux-sunxi and check libva if can work as 
is

Thank you
So, I have been rebasing to 4.14.0 and have the cedrus driver working.

I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from Hans
Verkuil's media_tree. I have a patch available of the merge between these 2
branches.
After this I pulled the sunxi-cedrus repository from Florent Revests github. I
believe this one is the same as the ones you are cloning right now.
I have merged this and have a patch available for this as well.

So to summarize:
   o pulled linux 4.14 from:
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
   o pulled requests2 from:
  https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2
  will be replaced with the work, when it is done, in:
   

[PATCH] media: dvb_usb_pctv452e: module refcount changes were unbalanced

[Wolfgang Rohdewald]

dvb_frontend will call dvb_detach for:
- stb0899_detach in dvb_frontend_release and
- stb0899_release in __dvb_frontend_free

But we only do dvb_attach(stb0899_attach).
Increment the module refcount instead.

Signed-off-by: Wolfgang Rohdewald 
---
 drivers/media/usb/dvb-usb/pctv452e.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/usb/dvb-usb/pctv452e.c 
b/drivers/media/usb/dvb-usb/pctv452e.c
index 601ade7ca48d..3b7f8298b24d 100644
--- a/drivers/media/usb/dvb-usb/pctv452e.c
+++ b/drivers/media/usb/dvb-usb/pctv452e.c
@@ -913,6 +913,14 @@ static int pctv452e_frontend_attach(struct dvb_usb_adapter 
*a)
>dev->i2c_adap);
if (!a->fe_adap[0].fe)
return -ENODEV;
+
+   /*
+* dvb_frontend will call dvb_detach for both stb0899_detach
+* and stb0899_release but we only do dvb_attach(stb0899_attach).
+* Increment the module refcount instead.
+*/
+   symbol_get(stb0899_attach);
+
if ((dvb_attach(lnbp22_attach, a->fe_adap[0].fe,
>dev->i2c_adap)) == NULL)
err("Cannot attach lnbp22\n");
-- 
2.11.0

Re: [linux-sunxi] Cedrus driver

[Thomas van Kleef]

Hi,

On 28-11-17 12:26, Giulio Benetti wrote:
> Hi Thomas,
> 
> Il 28/11/2017 12:20, Thomas van Kleef ha scritto:
>> On 28-11-17 10:50, Giulio Benetti wrote:
>>> Hi Maxime,
>>>
>>> Il 28/11/2017 09:35, Maxime Ripard ha scritto:
 On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote:
> Hi Maxime,
>
> Il 16/11/2017 14:42, Giulio Benetti ha scritto:
>> Hi,
>>
>> Il 16/11/2017 14:39, Maxime Ripard ha scritto:
>>> On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote:
 Hi Hans,

 Il 16/11/2017 14:12, Hans Verkuil ha scritto:
> On 16/11/17 13:57, Giulio Benetti wrote:
>> Il 16/11/2017 13:53, Maxime Ripard ha scritto:
>>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote:
> On Thu, Nov 16, 2017 at 11:37:30AM +0100, Giulio Benetti wrote:
>> Il 16/11/2017 11:31, Andreas Baierl ha scritto:
>>> Am 16.11.2017 um 11:13 schrieb Giulio Benetti:
 Hello,

>>> Hello,
 I'm wondering why cedrus
 https://github.com/FlorentRevest/linux-sunxi-cedrus
 has never been
 merged with linux-sunxi sunxi-next.

>>> Because it is not ready to be
>>> merged. It depends on the v4l2
>>> request
>>> API, which was not merged and which is re-worked atm.
>>> Also, sunxi-cedrus itself is not in
>>> a finished state and is not as
>>> feature-complete to be merged. Anyway it might be something for
>>> staging... Has there been a [RFC] on the mailing list at all?
>>
>> Where can I find a list of TODOs to get it ready to be merged?
>
> Assuming that the request API is in, we'd need to:
>     - Finish the MPEG4 support
>     - Work on more useful codecs (H264 comes to my mind)
>     - Implement the DRM planes support for
> the custom frame format
>     - Implement the DRM planes support for scaling
>     - Test it on more SoCs
>
> Or something along those lines.

 Lot of work to do
>>>
>>> Well... If it was fast and easy it would have been done already :)
>>
>> :))
>>
>>>
 I see it seems to be dead, no commit in 1 year.
>>>
>>> Yes, because the author did this
>>> during an internship, which ended
>>> ...
>>> Afaik nobody picked up his work yet.
>
> That's not entirely true. Some work has been
> done by Thomas (in CC),
> especially on the display engine side, but last time we talked his
> work was not really upstreamable.
>
> We will also resume that effort starting next march.

 Is it possible a preview on a separate
 Reporitory to start working on now?
 Expecially to start porting everything done by
 FlorentRevest to mainline,
 admitted you've not already done.
>>>
>>> I'm not sure what you're asking for. Florent's work
>>> *was* on mainline.
>>
>> and then they took it off because it was unmantained?
>> You've spoken about Thomas(in CC) not ready,
>> maybe I could help on that if it's public to accelerate.
>> If I'm able to of course, this is my primary concern.
>>
>> Otherwise, in which way can I help improving it to make
>> it accept to linux-sunxi?
>> Starting from Florent's work and porting it to sunxi-next to begin?
>> And after that adding all features you've listed?
>> Tell me what I can do(I repeat, if I'm able to).
>
> The bottleneck is that the Request API is not mainlined. We
> restarted work
> on it after a meeting a few weeks back where we all agreed
> on the roadmap
> so hopefully it will go into mainline Q1 or Q2 next year.
>
> That said, you can use Florent's patch series for further development.
> It should be relatively easy to convert it to the final version of the
> Request API. Just note that the public API of the final
> Request API will
> be somewhat different from the old version Florent's patch
> series is using.

 So I'm going to try soon to :
 1) adapt that patchset to sunxi-next
 2) add A20 support
 3) add A33 support
 4) after mainlined APIs, merge
>>>
>>> That sounds good. Thomas already has the support for the A20, and as I
>>> was saying, there is someone that is going to work full time on this
>>> in a couple monthes on 

Re: [linux-sunxi] Cedrus driver

[Thomas van Kleef]

On 28-11-17 10:50, Giulio Benetti wrote:
> Hi Maxime,
> 
> Il 28/11/2017 09:35, Maxime Ripard ha scritto:
>> On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote:
>>> Hi Maxime,
>>>
>>> Il 16/11/2017 14:42, Giulio Benetti ha scritto:
 Hi,

 Il 16/11/2017 14:39, Maxime Ripard ha scritto:
> On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote:
>> Hi Hans,
>>
>> Il 16/11/2017 14:12, Hans Verkuil ha scritto:
>>> On 16/11/17 13:57, Giulio Benetti wrote:
 Il 16/11/2017 13:53, Maxime Ripard ha scritto:
> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote:
>>> On Thu, Nov 16, 2017 at 11:37:30AM +0100, Giulio Benetti wrote:
 Il 16/11/2017 11:31, Andreas Baierl ha scritto:
> Am 16.11.2017 um 11:13 schrieb Giulio Benetti:
>> Hello,
>>
> Hello,
>> I'm wondering why cedrus
>> https://github.com/FlorentRevest/linux-sunxi-cedrus
>> has never been
>> merged with linux-sunxi sunxi-next.
>>
> Because it is not ready to be
> merged. It depends on the v4l2
> request
> API, which was not merged and which is re-worked atm.
> Also, sunxi-cedrus itself is not in
> a finished state and is not as
> feature-complete to be merged. Anyway it might be something for
> staging... Has there been a [RFC] on the mailing list at all?

 Where can I find a list of TODOs to get it ready to be merged?
>>>
>>> Assuming that the request API is in, we'd need to:
>>>    - Finish the MPEG4 support
>>>    - Work on more useful codecs (H264 comes to my mind)
>>>    - Implement the DRM planes support for
>>> the custom frame format
>>>    - Implement the DRM planes support for scaling
>>>    - Test it on more SoCs
>>>
>>> Or something along those lines.
>>
>> Lot of work to do
>
> Well... If it was fast and easy it would have been done already :)

 :))

>
>> I see it seems to be dead, no commit in 1 year.
>
> Yes, because the author did this
> during an internship, which ended
> ...
> Afaik nobody picked up his work yet.
>>>
>>> That's not entirely true. Some work has been
>>> done by Thomas (in CC),
>>> especially on the display engine side, but last time we talked his
>>> work was not really upstreamable.
>>>
>>> We will also resume that effort starting next march.
>>
>> Is it possible a preview on a separate
>> Reporitory to start working on now?
>> Expecially to start porting everything done by
>> FlorentRevest to mainline,
>> admitted you've not already done.
>
> I'm not sure what you're asking for. Florent's work
> *was* on mainline.

 and then they took it off because it was unmantained?
 You've spoken about Thomas(in CC) not ready,
 maybe I could help on that if it's public to accelerate.
 If I'm able to of course, this is my primary concern.

 Otherwise, in which way can I help improving it to make
 it accept to linux-sunxi?
 Starting from Florent's work and porting it to sunxi-next to begin?
 And after that adding all features you've listed?
 Tell me what I can do(I repeat, if I'm able to).
>>>
>>> The bottleneck is that the Request API is not mainlined. We
>>> restarted work
>>> on it after a meeting a few weeks back where we all agreed
>>> on the roadmap
>>> so hopefully it will go into mainline Q1 or Q2 next year.
>>>
>>> That said, you can use Florent's patch series for further development.
>>> It should be relatively easy to convert it to the final version of the
>>> Request API. Just note that the public API of the final
>>> Request API will
>>> be somewhat different from the old version Florent's patch
>>> series is using.
>>
>> So I'm going to try soon to :
>> 1) adapt that patchset to sunxi-next
>> 2) add A20 support
>> 3) add A33 support
>> 4) after mainlined APIs, merge
>
> That sounds good. Thomas already has the support for the A20, and as I
> was saying, there is someone that is going to work full time on this
> in a couple monthes on our side.
>
> I'll set up a git repo on github so that we can collaborate until the
> request API is ready.
>>>
>>> Any news about git repo?
>>> When do you plan to do it more or less?
>>
>> I started to do it yesterday.
>>
>> https://github.com/free-electrons/linux-cedrus
>> https://github.com/free-electrons/libva-cedrus
> 
> 

Re: [linux-sunxi] Cedrus driver

[Giulio Benetti]

Hi Thomas,

Il 28/11/2017 12:20, Thomas van Kleef ha scritto:

On 28-11-17 10:50, Giulio Benetti wrote:

Hi Maxime,

Il 28/11/2017 09:35, Maxime Ripard ha scritto:

On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote:

Hi Maxime,

Il 16/11/2017 14:42, Giulio Benetti ha scritto:

Hi,

Il 16/11/2017 14:39, Maxime Ripard ha scritto:

On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote:

Hi Hans,

Il 16/11/2017 14:12, Hans Verkuil ha scritto:

On 16/11/17 13:57, Giulio Benetti wrote:

Il 16/11/2017 13:53, Maxime Ripard ha scritto:

On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote:

On Thu, Nov 16, 2017 at 11:37:30AM +0100, Giulio Benetti wrote:

Il 16/11/2017 11:31, Andreas Baierl ha scritto:

Am 16.11.2017 um 11:13 schrieb Giulio Benetti:

Hello,


Hello,

I'm wondering why cedrus
https://github.com/FlorentRevest/linux-sunxi-cedrus
has never been
merged with linux-sunxi sunxi-next.


Because it is not ready to be
merged. It depends on the v4l2
request
API, which was not merged and which is re-worked atm.
Also, sunxi-cedrus itself is not in
a finished state and is not as
feature-complete to be merged. Anyway it might be something for
staging... Has there been a [RFC] on the mailing list at all?


Where can I find a list of TODOs to get it ready to be merged?


Assuming that the request API is in, we'd need to:
    - Finish the MPEG4 support
    - Work on more useful codecs (H264 comes to my mind)
    - Implement the DRM planes support for
the custom frame format
    - Implement the DRM planes support for scaling
    - Test it on more SoCs

Or something along those lines.


Lot of work to do


Well... If it was fast and easy it would have been done already :)


:))




I see it seems to be dead, no commit in 1 year.


Yes, because the author did this
during an internship, which ended
...
Afaik nobody picked up his work yet.


That's not entirely true. Some work has been
done by Thomas (in CC),
especially on the display engine side, but last time we talked his
work was not really upstreamable.

We will also resume that effort starting next march.


Is it possible a preview on a separate
Reporitory to start working on now?
Expecially to start porting everything done by
FlorentRevest to mainline,
admitted you've not already done.


I'm not sure what you're asking for. Florent's work
*was* on mainline.


and then they took it off because it was unmantained?
You've spoken about Thomas(in CC) not ready,
maybe I could help on that if it's public to accelerate.
If I'm able to of course, this is my primary concern.

Otherwise, in which way can I help improving it to make
it accept to linux-sunxi?
Starting from Florent's work and porting it to sunxi-next to begin?
And after that adding all features you've listed?
Tell me what I can do(I repeat, if I'm able to).


The bottleneck is that the Request API is not mainlined. We
restarted work
on it after a meeting a few weeks back where we all agreed
on the roadmap
so hopefully it will go into mainline Q1 or Q2 next year.

That said, you can use Florent's patch series for further development.
It should be relatively easy to convert it to the final version of the
Request API. Just note that the public API of the final
Request API will
be somewhat different from the old version Florent's patch
series is using.


So I'm going to try soon to :
1) adapt that patchset to sunxi-next
2) add A20 support
3) add A33 support
4) after mainlined APIs, merge


That sounds good. Thomas already has the support for the A20, and as I
was saying, there is someone that is going to work full time on this
in a couple monthes on our side.

I'll set up a git repo on github so that we can collaborate until the
request API is ready.


Any news about git repo?
When do you plan to do it more or less?


I started to do it yesterday.

https://github.com/free-electrons/linux-cedrus
https://github.com/free-electrons/libva-cedrus


Great, I'm cloning.
1st: have it working with A20 with kernel as is and libva as buildroot package
2nd: porting to sunxi-next branch of linux-sunxi and check libva if can work as 
is

Thank you
So, I have been rebasing to 4.14.0 and have the cedrus driver working.

I have pulled linux-mainline 4.14.0. Then pulled the requests2 branch from Hans
Verkuil's media_tree. I have a patch available of the merge between these 2
branches.
After this I pulled the sunxi-cedrus repository from Florent Revests github. I
believe this one is the same as the ones you are cloning right now.
I have merged this and have a patch available for this as well.

So to summarize:
  o pulled linux 4.14 from:
 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  o pulled requests2 from:
 https://git.linuxtv.org/hverkuil/media_tree.git?h=requests2
 will be replaced with the work, when it is done, in:
  https://git.linuxtv.org/hverkuil/media_tree.git?h=ctrl-req-v2
  o pulled linux-sunxi-cedrus from:
 

Re: [PATCH 1/4] staging: add missing blank line after declarations in atomisp-ov5693

[Riccardo S.]

On 11/28, jacopo mondi wrote:
> Hi Riccardo,
> 
> On Mon, Nov 27, 2017 at 10:44:10PM +0100, Riccardo Schirone wrote:
> > Signed-off-by: Riccardo Schirone 
> 
> No patch can be accepted without a commit message. I know subject is
> self-explanatory here, but please add some lines eg. reporting
> checkpatch warnings.
> 

Ok, I'll do it in V2.
Thanks,

Riccardo

[PATCH v3 2/2] media: staging: atomisp: fixes for "symbol was not declared. Should it be static?" sparse warnings.

[Jeremy Sowden]

Defined some const arrays as static since they don't need external linkage.

Signed-off-by: Jeremy Sowden 
---
 .../isp/kernels/eed1_8/ia_css_eed1_8.host.c| 24 +++---
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
index 682f8b709ff9..47bb5042381b 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/eed1_8/ia_css_eed1_8.host.c
@@ -32,44 +32,44 @@
 #define NUMBER_OF_TCINV_POINTS 9
 #define NUMBER_OF_FCINV_POINTS 9
 
-const int16_t chgrinv_x[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_x[NUMBER_OF_CHGRINV_POINTS] = {
 0, 16, 64, 144, 272, 448, 672, 976,
 1376, 1888, 2528, 3312, 4256, 5376, 6688};
 
-const int16_t chgrinv_a[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_a[NUMBER_OF_CHGRINV_POINTS] = {
 -7171, -256, -29, -3456, -1071, -475, -189, -102,
 -48, -38, -10, -9, -7, -6, 0};
 
-const int16_t chgrinv_b[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_b[NUMBER_OF_CHGRINV_POINTS] = {
 8191, 1021, 256, 114, 60, 37, 24, 17,
 12, 9, 6, 5, 4, 3, 2};
 
-const int16_t chgrinv_c[NUMBER_OF_CHGRINV_POINTS] = {
+static const int16_t chgrinv_c[NUMBER_OF_CHGRINV_POINTS] = {
 1, 1, 1, 0, 0, 0, 0, 0,
 0, 0, 0, 0, 0, 0, 0};
 
-const int16_t tcinv_x[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_x[NUMBER_OF_TCINV_POINTS] = {
 0, 4, 11, 23, 42, 68, 102, 148, 205};
 
-const int16_t tcinv_a[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_a[NUMBER_OF_TCINV_POINTS] = {
 -6364, -631, -126, -34, -13, -6, -4452, -2156, 0};
 
-const int16_t tcinv_b[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_b[NUMBER_OF_TCINV_POINTS] = {
 8191, 1828, 726, 352, 197, 121, 80, 55, 40};
 
-const int16_t tcinv_c[NUMBER_OF_TCINV_POINTS] = {
+static const int16_t tcinv_c[NUMBER_OF_TCINV_POINTS] = {
 1, 1, 1, 1, 1, 1, 0, 0, 0};
 
-const int16_t fcinv_x[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_x[NUMBER_OF_FCINV_POINTS] = {
 0, 80, 216, 456, 824, 1344, 2040, 2952, 4096};
 
-const int16_t fcinv_a[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_a[NUMBER_OF_FCINV_POINTS] = {
 -5244, -486, -86, -2849, -961, -400, -180, -86, 0};
 
-const int16_t fcinv_b[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_b[NUMBER_OF_FCINV_POINTS] = {
 8191, 1637, 607, 287, 159, 98, 64, 44, 32};
 
-const int16_t fcinv_c[NUMBER_OF_FCINV_POINTS] = {
+static const int16_t fcinv_c[NUMBER_OF_FCINV_POINTS] = {
 1, 1, 1, 0, 0, 0, 0, 0, 0};
 
 
-- 
2.15.0

Re: [PATCH 1/4] staging: add missing blank line after declarations in atomisp-ov5693

[jacopo mondi]

Hi Riccardo,

On Mon, Nov 27, 2017 at 10:44:10PM +0100, Riccardo Schirone wrote:
> Signed-off-by: Riccardo Schirone 

No patch can be accepted without a commit message. I know subject is
self-explanatory here, but please add some lines eg. reporting
checkpatch warnings.

Thanks
   j

> ---
>  drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c 
> b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> index 3e7c3851280f..387c65be10f4 100644
> --- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> +++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> @@ -82,6 +82,7 @@ static int ad5823_i2c_write(struct i2c_client *client, u8 
> reg, u8 val)
>  {
>   struct i2c_msg msg;
>   u8 buf[2];
> +
>   buf[0] = reg;
>   buf[1] = val;
>   msg.addr = AD5823_VCM_ADDR;
> @@ -98,6 +99,7 @@ static int ad5823_i2c_read(struct i2c_client *client, u8 
> reg, u8 *val)
>  {
>   struct i2c_msg msg[2];
>   u8 buf[2];
> +
>   buf[0] = reg;
>   buf[1] = 0;
>
> @@ -228,6 +230,7 @@ static int vcm_detect(struct i2c_client *client)
>   int i, ret;
>   struct i2c_msg msg;
>   u16 data0 = 0, data;
> +
>   for (i = 0; i < 4; i++) {
>   msg.addr = VCM_ADDR;
>   msg.flags = I2C_M_RD;
> @@ -690,6 +693,7 @@ static long ov5693_s_exposure(struct v4l2_subdev *sd,
>   /* we should not accept the invalid value below */
>   if (analog_gain == 0) {
>   struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
>   v4l2_err(client, "%s: invalid value\n", __func__);
>   return -EINVAL;
>   }
> @@ -722,6 +726,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8 
> *buf)
>   int ret;
>   int i;
>   u8 *b = buf;
> +
>   dev->otp_size = 0;
>   for (i = 1; i < OV5693_OTP_BANK_MAX; i++) {
>   /*set bank NO and OTP read mode. */
> @@ -984,6 +989,7 @@ static int ov5693_t_focus_abs(struct v4l2_subdev *sd, s32 
> value)
>  static int ov5693_t_focus_rel(struct v4l2_subdev *sd, s32 value)
>  {
>   struct ov5693_device *dev = to_ov5693_sensor(sd);
> +
>   return ov5693_t_focus_abs(sd, dev->focus + value);
>  }
>
> @@ -1033,6 +1039,7 @@ static int ov5693_q_focus_abs(struct v4l2_subdev *sd, 
> s32 *value)
>  static int ov5693_t_vcm_slew(struct v4l2_subdev *sd, s32 value)
>  {
>   struct ov5693_device *dev = to_ov5693_sensor(sd);
> +
>   dev->number_of_steps = value;
>   dev->vcm_update = true;
>   return 0;
> @@ -1041,6 +1048,7 @@ static int ov5693_t_vcm_slew(struct v4l2_subdev *sd, 
> s32 value)
>  static int ov5693_t_vcm_timing(struct v4l2_subdev *sd, s32 value)
>  {
>   struct ov5693_device *dev = to_ov5693_sensor(sd);
> +
>   dev->number_of_steps = value;
>   dev->vcm_update = true;
>   return 0;
> @@ -1563,6 +1571,7 @@ static int ov5693_set_fmt(struct v4l2_subdev *sd,
>   struct camera_mipi_info *ov5693_info = NULL;
>   int ret = 0;
>   int idx;
> +
>   if (format->pad)
>   return -EINVAL;
>   if (!fmt)
> @@ -1599,6 +1608,7 @@ static int ov5693_set_fmt(struct v4l2_subdev *sd,
>   ret = startup(sd);
>   if (ret) {
>   int i = 0;
> +
>   dev_err(>dev, "ov5693 startup err, retry to power 
> up\n");
>   for (i = 0; i < OV5693_POWER_UP_RETRY_NUM; i++) {
>   dev_err(>dev,
> @@ -1655,6 +1665,7 @@ static int ov5693_get_fmt(struct v4l2_subdev *sd,
>  {
>   struct v4l2_mbus_framefmt *fmt = >format;
>   struct ov5693_device *dev = to_ov5693_sensor(sd);
> +
>   if (format->pad)
>   return -EINVAL;
>
> @@ -1818,6 +1829,7 @@ static int ov5693_s_parm(struct v4l2_subdev *sd,
>   struct v4l2_streamparm *param)
>  {
>   struct ov5693_device *dev = to_ov5693_sensor(sd);
> +
>   dev->run_mode = param->parm.capture.capturemode;
>
>   mutex_lock(>input_lock);
> @@ -1907,6 +1919,7 @@ static int ov5693_remove(struct i2c_client *client)
>  {
>   struct v4l2_subdev *sd = i2c_get_clientdata(client);
>   struct ov5693_device *dev = to_ov5693_sensor(sd);
> +
>   dev_dbg(>dev, "ov5693_remove...\n");
>
>   dev->platform_data->csi_cfg(sd, 0);
> --
> 2.14.3
>

Re: [PATCH 3/4] staging: improves comparisons readability in atomisp-ov5693

[jacopo mondi]

Hi Riccardo,
   thanks for the patch

On Mon, Nov 27, 2017 at 10:44:12PM +0100, Riccardo Schirone wrote:
> Fix "Comparisons should place the constant on the right side of the
> test" issue.
>
> Signed-off-by: Riccardo Schirone 
> ---
>  drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c 
> b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> index ecd607b7b005..4eeb478ae84b 100644
> --- a/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> +++ b/drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c
> @@ -764,7 +764,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8 
> *buf)
>   //pr_debug("BANK[%2d] %02x %02x %02x %02x %02x %02x %02x %02x 
> %02x %02x %02x %02x %02x %02x %02x %02x\n", i, *b, *(b+1), *(b+2), *(b+3), 
> *(b+4), *(b+5), *(b+6), *(b+7), *(b+8), *(b+9), *(b+10), *(b+11), *(b+12), 
> *(b+13), *(b+14), *(b+15));
>
>   //Intel OTP map, try to read 320byts first.
> - if (21 == i) {
> + if (i == 21) {
>   if ((*b) == 0) {
>   dev->otp_size = 320;
>   break;
> @@ -772,7 +772,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8 
> *buf)
>   b = buf;
>   continue;
>   }
> - } else if (24 == i) {   //if the first 320bytes data 
> doesn't not exist, try to read the next 32bytes data.
> + } else if (i == 24) {   //if the first 320bytes data 
> doesn't not exist, try to read the next 32bytes data.
>   if ((*b) == 0) {
>   dev->otp_size = 32;
>   break;
> @@ -780,7 +780,7 @@ static int __ov5693_otp_read(struct v4l2_subdev *sd, u8 
> *buf)
>   b = buf;
>   continue;
>   }
> - } else if (27 == i) {   //if the prvious 32bytes data 
> doesn't exist, try to read the next 32bytes data again.
> + } else if (i == 27) {   //if the prvious 32bytes data 
> doesn't exist, try to read the next 32bytes data again.

I wonder why checkpatch does not complain about these C++ style
comments clearly exceeding 80 columns...

>   if ((*b) == 0) {
>   dev->otp_size = 32;
>   break;
> @@ -1351,7 +1351,7 @@ static int __power_up(struct v4l2_subdev *sd)
>   struct i2c_client *client = v4l2_get_subdevdata(sd);
>   int ret;
>
> - if (NULL == dev->platform_data) {
> + if (!dev->platform_data) {

Please mention in changelog that you're also substituting a comparison to
NULL with this.

Checkpatch points this out, didn't it?

Thanks
   j

>   dev_err(>dev,
>   "no camera_sensor_platform_data");
>   return -ENODEV;
> @@ -1399,7 +1399,7 @@ static int power_down(struct v4l2_subdev *sd)
>   int ret = 0;
>
>   dev->focus = OV5693_INVALID_CONFIG;
> - if (NULL == dev->platform_data) {
> + if (!dev->platform_data) {
>   dev_err(>dev,
>   "no camera_sensor_platform_data");
>   return -ENODEV;
> --
> 2.14.3
>

Re: [linux-sunxi] Cedrus driver

[Giulio Benetti]

Hi Maxime,

Il 28/11/2017 09:35, Maxime Ripard ha scritto:

On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote:

Hi Maxime,

Il 16/11/2017 14:42, Giulio Benetti ha scritto:

Hi,

Il 16/11/2017 14:39, Maxime Ripard ha scritto:

On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote:

Hi Hans,

Il 16/11/2017 14:12, Hans Verkuil ha scritto:

On 16/11/17 13:57, Giulio Benetti wrote:

Il 16/11/2017 13:53, Maxime Ripard ha scritto:

On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote:

On Thu, Nov 16, 2017 at 11:37:30AM +0100, Giulio Benetti wrote:

Il 16/11/2017 11:31, Andreas Baierl ha scritto:

Am 16.11.2017 um 11:13 schrieb Giulio Benetti:

Hello,


Hello,

I'm wondering why cedrus
https://github.com/FlorentRevest/linux-sunxi-cedrus
has never been
merged with linux-sunxi sunxi-next.


Because it is not ready to be
merged. It depends on the v4l2
request
API, which was not merged and which is re-worked atm.
Also, sunxi-cedrus itself is not in
a finished state and is not as
feature-complete to be merged. Anyway it might be something for
staging... Has there been a [RFC] on the mailing list at all?


Where can I find a list of TODOs to get it ready to be merged?


Assuming that the request API is in, we'd need to:
   - Finish the MPEG4 support
   - Work on more useful codecs (H264 comes to my mind)
   - Implement the DRM planes support for
the custom frame format
   - Implement the DRM planes support for scaling
   - Test it on more SoCs

Or something along those lines.


Lot of work to do


Well... If it was fast and easy it would have been done already :)


:))




I see it seems to be dead, no commit in 1 year.


Yes, because the author did this
during an internship, which ended
...
Afaik nobody picked up his work yet.


That's not entirely true. Some work has been
done by Thomas (in CC),
especially on the display engine side, but last time we talked his
work was not really upstreamable.

We will also resume that effort starting next march.


Is it possible a preview on a separate
Reporitory to start working on now?
Expecially to start porting everything done by
FlorentRevest to mainline,
admitted you've not already done.


I'm not sure what you're asking for. Florent's work
*was* on mainline.


and then they took it off because it was unmantained?
You've spoken about Thomas(in CC) not ready,
maybe I could help on that if it's public to accelerate.
If I'm able to of course, this is my primary concern.

Otherwise, in which way can I help improving it to make
it accept to linux-sunxi?
Starting from Florent's work and porting it to sunxi-next to begin?
And after that adding all features you've listed?
Tell me what I can do(I repeat, if I'm able to).


The bottleneck is that the Request API is not mainlined. We
restarted work
on it after a meeting a few weeks back where we all agreed
on the roadmap
so hopefully it will go into mainline Q1 or Q2 next year.

That said, you can use Florent's patch series for further development.
It should be relatively easy to convert it to the final version of the
Request API. Just note that the public API of the final
Request API will
be somewhat different from the old version Florent's patch
series is using.


So I'm going to try soon to :
1) adapt that patchset to sunxi-next
2) add A20 support
3) add A33 support
4) after mainlined APIs, merge


That sounds good. Thomas already has the support for the A20, and as I
was saying, there is someone that is going to work full time on this
in a couple monthes on our side.

I'll set up a git repo on github so that we can collaborate until the
request API is ready.


Any news about git repo?
When do you plan to do it more or less?


I started to do it yesterday.

https://github.com/free-electrons/linux-cedrus
https://github.com/free-electrons/libva-cedrus


Great, I'm cloning.
1st: have it working with A20 with kernel as is and libva as buildroot 
package
2nd: porting to sunxi-next branch of linux-sunxi and check libva if can 
work as is


Thank you



Maxime




--
Giulio Benetti
R Manager &
Advanced Research

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642

Re: [linux-sunxi] Cedrus driver

[Maxime Ripard]

On Tue, Nov 28, 2017 at 01:03:59AM +0100, Giulio Benetti wrote:
> Hi Maxime,
> 
> Il 16/11/2017 14:42, Giulio Benetti ha scritto:
> > Hi,
> > 
> > Il 16/11/2017 14:39, Maxime Ripard ha scritto:
> > > On Thu, Nov 16, 2017 at 02:17:08PM +0100, Giulio Benetti wrote:
> > > > Hi Hans,
> > > > 
> > > > Il 16/11/2017 14:12, Hans Verkuil ha scritto:
> > > > > On 16/11/17 13:57, Giulio Benetti wrote:
> > > > > > Il 16/11/2017 13:53, Maxime Ripard ha scritto:
> > > > > > > On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote:
> > > > > > > > > On Thu, Nov 16, 2017 at 11:37:30AM +0100, Giulio Benetti 
> > > > > > > > > wrote:
> > > > > > > > > > Il 16/11/2017 11:31, Andreas Baierl ha scritto:
> > > > > > > > > > > Am 16.11.2017 um 11:13 schrieb Giulio Benetti:
> > > > > > > > > > > > Hello,
> > > > > > > > > > > > 
> > > > > > > > > > > Hello,
> > > > > > > > > > > > I'm wondering why cedrus
> > > > > > > > > > > > https://github.com/FlorentRevest/linux-sunxi-cedrus
> > > > > > > > > > > > has never been
> > > > > > > > > > > > merged with linux-sunxi sunxi-next.
> > > > > > > > > > > > 
> > > > > > > > > > > Because it is not ready to be
> > > > > > > > > > > merged. It depends on the v4l2
> > > > > > > > > > > request
> > > > > > > > > > > API, which was not merged and which is re-worked atm.
> > > > > > > > > > > Also, sunxi-cedrus itself is not in
> > > > > > > > > > > a finished state and is not as
> > > > > > > > > > > feature-complete to be merged. Anyway it might be 
> > > > > > > > > > > something for
> > > > > > > > > > > staging... Has there been a [RFC] on the mailing list at 
> > > > > > > > > > > all?
> > > > > > > > > > 
> > > > > > > > > > Where can I find a list of TODOs to get it ready to be 
> > > > > > > > > > merged?
> > > > > > > > > 
> > > > > > > > > Assuming that the request API is in, we'd need to:
> > > > > > > > >   - Finish the MPEG4 support
> > > > > > > > >   - Work on more useful codecs (H264 comes to my mind)
> > > > > > > > >   - Implement the DRM planes support for
> > > > > > > > > the custom frame format
> > > > > > > > >   - Implement the DRM planes support for scaling
> > > > > > > > >   - Test it on more SoCs
> > > > > > > > > 
> > > > > > > > > Or something along those lines.
> > > > > > > > 
> > > > > > > > Lot of work to do
> > > > > > > 
> > > > > > > Well... If it was fast and easy it would have been done already :)
> > > > > > 
> > > > > > :))
> > > > > > 
> > > > > > > 
> > > > > > > > > > > > I see it seems to be dead, no commit in 1 year.
> > > > > > > > > > > 
> > > > > > > > > > > Yes, because the author did this
> > > > > > > > > > > during an internship, which ended
> > > > > > > > > > > ...
> > > > > > > > > > > Afaik nobody picked up his work yet.
> > > > > > > > > 
> > > > > > > > > That's not entirely true. Some work has been
> > > > > > > > > done by Thomas (in CC),
> > > > > > > > > especially on the display engine side, but last time we 
> > > > > > > > > talked his
> > > > > > > > > work was not really upstreamable.
> > > > > > > > > 
> > > > > > > > > We will also resume that effort starting next march.
> > > > > > > > 
> > > > > > > > Is it possible a preview on a separate
> > > > > > > > Reporitory to start working on now?
> > > > > > > > Expecially to start porting everything done by
> > > > > > > > FlorentRevest to mainline,
> > > > > > > > admitted you've not already done.
> > > > > > > 
> > > > > > > I'm not sure what you're asking for. Florent's work
> > > > > > > *was* on mainline.
> > > > > > 
> > > > > > and then they took it off because it was unmantained?
> > > > > > You've spoken about Thomas(in CC) not ready,
> > > > > > maybe I could help on that if it's public to accelerate.
> > > > > > If I'm able to of course, this is my primary concern.
> > > > > > 
> > > > > > Otherwise, in which way can I help improving it to make
> > > > > > it accept to linux-sunxi?
> > > > > > Starting from Florent's work and porting it to sunxi-next to begin?
> > > > > > And after that adding all features you've listed?
> > > > > > Tell me what I can do(I repeat, if I'm able to).
> > > > > 
> > > > > The bottleneck is that the Request API is not mainlined. We
> > > > > restarted work
> > > > > on it after a meeting a few weeks back where we all agreed
> > > > > on the roadmap
> > > > > so hopefully it will go into mainline Q1 or Q2 next year.
> > > > > 
> > > > > That said, you can use Florent's patch series for further development.
> > > > > It should be relatively easy to convert it to the final version of the
> > > > > Request API. Just note that the public API of the final
> > > > > Request API will
> > > > > be somewhat different from the old version Florent's patch
> > > > > series is using.
> > > > 
> > > > So I'm going to try soon to :
> > > > 1) adapt that patchset to sunxi-next
> > > > 2) add A20 support
> > > > 3) add A33 support
> > > > 4) after mainlined APIs, merge
> > > 
> > > That sounds good. Thomas already has the