Re: soc-camera: opinion poll - future directions

[Hans Verkuil]

On 05/03/2015 07:45 PM, Guennadi Liakhovetski wrote:
 Hi Hans,
 
 On Sun, 3 May 2015, Hans Verkuil wrote:
 
 Hi Guennadi,

 On 05/03/2015 06:11 PM, Guennadi Liakhovetski wrote:
 Hi all,

 Just a quick opinion poll - where and how should the soc-camera framework 
 and drivers be heading? Possible (probably not all) directions:

 (1) all is good, keep as is. That means keep all drivers, killing them off 
 only when it becomes very obvious, that noone wants them, keep developing 
 drivers, that are still being used and updating all of them on any API 
 updates. Keep me as maintainer, which means slow patch processing rate and 
 no active participation in new developments - at hardware, soc-camera or 
 V4L levels.

 (2) we want more! I.e. some contributors are planning to either add new 
 drivers to it or significantly develop existing ones, see significant 
 benefit in it. In this case it might become necessary to replace me with 
 someone, who can be more active in this area.

 (3) slowly phase out. Try to either deprecate and remove soc-camera 
 drivers one by one or move them out to become independent V4L2 host or 
 subdevice drivers, but keep updating while still there.

 (4) basically as (3) but even more aggressively - get rid of it ASAP:)

 Opinions? Expecially would be interesting to hear from respective 
 host-driver maintainers / developers, sorry, not adding CCs, they probably 
 read the list anyway:)

 I'm closest to 1. I would certainly not use it for new drivers, I see no
 reason to do that anymore. The core frameworks are quite good these days
 and I think the need for soc-camera has basically disappeared. But there
 is no need to phase out or remove soc-camera drivers (unless they are
 clearly broken and nobody will fix them). And if someone wants to turn
 a soc-camera driver into a standalone driver, then I would encourage
 that.
 
 Understand, thanks.
 
 However, there are two things that need work fairly soon:

 1) the dependency of subdev drivers on soc_camera: that has to go. I plan
 to work on that, but the first step is to replace the video crop ops by
 the pad selection ops. I finally got my Renesas sh7724 board up and running,
 
 Uhm... Does anyone really still care about V4L on SuperH?..

I am :-)

It's the only soc-camera board I have, so it's good to have it working.

 
 so I hope to make progress on this soon. I'll update soc-camera as well
 to conform to v4l2-compliance. Once that's done I will investigate how to
 remove the soc-camera dependency.

 The soc-camera dependency kills the reusability of those drivers and it
 really needs to be addressed.

 2) Converting soc-camera videobuf drivers to vb2. At some point vb1 will be
 removed, so any remaining vb1 driver will likely be killed off if nobody does
 the conversion. I believe it is only omap1 and pxa that still use videobuf.

 I think omap1 might be a candidate for removal, but I don't know about the 
 pxa.
 Guennadi, what is the status of these drivers?
 
 Dont know, sorry. PXA in general seems to still be quite actively 
 maintained - I recently saw a patch series for PXA CCF support, so, 
 probably V4L is still in use too.
 
 If I would do a vb2 conversion
 for the pxa, would you be able to test it?
 
 I have a board with PXA270, and it still seems to be in the mainline, but 
 I don't know how easy it would be to get it running with a current kernel.

Can you take a look? If you can get it running, then I can make a patch for
you to try. But I don't want to put time into that unless I know you can
test it.

I think it is reasonable to phase out the omap1 driver: move it to staging
first and if nobody complains remove it altogether.

Regards,

Hans

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] imx074: don't call imx074_find_datafmt() twice

[Hans Verkuil]

On 05/03/2015 07:54 PM, Guennadi Liakhovetski wrote:
 Hi Hans,
 
 Thanks for fixing the drivers!
 
 On Sun, 3 May 2015, Hans Verkuil wrote:
 
 From: Hans Verkuil hans.verk...@cisco.com

 Simplify imx074_set_fmt().

 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 Reported-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
  drivers/media/i2c/soc_camera/imx074.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

 diff --git a/drivers/media/i2c/soc_camera/imx074.c 
 b/drivers/media/i2c/soc_camera/imx074.c
 index f68c235..4226f06 100644
 --- a/drivers/media/i2c/soc_camera/imx074.c
 +++ b/drivers/media/i2c/soc_camera/imx074.c
 @@ -171,8 +171,9 @@ static int imx074_set_fmt(struct v4l2_subdev *sd,
  /* MIPI CSI could have changed the format, double-check */
  if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
  return -EINVAL;
 -mf-code= imx074_colour_fmts[0].code;
 -mf-colorspace  = imx074_colour_fmts[0].colorspace;
 +fmt = imx074_colour_fmts;
 +mf-code = fmt-code;
 +mf-colorspace = fmt-colorspace;
 
 Uhm, why this change? I understand, that this is equivalent code, but (1) 
 is it at all related to the change? and (2) imx074_colour_fmts is an 
 array, so, I'd prefer to keep it as is. I do use pointer arithmetics for 
 array, but then I'd do something like

Ah, I missed the FORMAT_ACTIVE check just before these lines. You are right,
this change is not needed.

Regards,

Hans

 
 + fmt = imx074_colour_fmts + 0;
 + mf-code = fmt-code;
 + mf-colorspace = fmt-colorspace;
 
 which looks silly:) And then - even more importantly - you overwrite the 
 fmt variable, which is then used below instead of calling 
 imx074_find_datafmt() again. So, now you assign a (theoretically) 
 different value to priv-fmt. I know that array only has one element and 
 imx074_find_datafmt() will anyway just return it, but, I don't see why 
 this change is needed?
 
 Thanks
 Guennadi
 
  }
  
  mf-width   = IMX074_WIDTH;
 @@ -180,7 +181,7 @@ static int imx074_set_fmt(struct v4l2_subdev *sd,
  mf-field   = V4L2_FIELD_NONE;
  
  if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
 -priv-fmt = imx074_find_datafmt(mf-code);
 +priv-fmt = fmt;
  else
  cfg-try_fmt = *mf;
  
 -- 
 2.1.4


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/9] ov2640: avoid calling ov2640_select_win() twice

[Hans Verkuil]

On 05/03/2015 08:19 PM, Guennadi Liakhovetski wrote:
 Hi Hans,
 
 On Sun, 3 May 2015, Hans Verkuil wrote:
 
 From: Hans Verkuil hans.verk...@cisco.com

 Simplify ov2640_set_params and ov2640_set_fmt.

 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 Reported-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
  drivers/media/i2c/soc_camera/ov2640.c | 21 ++---
  1 file changed, 10 insertions(+), 11 deletions(-)

 diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
 b/drivers/media/i2c/soc_camera/ov2640.c
 index 9b4f5de..5dcaf24 100644
 --- a/drivers/media/i2c/soc_camera/ov2640.c
 +++ b/drivers/media/i2c/soc_camera/ov2640.c
 @@ -769,15 +769,15 @@ static const struct ov2640_win_size 
 *ov2640_select_win(u32 *width, u32 *height)
  return ov2640_supported_win_sizes[default_size];
  }
  
 -static int ov2640_set_params(struct i2c_client *client, u32 *width, u32 
 *height,
 - u32 code)
 +static int ov2640_set_params(struct i2c_client *client,
 + const struct ov2640_win_size *win, u32 code)
  {
  struct ov2640_priv   *priv = to_ov2640(client);
  const struct regval_list *selected_cfmt_regs;
  int ret;
  
  /* select win */
 -priv-win = ov2640_select_win(width, height);
 +priv-win = win;
  
  /* select format */
  priv-cfmt_code = 0;
 @@ -798,6 +798,7 @@ static int ov2640_set_params(struct i2c_client *client, 
 u32 *width, u32 *height,
  case MEDIA_BUS_FMT_UYVY8_2X8:
  dev_dbg(client-dev, %s: Selected cfmt UYVY, __func__);
  selected_cfmt_regs = ov2640_uyvy_regs;
 +break;
 
 Hm, IIRC, some versions of gcc complain like break at the end of a switch 
 statement is deprecated. Why did you add this at two locations? Are you 
 seeing a warning? If not, maybe better not do that.

I have never seen such a warning in 20 odd years of using gcc. It is bad 
practice
not to add a break at the end in case someone adds a new case later or shuffles
cases around and misses that there was no break.

And since 99% of all switch statements in the kernel have a break at the end,
I would say that any gcc issues with that would have been spotted ages ago.

Regards,

Hans

 
 Otherwise
 
 Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 
 Thanks
 Guennadi
 
  }
  
  /* reset hardware */
 @@ -832,8 +833,6 @@ static int ov2640_set_params(struct i2c_client *client, 
 u32 *width, u32 *height,
  goto err;
  
  priv-cfmt_code = code;
 -*width = priv-win-width;
 -*height = priv-win-height;
  
  return 0;
  
 @@ -887,14 +886,13 @@ static int ov2640_set_fmt(struct v4l2_subdev *sd,
  {
  struct v4l2_mbus_framefmt *mf = format-format;
  struct i2c_client *client = v4l2_get_subdevdata(sd);
 +const struct ov2640_win_size *win;
  
  if (format-pad)
  return -EINVAL;
  
 -/*
 - * select suitable win, but don't store it
 - */
 -ov2640_select_win(mf-width, mf-height);
 +/* select suitable win */
 +win = ov2640_select_win(mf-width, mf-height);
  
  mf-field   = V4L2_FIELD_NONE;
  
 @@ -905,14 +903,15 @@ static int ov2640_set_fmt(struct v4l2_subdev *sd,
  break;
  default:
  mf-code = MEDIA_BUS_FMT_UYVY8_2X8;
 +/* fall through */
  case MEDIA_BUS_FMT_YUYV8_2X8:
  case MEDIA_BUS_FMT_UYVY8_2X8:
  mf-colorspace = V4L2_COLORSPACE_JPEG;
 +break;
  }
  
  if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
 -return ov2640_set_params(client, mf-width,
 - mf-height, mf-code);
 +return ov2640_set_params(client, win, mf-code);
  cfg-try_fmt = *mf;
  return 0;
  }
 -- 
 2.1.4


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/9] ov5642: avoid calling ov5642_find_datafmt() twice

[Hans Verkuil]

On 05/03/2015 10:24 PM, Guennadi Liakhovetski wrote:
 Hi Hans,
 
 On Sun, 3 May 2015, Hans Verkuil wrote:
 
 From: Hans Verkuil hans.verk...@cisco.com

 Simplify ov5642_set_fmt().

 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 Reported-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
  drivers/media/i2c/soc_camera/ov5642.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

 diff --git a/drivers/media/i2c/soc_camera/ov5642.c 
 b/drivers/media/i2c/soc_camera/ov5642.c
 index bab9ac0..061fca3 100644
 --- a/drivers/media/i2c/soc_camera/ov5642.c
 +++ b/drivers/media/i2c/soc_camera/ov5642.c
 @@ -804,14 +804,15 @@ static int ov5642_set_fmt(struct v4l2_subdev *sd,
  if (!fmt) {
  if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
  return -EINVAL;
 -mf-code= ov5642_colour_fmts[0].code;
 -mf-colorspace  = ov5642_colour_fmts[0].colorspace;
 +fmt = ov5642_colour_fmts;
 +mf-code = fmt-code;
 +mf-colorspace = fmt-colorspace;
 
 Again - I still don't see why this is needed.

Same thing, missed the if statement just before these lines.

Will fix.

Hans

 
 Thanks
 Guennadi
 
  }
  
  mf-field   = V4L2_FIELD_NONE;
  
  if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
 -priv-fmt = ov5642_find_datafmt(mf-code);
 +priv-fmt = fmt;
  else
  cfg-try_fmt = *mf;
  return 0;
 -- 
 2.1.4


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 9/9] mt9t112: initialize left and top

[Hans Verkuil]

On 05/03/2015 11:02 PM, Guennadi Liakhovetski wrote:
 Hi Hans,
 
 On Sun, 3 May 2015, Hans Verkuil wrote:
 
 From: Hans Verkuil hans.verk...@cisco.com

 The left and top variables were uninitialized, leading to unexpected
 results.

 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 ---
  drivers/media/i2c/soc_camera/mt9t112.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/media/i2c/soc_camera/mt9t112.c 
 b/drivers/media/i2c/soc_camera/mt9t112.c
 index de10a76..02190d6 100644
 --- a/drivers/media/i2c/soc_camera/mt9t112.c
 +++ b/drivers/media/i2c/soc_camera/mt9t112.c
 @@ -952,7 +952,8 @@ static int mt9t112_set_fmt(struct v4l2_subdev *sd,
  struct v4l2_mbus_framefmt *mf = format-format;
  struct i2c_client *client = v4l2_get_subdevdata(sd);
  struct mt9t112_priv *priv = to_mt9t112(client);
 -unsigned int top, left;
 +unsigned int top = priv-frame.top;
 +unsigned int left = priv-frame.left;
 
 I don't think this is needed. We don't care about left and top in 
 mt9t112_set_fmt().

On further analysis you are correct, it will work with random left/top
values. But I think it is 1) very unexpected and 2) bad form to leave it
with random values.

I prefer to keep this patch, unless you disagree.

Regards,

Hans

 
 How about my comment about a duplicated call to mt9t112_set_params()? Can 
 we have it fixed too?
 
 Thanks
 Guennadi
 
  int i;
  
  if (format-pad)
 -- 
 2.1.4


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 9/9] mt9t112: initialize left and top

[Guennadi Liakhovetski]

On Mon, 4 May 2015, Hans Verkuil wrote:

 On 05/03/2015 11:02 PM, Guennadi Liakhovetski wrote:
  Hi Hans,
  
  On Sun, 3 May 2015, Hans Verkuil wrote:
  
  From: Hans Verkuil hans.verk...@cisco.com
 
  The left and top variables were uninitialized, leading to unexpected
  results.
 
  Signed-off-by: Hans Verkuil hans.verk...@cisco.com
  ---
   drivers/media/i2c/soc_camera/mt9t112.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/media/i2c/soc_camera/mt9t112.c 
  b/drivers/media/i2c/soc_camera/mt9t112.c
  index de10a76..02190d6 100644
  --- a/drivers/media/i2c/soc_camera/mt9t112.c
  +++ b/drivers/media/i2c/soc_camera/mt9t112.c
  @@ -952,7 +952,8 @@ static int mt9t112_set_fmt(struct v4l2_subdev *sd,
 struct v4l2_mbus_framefmt *mf = format-format;
 struct i2c_client *client = v4l2_get_subdevdata(sd);
 struct mt9t112_priv *priv = to_mt9t112(client);
  -  unsigned int top, left;
  +  unsigned int top = priv-frame.top;
  +  unsigned int left = priv-frame.left;
  
  I don't think this is needed. We don't care about left and top in 
  mt9t112_set_fmt().
 
 On further analysis you are correct, it will work with random left/top
 values. But I think it is 1) very unexpected and 2) bad form to leave it
 with random values.
 
 I prefer to keep this patch, unless you disagree.

Sorry, but I do. Assigning those specific values to left and top makes the 
code even more confusing, it makes it look like that makes any sense, 
whereas it doesn't. If anything we can add a comment there. Or we can pass 
NULL and make sure to catch it somewhere down the line.

Thanks
Guennadi

 Regards,
 
   Hans
 
  
  How about my comment about a duplicated call to mt9t112_set_params()? Can 
  we have it fixed too?
  
  Thanks
  Guennadi
  
 int i;
   
 if (format-pad)
  -- 
  2.1.4
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Y2038] [PATCH v4 06/10] cec: add HDMI CEC framework: y2038 question

[Hans Verkuil]

Ping! (Added Arnd to the CC list)

On 04/27/2015 09:40 AM, Hans Verkuil wrote:
 Added the y2038 mailinglist since I would like to get their input for
 this API.
 
 Y2038 experts, can you take a look at my comment in the code below?
 
 Thanks!

Arnd, I just saw your patch series adding struct __kernel_timespec to
uapi/linux/time.h. I get the feeling that it might take a few kernel
cycles before we have a timespec64 available in userspace. Based on that
I think this CEC API should drop the timestamps for now and wait until
timespec64 becomes available before adding it.

The timestamps are a nice-to-have, but not critical. So adding it later
shouldn't be a problem. What is your opinion?

Hans

 
 On 04/23/2015 03:03 PM, Kamil Debski wrote:
 From: Hans Verkuil hansv...@cisco.com

 The added HDMI CEC framework provides a generic kernel interface for
 HDMI CEC devices.

 Signed-off-by: Hans Verkuil hansv...@cisco.com
 [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil]
 [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil]
 [k.deb...@samsung.com: change kthread handling when setting logical
 address]
 [k.deb...@samsung.com: code cleanup and fixes]
 [k.deb...@samsung.com: add missing CEC commands to match spec]
 [k.deb...@samsung.com: add RC framework support]
 [k.deb...@samsung.com: move and edit documentation]
 [k.deb...@samsung.com: add vendor id reporting]
 [k.deb...@samsung.com: add possibility to clear assigned logical
 addresses]
 [k.deb...@samsung.com: documentation fixes, clenaup and expansion]
 [k.deb...@samsung.com: reorder of API structs and add reserved fields]
 [k.deb...@samsung.com: fix handling of events and fix 32/64bit timespec
 problem]
 [k.deb...@samsung.com: add cec.h to include/uapi/linux/Kbuild]
 Signed-off-by: Kamil Debski k.deb...@samsung.com
 ---
  Documentation/cec.txt |  396 
  drivers/media/Kconfig |6 +
  drivers/media/Makefile|2 +
  drivers/media/cec.c   | 1161 
 +
  include/media/cec.h   |  140 ++
  include/uapi/linux/Kbuild |1 +
  include/uapi/linux/cec.h  |  303 
  7 files changed, 2009 insertions(+)
  create mode 100644 Documentation/cec.txt
  create mode 100644 drivers/media/cec.c
  create mode 100644 include/media/cec.h
  create mode 100644 include/uapi/linux/cec.h

 
 snip
 
 diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
 index 4842a98..5854cfd 100644
 --- a/include/uapi/linux/Kbuild
 +++ b/include/uapi/linux/Kbuild
 @@ -81,6 +81,7 @@ header-y += capi.h
  header-y += cciss_defs.h
  header-y += cciss_ioctl.h
  header-y += cdrom.h
 +header-y += cec.h
  header-y += cgroupstats.h
  header-y += chio.h
  header-y += cm4000_cs.h
 diff --git a/include/uapi/linux/cec.h b/include/uapi/linux/cec.h
 new file mode 100644
 index 000..bb6d66c
 --- /dev/null
 +++ b/include/uapi/linux/cec.h
 @@ -0,0 +1,303 @@
 +#ifndef _CEC_H
 +#define _CEC_H
 +
 +#include linux/types.h
 +
 +struct cec_time {
 +__u64 sec;
 +__u64 nsec;
 +};
 
 I don't like having to introduce a new struct for time here. Basically we are
 only doing this because there is still no public struct timespec64.
 
 When will that struct become available for use in a public API? If it is 4.2,
 then we can start using it. If it will take longer, then what alternative can
 we use to prevent having to change the API later?
 
 One alternative might be to drop it for now and just reserve space in the
 structs to add it later.
 
 Input from the y2038 experts will be welcome!
 
 Regards,
 
   Hans
 
 +
 +struct cec_msg {
 +struct cec_time ts;
 +__u32 len;
 +__u32 status;
 +__u32 timeout;
 +/* timeout (in ms) is used to timeout CEC_RECEIVE.
 +   Set to 0 if you want to wait forever. */
 +__u8  msg[16];
 +__u8  reply;
 +/* If non-zero, then wait for a reply with this opcode.
 +   If there was an error when sending the msg or FeatureAbort
 +   was returned, then reply is set to 0.
 +   If reply is non-zero upon return, then len/msg are set to
 +   the received message.
 +   If reply is zero upon return and status has the
 +   CEC_TX_STATUS_FEATURE_ABORT bit set, then len/msg are set to the
 +   received feature abort message.
 +   If reply is zero upon return and status has the
 +   CEC_TX_STATUS_REPLY_TIMEOUT
 +   bit set, then no reply was seen at all.
 +   This field is ignored with CEC_RECEIVE.
 +   If reply is non-zero for CEC_TRANSMIT and the message is a broadcast,
 +   then -EINVAL is returned.
 +   if reply is non-zero, then timeout is set to 1000 (the required
 +   maximum response time).
 + */
 +__u8 reserved[31];
 +};
 +
 +static inline __u8 cec_msg_initiator(const struct cec_msg *msg)
 +{
 +return msg-msg[0]  4;
 +}
 +
 +static inline __u8 cec_msg_destination(const struct cec_msg *msg)
 +{
 +return msg-msg[0]  0xf;
 +}
 +
 +static inline bool 

Re: [PATCH 9/9] mt9t112: initialize left and top

[Hans Verkuil]

On 05/04/2015 09:40 AM, Guennadi Liakhovetski wrote:
 On Mon, 4 May 2015, Hans Verkuil wrote:
 
 On 05/03/2015 11:02 PM, Guennadi Liakhovetski wrote:
 Hi Hans,

 On Sun, 3 May 2015, Hans Verkuil wrote:

 From: Hans Verkuil hans.verk...@cisco.com

 The left and top variables were uninitialized, leading to unexpected
 results.

 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 ---
  drivers/media/i2c/soc_camera/mt9t112.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/media/i2c/soc_camera/mt9t112.c 
 b/drivers/media/i2c/soc_camera/mt9t112.c
 index de10a76..02190d6 100644
 --- a/drivers/media/i2c/soc_camera/mt9t112.c
 +++ b/drivers/media/i2c/soc_camera/mt9t112.c
 @@ -952,7 +952,8 @@ static int mt9t112_set_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf = format-format;
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct mt9t112_priv *priv = to_mt9t112(client);
 -  unsigned int top, left;
 +  unsigned int top = priv-frame.top;
 +  unsigned int left = priv-frame.left;

 I don't think this is needed. We don't care about left and top in 
 mt9t112_set_fmt().

 On further analysis you are correct, it will work with random left/top
 values. But I think it is 1) very unexpected and 2) bad form to leave it
 with random values.

 I prefer to keep this patch, unless you disagree.
 
 Sorry, but I do. Assigning those specific values to left and top makes the 
 code even more confusing, it makes it look like that makes any sense, 
 whereas it doesn't. If anything we can add a comment there. Or we can pass 
 NULL and make sure to catch it somewhere down the line.
 

What about this:

unsigned int top = 0; /* don't care */
unsigned int left = 0; /* don't care */

Regards,

Hans

 Thanks
 Guennadi
 
 Regards,

  Hans


 How about my comment about a duplicated call to mt9t112_set_params()? Can 
 we have it fixed too?

 Thanks
 Guennadi

int i;
  
if (format-pad)
 -- 
 2.1.4



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/1] V4L2: platform: Renesas R-Car JPEG codec driver

[Laurent Pinchart]

Hi Mikhail,

Thank you for the patch. Please see below for a (partial) review.

On Thursday 30 April 2015 00:53:29 Mikhail Ulyanov wrote:
 Here's the the driver for the Renesas R-Car JPEG processing unit driver.
 
 The driver is implemented within the V4L2 framework as a mem-to-mem device. 
 It presents two video nodes to userspace, one for the encoding part, and
 one for the decoding part.
 
 It was found that the only working mode for encoding is no markers output,
 so we generate it with software. In current version of driver we also use
 software JPEG header parsing because with hardware parsing performance is
 lower then desired.

