- Apr 07, 2021
-
-
Benjamin Gaignard authored
Add variant to IMX8M to enable G2/HEVC codec. Define the capabilities for the hardware up to 3840x2160. G2 doesn't have a postprocessor, uses the same clocks and has it own interrupt. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Benjamin Gaignard authored
Implement all the logic to get G2 hardware decoding HEVC frames. It supports up level 5.1 HEVC stream. It doesn't support yet 10 bits formats or the scaling feature. Add HANTRO HEVC dedicated control to skip some bits at the beginning of the slice header. That is very specific to this hardware so can't go into uapi structures. Computing the needed value is complex and requires information from the stream that only the userland knows so let it provide the correct value to the driver. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Co-developed-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Co-developed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
-
Benjamin Gaignard authored
Make sure that V4L2_PIX_FMT_HEVC_SLICE is correctly handled by the driver. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
-
Benjamin Gaignard authored
The HEVC HANTRO driver needs to know the number of bits to skip at the beginning of the slice header. That is a hardware specific requirement so create a dedicated control for this purpose. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
-
Benjamin Gaignard authored
If the variant doesn't support postprocessed formats make sure it will be ok. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
-
Benjamin Gaignard authored
Define which HEVC profiles (up to level 5.1) and features (no scaling, no 10 bits) are supported by the driver. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
-
Benjamin Gaignard authored
Change hantro_codec_ops run prototype from 'void' to 'int'. This allows the driver to cancel the job if an error occurs while configuring the hardware. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
-
Benjamin Gaignard authored
Add decode params control and the associated structure to group all the information that are needed to decode a reference frame as is described in ITU-T Rec. H.265 section "8.3.2 Decoding process for reference picture set". Adapt Cedrus driver to these changes. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
-
Benjamin Gaignard authored
Add fields and flags as they are defined in 7.4.3.3.1 "General picture parameter set RBSP semantics of the H.265 ITU specification. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
-
Benjamin Gaignard authored
In order to be able to share the control hardware block between VPUs use a syscon instead a ioremap it in the driver. To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl' phandle is not found look at 'ctrl' reg-name. With the method it becomes useless to provide a list of register names so remove it. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Benjamin Gaignard authored
Introducing the G2 hevc video decoder requires modifications of the bindings to allow one node per VPU. VPUs share one hardware control block which is provided as a phandle on a syscon. Each node has now one reg and one interrupt. Add a compatible for G2 hardware block: nxp,imx8mq-vpu-g2. To be compatible with older DT the driver is still capable to use the 'ctrl' reg-name even if it is deprecated now. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Benjamin Gaignard authored
Add 'nxp,imx8mq-vpu-ctrl' to the list of possible syscon. It will used to access the VPU control registers. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Acked-by: Rob Herring <robh@kernel.org>
-
- Apr 06, 2021
-
-
Sylwester Nawrocki authored
Fixes scripts/kernel-doc warnings: s5p_mfc_common.h:343: warning: Function parameter or member 'fw_buf' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'mem_size' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'mem_base' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'mem_bitmap' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'mem_virt' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'dma_base' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'watchdog_timer' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'fw_get_done' not described in 's5p_mfc_dev' s5p_mfc_common.h:343: warning: Function parameter or member 'risc_on' not described in 's5p_mfc_dev' s5p_mfc_common.h:714: warning: Function parameter or member 'src_bufs_cnt' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'dst_bufs_cnt' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'pb_count' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'force_frame_type' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'slice_mode' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'slice_size' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'frame_tag' not described in 's5p_mfc_ctx' s5p_mfc_common.h:714: warning: Function parameter or member 'scratch_buf_size' not described in 's5p_mfc_ctx' Reported-by: Hans verkuil <hverkuil@xs4all.nl> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sylwester Nawrocki authored
Fixes scripts/kernel-doc warnings: fimc-is.h:286: warning: Function parameter or member 'fw' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'memory' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'f_w' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'isp' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'sensor' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'setfile' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'ctrl_handler' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'irq' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'sensor_index' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'i2h_cmd' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'h2i_cmd' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'fd_header' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'config' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'config_index' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'is_p_region' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'is_dma_p_region' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'is_shared_region' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'af' not described in 'fimc_is' fimc-is.h:286: warning: Function parameter or member 'debugfs_entry' not described in 'fimc_is' The f_w field is unused so remove it. Reported-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
If the EDID has an odd number of blocks (usually just 1, but the same problem occurs with 3 blocks), then VIDIOC_G_EDID reported 2 (or 4) blocks. Fix this. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
While the adv7604/11/12 hardware supported EDIDs up to 4 blocks, the driver didn't. This patch adds support for this. It also improves support for EDIDs that do not have a Source Physical Address: in that case the spa location is set to the first byte of the second block, and the 'physical address' is just the two bytes at that location. This is per the suggestion in the adv76xx documentation for such EDIDs. Tested with an adv7604 and adv7612. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
For the adv7604 the hotplug detect pin is controlled through gpio pins from the SoC, but the adv7611 and adv7612 control the hotplug detect pin themselves. But the driver had no support for this, so the HPD was always high, even when changing the EDID. Add proper support for this to the driver. Tested with an adv7612. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Daniel Almeida authored
According to the v4l2 api, it is allowed to skip setting a control if its contents haven't changed for performance reasons: userspace should only update the controls that changed from last frame rather then updating them all. Still some ancient code that checks for mandatory controls has been left in this driver. Remove it. Fixes: cd33c830 ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Geert Uytterhoeven authored
The i.MX8 QXP/QM integrated JPEG encoder/decoder is only present on Freescale/NXP i.MX8 QXP and QM SoCs. Hence add a dependency on ARCH_MXC, to prevent asking the user about this driver when configuring a kernel without i.MX8 support. Drop the "default m" (which means "default y" if CONFIG_MODULES is not enabled), as merely enabling CONFIG_COMPILE_TEST should not enable additional code. Fixes: 2db16c6e ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Wan Jiabing authored
struct em28xx is declared at 219th line. The declaration here is unnecessary. Remove it. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Wan Jiabing authored
struct cx231xx is declared at 146th line. The declaration here is unnecessary. Remove it. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Yang Yingliang authored
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Yang Yingliang authored
There is an error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Yang Yingliang authored
There is an error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Yang Yingliang authored
There is an error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Yang Yingliang authored
There is an error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
The rx-arb-lost error injection command only works with <op> set to 'any'. Explicitly say so in the usage message. Also use [] to indicate that the <poll> argument is optional. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Fabio Estevam authored
i.MX is a DT-only platform, so of_match_ptr() can be safely removed. Remove the unneeded of_match_ptr(). Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'tw68_risc_buffer()' (tw68-risc.c) GFP_KERNEL can be used because this function is only called from a vb2_ops buf_prepare function. The call chain is: tw68_video_qops.buf_prepare (tw68-video.c) --> tw68_buf_prepare (tw68-video.c) --> tw68_risc_buffer @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'tw686x_audio_dma_alloc()' (tw686x-audio.c) GFP_KERNEL can be used because it is only called from a probe function and no spinlock is taken in the between. The call chain is: tw686x_probe (tw686x-core.c) --> tw686x_audio_init (tw686x-audio.c) --> tw686x_audio_dma_alloc (tw686x-audio.c) When memory is allocated in 'tw686x_memcpy_dma_alloc()' and in 'tw686x_sg_dma_alloc()' (tw686x-video.c) GFP_KERNEL can be used because these functions are .alloc functions from a tw686x_dma_ops structure. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'cx23885_risc_buffer()' GFP_KERNEL can be used because this function is only called from a vb2_ops buf_prepare function. The call chain is: cx23885_video_qops.buf_prepare (cx23885-video.c) --> buffer_prepare (cx23885-video.c) --> cx23885_risc_buffer When memory is allocated in 'cx23885_risc_databuffer()' GFP_KERNEL can be used because this function is only called from a function that already uses GFP_KERNEL or from a vb2_ops buf_prepare function. The call chains are: snd_cx23885_hw_params (cx23885-alsa.c) --> use GFP_KERNEL --> cx23885_risc_databuffer cx23885_qops.buffer_prepare (cx23885-417.c) or dvb_qops.buffer_prepare (cx23885-dvb.c) --> cx23885_buf_prepare --> cx23885_risc_databuffer When memory is allocated in 'cx23885_risc_vbibuffer()' GFP_KERNEL can be used because this function is only called from a vb2_ops buf_prepare function. The call chains are: cx23885_vbi_qops.buffer_prepare (cx23885-vbi.c) --> cx23885_risc_vbibuffer @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Irui Wang authored
MTK H264 Encoder(VENC_SYS) and VP8 Encoder(VENC_LT_SYS) are two independent hardware instance. They have their owner interrupt, register mapping, and special clocks. This patch separates them into two devices. This is a preparing patch for adding device_link between the larbs and venc-device. It's mainly for fixing the problem: https://lkml.org/lkml/2019/9/3/316 Acked-by: Tiffany Lin <tiffany.lin@mediatek.com> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Maoguang Meng <maoguang.meng@mediatek.com> Signed-off-by: Irui Wang <irui.wang@mediatek.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Irui Wang authored
Updates binding document since the avc and vp8 hardware encoder in MT8173 are now separated. Separate "mediatek,mt8173-vcodec-enc" to "mediatek,mt8173-vcodec-enc-vp8" and "mediatek,mt8173-vcodec-enc". This patch is not a compatible change, but we must do this modifaction because MediaTek IOMMU add the device_link between the smi-larb device and venc_device, if the venc device call the pm_runtime_get_sync, the smi-larb's pm_runtime_get_sync also be called automatically. There is a bit of backward compatibility for avc encoder, the avc encoder device node still has compatible "mediatek,mt8173-vcodec-enc". Acked-by: Tiffany Lin <tiffany.lin@mediatek.com> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Maoguang Meng <maoguang.meng@mediatek.com> Signed-off-by: Irui Wang <irui.wang@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
When a request is re-inited it will release all control handler objects that are still in the request. It does that by unbinding and putting all those objects. When the object is unbound the obj->req pointer is set to NULL, and the object's unbind op is called. When the object it put the object's release op is called to free the memory. For a request object that contains a control handler that means that v4l2_ctrl_handler_free() is called in the release op. A control handler used in a request has a pointer to the main control handler that is created by the driver and contains the current state of all controls. If the device is unbound (due to rmmod or a forced unbind), then that main handler is freed, again by calling v4l2_ctrl_handler_free(), and any outstanding request objects that refer to that main handler have to be unbound and put as well. It does that by this test: if (!hdl->req_obj.req && !list_empty(&hdl->requests)) { I.e. the handler has no pointer to a request, so is the main handler, and one or more request objects refer to this main handler. However, this test is wrong since hdl->req_obj.req is actually NULL when re-initing a request (the object unbind will set req to NULL), and the only reason this seemingly worked is that the requests list is typically empty since the request's unbind op will remove the handler from the requests list. But if another thread is at the same time adding a new control to a request, then there is a race condition where one thread is removing a control handler object from the requests list and another thread is adding one. The result is that hdl->requests is no longer empty and the code thinks that a main handler is being freed instead of a control handler that is part of a request. There are two bugs here: first the test for hdl->req_obj.req: this should be hdl->req_obj.ops since only the main control handler will have a NULL pointer there. The second is that adding or deleting request objects from the requests list of the main handler isn't protected by taking the main handler's lock. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by: John Cox <jc@kynesim.co.uk> Fixes: 6fa6f831 ("media: v4l2-ctrls: add core request support") Tested-by: John Cox <jc@kynesim.co.uk> Reported-by: John Cox <jc@kynesim.co.uk> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
This read-only int32 control is used to test read-only controls in combination with requests. It is set by the driver to the buffer sequence counter module 256. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Stanimir Varbanov authored
Fixes an issue when issuing a stop command to the controller, negating the following firmware error. "SFR message from FW: Exception: TID = Unknown IP = 0x3b7dc FA = 0x0 cause = 0x6" Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dikshita Agarwal authored
Decide work mode for encoder and decoder based on different use-cases. Signed-off-by: Dikshita Agarwal <dikshita@codeaurora.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dikshita Agarwal authored
Presently, minimum buffer count for output buffers for h264 & hevc codec is kept as 8 which might not be sufficient for few use cases so increasing the value to 18. Signed-off-by: Dikshita Agarwal <dikshita@codeaurora.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dikshita Agarwal authored
Set actual plane alignments to FW with HFI_PROPERTY_PARAM_UNCOMPRESSED_PLANE_ACTUAL_CONSTRAINTS_INFO to calculate correct buffer size. bod: Fixed fall-through error in pkt_session_set_property_6xx() switch Ensure setting format constraints on 6xx only Signed-off-by: Dikshita Agarwal <dikshita@codeaurora.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dikshita Agarwal authored
- Internal buffers required by v6 are different than v4, add new list of internal buffers for v6. - Differentiate encoder/decoder buffers for 6xx Signed-off-by: Dikshita Agarwal <dikshita@codeaurora.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-