In commit 7d3c7d2a29 ("media: i2c: Add a camera sensor top level menu")
a top level menu was added for sensor drivers so that all sensor drivers
would depend on I2C and so that MEDIA_CONTROLLER, V4L2_FWNODE and
VIDEO_V4L2_SUBDEV_API would be automatically selected for all sensor
drivers.
All lens drivers must depend on I2C and VIDEO_DEV and must select
MEDIA_CONTROLLER, V4L2_FWNODE and VIDEO_V4L2_SUBDEV_API and most already
do, but e.g. VIDEO_V4L2_SUBDEV_API is not consistenly selected.
Change the "Lens drivers" menu into a menuconfig option with
the necessary depends and selects. This ensures that these options are
depended on / selected consistently and simplifies the Kconfig snippets
for the various lens voice coil drivers.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202411061152.VKd9JYpa-lkp@intel.com/
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Use regulator_bulk_* to get the array of potential power rails for
the hi556.
Previously the driver only supported avdd as only avdd is used on IPU6
designs. But other designs may also need the driver to control the other
power rails and the new INT3472 handshake support also makes use of
dvdd on IPU6 designs.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2368506
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
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 <hdegoede@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Enable the csi2rx_err_irq interrupt to record any errors during streaming
and also add support for VIDIOC_LOG_STATUS ioctl. This allows users to
retrieve detailed error information during streaming, including FIFO
overflow, packet errors, and ECC errors.
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Reviewed-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Tested-by: Jai Luthra <jai.luthra@linux.dev>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Print streams found by v4l2_subdev_collect_streams() at debug level. This
could be useful in debugging drivers, userspace programs or the framework
itself.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Print debug messages early in v4l2_subdev_enable_streams() and
v4l2_subdev_disable_streams(), before sanity checks take place. This can
help figuring out why something goes wrong, in driver development or
otherwise.
Also print the name of the sub-device where streaming is to be enabled or
disabled.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
For image data generally 2 seems like a minimum height that surely won't
cause any issues, but some sensors have metadata the height of which is
just one line. Set the minimum height to 1.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The pad argument to v4l2_subdev_state_xlate_streams() is incorrect, static
pad number is used for the source pad even though the pad number is
dependent on the stream. Fix it.
Fixes: 3a5c59ad92 ("media: ipu6: Rework CSI-2 sub-device streaming control")
Cc: stable@vger.kernel.org
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The pixel_array control size was calculated incorrectly:
the dimensions were swapped (dims[0] should be the height), and the
values should be the width or height divided by PIXEL_ARRAY_DIV
and rounded up. So don't use roundup, but use DIV_ROUND_UP instead.
This bug is harmless in the sense that nothing will break, except that
it consumes way too much memory for this control.
Fixes: 6bc7643d1b ("media: vivid: add pixel_array test control")
Cc: <stable@vger.kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Continue the cleanup of the AtomISP driver, as discussed with Hans and Andy
in [1].
Tackle TODO item: "Remove custom sysfs files created by atomisp_drvfs.c":
- Remove the sysfs attributes `dbglvl`, `dbgfun`, and `dbgopt`.
- Delete their associated show/store handler functions.
- Remove the corresponding attribute group definitions.
Link: https://lore.kernel.org/all/836dc6b6-2821-47fc-8f24-0838f979af76@kernel.org/ [1]
Suggested-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Abdelrahman Fekry <abdelrahmanfekry375@gmail.com>
Link: https://lore.kernel.org/r/20250704161051.16733-1-abdelrahmanfekry375@gmail.com
[hansg@kernel.org: Completely remove the now empty atomisp_drvfs files]
Reviewed-by: Hans de Goede <hansg@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The HMM_BO_DEVICE_INITED flag was being set in hmm_bo_device_init()
before key initialization steps like kmem_cache_create(),
kmem_cache_alloc(), and __bo_init().
This means that if any of these steps fail, the flag remains set,
misleading other parts of the driver (e.g. hmm_bo_alloc())
into thinking the device is initialized. This could lead
to undefined behavior or invalid memory use.
Additionally, since __bo_init() is called from inside
hmm_bo_device_init() after the flag was already set, its internal
check for HMM_BO_DEVICE_INITED is redundant.
- Move the flag assignment to the end after all allocations succeed.
- Remove redundant check of the flag inside __bo_init()
See the link [1] below for a backtrace which happens when deliberately
triggering the problem of the flag getting set too early.
Link: https://lore.kernel.org/linux-media/CAGn2d8ONZpOHXex8kjeUDgRPiMqKp8vZ=xhGbEDGphV1t7ZEFw@mail.gmail.com/ [1]
Signed-off-by: Abdelrahman Fekry <abdelrahmanfekry375@gmail.com>
Link: https://lore.kernel.org/r/20250628052536.43737-1-abdelrahmanfekry375@gmail.com
Reviewed-by: Hans de Goede <hansg@kernel.org>
Signed-off-by: Hans de Goede <hansg@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The i2c-client's power-domain has already been powered up when probe()
gets called. So e.g. ACPI resources for regulators and clks have
already been enabled and only the GPIOs need to be set to the on state.
Instead of calling pm_runtime_set_suspended() while the domain is
already powered up and then have detect() do a pm_runtime_get()
to set the GPIOs do the following:
1. Call gc0310_power_on() to only set the GPIOs
2. Set the device's runtime-PM state to active instead of suspended
3. Avoid the device getting suspended as soon as pm_runtime_enable()
gets called by calling pm_runtime_get() before _enable(), this means
moving the pm_runtime_get() / _put() from detect() to probe ()
This fixes power_on() not getting called when runtime-PM is not
enabled in the Kconfig and this keeps the sensor powered-up while
registering it avoiding unnecessary power cycles.
Also modify gc0310_remove() to power-off the device if it is in
active state when gc0310_remove() runs.
Signed-off-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250517114106.43494-21-hansg@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Stop having a v4l2_mbus_framefmt mode.fmt driver-data member to store
the fmt for the active-state, instead use sd.active_state fmt.
This also removes the need for gc0310_get_pad_format() since
v4l2_subdev_state_get_format() now will return the correct
v4l2_mbus_framefmt for all whence values.
Instead of switching gc0310_set_fmt() from gc0310_get_pad_format() to
v4l2_subdev_state_get_format() just drop it entirely since there is only
1 fixed mode. Otherwise the new gc0310_set_fmt() would be 100% the same
as v4l2_subdev_get_fmt() after this.
Signed-off-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250517114106.43494-19-hansg@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reduce the unnecessary long msleep(100) done on stream start to 10 ms and
move this to gc0310_resume() so that it is also done on the initial
power-up done by gc0310_detect(), which should fix gc0310_detect()
sometimes failing.
While at it switch the sleeps from msleep() / usleep_range() to fsleep().
Signed-off-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250517114106.43494-13-hansg@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Replace the duplicate code for calling the special Intel camera sensor GPIO
type _DSM (79234640-9e10-4fea-a5c1-b5aa8b19756f) and mapping GPIOs to
the sensor with a call to int3472_discrete_parse_crs() from the int3472
driver.
Besides avoiding code duplication the int3472 version of the code also
supports more features, like mapping the powerdown GPIO to a regulator on
the mt9m114 which is necessary to make the camera on the Asus T100TA work.
Signed-off-by: Hans de Goede <hansg@kernel.org>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250507184737.154747-7-hdegoede@redhat.com
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Commit c7194b2180 ("media: atomisp: On streamoff wait for buffers owned
by the CSS to be given back") added draining of the CSS buffer queue to
the beginning of atomisp_stop_stream().
But it turns out that when telling the CSS to stop streaming it needs at
least 1 buffer queued, because the CSS firmware waits for a frame to be
completed before stopping and without buffers it cannot complete a frame.
At the end of atomisp_stop_stream() it is always safe to return buffer
ownership to the videobuf2-core. Either atomisp_css_stop() has successfully
stopped the stream; or the atomisp_reset() later on which power-cycles
the ISP will definitely have stopped the stream.
Drop the draining of the CSS buffer queue to fix the "stop stream timeout."
error and move the atomisp_flush_video_pipe() call after atomisp_reset(),
passing false for the warn_on_css_frames flag since some buffers still
being marked as owned by the CSS expected on stream off.
Also increase the timeout in destroy_stream(), since this waits for
the last frame to be completed this can take longer then 40 ms. When e.g.
using a framerate of 15 fps, this could take 66ms, make the timeout 200 ms
to be on the safe side.
Signed-off-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250505210008.152659-6-hdegoede@redhat.com
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The atomisp interrupt handling will free the MIPI / CSI-receiver buffers
when processing a frame-completion event if the stop_requested flag is set,
but only in the ISP2400 / BYT, not in the ISP2401 / CHT case.
There are 2 problems with this:
1. Since this is only done in the BYT case the "mipi frames are not freed."
warning always triggers on CHT devices.
2. There are 2 stop_requested flags, ia_css_pipe.stop_requested and
ia_css_pipeline.stop_requested. The ISR checks the ia_css_pipe flag,
but atomisp_css_stop() sets the ia_css_pipeline.stop_requested flag.
So even on BYT freeing the buffers from the ISR never happens.
This likely is a good thing since the buffers get freed on the first
frame completion event and there might be multiple frames queued up.
Fix things by completely dropping the freeing of the MIPI buffers from
the ISR as well as the stop_requested flag always freeing the buffers
from ia_css_uninit().
Also drop the warning since this now always is expected behavior.
Note that ia_css_uninit() get called whenever streaming is stopped
through atomisp_stop_stream() calling atomisp_reset() so the buffers
are still freed whenever streaming is stopped.
Signed-off-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250505210008.152659-5-hdegoede@redhat.com
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
