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>

drm/vc4: Ensure vc4_hdmi doesn't use 2711 HPD registers on Pi0-3

The existing logic was flawed in that it could try reading the
2711 specific registers for HPD on a CM1/3 where the HPD GPIO
hadn't been defined in DT.

Ensure we don't do the 2711 register read on invalid hardware,
and then

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

drm/vc4: Add support for composite syncs to vc4_dpi

The hardware can combine H&V syncs onto the output enable line
as composite syncs, so add the relevant configuration to do that.

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

spi: spidev: Restore loading from Device Tree

As happens occasionally, an upstream change has once again prevented
spidev from being loaded via Device Tree. We now need "spidev" to be
included in the new spi_device_id list, otherwise although the
spidev driver gets loaded no /dev/spidev*.* entries will appear.

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

ARM: dts: Update rpi-400 and cm4 dts to match 4-b

The Pi 4B dts file has had numerous updates since the Pi 400 and CM4
dts files were written. Apply those updates to the other files to
minimise the differences. The change is largely cosmetic, except for
the PCI "device-type" to "device_type" rename, and the correction of
the labels on the Pi 400 GPIO expander pins.

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

Pass V4L2_CID_MPEG_VIDEO_H264_MIN_QP/MAX_QP to bcm2835-v4l2-codec

Following raspberrypi/linux#4704. This is necessary to set up
quantization for variable bitrate to avoid video flickering.

drivers: bcm2835_isp: Fix div by 0 bug.

Fix a possible division by 0 bug when setting up the mmal port for the stats
port.

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

drivers: bcm2835_isp: Allow multiple users for the ISP driver.

Add a second (identical) set of device nodes to allow concurrent use of the ISP
hardware by another user. This change effectively creates a second state
structure (struct bcm2835_isp_dev) to maintain independent state for the second
user. Node and media entity names are appened with the instance index
appropriately.

Further users can be added by changing the BCM2835_ISP_NUM_INSTANCES define.

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

media: i2c: ov5647: Support HFLIP and VFLIP

Add these missing V4L2 controls. Tested binned and full resolution
modes in all four orientations using Raspberry Pi running libcamera.

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

configs: Add USB gadget support (for Zero 2 W)

Bring the Pi 3 kernel in line with the Pi Zero and Pi 4 by enabling
USB gadget support, which is useful on Zero 2 W.

See: https://github.com/raspberrypi/firmware/issues/1654

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

configs: add LEDS_PWM=y

Enable support for PWM driven LEDs.

Signed-off-by: Michael Heimpold <mhei@heimpold.de>

configs: add CONFIG_HID_PLAYSTATION=m and CONFIG_PLAYSTATION_FF=y

Enables support for the PlayStation 5 'DualSense' controller and its
force feedback.

Also, Sony is planning to move PlayStation peripheral support from
hid-sony into hid-playstation in the future:
https://lore.kernel.org/all/20201219062336.72568-1-roderick@gaikai.com/

This means that, potentially, in future kernel releases older
PlayStation controllers may stop working without this option. As
Raspberry Pis are a popular choice as emulation consoles, it is probably
a good idea to enable this.

Signed-off-by: Ilya Trukhanov <lahvuun@gmail.com>

enable several virtual devices for hosting virtual machines

drm/vc4: Don't try disabling SCDC on Pi0-3.

The code that set the scdc_enabled flag to ensure it was
disabled at boot time also ran on Pi0-3 where there is no
SCDC support. This lead to a warning in vc4_hdmi_encoder_post_crtc_disable
due to vc4_hdmi_disable_scrambling being called and trying to
read (and write) register HDMI_SCRAMBLER_CTL which doesn't
exist on those platforms.

Only set the flag should the interface be configured to support
more than HDMI 1.4.

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

drm/vc4: Validate the size of the gamma_lut

Add a check to vc4_hvs_gamma_check to ensure a new non-empty
gamma LUT is of the correct length before accepting it.

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

dtoverlays: Remove i2c0mux and i20if status from edt-ft5406.dtsi

