| Age | Commit message (Collapse) | Author |
|---|
|
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.
Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.
Reviewed-by: Patrice Chotard <[email protected]> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <[email protected]> #TI boards
Acked-by: Yao Zi <[email protected]> #TH1520
Signed-off-by: Peng Fan <[email protected]>
|
|
Now that we have a damage tracking API, let's populate damage done by
UEFI payloads when they BLT data onto the screen.
Signed-off-by: Alexander Graf <[email protected]>
Reported-by: Da Xue <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
[Alper: Add struct comment for new member]
Signed-off-by: Alper Nebi Yasak <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Link: https://lore.kernel.org/u-boot/[email protected]/
|
|
The log category should be LOGC_EFI all over the EFI sub-system.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
We largely do not need <common.h> in these files, so drop it. The only
exception here is that efi_freestanding.c needs <linux/types.h> and had
been getting that via <common.h>.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
The efi_gop driver uses private fields from the video uclass to obtain a
pointer to the frame buffer. Use the platform data instead.
Check the VIDEO_COPY setting to determine which frame buffer to use. Once
the next stage is running (and making use of U-Boot's EFI boot services)
U-Boot does not handle copying from priv->fb to the hardware framebuffer,
so we must allow EFI to write directly to the hardware framebuffer.
We could provide a function to read this, but it seems better to just
document how it works. The original change ignored an explicit comment
in the video.h file ("Things that are private to the uclass: don't use
these in the driver") which is why this was missed when the VIDEO_COPY
feature was added.
Signed-off-by: Simon Glass <[email protected]>
Fixes: 8f661a5b662 ("efi_loader: gop: Expose fb when 32bpp")
Reviewed-by: Bin Meng <[email protected]>
|
|
This function is not used externally.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
This relies on the old LCD implementation which is to be removed. Drop the
existing #ifdef and convert it to C code.
Signed-off-by: Simon Glass <[email protected]>
|
|
There is a number of users that use uclass_first_device to access the
first and (assumed) only device in uclass.
Some check the return value of uclass_first_device and also that a
device was returned which is exactly what uclass_first_device_err does.
Some are not checking that a device was returned and can potentially
crash if no device exists in the uclass. Finally there is one that
returns NULL on error either way.
Convert all of these to use uclass_first_device_err instead, the return
value will be removed from uclass_first_device in a later patch.
Signed-off-by: Michal Suchanek <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
There is no board left using CONFIG_LCD without CONFIG_DM_VIDEO.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Replace @return and @param.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Convert pixel values when necessary like we do for 16bpp
framebuffers.
Signed-off-by: Mark Kettenis <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Provide correct framebuffer information for 30bpp modes.
Signed-off-by: Mark Kettenis <[email protected]>
|
|
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Move this header out of the common header.
Signed-off-by: Simon Glass <[email protected]>
|
|
Add some more files to the UEFI API documentation.
Correct some Sphinx comments.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
For 5:6:5 modes provide correct frame buffer information.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() must blank the screen.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
EFI_GRAPHICS_OUTPUT_PROTOCOL.QueryMode() must allocate a buffer for the
mode information structure.
Adjust the unit test to free the buffer.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
If EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() is called with an invalid mode,
return EFI_UNSUPPORTED.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Check the parameters of EFI_GRAPHICS_OUTPUT_PROTOCOL.QueryMode().
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
If EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() is called with an invalid value of
BltOperation return EFI_INVALID_PARAMETER.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
We should consistently use the same name for protocol GUIDs as defined in
the UEFI specification. Not adhering to this rule has led to duplicate
definitions for the EFI_LOADED_IMAGE_PROTOCOL_GUID.
Adjust misnamed protocol GUIDs.
Adjust the text for the graphics output protocol in the output of the
`efidebug dh` command.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Fix typos in EFI subsystem comments.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
Rename the component parent of some EFI objects to header. This avoids
misunderstandings.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
A pointer to a struct efi_object is a handle. We do not need any handle
member in this structure. Let's eliminate it.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
In int-ll64.h, we always use the following typedefs:
typedef unsigned int u32;
typedef unsigned long uintptr_t;
typedef unsigned long long u64;
This does not need to match to the compiler's <inttypes.h>.
Do not include it.
The use of PRI* makes the code super-ugly. You can simply use
"l" for printing uintptr_t, "ll" for u64, and no modifier for u32.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
We store pixels as BGRA in memory, as can be seen from struct efi_gop_pixel.
So we need to expose the same format to UEFI payloads to actually have them
use the correct colors.
Reported-by: Fabian Vogt <[email protected]>
Tested-by: Peter Robinson <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
As part of the main conversion a few files were missed. These files had
additional whitespace after the '*' and before the SPDX tag and my
previous regex was too strict. This time I did a grep for all SPDX tags
and then filtered out anything that matched the correct styles.
Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style")
Reported-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
The GOP path was optimized, but still not as fast as it should be. Let's
push it even further by trimming the hot path into simple 32bit load/store
operations for buf->vid 32bpp operations.
Signed-off-by: Alexander Graf <[email protected]>
|
|
We usually try to compile for size, not for speed. Unfortunately with the
more powerful GOP infrastructure to handle all sorts of GOP operations, we
end up slowing down our copying hot path quite a lot.
So this patch moves the 4 possible GOP operation modes into separate
functions which call a common function again. The end result of that is
more optimized code that can properly do constant propagation throughout
its switch() statements and thus removes compares in the hot path.
Signed-off-by: Alexander Graf <[email protected]>
|
|
We optimize for size using -Os so gcc might ignore 'inline'.
Pixel conversions are called so often that we always want to inline them.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
In the Blt service of the EFI_GRAPHICS_OUTPUT_PROTOCOL the parameter delta
is measured in bytes and not in pixels.
The coding only supports delta being a multiple of four. The UEFI
specification does not explicitly require this but as pixels have a size of
four bytes we should be able to assume four byte alignment.
The corresponding unit test is corrected, too. It can be launched with
setenv efi_selftest block image transfer
bootefi selftest
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
With the patch all block image transfer operations of the
EFI_GRAPHICS_OUTPUT_PROTOCOL are supported.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
All initialization routines should return a status code instead of
a boolean.
Signed-off-by: Heinrich Schuchardt <[email protected]>
[agraf: Convert warnings to debug() prints]
Signed-off-by: Alexander Graf <[email protected]>
|
|
To avoid duplicate coding provide a helper function that
initializes an EFI object and adds it to the EFI object
list.
efi_exit() is the only place where we dereference a handle
to obtain a protocol interface. Add a comment to the function.
Suggested-by: Alexander Graf <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
Use efi_add_protocol to add protocol.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
Use efi_uintn_t instead of unsigned long.
EFI_GRAPHICS_OUTPUT_BLT_OPERATION is an enum. If we don't
define an enum we have to pass it as u32.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
Calloc may return NULL. We have to check the return value.
Fixes: be8d324191f efi_loader: Add GOP support
Signed-off-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
uclass_first_device() returns 0 if there is no device, but error if
there is a device that failed to probe.
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
Commit ca9193d2b16 ("efi_loader: gop: fixes for CONFIG_DM_VIDEO without
CONFIG_LCD") dropped the explicit (void*) cast for fb_base in efi gop support
for CONFIG_LCD without DM. This patch adds it back, eliminating the now occuring
warning again
Fixes: ca9193d2b16 ("efi_loader: gop: fixes for CONFIG_DM_VIDEO without CONFIG_LCD")
Reported-by: Tom Rini <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
Make EFI GOP support work with DM_VIDEO but without legacy LCD.
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Alexander Graf <[email protected]>
|
|
efi_open_protocol was implemented to call a protocol specific open
function to retrieve the protocol interface.
The UEFI specification does not know of such a function.
It is not possible to implement InstallProtocolInterface with the
current design.
With the patch the protocol interface itself is stored in the list
of installed protocols of an efi_object instead of an open function.
Signed-off-by: Heinrich Schuchardt <[email protected]>
[agraf: fix efi gop support]
Signed-off-by: Alexander Graf <[email protected]>
|
|
When we're running in 32bpp mode, expose the frame buffer address
to our payloads so that Linux efifb can pick it up.
Signed-off-by: Alexander Graf <[email protected]>
|
|
Some systems are starting to shift to support DM_VIDEO which exposes
the frame buffer through a slightly different interface.
This is a poor man's effort to support the dm video interface instead
of the lcd one. We still only support a single display device.
Signed-off-by: Alexander Graf <[email protected]>
[trini: Remove fb_size / fb_base as they were not used]
Signed-off-by: Tom Rini <[email protected]>
|
|
Recently Linux is gaining support for efifb on AArch64 and that support actually
tries to make use of the frame buffer address we expose to it via gop.
While this wouldn't be bad in theory, in practice it means a few bad things
1) We expose 16bit frame buffers as 32bit today
2) Linux can't deal with overlapping non-PCI regions between efifb and
a different frame buffer driver
For now, let's just disable exposure of the frame buffer address. Most OSs that
get booted will have a native driver for the GPU anyway.
Signed-off-by: Alexander Graf <[email protected]>
[trini: Remove line_len entirely]
Signed-off-by: Tom Rini <[email protected]>
|
|
The EFI standard defines a simple boot protocol that an EFI payload can use
to access video output.
This patch adds support to expose exactly that one (and the mode already in
use) as possible graphical configuration to an EFI payload.
With this, I can successfully run grub2 with graphical output.
Signed-off-by: Alexander Graf <[email protected]>
|
