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: NJernej Skrabec <jernej.skrabec@siol.net>
Suggested-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: NSamuel Holland <samuel@sholland.org>
Tested-by: NJernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: NJernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: NEzequiel Garcia <ezequiel@collabora.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro 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: NMauro 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 0a76fd8e.
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NMauro 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: NMauro 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: NMauro 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: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Replace usages of strcpy(), strlcpy() and strncpy() in favor
of strscpy().
Suggested-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro 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: NMauro 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: NMauro 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: NMauro 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: NMauro 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: NMauro 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: NMauro 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: NMauro 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: NMauro 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: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are some ifdefs there that end doing the same thing.
Get rid of them.
Signed-off-by: NMauro 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: NMauro 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: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

When an IRQ is not handled, it is nice to know what's the
reason.
Signed-off-by: NMauro 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: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

The abstraction layer for kvfree() was removed, but there
is still a left-over code there.
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NMauro 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: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

There's nothing there, just comments.
Signed-off-by: NMauro 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: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Fixes: 6dc9a256 ("media: atomisp: convert default struct values to use compound-literals with designated initializers")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMauro 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: NMauro 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: NMauro 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: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NMauro 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: cb02ae3d ("media: staging: atomisp: Disable custom format for now")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: a49d2536 ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: 9d4fa1a1 ("media: atomisp: cleanup directory hierarchy")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

If something gets wrong, return, instead of trying to
convert from a NULL pointer.
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Atomisp compat IOCTL handling suffers from the same security issue than
the V4L2 did. Fix this for atomisp.

See more information in patch a1dfb4c4 ("media: v4l2-compat-ioctl32.c:
refactor compat ioctl32 logic").
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

It's called struct atomisp_dis_coefficients.
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

In order to check if aren't there any memory leaks, let's
add a debug print for hmm_free().
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

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: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>