edt-ft5406.dtsi is included from vc4-kms-dsi-7inch which was
also setting i2c0mux and i2c0if status fields. This meant that
dtoverlay wouldn't apply the overlay due to multiple fragments
changing the same parameter.

Move the enable from edt-ft5406.dtsi to edt-ft5406-overlay.dts
for when it should be needed as an independent overlay.

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

drm/vc4: Only add gamma properties once.

Two calls were made to drm_crtc_enable_color_mgmt to add gamma
and CTM, however they were both set to add the gamma properties,
so they ended up added twice.

Fixes: 766cc6b1f7fc "drm/vc4: Add CTM support"
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

drm/vc4: Enable gamma block only when required.

With HVS5 the gamma block is now only reprogrammed with
a disable/enable. Loading the table from vc4_hvs_init_channel
(called from vc4_hvs_atomic_enable) appears to be at an
invalid point in time and so isn't applied.

Switch to enabling and disabling the gamma table instead. This
isn't safe if the pipeline is running, but it isn't now.
For HVS4 it is safe to enable and disable dynamically, so
adopt that approach there too.

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

drm: Fix double free from checking if gamma lut has been updated

The code falls through to "fail" under all conditions, so there is no
need for the drm_property_blob_put if the gamma lut hasn't been changed.
Fixes: 9cca26674a2b "drm: Check whether the gamma lut has changed before updating"

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

configs: Add TCA6416 driver module

Add a matrix keyboard on I2C

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

overlays: Additional parameters for gpio-poweroff

The gpio-poweroff driver supports active-delay-ms and inactive-delay-ms
properties. Add parameters to set these parameters - active_delay_ms
and inactive_delay_ms.

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

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

config: Set TCA8418 to module

This chip is a popular way to add a matrix keyboard using I2C.

configs: Add kernel SMB3 server support

Enable the in-kernel (module) SMB3 server.

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

configs: Add NTFS3 support

ntfs3 provides improved support for NTFS filesystems without the
performance hit of a userspace FUSE filesystem.

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

configs: Regenerate defconfigs

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

overlays: Add fbtft overlay

Add an overlay that provides much of the functionality that fbtft_device did.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

drm/vc4: kms: Move clock request to our HVS state

Our current clock request has been stored so far on the main HVS
structure, but even though we shouldn't have two commits in parallel and
it shouldn't cause any functional change, the request itself is linked
to a given HVS state.

Move the request there to make a bit more sense.

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

drm/vc4: kms: Fix return code check

The HVS global state functions return an error pointer, but in most
cases we check if it's NULL, possibly resulting in an invalid pointer
dereference.

Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

brcmfmac: Protect against reprobing

It is important to reinitialise the firmware array pointers to protect
against the case that the brcmfmac driver is reprobed without first
being unloaded.

The potential hazard was noticed while investigating
https://github.com/raspberrypi/firmware/issues/1644 .

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

drm: Check whether the gamma lut has changed before updating

drm_crtc_legacy_gamma_set updates the gamma_lut blob unconditionally,
which leads to unnecessary reprogramming of hardware.

Check whether the blob contents has actually changed before
signalling that it has been updated.

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

ARM: dts: Provide WLAN firmware names for Zero 2 W

BCM43430/2 may be BCM43430B0 or BCM43436P, and BCM43430/1 can be either
BCM43430A1 or BCM43436S, the former being upstream names and the
latter downstream names for differently-sourced sister parts.

Make the choice of firmwares board-specific (without making the actual
firmwares board-specific) by placing the alternative firmware names for
each part in the DT node.

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

brcmfmac: Read alternative firmware names from DT

Add the ability to load the names of alternative firmwares from the
Device Tree node. This permits separate firmwares for 43436s and 43438
and allows downstream firmwares to coexist with upstream.

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

ARM: dt: Add DT nodes for the WLAN interfaces

Mirror upstream changes into the downstream dts files.

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

dtoverlays: Update all image sensor overlays for Media Controller option

Add an option to enable configuration via the Media Controller API
(rather than the video-node-centric /dev/videoN) as about to
be used by libcamera as it enables more complex pipelines to be
handled.

