media: atomisp: Remove unnecessary NULL checks in ia_css_pipe_load_extension

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/1036
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: Remove second increment of count in atomisp_subdev_probe

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/1036
Reported-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>

media: atomisp: Clean up if block in sh_css_sp_init_stage

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/1036
Reported-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>

media: atomisp: avoid OOPS due to non-existing ref_frames

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>

media: atomisp: remove kvmalloc/kvcalloc abstractions

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>

media: atomisp: add more comments about frame allocation

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>

media: atomisp: add debug functions for received events

For debugging purposes, it helps to know what event
was actually received.

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

media: atomisp: improve warning for IRQ enable function

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>

media: atomisp: add debug for hmm alloc

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>

media: atomisp: use pin_user_pages() for memory allocation

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>

media: atomisp: fix driver caps

This device driver is not MC-centric. So, remove the wrong
caps from it.

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

media: atomisp: use Yocto Aero default hmm pool sizes

Yocto Aero driver has a different default for hmm pools.

Use the definitions there.

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

media: atomisp: add debug message to help debugging hmm code

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>

media: atomisp: hmm_bo: untag user pointers

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

Untag the pointers in this function.

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

media: atomisp: get rid of memory_access.c

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>

media: atomisp: change the type returned by mmgr alloc

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>

media: atomisp: get rid of unused memory_realloc code

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>

media: atomisp: get rid of mmgr_load and mmgr_store

Those functions are just wrappers for hmm_load/hmm_store.

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

media: atomisp: go one step further to drop ia_css_memory_access.c

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>

media: atomisp: reduce abstraction at ia_css_memory_access

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>

media: atomisp: get rid of the hrt/hive_isp_css_mm_hrt abstraction layer

Simplify the code by removing this extra memory management
abstraction layer.

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

media: atomisp: simplify hive_isp_css_mm_hrt wrapper

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>

media: atomisp: fix a handful of spelling mistakes

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>

media: atomisp: fix size of delay_frames array

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>

media: atomisp: drop a cast for a const argument

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>

media: atomisp: partially get rid of one abstraction layer

The very same macros are defined as CSS_foo and IA_CSS_foo.

Remove this abstraction, as it just make things confusing,
for no good reason.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: make it use dbg_level to control debug level

This driver has 3 different types of debug messages:

- dev_dbg()
- dbg_level
- ia_css_debug_trace_level

Which is crazy. Ideally, it shold just use dev_dbg()
everywhere, but for now let's unify the last two machanisms.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: get rid of some old broken debug code

It sounds that someone once changed the debug level at compile
time for some testing, but forgot to remove the legacy code after
finishing debuging it.

Get rid of the dead code.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: update TODO list

Let's reflect the current status at the TODO list, as other
developers can help addressing issues over there.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: don't flood dmesg with -EAGAIN return codes

Using DQBUF on non-blocking mode will return -EAGAIN
if nothing arrives. Printing it has no value, even for debug
purposes. So, only display real return codes.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: improve debug messages for set format

There are several error conditions that don't print anything,
making harder to identify bugs at the code there.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: avoid a copy of v4l2_mbus_framefmt at stack

There's no reason to copy isp_sink_fmt, as the driver
uses it for read-only purposes.

Linux stack is a precious resource. Let's avoid wasting it.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: reduce debug printk rate when IRQs are received

Currently, when an EOF IRQ is received, it generates two messages:

[   59.191893] atomisp-isp2 0000:00:03.0: irq:0x200000
[   59.191913] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 142, asd 0

Flooding the dmesg with lots of messages per second. The same
pattern happens for all other IRQs.

Change the logic for printing just one message per IRQ and
rate-limit those, as, for debugging purposes, it is usually
interesting to know that IRQs are being received, but not
displaying every single one.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: get rid of hmm_vm.c

This is not used anywhere. So, let's trash it.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix pipeline initialization code

The code under load_primary_binaries() is complex and
were hard to understand, because it used to have lots
of ifdefs and broken identation.

The patch which cleaned it and removed the version-specific
ifdefs added a regression.

Solve it.

Fixes: 3c0538fbad9f ("media: atomisp: get rid of most checks for ISP2401 version")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: Documentation: media: Refer to mbus format documentation from CSI-2 docs

The media bus formats to be used on serial busses are documented but there
was no reference from CSI-2 documentation. Add that now.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: s5k5baf: Replace zero-length array with flexible-array

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: imx219: Drop <linux/clk-provider.h> and <linux/clkdev.h>

The IMX219 camera driver is not a clock provider, but merely a clock
consumer, and thus does not need to include <linux/clk-provider.h> and
<linux/clkdev.h>.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: Add ov2740 image sensor driver

OminiVision ov2740 is a 2 megapixels RAW RGB image sensor which can
deliver 1920x1080@60fps frames. This driver add the support of
vertical blanking, exposure, test pattern, digital and analog gain
control for sensor.

Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Shawn Tu <shawnx.tu@intel.com>
Signed-off-by: Qiu, Tianshu <tian.shu.qiu@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: ov8856: Implement sensor module revision identification

Query the sensor for its module revision, and compare it
to known revisions.

Currently 2A and 1B revision indentification is supported.

[Sakari Ailus: Wrap a line over 80, alignment, use %u for printing u32]

Signed-off-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: ov8856: Add devicetree support

Add match table, enable ov8856_probe() to support
both ACPI and DT modes.

ACPI and DT modes are primarily distinguished from
by checking for ACPI mode and by having resource like
be NULL.

Signed-off-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dt-bindings: ov8856: Document YAML bindings

This patch adds documentation of device tree in YAML schema for the
OV8856 CMOS image sensor.

Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dvb-usb: Add Cinergy S2 PCIe Dual Port support

