* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-10-31 11:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc, linux-arm-kernel, linuxppc-dev,
devicetree, linux-kernel, Geert Uytterhoeven
Hi all,
Some Renesas SoCs may exist in different revisions, providing slightly
different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
(errate and quirks). This needs to be catered for by drivers and/or
platform code. The recently proposed soc_device_match() API seems like
a good fit to handle this.
This patch series implements the core infrastructure to provide SoC and
revision information through the SoC bus for Renesas ARM SoCs. It
consists of 7 patches:
- Patches 1-4 provide soc_device_match(), with some related fixes,
- Patches 5-7 implement identification of Renesas SoCs and
registration with the SoC bus,
Changes compared to v1:
- Add Acked-by,
- New patches:
- "[4/7] base: soc: Provide a dummy implementation of
soc_device_match()",
- "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
- "[6/7] arm64: dts: r8a7795: Add device node for PRR"
(more similar patches available, I'm not yet spamming you all
with them),
- Drop SoC families and family names; use fixed "Renesas" instead,
- Drop EMEV2, which doesn't have a chip ID register, and doesn't share
devices with other SoCs,
- Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
M1A: not accessible from the ARM core?),
- On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
for SoCs that provide a chip ID register,
- Build renesas-soc only if SOC_BUS is enabled,
- Use "renesas,prr" and "renesas,cccr" device nodes in DT if
available, else fall back to hardcoded addresses for compatibility
with existing DTBs,
- Remove verification of product IDs; just print the ID instead,
- Don't register the SoC bus if the chip ID register is missing,
- Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
both).
Merge strategy:
- In theory, patches 1-4 should go through Greg's driver core tree.
But it's a hard dependency for all users.
If people agree, I can provide an immutable branch in my
renesas-drivers repository, to be merged by all interested parties.
So far I'm aware of Freescale/NXP, and Renesas.
- Patches 5-7 obviously have to go through Simon's Renesas tree (after
merging the soc_device_match() core), and arm-soc.
Tested on (machine, soc_id, optional revision):
EMEV2 KZM9D Board, emev2
Genmai, r7s72100
APE6EVM, r8a73a4, ES1.0
armadillo 800 eva, r8a7740, ES2.0
bockw, r8a7778
marzen, r8a7779, ES1.0
Lager, r8a7790, ES1.0
Koelsch, r8a7791, ES1.0
Porter, r8a7791, ES3.0
Blanche, r8a7792, ES1.1
Gose, r8a7793, ES1.0
Alt, r8a7794, ES1.0
Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
KZM-A9-GT, sh73a0, ES2.0
For your convenience, this series (incl. more DT updates to add device
nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
Its first user is support for R-Car H3 ES2.0 in branch
topic/r8a7795-es2-v1-rebased2.
Thanks for your comments!
Arnd Bergmann (1):
base: soc: Introduce soc_device_match() interface
Geert Uytterhoeven (6):
base: soc: Early register bus when needed
base: soc: Check for NULL SoC device attributes
base: soc: Provide a dummy implementation of soc_device_match()
ARM: shmobile: Document DT bindings for CCCR and PRR
arm64: dts: r8a7795: Add device node for PRR
soc: renesas: Identify SoC and register with the SoC bus
Documentation/devicetree/bindings/arm/shmobile.txt | 26 +++++
arch/arm/mach-shmobile/Kconfig | 3 +
arch/arm64/Kconfig.platforms | 1 +
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +
drivers/base/Kconfig | 1 +
drivers/base/soc.c | 79 +++++++++++++
drivers/soc/renesas/Makefile | 2 +
drivers/soc/renesas/renesas-soc.c | 130 +++++++++++++++++++++
include/linux/sys_soc.h | 9 ++
9 files changed, 256 insertions(+)
create mode 100644 drivers/soc/renesas/renesas-soc.c
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-10-31 11:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
Hi all,
Some Renesas SoCs may exist in different revisions, providing slightly
different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
(errate and quirks). This needs to be catered for by drivers and/or
platform code. The recently proposed soc_device_match() API seems like
a good fit to handle this.
This patch series implements the core infrastructure to provide SoC and
revision information through the SoC bus for Renesas ARM SoCs. It
consists of 7 patches:
- Patches 1-4 provide soc_device_match(), with some related fixes,
- Patches 5-7 implement identification of Renesas SoCs and
registration with the SoC bus,
Changes compared to v1:
- Add Acked-by,
- New patches:
- "[4/7] base: soc: Provide a dummy implementation of
soc_device_match()",
- "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
- "[6/7] arm64: dts: r8a7795: Add device node for PRR"
(more similar patches available, I'm not yet spamming you all
with them),
- Drop SoC families and family names; use fixed "Renesas" instead,
- Drop EMEV2, which doesn't have a chip ID register, and doesn't share
devices with other SoCs,
- Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
M1A: not accessible from the ARM core?),
- On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
for SoCs that provide a chip ID register,
- Build renesas-soc only if SOC_BUS is enabled,
- Use "renesas,prr" and "renesas,cccr" device nodes in DT if
available, else fall back to hardcoded addresses for compatibility
with existing DTBs,
- Remove verification of product IDs; just print the ID instead,
- Don't register the SoC bus if the chip ID register is missing,
- Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
both).
Merge strategy:
- In theory, patches 1-4 should go through Greg's driver core tree.
But it's a hard dependency for all users.
If people agree, I can provide an immutable branch in my
renesas-drivers repository, to be merged by all interested parties.
So far I'm aware of Freescale/NXP, and Renesas.
- Patches 5-7 obviously have to go through Simon's Renesas tree (after
merging the soc_device_match() core), and arm-soc.
Tested on (machine, soc_id, optional revision):
EMEV2 KZM9D Board, emev2
Genmai, r7s72100
APE6EVM, r8a73a4, ES1.0
armadillo 800 eva, r8a7740, ES2.0
bockw, r8a7778
marzen, r8a7779, ES1.0
Lager, r8a7790, ES1.0
Koelsch, r8a7791, ES1.0
Porter, r8a7791, ES3.0
Blanche, r8a7792, ES1.1
Gose, r8a7793, ES1.0
Alt, r8a7794, ES1.0
Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
KZM-A9-GT, sh73a0, ES2.0
For your convenience, this series (incl. more DT updates to add device
nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
Its first user is support for R-Car H3 ES2.0 in branch
topic/r8a7795-es2-v1-rebased2.
Thanks for your comments!
Arnd Bergmann (1):
base: soc: Introduce soc_device_match() interface
Geert Uytterhoeven (6):
base: soc: Early register bus when needed
base: soc: Check for NULL SoC device attributes
base: soc: Provide a dummy implementation of soc_device_match()
ARM: shmobile: Document DT bindings for CCCR and PRR
arm64: dts: r8a7795: Add device node for PRR
soc: renesas: Identify SoC and register with the SoC bus
Documentation/devicetree/bindings/arm/shmobile.txt | 26 +++++
arch/arm/mach-shmobile/Kconfig | 3 +
arch/arm64/Kconfig.platforms | 1 +
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +
drivers/base/Kconfig | 1 +
drivers/base/soc.c | 79 +++++++++++++
drivers/soc/renesas/Makefile | 2 +
drivers/soc/renesas/renesas-soc.c | 130 +++++++++++++++++++++
include/linux/sys_soc.h | 9 ++
9 files changed, 256 insertions(+)
create mode 100644 drivers/soc/renesas/renesas-soc.c
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 1/7] base: soc: Early register bus when needed
2016-10-31 11:30 ` Geert Uytterhoeven
(?)
@ 2016-10-31 11:30 ` Geert Uytterhoeven
-1 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc, linux-arm-kernel, linuxppc-dev,
devicetree, linux-kernel, Geert Uytterhoeven
If soc_device_register() is called before soc_bus_register(), it crashes
with a NULL pointer dereference.
soc_bus_register() is already a core_initcall(), but drivers/base/ is
entered later than e.g. drivers/pinctrl/ and drivers/soc/. Hence there
are several subsystems that may need to know SoC revision information,
while it's not so easy to initialize the SoC bus even earlier using an
initcall.
To fix this, let soc_device_register() register the bus early if that
hasn't happened yet.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
v2:
- Add Acked-by.
---
drivers/base/soc.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index b63f23e6ad61b647..028cef377fd49959 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -113,6 +113,12 @@ struct soc_device *soc_device_register(struct soc_device_attribute *soc_dev_attr
struct soc_device *soc_dev;
int ret;
+ if (!soc_bus_type.p) {
+ ret = bus_register(&soc_bus_type);
+ if (ret)
+ goto out1;
+ }
+
soc_dev = kzalloc(sizeof(*soc_dev), GFP_KERNEL);
if (!soc_dev) {
ret = -ENOMEM;
@@ -156,6 +162,9 @@ void soc_device_unregister(struct soc_device *soc_dev)
static int __init soc_bus_register(void)
{
+ if (soc_bus_type.p)
+ return 0;
+
return bus_register(&soc_bus_type);
}
core_initcall(soc_bus_register);
--
1.9.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCH v2 2/7] base: soc: Introduce soc_device_match() interface
2016-10-31 11:30 ` Geert Uytterhoeven
(?)
(?)
@ 2016-10-31 11:30 ` Geert Uytterhoeven
-1 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc, linux-arm-kernel, linuxppc-dev,
devicetree, linux-kernel, Geert Uytterhoeven
From: Arnd Bergmann <arnd@arndb.de>
We keep running into cases where device drivers want to know the exact
version of the a SoC they are currently running on. In the past, this has
usually been done through a vendor specific API that can be called by a
driver, or by directly accessing some kind of version register that is
not part of the device itself but that belongs to a global register area
of the chip.
Common reasons for doing this include:
- A machine is not using devicetree or similar for passing data about
on-chip devices, but just announces their presence using boot-time
platform devices, and the machine code itself does not care about the
revision.
- There is existing firmware or boot loaders with existing DT binaries
with generic compatible strings that do not identify the particular
revision of each device, but the driver knows which SoC revisions
include which part.
- A prerelease version of a chip has some quirks and we are using the same
version of the bootloader and the DT blob on both the prerelease and the
final version. An update of the DT binding seems inappropriate because
that would involve maintaining multiple copies of the dts and/or
bootloader.
This patch introduces the soc_device_match() interface that is meant to
work like of_match_node() but instead of identifying the version of a
device, it identifies the SoC itself using a vendor-agnostic interface.
Unlike of_match_node(), we do not do an exact string compare but instead
use glob_match() to allow wildcards in strings.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v2:
- Add Acked-by.
---
drivers/base/Kconfig | 1 +
drivers/base/soc.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/sys_soc.h | 3 +++
3 files changed, 70 insertions(+)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d02e7c0f5bfdff1c..2abea876c0a0c2c2 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -237,6 +237,7 @@ config GENERIC_CPU_AUTOPROBE
config SOC_BUS
bool
+ select GLOB
source "drivers/base/regmap/Kconfig"
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 028cef377fd49959..04ee597fc3a3fda0 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -13,6 +13,7 @@
#include <linux/spinlock.h>
#include <linux/sys_soc.h>
#include <linux/err.h>
+#include <linux/glob.h>
static DEFINE_IDA(soc_ida);
@@ -168,3 +169,68 @@ static int __init soc_bus_register(void)
return bus_register(&soc_bus_type);
}
core_initcall(soc_bus_register);
+
+static int soc_device_match_one(struct device *dev, void *arg)
+{
+ struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
+ const struct soc_device_attribute *match = arg;
+
+ if (match->machine &&
+ !glob_match(match->machine, soc_dev->attr->machine))
+ return 0;
+
+ if (match->family &&
+ !glob_match(match->family, soc_dev->attr->family))
+ return 0;
+
+ if (match->revision &&
+ !glob_match(match->revision, soc_dev->attr->revision))
+ return 0;
+
+ if (match->soc_id &&
+ !glob_match(match->soc_id, soc_dev->attr->soc_id))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * soc_device_match - identify the SoC in the machine
+ * @matches: zero-terminated array of possible matches
+ *
+ * returns the first matching entry of the argument array, or NULL
+ * if none of them match.
+ *
+ * This function is meant as a helper in place of of_match_node()
+ * in cases where either no device tree is available or the information
+ * in a device node is insufficient to identify a particular variant
+ * by its compatible strings or other properties. For new devices,
+ * the DT binding should always provide unique compatible strings
+ * that allow the use of of_match_node() instead.
+ *
+ * The calling function can use the .data entry of the
+ * soc_device_attribute to pass a structure or function pointer for
+ * each entry.
+ */
+const struct soc_device_attribute *soc_device_match(
+ const struct soc_device_attribute *matches)
+{
+ int ret = 0;
+
+ if (!matches)
+ return NULL;
+
+ while (!ret) {
+ if (!(matches->machine || matches->family ||
+ matches->revision || matches->soc_id))
+ break;
+ ret = bus_for_each_dev(&soc_bus_type, NULL, (void *)matches,
+ soc_device_match_one);
+ if (!ret)
+ matches++;
+ else
+ return matches;
+ }
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(soc_device_match);
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 2739ccb69571e444..9f5eb06f9fd87565 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -13,6 +13,7 @@ struct soc_device_attribute {
const char *family;
const char *revision;
const char *soc_id;
+ const void *data;
};
/**
@@ -34,4 +35,6 @@ struct soc_device *soc_device_register(
*/
struct device *soc_device_to_device(struct soc_device *soc);
+const struct soc_device_attribute *soc_device_match(
+ const struct soc_device_attribute *matches);
#endif /* __SOC_BUS_H */
--
1.9.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCH v2 3/7] base: soc: Check for NULL SoC device attributes
@ 2016-10-31 11:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc, linux-arm-kernel, linuxppc-dev,
devicetree, linux-kernel, Geert Uytterhoeven
If soc_device_match() is used to check the value of a specific
attribute that is not present for the current SoC, the kernel crashes
with a NULL pointer dereference.
Fix this by explicitly checking for the absence of a needed property,
and considering this a non-match.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v2:
- Add Acked-by.
---
drivers/base/soc.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 04ee597fc3a3fda0..dc26e5949a320223 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -176,19 +176,23 @@ static int soc_device_match_one(struct device *dev, void *arg)
const struct soc_device_attribute *match = arg;
if (match->machine &&
- !glob_match(match->machine, soc_dev->attr->machine))
+ (!soc_dev->attr->machine ||
+ !glob_match(match->machine, soc_dev->attr->machine)))
return 0;
if (match->family &&
- !glob_match(match->family, soc_dev->attr->family))
+ (!soc_dev->attr->family ||
+ !glob_match(match->family, soc_dev->attr->family)))
return 0;
if (match->revision &&
- !glob_match(match->revision, soc_dev->attr->revision))
+ (!soc_dev->attr->revision ||
+ !glob_match(match->revision, soc_dev->attr->revision)))
return 0;
if (match->soc_id &&
- !glob_match(match->soc_id, soc_dev->attr->soc_id))
+ (!soc_dev->attr->soc_id ||
+ !glob_match(match->soc_id, soc_dev->attr->soc_id)))
return 0;
return 1;
--
1.9.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCH v2 3/7] base: soc: Check for NULL SoC device attributes
@ 2016-10-31 11:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
If soc_device_match() is used to check the value of a specific
attribute that is not present for the current SoC, the kernel crashes
with a NULL pointer dereference.
Fix this by explicitly checking for the absence of a needed property,
and considering this a non-match.
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
---
v2:
- Add Acked-by.
---
drivers/base/soc.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 04ee597fc3a3fda0..dc26e5949a320223 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -176,19 +176,23 @@ static int soc_device_match_one(struct device *dev, void *arg)
const struct soc_device_attribute *match = arg;
if (match->machine &&
- !glob_match(match->machine, soc_dev->attr->machine))
+ (!soc_dev->attr->machine ||
+ !glob_match(match->machine, soc_dev->attr->machine)))
return 0;
if (match->family &&
- !glob_match(match->family, soc_dev->attr->family))
+ (!soc_dev->attr->family ||
+ !glob_match(match->family, soc_dev->attr->family)))
return 0;
if (match->revision &&
- !glob_match(match->revision, soc_dev->attr->revision))
+ (!soc_dev->attr->revision ||
+ !glob_match(match->revision, soc_dev->attr->revision)))
return 0;
if (match->soc_id &&
- !glob_match(match->soc_id, soc_dev->attr->soc_id))
+ (!soc_dev->attr->soc_id ||
+ !glob_match(match->soc_id, soc_dev->attr->soc_id)))
return 0;
return 1;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCH v2 4/7] base: soc: Provide a dummy implementation of soc_device_match()
2016-10-31 11:30 ` Geert Uytterhoeven
` (3 preceding siblings ...)
(?)
@ 2016-10-31 11:30 ` Geert Uytterhoeven
-1 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc, linux-arm-kernel, linuxppc-dev,
devicetree, linux-kernel, Geert Uytterhoeven
Provide a dummy implementation of soc_device_match(), to allow compiling
drivers that may be used on SoCs both with and without CONFIG_SOC_BUS,
and for compile testing.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- New.
---
include/linux/sys_soc.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 9f5eb06f9fd87565..bed223b70217fd2d 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -35,6 +35,12 @@ struct soc_device *soc_device_register(
*/
struct device *soc_device_to_device(struct soc_device *soc);
+#ifdef CONFIG_SOC_BUS
const struct soc_device_attribute *soc_device_match(
const struct soc_device_attribute *matches);
+#else
+static inline const struct soc_device_attribute *soc_device_match(
+ const struct soc_device_attribute *matches) { return NULL; }
+#endif
+
#endif /* __SOC_BUS_H */
--
1.9.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCH v2 5/7] ARM: shmobile: Document DT bindings for CCCR and PRR
@ 2016-10-31 11:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc, linux-arm-kernel, linuxppc-dev,
devicetree, linux-kernel, Geert Uytterhoeven
Add device tree binding documentation for the Common Chip Code Register
and Product Register, which provide SoC product and revision
information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- New.
---
Documentation/devicetree/bindings/arm/shmobile.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 15669642b5324412..bff1b596b235c535 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -79,3 +79,29 @@ Boards:
compatible = "renesas,sk-rzg1m", "renesas,r8a7743"
- Wheat
compatible = "renesas,wheat", "renesas,r8a7792"
+
+
+Most Renesas ARM SoCs have one or two registers (Common Chip Code
+Register and/or Product Register) that allow to retrieve SoC product and
+revision information. If present, device nodes for these devices should
+be added.
+
+Required properties:
+ - compatible: Must be one of:
+ - "renesas,cccr" for the Common Chip Code Register,
+ - "renesas,prr" for the Product Register.
+ - reg: Base address and length of the register block.
+
+
+Examples
+--------
+
+ cccr: chipid@e600101c {
+ compatible = "renesas,cccr";
+ reg = <0xe600101c 4>;
+ };
+
+ prr: chipid@ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
--
1.9.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCH v2 5/7] ARM: shmobile: Document DT bindings for CCCR and PRR
@ 2016-10-31 11:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
Add device tree binding documentation for the Common Chip Code Register
and Product Register, which provide SoC product and revision
information.
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
v2:
- New.
---
Documentation/devicetree/bindings/arm/shmobile.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 15669642b5324412..bff1b596b235c535 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -79,3 +79,29 @@ Boards:
compatible = "renesas,sk-rzg1m", "renesas,r8a7743"
- Wheat
compatible = "renesas,wheat", "renesas,r8a7792"
+
+
+Most Renesas ARM SoCs have one or two registers (Common Chip Code
+Register and/or Product Register) that allow to retrieve SoC product and
+revision information. If present, device nodes for these devices should
+be added.
+
+Required properties:
+ - compatible: Must be one of:
+ - "renesas,cccr" for the Common Chip Code Register,
+ - "renesas,prr" for the Product Register.
+ - reg: Base address and length of the register block.
+
+
+Examples
+--------
+
+ cccr: chipid@e600101c {
+ compatible = "renesas,cccr";
+ reg = <0xe600101c 4>;
+ };
+
+ prr: chipid@ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCH v2 6/7] arm64: dts: r8a7795: Add device node for PRR
2016-10-31 11:30 ` Geert Uytterhoeven
` (5 preceding siblings ...)
(?)
@ 2016-10-31 11:30 ` Geert Uytterhoeven
-1 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc, linux-arm-kernel, linuxppc-dev,
devicetree, linux-kernel, Geert Uytterhoeven
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- New.
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 681f54422375f4f7..a39a702b904da73c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -321,6 +321,11 @@
#power-domain-cells = <0>;
};
+ prr: chipid@fff00044 {
+ compatible = "renesas,prr";
+ reg = <0 0xfff00044 0 4>;
+ };
+
sysc: system-controller@e6180000 {
compatible = "renesas,r8a7795-sysc";
reg = <0 0xe6180000 0 0x0400>;
--
1.9.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-10-31 11:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc, linux-arm-kernel, linuxppc-dev,
devicetree, linux-kernel, Geert Uytterhoeven
Identify the SoC type and revision, and register this information with
the SoC bus, so it is available under /sys/devices/soc0/, and can be
checked where needed using soc_device_match().
Identification is done using the Product Register or Common Chip Code
Register, as declared in DT, or using a hardcoded fallback if missing.
Example:
Detected Renesas r8a7791 (0x47) ES1.0
...
# cat /sys/devices/soc0/{family,machine,soc_id,revision}
Renesas
Koelsch
r8a7791
ES1.0
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Drop SoC families and family names; use fixed "Renesas" instead,
- Drop EMEV2, which doesn't have a chip ID register, and doesn't share
devices with other SoCs,
- Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
M1A: not accessible from the ARM core?),
- On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
for SoCs that provide a chip ID register,
- Build renesas-soc only if SOC_BUS is enabled,
- Use "renesas,prr" and "renesas,cccr" device nodes in DT if
available, else fall back to hardcoded addresses for compatibility
with existing DTBs,
- Remove verification of product IDs; just print the ID instead,
- Don't register the SoC bus if the chip ID register is missing,
- Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
both).
---
arch/arm/mach-shmobile/Kconfig | 3 +
arch/arm64/Kconfig.platforms | 1 +
drivers/soc/renesas/Makefile | 2 +
drivers/soc/renesas/renesas-soc.c | 130 ++++++++++++++++++++++++++++++++++++++
4 files changed, 136 insertions(+)
create mode 100644 drivers/soc/renesas/renesas-soc.c
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 6fbd9b7d2d67a18f..dd4d52dd71b4eab2 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -21,11 +21,13 @@ config ARCH_RCAR_GEN2
select PM
select PM_GENERIC_DOMAINS
select RENESAS_IRQC
+ select SOC_BUS
select SYS_SUPPORTS_SH_CMT
config ARCH_RMOBILE
bool
select PM_RMOBILE
+ select SOC_BUS
select SYS_SUPPORTS_SH_CMT
select SYS_SUPPORTS_SH_TMU
@@ -80,6 +82,7 @@ config ARCH_R8A7778
config ARCH_R8A7779
bool "R-Car H1 (R8A77790)"
select ARCH_RCAR_GEN1
+ select SOC_BUS
config ARCH_R8A7790
bool "R-Car H2 (R8A77900)"
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 101794f5ce1008b7..b751c6891c6a51ed 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -143,6 +143,7 @@ config ARCH_RENESAS
select PM
select PM_GENERIC_DOMAINS
select RENESAS_IRQC
+ select SOC_BUS
help
This enables support for the ARMv8 based Renesas SoCs.
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 9e0bb329594c4fca..1652df037955e0e6 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -1,3 +1,5 @@
+obj-$(CONFIG_SOC_BUS) += renesas-soc.o
+
obj-$(CONFIG_ARCH_R8A7743) += rcar-sysc.o r8a7743-sysc.o
obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
new file mode 100644
index 0000000000000000..01104bfaefdb9f32
--- /dev/null
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -0,0 +1,130 @@
+/*
+ * Renesas SoC Identification
+ *
+ * Copyright (C) 2014-2016 Glider bvba
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/sys_soc.h>
+
+
+#define CCCR 0xe600101c /* Common Chip Code Register */
+#define PRR 0xff000044 /* Product Register */
+#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
+
+static const struct of_device_id renesas_socs[] __initconst = {
+#ifdef CONFIG_ARCH_R8A73A4
+ { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7740
+ { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7743
+ { .compatible = "renesas,r8a7743", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7745
+ { .compatible = "renesas,r8a7745", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7779
+ { .compatible = "renesas,r8a7779", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7790
+ { .compatible = "renesas,r8a7790", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7791
+ { .compatible = "renesas,r8a7791", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7792
+ { .compatible = "renesas,r8a7792", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7793
+ { .compatible = "renesas,r8a7793", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7794
+ { .compatible = "renesas,r8a7794", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7795
+ { .compatible = "renesas,r8a7795", .data = (void *)PRR3, },
+#endif
+#ifdef CONFIG_ARCH_R8A7796
+ { .compatible = "renesas,r8a7796", .data = (void *)PRR3, },
+#endif
+#ifdef CONFIG_ARCH_SH73A0
+ { .compatible = "renesas,sh73a0", .data = (void *)CCCR, },
+#endif
+ { /* sentinel */ }
+};
+
+static int __init renesas_soc_init(void)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ const struct of_device_id *match;
+ void __iomem *chipid = NULL;
+ struct soc_device *soc_dev;
+ struct device_node *np;
+ unsigned int product;
+
+ np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
+ if (!np)
+ return -ENODEV;
+
+ of_node_put(np);
+
+ /* Try PRR first, then CCCR, then hardcoded fallback */
+ np = of_find_compatible_node(NULL, NULL, "renesas,prr");
+ if (!np)
+ np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
+ if (np) {
+ chipid = of_iomap(np, 0);
+ of_node_put(np);
+ } else if (match->data) {
+ chipid = ioremap((uintptr_t)match->data, 4);
+ }
+ if (!chipid)
+ return -ENODEV;
+
+ product = readl(chipid);
+ iounmap(chipid);
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return -ENOMEM;
+
+ np = of_find_node_by_path("/");
+ of_property_read_string(np, "model", &soc_dev_attr->machine);
+ of_node_put(np);
+
+ soc_dev_attr->family = "Renesas";
+ soc_dev_attr->revision = kasprintf(GFP_KERNEL, "ES%u.%u",
+ ((product >> 4) & 0xf) + 1,
+ product & 0xf);
+ soc_dev_attr->soc_id = kstrdup_const(strchr(match->compatible, ',') + 1,
+ GFP_KERNEL);
+ pr_info("Detected %s %s (0x%02x) %s\n", soc_dev_attr->family,
+ soc_dev_attr->soc_id, (product >> 8) & 0xff,
+ soc_dev_attr->revision);
+
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ kfree(soc_dev_attr->revision);
+ kfree_const(soc_dev_attr->soc_id);
+ kfree(soc_dev_attr);
+ return PTR_ERR(soc_dev);
+ }
+
+ return 0;
+}
+core_initcall(renesas_soc_init);
--
1.9.1
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-10-31 11:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-10-31 11:30 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland
Cc: Dirk Behme, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
Identify the SoC type and revision, and register this information with
the SoC bus, so it is available under /sys/devices/soc0/, and can be
checked where needed using soc_device_match().
Identification is done using the Product Register or Common Chip Code
Register, as declared in DT, or using a hardcoded fallback if missing.
Example:
Detected Renesas r8a7791 (0x47) ES1.0
...
# cat /sys/devices/soc0/{family,machine,soc_id,revision}
Renesas
Koelsch
r8a7791
ES1.0
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
v2:
- Drop SoC families and family names; use fixed "Renesas" instead,
- Drop EMEV2, which doesn't have a chip ID register, and doesn't share
devices with other SoCs,
- Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
M1A: not accessible from the ARM core?),
- On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
for SoCs that provide a chip ID register,
- Build renesas-soc only if SOC_BUS is enabled,
- Use "renesas,prr" and "renesas,cccr" device nodes in DT if
available, else fall back to hardcoded addresses for compatibility
with existing DTBs,
- Remove verification of product IDs; just print the ID instead,
- Don't register the SoC bus if the chip ID register is missing,
- Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
both).
---
arch/arm/mach-shmobile/Kconfig | 3 +
arch/arm64/Kconfig.platforms | 1 +
drivers/soc/renesas/Makefile | 2 +
drivers/soc/renesas/renesas-soc.c | 130 ++++++++++++++++++++++++++++++++++++++
4 files changed, 136 insertions(+)
create mode 100644 drivers/soc/renesas/renesas-soc.c
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 6fbd9b7d2d67a18f..dd4d52dd71b4eab2 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -21,11 +21,13 @@ config ARCH_RCAR_GEN2
select PM
select PM_GENERIC_DOMAINS
select RENESAS_IRQC
+ select SOC_BUS
select SYS_SUPPORTS_SH_CMT
config ARCH_RMOBILE
bool
select PM_RMOBILE
+ select SOC_BUS
select SYS_SUPPORTS_SH_CMT
select SYS_SUPPORTS_SH_TMU
@@ -80,6 +82,7 @@ config ARCH_R8A7778
config ARCH_R8A7779
bool "R-Car H1 (R8A77790)"
select ARCH_RCAR_GEN1
+ select SOC_BUS
config ARCH_R8A7790
bool "R-Car H2 (R8A77900)"
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 101794f5ce1008b7..b751c6891c6a51ed 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -143,6 +143,7 @@ config ARCH_RENESAS
select PM
select PM_GENERIC_DOMAINS
select RENESAS_IRQC
+ select SOC_BUS
help
This enables support for the ARMv8 based Renesas SoCs.
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index 9e0bb329594c4fca..1652df037955e0e6 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -1,3 +1,5 @@
+obj-$(CONFIG_SOC_BUS) += renesas-soc.o
+
obj-$(CONFIG_ARCH_R8A7743) += rcar-sysc.o r8a7743-sysc.o
obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
new file mode 100644
index 0000000000000000..01104bfaefdb9f32
--- /dev/null
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -0,0 +1,130 @@
+/*
+ * Renesas SoC Identification
+ *
+ * Copyright (C) 2014-2016 Glider bvba
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/sys_soc.h>
+
+
+#define CCCR 0xe600101c /* Common Chip Code Register */
+#define PRR 0xff000044 /* Product Register */
+#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
+
+static const struct of_device_id renesas_socs[] __initconst = {
+#ifdef CONFIG_ARCH_R8A73A4
+ { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7740
+ { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7743
+ { .compatible = "renesas,r8a7743", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7745
+ { .compatible = "renesas,r8a7745", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7779
+ { .compatible = "renesas,r8a7779", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7790
+ { .compatible = "renesas,r8a7790", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7791
+ { .compatible = "renesas,r8a7791", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7792
+ { .compatible = "renesas,r8a7792", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7793
+ { .compatible = "renesas,r8a7793", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7794
+ { .compatible = "renesas,r8a7794", .data = (void *)PRR, },
+#endif
+#ifdef CONFIG_ARCH_R8A7795
+ { .compatible = "renesas,r8a7795", .data = (void *)PRR3, },
+#endif
+#ifdef CONFIG_ARCH_R8A7796
+ { .compatible = "renesas,r8a7796", .data = (void *)PRR3, },
+#endif
+#ifdef CONFIG_ARCH_SH73A0
+ { .compatible = "renesas,sh73a0", .data = (void *)CCCR, },
+#endif
+ { /* sentinel */ }
+};
+
+static int __init renesas_soc_init(void)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ const struct of_device_id *match;
+ void __iomem *chipid = NULL;
+ struct soc_device *soc_dev;
+ struct device_node *np;
+ unsigned int product;
+
+ np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
+ if (!np)
+ return -ENODEV;
+
+ of_node_put(np);
+
+ /* Try PRR first, then CCCR, then hardcoded fallback */
+ np = of_find_compatible_node(NULL, NULL, "renesas,prr");
+ if (!np)
+ np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
+ if (np) {
+ chipid = of_iomap(np, 0);
+ of_node_put(np);
+ } else if (match->data) {
+ chipid = ioremap((uintptr_t)match->data, 4);
+ }
+ if (!chipid)
+ return -ENODEV;
+
+ product = readl(chipid);
+ iounmap(chipid);
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return -ENOMEM;
+
+ np = of_find_node_by_path("/");
+ of_property_read_string(np, "model", &soc_dev_attr->machine);
+ of_node_put(np);
+
+ soc_dev_attr->family = "Renesas";
+ soc_dev_attr->revision = kasprintf(GFP_KERNEL, "ES%u.%u",
+ ((product >> 4) & 0xf) + 1,
+ product & 0xf);
+ soc_dev_attr->soc_id = kstrdup_const(strchr(match->compatible, ',') + 1,
+ GFP_KERNEL);
+ pr_info("Detected %s %s (0x%02x) %s\n", soc_dev_attr->family,
+ soc_dev_attr->soc_id, (product >> 8) & 0xff,
+ soc_dev_attr->revision);
+
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ kfree(soc_dev_attr->revision);
+ kfree_const(soc_dev_attr->soc_id);
+ kfree(soc_dev_attr);
+ return PTR_ERR(soc_dev);
+ }
+
+ return 0;
+}
+core_initcall(renesas_soc_init);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
2016-10-31 11:30 ` Geert Uytterhoeven
(?)
@ 2016-11-07 9:35 ` Geert Uytterhoeven
-1 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-07 9:35 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland, Dirk Behme,
Linux-Renesas, linux-arm-kernel, linuxppc-dev, devicetree,
linux-kernel, Pankaj Dubey, linux-samsung-soc
On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Some Renesas SoCs may exist in different revisions, providing slightly
> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> (errate and quirks). This needs to be catered for by drivers and/or
> platform code. The recently proposed soc_device_match() API seems like
> a good fit to handle this.
>
> This patch series implements the core infrastructure to provide SoC and
> revision information through the SoC bus for Renesas ARM SoCs. It
> consists of 7 patches:
> - Patches 1-4 provide soc_device_match(), with some related fixes,
> - Patches 5-7 implement identification of Renesas SoCs and
> registration with the SoC bus,
>
> Changes compared to v1:
> - Add Acked-by,
> - New patches:
> - "[4/7] base: soc: Provide a dummy implementation of
> soc_device_match()",
> - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
> - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
> (more similar patches available, I'm not yet spamming you all
> with them),
> - Drop SoC families and family names; use fixed "Renesas" instead,
> - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
> devices with other SoCs,
> - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
> M1A: not accessible from the ARM core?),
> - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
> for SoCs that provide a chip ID register,
> - Build renesas-soc only if SOC_BUS is enabled,
> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> available, else fall back to hardcoded addresses for compatibility
> with existing DTBs,
> - Remove verification of product IDs; just print the ID instead,
> - Don't register the SoC bus if the chip ID register is missing,
> - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
> both).
>
> Merge strategy:
> - In theory, patches 1-4 should go through Greg's driver core tree.
> But it's a hard dependency for all users.
> If people agree, I can provide an immutable branch in my
> renesas-drivers repository, to be merged by all interested parties.
> So far I'm aware of Freescale/NXP, and Renesas.
And Samsung.
Shall I create the immutable branch now?
Thanks!
> - Patches 5-7 obviously have to go through Simon's Renesas tree (after
> merging the soc_device_match() core), and arm-soc.
>
> Tested on (machine, soc_id, optional revision):
> EMEV2 KZM9D Board, emev2
> Genmai, r7s72100
> APE6EVM, r8a73a4, ES1.0
> armadillo 800 eva, r8a7740, ES2.0
> bockw, r8a7778
> marzen, r8a7779, ES1.0
> Lager, r8a7790, ES1.0
> Koelsch, r8a7791, ES1.0
> Porter, r8a7791, ES3.0
> Blanche, r8a7792, ES1.1
> Gose, r8a7793, ES1.0
> Alt, r8a7794, ES1.0
> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
> Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
> KZM-A9-GT, sh73a0, ES2.0
>
> For your convenience, this series (incl. more DT updates to add device
> nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
> in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
> repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> Its first user is support for R-Car H3 ES2.0 in branch
> topic/r8a7795-es2-v1-rebased2.
>
> Thanks for your comments!
>
> Arnd Bergmann (1):
> base: soc: Introduce soc_device_match() interface
>
> Geert Uytterhoeven (6):
> base: soc: Early register bus when needed
> base: soc: Check for NULL SoC device attributes
> base: soc: Provide a dummy implementation of soc_device_match()
> ARM: shmobile: Document DT bindings for CCCR and PRR
> arm64: dts: r8a7795: Add device node for PRR
> soc: renesas: Identify SoC and register with the SoC bus
>
> Documentation/devicetree/bindings/arm/shmobile.txt | 26 +++++
> arch/arm/mach-shmobile/Kconfig | 3 +
> arch/arm64/Kconfig.platforms | 1 +
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 79 +++++++++++++
> drivers/soc/renesas/Makefile | 2 +
> drivers/soc/renesas/renesas-soc.c | 130 +++++++++++++++++++++
> include/linux/sys_soc.h | 9 ++
> 9 files changed, 256 insertions(+)
> create mode 100644 drivers/soc/renesas/renesas-soc.c
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-07 9:35 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-07 9:35 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland, Dirk Behme,
Linux-Renesas, linux-arm-kernel, linuxppc-dev, devicetree,
linux-kernel, Pankaj Dubey, linux-samsung-soc
On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Some Renesas SoCs may exist in different revisions, providing slightly
> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> (errate and quirks). This needs to be catered for by drivers and/or
> platform code. The recently proposed soc_device_match() API seems like
> a good fit to handle this.
>
> This patch series implements the core infrastructure to provide SoC and
> revision information through the SoC bus for Renesas ARM SoCs. It
> consists of 7 patches:
> - Patches 1-4 provide soc_device_match(), with some related fixes,
> - Patches 5-7 implement identification of Renesas SoCs and
> registration with the SoC bus,
>
> Changes compared to v1:
> - Add Acked-by,
> - New patches:
> - "[4/7] base: soc: Provide a dummy implementation of
> soc_device_match()",
> - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
> - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
> (more similar patches available, I'm not yet spamming you all
> with them),
> - Drop SoC families and family names; use fixed "Renesas" instead,
> - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
> devices with other SoCs,
> - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
> M1A: not accessible from the ARM core?),
> - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
> for SoCs that provide a chip ID register,
> - Build renesas-soc only if SOC_BUS is enabled,
> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> available, else fall back to hardcoded addresses for compatibility
> with existing DTBs,
> - Remove verification of product IDs; just print the ID instead,
> - Don't register the SoC bus if the chip ID register is missing,
> - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
> both).
>
> Merge strategy:
> - In theory, patches 1-4 should go through Greg's driver core tree.
> But it's a hard dependency for all users.
> If people agree, I can provide an immutable branch in my
> renesas-drivers repository, to be merged by all interested parties.
> So far I'm aware of Freescale/NXP, and Renesas.
And Samsung.
Shall I create the immutable branch now?
Thanks!
> - Patches 5-7 obviously have to go through Simon's Renesas tree (after
> merging the soc_device_match() core), and arm-soc.
>
> Tested on (machine, soc_id, optional revision):
> EMEV2 KZM9D Board, emev2
> Genmai, r7s72100
> APE6EVM, r8a73a4, ES1.0
> armadillo 800 eva, r8a7740, ES2.0
> bockw, r8a7778
> marzen, r8a7779, ES1.0
> Lager, r8a7790, ES1.0
> Koelsch, r8a7791, ES1.0
> Porter, r8a7791, ES3.0
> Blanche, r8a7792, ES1.1
> Gose, r8a7793, ES1.0
> Alt, r8a7794, ES1.0
> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
> Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
> KZM-A9-GT, sh73a0, ES2.0
>
> For your convenience, this series (incl. more DT updates to add device
> nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
> in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
> repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> Its first user is support for R-Car H3 ES2.0 in branch
> topic/r8a7795-es2-v1-rebased2.
>
> Thanks for your comments!
>
> Arnd Bergmann (1):
> base: soc: Introduce soc_device_match() interface
>
> Geert Uytterhoeven (6):
> base: soc: Early register bus when needed
> base: soc: Check for NULL SoC device attributes
> base: soc: Provide a dummy implementation of soc_device_match()
> ARM: shmobile: Document DT bindings for CCCR and PRR
> arm64: dts: r8a7795: Add device node for PRR
> soc: renesas: Identify SoC and register with the SoC bus
>
> Documentation/devicetree/bindings/arm/shmobile.txt | 26 +++++
> arch/arm/mach-shmobile/Kconfig | 3 +
> arch/arm64/Kconfig.platforms | 1 +
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 79 +++++++++++++
> drivers/soc/renesas/Makefile | 2 +
> drivers/soc/renesas/renesas-soc.c | 130 +++++++++++++++++++++
> include/linux/sys_soc.h | 9 ++
> 9 files changed, 256 insertions(+)
> create mode 100644 drivers/soc/renesas/renesas-soc.c
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-07 9:35 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-07 9:35 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Some Renesas SoCs may exist in different revisions, providing slightly
> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> (errate and quirks). This needs to be catered for by drivers and/or
> platform code. The recently proposed soc_device_match() API seems like
> a good fit to handle this.
>
> This patch series implements the core infrastructure to provide SoC and
> revision information through the SoC bus for Renesas ARM SoCs. It
> consists of 7 patches:
> - Patches 1-4 provide soc_device_match(), with some related fixes,
> - Patches 5-7 implement identification of Renesas SoCs and
> registration with the SoC bus,
>
> Changes compared to v1:
> - Add Acked-by,
> - New patches:
> - "[4/7] base: soc: Provide a dummy implementation of
> soc_device_match()",
> - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
> - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
> (more similar patches available, I'm not yet spamming you all
> with them),
> - Drop SoC families and family names; use fixed "Renesas" instead,
> - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
> devices with other SoCs,
> - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
> M1A: not accessible from the ARM core?),
> - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
> for SoCs that provide a chip ID register,
> - Build renesas-soc only if SOC_BUS is enabled,
> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> available, else fall back to hardcoded addresses for compatibility
> with existing DTBs,
> - Remove verification of product IDs; just print the ID instead,
> - Don't register the SoC bus if the chip ID register is missing,
> - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
> both).
>
> Merge strategy:
> - In theory, patches 1-4 should go through Greg's driver core tree.
> But it's a hard dependency for all users.
> If people agree, I can provide an immutable branch in my
> renesas-drivers repository, to be merged by all interested parties.
> So far I'm aware of Freescale/NXP, and Renesas.
And Samsung.
Shall I create the immutable branch now?
Thanks!
> - Patches 5-7 obviously have to go through Simon's Renesas tree (after
> merging the soc_device_match() core), and arm-soc.
>
> Tested on (machine, soc_id, optional revision):
> EMEV2 KZM9D Board, emev2
> Genmai, r7s72100
> APE6EVM, r8a73a4, ES1.0
> armadillo 800 eva, r8a7740, ES2.0
> bockw, r8a7778
> marzen, r8a7779, ES1.0
> Lager, r8a7790, ES1.0
> Koelsch, r8a7791, ES1.0
> Porter, r8a7791, ES3.0
> Blanche, r8a7792, ES1.1
> Gose, r8a7793, ES1.0
> Alt, r8a7794, ES1.0
> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
> Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
> KZM-A9-GT, sh73a0, ES2.0
>
> For your convenience, this series (incl. more DT updates to add device
> nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
> in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
> repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> Its first user is support for R-Car H3 ES2.0 in branch
> topic/r8a7795-es2-v1-rebased2.
>
> Thanks for your comments!
>
> Arnd Bergmann (1):
> base: soc: Introduce soc_device_match() interface
>
> Geert Uytterhoeven (6):
> base: soc: Early register bus when needed
> base: soc: Check for NULL SoC device attributes
> base: soc: Provide a dummy implementation of soc_device_match()
> ARM: shmobile: Document DT bindings for CCCR and PRR
> arm64: dts: r8a7795: Add device node for PRR
> soc: renesas: Identify SoC and register with the SoC bus
>
> Documentation/devicetree/bindings/arm/shmobile.txt | 26 +++++
> arch/arm/mach-shmobile/Kconfig | 3 +
> arch/arm64/Kconfig.platforms | 1 +
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 79 +++++++++++++
> drivers/soc/renesas/Makefile | 2 +
> drivers/soc/renesas/renesas-soc.c | 130 +++++++++++++++++++++
> include/linux/sys_soc.h | 9 ++
> 9 files changed, 256 insertions(+)
> create mode 100644 drivers/soc/renesas/renesas-soc.c
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-07 18:33 ` Krzysztof Kozlowski
0 siblings, 0 replies; 59+ messages in thread
From: Krzysztof Kozlowski @ 2016-11-07 18:33 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, Dirk Behme,
Linux-Renesas, linux-arm-kernel, linuxppc-dev, devicetree,
linux-kernel, Pankaj Dubey, linux-samsung-soc
On Mon, Nov 07, 2016 at 10:35:31AM +0100, Geert Uytterhoeven wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > Some Renesas SoCs may exist in different revisions, providing slightly
> > different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> > (errate and quirks). This needs to be catered for by drivers and/or
> > platform code. The recently proposed soc_device_match() API seems like
> > a good fit to handle this.
> >
> > This patch series implements the core infrastructure to provide SoC and
> > revision information through the SoC bus for Renesas ARM SoCs. It
> > consists of 7 patches:
> > - Patches 1-4 provide soc_device_match(), with some related fixes,
> > - Patches 5-7 implement identification of Renesas SoCs and
> > registration with the SoC bus,
> >
> > Changes compared to v1:
> > - Add Acked-by,
> > - New patches:
> > - "[4/7] base: soc: Provide a dummy implementation of
> > soc_device_match()",
> > - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
> > - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
> > (more similar patches available, I'm not yet spamming you all
> > with them),
> > - Drop SoC families and family names; use fixed "Renesas" instead,
> > - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
> > devices with other SoCs,
> > - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
> > M1A: not accessible from the ARM core?),
> > - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
> > for SoCs that provide a chip ID register,
> > - Build renesas-soc only if SOC_BUS is enabled,
> > - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> > available, else fall back to hardcoded addresses for compatibility
> > with existing DTBs,
> > - Remove verification of product IDs; just print the ID instead,
> > - Don't register the SoC bus if the chip ID register is missing,
> > - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
> > both).
> >
> > Merge strategy:
> > - In theory, patches 1-4 should go through Greg's driver core tree.
> > But it's a hard dependency for all users.
> > If people agree, I can provide an immutable branch in my
> > renesas-drivers repository, to be merged by all interested parties.
> > So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
Yes, I would need it as well.
> Shall I create the immutable branch now?
...or the applying person could provide one.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-07 18:33 ` Krzysztof Kozlowski
0 siblings, 0 replies; 59+ messages in thread
From: Krzysztof Kozlowski @ 2016-11-07 18:33 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, Dirk Behme,
Linux-Renesas, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Pankaj Dubey,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
On Mon, Nov 07, 2016 at 10:35:31AM +0100, Geert Uytterhoeven wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
> > Some Renesas SoCs may exist in different revisions, providing slightly
> > different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> > (errate and quirks). This needs to be catered for by drivers and/or
> > platform code. The recently proposed soc_device_match() API seems like
> > a good fit to handle this.
> >
> > This patch series implements the core infrastructure to provide SoC and
> > revision information through the SoC bus for Renesas ARM SoCs. It
> > consists of 7 patches:
> > - Patches 1-4 provide soc_device_match(), with some related fixes,
> > - Patches 5-7 implement identification of Renesas SoCs and
> > registration with the SoC bus,
> >
> > Changes compared to v1:
> > - Add Acked-by,
> > - New patches:
> > - "[4/7] base: soc: Provide a dummy implementation of
> > soc_device_match()",
> > - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
> > - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
> > (more similar patches available, I'm not yet spamming you all
> > with them),
> > - Drop SoC families and family names; use fixed "Renesas" instead,
> > - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
> > devices with other SoCs,
> > - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
> > M1A: not accessible from the ARM core?),
> > - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
> > for SoCs that provide a chip ID register,
> > - Build renesas-soc only if SOC_BUS is enabled,
> > - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> > available, else fall back to hardcoded addresses for compatibility
> > with existing DTBs,
> > - Remove verification of product IDs; just print the ID instead,
> > - Don't register the SoC bus if the chip ID register is missing,
> > - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
> > both).
> >
> > Merge strategy:
> > - In theory, patches 1-4 should go through Greg's driver core tree.
> > But it's a hard dependency for all users.
> > If people agree, I can provide an immutable branch in my
> > renesas-drivers repository, to be merged by all interested parties.
> > So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
Yes, I would need it as well.
> Shall I create the immutable branch now?
...or the applying person could provide one.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-07 18:33 ` Krzysztof Kozlowski
0 siblings, 0 replies; 59+ messages in thread
From: Krzysztof Kozlowski @ 2016-11-07 18:33 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, Dirk Behme,
Linux-Renesas, linux-arm-kernel, linuxppc-dev, devicetree,
linux-kernel, Pankaj Dubey, linux-samsung-soc
On Mon, Nov 07, 2016 at 10:35:31AM +0100, Geert Uytterhoeven wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > Some Renesas SoCs may exist in different revisions, providing slightly
> > different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> > (errate and quirks). This needs to be catered for by drivers and/or
> > platform code. The recently proposed soc_device_match() API seems like
> > a good fit to handle this.
> >
> > This patch series implements the core infrastructure to provide SoC and
> > revision information through the SoC bus for Renesas ARM SoCs. It
> > consists of 7 patches:
> > - Patches 1-4 provide soc_device_match(), with some related fixes,
> > - Patches 5-7 implement identification of Renesas SoCs and
> > registration with the SoC bus,
> >
> > Changes compared to v1:
> > - Add Acked-by,
> > - New patches:
> > - "[4/7] base: soc: Provide a dummy implementation of
> > soc_device_match()",
> > - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
> > - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
> > (more similar patches available, I'm not yet spamming you all
> > with them),
> > - Drop SoC families and family names; use fixed "Renesas" instead,
> > - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
> > devices with other SoCs,
> > - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
> > M1A: not accessible from the ARM core?),
> > - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
> > for SoCs that provide a chip ID register,
> > - Build renesas-soc only if SOC_BUS is enabled,
> > - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> > available, else fall back to hardcoded addresses for compatibility
> > with existing DTBs,
> > - Remove verification of product IDs; just print the ID instead,
> > - Don't register the SoC bus if the chip ID register is missing,
> > - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
> > both).
> >
> > Merge strategy:
> > - In theory, patches 1-4 should go through Greg's driver core tree.
> > But it's a hard dependency for all users.
> > If people agree, I can provide an immutable branch in my
> > renesas-drivers repository, to be merged by all interested parties.
> > So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
Yes, I would need it as well.
> Shall I create the immutable branch now?
...or the applying person could provide one.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-07 18:33 ` Krzysztof Kozlowski
0 siblings, 0 replies; 59+ messages in thread
From: Krzysztof Kozlowski @ 2016-11-07 18:33 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Nov 07, 2016 at 10:35:31AM +0100, Geert Uytterhoeven wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > Some Renesas SoCs may exist in different revisions, providing slightly
> > different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> > (errate and quirks). This needs to be catered for by drivers and/or
> > platform code. The recently proposed soc_device_match() API seems like
> > a good fit to handle this.
> >
> > This patch series implements the core infrastructure to provide SoC and
> > revision information through the SoC bus for Renesas ARM SoCs. It
> > consists of 7 patches:
> > - Patches 1-4 provide soc_device_match(), with some related fixes,
> > - Patches 5-7 implement identification of Renesas SoCs and
> > registration with the SoC bus,
> >
> > Changes compared to v1:
> > - Add Acked-by,
> > - New patches:
> > - "[4/7] base: soc: Provide a dummy implementation of
> > soc_device_match()",
> > - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
> > - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
> > (more similar patches available, I'm not yet spamming you all
> > with them),
> > - Drop SoC families and family names; use fixed "Renesas" instead,
> > - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
> > devices with other SoCs,
> > - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
> > M1A: not accessible from the ARM core?),
> > - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
> > for SoCs that provide a chip ID register,
> > - Build renesas-soc only if SOC_BUS is enabled,
> > - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> > available, else fall back to hardcoded addresses for compatibility
> > with existing DTBs,
> > - Remove verification of product IDs; just print the ID instead,
> > - Don't register the SoC bus if the chip ID register is missing,
> > - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
> > both).
> >
> > Merge strategy:
> > - In theory, patches 1-4 should go through Greg's driver core tree.
> > But it's a hard dependency for all users.
> > If people agree, I can provide an immutable branch in my
> > renesas-drivers repository, to be merged by all interested parties.
> > So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
Yes, I would need it as well.
> Shall I create the immutable branch now?
...or the applying person could provide one.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
2016-11-07 9:35 ` Geert Uytterhoeven
(?)
@ 2016-11-09 13:34 ` Geert Uytterhoeven
-1 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-09 13:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, Dirk Behme, Linux-Renesas,
linux-arm-kernel, linuxppc-dev, devicetree, linux-kernel,
Pankaj Dubey, linux-samsung-soc
Hi Arnd,
On Mon, Nov 7, 2016 at 10:35 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>> Some Renesas SoCs may exist in different revisions, providing slightly
>> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
>> (errate and quirks). This needs to be catered for by drivers and/or
>> platform code. The recently proposed soc_device_match() API seems like
>> a good fit to handle this.
>>
>> This patch series implements the core infrastructure to provide SoC and
>> revision information through the SoC bus for Renesas ARM SoCs. It
>> consists of 7 patches:
>> - Patches 1-4 provide soc_device_match(), with some related fixes,
>> - Patches 5-7 implement identification of Renesas SoCs and
>> registration with the SoC bus,
>>
>> Changes compared to v1:
>> - Add Acked-by,
>> - New patches:
>> - "[4/7] base: soc: Provide a dummy implementation of
>> soc_device_match()",
>> - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
>> - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
>> (more similar patches available, I'm not yet spamming you all
>> with them),
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>> - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
>> devices with other SoCs,
>> - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
>> M1A: not accessible from the ARM core?),
>> - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
>> for SoCs that provide a chip ID register,
>> - Build renesas-soc only if SOC_BUS is enabled,
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>> - Remove verification of product IDs; just print the ID instead,
>> - Don't register the SoC bus if the chip ID register is missing,
>> - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
>> both).
>>
>> Merge strategy:
>> - In theory, patches 1-4 should go through Greg's driver core tree.
>> But it's a hard dependency for all users.
>> If people agree, I can provide an immutable branch in my
>> renesas-drivers repository, to be merged by all interested parties.
>> So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
> Shall I create the immutable branch now?
Arnd: are you happy with the new patches and changes?
Thanks again!
>> - Patches 5-7 obviously have to go through Simon's Renesas tree (after
>> merging the soc_device_match() core), and arm-soc.
>>
>> Tested on (machine, soc_id, optional revision):
>> EMEV2 KZM9D Board, emev2
>> Genmai, r7s72100
>> APE6EVM, r8a73a4, ES1.0
>> armadillo 800 eva, r8a7740, ES2.0
>> bockw, r8a7778
>> marzen, r8a7779, ES1.0
>> Lager, r8a7790, ES1.0
>> Koelsch, r8a7791, ES1.0
>> Porter, r8a7791, ES3.0
>> Blanche, r8a7792, ES1.1
>> Gose, r8a7793, ES1.0
>> Alt, r8a7794, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
>> Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
>> KZM-A9-GT, sh73a0, ES2.0
>>
>> For your convenience, this series (incl. more DT updates to add device
>> nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
>> in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
>> repository at
>> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
>> Its first user is support for R-Car H3 ES2.0 in branch
>> topic/r8a7795-es2-v1-rebased2.
>>
>> Thanks for your comments!
>>
>> Arnd Bergmann (1):
>> base: soc: Introduce soc_device_match() interface
>>
>> Geert Uytterhoeven (6):
>> base: soc: Early register bus when needed
>> base: soc: Check for NULL SoC device attributes
>> base: soc: Provide a dummy implementation of soc_device_match()
>> ARM: shmobile: Document DT bindings for CCCR and PRR
>> arm64: dts: r8a7795: Add device node for PRR
>> soc: renesas: Identify SoC and register with the SoC bus
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-09 13:34 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-09 13:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, Dirk Behme, Linux-Renesas,
linux-arm-kernel, linuxppc-dev, devicetree, linux-kernel,
Pankaj Dubey, linux-samsung-soc
Hi Arnd,
On Mon, Nov 7, 2016 at 10:35 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>> Some Renesas SoCs may exist in different revisions, providing slightly
>> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
>> (errate and quirks). This needs to be catered for by drivers and/or
>> platform code. The recently proposed soc_device_match() API seems like
>> a good fit to handle this.
>>
>> This patch series implements the core infrastructure to provide SoC and
>> revision information through the SoC bus for Renesas ARM SoCs. It
>> consists of 7 patches:
>> - Patches 1-4 provide soc_device_match(), with some related fixes,
>> - Patches 5-7 implement identification of Renesas SoCs and
>> registration with the SoC bus,
>>
>> Changes compared to v1:
>> - Add Acked-by,
>> - New patches:
>> - "[4/7] base: soc: Provide a dummy implementation of
>> soc_device_match()",
>> - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
>> - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
>> (more similar patches available, I'm not yet spamming you all
>> with them),
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>> - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
>> devices with other SoCs,
>> - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
>> M1A: not accessible from the ARM core?),
>> - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
>> for SoCs that provide a chip ID register,
>> - Build renesas-soc only if SOC_BUS is enabled,
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>> - Remove verification of product IDs; just print the ID instead,
>> - Don't register the SoC bus if the chip ID register is missing,
>> - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
>> both).
>>
>> Merge strategy:
>> - In theory, patches 1-4 should go through Greg's driver core tree.
>> But it's a hard dependency for all users.
>> If people agree, I can provide an immutable branch in my
>> renesas-drivers repository, to be merged by all interested parties.
>> So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
> Shall I create the immutable branch now?
Arnd: are you happy with the new patches and changes?
Thanks again!
>> - Patches 5-7 obviously have to go through Simon's Renesas tree (after
>> merging the soc_device_match() core), and arm-soc.
>>
>> Tested on (machine, soc_id, optional revision):
>> EMEV2 KZM9D Board, emev2
>> Genmai, r7s72100
>> APE6EVM, r8a73a4, ES1.0
>> armadillo 800 eva, r8a7740, ES2.0
>> bockw, r8a7778
>> marzen, r8a7779, ES1.0
>> Lager, r8a7790, ES1.0
>> Koelsch, r8a7791, ES1.0
>> Porter, r8a7791, ES3.0
>> Blanche, r8a7792, ES1.1
>> Gose, r8a7793, ES1.0
>> Alt, r8a7794, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
>> Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
>> KZM-A9-GT, sh73a0, ES2.0
>>
>> For your convenience, this series (incl. more DT updates to add device
>> nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
>> in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
>> repository at
>> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
>> Its first user is support for R-Car H3 ES2.0 in branch
>> topic/r8a7795-es2-v1-rebased2.
>>
>> Thanks for your comments!
>>
>> Arnd Bergmann (1):
>> base: soc: Introduce soc_device_match() interface
>>
>> Geert Uytterhoeven (6):
>> base: soc: Early register bus when needed
>> base: soc: Check for NULL SoC device attributes
>> base: soc: Provide a dummy implementation of soc_device_match()
>> ARM: shmobile: Document DT bindings for CCCR and PRR
>> arm64: dts: r8a7795: Add device node for PRR
>> soc: renesas: Identify SoC and register with the SoC bus
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-09 13:34 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-09 13:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
On Mon, Nov 7, 2016 at 10:35 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>> Some Renesas SoCs may exist in different revisions, providing slightly
>> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
>> (errate and quirks). This needs to be catered for by drivers and/or
>> platform code. The recently proposed soc_device_match() API seems like
>> a good fit to handle this.
>>
>> This patch series implements the core infrastructure to provide SoC and
>> revision information through the SoC bus for Renesas ARM SoCs. It
>> consists of 7 patches:
>> - Patches 1-4 provide soc_device_match(), with some related fixes,
>> - Patches 5-7 implement identification of Renesas SoCs and
>> registration with the SoC bus,
>>
>> Changes compared to v1:
>> - Add Acked-by,
>> - New patches:
>> - "[4/7] base: soc: Provide a dummy implementation of
>> soc_device_match()",
>> - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
>> - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
>> (more similar patches available, I'm not yet spamming you all
>> with them),
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>> - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
>> devices with other SoCs,
>> - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
>> M1A: not accessible from the ARM core?),
>> - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
>> for SoCs that provide a chip ID register,
>> - Build renesas-soc only if SOC_BUS is enabled,
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>> - Remove verification of product IDs; just print the ID instead,
>> - Don't register the SoC bus if the chip ID register is missing,
>> - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
>> both).
>>
>> Merge strategy:
>> - In theory, patches 1-4 should go through Greg's driver core tree.
>> But it's a hard dependency for all users.
>> If people agree, I can provide an immutable branch in my
>> renesas-drivers repository, to be merged by all interested parties.
>> So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
> Shall I create the immutable branch now?
Arnd: are you happy with the new patches and changes?
Thanks again!
>> - Patches 5-7 obviously have to go through Simon's Renesas tree (after
>> merging the soc_device_match() core), and arm-soc.
>>
>> Tested on (machine, soc_id, optional revision):
>> EMEV2 KZM9D Board, emev2
>> Genmai, r7s72100
>> APE6EVM, r8a73a4, ES1.0
>> armadillo 800 eva, r8a7740, ES2.0
>> bockw, r8a7778
>> marzen, r8a7779, ES1.0
>> Lager, r8a7790, ES1.0
>> Koelsch, r8a7791, ES1.0
>> Porter, r8a7791, ES3.0
>> Blanche, r8a7792, ES1.1
>> Gose, r8a7793, ES1.0
>> Alt, r8a7794, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
>> Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
>> Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
>> KZM-A9-GT, sh73a0, ES2.0
>>
>> For your convenience, this series (incl. more DT updates to add device
>> nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
>> in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
>> repository at
>> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
>> Its first user is support for R-Car H3 ES2.0 in branch
>> topic/r8a7795-es2-v1-rebased2.
>>
>> Thanks for your comments!
>>
>> Arnd Bergmann (1):
>> base: soc: Introduce soc_device_match() interface
>>
>> Geert Uytterhoeven (6):
>> base: soc: Early register bus when needed
>> base: soc: Check for NULL SoC device attributes
>> base: soc: Provide a dummy implementation of soc_device_match()
>> ARM: shmobile: Document DT bindings for CCCR and PRR
>> arm64: dts: r8a7795: Add device node for PRR
>> soc: renesas: Identify SoC and register with the SoC bus
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
2016-10-31 11:30 ` Geert Uytterhoeven
@ 2016-11-09 16:55 ` Arnd Bergmann
-1 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-09 16:55 UTC (permalink / raw)
To: linuxppc-dev
Cc: Geert Uytterhoeven, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Rob Herring, Mark Rutland, devicetree, Dirk Behme,
linux-kernel, linux-renesas-soc, linux-arm-kernel
On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> v2:
> - Drop SoC families and family names; use fixed "Renesas" instead,
I think I'd rather have seen the family names left in there, but it's
not important, so up to you.
> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> available, else fall back to hardcoded addresses for compatibility
> with existing DTBs,
I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
binding for these, among other things.
It does seem wrong to have a device node for a specific register though.
Shouldn't the node be for the block of registers that these are inside
of?
> - Don't register the SoC bus if the chip ID register is missing,
Why? My objection was to hardcoding the register, not to registering
the device? I think I'd rather see the device registered with an
empty revision string.
> +#define CCCR 0xe600101c /* Common Chip Code Register */
> +#define PRR 0xff000044 /* Product Register */
> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
> +
> +static const struct of_device_id renesas_socs[] __initconst = {
> +#ifdef CONFIG_ARCH_R8A73A4
> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7740
> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
> +#endif
My preference here would be to list the register address only for
SoCs that are known to need them, while also having .dtb files that
don't have the nodes.
> +static int __init renesas_soc_init(void)
> +{
> + struct soc_device_attribute *soc_dev_attr;
> + const struct of_device_id *match;
> + void __iomem *chipid = NULL;
> + struct soc_device *soc_dev;
> + struct device_node *np;
> + unsigned int product;
> +
> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
> + if (!np)
> + return -ENODEV;
> +
> + of_node_put(np);
> +
> + /* Try PRR first, then CCCR, then hardcoded fallback */
> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
> + if (!np)
> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
> + if (np) {
> + chipid = of_iomap(np, 0);
> + of_node_put(np);
> + } else if (match->data) {
> + chipid = ioremap((uintptr_t)match->data, 4);
> + }
> + if (!chipid)
>
Here, I'd turn the order around and look for the DT nodes of the
devices first. Only if they are not found, look at the compatible
string of the root node. No need to search for a node though,
you know which one it is when you look for a compatible =
"renesas,r8a73a4".
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-09 16:55 ` Arnd Bergmann
0 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-09 16:55 UTC (permalink / raw)
To: linux-arm-kernel
On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> v2:
> - Drop SoC families and family names; use fixed "Renesas" instead,
I think I'd rather have seen the family names left in there, but it's
not important, so up to you.
> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> available, else fall back to hardcoded addresses for compatibility
> with existing DTBs,
I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
binding for these, among other things.
It does seem wrong to have a device node for a specific register though.
Shouldn't the node be for the block of registers that these are inside
of?
> - Don't register the SoC bus if the chip ID register is missing,
Why? My objection was to hardcoding the register, not to registering
the device? I think I'd rather see the device registered with an
empty revision string.
> +#define CCCR 0xe600101c /* Common Chip Code Register */
> +#define PRR 0xff000044 /* Product Register */
> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
> +
> +static const struct of_device_id renesas_socs[] __initconst = {
> +#ifdef CONFIG_ARCH_R8A73A4
> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
> +#endif
> +#ifdef CONFIG_ARCH_R8A7740
> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
> +#endif
My preference here would be to list the register address only for
SoCs that are known to need them, while also having .dtb files that
don't have the nodes.
> +static int __init renesas_soc_init(void)
> +{
> + struct soc_device_attribute *soc_dev_attr;
> + const struct of_device_id *match;
> + void __iomem *chipid = NULL;
> + struct soc_device *soc_dev;
> + struct device_node *np;
> + unsigned int product;
> +
> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
> + if (!np)
> + return -ENODEV;
> +
> + of_node_put(np);
> +
> + /* Try PRR first, then CCCR, then hardcoded fallback */
> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
> + if (!np)
> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
> + if (np) {
> + chipid = of_iomap(np, 0);
> + of_node_put(np);
> + } else if (match->data) {
> + chipid = ioremap((uintptr_t)match->data, 4);
> + }
> + if (!chipid)
>
Here, I'd turn the order around and look for the DT nodes of the
devices first. Only if they are not found, look at the compatible
string of the root node. No need to search for a node though,
you know which one it is when you look for a compatible =
"renesas,r8a73a4".
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-09 16:56 ` Arnd Bergmann
0 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-09 16:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, Dirk Behme, Linux-Renesas,
linux-arm-kernel, linuxppc-dev, devicetree, linux-kernel,
Pankaj Dubey, linux-samsung-soc
On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
> >
> > And Samsung.
> > Shall I create the immutable branch now?
>
> Arnd: are you happy with the new patches and changes?
I still had some comments for patch 7, but that shouldn't stop
you from creating a branch for the first three so everyone can
build on top of that.
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-09 16:56 ` Arnd Bergmann
0 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-09 16:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, Dirk Behme, Linux-Renesas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Pankaj Dubey,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA
On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
> >
> > And Samsung.
> > Shall I create the immutable branch now?
>
> Arnd: are you happy with the new patches and changes?
I still had some comments for patch 7, but that shouldn't stop
you from creating a branch for the first three so everyone can
build on top of that.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-09 16:56 ` Arnd Bergmann
0 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-09 16:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, Dirk Behme, Linux-Renesas,
linux-arm-kernel, linuxppc-dev, devicetree, linux-kernel,
Pankaj Dubey, linux-samsung-soc
On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
> >
> > And Samsung.
> > Shall I create the immutable branch now?
>
> Arnd: are you happy with the new patches and changes?
I still had some comments for patch 7, but that shouldn't stop
you from creating a branch for the first three so everyone can
build on top of that.
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-09 16:56 ` Arnd Bergmann
0 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-09 16:56 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
> >
> > And Samsung.
> > Shall I create the immutable branch now?
>
> Arnd: are you happy with the new patches and changes?
I still had some comments for patch 7, but that shouldn't stop
you from creating a branch for the first three so everyone can
build on top of that.
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
2016-11-09 16:56 ` Arnd Bergmann
(?)
@ 2016-11-09 17:19 ` Geert Uytterhoeven
-1 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-09 17:19 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, Dirk Behme, Linux-Renesas,
linux-arm-kernel, linuxppc-dev, devicetree, linux-kernel,
Pankaj Dubey, linux-samsung-soc
Hi Arnd,
On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> > And Samsung.
>> > Shall I create the immutable branch now?
>>
>> Arnd: are you happy with the new patches and changes?
>
> I still had some comments for patch 7, but that shouldn't stop
> you from creating a branch for the first three so everyone can
> build on top of that.
Thanks!
What about patch [4/7]?
Haven't you received it? Your address was in the To-line for all 7 patches.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-09 17:19 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-09 17:19 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, Dirk Behme, Linux-Renesas,
linux-arm-kernel, linuxppc-dev, devicetree, linux-kernel,
Pankaj Dubey, linux-samsung-soc
Hi Arnd,
On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> > And Samsung.
>> > Shall I create the immutable branch now?
>>
>> Arnd: are you happy with the new patches and changes?
>
> I still had some comments for patch 7, but that shouldn't stop
> you from creating a branch for the first three so everyone can
> build on top of that.
Thanks!
What about patch [4/7]?
Haven't you received it? Your address was in the To-line for all 7 patches.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-09 17:19 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-09 17:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> > And Samsung.
>> > Shall I create the immutable branch now?
>>
>> Arnd: are you happy with the new patches and changes?
>
> I still had some comments for patch 7, but that shouldn't stop
> you from creating a branch for the first three so everyone can
> build on top of that.
Thanks!
What about patch [4/7]?
Haven't you received it? Your address was in the To-line for all 7 patches.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 5/7] ARM: shmobile: Document DT bindings for CCCR and PRR
2016-10-31 11:30 ` Geert Uytterhoeven
(?)
@ 2016-11-09 18:24 ` Rob Herring
-1 siblings, 0 replies; 59+ messages in thread
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Greg Kroah-Hartman, Yangbo Lu, Simon Horman,
Magnus Damm, Mark Rutland, Dirk Behme, linux-renesas-soc,
linux-arm-kernel, linuxppc-dev, devicetree, linux-kernel
On Mon, Oct 31, 2016 at 12:30:53PM +0100, Geert Uytterhoeven wrote:
> Add device tree binding documentation for the Common Chip Code Register
> and Product Register, which provide SoC product and revision
> information.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
> - New.
> ---
> Documentation/devicetree/bindings/arm/shmobile.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 5/7] ARM: shmobile: Document DT bindings for CCCR and PRR
@ 2016-11-09 18:24 ` Rob Herring
0 siblings, 0 replies; 59+ messages in thread
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Rutland, devicetree, Dirk Behme, Arnd Bergmann,
Greg Kroah-Hartman, Magnus Damm, linux-kernel, linux-renesas-soc,
Simon Horman, Yangbo Lu, linuxppc-dev, linux-arm-kernel
On Mon, Oct 31, 2016 at 12:30:53PM +0100, Geert Uytterhoeven wrote:
> Add device tree binding documentation for the Common Chip Code Register
> and Product Register, which provide SoC product and revision
> information.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
> - New.
> ---
> Documentation/devicetree/bindings/arm/shmobile.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 5/7] ARM: shmobile: Document DT bindings for CCCR and PRR
@ 2016-11-09 18:24 ` Rob Herring
0 siblings, 0 replies; 59+ messages in thread
From: Rob Herring @ 2016-11-09 18:24 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 31, 2016 at 12:30:53PM +0100, Geert Uytterhoeven wrote:
> Add device tree binding documentation for the Common Chip Code Register
> and Product Register, which provide SoC product and revision
> information.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
> - New.
> ---
> Documentation/devicetree/bindings/arm/shmobile.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
2016-11-09 17:19 ` Geert Uytterhoeven
(?)
@ 2016-11-09 21:12 ` Arnd Bergmann
-1 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-09 21:12 UTC (permalink / raw)
To: linuxppc-dev
Cc: Geert Uytterhoeven, Mark Rutland, devicetree, Dirk Behme,
Greg Kroah-Hartman, linux-kernel, Rob Herring, Linux-Renesas,
linux-samsung-soc, Simon Horman, Yangbo Lu, Pankaj Dubey,
linux-arm-kernel
On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
> >> > And Samsung.
> >> > Shall I create the immutable branch now?
> >>
> >> Arnd: are you happy with the new patches and changes?
> >
> > I still had some comments for patch 7, but that shouldn't stop
> > you from creating a branch for the first three so everyone can
> > build on top of that.
>
> Thanks!
>
> What about patch [4/7]?
> Haven't you received it? Your address was in the To-line for all 7 patches.
Ok, I see it now, looks good. That should be included as well then.
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-09 21:12 ` Arnd Bergmann
0 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-09 21:12 UTC (permalink / raw)
To: linuxppc-dev
Cc: Geert Uytterhoeven, Mark Rutland, devicetree, Dirk Behme,
Greg Kroah-Hartman, linux-kernel, Rob Herring, Linux-Renesas,
linux-samsung-soc, Simon Horman, Yangbo Lu, Pankaj Dubey,
linux-arm-kernel
On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
> >> > And Samsung.
> >> > Shall I create the immutable branch now?
> >>
> >> Arnd: are you happy with the new patches and changes?
> >
> > I still had some comments for patch 7, but that shouldn't stop
> > you from creating a branch for the first three so everyone can
> > build on top of that.
>
> Thanks!
>
> What about patch [4/7]?
> Haven't you received it? Your address was in the To-line for all 7 patches.
Ok, I see it now, looks good. That should be included as well then.
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-09 21:12 ` Arnd Bergmann
0 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-09 21:12 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
> >> > And Samsung.
> >> > Shall I create the immutable branch now?
> >>
> >> Arnd: are you happy with the new patches and changes?
> >
> > I still had some comments for patch 7, but that shouldn't stop
> > you from creating a branch for the first three so everyone can
> > build on top of that.
>
> Thanks!
>
> What about patch [4/7]?
> Haven't you received it? Your address was in the To-line for all 7 patches.
Ok, I see it now, looks good. That should be included as well then.
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
2016-11-09 21:12 ` Arnd Bergmann
(?)
(?)
@ 2016-11-10 9:22 ` Geert Uytterhoeven
-1 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-10 9:22 UTC (permalink / raw)
To: Ulf Hansson
Cc: linuxppc-dev, Mark Rutland, devicetree, Dirk Behme,
Greg Kroah-Hartman, linux-kernel, Rob Herring, Linux-Renesas,
linux-samsung-soc, Simon Horman, Yangbo Lu, Pankaj Dubey,
linux-arm-kernel, Arnd Bergmann
Hi Ulf,
On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> >> > And Samsung.
>> >> > Shall I create the immutable branch now?
>> >>
>> >> Arnd: are you happy with the new patches and changes?
>> >
>> > I still had some comments for patch 7, but that shouldn't stop
>> > you from creating a branch for the first three so everyone can
>> > build on top of that.
>>
>> Thanks!
>>
>> What about patch [4/7]?
>> Haven't you received it? Your address was in the To-line for all 7 patches.
>
> Ok, I see it now, looks good. That should be included as well then.
Thanks, I've created the branch/tag :
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
branch soc-device-match
signed tag soc-device-match-tag1
In the mean time, Ulf has applied the first two patches to mmc/next, on top
of lots of MMC work :-(
Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
but also for Samsung and Renesas, would it still be possible to replace these
two commits
8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
6fa350172b098f0f base: soc: Check for NULL SoC device attributes
by a merge of soc-device-match-tag1?
You can find more info in the full thread at
https://www.spinics.net/lists/devicetree/msg148558.html
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-10 9:22 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-10 9:22 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, devicetree, Dirk Behme, Arnd Bergmann,
Simon Horman, Greg Kroah-Hartman, linux-kernel, Linux-Renesas,
linux-samsung-soc, Rob Herring, Yangbo Lu, linuxppc-dev,
Pankaj Dubey, linux-arm-kernel
Hi Ulf,
On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> >> > And Samsung.
>> >> > Shall I create the immutable branch now?
>> >>
>> >> Arnd: are you happy with the new patches and changes?
>> >
>> > I still had some comments for patch 7, but that shouldn't stop
>> > you from creating a branch for the first three so everyone can
>> > build on top of that.
>>
>> Thanks!
>>
>> What about patch [4/7]?
>> Haven't you received it? Your address was in the To-line for all 7 patches.
>
> Ok, I see it now, looks good. That should be included as well then.
Thanks, I've created the branch/tag :
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
branch soc-device-match
signed tag soc-device-match-tag1
In the mean time, Ulf has applied the first two patches to mmc/next, on top
of lots of MMC work :-(
Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
but also for Samsung and Renesas, would it still be possible to replace these
two commits
8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
6fa350172b098f0f base: soc: Check for NULL SoC device attributes
by a merge of soc-device-match-tag1?
You can find more info in the full thread at
https://www.spinics.net/lists/devicetree/msg148558.html
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-10 9:22 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-10 9:22 UTC (permalink / raw)
To: Ulf Hansson
Cc: linuxppc-dev, Mark Rutland, devicetree, Dirk Behme,
Greg Kroah-Hartman, linux-kernel, Rob Herring, Linux-Renesas,
linux-samsung-soc, Simon Horman, Yangbo Lu, Pankaj Dubey,
linux-arm-kernel, Arnd Bergmann
Hi Ulf,
On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> >> > And Samsung.
>> >> > Shall I create the immutable branch now?
>> >>
>> >> Arnd: are you happy with the new patches and changes?
>> >
>> > I still had some comments for patch 7, but that shouldn't stop
>> > you from creating a branch for the first three so everyone can
>> > build on top of that.
>>
>> Thanks!
>>
>> What about patch [4/7]?
>> Haven't you received it? Your address was in the To-line for all 7 patches.
>
> Ok, I see it now, looks good. That should be included as well then.
Thanks, I've created the branch/tag :
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
branch soc-device-match
signed tag soc-device-match-tag1
In the mean time, Ulf has applied the first two patches to mmc/next, on top
of lots of MMC work :-(
Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
but also for Samsung and Renesas, would it still be possible to replace these
two commits
8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
6fa350172b098f0f base: soc: Check for NULL SoC device attributes
by a merge of soc-device-match-tag1?
You can find more info in the full thread at
https://www.spinics.net/lists/devicetree/msg148558.html
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-10 9:22 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-10 9:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ulf,
On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> >> > And Samsung.
>> >> > Shall I create the immutable branch now?
>> >>
>> >> Arnd: are you happy with the new patches and changes?
>> >
>> > I still had some comments for patch 7, but that shouldn't stop
>> > you from creating a branch for the first three so everyone can
>> > build on top of that.
>>
>> Thanks!
>>
>> What about patch [4/7]?
>> Haven't you received it? Your address was in the To-line for all 7 patches.
>
> Ok, I see it now, looks good. That should be included as well then.
Thanks, I've created the branch/tag :
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
branch soc-device-match
signed tag soc-device-match-tag1
In the mean time, Ulf has applied the first two patches to mmc/next, on top
of lots of MMC work :-(
Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
but also for Samsung and Renesas, would it still be possible to replace these
two commits
8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
6fa350172b098f0f base: soc: Check for NULL SoC device attributes
by a merge of soc-device-match-tag1?
You can find more info in the full thread at
https://www.spinics.net/lists/devicetree/msg148558.html
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
2016-11-09 16:55 ` Arnd Bergmann
(?)
@ 2016-11-10 10:19 ` Geert Uytterhoeven
-1 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-10 10:19 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Geert Uytterhoeven, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, devicetree,
Dirk Behme, linux-kernel, Linux-Renesas, linux-arm-kernel
Hi Arnd,
Thanks for your comments!
On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> v2:
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>
> I think I'd rather have seen the family names left in there, but it's
> not important, so up to you.
They're not useful for matching, as family names may change anytime, and don't
always say much about the hardware capabilities.
E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
SuperH.
At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>
> I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
> binding for these, among other things.
I understand you've received them in the mean time?
> It does seem wrong to have a device node for a specific register though.
> Shouldn't the node be for the block of registers that these are inside
> of?
On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
we further don't touch at all.
On R-Car Gen2, it's not documented, but does exist.
BTW, see why I'd prefer not to have it in DT at all, and go for KISS in code
we can change at any time? To avoid mistakes we have to keep on supporting
forever.
>> - Don't register the SoC bus if the chip ID register is missing,
>
> Why? My objection was to hardcoding the register, not to registering
> the device? I think I'd rather see the device registered with an
> empty revision string.
If there's no chip ID register, there's no reason to use soc_device_match(),
as we can always look at a compatible value. All SoCs listed in this driver
have a chip ID register.
if you want me to register the soc_bus for those SoCs regardless, I want to
re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
registers ;-)
>> +#define CCCR 0xe600101c /* Common Chip Code Register */
>> +#define PRR 0xff000044 /* Product Register */
>> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
>> +
>> +static const struct of_device_id renesas_socs[] __initconst = {
>> +#ifdef CONFIG_ARCH_R8A73A4
>> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
>> +#endif
>> +#ifdef CONFIG_ARCH_R8A7740
>> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
>> +#endif
>
> My preference here would be to list the register address only for
> SoCs that are known to need them, while also having .dtb files that
> don't have the nodes.
Even if drivers don't have to handle differences, there's been a long
outstanding request to print SoC revision information during bootup
(E.g. "Does it still work on ES1.0?"). Hence that covers all SoCs.
>> +static int __init renesas_soc_init(void)
>> +{
>> + struct soc_device_attribute *soc_dev_attr;
>> + const struct of_device_id *match;
>> + void __iomem *chipid = NULL;
>> + struct soc_device *soc_dev;
>> + struct device_node *np;
>> + unsigned int product;
>> +
>> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> + if (!np)
>> + return -ENODEV;
>> +
>> + of_node_put(np);
>> +
>> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> + if (!np)
>> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> + if (np) {
>> + chipid = of_iomap(np, 0);
>> + of_node_put(np);
>> + } else if (match->data) {
>> + chipid = ioremap((uintptr_t)match->data, 4);
>> + }
>> + if (!chipid)
>>
>
> Here, I'd turn the order around and look for the DT nodes of the
> devices first. Only if they are not found, look at the compatible
> string of the root node. No need to search for a node though,
> you know which one it is when you look for a compatible =
> "renesas,r8a73a4".
"renesas,r8a73a4" is the root node, not the device, so it does not have the
"reg" property for reading the chip ID?
There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
Hence I always need to look at the root nodes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-10 10:19 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-10 10:19 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Geert Uytterhoeven, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, devicetree,
Dirk Behme, linux-kernel, Linux-Renesas, linux-arm-kernel
Hi Arnd,
Thanks for your comments!
On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> v2:
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>
> I think I'd rather have seen the family names left in there, but it's
> not important, so up to you.
They're not useful for matching, as family names may change anytime, and don't
always say much about the hardware capabilities.
E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
SuperH.
At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>
> I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
> binding for these, among other things.
I understand you've received them in the mean time?
> It does seem wrong to have a device node for a specific register though.
> Shouldn't the node be for the block of registers that these are inside
> of?
On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
we further don't touch at all.
On R-Car Gen2, it's not documented, but does exist.
BTW, see why I'd prefer not to have it in DT at all, and go for KISS in code
we can change at any time? To avoid mistakes we have to keep on supporting
forever.
>> - Don't register the SoC bus if the chip ID register is missing,
>
> Why? My objection was to hardcoding the register, not to registering
> the device? I think I'd rather see the device registered with an
> empty revision string.
If there's no chip ID register, there's no reason to use soc_device_match(),
as we can always look at a compatible value. All SoCs listed in this driver
have a chip ID register.
if you want me to register the soc_bus for those SoCs regardless, I want to
re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
registers ;-)
>> +#define CCCR 0xe600101c /* Common Chip Code Register */
>> +#define PRR 0xff000044 /* Product Register */
>> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
>> +
>> +static const struct of_device_id renesas_socs[] __initconst = {
>> +#ifdef CONFIG_ARCH_R8A73A4
>> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
>> +#endif
>> +#ifdef CONFIG_ARCH_R8A7740
>> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
>> +#endif
>
> My preference here would be to list the register address only for
> SoCs that are known to need them, while also having .dtb files that
> don't have the nodes.
Even if drivers don't have to handle differences, there's been a long
outstanding request to print SoC revision information during bootup
(E.g. "Does it still work on ES1.0?"). Hence that covers all SoCs.
>> +static int __init renesas_soc_init(void)
>> +{
>> + struct soc_device_attribute *soc_dev_attr;
>> + const struct of_device_id *match;
>> + void __iomem *chipid = NULL;
>> + struct soc_device *soc_dev;
>> + struct device_node *np;
>> + unsigned int product;
>> +
>> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> + if (!np)
>> + return -ENODEV;
>> +
>> + of_node_put(np);
>> +
>> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> + if (!np)
>> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> + if (np) {
>> + chipid = of_iomap(np, 0);
>> + of_node_put(np);
>> + } else if (match->data) {
>> + chipid = ioremap((uintptr_t)match->data, 4);
>> + }
>> + if (!chipid)
>>
>
> Here, I'd turn the order around and look for the DT nodes of the
> devices first. Only if they are not found, look at the compatible
> string of the root node. No need to search for a node though,
> you know which one it is when you look for a compatible =
> "renesas,r8a73a4".
"renesas,r8a73a4" is the root node, not the device, so it does not have the
"reg" property for reading the chip ID?
There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
Hence I always need to look at the root nodes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-10 10:19 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-10 10:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Thanks for your comments!
On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> v2:
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>
> I think I'd rather have seen the family names left in there, but it's
> not important, so up to you.
They're not useful for matching, as family names may change anytime, and don't
always say much about the hardware capabilities.
E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
SuperH.
At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>
> I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
> binding for these, among other things.
I understand you've received them in the mean time?
> It does seem wrong to have a device node for a specific register though.
> Shouldn't the node be for the block of registers that these are inside
> of?
On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
we further don't touch at all.
On R-Car Gen2, it's not documented, but does exist.
BTW, see why I'd prefer not to have it in DT at all, and go for KISS in code
we can change at any time? To avoid mistakes we have to keep on supporting
forever.
>> - Don't register the SoC bus if the chip ID register is missing,
>
> Why? My objection was to hardcoding the register, not to registering
> the device? I think I'd rather see the device registered with an
> empty revision string.
If there's no chip ID register, there's no reason to use soc_device_match(),
as we can always look at a compatible value. All SoCs listed in this driver
have a chip ID register.
if you want me to register the soc_bus for those SoCs regardless, I want to
re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
registers ;-)
>> +#define CCCR 0xe600101c /* Common Chip Code Register */
>> +#define PRR 0xff000044 /* Product Register */
>> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
>> +
>> +static const struct of_device_id renesas_socs[] __initconst = {
>> +#ifdef CONFIG_ARCH_R8A73A4
>> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
>> +#endif
>> +#ifdef CONFIG_ARCH_R8A7740
>> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
>> +#endif
>
> My preference here would be to list the register address only for
> SoCs that are known to need them, while also having .dtb files that
> don't have the nodes.
Even if drivers don't have to handle differences, there's been a long
outstanding request to print SoC revision information during bootup
(E.g. "Does it still work on ES1.0?"). Hence that covers all SoCs.
>> +static int __init renesas_soc_init(void)
>> +{
>> + struct soc_device_attribute *soc_dev_attr;
>> + const struct of_device_id *match;
>> + void __iomem *chipid = NULL;
>> + struct soc_device *soc_dev;
>> + struct device_node *np;
>> + unsigned int product;
>> +
>> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> + if (!np)
>> + return -ENODEV;
>> +
>> + of_node_put(np);
>> +
>> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> + if (!np)
>> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> + if (np) {
>> + chipid = of_iomap(np, 0);
>> + of_node_put(np);
>> + } else if (match->data) {
>> + chipid = ioremap((uintptr_t)match->data, 4);
>> + }
>> + if (!chipid)
>>
>
> Here, I'd turn the order around and look for the DT nodes of the
> devices first. Only if they are not found, look at the compatible
> string of the root node. No need to search for a node though,
> you know which one it is when you look for a compatible =
> "renesas,r8a73a4".
"renesas,r8a73a4" is the root node, not the device, so it does not have the
"reg" property for reading the chip ID?
There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
Hence I always need to look at the root nodes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
2016-11-10 9:22 ` Geert Uytterhoeven
(?)
@ 2016-11-10 10:56 ` Geert Uytterhoeven
-1 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-10 10:56 UTC (permalink / raw)
To: Ulf Hansson
Cc: linuxppc-dev, Mark Rutland, devicetree, Dirk Behme,
Greg Kroah-Hartman, linux-kernel, Rob Herring, Linux-Renesas,
linux-samsung-soc, Simon Horman, Yangbo Lu, Pankaj Dubey,
linux-arm-kernel, Arnd Bergmann
On Thu, Nov 10, 2016 at 10:22 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
Tested by kbuild test robot:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
soc-device-match
da65a1589dacc7ec44ea0557a14d70a39d991f32 base: soc: Provide a
dummy implementation of soc_device_match()
elapsed time: 101m
configs tested: 85
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-10 10:56 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-10 10:56 UTC (permalink / raw)
To: Ulf Hansson
Cc: linuxppc-dev, Mark Rutland, devicetree, Dirk Behme,
Greg Kroah-Hartman, linux-kernel, Rob Herring, Linux-Renesas,
linux-samsung-soc, Simon Horman, Yangbo Lu, Pankaj Dubey,
linux-arm-kernel, Arnd Bergmann
On Thu, Nov 10, 2016 at 10:22 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
Tested by kbuild test robot:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
soc-device-match
da65a1589dacc7ec44ea0557a14d70a39d991f32 base: soc: Provide a
dummy implementation of soc_device_match()
elapsed time: 101m
configs tested: 85
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-10 10:56 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-10 10:56 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Nov 10, 2016 at 10:22 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
Tested by kbuild test robot:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
soc-device-match
da65a1589dacc7ec44ea0557a14d70a39d991f32 base: soc: Provide a
dummy implementation of soc_device_match()
elapsed time: 101m
configs tested: 85
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
2016-11-10 9:22 ` Geert Uytterhoeven
(?)
@ 2016-11-10 10:59 ` Ulf Hansson
-1 siblings, 0 replies; 59+ messages in thread
From: Ulf Hansson @ 2016-11-10 10:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev, Mark Rutland, devicetree, Dirk Behme,
Greg Kroah-Hartman, linux-kernel, Rob Herring, Linux-Renesas,
linux-samsung-soc, Simon Horman, Yangbo Lu, Pankaj Dubey,
linux-arm-kernel, Arnd Bergmann
On 10 November 2016 at 10:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Ulf,
>
> On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>>> >> > And Samsung.
>>> >> > Shall I create the immutable branch now?
>>> >>
>>> >> Arnd: are you happy with the new patches and changes?
>>> >
>>> > I still had some comments for patch 7, but that shouldn't stop
>>> > you from creating a branch for the first three so everyone can
>>> > build on top of that.
>>>
>>> Thanks!
>>>
>>> What about patch [4/7]?
>>> Haven't you received it? Your address was in the To-line for all 7 patches.
>>
>> Ok, I see it now, looks good. That should be included as well then.
>
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
>
> In the mean time, Ulf has applied the first two patches to mmc/next, on top
> of lots of MMC work :-(
No worries! :-)
>
> Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
> but also for Samsung and Renesas, would it still be possible to replace these
> two commits
>
> 8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
> 6fa350172b098f0f base: soc: Check for NULL SoC device attributes
>
> by a merge of soc-device-match-tag1?
Yes, I will take care of it during the day.
Kind regards
Uffe
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-10 10:59 ` Ulf Hansson
0 siblings, 0 replies; 59+ messages in thread
From: Ulf Hansson @ 2016-11-10 10:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev, Mark Rutland, devicetree, Dirk Behme,
Greg Kroah-Hartman, linux-kernel, Rob Herring, Linux-Renesas,
linux-samsung-soc, Simon Horman, Yangbo Lu, Pankaj Dubey,
linux-arm-kernel, Arnd Bergmann
On 10 November 2016 at 10:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Ulf,
>
> On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>>> >> > And Samsung.
>>> >> > Shall I create the immutable branch now?
>>> >>
>>> >> Arnd: are you happy with the new patches and changes?
>>> >
>>> > I still had some comments for patch 7, but that shouldn't stop
>>> > you from creating a branch for the first three so everyone can
>>> > build on top of that.
>>>
>>> Thanks!
>>>
>>> What about patch [4/7]?
>>> Haven't you received it? Your address was in the To-line for all 7 patches.
>>
>> Ok, I see it now, looks good. That should be included as well then.
>
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
>
> In the mean time, Ulf has applied the first two patches to mmc/next, on top
> of lots of MMC work :-(
No worries! :-)
>
> Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
> but also for Samsung and Renesas, would it still be possible to replace these
> two commits
>
> 8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
> 6fa350172b098f0f base: soc: Check for NULL SoC device attributes
>
> by a merge of soc-device-match-tag1?
Yes, I will take care of it during the day.
Kind regards
Uffe
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-10 10:59 ` Ulf Hansson
0 siblings, 0 replies; 59+ messages in thread
From: Ulf Hansson @ 2016-11-10 10:59 UTC (permalink / raw)
To: linux-arm-kernel
On 10 November 2016 at 10:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Ulf,
>
> On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>>> >> > And Samsung.
>>> >> > Shall I create the immutable branch now?
>>> >>
>>> >> Arnd: are you happy with the new patches and changes?
>>> >
>>> > I still had some comments for patch 7, but that shouldn't stop
>>> > you from creating a branch for the first three so everyone can
>>> > build on top of that.
>>>
>>> Thanks!
>>>
>>> What about patch [4/7]?
>>> Haven't you received it? Your address was in the To-line for all 7 patches.
>>
>> Ok, I see it now, looks good. That should be included as well then.
>
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
>
> In the mean time, Ulf has applied the first two patches to mmc/next, on top
> of lots of MMC work :-(
No worries! :-)
>
> Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
> but also for Samsung and Renesas, would it still be possible to replace these
> two commits
>
> 8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
> 6fa350172b098f0f base: soc: Check for NULL SoC device attributes
>
> by a merge of soc-device-match-tag1?
Yes, I will take care of it during the day.
Kind regards
Uffe
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
2016-11-10 10:19 ` Geert Uytterhoeven
(?)
@ 2016-11-10 11:37 ` Arnd Bergmann
-1 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-10 11:37 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev, Geert Uytterhoeven, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, devicetree,
Dirk Behme, linux-kernel, Linux-Renesas, linux-arm-kernel
On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> Hi Arnd,
>
> Thanks for your comments!
>
> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> v2:
> >> - Drop SoC families and family names; use fixed "Renesas" instead,
> >
> > I think I'd rather have seen the family names left in there, but it's
> > not important, so up to you.
>
> They're not useful for matching, as family names may change anytime, and don't
> always say much about the hardware capabilities.
> E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
> Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
> SuperH.
>
> At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
I think the marketing names are much more useful for humans looking
at the sysfs files than the kernel doing matching on, but both use
cases are important.
> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> available, else fall back to hardcoded addresses for compatibility
> >> with existing DTBs,
> >
> > I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
> > binding for these, among other things.
>
> I understand you've received them in the mean time?
Yes, I found them in my inbox later, not sure why I didn't see them
at first.
> > It does seem wrong to have a device node for a specific register though.
> > Shouldn't the node be for the block of registers that these are inside
> > of?
>
> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
It just seems odd to have it at address 0xff000044 when all the other
devices are at page-aligned addresses. Do you mean that accessing
0xff000040 or 0xff000048 will result in a bus-level exception for a
missing register and just 0xff000044 is actually valid for access,
or is it just the only thing that is documented?
> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
> we further don't touch at all.
> On R-Car Gen2, it's not documented, but does exist.
This is where the family names would come in handy ;-) I now have
no idea which chip(s) you are referring to.
If you know the name of the register block, just put it into DT with
that name. The driver can trivially add the right offset.
> >> - Don't register the SoC bus if the chip ID register is missing,
> >
> > Why? My objection was to hardcoding the register, not to registering
> > the device? I think I'd rather see the device registered with an
> > empty revision string.
>
> If there's no chip ID register, there's no reason to use soc_device_match(),
> as we can always look at a compatible value. All SoCs listed in this driver
> have a chip ID register.
But you may still have user space tools looking into sysfs, e.g. to
figure out how to install a kernel that the boot loader can find,
or which hardware specific distro packages to install.
> if you want me to register the soc_bus for those SoCs regardless, I want to
> re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
> registers ;-)
Right. Just don't encode too much knowledge about the SoCs into the
driver, so we are prepared for adding new ones: We should still look
for the registers in DT on all chips.
> >> +#define CCCR 0xe600101c /* Common Chip Code Register */
> >> +#define PRR 0xff000044 /* Product Register */
> >> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
> >> +
> >> +static const struct of_device_id renesas_socs[] __initconst = {
> >> +#ifdef CONFIG_ARCH_R8A73A4
> >> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
> >> +#endif
> >> +#ifdef CONFIG_ARCH_R8A7740
> >> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
> >> +#endif
> >
> > My preference here would be to list the register address only for
> > SoCs that are known to need them, while also having .dtb files that
> > don't have the nodes.
>
> Even if drivers don't have to handle differences, there's been a long
> outstanding request to print SoC revision information during bootup
> (E.g. "Does it still work on ES1.0?"). Hence that covers all SoCs.
Ok, fair enough.
> >> +static int __init renesas_soc_init(void)
> >> +{
> >> + struct soc_device_attribute *soc_dev_attr;
> >> + const struct of_device_id *match;
> >> + void __iomem *chipid = NULL;
> >> + struct soc_device *soc_dev;
> >> + struct device_node *np;
> >> + unsigned int product;
> >> +
> >> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
> >> + if (!np)
> >> + return -ENODEV;
> >> +
> >> + of_node_put(np);
> >> +
> >> + /* Try PRR first, then CCCR, then hardcoded fallback */
> >> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
> >> + if (!np)
> >> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
> >> + if (np) {
> >> + chipid = of_iomap(np, 0);
> >> + of_node_put(np);
> >> + } else if (match->data) {
> >> + chipid = ioremap((uintptr_t)match->data, 4);
> >> + }
> >> + if (!chipid)
> >>
> >
> > Here, I'd turn the order around and look for the DT nodes of the
> > devices first. Only if they are not found, look at the compatible
> > string of the root node. No need to search for a node though,
> > you know which one it is when you look for a compatible =
> > "renesas,r8a73a4".
>
> "renesas,r8a73a4" is the root node, not the device, so it does not have the
> "reg" property for reading the chip ID?
I mean replace of_find_matching_node_and_match() with
of_match_node(renesas_socs, of_root).
It does the same thing, just more efficiently.
> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> Hence I always need to look at the root nodes.
Not sure what that would protect you from. Could you have a renesas,cccr
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-10 11:37 ` Arnd Bergmann
0 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-10 11:37 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev, Geert Uytterhoeven, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, devicetree,
Dirk Behme, linux-kernel, Linux-Renesas, linux-arm-kernel
On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> Hi Arnd,
>
> Thanks for your comments!
>
> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> v2:
> >> - Drop SoC families and family names; use fixed "Renesas" instead,
> >
> > I think I'd rather have seen the family names left in there, but it's
> > not important, so up to you.
>
> They're not useful for matching, as family names may change anytime, and don't
> always say much about the hardware capabilities.
> E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
> Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
> SuperH.
>
> At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
I think the marketing names are much more useful for humans looking
at the sysfs files than the kernel doing matching on, but both use
cases are important.
> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> available, else fall back to hardcoded addresses for compatibility
> >> with existing DTBs,
> >
> > I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
> > binding for these, among other things.
>
> I understand you've received them in the mean time?
Yes, I found them in my inbox later, not sure why I didn't see them
at first.
> > It does seem wrong to have a device node for a specific register though.
> > Shouldn't the node be for the block of registers that these are inside
> > of?
>
> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
It just seems odd to have it at address 0xff000044 when all the other
devices are at page-aligned addresses. Do you mean that accessing
0xff000040 or 0xff000048 will result in a bus-level exception for a
missing register and just 0xff000044 is actually valid for access,
or is it just the only thing that is documented?
> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
> we further don't touch at all.
> On R-Car Gen2, it's not documented, but does exist.
This is where the family names would come in handy ;-) I now have
no idea which chip(s) you are referring to.
If you know the name of the register block, just put it into DT with
that name. The driver can trivially add the right offset.
> >> - Don't register the SoC bus if the chip ID register is missing,
> >
> > Why? My objection was to hardcoding the register, not to registering
> > the device? I think I'd rather see the device registered with an
> > empty revision string.
>
> If there's no chip ID register, there's no reason to use soc_device_match(),
> as we can always look at a compatible value. All SoCs listed in this driver
> have a chip ID register.
But you may still have user space tools looking into sysfs, e.g. to
figure out how to install a kernel that the boot loader can find,
or which hardware specific distro packages to install.
> if you want me to register the soc_bus for those SoCs regardless, I want to
> re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
> registers ;-)
Right. Just don't encode too much knowledge about the SoCs into the
driver, so we are prepared for adding new ones: We should still look
for the registers in DT on all chips.
> >> +#define CCCR 0xe600101c /* Common Chip Code Register */
> >> +#define PRR 0xff000044 /* Product Register */
> >> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
> >> +
> >> +static const struct of_device_id renesas_socs[] __initconst = {
> >> +#ifdef CONFIG_ARCH_R8A73A4
> >> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
> >> +#endif
> >> +#ifdef CONFIG_ARCH_R8A7740
> >> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
> >> +#endif
> >
> > My preference here would be to list the register address only for
> > SoCs that are known to need them, while also having .dtb files that
> > don't have the nodes.
>
> Even if drivers don't have to handle differences, there's been a long
> outstanding request to print SoC revision information during bootup
> (E.g. "Does it still work on ES1.0?"). Hence that covers all SoCs.
Ok, fair enough.
> >> +static int __init renesas_soc_init(void)
> >> +{
> >> + struct soc_device_attribute *soc_dev_attr;
> >> + const struct of_device_id *match;
> >> + void __iomem *chipid = NULL;
> >> + struct soc_device *soc_dev;
> >> + struct device_node *np;
> >> + unsigned int product;
> >> +
> >> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
> >> + if (!np)
> >> + return -ENODEV;
> >> +
> >> + of_node_put(np);
> >> +
> >> + /* Try PRR first, then CCCR, then hardcoded fallback */
> >> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
> >> + if (!np)
> >> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
> >> + if (np) {
> >> + chipid = of_iomap(np, 0);
> >> + of_node_put(np);
> >> + } else if (match->data) {
> >> + chipid = ioremap((uintptr_t)match->data, 4);
> >> + }
> >> + if (!chipid)
> >>
> >
> > Here, I'd turn the order around and look for the DT nodes of the
> > devices first. Only if they are not found, look at the compatible
> > string of the root node. No need to search for a node though,
> > you know which one it is when you look for a compatible =
> > "renesas,r8a73a4".
>
> "renesas,r8a73a4" is the root node, not the device, so it does not have the
> "reg" property for reading the chip ID?
I mean replace of_find_matching_node_and_match() with
of_match_node(renesas_socs, of_root).
It does the same thing, just more efficiently.
> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> Hence I always need to look at the root nodes.
Not sure what that would protect you from. Could you have a renesas,cccr
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-10 11:37 ` Arnd Bergmann
0 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-10 11:37 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> Hi Arnd,
>
> Thanks for your comments!
>
> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> v2:
> >> - Drop SoC families and family names; use fixed "Renesas" instead,
> >
> > I think I'd rather have seen the family names left in there, but it's
> > not important, so up to you.
>
> They're not useful for matching, as family names may change anytime, and don't
> always say much about the hardware capabilities.
> E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
> Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
> SuperH.
>
> At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
I think the marketing names are much more useful for humans looking
at the sysfs files than the kernel doing matching on, but both use
cases are important.
> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> available, else fall back to hardcoded addresses for compatibility
> >> with existing DTBs,
> >
> > I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
> > binding for these, among other things.
>
> I understand you've received them in the mean time?
Yes, I found them in my inbox later, not sure why I didn't see them
at first.
> > It does seem wrong to have a device node for a specific register though.
> > Shouldn't the node be for the block of registers that these are inside
> > of?
>
> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
It just seems odd to have it at address 0xff000044 when all the other
devices are at page-aligned addresses. Do you mean that accessing
0xff000040 or 0xff000048 will result in a bus-level exception for a
missing register and just 0xff000044 is actually valid for access,
or is it just the only thing that is documented?
> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
> we further don't touch at all.
> On R-Car Gen2, it's not documented, but does exist.
This is where the family names would come in handy ;-) I now have
no idea which chip(s) you are referring to.
If you know the name of the register block, just put it into DT with
that name. The driver can trivially add the right offset.
> >> - Don't register the SoC bus if the chip ID register is missing,
> >
> > Why? My objection was to hardcoding the register, not to registering
> > the device? I think I'd rather see the device registered with an
> > empty revision string.
>
> If there's no chip ID register, there's no reason to use soc_device_match(),
> as we can always look at a compatible value. All SoCs listed in this driver
> have a chip ID register.
But you may still have user space tools looking into sysfs, e.g. to
figure out how to install a kernel that the boot loader can find,
or which hardware specific distro packages to install.
> if you want me to register the soc_bus for those SoCs regardless, I want to
> re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
> registers ;-)
Right. Just don't encode too much knowledge about the SoCs into the
driver, so we are prepared for adding new ones: We should still look
for the registers in DT on all chips.
> >> +#define CCCR 0xe600101c /* Common Chip Code Register */
> >> +#define PRR 0xff000044 /* Product Register */
> >> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
> >> +
> >> +static const struct of_device_id renesas_socs[] __initconst = {
> >> +#ifdef CONFIG_ARCH_R8A73A4
> >> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
> >> +#endif
> >> +#ifdef CONFIG_ARCH_R8A7740
> >> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
> >> +#endif
> >
> > My preference here would be to list the register address only for
> > SoCs that are known to need them, while also having .dtb files that
> > don't have the nodes.
>
> Even if drivers don't have to handle differences, there's been a long
> outstanding request to print SoC revision information during bootup
> (E.g. "Does it still work on ES1.0?"). Hence that covers all SoCs.
Ok, fair enough.
> >> +static int __init renesas_soc_init(void)
> >> +{
> >> + struct soc_device_attribute *soc_dev_attr;
> >> + const struct of_device_id *match;
> >> + void __iomem *chipid = NULL;
> >> + struct soc_device *soc_dev;
> >> + struct device_node *np;
> >> + unsigned int product;
> >> +
> >> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
> >> + if (!np)
> >> + return -ENODEV;
> >> +
> >> + of_node_put(np);
> >> +
> >> + /* Try PRR first, then CCCR, then hardcoded fallback */
> >> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
> >> + if (!np)
> >> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
> >> + if (np) {
> >> + chipid = of_iomap(np, 0);
> >> + of_node_put(np);
> >> + } else if (match->data) {
> >> + chipid = ioremap((uintptr_t)match->data, 4);
> >> + }
> >> + if (!chipid)
> >>
> >
> > Here, I'd turn the order around and look for the DT nodes of the
> > devices first. Only if they are not found, look at the compatible
> > string of the root node. No need to search for a node though,
> > you know which one it is when you look for a compatible =
> > "renesas,r8a73a4".
>
> "renesas,r8a73a4" is the root node, not the device, so it does not have the
> "reg" property for reading the chip ID?
I mean replace of_find_matching_node_and_match() with
of_match_node(renesas_socs, of_root).
It does the same thing, just more efficiently.
> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> Hence I always need to look at the root nodes.
Not sure what that would protect you from. Could you have a renesas,cccr
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
2016-11-10 11:37 ` Arnd Bergmann
(?)
@ 2016-11-14 10:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-14 10:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Geert Uytterhoeven, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, devicetree,
Dirk Behme, linux-kernel, Linux-Renesas, linux-arm-kernel
Hi Arnd,
On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> >> v2:
>> >> - Drop SoC families and family names; use fixed "Renesas" instead,
>> >
>> > I think I'd rather have seen the family names left in there, but it's
>> > not important, so up to you.
>>
>> They're not useful for matching, as family names may change anytime, and don't
>> always say much about the hardware capabilities.
>> E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
>> Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
>> SuperH.
>>
>> At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>
> I think the marketing names are much more useful for humans looking
> at the sysfs files than the kernel doing matching on, but both use
> cases are important.
OK, I'll re-add the family names for humans reading sysfs.
>> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> >> available, else fall back to hardcoded addresses for compatibility
>> >> with existing DTBs,
>> > It does seem wrong to have a device node for a specific register though.
>> > Shouldn't the node be for the block of registers that these are inside
>> > of?
>>
>> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
>> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
>
> It just seems odd to have it at address 0xff000044 when all the other
> devices are at page-aligned addresses. Do you mean that accessing
> 0xff000040 or 0xff000048 will result in a bus-level exception for a
> missing register and just 0xff000044 is actually valid for access,
> or is it just the only thing that is documented?
For PRR, all other registers in the page read as all zeroes on all SoCs that
have it. So it really is a lone register.
>> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
>> we further don't touch at all.
>> On R-Car Gen2, it's not documented, but does exist.
>
> This is where the family names would come in handy ;-) I now have
> no idea which chip(s) you are referring to.
SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
R-Car Gen2 are r8a779[0-4].
> If you know the name of the register block, just put it into DT with
> that name. The driver can trivially add the right offset.
CCCR is different. The amount of registers that read as non-zero depends a lot
on the actual SoC.
HPB/APB is gonna need real DT bindings, which needs some more investigation.
Hence if you don't mind, I'd like to postpone that part, which only affects
the older SoCs. And I'll drop the "renesas,cccr" binding.
For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
waiting for this support. So I'd like to have that dependency in v4.10.
>> >> - Don't register the SoC bus if the chip ID register is missing,
>> >
>> > Why? My objection was to hardcoding the register, not to registering
>> > the device? I think I'd rather see the device registered with an
>> > empty revision string.
>>
>> If there's no chip ID register, there's no reason to use soc_device_match(),
>> as we can always look at a compatible value. All SoCs listed in this driver
>> have a chip ID register.
>
> But you may still have user space tools looking into sysfs, e.g. to
> figure out how to install a kernel that the boot loader can find,
> or which hardware specific distro packages to install.
>
>> if you want me to register the soc_bus for those SoCs regardless, I want to
>> re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
>> registers ;-)
>
> Right. Just don't encode too much knowledge about the SoCs into the
> driver, so we are prepared for adding new ones: We should still look
> for the registers in DT on all chips.
OK, will re-add.
>> >> +static int __init renesas_soc_init(void)
>> >> +{
>> >> + struct soc_device_attribute *soc_dev_attr;
>> >> + const struct of_device_id *match;
>> >> + void __iomem *chipid = NULL;
>> >> + struct soc_device *soc_dev;
>> >> + struct device_node *np;
>> >> + unsigned int product;
>> >> +
>> >> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> >> + if (!np)
>> >> + return -ENODEV;
>> >> +
>> >> + of_node_put(np);
>> >> +
>> >> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> >> + if (!np)
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> >> + if (np) {
>> >> + chipid = of_iomap(np, 0);
>> >> + of_node_put(np);
>> >> + } else if (match->data) {
>> >> + chipid = ioremap((uintptr_t)match->data, 4);
>> >> + }
>> >> + if (!chipid)
>> >>
>> >
>> > Here, I'd turn the order around and look for the DT nodes of the
>> > devices first. Only if they are not found, look at the compatible
>> > string of the root node. No need to search for a node though,
>> > you know which one it is when you look for a compatible =
>> > "renesas,r8a73a4".
>>
>> "renesas,r8a73a4" is the root node, not the device, so it does not have the
>> "reg" property for reading the chip ID?
>
> I mean replace of_find_matching_node_and_match() with
> of_match_node(renesas_socs, of_root).
>
> It does the same thing, just more efficiently.
OK (didn't know "of_root" was available for public use ;-)
>> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
>> Hence I always need to look at the root nodes.
>
> Not sure what that would protect you from. Could you have a renesas,cccr
Looks like you forgot to finish your sentence?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-14 10:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-14 10:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Geert Uytterhoeven, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, devicetree,
Dirk Behme, linux-kernel, Linux-Renesas, linux-arm-kernel
Hi Arnd,
On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> >> v2:
>> >> - Drop SoC families and family names; use fixed "Renesas" instead,
>> >
>> > I think I'd rather have seen the family names left in there, but it's
>> > not important, so up to you.
>>
>> They're not useful for matching, as family names may change anytime, and don't
>> always say much about the hardware capabilities.
>> E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
>> Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
>> SuperH.
>>
>> At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>
> I think the marketing names are much more useful for humans looking
> at the sysfs files than the kernel doing matching on, but both use
> cases are important.
OK, I'll re-add the family names for humans reading sysfs.
>> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> >> available, else fall back to hardcoded addresses for compatibility
>> >> with existing DTBs,
>> > It does seem wrong to have a device node for a specific register though.
>> > Shouldn't the node be for the block of registers that these are inside
>> > of?
>>
>> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
>> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
>
> It just seems odd to have it at address 0xff000044 when all the other
> devices are at page-aligned addresses. Do you mean that accessing
> 0xff000040 or 0xff000048 will result in a bus-level exception for a
> missing register and just 0xff000044 is actually valid for access,
> or is it just the only thing that is documented?
For PRR, all other registers in the page read as all zeroes on all SoCs that
have it. So it really is a lone register.
>> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
>> we further don't touch at all.
>> On R-Car Gen2, it's not documented, but does exist.
>
> This is where the family names would come in handy ;-) I now have
> no idea which chip(s) you are referring to.
SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
R-Car Gen2 are r8a779[0-4].
> If you know the name of the register block, just put it into DT with
> that name. The driver can trivially add the right offset.
CCCR is different. The amount of registers that read as non-zero depends a lot
on the actual SoC.
HPB/APB is gonna need real DT bindings, which needs some more investigation.
Hence if you don't mind, I'd like to postpone that part, which only affects
the older SoCs. And I'll drop the "renesas,cccr" binding.
For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
waiting for this support. So I'd like to have that dependency in v4.10.
>> >> - Don't register the SoC bus if the chip ID register is missing,
>> >
>> > Why? My objection was to hardcoding the register, not to registering
>> > the device? I think I'd rather see the device registered with an
>> > empty revision string.
>>
>> If there's no chip ID register, there's no reason to use soc_device_match(),
>> as we can always look at a compatible value. All SoCs listed in this driver
>> have a chip ID register.
>
> But you may still have user space tools looking into sysfs, e.g. to
> figure out how to install a kernel that the boot loader can find,
> or which hardware specific distro packages to install.
>
>> if you want me to register the soc_bus for those SoCs regardless, I want to
>> re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
>> registers ;-)
>
> Right. Just don't encode too much knowledge about the SoCs into the
> driver, so we are prepared for adding new ones: We should still look
> for the registers in DT on all chips.
OK, will re-add.
>> >> +static int __init renesas_soc_init(void)
>> >> +{
>> >> + struct soc_device_attribute *soc_dev_attr;
>> >> + const struct of_device_id *match;
>> >> + void __iomem *chipid = NULL;
>> >> + struct soc_device *soc_dev;
>> >> + struct device_node *np;
>> >> + unsigned int product;
>> >> +
>> >> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> >> + if (!np)
>> >> + return -ENODEV;
>> >> +
>> >> + of_node_put(np);
>> >> +
>> >> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> >> + if (!np)
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> >> + if (np) {
>> >> + chipid = of_iomap(np, 0);
>> >> + of_node_put(np);
>> >> + } else if (match->data) {
>> >> + chipid = ioremap((uintptr_t)match->data, 4);
>> >> + }
>> >> + if (!chipid)
>> >>
>> >
>> > Here, I'd turn the order around and look for the DT nodes of the
>> > devices first. Only if they are not found, look at the compatible
>> > string of the root node. No need to search for a node though,
>> > you know which one it is when you look for a compatible =
>> > "renesas,r8a73a4".
>>
>> "renesas,r8a73a4" is the root node, not the device, so it does not have the
>> "reg" property for reading the chip ID?
>
> I mean replace of_find_matching_node_and_match() with
> of_match_node(renesas_socs, of_root).
>
> It does the same thing, just more efficiently.
OK (didn't know "of_root" was available for public use ;-)
>> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
>> Hence I always need to look at the root nodes.
>
> Not sure what that would protect you from. Could you have a renesas,cccr
Looks like you forgot to finish your sentence?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-14 10:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 59+ messages in thread
From: Geert Uytterhoeven @ 2016-11-14 10:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> >> v2:
>> >> - Drop SoC families and family names; use fixed "Renesas" instead,
>> >
>> > I think I'd rather have seen the family names left in there, but it's
>> > not important, so up to you.
>>
>> They're not useful for matching, as family names may change anytime, and don't
>> always say much about the hardware capabilities.
>> E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
>> Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
>> SuperH.
>>
>> At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>
> I think the marketing names are much more useful for humans looking
> at the sysfs files than the kernel doing matching on, but both use
> cases are important.
OK, I'll re-add the family names for humans reading sysfs.
>> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> >> available, else fall back to hardcoded addresses for compatibility
>> >> with existing DTBs,
>> > It does seem wrong to have a device node for a specific register though.
>> > Shouldn't the node be for the block of registers that these are inside
>> > of?
>>
>> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
>> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
>
> It just seems odd to have it at address 0xff000044 when all the other
> devices are at page-aligned addresses. Do you mean that accessing
> 0xff000040 or 0xff000048 will result in a bus-level exception for a
> missing register and just 0xff000044 is actually valid for access,
> or is it just the only thing that is documented?
For PRR, all other registers in the page read as all zeroes on all SoCs that
have it. So it really is a lone register.
>> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
>> we further don't touch at all.
>> On R-Car Gen2, it's not documented, but does exist.
>
> This is where the family names would come in handy ;-) I now have
> no idea which chip(s) you are referring to.
SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
R-Car Gen2 are r8a779[0-4].
> If you know the name of the register block, just put it into DT with
> that name. The driver can trivially add the right offset.
CCCR is different. The amount of registers that read as non-zero depends a lot
on the actual SoC.
HPB/APB is gonna need real DT bindings, which needs some more investigation.
Hence if you don't mind, I'd like to postpone that part, which only affects
the older SoCs. And I'll drop the "renesas,cccr" binding.
For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
waiting for this support. So I'd like to have that dependency in v4.10.
>> >> - Don't register the SoC bus if the chip ID register is missing,
>> >
>> > Why? My objection was to hardcoding the register, not to registering
>> > the device? I think I'd rather see the device registered with an
>> > empty revision string.
>>
>> If there's no chip ID register, there's no reason to use soc_device_match(),
>> as we can always look at a compatible value. All SoCs listed in this driver
>> have a chip ID register.
>
> But you may still have user space tools looking into sysfs, e.g. to
> figure out how to install a kernel that the boot loader can find,
> or which hardware specific distro packages to install.
>
>> if you want me to register the soc_bus for those SoCs regardless, I want to
>> re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
>> registers ;-)
>
> Right. Just don't encode too much knowledge about the SoCs into the
> driver, so we are prepared for adding new ones: We should still look
> for the registers in DT on all chips.
OK, will re-add.
>> >> +static int __init renesas_soc_init(void)
>> >> +{
>> >> + struct soc_device_attribute *soc_dev_attr;
>> >> + const struct of_device_id *match;
>> >> + void __iomem *chipid = NULL;
>> >> + struct soc_device *soc_dev;
>> >> + struct device_node *np;
>> >> + unsigned int product;
>> >> +
>> >> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> >> + if (!np)
>> >> + return -ENODEV;
>> >> +
>> >> + of_node_put(np);
>> >> +
>> >> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> >> + if (!np)
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> >> + if (np) {
>> >> + chipid = of_iomap(np, 0);
>> >> + of_node_put(np);
>> >> + } else if (match->data) {
>> >> + chipid = ioremap((uintptr_t)match->data, 4);
>> >> + }
>> >> + if (!chipid)
>> >>
>> >
>> > Here, I'd turn the order around and look for the DT nodes of the
>> > devices first. Only if they are not found, look at the compatible
>> > string of the root node. No need to search for a node though,
>> > you know which one it is when you look for a compatible =
>> > "renesas,r8a73a4".
>>
>> "renesas,r8a73a4" is the root node, not the device, so it does not have the
>> "reg" property for reading the chip ID?
>
> I mean replace of_find_matching_node_and_match() with
> of_match_node(renesas_socs, of_root).
>
> It does the same thing, just more efficiently.
OK (didn't know "of_root" was available for public use ;-)
>> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
>> Hence I always need to look at the root nodes.
>
> Not sure what that would protect you from. Could you have a renesas,cccr
Looks like you forgot to finish your sentence?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
2016-11-14 10:51 ` Geert Uytterhoeven
(?)
@ 2016-11-14 11:22 ` Arnd Bergmann
-1 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-14 11:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev, Geert Uytterhoeven, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, devicetree,
Dirk Behme, linux-kernel, Linux-Renesas, linux-arm-kernel
On Monday, November 14, 2016 11:51:15 AM CET Geert Uytterhoeven wrote:
> On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> >> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> >> available, else fall back to hardcoded addresses for compatibility
> >> >> with existing DTBs,
>
> >> > It does seem wrong to have a device node for a specific register though.
> >> > Shouldn't the node be for the block of registers that these are inside
> >> > of?
> >>
> >> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> >> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
> >
> > It just seems odd to have it at address 0xff000044 when all the other
> > devices are at page-aligned addresses. Do you mean that accessing
> > 0xff000040 or 0xff000048 will result in a bus-level exception for a
> > missing register and just 0xff000044 is actually valid for access,
> > or is it just the only thing that is documented?
>
> For PRR, all other registers in the page read as all zeroes on all SoCs that
> have it. So it really is a lone register.
Ok.
> >> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
> >> we further don't touch at all.
> >> On R-Car Gen2, it's not documented, but does exist.
> >
> > This is where the family names would come in handy ;-) I now have
> > no idea which chip(s) you are referring to.
>
> SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
> R-Car Gen2 are r8a779[0-4].
>
> > If you know the name of the register block, just put it into DT with
> > that name. The driver can trivially add the right offset.
>
> CCCR is different. The amount of registers that read as non-zero depends a lot
> on the actual SoC.
>
> HPB/APB is gonna need real DT bindings, which needs some more investigation.
> Hence if you don't mind, I'd like to postpone that part, which only affects
> the older SoCs. And I'll drop the "renesas,cccr" binding.
>
> For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
> most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
> waiting for this support. So I'd like to have that dependency in v4.10.
Ok, sounds good.
> >> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> >> Hence I always need to look at the root nodes.
> >
> > Not sure what that would protect you from. Could you have a renesas,cccr
>
> Looks like you forgot to finish your sentence?
Yes, and I forgot what I was going to say there now. It's probably covered
by what we discussed above.
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-14 11:22 ` Arnd Bergmann
0 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-14 11:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev, Geert Uytterhoeven, Greg Kroah-Hartman, Yangbo Lu,
Simon Horman, Magnus Damm, Rob Herring, Mark Rutland, devicetree,
Dirk Behme, linux-kernel, Linux-Renesas, linux-arm-kernel
On Monday, November 14, 2016 11:51:15 AM CET Geert Uytterhoeven wrote:
> On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> >> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> >> available, else fall back to hardcoded addresses for compatibility
> >> >> with existing DTBs,
>
> >> > It does seem wrong to have a device node for a specific register though.
> >> > Shouldn't the node be for the block of registers that these are inside
> >> > of?
> >>
> >> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> >> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
> >
> > It just seems odd to have it at address 0xff000044 when all the other
> > devices are at page-aligned addresses. Do you mean that accessing
> > 0xff000040 or 0xff000048 will result in a bus-level exception for a
> > missing register and just 0xff000044 is actually valid for access,
> > or is it just the only thing that is documented?
>
> For PRR, all other registers in the page read as all zeroes on all SoCs that
> have it. So it really is a lone register.
Ok.
> >> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
> >> we further don't touch at all.
> >> On R-Car Gen2, it's not documented, but does exist.
> >
> > This is where the family names would come in handy ;-) I now have
> > no idea which chip(s) you are referring to.
>
> SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
> R-Car Gen2 are r8a779[0-4].
>
> > If you know the name of the register block, just put it into DT with
> > that name. The driver can trivially add the right offset.
>
> CCCR is different. The amount of registers that read as non-zero depends a lot
> on the actual SoC.
>
> HPB/APB is gonna need real DT bindings, which needs some more investigation.
> Hence if you don't mind, I'd like to postpone that part, which only affects
> the older SoCs. And I'll drop the "renesas,cccr" binding.
>
> For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
> most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
> waiting for this support. So I'd like to have that dependency in v4.10.
Ok, sounds good.
> >> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> >> Hence I always need to look at the root nodes.
> >
> > Not sure what that would protect you from. Could you have a renesas,cccr
>
> Looks like you forgot to finish your sentence?
Yes, and I forgot what I was going to say there now. It's probably covered
by what we discussed above.
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
@ 2016-11-14 11:22 ` Arnd Bergmann
0 siblings, 0 replies; 59+ messages in thread
From: Arnd Bergmann @ 2016-11-14 11:22 UTC (permalink / raw)
To: linux-arm-kernel
On Monday, November 14, 2016 11:51:15 AM CET Geert Uytterhoeven wrote:
> On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> >> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> >> available, else fall back to hardcoded addresses for compatibility
> >> >> with existing DTBs,
>
> >> > It does seem wrong to have a device node for a specific register though.
> >> > Shouldn't the node be for the block of registers that these are inside
> >> > of?
> >>
> >> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> >> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
> >
> > It just seems odd to have it at address 0xff000044 when all the other
> > devices are at page-aligned addresses. Do you mean that accessing
> > 0xff000040 or 0xff000048 will result in a bus-level exception for a
> > missing register and just 0xff000044 is actually valid for access,
> > or is it just the only thing that is documented?
>
> For PRR, all other registers in the page read as all zeroes on all SoCs that
> have it. So it really is a lone register.
Ok.
> >> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
> >> we further don't touch at all.
> >> On R-Car Gen2, it's not documented, but does exist.
> >
> > This is where the family names would come in handy ;-) I now have
> > no idea which chip(s) you are referring to.
>
> SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
> R-Car Gen2 are r8a779[0-4].
>
> > If you know the name of the register block, just put it into DT with
> > that name. The driver can trivially add the right offset.
>
> CCCR is different. The amount of registers that read as non-zero depends a lot
> on the actual SoC.
>
> HPB/APB is gonna need real DT bindings, which needs some more investigation.
> Hence if you don't mind, I'd like to postpone that part, which only affects
> the older SoCs. And I'll drop the "renesas,cccr" binding.
>
> For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
> most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
> waiting for this support. So I'd like to have that dependency in v4.10.
Ok, sounds good.
> >> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> >> Hence I always need to look at the root nodes.
> >
> > Not sure what that would protect you from. Could you have a renesas,cccr
>
> Looks like you forgot to finish your sentence?
Yes, and I forgot what I was going to say there now. It's probably covered
by what we discussed above.
Arnd
^ permalink raw reply [flat|nested] 59+ messages in thread
end of thread, other threads:[~2016-11-14 11:23 UTC | newest]
Thread overview: 59+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-31 11:30 [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus Geert Uytterhoeven
2016-10-31 11:30 ` Geert Uytterhoeven
2016-10-31 11:30 ` [PATCH v2 1/7] base: soc: Early register bus when needed Geert Uytterhoeven
2016-10-31 11:30 ` [PATCH v2 2/7] base: soc: Introduce soc_device_match() interface Geert Uytterhoeven
2016-10-31 11:30 ` [PATCH v2 3/7] base: soc: Check for NULL SoC device attributes Geert Uytterhoeven
2016-10-31 11:30 ` Geert Uytterhoeven
2016-10-31 11:30 ` [PATCH v2 4/7] base: soc: Provide a dummy implementation of soc_device_match() Geert Uytterhoeven
2016-10-31 11:30 ` [PATCH v2 5/7] ARM: shmobile: Document DT bindings for CCCR and PRR Geert Uytterhoeven
2016-10-31 11:30 ` Geert Uytterhoeven
2016-11-09 18:24 ` Rob Herring
2016-11-09 18:24 ` Rob Herring
2016-11-09 18:24 ` Rob Herring
2016-10-31 11:30 ` [PATCH v2 6/7] arm64: dts: r8a7795: Add device node for PRR Geert Uytterhoeven
2016-10-31 11:30 ` [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus Geert Uytterhoeven
2016-10-31 11:30 ` Geert Uytterhoeven
2016-11-09 16:55 ` Arnd Bergmann
2016-11-09 16:55 ` Arnd Bergmann
2016-11-10 10:19 ` Geert Uytterhoeven
2016-11-10 10:19 ` Geert Uytterhoeven
2016-11-10 10:19 ` Geert Uytterhoeven
2016-11-10 11:37 ` Arnd Bergmann
2016-11-10 11:37 ` Arnd Bergmann
2016-11-10 11:37 ` Arnd Bergmann
2016-11-14 10:51 ` Geert Uytterhoeven
2016-11-14 10:51 ` Geert Uytterhoeven
2016-11-14 10:51 ` Geert Uytterhoeven
2016-11-14 11:22 ` Arnd Bergmann
2016-11-14 11:22 ` Arnd Bergmann
2016-11-14 11:22 ` Arnd Bergmann
2016-11-07 9:35 ` [PATCH v2 0/7] " Geert Uytterhoeven
2016-11-07 9:35 ` Geert Uytterhoeven
2016-11-07 9:35 ` Geert Uytterhoeven
2016-11-07 18:33 ` Krzysztof Kozlowski
2016-11-07 18:33 ` Krzysztof Kozlowski
2016-11-07 18:33 ` Krzysztof Kozlowski
2016-11-07 18:33 ` Krzysztof Kozlowski
2016-11-09 13:34 ` Geert Uytterhoeven
2016-11-09 13:34 ` Geert Uytterhoeven
2016-11-09 13:34 ` Geert Uytterhoeven
2016-11-09 16:56 ` Arnd Bergmann
2016-11-09 16:56 ` Arnd Bergmann
2016-11-09 16:56 ` Arnd Bergmann
2016-11-09 16:56 ` Arnd Bergmann
2016-11-09 17:19 ` Geert Uytterhoeven
2016-11-09 17:19 ` Geert Uytterhoeven
2016-11-09 17:19 ` Geert Uytterhoeven
2016-11-09 21:12 ` Arnd Bergmann
2016-11-09 21:12 ` Arnd Bergmann
2016-11-09 21:12 ` Arnd Bergmann
2016-11-10 9:22 ` Geert Uytterhoeven
2016-11-10 9:22 ` Geert Uytterhoeven
2016-11-10 9:22 ` Geert Uytterhoeven
2016-11-10 9:22 ` Geert Uytterhoeven
2016-11-10 10:56 ` Geert Uytterhoeven
2016-11-10 10:56 ` Geert Uytterhoeven
2016-11-10 10:56 ` Geert Uytterhoeven
2016-11-10 10:59 ` Ulf Hansson
2016-11-10 10:59 ` Ulf Hansson
2016-11-10 10:59 ` Ulf Hansson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.