From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E20C53A7; Fri, 12 Apr 2024 01:54:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712886879; cv=none; b=iYBbYQt28FoCSqdBBqTaD9j3Nju9meZOoJv0gPImf0lKIRs15ox87HhJ4YNu+jjtho9KzvUE2pUONx0//EYfyjzBJ/reKR1FLmVmfPAolLeiukDocR4vv5at29wmHJbWjZdMzS2lJsng1pnKGnzOqvCpwF+KmSu7JhhL5OJRRKU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712886879; c=relaxed/simple; bh=y4vlt8TB9yDjErxa7aoPppj34TQs7XIg9OjF7nGdMbk=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=gIGvdWT8BE5Yf+wceiyPfbr4z7uWtdzjoB//mOuIyjZr4Kw1o+zPEseQr8U7ZnOxFbXuu9/vCEptHFPcFszmKPjOlary1qRwfhg8UzE3TMx92fjnM0AMwRe6xxdnb0ybflM7b4oIkdRGBf1DcWRzgmTjynQ8PMPtHBGDsm+Byx0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=kdbONLGY; arc=none smtp.client-ip=209.85.221.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kdbONLGY" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-346b09d474dso363183f8f.2; Thu, 11 Apr 2024 18:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712886876; x=1713491676; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y4vlt8TB9yDjErxa7aoPppj34TQs7XIg9OjF7nGdMbk=; b=kdbONLGYw2QldU//Gv4Ys+kJRUEYyE1Wkx9stlBiRwEA3BetUjUy7y2Gg8nnVxHtvC 0pXPmsdzzacgTPR9NmR993Ump2WWYyJwdG5+K2EZ2w2s6nY3MvjLgexU6tX8Hx7by4XB 2B+UzHDbNTYp+uZBVmCa30o1nTv3LWe6wdDXjpCb6LK7C0+ypf/UBbG8bbnHipw8hUTJ 8bzTRflt74OEd3O2RYQHuuk2PQh6Bexe+QuEdkpo4Mb83IZlaO0FhWRy4nulfPId7BVT y4c33ws+NE8f1HyOGAAjeJACZBIYI6GRZ+PbRBzhE5Za/jexbvwiULFX6iFFYOcga8ZB XCuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712886876; x=1713491676; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y4vlt8TB9yDjErxa7aoPppj34TQs7XIg9OjF7nGdMbk=; b=MVy98J8kdp+YYIOYzzRtVjsE0rJbR/J4Uzp7o4FPCoqMejHAYslhgM/IjR8ITLx4U0 f7ZNFdIt1KWWFEtNq3DOe1YDCFuK/y22TaaKvVZIGihEFvKgArzNZI6PvkH1ublYNx6l 1z0yDeRl63OoY7k9v12fvvHLDU38lMP5MJHmGpQBYuHtYqb9CcZB6GVCR2p+FrY2zE7Z KE8+tGw604ZmFJu9nQhsY2Rv7qZEHEGhHfTLhsEwjrIBfhG75F/2/d4POk6ki4CPbvkZ CDBN39llaxrBznXNXSCvJYWbnGhtVsXp+Sq/lkxCDO/u3D4NRvnkDcY4rL2E2URa/lGz q1cA== X-Forwarded-Encrypted: i=1; AJvYcCW5x1fawopXJpoluSTsfIHvpSLEkIxw8ZGEuQ+hXhwgx2AWtMJR3/EpzP6ZGasBkUxcN4M5NyiiiAE56NAHrWEzfQEalR5o6i0MSkzaU/Jkp27fF4HRbDYMRG/cmUtCq1osqZc0exrR8Q== X-Gm-Message-State: AOJu0YxTdC39WWyCmGBK1x+9QA6pmeg2WNZTYLc7dLicm5eT8KUA9elf XRO0tJLhIE0gsio+OnnTeo+qTE4AguL9z4SMFbL8XiaGn4RKRfdW5onGQr2k1t5AjzvPo7YMMny 1+EVKf0weLc6clnSz8zhAx70UKgm6DMV6 X-Google-Smtp-Source: AGHT+IH+PR4h3oVtQ8Ez0cRs6zyDvlUxECTYXxWqfVRSac34W79R5yeA3Zq4bIaDyQbovOeeCgfyqRUJHwPOnRqGQX0= X-Received: by 2002:a5d:474f:0:b0:33e:ca28:bb59 with SMTP id o15-20020a5d474f000000b0033eca28bb59mr856430wrs.57.1712886876424; Thu, 11 Apr 2024 18:54:36 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240329072441.591471-1-samuel.holland@sifive.com> <20240329072441.591471-14-samuel.holland@sifive.com> <87wmp4oo3y.fsf@linaro.org> <75a37a4b-f516-40a3-b6b5-4aa1636f9b60@sifive.com> <87wmp4ogoe.fsf@linaro.org> <4c8e63d6-ba33-47fe-8150-59eba8babf2d@sifive.com> In-Reply-To: From: Dave Airlie Date: Fri, 12 Apr 2024 11:54:25 +1000 Message-ID: Subject: Re: [PATCH v4 13/15] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT To: Arnd Bergmann Cc: Ard Biesheuvel , Samuel Holland , Thiago Jung Bauermann , Andrew Morton , linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kernel@vger.kernel.org, Linux-Arch , linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, Christoph Hellwig , loongarch@lists.linux.dev, amd-gfx@lists.freedesktop.org, Alex Deucher Content-Type: text/plain; charset="UTF-8" On Thu, 11 Apr 2024 at 17:32, Arnd Bergmann wrote: > > On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote: > > On Thu, 11 Apr 2024 at 03:11, Samuel Holland wrote: > >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote: > >> > Samuel Holland 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C4CFAC04FF0 for ; Fri, 12 Apr 2024 01:54:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kpfuuZ59oOZExKKYY/KZPp2uMSMVZBmCs8aY6jtYbwg=; b=182vQzHI5DR+PO npUG3B4jPl88GKDRV3BEJJQFrQw96qUbcm34Kj7N2fAzEXJ2tM4Kd8u+4sr+Qji2swbYQ5p3a10l6 nUa3SJ4TiATyEwEaMImgLFQnXSol8jF6F3AiKXKM/YWGljpWhUzupLGaCO5BWNbLrlUe+Yad8z1sl UHZ26XGiyE2Yv2aZAVgyobiU9k6hF8c+U0151yeZg2RNl8PDkOFdkZ+kcqhjceCuB6yAkIe+V+lu+ jKxs4YCzLkxwLwM+ktpKvvo8MH8m+YpcdPNVTT+TUlZchES13kNFV92YaoU/1P7XIAVSJ8Fa8WJ5n SZ294aXW2pbXbjyBiB2A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rv67o-0000000Ep6y-0Kmj; Fri, 12 Apr 2024 01:54:44 +0000 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rv67j-0000000Ep5q-2ov6; Fri, 12 Apr 2024 01:54:41 +0000 Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-346b94fa7ecso371111f8f.3; Thu, 11 Apr 2024 18:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712886876; x=1713491676; darn=lists.infradead.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y4vlt8TB9yDjErxa7aoPppj34TQs7XIg9OjF7nGdMbk=; b=abrPmGmvwiFXdCT7LZrjo/eORtEM+wJT15IpOVCrZvJw2cTKr9roMRufr0HLxbfBMd xs37RtvbmbtEeVEhauqIA3slcD+TFHE+GMcL462YnOBFeCWjxBEcC1jdKDTu4Y6Id5yQ 2dX5ois2/bWZvShhmq/UwW14eTSzk0fgXAkd5XzBIqBJdLOpJ9UcA2chbicYDLUICwjb Bi49vwbhXGwDdPTDBJAfwV6qCunNtOXJJ3vi32bHOxmDvqNlFk/EwJUg3WTZlnIfcFue bfWpDePao4JTn/7eWnsMkN0PYekSGhowE7xRRoLWPMwjhp4CPkACXlbgc+R331Plm/uP ChOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712886876; x=1713491676; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y4vlt8TB9yDjErxa7aoPppj34TQs7XIg9OjF7nGdMbk=; b=SbSVZ46j1NexLy6S2UximCudzyvMqWGxpqZA0d2ni3uz6M1Ee25/NY974DN8bEwmmk mWRaQ5U7pZ3+Y0q4eM8al1D0yu4sAHUVEdbiqhSpg9TNARd067T7OiTCMWl0WNk7vQTY oFIB7qsHyZIB/9UxwSnnXNOBvUOENp7qa70l+WFjDwpKT0JyF6p5BHDmhpECWxNoPsqw ROCqFUDrfVc2NLMPH4b7Ei0mTzFrkB+CjC36td9X9eXdSugA5x4ttoEAlQpjJGszFB1R Y4Lwonl6Bqr0UI/cAWuUzm+3wHN7Wuf0hfV9YmmS7VaQEY23JCVDvbmdaeIf5bHfL20/ GA9A== X-Forwarded-Encrypted: i=1; AJvYcCVwFn4s1IXE/K6psDNuCjFghq8EeGVgJfZIUFbqzF8lo6oBTF1CZg2ZPVyEUPwqKNs5qryFtklEKGxZzKweRi+Z2qcODw+Nejy9q8zEZwj8p1G183k3c1ucYZP3F60iwp1xjq+pcEhD75yYkt5BYoCqrU60ozk= X-Gm-Message-State: AOJu0Yz2glqX8mPtrcfvTZotIC1/xpWYzQ/fr7SFPjlK2qscmy+fB+Pn MTAgv+i7xbaZwzX1vL6DN4V0CVXalgPzUOW6Zsg1tPBecAokIkw5OcegIFrn8a3NigC/bRBhkic unRUjypAcoWWeAAlr4e5eemMiQtU= X-Google-Smtp-Source: AGHT+IH+PR4h3oVtQ8Ez0cRs6zyDvlUxECTYXxWqfVRSac34W79R5yeA3Zq4bIaDyQbovOeeCgfyqRUJHwPOnRqGQX0= X-Received: by 2002:a5d:474f:0:b0:33e:ca28:bb59 with SMTP id o15-20020a5d474f000000b0033eca28bb59mr856430wrs.57.1712886876424; Thu, 11 Apr 2024 18:54:36 -0700 (PDT) MIME-Version: 1.0 References: <20240329072441.591471-1-samuel.holland@sifive.com> <20240329072441.591471-14-samuel.holland@sifive.com> <87wmp4oo3y.fsf@linaro.org> <75a37a4b-f516-40a3-b6b5-4aa1636f9b60@sifive.com> <87wmp4ogoe.fsf@linaro.org> <4c8e63d6-ba33-47fe-8150-59eba8babf2d@sifive.com> In-Reply-To: From: Dave Airlie Date: Fri, 12 Apr 2024 11:54:25 +1000 Message-ID: Subject: Re: [PATCH v4 13/15] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT To: Arnd Bergmann Cc: Ard Biesheuvel , Samuel Holland , Thiago Jung Bauermann , Andrew Morton , linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kernel@vger.kernel.org, Linux-Arch , linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, Christoph Hellwig , loongarch@lists.linux.dev, amd-gfx@lists.freedesktop.org, Alex Deucher X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240411_185439_735969_F62D4E3D X-CRM114-Status: GOOD ( 32.61 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Thu, 11 Apr 2024 at 17:32, Arnd Bergmann wrote: > > On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote: > > On Thu, 11 Apr 2024 at 03:11, Samuel Holland wrote: > >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote: > >> > Samuel Holland 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. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1D731C4345F for ; Fri, 12 Apr 2024 01:54:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IaBfPKevopb3nukg+qX24s9M5x/iaBEa1+8OtJi+9Gg=; b=Sdv5FPnNvViTm6 WUQ5+KxfNg8fz3QNh3L+bpksqv7qmf5haUazwUS2fOAy/nZOt8sCCLyBQTf8tQTIbjxRHVE8L+LnE hmkT8lvwFM6kjoKhzdR4xcqtb6EDY9G4LkaGYToyVHTMHQsOsQCg+RL/xDQD56tN2QacdCnlKvfPe mIfCVQISqMAEvxltEMGtYb754EXfm8OOeb9VfSTe4bVcpIFVdfobSbR9tWax98XYBpNuTCmldWU+T fiqYFO365Fu0gHbuJo8V/T2Aq121qkHF0TjLraYmcEgNSY1rM3XuVfAkBxeOoQvBBtOOf97PSjtT9 UYxLNXDeWwC+d2fOoWhg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rv67n-0000000Ep6g-1woE; Fri, 12 Apr 2024 01:54:43 +0000 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rv67j-0000000Ep5q-2ov6; Fri, 12 Apr 2024 01:54:41 +0000 Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-346b94fa7ecso371111f8f.3; Thu, 11 Apr 2024 18:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712886876; x=1713491676; darn=lists.infradead.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y4vlt8TB9yDjErxa7aoPppj34TQs7XIg9OjF7nGdMbk=; b=abrPmGmvwiFXdCT7LZrjo/eORtEM+wJT15IpOVCrZvJw2cTKr9roMRufr0HLxbfBMd xs37RtvbmbtEeVEhauqIA3slcD+TFHE+GMcL462YnOBFeCWjxBEcC1jdKDTu4Y6Id5yQ 2dX5ois2/bWZvShhmq/UwW14eTSzk0fgXAkd5XzBIqBJdLOpJ9UcA2chbicYDLUICwjb Bi49vwbhXGwDdPTDBJAfwV6qCunNtOXJJ3vi32bHOxmDvqNlFk/EwJUg3WTZlnIfcFue bfWpDePao4JTn/7eWnsMkN0PYekSGhowE7xRRoLWPMwjhp4CPkACXlbgc+R331Plm/uP ChOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712886876; x=1713491676; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y4vlt8TB9yDjErxa7aoPppj34TQs7XIg9OjF7nGdMbk=; b=SbSVZ46j1NexLy6S2UximCudzyvMqWGxpqZA0d2ni3uz6M1Ee25/NY974DN8bEwmmk mWRaQ5U7pZ3+Y0q4eM8al1D0yu4sAHUVEdbiqhSpg9TNARd067T7OiTCMWl0WNk7vQTY oFIB7qsHyZIB/9UxwSnnXNOBvUOENp7qa70l+WFjDwpKT0JyF6p5BHDmhpECWxNoPsqw ROCqFUDrfVc2NLMPH4b7Ei0mTzFrkB+CjC36td9X9eXdSugA5x4ttoEAlQpjJGszFB1R Y4Lwonl6Bqr0UI/cAWuUzm+3wHN7Wuf0hfV9YmmS7VaQEY23JCVDvbmdaeIf5bHfL20/ GA9A== X-Forwarded-Encrypted: i=1; AJvYcCVwFn4s1IXE/K6psDNuCjFghq8EeGVgJfZIUFbqzF8lo6oBTF1CZg2ZPVyEUPwqKNs5qryFtklEKGxZzKweRi+Z2qcODw+Nejy9q8zEZwj8p1G183k3c1ucYZP3F60iwp1xjq+pcEhD75yYkt5BYoCqrU60ozk= X-Gm-Message-State: AOJu0Yz2glqX8mPtrcfvTZotIC1/xpWYzQ/fr7SFPjlK2qscmy+fB+Pn MTAgv+i7xbaZwzX1vL6DN4V0CVXalgPzUOW6Zsg1tPBecAokIkw5OcegIFrn8a3NigC/bRBhkic unRUjypAcoWWeAAlr4e5eemMiQtU= X-Google-Smtp-Source: AGHT+IH+PR4h3oVtQ8Ez0cRs6zyDvlUxECTYXxWqfVRSac34W79R5yeA3Zq4bIaDyQbovOeeCgfyqRUJHwPOnRqGQX0= X-Received: by 2002:a5d:474f:0:b0:33e:ca28:bb59 with SMTP id o15-20020a5d474f000000b0033eca28bb59mr856430wrs.57.1712886876424; Thu, 11 Apr 2024 18:54:36 -0700 (PDT) MIME-Version: 1.0 References: <20240329072441.591471-1-samuel.holland@sifive.com> <20240329072441.591471-14-samuel.holland@sifive.com> <87wmp4oo3y.fsf@linaro.org> <75a37a4b-f516-40a3-b6b5-4aa1636f9b60@sifive.com> <87wmp4ogoe.fsf@linaro.org> <4c8e63d6-ba33-47fe-8150-59eba8babf2d@sifive.com> In-Reply-To: From: Dave Airlie Date: Fri, 12 Apr 2024 11:54:25 +1000 Message-ID: Subject: Re: [PATCH v4 13/15] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT To: Arnd Bergmann Cc: Ard Biesheuvel , Samuel Holland , Thiago Jung Bauermann , Andrew Morton , linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kernel@vger.kernel.org, Linux-Arch , linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, Christoph Hellwig , loongarch@lists.linux.dev, amd-gfx@lists.freedesktop.org, Alex Deucher X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240411_185439_735969_F62D4E3D X-CRM114-Status: GOOD ( 32.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 11 Apr 2024 at 17:32, Arnd Bergmann wrote: > > On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote: > > On Thu, 11 Apr 2024 at 03:11, Samuel Holland wrote: > >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote: > >> > Samuel Holland 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E8311C4345F for ; Fri, 12 Apr 2024 01:55:27 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=BccNoe/o; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4VG05B1gpQz3vcD for ; Fri, 12 Apr 2024 11:55:26 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=BccNoe/o; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2a00:1450:4864:20::435; helo=mail-wr1-x435.google.com; envelope-from=airlied@gmail.com; receiver=lists.ozlabs.org) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4VG04M3WV3z3dDn for ; Fri, 12 Apr 2024 11:54:42 +1000 (AEST) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-343cfa6faf0so319959f8f.0 for ; Thu, 11 Apr 2024 18:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712886876; x=1713491676; darn=lists.ozlabs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y4vlt8TB9yDjErxa7aoPppj34TQs7XIg9OjF7nGdMbk=; b=BccNoe/oZFmzzaoFOFy7MfI1MjbWirpcVi+a7cSlm7+QAjkmvCZSJuRGR+N5MstXq3 zyJLlTEr5gjmRfPI+nMgzfH7/Ucwutx+efRPC+Fu3GG5jnFet7SudIVE+Mu7yjLwdeL/ v4Z3Q6Q43ANtc3uCzMaDwGhwb4+cG8BB5BSIMsHxcdwFNP8127TpOXJCB8o/6C4sxX+B YXcCTmnC0KKKz3SkneXyPbwZU1rUUkNeMOxtEyo8aEQXxivUtt0YDq7ZIS5yWp2S+0mg Hw0QlmlW7nJrB6/z79mvHS0CWiOmPLUit5TRYJQoEKZeFJ2NSox7174k2NvlKa3rTjOe vDVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712886876; x=1713491676; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y4vlt8TB9yDjErxa7aoPppj34TQs7XIg9OjF7nGdMbk=; b=RhWpg7+IqzVKrAMqjkC000BmXnKoYawFFv4BaWijNpZWQLhV3Ps3O99D+6/zk60vA1 v4uGjdzWK5Xn7aeSt9M9HOvkINmH1QZFvbZsE7gEp+wnwFXgUXr6meCkd+rURm1zvMC4 GOVVw1eNf60ZWk4sLf7BD2rGsh/jW1+nV6HmMQq+WgoNhOZqlj2Kfz3qbByAR4kYV+JT /eB07+gnW7zMexKfG6S72gnDfQt/bHkmBJaEEekaUFL2MxV33DsVXlb3wjBxLBdfrrxU FEKlDZvfYkOySw9wvhKXsUP1VWD+syW2caA3FFw9i7/cODXru32Q7LdXj75ktJsru0Cr zBHQ== X-Forwarded-Encrypted: i=1; AJvYcCUpeq2pAi5W7SclAS40xv4J8IY0kDsRMYmqp3azumOi1pEwDG5VkyDLe4mobTddRskVS3QlR9S/GrAaF3KVr2ieLBOT7Csnp7VbiIahVQ== X-Gm-Message-State: AOJu0YwGQ+aCt5Dps6Ghk5yk50iMDstYmAn17oA42ro/fKZNFhaIyCRc yp3AA7Gz4mqmoEU9nGxEKRGs01sNyHmKpQ1EueflRcyFKIu9HKLGaGhzMlQcXd1Ni0ql58IUwN2 4jR/Z36NG3g4mBvXr6bl9iKb2qjI= X-Google-Smtp-Source: AGHT+IH+PR4h3oVtQ8Ez0cRs6zyDvlUxECTYXxWqfVRSac34W79R5yeA3Zq4bIaDyQbovOeeCgfyqRUJHwPOnRqGQX0= X-Received: by 2002:a5d:474f:0:b0:33e:ca28:bb59 with SMTP id o15-20020a5d474f000000b0033eca28bb59mr856430wrs.57.1712886876424; Thu, 11 Apr 2024 18:54:36 -0700 (PDT) MIME-Version: 1.0 References: <20240329072441.591471-1-samuel.holland@sifive.com> <20240329072441.591471-14-samuel.holland@sifive.com> <87wmp4oo3y.fsf@linaro.org> <75a37a4b-f516-40a3-b6b5-4aa1636f9b60@sifive.com> <87wmp4ogoe.fsf@linaro.org> <4c8e63d6-ba33-47fe-8150-59eba8babf2d@sifive.com> In-Reply-To: From: Dave Airlie Date: Fri, 12 Apr 2024 11:54:25 +1000 Message-ID: Subject: Re: [PATCH v4 13/15] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT To: Arnd Bergmann Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux-Arch , Thiago Jung Bauermann , x86@kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Samuel Holland , Christoph Hellwig , amd-gfx@lists.freedesktop.org, loongarch@lists.linux.dev, Alex Deucher , Andrew Morton , linuxppc-dev@lists.ozlabs.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, 11 Apr 2024 at 17:32, Arnd Bergmann wrote: > > On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote: > > On Thu, 11 Apr 2024 at 03:11, Samuel Holland wrote: > >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote: > >> > Samuel Holland 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.