summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDexuan Cui <decui@microsoft.com>2021-01-09 14:53:58 -0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2021-01-12 20:10:20 +0100
commit9540ea23f62391050da23c2dd47e76bdfb5dcbd5 (patch)
treea48ac00d398b2b7de7afb03bc288fd61f5b1de3d
parente40cc214c690a1e0145484d2a1aeb35c6cd58387 (diff)
downloadlinux-stable-9540ea23f62391050da23c2dd47e76bdfb5dcbd5.tar.gz
linux-stable-9540ea23f62391050da23c2dd47e76bdfb5dcbd5.tar.bz2
linux-stable-9540ea23f62391050da23c2dd47e76bdfb5dcbd5.zip
video: hyperv_fb: Fix the mmap() regression for v5.4.y and older
db49200b1dad is backported from the mainline commit 5f1251a48c17 ("video: hyperv_fb: Fix the cache type when mapping the VRAM"), to v5.4.y and older stable branches, but unluckily db49200b1dad causes mmap() to fail for /dev/fb0 due to EINVAL: [ 5797.049560] x86/PAT: a.out:1910 map pfn expected mapping type uncached-minus for [mem 0xf8200000-0xf85cbfff], got write-back This means the v5.4.y kernel detects an incompatibility issue about the mapping type of the VRAM: db49200b1dad changes to use Write-Back when mapping the VRAM, while the mmap() syscall tries to use Uncached-minus. That’s to say, the kernel thinks Uncached-minus is incompatible with Write-Back: see drivers/video/fbdev/core/fbmem.c: fb_mmap() -> vm_iomap_memory() -> io_remap_pfn_range() -> ... -> track_pfn_remap() -> reserve_pfn_range(). Note: any v5.5 and newer kernel doesn't have the issue, because they have commit d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver") , and when the hyperv_fb driver has the deferred_io support, fb_deferred_io_init() overrides info->fbops->fb_mmap with fb_deferred_io_mmap(), which doesn’t check the mapping type incompatibility. Note: since it's VRAM here, the checking is not really necessary. Fix the regression by ioremap_wc(), which uses Write-combining. The kernel thinks it's compatible with Uncached-minus. The VRAM mappped by ioremap_wc() is slightly slower than mapped by ioremap_cache(), but is still significantly faster than by ioremap(). Change the comment accordingly. Linux VM on ARM64 Hyper-V is still not working in the latest mainline yet, and when it works in future, the ARM64 support is unlikely to be backported to v5.4 and older, so using ioremap_wc() in v5.4 and older should be ok. Note: this fix is only targeted at the stable branches: v5.4.y, v4.19.y, v4.14.y, v4.9.y and v4.4.y. Fixes: db49200b1dad ("video: hyperv_fb: Fix the cache type when mapping the VRAM") Signed-off-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
-rw-r--r--drivers/video/fbdev/hyperv_fb.c6
1 files changed, 2 insertions, 4 deletions
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 56e70f12c996..c907f96d6890 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -713,11 +713,9 @@ static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info)
}
/*
- * Map the VRAM cacheable for performance. This is also required for
- * VM Connect to display properly for ARM64 Linux VM, as the host also
- * maps the VRAM cacheable.
+ * Map the VRAM cacheable for performance.
*/
- fb_virt = ioremap_cache(par->mem->start, screen_fb_size);
+ fb_virt = ioremap_wc(par->mem->start, screen_fb_size);
if (!fb_virt)
goto err2;