The dummy_ptr check in hmm_init() [1] results in the following
"hmm_init Failed to create sysfs" error exactly once every
two times on atomisp reload by rmmod/insmod (although atomisp module
loads and works fine regardless of this error):

	[  140.230662] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:03.0/active_bo'
	[  140.230668] CPU: 1 PID: 2502 Comm: insmod Tainted: G         C OE     5.15.0-rc4-1-surface-mainline #1 b8acf6eb64994414b2e20bad312a7a2c45f748f9
	[  140.230675] Hardware name: OEMB OEMB/OEMB, BIOS 1.51116.238 03/09/2015
	[  140.230678] Call Trace:
	[  140.230687]  dump_stack_lvl+0x46/0x5a
	[  140.230702]  sysfs_warn_dup.cold+0x17/0x24
	[  140.230710]  sysfs_add_file_mode_ns+0x160/0x170
	[  140.230717]  internal_create_group+0x126/0x390
	[  140.230723]  hmm_init+0x5c/0x70 [atomisp 7a6a680bf400629363d2a6f58fd10e7299678b99]
	[  140.230811]  atomisp_pci_probe.cold+0x1136/0x148e [atomisp 7a6a680bf400629363d2a6f58fd10e7299678b99]
	[  140.230875]  local_pci_probe+0x45/0x80
	[  140.230882]  ? pci_match_device+0xd7/0x130
	[  140.230887]  pci_device_probe+0xfa/0x1b0
	[  140.230892]  really_probe+0x1f5/0x3f0
	[  140.230899]  __driver_probe_device+0xfe/0x180
	[  140.230903]  driver_probe_device+0x1e/0x90
	[  140.230908]  __driver_attach+0xc0/0x1c0
	[  140.230912]  ? __device_attach_driver+0xe0/0xe0
	[  140.230915]  ? __device_attach_driver+0xe0/0xe0
	[  140.230919]  bus_for_each_dev+0x89/0xd0
	[  140.230924]  bus_add_driver+0x12b/0x1e0
	[  140.230929]  driver_register+0x8f/0xe0
	[  140.230933]  ? 0xffffffffc153f000
	[  140.230937]  do_one_initcall+0x57/0x220
	[  140.230945]  do_init_module+0x5c/0x260
	[  140.230952]  load_module+0x24bd/0x26a0
	[  140.230962]  ? __do_sys_finit_module+0xae/0x110
	[  140.230966]  __do_sys_finit_module+0xae/0x110
	[  140.230972]  do_syscall_64+0x5c/0x80
	[  140.230979]  ? syscall_exit_to_user_mode+0x23/0x40
	[  140.230983]  ? do_syscall_64+0x69/0x80
	[  140.230988]  ? exc_page_fault+0x72/0x170
	[  140.230991]  entry_SYSCALL_64_after_hwframe+0x44/0xae
	[  140.230997] RIP: 0033:0x7f7fd5d8718d
	[  140.231003] Code: b4 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 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 b3 6c 0c 00 f7 d8 64 89 01 48
	[  140.231006] RSP: 002b:00007ffefc25f0e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
	[  140.231012] RAX: ffffffffffffffda RBX: 000055ac3edcd7f0 RCX: 00007f7fd5d8718d
	[  140.231015] RDX: 0000000000000000 RSI: 000055ac3d723270 RDI: 0000000000000003
	[  140.231017] RBP: 0000000000000000 R08: 0000000000000000 R09: 00007f7fd5e52380
	[  140.231019] R10: 0000000000000003 R11: 0000000000000246 R12: 000055ac3d723270
	[  140.231021] R13: 0000000000000000 R14: 000055ac3edd06e0 R15: 0000000000000000
	[  140.231038] atomisp-isp2 0000:00:03.0: hmm_init Failed to create sysfs

The problem is that dummy_ptr == 0 is a valid value. So, change the logic
which checks if dummy_ptr was allocated.

At this point, atomisp now gives WARN_ON() in hmm_free() [2] on atomisp
reload by rmmod/insmod. Again, the check is wrong there.

So, change both checks for mmgr_EXCEPTION, which is the error value when
HMM allocation fails, and initialize dummy_ptr with such value.

[1] added on commit
    d9ab8395 ("media: atomisp: don't cause a warn if probe failed")
[2] added on commit
    b83cc378 ("atomisp: clean up the hmm init/cleanup indirections")

