Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2021-01-20 Thread Alex Deucher
On Wed, Jan 20, 2021 at 3:20 AM Ard Biesheuvel  wrote:
>
> On Tue, 5 Jan 2021 at 17:23, Alex Deucher  wrote:
> >
> > On Tue, Jan 5, 2021 at 8:05 AM Will Deacon  wrote:
> > >
> > > On Mon, Jan 04, 2021 at 11:27:24AM -0500, Alex Deucher wrote:
> > > > On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel  wrote:
> > > > >
> > > > > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel  wrote:
> > > > > >
> > > > > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
> > > > > > > >
> > > > > > > > Simply disabling -mgeneral-regs-only left and right is risky, 
> > > > > > > > given that
> > > > > > > > the standard AArch64 ABI permits the use of FP/SIMD registers 
> > > > > > > > anywhere,
> > > > > > > > and GCC is known to use SIMD registers for spilling, and may 
> > > > > > > > invent
> > > > > > > > other uses of the FP/SIMD register file that have nothing to do 
> > > > > > > > with the
> > > > > > > > floating point code in question. Note that putting 
> > > > > > > > kernel_neon_begin()
> > > > > > > > and kernel_neon_end() around the code that does use FP is not 
> > > > > > > > sufficient
> > > > > > > > here, the problem is in all the other code that may be emitted 
> > > > > > > > with
> > > > > > > > references to SIMD registers in it.
> > > > > > > >
> > > > > > > > So the only way to do this properly is to put all floating 
> > > > > > > > point code in
> > > > > > > > a separate compilation unit, and only compile that unit with
> > > > > > > > -mgeneral-regs-only. But perhaps the use of floating point here 
> > > > > > > > is
> > > > > > > > something that should be reconsidered entirely.
> > > > > > > >
> > > > > > > > Cc: Catalin Marinas 
> > > > > > > > Cc: Will Deacon 
> > > > > > > > Cc: Dave Martin 
> > > > > > > > Cc: Rob Herring 
> > > > > > > > Cc: Leo Li 
> > > > > > > > Cc: Alex Deucher 
> > > > > > > > Cc: "Christian König" 
> > > > > > > > Cc: David Airlie 
> > > > > > > > Cc: Daniel Vetter 
> > > > > > > > Cc: Daniel Kolesa 
> > > > > > > > Cc: amd-...@lists.freedesktop.org
> > > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > > Signed-off-by: Ard Biesheuvel 
> > > > > > >
> > > > > > > Can rebase this on Linus' master branch?  There were a number of 
> > > > > > > new
> > > > > > > asics added which copy pasted the ARM64 support.
> > > > > > >
> > > > > >
> > > > > > Not sure what you are asking me here. Reverting commit 
> > > > > > c38d444e44badc5
> > > > > > on top of mainline is not going to fix the other code that was 
> > > > > > added.
> > > > > > Or are you asking me to go and find the patches (how many?) that 
> > > > > > added
> > > > > > new ASICs and fix them for arm64?
> > > > > >
> > > > > > Note that this code is critically broken, as it may corrupt user
> > > > > > process state arbitrarily. So if new code was added that contains 
> > > > > > the
> > > > > > same bug, it should be reverted so that the respective authors can 
> > > > > > fix
> > > > > > it and resubmit.
> > > > > >
> > > > >
> > > > > Is this simply about dropping the newly added references to
> > > > > $(dml_rcflags) from the Makefile? Because that is quite trivial ...
> > > >
> > > > Yes, I was thinking something like the attached patch.
> > > >
> > > > Alex
> > >
> > > > From fbc93ca7d7739861ce63f6b483cf23d7cf1d69fb Mon Sep 17 00:00:00 2001
> > > > From: Alex Deucher 
> > > > Date: Mon, 4 Jan 2021 11:24:20 -0500
> > > > Subject: [PATCH] drm/amdgpu/display: drop DCN support for aarch64
> > > >
> > > > From Ard:
> > > >
> > > > "Simply disabling -mgeneral-regs-only left and right is risky, given 
> > > > that
> > > > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
> > > > and GCC is known to use SIMD registers for spilling, and may invent
> > > > other uses of the FP/SIMD register file that have nothing to do with the
> > > > floating point code in question. Note that putting kernel_neon_begin()
> > > > and kernel_neon_end() around the code that does use FP is not sufficient
> > > > here, the problem is in all the other code that may be emitted with
> > > > references to SIMD registers in it.
> > > >
> > > > So the only way to do this properly is to put all floating point code in
> > > > a separate compilation unit, and only compile that unit with
> > > > -mgeneral-regs-only."
> > > >
> > > > Disable support until the code can be properly refactored to support 
> > > > this
> > > > properly on aarch64.
> > > >
> > > > Reported-by: Ard Biesheuvel 
> > > > Signed-off-by: Alex Deucher 
> > > > ---
> > > >  drivers/gpu/drm/amd/display/Kconfig   |  2 +-
> > > >  drivers/gpu/drm/amd/display/dc/calcs/Makefile |  4 
> > > >  .../gpu/drm/amd/display/dc/clk_mgr/Makefile   | 21 ---
> > > >  drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  7 ---
> > > >  

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2021-01-20 Thread Ard Biesheuvel
On Tue, 5 Jan 2021 at 17:23, Alex Deucher  wrote:
>
> On Tue, Jan 5, 2021 at 8:05 AM Will Deacon  wrote:
> >
> > On Mon, Jan 04, 2021 at 11:27:24AM -0500, Alex Deucher wrote:
> > > On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel  wrote:
> > > >
> > > > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel  wrote:
> > > > >
> > > > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher  
> > > > > wrote:
> > > > > >
> > > > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel  
> > > > > > wrote:
> > > > > > >
> > > > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
> > > > > > >
> > > > > > > Simply disabling -mgeneral-regs-only left and right is risky, 
> > > > > > > given that
> > > > > > > the standard AArch64 ABI permits the use of FP/SIMD registers 
> > > > > > > anywhere,
> > > > > > > and GCC is known to use SIMD registers for spilling, and may 
> > > > > > > invent
> > > > > > > other uses of the FP/SIMD register file that have nothing to do 
> > > > > > > with the
> > > > > > > floating point code in question. Note that putting 
> > > > > > > kernel_neon_begin()
> > > > > > > and kernel_neon_end() around the code that does use FP is not 
> > > > > > > sufficient
> > > > > > > here, the problem is in all the other code that may be emitted 
> > > > > > > with
> > > > > > > references to SIMD registers in it.
> > > > > > >
> > > > > > > So the only way to do this properly is to put all floating point 
> > > > > > > code in
> > > > > > > a separate compilation unit, and only compile that unit with
> > > > > > > -mgeneral-regs-only. But perhaps the use of floating point here is
> > > > > > > something that should be reconsidered entirely.
> > > > > > >
> > > > > > > Cc: Catalin Marinas 
> > > > > > > Cc: Will Deacon 
> > > > > > > Cc: Dave Martin 
> > > > > > > Cc: Rob Herring 
> > > > > > > Cc: Leo Li 
> > > > > > > Cc: Alex Deucher 
> > > > > > > Cc: "Christian König" 
> > > > > > > Cc: David Airlie 
> > > > > > > Cc: Daniel Vetter 
> > > > > > > Cc: Daniel Kolesa 
> > > > > > > Cc: amd-...@lists.freedesktop.org
> > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > Signed-off-by: Ard Biesheuvel 
> > > > > >
> > > > > > Can rebase this on Linus' master branch?  There were a number of new
> > > > > > asics added which copy pasted the ARM64 support.
> > > > > >
> > > > >
> > > > > Not sure what you are asking me here. Reverting commit c38d444e44badc5
> > > > > on top of mainline is not going to fix the other code that was added.
> > > > > Or are you asking me to go and find the patches (how many?) that added
> > > > > new ASICs and fix them for arm64?
> > > > >
> > > > > Note that this code is critically broken, as it may corrupt user
> > > > > process state arbitrarily. So if new code was added that contains the
> > > > > same bug, it should be reverted so that the respective authors can fix
> > > > > it and resubmit.
> > > > >
> > > >
> > > > Is this simply about dropping the newly added references to
> > > > $(dml_rcflags) from the Makefile? Because that is quite trivial ...
> > >
> > > Yes, I was thinking something like the attached patch.
> > >
> > > Alex
> >
> > > From fbc93ca7d7739861ce63f6b483cf23d7cf1d69fb Mon Sep 17 00:00:00 2001
> > > From: Alex Deucher 
> > > Date: Mon, 4 Jan 2021 11:24:20 -0500
> > > Subject: [PATCH] drm/amdgpu/display: drop DCN support for aarch64
> > >
> > > From Ard:
> > >
> > > "Simply disabling -mgeneral-regs-only left and right is risky, given that
> > > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
> > > and GCC is known to use SIMD registers for spilling, and may invent
> > > other uses of the FP/SIMD register file that have nothing to do with the
> > > floating point code in question. Note that putting kernel_neon_begin()
> > > and kernel_neon_end() around the code that does use FP is not sufficient
> > > here, the problem is in all the other code that may be emitted with
> > > references to SIMD registers in it.
> > >
> > > So the only way to do this properly is to put all floating point code in
> > > a separate compilation unit, and only compile that unit with
> > > -mgeneral-regs-only."
> > >
> > > Disable support until the code can be properly refactored to support this
> > > properly on aarch64.
> > >
> > > Reported-by: Ard Biesheuvel 
> > > Signed-off-by: Alex Deucher 
> > > ---
> > >  drivers/gpu/drm/amd/display/Kconfig   |  2 +-
> > >  drivers/gpu/drm/amd/display/dc/calcs/Makefile |  4 
> > >  .../gpu/drm/amd/display/dc/clk_mgr/Makefile   | 21 ---
> > >  drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  7 ---
> > >  .../drm/amd/display/dc/dcn10/dcn10_resource.c |  7 ---
> > >  drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 
> > >  drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 
> > >  drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  5 -
> > >  .../gpu/drm/amd/display/dc/dcn301/Makefile|  4 
> > >  .../gpu/drm/amd/display/dc/dcn302/Makefile|  4 
> > >  

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2021-01-05 Thread Alex Deucher
On Tue, Jan 5, 2021 at 8:05 AM Will Deacon  wrote:
>
> On Mon, Jan 04, 2021 at 11:27:24AM -0500, Alex Deucher wrote:
> > On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel  wrote:
> > >
> > > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel  wrote:
> > > >
> > > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher  
> > > > wrote:
> > > > >
> > > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel  
> > > > > wrote:
> > > > > >
> > > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
> > > > > >
> > > > > > Simply disabling -mgeneral-regs-only left and right is risky, given 
> > > > > > that
> > > > > > the standard AArch64 ABI permits the use of FP/SIMD registers 
> > > > > > anywhere,
> > > > > > and GCC is known to use SIMD registers for spilling, and may invent
> > > > > > other uses of the FP/SIMD register file that have nothing to do 
> > > > > > with the
> > > > > > floating point code in question. Note that putting 
> > > > > > kernel_neon_begin()
> > > > > > and kernel_neon_end() around the code that does use FP is not 
> > > > > > sufficient
> > > > > > here, the problem is in all the other code that may be emitted with
> > > > > > references to SIMD registers in it.
> > > > > >
> > > > > > So the only way to do this properly is to put all floating point 
> > > > > > code in
> > > > > > a separate compilation unit, and only compile that unit with
> > > > > > -mgeneral-regs-only. But perhaps the use of floating point here is
> > > > > > something that should be reconsidered entirely.
> > > > > >
> > > > > > Cc: Catalin Marinas 
> > > > > > Cc: Will Deacon 
> > > > > > Cc: Dave Martin 
> > > > > > Cc: Rob Herring 
> > > > > > Cc: Leo Li 
> > > > > > Cc: Alex Deucher 
> > > > > > Cc: "Christian König" 
> > > > > > Cc: David Airlie 
> > > > > > Cc: Daniel Vetter 
> > > > > > Cc: Daniel Kolesa 
> > > > > > Cc: amd-...@lists.freedesktop.org
> > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > Signed-off-by: Ard Biesheuvel 
> > > > >
> > > > > Can rebase this on Linus' master branch?  There were a number of new
> > > > > asics added which copy pasted the ARM64 support.
> > > > >
> > > >
> > > > Not sure what you are asking me here. Reverting commit c38d444e44badc5
> > > > on top of mainline is not going to fix the other code that was added.
> > > > Or are you asking me to go and find the patches (how many?) that added
> > > > new ASICs and fix them for arm64?
> > > >
> > > > Note that this code is critically broken, as it may corrupt user
> > > > process state arbitrarily. So if new code was added that contains the
> > > > same bug, it should be reverted so that the respective authors can fix
> > > > it and resubmit.
> > > >
> > >
> > > Is this simply about dropping the newly added references to
> > > $(dml_rcflags) from the Makefile? Because that is quite trivial ...
> >
> > Yes, I was thinking something like the attached patch.
> >
> > Alex
>
> > From fbc93ca7d7739861ce63f6b483cf23d7cf1d69fb Mon Sep 17 00:00:00 2001
> > From: Alex Deucher 
> > Date: Mon, 4 Jan 2021 11:24:20 -0500
> > Subject: [PATCH] drm/amdgpu/display: drop DCN support for aarch64
> >
> > From Ard:
> >
> > "Simply disabling -mgeneral-regs-only left and right is risky, given that
> > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
> > and GCC is known to use SIMD registers for spilling, and may invent
> > other uses of the FP/SIMD register file that have nothing to do with the
> > floating point code in question. Note that putting kernel_neon_begin()
> > and kernel_neon_end() around the code that does use FP is not sufficient
> > here, the problem is in all the other code that may be emitted with
> > references to SIMD registers in it.
> >
> > So the only way to do this properly is to put all floating point code in
> > a separate compilation unit, and only compile that unit with
> > -mgeneral-regs-only."
> >
> > Disable support until the code can be properly refactored to support this
> > properly on aarch64.
> >
> > Reported-by: Ard Biesheuvel 
> > Signed-off-by: Alex Deucher 
> > ---
> >  drivers/gpu/drm/amd/display/Kconfig   |  2 +-
> >  drivers/gpu/drm/amd/display/dc/calcs/Makefile |  4 
> >  .../gpu/drm/amd/display/dc/clk_mgr/Makefile   | 21 ---
> >  drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  7 ---
> >  .../drm/amd/display/dc/dcn10/dcn10_resource.c |  7 ---
> >  drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 
> >  drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 
> >  drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  5 -
> >  .../gpu/drm/amd/display/dc/dcn301/Makefile|  4 
> >  .../gpu/drm/amd/display/dc/dcn302/Makefile|  4 
> >  drivers/gpu/drm/amd/display/dc/dml/Makefile   |  4 
> >  drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  4 
> >  drivers/gpu/drm/amd/display/dc/os_types.h |  4 
> >  13 files changed, 1 insertion(+), 73 deletions(-)
>
> Acked-by: Will Deacon 