Terratec Cinergy S2 PCIe Dual is a PCIe device with two tuners that
actually contains two USB devices. The devices are visible in the
lsusb printout.

Bus 004 Device 002: ID 153b:1182 TerraTec Electronic GmbH Cinergy S2 PCIe Dual Port 2
Bus 003 Device 002: ID 153b:1181 TerraTec Electronic GmbH Cinergy S2 PCIe Dual Port 1

The devices use the Montage M88DS3000/M88TS2022 demod/tuner.

Signed-off-by: Dirk Nehring <dnehring@gmx.net>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dvbdev: Fix tuner->demod media controller link

Fixes bug exposed by:

[a3fbc2e6bb0: media: mc-entity.c: use WARN_ON, validate link pads]

The dvbdev incorrectly requests a tuner sink pad to connect to a demux
sink pad. The media controller failure percolates back and the dvb device
creation fails. Fix this by requesting a tuner source pad. Instead of
forcing that pad to be index zero, check if a negative integer error
is returned. A note is added that first source pad found is chosen.

Affected bridges cx231xx and em28xx printed the below warning[s]
when a variety of media controller dvb enabled devices were connected.
The warning returns an error causing all affected devices to fail DVB
device creation.

[  253.138332] ------------[ cut here ]------------
[  253.138339] WARNING: CPU: 0 PID: 1550 at drivers/media/mc/mc-entity.c:669 media_create_pad_link+0x1e0/0x200 [mc]
[  253.138339] Modules linked in: si2168 em28xx_dvb(+) em28xx si2157 lgdt3306a cx231xx_dvb dvb_core cx231xx_alsa cx25840 cx231xx tveeprom cx2341x i2c_mux videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc ir_rc5_decoder rc_hauppauge mceusb rc_core eda
c_mce_amd kvm nls_iso8859_1 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper efi_pstore wmi_bmof k10temp asix usbnet mii nouveau snd_hda_codec_realtek snd_hda_codec_generic input_leds ledtrig_audio snd_hda_codec_hdmi mxm_wmi snd_hda_in
tel video snd_intel_dspcfg ttm snd_hda_codec drm_kms_helper snd_hda_core drm snd_hwdep snd_seq_midi snd_seq_midi_event i2c_algo_bit snd_pcm snd_rawmidi fb_sys_fops snd_seq syscopyarea sysfillrect snd_seq_device sysimgblt snd_timer snd soundcore ccp mac_hid sch_fq_codel parport_p
c ppdev lp parport ip_tables x_tables autofs4 vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio hid_generic usbhid hid i2c_piix4 ahci libahci wmi gpio_amdpt
[  253.138370]  gpio_generic
[  253.138372] CPU: 0 PID: 1550 Comm: modprobe Tainted: G        W         5.7.0-rc2+ #181
[  253.138373] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS 2.G0 04/27/2018
[  253.138376] RIP: 0010:media_create_pad_link+0x1e0/0x200 [mc]
[  253.138378] Code: 26 fd ff ff 44 8b 4d d0 eb d9 0f 0b 41 b9 ea ff ff ff 44 89 c8 c3 0f 0b 41 b9 ea ff ff ff eb f2 0f 0b 41 b9 ea ff ff ff eb e8 <0f> 0b 41 b9 ea ff ff ff eb af 0f 0b 41 b9 ea ff ff ff eb a5 66 90
[  253.138379] RSP: 0018:ffffb9ecc0ee7a78 EFLAGS: 00010246
[  253.138380] RAX: ffff943f706c99d8 RBX: 0000000000000000 RCX: 0000000000000000
[  253.138381] RDX: ffff943f613e0180 RSI: 0000000000000000 RDI: ffff943f706c9958
[  253.138381] RBP: ffffb9ecc0ee7ab0 R08: 0000000000000001 R09: ffff943f613e0180
[  253.138382] R10: ffff943f613e0180 R11: ffff943f706c9400 R12: 0000000000000000
[  253.138383] R13: 0000000000000001 R14: ffff943f706c9958 R15: 0000000000000001
[  253.138384] FS:  00007f3cd29ba540(0000) GS:ffff943f8ec00000(0000) knlGS:0000000000000000
[  253.138385] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  253.138385] CR2: 000055f7de0ca830 CR3: 00000003dd208000 CR4: 00000000003406f0
[  253.138386] Call Trace:
[  253.138392]  media_create_pad_links+0x104/0x1b0 [mc]
[  253.138397]  dvb_create_media_graph+0x350/0x5f0 [dvb_core]
[  253.138402]  em28xx_dvb_init+0x5ea/0x2600 [em28xx_dvb]
[  253.138408]  em28xx_register_extension+0x63/0xc0 [em28xx]
[  253.138410]  ? 0xffffffffc039c000
[  253.138412]  em28xx_dvb_register+0x15/0x1000 [em28xx_dvb]
[  253.138416]  do_one_initcall+0x71/0x250
[  253.138418]  ? do_init_module+0x27/0x22e
[  253.138421]  ? _cond_resched+0x1a/0x50
[  253.138423]  ? kmem_cache_alloc_trace+0x1ec/0x270
[  253.138425]  ? __vunmap+0x1e3/0x240
[  253.138427]  do_init_module+0x5f/0x22e
[  253.138430]  load_module+0x2525/0x2d40
[  253.138436]  __do_sys_finit_module+0xe5/0x120
[  253.138438]  ? __do_sys_finit_module+0xe5/0x120
[  253.138442]  __x64_sys_finit_module+0x1a/0x20
[  253.138443]  do_syscall_64+0x57/0x1b0
[  253.138445]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  253.138446] RIP: 0033:0x7f3cd24dc839
[  253.138448] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
[  253.138449] RSP: 002b:00007ffe4fc514d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[  253.138450] RAX: ffffffffffffffda RBX: 000055a9237f63f0 RCX: 00007f3cd24dc839
[  253.138451] RDX: 0000000000000000 RSI: 000055a922c3ad2e RDI: 0000000000000000
[  253.138451] RBP: 000055a922c3ad2e R08: 0000000000000000 R09: 0000000000000000
[  253.138452] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[  253.138453] R13: 000055a9237f5550 R14: 0000000000040000 R15: 000055a9237f63f0
[  253.138456] ---[ end trace a60f19c54aa96ec4 ]---

