| Age | Commit message (Collapse) | Author |
|---|
|
There are devices with completely different _DSM() format,
and accessing object as a package leads to crashes.
Bail out in the case of unexpected object type.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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>
|
|
Refactor code to avoid use of atomisp_dev global variable
where it's easy to achieve.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
We have special helpers to access MMIO. Use them.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Unify pdev to be pointer to struct pci_device.
While here, 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>
|
|
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>
|
|
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 <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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 <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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 <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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>
|
|
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
If the ACPI DSDT tables provide _CRS for the camera, the
GPIO core code should be able to handle them automatically.
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
- 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
There's nothing there, just comments.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
