- 17 Feb, 2022 1 commit
-
-
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:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
- 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:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> 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 12 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:
-
Hans de Goede authored
There is no irci_stable_candrpv_0415_20150521_0458 build for the isp2400/byt version of the atomisp2. There is however an irci_stable_candrpv_0415_20150423_1753 version which according to: https://github.com/intel/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/cam-041 Has the exact same fw ABI, so use that on the isp2400. Link: https://lore.kernel.org/linux-media/20220116215204.307649-4-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
IPS2400 is never defined, for ISP2401 builds ISP2401 gets defined and for ISP2400 nothing gets defined, so any #ifdef ISP2400 checks should be #ifndef ISP2401 checks instead. Link: https://lore.kernel.org/linux-media/20220116215204.307649-3-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
IS_ISP2401 is a function like macro which is always defined, so it must not be used together with #ifdef. #ifdef checks should check for "ISP2401", not "IS_ISP2401". Link: https://lore.kernel.org/linux-media/20220116215204.307649-2-hdegoede@redhat.comSigned-off-by:
-
- 28 Jan, 2022 23 commits
-
-
Sean Young authored
If the driver reports that the hardware had an overflow, report this to userspace. It would be nice to know when this happens, and not just get a long space. This change has been tested with lircd, ir-ctl, and ir-keytable. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Sean Young authored
The driver report a reset event when the hardware reports and overflow. There is no reason to have a generic "reset" event. Signed-off-by:
-
Sean Young authored
These features have never been implemented by any lirc driver, including staging or out of tree drivers. The ioctls for these feaures were removed in commit d55f09ab ("[media] lirc.h: remove several unused ioctls"). So, we can safely remove them. Signed-off-by:
-
Jammy Huang authored
Correct timing's fp/sync/bp value based on the information below. It should be noticed that the calculation formula should be changed per sync polarity. The sequence of signal: sync - backporch - video data - frontporch The following registers start counting from sync's rising edge: 1. VR090: frame edge's left and right 2. VR094: frame edge's top and bottom 3. VR09C: counting from sync's rising edge to falling edge [Vertical timing] +--+ +-------------------+ +--+ | | | v i d e o | | | +--+ +-----+ +-----+ +---+ vsync+--+ frame_top+--------+ frame_bottom+----------------------------+ +-------------------+ | v i d e o | +--+ +-----+ +-----+ +---+ | | | | +--+ +--+ vsync+-------------------------------+ frame_top+-----+ frame_bottom+-------------------------+ [Horizontal timing] +--+ +-------------------+ +--+ | | | v i d e o | | | +--+ +-----+ +-----+ +---+ hsync+--+ frame_left+--------+ frame_right+----------------------------+ +-------------------+ | v i d e o | +--+ +-----+ +-----+ +---+ | | | | +--+ +--+ hsync+-------------------------------+ frame_left+-----+ frame_right+-------------------------+ Ex. 1920x1200@60 whose vsync polarity is negative VR098: c4d3efff, VR09C: 04cc001f v-total = 0x4D3 (VR098[27:16]) = 1235 v-sync = 0x4CC (VR09C[27:16]) = 1228 [hverkuil: drop unused variable mds] Signed-off-by:Jammy Huang <jammy_huang@aspeedtech.com> Signed-off-by:
-
Jammy Huang authored
Use the bitfield macro FIELD_GET, and GENMASK to do the shift and mask in one go for reg values. Signed-off-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Jammy Huang authored
Previous reg-field, 0x98[11:0], stands for the period of the detected hsync signal. Use the correct reg, 0xa0, to get h-total in pixels. Fixes: d2b4387f ("media: platform: Add Aspeed Video Engine driver") Signed-off-by:
-
Jammy Huang authored
In ast2500, engine will stop occasionally for 1360x768. This is a bug which has been addressed, but the workaround is specific for 1680 only. Here we make it more complete. Signed-off-by:
-
Jammy Huang authored
The new messages are listed as below: 1. jpeg header and capture buffer information 2. information for each irq 3. current capture mode, sync or direct-fetch 4. time consumed for each frame 5. input timing changed information [hverkuil: use %pad for dma_addr_t to avoid compiler warnings] Signed-off-by:
-
Jammy Huang authored
The debug log level, 0~3, is controlled by module_param, debug. The higher the value, the more the information. 0: off 1: info 2: debug 3: register operations Signed-off-by:
-
Angus Ainslie authored
Allow the dw9714 to control a regulator and adjust suspend() and resume() to support both runtime and system pm. Signed-off-by:
Angus Ainslie <angus@akkea.ca> Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Bingbu Cao authored
The module identifying will try to get the sub device data which will be ready after sub device initialisation, so if try to use the subdev data to deference the client will cause NULL pointer dereference, this patch move the module identification after v4l2_i2c_subdev_init() to fix this issue, it also fixes duplicate module idendification. Fixes: ada2c4f5 ("media: ov2740: support device probe in non-zero ACPI D state") Signed-off-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
-
Philippe Cornu authored
Add Alain as sti maintainer for both drm/sti & cec/sti. Add Raphaël as stm maintainer for drm/stm. Signed-off-by:
Philippe Cornu <philippe.cornu@foss.st.com> Reviewed-by:
Alain Volmat <alain.volmat@foss.st.com> Reviewed-by:
Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by:
-
Benjamin Gaignard authored
Update Benjamin Gaignard address and remove it from no more maintained drivers. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by:
-
Laurent Pinchart authored
The MAX9286 has sink pads, so it should implement .link_validate(). Do so. Signed-off-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
-
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:
-
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:
-
