The current HVS muxing code will consider the CRTCs in a given state to
setup their muxing in the HVS, and disable the other CRTCs muxes.

However, it's valid to only update a single CRTC with a state, and in this
situation we would mux out a CRTC that was enabled but left untouched by
the new state.

Fix this by setting a flag on the CRTC state when the muxing has been
changed, and only change the muxing configuration when that flag is there.

Fixes: 87ebcd42 ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201120144245.398711-3-maxime@cerno.tech

If a CRTC is enabled but not active, and that we're then doing a page
flip on another CRTC, drm_atomic_get_crtc_state will bring the first
CRTC state into the global state, and will make us wait for its vblank
as well, even though that might never occur.

Instead of creating the list of the free channels each time atomic_check
is called, and calling drm_atomic_get_crtc_state to retrieve the
allocated channels, let's create a private state object in the main
atomic state, and use it to store the available channels.

Since vc4 has a semaphore (with a value of 1, so a lock) in its commit
implementation to serialize all the commits, even the nonblocking ones, we
are free from the use-after-free race if two subsequent commits are not ran
in their submission order.

Fixes: 87ebcd42 ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201120144245.398711-2-maxime@cerno.tech

There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi
chip and some resolutions, most notably 1440p at 60Hz.

In such a case, we can either reject entirely the mode, or lower slightly
the pixel frequency to remove the overlap. Let's go for the latter.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201029134018.1948636-2-maxime@cerno.tech

We've had a number of muxing corner-cases with specific ways to reproduce
them, so let's document them to make sure they aren't lost and introduce
regressions later on.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201105135656.383350-6-maxime@cerno.tech

The code that assigns HVS channels during atomic_check is starting to grow
a bit big, let's move it into a separate function.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201105135656.383350-5-maxime@cerno.tech

The NUM_CHANNELS define has a pretty generic name and was right before the
function using it. Let's move to something that makes the hardware-specific
nature more obvious, and to a more appropriate place.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201105135656.383350-4-maxime@cerno.tech

NUM_OUTPUTS isn't used anymore, let's remove it.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201105135656.383350-3-maxime@cerno.tech

Even though it was pointed in the review by Daniel, and I thought to have
fixed it while applying the patches, but it turns out I forgot to commit
the fixes in the process. Properly fix it this time.

Fixes: dcda7c28 ("drm/vc4: kms: Add functions to create the state objects")
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201105135656.383350-2-maxime@cerno.tech

The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels
per clock cycle, and cannot deal with odd timings.

Let's reject any mode with such timings.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201029122522.1917579-2-maxime@cerno.tech

The HDMI controller cannot go above a certain pixel rate limit depending on
the generations, but that limit is only enforced in mode_valid at the
moment, which means that we won't advertise modes that exceed that limit,
but the userspace is still free to try to setup a mode that would.

Implement atomic_check to make sure we check it in that scenario too.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201029122522.1917579-1-maxime@cerno.tech