Link: https://lore.kernel.org/linux-media/20211017162337.44860-3-kitakar@gmail.comSigned-off-by: NTsuchiya Yuto <kitakar@gmail.com>
Co-developed-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

There is a BIT(nr) macro available in Linux Kernel,
which does the same thing.
Example: BIT(7) = (1UL << 7)

Link: https://lore.kernel.org/linux-media/20220206185232.21726-1-mosescb.dev@gmail.comSigned-off-by: NMoses Christopher Bollavarapu <mosescb.dev@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Don't populate the read-only array idx_map on the stack but
instead it static const. Also makes the object code a little smaller.

Link: https://lore.kernel.org/linux-media/20220109195129.46118-1-colin.i.king@gmail.comSigned-off-by: NColin Ian King <colin.i.king@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

The TrekStor SurfTab duo W1 10.1 has a hw bug where turning eldo2 back on
after having turned it off causes the CPLM3218 ambient-light-sensor on
the front camera sensor's I2C bus to crash, hanging the bus.

Add a DMI quirk table for systems on which to leave eldo2 on.

Note an alternative fix is to turn off the CPLM3218 ambient-light-sensor
as long as the camera sensor is being used, this is what Windows seems
to do as a workaround (based on analyzing the DSDT). But that is not
easy to do cleanly under Linux.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-10-hdegoede@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

On devices with 2 cameras and no _DSM / EFI-vars providing CsiPort
clock info, defaulting to CsiPort 0 obviously is wrong for 1 of the
2 cameras.

The Intel Cherry Trail (ISP2401) reference design combines:
 pmc_plt_clk_2 with CsiPort 0
 pmc_plt_clk_4 with CsiPort 1

The Intel Bay Trail (ISP2400) reference design combines:
 pmc_plt_clk_1 with CsiPort 0
 pmc_plt_clk_0 with CsiPort 1

Use this knowledge to set the default CsiPort value based on
the detected CLK for the sensor.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-9-hdegoede@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Fix axp_v1p8_on() turning ELDO2 off at the end again by removing the bogus
code which turns it off again after just having turned it on.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-8-hdegoede@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Testing on multiple tablet models has shown that Android always uses
1.6V for ELDO1, adjust our code to match.

This also matches with how ELDO1 is used in the DSDTs on these devices,
where for Cherry Trail (ISP2401) based devices ELDO1 is used for an
ACPI power-resource which is named "P16P".

Note on Bay Trail (ISP2400) based devices the power-resource is called
"P15P", which suggests that 1.5V might be a better value there.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-7-hdegoede@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

On devices with 2 sensors the 2 sensors may get probed simultaneously
and the v1p8 and v2p8 regulators are ususally shared between the
2 sensors.

This means that the probe() function of sensor 1 may end up calling
gmin_v1p8_ctrl(..., false) turning the regulator off while sensor 2's
probe() function still needs it to be on, causing the probe() of
sensor 2 to sometimes fail.

Fix this by adding an enable-count for both regulators and only
disabling them again when that goes to 0.

Note all this really should be converted to use the standard kernel
regulator framework, I have doing this on my long term TODO list,
this fix is only meant as a temporary workaround for the issue.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-6-hdegoede@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

The second write done in axp_regulator_set() must go to the ctrl_reg which
turns the various regulators on/off. This replaces the second write
writing the sel_reg, which sets the voltage for the regulator, for a
second time with a wrong value.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-5-hdegoede@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

There is no irci_stable_candrpv_0415_20150521_0458 build for the
isp2400/byt version of the atomisp2. There is however an
irci_stable_candrpv_0415_20150423_1753 version which according to:
https://github.com/intel/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/cam-041

Has the exact same fw ABI, so use that on the isp2400.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-4-hdegoede@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

IPS2400 is never defined, for ISP2401 builds ISP2401 gets defined and
for ISP2400 nothing gets defined, so any #ifdef ISP2400 checks should
be #ifndef ISP2401 checks instead.

Link: https://lore.kernel.org/linux-media/20220116215204.307649-3-hdegoede@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

IS_ISP2401 is a function like macro which is always defined, so it must
not be used together with #ifdef. #ifdef checks should check for
"ISP2401", not "IS_ISP2401".

Link: https://lore.kernel.org/linux-media/20220116215204.307649-2-hdegoede@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

If the driver reports that the hardware had an overflow, report this to
userspace. It would be nice to know when this happens, and not just get
a long space.

This change has been tested with lircd, ir-ctl, and ir-keytable.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