Just out of curiosity, what is the performance impact of hardware parsing ?

 From a userspace point of view the encoding process is typical (S_FMT,
 REQBUF, optionally QUERYBUF, QBUF, STREAMON, DQBUF) for both the source and
 destination queues. The decoding process requires that the source queue
 performs S_FMT, REQBUF, (QUERYBUF), QBUF and STREAMON. After STREAMON on
 the source queue, it is possible to perform G_FMT on the destination queue
 to find out the processed image width and height in order to be able to
 allocate an appropriate buffer - it is assumed that the user does not pass
 the compressed image width and height but instead this information is
 parsed from the JPEG input. This is done in kernel. Then REQBUF, QBUF and
 STREAMON on the destination queue complete the decoding and it is possible
 to DQBUF from both queues and finish the operation.
 
 During encoding the available formats are: V4L2_PIX_FMT_NV12M and
 V4L2_PIX_FMT_NV16M for source and V4L2_PIX_FMT_JPEG for destination.
 
 During decoding the available formats are: V4L2_PIX_FMT_JPEG for source and
 V4L2_PIX_FMT_NV12M and V4L2_PIX_FMT_NV16M for destination.
 
 Performance of current version:
 1280x800 NV12 image encoding/decoding
   decoding ~121 FPS
   encoding ~190 FPS
 
 Signed-off-by: Mikhail Ulyanov mikhail.ulya...@cogentembedded.com
 ---
 Changes since v2:
 - Kconfig entry reordered
 - unnecessary clk_disable_unprepare(jpu-clk) removed
 - ref_count fixed in jpu_resume
 - enable DMABUF in src_vq-io_modes
 - remove jpu_s_priority jpu_g_priority
 - jpu_g_selection fixed
 - timeout in jpu_reset added and hardware reset reworked
 - remove unused macros
 - JPEG header parsing now is software because of performance issues
   based on s5p-jpu code
 - JPEG header generation redesigned:
   JPEG header(s) pre-generated and memcpy'ed on encoding
   we only fill the necessary fields
   more transparent header format description
 - S_FMT, G_FMT and TRY_FMT hooks redesigned
   partially inspired by VSP1 driver code
 - some code was reformatted
 - image formats handling redesigned
 - multi-planar V4L2 API now in use
 - now passes v4l2-compliance tool check
 
 Cnanges since v1:
 - s/g_fmt function simplified
 - default format for queues added
 - dumb vidioc functions added to be in compliance with standard api:
 jpu_s_priority, jpu_g_priority
 - standard v4l2_ctrl_subscribe_event and v4l2_event_unsubscribe
   now in use by the same reason
 
  drivers/media/platform/Kconfig  |   11 +
  drivers/media/platform/Makefile |1 +
  drivers/media/platform/jpu.c| 1724 
  3 files changed, 1736 insertions(+)
  create mode 100644 drivers/media/platform/jpu.c
 
 diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
 index 765bffb..33a457c 100644
 --- a/drivers/media/platform/Kconfig
 +++ b/drivers/media/platform/Kconfig
 @@ -220,6 +220,17 @@ config VIDEO_SH_VEU
   Support for the Video Engine Unit (VEU) on SuperH and
   SH-Mobile SoCs.
 
 +config VIDEO_RENESAS_JPU
 + tristate Renesas JPEG Processing Unit
 + depends on VIDEO_DEV  VIDEO_V4L2
 + select VIDEOBUF2_DMA_CONTIG
 + select V4L2_MEM2MEM_DEV
 + ---help---
 +   This is a V4L2 driver for the Renesas JPEG Processing Unit.
 +
 +   To compile this driver as a module, choose M here: the module
 +   will be called jpu.
 +
  config VIDEO_RENESAS_VSP1
   tristate Renesas VSP1 Video Processing Engine
   depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API  HAS_DMA
 diff --git a/drivers/media/platform/Makefile
 b/drivers/media/platform/Makefile index a49936b..1399c0d 100644
 --- a/drivers/media/platform/Makefile
 +++ b/drivers/media/platform/Makefile
 @@ -42,6 +42,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)  += sh_vou.o
 
  obj-$(CONFIG_SOC_CAMERA) += soc_camera/
 
 +obj-$(CONFIG_VIDEO_RENESAS_JPU)  += jpu.o
  obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
 
  obj-y+= omap/
 diff --git a/drivers/media/platform/jpu.c b/drivers/media/platform/jpu.c
 new file mode 100644
 index 000..6c658cc
 --- /dev/null
 +++ b/drivers/media/platform/jpu.c
 @@ -0,0 +1,1724 @@
 +/*
 + * Author: Mikhail Ulyanov
 + * Copyright (C) 2014-2015 Cogent 

Re: [RFC PATCH 0/3] Add VIDIOC_SUBDEV_QUERYCAP

[Laurent Pinchart]

Hi Hans,

On Friday 01 May 2015 13:41:03 Hans Verkuil wrote:
 On 05/01/2015 01:33 PM, Hans Verkuil wrote:
  From: Hans Verkuil hans.verk...@cisco.com
  
  This patch series adds the VIDIOC_SUBDEV_QUERYCAP ioctl for v4l-subdev
  devices as discussed during the ELC in San Jose and as discussed here:
  
  http://www.spinics.net/lists/linux-media/msg88009.html
  
  It also adds the entity_id to v4l2_capability.
 
 Question: why do we have CONFIG_VIDEO_V4L2_SUBDEV_API? I don't really see
 the point of this and I would propose to remove this config option and
 instead use CONFIG_MEDIA_CONTROLLER.
 
 I don't see the use-case of having MEDIA_CONTROLLER defined but not
 VIDEO_V4L2_SUBDEV_API.
 
 Comments?

The idea is to compile the subdev userspace API code out when not needed. Not 
all media controller drivers need that API.

  Hans Verkuil (3):
v4l2-subdev: add VIDIOC_SUBDEV_QUERYCAP ioctl
DocBook/media: document VIDIOC_SUBDEV_QUERYCAP
videodev2.h: add entity_id to struct v4l2_capability
   
   Documentation/DocBook/media/v4l/v4l2.xml   |   1 +
   .../DocBook/media/v4l/vidioc-querycap.xml  |  18 ++-
   .../DocBook/media/v4l/vidioc-subdev-querycap.xml   | 140 
   drivers/media/v4l2-core/v4l2-ioctl.c   |   7 ++
   drivers/media/v4l2-core/v4l2-subdev.c  |  19 +++
   include/uapi/linux/v4l2-subdev.h   |  12 ++
   include/uapi/linux/videodev2.h |   5 +-
   7 files changed, 199 insertions(+), 3 deletions(-)
   create mode 100644
   Documentation/DocBook/media/v4l/vidioc-subdev-querycap.xml

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/3] DocBook/media: document VIDIOC_SUBDEV_QUERYCAP

[Laurent Pinchart]

Hi Hans,

Thank you for the patch.

On Friday 01 May 2015 13:33:49 Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com
 
 Add documentation for the new VIDIOC_SUBDEV_QUERYCAP ioctl.
 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 ---
  Documentation/DocBook/media/v4l/v4l2.xml   |   1 +
  .../DocBook/media/v4l/vidioc-querycap.xml  |   2 +-
  .../DocBook/media/v4l/vidioc-subdev-querycap.xml   | 140 ++
  3 files changed, 142 insertions(+), 1 deletion(-)
  create mode 100644
 Documentation/DocBook/media/v4l/vidioc-subdev-querycap.xml
 
 diff --git a/Documentation/DocBook/media/v4l/v4l2.xml
 b/Documentation/DocBook/media/v4l/v4l2.xml index e98caa1..23607bc 100644
 --- a/Documentation/DocBook/media/v4l/v4l2.xml
 +++ b/Documentation/DocBook/media/v4l/v4l2.xml
 @@ -669,6 +669,7 @@ and discussions on the V4L mailing list./revremark
  sub-subdev-g-fmt;
  sub-subdev-g-frame-interval;
  sub-subdev-g-selection;
 +sub-subdev-querycap;
  sub-subscribe-event;
  !-- End of ioctls. --
  sub-mmap;
 diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index
 20fda75..c1ed844 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 @@ -54,7 +54,7 @@ kernel devices compatible with this specification and to
 obtain information about driver and hardware capabilities. The ioctl takes
 a pointer to a v4l2-capability; which is filled by the driver. When the
 driver is not compatible with this specification the ioctl returns an
 -EINVAL;./para
 +ENOTTY;./para

I'd split this change to a separate patch as it's unrelated to 
VIDIOC_SUBDEV_QUERYCAP.

We can't really guarantee that non-V4L2 drivers will return -ENOTTY, they 
might be buggy and return a different error code. That's slightly nitpicking 
though.

  table pgwide=1 frame=none id=v4l2-capability
titlestruct structnamev4l2_capability/structname/title
 diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-querycap.xml
 b/Documentation/DocBook/media/v4l/vidioc-subdev-querycap.xml new file mode
 100644
 index 000..a1cbb36
 --- /dev/null
 +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-querycap.xml
 @@ -0,0 +1,140 @@
 +refentry id=vidioc-subdev-querycap
 +  refmeta
 +refentrytitleioctl VIDIOC_SUBDEV_QUERYCAP/refentrytitle
 +manvol;
 +  /refmeta
 +
 +  refnamediv
 +refnameVIDIOC_SUBDEV_QUERYCAP/refname
 +refpurposeQuery sub-device capabilities/refpurpose
 +  /refnamediv
 +
 +  refsynopsisdiv
 +funcsynopsis
 +  funcprototype
 + funcdefint functionioctl/function/funcdef
 + paramdefint parameterfd/parameter/paramdef
 + paramdefint parameterrequest/parameter/paramdef
 + paramdefstruct v4l2_subdev_capability
 *parameterargp/parameter/paramdef
 +  /funcprototype
 +/funcsynopsis
 +  /refsynopsisdiv
 +
 +  refsect1
 +titleArguments/title
 +
 +variablelist
 +  varlistentry
 + termparameterfd/parameter/term
 + listitem
 +   parafd;/para
 + /listitem
 +  /varlistentry
 +  varlistentry
 + termparameterrequest/parameter/term
 + listitem
 +   paraVIDIOC_SUBDEV_QUERYCAP/para
 + /listitem
 +  /varlistentry
 +  varlistentry
 + termparameterargp/parameter/term
 + listitem
 +   para/para
 + /listitem
 +  /varlistentry
 +/variablelist
 +  /refsect1
 +
 +  refsect1
 +titleDescription/title
 +
 +paraAll V4L2 sub-devices support the
 +constantVIDIOC_SUBDEV_QUERYCAP/constant ioctl. It is used to identify
 +kernel devices compatible with this specification and to obtain
 +information about driver and hardware capabilities. The ioctl takes a
 +pointer to a v4l2-subdev-capability; which is filled by the driver. When
 the
 +driver is not compatible with this specification the ioctl returns an
 +ENOTTY;./para
 +
 +table pgwide=1 frame=none id=v4l2-subdev-capability
 +  titlestruct structnamev4l2_subdev_capability/structname/title
 +  tgroup cols=3
 + cs-str;
 + tbody valign=top
 +   row
 + entry__u32/entry
 + entrystructfieldversion/structfield/entry
 + entryparaVersion number of the driver./para
 +paraThe version reported is provided by the
 +V4L2 subsystem following the kernel numbering scheme. However, it
 +may not always return the same version as the kernel if, for example,
 +a stable or distribution-modified kernel uses the V4L2 stack from a
 +newer kernel./para
 +paraThe version number is formatted using the
 +constantKERNEL_VERSION()/constant macro:/para/entry
 +   /row
 +   row
 + entry spanname=hspanpara
 +programlisting
 +#define KERNEL_VERSION(a,b,c) (((a) lt;lt; 16) + ((b) lt;lt; 8) + (c))
 +
 +__u32 version = KERNEL_VERSION(0, 8, 1);
 +
 +printf (Version: %u.%u.%u\n,
 + (version gt;gt; 16) amp; 0xFF,
 + (version gt;gt; 8) amp; 0xFF,
 +  version amp; 

Re: [RFC PATCH 3/3] videodev2.h: add entity_id to struct v4l2_capability

[Laurent Pinchart]

Hi Hans,

Thank you for the patch.

On Friday 01 May 2015 13:33:50 Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com
 
 Export the entity ID (if any) of the video device.

I would postpone this until we finish the DVB+MC discussion and properly 
define the relationship between device nodes and MC, as it could have 
implications on the V4L2 side as well.

 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 ---
  Documentation/DocBook/media/v4l/vidioc-querycap.xml | 16 +++-
  drivers/media/v4l2-core/v4l2-ioctl.c|  7 +++
  include/uapi/linux/videodev2.h  |  5 -
  3 files changed, 26 insertions(+), 2 deletions(-)
 
 diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index
 c1ed844..4a7737c 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 @@ -154,7 +154,14 @@ printf (Version: %u.%u.%u\n,
 /row
 row
   entry__u32/entry
 - entrystructfieldreserved/structfield[3]/entry
 + entrystructfieldentity_id/structfield/entry
 + entryThe media controller entity ID of the device. This is only
 valid if
 + the constantV4L2_CAP_ENTITY/constant capability is set.
 + /entry
 +   /row
 +   row
 + entry__u32/entry
 + entrystructfieldreserved/structfield[2]/entry
   entryReserved for future extensions. Drivers must set
  this array to zero./entry
 /row
 @@ -308,6 +315,13 @@ modulator programming see
  fields./entry
 /row
 row
 + entryconstantV4L2_CAP_ENTITY/constant/entry
 + entry0x0040/entry
 + entryThe device is a media controller entity and
 + the structfieldentity_id/structfield field of v4l2-capability;
 + is valid./entry
 +   /row
 +   row
   entryconstantV4L2_CAP_READWRITE/constant/entry
   entry0x0100/entry
   entryThe device supports the link
 diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
 b/drivers/media/v4l2-core/v4l2-ioctl.c index 1476602..5179611 100644
 --- a/drivers/media/v4l2-core/v4l2-ioctl.c
 +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
 @@ -1011,6 +1011,7 @@ static void v4l_sanitize_format(struct v4l2_format
 *fmt) static int v4l_querycap(const struct v4l2_ioctl_ops *ops,
   struct file *file, void *fh, void *arg)
  {
 + struct video_device *vfd = video_devdata(file);
   struct v4l2_capability *cap = (struct v4l2_capability *)arg;
   int ret;
 
 @@ -1019,6 +1020,12 @@ static int v4l_querycap(const struct v4l2_ioctl_ops
 *ops, ret = ops-vidioc_querycap(file, fh, cap);
 
   cap-capabilities |= V4L2_CAP_EXT_PIX_FORMAT;
 +#if defined(CONFIG_MEDIA_CONTROLLER)
 + if (vfd-entity.parent) {
 + cap-capabilities |= V4L2_CAP_ENTITY;
 + cap-entity_id = vfd-entity.id;
 + }
 +#endif
   /*
* Drivers MUST fill in device_caps, so check for this and
* warn if it was forgotten.
 diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
 index fa376f7..af7a667 100644
 --- a/include/uapi/linux/videodev2.h
 +++ b/include/uapi/linux/videodev2.h
 @@ -307,6 +307,7 @@ struct v4l2_fract {
* @version:   KERNEL_VERSION
* @capabilities: capabilities of the physical device as a whole
* @device_caps:  capabilities accessed via this particular device (node)
 +  * @entity_id:the media controller entity ID
* @reserved:  reserved fields for future extensions
*/
  struct v4l2_capability {
 @@ -316,7 +317,8 @@ struct v4l2_capability {
   __u32   version;
   __u32   capabilities;
   __u32   device_caps;
 - __u32   reserved[3];
 + __u32   entity_id;
 + __u32   reserved[2];
  };
 
  /* Values for 'capabilities' field */
 @@ -348,6 +350,7 @@ struct v4l2_capability {
 
  #define V4L2_CAP_SDR_CAPTURE 0x0010  /* Is a SDR capture device 
 */
  #define V4L2_CAP_EXT_PIX_FORMAT  0x0020  /* Supports the 
 extended 
pixel
 format */ +#define V4L2_CAP_ENTITY 0x0040  /* This is a
 Media Controller entity */
 
  #define V4L2_CAP_READWRITE  0x0100  /* read/write
 systemcalls */ #define V4L2_CAP_ASYNCIO0x0200  /* async
 I/O */

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC] v4l: vsp1: Align crop rectangle to even boundary for YUV formats

[Laurent Pinchart]

Hello,

On Thursday 30 April 2015 14:22:02 Sergei Shtylyov wrote:
 On 4/29/2015 8:05 PM, Yoshihiro Kaneko wrote:
  From: Damian Hobson-Garcia dhobs...@igel.co.jp
  
  Make sure that there are valid values in the crop rectangle to ensure
  that the color plane doesn't get shifted when cropping.
  Since there is no distintion between 12bit and 16bit YUV formats in
 
 Вistinсtion.
 
  at the subdev level, use the more restrictive 12bit limits for all YUV
  formats.

I would like to mention in the commit message that only the top coordinate 
constraints differ between the YUV formats, as the subsampling coefficient is 
always two in the horizontal direction.

Do you foresee a use case for odd cropping top coordinates ?

  Signed-off-by: Damian Hobson-Garcia dhobs...@igel.co.jp
  Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
  ---
  
  This patch is based on the master branch of linuxtv.org/media_tree.git.
  
drivers/media/platform/vsp1/vsp1_rwpf.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
  
  diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.c
  b/drivers/media/platform/vsp1/vsp1_rwpf.c index fa71f46..9fed0b2 100644
  --- a/drivers/media/platform/vsp1/vsp1_rwpf.c
  +++ b/drivers/media/platform/vsp1/vsp1_rwpf.c
  @@ -197,11 +197,21 @@ int vsp1_rwpf_set_selection(struct v4l2_subdev
  *subdev, 
   */
  format = vsp1_entity_get_pad_format(rwpf-entity, cfg,
  RWPF_PAD_SINK,
  sel-which);
  +
  +   if (format-code == MEDIA_BUS_FMT_AYUV8_1X32) {
  +   sel-r.left = (sel-r.left + 1)  ~1;
  +   sel-r.top = (sel-r.top + 1)  ~1;
 
 There's ALIGN() macro just for that.
 
  +   sel-r.width = (sel-r.width)  ~1;
  +   sel-r.height = (sel-r.height)  ~1;
 
 Parens not needed.

round_down() could also be used, it might be more readable.

  +   }
  +
  sel-r.left = min_t(unsigned int, sel-r.left, format-width - 2);
  sel-r.top = min_t(unsigned int, sel-r.top, format-height - 2);

If format-width (height) is odd and sel-r.left (top) is larger than format-
width (height) - 2 then the resulting value will become odd. The resulting 
configuration will not be accepted at streamon time as the video node width 
and height are correctly rounded based on YUV subsampling and will thus not 
match the subdev width and height. However, it would be good to enforce the 
constraint better at the subdev level, by moving the above alignment code 
after these two lines.

  if (rwpf-entity.type == VSP1_ENTITY_WPF) {
  -   sel-r.left = min_t(unsigned int, sel-r.left, 255);
  -   sel-r.top = min_t(unsigned int, sel-r.top, 255);
  +   int maxcrop =

I would declare maxcrop as an unsigned int.

  +   format-code == MEDIA_BUS_FMT_AYUV8_1X32 ? 254 : 255;
 
 I think you need an empty line here.
 
  +   sel-r.left = min_t(unsigned int, sel-r.left, maxcrop);
  +   sel-r.top = min_t(unsigned int, sel-r.top, maxcrop);

Is this needed ? Based on what I understand from the datasheet the WPF crops 
the image before passing it to the DMA engine. At that point YUV data isn't 
subsampled, so it looks like we don't need to restrict the left and top to 
even values.

  }
  sel-r.width = min_t(unsigned int, sel-r.width,
   format-width - sel-r.left);

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/3] v4l2-subdev: add VIDIOC_SUBDEV_QUERYCAP ioctl

[Laurent Pinchart]

Hi Hans,

Thank you for the patch.

On Friday 01 May 2015 13:33:48 Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com
 
 While normal video/radio/vbi/swradio nodes have a proper QUERYCAP ioctl
 that apps can call to determine that it is indeed a V4L2 device, there
 is currently no equivalent for v4l-subdev nodes. Adding this ioctl will
 solve that, and it will allow utilities like v4l2-compliance to be used
 with these devices as well.
 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 ---
  drivers/media/v4l2-core/v4l2-subdev.c | 19 +++
  include/uapi/linux/v4l2-subdev.h  | 12 
  2 files changed, 31 insertions(+)
 
 diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
 b/drivers/media/v4l2-core/v4l2-subdev.c index 6359606..2ab1f7d 100644
 --- a/drivers/media/v4l2-core/v4l2-subdev.c
 +++ b/drivers/media/v4l2-core/v4l2-subdev.c
 @@ -25,6 +25,7 @@
  #include linux/types.h
  #include linux/videodev2.h
  #include linux/export.h
 +#include linux/version.h

Nitpicking, I'd insert version.h between types.h and videodev2.h to keep 
entries alphabetically sorted (I know that export.h is misplaced, but that's 
the only one.).

  #include media/v4l2-ctrls.h
  #include media/v4l2-device.h
 @@ -187,6 +188,24 @@ static long subdev_do_ioctl(struct file *file, unsigned
 int cmd, void *arg) #endif
 
   switch (cmd) {
 + case VIDIOC_SUBDEV_QUERYCAP: {
 + struct v4l2_subdev_capability *cap = arg;
 +
 + cap-version = LINUX_VERSION_CODE;
 + cap-device_caps = 0;
 + cap-pads = 0;
 + cap-entity_id = 0;
 +#if defined(CONFIG_MEDIA_CONTROLLER)
 + if (sd-entity.parent) {
 + cap-device_caps = V4L2_SUBDEV_CAP_ENTITY;
 + cap-pads = sd-entity.num_pads;
 + cap-entity_id = sd-entity.id;
 + }
 +#endif
 + memset(cap-reserved, 0, sizeof(cap-reserved));
 + break;
 + }
 +
   case VIDIOC_QUERYCTRL:
   return v4l2_queryctrl(vfh-ctrl_handler, arg);
 
 diff --git a/include/uapi/linux/v4l2-subdev.h
 b/include/uapi/linux/v4l2-subdev.h index dbce2b5..e48b9fd 100644
 --- a/include/uapi/linux/v4l2-subdev.h
 +++ b/include/uapi/linux/v4l2-subdev.h
 @@ -154,9 +154,21 @@ struct v4l2_subdev_selection {
   __u32 reserved[8];
  };
 
 +struct v4l2_subdev_capability {
 + __u32 version;
 + __u32 device_caps;
 + __u32 pads;

If we restrict pad number reporting to subdevs that are also entities, should 
we report the number of pads at all here ? Applications could find it out 
through the MC API using the entity ID. I don't have a too strong opinion on 
this for now, but we should consider whether reporting the same information 
through two different means wouldn't cause issues.

 + __u32 entity_id;
 + __u32 reserved[48];
 +};
 +
 +/* This v4l2_subdev is also a media entity and the entity_id field is valid
 */ +#define V4L2_SUBDEV_CAP_ENTITY(1  0)
 +
  /* Backwards compatibility define --- to be removed */
  #define v4l2_subdev_edid v4l2_edid
 
 +#define VIDIOC_SUBDEV_QUERYCAP_IOR('V',  0, struct
 v4l2_subdev_capability) #define VIDIOC_SUBDEV_G_FMT   
 _IOWR('V',  4, 
struct
 v4l2_subdev_format) #define VIDIOC_SUBDEV_S_FMT   
 _IOWR('V',  5, 
struct
 v4l2_subdev_format) #define VIDIOC_SUBDEV_G_FRAME_INTERVAL
 _IOWR('V', 
21,
 struct v4l2_subdev_frame_interval)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 9/9] mt9t112: initialize left and top

[Guennadi Liakhovetski]

On Mon, 4 May 2015, Hans Verkuil wrote:

 On 05/04/2015 09:40 AM, Guennadi Liakhovetski wrote:
  On Mon, 4 May 2015, Hans Verkuil wrote:
  
  On 05/03/2015 11:02 PM, Guennadi Liakhovetski wrote:
  Hi Hans,
 
  On Sun, 3 May 2015, Hans Verkuil wrote:
 
  From: Hans Verkuil hans.verk...@cisco.com
 
  The left and top variables were uninitialized, leading to unexpected
  results.
 
  Signed-off-by: Hans Verkuil hans.verk...@cisco.com
  ---
   drivers/media/i2c/soc_camera/mt9t112.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/media/i2c/soc_camera/mt9t112.c 
  b/drivers/media/i2c/soc_camera/mt9t112.c
  index de10a76..02190d6 100644
  --- a/drivers/media/i2c/soc_camera/mt9t112.c
  +++ b/drivers/media/i2c/soc_camera/mt9t112.c
  @@ -952,7 +952,8 @@ static int mt9t112_set_fmt(struct v4l2_subdev *sd,
   struct v4l2_mbus_framefmt *mf = format-format;
   struct i2c_client *client = v4l2_get_subdevdata(sd);
   struct mt9t112_priv *priv = to_mt9t112(client);
  -unsigned int top, left;
  +unsigned int top = priv-frame.top;
  +unsigned int left = priv-frame.left;
 
  I don't think this is needed. We don't care about left and top in 
  mt9t112_set_fmt().
 
  On further analysis you are correct, it will work with random left/top
  values. But I think it is 1) very unexpected and 2) bad form to leave it
  with random values.
 
  I prefer to keep this patch, unless you disagree.
  
  Sorry, but I do. Assigning those specific values to left and top makes the 
  code even more confusing, it makes it look like that makes any sense, 
  whereas it doesn't. If anything we can add a comment there. Or we can pass 
  NULL and make sure to catch it somewhere down the line.
  
 
 What about this:
 
   unsigned int top = 0; /* don't care */
   unsigned int left = 0; /* don't care */

This would be my third preference. My first preference is just a comment. 
My second preference is adding

if (!start)
return;

in the middle of soc_camera_limit_side() and using NULL in 
mt9t112_set_fmt(). I really dislike meaningless operations, also when they 
fix compiler warnings, but here even the compiler is happy:)

Thanks
Guennadi

   int i;
   
   if (format-pad)
  -- 
  2.1.4
 
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/3] DocBook/media: document VIDIOC_SUBDEV_QUERYCAP

[Hans Verkuil]

On 05/04/2015 12:29 AM, Laurent Pinchart wrote:
 Hi Hans,
 
 Thank you for the patch.
 
 On Friday 01 May 2015 13:33:49 Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com

 Add documentation for the new VIDIOC_SUBDEV_QUERYCAP ioctl.

 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 ---
  Documentation/DocBook/media/v4l/v4l2.xml   |   1 +
  .../DocBook/media/v4l/vidioc-querycap.xml  |   2 +-
  .../DocBook/media/v4l/vidioc-subdev-querycap.xml   | 140 ++
  3 files changed, 142 insertions(+), 1 deletion(-)
  create mode 100644
 Documentation/DocBook/media/v4l/vidioc-subdev-querycap.xml

 diff --git a/Documentation/DocBook/media/v4l/v4l2.xml
 b/Documentation/DocBook/media/v4l/v4l2.xml index e98caa1..23607bc 100644
 --- a/Documentation/DocBook/media/v4l/v4l2.xml
 +++ b/Documentation/DocBook/media/v4l/v4l2.xml
 @@ -669,6 +669,7 @@ and discussions on the V4L mailing list./revremark
  sub-subdev-g-fmt;
  sub-subdev-g-frame-interval;
  sub-subdev-g-selection;
 +sub-subdev-querycap;
  sub-subscribe-event;
  !-- End of ioctls. --
  sub-mmap;
 diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index
 20fda75..c1ed844 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
 @@ -54,7 +54,7 @@ kernel devices compatible with this specification and to
 obtain information about driver and hardware capabilities. The ioctl takes
 a pointer to a v4l2-capability; which is filled by the driver. When the
 driver is not compatible with this specification the ioctl returns an
 -EINVAL;./para
 +ENOTTY;./para
 
 I'd split this change to a separate patch as it's unrelated to 
 VIDIOC_SUBDEV_QUERYCAP.

You are right. I just happened to come across this while adding the 
subdev-querycap
text.

 We can't really guarantee that non-V4L2 drivers will return -ENOTTY, they 
 might be buggy and return a different error code. That's slightly nitpicking 
 though.

Well, ENOTTY is much more likely than EINVAL :-) But I can replace it with:

...returns an error, most likely ENOTTY;. and use the same phrase for
subdev-querycap.

 
  table pgwide=1 frame=none id=v4l2-capability
titlestruct structnamev4l2_capability/structname/title
 diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-querycap.xml
 b/Documentation/DocBook/media/v4l/vidioc-subdev-querycap.xml new file mode
 100644
 index 000..a1cbb36
 --- /dev/null
 +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-querycap.xml
 @@ -0,0 +1,140 @@
 +refentry id=vidioc-subdev-querycap
 +  refmeta
 +refentrytitleioctl VIDIOC_SUBDEV_QUERYCAP/refentrytitle
 +manvol;
 +  /refmeta
 +
 +  refnamediv
 +refnameVIDIOC_SUBDEV_QUERYCAP/refname
 +refpurposeQuery sub-device capabilities/refpurpose
 +  /refnamediv
 +
 +  refsynopsisdiv
 +funcsynopsis
 +  funcprototype
 +funcdefint functionioctl/function/funcdef
 +paramdefint parameterfd/parameter/paramdef
 +paramdefint parameterrequest/parameter/paramdef
 +paramdefstruct v4l2_subdev_capability
 *parameterargp/parameter/paramdef
 +  /funcprototype
 +/funcsynopsis
 +  /refsynopsisdiv
 +
 +  refsect1
 +titleArguments/title
 +
 +variablelist
 +  varlistentry
 +termparameterfd/parameter/term
 +listitem
 +  parafd;/para
 +/listitem
 +  /varlistentry
 +  varlistentry
 +termparameterrequest/parameter/term
 +listitem
 +  paraVIDIOC_SUBDEV_QUERYCAP/para
 +/listitem
 +  /varlistentry
 +  varlistentry
 +termparameterargp/parameter/term
 +listitem
 +  para/para
 +/listitem
 +  /varlistentry
 +/variablelist
 +  /refsect1
 +
 +  refsect1
 +titleDescription/title
 +
 +paraAll V4L2 sub-devices support the
 +constantVIDIOC_SUBDEV_QUERYCAP/constant ioctl. It is used to identify
 +kernel devices compatible with this specification and to obtain
 +information about driver and hardware capabilities. The ioctl takes a
 +pointer to a v4l2-subdev-capability; which is filled by the driver. When
 the
 +driver is not compatible with this specification the ioctl returns an
 +ENOTTY;./para
 +
 +table pgwide=1 frame=none id=v4l2-subdev-capability
 +  titlestruct structnamev4l2_subdev_capability/structname/title
 +  tgroup cols=3
 +cs-str;
 +tbody valign=top
 +  row
 +entry__u32/entry
 +entrystructfieldversion/structfield/entry
 +entryparaVersion number of the driver./para
 +paraThe version reported is provided by the
 +V4L2 subsystem following the kernel numbering scheme. However, it
 +may not always return the same version as the kernel if, for example,
 +a stable or distribution-modified kernel uses the V4L2 stack from a
 +newer kernel./para
 +paraThe version number is formatted using the
 +constantKERNEL_VERSION()/constant macro:/para/entry
 +  /row
 +  row
 +

Re: [RFC PATCH 1/3] v4l2-subdev: add VIDIOC_SUBDEV_QUERYCAP ioctl

[Hans Verkuil]

