Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756788AbbDUWqK (ORCPT ); Tue, 21 Apr 2015 18:46:10 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53749 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755879AbbDUWqG (ORCPT ); Tue, 21 Apr 2015 18:46:06 -0400 Date: Wed, 22 Apr 2015 00:46:01 +0200 From: "Luis R. Rodriguez" To: Andy Lutomirski , jgunthorpe@obsidianresearch.com, mike.marciniszyn@intel.com, infinipath@intel.com, linux-rdma@vger.kernel.org, awalls@md.metrocast.net Cc: linux-rdma@vger.kernel.org, Toshi Kani , "H. Peter Anvin" , Ingo Molnar , "linux-kernel@vger.kernel.org" , Hal Rosenstock , Sean Hefty , Suresh Siddha , Rickard Strandqvist , Mike Marciniszyn , Roland Dreier , Juergen Gross , Mauro Carvalho Chehab , Andy Walls , Borislav Petkov , Mel Gorman , Vlastimil Babka , Davidlohr Bueso , Dave Hansen , Jean-Christophe Plagniol-Villard , Thomas Gleixner , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Linux Fbdev development list , linux-media@vger.kernel.org, X86 ML , mcgrof@do-not-panic.com Subject: Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR Message-ID: <20150421224601.GY5622@wotan.suse.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2474 Lines: 52 On Wed, Apr 15, 2015 at 01:42:47PM -0700, Andy Lutomirski wrote: > On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez wrote: > > > c) ivtv: the driver does not have the PCI space mapped out separately, and > > in fact it actually does not do the math for the framebuffer, instead it lets > > the device's own CPU do that and assume where its at, see > > ivtvfb_get_framebuffer() and CX2341X_OSD_GET_FRAMEBUFFER, it has a get > > but not a setter. Its not clear if the firmware would make a split easy. > > We'd need ioremap_ucminus() here too and __arch_phys_wc_add(). > > > > IMO this should be conceptually easy to split. Once we get the > framebuffer address, just unmap it (or don't prematurely map it) and > then ioremap the thing. Side note to ipath driver folks: as reviewed with Andy Walls, the ivtv driver cannot easily be ported to use PAT so we are evaluating simply removing write-combing from that driver on future kernels. > > > From the beginning it seems only framebuffer devices used MTRR/WC, lately it > > seems infiniband drivers also find good use for for it for PIO TX buffers to > > blast some sort of data, in the future I would not be surprised if other > > devices found use for it. > > IMO the Infiniband maintainers should fix their code. Especially in > the server space, there aren't that many MTRRs to go around. I wrote > arch_phys_wc_add in the first place because my server *ran out of > MTRRs*. > > Hey, IB people: can you fix your drivers to use arch_phys_wc_add > (which is permitted to be a no-op) along with ioremap_wc? Your users ipath driver maintainers: The ipath driver is one of two drivers left to convert over to arch_phys_wc_add(). MTRR use is being deprecated, and its use is actually highly discouraged now that we have proper PAT implemenation on Linux. Since we are talking about annotating the qib driver as "known to be broken without PAT" and since the ipath driver needs considerable work to be ported to use PAT (the userspace register is just one area) I wanted to review if we can just remove MTRR use on the ipath driver and annotate write-combining with PAT as a TODO item. This would help a lot in our journey to bury MTRR use. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/