Any source that has a libcamera tuning merged has MC enabled by
default.
Sources with no libcamera tuning merged have it disabled by
default.
In either case it can be overridden with the overlay parameter
"media-controller".

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

brcmfmac: Don't promote INFO logging to ERR

An unwanted side effect of enabling the BRCMDBG config setting is
redefining brcmf_info to be brcmf_err. This can be alarming to users
and makes it harder to spot real errors, so don't do it.

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

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

ARM: dts: Rename Zero 2 W DT files

Retain the old names for backwards compatibility for a while, while the
necessary firmware change rolls out.

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

bcm2835-v4l2-codec: Remove advertised support of VP8

The support for this format by firmware is very limited
and won't be faster than the arm.

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

drm/vc4: Make VEC progressive modes readily accessible

Add predefined modelines for the 240p (NTSC) and 288p (PAL) progressive
modes, and report them through vc4_vec_connector_get_modes().

Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>

drm/vc4: Relax VEC modeline requirements and add progressive mode support

Make vc4_vec_encoder_atomic_check() accept arbitrary modelines, as long
as they result in somewhat sane output from the VEC. The bounds have
been determined empirically. Additionally, add support for the
progressive 262-line and 312-line modes.

Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>

media: i2c: imx477: Add vsync trigger_mode parameter

trigger_mode == 0 (default) => no effect / no registers written
trigger_mode == 1           => source
trigger_mode == 2           => sink

This can be set e.g. in /boot/cmdline.txt as imx477.trigger_mode=N

Signed-off-by: Jonas Jacob <jonas.jacob@neocortexvision.com>

drm/vc4: hvs: Force modeset on gamma lut change

The HVS Gamma block can only be updated when idle, so we need to disable
the HVS channel when the gamma property is set in an atomic commit.

Since the pixelvalve cannot have its assigned channel halted without
stalling unless it's disabled as well, in our case that means forcing a
full disable / enable cycle on the pipeline.

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

drm/vc4: Add debugfs node that dumps the vc5 gamma PWL entries

This helps with debugging the conversion from a 256 point gamma LUT to
16 point PWL entries as used by the BCM2711.

Co-developed-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/vc4: Add support for gamma on BCM2711

BCM2711 changes from a 256 entry lookup table to a 16 point
piecewise linear function as the pipeline bitdepth has increased
to make a LUT unwieldy.

Implement a simple conversion from a 256 entry LUT that userspace
is likely to expect to 16 evenly spread points in the PWL. This
could be improved with curve fitting at a later date.

Co-developed-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

clk-bcm2835: Remove VEC clock support

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

dt: Move VEC clock to clk-raspberrypi

clk-2835 is deprecated and gets an innacurate clock for VEC (107MHz).
Switch to clk-raspberrypi which uses the right PLL to get an accurate 108MHz.

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

clk-raspberrypi: Support VEC clock

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

ARM: dts: Add Pi Zero 2 support

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

staging/bcm2835-camera: Add support for MPEG_VIDEO_FORCE_KEY_FRAME

Signed-off-by: Gergo Koteles <soyer@irl.hu>

staging/bcm2835-camera: Add support for H264_MIN_QP, H264_MAX_QP

Signed-off-by: Gergo Koteles <soyer@irl.hu>

ARM: dts: vc4-kms-v3d: Always disable firmware HDMI

Both the firmware audio driver and the vc4-kms-v3d driver are capable
of providing HDMI audio, but only one should be active at any time.
The vc4-kms-v3d overlays disable the firmware audio driver, but they
also have a noaudio parameter that as well as disabling the ARM-side
HDMI audio also re-enables the firmware HDMI audio. This is not
guaranteed to work and has been seen to break the display completely.

Modify the noaudio parameters so that the firmware HDMI audio support
remains disabled.

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

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

media/bcm2835-unicam: Add support for configuration via MC API

Adds Media Controller API support for more complex pipelines.
libcamera is about to switch to using this mechanism for configuring
sensors.

This can be enabled by either a module parameter, or device tree.

Various functions have been moved to group video-centric and
mc-centric functions together.

Based on a similar conversion done to ti-vpe.

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