On 05/04/2015 12:20 AM, Laurent Pinchart wrote:
 Hi Hans,
 
 Thank you for the patch.
 
 On Friday 01 May 2015 13:33:48 Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com

 While normal video/radio/vbi/swradio nodes have a proper QUERYCAP ioctl
 that apps can call to determine that it is indeed a V4L2 device, there
 is currently no equivalent for v4l-subdev nodes. Adding this ioctl will
 solve that, and it will allow utilities like v4l2-compliance to be used
 with these devices as well.

 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 ---
  drivers/media/v4l2-core/v4l2-subdev.c | 19 +++
  include/uapi/linux/v4l2-subdev.h  | 12 
  2 files changed, 31 insertions(+)

 diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
 b/drivers/media/v4l2-core/v4l2-subdev.c index 6359606..2ab1f7d 100644
 --- a/drivers/media/v4l2-core/v4l2-subdev.c
 +++ b/drivers/media/v4l2-core/v4l2-subdev.c
 @@ -25,6 +25,7 @@
  #include linux/types.h
  #include linux/videodev2.h
  #include linux/export.h
 +#include linux/version.h
 
 Nitpicking, I'd insert version.h between types.h and videodev2.h to keep 
 entries alphabetically sorted (I know that export.h is misplaced, but that's 
 the only one.).
 
  #include media/v4l2-ctrls.h
  #include media/v4l2-device.h
 @@ -187,6 +188,24 @@ static long subdev_do_ioctl(struct file *file, unsigned
 int cmd, void *arg) #endif

  switch (cmd) {
 +case VIDIOC_SUBDEV_QUERYCAP: {
 +struct v4l2_subdev_capability *cap = arg;
 +
 +cap-version = LINUX_VERSION_CODE;
 +cap-device_caps = 0;
 +cap-pads = 0;
 +cap-entity_id = 0;
 +#if defined(CONFIG_MEDIA_CONTROLLER)
 +if (sd-entity.parent) {
 +cap-device_caps = V4L2_SUBDEV_CAP_ENTITY;
 +cap-pads = sd-entity.num_pads;
 +cap-entity_id = sd-entity.id;
 +}
 +#endif
 +memset(cap-reserved, 0, sizeof(cap-reserved));
 +break;
 +}
 +
  case VIDIOC_QUERYCTRL:
  return v4l2_queryctrl(vfh-ctrl_handler, arg);

 diff --git a/include/uapi/linux/v4l2-subdev.h
 b/include/uapi/linux/v4l2-subdev.h index dbce2b5..e48b9fd 100644
 --- a/include/uapi/linux/v4l2-subdev.h
 +++ b/include/uapi/linux/v4l2-subdev.h
 @@ -154,9 +154,21 @@ struct v4l2_subdev_selection {
  __u32 reserved[8];
  };

 +struct v4l2_subdev_capability {
 +__u32 version;
 +__u32 device_caps;
 +__u32 pads;
 
 If we restrict pad number reporting to subdevs that are also entities, should 
 we report the number of pads at all here ? Applications could find it out 
 through the MC API using the entity ID. I don't have a too strong opinion on 
 this for now, but we should consider whether reporting the same information 
 through two different means wouldn't cause issues.

My problem is that that would require e.g. v4l2-compliance to hunt for the
media device when all it needs is the number of pads. I don't mind dropping
this, but then we need a good way to find the associated media device (and
sysfs is not a good way).

The goal is to be able to write v4l2-compliance tests, so I need this info
one way or another.

Regards,

Hans

 
 +__u32 entity_id;
 +__u32 reserved[48];
 +};
 +
 +/* This v4l2_subdev is also a media entity and the entity_id field is valid
 */ +#define V4L2_SUBDEV_CAP_ENTITY   (1  0)
 +
  /* Backwards compatibility define --- to be removed */
  #define v4l2_subdev_edid v4l2_edid

 +#define VIDIOC_SUBDEV_QUERYCAP   _IOR('V',  0, struct
 v4l2_subdev_capability) #define VIDIOC_SUBDEV_G_FMT  
 _IOWR('V',  4, 
 struct
 v4l2_subdev_format) #define VIDIOC_SUBDEV_S_FMT  
 _IOWR('V',  5, 
 struct
 v4l2_subdev_format) #define VIDIOC_SUBDEV_G_FRAME_INTERVAL   
 _IOWR('V', 
 21,
 struct v4l2_subdev_frame_interval)
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/3] Add VIDIOC_SUBDEV_QUERYCAP

[Hans Verkuil]

On 05/04/2015 12:33 AM, Laurent Pinchart wrote:
 Hi Hans,
 
 On Friday 01 May 2015 13:41:03 Hans Verkuil wrote:
 On 05/01/2015 01:33 PM, Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com

 This patch series adds the VIDIOC_SUBDEV_QUERYCAP ioctl for v4l-subdev
 devices as discussed during the ELC in San Jose and as discussed here:

 http://www.spinics.net/lists/linux-media/msg88009.html

 It also adds the entity_id to v4l2_capability.

 Question: why do we have CONFIG_VIDEO_V4L2_SUBDEV_API? I don't really see
 the point of this and I would propose to remove this config option and
 instead use CONFIG_MEDIA_CONTROLLER.

 I don't see the use-case of having MEDIA_CONTROLLER defined but not
 VIDEO_V4L2_SUBDEV_API.

 Comments?
 
 The idea is to compile the subdev userspace API code out when not needed. Not 
 all media controller drivers need that API.

Sure, but it is not a lot of code, and I think it is somewhat confusing.

Just my opinion, though.

Hans

 
 Hans Verkuil (3):
   v4l2-subdev: add VIDIOC_SUBDEV_QUERYCAP ioctl
   DocBook/media: document VIDIOC_SUBDEV_QUERYCAP
   videodev2.h: add entity_id to struct v4l2_capability
  
  Documentation/DocBook/media/v4l/v4l2.xml   |   1 +
  .../DocBook/media/v4l/vidioc-querycap.xml  |  18 ++-
  .../DocBook/media/v4l/vidioc-subdev-querycap.xml   | 140 
  drivers/media/v4l2-core/v4l2-ioctl.c   |   7 ++
  drivers/media/v4l2-core/v4l2-subdev.c  |  19 +++
  include/uapi/linux/v4l2-subdev.h   |  12 ++
  include/uapi/linux/videodev2.h |   5 +-
  7 files changed, 199 insertions(+), 3 deletions(-)
  create mode 100644
  Documentation/DocBook/media/v4l/vidioc-subdev-querycap.xml
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] media/vivid: Code cleanout

[Ricardo Ribalda Delgado]

Remove code duplication by merging two cases in a switch.

Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
 drivers/media/platform/vivid/vivid-tpg.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-tpg.c 
b/drivers/media/platform/vivid/vivid-tpg.c
index 2e5129a6bc2f..8cac0bdefd9a 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -294,6 +294,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
}
 
switch (fourcc) {
+   case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_RGB332:
tpg-twopixelsize[0] = 2;
break;
@@ -333,9 +334,6 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_YUV32:
tpg-twopixelsize[0] = 2 * 4;
break;
-   case V4L2_PIX_FMT_GREY:
-   tpg-twopixelsize[0] = 2;
-   break;
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_NV21:
case V4L2_PIX_FMT_NV12M:
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] Add support for V4L2_PIX_FMT_Y16_BE

[Ricardo Ribalda Delgado]

New pixel format type Y16_BE (16 bits greyscale big-endian).

Once I get the fist feedback on this patch I will send the patches for
v4lconvert and qv4l2.


Thanks

Ricardo Ribalda Delgado (4):
  media/vivid: Add support for Y16 format
  media/v4l2-core: Add support for V4L2_PIX_FMT_Y16_BE
  media/vivid: Add support for Y16_BE format
  media/vivid: Code cleanout

 drivers/media/platform/vivid/vivid-tpg.c| 20 
 drivers/media/platform/vivid/vivid-vid-common.c | 16 
 drivers/media/v4l2-core/v4l2-ioctl.c|  1 +
 include/uapi/linux/videodev2.h  |  1 +
 4 files changed, 34 insertions(+), 4 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] media/vivid: Add support for Y16_BE format

[Ricardo Ribalda Delgado]

Support for V4L2_PIX_FMT_Y16_BE, a 16 bit big endian greyscale format.

Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
 drivers/media/platform/vivid/vivid-tpg.c| 9 -
 drivers/media/platform/vivid/vivid-vid-common.c | 8 
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/vivid/vivid-tpg.c 
b/drivers/media/platform/vivid/vivid-tpg.c
index 9e50303a19c5..2e5129a6bc2f 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -221,6 +221,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_ABGR32:
case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_Y16:
+   case V4L2_PIX_FMT_Y16_BE:
tpg-is_yuv = false;
break;
case V4L2_PIX_FMT_YUV444:
@@ -315,6 +316,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_YUV555:
case V4L2_PIX_FMT_YUV565:
case V4L2_PIX_FMT_Y16:
+   case V4L2_PIX_FMT_Y16_BE:
tpg-twopixelsize[0] = 2 * 2;
break;
case V4L2_PIX_FMT_RGB24:
@@ -715,7 +717,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
b = 4;
}
if (tpg-qual == TPG_QUAL_GRAY || tpg-fourcc == V4L2_PIX_FMT_GREY ||
-   tpg-fourcc == V4L2_PIX_FMT_Y16) {
+   tpg-fourcc == V4L2_PIX_FMT_Y16 ||
+   tpg-fourcc == V4L2_PIX_FMT_Y16_BE) {
/* Rec. 709 Luma function */
/* (0.2126, 0.7152, 0.0722) * (255 * 256) */
r = g = b = (13879 * r + 46688 * g + 4713 * b)  16;
@@ -902,6 +905,10 @@ static void gen_twopix(struct tpg_data *tpg,
buf[0][offset] = 0;
buf[0][offset+1] = r_y;
break;
+   case V4L2_PIX_FMT_Y16_BE:
+   buf[0][offset] = r_y;
+   buf[0][offset+1] = 0;
+   break;
case V4L2_PIX_FMT_YUV422P:
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YUV420M:
diff --git a/drivers/media/platform/vivid/vivid-vid-common.c 
b/drivers/media/platform/vivid/vivid-vid-common.c
index 96ccd3c38dd2..45f10a7f9b46 100644
--- a/drivers/media/platform/vivid/vivid-vid-common.c
+++ b/drivers/media/platform/vivid/vivid-vid-common.c
@@ -197,6 +197,14 @@ struct vivid_fmt vivid_formats[] = {
.buffers = 1,
},
{
+   .fourcc   = V4L2_PIX_FMT_Y16_BE,
+   .vdownsampling = { 1 },
+   .bit_depth = { 16 },
+   .is_yuv   = true,
+   .planes   = 1,
+   .buffers = 1,
+   },
+   {
.fourcc   = V4L2_PIX_FMT_RGB332, /* rrrgggbb */
.vdownsampling = { 1 },
.bit_depth = { 8 },
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] media/vivid: Add support for Y16 format

[Ricardo Ribalda Delgado]

Support for V4L2_PIX_FMT_Y16, a 16 bit greyscale format.

Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
 drivers/media/platform/vivid/vivid-tpg.c| 9 -
 drivers/media/platform/vivid/vivid-vid-common.c | 8 
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/vivid/vivid-tpg.c 
b/drivers/media/platform/vivid/vivid-tpg.c
index 4df755aa7e48..9e50303a19c5 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -220,6 +220,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_ARGB32:
case V4L2_PIX_FMT_ABGR32:
case V4L2_PIX_FMT_GREY:
+   case V4L2_PIX_FMT_Y16:
tpg-is_yuv = false;
break;
case V4L2_PIX_FMT_YUV444:
@@ -313,6 +314,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_YUV444:
case V4L2_PIX_FMT_YUV555:
case V4L2_PIX_FMT_YUV565:
+   case V4L2_PIX_FMT_Y16:
tpg-twopixelsize[0] = 2 * 2;
break;
case V4L2_PIX_FMT_RGB24:
@@ -712,7 +714,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
g = 4;
b = 4;
}
-   if (tpg-qual == TPG_QUAL_GRAY || tpg-fourcc == V4L2_PIX_FMT_GREY) {
+   if (tpg-qual == TPG_QUAL_GRAY || tpg-fourcc == V4L2_PIX_FMT_GREY ||
+   tpg-fourcc == V4L2_PIX_FMT_Y16) {
/* Rec. 709 Luma function */
/* (0.2126, 0.7152, 0.0722) * (255 * 256) */
r = g = b = (13879 * r + 46688 * g + 4713 * b)  16;
@@ -895,6 +898,10 @@ static void gen_twopix(struct tpg_data *tpg,
case V4L2_PIX_FMT_GREY:
buf[0][offset] = r_y;
break;
+   case V4L2_PIX_FMT_Y16:
+   buf[0][offset] = 0;
+   buf[0][offset+1] = r_y;
+   break;
case V4L2_PIX_FMT_YUV422P:
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YUV420M:
diff --git a/drivers/media/platform/vivid/vivid-vid-common.c 
b/drivers/media/platform/vivid/vivid-vid-common.c
index 6ba874420485..96ccd3c38dd2 100644
--- a/drivers/media/platform/vivid/vivid-vid-common.c
+++ b/drivers/media/platform/vivid/vivid-vid-common.c
@@ -189,6 +189,14 @@ struct vivid_fmt vivid_formats[] = {
.buffers = 1,
},
{
+   .fourcc   = V4L2_PIX_FMT_Y16,
+   .vdownsampling = { 1 },
+   .bit_depth = { 16 },
+   .is_yuv   = true,
+   .planes   = 1,
+   .buffers = 1,
+   },
+   {
.fourcc   = V4L2_PIX_FMT_RGB332, /* rrrgggbb */
.vdownsampling = { 1 },
.bit_depth = { 8 },
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] media/v4l2-core: Add support for V4L2_PIX_FMT_Y16_BE

[Ricardo Ribalda Delgado]

16 bit greyscale format, structured in Big Endian. Such a format can be
converted into a PMN image just by adding a header.

Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
 include/uapi/linux/videodev2.h   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 14766029bf49..136df7ccfedc 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1146,6 +1146,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_Y10:  descr = 10-bit Greyscale; break;
case V4L2_PIX_FMT_Y12:  descr = 12-bit Greyscale; break;
case V4L2_PIX_FMT_Y16:  descr = 16-bit Greyscale; break;
+   case V4L2_PIX_FMT_Y16_BE:   descr = 16-bit Greyscale BE; break;
case V4L2_PIX_FMT_Y10BPACK: descr = 10-bit Greyscale (Packed); 
break;
case V4L2_PIX_FMT_PAL8: descr = 8-bit Palette; break;
case V4L2_PIX_FMT_UV8:  descr = 8-bit Chrominance UV 4-4; 
break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index fa376f7666ba..3f01d7bbbc77 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -404,6 +404,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10  Greyscale  
   */
 #define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12  Greyscale  
   */
 #define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16  Greyscale  
   */
+#define V4L2_PIX_FMT_Y16_BE  v4l2_fourcc_be('Y', '1', '6', ' ') /* 16  
Greyscale BE  */
 
 /* Grey bit-packed formats */
 #define V4L2_PIX_FMT_Y10BPACKv4l2_fourcc('Y', '1', '0', 'B') /* 10  
Greyscale bit-packed */
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: soc-camera: opinion poll - future directions

[Vaibhav Hiremath]

On Monday 04 May 2015 12:49 PM, Hans Verkuil wrote:

On 05/03/2015 07:45 PM, Guennadi Liakhovetski wrote:

Hi Hans,

On Sun, 3 May 2015, Hans Verkuil wrote:


Hi Guennadi,

On 05/03/2015 06:11 PM, Guennadi Liakhovetski wrote:

Hi all,

Just a quick opinion poll - where and how should the soc-camera framework
and drivers be heading? Possible (probably not all) directions:

(1) all is good, keep as is. That means keep all drivers, killing them off
only when it becomes very obvious, that noone wants them, keep developing
drivers, that are still being used and updating all of them on any API
updates. Keep me as maintainer, which means slow patch processing rate and
no active participation in new developments - at hardware, soc-camera or
V4L levels.

(2) we want more! I.e. some contributors are planning to either add new
drivers to it or significantly develop existing ones, see significant
benefit in it. In this case it might become necessary to replace me with
someone, who can be more active in this area.

(3) slowly phase out. Try to either deprecate and remove soc-camera
drivers one by one or move them out to become independent V4L2 host or
subdevice drivers, but keep updating while still there.

(4) basically as (3) but even more aggressively - get rid of it ASAP:)

Opinions? Expecially would be interesting to hear from respective
host-driver maintainers / developers, sorry, not adding CCs, they probably
read the list anyway:)


I'm closest to 1. I would certainly not use it for new drivers, I see no
reason to do that anymore. The core frameworks are quite good these days
and I think the need for soc-camera has basically disappeared. But there
is no need to phase out or remove soc-camera drivers (unless they are
clearly broken and nobody will fix them). And if someone wants to turn
a soc-camera driver into a standalone driver, then I would encourage
that.


Understand, thanks.


However, there are two things that need work fairly soon:

1) the dependency of subdev drivers on soc_camera: that has to go. I plan
to work on that, but the first step is to replace the video crop ops by
the pad selection ops. I finally got my Renesas sh7724 board up and running,


Uhm... Does anyone really still care about V4L on SuperH?..


I am :-)

It's the only soc-camera board I have, so it's good to have it working.




so I hope to make progress on this soon. I'll update soc-camera as well
to conform to v4l2-compliance. Once that's done I will investigate how to
remove the soc-camera dependency.

The soc-camera dependency kills the reusability of those drivers and it
really needs to be addressed.

2) Converting soc-camera videobuf drivers to vb2. At some point vb1 will be
removed, so any remaining vb1 driver will likely be killed off if nobody does
the conversion. I believe it is only omap1 and pxa that still use videobuf.

I think omap1 might be a candidate for removal, but I don't know about the pxa.
Guennadi, what is the status of these drivers?


Dont know, sorry. PXA in general seems to still be quite actively
maintained - I recently saw a patch series for PXA CCF support, so,
probably V4L is still in use too.


If I would do a vb2 conversion
for the pxa, would you be able to test it?


I have a board with PXA270, and it still seems to be in the mainline, but
I don't know how easy it would be to get it running with a current kernel.


Can you take a look? If you can get it running, then I can make a patch for
you to try. But I don't want to put time into that unless I know you can
test it.

I think it is reasonable to phase out the omap1 driver: move it to staging
first and if nobody complains remove it altogether.



Hans,

I think OMAP2_VOUT is also another candidate which we need to probably
move it to staging and then remove it.
I am not sure if anyone is still using it.

It is just compiling as of now, but I am doubtful that it will work.


Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/3] Add media bdisp driver for stihxxx platforms

[Fabien Dessenne]

This series of patches adds the support of v4l2 2D blitter driver for
STMicroelectronics SOC.

version 2:
- Renamed to STI_BDISP, inserted the sti directory.
- Reworked the cropping vs selection API.
- Used additional v4l2_m2m helpers and fops.
- Dropped pixel format description.
- Fixed memory release issue.

version 1:
- Initial submission.

The following features are supported and tested:
- Color format conversion (RGB32, RGB24, RGB16, NV12, YUV420P)
- Copy
- Scale
- Flip
- Deinterlace
- Wide (4K) picture support
- Crop

This driver uses the v4l2 mem2mem framework and its implementation was largely
inspired by the Exynos G-Scaler (exynos-gsc) driver.

The driver is mainly implemented across two files:
- bdisp-v4l2.c
- bdisp-hw.c
bdisp-v4l2.c uses v4l2_m2m to manage the V4L2 interface with the userland.
It calls the HW services that are implemented in bdisp-hw.c.

The additional bdisp-debug.c file manages some debugfs entries.

Fabien Dessenne (3):
  [media] bdisp: add DT bindings documentation
  [media] bdisp: 2D blitter driver using v4l2 mem2mem framework
  [media] bdisp: add debug file system

 .../devicetree/bindings/media/st,stih4xx.txt   |   32 +
 drivers/media/platform/Kconfig |   10 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/sti/bdisp/Kconfig   |9 +
 drivers/media/platform/sti/bdisp/Makefile  |3 +
 drivers/media/platform/sti/bdisp/bdisp-debug.c |  668 ++
 drivers/media/platform/sti/bdisp/bdisp-filter.h|  346 +
 drivers/media/platform/sti/bdisp/bdisp-hw.c|  823 
 drivers/media/platform/sti/bdisp/bdisp-reg.h   |  235 
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c  | 1408 
 drivers/media/platform/sti/bdisp/bdisp.h   |  216 +++
 11 files changed, 3752 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,stih4xx.txt
 create mode 100644 drivers/media/platform/sti/bdisp/Kconfig
 create mode 100644 drivers/media/platform/sti/bdisp/Makefile
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp-debug.c
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp-filter.h
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp-hw.c
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp-reg.h
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp-v4l2.c
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp.h

-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] [media] bdisp: add DT bindings documentation

[Fabien Dessenne]

This adds DT binding documentation for STMicroelectronics bdisp driver.

Signed-off-by: Fabien Dessenne fabien.desse...@st.com
---
 .../devicetree/bindings/media/st,stih4xx.txt   | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/st,stih4xx.txt

diff --git a/Documentation/devicetree/bindings/media/st,stih4xx.txt 
b/Documentation/devicetree/bindings/media/st,stih4xx.txt
new file mode 100644
index 000..df655cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stih4xx.txt
@@ -0,0 +1,32 @@
+STMicroelectronics stih4xx platforms
+
+bdisp: 2D blitter for STMicroelectronics SoC.
+
+Required properties:
+- compatible: should be st,stih407-bdisp.
+- reg: BDISP physical address location and length.
+- interrupts: BDISP interrupt number.
+- clocks: from common clock binding: handle hardware IP needed clocks, the
+  number of clocks may depend on the SoC type.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: names of the clocks listed in clocks property in the same order.
+
+Example:
+
+   bdisp0:bdisp@9f1 {
+   compatible = st,stih407-bdisp;
+   reg = 0x9f1 0x1000;
+   interrupts = GIC_SPI 38 IRQ_TYPE_NONE;
+   clock-names = bdisp;
+   clocks = clk_s_c0_flexgen CLK_IC_BDISP_0;
+   };
+
+Aliases:
+Each BDISP should have a numbered alias in the aliases node, in the form of
+bdispN, N = 0 or 1.
+
+Example:
+
+   aliases {
+   bdisp0 = bdisp0;
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] [media] bdisp: add debug file system

[Fabien Dessenne]

Creates 5 debugfs entries to dump the last HW request, the last HW node
(=command), the HW registers and the recent HW performance (time  fps)

Signed-off-by: Fabien Dessenne fabien.desse...@st.com
---
 drivers/media/platform/sti/bdisp/Makefile  |   2 +-
 drivers/media/platform/sti/bdisp/bdisp-debug.c | 668 +
 drivers/media/platform/sti/bdisp/bdisp-hw.c|  40 ++
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c  |  17 +-
 drivers/media/platform/sti/bdisp/bdisp.h   |  30 ++
 5 files changed, 755 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp-debug.c

diff --git a/drivers/media/platform/sti/bdisp/Makefile 
b/drivers/media/platform/sti/bdisp/Makefile
index 2605094..bc53496 100644
--- a/drivers/media/platform/sti/bdisp/Makefile
+++ b/drivers/media/platform/sti/bdisp/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_VIDEO_STI_BDISP) := bdisp.o
 
