cron job: media_tree daily build: ERRORS
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
Em Fri, 21 Apr 2017 14:09:37 -0400 Devin Heitmuellerescreveu: > >> 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]
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
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
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 HeitmuellerReported-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
>> 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
Em Fri, 21 Apr 2017 08:33:12 +0200 Pavel Machekescreveu: > 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
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
Hi Devin, Em Wed, 19 Apr 2017 15:15:20 -0400 Devin Heitmuellerescreveu: > 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
Em Fri, 21 Apr 2017 16:41:25 +0200 Maxime Ripardescreveu: > 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
Hi Laura, Thanks much for this series! On 18 April 2017 at 23:57, Laura Abbottwrote: > 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
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
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
On Wed, Apr 19, 2017 at 08:15:45AM -0300, Mauro Carvalho Chehab wrote: > Em Thu, 6 Apr 2017 16:40:51 +0200 > Maxime Ripardescreveu: > > > 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
> 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
On 04/18/2017 03:33 AM, Mauro Carvalho Chehab wrote: Em Sun, 5 Mar 2017 18:00:32 +0800 Randy Liescreveu: 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
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
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
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
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
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 PalminhaCc: 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
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 AbreuCc: 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
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 AbreuCc: 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
On Wed, 2017-04-19 at 07:56 -0300, Mauro Carvalho Chehab wrote: > Em Wed, 5 Apr 2017 19:09:59 +0800 > Tiffany Linescreveu: > > > 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
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
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