- 07 Dec, 2023 22 commits
-
-
Michael Tretter authored
The RGA driver allocates two buffers for the DMA descriptors of the input and output buffers. Whenever a new job is processed, the descriptor list is updated for the current buffers. By updating the descriptor list during buf_prepare, it is possible to correctly fail DMABUF imports if the buffers that shall be imported are not within the 32 bit address range that can be addressed by the RGA. Managing the DMA descriptor list with the buffer also makes it easier to track the buffer mapping and the plane offsets into this mapping. The cost is that the driver now requires DMA coherent memory per buffer for the descriptor list. However, the size scales with the size of the video buffers and is not allocated if the RGA is not used. While at it, use dma_alloc_coherent to allocate the descriptors and get rid of the virt_to_phys calls to get the physical addresses. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl>
-
Michael Tretter authored
The IOMMU of the RGA is programmed with a list of DMA descriptors that contain an 32 bit address per 4k page in the video buffers. The address in the descriptor points to the start address of the page. Introduce 'struct rga_dma_desc' to make the handling of the DMA descriptors explicit instead of hiding them behind standard types. While at it, use provided helpers for iterating the sg_table instead of manually calculating the DMA addresses. Signed-off-by:
-
Michael Tretter authored
When using 32 bit RGB formats, the RGA on the rk3568 produces wrong colors as the wrong color channels are read or written. The reason is that the format description for the channel swizzeling is wrong and the wrong bits are configured. For example, when converting ARGB32 to NV12, the alpha channel is used as blue channel.. This doesn't happen if the color format is the same on both sides. Fix the color_swap settings of the formats to correctly handle 32 bit RGB formats. For RGA_COLOR_FMT_XBGR8888, the RGA_COLOR_ALPHA_SWAP bit doesn't have an effect. Thus, it isn't possible to handle the V4L2_PIX_FMT_XRGB32. Thus, it is removed from the list of supported formats. Signed-off-by:
-
Bryan O'Donoghue authored
Declare power-domain names "top", "ife0" and "ife1" eponymously for the power-domains TITAN_TOP_GDSC, IFE_0_GDSC and IFE_1_GDSC respectively. Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
-
Matti Lehtimäki authored
Some platforms such as SC7280 have 3 CSIDs and 2 CSID-lites but current code has hardcoded 2 as the maximum number of CSIDs. Remove the hardcoded maximum number of VFEs to handle all possible combinations of CSIDs and CSID-lites. Signed-off-by:
Matti Lehtimäki <matti.lehtimaki@gmail.com> Signed-off-by:
-
Matti Lehtimäki authored
Some platforms such as SC7280 have three VFEs and two VFE-lites. Current code has hard-coded two as the maximum number of VFEs. Remove the hard-coded maximum number of VFEs to handle all possible combinations of VFEs and VFE-lites. Signed-off-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311200405.h6G4L9oe-lkp@intel.comSigned-off-by:
-
Bryan O'Donoghue authored
Right now we use fixed indexes to assign power-domains, with a requirement for the TOP GDSC to come last in the list. Adding support for named power-domains means the declaration in the dtsi can come in any order. After this change we continue to support the old indexing - if a SoC resource declaration or the in-use dtb doesn't declare power-domain names we fall back to the default legacy indexing. From this point on though new SoC additions should contain named power-domains, eventually we will drop support for legacy indexing. Tested-by:
-
Bryan O'Donoghue authored
Moving the location of the hooks to VFE power domains has several advantages. 1. Separation of concerns and functional decomposition. vfe.c should be responsible for and know best how manage power-domains for a VFE, excising from camss.c follows this principle. 2. Embedding a pointer to genpd in struct camss_vfe{} meas that we can dispense with a bunch of kmalloc array inside of camss.c. 3. Splitting up titan top gdsc from vfe/ife gdsc provides a base for breaking up magic indexes in dtsi. Suggested-by: -
Bryan O'Donoghue authored
For the various versions of VFE we have a boiler-plate pm_domain_on/pm_domain_off callback pair of the general form. - Error check. Not always done but applicable to all. - device_link_add (DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE); - Error check returning -EINVAL on error. - Return 0 Reduce the pattern down to a common callback. VFE 4.1 is a special case which to me also indicates that it is worthwhile maintaining an indirection for the vfe_pm_domain_{on|off} for now. Otherwise lets chuck out a bunch of needlessly replicated code. Reviewed-by: -
Bryan O'Donoghue authored
Right now we use the top-level camss structure to provide pointers via VFE id index back to genpd linkages. In effect this hard-codes VFE indexes to power-domain indexes in the dtsi and mandates a very particular ordering of power domains in the dtsi, which bears no relationship to a real hardware dependency. As a first step to rationalising the VFE power-domain code and breaking the magic indexing in dtsi use per-VFE pointers to genpd linkages. The top-level index in msm_vfe_subdev_init is still used to attain the initial so no functional or logical change arises from this change. Reviewed-by:
-
Bryan O'Donoghue authored
At the moment we have some complex code for determining if a VFE requires a power-domain attachment. Particularly discordant in this scheme is the subtle reliance on VFE and VFE Lite declaration ordering in our resources. VFE id is used to determine if a VFE is lite or not and consequently if a VFE requires power-domain attachment. VFE Lite though is not a correct delineation between power-domain and non power-domain state since early SoCs have neither VFE Lite nor power-domains attached to VFEs. Introduce has_pd to the VFE resource structure to allow the CAMSS code to understand if it needs to try to attach a power-domain for a given VFE. As a side-effect from this we no longer need to care about VFE Lite or non-Lite or the id number associated with either and which order the VFE/VFE Lite was declared in. Reviewed-by:
-
Ghanshyam Agrawal authored
The function stk1160_dbg gets called too many times, which causes the output to get flooded with messages. Since stk1160_dbg uses printk, it is now replaced with printk_ratelimited. Suggested-by:
Phillip Potter <phil@philpotter.co.uk> Signed-off-by:
Ghanshyam Agrawal <ghanshyam1898@gmail.com> Signed-off-by:
-
Zhipeng Lu authored
The dma_q->p_left_data alloced by kzalloc should be freed in all the following error handling paths. However, it hasn't been freed in the allocation error paths of dev->video_mode.isoc_ctl.urb and dev->video_mode.isoc_ctl.transfer_buffer. On the other hand, the dma_q->p_left_data did be freed in the error-handling paths after that of dev->video_mode.isoc_ctl.urb and dev->video_mode.isoc_ctl.transfer_buffer, by calling cx231xx_uninit_isoc(dev). So the same free operation should be done in error-handling paths of those two allocation. Fixes: 64fbf444 ("[media] cx231xx: Added support for Carraera, Shelby, RDx_253S and VIDEO_GRABBER") Signed-off-by:
Zhipeng Lu <alexious@zju.edu.cn> Signed-off-by:
-
Geert Uytterhoeven authored
The StarFive Camera Subsystem is only present on the StarFive JH7110 SoC. Hence add a dependency on ARCH_STARFIVE, to prevent asking the user about this driver when configuring a kernel without StarFive SoC support. Fixes: bba185d1 ("media: staging: media: starfive: camss: Add core driver") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Changhuang Liang <changhuang.liang@starfivetech.com> Signed-off-by:
-
Geert Uytterhoeven authored
The Chips&Media Wave 5 Series multi-standard codec IP is currently only supported on Texas Instruments K3 architecture. Hence add a dependency on ARCH_K3, to prevent asking the user about this driver when configuring a kernel without Texas Instruments K3 Multicore SoC support. Fixes: 9707a625 ("media: chips-media: wave5: Add the v4l2 layer") Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
-
Dan Carpenter authored
These > comparisons should be >=. The formats->fmts[] array is either a pointer to isp_formats_sink[] or isp_formats_source[] respectively. Fixes: e5785462 ("media: staging: media: starfive: camss: Add ISP driver") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
-
Michael Grzeschik authored
For dmabuf import users to be able to use the vaddr from another videobuf2-dma-sg source, the exporter needs to set a proper vaddr on vb2_dma_sg_dmabuf_ops_vmap callback. This patch adds vmap on map if buf->vaddr was not set. Cc: stable@kernel.org Fixes: 7938f421 ("dma-buf-map: Rename to iosys-map") Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
-
Detlev Casanova authored
Add AV1 information in visl documentation. Reviewed-by:
Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by:
Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by:
-
Detlev Casanova authored
Let the visl test driver accept the AV1 pixel format. Reviewed-by:
-
Lukas Bulwahn authored
Defines prefixed with "CONFIG" should be limited to proper Kconfig options, that are introduced in a Kconfig file. In the driver code, there is a define for CONFIG_VB2_GSC_DMA_CONTIG, but this is not used anywhere in the code. Just remove this unused definition. No functional change. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
AngeloGioacchino Del Regno authored
Instead of walking the entire parent node for something that has the right compatible, use the scp_get() function provided by the MediaTek SCP remoteproc driver to retrieve a handle to mtk_scp through the devicetree "mediatek,scp" (phandle) property. In case of multi-core SCP, this also allows to select a specific core. Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by:
-
AngeloGioacchino Del Regno authored
The MDP3 RDMA needs to communicate with the SCP remote processor: allow specifying a phandle to a SCP core. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
-
- 04 Dec, 2023 18 commits
-
-
Sebastian Reichel authored
v4l2_async_unbind_subdev_one(), which is called in the line following the list_move() operation contains list_move_tail() for the same entry and overrides anything list_move() did. Thus it can be removed. Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Sebastian Reichel authored
The list deletion call dropped here is already called from the helper function in the line before. Having a second list_del() call results in either a warning (with CONFIG_DEBUG_LIST=y): list_del corruption, c46c8198->next is LIST_POISON1 (00000100) If CONFIG_DEBUG_LIST is disabled the operation results in a kernel error due to NULL pointer dereference. Fixes: 28a12957 ("media: v4l: async: Allow multiple connections between entities") Signed-off-by:
-
Laurent Pinchart authored
Fix a simple indentation issue in the v4l2-subdev.h header. Fixes: f57fa295 ("media: v4l2-subdev: Add new ioctl for client capabilities") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
Use V4L2 CCI for accessing device's registers. The 8-bit compatibility read option is removed but this is supported by regmap through other means. Also the CCS register definitions are re-generated with V4L2 CCI definitions. The older SMIA++ register definitions have been manually converted. Signed-off-by:
-
Sakari Ailus authored
Separate CCS static data read-only register access in ccs-reg-access.c by naming them differently. The code in this file generally deals with reading and writing registers where as static data (when it comes to ccs_static_data_read_ro_reg()) contains the read-only register values but no hardware registers are accessed in that case. Signed-off-by:
-
Sakari Ailus authored
Generate register definitions that are fit for use with V4L2 CCI. Signed-off-by:
-
Sakari Ailus authored
Add CCI_REG_WIDTH() macro to obtain register width in bits and similarly, CCI_REG_WIDTH_BYTES() to obtain it in bytes. Also add CCI_REG_ADDR() macro to obtain the address of a register. Use both macros in v4l2-cci.c, too. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Sakari Ailus authored
Provide a few bits for drivers to store private information on register definitions. Signed-off-by:
-
Sakari Ailus authored
linux/bits.h is needed for GENMASK(). Include it. Signed-off-by:
-
Laurent Pinchart authored
The isc_try_fse() function, called from isc_validate(), takes two parameters, an isc_device pointer, and a v4l2_subdev_state pointer. The isc_device is accessed but not modified by the function. The state is modified, including the struct v4l2_subdev_pad_config array it points to, but they are then never used by the caller. Furthermore, the V4L2 subdev operation called by isc_try_fse() doesn't modify the subdev it is called on. The isc_try_fse() function has thus no effect, and can just be dropped. Signed-off-by:
Eugen Hristev <eugen.hristev@collabora.com> Tested-by:
-
Sakari Ailus authored
Document that sub-device initialisation needs to complete before the async sub-device is registered as there is no further driver action needed before the sensor becomes accessible via the UAPI. Signed-off-by:
-
Sakari Ailus authored
As the sensor may be accessible right after its async sub-device is registered, enable runtime PM before doing so. Signed-off-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
A number of CCS register value limits are in ireal or float format. Also convert them to integers for easier interpretation. Signed-off-by:
-
Bingbu Cao authored
As the sensor device maybe accessible right after its async sub-device is registered, such as ipu-bridge will try to power up sensor by sensor's client device's runtime PM from the async notifier callback, if runtime PM is not enabled, it will fail. So runtime PM should be ready before its async sub-device is registered and accessible by others. Fixes: d3f863a6 ("media: i2c: Add ov9734 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
-
Bingbu Cao authored
As the sensor device maybe accessible right after its async sub-device is registered, such as ipu-bridge will try to power up sensor by sensor's client device's runtime PM from the async notifier callback, if runtime PM is not enabled, it will fail. So runtime PM should be ready before its async sub-device is registered and accessible by others. Fixes: 7ee85054 ("media: Add sensor driver support for the ov13b10 camera.") Cc: stable@vger.kernel.org Signed-off-by:
-
Bingbu Cao authored
As the sensor device maybe accessible right after its async sub-device is registered, such as ipu-bridge will try to power up sensor by sensor's client device's runtime PM from the async notifier callback, if runtime PM is not enabled, it will fail. So runtime PM should be ready before its async sub-device is registered and accessible by others. It also sets the runtime PM status to active as the sensor was turned on by i2c-core. Fixes: 0827b58d ("media: i2c: add ov01a10 image sensor driver") Cc: stable@vger.kernel.org Signed-off-by:
-
Bingbu Cao authored
As the sensor device maybe accessible right after its async sub-device is registered, such as ipu-bridge will try to power up sensor by sensor's client device's runtime PM from the async notifier callback, if runtime PM is not enabled, it will fail. So runtime PM should be ready before its async sub-device is registered and accessible by others. Fixes: df0b5c4a ("media: add imx355 camera sensor driver") Cc: stable@vger.kernel.org Signed-off-by:
-
Hugues Fruchet authored
This V4L2 subdev driver enables Digital Camera Memory Interface Pixel Processor(DCMIPP) of STMicroelectronics STM32 SoC series. Signed-off-by:
Hugues Fruchet <hugues.fruchet@foss.st.com> Signed-off-by:
Alain Volmat <alain.volmat@foss.st.com> Signed-off-by:
-
