Re: [PATCH v1 1/1] media: atmel-isc: Add safety checks for NULL isc->raw_fmt struct
On 20.11.2018 22:43, Ken Sloat wrote:
> From: Ken Sloat
>
> In some usages isc->raw_fmt will not be initialized. If this
> is the case, it is very possible that a NULL struct de-reference
> will occur, as this member is referenced many times.
Hello Ken,
Do you have any confidence that just by avoiding the NULL situation,
this fix makes things right for adding new sensors that for example, do
not offer a raw format ?
The check that actually sets the raw_fmt comes from an iteration through
the formats, and the one having the RAW flag gets put into this
variable. One could just alter the formats table and get the raw_fmt
that is needed.
My feeling is that the method of adding this variable (raw_fmt) is very
unfortunate, and I did not completely understand the situations where
it's needed.
Look inline about what I mean...
>
> To prevent this, add safety checks for this member and handle
> situations accordingly.
>
> Signed-off-by: Ken Sloat
> ---
> drivers/media/platform/atmel/atmel-isc.c | 64
> 1 file changed, 44 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.c
> b/drivers/media/platform/atmel/atmel-isc.c
> index 50178968b8a6..4cccaa4f2ce9 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -902,6 +902,15 @@ static inline bool sensor_is_preferred(const struct
> isc_format *isc_fmt)
> !isc_fmt->isc_support;
> }
>
> +static inline u32 get_preferred_mbus_code(const struct isc_device *isc,
> + const struct isc_format *isc_fmt)
> +{
> + if (sensor_is_preferred(isc_fmt) || !isc->raw_fmt)
> + return isc_fmt->mbus_code;
For example here, if we do _not_ have a raw format, what makes us
believe that the right format is the one from the mbus_code from the
isc_fmt ? Is there anything useful there at all ?
> + else
> + return isc->raw_fmt->mbus_code;
> +}
> +
> static struct fmt_config *get_fmt_config(u32 fourcc)
> {
> struct fmt_config *config;
> @@ -955,7 +964,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32
> pipeline)
> {
> struct regmap *regmap = isc->regmap;
> struct isc_ctrls *ctrls = >ctrls;
> - struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);
> + struct fmt_config *config;
> u32 val, bay_cfg;
> const u32 *gamma;
> unsigned int i;
> @@ -969,7 +978,12 @@ static void isc_set_pipeline(struct isc_device *isc, u32
> pipeline)
> if (!pipeline)
> return;
>
> - bay_cfg = config->cfa_baycfg;
> + if (isc->raw_fmt) {
> + config = get_fmt_config(isc->raw_fmt->fourcc);
> + bay_cfg = config->cfa_baycfg;
> + } else {
> + bay_cfg = 0;
> + }
Having bay_cfg zero, in the case when we do not have a raw format, is
the real proper way to do this ? it is possible that this bay cfg is
required at a different value, or corresponding to different formats in
the pipeline of the ISC.
>
> regmap_write(regmap, ISC_WB_CFG, bay_cfg);
> regmap_write(regmap, ISC_WB_O_RGR, 0x0);
> @@ -1022,12 +1036,20 @@ static void isc_set_histogram(struct isc_device *isc)
> {
> struct regmap *regmap = isc->regmap;
> struct isc_ctrls *ctrls = >ctrls;
> - struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);
> + struct fmt_config *config;
> + u32 cfa_baycfg;
> +
> + if (isc->raw_fmt) {
> + config = get_fmt_config(isc->raw_fmt->fourcc);
> + cfa_baycfg = config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
> + } else {
> + cfa_baycfg = 0;
> + }
Ditto
>
> if (ctrls->awb && (ctrls->hist_stat != HIST_ENABLED)) {
> regmap_write(regmap, ISC_HIS_CFG,
>ISC_HIS_CFG_MODE_R |
> - (config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT) |
> + cfa_baycfg |
>ISC_HIS_CFG_RAR);
> regmap_write(regmap, ISC_HIS_CTRL, ISC_HIS_CTRL_EN);
> regmap_write(regmap, ISC_INTEN, ISC_INT_HISDONE);
> @@ -1075,7 +1097,7 @@ static int isc_configure(struct isc_device *isc)
> struct regmap *regmap = isc->regmap;
> const struct isc_format *current_fmt = isc->current_fmt;
> struct fmt_config *curfmt_config = get_fmt_config(current_fmt->fourcc);
> - struct fmt_config *rawfmt_config = get_fmt_config(isc->raw_fmt->fourcc);
> + struct fmt_config *rawfmt_config;
> struct isc_subdev_entity *subdev = isc->current_subdev;
> u32 pfe_cfg0, rlp_mode, dcfg, mask, pipeline;
>
> @@ -1085,7 +1107,12 @@ static int isc_configure(struct isc_device *isc)
> isc_get_param(current_fmt, _mode, );
> isc->ctrls.hist_stat = HIST_INIT;
> } else {
> - pfe_cfg0 = rawfmt_config->pfe_cfg0_bps;
> + if
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Nov 21 05:00:13 CET 2018 media-tree git hash:5200ab6a32d6055428896a49ec9e3b1652c1a100 media_build git hash: a8aef9cea0a4a2f3ea86c0b37bd6a1378018c0c1 v4l-utils git hash: 7a98cfff67c41b82864a953d606270fbedb151dc 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: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: WARNINGS linux-git-arm-stm32: WARNINGS linux-git-arm64: OK linux-git-i686: WARNINGS linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-sh: OK linux-git-x86_64: WARNINGS Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.123-i686: OK linux-3.18.123-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.159-i686: OK linux-4.4.159-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.131-i686: OK linux-4.9.131-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.74-i686: OK linux-4.14.74-x86_64: OK 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
[PATCH v9 3/3] media: add Rockchip VPU JPEG encoder driver
Add a mem2mem driver for the VPU available on Rockchip SoCs. Currently only JPEG encoding is supported, for RK3399 and RK3288 platforms. Signed-off-by: Ezequiel Garcia --- MAINTAINERS | 7 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 14 + drivers/staging/media/rockchip/vpu/Makefile | 10 + drivers/staging/media/rockchip/vpu/TODO | 6 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 +++ .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 +++ .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++ .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 + .../media/rockchip/vpu/rockchip_vpu_enc.c | 702 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 289 +++ .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 12 + 19 files changed, 3473 insertions(+) create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h diff --git a/MAINTAINERS b/MAINTAINERS index a8588dedc683..e5a294453393 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12742,6 +12742,13 @@ S: Maintained F: drivers/media/platform/rockchip/rga/ F: Documentation/devicetree/bindings/media/rockchip-rga.txt +ROCKCHIP VPU CODEC DRIVER +M: Ezequiel Garcia +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/staging/media/platform/rockchip/vpu/ +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt + ROCKER DRIVER M: Jiri Pirko L: net...@vger.kernel.org diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index b3620a8f2d9f..c6f3404dea43 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" source "drivers/staging/media/omap4iss/Kconfig" +source "drivers/staging/media/rockchip/vpu/Kconfig" + source "drivers/staging/media/sunxi/Kconfig" source "drivers/staging/media/tegra-vde/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 42948f805548..43c7bee1fc8c 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ diff --git a/drivers/staging/media/rockchip/vpu/Kconfig b/drivers/staging/media/rockchip/vpu/Kconfig new file mode 100644 index ..fa65c03d65bf --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Kconfig @@ -0,0 +1,14 @@ +config VIDEO_ROCKCHIP_VPU + tristate "Rockchip VPU driver" + depends on ARCH_ROCKCHIP || COMPILE_TEST + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER + select VIDEOBUF2_DMA_CONTIG + select VIDEOBUF2_VMALLOC + select V4L2_MEM2MEM_DEV + default n + help + Support for the Video Processing Unit present on Rockchip SoC, + which accelerates video and image encoding and decoding. + To compile this driver as a module, choose M here: the module + will be called rockchip-vpu. + diff --git a/drivers/staging/media/rockchip/vpu/Makefile b/drivers/staging/media/rockchip/vpu/Makefile new file mode 100644 index ..e9d733bb7632 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Makefile @@ -0,0 +1,10 @@
[PATCH v9 2/3] arm64: dts: rockchip: add VPU device node for RK3399
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.
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 99e7f65c1779..040d3080565f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1226,6 +1226,18 @@
status = "disabled";
};
+ vpu: video-codec@ff65 {
+ compatible = "rockchip,rk3399-vpu";
+ reg = <0x0 0xff65 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3399_PD_VCODEC>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff650800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff650800 0x0 0x40>;
@@ -1233,8 +1245,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3399_PD_VCODEC>;
#iommu-cells = <0>;
- status = "disabled";
};
vdec_mmu: iommu@ff660480 {
--
2.19.1
[PATCH v9 1/3] ARM: dts: rockchip: add VPU device node for RK3288
Add the Video Processing Unit node for RK3288 SoC.
Fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/rk3288.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 0840ffb3205c..40d203cdca09 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1223,6 +1223,18 @@
};
};
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff9a0800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff9a0800 0x0 0x100>;
@@ -1230,8 +1242,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3288_PD_VIDEO>;
#iommu-cells = <0>;
- status = "disabled";
};
hevc_mmu: iommu@ff9c0440 {
--
2.19.1
[PATCH v9 0/3] Add Rockchip VPU JPEG encoder
Hi everyone, This is a quick respin addressing Hans' feedback on the v8 version (see previous series for more details [1]). Long story short: This new version supports V4L2_PIX_FMT_JPEG capture format, which means standard userspace can be used, such as gstreamer: gst-launch-1.0 videotestsrc ! v4l2jpegenc extra-controls="c,compression_quality=95" ! ... The hardware produces a JPEG scan (i.e. without the start JPEG headers), so the driver has to add the needed headers. Note that the hardware produces a EOI marker at the end of the JPEG scan. [1] https://www.mail-archive.com/linux-media@vger.kernel.org/msg136539.html Future work --- * factorization of default JPEG tables, with other JPEG drivers such as CODA. * factorization of the fill_fmt functions. * removal of bounce buffer via APPn marker padding. I'd like to pospone such factorization until after this driver is merged, to avoid delaying this work any further. In addition to this, it would be interesting to add user controls to specify the quantization tables. It's not yet clear how this control would interact with the JPEG compression quality control, and so it needs some discussion. Compliance output - root@ficus:~# v4l2-compliance -d /dev/video3 -s v4l2-compliance SHA: d0f4ea7ddab6d0244c4fe1e960bb2aaeefb911b9, 64 bits Compliance test for device /dev/video3: Driver Info: Driver name : rockchip-vpu Card type: rockchip,rk3399-vpu-enc Bus info : platform: rockchip-vpu Driver version : 4.20.0 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Media Driver Info: Driver name : rockchip-vpu Model: rockchip-vpu Serial : Bus info : Media version: 4.20.0 Hardware revision: 0x (0) Driver version : 4.20.0 Interface Info: ID : 0x030c Type : V4L Video Entity Info: ID : 0x0001 (1) Name : rockchip,rk3399-vpu-enc-source Function : V4L2 I/O Pad 0x0102 : 0: Source Link 0x0208: to remote pad 0x105 of entity 'rockchip,rk3399-vpu-enc-proc': Data, Enabled, Immutable Required ioctls: test MC information (see 'Media Driver Info' above): OK test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second /dev/video3 open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 2 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test
[PATCH v1 1/1] media: atmel-isc: Add safety checks for NULL isc->raw_fmt struct
From: Ken Sloat
In some usages isc->raw_fmt will not be initialized. If this
is the case, it is very possible that a NULL struct de-reference
will occur, as this member is referenced many times.
To prevent this, add safety checks for this member and handle
situations accordingly.
Signed-off-by: Ken Sloat
---
drivers/media/platform/atmel/atmel-isc.c | 64
1 file changed, 44 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isc.c
b/drivers/media/platform/atmel/atmel-isc.c
index 50178968b8a6..4cccaa4f2ce9 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -902,6 +902,15 @@ static inline bool sensor_is_preferred(const struct
isc_format *isc_fmt)
!isc_fmt->isc_support;
}
+static inline u32 get_preferred_mbus_code(const struct isc_device *isc,
+ const struct isc_format *isc_fmt)
+{
+ if (sensor_is_preferred(isc_fmt) || !isc->raw_fmt)
+ return isc_fmt->mbus_code;
+ else
+ return isc->raw_fmt->mbus_code;
+}
+
static struct fmt_config *get_fmt_config(u32 fourcc)
{
struct fmt_config *config;
@@ -955,7 +964,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32
pipeline)
{
struct regmap *regmap = isc->regmap;
struct isc_ctrls *ctrls = >ctrls;
- struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);
+ struct fmt_config *config;
u32 val, bay_cfg;
const u32 *gamma;
unsigned int i;
@@ -969,7 +978,12 @@ static void isc_set_pipeline(struct isc_device *isc, u32
pipeline)
if (!pipeline)
return;
- bay_cfg = config->cfa_baycfg;
+ if (isc->raw_fmt) {
+ config = get_fmt_config(isc->raw_fmt->fourcc);
+ bay_cfg = config->cfa_baycfg;
+ } else {
+ bay_cfg = 0;
+ }
regmap_write(regmap, ISC_WB_CFG, bay_cfg);
regmap_write(regmap, ISC_WB_O_RGR, 0x0);
@@ -1022,12 +1036,20 @@ static void isc_set_histogram(struct isc_device *isc)
{
struct regmap *regmap = isc->regmap;
struct isc_ctrls *ctrls = >ctrls;
- struct fmt_config *config = get_fmt_config(isc->raw_fmt->fourcc);
+ struct fmt_config *config;
+ u32 cfa_baycfg;
+
+ if (isc->raw_fmt) {
+ config = get_fmt_config(isc->raw_fmt->fourcc);
+ cfa_baycfg = config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
+ } else {
+ cfa_baycfg = 0;
+ }
if (ctrls->awb && (ctrls->hist_stat != HIST_ENABLED)) {
regmap_write(regmap, ISC_HIS_CFG,
ISC_HIS_CFG_MODE_R |
-(config->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT) |
+cfa_baycfg |
ISC_HIS_CFG_RAR);
regmap_write(regmap, ISC_HIS_CTRL, ISC_HIS_CTRL_EN);
regmap_write(regmap, ISC_INTEN, ISC_INT_HISDONE);
@@ -1075,7 +1097,7 @@ static int isc_configure(struct isc_device *isc)
struct regmap *regmap = isc->regmap;
const struct isc_format *current_fmt = isc->current_fmt;
struct fmt_config *curfmt_config = get_fmt_config(current_fmt->fourcc);
- struct fmt_config *rawfmt_config = get_fmt_config(isc->raw_fmt->fourcc);
+ struct fmt_config *rawfmt_config;
struct isc_subdev_entity *subdev = isc->current_subdev;
u32 pfe_cfg0, rlp_mode, dcfg, mask, pipeline;
@@ -1085,7 +1107,12 @@ static int isc_configure(struct isc_device *isc)
isc_get_param(current_fmt, _mode, );
isc->ctrls.hist_stat = HIST_INIT;
} else {
- pfe_cfg0 = rawfmt_config->pfe_cfg0_bps;
+ if (isc->raw_fmt) {
+ rawfmt_config = get_fmt_config(isc->raw_fmt->fourcc);
+ pfe_cfg0 = rawfmt_config->pfe_cfg0_bps;
+ } else {
+ pfe_cfg0 = curfmt_config->pfe_cfg0_bps;
+ }
pipeline = curfmt_config->bits_pipeline;
rlp_mode = curfmt_config->rlp_cfg_mode;
dcfg = curfmt_config->dcfg_imode |
@@ -1315,10 +1342,7 @@ static int isc_try_fmt(struct isc_device *isc, struct
v4l2_format *f,
if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
- if (sensor_is_preferred(isc_fmt))
- mbus_code = isc_fmt->mbus_code;
- else
- mbus_code = isc->raw_fmt->mbus_code;
+ mbus_code = get_preferred_mbus_code(isc, isc_fmt);
v4l2_fill_mbus_format(, pixfmt, mbus_code);
ret = v4l2_subdev_call(isc->current_subdev->sd, pad, set_fmt,
@@ -1442,10 +1466,7 @@ static int isc_enum_framesizes(struct file *file, void
*fh,
if (!isc_fmt)
return -EINVAL;
- if (sensor_is_preferred(isc_fmt))
- fse.code =
Re: [PATCH v8 3/3] media: add Rockchip VPU JPEG encoder driver
On Tue, 2018-11-20 at 14:52 +0100, Hans Verkuil wrote: > On 11/19/2018 04:29 PM, Ezequiel Garcia wrote: > > Add a mem2mem driver for the VPU available on Rockchip SoCs. > > Currently only JPEG encoding is supported, for RK3399 and RK3288 > > platforms. > > > > Signed-off-by: Ezequiel Garcia > > --- > > MAINTAINERS | 7 + > > drivers/staging/media/Kconfig | 2 + > > drivers/staging/media/Makefile| 1 + > > drivers/staging/media/rockchip/vpu/Kconfig| 14 + > > drivers/staging/media/rockchip/vpu/Makefile | 10 + > > drivers/staging/media/rockchip/vpu/TODO | 9 + > > .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ > > .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 > > .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 +++ > > .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ > > .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 > > .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 +++ > > .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++ > > .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + > > .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 + > > .../media/rockchip/vpu/rockchip_vpu_enc.c | 701 ++ > > .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ > > .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 289 > > .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 12 + > > 19 files changed, 3475 insertions(+) > > create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig > > create mode 100644 drivers/staging/media/rockchip/vpu/Makefile > > create mode 100644 drivers/staging/media/rockchip/vpu/TODO > > create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c > > create mode 100644 > > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h > > create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c > > create mode 100644 > > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index a8588dedc683..e5a294453393 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -12742,6 +12742,13 @@ S: Maintained > > F: drivers/media/platform/rockchip/rga/ > > F: Documentation/devicetree/bindings/media/rockchip-rga.txt > > > > +ROCKCHIP VPU CODEC DRIVER > > +M: Ezequiel Garcia > > +L: linux-media@vger.kernel.org > > +S: Maintained > > +F: drivers/staging/media/platform/rockchip/vpu/ > > +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt > > + > > ROCKER DRIVER > > M: Jiri Pirko > > L: net...@vger.kernel.org > > diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig > > index b3620a8f2d9f..c6f3404dea43 100644 > > --- a/drivers/staging/media/Kconfig > > +++ b/drivers/staging/media/Kconfig > > @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" > > > > source "drivers/staging/media/omap4iss/Kconfig" > > > > +source "drivers/staging/media/rockchip/vpu/Kconfig" > > + > > source "drivers/staging/media/sunxi/Kconfig" > > > > source "drivers/staging/media/tegra-vde/Kconfig" > > diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile > > index 42948f805548..43c7bee1fc8c 100644 > > --- a/drivers/staging/media/Makefile > > +++ b/drivers/staging/media/Makefile > > @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ > > obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ > > obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ > > obj-$(CONFIG_VIDEO_ZORAN) += zoran/ > > +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ > > diff --git a/drivers/staging/media/rockchip/vpu/Kconfig > > b/drivers/staging/media/rockchip/vpu/Kconfig > > new file mode 100644 > > index ..fa65c03d65bf > > --- /dev/null > > +++ b/drivers/staging/media/rockchip/vpu/Kconfig > > @@ -0,0 +1,14 @@ > > +config VIDEO_ROCKCHIP_VPU > > + tristate "Rockchip VPU driver" > > + depends on ARCH_ROCKCHIP || COMPILE_TEST > > + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER > > + select VIDEOBUF2_DMA_CONTIG > > + select VIDEOBUF2_VMALLOC > > + select V4L2_MEM2MEM_DEV > > + default n > > + help > > + Support for the Video Processing Unit present on Rockchip SoC, > > +
Re: [PATCH v5 01/11] media: ov5640: Adjust the clock based on the expected rate
Hi Maxime,
On Tue, Nov 20, 2018 at 10:48:39AM +0100, Maxime Ripard wrote:
> Hi Jacopo,
>
> On Wed, Nov 14, 2018 at 08:48:47PM +0100, jacopo mondi wrote:
> > On Tue, Nov 13, 2018 at 02:03:15PM +0100, Maxime Ripard wrote:
> > > The clock structure for the PCLK is quite obscure in the documentation,
> > > and
> > > was hardcoded through the bytes array of each and every mode.
> > >
> > > This is troublesome, since we cannot adjust it at runtime based on other
> > > parameters (such as the number of bytes per pixel), and we can't support
> > > either framerates that have not been used by the various vendors, since we
> > > don't have the needed initialization sequence.
> > >
> > > We can however understand how the clock tree works, and then implement
> > > some
> > > functions to derive the various parameters from a given rate. And now that
> > > those parameters are calculated at runtime, we can remove them from the
> > > initialization sequence.
> > >
> > > The modes also gained a new parameter which is the clock that they are
> > > running at, from the register writes they were doing, so for now the
> > > switch
> > > to the new algorithm should be transparent.
> > >
> > > Signed-off-by: Maxime Ripard
> >
> > As you've squashed in my MIPI CSI-2 fixes, do you think it is
> > appropriate adding my So-b tag here?
>
> Yeah, I'll add your co-developped-by tag as well, if that's ok.
>
Yeah, whatever works for you here... Thanks ;)
> > > +/*
> > > + * This is supposed to be ranging from 1 to 16, but the value is
> > > + * always set to either 1 or 2 in the vendor kernels.
> > > + */
> >
> > I forgot to fix this comment in my patches you squahed in here (the
> > value now ranges from 1 to 16
>
> Ok.
>
> > > +#define OV5640_SYSDIV_MIN1
> > > +#define OV5640_SYSDIV_MAX16
> > > +
> > > +/*
> > > + * This is supposed to be ranging from 1 to 16, but the value is always
> > > + * set to 2 in the vendor kernels.
> > > + */
> > > +#define OV5640_MIPI_DIV 2
> > > +
> > > +/*
> > > + * This is supposed to be ranging from 1 to 2, but the value is always
> > > + * set to 2 in the vendor kernels.
> > > + */
> > > +#define OV5640_PLL_ROOT_DIV 2
> > > +#define OV5640_PLL_CTRL3_PLL_ROOT_DIV_2 BIT(4)
> > > +
> > > +/*
> > > + * We only supports 8-bit formats at the moment
> > > + */
> > > +#define OV5640_BIT_DIV 2
> > > +#define OV5640_PLL_CTRL0_MIPI_MODE_8BIT 0x08
> > > +
> > > +/*
> > > + * This is supposed to be ranging from 1 to 8, but the value is always
> > > + * set to 2 in the vendor kernels.
> > > + */
> > > +#define OV5640_SCLK_ROOT_DIV 2
> > > +
> > > +/*
> > > + * This is hardcoded so that the consistency is maintained between SCLK
> > > and
> > > + * SCLK 2x.
> > > + */
> > > +#define OV5640_SCLK2X_ROOT_DIV (OV5640_SCLK_ROOT_DIV / 2)
> > > +
> > > +/*
> > > + * This is supposed to be ranging from 1 to 8, but the value is always
> > > + * set to 1 in the vendor kernels.
> > > + */
> > > +#define OV5640_PCLK_ROOT_DIV 1
> > > +#define OV5640_PLL_SYS_ROOT_DIVIDER_BYPASS 0x00
> > > +
> > > +static unsigned long ov5640_compute_sys_clk(struct ov5640_dev *sensor,
> > > + u8 pll_prediv, u8 pll_mult,
> > > + u8 sysdiv)
> > > +{
> > > + unsigned long sysclk = sensor->xclk_freq / pll_prediv * pll_mult;
> > > +
> > > + /* PLL1 output cannot exceed 1GHz. */
> > > + if (sysclk / 100 > 1000)
> > > + return 0;
> > > +
> > > + return sysclk / sysdiv;
> > > +}
> >
> > That's better, but Sam's version is even better. I plan to pick some
> > part of his patch and apply them on top of this (for this and a few
> > other things I'm pointing out a here below). How would you like to
> > have those updates? Incremental patches on top of this series once it
> > gets merged (and it can now be merged, since it works for both CSI-2
> > and DVP), or would you like to receive those patches, squash them in
> > and re-send?
>
> The first solution would be better, having to constantly piling up
> patches in a series is a very efficient way to not get anything
> merged.
>
I know -.-
Fine, I'll have some more patches for ov5640 for next cycle then :)
(For this and all other changes to the CSI-2 portion of this patch)
> > > +
> > > +static unsigned long ov5640_calc_sys_clk(struct ov5640_dev *sensor,
> > > + unsigned long rate,
> > > + u8 *pll_prediv, u8 *pll_mult,
> > > + u8 *sysdiv)
> > > +{
> > > + unsigned long best = ~0;
> > > + u8 best_sysdiv = 1, best_mult = 1;
> > > + u8 _sysdiv, _pll_mult;
> > > +
> > > + for (_sysdiv = OV5640_SYSDIV_MIN;
> > > + _sysdiv <= OV5640_SYSDIV_MAX;
> > > + _sysdiv++) {
> > > + for (_pll_mult = OV5640_PLL_MULT_MIN;
> > > + _pll_mult <= OV5640_PLL_MULT_MAX;
> > > +
Re: [PATCH] media: video-i2c: don't use msleep for 1ms - 20ms
On Wed, Nov 21, 2018 at 12:27:40AM +0900, Akinobu Mita wrote: > Documentation/timers/timers-howto.txt says: > > "msleep(1~20) may not do what the caller intends, and will often sleep > longer (~20 ms actual sleep for any value given in the 1~20ms range)." > > So replace msleep(2) by usleep_range(2000, 3000). > > Reported-by: Hans Verkuil > Cc: Matt Ranostay > Cc: Sakari Ailus > Cc: Hans Verkuil > Cc: Mauro Carvalho Chehab > Signed-off-by: Akinobu Mita Acked-by: Sakari Ailus -- Sakari Ailus sakari.ai...@linux.intel.com
[PATCH] media: video-i2c: don't use msleep for 1ms - 20ms
Documentation/timers/timers-howto.txt says: "msleep(1~20) may not do what the caller intends, and will often sleep longer (~20 ms actual sleep for any value given in the 1~20ms range)." So replace msleep(2) by usleep_range(2000, 3000). Reported-by: Hans Verkuil Cc: Matt Ranostay Cc: Sakari Ailus Cc: Hans Verkuil Cc: Mauro Carvalho Chehab Signed-off-by: Akinobu Mita --- This fixes "[PATCH v4 6/6] media: video-i2c: support runtime PM" in the patchset "[PATCH v4 0/6] media: video-i2c: support changing frame interval and runtime PM". drivers/media/i2c/video-i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c index 0c82131..77080d7 100644 --- a/drivers/media/i2c/video-i2c.c +++ b/drivers/media/i2c/video-i2c.c @@ -155,7 +155,7 @@ static int amg88xx_set_power_on(struct video_i2c_data *data) if (ret) return ret; - msleep(2); + usleep_range(2000, 3000); ret = regmap_write(data->regmap, AMG88XX_REG_RST, AMG88XX_RST_FLAG); if (ret) -- 2.7.4
RE: MICROCHIP ISC DRIVER Bug: Possible NULL struct pointer dereference case
> Hello Ken, > > Indeed this is a bug, I saw it before as well, but so far, this has not > appeared with the sensors we have connected. I have been trying to get around > to fix it, but it's not a simple fix, much rather a rework of the driver part > that handles the raw > formats. > > Feel free to submit patches if you find a good fix/rework and I will have a > look and test it for the sensors which I currently have. > > Thanks again, > Eugen Hi Eugen, Thanks for your quick reply. I will see what I can come up with. I may reply with additional questions. Thanks, Ken Sloat
Re: [PATCH v8 3/3] media: add Rockchip VPU JPEG encoder driver
On 11/19/2018 04:29 PM, Ezequiel Garcia wrote: > Add a mem2mem driver for the VPU available on Rockchip SoCs. > Currently only JPEG encoding is supported, for RK3399 and RK3288 > platforms. > > Signed-off-by: Ezequiel Garcia > --- > MAINTAINERS | 7 + > drivers/staging/media/Kconfig | 2 + > drivers/staging/media/Makefile| 1 + > drivers/staging/media/rockchip/vpu/Kconfig| 14 + > drivers/staging/media/rockchip/vpu/Makefile | 10 + > drivers/staging/media/rockchip/vpu/TODO | 9 + > .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ > .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 > .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 +++ > .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ > .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 > .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 +++ > .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++ > .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + > .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 + > .../media/rockchip/vpu/rockchip_vpu_enc.c | 701 ++ > .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ > .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 289 > .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 12 + > 19 files changed, 3475 insertions(+) > create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig > create mode 100644 drivers/staging/media/rockchip/vpu/Makefile > create mode 100644 drivers/staging/media/rockchip/vpu/TODO > create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c > create mode 100644 > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h > create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c > create mode 100644 > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index a8588dedc683..e5a294453393 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -12742,6 +12742,13 @@ S: Maintained > F: drivers/media/platform/rockchip/rga/ > F: Documentation/devicetree/bindings/media/rockchip-rga.txt > > +ROCKCHIP VPU CODEC DRIVER > +M: Ezequiel Garcia > +L: linux-media@vger.kernel.org > +S: Maintained > +F: drivers/staging/media/platform/rockchip/vpu/ > +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt > + > ROCKER DRIVER > M: Jiri Pirko > L: net...@vger.kernel.org > diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig > index b3620a8f2d9f..c6f3404dea43 100644 > --- a/drivers/staging/media/Kconfig > +++ b/drivers/staging/media/Kconfig > @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" > > source "drivers/staging/media/omap4iss/Kconfig" > > +source "drivers/staging/media/rockchip/vpu/Kconfig" > + > source "drivers/staging/media/sunxi/Kconfig" > > source "drivers/staging/media/tegra-vde/Kconfig" > diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile > index 42948f805548..43c7bee1fc8c 100644 > --- a/drivers/staging/media/Makefile > +++ b/drivers/staging/media/Makefile > @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ > obj-$(CONFIG_VIDEO_SUNXI)+= sunxi/ > obj-$(CONFIG_TEGRA_VDE) += tegra-vde/ > obj-$(CONFIG_VIDEO_ZORAN)+= zoran/ > +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ > diff --git a/drivers/staging/media/rockchip/vpu/Kconfig > b/drivers/staging/media/rockchip/vpu/Kconfig > new file mode 100644 > index ..fa65c03d65bf > --- /dev/null > +++ b/drivers/staging/media/rockchip/vpu/Kconfig > @@ -0,0 +1,14 @@ > +config VIDEO_ROCKCHIP_VPU > + tristate "Rockchip VPU driver" > + depends on ARCH_ROCKCHIP || COMPILE_TEST > + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER > + select VIDEOBUF2_DMA_CONTIG > + select VIDEOBUF2_VMALLOC > + select V4L2_MEM2MEM_DEV > + default n > + help > + Support for the Video Processing Unit present on Rockchip SoC, > + which accelerates video and image encoding and decoding. > + To compile this driver as a module, choose M here: the module > + will be called rockchip-vpu. > + > diff --git
Re: 'bad remote port parent' warnings
Hi Sakari, On Tue, Nov 20, 2018 at 10:15 AM Sakari Ailus wrote: > Where's the DT source for the board? Board dts is arch/arm/boot/dts/imx6qdl-wandboard.dtsi SoC dtsi is arch/arm/boot/dts/imx6q.dtsi Also, since 4.20-rc the following errors are seen: [3.449564] imx-ipuv3 240.ipu: driver could not parse port@1/endpoint@0 (-22) [3.457342] imx-ipuv3-csi: probe of imx-ipuv3-csi.1 failed with error -22 [3.464498] imx-ipuv3 280.ipu: driver could not parse port@0/endpoint@0 (-22) [3.472120] imx-ipuv3-csi: probe of imx-ipuv3-csi.4 failed with error -22 which were not present in 4.19. Log from 4.19: https://storage.kernelci.org/stable/linux-4.19.y/v4.19.2/arm/imx_v6_v7_defconfig/lab-baylibre-seattle/boot-imx6q-wandboard.html Log from 4.20-rc3: https://storage.kernelci.org/mainline/master/v4.20-rc3/arm/imx_v6_v7_defconfig/lab-baylibre-seattle/boot-imx6q-wandboard.html Thanks
Re: 'bad remote port parent' warnings
On Tue, Nov 20, 2018 at 10:10:57AM -0200, Fabio Estevam wrote: > Hi, > > On a imx6q-wandboard running linux-next 20181120 there the following warnings: > > [4.327794] video-mux 20e.iomuxc-gpr:ipu1_csi0_mux: bad remote > port parent > [4.336118] video-mux 20e.iomuxc-gpr:ipu2_csi1_mux: bad remote > port parent > > Is there anything we should do to prevent this from happening? Where's the DT source for the board? -- Sakari Ailus sakari.ai...@linux.intel.com
'bad remote port parent' warnings
Hi, On a imx6q-wandboard running linux-next 20181120 there the following warnings: [4.327794] video-mux 20e.iomuxc-gpr:ipu1_csi0_mux: bad remote port parent [4.336118] video-mux 20e.iomuxc-gpr:ipu2_csi1_mux: bad remote port parent Is there anything we should do to prevent this from happening? Thanks, Fabio Estevam
Re: [PATCH] videodev2.h: add V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF/CREATE_BUFS
Hi Hans,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.20-rc3 next-20181120]
[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/Hans-Verkuil/videodev2-h-add-V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF-CREATE_BUFS/20181120-190153
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x070-201846 (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=i386
All warnings (new ones prefixed by >>):
In file included from include/linux/err.h:5:0,
from drivers/media/common/videobuf2/videobuf2-v4l2.c:17:
drivers/media/common/videobuf2/videobuf2-v4l2.c: In function
'fill_buf_caps_vdev':
drivers/media/common/videobuf2/videobuf2-v4l2.c:878:21: error: dereferencing
pointer to incomplete type 'const struct v4l2_ioctl_ops'
if (vdev->ioctl_ops->vidioc_prepare_buf)
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/media/common/videobuf2/videobuf2-v4l2.c:878:2: note: in expansion of
>> macro 'if'
if (vdev->ioctl_ops->vidioc_prepare_buf)
^~
vim +/if +878 drivers/media/common/videobuf2/videobuf2-v4l2.c
873
874 static void fill_buf_caps_vdev(struct video_device *vdev, u32 *caps)
875 {
876 *caps = 0;
877 fill_buf_caps(vdev->queue, caps);
> 878 if (vdev->ioctl_ops->vidioc_prepare_buf)
879 *caps |= V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF;
880 if (vdev->ioctl_ops->vidioc_create_bufs)
881 *caps |= V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS;
882 }
883
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] videodev2.h: add V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF/CREATE_BUFS
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.20-rc3 next-20181120]
[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/Hans-Verkuil/videodev2-h-add-V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF-CREATE_BUFS/20181120-190153
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x077-201846 (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=i386
All errors (new ones prefixed by >>):
drivers/media/common/videobuf2/videobuf2-v4l2.c: In function
'fill_buf_caps_vdev':
>> drivers/media/common/videobuf2/videobuf2-v4l2.c:878:21: error: dereferencing
>> pointer to incomplete type 'const struct v4l2_ioctl_ops'
if (vdev->ioctl_ops->vidioc_prepare_buf)
^~
vim +878 drivers/media/common/videobuf2/videobuf2-v4l2.c
873
874 static void fill_buf_caps_vdev(struct video_device *vdev, u32 *caps)
875 {
876 *caps = 0;
877 fill_buf_caps(vdev->queue, caps);
> 878 if (vdev->ioctl_ops->vidioc_prepare_buf)
879 *caps |= V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF;
880 if (vdev->ioctl_ops->vidioc_create_bufs)
881 *caps |= V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS;
882 }
883
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v2 for v4.4 1/1] v4l: event: Add subscription to list before calling "add" operation
Em Tue, 20 Nov 2018 12:49:46 +0200 Sakari Ailus escreveu: > Hi Greg, > > On Mon, Nov 19, 2018 at 06:46:21PM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 19, 2018 at 07:03:54PM +0200, Sakari Ailus wrote: > > > Hi Greg, > > > > > > On Mon, Nov 19, 2018 at 04:14:00PM +0100, Greg Kroah-Hartman wrote: > > > > On Wed, Nov 14, 2018 at 11:37:46AM +0200, Sakari Ailus wrote: > > > > > [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ] > > > > > > > > There is no such git commit id in Linus's tree :( > > > > > > Right. At the moment it's in the media tree only. I expect it'll end up to > > > Linus's tree once Mauro will send the next pull request from the media > > > tree > > > to Linus. > > > > Ok, please do not send requests for stable tree inclusion until _AFTER_ > > the patch is in Linus's tree, otherwise it just wastes the stable tree > > maintainer's time :( > > Apologies for the noise. I'll send you a note once the patches are in > Linus's tree. Btw, just sent a pull request with this patch. I wanted to send this two weeks ago, but I had to do two trips (the final one to be at KS/LPC). This ended by delaying the pull request. Thanks, Mauro
Re: [PATCH v2 for v4.4 1/1] v4l: event: Add subscription to list before calling "add" operation
Hi Greg, On Mon, Nov 19, 2018 at 06:46:21PM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 19, 2018 at 07:03:54PM +0200, Sakari Ailus wrote: > > Hi Greg, > > > > On Mon, Nov 19, 2018 at 04:14:00PM +0100, Greg Kroah-Hartman wrote: > > > On Wed, Nov 14, 2018 at 11:37:46AM +0200, Sakari Ailus wrote: > > > > [ upstream commit 92539d3eda2c090b382699bbb896d4b54e9bdece ] > > > > > > There is no such git commit id in Linus's tree :( > > > > Right. At the moment it's in the media tree only. I expect it'll end up to > > Linus's tree once Mauro will send the next pull request from the media tree > > to Linus. > > Ok, please do not send requests for stable tree inclusion until _AFTER_ > the patch is in Linus's tree, otherwise it just wastes the stable tree > maintainer's time :( Apologies for the noise. I'll send you a note once the patches are in Linus's tree. Thanks. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com
[GIT PULL for 4.21] Sensor and CSI driver patches
Hi Mauro, Here are a bunch of sensor driver improvements as well as a driver for the Allwinner CSI parallel bridge. Finally, a small uAPI documentation fix to better document the metadata capture buffers. Please pull. The following changes since commit fbe57dde7126d1b2712ab5ea93fb9d15f89de708: media: ov7740: constify structures stored in fields of v4l2_subdev_ops structure (2018-11-06 07:17:02 -0500) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git tags/for-4.21-2-sign for you to fetch changes up to 76bdfdc1cf59b13a204ff18d57549f635956050e: media: V3s: Add support for Allwinner CSI. (2018-11-20 12:31:04 +0200) sensor + CSI patches for 4.21 Akinobu Mita (7): media: mt9m111: support log_status ioctl and event interface media: mt9m111: add V4L2_CID_COLORFX control media: ov2640: add V4L2_CID_TEST_PATTERN control media: ov2640: support log_status ioctl and event interface media: ov5640: support log_status ioctl and event interface media: ov7670: support log_status ioctl and event interface media: ov772x: support log_status ioctl and event interface Chen, JasonX Z (1): media: imx258: remove test pattern map from driver Nathan Chancellor (1): media: imx214: Remove unnecessary self assignment in for loop Sakari Ailus (1): v4l: uAPI doc: Simplify NATIVE_SIZE selection target documentation Yong Deng (2): dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI) media: V3s: Add support for Allwinner CSI. .../devicetree/bindings/media/sun6i-csi.txt| 56 ++ .../media/uapi/v4l/v4l2-selection-targets.rst | 7 +- MAINTAINERS| 8 + drivers/media/i2c/imx214.c | 2 +- drivers/media/i2c/imx258.c | 22 +- drivers/media/i2c/mt9m111.c| 44 +- drivers/media/i2c/ov2640.c | 21 +- drivers/media/i2c/ov5640.c | 7 +- drivers/media/i2c/ov7670.c | 6 +- drivers/media/i2c/ov772x.c | 7 +- drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile| 2 + drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 + drivers/media/platform/sunxi/sun6i-csi/Makefile| 3 + drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 912 + drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 135 +++ .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 196 + .../media/platform/sunxi/sun6i-csi/sun6i_video.c | 678 +++ .../media/platform/sunxi/sun6i-csi/sun6i_video.h | 38 + 19 files changed, 2121 insertions(+), 33 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h -- Sakari Ailus e-mail: sakari.ai...@iki.fi
[PATCH 1/3] media: dvb_frontend: don't print function names twice
The dvb_frontend dprintk() macro already prints __func__. So,
we don't need to add it again at the printed message.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-core/dvb_frontend.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 961207cf09eb..2a26f9210394 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2587,8 +2587,8 @@ static int dvb_frontend_handle_ioctl(struct file *file,
u8 last = 1;
if (dvb_frontend_debug)
- dprintk("%s switch command: 0x%04lx\n",
- __func__, swcmd);
+ dprintk("switch command: 0x%04lx\n",
+ swcmd);
nexttime = ktime_get_boottime();
if (dvb_frontend_debug)
tv[0] = nexttime;
@@ -2611,8 +2611,8 @@ static int dvb_frontend_handle_ioctl(struct file *file,
dvb_frontend_sleep_until(,
8000);
}
if (dvb_frontend_debug) {
- dprintk("%s(%d): switch delay (should be 32k
followed by all 8k)\n",
- __func__, fe->dvb->num);
+ dprintk("(adapter %d): switch delay (should be
32k followed by all 8k)\n",
+ fe->dvb->num);
for (i = 1; i < 10; i++)
pr_info("%d: %d\n", i,
(int)ktime_us_delta(tv[i], tv[i
- 1]));
--
2.19.1
[PATCH 2/3] media: dvb_frontend: add debug message for frequency intervals
As we did an internal change inside the subsystem to always
represent min/max frequencies in Hz, add a debug message, as this
would help to discover bugs on drivers, if any.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-core/dvb_frontend.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 2a26f9210394..27a1d4a98d73 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -917,6 +917,9 @@ static void dvb_frontend_get_frequency_limits(struct
dvb_frontend *fe,
"DVB: adapter %i frontend %u frequency limits
undefined - fix the driver\n",
fe->dvb->num, fe->id);
+ dprintk("frequency interval: tuner: %u...%u, frontend: %u...%u",
+ tuner_min, tuner_max, frontend_min, frontend_max);
+
/* If the standard is for satellite, convert frequencies to kHz */
switch (c->delivery_system) {
case SYS_DVBS:
--
2.19.1
[PATCH 3/3] media: dvb-pll: fix tuner frequency ranges
Tuners should report frequencies in Hz. That works fine on most
drivers, but, in the case of dvb-pll, some settings are for
satellite tuners, while others are for terrestrial/cable ones.
The code was trying to solve it at probing time, but that doesn't
work, as, when _attach is called, the delivery system may be wrong.
Fix it by ensuring that all frequencies are in Hz at the per-tuner
max/min values.
While here, add a debug message, as this would help to debug any
issues there.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/dvb-pll.c | 103 --
1 file changed, 48 insertions(+), 55 deletions(-)
diff --git a/drivers/media/dvb-frontends/dvb-pll.c
b/drivers/media/dvb-frontends/dvb-pll.c
index 6d4b2eec67b4..fff5816f6ec4 100644
--- a/drivers/media/dvb-frontends/dvb-pll.c
+++ b/drivers/media/dvb-frontends/dvb-pll.c
@@ -80,8 +80,8 @@ struct dvb_pll_desc {
static const struct dvb_pll_desc dvb_pll_thomson_dtt7579 = {
.name = "Thomson dtt7579",
- .min = 17700,
- .max = 85800,
+ .min = 177 * MHz,
+ .max = 858 * MHz,
.iffreq= 3617,
.sleepdata = (u8[]){ 2, 0xb4, 0x03 },
.count = 4,
@@ -102,8 +102,8 @@ static void thomson_dtt759x_bw(struct dvb_frontend *fe, u8
*buf)
static const struct dvb_pll_desc dvb_pll_thomson_dtt759x = {
.name = "Thomson dtt759x",
- .min = 17700,
- .max = 89600,
+ .min = 177 * MHz,
+ .max = 896 * MHz,
.set = thomson_dtt759x_bw,
.iffreq= 3617,
.sleepdata = (u8[]){ 2, 0x84, 0x03 },
@@ -126,8 +126,8 @@ static void thomson_dtt7520x_bw(struct dvb_frontend *fe, u8
*buf)
static const struct dvb_pll_desc dvb_pll_thomson_dtt7520x = {
.name = "Thomson dtt7520x",
- .min = 18500,
- .max = 9,
+ .min = 185 * MHz,
+ .max = 900 * MHz,
.set = thomson_dtt7520x_bw,
.iffreq = 3617,
.count = 7,
@@ -144,8 +144,8 @@ static const struct dvb_pll_desc dvb_pll_thomson_dtt7520x =
{
static const struct dvb_pll_desc dvb_pll_lg_z201 = {
.name = "LG z201",
- .min = 17400,
- .max = 86200,
+ .min = 174 * MHz,
+ .max = 862 * MHz,
.iffreq= 3617,
.sleepdata = (u8[]){ 2, 0xbc, 0x03 },
.count = 5,
@@ -160,8 +160,8 @@ static const struct dvb_pll_desc dvb_pll_lg_z201 = {
static const struct dvb_pll_desc dvb_pll_unknown_1 = {
.name = "unknown 1", /* used by dntv live dvb-t */
- .min = 17400,
- .max = 86200,
+ .min = 174 * MHz,
+ .max = 862 * MHz,
.iffreq= 3617,
.count = 9,
.entries = {
@@ -182,8 +182,8 @@ static const struct dvb_pll_desc dvb_pll_unknown_1 = {
*/
static const struct dvb_pll_desc dvb_pll_tua6010xs = {
.name = "Infineon TUA6010XS",
- .min = 4425,
- .max = 85800,
+ .min = 44250 * kHz,
+ .max = 858 * MHz,
.iffreq= 36125000,
.count = 3,
.entries = {
@@ -196,8 +196,8 @@ static const struct dvb_pll_desc dvb_pll_tua6010xs = {
/* Panasonic env57h1xd5 (some Philips PLL ?) */
static const struct dvb_pll_desc dvb_pll_env57h1xd5 = {
.name = "Panasonic ENV57H1XD5",
- .min = 4425,
- .max = 85800,
+ .min = 44250 * kHz,
+ .max = 858 * MHz,
.iffreq= 36125000,
.count = 4,
.entries = {
@@ -220,8 +220,8 @@ static void tda665x_bw(struct dvb_frontend *fe, u8 *buf)
static const struct dvb_pll_desc dvb_pll_tda665x = {
.name = "Philips TDA6650/TDA6651",
- .min = 4425,
- .max = 85800,
+ .min = 44250 * kHz,
+ .max = 858 * MHz,
.set = tda665x_bw,
.iffreq= 3617,
.initdata = (u8[]){ 4, 0x0b, 0xf5, 0x85, 0xab },
@@ -254,8 +254,8 @@ static void tua6034_bw(struct dvb_frontend *fe, u8 *buf)
static const struct dvb_pll_desc dvb_pll_tua6034 = {
.name = "Infineon TUA6034",
- .min = 4425,
- .max = 85800,
+ .min = 44250 * kHz,
+ .max = 858 * MHz,
.iffreq= 3617,
.count = 3,
.set = tua6034_bw,
@@ -278,8 +278,8 @@ static void tded4_bw(struct dvb_frontend *fe, u8 *buf)
static const struct dvb_pll_desc dvb_pll_tded4 = {
.name = "ALPS TDED4",
- .min = 4700,
- .max = 86300,
+ .min = 47 * MHz,
+ .max = 863 * MHz,
.iffreq= 3617,
.set = tded4_bw,
.count = 4,
@@ -296,8 +296,8 @@ static const struct dvb_pll_desc dvb_pll_tded4 = {
*/
static const struct dvb_pll_desc dvb_pll_tdhu2 = {
.name = "ALPS TDHU2",
- .min = 5400,
- .max = 86400,
+ .min = 54 * MHz,
+ .max = 864 * MHz,
.iffreq= 4400,
.count = 4,
.entries = {
@@ -313,8 +313,8 @@ static const struct dvb_pll_desc
[PATCH for v4.20] gspca: fix frame overflow error
When converting gspca to vb2 I missed that fact that the buffer sizes
were rounded up to the next page size. As a result some gspca drivers
(spca561 being one of them) reported frame overflows.
Modify the code to align the buffer sizes to the next page size, just
as the original code did.
Fixes: 1f5965c4dfd7 ("media: gspca: convert to vb2")
Signed-off-by: Hans Verkuil
Tested-off-by: Hans Verkuil
Reported-by: softwarebugs
Cc: # for v4.18 and up
---
diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index fce9d6f4b7c9..3137f5d89d80 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -426,10 +426,10 @@ void gspca_frame_add(struct gspca_dev *gspca_dev,
/* append the packet to the frame buffer */
if (len > 0) {
- if (gspca_dev->image_len + len > gspca_dev->pixfmt.sizeimage) {
+ if (gspca_dev->image_len + len >
PAGE_ALIGN(gspca_dev->pixfmt.sizeimage)) {
gspca_err(gspca_dev, "frame overflow %d > %d\n",
gspca_dev->image_len + len,
- gspca_dev->pixfmt.sizeimage);
+ PAGE_ALIGN(gspca_dev->pixfmt.sizeimage));
packet_type = DISCARD_PACKET;
} else {
/* !! image is NULL only when last pkt is LAST or DISCARD
@@ -1297,18 +1297,19 @@ static int gspca_queue_setup(struct vb2_queue *vq,
unsigned int sizes[], struct device *alloc_devs[])
{
struct gspca_dev *gspca_dev = vb2_get_drv_priv(vq);
+ unsigned int size = PAGE_ALIGN(gspca_dev->pixfmt.sizeimage);
if (*nplanes)
- return sizes[0] < gspca_dev->pixfmt.sizeimage ? -EINVAL : 0;
+ return sizes[0] < size ? -EINVAL : 0;
*nplanes = 1;
- sizes[0] = gspca_dev->pixfmt.sizeimage;
+ sizes[0] = size;
return 0;
}
static int gspca_buffer_prepare(struct vb2_buffer *vb)
{
struct gspca_dev *gspca_dev = vb2_get_drv_priv(vb->vb2_queue);
- unsigned long size = gspca_dev->pixfmt.sizeimage;
+ unsigned long size = PAGE_ALIGN(gspca_dev->pixfmt.sizeimage);
if (vb2_plane_size(vb, 0) < size) {
gspca_err(gspca_dev, "buffer too small (%lu < %lu)\n",
Re: [PATCH] videodev2.h: add V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF/CREATE_BUFS
On Tue, Nov 20, 2018 at 10:41:42AM +0100, Hans Verkuil wrote: > On 11/20/2018 10:27 AM, Sakari Ailus wrote: > > Hi Hans, > > > > On Tue, Nov 20, 2018 at 09:58:43AM +0100, Hans Verkuil wrote: > >> Add new buffer capability flags to indicate if the VIDIOC_PREPARE_BUF or > >> VIDIOC_CREATE_BUFS ioctls are supported. > > > > Are there practical benefits from the change for the user space? > > The more important ioctl to know about is PREPARE_BUF. I noticed this when > working > on v4l2-compliance: the only way to know for an application if PREPARE_BUF > exists > is by trying it, but then you already have prepared a buffer. That's not what > you > want in the application, you need a way to know up front if prepare_buf is > present > or not without having to actually execute it. > > CREATE_BUFS was added because not all drivers support it. It can be dropped > since > it is possible to test for the existence of CREATE_BUFS without actually > allocating > anything, but if I'm adding V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF anyway, then it > is > trivial to add V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS as well to avoid an > additional > ioctl call. > > Hmm, I should have explained this in the commit log. Please add: Acked-by: Sakari Ailus -- Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH v5 01/11] media: ov5640: Adjust the clock based on the expected rate
Hi Jacopo,
On Wed, Nov 14, 2018 at 08:48:47PM +0100, jacopo mondi wrote:
> On Tue, Nov 13, 2018 at 02:03:15PM +0100, Maxime Ripard wrote:
> > The clock structure for the PCLK is quite obscure in the documentation, and
> > was hardcoded through the bytes array of each and every mode.
> >
> > This is troublesome, since we cannot adjust it at runtime based on other
> > parameters (such as the number of bytes per pixel), and we can't support
> > either framerates that have not been used by the various vendors, since we
> > don't have the needed initialization sequence.
> >
> > We can however understand how the clock tree works, and then implement some
> > functions to derive the various parameters from a given rate. And now that
> > those parameters are calculated at runtime, we can remove them from the
> > initialization sequence.
> >
> > The modes also gained a new parameter which is the clock that they are
> > running at, from the register writes they were doing, so for now the switch
> > to the new algorithm should be transparent.
> >
> > Signed-off-by: Maxime Ripard
>
> As you've squashed in my MIPI CSI-2 fixes, do you think it is
> appropriate adding my So-b tag here?
Yeah, I'll add your co-developped-by tag as well, if that's ok.
> > +/*
> > + * This is supposed to be ranging from 1 to 16, but the value is
> > + * always set to either 1 or 2 in the vendor kernels.
> > + */
>
> I forgot to fix this comment in my patches you squahed in here (the
> value now ranges from 1 to 16
Ok.
> > +#define OV5640_SYSDIV_MIN 1
> > +#define OV5640_SYSDIV_MAX 16
> > +
> > +/*
> > + * This is supposed to be ranging from 1 to 16, but the value is always
> > + * set to 2 in the vendor kernels.
> > + */
> > +#define OV5640_MIPI_DIV2
> > +
> > +/*
> > + * This is supposed to be ranging from 1 to 2, but the value is always
> > + * set to 2 in the vendor kernels.
> > + */
> > +#define OV5640_PLL_ROOT_DIV2
> > +#define OV5640_PLL_CTRL3_PLL_ROOT_DIV_2BIT(4)
> > +
> > +/*
> > + * We only supports 8-bit formats at the moment
> > + */
> > +#define OV5640_BIT_DIV 2
> > +#define OV5640_PLL_CTRL0_MIPI_MODE_8BIT0x08
> > +
> > +/*
> > + * This is supposed to be ranging from 1 to 8, but the value is always
> > + * set to 2 in the vendor kernels.
> > + */
> > +#define OV5640_SCLK_ROOT_DIV 2
> > +
> > +/*
> > + * This is hardcoded so that the consistency is maintained between SCLK and
> > + * SCLK 2x.
> > + */
> > +#define OV5640_SCLK2X_ROOT_DIV (OV5640_SCLK_ROOT_DIV / 2)
> > +
> > +/*
> > + * This is supposed to be ranging from 1 to 8, but the value is always
> > + * set to 1 in the vendor kernels.
> > + */
> > +#define OV5640_PCLK_ROOT_DIV 1
> > +#define OV5640_PLL_SYS_ROOT_DIVIDER_BYPASS 0x00
> > +
> > +static unsigned long ov5640_compute_sys_clk(struct ov5640_dev *sensor,
> > + u8 pll_prediv, u8 pll_mult,
> > + u8 sysdiv)
> > +{
> > + unsigned long sysclk = sensor->xclk_freq / pll_prediv * pll_mult;
> > +
> > + /* PLL1 output cannot exceed 1GHz. */
> > + if (sysclk / 100 > 1000)
> > + return 0;
> > +
> > + return sysclk / sysdiv;
> > +}
>
> That's better, but Sam's version is even better. I plan to pick some
> part of his patch and apply them on top of this (for this and a few
> other things I'm pointing out a here below). How would you like to
> have those updates? Incremental patches on top of this series once it
> gets merged (and it can now be merged, since it works for both CSI-2
> and DVP), or would you like to receive those patches, squash them in
> and re-send?
The first solution would be better, having to constantly piling up
patches in a series is a very efficient way to not get anything
merged.
> > +
> > +static unsigned long ov5640_calc_sys_clk(struct ov5640_dev *sensor,
> > +unsigned long rate,
> > +u8 *pll_prediv, u8 *pll_mult,
> > +u8 *sysdiv)
> > +{
> > + unsigned long best = ~0;
> > + u8 best_sysdiv = 1, best_mult = 1;
> > + u8 _sysdiv, _pll_mult;
> > +
> > + for (_sysdiv = OV5640_SYSDIV_MIN;
> > +_sysdiv <= OV5640_SYSDIV_MAX;
> > +_sysdiv++) {
> > + for (_pll_mult = OV5640_PLL_MULT_MIN;
> > +_pll_mult <= OV5640_PLL_MULT_MAX;
> > +_pll_mult++) {
> > + unsigned long _rate;
> > +
> > + /*
> > +* The PLL multiplier cannot be odd if above
> > +* 127.
> > +*/
> > + if (_pll_mult > 127 && (_pll_mult % 2))
> > + continue;
> > +
> > + _rate = ov5640_compute_sys_clk(sensor,
> > + OV5640_PLL_PREDIV,
> > +
Re: [PATCH] videodev2.h: add V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF/CREATE_BUFS
On 11/20/2018 10:27 AM, Sakari Ailus wrote:
> Hi Hans,
>
> On Tue, Nov 20, 2018 at 09:58:43AM +0100, Hans Verkuil wrote:
>> Add new buffer capability flags to indicate if the VIDIOC_PREPARE_BUF or
>> VIDIOC_CREATE_BUFS ioctls are supported.
>
> Are there practical benefits from the change for the user space?
The more important ioctl to know about is PREPARE_BUF. I noticed this when
working
on v4l2-compliance: the only way to know for an application if PREPARE_BUF
exists
is by trying it, but then you already have prepared a buffer. That's not what
you
want in the application, you need a way to know up front if prepare_buf is
present
or not without having to actually execute it.
CREATE_BUFS was added because not all drivers support it. It can be dropped
since
it is possible to test for the existence of CREATE_BUFS without actually
allocating
anything, but if I'm adding V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF anyway, then it is
trivial to add V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS as well to avoid an additional
ioctl call.
Hmm, I should have explained this in the commit log.
Regards,
Hans
>
>>
>> Signed-off-by: Hans Verkuil
>> ---
>> Note: the flag bits will change since there are two other patches that add
>> flags, so the numbering will change.
>> ---
>> diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
>> b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
>> index d40c60e8..abf925484aff 100644
>> --- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
>> +++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
>> @@ -112,6 +112,8 @@ any DMA in progress, an implicit
>> .. _V4L2-BUF-CAP-SUPPORTS-USERPTR:
>> .. _V4L2-BUF-CAP-SUPPORTS-DMABUF:
>> .. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
>> +.. _V4L2-BUF-CAP-SUPPORTS-PREPARE-BUF:
>> +.. _V4L2-BUF-CAP-SUPPORTS-CREATE-BUFS:
>>
>> .. cssclass:: longtable
>>
>> @@ -132,6 +134,12 @@ any DMA in progress, an implicit
>> * - ``V4L2_BUF_CAP_SUPPORTS_REQUESTS``
>>- 0x0008
>>- This buffer type supports :ref:`requests `.
>> +* - ``V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF``
>> + - 0x0010
>> + - This buffer type supports :ref:`VIDIOC_PREPARE_BUF`.
>> +* - ``V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS``
>> + - 0x0020
>> + - This buffer type supports :ref:`VIDIOC_CREATE_BUFS`.
>>
>> Return Value
>>
>> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> index a17033ab2c22..27c0fafca0bf 100644
>> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> @@ -871,6 +871,16 @@ static inline bool vb2_queue_is_busy(struct
>> video_device *vdev, struct file *fil
>> return vdev->queue->owner && vdev->queue->owner !=
>> file->private_data;D_PACK
>> }
>>
>> +static void fill_buf_caps_vdev(struct video_device *vdev, u32 *caps)
>> +{
>> +*caps = 0;
>> +fill_buf_caps(vdev->queue, caps);
>> +if (vdev->ioctl_ops->vidioc_prepare_buf)
>> +*caps |= V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF;
>> +if (vdev->ioctl_ops->vidioc_create_bufs)
>> +*caps |= V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS;
>> +}
>> +
>> /* vb2 ioctl helpers */
>>
>> int vb2_ioctl_reqbufs(struct file *file, void *priv,
>> @@ -879,7 +889,7 @@ int vb2_ioctl_reqbufs(struct file *file, void *priv,
>> struct video_device *vdev = video_devdata(file);
>> int res = vb2_verify_memory_type(vdev->queue, p->memory, p->type);
>>
>> -fill_buf_caps(vdev->queue, >capabilities);
>> +fill_buf_caps_vdev(vdev, >capabilities);
>> if (res)
>> return res;
>> if (vb2_queue_is_busy(vdev, file))
>> @@ -901,7 +911,7 @@ int vb2_ioctl_create_bufs(struct file *file, void *priv,
>> p->format.type);
>>
>> p->index = vdev->queue->num_buffers;
>> -fill_buf_caps(vdev->queue, >capabilities);
>> +fill_buf_caps_vdev(vdev, >capabilities);
>> /*
>> * If count == 0, then just check if memory and type are valid.
>> * Any -EBUSY result from vb2_verify_memory_type can be mapped to 0.
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index c8e8ff810190..6648f8ba2277 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -879,6 +879,8 @@ struct v4l2_requestbuffers {
>> #define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
>> #define V4L2_BUF_CAP_SUPPORTS_DMABUF(1 << 2)
>> #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
>
> Could you align the previous lines to match the ones below?
>
>> +#define V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF (1 << 4)
>> +#define V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS (1 << 5)
>>
>> /**
>> * struct v4l2_plane - plane info for multi-planar buffers
>
Re: [PATCH] videodev2.h: add V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF/CREATE_BUFS
Hi Hans,
On Tue, Nov 20, 2018 at 09:58:43AM +0100, Hans Verkuil wrote:
> Add new buffer capability flags to indicate if the VIDIOC_PREPARE_BUF or
> VIDIOC_CREATE_BUFS ioctls are supported.
Are there practical benefits from the change for the user space?
>
> Signed-off-by: Hans Verkuil
> ---
> Note: the flag bits will change since there are two other patches that add
> flags, so the numbering will change.
> ---
> diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
> b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
> index d40c60e8..abf925484aff 100644
> --- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
> @@ -112,6 +112,8 @@ any DMA in progress, an implicit
> .. _V4L2-BUF-CAP-SUPPORTS-USERPTR:
> .. _V4L2-BUF-CAP-SUPPORTS-DMABUF:
> .. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
> +.. _V4L2-BUF-CAP-SUPPORTS-PREPARE-BUF:
> +.. _V4L2-BUF-CAP-SUPPORTS-CREATE-BUFS:
>
> .. cssclass:: longtable
>
> @@ -132,6 +134,12 @@ any DMA in progress, an implicit
> * - ``V4L2_BUF_CAP_SUPPORTS_REQUESTS``
>- 0x0008
>- This buffer type supports :ref:`requests `.
> +* - ``V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF``
> + - 0x0010
> + - This buffer type supports :ref:`VIDIOC_PREPARE_BUF`.
> +* - ``V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS``
> + - 0x0020
> + - This buffer type supports :ref:`VIDIOC_CREATE_BUFS`.
>
> Return Value
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index a17033ab2c22..27c0fafca0bf 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -871,6 +871,16 @@ static inline bool vb2_queue_is_busy(struct video_device
> *vdev, struct file *fil
> return vdev->queue->owner && vdev->queue->owner != file->private_data;
> }
>
> +static void fill_buf_caps_vdev(struct video_device *vdev, u32 *caps)
> +{
> + *caps = 0;
> + fill_buf_caps(vdev->queue, caps);
> + if (vdev->ioctl_ops->vidioc_prepare_buf)
> + *caps |= V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF;
> + if (vdev->ioctl_ops->vidioc_create_bufs)
> + *caps |= V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS;
> +}
> +
> /* vb2 ioctl helpers */
>
> int vb2_ioctl_reqbufs(struct file *file, void *priv,
> @@ -879,7 +889,7 @@ int vb2_ioctl_reqbufs(struct file *file, void *priv,
> struct video_device *vdev = video_devdata(file);
> int res = vb2_verify_memory_type(vdev->queue, p->memory, p->type);
>
> - fill_buf_caps(vdev->queue, >capabilities);
> + fill_buf_caps_vdev(vdev, >capabilities);
> if (res)
> return res;
> if (vb2_queue_is_busy(vdev, file))
> @@ -901,7 +911,7 @@ int vb2_ioctl_create_bufs(struct file *file, void *priv,
> p->format.type);
>
> p->index = vdev->queue->num_buffers;
> - fill_buf_caps(vdev->queue, >capabilities);
> + fill_buf_caps_vdev(vdev, >capabilities);
> /*
>* If count == 0, then just check if memory and type are valid.
>* Any -EBUSY result from vb2_verify_memory_type can be mapped to 0.
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index c8e8ff810190..6648f8ba2277 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -879,6 +879,8 @@ struct v4l2_requestbuffers {
> #define V4L2_BUF_CAP_SUPPORTS_USERPTR(1 << 1)
> #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
> #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
Could you align the previous lines to match the ones below?
> +#define V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF(1 << 4)
> +#define V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS(1 << 5)
>
> /**
> * struct v4l2_plane - plane info for multi-planar buffers
--
Kind regards,
Sakari Ailus
sakari.ai...@linux.intel.com
How are you today?
Good Day Dear, I'm Ms Amelia and am new here looking for a serious relationship with someone i can spend the rest of my life with, someone who is loving, caring, honest and faithful to spend the rest of my life with, i came across your profile and its very interesting to me and i would like to know more about you to see if this will work out for both of us...Kindly reply me to know more about each other better. Here is my email address ( mis.ameliahal...@gmail.com ) Love Ms Amelia
[GIT PULL FOR v4.21] mem2mem, venus and vb2 fixes/improvements
The following changes since commit fbe57dde7126d1b2712ab5ea93fb9d15f89de708: media: ov7740: constify structures stored in fields of v4l2_subdev_ops structure (2018-11-06 07:17:02 -0500) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git tags/br-v4.21e for you to fetch changes up to ef1b25960c21848d5bb748296059cab4a4a0ee4c: videobuf2-v4l2: drop WARN_ON in vb2_warn_zero_bytesused() (2018-11-20 10:04:50 +0100) Tag branch Ezequiel Garcia (4): mem2mem: Require capture and output mutexes to match v4l2-ioctl.c: Simplify locking for m2m devices v4l2-mem2mem: Avoid calling .device_run in v4l2_m2m_job_finish media: cedrus: Get rid of interrupt bottom-half Hans Verkuil (1): videobuf2-v4l2: drop WARN_ON in vb2_warn_zero_bytesused() John Sheu (1): media: vb2: Allow reqbufs(0) with "in use" MMAP buffers Sakari Ailus (1): v4l2-mem2mem: Simplify exiting the function in __v4l2_m2m_try_schedule Stanimir Varbanov (1): venus: firmware: register separate platform_device for firmware loader vgaro...@codeaurora.org (4): venus: firmware: add routine to reset ARM9 venus: firmware: move load firmware in a separate function venus: firmware: add no TZ boot and shutdown routine dt-bindings: media: Document bindings for venus firmware device Documentation/devicetree/bindings/media/qcom,venus.txt | 14 ++- Documentation/media/uapi/v4l/vidioc-reqbufs.rst| 17 +++- drivers/media/common/videobuf2/videobuf2-core.c| 8 +- drivers/media/common/videobuf2/videobuf2-v4l2.c| 3 +- drivers/media/platform/qcom/venus/core.c | 24 +++-- drivers/media/platform/qcom/venus/core.h | 6 ++ drivers/media/platform/qcom/venus/firmware.c | 235 +++- drivers/media/platform/qcom/venus/firmware.h | 17 +++- drivers/media/platform/qcom/venus/hfi_venus.c | 13 +-- drivers/media/platform/qcom/venus/hfi_venus_io.h | 8 ++ drivers/media/v4l2-core/v4l2-ioctl.c | 47 +- drivers/media/v4l2-core/v4l2-mem2mem.c | 66 +- drivers/staging/media/sunxi/cedrus/cedrus_hw.c | 26 ++ include/uapi/linux/videodev2.h | 1 + 14 files changed, 344 insertions(+), 141 deletions(-)
[PATCH] videodev2.h: add V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF/CREATE_BUFS
Add new buffer capability flags to indicate if the VIDIOC_PREPARE_BUF or
VIDIOC_CREATE_BUFS ioctls are supported.
Signed-off-by: Hans Verkuil
---
Note: the flag bits will change since there are two other patches that add
flags, so the numbering will change.
---
diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
index d40c60e8..abf925484aff 100644
--- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
+++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
@@ -112,6 +112,8 @@ any DMA in progress, an implicit
.. _V4L2-BUF-CAP-SUPPORTS-USERPTR:
.. _V4L2-BUF-CAP-SUPPORTS-DMABUF:
.. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
+.. _V4L2-BUF-CAP-SUPPORTS-PREPARE-BUF:
+.. _V4L2-BUF-CAP-SUPPORTS-CREATE-BUFS:
.. cssclass:: longtable
@@ -132,6 +134,12 @@ any DMA in progress, an implicit
* - ``V4L2_BUF_CAP_SUPPORTS_REQUESTS``
- 0x0008
- This buffer type supports :ref:`requests `.
+* - ``V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF``
+ - 0x0010
+ - This buffer type supports :ref:`VIDIOC_PREPARE_BUF`.
+* - ``V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS``
+ - 0x0020
+ - This buffer type supports :ref:`VIDIOC_CREATE_BUFS`.
Return Value
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index a17033ab2c22..27c0fafca0bf 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -871,6 +871,16 @@ static inline bool vb2_queue_is_busy(struct video_device
*vdev, struct file *fil
return vdev->queue->owner && vdev->queue->owner != file->private_data;
}
+static void fill_buf_caps_vdev(struct video_device *vdev, u32 *caps)
+{
+ *caps = 0;
+ fill_buf_caps(vdev->queue, caps);
+ if (vdev->ioctl_ops->vidioc_prepare_buf)
+ *caps |= V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF;
+ if (vdev->ioctl_ops->vidioc_create_bufs)
+ *caps |= V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS;
+}
+
/* vb2 ioctl helpers */
int vb2_ioctl_reqbufs(struct file *file, void *priv,
@@ -879,7 +889,7 @@ int vb2_ioctl_reqbufs(struct file *file, void *priv,
struct video_device *vdev = video_devdata(file);
int res = vb2_verify_memory_type(vdev->queue, p->memory, p->type);
- fill_buf_caps(vdev->queue, >capabilities);
+ fill_buf_caps_vdev(vdev, >capabilities);
if (res)
return res;
if (vb2_queue_is_busy(vdev, file))
@@ -901,7 +911,7 @@ int vb2_ioctl_create_bufs(struct file *file, void *priv,
p->format.type);
p->index = vdev->queue->num_buffers;
- fill_buf_caps(vdev->queue, >capabilities);
+ fill_buf_caps_vdev(vdev, >capabilities);
/*
* If count == 0, then just check if memory and type are valid.
* Any -EBUSY result from vb2_verify_memory_type can be mapped to 0.
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index c8e8ff810190..6648f8ba2277 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -879,6 +879,8 @@ struct v4l2_requestbuffers {
#define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
#define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
#define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
+#define V4L2_BUF_CAP_SUPPORTS_PREPARE_BUF (1 << 4)
+#define V4L2_BUF_CAP_SUPPORTS_CREATE_BUFS (1 << 5)
/**
* struct v4l2_plane - plane info for multi-planar buffers
Re: [PATCH 2/2] media: video-i2c: add Melexis MLX90640 thermal camera support
On 11/19/2018 09:54 PM, Matt Ranostay wrote:
> On Mon, Nov 19, 2018 at 6:26 AM Hans Verkuil wrote:
>>
>> On 11/01/2018 05:15 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.
>>>
>>> Signed-off-by: Matt Ranostay
>>> ---
>>> drivers/media/i2c/Kconfig | 1 +
>>> drivers/media/i2c/video-i2c.c | 110 +-
>>> 2 files changed, 110 insertions(+), 1 deletion(-)
>>
>>
>>
>>>
>>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>>> index 704af210e270..4bfb2c66d192 100644
>>> --- a/drivers/media/i2c/Kconfig
>>> +++ b/drivers/media/i2c/Kconfig
>>> @@ -1085,6 +1085,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 6d3b6df0b634..38ade8cb7656 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
>>> +
>>> static int amg88xx_xfer(struct video_i2c_data *data, char *buf)
>>> {
>>> return regmap_bulk_read(data->regmap, AMG88XX_REG_T01L, buf,
>>> data->chip->buffer_size);
>>> }
>>>
>>> +static int mlx90640_xfer(struct video_i2c_data *data, char *buf)
>>> +{
>>> + return regmap_bulk_read(data->regmap, 0x400, buf,
>>> + data->chip->buffer_size);
>>> +}
>>> +
>>> static int amg88xx_setup(struct video_i2c_data *data)
>>> {
>>> unsigned int mask = AMG88XX_FPSC_1FPS;
>>> @@ -141,6 +185,27 @@ static int amg88xx_setup(struct video_i2c_data *data)
>>> return regmap_update_bits(data->regmap, AMG88XX_REG_FPSC, mask, val);
>>> }
>>>
>>> +static int mlx90640_setup(struct video_i2c_data *data)
>>> +{
>>> + unsigned int n, idx;
>>> +
>>> + for (n = 0; n < data->chip->num_frame_intervals - 1; n++) {
>>> + if (data->frame_interval.numerator
>>> + != data->chip->frame_intervals[n].numerator)
>>> + continue;
>>> +
>>> + if (data->frame_interval.denominator
>>> +
