aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/vc4
AgeCommit message (Collapse)AuthorFilesLines
2020-11-30drm/cma-helper: Remove prime infix from GEM object functionsThomas Zimmermann1-2/+2
These functions are not directly related to PRIME interfaces any longer, but are now GEM object functions. Rename them accordingly and fix the docs. Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-23drm/vc4: kms: Don't disable the muxing of an active CRTCMaxime Ripard2-36/+48
The current HVS muxing code will consider the CRTCs in a given state to setup their muxing in the HVS, and disable the other CRTCs muxes. However, it's valid to only update a single CRTC with a state, and in this situation we would mux out a CRTC that was enabled but left untouched by the new state. Fix this by setting a flag on the CRTC state when the muxing has been changed, and only change the muxing configuration when that flag is there. Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Reviewed-by: Hoegeun Kwon <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-23drm/vc4: kms: Store the unassigned channel list in the stateMaxime Ripard2-25/+102
If a CRTC is enabled but not active, and that we're then doing a page flip on another CRTC, drm_atomic_get_crtc_state will bring the first CRTC state into the global state, and will make us wait for its vblank as well, even though that might never occur. Instead of creating the list of the free channels each time atomic_check is called, and calling drm_atomic_get_crtc_state to retrieve the allocated channels, let's create a private state object in the main atomic state, and use it to store the available channels. Since vc4 has a semaphore (with a value of 1, so a lock) in its commit implementation to serialize all the commits, even the nonblocking ones, we are free from the use-after-free race if two subsequent commits are not ran in their submission order. Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Reviewed-by: Hoegeun Kwon <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-20drm: Pass the full state to connectors atomic functionsMaxime Ripard1-1/+3
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. Now that the CRTCs have been converted, let's move forward with the connectors to provide a consistent interface. The conversion was done using the coccinelle script below, and built tested on all the drivers. @@ identifier connector, connector_state; @@ struct drm_connector_helper_funcs { ... struct drm_encoder* (*atomic_best_encoder)(struct drm_connector *connector, - struct drm_connector_state *connector_state); + struct drm_atomic_state *state); ... } @@ identifier connector, connector_state; @@ struct drm_connector_helper_funcs { ... void (*atomic_commit)(struct drm_connector *connector, - struct drm_connector_state *connector_state); + struct drm_atomic_state *state); ... } @@ struct drm_connector_helper_funcs *FUNCS; identifier state; identifier connector, connector_state; identifier f; @@ f(..., struct drm_atomic_state *state, ...) { <+... - FUNCS->atomic_commit(connector, connector_state); + FUNCS->atomic_commit(connector, state); ...+> } @@ struct drm_connector_helper_funcs *FUNCS; identifier state; identifier connector, connector_state; identifier var, f; @@ f(struct drm_atomic_state *state, ...) { <+... - var = FUNCS->atomic_best_encoder(connector, connector_state); + var = FUNCS->atomic_best_encoder(connector, state); ...+> } @ connector_atomic_func @ identifier helpers; identifier func; @@ ( static struct drm_connector_helper_funcs helpers = { ..., .atomic_best_encoder = func, ..., }; | static struct drm_connector_helper_funcs helpers = { ..., .atomic_commit = func, ..., }; ) @@ identifier connector_atomic_func.func; identifier connector; symbol state; @@ func(struct drm_connector *connector, - struct drm_connector_state *state + struct drm_connector_state *connector_state ) { ... - state + connector_state ... } @ ignores_state @ identifier connector_atomic_func.func; identifier connector, connector_state; @@ func(struct drm_connector *connector, struct drm_connector_state *connector_state) { ... when != connector_state } @ adds_state depends on connector_atomic_func && !ignores_state @ identifier connector_atomic_func.func; identifier connector, connector_state; @@ func(struct drm_connector *connector, struct drm_connector_state *connector_state) { + struct drm_connector_state *connector_state = drm_atomic_get_new_connector_state(state, connector); ... } @ depends on connector_atomic_func @ identifier connector_atomic_func.func; identifier connector_state; identifier connector; @@ func(struct drm_connector *connector, - struct drm_connector_state *connector_state + struct drm_atomic_state *state ) { ... } @ include depends on adds_state @ @@ #include <drm/drm_atomic.h> @ no_include depends on !include && adds_state @ @@ + #include <drm/drm_atomic.h> #include <drm/...> Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Acked-by: Harry Wentland <[email protected]> Cc: Leo Li <[email protected]> Cc: Alex Deucher <[email protected]> Cc: "Christian König" <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: Rodrigo Siqueira <[email protected]> Cc: Melissa Wen <[email protected]> Cc: Haneen Mohammed <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-19drm/vc4: hdmi: Disable Wifi FrequenciesMaxime Ripard2-0/+29
There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi chip and some resolutions, most notably 1440p at 60Hz. In such a case, we can either reject entirely the mode, or lower slightly the pixel frequency to remove the overlap. Let's go for the latter. Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-19drm/vc4: kms: Document the muxing corner casesMaxime Ripard1-0/+22
We've had a number of muxing corner-cases with specific ways to reproduce them, so let's document them to make sure they aren't lost and introduce regressions later on. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Reviewed-by: Hoegeun Kwon <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-19drm/vc4: kms: Split the HVS muxing check in a separate functionMaxime Ripard1-3/+15
The code that assigns HVS channels during atomic_check is starting to grow a bit big, let's move it into a separate function. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Reviewed-by: Hoegeun Kwon <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-19drm/vc4: kms: Rename NUM_CHANNELSMaxime Ripard1-3/+3
The NUM_CHANNELS define has a pretty generic name and was right before the function using it. Let's move to something that makes the hardware-specific nature more obvious, and to a more appropriate place. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Reviewed-by: Hoegeun Kwon <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-19drm/vc4: kms: Remove useless defineMaxime Ripard1-1/+0
NUM_OUTPUTS isn't used anymore, let's remove it. Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Reviewed-by: Hoegeun Kwon <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-19drm/vc4: kms: Switch to drmm_add_action_or_resetMaxime Ripard1-2/+2
Even though it was pointed in the review by Daniel, and I thought to have fixed it while applying the patches, but it turns out I forgot to commit the fixes in the process. Properly fix it this time. Fixes: dcda7c28bff2 ("drm/vc4: kms: Add functions to create the state objects") Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-19drm/vc4: hdmi: Block odd horizontal timingsMaxime Ripard2-0/+15
The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels per clock cycle, and cannot deal with odd timings. Let's reject any mode with such timings. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-19drm/vc4: hdmi: Make sure our clock rate is within limitsMaxime Ripard1-0/+15
The HDMI controller cannot go above a certain pixel rate limit depending on the generations, but that limit is only enforced in mode_valid at the moment, which means that we won't advertise modes that exceed that limit, but the userspace is still free to try to setup a mode that would. Implement atomic_check to make sure we check it in that scenario too. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-18drm/vc4/vc4_debugfs: Demote non-conformant kernel-doc headersLee Jones1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vc4/vc4_debugfs.c:25: warning: Function parameter or member 'minor' not described in 'vc4_debugfs_init' drivers/gpu/drm/vc4/vc4_debugfs.c:62: warning: Function parameter or member 'dev' not described in 'vc4_debugfs_add_file' drivers/gpu/drm/vc4/vc4_debugfs.c:62: warning: Function parameter or member 'name' not described in 'vc4_debugfs_add_file' drivers/gpu/drm/vc4/vc4_debugfs.c:62: warning: Function parameter or member 'show' not described in 'vc4_debugfs_add_file' drivers/gpu/drm/vc4/vc4_debugfs.c:62: warning: Function parameter or member 'data' not described in 'vc4_debugfs_add_file' Cc: Eric Anholt <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-18drm/vc4/vc4_v3d: Demote non-conformant kernel-doc headersLee Jones1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vc4/vc4_v3d.c:131: warning: Function parameter or member 'vc4' not described in 'vc4_v3d_pm_get' drivers/gpu/drm/vc4/vc4_v3d.c:231: warning: Function parameter or member 'vc4' not described in 'bin_bo_alloc' Cc: Eric Anholt <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Rob Clark <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-18drm/vc4/vc4_hdmi: Remove set but unused variable 'ret'Lee Jones1-2/+1
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vc4/vc4_hdmi.c: In function ‘vc4_hdmi_set_audio_infoframe’: drivers/gpu/drm/vc4/vc4_hdmi.c:334:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Cc: Eric Anholt <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: Rob Clark <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-18drm/vc4/vc4_hdmi_regs: Mark some data sets as __maybe_unusedLee Jones1-3/+3
The alternative is to move them into the source file that uses then, but they are large and intrusive, so that strategy is being avoided. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vc4/vc4_hdmi_regs.h:282:39: warning: ‘vc5_hdmi_hdmi1_fields’ defined but not used [-Wunused-const-variable=] drivers/gpu/drm/vc4/vc4_hdmi_regs.h:206:39: warning: ‘vc5_hdmi_hdmi0_fields’ defined but not used [-Wunused-const-variable=] drivers/gpu/drm/vc4/vc4_hdmi_regs.h:145:39: warning: ‘vc4_hdmi_fields’ defined but not used [-Wunused-const-variable=] Cc: Eric Anholt <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-16drm: fix some kernel-doc markupsMauro Carvalho Chehab1-1/+1
Some identifiers have different names between their prototypes and the kernel-doc markup. Others need to be fixed, as kernel-doc markups should use this format: identifier - description Signed-off-by: Mauro Carvalho Chehab <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/12d4ca26f6843618200529ce5445063734d38c04.1605521731.git.mchehab+huawei@kernel.org
2020-11-10Merge drm/drm-next into drm-misc-nextThomas Zimmermann7-75/+99
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 <[email protected]>
2020-11-10Merge v5.10-rc3 into drm-nextDaniel Vetter7-75/+99
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 <[email protected]>
2020-11-09drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backendsThomas Zimmermann2-4/+4
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 <[email protected]> Acked-by: Christian König <[email protected]> Tested-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-09drm/cma-helper: Remove empty drm_gem_cma_prime_vunmap()Thomas Zimmermann1-1/+0
The function drm_gem_cma_prime_vunmap() is empty. Remove it before changing the interface to use struct drm_buf_map. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Christian König <[email protected]> Tested-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-06drm/vc4: replace idr_init() by idr_init_base()Deepak R Varma1-1/+1
idr_init() uses base 0 which is an invalid identifier for this driver. The idr_alloc for this driver uses VC4_PERFMONID_MIN as start value for ID range and it is #defined to 1. The new function idr_init_base allows IDR to set the ID lookup from base 1. This avoids all lookups that otherwise starts from 0 since 0 is always unused / available. References: commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient") Signed-off-by: Deepak R Varma <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20201105202135.GA145111@localhost
2020-11-03drm: Use the state pointer directly in atomic_checkMaxime Ripard1-1/+1
Now that atomic_check takes the global atomic state as a parameter, we don't need to go through the pointer in the CRTC state. This was done using the following coccinelle script: @ crtc_atomic_func @ identifier helpers; identifier func; @@ static struct drm_crtc_helper_funcs helpers = { ..., .atomic_check = func, ..., }; @@ identifier crtc_atomic_func.func; identifier crtc, state; @@ func(struct drm_crtc *crtc, struct drm_atomic_state *state) { ... - struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state, crtc); ... when != crtc_state - crtc_state->state + state ... } @@ struct drm_crtc_state *crtc_state; identifier crtc_atomic_func.func; identifier crtc, state; @@ func(struct drm_crtc *crtc, struct drm_atomic_state *state) { ... - crtc_state->state + state ... } Suggested-by: Ville Syrjälä <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-03drm/vc4: drv: Remove unused variableMaxime Ripard1-1/+0
The commit dcda7c28bff2 ("drm/vc4: kms: Add functions to create the state objects") removed the last users of the vc4 variable, but didn't remove that variable resulting in a warning. Fixes: dcda7c28bff2 ("drm/vc4: kms: Add functions to create the state objects") Reported-by: Daniel Vetter <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-02drm/atomic: Pass the full state to CRTC atomic begin and flushMaxime Ripard2-2/+5
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 <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Daniel Vetter <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-02drm/atomic: Pass the full state to CRTC atomic_checkMaxime Ripard2-8/+13
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_check. 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; struct drm_crtc *crtc; struct drm_crtc_state *crtc_state; identifier dev, state; identifier ret, f; @@ f(struct drm_device *dev, struct drm_atomic_state *state) { <... - ret = FUNCS->atomic_check(crtc, crtc_state); + ret = FUNCS->atomic_check(crtc, state); ...> } @@ identifier crtc, new_state; @@ struct drm_crtc_helper_funcs { ... - int (*atomic_check)(struct drm_crtc *crtc, struct drm_crtc_state *new_state); + int (*atomic_check)(struct drm_crtc *crtc, struct drm_atomic_state *state); ... } @ crtc_atomic_func @ identifier helpers; identifier func; @@ static struct drm_crtc_helper_funcs helpers = { ..., .atomic_check = func, ..., }; @ ignores_new_state @ identifier crtc_atomic_func.func; identifier crtc, new_state; @@ int func(struct drm_crtc *crtc, struct drm_crtc_state *new_state) { ... when != new_state } @ adds_new_state depends on crtc_atomic_func && !ignores_new_state @ identifier crtc_atomic_func.func; identifier crtc, new_state; @@ int func(struct drm_crtc *crtc, struct drm_crtc_state *new_state) { + struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state, crtc); ... } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; expression E; type T; @@ int func(...) { ... - T state = E; + T crtc_state = E; <+... - state + crtc_state ...+> } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; type T; @@ int func(...) { ... - T state; + T crtc_state; <+... - state + crtc_state ...+> } @ depends on crtc_atomic_func @ identifier crtc_atomic_func.func; identifier new_state; identifier crtc; @@ int func(struct drm_crtc *crtc, - struct drm_crtc_state *new_state + struct drm_atomic_state *state ) { ... } @@ identifier new_state; identifier crtc; @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc, - struct drm_crtc_state *new_state + struct drm_atomic_state *state ) { + struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state, crtc); ... } @@ identifier new_state; identifier crtc; @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc, - struct drm_crtc_state *new_state + struct drm_atomic_state *state ); @ include depends on adds_new_state @ @@ #include <drm/drm_atomic.h> @ no_include depends on !include && adds_new_state @ @@ + #include <drm/drm_atomic.h> #include <drm/...> Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-02drm/vc4: kms: Add functions to create the state objectsMaxime Ripard2-24/+57
In order to make the vc4_kms_load code and error path a bit easier to read and extend, add functions to create state objects, and use managed actions to cleanup if needed. Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-02drm/vc4: Use devm_drm_dev_allocMaxime Ripard5-32/+25
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-02drm/vc4: Use the helper to retrieve vc4_dev when neededMaxime Ripard2-3/+3
We have a helper to retrieve the vc4_dev structure from the drm_device one when needed, so let's use it consistently. Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-02drm/vc4: gem: Add a managed action to cleanup the job queueMaxime Ripard3-10/+10
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-02drm/vc4: drv: Use managed drm_mode_config_initMaxime Ripard1-4/+3
Using drmm_mode_config_init instead of drm_mode_config_init allows us to cleanup a bit the error path. Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-02drm/vc4: bo: Add a managed action to cleanup the cacheMaxime Ripard3-4/+4
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-02Merge drm/drm-next into drm-misc-nextMaxime Ripard5-17/+41
Daniel needs -rc2 in drm-misc-next to merge some patches Signed-off-by: Maxime Ripard <[email protected]>
2020-10-29drm/vc4: Rework the structure conversion functionsMaxime Ripard1-6/+6
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 <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-29drm/vc4: hdmi: Add a name to the codec DAI componentMaxime Ripard1-0/+1
Since the components for a given device in ASoC are identified by their name, it makes sense to add one even though it's not strictly necessary. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-27drm/vc4: hdmi: Avoid sleeping in atomic contextMaxime Ripard1-2/+3
When running the trigger hook, ALSA by default will take a spinlock, and thus will run the trigger hook in atomic context. However, our HDMI driver will send the infoframes as part of the trigger hook, and part of that process is to wait for a bit to be cleared for up to 100ms. To be nicer to the system, that wait has some usleep_range that interact poorly with the atomic context. There's several ways we can fix this, but the more obvious one is to make ALSA take a mutex instead by setting the nonatomic flag on the DAI link. That doesn't work though, since now the cyclic callback installed by the dmaengine helpers in ALSA will take a mutex, while that callback is run by dmaengine's virt-chan code in a tasklet where sleeping is not allowed either. Given the delay we need to poll the bit for, changing the usleep_range for a udelay and keep running it from a context where interrupts are disabled is not really a good option either. However, we can move the infoframe setup code in the hw_params hook, like is usually done in other HDMI controllers, that isn't protected by a spinlock and thus where we can sleep. Infoframes will be sent on a regular basis anyway, and since hw_params is where the audio parameters that end up in the infoframes are setup, this also makes a bit more sense. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Suggested-by: Mark Brown <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Mark Brown <[email protected]> Reviewed-by: Takashi Iwai <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-27drm/vc4: drv: Add error handding for bindHoegeun Kwon1-0/+1
There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-22drm/vc4: dsi: Only register our component once a DSI device is attachedMaxime Ripard1-17/+8
If the DSI driver is the last to probe, component_add will try to run all the bind callbacks straight away and return the error code. However, since we depend on a power domain, we're pretty much guaranteed to be in that case on the BCM2711, and are just lucky on the previous SoCs since the v3d also depends on that power domain and is further in the probe order. In that case, the DSI host will not stick around in the system: the DSI bind callback will be executed, will not find any DSI device attached and will return EPROBE_DEFER, and we will then remove the DSI host and ask to be probed later on. But since that host doesn't stick around, DSI devices like the RaspberryPi touchscreen whose probe is not linked to the DSI host (unlike the usual DSI devices that will be probed through the call to mipi_dsi_host_register) cannot attach to the DSI host, and we thus end up in a situation where the DSI host cannot probe because the panel hasn't probed yet, and the panel cannot probe because the DSI host hasn't yet. In order to break this cycle, let's wait until there's a DSI device that attaches to the DSI host to register the component and allow to progress further. Acked-by: Eric Anholt <[email protected]> Suggested-by: Andrzej Hajda <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-15Merge tag 'drm-next-2020-10-15' of git://anongit.freedesktop.org/drm/drmLinus Torvalds13-1006/+3140
Pull drm updates from Dave Airlie: "Not a major amount of change, the i915 trees got split into display and gt trees to better facilitate higher level review, and there's a major refactoring of i915 GEM locking to use more core kernel concepts (like ww-mutexes). msm gets per-process pagetables, older AMD SI cards get DC support, nouveau got a bump in displayport support with common code extraction from i915. Outside of drm this contains a couple of patches for hexint moduleparams which you've acked, and a virtio common code tree that you should also get via it's regular path. New driver: - Cadence MHDP8546 DisplayPort bridge driver core: - cross-driver scatterlist cleanups - devm_drm conversions - remove drm_dev_init - devm_drm_dev_alloc conversion ttm: - lots of refactoring and cleanups bridges: - chained bridge support in more drivers panel: - misc new panels scheduler: - cleanup priority levels displayport: - refactor i915 code into helpers for nouveau i915: - split into display and GT trees - WW locking refactoring in GEM - execbuf2 extension mechanism - syncobj timeline support - GEN 12 HOBL display powersaving - Rocket Lake display additions - Disable FBC on Tigerlake - Tigerlake Type-C + DP improvements - Hotplug interrupt refactoring amdgpu: - Sienna Cichlid updates - Navy Flounder updates - DCE6 (SI) support for DC - Plane rotation enabled - TMZ state info ioctl - PCIe DPC recovery support - DC interrupt handling refactor - OLED panel fixes amdkfd: - add SMI events for thermal throttling - SMI interface events ioctl update - process eviction counters radeon: - move to dma_ for allocations - expose sclk via sysfs msm: - DSI support for sm8150/sm8250 - per-process GPU pagetable support - Displayport support mediatek: - move HDMI phy driver to PHY - convert mtk-dpi to bridge API - disable mt2701 tmds tegra: - bridge support exynos: - misc cleanups vc4: - dual display cleanups ast: - cleanups gma500: - conversion to GPIOd API hisilicon: - misc reworks ingenic: - clock handling and format improvements mcde: - DSI support mgag200: - desktop g200 support mxsfb: - i.MX7 + i.MX8M - alpha plane support panfrost: - devfreq support - amlogic SoC support ps8640: - EDID from eDP retrieval tidss: - AM65xx YUV workaround virtio: - virtio-gpu exported resources rcar-du: - R8A7742, R8A774E1 and R8A77961 support - YUV planar format fixes - non-visible plane handling - VSP device reference count fix - Kconfig fix to avoid displaying disabled options in .config" * tag 'drm-next-2020-10-15' of git://anongit.freedesktop.org/drm/drm: (1494 commits) drm/ingenic: Fix bad revert drm/amdgpu: Fix invalid number of character '{' in amdgpu_acpi_init drm/amdgpu: Remove warning for virtual_display drm/amdgpu: kfd_initialized can be static drm/amd/pm: setup APU dpm clock table in SMU HW initialization drm/amdgpu: prevent spurious warning drm/amdgpu/swsmu: fix ARC build errors drm/amd/display: Fix OPTC_DATA_FORMAT programming drm/amd/display: Don't allow pstate if no support in blank drm/panfrost: increase readl_relaxed_poll_timeout values MAINTAINERS: Update entry for st7703 driver after the rename Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached" drm/amd/display: HDMI remote sink need mode validation for Linux drm/amd/display: Change to correct unit on audio rate drm/amd/display: Avoid set zero in the requested clk drm/amdgpu: align frag_end to covered address space drm/amdgpu: fix NULL pointer dereference for Renoir drm/vmwgfx: fix regression in thp code due to ttm init refactor. drm/amdgpu/swsmu: add interrupt work handler for smu11 parts drm/amdgpu/swsmu: add interrupt work function ...
2020-10-09drm/atomic: Pass the full state to CRTC atomic enable/disableMaxime Ripard2-4/+13
If the CRTC driver ever needs to access the full DRM state, it can't do so at atomic_enable / atomic_disable time since drm_atomic_helper_swap_state will have cleared the pointer from the struct drm_crtc_state to the struct drm_atomic_state before calling those hooks. In order to allow that, let's pass the full DRM state to atomic_enable and atomic_disable. 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 dev, state; identifier crtc, crtc_state; @@ disable_outputs(struct drm_device *dev, struct drm_atomic_state *state) { <... - FUNCS->atomic_disable(crtc, crtc_state); + FUNCS->atomic_disable(crtc, state); ...> } @@ struct drm_crtc_helper_funcs *FUNCS; identifier dev, state; identifier crtc, crtc_state; @@ drm_atomic_helper_commit_modeset_enables(struct drm_device *dev, struct drm_atomic_state *state) { <... - FUNCS->atomic_enable(crtc, crtc_state); + FUNCS->atomic_enable(crtc, state); ...> } @@ identifier crtc, old_state; @@ struct drm_crtc_helper_funcs { ... - void (*atomic_enable)(struct drm_crtc *crtc, struct drm_crtc_state *old_state); + void (*atomic_enable)(struct drm_crtc *crtc, struct drm_atomic_state *state); ... - void (*atomic_disable)(struct drm_crtc *crtc, struct drm_crtc_state *old_state); + void (*atomic_disable)(struct drm_crtc *crtc, struct drm_atomic_state *state); ... } @ crtc_atomic_func @ identifier helpers; identifier func; @@ ( static struct drm_crtc_helper_funcs helpers = { ..., .atomic_enable = func, ..., }; | static struct drm_crtc_helper_funcs helpers = { ..., .atomic_disable = 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 ...+> } @ 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 <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/845aa10ef171fc0ea060495efef142a0c13f7870.1602161031.git-series.maxime@cerno.tech
2020-09-25drm/vc4: crtc: Keep the previously assigned HVS FIFOMaxime Ripard3-6/+19
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 <[email protected]> Tested-by: Dave Stevenson <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-25drm/vc4: crtc: Rework a bit the CRTC state codeMaxime Ripard1-3/+10
The current CRTC state reset hook in vc4 allocates a vc4_crtc_state structure as a drm_crtc_state, and relies on the fact that vc4_crtc_state embeds drm_crtc_state as its first member, and therefore can be safely cast. However, this is pretty fragile especially since there's no check for this in place, and we're going to need to access vc4_crtc_state member at reset so this looks like a good occasion to make it more robust. Fixes: 6d6e50039187 ("drm/vc4: Allocate the right amount of space for boot-time CRTC state.") Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Dave Stevenson <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-25drm/vc4: Introduce GEM object functionsThomas Zimmermann3-14/+20
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 <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Acked-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-23drm/vc4: kms: Assign a FIFO to enabled CRTCs instead of activeMaxime Ripard1-1/+1
The HVS has three FIFOs that can be assigned to a number of PixelValves through a mux. However, changing that FIFO requires that we disable and then enable the pixelvalve, so we want to assign FIFOs to all the enabled CRTCs, and not just the active ones. Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Dave Stevenson <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-21drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxingMaxime Ripard1-0/+17
The vc4 display engine has a first controller called the HVS that will perform the composition of the planes. That HVS has 3 FIFOs and can therefore compose planes for up to three outputs. The timings part is generated through a component called the Pixel Valve, and the BCM2711 has 6 of them. Thus, the HVS has some bits to control which FIFO gets output to which Pixel Valve. The current code supports that muxing by looking at all the CRTCs in a new DRM atomic state in atomic_check, and given the set of constraints that we have, assigns FIFOs to CRTCs or reject the mode entirely. The actual muxing will occur during atomic_commit. However, that doesn't work if only a fraction of the CRTCs' state is updated in that state, since it will ignore the CRTCs that are kept running unmodified, and will thus unassign its associated FIFO, and later disable it. In order to make the code work as expected, let's pull the CRTC state of all the enabled CRTC in our atomic_check so that we can operate on all the running CRTCs, no matter whether they are affected by the new state or not. Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Hoegeun Kwon <[email protected]> Tested-by: Dave Stevenson <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Reviewed-by: Hoegeun Kwon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-16drm/vc4: Handing the return value of drm_universal_plane_initTian Tao1-0/+2
Handing the return value of drm_universal_plane_init to fix the following W=1 kernel build warning(s): vc4_plane.c: In function ‘vc4_plane_init’: vc4_plane.c:1340:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Signed-off-by: Tian Tao <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-11drm/vc4: Fix bitwise OR versus ternary operator in vc4_plane_mode_setNathan Chancellor1-2/+2
Clang warns: drivers/gpu/drm/vc4/vc4_plane.c:901:27: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] fb->format->has_alpha ? ~~~~~~~~~~~~~~~~~~~~~ ^ drivers/gpu/drm/vc4/vc4_plane.c:901:27: note: place parentheses around the '|' expression to silence this warning fb->format->has_alpha ? ~~~~~~~~~~~~~~~~~~~~~ ^ drivers/gpu/drm/vc4/vc4_plane.c:901:27: note: place parentheses around the '?:' expression to evaluate it first fb->format->has_alpha ? ~~~~~~~~~~~~~~~~~~~~~~^ 1 warning generated. Add the parentheses as that was clearly intended, otherwise SCALER5_CTL2_ALPHA_PREMULT won't be added to the list. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Nathan Chancellor <[email protected]> Link: https://github.com/ClangBuiltLinux/linux/issues/1150 Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-11drm/vc4: Update type of reg parameter in vc4_hdmi_{read,write}Nathan Chancellor1-2/+2
Clang warns 100+ times in the vc4 driver along the lines of: drivers/gpu/drm/vc4/vc4_hdmi_phy.c:518:13: warning: implicit conversion from enumeration type 'enum vc4_hdmi_field' to different enumeration type 'enum vc4_hdmi_regs' [-Wenum-conversion] HDMI_WRITE(HDMI_TX_PHY_POWERDOWN_CTL, ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~ The HDMI_READ and HDMI_WRITE macros pass in enumerators of type vc4_hdmi_field but vc4_hdmi_write and vc4_hdmi_read expect a enumerator of type vc4_hdmi_regs, causing a warning for every instance of this. Update the parameter type so there is no more mismatch. Fixes: 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction") Signed-off-by: Nathan Chancellor <[email protected]> Link: https://github.com/ClangBuiltLinux/linux/issues/1149 Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-10drm/vc4: hdmi: Fix NULL vs IS_ERR() checks in vc5_hdmi_init_resources()Dan Carpenter1-16/+16
The devm_ioremap() function never returns error pointers, it returns NULL. Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20200910100825.GC79916@mwanda
2020-09-10drm/vc4: hdmi: Fix off by ones in vc4_hdmi_read/write()Dan Carpenter1-2/+2
The variant->registers[] has ->num_registers elements so the > comparison needs to be changes to >= to prevent an out of bounds access. Fixes: 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20200910100748.GA79916@mwanda
Powered by cgit, Gruvboxed by Blaster4385.