From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Tue, 12 Nov 2019 14:06:31 +0000 Subject: Re: [PATCH] video: fbdev: atyfb: only use ioremap_uc() on i386 and ia64 Message-Id: <20191112140631.GA10922@lst.de> List-Id: References: <20191111192258.2234502-1-arnd@arndb.de> <20191112105507.GA7122@lst.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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.