Applied.  Thanks!

Alex

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2021-01-05 Thread Will Deacon
On Mon, Jan 04, 2021 at 11:27:24AM -0500, Alex Deucher wrote:
> On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel  wrote:
> >
> > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel  wrote:
> > >
> > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher  wrote:
> > > >
> > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel  wrote:
> > > > >
> > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
> > > > >
> > > > > Simply disabling -mgeneral-regs-only left and right is risky, given 
> > > > > that
> > > > > the standard AArch64 ABI permits the use of FP/SIMD registers 
> > > > > anywhere,
> > > > > and GCC is known to use SIMD registers for spilling, and may invent
> > > > > other uses of the FP/SIMD register file that have nothing to do with 
> > > > > the
> > > > > floating point code in question. Note that putting kernel_neon_begin()
> > > > > and kernel_neon_end() around the code that does use FP is not 
> > > > > sufficient
> > > > > here, the problem is in all the other code that may be emitted with
> > > > > references to SIMD registers in it.
> > > > >
> > > > > So the only way to do this properly is to put all floating point code 
> > > > > in
> > > > > a separate compilation unit, and only compile that unit with
> > > > > -mgeneral-regs-only. But perhaps the use of floating point here is
> > > > > something that should be reconsidered entirely.
> > > > >
> > > > > Cc: Catalin Marinas 
> > > > > Cc: Will Deacon 
> > > > > Cc: Dave Martin 
> > > > > Cc: Rob Herring 
> > > > > Cc: Leo Li 
> > > > > Cc: Alex Deucher 
> > > > > Cc: "Christian König" 
> > > > > Cc: David Airlie 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: Daniel Kolesa 
> > > > > Cc: amd-...@lists.freedesktop.org
> > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > Signed-off-by: Ard Biesheuvel 
> > > >
> > > > Can rebase this on Linus' master branch?  There were a number of new
> > > > asics added which copy pasted the ARM64 support.
> > > >
> > >
> > > Not sure what you are asking me here. Reverting commit c38d444e44badc5
> > > on top of mainline is not going to fix the other code that was added.
> > > Or are you asking me to go and find the patches (how many?) that added
> > > new ASICs and fix them for arm64?
> > >
> > > Note that this code is critically broken, as it may corrupt user
> > > process state arbitrarily. So if new code was added that contains the
> > > same bug, it should be reverted so that the respective authors can fix
> > > it and resubmit.
> > >
> >
> > Is this simply about dropping the newly added references to
> > $(dml_rcflags) from the Makefile? Because that is quite trivial ...
> 
> Yes, I was thinking something like the attached patch.
> 
> Alex

