Use ~0, not -1, when working with unsigned values (-1 is not unsigned).

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

The driver has two places where it writes a register based on a
condition, and when that condition is false, the driver presumes that
the register has the reset value. This is not a good idea, so fix those
places to always write the register.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

The logic for handling width & height in cfe_start_channel() is somewhat
odd and, afaics, broken. The code reads:

bool start_fe = is_fe_enabled(cfe) &&
                test_all_nodes(cfe, NODE_ENABLED, NODE_STREAMING);

if (start_fe || is_image_output_node(node)) {
        width = node->fmt.fmt.pix.width;
        height = node->fmt.fmt.pix.height;
}

cfe_start_channel() is called for all video nodes that will be used. So
this means that if, say, fe_stats is enabled as the last node, start_fe
will be true, and width and height will be taken from fe_stats' node.
The width and height will thus contain garbage, which then gets
programmed to the csi2 registers.

It seems that this often still works fine, though, probably if the width
& height are large enough.

Drop the above code, and instead get the width & height from the csi2
subdev's sink pad for the csi2 channel that is used. For metadata the
width & height will be 0 as before.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

cfe_probe_complete() calls cfe_put() on both success and fail code paths.
This works for the success path, but causes the cfe_device struct to be
freed, even if it will be used later in the teardown code.

Fix this by making the ref handling a bit saner: Let the video nodes
have the refs as they do now, but also keep a ref in the "main" driver,
released only at cfe_remove() time. This way the driver does not depend
on the video nodes keeping the refs.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

Commit b84b5314 upstream.