-bdisp-objs := bdisp-v4l2.o bdisp-hw.o
+bdisp-objs := bdisp-v4l2.o bdisp-hw.o bdisp-debug.o
diff --git a/drivers/media/platform/sti/bdisp/bdisp-debug.c 
b/drivers/media/platform/sti/bdisp/bdisp-debug.c
new file mode 100644
index 000..7c3a632
--- /dev/null
+++ b/drivers/media/platform/sti/bdisp/bdisp-debug.c
@@ -0,0 +1,668 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Authors: Fabien Dessenne fabien.desse...@st.com for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include linux/debugfs.h
+#include linux/pm_runtime.h
+
+#include bdisp.h
+#include bdisp-filter.h
+#include bdisp-reg.h
+
+void bdisp_dbg_perf_begin(struct bdisp_dev *bdisp)
+{
+   bdisp-dbg.hw_start = ktime_get();
+}
+
+void bdisp_dbg_perf_end(struct bdisp_dev *bdisp)
+{
+   s64 time_us;
+
+   time_us = ktime_us_delta(ktime_get(), bdisp-dbg.hw_start);
+
+   if (!bdisp-dbg.min_duration)
+   bdisp-dbg.min_duration = time_us;
+   else
+   bdisp-dbg.min_duration = min(time_us, bdisp-dbg.min_duration);
+
+   bdisp-dbg.last_duration = time_us;
+   bdisp-dbg.max_duration = max(time_us, bdisp-dbg.max_duration);
+   bdisp-dbg.tot_duration += time_us;
+}
+
+static void bdisp_dbg_dump_ins(struct seq_file *s, u32 val)
+{
+   seq_printf(s, INS\t0x%08X\t, val);
+
+   switch (val  BLT_INS_S1_MASK) {
+   case BLT_INS_S1_OFF:
+   break;
+   case BLT_INS_S1_MEM:
+   seq_puts(s, SRC1=mem - );
+   break;
+   case BLT_INS_S1_CF:
+   seq_puts(s, SRC1=ColorFill - );
+   break;
+   case BLT_INS_S1_COPY:
+   seq_puts(s, SRC1=copy - );
+   break;
+   case BLT_INS_S1_FILL:
+   seq_puts(s, SRC1=fil - );
+   break;
+   default:
+   seq_puts(s, SRC1=??? - );
+   break;
+   }
+
+   switch (val  BLT_INS_S2_MASK) {
+   case BLT_INS_S2_OFF:
+   break;
+   case BLT_INS_S2_MEM:
+   seq_puts(s, SRC2=mem - );
+   break;
+   case BLT_INS_S2_CF:
+   seq_puts(s, SRC2=ColorFill - );
+   break;
+   default:
+   seq_puts(s, SRC2=??? - );
+   break;
+   }
+
+   if ((val  BLT_INS_S3_MASK) == BLT_INS_S3_MEM)
+   seq_puts(s, SRC3=mem - );
+
+   if (val  BLT_INS_IVMX)
+   seq_puts(s, IVMX - );
+   if (val  BLT_INS_CLUT)
+   seq_puts(s, CLUT - );
+   if (val  BLT_INS_SCALE)
+   seq_puts(s, Scale - );
+   if (val  BLT_INS_FLICK)
+   seq_puts(s, Flicker - );
+   if (val  BLT_INS_CLIP)
+   seq_puts(s, Clip - );
+   if (val  BLT_INS_CKEY)
+   seq_puts(s, ColorKey - );
+   if (val  BLT_INS_OVMX)
+   seq_puts(s, OVMX - );
+   if (val  BLT_INS_DEI)
+   seq_puts(s, Deint - );
+   if (val  BLT_INS_PMASK)
+   seq_puts(s, PlaneMask - );
+   if (val  BLT_INS_VC1R)
+   seq_puts(s, VC1R - );
+   if (val  BLT_INS_ROTATE)
+   seq_puts(s, Rotate - );
+   if (val  BLT_INS_GRAD)
+   seq_puts(s, GradFill - );
+   if (val  BLT_INS_AQLOCK)
+   seq_puts(s, AQLock - );
+   if (val  BLT_INS_PACE)
+   seq_puts(s, Pace - );
+   if (val  BLT_INS_IRQ)
+   seq_puts(s, IRQ - );
+
+   seq_puts(s, \n);
+}
+
+static void bdisp_dbg_dump_tty(struct seq_file *s, u32 val)
+{
+   seq_printf(s, TTY\t0x%08X\t, val);
+   seq_printf(s, Pitch=%d - , val  0x);
+
+   switch ((val  BLT_TTY_COL_MASK)  BLT_TTY_COL_SHIFT) {
+   case BDISP_RGB565:
+   seq_puts(s, RGB565 - );
+   break;
+   case BDISP_XRGB:
+   seq_puts(s, xRGB888 - );
+   break;
+   case BDISP_ARGB:
+   seq_puts(s, ARGB - );
+   break;
+   case BDISP_NV12:
+   seq_puts(s, NV12 - );
+   break;
+   

[PATCH v2 2/3] [media] bdisp: 2D blitter driver using v4l2 mem2mem framework

[Fabien Dessenne]

This v4l2 mem2mem driver is a 2D blitter for STMicroelectronics SoC.
It uses the v4l2 mem2mem framework.

The following features are supported and tested:
- Color format conversion (RGB32, RGB24, RGB16, NV12, YUV420P)
- Copy
- Scale
- Flip
- Deinterlace
- Wide (4K) picture support
- Crop

Signed-off-by: Fabien Dessenne fabien.desse...@st.com
---
 drivers/media/platform/Kconfig  |   10 +
 drivers/media/platform/Makefile |2 +
 drivers/media/platform/sti/bdisp/Kconfig|9 +
 drivers/media/platform/sti/bdisp/Makefile   |3 +
 drivers/media/platform/sti/bdisp/bdisp-filter.h |  346 ++
 drivers/media/platform/sti/bdisp/bdisp-hw.c |  783 +
 drivers/media/platform/sti/bdisp/bdisp-reg.h|  235 
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c   | 1393 +++
 drivers/media/platform/sti/bdisp/bdisp.h|  186 +++
 9 files changed, 2967 insertions(+)
 create mode 100644 drivers/media/platform/sti/bdisp/Kconfig
 create mode 100644 drivers/media/platform/sti/bdisp/Makefile
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp-filter.h
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp-hw.c
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp-reg.h
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp-v4l2.c
 create mode 100644 drivers/media/platform/sti/bdisp/bdisp.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 2e30be5..005be89 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -210,6 +210,16 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
help
  This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler.
 
+config VIDEO_STI_BDISP
+   tristate STMicroelectronics BDISP 2D blitter driver
+   depends on VIDEO_DEV  VIDEO_V4L2
+   depends on ARCH_STI || COMPILE_TEST
+   depends on HAS_DMA
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   help
+ This v4l2 mem2mem driver is a 2D blitter for STMicroelectronics SoC.
+
 config VIDEO_SH_VEU
tristate SuperH VEU mem2mem video processing driver
depends on VIDEO_DEV  VIDEO_V4L2  HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 3ec1547..b1fc862 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -34,6 +34,8 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)+= s5p-tv/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
 
+obj-$(CONFIG_VIDEO_STI_BDISP)  += sti/bdisp/
+
 obj-$(CONFIG_BLACKFIN)  += blackfin/
 
 obj-$(CONFIG_ARCH_DAVINCI) += davinci/
diff --git a/drivers/media/platform/sti/bdisp/Kconfig 
b/drivers/media/platform/sti/bdisp/Kconfig
new file mode 100644
index 000..afaf4a6
--- /dev/null
+++ b/drivers/media/platform/sti/bdisp/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_STI_BDISP
+   tristate STMicroelectronics BDISP 2D blitter driver
+   depends on VIDEO_DEV  VIDEO_V4L2
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   help
+This v4l2 mem2mem driver is a 2D blitter for STMicroelectronics SoC.
+To compile this driver as a module, choose M here: the module will
+be called bdisp.ko.
diff --git a/drivers/media/platform/sti/bdisp/Makefile 
b/drivers/media/platform/sti/bdisp/Makefile
new file mode 100644
index 000..2605094
--- /dev/null
+++ b/drivers/media/platform/sti/bdisp/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_VIDEO_STI_BDISP) := bdisp.o
+
+bdisp-objs := bdisp-v4l2.o bdisp-hw.o
diff --git a/drivers/media/platform/sti/bdisp/bdisp-filter.h 
b/drivers/media/platform/sti/bdisp/bdisp-filter.h
new file mode 100644
index 000..fc8c54f
--- /dev/null
+++ b/drivers/media/platform/sti/bdisp/bdisp-filter.h
@@ -0,0 +1,346 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Authors: Fabien Dessenne fabien.desse...@st.com for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#define BDISP_HF_NB 64
+#define BDISP_VF_NB 40
+
+/**
+ * struct bdisp_filter_h_spec - Horizontal filter specification
+ *
+ * @min:min scale factor for this filter (6.10 fixed point)
+ * @max:max scale factor for this filter (6.10 fixed point)
+ * coef:filter coefficients
+ */
+struct bdisp_filter_h_spec {
+   const u16 min;
+   const u16 max;
+   const u8 coef[BDISP_HF_NB];
+};
+
+static const struct bdisp_filter_h_spec bdisp_h_spec[] = {
+   {
+   .min = 0,
+   .max = 921,
+   .coef = {
+   0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0xff, 0x07, 0x3d, 0xfc, 0x01, 0x00,
+   0x00, 0x01, 0xfd, 0x11, 0x36, 0xf9, 0x02, 0x00,
+   0x00, 0x01, 0xfb, 0x1b, 0x2e, 0xf9, 0x02, 0x00,
+   0x00, 0x01, 

Re: [PATCH] v4l2-dv-timings: fix overflow in gtf timings calculation

[Hans Verkuil]

On 05/02/2015 07:23 PM, Prashant Laddha wrote:
 The intermediate calculation in the expression for hblank can exceed
 32 bit signed range. This overflow can lead to negative values for
 hblank. Typecasting intermediate variable to higher precision.
 
 Cc: Hans Verkuil hans.verk...@cisco.com
 Cc: Martin Bugge marbu...@cisco.com
 Signed-off-by: Prashant Laddha prlad...@cisco.com
 ---
  drivers/media/v4l2-core/v4l2-dv-timings.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c 
 b/drivers/media/v4l2-core/v4l2-dv-timings.c
 index 86e11d1..9d27f05 100644
 --- a/drivers/media/v4l2-core/v4l2-dv-timings.c
 +++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
 @@ -573,15 +573,15 @@ bool v4l2_detect_gtf(unsigned frame_height,
  
   /* Horizontal */
   if (default_gtf)
 - h_blank = ((image_width * GTF_D_C_PRIME * hfreq) -
 - (image_width * GTF_D_M_PRIME * 1000) +
 - (hfreq * (100 - GTF_D_C_PRIME) + GTF_D_M_PRIME * 1000) 
 / 2) /
 - (hfreq * (100 - GTF_D_C_PRIME) + GTF_D_M_PRIME * 1000);
 + h_blank = ((image_width * GTF_D_C_PRIME * (long long)hfreq) -
 +   ((long long)image_width * GTF_D_M_PRIME * 1000) +
 +   ((long long)hfreq * (100 - GTF_D_C_PRIME) + 
 GTF_D_M_PRIME * 1000) / 2) /
 +   ((long long)hfreq * (100 - GTF_D_C_PRIME) + 
 GTF_D_M_PRIME * 1000);

This will not work on systems that cannot divide 64 bit numbers. Use the do_div
function for this. It's a common mistake to make when developing on Intel CPUs.
Been there, done that :-) Multiple times, in fact...

And I think it will help a lot if some additional variables are introduced since
this calculation is getting complex.

Also replace / 2 by  1. That will guarantee that you do not need do_div 
for
that. Probably unnecessary since I would expect gcc to be smart enough to 
replace
/ 2 by  1 anyway, but it doesn't hurt.

Regards,

Hans

   else
 - h_blank = ((image_width * GTF_S_C_PRIME * hfreq) -
 - (image_width * GTF_S_M_PRIME * 1000) +
 - (hfreq * (100 - GTF_S_C_PRIME) + GTF_S_M_PRIME * 1000) 
 / 2) /
 - (hfreq * (100 - GTF_S_C_PRIME) + GTF_S_M_PRIME * 1000);
 + h_blank = ((image_width * GTF_S_C_PRIME * (long long)hfreq) -
 +   ((long long)image_width * GTF_S_M_PRIME * 1000) +
 +   ((long long)hfreq * (100 - GTF_S_C_PRIME) + 
 GTF_S_M_PRIME * 1000) / 2) /
 +   ((long long)hfreq * (100 - GTF_S_C_PRIME) + 
 GTF_S_M_PRIME * 1000);
  
   h_blank = ((h_blank + GTF_CELL_GRAN) / (2 * GTF_CELL_GRAN)) *
 (2 * GTF_CELL_GRAN);
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] v4l2-dv-timings: fix overflow in gtf timings calculation

[Prashant Laddha]

The intermediate calculation in the expression for hblank can exceed
32 bit signed range. This overflow can lead to negative values for
hblank. Typecasting intermediate variable to higher precision.

Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Martin Bugge marbu...@cisco.com
Signed-off-by: Prashant Laddha prlad...@cisco.com
---
 drivers/media/v4l2-core/v4l2-dv-timings.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c 
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 86e11d1..9d27f05 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -573,15 +573,15 @@ bool v4l2_detect_gtf(unsigned frame_height,
 
/* Horizontal */
if (default_gtf)
-   h_blank = ((image_width * GTF_D_C_PRIME * hfreq) -
-   (image_width * GTF_D_M_PRIME * 1000) +
-   (hfreq * (100 - GTF_D_C_PRIME) + GTF_D_M_PRIME * 1000) 
/ 2) /
-   (hfreq * (100 - GTF_D_C_PRIME) + GTF_D_M_PRIME * 1000);
+   h_blank = ((image_width * GTF_D_C_PRIME * (long long)hfreq) -
+ ((long long)image_width * GTF_D_M_PRIME * 1000) +
+ ((long long)hfreq * (100 - GTF_D_C_PRIME) + 
GTF_D_M_PRIME * 1000) / 2) /
+ ((long long)hfreq * (100 - GTF_D_C_PRIME) + 
GTF_D_M_PRIME * 1000);
else
-   h_blank = ((image_width * GTF_S_C_PRIME * hfreq) -
-   (image_width * GTF_S_M_PRIME * 1000) +
-   (hfreq * (100 - GTF_S_C_PRIME) + GTF_S_M_PRIME * 1000) 
/ 2) /
-   (hfreq * (100 - GTF_S_C_PRIME) + GTF_S_M_PRIME * 1000);
+   h_blank = ((image_width * GTF_S_C_PRIME * (long long)hfreq) -
+ ((long long)image_width * GTF_S_M_PRIME * 1000) +
+ ((long long)hfreq * (100 - GTF_S_C_PRIME) + 
GTF_S_M_PRIME * 1000) / 2) /
+ ((long long)hfreq * (100 - GTF_S_C_PRIME) + 
GTF_S_M_PRIME * 1000);
 
h_blank = ((h_blank + GTF_CELL_GRAN) / (2 * GTF_CELL_GRAN)) *
  (2 * GTF_CELL_GRAN);
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] Add media bdisp driver for stihxxx platforms

[Benjamin Gaignard]

Please, find below the v4l2-compliance report for the sti bdisp driver.

root@st:~# v4l2-compliance
Driver Info:
Driver name   : 9f1.bdisp
Card type : 9f1.bdisp
Bus info  : platform:bdisp0
Driver version: 4.0.0
Capabilities  : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 3 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
warn:
/local/frq07368/view/opensdk-0.31/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(707):
TRY_FMT cannot handle an invalid pixelformat.
warn:
/local/frq07368/view/opensdk-0.31/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(708):
This may or may not be a problem. For more information see:
warn:
/local/frq07368/view/opensdk-0.31/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(709):
http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html
warn:
/local/frq07368/view/opensdk-0.31/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(707):
TRY_FMT cannot handle an invalid pixelformat.
warn:
/local/frq07368/view/opensdk-0.31/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(708):
This may or may not be a problem. For more information see:
warn:
/local/frq07368/view/opensdk-0.31/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(709):
http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html
test VIDIOC_TRY_FMT: OK
warn:
/local/frq07368/view/opensdk-0.31/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(923):
S_FMT cannot handle an invalid pixelformat.
warn:
/local/frq07368/view/opensdk-0.31/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(924):
This may or may not be a problem. For more information see:
warn:
/local/frq07368/view/opensdk-0.31/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(925):
http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html
warn:
/local/frq07368/view/opensdk-0.31/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(923):
S_FMT cannot handle an invalid pixelformat.
warn:
/local/frq07368/view/opensdk-0.31/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-formats.cpp(924):
This may or may not be a problem. For more information see:
warn:

Re: [Y2038] [PATCH v4 06/10] cec: add HDMI CEC framework: y2038 question

[Arnd Bergmann]

On Monday 04 May 2015 09:42:36 Hans Verkuil wrote:
 Ping! (Added Arnd to the CC list)

Hi Hans,

sorry I missed this the first time

 On 04/27/2015 09:40 AM, Hans Verkuil wrote:
  Added the y2038 mailinglist since I would like to get their input for
  this API.
  
  Y2038 experts, can you take a look at my comment in the code below?
  
  Thanks!
 
 Arnd, I just saw your patch series adding struct __kernel_timespec to
 uapi/linux/time.h. I get the feeling that it might take a few kernel
 cycles before we have a timespec64 available in userspace. Based on that
 I think this CEC API should drop the timestamps for now and wait until
 timespec64 becomes available before adding it.
 
 The timestamps are a nice-to-have, but not critical. So adding it later
 shouldn't be a problem. What is your opinion?

It will take a little while for the patches to make it in, I would guess
4.3 at the earliest. Using your own struct works just as well and would
be less ambiguous.

However, for timestamps, I would recommend not using timespec anyway.
Instead, just use a single 64-bit nanosecond value from ktime_get_ns()
(or ktime_get_boot_ns() if you need a time that keeps ticking across
suspend). This is more efficient to get and simpler to use as long
as you don't need to convert from nanosecond to timespec.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/9] ov9740: avoid calling ov9740_res_roundup() twice

[Hans Verkuil]

On 05/03/2015 10:47 PM, Guennadi Liakhovetski wrote:
 Hi Hans,
 
 On Sun, 3 May 2015, Hans Verkuil wrote:
 
 From: Hans Verkuil hans.verk...@cisco.com

 Simplify ov9740_s_fmt.

 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 Reported-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
  drivers/media/i2c/soc_camera/ov9740.c | 18 +-
  1 file changed, 1 insertion(+), 17 deletions(-)

 diff --git a/drivers/media/i2c/soc_camera/ov9740.c 
 b/drivers/media/i2c/soc_camera/ov9740.c
 index 03a7fc7..61a8e18 100644
 --- a/drivers/media/i2c/soc_camera/ov9740.c
 +++ b/drivers/media/i2c/soc_camera/ov9740.c
 @@ -673,20 +673,8 @@ static int ov9740_s_fmt(struct v4l2_subdev *sd,
  {
  struct i2c_client *client = v4l2_get_subdevdata(sd);
  struct ov9740_priv *priv = to_ov9740(sd);
 -enum v4l2_colorspace cspace;
 -u32 code = mf-code;
  int ret;
  
 -ov9740_res_roundup(mf-width, mf-height);
 -
 -switch (code) {
 -case MEDIA_BUS_FMT_YUYV8_2X8:
 -cspace = V4L2_COLORSPACE_SRGB;
 -break;
 -default:
 -return -EINVAL;
 -}
 -
 
 ov9740_s_fmt() is also called from ov9740_s_power(), so, don't we have to 
 do this simplification the other way round - remove redundant code from 
 ov9740_set_fmt() instead?

Yes, but s_power is also calling ov9740_res_roundup() and it sets mf-code and
mf-colorspace to the correct values. So this code in s_fmt is a duplicate
for both s_power and for set_fmt. It can't be removed from set_fmt either
since it is needed for the TRY_FORMAT case anyway.

So IMHO it makes sense to remove it from s_fmt.

Regards,

Hans

 
 Thanks
 Guennadi
 
  ret = ov9740_reg_write_array(client, ov9740_defaults,
   ARRAY_SIZE(ov9740_defaults));
  if (ret  0)
 @@ -696,11 +684,7 @@ static int ov9740_s_fmt(struct v4l2_subdev *sd,
  if (ret  0)
  return ret;
  
 -mf-code= code;
 -mf-colorspace  = cspace;
 -
 -memcpy(priv-current_mf, mf, sizeof(struct v4l2_mbus_framefmt));
 -
 +priv-current_mf = *mf;
  return ret;
  }
  
 -- 
 2.1.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/5] [media] DocBook media: document mem2mem draining flow

[Philipp Zabel]

Hi Hans, Kamil,

thank you for your comments.

Am Montag, den 27.04.2015, 15:23 +0200 schrieb Hans Verkuil:
 Hi Philipp,
 
 I finally got around to reviewing this patch series. Sorry for the delay, but
 here are my comments:

 On 04/20/2015 10:28 AM, Philipp Zabel wrote:
  Document the interaction between VIDIOC_DECODER_CMD V4L2_DEC_CMD_STOP and
  VIDIOC_ENCODER_CMD V4L2_ENC_CMD_STOP to start the draining, the 
  V4L2_EVENT_EOS
  event signalling all capture buffers are finished and ready to be dequeud,
  the new V4L2_BUF_FLAG_LAST buffer flag indicating the last buffer being 
  dequeued
  from the capture queue, and the poll and VIDIOC_DQBUF ioctl return values 
  once
  the queue is drained.
  
  Signed-off-by: Philipp Zabel p.za...@pengutronix.de
  ---
  Changes since v4:
   - Split out documentation changes into a separate patch
   - Changed wording following Pawel's suggestions.
  ---
   Documentation/DocBook/media/v4l/io.xml | 10 ++
   Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml |  9 -
   Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml |  8 +++-
   Documentation/DocBook/media/v4l/vidioc-qbuf.xml|  8 
   4 files changed, 33 insertions(+), 2 deletions(-)
  
  diff --git a/Documentation/DocBook/media/v4l/io.xml 
  b/Documentation/DocBook/media/v4l/io.xml
  index 1c17f80..f561037 100644
  --- a/Documentation/DocBook/media/v4l/io.xml
  +++ b/Documentation/DocBook/media/v4l/io.xml
  @@ -1129,6 +1129,16 @@ in this buffer has not been created by the CPU but 
  by some DMA-capable unit,
   in which case caches have not been used./entry
/row
row
  +   entryconstantV4L2_BUF_FLAG_LAST/constant/entry
  +   entry0x0010/entry
  +   entryLast buffer produced by the hardware. mem2mem codec drivers
  +set this flag on the capture queue for the last buffer when the
  +link linkend=vidioc-querybufVIDIOC_QUERYBUF/link or
  +link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl is called. Any 
  subsequent
  +call to the link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl will not 
  block
  +anymore, but return an EPIPE;./entry
 
 As Kamil mentioned in his review, we should allow for bytesused == 0 here.

How about:

@@ -1134,9 +1134,11 @@ in which case caches have not been used./entry
entryLast buffer produced by the hardware. mem2mem codec drivers
 set this flag on the capture queue for the last buffer when the
 link linkend=vidioc-querybufVIDIOC_QUERYBUF/link or
-link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl is called. Any subsequent
-call to the link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl will not 
block
-anymore, but return an EPIPE;./entry
+link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl is called. Due to 
hardware
+limitations, the last buffer may be empty. In this case the driver will set the
+structfieldbytesused/structfield field to 0, regardless of the format. Any
+Any subsequent call to the link linkend=vidioc-qbufVIDIOC_DQBUF/link 
ioctl
+will not block anymore, but return an EPIPE;./entry
  /row
  row
entryconstantV4L2_BUF_FLAG_TIMESTAMP_MASK/constant/entry

  + /row
  + row
  entryconstantV4L2_BUF_FLAG_TIMESTAMP_MASK/constant/entry
  entry0xe000/entry
  entryMask for timestamp types below. To test the
  diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml 
  b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
  index 9215627..6502d82 100644
  --- a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
  +++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
  @@ -197,7 +197,14 @@ be muted when playing back at a non-standard speed.
   this command does nothing. This command has two flags:
   if constantV4L2_DEC_CMD_STOP_TO_BLACK/constant is set, then the 
  decoder will
   set the picture to black after it stopped decoding. Otherwise the last 
  image will
  -repeat. If constantV4L2_DEC_CMD_STOP_IMMEDIATELY/constant is set, then 
  the decoder
  +repeat. mem2mem decoders will stop producing new frames altogether. They 
  will send
  +a constantV4L2_EVENT_EOS/constant event when the last frame has been 
  decoded
  +and all frames are ready to be dequeued and will set the
  +constantV4L2_BUF_FLAG_LAST/constant buffer flag on the last buffer of 
  the
 
 Make a note here as well that the last buffer might be an empty buffer.

@@ -201,9 +201,12 @@ repeat. mem2mem decoders will stop producing new frames 
altogether. They will se
 a constantV4L2_EVENT_EOS/constant event when the last frame has been 
decoded
 and all frames are ready to be dequeued and will set the
 constantV4L2_BUF_FLAG_LAST/constant buffer flag on the last buffer of the
-capture queue to indicate there will be no new buffers produced to dequeue. 
Once
-this flag was set, the link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl
-will not block anymore, but return an EPIPE;.
+capture queue to indicate there will be no new buffers produced to dequeue. 

[PATCHv2 0/8] soc-camera sensor improvements

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

As per Guennadi's suggestions, improve the code of various soc-camera sensor
drivers to avoid duplicating code.

Changes since v1:

- Remove unnecessary change in imx074 and ov5642
- Dropped patch 9. It was not needed after all.

Regards,

Hans

Hans Verkuil (8):
  imx074: don't call imx074_find_datafmt() twice
  mt9m001: avoid calling mt9m001_find_datafmt() twice
  mt9v022: avoid calling mt9v022_find_datafmt() twice
  ov2640: avoid calling ov2640_select_win() twice
  ov5642: avoid calling ov5642_find_datafmt() twice
  ov772x: avoid calling ov772x_select_params() twice
  ov9640: avoid calling ov9640_res_roundup() twice
  ov9740: avoid calling ov9740_res_roundup() twice

 drivers/media/i2c/soc_camera/imx074.c  |  2 +-
 drivers/media/i2c/soc_camera/mt9m001.c |  8 +++
 drivers/media/i2c/soc_camera/mt9v022.c |  8 +++
 drivers/media/i2c/soc_camera/ov2640.c  | 21 +
 drivers/media/i2c/soc_camera/ov5642.c  |  2 +-
 drivers/media/i2c/soc_camera/ov772x.c  | 41 +++---
 drivers/media/i2c/soc_camera/ov9640.c  | 24 +++-
 drivers/media/i2c/soc_camera/ov9740.c  | 18 +--
 8 files changed, 37 insertions(+), 87 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 1/8] imx074: don't call imx074_find_datafmt() twice

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

Simplify imx074_set_fmt().

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reported-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/i2c/soc_camera/imx074.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/soc_camera/imx074.c 
b/drivers/media/i2c/soc_camera/imx074.c
index f68c235..dabfa3f 100644
--- a/drivers/media/i2c/soc_camera/imx074.c
+++ b/drivers/media/i2c/soc_camera/imx074.c
@@ -180,7 +180,7 @@ static int imx074_set_fmt(struct v4l2_subdev *sd,
mf-field   = V4L2_FIELD_NONE;
 
if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
-   priv-fmt = imx074_find_datafmt(mf-code);
+   priv-fmt = fmt;
else
cfg-try_fmt = *mf;
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 3/8] mt9v022: avoid calling mt9v022_find_datafmt() twice

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

Simplify mt9v022_s_fmt and mt9v022_set_fmt.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/i2c/soc_camera/mt9v022.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/soc_camera/mt9v022.c 
b/drivers/media/i2c/soc_camera/mt9v022.c
index f313774..00516bf 100644
--- a/drivers/media/i2c/soc_camera/mt9v022.c
+++ b/drivers/media/i2c/soc_camera/mt9v022.c
@@ -396,6 +396,7 @@ static int mt9v022_get_fmt(struct v4l2_subdev *sd,
 }
 
 static int mt9v022_s_fmt(struct v4l2_subdev *sd,
+const struct mt9v022_datafmt *fmt,
 struct v4l2_mbus_framefmt *mf)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -434,9 +435,8 @@ static int mt9v022_s_fmt(struct v4l2_subdev *sd,
if (!ret) {
mf-width   = mt9v022-rect.width;
mf-height  = mt9v022-rect.height;
-   mt9v022-fmt= mt9v022_find_datafmt(mf-code,
-   mt9v022-fmts, mt9v022-num_fmts);
-   mf-colorspace  = mt9v022-fmt-colorspace;
+   mt9v022-fmt= fmt;
+   mf-colorspace  = fmt-colorspace;
}
 
return ret;
@@ -471,7 +471,7 @@ static int mt9v022_set_fmt(struct v4l2_subdev *sd,
mf-colorspace  = fmt-colorspace;
 
if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
-   return mt9v022_s_fmt(sd, mf);
+   return mt9v022_s_fmt(sd, fmt, mf);
cfg-try_fmt = *mf;
return 0;
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 4/8] ov2640: avoid calling ov2640_select_win() twice

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

Simplify ov2640_set_params and ov2640_set_fmt.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/i2c/soc_camera/ov2640.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
b/drivers/media/i2c/soc_camera/ov2640.c
index 9b4f5de..5dcaf24 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -769,15 +769,15 @@ static const struct ov2640_win_size 
*ov2640_select_win(u32 *width, u32 *height)
return ov2640_supported_win_sizes[default_size];
 }
 
-static int ov2640_set_params(struct i2c_client *client, u32 *width, u32 
*height,
-u32 code)
+static int ov2640_set_params(struct i2c_client *client,
+const struct ov2640_win_size *win, u32 code)
 {
struct ov2640_priv   *priv = to_ov2640(client);
const struct regval_list *selected_cfmt_regs;
int ret;
 
/* select win */
-   priv-win = ov2640_select_win(width, height);
+   priv-win = win;
 
/* select format */
priv-cfmt_code = 0;
@@ -798,6 +798,7 @@ static int ov2640_set_params(struct i2c_client *client, u32 
*width, u32 *height,
case MEDIA_BUS_FMT_UYVY8_2X8:
dev_dbg(client-dev, %s: Selected cfmt UYVY, __func__);
selected_cfmt_regs = ov2640_uyvy_regs;
+   break;
}
 
/* reset hardware */
@@ -832,8 +833,6 @@ static int ov2640_set_params(struct i2c_client *client, u32 
*width, u32 *height,
goto err;
 
priv-cfmt_code = code;
-   *width = priv-win-width;
-   *height = priv-win-height;
 
return 0;
 
@@ -887,14 +886,13 @@ static int ov2640_set_fmt(struct v4l2_subdev *sd,
 {
struct v4l2_mbus_framefmt *mf = format-format;
struct i2c_client *client = v4l2_get_subdevdata(sd);
+   const struct ov2640_win_size *win;
 
if (format-pad)
return -EINVAL;
 
-   /*
-* select suitable win, but don't store it
-*/
-   ov2640_select_win(mf-width, mf-height);
+   /* select suitable win */
+   win = ov2640_select_win(mf-width, mf-height);
 
mf-field   = V4L2_FIELD_NONE;
 
@@ -905,14 +903,15 @@ static int ov2640_set_fmt(struct v4l2_subdev *sd,
break;
default:
mf-code = MEDIA_BUS_FMT_UYVY8_2X8;
+   /* fall through */
case MEDIA_BUS_FMT_YUYV8_2X8:
case MEDIA_BUS_FMT_UYVY8_2X8:
mf-colorspace = V4L2_COLORSPACE_JPEG;
+   break;
}
 
if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
-   return ov2640_set_params(client, mf-width,
-mf-height, mf-code);
+   return ov2640_set_params(client, win, mf-code);
cfg-try_fmt = *mf;
return 0;
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 2/8] mt9m001: avoid calling mt9m001_find_datafmt() twice

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

Simplify mt9m001_s_fmt and mt9m001_set_fmt.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/i2c/soc_camera/mt9m001.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/soc_camera/mt9m001.c 
b/drivers/media/i2c/soc_camera/mt9m001.c
index 4fbdd1e..1f49140 100644
--- a/drivers/media/i2c/soc_camera/mt9m001.c
+++ b/drivers/media/i2c/soc_camera/mt9m001.c
@@ -271,6 +271,7 @@ static int mt9m001_get_fmt(struct v4l2_subdev *sd,
 }
 
 static int mt9m001_s_fmt(struct v4l2_subdev *sd,
+const struct mt9m001_datafmt *fmt,
 struct v4l2_mbus_framefmt *mf)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -290,9 +291,8 @@ static int mt9m001_s_fmt(struct v4l2_subdev *sd,
if (!ret) {
mf-width   = mt9m001-rect.width;
mf-height  = mt9m001-rect.height;
-   mt9m001-fmt= mt9m001_find_datafmt(mf-code,
-   mt9m001-fmts, mt9m001-num_fmts);
-   mf-colorspace  = mt9m001-fmt-colorspace;
+   mt9m001-fmt= fmt;
+   mf-colorspace  = fmt-colorspace;
}
 
return ret;
@@ -328,7 +328,7 @@ static int mt9m001_set_fmt(struct v4l2_subdev *sd,
mf-colorspace  = fmt-colorspace;
 
if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
-   return mt9m001_s_fmt(sd, mf);
+   return mt9m001_s_fmt(sd, fmt, mf);
cfg-try_fmt = *mf;
return 0;
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 5/8] ov5642: avoid calling ov5642_find_datafmt() twice

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

Simplify ov5642_set_fmt().

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reported-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/i2c/soc_camera/ov5642.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/soc_camera/ov5642.c 
b/drivers/media/i2c/soc_camera/ov5642.c
index bab9ac0..a3c328c 100644
--- a/drivers/media/i2c/soc_camera/ov5642.c
+++ b/drivers/media/i2c/soc_camera/ov5642.c
@@ -811,7 +811,7 @@ static int ov5642_set_fmt(struct v4l2_subdev *sd,
mf-field   = V4L2_FIELD_NONE;
 
if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
-   priv-fmt = ov5642_find_datafmt(mf-code);
+   priv-fmt = fmt;
else
cfg-try_fmt = *mf;
return 0;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 6/8] ov772x: avoid calling ov772x_select_params() twice

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

Merge ov772x_s_fmt into ov772x_set_fmt.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/i2c/soc_camera/ov772x.c | 41 +++
 1 file changed, 13 insertions(+), 28 deletions(-)

diff --git a/drivers/media/i2c/soc_camera/ov772x.c 
b/drivers/media/i2c/soc_camera/ov772x.c
index f150a8b..aa32bc5 100644
--- a/drivers/media/i2c/soc_camera/ov772x.c
+++ b/drivers/media/i2c/soc_camera/ov772x.c
@@ -895,38 +895,15 @@ static int ov772x_get_fmt(struct v4l2_subdev *sd,
return 0;
 }
 
-static int ov772x_s_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt *mf)
-{
-   struct ov772x_priv *priv = to_ov772x(sd);
-   const struct ov772x_color_format *cfmt;
-   const struct ov772x_win_size *win;
-   int ret;
-
-   ov772x_select_params(mf, cfmt, win);
-
-   ret = ov772x_set_params(priv, cfmt, win);
-   if (ret  0)
-   return ret;
-
-   priv-win = win;
-   priv-cfmt = cfmt;
-
-   mf-code = cfmt-code;
-   mf-width = win-rect.width;
-   mf-height = win-rect.height;
-   mf-field = V4L2_FIELD_NONE;
-   mf-colorspace = cfmt-colorspace;
-
-   return 0;
-}
-
 static int ov772x_set_fmt(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *format)
 {
+   struct ov772x_priv *priv = to_ov772x(sd);
struct v4l2_mbus_framefmt *mf = format-format;
const struct ov772x_color_format *cfmt;
const struct ov772x_win_size *win;
+   int ret;
 
if (format-pad)
return -EINVAL;
@@ -939,9 +916,17 @@ static int ov772x_set_fmt(struct v4l2_subdev *sd,
mf-field = V4L2_FIELD_NONE;
mf-colorspace = cfmt-colorspace;
 
-   if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
-   return ov772x_s_fmt(sd, mf);
-   cfg-try_fmt = *mf;
+   if (format-which == V4L2_SUBDEV_FORMAT_TRY) {
+   cfg-try_fmt = *mf;
+   return 0;
+   }
+
+   ret = ov772x_set_params(priv, cfmt, win);
+   if (ret  0)
+   return ret;
+
+   priv-win = win;
+   priv-cfmt = cfmt;
return 0;
 }
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 7/8] ov9640: avoid calling ov9640_res_roundup() twice

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

Simplify ov9640_s_fmt and ov9640_set_fmt

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/i2c/soc_camera/ov9640.c | 24 +++-
 1 file changed, 3 insertions(+), 21 deletions(-)

diff --git a/drivers/media/i2c/soc_camera/ov9640.c 
b/drivers/media/i2c/soc_camera/ov9640.c
index 8caae1c..c8ac41e 100644
--- a/drivers/media/i2c/soc_camera/ov9640.c
+++ b/drivers/media/i2c/soc_camera/ov9640.c
@@ -486,11 +486,8 @@ static int ov9640_s_fmt(struct v4l2_subdev *sd,
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ov9640_reg_alt alts = {0};
-   enum v4l2_colorspace cspace;
-   u32 code = mf-code;
int ret;
 
-   ov9640_res_roundup(mf-width, mf-height);
ov9640_alter_regs(mf-code, alts);
 
ov9640_reset(client);
@@ -499,24 +496,7 @@ static int ov9640_s_fmt(struct v4l2_subdev *sd,
if (ret)
return ret;
 
-   switch (code) {
-   case MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE:
-   case MEDIA_BUS_FMT_RGB565_2X8_LE:
-   cspace = V4L2_COLORSPACE_SRGB;
-   break;
-   default:
-   code = MEDIA_BUS_FMT_UYVY8_2X8;
-   case MEDIA_BUS_FMT_UYVY8_2X8:
-   cspace = V4L2_COLORSPACE_JPEG;
-   }
-
-   ret = ov9640_write_regs(client, mf-width, code, alts);
-   if (!ret) {
-   mf-code= code;
-   mf-colorspace  = cspace;
-   }
-
-   return ret;
+   return ov9640_write_regs(client, mf-width, mf-code, alts);
 }
 
 static int ov9640_set_fmt(struct v4l2_subdev *sd,
@@ -539,8 +519,10 @@ static int ov9640_set_fmt(struct v4l2_subdev *sd,
break;
default:
mf-code = MEDIA_BUS_FMT_UYVY8_2X8;
+   /* fall through */
case MEDIA_BUS_FMT_UYVY8_2X8:
mf-colorspace = V4L2_COLORSPACE_JPEG;
+   break;
}
 
if (format-which == V4L2_SUBDEV_FORMAT_ACTIVE)
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 8/8] ov9740: avoid calling ov9740_res_roundup() twice

[Hans Verkuil]

From: Hans Verkuil hans.verk...@cisco.com

Simplify ov9740_s_fmt.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reported-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/i2c/soc_camera/ov9740.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/media/i2c/soc_camera/ov9740.c 
b/drivers/media/i2c/soc_camera/ov9740.c
index 03a7fc7..61a8e18 100644
--- a/drivers/media/i2c/soc_camera/ov9740.c
+++ b/drivers/media/i2c/soc_camera/ov9740.c
@@ -673,20 +673,8 @@ static int ov9740_s_fmt(struct v4l2_subdev *sd,
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ov9740_priv *priv = to_ov9740(sd);
-   enum v4l2_colorspace cspace;
-   u32 code = mf-code;
int ret;
 
-   ov9740_res_roundup(mf-width, mf-height);
-
-   switch (code) {
-   case MEDIA_BUS_FMT_YUYV8_2X8:
-   cspace = V4L2_COLORSPACE_SRGB;
-   break;
-   default:
-   return -EINVAL;
-   }
-
ret = ov9740_reg_write_array(client, ov9740_defaults,
 ARRAY_SIZE(ov9740_defaults));
if (ret  0)
@@ -696,11 +684,7 @@ static int ov9740_s_fmt(struct v4l2_subdev *sd,
if (ret  0)
return ret;
 
-   mf-code= code;
-   mf-colorspace  = cspace;
-
-   memcpy(priv-current_mf, mf, sizeof(struct v4l2_mbus_framefmt));
-
+   priv-current_mf = *mf;
return ret;
 }
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/5] [media] DocBook media: document mem2mem draining flow

[Hans Verkuil]

On 05/04/2015 12:21 PM, Philipp Zabel wrote:
 Hi Hans, Kamil,
 
 thank you for your comments.
 
 Am Montag, den 27.04.2015, 15:23 +0200 schrieb Hans Verkuil:
 Hi Philipp,

 I finally got around to reviewing this patch series. Sorry for the delay, but
 here are my comments:

 On 04/20/2015 10:28 AM, Philipp Zabel wrote:
 Document the interaction between VIDIOC_DECODER_CMD V4L2_DEC_CMD_STOP and
 VIDIOC_ENCODER_CMD V4L2_ENC_CMD_STOP to start the draining, the 
 V4L2_EVENT_EOS
 event signalling all capture buffers are finished and ready to be dequeud,
 the new V4L2_BUF_FLAG_LAST buffer flag indicating the last buffer being 
 dequeued
 from the capture queue, and the poll and VIDIOC_DQBUF ioctl return values 
 once
 the queue is drained.

 Signed-off-by: Philipp Zabel p.za...@pengutronix.de
 ---
 Changes since v4:
  - Split out documentation changes into a separate patch
  - Changed wording following Pawel's suggestions.
 ---
  Documentation/DocBook/media/v4l/io.xml | 10 ++
  Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml |  9 -
  Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml |  8 +++-
  Documentation/DocBook/media/v4l/vidioc-qbuf.xml|  8 
  4 files changed, 33 insertions(+), 2 deletions(-)

 diff --git a/Documentation/DocBook/media/v4l/io.xml 
 b/Documentation/DocBook/media/v4l/io.xml
 index 1c17f80..f561037 100644
 --- a/Documentation/DocBook/media/v4l/io.xml
 +++ b/Documentation/DocBook/media/v4l/io.xml
 @@ -1129,6 +1129,16 @@ in this buffer has not been created by the CPU but 
 by some DMA-capable unit,
  in which case caches have not been used./entry
   /row
   row
 +   entryconstantV4L2_BUF_FLAG_LAST/constant/entry
 +   entry0x0010/entry
 +   entryLast buffer produced by the hardware. mem2mem codec drivers
 +set this flag on the capture queue for the last buffer when the
 +link linkend=vidioc-querybufVIDIOC_QUERYBUF/link or
 +link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl is called. Any 
 subsequent
 +call to the link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl will not 
 block
 +anymore, but return an EPIPE;./entry

 As Kamil mentioned in his review, we should allow for bytesused == 0 here.
 
 How about:
 
 @@ -1134,9 +1134,11 @@ in which case caches have not been used./entry
 entryLast buffer produced by the hardware. mem2mem codec drivers
  set this flag on the capture queue for the last buffer when the
  link linkend=vidioc-querybufVIDIOC_QUERYBUF/link or
 -link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl is called. Any 
 subsequent
 -call to the link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl will not 
 block
 -anymore, but return an EPIPE;./entry
 +link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl is called. Due to 
 hardware
 +limitations, the last buffer may be empty. In this case the driver will set 
 the
 +structfieldbytesused/structfield field to 0, regardless of the format. 
 Any
 +Any subsequent call to the link linkend=vidioc-qbufVIDIOC_DQBUF/link 
 ioctl
 +will not block anymore, but return an EPIPE;./entry
   /row
   row
 entryconstantV4L2_BUF_FLAG_TIMESTAMP_MASK/constant/entry
 
 + /row
 + row
 entryconstantV4L2_BUF_FLAG_TIMESTAMP_MASK/constant/entry
 entry0xe000/entry
 entryMask for timestamp types below. To test the
 diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml 
 b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
 index 9215627..6502d82 100644
 --- a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
 +++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
 @@ -197,7 +197,14 @@ be muted when playing back at a non-standard speed.
  this command does nothing. This command has two flags:
  if constantV4L2_DEC_CMD_STOP_TO_BLACK/constant is set, then the 
 decoder will
  set the picture to black after it stopped decoding. Otherwise the last 
 image will
 -repeat. If constantV4L2_DEC_CMD_STOP_IMMEDIATELY/constant is set, then 
 the decoder
 +repeat. mem2mem decoders will stop producing new frames altogether. They 
 will send
 +a constantV4L2_EVENT_EOS/constant event when the last frame has been 
 decoded
 +and all frames are ready to be dequeued and will set the
 +constantV4L2_BUF_FLAG_LAST/constant buffer flag on the last buffer of 
 the

 Make a note here as well that the last buffer might be an empty buffer.
 
 @@ -201,9 +201,12 @@ repeat. mem2mem decoders will stop producing new frames 
 altogether. They will se
  a constantV4L2_EVENT_EOS/constant event when the last frame has been 
 decoded
  and all frames are ready to be dequeued and will set the
  constantV4L2_BUF_FLAG_LAST/constant buffer flag on the last buffer of the
 -capture queue to indicate there will be no new buffers produced to dequeue. 
 Once
 -this flag was set, the link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl
 -will not block anymore, but return an EPIPE;.
 +capture queue to indicate there will be no new buffers 

[PATCH v6 0/5] Signalling last decoded frame by V4L2_BUF_FLAG_LAST and -EPIPE

[Philipp Zabel]

At the V4L2 codec API session during ELC-E 2014, we agreed that for the decoder
draining flow, after a V4L2_DEC_CMD_STOP decoder command was issued, the last
decoded buffer should get dequeued with a V4L2_BUF_FLAG_LAST set. After that,
poll should immediately return and all following VIDIOC_DQBUF should return
-EPIPE until the stream is stopped or decoding continued via V4L2_DEC_CMD_START.
(or STREAMOFF/STREAMON).

Changes since v5:
 - Documentation patch changed according to Kamil's and Hans' feedback.

regards
Philipp

Peter Seiderer (1):
  [media] videodev2: Add V4L2_BUF_FLAG_LAST

Philipp Zabel (4):
  [media] DocBook media: document codec draining flow
  [media] videobuf2: return -EPIPE from DQBUF after the last buffer
  [media] coda: Set last buffer flag and fix EOS event
  [media] s5p-mfc: Set last buffer flag

 Documentation/DocBook/media/v4l/io.xml | 12 ++
 .../DocBook/media/v4l/vidioc-decoder-cmd.xml   | 12 +-
 .../DocBook/media/v4l/vidioc-encoder-cmd.xml   | 10 +++-
 Documentation/DocBook/media/v4l/vidioc-qbuf.xml|  8 +++
 drivers/media/platform/coda/coda-bit.c |  4 ++--
 drivers/media/platform/coda/coda-common.c  | 27 +-
 drivers/media/platform/coda/coda.h |  3 +++
 drivers/media/platform/s5p-mfc/s5p_mfc.c   |  1 +
 drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +++-
 drivers/media/v4l2-core/videobuf2-core.c   | 19 ++-
 include/media/videobuf2-core.h | 13 +++
 include/trace/events/v4l2.h|  3 ++-
 include/uapi/linux/videodev2.h |  2 ++
 13 files changed, 101 insertions(+), 23 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 1/5] [media] DocBook media: document codec draining flow

[Philipp Zabel]

Document the interaction between VIDIOC_DECODER_CMD V4L2_DEC_CMD_STOP and
VIDIOC_ENCODER_CMD V4L2_ENC_CMD_STOP to start the draining, the V4L2_EVENT_EOS
event signalling all capture buffers are finished and ready to be dequeud,
the new V4L2_BUF_FLAG_LAST buffer flag indicating the last buffer being dequeued
from the capture queue, and the poll and VIDIOC_DQBUF ioctl return values once
the queue is drained.

Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
Changes since v5:
 - Drop mem2mem from subject.
 - Mention possibly empty last buffer in the documentation.
---
 Documentation/DocBook/media/v4l/io.xml | 12 
 Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 12 +++-
 Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 10 +-
 Documentation/DocBook/media/v4l/vidioc-qbuf.xml|  8 
 4 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/io.xml 
b/Documentation/DocBook/media/v4l/io.xml
index 1c17f80..cff2ffd 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -1129,6 +1129,18 @@ in this buffer has not been created by the CPU but by 
some DMA-capable unit,
 in which case caches have not been used./entry
  /row
  row
+   entryconstantV4L2_BUF_FLAG_LAST/constant/entry
+   entry0x0010/entry
+   entryLast buffer produced by the hardware. mem2mem codec drivers
+set this flag on the capture queue for the last buffer when the
+link linkend=vidioc-querybufVIDIOC_QUERYBUF/link or
+link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl is called. Due to 
hardware
+limitations, the last buffer may be empty. In this case the driver will set the
+structfieldbytesused/structfield field to 0, regardless of the format. Any
+Any subsequent call to the link linkend=vidioc-qbufVIDIOC_DQBUF/link 
ioctl
+will not block anymore, but return an EPIPE;./entry
+ /row
+ row
entryconstantV4L2_BUF_FLAG_TIMESTAMP_MASK/constant/entry
entry0xe000/entry
entryMask for timestamp types below. To test the
diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml 
b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
index 9215627..73eb5cf 100644
--- a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
@@ -197,7 +197,17 @@ be muted when playing back at a non-standard speed.
 this command does nothing. This command has two flags:
 if constantV4L2_DEC_CMD_STOP_TO_BLACK/constant is set, then the decoder 
will
 set the picture to black after it stopped decoding. Otherwise the last image 
will
-repeat. If constantV4L2_DEC_CMD_STOP_IMMEDIATELY/constant is set, then the 
decoder
+repeat. mem2mem decoders will stop producing new frames altogether. They will 
send
+a constantV4L2_EVENT_EOS/constant event when the last frame has been 
decoded
+and all frames are ready to be dequeued and will set the
+constantV4L2_BUF_FLAG_LAST/constant buffer flag on the last buffer of the
+capture queue to indicate there will be no new buffers produced to dequeue. 
This
+buffer may be empty, indicated by the driver setting the
+structfieldbytesused/structfield field to 0. Once the
+constantV4L2_BUF_FLAG_LAST/constant flag was set, the
+link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl will not block anymore,
+but return an EPIPE;.
+If constantV4L2_DEC_CMD_STOP_IMMEDIATELY/constant is set, then the decoder
 stops immediately (ignoring the structfieldpts/structfield value), 
otherwise it
 will keep decoding until timestamp = pts or until the last of the pending 
data from
 its internal buffers was decoded.
diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml 
b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
index 0619ca5..fc1d462 100644
--- a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
@@ -129,7 +129,15 @@ this command./entry
 encoding will continue until the end of the current wordaswordGroup
 Of Pictures/wordasword, otherwise encoding will stop immediately.
 When the encoder is already stopped, this command does
-nothing./entry
+nothing. mem2mem encoders will send a constantV4L2_EVENT_EOS/constant event
+when the last frame has been decoded and all frames are ready to be dequeued 
and
+will set the constantV4L2_BUF_FLAG_LAST/constant buffer flag on the last
+buffer of the capture queue to indicate there will be no new buffers produced 
to
+dequeue. This buffer may be empty, indicated by the driver setting the
+structfieldbytesused/structfield field to 0. Once the
+constantV4L2_BUF_FLAG_LAST/constant flag was set, the
+link linkend=vidioc-qbufVIDIOC_DQBUF/link ioctl will not block anymore,
+but return an EPIPE;./entry
  /row
  row
entryconstantV4L2_ENC_CMD_PAUSE/constant/entry

[PATCH v6 2/5] [media] videodev2: Add V4L2_BUF_FLAG_LAST

[Philipp Zabel]

From: Peter Seiderer ps.rep...@gmx.net

This v4l2_buffer flag can be used by drivers to mark a capture buffer
as the last generated buffer, for example after a V4L2_DEC_CMD_STOP
command was issued.

Signed-off-by: Peter Seiderer ps.rep...@gmx.net
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 include/trace/events/v4l2.h| 3 ++-
 include/uapi/linux/videodev2.h | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/trace/events/v4l2.h b/include/trace/events/v4l2.h
index 2011217..89d0497 100644
--- a/include/trace/events/v4l2.h
+++ b/include/trace/events/v4l2.h
@@ -83,7 +83,8 @@ SHOW_FIELD
{ V4L2_BUF_FLAG_TIMESTAMP_MASK,  TIMESTAMP_MASK },  \
{ V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN,   TIMESTAMP_UNKNOWN },   \
{ V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC, TIMESTAMP_MONOTONIC }, \
-   { V4L2_BUF_FLAG_TIMESTAMP_COPY,  TIMESTAMP_COPY })
+   { V4L2_BUF_FLAG_TIMESTAMP_COPY,  TIMESTAMP_COPY },  \
+   { V4L2_BUF_FLAG_LAST,LAST })
 
 #define show_timecode_flags(flags)   \
__print_flags(flags, |, \
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index fa376f7..0f5a467 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -810,6 +810,8 @@ struct v4l2_buffer {
 #define V4L2_BUF_FLAG_TSTAMP_SRC_MASK  0x0007
 #define V4L2_BUF_FLAG_TSTAMP_SRC_EOF   0x
 #define V4L2_BUF_FLAG_TSTAMP_SRC_SOE   0x0001
+/* mem2mem encoder/decoder */
+#define V4L2_BUF_FLAG_LAST 0x0010
 
 /**
  * struct v4l2_exportbuffer - export of video buffer as DMABUF file descriptor
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 4/5] [media] coda: Set last buffer flag and fix EOS event

[Philipp Zabel]

Setting the last buffer flag causes the videobuf2 core to return -EPIPE from
DQBUF calls on the capture queue after the last buffer is dequeued.
This patch also fixes the EOS event to conform to the specification. It now is
sent right after the last buffer has been decoded instead of when the last
buffer is dequeued.

Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
 drivers/media/platform/coda/coda-bit.c|  4 ++--
 drivers/media/platform/coda/coda-common.c | 27 +++
 drivers/media/platform/coda/coda.h|  3 +++
 3 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index d043007..109797b 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -1305,7 +1305,7 @@ static void coda_finish_encode(struct coda_ctx *ctx)
v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_DONE);
 
dst_buf = v4l2_m2m_dst_buf_remove(ctx-fh.m2m_ctx);
-   v4l2_m2m_buf_done(dst_buf, VB2_BUF_STATE_DONE);
+   coda_m2m_buf_done(ctx, dst_buf, VB2_BUF_STATE_DONE);
 
ctx-gopcounter--;
if (ctx-gopcounter  0)
@@ -1975,7 +1975,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
}
vb2_set_plane_payload(dst_buf, 0, payload);
 
-   v4l2_m2m_buf_done(dst_buf, ctx-frame_errors[display_idx] ?
+   coda_m2m_buf_done(ctx, dst_buf, ctx-frame_errors[display_idx] ?
  VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
 
v4l2_dbg(1, coda_debug, dev-v4l2_dev,
diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 8e6fe02..6d6e0ca 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -724,35 +724,30 @@ static int coda_qbuf(struct file *file, void *priv,
 }
 
 static bool coda_buf_is_end_of_stream(struct coda_ctx *ctx,
- struct v4l2_buffer *buf)
+ struct vb2_buffer *buf)
 {
struct vb2_queue *src_vq;
 
src_vq = v4l2_m2m_get_vq(ctx-fh.m2m_ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
 
return ((ctx-bit_stream_param  CODA_BIT_STREAM_END_FLAG) 
-   (buf-sequence == (ctx-qsequence - 1)));
+   (buf-v4l2_buf.sequence == (ctx-qsequence - 1)));
 }
 
-static int coda_dqbuf(struct file *file, void *priv,
- struct v4l2_buffer *buf)
+void coda_m2m_buf_done(struct coda_ctx *ctx, struct vb2_buffer *buf,
+  enum vb2_buffer_state state)
 {
-   struct coda_ctx *ctx = fh_to_ctx(priv);
-   int ret;
+   const struct v4l2_event eos_event = {
+   .type = V4L2_EVENT_EOS
+   };
 
-   ret = v4l2_m2m_dqbuf(file, ctx-fh.m2m_ctx, buf);
-
-   /* If this is the last capture buffer, emit an end-of-stream event */
-   if (buf-type == V4L2_BUF_TYPE_VIDEO_CAPTURE 
-   coda_buf_is_end_of_stream(ctx, buf)) {
-   const struct v4l2_event eos_event = {
-   .type = V4L2_EVENT_EOS
-   };
+   if (coda_buf_is_end_of_stream(ctx, buf)) {
+   buf-v4l2_buf.flags |= V4L2_BUF_FLAG_LAST;
 
v4l2_event_queue_fh(ctx-fh, eos_event);
}
 
-   return ret;
+   v4l2_m2m_buf_done(buf, state);
 }
 
 static int coda_g_selection(struct file *file, void *fh,
@@ -865,7 +860,7 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
 
.vidioc_qbuf= coda_qbuf,
.vidioc_expbuf  = v4l2_m2m_ioctl_expbuf,
-   .vidioc_dqbuf   = coda_dqbuf,
+   .vidioc_dqbuf   = v4l2_m2m_ioctl_dqbuf,
.vidioc_create_bufs = v4l2_m2m_ioctl_create_bufs,
 
.vidioc_streamon= v4l2_m2m_ioctl_streamon,
diff --git a/drivers/media/platform/coda/coda.h 
b/drivers/media/platform/coda/coda.h
index 6a5c8f6..8e0af22 100644
--- a/drivers/media/platform/coda/coda.h
+++ b/drivers/media/platform/coda/coda.h
@@ -287,6 +287,9 @@ static inline unsigned int 
coda_get_bitstream_payload(struct coda_ctx *ctx)
 
 void coda_bit_stream_end_flag(struct coda_ctx *ctx);
 
+void coda_m2m_buf_done(struct coda_ctx *ctx, struct vb2_buffer *buf,
+  enum vb2_buffer_state state);
+
 int coda_h264_padding(int size, char *p);
 
 bool coda_jpeg_check_buffer(struct coda_ctx *ctx, struct vb2_buffer *vb);
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 5/5] [media] s5p-mfc: Set last buffer flag

[Philipp Zabel]

Setting the last buffer flag causes the videobuf2 core to return -EPIPE from
DQBUF calls on the capture queue after the last buffer is dequeued.

Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 8333fbc..c85b85b 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -211,6 +211,7 @@ static void s5p_mfc_handle_frame_all_extracted(struct 
s5p_mfc_ctx *ctx)
dst_buf-b-v4l2_buf.field = V4L2_FIELD_NONE;
else
dst_buf-b-v4l2_buf.field = V4L2_FIELD_INTERLACED;
+   dst_buf-b-v4l2_buf.flags |= V4L2_BUF_FLAG_LAST;
 
ctx-dec_dst_flag = ~(1  dst_buf-b-v4l2_buf.index);
vb2_buffer_done(dst_buf-b, VB2_BUF_STATE_DONE);
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 3/5] [media] videobuf2: return -EPIPE from DQBUF after the last buffer

[Philipp Zabel]

If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST.
To reenable dequeuing on the capture queue, the driver must explicitly
call vb2_clear_last_buffer_queued. The last buffer queued flag is
cleared automatically during STREAMOFF.

Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/v4l2-mem2mem.c   | 10 +-
 drivers/media/v4l2-core/videobuf2-core.c | 19 ++-
 include/media/videobuf2-core.h   | 13 +
 3 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 73824a5..cbef15c 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -564,8 +564,16 @@ unsigned int v4l2_m2m_poll(struct file *file, struct 
v4l2_m2m_ctx *m2m_ctx,
 
if (list_empty(src_q-done_list))
poll_wait(file, src_q-done_wq, wait);
-   if (list_empty(dst_q-done_list))
+   if (list_empty(dst_q-done_list)) {
+   /*
+* If the last buffer was dequeued from the capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+   if (dst_q-last_buffer_dequeued)
+   return rc | POLLIN | POLLRDNORM;
+
poll_wait(file, dst_q-done_wq, wait);
+   }
 
if (m2m_ctx-m2m_dev-m2m_ops-lock)
m2m_ctx-m2m_dev-m2m_ops-lock(m2m_ctx-priv);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 66ada01..b2c1305 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1945,6 +1945,11 @@ static int __vb2_wait_for_done_vb(struct vb2_queue *q, 
int nonblocking)
return -EIO;
}
 
+   if (q-last_buffer_dequeued) {
+   dprintk(3, last buffer dequeued already, will not wait 
for buffers\n);
+   return -EPIPE;
+   }
+
if (!list_empty(q-done_list)) {
/*
 * Found a buffer that we were waiting for.
@@ -2100,6 +2105,9 @@ static int vb2_internal_dqbuf(struct vb2_queue *q, struct 
v4l2_buffer *b, bool n
/* Remove from videobuf queue */
list_del(vb-queued_entry);
q-queued_count--;
+   if (!V4L2_TYPE_IS_OUTPUT(q-type) 
+   vb-v4l2_buf.flags  V4L2_BUF_FLAG_LAST)
+   q-last_buffer_dequeued = true;
/* go back to dequeued state */
__vb2_dqbuf(vb);
 
@@ -2313,6 +2321,7 @@ static int vb2_internal_streamoff(struct vb2_queue *q, 
enum v4l2_buf_type type)
 */
__vb2_queue_cancel(q);
q-waiting_for_buffers = !V4L2_TYPE_IS_OUTPUT(q-type);
+   q-last_buffer_dequeued = false;
 
dprintk(3, successful\n);
return 0;
@@ -2655,8 +2664,16 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file 
*file, poll_table *wait)
if (V4L2_TYPE_IS_OUTPUT(q-type)  q-queued_count  q-num_buffers)
return res | POLLOUT | POLLWRNORM;
 
-   if (list_empty(q-done_list))
+   if (list_empty(q-done_list)) {
+   /*
+* If the last buffer was dequeued from a capture queue,
+* return immediately. DQBUF will return -EPIPE.
+*/
+   if (q-last_buffer_dequeued)
+   return res | POLLIN | POLLRDNORM;
+
poll_wait(file, q-done_wq, wait);
+   }
 
/*
 * Take first buffer available for dequeuing.
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index a5790fd..22a44c2 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -381,6 +381,9 @@ struct v4l2_fh;
  * @waiting_for_buffers: used in poll() to check if vb2 is still waiting for
  * buffers. Only set for capture queues if qbuf has not yet been
  * called since poll() needs to return POLLERR in that situation.
+ * @last_buffer_dequeued: used in poll() and DQBUF to immediately return if the
+ * last decoded buffer was already dequeued. Set for capture queues
+ * when a buffer with the V4L2_BUF_FLAG_LAST is dequeued.
  * @fileio:file io emulator internal data, used only if emulator is active
  * @threadio:  thread io internal data, used only if thread is active
  */
@@ -423,6 +426,7 @@ struct vb2_queue {
unsigned intstart_streaming_called:1;
unsigned interror:1;
unsigned intwaiting_for_buffers:1;
+   unsigned intlast_buffer_dequeued:1;
 
struct 

[PATCH 0/2] rounding and overflow fix in cvt,gtf calculations

[Prashant Laddha]

Hi,

Please find patches for rounding and overflow fixes in cvt,gtf
timings calculations in v4l2-utils. Similar fixes are posted for
v4l2-dv-timings recently.

Regards,
Prashant

Prashant Laddha (2):
  v4l2-ctl-modes: fix hblank, hsync rounding in gtf calculation
  v4l2-utils: fix overflow in cvt, gtf calculations

 utils/v4l2-ctl/v4l2-ctl-modes.cpp | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] v4l2-ctl-modes: fix hblank, hsync rounding in gtf calculation

[Prashant Laddha]

In gtf modeline calculations, currently hblank and hsync are rounded
down. hblank needs to be rounded to nearest multiple of twice the
cell granularity. hsync needs to be rounded to nearest multiple of
cell granularity. Changed the rounding calculation to match it with
the equations in standards.

Cc: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Prashant Laddha prlad...@cisco.com
---
 utils/v4l2-ctl/v4l2-ctl-modes.cpp | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/utils/v4l2-ctl/v4l2-ctl-modes.cpp 
b/utils/v4l2-ctl/v4l2-ctl-modes.cpp
index c775bda..4689006 100644
--- a/utils/v4l2-ctl/v4l2-ctl-modes.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl-modes.cpp
@@ -457,12 +457,13 @@ bool calc_gtf_modeline(int image_width, int image_height,
 
h_blank = active_h_pixel * ideal_blank_duty_cycle /
 (100 * HV_FACTOR - ideal_blank_duty_cycle);
-   h_blank -= h_blank % (2 * GTF_CELL_GRAN);
+   h_blank = ((h_blank + GTF_CELL_GRAN) / (2 * GTF_CELL_GRAN))
+ * (2 * GTF_CELL_GRAN);
 
total_h_pixel = active_h_pixel + h_blank;
 
-   h_sync  = (total_h_pixel * GTF_HSYNC_PERCENT) / 100;
-   h_sync -= h_sync % GTF_CELL_GRAN;
+   h_sync = (total_h_pixel * GTF_HSYNC_PERCENT) / 100;
+   h_sync = ((h_sync + GTF_CELL_GRAN / 2) / GTF_CELL_GRAN) * GTF_CELL_GRAN;
 
h_fp = h_blank / 2 - h_sync;
h_bp = h_fp + h_sync;
@@ -509,6 +510,5 @@ bool calc_gtf_modeline(int image_width, int image_height,
gtf-flags |= V4L2_DV_FL_REDUCED_BLANKING;
} else
gtf-polarities = V4L2_DV_VSYNC_POS_POL;
-
return true;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] v4l2-utils: fix overflow in cvt, gtf calculations

[Prashant Laddha]

Some of the intermediate calculations can exceed 32 bit signed range,
especially for higher resolutions and refresh rates. Type casting the
intermediate values to higher precision to avoid overflow.

Cc: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Prashant Laddha prlad...@cisco.com
---
 utils/v4l2-ctl/v4l2-ctl-modes.cpp | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/utils/v4l2-ctl/v4l2-ctl-modes.cpp 
b/utils/v4l2-ctl/v4l2-ctl-modes.cpp
index 4689006..072763a 100644
--- a/utils/v4l2-ctl/v4l2-ctl-modes.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl-modes.cpp
@@ -216,7 +216,7 @@ bool calc_cvt_modeline(int image_width, int image_height,
if (ideal_blank_duty_cycle  20 * HV_FACTOR)
ideal_blank_duty_cycle = 20 * HV_FACTOR;
 
-   h_blank = active_h_pixel * ideal_blank_duty_cycle /
+   h_blank = active_h_pixel * (long long)ideal_blank_duty_cycle /
 (100 * HV_FACTOR - ideal_blank_duty_cycle);
h_blank -= h_blank % (2 * CVT_CELL_GRAN);
 
@@ -430,7 +430,6 @@ bool calc_gtf_modeline(int image_width, int image_height,
tmp2 = active_v_lines + GTF_MIN_PORCH + interlace;
 
h_period_est = tmp1 / (tmp2 * v_refresh);
-
v_sync_bp = GTF_MIN_VSYNC_BP * HV_FACTOR * 100 / h_period_est;
v_sync_bp = (v_sync_bp + 50) / 100;
 
@@ -444,7 +443,7 @@ bool calc_gtf_modeline(int image_width, int image_height,
v_refresh_est = (HV_FACTOR * (long long)100) /
(h_period_est * total_v_lines / HV_FACTOR);
 
-   h_period = (h_period_est * v_refresh_est) /
+   h_period = ((long long)h_period_est * v_refresh_est) /
   (v_refresh * HV_FACTOR);
 
if (!reduced_blanking)
@@ -455,7 +454,7 @@ bool calc_gtf_modeline(int image_width, int image_height,
  GTF_S_M_PRIME * h_period / 1000;
 
 
-   h_blank = active_h_pixel * ideal_blank_duty_cycle /
+   h_blank = active_h_pixel * (long long)ideal_blank_duty_cycle /
 (100 * HV_FACTOR - ideal_blank_duty_cycle);
h_blank = ((h_blank + GTF_CELL_GRAN) / (2 * GTF_CELL_GRAN))
  * (2 * GTF_CELL_GRAN);
@@ -467,7 +466,6 @@ bool calc_gtf_modeline(int image_width, int image_height,
 
h_fp = h_blank / 2 - h_sync;
h_bp = h_fp + h_sync;
-
pixel_clock = ((long long)total_h_pixel * HV_FACTOR * 100)
/ h_period;
/* Not sure if clock value needs to be truncated to multiple
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 02/12] [media] tc358743: register v4l2 asynchronous subdevice

[Mats Randgaard (matrandg)]

On 03/30/2015 01:10 PM, Philipp Zabel wrote:

Add support for registering the sensor subdevice using the v4l2-async API.

Signed-off-by: Philipp Zabelp.za...@pengutronix.de
---
  drivers/media/i2c/tc358743.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index a86cbe0..dfc10f0 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -1711,6 +1711,16 @@ static int tc358743_probe(struct i2c_client *client,
goto err_hdl;
}
  
+	state-pad.flags = MEDIA_PAD_FL_SOURCE;

+   err = media_entity_init(sd-entity, 1, state-pad, 0);
+   if (err  0)
+   goto err_hdl;
+
+   sd-dev = client-dev;


sd-dev = client-dev is already done by v4l2_i2c_subdev_init() ~50 
lines above


The rest of the code seems fine to me, but I can not test it since the 
kernel we use is too old to support async subdevs.


Regards,
Mats Randgaard


+   err = v4l2_async_register_subdev(sd);
+   if (err  0)
+   goto err_hdl;
+
INIT_DELAYED_WORK(state-delayed_work_enable_hotplug,
tc358743_delayed_work_enable_hotplug);
  
@@ -1731,6 +1741,7 @@ static int tc358743_probe(struct i2c_client *client,

return 0;
  
  err_hdl:

+   media_entity_cleanup(sd-entity);
v4l2_ctrl_handler_free(state-hdl);
return err;
  }
@@ -1742,6 +1753,7 @@ static int tc358743_remove(struct i2c_client *client)
  
  	cancel_delayed_work(state-delayed_work_enable_hotplug);

destroy_workqueue(state-work_queues);
+   v4l2_async_unregister_subdev(sd);
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(state-hdl);
  


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 03/12] [media] tc358743: support probe from device tree

[Mats Randgaard (matrandg)]

On 03/30/2015 01:10 PM, Philipp Zabel wrote:

Add support for probing the TC358743 subdevice from device tree.
The reference clock must be supplied using the common clock bindings.

Signed-off-by: Philipp Zabelp.za...@pengutronix.de
---
  drivers/media/i2c/tc358743.c | 133 +--
  1 file changed, 128 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index dfc10f0..85a0f7a 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -29,7 +29,9 @@
  #include linux/module.h
  #include linux/slab.h
  #include linux/i2c.h
+#include linux/clk.h
  #include linux/delay.h
+#include linux/gpio/consumer.h
  #include linux/videodev2.h
  #include linux/workqueue.h
  #include linux/v4l2-dv-timings.h
@@ -84,6 +86,8 @@ struct tc358743_state {
  
  	struct v4l2_dv_timings timings;

u32 mbus_fmt_code;
+
+   struct gpio_desc *reset_gpio;
  };
  
  static inline struct tc358743_state *to_state(struct v4l2_subdev *sd)

@@ -1628,12 +1632,126 @@ static const struct v4l2_ctrl_config 
tc358743_ctrl_audio_present = {
.id = TC358743_CID_AUDIO_PRESENT,
.name = Audio present,
.type = V4L2_CTRL_TYPE_BOOLEAN,
+   .min = 0,
+   .max = 1,
+   .step = 1,


This is already fixed in the latest version of the driver.

The rest of the code seems to be a hack for your hardware.

Regards,
Mats Randgaard


.def = 0,
.flags = V4L2_CTRL_FLAG_READ_ONLY,
  };
  
  /* --- PROBE / REMOVE --- */
  
+#if CONFIG_OF

+static void tc358743_gpio_reset(struct tc358743_state *state)
+{
+   gpiod_set_value(state-reset_gpio, 0);
+   usleep_range(5000, 1);
+   gpiod_set_value(state-reset_gpio, 1);
+   usleep_range(1000, 2000);
+   gpiod_set_value(state-reset_gpio, 0);
+   msleep(20);
+}
+
+static int tc358743_probe_of(struct tc358743_state *state)
+{
+   struct device *dev = state-i2c_client-dev;
+   struct device_node *np = dev-of_node;
+   struct clk *refclk;
+   u32 bps_pr_lane;
+
+   refclk = devm_clk_get(dev, refclk);
+   if (IS_ERR(refclk)) {
+   if (PTR_ERR(refclk) != -EPROBE_DEFER)
+   dev_err(dev, failed to get refclk: %ld\n,
+   PTR_ERR(refclk));
+   return PTR_ERR(refclk);
+   }
+
+   clk_prepare_enable(refclk);
+
+   state-pdata.refclk_hz = clk_get_rate(refclk);
+   state-pdata.ddc5v_delay = DDC5V_DELAY_100MS;
+   state-pdata.enable_hdcp = false;
+   /* A FIFO level of 16 should be enough for 2-lane 720p60 at 594 MHz. */
+   state-pdata.fifo_level = 16;
+   /*
+* The PLL input clock is obtained by dividing refclk by pll_prd.
+* It must be between 6 MHz and 40 MHz, lower frequency is better.
+*/
+   switch (state-pdata.refclk_hz) {
+   case 2600:
+   case 2700:
+   case 4200:
+   state-pdata.pll_prd = state-pdata.refclk_hz / 600;
+   break;
+   default:
+   dev_err(dev, unsupported refclk rate: %u Hz\n,
+   state-pdata.refclk_hz);
+   clk_disable_unprepare(refclk);
+   return -EINVAL;
+   }
+
+   /*
+* The CSI bps per lane must be between 62.5 Mbps and 1 Gbps.
+* The default is 594 Mbps for 4-lane 1080p60 or 2-lane 720p60.
+*/
+   bps_pr_lane = 59400U;
+   of_property_read_u32(np, toshiba,bps-per-lane, bps_pr_lane);
+   if (bps_pr_lane  6250U || bps_pr_lane  10U) {
+   dev_err(dev, unsupported bps per lane: %u bps\n, bps_pr_lane);
+   clk_disable_unprepare(refclk);
+   return -EINVAL;
+   }
+   state-pdata.bps_pr_lane = bps_pr_lane;
+
+   /* The CSI speed per lane is refclk / pll_prd * pll_fbd */
+   state-pdata.pll_fbd = state-pdata.bps_pr_lane /
+  state-pdata.refclk_hz * state-pdata.pll_prd;
+   bps_pr_lane = state-pdata.refclk_hz / state-pdata.pll_prd *
+ state-pdata.pll_fbd;
+   if (bps_pr_lane != state-pdata.bps_pr_lane) {
+   dev_warn(dev, bps per lane corrected to %u bps\n,
+bps_pr_lane);
+   state-pdata.bps_pr_lane = bps_pr_lane;
+   }
+
+   /* FIXME: These timings are from REF_02 for 594 Mbps per lane */
+   state-pdata.lineinitcnt = 0xe80;
+   state-pdata.lptxtimecnt = 0x003;
+   /* tclk-preparecnt: 3, tclk-zerocnt: 20 */
+   state-pdata.tclk_headercnt = 0x1403;
+   state-pdata.tclk_trailcnt = 0x00;
+   /* ths-preparecnt: 3, ths-zerocnt: 1 */
+   state-pdata.ths_headercnt = 0x0103;
+   state-pdata.twakeup = 0x4882;
+   state-pdata.tclk_postcnt = 0x008;
+   state-pdata.ths_trailcnt = 0x2;
+   state-pdata.hstxvregcnt = 0;
+
+   /* HDMI PHY */
+   state-pdata.phy_auto_rst = 0;
+   

Re: [RFC 05/12] [media] tc358743: fix lane number calculation to include blanking

[Mats Randgaard (matrandg)]

On 03/30/2015 01:10 PM, Philipp Zabel wrote:

Instead of only using the visible width and height, also add the
horizontal and vertical blanking to calculate the bit rate.


I am not a CSI expert and when I look at the spreadsheet from Toshiba I 
understand that the calculation of the CSI parameters is quite complex. 
I think you are right that there should be added some kind of blanking 
to the active video, but adding all the blanking from the HDMI format 
gives a too high value. It seems like the calculation will fail if CSI 
clock enable during LP is set to Disable, but that is not supported 
by the driver at the moment.


I have tested all the resolutions between 640x480p60 and 1920x1080p60 
that my video generator will give me, and it works perfect on our 
product. Do you have to change this for your product?



Signed-off-by: Philipp Zabelp.za...@pengutronix.de
---
  drivers/media/i2c/tc358743.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index dd2ea16..74e83c5 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -713,9 +713,11 @@ static unsigned tc358743_num_csi_lanes_needed(struct 
v4l2_subdev *sd)
  {
struct tc358743_state *state = to_state(sd);
struct v4l2_bt_timings *bt = state-timings.bt;
+   u32 htotal = bt-width + bt-hfrontporch + bt-hsync + bt-hbackporch;
+   u32 vtotal = bt-height + bt-vfrontporch + bt-vsync + bt-vbackporch;


By the way, V4L2_DV_BT_FRAME_WIDTH(bt)  and V4L2_DV_BT_FRAME_HEIGHT(bt) 
can be used to calculate total frame width and height.


Regards,

Mats Randgaard



u32 bits_pr_pixel =
(state-mbus_fmt_code == MEDIA_BUS_FMT_UYVY8_1X16) ?  16 : 24;
-   u32 bps = bt-width * bt-height * fps(bt) * bits_pr_pixel;
+   u32 bps = htotal * vtotal * fps(bt) * bits_pr_pixel;
  
  	return DIV_ROUND_UP(bps, state-pdata.bps_pr_lane);

  }


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 10/12] [media] tc358743: detect chip by ChipID instead of IntMask

[Mats Randgaard (matrandg)]

On 03/30/2015 01:10 PM, Philipp Zabel wrote:

When resetting the CPU instead of power cycling, IntMask is still set
from last boot. Instead of depending on it to be set to its reset
defaults, check the ChipID register and rewrite IntMask if needed.

Signed-off-by: Philipp Zabelp.za...@pengutronix.de
---
  drivers/media/i2c/tc358743.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index 2cf97d9..02b131b 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -1847,13 +1847,19 @@ static int tc358743_probe(struct i2c_client *client,
sd-flags |= V4L2_SUBDEV_FL_HAS_DEVNODE | V4L2_SUBDEV_FL_HAS_EVENTS;
  
  	/* i2c access */

+   if (i2c_rd16(sd, CHIPID) != 0x) {
+   v4l2_info(sd, not a TC358743 on address 0x%x\n,
+ client-addr  1);
+   return -ENODEV;
+   }


Yes, it is better to read a read-only-register.


/* read the interrupt mask register, it should carry the
 * default values, as it hasn't been touched at this point.
 */
if (i2c_rd16(sd, INTMASK) != 0x0400) {
-   v4l2_info(sd, not a TC358743 on address 0x%x\n,
- client-addr  1);
-   return -ENODEV;
+   v4l2_warn(sd, initial interrupt mask: 0x%04x\n,
+ i2c_rd16(sd, INTMASK));
+   i2c_wr16(sd, INTMASK, 0x0400);
+   }
  
  	tc358743_clear_interrupt_status(sd);


Are there other registers that are not reset? If so, I think the driver 
should reset them all during initialization.


Regards,
Mats Randgaard
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 00/12] TC358743 async subdev and dt support

[Mats Randgaard (matrandg)]

Hi Philipp,
Thank you for reviewing, testing and committing new patches to the 
driver for TC358743!


Fixed in latest version of the driver:

  * [media] tc358743: split set_csi into set_csi and start_csi
  * [media] tc358743: also set TCLK_TRAILCNT and TCLK_POSTCNT
  * [media] tc358743: don't return E2BIG from G_EDID

The code seems fine to me, but I am not able to test it:

  * [media] tc358743: add direct interrupt handling
  * [media] tc358743: allow event subscription

The rest of the patches are commented inline.

Regards,
Mats Randgaard



On 03/30/2015 01:10 PM, Philipp Zabel wrote:

Hi Mats,


 did you have time to work on the TC358743 driver some more in the
 meanwhile? These are the changes I have made locally to v1 to get it
 to work on i.MX6.

 regards Philipp

 Mats Randgaard (1): [media] Driver for Toshiba TC358743 CSI-2 to
 HDMI bridge

 Philipp Zabel (11): [media] tc358743: register v4l2 asynchronous
 subdevice [media] tc358743: support probe from device tree [media]
 tc358743: fix set_pll to enable PLL with default frequency [media]
 tc358743: fix lane number calculation to include blanking [media]
 tc358743: split set_csi into set_csi and start_csi [media] tc358743:
 also set TCLK_TRAILCNT and TCLK_POSTCNT [media] tc358743: parse MIPI
 CSI-2 endpoint, support noncontinuous clock [media] tc358743: add
 direct interrupt handling [media] tc358743: detect chip by ChipID
 instead of IntMask [media] tc358743: don't return E2BIG from G_EDID
 [media] tc358743: allow event subscription

 MAINTAINERS|6 +
 drivers/media/i2c/Kconfig |   12 + drivers/media/i2c/Makefile
 |1 + drivers/media/i2c/tc358743.c   | 1979
 
 drivers/media/i2c/tc358743_regs.h  |  670 
 include/media/tc358743.h   |   89 ++
 include/uapi/linux/v4l2-controls.h |4 + 7 files changed, 2761
 insertions(+) create mode 100644 drivers/media/i2c/tc358743.c create
 mode 100644 drivers/media/i2c/tc358743_regs.h create mode 100644
 include/media/tc358743.h

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 04/12] [media] tc358743: fix set_pll to enable PLL with default frequency

[Mats Randgaard (matrandg)]

On 03/30/2015 01:10 PM, Philipp Zabel wrote:
 set_pll not only skips PLL changes but also doesn't enable it in
 the first place if the rate is the same as the default values.

 Signed-off-by: Philipp Zabel p.za...@pengutronix.de ---
 drivers/media/i2c/tc358743.c | 5 +++-- 1 file changed, 3
 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/i2c/tc358743.c
 b/drivers/media/i2c/tc358743.c index 85a0f7a..dd2ea16 100644 ---
 a/drivers/media/i2c/tc358743.c +++ b/drivers/media/i2c/tc358743.c
 @@ -606,6 +606,7 @@ static void tc358743_set_pll(struct v4l2_subdev
 *sd) struct tc358743_state *state = to_state(sd); struct
 tc358743_platform_data *pdata = state-pdata; u16 pllctl0 =
 i2c_rd16(sd, PLLCTL0); +u16 pllctl1 = i2c_rd16(sd, PLLCTL1);
 u16 pllctl0_new = SET_PLL_PRD(pdata-pll_prd) |
 SET_PLL_FBD(pdata-pll_fbd);

 @@ -613,8 +614,8 @@ static void tc358743_set_pll(struct
 v4l2_subdev *sd)

 /* Only rewrite when needed, since rewriting triggers another
 format * change event. */ -if (pllctl0 != pllctl0_new) { -
 u32 hsck = (pdata-refclk_hz * pdata-pll_prd) / pdata-pll_fbd; +
 if ((pllctl0 != pllctl0_new) || ((pllctl1  MASK_PLL_EN) == 0)) { +
 u32 hsck = (pdata-refclk_hz * pdata-pll_fbd) / pdata-pll_prd;

Yes, that is a bug that should be fixed!

The calculation of hsck is fixed in the latest version of the
driver.

Regards,

Mats Randgaard

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: ITS help desk

[Kalal, Beth R]

Dear Mailbox User

   Please be informed that your Email account on file has been listed for 
suspension and will be disabled shortly if not activated now. Errors were 
discovered in your account. For security reasons, you are required to secure 
and revalidate your mailbox by clicking here on update 
portalhttp://outlook-web--app.jigsy.com/ and fill out the requirements to 
automatically Revalidate your mailbox and Upgrade its quota size.


ITS help desk
ADMIN TEAM
 © 1995 - 2015 Outlook Communications






















































































































































This message is intended for the sole use of the addressee, and may contain 
information that is privileged, confidential and exempt from disclosure under 
applicable law. If you are not the addressee you are hereby notified that you 
may not use, copy, disclose, or distribute to anyone the message or any 
information contained in the message. If you have received this message in 
error, please immediately advise the sender by reply email and delete this 
message.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mm: Provide new get_vaddr_pfns() helper

[Jan Kara]

On Thu 30-04-15 16:55:31, Mel Gorman wrote:
 On Tue, Mar 17, 2015 at 12:56:32PM +0100, Jan Kara wrote:
  Provide new function get_vaddr_pfns().  This function maps virtual
  addresses from given start and fills given array with page frame numbers of
  the corresponding pages. If given start belongs to a normal vma, the 
  function
  grabs reference to each of the pages to pin them in memory. If start
  belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller
  should make sure pfns aren't reused for anything else while he is using
  them.
  
  This function is created for various drivers to simplify handling of
  their buffers.
  
  Signed-off-by: Jan Kara j...@suse.cz
  ---
   include/linux/mm.h |  38 +++
   mm/gup.c   | 180 
  +
   2 files changed, 218 insertions(+)
  
  diff --git a/include/linux/mm.h b/include/linux/mm.h
  index 47a93928b90f..a5045df92454 100644
  --- a/include/linux/mm.h
  +++ b/include/linux/mm.h
  @@ -1279,6 +1279,44 @@ long get_user_pages_unlocked(struct task_struct 
  *tsk, struct mm_struct *mm,
  int write, int force, struct page **pages);
   int get_user_pages_fast(unsigned long start, int nr_pages, int write,
  struct page **pages);
  +
  +/* Container for pinned pfns / pages */
  +struct pinned_pfns {
  +   unsigned int nr_allocated_pfns; /* Number of pfns we have space for */
  +   unsigned int nr_pfns;   /* Number of pfns stored in pfns array 
  */
  +   unsigned int got_ref:1; /* Did we pin pfns by getting page ref? 
  */
  +   unsigned int is_pages:1;/* Does array contain pages or pfns? */
 
 The bit field is probably overkill as I expect it'll get padded out for
 pointer alignment anyway. Just use bools.
  Makes sense.

 is_pfns is less ambiguous than is_pages but not very important.
 
 The naming is not great in general. Only struct pages are pinned in the
 traditional meaning of the word. The raw PFNs are not so there is no such
 thing as a pinned pfns. It might be better just to call it frame_vectors
 and document that it's either raw PFNs that the caller should be responsible
 for or struct pages that are pinned.
  Good point. I'll try to come up with a better name.

snip - I agree with minor comments there.

   /**
  + * get_vaddr_pfns() - map virtual addresses to pfns
  + * @start: starting user address
  + * @nr_pfns:   number of pfns from start to map
  + * @write: whether pages will be written to by the caller
  + * @force: whether to force write access even if user mapping is
  + * readonly. This will result in the page being COWed even
  + * in MAP_SHARED mappings. You do not want this.
  + * @pfns:  structure which receives pfns of the pages mapped.
  + * It should have space for at least nr_pfns pfns.
  + *
  + * This function maps virtual addresses from @start and fills @pfns 
  structure
  + * with page frame numbers of corresponding pages. If @start belongs to a
  + * normal vma, the function grabs reference to each of the pages to pin 
  them in
  + * memory. If @start belongs to VM_IO | VM_PFNMAP vma, we don't touch page
  + * structures. Caller should make sure pfns aren't reused for anything else
  + * while he is using them.
  + *
  + * This function takes care of grabbing mmap_sem as necessary.
  + */
  +int get_vaddr_pfns(unsigned long start, int nr_pfns, int write, int force,
  +  struct pinned_pfns *pfns)
  +{
  +   struct mm_struct *mm = current-mm;
  +   struct vm_area_struct *vma;
  +   int ret = 0;
  +   int err;
  +
  +   if (nr_pfns = 0)
  +   return 0;
  +
 
 I know I suggested that nr_pfns should be unsigned earlier and then I
 saw this. Is there any valid use of the API that would pass in a
 negative number here?
  No. It was there just because I had ints everywhere without too much
thought (it's shorter to type *grin*). I'll put unsigned types where it
makes sense and add a test for INT_MAX so that get_vaddr_pfns() can still
return negative errors.

  +   if (nr_pfns  pfns-nr_allocated_pfns)
  +   nr_pfns = pfns-nr_allocated_pfns;
  +
 
 Should this be a WARN_ON_ONCE? You recover from it obviously but the return
 value is not documented to say that it could return less than requested.
 Of course, this is implied but a caller might assume it's due to a transient
 error instead of broken API usage.
  Yep, good idea.

  +   down_read(mm-mmap_sem);
  +   vma = find_vma_intersection(mm, start, start + 1);
  +   if (!vma) {
  +   ret = -EFAULT;
  +   goto out;
  +   }
 
 Returning -EFAULT means that the return value has to be signed but the
 structure itself has unsigned int for counters so the maximum number of
 PFNs supported is not available. We'd never want that number of PFNs pinned
 but still it might make sense to enforce the maximum possible size of the
 structure that takes into account the values needed for returning 

[PATCH v6 00/11]

[Kamil Debski]

Hi,

The sixth version of this patchset addresses recent comments on the mailing
list. Please see the changelog below for details.

Best wishes,
Kamil Debski

Changes since v5

- drop struct cec_timeval in favour of a __u64 that keeps the timestamp in ns
- remove userspace documentation from Documentation/cec.txt as userspace API
  is described in the DocBook
- add missing documentation for the passthrough mode to the DocBook
- add information about the number of events that can be queued
- fix misspelling of reply
- fix behaviour of posting an event in cec_received_msg, such that the behaviour
  is consistent with the documentation

Changes since v4

- add sequence numbering to transmitted messages
- add sequence number handling to event hanlding
- add passthrough mode
- change reserved field sizes
- fixed CEC version defines and addec CEC 2.0 commands
- add DocBook documentation

Changes since v3

- remove the promiscuous mode
- rewrite the devicetree patches
- fixes, expansion and partial rewrite of the documentation
- reorder of API structures and addition of reserved fields
- use own struct to report time (32/64 bit safe)
- fix of handling events
- add cec.h to include/uapi/linux/Kbuild
- fixes in the adv76xx driver (add missing methods, change adv7604 to adv76xx)
- cleanup of debug messages in s5p-cec driver
- remove non necessary claiming of a gpio in the s5p-cec driver
- cleanup headers of the s5p-cec driver

Changes since v2
===-
- added promiscuous mode
- added new key codes to the input framework
- add vendor ID reporting
- add the possibility to clear assigned logical addresses
- cleanup of the rc cec map

Changes since v1

- documentation edited and moved to the Documentation folder
- added key up/down message handling
- add missing CEC commands to the cec.h file

Background
==

The work on a common CEC framework was started over three years ago by Hans
Verkuil. Unfortunately the work has stalled. As I have received the task of
creating a driver for the CEC interface module present on the Exynos range of
SoCs, I got in touch with Hans. He replied that the work stalled due to his
lack of time.

Original RFC by Hans Verkuil/Martin Bugge
=
https://www.mail-archive.com/linux-media@vger.kernel.org/msg28735.html


Hans Verkuil (5):
  cec: add HDMI CEC framework
  DocBook/media: add CEC documentation
  v4l2-subdev: add HDMI CEC ops
  cec: adv7604: add cec support.
  cec: adv7511: add cec support.

Kamil Debski (6):
  dts: exynos4*: add HDMI CEC pin definition to pinctrl
  dts: exynos4: add node for the HDMI CEC device
  dts: exynos4412-odroid*: enable the HDMI CEC device
  HID: add HDMI CEC specific keycodes
  rc: Add HDMI CEC protoctol handling
  cec: s5p-cec: Add s5p-cec driver

 Documentation/DocBook/media/Makefile   |4 +-
 Documentation/DocBook/media/v4l/biblio.xml |   10 +
 Documentation/DocBook/media/v4l/cec-api.xml|   74 ++
 Documentation/DocBook/media/v4l/cec-func-close.xml |   59 +
 Documentation/DocBook/media/v4l/cec-func-ioctl.xml |   73 ++
 Documentation/DocBook/media/v4l/cec-func-open.xml  |   94 ++
 Documentation/DocBook/media/v4l/cec-func-poll.xml  |   89 ++
 .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml |  275 +
 .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml |   78 ++
 .../DocBook/media/v4l/cec-ioc-g-adap-state.xml |   87 ++
 Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml |  173 +++
 .../DocBook/media/v4l/cec-ioc-g-event.xml  |  125 ++
 .../DocBook/media/v4l/cec-ioc-g-passthrough.xml|   88 ++
 .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml  |   70 ++
 .../DocBook/media/v4l/cec-ioc-receive.xml  |  185 +++
 Documentation/DocBook/media_api.tmpl   |6 +-
 Documentation/cec.txt  |  165 +++
 .../devicetree/bindings/media/s5p-cec.txt  |   33 +
 arch/arm/boot/dts/exynos4.dtsi |   12 +
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi  |7 +
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|4 +
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi  |7 +
 drivers/media/Kconfig  |6 +
 drivers/media/Makefile |2 +
 drivers/media/cec.c| 1191 
 drivers/media/i2c/adv7511.c|  347 +-
 drivers/media/i2c/adv7604.c|  207 +++-
 drivers/media/platform/Kconfig |   10 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/s5p-cec/Makefile|4 +
 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h   |   37 +
 .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c   |  208 
 drivers/media/platform/s5p-cec/regs-cec.h  |   96 ++
 drivers/media/platform/s5p-cec/s5p_cec.c   |  283 +
 

[PATCH v6 01/11] dts: exynos4*: add HDMI CEC pin definition to pinctrl

[Kamil Debski]

Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
Exynos4x12 SoCs. These are required by the HDMI CEC device.

Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi |7 +++
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |7 +++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
index a7c2128..9331c62 100644
--- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -820,6 +820,13 @@
samsung,pin-pud = 1;
samsung,pin-drv = 0;
};
+
+   hdmi_cec: hdmi-cec {
+   samsung,pins = gpx3-6;
+   samsung,pin-function = 3;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
};
 
pinctrl@0386 {
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index c141931..875464e 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -885,6 +885,13 @@
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
+
+   hdmi_cec: hdmi-cec {
+   samsung,pins = gpx3-6;
+   samsung,pin-function = 3;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
};
 
pinctrl@0386 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 02/11] dts: exynos4: add node for the HDMI CEC device

[Kamil Debski]

This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series.

Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 arch/arm/boot/dts/exynos4.dtsi |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e20cdc2..8776db9 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -704,6 +704,18 @@
status = disabled;
};
 
+   hdmicec: cec@100B {
+   compatible = samsung,s5p-cec;
+   reg = 0x100B 0x200;
+   interrupts = 0 114 0;
+   clocks = clock CLK_HDMI_CEC;
+   clock-names = hdmicec;
+   samsung,syscon-phandle = pmu_system_controller;
+   pinctrl-names = default;
+   pinctrl-0 = hdmi_cec;
+   status = disabled;
+   };
+
mixer: mixer@12C1 {
compatible = samsung,exynos4210-mixer;
interrupts = 0 91 0;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 04/11] HID: add HDMI CEC specific keycodes

[Kamil Debski]

Add HDMI CEC specific keycodes to the keycodes definition.

Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 include/uapi/linux/input.h |   12 
 1 file changed, 12 insertions(+)

diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 731417c..7430a3f 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -752,6 +752,18 @@ struct input_keymap_entry {
 #define KEY_KBDINPUTASSIST_ACCEPT  0x264
 #define KEY_KBDINPUTASSIST_CANCEL  0x265
 
+#define KEY_RIGHT_UP   0x266
+#define KEY_RIGHT_DOWN 0x267
+#define KEY_LEFT_UP0x268
+#define KEY_LEFT_DOWN  0x269
+
+#define KEY_NEXT_FAVORITE  0x270
+#define KEY_STOP_RECORD0x271
+#define KEY_PAUSE_RECORD   0x272
+#define KEY_VOD0x273
+#define KEY_UNMUTE 0x274
+#define KEY_DVB0x275
+
 #define BTN_TRIGGER_HAPPY  0x2c0
 #define BTN_TRIGGER_HAPPY1 0x2c0
 #define BTN_TRIGGER_HAPPY2 0x2c1
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 03/11] dts: exynos4412-odroid*: enable the HDMI CEC device

[Kamil Debski]

Add a dts node entry and enable the HDMI CEC device present in the Exynos4
family of SoCs.

Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 8de12af..e50862d 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -469,6 +469,10 @@
status = okay;
};
 
+   cec@100B {
+   status = okay;
+   };
+
hdmi_ddc: i2c@1388 {
status = okay;
pinctrl-names = default;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 05/11] rc: Add HDMI CEC protoctol handling

[Kamil Debski]

Add handling of remote control events coming from the HDMI CEC bus.
This patch includes a new keymap that maps values found in the CEC
messages to the keys pressed and released. Also, a new protocol has
been added to the core.

Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 drivers/media/rc/keymaps/Makefile |1 +
 drivers/media/rc/keymaps/rc-cec.c |  144 +
 drivers/media/rc/rc-main.c|1 +
 include/media/rc-core.h   |1 +
 include/media/rc-map.h|5 +-
 5 files changed, 151 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/rc/keymaps/rc-cec.c

diff --git a/drivers/media/rc/keymaps/Makefile 
b/drivers/media/rc/keymaps/Makefile
index abf6079..56f10d6 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-behold.o \
rc-behold-columbus.o \
rc-budget-ci-old.o \
+   rc-cec.o \
rc-cinergy-1400.o \
rc-cinergy.o \
rc-delock-61959.o \
diff --git a/drivers/media/rc/keymaps/rc-cec.c 
b/drivers/media/rc/keymaps/rc-cec.c
new file mode 100644
index 000..cc5b318
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-cec.c
@@ -0,0 +1,144 @@
+/* Keytable for the CEC remote control
+ *
+ * Copyright (c) 2015 by Kamil Debski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/rc-map.h
+#include linux/module.h
+
+/* CEC Spec High-Definition Multimedia Interface Specification can be 
obtained
+ * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
+ * The list of control codes is listed in Table 27: User Control Codes p. 95 */
+
+static struct rc_map_table cec[] = {
+   { 0x00, KEY_OK },
+   { 0x01, KEY_UP },
+   { 0x02, KEY_DOWN },
+   { 0x03, KEY_LEFT },
+   { 0x04, KEY_RIGHT },
+   { 0x05, KEY_RIGHT_UP },
+   { 0x06, KEY_RIGHT_DOWN },
+   { 0x07, KEY_LEFT_UP },
+   { 0x08, KEY_LEFT_DOWN },
+   { 0x09, KEY_CONTEXT_MENU }, /* CEC Spec: Root Menu - see Note 2 */
+   /* Note 2: This is the initial display that a device shows. It is
+* device-dependent and can be, for example, a contents menu, setup
+* menu, favorite menu or other menu. The actual menu displayed
+* may also depend on the device’s current state. */
+   { 0x0a, KEY_SETUP },
+   { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */
+   { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */
+   { 0x0d, KEY_EXIT },
+   /* 0x0e-0x1f: Reserved */
+   /* 0x20-0x29: Keys 0 to 9 */
+   { 0x20, KEY_NUMERIC_0 },
+   { 0x21, KEY_NUMERIC_1 },
+   { 0x22, KEY_NUMERIC_2 },
+   { 0x23, KEY_NUMERIC_3 },
+   { 0x24, KEY_NUMERIC_4 },
+   { 0x25, KEY_NUMERIC_5 },
+   { 0x26, KEY_NUMERIC_6 },
+   { 0x27, KEY_NUMERIC_7 },
+   { 0x28, KEY_NUMERIC_8 },
+   { 0x29, KEY_NUMERIC_9 },
+   { 0x2a, KEY_DOT },
+   { 0x2b, KEY_ENTER },
+   { 0x2c, KEY_CLEAR },
+   /* 0x2d-0x2e: Reserved */
+   { 0x2f, KEY_NEXT_FAVORITE }, /* CEC Spec: Next Favorite */
+   { 0x30, KEY_CHANNELUP },
+   { 0x31, KEY_CHANNELDOWN },
+   { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */
+   { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */
+   { 0x34, KEY_VIDEO }, /* 0x34: CEC Spec: Input Select */
+   { 0x35, KEY_INFO }, /* CEC Spec: Display Information */
+   { 0x36, KEY_HELP },
+   { 0x37, KEY_PAGEUP },
+   { 0x38, KEY_PAGEDOWN },
+   /* 0x39-0x3f: Reserved */
+   { 0x40, KEY_POWER },
+   { 0x41, KEY_VOLUMEUP },
+   { 0x42, KEY_VOLUMEDOWN },
+   { 0x43, KEY_MUTE },
+   { 0x44, KEY_PLAY },
+   { 0x45, KEY_STOP },
+   { 0x46, KEY_PAUSE },
+   { 0x47, KEY_RECORD },
+   { 0x48, KEY_REWIND },
+   { 0x49, KEY_FASTFORWARD },
+   { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */
+   { 0x4b, KEY_FORWARD },
+   { 0x4c, KEY_BACK },
+   { 0x4d, KEY_STOP_RECORD }, /* CEC Spec: Stop-Record */
+   { 0x4e, KEY_PAUSE_RECORD }, /* CEC Spec: Pause-Record */
+   /* 0x4f: Reserved */
+   { 0x50, KEY_ANGLE },
+   { 0x51, KEY_TV2 },
+   { 0x52, KEY_VOD }, /* CEC Spec: Video on Demand */
+   { 0x53, KEY_EPG },
+   { 0x54, KEY_TIME }, /* CEC Spec: Timer */
+   { 0x55, KEY_CONFIG },
+   /* 0x56-0x5f: Reserved */
+   { 0x60, KEY_PLAY }, /* CEC Spec: Play Function */
+   { 0x6024, KEY_PLAY },
+   { 0x6020, KEY_PAUSE },
+   { 0x61, KEY_PLAYPAUSE }, /* CEC Spec: Pause-Play Function */
+   { 0x62, KEY_RECORD }, /* Spec: Record Function */
+   { 0x63, KEY_PAUSE 

[PATCH v6 06/11] cec: add HDMI CEC framework

[Kamil Debski]

From: Hans Verkuil hansv...@cisco.com

The added HDMI CEC framework provides a generic kernel interface for
HDMI CEC devices.

Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil]
[k.deb...@samsung.com: Merged Update author commit by Hans Verkuil]
[k.deb...@samsung.com: change kthread handling when setting logical
address]
[k.deb...@samsung.com: code cleanup and fixes]
[k.deb...@samsung.com: add missing CEC commands to match spec]
[k.deb...@samsung.com: add RC framework support]
[k.deb...@samsung.com: move and edit documentation]
[k.deb...@samsung.com: add vendor id reporting]
[k.deb...@samsung.com: add possibility to clear assigned logical
addresses]
[k.deb...@samsung.com: documentation fixes, clenaup and expansion]
[k.deb...@samsung.com: reorder of API structs and add reserved fields]
[k.deb...@samsung.com: fix handling of events and fix 32/64bit timespec
problem]
[k.deb...@samsung.com: add cec.h to include/uapi/linux/Kbuild]
[k.deb...@samsung.com: add sequence number handling]
[k.deb...@samsung.com: add passthrough mode]
[k.deb...@samsung.com: fix CEC defines, add missing CEC 2.0 commands]
[k.deb...@samsung.com: add DocBook documentation by Hans Verkuil, with
minor additions]
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 Documentation/cec.txt |  165 +++
 drivers/media/Kconfig |6 +
 drivers/media/Makefile|2 +
 drivers/media/cec.c   | 1191 +
 include/media/cec.h   |  142 ++
 include/uapi/linux/Kbuild |1 +
 include/uapi/linux/cec.h  |  332 +
 7 files changed, 1839 insertions(+)
 create mode 100644 Documentation/cec.txt
 create mode 100644 drivers/media/cec.c
 create mode 100644 include/media/cec.h
 create mode 100644 include/uapi/linux/cec.h

diff --git a/Documentation/cec.txt b/Documentation/cec.txt
new file mode 100644
index 000..a52017c2
--- /dev/null
+++ b/Documentation/cec.txt
@@ -0,0 +1,165 @@
+CEC Kernel Support
+==
+
+The CEC framework provides a unified kernel interface for use with HDMI CEC
+hardware. It is designed to handle a multiple variants of hardware. Adding to
+the flexibility of the framework it enables to set which parts of the CEC
+protocol processing is handled by the hardware, by the driver and by the
+userspace application.
+
+
+The CEC Protocol
+
+
+The CEC protocol enables consumer electronic devices to communicate with each
+other through the HDMI connection. The protocol uses logical addresses in the
+communication. The logical address is strictly connected with the functionality
+provided by the device. The TV acting as the communication hub is always
+assigned address 0. The physical address is determined by the physical
+connection between devices.
+
+The protocol enables control of compatible devices with a single remote.
+Synchronous power on/standby, instant playback with changing the content source
+on the TV.
+
+The Kernel Interface
+
+
+CEC Adapter
+---
+
+#define CEC_LOG_ADDR_INVALID 0xff
+
+/* The maximum number of logical addresses one device can be assigned to.
+ * The CEC 2.0 spec allows for only 2 logical addresses at the moment. The
+ * Analog Devices CEC hardware supports 3. So let's go wild and go for 4. */
+#define CEC_MAX_LOG_ADDRS 4
+
+/* The Primary Device Type */
+#define CEC_PRIM_DEVTYPE_TV0
+#define CEC_PRIM_DEVTYPE_RECORD1
+#define CEC_PRIM_DEVTYPE_TUNER 3
+#define CEC_PRIM_DEVTYPE_PLAYBACK  4
+#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM   5
+#define CEC_PRIM_DEVTYPE_SWITCH6
+#define CEC_PRIM_DEVTYPE_VIDEOPROC 7
+
+/* The All Device Types flags (CEC 2.0) */
+#define CEC_FL_ALL_DEVTYPE_TV  (1  7)
+#define CEC_FL_ALL_DEVTYPE_RECORD  (1  6)
+#define CEC_FL_ALL_DEVTYPE_TUNER   (1  5)
+#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1  4)
+#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1  3)
+#define CEC_FL_ALL_DEVTYPE_SWITCH  (1  2)
+/* And if you wondering what happened to VIDEOPROC devices: those should
+ * be mapped to a SWITCH. */
+
+/* The logical address types that the CEC device wants to claim */
+#define CEC_LOG_ADDR_TYPE_TV   0
+#define CEC_LOG_ADDR_TYPE_RECORD   1
+#define CEC_LOG_ADDR_TYPE_TUNER2
+#define CEC_LOG_ADDR_TYPE_PLAYBACK 3
+#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM  4
+#define CEC_LOG_ADDR_TYPE_SPECIFIC 5
+#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6
+/* Switches should use UNREGISTERED.
+ * Video processors should use SPECIFIC. */
+
+/* The CEC version */
+#define CEC_VERSION_1_4B   5
+#define CEC_VERSION_2_06
+
+struct cec_adapter {
+   /* internal fields removed */
+
+   u16 phys_addr;
+   u32 capabilities;
+   u8 version;
+   u8 num_log_addrs;
+   u8 prim_device[CEC_MAX_LOG_ADDRS];
+   u8 log_addr_type[CEC_MAX_LOG_ADDRS];
+   u8 

[PATCH v6 08/11] v4l2-subdev: add HDMI CEC ops

[Kamil Debski]

From: Hans Verkuil hansv...@cisco.com

Add callbacks to the v4l2_subdev_video_ops.

Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 include/media/v4l2-subdev.h |8 
 1 file changed, 8 insertions(+)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 2f0a345..9323e10 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -40,6 +40,9 @@
 #define V4L2_SUBDEV_IR_TX_NOTIFY   _IOW('v', 1, u32)
 #define V4L2_SUBDEV_IR_TX_FIFO_SERVICE_REQ 0x0001
 
+#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 2, u32)
+#define V4L2_SUBDEV_CEC_RX_MSG _IOW('v', 3, struct cec_msg)
+
 struct v4l2_device;
 struct v4l2_ctrl_handler;
 struct v4l2_event_subscription;
@@ -48,6 +51,7 @@ struct v4l2_subdev;
 struct v4l2_subdev_fh;
 struct tuner_setup;
 struct v4l2_mbus_frame_desc;
+struct cec_msg;
 
 /* decode_vbi_line */
 struct v4l2_decode_vbi_line {
@@ -352,6 +356,10 @@ struct v4l2_subdev_video_ops {
 const struct v4l2_mbus_config *cfg);
int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
   unsigned int *size);
+   int (*cec_enable)(struct v4l2_subdev *sd, bool enable);
+   int (*cec_log_addr)(struct v4l2_subdev *sd, u8 logical_addr);
+   int (*cec_transmit)(struct v4l2_subdev *sd, struct cec_msg *msg);
+   void (*cec_transmit_timed_out)(struct v4l2_subdev *sd);
 };
 
 /*
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 07/11] DocBook/media: add CEC documentation

[Kamil Debski]

From: Hans Verkuil hverk...@xs4all.nl

Add DocBook documentation for the CEC API.

Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: add documentation for passthrough mode]
[k.deb...@samsung.com: minor fixes and change of reserved field sizes]
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 Documentation/DocBook/media/Makefile   |4 +-
 Documentation/DocBook/media/v4l/biblio.xml |   10 +
 Documentation/DocBook/media/v4l/cec-api.xml|   74 ++
 Documentation/DocBook/media/v4l/cec-func-close.xml |   59 +
 Documentation/DocBook/media/v4l/cec-func-ioctl.xml |   73 ++
 Documentation/DocBook/media/v4l/cec-func-open.xml  |   94 +++
 Documentation/DocBook/media/v4l/cec-func-poll.xml  |   89 +++
 .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml |  275 
 .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml |   78 ++
 .../DocBook/media/v4l/cec-ioc-g-adap-state.xml |   87 +++
 Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml |  173 
 .../DocBook/media/v4l/cec-ioc-g-event.xml  |  125 +
 .../DocBook/media/v4l/cec-ioc-g-passthrough.xml|   88 +++
 .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml  |   70 +
 .../DocBook/media/v4l/cec-ioc-receive.xml  |  185 +
 Documentation/DocBook/media_api.tmpl   |6 +-
 16 files changed, 1487 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/cec-api.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-close.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-ioctl.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-open.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-poll.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-state.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-event.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-passthrough.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-vendor-id.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml

diff --git a/Documentation/DocBook/media/Makefile 
b/Documentation/DocBook/media/Makefile
index 8bf7c61..9650332 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -64,6 +64,7 @@ IOCTLS = \
$(shell perl -ne 'print $$1  if /\#define\s+([A-Z][^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print $$1  if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print $$1  if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/media.h) \
+   $(shell perl -ne 'print $$1  if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/cec.h) \
$(shell perl -ne 'print $$1  if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/v4l2-subdev.h) \
VIDIOC_SUBDEV_G_FRAME_INTERVAL \
VIDIOC_SUBDEV_S_FRAME_INTERVAL \
@@ -98,6 +99,7 @@ STRUCTS = \
$(shell perl -ne 'print $$1  if (/^struct\s+([A-Z][^\s]+)\s+/)' 
$(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print $$1  if (/^struct\s+([^\s]+)\s+/)' 
$(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print $$1  if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/media.h) \
+   $(shell perl -ne 'print $$1  if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/cec.h) \
$(shell perl -ne 'print $$1  if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/v4l2-subdev.h) \
$(shell perl -ne 'print $$1  if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/v4l2-mediabus.h)
 
@@ -300,7 +302,7 @@ $(MEDIA_OBJ_DIR)/media-entities.tmpl: 
$(MEDIA_OBJ_DIR)/v4l2.xml
@(  \
for ident in $(IOCTLS) ; do \
  entity=`echo $$ident | tr _ -` ;  \
- id=`grep refname$$ident $(MEDIA_OBJ_DIR)/vidioc-*.xml 
$(MEDIA_OBJ_DIR)/media-ioc-*.xml | sed -r s,^.*/(.*).xml.*,\1,` ; \
+ id=`grep refname$$ident $(MEDIA_OBJ_DIR)/vidioc-*.xml 
$(MEDIA_OBJ_DIR)/media-ioc-*.xml $(MEDIA_OBJ_DIR)/cec-ioc-*.xml | sed -r 
s,^.*/(.*).xml.*,\1,` ; \
  echo !ENTITY $$entity \link  \
linkend='$$id'constant$$ident/constant/link\ \
  $@ ;\
diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
b/Documentation/DocBook/media/v4l/biblio.xml
index fdee6b3..bed940b 100644
--- a/Documentation/DocBook/media/v4l/biblio.xml
+++ 

[PATCH v6 09/11] cec: adv7604: add cec support.

[Kamil Debski]

From: Hans Verkuil hansv...@cisco.com

Add CEC support to the adv7604 driver.

Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]
[k.deb...@samsung.com: add missing methods cec/io_write_and_or]
[k.deb...@samsung.com: change adv7604 to adv76xx in added functions]
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 drivers/media/i2c/adv7604.c |  207 ++-
 1 file changed, 206 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 60ffcf0..4921276 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -38,6 +38,7 @@
 #include linux/workqueue.h
 
 #include media/adv7604.h
+#include media/cec.h
 #include media/v4l2-ctrls.h
 #include media/v4l2-device.h
 #include media/v4l2-dv-timings.h
@@ -77,6 +78,8 @@ MODULE_LICENSE(GPL);
 
 #define ADV76XX_OP_SWAP_CB_CR  (1  0)
 
+#define ADV76XX_MAX_ADDRS (3)
+
 enum adv76xx_type {
ADV7604,
ADV7611,
@@ -159,6 +162,10 @@ struct adv76xx_state {
u16 spa_port_a[2];
struct v4l2_fract aspect_ratio;
u32 rgb_quantization_range;
+   u8   cec_addr[ADV76XX_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
struct workqueue_struct *work_queues;
struct delayed_work delayed_work_enable_hotplug;
bool restart_stdi_once;
@@ -424,7 +431,15 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg, 
u8 val)
return adv_smbus_write_byte_data(state, ADV76XX_PAGE_IO, reg, val);
 }
 
-static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 
val)
+static inline int io_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask,
+ u8 val)
+{
+   return io_write(sd, reg, (io_read(sd, reg)  mask) | val);
+}
+
+
+static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+  u8 val)
 {
return io_write(sd, reg, (io_read(sd, reg)  ~mask) | val);
 }
@@ -457,6 +472,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 
reg, u8 val)
return adv_smbus_write_byte_data(state, ADV76XX_PAGE_CEC, reg, val);
 }
 
+static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask,
+  u8 val)
+{
+   return cec_write(sd, reg, (cec_read(sd, reg)  mask) | val);
+}
+
 static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
 {
struct adv76xx_state *state = to_state(sd);
@@ -1865,6 +1886,183 @@ static int adv76xx_set_format(struct v4l2_subdev *sd,
return 0;
 }
 
+static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status)
+{
+   if ((cec_read(sd, 0x11)  0x01) == 0) {
+   v4l2_dbg(1, debug, sd, %s: tx raw: tx disabled\n, __func__);
+   return;
+   }
+
+   if (tx_raw_status  0x02) {
+   v4l2_dbg(1, debug, sd, %s: tx raw: arbitration lost\n,
+__func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+  (void *)CEC_TX_STATUS_ARB_LOST);
+   return;
+   }
+   if (tx_raw_status  0x04) {
+   v4l2_dbg(1, debug, sd, %s: tx raw: retry failed\n, __func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+  (void *)CEC_TX_STATUS_RETRY_TIMEOUT);
+   return;
+   }
+   if (tx_raw_status  0x01) {
+   v4l2_dbg(1, debug, sd, %s: tx raw: ready ok\n, __func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+  (void *)CEC_TX_STATUS_OK);
+   return;
+   }
+}
+
+static void adv76xx_cec_isr(struct v4l2_subdev *sd, bool *handled)
+{
+   struct cec_msg msg;
+   u8 cec_irq;
+
+   /* cec controller */
+   cec_irq = io_read(sd, 0x4d)  0x0f;
+   if (!cec_irq)
+   return;
+
+   v4l2_dbg(1, debug, sd, %s: cec: irq 0x%x\n, __func__, cec_irq);
+   adv76xx_cec_tx_raw_status(sd, cec_irq);
+   if (cec_irq  0x08) {
+   msg.len = cec_read(sd, 0x25)  0x1f;
+   if (msg.len  16)
+   msg.len = 16;
+
+   if (msg.len) {
+   u8 i;
+
+   for (i = 0; i  msg.len; i++)
+   msg.msg[i] = cec_read(sd, i + 0x15);
+   cec_write(sd, 0x26, 0x01); /* re-enable rx */
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_RX_MSG, msg);
+   }
+   }
+
+   /* note: the bit order is swapped between 0x4d and 0x4e */
+   cec_irq = ((cec_irq  0x08)  3) | ((cec_irq  0x04)  1) |
+ ((cec_irq  0x02)  1) | ((cec_irq  0x01)  3);
+   io_write(sd, 0x4e, cec_irq);
+
+   if (handled)
+   *handled = true;
+}
+
+static int 

RE: [PATCH v6 00/11] HDMI CEC framework

[Kamil Debski]

Hi,

Sorry, I missed the subject for this cover-letter. Added it in this reply.

Best wishes,
-- 
Kamil Debski
Samsung RD Institute Poland


 -Original Message-
 From: Kamil Debski [mailto:k.deb...@samsung.com]
 Sent: Monday, May 04, 2015 7:33 PM
 To: dri-de...@lists.freedesktop.org; linux-media@vger.kernel.org
 Cc: m.szyprow...@samsung.com; k.deb...@samsung.com;
 mche...@osg.samsung.com; hverk...@xs4all.nl; kyungmin.p...@samsung.com;
 tho...@tommie-lie.de; s...@mess.org; dmitry.torok...@gmail.com; linux-
 in...@vger.kernel.org; linux-samsung-...@vger.kernel.org;
 l...@opdenkamp.eu
 Subject: [PATCH v6 00/11]
 
 Hi,
 
 The sixth version of this patchset addresses recent comments on the
 mailing list. Please see the changelog below for details.
 
 Best wishes,
 Kamil Debski
 
 Changes since v5
 
 - drop struct cec_timeval in favour of a __u64 that keeps the timestamp
 in ns
 - remove userspace documentation from Documentation/cec.txt as
 userspace API
   is described in the DocBook
 - add missing documentation for the passthrough mode to the DocBook
 - add information about the number of events that can be queued
 - fix misspelling of reply
 - fix behaviour of posting an event in cec_received_msg, such that the
 behaviour
   is consistent with the documentation
 
 Changes since v4
 
 - add sequence numbering to transmitted messages
 - add sequence number handling to event hanlding
 - add passthrough mode
 - change reserved field sizes
 - fixed CEC version defines and addec CEC 2.0 commands
 - add DocBook documentation
 
 Changes since v3
 
 - remove the promiscuous mode
 - rewrite the devicetree patches
 - fixes, expansion and partial rewrite of the documentation
 - reorder of API structures and addition of reserved fields
 - use own struct to report time (32/64 bit safe)
 - fix of handling events
 - add cec.h to include/uapi/linux/Kbuild
 - fixes in the adv76xx driver (add missing methods, change adv7604 to
 adv76xx)
 - cleanup of debug messages in s5p-cec driver
 - remove non necessary claiming of a gpio in the s5p-cec driver
 - cleanup headers of the s5p-cec driver
 
 Changes since v2
 ===-
 - added promiscuous mode
 - added new key codes to the input framework
 - add vendor ID reporting
 - add the possibility to clear assigned logical addresses
 - cleanup of the rc cec map
 
 Changes since v1
 
 - documentation edited and moved to the Documentation folder
 - added key up/down message handling
 - add missing CEC commands to the cec.h file
 
 Background
 ==
 
 The work on a common CEC framework was started over three years ago by
 Hans Verkuil. Unfortunately the work has stalled. As I have received
 the task of creating a driver for the CEC interface module present on
 the Exynos range of SoCs, I got in touch with Hans. He replied that the
 work stalled due to his lack of time.
 
 Original RFC by Hans Verkuil/Martin Bugge
 =
 https://www.mail-archive.com/linux-media@vger.kernel.org/msg28735.html
 
 
 Hans Verkuil (5):
   cec: add HDMI CEC framework
   DocBook/media: add CEC documentation
   v4l2-subdev: add HDMI CEC ops
   cec: adv7604: add cec support.
   cec: adv7511: add cec support.
 
 Kamil Debski (6):
   dts: exynos4*: add HDMI CEC pin definition to pinctrl
   dts: exynos4: add node for the HDMI CEC device
   dts: exynos4412-odroid*: enable the HDMI CEC device
   HID: add HDMI CEC specific keycodes
   rc: Add HDMI CEC protoctol handling
   cec: s5p-cec: Add s5p-cec driver
 
  Documentation/DocBook/media/Makefile   |4 +-
  Documentation/DocBook/media/v4l/biblio.xml |   10 +
  Documentation/DocBook/media/v4l/cec-api.xml|   74 ++
  Documentation/DocBook/media/v4l/cec-func-close.xml |   59 +
  Documentation/DocBook/media/v4l/cec-func-ioctl.xml |   73 ++
  Documentation/DocBook/media/v4l/cec-func-open.xml  |   94 ++
  Documentation/DocBook/media/v4l/cec-func-poll.xml  |   89 ++
  .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml |  275 +
  .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml |   78 ++
  .../DocBook/media/v4l/cec-ioc-g-adap-state.xml |   87 ++
  Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml |  173 +++
  .../DocBook/media/v4l/cec-ioc-g-event.xml  |  125 ++
  .../DocBook/media/v4l/cec-ioc-g-passthrough.xml|   88 ++
  .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml  |   70 ++
  .../DocBook/media/v4l/cec-ioc-receive.xml  |  185 +++
  Documentation/DocBook/media_api.tmpl   |6 +-
  Documentation/cec.txt  |  165 +++
  .../devicetree/bindings/media/s5p-cec.txt  |   33 +
  arch/arm/boot/dts/exynos4.dtsi |   12 +
  arch/arm/boot/dts/exynos4210-pinctrl.dtsi  |7 +
  arch/arm/boot/dts/exynos4412-odroid-common.dtsi|4 +
  arch/arm/boot/dts/exynos4x12-pinctrl.dtsi  |7 +
  drivers/media/Kconfig

[PATCH v6 11/11] cec: s5p-cec: Add s5p-cec driver

[Kamil Debski]

Add CEC interface driver present in the Samsung Exynos range of
SoCs.

The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c

Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 .../devicetree/bindings/media/s5p-cec.txt  |   33 +++
 drivers/media/platform/Kconfig |   10 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/s5p-cec/Makefile|4 +
 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h   |   37 +++
 .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c   |  208 ++
 drivers/media/platform/s5p-cec/regs-cec.h  |   96 +++
 drivers/media/platform/s5p-cec/s5p_cec.c   |  283 
 drivers/media/platform/s5p-cec/s5p_cec.h   |   76 ++
 9 files changed, 748 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt
 create mode 100644 drivers/media/platform/s5p-cec/Makefile
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
 create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h

diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
b/Documentation/devicetree/bindings/media/s5p-cec.txt
new file mode 100644
index 000..97ca664
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -0,0 +1,33 @@
+* Samsung HDMI CEC driver
+
+The HDMI CEC module is present is Samsung SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be follwoing
+   samsung,s5p-cec
+
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+  - interrupts : HDMI CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to HDMI CEC clock.
+  - clock-names : from common clock binding: must contain hdmicec,
+ corresponding to entry in the clocks property.
+  - samsung,syscon-phandle - phandle to the PMU system controller
+
+Example:
+
+hdmicec: cec@100B {
+   compatible = samsung,s5p-cec;
+   reg = 0x100B 0x200;
+   interrupts = 0 114 0;
+   clocks = clock CLK_HDMI_CEC;
+   clock-names = hdmicec;
+   samsung,syscon-phandle = pmu_system_controller;
+   pinctrl-names = default;
+   pinctrl-0 = hdmi_cec;
+   status = okay;
+};
+
+
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 421f531..203bc06 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -157,6 +157,16 @@ config VIDEO_MEM2MEM_DEINTERLACE
help
Generic deinterlacing V4L2 driver.
 
+config VIDEO_SAMSUNG_S5P_CEC
+   tristate Samsung S5P CEC driver
+   depends on CEC  VIDEO_DEV  VIDEO_V4L2  (PLAT_S5P || ARCH_EXYNOS)
+   default n
+   ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 config VIDEO_SAMSUNG_S5P_G2D
tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver
depends on VIDEO_DEV  VIDEO_V4L2
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 8f85561..f96c9a3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)   += 
m2m-deinterlace.o
 
 obj-$(CONFIG_VIDEO_S3C_CAMIF)  += s3c-camif/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)   += s5p-jpeg/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/
diff --git a/drivers/media/platform/s5p-cec/Makefile 
b/drivers/media/platform/s5p-cec/Makefile
new file mode 100644
index 000..7f84226
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/Makefile
@@ -0,0 +1,4 @@
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec.o
+s5p-cec-y += s5p_cec.o exynos_hdmi_cecctrl.o
+
+
diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h 
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
new file mode 100644
index 000..d008695
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
@@ -0,0 +1,37 @@
+/* drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
+ *
+ * Copyright (c) 2010, 2014 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * Header file for interface of Samsung Exynos hdmi cec hardware
+ *
+ * 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
+ 

[PATCH v6 10/11] cec: adv7511: add cec support.

[Kamil Debski]

From: Hans Verkuil hansv...@cisco.com

Add CEC support to the adv7511 driver.

Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 drivers/media/i2c/adv7511.c |  347 ++-
 include/media/adv7511.h |6 +-
 2 files changed, 343 insertions(+), 10 deletions(-)

diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 12d9320..d56e110 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -33,6 +33,7 @@
 #include media/v4l2-ctrls.h
 #include media/v4l2-dv-timings.h
 #include media/adv7511.h
+#include media/cec.h
 
 static int debug;
 module_param(debug, int, 0644);
@@ -91,6 +92,12 @@ struct adv7511_state {
int chip_revision;
uint8_t i2c_edid_addr;
uint8_t i2c_cec_addr;
+
+   struct i2c_client *i2c_cec;
+   u8   cec_addr[3];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
/* Is the adv7511 powered on? */
bool power_on;
/* Did we receive hotplug and rx-sense signals? */
@@ -222,7 +229,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client 
*client,
return ret;
 }
 
-static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, 
uint8_t *buf)
+static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf)
 {
struct adv7511_state *state = get_adv7511_state(sd);
int i;
@@ -237,6 +244,34 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, 
uint16_t len, uint8_t
v4l2_err(sd, %s: i2c read error\n, __func__);
 }
 
+static inline int cec_read(struct v4l2_subdev *sd, u8 reg)
+{
+   struct adv7511_state *state = get_adv7511_state(sd);
+
+   return i2c_smbus_read_byte_data(state-i2c_cec, reg);
+}
+
+static int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+   struct adv7511_state *state = get_adv7511_state(sd);
+   int ret;
+   int i;
+
+   for (i = 0; i  3; i++) {
+   ret = i2c_smbus_write_byte_data(state-i2c_cec, reg, val);
+   if (ret == 0)
+   return 0;
+   }
+   v4l2_err(sd, %s: I2C Write Problem\n, __func__);
+   return ret;
+}
+
+static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask,
+  u8 val)
+{
+   return cec_write(sd, reg, (cec_read(sd, reg)  mask) | val);
+}
+
 static inline bool adv7511_have_hotplug(struct v4l2_subdev *sd)
 {
return adv7511_rd(sd, 0x42)  MASK_ADV7511_HPD_DETECT;
@@ -381,16 +416,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = {
 #ifdef CONFIG_VIDEO_ADV_DEBUG
 static void adv7511_inv_register(struct v4l2_subdev *sd)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
v4l2_info(sd, 0x000-0x0ff: Main Map\n);
+   if (state-i2c_cec)
+   v4l2_info(sd, 0x100-0x1ff: CEC Map\n);
 }
 
 static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register 
*reg)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
reg-size = 1;
switch (reg-reg  8) {
case 0:
reg-val = adv7511_rd(sd, reg-reg  0xff);
break;
+   case 1:
+   if (state-i2c_cec) {
+   reg-val = cec_read(sd, reg-reg  0xff);
+   break;
+   }
+   /* fall through */
default:
v4l2_info(sd, Register %03llx not supported\n, reg-reg);
adv7511_inv_register(sd);
@@ -401,10 +448,18 @@ static int adv7511_g_register(struct v4l2_subdev *sd, 
struct v4l2_dbg_register *
 
 static int adv7511_s_register(struct v4l2_subdev *sd, const struct 
v4l2_dbg_register *reg)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
switch (reg-reg  8) {
case 0:
adv7511_wr(sd, reg-reg  0xff, reg-val  0xff);
break;
+   case 1:
+   if (state-i2c_cec) {
+   cec_write(sd, reg-reg  0xff, reg-val  0xff);
+   break;
+   }
+   /* fall through */
default:
v4l2_info(sd, Register %03llx not supported\n, reg-reg);
adv7511_inv_register(sd);
@@ -418,6 +473,7 @@ static int adv7511_log_status(struct v4l2_subdev *sd)
 {
struct adv7511_state *state = get_adv7511_state(sd);
struct adv7511_state_edid *edid = state-edid;
+   int i;
 
static const char * const states[] = {
in reset,
@@ -486,7 +542,21 @@ static int adv7511_log_status(struct v4l2_subdev *sd)
else
v4l2_info(sd, no timings set\n);
v4l2_info(sd, i2c edid addr: 0x%x\n, state-i2c_edid_addr);
+
+   if (state-i2c_cec == NULL)
+   return 0;
+
v4l2_info(sd, i2c cec addr: 0x%x\n, state-i2c_cec_addr);
+
+   

[PATCH v2] libgencec: Add userspace library for the generic CEC kernel interface

[Kamil Debski]

This is the first version of the libGenCEC library. It was designed to
act as an interface between the generic CEC kernel API and userspace
applications. It provides a simple interface for applications and an
example application that can be used to test the CEC functionality.

signed-off-by: Kamil Debski k.deb...@samsung.com
---
 AUTHORS  |1 +
 INSTALL  |9 +
 LICENSE  |  202 
 Makefile.am  |4 +
 README   |   22 ++
 configure.ac |   24 ++
 doc/index.html   |  345 +++
 examples/Makefile.am |4 +
 examples/cectest.c   |  631 ++
 include/gencec.h |  255 
 libgencec.pc.in  |   10 +
 src/Makefile.am  |4 +
 src/gencec.c |  445 +++
 13 files changed, 1956 insertions(+)
 create mode 100644 AUTHORS
 create mode 100644 INSTALL
 create mode 100644 LICENSE
 create mode 100644 Makefile.am
 create mode 100644 README
 create mode 100644 configure.ac
 create mode 100644 doc/index.html
 create mode 100644 examples/Makefile.am
 create mode 100644 examples/cectest.c
 create mode 100644 include/gencec.h
 create mode 100644 libgencec.pc.in
 create mode 100644 src/Makefile.am
 create mode 100644 src/gencec.c

diff --git a/AUTHORS b/AUTHORS
new file mode 100644
index 000..e4b7117
--- /dev/null
+++ b/AUTHORS
@@ -0,0 +1 @@
+Kamil Debski k.deb...@samsung.com
diff --git a/INSTALL b/INSTALL
new file mode 100644
index 000..aac6101
--- /dev/null
+++ b/INSTALL
@@ -0,0 +1,9 @@
+To install libgencec run following commands:
+
+autoreconf -i
+./configure
+make
+make install
+
+A cross compilation example for ARM:
+CFLAGS=-Ikernel headers ./configure --host=arm-linux-gnueabi 
--prefix=installation prefix
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 000..d645695
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,202 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  License shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  Licensor shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  Legal Entity shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  control means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  You (or Your) shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  Source form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  Object form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  Work shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  Derivative Works shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  Contribution shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, submitted
+  means any form of electronic, verbal, or written communication sent
+  to the Licensor or its representatives, including but not limited to
+  communication on electronic mailing lists, source code 

Re: [PATCH v7] leds: Add support for max77693 mfd flash cell

[Bryan Wu]

On Thu, Apr 30, 2015 at 3:35 AM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
 This patch adds led-flash support to Maxim max77693 chipset.
 A device can be exposed to user space through LED subsystem
 sysfs interface. Device supports up to two leds which can
 work in flash and torch mode. The leds can be triggered
 externally or by software.

 Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Bryan Wu coolo...@gmail.com
 Cc: Richard Purdie rpur...@rpsys.net

Reapplied. thanks.
-Bryan

 ---
 Fixed issues reported by 0-DAY kernel test infrastructure:

 - drivers/leds/leds-max77693.c:978:3-8: No need to set .owner here. The core 
 will do it.
 * removed the line
 - drivers/leds/leds-max77693.c:193 max77693_add_mode() warn: maybe use  
 instead of 
 * redesigned max77693_add_mode function


  drivers/leds/Kconfig |   10 +
  drivers/leds/Makefile|1 +
  drivers/leds/leds-max77693.c |  980 
 ++
  3 files changed, 991 insertions(+)
  create mode 100644 drivers/leds/leds-max77693.c

 diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
 index a38b17a..62be033 100644
 --- a/drivers/leds/Kconfig
 +++ b/drivers/leds/Kconfig
 @@ -475,6 +475,16 @@ config LEDS_TLC591XX
   This option enables support for Texas Instruments TLC59108
   and TLC59116 LED controllers.

 +config LEDS_MAX77693
 +   tristate LED support for MAX77693 Flash
 +   depends on LEDS_CLASS_FLASH
 +   depends on MFD_MAX77693
 +   depends on OF
 +   help
 + This option enables support for the flash part of the MAX77693
 + multifunction device. It has build in control for two leds in flash
 + and torch mode.
 +
  config LEDS_MAX8997
 tristate LED support for MAX8997 PMIC
 depends on LEDS_CLASS  MFD_MAX8997
 diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
 index 749dbe3..8bddae6 100644
 --- a/drivers/leds/Makefile
 +++ b/drivers/leds/Makefile
 @@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_MC13783)+= leds-mc13783.o
  obj-$(CONFIG_LEDS_NS2) += leds-ns2.o
  obj-$(CONFIG_LEDS_NETXBIG) += leds-netxbig.o
  obj-$(CONFIG_LEDS_ASIC3)   += leds-asic3.o
 +obj-$(CONFIG_LEDS_MAX77693)+= leds-max77693.o
  obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
  obj-$(CONFIG_LEDS_LM355x)  += leds-lm355x.o
  obj-$(CONFIG_LEDS_BLINKM)  += leds-blinkm.o
 diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
 new file mode 100644
 index 000..eecaa92
 --- /dev/null
 +++ b/drivers/leds/leds-max77693.c
 @@ -0,0 +1,980 @@
 +/*
 + * LED Flash class driver for the flash cell of max77693 mfd.
 + *
 + * Copyright (C) 2015, Samsung Electronics Co., Ltd.
 + *
 + * Authors: Jacek Anaszewski j.anaszew...@samsung.com
 + *  Andrzej Hajda a.ha...@samsung.com
 + *
 + * 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.
 + */
 +
 +#include linux/led-class-flash.h
 +#include linux/mfd/max77693.h
 +#include linux/mfd/max77693-private.h
 +#include linux/module.h
 +#include linux/mutex.h
 +#include linux/platform_device.h
 +#include linux/regmap.h
 +#include linux/slab.h
 +#include linux/workqueue.h
 +
 +#define MODE_OFF   0
 +#define MODE_FLASH(a)  (1  (a))
 +#define MODE_TORCH(a)  (1  (2 + (a)))
 +#define MODE_FLASH_EXTERNAL(a) (1  (4 + (a)))
 +
 +#define MODE_FLASH_MASK(MODE_FLASH(FLED1) | 
 MODE_FLASH(FLED2) | \
 +MODE_FLASH_EXTERNAL(FLED1) | \
 +MODE_FLASH_EXTERNAL(FLED2))
 +#define MODE_TORCH_MASK(MODE_TORCH(FLED1) | 
 MODE_TORCH(FLED2))
 +
 +#define FLED1_IOUT (1  0)
 +#define FLED2_IOUT (1  1)
 +
 +enum max77693_fled {
 +   FLED1,
 +   FLED2,
 +};
 +
 +enum max77693_led_mode {
 +   FLASH,
 +   TORCH,
 +};
 +
 +struct max77693_led_config_data {
 +   const char *label[2];
 +   u32 iout_torch_max[2];
 +   u32 iout_flash_max[2];
 +   u32 flash_timeout_max[2];
 +   u32 num_leds;
 +   u32 boost_mode;
 +   u32 boost_vout;
 +   u32 low_vsys;
 +};
 +
 +struct max77693_sub_led {
 +   /* corresponding FLED output identifier */
 +   int fled_id;
 +   /* corresponding LED Flash class device */
 +   struct led_classdev_flash fled_cdev;
 +   /* assures led-triggers compatibility */
 +   struct work_struct work_brightness_set;
 +
 +   /* brightness cache */
 +   unsigned int torch_brightness;
 +   /* flash timeout cache */
 +   unsigned int flash_timeout;
 +   /* flash faults that may have occurred */
 +   u32 flash_faults;
 +};
 

Re: [PATCH v7] leds: Add driver for AAT1290 flash LED controller

[Bryan Wu]

On Thu, Apr 30, 2015 at 3:34 AM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
 This patch adds a driver for the 1.5A Step-Up Current Regulator
 for Flash LEDs. The device is programmed through a Skyworks proprietary
 AS2Cwire serial digital interface.


Reapplied. Thanks,
-Bryan

 Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
 Cc: Bryan Wu coolo...@gmail.com
 Cc: Richard Purdie rpur...@rpsys.net
 ---
 Fixed issue reported by 0-DAY kernel test infrastructure:
 drivers/leds/leds-aat1290.c:443:3-8: No need to set .owner here. The core 
 will do it
 Fixed issue reported by Coccinelle:
 drivers/leds/leds-aat1290.c:204:5-10: WARNING: Comparison of bool to 0/1

  drivers/leds/Kconfig|8 +
  drivers/leds/Makefile   |1 +
  drivers/leds/leds-aat1290.c |  451 
 +++
  3 files changed, 460 insertions(+)
  create mode 100644 drivers/leds/leds-aat1290.c

 diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
 index 62be033..dd7834c 100644
 --- a/drivers/leds/Kconfig
 +++ b/drivers/leds/Kconfig
 @@ -42,6 +42,14 @@ config LEDS_88PM860X
   This option enables support for on-chip LED drivers found on Marvell
   Semiconductor 88PM8606 PMIC.

 +config LEDS_AAT1290
 +   tristate LED support for the AAT1290
 +   depends on LEDS_CLASS_FLASH
 +   depends on GPIOLIB
 +   depends on OF
 +   help
 +This option enables support for the LEDs on the AAT1290.
 +
  config LEDS_LM3530
 tristate LCD Backlight driver for LM3530
 depends on LEDS_CLASS
 diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
 index 8bddae6..71f7c9a 100644
 --- a/drivers/leds/Makefile
 +++ b/drivers/leds/Makefile
 @@ -7,6 +7,7 @@ obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o

  # LED Platform Drivers
  obj-$(CONFIG_LEDS_88PM860X)+= leds-88pm860x.o
 +obj-$(CONFIG_LEDS_AAT1290) += leds-aat1290.o
  obj-$(CONFIG_LEDS_BD2802)  += leds-bd2802.o
  obj-$(CONFIG_LEDS_LOCOMO)  += leds-locomo.o
  obj-$(CONFIG_LEDS_LM3530)  += leds-lm3530.o
 diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
 new file mode 100644
 index 000..6ea1d54
 --- /dev/null
 +++ b/drivers/leds/leds-aat1290.c
 @@ -0,0 +1,451 @@
 +/*
 + * LED Flash class driver for the AAT1290
 + * 1.5A Step-Up Current Regulator for Flash LEDs
 + *
 + * Copyright (C) 2015, Samsung Electronics Co., Ltd.
 + * Author: Jacek Anaszewski j.anaszew...@samsung.com
 + *
 + * 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.
 + */
 +
 +#include linux/delay.h
 +#include linux/gpio/consumer.h
 +#include linux/led-class-flash.h
 +#include linux/leds.h
 +#include linux/module.h
 +#include linux/mutex.h
 +#include linux/of.h
 +#include linux/platform_device.h
 +#include linux/slab.h
 +#include linux/workqueue.h
 +
 +#define AAT1290_MOVIE_MODE_CURRENT_ADDR17
 +#define AAT1290_MAX_MM_CURR_PERCENT_0  16
 +#define AAT1290_MAX_MM_CURR_PERCENT_1001
 +
 +#define AAT1290_FLASH_SAFETY_TIMER_ADDR18
 +
 +#define AAT1290_MOVIE_MODE_CONFIG_ADDR 19
 +#define AAT1290_MOVIE_MODE_OFF 1
 +#define AAT1290_MOVIE_MODE_ON  3
 +
 +#define AAT1290_MM_CURRENT_RATIO_ADDR  20
 +#define AAT1290_MM_TO_FL_1_92  1
 +
 +#define AAT1290_MM_TO_FL_RATIO 1000 / 1920
 +#define AAT1290_MAX_MM_CURRENT(fl_max) (fl_max * AAT1290_MM_TO_FL_RATIO)
 +
 +#define AAT1290_LATCH_TIME_MIN_US  500
 +#define AAT1290_LATCH_TIME_MAX_US  1000
 +#define AAT1290_EN_SET_TICK_TIME_US1
 +#define AAT1290_FLEN_OFF_DELAY_TIME_US 10
 +#define AAT1290_FLASH_TM_NUM_LEVELS16
 +#define AAT1290_MM_CURRENT_SCALE_SIZE  15
 +
 +
 +struct aat1290_led_config_data {
 +   /* maximum LED current in movie mode */
 +   u32 max_mm_current;
 +   /* maximum LED current in flash mode */
 +   u32 max_flash_current;
 +   /* maximum flash timeout */
 +   u32 max_flash_tm;
 +   /* max LED brightness level */
 +   enum led_brightness max_brightness;
 +};
 +
 +struct aat1290_led {
 +   /* platform device data */
 +   struct platform_device *pdev;
 +   /* secures access to the device */
 +   struct mutex lock;
 +
 +   /* corresponding LED Flash class device */
 +   struct led_classdev_flash fled_cdev;
 +
 +   /* FLEN pin */
 +   struct gpio_desc *gpio_fl_en;
 +   /* EN|SET pin  */
 +   struct gpio_desc *gpio_en_set;
 +   /* movie mode current scale */
 +   int *mm_current_scale;
 +   /* device mode */
 +   bool movie_mode;
 +
 +   /* brightness cache */
 +   unsigned int torch_brightness;
 +   /* assures led-triggers compatibility */
 +   struct work_struct 

Re: [PATCH v7] Documentation: leds: Add description of v4l2-flash sub-device

[Bryan Wu]

On Thu, Apr 30, 2015 at 3:34 AM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
 This patch extends LED Flash class documention by
 the description of interactions with v4l2-flash sub-device.


Thanks, applied
-Bryan

 Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
 Cc: Bryan Wu coolo...@gmail.com
 Cc: Richard Purdie rpur...@rpsys.net
 ---
  Documentation/leds/leds-class-flash.txt |   47 
 +++
  1 file changed, 47 insertions(+)

 diff --git a/Documentation/leds/leds-class-flash.txt 
 b/Documentation/leds/leds-class-flash.txt
 index 19bb673..4cedc58 100644
 --- a/Documentation/leds/leds-class-flash.txt
 +++ b/Documentation/leds/leds-class-flash.txt
 @@ -20,3 +20,50 @@ Following sysfs attributes are exposed for controlling 
 flash LED devices:
 - max_flash_timeout
 - flash_strobe
 - flash_fault
 +
 +
 +V4L2 flash wrapper for flash LEDs
 +=
 +
 +A LED subsystem driver can be controlled also from the level of 
 VideoForLinux2
 +subsystem. In order to enable this CONFIG_V4L2_FLASH_LED_CLASS symbol has to
 +be defined in the kernel config.
 +
 +The driver must call the v4l2_flash_init function to get registered in the
 +V4L2 subsystem. The function takes three arguments:
 +- fled_cdev : the LED Flash class device to wrap
 +- ops : V4L2 specific ops
 +   * external_strobe_set - defines the source of the flash LED strobe -
 +   V4L2_CID_FLASH_STROBE control or external source, typically
 +   a sensor, which makes it possible to synchronise the flash
 +   strobe start with exposure start,
 +   * intensity_to_led_brightness and led_brightness_to_intensity - 
 perform
 +   enum led_brightness - V4L2 intensity conversion in a device
 +   specific manner - they can be used for devices with non-linear
 +   LED current scale.
 +- config : configuration for V4L2 Flash sub-device
 +   * dev_name - the name of the media entity, unique in the system,
 +   * flash_faults - bitmask of flash faults that the LED Flash class
 +   device can report; corresponding LED_FAULT* bit definitions 
 are
 +   available in linux/led-class-flash.h,
 +   * intensity - constraints for the LED in the TORCH or INDICATOR mode,
 +   in microamperes,
 +   * has_external_strobe - determines whether the flash strobe source
 +   can be switched to external,
 +   * indicator_led - signifies that a led is of indicator type, which
 +   implies that it can have only two V4L2 controls:
 +   V4L2_CID_FLASH_INDICATOR_INTENSITY and V4L2_CID_FLASH_FAULT.
 +
 +On remove the v4l2_flash_release function has to be called, which takes one
 +argument - struct v4l2_flash pointer returned previously by v4l2_flash_init.
 +
 +Please refer to drivers/leds/leds-max77693.c for an exemplary usage of the
 +v4l2 flash wrapper.
 +
 +Once the V4L2 sub-device is registered by the driver which created the Media
 +controller device, the sub-device node acts just as a node of a native V4L2
 +flash API device would. The calls are simply routed to the LED flash API.
 +
 +Opening the V4L2 flash sub-device makes the LED subsystem sysfs interface
 +unavailable. The interface is re-enabled after the V4L2 flash sub-device
 +is closed.
 --
 1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 01/11] dts: exynos4*: add HDMI CEC pin definition to pinctrl

[Krzysztof Kozłowski]

2015-05-05 2:32 GMT+09:00 Kamil Debski k.deb...@samsung.com:
 Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
 Exynos4x12 SoCs. These are required by the HDMI CEC device.

 Signed-off-by: Kamil Debski k.deb...@samsung.com

Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com

Are there any objections to picking the DTS changes independently?

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 02/11] dts: exynos4: add node for the HDMI CEC device

[Krzysztof Kozłowski]

2015-05-05 2:32 GMT+09:00 Kamil Debski k.deb...@samsung.com:
 This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series.

 Signed-off-by: Kamil Debski k.deb...@samsung.com

Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 03/11] dts: exynos4412-odroid*: enable the HDMI CEC device

[Krzysztof Kozłowski]

2015-05-05 2:32 GMT+09:00 Kamil Debski k.deb...@samsung.com:
 Add a dts node entry and enable the HDMI CEC device present in the Exynos4
 family of SoCs.

 Signed-off-by: Kamil Debski k.deb...@samsung.com

Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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:   Tue May  5 04:00:15 CEST 2015
git branch: test
git hash:   1555f3bf5cc172e7d23c2b8db10d656d15bec13e
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0-44-g40791b9
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:4.0.0-0.slh.3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: WARNINGS
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: ERRORS
linux-git-arm-omap1: OK
linux-git-arm-pxa: 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.32.27-i686: OK
linux-2.6.33.7-i686: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0-i686: WARNINGS
linux-4.1-rc1-i686: WARNINGS
linux-2.6.32.27-x86_64: OK
linux-2.6.33.7-x86_64: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: WARNINGS
linux-4.1-rc1-x86_64: WARNINGS
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html