Rockchip: generalize GRF setup

The General register files contain a big bunch of settings for various components. Things like the automatic sdmmc/jtag switch may even affect us in a bad way, while that property (and possibly others) are not even part of the dw_mmc controller itself.

And while the rk3288 could still carry adaptions to these defaults in its mach files, this is no longer possible on the arm64 socs, while things like the jtag-switch from above still can affect us there.

changes in v3:
- remove duplicate regmap header (now they're even sorted alphabetically)
- add Dougs Review-tag from v2
- fix the of_find_matching_node_and_match being over 80 chars

changes in v2:
- address comments from Doug Anderson
- drop platform device, as we actual probing may happen at some unspecified later time during boot
- add reviews / acks received in v1

Heiko Stuebner (3):
dt-bindings: add used but undocumented rockchip grf compatible values
soc: rockchip: add driver handling grf setup
ARM: rockchip: drop rk3288 jtag/mmc switch handling

 .../devicetree/bindings/soc/rockchip/grf.txt       |   4 +
 arch/arm/mach-rockchip/rockchip.c                  |  12 --
 drivers/soc/rockchip/Kconfig                       |  10 ++
 drivers/soc/rockchip/Makefile                      |   1 +
 drivers/soc/rockchip/grf.c                         | 133 +++++++++++++++++++++
 5 files changed, 148 insertions(+), 12 deletions(-)
 create mode 100644 drivers/soc/rockchip/grf.c

2.10.2

There are some more General Register Files used in devicetree files already, but as of now undocumented in the binding document, fix that.

---
 Documentation/devicetree/bindings/soc/rockchip/grf.txt | 4 ++++
 1 file changed, 4 insertions(+)

index 013e71a..c6e62cb 100644
@@ -5,11 +5,13 @@ is composed of many registers for system control.
 
 From RK3368 SoCs, the GRF is divided into two sections,
 - GRF, used for general non-secure system,
+- SGRF, used for general secure system,
 - PMUGRF, used for always on system
 
 Required Properties:
 
 - compatible: GRF should be one of the followings
+   - "rockchip,rk3036-grf", "syscon": for rk3036
    - "rockchip,rk3066-grf", "syscon": for rk3066
    - "rockchip,rk3188-grf", "syscon": for rk3188
    - "rockchip,rk3228-grf", "syscon": for rk3228

@@ -19,6 +21,8 @@ Required Properties:
 - compatible: PMUGRF should be one of the followings
    - "rockchip,rk3368-pmugrf", "syscon": for rk3368
    - "rockchip,rk3399-pmugrf", "syscon": for rk3399
+- compatible: SGRF should be one of the following
+   - "rockchip,rk3288-sgrf", "syscon": for rk3288
 - reg: physical base address of the controller and length of memory mapped
   region.
 

2.10.2

The General Register Files are an area of registers containing a lot of single-bit settings for numerous components as well full components like usbphy control. Therefore all used components are accessed via the syscon provided by the grf nodes or from the sub-devices created through the simple-mfd created from the grf node.

Some settings are not used by anything but will need to be set up according to expectations on the kernel side.

Best example is the force_jtag setting, which defaults to on and results in the soc switching the pin-outputs between jtag and sdmmc automatically depending on the card-detect status. This conflicts heavily with how the dw_mmc driver expects to do its work and also with the clock-controller, which has most likely deactivated the jtag clock due to it being unused.

So far the handling of this setting was living in the mach-rockchip code for the arm32-based rk3288 but that of course doesn't work for arm64 socs and would also look ugly for further arm32 socs.

Also always disabling this setting is quite specific to linux and its subsystems, other operating systems might prefer other settings, so that the bootloader cannot really set a sane default for all.

So introduce a top-level driver for the grf that handles these settings that need to be a certain way but nobody cares about.

Other needed settings might surface in the future and can then be added here, but only as a last option. Ideally general GRF settings should be handled in the driver needing them.

---
 drivers/soc/rockchip/Kconfig  |  10 ++++
 drivers/soc/rockchip/Makefile |   1 +
 drivers/soc/rockchip/grf.c    | 133 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 144 insertions(+)
 create mode 100644 drivers/soc/rockchip/grf.c

index 7140ff8..20da55d 100644
@@ -3,6 +3,16 @@ if ARCH_ROCKCHIP || COMPILE_TEST
 #
 # Rockchip Soc drivers
 #
+
+config ROCKCHIP_GRF
+	bool
+	default y
+	help
+	  The General Register Files are a central component providing
+	  special additional settings registers for a lot of soc-components.
+	  In a lot of cases there also need to be default settings initialized
+	  to make some of them conform to expectations of the kernel.
+
 config ROCKCHIP_PM_DOMAINS
         bool "Rockchip generic power domain"
         depends on PM

index 3d73d06..c851fa0 100644
@@ -1,4 +1,5 @@
 #
 # Rockchip Soc drivers
 #
+obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
 obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o

2.10.2

We moved that functionality to a more generic place where it can also be used for other socs, so drop it from architecture code.

---
 arch/arm/mach-rockchip/rockchip.c | 12 ------------
 1 file changed, 12 deletions(-)

index e7fdf06..0008783 100644
@@ -29,13 +29,11 @@
 #include "core.h"
 #include "pm.h"
 
-#define RK3288_GRF_SOC_CON0 0x244
 #define RK3288_TIMER6_7_PHYS 0xff810000
 
 static void __init rockchip_timer_init(void)
 {
 	if (of_machine_is_compatible("rockchip,rk3288")) {
-		struct regmap *grf;
 		void __iomem *reg_base;
 
 		/*

@@ -54,16 +52,6 @@ static void __init rockchip_timer_init(void)
 		} else {
 			pr_err("rockchip: could not map timer7 registers\n");
 		}
-
-		/*
-		 * Disable auto jtag/sdmmc switching that causes issues
-		 * with the mmc controllers making them unreliable
-		 */
-		grf = syscon_regmap_lookup_by_compatible("rockchip,rk3288-grf");
-		if (!IS_ERR(grf))
-			regmap_write(grf, RK3288_GRF_SOC_CON0, 0x10000000);
-		else
-			pr_err("rockchip: could not get grf syscon\n");
 	}
 
 	of_clk_init(NULL);

2.10.2

Am Donnerstag, 17. November 2016, 00:03:01 CET schrieb Heiko Stuebner:

applied these 3 to my drivers branch for 4.11