| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
With the validation done for DDR3-1866 (i.e. 933 MHz bus clock), we
add the timings (rk3399-sdram-ddr3-1866.dtsi) and change rk3399-puma.dts
to use these by default.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
|
|
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
The ITS file generated warnings due to @<num> designations in the naming
which cause DTC to complain as follows:
Warning (unit_address_vs_reg): Node /images/uboot@1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /images/atf@1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /images/pmu@1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /images/fdt@1 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /configurations/conf@1 has a unit name, but no reg property
This removes the @<num> part from the names, as we only have a single
image for each payload aspect (and only a single configuration) anyway.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
|
|
defines the spl-payload to 256k (0x40000)
Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
|
|
With HDMI output for the RK3399 working, this update the RK3399-Q7
(Puma) defconfig for the new functionality:
1. enables PMIC command (to check if the HDMI voltages are correct)
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
2. enables video-output (via HDMI)
+CONFIG_DM_VIDEO=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
3. turns on the 'dcache'-command (for a dcache flush) for our QA to
fill the framebuffer using 'mw.l'
+CONFIG_CMD_CACHE=y
4. turns on the 'bmp'-command
+CONFIG_CMD_BMP=y
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-changes: 2
- enable CMD_BMP in the puma-rk3399_defconfig (following a rebase to
the upstream master after CMD_BMP was migrate to Kconfig)
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
With video output support for the RK3399-Q7 (Puma) available, we want
CMD_BMP enabled and the support for 16bit, 24bit and 32bit BMPs
defined.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Version-changes: 2
- enable SYS_WHITE_ON_BLACK via defconfig
|
|
Due to a typo, the 24 bit-per-pixel configuration ends in 24BMP
instead of 24BPP. This change renames it throughout the source tree
for consistency and to make moving these options into Kconfig easier
and less error-prone.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com)
Series-version: 2
Series-changes:
- rebase to master after CMD_BMP was migrated to Kconfig
- don't device CONFIG_BMP_24BPP twice in config_whitelist (apparently
there had been both the _24BPP and the _24BMP whitelisted before and
I didn't even spot it ... thanks go to Simon for catching this)
|
|
This commit enables HDMI output in the DTS by adding the necessary
nodes to vopl/vopb and by adding the HDMI node.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
This commit enables the RK3399 HDMI TX, which is very similar to the
one found on the RK3288. As requested by Simon, this splits the HDMI
driver into a SOC-specific portion (rk3399_hdmi.c, rk3288_hdmi.c) and
a common portion (rk_hdmi.c).
Note that the I2C communication for reading the EDID works well with
the default settings, but does not with the alternate settings used on
the RK3288... so this configuration aspect also is part of the
driverdata.
Having some sort of DTS-based configuration for the regulator
dependencies would be nice for the future, but for now we simply use
lists of regulator names (also via driverdata) that we probe.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Cover-letter:
rockchip: video: rk3399: enable HDMI output
This series provides HDMI enablement for the RK3399 and will support
video console on the RK3399 either with VOP-lit or VOP-big:
- pinctrl and clk support for the hdmi node
- a refactoring of rk_vop.c and rk_hdmi.c to allow for the minor
differences between the RK3288 and RK3399 VOP and HDMI blocks
To see the full series in the context of a working configuration (i.e.
including DTS, defconfig, etc. and on top of the MIPI enablement
change series from Rockchip), refer to
https://git.theobroma-systems.com/puma-u-boot.git/log/?h=puma-hdmi-rfc
This has been tested (on top of Eric Gao's change series for MIPI-DSI)
using 'bmp display' and 'setenv stdout vidconsole' on the RK3399-Q7
with various HDMI monitors, both for VOP-lit and VOP-big (setting the
other one to 'disabled').
END
Series-version: 3
Series-changes: 2
- removed DEBUG from the patch (as was done in our production branches,
but missing from the patch-prep branch)
- updated SJG's comment (with a TODO for the RK3288) to reflect the
new code structure
Series-changes: 3
- split into separate drivers for the SOC-specific portion of the driver
|
|
This commit enables RK3399 support for HDMI through the following
changes:
- adds a driverdata structure to mirror some subtle version
differences between the RK3399 VOPs and those in the RK3288
(e.g. the pin-polarity configuration)
- configures the VOP to output 32bpp for HDMI
- handles whether a VOP can output 10BIT data or not (i.e. RGBaaa vs. RGB888)
using the driverdata structure
And as we touch this file anyway, we also increase the size of the
framebuffer to a slightly overzealous 4K2K@32bpp.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-changes: 3
- splits the VOP driver into SOC-specific and common portions
- moves the "maximum x" and "maximum y" resolution config into Kconfig (instead
of having hard-coded values that may need to be revised each time someone adds
a new device or new features)
|
|
To add HDMI support for the RK3399, this commit provides the needed
pinctrl functionality to configure the HDMI I2C pins (used for reading
the screen's EDID).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-cc: Kever Yang <kever.yang@rock-chips.com>
Series-cc: Eric Gao <eric.gao@rock-chips.com>
Series-cc: Simon Glass <sjg@chromium.org>
|
|
This allows requests (via the DTS) for PCLK_HDMI_CTRL/PCLK_VIO_GRF,
which are clock gates in the HDMI output path for the RK3399.
As these are enabled by default (i.e. after reset), we don't implement
any logic to actively open/close these clock gates and simply assume
that their reset-default has not been changed.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
Enable mipi dsi by default for rk3399-evb board
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
|
|
Add dts config for mipi display, include vop, mipi controller, panel, backlight
. And Enable rk808 for lcd_3v3 in another patch.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
plat->size here is used to reserve frame buffer space befor relocation.
our mipi panel use 24 bitwidth, and vop require 32bit align. So the frame
buffer size should be at least 1920*1200*32/8.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Add mipi display mode for rk3399 vop, so that we can use mipi panel
for display.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Because the bitwidth is different for different display mode, so we need
to set them according to demand.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
|
|
The function clk_set_rate() will return it's input parameter, so it's return
value in normal condition is nonzero. In this case, we should report error
when it return zero rather than return a nonzero value.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
|
|
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
|
|
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Instead of having drivers/video/rockchip/Kconfig point outside of its
hierarchy for dw_hdmi.o, we should use a configuration-option to
include the Designware HDMI support.
This change introduces a new config option (not to be selected via
menuconfig, but to be selected from a dependent video driver's
configuration option) that enables dw_hdmi.o and selects it whenever
the HDMI support for Rockchip SoCs is selected.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Series-version: 2
Series-changes: 2
- renamed to CONFIG_DW_HDMI (from CONFIG_DESIGNWARE_HDMI) for consistency
with naming in the MMC and USB subsystems
|
|
Modify Makefile for rockchip video driver according to Kconfig, so that
source code will not be compiled if not needed.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
1. add Kconfig for rockchip video driver, so that video port can be
selected as needed.
2. move VIDEO_ROCKCHIP option to new Kconfig for concision.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
Drop indenting in Kconfig:
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
With everything in place (i.e. the new efuse driver, the clk-support
for the non-secure efuse block, and the board-specific functions to
derive 'serial#' from the cpu-id within the efuses), enable this in
the RK3399-Q7 defconfig.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-cc: Kever Yang <kever.yang@rock-chips.com>
Series-cc: Simon Glass <sjg@chromium.org>
Cover-letter:
rockchip: Add a read-only efuse driver for the RK3399 (and derive serial# from fuses on the RK3399-Q7)
As the RK3399-Q7 (Puma) differs from our previous modules in how we
can force an external boot (on the RK3399-Q7 this holds the eMMC and
SPI in reset, until an external signal is removed) through the 'BIOS
disable'-signal of the Qseven specification, we can't derive the
unique board id reliably from the eMMC's unique id.
Instead, for the RK3399-Q7, we rely on the efuse block of the RK3399
and use the (assumed to be unique) cpu_id region.
This patch-series adds the required infrastructure and switches the
RK3399-Q7 (puma_rk3399) over to this new infrastructure:
- adds a rockchip-efuse driver as a misc-device (and permits requests
for the clock gate listed in the DTS for the efuse node)
- ports the CRC32-based 'serial#' derivation over from Linux
- exposes the complete cpu_id field through 'cpuid#'
END
Series-version: 3
|
|
Generate a MAC address based on the cpuid available in the efuse
block: Use the first 6 byte of the cpuid's SHA256 hash and set the
locally administered bits. Also ensure that the multicast bit is
cleared.
The MAC address is only generated and set if there is no ethaddr
present in the saved environment.
Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-changes: 2
- added derivation of ethaddr from cpuid
Reviewed-by: Simon Glass <sjg@chromium.org>
Series-changes: 3
- uses uclass_get_device_by_driver() to ensure we don't pick up the wrong
misc-device
|
|
With our efuse driver for the RK3399 ready, we can add the
board-specific code that consumes the cpuid from the efuse block and
postprocesses it into the system serial (using the same CRC32 based
derivation as in Linux).
We expose the cpuid via two distinct environment variables:
serial# - the serial number, as derived in Linux
cpuid# - the raw 16 byte CPU id field from the fuse block
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
This adds a simple driver for reading the efuse block of the RK3399.
It should be easy enough to add drivers for other devices (e.g. the
RK3328, RK3368, etc.) by passing the device details via driver_data.
Unlike the kernel driver (using the nvmem subsystem), we don't expose
the efuse as multiple named cells, but rather as a linear memory that
can be read using misc_read(...).
The primary use case (as of today) is the generation of a 'serial#'
(and a 'cpuid#') environment variable for the RK3399-Q7 (Puma)
system-on-module.
Note that this adds a debug-only (i.e. only if DEBUG is defined)
command 'rk3399_dump_efuses' that dumps the efuse block's content.
N.B.: The name 'rk3399_dump_efuses' was intentionally chosen to
include a SoC-name (together with a comment in the function) to
remind whoever adds support for additional SoCs that this
function currently makes assumptions regarding the size of the
fuse-box based on the RK3399. The hope is that the function is
adjusted to reflect any changes resulting from generalising the
driver for multiple SoCs and is then renamed.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Series-changes: 3
- uses uclass_get_device_by_driver() to ensure we don't pick up the wrong
misc-device
|
|
The (non-secure) efuse node in the DTS requests PCLK_EFUSE1024NS.
To allow us to add a efuse-driver (and more importantly, to allow
probes of such a driver to succeed), we need need to accept requests
for PCLK_EFUSE1024NS and return a non-error result.
As PCLK_EFUSE1024NS is enabled by default (i.e. after reset), we don't
implement any logic to manage this clock gate and simply assume that
the reset-default has not been changed.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
With the RK3399 DRAM controller (DMC) driver providing all the
infrastructure, retrieve the DRAM size from the DMC init in the
board-specific code (instead of hard-coding) for the RK3399-Q7 (Puma).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
Adding documentation on the new config properties:
'u-boot,mmc-env-offset' - overrides CONFIG_ENV_OFFSET
'u-boot,mmc-env-offset-redundant'
- overrides CONFIG_ENV_OFFSET_REDUND
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-version: 4
Series-changes: 2
- added documentation in config.txt
|
|
This introduces the ability to override the environment offets from the
device tree by setting the following nodes in '/config':
'u-boot,mmc-env-offset' - overrides CONFIG_ENV_OFFSET
'u-boot,mmc-env-offset-redundant'
- overrides CONFIG_ENV_OFFSET_REDUND
To keep with the previous logic, the CONFIG_* defines still need to
be available and the statically defined values become the defaults,
when the corresponding properties are not set in the device-tree.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-cc: Jaehoon Chung <jh80.chung@samsung.com>
Series-changes: 3
- changes the config-check to depend on CONFIG_OF_CONTROL to detect
if 'fdtdec_get_config_int' is available
Series-changes: 4
- change the test for OF_CONTROL to use CONFIG_IS_ENABLED to pick up
the differece between SPL_OF_CONTROL and OF_CONTROL
|
|
The 'clock-freq-min-max' property was deprecated in the upstream
(i.e. Linux) DTS bindings in favor of the 'max-frequency' property.
With the latest RK3399 DTSI does no longer include the deprecated
property and the rockchip_dw_mmc driver requiring it to be present,
the driver doesn't bind to the node in the RK3399 DTSI any longer
(thus breaking access to the SD card on the RK3399-Q7 board).
To fix this, we implement a similar logic as in the Linux driver: if
the deprecated property is present, we issue a warning (if DEBUG is
enabled); if it is missing, we require 'max-frequency' to be set and
use it to create a min/max value-pair.
See https://github.com/torvalds/linux/commit/b023030f10573de738bbe8df63d43acab64c9f7b
for the deprecation/matching change in Linux.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
The clocking of the designware MMC controller in the upstream
(i.e. Linux) RK3399 has changed/does not match what the current DTS in
U-Boot uses: the first clock entry now is HCLK_SDMMC instead of
SCLK_SDMMC.
With the simple clock driver used for the RK3399, this needs a change
in the selector understood by the various case statements in the driver
to ensure that the driver still loads successfully.
Cover-letter:
With the update of the RK3399 DTS (to sync it with what the kernel uses),
the support for the Designware driver in the RK3399 needs some minor
adjustments to successfully attach:
- the clock identifier that the simple clk driver for the RK3399 sees
has changed (SCLK_SDMMC -> HCLK_SDMMC)
- the 'clock-freq-min-max' property has been deprecated upstream
For the submitted update of the DTS see:
https://patchwork.ozlabs.org/patch/752192/
For the deprecation of the 'clock-freq-min-max' property, see
https://github.com/torvalds/linux/commit/b023030f10573de738bbe8df63d43acab64c9f7b
END
Series-cc: Simon Glass <sjg@chromium.org>
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-cc: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
The kernel dts has update a lot since the first time we commit rk3399.dtsi,
sync with kernel for further development.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Since our sdram driver is ready, we can use the actual size
instead of hard code.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
|
|
This change encodes the CC list to UTF-8 to avoid failures on
maintainer-addresses that include non-ASCII characters (observed on
Debian 7.11 with Python 2.7.3).
Without this, I get the following failure:
Traceback (most recent call last):
File "tools/patman/patman", line 159, in <module>
options.add_maintainers)
File "[snip]/u-boot/tools/patman/series.py", line 234, in MakeCcFile
print(commit.patch, ', '.join(set(list)), file=fd)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 81: ordinal not in range(128)
from Heiko's email address:
[..., u'"Heiko St\xfcbner" <heiko@sntech.de>', ...]
While with this change added this encodes to:
"=?UTF-8?q?Heiko=20St=C3=BCbner?= <heiko@sntech.de>"
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
|
|
With the validation done for DDR3-1600 (i.e. 800 MHz bus clock), we
add the timings (rk3399-sdram-ddr3-1600.dtsi) and change rk3399-puma.dts
to use these by default.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Series-cc: Simon Glass <sjg@chromium.org>
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Cover-letter:
rockchip: dts: rk3399-puma: Update to use DDR3-1600 timings
With our validation having progresses to the point of tuning the DRAM
interface, we can now use a DDR3-1600 timing (i.e. 800MHz base clock)
as the default for the RK3399-Q7 (Puma).
This series
- adds a DDR3-1600 timing for the RK3399-Q7
- switches the RK3399-Q7 over to use this new timing
- cleans up some graffiti (i.e. unwanted source edits) from the
DDR3-1333 timing we had submitted earlier
END
Series-version: 1
|
|
The DDR3-1333 timings for the RK3399-Q7 (Puma) has some unintended
left-over comments in them. This change cleans the file up.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
|
|
The rockchip image generation was previously missing the ability to
verify the generated header (and dump the image-type) without having
to resort to hexdump or od. Experience in our testing has showed it
to be very easy to get the rkspi and rksd images mixed up and the
lab... so we add the necessary support to have dumpimage tell us
what image type we're dealing with.
This change set adds the verify_header and print_header capability
to the rksd/rkspi image drivers (through shared code in rkcommon).
As of now, we only support images fully that are not RC4-encoded for
the SPL payload (i.e. header1 and payload). For RC4-encoded payloads,
the outer header (header0) is checked, but no detection of whether
this is a SD/MMC or SPI formatted payload takes place.
The output of dumpsys now prints the image type (spl_hdr), whether it
is a SD/MMC or SPI image, and the (padded) size of the image:
$ ./tools/dumpimage -l ./spl.img
Image Type: Rockchip RK33 (SD/MMC) boot image
^^^^^^ SD/MMC vs. SPI indication
^^^^ spl_hdr indicated by the image
Data Size: 79872 bytes
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
Series-to: u-boot@lists.denx.de
Series-cc: Simon Glass <sjg@chromium.org>
Series-cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-cc: Kever Yang <kever.yang@rock-chips.com>
Cover-letter:
rockchip: mkimage: refactor rksd/rkspi padding calculation and add dumpimage support
We support booting both from SD/MMC images and SPI images on the
RK3399-Q7 for different use-cases (e.g. external boot in development
from the SD card, internal boot from MMC or SPI depending on whether
the SPI flash is populated on any given configuration option).
In getting the SPI image support ready for production, we found a
few areas that warranted improvements:
- we had broken SPI bootstrap earlier in the changes introducting
boot0-style images for the RK3399 (this needed fixing)
- in fixing the broken SPI padding calculation, it became apparent
that it's best to refactor and document things before we make
the same mistake again in the future
- with both SD/MMC and SPI images being used for various purposes
by various people, the wrong image style was inadvertendly used
in some tests... so we support for 'dumpimage' (i.e. verify_header
and print_header) had to be added to quickly check the image
type being handled
Note that with the refactored calculation of the image-size, we
don't pad the image to the maximum SPL size any longer, but pad
SD/MMC to the next 512 byte block (RK_BLK_SIZE) and SPI to the
next 2K boundary.
END
Series-version: 2
Series-changes: 2
- (in rkcommon_verify_header): changed to use a standard error
(i.e. from errno.h) to convey 'header0 signature does not match'
[squash of: "rockchip: mkimage: don't mix standard errors and FDT"]
|
|
The imagetool framework checks whether function pointer for the verify,
print and extract actions are available and will will handle their
absence appropriately.
This change removes the unnecessary functions and uses the driver
structure to convey available functionality to imagetool. This is in
fact better than having verify just return 0 (which previously broke
dumpimage, as dumpimage assumed that we had handled the image and did
not continue to probe further).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
