summaryrefslogtreecommitdiffstats
path: root/drivers/staging
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'kbuild-v5.8-2' of ↵Linus Torvalds2020-06-137-32/+32
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull more Kbuild updates from Masahiro Yamada: - fix build rules in binderfs sample - fix build errors when Kbuild recurses to the top Makefile - covert '---help---' in Kconfig to 'help' * tag 'kbuild-v5.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: treewide: replace '---help---' in Kconfig files with 'help' kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables samples: binderfs: really compile this sample and fix build issues
| * treewide: replace '---help---' in Kconfig files with 'help'Masahiro Yamada2020-06-147-32/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* | Merge tag 'media/v5.8-2' of ↵Linus Torvalds2020-06-13674-6780/+5133
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull more media updates from Mauro Carvalho Chehab: - a set of atomisp patches. They remove several abstraction layers, and fixes clang and gcc warnings (that were hidden via some macros that were disabling 4 or 5 types of warnings there). There are also some important fixes and sensor auto-detection on newer BIOSes via ACPI _DCM tables. - some fixes * tag 'media/v5.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (95 commits) media: rkvdec: Fix H264 scaling list order media: v4l2-ctrls: Unset correct HEVC loop filter flag media: videobuf2-dma-contig: fix bad kfree in vb2_dma_contig_clear_max_seg_size media: v4l2-subdev.rst: correct information about v4l2 events media: s5p-mfc: Properly handle dma_parms for the allocated devices media: medium: cec: Make MEDIA_CEC_SUPPORT default to n if !MEDIA_SUPPORT media: cedrus: Implement runtime PM media: cedrus: Program output format during each run media: atomisp: improve ACPI/DMI detection logs media: Revert "media: atomisp: add Asus Transform T101HA ACPI vars" media: Revert "media: atomisp: Add some ACPI detection info" media: atomisp: improve sensor detection code to use _DSM table media: atomisp: get rid of an iomem abstraction layer media: atomisp: get rid of a string_support.h abstraction layer media: atomisp: use strscpy() instead of less secure variants media: atomisp: set DFS to MAX if sensor doesn't report fps media: atomisp: use different dfs failed messages media: atomisp: change the detection of ISP2401 at runtime media: atomisp: use macros from intel-family.h media: atomisp: don't set hpll_freq twice with different values ...
| * media: rkvdec: Fix H264 scaling list orderJonas Karlman2020-06-111-48/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Rockchip Video Decoder driver is expecting that the values in a scaling list are in zig-zag order and applies the inverse scanning process to get the values in matrix order. Commit 0b0393d59eb4 ("media: uapi: h264: clarify expected scaling_list_4x4/8x8 order") clarified that the values in the scaling list should already be in matrix order. Fix this by removing the reordering and change to use two memcpy. Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> [hverkuil-cisco@xs4all.nl: rkvdec_scaling_matrix -> rkvdec_h264_scaling_list] Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: cedrus: Implement runtime PMJernej Skrabec2020-06-114-45/+104
| | | | | | | | | | | | | | | | | | | | | | This allows the VE clocks and PLL_VE to be disabled most of the time. A runtime PM reference is held while streaming. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: cedrus: Program output format during each runSamuel Holland2020-06-112-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the output format was programmed as part of the ioctl() handler. However, this has two problems: 1) If there are multiple active streams with different output formats, the hardware will use whichever format was set last for both streams. Similarly, an ioctl() done in an inactive context will wrongly affect other active contexts. 2) The registers are written while the device is not actively streaming. To enable runtime PM tied to the streaming state, all hardware access needs to be moved inside cedrus_device_run(). The call to cedrus_dst_format_set() is now placed just before the codec-specific callback that programs the hardware. Cc: <stable@vger.kernel.org> Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Suggested-by: Jernej Skrabec <jernej.skrabec@siol.net> Suggested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Tested-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: improve ACPI/DMI detection logsMauro Carvalho Chehab2020-06-111-6/+12
| | | | | | | | | | | | | | | | As there are several ways where the driver could possible retrieve sensor data, make the prints clearer about what was detected and from where. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: Revert "media: atomisp: add Asus Transform T101HA ACPI vars"Mauro Carvalho Chehab2020-06-111-16/+0
| | | | | | | | | | | | | | | | | | Now that the EFI _DSM table is parsed by the driver, we don't need a DMI match anymore for Asus Transform T101HA. This reverts commit 0a76fd8e8d202dcaabc714850205d5d75c9b8271. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: Revert "media: atomisp: Add some ACPI detection info"Mauro Carvalho Chehab2020-06-117-77/+0
| | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 0d64e9420583cbc3c4a3f949ebe38fd8f7769281. As gmin_subdev_add() now takes the ACPI handle directly, we can deprecate the code that were doing this inside each I2C driver. PS.: This also reverts commit c03496b3bd92 ("media: atomisp: add a notice about possible leak resources") Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: improve sensor detection code to use _DSM tableMauro Carvalho Chehab2020-06-112-47/+101
| | | | | | | | | | | | | | | | | | | | | | | | Instead of keep hardcoding device-specific tables, read them directly from the ACPI BIOS, if available. This method is know to work with Asus T101HA device. the same table is also visible on EzPad devices. So, it seems that at least some BIOSes use this method to pass data about ISP2401-connected sensors. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: get rid of an iomem abstraction layerMauro Carvalho Chehab2020-06-1118-192/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * media: atomisp: get rid of a string_support.h abstraction layerMauro Carvalho Chehab2020-06-118-215/+38
| | | | | | | | | | | | | | Some parts of the driver have their own implementation of memcpy() & friends. Replace all of them by strscpy(). Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: use strscpy() instead of less secure variantsMauro Carvalho Chehab2020-06-118-16/+15
| | | | | | | | | | | | | | | | Replace usages of strcpy(), strlcpy() and strncpy() in favor of strscpy(). Suggested-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: set DFS to MAX if sensor doesn't report fpsMauro Carvalho Chehab2020-06-111-2/+6
| | | | | | | | | | | | | | | | | | | | If the sensor doesn't implement support for g_frame_interval, it won't return the expected fps rate. Instead of keeping DFS on its minimal value (which will likely not work), set it to the max. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: use different dfs failed messagesMauro Carvalho Chehab2020-06-112-5/+5
| | | | | | | | | | | | | | | | There are several parts of the driver that could produce a "dfs failed!" message. Change the texts, in order to help identifying from where they're coming. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: change the detection of ISP2401 at runtimeMauro Carvalho Chehab2020-06-1117-114/+108
| | | | | | | | | | | | | | | | | | 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>
| * media: atomisp: use macros from intel-family.hMauro Carvalho Chehab2020-06-111-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>
| * media: atomisp: don't set hpll_freq twice with different valuesMauro Carvalho Chehab2020-06-111-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic which sets the hpll_freq for BYT sets hpll_freq to 1600MHz, but ignores it, and sets it again after reading from-device-specific EFI vars (this time, using a default of 2000MHz). Remove the first set, as this will be overriden anyway. While here, do minor adjustments on comments and on a printk message. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: get rid of a detection hack for a BYT Andorid-based tabletMauro Carvalho Chehab2020-06-111-65/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a hack at the driver that selects a different table for a BYT tablet, which sets the maximum frequency to 320 MHz, instead of 400 MHz. After looking at the Intel Aero Yocto's version from: https://download.01.org/aero/deb/pool/main/l/linux-4.4.76-aero-1.3/ It was noticed that this depends on an Android-specific modprobe parameter, which uses a macro (INTEL_MID_BOARD) from this file: arch/x86/include/asm/spid.h >From the comments there, it looks like this macro parses a variable passed at boot time: cmdline : androidboot.spid=vend:cust:manu:plat:prod:hard The devices in question are identified there as: INTEL_BYT_TABLET_BLK_PRO = 0x0000 INTEL_BYT_TABLET_BLK_ENG = 0x8000 Well, this is something that we don't have upstream. So, without further details about that, we can't really parse it. If we ever end supporting those devices with the upstream driver, this patch can be reverted and the device can be detected via DMI (or maybe via PCI ID?). Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: use just one mamoiada_params.hMauro Carvalho Chehab2020-06-113-216/+1
| | | | | | | | | | | | | | As both isp2400 and isp2401 files are identical, remove one of them and remove the test for ISP variant. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: remove some unused defines from *mamoiada_params.hMauro Carvalho Chehab2020-06-112-38/+2
| | | | | | | | | | | | | | | | | | There are some parameters that are different between isp2400 and isp2401. None of those are actually used. So, get rid of them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: simplify IRQ ifdef logicMauro Carvalho Chehab2020-06-119-120/+2
| | | | | | | | | | | | | | | | | | There are lots of mess with IRQ ifdef settings. As the *_global.h will already detect the type of IRQ system at compile time, we can get rid of them, replacing by just one ifdef for ISP2401. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: get rid of ifdef nonsenseMauro Carvalho Chehab2020-06-111-8/+8
| | | | | | | | | | | | | | There are some ifdefs there that end doing the same thing. Get rid of them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: get rid of a duplicated fileMauro Carvalho Chehab2020-06-113-78/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The contents of hive_isp_css_2401_irq_types_hrt.h and hive_isp_css_common/irq_global.h are identical, except for one unused enum: On isp2401, this IRQ line has this name: hrt_isp_css_irq_is2401 = HIVE_GP_DEV_IRQ_ISP_PMEM_ERROR_BIT_ID, While the same bit is named as: hrt_isp_css_irq_isp_pmem_error = HIVE_GP_DEV_IRQ_ISP_PMEM_ERROR_BIT_ID, At the isp2400 version. Remove one of them, in order to reduce the code differences between those two versions. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: do some cleanup at irq_local.hMauro Carvalho Chehab2020-06-115-44/+30
| | | | | | | | | | | | | | | | | | - Get rid of typedefs; - Get rid of a duplicated enum type with different names for ISP2400 and ISP2401; - adjust indentation on the touched code. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: improve IRQ handling debug messagesMauro Carvalho Chehab2020-06-111-5/+6
| | | | | | | | | | | | | | When an IRQ is not handled, it is nice to know what's the reason. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: comment an unused codeMauro Carvalho Chehab2020-06-111-0/+8
| | | | | | | | | | | | | | | | | | | | There's a different table for some BYT variants that depend on something inside a FIXME ifdef. Place this also inside it, just to shut up a clang-11 warning. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: get rid of a left-over wrapper functionMauro Carvalho Chehab2020-06-111-8/+0
| | | | | | | | | | | | | | | | The abstraction layer for kvfree() was removed, but there is still a left-over code there. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: get rid of an unused IRQ duplicated eventMauro Carvalho Chehab2020-06-111-4/+1
| | | | | | | | | | | | | | There are two names for the same IRQ, but just one is used. Remove the unused one. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: get rid of sh_css_pipe.cMauro Carvalho Chehab2020-06-112-18/+0
| | | | | | | | | | | | There's nothing there, just comments. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: staging: media: atomisp: fix stack overflow in init_pipe_defaults()Arnd Bergmann2020-06-119-42/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building with clang, multiple copies of the structures to be initialized are passed around on the stack and copied locally, using an insane amount of stack space: drivers/staging/media/atomisp/pci/sh_css.c:2371:1: error: stack frame size of 26864 bytes in function 'create_pipe' [-Werror,-Wframe-larger-than=] Use constantly-allocated variables plus an explicit memcpy() to avoid that. Co-authored-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Fixes: 6dc9a2568f84 ("media: atomisp: convert default struct values to use compound-literals with designated initializers") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: re-enable warnings againMauro Carvalho Chehab2020-06-117-30/+30
| | | | | | | | | | | | | | | | | | For most warnings, the current code is OK. There are still some issues with implicit-fallthough warnings. Solve those and re-enable all warnings for this driver. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: remove format duplication at mbus->fourcc tableMauro Carvalho Chehab2020-06-113-26/+25
| | | | | | | | | | | | | | | | | | | | | | | | This table used to be used also to translate between ia_css abstraction and V4L2 fourcc codes. This was removed on a past patch, but the table now contains two fields with identical values. Get rid of one of them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: staging: media: atomisp: add PMIC_OPREGION dependencyArnd Bergmann2020-06-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Without that driver, there is a link failure in ERROR: modpost: "intel_soc_pmic_exec_mipi_pmic_seq_element" [drivers/staging/media/atomisp/pci/atomisp_gmin_platform.ko] undefined! Add an explicit Kconfig dependency. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: staging: media: atomisp: disable all custom formatsArnd Bergmann2020-06-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clang points out the usage of an incorrect enum type in the list of supported image formats: drivers/staging/media/atomisp/pci/atomisp_subdev.c:49:65: error: implicit conversion from enumeration type 'enum ia_css_frame_format' to different enumeration type 'enum atomisp_input_format' [-Werror,-Wenum-conversion] { V4L2_MBUS_FMT_CUSTOM_NV21, 12, 12, CSS_FRAME_FORMAT_NV21, 0, CSS_FRAME_FORMAT_NV21 }, drivers/staging/media/atomisp/pci/atomisp_subdev.c:49:39: error: implicit conversion from enumeration type 'enum ia_css_frame_format' to different enumeration type 'enum atomisp_input_format' [-Werror,-Wenum-conversion] { V4L2_MBUS_FMT_CUSTOM_NV21, 12, 12, CSS_FRAME_FORMAT_NV21, 0, CSS_FRAME_FORMAT_NV21 }, { V4L2_MBUS_FMT_CUSTOM_NV12, 12, 12, CSS_FRAME_FORMAT_NV12, 0, CSS_FRAME_FORMAT_NV12 }, { MEDIA_BUS_FMT_JPEG_1X8, 8, 8, CSS_FRAME_FORMAT_BINARY_8, 0, ATOMISP_INPUT_FORMAT_BINARY_8 }, Checking the git history, I found a commit that disabled one such case because it did not work. It seems likely that the incorrect enum was part of the original problem and that the others do not work either, or have never been tested. Disable all the ones that cause a warning. Fixes: cb02ae3d71ea ("media: staging: atomisp: Disable custom format for now") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: staging: media: atomisp: fix enum type mixupsArnd Bergmann2020-06-111-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some function calls pass an incorrect enum type: drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:858:16: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion] gp_device_rst(INPUT_SYSTEM0_ID); ~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~ drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:860:19: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion] input_switch_rst(INPUT_SYSTEM0_ID); ~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~ drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:876:27: error: implicit conversion from enumeration type 'input_system_cfg_flag_t' to different enumeration type 'input_system_connection_t' [-Werror,-Wenum-conversion] config.multicast[i] = INPUT_SYSTEM_CFG_FLAG_RESET; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:1326:32: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion] input_selector_cfg_for_sensor(INPUT_SYSTEM0_ID); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~ drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:1329:19: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion] input_switch_cfg(INPUT_SYSTEM0_ID, &config.input_switch_cfg); ~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~ INPUT_SYSTEM0_ID is zero, so use the corresponding zero-value of the expected types instead. Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: staging: media: atomisp: declare 'struct device' before using itArnd Bergmann2020-06-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In some configurations, including this header leads to a warning: drivers/staging/media/atomisp//pci/sh_css_firmware.h:41:38: error: declaration of 'struct device' will not be visible outside of this function [-Werror,-Wvisibility] Make sure the struct tag is known before declaring a function that uses it as an argument. Fixes: 9d4fa1a16b28 ("media: atomisp: cleanup directory hierarchy") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: add SPDX headersMauro Carvalho Chehab2020-06-11657-0/+657
| | | | | | | | | | | | | | | | | | | | | | 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>
| * media: staging: atomisp: Check return value from compat_alloc_user_spaceSakari Ailus2020-06-111-0/+2
| | | | | | | | | | | | | | | | If something gets wrong, return, instead of trying to convert from a NULL pointer. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: staging: atomisp: Fix compat IOCTL handlingSakari Ailus2020-06-111-463/+471
| | | | | | | | | | | | | | | | | | | | | | Atomisp compat IOCTL handling suffers from the same security issue than the V4L2 did. Fix this for atomisp. See more information in patch a1dfb4c48cc1 ("media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: staging: atomisp: Fix atomisp_overlay32 compat handlingSakari Ailus2020-06-111-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The struct atomisp_overlay contains overlay_start_x and overlay_start_y fields. Instead of copying the value of the overlay_start_x field between the two structs, the value of the overlay_start_y field of the compat struct was copied to the overlay_start_x field of the 64-bit kernel struct in get operation and back in put. The overlay_start_x field value was not copied from or to the user space struct. Fix this so that the value of overlay_start_x is copied to overlay_start_x and the value of overlay_start_y is copied to overlay_start_y. Also do copy blend_overlay_perc_u field only once. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: staging: atomisp: There's no struct atomisp_dvs2_coefficientsSakari Ailus2020-06-113-4/+4
| | | | | | | | | | | | | | 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>
| * media: atomisp: add some debug messages when binaries are usedMauro Carvalho Chehab2020-06-111-4/+27
| | | | | | | | | | | | | | | | | | | | | | The ISP firmware logic is complex, as several binaries are contained into a single file. Print debug messages: - with a stack dump if binary not found; - when a firmware is selected. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: add a debug message at hmm freeMauro Carvalho Chehab2020-06-111-0/+2
| | | | | | | | | | | | | | In order to check if aren't there any memory leaks, let's add a debug print for hmm_free(). Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: allow passing firmware name at modprobe timeMauro Carvalho Chehab2020-06-111-13/+21
| | | | | | | | | | | | | | | | It can be useful to be able to test different firmware files at modprobe time, in order to be able to test different variants without much efforts. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: print firmware data during loadMauro Carvalho Chehab2020-06-111-1/+48
| | | | | | | | | | | | | | | | | | | | | | While there's a way to list the firmware binaries in runtime, it is worth to also print it during firmware load. One advantage is that this code also introduces additional checks with regards to invalid firmware types, which can be useful to identify problems. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: provide more details about the firmware binariesMauro Carvalho Chehab2020-06-113-5/+40
| | | | | | | | | | | | | | In order to make easier to identify what a firmware file contains, add more info at the firmware dump log facility. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: get rid of system_types.hMauro Carvalho Chehab2020-06-1128-51/+27
| | | | | | | | | | | | This is just a wrapper for system_local.h. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: get rid of a bunch of other wrappersMauro Carvalho Chehab2020-06-117-462/+95
| | | | | | | | | | | | | | | | There are too many wrapper functions at atomisp_compat_css20.c. Get rid of another set of such wrappers. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
| * media: atomisp: don't cause a warn if probe failedMauro Carvalho Chehab2020-06-111-0/+2
| | | | | | | | | | | | | | | | | | | | When probe fails, it is possible that hmm_init() to not be called. On such case, hmm_cleanup() will cause a WARN_ON(). Avoid it by adding an explicit check at hmm_cleanup() to ensure that the hmm code was properly initialized. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-27 06:37:23 +0000