- Jul 21, 2015
-
-
Simon Glass authored
Clocks are an important feature of platforms and have become increasing complex with time. Most modern SoCs have multiple PLLs and dozens of clock dividers which distribute clocks to on-chip peripherals. Some SoC implementations have a clock API which is private to that SoC family, e.g. Tegra and Exynos. This is useful but it would be better to have a common API that can be understood and used throughout U-Boot. Add a simple clock API as a starting point. It supports querying and setting the rate of a clock. Each clock is a device. To reduce memory and processing overhead the concept of peripheral clocks is provided. These do not need to be explicit devices - it is possible to write a driver that can adjust the I2C clock (for example) without an explicit I2C clock device. This can dramatically reduce the number of devices (and associated overhead) in a complex SoC. Clocks are referenced by a number, and it is expected that SoCs will define that numbering themselves via an enum. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Since we want clk_ops to be used in U-Boot as a whole, rename the Zynq version until it can be converted to driver model. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
It is common for system reset to be available at multiple levels in modern hardware. For example, an SoC may provide a reset option, and a board may provide its own reset for reasons of security or thoroughness. It is useful to be able to model this hardware without hard-coding the behaviour in the SoC or board. Also there is a distinction sometimes between resetting just the CPU (leaving GPIO state alone) and resetting all the PMICs, just cutting power. To achieve this, add a simple system reset uclass. It allows multiple devices to provide reset functionality and provides a way to walk through them, requesting a particular reset type until is it provided. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Some functions called by mkimage would like to know the output file size. Initially this is the same as the input file size, but it may be affected by adding headers, etc. Add this information to the image parameters. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Joe Hershberger <joe.hershberger@ni.com>
-
Simon Glass authored
As a debug option, add positive confirmation that SPL has completed execution. This can help with diagnosing the location of unexpected hangs. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add an spl_init() function that does basic init such that board_init_f() can use simple malloc(), device tree and driver model. Each one is set up only if enabled for SPL. Note: We really should refactor SPL such that there is a single board_init_f() and rename the existing weak board_init_f() functions provided by boards, calling them from the single board_init_f(). Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
It can be quite confusing with a new platform to figure out why the device tree cannot be located. Add some debug information for this case. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Split out the code in fdtdec which finds a number at the end of a string. It can be useful in other situations. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add an implementation of RC4. This will be used by Rockchip booting but may be useful in other situations. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Since Rockchip requires 32-bit serial access, add this to the driver. Refactor a little to make this easier. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Several functions in this file should be marked as static. Update them. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add support for a driver which sets up DRAM and can return information about the amount of RAM available. This is a first step towards moving RAM init to driver model. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This bloats the code size quite a bit and is less useful in SPL where there is no command line. Avoid including this code in SPL. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This functionality may be useful for setting up regulators early during boot. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
It is a common requirement to update some PMIC registers. Provide some simple convenience functions to do this. Signed-off-by:
Simon Glass <sjg@chromium.org> Tested-by:
Przemyslaw Marczak <p.marczak@samsung.com> Acked-by:
Przemyslaw Marczak <p.marczak@samsung.com>
-
Simon Glass authored
To reduce unnecessary code size in an uncommon code path, use debug() where possible(). The driver returns an error which indicates failure. Signed-off-by:
Simon Glass <sjg@chromium.org> Tested-by:
Przemyslaw Marczak <p.marczak@samsung.com> Acked-by:
Przemyslaw Marczak <p.marczak@samsung.com>
-
Simon Glass authored
The device tree provides information about which regulators should be on at boot, or always on. Use this to set them up automatically. Signed-off-by:
Simon Glass <sjg@chromium.org> Tested-by:
Przemyslaw Marczak <p.marczak@samsung.com> Acked-by:
Przemyslaw Marczak <p.marczak@samsung.com>
-
Simon Glass authored
The regulator_autoset() function mixes printf() output and PMIC adjustment code. It provides a boolean to control the output. It is better to avoid missing logic and output, and this permits a smaller SPL code size. So split the output into a separate function. Also rename the function to have a by_name() suffix, since we would like to be able to pass a device when we know it, and thus avoid the name search. Signed-off-by:
Simon Glass <sjg@chromium.org> Tested-by:
Przemyslaw Marczak <p.marczak@samsung.com> Acked-by:
Przemyslaw Marczak <p.marczak@samsung.com>
-
Simon Glass authored
Decide when the regulator is set up whether we want to auto-set the voltage or current. This avoids the complex logic spilling into the processing code. Signed-off-by:
Simon Glass <sjg@chromium.org> Tested-by:
Przemyslaw Marczak <p.marczak@samsung.com> Acked-by:
Przemyslaw Marczak <p.marczak@samsung.com>
-
Simon Glass authored
This is not user input (i.e. from the command line). It should be possible to get the case correct and avoid the case-insensitive match. This will help avoid sloppy device tree setups. Signed-off-by:
Simon Glass <sjg@chromium.org> Tested-by:
Przemyslaw Marczak <p.marczak@samsung.com> Acked-by:
Przemyslaw Marczak <p.marczak@samsung.com>
-
Simon Glass authored
It took a little while to figure this out, so this patch adds documentation to help the next person who needs to do this. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Enable MMC using driver model in SPL for consistency with U-Boot proper. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Allow read errors to be diagnosed more easily. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add basic support for MMC, providing a uclass which can set up an MMC device. This allows MMC drivers to move to using driver model. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add a few messages to indicate progress and failure. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add a simple driver which allows use of LEDs attached to GPIOs. The linux device tree binding is used. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add a simple uclass for LEDs, so that these can be controlled by the device tree and activated when needed. LEDs are referred to by their label. This implementation requires a driver for each type of LED (e.g GPIO, I2C). Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Many SoCs have a number of system controllers which are dealt with as a group by a single driver. It is a pain to have to add lots of compatible strings and/or separate drivers for each. Instead we can identify the controllers by a number and request the address of the one we want. Add a simple implementation of this which can be used by SoC driver code. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add a simple implementaton of register maps, supporting only direct I/O for now. This can be enhanced later to support buses which have registers, such as I2C, SPI and PCI. It allows drivers which can operate with multiple buses to avoid dealing with the particulars of register access on that bus. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This function can be used for testing to manually request a GPIO for use, without resorting to the legacy GPIO API. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Provide a driver-model function to look up a GPIO name. Make the standard function use it. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Now that we support driver model in SPL, allow GPIO drivers to be used there also. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This parameter is named 'seq' but should be named 'of_offset'. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
In some rare cases it is useful to be able to locate a device given a device tree node offset. An example is when you have an alias that points to a node and you want to find the associated device. The device may be SPI, MMC or something else, but you don't need to know the uclass to find it. Add a function to do a global search for a device, given its device tree offset. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
To avoid bloating SPL code, use debug() where possible in the driver model core code. The error code is already returned, and can be investigated as needed. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
In SPL it is sometimes useful to be able to obtain a dump of the current driver model state. Since commands are not available, provide a way to directly call the functions to output this information. Adjust the existing commands to use these functions. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
At present printf() skips output if it can see there is no console. This is really just an optimisation, and is not necessary. Also it is currently incorrect in some cases. Rather than update the logic, just remove it so that we don't need to keep it in sync. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
When there is no console ready, allow the debug UART to be used for output. This makes debugging of early code considerably easier. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This does not actually help any current arch. For x86 it makes it harder to call (requires stack) and for ARM it has no effect. Drop it. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
U-Boot uses structures for hardware access so it is important that these structures are correct. Add a way of asserting that a structure member is at a particular offset. This can be created using the datasheet for the hardware. This implementation uses Static_assert() since BUILD_BUG_ON() only works within functions. Signed-off-by:
Simon Glass <sjg@chromium.org>
-