From: Robin Murphy <robin.murphy@arm.com> To: liviu.dudau@arm.com Cc: linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, tzimmermann@suse.de, javierm@redhat.com Subject: [PATCH v2] drm/arm/hdlcd: Take over EFI framebuffer properly Date: Wed, 15 Jun 2022 17:09:15 +0100 [thread overview] Message-ID: <31acd57f4aa8a4d02877026fa3a8c8d035e15a0d.1655309004.git.robin.murphy@arm.com> (raw) The Arm Juno board EDK2 port has provided an EFI GOP display via HDLCD0 for some time now, which works nicely as an early framebuffer. However, once the HDLCD driver probes and takes over the hardware, it should take over the logical framebuffer as well, otherwise the now-defunct GOP device hangs about and virtual console output inevitably disappears into the wrong place most of the time. We'll do this after binding the HDMI encoder, since that's the most likely thing to fail, and the EFI console is still better than nothing when that happens. However, the two HDLCD controllers on Juno are independent, and many users will still be using older firmware without any display support, so we'll only bother if we find that the HDLCD we're probing is already enabled. And if it is, then we'll also stop it, since otherwise the display can end up shifted if it's still scanning out while the rest of the registers are subsequently reconfigured. Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- Since I ended up adding (relatively) a lot here, I didn't want to second-guess Javier's opinion so left off the R-b tag from v1. drivers/gpu/drm/arm/hdlcd_drv.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c index e89ae0ec60eb..1f1171f2f16a 100644 --- a/drivers/gpu/drm/arm/hdlcd_drv.c +++ b/drivers/gpu/drm/arm/hdlcd_drv.c @@ -21,6 +21,7 @@ #include <linux/platform_device.h> #include <linux/pm_runtime.h> +#include <drm/drm_aperture.h> #include <drm/drm_atomic_helper.h> #include <drm/drm_crtc.h> #include <drm/drm_debugfs.h> @@ -314,6 +315,12 @@ static int hdlcd_drm_bind(struct device *dev) goto err_vblank; } + /* If EFI left us running, take over from efifb/sysfb */ + if (hdlcd_read(hdlcd, HDLCD_REG_COMMAND)) { + hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0); + drm_aperture_remove_framebuffers(false, &hdlcd_driver); + } + drm_mode_config_reset(drm); drm_kms_helper_poll_init(drm); -- 2.36.1.dirty
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com> To: liviu.dudau@arm.com Cc: brian.starkey@arm.com, javierm@redhat.com, tzimmermann@suse.de, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH v2] drm/arm/hdlcd: Take over EFI framebuffer properly Date: Wed, 15 Jun 2022 17:09:15 +0100 [thread overview] Message-ID: <31acd57f4aa8a4d02877026fa3a8c8d035e15a0d.1655309004.git.robin.murphy@arm.com> (raw) The Arm Juno board EDK2 port has provided an EFI GOP display via HDLCD0 for some time now, which works nicely as an early framebuffer. However, once the HDLCD driver probes and takes over the hardware, it should take over the logical framebuffer as well, otherwise the now-defunct GOP device hangs about and virtual console output inevitably disappears into the wrong place most of the time. We'll do this after binding the HDMI encoder, since that's the most likely thing to fail, and the EFI console is still better than nothing when that happens. However, the two HDLCD controllers on Juno are independent, and many users will still be using older firmware without any display support, so we'll only bother if we find that the HDLCD we're probing is already enabled. And if it is, then we'll also stop it, since otherwise the display can end up shifted if it's still scanning out while the rest of the registers are subsequently reconfigured. Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- Since I ended up adding (relatively) a lot here, I didn't want to second-guess Javier's opinion so left off the R-b tag from v1. drivers/gpu/drm/arm/hdlcd_drv.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c index e89ae0ec60eb..1f1171f2f16a 100644 --- a/drivers/gpu/drm/arm/hdlcd_drv.c +++ b/drivers/gpu/drm/arm/hdlcd_drv.c @@ -21,6 +21,7 @@ #include <linux/platform_device.h> #include <linux/pm_runtime.h> +#include <drm/drm_aperture.h> #include <drm/drm_atomic_helper.h> #include <drm/drm_crtc.h> #include <drm/drm_debugfs.h> @@ -314,6 +315,12 @@ static int hdlcd_drm_bind(struct device *dev) goto err_vblank; } + /* If EFI left us running, take over from efifb/sysfb */ + if (hdlcd_read(hdlcd, HDLCD_REG_COMMAND)) { + hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0); + drm_aperture_remove_framebuffers(false, &hdlcd_driver); + } + drm_mode_config_reset(drm); drm_kms_helper_poll_init(drm); -- 2.36.1.dirty _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2022-06-15 16:09 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-15 16:09 Robin Murphy [this message] 2022-06-15 16:09 ` [PATCH v2] drm/arm/hdlcd: Take over EFI framebuffer properly Robin Murphy 2022-06-16 9:44 ` Liviu Dudau 2022-06-16 9:44 ` Liviu Dudau 2022-06-16 10:37 ` Javier Martinez Canillas 2022-06-16 10:37 ` Javier Martinez Canillas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=31acd57f4aa8a4d02877026fa3a8c8d035e15a0d.1655309004.git.robin.murphy@arm.com \ --to=robin.murphy@arm.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=javierm@redhat.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=liviu.dudau@arm.com \ --cc=tzimmermann@suse.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.