- Jan 29, 2022
-
-
Laurent Pinchart authored
The MAX9286 has sink pads, so it should implement .link_validate(). Do so. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
kernel test robot authored
drivers/media/i2c/ov5693.c:953:5-8: Unneeded variable: "ret". Return "0" on line 985 Remove unneeded variable used to store return value. Generated by: scripts/coccinelle/misc/returnvar.cocci [Sakari Ailus: Improved subject] CC: Daniel Scally <djrscally@gmail.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
kernel test robot authored
drivers/media/i2c/ov5693.c:989:46-51: WARNING: conversion to bool not needed here drivers/media/i2c/ov5693.c:991:46-51: WARNING: conversion to bool not needed here Remove unneeded conversion to bool Semantic patch information: Relational and logical operators evaluate to bool, explicit conversion is overly verbose and unneeded. Generated by: scripts/coccinelle/misc/boolconv.cocci [Sakari Ailus: Improved subject] CC: Daniel Scally <djrscally@gmail.com> Reported-by:
-
Jimmy Su authored
Add a v4l2 sub-device driver for the OmniVision ov08d10 image sensor. This camera sensor is using the i2c bus for control and the csi-2 bus for data. The following features are supported: - manual exposure and analog/digital gain control - vblank/hblank control - test pattern - image vertical flip and horizontal mirror control - supported resolution: - 3280x2460 at 30 FPS - 3264x2448 at 30 FPS - 1632x1224 at 30 FPS - supported bayer order output: - SGRBG10 as default - SBGGR10 at flip mode - SRGGB10 at mirror mode - SGBRG10 at flip + mirror mode Signed-off-by:
Jimmy Su <jimmy.su@intel.com> Signed-off-by:
-
Shawn Tu authored
Add a V4L2 sub-device driver for Hynix Hi-847 image sensor. This is a camera sensor using the I2C bus for control and the CSI-2 bus for data. This driver supports following features: - manual exposure and analog/digital gain control support - vblank/hblank control support - test pattern support - media controller support - runtime PM support - vflip/hflip control support - keep SGRBG10 Bayer order output - support following resolutions: + 3264x2448 at 30FPS + 1632x1224 at 60FPS [Sakari Ailus: Wrapped a few long lines.] Signed-off-by:
Shawn Tu <shawnx.tu@intel.com> Signed-off-by:
-
Sakari Ailus authored
Fixed wrong indentation in set_selection callback. Reported-by:
-
Sakari Ailus authored
Don't pack the driver specific struct containing control pointers. This lead to potential alignment issues when working with the pointers. Reported-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
-
Sakari Ailus authored
Pointers V4L2 pixelformat and dataformat fields in a few packed structs are directly passed to printk family of functions. This could result in an unaligned access albeit no such possibility appears to exist at the moment i.e. this clang warning appears to be a false positive. Address the warning by copying the pixelformat or dataformat value to a local variable first. Reported-by:
-
Janusz Krzysztofik authored
According to v4l2-compliance utility, a video device which supports V4L2_CAP_TIMEPERFRAME via .vidioc_s_parm() operation should also support .vidioc_enum_frameintervals(). If the former is implemented via a call to v4l2_s_parm_cap() which in turn calls a subdevice .s_frame_interval() pad operation, the video device may want to implement the latter by passing frame interval enumeration requests to the subdevice .enum_frame_intervals() video operation. If that operation is not supported by the subdevice and failure is returned by the video device, the compliance test issues a warning. Implement the missing pad operation. Enumerate frame intervals possible to be set via pixel clock adjustment, as implemented by .s_frame_interval(), but not exceeding a reasonable maximum of 1 second. [Sakari Ailus: Rebased on mbus config pad op patches] Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by:
-
Janusz Krzysztofik authored
According to subdevice interface specification found in V4L2 API documentation, set format pad operations should not affect image geometry set in preceding image processing steps. Unfortunately, that requirement is not respected by the driver implementation of set format as it was not the case when that code was still implementing a pair of now obsolete .s_mbus_fmt() / .try_mbus_fmt() video operations before they have been merged and reused as an implementation of .set_fmt() pad operation by commit 717fd5b4 ("[media] v4l2: replace try_mbus_fmt by set_fmt"). Exclude non-compliant crop rectangle adjustments from set format try, as well as a call to .set_selection() from set format active processing path, so only frame scaling is applied as needed and crop rectangle is no longer modified. [Sakari Ailus: Rebase on subdev state patches] Fixes: 717fd5b4 ("[media] v4l2: replace try_mbus_fmt by set_fmt") Signed-off-by:
-
Janusz Krzysztofik authored
Try requests are now only supported by format processing pad operations implemented by the driver. The driver selection API operations currently respond to them with -EINVAL. While that is correct, it constraints video device drivers to not use subdevice cropping at all while processing user requested active frame size, otherwise their set try format results might differ from active. As a consequence, we can't fix set format pad operation as not to touch crop rectangle since that would affect users not being able to set arbitrary frame sizes. Moreover, without a working set try selection support we are not able to use pad config crop rectangle as a reference while processing set try format requests. Implement missing try selection support. Moreover, as it will be now possible to maintain the pad config crop rectangle via selection API, start using it instead of the active one as a reference while processing set try format requests. is_unscaled_ok() helper, now also called from set selection operation, has been just moved up in the source file to avoid a prototype, with no functional changes. [Sakari Ailus: Rebase on subdev state patches] Fixes: 717fd5b4 ("[media] v4l2: replace try_mbus_fmt by set_fmt") Signed-off-by:
-
Janusz Krzysztofik authored
According to subdevice interface specification found in V4L2 API documentation, set format pad operations should not affect image geometry set in preceding image processing steps. Unfortunately, that requirement is not respected by the driver implementation of set format as it was not the case when that code was still implementing a pair of now obsolete .s_mbus_fmt() / .try_mbus_fmt() video operations before they have been merged and reused as an implementation of .set_fmt() pad operation by commit 717fd5b4 ("[media] v4l2: replace try_mbus_fmt by set_fmt"). In case of set format active processing path the issue can be fixed easily by excluding a call to set active selection from that path. That will effectively limit frame size processing to optimal frame scaling against active crop rectangle without touching it. Users can just call set active selection themselves to obtain desired frame size. However, set format try processing path needs more work. First of all, the driver should be extended with set try selection support. Lack of it constraints video device drivers to not use subdevice cropping at all while processing user requested active frame size, otherwise their set try format results might differ from active. Next, set format try processing path should use pad config crop rectangle as a reference, not the active one as it does now. That issue can be resolved easily as soon as set try selection support is added to the driver so pad config crop rectangle can be maintained by users via selection API. Last, set format try processing path should give the same results as active in respect to active vs. pad config crop rectangle geometry. Both rectangles should be either not touched by set format (that's what we are going to achieve) or modified the same way, otherwise users won't be able to obtain equal results from both paths while iterating through set format and set selection operations in order to obtain desired frame size. We can't begin with modifying set format pad operation as not to touch crop rectangle since that depends on availability of set try selection for symmetry. Neither can we begin with adding set try selection since that in turn depends on equal handling of active and pad config crop rectangles by set format. We can either implement all required modifications in a single patch, or begin with fixing current set format try processing path to appropriately handle pad config crop rectangle. This patch implements the latter approach as believed to be more readable. Move crop rectangle adjustments code from a helper (the former implementation of .s_fmt(), now called from set format active processing path) to the body of set format pad operation function where it can be also used for processing try requests for symmetry with active ones. As the helper no longer processes frame geometry, only frame format and half scaling, simplify its API accordingly and update its users. Moreover, extract code that applies crop rectangle hardware limits (now a part of .set_selection() operation which is called from set format active processing path) to a new helper and call that helper from set format try processing path as well for symmetry with active. [Sakari Ailus: Rebase on subdev state patches] Fixes: 717fd5b4 ("[media] v4l2: replace try_mbus_fmt by set_fmt") Signed-off-by:
-
- Jan 28, 2022
-
-
Laurent Pinchart authored
To prepare for usage of the v4l2_fwnode_bus_* data structures to describe bus configuration in the subdev .get_mbus_config() operation, rename the structures with a v4l2_mbus_config_ prefix instead of v4l2_fwnode_bus_, and move them to v4l2_mediabus.h. Signed-off-by:
-
Laurent Pinchart authored
The .set_mbus_config() operation is deprecated, and nothing in the kernel uses it. Drop it. Signed-off-by:
-
Laurent Pinchart authored
The subdev .set_mbus_config() operation is deprecated. No code in the kernel calls it, so drop its implementation from the ov6650 driver. Signed-off-by:
-
Laurent Pinchart authored
The subdev .set_mbus_config() operation is deprecated and will be dropped. Drop its usage from the pxa_camera driver, querying the sensor bus configuration instead of setting it. Only the ov6650 driver supports the operation, any platform that experiences issues with this change should update the ov6650 configuration to match what pxa_camera supports. Signed-off-by:
-
Robert Foss authored
The clock-lanes property is not programmable by the hardware, and as such it should not be exposed in the dt-binding. Signed-off-by:
Robert Foss <robert.foss@linaro.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Yong Wu authored
After adding device_link between the iommu consumer and smi-larb, the pm_runtime_get(_sync) of smi-larb and smi-common will be called automatically. we can get rid of mtk_smi_larb_get/put. Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by:
Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Tested-by: Frank Wunderlich <frank-w@public-files.de> # BPI-R2/MT7623 Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Yong Wu authored
MediaTek IOMMU has already added the device_link between the consumer and smi-larb device. If the vcodec devices call the pm_runtime_get_sync, the smi-larb's pm_runtime_get_sync also be called automatically. CC: Irui Wang <irui.wang@mediatek.com> Signed-off-by:
Tiffany Lin <tiffany.lin@mediatek.com> Reviewed-by:
-
Yong Wu authored
MediaTek IOMMU has already added the device_link between the consumer and smi-larb device. If the drm device calls the pm_runtime_get_sync, the smi-larb's pm_runtime_get_sync also be called automatically. CC: CK Hu <ck.hu@mediatek.com> CC: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by:
-
Yongqiang Niu authored
Prepare for smi cleaning up "mediatek,larb". Display use the dispsys device to call pm_rumtime_get_sync before. This patch add pm_runtime_xx with ovl and rdma device whose nodes has "iommus" property, then display could help pm_runtime_get for smi via ovl or rdma device. (Yong: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync) CC: CK Hu <ck.hu@mediatek.com> Signed-off-by:
Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by:
-
Yong Wu authored
MediaTek IOMMU has already added the device_link between the consumer and smi-larb device. If the mdp device calls the pm_runtime_get_sync, the smi-larb's pm_runtime_get_sync also be called automatically. CC: Minghsiu Tsai <minghsiu.tsai@mediatek.com> Signed-off-by:
Houlong Wei <houlong.wei@mediatek.com> Reviewed-by:
-
Yong Wu authored
MediaTek IOMMU has already added device_link between the consumer and smi-larb device. If the jpg device calls the pm_runtime_get_sync, the smi-larb's pm_runtime_get_sync also be called automatically. After removing the larb_get operations, then mtk_jpeg_clk_init is also unnecessary. Remove it too. CC: Xia Jiang <xia.jiang@mediatek.com> Signed-off-by:
Rick Chang <rick.chang@mediatek.com> Reviewed-by:
-
Yong Wu authored
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with smi-larb, then connect with smi-common. M4U | smi-common | ------------- | | ... | | larb1 larb2 | | vdec venc When the consumer works, it should enable the smi-larb's power which also need enable the smi-common's power firstly. Thus, First of all, use the device link connect the consumer and the smi-larbs. then add device link between the smi-larb and smi-common. This patch adds device_link between the consumer and the larbs. When device_link_add, I add the flag DL_FLAG_STATELESS to avoid calling pm_runtime_xx to keep the original status of clocks. It can avoid two issues: 1) Display HW show fastlogo abnormally reported in [1]. At the beggining, all the clocks are enabled before entering kernel, but the clocks for display HW(always in larb0) will be gated after clk_enable and clk_disable called from device_link_add(->pm_runtime_resume) and rpm_idle. The clock operation happened before display driver probe. At that time, the display HW will be abnormal. 2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to skip pm_runtime_xx to avoid the deadlock. Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then device_link_removed should be added explicitly. Meanwhile, Currently we don't have a device connect with 2 larbs at the same time. Disallow this case, print the error log. [1] https://lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/ [2] https://lore.kernel.org/patchwork/patch/1086569/ Suggested-by:Tomasz Figa <tfiga@chromium.org> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Reviewed-by:
-
Yong Wu authored
Prepare for adding device_link. The iommu consumer should use device_link to connect with the smi-larb(supplier). then the smi-larb should run before the iommu consumer. Here we delay the iommu driver until the smi driver is ready, then all the iommu consumers always are after the smi driver. When there is no this patch, if some consumer drivers run before smi-larb, the supplier link_status is DL_DEV_NO_DRIVER(0) in the device_link_add, then device_links_driver_bound will use WARN_ON to complain that the link_status of supplier is not right. device_is_bound may be more elegant here. but it is not allowed to EXPORT from https://lore.kernel.org/patchwork/patch/1334670/ . Signed-off-by:
-
Yong Wu authored
The platform device is created at: of_platform_default_populate_init: arch_initcall_sync ->of_platform_populate ->of_platform_device_create_pdata When entering our probe, all the devices should be already created. if it is null, means NODEV. Currently we don't get the fail case. It's a minor fix, no need add fixes tags. Signed-off-by: -
Yong Wu authored
When the iommu master device enters of_iommu_xlate, the ops may be NULL(iommu dev is defered), then it will initialize the fwspec here: [<c0c9c5bc>] (dev_iommu_fwspec_set) from [<c06bda80>] (iommu_fwspec_init+0xbc/0xd4) [<c06bd9c4>] (iommu_fwspec_init) from [<c06c0db4>] (of_iommu_xlate+0x7c/0x12c) [<c06c0d38>] (of_iommu_xlate) from [<c06c10e8>] (of_iommu_configure+0x144/0x1e8) BUT the mtk_iommu_v1.c only supports arm32, the probing flow still is a bit weird. We always expect create the fwspec internally. otherwise it will enter here and return fail. static int mtk_iommu_create_mapping(struct device *dev, struct of_phandle_args *args) { ... if (!fwspec) { .... } else if (dev_iommu_fwspec_get(dev)->ops != &mtk_iommu_ops) { >>>>>>>>>>Enter here. return fail.<<<<<<<<<<<< return -EINVAL; } ... } Thus, Free the existed fwspec if the master device already has fwspec. This issue is reported at: https://lore.kernel.org/linux-mediatek/trinity-7d9ebdc9-4849-4d93-bfb5-429dcb4ee449-1626253158870@3c-app-gmx-bs01/ Reported-by:Frank Wunderlich <frank-w@public-files.de> Tested-by: Frank Wunderlich <frank-w@public-files.de> # BPI-R2/MT7623 Signed-off-by:
-
Yong Wu authored
After adding device_link between the consumer with the smi-larbs, if the consumer call its owner pm_runtime_get(_sync), the pm_runtime_get(_sync) of smi-larb and smi-common will be called automatically. Thus, the consumer don't need this property. And IOMMU also know which larb this consumer connects with from iommu id in the "iommus=" property. Signed-off-by:
-
Hsin-Yi Wang authored
Add mediatek,mt8183-jpgenc compatible to binding document. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
-
Hsin-Yi Wang authored
Convert mediatek jpeg decoder and encoder bindings to yaml. Signed-off-by:
-
Chen-Yu Tsai authored
The quantization tables used in the Hantro JPEG encoder driver are implicitly sized by the data they contain, but the loop that scales the tables based on the compression quality hard codes the size to 64. No code exists to check whether the two actually match. Commit 85bdcb7e ("media: hantro: Write the quantization tables in proper order") introduced two new tables, with sizes hardcoded to 64, but still no checking if all the sizes are the same. Commit 41479adb ("media: hantro: Avoid global variable for jpeg quantization tables") added the macro JPEG_QUANT_SIZE, but only the newly added fields used this. This has resulted in code scattered with magic numbers and array sizes that happen to match up, without any sort of sanity checking to enforce it. Drop the hard-coded array sizes, replace the magic loop count with a proper JPEG_QUANT_SIZE macro, and add BUILD_BUG_ON()s to check that all the table sizes match up. Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Chen-Yu Tsai authored
Now that the JPEG header length is aligned with bus access boundaries, the JPEG encoder can output to the capture buffers directly without going through a bounce buffer. Do just that, and get rid of all the bounce buffer related code. Signed-off-by:
-
Chen-Yu Tsai authored
The Hantro JPEG encoder driver adds various segments to the JPEG header. While it would be quite complicated to make these segments selectable to userspace, given that the driver has to fill in various fields in these segments, and also take care of alignment, it would be nice if the driver could signal to userspace what segments are included. Implement the V4L2_CID_JPEG_ACTIVE_MARKER control, and make it read only so that it always returns the set of segments that the driver adds. Signed-off-by:
-
Chen-Yu Tsai authored
The JPEG header size is not 64-bit aligned. This makes the driver require a bounce buffer for the encoded JPEG image scan output. Add a COM (comment) segment to the JPEG header so that the header size is a multiple of 64 bits. This will then allow dropping the use of the bounce buffer, and instead have the hardware write out to the capture buffer directly. Signed-off-by:
-
Chen-Yu Tsai authored
While the V4L2_PIX_FMT_JPEG format doesn't specify any requirements for the APP0 or APP1 segments, it would be nice if the output is JFIF compliant. While some programs can read JPEG streams that aren't, some guess work is involved. Add the standard JFIF APP0 segment to the JPEG header, so that the JPEG encoder output is JFIF compliant. Signed-off-by:
-
Chen-Yu Tsai authored
Encoders typically operate on macroblocks. Thus their output or coded resolution is constrained to multiples of macroblocks. For frame sizes not aligned to macroblocks, cropping is needed to limit the visible area of the frame. Add support for cropping on the output (source) side for encoders, using the selection API. Signed-off-by:
-
Chen-Yu Tsai authored
The Hantro H1 hardware can crop off pixels from the right and bottom of the source frame. These are controlled with the H1_REG_IN_IMG_CTRL_OVRFLB and H1_REG_IN_IMG_CTRL_OVRFLR in the H1_REG_IN_IMG_CTRL register. The ChromeOS kernel driver that this was based on incorrectly added the _D4 suffix H1_REG_IN_IMG_CTRL_OVRFLB. This field crops the bottom of the input frame, and the number is _not_ divided by 4. [1] Correct the name to avoid confusion when crop support with the selection API is added. [1] https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/ \ heads/chromeos-4.19/drivers/staging/media/hantro/hantro_h1_vp8_enc.c#377 Fixes: 775fec69 ("media: add Rockchip VPU JPEG encoder driver") Fixes: a29add8c ("media: rockchip/vpu: rename from rockchip to hantro") Signed-off-by:
-
Benjamin Mugnier authored
Mickael left the company and is not willing to keep maintainership. Add Sylvain and myself as maintainers of mipid02 driver. Signed-off-by:
Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by:
-
Christophe JAILLET authored
No concurrent access is possible when a bitmap is local to a function. So prefer the non-atomic '__[set|clear]_bit()' functions to save a few cycles. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Martin Kepplinger authored
Add the fsl,imx8mq-csi compatible string to the bindings for nxp,imx7-csi. The i.MX8MQ SoC contains the same CSI bridge controller as the i.MX7. Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
-
