cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Sat Apr 22 05:00:20 CEST 2017
media-tree git hash:9eb9db3a0f92b75ec710066202e0b2accb45afa9
media_build git hash:   1af19680bde3e227d64d99ff5fdc43eb343a3b28
v4l-utils git hash: b514d615166bdc0901a4c71261b87db31e89f464
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: 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.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: 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: WARNINGS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
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.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: 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: WARNINGS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: RFC: Power states and VIDIOC_STREAMON

[Mauro Carvalho Chehab]

Em Fri, 21 Apr 2017 14:09:37 -0400
Devin Heitmueller  escreveu:

> >> I had always interpreted it such that the STREAMON call just
> >> controlled whether the DMA engine was running, and thus you could do
> >> anything else with the decoder before calling STREAMON other than
> >> actually receiving video buffers.  
> >
> > Indeed there's an ambiguity there, although I always read that
> > the device's logic should keep accepting calls via both DVB
> > and V4L2 APIs until V4L2 streaming ioctls are issued.  
> 
> Yeah, the hybrid use case is clearly something that didn't exist back
> then.  Most of the video decoders I've worked on (e.g. tvp5150,
> saa7115) have the device running all the time and s_stream is only
> used for output control (i.e. enable/disable the ITU-656 output).

Yeah, on most devices, switching is simpler.

