summaryrefslogtreecommitdiffstats
path: root/drivers/gpu (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'drm-misc-fixes-2018-06-21' of ↵Dave Airlie2018-06-223-218/+118
|\ | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Fixes for v4.18-rc2: - A reversion of a commit in drm/sun4i to fix a run-time fault. - Various fixes to the sii8620 bridge. - Small bugfix to correctly check stride in atmel-hlcdc. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/787d4bef-a579-4046-d0fc-f8c2c5b80c25@linux.intel.com
| * drm/bridge/sii8620: fix display of packed pixel modes in MHL2Maciej Purski2018-06-211-16/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently packed pixel modes in MHL2 can't be displayed. The device automatically recognizes output format, so setting format other than RGB causes failure. Fix it by writing proper values to registers. Tested on MHL1 and MHL2 using various vendors' dongles both in DVI and HDMI mode. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1516706239-9104-1-git-send-email-m.purski@samsung.com
| * Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"Paul Kocialkowski2018-06-181-25/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 2c17a4368aad2b88b68e4390c819e226cf320f70. The offending commit triggers a run-time fault when accessing the panel element of the sun4i_tcon structure when no such panel is attached. It was apparently assumed in said commit that a panel is always used with the TCON. Although it is often the case, this is not always true. For instance a bridge might be used instead of a panel. This issue was discovered using an A13-OLinuXino, that uses the TCON in RGB mode for a simple DAC-based VGA bridge. Cc: stable@vger.kernel.org Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180613081647.31183-1-paul.kocialkowski@bootlin.com
| * drm/atmel-hlcdc: check stride values in the first planeStefan Agner2018-06-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The statement always evaluates to true since the struct fields are arrays. This has shown up as a warning when compiling with clang: warning: address of array 'desc->layout.xstride' will always evaluate to 'true' [-Wpointer-bool-conversion] Check for values in the first plane instead. Fixes: 1a396789f65a ("drm: add Atmel HLCDC Display Controller support") Cc: <stable@vger.kernel.org> Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180617084826.31885-1-stefan@agner.ch
| * drm/bridge/sii8620: fix HDMI cable connection to dongleMaciej Purski2018-06-131-23/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MHL bridge is usually connected to TV via MHL dongle. Currently plugging HDMI cable to dongle is handled improperly. Fix it by splitting connecting of a dongle and a HDMI cable. The driver should now handle unplugging a sink from a dongle and plugging a different sink with new edid. Tested on MHL1, MHL2 and MHL3 using various vendors' dongles both in DVI and HDMI mode. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1516705996-8928-1-git-send-email-m.purski@samsung.com
| * drm/bridge/sii8620: remove HSIC initializationMaciej Purski2018-06-131-38/+0
| | | | | | | | | | | | | | | | | | | | HSIC initialization was taken from the vendor code. HSIC in MHL circuit is not connected, so it is not possible to test it. Tests prove that without HSIC the device works well. Therefore it can be removed. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1511968368-30884-1-git-send-email-m.purski@samsung.com
| * drm/bridge/sii8620: start MHL transmission after HDMI signal detectionMaciej Purski2018-06-131-51/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The vendor code waits for infoframe to detect video mode set by source. We do not need to follow this pattern, because video mode information is provided by drm core. As a result most of the infoframe handling code can be removed. Start transmission immediately after detecting stream on HDMI lines in irq_scdt() function without waiting for infoframe interrupt. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1511956130-24482-1-git-send-email-m.purski@samsung.com
| * drm/bridge/sii8620: fix potential buffer overflowMaciej Purski2018-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Buffer overflow error should not occur, as mode_fixup() callback filters pixel clock value and it should never exceed 600000. However, current implementation is not obviously safe and relies on implementation of mode_fixup(). Make 'i' variable never reach unsafe value in order to avoid buffer overflow error. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: bf1722ca ("drm/bridge/sii8620: rewrite hdmi start sequence") Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1511341718-6974-1-git-send-email-m.purski@samsung.com
| * drm/bridge/sii8620: fix display modes validationMaciej Purski2018-06-131-39/+41
| | | | | | | | | | | | | | | | | | | | | | Current implementation of mode_valid() and mode_fixup() callbacks handle packed pixel modes improperly. Fix it by using proper maximum clock values from the documentation. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1517568865-25219-1-git-send-email-m.purski@samsung.com
| * drm/bridge/sii8620: fix loops in EDID fetch logicAndrzej Hajda2018-06-131-11/+20
| | | | | | | | | | | | | | | | | | | | Function should constantly check if cable is connected and finish in finite time. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Maciej Purski <m.purski@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180115173357.31067-4-a.hajda@samsung.com
| * drm/bridge/sii8620: simplify hardware reset procedureAndrzej Hajda2018-06-131-13/+10
| | | | | | | | | | | | | | | | | | | | There is no need to flip reset pin twice. Also delays can be changed to values present in vendor's code. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Maciej Purski <m.purski@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180608060457.18357-1-a.hajda@samsung.com
* | Merge tag 'drm-intel-fixes-2018-06-21' of ↵Dave Airlie2018-06-2217-77/+204
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v4.18-rc2: - Mostly cc: stable display fixes, including a DBLSCAN regression fix - GEM fixes for this merge window Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/87d0wkuypy.fsf@intel.com
| * | drm/i915: Enable provoking vertex fix on Gen9 systems.Kenneth Graunke2018-06-192-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SF and clipper units mishandle the provoking vertex in some cases, which can cause misrendering with shaders that use flat shaded inputs. There are chicken bits in 3D_CHICKEN3 (for SF) and FF_SLICE_CHICKEN (for the clipper) that work around the issue. These registers are unfortunately not part of the logical context (even the power context), and so we must reload them every time we start executing in a context. Bugzilla: https://bugs.freedesktop.org/103047 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180615190605.16238-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org (cherry picked from commit b77422f80337d363eed60c8c48db9cb6e33085c9) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | drm/i915: Fix context ban and hang accounting for clientMika Kuoppala2018-06-193-25/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If client is smart or lucky enough to create a new context after each hang, our context banning mechanism will never catch up, and as a result of that it will be saved from client banning. This can result in a never ending streak of gpu hangs caused by bad or malicious client, preventing access from other legit gpu clients. Fix this by always incrementing per client ban score if it hangs in short successions regardless of context ban scoring. The exception are non bannable contexts. They remain detached from client ban scoring mechanism. v2: xchg timestamp, tidyup (Chris) v3: comment, bannable & banned together (Chris) Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180615104429.31477-1-mika.kuoppala@linux.intel.com (cherry picked from commit 14921f3cef85b0167a9145e5f29b9dfc3b2a84dc) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | drm/i915: Turn off g4x DP port in .post_disable()Ville Syrjälä2018-06-191-16/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While Bspec doesn't list a specific sequence for turning off the DP port on g4x we are getting an underrun if the port is disabled in the .disable() hook. Looks like the pipe stops when the port stops, and by that time the plane disable may not have completed yet. Also the plane(s) seem to end up in some wonky state when this happens as they also signal another underrun immediately after we turn them back on during the next enable sequence. We could add a vblank wait in .disable() to avoid wedging the planes, but I assume we're still tripping up the pipe in some way. So it seems better to me to just follow the ILK+ sequence and turn off the DP port in .post_disable() instead. This sequence doesn't seem to suffer from this problem. Could be it was always the intended sequence for DP and the gen4 bspec was just never updated to include it. Originally we used the bad sequence even on ilk+, but I changed that in commit 08aff3fe26ae ("drm/i915: Move DP port disable to post_disable for pch platforms") as it was causing issues on those platforms as well. I left out g4x then only because I didn't have the hardware to test it. Now that I do it's fairly clear that the ilk+ sequence is also the right choice for g4x. v2: Fix whitespace fail (Jani) Mention the ilk+ commit (Jani) Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180613160553.11664-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 51a9f6dfc00d35f927ecfaf6f0ae8ebaba39b3fe) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | drm/i915: Disallow interlaced modes on g4x DP outputsVille Syrjälä2018-06-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looks like interlaced DP output doesn't work on g4x either. Not all that surprising considering we already established that interlaced DP output is busted on VLV/CHV. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180613160553.11664-1-ville.syrjala@linux.intel.com (cherry picked from commit 929168c5f3df5d9ea0ef426c33e971157d045eab) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | drm/i915: Fix PIPESTAT irq ack on i965/g4xVille Syrjälä2018-06-191-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On i965/g4x IIR is edge triggered. So in order for IIR to notice that there is still a pending interrupt we have to force and edge in ISR. For the ISR/IIR pipe event bits we can do that by temporarily clearing all the PIPESTAT enable bits when we ack the status bits. This will force the ISR pipe event bit low, and it can then go back high when we restore the PIPESTAT enable bits. This avoids the following race: 1. stat = read(PIPESTAT) 2. an enabled PIPESTAT status bit goes high 3. write(PIPESTAT, enable|stat); 4. write(IIR, PIPE_EVENT) The end result is IIR==0 and ISR!=0. This can lead to nasty vblank wait/flip_done timeouts if another interrupt source doesn't trick us into looking at the PIPESTAT status bits despite the IIR PIPE_EVENT bit being low. Before i965 IIR was level triggered so this problem can't actually happen there. And curiously VLV/CHV went back to the level triggered scheme as well. But for simplicity we'll use the same i965/g4x compatible code for all platforms. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106033 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105225 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106030 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 132c27c97cb958f637dc05adc35a61b47779bcd8) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSIVille Syrjälä2018-06-1910-5/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When encountering a connector with the scaling mode property both intel and modesetting ddxs sometimes add tons of DBLSCAN modes to the output's mode list. The idea presumably being that since the output will be going through the panel fitter anyway we can pretend to use any kind of mode. Sadly that means we can't reject user modes with the DBLSCAN flag until we know whether we're going to be using the panel's native mode or the user mode directly. Doing otherwise means X clients using xf86vidmode/xrandr will get a protocol error (and often self terminate as a result) when the kernel refuses to use the requested mode with the DBLSCAN flag. To undo the regression we'll move the DBLSCAN checks into the connector->mode_valid() and encoder->compute_config() hooks. Cc: stable@vger.kernel.org Cc: Vito Caputo <vcaputo@pengaru.com> Reported-by: Vito Caputo <vcaputo@pengaru.com> Fixes: e995ca0b8139 ("drm/i915: Provide a device level .mode_valid() hook") References: https://lkml.org/lkml/2018/5/21/715 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180524125403.23445-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106804 Tested-by: Arkadiusz Miskiewicz <arekm@maven.pl> (cherry picked from commit e4dd27aadd205417a2e9ea9902b698a0252ec3a0) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | drm/i915/execlists: Avoid putting the error pointerChris Wilson2018-06-191-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On allocation error, do not jump to the unwind handler that tries to free the error pointer. Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual timelines") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611153332.14824-1-chris@chris-wilson.co.uk (cherry picked from commit 467d35789e5a4f47428b65ef711b30fdabbb0fd4) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | drm/i915: Apply batch location restrictions before pinningChris Wilson2018-06-191-22/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We special case the position of the batch within the GTT to prevent negative self-relocation deltas from underflowing. However, that restriction is being applied after a trial pin of the batch in its current position. Thus we are not rejecting an invalid location if the batch has been used before, leading to an assertion if we happen to need to rearrange the entire payload. In the worst case, this may cause a GPU hang on gen7 or perhaps missing state. References: https://bugs.freedesktop.org/show_bug.cgi?id=105720 Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180610194325.13467-2-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit 746c8f143afad7aaa66c484485fc39888d437a3f) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | Merge branch 'drm-fixes-4.18' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2018-06-217-27/+65
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes Bunch of amdgpu fixes mostly all going to stable. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180620190021.2775-1-alexander.deucher@amd.com
| * | | drm/amdgpu: Make amdgpu_vram_mgr_bo_invisible_size always accurateMichel Dänzer2018-06-191-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even BOs with AMDGPU_GEM_CREATE_NO_CPU_ACCESS may end up at least partially in CPU visible VRAM, in particular when all VRAM is visible. v2: * Don't take VRAM mgr spinlock, not needed (Christian König) * Make loop logic simpler and clearer. Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | | drm/amdgpu: Refactor amdgpu_vram_mgr_bo_invisible_size helperMichel Dänzer2018-06-193-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Preparation for the following fix, no functional change intended. Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | | drm/amdgpu: Update pin_size values before unpinning BOMichel Dänzer2018-06-191-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least in theory, ttm_bo_validate may move the BO, in which case the pin_size accounting would be inconsistent with when the BO was pinned. Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | | drm/amdgpu:All UVD instances share one idle_work handleJames Zhu2018-06-192-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All UVD instanses have only one dpm control, so it is better to share one idle_work handle. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Tested-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | | drm/amdgpu: Don't default to DC support for Kaveri and olderHarry Wentland2018-06-191-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've had a number of users report failures to detect and light up display with DC with LVDS and VGA. These connector types are not currently supported with DC. I'd like to add support but unfortunately don't have a system with LVDS or VGA available. In order not to cause regressions we should probably fallback to the non-DC driver for ASICs that support VGA and LVDS. These ASICs are: * Bonaire * Kabini * Kaveri * Mullins ASIC support can always be force enabled with amdgpu.dc=1 v2: Keep Hawaii on DC v3: Added Mullins to the list Cc: stable@vger.kernel.org Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | | drm/amdgpu: Use kvmalloc_array for allocating VRAM manager nodes arrayMichel Dänzer2018-06-191-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It can be quite big, and there's no need for it to be physically contiguous. This is less likely to fail under memory pressure (has actually happened while running piglit). Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | | drm/amd/pp: Fix uninitialized variableRajan Vaja2018-06-191-1/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | Initialize variable to 0 before performing logical OR operation. Reviewed-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Rajan Vaja <rajan.vaja@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | Merge tag 'drm-misc-fixes-2018-06-12' of ↵Dave Airlie2018-06-201-2/+5
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Only a small qxl fix that was queued for v4.17. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/08dcbd63-ed18-6232-7bbd-547a3d63b90f@linux.intel.com
| * | drm/qxl: Call qxl_bo_unref outside atomic contextJeremy Cline2018-06-041-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "qxl_bo_unref" may sleep, but calling "qxl_release_map" causes "preempt_disable()" to be called and "preempt_enable()" isn't called until "qxl_release_unmap" is used. Move the call to "qxl_bo_unref" out from in between the two to avoid sleeping from an atomic context. This issue can be demonstrated on a kernel with CONFIG_LOCKDEP=y by creating a VM using QXL, using a desktop environment using Xorg, then moving the cursor on or off a window. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1571128 Fixes: 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary") Cc: stable@vger.kernel.org Signed-off-by: Jeremy Cline <jcline@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180601200532.13619-1-jcline@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* | | Merge tag 'drm-misc-next-fixes-2018-06-15' of ↵Dave Airlie2018-06-201-7/+7
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Single fix for v4.18: - Fix possible race conditions while unplugging DRM device. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/1fd8b7d1-e60a-0105-dfb5-d36f99ea0239@linux.intel.com
| * | | drm: Fix possible race conditions while unplugging DRM deviceOleksandr Andrushchenko2018-05-311-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When unplugging a hotpluggable DRM device we first unregister it with drm_dev_unregister and then set drm_device.unplugged flag which is used to mark device critical sections with drm_dev_enter()/ drm_dev_exit() preventing access to device resources that are not available after the device is gone. But drm_dev_unregister may lead to hotplug uevent(s) fired to user-space on card and/or connector removal, thus making it possible for user-space to try accessing a disconnected device. Fix this by first making sure device is properly marked as disconnected and only then unregister it. Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged") Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reported-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180522141304.18646-1-andr2000@gmail.com
* | | | Merge branch 'linux-4.18' of git://github.com/skeggsb/linux into drm-fixesDave Airlie2018-06-202-6/+9
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | Single nouveau regression fix. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv5VDDKaYKJShyVAGK0MJAHMZOJ02FKQ_aW5DnBCNVgRUw@mail.gmail.com
| * | | drm/nouveau/kms/nv50-: cursors always use core channel vram ctxdmaBen Skeggs2018-06-192-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ctxdmas for cursors from all heads are setup in the core channel, and due to us tracking allocated handles per-window, we were failing with -EEXIST on multiple-head setups trying to allocate duplicate handles. The cursor code is hardcoded to use the core channel vram ctxdma already, so just skip ctxdma allocation for cursor fbs to fix the issue. Fixes: 5bca1621c07 ("drm/nouveau/kms/nv50-: move fb ctxdma tracking into windows") Reported-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | | | Merge tag 'docs-broken-links' of git://linuxtv.org/mchehab/experimentalLinus Torvalds2018-06-162-2/+2
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull documentation fixes from Mauro Carvalho Chehab: "This solves a series of broken links for files under Documentation, and improves a script meant to detect such broken links (see scripts/documentation-file-ref-check). The changes on this series are: - can.rst: fix a footnote reference; - crypto_engine.rst: Fix two parsing warnings; - Fix a lot of broken references to Documentation/*; - improve the scripts/documentation-file-ref-check script, in order to help detecting/fixing broken references, preventing false-positives. After this patch series, only 33 broken references to doc files are detected by scripts/documentation-file-ref-check" * tag 'docs-broken-links' of git://linuxtv.org/mchehab/experimental: (26 commits) fix a series of Documentation/ broken file name references Documentation: rstFlatTable.py: fix a broken reference ABI: sysfs-devices-system-cpu: remove a broken reference devicetree: fix a series of wrong file references devicetree: fix name of pinctrl-bindings.txt devicetree: fix some bindings file names MAINTAINERS: fix location of DT npcm files MAINTAINERS: fix location of some display DT bindings kernel-parameters.txt: fix pointers to sound parameters bindings: nvmem/zii: Fix location of nvmem.txt docs: Fix more broken references scripts/documentation-file-ref-check: check tools/*/Documentation scripts/documentation-file-ref-check: get rid of false-positives scripts/documentation-file-ref-check: hint: dash or underline scripts/documentation-file-ref-check: add a fix logic for DT scripts/documentation-file-ref-check: accept more wildcards at filenames scripts/documentation-file-ref-check: fix help message media: max2175: fix location of driver's companion documentation media: v4l: fix broken video4linux docs locations media: dvb: point to the location of the old README.dvb-usb file ...
| * | | | docs: Fix some broken referencesMauro Carvalho Chehab2018-06-152-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As we move stuff around, some doc references are broken. Fix some of them via this script: ./scripts/documentation-file-ref-check --fix Manually checked if the produced result is valid, removing a few false-positives. Acked-by: Takashi Iwai <tiwai@suse.de> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Acked-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Coly Li <colyli@suse.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Jonathan Corbet <corbet@lwn.net>
* | | | | Merge tag 'fbdev-v4.18' of git://github.com/bzolnier/linuxLinus Torvalds2018-06-167-60/+0
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull fbdev updates from Bartlomiej Zolnierkiewicz: "There is nothing really major here, few small fixes, some cleanups and dead drivers removal: - mark omapfb drivers as orphans in MAINTAINERS file (Tomi Valkeinen) - add missing module license tags to omap/omapfb driver (Arnd Bergmann) - add missing GPIOLIB dependendy to omap2/omapfb driver (Arnd Bergmann) - convert savagefb, aty128fb & radeonfb drivers to use msleep & co. (Jia-Ju Bai) - allow COMPILE_TEST build for viafb driver (media part was reviewed by media subsystem Maintainer) - remove unused MERAM support from sh_mobile_lcdcfb and shmob-drm drivers (drm parts were acked by shmob-drm driver Maintainer) - remove unused auo_k190xfb drivers - misc cleanups (Souptick Joarder, Wolfram Sang, Markus Elfring, Andy Shevchenko, Colin Ian King)" * tag 'fbdev-v4.18' of git://github.com/bzolnier/linux: (26 commits) fb_omap2: add gpiolib dependency video/omap: add module license tags MAINTAINERS: make omapfb orphan video: fbdev: pxafb: match_string() conversion fixup video: fbdev: nvidia: fix spelling mistake: "scaleing" -> "scaling" video: fbdev: fix spelling mistake: "frambuffer" -> "framebuffer" video: fbdev: pxafb: Convert to use match_string() helper video: fbdev: via: allow COMPILE_TEST build video: fbdev: remove unused sh_mobile_meram driver drm: shmobile: remove unused MERAM support video: fbdev: sh_mobile_lcdcfb: remove unused MERAM support video: fbdev: remove unused auo_k190xfb drivers video: omap: Improve a size determination in omapfb_do_probe() video: sm501fb: Improve a size determination in sm501fb_probe() video: fbdev-MMP: Improve a size determination in path_init() video: fbdev-MMP: Delete an error message for a failed memory allocation in two functions video: auo_k190x: Delete an error message for a failed memory allocation in auok190x_common_probe() video: sh_mobile_lcdcfb: Delete an error message for a failed memory allocation in two functions video: sh_mobile_meram: Delete an error message for a failed memory allocation in sh_mobile_meram_probe() video: fbdev: sh_mobile_meram: Drop SUPERH platform dependency ...
| * | | | drm: shmobile: remove unused MERAM supportBartlomiej Zolnierkiewicz2018-05-147-60/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit a521422ea4ae ("ARM: shmobile: mackerel: Remove Legacy C board code") MERAM functionality is unused. Remove it. Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
* | | | | Merge tag 'drm-next-2018-06-15' of git://anongit.freedesktop.org/drm/drmLinus Torvalds2018-06-1543-249/+365
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull amd drm fixes from Dave Airlie: "Just a single set of AMD fixes for stuff in -next for -rc1" * tag 'drm-next-2018-06-15' of git://anongit.freedesktop.org/drm/drm: (47 commits) drm/amd/powerplay: Set higher SCLK&MCLK frequency than dpm7 in OD (v2) drm/amd/powerplay: remove uncessary extra gfxoff control call drm/amdgpu: fix parsing indirect register list v2 drm/amd/include: Update df 3.6 mask and shift definition drm/amd/pp: Fix OD feature enable failed on Vega10 workstation cards drm/amd/display: Fix stale buffer object (bo) use drm/amd/pp: initialize result to before or'ing in data drm/amd/powerplay: fix wrong clock adjust sequence drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail() drm/amd/powerplay: fix missed hwmgr check warning before call gfx_off_control handler drm/amdgpu: fix CG enabling hang with gfxoff enabled drm/amdgpu: fix clear_all and replace handling in the VM (v2) drm/amdgpu: add checking for sos version drm/amdgpu: fix the missed vcn fw version report Revert "drm/amdgpu: Add an ATPX quirk for hybrid laptop" drm/amdgpu/df: fix potential array out-of-bounds read drm/amdgpu: Fix NULL pointer when load kfd driver with PP block is disabled drm/gfx9: Update gc goldensetting for vega20. drm/amd/pp: Allow underclocking when od table is empty in vbios drm/amdgpu/display: check if ppfuncs exists before using it ...
| * \ \ \ \ Merge branch 'drm-next-4.18' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2018-06-1543-255/+372
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next Fixes for 4.18. Highlights: - Fixes for gfxoff on Raven - Remove an ATPX quirk now that the root cause is fixed - Runtime PM fixes - Vega20 register header update - Wattman fixes - Misc bug fixes Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614141428.2909-1-alexander.deucher@amd.com
| | * | | | | drm/amd/powerplay: Set higher SCLK&MCLK frequency than dpm7 in OD (v2)Kenneth Feng2018-06-141-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the issue that SCLK&MCLK can't be set higher than dpm7 when OD is enabled in SMU7. v2: fix warning (Alex) Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Acked-by: Rex Zhu<rezhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | | drm/amd/powerplay: remove uncessary extra gfxoff control callEvan Quan2018-06-131-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gfxoff is already enabled in amdgpu_device_ip_set_powergating_state. So, no need to enable it again in pp_late_init. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | | drm/amdgpu: fix parsing indirect register list v2Evan Quan2018-06-131-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WARN_ON possible buffer overflow and avoid unnecessary dereference. v2: change BUG_ON to WARN_ON Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | | drm/amd/include: Update df 3.6 mask and shift definitionShaoyun Liu2018-06-131-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The register field hsas been changed in df 3.6, update to correct setting Signed-off-by: Shaoyun Liu <Shaoyun.Liu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | | drm/amd/pp: Fix OD feature enable failed on Vega10 workstation cardsRex Zhu2018-06-131-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As hw required, soc clock must large than mclk, So we set max soc clock to OD Max Memory clk. But on workstation, vbios do not support OD feature, the OD max memory clock is equal to 0. In this case, driver can support underclocking. and set od max memory clock to the value in highest memory dpm level. So the od max memory clock should be less than highest soc clock. and driver should not change the soc clock. caused by commit ca57b9b0a156 ("drm/amd/pp: Allow underclocking when od table is empty in vbios") Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | | drm/amd/display: Fix stale buffer object (bo) usePratik Vishwakarma2018-06-131-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes stale buffer object (bo) usage for cursor plane Cursor plane's bo operations are handled in DC code. Currently, atomic_commit() does not handle bo operations for cursor plane, as a result the bo assigned for cursor plane in dm_plane_helper_prepare_fb() is not coherent with the updates to the same made in dc code.This mismatch leads to "bo" corruption and hence crashes during S3 entry. This patch cleans up the code which was added as a hack for 4.9 version only. Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | | drm/amd/pp: initialize result to before or'ing in dataColin Ian King2018-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current use of result is or'ing in values and checking for a non-zero result, however, result is not initialized to zero so it potentially contains garbage to start with. Fix this by initializing it to the first return from the call to vega10_program_didt_config_registers. Detected by cppcheck: "(error) Uninitialized variable: result" Fixes: 9b7b8154cdb8 ("drm/amd/powerplay: added didt support for vega10") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Huang Rui <ray.huang@amd.com> [Fix the subject as Colin's comment] Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | | | drm/amd/powerplay: fix wrong clock adjust sequenceEvan Quan2018-06-131-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The clocks should be adjusted after display configuration changed. Otherwise, the socclk and memclk may be forced on an unnecessary higher level. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | | | drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()Lyude Paul2018-06-131-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So, unfortunately I recently made the discovery that in the upstream kernel, the only reason that amdgpu is not currently suffering from issues with runtime PM putting the GPU into suspend while it's driving displays is due to the fact that on most prime systems, we have sound devices associated with the GPU that hold their own runtime PM ref for the GPU. What this means however, is that in the event that there isn't any kind of sound device active (which can easily be reproduced by building a kernel with sound drivers disabled), the GPU will fall asleep even when there's displays active. This appears to be in part due to the fact that amdgpu has not actually ever relied on it's rpm_idle() function to be the only thing keeping it running, and normally grabs it's own power references whenever there are displays active (as can be seen with the original pre-DC codepath in amdgpu_display_crtc_set_config() in amdgpu_display.c). This means it's very likely that this bug was introduced during the switch over the DC. So to fix this, we start grabbing runtime PM references every time we enable a previously disabled CRTC in atomic_commit_tail(). This appears to be the correct solution, as it matches up with what i915 does in i915/intel_runtime_pm.c. The one sideaffect of this is that we ignore the variable that the pre-DC code used to use for tracking when it needed runtime PM refs, adev->have_disp_power_ref. This is mainly because there's no way for a driver to tell whether or not all of it's CRTCs are enabled or disabled when we've begun committing an atomic state, as there may be CRTC commits happening in parallel that aren't contained within the atomic state being committed. So, it's safer to just get/put a reference for each CRTC being enabled or disabled in the new atomic state. Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Christian König <christian.koenig@amd.com>. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | | | drm/amd/powerplay: fix missed hwmgr check warning before call ↵Huang Rui2018-06-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gfx_off_control handler Patch 9667849bbb8d: "drm/amd/powerplay: add control gfxoff enabling in late init" from Mar 13, 2018, leads to the following static checker warning: drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c:194 pp_late_init() error: we previously assumed 'hwmgr' could be null (see line 185) drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c This patch fixes the warning to add hwmgr checking. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>