Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756497AbbDPA6o (ORCPT ); Wed, 15 Apr 2015 20:58:44 -0400 Received: from mail-la0-f42.google.com ([209.85.215.42]:34770 "EHLO mail-la0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751756AbbDPA6g (ORCPT ); Wed, 15 Apr 2015 20:58:36 -0400 MIME-Version: 1.0 In-Reply-To: <1429142387.1899.57.camel@palomino.walls.org> References: <20150410171750.GA5622@wotan.suse.de> <1428695379.6646.69.camel@misato.fc.hp.com> <20150410210538.GB5622@wotan.suse.de> <1428699490.21794.5.camel@misato.fc.hp.com> <20150411012938.GC5622@wotan.suse.de> <20150413174938.GE5622@wotan.suse.de> <1429137531.1899.28.camel@palomino.walls.org> <1429142387.1899.57.camel@palomino.walls.org> From: Andy Lutomirski Date: Wed, 15 Apr 2015 17:58:14 -0700 Message-ID: Subject: Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR To: Andy Walls Cc: "Luis R. Rodriguez" , 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 , Borislav Petkov , Mel Gorman , Vlastimil Babka , Davidlohr Bueso , Dave Hansen , Jean-Christophe Plagniol-Villard , Thomas Gleixner , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Linux Fbdev development list , linux-media@vger.kernel.org, X86 ML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2241 Lines: 53 On Wed, Apr 15, 2015 at 4:59 PM, Andy Walls wrote: > On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote: >> On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls wrote: > >> > >> >> IMO the right solution would be to avoid ioremapping the whole bar at >> startup. Instead ioremap pieces once the driver learns what they are. >> This wouldn't have any of these problems -- you'd ioremap() register >> regions and you'd ioremap_wc() the framebuffer once you find it. If >> there are regions of unknown purpose, just don't map them all. >> >> Would this be feasible? > > Feasible? Maybe. > > Worth the time and effort for end-of-life, convential PCI hardware so I > can have an optimally performing X display on a Standard Def Analog TV > screen? Nope. I don't have that level of nostalgia. > The point is actually to let us unexport or delete mtrr_add. We can either severely regress performance on ivtv on PAT-capable hardware if we naively switch it to arch_phys_wc_add or we can do something else. The something else remains to be determined. > > We sort of know where some things are in the MMIO space due to > experimentation and past efforts examining the firmware binary. > > Documentation/video4linux/cx2341x/fw-*.txt documents some things. The > driver code actually codifies a little bit more knowledge. > > The driver code for doing transfers between host and card is complex and > fragile with some streams that use DMA, other streams that use PIO, > digging VBI data straight out of card memory, and scatter-gather being > broken on newer firmwares. Playing around with ioremapping will be hard > to get right and likely cause something in the code to break for the > primary use case of the ivtv supported cards. Ick. If the only thing that really wants WC is the esoteric framebuffer thing, could we just switch to arch_phys_wc_add and assume that no one will care about the regression on new CPUs with ivtv cards? --Andy -- 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/