From owner-freebsd-x11@freebsd.org Tue Apr 28 21:19:03 2020 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 246B12C5628; Tue, 28 Apr 2020 21:19:03 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49BZJl06L1z4Jxw; Tue, 28 Apr 2020 21:19:03 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id D335B1E1E6; Tue, 28 Apr 2020 21:19:02 +0000 (UTC) From: Jan Beich To: Alexey Dokuchaev via freebsd-x11 Cc: Niclas Zeising , Alexey Dokuchaev , x11@freebsd.org Subject: Re: GPU firmware naming and problems with loading References: <20200421090909.GB13384@regency.nsu.ru> <8990dbd6-65b7-81f4-e0c5-4541e34afee2@freebsd.org> <20200421130955.GA8165@regency.nsu.ru> <749e8db2-8dd8-3ad8-dbee-332bb2a7742b@freebsd.org> <20200424154229.GA11678@regency.nsu.ru> <20200428071934.GA74382@regency.nsu.ru> Date: Tue, 28 Apr 2020 23:18:58 +0200 In-Reply-To: <20200428071934.GA74382@regency.nsu.ru> (Alexey Dokuchaev via freebsd-x's message of "Tue, 28 Apr 2020 14:19:34 +0700") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 21:19:03 -0000 Alexey Dokuchaev via freebsd-x11 writes: > On Fri, Apr 24, 2020 at 10:42:29PM +0700, Alexey Dokuchaev wrote: > >> On Thu, Apr 23, 2020 at 10:42:22PM +0200, Niclas Zeising wrote: >> > On 2020-04-21 15:09, Alexey Dokuchaev wrote: >> > > ... >> > >Why is it trying to load TAHITI modules is another question. >> >=20 >> > I don't know why it tries to load TAHITI, I'll try to figure more >> > out, but in general, the firmware selection code is from the original >> > source, so it should be the same elsewhere. Does TAHITI load with >> > drm-legacy-kmod? >>=20 >> Nope. This is for legacy (kldstat | grep radeon_): >> 41 1 0xffffffff81b31000 2385 radeon_ARUBA_pfp_bin.ko >> 42 1 0xffffffff81b34000 2383 radeon_ARUBA_me_bin.ko >> 43 1 0xffffffff81b37000 1985 radeon_ARUBA_rlc_bin.ko >>=20 >> This is for drm-{current,devel}-kmod (surprisingly, couple of my later >> attempts to "kldload radeonkms" did not hang the laptop, but the very >> latest still did): >>=20 >> 48 1 0xffffffff819d3000 2385 radeon_ARUBA_pfp_bin.ko >> 49 1 0xffffffff819d6000 2383 radeon_ARUBA_me_bin.ko >> 50 1 0xffffffff819d9000 1985 radeon_ARUBA_rlc_bin.ko >> 51 1 0xffffffff819db000 35ba7 radeon_TAHITI_uvd_bin.ko >> 52 1 0xffffffff81a11000 beb7 radeon_TAHITI_vce_bin.ko >>=20 >> Both drm-fbsd{11.2,12.0}-kmod still lock up the laptop, but the logs >> show they do load TAHITI modules as well. > > Interestingly, Gentoo Wiki lists both ARUBA and TAHITI firmware as > needed for NI/ARUBA: > > https://wiki.gentoo.org/wiki/Radeon > > Unfortunately, it's unclear if that requirement predates Linux 4.14 (or > even some older version) or not. Maybe drm-legacy-kmod only needs > and thus loads ARUBA files, while drm-{current,devel}-kmod need both. TAHITI firmware on ARUBA is probably due to the following changes: https://github.com/torvalds/linux/commit/a918efab631a # TAHITI_vce https://github.com/torvalds/linux/commit/f2ba57b5eab8 # TAHITI_uvd For example, $ rg TAHITI_vce drivers/gpu/drm/radeon/radeon_vce.c 41:#define FIRMWARE_TAHITI "radeon/TAHITI_vce.bin" $ rg -B6 FIRMWARE_TAHITI drivers/gpu/drm/radeon/radeon_vce.c 67- switch (rdev->family) { 68- case CHIP_TAHITI: 69- case CHIP_PITCAIRN: 70- case CHIP_VERDE: 71- case CHIP_OLAND: 72- case CHIP_ARUBA: 73: fw_name =3D FIRMWARE_TAHITI; $ git blame drivers/gpu/drm/radeon/radeon_vce.c | fgrep 'case CHIP_ARUBA' a918efab631a5 (Christian K=C3=B6nig 2015-05-11 22:01:53 +0200 72) = case CHIP_ARUBA: $ git log -1 -p a918efab631a5 | fgrep -A3 CHIP_ARUBA + case CHIP_ARUBA: + fw_name =3D FIRMWARE_TAHITI; + break; +