2019-06-12 20:52:45 +03:00
==============
2010-04-07 01:34:45 +04:00
What is efifb?
2019-06-12 20:52:45 +03:00
==============
2006-08-14 10:24:16 +04:00
2020-03-20 05:00:25 +03:00
This is a generic EFI platform driver for systems with UEFI firmware. The
system must be booted via the EFI stub for this to be usable. efifb supports
both firmware with Graphics Output Protocol (GOP) displays as well as older
systems with only Universal Graphics Adapter (UGA) displays.
2006-08-14 10:24:16 +04:00
Supported Hardware
==================
2019-06-12 20:52:45 +03:00
- iMac 17"/20"
- Macbook
- Macbook Pro 15"/17"
- MacMini
2020-03-20 05:00:25 +03:00
- ARM/ARM64/X86 systems with UEFI firmware
2006-08-14 10:24:16 +04:00
How to use it?
==============
2020-03-20 05:00:25 +03:00
For UGA displays, efifb does not have any kind of autodetection of your
machine.
2019-06-12 20:52:45 +03:00
You have to add the following kernel parameters in your elilo.conf::
2006-08-14 10:24:16 +04:00
Macbook :
2010-04-07 01:34:45 +04:00
video=efifb:macbook
2006-08-14 10:24:16 +04:00
MacMini :
2010-04-07 01:34:45 +04:00
video=efifb:mini
2006-08-14 10:24:16 +04:00
Macbook Pro 15", iMac 17" :
2010-04-07 01:34:45 +04:00
video=efifb:i17
2006-08-14 10:24:16 +04:00
Macbook Pro 17", iMac 20" :
2010-04-07 01:34:45 +04:00
video=efifb:i20
2006-08-14 10:24:16 +04:00
2020-03-20 05:00:25 +03:00
For GOP displays, efifb can autodetect the display's resolution and framebuffer
address, so these should work out of the box without any special parameters.
efifb: allow user to disable write combined mapping.
This patch allows the user to disable write combined mapping
of the efifb framebuffer console using an nowc option.
A customer noticed major slowdowns while logging to the console
with write combining enabled, on other tasks running on the same
CPU. (10x or greater slow down on all other cores on the same CPU
as is doing the logging).
I reproduced this on a machine with dual CPUs.
Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz (6 core)
I wrote a test that just mmaps the pci bar and writes to it in
a loop, while this was running in the background one a single
core with (taskset -c 1), building a kernel up to init/version.o
(taskset -c 8) went from 13s to 133s or so. I've yet to explain
why this occurs or what is going wrong I haven't managed to find
a perf command that in any way gives insight into this.
11,885,070,715 instructions # 1.39 insns per cycle
vs
12,082,592,342 instructions # 0.13 insns per cycle
is the only thing I've spotted of interest, I've tried at least:
dTLB-stores,dTLB-store-misses,L1-dcache-stores,LLC-store,LLC-store-misses,LLC-load-misses,LLC-loads,\mem-loads,mem-stores,iTLB-loads,iTLB-load-misses,cache-references,cache-misses
For now it seems at least a good idea to allow a user to disable write
combining if they see this until we can figure it out.
Note also most users get a real framebuffer driver loaded when kms
kicks in, it just happens on these machines the kernel didn't support
the gpu specific driver.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Acked-by: Peter Jones <pjones@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-07-31 19:45:41 +03:00
Accepted options:
2019-06-12 20:52:45 +03:00
======= ===========================================================
efifb: allow user to disable write combined mapping.
This patch allows the user to disable write combined mapping
of the efifb framebuffer console using an nowc option.
A customer noticed major slowdowns while logging to the console
with write combining enabled, on other tasks running on the same
CPU. (10x or greater slow down on all other cores on the same CPU
as is doing the logging).
I reproduced this on a machine with dual CPUs.
Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz (6 core)
I wrote a test that just mmaps the pci bar and writes to it in
a loop, while this was running in the background one a single
core with (taskset -c 1), building a kernel up to init/version.o
(taskset -c 8) went from 13s to 133s or so. I've yet to explain
why this occurs or what is going wrong I haven't managed to find
a perf command that in any way gives insight into this.
11,885,070,715 instructions # 1.39 insns per cycle
vs
12,082,592,342 instructions # 0.13 insns per cycle
is the only thing I've spotted of interest, I've tried at least:
dTLB-stores,dTLB-store-misses,L1-dcache-stores,LLC-store,LLC-store-misses,LLC-load-misses,LLC-loads,\mem-loads,mem-stores,iTLB-loads,iTLB-load-misses,cache-references,cache-misses
For now it seems at least a good idea to allow a user to disable write
combining if they see this until we can figure it out.
Note also most users get a real framebuffer driver loaded when kms
kicks in, it just happens on these machines the kernel didn't support
the gpu specific driver.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Acked-by: Peter Jones <pjones@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-07-31 19:45:41 +03:00
nowc Don't map the framebuffer write combined. This can be used
to workaround side-effects and slowdowns on other CPU cores
when large amounts of console data are written.
2019-06-12 20:52:45 +03:00
======= ===========================================================
efifb: allow user to disable write combined mapping.
This patch allows the user to disable write combined mapping
of the efifb framebuffer console using an nowc option.
A customer noticed major slowdowns while logging to the console
with write combining enabled, on other tasks running on the same
CPU. (10x or greater slow down on all other cores on the same CPU
as is doing the logging).
I reproduced this on a machine with dual CPUs.
Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz (6 core)
I wrote a test that just mmaps the pci bar and writes to it in
a loop, while this was running in the background one a single
core with (taskset -c 1), building a kernel up to init/version.o
(taskset -c 8) went from 13s to 133s or so. I've yet to explain
why this occurs or what is going wrong I haven't managed to find
a perf command that in any way gives insight into this.
11,885,070,715 instructions # 1.39 insns per cycle
vs
12,082,592,342 instructions # 0.13 insns per cycle
is the only thing I've spotted of interest, I've tried at least:
dTLB-stores,dTLB-store-misses,L1-dcache-stores,LLC-store,LLC-store-misses,LLC-load-misses,LLC-loads,\mem-loads,mem-stores,iTLB-loads,iTLB-load-misses,cache-references,cache-misses
For now it seems at least a good idea to allow a user to disable write
combining if they see this until we can figure it out.
Note also most users get a real framebuffer driver loaded when kms
kicks in, it just happens on these machines the kernel didn't support
the gpu specific driver.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Acked-by: Peter Jones <pjones@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-07-31 19:45:41 +03:00
2020-03-20 05:00:25 +03:00
Options for GOP displays:
mode=n
The EFI stub will set the mode of the display to mode number n if
possible.
2020-03-20 05:00:27 +03:00
<xres> x<yres>[-(rgb|bgr|<bpp>)]
2020-03-20 05:00:26 +03:00
The EFI stub will search for a display mode that matches the specified
2020-03-20 05:00:27 +03:00
horizontal and vertical resolution, and optionally bit depth, and set
the mode of the display to it if one is found. The bit depth can either
"rgb" or "bgr" to match specifically those pixel formats, or a number
for a mode with matching bits per pixel.
2020-03-20 05:00:26 +03:00
2020-03-28 19:06:01 +03:00
auto
The EFI stub will choose the mode with the highest resolution (product
of horizontal and vertical resolution). If there are multiple modes
with the highest resolution, it will choose one with the highest color
depth.
2006-08-14 10:24:16 +04:00
Edgar Hucek <gimli@dark-green.com>
