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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 2A0C8C282C5 for ; Thu, 24 Jan 2019 16:04:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D17C1217D7 for ; Thu, 24 Jan 2019 16:04:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728835AbfAXQEo (ORCPT ); Thu, 24 Jan 2019 11:04:44 -0500 Received: from mail.netline.ch ([148.251.143.178]:45214 "EHLO netline-mail3.netline.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728815AbfAXQEm (ORCPT ); Thu, 24 Jan 2019 11:04:42 -0500 Received: from localhost (localhost [127.0.0.1]) by netline-mail3.netline.ch (Postfix) with ESMTP id ED8952A6056; Thu, 24 Jan 2019 17:04:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at netline-mail3.netline.ch Received: from netline-mail3.netline.ch ([127.0.0.1]) by localhost (netline-mail3.netline.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LeWIp6H_pu1C; Thu, 24 Jan 2019 17:04:39 +0100 (CET) Received: from thor (39.1.199.178.dynamic.wline.res.cust.swisscom.ch [178.199.1.39]) by netline-mail3.netline.ch (Postfix) with ESMTPSA id 7E6052A6054; Thu, 24 Jan 2019 17:04:38 +0100 (CET) Received: from [::1] by thor with esmtp (Exim 4.92-RC4) (envelope-from ) id 1gmhUc-0002p1-2E; Thu, 24 Jan 2019 17:04:38 +0100 Subject: Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86 To: Ard Biesheuvel , "Koenig, Christian" Cc: Maxime Ripard , Michael Ellerman , Will Deacon , Linux Kernel Mailing List , amd-gfx list , "Zhang, Jerry" , Christoph Hellwig , David Airlie , "Huang, Ray" , dri-devel , Alex Deucher , "Deucher, Alexander" , Sean Paul , linux-arm-kernel References: <850b6aee-0040-c333-b125-45211c18ada5@daenzer.net> <20190123071521.GB20526@infradead.org> <20190123164428.GA9367@infradead.org> <20190124091316.GA22796@infradead.org> <953e5e5f-5d47-d6df-40df-c8c94db5447f@amd.com> <57590a48-4629-e2a1-8673-ce9eb2ec210b@amd.com> <40ad3ae7-9970-0cb9-d35c-05e128f83820@amd.com> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Openpgp: preference=signencrypt Autocrypt: addr=michel@daenzer.net; prefer-encrypt=mutual; keydata= mQGiBDsehS8RBACbsIQEX31aYSIuEKxEnEX82ezMR8z3LG8ktv1KjyNErUX9Pt7AUC7W3W0b LUhu8Le8S2va6hi7GfSAifl0ih3k6Bv1Itzgnd+7ZmSrvCN8yGJaHNQfAevAuEboIb+MaVHo 9EMJj4ikOcRZCmQWw7evu/D9uQdtkCnRY9iJiAGxbwCguBHtpoGMxDOINCr5UU6qt+m4O+UD /355ohBBzzyh49lTj0kTFKr0Ozd20G2FbcqHgfFL1dc1MPyigej2gLga2osu2QY0ObvAGkOu WBi3LTY8Zs8uqFGDC4ZAwMPoFy3yzu3ne6T7d/68rJil0QcdQjzzHi6ekqHuhst4a+/+D23h Za8MJBEcdOhRhsaDVGAJSFEQB1qLBACOs0xN+XblejO35gsDSVVk8s+FUUw3TSWJBfZa3Imp V2U2tBO4qck+wqbHNfdnU/crrsHahjzBjvk8Up7VoY8oT+z03sal2vXEonS279xN2B92Tttr AgwosujguFO/7tvzymWC76rDEwue8TsADE11ErjwaBTs8ZXfnN/uAANgPLQjTWljaGVsIERh ZW56ZXIgPG1pY2hlbEBkYWVuemVyLm5ldD6IXgQTEQIAHgUCQFXxJgIbAwYLCQgHAwIDFQID AxYCAQIeAQIXgAAKCRBaga+OatuyAIrPAJ9ykonXI3oQcX83N2qzCEStLNW47gCeLWm/QiPY jqtGUnnSbyuTQfIySkK5AQ0EOx6FRRAEAJZkcvklPwJCgNiw37p0GShKmFGGqf/a3xZZEpjI qNxzshFRFneZze4f5LhzbX1/vIm5+ZXsEWympJfZzyCmYPw86QcFxyZflkAxHx9LeD+89Elx bw6wT0CcLvSv8ROfU1m8YhGbV6g2zWyLD0/naQGVb8e4FhVKGNY2EEbHgFBrAAMGA/0VktFO CxFBdzLQ17RCTwCJ3xpyP4qsLJH0yCoA26rH2zE2RzByhrTFTYZzbFEid3ddGiHOBEL+bO+2 GNtfiYKmbTkj1tMZJ8L6huKONaVrASFzLvZa2dlc2zja9ZSksKmge5BOTKWgbyepEc5qxSju YsYrX5xfLgTZC5abhhztpYhGBBgRAgAGBQI7HoVFAAoJEFqBr45q27IAlscAn2Ufk2d6/3p4 Cuyz/NX7KpL2dQ8WAJ9UD5JEakhfofed8PSqOM7jOO3LCA== Message-ID: <66a7aa82-3ebd-55c3-0263-ee9694294896@daenzer.net> Date: Thu, 24 Jan 2019 17:04:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-01-24 12:45 p.m., Ard Biesheuvel wrote: > On Thu, 24 Jan 2019 at 12:37, Koenig, Christian > wrote: >> Am 24.01.19 um 12:26 schrieb Ard Biesheuvel: >>> On Thu, 24 Jan 2019 at 12:23, Koenig, Christian >>> wrote: >>>> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel: >>>>> [SNIP] >>>>> This is *exactly* my point the whole time. >>>>> >>>>> The current code has >>>>> >>>>> static inline bool drm_arch_can_wc_memory(void) >>>>> { >>>>> #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE) >>>>> return false; >>>>> >>>>> which means the optimization is disabled *unless the system is >>>>> non-cache coherent* >>>>> >>>>> So if you have reports that the optimization works on some PowerPC, it >>>>> must be non-cache coherent PowerPC, because that is the only place >>>>> where it is enabled in the first place. >>>>> >>>>>> The only problematic here actually seems to be ARM, so you should >>>>>> probably just add an "#ifdef .._ARM return false;". >>>>>> >>>>> ARM/arm64 does not have a Kconfig symbol like >>>>> CONFIG_NOT_COHERENT_CACHE, so we can only disable it everywhere. If >>>>> there are non-coherent ARM systems that are currently working in the >>>>> same way as those non-coherent PowerPC systems, we will break them by >>>>> doing this. >>>> Summing the things I've read so far for ARM up I actually think it >>>> depends on a runtime configuration and not on compile time one. >>>> >>>> So the whole idea of providing the device to the drm_*_can_wc_memory() >>>> function isn't so far fetched. >>>> >>> Thank you. >>> >>>> But for now I do prefer working and slightly slower system over broken >>>> one, so I think we should just disable this on ARM for now. >>>> >>> Again, this is not about non-cache coherent being slower without the >>> optimization, it is about non-cache coherent likely not working *at >>> all* unless the optimization is enabled. >> >> As Michel tried to explain this CAN'T happen. The optimization is a >> purely optional request from userspace. >> > > Right. > > So in that case, we can assume that the following test > > static inline bool drm_arch_can_wc_memory(void) > { > #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE) > return false; > > is bogus, and it was just unnecessary caution on the part of the > author to disregard non-cache coherent devices. This is driver-independent core code, meaning "non-snooped PCIe transfers don't work on cache coherent PPC". It doesn't imply anything about whether or not amdgpu or any other driver works on non-cache-coherent PPC in general. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer