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 X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFFFEC2BB40 for ; Thu, 17 Dec 2020 08:44:05 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2D09223884 for ; Thu, 17 Dec 2020 08:44:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D09223884 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=uniontech.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 04F1D6E1F8; Thu, 17 Dec 2020 08:43:35 +0000 (UTC) Received: from regular1.263xmail.com (regular1.263xmail.com [211.150.70.205]) by gabe.freedesktop.org (Postfix) with ESMTPS id B9E3089A35 for ; Thu, 17 Dec 2020 01:07:06 +0000 (UTC) Received: from localhost (unknown [192.168.167.13]) by regular1.263xmail.com (Postfix) with ESMTP id 38BCE8D6; Thu, 17 Dec 2020 09:07:03 +0800 (CST) X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-ADDR-CHECKED4: 1 X-ANTISPAM-LEVEL: 2 X-SKE-CHECKED: 1 X-ABS-CHECKED: 1 Received: from firstlove-e500.uniontech.com (unknown [58.246.122.242]) by smtp.263.net (postfix) whith ESMTP id P20464T140379139880704S1608167222508574_; Thu, 17 Dec 2020 09:07:03 +0800 (CST) X-IP-DOMAINF: 1 X-UNIQUE-TAG: <0d6d81cf0b80932ae92a86ec7827e8ea> X-RL-SENDER: chenli@uniontech.com X-SENDER: chenli@uniontech.com X-LOGIN-NAME: chenli@uniontech.com X-FST-TO: christian.koenig@amd.com X-SENDER-IP: 58.246.122.242 X-ATTACHMENT-NUM: 0 X-System-Flag: 0 Date: Thu, 17 Dec 2020 09:07:09 +0800 Message-ID: <873605z1du.wl-chenli@uniontech.com> From: Chen Li To: Christian =?ISO-8859-1?Q?K=F6nig?= Subject: Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem In-Reply-To: <90b625e2-2409-d13b-2456-483ad4eef18f@amd.com> References: <877dpiz4sf.wl-chenli@uniontech.com> <4277816d-db00-7e81-a2fb-069aeee18e8b@amd.com> <875z51zwsq.wl-chenli@uniontech.com> <90b625e2-2409-d13b-2456-483ad4eef18f@amd.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-Mailman-Approved-At: Thu, 17 Dec 2020 08:43:32 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alex Deucher , Chen Li , dri-devel@lists.freedesktop.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, 16 Dec 2020 22:19:11 +0800, Christian K=F6nig wrote: > = > Am 16.12.20 um 14:48 schrieb Chen Li: > > On Wed, 16 Dec 2020 15:59:37 +0800, > > Christian K=F6nig wrote: > >> Am 16.12.20 um 06:41 schrieb Chen Li: > >>> When using e8860(gcn1) on arm64, the kernel crashed on drm/radeon: > >>> [SNIP] > >>> Obviously, the __memset call is generated by gcc(8.3.1). It optimizes > >>> this for loop into memset. But this may break, because dest here is > >>> cpu_addr mapped to io mem. So, just invoke `memset_io` directly, which > >>> do solve the problem here. > >> Well interesting problem you stumbled over here, but the solution is q= uite a > >> hack. > > Hi, Christian. I'm not sure why this change is a hack here. I cannot se= e the problem and wll be grateful if you give more explainations. > = > __memset is supposed to work on those addresses, otherwise you can't use = the > e8860 on your arm64 system. If __memset is supposed to work on those adresses, why this commit(https://= github.com/torvalds/linux/commit/ba0b2275a6781b2f3919d931d63329b5548f6d5f) = is needed? (I also notice drm/radeon didn't take this change though) just o= ut of curiosity. > = > Replacing the the direct write in the kernel with calls to writel() or > memset_io() will fix that temporary, but you have a more general problem = here. = I cannot see what's the more general problem here :( u mean performance? > >> For amdgpu I suggest that we allocate the UVD message in GTT instead o= f VRAM > >> since we don't have the hardware restriction for that on the new gener= ations. > >> = > > Thanks, I will try to dig into deeper. But what's the "hardware restric= tion" meaning here? I'm not familiar with video driver stack and amd gpu, s= orry. > = > On older hardware (AGP days) the buffer had to be in VRAM (MMIO) memory, = but on > modern system GTT (system memory) works as well. IIUC, e8860 can use amdgpu(I use radeon now) beause its device id 6822 is i= n amdgpu's table. But I cannot tell whether e8860 has iommu, and I cannot f= ind iommu from lspci, so graphics translation table may not work here? > = > >> For radeon I think the better approach would be to convert the direct = memory > >> writes into calls to writel(). > > Ok, so you mean the more proper way is to use writel instead of memset_= io? > = > Well, it is a start. But I'm not sure if you will ever get that hardware = working > with this CPU. > = > >> BTW: How does userspace work on arm64 then? The driver stack usually o= nly works > >> if mmio can be mapped directly. > > I also post two usespace issue on mesa, and you may be interested with = them: > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= itlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fissues%2F3954&data=3D04%7C01%= 7Cchristian.koenig%40amd.com%7Cd6ff52383a454a6dc03108d8a1c94dc1%7C3dd8961fe= 4884e608e11a82d994e183d%7C0%7C0%7C637437233268588747%7CUnknown%7CTWFpbGZsb3= d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000= &sdata=3DRDESyzYBB3ql2GgBigsYf%2Fx2g6zwCq%2Fy8HQ0AAMtX90%3D&reserve= d=3D0 > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= itlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fissues%2F3951&data=3D04%7C01%= 7Cchristian.koenig%40amd.com%7Cd6ff52383a454a6dc03108d8a1c94dc1%7C3dd8961fe= 4884e608e11a82d994e183d%7C0%7C0%7C637437233268588747%7CUnknown%7CTWFpbGZsb3= d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000= &sdata=3DY5f9Ki%2FQ8G4zn3MjLVG7yiLLCxbhTyNelZj36hAuXQY%3D&reserved= =3D0 > > I paste some virtual memory map in userspace there. (and the two proble= ms do bother me quite a long time.) > = > I don't really see a solution for those problems. > = > See it is perfectly valid for an application to memset/memcpy on mmaped M= MIO > space which comes from OpenGL or Vulkan. > = > So your CPU simply won't work with the hardware. We could work around tha= t with > a couple of hacks, but this is a pretty much general problem. > = > Regards, > Christian. = Thanks! Can you provid some details about these hacks? Should I post anothe= r issue on the mail list? = _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel