Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756523AbbDPCBe (ORCPT ); Wed, 15 Apr 2015 22:01:34 -0400 Received: from proofpoint-cluster.metrocast.net ([65.175.128.136]:46574 "EHLO proofpoint-cluster.metrocast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751665AbbDPCB0 (ORCPT ); Wed, 15 Apr 2015 22:01:26 -0400 Message-ID: <1429146457.1899.99.camel@palomino.walls.org> Subject: Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR From: Andy Walls To: "Luis R. Rodriguez" Cc: Hyong-Youb Kim , netdev@vger.kernel.org, Andy Lutomirski , 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@linux.intel.com, plagnioj@jcrosoft.com, tglx@linutronix.de, Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= , linux-fbdev@vger.kernel.org, linux-media@vger.kernel.org, x86@kernel.org Date: Wed, 15 Apr 2015 21:07:37 -0400 In-Reply-To: <20150415235816.GG5622@wotan.suse.de> References: <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> <20150415235816.GG5622@wotan.suse.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-16_01:2015-04-15,2015-04-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504160017 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3252 Lines: 70 On Thu, 2015-04-16 at 01:58 +0200, Luis R. Rodriguez wrote: > Hey Andy, thanks for your review, adding Hyong-Youb Kim for review of the > full range ioremap_wc() idea below. > > On Wed, Apr 15, 2015 at 06:38:51PM -0400, Andy Walls wrote: > > Hi All, > > > > On Mon, 2015-04-13 at 19:49 +0200, Luis R. Rodriguez wrote: > > > From the beginning it seems only framebuffer devices used MTRR/WC, > > [snip] > > > The ivtv device is a good example of the worst type of > > > situations and these days. So perhap __arch_phys_wc_add() and a > > > ioremap_ucminus() might be something more than transient unless hardware folks > > > get a good memo or already know how to just Do The Right Thing (TM). > > > > Just to reiterate a subtle point, use of the ivtvfb is *optional*. A > > user may or may not load it. When the user does load the ivtvfb driver, > > the ivtv driver has already been initialized and may have functions of > > the card already in use by userspace. > > I suspected this and its why I note that a rewrite to address a clean > split with separate ioremap seems rather difficult in this case. > > > Hopefully no one is trying to use the OSD as framebuffer and the video > > decoder/output engine for video display at the same time. > > Worst case concern I have also is the implications of having overlapping > ioremap() calls (as proposed in my last reply) for different memory types > and having the different virtual memory addresse used by different parts > of the driver. Its not clear to me what the hardware implications of this > are. > > > But the video > > decoder/output device nodes may already be open for performing ioctl() > > functions so unmapping the decoder IO space out from under them, when > > loading the ivtvfb driver module, might not be a good thing. > > Using overlapping ioremap() calls with different memory types would address > this concern provided hardware won't barf both on the device and CPU. Hardware > folks could provide feedback or an ivtvfb user could test the patch supplied > on both non-PAT and PAT systems. Even so, who knows, this might work on some > systems while not on others, only hardware folks would know. The CX2341[56] firmware+hardware has a track record for being really picky about sytem hardware. It's primary symptoms are for the DMA engine or Mailbox protocol to get hung up. So yeah, it could barf easily on some users. > An alternative... is to just ioremap_wc() the entire region, including > MMIO registers for these old devices. That's my thought; as long as implementing PCI write then read can force writes to be posted and that setting that many pages as WC doesn't cause some sort of PAT resource exhaustion. (I know very little about PAT). > I see one ethernet driver that does > this, myri10ge, and am curious how and why they ended up deciding this > and if they have run into any issues. I wonder if this is a reasonable > comrpomise for these 2 remaining corner cases. > > Luis 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/