lkml.org 
[lkml]   [2020]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v6 09/10] arm64: efi: Export screen_info
    On Fri, 22 May 2020 at 13:15, Nikhil Mahale <nmahale@nvidia.com> wrote:
    >
    > On 5/18/20 6:21 PM, Ard Biesheuvel wrote:
    > > External email: Use caution opening links or attachments
    > >
    > >
    > > On Mon, 18 May 2020 at 06:25, Nikhil Mahale <nmahale@nvidia.com> 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@arndb.de> Sent: Wednesday, March 18, 2020 2:27 AM
    > >>>>>
    > >>>>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <mikelley@microsoft.com> wrote:
    > >>>>>> From: Arnd Bergmann <arnd@arndb.de>
    > >>>>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@microsoft.com> 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@microsoft.com>
    > >>>>>>>
    > >>>>>>> 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.
    > >
    >
    > Hi Ard, thanks for your feedback. If my understanding is correct,
    > you are agree to export screen_info. Can you provide guidance on how can
    > we proceed here? are you willing to accept this current patch as-is or
    > would you like me to re-submit the patch with the additional rationale
    > provided?
    >

    Please (re-)submit it along with the code that actually makes use of it.

    \
     
     \ /
      Last update: 2020-05-22 13:33    [W:2.535 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site