> From fbc93ca7d7739861ce63f6b483cf23d7cf1d69fb Mon Sep 17 00:00:00 2001
> From: Alex Deucher 
> Date: Mon, 4 Jan 2021 11:24:20 -0500
> Subject: [PATCH] drm/amdgpu/display: drop DCN support for aarch64
> 
> From Ard:
> 
> "Simply disabling -mgeneral-regs-only left and right is risky, given that
> the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
> and GCC is known to use SIMD registers for spilling, and may invent
> other uses of the FP/SIMD register file that have nothing to do with the
> floating point code in question. Note that putting kernel_neon_begin()
> and kernel_neon_end() around the code that does use FP is not sufficient
> here, the problem is in all the other code that may be emitted with
> references to SIMD registers in it.
> 
> So the only way to do this properly is to put all floating point code in
> a separate compilation unit, and only compile that unit with
> -mgeneral-regs-only."
> 
> Disable support until the code can be properly refactored to support this
> properly on aarch64.
> 
> Reported-by: Ard Biesheuvel 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/display/Kconfig   |  2 +-
>  drivers/gpu/drm/amd/display/dc/calcs/Makefile |  4 
>  .../gpu/drm/amd/display/dc/clk_mgr/Makefile   | 21 ---
>  drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  7 ---
>  .../drm/amd/display/dc/dcn10/dcn10_resource.c |  7 ---
>  drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 
>  drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 
>  drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  5 -
>  .../gpu/drm/amd/display/dc/dcn301/Makefile|  4 
>  .../gpu/drm/amd/display/dc/dcn302/Makefile|  4 
>  drivers/gpu/drm/amd/display/dc/dml/Makefile   |  4 
>  drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  4 
>  drivers/gpu/drm/amd/display/dc/os_types.h |  4 
>  13 files changed, 1 insertion(+), 73 deletions(-)