[  234.915628] ------------[ cut here ]------------
[  234.915640] WARNING: CPU: 0 PID: 1502 at drivers/media/mc/mc-entity.c:669 media_create_pad_link+0x1e0/0x200 [mc]
[  234.915641] Modules linked in: si2157 lgdt3306a cx231xx_dvb(+) dvb_core cx231xx_alsa cx25840 cx231xx tveeprom cx2341x i2c_mux videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc ir_rc5_decoder rc_hauppauge mceusb rc_core edac_mce_amd kvm nls_iso8859
_1 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper efi_pstore wmi_bmof k10temp asix usbnet mii nouveau snd_hda_codec_realtek snd_hda_codec_generic input_leds ledtrig_audio snd_hda_codec_hdmi mxm_wmi snd_hda_intel video snd_intel_dspcf
g ttm snd_hda_codec drm_kms_helper snd_hda_core drm snd_hwdep snd_seq_midi snd_seq_midi_event i2c_algo_bit snd_pcm snd_rawmidi fb_sys_fops snd_seq syscopyarea sysfillrect snd_seq_device sysimgblt snd_timer snd soundcore ccp mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tab
les x_tables autofs4 vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio hid_generic usbhid hid i2c_piix4 ahci libahci wmi gpio_amdpt gpio_generic
[  234.915700] CPU: 0 PID: 1502 Comm: modprobe Not tainted 5.7.0-rc2+ #181
[  234.915702] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS 2.G0 04/27/2018
[  234.915709] RIP: 0010:media_create_pad_link+0x1e0/0x200 [mc]
[  234.915712] Code: 26 fd ff ff 44 8b 4d d0 eb d9 0f 0b 41 b9 ea ff ff ff 44 89 c8 c3 0f 0b 41 b9 ea ff ff ff eb f2 0f 0b 41 b9 ea ff ff ff eb e8 <0f> 0b 41 b9 ea ff ff ff eb af 0f 0b 41 b9 ea ff ff ff eb a5 66 90
[  234.915714] RSP: 0018:ffffb9ecc1b6fa50 EFLAGS: 00010246
[  234.915717] RAX: ffff943f8c94a9d8 RBX: 0000000000000000 RCX: 0000000000000000
[  234.915719] RDX: ffff943f613e0900 RSI: 0000000000000000 RDI: ffff943f8c94a958
[  234.915721] RBP: ffffb9ecc1b6fa88 R08: 0000000000000001 R09: ffff943f613e0900
[  234.915723] R10: ffff943f613e0900 R11: ffff943f6b590c00 R12: 0000000000000000
[  234.915724] R13: 0000000000000001 R14: ffff943f8c94a958 R15: 0000000000000001
[  234.915727] FS:  00007f4ca3646540(0000) GS:ffff943f8ec00000(0000) knlGS:0000000000000000
[  234.915729] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  234.915731] CR2: 00007fff7a53ba18 CR3: 00000003da614000 CR4: 00000000003406f0
[  234.915733] Call Trace:
[  234.915745]  media_create_pad_links+0x104/0x1b0 [mc]
[  234.915756]  dvb_create_media_graph+0x350/0x5f0 [dvb_core]
[  234.915766]  dvb_init.part.4+0x691/0x1360 [cx231xx_dvb]
[  234.915780]  dvb_init+0x1a/0x20 [cx231xx_dvb]
[  234.915787]  cx231xx_register_extension+0x71/0xa0 [cx231xx]
[  234.915791]  ? 0xffffffffc042f000
[  234.915796]  cx231xx_dvb_register+0x15/0x1000 [cx231xx_dvb]
[  234.915802]  do_one_initcall+0x71/0x250
[  234.915807]  ? do_init_module+0x27/0x22e
[  234.915811]  ? _cond_resched+0x1a/0x50
[  234.915816]  ? kmem_cache_alloc_trace+0x1ec/0x270
[  234.915820]  ? __vunmap+0x1e3/0x240
[  234.915826]  do_init_module+0x5f/0x22e
[  234.915831]  load_module+0x2525/0x2d40
[  234.915848]  __do_sys_finit_module+0xe5/0x120
[  234.915850]  ? __do_sys_finit_module+0xe5/0x120
[  234.915862]  __x64_sys_finit_module+0x1a/0x20
[  234.915865]  do_syscall_64+0x57/0x1b0
[  234.915870]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  234.915872] RIP: 0033:0x7f4ca3168839
[  234.915876] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
[  234.915878] RSP: 002b:00007ffcea3db3b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[  234.915881] RAX: ffffffffffffffda RBX: 000055af22c29340 RCX: 00007f4ca3168839
[  234.915882] RDX: 0000000000000000 RSI: 000055af22c38390 RDI: 0000000000000001
[  234.915884] RBP: 000055af22c38390 R08: 0000000000000000 R09: 0000000000000000
[  234.915885] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000
[  234.915887] R13: 000055af22c29060 R14: 0000000000040000 R15: 0000000000000000
[  234.915896] ---[ end trace a60f19c54aa96ec3 ]---

Signed-off-by: Brad Love <brad@nextdimension.cc>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dt-bindings: phy: phy-rockchip-dphy-rx0: move rockchip dphy rx0 bindings out of staging

