| Message ID | 20210625130947.1803678-1-javierm@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | allow simple{fb, drm} drivers to be used on non-x86 EFI platforms | expand |
On 6/25/21 3:09 PM, Javier Martinez Canillas wrote: > The simplefb and simpledrm drivers match against a "simple-framebuffer" > device, but for aarch64 this is only registered when using Device Trees > and there's a node with a "simple-framebuffer" compatible string. > > There is no code to register a "simple-framebuffer" platform device when > using EFI instead. In fact, the only platform device that's registered in > this case is an "efi-framebuffer", which means that the efifb driver is > the only driver supported to have an early console with EFI on aarch64. > > The x86 architecture platform has a Generic System Framebuffers (sysfb) > support, that register a system frambuffer platform device. It either > registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy > VGA/EFI FB devices for the vgafb/efifb drivers. > > The sysfb is generic enough to be reused by other architectures and can be > moved out of the arch/x86 directory to drivers/firmware, allowing the EFI > logic used by non-x86 architectures to be folded into sysfb as well. > Any more comments on this series? It would be nice for this to land so the simpledrm driver could be used on aarch64 EFI systems as well. The patches have already been acked by x86 and DRM folks. Best regards,
Hi Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas: > On 6/25/21 3:09 PM, Javier Martinez Canillas wrote: >> The simplefb and simpledrm drivers match against a "simple-framebuffer" >> device, but for aarch64 this is only registered when using Device Trees >> and there's a node with a "simple-framebuffer" compatible string. >> >> There is no code to register a "simple-framebuffer" platform device when >> using EFI instead. In fact, the only platform device that's registered in >> this case is an "efi-framebuffer", which means that the efifb driver is >> the only driver supported to have an early console with EFI on aarch64. >> >> The x86 architecture platform has a Generic System Framebuffers (sysfb) >> support, that register a system frambuffer platform device. It either >> registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy >> VGA/EFI FB devices for the vgafb/efifb drivers. >> >> The sysfb is generic enough to be reused by other architectures and can be >> moved out of the arch/x86 directory to drivers/firmware, allowing the EFI >> logic used by non-x86 architectures to be folded into sysfb as well. >> > > Any more comments on this series? It would be nice for this to land so the > simpledrm driver could be used on aarch64 EFI systems as well. > > The patches have already been acked by x86 and DRM folks. Time to get this merged, I'd say. People are asking for these patches already. Best regards Thomas > > Best regards, >
On Thu, 15 Jul 2021 at 18:11, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Hi > > Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas: > > On 6/25/21 3:09 PM, Javier Martinez Canillas wrote: > >> The simplefb and simpledrm drivers match against a "simple-framebuffer" > >> device, but for aarch64 this is only registered when using Device Trees > >> and there's a node with a "simple-framebuffer" compatible string. > >> > >> There is no code to register a "simple-framebuffer" platform device when > >> using EFI instead. In fact, the only platform device that's registered in > >> this case is an "efi-framebuffer", which means that the efifb driver is > >> the only driver supported to have an early console with EFI on aarch64. > >> > >> The x86 architecture platform has a Generic System Framebuffers (sysfb) > >> support, that register a system frambuffer platform device. It either > >> registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy > >> VGA/EFI FB devices for the vgafb/efifb drivers. > >> > >> The sysfb is generic enough to be reused by other architectures and can be > >> moved out of the arch/x86 directory to drivers/firmware, allowing the EFI > >> logic used by non-x86 architectures to be folded into sysfb as well. > >> > > > > Any more comments on this series? It would be nice for this to land so the > > simpledrm driver could be used on aarch64 EFI systems as well. > > > > The patches have already been acked by x86 and DRM folks. > > Time to get this merged, I'd say. People are asking for these patches > already. Can we just merge via drm-misc and make sure the acks are present and I'll deal with the fallout if any. Dave.
On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: > > On Thu, 15 Jul 2021 at 18:11, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > Hi > > > > Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas: > > > On 6/25/21 3:09 PM, Javier Martinez Canillas wrote: > > >> The simplefb and simpledrm drivers match against a "simple-framebuffer" > > >> device, but for aarch64 this is only registered when using Device Trees > > >> and there's a node with a "simple-framebuffer" compatible string. > > >> > > >> There is no code to register a "simple-framebuffer" platform device when > > >> using EFI instead. In fact, the only platform device that's registered in > > >> this case is an "efi-framebuffer", which means that the efifb driver is > > >> the only driver supported to have an early console with EFI on aarch64. > > >> > > >> The x86 architecture platform has a Generic System Framebuffers (sysfb) > > >> support, that register a system frambuffer platform device. It either > > >> registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy > > >> VGA/EFI FB devices for the vgafb/efifb drivers. > > >> > > >> The sysfb is generic enough to be reused by other architectures and can be > > >> moved out of the arch/x86 directory to drivers/firmware, allowing the EFI > > >> logic used by non-x86 architectures to be folded into sysfb as well. > > >> > > > > > > Any more comments on this series? It would be nice for this to land so the > > > simpledrm driver could be used on aarch64 EFI systems as well. > > > > > > The patches have already been acked by x86 and DRM folks. > > > > Time to get this merged, I'd say. People are asking for these patches > > already. > > Can we just merge via drm-misc and make sure the acks are present and > I'll deal with the fallout if any. > Fine with me. Could you stick it on a separate branch so I can double check whether there are any issues wrt the EFI tree? Thanks, Ard.
On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote: > On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: > > > > On Thu, 15 Jul 2021 at 18:11, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > > > Hi > > > > > > Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas: > > > > On 6/25/21 3:09 PM, Javier Martinez Canillas wrote: > > > >> The simplefb and simpledrm drivers match against a "simple-framebuffer" > > > >> device, but for aarch64 this is only registered when using Device Trees > > > >> and there's a node with a "simple-framebuffer" compatible string. > > > >> > > > >> There is no code to register a "simple-framebuffer" platform device when > > > >> using EFI instead. In fact, the only platform device that's registered in > > > >> this case is an "efi-framebuffer", which means that the efifb driver is > > > >> the only driver supported to have an early console with EFI on aarch64. > > > >> > > > >> The x86 architecture platform has a Generic System Framebuffers (sysfb) > > > >> support, that register a system frambuffer platform device. It either > > > >> registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy > > > >> VGA/EFI FB devices for the vgafb/efifb drivers. > > > >> > > > >> The sysfb is generic enough to be reused by other architectures and can be > > > >> moved out of the arch/x86 directory to drivers/firmware, allowing the EFI > > > >> logic used by non-x86 architectures to be folded into sysfb as well. > > > >> > > > > > > > > Any more comments on this series? It would be nice for this to land so the > > > > simpledrm driver could be used on aarch64 EFI systems as well. > > > > > > > > The patches have already been acked by x86 and DRM folks. > > > > > > Time to get this merged, I'd say. People are asking for these patches > > > already. > > > > Can we just merge via drm-misc and make sure the acks are present and > > I'll deal with the fallout if any. > > > > Fine with me. Could you stick it on a separate branch so I can double > check whether there are any issues wrt the EFI tree? It'll pop up in linux-next for integration testing or you can pick up the patch here for test-merge if you want. And since Dave has given a blanket cheque for handling fallout he'll deal with the need for fixups too if there's any. -Daniel
On 7/20/21 3:01 PM, Daniel Vetter wrote: > On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote: >> On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: [snip] >>> >>> Can we just merge via drm-misc and make sure the acks are present and >>> I'll deal with the fallout if any. >>> >> >> Fine with me. Could you stick it on a separate branch so I can double >> check whether there are any issues wrt the EFI tree? > > It'll pop up in linux-next for integration testing or you can pick up the > patch here for test-merge if you want. > Thanks a lot Dave and Daniel! > And since Dave has given a blanket cheque for handling fallout he'll deal > with the need for fixups too if there's any. I also plan to look at any regression that might had been introduced by these. Best regards,
On Tue, Jul 20, 2021 at 03:42:45PM +0200, Javier Martinez Canillas wrote: > On 7/20/21 3:01 PM, Daniel Vetter wrote: > > On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote: > >> On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: > > [snip] > > >>> > >>> Can we just merge via drm-misc and make sure the acks are present and > >>> I'll deal with the fallout if any. > >>> > >> > >> Fine with me. Could you stick it on a separate branch so I can double > >> check whether there are any issues wrt the EFI tree? > > > > It'll pop up in linux-next for integration testing or you can pick up the > > patch here for test-merge if you want. > > > > Thanks a lot Dave and Daniel! Oh I haven't merged them, I'm assuming Thomas will do that. Just figured I'll throw my ack on top: Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > And since Dave has given a blanket cheque for handling fallout he'll deal > > with the need for fixups too if there's any. > > I also plan to look at any regression that might had been introduced by these. > > Best regards, > -- > Javier Martinez Canillas > Linux Engineering > Red Hat >
Hi Am 20.07.21 um 15:59 schrieb Daniel Vetter: > On Tue, Jul 20, 2021 at 03:42:45PM +0200, Javier Martinez Canillas wrote: >> On 7/20/21 3:01 PM, Daniel Vetter wrote: >>> On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote: >>>> On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: >> >> [snip] >> >>>>> >>>>> Can we just merge via drm-misc and make sure the acks are present and >>>>> I'll deal with the fallout if any. >>>>> >>>> >>>> Fine with me. Could you stick it on a separate branch so I can double >>>> check whether there are any issues wrt the EFI tree? >>> >>> It'll pop up in linux-next for integration testing or you can pick up the >>> patch here for test-merge if you want. >>> >> >> Thanks a lot Dave and Daniel! > > Oh I haven't merged them, I'm assuming Thomas will do that. Just figured Can I simply put the patches in to drm-misc-next? There was some talk about a topic branch? Best regards Thomas > I'll throw my ack on top: > > Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> > >>> And since Dave has given a blanket cheque for handling fallout he'll deal >>> with the need for fixups too if there's any. >> >> I also plan to look at any regression that might had been introduced by these. >> >> Best regards, >> -- >> Javier Martinez Canillas >> Linux Engineering >> Red Hat >> >
Hello Thomas, On 7/20/21 8:38 PM, Thomas Zimmermann wrote: > Am 20.07.21 um 15:59 schrieb Daniel Vetter: >> On Tue, Jul 20, 2021 at 03:42:45PM +0200, Javier Martinez Canillas wrote: >>> On 7/20/21 3:01 PM, Daniel Vetter wrote: >>>> On Mon, Jul 19, 2021 at 09:10:52AM +0200, Ard Biesheuvel wrote: >>>>> On Mon, 19 Jul 2021 at 04:59, Dave Airlie <airlied@gmail.com> wrote: [snip] >>>>>> Can we just merge via drm-misc and make sure the acks are present and >>>>>> I'll deal with the fallout if any. >>>>>> >>>>> >>>>> Fine with me. Could you stick it on a separate branch so I can double >>>>> check whether there are any issues wrt the EFI tree? >>>> >>>> It'll pop up in linux-next for integration testing or you can pick up the >>>> patch here for test-merge if you want. >>>> This is what Daniel said... >>> >>> Thanks a lot Dave and Daniel! >> >> Oh I haven't merged them, I'm assuming Thomas will do that. Just figured > > Can I simply put the patches in to drm-misc-next? There was some talk > about a topic branch? > ... which AFAIU means that there's no need for a topic branch, since the patches will be present in linux-next. And the EFI folks can use that to check if there are any integration issues or regressions caused by these. > Best regards > Thomas > Best regards,
Hi Am 21.07.21 um 07:09 schrieb Javier Martinez Canillas: ... >> >> Can I simply put the patches in to drm-misc-next? There was some talk >> about a topic branch? >> > > ... which AFAIU means that there's no need for a topic branch, since the > patches will be present in linux-next. And the EFI folks can use that to > check if there are any integration issues or regressions caused by these. Merged into drm-misc-next. Best regards Thomas > >> Best regards >> Thomas >> > > Best regards, >
On 7/21/21 12:07 PM, Thomas Zimmermann wrote: > Hi > > Am 21.07.21 um 07:09 schrieb Javier Martinez Canillas: > ... >>> >>> Can I simply put the patches in to drm-misc-next? There was some talk >>> about a topic branch? >>> >> >> ... which AFAIU means that there's no need for a topic branch, since the >> patches will be present in linux-next. And the EFI folks can use that to >> check if there are any integration issues or regressions caused by these. > > Merged into drm-misc-next. > Thanks a lot Thomas for all your help! Best regards,
On Wed, Jul 21, 2021 at 12:15:12PM +0200, Javier Martinez Canillas wrote: > On 7/21/21 12:07 PM, Thomas Zimmermann wrote: > > Hi > > > > Am 21.07.21 um 07:09 schrieb Javier Martinez Canillas: > > ... > >>> > >>> Can I simply put the patches in to drm-misc-next? There was some talk > >>> about a topic branch? > >>> > >> > >> ... which AFAIU means that there's no need for a topic branch, since the > >> patches will be present in linux-next. And the EFI folks can use that to > >> check if there are any integration issues or regressions caused by these. > > > > Merged into drm-misc-next. > > > > Thanks a lot Thomas for all your help! Yeah topic branch makes sense when we have further work that will build on top of a patch sets in at latest _two_ different subsystems, and it doesn't make sense to just merge it all in one place (because too much work, or a refactoring that's too invasive and will cause random conflicts with subsequent work in the same subsystem, or ...). Otherwise just acks and then merge in one place. We shouldn't do bureaucratics like topic branches if there's not an actual need for them. -Daniel
The simplefb and simpledrm drivers match against a "simple-framebuffer" device, but for aarch64 this is only registered when using Device Trees and there's a node with a "simple-framebuffer" compatible string. There is no code to register a "simple-framebuffer" platform device when using EFI instead. In fact, the only platform device that's registered in this case is an "efi-framebuffer", which means that the efifb driver is the only driver supported to have an early console with EFI on aarch64. The x86 architecture platform has a Generic System Framebuffers (sysfb) support, that register a system frambuffer platform device. It either registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy VGA/EFI FB devices for the vgafb/efifb drivers. The sysfb is generic enough to be reused by other architectures and can be moved out of the arch/x86 directory to drivers/firmware, allowing the EFI logic used by non-x86 architectures to be folded into sysfb as well. Patch #1 in this series do the former while patch #2 do the latter. It has been tested on x86_64 and aarch64 machines using the efifb, simplefb and simpledrm drivers. But more testing will be highly appreciated, to make sure that no regressions are being introduced by these changes. The series touches different subystems and will need coordination between maintainers but the patches have already been acked by the x86 folks. Ard Biesheuvel said that these could be merged through the EFI tree if needed. Best regards, Javier Changes in v3: - Add Borislav and Greg Acked-by tags. - Also update the SYSFB_SIMPLEFB symbol name in drivers/gpu/drm/tiny/Kconfig. - We have a a max 100 char limit now, use it to avoid multi-line statements. - Figure out the platform device name before allocating the platform device. Changes in v2: - Use default y and depends on X86 instead doing a select in arch/x86/Kconfig. - Also enable the SYSFB Kconfig option when COMPILE_TEST. - Improve commit message to explain why is useful for other arches to use this. - Use "depends on" for the supported architectures instead of selecting it. - Improve commit message to explain the benefits of reusing sysfb for !X86. Javier Martinez Canillas (2): drivers/firmware: move x86 Generic System Framebuffers support drivers/firmware: consolidate EFI framebuffer setup for all arches arch/arm/include/asm/efi.h | 5 +- arch/arm64/include/asm/efi.h | 5 +- arch/riscv/include/asm/efi.h | 5 +- arch/x86/Kconfig | 26 ------ arch/x86/kernel/Makefile | 3 - drivers/firmware/Kconfig | 32 +++++++ drivers/firmware/Makefile | 2 + drivers/firmware/efi/Makefile | 2 + drivers/firmware/efi/efi-init.c | 90 ------------------- .../firmware/efi}/sysfb_efi.c | 78 +++++++++++++++- {arch/x86/kernel => drivers/firmware}/sysfb.c | 37 +++++--- .../firmware}/sysfb_simplefb.c | 33 ++++--- drivers/gpu/drm/tiny/Kconfig | 4 +- .../x86/include/asm => include/linux}/sysfb.h | 32 +++---- 14 files changed, 180 insertions(+), 174 deletions(-) rename {arch/x86/kernel => drivers/firmware/efi}/sysfb_efi.c (84%) rename {arch/x86/kernel => drivers/firmware}/sysfb.c (75%) rename {arch/x86/kernel => drivers/firmware}/sysfb_simplefb.c (81%) rename {arch/x86/include/asm => include/linux}/sysfb.h (70%)