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

The audio configuration has changed for the BCM2711, with notably a
different parent clock and a different channel configuration.

Make that modular to be able to support the BCM2711.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
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>
Link: https://patchwork.freedesktop.org/patch/msgid/85a8ca721c2d800be758c55870cea98536749680.1599120059.git-series.maxime@cerno.tech

ALSA's iec958 plugin by default sets the block start preamble
to 8, whilst this driver was programming the hardware to expect
0xF.
Amend the hardware config to match ALSA.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
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>
Link: https://patchwork.freedesktop.org/patch/msgid/d0b126deb228baf1244c91e02ac0a8f7c9c60dc5.1599120059.git-series.maxime@cerno.tech

If the encoder is disabled and re-enabled (eg mode change) all infoframes
are reset, whilst the audio subsystem know nothing about this change.
The driver therefore needs to reinstate the audio infoframe for
itself.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
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>
Link: https://patchwork.freedesktop.org/patch/msgid/cd579ccc2c9b9d2fce0ebaf32f847cedb0e4a7a2.1599120059.git-series.maxime@cerno.tech

The register range used for audio setup in the previous generations of
SoC were always the second range in the device tree. However, now that
the BCM2711 has way more register ranges, it makes sense to retrieve it
by names for it, while preserving the id-based lookup as a fallback.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
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>
Link: https://patchwork.freedesktop.org/patch/msgid/a1ba5605fe1006a1ead5262ef3d66ea5d0750381.1599120059.git-series.maxime@cerno.tech

The HSM clock needs to be running at 101% the pixel clock of the HDMI
controller, however it's shared between the two HDMI controllers, which
means that if the resolutions are different between the two HDMI
controllers, and the lowest resolution is on the second (in enable order)
controller, the first HDMI controller will end up with a smaller than
expected clock rate.

Since we don't really need an exact frequency there, we can simply change
the minimum rate we expect instead.
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/821992209cc0d7a83254bf26fe2bf507ef0994d2.1599120059.git-series.maxime@cerno.tech

The HSM clock needs to be setup at around 101% of the pixel rate. This
was done previously by setting the clock rate to 163.7MHz at probe time and
only check in mode_valid whether the mode pixel clock was under the pixel
clock +1% or not.

However, with 4k we need to change that frequency to a higher frequency
than 163.7MHz, and yet want to have the lowest clock as possible to have a
decent power saving.

Let's change that logic a bit by setting the clock rate of the HSM clock
to the pixel rate at encoder_enable time. This would work for the
BCM2711 that support 4k resolutions and has a clock that can provide it,
but we still have to take care of a 4k panel plugged on a BCM283x SoCs
that wouldn't be able to use those modes, so let's define the limit in
the variant.
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/7e692ddc231d33dd671e70ea04dd1dcf56c1ecb3.1599120059.git-series.maxime@cerno.tech

The mode_valid hook on the encoder uses a pointer to a drm_encoder called
crtc, which is pretty confusing. Let's rename it to encoder to make it
clear what it is.
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/7fbabab03992efe4a3a3640ac5ee2bb49b1c7338.1599120059.git-series.maxime@cerno.tech

The CEC_CLOCK_DIV define is not used anywhere in the driver, let's remove
it.
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/53805cc47e99a137e5f08c92fb781cc2e2134299.1599120059.git-series.maxime@cerno.tech

Similarly to the audio support, CEC support is not there yet for the
BCM2711, so let's skip entirely the CEC initialization through a variant
flag.
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/bd0c4afa83b4e121692352cdc2dd1886162c7552.1599120059.git-series.maxime@cerno.tech

The CEC init code was put directly into the bind function, which was quite
inconsistent with how the audio support was done, and would prevent us from
further changes to skip that initialisation entirely.
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/21f4717e076291522d0784a7fd3774d8e97eaf01.1599120059.git-series.maxime@cerno.tech

The HDMI driver was registering a single debugfs file so far with the name
hdmi_regs.

Obviously, this is not going to work anymore when 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/9505c1eb40b3ef3709277bf9e8af77917b249c32.1599120059.git-series.maxime@cerno.tech

The vc4 CRTC will use the encoder type to control its output clock
muxing. However, this will be different from HDMI0 to HDMI1, so let's
store our type in the variant structure so that we can support multiple
controllers later on.
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/2736a86b498551ba9dbc5803c5bb910627a2550c.1599120059.git-series.maxime@cerno.tech

Similarly to the previous patches, the timings setup in the HDMI controller
of the BCM2711 is slightly different, mostly because it supports higher
resolutions and thus needed more spaces for the various timings, resulting
in the register layout changing.

Let's add a callback for that as well.
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/0cfcbb379212f90b4abc76c0ccf3b90d1d7c0268.1599120059.git-series.maxime@cerno.tech

Similarly to the previous patches, the CSC setup is slightly different in
the BCM2711 than in the previous generations. Let's add a callback for it.
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/5c19bbf10153cb42ca0fb67e08606c8295c17236.1599120059.git-series.maxime@cerno.tech

Let's continue the implementation of hooks for the parts that change in the
BCM2711 SoC with the PHY RNG setup.
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/216155f1c0b83e622ac60a2f7d00eb707de3acba.1599120059.git-series.maxime@cerno.tech

The HDMI PHY in the BCM2711 HDMI controller is significantly more
complicated to setup than in the older BCM283x SoCs.

Let's add hooks to enable and disable the PHY.
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/7216826284dbc60a58bdacd662805d20699e5c80.1599120059.git-series.maxime@cerno.tech

The BCM2711 and BCM283x HDMI controllers use a slightly different reset
sequence, so let's add a callback to reset the 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/a34bcb493da07eae58ed704f65e72ce0748e8952.1599120059.git-series.maxime@cerno.tech

