arm/dt: Add SoC detection macros

These macros allow runtime query of SoC family and version via soc_is_*() ?If the corresponding SoC is not configured the macro will evaluate to 0. ?If the corresponding SoC is the only architecure configured, the macro will evaluate to 1. ?If multiple architecures are configured the macro will evaluate to a runtime call to soc_get_version().

arch/arm/include/asm/soc.h new file +28 -0

+#ifdef CONFIG_ARCH_TEGRA_2x_SOC
+# ifdef SOC_NAME
+#  undef MULTI_SOC
+#  define MULTI_SOC
+# else
+#   define SOC_NAME tegra2
+# endif
+#endif
+#ifdef CONFIG_ARCH_TEGRA_3x_SOC
+# ifdef SOC_NAME
+#  undef MULTI_SOC
+#  define MULTI_SOC
+# else
+#   define SOC_NAME tegra3
+# endif
+#endif
+
+#define soc_is_tegra2()			0
+#define soc_is_tegra3()			0
+
+#if defined(MULTI_SOC)
+# if defined(CONFIG_ARCH_TEGRA_2x_SOC)
+#  undef soc_is_tegra2
+#  define soc_is_tegra2()		is_tegra2()
+# endif
+# if defined(CONFIG_ARCH_TEGRA_3x_SOC)
+#  undef soc_is_tegra3
+#  define soc_is_tegra3()		is_tegra3()

arch/arm/include/asm/soc.h new file +4 -0

+};
+
+void soc_init_version(void);
+enum soc_version soc_get_version(void);

Quoted 28 lines · Allen Martin

arch/arm/include/asm/soc.h new file +28 -0

+#ifdef CONFIG_ARCH_TEGRA_2x_SOC
+# ifdef SOC_NAME
+#  undef MULTI_SOC
+#  define MULTI_SOC
+# else
+#   define SOC_NAME tegra2
+# endif
+#endif
+#ifdef CONFIG_ARCH_TEGRA_3x_SOC
+# ifdef SOC_NAME
+#  undef MULTI_SOC
+#  define MULTI_SOC
+# else
+#   define SOC_NAME tegra3
+# endif
+#endif
+
+#define soc_is_tegra2()			0
+#define soc_is_tegra3()			0
+
+#if defined(MULTI_SOC)
+# if defined(CONFIG_ARCH_TEGRA_2x_SOC)
+#  undef soc_is_tegra2
+#  define soc_is_tegra2()		is_tegra2()
+# endif
+# if defined(CONFIG_ARCH_TEGRA_3x_SOC)
+#  undef soc_is_tegra3
+#  define soc_is_tegra3()		is_tegra3()

arch/arm/include/asm/soc.h line 57

Quoted 10 lines

arch/arm/include/asm/soc.h new file +10 -0

+# endif
+#else /* non-multi, only one architecture is on */
+# if defined(CONFIG_ARCH_TEGRA_2x_SOC)
+#  undef soc_is_tegra2
+#  define soc_is_tegra2()		1
+# elif defined(CONFIG_ARCH_TEGRA_3x_SOC)
+#  undef soc_is_tegra3
+#  define soc_is_tegra3()		1
+# endif
+#endif

