- 25 Nov, 2022 40 commits
-
-
Hans de Goede authored
atomisp_css_suspend() is a 1:1 copy of atomisp_css_uninit() and atomisp_css_resume() is a 1:1 copy of atomisp_css_init(). Remove the 2 copies and have their one caller just call atomisp_css_uninit() / atomisp_css_init() instead. Reviewed-by:
Andy Shevchenko <andy@kernel.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Hans de Goede authored
atomisp_css_uninit() only runs when all streams are stopped and atomisp_css_stop() already clears the config, so the clearing of the config can be dropped from atomisp_css_uninit(). Reviewed-by:
-
Hans de Goede authored
atomisp_mrfld_power_down()/_up() are unnecessary wrappers around atomisp_mrfld_power() remove them and just call atomisp_mrfld_power() directly. Reviewed-by:
-
Hans de Goede authored
atomisp_reset() calls atomisp_mrfld_power_down() after calling atomisp_runtime_suspend(), which already calls atomisp_mrfld_power_down() itself. And the some goes for atomisp_runtime_resume() / atomisp_mrfld_power_up(). Reviewed-by:
-
Hans de Goede authored
After the conversion to videobuf2 userptr support is no longer needed, drop it. Reviewed-by:
-
Hans de Goede authored
After the conversion to videobuf2 a bunch of ia_css_frame_*() functions are unused, remove them. Reviewed-by:
-
Hans de Goede authored
Remove atomisp_css_yuvpp_configure_viewfinder(), it is not used anywhere. Reviewed-by:
-
Hans de Goede authored
Remove ia_css_pipe_get_acc_stage_desc() and sh_css_flush(), after removing the accelerator /dev/video# node and related ioctls these are no longer used. Reviewed-by:
-
Hans de Goede authored
atomisp_release() was taking pipe->vb_queue_mutex + isp->mutex at the same time. But if the /dev/video# node is closed while still streaming then vb2_queue_release() will call atomisp_stop_streaming() which takes isp->mutex itself, leading to a deadlock. To fix this only take isp->mutex after cleaning up the v4l2_fh / the vb2_queue. While at it switch to vb2_fop_release() which will take pipe->vb_queue_mutex for us, which also resolves a FIXME comment. Reviewed-by:
-
Hans de Goede authored
I managed to trigger an atomisp_css_start() error by pushing my test system towards an OOM situation, this resulted in the following errors: atomisp-isp2 0000:00:03.0: alloc pages err... atomisp-isp2 0000:00:03.0: hmm_bo_alloc_pages failed. atomisp-isp2 0000:00:03.0: stream[0] start error. But it is not entirely clear what the root cause of the "alloc pages err..." error is. I suspect the root cause is alloc_pages_bulk_array() failing. Add a log message to make the root cause more clear if this is hit again. Reviewed-by:
-
Hans de Goede authored
I managed to trigger an atomisp_css_start() error by pushing my test system towards an OOM situation, this triggered the following WARN_ON() in __vb2_queue_cancel() in videobuf2-core.c: /* * If you see this warning, then the driver isn't cleaning up properly * after a failed start_streaming(). See the start_streaming() * documentation in videobuf2-core.h for more information how buffers * should be returned to vb2 in start_streaming(). */ if (WARN_ON(atomic_read(&q->owned_by_drv_count))) { Fix this by calling atomisp_flush_video_pipe() to return any queued buffers back to the videobuf2-core on an atomisp_css_start() error. Reviewed-by: -
Hans de Goede authored
With the accel code gone this is unused, remove it. Reviewed-by:
-
Hans de Goede authored
The ATOMISP_ACC_* custom ioctls and the ACC device node have been removed in commit a5c17adbadcb ("media: atomisp: Remove the ACC device node"). This means that pipe_configs[pipe_id].acc_extension now never gets set which causes atomisp_compat_css20.c: __create_pipe() to always skip creation of pipes with a pipe_id of IA_CSS_PIPE_ID_ACC / a mode of IA_CSS_PIPE_MODE_ACC. This allows removing of the acc_pipe creation / handling code from mainly sh_css.c and a bunch of other places. Reviewed-by: -
Hans de Goede authored
media: atomisp: Silence: 'atomisp_q_one_s3a_buffer: drop one s3a stat which has exp_id xx' log messages Standard v4l2 userspace apps do not consume the s3a statistics block data. Until we have a userspace consumer for this (libcamera), which might also involve changing the API for this, lower the log level of these messages to dev_dbg() to avoid them filling up the logs. Reviewed-by:
-
Hans de Goede authored
Depending on which order userspace makes various v4l2 calls, the sensor might still be powered down when set_fmt is called. What should really happen here is delay the writing of the mode-related registers till streaming is started, but for now use the same quick fix as the atomisp_ov2680 code and call power_up() from set_fmt() in combination with keeping track of the power-state to avoid doing the power-up sequence twice. Reviewed-by:
-
Hans de Goede authored
Remove the complicated __atomisp_get_pipe() helper, atomisp_buf_done() only needs the pipe pointer in cases where it has a frame, so we can simply get the pipe from the frame using the vb_to_pipe() helper. Reviewed-by:
-
Hans de Goede authored
Make atomisp_g_fmt_cap() default to YUV420 so that it matches with what atomisp_try_fmt_cap() and atomisp_queue_setup() do when they need to pick a default pixelformat. Reviewed-by:
-
Hans de Goede authored
The atomisp_try_fmt() call in atomisp_try_fmt_cap() replaces the pixelformat passed by userspace with the sensors native pixelformat. Which always gets replaced by V4L2_PIX_FMT_YUV420 by atomisp_adjust_fmt() because raw sensor formats are not supported. This needs to be fixed so that userspace which does a try_fmt call before s_fmt does not end up always getting YUV420 even if it passed something else into the try_fmt call. To fix this restore the userspace requested pixelformat before the atomisp_adjust_fmt() call. atomisp_adjust_fmt() will replace this with V4L2_PIX_FMT_YUV420 in case an unsupported format is requested. Note this relies on the "media: atomisp: Refactor atomisp_adjust_fmt()" change, before that atomisp_adjust_fmt() would return -EINVAL for unsupported pixelformats. Reviewed-by:
-
Hans de Goede authored
Refactor atomisp_adjust_fmt(): 1. The block starting at "format_bridge = atomisp_get_format_bridge(...)" and ending with "if (field == V4L2_FIELD_ANY) field = V4L2_FIELD_NONE;" is duplicated. With only the second block: a) Properly checking that format_bridge is not NULL; amd b) Having the special handling for IA_CSS_FRAME_FORMAT_RAW Remove the first block. 2. On a NULL return from atomisp_get_format_bridge(f->fmt.pix.pixelformat) fall back to V4L2_PIX_FMT_YUV420 just like in the IA_CSS_FRAME_FORMAT_RAW case. atomisp_adjust_fmt() is used in VIDIOC_TRY_FMT handling and that should jusy pick a fmt rather then returning -EINVAL. Reviewed-by:
-
Hans de Goede authored
camorama calls VIDIOC_REQBUFS(V4L2_MEMORY_MMAP) to test if MMAP support works (this was added specifically because of the previously broken MMAP support in atomisp). Currently this fails because atomisp_get_css_frame_info() fails in this case. Although it is weird to call VIDIOC_REQBUFS before VIDIOC_S_FMT, it is allowed to do this. Fix this not working by doing a S_FMT to V4L2_PIX_FMT_YUV420 + the highest supported resolution. Note this will cause camorama to use mmap mode, which means it will also use libv4l2 to do format conversion. libv4l2 will pick V4L2_PIX_FMT_RGB565 as input format and this will lead to a garbled video display. This is a libv4lconvert bug, the RGB565 -> RGB24 path in libv4lconvert assumes that stride == width which is not true on the atomisp. I've already send out a libv4lconvert fix for this. Also this can be worked around by passing --dont-use-libv4l2 as argument to camorama. Link: https://git.linuxtv.org/v4l-utils.git/commit/?id=aecfcfccfc2f78d7531456ffa5465666c6bc641eReviewed-by:
-
Hans de Goede authored
To fix atomisp_queue_setup() sometimes failing it needs to be able to call atomisp_set_fmt(), but atomisp_queue_setup() (VIDIOC_REQBUFS) does not get passed a file handle by the videobuf2 core. Partly revert commit b3be98f984d4 ("media: atomisp: Remove a couple of not useful function wrappers") so that atomisp_set_fmt() can be used without a file handle. Reviewed-by: -
Hans de Goede authored
Convert atomisp to use videobuf2. This fixes mmap not working and in general moving over to the more modern videobuf2 is a good plan. Reviewed-by:
-
Hans de Goede authored
Several places rely on the [frame_]info member being the first member of struct ia_css_frame, so that &frame->info will yield NULL when frame is NULL (some places already explicitly check for a NULL frame pointer but not nearly all). For videobuf2 support the vb2_v4l2_buffer struct needs to be embedded in the frame struct and it needs to be the first member. Breaking the assumption that &frame->info will yield NULL when frame is NULL. Add a ia_css_frame_get_info() helper to return either the ia_css_frame_info struct embedded in the frame, or NULL when the frame pointer is NULL and use this in places where a ia_css_frame_info ptr or NULL is expected. To make sure that we catch all uses of the info field this patch also renames the info field to frame_info. This is a preparation patch for converting the driver to videobuf2. Reviewed-by:
-
Hans de Goede authored
Use the new atomisp_flush_video_pipe() helper instead of open-coding it. Reviewed-by:
-
Hans de Goede authored
With the videobuf2 conversion accessing the index of a frame is going to become more involved and writing this out each time is undesired. Add an 'i' helper variable for the index and assing this once as preparation for the videobuf2 conversion. This also makes use of the new rules wrt max line-lengths in the kernel to avoid breaking up a bunch of lines. Not breaking these lines results in better readable code (IMHO). Reviewed-by:
-
Hans de Goede authored
Instead of using an integer to keep count of how many buffers have been handed over to the ISP (buffers_in_css) move buffers handed over to the ISP to a new buffers_in_css list_head so that we can easily loop over them. This removes the need for atomisp_flush_video_pipe() to loop over all buffers and then (ab)use the state to figure out if they were handed over to the ISP. Since the buffers are now always on a list when owned by the driver this also allows the buffer_done path on flush vs normal completion to be unified (both now need a list_del()) and this common code can now be factored out into a new atomisp_buffer_done() helper. This is a preparation patch for moving the driver over to the videobuf2 framework. Reviewed-by:
-
Hans de Goede authored
The atomisp_buffers_queued[_pipe] functions are not used anywhere, remove them. Reviewed-by:
-
Hans de Goede authored
There is no guarantee that when we stop the pipeline all buffers owned by the CSS are cleanly returned to the videobuf queue. This is a problem with videobuf2 which will complain loudly when not all buffers have been returned after the streamoff() queue op has returned. And this also allows removing a WARN() in the continuous mode path. Reviewed-by:
-
Hans de Goede authored
atomisp_q_video_buffers_to_css() is only used insidd atomisp_fops.c, make it static. Reviewed-by:
-
Hans de Goede authored
Add a function to initialize (rather then alloc/create) a ia_css_frame struct based on an ia_css_frame_info struct. This is a preparation patch for adding videobuf2 support. Reviewed-by:
-
Hans de Goede authored
Add a new hmm creating function to create a vmm object from a vmalloc-ed kernel buffer. This is a preparation patch for adding videobuf2 (and working MMAP mode) support. Reviewed-by:
-
Gautam Menghani authored
The function send_packet() has a race condition as follows: func send_packet() { // do work call usb_submit_urb() mutex_unlock() wait_for_event_interruptible() <-- lock gone mutex_lock() } func vfd_write() { mutex_lock() call send_packet() <- prev call is not completed mutex_unlock() } When the mutex is unlocked and the function send_packet() waits for the call to complete, vfd_write() can start another call, which leads to the "URB submitted while active" warning in usb_submit_urb(). Fix this by removing the mutex_unlock() call in send_packet() and using mutex_lock_interruptible(). Link: https://syzkaller.appspot.com/bug?id=e378e6a51fbe6c5cc43e34f131cc9a315ef0337e Fixes: 21677cfc ("V4L/DVB: ir-core: add imon driver") Reported-by: syzbot+0c3cb6dc05fbbdc3ad66@syzkaller.appspotmail.com Signed-off-by:Gautam Menghani <gautammenghani201@gmail.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Wei Yongjun authored
SPI devices use the spi_device_id for module autoloading even on systems using device tree, after commit 5fa6863b ("spi: Check we have a spi_device_id for each DT compatible"), kernel warns as follows since the spi_device_id is missing: SPI driver ir-spi has no spi_device_id for ir-spi-led Add spi_device_id entries to silence the warning, and ensure driver module autoloading works. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
git://linuxtv.org/hverkuil/media_treeMauro Carvalho Chehab authored
Despite being big, the changes here are trivial: they just change the probing method for I2C. So, apply it as a merge. Tag branch * tag 'br-v6.2g' of git://linuxtv.org/hverkuil/media_tree: (96 commits) media: v4l2-core/tuner-core: Convert to i2c's .probe_new() media: usb: go7007: s2250-board: Convert to i2c's .probe_new() media: tuners/tua9001: Convert to i2c's .probe_new() media: tuners/tda18250: Convert to i2c's .probe_new() media: tuners/tda18212: Convert to i2c's .probe_new() media: tuners/qm1d1c0042: Convert to i2c's .probe_new() media: tuners/qm1d1b0004: Convert to i2c's .probe_new() media: tuners/mxl301rf: Convert to i2c's .probe_new() media: tuners/mt2060: Convert to i2c's .probe_new() media: tuners/m88rs6000t: Convert to i2c's .probe_new() media: tuners/fc2580: Convert to i2c's .probe_new() media: tuners/e4000: Convert to i2c's .probe_new() media: vidtv: Convert to i2c's .probe_new() media: radio/tef6862: Convert to i2c's .probe_new() media: radio/saa7706h: Convert to i2c's .probe_new() media: radio/radio-tea5764: Convert to i2c's .probe_new() media: i2c/wm8775: Convert to i2c's .probe_new() media: i2c/wm8739: Convert to i2c's .probe_new() media: i2c/vs6624: Convert to i2c's .probe_new() media: i2c/vpx3220: Convert to i2c's .probe_new() ... Signed-off-by:
-
Eugen Hristev authored
The Atmel ISC driver is not compliant with media controller specification. In order to evolve this driver, it has to move to media controller, to support enhanced features and future products which embed it. The move to media controller involves several changes which are not backwards compatible with the current usability of the driver. The best example is the way the format is propagated from the top video driver /dev/videoX down to the sensor. In a simple configuration sensor ==> isc , the isc just calls subdev s_fmt and controls the sensor directly. This is achieved by having a lot of code inside the driver that will query the subdev at probe time and make a list of formats which are usable. Basically the user has nothing to configure, as the isc will handle everything at the top level. This is an easy way to capture, but also comes with the drawback of lack of flexibility. In a more complicated pipeline sensor ==> controller 1 ==> controller 2 ==> isc this will not be achievable, as controller 1 and controller 2 might be media-controller configurable, and will not propagate the formats down to the sensor. After discussions with the media maintainers, the decision is to move Atmel ISC to staging as-is, to keep the Kconfig symbols and the users to the driver in staging. Thus, all the existing users of the non media-controller paradigm will continue to be happy and use the old config way. The new driver was added in the media subsystem with a different symbol, with the conversion to media controller done, and new users of the driver will be able to use all the new features. This patch is merely a file move to staging, not affecting any of the users. The exported symbols had to be renamed to atmel_* to avoid duplication with the new Microchip ISC driver. Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Eugen Hristev authored
Move the media_pipeline_start/stop calls from start/stop streaming to the new prepare_streaming and unprepare_streaming callbacks. Signed-off-by:
-
Eugen Hristev authored
As a top MC video driver, the microchip-isc should not propagate the format to the subdevice, it should rather check at start_streaming() time if the subdev is properly configured with a compatible format. Removed the whole format finding logic, and reworked the format verification at start_streaming time, such that the ISC will return an error if the subdevice is not properly configured. To achieve this, media_pipeline_start is called and a link_validate callback is created to check the formats. With this being done, the module parameter 'sensor_preferred' makes no sense anymore. The ISC should not decide which format the sensor is using. The ISC should only cope with the situation and inform userspace if the streaming is possible in the current configuration. The redesign of the format propagation has also risen the question of the enumfmt callback. If enumfmt is called with an mbus_code, the enumfmt handler should only return the formats that are supported for this mbus_code. Otherwise, the enumfmt will report all the formats that the ISC could output. With this rework, the dynamic list of user formats is removed. It makes no more sense to identify at complete time which formats the sensor could emit, and add those into a separate dynamic list. The ISC will start with a simple preconfigured default format, and at link validate time, decide whether it can use the format that is configured on the sink or not. >From now on, the driver also advertises the IO_MC capability. Signed-off-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
-
Eugen Hristev authored
Prepare the support for media-controller. This means that the capabilities of the driver have changed and now it's capable of media controller operations. The driver will register its media device, and add the video entity to this media device. The subdevices are registered to the same media device. The ISC will have a base entity which is auto-detected as microchip_isc_base. It will also register a subdevice that allows cropping of the incoming frame to the maximum frame size supported by the ISC. The ISC will create a link between the subdevice that is asynchronously registered and the microchip_isc_scaler entity. Then, the microchip_isc_scaler and microchip_isc_base are connected through another link. This patch does not change the previous capability of the driver, the fact that the format is still being propagated from the top video node down to the sensor. Signed-off-by:
-
Eugen Hristev authored
The Atmel ISC driver will be moved to staging to support old users that are not using the media controller paradigm. The ISC driver was converted to media controller in the public patch series: https://lore.kernel.org/lkml/20220503095127.48710-1-eugen.hristev@microchip.com/T/#m2c320fa8153c01379a1c35b1d90a00903949513a However the conversion cannot be done directly as it would affect existing users by breaking the old way of configuration for sama5d2 platforms. After discussions with the media maintainers, the decision is to move Atmel ISC to staging as-is, to keep the Kconfig symbols and the users to the driver in staging. Thus, all the existing users of the non media-controller paradigm will continue to be happy and use the old config way. The converted driver would support both sama5d2 and sama7g5 platforms with media controller paradigm, but it requires userspace configuration of the pipeline for all the pipeline modules. In a simple configuration sensor ==> isc , the old isc driver used to call subdev s_fmt and control the sensor directly. This was achieved by having a lot of code inside the driver that was querying the subdev at probe time and made a list of formats which are usable. Basically the user had nothing to configure, as the isc would handle everything at the top level. This was an easy way to capture, but also came with the drawback of lack of flexibility. In a more complicated pipeline sensor ==> controller 1 ==> controller 2 ==> isc this would not be achievable, as controller 1 and controller 2 might be media-controller configurable, and will not propagate the formats down to the sensor. The new driver Microchip ISC would solve all these problems and exposes pads entities and links to userspace. For the ease of tracking, the patches that convert to media controller come on top of this patch that simply readds the driver to the new location under the new Kconfig symbols. To differentiate between the old driver and the new driver, I have renamed the new driver to Microchip ISC, renaming the Kconfig symbols as well, and all the mentions inside the driver. The only thing that remains common is the file include/linux/atmel-isc-media.h which is the ABI for the v4l2 custom controls that the ISC exposes. This file is used by both driver, so I kept it as-is. To further avoid confusion all files have been renamed and all functions named isc_* as well. The exported symbols have been renamed with added microchip_ prefix, to avoid symbol duplication with the old driver, and to avoid confusion. Other than that, I have fixed small checkpatch issues when readding the driver. Signed-off-by:
-
Eugen Hristev authored
The Atmel ISC will be moved to staging thus the atmel platform will only have the ISI driver. The new media-controller converted ISC driver will be placed inside a dedicated microchip platform directory. It is then natural to have the microchip-csi2dc moved to this new platform directory. The next step is to add the Microchip ISC driver to the new platform directory and reside together with the Microchip CSI2DC driver. Signed-off-by:
-
