summaryrefslogtreecommitdiffstats
path: root/drivers/staging/media/atomisp/pci/atomisp_cmd.h
AgeCommit message (Collapse)AuthorFilesLines
2022-11-25media: atomisp: Remove atomisp_ospm_dphy_up()/_down() functionsHans de Goede1-2/+0
atomisp_ospm_dphy_up() is an empty function now and atomisp_ospm_dphy_down() contains a couple of checks + goto done statements which don't matter since the function always ends up at the done label regardless and then it does 1 pci-config write. Move the single pci-config write directly to atomisp_power_off() and remove the atomisp_ospm_dphy_up()/_down() functions. 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>
2022-11-25media: atomisp: Remove duplication between runtime-pm and normal-pm codeHans de Goede1-2/+2
atomisp_suspend() contains a 1:1 copy of atomisp_runtime_suspend() and the same goes for the resume() functions. Rename the runtime functions to atomisp_power_on()/_off() and use these as runtime-pm handlers as well as helper in other places to remove the code duplication. 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>
2022-11-25media: atomisp: Remove double atomisp_mrfld_power_down()/_up() calls from ↵Hans de Goede1-2/+0
atomisp_reset() 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: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-11-25media: atomisp: Make it possible to call atomisp_set_fmt() without a file handleHans de Goede1-1/+1
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: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-11-25media: atomisp: Convert to videobuf2Hans de Goede1-2/+1
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: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-11-25media: atomisp: Also track buffers in a list when submitted to the ISPHans de Goede1-0/+4
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: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-11-25media: atomisp: Remove unused atomisp_buffers_queued[_pipe] functionsHans de Goede1-4/+0
The atomisp_buffers_queued[_pipe] functions are not used anywhere, remove them. 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>
2022-09-24media: atomisp: Remove atomisp_source_pad_to_stream_id()Hans de Goede1-2/+0
atomisp_source_pad_to_stream_id() returns ATOMISP_INPUT_STREAM_GENERAL unconditionally now. Drop it and directly use ATOMISP_INPUT_STREAM_GENERAL in its callers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-09-24media: atomisp: Make atomisp_set_raw_buffer_bitmap() staticHans de Goede1-2/+0
atomisp_set_raw_buffer_bitmap() is only used in atomisp_cmd.c, make it static. Unfortunately this still requires a forward declaration (the function cannot be moved easily). Still this will at least make it obvious to anyone reading the code that the function is not used elsewhere. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-09-24media: atomisp: Remove a couple of not useful function wrappersHans de Goede1-1/+1
The __atomisp_reqbufs(), __atomisp_streamoff() are 1:1 wrappers for the non __ prefixed functions now, drop these wrappers. The atomisp_s_fmt_cap() wrapper is almost a 1:1 wrapper for atomisp_set_fmt() adjust the latter to have the right function prototype and drop the wrapper. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-09-24media: atomisp: Remove watchdog timerHans de Goede1-2/+1
The watchdog timer code to recover from the ISP getting stuck has several major issues: 1. There is no way to do fault injection and normally the ISP does not get stuck, so is it is impossible to test it. 2. It in essence just stops all streams, resets the ISP and then brings everything back up. Userspace can easily do this itself by using a timeout on dqbuf and then closing (which causes a poweroff) + re-opening the device. Doing this in userspace (if it ever turns out to be necessary) greatly simplifies the kernel code and in general will be a more robust solution. Even just a quick look at the code finds several more issues: 3. The need to sync-cancel the timers + work on streamoff requires isp->mutex to be dropped halfway during the ioctl opening all sorts of races. 4. The atomisp code supports setting up 2 pipelines, streaming from two sensors at the same time. But there is only a single wdt_work and stopping one of the 2 streams will cancel the timers + work, stopping the wdt even though the other stream might still be running. 5. In case atomisp_css_flush() the sync cancel is done while keeping isp->mutex locked, causing a deadlock when racing with wdt_work which also takes isp->mutex. 6. Even though the watchdog is purely a software/driver thing which just checkes that new frames keep coming in, there are 2 completely different implementations for the ISP2400/ISP2401 which is not necessary at all. So all in all I believe that it is better to just remove the current watchdog implementation. Fixing all the issues with the current implementation will be so much work, that if it turns out that we do need something like this then doing a clean re-implementation from scratch will be better anyways. wdt_work was also (ab)used to reset the ISP after the firmware signalled an fw-assert error through the irq, add a new assert_recover_work to replace this. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-09-24media: atomisp: Remove the ACC device nodeHans de Goede1-1/+0
The ACC /dev/video# device node uses a struct video_device embedded in an atomisp_acc_pipe struct instead of in an atomisp_video_pipe struct. Yet it uses the same file-ops and ioctl-ops even though it does not have a videobuf queue, which makes e.g. the mmap fop nonsense. Worse the only file-ops / ioctls which differentiate between the 2 types and correctly do container_of on the right type are the open/release fops and the vidioc_default handler. The mmap and poll fops and *all* other ioctl handlers unconditionally do container_of on the passed in struct video_device blindly assuming they are dealing with the one embedded in the atomisp_video_pipe struct. This makes it trivial for userspace to cause all sort of undefined behavior by calling mmap, poll or the other ioctls on the ACC device node! Presumably the use of the ACC device node was to allow making the special ioctls to load custom programs while the other /dev/video# nodes were already open, since the /dev/video# nodes can currently all be opened only once (which needs to be fixed). commit 4bbca788b6eb ("media: atomisp: remove private acceleration ioctls") has removed the custom ATOMISP_ACC_* ioctls, so there no longer is any reason to keep the ACC device node. As explained above its presence can easily cause the kernel to crash, so remove the ACC device node and the code for handling it. Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-09-24media: atomisp: Remove atomisp_file_fops and atomisp_file_ioctl_opsHans de Goede1-1/+0
After the file-injection support removal, atomisp_video_pipe->type never is V4L2_BUF_TYPE_VIDEO_OUTPUT anymore, so the V4L2_BUF_TYPE_VIDEO_OUTPUT support path in atomisp_video_init() is never hit and this path is the only user of atomisp_file_fops and atomisp_file_ioctl_ops. Remove atomisp_file_fops and atomisp_file_ioctl_ops and all of the functions which are only referenced by these ops structs. Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2021-11-15media: atomisp: get rid of atomisp_get_frame_pgnr() abstractionMauro Carvalho Chehab1-2/+0
Simplify the code by getting rid of this function, as it ends being just a single line of code. Link: https://lore.kernel.org/linux-media/80ea920d14379124ba92aab2e6a6d12a92d79b2b.1636544620.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-15media: atomisp: properly implement g_fmtMauro Carvalho Chehab1-2/+2
The current logic only initializes pipe->pix after setting up a pipeline - e. g. after start streaming. While it makes sense to get the format of the pipeline, when it is set, this breaks support for generic applications, as they rely on getting the current sensor format (which is usually the highest resolution format). So, implement a call to the sensor's get_fmt, when this is called before setting up a pipeline. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-05-10media: staging: media: atomisp: pci: Format comments according to ↵Aline Santana Cordeiro1-118/+43
coding-style in file atomisp_cmd.h Format all comments according to the coding-style. Issue detected by checkpatch.pl. Signed-off-by: Aline Santana Cordeiro <alinesantanacordeiro@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-03-23media: staging: atomisp: reduce kernel stack usageArnd Bergmann1-1/+1
The atomisp_set_fmt() function has multiple copies of the large v4l2_format structure on its stack, resulting in a warning about excessive stack usage in some rare randconfig builds. drivers/staging/media/atomisp/pci/atomisp_cmd.c:5600:5: error: stack frame size of 1084 bytes in function 'atomisp_set_fmt' [-Werror,-Wframe-larger-than=] Of this structure, only three members in the 'fmt.pix' member are used, so simplify it by using the smaller v4l2_pix_format structure directly. This reduces the stack usage to 612 bytes, and it could be reduced further by only storing the three members that are used. Link: https://lore.kernel.org/linux-media/20210226140524.3478346-1-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-07-18media: atomisp: Get rid of struct pci_dev in struct atomisp_deviceAndy Shevchenko1-2/+2
struct atomisp device has struct device and struct pci_dev pointers which are basically duplicates of each other. Drop the latter in favour of the former. While here, unify pdev to be pointer to struct pci_device and reindent some (touched) lines for better readability. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: get rid of an iomem abstraction layerMauro Carvalho Chehab1-10/+0
The hive_isp_css_custom_host_hrt.h code, together with atomisp_helper.h, provides an abstraction layer for some functions inside atomisp_compat_css20.c and atomisp_cmd.c. There's no good reason for that. In a matter of fact, after removing the abstraction, the code looked a lot cleaner and easier to understand. So, get rid of them. While here, get rid also of the udelay(1) abstraction code. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: add SPDX headersMauro Carvalho Chehab1-0/+1
This driver is licensed under GPL 2.0, as stated inside their headers. Add the proper tag there. We should probably latter cleanup the reduntant licensing text, but this could be done later, after we get rid of other abstraction layers. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: partially get rid of one abstraction layerMauro Carvalho Chehab1-6/+6
The very same macros are defined as CSS_foo and IA_CSS_foo. Remove this abstraction, as it just make things confusing, for no good reason. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-05-20media: atomisp: cleanup directory hierarchyMauro Carvalho Chehab1-0/+442
This driver has very long directories without a good reason (IMHO). Let's drop two directories from such hierarchy, in order to simplify things a little bit and make the dir output a bit more readable. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>