The commit dcda7c28 ("drm/vc4: kms: Add functions to create the state
objects") removed the last users of the vc4 variable, but didn't remove
that variable resulting in a warning.

Fixes: dcda7c28 ("drm/vc4: kms: Add functions to create the state objects")
Reported-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201102162908.1436567-1-maxime@cerno.tech

In order to make the vc4_kms_load code and error path a bit easier to
read and extend, add functions to create state objects, and use managed
actions to cleanup if needed.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201029190104.2181730-6-maxime@cerno.tech

We can simplify a bit the bind code, its error path and unbind by using
the managed devm_drm_dev_alloc function.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20201029190104.2181730-5-maxime@cerno.tech

We have a helper to retrieve the vc4_dev structure from the drm_device one
when needed, so let's use it consistently.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20201029190104.2181730-4-maxime@cerno.tech

The job queue needs to be cleaned up using vc4_gem_destroy, but it's
not used consistently (vc4_drv's bind calls it in its error path, but
doesn't in unbind), and we can make that automatic through a managed
action. Let's remove the requirement to call vc4_gem_destroy.

Fixes: d5b1a78a ("drm/vc4: Add support for drawing 3D frames.")
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20201029190104.2181730-3-maxime@cerno.tech

Using drmm_mode_config_init instead of drm_mode_config_init allows us to
cleanup a bit the error path.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201029190104.2181730-2-maxime@cerno.tech

The BO cache needs to be cleaned up using vc4_bo_cache_destroy, but it's
not used consistently (vc4_drv's bind calls it in its error path, but
doesn't in unbind), and we can make that automatic through a managed
action. Let's remove the requirement to call vc4_bo_cache_destroy.

Fixes: c826a6e1 ("drm/vc4: Add a BO cache.")
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20201029190104.2181730-1-maxime@cerno.tech

Most of the helpers to retrieve vc4 structures from the DRM base structures
rely on the fact that the first member of the vc4 structure is the DRM one
and just cast the pointers between them.

However, this is pretty fragile especially since there's no check to make
sure that the DRM structure is indeed at the offset 0 in the structure, so
let's use container_of to make it more robust.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201028123752.1733242-1-maxime@cerno.tech

Since the components for a given device in ASoC are identified by their
name, it makes sense to add one even though it's not strictly necessary.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200708144555.718404-1-maxime@cerno.tech

When running the trigger hook, ALSA by default will take a spinlock, and
thus will run the trigger hook in atomic context.

However, our HDMI driver will send the infoframes as part of the trigger
hook, and part of that process is to wait for a bit to be cleared for up to
100ms. To be nicer to the system, that wait has some usleep_range that
interact poorly with the atomic context.

There's several ways we can fix this, but the more obvious one is to make
ALSA take a mutex instead by setting the nonatomic flag on the DAI link.
That doesn't work though, since now the cyclic callback installed by the
dmaengine helpers in ALSA will take a mutex, while that callback is run by
dmaengine's virt-chan code in a tasklet where sleeping is not allowed
either.

Given the delay we need to poll the bit for, changing the usleep_range for
a udelay and keep running it from a context where interrupts are disabled
is not really a good option either.

However, we can move the infoframe setup code in the hw_params hook, like
is usually done in other HDMI controllers, that isn't protected by a
spinlock and thus where we can sleep. Infoframes will be sent on a regular
basis anyway, and since hw_params is where the audio parameters that end up
in the infoframes are setup, this also makes a bit more sense.

Fixes: bb7d7856 ("drm/vc4: Add HDMI audio support")
Suggested-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Reviewed-by: NMark Brown <broonie@kernel.org>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201027101558.427256-1-maxime@cerno.tech

There is a problem that if vc4_drm bind fails, a memory leak occurs on
the drm_property_create side. Add error handding for drm_mode_config.
Signed-off-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.kwon@samsung.com

The HVS FIFOs are currently assigned each time we have an atomic_check
for all the enabled CRTCs.

However, if we are running multiple outputs in parallel and we happen to
disable the first (by index) CRTC, we end up changing the assigned FIFO
of the second CRTC without disabling and reenabling the pixelvalve which
ends up in a stall and eventually a VBLANK timeout.

In order to fix this, we can create a special value for our assigned
channel to mark it as disabled, and if our CRTC already had an assigned
channel in its previous state, we keep on using it.

Fixes: 87ebcd42 ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200923084032.218619-2-maxime@cerno.tech

The current CRTC state reset hook in vc4 allocates a vc4_crtc_state
structure as a drm_crtc_state, and relies on the fact that vc4_crtc_state
embeds drm_crtc_state as its first member, and therefore can be safely
cast.

However, this is pretty fragile especially since there's no check for this
in place, and we're going to need to access vc4_crtc_state member at reset
so this looks like a good occasion to make it more robust.

Fixes: 6d6e5003 ("drm/vc4: Allocate the right amount of space for boot-time CRTC state.")
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200923084032.218619-1-maxime@cerno.tech

The HVS has three FIFOs that can be assigned to a number of PixelValves
through a mux.

However, changing that FIFO requires that we disable and then enable the
pixelvalve, so we want to assign FIFOs to all the enabled CRTCs, and not
just the active ones.

Fixes: 87ebcd42 ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200918145918.101068-1-maxime@cerno.tech

The vc4 display engine has a first controller called the HVS that will
perform the composition of the planes. That HVS has 3 FIFOs and can
therefore compose planes for up to three outputs. The timings part is
generated through a component called the Pixel Valve, and the BCM2711 has 6
of them.

Thus, the HVS has some bits to control which FIFO gets output to which
Pixel Valve. The current code supports that muxing by looking at all the
CRTCs in a new DRM atomic state in atomic_check, and given the set of
constraints that we have, assigns FIFOs to CRTCs or reject the mode
entirely. The actual muxing will occur during atomic_commit.

However, that doesn't work if only a fraction of the CRTCs' state is
updated in that state, since it will ignore the CRTCs that are kept running
unmodified, and will thus unassign its associated FIFO, and later disable
it.

In order to make the code work as expected, let's pull the CRTC state of
all the enabled CRTC in our atomic_check so that we can operate on all the
running CRTCs, no matter whether they are affected by the new state or not.

Fixes: 87ebcd42 ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200917121623.42023-1-maxime@cerno.tech

Handing the return value of drm_universal_plane_init to fix the following
W=1 kernel build warning(s):
vc4_plane.c: In function ‘vc4_plane_init’:
vc4_plane.c:1340:6: warning: variable ‘ret’ set but not
used [-Wunused-but-set-variable]
Signed-off-by: NTian Tao <tiantao6@hisilicon.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1599811777-34093-1-git-send-email-tiantao6@hisilicon.com

Clang warns:

drivers/gpu/drm/vc4/vc4_plane.c:901:27: warning: operator '?:' has lower
precedence than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
                                fb->format->has_alpha ?
                                ~~~~~~~~~~~~~~~~~~~~~ ^
drivers/gpu/drm/vc4/vc4_plane.c:901:27: note: place parentheses around
the '|' expression to silence this warning
                                fb->format->has_alpha ?
                                ~~~~~~~~~~~~~~~~~~~~~ ^
drivers/gpu/drm/vc4/vc4_plane.c:901:27: note: place parentheses around
the '?:' expression to evaluate it first
                                fb->format->has_alpha ?
                                ~~~~~~~~~~~~~~~~~~~~~~^
1 warning generated.

Add the parentheses as that was clearly intended, otherwise
SCALER5_CTL2_ALPHA_PREMULT won't be added to the list.

Fixes: c54619b0 ("drm/vc4: Add support for the BCM2711 HVS5")
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/1150Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910171831.4112580-1-natechancellor@gmail.com

Clang warns 100+ times in the vc4 driver along the lines of:

drivers/gpu/drm/vc4/vc4_hdmi_phy.c:518:13: warning: implicit conversion
from enumeration type 'enum vc4_hdmi_field' to different enumeration
type 'enum vc4_hdmi_regs' [-Wenum-conversion]
        HDMI_WRITE(HDMI_TX_PHY_POWERDOWN_CTL,
        ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~

The HDMI_READ and HDMI_WRITE macros pass in enumerators of type
vc4_hdmi_field but vc4_hdmi_write and vc4_hdmi_read expect a enumerator
of type vc4_hdmi_regs, causing a warning for every instance of this.
Update the parameter type so there is no more mismatch.

Fixes: 311e305f ("drm/vc4: hdmi: Implement a register layout abstraction")
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/1149Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910170401.3857250-1-natechancellor@gmail.com

The devm_ioremap() function never returns error pointers, it returns
NULL.

Fixes: 83239891 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910100825.GC79916@mwanda

The variant->registers[] has ->num_registers elements so the >
comparison needs to be changes to >= to prevent an out of bounds
access.

Fixes: 311e305f ("drm/vc4: hdmi: Implement a register layout abstraction")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910100748.GA79916@mwanda

card->owner is a required property and since commit 81033c6b ("ALSA:
core: Warn on empty module") a warning is issued if it is empty. Fix lack
of it. This fixes following warning observed on RaspberryPi 3B board
with ARM 32bit kernel and multi_v7_defconfig:

------------[ cut here ]------------
WARNING: CPU: 1 PID: 210 at sound/core/init.c:207 snd_card_new+0x378/0x398 [snd]
Modules linked in: vc4(+) snd_soc_core ac97_bus snd_pcm_dmaengine bluetooth snd_pcm snd_timer crc32_arm_ce raspberrypi_hwmon snd soundcore ecdh_generic ecc bcm2835_thermal phy_generic
CPU: 1 PID: 210 Comm: systemd-udevd Not tainted 5.8.0-rc1-00027-g81033c6b #1087
Hardware name: BCM2835
[<c03113c0>] (unwind_backtrace) from [<c030bcb4>] (show_stack+0x10/0x14)
[<c030bcb4>] (show_stack) from [<c071cef8>] (dump_stack+0xd4/0xe8)
[<c071cef8>] (dump_stack) from [<c0345bfc>] (__warn+0xdc/0xf4)
[<c0345bfc>] (__warn) from [<c0345cc4>] (warn_slowpath_fmt+0xb0/0xb8)
[<c0345cc4>] (warn_slowpath_fmt) from [<bf02ff74>] (snd_card_new+0x378/0x398 [snd])
[<bf02ff74>] (snd_card_new [snd]) from [<bf11f0b4>] (snd_soc_bind_card+0x280/0x99c [snd_soc_core])
[<bf11f0b4>] (snd_soc_bind_card [snd_soc_core]) from [<bf12f000>] (devm_snd_soc_register_card+0x34/0x6c [snd_soc_core])
[<bf12f000>] (devm_snd_soc_register_card [snd_soc_core]) from [<bf165654>] (vc4_hdmi_bind+0x43c/0x5f4 [vc4])
[<bf165654>] (vc4_hdmi_bind [vc4]) from [<c09d660c>] (component_bind_all+0xec/0x24c)
[<c09d660c>] (component_bind_all) from [<bf15c44c>] (vc4_drm_bind+0xd4/0x174 [vc4])
[<bf15c44c>] (vc4_drm_bind [vc4]) from [<c09d6ac0>] (try_to_bring_up_master+0x160/0x1b0)
[<c09d6ac0>] (try_to_bring_up_master) from [<c09d6f38>] (component_master_add_with_match+0xd0/0x104)
[<c09d6f38>] (component_master_add_with_match) from [<bf15c588>] (vc4_platform_drm_probe+0x9c/0xbc [vc4])
[<bf15c588>] (vc4_platform_drm_probe [vc4]) from [<c09df740>] (platform_drv_probe+0x6c/0xa4)
[<c09df740>] (platform_drv_probe) from [<c09dd6f0>] (really_probe+0x210/0x350)
[<c09dd6f0>] (really_probe) from [<c09dd940>] (driver_probe_device+0x5c/0xb4)
[<c09dd940>] (driver_probe_device) from [<c09ddb38>] (device_driver_attach+0x58/0x60)
[<c09ddb38>] (device_driver_attach) from [<c09ddbc0>] (__driver_attach+0x80/0xbc)
[<c09ddbc0>] (__driver_attach) from [<c09db820>] (bus_for_each_dev+0x68/0xb4)
[<c09db820>] (bus_for_each_dev) from [<c09dc9f8>] (bus_add_driver+0x130/0x1e8)
[<c09dc9f8>] (bus_add_driver) from [<c09de648>] (driver_register+0x78/0x110)
[<c09de648>] (driver_register) from [<c0302038>] (do_one_initcall+0x50/0x220)
[<c0302038>] (do_one_initcall) from [<c03db544>] (do_init_module+0x60/0x210)
[<c03db544>] (do_init_module) from [<c03da4f8>] (load_module+0x1e34/0x2338)
[<c03da4f8>] (load_module) from [<c03dac00>] (sys_finit_module+0xac/0xbc)
[<c03dac00>] (sys_finit_module) from [<c03000c0>] (ret_fast_syscall+0x0/0x54)
Exception stack(0xeded9fa8 to 0xeded9ff0)
...
---[ end trace 6414689569c2bc08 ]---

Fixes: bb7d7856 ("drm/vc4: Add HDMI audio support")
Suggested-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200701073949.28941-1-m.szyprowski@samsung.com

The BCM2711 has a reworked display pipeline, and the load tracker needs
some adjustment to operate properly. Let's add a compatible for BCM2711
and disable the load tracker until properly supported.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NChanwoo Choi <cw00.choi@samsung.com>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/beac4f9ef0261bca731a0402c8354e9af740519c.1599120059.git-series.maxime@cerno.tech

Now that the driver is ready for it, let's bring in the HDMI controllers
variants for the BCM2711.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NChanwoo Choi <cw00.choi@samsung.com>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b540c7a9ebb7ad51da39271a8388b69c7e27e582.1599120059.git-series.maxime@cerno.tech

The BCM2711 has another clock that needs to be ramped up depending on the
pixel rate: the pixel BVB clock. Add the code to adjust that clock when
changing the mode.

[Maxime: Changed the commit log, used clk_set_min_rate]
Signed-off-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20200901040759.29992-3-hoegeun.kwon@samsung.com
Link: https://patchwork.freedesktop.org/patch/msgid/d757ddd6549da140f178563e5fd2bf1d129913fd.1599120059.git-series.maxime@cerno.tech

In order to avoid pixels getting stuck in an unflushable FIFO, we need when
we disable the HDMI controller to switch away from getting our pixels from
the pixelvalve and instead use blank pixels, and switch back to the
pixelvalve when we enable the HDMI controller.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NChanwoo Choi <cw00.choi@samsung.com>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fde3efb1ad79f4476a73d310cbba3ec07dc6dabe.1599120059.git-series.maxime@cerno.tech

The VID_CTL setup is done in several places in the driver even though it's
not really required. Let's simplify it a bit to do the configuration in one
go.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NChanwoo Choi <cw00.choi@samsung.com>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/08e7ebb605a560fcc149b69b4af52753a7870b2f.1599120059.git-series.maxime@cerno.tech

In order to prevent some pixels getting stuck in an unflushable FIFO on
bcm2711, we need to enable the HVS, the pixelvalve (the CRTC) and the HDMI
controller (the encoder) in an intertwined way, and with tight delays.

However, the atomic callbacks don't really provide a way to work with
either constraints, so we need to roll our own callbacks so that we can
provide those guarantees.

Since those callbacks have been implemented and called in the CRTC code, we
can just implement them in the HDMI driver now.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NChanwoo Choi <cw00.choi@samsung.com>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2e9226d971117065f3b97e597f04f7fe2f0c134c.1599120059.git-series.maxime@cerno.tech

In order to avoid a pixel getting stuck in an unflushable FIFO, we need to
recenter the FIFO every time we're doing a modeset and not only if we're
connected to an HDMI monitor.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NChanwoo Choi <cw00.choi@samsung.com>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b3faaf05ac6c4d3c364d28fa441571eb85903269.1599120059.git-series.maxime@cerno.tech

The current code has some logic, disabled by default, to dump the register
setup in the HDMI controller.

However, since we're going to split those functions in multiple, shorter,
functions that only make sense where they are called in sequence, keeping
the register dump makes little sense.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NChanwoo Choi <cw00.choi@samsung.com>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c8c8d388f2d32fc3536336be36d003a862487eb7.1599120059.git-series.maxime@cerno.tech

The HDMI driver was registering a single ALSA card so far with the name
vc4-hdmi.

Obviously, this is not going to work anymore when we will have multiple
HDMI controllers since we will end up trying to register two files with the
same name.

Let's use the variant to avoid that name conflict.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Tested-by: NChanwoo Choi <cw00.choi@samsung.com>
Tested-by: NHoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e60a37444e848a384a45707a21d6df8883115f86.1599120059.git-series.maxime@cerno.tech