From: agraf@suse•de (Alexander Graf)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 0/8] EFI framebuffer support for ARM and arm64
Date: Fri, 11 Mar 2016 18:52:54 +0100 [thread overview]
Message-ID: <56E305F6.5070402@suse.de> (raw)
In-Reply-To: <CAKv+Gu8imCVQ+8QM+txqXNgs54p2Uv3FMkQEMNoCkB8JJcaZUw@mail.gmail.com>
On 10.03.16 17:23, Ard Biesheuvel wrote:
> (+ Laszlo)
>
> On 10 March 2016 at 23:12, Mark Langsdorf <mlangsdo@redhat•com> wrote:
>> On 03/09/2016 11:40 PM, Ard Biesheuvel wrote:
>>>
>>> This series adds support to ARM and arm64 for using the kernel's EFI
>>> framebuffer driver to drive EFI Graphics Output Protocol (GOP) based
>>> framebuffers.
>>>
>>> This involves refactoring some of the existing x86 code so it can be
>>> reused
>>> by ARM and arm64, and wiring it up both in the UEFI stub and in the core
>>> kernel into the existing UEFI infrastructure for ARM and arm64.
>>
>>
>> Given that I have access to a variety of different ARM64 UEFI
>> implementations, how would I go about testing this code? Do I
>> need a specific UEFI implementation and are there any special
>> command line arguments I should pass to the kernel?
>>
>
> I have tested this myself on QEMU and FVP Base, which are both
> software models. On bare metal, it would involve a system with a
> graphics card that the firmware knows how to drive, and I am honestly
> not sure if any such combinations currently exist, other than the ARM
> development platforms such as Juno which have an embedded-style (i.e.,
> non-PCI) graphics controller that the firmware knows how to drive out
> of the box.
>
> The code itself is smart enough to figure which (if any) of the
> available handles carrying the GOP protocol is the one that is
> attached to ConOut, and so there is nothing required to enable this
> other than building it into the kernel and running it on a system with
> a firmware supported screen attached.
>
How does this deal with caches? Does the GOP driver access the frame
buffer as cached or as uncached memory? I suppose it's always uncached?
I'm mostly curious because I'd like to implement support for GOP in
U-Boot soon.
Alex
next prev parent reply other threads:[~2016-03-11 17:52 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 5:40 [PATCH 0/8] EFI framebuffer support for ARM and arm64 Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 1/8] efi: make install_configuration_table() boot service usable Ard Biesheuvel
2016-03-18 10:59 ` Matt Fleming
2016-03-18 11:02 ` Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 2/8] efi: libstub: move Graphics Output Protocol handling to generic code Ard Biesheuvel
2016-03-18 11:25 ` Matt Fleming
2016-03-10 5:40 ` [PATCH 3/8] efi/x86: libstub: move to generic GOP code Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 4/8] efi/x86: efifb: move DMI based quirks handling out of generic code Ard Biesheuvel
2016-03-18 10:50 ` Matt Fleming
2016-03-21 13:42 ` Peter Jones
2016-03-10 5:40 ` [PATCH 5/8] efi: efifb: use builtin_platform_driver and drop unused includes Ard Biesheuvel
2016-03-18 10:52 ` Matt Fleming
2016-03-21 13:43 ` Peter Jones
2016-03-10 5:40 ` [PATCH 6/8] efi/arm*: libstub: wire up GOP handling into the ARM UEFI stub Ard Biesheuvel
2016-03-10 8:25 ` Ingo Molnar
2016-03-10 8:36 ` Ard Biesheuvel
2016-03-10 9:03 ` Ingo Molnar
2016-03-10 9:14 ` Ard Biesheuvel
2016-03-10 9:25 ` Ingo Molnar
2016-03-10 10:25 ` Ard Biesheuvel
2016-03-10 14:49 ` Matt Fleming
2016-03-10 14:30 ` Matt Fleming
2016-03-18 11:37 ` Matt Fleming
2016-03-10 5:40 ` [PATCH 7/8] efi/arm*: efifb: expose efifb platform device if GOP is available Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 8/8] efi/arm: populate screen_info based on data provided by the UEFI stub Ard Biesheuvel
2016-03-18 11:53 ` Matt Fleming
2016-03-18 11:57 ` Ard Biesheuvel
2016-03-10 16:12 ` [PATCH 0/8] EFI framebuffer support for ARM and arm64 Mark Langsdorf
2016-03-10 16:23 ` Ard Biesheuvel
2016-03-11 17:52 ` Alexander Graf [this message]
2016-03-11 18:24 ` Ard Biesheuvel
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=56E305F6.5070402@suse.de \
--to=agraf@suse$(echo .)de \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox