Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751046AbbDPTTg (ORCPT ); Thu, 16 Apr 2015 15:19:36 -0400 Received: from mail-lb0-f171.google.com ([209.85.217.171]:34580 "EHLO mail-lb0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751207AbbDPTT2 (ORCPT ); Thu, 16 Apr 2015 15:19:28 -0400 MIME-Version: 1.0 In-Reply-To: <1429146083.1899.94.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> <1429146083.1899.94.camel@palomino.walls.org> From: Andy Lutomirski Date: Thu, 16 Apr 2015 12:19:05 -0700 Message-ID: Subject: Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR To: Andy Walls Cc: Jean-Christophe Plagniol-Villard , Roland Dreier , Linux Fbdev development list , Juergen Gross , X86 ML , Mauro Carvalho Chehab , Mike Marciniszyn , Suresh Siddha , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Borislav Petkov , Sean Hefty , Rickard Strandqvist , Hal Rosenstock , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Mel Gorman , Vlastimil Babka , "Luis R. Rodriguez" , Toshi Kani , Thomas Gleixner , Dave Hansen , Davidlohr Bueso , linux-media@vger.kernel.org, Ingo Molnar 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: 3763 Lines: 99 On Apr 15, 2015 6:54 PM, "Andy Walls" wrote: > > On Wed, 2015-04-15 at 17:58 -0700, Andy Lutomirski wrote: > > 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. > > Understood. > > > > 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. > > Maybe ioremap the decoder register area as UC, and ioremap the rest of > the decoder region to WC. (Does that suck up too many PAT resources? PAT resources are unlimited. > Then add PCI reads following any sort of singleton PCI writes in the WC > region. I assume PCI rules about write postings before reads still > apply when WC is set. > I think we need sfence, too, but that's easy. We also lose the write sizes. That is, adjacent writes get combined. Maybe that's okay. > > > > > > 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. > > Yeah. > > > If the only thing that really wants WC is the esoteric framebuffer > > thing, > > That appears to be it. > > > 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? > > That's on the table in my mind. Not sure if it is the friendliest thing > to do to users. Quite honestly though, modern graphics cards have much > better ouput resolution and performance. Anyone with a modern system > really should be using one. (i.e. MythTV gave up on support for PVR-350 > output for video playback years ago in May 2010.) > > > BTW, my 2005 system with multiple conventional PCI slots in it shows a > 'pat' flag in /proc/cpuinfo. (AMD Athlon(tm) 64 X2 Dual Core Processor > 4200+) I didn't know it was considered "new". :) Tons of CPUs have that ability, but we often turn it off due to errata on older CPUs. --Andy > > Regards, > 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/