summaryrefslogtreecommitdiff
path: root/arch/arm/include/asm/arch-rockchip/grf_rk3368.h
AgeCommit message (Collapse)Author
2017-08-13rockchip: rk3368: add DRAM controller driver with DRAM initialisationPhilipp Tomsich
This adds a DRAM controller driver for the RK3368 and places it in drivers/ram/rockchip (where the other DM-enabled DRAM controller drivers for rockchip devices should also be moved eventually). At this stage, only the following feature-set is supported: - DDR3 - 32-bit configuration (i.e. fully populated) - dual-rank (i.e. no auto-detection of ranks) - DDR3-1600K speed-bin This driver expects to run from a TPL stage that will later return to the RK3368 BROM. It communicates with later stages through the os_reg2 in the pmugrf (i.e. using the same mechanism as Rockchip's DDR init code). Unlike other DMC drivers for RK32xx and RK33xx parts, the required timings are calculated within the driver based on a target frequency and a DDR3 speed-bin (only the DDR3-1600K speed-bin is support at this time). The RK3368 also has the DDRC0_CON0 (DDR ch. 0, control-register 0) register for controlling the operation of its (single-channel) DRAM controller in the GRF block. This provides for selecting DDR3, mobile DDR modes, and control low-power operation. As part of this change, DDRC0_CON0 is also added to the GRF structure definition (at offset 0x600). Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-13net: gmac_rockchip: Add support for the RK3368 GMACPhilipp Tomsich
The GMAC in the RK3368 once again is identical to the incarnation in the RK3288 and the RK3399, except for where some of the configuration and control registers are located in the GRF. This adds the RK3368-specific logic necessary to reuse this driver. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2017-08-13rockchip: pinctrl: rk3368: move IOMUX bit-definitions to pinctrl driverPhilipp Tomsich
There is no real reason to keep the bit-definitions for the IOMUX in the grf header file (which defines the register layout of the GRF block): these should only be used by our pinctrl driver (with the possible exception of early debug-init code in TPL/SPL). This moves the relevant definitions from the grf_rk3368.h header into the pinctrl driver pinctrl_rk3368.c. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-08-13rockchip: rk3368: grf: use shifted-constantsPhilipp Tomsich
The RK3368 GRF header was still defines with a shifted-mask but with non-shifted function selectors for the IOMUX defines. As the RK3368 support is still fresh enough to allow a quick change, we do this now before having more code use this. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2017-08-13rockchip: rk3368: pmugrf: add definitions for os_reg[0..3]Philipp Tomsich
On the RK3368 we use a TPL-stage similar to Rockchip's DDR init (i.e. it initialises DRAM, leaves some info for the next stage and returns to the BootROM). To allow compatibility with Rockchip's DDR init code, we use the same register os_reg2 in pmugrf for passing this info (i.e. DRAM size and configuration) between stages. This change adds the definitions for os_reg[0] through os_reg[3] to the pmugrf structure for the RK3368. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-07-11rockchip: rk3368: add sdram driver for U-BootKever Yang
Add sdram driver in U-Boot for get the correct sdram size from sys_reg, so that U-Boot can co-work with Rockchip loader or SPL to get different dram capability and then tell the kernel. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2017-06-07rockchip: rk3368: Add pinctrl driverAndy Yan
Add driver to support iomux setup for the most commonly used peripherals on rk3368. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org>