The driver report a reset event when the hardware reports and overflow.
There is no reason to have a generic "reset" event.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

These features have never been implemented by any lirc driver, including
staging or out of tree drivers. The ioctls for these feaures were removed
in commit d55f09ab ("[media] lirc.h: remove several unused ioctls").

So, we can safely remove them.
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Correct timing's fp/sync/bp value based on the information below.
It should be noticed that the calculation formula should be changed
per sync polarity.

The sequence of signal: sync - backporch - video data - frontporch

The following registers start counting from sync's rising edge:
1. VR090: frame edge's left and right
2. VR094: frame edge's top and bottom
3. VR09C: counting from sync's rising edge to falling edge

[Vertical timing]
            +--+     +-------------------+     +--+
            |  |     |     v i d e o     |     |  |
         +--+  +-----+                   +-----+  +---+
       vsync+--+
   frame_top+--------+
frame_bottom+----------------------------+

                  +-------------------+
                  |     v i d e o     |
      +--+  +-----+                   +-----+  +---+
         |  |                               |  |
         +--+                               +--+
       vsync+-------------------------------+
   frame_top+-----+
frame_bottom+-------------------------+

[Horizontal timing]
            +--+     +-------------------+     +--+
            |  |     |     v i d e o     |     |  |
         +--+  +-----+                   +-----+  +---+
       hsync+--+
  frame_left+--------+
 frame_right+----------------------------+

                  +-------------------+
                  |     v i d e o     |
      +--+  +-----+                   +-----+  +---+
         |  |                               |  |
         +--+                               +--+
       hsync+-------------------------------+
  frame_left+-----+
 frame_right+-------------------------+

Ex. 1920x1200@60 whose vsync polarity is negative
  VR098: c4d3efff, VR09C: 04cc001f
  v-total = 0x4D3 (VR098[27:16]) = 1235
  v-sync  = 0x4CC (VR09C[27:16]) = 1228

[hverkuil: drop unused variable mds]
Signed-off-by: NJammy Huang <jammy_huang@aspeedtech.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Use the bitfield macro FIELD_GET, and GENMASK to do the shift and mask in
one go for reg values.
Signed-off-by: NJammy Huang <jammy_huang@aspeedtech.com>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Previous reg-field, 0x98[11:0], stands for the period of the detected
hsync signal.
Use the correct reg, 0xa0, to get h-total in pixels.

Fixes: d2b4387f ("media: platform: Add Aspeed Video Engine driver")
Signed-off-by: NJammy Huang <jammy_huang@aspeedtech.com>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

In ast2500, engine will stop occasionally for 1360x768.

This is a bug which has been addressed, but the workaround is specific
for 1680 only. Here we make it more complete.
Signed-off-by: NJammy Huang <jammy_huang@aspeedtech.com>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

The new messages are listed as below:
1. jpeg header and capture buffer information
2. information for each irq
3. current capture mode, sync or direct-fetch
4. time consumed for each frame
5. input timing changed information

[hverkuil: use %pad for dma_addr_t to avoid compiler warnings]
Signed-off-by: NJammy Huang <jammy_huang@aspeedtech.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

The debug log level, 0~3, is controlled by module_param, debug.
The higher the value, the more the information.
  0: off
  1: info
  2: debug
  3: register operations
Signed-off-by: NJammy Huang <jammy_huang@aspeedtech.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Allow the dw9714 to control a regulator and adjust suspend() and resume()
to support both runtime and system pm.
Signed-off-by: NAngus Ainslie <angus@akkea.ca>
Signed-off-by: NMartin Kepplinger <martin.kepplinger@puri.sm>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

The module identifying will try to get the sub device data which
will be ready after sub device initialisation, so if try to use the
subdev data to deference the client will cause NULL pointer
dereference, this patch move the module identification after
v4l2_i2c_subdev_init() to fix this issue, it also fixes duplicate
module idendification.

Fixes: ada2c4f5 ("media: ov2740: support device probe in non-zero ACPI D state")
Signed-off-by: NBingbu Cao <bingbu.cao@intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Add Alain as sti maintainer for both drm/sti & cec/sti.
Add Raphaël as stm maintainer for drm/stm.
Signed-off-by: NPhilippe Cornu <philippe.cornu@foss.st.com>
Reviewed-by: NAlain Volmat <alain.volmat@foss.st.com>
Reviewed-by: NRaphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Update Benjamin Gaignard address and remove it from no more maintained
drivers.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@collabora.com>
Reviewed-by: NPhilippe Cornu <philippe.cornu@foss.st.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

