On Tue, Oct 25, 2016 at 07:31:29PM +0200, Luis R. Rodriguez wrote: > On Mon, Oct 24, 2016 at 04:31:45PM +1000, Dave Airlie wrote: > > A recent change to the mm code in: > > 87744ab3832b83ba71b931f86f9cfdb000d07da5 > > mm: fix cache mode tracking in vm_insert_mixed() > > > > started enforcing checking the memory type against the registered list for > > amixed pfn insertion mappings. It happens that the drm drivers for a number > > of gpus relied on this being broken. Currently the driver only inserted > > VRAM mappings into the tracking table when they came from the kernel, > > and userspace mappings never landed in the table. This led to a regression > > where all the mapping end up as UC instead of WC now. > > Eek. > > > I've considered a number of solutions but since this needs to be fixed > > in fixes and not next, and some of the solutions were going to introduce > > overhead that hadn't been there before I didn't consider them viable at > > this stage. These mainly concerned hooking into the TTM io reserve APIs, > > but these API have a bunch of fast paths I didn't want to unwind to add > > this to. > > > > The solution I've decided on is to add a new API like the arch_phys_wc > > APIs (these would have worked but wc_del didn't take a range), and > > use them from the drivers to add a WC compatible mapping to the table > > for all VRAM on those GPUs. This means we can then create userspace > > mapping that won't get degraded to UC. > > Is anything on a driver to be able to tell when this is actually needed ? > How will driver developers know? Can you add a bit of documentation to > the API? If its transitive towards a secondary solution indicating so > would help driver developers. I'll plug the io-mapping stuff again here, and more specifically the userspace pte wrangling stuff we've added in 4.9 to i915_mm.c. Should probably move that one to the core. That way io_mapping takes care of the full reservartion, and allows you to on-demand kmap (for kernel) and write ptes. All nicely fast and all, and for bonus, also nicely encapsulated. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