This is not the way to do this, especially for a file in asm/*.h. Look at the way machine_is_xxx() is dealt with in include/generated/mach-types.h.

#define MULTI_SOC 0
#undef SOC_SELECTED

#ifdef CONFIG_ARCH_TEGRA_2x_SOC

# ifdef SOC_SELECTED
#  undef MULTI_SOC
#  define MULTI_SOC			1
# else
#  define SOC_SELECTED
# endif
# define soc_is_tegra2()		(!MULTI_SOC || is_tegra2())
#else
# define soc_is_tegra2()		0
#endif

#ifdef CONFIG_ARCH_TEGRA_3x_SOC

# ifdef SOC_SELECTED
#  undef MULTI_SOC
#  define MULTI_SOC			1
# else
#  define SOC_SELECTED
# endif
# define soc_is_tegra3()		(!MULTI_SOC || is_tegra3())
#else
# define soc_is_tegra3()		0
#endif

#undef SOC_SELECTED

The above is nicely extensible - if other SoCs need to extend this they just need to add another outer ifdef..endif section to the file.

arch/arm/include/asm/soc.h line 62

Quoted 5 lines

arch/arm/include/asm/soc.h new file +5 -0

+
+enum soc_version {
+	SOC_UNKNOWN = 0,
+	TEGRA_T20,
+	TEGRA_T30,

I'd suggest prefixing these with SOC_ to avoid any namespace problems.

Quoted 4 lines

arch/arm/include/asm/soc.h new file +4 -0

+};
+
+void soc_init_version(void);
+enum soc_version soc_get_version(void);

arch/arm/include/asm/soc.h line 76

Quoted 10 lines

arch/arm/include/asm/soc.h new file +10 -0

+
+static inline int is_tegra2(void)
+{
+	return soc_get_version() == TEGRA_T20;
+}
+
+static inline int is_tegra3(void)
+{
+	return soc_get_version() == TEGRA_T30;
+}

If we require all SoCs to provide a value in soc_version, then we can use exactly the same method as mach-types.h uses - and while at this, please get rid of soc_get_version(). It's far cheaper to access the variable directly rather than indirect through a function, just like we do with __machine_arch_type. Mark it __read_mostly too.

One last point to raise here is - and it's quite a fundamental one - do we really want this? If we're making decisions based on the SoC type, that suggests to me that the hardware description in DT is incomplete, and we're hiding stuff in the kernel behind the SoC type. That doesn't sound particularly appealing given the point of DT is to encode the hardware specific information outside the kernel code.

Quoted 6 lines · Russell King - ARM Linux

One last point to raise here is - and it's quite a fundamental one - do we really want this? If we're making decisions based on the SoC type, that suggests to me that the hardware description in DT is incomplete, and we're hiding stuff in the kernel behind the SoC type. That doesn't sound particularly appealing given the point of DT is to encode the hardware specific information outside the kernel code.

except if a machine can run on 2 soc so detect it will avoid to have 2 Device Tree

Quoted 10 lines · Jean-Christophe PLAGNIOL-VILLARD

Quoted 6 lines · Russell King - ARM Linux

One last point to raise here is - and it's quite a fundamental one - do we really want this? If we're making decisions based on the SoC type, that suggests to me that the hardware description in DT is incomplete, and we're hiding stuff in the kernel behind the SoC type. That doesn't sound particularly appealing given the point of DT is to encode the hardware specific information outside the kernel code.

except if a machine can run on 2 soc so detect it will avoid to have 2 Device Tree

This code is structured to match the SoC based upon an entry in the DT, so for tegra2 vs tegra3 it's already having to have two different DTs to distinguish between them.

However, I still go back to my original point: the point of DT is to provide a description of the hardware which the kernel is running on - not only for current hardware but possibly future hardware as well. Eg, if Tegra4 comes along with more peripherals than Tegra3 but has basic hardware which the kernel already supports, just wired up differently, then Tegra4 should just work with a new DT file and no code changes.

What I'm saying is that in that scenario it should not be necessary to edit the kernel to invent new SoC types, and then teach it that Tegra4 is mostly the same as Tegra3. That information should all be encoded into the DT rather than the C code in the kernel.

So, I think adding this SoC type stuff is the wrong approach to the problem.

I agree about it I just mean that if you have the same board with 2 SoC which are pin to pin compatible detect the soc type will be usefull as the soc resource may not be the same

Quoted 4 lines · On Saturday 17 September 2011 20:19:07 Jean-Christophe PLAGNIOL-VILLARD wrote:

I agree about it I just mean that if you have the same board with 2 SoC which are pin to pin compatible detect the soc type will be usefull as the soc resource may not be the same

In that scenario, you would put all SOC specific data into one .dtsi file and all board data into another .dtsi file and then create a description for the combination using a trivial .dts file with two include statements. This is all solved outside of the kernel already, so there is no need for infrastructure in the kernel.

Quoted 6 lines · Arnd Bergmann

Quoted 4 lines · On Saturday 17 September 2011 20:19:07 Jean-Christophe PLAGNIOL-VILLARD wrote:

I agree about it I just mean that if you have the same board with 2 SoC which are pin to pin compatible detect the soc type will be usefull as the soc resource may not be the same

Quoted 5 lines

In that scenario, you would put all SOC specific data into one .dtsi file and all board data into another .dtsi file and then create a description for the combination using a trivial .dts file with two include statements. This is all solved outside of the kernel already, so there is no need for infrastructure in the kernel.

except in this case you must have 2 machine id which can be avoided if you can detect the soc at kernel level

What I'm saying is that in that scenario it should not be necessary to edit the kernel to invent new SoC types, and then teach it that Tegra4 is mostly the same as Tegra3. That information should all be encoded into the DT rather than the C code in the kernel.

So, I think adding this SoC type stuff is the wrong approach to the problem.

Quoted 6 lines

What I'm saying is that in that scenario it should not be necessary to edit the kernel to invent new SoC types, and then teach it that Tegra4 is mostly the same as Tegra3. ?That information should all be encoded into the DT rather than the C code in the kernel.

So, I think adding this SoC type stuff is the wrong approach to the problem.

What ends up happening in practice for a lot of hw blocks inside the SoC, is that tegra4 is mostly the same as tegra3 with a few new registers and bug fixes that slightly change the programming model. ?So either we have to add device quirks to teach device tree about the differences, and pass those in as flags to the driver, or we can do SoC detection at runtime in the driver. ?It sounds like the consensus from you and Olof is that the first is preferable.