Move phy-rockchip-dphy-rx0 bindings to Documentation/devicetree/bindings/phy

Verified with:
make ARCH=arm64 dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml

Signed-off-by: Helen Koike <helen.koike@collabora.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: dt-bindings: phy-rockchip-dphy-rx0: remove non-used reg property

reg property is not used in Rockchip MIPI DPHY RX0 bindings, thus remove
it.

Suggested-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: unify the version for isp2401 a0 and b0 versions

Based on Yocto Aero's repository, the file name for the isp2401
is the same for the B0 release.

So, unify it at the driver.

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

media: atomisp: update TODO with the current data

The TODO list doesn't reflect the current status of the driver.

Update it.

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

media: atomisp: adjust some code at sh_css that could be broken

When checking sh_css.c against the Yocto Aero's version, it can
be noticed that some isp2401 dependencies may have been taken
wrongly.

Change the code to work like the Yocto Aero, as this driver
was tested in the past with an ISP2401 device.

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

media: atomisp: don't produce errs for ignored IRQs

Depending on the ISP-specific HAS_NO_INPUT_FORMATTER macro,
some IRQs will be ignored by the driver. Yet, those keep
happening, as reported by this debug print:

[   61.620746] atomisp-isp2 0000:00:03.0: atomisp_css_irq_enable: css irq info 0x00000004: disable.

Causing this warning:
[   61.620749] atomisp-isp2 0000:00:03.0: atomisp_css_irq_enable:Invalid irq info.

Well, if this is a normal situation, just ignore it without
warnings.

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

media: atomisp: print IRQ when debugging

Add a debug printk to show what IRQ is popping up.

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

media: atomisp: isp_mmu: don't use kmem_cache

Instead of using it only if system memory is below 2GB,
don't use it at all. The problem is that the code there is not
compatible anymore with modern Kernels:

[  179.552797] virt_to_cache: Object is not a Slab page!
[  179.552821] WARNING: CPU: 0 PID: 1414 at mm/slab.h:475 cache_from_obj+0xab/0xf0
[  179.552824] Modules linked in: ccm(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) ip6table_nat(E) ip6table_mangle(E) ip6table_raw(E) ip6table_security(E) iptable_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) libcrc32c(E) nf_defrag_ipv4(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) ip_set(E) nf_tables(E) nfnetlink(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) cmac(E) bnep(E) sunrpc(E) vfat(E) fat(E) mei_hdcp(E) snd_soc_sst_cht_bsw_rt5645(E) gpio_keys(E) intel_rapl_msr(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) asus_nb_wmi(E) ath10k_pci(E) ghash_clmulni_intel(E) ath10k_core(E) intel_cstate(E) wdat_wdt(E) pcspkr(E) ath(E) mac80211(E) intel_chtdc_ti_pwrbtn(E) joydev(E) btusb(E) btrtl(E) btbcm(E) btintel(E) libarc4(E) bluetooth(E) cfg80211(E) ecdh_generic(E) ecc(E) mei_txe(E) mei(E) lpc_ich(E)
[  179.552887]  hid_sensor_accel_3d(E) hid_sensor_gyro_3d(E) hid_sensor_trigger(E) hid_sensor_iio_common(E) industrialio_triggered_buffer(E) kfifo_buf(E) industrialio(E) atomisp_ov2680(CE) snd_soc_rt5645(E) snd_intel_sst_acpi(E) snd_soc_rl6231(E) snd_intel_sst_core(E) snd_soc_sst_atom_hifi2_platform(E) intel_hid(E) snd_soc_acpi_intel_match(E) spi_pxa2xx_platform(E) snd_soc_acpi(E) snd_soc_core(E) snd_compress(E) dw_dmac(E) snd_hdmi_lpe_audio(E) int3400_thermal(E) int3406_thermal(E) snd_seq(E) acpi_thermal_rel(E) int3403_thermal(E) atomisp(CE) snd_seq_device(E) snd_pcm(E) intel_int0002_vgpio(E) soc_button_array(E) acpi_pad(E) intel_xhci_usb_role_switch(E) snd_timer(E) videobuf_vmalloc(E) videobuf_core(E) snd(E) atomisp_gmin_platform(CE) soundcore(E) videodev(E) processor_thermal_device(E) intel_soc_dts_iosf(E) mc(E) intel_rapl_common(E) int340x_thermal_zone(E) ip_tables(E) hid_sensor_hub(E) intel_ishtp_loader(E) intel_ishtp_hid(E) mmc_block(E) hid_multitouch(E) crc32c_intel(E) i915(E)
[  179.552936]  hid_asus(E) i2c_algo_bit(E) asus_wmi(E) sparse_keymap(E) rfkill(E) drm_kms_helper(E) intel_ish_ipc(E) intel_ishtp(E) drm(E) wmi(E) video(E) i2c_hid(E) pwm_lpss_platform(E) pwm_lpss(E) sdhci_acpi(E) sdhci(E) mmc_core(E) fuse(E)
[  179.552961] CPU: 0 PID: 1414 Comm: v4l2grab Tainted: G         C  EL    5.7.0-rc2+ #42
[  179.552963] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.306 04/23/2019
[  179.552968] RIP: 0010:cache_from_obj+0xab/0xf0
[  179.552973] Code: c3 31 c0 80 3d 1c 38 72 01 00 75 f0 48 c7 c6 20 12 06 9f 48 c7 c7 10 f3 37 9f 48 89 04 24 c6 05 01 38 72 01 01 e8 2c 99 e0 ff <0f> 0b 48 8b 04 24 eb ca 48 8b 57 58 48 8b 48 58 48 c7 c6 30 12 06
[  179.552976] RSP: 0018:ffffaf1f00c3fae0 EFLAGS: 00010282
[  179.552980] RAX: 0000000000000029 RBX: 00000000000003ff RCX: 0000000000000007
[  179.552983] RDX: 00000000fffffff8 RSI: 0000000000000082 RDI: ffff9cb6bbc19cc0
[  179.552985] RBP: 0000000001000000 R08: 00000000000005a4 R09: ffffaf1f00c3f970
[  179.552988] R10: 0000000000000005 R11: 0000000000000000 R12: ffffffffc0713da0
[  179.552991] R13: ffff9cb5a7bb1000 R14: 0000000001000000 R15: ffff9cb5a7bb1000
[  179.552995] FS:  0000000000000000(0000) GS:ffff9cb6bbc00000(0000) knlGS:0000000000000000
[  179.552998] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  179.553000] CR2: 00007fe780544400 CR3: 000000002480a000 CR4: 00000000001006f0
[  179.553003] Call Trace:
[  179.553015]  kmem_cache_free+0x19/0x180
[  179.553070]  mmu_l2_unmap+0xd1/0x100 [atomisp]
[  179.553113]  ? __bo_merge+0x8f/0xa0 [atomisp]
[  179.553155]  mmu_unmap+0xd0/0xf0 [atomisp]
[  179.553198]  hmm_bo_unbind+0x62/0xb0 [atomisp]
[  179.553240]  hmm_free+0x44/0x60 [atomisp]

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

media: atomisp: add a notice about possible leak resources

Calling acpi_bus_get_device() may end allocating resources that
aren't freed. So, add a notice about that, as, if those drivers
get out of staging, we may need some changes.

Fixes: 0d64e9420583 ("media: atomisp: Add some ACPI detection info")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: disable the dynamic and reserved pools

The memory management code for atomisp is complex: it has 2
extra pools (plus some ION-specific code).

The code for those extra pools are complex, and there are even
some parts of code over there that were forked from some
mm/ code, probably from Kernel 3.10.

Let's just use a single one, in order to make the driver
simpler.

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

media: atomisp: turn on camera before setting it

Camera cannot be set on power off mode.

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

media: atomisp: simplify ov2680 array write logic

Instead of trying to send multiple bytes at the same time,
just go one by one, like the upstream driver does.

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

media: atomisp-ov2680: get rid of the type field

This isn't really used, so get rid, in order to make the code
simpler.

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

media: atomisp: use read/write routines from mainstream

There is an ov2680 driver mainstream. Use the read/write
routines from it, as the ones inside this driver are
generating some errors:

ov2680 i2c-OVTI2680:00: ov2680_i2c_write: i2c write reg=0x3086, value 0x00, error -121

Maybe the code that changes from/to BE are not right.

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

media: atomisp: ov2680: improve debug messages

Change some code at ov2680 for it to better report what's
happening there at sensor's level.

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

media: atomisp: change the code to properly wait for sensor

The sensor should finish its init before atomisp driver, as
otherwise the atomisp driver won't be able to talk with it.

So, we need to turn atomisp_gmin_platform into a module
again, for it to not depend on atomisp driver to finish
probing, and add some delay at atomisp to let the sensor
driver to finish probing.

Yeah, this is hacky. The real solution here would be to use
the async framework, but for now, our goal is to make the
driver to work. So, let's postpone such change to be done
later.

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

media: atomisp: keep the ISP powered on when setting it

The current code causes ISP2401 to power down and never return
back to live, causing the driver to crash.

Fix it by commenting out the bad code. It should be noticed that
the Yocto Aero code has something similar to it.

Maybe the issue is related to an ISP bug (or maybe PM is
controlled on a different way for this hardware).

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

media: atomisp: fix the value for CamClk on Asus T101HA

The value returned by BIOS is 1. Fix it at the driver,
as it won't read this from EFI.

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

media: atomisp: fix a slab error due to a wrong free

The mmu mapping logic uses a different logic depending on the
RAM size: if it is lower than 2GB, it uses kmem_cache_zalloc(),
but if memory is bigger than that, it uses its own way to
allocate memory.

Yet, when freeing, it uses kmem_cache_free() for any cases.

