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: <9f86a94a-02da-496d-81cd-5a2306520c6d@redhat.com>
Date: Tue, 1 Oct 2024 14:43:01 +0200
From: Jocelyn Falempe <jfalempe@...hat.com>
To: Alex Deucher <alexdeucher@...il.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 25/09/2024 10:33, Jocelyn Falempe wrote:
> On 24/09/2024 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.
> 
> I tried to use ttm_bo_kmap() anyway, it returns a valid virtual address, 
> but writing to it has no effect on the display.
>>
>>>
>>> Also I don't know if there is a similar way to disable
>>> tiling/compression on this hardware.
>>
>> UNP_GRPH_CONTROL on chips with DCE display hardware and
>> DCSURF_ADDR_CONFIG and DCSURF_TILING_CONFIG on DCN display hardware.

I've now a working Prototype on a Radeon pro W6400.

Here is what I do to disable tiling:

REG_UPDATE(DCHUBP_REQ_SIZE_CONFIG, SWATH_HEIGHT, 0);
REG_UPDATE(DCSURF_TILING_CONFIG, SW_MODE, DC_SW_LINEAR);

REG_UPDATE_6(DCSURF_SURFACE_CONTROL,
		PRIMARY_SURFACE_DCC_EN, 0,
		PRIMARY_SURFACE_DCC_IND_BLK, 0,
		PRIMARY_SURFACE_DCC_IND_BLK_C, 0,
		SECONDARY_SURFACE_DCC_EN, 0,
		SECONDARY_SURFACE_DCC_IND_BLK, 0,
		SECONDARY_SURFACE_DCC_IND_BLK_C, 0);

I also need to call this, to refresh the display:

hubp->funcs->hubp_program_surface_flip_and_addr(hubp, 
&dc_plane_state->address, dc_plane_state->flip_immediate);

And I use a modified version of amdgpu_ttm_access_memory() to write to 
the framebuffer.

I will send a patch when I've time to make a clean version.

Best regards,

-- 

Jocelyn