- 06 Apr, 2021 40 commits
-
-
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:
-
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:
-
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 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: -
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/316Acked-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:
-
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:
Rob Herring <robh@kernel.org> Signed-off-by:
-
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:John Cox <jc@kynesim.co.uk> Fixes: 6fa6f831 ("media: v4l2-ctrls: add core request support") Tested-by:
-
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:
-
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:
-
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:
-
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 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 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 authored
Do not toggle the WRAPPER_A9SS_SW_RESET on 6xx. Signed-off-by:
-
Dikshita Agarwal authored
When in vcodec_control_v4() on the 4xx path we select between one of two vcodec cores to toggle power control bits. In 6xx there is only one core which offsets the relevant control registers to a slightly different address. This patch accounts for the address offset for 6xx silicon. Signed-off-by:
-
Dikshita Agarwal authored
This patch takes the downstream AXI halt routine and applies it when IS_V6() is true. bod: Converted to readl_poll_timeout() Removed poll timeout for LPI register, testing showed the value would always timeout and work, so the polling did nothing of value. Signed-off-by: -
Dikshita Agarwal authored
Vote for min clk frequency for core clks during prepare and enable clocks at boot sequence. Without this the controller clock runs at very low value (9.6MHz) which is not sufficient to boot venus. Signed-off-by:
-
Bryan O'Donoghue authored
At this time there is no need to differentiate between the two, we can reuse the 4xx pm ops callback structure for 6xx. Signed-off-by:
-
Bryan O'Donoghue authored
In various places in the venus codebase we have if (IS_V4()) which takes the code down paths for 4xx silicon. This logic is broadly applicable to 6xx silicon also. In this patch we add IS_V6() to various IS_V4() decision locations. Co-developed-by:
Dikshita Agarwal <dikshita@qti.qualcomm.com> Signed-off-by:
-
Bryan O'Donoghue authored
On 6xx we should read wrapper cpu status from the wrapper TZ register set. Co-developed-by:
Jonathan Marek <jonathan@marek.ca> Signed-off-by:
-
Dikshita Agarwal authored
This commit adds 6xx specific interrupt support, some register offsets and bitmasks differ from 4xx, which we account for in this commit. [bod: Added commit log. Moved register definition into commit] Signed-off-by:
-
Dikshita Agarwal authored
This patch adds a 6xx specific boot logic. The goal is to share as much code as possible between 3xx, 4xx and 6xx silicon. We need to do a different write to WRAPPER_INTR_MASK with an additional write to CPU_CS_H2XSOFTINTEN_V6 and CPU_CS_X2RPMh_V6. The other writes are the same for 6xx and non-6xx silicon albeit at different absolute relative locations to the base of the venus address space. Signed-off-by:
-
Bryan O'Donoghue authored
This commit points the IO base registers 6xx offsets when probing for 6xx hardware. Signed-off-by:
-
Bryan O'Donoghue authored
6xx silicon needs to access registers from a AON base address range. This commit defines the necessary variable for later use. Signed-off-by:
-
Bryan O'Donoghue authored
6xx silicon needs to access registers from a wrapper trust-zone base address range. This commit defines the necessary variable for later use. Signed-off-by:
-
Bryan O'Donoghue authored
This commit adds the macro helper IS_V6() which will be used to differentiate iris2/v6 silicon from previous versions. Signed-off-by:
-
Dikshita Agarwal authored
- Add X2 RPMh registers and definitions from the downstream example. - Add 6xx core power definitions - Add 6xx AON definitions - Add 6xx wrapper tz definitions - Add 6xx wrapper interrupt definitions - Add 6xx soft interrupt definitions - Define wrapper LPI register offsets Signed-off-by:
-
Dikshita Agarwal authored
This commit defines a range of new base addresses for already defined blocks. - CPU_BASE_V6 - CPU_CS_BASE_V6 - CPU_IC_BASE_V6 - WRAPPER_BASE_V6 The base addresses of the blocks are slightly different for 6xx but, aside from that are layout and bit compatible. New 6xx specific block addresses will be added in separate commits. Signed-off-by:
-
Bryan O'Donoghue authored
An upcoming silicon change places a number of existing blocks within the Venus at different relative offsets to the base address of IO region. In order to handle this difference this patch changes the address offsets of the registers to function as offsets relative to the relevant sub-block of registers within the IO region not the base address of the IO region. As a result of this change venus_readl() and venus_writel() are deleted. Co-developed-by:
-
Bryan O'Donoghue authored
New silicon means that the pre-determined offsets we have been using in this driver no longer hold. Existing blocks of registers can exist at different offsets relative to the IO base address. This commit adds a routine to assign the IO base hooks a subsequent commit will convert from absolute to relative addressing. Signed-off-by:
-
Bryan O'Donoghue authored
Adds an sm8250 compatible binding to the venus core. Co-developed-by:
-
Stanimir Varbanov authored
The Venus driver has to control two reset signals related to gcc video_axi0 and videocc mvs0c for v6. Add it. Signed-off-by:
-
Bryan O'Donoghue authored
Currently hfi_platform_v6.c adds a bunch of capability parameters. Reviewing downstream we can see a number of these need to be updated. techpack/video/msm/vidc/msm_vidc_platform.c :: kona_capabilities[] Signed-off-by:
-
Stanimir Varbanov authored
Create CLL and Mastering display colour volume v4l2 controls for encoder, add handling of HDR10 PQ SEI packet payloads for v4. Signed-off-by:
-
Stanimir Varbanov authored
Document Content Light Level and Mastering Display v4l2 colorimetry controls. Signed-off-by:
-
Stanimir Varbanov authored
Introduce Content light level and Mastering display colour volume Colorimetry compound controls with relevant payload structures and validation. Signed-off-by:
-
Stanimir Varbanov authored
Add a document for ext control colorimetry class. Signed-off-by:
-
Stanimir Varbanov authored
Add Colorimetry control class for colorimetry controls Signed-off-by:
-
Stanimir Varbanov authored
Adds support for decoder conceal color control. Signed-off-by:
-