Acked-by: Will Deacon 

Will
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2021-01-04 Thread Ard Biesheuvel
On Mon, 4 Jan 2021 at 17:27, Alex Deucher  wrote:
>
> On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel  wrote:
> >
> > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel  wrote:
> > >
> > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher  wrote:
> > > >
> > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel  wrote:
> > > > >
> > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
> > > > >
> > > > > Simply disabling -mgeneral-regs-only left and right is risky, given 
> > > > > that
> > > > > the standard AArch64 ABI permits the use of FP/SIMD registers 
> > > > > anywhere,
> > > > > and GCC is known to use SIMD registers for spilling, and may invent
> > > > > other uses of the FP/SIMD register file that have nothing to do with 
> > > > > the
> > > > > floating point code in question. Note that putting kernel_neon_begin()
> > > > > and kernel_neon_end() around the code that does use FP is not 
> > > > > sufficient
> > > > > here, the problem is in all the other code that may be emitted with
> > > > > references to SIMD registers in it.
> > > > >
> > > > > So the only way to do this properly is to put all floating point code 
> > > > > in
> > > > > a separate compilation unit, and only compile that unit with
> > > > > -mgeneral-regs-only. But perhaps the use of floating point here is
> > > > > something that should be reconsidered entirely.
> > > > >
> > > > > Cc: Catalin Marinas 
> > > > > Cc: Will Deacon 
> > > > > Cc: Dave Martin 
> > > > > Cc: Rob Herring 
> > > > > Cc: Leo Li 
> > > > > Cc: Alex Deucher 
> > > > > Cc: "Christian König" 
> > > > > Cc: David Airlie 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: Daniel Kolesa 
> > > > > Cc: amd-...@lists.freedesktop.org
> > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > Signed-off-by: Ard Biesheuvel 
> > > >
> > > > Can rebase this on Linus' master branch?  There were a number of new
> > > > asics added which copy pasted the ARM64 support.
> > > >
> > >
> > > Not sure what you are asking me here. Reverting commit c38d444e44badc5
> > > on top of mainline is not going to fix the other code that was added.
> > > Or are you asking me to go and find the patches (how many?) that added
> > > new ASICs and fix them for arm64?
> > >
> > > Note that this code is critically broken, as it may corrupt user
> > > process state arbitrarily. So if new code was added that contains the
> > > same bug, it should be reverted so that the respective authors can fix
> > > it and resubmit.
> > >
> >
> > Is this simply about dropping the newly added references to
> > $(dml_rcflags) from the Makefile? Because that is quite trivial ...
>
> Yes, I was thinking something like the attached patch.
>