On recent Kernels, slab tracks the memory allocated on it,
with causes those warnings:

 virt_to_cache: Object is not a Slab page!
 WARNING: CPU: 0 PID: 758 at mm/slab.h:475 cache_from_obj+0xab/0xf0
 Modules linked in: snd_soc_sst_cht_bsw_rt5645(E) mei_hdcp(E) gpio_keys(E) intel_rapl_msr(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) atomisp_ov2680(CE) intel_cstate(E) asus_nb_wmi(E) wdat_wdt(E) pcspkr(E) ath10k_pci(E) ath10k_core(E) intel_chtdc_ti_pwrbtn(E) ath(E) mac80211(E) btusb(E) joydev(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) libarc4(E) ecdh_generic(E) cfg80211(E) ecc(E) hid_sensor_gyro_3d(E) hid_sensor_accel_3d(E) hid_sensor_trigger(E) hid_sensor_iio_common(E) industrialio_triggered_buffer(E) kfifo_buf(E) industrialio(E) atomisp(CE) videobuf_vmalloc(E) videobuf_core(E) videodev(E) mc(E) snd_soc_rt5645(E) snd_soc_rl6231(E) snd_intel_sst_acpi(E) snd_intel_sst_core(E) snd_soc_sst_atom_hifi2_platform(E) snd_soc_acpi_intel_match(E) intel_hid(E) spi_pxa2xx_platform(E) snd_soc_acpi(E) snd_soc_core(E) snd_compress(E) dw_dmac(E) intel_xhci_usb_role_switch(E) int3406_thermal(E)
  snd_hdmi_lpe_audio(E) int3403_thermal(E) int3400_thermal(E) acpi_thermal_rel(E) snd_seq(E) intel_int0002_vgpio(E) soc_button_array(E) snd_seq_device(E) acpi_pad(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) lpc_ich(E) mei_txe(E) mei(E) processor_thermal_device(E) intel_soc_dts_iosf(E) intel_rapl_common(E) int340x_thermal_zone(E) ip_tables(E) hid_sensor_hub(E) intel_ishtp_loader(E) intel_ishtp_hid(E) mmc_block(E) hid_multitouch(E) crc32c_intel(E) i915(E) i2c_algo_bit(E) drm_kms_helper(E) hid_asus(E) asus_wmi(E) sparse_keymap(E) rfkill(E) drm(E) intel_ish_ipc(E) intel_ishtp(E) wmi(E) video(E) i2c_hid(E) sdhci_acpi(E) sdhci(E) mmc_core(E) pwm_lpss_platform(E) pwm_lpss(E) fuse(E)
 CPU: 0 PID: 758 Comm: v4l_id Tainted: G         C  E     5.7.0-rc2+ #40
 Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.306 04/23/2019
 RIP: 0010:cache_from_obj+0xab/0xf0
 Code: c3 31 c0 80 3d 1c 38 72 01 00 75 f0 48 c7 c6 20 12 06 b5 48 c7 c7 10 f3 37 b5 48 89 04 24 c6 05 01 38 72 01 01 e8 2c 99 e0 ff <0f> 0b 48 8b 04 24 eb ca 48 8b 57 58 48 8b 48 58 48 c7 c6 30 12 06
 RSP: 0018:ffffb0a4c07cfb10 EFLAGS: 00010282
 RAX: 0000000000000029 RBX: 0000000000000048 RCX: 0000000000000000
 RDX: ffffa004fbca5b80 RSI: ffffa004fbc19cc8 RDI: ffffa004fbc19cc8
 RBP: 0000000000c49000 R08: 00000000000004f7 R09: 0000000000000001
 R10: 0000000000aaaaaa R11: ffffffffb50e0600 R12: ffffffffc0be0a00
 R13: ffffa003f2448000 R14: 0000000000c49000 R15: ffffa003f2448000
 FS:  00007f9060c9cb80(0000) GS:ffffa004fbc00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000559fc55b8000 CR3: 0000000165b02000 CR4: 00000000001006f0
 Call Trace:
  kmem_cache_free+0x19/0x180
  mmu_l2_unmap+0xd1/0x100 [atomisp]
  mmu_unmap+0xd0/0xf0 [atomisp]
  hmm_bo_unbind+0x62/0xb0 [atomisp]
  hmm_free+0x44/0x60 [atomisp]
  ia_css_spctrl_unload_fw+0x30/0x50 [atomisp]
  ia_css_uninit+0x3a/0x90 [atomisp]
  atomisp_open+0x50b/0x5c0 [atomisp]
  v4l2_open+0x85/0xf0 [videodev]
  chrdev_open+0xdd/0x210
  ? cdev_device_add+0xc0/0xc0
  do_dentry_open+0x13a/0x380
  path_openat+0xa9a/0xfe0
  do_filp_open+0x75/0x100
  ? __check_object_size+0x12e/0x13c
  ? __alloc_fd+0x44/0x150
  do_sys_openat2+0x8a/0x130
  __x64_sys_openat+0x46/0x70
  do_syscall_64+0x5b/0xf0
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Solve it by calling free_page() directly

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

media: atomisp: get rid of __bo_alloc() macro

Simplify the hmm_bo a little bit by removing this
macro. This will avoid printing twice errors when
allocations happen.

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

media: atomisp: get rid of spmem_dump.c

Those files seem to be firmware-dependent, probably being used
by some debug interface.

Well, their contents are not really used by atomisp, so let's
just send them to the trash can, as it shouldn't have any
usage upstream.

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

media: atomisp: fix an inverted logic

When changing the IFs to select isp2401 at runtime, one of
the conditions ended by being written wrong.

Code double-checked on both Yocto Aero's driver version and
against the previous code.

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

media: atomisp: remove a misplaced #endif

There is an endif in the middle of a comment at
ia_css_xnr3.host.c. Remove it.

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

media: atomisp: simplify the power down/up code

Use the version from intel_atomisp2_pm.c for power up/down,
removing some code duplication and using just one kAPI call
for modifying the ISPSSPM0 register.

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

media: atomisp: use pcim_enable_device() again

Changing to pci_enable_device() didn't produce the expected
result. It could also eventually led to problems when driver
is removed, due to object lifetime issues. So, let's just
return to the previous behavior.

Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: spctrl: be sure to zero .code_addr after free

We need that to avoid trying to double-free the driver.

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

media: atomisp: add support for different PMIC configurations

This patch required lots of research and work. The existing
atomisp driver at staging assumed that all Intel PMIC would
be using regulators, but upstream didn't follow it. Instead,
the intel_pmic.c driver added a hack, instead of using i2c_transfer,
it writes I2C values directly via regmapped registers.

Oh, well... At least, it provided a common API for doing that.

The PMIC settings used here came from the driver at the
yocto Aero distribution:

https://download.01.org/aero/deb/pool/main/l/linux-4.4.76-aero-1.3/

The logic itself was re-written, in order to use the I2C address
detected by the probing part.

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

media: atomisp: move atomisp_gmin_platform.c to pci/ dir

The atomisp_gmin_platform.c is not a platform driver anymore,
but it is, instead, part of the atomisp driver.

Move it to be together with the driver. As a bonus, as the
atomisp i2c drivers depends on its contents, probing them
should load automatically the atomisp core. This should
likely avoid some possible race conditions.

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

media: atomisp: detect the PMIC type

Sub-device's power management can be provided via different ways.

Instead of hardcoding it, add a code that would be detecting it.

This uses a code similar to what's found at the atomisp driver
inside the Intel Aero repository:

