aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2022-01-20drm/i915/dmc: Eliminate remnant GEN<n> referencesMadhumitha Tolakanahalli Pradeep1-7/+7
Replace GEN<n> with DISPLAY_VER<n>, in line with the naming convention followed in the i915 driver code. Signed-off-by: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217034141.198033-1-madhumitha.tolakanahalli.pradeep@intel.com
2022-01-20drm/i915: Clean up vlv/chv sprite plane registersVille Syrjälä2-42/+70
Use REG_BIT() & co. to polish the vlv/chv sprite plane registers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-10-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2022-01-19drm/amd/display: change FIFO reset condition to embedded display onlyZhan Liu1-1/+1
[Why] FIFO reset is only necessary for fast boot sequence, where otg is disabled and dig fe is enabled when changing dispclk. Fast boot is only enabled on embedded displays. [How] Change FIFO reset condition to "embedded display only". Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amd/display: Correct MPC split policy for DCN301Zhan Liu1-1/+1
[Why] DCN301 has seamless boot enabled. With MPC split enabled at the same time, system will hang. [How] Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have ODM combine enabled on DCN301, pipe split is not necessary here. Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdkfd: enable heavy-weight TLB flush on ArcturusEric Huang2-8/+8
SDMA FW fixes the hang issue for adding heavy-weight TLB flush on Arcturus, so we can enable it. Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: fix broken debug sdma vram access functionJonathan Kim1-7/+8
Debug VRAM access through SDMA has several broken parts resulting in silent MMIO fallback. BO kernel creation takes the location of the cpu addr pointer, not the pointer itself for address kmap. drm_dev_enter return true on success so change access check. The source BO is reserved but not pinned so find the address using the cursor offset relative to its memory domain start. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: remove gart.ready flagChristian König11-137/+52
That's just a leftover from old radeon days and was preventing CS and GART bindings before the hardware was initialized. But nowdays that is perfectly valid. The only thing we need to warn about are GART binding before the table is even allocated. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: remove unused variable warningStanley.Yang2-29/+0
Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: remove unused variablemziya1-4/+0
Remove set but unused variable. warning: variable 'umc_reg_offset' set but not used Signed-off-by: mziya <Mohammadzafar.ziya@amd.com> Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: Remove repeated callsyipechai1-3/+1
Remove repeated calls. Signed-off-by: yipechai <YiPeng.Chai@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: modify a pair of functions for the pcie port wreg/rregXiaojian Du3-32/+39
This patch will modify a pair of functions for pcie port wreg/rreg. AMD GPU have had an independent NBIO block from SOC15 arch. If the dirver wants to read/write the address space of the pcie devices, it has to go through the NBIO block. This patch will move the pcie port wreg/rreg functions to "amdgpu_device.c", so that to reuse the functions on the future GPU ASICs. Signed-off-by: Xiaojian Du <Xiaojian.Du@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-19drm/amdgpu: add vram check function for GMCXiaojian Du7-5/+74
This patch will add vram check function for GMC block. It will write pattern data to the vram and then read back from the vram, so that to verify the work status of vram. This patch will cover gmc v6/7/8/9/10. Signed-off-by: Xiaojian Du <Xiaojian.Du@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-20drm/i915/hdmi: Ignore DP++ TMDS clock limit for native HDMI portsVille Syrjälä1-0/+8
Lots of machines these days seem to have a crappy type1 DP dual mode adaptor chip slapped onto the motherboard. Based on the DP dual mode spec we currently limit those to 165MHz max TMDS clock. Windows OTOH ignores DP dual mode adaptors when the VBT indicates that the port is not actually DP++, so we can perhaps assume that the vendors did intend that the 165MHz clock limit doesn't apply here. Though it would be much nicer if they actually declared an explicit limit through VBT, but that doesn't seem to be happening either. So in order to match Windows behaviour let's ignore the DP dual mode adaptor's TMDS clock limit for ports that don't look like DP++ in VBT. Unfortunately many older VBTs misdelcare their DP++ ports as just HDMI (eg. ILK Dell Latitude E5410) or DP (eg. SNB Lenovo ThinkPad X220). So we can't really do this universally without risking black screens. I suppose a sensible cutoff is HSW+ since that's when 4k became a thing and one might assume that the machines have been tested to work with higher TMDS clock rates. v2: s/IS_BROADWELL/IS_HASWELL/ Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211222161738.12478-1-ville.syrjala@linux.intel.com
2022-01-20drm/i915/bios: Nuke DEVICE_TYPE_DP_DUAL_MODE_BITSVille Syrjälä2-15/+6
Replace the DEVICE_TYPE_DP_DUAL_MODE_BITS stuff with just a DP+HDMI check. The rest of the bits shouldn't really matter anyway. The slight change in behaviour here is that now we do look at the DEVICE_TYPE_NOT_HDMI_OUTPUT bit (via intel_bios_encoder_supports_hdmi()) when we previously ignored it. The one platform we know that has problems with that bit is VLV. But IIRC the problem was always that buggy VBTs basically never set that bit. So that should be OK since all it would do is make all DVI ports look like HDMI ports instead. Also can't imagine there are many VLV machines with actual DVI ports in existence. We still keep the rest of the dvo_port/aux_ch checks as we can't trust that DP+HDMI device type equals DP++ due to buggy VBTs. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-20drm/i915/bios: Throw out the !has_ddi_port_info() codepathsVille Syrjälä2-105/+9
Now that we parse the DDI port info from the VBT on all g4x+ platforms we can throw out all the old codepaths in intel_bios_is_port_present(), intel_bios_is_port_edp() and intel_bios_is_port_dp_dual_mode(). None of these should be called on pre-g4x platforms. For good measure throw in a WARN into intel_bios_is_port_present() should someone get the urge to call it on older platforms. The other two functions are specific to HDMI and DP so should not need any protection as those encoder types don't even exist on older platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-20drm/i915/bios: Use i915->vbt.ports[] for all g4x+Ville Syrjälä1-4/+1
Extend the vbt.ports[] stuff for all g4x+ platforms. We do need to drop the version check as some elk/ctg machines may have VBTs older than that. The oldest I know is an elk with version 142. But the child device stuff has had the correct size since at least version 125 (observed on my sdg), so from that angle this should be totally safe. This does couple of things: - Start using the aux_ch/ddc_pin from VBT instead of just the hardcoded defaults. Hopefully there are no VBTs with entirely bogus information here. - Start using i915->vbt.ports[] for intel_bios_is_port_dp_dual_mode(). Should be fine as the logic doesn't actually change. - Start using i915->vbt.ports[] for intel_bios_is_port_edp(). The old codepath only looks at the DP DVO ports, the new codepath looks at both DP and HDMI DVO ports. In principle that should not matter. We also stop looking at some of the other device type bits (eg. LVDS,MIPI,ANALOG,etc.). Hopefully no VBT is broken enough that it sets up totally conflicting device type bits (eg. LVDS+eDP at the same time). We also lose the "g4x->no eDP ever" hardcoding (shouldn't be hard to re-introduce that into eg. sanitize_device_type() if needed). Lightly smoke tested on a set of machines (one of ctg,ilk,snb,ivb each) with both DP and HDMI (DP++). Everything still worked as it should. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-19drm/i915/bios: Use i915->vbt.ports[] on CHVVille Syrjälä1-2/+2
CHV is currently straddling the divide by using parse_ddi_ports() stuff for aux_ch/ddc_pin but going through all old codepaths for the rest (intel_bios_is_port_present(), intel_bios_is_port_edp(), intel_bios_is_port_dp_dual_mode()). Let's switch over full and use i915->vbt.ports[] for the rest of the stuff. dvo_port_to_port() doesn't know about DSI so we won't get into any kind of "is port B HDMI or DSI or both?" conundrum, which could otherwise happen on VLV/CHV due to DSI ports living in a separate world from the other digital ports. Including Jani's detailed analysis here for posterity: "We stop checking for port A for CHV in intel_bios_is_port_present(), but it's a warn and I don't recall any bug reports, so probably fine. We could add a check in parse_ddi_port(), but meh. Ditto for intel_bios_is_port_dp_dual_mode(), except it doesn't have a warn. The eDP check in intel_bios_is_port_edp() becomes slightly more relaxed. Both the old and new check require these to be set: - DEVICE_TYPE_DISPLAYPORT_OUTPUT - DEVICE_TYPE_INTERNAL_CONNECTOR. The old code also required these to be unset: - DEVICE_TYPE_MIPI_OUTPUT - DEVICE_TYPE_COMPOSITE_OUTPUT - DEVICE_TYPE_DUAL_CHANNEL - DEVICE_TYPE_LVDS_SIGNALING - DEVICE_TYPE_TMDS_DVI_SIGNALING - DEVICE_TYPE_VIDEO_SIGNALING - DEVICE_TYPE_ANALOG_OUTPUT It's possible we've added these just as a sanity check for broken VBTs more than anything. I guess I'd see if actual problems arise. Bottom line, I think the functional changes matter only for VBTs with bogus data." I agree that it should work assuming the VBT isn't totally insane. Modern windows drivers also don't seem to check any of those additional device type bits, which may or may not matter for older devices (no idea what some old driver versions are checking). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-19drm/i915/bios: Introduce has_ddi_port_info()Ville Syrjälä1-3/+8
Pull the "do we want to use i915->vbt.ports[]?" check into a central place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-19drm/malidp: Replace module initialization with DRM helpersJavier Martinez Canillas1-1/+2
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-11-javierm@redhat.com
2022-01-19drm/arm/hdlcd: Replace module initialization with DRM helpersJavier Martinez Canillas1-1/+2
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-10-javierm@redhat.com
2022-01-19drm/komeda: Replace module initialization with DRM helpersJavier Martinez Canillas1-1/+2
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-9-javierm@redhat.com
2022-01-19drm/imx/dcss: Replace module initialization with DRM helpersJavier Martinez Canillas1-1/+2
Replace module_platform_driver() with drm_module_platform_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-8-javierm@redhat.com
2022-01-19drm/hisilicon/hibmc: Replace module initialization with DRM helpersThomas Zimmermann1-1/+2
Replace module_pci_driver() with drm_module_pci_driver(). The DRM macro respects drm_firmware_drivers_only() and fails if the flag has been set. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-6-javierm@redhat.com
2022-01-19drm/cirrus: Replace module-init boiler-plate code with DRM helpersThomas Zimmermann1-15/+2
Remove custom cirrus_init() and cirrus_exit() functions and initialize the module with DRM module helpers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-5-javierm@redhat.com
2022-01-19drm/bochs: Replace module-init boiler-plate code with DRM helpersThomas Zimmermann1-18/+2
Remove custom bochs_init() and bochs_exit() functions and initialize the module with DRM module helpers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-4-javierm@redhat.com
2022-01-19drm/ast: Replace module-init boiler-plate code with DRM helpersThomas Zimmermann1-16/+2
Remove custom ast_init() and ast_exit() functions and initialize the module with DRM module helpers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-3-javierm@redhat.com
2022-01-19drm/i915: Remove zombie async flip vt-d w/aVille Syrjälä1-12/+0
This async flip vt-d w/a was moved to a different place in commit 7d396cacaea6 ("drm/i195: Make the async flip VT-d workaround dynamic") but the drm-intel-fixes cherry-pick commit b2d73debfdc1 ("drm/i915: Extend the async flip VT-d w/a to skl/bxt") resurrected the original code as well. So now we have this w/a in two places. Remove the resurrected zombie code. Not done as a revert to hopefully prevent any kind of automagic stable backport. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211208150050.17230-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-19drm: panel-orientation-quirks: Add quirk for the 1Netbook OneXPlayerRaymond Jay Golo1-0/+12
The 1Netbook OneXPlayer uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by: Raymond Jay Golo <rjgolo@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220113000619.90988-1-rjgolo@gmail.com
2022-01-19drm/selftests/test-drm_dp_mst_helper: Fix memory leak in sideband_msg_req_encode_decodeJosé Expósito1-1/+3
Avoid leaking the "out" variable if it is not possible to allocate the "txmsg" variable. Fixes: 09234b88ef55 ("drm/selftests/test-drm_dp_mst_helper: Move 'sideband_msg_req_encode_decode' onto the heap") Addresses-Coverity-ID: 1475685 ("Resource leak") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220108165812.46797-1-jose.exposito89@gmail.com
2022-01-19drm/ast: Create threshold values for AST2600KuoHsiang Chou1-1/+4
The threshold value is used for AST2600 only. Signed-off-by: KuoHsiang Chou <kuohsiang_chou@aspeedtech.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220117083643.41493-1-kuohsiang_chou@aspeedtech.com
2022-01-19mgag200 fix memmapsl configuration in GCTL6 registerJocelyn Falempe1-1/+4
On some servers with MGA G200_SE_A (rev 42), booting with Legacy BIOS, the hardware hangs when using kdump and kexec into the kdump kernel. This happens when the uncompress code tries to write "Decompressing Linux" to the VGA Console. It can be reproduced by writing to the VGA console (0xB8000) after booting to graphic mode, it generates the following error: kernel:NMI: PCI system error (SERR) for reason a0 on CPU 0. kernel:Dazed and confused, but trying to continue The root cause is the configuration of the MGA GCTL6 register According to the GCTL6 register documentation: bit 0 is gcgrmode: 0: Enables alpha mode, and the character generator addressing system is activated. 1: Enables graphics mode, and the character addressing system is not used. bit 1 is chainodd even: 0: The A0 signal of the memory address bus is used during system memory addressing. 1: Allows A0 to be replaced by either the A16 signal of the system address (ifmemmapsl is ‘00’), or by the hpgoddev (MISC<5>, odd/even page select) field, described on page 3-294). bit 3-2 are memmapsl: Memory map select bits 1 and 0. VGA. These bits select where the video memory is mapped, as shown below: 00 => A0000h - BFFFFh 01 => A0000h - AFFFFh 10 => B0000h - B7FFFh 11 => B8000h - BFFFFh bit 7-4 are reserved. Current code set it to 0x05 => memmapsl to b01 => 0xa0000 (graphic mode) But on x86, the VGA console is at 0xb8000 (text mode) In arch/x86/boot/compressed/misc.c debug strings are written to 0xb8000 As the driver doesn't use this mapping at 0xa0000, it is safe to set it to 0xb8000 instead, to avoid kernel hang on G200_SE_A rev42, with kexec/kdump. Thus changing the value 0x05 to 0x0d Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220119102905.1194787-1-jfalempe@redhat.com
2022-01-19drm/bridge: Remove extra device acquisition method of i2c client in lt9611 driverZhiming Liu2-4/+4
We have got the device of i2c client in probe function. So we should remove extra device acquisition method of i2c client. Signed-off-by: Zhiming Liu <lzmlzmhh@gmail.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220117154150.5145-1-lzmlzmhh@gmail.com Reviewed-by: Robert Foss <robert.foss@linaro.org>
2022-01-19drm/i915/dpll: make intel_shared_dpll_funcs internal to intel_dpll_mgr.cJani Nikula2-45/+36
Move struct intel_shared_dpll_funcs to intel_dpll_mgr.c, as no other place needs to have access to it. We also don't need to have kernel-doc documentation for file internal structures, so drop them while at it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220119110528.2377899-1-jani.nikula@intel.com
2022-01-19drm/msm: Fix include statements for DisplayPortThomas Zimmermann2-2/+2
Update the include statements for DisplayPort helpers. The header files are in the dp/ subdirectory. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5b529e8d9c38 ("drm/dp: Move public DisplayPort headers into dp/") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reported-by: kernel test robot <lkp@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220118154450.25947-1-tzimmermann@suse.de
2022-01-19drm/selftests: Select DRM_DP_HELPERThomas Zimmermann1-0/+1
Resolve warnings about non-existing symbols by selecting DRM_DP_HELPER. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: adb9d5a2cc77 ("drm/dp: Move DisplayPort helpers into separate helper module") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reported-by: kernel test robot <lkp@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220118154418.25932-1-tzimmermann@suse.de
2022-01-19drm/vc4: Fix deadlock on DSI device attach errorPadmanabha Srinivasaiah1-10/+4
DSI device attach to DSI host will be done with host device's lock held. Un-registering host in "device attach" error path (ex: probe retry) will result in deadlock with below call trace and non operational DSI display. Startup Call trace: [ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8 [ 35.043048] mutex_lock_nested+0x7c/0xc8 [ 35.043060] device_del+0x4c/0x3e8 [ 35.043075] device_unregister+0x20/0x40 [ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28 [ 35.043093] device_for_each_child+0x68/0xb0 [ 35.043105] mipi_dsi_host_unregister+0x40/0x90 [ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4] [ 35.043199] mipi_dsi_attach+0x30/0x48 [ 35.043209] tc358762_probe+0x128/0x164 [tc358762] [ 35.043225] mipi_dsi_drv_probe+0x28/0x38 [ 35.043234] really_probe+0xc0/0x318 [ 35.043244] __driver_probe_device+0x80/0xe8 [ 35.043254] driver_probe_device+0xb8/0x118 [ 35.043263] __device_attach_driver+0x98/0xe8 [ 35.043273] bus_for_each_drv+0x84/0xd8 [ 35.043281] __device_attach+0xf0/0x150 [ 35.043290] device_initial_probe+0x1c/0x28 [ 35.043300] bus_probe_device+0xa4/0xb0 [ 35.043308] deferred_probe_work_func+0xa0/0xe0 [ 35.043318] process_one_work+0x254/0x700 [ 35.043330] worker_thread+0x4c/0x448 [ 35.043339] kthread+0x19c/0x1a8 [ 35.043348] ret_from_fork+0x10/0x20 Shutdown Call trace: [ 365.565417] Call trace: [ 365.565423] __switch_to+0x148/0x200 [ 365.565452] __schedule+0x340/0x9c8 [ 365.565467] schedule+0x48/0x110 [ 365.565479] schedule_timeout+0x3b0/0x448 [ 365.565496] wait_for_completion+0xac/0x138 [ 365.565509] __flush_work+0x218/0x4e0 [ 365.565523] flush_work+0x1c/0x28 [ 365.565536] wait_for_device_probe+0x68/0x158 [ 365.565550] device_shutdown+0x24/0x348 [ 365.565561] kernel_restart_prepare+0x40/0x50 [ 365.565578] kernel_restart+0x20/0x70 [ 365.565591] __do_sys_reboot+0x10c/0x220 [ 365.565605] __arm64_sys_reboot+0x2c/0x38 [ 365.565619] invoke_syscall+0x4c/0x110 [ 365.565634] el0_svc_common.constprop.3+0xfc/0x120 [ 365.565648] do_el0_svc+0x2c/0x90 [ 365.565661] el0_svc+0x4c/0xf0 [ 365.565671] el0t_64_sync_handler+0x90/0xb8 [ 365.565682] el0t_64_sync+0x180/0x184 Signed-off-by: Padmanabha Srinivasaiah <treasure4paddy@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220118005127.29015-1-treasure4paddy@gmail.com
2022-01-19dma-buf: drop excl_fence parameter from dma_resv_get_fencesChristian König3-5/+6
Returning the exclusive fence separately is no longer used. Instead add a write parameter to indicate the use case. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211207123411.167006-4-christian.koenig@amd.com
2022-01-19drm/amdgpu: remove excl as shared workaroundsChristian König2-10/+1
This was added because of the now dropped shared on excl dependency. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211123142111.3885-15-christian.koenig@amd.com
2022-01-19drm: move the buddy allocator from i915 into common drmArunpravin14-1431/+575
Move the base i915 buddy allocator code into drm - Move i915_buddy.h to include/drm - Move i915_buddy.c to drm root folder - Rename "i915" string with "drm" string wherever applicable - Rename "I915" string with "DRM" string wherever applicable - Fix header file dependencies - Fix alignment issues - add Makefile support for drm buddy - export functions and write kerneldoc description - Remove i915 selftest config check condition as buddy selftest will be moved to drm selftest folder cleanup i915 buddy references in i915 driver module and replace with drm buddy v2: - include header file in alphabetical order(Thomas) - merged changes listed in the body section into a single patch to keep the build intact(Christian, Jani) v3: - make drm buddy a separate module(Thomas, Christian) v4: - Fix build error reported by kernel test robot <lkp@intel.com> - removed i915 buddy selftest from i915_mock_selftests.h to avoid build error - removed selftests/i915_buddy.c file as we create a new set of buddy test cases in drm/selftests folder v5: - Fix merge conflict issue v6: - replace drm_buddy_mm structure name as drm_buddy(Thomas, Christian) - replace drm_buddy_alloc() function name as drm_buddy_alloc_blocks() (Thomas) - replace drm_buddy_free() function name as drm_buddy_free_block() (Thomas) - export drm_buddy_free_block() function - fix multiple instances of KMEM_CACHE() entry v7: - fix warnings reported by kernel test robot <lkp@intel.com> - modify the license(Christian) v8: - fix warnings reported by kernel test robot <lkp@intel.com> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220118104504.2349-1-Arunpravin.PaneerSelvam@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
2022-01-18drm/i915/guc: Remove hacks for reset and schedule disable G2H being received out of orderMatthew Brost1-28/+2
In the i915 there are several hacks in place to make request cancellation work with an old version of the GuC which delivered the G2H indicating schedule disable is done before G2H indicating a context reset. Version 69 fixes this, so we can remove these hacks. v2: (Checkpatch) - s/cancelation/cancellation Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220113181351.21296-3-matthew.brost@intel.com
2022-01-18drm/i915/selftests: Add a cancel request selftest that triggers a resetMatthew Brost1-0/+117
Add a cancel request selftest that results in an engine reset to cancel the request as it is non-preemptable. Also insert a NOP request after the cancelled request and confirm that it completes successfully. v2: (Tvrtko) - Skip test if preemption timeout compiled out - Skip test if engine reset isn't supported - Update debug prints to be more descriptive v3: - Add comment explaining test v4: (John Harrison) - Fix typos in comment explaining test - goto out_rq is NOP creation fails Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220113181351.21296-2-matthew.brost@intel.com
2022-01-18drm/radeon: fix error handling in radeon_driver_open_kmsChristian König1-10/+12
The return value was never initialized so the cleanup code executed when it isn't even necessary. Just add proper error handling. Fixes: ab50cb9df889 ("drm/radeon/radeon_kms: Fix a NULL pointer dereference in radeon_driver_open_kms()") Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Jan Stancek <jstancek@redhat.com> Tested-by: Borislav Petkov <bp@suse.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-18drm/amd/amdgpu: fixing read wrong pf2vf data in SRIOVJingwen Chen2-14/+8
[Why] This fixes 892deb48269c ("drm/amdgpu: Separate vf2pf work item init from virt data exchange"). we should read pf2vf data based at mman.fw_vram_usage_va after gmc sw_init. commit 892deb48269c breaks this logic. [How] calling amdgpu_virt_exchange_data in amdgpu_virt_init_data_exchange to set the right base in the right sequence. v2: call amdgpu_virt_init_data_exchange after gmc sw_init to make data exchange workqueue run v3: clean up the code logic v4: add some comment and make the code more readable Fixes: 892deb48269c ("drm/amdgpu: Separate vf2pf work item init from virt data exchange") Signed-off-by: Jingwen Chen <Jingwen.Chen2@amd.com> Reviewed-by: Horace Chen <horace.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-18drm/amdgpu: apply vcn harvest quirkGuchun Chen1-5/+27
This is a following patch to apply the workaround only on those boards with a bad harvest table in ip discovery. Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-18amdgpu/amdgpu_psp: remove unneeded ret variableMinghao Chi1-5/+1
Return value from amdgpu_bo_create_kernel() directly instead of taking this in another redundant variable. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: CGEL ZTE <cgel.zte@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-18drm/radeon: fix UVD suspend errorQiang Ma6-6/+6
I met a bug recently and the kernel log: [ 330.171875] radeon 0000:03:00.0: couldn't schedule ib [ 330.175781] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD (-22)! In radeon drivers, using UVD suspend is as follows: if (rdev->has_uvd) { uvd_v1_0_fini(rdev); radeon_uvd_suspend(rdev); } In radeon_ib_schedule function, we check the 'ring->ready' state, but in uvd_v1_0_fini funciton, we've cleared the ready state. So, just modify the suspend code flow to fix error. Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Qiang Ma <maqianga@uniontech.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-18drm/amdgpu: Add missing pm_runtime_put_autosuspendYongzhi Liu1-1/+3
pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, thus a matching decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Yongzhi Liu <lyz_cs@pku.edu.cn> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-18drm/amd/display: move calcs folder into DMLIsabella Basso11-71/+11
The calcs folder has FPU code on it, which should be isolated inside the DML folder as per https://patchwork.freedesktop.org/series/93042/. This commit aims single-handedly to correct the location of such FPU code and does not refactor any functions. Changes since v2: - Corrected problems to compile when DCN was disabled. Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Isabella Basso <isabbasso@riseup.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-18drm/amd/display: 3.2.169Aric Cyr1-1/+1
This version brings along following fixes: - Organize FPU associated code to DML - Modify SMU_TIMEOUT macro - Organize dcn201 code - Address DS stays disabled problem under specific scenario - Fix black screen issue - Update DML to rev.99 - Address problem of eDP hot-plug feature Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-18drm/amd/display: [FW Promotion] Release 0.0.100.0Anthony Koo1-2/+2
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.