kernel.git/drivers/media/i2c, branch linux-6.15.y

media: tc358743: Increase FIFO trigger level to 374

2025-08-20T16:36:21Z

[ Upstream commit 86addd25314a1e77dbdcfddfeed0bab2f27da0e2 ] The existing fixed value of 16 worked for UYVY 720P60 over 2 lanes at 594MHz, or UYVY 1080P60 over 4 lanes. (RGB888 1080P60 needs 6 lanes at 594MHz). It doesn't allow for lower resolutions to work as the FIFO underflows. 374 is required for 1080P24 or 1080P30 UYVY over 2 lanes @ 972Mbit/s, but >374 means that the FIFO underflows on 1080P50 UYVY over 2 lanes @ 972Mbit/s. Whilst it would be nice to compute it, the required information isn't published by Toshiba. Signed-off-by: Dave Stevenson Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: tc358743: Return an appropriate colorspace from tc358743_set_fmt

2025-08-20T16:36:21Z

[ Upstream commit 377cc006a364dfdab2f3f221cfad63a9265200b8 ] When calling tc358743_set_fmt, the code was calling tc358743_get_fmt to choose a valid format. However that sets the colorspace based on information read back from the chip, not the colour format requested. The result was that if you called try or set format for UYVY when the current format was RGB3 then you would get told SRGB, and try RGB3 when current was UYVY and you would get told SMPTE170M. The value programmed in the VI_REP register for the colorspace is always set by this driver, therefore there is no need to read back the value, and never set to REC709. Return the colorspace based on the format set/tried instead. Signed-off-by: Dave Stevenson Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: tc358743: Check I2C succeeded during probe

2025-08-20T16:36:20Z

[ Upstream commit 303d81635e1d9c949b370215cc94526ed81f2e3d ] The probe for the TC358743 reads the CHIPID register from the device and compares it to the expected value of 0. If the I2C request fails then that also returns 0, so the driver loads thinking that the device is there. Generally I2C communications are reliable so there is limited need to check the return value on every transfer, therefore only amend the one read during probe to check for I2C errors. Signed-off-by: Dave Stevenson Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: hi556: Fix reset GPIO timings

2025-08-20T16:36:18Z

[ Upstream commit 99f2211a9d89fe34b3fa847fd7a4475171406cd0 ] probe() requests the reset GPIO to be set to high when getting it. Immeditately after this hi556_resume() is called and sets the GPIO low. If the GPIO was low before requesting it this will result in the GPIO only very briefly spiking high and the sensor not being properly reset. The same problem also happens on back to back runtime suspend + resume. Fix this by adding a sleep of 2 ms in hi556_resume() before setting the GPIO low (if there is a reset GPIO). The final sleep is kept unconditional, because if there is e.g. no reset GPIO but a controllable clock then the sensor also needs some time after enabling the clock. Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: i2c: set lt6911uxe's reset_gpio to GPIOD_OUT_LOW

2025-08-20T16:35:42Z

commit 3c607baf68639d6bfe1a336523c4c9597f4b512a upstream. reset_gpio needs to be an output and set to GPIOD_OUT_LOW, to ensure lt6911uxe is in reset state during probe. This issue was found on the onboard lt6911uxe, where the reset_pin was not reset, causing the lt6911uxe to fail to probe. Fixes: e49563c3be09d4 ("media: i2c: add lt6911uxe hdmi bridge driver") Cc: stable@vger.kernel.org Signed-off-by: Dongcheng Yan Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: i2c: imx334: update mode_3840x2160_regs array

2025-06-27T10:13:19Z

[ Upstream commit 35132d039c566b0e9d8e53f76f512b22607c2405 ] The 3840x2160 mode operates with the imx334 reset values. If we switch to other modes and then return to the 3840x2160 mode, it should function correctly. so updated the mode_3840x2160_regs array with the imx334 reset values. Signed-off-by: Shravan Chippa Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: tc358743: ignore video while HPD is low

2025-06-27T10:13:19Z

[ Upstream commit 6829c5b5d26b1be31880d74ec24cb32d2d75f1ae ] If the HPD is low (happens if there is no EDID or the EDID is being updated), then return -ENOLINK in tc358743_get_detected_timings() instead of detecting video. This avoids userspace thinking that it can start streaming when the HPD is low. Signed-off-by: Hans Verkuil Tested-by: Maxime Ripard Link: https://lore.kernel.org/linux-media/20240628-stoic-bettong-of-fortitude-e25611@houat/ Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: ccs-pll: Better validate VT PLL branch

2025-06-27T10:13:16Z

[ Upstream commit cd9cb0313a42ae029cd5af9293b0add984ed252e ] Check that the VT PLL dividers are actually found, don't trust they always are even though they should be. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: i2c: imx334: Fix runtime PM handling in remove function

2025-06-27T10:13:16Z

[ Upstream commit b493cd3c03641f9bbaa9787e43ca92163cb50051 ] pm_runtime_suspended() only checks the current runtime PM status and does not modify it, making it ineffective in this context. This could result in improper power management if the device remains active when removed. This patch fixes the issue by introducing a check with pm_runtime_status_suspended() to determine if the device is already suspended. If it is not, it calls imx334_power_off() to power down the device and then uses pm_runtime_set_suspended() to correctly update the runtime PM status to suspended. Signed-off-by: Tarang Raval Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: i2c: imx334: Enable runtime PM before sub-device registration

2025-06-27T10:13:15Z

[ Upstream commit 01dfdf6a80c57151af0589af0db7adbbdd1361c7 ] Runtime PM is fully initialized before calling v4l2_async_register_subdev_sensor(). Moving the runtime PM initialization earlier prevents potential access to an uninitialized or powered-down device. Signed-off-by: Tarang Raval Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin