[PATCH v5 0/2] Introducing Exynos ChipId driver

[PATCH v5 0/2] Introducing Exynos ChipId driver

[Pankaj Dubey]

This patch series introduces Exynos Chipid platform driver.
Each Exynos SoC has ChipID block which can give information about SoC's
product Id and revision number.
At the same time it reduces dependency of mach-exynos files from plat-samsung,
by removing samsung_rev API, similar API is introduced in chipid driver itself
to get revision number and product id. 

This patch series is based on Kukjin Kim's for-next having SHA_ID:
9db7d78aca2c7fbc19a26ce2ef01c805dc010c72

It can also be cleanly applied on latest (next-20141209) linux-next.

This has been tested against both tree on Exynos3250 and Exynos5250 (SMDK) board.

Revision 4 and it's discussion can be found here
 - https://lkml.org/lkml/2014/12/3/115

Changes since v4:
 - Removed custom sysfs entries as they were not providing any new information
   as pointed out by Arnd.
 - Removed functions exporting product_id and revision, instead we will export
   exynos_chipid_info structure. It will be helpfull when we need to provide more
   fields of chipid outside of chipid, as commented by Yadwinder
 - Converted all funcions as __init. 

Change since v3: 
 - This patch set contains 5/6 and 6/6 patch from v3 series.
 - Made EXYNOS_CHIPID config option non-user selectable,
   as suggested by Tomasz Figa.
 - Made uniform macro for EXYNOS4/5_SOC_MASK as EXYNOS_SOC_MASK as
   suggested by Tomasz Figa.
 - Made local variables static in chipid driver.
 - Added existing SoC's product id's.
 - Added platform driver support.

Changes since v2:
 - Reorganized patches as suggested by Tomasz Figa.
 - Addressed review comments of Tomasz Figa in i2c-s3c2410.c file.

Changes since v1:
 - Added patch to move i2c interrupt re-configuration code from exynos.c
   to i2c driver, as suggested by Arnd.
 - After above patch only user of SYS_I2C_CFG register is pm.c so moving
   save/restore of this register also into i2c driver.
 - Spiltted up exynos4 and exynos5 machine descriptors to get rid from
   soc_is_exynos4/exynos5 kind of macros, as suggested by Arnd.
 - Changed location of chipid driver to "drivers/soc".
 - Added drivers/base/soc.c provided infrastructure to make SoC specific 
   information avaible to user space via sysfs entry, as suggested by Arnd.


Pankaj Dubey (2):
  soc: samsung: add exynos chipid driver support
  ARM: EXYNOS: refactoring of mach-exynos to enable chipid driver

 arch/arm/mach-exynos/Kconfig                 |   2 +
 arch/arm/mach-exynos/common.h                |  54 ++++-----
 arch/arm/mach-exynos/exynos.c                |  77 +++++-------
 arch/arm/mach-exynos/include/mach/map.h      |   2 -
 arch/arm/mach-exynos/platsmp.c               |   2 +-
 arch/arm/mach-exynos/pm.c                    |   8 +-
 arch/arm/plat-samsung/cpu.c                  |  14 ---
 arch/arm/plat-samsung/include/plat/cpu.h     |   2 -
 arch/arm/plat-samsung/include/plat/map-s5p.h |   1 -
 drivers/soc/Kconfig                          |   1 +
 drivers/soc/Makefile                         |   1 +
 drivers/soc/samsung/Kconfig                  |  14 +++
 drivers/soc/samsung/Makefile                 |   1 +
 drivers/soc/samsung/exynos-chipid.c          | 168 +++++++++++++++++++++++++++
 include/linux/soc/samsung/exynos-soc.h       |  51 ++++++++
 15 files changed, 296 insertions(+), 102 deletions(-)
 create mode 100644 drivers/soc/samsung/Kconfig
 create mode 100644 drivers/soc/samsung/Makefile
 create mode 100644 drivers/soc/samsung/exynos-chipid.c
 create mode 100644 include/linux/soc/samsung/exynos-soc.h

-- 
2.2.0

[PATCH v5 1/2] soc: samsung: add exynos chipid driver support

[Pankaj Dubey]

Exynos SoCs have Chipid, for identification of product IDs
and SoC revisions. This patch intendes to provide initialization
code for all these functionalites.

This driver usese existing binding for exnos-chipid.

CC: Grant Likely <grant.likely@linaro.org>
CC: Rob Herring <robh+dt@kernel.org>
CC: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
 drivers/soc/Kconfig                    |   1 +
 drivers/soc/Makefile                   |   1 +
 drivers/soc/samsung/Kconfig            |  14 +++
 drivers/soc/samsung/Makefile           |   1 +
 drivers/soc/samsung/exynos-chipid.c    | 168 +++++++++++++++++++++++++++++++++
 include/linux/soc/samsung/exynos-soc.h |  51 ++++++++++
 6 files changed, 236 insertions(+)
 create mode 100644 drivers/soc/samsung/Kconfig
 create mode 100644 drivers/soc/samsung/Makefile
 create mode 100644 drivers/soc/samsung/exynos-chipid.c
 create mode 100644 include/linux/soc/samsung/exynos-soc.h

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 76d6bd4..c3abfbe 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,6 +1,7 @@
 menu "SOC (System On Chip) specific Drivers"
 
 source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/samsung/Kconfig"
 source "drivers/soc/ti/Kconfig"
 source "drivers/soc/versatile/Kconfig"
 
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 063113d..620366f 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_ARCH_QCOM)		+= qcom/
+obj-$(CONFIG_SOC_SAMSUNG)	+= samsung/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 obj-$(CONFIG_SOC_TI)		+= ti/
 obj-$(CONFIG_PLAT_VERSATILE)	+= versatile/
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
new file mode 100644
index 0000000..2d83652
--- /dev/null
+++ b/drivers/soc/samsung/Kconfig
@@ -0,0 +1,14 @@
+#
+# SAMSUNG SoC drivers
+#
+menu "Samsung SOC driver support"
+
+config SOC_SAMSUNG
+	bool
+
+config EXYNOS_CHIPID
+	bool
+	depends on ARCH_EXYNOS
+	select SOC_BUS
+
+endmenu
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
new file mode 100644
index 0000000..855ca05
--- /dev/null
+++ b/drivers/soc/samsung/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_EXYNOS_CHIPID)	+= exynos-chipid.o
diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
new file mode 100644
index 0000000..8968f83
--- /dev/null
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *	      http://www.samsung.com/
+ *
+ * EXYNOS - CHIP ID support
+ * Author: Pankaj Dubey <pankaj.dubey@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/sys_soc.h>
+#include <linux/soc/samsung/exynos-soc.h>
+
+#define EXYNOS_SUBREV_MASK	(0xF << 4)
+#define EXYNOS_MAINREV_MASK	(0xF << 0)
+#define EXYNOS_REV_MASK		(EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
+
+static void __iomem *exynos_chipid_base;
+
+struct exynos_chipid_info exynos_soc_info;
+EXPORT_SYMBOL(exynos_soc_info);
+
+static const char * __init product_id_to_name(unsigned int product_id)
+{
+	const char *soc_name;
+	unsigned int soc_id = product_id & EXYNOS_SOC_MASK;
+
+	switch (soc_id) {
+	case EXYNOS3250_SOC_ID:
+		soc_name = "EXYNOS3250";
+		break;
+	case EXYNOS4210_SOC_ID:
+		soc_name = "EXYNOS4210";
+		break;
+	case EXYNOS4212_SOC_ID:
+		soc_name = "EXYNOS4212";
+		break;
+	case EXYNOS4412_SOC_ID:
+		soc_name = "EXYNOS4412";
+		break;
+	case EXYNOS4415_SOC_ID:
+		soc_name = "EXYNOS4415";
+		break;
+	case EXYNOS5250_SOC_ID:
+		soc_name = "EXYNOS5250";
+		break;
+	case EXYNOS5260_SOC_ID:
+		soc_name = "EXYNOS5260";
+		break;
+	case EXYNOS5420_SOC_ID:
+		soc_name = "EXYNOS5420";
+		break;
+	case EXYNOS5440_SOC_ID:
+		soc_name = "EXYNOS5440";
+		break;
+	case EXYNOS5800_SOC_ID:
+		soc_name = "EXYNOS5800";
+		break;
+	default:
+		soc_name = "UNKNOWN";
+	}
+	return soc_name;
+}
+
+static const struct of_device_id of_exynos_chipid_ids[] __initconst = {
+	{
+		.compatible	= "samsung,exynos4210-chipid",
+	},
+	{},
+};
+
+/**
+ *  exynos_chipid_early_init: Early chipid initialization
+ *  @dev: pointer to chipid device
+ */
+void __init exynos_chipid_early_init(struct device *dev)
+{
+	struct device_node *np;
+	const struct of_device_id *match;
+
+	if (exynos_chipid_base)
+		return;
+
+	if (!dev)
+		np = of_find_matching_node_and_match(NULL,
+			of_exynos_chipid_ids, &match);
+	else
+		np = dev->of_node;
+
+	if (!np)
+		panic("%s, failed to find chipid node\n", __func__);
+
+	exynos_chipid_base = of_iomap(np, 0);
+
+	if (!exynos_chipid_base)
+		panic("%s: failed to map registers\n", __func__);
+
+	exynos_soc_info.product_id  = __raw_readl(exynos_chipid_base);
+	exynos_soc_info.revision = exynos_soc_info.product_id & EXYNOS_REV_MASK;
+}
+
+static int __init exynos_chipid_probe(struct platform_device *pdev)
+{
+	struct soc_device_attribute *soc_dev_attr;
+	struct soc_device *soc_dev;
+	struct device_node *root;
+	int ret;
+
+	exynos_chipid_early_init(&pdev->dev);
+
+	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+	if (!soc_dev_attr)
+		return -ENODEV;
+
+	soc_dev_attr->family = "Samsung Exynos";
+
+	root = of_find_node_by_path("/");
+	ret = of_property_read_string(root, "model", &soc_dev_attr->machine);
+	of_node_put(root);
+	if (ret)
+		goto free_soc;
+
+	soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%d",
+					exynos_soc_info.revision);
+	if (!soc_dev_attr->revision)
+		goto free_soc;
+
+	soc_dev_attr->soc_id = product_id_to_name(exynos_soc_info.product_id);
+
+	soc_dev = soc_device_register(soc_dev_attr);
+	if (IS_ERR(soc_dev))
+		goto free_rev;
+
+	soc_device_to_device(soc_dev);
+
+	dev_info(&pdev->dev, "Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
+			product_id_to_name(exynos_soc_info.product_id),
+			exynos_soc_info.revision);
+	return 0;
+free_rev:
+	kfree(soc_dev_attr->revision);
+free_soc:
+	kfree(soc_dev_attr);
+	return -EINVAL;
+}
+
+static struct platform_driver exynos_chipid_driver __initdata = {
+	.driver = {
+		.name = "exynos-chipid",
+		.of_match_table = of_exynos_chipid_ids,
+	},
+	.probe = exynos_chipid_probe,
+};
+
+static int __init exynos_chipid_init(void)
+{
+	return platform_driver_register(&exynos_chipid_driver);
+}
+core_initcall(exynos_chipid_init);
+
diff --git a/include/linux/soc/samsung/exynos-soc.h b/include/linux/soc/samsung/exynos-soc.h
new file mode 100644
index 0000000..d2d9f05
--- /dev/null
+++ b/include/linux/soc/samsung/exynos-soc.h
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *
+ * Header for EXYNOS SoC Chipid support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __EXYNOS_SOC_H
+#define __EXYNOS_SOC_H
+
+#define EXYNOS3250_SOC_ID	0xE3472000
+#define EXYNOS4210_SOC_ID	0x43210000
+#define EXYNOS4212_SOC_ID	0x43220000
+#define EXYNOS4412_SOC_ID	0xE4412000
+#define EXYNOS4415_SOC_ID	0xE4415000
+#define EXYNOS5250_SOC_ID	0x43520000
+#define EXYNOS5260_SOC_ID	0xE5260000
+#define EXYNOS5410_SOC_ID	0xE5410000
+#define EXYNOS5420_SOC_ID	0xE5420000
+#define EXYNOS5440_SOC_ID	0xE5440000
+#define EXYNOS5800_SOC_ID	0xE5422000
+
+#define EXYNOS_SOC_MASK		0xFFFFF000
+
+#define EXYNOS4210_REV_0	0x0
+#define EXYNOS4210_REV_1_0	0x10
+#define EXYNOS4210_REV_1_1	0x11
+
+/**
+ * Struct exynos_chipid_info
+ * @soc_product_id: product id allocated to exynos SoC
+ * @soc_revision: revision of exynos SoC
+ */
+
+struct exynos_chipid_info {
+	u32 product_id;
+	u32 revision;
+};
+
+extern struct exynos_chipid_info exynos_soc_info;
+
+/* Since we need chipid to be initialized as early as possible
+ * during secondary core bootup adding early initialization function
+ */
+extern void exynos_chipid_early_init(struct device *dev);
+
+#endif /* __EXYNOS_SOC_H */
-- 
2.2.0

[PATCH v5 2/2] ARM: EXYNOS: refactoring of mach-exynos to enable chipid driver

[Pankaj Dubey]

This patch enables chipid driver for ARCH_EXYNOS and refactors
machine code for using chipid driver for identification of
SoC ID and SoC rev.

Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
 arch/arm/mach-exynos/Kconfig                 |  2 +
 arch/arm/mach-exynos/common.h                | 54 ++++++++-----------
 arch/arm/mach-exynos/exynos.c                | 77 +++++++++++-----------------
 arch/arm/mach-exynos/include/mach/map.h      |  2 -
 arch/arm/mach-exynos/platsmp.c               |  2 +-
 arch/arm/mach-exynos/pm.c                    |  8 +--
 arch/arm/plat-samsung/cpu.c                  | 14 -----
 arch/arm/plat-samsung/include/plat/cpu.h     |  2 -
 arch/arm/plat-samsung/include/plat/map-s5p.h |  1 -
 9 files changed, 60 insertions(+), 102 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index b9e3f1c..dd656a4 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -25,6 +25,8 @@ menuconfig ARCH_EXYNOS
 	select S5P_DEV_MFC
 	select SRAM
 	select MFD_SYSCON
+	select SOC_SAMSUNG
+	select EXYNOS_CHIPID
 	help
 	  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
 
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 865f878..107b2c8 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -13,39 +13,26 @@
 #define __ARCH_ARM_MACH_EXYNOS_COMMON_H
 
 #include <linux/of.h>
+#include <linux/soc/samsung/exynos-soc.h>
 
-#define EXYNOS3250_SOC_ID	0xE3472000
-#define EXYNOS3_SOC_MASK	0xFFFFF000
-
-#define EXYNOS4210_CPU_ID	0x43210000
-#define EXYNOS4212_CPU_ID	0x43220000
-#define EXYNOS4412_CPU_ID	0xE4412200
-#define EXYNOS4_CPU_MASK	0xFFFE0000
-
-#define EXYNOS5250_SOC_ID	0x43520000
-#define EXYNOS5410_SOC_ID	0xE5410000
-#define EXYNOS5420_SOC_ID	0xE5420000
-#define EXYNOS5440_SOC_ID	0xE5440000
-#define EXYNOS5800_SOC_ID	0xE5422000
-#define EXYNOS5_SOC_MASK	0xFFFFF000
-
-extern unsigned long samsung_cpu_id;
+static inline u32 exynos_product_id(void);
 
 #define IS_SAMSUNG_CPU(name, id, mask)		\
 static inline int is_samsung_##name(void)	\
 {						\
-	return ((samsung_cpu_id & mask) == (id & mask));	\
+	u32 product_id = exynos_product_id();	\
+	return ((product_id & mask) == (id));	\
 }
 
-IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
-IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
-IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
-IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
-IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)
-IS_SAMSUNG_CPU(exynos5410, EXYNOS5410_SOC_ID, EXYNOS5_SOC_MASK)
-IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK)
-IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
-IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK)
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS_SOC_MASK)
+IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_SOC_ID, EXYNOS_SOC_MASK)
+IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_SOC_ID, EXYNOS_SOC_MASK)
+IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_SOC_ID, EXYNOS_SOC_MASK)
+IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS_SOC_MASK)
+IS_SAMSUNG_CPU(exynos5410, EXYNOS5410_SOC_ID, EXYNOS_SOC_MASK)
+IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS_SOC_MASK)
+IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS_SOC_MASK)
+IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS_SOC_MASK)
 
 #if defined(CONFIG_SOC_EXYNOS3250)
 # define soc_is_exynos3250()	is_samsung_exynos3250()
@@ -71,10 +58,6 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK)
 # define soc_is_exynos4412()	0
 #endif
 
-#define EXYNOS4210_REV_0	(0x0)
-#define EXYNOS4210_REV_1_0	(0x10)
-#define EXYNOS4210_REV_1_1	(0x11)
-
 #if defined(CONFIG_SOC_EXYNOS5250)
 # define soc_is_exynos5250()	is_samsung_exynos5250()
 #else
@@ -150,8 +133,15 @@ extern void exynos_pm_central_suspend(void);
 extern int exynos_pm_central_resume(void);
 extern void exynos_enter_aftr(void);
 
-extern void s5p_init_cpu(void __iomem *cpuid_addr);
-extern unsigned int samsung_rev(void);
+static inline u32 exynos_product_id(void)
+{
+	return exynos_soc_info.product_id;
+}
+
+static inline u32 exynos_revision(void)
+{
+	return exynos_soc_info.revision;
+}
 
 static inline void pmu_raw_writel(u32 val, u32 offset)
 {
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index c13d083..e2a640b 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -126,53 +126,16 @@ static void __init exynos_init_late(void)
 	exynos_pm_init();
 }
 
-static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
-					int depth, void *data)
+static void __init exynos4_init_io(void)
 {
-	struct map_desc iodesc;
-	const __be32 *reg;
-	int len;
-
-	if (!of_flat_dt_is_compatible(node, "samsung,exynos4210-chipid") &&
-		!of_flat_dt_is_compatible(node, "samsung,exynos5440-clock"))
-		return 0;
-
-	reg = of_get_flat_dt_prop(node, "reg", &len);
-	if (reg == NULL || len != (sizeof(unsigned long) * 2))
-		return 0;
-
-	iodesc.pfn = __phys_to_pfn(be32_to_cpu(reg[0]));
-	iodesc.length = be32_to_cpu(reg[1]) - 1;
-	iodesc.virtual = (unsigned long)S5P_VA_CHIPID;
-	iodesc.type = MT_DEVICE;
-	iotable_init(&iodesc, 1);
-	return 1;
-}
-
-/*
- * exynos_map_io
- *
- * register the standard cpu IO areas
- */
-static void __init exynos_map_io(void)
-{
-	if (soc_is_exynos4())
-		iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
-
-	if (soc_is_exynos5())
-		iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
+	debug_ll_io_init();
+	iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
 }
 
-static void __init exynos_init_io(void)
+static void __init exynos5_init_io(void)
 {
 	debug_ll_io_init();
-
-	of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
-
-	/* detect cpu id and rev. */
-	s5p_init_cpu(S5P_VA_CHIPID);
-
-	exynos_map_io();
+	iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
 }
 
 static const struct of_device_id exynos_dt_pmu_match[] = {
@@ -209,6 +172,8 @@ static void __init exynos_init_irq(void)
 	 * init_irq
 	 */
 	exynos_map_pmu();
+
+	exynos_chipid_early_init(NULL);
 }
 
 static void __init exynos_dt_machine_init(void)
@@ -258,7 +223,7 @@ static void __init exynos_dt_machine_init(void)
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-static char const *exynos_dt_compat[] __initconst = {
+static char const *exynos4_dt_compat[] __initconst = {
 	"samsung,exynos3",
 	"samsung,exynos3250",
 	"samsung,exynos4",
@@ -266,6 +231,10 @@ static char const *exynos_dt_compat[] __initconst = {
 	"samsung,exynos4212",
 	"samsung,exynos4412",
 	"samsung,exynos4415",
+	NULL
+};
+
+static char const *exynos5_dt_compat[] __initconst = {
 	"samsung,exynos5",
 	"samsung,exynos5250",
 	"samsung,exynos5260",
@@ -299,18 +268,34 @@ static void __init exynos_dt_fixup(void)
 	of_fdt_limit_memory(8);
 }
 
-DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
+DT_MACHINE_START(EXYNOS4_DT, "SAMSUNG EXYNOS4 (Flattened Device Tree)")
+	/* Maintainer: Thomas Abraham <thomas.abraham@linaro.org> */
+	/* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
+	.l2c_aux_val	= 0x3c400001,
+	.l2c_aux_mask	= 0xc20fffff,
+	.smp		= smp_ops(exynos_smp_ops),
+	.map_io		= exynos4_init_io,
+	.init_early	= exynos_firmware_init,
+	.init_irq	= exynos_init_irq,
+	.init_machine	= exynos_dt_machine_init,
+	.init_late	= exynos_init_late,
+	.dt_compat	= exynos4_dt_compat,
+	.reserve	= exynos_reserve,
+	.dt_fixup	= exynos_dt_fixup,
+MACHINE_END
+
+DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)")
 	/* Maintainer: Thomas Abraham <thomas.abraham@linaro.org> */
 	/* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
 	.l2c_aux_val	= 0x3c400001,
 	.l2c_aux_mask	= 0xc20fffff,
 	.smp		= smp_ops(exynos_smp_ops),
-	.map_io		= exynos_init_io,
+	.map_io		= exynos5_init_io,
 	.init_early	= exynos_firmware_init,
 	.init_irq	= exynos_init_irq,
 	.init_machine	= exynos_dt_machine_init,
 	.init_late	= exynos_init_late,
-	.dt_compat	= exynos_dt_compat,
+	.dt_compat	= exynos5_dt_compat,
 	.reserve	= exynos_reserve,
 	.dt_fixup	= exynos_dt_fixup,
 MACHINE_END
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 1ad3f49..2e1c115 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -22,8 +22,6 @@
 
 #include <plat/map-s5p.h>
 
-#define EXYNOS_PA_CHIPID		0x10000000
-
 #define EXYNOS4_PA_SYSCON		0x10010000
 #define EXYNOS5_PA_SYSCON		0x10050100
 
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 7a1ebfe..5c318c3 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -196,7 +196,7 @@ int exynos_cluster_power_state(int cluster)
 
 static inline void __iomem *cpu_boot_reg_base(void)
 {
-	if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_1_1)
+	if (soc_is_exynos4210() && exynos_revision() == EXYNOS4210_REV_1_1)
 		return pmu_base_addr + S5P_INFORM5;
 	return sysram_base_addr;
 }
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 86f3ecd..d694190 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -32,18 +32,18 @@
 
 static inline void __iomem *exynos_boot_vector_addr(void)
 {
-	if (samsung_rev() == EXYNOS4210_REV_1_1)
+	if (exynos_revision() == EXYNOS4210_REV_1_1)
 		return pmu_base_addr + S5P_INFORM7;
-	else if (samsung_rev() == EXYNOS4210_REV_1_0)
+	else if (exynos_revision() == EXYNOS4210_REV_1_0)
 		return sysram_base_addr + 0x24;
 	return pmu_base_addr + S5P_INFORM0;
 }
 
 static inline void __iomem *exynos_boot_vector_flag(void)
 {
-	if (samsung_rev() == EXYNOS4210_REV_1_1)
+	if (exynos_revision() == EXYNOS4210_REV_1_1)
 		return pmu_base_addr + S5P_INFORM6;
-	else if (samsung_rev() == EXYNOS4210_REV_1_0)
+	else if (exynos_revision() == EXYNOS4210_REV_1_0)
 		return sysram_base_addr + 0x20;
 	return pmu_base_addr + S5P_INFORM1;
 }
diff --git a/arch/arm/plat-samsung/cpu.c b/arch/arm/plat-samsung/cpu.c
index 71333bb..02d95fd 100644
--- a/arch/arm/plat-samsung/cpu.c
+++ b/arch/arm/plat-samsung/cpu.c
@@ -21,12 +21,6 @@
 unsigned long samsung_cpu_id;
 static unsigned int samsung_cpu_rev;
 
-unsigned int samsung_rev(void)
-{
-	return samsung_cpu_rev;
-}
-EXPORT_SYMBOL(samsung_rev);
-
 void __init s3c64xx_init_cpu(void)
 {
 	samsung_cpu_id = __raw_readl(S3C_VA_SYS + 0x118);
@@ -43,11 +37,3 @@ void __init s3c64xx_init_cpu(void)
 
 	pr_info("Samsung CPU ID: 0x%08lx\n", samsung_cpu_id);
 }
-
-void __init s5p_init_cpu(void __iomem *cpuid_addr)
-{
-	samsung_cpu_id = __raw_readl(cpuid_addr);
-	samsung_cpu_rev = samsung_cpu_id & 0xFF;
-
-	pr_info("Samsung CPU ID: 0x%08lx\n", samsung_cpu_id);
-}
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h b/arch/arm/plat-samsung/include/plat/cpu.h
index 61d14f3..fa7d0d6 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -114,8 +114,6 @@ extern void s3c24xx_init_io(struct map_desc *mach_desc, int size);
 
 extern void s3c64xx_init_cpu(void);
 
-extern unsigned int samsung_rev(void);
-
 extern void s3c24xx_init_uarts(struct s3c2410_uartcfg *cfg, int no);
 
 extern void s3c24xx_init_clocks(int xtal);
diff --git a/arch/arm/plat-samsung/include/plat/map-s5p.h b/arch/arm/plat-samsung/include/plat/map-s5p.h
index f5cf2bd..3df015c 100644
--- a/arch/arm/plat-samsung/include/plat/map-s5p.h
+++ b/arch/arm/plat-samsung/include/plat/map-s5p.h
@@ -13,7 +13,6 @@
 #ifndef __ASM_PLAT_MAP_S5P_H
 #define __ASM_PLAT_MAP_S5P_H __FILE__
 
-#define S5P_VA_CHIPID		S3C_ADDR(0x02000000)
 #define S5P_VA_CMU		S3C_ADDR(0x02100000)
 
 #define S5P_VA_DMC0		S3C_ADDR(0x02440000)
-- 
2.2.0

Re: [PATCH v5 1/2] soc: samsung: add exynos chipid driver support

[Rob Herring]

On Thu, Dec 11, 2014 at 2:07 AM, Pankaj Dubey <pankaj.dubey@samsung.com> wrote:
> Exynos SoCs have Chipid, for identification of product IDs
> and SoC revisions. This patch intendes to provide initialization
> code for all these functionalites.
>
> This driver usese existing binding for exnos-chipid.

s/usese/uses/
s/exnos/exynos/

>
> CC: Grant Likely <grant.likely@linaro.org>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
>  drivers/soc/Kconfig                    |   1 +
>  drivers/soc/Makefile                   |   1 +
>  drivers/soc/samsung/Kconfig            |  14 +++
>  drivers/soc/samsung/Makefile           |   1 +
>  drivers/soc/samsung/exynos-chipid.c    | 168 +++++++++++++++++++++++++++++++++
>  include/linux/soc/samsung/exynos-soc.h |  51 ++++++++++
>  6 files changed, 236 insertions(+)
>  create mode 100644 drivers/soc/samsung/Kconfig
>  create mode 100644 drivers/soc/samsung/Makefile
>  create mode 100644 drivers/soc/samsung/exynos-chipid.c
>  create mode 100644 include/linux/soc/samsung/exynos-soc.h
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 76d6bd4..c3abfbe 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -1,6 +1,7 @@
>  menu "SOC (System On Chip) specific Drivers"
>
>  source "drivers/soc/qcom/Kconfig"
> +source "drivers/soc/samsung/Kconfig"
>  source "drivers/soc/ti/Kconfig"
>  source "drivers/soc/versatile/Kconfig"
>
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 063113d..620366f 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -3,6 +3,7 @@
>  #
>
>  obj-$(CONFIG_ARCH_QCOM)                += qcom/
> +obj-$(CONFIG_SOC_SAMSUNG)      += samsung/
>  obj-$(CONFIG_ARCH_TEGRA)       += tegra/
>  obj-$(CONFIG_SOC_TI)           += ti/
>  obj-$(CONFIG_PLAT_VERSATILE)   += versatile/
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> new file mode 100644
> index 0000000..2d83652
> --- /dev/null
> +++ b/drivers/soc/samsung/Kconfig
> @@ -0,0 +1,14 @@
> +#
> +# SAMSUNG SoC drivers
> +#
> +menu "Samsung SOC driver support"
> +
> +config SOC_SAMSUNG
> +       bool
> +
> +config EXYNOS_CHIPID
> +       bool
> +       depends on ARCH_EXYNOS
> +       select SOC_BUS

This is going to show an empty menu when ARCH_EXYNOS is not enabled.
The whole menu should probably have "if ARCH_EXYNOS" instead.

> +
> +endmenu
> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> new file mode 100644
> index 0000000..855ca05
> --- /dev/null
> +++ b/drivers/soc/samsung/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_EXYNOS_CHIPID)    += exynos-chipid.o
> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> new file mode 100644
> index 0000000..8968f83
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-chipid.c
> @@ -0,0 +1,168 @@
> +/*
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + *           http://www.samsung.com/
> + *
> + * EXYNOS - CHIP ID support
> + * Author: Pankaj Dubey <pankaj.dubey@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/sys_soc.h>
> +#include <linux/soc/samsung/exynos-soc.h>
> +
> +#define EXYNOS_SUBREV_MASK     (0xF << 4)
> +#define EXYNOS_MAINREV_MASK    (0xF << 0)
> +#define EXYNOS_REV_MASK                (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
> +
> +static void __iomem *exynos_chipid_base;
> +
> +struct exynos_chipid_info exynos_soc_info;
> +EXPORT_SYMBOL(exynos_soc_info);

The soc_device already has similar data. Why is this needed? Is it
temporary for compatibility? For early use? If for early use, then it
should not be exported.


> +
> +static const char * __init product_id_to_name(unsigned int product_id)
> +{
> +       const char *soc_name;
> +       unsigned int soc_id = product_id & EXYNOS_SOC_MASK;
> +
> +       switch (soc_id) {
> +       case EXYNOS3250_SOC_ID:
> +               soc_name = "EXYNOS3250";
> +               break;
> +       case EXYNOS4210_SOC_ID:
> +               soc_name = "EXYNOS4210";
> +               break;
> +       case EXYNOS4212_SOC_ID:
> +               soc_name = "EXYNOS4212";
> +               break;
> +       case EXYNOS4412_SOC_ID:
> +               soc_name = "EXYNOS4412";
> +               break;
> +       case EXYNOS4415_SOC_ID:
> +               soc_name = "EXYNOS4415";
> +               break;
> +       case EXYNOS5250_SOC_ID:
> +               soc_name = "EXYNOS5250";
> +               break;
> +       case EXYNOS5260_SOC_ID:
> +               soc_name = "EXYNOS5260";
> +               break;
> +       case EXYNOS5420_SOC_ID:
> +               soc_name = "EXYNOS5420";
> +               break;
> +       case EXYNOS5440_SOC_ID:
> +               soc_name = "EXYNOS5440";
> +               break;
> +       case EXYNOS5800_SOC_ID:
> +               soc_name = "EXYNOS5800";
> +               break;
> +       default:
> +               soc_name = "UNKNOWN";
> +       }
> +       return soc_name;
> +}
> +
> +static const struct of_device_id of_exynos_chipid_ids[] __initconst = {
> +       {
> +               .compatible     = "samsung,exynos4210-chipid",
> +       },
> +       {},
> +};
> +
> +/**
> + *  exynos_chipid_early_init: Early chipid initialization
> + *  @dev: pointer to chipid device
> + */
> +void __init exynos_chipid_early_init(struct device *dev)
> +{
> +       struct device_node *np;
> +       const struct of_device_id *match;
> +
> +       if (exynos_chipid_base)
> +               return;
> +
> +       if (!dev)
> +               np = of_find_matching_node_and_match(NULL,
> +                       of_exynos_chipid_ids, &match);
> +       else
> +               np = dev->of_node;
> +
> +       if (!np)
> +               panic("%s, failed to find chipid node\n", __func__);

Do you really want to halt booting here? Your console may not be up to
see the panic anyway.

> +
> +       exynos_chipid_base = of_iomap(np, 0);

Once you read the rev and product_id, do you need to keep the mapping?

> +
> +       if (!exynos_chipid_base)
> +               panic("%s: failed to map registers\n", __func__);
> +
> +       exynos_soc_info.product_id  = __raw_readl(exynos_chipid_base);
> +       exynos_soc_info.revision = exynos_soc_info.product_id & EXYNOS_REV_MASK;
> +}
> +
> +static int __init exynos_chipid_probe(struct platform_device *pdev)
> +{
> +       struct soc_device_attribute *soc_dev_attr;
> +       struct soc_device *soc_dev;
> +       struct device_node *root;
> +       int ret;
> +
> +       exynos_chipid_early_init(&pdev->dev);
> +
> +       soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> +       if (!soc_dev_attr)
> +               return -ENODEV;
> +
> +       soc_dev_attr->family = "Samsung Exynos";
> +
> +       root = of_find_node_by_path("/");
> +       ret = of_property_read_string(root, "model", &soc_dev_attr->machine);
> +       of_node_put(root);
> +       if (ret)
> +               goto free_soc;

Should a lack of model really be a reason to not load the soc_device?

> +
> +       soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%d",
> +                                       exynos_soc_info.revision);
> +       if (!soc_dev_attr->revision)
> +               goto free_soc;
> +
> +       soc_dev_attr->soc_id = product_id_to_name(exynos_soc_info.product_id);
> +
> +       soc_dev = soc_device_register(soc_dev_attr);
> +       if (IS_ERR(soc_dev))
> +               goto free_rev;
> +
> +       soc_device_to_device(soc_dev);
> +
> +       dev_info(&pdev->dev, "Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
> +                       product_id_to_name(exynos_soc_info.product_id),
> +                       exynos_soc_info.revision);
> +       return 0;
> +free_rev:
> +       kfree(soc_dev_attr->revision);
> +free_soc:
> +       kfree(soc_dev_attr);
> +       return -EINVAL;
> +}
> +
> +static struct platform_driver exynos_chipid_driver __initdata = {
> +       .driver = {
> +               .name = "exynos-chipid",
> +               .of_match_table = of_exynos_chipid_ids,
> +       },
> +       .probe = exynos_chipid_probe,
> +};
> +
> +static int __init exynos_chipid_init(void)
> +{
> +       return platform_driver_register(&exynos_chipid_driver);
> +}
> +core_initcall(exynos_chipid_init);
> +
> diff --git a/include/linux/soc/samsung/exynos-soc.h b/include/linux/soc/samsung/exynos-soc.h
> new file mode 100644
> index 0000000..d2d9f05
> --- /dev/null
> +++ b/include/linux/soc/samsung/exynos-soc.h
> @@ -0,0 +1,51 @@
> +/*
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + *             http://www.samsung.com
> + *
> + * Header for EXYNOS SoC Chipid support
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __EXYNOS_SOC_H
> +#define __EXYNOS_SOC_H
> +
> +#define EXYNOS3250_SOC_ID      0xE3472000
> +#define EXYNOS4210_SOC_ID      0x43210000
> +#define EXYNOS4212_SOC_ID      0x43220000
> +#define EXYNOS4412_SOC_ID      0xE4412000
> +#define EXYNOS4415_SOC_ID      0xE4415000
> +#define EXYNOS5250_SOC_ID      0x43520000
> +#define EXYNOS5260_SOC_ID      0xE5260000
> +#define EXYNOS5410_SOC_ID      0xE5410000
> +#define EXYNOS5420_SOC_ID      0xE5420000
> +#define EXYNOS5440_SOC_ID      0xE5440000
> +#define EXYNOS5800_SOC_ID      0xE5422000
> +
> +#define EXYNOS_SOC_MASK                0xFFFFF000
> +
> +#define EXYNOS4210_REV_0       0x0
> +#define EXYNOS4210_REV_1_0     0x10
> +#define EXYNOS4210_REV_1_1     0x11
> +
> +/**
> + * Struct exynos_chipid_info
> + * @soc_product_id: product id allocated to exynos SoC
> + * @soc_revision: revision of exynos SoC
> + */
> +
> +struct exynos_chipid_info {
> +       u32 product_id;
> +       u32 revision;
> +};

Exposing this struct kernel wide in an SOC specific way concerns me. I
would not like to see this done on every SOC family. That would become
a mess.

Rob

Re: [PATCH v5 1/2] soc: samsung: add exynos chipid driver support

[Pankaj Dubey]

Hi Rob,

On Thursday 11 December 2014 11:00 PM, Rob Herring wrote:
> On Thu, Dec 11, 2014 at 2:07 AM, Pankaj Dubey <pankaj.dubey@samsung.com> wrote:
>> Exynos SoCs have Chipid, for identification of product IDs
>> and SoC revisions. This patch intendes to provide initialization
>> code for all these functionalites.
>>
>> This driver usese existing binding for exnos-chipid.
>
> s/usese/uses/
> s/exnos/exynos/
>

I'll fix this.

>>
>> CC: Grant Likely <grant.likely@linaro.org>
>> CC: Rob Herring <robh+dt@kernel.org>
>> CC: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>>   drivers/soc/Kconfig                    |   1 +
>>   drivers/soc/Makefile                   |   1 +
>>   drivers/soc/samsung/Kconfig            |  14 +++
>>   drivers/soc/samsung/Makefile           |   1 +
>>   drivers/soc/samsung/exynos-chipid.c    | 168 +++++++++++++++++++++++++++++++++
>>   include/linux/soc/samsung/exynos-soc.h |  51 ++++++++++
>>   6 files changed, 236 insertions(+)
>>   create mode 100644 drivers/soc/samsung/Kconfig
>>   create mode 100644 drivers/soc/samsung/Makefile
>>   create mode 100644 drivers/soc/samsung/exynos-chipid.c
>>   create mode 100644 include/linux/soc/samsung/exynos-soc.h
>>
>> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
>> index 76d6bd4..c3abfbe 100644
>> --- a/drivers/soc/Kconfig
>> +++ b/drivers/soc/Kconfig
>> @@ -1,6 +1,7 @@
>>   menu "SOC (System On Chip) specific Drivers"
>>
>>   source "drivers/soc/qcom/Kconfig"
>> +source "drivers/soc/samsung/Kconfig"
>>   source "drivers/soc/ti/Kconfig"
>>   source "drivers/soc/versatile/Kconfig"
>>
>> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
>> index 063113d..620366f 100644
>> --- a/drivers/soc/Makefile
>> +++ b/drivers/soc/Makefile
>> @@ -3,6 +3,7 @@
>>   #
>>
>>   obj-$(CONFIG_ARCH_QCOM)                += qcom/
>> +obj-$(CONFIG_SOC_SAMSUNG)      += samsung/
>>   obj-$(CONFIG_ARCH_TEGRA)       += tegra/
>>   obj-$(CONFIG_SOC_TI)           += ti/
>>   obj-$(CONFIG_PLAT_VERSATILE)   += versatile/
>> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
>> new file mode 100644
>> index 0000000..2d83652
>> --- /dev/null
>> +++ b/drivers/soc/samsung/Kconfig
>> @@ -0,0 +1,14 @@
>> +#
>> +# SAMSUNG SoC drivers
>> +#
>> +menu "Samsung SOC driver support"
>> +
>> +config SOC_SAMSUNG
>> +       bool
>> +
>> +config EXYNOS_CHIPID
>> +       bool
>> +       depends on ARCH_EXYNOS
>> +       select SOC_BUS
>
> This is going to show an empty menu when ARCH_EXYNOS is not enabled.
> The whole menu should probably have "if ARCH_EXYNOS" instead.
>

OK, I can add 'depends on ARCH_EXYNOS' for menu above so that it should 
not show empty menu option if ARCH_EXNOS is not enabled.

>> +
>> +endmenu
>> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
>> new file mode 100644
>> index 0000000..855ca05
>> --- /dev/null
>> +++ b/drivers/soc/samsung/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_EXYNOS_CHIPID)    += exynos-chipid.o
>> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
>> new file mode 100644
>> index 0000000..8968f83
>> --- /dev/null
>> +++ b/drivers/soc/samsung/exynos-chipid.c
>> @@ -0,0 +1,168 @@
>> +/*
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + *           http://www.samsung.com/
>> + *
>> + * EXYNOS - CHIP ID support
>> + * Author: Pankaj Dubey <pankaj.dubey@samsung.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include <linux/io.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/sys_soc.h>
>> +#include <linux/soc/samsung/exynos-soc.h>
>> +
>> +#define EXYNOS_SUBREV_MASK     (0xF << 4)
>> +#define EXYNOS_MAINREV_MASK    (0xF << 0)
>> +#define EXYNOS_REV_MASK                (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
>> +
>> +static void __iomem *exynos_chipid_base;
>> +
>> +struct exynos_chipid_info exynos_soc_info;
>> +EXPORT_SYMBOL(exynos_soc_info);
>
> The soc_device already has similar data.Why is this needed? Is it
> temporary for compatibility?

struct soc_device_attribute can hold these two (product_id, and 
revision) but they are defined as char * in soc_device_atttribute, and I 
feel it's more specific for exposing via sysfs.
Also existing code in mach-exynos compares them via product_id/revision 
macros, so I can say to keep compatibility.

> For early use?

Yes, partially correct. These parameters will be required in during 
early boot, from mach-exynos/platsmp.c, by that time probe of chipid 
would not have happened. But usage of this is not limited to early 
users, even mach-exynos/pm.c will use this later any point of time.
Since there are early users I added "exynos_chipid_early_init" which 
will be called via mach-exynos.c at very early stage [1].

[1]: https://lkml.org/lkml/2014/12/11/47


> If for early use, then it
> should not be exported.

Other reason to make and expose this structure was we can see that other 
fields of chipid bank (other than product_id and revision, which is not 
part of this patch as of now) can be used by other driver such as ASV 
(which is not yet part of mainline but is there for every exynos SoC).

I do not exported this in my PATCH v4 [2] of this, and instead provided 
exposed functions to directly access product_id and revision, but 
sometime in future when we will need other fields of chipid bank, we 
will end-up adding new exported function for each new field, so decided 
to expose this structure itself.

[2]: http://www.spinics.net/lists/linux-samsung-soc/msg39913.html

>
>
>> +
>> +static const char * __init product_id_to_name(unsigned int product_id)
>> +{
>> +       const char *soc_name;
>> +       unsigned int soc_id = product_id & EXYNOS_SOC_MASK;
>> +
>> +       switch (soc_id) {
>> +       case EXYNOS3250_SOC_ID:
>> +               soc_name = "EXYNOS3250";
>> +               break;
>> +       case EXYNOS4210_SOC_ID:
>> +               soc_name = "EXYNOS4210";
>> +               break;
>> +       case EXYNOS4212_SOC_ID:
>> +               soc_name = "EXYNOS4212";
>> +               break;
>> +       case EXYNOS4412_SOC_ID:
>> +               soc_name = "EXYNOS4412";
>> +               break;
>> +       case EXYNOS4415_SOC_ID:
>> +               soc_name = "EXYNOS4415";
>> +               break;
>> +       case EXYNOS5250_SOC_ID:
>> +               soc_name = "EXYNOS5250";
>> +               break;
>> +       case EXYNOS5260_SOC_ID:
>> +               soc_name = "EXYNOS5260";
>> +               break;
>> +       case EXYNOS5420_SOC_ID:
>> +               soc_name = "EXYNOS5420";
>> +               break;
>> +       case EXYNOS5440_SOC_ID:
>> +               soc_name = "EXYNOS5440";
>> +               break;
>> +       case EXYNOS5800_SOC_ID:
>> +               soc_name = "EXYNOS5800";
>> +               break;
>> +       default:
>> +               soc_name = "UNKNOWN";
>> +       }
>> +       return soc_name;
>> +}
>> +
>> +static const struct of_device_id of_exynos_chipid_ids[] __initconst = {
>> +       {
>> +               .compatible     = "samsung,exynos4210-chipid",
>> +       },
>> +       {},
>> +};
>> +
>> +/**
>> + *  exynos_chipid_early_init: Early chipid initialization
>> + *  @dev: pointer to chipid device
>> + */
>> +void __init exynos_chipid_early_init(struct device *dev)
>> +{
>> +       struct device_node *np;
>> +       const struct of_device_id *match;
>> +
>> +       if (exynos_chipid_base)
>> +               return;
>> +
>> +       if (!dev)
>> +               np = of_find_matching_node_and_match(NULL,
>> +                       of_exynos_chipid_ids, &match);
>> +       else
>> +               np = dev->of_node;
>> +
>> +       if (!np)
>> +               panic("%s, failed to find chipid node\n", __func__);
>
> Do you really want to halt booting here?

Since some critical configuration are done in platsmp.c based on 
product_id and revision, I don't see any point moving ahead without it.
Even if we allow to continue here it will crash or lead to system 
malfunction later during system boot for existing SoC support.

Your console may not be up to
> see the panic anyway.

I feel this we can still see via earlyprintk.

>
>> +
>> +       exynos_chipid_base = of_iomap(np, 0);
>
> Once you read the rev and product_id, do you need to keep the mapping?
>

OK. I can unmap it, once all fields are read.

>> +
>> +       if (!exynos_chipid_base)
>> +               panic("%s: failed to map registers\n", __func__);
>> +
>> +       exynos_soc_info.product_id  = __raw_readl(exynos_chipid_base);
>> +       exynos_soc_info.revision = exynos_soc_info.product_id & EXYNOS_REV_MASK;
>> +}
>> +
>> +static int __init exynos_chipid_probe(struct platform_device *pdev)
>> +{
>> +       struct soc_device_attribute *soc_dev_attr;
>> +       struct soc_device *soc_dev;
>> +       struct device_node *root;
>> +       int ret;
>> +
>> +       exynos_chipid_early_init(&pdev->dev);
>> +
>> +       soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
>> +       if (!soc_dev_attr)
>> +               return -ENODEV;
>> +
>> +       soc_dev_attr->family = "Samsung Exynos";
>> +
>> +       root = of_find_node_by_path("/");
>> +       ret = of_property_read_string(root, "model", &soc_dev_attr->machine);
>> +       of_node_put(root);
>> +       if (ret)
>> +               goto free_soc;
>
> Should a lack of model really be a reason to not load the soc_device?

No. I can make it optional and initialize machine with some default value.

>
>> +
>> +       soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%d",
>> +                                       exynos_soc_info.revision);
>> +       if (!soc_dev_attr->revision)
>> +               goto free_soc;
>> +
>> +       soc_dev_attr->soc_id = product_id_to_name(exynos_soc_info.product_id);
>> +
>> +       soc_dev = soc_device_register(soc_dev_attr);
>> +       if (IS_ERR(soc_dev))
>> +               goto free_rev;
>> +
>> +       soc_device_to_device(soc_dev);
>> +
>> +       dev_info(&pdev->dev, "Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
>> +                       product_id_to_name(exynos_soc_info.product_id),
>> +                       exynos_soc_info.revision);
>> +       return 0;
>> +free_rev:
>> +       kfree(soc_dev_attr->revision);
>> +free_soc:
>> +       kfree(soc_dev_attr);
>> +       return -EINVAL;
>> +}
>> +
>> +static struct platform_driver exynos_chipid_driver __initdata = {
>> +       .driver = {
>> +               .name = "exynos-chipid",
>> +               .of_match_table = of_exynos_chipid_ids,
>> +       },
>> +       .probe = exynos_chipid_probe,
>> +};
>> +
>> +static int __init exynos_chipid_init(void)
>> +{
>> +       return platform_driver_register(&exynos_chipid_driver);
>> +}
>> +core_initcall(exynos_chipid_init);
>> +
>> diff --git a/include/linux/soc/samsung/exynos-soc.h b/include/linux/soc/samsung/exynos-soc.h
>> new file mode 100644
>> index 0000000..d2d9f05
>> --- /dev/null
>> +++ b/include/linux/soc/samsung/exynos-soc.h
>> @@ -0,0 +1,51 @@
>> +/*
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + *             http://www.samsung.com
>> + *
>> + * Header for EXYNOS SoC Chipid support
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef __EXYNOS_SOC_H
>> +#define __EXYNOS_SOC_H
>> +
>> +#define EXYNOS3250_SOC_ID      0xE3472000
>> +#define EXYNOS4210_SOC_ID      0x43210000
>> +#define EXYNOS4212_SOC_ID      0x43220000
>> +#define EXYNOS4412_SOC_ID      0xE4412000
>> +#define EXYNOS4415_SOC_ID      0xE4415000
>> +#define EXYNOS5250_SOC_ID      0x43520000
>> +#define EXYNOS5260_SOC_ID      0xE5260000
>> +#define EXYNOS5410_SOC_ID      0xE5410000
>> +#define EXYNOS5420_SOC_ID      0xE5420000
>> +#define EXYNOS5440_SOC_ID      0xE5440000
>> +#define EXYNOS5800_SOC_ID      0xE5422000
>> +
>> +#define EXYNOS_SOC_MASK                0xFFFFF000
>> +
>> +#define EXYNOS4210_REV_0       0x0
>> +#define EXYNOS4210_REV_1_0     0x10
>> +#define EXYNOS4210_REV_1_1     0x11
>> +
>> +/**
>> + * Struct exynos_chipid_info
>> + * @soc_product_id: product id allocated to exynos SoC
>> + * @soc_revision: revision of exynos SoC
>> + */
>> +
>> +struct exynos_chipid_info {
>> +       u32 product_id;
>> +       u32 revision;
>> +};
>
> Exposing this struct kernel wide in an SOC specific way concerns me. I
> would not like to see this done on every SOC family. That would become
> a mess.
>

