ASoC: ma120x0p: Remove unnecessary const specifier

Clang warns:

  sound/soc/codecs/ma120x0p.c:891:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
  static const SOC_VALUE_ENUM_SINGLE_DECL(pwr_mode_ctrl,
               ^
  ./include/sound/soc.h:362:2: note: expanded from macro 'SOC_VALUE_ENUM_SINGLE_DECL'
          SOC_VALUE_ENUM_DOUBLE_DECL(name, xreg, xshift, xshift, xmask, xtexts, xvalues)
          ^
  ./include/sound/soc.h:359:2: note: expanded from macro 'SOC_VALUE_ENUM_DOUBLE_DECL'
          const struct soc_enum name = SOC_VALUE_ENUM_DOUBLE(xreg, xshift_l, xshift_r, xmask, \
          ^
  1 warning generated.

SOC_VALUE_ENUM_DOUBLE_DECL already has a const specifier. Remove the duplicate
const to clean up the warning.

Fixes: 42444979e710 ("Add support for all the downstream rpi sound card drivers")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>

misc: bcm2835_smi: Use proper enum types for dma_{,un}map_single()

Clang warns:

  drivers/misc/bcm2835_smi.c:692:4: warning: implicit conversion from enumeration type 'enum dma_transfer_direction' to different enumeration type 'enum dma_data_direction' [-Wenum-conversion]
                          DMA_MEM_TO_DEV);
                          ^~~~~~~~~~~~~~~
  ./include/linux/dma-mapping.h:406:66: note: expanded from macro 'dma_map_single'
  #define dma_map_single(d, a, s, r) dma_map_single_attrs(d, a, s, r, 0)
                                     ~~~~~~~~~~~~~~~~~~~~          ^
  drivers/misc/bcm2835_smi.c:705:35: warning: implicit conversion from enumeration type 'enum dma_transfer_direction' to different enumeration type 'enum dma_data_direction' [-Wenum-conversion]
                          (inst->dev, phy_addr, n_bytes, DMA_MEM_TO_DEV);
                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
  ./include/linux/dma-mapping.h:407:70: note: expanded from macro 'dma_unmap_single'
  #define dma_unmap_single(d, a, s, r) dma_unmap_single_attrs(d, a, s, r, 0)
                                       ~~~~~~~~~~~~~~~~~~~~~~          ^
  drivers/misc/bcm2835_smi.c:751:12: warning: implicit conversion from enumeration type 'enum dma_transfer_direction' to different enumeration type 'enum dma_data_direction' [-Wenum-conversion]
                                                       DMA_DEV_TO_MEM);
                                                       ^~~~~~~~~~~~~~~
  ./include/linux/dma-mapping.h:406:66: note: expanded from macro 'dma_map_single'
  #define dma_map_single(d, a, s, r) dma_map_single_attrs(d, a, s, r, 0)
                                     ~~~~~~~~~~~~~~~~~~~~          ^
  drivers/misc/bcm2835_smi.c:761:50: warning: implicit conversion from enumeration type 'enum dma_transfer_direction' to different enumeration type 'enum dma_data_direction' [-Wenum-conversion]
                  dma_unmap_single(inst->dev, phy_addr, n_bytes, DMA_DEV_TO_MEM);
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
  ./include/linux/dma-mapping.h:407:70: note: expanded from macro 'dma_unmap_single'
  #define dma_unmap_single(d, a, s, r) dma_unmap_single_attrs(d, a, s, r, 0)
                                       ~~~~~~~~~~~~~~~~~~~~~~          ^
  4 warnings generated.

Use the proper enumerated type to clear up the warning. There is not
actually a bug here because the enumerated types have the same integer
value:

DMA_MEM_TO_DEV = DMA_TO_DEVICE = 1
DMA_DEV_TO_MEM = DMA_FROM_DEVICE = 2

Fixes: 93254d0f7bc8 ("Add SMI driver")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>

overlays: Add MAX30102 HR to i2c-sensor overlay

Add support for the MAX30102 heart rate and blood oxygen sensor to the
i2c-sensor overlay.

See: https://github.com/raspberrypi/linux/pull/4535

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

configs: Add CONFIG_MAX30102=m

