Re: VIVID/VIMC and media fuzzing
On Fri, Dec 7, 2018 at 8:22 PM Helen Koike wrote: > >>> You also mentioned that one of the devices requires some complex setup > >>> via configfs. Is this interface described somewhere? Do you think it's > >>> more profitable to pre-setup some fixed configuration for each test > >>> process? Or just give the setup interface to fuzzer and let it do > >>> random setup? Or both? > >> > >> That's the vimc driver, but the configfs code isn't in yet. > > > > I'll try to submit it later this week (with documentation) :) > > I submitted the first version at: > https://www.spinics.net/lists/linux-media/msg144244.html > As soon as it is updated we can add it to fuzzer. I believe some > pre-setup/fixed configuration would work. > > I don't know much about fuzzer's code, if you could give me some > pointers I can help with that. Hi Helen, Great! It may be easier to think about this on 2 levels: The first is _what_ we want to do. For this, imagine you are writing a stress test for the subsystem as a C program that does some fixed setup and then executes random syscalls related to the subsystem and acting on the devices using rand() to select syscalls and arguments. What setup would you do for this? What syscalls would you issue? The second is then how to fit this into syzkaller. The setup part in syzkaller is also just custom C code. E.g. this setups network devices for test process: https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L154-L301 There is a little bit of trickery because this code is also used to generate C reproducers for crashes, and it also needs to preferably support multiple independent test processes (namely this code has procid=0..N variable and needs to setup e.g. /dev/loopN device corresponding to current procid). E.g. for vivid we use "vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2". But overall it's just C code. For the main stress/fuzzing we have these declarative descriptions, which are hopefully mostly self-explanatory: https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt If there is something missing, we need to add missing parts. And maybe even give fuzzer the configfs interface too to mess with (it can open specified files and do, say, writes with complex inputs, both binary and text based). Also, will we gain something by enabling the following ones inside of a VM: # CONFIG_V4L_PLATFORM_DRIVERS is not set # CONFIG_V4L_MEM2MEM_DRIVERS is not set ? Or, it's just physical hardware drivers? FTR, here are configs that syzbot uses: https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-kasan.config https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-selinux.cmdline https://github.com/google/syzkaller/blob/master/dashboard/config/upstream.sysctl Thanks
Re: [PATCH 2/3] media: ov2640: make VIDIOC_SUBDEV_G_FMT ioctl work with V4L2_SUBDEV_FORMAT_TRY
Hi Akinobu,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.20-rc5 next-20181207]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Akinobu-Mita/media-ov2640-fix-two-problems/20181208-165345
base: git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-x011-201848 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers/media//i2c/ov2640.c: In function 'ov2640_get_fmt':
>> drivers/media//i2c/ov2640.c:930:8: error: implicit declaration of function
>> 'v4l2_subdev_get_try_format'; did you mean 'v4l2_subdev_notify_event'?
>> [-Werror=implicit-function-declaration]
mf = v4l2_subdev_get_try_format(sd, cfg, 0);
^~
v4l2_subdev_notify_event
>> drivers/media//i2c/ov2640.c:930:6: warning: assignment makes pointer from
>> integer without a cast [-Wint-conversion]
mf = v4l2_subdev_get_try_format(sd, cfg, 0);
^
drivers/media//i2c/ov2640.c: In function 'ov2640_init_cfg':
>> drivers/media//i2c/ov2640.c:1007:3: warning: initialization makes pointer
>> from integer without a cast [-Wint-conversion]
v4l2_subdev_get_try_format(sd, cfg, 0);
^~
cc1: some warnings being treated as errors
vim +930 drivers/media//i2c/ov2640.c
917
918 static int ov2640_get_fmt(struct v4l2_subdev *sd,
919 struct v4l2_subdev_pad_config *cfg,
920 struct v4l2_subdev_format *format)
921 {
922 struct v4l2_mbus_framefmt *mf = >format;
923 struct i2c_client *client = v4l2_get_subdevdata(sd);
924 struct ov2640_priv *priv = to_ov2640(client);
925
926 if (format->pad)
927 return -EINVAL;
928
929 if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
> 930 mf = v4l2_subdev_get_try_format(sd, cfg, 0);
931 format->format = *mf;
932
933 return 0;
934 }
935
936 mf->width = priv->win->width;
937 mf->height = priv->win->height;
938 mf->code= priv->cfmt_code;
939 mf->colorspace = V4L2_COLORSPACE_SRGB;
940 mf->field = V4L2_FIELD_NONE;
941
942 return 0;
943 }
944
945 static int ov2640_set_fmt(struct v4l2_subdev *sd,
946 struct v4l2_subdev_pad_config *cfg,
947 struct v4l2_subdev_format *format)
948 {
949 struct v4l2_mbus_framefmt *mf = >format;
950 struct i2c_client *client = v4l2_get_subdevdata(sd);
951 struct ov2640_priv *priv = to_ov2640(client);
952 const struct ov2640_win_size *win;
953 int ret = 0;
954
955 if (format->pad)
956 return -EINVAL;
957
958 mutex_lock(>lock);
959
960 /* select suitable win */
961 win = ov2640_select_win(mf->width, mf->height);
962 mf->width = win->width;
963 mf->height = win->height;
964
965 mf->field = V4L2_FIELD_NONE;
966 mf->colorspace = V4L2_COLORSPACE_SRGB;
967
968 switch (mf->code) {
969 case MEDIA_BUS_FMT_RGB565_2X8_BE:
970 case MEDIA_BUS_FMT_RGB565_2X8_LE:
971 case MEDIA_BUS_FMT_YUYV8_2X8:
972 case MEDIA_BUS_FMT_UYVY8_2X8:
973 case MEDIA_BUS_FMT_YVYU8_2X8:
974 case MEDIA_BUS_FMT_VYUY8_2X8:
975 break;
976 default:
977 mf->code = MEDIA_BUS_FMT_UYVY8_2X8;
978 break;
979 }
980
981 if (format->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
982 struct ov2640_priv *priv = to_ov2640(client);
983
984 if (priv->streaming) {
985 ret = -EBUSY;
986 goto out;
987 }
988 /* select win */
989 priv->win = win;
990 /* select format */
991 priv->cfmt_code = mf->code;
992 } else {
993 cfg->try_fmt = *mf;
994 }
995 out:
996 mutex_unlock(>lock);
997
998 return ret;
999 }
1000
1001 static int ov2640_init_cfg(struct v4l2_subdev *sd,
1002 struct v4l2_subdev_pad_config *cfg)
1003 {
1004 struct i2c_client *client = v4l2_get_subdevdata(sd);
1005 struct ov2640_priv *priv = to_ov2640(client);
1006
[PATCH 1/3] media: ov2640: set default window and format code at probe time
Set default window and format code at probe time instead of always checking
if they have not been set yet when VIDIOC_SUBDEV_G_FMT ioctl is called.
This change simplifies the next patch (make VIDIOC_SUBDEV_G_FMT ioctl work
with V4L2_SUBDEV_FORMAT_TRY).
Cc: Sakari Ailus
Cc: Mauro Carvalho Chehab
Signed-off-by: Akinobu Mita
---
drivers/media/i2c/ov2640.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index d8e91bc..a07e6f2 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -842,9 +842,6 @@ static int ov2640_set_params(struct i2c_client *client,
u8 val;
int ret;
- if (!win)
- return -EINVAL;
-
switch (code) {
case MEDIA_BUS_FMT_RGB565_2X8_BE:
dev_dbg(>dev, "%s: Selected cfmt RGB565 BE", __func__);
@@ -929,10 +926,6 @@ static int ov2640_get_fmt(struct v4l2_subdev *sd,
if (format->pad)
return -EINVAL;
- if (!priv->win) {
- priv->win = ov2640_select_win(SVGA_WIDTH, SVGA_HEIGHT);
- priv->cfmt_code = MEDIA_BUS_FMT_UYVY8_2X8;
- }
mf->width = priv->win->width;
mf->height = priv->win->height;
@@ -1193,6 +1186,9 @@ static int ov2640_probe(struct i2c_client *client,
if (ret)
goto err_clk;
+ priv->win = ov2640_select_win(SVGA_WIDTH, SVGA_HEIGHT);
+ priv->cfmt_code = MEDIA_BUS_FMT_UYVY8_2X8;
+
v4l2_i2c_subdev_init(>subdev, client, _subdev_ops);
priv->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE |
V4L2_SUBDEV_FL_HAS_EVENTS;
--
2.7.4
[PATCH 3/3] media: ov2640: set all mbus format field when G_FMT and S_FMT ioctls
This driver doesn't set all members of mbus format field when the
VIDIOC_SUBDEV_{S,G}_FMT ioctls are called.
This is detected by v4l2-compliance.
Cc: Sakari Ailus
Cc: Mauro Carvalho Chehab
Signed-off-by: Akinobu Mita
---
drivers/media/i2c/ov2640.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 5f888f5..439c6da 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -938,6 +938,9 @@ static int ov2640_get_fmt(struct v4l2_subdev *sd,
mf->code= priv->cfmt_code;
mf->colorspace = V4L2_COLORSPACE_SRGB;
mf->field = V4L2_FIELD_NONE;
+ mf->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
+ mf->quantization = V4L2_QUANTIZATION_DEFAULT;
+ mf->xfer_func = V4L2_XFER_FUNC_DEFAULT;
return 0;
}
@@ -964,6 +967,9 @@ static int ov2640_set_fmt(struct v4l2_subdev *sd,
mf->field = V4L2_FIELD_NONE;
mf->colorspace = V4L2_COLORSPACE_SRGB;
+ mf->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
+ mf->quantization = V4L2_QUANTIZATION_DEFAULT;
+ mf->xfer_func = V4L2_XFER_FUNC_DEFAULT;
switch (mf->code) {
case MEDIA_BUS_FMT_RGB565_2X8_BE:
--
2.7.4
[PATCH 2/3] media: ov2640: make VIDIOC_SUBDEV_G_FMT ioctl work with V4L2_SUBDEV_FORMAT_TRY
The VIDIOC_SUBDEV_G_FMT ioctl for this driver doesn't recognize
V4L2_SUBDEV_FORMAT_TRY and always works as if V4L2_SUBDEV_FORMAT_ACTIVE
is specified.
Cc: Sakari Ailus
Cc: Mauro Carvalho Chehab
Signed-off-by: Akinobu Mita
---
drivers/media/i2c/ov2640.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index a07e6f2..5f888f5 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -926,6 +926,12 @@ static int ov2640_get_fmt(struct v4l2_subdev *sd,
if (format->pad)
return -EINVAL;
+ if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
+ mf = v4l2_subdev_get_try_format(sd, cfg, 0);
+ format->format = *mf;
+
+ return 0;
+ }
mf->width = priv->win->width;
mf->height = priv->win->height;
@@ -992,6 +998,26 @@ static int ov2640_set_fmt(struct v4l2_subdev *sd,
return ret;
}
+static int ov2640_init_cfg(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ov2640_priv *priv = to_ov2640(client);
+ struct v4l2_mbus_framefmt *try_fmt =
+ v4l2_subdev_get_try_format(sd, cfg, 0);
+
+ try_fmt->width = priv->win->width;
+ try_fmt->height = priv->win->height;
+ try_fmt->code = priv->cfmt_code;
+ try_fmt->colorspace = V4L2_COLORSPACE_SRGB;
+ try_fmt->field = V4L2_FIELD_NONE;
+ try_fmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
+ try_fmt->quantization = V4L2_QUANTIZATION_DEFAULT;
+ try_fmt->xfer_func = V4L2_XFER_FUNC_DEFAULT;
+
+ return 0;
+}
+
static int ov2640_enum_mbus_code(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code)
@@ -1101,6 +1127,7 @@ static const struct v4l2_subdev_core_ops
ov2640_subdev_core_ops = {
};
static const struct v4l2_subdev_pad_ops ov2640_subdev_pad_ops = {
+ .init_cfg = ov2640_init_cfg,
.enum_mbus_code = ov2640_enum_mbus_code,
.get_selection = ov2640_get_selection,
.get_fmt= ov2640_get_fmt,
--
2.7.4
[PATCH 0/3] media: ov2640: fix two problems
This patch series contains two bugfixes and a preparatory change for ov2640 driver. Akinobu Mita (3): media: ov2640: set default window and format code at probe time media: ov2640: make VIDIOC_SUBDEV_G_FMT ioctl work with V4L2_SUBDEV_FORMAT_TRY media: ov2640: set all mbus format field when G_FMT and S_FMT ioctls drivers/media/i2c/ov2640.c | 41 +++-- 1 file changed, 35 insertions(+), 6 deletions(-) Cc: Sakari Ailus Cc: Mauro Carvalho Chehab -- 2.7.4
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 Dec 8 05:00:14 CET 2018 media-tree git hash:e159b6074c82fe31b79aad672e02fa204dbbc6d8 media_build git hash: 4b9237c73e29ea969f6a7b3d00030e14be50 v4l-utils git hash: 516595495957cbc18b578e6c1598bec21858b4e5 edid-decode git hash: 6def7bc83dfb0338632e06a8b14c93faa6af8879 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-3-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: ERRORS linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: ERRORS linux-3.10.108-x86_64: ERRORS linux-3.11.10-i686: ERRORS linux-3.11.10-x86_64: ERRORS linux-3.12.74-i686: ERRORS linux-3.12.74-x86_64: ERRORS linux-3.13.11-i686: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.79-i686: ERRORS linux-3.14.79-x86_64: ERRORS linux-3.15.10-i686: ERRORS linux-3.15.10-x86_64: ERRORS linux-3.16.57-i686: ERRORS linux-3.16.57-x86_64: ERRORS linux-3.17.8-i686: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.123-i686: ERRORS linux-3.18.123-x86_64: ERRORS linux-3.19.8-i686: ERRORS linux-3.19.8-x86_64: ERRORS linux-4.0.9-i686: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.52-i686: ERRORS linux-4.1.52-x86_64: ERRORS linux-4.2.8-i686: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-i686: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.159-i686: ERRORS linux-4.4.159-x86_64: ERRORS linux-4.5.7-i686: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-i686: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.10-i686: ERRORS linux-4.7.10-x86_64: ERRORS linux-4.8.17-i686: ERRORS linux-4.8.17-x86_64: ERRORS linux-4.9.131-i686: ERRORS linux-4.9.131-x86_64: ERRORS linux-4.10.17-i686: ERRORS linux-4.10.17-x86_64: ERRORS linux-4.11.12-i686: ERRORS linux-4.11.12-x86_64: ERRORS linux-4.12.14-i686: ERRORS linux-4.12.14-x86_64: ERRORS linux-4.13.16-i686: ERRORS linux-4.13.16-x86_64: ERRORS linux-4.14.74-i686: ERRORS linux-4.14.74-x86_64: ERRORS linux-4.15.18-i686: ERRORS linux-4.15.18-x86_64: ERRORS linux-4.16.18-i686: ERRORS linux-4.16.18-x86_64: ERRORS linux-4.17.19-i686: ERRORS linux-4.17.19-x86_64: ERRORS linux-4.18.12-i686: ERRORS linux-4.18.12-x86_64: ERRORS linux-4.19.1-i686: OK linux-4.19.1-x86_64: OK linux-4.20-rc1-i686: OK linux-4.20-rc1-x86_64: OK apps: OK 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
[PATCH v5 1/1] media: rc: rcmm decoder
media: add support for RCMM infrared remote controls.
Signed-off-by: Patrick Lerda
---
MAINTAINERS| 5 +
drivers/media/rc/Kconfig | 7 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-rcmm-decoder.c | 164 +
drivers/media/rc/rc-core-priv.h| 5 +
drivers/media/rc/rc-main.c | 3 +
include/media/rc-map.h | 6 +-
include/uapi/linux/lirc.h | 2 +
tools/include/uapi/linux/lirc.h| 2 +
9 files changed, 193 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 3e9f1710ed13..80426d1faaba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16277,6 +16277,11 @@ M: David Härdeman
S: Maintained
F: drivers/media/rc/winbond-cir.c
+RCMM REMOTE CONTROLS DECODER
+M: Patrick Lerda
+S: Maintained
+F: drivers/media/rc/ir-rcmm-decoder.c
+
WINSYSTEMS EBC-C384 WATCHDOG DRIVER
M: William Breathitt Gray
L: linux-watch...@vger.kernel.org
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 8a216068a35a..43775ac74268 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -133,6 +133,13 @@ config IR_IMON_DECODER
remote control and you would like to use it with a raw IR
receiver, or if you wish to use an encoder to transmit this IR.
+config IR_RCMM_DECODER
+ tristate "Enable IR raw decoder for the RC-MM protocol"
+ depends on RC_CORE
+ help
+ Enable this option if you have IR with RC-MM protocol, and
+ if the IR is decoded in software
+
endif #RC_DECODERS
menuconfig RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 92c163816849..48d23433b3c0 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
+obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
diff --git a/drivers/media/rc/ir-rcmm-decoder.c
b/drivers/media/rc/ir-rcmm-decoder.c
new file mode 100644
index ..a3c09885da5f
--- /dev/null
+++ b/drivers/media/rc/ir-rcmm-decoder.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0+
+// ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
+//
+// Copyright (C) 2018 by Patrick Lerda
+
+#include "rc-core-priv.h"
+#include
+#include
+
+#define RCMM_UNIT 17 /* nanosecs */
+#define RCMM_PREFIX_PULSE 41 /* 16.6*2.5 */
+#define RCMM_PULSE_027 /* 16.6*(1+2/3) */
+#define RCMM_PULSE_144 /* 16.6*(2+2/3) */
+#define RCMM_PULSE_261 /* 16.6*(3+2/3) */
+#define RCMM_PULSE_378 /* 16.6*(4+2/3) */
+
+enum rcmm_state {
+ STATE_INACTIVE,
+ STATE_LOW,
+ STATE_BUMP,
+ STATE_VALUE,
+ STATE_FINISHED,
+};
+
+static bool rcmm_mode(struct rcmm_dec *data)
+{
+ return !((0x000c & data->bits) == 0x000c);
+}
+
+/**
+ * ir_rcmm_decode() - Decode one RCMM pulse or space
+ * @dev: the struct rc_dev descriptor of the device
+ * @ev:the struct ir_raw_event descriptor of the pulse/space
+ *
+ * This function returns -EINVAL if the pulse violates the state machine
+ */
+static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event ev)
+{
+ struct rcmm_dec *data = >raw->rcmm;
+ u32 scancode;
+ u8 toggle;
+ int value;
+
+ if (!(dev->enabled_protocols & RC_PROTO_BIT_RCMM))
+ return 0;
+
+ if (!is_timing_event(ev)) {
+ if (ev.reset)
+ data->state = STATE_INACTIVE;
+ return 0;
+ }
+
+ if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
+ goto out;
+
+ switch (data->state) {
+ case STATE_INACTIVE:
+ if (!ev.pulse)
+ break;
+
+ if (!eq_margin(ev.duration, RCMM_PREFIX_PULSE, RCMM_UNIT / 2))
+ break;
+
+ data->state = STATE_LOW;
+ data->count = 0;
+ data->bits = 0;
+ return 0;
+
+ case STATE_LOW:
+ if (ev.pulse)
+ break;
+
+ if (!eq_margin(ev.duration, RCMM_PULSE_0, RCMM_UNIT / 2))
+ break;
+
+ data->state = STATE_BUMP;
+ return 0;
+
+ case STATE_BUMP:
+ if (!ev.pulse)
+ break;
+
+ if (!eq_margin(ev.duration, RCMM_UNIT, RCMM_UNIT / 2))
+ break;
+
+ data->state = STATE_VALUE;
+
Re: [PATCHv3 1/1] Add ir-rcmm-driver
Hi Patrick, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.20-rc5 next-20181207] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Patrick-LERDA/Add-ir-rcmm-driver/20181208-02 base: git://linuxtv.org/media_tree.git master reproduce: make htmldocs All warnings (new ones prefixed by >>): include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.chain_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.filtered' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_count' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.lost_packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_tdls_pkt_time' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_retries' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.ack_signal_filled' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.avg_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.bytes' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.last_rate' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.msdu' not described in 'sta_info' kernel/rcu/tree.c:685: warning: Excess function parameter 'irq' description in 'rcu_nmi_exit' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.cb' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.poll' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_excl.active' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.cb' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.poll' not described in 'dma_buf' include/linux/dma-buf.h:304: warning: Function parameter or member 'cb_shared.active' not described in 'dma_buf' include/linux/dma-fence-array.h:54: warning: Function parameter or member 'work' not described in 'dma_fence_array' include/linux/gpio/driver.h:375: warning: Function parameter or member 'init_valid_mask' not described in 'gpio_chip' include/linux/iio/hw-consumer.h:1: warning: no structured comments found include/linux/input/sparse-keymap.h:46: warning: Function parameter or member 'sw' not
[GIT FIXES for 4.20] Fwnode parsing fix
Hi Mauro, Here's a patch that fixes clearing fwnode flags. The patch that broke it is only in 4.20. Please pull. The following changes since commit 078ab3ea2c3bb69cb989d52346fefa1246055e5b: media: Add a Kconfig option for the Request API (2018-12-05 13:07:43 -0500) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git tags/fixes-4.20-1-sign for you to fetch changes up to 7add7222d1741afb448a386c3085f38da801fd50: media: v4l2-fwnode: Fix setting V4L2_MBUS_DATA_ACTIVE_HIGH/LOW flag (2018-12-08 00:27:15 +0200) clear correct fwnode flags Ondrej Jirman (1): media: v4l2-fwnode: Fix setting V4L2_MBUS_DATA_ACTIVE_HIGH/LOW flag drivers/media/v4l2-core/v4l2-fwnode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- Sakari Ailus
Re: [PATCH 1/2] media: pxa_camera: don't deferenciate a NULL pointer
Hi Mauro,
On Fri, Dec 07, 2018 at 08:07:54AM -0500, Mauro Carvalho Chehab wrote:
> As warned by smatch:
> drivers/media/platform/pxa_camera.c:2400 pxa_camera_probe() error: we
> previously assumed 'pcdev->pdata' could be null (see line 2397)
>
> It would be possible that neither DT nor platform data would be
> provided. This is a Kernel bug, so warn about that and bail.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/platform/pxa_camera.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/media/platform/pxa_camera.c
> b/drivers/media/platform/pxa_camera.c
> index 5f930560eb30..f91f8fd424c4 100644
> --- a/drivers/media/platform/pxa_camera.c
> +++ b/drivers/media/platform/pxa_camera.c
> @@ -2396,6 +2396,9 @@ static int pxa_camera_probe(struct platform_device
> *pdev)
> pcdev->pdata = pdev->dev.platform_data;
> if (pdev->dev.of_node && !pcdev->pdata) {
> err = pxa_camera_pdata_from_dt(>dev, pcdev, >asd);
> + } else if (!pcdev->pdata) {
This fixes the issue, but the current checks remain a bit odd.
The driver seems to prefer platform data over OF. I wonder if that's
intentional or not.
In that case, I'd roughly write this as:
if (pcdev->pdata) {
...;
} else if (pdev->dev.of_node) {
...;
} else {
return -ENODEV;
}
I'm not sure WARN_ON(1) is necessary. A lot of drivers simply do it this
way without WARN_ON().
> + WARN_ON(1);
> + return -ENODEV;
> } else {
> pcdev->platform_flags = pcdev->pdata->flags;
> pcdev->mclk = pcdev->pdata->mclk_10khz * 1;
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
Re: [PATCH v5 00/12] imx-media: Fixes for interlaced capture
Hi Hans, On 12/7/18 5:35 AM, Hans Verkuil wrote: Hi Steve, How to proceed with this w.r.t. the two gpu ipu patches? Are those going in first through the gpu tree? Or do they have to go in through our tree? There is only one remaining gpu ipu patch in this series that is awaiting an ack from Philipp: "gpu: ipu-csi: Swap fields according to input/output field types" I pinged him again. Philipp agreed to allow the two ipu patches in the series to be merged to media tree. Steve In that case I need Acks from whoever maintains that code. Regards, Hans On 10/17/2018 02:00 AM, Steve Longerbeam wrote: A set of patches that fixes some bugs with capturing from an interlaced source, and incompatibilites between IDMAC interlace interweaving and 4:2:0 data write reduction. History: v5: - Added a regression fix to allow empty endpoints to CSI (fix for imx6q SabreAuto). - Cleaned up some convoluted code in ipu_csi_init_interface(), suggested by Philipp Zabel. - Fixed a regression in csi_setup(), caught by Philipp. - Removed interweave_offset and replace with boolean interweave_swap, suggested by Philipp. - Make clear that it is IDMAC channel that does pixel reordering and interweave, not the CSI, in the imx.rst doc, caught by Philipp. v4: - rebased to latest media-tree master branch. - Make patch author and SoB email addresses the same. v3: - add support for/fix interweaved scan with YUV planar output. - fix bug in 4:2:0 U/V offset macros. - add patch that generalizes behavior of field swap in ipu_csi_init_interface(). - add support for interweaved scan with field order swap. Suggested by Philipp Zabel. - in v2, inteweave scan was determined using field types of CSI (and PRPENCVF) at the sink and source pads. In v3, this has been moved one hop downstream: interweave is now determined using field type at source pad, and field type selected at capture interface. Suggested by Philipp. - make sure to double CSI crop target height when input field type in alternate. - more updates to media driver doc to reflect above. v2: - update media driver doc. - enable idmac interweave only if input field is sequential/alternate, and output field is 'interlaced*'. - move field try logic out of *try_fmt and into separate function. - fix bug with resetting crop/compose rectangles. - add a patch that fixes a field order bug in VDIC indirect mode. - remove alternate field type from V4L2_FIELD_IS_SEQUENTIAL() macro Suggested-by: Nicolas Dufresne . - add macro V4L2_FIELD_IS_INTERLACED(). Steve Longerbeam (12): media: videodev2.h: Add more field helper macros gpu: ipu-csi: Swap fields according to input/output field types gpu: ipu-v3: Add planar support to interlaced scan media: imx: Fix field negotiation media: imx-csi: Input connections to CSI should be optional media: imx-csi: Double crop height for alternate fields at sink media: imx: interweave and odd-chroma-row skip are incompatible media: imx-csi: Allow skipping odd chroma rows for YVU420 media: imx: vdic: rely on VDIC for correct field order media: imx-csi: Move crop/compose reset after filling default mbus fields media: imx: Allow interweave with top/bottom lines swapped media: imx.rst: Update doc to reflect fixes to interlaced capture Documentation/media/v4l-drivers/imx.rst | 103 +++ drivers/gpu/ipu-v3/ipu-cpmem.c| 26 ++- drivers/gpu/ipu-v3/ipu-csi.c | 119 + drivers/staging/media/imx/imx-ic-prpencvf.c | 46 +++-- drivers/staging/media/imx/imx-media-capture.c | 14 ++ drivers/staging/media/imx/imx-media-csi.c | 168 +- drivers/staging/media/imx/imx-media-vdic.c| 12 +- include/uapi/linux/videodev2.h| 7 + include/video/imx-ipu-v3.h| 6 +- 9 files changed, 354 insertions(+), 147 deletions(-)
Re: VIVID/VIMC and media fuzzing
Hi Dmitry, On 10/31/18 9:49 AM, Helen Koike wrote: > Hi Dmitry, > > On 10/31/18 7:46 AM, Hans Verkuil wrote: >> On 10/30/2018 03:02 PM, Dmitry Vyukov wrote: >>> Hello Helen and linux-media, >>> >>> I've attended your talk "Shifting Media App Development into High >>> Gear" on OSS Summit last week and approached you with some questions >>> if/how this can be used for kernel testing. Thanks, turn out to be a >>> very useful talk! > > Great, I am glad it was useful :) > >>> >>> I am working on syzkaller/syzbot, continuous kernel fuzzing system: >>> https://github.com/google/syzkaller >>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md >>> https://syzkaller.appspot.com >>> >>> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M, >>> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in >>> media subsystem in just 24 hours: >>> >>> KASAN: use-after-free Read in vb2_mmap >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ >>> >>> KASAN: use-after-free Write in __vb2_cleanup_fileio >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ >>> >>> WARNING in __vb2_queue_cancel >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ >>> >>> divide error in vivid_vid_cap_s_dv_timings >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ >> >> Should be fixed by https://patchwork.linuxtv.org/patch/52641/ >> >>> >>> KASAN: use-after-free Read in wake_up_if_idle >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ >>> >>> KASAN: use-after-free Read in __vb2_perform_fileio >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ >>> >>> INFO: task hung in vivid_stop_generating_vid_cap >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ >>> >>> KASAN: null-ptr-deref Write in kthread_stop >>> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ >> >> These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/ >> >> Haven't figured out the others yet (hope to get back to that next week). >> >>> >>> Based on this I think if we put more effort into media fuzzing, it >>> will be able to find dozens more. >> >> Yeah, this is good stuff. Thank you for setting this up. > > Agreed, Dmitry thank you for doing this. > >> >>> >>> syzkaller needs descriptions of kernel interfaces to efficiently cover >>> a subsystem. For example, see: >>> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt >>> Hopefully you can read it without much explanation, it basically >>> states that there is that node in /dev and here are ioctls and other >>> syscalls that are relevant for this device and here are types of >>> arguments and layout of involved data structures. >>> >>> Turned we actually have such descriptions for /dev/video* and >>> /dev/v4l-subdev*: >>> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt >>> But we don't have anything for /dev/media*, fuzzer merely knows that >>> it can open the device: >>> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479 >>> and then it will just blindly execute completely random workload on >>> it, e.g. most likely it won't be able to come up with a proper complex >>> structure layout for some ioctls. And I am actually not completely >>> sure about completeness and coverage of video4linux.txt descriptions >>> too as they were contributed by somebody interested in android >>> testing. >> >> A quick look suggests that it is based on the 4.9 videodev2.h, which ain't >> too bad. There are some differences between the 4.20 videodev2.h and the >> 4.9, but not too many. >> >>> >>> I wonder if somebody knowledgeable in /dev/media interface be willing >>> to contribute additional descriptions? >> >> We'll have to wait for 4.20-rc1 to be released since there are important >> additions to the media API. I can probably come up with something, I'm >> just not sure when I get around to it. Ping me in three weeks time if you >> haven't heard from me. >> >>> >>> We also have code coverage reports with the coverage fuzzer achieved >>> so far. Here in the Cover column: >>> https://syzkaller.appspot.com/#managers >>> e.g. this one (but note this is a ~80MB html file): >>> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html >>> This can be used to assess e.g. v4l coverage. But I don't know what's >>> coverable in general from syscalls and what's coverable via the stub >>> drivers in particular. So some expertise from media developers would >>> be helpful too. >> >> The four virtual drivers should give pretty decent coverage of the core >> code. Are you able to test with a 32-bit syzkaller application on a 64-bit >> kernel as well? That way the compat32 code is tested. >> >>> >>> Do I understand it correctly that when a process opens
Re: [PATCH 2/2] media: drxk_hard: check if parameter is not NULL
On Fri, Dec 7, 2018 at 5:08 AM Mauro Carvalho Chehab
wrote:
>
> There is a smatch warning:
> drivers/media/dvb-frontends/drxk_hard.c:
> drivers/media/dvb-frontends/drxk_hard.c:1478 scu_command() error: we
> previously assumed 'parameter' could be null (see line 1467)
>
> Telling that parameter might be NULL. Well, it can't, due to the
> way the driver works, but it doesn't hurt to add a check, in order
> to shut up smatch.
eh, yeah this function is kind of odd; the early return conditions are
a little tricky, but I agree that this check doesn't hurt to add.
Reviewed-by: Nick Desaulniers
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/dvb-frontends/drxk_hard.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/drxk_hard.c
> b/drivers/media/dvb-frontends/drxk_hard.c
> index 84ac3f73f8fe..8ea1e45be710 100644
> --- a/drivers/media/dvb-frontends/drxk_hard.c
> +++ b/drivers/media/dvb-frontends/drxk_hard.c
> @@ -1474,9 +1474,11 @@ static int scu_command(struct drxk_state *state,
>
> /* assume that the command register is ready
> since it is checked afterwards */
> - for (ii = parameter_len - 1; ii >= 0; ii -= 1) {
> - buffer[cnt++] = (parameter[ii] & 0xFF);
> - buffer[cnt++] = ((parameter[ii] >> 8) & 0xFF);
> + if (parameter) {
> + for (ii = parameter_len - 1; ii >= 0; ii -= 1) {
> + buffer[cnt++] = (parameter[ii] & 0xFF);
> + buffer[cnt++] = ((parameter[ii] >> 8) & 0xFF);
> + }
> }
> buffer[cnt++] = (cmd & 0xFF);
> buffer[cnt++] = ((cmd >> 8) & 0xFF);
> --
> 2.19.2
>
--
Thanks,
~Nick Desaulniers
Re: [PATCH v2] [RFC v2] v4l2: add support for colorspace conversion for video capture
On 12/07/2018 03:30 PM, Mauro Carvalho Chehab wrote: > Em Thu, 6 Sep 2018 11:02:28 +0200 > Hans Verkuil escreveu: > >> Hi Philipp, >> >> It is much appreciated that this old RFC of mine is picked up again. >> I always wanted to get this in, but I never had a driver where it would >> make sense to do so. > > What's the status of this? Changes were requested, and there was some discussion. I'm basically waiting for an update. I've delegated it to me. Regards, Hans > > Hans, > As this is an old RFC from you, I'll delegate it to you at patchwork, > for you to track it. > > Regards, > Mauro > >> >> On 09/05/2018 07:09 PM, Philipp Zabel wrote: >>> For video capture it is the driver that reports the colorspace, >> >> add: "transfer function," >> >>> Y'CbCr/HSV encoding and quantization range used by the video, and there >>> is no way to request something different, even though many HDTV >>> receivers have some sort of colorspace conversion capabilities. >>> >>> For output video this feature already exists since the application >>> specifies this information for the video format it will send out, and >>> the transmitter will enable any available CSC if a format conversion has >>> to be performed in order to match the capabilities of the sink. >>> >>> For video capture we propose adding new pix_format flags: >>> V4L2_PIX_FMT_FLAG_CSC_COLORSPACE, V4L2_PIX_FMT_FLAG_CSC_YCBCR_ENC, >>> V4L2_PIX_FMT_FLAG_CSC_HSV_ENC, V4L2_PIX_FMT_FLAG_CSC_QUANTIZATION, and >>> V4L2_PIX_FMT_FLAG_CSC_XFER_FUNC. These are set by the driver to indicate >>> its conversion features. When set by the application, the driver will >>> interpret the colorspace, ycbcr_enc/hsv_enc, quantization and xfer_func >>> fields as the requested colorspace information and will attempt to do >>> the conversion it supports. >>> >>> Drivers do not have to actually look at the flags: if the flags are not >>> set, then the colorspace, ycbcr_enc and quantization fields are set to >>> the default values by the core, i.e. just pass on the received format >>> without conversion. >> >> Thinking about this some more, I don't think this is quite the right >> approach. >> Having userspace set these flags with S_FMT if they want to do explicit >> conversions makes sense, and that part we can keep. >> >> But to signal the capabilities I think should be done via new flags for >> VIDIOC_ENUM_FMT. Basically the same set of flags, but for the flags field >> of struct v4l2_fmtdesc. >> >> One thing that's not clear to me is what happens if userspace sets one or >> more flags and calls S_FMT for a driver that doesn't support this. Are the >> flags zeroed in that case upon return? I don't think so, but I think that >> is already true for the existing flag V4L2_PIX_FMT_FLAG_PREMUL_ALPHA. >> >> I wonder if V4L2_PIX_FMT_FLAG_PREMUL_ALPHA should also get an equivalent >> flag for v4l2_fmtdesc. >> >> Then we can just document that v4l2_format flags are only valid if they >> are also defined in v4l2_fmtdesc. >> >> Does anyone have better ideas for this? >> >> Regards, >> >> Hans >> >>> >>> Signed-off-by: Hans Verkuil >>> Signed-off-by: Philipp Zabel >>> --- >>> Changes since v1 [1] >>> - convert to rst >>> - split V4L2_PIX_FMT_FLAG_REQUEST_CSC into four separate flags for >>>colorspace, ycbcr_enc/hsv_enc, quantization, and xfer_func >>> - let driver set flags to indicate supported features >>> >>> [1] https://patchwork.linuxtv.org/patch/28847/ >>> --- >>> .../media/uapi/v4l/pixfmt-reserved.rst| 41 +++ >>> .../media/uapi/v4l/pixfmt-v4l2-mplane.rst | 16 ++-- >>> Documentation/media/uapi/v4l/pixfmt-v4l2.rst | 37 ++--- >>> drivers/media/v4l2-core/v4l2-ioctl.c | 12 ++ >>> include/uapi/linux/videodev2.h| 5 +++ >>> 5 files changed, 94 insertions(+), 17 deletions(-) >>> >>> diff --git a/Documentation/media/uapi/v4l/pixfmt-reserved.rst >>> b/Documentation/media/uapi/v4l/pixfmt-reserved.rst >>> index 38af1472a4b4..c1090027626c 100644 >>> --- a/Documentation/media/uapi/v4l/pixfmt-reserved.rst >>> +++ b/Documentation/media/uapi/v4l/pixfmt-reserved.rst >>> @@ -261,3 +261,44 @@ please make a proposal on the linux-media mailing list. >>> by RGBA values (128, 192, 255, 128), the same pixel described with >>> premultiplied colors would be described by RGBA values (64, 96, >>> 128, 128) >>> +* - ``V4L2_PIX_FMT_FLAG_CSC_COLORSPACE`` >>> + - 0x0002 >>> + - Set by the driver to indicate colorspace conversion support. Set >>> by the >>> + application to request conversion to the specified colorspace. It is >>> + only used for capture and is ignored for output streams. If set by the >>> + application, then request the driver to do colorspace conversion from >>> + the received colorspace to the requested colorspace by setting the >>> + ``colorspace`` field of struct :c:type:`v4l2_pix_format`. >>> +* - ``V4L2_PIX_FMT_FLAG_CSC_YCBCR_ENC`` >>> +
Re: [PATCH v2] [RFC v2] v4l2: add support for colorspace conversion for video capture
Em Thu, 6 Sep 2018 11:02:28 +0200 Hans Verkuil escreveu: > Hi Philipp, > > It is much appreciated that this old RFC of mine is picked up again. > I always wanted to get this in, but I never had a driver where it would > make sense to do so. What's the status of this? Hans, As this is an old RFC from you, I'll delegate it to you at patchwork, for you to track it. Regards, Mauro > > On 09/05/2018 07:09 PM, Philipp Zabel wrote: > > For video capture it is the driver that reports the colorspace, > > add: "transfer function," > > > Y'CbCr/HSV encoding and quantization range used by the video, and there > > is no way to request something different, even though many HDTV > > receivers have some sort of colorspace conversion capabilities. > > > > For output video this feature already exists since the application > > specifies this information for the video format it will send out, and > > the transmitter will enable any available CSC if a format conversion has > > to be performed in order to match the capabilities of the sink. > > > > For video capture we propose adding new pix_format flags: > > V4L2_PIX_FMT_FLAG_CSC_COLORSPACE, V4L2_PIX_FMT_FLAG_CSC_YCBCR_ENC, > > V4L2_PIX_FMT_FLAG_CSC_HSV_ENC, V4L2_PIX_FMT_FLAG_CSC_QUANTIZATION, and > > V4L2_PIX_FMT_FLAG_CSC_XFER_FUNC. These are set by the driver to indicate > > its conversion features. When set by the application, the driver will > > interpret the colorspace, ycbcr_enc/hsv_enc, quantization and xfer_func > > fields as the requested colorspace information and will attempt to do > > the conversion it supports. > > > > Drivers do not have to actually look at the flags: if the flags are not > > set, then the colorspace, ycbcr_enc and quantization fields are set to > > the default values by the core, i.e. just pass on the received format > > without conversion. > > Thinking about this some more, I don't think this is quite the right approach. > Having userspace set these flags with S_FMT if they want to do explicit > conversions makes sense, and that part we can keep. > > But to signal the capabilities I think should be done via new flags for > VIDIOC_ENUM_FMT. Basically the same set of flags, but for the flags field > of struct v4l2_fmtdesc. > > One thing that's not clear to me is what happens if userspace sets one or > more flags and calls S_FMT for a driver that doesn't support this. Are the > flags zeroed in that case upon return? I don't think so, but I think that > is already true for the existing flag V4L2_PIX_FMT_FLAG_PREMUL_ALPHA. > > I wonder if V4L2_PIX_FMT_FLAG_PREMUL_ALPHA should also get an equivalent > flag for v4l2_fmtdesc. > > Then we can just document that v4l2_format flags are only valid if they > are also defined in v4l2_fmtdesc. > > Does anyone have better ideas for this? > > Regards, > > Hans > > > > > Signed-off-by: Hans Verkuil > > Signed-off-by: Philipp Zabel > > --- > > Changes since v1 [1] > > - convert to rst > > - split V4L2_PIX_FMT_FLAG_REQUEST_CSC into four separate flags for > >colorspace, ycbcr_enc/hsv_enc, quantization, and xfer_func > > - let driver set flags to indicate supported features > > > > [1] https://patchwork.linuxtv.org/patch/28847/ > > --- > > .../media/uapi/v4l/pixfmt-reserved.rst| 41 +++ > > .../media/uapi/v4l/pixfmt-v4l2-mplane.rst | 16 ++-- > > Documentation/media/uapi/v4l/pixfmt-v4l2.rst | 37 ++--- > > drivers/media/v4l2-core/v4l2-ioctl.c | 12 ++ > > include/uapi/linux/videodev2.h| 5 +++ > > 5 files changed, 94 insertions(+), 17 deletions(-) > > > > diff --git a/Documentation/media/uapi/v4l/pixfmt-reserved.rst > > b/Documentation/media/uapi/v4l/pixfmt-reserved.rst > > index 38af1472a4b4..c1090027626c 100644 > > --- a/Documentation/media/uapi/v4l/pixfmt-reserved.rst > > +++ b/Documentation/media/uapi/v4l/pixfmt-reserved.rst > > @@ -261,3 +261,44 @@ please make a proposal on the linux-media mailing list. > > by RGBA values (128, 192, 255, 128), the same pixel described with > > premultiplied colors would be described by RGBA values (64, 96, > > 128, 128) > > +* - ``V4L2_PIX_FMT_FLAG_CSC_COLORSPACE`` > > + - 0x0002 > > + - Set by the driver to indicate colorspace conversion support. Set > > by the > > + application to request conversion to the specified colorspace. It is > > + only used for capture and is ignored for output streams. If set by the > > + application, then request the driver to do colorspace conversion from > > + the received colorspace to the requested colorspace by setting the > > + ``colorspace`` field of struct :c:type:`v4l2_pix_format`. > > +* - ``V4L2_PIX_FMT_FLAG_CSC_YCBCR_ENC`` > > + - 0x0004 > > + - Set by the driver to indicate Y'CbCr encoding conversion support. > > Set > > + by the application to request conversion to the specified Y'CbCr > > + encoding. It is only used for capture and is ignored for
Urgently need money? We can help you!
Urgently need money? We can help you! Are you by the current situation in trouble or threatens you in trouble? In this way, we give you the ability to take a new development. As a rich person I feel obliged to assist people who are struggling to give them a chance. Everyone deserved a second chance and since the Government fails, it will have to come from others. No amount is too crazy for us and the maturity we determine by mutual agreement. No surprises, no extra costs, but just the agreed amounts and nothing else. Don't wait any longer and comment on this post. Please specify the amount you want to borrow and we will contact you with all the possibilities. contact us today at stewarrt.l...@gmail.com
Re: [PATCH v9 00/13] media: staging/imx7: add i.MX7 media driver
Hi Hans and Dan, On Fri 07 Dec 2018 at 13:38, Dan Carpenter wrote: On Fri, Dec 07, 2018 at 01:44:00PM +0100, Hans Verkuil wrote: CHECK: Alignment should match open parenthesis #936: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:921: + ret = v4l2_async_register_fwnode_subdev(mipi_sd, + sizeof(struct v4l2_async_subdev), _port, 1, Apparently the latest coding style is that alignment is more important than line length, although I personally do not agree. But since you need to respin in any case due to the wrong SPDX identifier you used you might as well take this into account. I added this in the cover letter: - some alignment parenthesis that were left as they are, to be more readable this ones were left as they are as they seem impossible to fit all rules. I hope you really do not mind about this checks. if you have a strong opinion about this let me know, otherwise I will leave this as it is. I'm pretty sure it complains about both equally. If you make fix one warning it will complain about the other. So you just have to pick which warning to not care about. Yeah, I agree with you, I normally like to avoid at all cost the line length issue. --- Cheers, Rui regards, dan carpenter
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
Em Fri, 7 Dec 2018 11:53:17 -0200 Mauro Carvalho Chehab escreveu: > Em Fri, 7 Dec 2018 14:27:48 +0100 > Hans Verkuil escreveu: > > > On 12/07/2018 01:42 PM, Mauro Carvalho Chehab wrote: > > > Em Fri, 7 Dec 2018 12:47:24 +0100 > > > Hans Verkuil escreveu: > > > > > >> On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote: > > >>> Em Fri, 7 Dec 2018 10:09:04 +0100 > > >>> Hans Verkuil escreveu: > > >>> > > This patch selects MEDIA_CONTROLLER for all camera, analog TV and > > digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. > > > > This will allow us to simplify drivers that currently have to add > > #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API > > to their code, since now this will always be available. > > > > The original intent of allowing these to be configured by the > > user was (I think) to save a bit of memory. > > >>> > > >>> No. The original intent was/is to be sure that adding the media > > >>> controller support won't be breaking existing working drivers. > > >> > > >> That doesn't make sense. If enabling this option would break existing > > >> drivers, then something is really wrong, isn't it? > > > > > > It is the opposite: disabling it should not break any driver that don't > > > depend on them to work. > > > > > >> > > >>> > > But as more and more > > drivers have a media controller and all regular distros already > > enable one or more of those drivers, the memory for the MC code is > > there anyway. > > > > Complexity has always been the bane of media drivers, so reducing > > complexity at the expense of a bit more memory (which is a rounding > > error compared to the amount of video buffer memory needed) is IMHO > > a good thing. > > > > Signed-off-by: Hans Verkuil > > --- > > diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig > > index 8add62a18293..56eb01cc8bb4 100644 > > --- a/drivers/media/Kconfig > > +++ b/drivers/media/Kconfig > > @@ -31,6 +31,7 @@ comment "Multimedia core support" > > # > > config MEDIA_CAMERA_SUPPORT > > bool "Cameras/video grabbers support" > > + select MEDIA_CONTROLLER > > ---help--- > > Enable support for webcams and video grabbers. > > > > @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT > > > > config MEDIA_ANALOG_TV_SUPPORT > > bool "Analog TV support" > > + select MEDIA_CONTROLLER > > ---help--- > > Enable analog TV support. > > > > @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT > > > > config MEDIA_DIGITAL_TV_SUPPORT > > bool "Digital TV support" > > + select MEDIA_CONTROLLER > > ---help--- > > Enable digital TV support. > > >>> > > >>> See my comments below. > > >>> > > > > @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" > > > > config MEDIA_CONTROLLER > > bool "Media Controller API" > > - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > > MEDIA_DIGITAL_TV_SUPPORT > > ---help--- > > Enable the media controller API used to query media devices > > internal > > topology and configure it dynamically. > > >>> > > >>> I have split comments with regards to it. Yeah, nowadays media > > >>> controller > > >>> has becoming more important. Still, a lot of media drivers work fine > > >>> without them. > > >>> > > >>> Anyway, if we're willing to make it mandatory, better to just remove the > > >>> entire config option or to make it a silent one. > > >> > > >> Well, that assumes that the media controller will only be used by media > > >> drivers, and not alsa or anyone else who wants to experiment with the MC. > > >> > > >> I won't object to making it silent (since it does reflect the current > > >> situation), but since this functionality is not actually specific to > > >> media > > >> drivers I think that is a good case to be made to allow it to be selected > > >> manually. > > >> > > >>> > > @@ -119,16 +121,11 @@ config VIDEO_DEV > > tristate > > depends on MEDIA_SUPPORT > > depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > > MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT > > + select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER > > default y > > > > config VIDEO_V4L2_SUBDEV_API > > - bool "V4L2 sub-device userspace API" > > - depends on VIDEO_DEV && MEDIA_CONTROLLER > > - ---help--- > > -Enables the V4L2 sub-device pad-level userspace API used to > > configure > > -video format, size and frame rate between hardware blocks. > > - > > -This API is mostly used by
Re: [PATCH v9 05/13] media: dt-bindings: add bindings for i.MX7 media driver
Hi Hans,
On Fri 07 Dec 2018 at 12:39, Hans Verkuil wrote:
On 11/22/2018 04:18 PM, Rui Miguel Silva wrote:
Add bindings documentation for i.MX7 media drivers.
The imx7 MIPI CSI2 and imx7 CMOS Sensor Interface.
Signed-off-by: Rui Miguel Silva
Reviewed-by: Rob Herring
Acked-by: Sakari Ailus
Please move this patch to the beginning of the series to avoid
checkpatch warnings:
WARNING: DT compatible string "fsl,imx7-csi" appears
un-documented -- check ./Documentation/devicetree/bindings/
#1378: FILE: drivers/staging/media/imx/imx7-media-csi.c:1336:
+ { .compatible = "fsl,imx7-csi" },
Will do, thanks for catching this one.
---
Cheers,
Rui
Thanks!
Hans
---
.../devicetree/bindings/media/imx7-csi.txt| 45 ++
.../bindings/media/imx7-mipi-csi2.txt | 90
+++
2 files changed, 135 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/imx7-csi.txt
create mode 100644
Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
diff --git
a/Documentation/devicetree/bindings/media/imx7-csi.txt
b/Documentation/devicetree/bindings/media/imx7-csi.txt
new file mode 100644
index ..3c07bc676bc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx7-csi.txt
@@ -0,0 +1,45 @@
+Freescale i.MX7 CMOS Sensor Interface
+=
+
+csi node
+
+
+This is device node for the CMOS Sensor Interface (CSI) which
enables the chip
+to connect directly to external CMOS image sensors.
+
+Required properties:
+
+- compatible: "fsl,imx7-csi";
+- reg : base address and length of the register set
for the device;
+- interrupts: should contain CSI interrupt;
+- clocks: list of clock specifiers, see
+
Documentation/devicetree/bindings/clock/clock-bindings.txt for
details;
+- clock-names : must contain "axi", "mclk" and "dcic"
entries, matching
+ entries in the clock property;
+
+The device node shall contain one 'port' child node with one
child 'endpoint'
+node, according to the bindings defined in:
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+In the following example a remote endpoint is a video
multiplexer.
+
+example:
+
+csi: csi@3071 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+compatible = "fsl,imx7-csi";
+reg = <0x3071 0x1>;
+interrupts = IRQ_TYPE_LEVEL_HIGH>;
+clocks = < IMX7D_CLK_DUMMY>,
+<
IMX7D_CSI_MCLK_ROOT_CLK>,
+<
IMX7D_CLK_DUMMY>;
+clock-names = "axi", "mclk", "dcic";
+
+port {
+csi_from_csi_mux: endpoint {
+remote-endpoint =
<_mux_to_csi>;
+};
+};
+};
diff --git
a/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
new file mode 100644
index ..71fd74ed3ec8
--- /dev/null
+++
b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
@@ -0,0 +1,90 @@
+Freescale i.MX7 Mipi CSI2
+=
+
+mipi_csi2 node
+--
+
+This is the device node for the MIPI CSI-2 receiver core in
i.MX7 SoC. It is
+compatible with previous version of Samsung D-phy.
+
+Required properties:
+
+- compatible: "fsl,imx7-mipi-csi2";
+- reg : base address and length of the register set
for the device;
+- interrupts: should contain MIPI CSIS interrupt;
+- clocks: list of clock specifiers, see
+
Documentation/devicetree/bindings/clock/clock-bindings.txt for
details;
+- clock-names : must contain "pclk", "wrap" and "phy"
entries, matching
+ entries in the clock property;
+- power-domains : a phandle to the power domain, see
+
Documentation/devicetree/bindings/power/power_domain.txt for
details.
+- reset-names : should include following entry "mrst";
+- resets: a list of phandle, should contain reset
entry of
+ reset-names;
+- phy-supply: from the generic phy bindings, a phandle to
a regulator that
+ provides power to MIPI CSIS core;
+
+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock frequency
in Hz, default
+ value when this property is not specified is
166 MHz;
+- fsl,csis-hs-settle : differential receiver (HS-RX) settle
time;
+
+The device node should contain two 'port' child nodes with one
child 'endpoint'
+node, according to the bindings defined in:
+ Documentation/devicetree/bindings/
media/video-interfaces.txt.
+ The following are properties specific to those nodes.
+
+port node
+-
+
+- reg : (required) can take
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
Em Fri, 7 Dec 2018 14:27:48 +0100 Hans Verkuil escreveu: > On 12/07/2018 01:42 PM, Mauro Carvalho Chehab wrote: > > Em Fri, 7 Dec 2018 12:47:24 +0100 > > Hans Verkuil escreveu: > > > >> On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote: > >>> Em Fri, 7 Dec 2018 10:09:04 +0100 > >>> Hans Verkuil escreveu: > >>> > This patch selects MEDIA_CONTROLLER for all camera, analog TV and > digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. > > This will allow us to simplify drivers that currently have to add > #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API > to their code, since now this will always be available. > > The original intent of allowing these to be configured by the > user was (I think) to save a bit of memory. > >>> > >>> No. The original intent was/is to be sure that adding the media > >>> controller support won't be breaking existing working drivers. > >> > >> That doesn't make sense. If enabling this option would break existing > >> drivers, then something is really wrong, isn't it? > > > > It is the opposite: disabling it should not break any driver that don't > > depend on them to work. > > > >> > >>> > But as more and more > drivers have a media controller and all regular distros already > enable one or more of those drivers, the memory for the MC code is > there anyway. > > Complexity has always been the bane of media drivers, so reducing > complexity at the expense of a bit more memory (which is a rounding > error compared to the amount of video buffer memory needed) is IMHO > a good thing. > > Signed-off-by: Hans Verkuil > --- > diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig > index 8add62a18293..56eb01cc8bb4 100644 > --- a/drivers/media/Kconfig > +++ b/drivers/media/Kconfig > @@ -31,6 +31,7 @@ comment "Multimedia core support" > # > config MEDIA_CAMERA_SUPPORT > bool "Cameras/video grabbers support" > +select MEDIA_CONTROLLER > ---help--- > Enable support for webcams and video grabbers. > > @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT > > config MEDIA_ANALOG_TV_SUPPORT > bool "Analog TV support" > +select MEDIA_CONTROLLER > ---help--- > Enable analog TV support. > > @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT > > config MEDIA_DIGITAL_TV_SUPPORT > bool "Digital TV support" > +select MEDIA_CONTROLLER > ---help--- > Enable digital TV support. > >>> > >>> See my comments below. > >>> > > @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" > > config MEDIA_CONTROLLER > bool "Media Controller API" > -depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > MEDIA_DIGITAL_TV_SUPPORT > ---help--- > Enable the media controller API used to query media devices > internal > topology and configure it dynamically. > >>> > >>> I have split comments with regards to it. Yeah, nowadays media controller > >>> has becoming more important. Still, a lot of media drivers work fine > >>> without them. > >>> > >>> Anyway, if we're willing to make it mandatory, better to just remove the > >>> entire config option or to make it a silent one. > >> > >> Well, that assumes that the media controller will only be used by media > >> drivers, and not alsa or anyone else who wants to experiment with the MC. > >> > >> I won't object to making it silent (since it does reflect the current > >> situation), but since this functionality is not actually specific to media > >> drivers I think that is a good case to be made to allow it to be selected > >> manually. > >> > >>> > @@ -119,16 +121,11 @@ config VIDEO_DEV > tristate > depends on MEDIA_SUPPORT > depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT > +select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER > default y > > config VIDEO_V4L2_SUBDEV_API > -bool "V4L2 sub-device userspace API" > -depends on VIDEO_DEV && MEDIA_CONTROLLER > ----help--- > - Enables the V4L2 sub-device pad-level userspace API used to > configure > - video format, size and frame rate between hardware blocks. > - > - This API is mostly used by camera interfaces in embedded > platforms. > +bool > >>> > >>> NACK. > >>> > >>> There is a very good reason why the subdev API is optional: there > >>> are drivers that use camera sensors but are not MC-centric. On those, > >>> the USB bridge
Re: [PATCH v9 01/13] media: staging/imx: refactor imx media device probe
Hi Hans, Thanks for the review. On Fri 07 Dec 2018 at 12:38, Hans Verkuil wrote: On 11/22/2018 04:18 PM, Rui Miguel Silva wrote: Refactor and move media device initialization code to a new common module, so it can be used by other devices, this will allow for example a near to introduce imx7 CSI driver, to use this media device. Signed-off-by: Rui Miguel Silva --- drivers/staging/media/imx/Makefile| 1 + .../staging/media/imx/imx-media-dev-common.c | 102 ++ drivers/staging/media/imx/imx-media-dev.c | 88 --- drivers/staging/media/imx/imx-media-of.c | 6 +- drivers/staging/media/imx/imx-media.h | 15 +++ 5 files changed, 141 insertions(+), 71 deletions(-) create mode 100644 drivers/staging/media/imx/imx-media-dev-common.c diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile index 698a4210316e..a30b3033f9a3 100644 --- a/drivers/staging/media/imx/Makefile +++ b/drivers/staging/media/imx/Makefile @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o +imx-media-objs += imx-media-dev-common.o imx-media-common-objs := imx-media-utils.o imx-media-fim.o imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o diff --git a/drivers/staging/media/imx/imx-media-dev-common.c b/drivers/staging/media/imx/imx-media-dev-common.c new file mode 100644 index ..55fe94fb72f2 --- /dev/null +++ b/drivers/staging/media/imx/imx-media-dev-common.c @@ -0,0 +1,102 @@ +// SPDX-License-Identifier: GPL This is an invalid SPDX license identifier. You probably want to use GPL-2.0. hrr... you are right, I will update it here and others. --- Cheers, Rui
Re: [PATCH v2] media: cedrus: don't initialize pointers with zero
Em Fri, 07 Dec 2018 14:21:44 +0100
Paul Kocialkowski escreveu:
> Hi,
>
> On Fri, 2018-12-07 at 08:03 -0500, Mauro Carvalho Chehab wrote:
> > A common mistake is to assume that initializing a var with:
> > struct foo f = { 0 };
> >
> > Would initialize a zeroed struct. Actually, what this does is
> > to initialize the first element of the struct to zero.
> >
> > According to C99 Standard 6.7.8.21:
> >
> > "If there are fewer initializers in a brace-enclosed
> > list than there are elements or members of an aggregate,
> > or fewer characters in a string literal used to initialize
> > an array of known size than there are elements in the array,
> > the remainder of the aggregate shall be initialized implicitly
> > the same as objects that have static storage duration."
> >
> > So, in practice, it could zero the entire struct, but, if the
> > first element is not an integer, it will produce warnings:
> >
> >
> > drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
> > warning: Using plain integer as NULL pointer
> >
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
> > warning: Using plain integer as NULL pointer
> >
> > As the right initialization would be, instead:
> >
> > struct foo f = { NULL };
>
> Thanks for sharing these details, it's definitely interesting and good
> to know :)
Yeah, that's something that was bothering for quite a while, as I've
seen patches using either one of the ways. It took me a while to
do some research, and having it documented at the patch helps, as
we should now handle it the same way for similar stuff :-)
>
> > Another way to initialize it with gcc is to use:
> >
> > struct foo f = {};
> >
> > That seems to be a gcc extension, but clang also does the right thing,
> > and that's a clean way for doing it.
> >
> > Anyway, I decided to check upstream what's the most commonly pattern.
> > The "= {}" pattern has about 2000 entries:
> >
> > $ git grep -E "=\s*\{\s*\}"|wc -l
> > 1951
> >
> > The standard-C compliant pattern has about 2500 entries:
> >
> > $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
> > 137
> > $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
> > 2323
> >
> > Meaning that developers have split options on that.
> >
> > So, let's opt to the simpler form.
>
> Acked-by: Paul Kocialkowski
Applied, thanks!
>
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > index b538eb0321d8..b7c918fa5fd1 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev,
> > struct cedrus_ctx *ctx)
> > memset(ctx->ctrls, 0, ctrl_size);
> >
> > for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> > - struct v4l2_ctrl_config cfg = { 0 };
> > + struct v4l2_ctrl_config cfg = {};
> >
> > cfg.elem_size = cedrus_controls[i].elem_size;
> > cfg.id = cedrus_controls[i].id;
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > index e40180a33951..f10c25f5460e 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
> > {
> > struct cedrus_ctx *ctx = priv;
> > struct cedrus_dev *dev = ctx->dev;
> > - struct cedrus_run run = { 0 };
> > + struct cedrus_run run = {};
> > struct media_request *src_req;
> > unsigned long flags;
> >
Thanks,
Mauro
Re: [PATCH v9 00/13] media: staging/imx7: add i.MX7 media driver
On Fri, Dec 07, 2018 at 01:44:00PM +0100, Hans Verkuil wrote: > CHECK: Alignment should match open parenthesis > #936: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:921: > + ret = v4l2_async_register_fwnode_subdev(mipi_sd, > + sizeof(struct v4l2_async_subdev), _port, > 1, > > Apparently the latest coding style is that alignment is more important than > line length, although I personally do not agree. But since you need to > respin in any case due to the wrong SPDX identifier you used you might as > well take this into account. I'm pretty sure it complains about both equally. If you make fix one warning it will complain about the other. So you just have to pick which warning to not care about. regards, dan carpenter
Re: [PATCH v5 00/12] imx-media: Fixes for interlaced capture
Hi Steve, How to proceed with this w.r.t. the two gpu ipu patches? Are those going in first through the gpu tree? Or do they have to go in through our tree? In that case I need Acks from whoever maintains that code. Regards, Hans On 10/17/2018 02:00 AM, Steve Longerbeam wrote: > A set of patches that fixes some bugs with capturing from an > interlaced source, and incompatibilites between IDMAC interlace > interweaving and 4:2:0 data write reduction. > > History: > v5: > - Added a regression fix to allow empty endpoints to CSI (fix for imx6q > SabreAuto). > - Cleaned up some convoluted code in ipu_csi_init_interface(), suggested > by Philipp Zabel. > - Fixed a regression in csi_setup(), caught by Philipp. > - Removed interweave_offset and replace with boolean interweave_swap, > suggested by Philipp. > - Make clear that it is IDMAC channel that does pixel reordering and > interweave, not the CSI, in the imx.rst doc, caught by Philipp. > > v4: > - rebased to latest media-tree master branch. > - Make patch author and SoB email addresses the same. > > v3: > - add support for/fix interweaved scan with YUV planar output. > - fix bug in 4:2:0 U/V offset macros. > - add patch that generalizes behavior of field swap in > ipu_csi_init_interface(). > - add support for interweaved scan with field order swap. > Suggested by Philipp Zabel. > - in v2, inteweave scan was determined using field types of > CSI (and PRPENCVF) at the sink and source pads. In v3, this > has been moved one hop downstream: interweave is now determined > using field type at source pad, and field type selected at > capture interface. Suggested by Philipp. > - make sure to double CSI crop target height when input field > type in alternate. > - more updates to media driver doc to reflect above. > > v2: > - update media driver doc. > - enable idmac interweave only if input field is sequential/alternate, > and output field is 'interlaced*'. > - move field try logic out of *try_fmt and into separate function. > - fix bug with resetting crop/compose rectangles. > - add a patch that fixes a field order bug in VDIC indirect mode. > - remove alternate field type from V4L2_FIELD_IS_SEQUENTIAL() macro > Suggested-by: Nicolas Dufresne . > - add macro V4L2_FIELD_IS_INTERLACED(). > > > Steve Longerbeam (12): > media: videodev2.h: Add more field helper macros > gpu: ipu-csi: Swap fields according to input/output field types > gpu: ipu-v3: Add planar support to interlaced scan > media: imx: Fix field negotiation > media: imx-csi: Input connections to CSI should be optional > media: imx-csi: Double crop height for alternate fields at sink > media: imx: interweave and odd-chroma-row skip are incompatible > media: imx-csi: Allow skipping odd chroma rows for YVU420 > media: imx: vdic: rely on VDIC for correct field order > media: imx-csi: Move crop/compose reset after filling default mbus > fields > media: imx: Allow interweave with top/bottom lines swapped > media: imx.rst: Update doc to reflect fixes to interlaced capture > > Documentation/media/v4l-drivers/imx.rst | 103 +++ > drivers/gpu/ipu-v3/ipu-cpmem.c| 26 ++- > drivers/gpu/ipu-v3/ipu-csi.c | 119 + > drivers/staging/media/imx/imx-ic-prpencvf.c | 46 +++-- > drivers/staging/media/imx/imx-media-capture.c | 14 ++ > drivers/staging/media/imx/imx-media-csi.c | 168 +- > drivers/staging/media/imx/imx-media-vdic.c| 12 +- > include/uapi/linux/videodev2.h| 7 + > include/video/imx-ipu-v3.h| 6 +- > 9 files changed, 354 insertions(+), 147 deletions(-) >
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
On 12/07/2018 01:42 PM, Mauro Carvalho Chehab wrote: > Em Fri, 7 Dec 2018 12:47:24 +0100 > Hans Verkuil escreveu: > >> On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote: >>> Em Fri, 7 Dec 2018 10:09:04 +0100 >>> Hans Verkuil escreveu: >>> This patch selects MEDIA_CONTROLLER for all camera, analog TV and digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. This will allow us to simplify drivers that currently have to add #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API to their code, since now this will always be available. The original intent of allowing these to be configured by the user was (I think) to save a bit of memory. >>> >>> No. The original intent was/is to be sure that adding the media >>> controller support won't be breaking existing working drivers. >> >> That doesn't make sense. If enabling this option would break existing >> drivers, then something is really wrong, isn't it? > > It is the opposite: disabling it should not break any driver that don't > depend on them to work. > >> >>> But as more and more drivers have a media controller and all regular distros already enable one or more of those drivers, the memory for the MC code is there anyway. Complexity has always been the bane of media drivers, so reducing complexity at the expense of a bit more memory (which is a rounding error compared to the amount of video buffer memory needed) is IMHO a good thing. Signed-off-by: Hans Verkuil --- diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 8add62a18293..56eb01cc8bb4 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -31,6 +31,7 @@ comment "Multimedia core support" # config MEDIA_CAMERA_SUPPORT bool "Cameras/video grabbers support" + select MEDIA_CONTROLLER ---help--- Enable support for webcams and video grabbers. @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT config MEDIA_ANALOG_TV_SUPPORT bool "Analog TV support" + select MEDIA_CONTROLLER ---help--- Enable analog TV support. @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT config MEDIA_DIGITAL_TV_SUPPORT bool "Digital TV support" + select MEDIA_CONTROLLER ---help--- Enable digital TV support. >>> >>> See my comments below. >>> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" config MEDIA_CONTROLLER bool "Media Controller API" - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT ---help--- Enable the media controller API used to query media devices internal topology and configure it dynamically. >>> >>> I have split comments with regards to it. Yeah, nowadays media controller >>> has becoming more important. Still, a lot of media drivers work fine >>> without them. >>> >>> Anyway, if we're willing to make it mandatory, better to just remove the >>> entire config option or to make it a silent one. >> >> Well, that assumes that the media controller will only be used by media >> drivers, and not alsa or anyone else who wants to experiment with the MC. >> >> I won't object to making it silent (since it does reflect the current >> situation), but since this functionality is not actually specific to media >> drivers I think that is a good case to be made to allow it to be selected >> manually. >> >>> @@ -119,16 +121,11 @@ config VIDEO_DEV tristate depends on MEDIA_SUPPORT depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT + select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER default y config VIDEO_V4L2_SUBDEV_API - bool "V4L2 sub-device userspace API" - depends on VIDEO_DEV && MEDIA_CONTROLLER - ---help--- -Enables the V4L2 sub-device pad-level userspace API used to configure -video format, size and frame rate between hardware blocks. - -This API is mostly used by camera interfaces in embedded platforms. + bool >>> >>> NACK. >>> >>> There is a very good reason why the subdev API is optional: there >>> are drivers that use camera sensors but are not MC-centric. On those, >>> the USB bridge driver is responsible to setup the subdevice. >>> >>> This options helps to ensure that camera sensors used by such drivers >>> won't stop working because of the lack of the subdev-API. >> >> But they won't stop working if this is enabled. > > That's not the issue. I've seen (and nacked) several patches breaking > drivers by assuming that all init would happen via subdev API. > > By having this as an optional feature that can be disabled, developers > need to ensure that either the driver won't be built as a hole, if > no
Re: [PATCH] media: cedrus: don't initialize pointers with zero
On Fri, Dec 07, 2018 at 09:31:06AM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 7 Dec 2018 12:14:50 +0100
> Hans Verkuil escreveu:
>
> > On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> > > A common mistake is to assume that initializing a var with:
> > > struct foo f = { 0 };
> > >
> > > Would initialize a zeroed struct. Actually, what this does is
> > > to initialize the first element of the struct to zero.
> > >
> > > According to C99 Standard 6.7.8.21:
> > >
> > > "If there are fewer initializers in a brace-enclosed
> > > list than there are elements or members of an aggregate,
> > > or fewer characters in a string literal used to initialize
> > > an array of known size than there are elements in the array,
> > > the remainder of the aggregate shall be initialized implicitly
> > > the same as objects that have static storage duration."
> > >
> > > So, in practice, it could zero the entire struct, but, if the
> > > first element is not an integer, it will produce warnings:
> > >
> > >
> > > drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
> > > warning: Using plain integer as NULL pointer
> > >
> > > drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
> > > warning: Using plain integer as NULL pointer
> > >
> > > A proper way to initialize it with gcc is to use:
> > >
> > > struct foo f = { };
> > >
> > > But that seems to be a gcc extension. So, I decided to check upstream
> >
> > No, this is not a gcc extension. It's part of the latest C standard.
>
> Sure? Where the C standard spec states that? I've been seeking for
> such info for a while, as '= {}' is also my personal preference.
>
> I tried to build the Kernel with clang, just to be sure that this
> won't cause issues with the clang support
My test says that clang works with {}.
I support this in Smatch as well.
regards,
dan carpenter
Re: [PATCH v2] media: cedrus: don't initialize pointers with zero
Hi,
On Fri, 2018-12-07 at 08:03 -0500, Mauro Carvalho Chehab wrote:
> A common mistake is to assume that initializing a var with:
> struct foo f = { 0 };
>
> Would initialize a zeroed struct. Actually, what this does is
> to initialize the first element of the struct to zero.
>
> According to C99 Standard 6.7.8.21:
>
> "If there are fewer initializers in a brace-enclosed
> list than there are elements or members of an aggregate,
> or fewer characters in a string literal used to initialize
> an array of known size than there are elements in the array,
> the remainder of the aggregate shall be initialized implicitly
> the same as objects that have static storage duration."
>
> So, in practice, it could zero the entire struct, but, if the
> first element is not an integer, it will produce warnings:
>
>
> drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
> warning: Using plain integer as NULL pointer
>
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
> warning: Using plain integer as NULL pointer
>
> As the right initialization would be, instead:
>
> struct foo f = { NULL };
Thanks for sharing these details, it's definitely interesting and good
to know :)
> Another way to initialize it with gcc is to use:
>
> struct foo f = {};
>
> That seems to be a gcc extension, but clang also does the right thing,
> and that's a clean way for doing it.
>
> Anyway, I decided to check upstream what's the most commonly pattern.
> The "= {}" pattern has about 2000 entries:
>
> $ git grep -E "=\s*\{\s*\}"|wc -l
> 1951
>
> The standard-C compliant pattern has about 2500 entries:
>
> $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
> 137
> $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
> 2323
>
> Meaning that developers have split options on that.
>
> So, let's opt to the simpler form.
Acked-by: Paul Kocialkowski
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index b538eb0321d8..b7c918fa5fd1 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct
> cedrus_ctx *ctx)
> memset(ctx->ctrls, 0, ctrl_size);
>
> for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> - struct v4l2_ctrl_config cfg = { 0 };
> + struct v4l2_ctrl_config cfg = {};
>
> cfg.elem_size = cedrus_controls[i].elem_size;
> cfg.id = cedrus_controls[i].id;
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> index e40180a33951..f10c25f5460e 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
> {
> struct cedrus_ctx *ctx = priv;
> struct cedrus_dev *dev = ctx->dev;
> - struct cedrus_run run = { 0 };
> + struct cedrus_run run = {};
> struct media_request *src_req;
> unsigned long flags;
>
--
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com
[PATCH 1/2] media: pxa_camera: don't deferenciate a NULL pointer
As warned by smatch:
drivers/media/platform/pxa_camera.c:2400 pxa_camera_probe() error: we
previously assumed 'pcdev->pdata' could be null (see line 2397)
It would be possible that neither DT nor platform data would be
provided. This is a Kernel bug, so warn about that and bail.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/platform/pxa_camera.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/pxa_camera.c
b/drivers/media/platform/pxa_camera.c
index 5f930560eb30..f91f8fd424c4 100644
--- a/drivers/media/platform/pxa_camera.c
+++ b/drivers/media/platform/pxa_camera.c
@@ -2396,6 +2396,9 @@ static int pxa_camera_probe(struct platform_device *pdev)
pcdev->pdata = pdev->dev.platform_data;
if (pdev->dev.of_node && !pcdev->pdata) {
err = pxa_camera_pdata_from_dt(>dev, pcdev, >asd);
+ } else if (!pcdev->pdata) {
+ WARN_ON(1);
+ return -ENODEV;
} else {
pcdev->platform_flags = pcdev->pdata->flags;
pcdev->mclk = pcdev->pdata->mclk_10khz * 1;
--
2.19.2
[PATCH 2/2] media: drxk_hard: check if parameter is not NULL
There is a smatch warning:
drivers/media/dvb-frontends/drxk_hard.c:
drivers/media/dvb-frontends/drxk_hard.c:1478 scu_command() error: we previously
assumed 'parameter' could be null (see line 1467)
Telling that parameter might be NULL. Well, it can't, due to the
way the driver works, but it doesn't hurt to add a check, in order
to shut up smatch.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/drxk_hard.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/drxk_hard.c
b/drivers/media/dvb-frontends/drxk_hard.c
index 84ac3f73f8fe..8ea1e45be710 100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -1474,9 +1474,11 @@ static int scu_command(struct drxk_state *state,
/* assume that the command register is ready
since it is checked afterwards */
- for (ii = parameter_len - 1; ii >= 0; ii -= 1) {
- buffer[cnt++] = (parameter[ii] & 0xFF);
- buffer[cnt++] = ((parameter[ii] >> 8) & 0xFF);
+ if (parameter) {
+ for (ii = parameter_len - 1; ii >= 0; ii -= 1) {
+ buffer[cnt++] = (parameter[ii] & 0xFF);
+ buffer[cnt++] = ((parameter[ii] >> 8) & 0xFF);
+ }
}
buffer[cnt++] = (cmd & 0xFF);
buffer[cnt++] = ((cmd >> 8) & 0xFF);
--
2.19.2
[PATCH v2] media: cedrus: don't initialize pointers with zero
A common mistake is to assume that initializing a var with:
struct foo f = { 0 };
Would initialize a zeroed struct. Actually, what this does is
to initialize the first element of the struct to zero.
According to C99 Standard 6.7.8.21:
"If there are fewer initializers in a brace-enclosed
list than there are elements or members of an aggregate,
or fewer characters in a string literal used to initialize
an array of known size than there are elements in the array,
the remainder of the aggregate shall be initialized implicitly
the same as objects that have static storage duration."
So, in practice, it could zero the entire struct, but, if the
first element is not an integer, it will produce warnings:
drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
warning: Using plain integer as NULL pointer
drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
warning: Using plain integer as NULL pointer
As the right initialization would be, instead:
struct foo f = { NULL };
Another way to initialize it with gcc is to use:
struct foo f = {};
That seems to be a gcc extension, but clang also does the right thing,
and that's a clean way for doing it.
Anyway, I decided to check upstream what's the most commonly pattern.
The "= {}" pattern has about 2000 entries:
$ git grep -E "=\s*\{\s*\}"|wc -l
1951
The standard-C compliant pattern has about 2500 entries:
$ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
137
$ git grep -E "=\s*\{\s*0\s*\}"|wc -l
2323
Meaning that developers have split options on that.
So, let's opt to the simpler form.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index b538eb0321d8..b7c918fa5fd1 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct
cedrus_ctx *ctx)
memset(ctx->ctrls, 0, ctrl_size);
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
- struct v4l2_ctrl_config cfg = { 0 };
+ struct v4l2_ctrl_config cfg = {};
cfg.elem_size = cedrus_controls[i].elem_size;
cfg.id = cedrus_controls[i].id;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..f10c25f5460e 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
{
struct cedrus_ctx *ctx = priv;
struct cedrus_dev *dev = ctx->dev;
- struct cedrus_run run = { 0 };
+ struct cedrus_run run = {};
struct media_request *src_req;
unsigned long flags;
--
2.19.2
Re: [PATCH] media: cetrus: return an error if alloc fails
Hi,
On Fri, 2018-12-07 at 06:13 -0500, Mauro Carvalho Chehab wrote:
> As warned by smatch:
>
> drivers/staging/media/sunxi/cedrus/cedrus.c:
> drivers/staging/media/sunxi/cedrus/cedrus.c:93 cedrus_init_ctrls() error:
> potential null dereference 'ctx->ctrls'. (kzalloc returns null)
>
> While here, remove the memset(), as kzalloc() already zeroes the
> struct.
Good catch, thanks for the patch!
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Paul Kocialkowski
> ---
> drivers/staging/media/sunxi/cedrus/cedrus.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index 44c45c687503..24b89cd2b692 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -72,7 +72,8 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct
> cedrus_ctx *ctx)
> ctrl_size = sizeof(ctrl) * CEDRUS_CONTROLS_COUNT + 1;
>
> ctx->ctrls = kzalloc(ctrl_size, GFP_KERNEL);
> - memset(ctx->ctrls, 0, ctrl_size);
> + if (!ctx->ctrls)
> + return -ENOMEM;
>
> for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> struct v4l2_ctrl_config cfg = { NULL };
--
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com
Re: [PATCHv3 1/1] Add ir-rcmm-driver
Hi Sean,
Sorry, I just checked the first paragraph.
I will send you a new release.
Thanks,
Patrick.
On 07/12/2018 11:12, Sean Young wrote:
Hi Patrick,
On Fri, Dec 07, 2018 at 10:57:21AM +0100, Patrick LERDA wrote:
Add support for RCMM infrared remote controls.
Signed-off-by: Patrick Lerda
Other than the Signed-off-by this looks exactly like the v2 version;
did you see my other comments on the v2 patch?
Thanks
Sean
---
drivers/media/rc/Kconfig | 10 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-rcmm-decoder.c | 185
+
drivers/media/rc/rc-core-priv.h| 5 +
drivers/media/rc/rc-main.c | 3 +
include/media/rc-map.h | 6 +-
include/uapi/linux/lirc.h | 1 +
tools/include/uapi/linux/lirc.h| 1 +
8 files changed, 210 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 1021c08a9ba4..b7e08324b874 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -133,6 +133,16 @@ config IR_IMON_DECODER
remote control and you would like to use it with a raw IR
receiver, or if you wish to use an encoder to transmit this IR.
+config IR_RCMM_DECODER
+ tristate "Enable IR raw decoder for the RC-MM protocol"
+ depends on RC_CORE
+ select BITREVERSE
+ default y
+
+ ---help---
+ Enable this option if you have IR with RC-MM protocol, and
+ if the IR is decoded in software
+
endif #RC_DECODERS
menuconfig RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index e0340d043fe8..fc4058013234 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
+obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
diff --git a/drivers/media/rc/ir-rcmm-decoder.c
b/drivers/media/rc/ir-rcmm-decoder.c
new file mode 100644
index ..94d5b70f7a0f
--- /dev/null
+++ b/drivers/media/rc/ir-rcmm-decoder.c
@@ -0,0 +1,185 @@
+/* ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
+ *
+ * Copyright (C) 2016 by Patrick Lerda
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License as published
by
+ * the Free Software Foundation version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "rc-core-priv.h"
+#include
+#include
+
+
+#define RCMM_UNIT 17 /* nanosecs */
+#define RCMM_0_NBITS 64
+#define RCMM_PREFIX_PULSE 41 /* 16.6*2.5 */
+#define RCMM_PULSE_027 /* 16.6*(1+2/3)
*/
+#define RCMM_PULSE_144 /* 16.6*(2+2/3)
*/
+#define RCMM_PULSE_261 /* 16.6*(3+2/3)
*/
+#define RCMM_PULSE_378 /* 16.6*(4+2/3)
*/
+#define RCMM_MODE_MASK 0x
+
+enum rcmm_state {
+ STATE_INACTIVE,
+ STATE_LOW,
+ STATE_BUMP,
+ STATE_VALUE,
+ STATE_FINISHED,
+};
+
+static bool rcmm_mode(struct rcmm_dec *data)
+{
+return !((0x000c & data->bits) == 0x000c);
+}
+
+/**
+ * ir_rcmm_decode() - Decode one RCMM pulse or space
+ * @dev: the struct rc_dev descriptor of the device
+ * @ev:the struct ir_raw_event descriptor of the pulse/space
+ *
+ * This function returns -EINVAL if the pulse violates the state
machine
+ */
+static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event ev)
+{
+ struct rcmm_dec *data = >raw->rcmm;
+ u32 scancode;
+ u8 toggle;
+
+ if (!(dev->enabled_protocols & RC_PROTO_BIT_RCMM))
+ return 0;
+
+ if (!is_timing_event(ev)) {
+ if (ev.reset)
+ data->state = STATE_INACTIVE;
+ return 0;
+ }
+
+ if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
+ goto out;
+
+ switch (data->state) {
+
+ case STATE_INACTIVE:
+ if (!ev.pulse)
+ break;
+
+ /* Note: larger margin on first pulse since each RCMM_UNIT
+ is quite short and some hardware takes some time to
+ adjust to the signal */
+ if (!eq_margin(ev.duration, RCMM_PREFIX_PULSE, RCMM_UNIT/2))
+ break;
+
+ data->state = STATE_LOW;
+
Re: [PATCH] media: cedrus: don't initialize pointers with zero
Em Fri, 7 Dec 2018 12:27:09 +
Ian Arkver escreveu:
> On 07/12/2018 11:37, Hans Verkuil wrote:
> > On 12/07/2018 12:31 PM, Mauro Carvalho Chehab wrote:
> >> Em Fri, 7 Dec 2018 12:14:50 +0100
> >> Hans Verkuil escreveu:
> >>
> >>> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> A common mistake is to assume that initializing a var with:
> struct foo f = { 0 };
>
> Would initialize a zeroed struct. Actually, what this does is
> to initialize the first element of the struct to zero.
>
> According to C99 Standard 6.7.8.21:
>
> "If there are fewer initializers in a brace-enclosed
> list than there are elements or members of an aggregate,
> or fewer characters in a string literal used to initialize
> an array of known size than there are elements in the array,
> the remainder of the aggregate shall be initialized implicitly
> the same as objects that have static storage duration."
>
> So, in practice, it could zero the entire struct, but, if the
> first element is not an integer, it will produce warnings:
>
>
> drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
> warning: Using plain integer as NULL pointer
>
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
> warning: Using plain integer as NULL pointer
>
> A proper way to initialize it with gcc is to use:
>
> struct foo f = { };
>
> But that seems to be a gcc extension. So, I decided to check upstream
> >>>
> >>> No, this is not a gcc extension. It's part of the latest C standard.
> >>
> >> Sure? Where the C standard spec states that? I've been seeking for
> >> such info for a while, as '= {}' is also my personal preference.
> >
> > I believe it was added in C11, but I've loaned the book that stated
> > that to someone else, so I can't check.
>
> Sadly I don't see mention of empty initializer lists in section 6.7.9 of
> ISO/IEC 9899:2011, though I've only got a draft version.
Yeah, as far as I checked, this is not really part of the standard.
Depending on how you read:
"If there are fewer initializers in a brace-enclosed
list than there are elements or members of an aggregate,
or fewer characters in a string literal used to initialize
an array of known size than there are elements in the array,
the remainder of the aggregate shall be initialized implicitly
the same as objects that have static storage duration."
One may infere that a brace-enclosed list with zero elements
would fit, and "the remainder of the aggregate shall be
initialized implicitly".
I suspect that this is how gcc people interpreted it.
> I had a play with Compiler Explorer[1] and it seems like clang is OK
> with the {} form though just out of interest msvc isn't.
Yeah, I'm aware that msvc won't support it. Good to know that clang
does the right thing cleaning the struct.
To be realistic, we only really care with gcc at the Kernel side, as
clang upstream versions still can't build upstream Kernels, and
nobody uses any other compiler for the Kernel anymore. Yet, with
regards to clang, there's a push to let it to build the Kernel.
So, it seems wise to add something that would work for both.
Anyway, I'll post a version 2 of this patch using ={} and placing
some rationale on it.
> I didn't try
> exploring other command line options.
>
> [1] https://gcc.godbolt.org/z/XIDC7W
>
> Regards,
> Ian
> >
> > In any case, it's used everywhere:
> >
> > git grep '= *{ *}' drivers/
> >
> > So it is really pointless to *not* use it.
> >
> > Regards,
> >
> > Hans
> >
> >> I tried to build the Kernel with clang, just to be sure that this
> >> won't cause issues with the clang support, but, unfortunately, the
> >> clang compiler (not even the upstream version) is able to build
> >> the upstream Kernel yet, as it lacks asm-goto support (there is an
> >> OOT patch for llvm solving it - but it sounds too much effort for
> >> my time to have to build llvm from their sources just for a simple
> >> check like this).
> >>
> >>> It's used all over in the kernel, so please use {} instead of { NULL }.
> >>>
> >>> Personally I think {} is a fantastic invention and I wish C++ had it as
> >>> well.
> >>
> >> Fully agreed on that.
> >>
> >>>
> >>> Regards,
> >>>
> >>> Hans
> >>>
> what's the most commonly pattern. The gcc pattern has about 2000 entries:
>
> $ git grep -E "=\s*\{\s*\}"|wc -l
> 1951
>
> The standard-C compliant pattern has about 2500 entries:
>
> $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
> 137
> $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
> 2323
>
> So, let's initialize those structs with:
> = { NULL }
>
> Signed-off-by: Mauro Carvalho Chehab
Re: [PATCH v9 00/13] media: staging/imx7: add i.MX7 media driver
On 11/22/2018 04:18 PM, Rui Miguel Silva wrote:
> Hi,
> This series introduces the Media driver to work with the i.MX7 SoC. it uses
> the
> already existing imx media core drivers but since the i.MX7, contrary to
> i.MX5/6, do not have an IPU and because of that some changes in the imx media
> core are made along this series to make it support that case.
>
> This patches adds CSI and MIPI-CSI2 drivers for i.MX7, along with several
> configurations changes for this to work as a capture subsystem. Some bugs are
> also fixed along the line. And necessary documentation.
>
> For a more detailed view of the capture paths, pads links in the i.MX7 please
> take a look at the documentation in PATCH 10.
>
> The system used to test and develop this was the Warp7 board with an OV2680
> sensor, which output format is 10-bit bayer. So, only MIPI interface was
> tested, a scenario with an parallel input would nice to have.
I got a few checkpatch warnings about coding style:
CHECK: Alignment should match open parenthesis
#953: FILE: drivers/staging/media/imx/imx7-media-csi.c:911:
+static struct v4l2_mbus_framefmt *imx7_csi_get_format(struct imx7_csi *csi,
+ struct v4l2_subdev_pad_config *cfg,
CHECK: Alignment should match open parenthesis
#1341: FILE: drivers/staging/media/imx/imx7-media-csi.c:1299:
+ ret = v4l2_async_register_fwnode_subdev(>sd,
+ sizeof(struct v4l2_async_subdev),
CHECK: Lines should not end with a '('
#684: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:669:
+static struct csis_pix_format const *mipi_csis_try_format(
CHECK: Alignment should match open parenthesis
#708: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:693:
+static struct v4l2_mbus_framefmt *mipi_csis_get_format(struct csi_state *state,
+ struct v4l2_subdev_pad_config *cfg,
CHECK: Alignment should match open parenthesis
#936: FILE: drivers/staging/media/imx/imx7-mipi-csis.c:921:
+ ret = v4l2_async_register_fwnode_subdev(mipi_sd,
+ sizeof(struct v4l2_async_subdev), _port, 1,
Apparently the latest coding style is that alignment is more important than
line length, although I personally do not agree. But since you need to
respin in any case due to the wrong SPDX identifier you used you might as
well take this into account.
I was really hoping I could merge this, but the SPDX license issue killed it.
Regards,
Hans
>
>
> Bellow goes an example of the output of the pads and links and the output of
> v4l2-compliance testing.
>
> The v4l-utils version used is:
> v4l2-compliance SHA : 044d5ab7b0d02683070d01a369c73d462d7a0cee from Nov 19th
>
> The Media Driver fail some tests but this failures are coming from code out of
> scope of this series (imx-capture), and some from the sensor OV2680
> but that I think not related with the sensor driver but with the testing and
> core.
>
> The csi and mipi-csi entities pass all compliance tests.
>
> Cheers,
> Rui
>
> v8->v9:
> Hans Verkuil:
> - Fix issues detected by checkpatch strict, still some left:
> - bigger kconfig option description
> - some alignement parenthesis that were left as they are, to be more
> readable
> - added new patch (PATCH13) for Maintainers update
> - SPDX in documentation rst file
> Sakari Ailus:
> - remove pad check in csi, this is done by core already
> - destroy mutex in probe error path (add label)
> - swap order in driver release
> - initialize endpoint in stack
> - use clk_bulk
> kbuild test robot:
> - add the missing imx-media-dev-common.c in patch 1/13
> - remove OWNER of module csis
> Myself:
> - add MAINTAINERS entries - new patch
>
> v7->v8:
> Myself:
> - rebase to latest linux-next (s/V4L2_MBUS_CSI2/V4L2_MBUS_CSI2_DPHY/)
> - Rebuild and test with latest v4l2-compliance
> - add Sakari reviewed-by tag to dt-bindings
>
> v6->v7:
> Myself:
> - Clock patches removed from this version since they were already merged
> - Rebuild and test with the latest v4l2-compliance
> - Add patch to video-mux regarding bayer formats
> - remove reference to dependent patch serie (was already merged)
>
> Sakari Ailus:
> - add port and endpoint explanantions
> - fix some wording should -> shall
>
> v5->v6:
> Rob Herring:
> - rename power-domain node name from: pgc-power-domain to power-domain
> - change mux-control-cells to 0
> - remove bus-width from mipi bindings and dts
> - remove err... regarding clock names line
> - remove clk-settle from example
> - split mipi-csi2 and csi bindings per file
> - add OF graph description to CSI
>
> Philipp Zabel:
> - rework group IDs and rename them with an _IPU_ prefix, this allowed to
> remove
>the ipu_present flag need.
>
> v4->v5:
> Sakari Ailus:
> - fix remove of the capture entries in dts bindings in the right patch
>
> Stephen Boyd:
> - Send all series to clk list
>
> v3->v4:
> Philipp Zabel:
> -
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
Em Fri, 7 Dec 2018 12:47:24 +0100 Hans Verkuil escreveu: > On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote: > > Em Fri, 7 Dec 2018 10:09:04 +0100 > > Hans Verkuil escreveu: > > > >> This patch selects MEDIA_CONTROLLER for all camera, analog TV and > >> digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. > >> > >> This will allow us to simplify drivers that currently have to add > >> #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API > >> to their code, since now this will always be available. > >> > >> The original intent of allowing these to be configured by the > >> user was (I think) to save a bit of memory. > > > > No. The original intent was/is to be sure that adding the media > > controller support won't be breaking existing working drivers. > > That doesn't make sense. If enabling this option would break existing > drivers, then something is really wrong, isn't it? It is the opposite: disabling it should not break any driver that don't depend on them to work. > > > > >> But as more and more > >> drivers have a media controller and all regular distros already > >> enable one or more of those drivers, the memory for the MC code is > >> there anyway. > >> > >> Complexity has always been the bane of media drivers, so reducing > >> complexity at the expense of a bit more memory (which is a rounding > >> error compared to the amount of video buffer memory needed) is IMHO > >> a good thing. > >> > >> Signed-off-by: Hans Verkuil > >> --- > >> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig > >> index 8add62a18293..56eb01cc8bb4 100644 > >> --- a/drivers/media/Kconfig > >> +++ b/drivers/media/Kconfig > >> @@ -31,6 +31,7 @@ comment "Multimedia core support" > >> # > >> config MEDIA_CAMERA_SUPPORT > >>bool "Cameras/video grabbers support" > >> + select MEDIA_CONTROLLER > >>---help--- > >> Enable support for webcams and video grabbers. > >> > >> @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT > >> > >> config MEDIA_ANALOG_TV_SUPPORT > >>bool "Analog TV support" > >> + select MEDIA_CONTROLLER > >>---help--- > >> Enable analog TV support. > >> > >> @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT > >> > >> config MEDIA_DIGITAL_TV_SUPPORT > >>bool "Digital TV support" > >> + select MEDIA_CONTROLLER > >>---help--- > >> Enable digital TV support. > > > > See my comments below. > > > >> > >> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" > >> > >> config MEDIA_CONTROLLER > >>bool "Media Controller API" > >> - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > >> MEDIA_DIGITAL_TV_SUPPORT > >>---help--- > >> Enable the media controller API used to query media devices internal > >> topology and configure it dynamically. > > > > I have split comments with regards to it. Yeah, nowadays media controller > > has becoming more important. Still, a lot of media drivers work fine > > without them. > > > > Anyway, if we're willing to make it mandatory, better to just remove the > > entire config option or to make it a silent one. > > Well, that assumes that the media controller will only be used by media > drivers, and not alsa or anyone else who wants to experiment with the MC. > > I won't object to making it silent (since it does reflect the current > situation), but since this functionality is not actually specific to media > drivers I think that is a good case to be made to allow it to be selected > manually. > > > > >> @@ -119,16 +121,11 @@ config VIDEO_DEV > >>tristate > >>depends on MEDIA_SUPPORT > >>depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > >> MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT > >> + select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER > >>default y > >> > >> config VIDEO_V4L2_SUBDEV_API > >> - bool "V4L2 sub-device userspace API" > >> - depends on VIDEO_DEV && MEDIA_CONTROLLER > >> - ---help--- > >> -Enables the V4L2 sub-device pad-level userspace API used to configure > >> -video format, size and frame rate between hardware blocks. > >> - > >> -This API is mostly used by camera interfaces in embedded platforms. > >> + bool > > > > NACK. > > > > There is a very good reason why the subdev API is optional: there > > are drivers that use camera sensors but are not MC-centric. On those, > > the USB bridge driver is responsible to setup the subdevice. > > > > This options helps to ensure that camera sensors used by such drivers > > won't stop working because of the lack of the subdev-API. > > But they won't stop working if this is enabled. That's not the issue. I've seen (and nacked) several patches breaking drivers by assuming that all init would happen via subdev API. By having this as an optional feature that can be disabled, developers need to ensure that either the driver won't be built as a hole, if no subdev API suport is enabled, or need to add the needed logic inside the sub-device
Re: [PATCH v9 05/13] media: dt-bindings: add bindings for i.MX7 media driver
On 11/22/2018 04:18 PM, Rui Miguel Silva wrote:
> Add bindings documentation for i.MX7 media drivers.
> The imx7 MIPI CSI2 and imx7 CMOS Sensor Interface.
>
> Signed-off-by: Rui Miguel Silva
> Reviewed-by: Rob Herring
> Acked-by: Sakari Ailus
Please move this patch to the beginning of the series to avoid
checkpatch warnings:
WARNING: DT compatible string "fsl,imx7-csi" appears un-documented -- check
./Documentation/devicetree/bindings/
#1378: FILE: drivers/staging/media/imx/imx7-media-csi.c:1336:
+ { .compatible = "fsl,imx7-csi" },
Thanks!
Hans
> ---
> .../devicetree/bindings/media/imx7-csi.txt| 45 ++
> .../bindings/media/imx7-mipi-csi2.txt | 90 +++
> 2 files changed, 135 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/imx7-csi.txt
> create mode 100644 Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
>
> diff --git a/Documentation/devicetree/bindings/media/imx7-csi.txt
> b/Documentation/devicetree/bindings/media/imx7-csi.txt
> new file mode 100644
> index ..3c07bc676bc3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx7-csi.txt
> @@ -0,0 +1,45 @@
> +Freescale i.MX7 CMOS Sensor Interface
> +=
> +
> +csi node
> +
> +
> +This is device node for the CMOS Sensor Interface (CSI) which enables the
> chip
> +to connect directly to external CMOS image sensors.
> +
> +Required properties:
> +
> +- compatible: "fsl,imx7-csi";
> +- reg : base address and length of the register set for the device;
> +- interrupts: should contain CSI interrupt;
> +- clocks: list of clock specifiers, see
> +Documentation/devicetree/bindings/clock/clock-bindings.txt for
> details;
> +- clock-names : must contain "axi", "mclk" and "dcic" entries, matching
> + entries in the clock property;
> +
> +The device node shall contain one 'port' child node with one child 'endpoint'
> +node, according to the bindings defined in:
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +In the following example a remote endpoint is a video multiplexer.
> +
> +example:
> +
> +csi: csi@3071 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +compatible = "fsl,imx7-csi";
> +reg = <0x3071 0x1>;
> +interrupts = ;
> +clocks = < IMX7D_CLK_DUMMY>,
> +< IMX7D_CSI_MCLK_ROOT_CLK>,
> +< IMX7D_CLK_DUMMY>;
> +clock-names = "axi", "mclk", "dcic";
> +
> +port {
> +csi_from_csi_mux: endpoint {
> +remote-endpoint = <_mux_to_csi>;
> +};
> +};
> +};
> diff --git a/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
> b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
> new file mode 100644
> index ..71fd74ed3ec8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
> @@ -0,0 +1,90 @@
> +Freescale i.MX7 Mipi CSI2
> +=
> +
> +mipi_csi2 node
> +--
> +
> +This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
> +compatible with previous version of Samsung D-phy.
> +
> +Required properties:
> +
> +- compatible: "fsl,imx7-mipi-csi2";
> +- reg : base address and length of the register set for the device;
> +- interrupts: should contain MIPI CSIS interrupt;
> +- clocks: list of clock specifiers, see
> +Documentation/devicetree/bindings/clock/clock-bindings.txt for
> details;
> +- clock-names : must contain "pclk", "wrap" and "phy" entries, matching
> + entries in the clock property;
> +- power-domains : a phandle to the power domain, see
> + Documentation/devicetree/bindings/power/power_domain.txt for
> details.
> +- reset-names : should include following entry "mrst";
> +- resets: a list of phandle, should contain reset entry of
> + reset-names;
> +- phy-supply: from the generic phy bindings, a phandle to a regulator
> that
> + provides power to MIPI CSIS core;
> +
> +Optional properties:
> +
> +- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
> + value when this property is not specified is 166 MHz;
> +- fsl,csis-hs-settle : differential receiver (HS-RX) settle time;
> +
> +The device node should contain two 'port' child nodes with one child
> 'endpoint'
> +node, according to the bindings defined in:
> + Documentation/devicetree/bindings/ media/video-interfaces.txt.
> + The following are properties specific to those nodes.
>
Re: [PATCH v9 01/13] media: staging/imx: refactor imx media device probe
On 11/22/2018 04:18 PM, Rui Miguel Silva wrote: > Refactor and move media device initialization code to a new common > module, so it can be used by other devices, this will allow for example > a near to introduce imx7 CSI driver, to use this media device. > > Signed-off-by: Rui Miguel Silva > --- > drivers/staging/media/imx/Makefile| 1 + > .../staging/media/imx/imx-media-dev-common.c | 102 ++ > drivers/staging/media/imx/imx-media-dev.c | 88 --- > drivers/staging/media/imx/imx-media-of.c | 6 +- > drivers/staging/media/imx/imx-media.h | 15 +++ > 5 files changed, 141 insertions(+), 71 deletions(-) > create mode 100644 drivers/staging/media/imx/imx-media-dev-common.c > > diff --git a/drivers/staging/media/imx/Makefile > b/drivers/staging/media/imx/Makefile > index 698a4210316e..a30b3033f9a3 100644 > --- a/drivers/staging/media/imx/Makefile > +++ b/drivers/staging/media/imx/Makefile > @@ -1,5 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o > +imx-media-objs += imx-media-dev-common.o > imx-media-common-objs := imx-media-utils.o imx-media-fim.o > imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o > > diff --git a/drivers/staging/media/imx/imx-media-dev-common.c > b/drivers/staging/media/imx/imx-media-dev-common.c > new file mode 100644 > index ..55fe94fb72f2 > --- /dev/null > +++ b/drivers/staging/media/imx/imx-media-dev-common.c > @@ -0,0 +1,102 @@ > +// SPDX-License-Identifier: GPL This is an invalid SPDX license identifier. You probably want to use GPL-2.0. This happens in more patches, please check! Regards, Hans
[GIT PULL FOR v4.21] Various fixes/enhancements
Note: there are a few patches that combine bindings with code changes. But since these are older patches and the bindings have already been reviewed I am not going to require the author to split them up. That's a bit overkill. If new patches arrive that have this problem, then I will request this going forward. Regards, Hans The following changes since commit 3c28b91380dd1183347d32d87d820818031ebecf: media: stkwebcam: Bugfix for wrong return values (2018-12-05 14:10:48 -0500) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21i for you to fetch changes up to 54efad597804e6846ab860e7c2af84af529c669c: media: cedrus: Add device-tree compatible and variant for A64 support (2018-12-07 13:12:34 +0100) Tag branch Akinobu Mita (1): media: video-i2c: support runtime PM Colin Ian King (2): media: pvrusb2: fix spelling mistake "statuss" -> "status" media: sun6i: fix spelling mistake "droped" -> "dropped" Dmitry Osipenko (1): media: staging: tegra-vde: Replace debug messages with trace points Ezequiel Garcia (1): v4l2-ioctl: Zero v4l2_plane_pix_format reserved fields Gabriel Francisco Mandaji (1): media: vivid: Improve timestamping Kelvin Lawson (1): media: venus: Support V4L2 QP parameters in Venus encoder Lubomir Rintel (1): marvell-ccic: trivial fix to the datasheet URL Luca Ceresoli (1): media: v4l2-subdev: document controls need _FL_HAS_DEVNODE Malathi Gottam (1): media: venus: add support for key frame Matt Ranostay (1): media: video-i2c: check if chip struct has set_power function Paul Kocialkowski (4): media: cedrus: Remove global IRQ spin lock from the driver dt-bindings: media: cedrus: Add compatibles for the A64 and H5 media: cedrus: Add device-tree compatible and variant for H5 support media: cedrus: Add device-tree compatible and variant for A64 support Philipp Zabel (2): media: v4l2: clarify H.264 loop filter offset controls media: coda: fix H.264 deblocking filter controls Rob Herring (2): media: Use of_node_name_eq for node name comparisons staging: media: imx: Use of_node_name_eq for node name comparisons Sergei Shtylyov (2): rcar-csi2: add R8A77980 support rcar-vin: add R8A77980 support Todor Tomov (1): MAINTAINERS: Change Todor Tomov's email address Vivek Gautam (1): media: venus: core: Set dma maximum segment size Documentation/devicetree/bindings/media/cedrus.txt| 2 + Documentation/devicetree/bindings/media/rcar_vin.txt | 1 + Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 1 + Documentation/media/uapi/v4l/extended-controls.rst| 6 ++ MAINTAINERS | 2 +- drivers/media/i2c/video-i2c.c | 153 +- drivers/media/platform/coda/coda-bit.c| 19 ++-- drivers/media/platform/coda/coda-common.c | 15 ++- drivers/media/platform/coda/coda.h| 6 +- drivers/media/platform/coda/coda_regs.h | 2 +- drivers/media/platform/exynos4-is/media-dev.c | 12 +-- drivers/media/platform/marvell-ccic/cafe-driver.c | 2 +- drivers/media/platform/qcom/venus/core.c | 8 ++ drivers/media/platform/qcom/venus/venc.c | 19 drivers/media/platform/qcom/venus/venc_ctrls.c| 19 +++- drivers/media/platform/rcar-vin/rcar-core.c | 32 ++ drivers/media/platform/rcar-vin/rcar-csi2.c | 11 ++ drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c | 4 +- drivers/media/platform/ti-vpe/cal.c | 4 +- drivers/media/platform/vivid/vivid-core.h | 3 + drivers/media/platform/vivid/vivid-kthread-cap.c | 51 ++--- drivers/media/platform/vivid/vivid-vbi-cap.c | 4 - drivers/media/platform/xilinx/xilinx-tpg.c| 2 +- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 2 +- drivers/media/v4l2-core/v4l2-fwnode.c | 6 +- drivers/media/v4l2-core/v4l2-ioctl.c | 10 ++ drivers/staging/media/imx/imx-media-of.c | 2 +- drivers/staging/media/sunxi/cedrus/cedrus.c | 17 ++- drivers/staging/media/sunxi/cedrus/cedrus.h | 2 - drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 9 -- drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 13 +-- drivers/staging/media/sunxi/cedrus/cedrus_video.c | 5 -
Re: [PATCH] media: cedrus: don't initialize pointers with zero
On 07/12/2018 11:37, Hans Verkuil wrote:
On 12/07/2018 12:31 PM, Mauro Carvalho Chehab wrote:
Em Fri, 7 Dec 2018 12:14:50 +0100
Hans Verkuil escreveu:
On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
A common mistake is to assume that initializing a var with:
struct foo f = { 0 };
Would initialize a zeroed struct. Actually, what this does is
to initialize the first element of the struct to zero.
According to C99 Standard 6.7.8.21:
"If there are fewer initializers in a brace-enclosed
list than there are elements or members of an aggregate,
or fewer characters in a string literal used to initialize
an array of known size than there are elements in the array,
the remainder of the aggregate shall be initialized implicitly
the same as objects that have static storage duration."
So, in practice, it could zero the entire struct, but, if the
first element is not an integer, it will produce warnings:
drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
warning: Using plain integer as NULL pointer
drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
warning: Using plain integer as NULL pointer
A proper way to initialize it with gcc is to use:
struct foo f = { };
But that seems to be a gcc extension. So, I decided to check upstream
No, this is not a gcc extension. It's part of the latest C standard.
Sure? Where the C standard spec states that? I've been seeking for
such info for a while, as '= {}' is also my personal preference.
I believe it was added in C11, but I've loaned the book that stated
that to someone else, so I can't check.
Sadly I don't see mention of empty initializer lists in section 6.7.9 of
ISO/IEC 9899:2011, though I've only got a draft version.
I had a play with Compiler Explorer[1] and it seems like clang is OK
with the {} form though just out of interest msvc isn't. I didn't try
exploring other command line options.
[1] https://gcc.godbolt.org/z/XIDC7W
Regards,
Ian
In any case, it's used everywhere:
git grep '= *{ *}' drivers/
So it is really pointless to *not* use it.
Regards,
Hans
I tried to build the Kernel with clang, just to be sure that this
won't cause issues with the clang support, but, unfortunately, the
clang compiler (not even the upstream version) is able to build
the upstream Kernel yet, as it lacks asm-goto support (there is an
OOT patch for llvm solving it - but it sounds too much effort for
my time to have to build llvm from their sources just for a simple
check like this).
It's used all over in the kernel, so please use {} instead of { NULL }.
Personally I think {} is a fantastic invention and I wish C++ had it as
well.
Fully agreed on that.
Regards,
Hans
what's the most commonly pattern. The gcc pattern has about 2000 entries:
$ git grep -E "=\s*\{\s*\}"|wc -l
1951
The standard-C compliant pattern has about 2500 entries:
$ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
137
$ git grep -E "=\s*\{\s*0\s*\}"|wc -l
2323
So, let's initialize those structs with:
= { NULL }
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index b538eb0321d8..44c45c687503 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct
cedrus_ctx *ctx)
memset(ctx->ctrls, 0, ctrl_size);
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
- struct v4l2_ctrl_config cfg = { 0 };
+ struct v4l2_ctrl_config cfg = { NULL };
cfg.elem_size = cedrus_controls[i].elem_size;
cfg.id = cedrus_controls[i].id;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..4099a42dba2d 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
{
struct cedrus_ctx *ctx = priv;
struct cedrus_dev *dev = ctx->dev;
- struct cedrus_run run = { 0 };
+ struct cedrus_run run = { NULL };
struct media_request *src_req;
unsigned long flags;
Thanks,
Mauro
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
On 12/07/2018 12:26 PM, Mauro Carvalho Chehab wrote: > Em Fri, 7 Dec 2018 10:09:04 +0100 > Hans Verkuil escreveu: > >> This patch selects MEDIA_CONTROLLER for all camera, analog TV and >> digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. >> >> This will allow us to simplify drivers that currently have to add >> #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API >> to their code, since now this will always be available. >> >> The original intent of allowing these to be configured by the >> user was (I think) to save a bit of memory. > > No. The original intent was/is to be sure that adding the media > controller support won't be breaking existing working drivers. That doesn't make sense. If enabling this option would break existing drivers, then something is really wrong, isn't it? > >> But as more and more >> drivers have a media controller and all regular distros already >> enable one or more of those drivers, the memory for the MC code is >> there anyway. >> >> Complexity has always been the bane of media drivers, so reducing >> complexity at the expense of a bit more memory (which is a rounding >> error compared to the amount of video buffer memory needed) is IMHO >> a good thing. >> >> Signed-off-by: Hans Verkuil >> --- >> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig >> index 8add62a18293..56eb01cc8bb4 100644 >> --- a/drivers/media/Kconfig >> +++ b/drivers/media/Kconfig >> @@ -31,6 +31,7 @@ comment "Multimedia core support" >> # >> config MEDIA_CAMERA_SUPPORT >> bool "Cameras/video grabbers support" >> +select MEDIA_CONTROLLER >> ---help--- >>Enable support for webcams and video grabbers. >> >> @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT >> >> config MEDIA_ANALOG_TV_SUPPORT >> bool "Analog TV support" >> +select MEDIA_CONTROLLER >> ---help--- >>Enable analog TV support. >> >> @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT >> >> config MEDIA_DIGITAL_TV_SUPPORT >> bool "Digital TV support" >> +select MEDIA_CONTROLLER >> ---help--- >>Enable digital TV support. > > See my comments below. > >> >> @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" >> >> config MEDIA_CONTROLLER >> bool "Media Controller API" >> -depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || >> MEDIA_DIGITAL_TV_SUPPORT >> ---help--- >>Enable the media controller API used to query media devices internal >>topology and configure it dynamically. > > I have split comments with regards to it. Yeah, nowadays media controller > has becoming more important. Still, a lot of media drivers work fine > without them. > > Anyway, if we're willing to make it mandatory, better to just remove the > entire config option or to make it a silent one. Well, that assumes that the media controller will only be used by media drivers, and not alsa or anyone else who wants to experiment with the MC. I won't object to making it silent (since it does reflect the current situation), but since this functionality is not actually specific to media drivers I think that is a good case to be made to allow it to be selected manually. > >> @@ -119,16 +121,11 @@ config VIDEO_DEV >> tristate >> depends on MEDIA_SUPPORT >> depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || >> MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT >> +select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER >> default y >> >> config VIDEO_V4L2_SUBDEV_API >> -bool "V4L2 sub-device userspace API" >> -depends on VIDEO_DEV && MEDIA_CONTROLLER >> ----help--- >> - Enables the V4L2 sub-device pad-level userspace API used to configure >> - video format, size and frame rate between hardware blocks. >> - >> - This API is mostly used by camera interfaces in embedded platforms. >> +bool > > NACK. > > There is a very good reason why the subdev API is optional: there > are drivers that use camera sensors but are not MC-centric. On those, > the USB bridge driver is responsible to setup the subdevice. > > This options helps to ensure that camera sensors used by such drivers > won't stop working because of the lack of the subdev-API. But they won't stop working if this is enabled. This option is used as a dependency by drivers that require this functionality, but enabling it will never break other drivers that don't need this. Those drivers simply won't use it. Also note that it is the bridge driver that controls whether or not the v4l-subdevX devices are created. If the bridge driver doesn't explicitly enable it AND the subdev driver explicitly supports it, those devices will not be created. Regards, Hans > >> >> source "drivers/media/v4l2-core/Kconfig" >> > > > > Thanks, > Mauro >
[PATCH] media: imx214: don't de-reference a NULL pointer
As warned by smatch: drivers/media/i2c/imx214.c:591 imx214_set_format() warn: variable dereferenced before check 'format' (see line 589) It turns that the code at imx214_set_format() has support for being called with the format being NULL. I've no idea why, as it is only called internally with the pointer set, and via subdev API (with should also set it). Also, the entire logic there depends on having format != NULL, so just remove the bogus broken support for a null format. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/i2c/imx214.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/media/i2c/imx214.c b/drivers/media/i2c/imx214.c index ec3d1b855f62..b046a26219a4 100644 --- a/drivers/media/i2c/imx214.c +++ b/drivers/media/i2c/imx214.c @@ -588,12 +588,10 @@ static int imx214_set_format(struct v4l2_subdev *sd, __crop = __imx214_get_pad_crop(imx214, cfg, format->pad, format->which); - if (format) - mode = v4l2_find_nearest_size(imx214_modes, - ARRAY_SIZE(imx214_modes), width, height, - format->format.width, format->format.height); - else - mode = _modes[0]; + mode = v4l2_find_nearest_size(imx214_modes, + ARRAY_SIZE(imx214_modes), width, height, + format->format.width, + format->format.height); __crop->width = mode->width; __crop->height = mode->height; -- 2.19.2
Re: [PATCH] media: cedrus: don't initialize pointers with zero
On 12/07/2018 12:31 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 7 Dec 2018 12:14:50 +0100
> Hans Verkuil escreveu:
>
>> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
>>> A common mistake is to assume that initializing a var with:
>>> struct foo f = { 0 };
>>>
>>> Would initialize a zeroed struct. Actually, what this does is
>>> to initialize the first element of the struct to zero.
>>>
>>> According to C99 Standard 6.7.8.21:
>>>
>>> "If there are fewer initializers in a brace-enclosed
>>> list than there are elements or members of an aggregate,
>>> or fewer characters in a string literal used to initialize
>>> an array of known size than there are elements in the array,
>>> the remainder of the aggregate shall be initialized implicitly
>>> the same as objects that have static storage duration."
>>>
>>> So, in practice, it could zero the entire struct, but, if the
>>> first element is not an integer, it will produce warnings:
>>>
>>>
>>> drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
>>> warning: Using plain integer as NULL pointer
>>>
>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
>>> warning: Using plain integer as NULL pointer
>>>
>>> A proper way to initialize it with gcc is to use:
>>>
>>> struct foo f = { };
>>>
>>> But that seems to be a gcc extension. So, I decided to check upstream
>>
>> No, this is not a gcc extension. It's part of the latest C standard.
>
> Sure? Where the C standard spec states that? I've been seeking for
> such info for a while, as '= {}' is also my personal preference.
I believe it was added in C11, but I've loaned the book that stated
that to someone else, so I can't check.
In any case, it's used everywhere:
git grep '= *{ *}' drivers/
So it is really pointless to *not* use it.
Regards,
Hans
> I tried to build the Kernel with clang, just to be sure that this
> won't cause issues with the clang support, but, unfortunately, the
> clang compiler (not even the upstream version) is able to build
> the upstream Kernel yet, as it lacks asm-goto support (there is an
> OOT patch for llvm solving it - but it sounds too much effort for
> my time to have to build llvm from their sources just for a simple
> check like this).
>
>> It's used all over in the kernel, so please use {} instead of { NULL }.
>>
>> Personally I think {} is a fantastic invention and I wish C++ had it as
>> well.
>
> Fully agreed on that.
>
>>
>> Regards,
>>
>> Hans
>>
>>> what's the most commonly pattern. The gcc pattern has about 2000 entries:
>>>
>>> $ git grep -E "=\s*\{\s*\}"|wc -l
>>> 1951
>>>
>>> The standard-C compliant pattern has about 2500 entries:
>>>
>>> $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
>>> 137
>>> $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
>>> 2323
>>>
>>> So, let's initialize those structs with:
>>> = { NULL }
>>>
>>> Signed-off-by: Mauro Carvalho Chehab
>>> ---
>>> drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> b/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> index b538eb0321d8..44c45c687503 100644
>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev,
>>> struct cedrus_ctx *ctx)
>>> memset(ctx->ctrls, 0, ctrl_size);
>>>
>>> for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
>>> - struct v4l2_ctrl_config cfg = { 0 };
>>> + struct v4l2_ctrl_config cfg = { NULL };
>>>
>>> cfg.elem_size = cedrus_controls[i].elem_size;
>>> cfg.id = cedrus_controls[i].id;
>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> index e40180a33951..4099a42dba2d 100644
>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
>>> {
>>> struct cedrus_ctx *ctx = priv;
>>> struct cedrus_dev *dev = ctx->dev;
>>> - struct cedrus_run run = { 0 };
>>> + struct cedrus_run run = { NULL };
>>> struct media_request *src_req;
>>> unsigned long flags;
>>>
>>>
>>
>
>
>
> Thanks,
> Mauro
>
Re: [PATCH] media: cedrus: don't initialize pointers with zero
Em Fri, 7 Dec 2018 12:14:50 +0100
Hans Verkuil escreveu:
> On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> > A common mistake is to assume that initializing a var with:
> > struct foo f = { 0 };
> >
> > Would initialize a zeroed struct. Actually, what this does is
> > to initialize the first element of the struct to zero.
> >
> > According to C99 Standard 6.7.8.21:
> >
> > "If there are fewer initializers in a brace-enclosed
> > list than there are elements or members of an aggregate,
> > or fewer characters in a string literal used to initialize
> > an array of known size than there are elements in the array,
> > the remainder of the aggregate shall be initialized implicitly
> > the same as objects that have static storage duration."
> >
> > So, in practice, it could zero the entire struct, but, if the
> > first element is not an integer, it will produce warnings:
> >
> >
> > drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
> > warning: Using plain integer as NULL pointer
> >
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
> > warning: Using plain integer as NULL pointer
> >
> > A proper way to initialize it with gcc is to use:
> >
> > struct foo f = { };
> >
> > But that seems to be a gcc extension. So, I decided to check upstream
>
> No, this is not a gcc extension. It's part of the latest C standard.
Sure? Where the C standard spec states that? I've been seeking for
such info for a while, as '= {}' is also my personal preference.
I tried to build the Kernel with clang, just to be sure that this
won't cause issues with the clang support, but, unfortunately, the
clang compiler (not even the upstream version) is able to build
the upstream Kernel yet, as it lacks asm-goto support (there is an
OOT patch for llvm solving it - but it sounds too much effort for
my time to have to build llvm from their sources just for a simple
check like this).
> It's used all over in the kernel, so please use {} instead of { NULL }.
>
> Personally I think {} is a fantastic invention and I wish C++ had it as
> well.
Fully agreed on that.
>
> Regards,
>
> Hans
>
> > what's the most commonly pattern. The gcc pattern has about 2000 entries:
> >
> > $ git grep -E "=\s*\{\s*\}"|wc -l
> > 1951
> >
> > The standard-C compliant pattern has about 2500 entries:
> >
> > $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
> > 137
> > $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
> > 2323
> >
> > So, let's initialize those structs with:
> > = { NULL }
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > index b538eb0321d8..44c45c687503 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev,
> > struct cedrus_ctx *ctx)
> > memset(ctx->ctrls, 0, ctrl_size);
> >
> > for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> > - struct v4l2_ctrl_config cfg = { 0 };
> > + struct v4l2_ctrl_config cfg = { NULL };
> >
> > cfg.elem_size = cedrus_controls[i].elem_size;
> > cfg.id = cedrus_controls[i].id;
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > index e40180a33951..4099a42dba2d 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
> > {
> > struct cedrus_ctx *ctx = priv;
> > struct cedrus_dev *dev = ctx->dev;
> > - struct cedrus_run run = { 0 };
> > + struct cedrus_run run = { NULL };
> > struct media_request *src_req;
> > unsigned long flags;
> >
> >
>
Thanks,
Mauro
Re: [PATCH 4/5 RESEND] si470x-i2c: Add optional reset-gpio support
Adding the actual author :-)
Regards,
Hans
On 12/07/2018 12:25 PM, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Fri, Dec 7, 2018 at 12:12 PM Hans Verkuil wrote:
>>
>> Subject: [PATCH 4/5] si470x-i2c: Add optional reset-gpio support
>> Date: Wed, 5 Dec 2018 16:47:49 +0100
>> From: Paweł Chmiel
>> To: mche...@kernel.org, robh...@kernel.org, mark.rutl...@arm.com
>> CC: hverk...@xs4all.nl, fischerdougl...@gmail.com, keesc...@chromium.org,
>> linux-media@vger.kernel.org, linux-ker...@vger.kernel.org,
>> devicet...@vger.kernel.org, Paweł Chmiel
>>
>> If reset-gpio is defined, use it to bring device out of reset.
>> Without this, it's not possible to access si470x registers.
>>
>> Signed-off-by: Paweł Chmiel
>> ---
>> For some reason this patch was not picked up by patchwork. Resending to see
>> if
>> it is picked up now.
>> ---
>> drivers/media/radio/si470x/radio-si470x-i2c.c | 15 +++
>> drivers/media/radio/si470x/radio-si470x.h | 1 +
>> 2 files changed, 16 insertions(+)
>>
>> diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
>> b/drivers/media/radio/si470x/radio-si470x-i2c.c
>> index a7ac09c55188..15eea2b2c90f 100644
>> --- a/drivers/media/radio/si470x/radio-si470x-i2c.c
>> +++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
>> @@ -28,6 +28,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include "radio-si470x.h"
>> @@ -392,6 +393,17 @@ static int si470x_i2c_probe(struct i2c_client *client,
>> radio->videodev.release = video_device_release_empty;
>> video_set_drvdata(>videodev, radio);
>> + radio->gpio_reset = devm_gpiod_get_optional(>dev, "reset",
>> + GPIOD_OUT_LOW);
>> + if (IS_ERR(radio->gpio_reset)) {
>> + retval = PTR_ERR(radio->gpio_reset);
>> + dev_err(>dev, "Failed to request gpio: %d\n",
>> retval);
>> + goto err_all;
>> + }
>> +
>> + if (radio->gpio_reset)
>> + gpiod_set_value(radio->gpio_reset, 1);
>> +
>> /* power up : need 110ms */
>> radio->registers[POWERCFG] = POWERCFG_ENABLE;
>> if (si470x_set_register(radio, POWERCFG) < 0) {
>> @@ -478,6 +490,9 @@ static int si470x_i2c_remove(struct i2c_client *client)
>> video_unregister_device(>videodev);
>> + if (radio->gpio_reset)
>> + gpiod_set_value(radio->gpio_reset, 0);
>
> I have a question for you. If the gpio is the last of the bank
> acquired for this cpu, when you put to 0, then the gpio will
> be free on remove and the clock of the logic will be deactivated so I
> think that you don't have any
> garantee that the state will be 0
>
> Michael
>
>> +
>> return 0;
>> }
>> diff --git a/drivers/media/radio/si470x/radio-si470x.h
>> b/drivers/media/radio/si470x/radio-si470x.h
>> index 35fa0f3bbdd2..6fd6a399cb77 100644
>> --- a/drivers/media/radio/si470x/radio-si470x.h
>> +++ b/drivers/media/radio/si470x/radio-si470x.h
>> @@ -189,6 +189,7 @@ struct si470x_device {
>> #if IS_ENABLED(CONFIG_I2C_SI470X)
>> struct i2c_client *client;
>> + struct gpio_desc *gpio_reset;
>> #endif
>> };
>> -- 2.17.1
>>
>
>
Re: [PATCH v2 2/2] media: video-i2c: add Melexis MLX90640 thermal camera support
On 11/22/2018 04:52 AM, Matt Ranostay wrote:
> Add initial support for MLX90640 thermal cameras which output an 32x24
> greyscale pixel image along with 2 rows of coefficent data.
>
> Because of this the data outputed is really 32x26 and needs the two rows
> removed after using the coefficent information to generate processed
> images in userspace.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Matt Ranostay
> ---
> .../bindings/media/i2c/melexis,mlx90640.txt | 20
> drivers/media/i2c/Kconfig | 1 +
> drivers/media/i2c/video-i2c.c | 110 +-
> 3 files changed, 130 insertions(+), 1 deletion(-)
> create mode 100644
> Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
This patch needs to be split up in two: one for the bindings, one for
the driver changes.
Once the bindings for the v3 of this patch are accepted, I can merge this.
Note that I am in the process of merging '[PATCH v3] media: video-i2c: check if
chip
struct has set_power function', so it shouldn't be necessary to repost that
patch.
Regards,
Hans
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
> b/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
> new file mode 100644
> index ..060d2b7a5893
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt
> @@ -0,0 +1,20 @@
> +* Melexis MLX90640 FIR Sensor
> +
> +Melexis MLX90640 FIR sensor support which allows recording of thermal data
> +with 32x24 resolution excluding 2 lines of coefficient data that is used by
> +userspace to render processed frames.
> +
> +Required Properties:
> + - compatible : Must be "melexis,mlx90640"
> + - reg : i2c address of the device
> +
> +Example:
> +
> + i2c0@1c22000 {
> + ...
> + mlx90640@33 {
> + compatible = "melexis,mlx90640";
> + reg = <0x33>;
> + };
> + ...
> + };
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 66bbbec487ec..24342f283f2a 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -1097,6 +1097,7 @@ config VIDEO_I2C
> Enable the I2C transport video support which supports the
> following:
> * Panasonic AMG88xx Grid-Eye Sensors
> +* Melexis MLX90640 Thermal Cameras
>
> To compile this driver as a module, choose M here: the
> module will be called video-i2c
> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> index a64e1a725a20..d58f40334e8b 100644
> --- a/drivers/media/i2c/video-i2c.c
> +++ b/drivers/media/i2c/video-i2c.c
> @@ -6,6 +6,7 @@
> *
> * Supported:
> * - Panasonic AMG88xx Grid-Eye Sensors
> + * - Melexis MLX90640 Thermal Cameras
> */
>
> #include
> @@ -18,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -66,12 +68,26 @@ static const struct v4l2_frmsize_discrete amg88xx_size = {
> .height = 8,
> };
>
> +static const struct v4l2_fmtdesc mlx90640_format = {
> + .pixelformat = V4L2_PIX_FMT_Y16_BE,
> +};
> +
> +static const struct v4l2_frmsize_discrete mlx90640_size = {
> + .width = 32,
> + .height = 26, /* 24 lines of pixel data + 2 lines of processing data */
> +};
> +
> static const struct regmap_config amg88xx_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> .max_register = 0xff
> };
>
> +static const struct regmap_config mlx90640_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 16,
> +};
> +
> struct video_i2c_chip {
> /* video dimensions */
> const struct v4l2_fmtdesc *format;
> @@ -88,6 +104,7 @@ struct video_i2c_chip {
> unsigned int bpp;
>
> const struct regmap_config *regmap_config;
> + struct nvmem_config *nvmem_config;
>
> /* setup function */
> int (*setup)(struct video_i2c_data *data);
> @@ -102,6 +119,22 @@ struct video_i2c_chip {
> int (*hwmon_init)(struct video_i2c_data *data);
> };
>
> +static int mlx90640_nvram_read(void *priv, unsigned int offset, void *val,
> + size_t bytes)
> +{
> + struct video_i2c_data *data = priv;
> +
> + return regmap_bulk_read(data->regmap, 0x2400 + offset, val, bytes);
> +}
> +
> +static struct nvmem_config mlx90640_nvram_config = {
> + .name = "mlx90640_nvram",
> + .word_size = 2,
> + .stride = 1,
> + .size = 1664,
> + .reg_read = mlx90640_nvram_read,
> +};
> +
> /* Power control register */
> #define AMG88XX_REG_PCTL 0x00
> #define AMG88XX_PCTL_NORMAL 0x00
> @@ -122,12 +155,23 @@ struct video_i2c_chip {
> /* Temperature register */
> #define AMG88XX_REG_T01L 0x80
>
> +/* Control register */
> +#define MLX90640_REG_CTL10x800d
> +#define MLX90640_REG_CTL1_MASK 0x0380
> +#define MLX90640_REG_CTL1_MASK_SHIFT 7
Re: [RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
Em Fri, 7 Dec 2018 10:09:04 +0100 Hans Verkuil escreveu: > This patch selects MEDIA_CONTROLLER for all camera, analog TV and > digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. > > This will allow us to simplify drivers that currently have to add > #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API > to their code, since now this will always be available. > > The original intent of allowing these to be configured by the > user was (I think) to save a bit of memory. No. The original intent was/is to be sure that adding the media controller support won't be breaking existing working drivers. > But as more and more > drivers have a media controller and all regular distros already > enable one or more of those drivers, the memory for the MC code is > there anyway. > > Complexity has always been the bane of media drivers, so reducing > complexity at the expense of a bit more memory (which is a rounding > error compared to the amount of video buffer memory needed) is IMHO > a good thing. > > Signed-off-by: Hans Verkuil > --- > diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig > index 8add62a18293..56eb01cc8bb4 100644 > --- a/drivers/media/Kconfig > +++ b/drivers/media/Kconfig > @@ -31,6 +31,7 @@ comment "Multimedia core support" > # > config MEDIA_CAMERA_SUPPORT > bool "Cameras/video grabbers support" > + select MEDIA_CONTROLLER > ---help--- > Enable support for webcams and video grabbers. > > @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT > > config MEDIA_ANALOG_TV_SUPPORT > bool "Analog TV support" > + select MEDIA_CONTROLLER > ---help--- > Enable analog TV support. > > @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT > > config MEDIA_DIGITAL_TV_SUPPORT > bool "Digital TV support" > + select MEDIA_CONTROLLER > ---help--- > Enable digital TV support. See my comments below. > > @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" > > config MEDIA_CONTROLLER > bool "Media Controller API" > - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > MEDIA_DIGITAL_TV_SUPPORT > ---help--- > Enable the media controller API used to query media devices internal > topology and configure it dynamically. I have split comments with regards to it. Yeah, nowadays media controller has becoming more important. Still, a lot of media drivers work fine without them. Anyway, if we're willing to make it mandatory, better to just remove the entire config option or to make it a silent one. > @@ -119,16 +121,11 @@ config VIDEO_DEV > tristate > depends on MEDIA_SUPPORT > depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || > MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT > + select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER > default y > > config VIDEO_V4L2_SUBDEV_API > - bool "V4L2 sub-device userspace API" > - depends on VIDEO_DEV && MEDIA_CONTROLLER > - ---help--- > - Enables the V4L2 sub-device pad-level userspace API used to configure > - video format, size and frame rate between hardware blocks. > - > - This API is mostly used by camera interfaces in embedded platforms. > + bool NACK. There is a very good reason why the subdev API is optional: there are drivers that use camera sensors but are not MC-centric. On those, the USB bridge driver is responsible to setup the subdevice. This options helps to ensure that camera sensors used by such drivers won't stop working because of the lack of the subdev-API. > > source "drivers/media/v4l2-core/Kconfig" > Thanks, Mauro
Re: [PATCH 4/5 RESEND] si470x-i2c: Add optional reset-gpio support
Hi
On Fri, Dec 7, 2018 at 12:12 PM Hans Verkuil wrote:
>
> Subject: [PATCH 4/5] si470x-i2c: Add optional reset-gpio support
> Date: Wed, 5 Dec 2018 16:47:49 +0100
> From: Paweł Chmiel
> To: mche...@kernel.org, robh...@kernel.org, mark.rutl...@arm.com
> CC: hverk...@xs4all.nl, fischerdougl...@gmail.com, keesc...@chromium.org,
> linux-media@vger.kernel.org, linux-ker...@vger.kernel.org,
> devicet...@vger.kernel.org, Paweł Chmiel
>
> If reset-gpio is defined, use it to bring device out of reset.
> Without this, it's not possible to access si470x registers.
>
> Signed-off-by: Paweł Chmiel
> ---
> For some reason this patch was not picked up by patchwork. Resending to see if
> it is picked up now.
> ---
> drivers/media/radio/si470x/radio-si470x-i2c.c | 15 +++
> drivers/media/radio/si470x/radio-si470x.h | 1 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
> b/drivers/media/radio/si470x/radio-si470x-i2c.c
> index a7ac09c55188..15eea2b2c90f 100644
> --- a/drivers/media/radio/si470x/radio-si470x-i2c.c
> +++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "radio-si470x.h"
> @@ -392,6 +393,17 @@ static int si470x_i2c_probe(struct i2c_client *client,
> radio->videodev.release = video_device_release_empty;
> video_set_drvdata(>videodev, radio);
> + radio->gpio_reset = devm_gpiod_get_optional(>dev, "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(radio->gpio_reset)) {
> + retval = PTR_ERR(radio->gpio_reset);
> + dev_err(>dev, "Failed to request gpio: %d\n", retval);
> + goto err_all;
> + }
> +
> + if (radio->gpio_reset)
> + gpiod_set_value(radio->gpio_reset, 1);
> +
> /* power up : need 110ms */
> radio->registers[POWERCFG] = POWERCFG_ENABLE;
> if (si470x_set_register(radio, POWERCFG) < 0) {
> @@ -478,6 +490,9 @@ static int si470x_i2c_remove(struct i2c_client *client)
> video_unregister_device(>videodev);
> + if (radio->gpio_reset)
> + gpiod_set_value(radio->gpio_reset, 0);
I have a question for you. If the gpio is the last of the bank
acquired for this cpu, when you put to 0, then the gpio will
be free on remove and the clock of the logic will be deactivated so I
think that you don't have any
garantee that the state will be 0
Michael
> +
> return 0;
> }
> diff --git a/drivers/media/radio/si470x/radio-si470x.h
> b/drivers/media/radio/si470x/radio-si470x.h
> index 35fa0f3bbdd2..6fd6a399cb77 100644
> --- a/drivers/media/radio/si470x/radio-si470x.h
> +++ b/drivers/media/radio/si470x/radio-si470x.h
> @@ -189,6 +189,7 @@ struct si470x_device {
> #if IS_ENABLED(CONFIG_I2C_SI470X)
> struct i2c_client *client;
> + struct gpio_desc *gpio_reset;
> #endif
> };
> -- 2.17.1
>
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
Re: [PATCH] media: cedrus: don't initialize pointers with zero
On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> A common mistake is to assume that initializing a var with:
> struct foo f = { 0 };
>
> Would initialize a zeroed struct. Actually, what this does is
> to initialize the first element of the struct to zero.
>
> According to C99 Standard 6.7.8.21:
>
> "If there are fewer initializers in a brace-enclosed
> list than there are elements or members of an aggregate,
> or fewer characters in a string literal used to initialize
> an array of known size than there are elements in the array,
> the remainder of the aggregate shall be initialized implicitly
> the same as objects that have static storage duration."
>
> So, in practice, it could zero the entire struct, but, if the
> first element is not an integer, it will produce warnings:
>
>
> drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
> warning: Using plain integer as NULL pointer
>
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
> warning: Using plain integer as NULL pointer
>
> A proper way to initialize it with gcc is to use:
>
> struct foo f = { };
>
> But that seems to be a gcc extension. So, I decided to check upstream
No, this is not a gcc extension. It's part of the latest C standard.
It's used all over in the kernel, so please use {} instead of { NULL }.
Personally I think {} is a fantastic invention and I wish C++ had it as
well.
Regards,
Hans
> what's the most commonly pattern. The gcc pattern has about 2000 entries:
>
> $ git grep -E "=\s*\{\s*\}"|wc -l
> 1951
>
> The standard-C compliant pattern has about 2500 entries:
>
> $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
> 137
> $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
> 2323
>
> So, let's initialize those structs with:
>= { NULL }
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index b538eb0321d8..44c45c687503 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct
> cedrus_ctx *ctx)
> memset(ctx->ctrls, 0, ctrl_size);
>
> for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> - struct v4l2_ctrl_config cfg = { 0 };
> + struct v4l2_ctrl_config cfg = { NULL };
>
> cfg.elem_size = cedrus_controls[i].elem_size;
> cfg.id = cedrus_controls[i].id;
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> index e40180a33951..4099a42dba2d 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
> {
> struct cedrus_ctx *ctx = priv;
> struct cedrus_dev *dev = ctx->dev;
> - struct cedrus_run run = { 0 };
> + struct cedrus_run run = { NULL };
> struct media_request *src_req;
> unsigned long flags;
>
>
[PATCH] media: cetrus: return an error if alloc fails
As warned by smatch:
drivers/staging/media/sunxi/cedrus/cedrus.c:
drivers/staging/media/sunxi/cedrus/cedrus.c:93 cedrus_init_ctrls() error:
potential null dereference 'ctx->ctrls'. (kzalloc returns null)
While here, remove the memset(), as kzalloc() already zeroes the
struct.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 44c45c687503..24b89cd2b692 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -72,7 +72,8 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct
cedrus_ctx *ctx)
ctrl_size = sizeof(ctrl) * CEDRUS_CONTROLS_COUNT + 1;
ctx->ctrls = kzalloc(ctrl_size, GFP_KERNEL);
- memset(ctx->ctrls, 0, ctrl_size);
+ if (!ctx->ctrls)
+ return -ENOMEM;
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
struct v4l2_ctrl_config cfg = { NULL };
--
2.19.2
[PATCH 4/5 RESEND] si470x-i2c: Add optional reset-gpio support
Subject: [PATCH 4/5] si470x-i2c: Add optional reset-gpio support
Date: Wed, 5 Dec 2018 16:47:49 +0100
From: Paweł Chmiel
To: mche...@kernel.org, robh...@kernel.org, mark.rutl...@arm.com
CC: hverk...@xs4all.nl, fischerdougl...@gmail.com, keesc...@chromium.org,
linux-media@vger.kernel.org, linux-ker...@vger.kernel.org,
devicet...@vger.kernel.org, Paweł Chmiel
If reset-gpio is defined, use it to bring device out of reset.
Without this, it's not possible to access si470x registers.
Signed-off-by: Paweł Chmiel
---
For some reason this patch was not picked up by patchwork. Resending to see if
it is picked up now.
---
drivers/media/radio/si470x/radio-si470x-i2c.c | 15 +++
drivers/media/radio/si470x/radio-si470x.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index a7ac09c55188..15eea2b2c90f 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include "radio-si470x.h"
@@ -392,6 +393,17 @@ static int si470x_i2c_probe(struct i2c_client *client,
radio->videodev.release = video_device_release_empty;
video_set_drvdata(>videodev, radio);
+ radio->gpio_reset = devm_gpiod_get_optional(>dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(radio->gpio_reset)) {
+ retval = PTR_ERR(radio->gpio_reset);
+ dev_err(>dev, "Failed to request gpio: %d\n", retval);
+ goto err_all;
+ }
+
+ if (radio->gpio_reset)
+ gpiod_set_value(radio->gpio_reset, 1);
+
/* power up : need 110ms */
radio->registers[POWERCFG] = POWERCFG_ENABLE;
if (si470x_set_register(radio, POWERCFG) < 0) {
@@ -478,6 +490,9 @@ static int si470x_i2c_remove(struct i2c_client *client)
video_unregister_device(>videodev);
+ if (radio->gpio_reset)
+ gpiod_set_value(radio->gpio_reset, 0);
+
return 0;
}
diff --git a/drivers/media/radio/si470x/radio-si470x.h
b/drivers/media/radio/si470x/radio-si470x.h
index 35fa0f3bbdd2..6fd6a399cb77 100644
--- a/drivers/media/radio/si470x/radio-si470x.h
+++ b/drivers/media/radio/si470x/radio-si470x.h
@@ -189,6 +189,7 @@ struct si470x_device {
#if IS_ENABLED(CONFIG_I2C_SI470X)
struct i2c_client *client;
+ struct gpio_desc *gpio_reset;
#endif
};
-- 2.17.1
[PATCH] media: cedrus: don't initialize pointers with zero
A common mistake is to assume that initializing a var with:
struct foo f = { 0 };
Would initialize a zeroed struct. Actually, what this does is
to initialize the first element of the struct to zero.
According to C99 Standard 6.7.8.21:
"If there are fewer initializers in a brace-enclosed
list than there are elements or members of an aggregate,
or fewer characters in a string literal used to initialize
an array of known size than there are elements in the array,
the remainder of the aggregate shall be initialized implicitly
the same as objects that have static storage duration."
So, in practice, it could zero the entire struct, but, if the
first element is not an integer, it will produce warnings:
drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49:
warning: Using plain integer as NULL pointer
drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35:
warning: Using plain integer as NULL pointer
A proper way to initialize it with gcc is to use:
struct foo f = { };
But that seems to be a gcc extension. So, I decided to check upstream
what's the most commonly pattern. The gcc pattern has about 2000 entries:
$ git grep -E "=\s*\{\s*\}"|wc -l
1951
The standard-C compliant pattern has about 2500 entries:
$ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
137
$ git grep -E "=\s*\{\s*0\s*\}"|wc -l
2323
So, let's initialize those structs with:
= { NULL }
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index b538eb0321d8..44c45c687503 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct
cedrus_ctx *ctx)
memset(ctx->ctrls, 0, ctrl_size);
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
- struct v4l2_ctrl_config cfg = { 0 };
+ struct v4l2_ctrl_config cfg = { NULL };
cfg.elem_size = cedrus_controls[i].elem_size;
cfg.id = cedrus_controls[i].id;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..4099a42dba2d 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
{
struct cedrus_ctx *ctx = priv;
struct cedrus_dev *dev = ctx->dev;
- struct cedrus_run run = { 0 };
+ struct cedrus_run run = { NULL };
struct media_request *src_req;
unsigned long flags;
--
2.19.2
Re: [PATCHv3 1/1] Add ir-rcmm-driver
Hi Patrick,
On Fri, Dec 07, 2018 at 10:57:21AM +0100, Patrick LERDA wrote:
> Add support for RCMM infrared remote controls.
>
> Signed-off-by: Patrick Lerda
Other than the Signed-off-by this looks exactly like the v2 version;
did you see my other comments on the v2 patch?
Thanks
Sean
> ---
> drivers/media/rc/Kconfig | 10 ++
> drivers/media/rc/Makefile | 1 +
> drivers/media/rc/ir-rcmm-decoder.c | 185 +
> drivers/media/rc/rc-core-priv.h| 5 +
> drivers/media/rc/rc-main.c | 3 +
> include/media/rc-map.h | 6 +-
> include/uapi/linux/lirc.h | 1 +
> tools/include/uapi/linux/lirc.h| 1 +
> 8 files changed, 210 insertions(+), 2 deletions(-)
> create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 1021c08a9ba4..b7e08324b874 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -133,6 +133,16 @@ config IR_IMON_DECODER
> remote control and you would like to use it with a raw IR
> receiver, or if you wish to use an encoder to transmit this IR.
>
> +config IR_RCMM_DECODER
> + tristate "Enable IR raw decoder for the RC-MM protocol"
> + depends on RC_CORE
> + select BITREVERSE
> + default y
> +
> + ---help---
> +Enable this option if you have IR with RC-MM protocol, and
> +if the IR is decoded in software
> +
> endif #RC_DECODERS
>
> menuconfig RC_DEVICES
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index e0340d043fe8..fc4058013234 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
> obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
> obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
> obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
> +obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
>
> # stand-alone IR receivers/transmitters
> obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
> diff --git a/drivers/media/rc/ir-rcmm-decoder.c
> b/drivers/media/rc/ir-rcmm-decoder.c
> new file mode 100644
> index ..94d5b70f7a0f
> --- /dev/null
> +++ b/drivers/media/rc/ir-rcmm-decoder.c
> @@ -0,0 +1,185 @@
> +/* ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
> + *
> + * Copyright (C) 2016 by Patrick Lerda
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "rc-core-priv.h"
> +#include
> +#include
> +
> +
> +#define RCMM_UNIT17 /* nanosecs */
> +#define RCMM_0_NBITS 64
> +#define RCMM_PREFIX_PULSE41 /* 16.6*2.5 */
> +#define RCMM_PULSE_027 /* 16.6*(1+2/3) */
> +#define RCMM_PULSE_144 /* 16.6*(2+2/3) */
> +#define RCMM_PULSE_261 /* 16.6*(3+2/3) */
> +#define RCMM_PULSE_378 /* 16.6*(4+2/3) */
> +#define RCMM_MODE_MASK 0x
> +
> +enum rcmm_state {
> + STATE_INACTIVE,
> + STATE_LOW,
> + STATE_BUMP,
> + STATE_VALUE,
> + STATE_FINISHED,
> +};
> +
> +static bool rcmm_mode(struct rcmm_dec *data)
> +{
> +return !((0x000c & data->bits) == 0x000c);
> +}
> +
> +/**
> + * ir_rcmm_decode() - Decode one RCMM pulse or space
> + * @dev: the struct rc_dev descriptor of the device
> + * @ev: the struct ir_raw_event descriptor of the pulse/space
> + *
> + * This function returns -EINVAL if the pulse violates the state machine
> + */
> +static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event ev)
> +{
> + struct rcmm_dec *data = >raw->rcmm;
> + u32 scancode;
> + u8 toggle;
> +
> + if (!(dev->enabled_protocols & RC_PROTO_BIT_RCMM))
> + return 0;
> +
> + if (!is_timing_event(ev)) {
> + if (ev.reset)
> + data->state = STATE_INACTIVE;
> + return 0;
> + }
> +
> + if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
> + goto out;
> +
> + switch (data->state) {
> +
> + case STATE_INACTIVE:
> + if (!ev.pulse)
> + break;
> +
> + /* Note: larger margin on first pulse since each RCMM_UNIT
> +is quite short and some hardware takes some time to
> +adjust to the signal */
> + if (!eq_margin(ev.duration, RCMM_PREFIX_PULSE, RCMM_UNIT/2))
> + break;
> +
> + data->state =
[PATCHv3 1/1] Add ir-rcmm-driver
Add support for RCMM infrared remote controls.
Signed-off-by: Patrick Lerda
---
drivers/media/rc/Kconfig | 10 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-rcmm-decoder.c | 185 +
drivers/media/rc/rc-core-priv.h| 5 +
drivers/media/rc/rc-main.c | 3 +
include/media/rc-map.h | 6 +-
include/uapi/linux/lirc.h | 1 +
tools/include/uapi/linux/lirc.h| 1 +
8 files changed, 210 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 1021c08a9ba4..b7e08324b874 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -133,6 +133,16 @@ config IR_IMON_DECODER
remote control and you would like to use it with a raw IR
receiver, or if you wish to use an encoder to transmit this IR.
+config IR_RCMM_DECODER
+ tristate "Enable IR raw decoder for the RC-MM protocol"
+ depends on RC_CORE
+ select BITREVERSE
+ default y
+
+ ---help---
+ Enable this option if you have IR with RC-MM protocol, and
+ if the IR is decoded in software
+
endif #RC_DECODERS
menuconfig RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index e0340d043fe8..fc4058013234 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
+obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
diff --git a/drivers/media/rc/ir-rcmm-decoder.c
b/drivers/media/rc/ir-rcmm-decoder.c
new file mode 100644
index ..94d5b70f7a0f
--- /dev/null
+++ b/drivers/media/rc/ir-rcmm-decoder.c
@@ -0,0 +1,185 @@
+/* ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
+ *
+ * Copyright (C) 2016 by Patrick Lerda
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "rc-core-priv.h"
+#include
+#include
+
+
+#define RCMM_UNIT 17 /* nanosecs */
+#define RCMM_0_NBITS 64
+#define RCMM_PREFIX_PULSE 41 /* 16.6*2.5 */
+#define RCMM_PULSE_027 /* 16.6*(1+2/3) */
+#define RCMM_PULSE_144 /* 16.6*(2+2/3) */
+#define RCMM_PULSE_261 /* 16.6*(3+2/3) */
+#define RCMM_PULSE_378 /* 16.6*(4+2/3) */
+#define RCMM_MODE_MASK 0x
+
+enum rcmm_state {
+ STATE_INACTIVE,
+ STATE_LOW,
+ STATE_BUMP,
+ STATE_VALUE,
+ STATE_FINISHED,
+};
+
+static bool rcmm_mode(struct rcmm_dec *data)
+{
+return !((0x000c & data->bits) == 0x000c);
+}
+
+/**
+ * ir_rcmm_decode() - Decode one RCMM pulse or space
+ * @dev: the struct rc_dev descriptor of the device
+ * @ev:the struct ir_raw_event descriptor of the pulse/space
+ *
+ * This function returns -EINVAL if the pulse violates the state machine
+ */
+static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event ev)
+{
+ struct rcmm_dec *data = >raw->rcmm;
+ u32 scancode;
+ u8 toggle;
+
+ if (!(dev->enabled_protocols & RC_PROTO_BIT_RCMM))
+ return 0;
+
+ if (!is_timing_event(ev)) {
+ if (ev.reset)
+ data->state = STATE_INACTIVE;
+ return 0;
+ }
+
+ if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
+ goto out;
+
+ switch (data->state) {
+
+ case STATE_INACTIVE:
+ if (!ev.pulse)
+ break;
+
+ /* Note: larger margin on first pulse since each RCMM_UNIT
+ is quite short and some hardware takes some time to
+ adjust to the signal */
+ if (!eq_margin(ev.duration, RCMM_PREFIX_PULSE, RCMM_UNIT/2))
+ break;
+
+ data->state = STATE_LOW;
+ data->count = 0;
+ data->bits = 0;
+ return 0;
+
+ case STATE_LOW:
+ if (ev.pulse)
+ break;
+
+ /* Note: larger margin on first pulse since each RCMM_UNIT
+ is quite short and some hardware takes some time to
+ adjust to the signal */
+
Re: [PATCH] media: venus: Add support for H265 controls required by gstreamer V4L2 H265 module
Hi Kelvin, Thanks for the patch! On 11/30/18 7:31 PM, Kelvin Lawson wrote: > Add support for V4L2_CID_MPEG_VIDEO_HEVC_PROFILE and > V4L2_CID_MPEG_VIDEO_HEVC_LEVEL controls required by gstreamer V4L2 H265 > encoder module. > > Signed-off-by: Kelvin Lawson > --- > drivers/media/platform/qcom/venus/venc_ctrls.c | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c > b/drivers/media/platform/qcom/venus/venc_ctrls.c > index 45910172..ad1a4d8 100644 > --- a/drivers/media/platform/qcom/venus/venc_ctrls.c > +++ b/drivers/media/platform/qcom/venus/venc_ctrls.c > @@ -101,6 +101,9 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl) > case V4L2_CID_MPEG_VIDEO_H264_PROFILE: > ctr->profile.h264 = ctrl->val; > break; > + case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE: > + ctr->profile.hevc = ctrl->val; > + break; > case V4L2_CID_MPEG_VIDEO_VP8_PROFILE: > ctr->profile.vpx = ctrl->val; > break; > @@ -110,6 +113,9 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl) > case V4L2_CID_MPEG_VIDEO_H264_LEVEL: > ctr->level.h264 = ctrl->val; > break; > + case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL: > + ctr->level.hevc = ctrl->val; > + break; > case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP: > ctr->h264_i_qp = ctrl->val; > break; > @@ -217,6 +223,19 @@ int venc_ctrl_init(struct venus_inst *inst) > 0, V4L2_MPEG_VIDEO_MPEG4_LEVEL_0); > > v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops, > + V4L2_CID_MPEG_VIDEO_HEVC_PROFILE, > + V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10, > + ~((1 << V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN) | > + (1 << V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE) | > + (1 << V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10)), > + V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN); > + > + v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops, > + V4L2_CID_MPEG_VIDEO_HEVC_LEVEL, > + V4L2_MPEG_VIDEO_HEVC_LEVEL_6_2, > + 0, V4L2_MPEG_VIDEO_HEVC_LEVEL_1); > + > + v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops, you are adding two new menu controls but forgot to increment the count of controls in v4l2_ctrl_handler_init(). Can you resend with that fixed? > V4L2_CID_MPEG_VIDEO_H264_PROFILE, > V4L2_MPEG_VIDEO_H264_PROFILE_MULTIVIEW_HIGH, > ~((1 << V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE) | > -- regards, Stan
Re: [PATCH v2] media: venus: Support V4L2 QP parameters in Venus encoder
Hi Kelvin, Thanks for the patch! On 11/30/18 2:07 AM, Kelvin Lawson wrote: > Support V4L2 QP parameters in Venus encoder: > * V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP > * V4L2_CID_MPEG_VIDEO_H264_B_FRAME_QP > * V4L2_CID_MPEG_VIDEO_H264_MIN_QP > * V4L2_CID_MPEG_VIDEO_H264_MAX_QP > > Signed-off-by: Kelvin Lawson > --- > drivers/media/platform/qcom/venus/venc.c | 19 +++ > 1 file changed, 19 insertions(+) Acked-by: Stanimir Varbanov -- regards, Stan
[RFC PATCH] media/Kconfig: always enable MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
This patch selects MEDIA_CONTROLLER for all camera, analog TV and digital TV drivers and selects VIDEO_V4L2_SUBDEV_API automatically. This will allow us to simplify drivers that currently have to add #ifdef CONFIG_MEDIA_CONTROLLER or #ifdef VIDEO_V4L2_SUBDEV_API to their code, since now this will always be available. The original intent of allowing these to be configured by the user was (I think) to save a bit of memory. But as more and more drivers have a media controller and all regular distros already enable one or more of those drivers, the memory for the MC code is there anyway. Complexity has always been the bane of media drivers, so reducing complexity at the expense of a bit more memory (which is a rounding error compared to the amount of video buffer memory needed) is IMHO a good thing. Signed-off-by: Hans Verkuil --- diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 8add62a18293..56eb01cc8bb4 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -31,6 +31,7 @@ comment "Multimedia core support" # config MEDIA_CAMERA_SUPPORT bool "Cameras/video grabbers support" + select MEDIA_CONTROLLER ---help--- Enable support for webcams and video grabbers. @@ -38,6 +39,7 @@ config MEDIA_CAMERA_SUPPORT config MEDIA_ANALOG_TV_SUPPORT bool "Analog TV support" + select MEDIA_CONTROLLER ---help--- Enable analog TV support. @@ -50,6 +52,7 @@ config MEDIA_ANALOG_TV_SUPPORT config MEDIA_DIGITAL_TV_SUPPORT bool "Digital TV support" + select MEDIA_CONTROLLER ---help--- Enable digital TV support. @@ -95,7 +98,6 @@ source "drivers/media/cec/Kconfig" config MEDIA_CONTROLLER bool "Media Controller API" - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT ---help--- Enable the media controller API used to query media devices internal topology and configure it dynamically. @@ -119,16 +121,11 @@ config VIDEO_DEV tristate depends on MEDIA_SUPPORT depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT + select VIDEO_V4L2_SUBDEV_API if MEDIA_CONTROLLER default y config VIDEO_V4L2_SUBDEV_API - bool "V4L2 sub-device userspace API" - depends on VIDEO_DEV && MEDIA_CONTROLLER - ---help--- - Enables the V4L2 sub-device pad-level userspace API used to configure - video format, size and frame rate between hardware blocks. - - This API is mostly used by camera interfaces in embedded platforms. + bool source "drivers/media/v4l2-core/Kconfig"
Re: Invite for IRC meeting: Re: [PATCHv4 01/10] videodev2.h: add tag support
Hi Hans, On Fri, Dec 7, 2018 at 12:08 AM Hans Verkuil wrote: > > Mauro raised a number of objections on irc regarding tags: > > https://linuxtv.org/irc/irclogger_log/media-maint?date=2018-12-06,Thu > > I would like to setup an irc meeting to discuss this and come to a > conclusion, since we need to decide this soon since this is critical > for stateless codec support. > > Unfortunately timezone-wise this is a bit of a nightmare. I think > that at least Mauro, myself and Tomasz Figa should be there, so UTC-2, > UTC+1 and UTC+9 (if I got that right). > > I propose 9 AM UTC which I think will work for everyone except Nicolas. > Any day next week works for me, and (for now) as well for Mauro. Let's pick > Monday to start with, and if you want to join in, then let me know. If that > day doesn't work for you, let me know what other days next week do work for > you. Monday (or any other day next week) 9AM UTC should work for me! Thanks, Alex.
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: Fri Dec 7 05:00:15 CET 2018 media-tree git hash:3c28b91380dd1183347d32d87d820818031ebecf media_build git hash: 4b9237c73e29ea969f6a7b3d00030e14be50 v4l-utils git hash: 7086a1ee8dda5ae34852379410432d259215ff5e edid-decode git hash: 6def7bc83dfb0338632e06a8b14c93faa6af8879 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: ERRORS linux-3.10.108-x86_64: ERRORS linux-3.11.10-i686: ERRORS linux-3.11.10-x86_64: ERRORS linux-3.12.74-i686: ERRORS linux-3.12.74-x86_64: ERRORS linux-3.13.11-i686: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.79-i686: ERRORS linux-3.14.79-x86_64: ERRORS linux-3.15.10-i686: ERRORS linux-3.15.10-x86_64: ERRORS linux-3.16.57-i686: ERRORS linux-3.16.57-x86_64: ERRORS linux-3.17.8-i686: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.123-i686: ERRORS linux-3.18.123-x86_64: ERRORS linux-3.19.8-i686: ERRORS linux-3.19.8-x86_64: ERRORS linux-4.0.9-i686: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.52-i686: ERRORS linux-4.1.52-x86_64: ERRORS linux-4.2.8-i686: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-i686: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.159-i686: ERRORS linux-4.4.159-x86_64: ERRORS linux-4.5.7-i686: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-i686: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.10-i686: ERRORS linux-4.7.10-x86_64: ERRORS linux-4.8.17-i686: ERRORS linux-4.8.17-x86_64: ERRORS linux-4.9.131-i686: ERRORS linux-4.9.131-x86_64: ERRORS linux-4.10.17-i686: ERRORS linux-4.10.17-x86_64: ERRORS linux-4.11.12-i686: ERRORS linux-4.11.12-x86_64: ERRORS linux-4.12.14-i686: ERRORS linux-4.12.14-x86_64: ERRORS linux-4.13.16-i686: ERRORS linux-4.13.16-x86_64: ERRORS linux-4.14.74-i686: ERRORS linux-4.14.74-x86_64: ERRORS linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19.1-i686: OK linux-4.19.1-x86_64: OK linux-4.20-rc1-i686: OK linux-4.20-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
RE,
-- Hello First of all i will like to apologies for my manner of communication because you do not know me personally, its due to the fact that i have a very important proposal for you.
[PATCH v8 15/17] media: v4l: Add Intel IPU3 meta buffer formats
Add IPU3-specific meta formats for processing parameters and
3A statistics.
V4L2_META_FMT_IPU3_PARAMS
V4L2_META_FMT_IPU3_STAT_3A
Signed-off-by: Yong Zhi
Reviewed-by: Laurent Pinchart
---
Documentation/media/uapi/v4l/meta-formats.rst | 1 +
.../media/uapi/v4l/pixfmt-meta-intel-ipu3.rst | 178 +
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
include/uapi/linux/videodev2.h | 4 +
4 files changed, 185 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
diff --git a/Documentation/media/uapi/v4l/meta-formats.rst
b/Documentation/media/uapi/v4l/meta-formats.rst
index 438bd244bd2f..5f956fa784b7 100644
--- a/Documentation/media/uapi/v4l/meta-formats.rst
+++ b/Documentation/media/uapi/v4l/meta-formats.rst
@@ -19,6 +19,7 @@ These formats are used for the :ref:`metadata` interface only.
.. toctree::
:maxdepth: 1
+pixfmt-meta-intel-ipu3
pixfmt-meta-d4xx
pixfmt-meta-uvc
pixfmt-meta-vsp1-hgo
diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
new file mode 100644
index ..8cd30ffbf8b8
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
@@ -0,0 +1,178 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _v4l2-meta-fmt-params:
+.. _v4l2-meta-fmt-stat-3a:
+
+**
+V4L2_META_FMT_IPU3_PARAMS ('ip3p'), V4L2_META_FMT_IPU3_3A ('ip3s')
+**
+
+.. c:type:: ipu3_uapi_stats_3a
+
+3A statistics
+=
+
+For IPU3 ImgU, the 3A statistics accelerators collect different statistics over
+an input bayer frame. Those statistics, defined in data struct
:c:type:`ipu3_uapi_stats_3a`,
+are obtained from "ipu3-imgu 3a stat" metadata capture video node, which are
then
+passed to user space for statistics analysis using :c:type:`v4l2_meta_format`
interface.
+
+The statistics collected are AWB (Auto-white balance) RGBS (Red, Green, Blue
and
+Saturation measure) cells, AWB filter response, AF (Auto-focus) filter
response,
+and AE (Auto-exposure) histogram.
+
+struct :c:type:`ipu3_uapi_4a_config` saves configurable parameters for all
above.
+
+.. code-block:: c
+
+ struct ipu3_uapi_stats_3a {
+ struct ipu3_uapi_awb_raw_buffer awb_raw_buffer;
+ struct ipu3_uapi_ae_raw_buffer_aligned
ae_raw_buffer[IPU3_UAPI_MAX_STRIPES];
+ struct ipu3_uapi_af_raw_buffer af_raw_buffer;
+ struct ipu3_uapi_awb_fr_raw_buffer awb_fr_raw_buffer;
+ struct ipu3_uapi_4a_config stats_4a_config;
+ __u32 ae_join_buffers;
+ __u8 padding[28];
+ struct ipu3_uapi_stats_3a_bubble_info_per_stripe
stats_3a_bubble_per_stripe;
+ struct ipu3_uapi_ff_status stats_3a_status;
+ };
+
+.. c:type:: ipu3_uapi_params
+
+Pipeline parameters
+===
+
+IPU3 pipeline has a number of image processing stages, each of which takes a
+set of parameters as input. The major stages of pipelines are shown here:
+
+Raw pixels -> Bayer Downscaling -> Optical Black Correction ->
+
+Linearization -> Lens Shading Correction -> White Balance / Exposure /
+
+Focus Apply -> Bayer Noise Reduction -> ANR -> Demosaicing -> Color
+
+Correction Matrix -> Gamma correction -> Color Space Conversion ->
+
+Chroma Down Scaling -> Chromatic Noise Reduction -> Total Color
+
+Correction -> XNR3 -> TNR -> DDR
+
+The table below presents a description of the above algorithms.
+
+
===
+NameDescription
+
===
+Optical Black Correction Optical Black Correction block subtracts a pre-defined
+value from the respective pixel values to obtain better
+image quality.
+Defined in :c:type:`ipu3_uapi_obgrid_param`.
+Linearization This algo block uses linearization parameters to
+address non-linearity sensor effects. The Lookup table
+table is defined in
+:c:type:`ipu3_uapi_isp_lin_vmem_params`.
+SHD Lens shading correction is used to correct spatial
+non-uniformity of the pixel response due to optical
+lens shading. This is done by applying a different gain
+for each pixel. The gain, black level etc are
+configured in :c:type:`ipu3_uapi_shd_config_static`.
+BNR Bayer noise reduction block removes image noise by
+applying a bilateral filter.
+See :c:type:`ipu3_uapi_bnr_static_config` for details.
+ANR
[PATCH v8 12/17] media: staging/intel-ipu3: Add imgu top level pci device driver
This patch adds support for the Intel IPU v3 as found on Skylake and Kaby Lake SoCs. The driver glues v4l2, css(camera sub system) and other pieces together to perform its functions, it also loads the IPU3 firmware binary as part of its initialization. Signed-off-by: Yong Zhi Signed-off-by: Tomasz Figa --- drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile | 1 + drivers/staging/media/ipu3/Kconfig | 14 + drivers/staging/media/ipu3/Makefile | 11 + drivers/staging/media/ipu3/TODO | 23 + drivers/staging/media/ipu3/ipu3.c | 844 drivers/staging/media/ipu3/ipu3.h | 152 +++ 7 files changed, 1047 insertions(+) create mode 100644 drivers/staging/media/ipu3/Kconfig create mode 100644 drivers/staging/media/ipu3/Makefile create mode 100644 drivers/staging/media/ipu3/TODO create mode 100644 drivers/staging/media/ipu3/ipu3.c create mode 100644 drivers/staging/media/ipu3/ipu3.h diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index c6f3404dea43..19cadd17e542 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -39,4 +39,6 @@ source "drivers/staging/media/tegra-vde/Kconfig" source "drivers/staging/media/zoran/Kconfig" +source "drivers/staging/media/ipu3/Kconfig" + endif diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 43c7bee1fc8c..edde1960b030 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -9,3 +9,4 @@ obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ +obj-$(CONFIG_VIDEO_IPU3_IMGU) += ipu3/ diff --git a/drivers/staging/media/ipu3/Kconfig b/drivers/staging/media/ipu3/Kconfig new file mode 100644 index ..75cd889f18f7 --- /dev/null +++ b/drivers/staging/media/ipu3/Kconfig @@ -0,0 +1,14 @@ +config VIDEO_IPU3_IMGU + tristate "Intel ipu3-imgu driver" + depends on PCI && VIDEO_V4L2 + depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API + depends on X86 + select IOMMU_IOVA + select VIDEOBUF2_DMA_SG + ---help--- + This is the Video4Linux2 driver for Intel IPU3 image processing unit, + found in Intel Skylake and Kaby Lake SoCs and used for processing + images and video. + + Say Y or M here if you have a Skylake/Kaby Lake SoC with a MIPI + camera. The module will be called ipu3-imgu. diff --git a/drivers/staging/media/ipu3/Makefile b/drivers/staging/media/ipu3/Makefile new file mode 100644 index ..fb146d178bd4 --- /dev/null +++ b/drivers/staging/media/ipu3/Makefile @@ -0,0 +1,11 @@ +# +# Makefile for the IPU3 ImgU drivers +# + +ipu3-imgu-objs += \ + ipu3-mmu.o ipu3-dmamap.o \ + ipu3-tables.o ipu3-css-pool.o \ + ipu3-css-fw.o ipu3-css-params.o \ + ipu3-css.o ipu3-v4l2.o ipu3.o + +obj-$(CONFIG_VIDEO_IPU3_IMGU) += ipu3-imgu.o diff --git a/drivers/staging/media/ipu3/TODO b/drivers/staging/media/ipu3/TODO new file mode 100644 index ..922b885f10a7 --- /dev/null +++ b/drivers/staging/media/ipu3/TODO @@ -0,0 +1,23 @@ +This is a list of things that need to be done to get this driver out of the +staging directory. + +- Request API conversion. Remove of the dual pipeline and associate buffers + as well as formats and the binary used to a request. Remove the + opportunistic buffer management. (Sakari) + +- Using ENABLED and IMMUTABLE link flags for the links where those are + relevant. (Sakari) + +- Prefix imgu for all public APIs, i.e. change ipu3_v4l2_register() to + imgu_v4l2_register(). (Sakari) + +- Use V4L2_CTRL_TYPE_MENU for dual-pipe mode control. (Sakari) + +- IPU3 driver documentation (Laurent) + Add diagram in driver rst to describe output capability. + Comments on configuring v4l2 subdevs for CIO2 and ImgU. + +- uAPI documentation: + Further clarification on some ambiguities such as data type conversion of + IEFD CU inputs. (Sakari) + Move acronyms to doc-rst file. (Mauro) diff --git a/drivers/staging/media/ipu3/ipu3.c b/drivers/staging/media/ipu3/ipu3.c new file mode 100644 index ..3d0a34b86ff4 --- /dev/null +++ b/drivers/staging/media/ipu3/ipu3.c @@ -0,0 +1,844 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2017 - 2018 Intel Corporation + * Copyright 2017 Google LLC + * + * Based on Intel IPU4 driver. + * + */ + +#include +#include +#include +#include + +#include "ipu3.h" +#include "ipu3-dmamap.h" +#include "ipu3-mmu.h" + +#define IMGU_PCI_ID0x1919 +#define IMGU_PCI_BAR 0 +#define IMGU_DMA_MASK DMA_BIT_MASK(39) +#define IMGU_MAX_QUEUE_DEPTH (2 + 2) + +/* + * pre-allocated buffer size for IMGU dummy buffers. Those + * values should be tuned to big enough to avoid buffer + * re-allocation
[PATCH v8 08/17] media: staging/intel-ipu3: css: Compute and program ccs
A collection of routines that are mainly used
to calculate the parameters for accelerator cluster.
Signed-off-by: Yong Zhi
---
drivers/staging/media/ipu3/ipu3-css-params.c | 2915 ++
drivers/staging/media/ipu3/ipu3-css-params.h | 25 +
2 files changed, 2940 insertions(+)
create mode 100644 drivers/staging/media/ipu3/ipu3-css-params.c
create mode 100644 drivers/staging/media/ipu3/ipu3-css-params.h
diff --git a/drivers/staging/media/ipu3/ipu3-css-params.c
b/drivers/staging/media/ipu3/ipu3-css-params.c
new file mode 100644
index ..747352c089dd
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-css-params.c
@@ -0,0 +1,2915 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include
+
+#include "ipu3-css.h"
+#include "ipu3-css-fw.h"
+#include "ipu3-tables.h"
+
+#define DIV_ROUND_CLOSEST_DOWN(a, b) (((a) + ((b) / 2) - 1) / (b))
+#define roundclosest_down(a, b)(DIV_ROUND_CLOSEST_DOWN(a, b) *
(b))
+
+#define IPU3_UAPI_ANR_MAX_RESET((1 << 12) - 1)
+#define IPU3_UAPI_ANR_MIN_RESET(((-1) << 12) + 1)
+
+struct ipu3_css_scaler_info {
+ unsigned int phase_step;/* Same for luma/chroma */
+ int exp_shift;
+
+ unsigned int phase_init;/* luma/chroma dependent */
+ int pad_left;
+ int pad_right;
+ int crop_left;
+ int crop_top;
+};
+
+static unsigned int ipu3_css_scaler_get_exp(unsigned int counter,
+ unsigned int divider)
+{
+ int i = fls(divider) - fls(counter);
+
+ if (i <= 0)
+ return 0;
+
+ if (divider >> i < counter)
+ i = i - 1;
+
+ return i;
+}
+
+/* Set up the CSS scaler look up table */
+static void
+ipu3_css_scaler_setup_lut(unsigned int taps, unsigned int input_width,
+ unsigned int output_width, int phase_step_correction,
+ const int *coeffs, unsigned int coeffs_size,
+ s8 coeff_lut[], struct ipu3_css_scaler_info *info)
+{
+ int tap, phase, phase_sum_left, phase_sum_right;
+ int exponent = ipu3_css_scaler_get_exp(output_width, input_width);
+ int mantissa = (1 << exponent) * output_width;
+ unsigned int phase_step;
+
+ if (input_width == output_width) {
+ for (phase = 0; phase < IMGU_SCALER_PHASES; phase++) {
+ for (tap = 0; tap < taps; tap++) {
+ coeff_lut[phase * IMGU_SCALER_FILTER_TAPS + tap]
+ = 0;
+ }
+ }
+
+ info->phase_step = IMGU_SCALER_PHASES *
+ (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF);
+ info->exp_shift = 0;
+ info->pad_left = 0;
+ info->pad_right = 0;
+ info->phase_init = 0;
+ info->crop_left = 0;
+ info->crop_top = 0;
+ return;
+ }
+
+ for (phase = 0; phase < IMGU_SCALER_PHASES; phase++) {
+ for (tap = 0; tap < taps; tap++) {
+ /* flip table to for convolution reverse indexing */
+ s64 coeff = coeffs[coeffs_size -
+ ((tap * (coeffs_size / taps)) + phase) - 1];
+ coeff *= mantissa;
+ coeff = div64_long(coeff, input_width);
+
+ /* Add +"0.5" */
+ coeff += 1 << (IMGU_SCALER_COEFF_BITS - 1);
+ coeff >>= IMGU_SCALER_COEFF_BITS;
+
+ coeff_lut[phase * IMGU_SCALER_FILTER_TAPS + tap] =
+ coeff;
+ }
+ }
+
+ phase_step = IMGU_SCALER_PHASES *
+ (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF) *
+ output_width / input_width;
+ phase_step += phase_step_correction;
+ phase_sum_left = (taps / 2 * IMGU_SCALER_PHASES *
+ (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF)) -
+ (1 << (IMGU_SCALER_PHASE_COUNTER_PREC_REF - 1));
+ phase_sum_right = (taps / 2 * IMGU_SCALER_PHASES *
+ (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF)) +
+ (1 << (IMGU_SCALER_PHASE_COUNTER_PREC_REF - 1));
+
+ info->exp_shift = IMGU_SCALER_MAX_EXPONENT_SHIFT - exponent;
+ info->pad_left = (phase_sum_left % phase_step == 0) ?
+ phase_sum_left / phase_step - 1 : phase_sum_left / phase_step;
+ info->pad_right = (phase_sum_right % phase_step == 0) ?
+ phase_sum_right / phase_step - 1 : phase_sum_right / phase_step;
+ info->phase_init = phase_sum_left - phase_step * info->pad_left;
+ info->phase_step = phase_step;
+ info->crop_left = taps - 1;
+ info->crop_top = taps - 1;
+}
+
+/*
+ * Calculates the exact output image
[PATCH v8 06/17] media: staging/intel-ipu3: css: Add support for firmware management
Introduce functions to load and install ImgU FW blobs.
Signed-off-by: Yong Zhi
---
drivers/staging/media/ipu3/ipu3-css-fw.c | 264 +++
drivers/staging/media/ipu3/ipu3-css-fw.h | 188 ++
2 files changed, 452 insertions(+)
create mode 100644 drivers/staging/media/ipu3/ipu3-css-fw.c
create mode 100644 drivers/staging/media/ipu3/ipu3-css-fw.h
diff --git a/drivers/staging/media/ipu3/ipu3-css-fw.c
b/drivers/staging/media/ipu3/ipu3-css-fw.c
new file mode 100644
index ..ba459e98d77d
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-css-fw.c
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include
+#include
+#include
+#include
+
+#include "ipu3-css.h"
+#include "ipu3-css-fw.h"
+#include "ipu3-dmamap.h"
+
+static void ipu3_css_fw_show_binary(struct device *dev, struct imgu_fw_info
*bi,
+ const char *name)
+{
+ unsigned int i;
+
+ dev_dbg(dev, "found firmware binary type %i size %i name %s\n",
+ bi->type, bi->blob.size, name);
+ if (bi->type != IMGU_FW_ISP_FIRMWARE)
+ return;
+
+ dev_dbg(dev, "id %i mode %i bds 0x%x veceven %i/%i out_pins %i\n",
+ bi->info.isp.sp.id, bi->info.isp.sp.pipeline.mode,
+ bi->info.isp.sp.bds.supported_bds_factors,
+ bi->info.isp.sp.enable.vf_veceven,
+ bi->info.isp.sp.vf_dec.is_variable,
+ bi->info.isp.num_output_pins);
+
+ dev_dbg(dev, "input (%i,%i)-(%i,%i) formats %s%s%s\n",
+ bi->info.isp.sp.input.min_width,
+ bi->info.isp.sp.input.min_height,
+ bi->info.isp.sp.input.max_width,
+ bi->info.isp.sp.input.max_height,
+ bi->info.isp.sp.enable.input_yuv ? "yuv420 " : "",
+ bi->info.isp.sp.enable.input_feeder ||
+ bi->info.isp.sp.enable.input_raw ? "raw8 raw10 " : "",
+ bi->info.isp.sp.enable.input_raw ? "raw12" : "");
+
+ dev_dbg(dev, "internal (%i,%i)\n",
+ bi->info.isp.sp.internal.max_width,
+ bi->info.isp.sp.internal.max_height);
+
+ dev_dbg(dev, "output (%i,%i)-(%i,%i) formats",
+ bi->info.isp.sp.output.min_width,
+ bi->info.isp.sp.output.min_height,
+ bi->info.isp.sp.output.max_width,
+ bi->info.isp.sp.output.max_height);
+ for (i = 0; i < bi->info.isp.num_output_formats; i++)
+ dev_dbg(dev, " %i", bi->info.isp.output_formats[i]);
+ dev_dbg(dev, " vf");
+ for (i = 0; i < bi->info.isp.num_vf_formats; i++)
+ dev_dbg(dev, " %i", bi->info.isp.vf_formats[i]);
+ dev_dbg(dev, "\n");
+}
+
+unsigned int ipu3_css_fw_obgrid_size(const struct imgu_fw_info *bi)
+{
+ unsigned int width = DIV_ROUND_UP(bi->info.isp.sp.internal.max_width,
+ IMGU_OBGRID_TILE_SIZE * 2) + 1;
+ unsigned int height = DIV_ROUND_UP(bi->info.isp.sp.internal.max_height,
+ IMGU_OBGRID_TILE_SIZE * 2) + 1;
+ unsigned int obgrid_size;
+
+ width = ALIGN(width, IPU3_UAPI_ISP_VEC_ELEMS / 4);
+ obgrid_size = PAGE_ALIGN(width * height *
+sizeof(struct ipu3_uapi_obgrid_param)) *
+bi->info.isp.sp.iterator.num_stripes;
+ return obgrid_size;
+}
+
+void *ipu3_css_fw_pipeline_params(struct ipu3_css *css,
+ enum imgu_abi_param_class c,
+ enum imgu_abi_memories m,
+ struct imgu_fw_isp_parameter *par,
+ size_t par_size, void *binary_params)
+{
+ struct imgu_fw_info *bi = >fwp->binary_header[css->current_binary];
+
+ if (par->offset + par->size >
+ bi->info.isp.sp.mem_initializers.params[c][m].size)
+ return NULL;
+
+ if (par->size != par_size)
+ pr_warn("parameter size doesn't match defined size\n");
+
+ if (par->size < par_size)
+ return NULL;
+
+ return binary_params + par->offset;
+}
+
+void ipu3_css_fw_cleanup(struct ipu3_css *css)
+{
+ struct imgu_device *imgu = dev_get_drvdata(css->dev);
+
+ if (css->binary) {
+ unsigned int i;
+
+ for (i = 0; i < css->fwp->file_header.binary_nr; i++)
+ ipu3_dmamap_free(imgu, >binary[i]);
+ kfree(css->binary);
+ }
+ if (css->fw)
+ release_firmware(css->fw);
+
+ css->binary = NULL;
+ css->fw = NULL;
+}
+
+int ipu3_css_fw_init(struct ipu3_css *css)
+{
+ static const u32 BLOCK_MAX = 65536;
+ struct imgu_device *imgu = dev_get_drvdata(css->dev);
+ struct device *dev = css->dev;
+ unsigned int i, j, binary_nr;
+ int r;
+
+ r =
[PATCH v8 10/17] media: staging/intel-ipu3: Add css pipeline programming
This provides helper library to be used by v4l2 level to program
imaging pipelines and control the streaming.
Signed-off-by: Yong Zhi
---
drivers/staging/media/ipu3/ipu3-css.c | 1740 +
1 file changed, 1740 insertions(+)
diff --git a/drivers/staging/media/ipu3/ipu3-css.c
b/drivers/staging/media/ipu3/ipu3-css.c
index 164830fc91ad..3811ad752e8d 100644
--- a/drivers/staging/media/ipu3/ipu3-css.c
+++ b/drivers/staging/media/ipu3/ipu3-css.c
@@ -16,6 +16,173 @@
IMGU_IRQCTRL_IRQ_SW_PIN(0) | \
IMGU_IRQCTRL_IRQ_SW_PIN(1))
+#define IPU3_CSS_FORMAT_BPP_DEN50 /* Denominator */
+
+/* Some sane limits for resolutions */
+#define IPU3_CSS_MIN_RES 32
+#define IPU3_CSS_MAX_H 3136
+#define IPU3_CSS_MAX_W 4224
+
+/* filter size from graph settings is fixed as 4 */
+#define FILTER_SIZE 4
+#define MIN_ENVELOPE8
+
+/*
+ * pre-allocated buffer size for CSS ABI, auxiliary frames
+ * after BDS and before GDC. Those values should be tuned
+ * to big enough to avoid buffer re-allocation when
+ * streaming to lower streaming latency.
+ */
+#define CSS_ABI_SIZE136
+#define CSS_BDS_SIZE(4480 * 3200 * 3)
+#define CSS_GDC_SIZE(4224 * 3200 * 12 / 8)
+
+#define IPU3_CSS_QUEUE_TO_FLAGS(q) (1 << (q))
+#define IPU3_CSS_FORMAT_FL_IN \
+ IPU3_CSS_QUEUE_TO_FLAGS(IPU3_CSS_QUEUE_IN)
+#define IPU3_CSS_FORMAT_FL_OUT \
+ IPU3_CSS_QUEUE_TO_FLAGS(IPU3_CSS_QUEUE_OUT)
+#define IPU3_CSS_FORMAT_FL_VF \
+ IPU3_CSS_QUEUE_TO_FLAGS(IPU3_CSS_QUEUE_VF)
+
+/* Formats supported by IPU3 Camera Sub System */
+static const struct ipu3_css_format ipu3_css_formats[] = {
+ {
+ .pixelformat = V4L2_PIX_FMT_NV12,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .frame_format = IMGU_ABI_FRAME_FORMAT_NV12,
+ .osys_format = IMGU_ABI_OSYS_FORMAT_NV12,
+ .osys_tiling = IMGU_ABI_OSYS_TILING_NONE,
+ .bytesperpixel_num = 1 * IPU3_CSS_FORMAT_BPP_DEN,
+ .chroma_decim = 4,
+ .width_align = IPU3_UAPI_ISP_VEC_ELEMS,
+ .flags = IPU3_CSS_FORMAT_FL_OUT | IPU3_CSS_FORMAT_FL_VF,
+ }, {
+ /* Each 32 bytes contains 25 10-bit pixels */
+ .pixelformat = V4L2_PIX_FMT_IPU3_SBGGR10,
+ .colorspace = V4L2_COLORSPACE_RAW,
+ .frame_format = IMGU_ABI_FRAME_FORMAT_RAW_PACKED,
+ .bayer_order = IMGU_ABI_BAYER_ORDER_BGGR,
+ .bit_depth = 10,
+ .bytesperpixel_num = 64,
+ .width_align = 2 * IPU3_UAPI_ISP_VEC_ELEMS,
+ .flags = IPU3_CSS_FORMAT_FL_IN,
+ }, {
+ .pixelformat = V4L2_PIX_FMT_IPU3_SGBRG10,
+ .colorspace = V4L2_COLORSPACE_RAW,
+ .frame_format = IMGU_ABI_FRAME_FORMAT_RAW_PACKED,
+ .bayer_order = IMGU_ABI_BAYER_ORDER_GBRG,
+ .bit_depth = 10,
+ .bytesperpixel_num = 64,
+ .width_align = 2 * IPU3_UAPI_ISP_VEC_ELEMS,
+ .flags = IPU3_CSS_FORMAT_FL_IN,
+ }, {
+ .pixelformat = V4L2_PIX_FMT_IPU3_SGRBG10,
+ .colorspace = V4L2_COLORSPACE_RAW,
+ .frame_format = IMGU_ABI_FRAME_FORMAT_RAW_PACKED,
+ .bayer_order = IMGU_ABI_BAYER_ORDER_GRBG,
+ .bit_depth = 10,
+ .bytesperpixel_num = 64,
+ .width_align = 2 * IPU3_UAPI_ISP_VEC_ELEMS,
+ .flags = IPU3_CSS_FORMAT_FL_IN,
+ }, {
+ .pixelformat = V4L2_PIX_FMT_IPU3_SRGGB10,
+ .colorspace = V4L2_COLORSPACE_RAW,
+ .frame_format = IMGU_ABI_FRAME_FORMAT_RAW_PACKED,
+ .bayer_order = IMGU_ABI_BAYER_ORDER_RGGB,
+ .bit_depth = 10,
+ .bytesperpixel_num = 64,
+ .width_align = 2 * IPU3_UAPI_ISP_VEC_ELEMS,
+ .flags = IPU3_CSS_FORMAT_FL_IN,
+ },
+};
+
+static const struct {
+ enum imgu_abi_queue_id qid;
+ size_t ptr_ofs;
+} ipu3_css_queues[IPU3_CSS_QUEUES] = {
+ [IPU3_CSS_QUEUE_IN] = {
+ IMGU_ABI_QUEUE_C_ID,
+ offsetof(struct imgu_abi_buffer, payload.frame.frame_data)
+ },
+ [IPU3_CSS_QUEUE_OUT] = {
+ IMGU_ABI_QUEUE_D_ID,
+ offsetof(struct imgu_abi_buffer, payload.frame.frame_data)
+ },
+ [IPU3_CSS_QUEUE_VF] = {
+ IMGU_ABI_QUEUE_E_ID,
+ offsetof(struct imgu_abi_buffer, payload.frame.frame_data)
+ },
+ [IPU3_CSS_QUEUE_STAT_3A] = {
+ IMGU_ABI_QUEUE_F_ID,
+ offsetof(struct imgu_abi_buffer, payload.s3a.data_ptr)
+ },
+};
+
+/* Initialize queue based on given format, adjust format as needed */
+static int ipu3_css_queue_init(struct ipu3_css_queue *queue,
[PATCH v8 01/17] media: staging/intel-ipu3: abi: Add register definitions and enum
Add macros and enums used for IPU3 firmware interface. Signed-off-by: Yong Zhi Signed-off-by: Rajmohan Mani Reviewed-by: Laurent Pinchart --- drivers/staging/media/ipu3/ipu3-abi.h | 661 ++ 1 file changed, 661 insertions(+) create mode 100644 drivers/staging/media/ipu3/ipu3-abi.h diff --git a/drivers/staging/media/ipu3/ipu3-abi.h b/drivers/staging/media/ipu3/ipu3-abi.h new file mode 100644 index ..e754ff5836c2 --- /dev/null +++ b/drivers/staging/media/ipu3/ipu3-abi.h @@ -0,0 +1,661 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* Copyright (C) 2018 Intel Corporation */ + +#ifndef __IPU3_ABI_H +#define __IPU3_ABI_H + +#include "include/intel-ipu3.h" + +/*** IMGU Hardware information ***/ + +typedef u32 imgu_addr_t; + +#define IMGU_ISP_VMEM_ALIGN128 +#define IMGU_DVS_BLOCK_W 64 +#define IMGU_DVS_BLOCK_H 32 +#define IMGU_GDC_BUF_X (2 * IMGU_DVS_BLOCK_W) +#define IMGU_GDC_BUF_Y IMGU_DVS_BLOCK_H +/* n = 0..1 */ +#define IMGU_SP_PMEM_BASE(n) (0x2 + (n) * 0x4000) +#define IMGU_MAX_BQ_GRID_WIDTH 80 +#define IMGU_MAX_BQ_GRID_HEIGHT60 +#define IMGU_OBGRID_TILE_SIZE 16 +#define IMGU_PIXELS_PER_WORD 50 +#define IMGU_BYTES_PER_WORD64 +#define IMGU_STRIPE_FIXED_HALF_OVERLAP 2 +#define IMGU_SHD_SETS 3 +#define IMGU_BDS_MIN_CLIP_VAL 0 +#define IMGU_BDS_MAX_CLIP_VAL 2 + +#define IMGU_ABI_AWB_MAX_CELLS_PER_SET 160 +#define IMGU_ABI_AF_MAX_CELLS_PER_SET 32 +#define IMGU_ABI_AWB_FR_MAX_CELLS_PER_SET 32 + +#define IMGU_ABI_ACC_OP_IDLE 0 +#define IMGU_ABI_ACC_OP_END_OF_ACK 1 +#define IMGU_ABI_ACC_OP_END_OF_OPS 2 +#define IMGU_ABI_ACC_OP_NO_OPS 3 + +#define IMGU_ABI_ACC_OPTYPE_PROCESS_LINES 0 +#define IMGU_ABI_ACC_OPTYPE_TRANSFER_DATA 1 + +/* Register definitions */ + +/* PM_CTRL_0_5_0_IMGHMMADR */ +#define IMGU_REG_PM_CTRL 0x0 +#define IMGU_PM_CTRL_START BIT(0) +#define IMGU_PM_CTRL_CFG_DONE BIT(1) +#define IMGU_PM_CTRL_RACE_TO_HALT BIT(2) +#define IMGU_PM_CTRL_NACK_ALL BIT(3) +#define IMGU_PM_CTRL_CSS_PWRDN BIT(4) +#define IMGU_PM_CTRL_RST_AT_EOFBIT(5) +#define IMGU_PM_CTRL_FORCE_HALTBIT(6) +#define IMGU_PM_CTRL_FORCE_UNHALT BIT(7) +#define IMGU_PM_CTRL_FORCE_PWRDN BIT(8) +#define IMGU_PM_CTRL_FORCE_RESET BIT(9) + +/* SYSTEM_REQ_0_5_0_IMGHMMADR */ +#define IMGU_REG_SYSTEM_REQ0x18 +#define IMGU_SYSTEM_REQ_FREQ_MASK 0x3f +#define IMGU_SYSTEM_REQ_FREQ_DIVIDER 25 +#define IMGU_REG_INT_STATUS0x30 +#define IMGU_REG_INT_ENABLE0x34 +#define IMGU_REG_INT_CSS_IRQ BIT(31) +/* STATE_0_5_0_IMGHMMADR */ +#define IMGU_REG_STATE 0x130 +#define IMGU_STATE_HALT_STSBIT(0) +#define IMGU_STATE_IDLE_STSBIT(1) +#define IMGU_STATE_POWER_UPBIT(2) +#define IMGU_STATE_POWER_DOWN BIT(3) +#define IMGU_STATE_CSS_BUSY_MASK 0xc0 +#define IMGU_STATE_PM_FSM_MASK 0x180 +#define IMGU_STATE_PWRDNM_FSM_MASK 0x1E0 +/* PM_STS_0_5_0_IMGHMMADR */ +#define IMGU_REG_PM_STS0x140 + +#define IMGU_REG_BASE 0x4000 + +#define IMGU_REG_ISP_CTRL (IMGU_REG_BASE + 0x00) +#define IMGU_CTRL_RST BIT(0) +#define IMGU_CTRL_STARTBIT(1) +#define IMGU_CTRL_BREAKBIT(2) +#define IMGU_CTRL_RUN BIT(3) +#define IMGU_CTRL_BROKEN BIT(4) +#define IMGU_CTRL_IDLE BIT(5) +#define IMGU_CTRL_SLEEPING BIT(6) +#define IMGU_CTRL_STALLING BIT(7) +#define IMGU_CTRL_IRQ_CLEARBIT(8) +#define IMGU_CTRL_IRQ_READYBIT(10) +#define IMGU_CTRL_IRQ_SLEEPING BIT(11) +#define IMGU_CTRL_ICACHE_INV BIT(12) +#define IMGU_CTRL_IPREFETCH_EN BIT(13) +#define IMGU_REG_ISP_START_ADDR(IMGU_REG_BASE + 0x04) +#define IMGU_REG_ISP_ICACHE_ADDR (IMGU_REG_BASE + 0x10) +#define IMGU_REG_ISP_PC(IMGU_REG_BASE + 0x1c) + +/* SP Registers, sp = 0:SP0; 1:SP1 */ +#define IMGU_REG_SP_CTRL(sp) (IMGU_REG_BASE + (sp) * 0x100 + 0x100) + /* For bits in IMGU_REG_SP_CTRL, see IMGU_CTRL_* */ +#define
[PATCH v8 00/17] Intel IPU3 ImgU patchset
Hi, This series adds support for the Intel IPU3 (Image Processing Unit) ImgU which is essentially a modern memory-to-memory ISP. It implements raw Bayer to YUV image format conversion as well as a large number of other pixel processing algorithms for improving the image quality. Meta data formats are defined for image statistics (3A, i.e. automatic white balance, exposure and focus, histogram and local area contrast enhancement) as well as for the pixel processing algorithm parameters. The documentation for these formats is currently not included in the patchset but will be added in a future version of this set. The algorithm parameters need to be considered specific to a given frame and typically a large number of these parameters change on frame to frame basis. Additionally, the parameters are highly structured (and not a flat space of independent configuration primitives). They also reflect the data structures used by the firmware and the hardware. On top of that, the algorithms require highly specialized user space to make meaningful use of them. For these reasons it has been chosen video buffers to pass the parameters to the device. On individual patches: The heart of ImgU is the CSS, or Camera Subsystem, which contains the image processors and HW accelerators. The 3A statistics and other firmware parameter computation related functions are implemented in patch 8. All IPU3 pipeline default settings can be found in patch 7. To access DDR via ImgU's own memory space, IPU3 is also equipped with its own MMU unit, the driver is implemented in patch 3. Patch 4 uses above driver for DMA mapping operation. The communication between IPU3 firmware and driver is implemented with circular queues in patch 5. Patch 6 provide some utility functions and manage IPU3 fw download and install. The firmware which is called ipu3-fw.bin can be downloaded from: git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git (commit 2c27b0cb02f18c022d8378e0e1abaf8b7ae8188f) Firmware ABI is defined in patches 1 and 2. Patches 9 and 10 are of the same file, the former contains all h/w programming related code, the latter implements interface functions for access fw & hw capabilities. Patch 11 implements a v4l2 media framework driver. Patch 12 represents the top level that glues all of the other components together, passing arguments between the components. Patch 14 is a recent effort to extend v6 for advanced camera features like Continuous View Finder (CVF) and Snapshot During Video(SDV) support. The whole series has a dependency on Sakari's work: https://git.linuxtv.org/sailus/media_tree.git/log/?h=meta-output> Patches not to be merged with staging: Patch 15 Add v4l IPU3 meta formats. Patch 16 Reserve v4l2 controls for IPU3 ImgU driver. Patch 17 Documentation of ImgU driver. Link to user space implementation: git clone https://chromium.googlesource.com/chromiumos/platform/arc-camera ImgU media topology print: # media-ctl -d /dev/media0 -p Media controller API version 4.20.0 Media device information driver ipu3-imgu model ipu3-imgu serial bus infoPCI::00:05.0 hw revision 0x80862015 driver version 4.20.0 Device topology - entity 1: ipu3-imgu 0 (5 pads, 5 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 pad0: Sink [fmt:FIXED/1920x1080 field:none colorspace:raw crop:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "ipu3-imgu 0 input":0 [] pad1: Sink [fmt:FIXED/1920x1080 field:none colorspace:raw] <- "ipu3-imgu 0 parameters":0 [] pad2: Source [fmt:FIXED/1920x1080 field:none colorspace:raw] -> "ipu3-imgu 0 output":0 [] pad3: Source [fmt:FIXED/1920x1080 field:none colorspace:raw] -> "ipu3-imgu 0 viewfinder":0 [] pad4: Source [fmt:FIXED/1920x1080 field:none colorspace:raw] -> "ipu3-imgu 0 3a stat":0 [] - entity 7: ipu3-imgu 0 input (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: Source -> "ipu3-imgu 0":0 [] - entity 13: ipu3-imgu 0 parameters (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video1 pad0: Source -> "ipu3-imgu 0":1 [] - entity 19: ipu3-imgu 0 output (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: Sink <- "ipu3-imgu 0":2 [] - entity 25: ipu3-imgu 0 viewfinder (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video3 pad0: Sink <- "ipu3-imgu 0":3 [] - entity 31: ipu3-imgu 0 3a stat (1 pad, 1 link) type Node subtype V4L
[PATCH v8 11/17] media: staging/intel-ipu3: Add v4l2 driver based on media framework
Implement video driver that utilizes v4l2, vb2 queue support
and media controller APIs. The driver exposes single subdevice and
six nodes.
Signed-off-by: Yong Zhi
---
drivers/staging/media/ipu3/ipu3-v4l2.c | 1086
1 file changed, 1086 insertions(+)
create mode 100644 drivers/staging/media/ipu3/ipu3-v4l2.c
diff --git a/drivers/staging/media/ipu3/ipu3-v4l2.c
b/drivers/staging/media/ipu3/ipu3-v4l2.c
new file mode 100644
index ..038ee749cb75
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-v4l2.c
@@ -0,0 +1,1086 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include
+#include
+
+#include
+
+#include "ipu3.h"
+#include "ipu3-dmamap.h"
+
+/ v4l2_subdev_ops /
+
+static int ipu3_subdev_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+ struct v4l2_rect try_crop = {
+ .top = 0,
+ .left = 0,
+ .width = 1920,
+ .height = 1080,
+ };
+ unsigned int i;
+
+ /* Initialize try_fmt */
+ for (i = 0; i < IMGU_NODE_NUM; i++) {
+ struct v4l2_mbus_framefmt *try_fmt =
+ v4l2_subdev_get_try_format(sd, fh->pad, i);
+
+ try_fmt->width = try_crop.width;
+ try_fmt->height = try_crop.height;
+ try_fmt->code = MEDIA_BUS_FMT_FIXED;
+ try_fmt->colorspace = V4L2_COLORSPACE_RAW;
+ try_fmt->field = V4L2_FIELD_NONE;
+ }
+
+ *v4l2_subdev_get_try_crop(sd, fh->pad, IMGU_NODE_IN) = try_crop;
+ *v4l2_subdev_get_try_compose(sd, fh->pad, IMGU_NODE_IN) = try_crop;
+
+ return 0;
+}
+
+static int ipu3_subdev_s_stream(struct v4l2_subdev *sd, int enable)
+{
+ struct imgu_device *imgu = container_of(sd, struct imgu_device, subdev);
+ int r = 0;
+
+ r = imgu_s_stream(imgu, enable);
+ if (!r)
+ imgu->streaming = enable;
+
+ return r;
+}
+
+static int ipu3_subdev_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+ struct imgu_device *imgu = container_of(sd, struct imgu_device, subdev);
+ struct v4l2_mbus_framefmt *mf;
+ u32 pad = fmt->pad;
+
+ if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
+ fmt->format = imgu->nodes[pad].pad_fmt;
+ } else {
+ mf = v4l2_subdev_get_try_format(sd, cfg, pad);
+ fmt->format = *mf;
+ }
+
+ return 0;
+}
+
+static int ipu3_subdev_set_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+ struct imgu_device *imgu = container_of(sd, struct imgu_device, subdev);
+ struct v4l2_mbus_framefmt *mf;
+ u32 pad = fmt->pad;
+
+ if (fmt->which == V4L2_SUBDEV_FORMAT_TRY)
+ mf = v4l2_subdev_get_try_format(sd, cfg, pad);
+ else
+ mf = >nodes[pad].pad_fmt;
+
+ fmt->format.code = mf->code;
+ /* Clamp the w and h based on the hardware capabilities */
+ if (imgu->subdev_pads[pad].flags & MEDIA_PAD_FL_SOURCE) {
+ fmt->format.width = clamp(fmt->format.width,
+ IPU3_OUTPUT_MIN_WIDTH,
+ IPU3_OUTPUT_MAX_WIDTH);
+ fmt->format.height = clamp(fmt->format.height,
+ IPU3_OUTPUT_MIN_HEIGHT,
+ IPU3_OUTPUT_MAX_HEIGHT);
+ } else {
+ fmt->format.width = clamp(fmt->format.width,
+ IPU3_INPUT_MIN_WIDTH,
+ IPU3_INPUT_MAX_WIDTH);
+ fmt->format.height = clamp(fmt->format.height,
+ IPU3_INPUT_MIN_HEIGHT,
+ IPU3_INPUT_MAX_HEIGHT);
+ }
+
+ *mf = fmt->format;
+
+ return 0;
+}
+
+static int ipu3_subdev_get_selection(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_selection *sel)
+{
+ struct imgu_device *imgu = container_of(sd, struct imgu_device, subdev);
+ struct v4l2_rect *try_sel, *r;
+
+ if (sel->pad != IMGU_NODE_IN)
+ return -EINVAL;
+
+ switch (sel->target) {
+ case V4L2_SEL_TGT_CROP:
+ try_sel = v4l2_subdev_get_try_crop(sd, cfg, sel->pad);
+ r = >rect.eff;
+ break;
+ case V4L2_SEL_TGT_COMPOSE:
+ try_sel = v4l2_subdev_get_try_compose(sd, cfg, sel->pad);
+ r = >rect.bds;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (sel->which ==
[PATCH v8 13/17] media: staging/intel-ipu3: Add Intel IPU3 meta data uAPI
These meta formats are used on Intel IPU3 ImgU video queues
to carry 3A statistics and ISP pipeline parameters.
V4L2_META_FMT_IPU3_3A
V4L2_META_FMT_IPU3_PARAMS
Signed-off-by: Yong Zhi
Signed-off-by: Chao C Li
Signed-off-by: Rajmohan Mani
---
drivers/staging/media/ipu3/include/intel-ipu3.h | 2775 +++
1 file changed, 2775 insertions(+)
create mode 100644 drivers/staging/media/ipu3/include/intel-ipu3.h
diff --git a/drivers/staging/media/ipu3/include/intel-ipu3.h
b/drivers/staging/media/ipu3/include/intel-ipu3.h
new file mode 100644
index ..07fd66817358
--- /dev/null
+++ b/drivers/staging/media/ipu3/include/intel-ipu3.h
@@ -0,0 +1,2775 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2017 - 2018 Intel Corporation */
+
+#ifndef __IPU3_UAPI_H
+#define __IPU3_UAPI_H
+
+#include
+
+/* from /drivers/staging/media/ipu3/include/videodev2.h */
+
+/* Vendor specific - used for IPU3 camera sub-system */
+#define V4L2_META_FMT_IPU3_PARAMS v4l2_fourcc('i', 'p', '3', 'p') /* IPU3
processing parameters */
+#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') /* IPU3
3A statistics */
+
+/*** ipu3_uapi_stats_3a ***/
+
+#define IPU3_UAPI_MAX_STRIPES 2
+#define IPU3_UAPI_MAX_BUBBLE_SIZE 10
+
+#define IPU3_UAPI_GRID_START_MASK ((1 << 12) - 1)
+#define IPU3_UAPI_GRID_Y_START_EN (1 << 15)
+
+/* controls generation of meta_data (like FF enable/disable) */
+#define IPU3_UAPI_AWB_RGBS_THR_B_EN(1 << 14)
+#define IPU3_UAPI_AWB_RGBS_THR_B_INCL_SAT (1 << 15)
+
+/**
+ * struct ipu3_uapi_grid_config - Grid plane config
+ *
+ * @width: Grid horizontal dimensions, in number of grid blocks(cells).
+ * @height:Grid vertical dimensions, in number of grid cells.
+ * @block_width_log2: Log2 of the width of each cell in pixels.
+ * for (2^3, 2^4, 2^5, 2^6, 2^7), values [3, 7].
+ * @block_height_log2: Log2 of the height of each cell in pixels.
+ * for (2^3, 2^4, 2^5, 2^6, 2^7), values [3, 7].
+ * @height_per_slice: The number of blocks in vertical axis per slice.
+ * Default 2.
+ * @x_start: X value of top left corner of Region of Interest(ROI).
+ * @y_start: Y value of top left corner of ROI
+ * @x_end: X value of bottom right corner of ROI
+ * @y_end: Y value of bottom right corner of ROI
+ *
+ * Due to the size of total amount of collected data, most statistics
+ * create a grid-based output, and the data is then divided into "slices".
+ */
+struct ipu3_uapi_grid_config {
+ __u8 width;
+ __u8 height;
+ __u16 block_width_log2:3;
+ __u16 block_height_log2:3;
+ __u16 height_per_slice:8;
+ __u16 x_start;
+ __u16 y_start;
+ __u16 x_end;
+ __u16 y_end;
+} __packed;
+
+/*
+ * The grid based data is divided into "slices" called set, each slice of setX
+ * refers to ipu3_uapi_grid_config width * height_per_slice.
+ */
+#define IPU3_UAPI_AWB_MAX_SETS 60
+/* Based on grid size 80 * 60 and cell size 16 x 16 */
+#define IPU3_UAPI_AWB_SET_SIZE 1280
+#define IPU3_UAPI_AWB_MD_ITEM_SIZE 8
+#define IPU3_UAPI_AWB_SPARE_FOR_BUBBLES \
+ (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \
+IPU3_UAPI_AWB_MD_ITEM_SIZE)
+#define IPU3_UAPI_AWB_MAX_BUFFER_SIZE \
+ (IPU3_UAPI_AWB_MAX_SETS * \
+(IPU3_UAPI_AWB_SET_SIZE + IPU3_UAPI_AWB_SPARE_FOR_BUBBLES))
+
+
+/**
+ * struct ipu3_uapi_awb_raw_buffer - AWB raw buffer
+ *
+ * @meta_data: buffer to hold auto white balance meta data which is
+ * the average values for each color channel.
+ */
+struct ipu3_uapi_awb_raw_buffer {
+ __u8 meta_data[IPU3_UAPI_AWB_MAX_BUFFER_SIZE]
+ __attribute__((aligned(32)));
+} __packed;
+
+/**
+ * struct ipu3_uapi_awb_config_s - AWB config
+ *
+ * @rgbs_thr_gr: gr threshold value.
+ * @rgbs_thr_r: Red threshold value.
+ * @rgbs_thr_gb: gb threshold value.
+ * @rgbs_thr_b: Blue threshold value.
+ * @grid: _uapi_grid_config, the default grid resolution is 16x16 cells.
+ *
+ * The threshold is a saturation measure range [0, 8191], 8191 is default.
+ * Values over threshold may be optionally rejected for averaging.
+ */
+struct ipu3_uapi_awb_config_s {
+ __u16 rgbs_thr_gr;
+ __u16 rgbs_thr_r;
+ __u16 rgbs_thr_gb;
+ __u16 rgbs_thr_b;
+ struct ipu3_uapi_grid_config grid;
+} __attribute__((aligned(32))) __packed;
+
+/**
+ * struct ipu3_uapi_awb_config - AWB config wrapper
+ *
+ * @config: config for auto white balance as defined by _uapi_awb_config_s
+ */
+struct ipu3_uapi_awb_config {
+ struct ipu3_uapi_awb_config_s config __attribute__((aligned(32)));
+} __packed;
+
+#define IPU3_UAPI_AE_COLORS4 /* R, G, B, Y */
+#define IPU3_UAPI_AE_BINS
[PATCH v8 05/17] media: staging/intel-ipu3: css: Add dma buff pool utility functions
The pools are used to store previous parameters set by
user with the parameter queue. Due to pipelining,
there needs to be multiple sets (up to four)
of parameters which are queued in a host-to-sp queue.
Signed-off-by: Yong Zhi
---
drivers/staging/media/ipu3/ipu3-css-pool.c | 100 +
drivers/staging/media/ipu3/ipu3-css-pool.h | 55
2 files changed, 155 insertions(+)
create mode 100644 drivers/staging/media/ipu3/ipu3-css-pool.c
create mode 100644 drivers/staging/media/ipu3/ipu3-css-pool.h
diff --git a/drivers/staging/media/ipu3/ipu3-css-pool.c
b/drivers/staging/media/ipu3/ipu3-css-pool.c
new file mode 100644
index ..6f271f81669b
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-css-pool.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include
+
+#include "ipu3.h"
+#include "ipu3-css-pool.h"
+#include "ipu3-dmamap.h"
+
+int ipu3_css_dma_buffer_resize(struct imgu_device *imgu,
+ struct ipu3_css_map *map, size_t size)
+{
+ if (map->size < size && map->vaddr) {
+ dev_warn(>pci_dev->dev, "dma buf resized from %zu to %zu",
+map->size, size);
+
+ ipu3_dmamap_free(imgu, map);
+ if (!ipu3_dmamap_alloc(imgu, map, size))
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+void ipu3_css_pool_cleanup(struct imgu_device *imgu, struct ipu3_css_pool
*pool)
+{
+ unsigned int i;
+
+ for (i = 0; i < IPU3_CSS_POOL_SIZE; i++)
+ ipu3_dmamap_free(imgu, >entry[i].param);
+}
+
+int ipu3_css_pool_init(struct imgu_device *imgu, struct ipu3_css_pool *pool,
+ size_t size)
+{
+ unsigned int i;
+
+ for (i = 0; i < IPU3_CSS_POOL_SIZE; i++) {
+ pool->entry[i].valid = false;
+ if (size == 0) {
+ pool->entry[i].param.vaddr = NULL;
+ continue;
+ }
+
+ if (!ipu3_dmamap_alloc(imgu, >entry[i].param, size))
+ goto fail;
+ }
+
+ pool->last = IPU3_CSS_POOL_SIZE;
+
+ return 0;
+
+fail:
+ ipu3_css_pool_cleanup(imgu, pool);
+ return -ENOMEM;
+}
+
+/*
+ * Allocate a new parameter via recycling the oldest entry in the pool.
+ */
+void ipu3_css_pool_get(struct ipu3_css_pool *pool)
+{
+ /* Get the oldest entry */
+ u32 n = (pool->last + 1) % IPU3_CSS_POOL_SIZE;
+
+ pool->entry[n].valid = true;
+ pool->last = n;
+}
+
+/*
+ * Undo, for all practical purposes, the effect of pool_get().
+ */
+void ipu3_css_pool_put(struct ipu3_css_pool *pool)
+{
+ pool->entry[pool->last].valid = false;
+ pool->last = (pool->last + IPU3_CSS_POOL_SIZE - 1) % IPU3_CSS_POOL_SIZE;
+}
+
+/**
+ * ipu3_css_pool_last - Retrieve the nth pool entry from last
+ *
+ * @pool: a pointer to ipu3_css_pool.
+ * @n: the distance to the last index.
+ *
+ * Returns:
+ * The nth entry from last or null map to indicate no frame stored.
+ */
+const struct ipu3_css_map *
+ipu3_css_pool_last(struct ipu3_css_pool *pool, unsigned int n)
+{
+ static const struct ipu3_css_map null_map = { 0 };
+ int i = (pool->last + IPU3_CSS_POOL_SIZE - n) % IPU3_CSS_POOL_SIZE;
+
+ WARN_ON(n >= IPU3_CSS_POOL_SIZE);
+
+ if (!pool->entry[i].valid)
+ return _map;
+
+ return >entry[i].param;
+}
diff --git a/drivers/staging/media/ipu3/ipu3-css-pool.h
b/drivers/staging/media/ipu3/ipu3-css-pool.h
new file mode 100644
index ..9c895efd2bfa
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-css-pool.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2018 Intel Corporation */
+
+#ifndef __IPU3_UTIL_H
+#define __IPU3_UTIL_H
+
+struct device;
+struct imgu_device;
+
+#define IPU3_CSS_POOL_SIZE 4
+
+/**
+ * ipu3_css_map - store DMA mapping info for buffer
+ *
+ * @size: size of the buffer in bytes.
+ * @vaddr: kernel virtual address.
+ * @daddr: iova dma address to access IPU3.
+ * @vma: private, a pointer to vm_struct,
+ * used for ipu3_dmamap_free.
+ */
+struct ipu3_css_map {
+ size_t size;
+ void *vaddr;
+ dma_addr_t daddr;
+ struct vm_struct *vma;
+};
+
+/**
+ * ipu3_css_pool - circular buffer pool definition
+ *
+ * @entry: array with IPU3_CSS_POOL_SIZE elements.
+ * @entry.param: a ipu3_css_map for storing the mem mapping.
+ * @entry.valid: used to mark if the entry has vaid data.
+ * @last: write pointer, initialized to IPU3_CSS_POOL_SIZE.
+ */
+struct ipu3_css_pool {
+ struct {
+ struct ipu3_css_map param;
+ bool valid;
+ } entry[IPU3_CSS_POOL_SIZE];
+ u32 last;
+};
+
+int ipu3_css_dma_buffer_resize(struct imgu_device *imgu,
+ struct
[PATCH v8 04/17] media: staging/intel-ipu3: Implement DMA mapping functions
From: Tomasz Figa
This driver uses IOVA space for buffer mapping through IPU3 MMU
to transfer data between imaging pipelines and system DDR.
Signed-off-by: Tomasz Figa
Signed-off-by: Yong Zhi
---
drivers/staging/media/ipu3/ipu3-dmamap.c | 270 +++
drivers/staging/media/ipu3/ipu3-dmamap.h | 22 +++
2 files changed, 292 insertions(+)
create mode 100644 drivers/staging/media/ipu3/ipu3-dmamap.c
create mode 100644 drivers/staging/media/ipu3/ipu3-dmamap.h
diff --git a/drivers/staging/media/ipu3/ipu3-dmamap.c
b/drivers/staging/media/ipu3/ipu3-dmamap.c
new file mode 100644
index ..93a393d4e15e
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-dmamap.c
@@ -0,0 +1,270 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Intel Corporation
+ * Copyright 2018 Google LLC.
+ *
+ * Author: Tomasz Figa
+ * Author: Yong Zhi
+ */
+
+#include
+
+#include "ipu3.h"
+#include "ipu3-css-pool.h"
+#include "ipu3-mmu.h"
+
+/*
+ * Free a buffer allocated by ipu3_dmamap_alloc_buffer()
+ */
+static void ipu3_dmamap_free_buffer(struct page **pages,
+ size_t size)
+{
+ int count = size >> PAGE_SHIFT;
+
+ while (count--)
+ __free_page(pages[count]);
+ kvfree(pages);
+}
+
+/*
+ * Based on the implementation of __iommu_dma_alloc_pages()
+ * defined in drivers/iommu/dma-iommu.c
+ */
+static struct page **ipu3_dmamap_alloc_buffer(size_t size,
+ unsigned long order_mask,
+ gfp_t gfp)
+{
+ struct page **pages;
+ unsigned int i = 0, count = size >> PAGE_SHIFT;
+ const gfp_t high_order_gfp = __GFP_NOWARN | __GFP_NORETRY;
+
+ /* Allocate mem for array of page ptrs */
+ pages = kvmalloc_array(count, sizeof(*pages), GFP_KERNEL);
+
+ if (!pages)
+ return NULL;
+
+ order_mask &= (2U << MAX_ORDER) - 1;
+ if (!order_mask)
+ return NULL;
+
+ gfp |= __GFP_HIGHMEM | __GFP_ZERO;
+
+ while (count) {
+ struct page *page = NULL;
+ unsigned int order_size;
+
+ for (order_mask &= (2U << __fls(count)) - 1;
+order_mask; order_mask &= ~order_size) {
+ unsigned int order = __fls(order_mask);
+
+ order_size = 1U << order;
+ page = alloc_pages((order_mask - order_size) ?
+ gfp | high_order_gfp : gfp, order);
+ if (!page)
+ continue;
+ if (!order)
+ break;
+ if (!PageCompound(page)) {
+ split_page(page, order);
+ break;
+ }
+
+ __free_pages(page, order);
+ }
+ if (!page) {
+ ipu3_dmamap_free_buffer(pages, i << PAGE_SHIFT);
+ return NULL;
+ }
+ count -= order_size;
+ while (order_size--)
+ pages[i++] = page++;
+ }
+
+ return pages;
+}
+
+/**
+ * ipu3_dmamap_alloc - allocate and map a buffer into KVA
+ * @imgu: struct device pointer
+ * @map: struct to store mapping variables
+ * @len: size required
+ *
+ * Returns:
+ * KVA on success
+ * %NULL on failure
+ */
+void *ipu3_dmamap_alloc(struct imgu_device *imgu, struct ipu3_css_map *map,
+ size_t len)
+{
+ unsigned long shift = iova_shift(>iova_domain);
+ unsigned int alloc_sizes = imgu->mmu->pgsize_bitmap;
+ struct device *dev = >pci_dev->dev;
+ size_t size = PAGE_ALIGN(len);
+ struct page **pages;
+ dma_addr_t iovaddr;
+ struct iova *iova;
+ int i, rval;
+
+ dev_dbg(dev, "%s: allocating %zu\n", __func__, size);
+
+ iova = alloc_iova(>iova_domain, size >> shift,
+ imgu->mmu->aperture_end >> shift, 0);
+ if (!iova)
+ return NULL;
+
+ pages = ipu3_dmamap_alloc_buffer(size, alloc_sizes >> PAGE_SHIFT,
+GFP_KERNEL);
+ if (!pages)
+ goto out_free_iova;
+
+ /* Call IOMMU driver to setup pgt */
+ iovaddr = iova_dma_addr(>iova_domain, iova);
+ for (i = 0; i < size / PAGE_SIZE; ++i) {
+ rval = ipu3_mmu_map(imgu->mmu, iovaddr,
+ page_to_phys(pages[i]), PAGE_SIZE);
+ if (rval)
+ goto out_unmap;
+
+ iovaddr += PAGE_SIZE;
+ }
+
+ /* Now grab a virtual region */
+ map->vma = __get_vm_area(size, VM_USERMAP, VMALLOC_START, VMALLOC_END);
+ if (!map->vma)
+ goto out_unmap;
+
+ map->vma->pages = pages;
+ /* And map it in KVA */
+ if
[PATCH v8 02/17] media: staging/intel-ipu3: abi: Add structs
This add all the structs of IPU3 firmware ABI.
Signed-off-by: Yong Zhi
Signed-off-by: Rajmohan Mani
Reviewed-by: Laurent Pinchart
---
drivers/staging/media/ipu3/ipu3-abi.h | 1350 +
1 file changed, 1350 insertions(+)
diff --git a/drivers/staging/media/ipu3/ipu3-abi.h
b/drivers/staging/media/ipu3/ipu3-abi.h
index e754ff5836c2..25be56ff01c8 100644
--- a/drivers/staging/media/ipu3/ipu3-abi.h
+++ b/drivers/staging/media/ipu3/ipu3-abi.h
@@ -658,4 +658,1354 @@ enum imgu_abi_stage_type {
IMGU_ABI_STAGE_TYPE_ISP,
};
+struct imgu_abi_acc_operation {
+ /*
+* zero means on init,
+* others mean upon receiving an ack signal from the BC acc.
+*/
+ u8 op_indicator;
+ u8 op_type;
+} __packed;
+
+struct imgu_abi_acc_process_lines_cmd_data {
+ u16 lines;
+ u8 cfg_set;
+ u8 reserved;/* Align to 4 bytes */
+} __packed;
+
+/* Bayer shading definitions */
+
+struct imgu_abi_shd_transfer_luts_set_data {
+ u8 set_number;
+ u8 padding[3];
+ imgu_addr_t rg_lut_ddr_addr;
+ imgu_addr_t bg_lut_ddr_addr;
+ u32 align_dummy;
+} __packed;
+
+struct imgu_abi_shd_grid_config {
+ /* reg 0 */
+ u32 grid_width:8;
+ u32 grid_height:8;
+ u32 block_width:3;
+ u32 reserved0:1;
+ u32 block_height:3;
+ u32 reserved1:1;
+ u32 grid_height_per_slice:8;
+ /* reg 1 */
+ s32 x_start:13;
+ s32 reserved2:3;
+ s32 y_start:13;
+ s32 reserved3:3;
+} __packed;
+
+struct imgu_abi_shd_general_config {
+ u32 init_set_vrt_offst_ul:8;
+ u32 shd_enable:1;
+ /* aka 'gf' */
+ u32 gain_factor:2;
+ u32 reserved:21;
+} __packed;
+
+struct imgu_abi_shd_black_level_config {
+ /* reg 0 */
+ s32 bl_r:12;
+ s32 reserved0:4;
+ s32 bl_gr:12;
+ u32 reserved1:1;
+ /* aka 'nf' */
+ u32 normalization_shift:3;
+ /* reg 1 */
+ s32 bl_gb:12;
+ s32 reserved2:4;
+ s32 bl_b:12;
+ s32 reserved3:4;
+} __packed;
+
+struct imgu_abi_shd_intra_frame_operations_data {
+ struct imgu_abi_acc_operation
+ operation_list[IMGU_ABI_SHD_MAX_OPERATIONS] __aligned(32);
+ struct imgu_abi_acc_process_lines_cmd_data
+ process_lines_data[IMGU_ABI_SHD_MAX_PROCESS_LINES]
__aligned(32);
+ struct imgu_abi_shd_transfer_luts_set_data
+ transfer_data[IMGU_ABI_SHD_MAX_TRANSFERS] __aligned(32);
+} __packed;
+
+struct imgu_abi_shd_config {
+ struct ipu3_uapi_shd_config_static shd __aligned(32);
+ struct imgu_abi_shd_intra_frame_operations_data shd_ops __aligned(32);
+ struct ipu3_uapi_shd_lut shd_lut __aligned(32);
+} __packed;
+
+struct imgu_abi_stripe_input_frame_resolution {
+ u16 width;
+ u16 height;
+ u32 bayer_order;/* enum ipu3_uapi_bayer_order */
+ u32 raw_bit_depth;
+} __packed;
+
+/* Stripe-based processing */
+
+struct imgu_abi_stripes {
+ /* offset from start of frame - measured in pixels */
+ u16 offset;
+ /* stripe width - measured in pixels */
+ u16 width;
+ /* stripe width - measured in pixels */
+ u16 height;
+} __packed;
+
+struct imgu_abi_stripe_data {
+ /*
+* number of stripes for current processing source
+* - VLIW binary parameter we currently support 1 or 2 stripes
+*/
+ u16 num_of_stripes;
+
+ u8 padding[2];
+
+ /*
+* the following data is derived from resolution-related
+* pipe config and from num_of_stripes
+*/
+
+ /*
+*'input-stripes' - before input cropping
+* used by input feeder
+*/
+ struct imgu_abi_stripe_input_frame_resolution input_frame;
+
+ /*'effective-stripes' - after input cropping used dpc, bds */
+ struct imgu_abi_stripes effective_stripes[IPU3_UAPI_MAX_STRIPES];
+
+ /* 'down-scaled-stripes' - after down-scaling ONLY. used by BDS */
+ struct imgu_abi_stripes down_scaled_stripes[IPU3_UAPI_MAX_STRIPES];
+
+ /*
+*'bds-out-stripes' - after bayer down-scaling and padding.
+* used by all algos starting with norm up to the ref-frame for GDC
+* (currently up to the output kernel)
+*/
+ struct imgu_abi_stripes bds_out_stripes[IPU3_UAPI_MAX_STRIPES];
+
+ /* 'bds-out-stripes (no overlap)' - used for ref kernel */
+ struct imgu_abi_stripes
+ bds_out_stripes_no_overlap[IPU3_UAPI_MAX_STRIPES];
+
+ /*
+* input resolution for output system (equal to bds_out - envelope)
+* output-system input frame width as configured by user
+*/
+ u16 output_system_in_frame_width;
+ /* output-system input frame height as configured by user */
+ u16 output_system_in_frame_height;
+
+ /*
+* 'output-stripes' - accounts for stiching on the output (no overlap)
+*
[PATCH v8 03/17] media: staging/intel-ipu3: mmu: Implement driver
From: Tomasz Figa
This driver translates IO virtual address to physical
address based on two levels page tables.
Signed-off-by: Tomasz Figa
Signed-off-by: Yong Zhi
---
drivers/staging/media/ipu3/ipu3-mmu.c | 561 ++
drivers/staging/media/ipu3/ipu3-mmu.h | 35 +++
2 files changed, 596 insertions(+)
create mode 100644 drivers/staging/media/ipu3/ipu3-mmu.c
create mode 100644 drivers/staging/media/ipu3/ipu3-mmu.h
diff --git a/drivers/staging/media/ipu3/ipu3-mmu.c
b/drivers/staging/media/ipu3/ipu3-mmu.c
new file mode 100644
index ..b9f209541f78
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-mmu.c
@@ -0,0 +1,561 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Intel Corporation.
+ * Copyright 2018 Google LLC.
+ *
+ * Author: Tuukka Toivonen
+ * Author: Sakari Ailus
+ * Author: Samu Onkalo
+ * Author: Tomasz Figa
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "ipu3-mmu.h"
+
+#define IPU3_PAGE_SHIFT12
+#define IPU3_PAGE_SIZE (1UL << IPU3_PAGE_SHIFT)
+
+#define IPU3_PT_BITS 10
+#define IPU3_PT_PTES (1UL << IPU3_PT_BITS)
+#define IPU3_PT_SIZE (IPU3_PT_PTES << 2)
+#define IPU3_PT_ORDER (IPU3_PT_SIZE >> PAGE_SHIFT)
+
+#define IPU3_ADDR2PTE(addr)((addr) >> IPU3_PAGE_SHIFT)
+#define IPU3_PTE2ADDR(pte) ((phys_addr_t)(pte) << IPU3_PAGE_SHIFT)
+
+#define IPU3_L2PT_SHIFTIPU3_PT_BITS
+#define IPU3_L2PT_MASK ((1UL << IPU3_L2PT_SHIFT) - 1)
+
+#define IPU3_L1PT_SHIFTIPU3_PT_BITS
+#define IPU3_L1PT_MASK ((1UL << IPU3_L1PT_SHIFT) - 1)
+
+#define IPU3_MMU_ADDRESS_BITS (IPU3_PAGE_SHIFT + \
+IPU3_L2PT_SHIFT + \
+IPU3_L1PT_SHIFT)
+
+#define IMGU_REG_BASE 0x4000
+#define REG_TLB_INVALIDATE (IMGU_REG_BASE + 0x300)
+#define TLB_INVALIDATE 1
+#define REG_L1_PHYS(IMGU_REG_BASE + 0x304) /* 27-bit pfn */
+#define REG_GP_HALT(IMGU_REG_BASE + 0x5dc)
+#define REG_GP_HALTED (IMGU_REG_BASE + 0x5e0)
+
+struct ipu3_mmu {
+ struct device *dev;
+ void __iomem *base;
+ /* protect access to l2pts, l1pt */
+ spinlock_t lock;
+
+ void *dummy_page;
+ u32 dummy_page_pteval;
+
+ u32 *dummy_l2pt;
+ u32 dummy_l2pt_pteval;
+
+ u32 **l2pts;
+ u32 *l1pt;
+
+ struct ipu3_mmu_info geometry;
+};
+
+static inline struct ipu3_mmu *to_ipu3_mmu(struct ipu3_mmu_info *info)
+{
+ return container_of(info, struct ipu3_mmu, geometry);
+}
+
+/**
+ * ipu3_mmu_tlb_invalidate - invalidate translation look-aside buffer
+ * @mmu: MMU to perform the invalidate operation on
+ *
+ * This function invalidates the whole TLB. Must be called when the hardware
+ * is powered on.
+ */
+static void ipu3_mmu_tlb_invalidate(struct ipu3_mmu *mmu)
+{
+ writel(TLB_INVALIDATE, mmu->base + REG_TLB_INVALIDATE);
+}
+
+static void call_if_ipu3_is_powered(struct ipu3_mmu *mmu,
+ void (*func)(struct ipu3_mmu *mmu))
+{
+ if (!pm_runtime_get_if_in_use(mmu->dev))
+ return;
+
+ func(mmu);
+ pm_runtime_put(mmu->dev);
+}
+
+/**
+ * ipu3_mmu_set_halt - set CIO gate halt bit
+ * @mmu: MMU to set the CIO gate bit in.
+ * @halt: Desired state of the gate bit.
+ *
+ * This function sets the CIO gate bit that controls whether external memory
+ * accesses are allowed. Must be called when the hardware is powered on.
+ */
+static void ipu3_mmu_set_halt(struct ipu3_mmu *mmu, bool halt)
+{
+ int ret;
+ u32 val;
+
+ writel(halt, mmu->base + REG_GP_HALT);
+ ret = readl_poll_timeout(mmu->base + REG_GP_HALTED,
+val, (val & 1) == halt, 1000, 10);
+
+ if (ret)
+ dev_err(mmu->dev, "failed to %s CIO gate halt\n",
+ halt ? "set" : "clear");
+}
+
+/**
+ * ipu3_mmu_alloc_page_table - allocate a pre-filled page table
+ * @pteval: Value to initialize for page table entries with.
+ *
+ * Return: Pointer to allocated page table or NULL on failure.
+ */
+static u32 *ipu3_mmu_alloc_page_table(u32 pteval)
+{
+ u32 *pt;
+ int pte;
+
+ pt = (u32 *)__get_free_page(GFP_KERNEL);
+ if (!pt)
+ return NULL;
+
+ for (pte = 0; pte < IPU3_PT_PTES; pte++)
+ pt[pte] = pteval;
+
+ set_memory_uc((unsigned long int)pt, IPU3_PT_ORDER);
+
+ return pt;
+}
+
+/**
+ * ipu3_mmu_free_page_table - free page table
+ * @pt: Page table to free.
+ */
+static void ipu3_mmu_free_page_table(u32 *pt)
+{
+ set_memory_wb((unsigned long int)pt, IPU3_PT_ORDER);
+ free_page((unsigned long)pt);
+}
+
+/**
+ * address_to_pte_idx - split IOVA into L1 and L2 page table indices
+ * @iova: IOVA to split.
+ * @l1pt_idx: Output for the L1 page table index.
+ * @l2pt_idx: Output for the L2 page index.
[PATCH v8 17/17] doc-rst: Add Intel IPU3 documentation
From: Rajmohan Mani
This patch adds the details about the IPU3 Imaging Unit driver.
Change-Id: I560cecf673df2dcc3ec72767cf8077708d649656
Signed-off-by: Rajmohan Mani
---
Documentation/media/v4l-drivers/index.rst | 1 +
Documentation/media/v4l-drivers/ipu3.rst | 326 ++
2 files changed, 327 insertions(+)
create mode 100644 Documentation/media/v4l-drivers/ipu3.rst
diff --git a/Documentation/media/v4l-drivers/index.rst
b/Documentation/media/v4l-drivers/index.rst
index 6cdd3bc98202..f28570ec9e42 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -44,6 +44,7 @@ For more details see the file COPYING in the source
distribution of Linux.
davinci-vpbe
fimc
imx
+ ipu3
ivtv
max2175
meye
diff --git a/Documentation/media/v4l-drivers/ipu3.rst
b/Documentation/media/v4l-drivers/ipu3.rst
new file mode 100644
index ..045bf4222b1a
--- /dev/null
+++ b/Documentation/media/v4l-drivers/ipu3.rst
@@ -0,0 +1,326 @@
+.. include::
+
+===
+Intel Image Processing Unit 3 (IPU3) Imaging Unit (ImgU) driver
+===
+
+Copyright |copy| 2018 Intel Corporation
+
+Introduction
+
+
+This file documents Intel IPU3 (3rd generation Image Processing Unit) Imaging
+Unit driver located under drivers/media/pci/intel/ipu3.
+
+The Intel IPU3 found in certain Kaby Lake (as well as certain Sky Lake)
+platforms (U/Y processor lines) is made up of two parts namely Imaging Unit
+(ImgU) and CIO2 device (MIPI CSI2 receiver).
+
+The CIO2 device receives the raw bayer data from the sensors and outputs the
+frames in a format that is specific to IPU3 (for consumption by IPU3 ImgU).
+CIO2 driver is available as drivers/media/pci/intel/ipu3/ipu3-cio2* and is
+enabled through the CONFIG_VIDEO_IPU3_CIO2 config option.
+
+The Imaging Unit (ImgU) is responsible for processing images captured
+through IPU3 CIO2 device. The ImgU driver sources can be found under
+drivers/media/pci/intel/ipu3 directory. The driver is enabled through the
+CONFIG_VIDEO_IPU3_IMGU config option.
+
+The two driver modules are named ipu3-csi2 and ipu3-imgu, respectively.
+
+The driver has been tested on Kaby Lake platforms (U/Y processor lines).
+
+The driver implements V4L2, Media controller and V4L2 sub-device interfaces.
+Camera sensors that have CSI-2 bus, which are connected to the IPU3 CIO2
+device are supported. Support for lens and flash drivers depends on the
+above sensors.
+
+ImgU device nodes
+=
+
+The ImgU is represented as two V4L2 subdevs, each of which provides a V4L2
+subdev interface to the user space.
+
+Each V4L2 subdev represents a pipe, which can support a maximum of 2
+streams. A private ioctl can be used to configure the mode (video or still)
+of the pipe.
+
+This helps to support advanced camera features like Continuous View Finder
+(CVF) and Snapshot During Video(SDV).
+
+CIO2 device
+===
+
+The CIO2 is represented as a single V4L2 subdev, which provides a V4L2 subdev
+interface to the user space. There is a video node for each CSI-2 receiver,
+with a single media controller interface for the entire device.
+
+Media controller
+
+
+The media device interface allows to configure the ImgU links, which defines
+the behavior of the IPU3 firmware.
+
+Device operation
+
+
+With IPU3, once the input video node ("ipu3-imgu 0/1":0,
+in : format) is queued with buffer (in packed raw bayer
+format), IPU3 ISP starts processing the buffer and produces the video output
+in YUV format and statistics output on respective output nodes. The driver
+is expected to have buffers ready for all of parameter, output and
+statistics nodes, when input video node is queued with buffer.
+
+At a minimum, all of input, main output, 3A statistics and viewfinder
+video nodes should be enabled for IPU3 to start image processing.
+
+Each ImgU V4L2 subdev has the following set of video nodes.
+
+input, output and viewfinder video nodes
+
+
+The frames (in packed raw bayer format specific to IPU3) received by the
+input video node is processed by the IPU3 Imaging Unit and is output to 2
+video nodes, with each targeting different purpose (main output and viewfinder
+output).
+
+Details on raw bayer format specific to IPU3 can be found as below.
+Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
+
+The driver supports V4L2 Video Capture Interface as defined at :ref:`devices`.
+
+Only the multi-planar API is supported. More details can be found at
+:ref:`planar-apis`.
+
+
+parameters video node
+-
+
+The parameter video node receives the ISP algorithm parameters that are used
+to configure how the ISP algorithms process the image.
+
+Details on raw bayer format specific to IPU3 can be found as
[PATCH v8 16/17] media: v4l2-ctrls: Reserve controls for IPU3 ImgU
From: "Cao,Bing Bu"
Add a base to be used for allocation of all the IPU3 specific
controls in the ImgU driver.
Signed-off-by: Yong Zhi
Signed-off-by: Tian Shu Qiu
---
include/uapi/linux/v4l2-controls.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 998983a6e6b7..2b52f44d0ba5 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -192,6 +192,10 @@ enum v4l2_colorfx {
* We reserve 16 controls for this driver. */
#define V4L2_CID_USER_IMX_BASE (V4L2_CID_USER_BASE + 0x10b0)
+/* The base for the ipu3 ImgU driver controls.
+ * We reserve 16 controls for this driver. */
+#define V4L2_CID_INTEL_IPU3_BASE (V4L2_CID_USER_BASE + 0x10c0)
+
/* MPEG-class control IDs */
/* The MPEG controls are applicable to all codec controls
* and the 'MPEG' part of the define is historical */
--
2.7.4
Re: [PATCH v5] media: imx: add mem2mem device
Hi Hans,
On 12/6/18 4:32 AM, Hans Verkuil wrote:
On 12/06/18 00:13, Steve Longerbeam wrote:
On 12/5/18 10:50 AM, Hans Verkuil wrote:
On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
Hi Hans, Philipp,
One comment on my side...
On 12/3/18 7:21 AM, Hans Verkuil wrote:
+void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
+{
+ struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
+ struct video_device *vfd = priv->vdev.vfd;
+
+ mutex_lock(>mutex);
+
+ if (video_is_registered(vfd)) {
+ video_unregister_device(vfd);
+ media_entity_cleanup(>entity);
Is this needed?
If this is to be part of the media controller, then I expect to see a call
to v4l2_m2m_register_media_controller() somewhere.
Yes, I agree there should be a call to
v4l2_m2m_register_media_controller(). This driver does not connect with
any of the imx-media entities, but calling it will at least make the
mem2mem output/capture device entities (and processing entity) visible
in the media graph.
Philipp, can you pick/squash the following from my media-tree github fork?
6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
device")
6787a50cdc ("media: imx: mem2mem: Register with media control")
Steve
Why is this driver part of the imx driver? Since it doesn't connect with
any of the imx-media entities, doesn't that mean that this is really a
stand-alone driver?
It is basically a stand-alone m2m driver, but it makes use of some
imx-media utility functions like imx_media_enum_format(). Also making it
a true stand-alone driver would require creating a second /dev/mediaN
device.
If it is standalone, is it reused in newer iMX versions? (7 or 8)
No, this driver makes use of the Image Converter in IPUv3, so it will
only run on iMX 5/6. The IPU has been dropped in iMX 7 and 8.
And if it is just a regular m2m device, then it doesn't need to create a
media device either (doesn't hurt, but it is not required).
Ok, I'll leave that up to Philipp. I don't mind either way whether it is
folded into imx-media device, or whether it is made stand-alone with or
without a new media device.
Steve
Re: [PATCH v2] media: rockchip vpu: remove some unused vars
On Wed, 2018-12-05 at 19:01 -0500, Mauro Carvalho Chehab wrote:
> As complained by gcc:
>
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c: In
> function 'rk3288_vpu_jpeg_enc_set_qtable':
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10:
> warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *chroma_qtable_p;
> ^~~
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10:
> warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *luma_qtable_p;
> ^
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c: In
> function 'rk3399_vpu_jpeg_enc_set_qtable':
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10:
> warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *chroma_qtable_p;
> ^~~
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10:
> warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *luma_qtable_p;
> ^
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
> 'rockchip_vpu_queue_setup':
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:522:33: warning:
> variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
> const struct rockchip_vpu_fmt *vpu_fmt;
>^~~
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
> 'rockchip_vpu_buf_prepare':
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:560:33: warning:
> variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
> const struct rockchip_vpu_fmt *vpu_fmt;
>^~~
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Ezequiel Garcia
Thanks!
> ---
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 5 -
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c | 6 --
> 3 files changed, 16 deletions(-)
>
> diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> index e27c10855de5..5282236d1bb1 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> @@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev
> *vpu,
> unsigned char *luma_qtable,
> unsigned char *chroma_qtable)
> {
> - __be32 *luma_qtable_p;
> - __be32 *chroma_qtable_p;
> u32 reg, i;
>
> - luma_qtable_p = (__be32 *)luma_qtable;
> - chroma_qtable_p = (__be32 *)chroma_qtable;
> -
> for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
> reg = get_unaligned_be32(_qtable[i]);
> vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
> diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> index 5f75e4d11d76..dbc86d95fe3b 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> @@ -97,13 +97,8 @@ rk3399_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev
> *vpu,
> unsigned char *luma_qtable,
> unsigned char *chroma_qtable)
> {
> - __be32 *luma_qtable_p;
> - __be32 *chroma_qtable_p;
> u32 reg, i;
>
> - luma_qtable_p = (__be32 *)luma_qtable;
> - chroma_qtable_p = (__be32 *)chroma_qtable;
> -
> for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
> reg = get_unaligned_be32(_qtable[i]);
> vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
> diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> index 038a7136d5d1..ab0fb2053620 100644
> --- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> @@ -519,17 +519,14 @@ rockchip_vpu_queue_setup(struct vb2_queue *vq,
>struct device *alloc_devs[])
> {
> struct rockchip_vpu_ctx *ctx = vb2_get_drv_priv(vq);
> - const struct rockchip_vpu_fmt *vpu_fmt;
> struct v4l2_pix_format_mplane *pixfmt;
> int i;
>
> switch (vq->type) {
> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> - vpu_fmt = ctx->vpu_dst_fmt;
> pixfmt = >dst_fmt;
> break;
> case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> - vpu_fmt = ctx->vpu_src_fmt;
> pixfmt =
[GIT PULL FOR v4.21] Two DVB patches
Hi Mauro, Two small dvb fixes which would be nice to have in 4.21. Thanks, Sean The following changes since commit 3c28b91380dd1183347d32d87d820818031ebecf: media: stkwebcam: Bugfix for wrong return values (2018-12-05 14:10:48 -0500) are available in the Git repository at: git://linuxtv.org/syoung/media_tree.git for-v4.21d for you to fetch changes up to 92ca069d61c96701c8660c114bbf8b772b4a33db: media: lmedm04: Move interrupt buffer to priv buffer. (2018-12-06 20:15:14 +) Malcolm Priestley (2): media: lmedm04: Add missing usb_free_urb to free interrupt urb. media: lmedm04: Move interrupt buffer to priv buffer. drivers/media/usb/dvb-usb-v2/lmedm04.c | 29 ++--- 1 file changed, 10 insertions(+), 19 deletions(-)
[PATCH v3] v4l2-ioctl: Zero v4l2_plane_pix_format reserved fields
Make the core set the reserved fields to zero in
vv4l2_pix_format_mplane.4l2_plane_pix_format,
for _MPLANE queue types.
Moving this to the core avoids having to do so in each
and every driver.
Suggested-by: Tomasz Figa
Signed-off-by: Ezequiel Garcia
Acked-by: Sakari Ailus
--
v3:
* s/int/unsigned int, suggested by Sakari
v2:
* Drop unneeded clear in g_fmt.
The sturct was already being cleared here.
* Only zero plane_fmt reserved fields.
* Use CLEAR_FIELD_MACRO.
drivers/media/v4l2-core/v4l2-ioctl.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index e384142d2826..7e8e7915c041 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1512,6 +1512,7 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
struct v4l2_format *p = arg;
struct video_device *vfd = video_devdata(file);
int ret = check_fmt(file, p->type);
+ unsigned int i;
if (ret)
return ret;
@@ -1536,6 +1537,8 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_s_fmt_vid_cap_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
if (unlikely(!ops->vidioc_s_fmt_vid_overlay))
@@ -1564,6 +1567,8 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_s_fmt_vid_out_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_s_fmt_vid_out_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
if (unlikely(!ops->vidioc_s_fmt_vid_out_overlay))
@@ -1604,6 +1609,7 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
{
struct v4l2_format *p = arg;
int ret = check_fmt(file, p->type);
+ unsigned int i;
if (ret)
return ret;
@@ -1623,6 +1629,8 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_try_fmt_vid_cap_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_try_fmt_vid_cap_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
if (unlikely(!ops->vidioc_try_fmt_vid_overlay))
@@ -1651,6 +1659,8 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_try_fmt_vid_out_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_try_fmt_vid_out_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
if (unlikely(!ops->vidioc_try_fmt_vid_out_overlay))
--
2.20.0.rc1
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Em Thu, 6 Dec 2018 17:07:52 -0200
Mauro Carvalho Chehab escreveu:
> Em Thu, 6 Dec 2018 13:36:24 -0500
> Alex Deucher escreveu:
>
> > On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab
> > wrote:
> > >
> > > Em Thu, 06 Dec 2018 18:18:23 +0100
> > > Markus Dobel escreveu:
> > >
> > > > Hi everyone,
> > > >
> > > > I will try if the hack mentioned fixes the issue for me on the weekend
> > > > (but I assume, as if effectively removes the function).
> > >
> > > It should, but it keeps a few changes. Just want to be sure that what
> > > would be left won't cause issues. If this works, the logic that would
> > > solve Ryzen DMA fixes will be contained into a single point, making
> > > easier to maintain it.
> > >
> > > >
> > > > Just in case this is of interest, I neither have Ryzen nor Intel, but
> > > > an HP Microserver G7 with an AMD Turion II Neo N54L, so the machine is
> > > > more on the slow side.
> > >
> > > Good to know. It would probably worth to check if this Ryzen
> > > bug occors with all versions of it or with just a subset.
> > > I mean: maybe it is only at the first gen or Ryzen and doesn't
> > > affect Ryzen 2 (or vice versa).
> >
> > The original commit also mentions some Xeons are affected too. Seems
> > like this is potentially an issue on the device side rather than the
> > platform.
>
> Maybe.
>
> > >
> > > The PCI quirks logic will likely need to detect the PCI ID of
> > > the memory controllers found at the buggy CPUs, in order to enable
> > > the quirk only for the affected ones.
> > >
> > > It could be worth talking with AMD people in order to be sure about
> > > the differences at the DMA engine side.
> > >
> >
> > It's not clear to me what the pci or platform quirk would do. The
> > workaround seems to be in the driver, not on the platform.
>
> Yeah, the fix should be at the driver, but pci/quirk.c would be able
> to detect memory controllers that would require a hack inside the
> driver, in a similar way to what the media PCI drivers already do
> for DMA controllers that don't support pci2pci transfers.
>
> There, basically the PCI core (drivers/pci/pci.c and
> drivers/pci/quirks.c) sets a flag (pci_pci_problems) indicating
> potential issues.
>
> Then, the driver compares such flag in order to enable the specific quirk.
>
> Ok, there would be a different way to handle it. The driver could use a
> logic similar to the one I wrote for drivers/edac/i7core_edac.c. There,
> the logic seeks for some specific PCI device IDs using pci_get_device(),
> adjusting the code accordingly, depending on the detected PCI devices.
>
> In other words, running something like this (untested), at probe time should
> produce similar results:
>
> /*
>* FIXME: It probably makes sense to also be able to identify specific
>* versions of the same PCI ID, just in case a latter stepping got a
>* fix for the issue.
>*/
> const static struct {
> int vendor, dev;
> } broken_dev_id[] = {
> PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_foo,
> PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_bar,
> },
>
> bool cx23885_does_dma_require_reset(void)
> {
> int i;
> struct pci_dev *pdev = NULL;
>
> for (i = 0; i < sizeof(broken_dev_id); i++) {
> pdev = pci_get_device(broken_dev_id[i].vendor,
> broken_dev_id[i].dev, NULL);
> if (pdev) {
> pci_put_device(pdev);
> return true;
> }
> }
> return false;
> }
>
> Should work. In any case, we need to know what memory controllers
> have problems, and what are their PCI IDs, and add them (if not there yet)
> at include/linux/pci_ids.h
>
> Thanks,
> Mauro
To be clearer, I'm thinking on something like the (untested)
code below (untested).
PS.: the PCI ID used there may be wrong. I just added one in
order to have a proof of concept.
Thanks,
Mauro
[PATCH] media: cx23885: only reset DMA on problematic CPUs
It is reported that changeset 95f408bbc4e4 ("media: cx23885:
Ryzen DMA related RiSC engine stall fixes") caused regresssions
with other CPUs.
Ensure that the quirk will be applied only for the CPUs that
are known to cause problems.
Fixes: 95f408bbc4e4 ("media: cx23885: Ryzen DMA related RiSC engine stall
fixes")
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/pci/cx23885/cx23885-core.c
b/drivers/media/pci/cx23885/cx23885-core.c
index 39804d830305..48da7d194cc1 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -603,8 +604,13 @@ static void cx23885_risc_disasm(struct cx23885_tsport
*port,
static void cx23885_clear_bridge_error(struct cx23885_dev *dev)
{
- uint32_t
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Em Thu, 6 Dec 2018 13:36:24 -0500
Alex Deucher escreveu:
> On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab
> wrote:
> >
> > Em Thu, 06 Dec 2018 18:18:23 +0100
> > Markus Dobel escreveu:
> >
> > > Hi everyone,
> > >
> > > I will try if the hack mentioned fixes the issue for me on the weekend
> > > (but I assume, as if effectively removes the function).
> >
> > It should, but it keeps a few changes. Just want to be sure that what
> > would be left won't cause issues. If this works, the logic that would
> > solve Ryzen DMA fixes will be contained into a single point, making
> > easier to maintain it.
> >
> > >
> > > Just in case this is of interest, I neither have Ryzen nor Intel, but an
> > > HP Microserver G7 with an AMD Turion II Neo N54L, so the machine is more
> > > on the slow side.
> >
> > Good to know. It would probably worth to check if this Ryzen
> > bug occors with all versions of it or with just a subset.
> > I mean: maybe it is only at the first gen or Ryzen and doesn't
> > affect Ryzen 2 (or vice versa).
>
> The original commit also mentions some Xeons are affected too. Seems
> like this is potentially an issue on the device side rather than the
> platform.
Maybe.
> >
> > The PCI quirks logic will likely need to detect the PCI ID of
> > the memory controllers found at the buggy CPUs, in order to enable
> > the quirk only for the affected ones.
> >
> > It could be worth talking with AMD people in order to be sure about
> > the differences at the DMA engine side.
> >
>
> It's not clear to me what the pci or platform quirk would do. The
> workaround seems to be in the driver, not on the platform.
Yeah, the fix should be at the driver, but pci/quirk.c would be able
to detect memory controllers that would require a hack inside the
driver, in a similar way to what the media PCI drivers already do
for DMA controllers that don't support pci2pci transfers.
There, basically the PCI core (drivers/pci/pci.c and
drivers/pci/quirks.c) sets a flag (pci_pci_problems) indicating
potential issues.
Then, the driver compares such flag in order to enable the specific quirk.
Ok, there would be a different way to handle it. The driver could use a
logic similar to the one I wrote for drivers/edac/i7core_edac.c. There,
the logic seeks for some specific PCI device IDs using pci_get_device(),
adjusting the code accordingly, depending on the detected PCI devices.
In other words, running something like this (untested), at probe time should
produce similar results:
/*
* FIXME: It probably makes sense to also be able to identify specific
* versions of the same PCI ID, just in case a latter stepping got a
* fix for the issue.
*/
const static struct {
int vendor, dev;
} broken_dev_id[] = {
PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_foo,
PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_bar,
},
bool cx23885_does_dma_require_reset(void)
{
int i;
struct pci_dev *pdev = NULL;
for (i = 0; i < sizeof(broken_dev_id); i++) {
pdev = pci_get_device(broken_dev_id[i].vendor,
broken_dev_id[i].dev, NULL);
if (pdev) {
pci_put_device(pdev);
return true;
}
}
return false;
}
Should work. In any case, we need to know what memory controllers
have problems, and what are their PCI IDs, and add them (if not there yet)
at include/linux/pci_ids.h
Thanks,
Mauro
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab wrote: > > Em Thu, 06 Dec 2018 18:18:23 +0100 > Markus Dobel escreveu: > > > Hi everyone, > > > > I will try if the hack mentioned fixes the issue for me on the weekend (but > > I assume, as if effectively removes the function). > > It should, but it keeps a few changes. Just want to be sure that what > would be left won't cause issues. If this works, the logic that would > solve Ryzen DMA fixes will be contained into a single point, making > easier to maintain it. > > > > > Just in case this is of interest, I neither have Ryzen nor Intel, but an HP > > Microserver G7 with an AMD Turion II Neo N54L, so the machine is more on > > the slow side. > > Good to know. It would probably worth to check if this Ryzen > bug occors with all versions of it or with just a subset. > I mean: maybe it is only at the first gen or Ryzen and doesn't > affect Ryzen 2 (or vice versa). The original commit also mentions some Xeons are affected too. Seems like this is potentially an issue on the device side rather than the platform. > > The PCI quirks logic will likely need to detect the PCI ID of > the memory controllers found at the buggy CPUs, in order to enable > the quirk only for the affected ones. > > It could be worth talking with AMD people in order to be sure about > the differences at the DMA engine side. > It's not clear to me what the pci or platform quirk would do. The workaround seems to be in the driver, not on the platform. Alex
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Em Thu, 06 Dec 2018 18:18:23 +0100 Markus Dobel escreveu: > Hi everyone, > > I will try if the hack mentioned fixes the issue for me on the weekend (but I > assume, as if effectively removes the function). It should, but it keeps a few changes. Just want to be sure that what would be left won't cause issues. If this works, the logic that would solve Ryzen DMA fixes will be contained into a single point, making easier to maintain it. > > Just in case this is of interest, I neither have Ryzen nor Intel, but an HP > Microserver G7 with an AMD Turion II Neo N54L, so the machine is more on the > slow side. Good to know. It would probably worth to check if this Ryzen bug occors with all versions of it or with just a subset. I mean: maybe it is only at the first gen or Ryzen and doesn't affect Ryzen 2 (or vice versa). The PCI quirks logic will likely need to detect the PCI ID of the memory controllers found at the buggy CPUs, in order to enable the quirk only for the affected ones. It could be worth talking with AMD people in order to be sure about the differences at the DMA engine side. Thanks, Mauro
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Hi everyone, I will try if the hack mentioned fixes the issue for me on the weekend (but I assume, as if effectively removes the function). Just in case this is of interest, I neither have Ryzen nor Intel, but an HP Microserver G7 with an AMD Turion II Neo N54L, so the machine is more on the slow side. Regards, Markus -- Gesendet mit zwei Streichhölzern, einem Gummiband und etwas Draht.
Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes
Hi Mauro & Markus,
On 05/12/2018 05.07, Mauro Carvalho Chehab wrote:
> Em Sun, 21 Oct 2018 15:45:39 +0200
> Markus Dobel escreveu:
>
>> The original commit (the one reverted in this patch) introduced a
>> regression,
>> making a previously flawless adapter unresponsive after running a few
>> hours
>> to days. Since I never experienced the problems that the original commit
>> is
>> supposed to fix, I propose to revert the change until a regression-free
>> variant is found.
>>
>> Before submitting this, I've been running a system 24x7 with this revert
>> for
>> several weeks now, and it's running stable again.
>>
>> It's not a pure revert, as the original commit does not revert cleanly
>> anymore due to other changes, but content-wise it is.
>>
>> Signed-off-by: Markus Dobel
>> ---
>> drivers/media/pci/cx23885/cx23885-core.c | 60
>> drivers/media/pci/cx23885/cx23885-reg.h | 14 --
>> 2 files changed, 74 deletions(-)
>>
>> diff --git a/drivers/media/pci/cx23885/cx23885-core.c
>> b/drivers/media/pci/cx23885/cx23885-core.c
>> index 39804d830305..606f6fc0e68b 100644
>> --- a/drivers/media/pci/cx23885/cx23885-core.c
>> +++ b/drivers/media/pci/cx23885/cx23885-core.c
>> @@ -601,25 +601,6 @@ static void cx23885_risc_disasm(struct
>> cx23885_tsport *port,
> Patch was mangled by your e-mailer: it broke longer lines, causing
> it to not apply.
>
> Also, before just reverting the entire thing, could you please check
> if the enclosed hack would solve it?
>
> If so, it should be easy to add a quirk at drivers/pci/quirks.c
> in order to detect the Ryzen models with a bad DMA engine that
> require periodic resets, and then make cx23885 to use it.
>
> We did similar tricks before with some broken DMA engines, at
> the time we had overlay support on drivers and AMD controllers
> didn't support PCI2PCI DMA transfers.
>
> Brad,
>
> Could you please address this issue?
I'll try to address this today or tomorrow. Since the original patch was
applied I have not received any complaints from ryzen users, but we have
accumulated a few reports from Intel users with a variety of
motherboards that do now encounter issue. Strangely system load affects
the repro; low/no load exhibits the error condition, high system load
everything is fine. I'll do my best to send in a ryzen specific patch by
the weekend.
Regards,
Brad
>
>
> diff --git a/drivers/media/pci/cx23885/cx23885-core.c
> b/drivers/media/pci/cx23885/cx23885-core.c
> index 39804d830305..8b012bee6b32 100644
> --- a/drivers/media/pci/cx23885/cx23885-core.c
> +++ b/drivers/media/pci/cx23885/cx23885-core.c
> @@ -603,8 +603,14 @@ static void cx23885_risc_disasm(struct cx23885_tsport
> *port,
>
> static void cx23885_clear_bridge_error(struct cx23885_dev *dev)
> {
> - uint32_t reg1_val = cx_read(TC_REQ); /* read-only */
> - uint32_t reg2_val = cx_read(TC_REQ_SET);
> + uint32_t reg1_val, reg2_val;
> +
> + /* TODO: check for Ryzen quirk */
> + if (1)
> + return;
> +
> + reg1_val = cx_read(TC_REQ); /* read-only */
> + reg2_val = cx_read(TC_REQ_SET);
>
> if (reg1_val && reg2_val) {
> cx_write(TC_REQ, reg1_val);
>
>
>
> Thanks,
> Mauro
Re: [PATCH v6 00/12] media: ov5640: Misc cleanup and improvements
On Mon, Dec 3, 2018 at 2:14 PM Maxime Ripard wrote: > > Hi, > > Here is a "small" series that mostly cleans up the ov5640 driver code, > slowly getting rid of the big data array for more understandable code > (hopefully). > > The biggest addition would be the clock rate computation at runtime, > instead of relying on those arrays to setup the clock tree > properly. As a side effect, it fixes the framerate that was off by > around 10% on the smaller resolutions, and we now support 60fps. > > This also introduces a bunch of new features. > > Let me know what you think, > Maxime > > Changes from v5: > - Squashed Jacopo patches fixing MIPI-CSI > > Changes from v4: > - Squashed Jacopo patches fixing the MIPI-CSI case > - Prefer clock rates superior to the ideal clock rate, even if it > means having a less precise one. > - Fix the JPEG case according to Hugues suggestions > - Rebased on 4.20 > > Changes from v3: > - Rebased on current Sakari tree > - Fixed an error when changing only the framerate > > Changes from v2: > - Rebased on latest Sakari PR > - Fixed the issues reported by Hugues: improper FPS returned for > formats, improper rounding of the FPS, some with his suggestions, > some by simplifying the logic. > - Expanded the clock tree comments based on the feedback from Samuel > Bobrowicz and Loic Poulain > - Merged some of the changes made by Samuel Bobrowicz to fix the > MIPI rate computation, fix the call sites of the > ov5640_set_timings function, the auto-exposure calculation call, > etc. > - Split the patches into smaller ones in order to make it more > readable (hopefully) > > Changes from v1: > - Integrated Hugues' suggestions to fix v4l2-compliance > - Fixed the bus width with JPEG > - Dropped the clock rate calculation loops for something simpler as > suggested by Sakari > - Cache the exposure value instead of using the control value > - Rebased on top of 4.17 > > Jacopo Mondi (1): > media: ov5640: Fix set format regression > > Maxime Ripard (11): > media: ov5640: Adjust the clock based on the expected rate > media: ov5640: Remove the clocks registers initialization > media: ov5640: Remove redundant defines > media: ov5640: Remove redundant register setup > media: ov5640: Compute the clock rate at runtime > media: ov5640: Remove pixel clock rates > media: ov5640: Enhance FPS handling > media: ov5640: Make the return rate type more explicit > media: ov5640: Make the FPS clamping / rounding more extendable > media: ov5640: Add 60 fps support > media: ov5640: Remove duplicate auto-exposure setup Tested 320x240@30, 640x480@30, 640x480@60, 1280x720@30 with UYVY8_2X8 and YUYV8_2X8 formats. Tested-by: Jagan Teki # a64-amarula-relic
[PATCH] dma-buf: balance refcount inbalance
From: Jérôme Glisse The debugfs take reference on fence without dropping them. Signed-off-by: Jérôme Glisse Cc: Christian König Cc: Daniel Vetter Cc: Sumit Semwal Cc: linux-media@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Cc: Stéphane Marchesin Cc: sta...@vger.kernel.org --- drivers/dma-buf/dma-buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 13884474d158..69842145c223 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1069,6 +1069,7 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused) fence->ops->get_driver_name(fence), fence->ops->get_timeline_name(fence), dma_fence_is_signaled(fence) ? "" : "un"); + dma_fence_put(fence); } rcu_read_unlock(); -- 2.17.2
Invite for IRC meeting: Re: [PATCHv4 01/10] videodev2.h: add tag support
Mauro raised a number of objections on irc regarding tags:
https://linuxtv.org/irc/irclogger_log/media-maint?date=2018-12-06,Thu
I would like to setup an irc meeting to discuss this and come to a
conclusion, since we need to decide this soon since this is critical
for stateless codec support.
Unfortunately timezone-wise this is a bit of a nightmare. I think
that at least Mauro, myself and Tomasz Figa should be there, so UTC-2,
UTC+1 and UTC+9 (if I got that right).
I propose 9 AM UTC which I think will work for everyone except Nicolas.
Any day next week works for me, and (for now) as well for Mauro. Let's pick
Monday to start with, and if you want to join in, then let me know. If that
day doesn't work for you, let me know what other days next week do work for
you.
Regards,
Hans
On 12/05/18 11:20, hverkuil-ci...@xs4all.nl wrote:
> From: Hans Verkuil
>
> Add support for 'tags' to struct v4l2_buffer. These can be used
> by m2m devices so userspace can set a tag for an output buffer and
> this value will then be copied to the capture buffer(s).
>
> This tag can be used to refer to capture buffers, something that
> is needed by stateless HW codecs.
>
> The new V4L2_BUF_CAP_SUPPORTS_TAGS capability indicates whether
> or not tags are supported.
>
> Signed-off-by: Hans Verkuil
> Reviewed-by: Paul Kocialkowski
> Reviewed-by: Alexandre Courbot
> ---
> include/uapi/linux/videodev2.h | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 2db1635de956..9095d7abe10d 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -881,6 +881,7 @@ struct v4l2_requestbuffers {
> #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
> #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
> #define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
> +#define V4L2_BUF_CAP_SUPPORTS_TAGS (1 << 5)
>
> /**
> * struct v4l2_plane - plane info for multi-planar buffers
> @@ -940,6 +941,7 @@ struct v4l2_plane {
> * @length: size in bytes of the buffer (NOT its payload) for single-plane
> * buffers (when type != *_MPLANE); number of elements in the
> * planes array for multi-plane buffers
> + * @tag: buffer tag
> * @request_fd: fd of the request that this buffer should use
> *
> * Contains data exchanged by application and driver using one of the
> Streaming
> @@ -964,7 +966,10 @@ struct v4l2_buffer {
> __s32 fd;
> } m;
> __u32 length;
> - __u32 reserved2;
> + union {
> + __u32 reserved2;
> + __u32 tag;
> + };
> union {
> __s32 request_fd;
> __u32 reserved;
> @@ -990,6 +995,8 @@ struct v4l2_buffer {
> #define V4L2_BUF_FLAG_IN_REQUEST 0x0080
> /* timecode field is valid */
> #define V4L2_BUF_FLAG_TIMECODE 0x0100
> +/* tag field is valid */
> +#define V4L2_BUF_FLAG_TAG0x0200
> /* Buffer is prepared for queuing */
> #define V4L2_BUF_FLAG_PREPARED 0x0400
> /* Cache handling flags */
>
Re: [PATCH] [PATCHv2] Add ir-rcmm-driver
On Wed, Dec 05, 2018 at 01:29:33AM +0100, patrick9...@free.fr wrote:
> From: Patrick LERDA
>
We need a Signed-off-by: here.
https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
> ---
> drivers/media/rc/Kconfig | 10 ++
> drivers/media/rc/Makefile | 1 +
> drivers/media/rc/ir-rcmm-decoder.c | 185 +
> drivers/media/rc/rc-core-priv.h| 5 +
> drivers/media/rc/rc-main.c | 3 +
> include/media/rc-map.h | 6 +-
> include/uapi/linux/lirc.h | 1 +
> tools/include/uapi/linux/lirc.h| 1 +
> 8 files changed, 210 insertions(+), 2 deletions(-)
> create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 1021c08a9ba4..b7e08324b874 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -133,6 +133,16 @@ config IR_IMON_DECODER
> remote control and you would like to use it with a raw IR
> receiver, or if you wish to use an encoder to transmit this IR.
>
> +config IR_RCMM_DECODER
> + tristate "Enable IR raw decoder for the RC-MM protocol"
> + depends on RC_CORE
> + select BITREVERSE
You're not using bitreverse, so don't depend on it.
> + default y
> +
> + ---help---
> +Enable this option if you have IR with RC-MM protocol, and
> +if the IR is decoded in software
> +
> endif #RC_DECODERS
>
> menuconfig RC_DEVICES
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index e0340d043fe8..fc4058013234 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
> obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
> obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
> obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
> +obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
>
> # stand-alone IR receivers/transmitters
> obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
> diff --git a/drivers/media/rc/ir-rcmm-decoder.c
> b/drivers/media/rc/ir-rcmm-decoder.c
> new file mode 100644
> index ..94d5b70f7a0f
> --- /dev/null
> +++ b/drivers/media/rc/ir-rcmm-decoder.c
> @@ -0,0 +1,185 @@
> +/* ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
> + *
> + * Copyright (C) 2016 by Patrick Lerda
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
Replace this with the SPDX-License-Identifier.
> + */
> +
> +#include "rc-core-priv.h"
> +#include
> +#include
> +
> +
> +#define RCMM_UNIT17 /* nanosecs */
> +#define RCMM_0_NBITS 64
Not used.
> +#define RCMM_PREFIX_PULSE41 /* 16.6*2.5 */
> +#define RCMM_PULSE_027 /* 16.6*(1+2/3) */
> +#define RCMM_PULSE_144 /* 16.6*(2+2/3) */
> +#define RCMM_PULSE_261 /* 16.6*(3+2/3) */
> +#define RCMM_PULSE_378 /* 16.6*(4+2/3) */
> +#define RCMM_MODE_MASK 0x
Not used.
> +
> +enum rcmm_state {
> + STATE_INACTIVE,
> + STATE_LOW,
> + STATE_BUMP,
> + STATE_VALUE,
> + STATE_FINISHED,
> +};
> +
> +static bool rcmm_mode(struct rcmm_dec *data)
> +{
> +return !((0x000c & data->bits) == 0x000c);
> +}
> +
> +/**
> + * ir_rcmm_decode() - Decode one RCMM pulse or space
> + * @dev: the struct rc_dev descriptor of the device
> + * @ev: the struct ir_raw_event descriptor of the pulse/space
> + *
> + * This function returns -EINVAL if the pulse violates the state machine
> + */
> +static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event ev)
> +{
> + struct rcmm_dec *data = >raw->rcmm;
> + u32 scancode;
> + u8 toggle;
> +
> + if (!(dev->enabled_protocols & RC_PROTO_BIT_RCMM))
> + return 0;
> +
> + if (!is_timing_event(ev)) {
> + if (ev.reset)
> + data->state = STATE_INACTIVE;
> + return 0;
> + }
> +
> + if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
> + goto out;
> +
> + switch (data->state) {
> +
> + case STATE_INACTIVE:
> + if (!ev.pulse)
> + break;
> +
> + /* Note: larger margin on first pulse since each RCMM_UNIT
> +is quite short and some hardware takes some time to
> +adjust to the signal */
Use:
/*
* Note:
*/
Type multiline comments
Re: [PATCH v11 2/4] ARM: dts: rockchip: add VPU device node for RK3288
Am Freitag, 30. November 2018, 18:34:31 CET schrieb Ezequiel Garcia: > Add the Video Processing Unit node for RK3288 SoC. > > Fix the VPU IOMMU node, which was disabled and lacking > its power domain property. > > Reviewed-by: Tomasz Figa > Signed-off-by: Ezequiel Garcia applied for 4.21 after a tiny bit of reordering Thanks for seeing this through Heiko
Re: [PATCH v11 3/4] arm64: dts: rockchip: add VPU device node for RK3399
Am Freitag, 30. November 2018, 18:34:32 CET schrieb Ezequiel Garcia: > Add the Video Processing Unit node for the RK3399 SoC. > > Also, fix the VPU IOMMU node, which was disabled and lacking > its power domain property. > > Reviewed-by: Tomasz Figa > Signed-off-by: Ezequiel Garcia applied for 4.21 after a tiny bit of reordering Thanks for seeing this through Heiko
Re: [PATCH v5] media: imx: add mem2mem device
On 12/06/18 00:13, Steve Longerbeam wrote:
>
>
> On 12/5/18 10:50 AM, Hans Verkuil wrote:
>> On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
>>> Hi Hans, Philipp,
>>>
>>> One comment on my side...
>>>
>>> On 12/3/18 7:21 AM, Hans Verkuil wrote:
> +void imx_media_mem2mem_device_unregister(struct imx_media_video_dev
> *vdev)
> +{
> + struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
> + struct video_device *vfd = priv->vdev.vfd;
> +
> + mutex_lock(>mutex);
> +
> + if (video_is_registered(vfd)) {
> + video_unregister_device(vfd);
> + media_entity_cleanup(>entity);
Is this needed?
If this is to be part of the media controller, then I expect to see a call
to v4l2_m2m_register_media_controller() somewhere.
>>> Yes, I agree there should be a call to
>>> v4l2_m2m_register_media_controller(). This driver does not connect with
>>> any of the imx-media entities, but calling it will at least make the
>>> mem2mem output/capture device entities (and processing entity) visible
>>> in the media graph.
>>>
>>> Philipp, can you pick/squash the following from my media-tree github fork?
>>>
>>> 6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
>>> d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
>>> device")
>>> 6787a50cdc ("media: imx: mem2mem: Register with media control")
>>>
>>> Steve
>>>
>> Why is this driver part of the imx driver? Since it doesn't connect with
>> any of the imx-media entities, doesn't that mean that this is really a
>> stand-alone driver?
>
> It is basically a stand-alone m2m driver, but it makes use of some
> imx-media utility functions like imx_media_enum_format(). Also making it
> a true stand-alone driver would require creating a second /dev/mediaN
> device.
If it is standalone, is it reused in newer iMX versions? (7 or 8)
And if it is just a regular m2m device, then it doesn't need to create a
media device either (doesn't hurt, but it is not required).
Regards,
Hans
>
> Steve
>
Re: [PATCHv4 00/10] vb2/cedrus: add tag support
(fix copy and paste error in the cover letter) As was discussed here (among other places): https://lkml.org/lkml/2018/10/19/440 using capture queue buffer indices to refer to reference frames is not a good idea. A better idea is to use a 'tag' where the application can assign a u32 tag to an output buffer, which is then copied to the capture buffer(s) derived from the output buffer. It has been suggested that the timestamp can be used for this. But there are a number of reasons why this is a bad idea: 1) the struct timeval is converted to a u64 in vb2. So there can be all sorts of unexpected conversion issues. In particular, the output of ns_to_timeval(timeval_to_ns(tv)) does not necessarily match the input. 2) it gets worse with the y2038 code where userspace either deals with a 32 bit tv_sec value or a 64 bit value. In other words, using timestamp for this is not a good idea. This implementation adds a new tag field in a union with the reserved2 field. The interpretation of that union depends on the flags field, so it still can be used for other things as well. In addition, in the previous patches the tag was in a union with the timecode field (again determined by the flags field), so if we need to cram additional information in this struct we can always put it in a union with the timecode field as well. It worked for the tag, it should work for other things. But we really need to start looking at a struct v4l2_ext_buffer. The first three patches add core tag support, the next two patches document the tag support, then a new helper function is added to v4l2-mem2mem.c to easily copy data from a source to a destination buffer that drivers can use. Next a new supports_tags vb2_queue flag is added to indicate that the driver supports tags. Ideally this should not be necessary, but that would require that all m2m drivers are converted to using the new helper function introduced in the previous patch. That takes more time then I have now. Finally the vim2m, vicodec and cedrus drivers are converted to support tags. I also removed the 'pad' fields from the mpeg2 control structs (it should never been added in the first place) and aligned the structs to a u32 boundary. Note that this might change further (Paul suggested using bitfields). Also note that the cedrus code doesn't set the sequence counter, that's something that should still be added before this driver can be moved out of staging. Note: if no buffer is found for a certain tag, then the dma address is just set to 0. That happened before as well with invalid buffer indices. This should be checked in the driver! Regards, Hans Changes since v3: - use reserved2 for the tag - split the documentation in two: one documenting the tag, one cleaning up the timecode documentation. Changes since v2: - rebased - added Reviewed-by tags - fixed a few remaining references in the documentation to the old v4l2_buffer_tag struct that was used in early versions of this series. Changes since v1: - changed to a u32 tag. Using a 64 bit tag was overly complicated due to the bad layout of the v4l2_buffer struct, and there is no real need for it by applications. Main changes since the RFC: - Added new buffer capability flag - Added m2m helper to copy data between buffers - Added documentation - Added tag logging in v4l2-ioctl.c Hans Verkuil (10): videodev2.h: add tag support vb2: add tag support v4l2-ioctl.c: log v4l2_buffer tag buffer.rst: document the new buffer tag feature. buffer.rst: clean up timecode documentation v4l2-mem2mem: add v4l2_m2m_buf_copy_data helper function vb2: add new supports_tags queue flag vim2m: add tag support vicodec: add tag support cedrus: add tag support Documentation/media/uapi/v4l/buffer.rst | 28 + .../media/uapi/v4l/vidioc-reqbufs.rst | 4 ++ .../media/common/videobuf2/videobuf2-v4l2.c | 41 --- drivers/media/platform/vicodec/vicodec-core.c | 14 ++- drivers/media/platform/vim2m.c| 14 ++- drivers/media/v4l2-core/v4l2-ctrls.c | 9 drivers/media/v4l2-core/v4l2-ioctl.c | 9 ++-- drivers/media/v4l2-core/v4l2-mem2mem.c| 23 +++ drivers/staging/media/sunxi/cedrus/cedrus.h | 9 ++-- .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 + .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 21 -- .../staging/media/sunxi/cedrus/cedrus_video.c | 2 + include/media/v4l2-mem2mem.h | 21 ++ include/media/videobuf2-core.h| 2 + include/media/videobuf2-v4l2.h| 21 +- include/uapi/linux/v4l2-controls.h| 14 +++ include/uapi/linux/videodev2.h| 9 +++- 17 files changed, 168 insertions(+), 75 deletions(-) -- 2.19.1
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: Thu Dec 6 05:00:13 CET 2018 media-tree git hash:3c28b91380dd1183347d32d87d820818031ebecf media_build git hash: 4b9237c73e29ea969f6a7b3d00030e14be50 v4l-utils git hash: 9f0354c3320f3cc62983f726bfed66e1d0c21f83 edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: ERRORS linux-3.10.108-x86_64: ERRORS linux-3.11.10-i686: ERRORS linux-3.11.10-x86_64: ERRORS linux-3.12.74-i686: ERRORS linux-3.12.74-x86_64: ERRORS linux-3.13.11-i686: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.79-i686: ERRORS linux-3.14.79-x86_64: ERRORS linux-3.15.10-i686: ERRORS linux-3.15.10-x86_64: ERRORS linux-3.16.57-i686: ERRORS linux-3.16.57-x86_64: ERRORS linux-3.17.8-i686: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.123-i686: ERRORS linux-3.18.123-x86_64: ERRORS linux-3.19.8-i686: ERRORS linux-3.19.8-x86_64: ERRORS linux-4.0.9-i686: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.52-i686: ERRORS linux-4.1.52-x86_64: ERRORS linux-4.2.8-i686: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-i686: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.159-i686: ERRORS linux-4.4.159-x86_64: ERRORS linux-4.5.7-i686: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-i686: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.10-i686: ERRORS linux-4.7.10-x86_64: ERRORS linux-4.8.17-i686: ERRORS linux-4.8.17-x86_64: ERRORS linux-4.9.131-i686: ERRORS linux-4.9.131-x86_64: ERRORS linux-4.10.17-i686: ERRORS linux-4.10.17-x86_64: ERRORS linux-4.11.12-i686: ERRORS linux-4.11.12-x86_64: ERRORS linux-4.12.14-i686: ERRORS linux-4.12.14-x86_64: ERRORS linux-4.13.16-i686: ERRORS linux-4.13.16-x86_64: ERRORS linux-4.14.74-i686: ERRORS linux-4.14.74-x86_64: ERRORS linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19.1-i686: OK linux-4.19.1-x86_64: OK linux-4.20-rc1-i686: OK linux-4.20-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
[PATCH v2] media: rockchip vpu: remove some unused vars
As complained by gcc:
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c: In
function 'rk3288_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10:
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *chroma_qtable_p;
^~~
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10:
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *luma_qtable_p;
^
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c: In
function 'rk3399_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10:
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *chroma_qtable_p;
^~~
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10:
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *luma_qtable_p;
^
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
'rockchip_vpu_queue_setup':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:522:33: warning:
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
const struct rockchip_vpu_fmt *vpu_fmt;
^~~
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
'rockchip_vpu_buf_prepare':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:560:33: warning:
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
const struct rockchip_vpu_fmt *vpu_fmt;
^~~
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 5 -
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c | 6 --
3 files changed, 16 deletions(-)
diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
index e27c10855de5..5282236d1bb1 100644
--- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
@@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
unsigned char *luma_qtable,
unsigned char *chroma_qtable)
{
- __be32 *luma_qtable_p;
- __be32 *chroma_qtable_p;
u32 reg, i;
- luma_qtable_p = (__be32 *)luma_qtable;
- chroma_qtable_p = (__be32 *)chroma_qtable;
-
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
index 5f75e4d11d76..dbc86d95fe3b 100644
--- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
@@ -97,13 +97,8 @@ rk3399_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
unsigned char *luma_qtable,
unsigned char *chroma_qtable)
{
- __be32 *luma_qtable_p;
- __be32 *chroma_qtable_p;
u32 reg, i;
- luma_qtable_p = (__be32 *)luma_qtable;
- chroma_qtable_p = (__be32 *)chroma_qtable;
-
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
index 038a7136d5d1..ab0fb2053620 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
@@ -519,17 +519,14 @@ rockchip_vpu_queue_setup(struct vb2_queue *vq,
struct device *alloc_devs[])
{
struct rockchip_vpu_ctx *ctx = vb2_get_drv_priv(vq);
- const struct rockchip_vpu_fmt *vpu_fmt;
struct v4l2_pix_format_mplane *pixfmt;
int i;
switch (vq->type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
- vpu_fmt = ctx->vpu_dst_fmt;
pixfmt = >dst_fmt;
break;
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
- vpu_fmt = ctx->vpu_src_fmt;
pixfmt = >src_fmt;
break;
default:
@@ -557,7 +554,6 @@ static int rockchip_vpu_buf_prepare(struct vb2_buffer *vb)
struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
struct
[PATCH] media: rockchip vpu: remove some unused vars
As complained by gcc:
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c: In
function 'rk3288_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10:
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *chroma_qtable_p;
^~~
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10:
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *luma_qtable_p;
^
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c: In
function 'rk3399_vpu_jpeg_enc_set_qtable':
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10:
warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *chroma_qtable_p;
^~~
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10:
warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
__be32 *luma_qtable_p;
^
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
'rockchip_vpu_queue_setup':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:522:33: warning:
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
const struct rockchip_vpu_fmt *vpu_fmt;
^~~
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
'rockchip_vpu_buf_prepare':
drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:560:33: warning:
variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
const struct rockchip_vpu_fmt *vpu_fmt;
^~~
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
index e27c10855de5..5282236d1bb1 100644
--- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
@@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
unsigned char *luma_qtable,
unsigned char *chroma_qtable)
{
- __be32 *luma_qtable_p;
- __be32 *chroma_qtable_p;
u32 reg, i;
- luma_qtable_p = (__be32 *)luma_qtable;
- chroma_qtable_p = (__be32 *)chroma_qtable;
-
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
--
2.19.1
Re: [PATCH v5] media: imx: add mem2mem device
On 12/5/18 10:50 AM, Hans Verkuil wrote:
On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
Hi Hans, Philipp,
One comment on my side...
On 12/3/18 7:21 AM, Hans Verkuil wrote:
+void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
+{
+ struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
+ struct video_device *vfd = priv->vdev.vfd;
+
+ mutex_lock(>mutex);
+
+ if (video_is_registered(vfd)) {
+ video_unregister_device(vfd);
+ media_entity_cleanup(>entity);
Is this needed?
If this is to be part of the media controller, then I expect to see a call
to v4l2_m2m_register_media_controller() somewhere.
Yes, I agree there should be a call to
v4l2_m2m_register_media_controller(). This driver does not connect with
any of the imx-media entities, but calling it will at least make the
mem2mem output/capture device entities (and processing entity) visible
in the media graph.
Philipp, can you pick/squash the following from my media-tree github fork?
6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
device")
6787a50cdc ("media: imx: mem2mem: Register with media control")
Steve
Why is this driver part of the imx driver? Since it doesn't connect with
any of the imx-media entities, doesn't that mean that this is really a
stand-alone driver?
It is basically a stand-alone m2m driver, but it makes use of some
imx-media utility functions like imx_media_enum_format(). Also making it
a true stand-alone driver would require creating a second /dev/mediaN
device.
Steve
Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
Em Wed, 05 Dec 2018 17:02:46 -0300
Ezequiel Garcia escreveu:
> On Wed, 2018-12-05 at 16:37 -0200, Mauro Carvalho Chehab wrote:
> > Em Wed, 5 Dec 2018 16:34:04 -0200
> > Mauro Carvalho Chehab escreveu:
> >
> > > Em Wed, 5 Dec 2018 17:29:38 +0100
> > > Hans Verkuil escreveu:
> > >
> > > > Note regarding the first 'Revert' patch: that is this patch:
> > > >
> > > > https://patchwork.linuxtv.org/patch/52869/
> > > >
> > > > It is currently pending for 4.20 as a fix, but since it is not merged
> > > > upstream
> > > > yet, our master branch still has those old bindings.
> > > >
> > > > I decided to first apply the Revert patch, then add the new patch on
> > > > top.
> > > >
> > > > Regards,
> > > >
> > > > Hans
> > > >
> > > > The following changes since commit
> > > > da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> > > >
> > > > media: v4l2: async: remove locking when initializing async notifier
> > > > (2018-12-05 06:51:28 -0500)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > > git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> > > >
> > > > for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> > > >
> > > > media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46
> > > > +0100)
> > > >
> > > >
> > > > Tag branch
> > > >
> > > >
> > > > Ezequiel Garcia (3):
> > > > Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> > > > media: dt-bindings: Document the Rockchip VPU bindings
> > > > media: add Rockchip VPU JPEG encoder driver
> > >
> > > Checkpatch produces a few warnings:
> > >
> > > # CHECK: Alignment should match open parenthesis
> > > # #385: FILE:
> > > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
> > > # + rk3288_vpu_jpeg_enc_set_qtable(vpu,
> > > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > > #
> > > # CHECK: Alignment should match open parenthesis
> > > # #1124: FILE:
> > > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
> > > # + rk3399_vpu_jpeg_enc_set_qtable(vpu,
> > > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > > #
> > > # WARNING: DT compatible string "rockchip,rk3399-vpu" appears
> > > un-documented -- check ./Documentation/devicetree/bindings/
> > > # #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
> > > # + { .compatible = "rockchip,rk3399-vpu", .data =
> > > _vpu_variant, },
> > > #
> > > # WARNING: DT compatible string "rockchip,rk3288-vpu" appears
> > > un-documented -- check ./Documentation/devicetree/bindings/
> > > # #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
> > > # + { .compatible = "rockchip,rk3288-vpu", .data =
> > > _vpu_variant, },
> > > #
> > > # CHECK: Unnecessary parentheses around 'formats[i].codec_mode !=
> > > RK_VPU_MODE_NONE'
> > > # #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
> > > # + if (bitstream == (formats[i].codec_mode !=
> > > RK_VPU_MODE_NONE))
> > > #
> > > # total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
> > >
>
> Please note that this last one is a false positive,
> the code needs those parenthesis.
Yes, I know. that "Unnecessary parentheses" warning should always be
taken with caution.
I've seen several cases where it was right, but, for the sake of a
better code readability, it was better to preserve it.
Thanks,
Mauro
Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
On Wed, 2018-12-05 at 16:37 -0200, Mauro Carvalho Chehab wrote:
> Em Wed, 5 Dec 2018 16:34:04 -0200
> Mauro Carvalho Chehab escreveu:
>
> > Em Wed, 5 Dec 2018 17:29:38 +0100
> > Hans Verkuil escreveu:
> >
> > > Note regarding the first 'Revert' patch: that is this patch:
> > >
> > > https://patchwork.linuxtv.org/patch/52869/
> > >
> > > It is currently pending for 4.20 as a fix, but since it is not merged
> > > upstream
> > > yet, our master branch still has those old bindings.
> > >
> > > I decided to first apply the Revert patch, then add the new patch on top.
> > >
> > > Regards,
> > >
> > > Hans
> > >
> > > The following changes since commit
> > > da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> > >
> > > media: v4l2: async: remove locking when initializing async notifier
> > > (2018-12-05 06:51:28 -0500)
> > >
> > > are available in the Git repository at:
> > >
> > > git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> > >
> > > for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> > >
> > > media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100)
> > >
> > >
> > > Tag branch
> > >
> > >
> > > Ezequiel Garcia (3):
> > > Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> > > media: dt-bindings: Document the Rockchip VPU bindings
> > > media: add Rockchip VPU JPEG encoder driver
> >
> > Checkpatch produces a few warnings:
> >
> > # CHECK: Alignment should match open parenthesis
> > # #385: FILE:
> > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
> > # + rk3288_vpu_jpeg_enc_set_qtable(vpu,
> > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > #
> > # CHECK: Alignment should match open parenthesis
> > # #1124: FILE:
> > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
> > # + rk3399_vpu_jpeg_enc_set_qtable(vpu,
> > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > #
> > # WARNING: DT compatible string "rockchip,rk3399-vpu" appears un-documented
> > -- check ./Documentation/devicetree/bindings/
> > # #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
> > # + { .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, },
> > #
> > # WARNING: DT compatible string "rockchip,rk3288-vpu" appears un-documented
> > -- check ./Documentation/devicetree/bindings/
> > # #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
> > # + { .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, },
> > #
> > # CHECK: Unnecessary parentheses around 'formats[i].codec_mode !=
> > RK_VPU_MODE_NONE'
> > # #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
> > # + if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
> > #
> > # total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
> >
Please note that this last one is a false positive,
the code needs those parenthesis.
Thanks!
Ezequiel
Re: [PATCH] media: rockchip/vpu: fix a few alignments
Em Wed, 5 Dec 2018 19:48:25 +0100 Hans Verkuil escreveu: > On 12/05/2018 07:43 PM, Mauro Carvalho Chehab wrote: > > As reported by checkpatch.pl, some function calls have a wrong > > alignment. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 4 ++-- > > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 4 ++-- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > index 8919151e1631..e27c10855de5 100644 > > --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > @@ -106,8 +106,8 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx > > *ctx) > > rk3288_vpu_set_src_img_ctrl(vpu, ctx); > > rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); > > rk3288_vpu_jpeg_enc_set_qtable(vpu, > > - rockchip_vpu_jpeg_get_qtable(_ctx, 0), > > - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 0), > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 1)); > > But now you get warnings because this is > 80 columns. > > I think the 'cure' is worse than the disease. > > I see this is already merged, but I don't think this patch improves > readability, > which is more important than a checkpatch warning IMHO. IMHO, it is a way more readable if things got aligned. Very very few people nowadays (if any) write patches directly at a 80 columns console. Btw, speaking about 80 cols, usually your commit messages are longer than that (the limit is actually 80 cols - 4). I keep fixing the corresponding checkpatch.pl warnings from your patches (when I have time) :-) > > Regards, > > Hans > > > > > reg = VEPU_REG_AXI_CTRL_OUTPUT_SWAP16 > > | VEPU_REG_AXI_CTRL_INPUT_SWAP16 > > diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > index 8afa2162bf9f..5f75e4d11d76 100644 > > --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > @@ -137,8 +137,8 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx > > *ctx) > > rk3399_vpu_set_src_img_ctrl(vpu, ctx); > > rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf); > > rk3399_vpu_jpeg_enc_set_qtable(vpu, > > - rockchip_vpu_jpeg_get_qtable(_ctx, 0), > > - rockchip_vpu_jpeg_get_qtable(_ctx, 1)); > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 0), > > + rockchip_vpu_jpeg_get_qtable(_ctx, > > 1)); > > > > reg = VEPU_REG_OUTPUT_SWAP32 > > | VEPU_REG_OUTPUT_SWAP16 > > > Thanks, Mauro