As of today chip-id can live up by exposing two APIs for getting 
product_id and revision, but in future when we need to access other 
fields we may end up adding new exported functions/extern functions. We 
had a discussion about it in Patch V4 [3].

[3]: https://lkml.org/lkml/2014/12/10/748


Thanks,
Pankaj Dubey
> Rob
>

Re: [PATCH v5 1/2] soc: samsung: add exynos chipid driver support

[Arnd Bergmann]

On Friday 12 December 2014 13:15:43 Pankaj Dubey wrote:
> >> +
> >> +static void __iomem *exynos_chipid_base;
> >> +
> >> +struct exynos_chipid_info exynos_soc_info;
> >> +EXPORT_SYMBOL(exynos_soc_info);
> >
> > The soc_device already has similar data.Why is this needed? Is it
> > temporary for compatibility?
> 
> struct soc_device_attribute can hold these two (product_id, and 
> revision) but they are defined as char * in soc_device_atttribute, and I 
> feel it's more specific for exposing via sysfs.
> Also existing code in mach-exynos compares them via product_id/revision 
> macros, so I can say to keep compatibility.

We had a similar discussion about the Marvell SoCs a while ago, and at
the time we concluded that it would be best to create a platform-
independent API to match the strings in soc_device_attribute against
a list of strings in the driver, either by matching the start of the
string, or using the glob_match() function. Would that work for you?

	Arnd