Cheers, that builds fine with v5.11-rc2/defconfig plus CONFIG_DRM_AMDGPU=m
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2021-01-04 Thread Alex Deucher
On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel  wrote:
>
> On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel  wrote:
> >
> > On Wed, 16 Dec 2020 at 19:00, Alex Deucher  wrote:
> > >
> > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel  wrote:
> > > >
> > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
> > > >
> > > > Simply disabling -mgeneral-regs-only left and right is risky, given that
> > > > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
> > > > and GCC is known to use SIMD registers for spilling, and may invent
> > > > other uses of the FP/SIMD register file that have nothing to do with the
> > > > floating point code in question. Note that putting kernel_neon_begin()
> > > > and kernel_neon_end() around the code that does use FP is not sufficient
> > > > here, the problem is in all the other code that may be emitted with
> > > > references to SIMD registers in it.
> > > >
> > > > So the only way to do this properly is to put all floating point code in
> > > > a separate compilation unit, and only compile that unit with
> > > > -mgeneral-regs-only. But perhaps the use of floating point here is
> > > > something that should be reconsidered entirely.
> > > >
> > > > Cc: Catalin Marinas 
> > > > Cc: Will Deacon 
> > > > Cc: Dave Martin 
> > > > Cc: Rob Herring 
> > > > Cc: Leo Li 
> > > > Cc: Alex Deucher 
> > > > Cc: "Christian König" 
> > > > Cc: David Airlie 
> > > > Cc: Daniel Vetter 
> > > > Cc: Daniel Kolesa 
> > > > Cc: amd-...@lists.freedesktop.org
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Signed-off-by: Ard Biesheuvel 
> > >
> > > Can rebase this on Linus' master branch?  There were a number of new
> > > asics added which copy pasted the ARM64 support.
> > >
> >
> > Not sure what you are asking me here. Reverting commit c38d444e44badc5
> > on top of mainline is not going to fix the other code that was added.
> > Or are you asking me to go and find the patches (how many?) that added
> > new ASICs and fix them for arm64?
> >
> > Note that this code is critically broken, as it may corrupt user
> > process state arbitrarily. So if new code was added that contains the
> > same bug, it should be reverted so that the respective authors can fix
> > it and resubmit.
> >
>
> Is this simply about dropping the newly added references to
> $(dml_rcflags) from the Makefile? Because that is quite trivial ...

Yes, I was thinking something like the attached patch.

Alex
From fbc93ca7d7739861ce63f6b483cf23d7cf1d69fb Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Mon, 4 Jan 2021 11:24:20 -0500
Subject: [PATCH] drm/amdgpu/display: drop DCN support for aarch64

From Ard:

"Simply disabling -mgeneral-regs-only left and right is risky, given that
the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
and GCC is known to use SIMD registers for spilling, and may invent
other uses of the FP/SIMD register file that have nothing to do with the
floating point code in question. Note that putting kernel_neon_begin()
and kernel_neon_end() around the code that does use FP is not sufficient
here, the problem is in all the other code that may be emitted with
references to SIMD registers in it.

So the only way to do this properly is to put all floating point code in
a separate compilation unit, and only compile that unit with
-mgeneral-regs-only."

Disable support until the code can be properly refactored to support this
properly on aarch64.

