ARM64: tizen_bcmrpi3_defconfig: Disable FB_BCM2708

Disable FB driver because of using DRM driver.

Change-Id: I3bfb899c1e0c71a235952934ecaf749a1d90dd85
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM64: tizen_bcmrpi3_defconfig: increase CMA size to 256MiB

CMA size 5MiB or 64MiB are insufficient in tizen platform.

Change-Id: I83fa78d12af93361a87f0819b7b7abcd5b23fb2e
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM64: tizen_bcmrpi3_defconfig: Enable I2C_BCM2835

It needs to enable I2C_BCM2835 to bind HDMI from drm driver.

Change-Id: Ifcfbcb7bd3ac5a76c2cbbb1acdec45a48bee0201
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM64: tizen_bcmrpi3_defconfig: Enable DRM_VC4

Enable DRM_VC4 driver for tizen platform.

v2: DRM_VC4 need also to enable SND and SND_SOC configs.

Change-Id: I85568d78710d81ffa4cb1ec6373647e31962d1fe
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

arm: dts: Add support for drm vc4 on RPI3

Fixed the DT status to operate drm vc4.

Change-Id: I06aa84303e1a7c10647ace3799ec09d08ca045eb
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>

scripts: mkbootimg_rpi3.sh: Add u-boot and optee binaries to boot.img

In boot.img for tizen rpi3 image, u-boot and optee atf binaries
are required, so the files should be also installed in boot.img.
Add u-boot.img with optee os for atf and u-boot received from
download.tizen.org to boot.img.

Change-Id: I9778ea5c72697c3e7d0a534627fc65841bb792a1
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

scripts: mkbootimg_rpi3.sh: Add ARM64 kernel/dtb binary to boot.img

Add script to create boot.img having boot related files with fat
file system.

Change-Id: I7a03c11ef155dd3ad5fc935511ae764ef699c145
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
[sw0312.kim: remove not required kernel.img and add sync command before umount]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

scripts: Add mkbootimg_rpi3.sh

This script is to make boot.img that is fused at boot partition.

Change-Id: I383fc8dee8460176c825e4ea360d37d62072e6d6
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

tools: Add build script for ARM64 kernel of rpi3

This patch adds build script to build the ARM64 kernel for rpi3 board.

v2: Remove codes for creating fit style image from its

Change-Id: Ie7fa6dbf0b6838832b6a05326fa0ca27e3a7a812
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

packaging: Added '.gbs.conf' for partial build

Added gbs configuration file for enhanced building.
it makes gbs build faster than before.

https://source.tizen.org/documentation/reference/git-build-system/maintenance-models-supported-gbs

Change-Id: I79d57aa5eb49d0fbfa9a3744ec2acb032a274e5e
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

packaging: Disable UBSan build

UBSan build on kernel will cause build error because kernel has its own
sanitizer build options. So, dislable UBSan build from packaging spec.

Change-Id: Ife910a1e666c6fcafb7ef7bfcc072d88d8549d77
Signed-off-by: Denis Khalikov <d.khalikov@partner.samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

packaging: Turn off building with ASan

Turn off ASan for ASan sanitized firmware build

Change-Id: If786306821ff22e994efaba2b00dcabcc5eb8426
Signed-off-by: Gonzha Dmitriy Evgenevich <d.gonzha@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

packaging: Add kernel devel package

Kernel devel is used now to build out-of-tree kernel modules

Change-Id: I753edba92042561b50dc6c645f23659a65568976
Signed-off-by: Alexander Aksenov <a.aksenov@samsung.com>

packaging: Add spec file for rpi

This adds linux-rpi3.spec file for ARM64/armv7l rpm packaging.

Change-Id: I428fd32b69d082d935159476ace30c59c14b570d
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
[jh80.chung, sw0312.kim: Update kernel version to v4.14.y in spec file]
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
[sw0312.kim: Rename spec file without arch name]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

ARM64: tizen_bcmrpi3_defconfig: Enable SMACK

It needs to enable configs related with SMACK for booting tizen
platform.

Change-Id: If58917b798c1bee0c16cd5e430a065e40852b97b
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM64: tizen_bcmrpi3_defconfig: Sync with .config

Change-Id: I4e11df92a40b5f4c48891a6e772d898ff58de6e8
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

rpi3: config: Enable camera

Add configration to enable the Raspberry Pi Camera Module in config.txt file.

Change-Id: I092851a559ebab462babf8c176a190339285ef9d
Signed-off-by: Hackseung Lee <lhs@dignsys.com>

rpi3: enable jtag gpio option

Enable jtag gpio option at 1st bootloader level. The option
enables jtag gpio as alt4 mode as like following:
 GPIO22 - PIN13 - TRST
 GPIO23 - PIN16 - RTCK
 GPIO24 - PIN18 - TDO
 GPIO25 - PIN22 - TCK
 GPIO26 - PIN37 - TDI
 GPIO27 - PIN07 - TMS

This is requested for debugging secure world with jtag.

Change-Id: I0e25dd9ecf95fa003e56eb73eae5a668a1f6e3ba
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

rpi3: Enable ARM atf boot for rpi3

Boot rpi3 with u-boot-spl.bin which enables ARM atf.
Other booting options are set as like:
https://github.com/OP-TEE/build/blob/master/rpi3/firmware/config.txt

Change-Id: I0c0559c3f72f252c2cd2716b746b3c49b04fd63e
Signed-off-by: Rafal Tyminski <r.tyminski@partner.samsung.com>
[sw0312.kim: add more options and adjust commit-msg]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

rpi3: enable uart in bootcode.bin

The uart_2ndstage option directs bootcode.bin to print some diagnostics,
that indicate the code is running.

Change-Id: I34a68ae3b5c2467ee58fd81adf687ce367e1ed1c
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>

rpi3: config: change the 'kernel' parameter from Image to u-boot.bin

It needs to use the u-boot for supporting ramdisk booting.
Current release image is including the u-boot.bin that modified the ramdisk
booting sequence.

Change the kernel parameter from "Image" to "u-boot.bin" in config.txt.

Change-Id: Icc4ddce7e9f9befba59240d02ddd9af111c92a40
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

rpi3: config: Enable SPI interface

Uncomment spi=on in config.txt file to enable SPI interface.

Change-Id: I595628838fe9d769b243948e7118d36f4647e490
Signed-off-by: Hyeongsik Min <hyeongsik.min@samsung.com>

rpi3: config: Add loading of arm64 kernel binary & dtb

Change-Id: Ib553d02595e357751d0080d6aa713efe1ce9515d
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

rpi3: config: Add boot mode to select ARM or ARM64

Add configration to select boot mode in config.txt file, then we can
determine booting in 32-bit mode or 64-bit mode.

Change-Id: I2a5a1b11c4c83f514a7e8cc4c2f077b0b1d02cdc
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

rpi3: config: Enable serial

Add configration to enable serial in config.txt file, then we can serial
log from kernel or u-boot during booting.

Change-Id: Iebe3345b52cb2886daa0d8bdf1e15747dde2af39
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

rpi3: Add config.txt extracted from raspbian lite binary

We can get raspbian lite binary from
https://downloads.raspberrypi.org/raspbian_lite_latest

This file that is necessary for booting was extracted from first
partition of 2017-07-05-raspbian-jessie-lite.img.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

rpi3: Add boot files from github

We can get boot binaries that are necessary for booting from master
branch of https://github.com/raspberrypi/firmware.

The git base is the commit 83977fe3b6ef ("kernel: Bump to 4.14.98").

LICENCE.broadcom
bootcode.bin
fixup*.dat
start*.elf

TYPES of each firmware:
start.elf       / fixup.dat     - normal
start_x.elf     / fixup_x.dat   - with extra feature including camera (start_x=1 in config.txt)
start_cd.elf    / fixup_cd.dat  - cut-down to minimum gpu set 16M
start_db.elf    / fixup_db.dat  - debug (start_debug=1 in config.txt)

NOTE:
start_x=1 in config.txt should be specified when using the camera
module and it implies start_file=start_x.elf/fixup_file=fixup_x.dat.

Change-Id: I827b4cb94b3f8baa805938cd9f44947be7865f0e
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
[lhs: Add firmware files for camera]
Signed-off-by: Hackseung Lee <lhs@dignsys.com>
[sw0312.kim: update firmware files including extra, cutdown and debug features]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

