summaryrefslogtreecommitdiff
path: root/arch/arm/mach-uniphier
Commit message (Collapse)AuthorAgeLines
* ARM: uniphier: move pin-mux code into pin_init functionMasahiro Yamada2016-05-01-27/+5
| | | | | | | The code in uniphier_sld3_sbc_init() is pin-muxing, so it would be a better fit in uniphier_sld3_early_pin_init(). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: allow to use System Bus for ROM boot mode of PH1-LD20Masahiro Yamada2016-05-01-1/+37
| | | | | | | | | The System Bus is not available by default on the ROM boot mode of PH1-LD20. To use devices connected to the System Bus, such as the Micro Support Card, it is necessary to set up pin-muxing and some System Bus Controller register. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: enable Peripherl clock to use UART in SPLMasahiro Yamada2016-05-01-0/+4
| | | | | | This is needed to use UART on SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: fix boot mode table of PH1-LD20Masahiro Yamada2016-05-01-1/+1
| | | | | | | PH1-LD20 does not have the dedicated boot swap select latch. Instead, it is controlled from the boot mode select. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add PH1-LD20 SoC supportMasahiro Yamada2016-04-24-3/+888
| | | | | | This is the first ARMv8 SoC from Socionext Inc. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: rework uniphier_set_fdt_file()Masahiro Yamada2016-04-24-31/+31
| | | | | | | | | | | | The current table look-up for the DTB file name turned out bothersome in terms of maintainability; I ended up adding a new entry every time a new board is supported. There is a common pattern between the DT compatible string and the corresponding file name; drop the vendor prefix "socionext," and prefix it with "uniphier-" and suffix it with ".dtb". Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: carry on booting for Unknown boot modeMasahiro Yamada2016-04-24-2/+2
| | | | | | | | No need to stop booting U-Boot even if boot mode is unknown. Setting the "bootmode" environment is only useful for booting Linux Kernel. Anyway, U-Boot has already booted by this point. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add sg_set_iectrl_range()Masahiro Yamada2016-04-24-0/+8
| | | | | | | | For PH1-LD20 or later, per-pin input-enable control is supported, that is, we need to set-up IECTRL registers for a group of pins. This helper function will be useful for a bunch of register settings. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: avoid unaligned access to DT on 64bit SoCMasahiro Yamada2016-04-24-6/+4
| | | | | | | Because DT properties are 4-byte aligned, the pointer access *(fdt64_t *) in this code causes unaligned access. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL) with asm codeHans de Goede2016-04-11-66/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | v7_maint_dcache_all() does not work reliable when build with gcc6, see: https://bugzilla.redhat.com/show_bug.cgi?id=1318788 While debugging this I learned that v7_maint_dcache_all() is unreliable when build with gcc5 too when it is marked as noinline. This commit fixes the reliability issues by replacing the C-code with the ready to use asm implementation from the kernel. Given that this code when written as C-code clearly is quite fragile (also see the existing comments about the C-code being the way it is to get optimal assembly) and that we have a proven asm alternative, I believe that this is the best solution. Note that we actually already had a copy of the kernel's v7_flush_dcache_all() before this commit in arch/arm/mach-uniphier/arm32/lowlevel_init.S. This commit moves that code arch/arm/cpu/armv7/cache_v7_asm.S, renames it to __v7_flush_dcache_all(), and adds a v7_flush_dcache_all() wrapper which saves / restores the clobbered registers for use from C-code. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* cosmetic: Fix typos "privide"Masahiro Yamada2016-04-01-7/+7
| | | | Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: rename function names ph1_* to uniphier_*Masahiro Yamada2016-04-01-193/+197
| | | | | | | Eliminate the "ph1"_ prefixes from function names because "uniphier_" describes the SoC familiy better. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add pin-mux settings for NAND, eMMC, SD of PH1-sLD3Masahiro Yamada2016-04-01-0/+23
| | | | Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: adjust dram_init() and dram_init_banksize() for ARM64Masahiro Yamada2016-04-01-10/+35
| | | | | | | | | | | Currently, these functions assume #address-cells and #size-cells are both one. Fix them to support 64bit DTB. Also, I am fixing a buffer overrun bug while I am here. The array size of gd->bd->bd_dram is CONFIG_NR_DRAM_BANKS. The number of iteration in the loop should be limited by that CONFIG. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add NOR boot supportMasahiro Yamada2016-03-24-2/+2
| | | | | | | This allows to boot from NOR flash (or SRAM) with help of an external loader (NOR-loader). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: support Debug UARTMasahiro Yamada2016-03-24-0/+364
| | | | | | | | | | | | For ARM32 architecture, CONFIG_DEBUG_LL is available for early low-level debugging (and actually UniPhier 32bit SoCs use it), but ARM64 architecture does not support it. Instead, CONFIG_DEBUG_UART is available as an architecture-independent debug facility. This commit supports it on all the UniPhier SoCs (including the new ARMv8 SoCs), which is very useful for new SoC bringups. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add System Control register macros for ARMv8 SoCsMasahiro Yamada2016-03-24-0/+44
| | | | | | | | The System Control block moved to a completely different register map for ARMv8 SoCs, so it cannot be shared with the ARM 32-bit ones. Define register macros in a new header file. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add sg_set_iectrl() functionMasahiro Yamada2016-03-24-0/+11
| | | | | | | This helper function would be useful for new SoCs with per-pin input enable controlling, such as PH1-LD20, PH1-LD11, etc. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: enable DDR PHY parameter dump commands by defaultMasahiro Yamada2016-03-24-0/+2
| | | | | | | | | These commands are not necessarily needed for usual operations (they are useful in case of DDR memory trouble), but enabling them by default would be nice in terms of the compilation test coverage. They are small enough, so limited impact on the memory footprint. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add work-around to support Micro Support Card v3.6.10Masahiro Yamada2016-03-24-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to some hardware guy's awful work, this version is not compatible with v3.6: the logic of BIT(0) of the reset logic is inverted! (and v3.6.10 is horribly wrong in multiple ways), but this is what we have to solve now. The v3.6 expects 0x0000 set to the register for reset de-assertion, while v3.6 does 0x0001. This commit (ab)uses another bug of v3.6.10 to work around the issue. The UniPhier System Bus is a 16-bit bus, which this support card is connected to. A 32-bit write to the bus (writel() function call) is divided into two 16-bit write transactions, with LSB the first. What is amazing for v3.6.10 is that access to address 4N + 2 goes to 4N (Jesus Christ!). For clarification, things are like this: writel(0x00010000, MICRO_SUPPORT_CARD_RESET); is done with two bus transactions as follows [1] write 0x0000 to address MICRO_SUPPORT_CARD [2] write 0x0001 to address MICRO_SUPPORT_CARD + 2 For v3.6, [1] is written to the register and [2] is correctly ignored because there is nothing at the address MICRO_SUPPORT_CARD + 2. This is what we expect. For v3.6.10, [1] is written to the reset register and then [2] is over-written to the same register due to the bus access bug. For the latter, it produces a glitch signal to the BIT[0], so the device state is lost due to the reset pulse. This solution only works for the start-up code. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: drop ifdef in ddrphy-regs.hMasahiro Yamada2016-03-24-75/+103
| | | | | | | | | The ifdef conditionals in header files prevent us from multi-SoC support in a single U-Boot image. Detect SoC specific parameters run-time rather than define them statically with an ifdef in ddrphy-regs.h. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: refactor SBC init codeMasahiro Yamada2016-03-24-145/+105
| | | | | | | | | There is a bunch of duplication in the System Bus Controller init code. Roughly, there are two types in the SBC mode: Adress/Data Multiplex Mode and Save Pins Mode. Consolidate per-SoC functions into the two, plus per-SoC optional init code. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: drop PH1- prefix from CONFIG options and file namesMasahiro Yamada2016-03-24-224/+213
| | | | | | | | The current CONFIG names like "CONFIG_ARCH_UNIPHIER_PH1_PRO4" is too long. It would not hurt to drop "PH1_" because "UNIPHIER_" already well specifies the SoC family. Also, rename files for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: allow debug_ll_init() to do nothing for unknown SoCsMasahiro Yamada2016-03-09-0/+1
| | | | | | | This function should just return for unknown SoCs rather than writing unexpected values to registers. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: fix build error when CONFIG_CMD_DDRMPHY_DUMP=yMasahiro Yamada2016-03-09-16/+2
| | | | | | | | The build fails if compiled with CONFIG_CMD_DDRMPHY_DUMP=y since commit 46abfcc99e04 ("ARM: uniphier: rework struct uniphier_board_data"). Fixes: 46abfcc99e04 ("ARM: uniphier: rework struct uniphier_board_data") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: fix warnings reported by aarch64 compilerMasahiro Yamada2016-03-01-4/+6
| | | | | | | | | | | | The UniPhier SoC family has not supported ARMv8 yet, but these would cause warnings if they were compiled with a 64bit compiler. Before adding the ARMv8 support really, fix them now. Because UniPhier SoCs do not support Large Physical Address Extension, casting "phys_addr_t" into "unsigned long" would carry the address as is. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: prepare directory structure for ARMv8 SoC supportMasahiro Yamada2016-03-01-10/+22
| | | | | | | | | | Before adding ARMv8 support, this commit refactors the directory structure. Move ARMv7 specific files to arch/arm/mach-uniphier/arm32 to avoid a mess by mixture of ARMv7 and ARMv8 code. Also move the "select CPU_V7" to the lower-level menu because we will have to select ARM64 instead of CPU_V7 for ARMv8 SoCs. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: rename PH1-LD10/PH1-sLD11 to PH1-LD20/PH1-LD11Masahiro Yamada2016-02-29-14/+14
| | | | | | | Due to the company's awful projecting, PH1-LD10 and PH1-sLD11 have been renamed to PH1-LD20 and PH1-LD11, respectively. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: rework UniPhier SoC select in KconfigMasahiro Yamada2016-02-29-34/+28
| | | | | | | | | | The chains of "depends on <SoC_name>" in the current Kconfig is clumsy. The idea here is to allow users to choose a SoC group first (SoC group consists of some SoCs that can coexist in one binary). Then, allow to enable/disable each SoC support in the selected SoC group. This makes the Kconfig menu clearer. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: rename variable for DRAM controller base addressMasahiro Yamada2016-02-29-114/+113
| | | | | | Rename the variable that contains the base address for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: deprecate umc_dram_init_{start, poll}Masahiro Yamada2016-02-29-23/+18
| | | | Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: remove unused macros for UMC base addressesMasahiro Yamada2016-02-29-11/+0
| | | | | | | These macros are no longer used. These base addresses are SoC-dependent, so they should not be placed in the header. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: rework DRAM size handling in UMC init codeMasahiro Yamada2016-02-29-15/+15
| | | | | | | | | Currently, DRAM size is converted twice: size in byte -> size in Gbit -> enum Optimize the code by converting the "size in byte" into enum directly. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: optimize PH1-Pro4 UMC init code with "for" loopMasahiro Yamada2016-02-29-55/+59
| | | | | | | Now this code can be re-written with a "for" statement instead of calling the same function multiple times. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: optimize PH1-LD4 UMC init code with "for" loopMasahiro Yamada2016-02-29-41/+49
| | | | | | | Now this code can be re-written with a "for" statement instead of calling the same function multiple times. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: optimize PH1-sLD8 UMC init code with "for" loopMasahiro Yamada2016-02-29-40/+43
| | | | | | | Now this code can be re-written with a "for" statement instead of calling the same function multiple times. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: refactor UMC init code for PH1-LD4Masahiro Yamada2016-02-29-24/+55
| | | | | | Move frequency-dependent register settings to arrays for clean-up. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: support more DRAM use cases for PH1-sLD8Masahiro Yamada2016-02-29-6/+40
| | | | | | Support DDR3-1600 / 512MB DDR size. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: refactor UMC init code for PH1-sLD8Masahiro Yamada2016-02-29-8/+29
| | | | | | Move frequency-dependent register settings to arrays for clean-up. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: refactor DDR-PHY init codeMasahiro Yamada2016-02-29-30/+40
| | | | | | | The if-else statements for the frequency-dependent register settings seem clumsy. Moving them to arrays would make it cleaner. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: remove unused argument of ph1_ld4_ddrphy_init()Masahiro Yamada2016-02-29-16/+10
| | | | | | | The DDR PHY settings no longer depend on the DRAM size. Drop the argument from the init function. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: merge DDR PHY init code for 3 SoCsMasahiro Yamada2016-02-29-167/+14
| | | | | | | | Now these three are almost the same. The only difference is the DTPR1 register dependency on the DRAM size, but it can be ignored. (It has already been ignored in PH1-sLD8 and PH1-Pro4.) Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add a field to specify DDR3+Masahiro Yamada2016-02-29-35/+44
| | | | | | | | | | | | | Add a field to distinguish DDR3+ from (standard) DDR3. It also allows to delete CONFIG_DDR_STANDARD (this is not a software configuration, but a board attribute). Default DDR3 spec for each SoC: PH1-LD4, PH1-sLD8: DDR3+ Others: DDR3 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: disable debug circuit clocks for PH1-Pro4Masahiro Yamada2016-02-29-2/+2
| | | | | | | These settings control the clocks around the memory controller. The debug ability is unneeded once it works properly. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: remove UMC_INITCTL* and UMC_DRMR* settingsMasahiro Yamada2016-02-29-60/+0
| | | | | | | | These settings were used only for the PH1-sLD3 and older SoCs. The PH1-LD4 and newer one just ignore them because their DDR-PHY take care of such timing parameters instead. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: refactor UMC init code for ProXstream2Masahiro Yamada2016-02-29-45/+64
| | | | | | | | | | | | | | | | | Currently, a dummy value is defined for the UMC_SPCCTLA register when the DRAM size is zero. This seems weird because the controller does not need setting in the first place if the size is zero. Also, redefine enum dram_size to represent the DRAM size per 16-bit unit. This makes things simpler because the channel 0 and 1 are connected with 32-bit width DRAM, while the channel 2 is connected with 16-bit width one. I am renaming SIZE_* into DRAM_SZ_* (and also FREQ_* to DRAM_FREQ_* for consistency) while I am here because SIZE_* might be easily mixed-up with the macros in include/linux/sizes.h. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: use pr_err() where possibleMasahiro Yamada2016-02-29-5/+5
| | | | Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: optimize ProXstream2 UMC init code with "for" loopMasahiro Yamada2016-02-29-22/+11
| | | | | | | Now this code can be re-written with a "for" statement instead of calling the same function multiple times. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: rework struct uniphier_board_dataMasahiro Yamada2016-02-29-114/+161
| | | | | | | | This commit reworks "struct uniphier_board_data" with an array of DRAM channel data in it. It will allow further cleanups by means of "for" statements that iterate over the DDR channels. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: remove unused umc_polling()Masahiro Yamada2016-02-29-9/+0
| | | | | | This function is unused. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>