Marek Vasut [Thu, 9 Jul 2015 01:52:12 +0000 (03:52 +0200)]
arm: socfpga: reset: Repair bridge reset handling
The current bridge reset code, which de-asserted the bridge reset,
was activelly polling whether the FPGA is programmed and ready and
in case it was (!), the code called hang(). This makes no sense at
all. Repair it such that the code instead checks whether the FPGA
is programmed, but without any polling involved, and only if it is
programmed, it de-asserts the reset.
Replace all those ad-hoc reset functions, which were all copies
of the same invocation of clrbits_le32() anyway, with one single
unified function, socfpga_per_reset(), with necessary parameters.
Marek Vasut [Thu, 9 Jul 2015 00:45:15 +0000 (02:45 +0200)]
arm: socfpga: reset: Implement unified function to toggle reset
Implement function socfpga_per_reset(), which allows asserting or
de-asserting reset of each reset manager peripheral in a unified
manner. Use this function throughout reset manager.
Marek Vasut [Thu, 9 Jul 2015 00:30:35 +0000 (02:30 +0200)]
arm: socfpga: reset: Start reworking the SoCFPGA reset manager
Implement macro SOCFPGA_RESET(name), which produces an abstract
reset number. Implement macros which allow extracting the reset
offset in permodrstN register and which permodrstN register the
reset is located in from this abstract reset number. Use these
macros throughout the reset manager.
Move the structure prototype from sdram.h header file into sdram.c
source file, since it is used only there and for local purpose only.
There is no point in having it global.
While at this move, fix the data types in the structure from uintNN_t
to uNN and fix the coding style a bit.
Dinh Nguyen [Wed, 3 Jun 2015 03:52:48 +0000 (22:52 -0500)]
driver/ddr/altera: Add DDR driver for Altera's SDRAM controller
This patch enables the SDRAM controller that is used on Altera's SoCFPGA
family. This patch configures the SDRAM controller based on a configuration
file that is generated from the Quartus tool, sdram_config.h.
Marek Vasut [Sat, 25 Jul 2015 06:22:21 +0000 (08:22 +0200)]
arm: socfpga: Move generated files into qts subdir
Move all the files generated by Quartus into the qts/ subdir of the
board/altera/socfpga dir to make them explicitly separate from the
generic U-Boot code.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Marek Vasut [Tue, 21 Jul 2015 09:25:14 +0000 (11:25 +0200)]
arm: dts: socfpga: Fix SPI aliases
The SPI aliases are completely wrong. First, they point to non-existing
/spi@.* nodes instead of the correct /soc/spi@.* nodes. Second, the use
ad-hoc string instead of a handle. Furthermore, they are copied multiple
times in each board DTS.
So fix it such that we move these into socfpga.dtsi and make them use
the usual handles.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
In case the FPGA bitstream is aligned to 4 bytes, skip the
part of the assembler which handles unaligned bitstream.
Otherwise, that part will loop indefinitelly.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Stephen Warren [Wed, 5 Aug 2015 17:52:08 +0000 (11:52 -0600)]
ARM: tegra: Add p2371-0000 board
P2371-0000 is a P2581 or P2530 CPU board married to a P2595 I/O
board. The combination contains SoC, DRAM, eMMC, SD card slot,
HDMI, USB micro-B port, Ethernet via USB3, USB3 host port, SATA,
a GPIO expansion header, and an analog audio jack.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
T124/210 requires some specific configuration (VPR setup) to
be performed by the bootloader before the GPU can be used.
For this reason, the GPU node in the device tree is disabled
by default. This patch enables the node if U-boot has performed
VPR configuration.
Boards enabled by this patch are T124's Jetson TK1 and Venice2
and T210's P2571.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
ARM: tegra: move VPR configuration to a later stage
U-boot is responsible for enabling the GPU DT node after all necessary
configuration (VPR setup for T124) is performed. In order to be able to
check whether this configuration has been performed right before booting
the kernel, make it happen during board_init().
Also move VPR configuration into the more generic gpu.c file, which will
also host other GPU-related functions, and let boards specify
individually whether they need VPR setup or not.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Stephen Warren [Thu, 30 Jul 2015 20:34:09 +0000 (14:34 -0600)]
ARM: tegra: add comment re: autogeneration to pinmux headers
Add a comment block to the top of each generated Tegra pinmux header file
indicating that the file was auto-generated, should not be manually
edited, and with a pointer to the tool and command used to generate it.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
Stephen Warren [Wed, 29 Jul 2015 19:47:58 +0000 (13:47 -0600)]
ARM: tegra: restrict usable RAM size further
Additionally, ARM64 devices typically run a secure monitor in EL3 and
U-Boot in EL2, and set up some secure RAM carve-outs to contain the EL3
code and data. These carve-outs are located at the top of 32-bit address
space. Restrict U-Boot's RAM usage to well below the location of those
carve-outs. Ideally, we would the secure monitor would inform U-Boot of
exactly which RAM it could use at run-time. However, I'm not sure how to
do that at present (and even if such a mechanism does exist, it would
likely not be generic across all forms of secure monitor).
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Simon Glass [Mon, 3 Aug 2015 14:19:19 +0000 (08:19 -0600)]
exynos: dts: Correct LDO and BUCK naming
At present lower case is used for the regulator names in the device tree.
The kernel uses upper case and U-Boot will require this also since it will
move to a case-sensitive name check.
Simon Glass [Mon, 3 Aug 2015 00:07:21 +0000 (18:07 -0600)]
x86: Enable debug UART for Minnowmax
Enable the debug UART and emit a single 'a' early in the init sequence to
show that it is working.
Unfortunately the debug UART implementation needs a stack to work. I cannot
seem to remove this limitation as the absolute 'jmp %eax' instruction goes
off into the weeds.
So this means that the character output cannot be any earlier than
car_init_ret, where memory is available for a stack.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Simon Glass [Thu, 30 Jul 2015 19:40:39 +0000 (13:40 -0600)]
dm: core: Add a way to set a device name
Some devices are bound entirely by probing and do not have the benefit of
a device tree to give them a name. This is very common with PCI and USB. In
most cases this is fine, but we should add an official way to set a device
name. This should be called in the device's bind() method.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 28 Jul 2015 17:53:14 +0000 (11:53 -0600)]
sandbox: Enable devres subsystem
This should be used for sandbox. We can convert at least one driver to use
it, but in the meantime, enable the feature so that the code is
build-tested.
devres: add debug command to dump device resources
This new command can dump all device resources associated to
each device. The fields in every line shows:
- The address of the resource
- The size of the resource
- The name of the release function
- The stage in which the resource has been acquired (BIND/PROBE)
Currently, there is no driver using devres, but if such drivers are
implemented, the output of this command should look like this:
Currently, Devres requires additional 16 byte for each allocation,
which is not so insignificant in some cases.
Add CONFIG_DEVRES to make this framework optional.
If the option is disabled, devres functions fall back to
non-managed variants. For example, devres_alloc() to kzalloc(),
devm_kmalloc() to kmalloc(), etc.
Because devres_head is also surrounded by an ifdef conditional,
there is no memory overhead when CONFIG_DEVRES is disabled.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Suggested-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
devres: add devm_kmalloc() and friends (managed memory allocators)
devm_kmalloc() is identical to kmalloc() except that the memory
allocated with it is managed and will be automatically released
when the device is removed/unbound.
Likewise for the other variants.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
In U-Boot's driver model, memory is basically allocated and freed
in the core framework. So, low level drivers generally only have
to specify the size of needed memory with .priv_auto_alloc_size,
.platdata_auto_alloc_size, etc. Nevertheless, some drivers still
need to allocate/free memory on their own in case they cannot
statically know the necessary memory size. So, I believe it is
reasonable enough to port Devres into U-boot.
Devres, which originates in Linux, manages device resources for each
device and automatically releases them on driver detach. With devres,
device resources are guaranteed to be freed whether initialization
fails half-way or the device gets detached.
The basic idea is totally the same to that of Linux, but I tweaked
it a bit so that it fits in U-Boot's driver model.
In U-Boot, drivers are activated in two steps: binding and probing.
Binding puts a driver and a device together. It is just data
manipulation on the system memory, so nothing has happened on the
hardware device at this moment. When the device is really used, it
is probed. Probing initializes the real hardware device to make it
really ready for use.
So, the resources acquired during the probing process must be freed
when the device is removed. Likewise, what has been allocated in
binding should be released when the device is unbound. The struct
devres has a member "probe" to remember when the resource was
allocated.
CONFIG_DEBUG_DEVRES is also supported for easier debugging.
If enabled, debug messages are printed each time a resource is
allocated/freed.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
Simon Glass [Wed, 8 Jul 2015 02:53:44 +0000 (20:53 -0600)]
dm: Support address translation for simple-bus
The 'ranges' property can be used to specify a translation from the system
address to the bus address. Add support for this using the dev_get_addr()
function, which devices should use to find their address.
Simon Glass [Wed, 8 Jul 2015 02:53:41 +0000 (20:53 -0600)]
net: smsc95xx: Prepare for conversion to driver model
At present struct eth_device is passed around all over the place. This does
not exist with driver model. Add explicit arguments instead, so that with
driver model we can pass the correct things.
Simon Glass [Fri, 17 Jul 2015 15:22:07 +0000 (09:22 -0600)]
dm: Make regmap and syscon optional
Not all boards use garbage collection in their link step, so we should avoid
adding options that rely on this for prevention of code bloat. Add separate
Kconfig options for syscon and regmap uclasses.
York Sun [Mon, 3 Aug 2015 19:02:04 +0000 (12:02 -0700)]
lib/fdtdec: Fix fdt_addr_t and fdt_size_t typedef
fdt_addr_t is a physical address. It can be either 64-bit or 32-bit,
depending on the architecture. It should be phys_addr_t instead of
u64 or u32. Similarly, fdt_size_t is changed to phys_size_t.
Signed-off-by: York Sun <yorksun@freescale.com> CC: Simon Glass <sjg@chromium.org>
Simon Glass [Mon, 3 Aug 2015 14:19:37 +0000 (08:19 -0600)]
exynos: Add support for spring
Spring is the first ARM-based HP Chromebook 11. It is similar to snow
and it uses the same Samsung Exynos5250 chip. But has some unusual
features. Mainline support for it has lagged snow (both in kernel and
U-Boot). Now that the exynos5 code is common we can support spring just
by adding a device tree and a few lines of configuration.
Simon Glass [Mon, 3 Aug 2015 14:19:27 +0000 (08:19 -0600)]
exynos: Add common board code for exynos5 boards that use device tree
Some boards use device tree for almost all board-specific configuration.
They therefore do not need their own separate board code, but can all use
the same version. Add a common version of the board code. It uses the
PMIC, regulator and video bridge uclasses. This will support smdk5250,
smdk5420, snow, spring, pit and pi.
Simon Glass [Mon, 3 Aug 2015 14:19:26 +0000 (08:19 -0600)]
exynos: dts: Drop the old TPS65090 I2C node
While the AP can access the main PMIC on snow, it must coordinate with the
EC which also wants access. Drop the old definition, which can in principle
generate collision errors. We will use the new arbitration driver instead.
Simon Glass [Fri, 3 Jul 2015 00:16:16 +0000 (18:16 -0600)]
dm: gpio: Check a GPIO is valid before using it
Since a gpio_desc is allowed to be invalid we should return an error
indicating that the operation cannot be completed. This can happen if the
GPIO is optional - e.g. some devices may have a reset line and some may
not.
Simon Glass [Fri, 3 Jul 2015 00:16:11 +0000 (18:16 -0600)]
exynos: spi: Convert the timeout to debug()
Since the timeout is reported through normal channels, and is sometimes
expected (e.g. if the bus is being probed for a non-existent device),
don't display the message in the driver.
In general, drivers should not write to the console as this limits their
usefulness in error conditions.
Simon Glass [Fri, 3 Jul 2015 00:16:10 +0000 (18:16 -0600)]
dm: video: Add support for the NXP PTN3460 bridge
This chip provides an eDP to LVDS bridge which is useful for SoCs that don't
support LVDS displays (or it would waste scarce pins). There is no setup
required by this chip, other than to adjust power-down and reset pins, and
those are managed by the uclass.
Simon Glass [Fri, 3 Jul 2015 00:16:09 +0000 (18:16 -0600)]
dm: video: Add support for the Parade PS8622/625 bridge
This chip provides an eDP to LVDS bridge which is useful for SoCs that don't
support LVDS displays (or it would waste scarce pins). The setup is included
in the device tree.
Simon Glass [Mon, 3 Aug 2015 14:19:20 +0000 (08:19 -0600)]
video: Work around lack of pinctrl
We haven't quite got pinctrl ready to apply to mainline. We don't want to
GPIO pull-up/down support to the driver model GPIO layer either. So work
around this for now.
Simon Glass [Fri, 3 Jul 2015 00:16:08 +0000 (18:16 -0600)]
dm: video: Add support for video bridges
A video bridge typically converts video from one format to another, e.g.
DisplayPort to LVDS. Add driver model support for these with a simple
interface to control activation and backlight. The uclass supports GPIO
control of power and reset lines.
Simon Glass [Fri, 3 Jul 2015 00:16:06 +0000 (18:16 -0600)]
dm: power: Don't return an error when regulators are not autoset
Not all regulators can be set up automatically. Adjust the code so that
regulators_enable_boot_on() will return success when some are skipped.
Only genuine errors are reported.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
Simon Glass [Fri, 3 Jul 2015 00:16:01 +0000 (18:16 -0600)]
dm: power: Add support for S5M8767 regulators
This PMIC is used with SoCs which need a combination of BUCKs and LDOs. The
driver supports changing voltage and enabling/disabling each regulator. It
supports the standard device tree binding and supports driver model.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
Simon Glass [Fri, 3 Jul 2015 00:16:00 +0000 (18:16 -0600)]
dm: power: Add support for the S5M8767 PMIC
This PMIC is used with SoCs which need a combination of BUCKs and LDOs. The
driver supports probing and basic register access. It supports the standard
device tree binding and supports driver model. A regulator driver can be
provided also.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
Simon Glass [Fri, 3 Jul 2015 00:15:59 +0000 (18:15 -0600)]
dm: power: Add support for TPS65090 FETs
The TPS65090 has 7 FETs which are modelled as regulators. This allows them
to be controlled by drivers easier, accessed through the 'regulator' command
and used by other drivers.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
Simon Glass [Fri, 3 Jul 2015 00:15:58 +0000 (18:15 -0600)]
dm: power: Add a new driver for the TPS65090 PMIC
The existing TPS65090 driver does not support driver model. Add a new one
that does. This can be used as a base for a regulator driver also. It uses
the standard device tree binding.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
Simon Glass [Fri, 3 Jul 2015 00:15:53 +0000 (18:15 -0600)]
exynos: serial: Refactor init code for debug UART
The debug UART code needs to perform the same init as the normal UART
driver. In preparation for this, move the init code into two functions, one
for the basic init and one for setting the baud rate. This will make adding
debug UART support easier.
Simon Glass [Mon, 3 Aug 2015 14:19:24 +0000 (08:19 -0600)]
cros_ec: Support the LDO access method used by spring
Add a driver to support the special LDO access used by spring. This is a
custom method in the cros_ec protocol - it does not use an I2C
pass-through.
There are two implementation choices:
1. Write a special LDO driver which can talk across the EC. Duplicate all
the logic from TPS65090 for retrying when the LDO fails to come up.
2. Write a special I2C bus driver which pretends to be a TPS65090 and
transfers reads and writes using the LDO message.
Either is distasteful. The latter method is chosen since it results in less
code duplication and a fairly simple (30-line) implementation of the core
logic.
The crosec 'ldo' subcommand could be removed (since i2c md/mw will work
instead) but is retained as a convenience.
Simon Glass [Mon, 3 Aug 2015 14:19:23 +0000 (08:19 -0600)]
dm: cros_ec: Convert the I2C tunnel code to use driver model
The Chrome OS EC supports tunnelling through to an I2C bus on the EC. This
currently uses a copy of the I2C command code and a special 'crosec'
sub-command.
With driver model we can define an I2C bus which tunnels through to the EC,
and use the normal 'i2c' command to access it. This simplifies the code and
removes some duplication.
Add an I2C driver which tunnels through to the EC. Adjust the EC code to
support binding child devices so that it can be set up. Adjust the existing
I2C xfer function to fit driver model better.
For now the old code remains to allow things to still work. It will be
removed in a later patch once the new flow is fully enabled.
Simon Glass [Fri, 3 Jul 2015 00:15:50 +0000 (18:15 -0600)]
exynos: dts: Support EC tunnel and main TPS65090 regulator
On pit and pi the TPS65090 regulator is connected only to the EC and we
must use a tunnel to get to it. The existing U-Boot support relies on a
special driver. Add a tunnel definition so that the new device-model
TPS65090 driver can be used unmodified.
Simon Glass [Fri, 3 Jul 2015 00:15:47 +0000 (18:15 -0600)]
exynos: i2c: Tidy up the driver model code
The existing driver model implementation uses the old non-driver-model code
to operate, but has become impossibly tangled as a result. The actual
algorithm is quite simple.
Also the normal-speed and high-speed buses are quite different and it
doesn't seem that useful to put them in the same driver.
Finally, there is a bug which breaks communication with the Maxim sound
codec and may cause problems with other device.
Rewrite the driver model code for normal-speed operation so that it is
easier to understand, and fix the bug. Add a TODO to split the drivers.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
Simon Glass [Mon, 3 Aug 2015 14:19:22 +0000 (08:19 -0600)]
i2c: Add a mux for GPIO-based I2C bus arbitration
While I2C supports multi-master buses this is difficult to get right.
The implementation on the master side in software is quite complex.
Clock-stretching and the arbitrary time that an I2C transaction can take
make it difficult to share the bus fairly in the face of high traffic.
When one or more masters can be reset independently part-way through a
transaction it is hard to know the state of the bus.
This driver provides a scheme based on two 'claim' GPIOs, one driven by the
AP (Application Processor, meaning the main CPU) and one driven by the EC
(Embedded Controller, a small CPU aimed at handling system tasks). With
these they can communicate and reliably share the bus. This scheme has
minimal overhead and involves very little code. It is used on snow to
permit the EC and the AP to share access to the main system PMIC and
battery. The scheme can survive reboots by either side without difficulty.
This scheme has been tested in the field with millions of devices.
Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO,
meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology
is used by the device tree bindings in Linux also.
Simon Glass [Mon, 3 Aug 2015 14:19:21 +0000 (08:19 -0600)]
dm: i2c: Add support for multiplexed I2C buses
Add a new I2C_MUX uclass. Devices in this class can multiplex between
several I2C buses, selecting them one at a time for use by the system.
The multiplexing mechanism is left to the driver to decide - it may be
controlled by GPIOs, for example.
The uclass supports only two methods: select() and deselect().
The current mux state is expected to be stored in the mux itself since
it is the only thing that knows how to make things work. The mux can
record the current state and then avoid switching unless it is necessary.
So select() can be skipped if the mux is already in the correct state.
Also deselect() can be made a nop if required.
Simon Glass [Fri, 3 Jul 2015 00:15:42 +0000 (18:15 -0600)]
dm: i2c: Add a function to transfer messages
Sometimes it is useful to be able to transfer a raw I2C message. This
happens when the chip address needs to be set manually, or when the data to
be sent/received is in another buffer.
Add a function to provide access to this.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
projects / u-boot / log