<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-obmc-linux/drivers/gpu/drm/amd, branch v5.0.1</title>
<subtitle>Talos™ II Linux sources for OpenBMC</subtitle>
<id>https://git.raptorcs.com/git/talos-obmc-linux/atom?h=v5.0.1</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-obmc-linux/atom?h=v5.0.1'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/'/>
<updated>2019-02-27T18:55:09+00:00</updated>
<entry>
<title>drm/amd/display: Use vrr friendly pageflip throttling in DC.</title>
<updated>2019-02-27T18:55:09+00:00</updated>
<author>
<name>Mario Kleiner</name>
<email>mario.kleiner.de@gmail.com</email>
</author>
<published>2019-01-30T05:04:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=d63716658ac16c515d1223a9fbf5edbf76b1b333'/>
<id>urn:sha1:d63716658ac16c515d1223a9fbf5edbf76b1b333</id>
<content type='text'>
In VRR mode, keep track of the vblank count of the last
completed pageflip in amdgpu_crtc-&gt;last_flip_vblank, as
recorded in the pageflip completion handler after each
completed flip.

Use that count to prevent mmio programming a new pageflip
within the same vblank in which the last pageflip completed,
iow. to throttle pageflips to at most one flip per video
frame, while at the same time allowing to request a flip
not only before start of vblank, but also anywhere within
vblank.

The old logic did the same, and made sense for regular fixed
refresh rate flipping, but in vrr mode it prevents requesting
a flip anywhere inside the possibly huge vblank, thereby
reducing framerate in vrr mode instead of improving it, by
delaying a slightly delayed flip requests up to a maximum
vblank duration + 1 scanout duration. This would limit VRR
usefulness to only help applications with a very high GPU
demand, which can submit the flip request before start of
vblank, but then have to wait long for fences to complete.

With this method a flip can be both requested and - after
fences have completed - executed, ie. it doesn't matter if
the request (amdgpu_dm_do_flip()) gets delayed until deep
into the extended vblank due to cpu execution delays. This
also allows clients which want to regulate framerate within
the vrr range a much more fine-grained control of flip timing,
a feature that might be useful for video playback, and is
very useful for neuroscience/vision research applications.

In regular non-VRR mode, retain the old flip submission
behavior. This to keep flip scheduling for fullscreen X11/GLX
OpenGL clients intact, if they use the GLX_OML_sync_control
extensions glXSwapBufferMscOML(, ..., target_msc,...) function
with a specific target_msc target vblank count.

glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will
not flip at the proper target_msc for a non-zero target_msc
if VRR mode is active with this patch. They'd often flip one
frame too early. However, this limitation should not matter
much in VRR mode, as scheduling based on vblank counts is
pretty futile/unusable under variable refresh duration
anyway, so no real extra harm is done.

Signed-off-by: Mario Kleiner &lt;mario.kleiner.de@gmail.com&gt;
Cc: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Cc: Harry Wentland &lt;harry.wentland@amd.com&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: Michel Dänzer &lt;michel@daenzer.net&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: disable bulk moves for now</title>
<updated>2019-02-20T22:13:27+00:00</updated>
<author>
<name>Christian König</name>
<email>ckoenig.leichtzumerken@gmail.com</email>
</author>
<published>2019-02-20T14:16:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=a213c2c7e235cfc0e0a161a558f7fdf2fb3a624a'/>
<id>urn:sha1:a213c2c7e235cfc0e0a161a558f7fdf2fb3a624a</id>
<content type='text'>
The changes to fix those are two invasive for backporting.

Just disable the feature in 4.20 and 5.0.

Acked-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;    [4.20+]
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: set clocks to 0 on suspend on dce80</title>
<updated>2019-02-20T21:58:06+00:00</updated>
<author>
<name>Bhawanpreet Lakha</name>
<email>Bhawanpreet.Lakha@amd.com</email>
</author>
<published>2019-02-05T19:03:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=4ece61a22be5ab5d49cc5fc20a19a0afa24a019d'/>
<id>urn:sha1:4ece61a22be5ab5d49cc5fc20a19a0afa24a019d</id>
<content type='text'>
[Why]
When a dce80 asic was suspended, the clocks were not set to 0.
Upon resume, the new clock was compared to the existing clock,
they were found to be the same, and so the clock was not set.
This resulted in a blackscreen.

[How]
In atomic commit, check to see if there are any active pipes.
If no, set clocks to 0

Signed-off-by: Bhawanpreet Lakha &lt;Bhawanpreet.Lakha@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>drm/amd/display: fix optimize_bandwidth func pointer for dce80</title>
<updated>2019-02-20T21:57:47+00:00</updated>
<author>
<name>Bhawanpreet Lakha</name>
<email>Bhawanpreet.Lakha@amd.com</email>
</author>
<published>2019-02-05T18:55:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=9f7ddbea2bb826a2147309f735726a8b09950944'/>
<id>urn:sha1:9f7ddbea2bb826a2147309f735726a8b09950944</id>
<content type='text'>
[Why]
optimize_bandwidth was using dce100_prepare_bandwidth this is incorrect

[How]
change it to dce100_optimize_bandwidth

