79d75d75 | 26-Feb-2015 |
Masahiro Yamada <yamada.m@jp.panasonic.com> |
ARM: move -march=* and -mtune= options to arch/arm/Makefile
My main motivations for this commit are:
[1] Follow the arch/arm/Makefile style of Linux Kernel
[2] Maintain compiler options systematic
ARM: move -march=* and -mtune= options to arch/arm/Makefile
My main motivations for this commit are:
[1] Follow the arch/arm/Makefile style of Linux Kernel
[2] Maintain compiler options systematically Currently, we give -march=* and -mtune=* options inconsistently: Only some of the CPUs pass -march=* and -mtune=* options. By collecting such options into the single place arch/arm/Makefile we can tell which options are missing at a glance.
[3] Prepare for deprecating arch/*/cpu/*/config.mk
Note: This commit just moves the compiler options so as not to change the behavior at all. It does not care about the correctness of the given options. Fox example, "-march=armv5te" might be better than "-march=armv4" for ARM946EJS, but it is beyond the scope this commit. Also, filling the missing -march=* and -tune=* is left to follow-up patches.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Stefan Roese <sr@denx.de>
show more ...
|
2364e151 | 08-May-2014 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: use a CPU freq that all SKUs can support
U-Boot on Tegra30 currently selects a main CPU frequency that cannot be supported at all on some SKUs, and needs higher VDD_CPU/VDD_CORE values o
ARM: tegra: use a CPU freq that all SKUs can support
U-Boot on Tegra30 currently selects a main CPU frequency that cannot be supported at all on some SKUs, and needs higher VDD_CPU/VDD_CORE values on some others. This can result in unreliable operation of the main CPUs.
Resolve this by switching to a CPU frequency that can be supported by any SKU. According to the following link, the maximum supported CPU frequency of the slowest Tegra30 SKU is 600MHz:
repo http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=summary branch l4t/l4t-r16-r2 path arch/arm/mach-tegra/tegra3_dvfs.c table cpu_dvfs_table[]
According to that same table, the minimum VDD_CPU required to operate at that frequency across all SKUs is 1.007V. Given the adjustment resolution of the TPS65911 PMIC that's used on all Tegra30-based boards we support, we'll end up using 1.0125V instead.
At that VDD_CPU, tegra3_get_core_floor_mv() in that same file dictates that VDD_CORE must be at least 1.2V on all SKUs. According to tegra_core_speedo_mv() (in tegra3_speedo.c in the same source tree), that voltage is safe for all SKUs.
An alternative would be to port much of the code from tegra3_dvfs.c and tegra3_speedo.c in the kernel tree mentioned above. That's more work than I want to take on right now.
While all the currently supported boards use the same regulator chip for VDD_CPU, different types of regulators are used for VDD_CORE. Hence, we add some small conditional code to select how VDD_CORE is programmed. If this becomes more complex in the future as new boards are added, or we end up adding code to detect the SoC SKU and dynamically determine the allowed frequency and required voltages, we should probably make this a runtime call into a function provided by the board file and/or relevant PMIC driver.
Cc: Alban Bedel <alban.bedel@avionic-design.de> Cc: Marcel Ziswiler <marcel@ziswiler.com> Cc: Bard Liao <bardliao@realtek.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
d68c9429 | 21-Mar-2014 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: Tegra124 pinmux cleanup
This renames all the pinmux pins, drive groups, and functions so they have a prefix which matches the type name. These lists are also auto- generated using script
ARM: tegra: Tegra124 pinmux cleanup
This renames all the pinmux pins, drive groups, and functions so they have a prefix which matches the type name. These lists are also auto- generated using scripts that were also used to generate the kernel pinctrl drivers. This ensures that the lists are consistent between the two.
The entries in tegra124_pingroups[] are all updated to remove the columns which are no longer used.
All affected code is updated to match.
There are differences in the set of drive groups. I have validated this against the TRM. There are differences order of pin definitions in pinmux.c; these previously had significant mismatches with the correct order:-( I adjusted a few entries in pinmux-config-venice2.h since the set of legal functions for some pins was updated to match the TRM.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
716ff5ce | 03-Feb-2014 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: simplify halt_avp()
In order to completely halt the AVP processor, we should simply write FLOW_MODE_STOP without any extra options that allow wakeup. Amend the code to do this.
I believ
ARM: tegra: simplify halt_avp()
In order to completely halt the AVP processor, we should simply write FLOW_MODE_STOP without any extra options that allow wakeup. Amend the code to do this.
I believe that enabling FIQ_1 and IRQ_1 allow the CPU to be awoken by interrupts. We don't want this; if later SW wishes to use the AVP, it should be reset and booted from scratch.
Related, the bits that were previously IRQ_1 and FIQ_1 have a slightly different definition starting with Tegra114, so the values we're writing don't entirely make sense there anyway.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
a4bcd67c | 24-Jan-2014 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: remove a conditional for CSITE rate
There's already an SoC-specific conditional in cpu.h to determine the PLLP rate. Define the CSITE clock rate inside the same conditional, so that we c
ARM: tegra: remove a conditional for CSITE rate
There's already an SoC-specific conditional in cpu.h to determine the PLLP rate. Define the CSITE clock rate inside the same conditional, so that we can remove a conditional from clock_enable_coresight(). This means one less place to update the code for new SoCs.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|
41447fb2 | 24-Jan-2014 |
Stephen Warren <swarren@nvidia.com> |
ARM: tegra: enable PLLX only once it's been fully configured
This programming sequence is correct per Jimmy Zhang, and makes sense too!
Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by:
ARM: tegra: enable PLLX only once it's been fully configured
This programming sequence is correct per Jimmy Zhang, and makes sense too!
Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
show more ...
|