If our HSM clock has not been properly initialized, any register access
will silently lock up the system.

Let's check that this can't happen by adding a check for the rate before
any register access, and error out otherwise.

Link: https://lore.kernel.org/dri-devel/20220922145448.w3xfywkn5ecak2et@pengutronix.de/Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220929-rpi-pi3-unplugged-fixes-v1-2-cd22e962296c@cerno.tech

This is a revert of commit fd5894fa ("drm/vc4: hdmi: Remove clock
rate initialization"), with the code slightly moved around.

It turns out that we can't downright remove that code from the driver,
since the Pi0-3 and Pi4 are in different cases, and it only works for
the Pi4.

Indeed, the commit mentioned above was relying on the RaspberryPi
firmware clocks driver to initialize the rate if it wasn't done by the
firmware. However, the Pi0-3 are using the clk-bcm2835 clock driver that
wasn't doing this initialization. We therefore end up with the clock not
being assigned a rate, and the CPU stalling when trying to access a
register.

We can't move that initialization in the clk-bcm2835 driver, since the
HSM clock we depend on is actually part of the HDMI power domain, so any
rate setup is only valid when the power domain is enabled. Thus, we
reinstated the minimum rate setup at runtime_suspend, which should
address both issues.

Link: https://lore.kernel.org/dri-devel/20220922145448.w3xfywkn5ecak2et@pengutronix.de/
Fixes: fd5894fa ("drm/vc4: hdmi: Remove clock rate initialization")
Reported-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220929-rpi-pi3-unplugged-fixes-v1-1-cd22e962296c@cerno.tech

The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In
order to set it up properly, in vc4_hdmi_audio_init(), our HDMI driver
will register a device matching the HDMI codec driver, and then register
an ASoC card using that codec.

However, if vc4 is compiled as a module, chances are that the hdmi-codec
driver will be too. In such a case, the module loader will have a very
narrow window to load the module between the device registration and the
card registration.

If it fails to load the module in time, the card registration will fail
with EPROBE_DEFER, and we'll abort the audio initialisation,
unregistering the HDMI codec device in the process.

The next time the bind callback will be run, it's likely that we end up
missing that window again, effectively preventing vc4 to probe entirely.

In order to prevent this, we can create a soft dependency of the vc4
driver on the HDMI codec one so that we're sure the HDMI codec will be
loaded before the VC4 module is, and thus we'll never end up in the
previous situation.

Fixes: 91e99e11 ("drm/vc4: hdmi: Register HDMI codec")
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220902144111.3424560-1-maxime@cerno.tech

During a hotplug cycle (such as a TV going out of suspend, or when the
cable is disconnected and reconnected), the expectation is that the same
state used before the disconnection is reused until the next commit.

However, the HDMI scrambling requires that some flags are set in the
monitor, and those flags are very likely to be reset when the cable has
been disconnected. This will thus result in a blank display, even if the
display pipeline configuration hasn't been modified or is in the exact
same state.

The solution we've had so far is to enable the scrambling-related bits
again on reconnection, but the HDMI 2.0 specification (Section 6.1.3.1 -
Scrambling Control) requires that the scrambling enable bit is set
before sending any scrambled video signal. Using that solution thus
breaks that expectation.

The solution used by i915 is to do a full modeset on the connector so
that we disable the video signal, enable the scrambling bit, and enable
the video signal again.

As such, we took that code and plugged it into vc4. It probably could
have been turned into an helper, but it proved to be difficult for
several reasons:

  * i915 has fairly different structures than simpler KMS drivers such
    as vc4, so doing some code that works with both proved to be
    difficult;

  * Other simpler drivers could reuse some of it (tegra, dw-hdmi), but
    it would still require to move some parameters currently stored in
    private structure that are needed to compute whether the scrambling
    is needed or not, and then inform the driver that it needs to be
    enabled. Some of those parameters are already in core structures
    (drm_display_mode, drm_display_info, bpc), but the output format
    isnt't. Adding it is fairly challenging since unlike the TMDS char
    rate or mode, there's no consensus on what format to pick in
    drivers, so it's not possible to write some generic code that can
    depend on it.

For these reasons, we chose to duplicate the code for now, until someone
else really needs it as well, in which case we will be able to convert
it into a generic helper.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-8-maxime@cerno.tech

We'll need it earlier in the driver, so let's move it next to the other
scrambling-related helpers.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-7-maxime@cerno.tech

We'll need the locking context in future patch, so let's convert .detect
to .detect_ctx.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-6-maxime@cerno.tech

Our detect callback has a bunch of operations to perform depending on
the current and last status of the connector, such a setting the CEC
physical address or enabling the scrambling again.

This is currently dealt with a bunch of if / else statetements that make
it fairly difficult to read and extend.

Let's move all that logic to a function of its own.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-5-maxime@cerno.tech

We recently introduced a new mutex to protect concurrent execution of
ALSA and KMS hooks, and the concurrent access to some of vc4_hdmi
fields.

However, using it in the detect hook was creating a reentrency issue
with CEC code. Indeed, calling cec_s_phys_addr_from_edid from detect
might call the CEC adap_enable hook with the lock held, eventually
resulting in a deadlock.

Since we didn't really need to protect anything at the moment in the CEC
code, the decision was made to ignore the mutex in those CEC hooks,
working around the issue.

However, we can have the same thing happening if we end up triggering a
mode set from the detect callback, for example using
drm_atomic_helper_connector_hdmi_reset_link().

Since we don't really need to protect anything in detect either, let's
just drop the lock in detect, and add it again in CEC.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-4-maxime@cerno.tech

Even though vc4_hdmi_supports_scrambling takes a mode as an argument, it
never uses it. Let's remove it.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-3-maxime@cerno.tech

We don't modify the drm_display_mode pointer we have in the driver in
most places, so let's make them const.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-2-maxime@cerno.tech

This commit fixes vertical timings of the VEC (composite output) modes
to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R
standards.

Previous timings were actually defined as 502 and 601 lines, resulting
in non-standard 62.69 Hz and 52 Hz signals being generated,
respectively.
Signed-off-by: NMateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Acked-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-28-459522d653a7@cerno.tech

Let's remove the superfluous tv_mode field, which was redundant with the
mode field in struct drm_tv_connector_state.
Signed-off-by: NMateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-27-459522d653a7@cerno.tech

Change the mode_set function pointer logic to declarative config0,
config1 and custom_freq fields, to make TV mode setting logic more
concise and uniform.
Signed-off-by: NMateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
[Maxime: Fixed != 0 check, added tv_mode variable]
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-26-459522d653a7@cerno.tech

The VC4 VEC driver still uses legacy enable and disable hook
implementation. Let's convert to the atomic variants.
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-25-459522d653a7@cerno.tech

The mode_fixup hooks are deprecated, and the behaviour we implement is the
default one anyway. Let's remove it.
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-24-459522d653a7@cerno.tech

In vc4_hvs_dump_state() potentially freed resources are protected from
being accessed with drm_dev_enter()/drm_dev_exit().

Also include drm_print_regset32() in the protected section, since
drm_print_regset32() does access memory that is typically mapped via
devm_* calls.

Fixes: 969cfae1 ("drm/vc4: hvs: Protect device resources after removal")
Signed-off-by: NDanilo Krummrich <dakr@redhat.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220824161327.330627-5-dakr@redhat.com

(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.

However, the DRM device isn't freed as long as the last user closed it,
hence userspace can still call into the driver.

Therefore protect the critical sections which are accessing those
resources with drm_dev_enter() and drm_dev_exit().

Fixes: 7cc4214c ("drm/vc4: crtc: Switch to drmm_kzalloc")
Signed-off-by: NDanilo Krummrich <dakr@redhat.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220824161327.330627-4-dakr@redhat.com

(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.

However, the DRM device isn't freed as long as the last user closed it,
hence userspace can still call into the driver.

Therefore protect the critical sections which are accessing those
resources with drm_dev_enter() and drm_dev_exit().

Fixes: 9872c7a3 ("drm/vc4: plane: Switch to drmm_universal_plane_alloc()")
Signed-off-by: NDanilo Krummrich <dakr@redhat.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220824161327.330627-3-dakr@redhat.com

In vc4_hdmi_encoder_{pre,post}_crtc_enable() commit cd00ed51
("drm/vc4: hdmi: Protect device resources after removal") missed to
unlock the mutex before returning due to drm_dev_enter() indicating the
device being unplugged.

Fixes: cd00ed51 ("drm/vc4: hdmi: Protect device resources after removal")
Signed-off-by: NDanilo Krummrich <dakr@redhat.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220824161327.330627-2-dakr@redhat.com

The current code tries to handle the case where CONFIG_PM isn't selected
by first calling our runtime_resume implementation and then properly
report the power state to the runtime_pm core.

This allows to have a functionning device even if pm_runtime_get_*
functions are nops.

However, the device power state if CONFIG_PM is enabled is
RPM_SUSPENDED, and thus our vc4_hdmi_write() and vc4_hdmi_read() calls
in the runtime_pm hooks will now report a warning since the device might
not be properly powered.

Even more so, we need CONFIG_PM enabled since the previous RaspberryPi
have a power domain that needs to be powered up for the HDMI controller
to be usable.

The previous patch has created a dependency on CONFIG_PM, now we can
just assume it's there and only call pm_runtime_resume_and_get() to make
sure our device is powered in bind.

Link: https://lore.kernel.org/r/20220629123510.1915022-39-maxime@cerno.techAcked-by: NThomas Zimmermann <tzimmermann@suse.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
(cherry picked from commit 53565c28)
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>

We already depend on runtime PM to get the power domains and clocks for
most of the devices supported by the vc4 driver, so let's just select it
to make sure it's there.

Link: https://lore.kernel.org/r/20220629123510.1915022-38-maxime@cerno.techAcked-by: NThomas Zimmermann <tzimmermann@suse.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
(cherry picked from commit f1bc386b)
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>

This driver includes the deprecated OF GPIO header <linux/of_gpio.h>
yet fail to use symbols from it, so drop the include.

Cc: Emma Anholt <emma@anholt.net>
Cc: Maxime Ripard <mripard@kernel.org>
Signed-off-by: NMaíra Canal <mairacanal@riseup.net>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220812205746.609107-6-mairacanal@riseup.net

The field paddr of struct drm_gem_dma_object holds a DMA address, which
might actually be a physical address. However, depending on the platform,
it can also be a bus address or a virtual address managed by an IOMMU.

Hence, rename the field to dma_addr, which is more applicable.

In order to do this renaming the following coccinelle script was used:

```
	@@
	struct drm_gem_dma_object *gem;
	@@

	- gem->paddr
	+ gem->dma_addr

	@@
	struct drm_gem_dma_object gem;
	@@

	- gem.paddr
	+ gem.dma_addr

	@exists@
	typedef dma_addr_t;
	symbol paddr;
	@@

	dma_addr_t paddr;
	<...
	- paddr
	+ dma_addr
	...>

	@@
	symbol paddr;
	@@
	dma_addr_t
	- paddr
	+ dma_addr
	;

```

This patch is compile-time tested with:

```
	make ARCH={x86_64,arm,arm64} allyesconfig
	make ARCH={x86_64,arm,arm64} drivers/gpu/drm`
```
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Suggested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDanilo Krummrich <dakr@redhat.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220802000405.949236-5-dakr@redhat.com

Rename "GEM CMA" helpers to "GEM DMA" helpers - considering the
hierarchy of APIs (mm/cma -> dma -> gem dma) calling them "GEM
DMA" seems to be more applicable.

Besides that, commit e57924d4 ("drm/doc: Task to rename CMA helpers")
requests to rename the CMA helpers and implies that people seem to be
confused about the naming.

In order to do this renaming the following script was used:

```
	#!/bin/bash

	DIRS="drivers/gpu include/drm Documentation/gpu"

	REGEX_SYM_UPPER="[0-9A-Z_\-]"
	REGEX_SYM_LOWER="[0-9a-z_\-]"

	REGEX_GREP_UPPER="(${REGEX_SYM_UPPER}*)(GEM)_CMA_(${REGEX_SYM_UPPER}*)"
	REGEX_GREP_LOWER="(${REGEX_SYM_LOWER}*)(gem)_cma_(${REGEX_SYM_LOWER}*)"

	REGEX_SED_UPPER="s/${REGEX_GREP_UPPER}/\1\2_DMA_\3/g"
	REGEX_SED_LOWER="s/${REGEX_GREP_LOWER}/\1\2_dma_\3/g"

	# Find all upper case 'CMA' symbols and replace them with 'DMA'.
	for ff in $(grep -REHl "${REGEX_GREP_UPPER}" $DIRS)
	do
	       sed -i -E "$REGEX_SED_UPPER" $ff
	done

	# Find all lower case 'cma' symbols and replace them with 'dma'.
	for ff in $(grep -REHl "${REGEX_GREP_LOWER}" $DIRS)
	do
	       sed -i -E "$REGEX_SED_LOWER" $ff
	done

	# Replace all occurrences of 'CMA' / 'cma' in comments and
	# documentation files with 'DMA' / 'dma'.
	for ff in $(grep -RiHl " cma " $DIRS)
	do
		sed -i -E "s/ cma / dma /g" $ff
		sed -i -E "s/ CMA / DMA /g" $ff
	done

	# Rename all 'cma_obj's to 'dma_obj'.
	for ff in $(grep -RiHl "cma_obj" $DIRS)
	do
		sed -i -E "s/cma_obj/dma_obj/g" $ff
	done
```

Only a few more manual modifications were needed, e.g. reverting the
following modifications in some DRM Kconfig files

    -       select CMA if HAVE_DMA_CONTIGUOUS
    +       select DMA if HAVE_DMA_CONTIGUOUS

as well as manually picking the occurrences of 'CMA'/'cma' in comments and
documentation which relate to "GEM CMA", but not "FB CMA".

Also drivers/gpu/drm/Makefile was fixed up manually after renaming
drm_gem_cma_helper.c to drm_gem_dma_helper.c.

This patch is compile-time tested building a x86_64 kernel with
`make allyesconfig && make drivers/gpu/drm`.
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDanilo Krummrich <dakr@redhat.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> #drivers/gpu/drm/arm
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220802000405.949236-4-dakr@redhat.com

Rename "FB CMA" helpers to "FB DMA" helpers - considering the hierarchy
of APIs (mm/cma -> dma -> fb dma) calling them "FB DMA" seems to be
more applicable.

Besides that, commit e57924d4 ("drm/doc: Task to rename CMA helpers")
requests to rename the CMA helpers and implies that people seem to be
confused about the naming.

In order to do this renaming the following script was used:

```
	#!/bin/bash

	DIRS="drivers/gpu include/drm Documentation/gpu"

	REGEX_SYM_UPPER="[0-9A-Z_\-]"
	REGEX_SYM_LOWER="[0-9a-z_\-]"

	REGEX_GREP_UPPER="(${REGEX_SYM_UPPER}*)(FB)_CMA_(${REGEX_SYM_UPPER}*)"
	REGEX_GREP_LOWER="(${REGEX_SYM_LOWER}*)(fb)_cma_(${REGEX_SYM_LOWER}*)"

	REGEX_SED_UPPER="s/${REGEX_GREP_UPPER}/\1\2_DMA_\3/g"
	REGEX_SED_LOWER="s/${REGEX_GREP_LOWER}/\1\2_dma_\3/g"

	# Find all upper case 'CMA' symbols and replace them with 'DMA'.
	for ff in $(grep -REHl "${REGEX_GREP_UPPER}" $DIRS)
	do
	       sed -i -E "$REGEX_SED_UPPER" $ff
	done

	# Find all lower case 'cma' symbols and replace them with 'dma'.
	for ff in $(grep -REHl "${REGEX_GREP_LOWER}" $DIRS)
	do
	       sed -i -E "$REGEX_SED_LOWER" $ff
	done

	# Replace all occurrences of 'CMA' / 'cma' in comments and
	# documentation files with 'DMA' / 'dma'.
	for ff in $(grep -RiHl " cma " $DIRS)
	do
		sed -i -E "s/ cma / dma /g" $ff
		sed -i -E "s/ CMA / DMA /g" $ff
	done
```

Only a few more manual modifications were needed, e.g. reverting the
following modifications in some DRM Kconfig files

    -       select CMA if HAVE_DMA_CONTIGUOUS
    +       select DMA if HAVE_DMA_CONTIGUOUS

as well as manually picking the occurrences of 'CMA'/'cma' in comments and
documentation which relate to "FB CMA", but not "GEM CMA".

This patch is compile-time tested building a x86_64 kernel with
`make allyesconfig && make drivers/gpu/drm`.
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDanilo Krummrich <dakr@redhat.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> #drivers/gpu/drm/arm
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220802000405.949236-3-dakr@redhat.com

Quite a lot of drivers include the drm_fb_cma_helper.h header file
without actually making use of it's provided API, hence remove those
includes.
Suggested-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDanilo Krummrich <dakr@redhat.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220802000405.949236-2-dakr@redhat.com

Remove the include statement for drm_plane_helper.h from all the files
that don't need it. Althogh the header file is almost empty, many drivers
include it somewhere.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220720083058.15371-5-tzimmermann@suse.de

devm_pm_runtime_enable() simplifies the driver a bit since it will call
pm_runtime_disable() automatically through a device-managed action.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-70-maxime@cerno.tech

At bind time, vc4_v3d_bind() will read a register to retrieve the v3d
version and make sure it's a version we're compatible with.

However, the v3d has an optional clock that is enabled only after the
register read-out and a power domain that wasn't enabled at all in the bind
implementation. This was working fine at boot because both were enabled,
but resulted in the version check failing if we were unbinding and
rebinding the driver because the unbinding would have turned them off.

The fix isn't as easy as calling pm_runtime_resume_and_get() prior to the
register access to power up the power domain though.

Indeed, the runtime_resume implementation will enable the clock mentioned
above, call vc4_v3d_init_hw() and then vc4_irq_enable().

Prior to the previous patch, vc4_irq_enable() needed to occur after our
call to platform_get_irq() and vc4_irq_install(), since vc4_irq_enable()
used to call enable_irq() and vc4_irq_install() will call request_irq().

vc4_irq_install() will also do some register access, so needs the power
domain to be on. So we ended up in a situation where
vc4_v3d_runtime_resume() needed vc4_irq_install() to have been called
before, and vc4_irq_install() needed vc4_v3d_runtime_resume().

The previous patch removed the enable_irq() call in vc4_irq_enable() and
thus removed the dependency of vc4_v3d_runtime_resume() on
vc4_irq_install().

Thus, we can now rework our bind implementation to call
pm_runtime_resume_and_get() before our register access to make sure the
power domain is on. vc4_v3d_runtime_resume() also takes care of turning the
clock on and calling vc4_v3d_init_hw() so we can remove them from bind.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-69-maxime@cerno.tech

The vc4_irq_disable(), among other things, will call disable_irq() to
complete any in-flight interrupts.

This requires its counterpart, vc4_irq_enable(), to call enable_irq() which
causes issues addressed in a later patch.

However, vc4_irq_disable() is called by two callees: vc4_irq_uninstall()
and vc4_v3d_runtime_suspend().

vc4_irq_uninstall() also calls free_irq() which already disables the
interrupt line. We thus don't require an explicit disable_irq() for that
call site.

vc4_v3d_runtime_suspend() doesn't have any other code. However, the rest of
vc4_irq_disable() masks the interrupts coming from the v3d, so explictly
disabling the interrupt line is also redundant.

The only thing we really care about is thus to make sure we don't have any
handler in-flight, as suggested by the comment. We can thus replace
disable_irq() by synchronize_irq().
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-68-maxime@cerno.tech

vc4_perfmon_open_file() will instantiate a mutex for that file instance,
but we never call mutex_destroy () in vc4_perfmon_close_file().

Let's add that missing call.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-67-maxime@cerno.tech

mutex_init is supposed to be balanced by a call to mutex_destroy that we
were never doing in the vc4 driver.

Since a DRM-managed mutex_init variant has been introduced, let's just
switch to it.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-66-maxime@cerno.tech

The vc4 has a custom API to allow components to register a debugfs file
before the DRM driver has been registered and the debugfs_init hook has
been called.

However, the .late_register hook allows to have the debugfs file creation
deferred after that time already.

Let's remove our custom code to only register later our debugfs entries as
part of either debugfs_init or after it.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-65-maxime@cerno.tech

vc4_debugfs_add_file() can fail, so let's propagate its error code instead
of silencing it.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-64-maxime@cerno.tech

Our current code now mixes some resources whose lifetime are tied to the
device (clocks, IO mappings, etc.) and some that are tied to the DRM device
(encoder, bridge).

The device one will be freed at unbind time, but the DRM one will only be
freed when the last user of the DRM device closes its file handle.

So we end up with a time window during which we can call the encoder hooks,
but we don't have access to the underlying resources and device.

Let's protect all those sections with drm_dev_enter() and drm_dev_exit() so
that we bail out if we are during that window.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-63-maxime@cerno.tech

devm_pm_runtime_enable() simplifies the driver a bit since it will call
pm_runtime_disable() automatically through a device-managed action.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-62-maxime@cerno.tech

Whenever the device and driver are unbound, the main device and all the
subdevices will be removed by calling their unbind() method.

However, the DRM device itself will only be freed when the last user will
have closed it.

It means that there is a time window where the device and its resources
aren't there anymore, but the userspace can still call into our driver.

Fortunately, the DRM framework provides the drm_dev_enter() and
drm_dev_exit() functions to make sure our underlying device is still there
for the section protected by those calls. Let's add them to the VEC driver.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-61-maxime@cerno.tech

The current code will call drm_connector_unregister() and
drm_connector_cleanup() when the device is unbound. However, by then, there
might still be some references held to that connector, including by the
userspace that might still have the DRM device open.

Let's switch to a DRM-managed initialization to clean up after ourselves
only once the DRM device has been last closed.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-60-maxime@cerno.tech

The current code will call drm_encoder_cleanup() when the device is
unbound. However, by then, there might still be some references held to
that encoder, including by the userspace that might still have the DRM
device open.

Let's switch to a DRM-managed initialization to clean up after ourselves
only once the DRM device has been last closed.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-59-maxime@cerno.tech

drm_connector_unregister() is only to be used for connectors that have been
registered through drm_connector_register() after drm_dev_register() has
been called. This is our case here so let's remove the call.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-58-maxime@cerno.tech