summaryrefslogtreecommitdiff
path: root/arch/arm/mach-tegra
Commit message (Collapse)AuthorAgeLines
* of: clean up OF_CONTROL ifdef conditionalsMasahiro Yamada2015-08-18-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We have flipped CONFIG_SPL_DISABLE_OF_CONTROL. We have cleansing devices, $(SPL_) and CONFIG_IS_ENABLED(), so we are ready to clear away the ugly logic in include/fdtdec.h: #ifdef CONFIG_OF_CONTROL # if defined(CONFIG_SPL_BUILD) && !defined(SPL_OF_CONTROL) # define OF_CONTROL 0 # else # define OF_CONTROL 1 # endif #else # define OF_CONTROL 0 #endif Now CONFIG_IS_ENABLED(OF_CONTROL) is the substitute. It refers to CONFIG_OF_CONTROL for U-boot proper and CONFIG_SPL_OF_CONTROL for SPL. Also, we no longer have to cancel CONFIG_OF_CONTROL in include/config_uncmd_spl.h and scripts/Makefile.spl. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
* of: flip CONFIG_SPL_DISABLE_OF_CONTROL into CONFIG_SPL_OF_CONTROLMasahiro Yamada2015-08-18-1/+0
| | | | | | | | | | | | | | | | | | | As we discussed a couple of times, negative CONFIG options make our life difficult; CONFIG_SYS_NO_FLASH, CONFIG_SYS_DCACHE_OFF, ... and here is another one. Now, there are three boards enabling OF_CONTROL on SPL: - socfpga_arria5_defconfig - socfpga_cyclone5_defconfig - socfpga_socrates_defconfig This commit adds CONFIG_SPL_OF_CONTROL for them and deletes CONFIG_SPL_DISABLE_OF_CONTROL from the other boards to invert the logic. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* ARM: tegra: represent RAM in 1 or 2 banksStephen Warren2015-08-13-14/+106
| | | | | | | | | | | | | | | | | | | | | Represent all available RAM in either one or two banks. The first bank describes any RAM below 4GB. The second bank describes any RAM above 4GB. This split is driven by the following requirements: - The NVIDIA L4T kernel requires separate entries in the DT /memory/reg property for memory below and above the 4GB boundary. The layout of that DT property is directly driven by the entries in the U-Boot bank array. - On systems with RAM beyond a physical address of 4GB, the potential existence of a carve-out at the end of RAM below 4GB can only be represented using multiple banks, since usable RAM is not contiguous. While making this change, add a lot more comments re: how and why RAM is represented in banks, and implement a few more "semantic" functions that define (and perhaps later detect at run-time) the size of any carve-out. 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: query_sdram_size() cleanupStephen Warren2015-08-13-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The return value of query_sdram_size() is assigned directly to gd->ram_size in dram_init(). Adjust the return type to match the field it's assigned to. This has the beneficial effect that on 64-bit systems, the return value can correctly represent large RAM sizes over 4GB. For similar reasons, change the type of variable size_bytes in the same way. query_sdram_size() would previously clip the detected RAM size to at most just under 4GB in all cases, since on 32-bit systems, larger values could not be represented. Disable this feature on 64-bit systems since the representation restriction does not exist. On 64-bit systems, never call get_ram_size() to validate the detected/ calculated RAM size. On any system with a secure OS/... carve-out, RAM may not have a single contiguous usable area, and this can confuse get_ram_size(). Ideally, we'd make this call conditional upon some other flag that indicates specifically that a carve-out is actually in use. At present, building for a 64-bit system is the best indication we have of this fact. In fact, the call to get_ram_size() is not useful by the time U-Boot runs on any system, since U-Boot (and potentially much other early boot software) always runs from RAM on Tegra, so any mistakes in memory controller register programming will already have manifested themselves and prevented U-Boot from running to this point. In the future, we may simply delete the call to get_ram_size() in all cases. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: Correct logic for reading pll_misc in clock_start_pll()Simon Glass2015-08-13-13/+31
| | | | | | | | | | | | The logic for simple PLLs on T124 was broken by this commit: 722e000c Tegra: PLL: use per-SoC pllinfo table instead of PLL_DIVM/N/P, etc. Correct it by reading from the same pll_misc register that it writes to and adding an entry for the DP PLL in the pllinfo table. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: tegra: Add p2371-0000 boardStephen Warren2015-08-06-0/+9
| | | | | | | | | | | 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/+8
| | | | | | | | | 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: enable GPU DT node when appropriateAlexandre Courbot2015-08-06-0/+19
| | | | | | | | | | | | | | | | 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-9/+19
| | | | | | | | | | | | | | | | 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>
* ARM: tegra: restrict usable RAM size furtherStephen Warren2015-08-06-2/+11
| | | | | | | | | | | | | | 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>
* Tegra: PLL: use per-SoC pllinfo table instead of PLL_DIVM/N/P, etc.Tom Warren2015-08-05-145/+260
| | | | | | | | | | | | | Added PLL variables (dividers mask/shift, lock enable/detect, etc.) to new pllinfo struct for each Soc/PLL. PLLA/C/D/E/M/P/U/X. Used pllinfo struct in all clock functions, validated on T210. Should be equivalent to prior code on T124/114/30/20. Thanks to Marcel Ziswiler for corrections to the T20/T30 values. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* Tegra: clocks: Add 38.4MHz OSC support for T210 useTom Warren2015-08-05-6/+27
| | | | | | | | | | | | | | | Added 38.4MHz/48MHz entries to pll_x_table for CPU PLL. Needs to be measured - should be close to 700MHz (1.4G/2). Note that some freqs aren't in the PLLU table in T210 TRM (13, 26MHz), so I used the 12MHz table entry for them. They shouldn't be selected since they're not viable T210 OSC freqs. Since there are now 2 new OSC defines, all tables (pll_x_table, PLLU) had to increase by two entries, but since 38.4/48MHz are not viable osc freqs on T20/30/114, etc, they're just set to 0. Signed-off-by: Tom Warren <twarren@nvidia.com>
* T210: P2571: Turn CPU fan onTom Warren2015-08-05-0/+3
| | | | | | | | CPU board (E2530) has a fan - turn it on via GPIO to keep the SoC cool. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* T210: Add support for 64-bit T210-based P2571 boardTom Warren2015-07-28-0/+7
| | | | | | | | | | | Based on Venice2, incorporates Stephen Warren's latest P2571 pinmux table. With Thierry Reding's 64-bit build fixes, this will build and and boot in 64-bit on my P2571 (when used with a 32-bit AVP loader). Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: Tegra210: Add support to common Tegra source/config filesTom Warren2015-07-28-25/+125
| | | | | | | | | | | Derived from Tegra124, modified as appropriate during T210 board bringup. Cleaned up debug statements to conserve string space, too. This also adds misc 64-bit changes from Thierry Reding/Stephen Warren. Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
* ARM: Tegra210: Add SoC code/include files for T210Tom Warren2015-07-28-0/+1648
| | | | | | | | | | | All based off of Tegra124. As a Tegra210 board is brought up, these may change a bit to match the HW more closely, but probably 90% of this is identical to T124. Note that since T210 is a 64-bit build, it has no SPL component, and hence no cpu.c for Tegra210. Signed-off-by: Tom Warren <twarren@nvidia.com>
* Tegra: Rework KConfig options to allow 64-bit builds (T210)Tom Warren2015-07-28-0/+18
| | | | | | | | | | Moved Tegra config options to mach-tegra/Kconfig so that both 32-bit and 64-bit builds can co-exist for Tegra SoCs. T210 will be 64-bit only (no SPL) and will require a 32-bit AVP/BPMP loader. Signed-off-by: Tom Warren <twarren@nvidia.com>
* Tegra210: Fix 64-bit build warning about save_boot_params_ret()Tom Warren2015-07-28-0/+2
| | | | | | | | Simon's 'tegra124: Implement spl_was_boot_source()' needs a prototype for save_boot_params_ret() to build cleanly for 64-bit Tegra210. Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: tegra: Initialize timer earlierThierry Reding2015-07-28-6/+6
| | | | | | | | | | | | | A subsequent patch will enable the use of the architected timer on ARMv8. Doing so implies that udelay() will be backed by this timer implementation, and hence the architected timer must be ready when udelay() is first called. The first time udelay() is used is while resetting the debug UART, which happens very early. Make sure that arch_timer_init() is called before that. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: tegra: Use standard cache enable for 64-bitThierry Reding2015-07-28-1/+1
| | | | | | | | | On 64-bit SoCs the I-cache isn't enabled in early code, so the default cache enable functions for 64-bit ARM can be used. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
* ARM: tegra: Restrict usable RAM to 32-bit on 64-bit SoCsThierry Reding2015-07-28-0/+16
| | | | | | | | | | | | | | | Most peripherals on Tegra can do DMA only to the lower 32-bit address space, even on 64-bit SoCs. This limitation is typically overcome by the use of an IOMMU. Since the IOMMU is not entirely trivial to set up and serves no other purpose (I/O protection, ...) in U-Boot, restrict 64-bit Tegra SoCs to the lower 32-bit address space for RAM. This ensures that the physical addresses of buffers that are programmed into the various DMA engines are valid and don't alias to lower addresses. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
* ARM: tegra: Build warning fixes for 64-bitThierry Reding2015-07-27-3/+3
| | | | | | | | Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> [swarren, stripped out changes not strictly related to warnings] Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* tegra124: Implement spl_was_boot_source()Simon Glass2015-07-27-0/+16
| | | | | | | Add an implementation of this function for Tegra. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* Move default y configs out of arch/board KconfigJoe Hershberger2015-06-25-12/+0
| | | | | | | | | | | | | | | | | | | Some archs/boards specify their own default by pre-defining the config which causes the Kconfig system to mix up the order of the configs in the defconfigs... This will cause merge pain if allowed to proliferate. Remove the configs that behave this way from the archs. A few configs still remain, but that is because they only exist as defaults and do not have a proper Kconfig entry. Those appear to be: SPIFLASH DISPLAY_BOARDINFO Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> [trini: rastaban, am43xx_evm_usbhost_boot, am43xx_evm_ethboot updates, drop DM_USB from MSI_Primo81 as USB_MUSB_SUNXI isn't converted yet to DM] Signed-off-by: Tom Rini <trini@konsulko.com>
* dm: usb: tegra: Drop legacy USB codeSimon Glass2015-06-10-3/+0
| | | | | | Drop the code that doesn't use driver model for USB. Signed-off-by: Simon Glass <sjg@chromium.org>
* dts: Disable device tree for SPL on all boardsSimon Glass2015-06-10-0/+3
| | | | | | | We plan to enable device tree in SPL by default. Before doing this, explicitly disable it for all boards. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: tegra: usb: Move USB to driver modelSimon Glass2015-06-10-0/+5
| | | | | | | | | | Somehow this change was dropped in the various merges. I noticed when I came to turn off the non-driver-model support for Tegra. We need to make this change (and deal with any problems) before going further. Change-Id: Ib9389a0d41008014eb0df0df98c27be65bc79ce6 Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Marek Vasut <marex@denx.de>
* tegra: Replace 'Norrin' with 'Nyan-big' and fix typoSimon Glass2015-06-09-1/+1
| | | | | | | | With the rename the MAINTAINER file was not updated. Fix it and the 'Chrombook' typo in Kconfig. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: Allow board-specific initSimon Glass2015-06-09-2/+6
| | | | | | | Add a hook to allows boards to add their own init to board_init(). Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: Add missing tegra124 peripheralsSimon Glass2015-06-09-1/+1
| | | | | | | There are some missing entries in the tables. Add them. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: Introduce SRAM repair on tegra124Simon Glass2015-06-09-1/+19
| | | | | | | | This is required in order to avoid instability when running from caches after the kernel starts. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: clock: Adjust PLL access to avoid a warningSimon Glass2015-06-09-2/+5
| | | | | | | | A harmless but confusing warning is displayed when looking up the DisplayPort PLL. Correct this. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: clock: Support enabling external clocksSimon Glass2015-06-09-0/+17
| | | | | | | Add a simple function to enable external clocks. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: tegra: move NVIDIA common files to arch/arm/mach-tegraMasahiro Yamada2015-05-13-1/+326
| | | | | | | | | | | | | | | | | | | | | 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>
* jetson-tk1: Add PSCI configuration options and reserve secure codeIan Campbell2015-05-13-0/+2
| | | | | | | | | | | | | | 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>
* ARM: tegra: Enable SMMU when going non-secureThierry Reding2015-05-13-0/+40
| | | | | | | | | | | | | 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>
* tegra: Set CNTFRQ for secondary CPUsJan Kiszka2015-05-13-0/+13
| | | | | | | | | | | | | | | We only set CNTFRQ in arch_timer_init for the boot CPU. But this has to happen for all cores. Fixing this resolves problems of KVM with emulating the generic timer/counter. 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>
* tegra124: Reserve secure RAM using MC_SECURITY_CFG{0, 1}_0Ian Campbell2015-05-13-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* tegra124: Add PSCI support for Tegra124Jan Kiszka2015-05-13-0/+168
| | | | | | | | | | | | | | | 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>
* tegra: Make tegra_powergate_power_on publicJan Kiszka2015-05-13-1/+1
| | | | | | | | | | | Will be used for unpowergating CPUs. 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>
* tegra: Move display controller header into commonSimon Glass2015-05-13-1/+1
| | | | | | | Allow this to be used by other Tegra SoCs. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra124: clock: Add display clocks and functionsSimon Glass2015-05-13-5/+138
| | | | | | | | Add functions to provide access to the display clocks on Tegra124 including setting the clock rate for an EDP display. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: clock: Split the clock source code into a separate functionSimon Glass2015-05-13-22/+29
| | | | | | | | | 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>
* tegra: clock: Add checking for invalid clock IDsSimon Glass2015-05-13-4/+26
| | | | | | | | | 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>
* tegra: Move checkboard() into the board codeSimon Glass2015-05-13-8/+0
| | | | | | | | This is only used by Nvidia boards, so move it into nvidia/common to simplify things. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: pwm: Allow the clock rate to be left as isSimon Glass2015-05-13-1/+4
| | | | | | | | When enabling a PWM, allow the existing clock rate and source to stand unchanged. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* tegra: Move the pwm into tegra-commonSimon Glass2015-05-13-2/+2
| | | | | | | | This is needed for tegra124 also, so make it common and add a header file for tegra124. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* arch: Make board selection choices optionalJoe Hershberger2015-05-12-0/+5
| | | | | | | | | | | | By making the board selections optional, every defconfig will include the board selection when running savedefconfig so if a new board is added to the top of the list of choices the former top's defconfig will still be correct. 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>
* dm: select CONFIG_DM* optionsMasahiro Yamada2015-04-18-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As mentioned in the previous commit, adding default values in each Kconfig causes problems because it does not co-exist with the "depends on" syntax. (Please note this is not a bug of Kconfig.) We should not do so unless we have a special reason. Actually, for CONFIG_DM*, we have no good reason to do so. Generally, CONFIG_DM is not a user-configurable option. Once we convert a driver into Driver Model, the board only works with Driver Model, i.e. CONFIG_DM must be always enabled for that board. So, using "select DM" is more suitable rather than allowing users to modify it. Another good thing is, Kconfig warns unmet dependencies for "select" syntax, so we easily notice bugs. Actually, CONFIG_DM and other related options have been added without consistency: some into arch/*/Kconfig, some into board/*/Kconfig, and some into configs/*_defconfig. This commit prefers "select" and cleans up the following issues. [1] Never use "CONFIG_DM=n" in defconfig files It is really rare to add "CONFIG_FOO=n" to disable CONFIG options. It is more common to use "# CONFIG_FOO is not set". But here, we do not even have to do it. Less than half of OMAP3 boards have been converted to Driver Model. Adding the default values to arch/arm/cpu/armv7/omap3/Kconfig is weird. Instead, add "select DM" only to appropriate boards, which eventually eliminates "CONFIG_DM=n", etc. [2] Delete redundant CONFIGs Sandbox sets CONFIG_DM in arch/sandbox/Kconfig and defines it again in configs/sandbox_defconfig. Likewise, OMAP3 sets CONFIG_DM arch/arm/cpu/armv7/omap3/Kconfig and defines it also in omap3_beagle_defconfig and devkit8000_defconfig. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* Merge branch 'master' of git://git.denx.de/u-boot-tegraTom Rini2015-04-03-3/+274
|\ | | | | | | | | | | | | Conflicts: board/armltd/vexpress64/vexpress64.c Signed-off-by: Tom Rini <trini@konsulko.com>
generated by cgit v1.1 at 2024-11-06 11:05:47 +0000