Re: [PATCH v5 1/2] soc: samsung: add exynos chipid driver support

[Rob Herring]

On Fri, Dec 12, 2014 at 1:45 AM, Pankaj Dubey <pankaj.dubey@samsung.com> wrote:
> Hi Rob,
>
> On Thursday 11 December 2014 11:00 PM, Rob Herring wrote:
>>
>> On Thu, Dec 11, 2014 at 2:07 AM, Pankaj Dubey <pankaj.dubey@samsung.com>
>> wrote:
>>>
>>> Exynos SoCs have Chipid, for identification of product IDs
>>> and SoC revisions. This patch intendes to provide initialization
>>> code for all these functionalites.

[...]

>>> +static void __iomem *exynos_chipid_base;
>>> +
>>> +struct exynos_chipid_info exynos_soc_info;
>>> +EXPORT_SYMBOL(exynos_soc_info);
>>
>>
>> The soc_device already has similar data.Why is this needed? Is it
>> temporary for compatibility?
>
>
> struct soc_device_attribute can hold these two (product_id, and revision)
> but they are defined as char * in soc_device_atttribute, and I feel it's
> more specific for exposing via sysfs.

But what is exposed generically for sysfs should also be exposed
internally in the kernel generically.

> Also existing code in mach-exynos compares them via product_id/revision
> macros, so I can say to keep compatibility.

