summaryrefslogtreecommitdiff
path: root/arch/arm/mach-tegra
Commit message (Collapse)AuthorAgeLines
* Merge branch 'master' of git://git.denx.de/u-boot-tegraTom Rini2015-03-10-35/+250
|\ | | | | | | | | | | | | Conflicts: README Signed-off-by: Tom Rini <trini@konsulko.com>
| * ARM: tegra: pinmux: support Tegra210's e_io_hv pin optionStephen Warren2015-03-04-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tegra210 has a per-pin option named e_io_hv, which indicates that the pin's input path should be configured to be 3.3v-tolerant. Add support for this. Note that this is very similar to previous chip's rcv_sel option. However, since the Tegra TRM names this option differently for the different chips, we support the new name so that the code exactly matches the naming in the TRM, to avoid confusion. This patch incorporates a few fixes from Tom Warren <twarren@nvidia.com>. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: account for different drivegroup base registersStephen Warren2015-03-04-1/+1
| | | | | | | | | | | | | | | | Tegra210 starts its drive group registers at a different offset from the APB MISC register block that other SoCs. Update the code to handle this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: support hsm/schmitt on pinsStephen Warren2015-03-04-2/+64
| | | | | | | | | | | | | | | | | | T210 support HSM and Schmitt options in the pinmux register (previous chips placed these options in the drive group register). Update the code to handle this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: partially handle varying register layoutsStephen Warren2015-03-04-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | Tegra210 moves some bits around in the pinmux registers. Update the code to handle this. This doesn't attempt to address the issues with the group-to-group varying drive group register layout mentioned earlier. This patch handles the SoC-to-SoC differences in the mux register layout. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: move some type definitionsStephen Warren2015-03-04-15/+15
| | | | | | | | | | | | | | | | | | On some future SoCs, some per-drive-group features became per-pin features. Move all type definitions early in the header so they can be enabled irrespective of the setting of TEGRA_PMX_SOC_HAS_DRVGRPS. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: handle feature removal on newer SoCsStephen Warren2015-03-04-0/+24
| | | | | | | | | | | | | | | | On some future SoCs, some of the per-drive-group features no longer exist. Add some ifdefs to support this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: simplify some definesStephen Warren2015-03-04-13/+31
| | | | | | | | | | | | | | | | | | | | Future SoCs have a slightly different combination of pinmux options per pin. This will be simpler to handle if we simply have one define per option, rather than grouping various options together, in combinations that don't align with future chips. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: add note re: drive group field definesStephen Warren2015-03-04-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tegra's drive group registers have a remarkably inconsistent layout. The current U-Boot driver doesn't take this into account at all. Add a comment to describe the issue, so at least anyone debugging the driver will be aware of this. To solve this, we'd need to add a per-drive-group data structure describing the layout for the individual register. Since we don't set up too many drive groups in U-Boot at present, this hopefully isn't causing too much practical issue. Still, we probably need to fix this sometime. Wth Tegra210, the register layout becomes almost entirely consistent, so this problem partially solves itself over time. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: add function to clear pinmux CLAMPING bitStephen Warren2015-03-04-4/+8
| | | | | | | | | | | | | | | | This is needed to correctly apply the new Jetson TK1 pinmux config. 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: support running in non-secure modeStephen Warren2015-03-04-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the CPU is in non-secure (NS) mode (when running U-Boot under a secure monitor), certain actions cannot be taken, since they would need to write to secure-only registers. One example is configuring the ARM architectural timer's CNTFRQ register. We could support this in one of two ways: 1) Compile twice, once for secure mode (in which case anything goes) and once for non-secure mode (in which case certain actions are disabled). This complicates things, since everyone needs to keep track of different U-Boot binaries for different situations. 2) Detect NS mode at run-time, and optionally skip any impossible actions. This has the advantage of a single U-Boot binary working in all cases. (2) is not possible on ARM in general, since there's no architectural way to detect secure-vs-non-secure. However, there is a Tegra-specific way to detect this. This patches uses that feature to detect secure vs. NS mode on Tegra, and uses that to: * Skip the ARM arch timer initialization. * Set/clear an environment variable so that boot scripts can take different action depending on which mode the CPU is in. This might be something like: if CPU is secure: load secure monitor code into RAM. boot secure monitor. secure monitor will restart (a new copy of) U-Boot in NS mode. else: execute normal boot process Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: support large RAM sizesStephen Warren2015-03-04-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some systems have so much RAM that the end of RAM is beyond 4GB. An example would be a Tegra124 system (where RAM starts at 2GB physical) that has more than 2GB of RAM. In this case, we want gd->ram_size to represent the actual RAM size, so that the actual RAM size is passed to the OS. This is useful if the OS implements LPAE, and can actually use the "extra" RAM. However, we can't use get_ram_size() to verify the actual amount of RAM present on such systems, since some of the RAM can't be accesses, which confuses that function. Avoid calling get_ram_size() when the RAM size is too large for it to work correctly. It's never actually needed anyway, since there's no reason for the BCT to report the wrong RAM size. In systems with >=4GB RAM, we still need to clip the reported RAM size since U-Boot uses a 32-bit variable to represent the RAM size in bytes. 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: fix variable naming in query_sdram_size()Stephen Warren2015-03-04-8/+9
| | | | | | | | | | | | | | | | | | | | size_mb is used to hold a value that's sometimes KB, sometimes MB, and sometimes bytes. Use separate correctly named variables to avoid confusion here. Also fix indentation of a conditional statement. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | dm: tegra: Enable driver model in SPL and adjust the GPIO driverSimon Glass2015-03-04-0/+3
| | | | | | | | | | | | | | | | | | | | | | Use the full driver model GPIO and serial drivers in SPL now that these are supported. Since device tree is not available they will use platform data. Remove the special SPL GPIO function as it is no longer needed. This is all in one commit to maintain bisectability. Signed-off-by: Simon Glass <sjg@chromium.org>
* | kconfig: remove unneeded dependency on !SPL_BUILDMasahiro Yamada2015-02-24-6/+6
| | | | | | | | | | | | | | Now CONFIG_SPL_BUILD is not defined in Kconfig, so "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* | kconfig: switch to single .config configurationMasahiro Yamada2015-02-24-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When Kconfig for U-boot was examined, one of the biggest issues was how to support multiple images (Normal, SPL, TPL). There were actually two options, "single .config" and "multiple .config". After some discussions and thought experiments, I chose the latter, i.e. to create ".config", "spl/.config", "tpl/.config" for Normal, SPL, TPL, respectively. It is true that the "multiple .config" strategy provided us the maximum flexibility and helped to avoid duplicating CONFIGs among Normal, SPL, TPL, but I have noticed some fatal problems: [1] It is impossible to share CONFIG options across the images. If you change the configuration of Main image, you often have to adjust some SPL configurations correspondingly. Currently, we cannot handle the dependencies between them. It means one of the biggest advantages of Kconfig is lost. [2] It is too painful to change both ".config" and "spl/.config". Sunxi guys started to work around this problem by creating a new configuration target. Commit cbdd9a9737cc (sunxi: kconfig: Add %_felconfig rule to enable FEL build of sunxi platforms.) added "make *_felconfig" to enable CONFIG_SPL_FEL on both images. Changing the configuration of multiple images in one command is a generic demand. The current implementation cannot propose any good solution about this. [3] Kconfig files are getting ugly and difficult to understand. Commit b724bd7d6349 (dm: Kconfig: Move CONFIG_SYS_MALLOC_F_LEN to Kconfig) has sprinkled "if !SPL_BUILD" over the Kconfig files. [4] The build system got more complicated than it should be. To adjust Linux-originated Kconfig to U-Boot, the helper script "scripts/multiconfig.sh" was introduced. Writing a complicated text processor is a shell script sometimes caused problems. Now I believe the "single .config" will serve us better. With it, all the problems above would go away. Instead, we will have to add some CONFIG_SPL_* (and CONFIG_TPL_*) options such as CONFIG_SPL_DM, but we will not have much. Anyway, this is what we do now in scripts/Makefile.spl. I admit my mistake with my apology and this commit switches to the single .config configuration. It is not so difficult to do that: - Remove unnecessary processings from scripts/multiconfig.sh This file will remain for a while to support the current defconfig format. It will be removed after more cleanups are done. - Adjust some makefiles and Kconfigs - Add some entries to include/config_uncmd_spl.h and the new file scripts/Makefile.uncmd_spl. Some CONFIG options that are not supported on SPL must be disabled because one .config is shared between SPL and U-Boot proper going forward. I know this is not a beautiful solution and I think we can do better, but let's see how much we will have to describe them. - update doc/README.kconfig More cleaning up patches will follow this. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* ARM: tegra: collect SoC sources into mach-tegraMasahiro Yamada2015-02-21-0/+10665
This commit moves files as follows: arch/arm/cpu/arm720t/tegra20/* -> arch/arm/mach-tegra/tegra20/* arch/arm/cpu/arm720t/tegra30/* -> arch/arm/mach-tegra/tegra30/* arch/arm/cpu/arm720t/tegra114/* -> arch/arm/mach-tegra/tegra114/* arch/arm/cpu/arm720t/tegra124* -> arch/arm/mach-tegra/tegra124/* arch/arm/cpu/arm720t/tegra-common/* -> arch/arm/mach-tegra/* arch/arm/cpu/armv7/tegra20/* -> arch/arm/mach-tegra/tegra20/* arch/arm/cpu/armv7/tegra30/* -> arch/arm/mach-tegra/tegra30/* arch/arm/cpu/armv7/tegra114/* -> arch/arm/mach-tegra/tegra114/* arch/arm/cpu/armv7/tegra124/* -> arch/arm/mach-tegra/tegra124/* arch/arm/cpu/armv7/tegra-common/* -> arch/arm/mach-tegra/* arch/arm/cpu/tegra20-common/* -> arch/arm/mach-tegra/tegra20/* arch/arm/cpu/tegra30-common/* -> arch/arm/mach-tegra/tegra30/* arch/arm/cpu/tegra114-common/* -> arch/arm/mach-tegra/tegra114/* arch/arm/cpu/tegra124-common/* -> arch/arm/mach-tegra/tegra124/* arch/arm/cpu/tegra-common/* -> arch/arm/mach-tegra/* Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Tested-by: Simon Glass <sjg@chromium.org> [ on nyan-big ] Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com>