The MAX9286 has sink pads, so it should implement .link_validate(). Do
so.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

drivers/media/i2c/ov5693.c:953:5-8: Unneeded variable: "ret". Return "0" on line 985

 Remove unneeded variable used to store return value.

Generated by: scripts/coccinelle/misc/returnvar.cocci

[Sakari Ailus: Improved subject]

CC: Daniel Scally <djrscally@gmail.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

drivers/media/i2c/ov5693.c:989:46-51: WARNING: conversion to bool not needed here
drivers/media/i2c/ov5693.c:991:46-51: WARNING: conversion to bool not needed here

 Remove unneeded conversion to bool

Semantic patch information:
 Relational and logical operators evaluate to bool,
 explicit conversion is overly verbose and unneeded.

Generated by: scripts/coccinelle/misc/boolconv.cocci

[Sakari Ailus: Improved subject]

CC: Daniel Scally <djrscally@gmail.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Add a v4l2 sub-device driver for the OmniVision ov08d10 image sensor.
This camera sensor is using the i2c bus for control and the
csi-2 bus for data.

The following features are supported:
- manual exposure and analog/digital gain control
- vblank/hblank control
- test pattern
- image vertical flip and horizontal mirror control
- supported resolution:
	- 3280x2460 at 30 FPS
	- 3264x2448 at 30 FPS
	- 1632x1224 at 30 FPS
- supported bayer order output:
	- SGRBG10 as default
	- SBGGR10 at flip mode
	- SRGGB10 at mirror mode
	- SGBRG10 at flip + mirror mode
Signed-off-by: NJimmy Su <jimmy.su@intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Add a V4L2 sub-device driver for Hynix Hi-847 image sensor.
This is a camera sensor using the I2C bus for control and the
CSI-2 bus for data.

This driver supports following features:
- manual exposure and analog/digital gain control support
- vblank/hblank control support
- test pattern support
- media controller support
- runtime PM support
- vflip/hflip control support
  - keep SGRBG10 Bayer order output
- support following resolutions:
  + 3264x2448 at 30FPS
  + 1632x1224 at 60FPS

[Sakari Ailus: Wrapped a few long lines.]
Signed-off-by: NShawn Tu <shawnx.tu@intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Fixed wrong indentation in set_selection callback.
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Don't pack the driver specific struct containing control pointers. This
lead to potential alignment issues when working with the pointers.
Reported-by: Nkernel test robot <lkp@intel.com>
Fixes: e43ccb0a ("media: i2c: Add support for the OV5648 image sensor")
Reviewed-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Pointers V4L2 pixelformat and dataformat fields in a few packed structs
are directly passed to printk family of functions. This could result in an
unaligned access albeit no such possibility appears to exist at the
moment i.e. this clang warning appears to be a false positive.

Address the warning by copying the pixelformat or dataformat value to a
local variable first.
Reported-by: Nkernel test robot <lkp@intel.com>
Fixes: e927e1e0 ("v4l: ioctl: Use %p4cc printk modifier to print FourCC codes")
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

According to v4l2-compliance utility, a video device which supports
V4L2_CAP_TIMEPERFRAME via .vidioc_s_parm() operation should also
support .vidioc_enum_frameintervals().  If the former is implemented
via a call to v4l2_s_parm_cap() which in turn calls a subdevice
.s_frame_interval() pad operation, the video device may want to
implement the latter by passing frame interval enumeration requests to
the subdevice .enum_frame_intervals() video operation.  If that
operation is not supported by the subdevice and failure is returned by
the video device, the compliance test issues a warning.

Implement the missing pad operation.  Enumerate frame intervals
possible to be set via pixel clock adjustment, as implemented by
.s_frame_interval(), but not exceeding a reasonable maximum of 1
second.

[Sakari Ailus: Rebased on mbus config pad op patches]
Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

According to subdevice interface specification found in V4L2 API
documentation, set format pad operations should not affect image
geometry set in preceding image processing steps. Unfortunately, that
requirement is not respected by the driver implementation of set format
as it was not the case when that code was still implementing a pair of
now obsolete .s_mbus_fmt() / .try_mbus_fmt() video operations before
they have been merged and reused as an implementation of .set_fmt() pad
operation by commit 717fd5b4 ("[media] v4l2: replace try_mbus_fmt
by set_fmt").

Exclude non-compliant crop rectangle adjustments from set format try,
as well as a call to .set_selection() from set format active processing
path, so only frame scaling is applied as needed and crop rectangle is
no longer modified.

[Sakari Ailus: Rebase on subdev state patches]

Fixes: 717fd5b4 ("[media] v4l2: replace try_mbus_fmt by set_fmt")
Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

Try requests are now only supported by format processing pad operations
implemented by the driver.  The driver selection API operations
currently respond to them with -EINVAL.  While that is correct, it
constraints video device drivers to not use subdevice cropping at all
while processing user requested active frame size, otherwise their set
try format results might differ from active.  As a consequence, we
can't fix set format pad operation as not to touch crop rectangle since
that would affect users not being able to set arbitrary frame sizes.
Moreover, without a working set try selection support we are not able
to use pad config crop rectangle as a reference while processing set
try format requests.

Implement missing try selection support.  Moreover, as it will be now
possible to maintain the pad config crop rectangle via selection API,
start using it instead of the active one as a reference while
processing set try format requests.

is_unscaled_ok() helper, now also called from set selection operation,
has been just moved up in the source file to avoid a prototype, with no
functional changes.

[Sakari Ailus: Rebase on subdev state patches]

Fixes: 717fd5b4 ("[media] v4l2: replace try_mbus_fmt by set_fmt")
Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

According to subdevice interface specification found in V4L2 API
documentation, set format pad operations should not affect image
geometry set in preceding image processing steps. Unfortunately, that
requirement is not respected by the driver implementation of set format
as it was not the case when that code was still implementing a pair of
now obsolete .s_mbus_fmt() / .try_mbus_fmt() video operations before
they have been merged and reused as an implementation of .set_fmt() pad
operation by commit 717fd5b4 ("[media] v4l2: replace try_mbus_fmt
by set_fmt").

In case of set format active processing path the issue can be fixed
easily by excluding a call to set active selection from that path. That
will effectively limit frame size processing to optimal frame scaling
against active crop rectangle without touching it.  Users can just call
set active selection themselves to obtain desired frame size.  However,
set format try processing path needs more work.

First of all, the driver should be extended with set try selection
support.  Lack of it constraints video device drivers to not use
subdevice cropping at all while processing user requested active frame
size, otherwise their set try format results might differ from active.

Next, set format try processing path should use pad config crop
rectangle as a reference, not the active one as it does now.  That
issue can be resolved easily as soon as set try selection support is
added to the driver so pad config crop rectangle can be maintained by
users via selection API.

Last, set format try processing path should give the same results as
active in respect to active vs. pad config crop rectangle geometry.
Both rectangles should be either not touched by set format (that's what
we are going to achieve) or modified the same way, otherwise users
won't be able to obtain equal results from both paths while iterating
through set format and set selection operations in order to obtain
desired frame size.

We can't begin with modifying set format pad operation as not to touch
crop rectangle since that depends on availability of set try selection
for symmetry.  Neither can we begin with adding set try selection since
that in turn depends on equal handling of active and pad config crop
rectangles by set format.  We can either implement all required
modifications in a single patch, or begin with fixing current set
format try processing path to appropriately handle pad config crop
rectangle.  This patch implements the latter approach as believed to
be more readable.

Move crop rectangle adjustments code from a helper (the former
implementation of .s_fmt(), now called from set format active
processing path) to the body of set format pad operation function
where it can be also used for processing try requests for symmetry with
active ones.  As the helper no longer processes frame geometry, only
frame format and half scaling, simplify its API accordingly and update
its users.

Moreover, extract code that applies crop rectangle hardware limits
(now a part of .set_selection() operation which is called from set
format active processing path) to a new helper and call that helper
from set format try processing path as well for symmetry with active.

[Sakari Ailus: Rebase on subdev state patches]

Fixes: 717fd5b4 ("[media] v4l2: replace try_mbus_fmt by set_fmt")
Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

To prepare for usage of the v4l2_fwnode_bus_* data structures to
describe bus configuration in the subdev .get_mbus_config() operation,
rename the structures with a v4l2_mbus_config_ prefix instead of
v4l2_fwnode_bus_, and move them to v4l2_mediabus.h.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

The .set_mbus_config() operation is deprecated, and nothing in the
kernel uses it. Drop it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>

The subdev .set_mbus_config() operation is deprecated. No code in the
kernel calls it, so drop its implementation from the ov6650 driver.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>