> > That's, btw, what happens on older drivers like cx88 and bttv.
> >
> > For example, on bttv, there's this logic:
> >
> > static int bttv_s_fmt_vid_cap(struct file *file, void *priv,
> > struct v4l2_format *f)
> > {
> > int retval;
> > const struct bttv_format *fmt;
> > struct bttv_fh *fh = priv;
> > struct bttv *btv = fh->btv;
> > __s32 width, height;
> > unsigned int width_mask, width_bias;
> > enum v4l2_field field;
> >
> > retval = bttv_switch_type(fh, f->type);
> > if (0 != retval)
> > return retval;
> >
> > The logic there actually happens earlier, at VIDIOC_S_FMT. Although I
> > guess all apps call it before streaming, the problem with the above is
> > that the V4L2 API doesn't actually make it mandatory to call this ioctl
> > before start streaming.
> >
> > I guess that the idea of doing that at STREAMON started when we
> > discussed how to lock hybrid devices via MC. I guess it was suggested
> > by Shuah, who looked on those issues and analyzed what apps used to do.  
> 
> I've got a pile of changes which involve refactoring the power
> management on the au8522, but I have never thoroughly reviewed where
> Shuah ended up with the MC changes and thus it's likely they don't
> take those into account.

We had also a couple of discussions at the media summits with
regards to use MC for hybrid devices and how this was supposed
to work, besides the ML discussions.

> >> My instinct would be to revert the patch in question since it breaks
> >> ABI behavior which has been present for over a decade, but I suspect
> >> such a patch would be rejected since it was Mauro himself who
> >> introduced the change in behavior.  
> >
> > It doesn't matter who committed a patch. If it is wrong, something
> > should be done.
> >
> > However, in the specific case of a change like that, just reverting the
> > patch right now would make it worse, as it will break the resource locks
> > between FM, analog TV and digital TV, causing regressions.
> >
> > Locking it at tuner get status is a bad place, as I guess that would
> > break locking between FM radio and analog TV, as both can read
> > tuner status.  
> 
> For what it's worth, FM radio isn't supported in the au0828/au8522
> driver, so that doesn't need to be a consideration for this particular
> driver unless you're suggesting some changes to the framework common
> to all devices.

Good to know, but as other devices also support FM, we need
to define something that would be compatible with what the other
drivers implement.

> > Maybe one solution would be to lock the resources on either
> > for VIDIOC_S_FMT, VIDIOC_STREAMON or read() (whatever comes first),
> > but we need to check if this won't break switching between analog TV
> > and FM.  
> 
> I could argue that despite the PAL-M changes you made a couple of
> years ago, the device is only ever really used with a single standard
> (NTSC), and thus it's entirely possible that the user may never call
> S_FMT given the default is to capture 720x480 YUY2 and the device is
> already in that mode at initialization. 

Well, even for PAL-M, an application could, in thesis use G_FMT and, if
the format matches, don't send a S_FMT.

I guess that, in practice, all GUI Open source apps will always send 
a S_FMT ioctl (and even non-GUI apps like mplayer).

> Also, IIRC the s_stream()
> subdev callback automatically gets invoked when you do a read(), in
> order to support both MMAP and READ modes.

Yes. That's why we don't need to bother much about read(), but we need
to test if whatever patchset gets applied  it won't break support for it.

> I could suggest that it
> should be locked when you call S_INPUT, but I'm pretty sure that's how
> I had it to begin with.  Likewise even in that case you could still
> hit the issue if the user is trying to use the default input of 0
> (i.e. plug in stick, call S_FREQ, and then poll for lock).

Nothing prevents that we hook it on multiple places. I mean, whatever
gets called first (STREAMON, S_INPUT, S_FMT, REQBUFS) 

[no subject]

[Mr.Jerry Smith]

We Give Out Loans At 3% Interest Rate And We Offer Loans From $5,000 To 
$50,000,000.00, Are You Looking To Buy A House Car Or Company Or Start Up A 
Truck Company or Buy A Truck Or Personal Loans Or Business Loan, Email Us At 
jerryfund...@inbox.lv  With Amount Needed And Phone Number.

[PATCH v5 3/3] [media] st-delta: add mpeg2 support

[Hugues Fruchet]

Adds support of DELTA MPEG-2 video decoder back-end,
implemented by calling MPEG2_TRANSFORMER0 firmware
using RPMSG IPC communication layer.
MPEG-2 decoder back-end is a stateless decoder which
require specific parsing metadata in access unit
in order to complete decoding.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/Kconfig |   11 +-
 drivers/media/platform/sti/delta/Makefile  |3 +
 drivers/media/platform/sti/delta/delta-cfg.h   |5 +
 drivers/media/platform/sti/delta/delta-mpeg2-dec.c | 1401 
 drivers/media/platform/sti/delta/delta-mpeg2-fw.h  |  423 ++
 drivers/media/platform/sti/delta/delta-v4l2.c  |4 +
 6 files changed, 1845 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/platform/sti/delta/delta-mpeg2-dec.c
 create mode 100644 drivers/media/platform/sti/delta/delta-mpeg2-fw.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ac026ee..1571462 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -355,15 +355,22 @@ config VIDEO_STI_DELTA_MJPEG
To compile this driver as a module, choose M here:
the module will be called st-delta.
 
+config VIDEO_STI_DELTA_MPEG2
+   bool "STMicroelectronics DELTA MPEG2/MPEG1 support"
+   default y
+   help
+   Enables DELTA MPEG2 hardware support.
+
 config VIDEO_STI_DELTA_DRIVER
tristate
depends on VIDEO_STI_DELTA
-   depends on VIDEO_STI_DELTA_MJPEG
-   default VIDEO_STI_DELTA_MJPEG
+   depends on VIDEO_STI_DELTA_MJPEG || VIDEO_STI_DELTA_MPEG2
+   default y
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
select RPMSG
 
+
 endif # VIDEO_STI_DELTA
 
 config VIDEO_SH_VEU
diff --git a/drivers/media/platform/sti/delta/Makefile 
b/drivers/media/platform/sti/delta/Makefile
index 8d032508..b18ed37 100644
--- a/drivers/media/platform/sti/delta/Makefile
+++ b/drivers/media/platform/sti/delta/Makefile
@@ -4,3 +4,6 @@ st-delta-y := delta-v4l2.o delta-mem.o delta-ipc.o delta-debug.o
 # MJPEG support
 st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-hdr.o
 st-delta-$(CONFIG_VIDEO_STI_DELTA_MJPEG) += delta-mjpeg-dec.o
+
+# MPEG2 support
+st-delta-$(CONFIG_VIDEO_STI_DELTA_MPEG2) += delta-mpeg2-dec.o
diff --git a/drivers/media/platform/sti/delta/delta-cfg.h 
b/drivers/media/platform/sti/delta/delta-cfg.h
index c6388f5..bce2c74 100644
--- a/drivers/media/platform/sti/delta/delta-cfg.h
+++ b/drivers/media/platform/sti/delta/delta-cfg.h
@@ -61,4 +61,9 @@
 extern const struct delta_dec mjpegdec;
 #endif
 
+#ifdef CONFIG_VIDEO_STI_DELTA_MPEG2
+extern const struct delta_dec mpeg2dec;
+extern const struct delta_dec mpeg1dec;
+#endif
+
 #endif /* DELTA_CFG_H */
diff --git a/drivers/media/platform/sti/delta/delta-mpeg2-dec.c 
b/drivers/media/platform/sti/delta/delta-mpeg2-dec.c
new file mode 100644
index 000..adb0300
--- /dev/null
+++ b/drivers/media/platform/sti/delta/delta-mpeg2-dec.c
@@ -0,0 +1,1401 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2015
+ * Authors: Hugues Fruchet 
+ *  Chetan Nanda 
+ *  Jean-Christophe Trotin 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+
+#include "delta.h"
+#include "delta-ipc.h"
+#include "delta-mem.h"
+#include "delta-mpeg2-fw.h"
+
+#define DELTA_MPEG2_MAX_RESO DELTA_MAX_RESO
+
+/* minimal number of frames for decoding = 1 dec + 2 refs frames */
+#define DELTA_MPEG2_DPB_FRAMES_NEEDED 3
+
+struct delta_mpeg2_ctx {
+   /* ipc */
+   void *ipc_hdl;
+   struct delta_buf *ipc_buf;
+
+   /* stream information */
+   struct delta_streaminfo streaminfo;
+
+   bool header_parsed;
+
+   /* reference frames mgt */
+   struct delta_mpeg2_frame *prev_ref;
+   struct delta_mpeg2_frame *next_ref;
+
+   /* output frames reordering management */
+   struct delta_frame *out_frame;
+   struct delta_frame *delayed_frame;
+
+   /* interlaced frame management */
+   struct delta_frame *last_frame;
+   enum mpeg2_picture_structure_t accumulated_picture_structure;
+
+   unsigned char str[3000];
+};
+
+/* codec specific frame struct */
+struct delta_mpeg2_frame {
+   struct delta_frame frame;
+   u32 tref;   /* temporal reference */
+   struct delta_buf omega_buf; /* 420mb buffer for decoding */
+};
+
+#define to_ctx(ctx) ((struct delta_mpeg2_ctx *)(ctx)->priv)
+#define to_mpeg2_frame(frame) ((struct delta_mpeg2_frame *)frame)
+#define to_frame(mpeg2_frame) ((struct delta_frame *)mpeg2_frame)
+
+/* default intra, zig-zag order */
+static u8 default_intra_matrix[] = {
+   8,
+   16, 16,
+   19, 16, 19,
+   22, 22, 22, 22,
+   22, 22, 26, 24, 26,
+   27, 27, 27, 26, 26, 26,
+   26, 27, 27, 27, 

[PATCH] mxl111sf: Fix driver to use heap allocate buffers for USB messages

[Devin Heitmueller]

The recent changes in 4.9 to mandate USB buffers be heap allocated
broke this driver, which was allocating the buffers on the stack.
This resulted in the device failing at initialization.

Introduce dedicated send/receive buffers as part of the state
structure, and add a mutex to protect access to them.

Note: we also had to tweak the API to mxl111sf_ctrl_msg to pass
the pointer to the state struct rather than the device, since
we need it inside the function to access the buffers and the
mutex.  This patch adjusts the callers to match the API change.

Signed-off-by: Devin Heitmueller 
Reported-by: Doug Lung 
Cc: Michael Ira Krufky 
---
 drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c |  4 ++--
 drivers/media/usb/dvb-usb-v2/mxl111sf.c | 32 +
 drivers/media/usb/dvb-usb-v2/mxl111sf.h |  8 +++-
 3 files changed, 28 insertions(+), 16 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c 
b/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c
index ffb49c2..0eb33e04 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c
@@ -316,7 +316,7 @@ static int mxl111sf_i2c_sw_xfer_msg(struct mxl111sf_state 
*state,
 static int mxl111sf_i2c_send_data(struct mxl111sf_state *state,
  u8 index, u8 *wdata)
 {
-   int ret = mxl111sf_ctrl_msg(state->d, wdata[0],
+   int ret = mxl111sf_ctrl_msg(state, wdata[0],
[1], 25, NULL, 0);
mxl_fail(ret);
 
@@ -326,7 +326,7 @@ static int mxl111sf_i2c_send_data(struct mxl111sf_state 
*state,
 static int mxl111sf_i2c_get_data(struct mxl111sf_state *state,
 u8 index, u8 *wdata, u8 *rdata)
 {
-   int ret = mxl111sf_ctrl_msg(state->d, wdata[0],
+   int ret = mxl111sf_ctrl_msg(state, wdata[0],
[1], 25, rdata, 24);
mxl_fail(ret);
 
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c 
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index abf69d8..b0d5904 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -24,9 +24,6 @@
 #include "lgdt3305.h"
 #include "lg2160.h"
 
-/* Max transfer size done by I2C transfer functions */
-#define MAX_XFER_SIZE  64
-
 int dvb_usb_mxl111sf_debug;
 module_param_named(debug, dvb_usb_mxl111sf_debug, int, 0644);
 MODULE_PARM_DESC(debug, "set debugging level (1=info, 2=xfer, 4=i2c, 8=reg, 
16=adv (or-able)).");
@@ -55,27 +52,34 @@
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
-int mxl111sf_ctrl_msg(struct dvb_usb_device *d,
+int mxl111sf_ctrl_msg(struct mxl111sf_state *state,
  u8 cmd, u8 *wbuf, int wlen, u8 *rbuf, int rlen)
 {
+   struct dvb_usb_device *d = state->d;
int wo = (rbuf == NULL || rlen == 0); /* write-only */
int ret;
-   u8 sndbuf[MAX_XFER_SIZE];
 
-   if (1 + wlen > sizeof(sndbuf)) {
+   if (1 + wlen > MXL_MAX_XFER_SIZE) {
pr_warn("%s: len=%d is too big!\n", __func__, wlen);
return -EOPNOTSUPP;
}
 
pr_debug("%s(wlen = %d, rlen = %d)\n", __func__, wlen, rlen);
 
-   memset(sndbuf, 0, 1+wlen);
+   mutex_lock(>msg_lock);
+   memset(state->sndbuf, 0, 1+wlen);
+   memset(state->rcvbuf, 0, rlen);
+
+   state->sndbuf[0] = cmd;
+   memcpy(>sndbuf[1], wbuf, wlen);
 
-   sndbuf[0] = cmd;
-   memcpy([1], wbuf, wlen);
+   ret = (wo) ? dvb_usbv2_generic_write(d, state->sndbuf, 1+wlen) :
+   dvb_usbv2_generic_rw(d, state->sndbuf, 1+wlen, state->rcvbuf,
+rlen);
+
+   memcpy(rbuf, state->rcvbuf, rlen);
+   mutex_unlock(>msg_lock);
 
-   ret = (wo) ? dvb_usbv2_generic_write(d, sndbuf, 1+wlen) :
-   dvb_usbv2_generic_rw(d, sndbuf, 1+wlen, rbuf, rlen);
mxl_fail(ret);
 
return ret;
@@ -91,7 +95,7 @@ int mxl111sf_read_reg(struct mxl111sf_state *state, u8 addr, 
u8 *data)
u8 buf[2];
int ret;
 
-   ret = mxl111sf_ctrl_msg(state->d, MXL_CMD_REG_READ, , 1, buf, 2);
+   ret = mxl111sf_ctrl_msg(state, MXL_CMD_REG_READ, , 1, buf, 2);
if (mxl_fail(ret)) {
mxl_debug("error reading reg: 0x%02x", addr);
goto fail;
@@ -117,7 +121,7 @@ int mxl111sf_write_reg(struct mxl111sf_state *state, u8 
addr, u8 data)
 
pr_debug("W: (0x%02x, 0x%02x)\n", addr, data);
 
-   ret = mxl111sf_ctrl_msg(state->d, MXL_CMD_REG_WRITE, buf, 2, NULL, 0);
+   ret = mxl111sf_ctrl_msg(state, MXL_CMD_REG_WRITE, buf, 2, NULL, 0);
if (mxl_fail(ret))
pr_err("error writing reg: 0x%02x, val: 0x%02x", addr, data);
return ret;
@@ -926,6 +930,8 @@ static int mxl111sf_init(struct dvb_usb_device *d)
  .len = sizeof(eeprom), .buf = eeprom },
};
 
+   mutex_init(>msg_lock);
+
ret = 

Re: RFC: Power states and VIDIOC_STREAMON

[Devin Heitmueller]

>> I had always interpreted it such that the STREAMON call just
>> controlled whether the DMA engine was running, and thus you could do
>> anything else with the decoder before calling STREAMON other than
>> actually receiving video buffers.
>
> Indeed there's an ambiguity there, although I always read that
> the device's logic should keep accepting calls via both DVB
> and V4L2 APIs until V4L2 streaming ioctls are issued.

Yeah, the hybrid use case is clearly something that didn't exist back
then.  Most of the video decoders I've worked on (e.g. tvp5150,
saa7115) have the device running all the time and s_stream is only
used for output control (i.e. enable/disable the ITU-656 output).

> That's, btw, what happens on older drivers like cx88 and bttv.
>
> For example, on bttv, there's this logic:
>
> static int bttv_s_fmt_vid_cap(struct file *file, void *priv,
> struct v4l2_format *f)
> {
> int retval;
> const struct bttv_format *fmt;
> struct bttv_fh *fh = priv;
> struct bttv *btv = fh->btv;
> __s32 width, height;
> unsigned int width_mask, width_bias;
> enum v4l2_field field;
>
> retval = bttv_switch_type(fh, f->type);
> if (0 != retval)
> return retval;
>
> The logic there actually happens earlier, at VIDIOC_S_FMT. Although I
> guess all apps call it before streaming, the problem with the above is
> that the V4L2 API doesn't actually make it mandatory to call this ioctl
> before start streaming.
>
> I guess that the idea of doing that at STREAMON started when we
> discussed how to lock hybrid devices via MC. I guess it was suggested
> by Shuah, who looked on those issues and analyzed what apps used to do.

I've got a pile of changes which involve refactoring the power
management on the au8522, but I have never thoroughly reviewed where
Shuah ended up with the MC changes and thus it's likely they don't
take those into account.

>> My instinct would be to revert the patch in question since it breaks
>> ABI behavior which has been present for over a decade, but I suspect
>> such a patch would be rejected since it was Mauro himself who
>> introduced the change in behavior.
>
> It doesn't matter who committed a patch. If it is wrong, something
> should be done.
>
> However, in the specific case of a change like that, just reverting the
> patch right now would make it worse, as it will break the resource locks
> between FM, analog TV and digital TV, causing regressions.
>
> Locking it at tuner get status is a bad place, as I guess that would
> break locking between FM radio and analog TV, as both can read
> tuner status.

For what it's worth, FM radio isn't supported in the au0828/au8522
driver, so that doesn't need to be a consideration for this particular
driver unless you're suggesting some changes to the framework common
to all devices.

> Maybe one solution would be to lock the resources on either
> for VIDIOC_S_FMT, VIDIOC_STREAMON or read() (whatever comes first),
> but we need to check if this won't break switching between analog TV
> and FM.

I could argue that despite the PAL-M changes you made a couple of
years ago, the device is only ever really used with a single standard
(NTSC), and thus it's entirely possible that the user may never call
S_FMT given the default is to capture 720x480 YUY2 and the device is
already in that mode at initialization.  Also, IIRC the s_stream()
subdev callback automatically gets invoked when you do a read(), in
order to support both MMAP and READ modes.  I could suggest that it
should be locked when you call S_INPUT, but I'm pretty sure that's how
I had it to begin with.  Likewise even in that case you could still
hit the issue if the user is trying to use the default input of 0
(i.e. plug in stick, call S_FREQ, and then poll for lock).

No easy answers here, just trade-offs between how badly you want to
break an API that was created with no consideration for power
management or hybrid devices.

Devin

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

Re: [PATCH] [media] ov2640: make GPIOLIB an optional dependency

[Mauro Carvalho Chehab]

Em Fri, 21 Apr 2017 08:33:12 +0200
Pavel Machek  escreveu:

> Hi!
> 
> > > Better solution would be for VIDEO_EM28XX_V4L2 to depend on GPIOLIB,
> > > too, no? If not, should there be BUG_ON(priv->pwdn_gpio);
> > > BUG_ON(priv->resetb_gpio);?  
> > 
> > Pavel,
> > 
> > The em28xx driver was added upstream several years the gpio driver. 
> > It controls GPIO using a different logic. It makes no sense to make
> > it dependent on GPIOLIB, except if someone converts it to use it.  
> 
> At least comment in the sourcecode...? Remove pwdn_gpio fields from
> structure in !GPIOLIB case, because otherwise they are trap for the
> programmer trying to understand what is going on?


Sorry, I answered to another e-mail thread related to it. I assumed
that it was c/c to linux-media, but it is, in fact a private e-mail.

I can see two alternatives:

1) Restore old behavior, assuming that all drivers that use OV2640 will
have GPIOLIB enabled, with a patch like:

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index fd181c99ce11..4e834c36f7da 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -521,6 +521,7 @@ config VIDEO_OV2640
tristate "OmniVision OV2640 sensor support"
depends on VIDEO_V4L2 && I2C
depends on MEDIA_CAMERA_SUPPORT
+   depends on GPIOLIB if OF
help
  This is a Video4Linux2 sensor-level driver for the OmniVision
  OV2640 camera.

However, I was told that some OF drivers don't actually define the GPIO
pins.

So, the other option is:

2) Make the logic smarter for OF, with this change:


diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 4a2ae24f8722..8855c81a9e1f 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -1048,21 +1048,39 @@ static const struct v4l2_subdev_ops ov2640_subdev_ops = 
{
 static int ov2640_probe_dt(struct i2c_client *client,
struct ov2640_priv *priv)
 {
+   int ret;
+
/* Request the reset GPIO deasserted */
priv->resetb_gpio = devm_gpiod_get_optional(>dev, "resetb",
GPIOD_OUT_LOW);
-   if (!priv->resetb_gpio)
+   if (!priv->resetb_gpio) {
dev_dbg(>dev, "resetb gpio is not assigned!\n");
-   else if (IS_ERR(priv->resetb_gpio))
-   return PTR_ERR(priv->resetb_gpio);
+   } else {
+   ret = PTR_ERR(priv->resetb_gpio);
+
+   if (ret && ret != -ENOSYS) {
+   dev_dbg(>dev,
+   "Error %d while getting resetb gpio\n",
+   ret);
+   return ret;
+   }
+   }
 
/* Request the power down GPIO asserted */
priv->pwdn_gpio = devm_gpiod_get_optional(>dev, "pwdn",
GPIOD_OUT_HIGH);
-   if (!priv->pwdn_gpio)
+   if (!priv->pwdn_gpio) {
dev_dbg(>dev, "pwdn gpio is not assigned!\n");
-   else if (IS_ERR(priv->pwdn_gpio))
-   return PTR_ERR(priv->pwdn_gpio);
+   } else {
+   ret = PTR_ERR(priv->pwdn_gpio);
+
+   if (ret && ret != -ENOSYS) {
+   dev_dbg(>dev,
+   "Error %d while getting pwdn gpio\n",
+   ret);
+   return ret;
+   }
+   }
 
return 0;
 }

For this to work, OF caller drivers will have to depend or select GPIOLIB,
if they need those GPIO pins.

IMHO, (2) is better, but I'd like to hear more opinions from the driver
authors that require the usage of ov2640 I2C driver.

> 
> Plus, something like this, because otherwise it is quite confusing?
> 
> Thanks,
>   Pavel
> 
> diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
> b/drivers/media/i2c/soc_camera/ov2640.c
> index 56de182..85620e1 100644
> --- a/drivers/media/i2c/soc_camera/ov2640.c
> +++ b/drivers/media/i2c/soc_camera/ov2640.c
> @@ -1060,7 +1060,7 @@ static int ov2640_hw_reset(struct device *dev)
>   /* Active the resetb pin to perform a reset pulse */
>   gpiod_direction_output(priv->resetb_gpio, 1);
>   usleep_range(3000, 5000);
> - gpiod_direction_output(priv->resetb_gpio, 0);
> + gpiod_set_value(priv->resetb_gpio, 0);
>   }
>  
>   return 0;
> 

That should be, IMHO, on a separate patch. Why are you changing just
one of the set commands there? Shouldn't it be, instead:

diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 8855c81a9e1f..4ec567569ba2 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -770,12 +770,12 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
 
 #ifdef CONFIG_GPIOLIB
if (priv->pwdn_gpio)
-   gpiod_direction_output(priv->pwdn_gpio, !on);
+   gpiod_set_value(priv->pwdn_gpio, !on);
if (on 

[PATCH v5 2/3] [media] st-delta: add parsing metadata controls support

[Hugues Fruchet]

Install all metadata controls required by registered decoders.
Update the decoding context with the set of metadata received
from user through extended control.
Set the received metadata in access unit prior to call the
decoder decoding ops.

Signed-off-by: Hugues Fruchet 
---
 drivers/media/platform/sti/delta/delta-v4l2.c | 125 +-
 drivers/media/platform/sti/delta/delta.h  |  34 +++
 2 files changed, 158 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/delta/delta-v4l2.c 
b/drivers/media/platform/sti/delta/delta-v4l2.c
index c6f2e24..1d4436e 100644
--- a/drivers/media/platform/sti/delta/delta-v4l2.c
+++ b/drivers/media/platform/sti/delta/delta-v4l2.c
@@ -339,6 +339,30 @@ static void register_decoders(struct delta_dev *delta)
}
 }
 
+static void register_ctrls(struct delta_dev *delta)
+{
+   const struct delta_dec *dec;
+   unsigned int i, j;
+   u32 meta_cid;
+
+   /* decoders optional meta controls */
+   for (i = 0; i < delta->nb_of_decoders; i++) {
+   dec = delta->decoders[i];
+   if (!dec->meta_cids)
+   continue;
+
+   for (j = 0; j < dec->nb_of_metas; j++) {
+   meta_cid = dec->meta_cids[j];
+   if (!meta_cid)
+   continue;
+
+   delta->cids[delta->nb_of_ctrls++] = meta_cid;
+   }
+   }
+
+   /* add here additional controls if needed */
+}
+
 static void delta_lock(void *priv)
 {
struct delta_ctx *ctx = priv;
@@ -355,6 +379,79 @@ static void delta_unlock(void *priv)
mutex_unlock(>lock);
 }
 
+static int delta_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct delta_ctx *ctx =
+   container_of(ctrl->handler, struct delta_ctx, ctrl_handler);
+   struct delta_dev *delta = ctx->dev;
+
+   if (ctx->nb_of_metas >= DELTA_MAX_METAS) {
+   dev_err(delta->dev, "%s not enough room to set meta control\n",
+   ctx->name);
+   return -EINVAL;
+   }
+
+   dev_dbg(delta->dev, "%s set metas[%d] from control id=%d (%s)\n",
+   ctx->name, ctx->nb_of_metas, ctrl->id, ctrl->name);
+
+   ctx->metas[ctx->nb_of_metas].cid = ctrl->id;
+   ctx->metas[ctx->nb_of_metas].p = ctrl->p_new.p;
+   ctx->nb_of_metas++;
+
+   return 0;
+}
+
+static const struct v4l2_ctrl_ops delta_ctrl_ops = {
+   .s_ctrl = delta_s_ctrl,
+};
+
+static int delta_ctrls_setup(struct delta_ctx *ctx)
+{
+   struct delta_dev *delta = ctx->dev;
+   struct v4l2_ctrl_handler *hdl = >ctrl_handler;
+   unsigned int i;
+
+   v4l2_ctrl_handler_init(hdl, delta->nb_of_ctrls);
+
+   for (i = 0; i < delta->nb_of_ctrls; i++) {
+   struct v4l2_ctrl *ctrl;
+   u32 cid = delta->cids[i];
+   struct v4l2_ctrl_config cfg;
+
+   /* override static config to set delta_ctrl_ops */
+   memset(, 0, sizeof(cfg));
+   cfg.id = cid;
+   cfg.ops = _ctrl_ops;
+
+   ctrl = v4l2_ctrl_new_custom(hdl, , NULL);
+   if (hdl->error) {
+   int err = hdl->error;
+
+   dev_err(delta->dev, "%s failed to setup control '%s' 
(id=%d, size=%d, err=%d)\n",
+   ctx->name, cfg.name, cfg.id,
+   cfg.elem_size, err);
+   v4l2_ctrl_handler_free(hdl);
+   return err;
+   }
+
+   /* force unconditional execution of s_ctrl() by
+* disabling control value evaluation in case of
+* meta control (passed by pointer)
+*/
+   if (ctrl->is_ptr)
+   ctrl->flags |= V4L2_CTRL_FLAG_EXECUTE_ON_WRITE;
+   }
+
+   v4l2_ctrl_handler_setup(hdl);
+   ctx->fh.ctrl_handler = hdl;
+
+   ctx->nb_of_metas = 0;
+   memset(ctx->metas, 0, sizeof(ctx->metas));
+
+   dev_dbg(delta->dev, "%s controls setup done\n", ctx->name);
+   return 0;
+}
+
 static int delta_open_decoder(struct delta_ctx *ctx, u32 streamformat,
  u32 pixelformat, const struct delta_dec **pdec)
 {
@@ -964,6 +1061,12 @@ static void delta_run_work(struct work_struct *work)
au->size = vb2_get_plane_payload(>vb2_buf, 0);
au->dts = vbuf->vb2_buf.timestamp;
 
+   /* set access unit meta data in case of decoder requires it */
+   memcpy(au->metas, ctx->metas, ctx->nb_of_metas * sizeof(au->metas[0]));
+   au->nb_of_metas = ctx->nb_of_metas;
+   /* reset context metas for next decoding */
+   ctx->nb_of_metas = 0;
+
/* dump access unit */
dump_au(ctx, au);
 
@@ -1364,6 +1467,12 @@ static int delta_vb2_au_start_streaming(struct vb2_queue 
*q,
au->size = vb2_get_plane_payload(>vb2_buf, 0);
au->dts = 

Re: RFC: Power states and VIDIOC_STREAMON

[Mauro Carvalho Chehab]

Hi Devin,

Em Wed, 19 Apr 2017 15:15:20 -0400
Devin Heitmueller  escreveu:

> Hello all,
> 
> I'm in the process of putting together a bunch of long-standing fixes
> for HVR-950q driver, and I ran into a regression related to the way
> the video decoder is being managed.  Before we dig into the details
> here's the general question:
> 
> Should a user be able to interrogate video decoder properties after
> doing a tune without having first called VIDIOC_STREAMON?
> 
> A long-standing use case is to be able to use a command-line tool like
> v4l2-ctl to set the input, set the standard, issue a tuning request,
> poll for a lock status, and once you see a signal lock then start
> streaming.  This means that prior to starting streaming the tuner,
> analog demodulator, and video decoder are all running even though
> you're not actually receiving video buffers.
> 
> The problem comes down to these two patches:
> 
> https://git.linuxtv.org/media_tree.git/commit/drivers/media/dvb-frontends/au8522_decoder.c?id=38fe3510fa8fb5e75ee3b196e44a7b717d167e5d
> https://git.linuxtv.org/media_tree.git/commit/drivers/media/dvb-frontends/au8522_decoder.c?id=d289cdf022c5bebf09c73097404aa9faf2211381
> 
> Prior to these patches, I would power up the IP blocks for the analog
> demodulator and decoder when the video routing was setup (typically
> when setting the input).  However as a result of these patches
> powering up of those IP blocks is deferred until STREAMON is called.
> Hence if you just set the input and issue a tuning request, and poll
> for lock then you will never see the tuner in a locked state
> regardless of the actual signal state.
> 
> I can appreciate the motivation behind Mauro's change in wanting to
> constrain the window that the analog decoder is powered up to reduce
> the risk of having it powered up at the same time as the digital
> demodulator, but if it breaks long-standing ABI behavior then that
> probably isn't going to work.
> 
> I did take a look at the the VIDIOC_STREAMON docs, which state that
> the "Capture hardware is disabled and no buffers are filled" prior to
> calling STREAMON:
> 
> https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-streamon.html
> 
> However that language would suggest that even the tuner would be
> powered down prior to calling STREAMON, which we know is almost never
> the case.
> 
> I suspect the ambiguity lies in what is defined by "capture hardware":
> 
> The DMA engine or other mechanism of transferring completed video
> buffers to userland?
> The DMA engine and the video decoder?
> The DMA engine, video decoder, and analog demodulator?
> The DMA engine, video decoder, analog demodulator, and tuner?
> 
> I had always interpreted it such that the STREAMON call just
> controlled whether the DMA engine was running, and thus you could do
> anything else with the decoder before calling STREAMON other than
> actually receiving video buffers.

Indeed there's an ambiguity there, although I always read that
the device's logic should keep accepting calls via both DVB
and V4L2 APIs until V4L2 streaming ioctls are issued.

That's, btw, what happens on older drivers like cx88 and bttv.

For example, on bttv, there's this logic:

static int bttv_s_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *f)
{
int retval;
const struct bttv_format *fmt;
struct bttv_fh *fh = priv;
struct bttv *btv = fh->btv;
__s32 width, height;
unsigned int width_mask, width_bias;
enum v4l2_field field;

retval = bttv_switch_type(fh, f->type);
if (0 != retval)
return retval;

The logic there actually happens earlier, at VIDIOC_S_FMT. Although I
guess all apps call it before streaming, the problem with the above is
that the V4L2 API doesn't actually make it mandatory to call this ioctl
before start streaming.

I guess that the idea of doing that at STREAMON started when we 
discussed how to lock hybrid devices via MC. I guess it was suggested
by Shuah, who looked on those issues and analyzed what apps used to do.

> My instinct would be to revert the patch in question since it breaks
> ABI behavior which has been present for over a decade, but I suspect
> such a patch would be rejected since it was Mauro himself who
> introduced the change in behavior.

It doesn't matter who committed a patch. If it is wrong, something
should be done.

However, in the specific case of a change like that, just reverting the
patch right now would make it worse, as it will break the resource locks
between FM, analog TV and digital TV, causing regressions.

Locking it at tuner get status is a bad place, as I guess that would
break locking between FM radio and analog TV, as both can read
tuner status.

Maybe one solution would be to lock the resources on either
for VIDIOC_S_FMT, VIDIOC_STREAMON or read() (whatever comes first),
but we need to check if this won't 

Re: [PATCH] [media] Order the Makefile alphabetically

[Mauro Carvalho Chehab]

Em Fri, 21 Apr 2017 16:41:25 +0200
Maxime Ripard  escreveu:

> On Wed, Apr 19, 2017 at 08:15:45AM -0300, Mauro Carvalho Chehab wrote:
> > Em Thu,  6 Apr 2017 16:40:51 +0200
> > Maxime Ripard  escreveu:
> >   
> > > The Makefiles were a free for all without a clear order defined. Sort all 
> > > the
> > > options based on the Kconfig symbol.
> > > 
> > > Signed-off-by: Maxime Ripard 
> > > 
> > > ---
> > > 
> > > Hi Mauro,
> > > 
> > > Here is my makefile ordering patch again, this time with all the Makefiles
> > > in drivers/media that needed ordering.
> > > 
> > > Since we're already pretty late in the release period, I guess there won't
> > > be any major conflicts between now and the merge window.
> > >   
> > 
> > The thing with patches like that is that they almost never apply fine.
> > By the time I review such patches, it was already broken. Also,
> > once applied, it breaks for everybody that have pending work to merge.
> > 
> > This patch is broken (see attached).
> > 
> > So, I prefer not applying stuff like that.  
> 
> I had the feeling that now would have been a good time to merge it,
> since all the PR should be merged I guess. But ok.

No, there are drivers that were late-submitted, and whose commit
(if driver gets accepted) will be after -rc1. If this patch gets 
applied, those drivers will have merge conflicts. There are also
the cases where people have drivers under development. If they pull
from my tree after a change like that, the developer will get
conflicts.


Thanks,
Mauro

Re: [PATCHv4 00/12] Ion cleanup in preparation for moving out of staging

[Sumit Semwal]

Hi Laura,

Thanks much for this series!

On 18 April 2017 at 23:57, Laura Abbott  wrote:
> Hi,
>
> This is v4 of the series to cleanup to Ion. Greg took some of the patches
> that weren't CMA related already. There was a minor bisectability problem
> with the CMA APIs so this is a new version to address that. I also
> addressed some minor comments on the patch to collapse header files.

For the series, please feel free to apply my
Acked-by: Sumit Semwal 

>
> Thanks,
> Laura
>
> Laura Abbott (12):
>   cma: Store a name in the cma structure
>   cma: Introduce cma_for_each_area
>   staging: android: ion: Use CMA APIs directly
>   staging: android: ion: Stop butchering the DMA address
>   staging: android: ion: Break the ABI in the name of forward progress
>   staging: android: ion: Get rid of ion_phys_addr_t
>   staging: android: ion: Collapse internal header files
>   staging: android: ion: Rework heap registration/enumeration
>   staging: android: ion: Drop ion_map_kernel interface
>   staging: android: ion: Remove ion_handle and ion_client
>   staging: android: ion: Set query return value
>   staging/android: Update Ion TODO list
>
>  arch/powerpc/kvm/book3s_hv_builtin.c|   3 +-
>  drivers/base/dma-contiguous.c   |   5 +-
>  drivers/staging/android/TODO|  21 +-
>  drivers/staging/android/ion/Kconfig |  32 +
>  drivers/staging/android/ion/Makefile|  11 +-
>  drivers/staging/android/ion/compat_ion.c| 152 -
>  drivers/staging/android/ion/compat_ion.h|  29 -
>  drivers/staging/android/ion/ion-ioctl.c |  55 +-
>  drivers/staging/android/ion/ion.c   | 812 
> ++--
>  drivers/staging/android/ion/ion.h   | 386 ---
>  drivers/staging/android/ion/ion_carveout_heap.c |  21 +-
>  drivers/staging/android/ion/ion_chunk_heap.c|  16 +-
>  drivers/staging/android/ion/ion_cma_heap.c  | 120 ++--
>  drivers/staging/android/ion/ion_heap.c  |  68 --
>  drivers/staging/android/ion/ion_page_pool.c |   3 +-
>  drivers/staging/android/ion/ion_priv.h  | 453 -
>  drivers/staging/android/ion/ion_system_heap.c   |  39 +-
>  drivers/staging/android/uapi/ion.h  |  36 +-
>  include/linux/cma.h |   6 +-
>  mm/cma.c|  31 +-
>  mm/cma.h|   1 +
>  mm/cma_debug.c  |   2 +-
>  22 files changed, 524 insertions(+), 1778 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/compat_ion.c
>  delete mode 100644 drivers/staging/android/ion/compat_ion.h
>  delete mode 100644 drivers/staging/android/ion/ion_priv.h
>
> --
> 2.7.4
>



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs

[PATCH v5 1/3] [media] v4l: add parsed MPEG-2 support

[Hugues Fruchet]

Add "parsed MPEG-2" pixel format & related controls
needed by stateless video decoders.
In order to decode the video bitstream chunk provided
by user on output queue, stateless decoders require
also some extra data resulting from this video bitstream
chunk parsing.
Those parsed extra data have to be set by user through
control framework using the dedicated mpeg video extended
controls introduced in this patchset.

Signed-off-by: Hugues Fruchet 
---
 Documentation/media/uapi/v4l/extended-controls.rst | 363 +
 Documentation/media/uapi/v4l/pixfmt-013.rst|  10 +
 drivers/media/v4l2-core/v4l2-ctrls.c   |  53 +++
 drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
 include/uapi/linux/v4l2-controls.h |  98 ++
 include/uapi/linux/videodev2.h |   8 +
 6 files changed, 534 insertions(+)

diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index abb1057..0f8d17f 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1827,6 +1827,369 @@ enum v4l2_mpeg_cx2341x_video_median_filter_type -
 not insert, 1 = insert packets.
 
 
+MPEG-2 Parsed Control Reference
+-
+
+The MPEG-2 parsed decoding controls are needed by stateless video decoders.
+Those decoders expose :ref:`Compressed formats ` 
:ref:`V4L2_PIX_FMT_MPEG1_PARSED` or 
:ref:`V4L2_PIX_FMT_MPEG2_PARSED`.
+In order to decode the video bitstream chunk provided by user on output queue,
+stateless decoders require also some extra data resulting from this video
+bitstream chunk parsing. Those parsed extra data have to be set by user
+through control framework using the mpeg video extended controls defined
+in this section. Those controls have been defined based on MPEG-2 standard
+ISO/IEC 13818-2, and so derive directly from the MPEG-2 video bitstream syntax
+including how it is coded inside bitstream (enumeration values for ex.).
+
+MPEG-2 Parsed Control IDs
+^^^
+
+.. _mpeg2-parsed-control-id:
+
+``V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_HDR``
+(enum)
+
+.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
+
+.. c:type:: v4l2_mpeg_video_mpeg2_seq_hdr
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_mpeg_video_mpeg2_seq_hdr
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u16
+  - ``width``
+  - Video width in pixels.
+* - __u16
+  - ``height``
+  - Video height in pixels.
+* - __u8
+  - ``aspect_ratio_info``
+  - Aspect ratio code as in the bitstream (1: 1:1 square pixels,
+2: 4:3 display, 3: 16:9 display, 4: 2.21:1 display)
+* - __u8
+  - ``framerate code``
+  - Framerate code as in the bitstream
+(1: 24000/1001.0 '23.976 fps, 2: 24.0, 3: 25.0,
+4: 3/1001.0 '29.97, 5: 30.0, 6: 50.0, 7: 6/1001.0,
+8: 60.0)
+* - __u16
+  - ``vbv_buffer_size``
+  -  Video Buffering Verifier size, expressed in 16KBytes unit.
+* - __u32
+  - ``bitrate_value``
+  - Bitrate value as in the bitstream, expressed in 400bps unit
+* - __u8
+  - ``constrained_parameters_flag``
+  - Set to 1 if this bitstream uses constrained parameters.
+* - __u8
+  - ``load_intra_quantiser_matrix``
+  - If set to 1, ``intra_quantiser_matrix`` table is to be used for
+decoding.
+* - __u8
+  - ``load_non_intra_quantiser_matrix``
+  - If set to 1, ``non_intra_quantiser_matrix`` table is to be used for
+decoding.
+* - __u8
+  - ``intra_quantiser_matrix[64]``
+  - Intra quantization table, in zig-zag scan order.
+* - __u8
+  - ``non_intra_quantiser_matrix[64]``
+  - Non-intra quantization table, in zig-zag scan order.
+* - __u32
+  - ``par_w``
+  - Pixel aspect ratio width in pixels.
+* - __u32
+  - ``par_h``
+  - Pixel aspect ratio height in pixels.
+* - __u32
+  - ``fps_n``
+  - Framerate nominator.
+* - __u32
+  - ``fps_d``
+  - Framerate denominator.
+* - __u32
+  - ``bitrate``
+  - Bitrate in bps if constant bitrate, 0 otherwise.
+* - :cspan:`2`
+
+
+``V4L2_CID_MPEG_VIDEO_MPEG2_SEQ_EXT``
+(enum)
+
+.. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
+
+.. c:type:: v4l2_mpeg_video_mpeg2_seq_ext
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_mpeg_video_mpeg2_seq_ext
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u8
+  - ``profile``
+  - Encoding profile used to encode this bitstream.
+(1: High Profile, 2: Spatially Scalable Profile,
+3: SNR Scalable Profile, 4: Main Profile, 5: Simple Profile).
+* - __u8
+  - ``level``
+  - Encoding level used to encode this bitstream
+(4: High Level, 6: High 1440 Level, 8: Main Level, 10: Low Level).
+* - 

[PATCH v5 0/3] Add support for MPEG-2 in DELTA video decoder

[Hugues Fruchet]

The patchset implements the MPEG-2 part of V4L2 unified low-level decoder
API RFC [0] needed by stateless video decoders, ie decoders which requires
specific parsing metadata in addition to video bitstream chunk in order
to complete decoding.
A reference implementation using STMicroelectronics DELTA video decoder
is provided as initial support in this patchset.
In addition to this patchset, a libv4l plugin is also provided which convert
MPEG-2 video bitstream to "parsed MPEG-2" by parsing the user video bitstream
and filling accordingly the dedicated controls, doing so user code remains
unchanged whatever decoder is: stateless or not.

The first patch implements the MPEG-2 part of V4L2 unified low-level decoder
API RFC [0]. A dedicated "parsed MPEG-2" pixel format has been introduced with
its related extended controls in order that user provides both video bitstream
chunk and the associated extra data resulting from this video bitstream chunk
parsing.

The second patch adds the support of "parsed" pixel format inside DELTA video
decoder including handling of the dedicated controls and setting of parsing
metadata required by decoder layer.
Please note that the current implementation has a restriction regarding
the atomicity of S_EXT_CTRL/QBUF that must be guaranteed by user.
This restriction will be removed when V4L2 request API will be implemented [1].
Please also note the failure in v4l2-compliance in controls section, related
to complex compound controls handling, to be discussed to find the right way
to fix it in v4l2-compliance.

The third patch adds the support of DELTA MPEG-2 stateless video decoder 
back-end.


This driver depends on:
  [PATCH v7 00/10] Add support for DELTA video decoder of STMicroelectronics 
STiH4xx SoC series https://patchwork.linuxtv.org/patch/39186/

References:
  [0] [RFC] V4L2 unified low-level decoder API 
https://www.spinics.net/lists/linux-media/msg107150.html
  [1] [ANN] Report of the V4L2 Request API brainstorm meeting 
https://www.spinics.net/lists/linux-media/msg106699.html

===
= history =
===
version 5:
  - patchset 4 review from Hans:
- fix 32/64 bit compat in mpeg2 controls struct (using pahole utility)
- fix upper case at begining of words in v4l2_ctrl_get_name()

version 4:
  - patchset 3 review from Nicolas Dufresne
- one attribute per line in structure
  - fix some multilines comments

version 3:
  - fix warning on parisc architecture

version 2:
  - rebase on top of DELTA v7, refer to [0]
  - change VIDEO_STI_DELTA_DRIVER to default=y as per Mauro recommendations

version 1:
  - Initial submission

===
= v4l2-compliance =
===
Below is the v4l2-compliance report, v4l2-compliance has been build from SHA1:
003f31e59f353b4aecc82e8fb1c7555964da7efa (v4l2-compliance: allow S_SELECTION to 
return ENOTTY)

root@sti-4:~# v4l2-compliance -d /dev/video3
v4l2-compliance SHA   : 003f31e59f353b4aecc82e8fb1c7555964da7efa


root@sti-lts:~# v4l2-compliance -d /dev/video3 
v4l2-compliance SHA   : not available

Driver Info:
Driver name   : st-delta
Card type : st-delta-21.1-3
Bus info  : platform:soc:delta0
Driver version: 4.9.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/video3 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

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

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (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
  

Re: [PATCH] [media] Order the Makefile alphabetically

[Maxime Ripard]

On Wed, Apr 19, 2017 at 08:15:45AM -0300, Mauro Carvalho Chehab wrote:
> Em Thu,  6 Apr 2017 16:40:51 +0200
> Maxime Ripard  escreveu:
> 
> > The Makefiles were a free for all without a clear order defined. Sort all 
> > the
> > options based on the Kconfig symbol.
> > 
> > Signed-off-by: Maxime Ripard 
> > 
> > ---
> > 
> > Hi Mauro,
> > 
> > Here is my makefile ordering patch again, this time with all the Makefiles
> > in drivers/media that needed ordering.
> > 
> > Since we're already pretty late in the release period, I guess there won't
> > be any major conflicts between now and the merge window.
> > 
> 
> The thing with patches like that is that they almost never apply fine.
> By the time I review such patches, it was already broken. Also,
> once applied, it breaks for everybody that have pending work to merge.
> 
> This patch is broken (see attached).
> 
> So, I prefer not applying stuff like that.

I had the feeling that now would have been a good time to merge it,
since all the PR should be merged I guess. But ok.

Maxime

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


signature.asc
Description: PGP signature

Re: HauppaugeTV-quadHD DVB-T mpeg risc op code errors

[Steven Toth]

> Just a follow up on this. I had a bit more time to dig deeper into this today.
>
> Enabling debug output for the cx23885 driver *fixes* the issue.
>
> I added this to my kernel command line: cx23885.debug=8

The driver's been around a very long time and is very stable with
almost anything anyone has every added, or I originally added during
the early development. That being said. this sounds like the quad
is producing some kind of race condition, or the PLX bridge is in
someway not as transparent as everyone would like.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: [PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats

[ayaka]

On 04/18/2017 03:33 AM, Mauro Carvalho Chehab wrote:

Em Sun,  5 Mar 2017 18:00:32 +0800
Randy Li  escreveu:


The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format.

Also a variant of V4L2_PIX_FMT_P010M pixel format is added.
The V4L2_PIX_FMT_P010CM is a compat variant of the V4L2_PIX_FMT_P010,
Some developers from Gstreamer think it should be renamed as CM10 for 
the P010CM, I don't have much idea about that.

which uses the unused 6 bits to store the next pixel. And with
the alignment requirement of the hardware, it usually would be
some extra space left at the end of a stride.

You should check your patches with checkpatch... I'm getting
this:


WARNING: 'simliar' may be misspelled - perhaps 'similar'?
#61: FILE: Documentation/media/uapi/v4l/pixfmt-p010.rst:13:
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``

I am sorry about that



WARNING: 'simliar' may be misspelled - perhaps 'similar'?
#334: FILE: Documentation/media/uapi/v4l/pixfmt-p016.rst:13:
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``



Signed-off-by: Randy Li 
---
  Documentation/media/uapi/v4l/pixfmt-p010.rst  | 126 
  Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++
  Documentation/media/uapi/v4l/pixfmt-p016.rst  | 125 
  Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 +
  Documentation/media/uapi/v4l/yuv-formats.rst  |   4 +
  include/uapi/linux/videodev2.h|   5 +
  6 files changed, 529 insertions(+)
  create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
  create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
  create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
  create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst 
b/Documentation/media/uapi/v4l/pixfmt-p010.rst
new file mode 100644
index 000..59ed118
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst
@@ -0,0 +1,126 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010:
+
+**
+V4L2_PIX_FMT_P010 ('P010')
+**
+
+
+V4L2_PIX_FMT_P010
+Formats with ½ horizontal and vertical chroma resolution. One luminance and
+one chrominance plane with alternating
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``

It is probably ok to use the UTF symbol for 1/2, but you should check
if both PDF and HTML outputs will be ok.

I see, I would upload a new version later



+
+
+Description
+===
+
+It is a two-plane versions of the YUV 4:2:0 format. The three
+components are separated into two sub-images or planes. The Y plane is
+first. The Y plane has 16 bits per pixel, but only 10 bits are used with the
+rest 6 bits set to zero. For ``V4L2_PIX_FMT_P010``, a combined CbCr plane
+immediately follows the Y plane in memory. The CbCr
+plane is the same width, in bytes, as the Y plane (and of the image),
+but is half as tall in pixels. Each CbCr pair belongs to four pixels.
+For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
+Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+**Byte Order.**
+Each cell is two bytes.
+
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* - start + 0:
+  - Y'\ :sub:`00`
+  - Y'\ :sub:`01`
+  - Y'\ :sub:`02`
+  - Y'\ :sub:`03`
+* - start + 4:
+  - Y'\ :sub:`10`
+  - Y'\ :sub:`11`
+  - Y'\ :sub:`12`
+  - Y'\ :sub:`13`
+* - start + 8:
+  - Y'\ :sub:`20`
+  - Y'\ :sub:`21`
+  - Y'\ :sub:`22`
+  - Y'\ :sub:`23`
+* - start + 12:
+  - Y'\ :sub:`30`
+  - Y'\ :sub:`31`
+  - Y'\ :sub:`32`
+  - Y'\ :sub:`33`
+* - start + 16:
+  - Cb\ :sub:`00`
+  - Cr\ :sub:`00`
+  - Cb\ :sub:`01`
+  - Cr\ :sub:`01`
+* - start + 20:
+  - Cb\ :sub:`10`
+  - Cr\ :sub:`10`
+  - Cb\ :sub:`11`
+  - Cr\ :sub:`11`
+
+
+**Color Sample Location..**
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* -
+  - 0
+  -
+  - 1
+  - 2
+  -
+  - 3
+* - 0
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+  -
+  - C
+  -
+  -
+  - C
+  -
+* - 1
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+* - 2
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+  -
+  - C
+  -
+  -
+  - C
+  -
+* - 3
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst 
b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
new file mode 

[PATCH] [media] cec: improve MEDIA_CEC_RC dependencies

[Arnd Bergmann]

Changing the IS_REACHABLE() into a plain #ifdef broke the case of
CONFIG_MEDIA_RC=m && CONFIG_MEDIA_CEC=y:

drivers/media/cec/cec-core.o: In function `cec_unregister_adapter':
cec-core.c:(.text.cec_unregister_adapter+0x18): undefined reference to 
`rc_unregister_device'
drivers/media/cec/cec-core.o: In function `cec_delete_adapter':
cec-core.c:(.text.cec_delete_adapter+0x54): undefined reference to 
`rc_free_device'
drivers/media/cec/cec-core.o: In function `cec_register_adapter':
cec-core.c:(.text.cec_register_adapter+0x94): undefined reference to 
`rc_register_device'
cec-core.c:(.text.cec_register_adapter+0xa4): undefined reference to 
`rc_free_device'
cec-core.c:(.text.cec_register_adapter+0x110): undefined reference to 
`rc_unregister_device'
drivers/media/cec/cec-core.o: In function `cec_allocate_adapter':
cec-core.c:(.text.cec_allocate_adapter+0x234): undefined reference to 
`rc_allocate_device'
drivers/media/cec/cec-adap.o: In function `cec_received_msg':
cec-adap.c:(.text.cec_received_msg+0x734): undefined reference to `rc_keydown'
cec-adap.c:(.text.cec_received_msg+0x768): undefined reference to `rc_keyup'

This adds an additional dependency to explicitly forbid this combination.

Fixes: 5f2c467c54f5 ("[media] cec: add MEDIA_CEC_RC config option")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/cec/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/cec/Kconfig b/drivers/media/cec/Kconfig
index f944d93e3167..488fb908244d 100644
--- a/drivers/media/cec/Kconfig
+++ b/drivers/media/cec/Kconfig
@@ -9,6 +9,7 @@ config MEDIA_CEC_NOTIFIER
 config MEDIA_CEC_RC
bool "HDMI CEC RC integration"
depends on CEC_CORE && RC_CORE
+   depends on CEC_CORE=m || RC_CORE=y
---help---
  Pass on CEC remote control messages to the RC framework.
 
-- 
2.9.0

[PATCH] [media] rainshadow-cec: avoid -Wmaybe-uninitialized warning

[Arnd Bergmann]

The barrier implied by spin_unlock() in rain_irq_work_handler makes it hard
for gcc to figure out the state of the variables, leading to a false-positive
warning:

drivers/media/usb/rainshadow-cec/rainshadow-cec.c: In function 
'rain_irq_work_handler':
drivers/media/usb/rainshadow-cec/rainshadow-cec.c:171:31: error: 'data' may be 
used uninitialized in this function [-Werror=maybe-uninitialized]

Slightly rearranging the code makes it easier for the compiler to see that the
code is correct, and gets rid of the warning.

Fixes: 0f314f6c2e77 ("[media] rainshadow-cec: new RainShadow Tech HDMI CEC 
driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/rainshadow-cec/rainshadow-cec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c 
b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
index dc1f64f904cd..9ddd6a99f066 100644
--- a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
+++ b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
@@ -123,11 +123,12 @@ static void rain_irq_work_handler(struct work_struct 
*work)
char data;
 
spin_lock_irqsave(>buf_lock, flags);
-   exit_loop = rain->buf_len == 0;
if (rain->buf_len) {
data = rain->buf[rain->buf_rd_idx];
rain->buf_len--;
rain->buf_rd_idx = (rain->buf_rd_idx + 1) & 0xff;
+   } else {
+   exit_loop = true;
}
spin_unlock_irqrestore(>buf_lock, flags);
 
-- 
2.9.0

[PATCH 2/2] staging: atomisp: remove #ifdef for runtime PM functions

[Arnd Bergmann]

The runtime power management functions are called from the reset handler even
if CONFIG_PM is disabled, leading to a link error:

drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd1c): undefined reference to `atomisp_runtime_suspend'
drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd3a): undefined reference to `atomisp_mrfld_power_down'
drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd58): undefined reference to `atomisp_mrfld_power_up'
drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd77): undefined reference to `atomisp_runtime_resume'

Removing the #ifdef around the PM functions avoids the problem, and
lets us simplify it further. The __maybe_unused annotation is needed
to ensure the compiler can silently drop the unused callbacks.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 9bd186bad1bd..9b4508e731f3 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -310,7 +310,6 @@ static int __maybe_unused atomisp_restore_iunit_reg(struct 
atomisp_device *isp)
return 0;
 }
 
-#ifdef CONFIG_PM
 static int atomisp_mrfld_pre_power_down(struct atomisp_device *isp)
 {
struct pci_dev *dev = isp->pdev;
@@ -550,7 +549,7 @@ int atomisp_runtime_resume(struct device *dev)
return 0;
 }
 
-static int atomisp_suspend(struct device *dev)
+static int __maybe_unused atomisp_suspend(struct device *dev)
 {
struct atomisp_device *isp = (struct atomisp_device *)
dev_get_drvdata(dev);
@@ -588,7 +587,7 @@ static int atomisp_suspend(struct device *dev)
return atomisp_mrfld_power_down(isp);
 }
 
-static int atomisp_resume(struct device *dev)
+static int __maybe_unused atomisp_resume(struct device *dev)
 {
struct atomisp_device *isp = (struct atomisp_device *)
dev_get_drvdata(dev);
@@ -614,7 +613,6 @@ static int atomisp_resume(struct device *dev)
atomisp_freq_scaling(isp, ATOMISP_DFS_MODE_LOW, true);
return 0;
 }
-#endif
 
 int atomisp_csi_lane_config(struct atomisp_device *isp)
 {
@@ -1576,7 +1574,6 @@ static const struct pci_device_id atomisp_pci_tbl[] = {
 
 MODULE_DEVICE_TABLE(pci, atomisp_pci_tbl);
 
-#ifdef CONFIG_PM
 static const struct dev_pm_ops atomisp_pm_ops = {
.runtime_suspend = atomisp_runtime_suspend,
.runtime_resume = atomisp_runtime_resume,
@@ -1584,14 +1581,9 @@ static const struct dev_pm_ops atomisp_pm_ops = {
.resume = atomisp_resume,
 };
 
-#define DEV_PM_OPS (_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif
-
 static struct pci_driver atomisp_pci_driver = {
.driver = {
-   .pm = DEV_PM_OPS,
+   .pm = _pm_ops,
},
.name = "atomisp-isp2",
.id_table = atomisp_pci_tbl,
-- 
2.9.0

[PATCH 1/2] staging: atomisp: satm include directory is gone

[Arnd Bergmann]

After the satm kernel was removed, we should no longer add the directory
to the search path. This was found with a 'make W=1' warning:

cc1: error: 
drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/satm/: No such 
file or directory [-Werror=missing-include-dirs]

Fixes: 184f8e0981ef ("atomisp: remove satm kernel")
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/media/atomisp/pci/atomisp2/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/Makefile 
b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
index 96a7bd0fa96e..5e8646c976a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile
+++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
@@ -301,7 +301,6 @@ INCLUDES += \
-I$(atomisp)/css2400/isp/kernels/s3a/ \
-I$(atomisp)/css2400/isp/kernels/s3a/s3a_1.0/ \
-I$(atomisp)/css2400/isp/kernels/s3a_stat_ls/ \
-   -I$(atomisp)/css2400/isp/kernels/satm/ \
-I$(atomisp)/css2400/isp/kernels/scale/ \
-I$(atomisp)/css2400/isp/kernels/scale/scale_1.0/ \
-I$(atomisp)/css2400/isp/kernels/sc/ \
-- 
2.9.0

[RFC 0/2] Synopsys Designware HDMI Video Capture Controller + PHY

[Jose Abreu]

Hi All,

This is a RFC series that is intended to collect comments regarding the
Synopsys Designware HDMI RX controller and Synopsys Designware HDMI RX e405 PHY
drivers.

The Synopsys Designware HDMI RX controller is an HDMI receiver controller that
is responsible to process digital data that comes from a phy. The final result
is a stream of raw video data that can then be connected to a video DMA, for
example, and transfered into RAM so that it can be displayed.

The controller + phy available in this series natively support all HDMI 1.4 and
HDMI 2.0 modes, including deep color. Although, the driver is quite in its
initial stage and unfortunatelly only non deep color modes are supported. Also,
audio is not yet supported in the driver (the controller has several audio
output interfaces).

Feel free to take a look at this series and please leave a comment! I can
expand a little bit more about design decisions and would like to know wether
these were the best choices.

With best regards,
Jose Miguel Abreu

Jose Abreu (2):
  [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver
  [media] platform: Add Synopsys Designware HDMI RX Controller Driver

Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: linux-ker...@vger.kernel.org
Cc: linux-media@vger.kernel.org

 drivers/media/platform/Kconfig|2 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/dwc/Kconfig|   17 +
 drivers/media/platform/dwc/Makefile   |2 +
 drivers/media/platform/dwc/dw-hdmi-phy-e405.c |  879 
 drivers/media/platform/dwc/dw-hdmi-phy-e405.h |   63 ++
 drivers/media/platform/dwc/dw-hdmi-rx.c   | 1396 +
 drivers/media/platform/dwc/dw-hdmi-rx.h   |  313 ++
 include/media/dwc/dw-hdmi-phy-pdata.h |   64 ++
 include/media/dwc/dw-hdmi-rx-pdata.h  |   50 +
 10 files changed, 2788 insertions(+)
 create mode 100644 drivers/media/platform/dwc/Kconfig
 create mode 100644 drivers/media/platform/dwc/Makefile
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h
 create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h
 create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h

-- 
1.9.1

[RFC 1/2] [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver

[Jose Abreu]

This adds support for the Synopsys Designware HDMI RX PHY e405. This
phy receives and decodes HDMI video that is delivered to a controller.

Main features included in this driver are:
- Equalizer algorithm that chooses the phy best settings
according to the detected HDMI cable characteristics.
- Support for scrambling
- Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz).

The driver was implemented as a standalone V4L2 subdevice and the
phy interface with the controller was implemented using V4L2 ioctls. I
do not know if this is the best option but it is not possible to use the
existing API functions directly as we need specific functions that will
be called by the controller at specific configuration stages.

There is also a bidirectional communication between controller and phy:
The phy must provide functions that the controller will call (i.e.
configuration functions) and the controller must provide read/write
callbacks, as well as other specific functions.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: linux-ker...@vger.kernel.org
Cc: linux-media@vger.kernel.org
---
 drivers/media/platform/Kconfig|   2 +
 drivers/media/platform/Makefile   |   2 +
 drivers/media/platform/dwc/Kconfig|   8 +
 drivers/media/platform/dwc/Makefile   |   1 +
 drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 879 ++
 drivers/media/platform/dwc/dw-hdmi-phy-e405.h |  63 ++
 include/media/dwc/dw-hdmi-phy-pdata.h |  64 ++
 7 files changed, 1019 insertions(+)
 create mode 100644 drivers/media/platform/dwc/Kconfig
 create mode 100644 drivers/media/platform/dwc/Makefile
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h
 create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ac026ee..5178229 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -33,6 +33,8 @@ source "drivers/media/platform/omap/Kconfig"
 
 source "drivers/media/platform/blackfin/Kconfig"
 
+source "drivers/media/platform/dwc/Kconfig"
+
 config VIDEO_SH_VOU
tristate "SuperH VOU video output driver"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d6..50bc148 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -77,3 +77,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)   += mtk-vcodec/
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
+
+obj-y  += dwc/
diff --git a/drivers/media/platform/dwc/Kconfig 
b/drivers/media/platform/dwc/Kconfig
new file mode 100644
index 000..361d38d
--- /dev/null
+++ b/drivers/media/platform/dwc/Kconfig
@@ -0,0 +1,8 @@
+config VIDEO_DWC_HDMI_PHY_E405
+   tristate "Synopsys Designware HDMI RX PHY e405 driver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   help
+ Support for Synopsys Designware HDMI RX PHY. Version is e405.
+
+ To compile this driver as a module, choose M here. The module
+ will be called dw-hdmi-phy-e405.
diff --git a/drivers/media/platform/dwc/Makefile 
b/drivers/media/platform/dwc/Makefile
new file mode 100644
index 000..fc3b62c
--- /dev/null
+++ b/drivers/media/platform/dwc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o
diff --git a/drivers/media/platform/dwc/dw-hdmi-phy-e405.c 
b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c
new file mode 100644
index 000..dc00677
--- /dev/null
+++ b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c
@@ -0,0 +1,879 @@
+/*
+ * Synopsys Designware HDMI PHY E405 driver
+ *
+ * This Synopsys dw-phy-e405 software and associated documentation
+ * (hereinafter the "Software") is an unsupported proprietary work of
+ * Synopsys, Inc. unless otherwise expressly agreed to in writing between
+ * Synopsys and you. The Software IS NOT an item of Licensed Software or a
+ * Licensed Product under any End User Software License Agreement or
+ * Agreement for Licensed Products with Synopsys or any supplement thereto.
+ * Synopsys is a registered trademark of Synopsys, Inc. Other names included
+ * in the SOFTWARE may be the trademarks of their respective owners.
+ *
+ * The contents of this file are dual-licensed; you may select either version 2
+ * of the GNU General Public License (“GPL”) or the MIT license (“MIT”).
+ *
+ * Copyright (c) 2017 Synopsys, Inc. and/or its affiliates.
+ *
+ * THIS SOFTWARE IS PROVIDED "AS IS"  WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING, BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. IN NO EVENT 

[RFC 2/2] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Jose Abreu]

This is an initial submission for the Synopsys Designware HDMI RX
Controller Driver. This driver interacts with a phy driver so that
a communication between them is created and a video pipeline is
configured.

The controller + phy pipeline can then be integrated into a fully
featured system that can be able to receive video up to 4k@60Hz
with deep color 48bit RGB, depending on the platform. Althoug,
this initial version does not yet handle deep color modes.

This driver was implemented as a standard V4L2 subdevice and its
main features are:
- Internal state machine that reconfigures phy until the
video is not stable
- JTAG communication with phy
- Inter-module communication with phy driver
- Debug write/read ioctls

Some notes:
- RX sense controller (cable connection/disconnection) must
be handled by the platform wrapper as this is not integrated
into the controller RTL
- The same goes for EDID ROM's
- ZCAL calibration is needed only in FPGA platforms, in ASIC
this is not needed
- The state machine is not an ideal solution as it creates a
kthread but it is needed because some sources might not be
very stable at sending the video (i.e. we must react
accordingly).

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: linux-ker...@vger.kernel.org
Cc: linux-media@vger.kernel.org
---
 drivers/media/platform/dwc/Kconfig  |9 +
 drivers/media/platform/dwc/Makefile |1 +
 drivers/media/platform/dwc/dw-hdmi-rx.c | 1396 +++
 drivers/media/platform/dwc/dw-hdmi-rx.h |  313 +++
 include/media/dwc/dw-hdmi-rx-pdata.h|   50 ++
 5 files changed, 1769 insertions(+)
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h
 create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h

diff --git a/drivers/media/platform/dwc/Kconfig 
b/drivers/media/platform/dwc/Kconfig
index 361d38d..11efa23 100644
--- a/drivers/media/platform/dwc/Kconfig
+++ b/drivers/media/platform/dwc/Kconfig
@@ -6,3 +6,12 @@ config VIDEO_DWC_HDMI_PHY_E405
 
  To compile this driver as a module, choose M here. The module
  will be called dw-hdmi-phy-e405.
+
+config VIDEO_DWC_HDMI_RX
+   tristate "Synopsys Designware HDMI Receiver driver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   help
+ Support for Synopsys Designware HDMI RX controller.
+
+ To compile this driver as a module, choose M here. The module
+ will be called dw-hdmi-rx.
diff --git a/drivers/media/platform/dwc/Makefile 
b/drivers/media/platform/dwc/Makefile
index fc3b62c..cd04ca9 100644
--- a/drivers/media/platform/dwc/Makefile
+++ b/drivers/media/platform/dwc/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o
+obj-$(CONFIG_VIDEO_DWC_HDMI_RX) += dw-hdmi-rx.o
diff --git a/drivers/media/platform/dwc/dw-hdmi-rx.c 
b/drivers/media/platform/dwc/dw-hdmi-rx.c
new file mode 100644
index 000..6bfbc86
--- /dev/null
+++ b/drivers/media/platform/dwc/dw-hdmi-rx.c
@@ -0,0 +1,1396 @@
+/*
+ * Synopsys Designware HDMI Receiver controller driver
+ *
+ * This Synopsys dw-hdmi-rx software and associated documentation
+ * (hereinafter the "Software") is an unsupported proprietary work of
+ * Synopsys, Inc. unless otherwise expressly agreed to in writing between
+ * Synopsys and you. The Software IS NOT an item of Licensed Software or a
+ * Licensed Product under any End User Software License Agreement or
+ * Agreement for Licensed Products with Synopsys or any supplement thereto.
+ * Synopsys is a registered trademark of Synopsys, Inc. Other names included
+ * in the SOFTWARE may be the trademarks of their respective owners.
+ *
+ * The contents of this file are dual-licensed; you may select either version 2
+ * of the GNU General Public License (“GPL”) or the MIT license (“MIT”).
+ *
+ * Copyright (c) 2017 Synopsys, Inc. and/or its affiliates.
+ *
+ * THIS SOFTWARE IS PROVIDED "AS IS"  WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING, BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE
+ * ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "dw-hdmi-rx.h"
+
+#define HDMI_DEFAULT_TIMINGV4L2_DV_BT_CEA_640X480P59_94
+
+MODULE_AUTHOR("Carlos Palminha ");
+MODULE_AUTHOR("Jose 

Re: [PATCH] media: mtk-vcodec: remove informative log

[Tiffany Lin]

On Wed, 2017-04-19 at 07:56 -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 5 Apr 2017 19:09:59 +0800
> Tiffany Lin  escreveu:
> 
> > On Wed, 2017-04-05 at 18:54 +0800, Minghsiu Tsai wrote:
> > > Driver is stable. Remove DEBUG definition from driver.
> > > 
> > > There are debug message in /var/log/messages if DEBUG is defined,
> > > such as:
> > > [MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
> > > [MTK_V4L2] level=0 fops_vcodec_open(),177: 1600.vcodec decoder [0]
> > > [MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder
> > > 
> > > Signed-off-by: Minghsiu Tsai   
> > Acked-by:Tiffany Lin 
> > 
> > > ---
> > >  drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 1 -
> > >  1 file changed, 1 deletion(-)
> > > 
> > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
> > > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > index 7d55975..1248083 100644
> > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > @@ -31,7 +31,6 @@ struct mtk_vcodec_mem {
> > >  extern int mtk_v4l2_dbg_level;
> > >  extern bool mtk_vcodec_dbg;
> > >  
> > > -#define DEBUG1
> > >  
> > >  #if defined(DEBUG)
> > >
> 
> After this patch, building the Kernel with W=1 now shows warnings:
> 
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 
> 'mtk_vcodec_dec_pw_on':
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: 
> suggest braces around empty body in an 'if' statement [-Wempty-body]
>mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
>^
> 
> I wrote a patch fixing it, as this is really a trivial issue.
> 
> Yet, after that, this one still remains:
> 
> 
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: In function 
> 'mtk_vdec_pic_info_update':
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:284:6: warning: variable 
> 'ret' set but not used [-Wunused-but-set-variable]
>   int ret;
>   ^~~
> 


> 
> Shouldn't be mtk_vdec_pic_info_update() returning an error code?
> 
> 
> Also, IMHO, at least errors should be shown at dmesg.
> 
Got it. We will upstream patch to fix warning and add dmesg when error.


best regards,
Tiffany

> Thanks,
> Mauro

Re: [PATCH] [media] mtk-vcodec: avoid warnings because of empty macros

[Tiffany Lin]

On Wed, 2017-04-19 at 07:56 -0300, Mauro Carvalho Chehab wrote:
> Remove those gcc warnings:
> 
>   drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 
> 'mtk_vcodec_dec_pw_on':
>   drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: 
> suggest braces around empty body in an 'if' statement [-Wempty-body]
>  mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
>  ^
> 
> By adding braces.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> index 12480837ff2e..237e144c194f 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> @@ -66,15 +66,15 @@ extern bool mtk_vcodec_dbg;
>  
>  #else
>  
> -#define mtk_v4l2_debug(level, fmt, args...)
> -#define mtk_v4l2_err(fmt, args...)
> -#define mtk_v4l2_debug_enter()
> -#define mtk_v4l2_debug_leave()
> +#define mtk_v4l2_debug(level, fmt, args...) {}
> +#define mtk_v4l2_err(fmt, args...) {}
> +#define mtk_v4l2_debug_enter() {}
> +#define mtk_v4l2_debug_leave() {}
>  
> -#define mtk_vcodec_debug(h, fmt, args...)
> -#define mtk_vcodec_err(h, fmt, args...)
> -#define mtk_vcodec_debug_enter(h)
> -#define mtk_vcodec_debug_leave(h)
> +#define mtk_vcodec_debug(h, fmt, args...) {}
> +#define mtk_vcodec_err(h, fmt, args...) {}
> +#define mtk_vcodec_debug_enter(h) {}
> +#define mtk_vcodec_debug_leave(h) {}
>  
>  #endif
>  

Acked-by: Tiffany Lin 

Re: [PATCH] [media] ov2640: make GPIOLIB an optional dependency

[Pavel Machek]

Hi!

> > Better solution would be for VIDEO_EM28XX_V4L2 to depend on GPIOLIB,
> > too, no? If not, should there be BUG_ON(priv->pwdn_gpio);
> > BUG_ON(priv->resetb_gpio);?
> 
> Pavel,
> 
> The em28xx driver was added upstream several years the gpio driver. 
> It controls GPIO using a different logic. It makes no sense to make
> it dependent on GPIOLIB, except if someone converts it to use it.

At least comment in the sourcecode...? Remove pwdn_gpio fields from
structure in !GPIOLIB case, because otherwise they are trap for the
programmer trying to understand what is going on?

Plus, something like this, because otherwise it is quite confusing?

Thanks,
Pavel

diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
b/drivers/media/i2c/soc_camera/ov2640.c
index 56de182..85620e1 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -1060,7 +1060,7 @@ static int ov2640_hw_reset(struct device *dev)
/* Active the resetb pin to perform a reset pulse */
gpiod_direction_output(priv->resetb_gpio, 1);
usleep_range(3000, 5000);
-   gpiod_direction_output(priv->resetb_gpio, 0);
+   gpiod_set_value(priv->resetb_gpio, 0);
}
 
return 0;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature