On Mon, 18 May 2020 at 06:25, Nikhil Mahale <nmahale@xxxxxxxxxx> wrote: > > On 5/13/20 7:56 PM, Nikhil Mahale wrote: > > On 3/20/20 3:16 AM, Michael Kelley wrote: > >> From: Arnd Bergmann <arnd@xxxxxxxx> Sent: Wednesday, March 18, 2020 2:27 AM > >>> > >>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <mikelley@xxxxxxxxxxxxx> wrote: > >>>> From: Arnd Bergmann <arnd@xxxxxxxx> > >>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@xxxxxxxxxxxxx> wrote: > >>>>>> > >>>>>> The Hyper-V frame buffer driver may be built as a module, and > >>>>>> it needs access to screen_info. So export screen_info. > >>>>>> > >>>>>> Signed-off-by: Michael Kelley <mikelley@xxxxxxxxxxxxx> > >>>>> > >>>>> Is there any chance of using a more modern KMS based driver for the screen > >>>>> than the old fbdev subsystem? I had hoped to one day completely remove > >>>>> support for the old CONFIG_VIDEO_FBDEV and screen_info from modern > >>>>> architectures. > >>>>> > >>>> > >>>> The current hyperv_fb.c driver is all we have today for the synthetic Hyper-V > >>>> frame buffer device. That driver builds and runs on both ARM64 and x86. > >>>> > >>>> I'm not knowledgeable about video/graphics drivers, but when you > >>>> say "a more modern KMS based driver", are you meaning one based on > >>>> DRM & KMS? Does DRM make sense for a "dumb" frame buffer device? > >>>> Are there any drivers that would be a good pattern to look at? > >>> > >>> It used to be a lot harder to write a DRM driver compared to an fbdev > >>> driver, but this has changed to the opposite over the years. > >>> > >>> A fairly minimal example would be drivers/gpu/drm/pl111/pl111_drv.c > >>> or anything in drivers/gpu/drm/tiny/, but you may want to look at the > >>> other hypervisor platforms first, i.e drivers/gpu/drm/virtio/virtgpu_drv.c, > >>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c, drivers/gpu/drm/xen/xen_drm_front.c, > >>> drivers/gpu/drm/qxl/qxl_drv.c, and drivers/gpu/drm/bochs/bochs_drv.c. > >>> > >> > >> Thanks for the pointers, especially for the other hypervisors. > >> > > Sorry if anybody in 'to' or 'cc' is receiving this reply multiple times. > > I had configured by email client incorrectly to reply. > > > > screen_info is still useful with a modern KMS-based driver. It exposes > > the mode parameters that the GOP driver chose. This information is > > needed to implement seamless or glitchless boot, by both ensuring that > > the scanout parameters don't change and being able to read back the > > scanout image to populate the initial contents of the new surface. > > > > This works today on arches which implement (U)EFI and export > > screen_info, including x86 and powerpc, but doesn't work on arm or > > arm64. As arm64 systems that implement UEFI with real GOP drivers > > become more prevalent, it would be nice to be have these features there > > as well. > > In addition to this, even if a driver doesn't implement a framebuffer > console, or if it does but has an option to disable it, the driver still > needs to know whether the EFI console is using resources on the GPU so > it can avoid clobbering them. For example screen_info provides information > like offset and size of EFI console, using this information driver can > reserve memory used by console and prevent corruption on it. > > I think arm64 should export screen_info. > If there are reasons why KMS or fbdev drivers may need to access the information in screen_info, it should be exported. I don't think that is under debate here.
