- 22 Feb, 2022 8 commits
-
-
Jammy Huang authored
Use of_device_get_match_data() to simplify the code. Signed-off-by:
Jammy Huang <jammy_huang@aspeedtech.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl>
-
Jammy Huang authored
Current settings for video capture rgb-2-yuv is BT.601(studio swing), but JFIF uses BT.601(full swing) to deocde. This mismatch will lead to incorrect color. For example, input RGB value, (0, 0, 255), will become (16, 16, 235) after jpg decoded. Add an enum, aspeed_video_capture_format, to define VR008[7:6] capture format and correct default settings for video capture to fix the problem. VR008[7:6] decides the data format for video capture as below: * 00: CCIR601 studio swing compliant YUV format * 01: CCIR601 full swing compliant YUV format * 10: RGB format * 11: Gray color mode Signed-off-by:
Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by:
-
Jammy Huang authored
Using stable-signal in resolution detection, and try detection again if unstable. VE_MODE_DETECT_EXTSRC_ADC: 1 if video source is from ADC output. VE_MODE_DETECT_H_STABLE: 1 if horizontal signal detection is stable. VE_MODE_DETECT_V_STABLE: 1 if vertical signal detection is stable. Signed-off-by:
-
Jammy Huang authored
VE_MODE_DT_HOR_TOLER: the tolerance in detecting for stable horizontal signal. VE_MODE_DT_VER_TOLER: the tolerance in detecting for stable vertical signal. VE_MODE_DT_HOR_STABLE: the minimum required count in detecting stable HSYNC signal to set mode detection horizontal signal stable. VE_MODE_DT_VER_STABLE: the minimum required count in detecting stable VSYNC signal to set mode detection vertical signal stable. Signed-off-by:
-
Jammy Huang authored
Add comments to describe video-stat and 'struct aspeed_video'. Add macro, ASPEED_VIDEO_V4L2_MIN_BUF_REQ, to describe the buffers needed. Signed-off-by:
-
Niklas Söderlund authored
When Gen3 support was first added to this R-Car VIN and CSI-2 driver the routing was centred around the CHSEL register which multiplexes the different parallel buses that sit between the CSI-2 receivers source side and the VIN dma engines. This was a bad design as the multiplexing do allow for only a few combinations and do not play nice with many video streams in the system. For example it's only possible for CSI-2 Virtual Channels 0 and 1 of any given CSI-2 receiver to be used together with the scaler. Later datasheets have expanded the documentation and it is now possible to improve on this design by allowing any Virtual Channel to be routed to any R-Car VIN instance, provided that there exists a parallel bus between them. This increases the flexibility as all Virtual Channels can now be used together with the scaler for example. The redesign is not however perfect. While the new design allows for many more routes, two constrains limit a small portion of routes that was possible in the old design but are no more. - It is no longer possible to route the same CSI-2 and VC to more then one VIN at a time. This was theoretically possible before if the specific SoC allowed for the same CSI-2 and VC to be routed to two different VIN capture groups. - It is no longer possible to simultaneously mix links from two CSI-2 IP blocks to the same VIN capture group. For example if VIN2 is capturing from CSI40 then VIN{0,1,3} must also capture from CSI40. While VIN{4,5,6,7} is still free to capture from any other CSI-2 IP in the system. Once all VIN{0,1,2,3} links to CSI40 are disabled that VIN capture group is free again to capture from any other CSI-2 IP it is connected to. At the core of the redesign is greater cooperator of the R-Car VIN and CSI-2 drivers in configuring the routing. The VIN driver is after this change only responsible to configure the full VIN capture groups parallel buses to be to a particular CSI-2 IP. While the configuration of which CSI-2 Virtual Channel is outputted on which of the R-Car CSI-2 IP output ports is handled by the CSI-2 driver. Before this change the CSI-2 Virtual Channel to output port was static in the CSI-2 driver and the different links only manipulated the VIN capture groups CHSEL register. With this change both the CHSEl register and the CSI-2 routing VCDT registers are modified for greater flexibility. This change touches both the R-Car VIN and R-Car CSI-2 drivers in the same commit as both drivers cooperate closely and one change without the other would more or less break video capture. Signed-off-by:Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Tested-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
-
Niklas Söderlund authored
In preparation of creating more links to allow for full Virtual Channel routing within the CSI-2 block break out the link creation logic to a helper function as the logic will grow in future work. There is no functional change. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Niklas Söderlund authored
The code has grown organically and a lot of checks are performed for the CSI-2 use-case even if the link notify is for a subdevice connected to the parallel interface. Before reworking the CSI-2 routing logic split the CSI-2 and parallel link notify code in two separate blocks to make it clearer. There is no functional change. Signed-off-by:
-
- 17 Feb, 2022 19 commits
-
-
Laurent Pinchart authored
Replace the driver-specific definitions of MIPI CSI-2 data types with macros from mipi-csi2.h. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Laurent Pinchart authored
Replace the hardcoded MIPI CSI-2 data types with macros from mipi-csi2.h. Signed-off-by:
-
Laurent Pinchart authored
Replace the hardcoded MIPI CSI-2 data types with macros from mipi-csi2.h. Signed-off-by:
-
Laurent Pinchart authored
There are many CSI-2-related drivers in the media subsystem that come with their own macros to handle the CSI-2 data types (or just hardcode the numerical values). Provide a shared header with definitions for those data types that driver can use. Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Nikita Yushchenko authored
VSP hardware could be used (e.g. by the bootloader) before driver load, and some interrupts could be left in enabled and pending state. In this case, setting up VSP interrupt handler without masking interrupts before causes interrupt handler to be immediately called (and crash due to null vsp->info dereference). Fix that by explicitly masking all interrupts before setting the interrupt handler. To do so, have to set the interrupt handler later, after hw revision is already detected and number of interrupts to mask gets known. Based on patch by Koji Matsuoka <koji.matsuoka.xm@renesas.com> included in the Renesas BSP kernel. Signed-off-by:
Nikita Yushchenko <nikita.yoush@cogentembedded.com> Reviewed-by:
-
Paul Pawlowski authored
Adds the requisite device id to support detection of the Apple FaceTime HD webcam exposed over the T2 BCE VHCI interface. Tested-by:
Aun-Ali Zaidi <admin@kodeit.net> Signed-off-by:
Paul Pawlowski <paul@mrarm.io> Signed-off-by:
Aditya Garg <gargaditya08@live.com> Reviewed-by:
Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by:
-
Alexander Stein authored
Without this the default (SMPTE 170M) from init_cfg stays unchanged. Even after configuring 'srgb' colorspace (or 'raw') $ media-ctl -V "'csis-32e30000.mipi-csi':0 [colorspace:srgb]" the colorspace does not change at all: $ media-ctl --get-v4l2 "'csis-32e30000.mipi-csi':0" [fmt:SRGGB10_1X10/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
-
Zhou Qingyang authored
In cal_ctx_v4l2_init_formats(), devm_kzalloc() is assigned to ctx->active_fmt and there is a dereference of it after that, which could lead to NULL pointer dereference on failure of devm_kzalloc(). Fix this bug by adding a NULL check of ctx->active_fmt. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code. Fixes: 71681550 ("media: ti-vpe: cal: Move format handling to cal.c and expose helpers") Signed-off-by:
Zhou Qingyang <zhou1615@umn.edu> Reviewed-by:
Pratyush Yadav <p.yadav@ti.com> Signed-off-by:
-
Dan Carpenter authored
This error path needs to drop the mutex to avoid a deadlock. Fixes: 7be91e02 ("media: i2c: Add ov08d10 camera sensor driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Bingbu Cao authored
MWB gain register are used to set gain for each mwb channel mannually. However, it will involve some artifacts at low light environment as gain cannot be applied to each channel synchronously. Update the driver to use group write for digital gain to make the sure RGB digital gain be applied together at frame boundary. Signed-off-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
-
Martin Kepplinger authored
link-frequencies is required but only mentioned in the example. Add it to the description. Fixes: f3ce7200 ("media: dt-bindings: media: document SK Hynix Hi-846 MIPI CSI-2 8M pixel sensor") Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Martin Kepplinger authored
This fixes "make dt_binding_check": Documentation/devicetree/bindings/media/i2c/hynix,hi846.example.dt.yaml: camera@20: port:endpoint: Unevaluated properties are not allowed ('link-frequencies', 'data-lanes' were unexpected) From schema: Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml [Sakari Ailus: Reword commit message] Fixes: f3ce7200 ("media: dt-bindings: media: document SK Hynix Hi-846 MIPI CSI-2 8M pixel sensor") Reported-by:Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Kees Cook authored
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Wrap the target region in struct_group(). This additionally fixes a theoretical misalignment of the copy (since the size of "buf" changes between 64-bit and 32-bit, but this is likely never built for 64-bit). FWIW, I think this code is totally broken on 64-bit (which appears to not be a "real" build configuration): it would either always fail (with an uninitialized data->buf_size) or would cause corruption in userspace due to the copy_to_user() in the call path against an uninitialized data->buf value: omap3isp_stat_request_statistics_time32(...) struct omap3isp_stat_data data64; ... omap3isp_stat_request_statistics(stat, &data64); int omap3isp_stat_request_statistics(struct ispstat *stat, struct omap3isp_stat_data *data) ... buf = isp_stat_buf_get(stat, data); static struct ispstat_buffer *isp_stat_buf_get(struct ispstat *stat, struct omap3isp_stat_data *data) ... if (buf->buf_size > data->buf_size) { ... return ERR_PTR(-EINVAL); } ... rval = copy_to_user(data->buf, buf->virt_addr, buf->buf_size); Regardless, additionally initialize data64 to be zero-filled to avoid undefined behavior. Link: https://lore.kernel.org/lkml/20211215220505.GB21862@embeddedor Cc: Arnd Bergmann <arnd@arndb.de> Fixes: 378e3f81 ("media: omap3isp: support 64-bit version of omap3isp_stat_data") Cc: stable@vger.kernel.org Reviewed-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
-
Laurent Pinchart authored
MIPI CSI-2 continuous and non-continuous clock modes are mutually exclusive. Drop the V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag and use V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK only. Signed-off-by:
-
Laurent Pinchart authored
The V4L2_MBUS_CSI2_CHANNEL_* flags are a legacy API. Only V4L2_MBUS_CSI2_CHANNEL_0 is used, set in a single driver, and never read. Drop those flags. Virtual channel information should be conveyed through frame descriptors instead. Signed-off-by:
-
Laurent Pinchart authored
The V4L2_MBUS_CSI2_*_LANE flags are a legacy API and are unused. Drop them. Signed-off-by:
-
Laurent Pinchart authored
The media bus configuration is specified through a set of flags, some of which being mutually exclusive. This doesn't scale to express more complex configurations. Improve the API by replacing the single flags field in v4l2_mbus_config by a union of v4l2_mbus_config_* structures. The flags themselves are still used in those structures, so they are kept here. Drivers are however updated to use structure fields instead of flags when already possible. Signed-off-by:
-
Sakari Ailus authored
As part of removing mbus config flags, remove VC flag use in the microchip-csi2dc driver. The support can be reintroduced later on as part of the streams patches. [mchehab: patch accepted by Eugen: https://lore.kernel.org/linux-media/c0676a4e-803f-9f1c-542b-4b007705ef3d@microchip.com/, so add an accepted-by tag] Accepted-by:
Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by:
-
Robert Foss authored
QCOM ISPs do not support having a programmable CSI Clock Lane number. In order to accurately reflect this, the different CSIPHY HW versions need to have their own register layer for computing lane masks. Signed-off-by:
Robert Foss <robert.foss@linaro.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
- 16 Feb, 2022 4 commits
-
-
Tom Rix authored
Calling hdmi_infoframe_unpack() with static sizeof(buffer) skips all the size checking done later in hdmi_infoframe_unpack(). A better value is the amount of data read into buffer. Fixes: 480b8b3e ("video/hdmi: Pass buffer size to infoframe unpack functions") Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Laurent Pinchart authored
The vimc driver is used for testing purpose, and some test use cases involve sharing buffers with a consumer device. Consumers often require DMA contiguous memory, which vimc doesn't currently support. This leads in the best case to usage of bounce buffers, which is very slow, and in the worst case in a complete failure. Add support for the dma-contig allocator in vimc to support those use cases properly. The allocator is selected through a new "allocator" module parameter, which defaults to vmalloc. [hverkuil: add missing 'select VIDEOBUF2_DMA_CONFIG' to Kconfig] Signed-off-by:
-
Neil Armstrong authored
The CLIP, SRC & DST registers are coded to take the pixel/line start & end, starting from 0. Thus the end should be the width/height minus 1. It can be an issue with clipping and rotation, where it will add spurious lines from uninitialized or unwanted data with a shift in the result. Fixes: 59a63532 ("media: meson: Add M2M driver for the Amlogic GE2D Accelerator Unit") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Maxime Jourdan authored
Tag all the coded formats where the s5p_mfc decoder supports dynamic resolution switching or has a bytestream parser. Signed-off-by:
Maxime Jourdan <mjourdan@baylibre.com> Reviewed-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
-
- 08 Feb, 2022 9 commits
-
-
Tsuchiya Yuto authored
The dummy_ptr check in hmm_init() [1] results in the following "hmm_init Failed to create sysfs" error exactly once every two times on atomisp reload by rmmod/insmod (although atomisp module loads and works fine regardless of this error): [ 140.230662] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:03.0/active_bo' [ 140.230668] CPU: 1 PID: 2502 Comm: insmod Tainted: G C OE 5.15.0-rc4-1-surface-mainline #1 b8acf6eb64994414b2e20bad312a7a2c45f748f9 [ 140.230675] Hardware name: OEMB OEMB/OEMB, BIOS 1.51116.238 03/09/2015 [ 140.230678] Call Trace: [ 140.230687] dump_stack_lvl+0x46/0x5a [ 140.230702] sysfs_warn_dup.cold+0x17/0x24 [ 140.230710] sysfs_add_file_mode_ns+0x160/0x170 [ 140.230717] internal_create_group+0x126/0x390 [ 140.230723] hmm_init+0x5c/0x70 [atomisp 7a6a680bf400629363d2a6f58fd10e7299678b99] [ 140.230811] atomisp_pci_probe.cold+0x1136/0x148e [atomisp 7a6a680bf400629363d2a6f58fd10e7299678b99] [ 140.230875] local_pci_probe+0x45/0x80 [ 140.230882] ? pci_match_device+0xd7/0x130 [ 140.230887] pci_device_probe+0xfa/0x1b0 [ 140.230892] really_probe+0x1f5/0x3f0 [ 140.230899] __driver_probe_device+0xfe/0x180 [ 140.230903] driver_probe_device+0x1e/0x90 [ 140.230908] __driver_attach+0xc0/0x1c0 [ 140.230912] ? __device_attach_driver+0xe0/0xe0 [ 140.230915] ? __device_attach_driver+0xe0/0xe0 [ 140.230919] bus_for_each_dev+0x89/0xd0 [ 140.230924] bus_add_driver+0x12b/0x1e0 [ 140.230929] driver_register+0x8f/0xe0 [ 140.230933] ? 0xffffffffc153f000 [ 140.230937] do_one_initcall+0x57/0x220 [ 140.230945] do_init_module+0x5c/0x260 [ 140.230952] load_module+0x24bd/0x26a0 [ 140.230962] ? __do_sys_finit_module+0xae/0x110 [ 140.230966] __do_sys_finit_module+0xae/0x110 [ 140.230972] do_syscall_64+0x5c/0x80 [ 140.230979] ? syscall_exit_to_user_mode+0x23/0x40 [ 140.230983] ? do_syscall_64+0x69/0x80 [ 140.230988] ? exc_page_fault+0x72/0x170 [ 140.230991] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 140.230997] RIP: 0033:0x7f7fd5d8718d [ 140.231003] Code: b4 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b3 6c 0c 00 f7 d8 64 89 01 48 [ 140.231006] RSP: 002b:00007ffefc25f0e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 140.231012] RAX: ffffffffffffffda RBX: 000055ac3edcd7f0 RCX: 00007f7fd5d8718d [ 140.231015] RDX: 0000000000000000 RSI: 000055ac3d723270 RDI: 0000000000000003 [ 140.231017] RBP: 0000000000000000 R08: 0000000000000000 R09: 00007f7fd5e52380 [ 140.231019] R10: 0000000000000003 R11: 0000000000000246 R12: 000055ac3d723270 [ 140.231021] R13: 0000000000000000 R14: 000055ac3edd06e0 R15: 0000000000000000 [ 140.231038] atomisp-isp2 0000:00:03.0: hmm_init Failed to create sysfs The problem is that dummy_ptr == 0 is a valid value. So, change the logic which checks if dummy_ptr was allocated. At this point, atomisp now gives WARN_ON() in hmm_free() [2] on atomisp reload by rmmod/insmod. Again, the check is wrong there. So, change both checks for mmgr_EXCEPTION, which is the error value when HMM allocation fails, and initialize dummy_ptr with such value. [1] added on commit d9ab8395 ("media: atomisp: don't cause a warn if probe failed") [2] added on commit b83cc378 ("atomisp: clean up the hmm init/cleanup indirections") Link: https://lore.kernel.org/linux-media/20211017162337.44860-3-kitakar@gmail.comSigned-off-by:Tsuchiya Yuto <kitakar@gmail.com> Co-developed-by:
-
Moses Christopher Bollavarapu authored
There is a BIT(nr) macro available in Linux Kernel, which does the same thing. Example: BIT(7) = (1UL << 7) Link: https://lore.kernel.org/linux-media/20220206185232.21726-1-mosescb.dev@gmail.comSigned-off-by:
Moses Christopher Bollavarapu <mosescb.dev@gmail.com> Signed-off-by:
-
Colin Ian King authored
Don't populate the read-only array idx_map on the stack but instead it static const. Also makes the object code a little smaller. Link: https://lore.kernel.org/linux-media/20220109195129.46118-1-colin.i.king@gmail.comSigned-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Hans de Goede authored
The TrekStor SurfTab duo W1 10.1 has a hw bug where turning eldo2 back on after having turned it off causes the CPLM3218 ambient-light-sensor on the front camera sensor's I2C bus to crash, hanging the bus. Add a DMI quirk table for systems on which to leave eldo2 on. Note an alternative fix is to turn off the CPLM3218 ambient-light-sensor as long as the camera sensor is being used, this is what Windows seems to do as a workaround (based on analyzing the DSDT). But that is not easy to do cleanly under Linux. Link: https://lore.kernel.org/linux-media/20220116215204.307649-10-hdegoede@redhat.comSigned-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
On devices with 2 cameras and no _DSM / EFI-vars providing CsiPort clock info, defaulting to CsiPort 0 obviously is wrong for 1 of the 2 cameras. The Intel Cherry Trail (ISP2401) reference design combines: pmc_plt_clk_2 with CsiPort 0 pmc_plt_clk_4 with CsiPort 1 The Intel Bay Trail (ISP2400) reference design combines: pmc_plt_clk_1 with CsiPort 0 pmc_plt_clk_0 with CsiPort 1 Use this knowledge to set the default CsiPort value based on the detected CLK for the sensor. Link: https://lore.kernel.org/linux-media/20220116215204.307649-9-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Fix axp_v1p8_on() turning ELDO2 off at the end again by removing the bogus code which turns it off again after just having turned it on. Link: https://lore.kernel.org/linux-media/20220116215204.307649-8-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Testing on multiple tablet models has shown that Android always uses 1.6V for ELDO1, adjust our code to match. This also matches with how ELDO1 is used in the DSDTs on these devices, where for Cherry Trail (ISP2401) based devices ELDO1 is used for an ACPI power-resource which is named "P16P". Note on Bay Trail (ISP2400) based devices the power-resource is called "P15P", which suggests that 1.5V might be a better value there. Link: https://lore.kernel.org/linux-media/20220116215204.307649-7-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
On devices with 2 sensors the 2 sensors may get probed simultaneously and the v1p8 and v2p8 regulators are ususally shared between the 2 sensors. This means that the probe() function of sensor 1 may end up calling gmin_v1p8_ctrl(..., false) turning the regulator off while sensor 2's probe() function still needs it to be on, causing the probe() of sensor 2 to sometimes fail. Fix this by adding an enable-count for both regulators and only disabling them again when that goes to 0. Note all this really should be converted to use the standard kernel regulator framework, I have doing this on my long term TODO list, this fix is only meant as a temporary workaround for the issue. Link: https://lore.kernel.org/linux-media/20220116215204.307649-6-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
The second write done in axp_regulator_set() must go to the ctrl_reg which turns the various regulators on/off. This replaces the second write writing the sel_reg, which sets the voltage for the regulator, for a second time with a wrong value. Link: https://lore.kernel.org/linux-media/20220116215204.307649-5-hdegoede@redhat.comSigned-off-by:
-