See: https://github.com/raspberrypi/linux/pull/4535

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

drm/vc4_hdmi: Add Broadcast RGB property to allow override of RGB range

Copy Intel's "Broadcast RGB" property semantics to add manual override
of the HDMI pixel range for monitors that don't abide by the content
of the AVI Infoframe.

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

media: i2c: imx219: Correct the minimum vblanking value

The datasheet for this sensor documents the minimum vblanking as being
32 lines. It does fix some problems with occasional black lines at the
bottom of images (tested on Raspberry Pi).

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

update rpi-display-overlay.dts pins for 5.10+

backlight has been turned off

ARM: dts: BCM2711 AON_INTR2 generates IRQ edges

THe AON_INTR2 controller manages the HDMI interrupts, combining them
into a single interrupt passed to the GIC. bcm2711.dtsi declares the
interrupt as being IRQ_TYPE_LEVEL_HIGH, but it should be
IRQ_TYPE_EDGE_RISING. Most of the time the distinction shouldn't
matter, but there is a small possibility of losing interrupts unless
it is corrected.

See: http://lists.infradead.org/pipermail/linux-arm-kernel/2022-January/710292.html

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

dtoverlays: Correct [h|v]sync_invert config in vc4-kms-dpi-generic

Both the base node and override set these parameters to 0,
so it made no difference. The base node should have been 1.

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

dtoverlays: Add pwm backlight option to vc4-kms-dpi-generic

Adds the option of a PWM controlled backlight on a generic
DPI display.

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

defconfig: Add BACKLIGHT_PWM to bcm2709 and bcmrpi defconfigs

BACKLIGHT_PWM can be used with DPI displays, so add it to the
defconfig.

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

drm/vc4: dsi: Correct max divider to 255 (not 7)

The integer divider from parent PLL to DSI clock is capable
of going up to /255, not just /7 that the driver was trying.
This allows for slower link frequencies on the DSI bus where
the resolution permits.

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

arm: Remove spurious .fnend directive

...a.k.a. Fix annoying build error

Some toolchains rightly object to the fact that once the acros are
expanded this results in multiple ".fnend"s without ".fnstart"s.

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

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

drivers: bcm2835_unicam: Disable trigger mode operation

On a Pi3 B/B+ platform the imx219 sensor frequently generates a single corrupt
frame when the sensor first starts. This can either be a missing line, or
invalid samples within the line. This only occurrs using the Unicam kernel
driver.

Disabling trigger mode elimiates this corruption. Since trigger mode is a
legacy feature copied from the firmware driver and not expected to be needed,
remove it. Tested on the Raspberry Pi cameras and shows no ill effects.

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

dtoverlays: Add option for PoE HAT to use Linux I2C instead of FW.

Adds parameter "i2c" to use the PoE HAT I2C MFD driver to instantiate
the PoE HAT drivers, instead of being off the firmware.

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

defconfigs: Add MFD_RASPBERRYPI_POE_HAT to Pi defconfigs.

Required for PoE HAT when driven from Linux over I2C.

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

power: rpi-poe: Add option of being created by MFD or FW

The firmware can only use I2C0 if the kernel isn't, therefore
with libcamera and DRM using it the PoE HAT fan control needs
to move to the kernel.

Add the option for the driver to be created by the PoE HAT core
MFD driver, and use the I2C regmap that provides to control fan
functions.

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

power: rpi-poe: Drop CURRENT_AVG as it is not hardware averaged

As documented the _AVG parameters are meant to be hardware
averaged, but the implementation for the PoE+ HAT was done in
software in the firmware.

Drop the property.

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

pwm: raspberrypi-poe: Add option of being created by MFD or FW

The firmware can only use I2C0 if the kernel isn't, therefore
with libcamera and DRM using it the PoE HAT fan control needs
to move to the kernel.

Add the option for the driver to be created by the PoE HAT core
MFD driver, and use the I2C regmap that provides to control fan
functions.

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

mfd: simple-mfd-i2c: Add configuration for RPi POE HAT

The Raspbery Pi PoE+ HAT exposes a fan controller and power
supply status reporting via a single I2C address.

Create an MFD device that allows loading of the relevant
sub-drivers, with a shared I2C regmap.

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

