[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMj1kXFk=EvC7CW42gko3Wve_6vFgKUm8HXvLNXEnTLuZqxXng@mail.gmail.com>
Date: Thu, 20 Nov 2025 09:25:49 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Thomas Zimmermann <tzimmermann@...e.de>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-efi@...r.kernel.org,
linux-kernel@...r.kernel.org, Javier Martinez Canillas <javierm@...hat.com>
Subject: Re: [PATCH 0/3] video/efi: Support FIRMWARE_EDID on non-x86
On Thu, 20 Nov 2025 at 09:19, Thomas Zimmermann <tzimmermann@...e.de> wrote:
>
>
>
> Am 20.11.25 um 08:56 schrieb Thomas Zimmermann:
> > Hi,
> >
> > thanks for addressing the remaining EDID support.
> >
> > First of all, you need to cc dri-devel@...ts.freedesktop.org on any
> > further revisions.
> >
> > Am 19.11.25 um 13:30 schrieb Ard Biesheuvel:
> >> From: Ard Biesheuvel <ardb@...nel.org>
> >>
> >> Refactor the screen_info handling so non-x86 platforms booting via the
> >> EFI stub also have access to the EDID data exposed by the EFI boot
> >> services.
> >
> > I don't like how this series complicates everything to make non-x86
> > easier. But the general idea of using efi_screen_info goes into the
> > right direction. It's just not generic enough.
> >
> > The sysfb code transfers struct screen_info as device parameter [1].
> > Drivers later fetch it on probe [2]. The direct ref to the global
> > edid_info [3] only exists because we have no means of transferring it
> > as device data.
> >
> > So instead of using efi_screen_info, let's declare struct
> > sysfb_display with screen_info and edid_info. The header would be
> > linux/sysfb.h. We transfer this to all related drivers. The generic
> > EFI code would set it up like efi_screen_info and the x86 code would
> > decalre it at [4]; replacing the existing state.
>
> If this proposal works for EFI, I could do the changes in graphics
> drivers and then resubmit the EDID series with an additional patch for
> generic EFI.
>
That sounds great, thanks.
Powered by blists - more mailing lists