| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Single nouveau regression fix.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv5VDDKaYKJShyVAGK0MJAHMZOJ02FKQ_aW5DnBCNVgRUw@mail.gmail.com
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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
|
|
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
...
|
|
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
...
|
|
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>
|
|
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
...
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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
|
|
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>
|
|
After defer the execution of clockgating enabling, at that time, gfx already
enter into "off" state. Howerver, clockgating enabling will use MMIO to access
the gfx registers, then get the gfx hung.
So here we should move the gfx powergating and gfxoff enabling behavior at the
end of initialization behind clockgating.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Cc: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
v2: assign bo_va as well
We need to put the lose ends on the invalid list because it is possible
that we need to split up huge pages for them.
Cc: stable@vger.kernel.org
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v2)
Reviewed-by: David Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The sos ucode version will be changed to align with the value of
mmMP0_SMN_C2PMSG_58. Then we add a checking for this. Meanwhile, we have to be
compatibility backwards. So it adds serveral recent legacy versions as the white
list for the version checking.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
It missed vcn.fw_version setting when init vcn microcode, and it will be used to
report vcn ucode version via amdgpu_firmware_info sysfs interface.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
