- 09 Dec, 2023 7 commits
-
-
Laurent Pinchart authored
Include all the headers that the driver needs explicitly instead of relying on indirect inclusion. While at it, drop a few unneeded headers. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Ricardo Ribalda authored
The device does not implement the power line frequency control correctly. It is a UVC 1.5 device, but implements the control as a UVC 1.1 device. Add the corresponding control mapping override. Bus 003 Device 002: ID 2b7e:b752 SunplusIT Inc HD Camera Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.01 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x2b7e idProduct 0xb752 bcdDevice 0.04 iManufacturer 1 SunplusIT Inc iProduct 2 HD Camera iSerial 3 01.00.00 bNumConfigurations 1 Cc: Yunke Cao <yunkec@chromium.org> Signed-off-by:
Ricardo Ribalda <ribalda@chromium.org> Signed-off-by:
-
Laurent Pinchart authored
When selecting an alternate setting, the driver loops over all available alternate settings to find the one with the lowest bandwidth high enough for the selected format and resolution. While all alternate settings should have different packet sizes, some buggy devices report multiple alternate settings with the same size. The driver happens to pick the last one in this case. In theory this should work fine, but in real life we have device bugs. The Ali Corp. Newmine Camera (0402:8841) exposes four alternate settings with the same packet size. The first three seem to work fine, while selecting the last one results in lots of transmission errors. Switch to using the first best alternate setting when multiple are present. This should be safe (last famous words), as sniffing USB traffic with the faulty device shows that Windows 10 picks the first alternate setting, and devices are typically tested on Windows. Closes: https://lore.kernel.org/linux-media/Nh6D0WI--3-9@tutanota.com/Reported-by:
Karel Janda <karel1@tutanota.com> Suggested-by:
-
Ricardo Ribalda authored
The device does not implement the control properly. Fixes v4l2-compliance error: info: checking control 'Power Line Frequency' (0x00980918) fail: v4l2-test-controls.cpp(552): could not set valid menu item 3 Signed-off-by:
-
Hans Verkuil authored
The vb2 read support requests 1 buffer, leaving it to the driver to increase this number to something that works. Unfortunately, drivers do not deal with this reliably, and in fact this caused problems for the bttv driver and reading from /dev/vbiX, causing every other VBI frame to be all 0. Instead, request as the number of buffers whatever is the maximum of 2 and q->min_buffers_needed+1. In order to start streaming you need at least q->min_buffers_needed queued buffers, so add 1 buffer for processing. And if that field is 0, then choose 2 (again, one buffer is being filled while the other one is being processed). This certainly makes more sense than requesting just 1 buffer, and the VBI bttv support is now working again. It turns out that the old videobuf1 behavior of bttv was to allocate 8 (video) and 4 (vbi) buffers when used with read(). After the vb2 conversion that changed to 2 for both. With this patch it is 3, which is really all you need. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: b7ec3212 ("media: bttv: convert to vb2") Tested-by:
Dr. David Alan Gilbert <dave@treblig.org> Signed-off-by:
-
Hans Verkuil authored
The old (now removed) videobuf framework had an optional vbi hack where the sequence number of the frame counter was copied in the last 4 bytes of the buffer. This hack was active only for the read() interface (so not for streaming I/O), and it was enabled by bttv. This allowed applications that used read() for the VBI data to match it with the corresponding video frame. When bttv was converted to vb2 this hack was forgotten, but some old applications rely on this. So add this back, but this time in the bttv driver rather than in the vb2 framework. Signed-off-by:
-
Hans Verkuil authored
The start_streaming callback returned 0 or 1 instead of a proper error code. Fix that. Signed-off-by:
-
- 08 Dec, 2023 7 commits
-
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
-
Sakari Ailus authored
Select V4L2_CCI_I2C Kconfig option which the CCS driver now depends on. Fixes: 52932211 ("media: ccs: Use V4L2 CCI for accessing sensor registers") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312060941.CYiHppAp-lkp@intel.com/Signed-off-by:
-
- 07 Dec, 2023 26 commits
-
-
Michael Tretter authored
Add support for the multi-planar variants of NV12. The RGA is now able to exchange DMABUFs with other devices that only support multi-planar NV12, for example the Hantro JPEG encoder. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
-
Michael Tretter authored
Multi-planar formats may have multiple planes that must be handled and correctly mapped into a continuous buffer for the RGA by using the DMA descriptors. The plane offsets in the continuous mapping may now start at page boundaries and the previous calculation based on the frame sizes is only valid for planar buffers in a single memory. Therefore, the offsets must be detected and set while creating the mapping. Signed-off-by:
-
Michael Tretter authored
Switch to the multi-planar API, which allows to handle buffers with separate planes. The RGA driver doesn't expose multi-planar formats, yet. The existing contiguous planar formats can be used with the multi-planar API as well, but the multi-planar API is required for multi-planar formats. Signed-off-by:
-
Michael Tretter authored
Use the provided V4L2_TYPE_IS_{OUTPUT,CAPTURE} macros to check if the buffer or queue is OUTPUT or CAPTURE. The macros work also work for the _MPLANE buffer and queue types and make it easier to switch to the multi-planar API. Signed-off-by: -
Michael Tretter authored
The local variable allows to simplify the accessed to the format and makes it easier to change the type of the format. Signed-off-by:
-
Michael Tretter authored
Use the pixelformat instead of the v4l2_format to find the rga_fmt. This avoids knowing the structure and type of v4l2_format in rga_fmt_find and simplifies the function. Also cleanup the users of the function. In try_fmt always return the found pixel format to make sure that the pixel format is always set. Thus, we can be sure that we will find the rga_fmt in s_fmt and can drop the check if a given format has been found. Signed-off-by:
-
Michael Tretter authored
The try_fmt should limit the width and height to the know limits of the RGA. Use the clamp() helper instead of open coding the clamping. Signed-off-by:
-
Michael Tretter authored
The RGA DMA descriptor list contains only 32-bit addresses. Set the dma_mask to only allocate memory that is addressable by the descriptors. This prevents errors when preparing vb2 buffers that were allocated by the RGA. Signed-off-by:
-
Michael Tretter authored
Calculate the plane offsets and store them with the video buffer while creating the buffer mapping. This allows the driver to more freely handle the memory of the DMA mapping as the offsets and the mapping can be kept in sync. The driver still has to update the offsets to respect the configured cropping and rotation, but this calculation is now separated from the calculation of the plane offsets. Signed-off-by:
-
Michael Tretter authored
Split the register setup for the source and destination video buffers into separate functions. This is a cleanup to make the code more readable by separating the offset calculation for the different buffers and prepares the driver for using pre-calculated offsets of planes. Signed-off-by:
-
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 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:
-
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:
-
