summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/vc4/vc4_drv.h
AgeCommit message (Collapse)Author
2020-11-10Merge drm/drm-next into drm-misc-nextThomas Zimmermann
We need commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set pgprot_decrypted()") to be able to merge Jason's cleanup patch. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2020-11-10Merge v5.10-rc3 into drm-nextDaniel Vetter
We need commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set pgprot_decrypted()") to be able to merge Jason's cleanup patch. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-11-09drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backendsThomas Zimmermann
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-02drm/atomic: Pass the full state to CRTC atomic begin and flushMaxime Ripard
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-02drm/vc4: Use devm_drm_dev_allocMaxime Ripard
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-02drm/vc4: gem: Add a managed action to cleanup the job queueMaxime Ripard
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: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.") 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-3-maxime@cerno.tech
2020-11-02drm/vc4: bo: Add a managed action to cleanup the cacheMaxime Ripard
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: c826a6e10644 ("drm/vc4: Add a BO cache.") 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-1-maxime@cerno.tech
2020-11-02Merge drm/drm-next into drm-misc-nextMaxime Ripard
Daniel needs -rc2 in drm-misc-next to merge some patches Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2020-10-29drm/vc4: Rework the structure conversion functionsMaxime Ripard
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-09-25drm/vc4: crtc: Keep the previously assigned HVS FIFOMaxime Ripard
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: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by: Maxime Ripard <maxime@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-25drm/vc4: Introduce GEM object functionsThomas Zimmermann
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-07drm/vc4: drv: Support BCM2711Maxime Ripard
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-07drm/vc4: hdmi: Remove vc4_dev hdmi pointerMaxime Ripard
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-07drm/vc4: drv: Disable the CRTC at boot timeMaxime Ripard
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-07drm/vc4: hvs: Introduce a function to get the assigned FIFOMaxime Ripard
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-07drm/vc4: hvs: Make the stop_channel function publicMaxime Ripard
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-07drm/vc4: encoder: Add finer-grained encoder callbacksMaxime Ripard
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-07drm/vc4: crtc: Move the HVS gamma LUT setup to our init functionMaxime Ripard
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-07drm/vc4: crtc: Add HDMI1 encoder typeMaxime Ripard
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-07drm/vc4: crtc: Rename HDMI encoder type to HDMI0Maxime Ripard
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-07drm/vc4: crtc: Add FIFO depth to vc4_crtc_dataMaxime Ripard
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-07drm/vc4: crtc: Assign output to channel automaticallyMaxime Ripard
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-07drm/vc4: crtc: Rename HVS channel to outputMaxime Ripard
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-07drm/vc4: crtc: Move the cob allocation outside of bindMaxime Ripard
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-07drm/vc4: crtc: Deal with different number of pixel per clockMaxime Ripard
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-07drm/vc4: hvs: Boost the core clock during modesetMaxime Ripard
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-07drm/vc4: Add support for the BCM2711 HVS5Dave Stevenson
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-07-07drm/vc4: crtc: Move the txp_armed function to the TXPMaxime Ripard
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-07drm/vc4: crtc: Move the CRTC initialisation to a separate functionMaxime Ripard
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-07drm/vc4: crtc: Split CRTC data in twoMaxime Ripard
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-07drm/vc4: crtc: Make state functions publicMaxime Ripard
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-07drm/vc4: crtc: Move HVS setup code to the HVS driverMaxime Ripard
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-06-10drm/vc4: crtc: Move crtc state to common headerMaxime Ripard
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-10drm/vc4: plane: Move additional planes creation to driverMaxime Ripard
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-10drm/vc4: plane: Move planes creation to its own functionMaxime Ripard
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-10drm/vc4: drv: Add include guardsMaxime Ripard
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-03-18drm: convert .debugfs_init() hook to return void.Wambui Karuga
As a result of commit 987d65d01356 (drm: debugfs: make drm_debugfs_create_files() never fail) and changes to various debugfs functions in drm/core and across various drivers, there is no need for the drm_driver.debugfs_init() hook to have a return value. Therefore, declare it as void. This also includes refactoring all users of the .debugfs_init() hook to return void across the subsystem. v2: include changes to the hook and drivers that use it in one patch to prevent driver breakage and enable individual successful compilation of this change. References: https://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-06drm/vc4/vc4_drv.h: Replace zero-length array with flexible-array memberGustavo A. R. Silva
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 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200305105707.GA19261@embeddedor
2020-03-04drm/vc4: Replace wait_for macros to remove use of msleepJames Hughes
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-02-13drm/vc4: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann
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
2019-07-22Merge v5.3-rc1 into drm-misc-nextMaxime Ripard
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-17drm/vc4: drop use of drmP.hSam Ravnborg
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-15Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
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-06-21drm/prime: Align gem_prime_export with obj_funcs.exportDaniel Vetter
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-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner
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-05-23drm/vc4: Allocate binner bo when starting to use the V3DPaul Kocialkowski
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-04-03drm/vc4: Disable V3D interactions if the v3d component didn't probe.Eric Anholt
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-03drm/vc4: Use common helpers for debugfs setup by the driver components.Eric Anholt
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-01drm/vc4: Add helpers for pm get/put.Eric Anholt
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-01drm/vc4: Use drm_print_regset32() for our debug register dumping.Eric Anholt
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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 13:24:27 +0000