- 09 Jun, 2023 40 commits
-
-
Hans de Goede authored
A lot of work has been done on the atomisp driver lately. Rewrite the TODO file to drop all the already fixed items: * Moved to videobuf2 + fixed mmap support * Whole bunch of v4l2 API fixes making more apps work * v4l2-async sensor probing support * pm-runtime support (for some sensor drivers at least) * buffer MM code was cleaned up / replaced when moving the videobuf2 And add a new TODO list (retaining some of the old items) split into items which absolutely must be fixed before the driver can be moved out of staging: 1. Conflicting hw-ids with regular sensor drivers 2. Private userspace API stuff As well as a list of items which also definitely needs to be fixed but which could also be fixed after moving the driver out of staging. Link: https://lore.kernel.org/r/20230529103741.11904-2-hdegoede@redhat.comSigned-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Hans de Goede authored
Not all functions used in gmin_get_var_int() update len to the actual length of the returned string. So len may still have its initial value of the length of val[] when "val[len] = 0;" is run to ensure 0 termination. If this happens we end up writing one beyond the bounds of val[], fix this. Note this is a quick fix for this since the entirety of atomisp_gmin_platform.c will be removed once all atomisp sensor drivers have been moved over to runtime-pm + v4l2-async device registration. Closes: https://lore.kernel.org/linux-media/26f37e19-c240-4d77-831d-ef3f1a4dd51d@kili.mountain/Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
Dan Carpenter authored
Ideally, strlen(cur->string.pointer) and strlen(out) would be the same. But this code is using strscpy() to avoid a potential buffer overflow. So in the same way we should take the strlen() of the smaller string to avoid a buffer overflow in the caller, gmin_get_var_int(). Link: https://lore.kernel.org/r/26124bcd-8132-4483-9d67-225c87d424e8@kili.mountain Fixes: 387041cd ("media: atomisp: improve sensor detection code to use _DSM table") Signed-off-by:
-
Hans de Goede authored
Drop v4l2_get_acpi_sensor_info() the 2 sensor drivers which were using this have both been converted to v4l2-async probing, relying on the atomisp_csi2_bridge.c code to add the GPIO mappings instead. Link: https://lore.kernel.org/r/20230525190100.130010-5-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Switch the atomisp-gc0310 driver to v4l2 async device registration. After this change this driver no longer depends on atomisp_gmin_platform and all atomisp-isms are gone. Link: https://lore.kernel.org/r/20230525190100.130010-4-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Turn the atomisp-ov2680 driver into a standard v4l2 sensor driver: 1. Stop filling camera_mipi_info 2. Stop calling v4l2_get_acpi_sensor_info() this will be done by atomisp_csi2_bridge_parse_firmware() now 3. Switch to v4l2 async device registration After this change this driver no longer depends on atomisp_gmin_platform and all atomisp-isms are gone. While at it, also add missing mutex_destroy() to ov2680_remove(). Link: https://lore.kernel.org/r/20230525190100.130010-3-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Add support for using v4l2-async sensor registration. This has been tested with both the gc0310 and the ov2680 sensor drivers. Drivers must add the ACPI HIDs they match on to the supported_sensors[] array in the same commit as that they are converted to v4l2_async_register_subdev_sensor(). Sensor drivers also must check they have a fwnode graph endpoint and return -EPROBE_DEFER from probe() if there is no endpoint yet. This guarantees that the GPIO mappings are in place before the driver tries to get GPIOs. For now it also is still possible to use the old atomisp_gmin_platform based sensor drivers. This is mainly intended for testing while moving other sensor drivers over to runtime-pm + v4l2-async. Link: https://lore.kernel.org/r/20230525190100.130010-2-hdegoede@redhat.comReviewed-by:
-
Hans Verkuil authored
The sanity checks were done too late, so move them up. This fixes this smatch warning: drivers/staging/media/atomisp/pci/sh_css_firmware.c:247 sh_css_load_firmware() warn: variable dereferenced before check 'fw_data' (see line 237) Link: https://lore.kernel.org/r/20230524121150.435736-9-hverkuil-cisco@xs4all.nlSigned-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Hans Verkuil authored
Fix a compiler warning: drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c:1525:13: warning: 'settings' may be used uninitialized [-Wmaybe-uninitialized] The 'settings' variable is actually always initialized, but the compiler isn't quite able to figure that out. Just initialize it to 0 to avoid this warning. Link: https://lore.kernel.org/r/20230524121150.435736-2-hverkuil-cisco@xs4all.nlSigned-off-by:
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then commit 03c835f4 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Link: https://lore.kernel.org/r/20230524151646.486847-3-u.kleine-koenig@pengutronix.deSigned-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Hans de Goede authored
camera_mipi_info is an atomisp / atomisp_gmin_platform specific struct, allow mipi_info pointers to be NULL. This is a preparation patch for making atomisp work with standard v4l2 sensor drivers. Link: https://lore.kernel.org/r/20230518153733.195306-9-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
atomisp_register_device_nodes() already iterates over the ports/sensors in a loop and that loop already does not include the TPG input. So we can simply setup the CSI2-port <-> ISP and sensor <-> CSI2-port mediactl-pad links there instead of repeating the loop in atomisp_create_pads_links(), which atomisp_register_device_nodes() used to call later on. Link: https://lore.kernel.org/r/20230518153733.195306-8-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Delay mapping sensors to inputs till atomisp_register_device_nodes() time. There are 2 reasons for this: 1. This guarantees a stable input order independent of the sensor probe order. 2. This is a preparation patch for v4l2-async sensor probing support. Link: https://lore.kernel.org/r/20230518153733.195306-7-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Store number of sensor lanes per port in struct atomisp_device. This is a preparation patch for adding v4l2-async sensor probing support. With async probing the inputs will get registered later, but we can already fill the sensor_lanes array when parsing the fwnodes. Link: https://lore.kernel.org/r/20230518153733.195306-6-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Rename __get_mipi_port() to atomisp_port_to_mipi_port(), this is not a private (not static) function so its name should be properly prefixed. While at is also cleanup the weird handling of ATOMISP_CAMERA_PORT_TERTIARY this seems to be a left over from when the driver also supported CSI receivers with only 2 ports, but those are not supported by the current code base, so this can be cleaned up now. Link: https://lore.kernel.org/r/20230518153733.195306-5-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Now that we only have a single /dev/video# node it is no longer necessary for atomisp_video_init() to be parametrized. Remove its parameters and while at it also change the name from the single /dev/video# node from "ATOMISP ISP PREVIEW output" to "ATOMISP video output". Link: https://lore.kernel.org/r/20230518153733.195306-4-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Remove unused fields from struct atomisp_input_subdev: 1. frame_size is never used at all 2. sensor_index is always 0, just directly pass 0 in the single user. Link: https://lore.kernel.org/r/20230518153733.195306-3-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
The info in the MRFLD_PORT_NUM define is duplicate with the ATOMISP_CAMERA_NR_PORTS and N_MIPI_PORT_ID enum values. Drop the MRFLD_PORT_NUM define and switch to N_MIPI_PORT_ID since the [sensor_]lanes arrays are in enum mipi_port_id order. Link: https://lore.kernel.org/r/20230518153733.195306-2-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Remove the gc0310.h header file, moving most of its content into atomisp-gc0310.c and dropping some unused parts. This brings the gc0310 sensor driver inline with other sensor regular / non atomisp sensor drivers which usually only are one single .c file. Link: https://lore.kernel.org/r/20230518153214.194976-9-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
gc0310_s_config() used to call camera_sensor_platform_data.csi_cfg() back when the gc0310 driver was still using the atomisp_gmin_platform code for power-management. Now it is just a weirdly named wrapper around gc0310_detect(), drop gc0310_s_config() and make probe() call gc0310_detect() directly. Link: https://lore.kernel.org/r/20230518153214.194976-8-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Remove a bunch of unused includes and sort the remainging includes alphabetically. Link: https://lore.kernel.org/r/20230518153214.194976-7-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
gc0310_remove() must not call kfree(dev) since the gc0310_device struct is devm managed so explicitly freeing it causes a double free. While at it add a missing mutex_destroy() call for the input_lock. Link: https://lore.kernel.org/r/20230518153214.194976-6-hdegoede@redhat.com Fixes: 340b4dd6 ("media: atomisp: gc0310: Use devm_kzalloc() for data struct") Reviewed-by:
-
Hans de Goede authored
The XXGC0310 ACPI hardware-id does not appear to be used in the DSDTs of any hardware out there, so drop it. Link: https://lore.kernel.org/r/20230518153214.194976-5-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Now that we have only one /dev/video# node we can set asd.subdev.devnode once from isp_subdev_init_entities(), replacing the hack to set it the last opened/closed /dev/video# node from atomisp_open() / atomisp_release(). Reviewed-by:
-
Hans de Goede authored
The in_reset argument to atomisp_css_start() is only ever true in atomisp_assert_recovery_work(), drop the argument and move the special reset handlig to atomisp_assert_recovery_work(). Reviewed-by:
-
Hans de Goede authored
Remove no longer user atomisp_get_css_pipe_id() function. Reviewed-by:
-
Hans de Goede authored
The css_pipe_id argument pass to atomisp_css_[start|stop]() is not used, drop it. Reviewed-by:
-
Hans de Goede authored
The atomisp_[sub]dev_users() functions are not used anymore, remove them. Reviewed-by:
-
Hans de Goede authored
Just having a /dev/video# node open is not a reason to block system suspend. At least when userspace is not streaming. In that case the worst case scenario is that streams have been created, but we can just destroy those before powering off the ISP and recreate the streams on resume. Fixing suspend when streaming is left as a FIXME item for later. Reviewed-by:
-
Hans de Goede authored
There now no longer is a non force version of atomisp_destroy_pipes_stream_force() so having the _force postfix no longer makes sense rename it to atomisp_destroy_pipes_stream(). Reviewed-by:
-
Hans de Goede authored
Both atomisp_isr() and recovery_work() now have a combination of: 1. "if (!isp->asd.streaming) goto out;" code at the top 2. "if (sp->asd.streaming) {}" blocks in the body which are jumped over by the goto out. This means that the "if (sp->asd.streaming) {}" blocks are always executed if they are not jumped over by the goto. Remove the unnecessary "if (sp->asd.streaming)" checks and re-indent the code. Reviewed-by: -
Hans de Goede authored
atomisp_streaming_count() is just an alias for isp->asd.streaming now, replace it with directly checking that and remove the helper. Reviewed-by:
-
Hans de Goede authored
Remove the no longer used atomisp_css_flush() function and merge atomisp_assert_recovery_work() and __atomisp_css_recover() into a single function. Reviewed-by:
-
Hans de Goede authored
The ATOMISP_DEVICE_STREAMING_STOPPING pipe state comes from when we still had continuous mode. This would be set when streaming from both capture + preview devnodes when 1 of the 2 streams has been stopped and the driver was waiting for the other stream to get stopped too. With continuous mode gone the stopping state is no longer necessary and asd->streaming can be changed to a bool. Note that atomisp_assert_recovery_work() would still temporarily set streaming to stopping, but it does so with the isp->mutex held and changes streaming to either enabled or disabled before releasing the mutex, so none of the consumers which care about the difference ever see the stopping state. Reviewed-by:
-
Hans de Goede authored
All switch (pipe->asd->streaming) cases in atomisp_pipe_check() are either no-ops or never happen: 1. ATOMISP_DEVICE_STREAMING_DISABLED already is a no-op 2. The videobuf2 core guarantees that when we are streaming vb2_is_busy() returns true. So the ATOMISP_DEVICE_STREAMING_ENABLED case is already handled by the if above the switch (pipe->asd->streaming). 3. After recent changes pipe->asd->streaming is only ever set to ATOMISP_DEVICE_STREAMING_STOPPING in atomisp_assert_recovery_work() and that function holds isp->mutex and always transitions the streaming state to ATOMISP_DEVICE_STREAMING_DISABLED or ATOMISP_DEVICE_STREAMING_ENABLED before releasing the mutex. So atomisp_pipe_check() never sees ATOMISP_DEVICE_STREAMING_STOPPING. Remove the entire switch-case. Reviewed-by:
-
Hans de Goede authored
Now that continuous mode is gone and we only have 1 /dev/video# node, combined with only allowing 1 open of that /dev/video# node for now, there is no need to check for other (sub)dev / pipe users. Remove the unnecessary checks for a nice cleanup. Note we also don't need to set asd->streaming to disabled since the vb2_fop_release() call done by atomisp_release() will have called atomisp_stop_streaming() already at this point (if necessary) and that will have already done this. Reviewed-by:
-
Hans de Goede authored
Now that continuous mode is gone and we only have 1 /dev/video# node, the videobuf2 core guarantees that atomisp_css_[start|stop]() will only be called one at a time. So there is no need for atomisp_streaming_count() counts. When reqbufs has been done then the streams are guaranteed to be created, and streaming cannot be started without reqbufs so there is no need for atomisp_css_start() to check if it needs to create the streams. Use this to clean-up atomisp_css_[start|stop](). While at it also fix atomisp_css_start() not re-creating the streams on an error, breaking the guarantee that the streams are always there after a succesfull reqbufs call. Reviewed-by:
-
Hans de Goede authored
Now that continuous mode is gone and we only have 1 /dev/video# node, the videobuf2 core guarantees that atomisp_[start|stop]_streaming() will only be called one at a time. So there is no need to check for things like the isp is already streaming when starting, or other streams still being active while stopping. Remove checks for these from atomisp_[start|stop]_streaming(). While at it also improve the logging a bit: 1. Remove the dev_err(isp->dev, "atomisp_reset") logged on every stream stop (even though everything is fine. 2. Log a message when starting/stopping the sensor stream fails Reviewed-by:
-
Hans de Goede authored
Now that we no longer have continuous mode we always want to start the sensor on the first atomisp_start_streaming() call and stop it on the first atomisp_stop_streaming() call. Remove atomisp_sensor_start_stream() which returned the number of streams which should be active before starting the sensor and always start/stop the sensor directly. Reviewed-by:
-
Hans de Goede authored
isp_timeout only ever gets set in __atomisp_css_recover() and then immediately gets cleared again after calling atomisp_reset(). All this happens with isp->mutex held. The only consumer of isp->isp_timeout is atomisp_stop_streaming(), which also holds isp->mutex and which is *not* called by atomisp_reset(). Since both hold isp->mutex and since __atomisp_css_recover() clears isp_timeout before releasing the mutex, atomisp_stop_streaming() can never see isp_timeout being true, so just remove the flag. Reviewed-by:
-