Perhaps you will have to change the users. Otherwise, I don't see the
point in moving this code as is. If there are a lot of users, then
having both old and new interface and moving them over one by one
would be okay. However, if this is widely used that is a problem in
itself.

>> For early use?
>
>
> Yes, partially correct. These parameters will be required in during early
> boot, from mach-exynos/platsmp.c, by that time probe of chipid would not
> have happened. But usage of this is not limited to early users, even
> mach-exynos/pm.c will use this later any point of time.
> Since there are early users I added "exynos_chipid_early_init" which will be
> called via mach-exynos.c at very early stage [1].
>
> [1]: https://lkml.org/lkml/2014/12/11/47
>
>
>> If for early use, then it
>> should not be exported.
>
>
> Other reason to make and expose this structure was we can see that other
> fields of chipid bank (other than product_id and revision, which is not part
> of this patch as of now) can be used by other driver such as ASV (which is
> not yet part of mainline but is there for every exynos SoC).
>
> I do not exported this in my PATCH v4 [2] of this, and instead provided
> exposed functions to directly access product_id and revision, but sometime
> in future when we will need other fields of chipid bank, we will end-up
> adding new exported function for each new field, so decided to expose this
> structure itself.

More on this below.


>>> +void __init exynos_chipid_early_init(struct device *dev)
>>> +{
>>> +       struct device_node *np;
>>> +       const struct of_device_id *match;
>>> +
>>> +       if (exynos_chipid_base)
>>> +               return;
>>> +
>>> +       if (!dev)
>>> +               np = of_find_matching_node_and_match(NULL,
>>> +                       of_exynos_chipid_ids, &match);
>>> +       else
>>> +               np = dev->of_node;
>>> +
>>> +       if (!np)
>>> +               panic("%s, failed to find chipid node\n", __func__);
>>
>>
>> Do you really want to halt booting here?
>
>
> Since some critical configuration are done in platsmp.c based on product_id
> and revision, I don't see any point moving ahead without it.
> Even if we allow to continue here it will crash or lead to system
> malfunction later during system boot for existing SoC support.
>
> Your console may not be up to
>>
>> see the panic anyway.
>
>
> I feel this we can still see via earlyprintk.

You can, yes. So when you don't boot getting no messages, you then
have to recompile to enable earlyprintk for exynos, load a new kernel,
and change your command line. That's not very good from a support
point of view. It would be better to boot while failing to boot
secondary cpus than not boot printing nothing. It is much better to
provide the warnings rather than have to debug why you are not
booting.

>>> +struct exynos_chipid_info {
>>> +       u32 product_id;
>>> +       u32 revision;
>>> +};
>>
>>
>> Exposing this struct kernel wide in an SOC specific way concerns me. I
>> would not like to see this done on every SOC family. That would become
>> a mess.
>>
>
> As of today chip-id can live up by exposing two APIs for getting product_id
> and revision, but in future when we need to access other fields we may end
> up adding new exported functions/extern functions. We had a discussion about
> it in Patch V4 [3].

Yes, but every SOC has an id and revision, so we should expose them in
a common way. For other fields, the mechanism to retrieve them should
probably be common, but the data could be custom.

Rob

>
> [3]: https://lkml.org/lkml/2014/12/10/748

Re: [PATCH v5 1/2] soc: samsung: add exynos chipid driver support

[Pankaj Dubey]

Hi Arnd,

Sorry for late reply.

On Friday 12 December 2014 05:01 PM, Arnd Bergmann wrote:
> On Friday 12 December 2014 13:15:43 Pankaj Dubey wrote:
>>>> +
>>>> +static void __iomem *exynos_chipid_base;
>>>> +
>>>> +struct exynos_chipid_info exynos_soc_info;
>>>> +EXPORT_SYMBOL(exynos_soc_info);
>>>
>>> The soc_device already has similar data.Why is this needed? Is it
>>> temporary for compatibility?
>>
>> struct soc_device_attribute can hold these two (product_id, and
>> revision) but they are defined as char * in soc_device_atttribute, and I
>> feel it's more specific for exposing via sysfs.
>> Also existing code in mach-exynos compares them via product_id/revision
>> macros, so I can say to keep compatibility.
>
> We had a similar discussion about the Marvell SoCs a while ago, and at
> the time we concluded that it would be best to create a platform-
> independent API to match the strings in soc_device_attribute against
> a list of strings in the driver, either by matching the start of the
> string, or using the glob_match() function. Would that work for you?
>

It might be useful, will you please point me to that discussion so that 
I can dig more and see how I can reuse it, or if required work on it.

Thanks,
Pankaj Dubey
> 	Arnd
>

Re: [PATCH v5 0/2] Introducing Exynos ChipId driver

[Krzysztof Kozlowski]

On Thu, Dec 11, 2014 at 9:07 AM, Pankaj Dubey <pankaj.dubey@samsung.com> wrote:
> This patch series introduces Exynos Chipid platform driver.
> Each Exynos SoC has ChipID block which can give information about SoC's
> product Id and revision number.
> At the same time it reduces dependency of mach-exynos files from plat-samsung,
> by removing samsung_rev API, similar API is introduced in chipid driver itself
> to get revision number and product id.
>
> This patch series is based on Kukjin Kim's for-next having SHA_ID:
> 9db7d78aca2c7fbc19a26ce2ef01c805dc010c72
>
> It can also be cleanly applied on latest (next-20141209) linux-next.
>
> This has been tested against both tree on Exynos3250 and Exynos5250 (SMDK) board.
>
> Revision 4 and it's discussion can be found here
>  - https://lkml.org/lkml/2014/12/3/115
>
> Changes since v4:
>  - Removed custom sysfs entries as they were not providing any new information
>    as pointed out by Arnd.
>  - Removed functions exporting product_id and revision, instead we will export
>    exynos_chipid_info structure. It will be helpfull when we need to provide more
>    fields of chipid outside of chipid, as commented by Yadwinder
>  - Converted all funcions as __init.
>
> Change since v3:
>  - This patch set contains 5/6 and 6/6 patch from v3 series.
>  - Made EXYNOS_CHIPID config option non-user selectable,
>    as suggested by Tomasz Figa.
>  - Made uniform macro for EXYNOS4/5_SOC_MASK as EXYNOS_SOC_MASK as
>    suggested by Tomasz Figa.
>  - Made local variables static in chipid driver.
>  - Added existing SoC's product id's.
>  - Added platform driver support.
>
> Changes since v2:
>  - Reorganized patches as suggested by Tomasz Figa.
>  - Addressed review comments of Tomasz Figa in i2c-s3c2410.c file.
>
> Changes since v1:
>  - Added patch to move i2c interrupt re-configuration code from exynos.c
>    to i2c driver, as suggested by Arnd.
>  - After above patch only user of SYS_I2C_CFG register is pm.c so moving
>    save/restore of this register also into i2c driver.
>  - Spiltted up exynos4 and exynos5 machine descriptors to get rid from
>    soc_is_exynos4/exynos5 kind of macros, as suggested by Arnd.
>  - Changed location of chipid driver to "drivers/soc".
>  - Added drivers/base/soc.c provided infrastructure to make SoC specific
>    information avaible to user space via sysfs entry, as suggested by Arnd.
>
>
> Pankaj Dubey (2):
>   soc: samsung: add exynos chipid driver support
>   ARM: EXYNOS: refactoring of mach-exynos to enable chipid driver

Hi,

This is quite old patchset and apparently was not merged. I quickly
looked at previous discussions (for previous versions) and it seems
all review feedback was addressed.

Any other obstacles?

Pankaj, maybe you could respin this (after merge window)?

Best regards,
Krzysztof

Re: [PATCH v5 0/2] Introducing Exynos ChipId driver

[Pankaj Dubey]

Hi Krzysztof,

On 16 May 2016 at 18:52, Krzysztof Kozlowski <k.kozlowski@samsung.com> wrote:
>
> On Thu, Dec 11, 2014 at 9:07 AM, Pankaj Dubey <pankaj.dubey@samsung.com> wrote:
> > This patch series introduces Exynos Chipid platform driver.
> > Each Exynos SoC has ChipID block which can give information about SoC's
> > product Id and revision number.
> > At the same time it reduces dependency of mach-exynos files from plat-samsung,
> > by removing samsung_rev API, similar API is introduced in chipid driver itself
> > to get revision number and product id.
> >
> > This patch series is based on Kukjin Kim's for-next having SHA_ID:
> > 9db7d78aca2c7fbc19a26ce2ef01c805dc010c72
> >
> > It can also be cleanly applied on latest (next-20141209) linux-next.
> >
> > This has been tested against both tree on Exynos3250 and Exynos5250 (SMDK) board.
> >
> > Revision 4 and it's discussion can be found here
> >  - https://lkml.org/lkml/2014/12/3/115
> >
> > Changes since v4:
> >  - Removed custom sysfs entries as they were not providing any new information
> >    as pointed out by Arnd.
> >  - Removed functions exporting product_id and revision, instead we will export
> >    exynos_chipid_info structure. It will be helpfull when we need to provide more
> >    fields of chipid outside of chipid, as commented by Yadwinder
> >  - Converted all funcions as __init.
> >
> > Change since v3:
> >  - This patch set contains 5/6 and 6/6 patch from v3 series.
> >  - Made EXYNOS_CHIPID config option non-user selectable,
> >    as suggested by Tomasz Figa.
> >  - Made uniform macro for EXYNOS4/5_SOC_MASK as EXYNOS_SOC_MASK as
> >    suggested by Tomasz Figa.
> >  - Made local variables static in chipid driver.
> >  - Added existing SoC's product id's.
> >  - Added platform driver support.
> >
> > Changes since v2:
> >  - Reorganized patches as suggested by Tomasz Figa.
> >  - Addressed review comments of Tomasz Figa in i2c-s3c2410.c file.
> >
> > Changes since v1:
> >  - Added patch to move i2c interrupt re-configuration code from exynos.c
> >    to i2c driver, as suggested by Arnd.
> >  - After above patch only user of SYS_I2C_CFG register is pm.c so moving
> >    save/restore of this register also into i2c driver.
> >  - Spiltted up exynos4 and exynos5 machine descriptors to get rid from
> >    soc_is_exynos4/exynos5 kind of macros, as suggested by Arnd.
> >  - Changed location of chipid driver to "drivers/soc".
> >  - Added drivers/base/soc.c provided infrastructure to make SoC specific
> >    information avaible to user space via sysfs entry, as suggested by Arnd.
> >
> >
> > Pankaj Dubey (2):
> >   soc: samsung: add exynos chipid driver support
> >   ARM: EXYNOS: refactoring of mach-exynos to enable chipid driver
>
> Hi,
>
> This is quite old patchset and apparently was not merged. I quickly
> looked at previous discussions (for previous versions) and it seems
> all review feedback was addressed.
>
> Any other obstacles?
>
> Pankaj, maybe you could respin this (after merge window)?

Thanks for looking into this.
Infact I also wanted to respin this patchset. Will do it soon.

Thanks,
Pankaj Dubey
>
> Best regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html