The field is not part of the structure. Remove the doc.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Those fields have been removed. They do not need to be documented.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The field is gone, remove the documentation for it.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The field is gone, remove the documentation.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Kerneldoc does not seem to understand that embed doc:
drivers/media/i2c/ccs/ccs-quirk.h:50: warning: Excess struct member 'write' description in 'ccs_quirk'
drivers/media/i2c/ccs/ccs-quirk.h:50: warning: Excess struct member 'reg' description in 'ccs_quirk'
drivers/media/i2c/ccs/ccs-quirk.h:50: warning: Excess struct member 'val' description in 'ccs_quirk'
Convert into a standard doc.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The field is gone, remove it.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The fields are gone, remove their documentation.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Named nested unions need their prefix:
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#nested-structs-unions
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The valid_la is used to check the length requirements,
including special cases of Timer Status. If the length is
shorter than 5, that means no Duration Available is returned,
the message will be forced to be invalid.
However, the description of Duration Available in the spec
is that this parameter may be returned when these cases, or
that it can be optionally return when these cases. The key
words in the spec description are flexible choices.
Remove the special length check of Timer Status to fit the
spec which is not compulsory about that.
Signed-off-by: Nini Song <nini.song@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
VIDIOC_LOG_STATUS will log the controls owned by the driver. But the
code didn't take into account the case where a single driver creates
multiple control handlers. A good example is the vivid driver, but
others use it as well.
Modify v4l2_ctrl_handler_log_status() so that it really shows all
controls owned by this driver.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The last argument of v4l2_ctrl_add_handler() indicates whether the controls
you add are from a control handler owned by another driver (true) or from
the same driver (false). In this case the last argument was incorrectly set
to false. The controls come from the cx25840 subdev.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Static analyzers generate alerts for an unchecked call to
`media_device_register()`. However, in this case, the device will work
reliably without the media controller API.
Add a comment above the call to prevent future unnecessary changes.
Suggested-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Fixes: 37ecc7b127 ("[media] em28xx: add media controller support")
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The documented struct member is called "planes" rather than "vb2_plane".
While at it, make the comments order follow struct members order.
Fixes: 2b14132455 ("media: vb2-core: Improve kernel-doc markups")
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Acked-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
ERROR: else should follow close brace '}'
Signed-off-by: Bhavin Sharma <bhavin.sharma@siliconsignals.io>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
In xc4000_get_frequency():
*freq = priv->freq_hz + priv->freq_offset;
The code accesses priv->freq_hz and priv->freq_offset without holding any
lock.
In xc4000_set_params():
// Code that updates priv->freq_hz and priv->freq_offset
...
xc4000_get_frequency() and xc4000_set_params() may execute concurrently,
risking inconsistent reads of priv->freq_hz and priv->freq_offset. Since
these related data may update during reading, it can result in incorrect
frequency calculation, leading to atomicity violations.
This possible bug is found by an experimental static analysis tool
developed by our team, BassCheck[1]. This tool analyzes the locking APIs
to extract function pairs that can be concurrently executed, and then
analyzes the instructions in the paired functions to identify possible
concurrency bugs including data races and atomicity violations. The above
possible bug is reported when our tool analyzes the source code of
Linux 6.2.
To address this issue, it is proposed to add a mutex lock pair in
xc4000_get_frequency() to ensure atomicity. With this patch applied, our
tool no longer reports the possible bug, with the kernel configuration
allyesconfig for x86_64. Due to the lack of associated hardware, we cannot
test the patch in runtime testing, and just verify it according to the
code logic.
[1] https://sites.google.com/view/basscheck/
Fixes: 4c07e32884 ("[media] xc4000: Fix get_frequency()")
Cc: stable@vger.kernel.org
Reported-by: BassCheck <bass@buaa.edu.cn>
Signed-off-by: Gui-Dong Han <2045gemini@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Function hantro_g1_h264_dec_prepare_table() does not exist,
should be replaced with hantro_h264_dec_init().
The register name av1_ulticore_tile_col confused sometimes,
although not be used corrently. The correct name should be
av1_multicore_tile_col.
Signed-off-by: renjun wang <renjunw0@foxmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The struct v4l2_subdev_client_capability was never actually documented,
only the capability flags were documented.
Add this.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
cx23885_vdev_init() can return a NULL pointer, but that pointer
is used in the next line without a check.
Add a NULL pointer check and go to the error unwind if it is NULL.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reported-by: Sicong Huang <huangsicong@iie.ac.cn>
Following formula of Pll_clk in 5.2 section, 50th page of
TC358746AXBG/748XBG/748IXBG Functional Specification Rev 1.1 document.
The formula of fout is as below:
fout = refclk * mul / (prediv * postdiv)
Remove "p" to avoid using 2 times of prediv in pll calculating function.
Signed-off-by: Duc-Long, Le <duclong.linux@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Because video duration involves calculating the streaming time, and i2c
communication incurs too many XTALK register settings every 4 bytes with
i2c START and STOP.
So we have opted switch to the i2c burst method.
This method involves writing the XTALK registers in the order of
the register block.
The start streaming time can be reduced from around 400ms to 150ms
[Sakari Ailus: Drop unneeded dev_dbg().]
Signed-off-by: Jason Chen <jason.z.chen@intel.com>
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
ov08x40 quad bayer sensor ISP has the following work modes:
- normal mode: full size
- 2x2 binned mode: binning size
In normal and binned modes, different tline calculations are
applied.
- normal mode: Tline value needs to be doubled as per the
vendor's update.
Tline time = 2 * HTS / SCLK
Exposure unit : 1 * HTS = 0.5 Tline
- 2x2 binned mode:
Tline time = 1 * HTS / SCLK
Exposure unit : 1 * HTS = 1 Tline
Signed-off-by: Jason Chen <jason.z.chen@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
When the system enters the D0 state and attempt to probe the device,
another component, such as LED, will also be pulled high due to the
hardware design. It's advisable to keep the device being probed in
a different D state.
Signed-off-by: Jason Chen <jason.z.chen@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Use the v4l2_link_freq_to_bitmap() helper to figure out which
driver-supported link freq can be used on a given system.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Use the v4l2_link_freq_to_bitmap() helper to figure out which
driver-supported link freq can be used on a given system.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Use the v4l2_link_freq_to_bitmap() helper to figure out which
driver-supported link frequencies can be used on a given system.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Add a helper for obtaining supported link frequencies in form most drivers
need them. The result is a bitmap of supported controls.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Complete the list from "INCK Setting" section in IMX415-AAQR-C
(Rev. E19504, 2019/05/21). For consistency suffix all lane rate values by
UL, which is needed for 2376000000 anyway.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Use the new common CCI register access helpers to replace the private
register access helpers in the imx415 driver.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
In some error cases leading '0' for register address
were missing.
Fixes: 613cbb91e9 ("media: Add MIPI CCI register access helper functions")
Signed-off-by: Julien Massot <julien.massot@collabora.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Use the new common CCI register access helpers to replace the private
register access helpers in the st-vgxy61 driver. This simplifies the
driver by reducing the amount of code.
st-vgxy61 devices use little endianness arrangement, therefore
the driver uses the CCI_REGx_LE registers definition.
Signed-off-by: Julien Massot <julien.massot@collabora.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Ensure the device has been setup correctly before registering the v4l2
async device, thus allowing userspace to access.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Fixes: 4c5211a100 ("[media] tc358743: register v4l2 asynchronous subdevice")
Cc: stable@vger.kernel.org
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Drop duplicated UAPI specific portions of the CCS (kernel) documentation
and fix a spelling error in UAPI documentation previously fixed in driver
documentation.
Also add references both ways.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Add support for STM32MP25 VENC video hardware encoder.
Support of JPEG encoding.
VENC has its own reset/clock/irq.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hugues Fruchet <hugues.fruchet@foss.st.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Add support for STM32MP25 VDEC video hardware decoder.
Support of H264/VP8 decoding.
No post-processor support.
VDEC has its own reset/clock/irq.
Successfully tested up to full HD.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hugues Fruchet <hugues.fruchet@foss.st.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
In some chips, MDP3 has the ability to utilize two pipelines to
parallelly process a single frame.
To enable this feature, multiple CMDQ clients and packets need to
be configured at the same time.
Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Extend the component settings used in MT8195 MDP3.
Additionally, it is crucial to read all component settings in
a specific manner to ensure that shared memory data structure lengths
are aligned across different platforms.
Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The configuration of the MT8195 components in the shared memory
is defined in the header file "mdp_sm_mt8195.h".
Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Add MT8195 MDP3 basic configuration in file "mdp_cfg_data.c"
and corresponding driver data.
Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Certain chips can combine several components to form complex virtual
units with advanced functions.
These components require simultaneous configuration of their MODs and
clocks.
Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Support for multiple RDMA/WROT waits for GCE events.
Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
