summaryrefslogtreecommitdiff
path: root/include
Commit message (Collapse)AuthorAgeLines
...
* | arm: socfpga: clock: Clean up pll_config.hMarek Vasut2015-08-08-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extract the clock configuration horribleness caused by pll_config.h in the following manner. First of all, introduce a few new accessors which return values of various clocks used in clock_manager.c and use them in clock_manager.c . These accessors replace those few macros which came from pll_config.h originally. Also introduce an accessor which returns the struct cm_config default configuration for the clock manager used in SPL. The accessors are implemented in a board-specific wrap_pll_config.c file, whose sole purpose is to include the qts-generated pll_config.h and provide only the necessary values to the clock manager. The purpose of this design is to limit the scope of inclusion for the pll_config.h , which thus far was included build-wide and poluted the namespace. With this change, the inclusion is limited to just the new wrap_pll_config.c file, which in turn provides three simple functions for the clock_manager.c to use. Signed-off-by: Marek Vasut <marex@denx.de>
* | arm: socfpga: enable the Altera SDRAM controller driverDinh Nguyen2015-08-08-0/+5
| | | | | | | | | | | | | | Enable the Altera SDRAM driver for the SoCFPGA platform. Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com> Acked-by: Marek Vasut <marex@denx.de>
* | arm: socfpga: Move generated files into qts subdirMarek Vasut2015-08-08-6/+6
|/ | | | | | | | | 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>
* Merge git://git.denx.de/u-boot-dmTom Rini2015-08-06-264/+771
|\
| * dm: core: Fix a typo in the uclass_get_device_by_name() commentSimon Glass2015-08-06-1/+1
| | | | | | | | | | | | | | This function comment has a typo. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * dm: core: Add a way to set a device nameSimon Glass2015-08-06-0/+15
| | | | | | | | | | | | | | | | | | | | 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>
| * devres: add debug command to dump device resourcesMasahiro Yamada2015-08-06-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: => dm devres - root_driver - soc - extbus - serial@54006800 bfb541e8 (8 byte) devm_kmalloc_release BIND bfb54440 (4 byte) devm_kmalloc_release PROBE bfb54460 (4 byte) devm_kmalloc_release PROBE - serial@54006900 bfb54270 (8 byte) devm_kmalloc_release BIND - gpio@55000000 - i2c@58780000 bfb5bce8 (12 byte) devm_kmalloc_release PROBE bfb5bd10 (4 byte) devm_kmalloc_release PROBE - eeprom bfb54418 (12 byte) devm_kmalloc_release BIND Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
| * devres: make Devres optional with CONFIG_DEVRESMasahiro Yamada2015-08-06-0/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)Masahiro Yamada2015-08-06-0/+44
| | | | | | | | | | | | | | | | | | | | | | 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>
| * devres: introduce Devres (Managed Device Resource) frameworkMasahiro Yamada2015-08-06-0/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * dm: add DM_FLAG_BOUND flagMasahiro Yamada2015-08-06-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Currently, we only have DM_FLAG_ACTIVATED to indicate the device status, but we still cannot know in which stage is in progress, binding or probing. This commit introduces a new flag, DM_FLAG_BOUND, which is set when the device is really bound, and cleared when it is unbound. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
| * dm: Support address translation for simple-busSimon Glass2015-08-06-0/+12
| | | | | | | | | | | | | | | | 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. Signed-off-by: Simon Glass <sjg@chromium.org>
| * lib/fdtdec: Fix fdt_addr_t and fdt_size_t typedefYork Sun2015-08-06-4/+2
| | | | | | | | | | | | | | | | | | 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>
| * exynos: Add support for springSimon Glass2015-08-05-0/+20
| | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dts: Drop unused compatible ID for the NXP video bridgeSimon Glass2015-08-05-1/+0
| | | | | | | | | | | | This has moved to driver model so we can drop the fdtdec support. Signed-off-by: Simon Glass <sjg@chromium.org>
| * video: Remove the old parade driverSimon Glass2015-08-05-23/+0
| | | | | | | | | | | | | | We have a new one which uses driver model and device tree configuration. Remove the old one. Signed-off-by: Simon Glass <sjg@chromium.org>
| * cros_ec: Remove the old tunnel codeSimon Glass2015-08-05-14/+0
| | | | | | | | | | | | This is not needed with driver mode. Remove it. Signed-off-by: Simon Glass <sjg@chromium.org>
| * power: Remove old TPS65090 driversSimon Glass2015-08-05-76/+0
| | | | | | | | | | | | | | Remove the old drivers (both the normal one and the cros_ec one) now that we have new drivers that use driver model. Signed-off-by: Simon Glass <sjg@chromium.org>
| * exynos: Drop old exynos5250-specific board codeSimon Glass2015-08-05-0/+2
| | | | | | | | | | | | | | Now that most exynos5250 boards can use the generic exynos5 code, switch over to it and remove the old code. Signed-off-by: Simon Glass <sjg@chromium.org>
| * exynos: Drop old exynos5420-specific board codeSimon Glass2015-08-05-0/+2
| | | | | | | | | | | | | | | | Now that exynos5420 boards can use the generic exynos5 code, switch over to it and remove the old code. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
| * exynos: config: Move common options to the common headers and tidy upSimon Glass2015-08-05-90/+39
| | | | | | | | | | | | | | | | | | | | Many options are duplicated on the exynos5 boards. Move these to the common files. Also some options are not used so can be removed. Tidy this up to make the files easier to maintain. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
| * exynos: Enable new features for exynos5 boardsSimon Glass2015-08-05-19/+6
| | | | | | | | | | | | | | Enable PMICs, regulators and the like so that new drivers will be made available. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: video: Add support for video bridgesSimon Glass2015-08-05-0/+93
| | | | | | | | | | | | | | | | | | 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. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: power: Add support for the S5M8767 PMICSimon Glass2015-08-05-0/+85
| | | | | | | | | | | | | | | | | | | | 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>
| * dm: power: Add a new driver for the TPS65090 PMICSimon Glass2015-08-05-0/+56
| | | | | | | | | | | | | | | | | | 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>
| * cros_ec: Support the LDO access method used by springSimon Glass2015-08-05-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: cros_ec: Convert the I2C tunnel code to use driver modelSimon Glass2015-08-05-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: i2c: Add support for multiplexed I2C busesSimon Glass2015-08-05-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: i2c: Add a function to transfer messagesSimon Glass2015-08-05-0/+13
| | | | | | | | | | | | | | | | | | | | | | 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>
| * dm: i2c: Move definitions to the top of the header fileSimon Glass2015-08-05-43/+43
| | | | | | | | | | | | | | | | Move the flags and struct definitions higher in the file so that we can reference them with functions declared in the driver model section. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: i2c: Correct comment nits in dm_i2c_reg_read/write()Simon Glass2015-08-05-0/+2
| | | | | | | | | | | | | | Add documentation for the @dev parameter. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: i2c: Add a message debug functionSimon Glass2015-08-05-0/+10
| | | | | | | | | | | | | | Add a way to dump the contents of an I2C message for debugging purposes. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: core: Support finding a device by phandleSimon Glass2015-08-05-0/+17
| | | | | | | | | | | | | | | | | | It is common for one node to reference another via a phandle. Add support for obtaining an attached device by this method. As an example, a node may have a 'power-supply' property which references a regulator, allowing the driver to turn on its power. Signed-off-by: Simon Glass <sjg@chromium.org>
* | ARM: tegra: Add p2371-0000 boardStephen Warren2015-08-06-0/+65
| | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: tegra: Add e2220-1170 boardStephen Warren2015-08-06-0/+65
| | | | | | | | | | | | | | | | | | E2220-1170 is a Tegra210 bringup board with onboard SoC, DRAM, eMMC, SD card slot, HDMI, USB micro-B port, and sockets for various expansion modules. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: p2571: remove another unused defineStephen Warren2015-08-06-3/+0
| | | | | | | | | | | | | | | | CONFIG_MAX77620_POWER isn't used anywhere. Don't define it in p2571.h. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: enable GPU DT node when appropriateAlexandre Courbot2015-08-06-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 stageAlexandre Courbot2015-08-06-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Tegra: P2571: Clean up config fileTom Warren2015-08-05-6/+1
| | | | | | | | | | | | | | Removed NS16550_COM1 #define, not used since there's no SPL for T210 Also changed the number of USB controllers to 1 as only USBD is used. Signed-off-by: Tom Warren <twarren@nvidia.com>
* | Tegra: spi: Move TEGRA114_SPI switch to defconfigsTom Warren2015-08-05-10/+0
| | | | | | | | | | | | | | | | | | | | | | All T114+ Tegra boards should be using the Kconfig TEGRA114_SPI switch. Remove it from include/config and put it into defconfig. Also removed unused TEGRA114_SPI_CTRLS from T114+ configs. All Tegra SoCs build OK with this change. Signed-off-by: Tom Warren <twarren@nvidia.com>
* | T210: P2571: Restore USB gadget mode (ums)Tom Warren2015-08-05-0/+1
|/ | | | | | | | | | The tegra-common-usb-gadget.h include was causing some build problems in ci_udc.c with a 64-bit gcc in an earlier version of the T210 patches, but it is working fine now, so restore it. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* configs: Remove CONFIG_SERIAL_MULTIStephen Warren2015-08-05-16/+0
| | | | | | | This config option isn't used anywhere at all. Remove all places that define/enable the option. Signed-off-by: Stephen Warren <swarren@nvidia.com>
* Merge git://git.denx.de/u-boot-x86Tom Rini2015-08-05-35/+736
|\
| * efi: Add 64-bit payload supportSimon Glass2015-08-05-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Most EFI implementations use 64-bit. Add a way to build U-Boot as a 64-bit EFI payload. The payload unpacks a (32-bit) U-Boot and starts it. This can be enabled for x86 boards at present. Signed-off-by: Simon Glass <sjg@chromium.org> Improvements to how the payload is built: Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * efi: Add support for loading U-Boot through an EFI stubSimon Glass2015-08-05-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is useful to be able to load U-Boot onto a board even if is it already running EFI. This can allow access to the U-Boot command interface, flexible booting options and easier development. The easiest way to do this is to build U-Boot as a binary blob and have an EFI stub copy it into RAM. Add support for this feature, targeting 32-bit initially. Also add a way to detect when U-Boot has been loaded via a stub. This goes in common.h since it needs to be widely available so that we avoid redoing initialisation that should be skipped. Signed-off-by: Simon Glass <sjg@chromium.org> Improvements to how the payload is built: Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Add definitions for the x86-efi board and plumb it inBen Stoltz2015-08-05-0/+34
| | | | | | | | | | | | | | | | Add configuration and Kconfig changes for this board. Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * Add a way to skip relocationSimon Glass2015-08-05-0/+1
| | | | | | | | | | | | | | | | | | | | | | When running U-Boot as an EFI application we cannot relocate since we do not have relocation information. U-Boot has already been relocated to a suitable address. Add a global_data flag to control skipping relocation. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: minnowmax: Drop the old PCI settingsSimon Glass2015-08-05-12/+0
| | | | | | | | | | | | | | | | These are now in the device tree so we don't need to use the CONFIG options. Drop them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Drop CONFIG_DCACHE_RAM_MRC_VAR_SIZE from header fileSimon Glass2015-08-05-1/+0
| | | | | | | | | | | | | | This is provided in Kconfig so we don't need it here. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Move CONFIG_X86_SERIAL to KconfigSimon Glass2015-08-05-10/+1
| | | | | | | | | | | | | | Move this config option to Kconfig and tidy up. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
generated by cgit v1.1 at 2024-11-08 10:49:59 +0000