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>

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>

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>

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>

This is just a wrapper for system_local.h.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

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>

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>

There is an abstraction layer there meant to convert to
the Linux standard error codes. As the driver now use
such errors everywhere. we can get rid of this.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The atomisp driver has its own error codes under the
ia_css_err.h file. On several places, those got already
replaced by standard error codes, but there are still a
lot more to be fixed.

Let's get rid of all of those, mapping them into
the already-existing set of Linux error codes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

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>

There are tons of code inside atomisp_compat_css20.c, but
several of them are just trivial wrappers to other functions.

Getting rid of all of them will take some time, but let's
start getting rid of some of the trivial ones.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Use the variant which zeroes the memory when allocating,
instead of having an explicit memset.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Clang warns:

drivers/staging/media/atomisp/pci/runtime/binary/src/binary.c:1707:64:
warning: implicit conversion from enumeration type 'const enum
ia_css_frame_format' to different enumeration type 'enum
atomisp_input_format' [-Wenum-conversion]
        binary_supports_input_format(xcandidate, req_in_info->format));
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~             ~~~~~~~~~~~~~^~~~~~

As it turns out, binary_supports_input_format only asserts that
xcandidate is not NULL and just returns true so this call is never
actually made.

There are other functions that are called that assert info is not NULL
so this function actually serves no purpose. Remove it. It can be
brought back if needed later.

Link: https://github.com/ClangBuiltLinux/linux/issues/1036Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Clang warns:

drivers/staging/media/atomisp/pci/isp/kernels/xnr/xnr_3.0/ia_css_xnr3.host.c:129:35:
warning: implicit conversion from 'unsigned long' to 'int32_t' (aka
'int') changes value from 18446744073709543424 to -8192
[-Wconstant-conversion]
        return MAX(MIN(isp_strength, 0), -XNR_BLENDING_SCALE_FACTOR);
        ~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~

XNR_BLENDING_SCALE_FACTOR is BIT(13), or 8192, which will easily fit
into a signed 32-bit integer. However, it is an unsigned long, which
means that negating it is the same as subtracting that value from
ULONG_MAX + 1, which causes it to be larger than a signed 32-bit
integer so it gets implicitly converted.

We can avoid this by using the variable isp_scale, which holds the value
of XNR_BLENDING_SCALE_FACTOR already, where the implicit conversion from
unsigned long to s32 already happened. If that were to ever overflow,
clang would warn: https://godbolt.org/z/EeSxLG

Link: https://github.com/ClangBuiltLinux/linux/issues/1036Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Clang warns:

