Add ddr voltage rail (dcdc3) configuration. Set the dcdc3
DDR supply to 1.35V.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Some boards like am437x-gp-evm require dcdc3 also to be configured
as it feeds on to ddr. Hence add the capability as well.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
The Kconfig entry depends on RMOBILE, but this was renamed
to ARCH_RMOBILE in commit 1cc95f6e1b (ARM: Rmobile: Rename
CONFIG_RMOBILE to CONFIG_ARCH_RMOBILE) . Fix this omission.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
R-Car Gen3 series have four SD card interfaces (SDHI0 to SDHI3),
two of which can also be used as MMC interfaces (SDHI2 and SDHI3).
This adds High-speed mode SD clock frequency between 25MHz and 50MHz,
8bit/4bit bus width, high capacity and low voltage device support.
Signed-off-by: Kouei Abe <kouei.abe.cp@renesas.com>
Cc: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The existing test (patman --test) only covers basic checkpatch output.
We have had some problems with unicode processing and could use test
coverage for the various tags patman supports.
Add a new functional test which runs most of the patman flow on a few
test commits and checks that the results are correct.
See the documentation in the test for a description of what it does.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
This is not a good variable name in Python because 'list' is a type. It
shows up highlighted in some editors. Rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Allow the add_maintainers parameter to be a list of maintainers, thus
allowing us to simulate calling the script in tests without actually
needing it to work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Add some unicode to the test patches to make sure that patman does the
right thing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
There is no need for this function to return the same object that was
passed in. Drop the return value.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Unicode characters may appear in input patches so we should not warn about
them. Drop this warning.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
This is not a good variable name in Python because 'str' is a type. It
shows up highlighted in some editors. Rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
The communication filter reads data in blocks and converts each block to
unicode (if necessary) one at a time. In the unlikely event that a unicode
character in the input spans a block this will not work. We get an error
like:
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1022-1023:
unexpected end of data
There is no need to change the input to unicode, so the easiest fix is to
drop this feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Don't mess with the email address when outputting them. Just make sure
they are encoded with utf-8.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
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>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
In the case where a new build only decreases sizes and does not increase
any size we still want to report what functions have been dropped when
doing a bloat comparison.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In os_dirent_get_typename() we are checking that type falls within the
known values of the enum os_dirent_t. With clang-3.8 testing this value
as being >= 0 results in a warning as it will always be true. This
assumes of course that we are only given valid data. Given that we want
to sanity check the input, we change this to check that it falls within
the range of the first to the last entry in the given enum.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
On ARM v7M, the processor will return to ARM mode when executing blx
instruction with bit 0 of the address == 0. Always set it to 1 to stay in thumb
mode.
At present, it is applied only for raw U-Boot. This patch moves it to just
before booting next image. This way armv7m will be in thumb mode for any image
like raw or image with header like zImage or standard U-Boot.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
The SoPine is a SoM by Pine64, with an Allwinner A64 SoC, a LPDDR3 DRAM
chip, an AXP803 PMIC, a SPI NOR Flash and a MicroSD slot. The card
detect pin of the MicroSD slot is broken, however, it doesn't matter as
the design of SoPine didn't allow hot-swapping the MicroSD card (The
MicroSD slot is at the back of the SoM, and when the SoM is installed on
the baseboard, it's nearly impossible to remove the MicroSD).
The official baseboard of it is a board with nearly the same connectors
with the original Pine64+, with the MicroUSB power jack replaced, and
at the position of MicroSD slot a eMMC module slot is added.
Add support for SoPine with the official baseboard by adding its
defconfig file. It still uses the device tree of Pine64, however, it
will change after a proper device tree of SoPine with baseboard is
accepted by Linux mainline.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
[Update board/sunxi/MAINTAINERS]
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
As we added LPDDR3 support in the former patch, we need a set of timing
info to really enable it.
Add the timing info used by stock boot0.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Some A64 boards (SoPine and Pinebook production batch) use LPDDR3 DRAM
chips.
Add support for LPDDR3 DRAM in the DesignWare-like DRAM controller code.
Real LPDDR3 chips' support is not added yet in this commit.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
As we have already support for the DesignWare DRAM controller and the
integrated DDR2 chip of V3s, let's enable the SPL support for V3s.
This patch also contains the default DRAM configuration for V3s.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Allwinner V3s features a DRAM controller like the on in H3, but with a
DDR2 DRAM.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Allwinner V3s SoC features a co-packaged DDR2 DRAM chip, which needs its
timing param.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
The DesignWare-like DRAM code used to set the controller defaultly to
single rank mode, which makes it not able to detect the second rank.
Set the default value to dual rank, thus the rank detection code can
work and finally the rank setting will be the correct value.
Currently we know little about the dual-rank on R40, and the usage
of A15 address line seems to be breaking dual-rank support. The only R40
board currently available (Sinovoip Banana Pi M2 Ultra) uses A15 rather
than dual-rank, thus we cannot do research for it. So dual rank detection
is temporarily disabled on R40.
This change is tested on a Orange Pi One (H3, single rank), a Pine64+
2GiB version (A64, single rank) , a Pinebook early prototype with DDR3
(A64, dual rank) and a SoPine with some LPDDR3 patch (A64, dual CS pins
on one chip).
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
DRAM chip varies, and one code cannot satisfy all DRAMs.
Add options to select a timing set.
Currently only DDR3-1333 (the original set) is added into it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Some DDR2 DRAM have only four banks, not eight.
Add code to detect this situation.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Some Allwinner SoCs features a DesignWare-like controller with only 16
bit bus width.
Add support for them.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
The DesignWare DRAM controller used by H3 and newer SoCs use a bit to
identify whether the DRAM is half-width.
As H3 itself come with 32-bit DRAM, the two modes of the bit used to be
named "MCTL_CR_32BIT" and "MCTL_CR_16BIT", but for SoCs with 16-bit DRAM
they're really 8-bit and 16-bit.
Rename the bit's macro, and also rename the variable name in
dram_sun8i_h3.c.
This commit do not add 16-bit DRAM controller support, but the support
will be introduced in next commit.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Allwinner SoCs after H3 (e.g. A64, H5, R40, V3s) uses a H3-like
DesignWare DRAM controller, which do not have official free DRAM
initialization code, but can use modified dram_sun8i_h3.c.
Add a invisible option for easier DRAM initialization code reuse.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
NanoPi M1 Plus is designed and developed by FriendlyElec
for professionals, enterprise users, makers and hobbyists
using the Allwinner H3 SOC.
NanoPi M1 Plus key features
- Allwinner H3, Quad-core Cortex-A7@1.2GHz
- 1GB DDR3 RAM
- 8GB eMMC
- microSD slot
- 10/100/1000M Ethernet
- Serial Debug Port
- 5V 2A DC power-supply
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Here is additional rk3368 and rk3399 support, rv1108 support,
refactoring HDMI video (brought in from Anatolij's tree to resolve
conflicts), some mkimage fixes and a few other things.
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
Reviewed-by: Simon Glass <sjg@chromium.org>
The last set of rebases had dropped the 'grf' field from the common
rk_vop. Add this back to un-break the build (and driver).
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... this configuration aspect is reflected by the driverdata
for the RK3399 driver.
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>
Reviewed-by: Simon Glass <sjg@chromium.org>
To prepare for the addition of RK3399 HDMI support, the HDMI driver is
refactored and broken into a chip-specific and a generic part. This
change adds the internal interfaces, makes common/reusable functions
externally visible and splits the RK3288 driver into a separate file.
For the probing of regulators, we reuse the infrastructure created
during the VOP refactoring... i.e. we simply call into the helper
function defined for the VOP.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The Linux driver now supports higher mpixelclock settings.
Add these to rockchip_phy_config[] and rockchip_mpll_cfg[].
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This commit adds a driver for the RK3399 VOPs capable and all the
necessary plumbing to feed the HDMI encoder. For the VOP-big, this
correctly tracks the ability to feed 10bit RGB data to the encoder.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
To prepare for adding the RK3399 VOP driver (which shares most of its
registers and config logic with the RK3228 VOP), this change refactors
the driver and splits the RK3288-specific driver off.
The changes in detail are:
- introduces a data-structure for chip-specific drivers to register
features/callbacks with the common driver: at this time, this is
limited to a callback for setting the pin polarities (between the
VOP and the encoder modules) and a flag to signal 10bit RGB
capability
- refactors the probing of regulators into a helper function that
can take a list of regulator names to probe and autoset
- moves the priv data-structure into a (common) header file to be
used by the chip-specific drivers to provide base addresses to
the common driver
- uses a callback into the chip-specific driver to set pin polarities
(replacing the direct register accesses previously used)
- splits enabling the output (towards an encoder) into a separate
help function withint the common driver
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This introduces two new Kconfig options that configure the maximum
allowable framebuffer size (i.e. the memory reservation/allocation for
the framebuffer):
- VIDEO_ROCKCHIP_MAX_XRES
- VIDEO_ROCKCHIP_MAX_YRES
The resulting memory allocation will cover 4 byte per pixel for these
resolutions.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
For consistency sake (and as we are about to add new options to this
file), reformat the help for VIDEO_ROCKCHIP.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
For the RK3399-Q7, we need spl_board_init to be called during SPL
startup to set up the pinmux for the debug UART. Enable SPL_BOARD_INIT
via defconfig to ensure this function is in fact called.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
RK3288_TXCLK_DLY_ENA_GMAC_ENABLE, in GRF_SOC_CON3, is supposed to be bit
0xe and not 0xf. Otherwise, it is RGMII RX clock delayline enable and
introduces random delays and data lose.
This commit fixes the issue by replacing RK3288_TXCLK_DLY_ENA_GMAC_ENABLE
with the right shift.
Signed-off-by: Romain Perier <romain.perier@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds the DDR3-1866 timing via its own DTS and wires it up. This
(currently) is not the default timing for the RK3399-Q7 and should be
selected explicitly via the config (CONFIG_DEFAULT_DEVICE_TREE).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
This adds the DDR3-1333 timing via its own DTS and wires it up. This
is not the default timing for the RK3399-Q7 and should be selected
explicitly via the config (CONFIG_DEFAULT_DEVICE_TREE).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
To better support different RAM timings (DDR3-1333 and DDR3-1866 are
assembly options for the RK3399-Q7), this refactors the DTS support
and renames the default DTS variant from rk3399-puma to
rk3399-puma-ddr1600:
- changes the rk3399-puma DTS into a board-specific DTSI by removing
the inclusion of the DRAM timings
- adds a new rk3399-puma-ddr1600.dts, which includes the (new) common
board DTSI and the DDR3-1600 timing DTSI
- wires this up from arch/arm/dts/Makefile and configs/puma-rk3399_defconfig
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
Keerthy
Marek Vasut
Kouei Abe
Simon Glass
Philipp Tomsich
Tom Rini
Vikas Manocha
Icenowy Zheng
Icenowy Zheng
Jagan Teki
Romain Perier