https://github.com/intel-aero/meta-intel-aero.git

(driver was removed on some commit, but it can be found on
git history).

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

media: atomisp: warn if unsupported subdevs are found

Right now, the driver supports just one VCM and just one
flash device. Warn if more than one such devices were
probed.

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

media: atomisp: reduce the risk of a race condition

This driver is really on bad shape. One of the problems
is that, as soon as the I2C transfers start to happen, it
timeouts detecting a camera:

ov2680 i2c-OVTI2680:00: ov2680_probe: ACPI detected it on bus ID=CAM1, HID=OVTI2680
atomisp-isp2 0000:00:03.0: no camera attached or fail to detect
ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module subdev data using PMIC regulator
...

The right fix here would be to use defer probe, but driver is
still on too bad shape.

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

media: atomisp: print the type of PMIC that will be used

While the current code is hardcoded to just one specific
type of PMIC, it can support several types. Those should
be board-dependent. Instead of just printing a number,
change the message to display what type of PMIC control
is used at runtime.

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

media: atomisp: better display DMI and EFI found entries

There are several device-specific data that are obtained
either via DMI or EFI, with changes the driver's behavior.

Display what has been detected, as such info may help
identifying troubles at the driver.

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

media: atomisp: Add some ACPI detection info

When someone would report problems with a new device, we
need to know the DMI product ID and the ACPI name for the
detected sensor. So, print them at dmesg.

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

media: atomisp: add -dDEBUG when building this driver

This driver still has lots of issues. Let's enable debug
there inconditionally, as we need more information in order
to address the pending issues.

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

media: atomisp: make dfs_config_merr_117a struct const

This setting is used only for one of te Merryfield PCI IDs.

As this is an ISP2400, we can just get rid of a version
test, writing the right value directly inside the struct.

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

media: atomisp: free PCI resources when probing fail

The atomisp probe error logic is incomplete. Add the missing
bits to return the PCI device to its original state.

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

media: atomisp: relax firmware version detection criteria

As getting the exact version used by the driver is not easy,
let's relax the version detection and hope for the best,
producing just a warning.

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

media: atomisp: improve device detection code

- Remove useless check if !dev at the probe function: if
  such function is called, the device is defined.
- Cleanup the PCI ID table using macros.
- Use the same macros at the version-dependent part of the
  atomisp_v4l2.c file;
- Add print messages to help understand what model the
  driver detect;
- If device is not valid, better explain why.

Signed-off-by: Mauro Carvalho Chehehab <mchehab+huawei@kernel.org>

media: atomisp: fix clock rate frequency setting

changeset d5426f4c2eba ("media: staging: atomisp: use clock framework for camera clocks")
removed a platform-specific code to set the clock rate, in favor of
using the Kernel clock framework.

However, instead of passing the frequency for clk_set_rate(),
it is passing either 0 or 1.

Looking at the original patchset, it seems that there are two
possible configurations for the ISP:

0 - it will use a 25 MHz XTAL to provide the clock;
1 - it will use a PLL with is set to 19.2 MHz
    (only for the CHT version?)

Eventually, different XTALs and/or PLL frequencies might
be possible some day, so, re-implent the logic for it to be
more generic.

Fixes: d5426f4c2eba ("media: staging: atomisp: use clock framework for camera clocks")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: limit the name of the firmware file

The firmware header has 64 bytes. Properly limit it to such
size.

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

media: atomisp: print a better message when fw version is wrong

The printed message when a firmware version is wrong says nothing
usefull:

atomisp-isp2 0000:00:03.0: Fw version check failed.
atomisp-isp2: probe of 0000:00:03.0 failed with error -22

Print the expected and the received firmware version instead.

In order to do that, the firmware functions will need at least
a struct device pointer, so pass it.

While writing this patch, it was noticed that some of the
abstraction layers of this driver have functions that are never
called, but use this interface. Get rid of them.

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

media: atomisp: disable the dummy PM driver is atomisp driver is built

As the atomisp driver should already be handling the ISP
PCI ID, there's no sense on keeping the dummy driver enabled
in tis case.

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

media: atomisp: move ia_css_configure_sc() implementation

With the changes, this function is now undefined if built
for ISP2400. So, move its implementation to the file which
calls it.

Reported-by: Francescodario Cuzzocrea <francescodario.cuzzocrea@mail.polimi.it>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix querycap initialization logic

Some recent changes at V4L2 core changed the way querycap is handled.

Due to that, this warning is generated:

WARNING: CPU: 1 PID: 503 at drivers/media/v4l2-core/v4l2-dev.c:885 __video_register_device+0x93e/0x1120 [videodev]

as introduced by this commit:

commit 3c1350501c21db8e3b1a38d9e97db29694305c3b
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Tue Jul 23 04:21:25 2019 -0400

    media: v4l2-dev/ioctl: require non-zero device_caps, verify sane querycap results

    Now that all V4L2 drivers set device_caps in struct video_device, we can add
    a check for this to ensure all future drivers fill this in.

The fix is simple: we just need to initialize dev_caps before
registering the V4L2 dev.

While here, solve other problems at VIDIOC_QUERYCAP ioctl.

Reported-by: Patrik Gfeller <patrik.gfeller@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: use add_qos_request instead of update

It doesn't make senst to update a request that was not
created. So, instead of using cpu_latency_qos_update_request(),
let's use, instead cpu_latency_qos_add_request() at device
probing code.

This should fix this issue:

