112e505a76
Merge drm/drm-next into drm-misc-next
...
We need commit f8f6ae5d07tzimmermann@suse.de >
2020-11-10 17:11:37 +01:00
512bce50a4
Merge v5.10-rc3 into drm-next
...
We need commit f8f6ae5d07daniel.vetter@ffwll.ch >
2020-11-10 14:36:36 +01:00
49a3f51dfe
drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
...
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap()
et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of
implementing their own vmap callbacks.
v7:
* init QXL cursor to mapped BO buffer (kernel test robot)
v5:
* update vkms after switch to shmem
v4:
* use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian)
* fix a trailing { in drm_gem_vmap()
* remove several empty functions instead of converting them (Daniel)
* comment uses of raw pointers with a TODO (Daniel)
* TODO list: convert more helpers to use struct dma_buf_map
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de >
Acked-by: Christian König <christian.koenig@amd.com >
Tested-by: Sam Ravnborg <sam@ravnborg.org >
Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-7-tzimmermann@suse.de
2020-11-09 09:19:24 +01:00
f6ebe9f9c9
drm/atomic: Pass the full state to CRTC atomic begin and flush
...
The current atomic helpers have either their object state being passed as
an argument or the full atomic state.
The former is the pattern that was done at first, before switching to the
latter for new hooks or when it was needed.
Let's start convert all the remaining helpers to provide a consistent
interface, starting with the CRTC's atomic_begin and atomic_flush.
The conversion was done using the coccinelle script below, built tested on
all the drivers and actually tested on vc4.
virtual report
@@
struct drm_crtc_helper_funcs *FUNCS;
identifier old_crtc_state, old_state;
identifier crtc;
identifier f;
@@
f(struct drm_crtc_state *old_crtc_state)
{
...
struct drm_atomic_state *old_state = old_crtc_state->state;
<...
- FUNCS->atomic_begin(crtc, old_crtc_state);
+ FUNCS->atomic_begin(crtc, old_state);
...>
}
@@
struct drm_crtc_helper_funcs *FUNCS;
identifier old_crtc_state, old_state;
identifier crtc;
identifier f;
@@
f(struct drm_crtc_state *old_crtc_state)
{
...
struct drm_atomic_state *old_state = old_crtc_state->state;
<...
- FUNCS->atomic_flush(crtc, old_crtc_state);
+ FUNCS->atomic_flush(crtc, old_state);
...>
}
@@
struct drm_crtc_helper_funcs *FUNCS;
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
identifier dev, state;
identifier f;
@@
f(struct drm_device *dev, struct drm_atomic_state *state, ...)
{
<...
- FUNCS->atomic_begin(crtc, crtc_state);
+ FUNCS->atomic_begin(crtc, state);
...>
}
@@
struct drm_crtc_helper_funcs *FUNCS;
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
identifier dev, state;
identifier f;
@@
f(struct drm_device *dev, struct drm_atomic_state *state, ...)
{
<...
- FUNCS->atomic_flush(crtc, crtc_state);
+ FUNCS->atomic_flush(crtc, state);
...>
}
@@
identifier crtc, old_state;
@@
struct drm_crtc_helper_funcs {
...
- void (*atomic_begin)(struct drm_crtc *crtc, struct drm_crtc_state *old_state);
+ void (*atomic_begin)(struct drm_crtc *crtc, struct drm_atomic_state *state);
...
- void (*atomic_flush)(struct drm_crtc *crtc, struct drm_crtc_state *old_state);
+ void (*atomic_flush)(struct drm_crtc *crtc, struct drm_atomic_state *state);
...
}
@ crtc_atomic_func @
identifier helpers;
identifier func;
@@
(
static struct drm_crtc_helper_funcs helpers = {
...,
.atomic_begin = func,
...,
};
|
static struct drm_crtc_helper_funcs helpers = {
...,
.atomic_flush = func,
...,
};
)
@ ignores_old_state @
identifier crtc_atomic_func.func;
identifier crtc, old_state;
@@
void func(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
... when != old_state
}
@ adds_old_state depends on crtc_atomic_func && !ignores_old_state @
identifier crtc_atomic_func.func;
identifier crtc, old_state;
@@
void func(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
{
+ struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state, crtc);
...
}
@ depends on crtc_atomic_func @
identifier crtc_atomic_func.func;
expression E;
type T;
@@
void func(...)
{
...
- T state = E;
+ T crtc_state = E;
<+...
- state
+ crtc_state
...+>
}
@ depends on crtc_atomic_func @
identifier crtc_atomic_func.func;
type T;
@@
void func(...)
{
...
- T state;
+ T crtc_state;
<+...
- state
+ crtc_state
...+>
}
@@
identifier old_state;
identifier crtc;
@@
void vc4_hvs_atomic_flush(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state
+ struct drm_atomic_state *state
)
{
+ struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state, crtc);
...
}
@@
identifier old_state;
identifier crtc;
@@
void vc4_hvs_atomic_flush(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state
+ struct drm_atomic_state *state
);
@@
identifier old_state;
identifier crtc;
@@
void vmw_du_crtc_atomic_begin(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state
+ struct drm_atomic_state *state
)
{
...
}
@@
identifier old_state;
identifier crtc;
@@
void vmw_du_crtc_atomic_begin(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state
+ struct drm_atomic_state *state
);
@@
identifier old_state;
identifier crtc;
@@
void vmw_du_crtc_atomic_flush(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state
+ struct drm_atomic_state *state
)
{
...
}
@@
identifier old_state;
identifier crtc;
@@
void vmw_du_crtc_atomic_flush(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state
+ struct drm_atomic_state *state
);
@ depends on crtc_atomic_func @
identifier crtc_atomic_func.func;
identifier old_state;
identifier crtc;
@@
void func(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state
+ struct drm_atomic_state *state
)
{ ... }
@ include depends on adds_old_state @
@@
#include <drm/drm_atomic.h>
@ no_include depends on !include && adds_old_state @
@@
+ #include <drm/drm_atomic.h>
#include <drm/...>
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Acked-by: Thomas Zimmermann <tzimmermann@suse.de >
Link: https://patchwork.freedesktop.org/patch/msgid/20201028123222.1732139-2-maxime@cerno.tech
2020-11-02 12:37:49 +01:00
84d7d4720c
drm/vc4: Use devm_drm_dev_alloc
...
We can simplify a bit the bind code, its error path and unbind by using
the managed devm_drm_dev_alloc function.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Link: https://patchwork.freedesktop.org/patch/msgid/20201029190104.2181730-5-maxime@cerno.tech
2020-11-02 12:14:50 +01:00
171a072b46
drm/vc4: gem: Add a managed action to cleanup the job queue
...
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: d5b1a78a77daniel.vetter@ffwll.ch >
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Link: https://patchwork.freedesktop.org/patch/msgid/20201029190104.2181730-3-maxime@cerno.tech
2020-11-02 12:14:43 +01:00
1c80be48c7
drm/vc4: bo: Add a managed action to cleanup the cache
...
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: c826a6e106daniel.vetter@ffwll.ch >
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Link: https://patchwork.freedesktop.org/patch/msgid/20201029190104.2181730-1-maxime@cerno.tech
2020-11-02 12:11:24 +01:00
c489573b5b
Merge drm/drm-next into drm-misc-next
...
Daniel needs -rc2 in drm-misc-next to merge some patches
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
2020-11-02 11:17:54 +01:00
5066f42c7d
drm/vc4: Rework the structure conversion functions
...
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: Maxime Ripard <maxime@cerno.tech >
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20201028123752.1733242-1-maxime@cerno.tech
2020-10-29 10:26:04 +01:00
8ba0b6d196
drm/vc4: crtc: Keep the previously assigned HVS FIFO
...
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: 87ebcd42fbmaxime@cerno.tech >
Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com >
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200923084032.218619-2-maxime@cerno.tech
2020-09-25 16:56:21 +02:00
dd60202237
drm/vc4: Introduce GEM object functions
...
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vc4. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de >
Reviewed-by: Eric Anholt <eric@anholt.net >
Acked-by: Christian König <christian.koenig@amd.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-17-tzimmermann@suse.de
2020-09-25 09:21:27 +02:00
f437bc1ec7
drm/vc4: drv: Support BCM2711
...
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: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com >
Link: https://patchwork.freedesktop.org/patch/msgid/beac4f9ef0261bca731a0402c8354e9af740519c.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:14:55 +02:00
283d347d6e
drm/vc4: hdmi: Remove vc4_dev hdmi pointer
...
Now that we don't have any users anymore, we can kill that pointer.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/d7ebf50319bbd902e4b7b7c39ae1612c3b38e6b2.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:05:38 +02:00
875a4d5368
drm/vc4: drv: Disable the CRTC at boot time
...
In order to prevent issues during the firmware to KMS transition, we need
to make sure the pixelvalve are disabled at boot time so that the DRM state
matches the hardware state.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/ad57f1bdeae7a99631713b0fc193c86f223de042.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:04:36 +02:00
29bbb93080
drm/vc4: hvs: Introduce a function to get the assigned FIFO
...
At boot time, if we detect that a pixelvalve has been enabled, we need to
be able to retrieve the HVS channel it has been assigned to so that we can
disable that channel too. Let's create that function that returns the FIFO
or an error from a given output.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/178192d90874559b8386139f2226e773347729fc.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:04:26 +02:00
50e9d6cb5d
drm/vc4: hvs: Make the stop_channel function public
...
During the transition from the firmware to the KMS driver, we need to pay
particular attention to how we deal with the pixelvalves that have already
been enabled, otherwise either timeouts or stuck pixels can occur. We'll
thus need to call the function to stop an HVS channel at boot.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/a9d5f0891c3bc1deb6b16d56ca6994ed912ec7c7.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:04:22 +02:00
792c3132bc
drm/vc4: encoder: Add finer-grained encoder callbacks
...
In the BCM2711, the setup of the HVS, pixelvalve and HDMI controller
requires very precise ordering and timing that the regular atomic callbacks
don't provide. Let's add new callbacks on top of the regular ones to be
able to split the configuration as needed.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com >
Link: https://patchwork.freedesktop.org/patch/msgid/1dd78efe8f29add73c97d0148cfd4ec8e34aaf22.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:04:03 +02:00
d2f06525f6
drm/vc4: crtc: Move the HVS gamma LUT setup to our init function
...
Since most of the HVS channel is setup in the init function, let's move the
gamma setup there too. As this makes the HVS mode_set function empty, let's
remove it in the process.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com >
Link: https://patchwork.freedesktop.org/patch/msgid/d439da8f1592a450a6ad35ab1f9e77def17c7965.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:03:39 +02:00
aa2fd1ca7f
drm/vc4: crtc: Add HDMI1 encoder type
...
The BCM2711 sports a second HDMI controller, so let's add that second HDMI
encoder type.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/6ba56d2421a4ad59ce72178e8f37eacfbd72cb33.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:03:13 +02:00
ed024b229d
drm/vc4: crtc: Rename HDMI encoder type to HDMI0
...
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: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/84e11e4793aaa30d6e5c56e305d22404ac5a932d.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:03:07 +02:00
649abf2f5d
drm/vc4: crtc: Add FIFO depth to vc4_crtc_data
...
Not all pixelvalve FIFOs in vc5 have the same depth, so we need to add that
to our vc4_crtc_data structure to be able to compute the fill level
properly later on.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/7df3549c1bea9b0a27c784dc416bb9a831e4e18f.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:02:57 +02:00
87ebcd42fb
drm/vc4: crtc: Assign output to channel automatically
...
The HVS found in the BCM2711 has 6 outputs and 3 FIFOs, with each output
being connected to a pixelvalve, and some muxing between the FIFOs and
outputs.
Any output cannot feed from any FIFO though, and they all have a bunch of
constraints.
In order to support this, let's store the possible FIFOs each output can be
assigned to in the vc4_crtc_data, and use that information at atomic_check
time to iterate over all the CRTCs enabled and assign them FIFOs.
The channel assigned is then set in the vc4_crtc_state so that the rest of
the driver can use it.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com >
Link: https://patchwork.freedesktop.org/patch/msgid/f9aba3814ef37156ff36f310118cdd3954dd3dc5.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:02:51 +02:00
8ebb2cf0f6
drm/vc4: crtc: Rename HVS channel to output
...
In vc5, the HVS has 6 outputs and 3 FIFOs (or channels), with
pixelvalves each being assigned to a given output, but each output can
then be muxed to feed from multiple FIFOs.
Since vc4 had that entirely static, both were probably equivalent, but
since that changes, let's rename hvs_channel to hvs_output in the
vc4_crtc_data, since a pixelvalve is really connected to an output, and
not to a FIFO.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com >
Link: https://patchwork.freedesktop.org/patch/msgid/b7618bb17b1c435c5d6ce50bcde2fe9243281d02.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:02:29 +02:00
78cbcc38b9
drm/vc4: crtc: Move the cob allocation outside of bind
...
The COB allocation depends on the HVS channel used for a given
pixelvalve.
While the channel allocation was entirely static in vc4, vc5 changes
that and at bind time, a pixelvalve can be assigned to multiple
HVS channels.
Let's prepare that rework by allocating the COB when it's actually
needed.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/484cbd4b00cfeee425295df438222258cc39a3dd.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:02:24 +02:00
644df22fe3
drm/vc4: crtc: Deal with different number of pixel per clock
...
Some of the HDMI pixelvalves in vc5 output two pixels per clock cycle.
Let's put the number of pixel output per clock cycle in the CRTC data and
update the various calculations to reflect that.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/18a3bb079981ba820132b37e736a4bb371234d2e.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:02:14 +02:00
d7d96c00e5
drm/vc4: hvs: Boost the core clock during modeset
...
In order to prevent timeouts and stalls in the pipeline, the core clock
needs to be maxed at 500MHz during a modeset on the BCM2711.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/37ed9e0124c5cce005ddc8dafe821d8b0da036ff.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:01:52 +02:00
c54619b0bf
drm/vc4: Add support for the BCM2711 HVS5
...
The HVS found in the BCM2711 is slightly different from the previous
generations.
Most notably, the display list layout changes a bit, the LBM doesn't have
the same size and the formats ordering for some formats is swapped.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com >
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Tested-by: Chanwoo Choi <cw00.choi@samsung.com >
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com >
Tested-by: Stefan Wahren <stefan.wahren@i2se.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/1d02fab3b916d639c2dc05608c117bbd8230ebe8.1599120059.git-series.maxime@cerno.tech
2020-09-07 18:01:44 +02:00
e25a21abb9
drm/vc4: crtc: Move the txp_armed function to the TXP
...
The TXP driver is the only place where we need to set the txp_armed flag,
so let's move the function in the TXP driver.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/12b383e7b8462e281b00c0a21b2b50f13691bead.1591882579.git-series.maxime@cerno.tech
2020-07-07 10:51:21 +02:00
5fefc601a6
drm/vc4: crtc: Move the CRTC initialisation to a separate function
...
The upcoming patches to turn the TXP into a full-blown CRTC will have the
same CRTC initialisation code, so let's move it into a separate, public,
function so that we can reuse it later on.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/3a3026c0e7408895d154d8dea454cf6d1c459715.1591882579.git-series.maxime@cerno.tech
2020-07-07 10:51:21 +02:00
5a20ff8bf3
drm/vc4: crtc: Split CRTC data in two
...
The vc4_crtc_data structure is currently storing data related to both the
general CRTC information needed by the rest of the vc4 driver (like HVS
output and available FIFOs) and some related to the pixelvalve attached to
that CRTC. Let's split this into two structures so that we can reuse the
CRTC part into the TXP later on.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/8eb317c91ac208d7f926d76ad421002fa0364c47.1591882579.git-series.maxime@cerno.tech
2020-07-07 10:51:21 +02:00
bdd9647296
drm/vc4: crtc: Make state functions public
...
We'll need the CRTC state related functions to be exported so that we can
reuse them for the TXP.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/658f40aa01d7a45cbf6feebfc3dc6549f100d110.1591882579.git-series.maxime@cerno.tech
2020-07-07 10:51:20 +02:00
8175287bdd
drm/vc4: crtc: Move HVS setup code to the HVS driver
...
The CRTC in vc4 is backed by two devices, the HVS that does the composition
and the PixelValve that does the timing generation.
The writeback is kind of a special case since it doesn't have an associated
pixelvalve but goes straight from the HVS to the TXP. Therefore, it makes
sense to move out the HVS setup code into helpers so that we can also reuse
them from the TXP driver.
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/96443394e81429ee38f070cfe231701b07e56d69.1591882579.git-series.maxime@cerno.tech
2020-07-07 10:51:16 +02:00
ae44a52779
drm/vc4: crtc: Move crtc state to common header
...
We'll need to access the crtc_state from outside of vc4_crtc.c, so let's
move it to vc4_drv.h
Reviewed-by: Eric Anholt <eric@anholt.net >
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Link: https://patchwork.freedesktop.org/patch/msgid/1e6e563f9c75961e2885c9d648a3130d3b46b6d1.1590594512.git-series.maxime@cerno.tech
2020-06-10 11:09:38 +02:00
0c2a50f1a0
drm/vc4: plane: Move additional planes creation to driver
...
So far the plane creation was done when each CRTC was bound, and those
planes were only tied to the CRTC that was registering them.
This causes two main issues:
- The planes in the vc4 hardware are actually not tied to any CRTC, but
can be used with every combination
- More importantly, so far, we allocate 10 planes per CRTC, with 3 CRTCs.
However, the next generation of hardware will have 5 CRTCs, putting us
well above the maximum of 32 planes currently allowed by DRM.
This patch is the first one in a series of patches that will take down both
of these issues so that we can support the next generation of hardware
while keeping a good amount of planes.
We start by changing the way the planes are registered to first registering
the primary planes for each CRTC in the CRTC bind function as we used to,
but moving the overlay and cursor creation to the main driver bind
function, after all the CRTCs have been bound, and make the planes
associated to all CRTCs.
This will slightly change the ID order of the planes, since the primary
planes of all CRTCs will be first, and then a pattern of 8 overlays, 1
cursor plane for each CRTC.
This shouldn't cause any trouble since the ordering between the planes is
preserved though.
Reviewed-by: Eric Anholt <eric@anholt.net >
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Link: https://patchwork.freedesktop.org/patch/msgid/0b85a3fdb20bb4ff85fb62cabd082d5a65e2730b.1590594512.git-series.maxime@cerno.tech
2020-06-10 11:09:38 +02:00
e10cde4ad0
drm/vc4: plane: Move planes creation to its own function
...
The planes so far were created as part of the CRTC binding code with
each planes created associated only to one CRTC. However, the hardware
in the vc4 doesn't really have such constraint and can be used with any
CRTC.
In order to rework this, let's first move the overlay and cursor planes
creation to a function of its own.
Reviewed-by: Eric Anholt <eric@anholt.net >
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Link: https://patchwork.freedesktop.org/patch/msgid/a378ea56214179f1f25fcd36ecc69511edd1e790.1590594512.git-series.maxime@cerno.tech
2020-06-10 11:09:37 +02:00
6a88752c09
drm/vc4: drv: Add include guards
...
vc4_drv.h doesn't have any include guards which prevents it from being
included twice. Let's add them.
Reviewed-by: Eric Anholt <eric@anholt.net >
Signed-off-by: Maxime Ripard <maxime@cerno.tech >
Link: https://patchwork.freedesktop.org/patch/msgid/68e89e315c4c35b313efc277c9642eca684e0ade.1590594512.git-series.maxime@cerno.tech
2020-06-10 11:09:37 +02:00
7ce84471e3
drm: convert .debugfs_init() hook to return void.
...
As a result of commit 987d65d013https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com >
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Link: https://patchwork.freedesktop.org/patch/msgid/20200310133121.27913-18-wambui.karugax@gmail.com
2020-03-18 17:53:28 +01:00
5b2adbddf2
drm/vc4/vc4_drv.h: Replace zero-length array with flexible-array member
...
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293gustavo@embeddedor.com >
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Link: https://patchwork.freedesktop.org/patch/msgid/20200305105707.GA19261@embeddedor
2020-03-06 11:50:17 +01:00
7f2a09ecf2
drm/vc4: Replace wait_for macros to remove use of msleep
...
The wait_for macro's for Broadcom VC4 driver used msleep, which is
inappropriate due to its inaccuracy at low values (minimum wait time
is about 30ms on the Raspberry Pi). This sleep was triggering in
v3d_clean_caches(), causing us to only be able to dispatch ~33 compute
jobs per second.
This patch replaces the macro with the one from the Intel i915 version
which uses usleep_range to provide more accurate waits.
v2: Split from the v3d patch in case this tickles modesetting bugs (by
anholt)
Signed-off-by: James Hughes <james.hughes@raspberrypi.com >
Signed-off-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/20200217153145.13780-1-james.hughes@raspberrypi.com
2020-03-04 22:15:27 -08:00
3c8639ce14
drm/vc4: Convert to struct drm_crtc_helper_funcs.get_scanout_position()
...
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert vc4
over.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de >
Acked-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-18-tzimmermann@suse.de
2020-02-13 13:10:10 +01:00
03b0f2ce73
Merge v5.3-rc1 into drm-misc-next
...
Noralf needs some SPI patches in 5.3 to merge some work on tinydrm.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com >
2019-07-22 21:24:10 +02:00
fd6d6d80cb
drm/vc4: drop use of drmP.h
...
Drop use of the deprecated header drmP.h.
Fix so vc4_drv.h is now self-contained, and fixed fall-out in remaining
files.
Divided include files in blocks.
Sorted include files within their blocks.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org >
Acked-by: Emil Velikov <emil.velikov@collabora.com >
Reviewed-by: Alex Deucher <alexander.deucher@amd.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/20190716064220.18157-7-sam@ravnborg.org
2019-07-17 12:52:45 +02:00
be8454afc5
Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm
...
Pull drm updates from Dave Airlie:
"The biggest thing in this is the AMD Navi GPU support, this again
contains a bunch of header files that are large. These are the new AMD
RX5700 GPUs that just recently became available.
New drivers:
- ST-Ericsson MCDE driver
- Ingenic JZ47xx SoC
UAPI change:
- HDR source metadata property
Core:
- HDR inforframes and EDID parsing
- drm hdmi infoframe unpacking
- remove prime sg_table caching into dma-buf
- New gem vram helpers to reduce driver code
- Lots of drmP.h removal
- reservation fencing fix
- documentation updates
- drm_fb_helper_connector removed
- mode name command handler rewrite
fbcon:
- Remove the fbcon notifiers
ttm:
- forward progress fixes
dma-buf:
- make mmap call optional
- debugfs refcount fixes
- dma-fence free with pending signals fix
- each dma-buf gets an inode
Panels:
- Lots of additional panel bindings
amdgpu:
- initial navi10 support
- avoid hw reset
- HDR metadata support
- new thermal sensors for vega asics
- RAS fixes
- use HMM rather than MMU notifier
- xgmi topology via kfd
- SR-IOV fixes
- driver reload fixes
- DC use a core bpc attribute
- Aux fixes for DC
- Bandwidth calc updates for DC
- Clock handling refactor
- kfd VEGAM support
vmwgfx:
- Coherent memory support changes
i915:
- HDR Support
- HDMI i2c link
- Icelake multi-segmented gamma support
- GuC firmware update
- Mule Creek Canyon PCH support for EHL
- EHL platform updtes
- move i915.alpha_support to i915.force_probe
- runtime PM refactoring
- VBT parsing refactoring
- DSI fixes
- struct mutex dependency reduction
- GEM code reorg
mali-dp:
- Komeda driver features
msm:
- dsi vs EPROBE_DEFER fixes
- msm8998 snapdragon 835 support
- a540 gpu support
- mdp5 and dpu interconnect support
exynos:
- drmP.h removal
tegra:
- misc fixes
tda998x:
- audio support improvements
- pixel repeated mode support
- quantisation range handling corrections
- HDMI vendor info fix
armada:
- interlace support fix
- overlay/video plane register handling refactor
- add gamma support
rockchip:
- RX3328 support
panfrost:
- expose perf counters via hidden ioctls
vkms:
- enumerate CRC sources list
ast:
- rework BO handling
mgag200:
- rework BO handling
dw-hdmi:
- suspend/resume support
rcar-du:
- R8A774A1 Soc Support
- LVDS dual-link mode support
- Additional formats
- Misc fixes
omapdrm:
- DSI command mode display support
stm
- fb modifier support
- runtime PM support
sun4i:
- use vmap ops
vc4:
- binner bo binding rework
v3d:
- compute shader support
- resync/sync fixes
- job management refactoring
lima:
- NULL pointer in irq handler fix
- scheduler default timeout
virtio:
- fence seqno support
- trace events
bochs:
- misc fixes
tc458767:
- IRQ/HDP handling
sii902x:
- HDMI audio support
atmel-hlcdc:
- misc fixes
meson:
- zpos support"
* tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm: (1815 commits)
Revert "Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next"
Revert "mm: adjust apply_to_pfn_range interface for dropped token."
mm: adjust apply_to_pfn_range interface for dropped token.
drm/amdgpu/navi10: add uclk activity sensor
drm/amdgpu: properly guard the generic discovery code
drm/amdgpu: add missing documentation on new module parameters
drm/amdgpu: don't invalidate caches in RELEASE_MEM, only do the writeback
drm/amd/display: avoid 64-bit division
drm/amdgpu/psp11: simplify the ucode register logic
drm/amdgpu: properly guard DC support in navi code
drm/amd/powerplay: vega20: fix uninitialized variable use
drm/amd/display: dcn20: include linux/delay.h
amdgpu: make pmu support optional
drm/amd/powerplay: Zero initialize current_rpm in vega20_get_fan_speed_percent
drm/amd/powerplay: Zero initialize freq in smu_v11_0_get_current_clk_freq
drm/amd/powerplay: Use memset to initialize metrics structs
drm/amdgpu/mes10.1: Fix header guard
drm/amd/powerplay: add temperature sensor support for navi10
drm/amdgpu: fix scheduler timeout calc
drm/amdgpu: Prepare for hmm_range_register API change (v2)
...
2019-07-15 19:04:27 -07:00
e4fa8457b2
drm/prime: Align gem_prime_export with obj_funcs.export
...
The idea is that gem_prime_export is deprecated in favor of
obj_funcs.export. That's much easier to do if both have matching
function signatures.
Reviewed-by: Eric Anholt <eric@anholt.net >
Reviewed-by: Emil Velikov <emil.velikov@collabora.com >
Acked-by: Christian König <christian.koenig@amd.com >
Acked-by: Thierry Reding <treding@nvidia.com >
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com >
Cc: Russell King <linux@armlinux.org.uk >
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Maxime Ripard <maxime.ripard@bootlin.com >
Cc: Sean Paul <sean@poorly.run >
Cc: David Airlie <airlied@linux.ie >
Cc: Daniel Vetter <daniel@ffwll.ch >
Cc: Zhenyu Wang <zhenyuw@linux.intel.com >
Cc: Zhi Wang <zhi.a.wang@intel.com >
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com >
Cc: Alex Deucher <alexander.deucher@amd.com >
Cc: "Christian König" <christian.koenig@amd.com >
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com >
Cc: Thierry Reding <thierry.reding@gmail.com >
Cc: Jonathan Hunter <jonathanh@nvidia.com >
Cc: Dave Airlie <airlied@redhat.com >
Cc: Eric Anholt <eric@anholt.net >
Cc: "Michel Dänzer" <michel.daenzer@amd.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Huang Rui <ray.huang@amd.com >
Cc: Felix Kuehling <Felix.Kuehling@amd.com >
Cc: Hawking Zhang <Hawking.Zhang@amd.com >
Cc: Feifei Xu <Feifei.Xu@amd.com >
Cc: Jim Qu <Jim.Qu@amd.com >
Cc: Evan Quan <evan.quan@amd.com >
Cc: Matthew Auld <matthew.auld@intel.com >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Thomas Zimmermann <tdz@users.sourceforge.net >
Cc: Kate Stewart <kstewart@linuxfoundation.org >
Cc: Sumit Semwal <sumit.semwal@linaro.org >
Cc: Jilayne Lovejoy <opensource@jilayne.com >
Cc: Thomas Gleixner <tglx@linutronix.de >
Cc: Mikulas Patocka <mpatocka@redhat.com >
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
Cc: Junwei Zhang <Jerry.Zhang@amd.com >
Cc: intel-gvt-dev@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-tegra@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-10-daniel.vetter@ffwll.ch
2019-06-21 17:30:49 +02:00
d2912cb15b
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
...
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de >
Reviewed-by: Enrico Weigelt <info@metux.net >
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org >
Reviewed-by: Allison Randal <allison@lohutok.net >
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2019-06-19 17:09:55 +02:00
35c8b4b2c0
drm/vc4: Allocate binner bo when starting to use the V3D
...
The binner BO is not required until the V3D is in use, so avoid
allocating it at probe and do it on the first non-dumb BO allocation.
Keep track of which clients are using the V3D and liberate the buffer
when there is none left, using a kref. Protect the logic with a
mutex to avoid race conditions.
The binner BO is created at the time of the first render ioctl and is
destroyed when there is no client and no exec job using it left.
The Out-Of-Memory (OOM) interrupt also gets some tweaking, to avoid
enabling it before having allocated a binner bo.
We also want to keep the BO alive during runtime suspend/resume to avoid
failing to allocate it at resume. This happens when the CMA pool is
full at that point and results in a hard crash.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com >
Reviewed-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/20190516145544.29051-5-paul.kocialkowski@bootlin.com
2019-05-23 17:32:21 +02:00
ffc2674071
drm/vc4: Disable V3D interactions if the v3d component didn't probe.
...
One might want to use the VC4 display stack without using Mesa.
Similar to the debugfs fixes for not having all of the possible
display bits enabled, make sure you can't oops in vc4 if v3d isn't
enabled.
v2: Fix matching against other v3d variants (review by Paul), don't
forget to set irq_enabled so that the vblank uapi works
v3: Use -ENODEV instead of -EINVAL on Paul's suggestion.
Signed-off-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/20190401183559.3823-2-eric@anholt.net
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com >
2019-04-03 12:49:18 -07:00
c9be804c8c
drm/vc4: Use common helpers for debugfs setup by the driver components.
...
The global list of all debugfs entries for the driver was painful: the
list couldn't see into the components' structs, so each component had
its own debugs show function to find the component, then find the
regset and dump it. The components also had to be careful to check
that they were actually registered in vc4 before dereferencing
themselves, in case they weren't probed on a particular platform.
They routinely failed at that.
Instead, we can have the components add their debugfs callbacks to a
little list in vc4 to be registered at drm_dev_register() time, which
gets vc4_debugfs.c out of the business of knowing the whole list of
components.
Thanks to this change, dsi0 (if it existed) would register its node.
v2: Rebase on hvs_underrun addition.
v3: whitespace fixup
Signed-off-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/20190401183559.3823-1-eric@anholt.net
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com >
2019-04-03 12:49:13 -07:00
cb74f6ee8e
drm/vc4: Add helpers for pm get/put.
...
This makes sure the vc4_reset doesn't hit an obscure race with the
GET_PARAM ioctl, fixes a decrement outside of the lock, and prevents
future code from making mistakes with the weird return value of
pm_runtime_get_sync().
Signed-off-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/20190220210343.28157-6-eric@anholt.net
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com >
2019-04-01 10:44:34 -07:00
3051719af1
drm/vc4: Use drm_print_regset32() for our debug register dumping.
...
This removes a bunch of duplicated boilerplate for the debugfs vs
runtime printk debug dumping.
Signed-off-by: Eric Anholt <eric@anholt.net >
Link: https://patchwork.freedesktop.org/patch/msgid/20190220210343.28157-2-eric@anholt.net
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com >
2019-04-01 10:44:34 -07:00
