<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-op-linux/drivers/gpu/drm/amd/display/dc/dcn21/Makefile, branch master</title>
<subtitle>Talos™ II Linux sources for OpenPOWER</subtitle>
<id>https://git.raptorcs.com/git/talos-op-linux/atom?h=master</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-op-linux/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/'/>
<updated>2019-12-18T21:09:05+00:00</updated>
<entry>
<title>amdgpu: Enable initial DCN support on POWER</title>
<updated>2019-12-18T21:09:05+00:00</updated>
<author>
<name>Timothy Pearson</name>
<email>tpearson@raptorengineering.com</email>
</author>
<published>2019-12-07T22:47:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=16a9dea110a67d62401ffeac4828cabdedec7548'/>
<id>urn:sha1:16a9dea110a67d62401ffeac4828cabdedec7548</id>
<content type='text'>
DCN requires floating point support to operate.  Add the appropriate
x86/ppc64 guards and FPU / AltiVec / VSX context switches to DCN.

Note that the current DC20 code doesn't contain all required FPU
wrappers on x86 or POWER, so this patch is insufficient to fully
enable DC20 on POWER.

v2: s/X86_64/X86/g to retain previous behavior.

Signed-off-by: Timothy Pearson &lt;tpearson@raptorengineering.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'drm-next-5.6-2019-12-11' of git://people.freedesktop.org/~agd5f/linux into drm-next</title>
<updated>2019-12-17T17:47:46+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2019-12-17T17:47:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=be452c4e8d1434a0095a9baa6523bb9772258d59'/>
<id>urn:sha1:be452c4e8d1434a0095a9baa6523bb9772258d59</id>
<content type='text'>
drm-next-5.6-2019-12-11:

amdgpu:
- Add MST atomic routines
- Add support for DMCUB (new helper microengine for displays)
- Add OEM i2c support in DC
- Use vstartup for vblank events on DCN
- Simplify Kconfig for DC
- Renoir fixes for DC
- Clean up function pointers in DC
- Initial support for HDCP 2.x
- Misc code cleanups
- GFX10 fixes
- Rework JPEG engine handling for VCN
- Add clock and power gating support for JPEG
- BACO support for Arcturus
- Cleanup PSP ring handling
- Add framework for using BACO with runtime pm to save power
- Move core pci state handling out of the driver for pm ops
- Allow guest power control in 1 VF case with SR-IOV
- SR-IOV fixes
- RAS fixes
- Support for power metrics on renoir
- Golden settings updates for gfx10
- Enable gfxoff on supported navi10 skus
- Update MAINTAINERS

amdkfd:
- Clean up generational gfx code
- Fixes for gfx10
- DIQ fixes
- Share more code with amdgpu

radeon:
- PPC DMA fix
- Register checker fixes for r1xx/r2xx
- Misc cleanups

From: Alex Deucher &lt;alexdeucher@gmail.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20191211223020.7510-1-alexander.deucher@amd.com
</content>
</entry>
<entry>
<title>drm/amdgpu: fix license on Kconfig and Makefiles</title>
<updated>2019-12-11T20:22:08+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2019-12-11T15:09:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=ad808910be68dcf8da5d837d4511d00ad5d3678a'/>
<id>urn:sha1:ad808910be68dcf8da5d837d4511d00ad5d3678a</id>
<content type='text'>
amdgpu is MIT licensed.

Fixes: ec8f24b7faaf3d ("treewide: Add SPDX license identifier - Makefile/Kconfig")
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: fix license on Kconfig and Makefiles</title>
<updated>2019-12-11T19:29:38+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2019-12-11T15:09:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=bd95c1445274c5e126ffd8998fbba9f3732a579e'/>
<id>urn:sha1:bd95c1445274c5e126ffd8998fbba9f3732a579e</id>
<content type='text'>
amdgpu is MIT licensed.

Fixes: ec8f24b7faaf3d ("treewide: Add SPDX license identifier - Makefile/Kconfig")
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: cleanup of function pointer tables</title>
<updated>2019-11-19T15:12:53+00:00</updated>
<author>
<name>Anthony Koo</name>
<email>Anthony.Koo@amd.com</email>
</author>
<published>2019-10-29T19:05:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=78c7738211e027f122ada3f59c2c5e8a83ee3c59'/>
<id>urn:sha1:78c7738211e027f122ada3f59c2c5e8a83ee3c59</id>
<content type='text'>
[Why]
It is becoming increasingly hard to figure out which
function is called on the different DCN versions

[How]
1. Make function pointer table init in its own init.c file
2. Remove other scenarios in hwseq.c file that need to
include headers of other DCN versions. (If needed,
it should have been done via the function pointers)

Signed-off-by: Anthony Koo &lt;Anthony.Koo@amd.com&gt;
Reviewed-by: Aric Cyr &lt;Aric.Cyr@amd.com&gt;
Acked-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>Merge v5.4-rc7 into drm-next</title>
<updated>2019-11-13T19:53:10+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2019-11-13T19:53:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=77e0723bd27f830d0903225372aa778fe2975648'/>
<id>urn:sha1:77e0723bd27f830d0903225372aa778fe2975648</id>
<content type='text'>
We have the i915 security fixes to backmerge, but first
let's clear the decks for other drivers to avoid a bigger
mess.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: enable -msse2 for GCC 7.1+ users</title>
<updated>2019-10-30T15:56:20+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2019-10-16T23:02:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=e8a170ff9a3576730e43c0dbdd27b7cd3dc56848'/>
<id>urn:sha1:e8a170ff9a3576730e43c0dbdd27b7cd3dc56848</id>
<content type='text'>
A final attempt at enabling sse2 for GCC users.

Orininally attempted in:
commit 10117450735c ("drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines")

Reverted due to "reported instability" in:
commit 193392ed9f69 ("Revert "drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines"")

Re-added just for Clang in:
commit 0f0727d971f6 ("drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines")

The original report didn't have enough information to know if the GPF
was due to misalignment, but I suspect that it was. (The missing
information was the disassembly of the function at the bottom of the
trace, to see if the instruction pointer pointed to an instruction with
16B alignment memory operand requirements.  The stack trace does show
the stack was only 8B but not 16B aligned though, which makes this a
strong possibility).

Now that the stack misalignment issue has been fixed for users of GCC
7.1+, reattempt adding -msse2. This matches Clang.

It will likely never be safe to enable this for pre-GCC 7.1 AND use a
16B aligned stack in these translation units.

This is only a functional change for GCC 7.1+ users, and should be boot
tested.

Link: https://bugs.freedesktop.org/show_bug.cgi?id=109487
Signed-off-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: fix stack alignment ABI mismatch for GCC 7.1+</title>
<updated>2019-10-30T15:56:20+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2019-10-16T23:02:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=00db297106e81770e7c4319014a67896053b5a22'/>
<id>urn:sha1:00db297106e81770e7c4319014a67896053b5a22</id>
<content type='text'>
GCC earlier than 7.1 errors when compiling code that makes use of
`double`s and sets a stack alignment outside of the range of [2^4-2^12]:

$ cat foo.c
double foo(double x, double y) {
  return x + y;
}
$ gcc-4.9 -mpreferred-stack-boundary=3 foo.c
error: -mpreferred-stack-boundary=3 is not between 4 and 12

This is likely why the AMDGPU driver was ever compiled with a different
stack alignment (and thus different ABI) than the rest of the x86
kernel. The kernel uses 8B stack alignment, while the driver was using
16B stack alignment in a few places.

Since GCC 7.1+ doesn't error, fix the ABI mismatch for users of newer
versions of GCC.

There was discussion about whether to mark the driver broken or not for
users of GCC earlier than 7.1, but since the driver currently is
working, don't explicitly break the driver for them here.

Relying on differing stack alignment is unspecified behavior, and
brittle, and may break in the future.

This patch is no functional change for GCC users earlier than 7.1. It's
been compile tested on GCC 4.9 and 8.3 to check the correct flags. It
should be boot tested when built with GCC 7.1+.

-mincoming-stack-boundary= or -mstackrealign may help keep this code
building for pre-GCC 7.1 users.

The version check for GCC is broken into two conditionals, both because
cc-ifversion is currently GCC specific, and it simplifies a subsequent
patch.

Signed-off-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: fix stack alignment ABI mismatch for Clang</title>
<updated>2019-10-30T15:56:20+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2019-10-16T23:02:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=c868868f6b6a5272350781f9a19b3a5ba1c00b02'/>
<id>urn:sha1:c868868f6b6a5272350781f9a19b3a5ba1c00b02</id>
<content type='text'>
The x86 kernel is compiled with an 8B stack alignment via
`-mpreferred-stack-boundary=3` for GCC since 3.6-rc1 via
commit d9b0cde91c60 ("x86-64, gcc: Use -mpreferred-stack-boundary=3 if supported")
or `-mstack-alignment=8` for Clang. Parts of the AMDGPU driver are
compiled with 16B stack alignment.

Generally, the stack alignment is part of the ABI. Linking together two
different translation units with differing stack alignment is dangerous,
particularly when the translation unit with the smaller stack alignment
makes calls into the translation unit with the larger stack alignment.
While 8B aligned stacks are sometimes also 16B aligned, they are not
always.

Multiple users have reported General Protection Faults (GPF) when using
the AMDGPU driver compiled with Clang. Clang is placing objects in stack
slots assuming the stack is 16B aligned, and selecting instructions that
require 16B aligned memory operands.

At runtime, syscall handlers with 8B aligned stack call into code that
assumes 16B stack alignment.  When the stack is a multiple of 8B but not
16B, these instructions result in a GPF.

Remove the code that added compatibility between the differing compiler
flags, as it will result in runtime GPFs when built with Clang. Cleanups
for GCC will be sent in later patches in the series.

Link: https://github.com/ClangBuiltLinux/linux/issues/735
Debugged-by: Yuxuan Shui &lt;yshuiv7@gmail.com&gt;
Reported-by: Shirish S &lt;shirish.s@amd.com&gt;
Reported-by: Yuxuan Shui &lt;yshuiv7@gmail.com&gt;
Suggested-by: Andrew Cooper &lt;andrew.cooper3@citrix.com&gt;
Signed-off-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'drm-next-5.5-2019-10-25' of git://people.freedesktop.org/~agd5f/linux into drm-next</title>
<updated>2019-10-29T19:46:09+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2019-10-29T19:46:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=60845e34f0c5c19a9e86af477b429993952f585b'/>
<id>urn:sha1:60845e34f0c5c19a9e86af477b429993952f585b</id>
<content type='text'>
drm-next-5.5-2019-10-25:

amdgpu:
- BACO support for CI and VI asics
- Quick memory training support for navi
- MSI-X support
- RAS fixes
- Display AVI infoframe fixes
- Display ref clock fixes for renoir
- Fix number of audio endpoints in renoir
- Fix for discovery tables
- Powerplay fixes
- Documentation fixes
- Misc cleanups

radeon:
- revert a PPC fix which broke x86

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
From: Alex Deucher &lt;alexdeucher@gmail.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20191025221020.203546-1-alexander.deucher@amd.com
</content>
</entry>
</feed>