The HDMI controllers found in the BCM2711 have most of the registers
reorganized in multiple registers areas and at different offsets than
previously found.

The logic however remains pretty much the same, so it doesn't really make
sense to create a whole new driver and we should share the code as much as
possible.

Let's implement some indirection to wrap around a register and depending on
the variant will lookup the associated register on that particular variant.
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/3070236daff920e7edd11c5a72ac31fd0f6a656b.1599120059.git-series.maxime@cerno.tech

The HDMI controllers found in the BCM2711 has a pretty different clock and
registers areas than found in the older BCM283x SoCs.

Let's create a variant structure to store the various adjustments we'll
need later on, and a function to get the resources needed for one
particular version.
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/71cfa3ce3d865bbab52a0e5651bc052dc4893f11.1599120059.git-series.maxime@cerno.tech

The vc4_hdmi_connector was only used to switch between drm_connector to
drm_encoder. However, we can now use vc4_hdmi to do the switch, so that
structure is redundant.
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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/aee5120728db350b19c074de4290eafaf01e6671.1599120059.git-series.maxime@cerno.tech

Now that we don't have any users anymore, we can kill that pointer.
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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/d7ebf50319bbd902e4b7b7c39ae1612c3b38e6b2.1599120059.git-series.maxime@cerno.tech

The unbind function needs to retrieve a vc4_hdmi structure pointer through
the struct device that we're given since we want to support multiple HDMI
controllers.

However, our optional ASoC support doesn't make that trivial since it will
overwrite the device drvdata if we use it, but obviously won't if we don't
use it.

Let's make sure the fields are at the proper offset to be able to cast
between the snd_soc_card structure and the vc4_hdmi structure
transparently so we can support both cases.
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/717082cba06b5c06280f26c56c08aee512365ed3.1599120059.git-series.maxime@cerno.tech

Our CEC code also retrieves the associated vc4_hdmi by setting the
vc4_dev pointer as its private data, and then dereferences its vc4_hdmi
pointer.

In order to eventually get rid of that pointer, we can simply pass the
vc4_hdmi pointer directly.
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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/cb575cb9e13018bce131b8535e5b572dc1027877.1599120059.git-series.maxime@cerno.tech

Whenever the code needs to access the vc4_hdmi structure from a DRM
connector or encoder, it first accesses the drm_device associated to the
connector, then retrieve the drm_dev private data which gives it a
pointer to our vc4_dev, and will finally follow the vc4_hdmi pointer in
that structure.

That will also give us some trouble when having multiple controllers,
but now that we have our encoder and connector structures that are part
of vc4_hdmi, we can simply call container_of on the DRM connector or
encoder and retrieve the vc4_hdmi structure directly.
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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/536ecce5898ea75839fa3788b876009d69a5ccae.1599120059.git-series.maxime@cerno.tech

The function vc4_hdmi_connector_detect access its vc4_hdmi struct by
dereferencing the pointer in the structure vc4_dev. This will cause some
issues when we will have multiple HDMI controllers, so let's just use the
local variable for now instead of dereferencing that pointer all the time,
and we'll fix the local variable later.
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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/ef92c5582d3b2894128b2272a8ada7cbc20be3d9.1599120059.git-series.maxime@cerno.tech

The current driver only supports a single HDMI controller, and part of
the issue is that the main vc4_dev structure holds a pointer to its
(only) HDMI controller, and the HDMI registers accessors will use it to
retrieve the mapped addresses.

Let's modify those accessors to use directly the vc4_hdmi structure so
that we can eventually get rid of that single global pointer.
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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/886b955586264ce078d7d35e9b8ef9ae51675c27.1599120059.git-series.maxime@cerno.tech

The driver isn't consistent with the name given to the vc4_hdmi
structure pointer in its functions. Make sure to use a consistent name.
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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/696be840dc427245afe94b43e0b829c728d948a7.1599120059.git-series.maxime@cerno.tech

Now that we are passing the vc4_hdmi structure to the connector init
function, we can simply use the pointer in that structure instead of
having the pointer as an argument.
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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/4fe1b45fe45e4ba57d40154da010807d4e5db86c.1599120059.git-series.maxime@cerno.tech

the vc4_hdmi driver has some custom structures to hold the data it needs to
associate with the drm_encoder and drm_connector structures.

However, it allocates them separately from the vc4_hdmi structure which
makes it more complicated than it needs to be.

Move those structures to be contained by vc4_hdmi and update the code
accordingly.
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/93b418d63c876355af2b3d3afebe31a256268623.1599120059.git-series.maxime@cerno.tech

We will need to share the vc4_hdmi and related structures with multiple
files, so let's create a header for it.
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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/db3ff2babc914e38e86f794c4e49128697aed887.1599120059.git-series.maxime@cerno.tech

We're calling vc4_debugfs_add_file with our struct vc4_hdmi pointer set
in the private field, but we don't use that field and go through the
main struct vc4_dev to get it.

Let's use the private field directly, that will save us some trouble
later on.
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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/24028dc06c379dbc71f98e027cce2839fdd446ce.1599120059.git-series.maxime@cerno.tech

The previous generations were only supporting a single HDMI controller, but
that's about to change, so put an index as well to differentiate between
the two controllers.
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: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/84e11e4793aaa30d6e5c56e305d22404ac5a932d.1599120059.git-series.maxime@cerno.tech

If the vc4 hdmi driver loads before the pixel clock is available we
see a spurious "*ERROR* Failed to get pixel clock" error.
Signed-off-by: NJames Hilliard <james.hilliard1@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200525012859.267433-1-james.hilliard1@gmail.com

The vc4 driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305155950.2705-19-tzimmermann@suse.de