Reported-by: Ard Biesheuvel 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/display/Kconfig   |  2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile |  4 
 .../gpu/drm/amd/display/dc/clk_mgr/Makefile   | 21 ---
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  7 ---
 .../drm/amd/display/dc/dcn10/dcn10_resource.c |  7 ---
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 
 drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  5 -
 .../gpu/drm/amd/display/dc/dcn301/Makefile|  4 
 .../gpu/drm/amd/display/dc/dcn302/Makefile|  4 
 drivers/gpu/drm/amd/display/dc/dml/Makefile   |  4 
 drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  4 
 drivers/gpu/drm/amd/display/dc/os_types.h |  4 
 13 files changed, 1 insertion(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig
index 797b5d4b43e5..e509a175ed17 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -6,7 +6,7 @@ config DRM_AMD_DC
 	bool "AMD DC - Enable new display engine"
 	default y
 	select SND_HDA_COMPONENT if SND_HDA_CORE
-	select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && KERNEL_MODE_NEON)) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
+	select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
 	help
 	  Choose this option if you want to use the new display engine
 	  support for AMDGPU. This adds 

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2020-12-29 Thread Ard Biesheuvel
On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel  wrote:
>
> On Wed, 16 Dec 2020 at 19:00, Alex Deucher  wrote:
> >
> > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel  wrote:
> > >
> > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
> > >
> > > Simply disabling -mgeneral-regs-only left and right is risky, given that
> > > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
> > > and GCC is known to use SIMD registers for spilling, and may invent
> > > other uses of the FP/SIMD register file that have nothing to do with the
> > > floating point code in question. Note that putting kernel_neon_begin()
> > > and kernel_neon_end() around the code that does use FP is not sufficient
> > > here, the problem is in all the other code that may be emitted with
> > > references to SIMD registers in it.
> > >
> > > So the only way to do this properly is to put all floating point code in
> > > a separate compilation unit, and only compile that unit with
> > > -mgeneral-regs-only. But perhaps the use of floating point here is
> > > something that should be reconsidered entirely.
> > >
> > > Cc: Catalin Marinas 
> > > Cc: Will Deacon 
> > > Cc: Dave Martin 
> > > Cc: Rob Herring 
> > > Cc: Leo Li 
> > > Cc: Alex Deucher 
> > > Cc: "Christian König" 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Cc: Daniel Kolesa 
> > > Cc: amd-...@lists.freedesktop.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Signed-off-by: Ard Biesheuvel 
> >
> > Can rebase this on Linus' master branch?  There were a number of new
> > asics added which copy pasted the ARM64 support.
> >
>
> Not sure what you are asking me here. Reverting commit c38d444e44badc5
> on top of mainline is not going to fix the other code that was added.
> Or are you asking me to go and find the patches (how many?) that added
> new ASICs and fix them for arm64?
>
> Note that this code is critically broken, as it may corrupt user
> process state arbitrarily. So if new code was added that contains the
> same bug, it should be reverted so that the respective authors can fix
> it and resubmit.
>

Is this simply about dropping the newly added references to
$(dml_rcflags) from the Makefile? Because that is quite trivial ...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2020-12-16 Thread Ard Biesheuvel
On Wed, 16 Dec 2020 at 19:00, Alex Deucher  wrote:
>
> On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel  wrote:
> >
> > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
> >
> > Simply disabling -mgeneral-regs-only left and right is risky, given that
> > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
> > and GCC is known to use SIMD registers for spilling, and may invent
> > other uses of the FP/SIMD register file that have nothing to do with the
> > floating point code in question. Note that putting kernel_neon_begin()
> > and kernel_neon_end() around the code that does use FP is not sufficient
> > here, the problem is in all the other code that may be emitted with
> > references to SIMD registers in it.
> >
> > So the only way to do this properly is to put all floating point code in
> > a separate compilation unit, and only compile that unit with
> > -mgeneral-regs-only. But perhaps the use of floating point here is
> > something that should be reconsidered entirely.
> >
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: Dave Martin 
> > Cc: Rob Herring 
> > Cc: Leo Li 
> > Cc: Alex Deucher 
> > Cc: "Christian König" 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Daniel Kolesa 
> > Cc: amd-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Ard Biesheuvel 
>
> Can rebase this on Linus' master branch?  There were a number of new
> asics added which copy pasted the ARM64 support.
>

Not sure what you are asking me here. Reverting commit c38d444e44badc5
on top of mainline is not going to fix the other code that was added.
Or are you asking me to go and find the patches (how many?) that added
new ASICs and fix them for arm64?

Note that this code is critically broken, as it may corrupt user
process state arbitrarily. So if new code was added that contains the
same bug, it should be reverted so that the respective authors can fix
it and resubmit.





