Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp572391ybc; Tue, 12 Nov 2019 06:07:45 -0800 (PST) X-Google-Smtp-Source: APXvYqxOAMBLHwNk7oaD3qFoxDmH4vuKglhW67kXiDZAARUu16GmG+ThBjzOPvhEMeAWsgAtikJD X-Received: by 2002:a17:906:d143:: with SMTP id br3mr28610243ejb.215.1573567665522; Tue, 12 Nov 2019 06:07:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573567665; cv=none; d=google.com; s=arc-20160816; b=QjloX8iWuZzRKb0o1E09ur7mnLbsizsHtmQ37wmMZgJZ0aS2k6uYYBr7yXVc2ssC7a bsTheoTXvCGaj7Q4vt9Z62Tpx/N9IRhubvtUzGIR6N14CnP1XJV45fLKqqfP1oPjrchb K20gN8QVkC7560CzQmtt84YB8u9vvqYcsuo/moDkVdXluHxnJdl66va9jDyd1eC6l7DS EITQDknudysQEm5jVKgXFv2XAaZ6Pf3s1AV44eSdDI2QGbD9WP2tDsoxpqoqD90VPTeh yZPvAr2yEx1eWqqwcAUaXjOrQBs4NVGPWCkgS4NPEnv3PI7jZqFeUFYXNwYiipB21ytd xlFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=9jAq+AHfzZvEjaFhqWSNfYdlv+zXlLbspL56VcVJSII=; b=cXUOeRQJEaQP9NoQlXDCWF6DBPO/4+X88mq8PGsTZqBgSEja9jtKOrydzmknXSe75o bzZfFnoXgZLilWgl1U4WvdxPiWh9igqlBuFIkkS9dUkDrK33wbzxM53HypRw8UVw+6Ek Ntk7Ws9qddTGy+4KhefvQ3ZY3rTyWqboQvgy2/csEBrLNp3qHQDd7sFsR+CjfOMLaQXl bbCdpCYMnXPtvZW2K5waYS+28q0FJkl+MnfwPdYiZPCFKtUQx/qnPfATWRyyg4QDWi9v GIA1c/z4UAITafi/yZzL5ovbL3joulqCl4C3naQ6QldPd32ecRKUm1er8JjCnuKbZoVJ NkoQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y51si13709310edb.29.2019.11.12.06.07.18; Tue, 12 Nov 2019 06:07:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727083AbfKLOGh (ORCPT + 99 others); Tue, 12 Nov 2019 09:06:37 -0500 Received: from verein.lst.de ([213.95.11.211]:55964 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726497AbfKLOGh (ORCPT ); Tue, 12 Nov 2019 09:06:37 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 4587368BE1; Tue, 12 Nov 2019 15:06:32 +0100 (CET) Date: Tue, 12 Nov 2019 15:06:31 +0100 From: Christoph Hellwig To: Daniel Vetter Cc: Christoph Hellwig , Arnd Bergmann , Bartlomiej Zolnierkiewicz , X86 ML , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , linux-ia64@vger.kernel.org, Tony Luck , Fenghua Yu , Maarten Lankhorst , Souptick Joarder , dri-devel , Linux Fbdev development list , Linux Kernel Mailing List , Luis Chamberlain , Tuowen Zhao , Mika Westerberg , Andy Shevchenko Subject: Re: [PATCH] video: fbdev: atyfb: only use ioremap_uc() on i386 and ia64 Message-ID: <20191112140631.GA10922@lst.de> References: <20191111192258.2234502-1-arnd@arndb.de> <20191112105507.GA7122@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 12, 2019 at 02:04:16PM +0100, Daniel Vetter wrote: > Wut ... Maybe I'm missing something, but from how we use mtrr in other > gpu drivers it's a) either you use MTRR because that's all you got or > b) you use pat. Mixing both sounds like a pretty bad idea, since if > you need MTRR for performance (because you dont have PAT) then you > can't fix the wc with the PAT-based ioremap_uc. And if you have PAT, > then you don't really need an MTRR to get wc. > > So I'd revert this patch from Luis and ... Sounds great to me.. > ... apply this one. Since the same reasoning should apply to anything > that's running on any cpu with PAT. Can you take a look at "mfd: intel-lpss: Use devm_ioremap_uc for MMIO" in linux-next, which also looks rather fishy to me? Can't we use the MTRR APIs to override the broken BIOS MTRR setup there as well? With that we could kill ioremap_uc entirely.