overlays: rpi-ft5406: Fix boolean parameters

An improvement in the automated testing of overlays revealed
these invalid boolean parameter declarations.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

dtoverlays: Fixup imx219 and imx477 overlays due to parsing failures

imx219 overlay failed to detect as CSI2 as it was missing any
of the CSI2 properties on the Unicam end of the configuration.
Clean up imx477 as well to include all the relevant properties.

Fixes: "dt/dtoverlays: Fix up base DT and overlays for updated Unicam driver"

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

irqchip/bcm2835: Quiesce IRQs left enabled by bootloader

[ Upstream commit bd59b343a9c902c522f006e6d71080f4893bbf42 ]

Per the spec, the BCM2835's IRQs are all disabled when coming out of
power-on reset.  Its IRQ driver assumes that's still the case when the
kernel boots and does not perform any initialization of the registers.
However the Raspberry Pi Foundation's bootloader leaves the USB
interrupt enabled when handing over control to the kernel.

Quiesce IRQs and the FIQ if they were left enabled and log a message to
let users know that they should update the bootloader once a fixed
version is released.

If the USB interrupt is not quiesced and the USB driver later on claims
the FIQ (as it does on the Raspberry Pi Foundation's downstream kernel),
interrupt latency for all other peripherals increases and occasional
lockups occur.  That's because both the FIQ and the normal USB interrupt
fire simultaneously:

On a multicore Raspberry Pi, if normal interrupts are routed to CPU 0
and the FIQ to CPU 1 (hardcoded in the Foundation's kernel), then a USB
interrupt causes CPU 0 to spin in bcm2836_chained_handle_irq() until the
FIQ on CPU 1 has cleared it.  Other peripherals' interrupts are starved
as long.  I've seen CPU 0 blocked for up to 2.9 msec.  eMMC throughput
on a Compute Module 3 irregularly dips to 23.0 MB/s without this commit
but remains relatively constant at 23.5 MB/s with this commit.

The lockups occur when CPU 0 receives a USB interrupt while holding a
lock which CPU 1 is trying to acquire while the FIQ is temporarily
disabled on CPU 1.  At best users get RCU CPU stall warnings, but most
of the time the system just freezes.

Fixes: 89214f009c1d ("ARM: bcm2835: add interrupt controller driver")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/f97868ba4e9b86ddad71f44ec9d8b3b7d8daa1ea.1582618537.git.lukas@wunner.de

drm/vc4: FKMS: Put includes in alphabetical order, and use <> instead of ""

Reorder the includes, and use the system include paths rather than
local ones

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

dt: Use rpi-firmware-kms-2711 on 2711 platforms

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

drm/vc4: FKMS Block modes with odd horizontal timing values on Pi4

Pi4 HDMI pipeline is 2 pixels/clock and can not produce timings
that have odd values for active pixels, front porch, sync width,
or back porch.
Detect these modes and block them within fkms.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

drm/vc4: Make FKMS max refresh rate a module parameter

Some people want to use the high refresh rate modes for 1080p100
and 1080p120, but they're currently filtered out as generally
they don't add anything.

Make the filter threshold a module parameter so that it can be
adjusted.

https://github.com/raspberrypi/linux/issues/3677

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

overlays: Fix miniuart-bt "krnbt" parameter

Although superficially appealing, an overlay parameter that targets a
label in the base DTB is not currently supported. Instead it is
necessary to create a fragment targeting the label which is patched
by the parameter.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

media: bcm2835-unicam: Add support for unpacked 14bit Bayer formats

Now that the 14bit non-packed Bayer formats are defined, add them
into the supported formats lookup table.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: bcm2835-unicam: Add support for 14bit mono sources

Now that V4L2_PIX_FMT_Y14 and V4L2_PIX_FMT_Y14P are defined,
allow passing 14bit mono data through the peripheral.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: bcm2835-unicam: Add support for 12bit mono packed format

Now that V4L2_PIX_FMT_Y12P is defined, allow passing raw 12bit
mono packed data through the peripheral.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

staging: vc04_services: codec: Add support for 14bit Bayer formats

Now that the 14bit Bayer formats have been defined within
V4L2, add them to the lookup table of V4L2/MMAL formats.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

staging: vc04_services: codec: Add support for mono formats

The firmware ISP component now allows for processing of mono
images, so add those formats for use by the simple ISP device.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

staging: vc04_services: codec: Increase the number of supported formats expected

The ISP now supports 47 different input formats, therefore increase the
array size for the number expected.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

staging: vc04_services: isp: Increase the number of supported formats expected

The ISP now supports 47 different input formats, therefore increase the
array size for the number expected.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

staging: vc04_services: isp: Add monochrome image formats

Adds support for monochrome image formats in the various
MIPI packings.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

staging: vc04_services: isp: Add support for 14bit Bayer

The only thing missing was a set of defines, therefore add them in.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: Add a pixel format for MIPI packed 14bit luma only.

This is the format used by monochrome 14bit image sensors.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: Add a pixel format for MIPI packed 12bit luma only.

This is the format used by monochrome 12bit image sensors.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: v4l: Add 1X14 14-bit greyscale media bus code definition

Commit 573a750813459725c6f6fc4bc5779da1fe03238a upstream.

The code is called MEDIA_BUS_FMT_Y14_1X14 and behaves just like
MEDIA_BUS_FMT_Y12_1X12 with two more bits.

Signed-off-by: Daniel Glöckner <dg@emlix.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l: Add 14-bit raw greyscale pixel format

Commit ae9753a04cfc8e41262605875e531b6ea5e3d0ac upstream.

The new format is called V4L2_PIX_FMT_Y14. Like V4L2_PIX_FMT_Y10 and
V4L2_PIX_FMT_Y12 it is stored in two bytes per pixel but has only two
unused bits at the top.

Signed-off-by: Daniel Glöckner <dg@emlix.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l: Add 14-bit raw bayer pixel formats

Commit d12127ed0e18192491c2508caae45bb19c2f8fdd upstream.

The formats added by this patch are:

V4L2_PIX_FMT_SBGGR14
V4L2_PIX_FMT_SGBRG14
V4L2_PIX_FMT_SGRBG14
V4L2_PIX_FMT_SRGGB14

Signed-off-by: Jouni Ukkonen <jouni.ukkonen@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
[dg@emlix.com: rebased onto current media_tree]
Signed-off-by: Daniel Glöckner <dg@emlix.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

serial: 8250: bcm2835aux - defer if clock is zero

See: https://github.com/raspberrypi/linux/issues/3700

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

drm/vc4: Allow interlaced HDMI modes from FKMS.

Having checked the firmware handling for interlaced modes,
it appears to be possible to support interlaced modes on
HDMI without adverse side effects, so do so.

https://github.com/raspberrypi/linux/issues/3694

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

ARM: dts: Add Bluetooth nodes for Raspberry Pi

Add device tree nodes for Bluetooth on supported Raspberry Pi boards.
It's disabled by default and can be enabled by `krnbt=on` dtparam. It's
an alternative way of configuring Bluetooth, as compared to hciattach or
btattach. When the dtparam is enabled, the Bluetooth driver is probed
automatically and doesn't require any additional bring-up scripts.

Note that Raspberry Pi 3 B rev 1.2 doesn't have the required hardware
flow control pins of UART0 connected to the Bluetooth module, so the
user should decrease the baudrate by passing `krnbt_baudrate=921600`
dtparam to make it more stable. It resembles the behavior of the btuart
script from Raspbian.

The miniuart-bt overlay was modified to support Bluetooth probing with
device tree, too. It's disabled by default and can be enabled by
`krnbt=on` parameter of the miniuart-bt overlay.

Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>

config: Set CONFIG_SERIAL_DEV_CTRL_TTYPORT=y in Raspberry Pi defconfigs

The next patch adds a device tree overlay for Bluetooth. The Bluetooth
device node is a child of uart0 (pl011). The children of pl011 are not
registered as platform devices by of_platform_bus_create, because they
fall into `of_device_is_compatible(bus, "arm,primecell")` check. These
children are registered by of_serdev_register_devices, called through
this chain of calls:

  - uart_add_one_port (drivers/tty/serial/amba-pl011.c)
  - tty_port_register_device_attr_serdev
  - serdev_tty_port_register
  - serdev_controller_add
  - of_serdev_register_devices

serdev_tty_port_register depends on CONFIG_SERIAL_DEV_CTRL_TTYPORT,
which in turn depends on CONFIG_SERIAL_DEV_BUS=y. This patch modifies
the defconfigs of Raspberry Pi devices to set these options and allow
to bind drivers to subnodes of UART devices that can be added by device
tree overlays.

Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>

uapi: bcm2835-isp: Fixups for bcm2835-isp uapi structures

Rename pad_[] to padding[].
struct bcm2835_isp_rational.den is now unsigned.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

staging: vc04_services: isp: Reorder operations during device probe

Register the video node at the end of the probe, swapping order with
registering the controls.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

staging: vc04_services: isp: Fixup g/s_selection implementation

Add V4L2_SEL_TGT_CROP_DEFAULT and V4L2_SEL_TGT_CROP_BOUND targets.
Disable the appropriate ioctls for the meta capture nodes - this now
passes v4l2-compliance tests.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

vc4_hdmi: Set HD_CTL_WHOLSMP and HD_CTL_CHALIGN_SET

Symptom is random switching of speakers when using multichannel.

Repeatedly running speakertest -c8 occasionally starts with
channels jumbled. This is fixed with HD_CTL_WHOLSMP.

The other bit looks beneficial and apears harmless in testing so
I'd suggest adding it too.

Documentation says: HD_CTL_WHILSMP_SET
Wait for whole sample. When this bit is set MAI transmit will start
only when there is at least one whole sample available in the fifo.

Documentation says: HD_CTL_CHALIGN_SET
Channel Align When Overflow. This bit is used to realign the audio channels in case of an overflow.
If this bit is set, after the detection of an overflow, equal amount of dummy words to the missing
words will be written to fifo, filling up the broken sample and maintaining alignment.

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

defconfig: Add Sony IMX290 image sensor driver to all Pi defconfigs

Adds the mainline IMX290 sensor driver (with extra features) to
the default configs.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

dtoverlays: Add an overlay for the Sony IMX290 image sensor

Adds an overlay to configure the IMX290 image sensor.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: i2c: imx290: Switch set_hmax to use imx290_write_buffered_reg

imx290_set_hmax was using two independent writes to set up hmax,
when all other multi-register writes were using imx290_write_buffered_reg
which claims the group hold first.

Switch imx290_set_hmax to using imx290_write_buffered_reg too.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media : i2c: imx290: Add support for the mono sensor variant.

The IMX290 module is available as either mono or colour (Bayer).

Update the driver so that it can advertise the correct mono
formats instead of the colour ones.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: dt-bindings: media: i2c: Add mono version to IMX290 bindings

The IMX290 module is available as either monochrome or colour and
the variant is not detectable at runtime.

Add a new compatible string for the monochrome version.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: i2c: imx290: Add H and V flip controls

The sensor supports horizontal and vertical flips, so support them
through V4L2_CID_HFLIP and V4L2_CID_VFLIP.

This sensor does NOT change the Bayer order when changing the
direction of readout, therefore no special handling is required for
that.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: i2c: imx290: Add exposure control to the driver.

Adds support for V4L2_CID_EXPOSURE so that userspace can control
the sensor exposure time.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: i2c: imx290: Add support for V4L2_CID_VBLANK

In order to calculate framerate and durations userspace needs
the vertical blanking information. This can be configurable,
and indeed the datasheet lists different values for VBLANK for
the 1080p and 720p modes.

Add the new control, and adopt the datasheet values for each mode.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: i2c: imx290: Convert HMAX setting into V4L2_CID_HBLANK

Userspace needs to know HBLANK if it is to work out exposure times
and frame rates, therefore convert it to map onto V4L2_CID_HBLANK

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: i2c: imx290: Correct range for V4L2_CID_GAIN to 0-238

The datasheet lists the gain as being 0.0 to 72.0dB in 0.3dB steps, which
makes 238 steps total.
Correct the 0-72 range defined in the driver.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: i2c: imx290: Add support for 74.25MHz clock

The existing driver only supported a clock of 37.125MHz, but the
sensor also supports 74.25MHz.

Add the relevant register modifications to support this alternate
clock frequency.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: i2c: imx290: set bus_type before calling v4l2_fwnode_endpoint_alloc_parse()

Commit a270675875829b6d46eb9e38960fd6019555ebb8 upstream.

The bus_type field of v4l2_fwnode_endpoint structure passed as the argument
to v4l2_fwnode_endpoint_alloc_parse() function must be initiaized.
Set it to V4L2_MBUS_CSI2_DPHY, and check for -ENXIO which is returned
when the requested media bus type doesn't match the fwnode.

Also remove v4l2_fwnode_endpoint field from struct imx290 as it is only
needed in the probe function: use the local variable for this purpose.

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

media: i2c: imx290: Move the settle time delay out of loop

Commit 6544af9b04b4484867c234ba0be1b5008e4a14ee upstream.

The 10ms settle time is needed only at the end of all consecutive
register writes. So move the delay to outside of the for loop of
imx290_set_register_array().

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: imx290: Add support to enumerate all frame sizes

Commit 3b867fb641d884b714fba390ae866714ba475f29 upstream.

Add support to enumerate all frame sizes supported by IMX290. This is
required for using with userspace tools such as libcamera.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: imx290: Add RAW12 mode support

Commit c566ac01ceaa02450acc155201772c0623530e76 upstream.

IMX290 is capable of outputting frames in both Raw Bayer (packed) 10 and
12 bit formats. Since the driver already supports RAW10 mode, let's add
the missing RAW12 mode as well.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: imx290: Add support for test pattern generation

Commit a58df1f9e4885eaf3d0663574a217e513821a9f0 upstream.

Add support for generating following test patterns by IMX290:

* Sequence Pattern 1
* Horizontal Color-bar Chart
* Vertical Color-bar Chart
* Sequence Pattern 2
* Gradation Pattern 1
* Gradation Pattern 2
* 000/555h Toggle Pattern

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: imx290: Add configurable link frequency and pixel rate

Commit 98e0500eadb772e1be32d8e369fcc3b7bcac93ed upstream.

IMX290 operates with multiple link frequency and pixel rate combinations.
The initial driver used a single setting for both but since we now have
the lane count support in place, let's add configurable link frequency
and pixel rate.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: imx290: Add support for 2 data lanes

Commit 97589ad61c730e0f486635c6c19fa25ab8e8f29d upstream.

The IMX290 sensor can output frames with 2/4 CSI2 data lanes. This commit
adds support for 2 lane mode in addition to the 4 lane and also
configuring the data lane settings in the driver based on system
configuration.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: imx290: fix reset GPIO pin handling

Commit 3909a92d7df622b41b9ceeeea694e641cad7667b upstream.

According to https://www.kernel.org/doc/Documentation/gpio/consumer.txt,

- all of the gpiod_set_value_xxx() functions operate with the *logical*
value. So in imx290_power_on() the reset signal should be cleared
(de-asserted) with gpiod_set_value_cansleep(imx290->rst_gpio, 0), and in
imx290_power_off() the value of 1 must be used to apply/assert the reset
to the sensor. In the device tree the reset pin is described as
GPIO_ACTIVE_LOW, and gpiod_set_value_xxx() functions take this into
account,

- when devm_gpiod_get_optional() is called with GPIOD_ASIS, the GPIO is
not initialized, and the direction must be set later; using a GPIO
without setting its direction first is illegal and will result in undefined
behavior. Fix this by using GPIOD_OUT_HIGH instead of GPIOD_ASIS (this
asserts the reset signal to the sensor initially).

Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: imx290: fix the order of the args in SET_RUNTIME_PM_OPS()

Commit 8d2d1bedb1b9af3e0c039a4444858da7b6da71f8 upstream.

The macro is defined as SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn),
so imx290_power_off must be the 1st arg, and imx290_power_on the 2nd.

Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: imx290: set the format before VIDIOC_SUBDEV_G_FMT is called

Commit d46cfdc86c30d5ec768924f0b1e2683c8d20b671 upstream.

With the current driver 'media-ctl -p' issued right after the imx290 driver
is loaded prints:
pad0: Source
             [fmt:unknown/0x0]

The format value of zero is due to the current_format field of the imx290
struct not being initialized yet.

As imx290_entity_init_cfg() calls imx290_set_fmt(), the current_mode field
is also initialized, so the line which set current_mode to a default value
in driver's probe() function is no longer needed.

Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: i2c: Add IMX290 CMOS image sensor driver

Commit 828dbc299278065b634e913d2700d254a3224853 upstream.

Add driver for Sony IMX290 CMOS image sensor driver. The driver only
supports I2C interface for programming and MIPI CSI-2 for sensor output.

[Sakari Ailus: Rewrapped a few lines over 80 chars a little.]

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: dt-bindings: media: i2c: Add IMX290 CMOS sensor binding

Commit 8a97a4676f8b1badcd9cfbed2b081342847bb1b1 upstream.

Add devicetree binding for IMX290 CMOS image sensor. Let's also
add MAINTAINERS entry for the binding and driver.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.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+samsung@kernel.org>

media: bcm2835-unicam: Avoid gcc warning over {0} on endpoint

Older gcc versions object to = { 0 } initialisation if the first
elemtn in the structure is a substructure.

Use = { } to avoid this compiler warning.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

dt/dtoverlays: Fix up base DT and overlays for updated Unicam driver

The upstreamed Unicam driver uses a dt property to denote how many
lanes are supported by the receiver peripheral, independent of
the number of lanes that the sensor wants to use. It also doesn't
check the remote endpoint config for the number of lanes as that
isn't the accepted way of doing things.

Update the base DT for the brcm,num-data-lanes property, and the
overlays to define the desired number of lanes at both ends of
the link.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: bcm2835-unicam: change minimum number of vb2_queue buffers to 1

Since the unicam driver was modified to write to a dummy buffer when no
user-supplied buffer is available, it can now write to and return a
buffer even when there's only a single one. Enable this by changing the
min_buffers_needed in the vb2_queue; it will be useful for enabling
still captures without allocating more memory than absolutely necessary.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

media: bcm2835-unicam: Retain packing information on G_FMT

The change to retrieve the pixel format always on g_fmt didn't
check whether the native or unpacked version of the format
had been requested, and always returned the packed one.
Correct this so that the packing setting is retained whereever
possible.

Fixes "9d59e89 media: bcm2835-unicam: Re-fetch mbus code from subdev
on a g_fmt call"

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: bcm2835-unicam: Fixup review comments from Hans.

Updates the driver based on the upstream review comments from
Hans Verkuil at https://patchwork.linuxtv.org/patch/63531/

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: bcm2835: unicam: Fix uninitialized warning

Signed-off-by: Jacko Dirks <jdirks.linuxdev@gmail.com>

media: bcm2835-unicam: Always service interrupts

From when bringing up the driver, there was a check in the isr
to ignore interrupts (claiming them handled) should the driver
not be streaming.

The VPU now will not register a camera driver if it finds a
CSI2 node enabled in device tree, therefore this flawed check is
redundant.

https://github.com/raspberrypi/linux/issues/3602

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: bcm2835-unicam: Add support for get_mbus_config to set num lanes

Use the get_mbus_config pad subdev call to allow a source to use
fewer than the number of CSI2 lanes defined in device tree.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: bcm2835-unicam: Driver for CCP2/CSI2 camera interface

Add a driver for the Unicam camera receiver block on BCM283x processors.
Compared to the bcm2835-camera driver present in staging, this driver
handles the Unicam block only (CSI-2 receiver), and doesn't depend on
the VC4 firmware running on the VPU.

The commit is made up of a series of changes cherry-picked from the
rpi-5.4.y branch of https://github.com/raspberrypi/linux/ with
additional enhancements, forward-ported to the mainline kernel.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reported-by: kbuild test robot <lkp@intel.com>

include: media: Add vfl_devnode_type of VFL_TYPE_VIDEO

Upsstream are renaming VFL_TYPE_GRABBER to VFL_TYPE_VIDEO.
To make backporting the upstream Unicam driver easier, add an
extra enum entry (same as VFL_TYPE_GRABBER) to match that.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

drivers: media: Remove the downstream version of bcm2835-unicam

About to be replaced by the upstream version.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

media: rcar-csi2: Negotiate data lanes number

Upstream https://patchwork.linuxtv.org/patch/64675/

Use the newly introduced get_mbus_config() subdevice pad operation to
retrieve the remote subdevice MIPI CSI-2 bus configuration and configure
the number of active data lanes accordingly.

In order to be able to call the remote subdevice operation cache the
index of the remote pad connected to the single CSI-2 input port.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

media: i2c: adv748x: Implement get_mbus_config

Upstream https://patchwork.linuxtv.org/patch/64676/

Implement the newly introduced get_mbus_config operation to report the
number of currently used data lanes on the MIPI CSI-2 interface.

Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

media: i2c: adv748x: Adjust TXA data lanes number

Upstream https://patchwork.linuxtv.org/patch/64673/

When outputting SD-Core output through the TXA MIPI CSI-2 interface,
the number of enabled data lanes should be reduced in order to guarantee
that the two video formats produced by the SD-Core (480i and 576i)
generate a MIPI CSI-2 link clock frequency compatible with the MIPI D-PHY
specifications.

Limit the number of enabled data lanes to 2, which is guaranteed to
support 480i and 576i formats.

Cache the number of enabled data lanes to be able to report it through
the new get_mbus_config operation.

Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

staging: media: imx: Update TODO entry

Upstream https://patchwork.linuxtv.org/patch/64672/

Update the TODO entry that mentioned a potential use case for the now
removed g_mbus_config video operation.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

media: v4l2-subdev: Remove [s|g]_mbus_config video ops

Upstream https://patchwork.linuxtv.org/patch/64670/

With all sensor and platform drivers now converted to use the new
get_mbus_config and set_mbus_config pad operations, remove the
deprecated video operations g_mbus_config and s_mbus_config.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

media: pxa_camera: Use the new set_mbus_config op

Upstream https://patchwork.linuxtv.org/patch/64671/

Move the PXA camera driver to use the new set_mbus_config pad operation.
For this platform the change is not only cosmetic, as the pxa driver is
currently the only driver in mainline to make use of the g_mbus_config
and s_mbus_config video operations.

The existing driver semantic is the following:
- Collect all supported mbus config flags from the remote end
- Match them with the supported PXA mbus configuration flags
- If the remote subdevice allows multiple options for for VSYNC, HSYNC
  and PCLK polarity, use platform data requested settings

The semantic of the new get_mbus_config and set_mbus_config differs from
the corresponding video ops, particularly in the fact get_mbus_config
reports the current mbus configuration and not the set of supported
configuration options, with set_mbus_config always reporting the actual
mbus configuration applied to the remote subdevice.

Adapt the driver to perform the following
- Set the remote subdevice mbus configuration according to the PXA
  platform data preferences.
- If the applied configuration differs from the requested one (i.e. the
  remote subdevice does not allow changing one setting) make sure that
  - The remote end does not claim for DATA_ACTIVE_LOW, which seems not
    supported by the platform
  - The bus mastering roles match

While at there remove a few checks performed on the media bus
configuration at get_format() time as they do not belong there.

Compile-tested only.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

media: i2c: ov6650: Use new [get|set]_mbus_config ops

Upstream https://patchwork.linuxtv.org/patch/64674/

Use the new get_mbus_config and set_mbus_config pad operations in place
of the video operations currently in use.

Compared to other drivers where the same conversion has been performed,
ov6650 proved to be a bit more tricky, as the existing g_mbus_config
implementation did not report the currently applied configuration but
the set of all possible configuration options.

Adapt the driver to support the semantic of the two newly introduced
operations:
- get_mbus_config reports the current media bus configuration
- set_mbus_config applies only changes explicitly requested and updates
  the provided cfg parameter to report what has actually been applied to
  the hardware.

Compile-tested only.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

media: i2c: Use the new get_mbus_config pad op

Upstream https://patchwork.linuxtv.org/patch/64669/

Move the existing users of the g_mbus_config video operation to use the
newly introduced get_mbus_config pad operations.

All the ported drivers report a static media bus configuration and do no
support s_mbus_config so the operation implementation has not changed.

Bridge drivers needs to call the new pad operation and will receive an
-ENOICTLCMD when calling the old g_mbus_config video operation

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

media: v4l2-subdev: Introduce [get|set]_mbus_config pad ops

Upstream https://patchwork.linuxtv.org/patch/64669/

Introduce two new pad operations to allow retrieving and configuring the
media bus parameters on a subdevice pad.

The newly introduced operations aims to replace the s/g_mbus_config video
operations, which have been on their way for deprecation since a long
time.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>