>
> > ---
> >  drivers/gpu/drm/amd/display/Kconfig   |  2 +-
> >  drivers/gpu/drm/amd/display/dc/calcs/Makefile |  7 --
> >  drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 --
> >  drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  7 --
> >  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 81 
> > 
> >  drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 -
> >  drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 -
> >  drivers/gpu/drm/amd/display/dc/dml/Makefile   | 13 
> >  drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  5 --
> >  drivers/gpu/drm/amd/display/dc/os_types.h |  4 -
> >  10 files changed, 32 insertions(+), 102 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/Kconfig 
> > b/drivers/gpu/drm/amd/display/Kconfig
> > index 60dfdd432aba..3c410d236c49 100644
> > --- a/drivers/gpu/drm/amd/display/Kconfig
> > +++ b/drivers/gpu/drm/amd/display/Kconfig
> > @@ -6,7 +6,7 @@ config DRM_AMD_DC
> > bool "AMD DC - Enable new display engine"
> > default y
> > select SND_HDA_COMPONENT if SND_HDA_CORE
> > -   select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && 
> > KERNEL_MODE_NEON)) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
> > +   select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && 
> > KCOV_ENABLE_COMPARISONS)
> > help
> >   Choose this option if you want to use the new display engine
> >   support for AMDGPU. This adds required support for Vega and
> > diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
> > b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> > index 64f515d74410..4674aca8f206 100644
> > --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> > @@ -33,10 +33,6 @@ ifdef CONFIG_PPC64
> >  calcs_ccflags := -mhard-float -maltivec
> >  endif
> >
> > -ifdef CONFIG_ARM64
> > -calcs_rcflags := -mgeneral-regs-only
> > -endif
> > -
> >  ifdef CONFIG_CC_IS_GCC
> >  ifeq ($(call cc-ifversion, -lt, 0701, y), y)
> >  IS_OLD_GCC = 1
> > @@ -57,9 +53,6 @@ endif
> >  CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_ccflags)
> >  CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_ccflags)
> >  CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_ccflags) 
> > -Wno-tautological-compare
> > -CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_rcflags)
> > -CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_rcflags)
> > -CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_rcflags)
> >
> >  BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile 
> > b/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile
> > index 1a495759a034..52b1ce775a1e 100644
> > --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile
> > @@ -104,13 +104,6 @@ ifdef CONFIG_PPC64
> >  

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2020-12-16 Thread Alex Deucher
On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel  wrote:
>
> This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
>
> Simply disabling -mgeneral-regs-only left and right is risky, given that
> the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
> and GCC is known to use SIMD registers for spilling, and may invent
> other uses of the FP/SIMD register file that have nothing to do with the
> floating point code in question. Note that putting kernel_neon_begin()
> and kernel_neon_end() around the code that does use FP is not sufficient
> here, the problem is in all the other code that may be emitted with
> references to SIMD registers in it.
>
> So the only way to do this properly is to put all floating point code in
> a separate compilation unit, and only compile that unit with
> -mgeneral-regs-only. But perhaps the use of floating point here is
> something that should be reconsidered entirely.
>
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Dave Martin 
> Cc: Rob Herring 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Daniel Kolesa 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Ard Biesheuvel 

Can rebase this on Linus' master branch?  There were a number of new
asics added which copy pasted the ARM64 support.

Alex


> ---
>  drivers/gpu/drm/amd/display/Kconfig   |  2 +-
>  drivers/gpu/drm/amd/display/dc/calcs/Makefile |  7 --
>  drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 --
>  drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  7 --
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 81 
> 
>  drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 -
>  drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 -
>  drivers/gpu/drm/amd/display/dc/dml/Makefile   | 13 
>  drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  5 --
>  drivers/gpu/drm/amd/display/dc/os_types.h |  4 -
>  10 files changed, 32 insertions(+), 102 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/Kconfig 
> b/drivers/gpu/drm/amd/display/Kconfig
> index 60dfdd432aba..3c410d236c49 100644
> --- a/drivers/gpu/drm/amd/display/Kconfig
> +++ b/drivers/gpu/drm/amd/display/Kconfig
> @@ -6,7 +6,7 @@ config DRM_AMD_DC
> bool "AMD DC - Enable new display engine"
> default y
> select SND_HDA_COMPONENT if SND_HDA_CORE
> -   select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && 
> KERNEL_MODE_NEON)) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
> +   select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && 
> KCOV_ENABLE_COMPARISONS)
> help
>   Choose this option if you want to use the new display engine
>   support for AMDGPU. This adds required support for Vega and
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
> b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> index 64f515d74410..4674aca8f206 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> @@ -33,10 +33,6 @@ ifdef CONFIG_PPC64
>  calcs_ccflags := -mhard-float -maltivec
>  endif
>
> -ifdef CONFIG_ARM64
> -calcs_rcflags := -mgeneral-regs-only
> -endif
> -
>  ifdef CONFIG_CC_IS_GCC
>  ifeq ($(call cc-ifversion, -lt, 0701, y), y)
>  IS_OLD_GCC = 1
> @@ -57,9 +53,6 @@ endif
>  CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_ccflags)
>  CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_ccflags)
>  CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_ccflags) 
> -Wno-tautological-compare
> -CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_rcflags)
> -CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_rcflags)
> -CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_rcflags)
>
>  BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o
>
> diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile 
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile
> index 1a495759a034..52b1ce775a1e 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile
> @@ -104,13 +104,6 @@ ifdef CONFIG_PPC64
>  CFLAGS_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := $(call 
> cc-option,-mno-gnu-attribute)
>  endif
>
> -# prevent build errors:
> -# ...: '-mgeneral-regs-only' is incompatible with the use of floating-point 
> types
> -# this file is unused on arm64, just like on ppc64
> -ifdef CONFIG_ARM64
> -CFLAGS_REMOVE_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := 
> -mgeneral-regs-only
> -endif
> -
>  AMD_DAL_CLK_MGR_DCN21 = $(addprefix 
> $(AMDDALPATH)/dc/clk_mgr/dcn21/,$(CLK_MGR_DCN21))
>
>  AMD_DISPLAY_FILES += $(AMD_DAL_CLK_MGR_DCN21)
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile 
> b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
> index 733e6e6e43bd..62ad1a11bff9 100644
> --- 

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2020-12-14 Thread Will Deacon
On Mon, Dec 14, 2020 at 06:52:25PM +0100, Ard Biesheuvel wrote:
> This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
> 
> Simply disabling -mgeneral-regs-only left and right is risky, given that
> the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
> and GCC is known to use SIMD registers for spilling, and may invent
> other uses of the FP/SIMD register file that have nothing to do with the
> floating point code in question. Note that putting kernel_neon_begin()
> and kernel_neon_end() around the code that does use FP is not sufficient
> here, the problem is in all the other code that may be emitted with
> references to SIMD registers in it.
> 
> So the only way to do this properly is to put all floating point code in
> a separate compilation unit, and only compile that unit with
> -mgeneral-regs-only. But perhaps the use of floating point here is
> something that should be reconsidered entirely.
> 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Dave Martin 
> Cc: Rob Herring 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Daniel Kolesa 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Ard Biesheuvel 
> ---
>  drivers/gpu/drm/amd/display/Kconfig   |  2 +-
>  drivers/gpu/drm/amd/display/dc/calcs/Makefile |  7 --
>  drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 --
>  drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  7 --
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 81 
> 
>  drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 -
>  drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 -
>  drivers/gpu/drm/amd/display/dc/dml/Makefile   | 13 
>  drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  5 --
>  drivers/gpu/drm/amd/display/dc/os_types.h |  4 -
>  10 files changed, 32 insertions(+), 102 deletions(-)

