summaryrefslogtreecommitdiff
path: root/drivers/staging/media/atomisp/include/linux
AgeCommit message (Collapse)AuthorFilesLines
2024-04-26media: atomisp: Remove struct atomisp_platform_dataHans de Goede1-5/+1
struct atomisp_platform_data only has a single subdevs member. Remove this struct and replace atomisp_get_platform_data() with atomisp_platform_get_subdevs(). Note atomisp_get_platform_data() and now atomisp_platform_get_subdevs() always succeed, so while at it also remove unnecessary error checking. 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>
2024-04-26media: atomisp: Remove gmin_platform VCM code.Hans de Goede2-24/+0
VCM support has already been removed from the main atomisp driver in commit 7473c97dd8d0 ("media: atomisp: Remove custom VCM handling") remove the left-over dead VCM handling from the gmin platform code. 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>
2024-04-26media: atomisp: Drop intel_v4l2_subdev_typeHans de Goede2-13/+1
intel_v4l2_subdev_type / atomisp_input_subdev.type now always is RAW_CAMERA, drop it. 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>
2024-04-26media: atomisp: Drop unused frame_status trackingHans de Goede1-15/+0
After removing the flash support frame_status now always is ATOMISP_FRAME_STATUS_OK aka 0. Drop frame_status tracking. This also means one less atomisp custom use for the vb2_buffer->reserved* fields (all custom use of these fields should be removed). While at it also remove the no longer used vf_frame pointer from struct atomisp_sub_device. 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>
2024-04-26media: atomisp: Drop custom flash supportHans de Goede2-43/+0
Remove the custom flash handling from the atomisp driver. There are only few Bay Trail / Cherry Trail devices with flash and if those will ever get supported then this should be done through the new standard include/linux/led-class-flash.h APIs instead of with atomisp specific custom APIs. 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>
2024-04-26media: atomisp: Remove test pattern generator (TPG) supportHans de Goede1-1/+0
The TPG support registers a v4l2-subdev for this, but this is not part of the media-controller graph in any way. After manually selecting the TPG as input using the s_input ioctl it does not work. Several supported sensors have their own working TPG and using the sensor's TPG means that the same data-flow is used as with actual sensors rather then the quite different data-flow from the ISP's builtin TPG. Remove the broken TPG support, when a test-pattern is needed for testing a sensor's TPG can be used. Using a sensor's TPG is actually better for testing since then the actual normal data-flow is being tested. 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>
2024-04-11media: atomisp: Remove ISP controls which get passed through to the cameraHans de Goede1-21/+0
Drop all ISP controls and ioctls which just get passed through to the camera subdev. Instead these calls should be done directly at the sensor subdev. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> 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>
2024-04-11media: atomisp: Remove custom VCM handlingHans de Goede2-6/+2
Remove the custom VCM handling, instead the VCM should be controlled through its own v4l2-subdev and the new ipu-bridge.c code already supports instantiating an i2c_client for this and setting up the necessary endpoints in the fwnode graph. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> 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>
2023-09-27media: atomisp: Remove support for custom run-mode v4l2-ctrl on sensorsHans de Goede1-10/+0
Remove the support to update a V4L2_CID_RUN_MODE run-mode control on sensors when changing the atomisp run-mode or directly by calling the custom ATOMISP_IOC_S_SENSOR_RUNMODE IOCTL. No sensor drivers implement this and having custom controls / IOCTLs is undesirable. Even if there was such a control on sensors then userspace should directly talk to the sensor v4l2-subdev, rather than relying on a custom IOCTLs on the output /dev/video# node to pass this through to the senor. Link: https://lore.kernel.org/r/20230619105212.303653-6-hdegoede@redhat.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-06-09media: atomisp: Remove a bunch of sensor related custom IOCTLsHans de Goede1-120/+0
Remove a bunch of sensor related custom IOCTLs because: 1. They are custom IOCTLs and all custom IOCTLs should be removed 2. Userspace should directly talk to the sensor v4l2-subdev, rather then relying on ioctl-s on the output /dev/video# node to pass through ioctl-s to the senor 3. Some of these rely on the atomisp specific camera_mipi_info struct which is going away as we are switching to using standard v4l2 sensor drivers 4. In the case of ATOMISP_IOC_S_EXPOSURE_WINDOW this was using the v4l2-subdev set_selection API in an undocumented atomisp custom way Link: https://lore.kernel.org/r/20230529103741.11904-8-hdegoede@redhat.com Signed-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>
2023-06-09media: atomisp: Store number of sensor lanes per port in struct atomisp_deviceHans de Goede1-0/+1
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.com 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>
2023-06-09media: atomisp: Remove Continuous capture and SDV run-modesHans de Goede1-4/+3
Since we no longer support Continuous mode, setting the run_mode to ATOMISP_RUN_MODE_CONTINUOUS_CAPTURE no longer make sense, so remove this. While at it, also remove ATOMISP_RUN_MODE_SDV, which was never exposed to userspace in the first place. 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>
2023-04-15media: atomisp: Remove custom V4L2_CID_FMT_AUTO controlHans de Goede1-2/+0
The custom V4L2_CID_FMT_AUTO control, which defaults to true controls whether the atomisp driver will automatically configure the sensor and ISP settings to match. This is necessary to make normal v4l2 apps to work. We do eventually want to add libcamera support, but even then moving this to userspace does not give any added value, while breaking classic v4l2 apps. Moreover we really don't know all the exact pipeline constraints, so moving this to userspace/libcamera will be tricky thus it is best to keep the current in kernel code for this and make the kernel unconditionally do this. 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>
2023-04-15media: atomisp: Add v4l2_get_acpi_sensor_info() helperHans de Goede1-0/+2
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: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-04-15media: atomisp: Remove unused SOC_CAMERA, XENON_FLASH and FILE_INPUT subdev ↵Hans de Goede1-6/+3
types 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.com 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>
2023-04-15media: atomisp: Remove delayed_init related codeHans de Goede1-1/+0
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.com 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>
2023-04-15media: atomisp: Remove continuous mode supportHans de Goede1-23/+0
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.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-04-15media: atomisp: Remove depth-mode supportHans de Goede1-2/+0
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.com 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>
2023-02-08media: atomisp: Add atomisp_register_sensor_no_gmin() helperHans de Goede1-0/+4
The DSDT of all Windows BYT / CHT devices which I have seen has proper ACPI powermagement for the clk and regulators used by the sensors. So there is no need for the whole custom atomisp_gmin custom code to disable the ACPI pm and directly poke at the PMIC for this. Add new atomisp_register_sensor_no_gmin() + atomisp_unregister_subdev() helpers which allow registering a sensor with the atomisp code without using any of the atomisp_gmin power-management code. 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>
2023-02-08media: atomisp: Remove atomisp_gmin_find_subdev()Hans de Goede2-8/+0
atomisp_gmin_find_subdev() can be used to lookup a subdev given its i2c-adapter + i2c-client-address. But the only caller of it reads this from the intel_v4l2_subdev_table struct and that same struct already contains a pointer to the v4l2_subdev. So this function is not necessary, drop it and modify its only caller to directly take the subdev from the intel_v4l2_subdev_table struct. Also drop struct intel_v4l2_subdev_i2c_board_info since that now no longer is used. 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>
2023-02-08media: atomisp: Remove V4L2_CID_BIN_FACTOR_HORZ/_VERTHans de Goede1-4/+0
The bin-factor-x and bin-factor-y ctrls are only used internally to get a single value to pass to atomisp_css_input_set_binning_factor(), which is supposed to tune the lens-shading correction for the binning factor. But all sensor drivers return either 0 or 1 for this, with 0 meaning unset and 1 meaning no-binning. Even though some modes do actually do binning ... Also note that the removed atomisp_get_sensor_bin_factor() would fall back to 0 if either the x and y factor differ or if the ctrls are not implemented (not all sensor drivers implement them). Simply always pass 0 to atomisp_css_input_set_binning_factor(). This is part of a patch-series which tries to remove atomisp specific / custom code from the sensor drivers, with as end goal to make the atomisp drivers regular camera sensor drivers. 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>
2023-02-08media: atomisp: Remove custom ATOMISP_IOC_G_SENSOR_MODE_DATA ioctlHans de Goede2-27/+0
This ioctl returns a number of fixed sensor parameters + a number of mode-specific parameters. With libcamera these fixed parameters are instead stored in a table with sensor-name to parameters mappings (camera_sensor_properties.cpp); and the variable parameters can be derived from the set fmt. So this custom ioctl is not necessary; and it currently has no users. Remove the ioctl and all the sensor drivers xxxx_get_intg_factor() helpers which return this info. This is part of a patch-series which tries to remove atomisp specific / custom code from the sensor drivers, with as end goal to make the atomisp drivers regular camera sensor drivers. 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>
2023-02-08media: atomisp: Remove custom ATOMISP_IOC_ISP_MAKERNOTE ioctlHans de Goede1-20/+0
This ioctl simply returns a couple of fixed sensor parameters. With libcamera these fixed parameters are instead stored in a table with sensor-name to parameters mappings (camera_sensor_properties.cpp), so this custom ioctl is not necessary; and it currently has no users. Remove the ioctl and also remove the custom v4l2-ctrls underpinning the ioctl. This is part of a patch-series which tries to remove atomisp specific / custom code from the sensor drivers, with as end goal to make the atomisp drivers regular camera sensor drivers. 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_gmin_platform: Unexport and split camera_sensor_csi()Andy Shevchenko1-2/+0
The camera_sensor_csi() is not used outside the module, hence make it static. While at it, split it to _alloc() and _free() to clearly show the idea behind the last parameter @flag that is passed to gmin_csi_cfg(). Link: https://lore.kernel.org/r/20220730162027.1011-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-09-24media: atomisp: Remove const/fixed camera_capsHans de Goede1-18/+0
The code checks a camera_caps struct in various places, but this always points to the same const camera_caps struct. Remove the checks, keeping the code paths which would be taken with the fixed camera caps struct still in place and remove the camera_caps struct itself. Note this completely removes atomisp_pause_buffer_event() because that only ever does something if camera_caps.sensors[0].is_slave is true and that never is true. 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 some further ATOMISP_ACC_* related dead codeHans de Goede1-14/+0
Remove some more code which is no longer referenced after the removal of the ATOMISP_ACC_* custom ioctls. 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-07-08media: atomisp: drop unused ATOMISP_MAP_FLAG_* flagsHans de Goede1-3/+0
Drop the ATOMISP_MAP_FLAG_CACHED flag, it is never set anywhere; also drop the matching "cached" parameter to hmm[_bo]_alloc which value was derived form the never set flag. Drop the ATOMISP_MAP_FLAG_NOFLUSH, it is not used anywhere. Link: https://lore.kernel.org/linux-media/20220615205037.16549-27-hdegoede@redhat.com 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>
2022-07-08media: atomisp: drop ATOMISP_MAP_FLAG_CLEAREDHans de Goede1-1/+0
This flag is only used by one hmm_alloc() caller, drop it and make the caller call hmm_set(ptr, 0, size) itself to do the clearing. Link: https://lore.kernel.org/linux-media/20220615205037.16549-26-hdegoede@redhat.com 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>
2022-07-08media: atomisp: drop unused ATOMISP_ACC_FW_LOAD_* definesHans de Goede1-12/+0
Drop the ATOMISP_ACC_FW_LOAD_* defines, these are no longer used anywhere. Link: https://lore.kernel.org/linux-media/20220615205037.16549-25-hdegoede@redhat.com 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>
2022-07-08media: atomisp: remove private acceleration ioctlsHans de Goede1-129/+0
These ioctls allow userspace to load custom programs into the ISP, which: a) Seems dangerous b) Cannot be used by opensource userspace since there is no FOSS code to create such programs b) These seem to be unused even by the Android closed source camera code (they don't show up in a strace of the camera app) So removing these seems be a good idea. Another reason to remove these is that atomisp_acc_map() is the only user of the userptr functionality in hmm_alloc(), so it gets in the way of further cleanups / simplification of the hmm code. Link: https://lore.kernel.org/linux-media/20220615205037.16549-19-hdegoede@redhat.com 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>
2022-07-08media: atomisp: drop ATOMISP_MAP_FLAG_CONTIGUOUSHans de Goede1-2/+1
Drop the ATOMISP_MAP_FLAG_CONTIGUOUS hmm_alloc flag. After the contiguous flag removal done in previous patches in this series it is never set. And hmm_alloc already did a WARN_ON on the flag and otherwise ignored it, proving that contiguous support was already never used. Link: https://lore.kernel.org/linux-media/20220615205037.16549-9-hdegoede@redhat.com 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>
2021-02-15media: atomisp: Remove unused headerAndy Shevchenko1-1/+0
sfi.h is not anyhow used by the driver. Remove it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-18media: atomisp: Replace last use of Intel MID APIsAndy Shevchenko1-0/+1
Intel MID special header is not in use in this driver. Replace it with a better macro for now on. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: change the detection of ISP2401 at runtimeMauro Carvalho Chehab2-4/+10
Instead of having a static var to detect it, let's use the already-existing arch-specific bytes, as this is how other parts of the code also checks when it needs to do something different, depending on an specific chipset version. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: use macros from intel-family.hMauro Carvalho Chehab1-4/+6
Instead of hardcoding the intel family values there, use the already defined ones from asm/intel-family.h. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: add SPDX headersMauro Carvalho Chehab4-0/+4
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: staging: atomisp: There's no struct atomisp_dvs2_coefficientsSakari Ailus1-1/+1
It's called struct atomisp_dis_coefficients. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: do another round of coding style cleanupMauro Carvalho Chehab1-1/+1
Run checkpatch --fix-inline again, in order to get rid of some additional issues that got introduced (or that checkpatch can now detect). This should help preventing receiving random cleanups, while keeping the code on a better shape. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11media: atomisp: go one step further to drop ia_css_memory_access.cMauro Carvalho Chehab1-0/+2
Move the attrs handling into hmm, simplifying even further what the ia_css_memory_access.c file does. Yet, the returned type for ia_css_memory_access.c is an integer, instead of a pointer. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-05-20media: atomisp: better display DMI and EFI found entriesMauro Carvalho Chehab1-2/+4
There are several device-specific data that are obtained either via DMI or EFI, with changes the driver's behavior. Display what has been detected, as such info may help identifying troubles at the driver. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-05-20media: atomisp: add a way for the driver to know the chipset versionMauro Carvalho Chehab1-0/+3
The atomisp supports two different chipsets: ISP2400 and ISP2401. Right now, this is controlled by ugly #defines inside the driver. Add a global bolean to identify the type of hardware. While this is hacky, it would be a quick way to start removing the ugly ifdefs. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-05-20media: atomisp: remove some dead codeMauro Carvalho Chehab1-4/+0
There are several parts of atomisp that are meant to be built on different environments, tested using ifdefs. Remove some of them, as this code should build only on Linux. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-05-20media: atomisp: do lots of other coding style cleanupsMauro Carvalho Chehab4-13/+14
Use some auto-reformat tools to make the atomisp style a little better. There are still lots of weird things there, but this will hopefully reduce the number of pure coding style patches submitted upstream. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-05-20media: atomisp: fix several coding style issuesMauro Carvalho Chehab4-86/+83
Use checkpatch.pl --fix-inplace --strict to solve several coding style issues, manually reviewing the produced code and fixing some troubles caused by checkpatch. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-05-20Revert "media: staging: atomisp: Remove driver"Mauro Carvalho Chehab4-0/+1672
There are some interest on having this driver back, and I can probably dedicate some time to address its issue. So, let's ressurect it. For now, the driver causes a recursive error and doesn't build, so, make it depend on BROKEN. This reverts commit 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2018-05-16media: staging: atomisp: Remove driverSakari Ailus4-1672/+0
The atomisp driver has a long list of todo items and little has been done to address these lately while more has been added. The driver is also not functional. In other words, the driver would not be getting out of staging in the foreseeable future. At the same time it consumes developer resources in order to maintain the flaky code base. Remove it. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-04-04media: staging: atomisp: stop duplicating input format typesMauro Carvalho Chehab1-0/+4
The same formats are defined twice with different names, as warned: drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5092:58: warning: mixing different enum types drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5092:58: int enum atomisp_input_format versus drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5092:58: int enum ia_css_stream_format drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5112:50: warning: mixing different enum types drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5112:50: int enum atomisp_input_format versus drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5112:50: int enum ia_css_stream_format drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5288:42: warning: mixing different enum types drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5288:42: int enum atomisp_input_format versus drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:5288:42: int enum ia_css_stream_format drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62: warning: incorrect type in argument 2 (different address spaces) drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62: expected void const [noderef] <asn:1>*from drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c:6179:62: got unsigned short [usertype] *<noident> Stop this enum abuse. Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2018-03-21media: staging: media: atomisp2: remove unused headersCorentin Labbe1-30/+0
All thoses headers are not used by any source files. Lets just remove them. Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-12-29media: staging: atomisp: Unexport local functionAndy Shevchenko1-1/+0
There is no need to export function which is only used once in the same module where it's defined. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-12-29media: staging: atomisp: Disable custom format for nowAndy Shevchenko1-0/+2
Custom video format 'M101' is not supported in upstream and as a result user will get ugly warning: Unknown pixelformat 0x3130314d ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1574 at drivers/media/v4l2-core/v4l2-ioctl.c:1291 v4l_enum_fmt+0xcf1/0x13a0 [videodev] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>