On Thu, 11 Apr 2024 at 17:32, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote: > > On Thu, 11 Apr 2024 at 03:11, Samuel Holland <samuel.holland@xxxxxxxxxx> wrote: > >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote: > >> > Samuel Holland <samuel.holland@xxxxxxxxxx> 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.
