Adam Ford [Tue, 21 Aug 2018 12:16:56 +0000 (07:16 -0500)]
mmc: omap_hsmmc: Make DM_GPIO calls dependent on DM_GPIO
The getcd and getwp functions when DM_MMC is enabled are
assumming the DM_GPIO is enabled. In cases (like SPL) where
DM_GPIO may not be enabled, wrap these calls in an #ifdef
Adam Ford [Tue, 21 Aug 2018 01:43:00 +0000 (20:43 -0500)]
DM: serial: ti_omap3_common: Don't define serial unless !DM_SERIAL
The serial port was being manually configured during SPL build,
however in preparation to allow DM in SPL, this needs to change
to be based on whether or not DM_SERIAL is enabled because, soon
the assumption that SPL means no DM may not be accurate.
Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Adam Ford [Tue, 21 Aug 2018 01:34:00 +0000 (20:34 -0500)]
ARM: mach-omap2: Don't initialize I2C if DM_I2C is enabled
boot-common.c checks to see if I2C is enabled in SPL, but
it doens't check for DM_I2C before initializing it. This
will now only initialize the I2C is the DM_I2C is not enabled
to avoid initializing it more than once.
Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Adam Ford [Tue, 21 Aug 2018 01:27:48 +0000 (20:27 -0500)]
DM: omap_gpio: Reduce overhead when used with OF_PLATDATA
Platforms with limited resources in SPL may enable OF_PLATDATA,
this limits some of the library functions and cannot extract data
from the device tree. This patch adds additional wrappers around
these functions to only allow them when OF_CONTROL is enabled and
OF_PLATDATA is not.
Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Adam Ford [Tue, 21 Aug 2018 01:24:35 +0000 (20:24 -0500)]
DM: OMAP24XX_I2C: Reduce overhead when used with OF_PLATDATA
Platforms with limited resources in SPL may enably OF_PLATDATA,
this limits some of the library functions and cannot extract data
from the device tree. This patch adds additional wrappers around
these functions to only allow them when OF_CONTROL is enabled and
OF_PLATDATA is not.
Adam Ford [Tue, 21 Aug 2018 01:24:34 +0000 (20:24 -0500)]
DM: I2C: Reduce overhead when used with OF_PLATDATA
Platforms with limited resources in SPL may enably OF_PLATDATA,
this limits some of the library functions and cannot extract data
from the device tree. This patch adds additional wrappers around
these functions to only allow them when OF_CONTROL is enabled and
OF_PLATDATA is not.
Adam Ford [Fri, 17 Aug 2018 04:13:34 +0000 (23:13 -0500)]
DM: GPIO: Fix da8xx GPIO indexing over GPIO 32
The GPIO banks are broken up into two 16-bit registers for each
bank set. Unfortunately, the math that determines how to shift
blindly shifted by the number of the gpio. This worked for gpio
numbers under 32, but higher gpio's are broken. This fixes the
gpio index, so the bank is passed and the shift amount within
the register is passed now instead of the gpio number.
Fixes: 8e51c0f25406("dm: gpio: Add DM compatibility to
GPIO driver for Davinci")
Adam Ford [Wed, 15 Aug 2018 18:22:03 +0000 (13:22 -0500)]
ARM: configs: Add da850evm_nand to boot from NAND
The DA850-EVM supports booting from NAND when used with the
UI expander board. da850evm_nand will create an ais file
that can be burned to NAND and booted while storing the env in
NAND along with some partitions tables for storing kernel,
dtb and rootfs in NAND.
include: am654_evm: Establish initial environment for SD card boot
Create a basic U-Boot environment that allows the automatic loading
of a Linux Kernel located at /boot/Image and an associated device tree
blob located at /boot/k3-am654-base-board.dtb from the secondary
partition of an ext4-formatted SD card on the AM654x EVM. Furthermore
the boot.scr and uEnv.txt detection and loading schemes are supported
in a manner already known from other TI platforms.
Note that this is intended to be a starting point to enable initial
board use and will most certainly get extended and refactored as
different boot media become available.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Lokesh Vutla [Mon, 27 Aug 2018 10:27:51 +0000 (15:57 +0530)]
remoteproc: Introduce K3 system controller
K3 specific SoCs have a dedicated microcontroller for doing
resource management. Any HLOS/firmware on compute clusters should
load a firmware to this microcontroller before accessing any resource.
Adding support for loading this firmware.
After the K3 system controller got loaded with firmware and started
up it sends out a boot notification message through the secure proxy
facility using the TI SCI protocol. Intercept and receive this message
through the rproc start operation which will need to get invoked
explicitly after the firmware got loaded.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Lokesh Vutla [Mon, 27 Aug 2018 10:27:50 +0000 (15:57 +0530)]
remoteproc: Allow for individual remoteproc initialization
Existing rproc_init() api tries to initialize all available
remoteproc devices. This will fail when there is dependency
among available remoteprocs. So introduce a separate api
that allows to initialize remoteprocs individually based
on id.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Lokesh Vutla [Mon, 27 Aug 2018 10:27:47 +0000 (15:57 +0530)]
mailbox: Allow attaching private data for mbox_chan
Sometimes mbox controllers wants to store private data in
mbox_chan so that it can be used at a later point of time.
Adding support for hooking private data.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
sysreset: Add TI System Control Interface (TI SCI) sysreset driver
Devices from the TI K3 family of SoCs like the AM654x contain a Device
Management and Security Controller (SYSFW) that manages the low-level
device control (like clocks, resets etc) for the various hardware
modules present on the SoC. These device control operations are provided
to the host processor OS through a communication protocol called the TI
System Control Interface (TI SCI) protocol.
This patch adds a system reset driver that communicates to the system
controller over the TI SCI protocol for allowing to perform a system-
wide SoC reset.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
power domain: Introduce TI System Control Interface (TI SCI) power domain driver
Some TI Keystone 2 and K3 family of SoCs contain a system controller
(like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and
the Device Management and Security Controller on AM65x SoCs) that manage
the low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations are
provided to the host processor OS through a communication protocol
called the TI System Control Interface (TI SCI) protocol.
This patch adds a power domain driver that communicates to the system
controller over the TI SCI protocol for performing power management of
various devices present on the SoC. Various power domain functionalities
are achieved by the means of different TI SCI device operations provided
by the TI SCI framework.
This code is loosely based on the drivers/soc/ti/ti_sci_pm_domains.c
driver of the Linux kernel.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Lokesh Vutla [Mon, 27 Aug 2018 10:27:44 +0000 (15:57 +0530)]
power domain: Add support for multiple powerdomains per device
There are cases where there are more than one power domain
attached to the device inorder to get the device functional.
So add support for enabling power domain based on the index.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
clk: Introduce TI System Control Interface (TI SCI) clock driver
Some TI Keystone 2 and K3 family of SoCs contain a system controller
(like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and
the Device Management and Security Controller on AM65x SoCs) that manage
the low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations are
provided to the host processor OS through a communication protocol
called the TI System Control Interface (TI SCI) protocol.
This patch adds a clock driver that communicates to the system
controller over the TI SCI protocol for performing clock management of
various devices present on the SoC. Various clock functionality is
achieved by the means of different TI SCI device operations provided by
the TI SCI framework.
This code is loosely based on the drivers/clk/keystone/sci-clk.c driver
of the Linux kernel.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
clk: Extend clock control with an optional data field
Some systems require more than a single ID to identify and configure any
clock provider. For those scenarios add an optional data field to the
clock control structure.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
reset: Introduce TI System Control Interface (TI SCI) reset driver
Some TI Keystone 2 and K3 family of SoCs contain a system controller
(like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and
the Device Management and Security Controller on AM65x SoCs) that manage
the low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations are
provided to the host processor OS through a communication protocol
called the TI System Control Interface (TI SCI) protocol.
This patch adds a reset driver that communicates to the system
controller over the TI SCI protocol for performing reset management of
various devices present on the SoC. Various reset functionalities are
achieved by the means of different TI SCI device operations provided by
the TI SCI framework.
This code is loosely based on the drivers/reset/reset-ti-sci.c driver of
the Linux kernel.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
reset: Extend reset control with an optional data field
Some systems require more than a single ID to identify and configure any
reset provider. For those scenarios add an optional data field to the
reset control structure.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
To support scenarios where a firmware device node has subnodes that
have their own drivers automatically scan the DT and bind those when
the firmware device gets bound.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Lokesh Vutla [Mon, 27 Aug 2018 10:27:37 +0000 (15:57 +0530)]
firmware: ti_sci: Add support for processor control services
TI-SCI message protocol provides support for controlling of various
physical cores available in SoC. In order to control which host is
capable of controlling a physical processor core, there is a processor
access control list that needs to be populated as part of the board
configuration data.
Introduce support for the set of TI-SCI message protocol apis that
provide us with this capability of controlling physical cores.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Lokesh Vutla [Mon, 27 Aug 2018 10:27:35 +0000 (15:57 +0530)]
firmware: ti_sci: Add support for clock control
In general, we expect to function at a device level of abstraction,
however, for proper operation of hardware blocks, many clocks directly
supplying the hardware block needs to be queried or configured.
Introduce support for the set of SCI message protocol support that
provide us with this capability.
TI-SCI message protocol provides support for management of various
hardware entitites within the SoC. Introduce the fundamental
device management capability support to the driver protocol
as part of this change.
firmware: ti_sci: Add support for board configuration
TI-SCI message protocol provides support for board configuration
to assign resources and other board related operations.
Introduce the board configuration capability support to the driver protocol
as part of this change.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Lokesh Vutla [Mon, 27 Aug 2018 10:27:32 +0000 (15:57 +0530)]
firmware: Add basic support for TI System Control Interface (TI SCI) protocol
Texas Instrument's System Control Interface (TI SCI) message protocol is
used in Texas Instrument's System on Chip (SoC) such as those in the K3
family AM654 SoC to communicate between various compute processors with
a central system controller entity.
The TI SCI message protocol provides support for management of various
hardware entities within the SoC. Add support driver to allow
communication with system controller entity within the SoC using the
mailbox client.
This is mostly derived from the TI SCI driver in Linux located at
drivers/firmware/ti_sci.c.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Lokesh Vutla [Mon, 27 Aug 2018 10:27:14 +0000 (15:57 +0530)]
armv8: K3: am654: Introduce FIT generator script
Add a script that is capable of generating a FIT image
source file that combines ATF, SPL(64 bit) and DT.
This combined image is used by R5 SPL and start ATF
on ARMv8 core.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Lokesh Vutla [Mon, 27 Aug 2018 10:27:11 +0000 (15:57 +0530)]
arm: K3: am654: Add support for boot device detection
AM654 allows for booting from primary or backup boot media.
Both media can be chosen individually based on switch settings.
ROM looks for a valid image in primary boot media, if not found
then looks in backup boot media. In order to pass this boot media
information to boot loader, ROM stores a value at a particular
address. Add support for reading this information and determining
the boot media correctly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Vignesh R <vigneshr@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Lokesh Vutla [Mon, 27 Aug 2018 10:27:10 +0000 (15:57 +0530)]
arm: K3: Update _start instruction
On K3 family SoCs, once the ROM loads image on R5, M3 resets R5 and
expects to start executing from 0x0. In order to handle this ROM
updates the boot vector of R5 such that first 64 bytes of image load
address are mapped to 0x0.
In this case, it is SPL's responsibility to jump to the proper image
location. So, update the PC with address of reset vector(like how
other exception vectors are handled), instead of branching to reset.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Lokesh Vutla [Mon, 27 Aug 2018 10:27:09 +0000 (15:57 +0530)]
arm: K3: Add support for AM654 SoC definition
The AM654 device is designed for industrial automation and PLC
controller class platforms among other applications. Introduce
base support for AM654 SoC.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN again
With the migration to distro-boot, the size of the U-Boot proper
image for uniphier_v7_defconfig exceeded the current limit, 576KB.
Increase it to 832KB.
CONFIG_SYS_UBOOT_BASE must be moved as well to avoid the image
over-wrap because the boot ROM of Pro4, Pro5, PXs2/LD6b loads
the SPL to the physical address 0x100000.
Michal Simek [Thu, 26 Jul 2018 13:33:51 +0000 (15:33 +0200)]
cmd: fpga: Add support for missing fpga loadmk commands
There are ways how to call fpga loadmk
1. Full command
fpga loadmk [dev] [address]
2. Dev setup via variable
set fpga [dev]
fpga loadmk [address]
3. Address setup via variable
set fpgadata [address]
fpga loadmk [dev]
4. Dev and address setup via variables
set fpga [dev]
set fpgadata [address]
fpga loadmk
Before this patch only cases 1 and 3 are working but the part of code
was trying to support also cases 2 and 4.
This patch is adding support for cases 2 and 4 to have all of
combinations supported.
Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Michal Simek [Mon, 4 Jun 2018 12:57:34 +0000 (14:57 +0200)]
cmd: fpga: Extract fpga info command to separate function
Move fpga info to U_BOOT_CMD_MKENT subcommand.
Also use strtol instead of simple_strtoul. The reason is that if -1 is
passed (or fpga info without "fpga" variable) the list of all fpgas is
shown.
This functionality is in the fpga core but it couldn't be performed.
Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Michal Simek [Wed, 30 May 2018 09:28:57 +0000 (11:28 +0200)]
cmd: fpga: Clean wrong_parms handling
There is no reason to check parameters in separate switch. Check them
directly when they are read. Also there is no reason to check loadmk
case separately because fpga_data address must be non zero too.
Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Michal Simek [Mon, 4 Jun 2018 11:57:19 +0000 (13:57 +0200)]
cmd: fpga: Remove parameter checking from fpga loadfs command
Parameter checking is dead code because all the time there must be all
params assigned. If they are not assigned there is no 9th parameters
passed and checking before return CMD_RET_USAGE.
Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Michal Simek [Wed, 30 May 2018 09:18:38 +0000 (11:18 +0200)]
cmd: fpga: Move parameter checking for loadfs/loads
There is no reason to check parameters in separate switch before main
one. This patch is simplifying error path and checking parameters right
after assignment.
Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Michal Simek [Wed, 30 May 2018 08:04:34 +0000 (10:04 +0200)]
cmd: fpga: Cleanup error handling in connection to FPGA_NONE
Incorrect command is already handled and FPGA_NONE should be used only
one. In case of error CMD_RET_USAGE can be returned directly without any
addition logic around.
Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
+ if (dev == FPGA_INVALID_DEVICE) {
+ puts("FPGA device not specified\n");
+ op = FPGA_NONE;
+ }
which simply broke one command flow which was
setenv fpga <dev>
fpga loadmk <addr> // legacy image
fpga loadmk <addr>:<fit_image_name> //fit image
Also this sequence for FIT image is completely broken
setenv fpga <dev>
setenv fpgadata <addr>:<fit_image_name>
fpga loadmk
(Note: For legacy images this is working fine).
even from code I don't think this has ever worked properly
for fit image (dev = FPGA_INVALID_DEVICE should be rejected
by fpga core). Fit image support was in 2008 added by:
"[new uImage] Add new uImage fromat support to fpga command"
(sha1: c28c4d193dbfb20b2dd3a5447640fd6de7fd0720)
Just a summary of these facts that none found this for pretty long time
it shouldn't be a problem to remove this flow (without fpga dev)
completely to simplify the code.
Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Mark Tomlinson [Tue, 28 Aug 2018 22:51:14 +0000 (10:51 +1200)]
tools: mkimage: Ensure munmap unmaps the same length that was mapped
The set_header call in kwbimage.c adds a checksum to the end of the
image in addition to setting up the header. It 'helpfully' updates the
st_size to match the fact that the file is now longer. However, mkimage
uses this length in the munmap call. This can lead to unmapping an extra
page, of perhaps required data. When this happens, a SEGV can occur.
To prevent this from happening, the munmap call now uses the same length
that was passed to mmap. This could also have been fixed by not changing
the length in kwbimage.c, however changing it in the main file means
that other plugins will also not fall for the same trap.
Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> Signed-off-by: Chris Packham <judge.packham@gmail.com>
[cp: resolve checkpatch complaints] Tested-by: Chris Packham <judge.packham@gmail.com>
Add support for loading U-Boot on the Broadcom 7260 SoC. This port
assumes Broadcom's BOLT bootloader is acting as the second stage
bootloader, and U-Boot is acting as the third stage bootloader, loaded
as an ELF program by BOLT.
Change the configured serial console index to reflect that it is the
first physical UART, reorder some defconfig lines and move some
environment configuration from bcmstb.h to bcm7445.h.
Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org> Cc: Florian Fainelli <f.fainelli@gmail.com>
Adam Ford [Thu, 16 Aug 2018 18:23:11 +0000 (13:23 -0500)]
ARM: CPU: arm926ejs: Consolidate cache routines to common file
Four different boards had different options for enabling cache
that were virtually all the same. This consolidates these
common functions into arch/arm/cpu/arm926ejs/cache.c
This also has the positive side-effect of enabling cache on
the Davinci (da850) boards.
Signed-off-by: Adam Ford <aford173@gmail.com>
[trini: Add mach-at91 to the list of consolidations] Signed-off-by: Tom Rini <trini@konsulko.com>
Lokesh Vutla [Thu, 16 Aug 2018 13:11:49 +0000 (18:41 +0530)]
pinctrl: Fix build warning with ARM64
Following build warning appears when pinctrl-single is built for ARM64:
In file included from drivers/pinctrl/pinctrl-single.c:10:0:
drivers/pinctrl/pinctrl-single.c: In function ‘single_configure_pins’:
./arch/arm/include/asm/io.h:43:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#define __arch_getw(a) (*(volatile unsigned short *)(a))
Fix this by using phys_addr_t for variable reg instead of u32
Lokesh Vutla [Thu, 16 Aug 2018 12:56:55 +0000 (18:26 +0530)]
dm: omap-timer: Update clock rate only if not populated
timer_pre_probe() tries to populate the clock rate from DT. omap
timer driver tries to overwrite this value irrespective of the value
populated fro DT. So update this value only when DT doesn't populate
the clock rate.
Peng Fan [Fri, 10 Aug 2018 06:07:55 +0000 (14:07 +0800)]
mmc: fsl_esdhc: enable HS400 feature
The strobe dll code is ported from Linux Kernel:
drivers/mmc/host/sdhci-esdhc-imx.c
The comments are from the above file,
"For HS400 eMMC, there is a data_strobe line. This signal is generated
by the device and used for data output and CRC status response output
in HS400 mode. The frequency of this signal follows the frequency of
CLK generated by host. The host receives the data which is aligned to the
edge of data_strobe line. Due to the time delay between CLK line and
data_strobe line, if the delay time is larger than one clock cycle,
then CLK and data_strobe line will be misaligned, read error shows up.
So when the CLK is higher than 100MHz, each clock cycle is short enough,
host should configure the delay target. "
Peng Fan [Fri, 10 Aug 2018 06:07:54 +0000 (14:07 +0800)]
mmc: add HS400 support
Add HS400 support.
Selecting HS400 needs first select HS200 according to spec, so use
a dedicated function for HS400.
Add HS400 related macros.
Remove the restriction of only using the low 6 bits of
EXT_CSD_CARD_TYPE, using all the 8 bits.
Signed-off-by: Peng Fan <peng.fan@nxp.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Jean-Jacques Hiblot <jjhiblot@ti.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Faiz Abbas <faiz_abbas@ti.com> Cc: Marek Vasut <marex@denx.de> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Eugen Hristev [Thu, 9 Aug 2018 11:12:01 +0000 (14:12 +0300)]
at91: fix devicetree warnings
This commit fixes various devicetree warnings in the at91 devicetrees
like:
arch/arm/dts/sama5d36ek_cmp.dtb: Warning (avoid_unnecessary_addr_size): /gpio_keys: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
These warnings make buildman report failed builds for most of at91 boards.
Thus, fixing it.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Patrice Chotard [Thu, 9 Aug 2018 09:57:57 +0000 (11:57 +0200)]
gpio: stm32f7: replace ODR update by BSRR write
Replace clrsetbits on ODR register (2 operations: one read + one write)
by writing on the correct bit (SET or RESET) of the BSRR register
(only 1 write operation).
Moreover this register if safe for simultaneous access by 2 master on
the bus.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Neil Armstrong [Mon, 6 Aug 2018 12:49:20 +0000 (14:49 +0200)]
clk: clk_meson: Add mux and div support for reparent and rate setting
This patch adds support for :
- Rate calculation through muxes and generic dividers
- Basic gate setting propagation
- Reparenting for muxes
- Clock rate setting through generic dividers without reparenting
Support is only added to the Composite VPU and VAPB clocks in order
to support the Video Processing Unit Power Domain clock setup.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Neil Armstrong [Mon, 6 Aug 2018 12:49:19 +0000 (14:49 +0200)]
power: domain: Add the VPU Power Domain driver
The Amlogic Meson SoCs embeds a specific Power Domain dedicated to the
Video Processing Unit.
This patch implements support for this power domain in preparation of the
future support for the Video display support in U-Boot.
This driver will depend on changes in the clock driver to handle the setup
of the VPU and VAPB clocks configured from DT using assigned-clocks entries.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Masahiro Yamada [Mon, 6 Aug 2018 11:47:39 +0000 (20:47 +0900)]
arch: types.h: factor out fixed width typedefs to int-ll64.h
All architectures have the same definition for s8/16/32/64
and u8/16/32/64.
Factor out the duplicated code into <asm-generic/int-ll64.h>.
BTW, Linux unified the kernel space definition into int-ll64.h
a few years ago as you see in Linux commit 0c79a8e29b5f
("asm/types.h: Remove include/asm-generic/int-l64.h").
projects / u-boot.git / log
