Mainline imx355 test PR - #7
Closed
6by9 wants to merge 38 commits into
Closed
Conversation
The field has been removed, but the kerneldoc not. Let's take care of this. This patch fixes the following warning: Warning: drivers/media/i2c/ov9282.c:223 Excess struct member 'mutex' description in 'ov9282' Fixes: 0c69a96 ("media: i2c: ov9282: Switch to using the sub-device state lock") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The variable has been previously removed but not its kerneldoc. Also remove the leftover reference to state in the description of qlock. This patch fixes the following warning: Warning: drivers/media/platform/renesas/rzg2l-cru/rzg2l-cru.h:164 Excess struct member 'state' description in 'rzg2l_cru_dev' Fixes: 85d8820 ("media: rzg2l-cru: Remove the 'state' variable") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The argument args is not documented, and the latest kernel version complains about that. This fixes the following warning: Warning: include/media/media-entity.h:1394 function parameter 'args' not described in 'media_entity_call' Fixes: 48a7c4b ("[media] docs-rst: improve the kAPI documentation for the mediactl") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds. Fixes: b4e3e59 ("[media] rc: add sunxi-ir driver") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Signed-off-by: Sean Young <sean@mess.org>
Explicitly assigning .driver_data in drivers that don't use this member is silly and a bit irritating. Drop it. Also simplify the list terminator entry to be just empty to match what most other device_id tables do. While touching these arrays convert them to use named initializers, empty list terminators and no comma after the terminator. There is no changed semantic, not even a change in the compiled result. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Signed-off-by: Sean Young <sean@mess.org>
Instead of using magic constants define an enum that that makes it easier to keep .driver_data and the array of different types in sync. While touching the pnp_device_id array simplify the list terminator and use named initializers which better show which struct members are actually assigned to. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Signed-off-by: Sean Young <sean@mess.org>
…ugfs clash The driver registers two regmaps on the same platform device: an MMIO regmap for the AO CEC registers, and an indirect regmap (using reg_read()/reg_write() callbacks) for the CEC controller core registers. Neither regmap_config sets a .name, so both default their debugfs directory to the device name and collide: debugfs: 'ff800280.cec' already exists in 'regmap' Because of the clash the second regmap's debugfs directory fails to register, so its registers can no longer be inspected via debugfs. Give the indirect CEC core regmap a distinct name. The two debugfs directories then become "<dev>.cec" and "<dev>.cec-core". This only affects debugfs naming; register access is unchanged. Tested on an ODROID-N2 (Amlogic S922X): the warning is gone and both /sys/kernel/debug/regmap/ff800280.cec and ff800280.cec-core are present. Fixes: b7778c4 ("media: platform: meson: Add Amlogic Meson G12A AO CEC Controller driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yi Ding <yi.s.ding@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The commit dccc0c3 ("media: rc: fix race between unregister and urb/irq callbacks") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device. kmemleak reports following after e.g. dw-hdmi unbind: unreferenced object 0xffff00010ac10000 (size 4096): comm "kworker/u16:1", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598 Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak. Fixes: dccc0c3 ("media: rc: fix race between unregister and urb/irq callbacks") Cc: stable@vger.kernel.org Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: cec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL. Fixes: d69ae57 ("[media] cec: add STM32 cec driver") Cc: stable@vger.kernel.org Signed-off-by: Weigang He <geoffreyhe2@gmail.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Add check to prevent overflowing msg.msg[] in case the incoming data is malformed. Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Reviewed-by: Sean Young <sean@mess.org> Fixes: 056f282 ("media: cec: extron-da-hd-4k-plus: add the Extron DA HD 4K Plus CEC driver") Cc: stable@vger.kernel.org
cec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in wait_for_completion_killable(). If that wait is interrupted by a signal, cancel_delayed_work_sync() can run before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts(). The work is then armed after the cancel, and the data is freed with its delayed_work still pending: ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout Use disable_delayed_work_sync(): it cancels the work and disables it, so the later schedule_delayed_work() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled. Fixes: 490d84f ("media: cec: forgot to cancel delayed work") Reported-by: syzbot+051024d603432b4ab395@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=051024d603432b4ab395 Suggested-by: Hillf Danton <hdanton@sina.com> Cc: stable@vger.kernel.org Signed-off-by: Biren Pandya <birenpandya@gmail.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
stm32_cec_adap_log_addr() waits for TXSOM to clear before disabling CEC and updating the logical address registers. The wait result is ignored, so a timeout can still be reported as a successful logical address update. Return the polling error before touching the address registers. Compute the address mask only for valid logical addresses so the invalid-address path does not evaluate a shift based on CEC_LOG_ADDR_INVALID. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
cec_pin_update() fills work_pin_events[] and work_pin_ts[], then increments work_pin_num_events. cec_pin_thread_func() uses that counter to decide when to read the FIFO entries. Do not let the counter update be observed without the event update. Also do not let a freed slot be reused before the thread has finished reading it. Use release operations when publishing an entry and releasing a slot, and acquire operations when consuming those counter updates. Leave the other work_pin_num_events users as they do not participate in this FIFO publication path. Fixes: ea5c8ef ("media: cec-pin: add low-level pin hardware support") Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Since commit 2062410 ("[media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap"), the rc-rc5-tv keymap is no longer in the tree. Fixes: 2062410 ("[media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap") Signed-off-by: Sean Young <sean@mess.org> Acked-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When loading a rc keymap, rc_map_get() attempts to load the kernel module using the keymap name. The rc_map RC_MAP_VIDEOMATE_K100 is defined to "rc-videomate-k100" but the module is called rc-videomate-m1f.ko, so therefore automagic loading of the keymap will fail. Rename the module to match. Signed-off-by: Sean Young <sean@mess.org> Acked-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The list is out of sync, so add missing entries, remove obsolete entries and sort. Signed-off-by: Sean Young <sean@mess.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
…eration This series came about as we had a customer ask about using imx355, so I had a look at what was going on. There was significant duplication between the various mode register lists, unused parameters around, and no support for advertising the crop rectangles through get_selection. It also wasn't using V4L2_CCI so had all the boilerplate for writing registers. The customer also wanted to run the sensor over only 2 CSI2 data lanes which required some rework of the clock setup so that the MIPI link frequency could be run at 445MHz instead of the 360MHz used for 4 lane mode. V2 has some fairly substantial differences to V1 as I obtained a datasheet. Whilst some things worked perfectly, the datasheet declared them as prohibited. This was largely using dual PLL mode in 2 lane mode, and LLP is restricted to specific values. Link frequencies are therefore now derived from the PLL configuration, and pixel rate is computed from that. Being able to refer against the datasheet, I've pulled an updated version of David Heidelberg's patch for 24MHz clock support into this series. I've tried to keep it that the earlier patches are largely cleanups or minor improvements, and then we get adding 2 lane support, and converting to using subdev state as they are larger patches. To: Sakari Ailus <sakari.ailus@linux.intel.com> To: Mauro Carvalho Chehab <mchehab@kernel.org> To: Rob Herring <robh@kernel.org> To: Krzysztof Kozlowski <krzk+dt@kernel.org> To: Conor Dooley <conor+dt@kernel.org> To: Richard Acayan <mailingradian@gmail.com> Cc: linux-media@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: David Heidelberg <david@ixit.cz> Cc: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Cc: devicetree@vger.kernel.org --- Changes in v4: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v3: https://lore.kernel.org/r/20260708-media-imx355-v3-0-9df386a623d7@raspberrypi.com Changes in v3: - Fixed a number of issues picked up by sashiko-bot - Unintentionally dropped writing reg 0x030b, which is at the default value anyway. - Swapped len and val in intermediate patches adding imx355_write_reg before converting to cci_write - Initialise colorspace in _open for try_fmt. - IMX355_REG_TEST_PATTERN is a 16 bit register, but was defined as 8 bit. - Call pm_runtime_dont_use_autosuspend on remove / probe error - Missed subdev_lock in set_stream. - Not addressed the pre-existing issues of double power_off in _probe error path, nor potential for VBLANK update on mode change not calling s_ctrl if the new value happens to be the same and therefore exposure range being incorrect. I'll look at them as separate fixes. - Variable definition for format and state in imx355_set_ctrl got pushed into the wrong patch - Collected Krzysztof's R-b tag for the binding patch. - Link to v2: https://lore.kernel.org/r/20260707-media-imx355-v2-0-1683ec07b897@raspberrypi.com Changes in v2: - Collected Jacopo's R-b tags and implement his review comments. - Add patches to switch to using the subdev state, clean up colorspace (sets RAW), use a define for the exposure offset. - Added DT binding update to permit 2 CSI2 data lanes. - Link to v1: https://lore.kernel.org/r/20260506-media-imx355-v1-0-660685030455@raspberrypi.com --- b4-submit-tracking --- # This section is used internally by b4 prep for tracking purposes. { "series": { "revision": 4, "change-id": "20260506-media-imx355-a30f5be3deda", "prefixes": [], "prerequisites": [ "base-commit: 254f496" ], "history": { "v1": [ "20260506-media-imx355-v1-0-660685030455@raspberrypi.com" ], "v2": [ "20260707-media-imx355-v2-0-1683ec07b897@raspberrypi.com" ], "v3": [ "20260708-media-imx355-v3-0-9df386a623d7@raspberrypi.com" ] } } }
The IMX355 sensor supports multiple external clock frequencies, including 19.2 MHz and 24 MHz. The driver currently supports only fixed 19.2 MHz input clock. Refactor the clock handling to make the PLL configuration dependent on the external clock frequency and add support for 24 MHz. Introduce a table of clock parameter sets and program the corresponding EXTCLK frequency and PLL multipliers to maintain consistent internal VCO frequencies across supported inputs. The PLL settings are adjusted so that OP VCO remains at 720 MHz This preserves existing timing characteristics while allowing systems using a 24 MHz clock to operate correctly. No functional change for existing 19.2 MHz users. Assisted-by: Claude:claude-opus-4-6 Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The sensor supports output over either 2 or 4 CSI2 data lanes. The binding only permitted the 4 lane configuration. Add the 2 lane configuration as an option. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
A large number of registers are identical within all the modes. Move those to imx355_global_regs. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Registers 0x0340 and 0x0341 (FRM_LENGTH_LINES) are already written from the set_ctrl(V4L2_CID_VBLANK) handler, so don't write them from the mode register list. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Currently the cropping is set via register entries in the per mode register lists. Add the crop information to the mode structure as a v4l2_rect, and set the registers programmatically. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The driver already has the LLP value stored in the mode structure, but also had the same value set via register writes in the mode's register list. Remove this duplication. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Compute the binning registers based on the difference between the mode width/height vs the crop width/height. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The link_freq_index value in imx355_mode is unused, so remove it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
The pixel rate is always the same, so there is no need to try and recompute it in imx355_set_pad_format, and then no need to have the pointer to it stored. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
fll_min (Frame Length Lines) is set to the same value as fll_def for all modes, which makes it redundant. The actual value is also erroneous as the sensor works in all the defined modes with FLL set at the mode height + 20 lines, so set the vblank control minimum to 20 rather than varying it. This also improves the maximum frame rate achievable. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Provide all the cropping information via get_selection. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Avoid powering the sensor up and down unnecessarily by using pm_runtime's autosuspend_delay feature. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Use the new comon CCI register access helpers to replace the private register access helpers in the imx355 driver. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The colorspace fields were left set to 0 when they should be set appropriately for a raw image sensor. Add those values. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The difference between frame length and max exposure time in lines is 10. That had been used as a bare value in calculations. Move it to a define, and use that define. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
This avoids the set_ctrl handler being called under any circumstances, as it will return an error for the unhandled ctrl. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
In preparation for additional options in the PLL setup, compute the link frequency rather than using a hardcoded value. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The sensor supports 2 or 4 lane readout, but the driver only allowed for 4 lanes. Add 2 lane support. The clock tree only supports single PLL mode to feed both IOP (MIPI) and IVT (Pixel array). 2 lane mode supports a MIPI link frequency of up to 445MHz (890Mbit/s) cf 360MHz (720Mbit/s) for 4lane. Update clock setup and pixel rates to match. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The subdev state is now preferred rather than handling crop and format within the driver state, so switch the driver to using it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
All the information for the mode is now stored within the subdev state, so configure the sensor based on that. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.