[    9.691775] cpu_latency_qos_update_request called for unknown object
[    9.695279] WARNING: CPU: 3 PID: 523 at kernel/power/qos.c:296 cpu_latency_qos_update_request+0x3a/0xb0
[    9.698826] Modules linked in: snd_soc_acpi_intel_match snd_rawmidi snd_soc_acpi snd_soc_rl6231 snd_soc_core ath mac80211 snd_compress snd_hdmi_lpe_audio ac97_bus hid_sensor_accel_3d snd_pcm_dmaengine hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common processor_thermal_device industrialio cfg80211 snd_pcm snd_seq intel_rapl_common atomisp(C+) libarc4 intel_soc_dts_iosf cros_ec_ishtp intel_xhci_usb_role_switch mei_txe cros_ec videobuf_vmalloc mei roles atomisp_ov2680(C) videobuf_core snd_seq_device snd_timer spi_pxa2xx_platform videodev snd mc dw_dmac intel_hid dw_dmac_core 8250_dw soundcore int3406_thermal int3400_thermal intel_int0002_vgpio acpi_pad acpi_thermal_rel soc_button_array int3403_thermal int340x_thermal_zone mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_sensor_custom hid_sensor_hub intel_ishtp_loader intel_ishtp_hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i915 mmc_block i2c_algo_bit
[    9.698885]  aesni_intel crypto_simd drm_kms_helper cryptd syscopyarea sysfillrect glue_helper sysimgblt fb_sys_fops cec intel_ish_ipc drm lpc_ich intel_ishtp hid_asus intel_soc_pmic_chtdc_ti asus_wmi i2c_hid sparse_keymap sdhci_acpi wmi video sdhci hid_generic usbhid hid
[    9.736699] CPU: 3 PID: 523 Comm: systemd-udevd Tainted: G         C        5.7.0-rc1+ #2
[    9.741309] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.305 01/24/2018
[    9.745962] RIP: 0010:cpu_latency_qos_update_request+0x3a/0xb0
[    9.750615] Code: 89 e5 41 55 41 54 41 89 f4 53 48 89 fb 48 81 7f 28 e0 7f c6 9e 74 1c 48 c7 c6 60 f3 65 9e 48 c7 c7 e8 a9 99 9e e8 b2 a6 f9 ff <0f> 0b 5b 41 5c 41 5d 5d c3 0f 1f 44 00 00 44 3b 23 74 ef 44 89 e2
[    9.760065] RSP: 0018:ffffa865404f39c0 EFLAGS: 00010282
[    9.764734] RAX: 0000000000000000 RBX: ffff9d2aefc84350 RCX: 0000000000000000
[    9.769435] RDX: ffff9d2afbfa97c0 RSI: ffff9d2afbf99808 RDI: ffff9d2afbf99808
[    9.774125] RBP: ffffa865404f39d8 R08: 0000000000000304 R09: 0000000000aaaaaa
[    9.778804] R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffff
[    9.783491] R13: ffff9d2afb4640b0 R14: ffffffffc07ecf20 R15: 0000000091000000
[    9.788187] FS:  00007efe67ff8880(0000) GS:ffff9d2afbf80000(0000) knlGS:0000000000000000
[    9.792864] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    9.797482] CR2: 00007ffc6424bdc8 CR3: 0000000178998000 CR4: 00000000001006e0
[    9.802126] Call Trace:
[    9.806775]  atomisp_pci_probe.cold.19+0x15f/0x116f [atomisp]
[    9.811441]  local_pci_probe+0x47/0x80
[    9.816085]  pci_device_probe+0xff/0x1b0
[    9.820706]  really_probe+0x1c8/0x3e0
[    9.825247]  driver_probe_device+0xd9/0x120
[    9.829769]  device_driver_attach+0x58/0x60
[    9.834294]  __driver_attach+0x8f/0x150
[    9.838782]  ? device_driver_attach+0x60/0x60
[    9.843205]  ? device_driver_attach+0x60/0x60
[    9.847634]  bus_for_each_dev+0x79/0xc0
[    9.852033]  ? kmem_cache_alloc_trace+0x167/0x230
[    9.856462]  driver_attach+0x1e/0x20

Reported-by: Patrik Gfeller <patrik.gfeller@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: remove some file duplication and do more dir renames

There are currently two identical copies of some files, one
at css_2401_csi2p_system/ and another one at css_2401_system/.

Get rid of one of them, moving the remaining files to the
directory with the shortest name.

While here, do more renames, in order to get smaller path
names.

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

media: atomisp: add firmware load code for ISP2401 rev B0

The Asus Transformer T101HA comes with a newer hardware
version. Add support to load firmware for it.

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

media: atomisp: get rid of most checks for ISP2401 version

There are lots of places inside this driver checking for
ISP2400/ISP2401 verison. Get rid of most of those, while
keep building for both.

Most of stuff in this patch is trivial to solve.

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

media: atomisp: cleanup contents of css_2401_system

Everything there is for ISP2401 only. So, we can trivially
solve all ifdefs at once.

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

media: atomisp: cleanup contents of css_2401_csi2p_system

Everything there is for ISP2401 only. So, we can trivially
solve all ifdefs at once.

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

media: atomisp: cleanup contents of css_2400_system/

Everything there is for ISP2400 only. So, we can trivially
solve all ifdefs at once

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

media: atomisp: allow building for isp2401

Now that everything needed to build for ISP2401 is solved,
we can setup atomisp to build either for ISP2400 or ISP2401.

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

media: atomisp: change function worders and fix include

With the current way, it will produce lots of errors because
the public header contains wrong definitions and the private
one has functions defined at the wrong order.

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

media: atomisp: get rid of some broken code

Probably due to some version conflicts while the atomisp code
were generated, some things don't build for ISP2401. So, use
the ISP2400 variant when available, or get rid of the
code that doesn't build.

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

media: atomisp: cleanup directory hierarchy

This driver has very long directories without a good
reason (IMHO). Let's drop two directories from such hierarchy,
in order to simplify things a little bit and make the dir
output a bit more readable.

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