summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2021-05-25drm/i915/display/adl_p: Drop earlier return in tc_has_modular_fia()José Roberto de Souza1-4/+2
MODULAR_FIA_MASK is set in adl_p so we can drop this ealier return and read registers. Also to avoid warnings from icl_tc_port_assert_ref_held() when calling tc_cold_block() in this functions it is necessary to held the lock. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524214805.259692-1-jose.souza@intel.com
2021-05-25drm/amdgpu: Fix crash when hot unplug in BACOAndrey Grodzovsky1-0/+4
Problem: When device goes into runtime suspend due to prolonged inactivity (e.g. BACO sleep) and then hot unplugged, PCI core will try to wake up the device as part of unplug process. Since the device is gone all HW programming during rpm resume fails leading to a bad SW state later during pci remove handling. Fix: Use a flag we use for PCIe error recovery to avoid accessing registres. This allows to successfully complete rpm resume sequence and finish pci remove. v2: Renamed HW access block flag Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1081 Link: https://patchwork.freedesktop.org/patch/msgid/20210521204122.762288-2-andrey.grodzovsky@amd.com
2021-05-25drm/amdgpu: Rename flag which prevents HW accessAndrey Grodzovsky5-8/+8
Make it's name not feature but function descriptive. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210521204122.762288-1-andrey.grodzovsky@amd.com
2021-05-25drm/i915/gt: Move CS interrupt handler to the backendChris Wilson9-74/+124
The different submission backends each have their own preferred behaviour and interrupt setup. Let each handle their own interrupts. This becomes more useful later as we to extract the use of auxiliary state in the interrupt handler that is backend specific. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210521183215.65451-4-matthew.brost@intel.com
2021-05-25drm/i915/gt: Move submission_method into intel_gtChris Wilson11-33/+32
Since we setup the submission method for the engines once, it is easy to assign an enum and use that instead of probing into the backends. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210521183215.65451-3-matthew.brost@intel.com
2021-05-25drm/i915/gt: Move engine setup out of set_default_submissionChris Wilson3-56/+44
Now that we no longer switch back and forth between guc and execlists, we no longer need to restore the backend's vfunc and can leave them set after initialisation. The only catch is that we lose the submission on wedging and still need to reset the submit_request vfunc on unwedging. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210521183215.65451-2-matthew.brost@intel.com
2021-05-25drm/ingenic: Add option to alloc cached GEM buffersPaul Cercueil3-7/+74
Alloc GEM buffers backed by noncoherent memory on SoCs where it is actually faster than write-combine. This dramatically speeds up software rendering on these SoCs, even for tasks where write-combine memory should in theory be faster (e.g. simple blits). v3: The option is now selected per-SoC instead of being a module parameter. v5: - Fix drm_atomic_get_new_plane_state() used to retrieve the old state - Use custom drm_gem_fb_create() - Only check damage clips and sync DMA buffers if non-coherent buffers are used Signed-off-by: Paul Cercueil <paul@crapouillou.net> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210523170415.90410-4-paul@crapouillou.net
2021-05-25drm: Add and export function drm_fb_cma_sync_non_coherentPaul Cercueil1-0/+46
This function can be used by drivers that use damage clips and have CMA GEM objects backed by non-coherent memory. Calling this function in a plane's .atomic_update ensures that all the data in the backing memory have been written to RAM. v3: - Only sync data if using GEM objects backed by non-coherent memory. - Use a drm_device pointer instead of device pointer in prototype v5: - Rename to drm_fb_cma_sync_non_coherent - Invert loops for better cache locality - Only sync BOs that have the non-coherent flag - Move to drm_fb_cma_helper.c to avoid circular dependency Signed-off-by: Paul Cercueil <paul@crapouillou.net> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210523170415.90410-3-paul@crapouillou.net
2021-05-25drm: Add support for GEM buffers backed by non-coherent memoryPaul Cercueil1-9/+29
Having GEM buffers backed by non-coherent memory is interesting in the particular case where it is faster to render to a non-coherent buffer then sync the data cache, than to render to a write-combine buffer, and (by extension) much faster than using a shadow buffer. This is true for instance on some Ingenic SoCs, where even simple blits (e.g. memcpy) are about three times faster using this method. Add a 'map_noncoherent' flag to the drm_gem_cma_object structure, which can be set by the drivers when they create the dumb buffer. Since this really only applies to software rendering, disable this flag as soon as the CMA objects are exported via PRIME. v3: New patch. Now uses a simple 'map_noncoherent' flag to control how the objects are mapped, and use the new dma_mmap_pages function. v4: Make sure map_noncoherent is always disabled when creating GEM objects meant to be used with dma-buf. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210523170415.90410-2-paul@crapouillou.net
2021-05-25drm/i915/debugfs: Print remap info for DPT VMAs as wellImre Deak2-3/+19
Similarly to GGTT VMAs, DPT VMAs can be also a remapped or rotated view of the mapped object, so make sure we debug print the details for these views as well besides the normal view. While at it also fix the debug print for the VMA type of DPT VMAs. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524172703.2113058-3-imre.deak@intel.com
2021-05-25drm/i915/adlp: Fix GEM VM asserts for DPT VMsImre Deak3-3/+4
An object mapped via DPT can have remapped and rotated VMA instances besides the normal VMA instance, similarly to GGTT VMA instances. Adjust the corresponding VMA lookup asserts. While at it also check if a DPT VM is passed incorrectly to i915_vm_to_ppgtt(). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524172703.2113058-2-imre.deak@intel.com
2021-05-25drm/i915/adlp: Require DPT FB CCS color planes to be 2MB alignedImre Deak1-2/+11
All DPT FB color plane surface base addresses must be 2MB aligned. On ADL_P this means that the offsets in CCS FB object must be also 2MB aligned. Adjusting unaligned offsets for these FBs during commit time (compensating with the x/y offsets) doesn't work, since the big alignment would most probably lead to an x/y offset mismatch error between the main and CCS planes. We can overcome this limitation by remapping CCS FBs, so that each color plane is at an aligned offset, leaving x/y for each plane unadjusted during commit and so not causing an x/y mismatch error. However remapping for CCS FBs will be done as a follow-up, so for now require that user space allocates the FB obj with properly aligned planes. v2: s/SZ_2M/512*4k/ for clarity. (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524172703.2113058-1-imre.deak@intel.com
2021-05-25drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4Imre Deak1-38/+33
The driver currently disables the LTTPR non-transparent link training mode for sinks with a DPCD_REV<1.4, based on the following description of the LTTPR DPCD register range in DP standard 2.0 (at the 0xF0000 register description): "" LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for DPCD r1.4 (or higher). """ The transparent link training mode should still work fine, however the implementation for this in some retimer FWs seems to be broken, see the References: link below. After discussions with DP standard authors the above "DPCD r1.4" does not refer to the DPCD revision (stored in the DPCD_REV reg at 0x00000), rather to the "LTTPR field data structure revision" stored in the 0xF0000 reg. An update request has been filed at vesa.org (see wg/Link/documentComment/3746) for the upcoming v2.1 specification to clarify the above description along the following lines: """ LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 1.4 (or higher) """ Based on my tests Windows uses the non-transparent link training mode for DPCD_REV==1.2 sinks as well (so presumably for all DPCD_REVs), and forcing it to use transparent mode on ICL/TGL platforms leads to the same LT failure as reported at the References: link. Based on the above let's assume that the transparent link training mode is not well tested/supported and align the code to the correct interpretation of what the r1.4 version refers to. Reported-and-tested-by: Casey Harkins <caseyharkins@gmail.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3415 Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") Cc: <stable@vger.kernel.org> # v5.11+ Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210512212809.1234701-1-imre.deak@intel.com (cherry picked from commit cb4920cc40f630b5a247f4ed7d3dea66749df588) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-05-25drm/vc4: hdmi: Fix PM reference leak in vc4_hdmi_encoder_pre_crtc_co()Zou Wei1-1/+1
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/1621840854-105978-1-git-send-email-zou_wei@huawei.com
2021-05-25drm/meson: fix shutdown crash when component not probedNeil Armstrong1-4/+5
When main component is not probed, by example when the dw-hdmi module is not loaded yet or in probe defer, the following crash appears on shutdown: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 ... pc : meson_drv_shutdown+0x24/0x50 lr : platform_drv_shutdown+0x20/0x30 ... Call trace: meson_drv_shutdown+0x24/0x50 platform_drv_shutdown+0x20/0x30 device_shutdown+0x158/0x360 kernel_restart_prepare+0x38/0x48 kernel_restart+0x18/0x68 __do_sys_reboot+0x224/0x250 __arm64_sys_reboot+0x24/0x30 ... Simply check if the priv struct has been allocated before using it. Fixes: fa0c16caf3d7 ("drm: meson_drv add shutdown function") Reported-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430082744.3638743-1-narmstrong@baylibre.com
2021-05-25drm/i915/display: fix typo when returning tableLucas De Marchi1-1/+1
Fix table returned when port_clock > 270000: drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c:752:47: error: variable 'adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] Initial version of the patch had it in a single table, but on second version the table got split, but we continued to reference just one of them. Fixes: ca962882268a ("drm/i915/adl_p: Define and use ADL-P specific DP translation tables") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210521005209.4058702-1-lucas.demarchi@intel.com
2021-05-25drm/panel: panel-simple: Add missing pm_runtime_dont_use_autosuspend() callsDouglas Anderson1-0/+2
The PM Runtime docs specifically call out the need to call pm_runtime_dont_use_autosuspend() in the remove() callback if pm_runtime_use_autosuspend() was called in probe(): > Drivers in ->remove() callback should undo the runtime PM changes done > in ->probe(). Usually this means calling pm_runtime_disable(), > pm_runtime_dont_use_autosuspend() etc. We should do this. This fixes a warning splat that I saw when I was testing out the panel-simple's remove(). Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210517130450.v7.1.I9e947183e95c9bd067c9c1d51208ac6a96385139@changeid
2021-05-24drm/vc4: hdmi: Add a workqueue to set scramblingMaxime Ripard2-0/+27
It looks like some displays (like the LG 27UL850-W) don't enable the scrambling when the HDMI driver enables it. However, if we set later the scrambler enable bit, the display will work as expected. Let's create delayed work queue to periodically look at the display scrambling status, and if it's not set yet try to enable it again. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-12-maxime@cerno.tech
2021-05-24drm/vc4: hdmi: Enable the scramblerMaxime Ripard2-0/+67
The HDMI controller on the BCM2711 includes a scrambler in order to reach the HDMI 2.0 modes that require it. Let's add the support for it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-11-maxime@cerno.tech
2021-05-24drm/vc4: hdmi: Check and warn if we can't reach 4kp60 frequenciesMaxime Ripard2-0/+39
In order to reach the frequencies needed to output at 594MHz, the firmware needs to be configured with the appropriate parameters in the config.txt file (enable_hdmi_4kp60 and force_turbo). Let's detect it at bind time, warn the user if we can't, and filter out the relevant modes. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-10-maxime@cerno.tech
2021-05-24drm/vc4: hdmi: Properly compute the BVB clock rateMaxime Ripard1-8/+9
The BVB clock rate computation doesn't take into account a mode clock of 594MHz that we're going to need to support 4k60. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-9-maxime@cerno.tech
2021-05-24drm/vc4: hvs: Make the HVS bind firstMaxime Ripard1-1/+10
We'll need to have the HVS binding before the HDMI controllers so that we can check whether the firmware allows to run in 4kp60. Reorder a bit the component list, and document the current constraints we're aware of. Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-8-maxime@cerno.tech
2021-05-24drm/vc4: hdmi: Prevent clock unbalanceMaxime Ripard1-0/+8
Since we fixed the hooks to disable the encoder at boot, we now have an unbalanced clk_disable call at boot since we never enabled them in the first place. Let's mimic the state of the hardware and enable the clocks at boot if the controller is enabled to get the use-count right. Cc: <stable@vger.kernel.org> # v5.10+ Fixes: 09c438139b8f ("drm/vc4: hdmi: Implement finer-grained hooks") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-7-maxime@cerno.tech
2021-05-24drm/vc4: crtc: Lookup the encoder from the register at bootMaxime Ripard1-4/+34
At boot, we can't rely on the vc4_get_crtc_encoder since we don't have a state yet and thus will not be able to figure out which connector is attached to our CRTC. However, we have a muxing bit in the CRTC register we can use to get the encoder currently connected to the pixelvalve. We can thus read that register, lookup the associated register through the vc4_pv_data structure, and then pass it to vc4_crtc_disable so that we can perform the proper operations. Fixes: 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-6-maxime@cerno.tech
2021-05-24drm/vc4: crtc: Fix vc4_get_crtc_encoder logicMaxime Ripard1-5/+16
The vc4_get_crtc_encoder function currently only works when the connector->state->crtc pointer is set, which is only true when the connector is currently enabled. However, we use it as part of the disable path as well, and our lookup will fail in that case, resulting in it returning a null pointer we can't act on. We can access the connector that used to be connected to that crtc though using the old connector state in the disable path. Since we want to support both the enable and disable path, we can support it by passing the state accessor variant as a function pointer, together with the atomic state. Fixes: 792c3132bc1b ("drm/vc4: encoder: Add finer-grained encoder callbacks") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-5-maxime@cerno.tech
2021-05-24drm/vc4: crtc: Pass the drm_atomic_state to config_pvMaxime Ripard1-4/+4
The vc4_crtc_config_pv will need to access the drm_atomic_state structure and its only parent function, vc4_crtc_atomic_enable already has access to it. Let's pass it as a parameter. Fixes: 792c3132bc1b ("drm/vc4: encoder: Add finer-grained encoder callbacks") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-4-maxime@cerno.tech
2021-05-24drm/vc4: crtc: Skip the TXPMaxime Ripard1-0/+3
The vc4_set_crtc_possible_masks is meant to run over all the encoders and then set their possible_crtcs mask to their associated pixelvalve. However, since the commit 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own"), the TXP has been turned to a CRTC and encoder of its own, and while it does indeed register an encoder, it no longer has an associated pixelvalve. The code will thus run over the TXP encoder and set a bogus possible_crtcs mask, overriding the one set in the TXP bind function. In order to fix this, let's skip any virtual encoder. Cc: <stable@vger.kernel.org> # v5.9+ Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-3-maxime@cerno.tech
2021-05-24drm/vc4: txp: Properly set the possible_crtcs maskMaxime Ripard1-1/+1
The current code does a binary OR on the possible_crtcs variable of the TXP encoder, while we want to set it to that value instead. Cc: <stable@vger.kernel.org> # v5.9+ Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-2-maxime@cerno.tech
2021-05-24drm/vc4: Separate VEC compatible variantsMateusz Kwiatkowski1-5/+22
The VEC's DAC on BCM2711 is slightly different compared to the one on BCM283x and needs different configuration. In particular, bit 3 (mask 0x8) switches the BCM2711 DAC input to "self-test input data", which makes the output unusable. Separating two compatible variants in devicetrees and the DRM driver was therefore necessary. The configurations used for both variants have been borrowed from Raspberry Pi (model 3B for BCM283x, 4B for BCM2711) firmware defaults. Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210520150344.273900-4-maxime@cerno.tech
2021-05-24drm/vc4: Fix clock source for VEC PixelValve on BCM2711Mateusz Kwiatkowski1-1/+1
On the BCM2711 (Raspberry Pi 4), the VEC is actually connected to output 2 of pixelvalve3. NOTE: This contradicts the Broadcom docs, but has been empirically tested and confirmed by Raspberry Pi firmware devs. Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210520150344.273900-2-maxime@cerno.tech
2021-05-24drm/i915/gvt: Add missing macro name changesAnusha Srivatsa1-4/+4
Propogate changes to macros name containing CSR_* to DMC_* from display side. Fixes: 0633cdcbaa77 ("drm/i915/dmc: Rename macro names containing csr") Cc: intel-gvt-dev@lists.freedesktop.org Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210521174047.3861-1-anusha.srivatsa@intel.com
2021-05-22Merge drm/drm-next into drm-misc-nextThomas Zimmermann369-4151/+63819
Backmerging from drm/drm-next to the patches for AMD devices for v5.14. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2021-05-22drm/mcde: Remove redundant error printing in mcde_dsi_probe()Zhen Lei1-3/+1
When devm_ioremap_resource() fails, a clear enough error message will be printed by its subfunction __devm_ioremap_resource(). The error information contains the device name, failure cause, and possibly resource information. Therefore, remove the error printing here to simplify code and reduce the binary size. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210511091344.4508-1-thunder.leizhen@huawei.com
2021-05-22drm/panel: s6e63m0: Depromote debug printsLinus Walleij1-3/+3
The dev_info():s in the DSI driver are very talkative, depromote these to dev_dbg(). Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210313230913.4108256-1-linus.walleij@linaro.org
2021-05-22drm/amd/amdkfd: Drop unnecessary NULL check after container_ofGuenter Roeck1-2/+0
The first parameter passed to container_of() is the pointer to the work structure passed to the worker and never NULL. The NULL check on the result of container_of() is therefore unnecessary and misleading. Remove it. This change was made automatically with the following Coccinelle script. @@ type t; identifier v; statement s; @@ <+... ( t v = container_of(...); | v = container_of(...); ) ... when != v - if (\( !v \| v == NULL \) ) s ...+> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-22drm/amdgpu: Fix inconsistent indentingJiapeng Chong1-7/+6
Eliminate the follow smatch warning: drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c:449 sdma_v5_0_ring_emit_mem_sync() warn: inconsistent indenting. Reviewed-by: Christian König <christian.koenig@amd.com> Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-22drm/amdgpu/apci: switch ATIF/ATCS probe orderAlex Deucher1-8/+6
Try the handle from ATPX first since this is the most common case. Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-22drm/amdgpu/acpi: unify ATCS handling (v3)Alex Deucher2-52/+93
Treat it like ATIF and check both the dGPU and APU for the method. This is required because ATCS may be hung off of the APU in ACPI on A+A systems. v2: add back accidently removed ACPI handle check. v3: Fix incorrect atif check (Colin) Fix uninitialized variable (Colin) Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-22drm/amdgpu/display: make backlight setting failure messages debugAlex Deucher1-2/+2
Avoid spamming the log. The backlight controller on DCN chips gets powered down when the display is off, so if you attempt to set the backlight level when the display is off, you'll get this message. This isn't a problem as we cache the requested backlight level if it's adjusted when the display is off and set it again during modeset. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: nicholas.choi@amd.com Cc: harry.wentland@amd.com
2021-05-22drm/amd/display: Fix GPU scaling regression by FS video supportNicholas Kazlauskas1-7/+7
[Why] FS video support regressed GPU scaling and the scaled buffer ends up stuck in the top left of the screen at native size - full, aspect, center scaling modes do not function. This is because decide_crtc_timing_for_drm_display_mode() does not get called when scaling is enabled. [How] Split recalculate timing and scaling into two different flags. We don't want to call drm_mode_set_crtcinfo() for scaling, but we do want to call it for FS video. Optimize and move preferred_refresh calculation next to decide_crtc_timing_for_drm_display_mode() like it used to be since that's not used for FS video. We don't need to copy over the VIC or polarity in the case of FS video modes because those don't change. Fixes: 6f59f229f8ed7a ("drm/amd/display: Skip modeset for front porch change") Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-22drm/amdgpu: Use preemptible placement for KFDFelix Kuehling1-3/+4
KFD userptr BOs and SG BOs used for DMA mappings can be preempted with CWSR. Therefore we can use preemptible placement and avoid unwanted evictions due to GTT accounting. Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-22drm/amdgpu: Add new placement for preemptible SG BOsFelix Kuehling6-9/+243
SG BOs such as dmabuf imports and userptr BOs do not consume system resources directly. Instead they point to resources owned elsewhere. They typically get evicted by DMABuf move notifiers of MMU notifiers. If those notifiers don't need to wait for hardware fences (i.e. the SG BOs are used in a preemptible context), then we don't need to limit them to the GTT size and we don't need TTM to evict them. Create a new placement for such preemptible SG BOs that does not impose artificial size limits and TTM evictions. Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-22drm/amd/display: Allow bandwidth validation for 0 streams.Bindu Ramamurthy1-1/+1
[Why] Bandwidth calculations are triggered for non zero streams, and in case of 0 streams, these calculations were skipped with pstate status not being updated. [How] As the pstate status is applicable for non zero streams, check added for allowing 0 streams inline with dcn internal bandwidth validations. Signed-off-by: Bindu Ramamurthy <bindu.r@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-22drm/amd/pm: fix return value in aldebaran_set_mp1_state()Feifei Xu1-3/+1
For default cases,we should return 0. Otherwise resume will abort because of the wrong return value. Signed-off-by: Feifei Xu <Feifei.Xu@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-22drm/amd/pm: Correct reserved uint32_t number in beige_goby_PPTableChengming Gui1-1/+1
Correct reserved number according to the latest struct in drm-next Signed-off-by: Chengming Gui <Jack.Gui@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-21drm/i915/gvt: remove local storage of debugfs fileGreg Kroah-Hartman1-6/+5
There is no need to keep the dentry around for the debugfs kvmgt cache file, as we can just look it up when we want to remove it later on. Simplify the structure by removing the dentry and relying on debugfs to find the dentry to remove when we want to. By doing this change, we remove the last in-kernel user that was storing the result of debugfs_create_long(), so that api can be cleaned up. 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: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gvt-dev@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20210518161705.3697143-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-21drm/amd/amdgpu/smuio_v13_0: Realign ↵Lee Jones1-1/+1
'smuio_v13_0_is_host_gpu_xgmi_supported()' header Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/smuio_v13_0.c:99: warning: expecting prototype for smuio_v13_0_supports_host_gpu_xgmi(). Prototype was for smuio_v13_0_is_host_gpu_xgmi_supported() instead Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-21drm/amd/amdgpu/gfx_v10_0: Demote kernel-doc abuseLee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:51: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-21drm/amd/amdgpu/vcn_v1_0: Fix some function naming disparityLee Jones1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c:775: warning: expecting prototype for vcn_v1_0_start(). Prototype was for vcn_v1_0_start_spg_mode() instead drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c:1111: warning: expecting prototype for vcn_v1_0_stop(). Prototype was for vcn_v1_0_stop_spg_mode() instead Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-05-21drm/amd/amdgpu/sdma_v5_2: Repair typo in function nameLee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:501: warning: expecting prototype for sdma_v_0_ctx_switch_enable(). Prototype was for sdma_v5_2_ctx_switch_enable() instead Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-30 06:36:25 +0300