ARM: dts: Remove VL805 USB node from CM4 dts

Neither the CM4 module nor the CM4IO board have a VL805 USB3
controller. The existing "usb@0,0" node is a hangover from the
Pi 4 dts; delete it. An up-to-date firmware will automatically load
the vl805 overlay on CM4s with VL805=1 in the EEPROM config, ensuring
that the firmware is notified of any PCIe reset.

See: https://forums.raspberrypi.com/viewtopic.php?t=326088

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

drm/vc4: hdmi: Fix clock value used for validating hdmi modes

We are using mode->crt_clock here which is filled by drm_mode_set_crtcinfo()
which is called right after .mode_valid.

Use mode->clock which is valid here.

Fixes: 624d93a4f0 ("drm/vc4: hdmi: Move clock calculation into its own function")

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

drm/vc4: Disable Gamma control on HVS5 due to issues writing the table

Still under investigation, but the conditions under which the HVS
will accept values written to the gamma PWL are not straightforward.

Disable gamma on HVS5 again until it can be resolved to avoid
gamma being enabled with an incorrect table.

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

arm: Fix annoying .eh_frame section warnings

Replace the cfi directives with the UNWIND equivalents. This prevents
the .eh_frame section from being created, eliminating the warnings.

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

overlays: Add vl805 overlay

With the automatic VL805 support being removed from the standard
CM4 dtb (since most CM4 carriers don't have a VL805), retain support
on those that do by creating a "vl805" overlay that restores the
deleted "usb@0,0" node.

The "vl805" overlay will be loaded automatically (after an upcoming
firmware update) on CM4 boards where the EEPROM config includes the
setting VL805=1.

See: https://forums.raspberrypi.com/viewtopic.php?t=326088

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

arm: Fix custom rpi __memset32 and __memset64

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

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

drm/vc4: Add alpha_blend_mode property to each plane.

Move from only supporting the default of pre-multiplied
alpha to supporting user specified blend mode using the
standardised property.

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

configs: add CONFIG_LEDS_TRIGGER_PATTERN=m

Enable the pattern led trigger.

Signed-off-by: Marco Nelissen <marco.nelissen@gmail.com>

dtoverlays: Add backlight-gpio parameter to vc4-kms-dpi-generic

To allow for the cases where a simple panel does have a GPIO
controlled backlight. Defaults to having no backlight defined.

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

overlays: Add overlay for Azoteq IQS550

This patch adds a device tree overlay for the Azoteq IQS550
trackpad/touchscreen controller.

Signed-off-by: Jeff LaBundy <jeff@labundy.com>

configs: Enable Azoteq IQS550/572/525

This patch enables the Azoteq IQS550/572/525 trackpad/touchscreen
controller as a module.

Signed-off-by: Jeff LaBundy <jeff@labundy.com>

bcm2835-v4l2-isp: Add missing lock initialization

ISP device allocation is dynamic hence the locks too.
struct mutex queue_lock is not initialized which result in bug.

Fixing same by initializing it.

[   29.847138] INFO: trying to register non-static key.
[   29.847156] The code is fine but needs lockdep annotation, or maybe
[   29.847159] you didn't initialize this object before use?
[   29.847161] turning off the locking correctness validator.
[   29.847167] CPU: 1 PID: 343 Comm: v4l_id Tainted: G         C        5.15.11-rt24-v8+ #8
[   29.847187] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[   29.847194] Call trace:
[   29.847197]  dump_backtrace+0x0/0x1b8
[   29.847227]  show_stack+0x20/0x30
[   29.847240]  dump_stack_lvl+0x8c/0xb8
[   29.847254]  dump_stack+0x18/0x34
[   29.847263]  register_lock_class+0x494/0x4a0
[   29.847278]  __lock_acquire+0x80/0x1680
[   29.847289]  lock_acquire+0x214/0x3a0
[   29.847300]  mutex_lock_nested+0x70/0xc8
[   29.847312]  _vb2_fop_release+0x3c/0xa8 [videobuf2_v4l2]
[   29.847346]  vb2_fop_release+0x34/0x60 [videobuf2_v4l2]
[   29.847367]  v4l2_release+0xc8/0x108 [videodev]
[   29.847453]  __fput+0x8c/0x258
[   29.847476]  ____fput+0x18/0x28
[   29.847487]  task_work_run+0x98/0x180
[   29.847502]  do_notify_resume+0x228/0x3f8
[   29.847515]  el0_svc+0xec/0xf0
[   29.847523]  el0t_64_sync_handler+0x90/0xb8
[   29.847531]  el0t_64_sync+0x180/0x184

Signed-off-by: Padmanabha Srinivasaiah <treasure4paddy@gmail.com>

Use GitHubs issue form for bug reports

Use GitHubs issue form for bug reports.

- modern look
- user don't need to mess with given markdown parts while filling the issue template

Setup config.yml for general questions and problems with the Raspbian distribution packages.

media: i2c: ov9281: Increase diff between VTS and max exposure

The driver did allow the exposure to go up to VTS - 4 lines,
but this would produce a visible line on 1280x800, and a stall of
the sensor at 640x480.

Whilst it appears to work with a difference of 5, the datasheet states
there should be at least 25 lines difference between VTS and exposure,
so use that value.

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

staging/bcm2835-codec: Fix typo

Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>

drm/vc4: hdmi: Fix no video output on DVI monitors

The drm edid parser doesn't signal RGB support on DVI monitors
with old edid versions, leading to 8-bit RGB mode being rejected
and no video on DVI monitors.

As 8-bit RGB is mandatory on HDMI and DVI monitors anyways we can
simply drop the RGB format check, aligning vc4 with other drivers.

Signed-off-by: Matthias Reichl <hias@horus.com>

drm/vc4: hdmi: Fix HDMI monitor detection in polled mode

When vc4_hdmi_connector_detect() was called in
connector_status_connected state it incorrectly cleared the
hdmi_monitor flag, leading to no audio on RPi3.

Fix this by clearing hdmi_monitor only when the hpd check
indicated no connection or if reading the edid failed.

Signed-off-by: Matthias Reichl <hias@horus.com>

uapi/v4l2-controls: Reset V4L2_CID_USER_BCM2835_ISP_BASE to same as 5.10

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

Upstream has added additional device specific controls, so the
V4L2_CID_USER_BASE + 0x10e0 value that had been defined for use with
the ISP has been taken by something else (and +0x10f0 has been used as
well)

Duplicate the use on V4L2_CID_USER_BASE + 0x10e0 so that userspace
(libcamera) doesn't need to change. Once the driver is upstream, then
we'll update libcamera to adopt the new value as it then won't change.

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

dtoverlays: Enable cam1_clock when using tc358743 or irs1125

This fixes a regression introduced in 131f1322039284932ccb601a5cffdd9ca5d36d96
(see also https://github.com/raspberrypi/linux/issues/4791).
The tc358743 driver refused to bind to the device. The irs1125
driver is likely behaving similarly.

The new unified cam1_clk node that represents the fixed on-board
oscillator is marked as disabled by default. These overlays didn't
expect this and so the clock nodes were stuck in disabled state.

This commit just adds the required status = "okay" line. Other sensor
drivers do this too.

Add panel overlay for CutiePi

Signed-off-by: Penk Chen <penk@cutiepi.io>

Enable ili9881 panel and pwm backlight driver by default

Signed-off-by: Penk Chen <penk@cutiepi.io>

Extending ili9881c driver support for nwe080 panel

Signed-off-by: Penk Chen <penk@cutiepi.io>

media: v4l2-ctrls: Document V4L2_CID_NOTIFY_GAINS control

commit 311a839a1ad255ebcb7291fb4e0d2ec2f32312a7 upstream.

Add documentation for the V4L2_CID_NOTIFY_GAINS control.

This control is required by sensors that need to know what colour
gains will be applied to pixels by downstream processing (such as by
an ISP), though the sensor does not apply these gains itself.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-ctrls: Add V4L2_CID_NOTIFY_GAINS control

commit a9c80593ff80ddb7c6496624e5384e1ea3460a72 upstream.

We add a new control V4L2_CID_NOTIFY_GAINS which allows the sensor to
be notified what gains will be applied to the different colour
channels by subsequent processing (such as by an ISP), even though the
sensor will not apply any of these gains itself.

For Bayer sensors this will be an array control taking 4 values which
are the 4 gains arranged in the fixed order B, Gb, Gr and R,
irrespective of the exact Bayer order of the sensor itself. The use of
an array makes it straightforward to extend this control to non-Bayer
sensors (for example, sensors with an RGBW pattern) in future.

The units are in all cases linear with the default value indicating a
gain of exactly 1.0. For example, if the default value were reported as
128 then the value 192 would represent a gain of exactly 1.5.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

drm/vc4: hdmi: Support HDMI YUV output

In addition to the RGB444 output, the BCM2711 HDMI controller supports
the YUV444 and YUV422 output formats.

Let's add support for them in the driver, but still use RGB as the
preferred format.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hdmi: Always try to have the highest bpc

Currently we take the max_bpc property as the bpc value and do not try
anything else.

However, what the other drivers seem to be doing is that they would try
with the highest bpc allowed by the max_bpc property and the hardware
capabilities, test if it results in an acceptable configuration, and if
not decrease the bpc and try again.

Let's use the same logic.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hdmi: Take bpp into account for the scrambler

The current code only base its decision for whether the scrambler must be
enabled or not on the pixel clock of the mode, but doesn't take the bits
per color into account.

Let's leverage the new function to compute the clock rate in the
scrambler setup code.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hdmi: Take the sink maximum TMDS clock into account

In the function that validates that the clock isn't too high, we've only
taken our controller limitations into account so far.

However, the sink can have a limit on the maximum TMDS clock it can deal
with too which is exposed through the EDID and the drm_display_info.

Make sure we check it.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hdmi: Move clock calculation into its own function

The code to compute our clock rate for a given setup will be called in
multiple places in the next patches, so let's create a separate function
for it.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hdmi: Move clock validation to its own function

Our code is doing the same clock rate validation in multiple instances.
Let's create a helper to share the rate validation.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hdmi: Change CSC callback prototype

In order to support the YUV output, we'll need the atomic state to know
what is the state of the associated property in the CSC setup callback.

Let's change the prototype of that callback to allow us to access it.

Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hdmi: Define colorspace matrices

The current CSC setup code for the BCM2711 uses a sequence of register
writes to configure the CSC depending on whether we output using a full
or limited range.

However, with the upcoming introduction of the YUV output, we're going
to add new matrices to perform the conversions, so we should switch to
something a bit more flexible that takes the matrix as an argument and
programs the CSC accordingly.

Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hdmi: Replace CSC_CTL hardcoded value by defines

On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an
opaque value. Let's replace it with properly defined values.

Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hdmi: Move XBAR setup to csc_setup

On the BCM2711, the HDMI_VEC_INTERFACE_XBAR register configuration
depends on whether we're using an RGB or YUV output. Let's move that
configuration to the CSC setup.

Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hdmi: Use full range helper in csc functions

The CSC callbacks takes a boolean as an argument to tell whether we're
using the full range or limited range RGB.

However, with the upcoming YUV support, the logic will be a bit more
complex. In order to address this, let's make the callbacks take the
entire mode, and call our new helper to tell whether the full or limited
range RGB should be used.

Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hdmi: Add full range RGB helper

We're going to need to tell whether we want to run with a full or
limited range RGB output in multiple places in the code, so let's create
a helper that will return whether we need with full range or not.

Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/edid: Rename drm_hdmi_avi_infoframe_colorspace to _colorimetry

The drm_hdmi_avi_infoframe_colorspace() function actually sets the
colorimetry and extended_colorimetry fields in the hdmi_avi_infoframe
structure with DRM_MODE_COLORIMETRY_* values.

To make things worse, the hdmi_avi_infoframe structure also has a
colorspace field used to signal whether an RGB or YUV output is being
used.

Let's remove the inconsistency and allow for the colorspace usage by
renaming the function.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/edid: Don't clear YUV422 if using deep color

The current code, when parsing the EDID Deep Color depths, that the
YUV422 cannot be used, referring to the HDMI 1.3 Specification.

This specification, in its section 6.2.4, indeed states:

  For each supported Deep Color mode, RGB 4:4:4 shall be supported and
  optionally YCBCR 4:4:4 may be supported.

  YCBCR 4:2:2 is not permitted for any Deep Color mode.

This indeed can be interpreted like the code does, but the HDMI 1.4
specification further clarifies that statement in its section 6.2.4:

  For each supported Deep Color mode, RGB 4:4:4 shall be supported and
  optionally YCBCR 4:4:4 may be supported.

  YCBCR 4:2:2 is also 36-bit mode but does not require the further use
  of the Deep Color modes described in section 6.5.2 and 6.5.3.

This means that, even though YUV422 can be used with 12 bit per color,
it shouldn't be treated as a deep color mode.

This deviates from the interpretation of the code and comment, so let's
fix those.

Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: Skip writes to disabled packet RAM

This path actually occurs when audio is started during a hdmi mode set.
As the data will be written by vc4_hdmi_set_infoframes when packet RAM
is enabled again, don't treat as an error

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

drm/vc4: hvs: Ignore atomic_flush if we're disabled

atomic_flush will be called for each CRTC even if they aren't enabled.

The whole code we have there will thus run without a properly affected
channel, which can then result in all sorts of weird behaviour.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hvs: Move the dlist setup to its own function

The vc4_hvs_update_dlist function mostly deals with setting up the
vblank events and setting up the dlist entry pointer to our current
active one.

We'll want to do the former separately from the vblank handling in later
patches, so let's move it to a function of its own.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hvs: Remove dlist setup duplication

Setting the DISPLISTx register needs to occur in every case, and we
don't need to protect the register using the event_lock, so we can just
move it after the if branches and simplify a bit the function.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: hvs: Store channel in variable

The assigned_channel field of our vc4_crtc_state structure is accessed
multiple times in vc4_hvs_atomic_flush, so let's move it to a variable
that can be used in all those places.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: kms: Take old state core clock rate into account

During a commit, the core clock, which feeds the HVS, needs to run at
a minimum of 500MHz.

While doing that commit, we can also change the mode to one that
requires a higher core clock, so we take the core clock rate associated
to that new state into account for that boost.

However, the old state also needs to be taken into account if it
requires a core clock higher that the new one and our 500MHz limit,
since it's still live in hardware at the beginning of our commit.

Fixes: 16e101051f32 ("drm/vc4: Increase the core clock based on HVS load")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

staging/bcm2835-isp: Fix cleanup after init fail

bcm2835_isp_remove is called on an initialisation failure, but at that
point the drvdata hasn't been set. This causes a crash when e.g. using
the cutdown firmware (gpu_mem=16).

Move platform_set_drvdata before the instance probing loop to avoid the
problem.

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

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

ASoC:ma120x0p: Increase maximum sample rate to 192KHz

Change the maximum sample rate for the amplifier to
192KHz as given in the Infineon specification.

Signed-off-by: Joerg Schambacher <joerg@hifiberry.com>

dtoverlays: Add option to select camera as on CAM0 of CM

Parameterise the overlays so that they can have an optional
cam0 parameter to switch to i2c_vc and csi0.

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

ARM: dts: bcm2711-cm4s Correct i2c0mux to use 0/1 and 28/29 & 2 regulators

CM4S follows CM1/3, so based on the documentation cameras/displays
connect to 0/1 and 28/29, not 0/1 and 44/45.

Likewise the camera regulator controls are independent as on CM1/3.

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

media: i2c: ov7251: Make the enable GPIO optional.

Not all implementations wire up the enable GPIO and may just tie
it to a supply rail.
Make it optional.

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

dtoverlays: Convert ov5647 to use the regulator framework

Fixing up shutdown GPIOs via overrides is ugly, and doesn't work
on eg CM4 where both cameras share the same shutdown GPIO.

The driver is now updated to use the regulator framework, so switch
to using that instead.

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

media: i2c: ov5647: Add support for regulator control.

The driver supported using GPIOs to control the shutdown line,
but no regulator control.

Add regulator hooks.

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

dtoverlays: Convert the camera sensor overlays to use the new regs and clks.

Now that we have regulators and clocks defined in the base DT for
image sensors, switch the overlays to use them.

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

dt: Create static regulators and clocks for camera nodes

Unloading regulators through dynamic device tree doesn't work
as the regulators will unregister whilst clients are still
registered. Whilst the regulator framework does WARN when that
happens, the client putting the regulator then typically results
in a NULL dereference and badness.

Instead of creating regulators and clocks from the overlays,
create regulators and clocks for the sensors in the base DT.

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

drm/vc4: Fix build without DRM_VC4_HDMI_CEC

As reported by @asavah.

Fixes: https://github.com/raspberrypi/linux/issues/4771

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

usb: xhci: add VLI_TRB_CACHE_BUG quirk

The VL805 fetches up to 4 transfer TRBs at a time. TRB reads don't cross
a 64B boundary, and if a TRB is fetched and is not on a 64B boundary,
the read is sized up to the next 64B boundary.

However the VL805 implements a readahead prefetch for TRBs on a transfer
ring. This fetches the next 64B after any TRB read has happened. Near
the end of a ring segment, the prefetcher can read the first 64B of the
next page in physical memory and this is where the behaviour causes a
bug.

The controller does not tag reads with which endpoint they are for, so
if the start of the next page is a ring segment used by a victim
endpoint, and the victim endpoint is about to fetch TRBs from the start
of the segment, the victim endpoint will read from the prefetched data
and not perform a read to main memory. If the data is stale, the ring
cycle state bit may not be correct and the endpoint will silently halt.

Adjust trbs_per_seg for transfer rings allocated for this controller.

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

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>

xhci: refactor out TRBS_PER_SEGMENT define in runtime code

In anticipation of adjusting the number of utilised TRBs in a ring
segment, add trbs_per_seg to struct xhci_ring and use this instead
of a compile-time define.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>

ARM: dts: Create bcm2711-rpi-cm4s.dts (#4761)

Signed-off-by: Peter Harper <peter.harper@raspberrypi.com>

vc4/drm: Ignore vc4_hdmi->output_enabled for allowing audio (#4759)

Otherwise we reject audio playback when switching hdmi modes

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

 media: imx219: Advertise embedded data node on media pad 1

This commit updates the imx219 driver to adverise support for embedded
data streams.  This can then be used by the bcm2835-unicam driver, which
has recently been updated to expose the embedded data stream to
userland.

The imx219 sensor subdevice overloads the media pad to differentiate
between image stream (pad 0) and embedded data stream (pad 1) when
performing the v4l2_subdev_pad_ops functions.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
[JMH: Adapt to the mainline 5.16 kernel]
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>

xhci: correct room_on_ring() for cases where there is a single segment

Don't calculate space based on the number of TRBs in the current segment,
as it's OK to wrap to the start (and flip the cycle state bit).

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>

xhci: quirks: add link TRB quirk for VL805

The VL805 controller can't cope with the TR Dequeue Pointer for an endpoint
being set to a Link TRB. The hardware-maintained endpoint context ends up
stuck at the address of the Link TRB, leading to erroneous ring expansion
events whenever the enqueue pointer wraps to the dequeue position.

If the search for the end of the current TD and ring cycle state lands on
a Link TRB, move to the next segment.

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

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>

dtoverlays: Add a generic DPI panel overlay for KMS

Uses the "panel-dpi" compatible to set panel timings from
DT.

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

dt: bcm270x: Add GPIO defines for RGB565 DPI output modes

Adds the pinctrl defines for the RGB565 DPI output modes.

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

drm/vc4: dpi: Ensure a default format is selected

In a couple of error/incomplete configuration cases, the
DPI_FORMAT bits wouldn't get set.

Adopt a default of RGB666 in all these cases.

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

drm/vc4: dpi: Add option for inverting pixel clock and output enable

DRM provides flags for inverting pixel clock and output enable
signals, but these were not mapped to the relevant registers.

Add those mappings.

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

drm/panel-simple: Allow the bus format to be read from DT for panel-dpi

The "panel-dpi" compatible string configures panel from device tree,
but it doesn't provide any way of configuring the bus format (colour
representation), nor does it populate it.

Add a DT parameter "bus-format" that allows the MEDIA_BUS_FMT_xxx value
to be specified from device tree.

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

drm/panel-simple: Populate bpc when using panel-dpi

panel-dpi doesn't know the bit depth, so in the same way that
DPI is guessed for the connector type, guess that it'll be 8bpc.

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

overlays: vc4-kms-v3d: Change composite handling

On a Pi 4, enabling composite video disables the HDMI output. As a
consequence, the composite output is disabled by default. Change the
vc4-kms-v3d overlay used on older Pis to also disable composite by
default, replacing the "nocomposite" parameter with a "composite"
parameter.

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

dt: bcm283x: Change BCM283x HDMI to use firmware clock driver

The clk-bcm2835 handling of the pixel clock does not function
correctly when the HDMI power domain is disabled.

The firmware supports it correctly, and the firmware clock
driver now supports it, so switch the vc4-hdmi driver to use
the firmware clock driver.

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

clk: bcm: rpi: Add the BCM283x pixel clock.

The clk-bcm2835 handling of the pixel clock does not function
correctly when the HDMI power domain is disabled.

The firmware supports it correctly, so add it to the
firmware clock driver.

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

drm/vc4: Move HDMI reset to pm_resume

Pi0-3 have power domains attached to the pm_runtime hooks
for the HDMI block. Initialisation done in the reset called
from bind is therefore lost if all users of the domain are
suspended.
The VEC shares the same lowest level clock/power gating as
the HDMI block, so whilst that is enabled the block is never
actually powered down, but if it isn't enabled then we lose
the state.

Reset and initialise the HDMI block from pm_resume.

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

input: edt-ft5x06: Only look at the number of points reported

Register 0x02 in the FT5x06 is TD_STATUS containing the number
of valid touch points being reported.

Iterate over that number of points rather than all that are
supported on the device.

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

regulator/rpi-panel-attiny: Use two transactions for I2C read

The I2C to the Atmel is very fussy, and locks up easily on
Pi0-3 particularly on reads.
If running at 100kHz on Pi3, reading the ID register generally
locks up the Atmel, but splitting the register select write and
read into two transactions is reliable.

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

regulator/rpi-panel-attiny: Don't read the LCD power status

The I2C to the Atmel is very fussy, and locks up easily on
Pi0-3 particularly on reads.

The LCD power status is controlled solely by this driver, so
rather than reading it back from the Atmel, use the cached
status last set.

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

drivers: bcm2835_unicam: Add logging message when a frame is dropped.

If a dummy buffer is still active on a frame start, it indicates that this frame
will be dropped. The explicit logging helps users identify performance issues.

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

staging/bcm2835-codec: Allow a different stride alignment per role

Deinterlace and decode aren't affected in the same way as encode
and ISP by the alignment requirement on 3 plane YUV420.
Decode would be affected, but it always aligns the height up to
a macroblock, and uses the selection API to reflect that.

Add in the facility to set the bytesperline alignment per role.

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

media: rpivid: remove min_buffers_needed from src queue

Remove min_buffers_needed=1 from src queue init. Src buffers are bound
to media requests therefore this setting is not needed and generates
a WARN in kernel 5.16.

Signed-off-by: John Cox <jc@kynesim.co.uk>

staging/bcm2835-codec: bytesperline for YUV420/YVU420 needs to be 64

Matching https://github.com/raspberrypi/linux/pull/4419, the ISP
block (which is also used on the input of the encoder, and output
of the decoder) needs the base address of all planes to be aligned
to multiples of 32. This includes the chroma planes of YUV420 and
YVU420.
If the height is only a multiple of 2 (not 4), then you get an odd
number of lines in the second plane, which means the 3rd plane
starts at a multiple of bytesperline/2.

Set the minimum bytesperline alignment to 64 for those formats
so that the plane alignment is always right.

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

dtoverlays: Use edt-ft5506 for 10 points, instead of edt-ft5x06

Whilst all the datasheets describe FT5x06 as supporting "up to
10 points of absolution X and Y coordinates", the driver
implementation for the compatible string "edt,edt-ft5x06" only
allows for 5.

Switch to the "edt,edt-ft5506" compatible string which allows for
10 points with no other differences.

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

input: edt-ft5x06: Handle unreliable TOUCH_UP events

The ft5x06 is unreliable in sending touch up events, so some
touch IDs can become stuck in the detected state.

Ensure that IDs that are unreported by the controller are
released.

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