linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Samuel Holland <samuel.holland@sifive.com>,
	 Thiago Jung Bauermann <thiago.bauermann@linaro.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	 linux-arm-kernel@lists.infradead.org, x86@kernel.org,
	 linux-kernel@vger.kernel.org,
	Linux-Arch <linux-arch@vger.kernel.org>,
	 linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	 Christoph Hellwig <hch@lst.de>,
	loongarch@lists.linux.dev, amd-gfx@lists.freedesktop.org,
	 Alex Deucher <alexander.deucher@amd.com>
Subject: Re: [PATCH v4 13/15] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT
Date: Fri, 12 Apr 2024 11:54:25 +1000	[thread overview]
Message-ID: <CAPM=9ty_9yKEk+cS6oJ8gD_UiB_K4X3P4mLv2RmKixLaq-1RfQ@mail.gmail.com> (raw)
In-Reply-To: <c0e170f7-5498-40ed-ba35-2ac392c2dd2a@app.fastmail.com>

On Thu, 11 Apr 2024 at 17:32, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote:
> > On Thu, 11 Apr 2024 at 03:11, Samuel Holland <samuel.holland@sifive.com> wrote:
> >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote:
> >> > Samuel Holland <samuel.holland@sifive.com> writes:
> >>
> >> >> The short-term fix would be to drop the `select ARCH_HAS_KERNEL_FPU_SUPPORT` for
> >> >> 32-bit arm until we can provide these runtime library functions.
> >> >
> >> > Does this mean that patch 2 in this series:
> >> >
> >> > [PATCH v4 02/15] ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
> >> >
> >> > will be dropped?
> >>
> >> No, because later patches in the series (3, 6) depend on the definition of
> >> CC_FLAGS_FPU from that patch. I will need to send a fixup patch unless I can
> >> find a GPL-2 compatible implementation of the runtime library functions.
> >>
> >
> > Is there really a point to doing that? Do 32-bit ARM systems even have
> > enough address space to the map the BARs of the AMD GPUs that need
> > this support?
> >
> > Given that this was not enabled before, I don't think the upshot of
> > this series should be that we enable support for something on 32-bit
> > ARM that may cause headaches down the road without any benefit.
> >
> > So I'd prefer a fixup patch that opts ARM out of this over adding
> > support code for 64-bit conversions.
>
> I have not found any dts file for a 32-bit platform with support
> for a 64-bit prefetchable BAR, and there are very few that even
> have a pcie slot (as opposed on on-board devices) you could
> plug a card into.
>
> That said, I also don't think we should encourage the use of
> floating-point code in random device drivers. There is really
> no excuse for the amdgpu driver to use floating point math
> here, and we should get AMD to fix their driver instead.

That would be nice, but it won't happen, there are many reasons for
that code to exist like it does, unless someone can write an automated
converter to fixed point and validate it produces the same results for
a long series of input values, it isn't really something that will get
"fixed".

AMD's hardware team produces the calculations, and will only look into
hardware problems in that area if the driver is using the calculations
they produce and validate.

If you've looked at the calculation complexity you'd understand this
isn't a trivial use of float-point for no reason.

Dave.

  reply	other threads:[~2024-04-12  1:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-29  7:18 [PATCH v4 00/15] Unified cross-architecture kernel-mode FPU API Samuel Holland
2024-03-29  7:18 ` [PATCH v4 01/15] arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT Samuel Holland
2024-03-29  7:18 ` [PATCH v4 02/15] ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT Samuel Holland
2024-03-29  7:18 ` [PATCH v4 03/15] ARM: crypto: Use CC_FLAGS_FPU for NEON CFLAGS Samuel Holland
2024-03-29  7:18 ` [PATCH v4 04/15] arm64: Implement ARCH_HAS_KERNEL_FPU_SUPPORT Samuel Holland
2024-03-29  7:18 ` [PATCH v4 05/15] arm64: crypto: Use CC_FLAGS_FPU for NEON CFLAGS Samuel Holland
2024-03-29  7:18 ` [PATCH v4 06/15] lib/raid6: " Samuel Holland
2024-03-29  7:18 ` [PATCH v4 07/15] LoongArch: Implement ARCH_HAS_KERNEL_FPU_SUPPORT Samuel Holland
2024-03-29  7:18 ` [PATCH v4 08/15] powerpc: " Samuel Holland
2024-03-29  7:18 ` [PATCH v4 09/15] x86/fpu: Fix asm/fpu/types.h include guard Samuel Holland
2024-03-29 17:30   ` Dave Hansen
2024-03-29  7:18 ` [PATCH v4 10/15] x86: Implement ARCH_HAS_KERNEL_FPU_SUPPORT Samuel Holland
2024-03-29 17:28   ` Dave Hansen
2024-03-29 18:02     ` Samuel Holland
2024-03-29  7:18 ` [PATCH v4 11/15] riscv: Add support for kernel-mode FPU Samuel Holland
2024-03-29  7:18 ` [PATCH v4 12/15] drm/amd/display: Only use hard-float, not altivec on powerpc Samuel Holland
2024-04-30 17:28   ` Harry Wentland
2024-03-29  7:18 ` [PATCH v4 13/15] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT Samuel Holland
2024-04-10 22:21   ` Thiago Jung Bauermann
2024-04-10 22:47     ` Samuel Holland
2024-04-11  1:02       ` Thiago Jung Bauermann
2024-04-11  1:11         ` Samuel Holland
2024-04-11  1:27           ` Thiago Jung Bauermann
2024-04-11  7:15           ` Ard Biesheuvel
2024-04-11  7:31             ` Arnd Bergmann
2024-04-12  1:54               ` Dave Airlie [this message]
2024-04-30 17:29   ` Harry Wentland
2024-05-24  4:50   ` Guenter Roeck
2024-05-24 13:17     ` Alex Deucher
2024-05-24 13:18       ` Alex Deucher
2024-05-24 13:43         ` Guenter Roeck
2024-05-24 13:53           ` Guenter Roeck
2024-05-24 18:23         ` Guenter Roeck
2024-03-29  7:18 ` [PATCH v4 14/15] selftests/fpu: Move FP code to a separate translation unit Samuel Holland
2024-03-29  7:18 ` [PATCH v4 15/15] selftests/fpu: Allow building on other architectures Samuel Holland
2024-04-03 12:51 ` [PATCH v4 00/15] Unified cross-architecture kernel-mode FPU API Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPM=9ty_9yKEk+cS6oJ8gD_UiB_K4X3P4mLv2RmKixLaq-1RfQ@mail.gmail.com' \
    --to=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=hch@lst.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=loongarch@lists.linux.dev \
    --cc=samuel.holland@sifive.com \
    --cc=thiago.bauermann@linaro.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).