[PATCH 0/6] amdgpu build fixes

[Arnd Bergmann]

Here are a couple of build fixes from my backlog in the randconfig
tree. It would be good to get them all into linux-5.4.

Arnd

Arnd Bergmann (6):
drm/amdgpu: make pmu support optional, again
drm/amdgpu: hide another #warning
drm/amdgpu: display_mode_vba_21: remove uint typedef
drm/amd/display: fix dcn21 Makefile for clang
[RESEND] drm/amd/display: hide an unused variable
[RESEND] drm/amdgpu: work around llvm bug #42576

drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/soc15.c | 2 --
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 12 +++++++++++-
.../amd/display/dc/dml/dcn21/display_mode_vba_21.c | 13 +++++--------
6 files changed, 20 insertions(+), 12 deletions(-)

--
2.20.0

[Arnd Bergmann]

When CONFIG_PERF_EVENTS is disabled, we cannot compile the pmu
portion of the amdgpu driver:

drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:48:38: error: no member named 'hw' in 'struct perf_event'
struct hw_perf_event *hwc = &event->hw;
~~~~~ ^
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:51:13: error: no member named 'attr' in 'struct perf_event'
if (event->attr.type != event->pmu->type)
~~~~~ ^
...

The same bug was already fixed by commit d155bef0636e ("amdgpu: make pmu
support optional") but broken again by what looks like an incorrectly
rebased patch.

Fixes: 64f55e629237 ("drm/amdgpu: Add RAS EEPROM table.")
Signed-off-by: Arnd Bergmann <ar...@arndb.de>
---
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile b/drivers/gpu/drm/amd/amdgpu/Makefile
index 42e2c1f57152..00962a659009 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -54,7 +54,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o amdgpu_atomfirmware.o \
amdgpu_vf_error.o amdgpu_sched.o amdgpu_debugfs.o amdgpu_ids.o \
amdgpu_gmc.o amdgpu_xgmi.o amdgpu_csa.o amdgpu_ras.o amdgpu_vm_cpu.o \
- amdgpu_vm_sdma.o amdgpu_pmu.o amdgpu_discovery.o amdgpu_ras_eeprom.o smu_v11_0_i2c.o
+ amdgpu_vm_sdma.o amdgpu_discovery.o amdgpu_ras_eeprom.o smu_v11_0_i2c.o

amdgpu-$(CONFIG_PERF_EVENTS) += amdgpu_pmu.o

--
2.20.0

[Arnd Bergmann]

An earlier patch of mine disabled some #warning statements
that get in the way of build testing, but then another
instance was added around the same time.

Remove that as well.

Fixes: b5203d16aef4 ("drm/amd/amdgpu: hide #warning for missing DC config")
Fixes: e1c14c43395c ("drm/amdgpu: Enable DC on Renoir")

Signed-off-by: Arnd Bergmann <ar...@arndb.de>
---

drivers/gpu/drm/amd/amdgpu/soc15.c | 2 --
1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c b/drivers/gpu/drm/amd/amdgpu/soc15.c
index f70658a536a9..a337d980b434 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -771,8 +771,6 @@ int soc15_set_ip_blocks(struct amdgpu_device *adev)
#if defined(CONFIG_DRM_AMD_DC)
else if (amdgpu_device_has_dc_support(adev))
amdgpu_device_ip_block_add(adev, &dm_ip_block);
-#else
-# warning "Enable CONFIG_DRM_AMD_DC for display support on SOC15."
#endif
amdgpu_device_ip_block_add(adev, &vcn_v2_0_ip_block);
break;
--
2.20.0

[Arnd Bergmann]

The type definition for 'uint' clashes with the generic kernel
headers:

drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:43:22: error: redefinition of typedef 'uint' is a C11 feature [-Werror,-Wtypedef-redefinition]
include/linux/types.h:92:23: note: previous definition is here

Just remove this type and use plain 'unsigned int' consistently,
as it is already use almost everywhere in this file.

Fixes: b04641a3f4c5 ("drm/amd/display: Add Renoir DML")

Signed-off-by: Arnd Bergmann <ar...@arndb.de>
---

.../amd/display/dc/dml/dcn21/display_mode_vba_21.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
index 46cda85d3d63..998970e2f84c 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
@@ -39,9 +39,6 @@
* ways. Unless there is something clearly wrong with it the code should
* remain as-is as it provides us with a guarantee from HW that it is correct.
*/
-
-typedef unsigned int uint;
-
typedef struct {
amdgpu_dc_double DPPCLK;
amdgpu_dc_double DISPCLK;
@@ -4774,7 +4771,7 @@ void dml21_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_l
mode_lib->vba.MaximumReadBandwidthWithoutPrefetch = 0.0;
mode_lib->vba.MaximumReadBandwidthWithPrefetch = 0.0;
for (k = 0; k <= mode_lib->vba.NumberOfActivePlanes - 1; k++) {
- uint m;
+ unsigned int m;

locals->cursor_bw[k] = 0;
locals->cursor_bw_pre[k] = 0;
@@ -5285,7 +5282,7 @@ static void CalculateWatermarksAndDRAMSpeedChangeSupport(
amdgpu_dc_double SecondMinActiveDRAMClockChangeMarginOneDisplayInVBLank;
amdgpu_dc_double FullDETBufferingTimeYStutterCriticalPlane = 0;
amdgpu_dc_double TimeToFinishSwathTransferStutterCriticalPlane = 0;
- uint k, j;
+ unsigned int k, j;

mode_lib->vba.TotalActiveDPP = 0;
mode_lib->vba.TotalDCCActiveDPP = 0;
@@ -5507,7 +5504,7 @@ static void CalculateDCFCLKDeepSleep(
amdgpu_dc_double DPPCLK[],
amdgpu_dc_double *DCFCLKDeepSleep)
{
- uint k;
+ unsigned int k;
amdgpu_dc_double DisplayPipeLineDeliveryTimeLuma;
amdgpu_dc_double DisplayPipeLineDeliveryTimeChroma;
//amdgpu_dc_double DCFCLKDeepSleepPerPlane[DC__NUM_DPP__MAX];
@@ -5727,7 +5724,7 @@ static void CalculatePixelDeliveryTimes(
amdgpu_dc_double DisplayPipeRequestDeliveryTimeChromaPrefetch[])
{
amdgpu_dc_double req_per_swath_ub;
- uint k;
+ unsigned int k;

for (k = 0; k < NumberOfActivePlanes; ++k) {
if (VRatio[k] <= 1) {
@@ -5869,7 +5866,7 @@ static void CalculateMetaAndPTETimes(
unsigned int dpte_groups_per_row_chroma_ub;
unsigned int num_group_per_lower_vm_stage;
unsigned int num_req_per_lower_vm_stage;
- uint k;
+ unsigned int k;

for (k = 0; k < NumberOfActivePlanes; ++k) {
if (GPUVMEnable == true) {
--
2.20.0

[Arnd Bergmann]

Just like all the other variants, this one passes invalid
compile-time options with clang after the new code got
merged:

clang: error: unknown argument: '-mpreferred-stack-boundary=4'
scripts/Makefile.build:265: recipe for target 'drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.o' failed

Use the same variant that we have for dcn20 to fix compilation.

Fixes: eced51f9babb ("drm/amd/display: Add hubp block for Renoir (v2)")

Signed-off-by: Arnd Bergmann <ar...@arndb.de>
---

drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
index 8cd9de8b1a7a..ef673bffc241 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
@@ -3,7 +3,17 @@

DCN21 = dcn21_hubp.o dcn21_hubbub.o dcn21_resource.o

-CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o := -mhard-float -msse -mpreferred-stack-boundary=4
+ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
+ cc_stack_align := -mpreferred-stack-boundary=4
+else ifneq ($(call cc-option, -mstack-alignment=16),)
+ cc_stack_align := -mstack-alignment=16
+endif
+
+CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o := -mhard-float -msse $(cc_stack_align)
+
+ifdef CONFIG_CC_IS_CLANG
+CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o += -msse2
+endif

AMD_DAL_DCN21 = $(addprefix $(AMDDALPATH)/dc/dcn21/,$(DCN21))

--
2.20.0

[Arnd Bergmann]

Without CONFIG_DEBUG_FS, we get a warning for an unused
variable:

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6020:33: error: unused variable 'source' [-Werror,-Wunused-variable]

Hide the variable in an #ifdef like its only users.

Fixes: 14b2584636c6 ("drm/amd/display: add functionality to grab DPRX CRC entries.")
Reviewed-by: Harry Wentland <harry.w...@amd.com>

Signed-off-by: Arnd Bergmann <ar...@arndb.de>
---

This was a bugfix for a commit that landed in v5.4-rc1. The
fix was applied by Alex Deucher on Sep 19, but is still not
seen in linux-next.
Resending to make sure this makes it into v5.4-final, but
please ignore if this is already coming.
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8cab6da512a0..7516a6436822 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6019,7 +6019,9 @@ static void amdgpu_dm_enable_crtc_interrupts(struct drm_device *dev,
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
int i;
+#ifdef CONFIG_DEBUG_FS
enum amdgpu_dm_pipe_crc_source source;
+#endif

for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
--
2.20.0

[Arnd Bergmann]

Code in the amdgpu driver triggers a bug when using clang to build
an arm64 kernel:

/tmp/sdma_v4_0-f95fd3.s: Assembler messages:
/tmp/sdma_v4_0-f95fd3.s:44: Error: selected processor does not support `bfc w0,#1,#5'

I expect this to be fixed in llvm soon, but we can also work around
it by inserting a barrier() that prevents the optimization.

Link: https://bugs.llvm.org/show_bug.cgi?id=42576

Signed-off-by: Arnd Bergmann <ar...@arndb.de>
---

Apparently this bug is still present in both the released clang-9
and the current development version of clang-10.
I was hoping we would not need a workaround in clang-9+, but
it seems that we do.
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index 78452cf0115d..39459cd8ddef 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -961,6 +961,7 @@ static uint32_t sdma_v4_0_rb_cntl(struct amdgpu_ring *ring, uint32_t rb_cntl)
/* Set ring buffer size in dwords */
uint32_t rb_bufsz = order_base_2(ring->ring_size / 4);

+ barrier(); /* work around https://bugs.llvm.org/show_bug.cgi?id=42576 */
rb_cntl = REG_SET_FIELD(rb_cntl, SDMA0_GFX_RB_CNTL, RB_SIZE, rb_bufsz);
#ifdef __BIG_ENDIAN
rb_cntl = REG_SET_FIELD(rb_cntl, SDMA0_GFX_RB_CNTL, RB_SWAP_ENABLE, 1);
--
2.20.0

[Alex Deucher]

On Wed, Oct 2, 2019 at 8:03 AM Arnd Bergmann <ar...@arndb.de> wrote:
>
> Just like all the other variants, this one passes invalid
> compile-time options with clang after the new code got
> merged:
>
> clang: error: unknown argument: '-mpreferred-stack-boundary=4'
> scripts/Makefile.build:265: recipe for target 'drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.o' failed
>
> Use the same variant that we have for dcn20 to fix compilation.
>
> Fixes: eced51f9babb ("drm/amd/display: Add hubp block for Renoir (v2)")
> Signed-off-by: Arnd Bergmann <ar...@arndb.de>

I'm getting an error with gcc with this patch:
CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.o
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In
function ‘calculate_wm_set_for_vlevel’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:964:22:
error: SSE register return with SSE disabled
wm_set->urgent_ns = get_wm_urgent(dml, pipes, pipe_cnt) * 1000;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[4]: *** [scripts/Makefile.build:273:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.o] Error
1
make[3]: *** [scripts/Makefile.build:490: drivers/gpu/drm/amd/amdgpu] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [scripts/Makefile.build:490: drivers/gpu/drm] Error 2
make[1]: *** [scripts/Makefile.build:490: drivers/gpu] Error 2
make: *** [Makefile:1080: drivers] Error 2

Alex

> ---
> drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
> index 8cd9de8b1a7a..ef673bffc241 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
> @@ -3,7 +3,17 @@
>
> DCN21 = dcn21_hubp.o dcn21_hubbub.o dcn21_resource.o
>
> -CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o := -mhard-float -msse -mpreferred-stack-boundary=4
> +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
> + cc_stack_align := -mpreferred-stack-boundary=4
> +else ifneq ($(call cc-option, -mstack-alignment=16),)
> + cc_stack_align := -mstack-alignment=16
> +endif
> +
> +CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o := -mhard-float -msse $(cc_stack_align)
> +
> +ifdef CONFIG_CC_IS_CLANG
> +CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o += -msse2
> +endif
>
> AMD_DAL_DCN21 = $(addprefix $(AMDDALPATH)/dc/dcn21/,$(DCN21))
>
> --
> 2.20.0
>

> _______________________________________________
> dri-devel mailing list
> dri-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Arnd Bergmann]

On Wed, Oct 2, 2019 at 4:17 PM Alex Deucher <alexd...@gmail.com> wrote:
>
> I'm getting an error with gcc with this patch:
> CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.o
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In
> function ‘calculate_wm_set_for_vlevel’:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:964:22:
> error: SSE register return with SSE disabled

I checked again with gcc-8, but do not see that error message.

> > -CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o := -mhard-float -msse -mpreferred-stack-boundary=4

> > +CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o := -mhard-float -msse $(cc_stack_align)

Nothing should really change with regards to the -msse flag here, only
the stack alignment flag changed. Maybe there was some other change
in your Makefile that conflicts with my my patch?

Arnd

[Alex Deucher]

This patch on top of yours seems to fix it and aligns better with the
other Makefiles:

diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
index ef673bffc241..e71f3ee76cd1 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
@@ -9,10 +9,10 @@ else ifneq ($(call cc-option, -mstack-alignment=16),)
cc_stack_align := -mstack-alignment=16
endif

-CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o := -mhard-float -msse
$(cc_stack_align)
+CFLAGS_dcn21_resource.o := -mhard-float -msse $(cc_stack_align)

ifdef CONFIG_CC_IS_CLANG
-CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o += -msse2
+CFLAGS_dcn21_resource.o += -msse2
endif

AMD_DAL_DCN21 = $(addprefix $(AMDDALPATH)/dc/dcn21/,$(DCN21))

[Arnd Bergmann]

Ok, so there is clearly a global change that went into your tree, or
is missing from it:

I see that as of linux-5.4-rc1, I have commit 54b8ae66ae1a ("kbuild: change
*FLAGS_<basetarget>.o to take the path relative to $(obj)"), which changed
all these path names to include the AMDDALPATH.

It seems you are either on an older kernel that does not yet have this,
or you have applied another patch that reverts it.

Arnd

[Alex Deucher]

Ah, I don't have that patch yet in my tree. That explains it.

Alex

[Nick Desaulniers]

> Apparently this bug is still present in both the released clang-9
> and the current development version of clang-10.
> I was hoping we would not need a workaround in clang-9+, but
> it seems that we do.

I think I'd rather:
1. mark AMDGPU BROKEN if CC_IS_CLANG. There are numerous other issues building
a working driver here.
2. Fix the compiler bug.

[Nathan Chancellor]

The only reason I am not thrilled about this is we will lose out on
warning coverage while the compiler bug gets fixed. I think the AMDGPU
drivers have been the single biggest source of clang warnings.

I think something like:

depends on CC_IS_GCC || (CC_IS_CLANG && COMPILE_TEST)

would end up avoiding the runtime issues and give us warning coverage.
The only issue is that we would still need this patch...

Cheers,
Nathan

[Alex Deucher]

On Wed, Oct 2, 2019 at 8:02 AM Arnd Bergmann <ar...@arndb.de> wrote:
>
> Here are a couple of build fixes from my backlog in the randconfig
> tree. It would be good to get them all into linux-5.4.
>
> Arnd
>
> Arnd Bergmann (6):
> drm/amdgpu: make pmu support optional, again
> drm/amdgpu: hide another #warning
> drm/amdgpu: display_mode_vba_21: remove uint typedef
> drm/amd/display: fix dcn21 Makefile for clang
> [RESEND] drm/amd/display: hide an unused variable
> [RESEND] drm/amdgpu: work around llvm bug #42576

I've applied 1-5 and I'll send them for 5.4. There still seems to be
some debate about 6.

Thanks.

Alex

>
> drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 1 +
> drivers/gpu/drm/amd/amdgpu/soc15.c | 2 --
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
> drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 12 +++++++++++-
> .../amd/display/dc/dml/dcn21/display_mode_vba_21.c | 13 +++++--------
> 6 files changed, 20 insertions(+), 12 deletions(-)
>
> --
> 2.20.0
>

[Arnd Bergmann]

On Wed, Oct 2, 2019 at 8:47 PM Alex Deucher <alexd...@gmail.com> wrote:
>
> On Wed, Oct 2, 2019 at 8:02 AM Arnd Bergmann <ar...@arndb.de> wrote:
> >
> > Here are a couple of build fixes from my backlog in the randconfig
> > tree. It would be good to get them all into linux-5.4.
> >
> > Arnd
> >
> > Arnd Bergmann (6):
> > drm/amdgpu: make pmu support optional, again
> > drm/amdgpu: hide another #warning
> > drm/amdgpu: display_mode_vba_21: remove uint typedef
> > drm/amd/display: fix dcn21 Makefile for clang
> > [RESEND] drm/amd/display: hide an unused variable
> > [RESEND] drm/amdgpu: work around llvm bug #42576
>
> I've applied 1-5 and I'll send them for 5.4. There still seems to be
> some debate about 6.

Awesome, thanks a lot!

Arnd

[Nick Desaulniers]

On Wed, Oct 2, 2019 at 10:07 AM Nathan Chancellor
<natecha...@gmail.com> wrote:
>
> On Wed, Oct 02, 2019 at 09:51:37AM -0700, 'Nick Desaulniers' via Clang Built Linux wrote:
> > > Apparently this bug is still present in both the released clang-9
> > > and the current development version of clang-10.
> > > I was hoping we would not need a workaround in clang-9+, but
> > > it seems that we do.

Here's a fix: https://reviews.llvm.org/D68356
Can't possibly land until clang-10 though.

> >
> > I think I'd rather:
> > 1. mark AMDGPU BROKEN if CC_IS_CLANG. There are numerous other issues building
> > a working driver here.
>
> The only reason I am not thrilled about this is we will lose out on
> warning coverage while the compiler bug gets fixed. I think the AMDGPU
> drivers have been the single biggest source of clang warnings.
>
> I think something like:
>
> depends on CC_IS_GCC || (CC_IS_CLANG && COMPILE_TEST)
>
> would end up avoiding the runtime issues and give us warning coverage.
> The only issue is that we would still need this patch...
>
> Cheers,
> Nathan

--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

On Wed, Oct 2, 2019 at 5:03 AM Arnd Bergmann <ar...@arndb.de> wrote:
>
> Just like all the other variants, this one passes invalid
> compile-time options with clang after the new code got
> merged:
>
> clang: error: unknown argument: '-mpreferred-stack-boundary=4'
> scripts/Makefile.build:265: recipe for target 'drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.o' failed
>
> Use the same variant that we have for dcn20 to fix compilation.
>
> Fixes: eced51f9babb ("drm/amd/display: Add hubp block for Renoir (v2)")
> Signed-off-by: Arnd Bergmann <ar...@arndb.de>

Thanks for the patch!
Reviewed-by: Nick Desaulniers <ndesau...@google.com>
Tested-by: Nick Desaulniers <ndesau...@google.com>
(Though I think it's already been merged)

Alex, do you know why the AMDGPU driver uses a different stack
alignment (16B) than the rest of the x86 kernel? (see
arch/x86/Makefile which uses 8B stack alignment).

> ---
> drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
> index 8cd9de8b1a7a..ef673bffc241 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn21/Makefile
> @@ -3,7 +3,17 @@
>
> DCN21 = dcn21_hubp.o dcn21_hubbub.o dcn21_resource.o
>
> -CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o := -mhard-float -msse -mpreferred-stack-boundary=4
> +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
> + cc_stack_align := -mpreferred-stack-boundary=4
> +else ifneq ($(call cc-option, -mstack-alignment=16),)
> + cc_stack_align := -mstack-alignment=16
> +endif
> +
> +CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o := -mhard-float -msse $(cc_stack_align)
> +
> +ifdef CONFIG_CC_IS_CLANG
> +CFLAGS_$(AMDDALPATH)/dc/dcn21/dcn21_resource.o += -msse2
> +endif
>
> AMD_DAL_DCN21 = $(addprefix $(AMDDALPATH)/dc/dcn21/,$(DCN21))
>
> --
> 2.20.0
>

> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20191002120136.1777161-5-arnd%40arndb.de.



--
Thanks,
~Nick Desaulniers

[Alex Deucher]

On Wed, Oct 2, 2019 at 5:19 PM Nick Desaulniers <ndesau...@google.com> wrote:
>
> On Wed, Oct 2, 2019 at 5:03 AM Arnd Bergmann <ar...@arndb.de> wrote:
> >
> > Just like all the other variants, this one passes invalid
> > compile-time options with clang after the new code got
> > merged:
> >
> > clang: error: unknown argument: '-mpreferred-stack-boundary=4'
> > scripts/Makefile.build:265: recipe for target 'drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.o' failed
> >
> > Use the same variant that we have for dcn20 to fix compilation.
> >
> > Fixes: eced51f9babb ("drm/amd/display: Add hubp block for Renoir (v2)")
> > Signed-off-by: Arnd Bergmann <ar...@arndb.de>
>
> Thanks for the patch!
> Reviewed-by: Nick Desaulniers <ndesau...@google.com>
> Tested-by: Nick Desaulniers <ndesau...@google.com>
> (Though I think it's already been merged)
>
> Alex, do you know why the AMDGPU driver uses a different stack
> alignment (16B) than the rest of the x86 kernel? (see
> arch/x86/Makefile which uses 8B stack alignment).

Not sure. Maybe Harry can comment. I think it was added for the
floating point stuff. Not sure if it's strictly required or not.

Alex

> _______________________________________________
> amd-gfx mailing list
> amd...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[Nick Desaulniers]

On Wed, Oct 2, 2019 at 2:24 PM Alex Deucher <alexd...@gmail.com> wrote:
>
> On Wed, Oct 2, 2019 at 5:19 PM Nick Desaulniers <ndesau...@google.com> wrote:
> >
> > Alex, do you know why the AMDGPU driver uses a different stack
> > alignment (16B) than the rest of the x86 kernel? (see
> > arch/x86/Makefile which uses 8B stack alignment).
>
> Not sure. Maybe Harry can comment. I think it was added for the
> floating point stuff. Not sure if it's strictly required or not.

Can you find out for me please who knows more about this and setup a
chat with all of us? (I don't want to deride this patch's review
thread, so let's start a new thread once we know more) We're facing
some interesting runtime issues when built with Clang.

--
Thanks,
~Nick Desaulniers