Re: [PATCH 7/9] videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range
Hi Souptick,
On 2018-11-15 16:50, Souptick Joarder wrote:
> Convert to use vm_insert_range to map range of kernel memory
> to user vma.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
Acked-by: Marek Szyprowski
> ---
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 23
> +++
> 1 file changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index 015e737..898adef 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -328,28 +328,19 @@ static unsigned int vb2_dma_sg_num_users(void *buf_priv)
> static int vb2_dma_sg_mmap(void *buf_priv, struct vm_area_struct *vma)
> {
> struct vb2_dma_sg_buf *buf = buf_priv;
> - unsigned long uaddr = vma->vm_start;
> - unsigned long usize = vma->vm_end - vma->vm_start;
> - int i = 0;
> + unsigned long page_count = vma_pages(vma);
> + int err;
>
> if (!buf) {
> printk(KERN_ERR "No memory to map\n");
> return -EINVAL;
> }
>
> - do {
> - int ret;
> -
> - ret = vm_insert_page(vma, uaddr, buf->pages[i++]);
> - if (ret) {
> - printk(KERN_ERR "Remapping memory, error: %d\n", ret);
> - return ret;
> - }
> -
> - uaddr += PAGE_SIZE;
> - usize -= PAGE_SIZE;
> - } while (usize > 0);
> -
> + err = vm_insert_range(vma, vma->vm_start, buf->pages, page_count);
> + if (err) {
> + printk(KERN_ERR "Remapping memory, error: %d\n", err);
> + return err;
> + }
>
> /*
>* Use common vm_area operations to track buffer refcount.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
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 = &isc->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 = &isc->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, &rlp_mode, &dcfg);
> isc->ctrls.hist_stat = HIST_INIT;
> } else {
> - pfe_cfg0 = rawfmt_config->pfe_cfg0_bps;
> +
[PATCH] media: mtk-vcodec: Remove VA from encoder frame buffers
The encoder driver has no need to do any CPU access to the source frame
buffers. Use a separate structure for holding DMA addresses and sizes
for those and remove, so we do not end up introducing any erroneous
dereferences of those VAs.
This fixes DMA-buf import from exporters that do not provide contiguous
kernel mappings, which includes the MTK DRM driver.
Signed-off-by: Tomasz Figa
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 6 +-
drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 5 +
drivers/media/platform/mtk-vcodec/venc_drv_if.h | 2 +-
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 54631ad1c71e..d1f12257bf66 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -1087,7 +1087,6 @@ static void mtk_venc_worker(struct work_struct *work)
src_buf = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
memset(&frm_buf, 0, sizeof(frm_buf));
for (i = 0; i < src_buf->num_planes ; i++) {
- frm_buf.fb_addr[i].va = vb2_plane_vaddr(src_buf, i);
frm_buf.fb_addr[i].dma_addr =
vb2_dma_contig_plane_dma_addr(src_buf, i);
frm_buf.fb_addr[i].size =
@@ -1098,14 +1097,11 @@ static void mtk_venc_worker(struct work_struct *work)
bs_buf.size = (size_t)dst_buf->planes[0].length;
mtk_v4l2_debug(2,
- "Framebuf VA=%p PA=%llx Size=0x%zx;VA=%p PA=0x%llx
Size=0x%zx;VA=%p PA=0x%llx Size=%zu",
- frm_buf.fb_addr[0].va,
+ "Framebuf PA=%llx Size=0x%zx;PA=0x%llx
Size=0x%zx;PA=0x%llx Size=%zu",
(u64)frm_buf.fb_addr[0].dma_addr,
frm_buf.fb_addr[0].size,
- frm_buf.fb_addr[1].va,
(u64)frm_buf.fb_addr[1].dma_addr,
frm_buf.fb_addr[1].size,
- frm_buf.fb_addr[2].va,
(u64)frm_buf.fb_addr[2].dma_addr,
frm_buf.fb_addr[2].size);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
index 06c254f5c171..9bf6e8d1b9c9 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
@@ -25,6 +25,11 @@ struct mtk_vcodec_mem {
dma_addr_t dma_addr;
};
+struct mtk_vcodec_fb {
+ size_t size;
+ dma_addr_t dma_addr;
+};
+
struct mtk_vcodec_ctx;
struct mtk_vcodec_dev;
diff --git a/drivers/media/platform/mtk-vcodec/venc_drv_if.h
b/drivers/media/platform/mtk-vcodec/venc_drv_if.h
index a6e7d32e55cb..55ecda844894 100644
--- a/drivers/media/platform/mtk-vcodec/venc_drv_if.h
+++ b/drivers/media/platform/mtk-vcodec/venc_drv_if.h
@@ -106,7 +106,7 @@ struct venc_enc_param {
* @fb_addr: plane frame buffer addresses
*/
struct venc_frm_buf {
- struct mtk_vcodec_mem fb_addr[MTK_VCODEC_MAX_PLANES];
+ struct mtk_vcodec_fb fb_addr[MTK_VCODEC_MAX_PLANES];
};
/*
--
2.19.1.1215.g8438c0b245-goog
Re: [PATCH] arm64: dts: sdm845: add video nodes
Hi Malathi,
On 2018-11-20 15:38, Malathi Gottam wrote:
This adds video nodes to sdm845 based on the examples
in the bindings.
Signed-off-by: Malathi Gottam
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 34
++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0c9a2aa..d82487d 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -84,6 +84,10 @@
reg = <0 0x8620 0 0x2d0>;
no-map;
};
+ venus_region: venus@9580 {
+ reg = <0x0 0x9580 0x0 0x50>;
+ no-map;
+ };
nit: Please make this venus_region: memory@9580
instead and add a new line before venus_region.
};
cpus {
@@ -1103,5 +1107,35 @@
status = "disabled";
};
};
+
+ video-codec@aa0 {
+ compatible = "qcom,sdm845-venus";
+ reg = <0x0aa0 0xff000>;
+ interrupts = ;
+ power-domains = <&videocc VENUS_GDSC>;
+ clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
+<&videocc VIDEO_CC_VENUS_AHB_CLK>,
+<&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>;
+ clock-names = "core", "iface", "bus";
+ iommus = <&apps_smmu 0x10a0 0x8>,
+<&apps_smmu 0x10b0 0x0>;
+ memory-region = <&venus_region>;
+
+ video-core0 {
+ compatible = "venus-decoder";
+ clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
+<&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
+ clock-names = "core", "bus";
+ power-domains = <&videocc VCODEC0_GDSC>;
+ };
+
+ video-core1 {
+ compatible = "venus-encoder";
+ clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>,
+<&videocc VIDEO_CC_VCODEC1_AXI_CLK>;
+ clock-names = "core", "bus";
+ power-domains = <&videocc VCODEC1_GDSC>;
+ };
+ };
};
};
--
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH 0/9] Use vm_insert_range
On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder wrote: > > Previouly drivers have their own way of mapping range of > kernel pages/memory into user vma and this was done by > invoking vm_insert_page() within a loop. > > As this pattern is common across different drivers, it can > be generalized by creating a new function and use it across > the drivers. > > vm_insert_range is the new API which will be used to map a > range of kernel memory/pages to user vma. > > All the applicable places are converted to use new vm_insert_range > in this patch series. > > Souptick Joarder (9): > mm: Introduce new vm_insert_range API > arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range > drivers/firewire/core-iso.c: Convert to use vm_insert_range > drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range > drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range > iommu/dma-iommu.c: Convert to use vm_insert_range > videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range > xen/gntdev.c: Convert to use vm_insert_range > xen/privcmd-buf.c: Convert to use vm_insert_range Any further comment on driver changes ? > > arch/arm/mm/dma-mapping.c | 21 ++--- > drivers/firewire/core-iso.c | 15 ++-- > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 20 ++-- > drivers/gpu/drm/xen/xen_drm_front_gem.c | 20 +--- > drivers/iommu/dma-iommu.c | 12 ++ > drivers/media/common/videobuf2/videobuf2-dma-sg.c | 23 ++- > drivers/xen/gntdev.c | 11 - > drivers/xen/privcmd-buf.c | 8 ++- > include/linux/mm_types.h | 3 +++ > mm/memory.c | 28 > +++ > mm/nommu.c| 7 ++ > 11 files changed, 70 insertions(+), 98 deletions(-) > > -- > 1.9.1 >
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 @@ +obj-$(CONFIG
[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 = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = <&power RK3399_PD_VCODEC>;
+ iommus = <&vpu_mmu>;
+ };
+
vpu_mmu: iommu@ff650800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff650800 0x0 0x40>;
@@ -1233,8 +1245,8 @@
interrupt-names = "vpu_mmu";
clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = <&power 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 = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = <&power RK3288_PD_VIDEO>;
+ iommus = <&vpu_mmu>;
+ };
+
vpu_mmu: iommu@ff9a0800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff9a0800 0x0 0x100>;
@@ -1230,8 +1242,8 @@
interrupt-names = "vpu_mmu";
clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = <&power 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 VIDIOC_EXPBU
[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 = &isc->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 = &isc->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, &rlp_mode, &dcfg);
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(&format.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))
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 v4 3/4] media: i2c: Add MAX9286 driver
Hi Luca,
On Tue, Nov 20, 2018 at 11:51:37AM +0100, Luca Ceresoli wrote:
> Hi Kieran,
>
> On 20/11/18 01:32, Kieran Bingham wrote:
> > Hi Luca,
> >
> > My apologies for my travel induced delay in responding here,
>
> No problem.
>
> > On 14/11/2018 02:04, Luca Ceresoli wrote:
> [...]
> > +static int max9286_probe(struct i2c_client *client,
> > +const struct i2c_device_id *did)
> > +{
> > + struct max9286_device *dev;
> > + unsigned int i;
> > + int ret;
> > +
> > + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> > + if (!dev)
> > + return -ENOMEM;
> > +
> > + dev->client = client;
> > + i2c_set_clientdata(client, dev);
> > +
> > + for (i = 0; i < MAX9286_N_SINKS; i++)
> > + max9286_init_format(&dev->fmt[i]);
> > +
> > + ret = max9286_parse_dt(dev);
> > + if (ret)
> > + return ret;
> > +
> > + dev->regulator = regulator_get(&client->dev, "poc");
> > + if (IS_ERR(dev->regulator)) {
> > + if (PTR_ERR(dev->regulator) != -EPROBE_DEFER)
> > + dev_err(&client->dev,
> > + "Unable to get PoC regulator (%ld)\n",
> > + PTR_ERR(dev->regulator));
> > + ret = PTR_ERR(dev->regulator);
> > + goto err_free;
> > + }
> > +
> > + /*
> > +* We can have multiple MAX9286 instances on the same physical
> > I2C
> > +* bus, and I2C children behind ports of separate MAX9286
> > instances
> > +* having the same I2C address. As the MAX9286 starts by
> > default with
> > +* all ports enabled, we need to disable all ports on all
> > MAX9286
> > +* instances before proceeding to further initialize the
> > devices and
> > +* instantiate children.
> > +*
> > +* Start by just disabling all channels on the current device.
> > Then,
> > +* if all other MAX9286 on the parent bus have been probed,
> > proceed
> > +* to initialize them all, including the current one.
> > +*/
> > + max9286_i2c_mux_close(dev);
> > +
> > + /*
> > +* The MAX9286 initialises with auto-acknowledge enabled by
> > default.
> > +* This means that if multiple MAX9286 devices are connected to
> > an I2C
> > +* bus, another MAX9286 could ack I2C transfers meant for a
> > device on
> > +* the other side of the GMSL links for this MAX9286 (such as a
> > +* MAX9271). To prevent that disable auto-acknowledge early on;
> > it
> > +* will be enabled later as needed.
> > +*/
> > + max9286_configure_i2c(dev, false);
> > +
> > + ret = device_for_each_child(client->dev.parent, &client->dev,
> > + max9286_is_bound);
> > + if (ret)
> > + return 0;
> > +
> > + dev_dbg(&client->dev,
> > + "All max9286 probed: start initialization sequence\n");
> > + ret = device_for_each_child(client->dev.parent, NULL,
> > + max9286_init);
>
> I can't manage to like this initialization sequence, sorry. If at all
> possible, each max9286 should initialize itself independently from each
> other, like any normal driver.
> >>>
> >>> Yes, I think we're in agreement here, but unfortunately this section is
> >>> a workaround for the fact that our devices share a common address space.
> >>>
> >>> We (currently) *must* disable both devices before we start the
> >>> initialisation process for either on our platform currently...
> >>
> >> The model I proposed in my review to patch 1/4 (split remote physical
> >> address from local address pool) allows to avoid this workaround.
> >
> >
> > Having just talked this through with Jacopo I think I see that we have
> > two topics getting intertwined here too.
> >
> > - Address translation so that we can separate the camera addressing
> >
> > - our 'device_is_bound/device_for_each_child()' workaround which lets
> >us make sure the buses are closed before we power on any camera
> >device.
> >
> >
> > For the upstream process of this driver - I will remove the
> > 'device_is_bound()/device_for_each_child()' workarounds.
> >
> >
> > It is /ugly/ and needs more consideration, but I believe we do still
> > need it (or something similar) for our platform currently.
> >
> >
> >
> > The other side of that is the address translation. I think I was wrong
> > earlier and may have said we have address translation on both sides.
> >
> >
> > I think I now see that we only have some minimal translation for two
>
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;
> > > + _pll_mu
Re: [GIT PULL for v4.20-rc4] media fixes
The pull request you sent on Tue, 20 Nov 2018 09:03:44 -0200: > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > tags/media/v4.20-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/06e68fed32826b44aa9ffcf282c14d3c58918a70 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: DVB-S PCI card regression on 4.19 / 4.20
Em Tue, 20 Nov 2018 14:20:01 +0100 stakanov escreveu: > In data martedì 20 novembre 2018 13:42:17 CET, Mauro Carvalho Chehab ha > scritto: > > Em Tue, 20 Nov 2018 13:11:58 +0100 > > > > "Stakanov Schufter" escreveu: > > > Sorry for the delay. Apparently my smtp exits are blocking me (for > > > whatever reason). I am trying now via web mailer. > > > > > > > > > In short, no it does not work. Only EPG, no pic no sound. > > > But the error message in dmesg is gone I think. > > > > > > uname -a > > > Linux silversurfer 4.20.0-rc3-2.gfe5d771-default #1 SMP PREEMPT Tue Nov 20 > > > 09:35:04 UTC 2018 (fe5d771) x86_64 x86_64 x86_64 GNU > > > > > > dmesg: > > > > > > [6.412792] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver > > > chip loaded successfully > > > [6.416645] flexcop-pci: will use the HW PID filter. > > > [6.416648] flexcop-pci: card revision 2 > > > [6.423749] scsi host10: usb-storage 9-3.1:1.0 > > > [6.423842] usbcore: registered new interface driver usb-storage > > > [6.426029] usbcore: registered new interface driver uas > > > [6.439251] dvbdev: DVB: registering new adapter (FlexCop Digital TV > > > device) > > > [6.440845] b2c2-flexcop: MAC address = 00:d0:d7:11:8b:58 > > > > > > [6.694999] dvb_pll_attach: delsys: 0, frequency range: > > > 95000..215000 > > > [6.695001] b2c2-flexcop: found 'ST STV0299 DVB-S' . > > > [6.695004] b2c2_flexcop_pci :06:06.0: DVB: registering adapter 0 > > > frontend 0 (ST STV0299 DVB-S)... > > > [6.695050] b2c2-flexcop: initialization of 'Sky2PC/SkyStar 2 DVB-S rev > > > 2.6' at the 'PCI' bus controlled by a 'FlexCopIIb' complete > > > > Well, the Kernel bug is probably gone. I don't see any other recent > > changes that would be affecting the b2c2 flexcop driver. > > > > If you're successfully getting EPG data from the transponders, then it > > should also be receiving audio and video channels too, as, for the Kernel, > > there's no difference if a given program ID (PID) contains EPG, audio or > > video. > > > > At the BZ, you're saying that you're using Kaffeine, right? > > > > There are a few reasons why you can't watch audio/video, but you're > > able to get EPG tables: > > > > - the audio/video PID had changed; > > - the audio/video is now encrypted; > > - too weak signal (or bad cabling). > > > > The EPG data comes several times per second on well known PIDs, via a low > > bandwidth PID and it is not encrypted. So, it is usually trivial to get > > it. > > > > I suggest you to re-scan your channels on Kaffeine, in order to force > > it to get the new PIDs. Also, please check that the channels you're > > trying to use are Free to the Air (FTA). > > > > You can also use libdvbv5 tools in order to check if you're not > > losing data due to weak signal/bad cabling. The newer versions > > of dvbv5-zap have a logic with detects and report data loses, when > > started on monitor mode (-m command line option). It also prints > > the transponder bandwidth, and check what PIDs are received. > > > > It is very useful to debug problems. > > > > Thanks, > > Mauro > > I checked again and: > [sudo] password di root: > [6.412792] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver > chip > loaded successfully > [6.440845] b2c2-flexcop: MAC address = 00:d0:d7:11:8b:58 > [6.695001] b2c2-flexcop: found 'ST STV0299 DVB-S' . > [6.695004] b2c2_flexcop_pci :06:06.0: DVB: registering adapter 0 > frontend 0 (ST STV0299 DVB-S)... > [6.695050] b2c2-flexcop: initialization of 'Sky2PC/SkyStar 2 DVB-S rev > 2.6' at the 'PCI' bus controlled by a 'FlexCopIIb' complete > [ 6265.403360] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 > frequency 10719000 out of range (95..215) > [ 6265.405702] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 > frequency 10723000 out of range (95..215) > [ 6265.407120] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 > frequency 10757000 out of range (95..215) > [ 6265.408556] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 > frequency 10775000 out of range (95..215) > [ 6265.409754] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 > frequency 10795000 out of range (95..215) > [ 6399.837806] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 > frequency 12713000 out of range (95..215) > [ 6399.839144] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 > frequency 12731000 out of range (95..215) Ok. Now, min/max frequencies are at the same scale. For DVB-S, dvb_frontend_get_frequency_limits() returns both in kHz, so the frequency range is now OK. The tuning frequency is wrong through. 10,719,000 kHz - e. g. 10,719 MHz seems to be the transponder frequency you're trying to tune, and not the intermediate frequency used at the DVB-S board. That sounds to me either a wrong LNBf setting or a bug at libdvbv5
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 a/drivers/staging/media/rockc
Re: [linux-sunxi] [PATCH v12 2/2] media: V3s: Add support for Allwinner CSI.
On Tue, Nov 20, 2018 at 06:27:48PM +0530, Jagan Teki wrote:
> On Mon, Nov 19, 2018 at 5:38 PM Jagan Teki wrote:
> >
> > On Tue, Oct 30, 2018 at 1:49 PM Yong Deng wrote:
> > >
> > > Allwinner V3s SoC features a CSI module with parallel interface.
> > >
> > > This patch implement a v4l2 framework driver for it.
> > >
> > > Reviewed-by: Hans Verkuil
> > > Reviewed-by: Maxime Ripard
> > > Tested-by: Maxime Ripard
> > > Signed-off-by: Yong Deng
> > > ---
> > > MAINTAINERS| 8 +
> > > 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 | 915
> > > +
> > > 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 +
> > > 10 files changed, 1985 insertions(+)
> > > 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
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 23021e0df5d7..42d73b35ed3e 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -3900,6 +3900,14 @@ M: Jaya Kumar
> > > S: Maintained
> > > F: sound/pci/cs5535audio/
> > >
> > > +CSI DRIVERS FOR ALLWINNER V3s
> > > +M: Yong Deng
> > > +L: linux-media@vger.kernel.org
> > > +T: git git://linuxtv.org/media_tree.git
> > > +S: Maintained
> > > +F: drivers/media/platform/sunxi/sun6i-csi/
> > > +F: Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > +
> > > CW1200 WLAN driver
> > > M: Solomon Peachy
> > > S: Maintained
> > > diff --git a/drivers/media/platform/Kconfig
> > > b/drivers/media/platform/Kconfig
> > > index 0edacfb01f3a..be6626ed0ec8 100644
> > > --- a/drivers/media/platform/Kconfig
> > > +++ b/drivers/media/platform/Kconfig
> > > @@ -138,6 +138,7 @@ source "drivers/media/platform/am437x/Kconfig"
> > > source "drivers/media/platform/xilinx/Kconfig"
> > > source "drivers/media/platform/rcar-vin/Kconfig"
> > > source "drivers/media/platform/atmel/Kconfig"
> > > +source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
> >
> > [snip]
> >
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int sun6i_subdev_notify_complete(struct v4l2_async_notifier
> > > *notifier)
> > > +{
> > > + struct sun6i_csi *csi = container_of(notifier, struct sun6i_csi,
> > > +notifier);
> > > + struct v4l2_device *v4l2_dev = &csi->v4l2_dev;
> > > + struct v4l2_subdev *sd;
> > > + int ret;
> > > +
> > > + dev_dbg(csi->dev, "notify complete, all subdevs registered\n");
> > > +
> > > + if (notifier->num_subdevs != 1)
> >
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c: In function
> > ‘sun6i_subdev_notify_complete’:
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c:646:14: error:
> > ‘struct v4l2_async_notifier’ has no member named ‘num_subdevs’
>
> This build issues on linux-next, let me know you have next version
> changes for this, thanks.
I've applied Maxime's fixes to the patch that went in:
https://git.linuxtv.org/sailus/media_tree.git/commit/?id=78d1d55a4fe1f82b83278c93803fbdf6226f698f>
--
Sakari Ailus
sakari.ai...@linux.intel.com
Re: [linux-sunxi] [PATCH v12 2/2] media: V3s: Add support for Allwinner CSI.
On Tue, Nov 20, 2018 at 06:27:48PM +0530, Jagan Teki wrote:
> On Mon, Nov 19, 2018 at 5:38 PM Jagan Teki wrote:
> >
> > On Tue, Oct 30, 2018 at 1:49 PM Yong Deng wrote:
> > >
> > > Allwinner V3s SoC features a CSI module with parallel interface.
> > >
> > > This patch implement a v4l2 framework driver for it.
> > >
> > > Reviewed-by: Hans Verkuil
> > > Reviewed-by: Maxime Ripard
> > > Tested-by: Maxime Ripard
> > > Signed-off-by: Yong Deng
> > > ---
> > > MAINTAINERS| 8 +
> > > 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 | 915
> > > +
> > > 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 +
> > > 10 files changed, 1985 insertions(+)
> > > 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
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 23021e0df5d7..42d73b35ed3e 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -3900,6 +3900,14 @@ M: Jaya Kumar
> > > S: Maintained
> > > F: sound/pci/cs5535audio/
> > >
> > > +CSI DRIVERS FOR ALLWINNER V3s
> > > +M: Yong Deng
> > > +L: linux-media@vger.kernel.org
> > > +T: git git://linuxtv.org/media_tree.git
> > > +S: Maintained
> > > +F: drivers/media/platform/sunxi/sun6i-csi/
> > > +F: Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > +
> > > CW1200 WLAN driver
> > > M: Solomon Peachy
> > > S: Maintained
> > > diff --git a/drivers/media/platform/Kconfig
> > > b/drivers/media/platform/Kconfig
> > > index 0edacfb01f3a..be6626ed0ec8 100644
> > > --- a/drivers/media/platform/Kconfig
> > > +++ b/drivers/media/platform/Kconfig
> > > @@ -138,6 +138,7 @@ source "drivers/media/platform/am437x/Kconfig"
> > > source "drivers/media/platform/xilinx/Kconfig"
> > > source "drivers/media/platform/rcar-vin/Kconfig"
> > > source "drivers/media/platform/atmel/Kconfig"
> > > +source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
> >
> > [snip]
> >
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int sun6i_subdev_notify_complete(struct v4l2_async_notifier
> > > *notifier)
> > > +{
> > > + struct sun6i_csi *csi = container_of(notifier, struct sun6i_csi,
> > > +notifier);
> > > + struct v4l2_device *v4l2_dev = &csi->v4l2_dev;
> > > + struct v4l2_subdev *sd;
> > > + int ret;
> > > +
> > > + dev_dbg(csi->dev, "notify complete, all subdevs registered\n");
> > > +
> > > + if (notifier->num_subdevs != 1)
> >
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c: In function
> > ‘sun6i_subdev_notify_complete’:
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c:646:14: error:
> > ‘struct v4l2_async_notifier’ has no member named ‘num_subdevs’
>
> This build issues on linux-next, let me know you have next version
> changes for this, thanks.
This driver has been merged now, and you have a fix on the thread
starting from the cover letter of that very same version.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [linux-sunxi] [PATCH v12 2/2] media: V3s: Add support for Allwinner CSI.
On Mon, Nov 19, 2018 at 5:38 PM Jagan Teki wrote:
>
> On Tue, Oct 30, 2018 at 1:49 PM Yong Deng wrote:
> >
> > Allwinner V3s SoC features a CSI module with parallel interface.
> >
> > This patch implement a v4l2 framework driver for it.
> >
> > Reviewed-by: Hans Verkuil
> > Reviewed-by: Maxime Ripard
> > Tested-by: Maxime Ripard
> > Signed-off-by: Yong Deng
> > ---
> > MAINTAINERS| 8 +
> > 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 | 915
> > +
> > 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 +
> > 10 files changed, 1985 insertions(+)
> > 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
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 23021e0df5d7..42d73b35ed3e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3900,6 +3900,14 @@ M: Jaya Kumar
> > S: Maintained
> > F: sound/pci/cs5535audio/
> >
> > +CSI DRIVERS FOR ALLWINNER V3s
> > +M: Yong Deng
> > +L: linux-media@vger.kernel.org
> > +T: git git://linuxtv.org/media_tree.git
> > +S: Maintained
> > +F: drivers/media/platform/sunxi/sun6i-csi/
> > +F: Documentation/devicetree/bindings/media/sun6i-csi.txt
> > +
> > CW1200 WLAN driver
> > M: Solomon Peachy
> > S: Maintained
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index 0edacfb01f3a..be6626ed0ec8 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -138,6 +138,7 @@ source "drivers/media/platform/am437x/Kconfig"
> > source "drivers/media/platform/xilinx/Kconfig"
> > source "drivers/media/platform/rcar-vin/Kconfig"
> > source "drivers/media/platform/atmel/Kconfig"
> > +source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
>
> [snip]
>
> > +
> > + return 0;
> > +}
> > +
> > +static int sun6i_subdev_notify_complete(struct v4l2_async_notifier
> > *notifier)
> > +{
> > + struct sun6i_csi *csi = container_of(notifier, struct sun6i_csi,
> > +notifier);
> > + struct v4l2_device *v4l2_dev = &csi->v4l2_dev;
> > + struct v4l2_subdev *sd;
> > + int ret;
> > +
> > + dev_dbg(csi->dev, "notify complete, all subdevs registered\n");
> > +
> > + if (notifier->num_subdevs != 1)
>
> drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c: In function
> ‘sun6i_subdev_notify_complete’:
> drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c:646:14: error:
> ‘struct v4l2_async_notifier’ has no member named ‘num_subdevs’
This build issues on linux-next, let me know you have next version
changes for this, thanks.
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: [RFC PATCH v8 4/4] sound/usb: Use Media Controller API to share media resources
On 11/02/2018 01:31 AM, sh...@kernel.org wrote:
> From: Shuah Khan
>
> Change ALSA driver to use Media Controller API to share media resources
> with DVB, and V4L2 drivers on a AU0828 media device.
>
> Media Controller specific initialization is done after sound card is
> registered. ALSA creates Media interface and entity function graph
> nodes for Control, Mixer, PCM Playback, and PCM Capture devices.
>
> snd_usb_hw_params() will call Media Controller enable source handler
> interface to request the media resource. If resource request is granted,
> it will release it from snd_usb_hw_free(). If resource is busy, -EBUSY is
> returned.
>
> Media specific cleanup is done in usb_audio_disconnect().
>
> Signed-off-by: Shuah Khan
> ---
> sound/usb/Kconfig| 4 +
> sound/usb/Makefile | 2 +
> sound/usb/card.c | 14 ++
> sound/usb/card.h | 3 +
> sound/usb/media.c| 320 +++
> sound/usb/media.h| 73 +
> sound/usb/mixer.h| 3 +
> sound/usb/pcm.c | 29 +++-
> sound/usb/quirks-table.h | 1 +
> sound/usb/stream.c | 2 +
> sound/usb/usbaudio.h | 6 +
> 11 files changed, 453 insertions(+), 4 deletions(-)
> create mode 100644 sound/usb/media.c
> create mode 100644 sound/usb/media.h
>
> diff --git a/sound/usb/Kconfig b/sound/usb/Kconfig
> index f61b5662bb89..6319b544ba3a 100644
> --- a/sound/usb/Kconfig
> +++ b/sound/usb/Kconfig
> @@ -15,6 +15,7 @@ config SND_USB_AUDIO
> select SND_RAWMIDI
> select SND_PCM
> select BITREVERSE
> + select SND_USB_AUDIO_USE_MEDIA_CONTROLLER if MEDIA_CONTROLLER &&
> (MEDIA_SUPPORT=y || MEDIA_SUPPORT=SND_USB_AUDIO)
> help
> Say Y here to include support for USB audio and USB MIDI
> devices.
> @@ -22,6 +23,9 @@ config SND_USB_AUDIO
> To compile this driver as a module, choose M here: the module
> will be called snd-usb-audio.
>
> +config SND_USB_AUDIO_USE_MEDIA_CONTROLLER
> + bool
> +
> config SND_USB_UA101
> tristate "Edirol UA-101/UA-1000 driver"
> select SND_PCM
> diff --git a/sound/usb/Makefile b/sound/usb/Makefile
> index d330f74c90e6..e1ce257ab705 100644
> --- a/sound/usb/Makefile
> +++ b/sound/usb/Makefile
> @@ -18,6 +18,8 @@ snd-usb-audio-objs := card.o \
> quirks.o \
> stream.o
>
> +snd-usb-audio-$(CONFIG_SND_USB_AUDIO_USE_MEDIA_CONTROLLER) += media.o
> +
> snd-usbmidi-lib-objs := midi.o
>
> # Toplevel Module Dependency
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index 2bfe4e80a6b9..d9ae331280a2 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -68,6 +68,7 @@
> #include "format.h"
> #include "power.h"
> #include "stream.h"
> +#include "media.h"
>
> MODULE_AUTHOR("Takashi Iwai ");
> MODULE_DESCRIPTION("USB Audio");
> @@ -673,6 +674,11 @@ static int usb_audio_probe(struct usb_interface *intf,
> if (err < 0)
> goto __error;
>
> + if (quirk && quirk->media_device) {
> + /* don't want to fail when media_snd_device_create() fails */
> + media_snd_device_create(chip, intf);
I'd change the prefix to snd_media_device_create. After all, you are creating
a media_device for a sound device.
> + }
> +
> usb_chip[chip->index] = chip;
> chip->num_interfaces++;
> usb_set_intfdata(intf, chip);
> @@ -729,6 +735,14 @@ static void usb_audio_disconnect(struct usb_interface
> *intf)
> list_for_each(p, &chip->midi_list) {
> snd_usbmidi_disconnect(p);
> }
> + /*
> + * Nice to check quirk && quirk->media_device and
> + * then call media_snd_device_delete(). Don't have
> + * access to quirk here. media_snd_device_delete()
> + * acceses mixer_list
acceses -> accesses
> + */
> + media_snd_device_delete(chip);
> +
> /* release mixer resources */
> list_for_each_entry(mixer, &chip->mixer_list, list) {
> snd_usb_mixer_disconnect(mixer);
> diff --git a/sound/usb/card.h b/sound/usb/card.h
> index ac785d15ced4..5dd3538ed6b5 100644
> --- a/sound/usb/card.h
> +++ b/sound/usb/card.h
> @@ -108,6 +108,8 @@ struct snd_usb_endpoint {
> struct list_head list;
> };
>
> +struct media_ctl;
> +
> struct snd_usb_substream {
> struct snd_usb_stream *stream;
> struct usb_device *dev;
> @@ -160,6 +162,7 @@ struct snd_usb_substream {
> } dsd_dop;
>
> bool trigger_tstamp_pending_update; /* trigger timestamp being updated
> from initial estimate */
> + struct media_ctl *media_ctl;
> };
>
> struct snd_usb_stream {
> diff --git a/sound/usb/media.c b/sound/usb/media.c
> new file mode 100644
> index ..140a98eed294
> --- /dev/null
> +++ b/sound/usb/media.c
> @@ -0,0 +1,320 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
>
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
[PATCH] media: davinci_vpfe: bail out if kmalloc failed
The kmalloc is passed indirectly to from but with an offset
which if not 0 will cause the null check if (to && from && size)
to succeed. An explicit !NULL check is thus added for params here.
ipipe_s_config and ipipe_g_config - both fail to check kmalloc
are called from ipipe_ioctl where a negative return is a valid
indication of error so simply setting rval = -ENOMEM seems ok.
Signed-off-by: Nicholas Mc Guire
Fixes: da43b6ccadcf ("[media] davinci: vpfe: dm365: add IPIPE support for media
controller driver")
---
Problem located with experimental coccinelle patch
Patch was compile tested with: davinci_all_defconfig + SAGING=y,
STAGING_MEDIA=y, MEDIA_SUPPORT=m, MEDIA_CONTROLLER=y,
VIDEO_V4L2_SUBDEV_API=y, VIDEO_DAVINCI_VPBE_DISPLAY=m,
VIDEO_DM365_VPFE=m
(with some coccicheck findings unrelated to the proposed change)
Patch is against 4.20-rc3 (localversion-next is next-20181120)
drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 3d910b8..0150aed 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1266,6 +1266,11 @@ static int ipipe_s_config(struct v4l2_subdev *sd, struct
vpfe_ipipe_config *cfg)
params = kmalloc(sizeof(struct ipipe_module_params),
GFP_KERNEL);
+ if (!params) {
+ rval = -ENOMEM;
+ goto error;
+ }
+
to = (void *)params + module_if->param_offset;
size = module_if->param_size;
@@ -1308,6 +1313,11 @@ static int ipipe_g_config(struct v4l2_subdev *sd, struct
vpfe_ipipe_config *cfg)
params = kmalloc(sizeof(struct ipipe_module_params),
GFP_KERNEL);
+ if (!params) {
+ rval = -ENOMEM;
+ goto error;
+ }
+
from = (void *)params + module_if->param_offset;
size = module_if->param_size;
--
2.1.4
Re: DVB-S PCI card regression on 4.19 / 4.20
Em Tue, 20 Nov 2018 12:11:03 +0100 Takashi Iwai escreveu: > On Tue, 20 Nov 2018 11:26:04 +0100, > Mauro Carvalho Chehab wrote: > > > > Em Tue, 20 Nov 2018 10:54:22 +0100 > > Takashi Iwai escreveu: > > > > > On Tue, 20 Nov 2018 10:51:59 +0100, > > > stakanov wrote: > > > > > > > > In data martedì 20 novembre 2018 10:18:10 CET, Mauro Carvalho Chehab ha > > > > scritto: > > > > > Em Tue, 20 Nov 2018 09:07:57 +0100 > > > > > > > > > > stakanov escreveu: > > > > > > In data martedì 20 novembre 2018 00:58:41 CET, Mauro Carvalho > > > > > > Chehab ha > > > > > > > > > > > > scritto: > > > > > > > Em Tue, 20 Nov 2018 00:19:54 +0100 > > > > > > > > > > > > > > stakanov escreveu: > > > > > > > > In data martedì 20 novembre 2018 00:08:45 CET, Mauro Carvalho > > > > > > > > Chehab > > > > > > > > ha > > > > > > > > > > > > > > > > scritto: > > > > > > > > > uname -a > > > > > > > > > > > > > > > > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP > > > > > > > > > > PREEMPT > > > > > > > > > > Mon > > > > > > > > > > Nov 19 > > > > > > > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux > > > > > > > > > > > > > > > > > > > > > > > > > > uname -a > > > > > > > > > > > > > > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP > > > > > > > > > PREEMPT Mon > > > > > > > > > Nov > > > > > > > > > 19 > > > > > > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux > > > > > > > > > > > > > > > > from > > > > > > > > https://download.opensuse.org/repositories/home:/tiwai:/bsc1116374/ > > > > > > > > standard/x86_64/ > > > > > > > > > > > > > > > > So I booted this one, should be the right one. > > > > > > > > sudo dmesg | grep -i b2c2 should give these additional > > > > > > > > messages? > > > > > > > > > > > > > > > > If Takashi is still around, he could confirm. > > > > > > > > > > > > > > Well, if the patch got applied, you should now be getting > > > > > > > messages > > > > > > > similar > > > > > > > > > > > > > > (but not identical) to: > > > > > > > dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > > > 915...215, > > > > > > > > > > > > > > frontend: 915...215 dvb_pll_attach: delsys: 5, frequency > > > > > > > range: > > > > > > > 915..215 > > > > > > > > > > > > > > > _ > > > > > > > > > > > > > > > > Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt > > > > > > > > wechseln > > > > > > > > und > > > > > > > > alte E-Mail-Adresse mitnehmen! https://www.eclipso.de > > > > > > > > > > > > > > Thanks, > > > > > > > Mauro > > > > > > > > > > > > My bad. > > > > > > With just dmesg: > > > > > > > > > > > > [ 89.399887] dvb_frontend_get_frequency_limits: frequencies: > > > > > > tuner: > > > > > > 95...215, frontend: 95000...215000 > > > > > > [ 95.020149] dvb_frontend_get_frequency_limits: frequencies: > > > > > > tuner: > > > > > > 95...215, frontend: 95000...215000 > > > > > > [ 95.152049] dvb_frontend_get_frequency_limits: frequencies: > > > > > > tuner: > > > > > > 95...215, frontend: 95000...215000 > > > > > > [ 95.152058] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 > > > > > > frontend 0 > > > > > > frequency 188 out of range (95..2150) > > > > > > [ 98.356539] dvb_frontend_get_frequency_limits: frequencies: > > > > > > tuner: > > > > > > 95...215, frontend: 95000...215000 > > > > > > [ 98.480372] dvb_frontend_get_frequency_limits: frequencies: > > > > > > tuner: > > > > > > 95...215, frontend: 95000...215000 > > > > > > [ 98.480381] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 > > > > > > frontend 0 > > > > > > frequency 1587500 out of range (95..2150) > > > > > > [ 100.016823] dvb_frontend_get_frequency_limits: frequencies: > > > > > > tuner: > > > > > > 95...215, frontend: 95000...215000 > > > > > > [ 100.140619] dvb_frontend_get_frequency_limits: frequencies: > > > > > > tuner: > > > > > > 95...215, frontend: 95000...215000 > > > > > > [ 100.140629] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 > > > > > > frontend 0 > > > > > > frequency 1353500 out of range (95..2150) > > > > > > [ 105.361166] dvb_frontend_get_frequency_limits: frequencies: > > > > > > tuner: > > > > > > 95...215, frontend: 95000...215000 > > > > > > [ 105.492972] dvb_frontend_get_frequency_limits: frequencies: > > > > > > tuner: > > > > > > 95...215, frontend: 95000...215000 > > > > > > [ 105.492977] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 > > > > > > frontend 0 > > > > > > frequency 1944750 out of range (95..2150) > > > > > > > > > > > > > > > > > > Which is, I guess the info you need? > > > > > > > > > > Yes, pa
Re: [RFC PATCH v8 3/4] media: media.h: Enable ALSA MEDIA_INTF_T* interface types
On 11/02/2018 01:31 AM, sh...@kernel.org wrote:
> From: Shuah Khan
>
> Move ALSA MEDIA_INTF_T* interface types back into __KERNEL__ scope
> to get ready for adding ALSA support to the media controller.
>
> Signed-off-by: Shuah Khan
> ---
> include/uapi/linux/media.h | 25 ++---
> 1 file changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 36f76e777ef9..07be07263597 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -262,6 +262,16 @@ struct media_links_enum {
> #define MEDIA_INTF_T_V4L_SWRADIO (MEDIA_INTF_T_V4L_BASE + 4)
> #define MEDIA_INTF_T_V4L_TOUCH (MEDIA_INTF_T_V4L_BASE
> + 5)
>
> +#define MEDIA_INTF_T_ALSA_BASE 0x0300
> +#define MEDIA_INTF_T_ALSA_PCM_CAPTURE(MEDIA_INTF_T_ALSA_BASE)
> +#define MEDIA_INTF_T_ALSA_PCM_PLAYBACK (MEDIA_INTF_T_ALSA_BASE
> + 1)
> +#define MEDIA_INTF_T_ALSA_CONTROL(MEDIA_INTF_T_ALSA_BASE + 2)
> +#define MEDIA_INTF_T_ALSA_COMPRESS (MEDIA_INTF_T_ALSA_BASE + 3)
> +#define MEDIA_INTF_T_ALSA_RAWMIDI(MEDIA_INTF_T_ALSA_BASE + 4)
> +#define MEDIA_INTF_T_ALSA_HWDEP (MEDIA_INTF_T_ALSA_BASE
> + 5)
> +#define MEDIA_INTF_T_ALSA_SEQUENCER (MEDIA_INTF_T_ALSA_BASE + 6)
> +#define MEDIA_INTF_T_ALSA_TIMER (MEDIA_INTF_T_ALSA_BASE
> + 7)
> +
I would only enable those defines that you need for the next patch.
Regards,
Hans
> #if defined(__KERNEL__)
>
> /*
> @@ -404,21 +414,6 @@ struct media_v2_topology {
>
> #define MEDIA_ENT_F_DTV_DECODER MEDIA_ENT_F_DV_DECODER
>
> -/*
> - * There is still no ALSA support in the media controller. These
> - * defines should not have been added and we leave them here only
> - * in case some application tries to use these defines.
> - */
> -#define MEDIA_INTF_T_ALSA_BASE 0x0300
> -#define MEDIA_INTF_T_ALSA_PCM_CAPTURE(MEDIA_INTF_T_ALSA_BASE)
> -#define MEDIA_INTF_T_ALSA_PCM_PLAYBACK (MEDIA_INTF_T_ALSA_BASE
> + 1)
> -#define MEDIA_INTF_T_ALSA_CONTROL(MEDIA_INTF_T_ALSA_BASE + 2)
> -#define MEDIA_INTF_T_ALSA_COMPRESS (MEDIA_INTF_T_ALSA_BASE + 3)
> -#define MEDIA_INTF_T_ALSA_RAWMIDI(MEDIA_INTF_T_ALSA_BASE + 4)
> -#define MEDIA_INTF_T_ALSA_HWDEP (MEDIA_INTF_T_ALSA_BASE
> + 5)
> -#define MEDIA_INTF_T_ALSA_SEQUENCER (MEDIA_INTF_T_ALSA_BASE + 6)
> -#define MEDIA_INTF_T_ALSA_TIMER (MEDIA_INTF_T_ALSA_BASE
> + 7)
> -
> /* Obsolete symbol for media_version, no longer used in the kernel */
> #define MEDIA_API_VERSION((0 << 16) | (1 << 8) | 0)
>
>
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: [RFC PATCH v8 1/4] media: Media Device Allocator API
On 11/02/2018 01:31 AM, sh...@kernel.org wrote: > From: Shuah Khan > > Media Device Allocator API to allows multiple drivers share a media device. > Using this API, drivers can allocate a media device with the shared struct > device as the key. Once the media device is allocated by a driver, other > drivers can get a reference to it. The media device is released when all > the references are released. > > Signed-off-by: Shuah Khan > --- > Documentation/media/kapi/mc-core.rst | 37 > drivers/media/Makefile | 3 +- > drivers/media/media-dev-allocator.c | 132 +++ > include/media/media-dev-allocator.h | 53 +++ > 4 files changed, 224 insertions(+), 1 deletion(-) > create mode 100644 drivers/media/media-dev-allocator.c > create mode 100644 include/media/media-dev-allocator.h > > diff --git a/Documentation/media/kapi/mc-core.rst > b/Documentation/media/kapi/mc-core.rst > index 0c05503eaf1f..d6f409598065 100644 > --- a/Documentation/media/kapi/mc-core.rst > +++ b/Documentation/media/kapi/mc-core.rst > @@ -257,8 +257,45 @@ Subsystems should facilitate link validation by > providing subsystem specific > helper functions to provide easy access for commonly needed information, and > in the end provide a way to use driver-specific callbacks. > > +Media Controller Device Allocator API > +^ > + > +When media device belongs to more than one driver, the shared media device When -> When the > +is allocated with the shared struct device as the key for look ups. > + > +Shared media device should stay in registered state until the last driver Shared -> The shared > +unregisters it. In addition, media device should be released when all the media -> the media > +references are released. Each driver gets a reference to the media device > +during probe, when it allocates the media device. If media device is already > +allocated, allocate API bumps up the refcount and return the existing media allocate -> the allocate return -> returns > +device. Driver puts the reference back from its disconnect routine when it Driver -> The driver from -> in > +calls :c:func:`media_device_delete()`. > + > +Media device is unregistered and cleaned up from the kref put handler to Media -> The media from -> in > +ensure that the media device stays in registered state until the last driver > +unregisters the media device. What happens if an application still has the media device open and you forcibly remove the last driver? I think it should be OK since the media_devnode struct isn't freed until the last open filehandle closes. But it is good to test this. > + > +**Driver Usage** > + > +Drivers should use the media-core routines to get register reference and 'get register reference'? Not sure what you meant to say. > +call :c:func:`media_device_delete()` routine to make sure the shared media > +device delete is handled correctly. > + > +**driver probe:** > +Call :c:func:`media_device_usb_allocate()` to allocate or get a reference > +Call :c:func:`media_device_register()`, if media devnode isn't registered > + > +**driver disconnect:** > +Call :c:func:`media_device_delete()` to free the media_device. Free'ing is Free'ing -> Freeing > +handled by the kref put handler. > + > +API Definitions > +^^^ > + > .. kernel-doc:: include/media/media-device.h > > .. kernel-doc:: include/media/media-devnode.h > > .. kernel-doc:: include/media/media-entity.h > + > +.. kernel-doc:: include/media/media-dev-allocator.h > diff --git a/drivers/media/Makefile b/drivers/media/Makefile > index 594b462ddf0e..8608f0a41dca 100644 > --- a/drivers/media/Makefile > +++ b/drivers/media/Makefile > @@ -3,7 +3,8 @@ > # Makefile for the kernel multimedia device drivers. > # > > -media-objs := media-device.o media-devnode.o media-entity.o > +media-objs := media-device.o media-devnode.o media-entity.o \ > +media-dev-allocator.o Perhaps only add media-dev-allocator if CONFIG_USB is enabled? > > # > # I2C drivers should come before other drivers, otherwise they'll fail > diff --git a/drivers/media/media-dev-allocator.c > b/drivers/media/media-dev-allocator.c > new file mode 100644 > index ..262d1293dc13 > --- /dev/null > +++ b/drivers/media/media-dev-allocator.c > @@ -0,0 +1,132 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * media-dev-allocator.c - Media Controller Device Allocator API > + * > + * Copyright (c) 2018 Shuah Khan > + * > + * Credits: Suggested by Laurent Pinchart > + */ > + > +/* > + * This file adds a global refcounted Media Controller Device Instance API. > + * A system wide global media device list is managed and each media device > + * includes a kref count. The last put on the media device releases the media > + * device instance. > + * > + */ > + > +#include > +#include > +#include > +#include > + > +#include > + > +static LIST_HEAD(media_device_list); > +s
Re: DVB-S PCI card regression on 4.19 / 4.20
On Tue, 20 Nov 2018 11:26:04 +0100, Mauro Carvalho Chehab wrote: > > Em Tue, 20 Nov 2018 10:54:22 +0100 > Takashi Iwai escreveu: > > > On Tue, 20 Nov 2018 10:51:59 +0100, > > stakanov wrote: > > > > > > In data martedì 20 novembre 2018 10:18:10 CET, Mauro Carvalho Chehab ha > > > scritto: > > > > Em Tue, 20 Nov 2018 09:07:57 +0100 > > > > > > > > stakanov escreveu: > > > > > In data martedì 20 novembre 2018 00:58:41 CET, Mauro Carvalho Chehab > > > > > ha > > > > > > > > > > scritto: > > > > > > Em Tue, 20 Nov 2018 00:19:54 +0100 > > > > > > > > > > > > stakanov escreveu: > > > > > > > In data martedì 20 novembre 2018 00:08:45 CET, Mauro Carvalho > > > > > > > Chehab > > > > > > > ha > > > > > > > > > > > > > > scritto: > > > > > > > > uname -a > > > > > > > > > > > > > > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP > > > > > > > > > PREEMPT > > > > > > > > > Mon > > > > > > > > > Nov 19 > > > > > > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux > > > > > > > > > > > > > > uname -a > > > > > > > > > > > > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP PREEMPT > > > > > > > > Mon > > > > > > > > Nov > > > > > > > > 19 > > > > > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux > > > > > > > > > > > > > > from > > > > > > > https://download.opensuse.org/repositories/home:/tiwai:/bsc1116374/ > > > > > > > standard/x86_64/ > > > > > > > > > > > > > > So I booted this one, should be the right one. > > > > > > > sudo dmesg | grep -i b2c2 should give these additional messages? > > > > > > > > > > > > > > If Takashi is still around, he could confirm. > > > > > > > > > > > > Well, if the patch got applied, you should now be getting messages > > > > > > similar > > > > > > > > > > > > (but not identical) to: > > > > > > dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > > 915...215, > > > > > > > > > > > > frontend: 915...215 dvb_pll_attach: delsys: 5, frequency > > > > > > range: > > > > > > 915..215 > > > > > > > > > > > > > _ > > > > > > > > > > > > > > Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt > > > > > > > wechseln > > > > > > > und > > > > > > > alte E-Mail-Adresse mitnehmen! https://www.eclipso.de > > > > > > > > > > > > Thanks, > > > > > > Mauro > > > > > > > > > > My bad. > > > > > With just dmesg: > > > > > > > > > > [ 89.399887] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > 95...215, frontend: 95000...215000 > > > > > [ 95.020149] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > 95...215, frontend: 95000...215000 > > > > > [ 95.152049] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > 95...215, frontend: 95000...215000 > > > > > [ 95.152058] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend > > > > > 0 > > > > > frequency 188 out of range (95..2150) > > > > > [ 98.356539] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > 95...215, frontend: 95000...215000 > > > > > [ 98.480372] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > 95...215, frontend: 95000...215000 > > > > > [ 98.480381] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend > > > > > 0 > > > > > frequency 1587500 out of range (95..2150) > > > > > [ 100.016823] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > 95...215, frontend: 95000...215000 > > > > > [ 100.140619] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > 95...215, frontend: 95000...215000 > > > > > [ 100.140629] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend > > > > > 0 > > > > > frequency 1353500 out of range (95..2150) > > > > > [ 105.361166] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > 95...215, frontend: 95000...215000 > > > > > [ 105.492972] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > 95...215, frontend: 95000...215000 > > > > > [ 105.492977] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend > > > > > 0 > > > > > frequency 1944750 out of range (95..2150) > > > > > > > > > > > > > > > Which is, I guess the info you need? > > > > > > > > Yes, partially. Clearly, the problem is coming from the tuner, with is > > > > not reporting the frequency in Hz, but I was hoping to see another > > > > message from the tuner driver, in order for me to be sure about what's > > > > happening there. > > > > > > > > Didn't you get any message that starts with "dvb_pll_attach"? > > > > > > > > The thing with Flexcop is that there are several variations, each one > > > > with a different tuner driver. > > > > > > > > Anyway, I guess I
[GIT PULL for v4.20-rc4] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.20-3 For a series of fixes: - add a missing include at v4l2-controls uAPI header; - minor kAPI update for the request API; - some fixes at CEC core; - use a lower minimum height for the virtual codec driver; - cleanup a gcc warning due to the lack of a fall though markup; - tc358743: Remove unnecessary self assignment - fix the V4L event subscription logic - docs: Document metadata format in struct v4l2_format - omap3isp and ipu3-cio2: fix unbinding logic PS.: I was meant to send this two weeks ago, but LPC/KS trip ended by delaying this pull request. Regards, Mauro - The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.20-3 for you to fetch changes up to 4e26f692e2e2aa4d7d6ddb3c4d3dec17f45d6495: media: ipu3-cio2: Use cio2_queues_exit (2018-11-06 07:11:59 -0500) media fixes for v4.20-rc4 Arnd Bergmann (1): media: v4l: fix uapi mpeg slice params definition Ezequiel Garcia (1): media: Rename vb2_m2m_request_queue -> v4l2_m2m_request_queue Hans Verkuil (3): media: vicodec: lower minimum height to 360 media: cec: check for non-OK/NACK conditions while claiming a LA media: cec: increase debug level for 'queue full' Mauro Carvalho Chehab (3): v4l2-controls: add a missing include Merge tag 'v4.20-rc1' into patchwork media: dm365_ipipeif: better annotate a fall though Nathan Chancellor (1): media: tc358743: Remove unnecessary self assignment Sakari Ailus (5): media: v4l: event: Add subscription to list before calling "add" operation media: docs: Document metadata format in struct v4l2_format media: omap3isp: Unregister media device as first media: ipu3-cio2: Unregister device nodes first, then release resources media: ipu3-cio2: Use cio2_queues_exit Documentation/media/uapi/v4l/dev-meta.rst | 2 +- Documentation/media/uapi/v4l/vidioc-g-fmt.rst | 5 +++ drivers/media/cec/cec-adap.c | 49 +- drivers/media/i2c/tc358743.c | 1 - drivers/media/pci/intel/ipu3/ipu3-cio2.c | 6 +-- drivers/media/platform/omap3isp/isp.c | 3 +- drivers/media/platform/vicodec/vicodec-core.c | 2 +- drivers/media/platform/vim2m.c | 2 +- drivers/media/v4l2-core/v4l2-ctrls.c | 5 +++ drivers/media/v4l2-core/v4l2-event.c | 43 ++- drivers/media/v4l2-core/v4l2-mem2mem.c | 4 +- drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 1 + drivers/staging/media/sunxi/cedrus/cedrus.c| 2 +- include/media/v4l2-mem2mem.h | 2 +- include/uapi/linux/v4l2-controls.h | 5 +++ 15 files changed, 89 insertions(+), 43 deletions(-)
Re: [PATCH v4 3/4] media: i2c: Add MAX9286 driver
Hi Kieran,
On 20/11/18 01:32, Kieran Bingham wrote:
> Hi Luca,
>
> My apologies for my travel induced delay in responding here,
No problem.
> On 14/11/2018 02:04, Luca Ceresoli wrote:
[...]
> +static int max9286_probe(struct i2c_client *client,
> + const struct i2c_device_id *did)
> +{
> + struct max9286_device *dev;
> + unsigned int i;
> + int ret;
> +
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> + if (!dev)
> + return -ENOMEM;
> +
> + dev->client = client;
> + i2c_set_clientdata(client, dev);
> +
> + for (i = 0; i < MAX9286_N_SINKS; i++)
> + max9286_init_format(&dev->fmt[i]);
> +
> + ret = max9286_parse_dt(dev);
> + if (ret)
> + return ret;
> +
> + dev->regulator = regulator_get(&client->dev, "poc");
> + if (IS_ERR(dev->regulator)) {
> + if (PTR_ERR(dev->regulator) != -EPROBE_DEFER)
> + dev_err(&client->dev,
> + "Unable to get PoC regulator (%ld)\n",
> + PTR_ERR(dev->regulator));
> + ret = PTR_ERR(dev->regulator);
> + goto err_free;
> + }
> +
> + /*
> + * We can have multiple MAX9286 instances on the same physical I2C
> + * bus, and I2C children behind ports of separate MAX9286 instances
> + * having the same I2C address. As the MAX9286 starts by default with
> + * all ports enabled, we need to disable all ports on all MAX9286
> + * instances before proceeding to further initialize the devices and
> + * instantiate children.
> + *
> + * Start by just disabling all channels on the current device. Then,
> + * if all other MAX9286 on the parent bus have been probed, proceed
> + * to initialize them all, including the current one.
> + */
> + max9286_i2c_mux_close(dev);
> +
> + /*
> + * The MAX9286 initialises with auto-acknowledge enabled by default.
> + * This means that if multiple MAX9286 devices are connected to an I2C
> + * bus, another MAX9286 could ack I2C transfers meant for a device on
> + * the other side of the GMSL links for this MAX9286 (such as a
> + * MAX9271). To prevent that disable auto-acknowledge early on; it
> + * will be enabled later as needed.
> + */
> + max9286_configure_i2c(dev, false);
> +
> + ret = device_for_each_child(client->dev.parent, &client->dev,
> + max9286_is_bound);
> + if (ret)
> + return 0;
> +
> + dev_dbg(&client->dev,
> + "All max9286 probed: start initialization sequence\n");
> + ret = device_for_each_child(client->dev.parent, NULL,
> + max9286_init);
I can't manage to like this initialization sequence, sorry. If at all
possible, each max9286 should initialize itself independently from each
other, like any normal driver.
>>>
>>> Yes, I think we're in agreement here, but unfortunately this section is
>>> a workaround for the fact that our devices share a common address space.
>>>
>>> We (currently) *must* disable both devices before we start the
>>> initialisation process for either on our platform currently...
>>
>> The model I proposed in my review to patch 1/4 (split remote physical
>> address from local address pool) allows to avoid this workaround.
>
>
> Having just talked this through with Jacopo I think I see that we have
> two topics getting intertwined here too.
>
> - Address translation so that we can separate the camera addressing
>
> - our 'device_is_bound/device_for_each_child()' workaround which lets
>us make sure the buses are closed before we power on any camera
>device.
>
>
> For the upstream process of this driver - I will remove the
> 'device_is_bound()/device_for_each_child()' workarounds.
>
>
> It is /ugly/ and needs more consideration, but I believe we do still
> need it (or something similar) for our platform currently.
>
>
>
> The other side of that is the address translation. I think I was wrong
> earlier and may have said we have address translation on both sides.
>
>
> I think I now see that we only have some minimal translation for two
> addresses on the remote (max9271) side, not the local (max9286) side.
Can the remote (max9271) translate addresses for transactions
originating from the local side? This would make it possible to do a
proper address translation, although 2 addresses is a quite small amount.
BTW all the TI chips I'm looking at can do address translation but, as
far as I understand, only when acting as "slave proxy", i.e. when
attached to the bus master. If the Maxim chips do the same, the "remote
translation" would be unusable.
> We have the ability to reprogram addresses through, and that's what we
> are using.
Sadly, it looks pretty much unavoidable...
> There's a lot more local discussion going on here
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
Re: DVB-S PCI card regression on 4.19 / 4.20
Em Tue, 20 Nov 2018 10:54:22 +0100 Takashi Iwai escreveu: > On Tue, 20 Nov 2018 10:51:59 +0100, > stakanov wrote: > > > > In data martedì 20 novembre 2018 10:18:10 CET, Mauro Carvalho Chehab ha > > scritto: > > > Em Tue, 20 Nov 2018 09:07:57 +0100 > > > > > > stakanov escreveu: > > > > In data martedì 20 novembre 2018 00:58:41 CET, Mauro Carvalho Chehab ha > > > > > > > > scritto: > > > > > Em Tue, 20 Nov 2018 00:19:54 +0100 > > > > > > > > > > stakanov escreveu: > > > > > > In data martedì 20 novembre 2018 00:08:45 CET, Mauro Carvalho Chehab > > > > > > ha > > > > > > > > > > > > scritto: > > > > > > > uname -a > > > > > > > > > > > > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP PREEMPT > > > > > > > > Mon > > > > > > > > Nov 19 > > > > > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux > > > > > > > > > > > > uname -a > > > > > > > > > > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP PREEMPT > > > > > > > Mon > > > > > > > Nov > > > > > > > 19 > > > > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux > > > > > > > > > > > > from > > > > > > https://download.opensuse.org/repositories/home:/tiwai:/bsc1116374/ > > > > > > standard/x86_64/ > > > > > > > > > > > > So I booted this one, should be the right one. > > > > > > sudo dmesg | grep -i b2c2 should give these additional messages? > > > > > > > > > > > > If Takashi is still around, he could confirm. > > > > > > > > > > Well, if the patch got applied, you should now be getting messages > > > > > similar > > > > > > > > > > (but not identical) to: > > > > > dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > > 915...215, > > > > > > > > > > frontend: 915...215 dvb_pll_attach: delsys: 5, frequency > > > > > range: > > > > > 915..215 > > > > > > > > > > > _ > > > > > > > > > > > > Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln > > > > > > und > > > > > > alte E-Mail-Adresse mitnehmen! https://www.eclipso.de > > > > > > > > > > Thanks, > > > > > Mauro > > > > > > > > My bad. > > > > With just dmesg: > > > > > > > > [ 89.399887] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > 95...215, frontend: 95000...215000 > > > > [ 95.020149] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > 95...215, frontend: 95000...215000 > > > > [ 95.152049] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > 95...215, frontend: 95000...215000 > > > > [ 95.152058] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 > > > > frequency 188 out of range (95..2150) > > > > [ 98.356539] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > 95...215, frontend: 95000...215000 > > > > [ 98.480372] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > 95...215, frontend: 95000...215000 > > > > [ 98.480381] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 > > > > frequency 1587500 out of range (95..2150) > > > > [ 100.016823] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > 95...215, frontend: 95000...215000 > > > > [ 100.140619] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > 95...215, frontend: 95000...215000 > > > > [ 100.140629] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 > > > > frequency 1353500 out of range (95..2150) > > > > [ 105.361166] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > 95...215, frontend: 95000...215000 > > > > [ 105.492972] dvb_frontend_get_frequency_limits: frequencies: tuner: > > > > 95...215, frontend: 95000...215000 > > > > [ 105.492977] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 > > > > frequency 1944750 out of range (95..2150) > > > > > > > > > > > > Which is, I guess the info you need? > > > > > > Yes, partially. Clearly, the problem is coming from the tuner, with is > > > not reporting the frequency in Hz, but I was hoping to see another > > > message from the tuner driver, in order for me to be sure about what's > > > happening there. > > > > > > Didn't you get any message that starts with "dvb_pll_attach"? > > > > > > The thing with Flexcop is that there are several variations, each one > > > with a different tuner driver. > > > > > > Anyway, I guess I found the trouble: it is trying to use the DVB > > > cache to check the delivery system too early (at attach time). > > > > > > I suspect that the enclosed patch will fix the issue. Could you please > > > test it? > > > > > > Thanks! > > > Mauro > > > > > > > > > diff --git a/drivers/media/dvb-frontends/dvb-pll.c > > > b/drivers/media/dvb-frontends/dvb-pll.c index 6d4b2eec67
[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 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(&nexttime,
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 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",
[PATCH] arm64: dts: sdm845: add video nodes
This adds video nodes to sdm845 based on the examples
in the bindings.
Signed-off-by: Malathi Gottam
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0c9a2aa..d82487d 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -84,6 +84,10 @@
reg = <0 0x8620 0 0x2d0>;
no-map;
};
+ venus_region: venus@9580 {
+ reg = <0x0 0x9580 0x0 0x50>;
+ no-map;
+ };
};
cpus {
@@ -1103,5 +1107,35 @@
status = "disabled";
};
};
+
+ video-codec@aa0 {
+ compatible = "qcom,sdm845-venus";
+ reg = <0x0aa0 0xff000>;
+ interrupts = ;
+ power-domains = <&videocc VENUS_GDSC>;
+ clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
+<&videocc VIDEO_CC_VENUS_AHB_CLK>,
+<&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>;
+ clock-names = "core", "iface", "bus";
+ iommus = <&apps_smmu 0x10a0 0x8>,
+<&apps_smmu 0x10b0 0x0>;
+ memory-region = <&venus_region>;
+
+ video-core0 {
+ compatible = "venus-decoder";
+ clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
+<&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
+ clock-names = "core", "bus";
+ power-domains = <&videocc VCODEC0_GDSC>;
+ };
+
+ video-core1 {
+ compatible = "venus-encoder";
+ clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>,
+<&videocc VIDEO_CC_VCODEC1_AXI_CLK>;
+ clock-names = "core", "bus";
+ power-domains = <&videocc VCODEC1_GDSC>;
+ };
+ };
};
};
--
1.9.1
[PATCH v3 01/14] media: ov7670: split register setting from set_fmt() logic
This will allow us to restore the last set format after the device returns
from a power off.
Signed-off-by: Lubomir Rintel
---
Changes since v2:
- This patch was added to the series
drivers/media/i2c/ov7670.c | 80 ++
1 file changed, 46 insertions(+), 34 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index bc68a3a5b4ec..ee2302fbdeee 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -240,6 +240,7 @@ struct ov7670_info {
};
struct v4l2_mbus_framefmt format;
struct ov7670_format_struct *fmt; /* Current format */
+ struct ov7670_win_size *wsize;
struct clk *clk;
struct gpio_desc *resetb_gpio;
struct gpio_desc *pwdn_gpio;
@@ -1003,48 +1004,20 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev
*sd,
return 0;
}
-/*
- * Set a format.
- */
-static int ov7670_set_fmt(struct v4l2_subdev *sd,
- struct v4l2_subdev_pad_config *cfg,
- struct v4l2_subdev_format *format)
+static int ov7670_apply_fmt(struct v4l2_subdev *sd)
{
- struct ov7670_format_struct *ovfmt;
- struct ov7670_win_size *wsize;
struct ov7670_info *info = to_state(sd);
-#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
- struct v4l2_mbus_framefmt *mbus_fmt;
-#endif
+ struct ov7670_win_size *wsize = info->wsize;
unsigned char com7, com10 = 0;
int ret;
- if (format->pad)
- return -EINVAL;
-
- if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
- ret = ov7670_try_fmt_internal(sd, &format->format, NULL, NULL);
- if (ret)
- return ret;
-#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
- mbus_fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
- *mbus_fmt = format->format;
- return 0;
-#else
- return -ENOTTY;
-#endif
- }
-
- ret = ov7670_try_fmt_internal(sd, &format->format, &ovfmt, &wsize);
- if (ret)
- return ret;
/*
* COM7 is a pain in the ass, it doesn't like to be read then
* quickly written afterward. But we have everything we need
* to set it absolutely here, as long as the format-specific
* register sets list it first.
*/
- com7 = ovfmt->regs[0].value;
+ com7 = info->fmt->regs[0].value;
com7 |= wsize->com7_bit;
ret = ov7670_write(sd, REG_COM7, com7);
if (ret)
@@ -1066,7 +1039,7 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
/*
* Now write the rest of the array. Also store start/stops
*/
- ret = ov7670_write_array(sd, ovfmt->regs + 1);
+ ret = ov7670_write_array(sd, info->fmt->regs + 1);
if (ret)
return ret;
@@ -1081,8 +1054,6 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
return ret;
}
- info->fmt = ovfmt;
-
/*
* If we're running RGB565, we must rewrite clkrc after setting
* the other parameters or the image looks poor. If we're *not*
@@ -1100,6 +1071,46 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
return 0;
}
+/*
+ * Set a format.
+ */
+static int ov7670_set_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *format)
+{
+ struct ov7670_info *info = to_state(sd);
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+ struct v4l2_mbus_framefmt *mbus_fmt;
+#endif
+ int ret;
+
+ if (format->pad)
+ return -EINVAL;
+
+ if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
+ ret = ov7670_try_fmt_internal(sd, &format->format, NULL, NULL);
+ if (ret)
+ return ret;
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+ mbus_fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
+ *mbus_fmt = format->format;
+ return 0;
+#else
+ return -ENOTTY;
+#endif
+ }
+
+ ret = ov7670_try_fmt_internal(sd, &format->format, &info->fmt,
&info->wsize);
+ if (ret)
+ return ret;
+
+ ret = ov7670_apply_fmt(sd);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
static int ov7670_get_fmt(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *format)
@@ -1847,6 +1858,7 @@ static int ov7670_probe(struct i2c_client *client,
info->devtype = &ov7670_devdata[id->driver_data];
info->fmt = &ov7670_formats[0];
+ info->wsize = &info->devtype->win_sizes[0];
ov7670_get_default_format(sd, &info->format);
--
2.19.1
[PATCH v3 04/14] media: ov7670: control clock along with power
This provides more power saving when the sensor is off.
While at that, do the delay on power/clock enable even if the sensor driver
itself doesn't control the GPIOs. This is required for the OLPC XO-1
platform, that lacks the proper power/reset properties in its DT, but
needs the delay after the sensor is clocked up.
Signed-off-by: Lubomir Rintel
---
drivers/media/i2c/ov7670.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index cbaab60c..d7635fb2d713 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1623,14 +1623,17 @@ static void ov7670_power_on(struct v4l2_subdev *sd)
if (info->on)
return;
+ clk_prepare_enable(info->clk);
+
if (info->pwdn_gpio)
gpiod_set_value(info->pwdn_gpio, 0);
if (info->resetb_gpio) {
gpiod_set_value(info->resetb_gpio, 1);
usleep_range(500, 1000);
gpiod_set_value(info->resetb_gpio, 0);
- usleep_range(3000, 5000);
}
+ if (info->pwdn_gpio || info->resetb_gpio || info->clk)
+ usleep_range(3000, 5000);
info->on = true;
}
@@ -1642,6 +1645,8 @@ static void ov7670_power_off(struct v4l2_subdev *sd)
if (!info->on)
return;
+ clk_disable_unprepare(info->clk);
+
if (info->pwdn_gpio)
gpiod_set_value(info->pwdn_gpio, 1);
@@ -1863,24 +1868,20 @@ static int ov7670_probe(struct i2c_client *client,
return ret;
}
- if (info->clk) {
- ret = clk_prepare_enable(info->clk);
- if (ret)
- return ret;
+ ret = ov7670_init_gpio(client, info);
+ if (ret)
+ return ret;
+ ov7670_power_on(sd);
+
+ if (info->clk) {
info->clock_speed = clk_get_rate(info->clk) / 100;
if (info->clock_speed < 10 || info->clock_speed > 48) {
ret = -EINVAL;
- goto clk_disable;
+ goto power_off;
}
}
- ret = ov7670_init_gpio(client, info);
- if (ret)
- goto clk_disable;
-
- ov7670_power_on(sd);
-
/* Make sure it's an ov7670 */
ret = ov7670_detect(sd);
if (ret) {
@@ -1960,6 +1961,7 @@ static int ov7670_probe(struct i2c_client *client,
if (ret < 0)
goto entity_cleanup;
+ ov7670_power_off(sd);
return 0;
entity_cleanup:
@@ -1968,12 +1970,9 @@ static int ov7670_probe(struct i2c_client *client,
v4l2_ctrl_handler_free(&info->hdl);
power_off:
ov7670_power_off(sd);
-clk_disable:
- clk_disable_unprepare(info->clk);
return ret;
}
-
static int ov7670_remove(struct i2c_client *client)
{
struct v4l2_subdev *sd = i2c_get_clientdata(client);
@@ -1981,7 +1980,6 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_async_unregister_subdev(sd);
v4l2_ctrl_handler_free(&info->hdl);
- clk_disable_unprepare(info->clk);
media_entity_cleanup(&info->sd.entity);
ov7670_power_off(sd);
return 0;
--
2.19.1
[PATCH v3 05/14] media: dt-bindings: marvell,mmp2-ccic: Add Marvell MMP2 camera
Add Marvell MMP2 camera host interface.
Signed-off-by: Lubomir Rintel
---
Changes since v2:
- Added #clock-cells, clock-names, port
.../bindings/media/marvell,mmp2-ccic.txt | 37 +++
1 file changed, 37 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt
diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt
b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt
new file mode 100644
index ..e5e8ca90e7f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt
@@ -0,0 +1,37 @@
+Marvell MMP2 camera host interface
+
+Required properties:
+ - compatible: Should be "marvell,mmp2-ccic"
+ - reg: register base and size
+ - interrupts: the interrupt number
+ - #clock-cells: must be 0
+ - any required generic properties defined in video-interfaces.txt
+
+Optional properties:
+ - clocks: input clock (see clock-bindings.txt)
+ - clock-names: names of the clocks used, may include "axi", "func" and
+"phy"
+ - clock-output-names: should contain the name of the clock driving the
+ sensor master clock MCLK
+
+Required subnodes:
+ - port: the parallel bus interface port with a single endpoint linked to
+ the sensor's endpoint as described in video-interfaces.txt
+
+Example:
+
+ camera0: camera@d420a000 {
+ compatible = "marvell,mmp2-ccic";
+ reg = <0xd420a000 0x800>;
+ interrupts = <42>;
+ clocks = <&soc_clocks MMP2_CLK_CCIC0>;
+ clock-names = "axi";
+ #clock-cells = <0>;
+ clock-output-names = "mclk";
+
+ port {
+ camera0_0: endpoint {
+ remote-endpoint = <&ov7670_0>;
+ };
+ };
+ };
--
2.19.1
[PATCH v3 03/14] media: ov7670: hook s_power onto v4l2 core
The commit 71862f63f351 ("media: ov7670: Add the ov7670_s_power function")
added a power control routing. However, it was not good enough to use as
a s_power() callback: it merely flipped on the power GPIOs without
restoring the register settings.
Fix this now and register an actual power callback.
Signed-off-by: Lubomir Rintel
---
Changes since v2:
- Restore the controls, format and frame rate on power on
drivers/media/i2c/ov7670.c | 50 +-
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index ead0c360df33..cbaab60c 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -242,6 +242,7 @@ struct ov7670_info {
struct ov7670_format_struct *fmt; /* Current format */
struct ov7670_win_size *wsize;
struct clk *clk;
+ int on;
struct gpio_desc *resetb_gpio;
struct gpio_desc *pwdn_gpio;
unsigned int mbus_config; /* Media bus configuration flags */
@@ -1615,19 +1616,54 @@ static int ov7670_s_register(struct v4l2_subdev *sd,
const struct v4l2_dbg_regis
}
#endif
-static int ov7670_s_power(struct v4l2_subdev *sd, int on)
+static void ov7670_power_on(struct v4l2_subdev *sd)
{
struct ov7670_info *info = to_state(sd);
+ if (info->on)
+ return;
+
if (info->pwdn_gpio)
- gpiod_set_value(info->pwdn_gpio, !on);
- if (on && info->resetb_gpio) {
+ gpiod_set_value(info->pwdn_gpio, 0);
+ if (info->resetb_gpio) {
gpiod_set_value(info->resetb_gpio, 1);
usleep_range(500, 1000);
gpiod_set_value(info->resetb_gpio, 0);
usleep_range(3000, 5000);
}
+ info->on = true;
+}
+
+static void ov7670_power_off(struct v4l2_subdev *sd)
+{
+ struct ov7670_info *info = to_state(sd);
+
+ if (!info->on)
+ return;
+
+ if (info->pwdn_gpio)
+ gpiod_set_value(info->pwdn_gpio, 1);
+
+ info->on = false;
+}
+
+static int ov7670_s_power(struct v4l2_subdev *sd, int on)
+{
+ struct ov7670_info *info = to_state(sd);
+
+ if (info->on == on)
+ return 0;
+
+ if (on) {
+ ov7670_power_on (sd);
+ ov7670_apply_fmt(sd);
+ ov7675_apply_framerate(sd);
+ v4l2_ctrl_handler_setup(&info->hdl);
+ } else {
+ ov7670_power_off (sd);
+ }
+
return 0;
}
@@ -1660,6 +1696,7 @@ static int ov7670_open(struct v4l2_subdev *sd, struct
v4l2_subdev_fh *fh)
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.reset = ov7670_reset,
.init = ov7670_init,
+ .s_power = ov7670_s_power,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.g_register = ov7670_g_register,
.s_register = ov7670_s_register,
@@ -1825,6 +1862,7 @@ static int ov7670_probe(struct i2c_client *client,
else
return ret;
}
+
if (info->clk) {
ret = clk_prepare_enable(info->clk);
if (ret)
@@ -1841,7 +1879,7 @@ static int ov7670_probe(struct i2c_client *client,
if (ret)
goto clk_disable;
- ov7670_s_power(sd, 1);
+ ov7670_power_on(sd);
/* Make sure it's an ov7670 */
ret = ov7670_detect(sd);
@@ -1929,7 +1967,7 @@ static int ov7670_probe(struct i2c_client *client,
hdl_free:
v4l2_ctrl_handler_free(&info->hdl);
power_off:
- ov7670_s_power(sd, 0);
+ ov7670_power_off(sd);
clk_disable:
clk_disable_unprepare(info->clk);
return ret;
@@ -1945,7 +1983,7 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_ctrl_handler_free(&info->hdl);
clk_disable_unprepare(info->clk);
media_entity_cleanup(&info->sd.entity);
- ov7670_s_power(sd, 0);
+ ov7670_power_off(sd);
return 0;
}
--
2.19.1
[PATCH v3 07/14] [media] marvell-ccic: don't generate EOF on parallel bus
The commit 05fed81625bf ("[media] marvell-ccic: add MIPI support for
marvell-ccic driver") that claimed to add CSI2 turned on C0_EOF_VSYNC for
parallel bus without a very good explanation.
That broke camera on OLPC XO-1.75 which precisely uses a sensor on a
parallel bus. Revert that chunk.
Tested on an OLPC XO-1.75.
Fixes: 05fed81625bf755cc67c5864cdfd18b69ea828d1
Signed-off-by: Lubomir Rintel
---
drivers/media/platform/marvell-ccic/mcam-core.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index d97f39bde9bd..d24e5b7a3bc5 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -792,12 +792,6 @@ static void mcam_ctlr_image(struct mcam_camera *cam)
* Make sure it knows we want to use hsync/vsync.
*/
mcam_reg_write_mask(cam, REG_CTRL0, C0_SIF_HVSYNC, C0_SIFM_MASK);
- /*
-* This field controls the generation of EOF(DVP only)
-*/
- if (cam->bus_type != V4L2_MBUS_CSI2_DPHY)
- mcam_reg_set_bit(cam, REG_CTRL0,
- C0_EOF_VSYNC | C0_VEDGE_CTRL);
}
--
2.19.1
[PATCH v3 06/14] [media] marvell-ccic: fix DMA s/g desc number calculation
The commit d790b7eda953 ("[media] vb2-dma-sg: move dma_(un)map_sg here")
left dma_desc_nent unset. It previously contained the number of DMA
descriptors as returned from dma_map_sg().
We can now (since the commit referred to above) obtain the same value from
the sg_table and drop dma_desc_nent altogether.
Tested on OLPC XO-1.75 machine. Doesn't affect the OLPC XO-1's Cafe
driver, since that one doesn't do DMA.
Fixes: d790b7eda953df474f470169ebdf111c02fa7a2d
Signed-off-by: Lubomir Rintel
---
drivers/media/platform/marvell-ccic/mcam-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index f1b301810260..d97f39bde9bd 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -200,7 +200,6 @@ struct mcam_vb_buffer {
struct list_head queue;
struct mcam_dma_desc *dma_desc; /* Descriptor virtual address */
dma_addr_t dma_desc_pa; /* Descriptor physical address */
- int dma_desc_nent; /* Number of mapped descriptors */
};
static inline struct mcam_vb_buffer *vb_to_mvb(struct vb2_v4l2_buffer *vb)
@@ -608,9 +607,11 @@ static void mcam_dma_contig_done(struct mcam_camera *cam,
int frame)
static void mcam_sg_next_buffer(struct mcam_camera *cam)
{
struct mcam_vb_buffer *buf;
+ struct sg_table *sg_table;
buf = list_first_entry(&cam->buffers, struct mcam_vb_buffer, queue);
list_del_init(&buf->queue);
+ sg_table = vb2_dma_sg_plane_desc(&buf->vb_buf.vb2_buf, 0);
/*
* Very Bad Not Good Things happen if you don't clear
* C1_DESC_ENA before making any descriptor changes.
@@ -618,7 +619,7 @@ static void mcam_sg_next_buffer(struct mcam_camera *cam)
mcam_reg_clear_bit(cam, REG_CTRL1, C1_DESC_ENA);
mcam_reg_write(cam, REG_DMA_DESC_Y, buf->dma_desc_pa);
mcam_reg_write(cam, REG_DESC_LEN_Y,
- buf->dma_desc_nent*sizeof(struct mcam_dma_desc));
+ sg_table->nents*sizeof(struct mcam_dma_desc));
mcam_reg_write(cam, REG_DESC_LEN_U, 0);
mcam_reg_write(cam, REG_DESC_LEN_V, 0);
mcam_reg_set_bit(cam, REG_CTRL1, C1_DESC_ENA);
--
2.19.1
[PATCH v3 09/14] [media] marvell-ccic: drop unused stuff
Remove structure members and headers that are not actually used. Saves
us from some noise in subsequent cleanup commits.
Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
---
drivers/media/platform/marvell-ccic/mcam-core.c | 1 -
drivers/media/platform/marvell-ccic/mcam-core.h | 2 --
drivers/media/platform/marvell-ccic/mmp-driver.c | 2 --
include/linux/platform_data/media/mmp-camera.h | 1 -
4 files changed, 6 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 1b879035948c..0113b8d37d03 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -1776,7 +1776,6 @@ int mccic_register(struct mcam_camera *cam)
*/
sensor_cfg.clock_speed = cam->clock_speed;
sensor_cfg.use_smbus = cam->use_smbus;
- cam->sensor_addr = ov7670_info.addr;
cam->sensor = v4l2_i2c_new_subdev_board(&cam->v4l2_dev,
cam->i2c_adapter, &ov7670_info, NULL);
if (cam->sensor == NULL) {
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index a3a097a45e78..b828b1bb59d3 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -112,7 +112,6 @@ struct mcam_camera {
short int use_smbus;/* SMBUS or straight I2c? */
enum mcam_buffer_mode buffer_mode;
- int mclk_min; /* The minimal value of mclk */
int mclk_src; /* which clock source the mclk derives from */
int mclk_div; /* Clock Divider Value for MCLK */
@@ -152,7 +151,6 @@ struct mcam_camera {
*/
struct video_device vdev;
struct v4l2_subdev *sensor;
- unsigned short sensor_addr;
/* Videobuf2 stuff */
struct vb2_queue vb_queue;
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index dbfc597b955d..f2e43b23af18 100644
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -332,7 +331,6 @@ static int mmpcam_probe(struct platform_device *pdev)
mcam->calc_dphy = mmpcam_calc_dphy;
mcam->dev = &pdev->dev;
mcam->use_smbus = 0;
- mcam->mclk_min = pdata->mclk_min;
mcam->mclk_src = pdata->mclk_src;
mcam->mclk_div = pdata->mclk_div;
mcam->bus_type = pdata->bus_type;
diff --git a/include/linux/platform_data/media/mmp-camera.h
b/include/linux/platform_data/media/mmp-camera.h
index d2d3a443eedf..4c3a80a45883 100644
--- a/include/linux/platform_data/media/mmp-camera.h
+++ b/include/linux/platform_data/media/mmp-camera.h
@@ -16,7 +16,6 @@ struct mmp_camera_platform_data {
int sensor_power_gpio;
int sensor_reset_gpio;
enum v4l2_mbus_type bus_type;
- int mclk_min; /* The minimal value of MCLK */
int mclk_src; /* which clock source the MCLK derives from */
int mclk_div; /* Clock Divider Value for MCLK */
/*
--
2.19.1
[PATCH v3 11/14] [media] marvell-ccic: rename the clocks
Use the names more suitable for devicetree bindings.
There are no board files utilizing this, thus we seem to be at liberty
at renaming this without consequences.
Signed-off-by: Lubomir Rintel
---
Changes since v2:
- This patch was added to the series
drivers/media/platform/marvell-ccic/mmp-driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 05cba74c0d13..5c61317f56bc 100644
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -33,7 +33,7 @@ MODULE_ALIAS("platform:mmp-camera");
MODULE_AUTHOR("Jonathan Corbet ");
MODULE_LICENSE("GPL");
-static char *mcam_clks[] = {"CCICAXICLK", "CCICFUNCLK", "CCICPHYCLK"};
+static char *mcam_clks[] = {"axi", "func", "phy"};
struct mmp_camera {
void __iomem *power_regs;
--
2.19.1
[PATCH v3 08/14] Revert "[media] marvell-ccic: reset ccic phy when stop streaming for stability"
This accesses the clock registers directly and thus is going to stay in the
way of making the driver devicetree friendly.
No boards seems to actually use this. If it's somehow actually needed it
needs to be done differently.
This reverts commit 7c269f454e7a51b151d94f99344120efa1cd0acb.
---
.../media/platform/marvell-ccic/mcam-core.c | 6 -
.../media/platform/marvell-ccic/mcam-core.h | 2 --
.../media/platform/marvell-ccic/mmp-driver.c | 25 ---
3 files changed, 33 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index d24e5b7a3bc5..1b879035948c 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -1154,12 +1154,6 @@ static void mcam_vb_stop_streaming(struct vb2_queue *vq)
if (cam->state != S_STREAMING)
return;
mcam_ctlr_stop_dma(cam);
- /*
-* Reset the CCIC PHY after stopping streaming,
-* otherwise, the CCIC may be unstable.
-*/
- if (cam->ctlr_reset)
- cam->ctlr_reset(cam);
/*
* VB2 reclaims the buffers, so we need to forget
* about them.
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index ad8955f9f0a1..a3a097a45e78 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -116,7 +116,6 @@ struct mcam_camera {
int mclk_src; /* which clock source the mclk derives from */
int mclk_div; /* Clock Divider Value for MCLK */
- int ccic_id;
enum v4l2_mbus_type bus_type;
/* MIPI support */
/* The dphy config value, allocated in board file
@@ -137,7 +136,6 @@ struct mcam_camera {
int (*plat_power_up) (struct mcam_camera *cam);
void (*plat_power_down) (struct mcam_camera *cam);
void (*calc_dphy) (struct mcam_camera *cam);
- void (*ctlr_reset) (struct mcam_camera *cam);
/*
* Everything below here is private to the mcam core and
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 70a2833db0d1..dbfc597b955d 100644
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -105,7 +105,6 @@ static struct mmp_camera *mmpcam_find_device(struct
platform_device *pdev)
#define CPU_SUBSYS_PMU_BASE0xd4282800
#define REG_CCIC_DCGCR 0x28/* CCIC dyn clock gate ctrl reg */
#define REG_CCIC_CRCR 0x50/* CCIC clk reset ctrl reg */
-#define REG_CCIC2_CRCR 0xf4/* CCIC2 clk reset ctrl reg */
static void mcam_clk_enable(struct mcam_camera *mcam)
{
@@ -183,28 +182,6 @@ static void mmpcam_power_down(struct mcam_camera *mcam)
mcam_clk_disable(mcam);
}
-static void mcam_ctlr_reset(struct mcam_camera *mcam)
-{
- unsigned long val;
- struct mmp_camera *cam = mcam_to_cam(mcam);
-
- if (mcam->ccic_id) {
- /*
-* Using CCIC2
-*/
- val = ioread32(cam->power_regs + REG_CCIC2_CRCR);
- iowrite32(val & ~0x2, cam->power_regs + REG_CCIC2_CRCR);
- iowrite32(val | 0x2, cam->power_regs + REG_CCIC2_CRCR);
- } else {
- /*
-* Using CCIC1
-*/
- val = ioread32(cam->power_regs + REG_CCIC_CRCR);
- iowrite32(val & ~0x2, cam->power_regs + REG_CCIC_CRCR);
- iowrite32(val | 0x2, cam->power_regs + REG_CCIC_CRCR);
- }
-}
-
/*
* calc the dphy register values
* There are three dphy registers being used.
@@ -352,11 +329,9 @@ static int mmpcam_probe(struct platform_device *pdev)
mcam = &cam->mcam;
mcam->plat_power_up = mmpcam_power_up;
mcam->plat_power_down = mmpcam_power_down;
- mcam->ctlr_reset = mcam_ctlr_reset;
mcam->calc_dphy = mmpcam_calc_dphy;
mcam->dev = &pdev->dev;
mcam->use_smbus = 0;
- mcam->ccic_id = pdev->id;
mcam->mclk_min = pdata->mclk_min;
mcam->mclk_src = pdata->mclk_src;
mcam->mclk_div = pdata->mclk_div;
--
2.19.1
[PATCH v3 10/14] [media] marvell-ccic/mmp: enable clock before accessing registers
The access to REG_CLKCTRL or REG_CTRL1 without the clock enabled hangs the machine. Enable the clock first. Signed-off-by: Lubomir Rintel Acked-by: Pavel Machek --- drivers/media/platform/marvell-ccic/mmp-driver.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c b/drivers/media/platform/marvell-ccic/mmp-driver.c index f2e43b23af18..05cba74c0d13 100644 --- a/drivers/media/platform/marvell-ccic/mmp-driver.c +++ b/drivers/media/platform/marvell-ccic/mmp-driver.c @@ -144,6 +144,7 @@ static int mmpcam_power_up(struct mcam_camera *mcam) * Turn on power and clocks to the controller. */ mmpcam_power_up_ctlr(cam); + mcam_clk_enable(mcam); /* * Provide power to the sensor. */ @@ -157,8 +158,6 @@ static int mmpcam_power_up(struct mcam_camera *mcam) gpio_set_value(pdata->sensor_reset_gpio, 1); /* reset is active low */ mdelay(5); - mcam_clk_enable(mcam); - return 0; } -- 2.19.1
[PATCH v3 14/14] [media] marvell-ccic: provide a clock for the sensor
The sensor needs the MCLK clock running when it's being probed. On
platforms where the sensor is instantiated from a DT (MMP2) it is going
to happen asynchronously.
Therefore, the current modus operandi, where the bridge driver fiddles
with the sensor power and clock itself is not going to fly. As the comments
wisely note, this doesn't even belong there.
Luckily, the ov7670 driver is already able to control its power and
reset lines, we can just drop the MMP platform glue altogether.
It also requests the clock via the standard clock subsystem. Good -- let's
set up a clock instance so that the sensor can ask us to enable the clock.
Note that this is pretty dumb at the moment: the clock is hardwired to a
particular frequency and parent. It was always the case.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- [kbuild/ia64] depend on COMMON_CLK.
- [smatch] fix bad return in mcam_v4l_open() leading to lock not getting
released on error.
drivers/media/platform/marvell-ccic/Kconfig | 2 +
.../media/platform/marvell-ccic/cafe-driver.c | 9 +-
.../media/platform/marvell-ccic/mcam-core.c | 156 +++---
.../media/platform/marvell-ccic/mcam-core.h | 3 +
.../media/platform/marvell-ccic/mmp-driver.c | 152 ++---
.../linux/platform_data/media/mmp-camera.h| 2 -
6 files changed, 161 insertions(+), 163 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/Kconfig
b/drivers/media/platform/marvell-ccic/Kconfig
index cf12e077203a..3e12eb25740a 100644
--- a/drivers/media/platform/marvell-ccic/Kconfig
+++ b/drivers/media/platform/marvell-ccic/Kconfig
@@ -1,6 +1,7 @@
config VIDEO_CAFE_CCIC
tristate "Marvell 88ALP01 (Cafe) CMOS Camera Controller support"
depends on PCI && I2C && VIDEO_V4L2
+ depends on COMMON_CLK
select VIDEO_OV7670
select VIDEOBUF2_VMALLOC
select VIDEOBUF2_DMA_CONTIG
@@ -14,6 +15,7 @@ config VIDEO_MMP_CAMERA
tristate "Marvell Armada 610 integrated camera controller support"
depends on I2C && VIDEO_V4L2
depends on ARCH_MMP || COMPILE_TEST
+ depends on COMMON_CLK
select VIDEO_OV7670
select I2C_GPIO
select VIDEOBUF2_VMALLOC
diff --git a/drivers/media/platform/marvell-ccic/cafe-driver.c
b/drivers/media/platform/marvell-ccic/cafe-driver.c
index 658294d319c0..0e712bb941ba 100644
--- a/drivers/media/platform/marvell-ccic/cafe-driver.c
+++ b/drivers/media/platform/marvell-ccic/cafe-driver.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include "mcam-core.h"
@@ -533,11 +534,10 @@ static int cafe_pci_probe(struct pci_dev *pdev,
goto out_iounmap;
/*
-* Initialize the controller and leave it powered up. It will
-* stay that way until the sensor driver shows up.
+* Initialize the controller.
*/
cafe_ctlr_init(mcam);
- cafe_ctlr_power_up(mcam);
+
/*
* Set up I2C/SMBUS communications. We have to drop the mutex here
* because the sensor could attach in this call chain, leading to
@@ -555,6 +555,9 @@ static int cafe_pci_probe(struct pci_dev *pdev,
if (ret)
goto out_smbus_shutdown;
+ clkdev_create(mcam->mclk, "xclk", "%d-%04x",
+ i2c_adapter_id(cam->i2c_adapter), ov7670_info.addr);
+
if (i2c_new_device(cam->i2c_adapter, &ov7670_info)) {
cam->registered = 1;
return 0;
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 87812b7287f0..982fbac6472d 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -303,9 +304,6 @@ static void mcam_enable_mipi(struct mcam_camera *mcam)
*/
mcam_reg_write(mcam, REG_CSI2_CTRL0,
CSI2_C0_MIPI_EN | CSI2_C0_ACT_LANE(mcam->lane));
- mcam_reg_write(mcam, REG_CLKCTRL,
- (mcam->mclk_src << 29) | mcam->mclk_div);
-
mcam->mipi_enabled = true;
}
}
@@ -846,11 +844,6 @@ static void mcam_ctlr_init(struct mcam_camera *cam)
* but it's good to be sure.
*/
mcam_reg_clear_bit(cam, REG_CTRL0, C0_ENABLE);
- /*
-* Clock the sensor appropriately. Controller clock should
-* be 48MHz, sensor "typical" value is half that.
-*/
- mcam_reg_write_mask(cam, REG_CLKCTRL, 2, CLK_DIV_MASK);
spin_unlock_irqrestore(&cam->dev_lock, flags);
}
@@ -898,14 +891,15 @@ static int mcam_ctlr_power_up(struct mcam_camera *cam)
int ret;
spin_lock_irqsave(&cam->dev_lock, flags);
- ret = cam->plat_power_up(cam);
- if (ret) {
- spin_unlock_irqrestore(&cam->dev_lock, flags);
- return ret;
+ if (cam->plat_pow
[PATCH v3 13/14] [media] marvell-ccic: use async notifier to get the sensor
An instance of a sensor on DT-based MMP2 platform is always going to be
created asynchronously.
Let's move the manual device creation away from the core to the Cafe
driver (used on OLPC XO-1, not present in DT) and set up appropriate
async matches: I2C on Cafe, FWNODE on MMP (OLPC XO-1.75).
Signed-off-by: Lubomir Rintel
---
Changes since v2:
- Moved a typo fix hunk that was accidentally in the following patch
here, to unbreak build.
.../media/platform/marvell-ccic/cafe-driver.c | 49 --
.../media/platform/marvell-ccic/mcam-core.c | 157 --
.../media/platform/marvell-ccic/mcam-core.h | 5 +-
.../media/platform/marvell-ccic/mmp-driver.c | 27 +--
.../linux/platform_data/media/mmp-camera.h| 1 -
5 files changed, 162 insertions(+), 77 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/cafe-driver.c
b/drivers/media/platform/marvell-ccic/cafe-driver.c
index 2986cb4b88d0..658294d319c0 100644
--- a/drivers/media/platform/marvell-ccic/cafe-driver.c
+++ b/drivers/media/platform/marvell-ccic/cafe-driver.c
@@ -8,6 +8,7 @@
*
* Copyright 2006-11 One Laptop Per Child Association, Inc.
* Copyright 2006-11 Jonathan Corbet
+ * Copyright 2018 Lubomir Rintel
*
* Written by Jonathan Corbet, cor...@lwn.net.
*
@@ -27,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -52,6 +54,7 @@ struct cafe_camera {
int registered; /* Fully initialized? */
struct mcam_camera mcam;
struct pci_dev *pdev;
+ struct i2c_adapter *i2c_adapter;
wait_queue_head_t smbus_wait; /* Waiting on i2c events */
};
@@ -351,15 +354,15 @@ static int cafe_smbus_setup(struct cafe_camera *cam)
return ret;
}
- cam->mcam.i2c_adapter = adap;
+ cam->i2c_adapter = adap;
cafe_smbus_enable_irq(cam);
return 0;
}
static void cafe_smbus_shutdown(struct cafe_camera *cam)
{
- i2c_del_adapter(cam->mcam.i2c_adapter);
- kfree(cam->mcam.i2c_adapter);
+ i2c_del_adapter(cam->i2c_adapter);
+ kfree(cam->i2c_adapter);
}
@@ -452,6 +455,29 @@ static irqreturn_t cafe_irq(int irq, void *data)
return IRQ_RETVAL(handled);
}
+/* --
*/
+
+static struct ov7670_config sensor_cfg = {
+ /*
+* Exclude QCIF mode, because it only captures a tiny portion
+* of the sensor FOV
+*/
+ .min_width = 320,
+ .min_height = 240,
+
+ /*
+* Set the clock speed for the XO 1; I don't believe this
+* driver has ever run anywhere else.
+*/
+ .clock_speed = 45,
+ .use_smbus = 1,
+};
+
+struct i2c_board_info ov7670_info = {
+ .type = "ov7670",
+ .addr = 0x42 >> 1,
+ .platform_data = &sensor_cfg,
+};
/* --
*/
/*
@@ -481,12 +507,6 @@ static int cafe_pci_probe(struct pci_dev *pdev,
mcam->plat_power_down = cafe_ctlr_power_down;
mcam->dev = &pdev->dev;
snprintf(mcam->bus_info, sizeof(mcam->bus_info), "PCI:%s",
pci_name(pdev));
- /*
-* Set the clock speed for the XO 1; I don't believe this
-* driver has ever run anywhere else.
-*/
- mcam->clock_speed = 45;
- mcam->use_smbus = 1;
/*
* Vmalloc mode for buffers is traditional with this driver.
* We *might* be able to run DMA_contig, especially on a system
@@ -527,12 +547,21 @@ static int cafe_pci_probe(struct pci_dev *pdev,
if (ret)
goto out_pdown;
+ mcam->asd.match_type = V4L2_ASYNC_MATCH_I2C;
+ mcam->asd.match.i2c.adapter_id = i2c_adapter_id(cam->i2c_adapter);
+ mcam->asd.match.i2c.address = ov7670_info.addr;
+
ret = mccic_register(mcam);
- if (ret == 0) {
+ if (ret)
+ goto out_smbus_shutdown;
+
+ if (i2c_new_device(cam->i2c_adapter, &ov7670_info)) {
cam->registered = 1;
return 0;
}
+ mccic_shutdown(mcam);
+out_smbus_shutdown:
cafe_smbus_shutdown(cam);
out_pdown:
cafe_ctlr_power_down(mcam);
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 0113b8d37d03..87812b7287f0 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -4,6 +4,7 @@
* so it needs platform-specific support outside of the core.
*
* Copyright 2011 Jonathan Corbet cor...@lwn.net
+ * Copyright 2018 Lubomir Rintel
*/
#include
#include
@@ -26,7 +27,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -93,6 +93,9 @@ MODULE_PARM_DESC(buffer_mode,
#define sensor_call(cam, o, f, args...) \
v4l2_subdev_call(cam->sensor, o, f, ##args)
+#define notifier_to_mcam(notifier) \
+ container_of
[PATCH v3 12/14] [media] marvell-ccic/mmp: add devicetree support
The platform data is actually not used anywhere (along with the CSI
support) and should be safe to remove.
Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
---
Changes since v1:
- s/This are/These are/ in a comment
.../media/platform/marvell-ccic/mmp-driver.c | 36 ++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 5c61317f56bc..05b9fa8c6a6f 100644
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -19,6 +19,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -196,6 +198,9 @@ static void mmpcam_calc_dphy(struct mcam_camera *mcam)
struct device *dev = &cam->pdev->dev;
unsigned long tx_clk_esc;
+ if (!pdata)
+ return;
+
/*
* If CSI2_DPHY3 is calculated dynamically,
* pdata->lane_clk should be already set
@@ -314,10 +319,6 @@ static int mmpcam_probe(struct platform_device *pdev)
struct mmp_camera_platform_data *pdata;
int ret;
- pdata = pdev->dev.platform_data;
- if (!pdata)
- return -ENODEV;
-
cam = devm_kzalloc(&pdev->dev, sizeof(*cam), GFP_KERNEL);
if (cam == NULL)
return -ENOMEM;
@@ -330,17 +331,29 @@ static int mmpcam_probe(struct platform_device *pdev)
mcam->calc_dphy = mmpcam_calc_dphy;
mcam->dev = &pdev->dev;
mcam->use_smbus = 0;
- mcam->mclk_src = pdata->mclk_src;
- mcam->mclk_div = pdata->mclk_div;
- mcam->bus_type = pdata->bus_type;
- mcam->dphy = pdata->dphy;
+ pdata = pdev->dev.platform_data;
+ if (pdata) {
+ mcam->mclk_src = pdata->mclk_src;
+ mcam->mclk_div = pdata->mclk_div;
+ mcam->bus_type = pdata->bus_type;
+ mcam->dphy = pdata->dphy;
+ mcam->lane = pdata->lane;
+ } else {
+ /*
+* These are values that used to be hardcoded in mcam-core and
+* work well on a OLPC XO 1.75 with a parallel bus sensor.
+* If it turns out other setups make sense, the values should
+* be obtained from the device tree.
+*/
+ mcam->mclk_src = 3;
+ mcam->mclk_div = 2;
+ }
if (mcam->bus_type == V4L2_MBUS_CSI2_DPHY) {
cam->mipi_clk = devm_clk_get(mcam->dev, "mipi");
if ((IS_ERR(cam->mipi_clk) && mcam->dphy[2] == 0))
return PTR_ERR(cam->mipi_clk);
}
mcam->mipi_enabled = false;
- mcam->lane = pdata->lane;
mcam->chip_id = MCAM_ARMADA610;
mcam->buffer_mode = B_DMA_sg;
strscpy(mcam->bus_info, "platform:mmp-camera", sizeof(mcam->bus_info));
@@ -475,6 +488,10 @@ static int mmpcam_resume(struct platform_device *pdev)
#endif
+static const struct of_device_id mmpcam_of_match[] = {
+ { .compatible = "marvell,mmp2-ccic", },
+ {},
+};
static struct platform_driver mmpcam_driver = {
.probe = mmpcam_probe,
@@ -485,6 +502,7 @@ static struct platform_driver mmpcam_driver = {
#endif
.driver = {
.name = "mmp-camera",
+ .of_match_table = of_match_ptr(mmpcam_of_match),
}
};
--
2.19.1
[PATCH v3 02/14] media: ov7670: split register setting from set_framerate() logic
This will allow us to restore the last set frame rate after the device
returns from a power off.
Signed-off-by: Lubomir Rintel
---
Changes since v2:
- This patch was added to the series
drivers/media/i2c/ov7670.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index ee2302fbdeee..ead0c360df33 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -810,13 +810,24 @@ static void ov7675_get_framerate(struct v4l2_subdev *sd,
(4 * clkrc);
}
+static int ov7675_apply_framerate(struct v4l2_subdev *sd)
+{
+ struct ov7670_info *info = to_state(sd);
+ int ret;
+
+ ret = ov7670_write(sd, REG_CLKRC, info->clkrc);
+ if (ret < 0)
+ return ret;
+
+ return ov7670_write(sd, REG_DBLV, info->pll_bypass ? DBLV_BYPASS :
DBLV_X4);
+}
+
static int ov7675_set_framerate(struct v4l2_subdev *sd,
struct v4l2_fract *tpf)
{
struct ov7670_info *info = to_state(sd);
u32 clkrc;
int pll_factor;
- int ret;
/*
* The formula is fps = 5/4*pixclk for YUV/RGB and
@@ -825,19 +836,10 @@ static int ov7675_set_framerate(struct v4l2_subdev *sd,
* pixclk = clock_speed / (clkrc + 1) * PLLfactor
*
*/
- if (info->pll_bypass) {
- pll_factor = 1;
- ret = ov7670_write(sd, REG_DBLV, DBLV_BYPASS);
- } else {
- pll_factor = PLL_FACTOR;
- ret = ov7670_write(sd, REG_DBLV, DBLV_X4);
- }
- if (ret < 0)
- return ret;
-
if (tpf->numerator == 0 || tpf->denominator == 0) {
clkrc = 0;
} else {
+ pll_factor = info->pll_bypass ? 1 : PLL_FACTOR;
clkrc = (5 * pll_factor * info->clock_speed * tpf->numerator) /
(4 * tpf->denominator);
if (info->fmt->mbus_code == MEDIA_BUS_FMT_SBGGR8_1X8)
@@ -859,11 +861,7 @@ static int ov7675_set_framerate(struct v4l2_subdev *sd,
/* Recalculate frame rate */
ov7675_get_framerate(sd, tpf);
- ret = ov7670_write(sd, REG_CLKRC, info->clkrc);
- if (ret < 0)
- return ret;
-
- return ov7670_write(sd, REG_DBLV, DBLV_X4);
+ return ov7675_apply_framerate(sd);
}
static void ov7670_get_framerate_legacy(struct v4l2_subdev *sd,
--
2.19.1
[PATCH v3 0/14] media: make Marvell camera work on DT-based OLPC XO-1.75
Hi, this is the third spin of a patchset that modernizes the Marvel MMP2 CCIC driver. Notably, it ports it from the platform data (which seems unused as the board support code never made it) to devicetree. At the core of the rework is the move to asynchronous sensor discovery and clock management with the standard clock framework. There are also some straightforward fixes for the bitrotten parts. There's probably still room for improvement, but as it is, it seems to work well on OLPC XO-1.75 and doesn't break OLPC XO-1 (I've tested on both platforms). Changes since v2: - All documented in individual patches. Changes since v1: - "marvell-ccic: drop ctlr_reset()" patch was replaced with a straightforward revert of the commit that added ctlr_reset() along with an explanation in commit message. - Added collected Acks - Other changes are noted in individial patches Thanks, Lubo
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: DVB-S PCI card regression on 4.19 / 4.20
On Tue, 20 Nov 2018 10:51:59 +0100,
stakanov wrote:
>
> In data martedì 20 novembre 2018 10:18:10 CET, Mauro Carvalho Chehab ha
> scritto:
> > Em Tue, 20 Nov 2018 09:07:57 +0100
> >
> > stakanov escreveu:
> > > In data martedì 20 novembre 2018 00:58:41 CET, Mauro Carvalho Chehab ha
> > >
> > > scritto:
> > > > Em Tue, 20 Nov 2018 00:19:54 +0100
> > > >
> > > > stakanov escreveu:
> > > > > In data martedì 20 novembre 2018 00:08:45 CET, Mauro Carvalho Chehab
> > > > > ha
> > > > >
> > > > > scritto:
> > > > > > uname -a
> > > > > >
> > > > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP PREEMPT
> > > > > > > Mon
> > > > > > > Nov 19
> > > > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux
> > > > >
> > > > > uname -a
> > > > >
> > > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP PREEMPT Mon
> > > > > > Nov
> > > > > > 19
> > > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux
> > > > >
> > > > > from
> > > > > https://download.opensuse.org/repositories/home:/tiwai:/bsc1116374/
> > > > > standard/x86_64/
> > > > >
> > > > > So I booted this one, should be the right one.
> > > > > sudo dmesg | grep -i b2c2 should give these additional messages?
> > > > >
> > > > > If Takashi is still around, he could confirm.
> > > >
> > > > Well, if the patch got applied, you should now be getting messages
> > > > similar
> > > >
> > > > (but not identical) to:
> > > > dvb_frontend_get_frequency_limits: frequencies: tuner:
> > > > 915...215,
> > > >
> > > > frontend: 915...215 dvb_pll_attach: delsys: 5, frequency range:
> > > > 915..215
> > > >
> > > > > _
> > > > >
> > > > > Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln
> > > > > und
> > > > > alte E-Mail-Adresse mitnehmen! https://www.eclipso.de
> > > >
> > > > Thanks,
> > > > Mauro
> > >
> > > My bad.
> > > With just dmesg:
> > >
> > > [ 89.399887] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > > 95...215, frontend: 95000...215000
> > > [ 95.020149] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > > 95...215, frontend: 95000...215000
> > > [ 95.152049] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > > 95...215, frontend: 95000...215000
> > > [ 95.152058] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> > > frequency 188 out of range (95..2150)
> > > [ 98.356539] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > > 95...215, frontend: 95000...215000
> > > [ 98.480372] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > > 95...215, frontend: 95000...215000
> > > [ 98.480381] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> > > frequency 1587500 out of range (95..2150)
> > > [ 100.016823] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > > 95...215, frontend: 95000...215000
> > > [ 100.140619] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > > 95...215, frontend: 95000...215000
> > > [ 100.140629] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> > > frequency 1353500 out of range (95..2150)
> > > [ 105.361166] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > > 95...215, frontend: 95000...215000
> > > [ 105.492972] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > > 95...215, frontend: 95000...215000
> > > [ 105.492977] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> > > frequency 1944750 out of range (95..2150)
> > >
> > >
> > > Which is, I guess the info you need?
> >
> > Yes, partially. Clearly, the problem is coming from the tuner, with is
> > not reporting the frequency in Hz, but I was hoping to see another
> > message from the tuner driver, in order for me to be sure about what's
> > happening there.
> >
> > Didn't you get any message that starts with "dvb_pll_attach"?
> >
> > The thing with Flexcop is that there are several variations, each one
> > with a different tuner driver.
> >
> > Anyway, I guess I found the trouble: it is trying to use the DVB
> > cache to check the delivery system too early (at attach time).
> >
> > I suspect that the enclosed patch will fix the issue. Could you please
> > test it?
> >
> > Thanks!
> > Mauro
> >
> >
> > diff --git a/drivers/media/dvb-frontends/dvb-pll.c
> > b/drivers/media/dvb-frontends/dvb-pll.c index 6d4b2eec67b4..390ecc915096
> > 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,
> > + .
Re: DVB-S PCI card regression on 4.19 / 4.20
In data martedì 20 novembre 2018 10:18:10 CET, Mauro Carvalho Chehab ha
scritto:
> Em Tue, 20 Nov 2018 09:07:57 +0100
>
> stakanov escreveu:
> > In data martedì 20 novembre 2018 00:58:41 CET, Mauro Carvalho Chehab ha
> >
> > scritto:
> > > Em Tue, 20 Nov 2018 00:19:54 +0100
> > >
> > > stakanov escreveu:
> > > > In data martedì 20 novembre 2018 00:08:45 CET, Mauro Carvalho Chehab
> > > > ha
> > > >
> > > > scritto:
> > > > > uname -a
> > > > >
> > > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP PREEMPT
> > > > > > Mon
> > > > > > Nov 19
> > > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux
> > > >
> > > > uname -a
> > > >
> > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP PREEMPT Mon
> > > > > Nov
> > > > > 19
> > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux
> > > >
> > > > from
> > > > https://download.opensuse.org/repositories/home:/tiwai:/bsc1116374/
> > > > standard/x86_64/
> > > >
> > > > So I booted this one, should be the right one.
> > > > sudo dmesg | grep -i b2c2 should give these additional messages?
> > > >
> > > > If Takashi is still around, he could confirm.
> > >
> > > Well, if the patch got applied, you should now be getting messages
> > > similar
> > >
> > > (but not identical) to:
> > > dvb_frontend_get_frequency_limits: frequencies: tuner:
> > > 915...215,
> > >
> > > frontend: 915...215 dvb_pll_attach: delsys: 5, frequency range:
> > > 915..215
> > >
> > > > _
> > > >
> > > > Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln
> > > > und
> > > > alte E-Mail-Adresse mitnehmen! https://www.eclipso.de
> > >
> > > Thanks,
> > > Mauro
> >
> > My bad.
> > With just dmesg:
> >
> > [ 89.399887] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > 95...215, frontend: 95000...215000
> > [ 95.020149] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > 95...215, frontend: 95000...215000
> > [ 95.152049] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > 95...215, frontend: 95000...215000
> > [ 95.152058] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> > frequency 188 out of range (95..2150)
> > [ 98.356539] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > 95...215, frontend: 95000...215000
> > [ 98.480372] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > 95...215, frontend: 95000...215000
> > [ 98.480381] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> > frequency 1587500 out of range (95..2150)
> > [ 100.016823] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > 95...215, frontend: 95000...215000
> > [ 100.140619] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > 95...215, frontend: 95000...215000
> > [ 100.140629] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> > frequency 1353500 out of range (95..2150)
> > [ 105.361166] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > 95...215, frontend: 95000...215000
> > [ 105.492972] dvb_frontend_get_frequency_limits: frequencies: tuner:
> > 95...215, frontend: 95000...215000
> > [ 105.492977] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> > frequency 1944750 out of range (95..2150)
> >
> >
> > Which is, I guess the info you need?
>
> Yes, partially. Clearly, the problem is coming from the tuner, with is
> not reporting the frequency in Hz, but I was hoping to see another
> message from the tuner driver, in order for me to be sure about what's
> happening there.
>
> Didn't you get any message that starts with "dvb_pll_attach"?
>
> The thing with Flexcop is that there are several variations, each one
> with a different tuner driver.
>
> Anyway, I guess I found the trouble: it is trying to use the DVB
> cache to check the delivery system too early (at attach time).
>
> I suspect that the enclosed patch will fix the issue. Could you please
> test it?
>
> Thanks!
> Mauro
>
>
> diff --git a/drivers/media/dvb-frontends/dvb-pll.c
> b/drivers/media/dvb-frontends/dvb-pll.c index 6d4b2eec67b4..390ecc915096
> 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 = {
>
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, &p->capabilities);
>> +fill_buf_caps_vdev(vdev, &p->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, &p->capabilities);
>> +fill_buf_caps_vdev(vdev, &p->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, &p->capabilities);
> + fill_buf_caps_vdev(vdev, &p->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, &p->capabilities);
> + fill_buf_caps_vdev(vdev, &p->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
Re: DVB-S PCI card regression on 4.19 / 4.20
Em Tue, 20 Nov 2018 09:07:57 +0100
stakanov escreveu:
> In data martedì 20 novembre 2018 00:58:41 CET, Mauro Carvalho Chehab ha
> scritto:
> > Em Tue, 20 Nov 2018 00:19:54 +0100
> >
> > stakanov escreveu:
> > > In data martedì 20 novembre 2018 00:08:45 CET, Mauro Carvalho Chehab ha
> > >
> > > scritto:
> > > > uname -a
> > > >
> > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP PREEMPT Mon
> > > > > Nov 19
> > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > uname -a
> > >
> > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP PREEMPT Mon Nov
> > > > 19
> > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > from https://download.opensuse.org/repositories/home:/tiwai:/bsc1116374/
> > > standard/x86_64/
> > >
> > > So I booted this one, should be the right one.
> > > sudo dmesg | grep -i b2c2 should give these additional messages?
> > >
> > > If Takashi is still around, he could confirm.
> >
> > Well, if the patch got applied, you should now be getting messages similar
> > (but not identical) to:
> >
> > dvb_frontend_get_frequency_limits: frequencies: tuner:
> > 915...215,
> > frontend: 915...215 dvb_pll_attach: delsys: 5, frequency range:
> > 915..215
> >
> > > _
> > >
> > > Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und
> > > alte E-Mail-Adresse mitnehmen! https://www.eclipso.de
> > Thanks,
> > Mauro
>
>
> My bad.
> With just dmesg:
>
> [ 89.399887] dvb_frontend_get_frequency_limits: frequencies: tuner:
> 95...215, frontend: 95000...215000
> [ 95.020149] dvb_frontend_get_frequency_limits: frequencies: tuner:
> 95...215, frontend: 95000...215000
> [ 95.152049] dvb_frontend_get_frequency_limits: frequencies: tuner:
> 95...215, frontend: 95000...215000
> [ 95.152058] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> frequency 188 out of range (95..2150)
> [ 98.356539] dvb_frontend_get_frequency_limits: frequencies: tuner:
> 95...215, frontend: 95000...215000
> [ 98.480372] dvb_frontend_get_frequency_limits: frequencies: tuner:
> 95...215, frontend: 95000...215000
> [ 98.480381] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> frequency 1587500 out of range (95..2150)
> [ 100.016823] dvb_frontend_get_frequency_limits: frequencies: tuner:
> 95...215, frontend: 95000...215000
> [ 100.140619] dvb_frontend_get_frequency_limits: frequencies: tuner:
> 95...215, frontend: 95000...215000
> [ 100.140629] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> frequency 1353500 out of range (95..2150)
> [ 105.361166] dvb_frontend_get_frequency_limits: frequencies: tuner:
> 95...215, frontend: 95000...215000
> [ 105.492972] dvb_frontend_get_frequency_limits: frequencies: tuner:
> 95...215, frontend: 95000...215000
> [ 105.492977] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0
> frequency 1944750 out of range (95..2150)
>
>
> Which is, I guess the info you need?
Yes, partially. Clearly, the problem is coming from the tuner, with is
not reporting the frequency in Hz, but I was hoping to see another
message from the tuner driver, in order for me to be sure about what's
happening there.
Didn't you get any message that starts with "dvb_pll_attach"?
The thing with Flexcop is that there are several variations, each one
with a different tuner driver.
Anyway, I guess I found the trouble: it is trying to use the DVB
cache to check the delivery system too early (at attach time).
I suspect that the enclosed patch will fix the issue. Could you please
test it?
Thanks!
Mauro
diff --git a/drivers/media/dvb-frontends/dvb-pll.c
b/drivers/media/dvb-frontends/dvb-pll.c
index 6d4b2eec67b4..390ecc915096 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
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, &p->capabilities);
+ fill_buf_caps_vdev(vdev, &p->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, &p->capabilities);
+ fill_buf_caps_vdev(vdev, &p->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
>>> +
Re: [PATCH v4 4/4] media: i2c: Add RDACM20 driver
Hi Kieran,
On Fri, Nov 02, 2018 at 03:47:23PM +, Kieran Bingham wrote:
> From: Kieran Bingham
>
> The RDACM20 is a GMSL camera supporting 1280x800 resolution images
> developed by IMI based on an Omnivision 10635 sensor and a Maxim MAX9271
> GMSL serializer.
>
> The GMSL link carries power, control (I2C) and video data over a
> single coax cable.
>
> Signed-off-by: Jacopo Mondi
> Signed-off-by: Laurent Pinchart
> Signed-off-by: Niklas Söderlund
> Signed-off-by: Kieran Bingham
>
> ---
> v2:
> - Fix MAINTAINERS entry
>
> v3:
> - Use new V4L2_MBUS_CSI2_DPHY bus type
> - Remove 'always zero' error print
> - Fix module description
> ---
> MAINTAINERS | 10 +
> drivers/media/i2c/Kconfig | 11 +
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/rdacm20-ov10635.h | 953
> drivers/media/i2c/rdacm20.c | 635 ++
> 5 files changed, 1610 insertions(+)
> create mode 100644 drivers/media/i2c/rdacm20-ov10635.h
> create mode 100644 drivers/media/i2c/rdacm20.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 745f0fd1fff1..26ef20087a43 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12230,6 +12230,16 @@ S: Supported
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> F: tools/testing/selftests/rcutorture
>
> +RDACM20 Camera Sensor
> +M: Jacopo Mondi
> +M: Kieran Bingham
> +M: Laurent Pinchart
> +M: Niklas Söderlund
I'm happy to see this will be well maintained. :-)
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/media/i2c/rdacm20.txt
> +F: drivers/media/i2c/rdacm20*
> +
> RDC R-321X SoC
> M: Florian Fainelli
> S: Maintained
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index eadc00bdd3bf..5eded5e337ec 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -989,6 +989,17 @@ config VIDEO_S5C73M3
> This is a V4L2 sensor driver for Samsung S5C73M3
> 8 Mpixel camera.
>
> +config VIDEO_RDACM20
> + tristate "IMI RDACM20 camera support"
> + depends on I2C && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
> + select V4L2_FWNODE
> + help
> + This driver supports the IMI RDACM20 GMSL camera, used in
> + ADAS systems.
> +
> + This camera should be used in conjunction with a GMSL
> + deserialiser such as the MAX9286.
> +
> comment "Flash devices"
>
> config VIDEO_ADP1653
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 4de7fe62b179..121d28283d45 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -111,5 +111,6 @@ obj-$(CONFIG_VIDEO_IMX274)+= imx274.o
> obj-$(CONFIG_VIDEO_IMX319) += imx319.o
> obj-$(CONFIG_VIDEO_IMX355) += imx355.o
> obj-$(CONFIG_VIDEO_MAX9286) += max9286.o
> +obj-$(CONFIG_VIDEO_RDACM20) += rdacm20.o
>
> obj-$(CONFIG_SDR_MAX2175) += max2175.o
> diff --git a/drivers/media/i2c/rdacm20-ov10635.h
> b/drivers/media/i2c/rdacm20-ov10635.h
> new file mode 100644
> index ..3c53a3262ee2
> --- /dev/null
> +++ b/drivers/media/i2c/rdacm20-ov10635.h
> @@ -0,0 +1,953 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * IMI RDACM20 camera OV10635 sensor register initialization values
> + *
> + * Copyright (C) 2017-2018 Jacopo Mondi
> + * Copyright (C) 2017-2018 Kieran Bingham
> + * Copyright (C) 2017-2018 Laurent Pinchart
> + * Copyright (C) 2017-2018 Niklas Söderlund
> + * Copyright (C) 2016 Renesas Electronics Corporation
> + * Copyright (C) 2015 Cogent Embedded, Inc.
> + *
> + */
> +
> +/*
> + * Generated by the OmniVision ov10635 sensor camera wizard for
> + * 1280x800@30/UYVY/BT601/8bit.
> + */
> +
> +#ifndef __RDACM20_OV10635_H__
> +#define __RDACM20_OV10635_H__
> +
> +#define OV10635_SENSOR_WIDTH 1312
> +#define OV10635_SENSOR_HEIGHT814
> +
> +#define OV10635_MAX_WIDTH1280
> +#define OV10635_MAX_HEIGHT 800
> +
> +/* VTS = PCLK / FPS / HTS / 2 (= 88MHz / 1572 / 30 / 2) */
> +#define OV10635_HTS 1572
> +/* FPS = 29,9998 */
> +#define OV10635_VTS 933
A part of this driver looks like a driver for an OV camera sensor. Would
there be something that prevents separating the camera sensor driver from
this one?
> +
> +struct ov10635_reg {
> + u16 reg;
> + u8 val;
> +};
> +
> +static const struct ov10635_reg ov10635_regs_wizard[] = {
> + { 0x301b, 0xff },
> + { 0x301c, 0xff },
> + { 0x301a, 0xff },
> + { 0x3011, 0x42 },
> + { 0x6900, 0x0c },
> + { 0x6901, 0x19 },
> + { 0x3503, 0x10 },
> + { 0x3025, 0x03 },
> + { 0x3003, 0x16 },
> + { 0x3004, 0x30 },
> + { 0x3005, 0x40 },
> + { 0x3006, 0x91 },
> + { 0x3600, 0x74 },
> + { 0x3601, 0x2b },
> + { 0x3612, 0x00 },
> + { 0x3611, 0x67 },
> + { 0x3633, 0xca },
> + { 0x3602, 0xaf },
> + {
Re: DVB-S PCI card regression on 4.19 / 4.20
In data martedì 20 novembre 2018 00:58:41 CET, Mauro Carvalho Chehab ha scritto: > Em Tue, 20 Nov 2018 00:19:54 +0100 > > stakanov escreveu: > > In data martedì 20 novembre 2018 00:08:45 CET, Mauro Carvalho Chehab ha > > > > scritto: > > > uname -a > > > > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP PREEMPT Mon > > > > Nov 19 > > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux > > > > uname -a > > > > > Linux silversurfer 4.20.0-rc3-1.g7e16618-default #1 SMP PREEMPT Mon Nov > > > 19 > > > 18:54:15 UTC 2018 (7e16618) x86_64 x86_64 x86_64 GNU/Linux > > > > from https://download.opensuse.org/repositories/home:/tiwai:/bsc1116374/ > > standard/x86_64/ > > > > So I booted this one, should be the right one. > > sudo dmesg | grep -i b2c2 should give these additional messages? > > > > If Takashi is still around, he could confirm. > > Well, if the patch got applied, you should now be getting messages similar > (but not identical) to: > > dvb_frontend_get_frequency_limits: frequencies: tuner: > 915...215, > frontend: 915...215 dvb_pll_attach: delsys: 5, frequency range: > 915..215 > > > _ > > > > Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und > > alte E-Mail-Adresse mitnehmen! https://www.eclipso.de > Thanks, > Mauro My bad. With just dmesg: [ 89.399887] dvb_frontend_get_frequency_limits: frequencies: tuner: 95...215, frontend: 95000...215000 [ 95.020149] dvb_frontend_get_frequency_limits: frequencies: tuner: 95...215, frontend: 95000...215000 [ 95.152049] dvb_frontend_get_frequency_limits: frequencies: tuner: 95...215, frontend: 95000...215000 [ 95.152058] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 frequency 188 out of range (95..2150) [ 98.356539] dvb_frontend_get_frequency_limits: frequencies: tuner: 95...215, frontend: 95000...215000 [ 98.480372] dvb_frontend_get_frequency_limits: frequencies: tuner: 95...215, frontend: 95000...215000 [ 98.480381] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 frequency 1587500 out of range (95..2150) [ 100.016823] dvb_frontend_get_frequency_limits: frequencies: tuner: 95...215, frontend: 95000...215000 [ 100.140619] dvb_frontend_get_frequency_limits: frequencies: tuner: 95...215, frontend: 95000...215000 [ 100.140629] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 frequency 1353500 out of range (95..2150) [ 105.361166] dvb_frontend_get_frequency_limits: frequencies: tuner: 95...215, frontend: 95000...215000 [ 105.492972] dvb_frontend_get_frequency_limits: frequencies: tuner: 95...215, frontend: 95000...215000 [ 105.492977] b2c2_flexcop_pci :06:06.0: DVB: adapter 0 frontend 0 frequency 1944750 out of range (95..2150) Which is, I guess the info you need? _ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de