Signed-off-by: Bhawanpreet Lakha &lt;Bhawanpreet.Lakha@amd.com&gt;
Reviewed-by: Charlene Liu &lt;Charlene.Liu@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>drm/amd/display: Fix negative cursor pos programming</title>
<updated>2019-02-20T21:56:28+00:00</updated>
<author>
<name>Nicholas Kazlauskas</name>
<email>nicholas.kazlauskas@amd.com</email>
</author>
<published>2019-02-01T14:36:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=0921c41e19028314830b33daa681e46b46477c5e'/>
<id>urn:sha1:0921c41e19028314830b33daa681e46b46477c5e</id>
<content type='text'>
[Why]
If the cursor pos passed from DM is less than the plane_state-&gt;dst_rect
top left corner then the unsigned cursor pos wraps around to a large
positive number since cursor pos is a u32.

There was an attempt to guard against this in hubp1_cursor_set_position
by checking the src_x_offset and src_y_offset and offseting the
cursor hotspot within hubp1_cursor_set_position.

However, the cursor position itself is still being programmed
incorrectly as a large value.

This manifests itself visually as the cursor disappearing or containing
strange artifacts near the middle of the screen on raven.

[How]
Don't subtract the destination rect top left corner from the pos but
add it to the hotspot instead. This happens before the pos gets
passed into hubp1_cursor_set_position.

This achieves the same result but avoids the subtraction wrap around.
With this fix the original cursor programming logic can be used again.

Signed-off-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Reviewed-by: Charlene Liu &lt;Charlene.Liu@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Acked-by: Murton Liu &lt;Murton.Liu@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Raise dispclk value for dce11</title>
<updated>2019-02-19T20:33:47+00:00</updated>
<author>
<name>Roman Li</name>
<email>Roman.Li@amd.com</email>
</author>
<published>2019-01-28T15:59:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=8852ae9a82498207c15262b6294d14aea1796966'/>
<id>urn:sha1:8852ae9a82498207c15262b6294d14aea1796966</id>
<content type='text'>
[Why]
The visual corruption due to low display clock value.
Observed on Carrizo 4K@60Hz.

[How]
There was earlier patch for dce_update_clocks:
Adding +15% workaround also to to dce11_update_clocks

Signed-off-by: Roman Li &lt;Roman.Li@amd.com&gt;
Reviewed-by: Nicholas Kazlauskas &lt;Nicholas.Kazlauskas@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Fix MST reboot/poweroff sequence</title>
<updated>2019-02-19T20:33:47+00:00</updated>
<author>
<name>Leo (Hanghong) Ma</name>
<email>hanghong.ma@amd.com</email>
</author>
<published>2019-01-24T20:07:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=d2f0b53bda3193874f3905bc839888f895d1c0cf'/>
<id>urn:sha1:d2f0b53bda3193874f3905bc839888f895d1c0cf</id>
<content type='text'>
[Why]

drm_dp_mst_topology_mgr_suspend() is added into the new reboot
sequence, which disables the UP request at the beginning.
Therefore sideband messages are blocked.

[How]

Finish MST sideband message transaction before UP request is
suppressed.

Signed-off-by: Leo (Hanghong) Ma &lt;hanghong.ma@amd.com&gt;
Reviewed-by: Roman Li &lt;Roman.Li@amd.com&gt;
Acked-by: Leo Li &lt;sunpeng.li@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>drm/amdgpu: Update sdma golden setting for vega20</title>
<updated>2019-02-19T20:33:47+00:00</updated>
<author>
<name>shaoyunl</name>
<email>shaoyun.liu@amd.com</email>
</author>
<published>2019-02-15T16:05:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=9db97d8aa8f8a518c421196a504dbfc942ef8d40'/>
<id>urn:sha1:9db97d8aa8f8a518c421196a504dbfc942ef8d40</id>
<content type='text'>
According to hardware engineer, WRITE_BURST_LENGTH [9:8] in register
SDMA0_CHICKEN_BITS need to change to 3 for better performance

Signed-off-by: shaoyunl &lt;shaoyun.liu@amd.com&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime</title>
<updated>2019-02-19T20:33:41+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2019-02-18T22:11:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=d33158530660bc89be3cc870a2152e4e9a76cac7'/>
<id>urn:sha1:d33158530660bc89be3cc870a2152e4e9a76cac7</id>
<content type='text'>
Based on a similar patch from Rafael for radeon.

When using ATPX to control dGPU power, the state is not retained
across suspend and resume cycles by default.  This can probably
be loosened for Hybrid Graphics (_PR3) laptops where I think the
state is properly retained.

Fixes: c62ec4610c40 ("PM / core: Fix direct_complete handling for devices with no callbacks")
Cc: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>drm/amdgpu/psp11: TA firmware is optional (v3)</title>
<updated>2019-02-13T14:44:05+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2019-02-12T14:54:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=1d69511e49b0107c0a60ff5ef488f5a2512a50ae'/>
<id>urn:sha1:1d69511e49b0107c0a60ff5ef488f5a2512a50ae</id>
<content type='text'>
Don't warn or fail if it's missing.

v2: handle xgmi case more gracefully.
v3: handle older kernels properly

Reviewed-by: Hawking Zhang &lt;Hawking.Zhang@amd.com&gt;
Tested-by: James Zhu &lt;James.Zhu@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
</feed>