I didn't notice we'd enabled this for arm64, but I agree with the reasoning
in the commit message, so:

Acked-by: Will Deacon 

The long and short of it is that it is not safe to compile kernel C code
without -mgeneral-regs-only on arm64.

Will
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2020-12-14 Thread Ard Biesheuvel
This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.

Simply disabling -mgeneral-regs-only left and right is risky, given that
the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
and GCC is known to use SIMD registers for spilling, and may invent
other uses of the FP/SIMD register file that have nothing to do with the
floating point code in question. Note that putting kernel_neon_begin()
and kernel_neon_end() around the code that does use FP is not sufficient
here, the problem is in all the other code that may be emitted with
references to SIMD registers in it.

So the only way to do this properly is to put all floating point code in
a separate compilation unit, and only compile that unit with
-mgeneral-regs-only. But perhaps the use of floating point here is
something that should be reconsidered entirely.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Dave Martin 
Cc: Rob Herring 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Daniel Kolesa 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Ard Biesheuvel 
---
 drivers/gpu/drm/amd/display/Kconfig   |  2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile |  7 --
 drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 --
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  7 --
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 81 
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 -
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 -
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 13 
 drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  5 --
 drivers/gpu/drm/amd/display/dc/os_types.h |  4 -
 10 files changed, 32 insertions(+), 102 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/Kconfig 
b/drivers/gpu/drm/amd/display/Kconfig
index 60dfdd432aba..3c410d236c49 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -6,7 +6,7 @@ config DRM_AMD_DC
bool "AMD DC - Enable new display engine"
default y
select SND_HDA_COMPONENT if SND_HDA_CORE
-   select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && KERNEL_MODE_NEON)) 
&& !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
+   select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && 
KCOV_ENABLE_COMPARISONS)
help
  Choose this option if you want to use the new display engine
  support for AMDGPU. This adds required support for Vega and
diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
index 64f515d74410..4674aca8f206 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
@@ -33,10 +33,6 @@ ifdef CONFIG_PPC64
 calcs_ccflags := -mhard-float -maltivec
 endif
 
-ifdef CONFIG_ARM64
-calcs_rcflags := -mgeneral-regs-only
-endif
-
 ifdef CONFIG_CC_IS_GCC
 ifeq ($(call cc-ifversion, -lt, 0701, y), y)
 IS_OLD_GCC = 1
@@ -57,9 +53,6 @@ endif
 CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_ccflags) 
-Wno-tautological-compare
-CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_rcflags)
-CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_rcflags)
-CFLAGS_REMOVE_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_rcflags)
 
 BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o
 
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile
index 1a495759a034..52b1ce775a1e 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile
@@ -104,13 +104,6 @@ ifdef CONFIG_PPC64
 CFLAGS_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := $(call 
cc-option,-mno-gnu-attribute)
 endif
 
-# prevent build errors:
-# ...: '-mgeneral-regs-only' is incompatible with the use of floating-point 
types
-# this file is unused on arm64, just like on ppc64
-ifdef CONFIG_ARM64
-CFLAGS_REMOVE_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := 
-mgeneral-regs-only
-endif
-
 AMD_DAL_CLK_MGR_DCN21 = $(addprefix 
$(AMDDALPATH)/dc/clk_mgr/dcn21/,$(CLK_MGR_DCN21))
 
 AMD_DISPLAY_FILES += $(AMD_DAL_CLK_MGR_DCN21)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
index 733e6e6e43bd..62ad1a11bff9 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
@@ -31,11 +31,4 @@ DCN10 = dcn10_init.o dcn10_resource.o dcn10_ipp.o 
dcn10_hw_sequencer.o \
 
 AMD_DAL_DCN10 = $(addprefix $(AMDDALPATH)/dc/dcn10/,$(DCN10))
 
-# fix:
-# ...: '-mgeneral-regs-only' is incompatible with the use of floating-point 
types
-# aarch64 does not support soft-float, so use hard-float and handle this in