- 15 Apr, 2023 40 commits
-
-
Hans de Goede authored
The gc0310 uses 8 bit register addresses which makes it compatible with the standard smbus access functions. Drop the custom reg access helpers, replacing them with the smbus access functions. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Hans de Goede authored
enum gc0310_tok_type / the data_length read/write parameter is always GC0310_8BIT, drop this. Note for the register-lists the indentation is also fixed and c++ style comments are converted to regular C-style /* */ comments. Reviewed-by:
-
Hans de Goede authored
Remove the complex optimization to send multiple registers in one i2c-transfer. None of the other sensor drivers are doing this and the reg-lists are only used once at stream-start time, so this does not need to be highly optimized. Reviewed-by:
-
Hans de Goede authored
Remove the ability to have special tokens in a reg-list, GC0310_TOK_DELAY is not used and GC0310_TOK_TERM can be replaced with ARRAY_SIZE, simplifying the code. Reviewed-by:
-
Hans de Goede authored
Drop the unused struct gc0310_format and struct regval_list definitions. Reviewed-by:
-
Hans de Goede authored
Fix 3 error handling issues: 1. In ov2680_s_stream(), when pm_runtime_get_sync() fails it will still have incremented the pm-runtime reference count so we need to call pm_runtime_put() 2. In ov2680_s_stream() sensor->is_streaming should always be set to false when the sensor is powered-off even on i2c-communication errors. 3. In ov2680_probe(), call ov2680_remove() on ov2680_s_config() errors, so that pm_runtime_disable() is properly called to disable the runtime-pm which has been enabled before the ov2680_s_config() call. Reviewed-by:
-
Hans de Goede authored
Use the new v4l2_get_acpi_sensor_info() for the GPIO lookups, this uses the special Intel _DSM method to get more info about the GPIOs like their function and their polarity. Reviewed-by:
-
Hans de Goede authored
ACPI nodes describing sensors on atomisp devices implement a "79234640-9e10-4fea-a5c1-b5aa8b19756f" Device Specific Method (DSM) to get info about the GPIOs. Using this method is necessary to figure out which ACPI GPIO resource is "reset" and which one is "powerdown" and this is also necessary to figure out the correct polarity of the pins. One example where this is necessary is the GC0310 sensor. The current GC0310 code hardcodes reset as being active-low and power-down as being active-high. This works on a number of devices such as the mpman converter 9. But it is wrong for the Chuwi Vi8 CWI501 where the powerdown pin is active-low. Rather then adding DMI quirks for this, add a helper for this, which can be shared between sensor-drivers. This new helper optionally also returns a string identifying the exact sensor-module used, which might be useful if any module specific behvior is necessary in the sensor driver. This uses the DSM directly on the sensor device's ACPI node. This is different from later Intel hardware (IPU3 / IPU6) which has a separate INT3472 node (with its own driver) with this info. Since there is no separate ACPI node to which we can bind to register GPIO lookups, this unfortunately means that all sensor drivers which may be used on BYT or CHT hw need to call this new helper. Note for now this function is being added to atomisp_gmin_platform.c, but once things are ready to move atomisp over to using generic sensor drivers this will need to become a generic v4l2 sensor helper. but this will require upstream discussion first. Reviewed-by:
-
Tsuchiya Yuto authored
(patch based on intel-aero kernel patch: https://github.com/intel-aero/meta-intel-aero-base/commit/26fc9fe5030b63bc9dcf0b5f32981948911ca272) Here is the original commit message from the aforementioned patch: From 26fc9fe5030b63bc9dcf0b5f32981948911ca272 Mon Sep 17 00:00:00 2001 From: Lucas De Marchi <lucas.demarchi@intel.com> Date: Fri, 7 Jul 2017 14:23:53 -0700 Subject: [PATCH] linux-yocto: Remove remaining instance of call to trace_printk It's not sufficient to leave trace_printk() out of "normal call chains" since the way trace infrastructure works is that it will allocate the trace_printk buffers if the symbol is there (by using a separate section for the function and checking if __start_* and __stop_* symbols are different. Therefore, even if the default value for the param tells the module to use printk(), just the fact that it can be changed to trace_printk() means the initialization code will be called. The trace_printk() was replaced by pr_info() on commit 3d81099c ("media: atomisp: Replace trace_printk by pr_info") for the upstreamed atomisp, too. However, as the aforementioned commit message says, there is still a remaining instance. This causes the "trace_printk() being used" kernel warning message to still appear on the first driver load. Based on the aforementioned patch, this patch removes the call to ftrace_vprintk(). This removes that kernel warning. In addition to this, this patch also removes the following now unused things: - now empty atomisp_css2_dbg_ftrace_print() - trace_printk option from dbg_func kernel parameter Link: https://lore.kernel.org/r/20211017161958.44351-15-kitakar@gmail.comSigned-off-by:
Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by:
-
Hans de Goede authored
online_process is always true, remove it. Link: https://lore.kernel.org/r/20230221145906.8113-11-hdegoede@redhat.comReviewed-by:
Andy Shevchenko <andy@kernel.org> Signed-off-by:
-
Hans de Goede authored
yuvpp_mode is never set, so it always is false remove it. Link: https://lore.kernel.org/r/20230221145906.8113-10-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
ATOMISP_USE_YUVPP() always returns false, so remove it and remove any code-paths which only run when it would return true. Link: https://lore.kernel.org/r/20230221145906.8113-9-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Nothing registers subdevs with the SOC_CAMERA, XENON_FLASH and FILE_INPUT types, remove the code for these. Link: https://lore.kernel.org/r/20230221145906.8113-8-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
atomisp_get_metadata_type() always returns ATOMISP_MAIN_METADATA, replace its uses with ATOMISP_MAIN_METADATA and remove it. Link: https://lore.kernel.org/r/20230221145906.8113-7-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Remove the now unused atomisp_css_enable_raw_binning() function. Link: https://lore.kernel.org/r/20230221145906.8113-6-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Remove the crop_needs_override local helper variable from atomisp_set_fmt(), as it always is true now. Link: https://lore.kernel.org/r/20230221145906.8113-5-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
After the continues-mode removal the delayed-work never gets queues remove all the related code. Link: https://lore.kernel.org/r/20230221145906.8113-4-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Continues mode is a special mode where 2 /dev/video devices can be active at the same time. Either the video-preview + video nodes or the viewfinder (for still capture) + capture nodes. For the video-preview + video-recording case modern userspace will use a single stream multiplexed by pipewire. The still-capture case is extra special only starting the preview stream and then relying on a custom ATOMISP_IOC_S_CONT_CAPTURE_CONFIG ioctl to set things up followed by a second stream on to capture the amount of configured still pictures. While running the sensor at full resolution all the time. This case too is better handled with dma-buf + GPU downscaling for the view-finder rather then all this custom special code. Besises this the ioctl expects a bunch of special non error checked conditions to be met otherwise things will crash/hang. The continues mode also involves a special cases all over the code getting in the way of further cleanups and simplifying the code to using just 1 /dev/video# node. So lets remove it and the related custom ATOMISP_IOC_S_CONT_CAPTURE_CONFIG ioctl. Link: https://lore.kernel.org/linux-media/ea81b17b-7d1f-a5e1-11dd-04db310e1e50@redhat.com/ Link: https://lore.kernel.org/r/20230221145906.8113-3-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Remove support for depth mode. This is a special mode where 2 streams (from 2 different sensors) can be setup and then starting/stopping 1 will automatically also start/stop the other. Like many of these special features I'm pretty sure that if the queue setup is not done exactly right things will crash and there is no error checking for this. This seems to be for stereoscopic vision and the only known hw which actually supports this is the Intel Aero board/SDK, all other 1000+ BYT/CHT models don't need this. This false outside of the standard webcam use scenario which we are trying to get working and this involves a bunch of hacks / special exceptions all over the code, so lets remove this. Link: https://lore.kernel.org/linux-media/ea81b17b-7d1f-a5e1-11dd-04db310e1e50@redhat.com/ Link: https://lore.kernel.org/r/20230221145906.8113-2-hdegoede@redhat.comReviewed-by:
-
Laurent Pinchart authored
The vs6624 camera sensor driver doesn't support DT and relies on platform data. The last board files supplying platform data for that device have been removed from the kernel in v4.17. The driver hasn't been used since them. Drop it. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Laurent Pinchart authored
The sr030pc30 camera sensor driver doesn't support DT and relies on platform data. No board file has ever provided platform data for that device. The driver has thus never been used in the mainline kernel since its introduction in v2.6.37. Drop it. Signed-off-by:
-
Laurent Pinchart authored
The s5k6aa camera sensor driver doesn't support DT and relies on platform data. The last board files supplying platform data for that device have been removed from the kernel in v3.11. The driver hasn't been used since them. Drop it. Signed-off-by:
-
Laurent Pinchart authored
The noon010pc30 camera sensor driver doesn't support DT and relies on platform data. The last board files supplying platform data for that device have been removed from the kernel in v3.16. A device tree file referencing the device has been added in v3.17, but without corresponding DT bindings, and with DT support in the driver. The driver thus hasn't been used since v316. Drop it. Signed-off-by:
-
Laurent Pinchart authored
The mt9t001 camera sensor driver doesn't support DT and relies on platform data. No board file has ever provided platform data for that device. The driver has thus never been used in the mainline kernel since its introduction in v3.2. Drop it. Signed-off-by:
-
Laurent Pinchart authored
The mt9m032 camera sensor driver doesn't support DT and relies on platform data. No board file has ever provided platform data for that device. The driver has thus never been used in the mainline kernel since its introduction in v3.4. Drop it. Signed-off-by:
-
Laurent Pinchart authored
The m5mols camera sensor driver doesn't support DT and relies on platform data. The last board files supplying platform data for that device have been removed from the kernel in v3.11. The driver hasn't been used since them. Drop it. Signed-off-by:
-
Laurent Pinchart authored
The ad9389b video encoder driver doesn't support DT and relies on platform data. No board file has ever provided platform data for that device. The driver has thus never been used in the mainline kernel since its introduction in v3.7. Drop it. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by:
-
Ming Qian authored
enable encoding 12-bit extended jpeg Signed-off-by:
Ming Qian <ming.qian@nxp.com> Signed-off-by:
-
Ming Qian authored
enable decoding 12-bit extended jpeg Signed-off-by:
-
Ming Qian authored
clear slot next desc ptr if config error, otherwise codec will report config error interrupt repeatedly, it may led to system hang. Signed-off-by:
-
Ming Qian authored
remove the unused parameter ctx Signed-off-by:
-
Ming Qian authored
ABGR64_12 is a reversed RGB format with alpha channel last, 12 bits per component like ABGR32, expanded to 16bits. Data in the 12 high bits, zeros in the 4 low bits, arranged in little endian order. Signed-off-by:
-
Ming Qian authored
BGR48_12 is a reversed RGB format with 12 bits per component like BGR24, expanded to 16bits. Data in the 12 high bits, zeros in the 4 low bits, arranged in little endian order. Signed-off-by:
-
Ming Qian authored
YUV48_12 is a YUV format with 12-bits per component like YUV24, expanded to 16bits. Data in the 12 high bits, zeros in the 4 low bits, arranged in little endian order. [hverkuil: replaced a . by ,] Signed-off-by:
-
Ming Qian authored
Y212 is a YUV format with 12-bits per component like YUYV, expanded to 16bits. Data in the 12 high bits, zeros in the 4 low bits, arranged in little endian order. Add the missing v4l2 foramt info of Y212 Signed-off-by:
-
Ming Qian authored
Y012 is a luma-only formats with 12-bits per pixel, expanded to 16bits. Data in the 12 high bits, zeros in the 4 low bits, arranged in little endian order. Signed-off-by:
-
Ming Qian authored
P012 is a YUV format with 12-bits per component with interleaved UV, like NV12, expanded to 16 bits. Data in the 12 high bits, zeros in the 4 low bits, arranged in little endian order. And P012M has two non contiguous planes. Signed-off-by:
-
Tomi Valkeinen authored
Add new ioctls to set and get subdev client capabilities. Client in this context means the userspace application which opens the subdev device node. The client capabilities are stored in the file handle of the opened subdev device node, and the client must set the capabilities for each opened subdev. For now we only add a single flag, V4L2_SUBDEV_CLIENT_CAP_STREAMS, which indicates that the client is streams-aware. The reason for needing such a flag is as follows: Many structs passed via ioctls, e.g. struct v4l2_subdev_format, contain reserved fields (usually a single array field). These reserved fields can be used to extend the ioctl. The userspace is required to zero the reserved fields. We recently added a new 'stream' field to many of these structs, and the space for the field was taken from these reserved arrays. The assumption was that these new 'stream' fields are always initialized to zero if the userspace does not use them. This was a mistake, as, as mentioned above, the userspace is required to zero the _reserved_ fields. In other words, there is no requirement to zero this new stream field, and if the userspace doesn't use the field (which is the case for all userspace applications at the moment), the field may contain random data. This shows that the way the reserved fields are defined in v4l2 is, in my opinion, somewhat broken, but there is nothing to do about that. To fix this issue we need a way for the userspace to tell the kernel that the userspace has indeed set the 'stream' field, and it's fine for the kernel to access it. This is achieved with the new ioctl, which the userspace should usually use right after opening the subdev device node. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
-
Hans Verkuil authored
With these changes it now passes the v4l2-compliance test. Signed-off-by:
-
Hans Verkuil authored
V4L2_STD_ALL advertises more standards than these boards actually support. This causes a V4L2 compliance issue. Limit the supported standards to those that are actually implemented. Signed-off-by:
-
