- Jul 18, 2020
-
-
Andy Shevchenko authored
Add few blank lines to make platform data more readable. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andy Shevchenko authored
Refactor code to avoid use of atomisp_dev global variable where it's easy to achieve. Signed-off-by:
-
Andy Shevchenko authored
We have special helpers to access MMIO. Use them. Signed-off-by:
-
Andy Shevchenko authored
Unify pdev to be pointer to struct pci_device. While here, reindent some (touched) lines for better readability. Signed-off-by:
-
Andy Shevchenko authored
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 authored
There is no need to pass a pointer to struct device_driver when we have an access to struct device already. Signed-off-by:
-
Andy Shevchenko authored
There are specific ACPI and I\xB2C APIs to match device by different parameters, such as ACPI HID, and retrieve an I\xB2C client. Use them instead of home grown approach. Note, it fixes a resource leak as well. Signed-off-by:
-
Andy Shevchenko authored
IOSF MBI header contains a lot of definitions, such as end point addresses of IPs. Move CCK address from AtomISP driver to generic header. While here, drop unused one. Signed-off-by:
-
Andy Shevchenko authored
Intel MID special header is not in use in this driver. Replace it with a better macro for now on. Signed-off-by:
-
Mauro Carvalho Chehab authored
Instead of parsing GPIO for two exceptions inside the logic which would be trying to use the GPIO, move the init code to the routine which adds a new gmin device. Move the notes to it too, as this helps to identify where those two GPIO settings are used, explaining why they're defaulting to -1 when not found. Tested-by:
-
Mauro Carvalho Chehab authored
There's only one place where a subdev can be added: when the sensor driver registers it. Trying to do it elsewhere will cause problems, as the detection code needs to access the I2C bus in order to probe some things. Tested-by:
-
Mauro Carvalho Chehab authored
If the ACPI DSDT tables provide _CRS for the camera, the GPIO core code should be able to handle them automatically. Tested-by:
-
Mauro Carvalho Chehab authored
The media core has now a check if fi->pad is bigger than zero or bigger than sd->entity.num_pads, if the media controller is defined. This causes a call to g_frame_interval to return -EINVAL. Fix it by first cleaning up the struct. Tested-by:
-
Mauro Carvalho Chehab authored
Newer devices don't place the PMIC CLK line inside an EFI var. Instead, those are found at the _PR0 table. Add a parser for it, using info stored via the DSDT table. Tested-by:
-
Mauro Carvalho Chehab authored
Add support code for this driver to use ACPI power management. Yet, at least with known devices, this won't work without further changes. The rationale is that the ACPI handling code checks for the _PR? tables in order to know what is required to switch the device from power state D0 (_PR0) up to D3COLD (_PR3). The adev->flags.power_manageable is set to true if the device has a _PR0 table, which can be checked by calling acpi_device_power_manageable(adev). However, this only says that the device can be set to power off mode. At least on the DSDT tables we've seen so far, there's no _PR3 nor _PS3 (which would have a somewhat similar effect). So, using ACPI for power management won't work, except if adding an ACPI override logic somewhere. Tested-by:
-
Mauro Carvalho Chehab authored
The gmin_subdev_add() currently doesn't use ACPI device power management. In order to prepare for adding support for it, let's shift some things, placing the PM-related stuff at the end of the probing logic. Let's also store the current gs on a temporary var, in order to simplify the source code. Tested-by:
-
- Jul 17, 2020
-
-
Mauro Carvalho Chehab authored
Right now, the driver is not doing the right thing to detect the clock like used by the sensor, at least on devices without the gmin's EFI vars. Add some notes at the code to explain why and skip the wrong value provided by the _DSM table. Signed-off-by:
-
- Jun 12, 2020
-
-
Jonas Karlman authored
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 0b0393d5 ("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: cd33c830 ("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:
-
Jonas Karlman authored
Wrong loop filter flag is unset when tiles enabled flag is not set, this cause HEVC decoding issues with Rockchip Video Decoder. Fix this by unsetting the loop filter across tiles enabled flag instead of the pps loop filter across slices enabled flag when tiles are disabled. Fixes: 256fa392 ("media: v4l: Add definitions for HEVC stateless decoding") Signed-off-by:
-
Tomi Valkeinen authored
Commit 9495b7e9 ("driver core: platform: Initialize dma_parms for platform devices") in v5.7-rc5 causes vb2_dma_contig_clear_max_seg_size() to kfree memory that was not allocated by vb2_dma_contig_set_max_seg_size(). The assumption in vb2_dma_contig_set_max_seg_size() seems to be that dev->dma_parms is always NULL when the driver is probed, and the case where dev->dma_parms has bee initialized by someone else than the driver (by calling vb2_dma_contig_set_max_seg_size) will cause a failure. All the current users of these functions are platform devices, which now always have dma_parms set by the driver core. To fix the issue for v5.7, make vb2_dma_contig_set_max_seg_size() return an error if dma_parms is NULL to be on the safe side, and remove the kfree code from vb2_dma_contig_clear_max_seg_size(). For v5.8 we should remove the two functions and move the dma_set_max_seg_size() calls into the drivers. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Fixes: 9495b7e9 ("driver core: platform: Initialize dma_parms for platform devices") Cc: stable@vger.kernel.org Acked-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Michael Rodin authored
Remove description of non-existing v4l2_subdev.nevents and replace the undefined flag V4L2_SUBDEV_USES_EVENTS by the correct flag V4L2_SUBDEV_FL_HAS_EVENTS, which is already documented in v4l2_subdev.flags Fixes: commit 02adb1cc ("[media] v4l: subdev: Events support") Signed-off-by:
Michael Rodin <mrodin@de.adit-jv.com> Signed-off-by:
-
Marek Szyprowski authored
Commit 9495b7e9 ("driver core: platform: Initialize dma_parms for platform devices") in v5.7-rc5 added allocation of dma_parms structure to all platform devices. Then vb2_dma_contig_set_max_seg_size() have been changed not to allocate dma_parms structure and rely on the one allocated by the device core. Lets allocate the needed structure also for the devices created for the 2 MFC device memory ports. Reported-by:
-
Geert Uytterhoeven authored
Recently, MEDIA_CEC_SUPPORT became indepedent of MEDIA_SUPPORT. However, if MEDIA_SUPPORT is not enabled, MEDIA_SUPPORT_FILTER is not defined, and MEDIA_CEC_SUPPORT is thus enabled by default, which is not desirable. Fix this by adding a dependency on MEDIA_CEC_SUPPORT to the default configuration. Fixes: 46d2a3b9 ("media: place CEC menu before MEDIA_SUPPORT") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Jernej Skrabec authored
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:
-
Samuel Holland authored
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: 50e76151 ("media: platform: Add Cedrus VPU decoder driver") Suggested-by:Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
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 authored
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 0a76fd8e . Signed-off-by:
-
Mauro Carvalho Chehab authored
This reverts commit 0d64e942. 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 c03496b3 ("media: atomisp: add a notice about possible leak resources") Signed-off-by:
-
Mauro Carvalho Chehab authored
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 authored
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 authored
Some parts of the driver have their own implementation of memcpy() & friends. Replace all of them by strscpy(). Signed-off-by: -
Mauro Carvalho Chehab authored
Replace usages of strcpy(), strlcpy() and strncpy() in favor of strscpy(). Suggested-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Mauro Carvalho Chehab authored
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 authored
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 authored
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 authored
Instead of hardcoding the intel family values there, use the already defined ones from asm/intel-family.h. Signed-off-by: -
Mauro Carvalho Chehab authored
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 authored
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 authored
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 authored
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:
-