Commit 4e087133 ("ASoC: hdmi-codec: fix channel info for
compressed formats") accidentally changed hcp->chmap_idx from
ca_id, the CEA channel allocation ID, to idx, the index to
the table of channel mappings ordered by preference.

This resulted in wrong channel maps being reported to userspace,
eg for 5.1 "FL,FR,LFE,FC" was reported instead of the expected
"FL,FR,LFE,FC,RL,RR":

~ # speaker-test -c 6 -t sine
...
 0 - Front Left
 3 - Front Center
 1 - Front Right
 2 - LFE
 4 - Unknown
 5 - Unknown

~ # amixer cget iface=PCM,name='Playback Channel Map' | grep ': values'
  : values=3,4,8,7,0,0,0,0

Switch this back to ca_id in case of PCM audio so the correct channel
map is reported again and set it to HDMI_CODEC_CHMAP_IDX_UNKNOWN in
case of non-PCM audio so the PCM channel map control returns "Unknown"
channels (value 0).

Fixes: 4e087133

 ("ASoC: hdmi-codec: fix channel info for compressed formats")
Cc: stable@vger.kernel.org
Signed-off-by: Matthias Reichl <hias@horus.com>
Link: https://lore.kernel.org/r/20230929195027.97136-1-hias@horus.com


Signed-off-by: Mark Brown <broonie@kernel.org>

This reverts commit a319c6c1.

Fix the touchscreen.

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



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

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

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

The driver does not lock the imx477 mutex when calling
imx477_set_framing_limits(), leading to:

WARNING: CPU: 3 PID: 426 at drivers/media/v4l2-core/v4l2-ctrls-api.c:934 __v4l2_ctrl_modify_range+0x1a0/0x210 [
videodev]

Fix this by taking the lock.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

The 10.1" panel doesn't work with the timings defined. vc4
will always have been fixing up the timing due to the limited
integer divider, so compute the fixed up mode and use it
directly.

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

vc4 has always fixed up the timing, so the values defined have
never actually appeared on the wire.
The display appears to want a slightly longer HFP, so extend
the timings and recompute the clock to give the same frame rate.

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

Avoid double buffering LBM allocations by making the
allocation a single alloc per crtc at atomic_flush.

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

On 2712, the firmware always runs these clock at a speed sufficient
for dual 4kp60.

The requests here prevent the gpu from going into its lowest voltage
mode, so just skip the clock requests.

With this applied the idle voltage on my pi 5 reduces from 0.7424V
to 0.72V.

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

The BCM2712 comes with a different LBM size computation than the
previous generations, so let's add the few examples provided as kunit
tests to make sure we always satisfy those requirements.

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

We'll start testing our planes code in situations where we will use more
than XRGB8888, so let's add a few common pixel formats.

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

We'll start to add some tests for the plane state logic, so let's create
a helper to add a plane to an existing atomic state.

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

Some tests will need to find a plane to run a test on for a given CRTC.
Let's create a small helper to do that.

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

The current mock planes were just using the regular drm_plane_state,
while the driver expect struct vc4_plane_state that subclasses
drm_plane_state.

Hook the proper implementations of reset, duplicate_state, destroy and
atomic_check to create vc4_plane_state.

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

The name collide with the Full KMS functions that are going to be made
public.

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

The BCM2712 has a simpler pipeline than the BCM2711, and thus the muxing
requirements are different. Create some tests to make sure we get proper
muxing decisions.

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

The BCM2712 has a simpler pipeline that can only output to a writeback
connector and two HDMI controllers.

Let's allow our kunit tests to create a mock of that pipeline.

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

Some tests will need to retrieve the output that was just allocated by
vc4_mock_atomic_add_output().

Instead of making them look them up in the DRM device, we can simply
make vc4_mock_atomic_add_output() return an error pointer that holds the
allocated output instead of the error code.

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

The DRM device pointer and the DRM encoder pointer are redundant, since
the latter is attached to the former and we can just follow the
drm_encoder->dev pointer.

Let's remove the drm_device pointer argument.

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

Testing whether the VideoCore generation we want to mock is vc5 or vc4
worked so far, but will be difficult to extend to support BCM2712 (VC6).

Convert to a switch.

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

Some code path in vc4 are conditional to a generation and cannot be
executed on others. Let's put a WARN_ON if that ever happens.

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

The BCM2712 features a simpler TXP called MOPLET. Let's add support for
it.

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

The BCM2712 has an evolution of what used to be called TXP in the
earlier SoCs, but is now called MOP.

There's a few differences still, so we can add a new compatible to deal
with them easily.

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

Starting with BCM2712, we'll have a two TXP. Let's follow the HDMI
example and add two encoder types for TXP: TXP0 and TXP1.

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

We'll have multiple TXP instances in the BCM2712, so we can't use a
single encoder type anymore. Let's tie the encoder type to the
compatible.

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

The BCM2712 MOP and MOPLET can handle addresses larger than 32bits
through an extra register. We can easily support it and make it
conditional based on the compatible through a boolean in our variant
structure.

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

The new writeback controllers that can be found on the BCM2712 require
to have their horizontal and vertical size reduced by one.

Let's tie that behaviour to the compatible so we can support both the
new and old controllers.

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

The MOPLET doesn't have the BYTE_ENABLE field to set, but the TXP and
MOP do, so let's add a boolean to control whether or not we need to set
it.

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

The TXP data structure has a name too generic for the multiple variants
we'll have to support. Let's rename it to mention the SoC it applies to.

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

The BCM2712 will have several TXP with small differences. Let's add a
structure tied to the compatible to deal with those differences.

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

The HDMI controllers found in the BCM2712 are largely the ones found in
the BCM2711 with a different PHY.

There's some difference with how timings are split between registers,
and HDMI1 is now able to run at 4k/60Hz.

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

The PixelValves found on the BCM2712 are similar to the ones found in
the previous generation.

Compared to BCM2711, the pixelvalves only drive one HDMI controller each
and HDMI1 PixelValve has a FIFO long enough to support 4k at 60Hz.

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

The HVS found in the BCM2712, while having a similar role, is very
different from the one found in the previous SoCs. Indeed, the register
layout is fairly different, and the DLIST format is new as well.

Let's introduce the needed functions to support the new HVS.

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

The BCM2712 has an improved display pipeline, most notably with a
different HVS and only HDMI and writeback outputs.

Let's introduce it as a new VideoCore generation and compatible.

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

The BCM2712 SoC comes with a new variation of the videocore display
pipeline. Let's create a new compatible for it.

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