From: Peter Jones <pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Matt Fleming
<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Pete Hawkins <pete.hawkins-ZTdz3wlHnvg@public.gmane.org>,
Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>,
Chad Page <chad.page-ZTdz3wlHnvg@public.gmane.org>
Subject: Re: [PATCH] efifb: Add support for 64-bit frame buffer addresses
Date: Mon, 31 Aug 2015 11:23:31 -0400 [thread overview]
Message-ID: <20150831152330.GC17921@redhat.com> (raw)
In-Reply-To: <1440763939-17027-1-git-send-email-matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
On Fri, Aug 28, 2015 at 01:12:19PM +0100, Matt Fleming wrote:
> From: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> The EFI Graphics Output Protocol uses 64-bit frame buffer addresses
> but these get truncated to 32-bit by the EFI boot stub when storing
> the address in the 'lfb_base' field of 'struct screen_info'.
>
> Add a 'ext_lfb_base' field for the upper 32-bits of the frame buffer
> address and set VIDEO_TYPE_CAPABILITY_64BIT_BASE when the field is
> useable.
>
> It turns out that the reason no one has required this support so far
> is that there's actually code in tianocore to "downgrade" PCI
> resources that have option ROMs and 64-bit BARS from 64-bit to 32-bit
> to cope with legacy option ROMs that can't handle 64-bit addresses.
> The upshot is that basically all GOP devices in the wild use a 32-bit
> frame buffer address.
>
> Still, it is possible to build firmware that uses a full 64-bit GOP
> frame buffer address. Chad did, which led to him reporting this issue.
>
> Add support in anticipation of GOP devices using 64-bit addresses more
> widely, and so that efifb works out of the box when that happens.
>
> Reported-by: Chad Page <chad.page-ZTdz3wlHnvg@public.gmane.org>
> Cc: Pete Hawkins <pete.hawkins-ZTdz3wlHnvg@public.gmane.org>
> Cc: Peter Jones <pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
> Signed-off-by: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Looks good to me.
Acked-by: Peter Jones <pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
Peter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Jones <pjones@redhat.com>
To: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Matt Fleming
<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Pete Hawkins <pete.hawkins-ZTdz3wlHnvg@public.gmane.org>,
Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>,
Chad Page <chad.page-ZTdz3wlHnvg@public.gmane.org>
Subject: Re: [PATCH] efifb: Add support for 64-bit frame buffer addresses
Date: Mon, 31 Aug 2015 15:23:31 +0000 [thread overview]
Message-ID: <20150831152330.GC17921@redhat.com> (raw)
In-Reply-To: <1440763939-17027-1-git-send-email-matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
On Fri, Aug 28, 2015 at 01:12:19PM +0100, Matt Fleming wrote:
> From: Matt Fleming <matt.fleming@intel.com>
>
> The EFI Graphics Output Protocol uses 64-bit frame buffer addresses
> but these get truncated to 32-bit by the EFI boot stub when storing
> the address in the 'lfb_base' field of 'struct screen_info'.
>
> Add a 'ext_lfb_base' field for the upper 32-bits of the frame buffer
> address and set VIDEO_TYPE_CAPABILITY_64BIT_BASE when the field is
> useable.
>
> It turns out that the reason no one has required this support so far
> is that there's actually code in tianocore to "downgrade" PCI
> resources that have option ROMs and 64-bit BARS from 64-bit to 32-bit
> to cope with legacy option ROMs that can't handle 64-bit addresses.
> The upshot is that basically all GOP devices in the wild use a 32-bit
> frame buffer address.
>
> Still, it is possible to build firmware that uses a full 64-bit GOP
> frame buffer address. Chad did, which led to him reporting this issue.
>
> Add support in anticipation of GOP devices using 64-bit addresses more
> widely, and so that efifb works out of the box when that happens.
>
> Reported-by: Chad Page <chad.page@znyx.com>
> Cc: Pete Hawkins <pete.hawkins@znyx.com>
> Cc: Peter Jones <pjones@redhat.com>
> Cc: Matthew Garrett <mjg59@srcf.ucam.org>
> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Looks good to me.
Acked-by: Peter Jones <pjones@redhat.com>
--
Peter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Jones <pjones@redhat.com>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org,
Matt Fleming <matt.fleming@intel.com>,
Pete Hawkins <pete.hawkins@znyx.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Chad Page <chad.page@znyx.com>
Subject: Re: [PATCH] efifb: Add support for 64-bit frame buffer addresses
Date: Mon, 31 Aug 2015 11:23:31 -0400 [thread overview]
Message-ID: <20150831152330.GC17921@redhat.com> (raw)
In-Reply-To: <1440763939-17027-1-git-send-email-matt@codeblueprint.co.uk>
On Fri, Aug 28, 2015 at 01:12:19PM +0100, Matt Fleming wrote:
> From: Matt Fleming <matt.fleming@intel.com>
>
> The EFI Graphics Output Protocol uses 64-bit frame buffer addresses
> but these get truncated to 32-bit by the EFI boot stub when storing
> the address in the 'lfb_base' field of 'struct screen_info'.
>
> Add a 'ext_lfb_base' field for the upper 32-bits of the frame buffer
> address and set VIDEO_TYPE_CAPABILITY_64BIT_BASE when the field is
> useable.
>
> It turns out that the reason no one has required this support so far
> is that there's actually code in tianocore to "downgrade" PCI
> resources that have option ROMs and 64-bit BARS from 64-bit to 32-bit
> to cope with legacy option ROMs that can't handle 64-bit addresses.
> The upshot is that basically all GOP devices in the wild use a 32-bit
> frame buffer address.
>
> Still, it is possible to build firmware that uses a full 64-bit GOP
> frame buffer address. Chad did, which led to him reporting this issue.
>
> Add support in anticipation of GOP devices using 64-bit addresses more
> widely, and so that efifb works out of the box when that happens.
>
> Reported-by: Chad Page <chad.page@znyx.com>
> Cc: Pete Hawkins <pete.hawkins@znyx.com>
> Cc: Peter Jones <pjones@redhat.com>
> Cc: Matthew Garrett <mjg59@srcf.ucam.org>
> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Looks good to me.
Acked-by: Peter Jones <pjones@redhat.com>
--
Peter
next prev parent reply other threads:[~2015-08-31 15:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-28 12:12 [PATCH] efifb: Add support for 64-bit frame buffer addresses Matt Fleming
2015-08-28 12:12 ` Matt Fleming
2015-08-28 12:12 ` Matt Fleming
[not found] ` <1440763939-17027-1-git-send-email-matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-08-31 15:23 ` Peter Jones [this message]
2015-08-31 15:23 ` Peter Jones
2015-08-31 15:23 ` Peter Jones
2015-08-31 20:24 ` Geert Uytterhoeven
2015-08-31 20:24 ` Geert Uytterhoeven
2015-08-31 20:24 ` Geert Uytterhoeven
2015-09-01 8:54 ` Matt Fleming
2015-09-01 8:54 ` Matt Fleming
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=20150831152330.GC17921@redhat.com \
--to=pjones-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=chad.page-ZTdz3wlHnvg@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org \
--cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org \
--cc=pete.hawkins-ZTdz3wlHnvg@public.gmane.org \
/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: link
Be 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.