linux-kernel - Re: [PATCH v2] drm/amdgpu: add dce6 drm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <00d08df9-346c-4710-8c08-615ba78b1bfc@mailbox.org>
Date: Wed, 25 Sep 2024 09:55:58 +0200
From: Michel Dänzer <michel.daenzer@...lbox.org>
To: Alex Deucher <alexdeucher@...il.com>,
 Jocelyn Falempe <jfalempe@...hat.com>
Cc: Lu Yao <yaolu@...inos.cn>, ckoenig.leichtzumerken@...il.com,
 daniel@...ll.ch, Xinhui.Pan@....com, airlied@...il.com,
 alexander.deucher@....com, amd-gfx@...ts.freedesktop.org,
 christian.koenig@....com, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, srinivasan.shanmugam@....com,
 sunil.khatri@....com
Subject: Re: [PATCH v2] drm/amdgpu: add dce6 drm_panic support

On 2024-09-24 16:02, Alex Deucher wrote:
> On Fri, Sep 20, 2024 at 11:36 AM Jocelyn Falempe <jfalempe@...hat.com> wrote:
>> On 17/09/2024 15:21, Alex Deucher wrote:
>>> On Mon, Aug 12, 2024 at 2:10 AM Lu Yao <yaolu@...inos.cn> wrote:
>>>>
>>>> Add support for the drm_panic module, which displays a pretty user
>>>> friendly message on the screen when a Linux kernel panic occurs.
>>>>
>>>> Signed-off-by: Lu Yao <yaolu@...inos.cn>
>>>
>>> Patch looks good to me.  Any chance you want to convert the other
>>> non-DC dce files (dce_v8_0.c, dce_v10_0.c, dce_v11_0.c) while you are
>>> at it?
>>
>> I've made a similar patch in amdgpu_dm_plane.c, and it works on a Radeon
>> pro w6400.
>> But it only works when I'm in a VT terminal (so the framebuffer is
>> linear and CPU accessible).
>> When under Gnome/Wayland, the flag AMDGPU_GEM_CREATE_NO_CPU_ACCESS is
>> set, so that means I can't vmap it ?
> 
> It just means that the application does not need CPU access.  Whether
> or not the CPU can access the buffer or not depends on the size of the
> PCI BAR.  E.g., if the driver or bios has resized the PCI BAR, then
> the CPU can access the entire BAR, but if not you are generally
> limited to the first 256M of framebuffer.

FWIW, it's also possible to access all of VRAM via MMIO indirect registers. That'll be slower than a direct CPU map, it might be acceptable for drm_panic though, at least as a fallback.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast