From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965162AbbDUXPG (ORCPT ); Tue, 21 Apr 2015 19:15:06 -0400 Received: from cantor2.suse.de ([195.135.220.15]:55790 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965025AbbDUXPB (ORCPT ); Tue, 21 Apr 2015 19:15:01 -0400 Date: Wed, 22 Apr 2015 01:14:56 +0200 From: "Luis R. Rodriguez" To: Andy Walls Cc: Andy Lutomirski , Hyong-Youb Kim , "netdev@vger.kernel.org" , infinipath@intel.com, jgunthorpe@obsidianresearch.com, mike.marciniszyn@intel.com, Toshi Kani , "H. Peter Anvin" , Ingo Molnar , "linux-kernel@vger.kernel.org" , Hal Rosenstock , Sean Hefty , Suresh Siddha , Rickard Strandqvist , Roland Dreier , Juergen Gross , Mauro Carvalho Chehab , 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 , linux-media@vger.kernel.org, X86ML@suse.de Subject: Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR Message-ID: <20150421231456.GZ5622@wotan.suse.de> References: <20150411012938.GC5622@wotan.suse.de> <20150413174938.GE5622@wotan.suse.de> <1429137531.1899.28.camel@palomino.walls.org> <20150415235816.GG5622@wotan.suse.de> <1429146457.1899.99.camel@palomino.walls.org> <20150421220219.GX5622@wotan.suse.de> <5536d47a.95968c0a.1d12.ffffbf85@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5536d47a.95968c0a.1d12.ffffbf85@mx.google.com> 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 On Tue, Apr 21, 2015 at 06:51:26PM -0400, Andy Walls wrote: > Sorry for the top post; mobile work email account. > > Luis, > > You do the changes to remove MTTR and point me to your dev repo and branch. > Also point me to the new functions/primitives I'll need. There is nothing new actually needed for ivtv, unless of course the ivtv driver is bounded to use a large MTRR that includes the non-framebuffer region, if so then the ioremap_uc() would be needed, and you can just cherry pick that patch: https://marc.info/?l=linux-kernel&m=142964809110516&w=1 I'll bounce that patch to you as well. Might help reading this patch too: https://marc.info/?l=linux-kernel&m=142964809710517&w=1 If your write-combining area is not restricted by size constraints so that it also include the non-framebuffer areas then you can just do a simple conversion of the driver to use ioremap_wc() on the framebuffer followed by arch_phys_wc_add(). An example driver that required changes to split this with size contraints is atyfb, here are the changes for it: https://marc.info/?l=linux-kernel&m=142964818810539&w=1 https://marc.info/?l=linux-kernel&m=142964813610531&w=1 https://marc.info/?l=linux-kernel&m=142964811010524&w=1 https://marc.info/?l=linux-kernel&m=142964814810532&w=1 If you are not constrained by MTRR's limitation on size then a simple trivial driver conversion is sufficient. For example: https://marc.info/?l=linux-kernel&m=142964744610286&w=1 I should also note that we are strivoing to also not use overlapping ioremap() calls as we want to avoid that mess. Overlapping iroemap() calls with different types could in theory work but its best we just design clean drivers and avoid this. As per Andy Lutomirski, what we'd need done on ivtv likely is for it to ioremap() for an initial bring up of the device, then infer the framebuffer offset, and only when that is being used then iounmap and then ioremap() again split areas on the driver, one with ioremap. > I'll do the changes to add write-combining back into ivtv and ivtvfb, test > them with my hardware and push them to my linuxtv.org git repo. Great! The above sounded like a complexity you did not wish to take on, but if you're up for the change, that'd be awesome! > I know there is at least one English speaking user in India using ivtv with > old PVR hardware, and probably folks in less developed places also using it. If the above is too much work for that few amount of users I'd hope we can just have them use older kernels, for the sake of sane APIs and clean driver architecture. Luis