On 5/18/22 20:48, Dexuan Cui wrote: >> From: Dexuan Cui <decui@xxxxxxxxxxxxx> >> Sent: Wednesday, May 4, 2022 10:05 AM >> To: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>; Wei Liu <wei.liu@xxxxxxxxxx>; >>> ... >>> When I initially implemented this driver 10 years ago, I believe there >>> was smaller limit for the fb... But I think this patch is good for the >>> newer MMIO alloc scheme. I hope to see reviews also from >>> @Dexuan Cui @Michael Kelley (LINUX) who are more familiar with >>> the PCI/BAR/MMIO area. >>> >>> Thanks, >>> - Haiyang >> >> The patch looks good to me but I suggest we check with the Hyper-V >> team to figure out how a Gen1 Windows VM supports a higher >> resolution that needs a VRAM size of more than 64MB. Just in case we >> miss something.. >> >> Thanks, >> -- Dexuan > > Reviewed-by: Dexuan Cui <decui@xxxxxxxxxxxxx> > > Saurabh checked this with Hyper-V team, who said there is no > Generation 1-specific block for larger VRAM sizes in Windows VM. > > When the driver was originally developed, we didn't have the API > vmbus_allocate_mmio(), and I guess we just used the PCI device's BAR > address for simplicity, and didn't realize the restriction with very high > resolutions that require >64 MB VRAM. It looks like the synthetic > VMBus framebuffer device doesn't have to use the same MMIO range > used by the Hyper-V legacy PCI framebuffer device, so the patch > looks good to me. Thanks for the review, Dexuan! I've applied this patch now to the fbdev git tree. > BTW, please check the hyperv-drm driver as well: > drivers/gpu/drm/hyperv/hyperv_drm_drv.c > I think we should make the same change there to support 7680x4320 > for Gen1 VMs. Haiyang, can you check that as well and send another patch for the drm tree ? Helge
