This command is based on driver model regulator's API.
The user interface provides:
- list UCLASS regulator devices
- show or [set] operating regulator device
- print constraints info
- print operating status
- print/[set] voltage value [uV] (force)
- print/[set] current value [uA]
- print/[set] operating mode id
- enable the regulator output
- disable the regulator output
The 'force' option can be used for setting the value which exceeds
the constraints min/max limits.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org>
This is new command for the PMIC devices based on driver model PMIC API.
Command features are unchanged:
- list UCLASS pmic devices
- show or [set] operating pmic device (NEW)
- dump registers
- read byte of register at address
- write byte to register at address
The only one change for this command is 'dev' subcommand.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org>
dm: regulator: add implementation of driver model regulator uclass
This commit introduces the implementation of dm regulator API.
Device tree support allows for auto binding. And by the basic
uclass operations, it allows to driving the devices in a common
way. For detailed informations, please look into the header file.
Core files:
- drivers/power/regulator-uclass.c - provides regulator common functions api
- include/power/regulator.h - define all structures required by the regulator
Changes:
- new uclass-id: UCLASS_REGULATOR
- new config: CONFIG_DM_REGULATOR
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org>
dm: pmic: add implementation of driver model pmic uclass
This commit introduces the PMIC uclass implementation.
It allows providing the basic I/O interface for PMIC devices.
For the multi-function PMIC devices, this can be used as I/O
parent device, for each IC's interface. Then, each PMIC particular
function can be provided by the child device's operations, and the
child devices will use its parent for read/write by the common API.
Move the configs listed below from exynos5-dt-common.h to exynos5-common.h:
- CONFIG_POWER
- CONFIG_POWER_I2C
fixes build break for Arndale and Smdk5250 boards.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org>
Peng Fan [Thu, 14 May 2015 23:29:12 +0000 (07:29 +0800)]
i2c: mxc: refactor i2c driver and support dm
1. Introduce a new structure `struct mxc_i2c_bus`, this structure will
used for non-DM and DM.
2. Remove `struct mxc_i2c_regs` structure, but use register offset to access
registers based on `base` entry of `struct mxc_i2c_bus`.
3. Remove most `#ifdef I2C_QUIRK_REG`. Using driver_data to contain platform
flags. A new flag is introduced, I2C_QUIRK_FLAG.
4. Most functions use `struct mxc_i2c_bus` as one of the parameters.
Make most functions common to DM and non-DM, try to avoid duplicated code.
5. Support DM, but pinctrl is not included. Pinmux setting is still set
by setup_i2c, but we do not need bus_i2c_init for DM.
6. struct i2c_parms and struct sram_data are removed.
7. Remove bus_i2c_read bus_i2c_write prototype in header file. The frist
paramter of bus_i2c_init is modified to i2c index. Add new prototype
i2c_idle_bus and force_bus_idle. Since bus_i2c_init is not good for
DM I2C and pinctrl is missed, we use a weak function for i2c_idle_bus.
Board file take the responsibility to implement this function, like this:
"
int i2c_idle_bus(struct mxc_i2c_bus *i2c_bus)
{
if (i2c_bus->index == 0)
force_bus_idle(i2c_pads_info0);
else if (i2c_bus->index == 1)
force_bus_idle(i2c_pads_info1);
else
xxxxxx
}
"
8. Introduce a weak function, enable_i2c_clk
9. Tested on an i.MX7 platform. Log info:
=> dm tree
Class Probed Name
----------------------------------------
root [ + ] root_driver
simple_bus [ ] |-- soc
simple_bus [ ] | |-- aips-bus@30000000
simple_bus [ ] | | |-- anatop@30360000
simple_bus [ ] | | `-- snvs@30370000
simple_bus [ ] | |-- aips-bus@30400000
simple_bus [ ] | `-- aips-bus@30800000
i2c [ ] | |-- i2c@30a20000
i2c [ ] | `-- i2c@30a40000
simple_bus [ ] `-- regulators
=> i2c dev 0
Setting bus to 0
=> i2c probe
Valid chip addresses: 08 50
=> i2c md 8 31
0031: 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08
Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Acked-by: Simon Glass <sjg@chromium.org>
Peng Fan [Thu, 14 May 2015 23:29:13 +0000 (07:29 +0800)]
imx: mx27 move GPIO_PORTx to gpio.h
These GPIO_PORTx macros should be in gpio.h, but not in imx-regs.h.
Also, imx-regs.h and iomux-v3.h has same macro defintion for
GPIO_PORTx, and both of them are included in mxc_i2c.c(include
mxc_i2c.h). This will incur build warnings with macro redefinition.
Since iomux-v3.h is not compatible with mx27, we can not simply
include iomux-v3.h for mx27, so move the GPIO_PORTx to gpio.h to
fix the build warning.
Hans de Goede [Wed, 13 May 2015 12:42:18 +0000 (14:42 +0200)]
sunxi: Change usb-kbd interrupt polling to use an usb interrupt queue
Now that the ohci code supports usb interrupt queues we can switch (back)
to using an usb interrupt queue for usb-kbd interrupt polling. This
greatly reduces u-boot's latency when dealing with usb keyboards.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ian Campbell <ijc@hellion.org.uk> Reviewed-by: Marek Vasut <marex@denx.de>
Hans de Goede [Wed, 13 May 2015 12:42:15 +0000 (14:42 +0200)]
usb: ohci: Do not reuse ed for interrupt endpoints of different devices
When submitting interrupt packets to an endpoint we only link in the ed
once to avoid some races surrounding unlinking of periodic endpoints,
but we share one ohci_device struct / one set of ed-s for all devices,
which means that if we have an interrupt endpoint at endpoint 1 with one
device, and a non interrupt endpoint 1 with another device we end up
with the same ed linked into both the periodic and async lists, which is
not good (tm).
This commit switches over to using separate ohci_device structs, and thus
separate ed-s for devices with interrupt endpoints, fixing this.
This fixes e.g. matching a usb storage device and keyboard on the same
usb-1 hub not working.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Mon, 4 May 2015 17:30:56 +0000 (11:30 -0600)]
bootstage: Add IDs for SPI flash reading and decompression
We maintain an accumulator for time spent reading from SPI flash, since
this can be significant on some platforms. Also add one for decompression
time.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com> Reviewed-by: Jagan Teki <jteki@openedev.com>
Provide a function to detect USB device insertion/removal in order to
avoid having to do USB enumeration in a tight loop when trying to detect
peripheral hotplugging.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
Hans de Goede [Sun, 10 May 2015 12:10:27 +0000 (14:10 +0200)]
sunxi: ohci: Add ohci usb host controller support
This commit adds support for the OHCI companion controller, which makes
usb-1 devices directly plugged into to usb root port work.
Note for now this switches usb-keyboard support for sunxi back from int-queue
support to the old interrupt polling method. Adding int-queue support to the
ohci code and switching back to int-queue support is in the works.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Ian Campbell <ijc@hellion.org.uk>
AFAICT there is no reason for the mdelay(1) calls. This commit disables them
when building the ohci code for new driver-model using boards. It leaves
the mdelay(1) calls in place when building for older boards, so as to avoid
causing any regressions there.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sun, 10 May 2015 12:10:23 +0000 (14:10 +0200)]
usb: ohci: Remove unnecessary delays from hc_start and power power-on paths
The usb spec says that we must wait a minimum amount of time after port
power on (exact time is in the hub descriptor), this is something which
we must not only do for root ports but also for external hub ports, which
is why the common usb_hub code already waits a full second after powering
up ports. Having a separate wait for just the root hub in the ohci-hcd
code only leads to doing the waiting twice for the root ports, so drop the
wait from the ohci-hcd code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sun, 10 May 2015 12:10:21 +0000 (14:10 +0200)]
dm: usb: Do not scan companion buses if no devices where handed over
USB scanning is slow, and there is no need to scan the companion buses
if no usb devices where handed over to the companinon controllers by any
of the main controllers.
This saves e.g. 2 seconds when booting a A10 OLinuxIno Lime with no USB-1
devices plugged into the root usb ports.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Glass <sjg@chromium.org>
Hans de Goede [Sun, 10 May 2015 12:10:20 +0000 (14:10 +0200)]
dm: usb: Add support for companion controllers
USB companion controllers must be scanned after the main controller has
been scanned, so that any devices which the main controller which to hand
over to the companion have actually been handed over before we scan the
companion.
As there are no guarantees that this will magically happen in the right
order, split the scanning of the buses in 2 phases, first main controllers,
and then companion controllers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Glass <sjg@chromium.org>
Hans de Goede [Sun, 10 May 2015 12:10:18 +0000 (14:10 +0200)]
dm: usb: Add support for interrupt queues to the dm usb code
Interrupt endpoints typically are polled for a long time by the usb
controller before they return anything, so calls to submit_int_msg() can
take a long time to complete this.
To avoid this the u-boot code has the an interrupt queue mechanism / API,
add support for this to the driver-model usb code and implement it for the
dm ehci code.
See the added doc comments for more details.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Glass <sjg@chromium.org>
Hans de Goede [Sun, 10 May 2015 12:10:16 +0000 (14:10 +0200)]
usb: Stop reset procedure when a dev is handed over to a companion hcd
Short circuit the retry loop in legacy_hub_port_reset() by returning an
error from usb_control_msg() when a device was handed over to a companion
by the ehci code. This avoids trying to reset low / fullspeed devices 5
times needlessly. Also do not print an error when a device has been handed
over.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Sun, 10 May 2015 12:10:13 +0000 (14:10 +0200)]
usb: Fix handover of full-speed devices from ehci to companion
When after a reset the port status connection bit is still set and the enable
bit is not then we're dealing with a full-speed device and should hand it over
to the companion controller.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tom Rini [Thu, 14 May 2015 15:07:03 +0000 (11:07 -0400)]
arch/arm/lib/bootm-fdt.c: Guard the include of <asm/armv7.h>
With d6b72da0 we started including this file unconditionally. This
isn't allowed in a file that we also use on armv8. This will get
cleaned up a bit better once we really start using these same features
(and have similar fdt updates needed) on armv8.
ARM: tegra: move NVIDIA common files to arch/arm/mach-tegra
All the Tegra boards borrow the files from board/nvidia/common/
directory, i.e., board/nvidia/common/* are not vendor-common files,
but SoC-common files.
Move NVIDIA common files to arch/arm/mach-tegra/ to clean up
Makefiles.
As arch/arm/mach-tegra/board.c already exists, this commit renames
board/nvidia/common/board.c to arch/arm/mach-tegra/board2.c,
expecting they will be consolidated as a second step.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
Ian Campbell [Tue, 21 Apr 2015 05:18:40 +0000 (07:18 +0200)]
jetson-tk1: Add PSCI configuration options and reserve secure code
The secure world code is relocated to the MB just below the top of 4G, we
reserve it in the FDT (by setting CONFIG_ARMV7_SECURE_RESERVE_SIZE) but it is
not protected in h/w.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Tested-by: Ian Campbell <ijc@hellion.org.uk> Signed-off-by: Tom Warren <twarren@nvidia.com>
Jan Kiszka [Tue, 21 Apr 2015 05:18:39 +0000 (07:18 +0200)]
tegra: Boot in non-secure mode by default
Upstream Linux is broken with default configs when PSCI, thus non-secure
mode is enabled. So the user should explicitly enable this mode, e.g.
when she disabled CONFIG_CPU_IDLE in Linux (in which case it's safe to
use). We can revert this workaround once Linux got fixed.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Make sure to enable the SMMU when booting the kernel in non-secure mode.
This is necessary because some of the SMMU registers are restricted to
TrustZone-secured requestors, hence the kernel wouldn't be able to turn
the SMMU on. At the same time, enable translation for all memory clients
for the same reasons. The kernel will still be able to control SMMU IOVA
translation using the per-SWGROUP enable bits.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Ian Campbell [Tue, 21 Apr 2015 05:18:36 +0000 (07:18 +0200)]
tegra124: Reserve secure RAM using MC_SECURITY_CFG{0, 1}_0
These registers can be used to prevent non-secure world from accessing a
megabyte aligned region of RAM, use them to protect the u-boot secure monitor
code.
At first I tried to do this from s_init(), however this inexplicably causes
u-boot's networking (e.g. DHCP) to fail, while networking under Linux was fine.
So instead I have added a new weak arch function protect_secure_section()
called from relocate_secure_section() and reserved the region there. This is
better overall since it defers the reservation until after the sec vs. non-sec
decision (which can be influenced by an envvar) has been made when booting the
os.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
[Jan: tiny style adjustment] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Tested-by: Ian Campbell <ijc@hellion.org.uk> Signed-off-by: Tom Warren <twarren@nvidia.com>
Jan Kiszka [Tue, 21 Apr 2015 05:18:35 +0000 (07:18 +0200)]
tegra124: Add PSCI support for Tegra124
This is based on Thierry Reding's work and uses Ian Campell's
preparatory patches. It comes with full support for CPU_ON/OFF PSCI
services. The algorithm used in this version for turning CPUs on and
off was proposed by Peter De Schrijver and Thierry Reding in
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/210881. It
consists of first enabling CPU1..3 via the PMC, just to powergate them
again with the help of the Flow Controller. Once the Flow Controller is
in place, we can leave the PMC alone while processing CPU_ON and CPU_OFF
PSCI requests.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Jan Kiszka [Tue, 21 Apr 2015 05:18:32 +0000 (07:18 +0200)]
virt-dt: Allow reservation of secure region when in a RAM carveout
In this case the secure code lives in RAM, and hence the memory node in
the device tree needs to be adjusted. This avoids that the OS will map
and possibly access the reservation.
Add support for setting CONFIG_ARMV7_SECURE_RESERVE_SIZE to carve out
such a region. We only support cutting off memory from the beginning or
the end of a RAM bank as we do not want to increase their number (which
would happen if punching a hole) for simplicity reasons
This will be used in a subsequent patch for Jetson-TK1.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Jan Kiszka [Tue, 21 Apr 2015 05:18:30 +0000 (07:18 +0200)]
ARM: Put target PC for PSCI CPU_ON on per-CPU stack
Use a per-CPU variable for saving the target PC during CPU_ON
operations. This allows us to run this service independently on targets
that have more than 2 cores and also core-local power control.
CC: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Tested-by: Ian Campbell <ijc@hellion.org.uk> Signed-off-by: Tom Warren <twarren@nvidia.com>
Jan Kiszka [Tue, 21 Apr 2015 05:18:27 +0000 (07:18 +0200)]
ARM: Factor out reusable psci_cpu_off_common
Move parts of sunxi's psci_cpu_off into psci_cpu_off_common, namely
cache disabling and flushing, clrex and the disabling of SMP for the
dying CPU. These steps are apparently generic for ARMv7 and will be
reused for Tegra124 support.
As the way of disabled SMP is not architectural, though commonly done
via ACLTR, the related function can be overloaded.
CC: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Tested-by: Ian Campbell <ijc@hellion.org.uk> Signed-off-by: Tom Warren <twarren@nvidia.com>
Jan Kiszka [Tue, 21 Apr 2015 05:18:26 +0000 (07:18 +0200)]
ARM: Factor out common psci_get_cpu_id
Will be required for obtaining the ID of the current CPU in shared PSCI
functions. The default implementation requires a dense ID space and only
supports a single cluster. Therefore, the functions can be overloaded in
cases where these assumptions do not hold.
CC: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Tested-by: Ian Campbell <ijc@hellion.org.uk> Acked-by: Ian Campbell <ijc@hellion.org.uk> Signed-off-by: Tom Warren <twarren@nvidia.com>
Jan Kiszka [Tue, 21 Apr 2015 05:18:24 +0000 (07:18 +0200)]
ARM: Clean up CONFIG_ARMV7_NONSEC/VIRT/PSCI conditions
CONFIG_ARMV7_VIRT depends on CONFIG_ARMV7_NONSEC, thus doesn't need to
be taken into account additionally. CONFIG_ARMV7_PSCI is only set on
boards that support CONFIG_ARMV7_NONSEC, and it only works on those.
CC: Tang Yuantian <Yuantian.Tang@freescale.com> CC: York Sun <yorksun@freescale.com> CC: Steve Rae <srae@broadcom.com> CC: Andre Przywara <andre.przywara@linaro.org> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Tested-by: Alison Wang <alison.wang@freescale.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Stephen Warren [Tue, 14 Apr 2015 14:41:14 +0000 (08:41 -0600)]
ARM: tegra: enable STDIO deregistration
At the very least when USB keyboard support is enabled, we need to enable
CONFIG_SYS_STDIO_DEREGISTER, so the "usb reset" is able to re-scan USB
ports and find new devices. Enable it everywhere per request from Simon
Glass.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
As best I can tell, CONFIG_SYS_LOAD_ADDR and CONFIG_LOADADDR/$loadaddr
serve essentially the same purpose. Roughly, if a command takes a load
address, then CONFIG_SYS_LOAD_ADDR or $loadaddr (or both) are the default
if the command-line does not specify the address. Different U-Boot
commands are inconsistent re: which of the two default values they use.
As such, set the two to the same value, and move the logic that does this
into tegra-common-post.h so it's not duplicated. A number of other non-
Tegra boards do this too.
The values chosen for these macros are no longer consistent with anything
in MEM_LAYOUT_ENV_SETTINGS. Regain consistency by setting $kernel_addr_r
to CONFIG_LOADADDR. Older scripts tend to use $loadaddr for the default
kernel load address, whereas newer scripts and features tend to use
$kernel_addr_r, along with other variables for other purposes such as
DTBs and initrds. Hence, it's logical they should share the same value.
I had originally thought to make the $kernel_addr_r and CONFIG_LOADADDR
have different values. This would guarantee no interference if a script
used the two variables for different purposes. However, that scenario is
unlikely given the semantic meaning associated with the two variables.
The lowest available value is 0x90200000; see comments for
MEM_LAYOUT_ENV_SETTINGS in tegra30-common-post.h for details. However,
that value would be problematic for a script that loaded a raw zImage to
$loadaddr, since it's more than 128MB beyond the start of SDRAM, which
would interfere with the kernel's CONFIG_AUTO_ZRELADDR. So, let's not do
that.
The only potential fallout I could foresee from this patch is if someone
has a script that loads the kernel to $loadaddr, but some other file
(DTB, initrd) to a hard-coded address that the new value of $loadaddr
interferes with. This seems unlikely. A user should not do that; they
should either hard-code all load addresses, or use U-Boot-supplied
variables for all load addresses. Equally, any fallout due to this change
is trivial to fix; simply modify the load addresses in that script.
Cc: Paul Walmsley <pwalmsley@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Paul Walmsley <pwalmsley@nvidia.com> Reviewed-by: Simon Glass Signed-off-by: Tom Warren <twarren@nvidia.com>
Simon Glass [Wed, 15 Apr 2015 03:03:41 +0000 (21:03 -0600)]
tegra: video: Add Embedded DisplayPort driver
This interface is used on laptop devices based on Tegra. Add a driver which
provides access to the eDP interface. The driver uses the display port
uclass.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
Simon Glass [Wed, 15 Apr 2015 03:03:33 +0000 (21:03 -0600)]
tegra: clock: Split the clock source code into a separate function
Create a function which sets the source clock for a peripheral, given
the number of mux bits to adjust. This can then be used more generally.
For now, don't export it.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
Simon Glass [Wed, 15 Apr 2015 03:03:32 +0000 (21:03 -0600)]
tegra: clock: Add checking for invalid clock IDs
The get_pll() function can do the wrong thing if passed values that are
out of range. Add checks for this and add a function which can return
a 'simple' PLL. This can be defined by SoCs with their own clocks.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
Simon Glass [Wed, 15 Apr 2015 03:03:20 +0000 (21:03 -0600)]
dm: gpio: Add error handling and a function to claim vector GPIOs
gpio_get_values_as_int() should return an error if something goes wrong.
Also provide gpio_claim_vector(), a function to request the GPIOs and set
them to input mode. Otherwise callers have to do this themselves.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
Alexey Brodkin [Wed, 13 May 2015 10:48:07 +0000 (13:48 +0300)]
arc: remove dummy target
TARGET_DUMMY was introduced to resolve the same problem as commit
"arch: Make board selection choices optional"
http://git.denx.de/?p=u-boot.git;a=commit;h=a26cd04920dc069fd6e91abb785426cf6c29f45f
Latter implementation is much cleaner and appropriate.
And anyways TARGET_DUMMY is no longer required.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Masahiro Yamada [Wed, 13 May 2015 09:49:31 +0000 (18:49 +0900)]
arc: use more universal prefix for default CROSS_COMPILE
As doc/README.ARC says, pre-build ARC toolchains are available at
the Synopsys GitHub page.
The bin files are prefixed with arc(eb)-buildroot-linux- for earlier
releases, but with arc(eb)-snps-linux- for the latest releases.
The symbolic links prefixed with arc(eb)-linux- are also available
for all the release, so those prefixes can be used as the default
CROSS_COMPILE regardless of the toolchains version/variants.
Joe Hershberger [Tue, 12 May 2015 19:46:24 +0000 (14:46 -0500)]
Clean all defconfigs with savedefconfig
In order to reduce merge conflicts and to maintain the simplest possible
defconfig files, we should be using the savedefconfig feature of Kconfig
every time a new feature is added. This keeps the defconfig settings to
a minimum (only those things not default) and keeps them in the same
order as the Kconfig options.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Cc: Tom Rini <trini@konsulko.com>
projects / u-boot.git / log