drivers/staging/media/atomisp/pci/atomisp_cmd.c:4278:17: warning:
address of 'config->info' will always evaluate to 'true'
[-Wpointer-bool-conversion]
                if (!&config->info) {
                    ~ ~~~~~~~~^~~~

config cannot be NULL because it comes from an ioctl, which ensures that
the user is not giving us an invalid pointer through copy_from_user. If
config is not NULL, info cannot be NULL. Remove this check.

Link: https://github.com/ClangBuiltLinux/linux/issues/1036Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Clang warns:

../drivers/staging/media/atomisp/pci/sh_css.c:8537:14: warning: address
of 'pipe->output_stage' will always evaluate to 'true'
[-Wpointer-bool-conversion]
                if (&pipe->output_stage)
                ~~   ~~~~~~^~~~~~~~~~~~
../drivers/staging/media/atomisp/pci/sh_css.c:8545:14: warning: address
of 'pipe->vf_stage' will always evaluate to 'true'
[-Wpointer-bool-conversion]
                if (&pipe->vf_stage)
                ~~   ~~~~~~^~~~~~~~

output_stage and vf_stage are pointers in the middle of a struct, their
addresses cannot be NULL if pipe is not NULL and pipe is already checked
for NULL in this function. Simplify this if block.

Link: https://github.com/ClangBuiltLinux/linux/issues/1036Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Clang warns:

../drivers/staging/media/atomisp/pci/atomisp_v4l2.c:1097:3: warning:
variable 'count' is incremented both in the loop header and in the loop
body [-Wfor-loop-analysis]
                count++;
                ^

This was probably unintentional, remove it.

Link: https://github.com/ClangBuiltLinux/linux/issues/1036Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Clang warns:

../drivers/staging/media/atomisp/pci/sh_css_sp.c:1039:23: warning:
address of 'binary->in_frame_info' will always evaluate to 'true'
[-Wpointer-bool-conversion]
                } else if (&binary->in_frame_info) {
                       ~~   ~~~~~~~~^~~~~~~~~~~~~

in_frame_info is not a pointer so if binary is not NULL, in_frame_info's
address cannot be NULL. Change this to an else since it will always be
evaluated as one.

While we are here, clean up this if block. The contents of both if
blocks are the same but a check against "stage == 0" is added when
ISP2401 is defined. USE_INPUT_SYSTEM_VERSION_2401 is only defined when
isp2401_system_global.h is included, which only happens when ISP2401. In
other words, USE_INPUT_SYSTEM_VERSION_2401 always requires ISP2401 to be
defined so the '#ifndef ISP2401' makes no sense. Remove that part of the
block to simplify everything.

Link: https://github.com/ClangBuiltLinux/linux/issues/1036Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

stage->args->delay_frames array could point to NULL frames.

What's weird is that we didn't notice this behavior with the
Intel Aero Yocto code.

Handle it, while adding a notice at the code, as this could
be due to some broken pipeline setup.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The sh_css layer adds an abstraction for kvmalloc/kvcalloc.

Get rid of them. Most of the work here was done by this
small coccinelle script:

<cocci>
@@
expression size;
@@

- sh_css_malloc(size)
+ kvmalloc(size, GFP_KERNEL)

@@
expression n;
expression size;
@@

- sh_css_calloc(n, size)
+ kvcalloc(n, size, GFP_KERNEL)
</cocci>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The frame allocation logic happens differently for userptr
or normal mmap. On a quick look, this sounded to be unbalanced,
but the logic should actually work for both cases.

Add an extra comment to reflect it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

For debugging purposes, it helps to know what event
was actually received.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

If something gets wrong when enabling or disabling an IRQ,
we should know better about what happened.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The hmm code is still complex and has bugs. Add a debug print
when memory gets allocated, in order to help identifying what's
happening out there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Instead of using a hacked version of an old copy of
get_user_pages(), use pin_user_pages().
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This device driver is not MC-centric. So, remove the wrong
caps from it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Yocto Aero driver has a different default for hmm pools.

Use the definitions there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The hmm code is partially based on a fork from 3.10 code,
and has bugs.

Add debug there to help tracking what happens there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The kernel ABI was extended to allow pass tagged user pointers.

Untag the pointers in this function.

Fixes: d9344522 ("uaccess: add noop untagged_addr definition")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Now that we have everything in place, we can get rid of the
memory_access abstraction layer.

Now, everything related to heterogeneous memory management
(hmm) is under hmm.c & related pools.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The mmgr alloc code returns a different type than hmm, due to
some abstraction layer.

Change the driver to use just one type to represent the
hmm memory.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The code for it is commented out, probably because it is
broken or uneeded for the driver to work. So, let's get
rid of it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Those functions are just wrappers for hmm_load/hmm_store.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

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>

Yet another memory abstraction layer. Getting rid of this
may be a little trickier, but let's reduce it to a minimal.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Simplify the code by removing this extra memory management
abstraction layer.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The code there is a wrapper for hmm/ wrapper. Simplify it,
and get rid of ION-specific code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are several spelling mistakes in various messages and literal
strings. Fix these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Right now, the variables that define the max number of
delay frames is defined as:

	#define VIDEO_FRAME_DELAY		2
	#define MAX_NUM_VIDEO_DELAY_FRAMES	(VIDEO_FRAME_DELAY + 1)
	#define NUM_PREVIEW_DVS_FRAMES          (2)
	#define MAX_NUM_DELAY_FRAMES   MAX(MAX_NUM_VIDEO_DELAY_FRAMES, NUM_PREVIEW_DVS_FRAMES)

In other words, we have:
	MAX_NUM_VIDEO_DELAY_FRAMES = 3
	MAX_NUM_DELAY_FRAMES = 2

The MAX_NUM_DELAY_FRAMES macro is used only only when allocating
memory. On all other parts, including looping over such array,
MAX_NUM_VIDEO_DELAY_FRAMES is used instead, like:

	void sh_css_binary_args_reset(struct sh_css_binary_args *args)
	{
		unsigned int i;
	...

		for (i = 0; i < MAX_NUM_VIDEO_DELAY_FRAMES; i++)
			args->delay_frames[i] = NULL;

Which will cause buffer overflows, with may override the next array
(tnr_frames[]).

In practice, this may not be causing real issues, as the code
checks for num_delay_frames on some parts (but not everywhere).

So, get rid of the smallest value.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Some arguments for tnf and ref settings are meant to be const, but
they're defined without such annotation. Due to that, there's an
ugly cast at sh_css_sp.c.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>