[PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Kevin Hilman]

On ARM platforms, power management can be very platform specific.
This patch allows ARM subarches to extend the platform_device
pdev_archdata for each subarch by creating a new struct pdev_machdata
and allowing each subarch to customize it as needed.

As a starting point, each subarch's <mach/device.h> creates an empty
struct pdev_machdata.

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
Applies against Linus' current master branch and is a follow up
to : 

commit d7aacaddcac3971e33cf52d7e610c06696cb347f
Author: Magnus Damm <damm@igel.co.jp>
Date:   Wed Jul 8 13:21:31 2009 +0200

    Driver Core: Add platform device arch data V3
    
    Allow architecture specific data in struct platform_device V3.
    [...]

 arch/arm/include/asm/device.h                  |    3 +++
 arch/arm/mach-aaec2000/include/mach/device.h   |   12 ++++++++++++
 arch/arm/mach-at91/include/mach/device.h       |   12 ++++++++++++
 arch/arm/mach-bcmring/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-clps711x/include/mach/device.h   |   12 ++++++++++++
 arch/arm/mach-davinci/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-ebsa110/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-ep93xx/include/mach/device.h     |   12 ++++++++++++
 arch/arm/mach-footbridge/include/mach/device.h |   12 ++++++++++++
 arch/arm/mach-gemini/include/mach/device.h     |   12 ++++++++++++
 arch/arm/mach-h720x/include/mach/device.h      |   12 ++++++++++++
 arch/arm/mach-integrator/include/mach/device.h |   12 ++++++++++++
 arch/arm/mach-iop13xx/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-iop32x/include/mach/device.h     |   12 ++++++++++++
 arch/arm/mach-iop33x/include/mach/device.h     |   12 ++++++++++++
 arch/arm/mach-ixp2000/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-ixp23xx/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-ixp4xx/include/mach/device.h     |   12 ++++++++++++
 arch/arm/mach-kirkwood/include/mach/device.h   |   12 ++++++++++++
 arch/arm/mach-ks8695/include/mach/device.h     |   12 ++++++++++++
 arch/arm/mach-l7200/include/mach/device.h      |   12 ++++++++++++
 arch/arm/mach-lh7a40x/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-loki/include/mach/device.h       |   12 ++++++++++++
 arch/arm/mach-mmp/include/mach/device.h        |   12 ++++++++++++
 arch/arm/mach-msm/include/mach/device.h        |   12 ++++++++++++
 arch/arm/mach-mv78xx0/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-netx/include/mach/device.h       |   12 ++++++++++++
 arch/arm/mach-nomadik/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-ns9xxx/include/mach/device.h     |   12 ++++++++++++
 arch/arm/mach-orion5x/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-pnx4008/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-pxa/include/mach/device.h        |   12 ++++++++++++
 arch/arm/mach-realview/include/mach/device.h   |   12 ++++++++++++
 arch/arm/mach-rpc/include/mach/device.h        |   12 ++++++++++++
 arch/arm/mach-s3c2400/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-s3c2410/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-s3c2442/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-s3c24a0/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-s3c6400/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-s5pc100/include/mach/device.h    |   12 ++++++++++++
 arch/arm/mach-sa1100/include/mach/device.h     |   12 ++++++++++++
 arch/arm/mach-shark/include/mach/device.h      |   12 ++++++++++++
 arch/arm/mach-stmp378x/include/mach/device.h   |   12 ++++++++++++
 arch/arm/mach-stmp37xx/include/mach/device.h   |   12 ++++++++++++
 arch/arm/mach-u300/include/mach/device.h       |   12 ++++++++++++
 arch/arm/mach-versatile/include/mach/device.h  |   12 ++++++++++++
 arch/arm/mach-w90x900/include/mach/device.h    |   12 ++++++++++++
 arch/arm/plat-mxc/include/mach/device.h        |   12 ++++++++++++
 arch/arm/plat-omap/include/mach/device.h       |   12 ++++++++++++
 arch/arm/plat-s3c/include/mach/device.h        |   12 ++++++++++++
 arch/arm/plat-s3c24xx/include/mach/device.h    |   12 ++++++++++++
 arch/arm/plat-stmp3xxx/include/mach/device.h   |   12 ++++++++++++
 52 files changed, 615 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-aaec2000/include/mach/device.h
 create mode 100644 arch/arm/mach-at91/include/mach/device.h
 create mode 100644 arch/arm/mach-bcmring/include/mach/device.h
 create mode 100644 arch/arm/mach-clps711x/include/mach/device.h
 create mode 100644 arch/arm/mach-davinci/include/mach/device.h
 create mode 100644 arch/arm/mach-ebsa110/include/mach/device.h
 create mode 100644 arch/arm/mach-ep93xx/include/mach/device.h
 create mode 100644 arch/arm/mach-footbridge/include/mach/device.h
 create mode 100644 arch/arm/mach-gemini/include/mach/device.h
 create mode 100644 arch/arm/mach-h720x/include/mach/device.h
 create mode 100644 arch/arm/mach-integrator/include/mach/device.h
 create mode 100644 arch/arm/mach-iop13xx/include/mach/device.h
 create mode 100644 arch/arm/mach-iop32x/include/mach/device.h
 create mode 100644 arch/arm/mach-iop33x/include/mach/device.h
 create mode 100644 arch/arm/mach-ixp2000/include/mach/device.h
 create mode 100644 arch/arm/mach-ixp23xx/include/mach/device.h
 create mode 100644 arch/arm/mach-ixp4xx/include/mach/device.h
 create mode 100644 arch/arm/mach-kirkwood/include/mach/device.h
 create mode 100644 arch/arm/mach-ks8695/include/mach/device.h
 create mode 100644 arch/arm/mach-l7200/include/mach/device.h
 create mode 100644 arch/arm/mach-lh7a40x/include/mach/device.h
 create mode 100644 arch/arm/mach-loki/include/mach/device.h
 create mode 100644 arch/arm/mach-mmp/include/mach/device.h
 create mode 100644 arch/arm/mach-msm/include/mach/device.h
 create mode 100644 arch/arm/mach-mv78xx0/include/mach/device.h
 create mode 100644 arch/arm/mach-netx/include/mach/device.h
 create mode 100644 arch/arm/mach-nomadik/include/mach/device.h
 create mode 100644 arch/arm/mach-ns9xxx/include/mach/device.h
 create mode 100644 arch/arm/mach-orion5x/include/mach/device.h
 create mode 100644 arch/arm/mach-pnx4008/include/mach/device.h
 create mode 100644 arch/arm/mach-pxa/include/mach/device.h
 create mode 100644 arch/arm/mach-realview/include/mach/device.h
 create mode 100644 arch/arm/mach-rpc/include/mach/device.h
 create mode 100644 arch/arm/mach-s3c2400/include/mach/device.h
 create mode 100644 arch/arm/mach-s3c2410/include/mach/device.h
 create mode 100644 arch/arm/mach-s3c2442/include/mach/device.h
 create mode 100644 arch/arm/mach-s3c24a0/include/mach/device.h
 create mode 100644 arch/arm/mach-s3c6400/include/mach/device.h
 create mode 100644 arch/arm/mach-s5pc100/include/mach/device.h
 create mode 100644 arch/arm/mach-sa1100/include/mach/device.h
 create mode 100644 arch/arm/mach-shark/include/mach/device.h
 create mode 100644 arch/arm/mach-stmp378x/include/mach/device.h
 create mode 100644 arch/arm/mach-stmp37xx/include/mach/device.h
 create mode 100644 arch/arm/mach-u300/include/mach/device.h
 create mode 100644 arch/arm/mach-versatile/include/mach/device.h
 create mode 100644 arch/arm/mach-w90x900/include/mach/device.h
 create mode 100644 arch/arm/plat-mxc/include/mach/device.h
 create mode 100644 arch/arm/plat-omap/include/mach/device.h
 create mode 100644 arch/arm/plat-s3c/include/mach/device.h
 create mode 100644 arch/arm/plat-s3c24xx/include/mach/device.h
 create mode 100644 arch/arm/plat-stmp3xxx/include/mach/device.h

diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 9f390ce..8bf0dd8 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -6,6 +6,8 @@
 #ifndef ASMARM_DEVICE_H
 #define ASMARM_DEVICE_H
 
+#include <mach/device.h>
+
 struct dev_archdata {
 #ifdef CONFIG_DMABOUNCE
 	struct dmabounce_device_info *dmabounce;
@@ -13,6 +15,7 @@ struct dev_archdata {
 };
 
 struct pdev_archdata {
+	struct pdev_machdata machdata;
 };
 
 #endif
diff --git a/arch/arm/mach-aaec2000/include/mach/device.h b/arch/arm/mach-aaec2000/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-aaec2000/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-at91/include/mach/device.h b/arch/arm/mach-at91/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-at91/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-bcmring/include/mach/device.h b/arch/arm/mach-bcmring/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-bcmring/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-clps711x/include/mach/device.h b/arch/arm/mach-clps711x/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-clps711x/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-davinci/include/mach/device.h b/arch/arm/mach-davinci/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-ebsa110/include/mach/device.h b/arch/arm/mach-ebsa110/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-ebsa110/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-ep93xx/include/mach/device.h b/arch/arm/mach-ep93xx/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-ep93xx/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-footbridge/include/mach/device.h b/arch/arm/mach-footbridge/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-footbridge/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-gemini/include/mach/device.h b/arch/arm/mach-gemini/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-gemini/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-h720x/include/mach/device.h b/arch/arm/mach-h720x/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-h720x/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-integrator/include/mach/device.h b/arch/arm/mach-integrator/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-integrator/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-iop13xx/include/mach/device.h b/arch/arm/mach-iop13xx/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-iop13xx/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-iop32x/include/mach/device.h b/arch/arm/mach-iop32x/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-iop32x/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-iop33x/include/mach/device.h b/arch/arm/mach-iop33x/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-iop33x/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-ixp2000/include/mach/device.h b/arch/arm/mach-ixp2000/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-ixp2000/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-ixp23xx/include/mach/device.h b/arch/arm/mach-ixp23xx/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-ixp23xx/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-ixp4xx/include/mach/device.h b/arch/arm/mach-ixp4xx/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-ixp4xx/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-kirkwood/include/mach/device.h b/arch/arm/mach-kirkwood/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-kirkwood/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-ks8695/include/mach/device.h b/arch/arm/mach-ks8695/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-ks8695/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-l7200/include/mach/device.h b/arch/arm/mach-l7200/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-l7200/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-lh7a40x/include/mach/device.h b/arch/arm/mach-lh7a40x/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-lh7a40x/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-loki/include/mach/device.h b/arch/arm/mach-loki/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-loki/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-mmp/include/mach/device.h b/arch/arm/mach-mmp/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-msm/include/mach/device.h b/arch/arm/mach-msm/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-msm/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-mv78xx0/include/mach/device.h b/arch/arm/mach-mv78xx0/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-mv78xx0/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-netx/include/mach/device.h b/arch/arm/mach-netx/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-netx/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-nomadik/include/mach/device.h b/arch/arm/mach-nomadik/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-nomadik/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-ns9xxx/include/mach/device.h b/arch/arm/mach-ns9xxx/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-ns9xxx/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-orion5x/include/mach/device.h b/arch/arm/mach-orion5x/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-orion5x/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-pnx4008/include/mach/device.h b/arch/arm/mach-pnx4008/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-pnx4008/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-pxa/include/mach/device.h b/arch/arm/mach-pxa/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-pxa/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-realview/include/mach/device.h b/arch/arm/mach-realview/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-realview/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-rpc/include/mach/device.h b/arch/arm/mach-rpc/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-rpc/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-s3c2400/include/mach/device.h b/arch/arm/mach-s3c2400/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-s3c2400/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-s3c2410/include/mach/device.h b/arch/arm/mach-s3c2410/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-s3c2410/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-s3c2442/include/mach/device.h b/arch/arm/mach-s3c2442/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-s3c2442/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-s3c24a0/include/mach/device.h b/arch/arm/mach-s3c24a0/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-s3c24a0/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-s3c6400/include/mach/device.h b/arch/arm/mach-s3c6400/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-s3c6400/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-s5pc100/include/mach/device.h b/arch/arm/mach-s5pc100/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-s5pc100/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-sa1100/include/mach/device.h b/arch/arm/mach-sa1100/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-sa1100/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-shark/include/mach/device.h b/arch/arm/mach-shark/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-shark/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-stmp378x/include/mach/device.h b/arch/arm/mach-stmp378x/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-stmp378x/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-stmp37xx/include/mach/device.h b/arch/arm/mach-stmp37xx/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-stmp37xx/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-u300/include/mach/device.h b/arch/arm/mach-u300/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-u300/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-versatile/include/mach/device.h b/arch/arm/mach-versatile/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-versatile/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/mach-w90x900/include/mach/device.h b/arch/arm/mach-w90x900/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/mach-w90x900/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/plat-mxc/include/mach/device.h b/arch/arm/plat-mxc/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/plat-mxc/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/plat-omap/include/mach/device.h b/arch/arm/plat-omap/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/plat-s3c/include/mach/device.h b/arch/arm/plat-s3c/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/plat-s3c/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/plat-s3c24xx/include/mach/device.h b/arch/arm/plat-s3c24xx/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/plat-s3c24xx/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
diff --git a/arch/arm/plat-stmp3xxx/include/mach/device.h b/arch/arm/plat-stmp3xxx/include/mach/device.h
new file mode 100644
index 0000000..0bd31e6
--- /dev/null
+++ b/arch/arm/plat-stmp3xxx/include/mach/device.h
@@ -0,0 +1,12 @@
+/*
+ * ARM mach-specific extensions to platform_device
+ *
+ * This file is released under the GPLv2
+ */
+#ifndef MACH_DEVICE_H
+#define MACH_DEVICE_H
+
+struct pdev_machdata {
+};
+
+#endif
-- 
1.6.4.3

[PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Ben Dooks]

How about adding a Kconfig for any architectures interested in defining
it to declare that they do not want a generic version, or some form of
default include that could be used to support archs where this is not
defined?

This i san awful lot of nothing header addition.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

[PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Eric Miao]

On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> On ARM platforms, power management can be very platform specific.
> This patch allows ARM subarches to extend the platform_device
> pdev_archdata for each subarch by creating a new struct pdev_machdata
> and allowing each subarch to customize it as needed.
>
> As a starting point, each subarch's <mach/device.h> creates an empty
> struct pdev_machdata.
>

Shouldn't that pdev_archdata and pdev_machdata be pointer or something
so that multiple platform_device can share something in common?

[PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Mikael Pettersson]

Eric Miao writes:
 > On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
 > <khilman@deeprootsystems.com> wrote:
 > > On ARM platforms, power management can be very platform specific.
 > > This patch allows ARM subarches to extend the platform_device
 > > pdev_archdata for each subarch by creating a new struct pdev_machdata
 > > and allowing each subarch to customize it as needed.
 > >
 > > As a starting point, each subarch's <mach/device.h> creates an empty
 > > struct pdev_machdata.
 > >
 > 
 > Shouldn't that pdev_archdata and pdev_machdata be pointer or something
 > so that multiple platform_device can share something in common?

Forcing it to be a pointer has allocation and lifetime implications.
Making it a struct allows the subarch to duplicate or share
(via a private pointer) data as it sees fit.

[PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Kevin Hilman]

Ben Dooks wrote:
> How about adding a Kconfig for any architectures interested in defining
> it to declare that they do not want a generic version, or some form of
> default include that could be used to support archs where this is not
> defined?
> 
> This i san awful lot of nothing header addition.
> 

I'm ok with a Kconfig option if that is preferred, but personally I 
prefer minimizing Kconfig space.

Thanks for the comments,

Kevin

[PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Kevin Hilman]

Mikael Pettersson wrote:
> Eric Miao writes:
>  > On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>  > <khilman@deeprootsystems.com> wrote:
>  > > On ARM platforms, power management can be very platform specific.
>  > > This patch allows ARM subarches to extend the platform_device
>  > > pdev_archdata for each subarch by creating a new struct pdev_machdata
>  > > and allowing each subarch to customize it as needed.
>  > >
>  > > As a starting point, each subarch's <mach/device.h> creates an empty
>  > > struct pdev_machdata.
>  > >
>  > 
>  > Shouldn't that pdev_archdata and pdev_machdata be pointer or something
>  > so that multiple platform_device can share something in common?
> 
> Forcing it to be a pointer has allocation and lifetime implications.
> Making it a struct allows the subarch to duplicate or share
> (via a private pointer) data as it sees fit.

Yes, the allocation/lifetime issues were why a struct was chosen.

Kevin

[PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Eric Miao]

On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Mikael Pettersson wrote:
>>
>> Eric Miao writes:
>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>> ?> <khilman@deeprootsystems.com> wrote:
>> ?> > On ARM platforms, power management can be very platform specific.
>> ?> > This patch allows ARM subarches to extend the platform_device
>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>> ?> > and allowing each subarch to customize it as needed.
>> ?> >
>> ?> > As a starting point, each subarch's <mach/device.h> creates an empty
>> ?> > struct pdev_machdata.
>> ?> >
>> ?> ?> Shouldn't that pdev_archdata and pdev_machdata be pointer or
>> something
>> ?> so that multiple platform_device can share something in common?
>>
>> Forcing it to be a pointer has allocation and lifetime implications.
>> Making it a struct allows the subarch to duplicate or share
>> (via a private pointer) data as it sees fit.
>
> Yes, the allocation/lifetime issues were why a struct was chosen.
>

Mmm... this makes sense to me. I'm ok with this patch - just wondering
for the moment what to put for the pxa architecture - I'll see what davinci
will do first, of course :)

[PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Kevin Hilman]

Eric Miao wrote:
> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> Mikael Pettersson wrote:
>>> Eric Miao writes:
>>>  > On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>  > <khilman@deeprootsystems.com> wrote:
>>>  > > On ARM platforms, power management can be very platform specific.
>>>  > > This patch allows ARM subarches to extend the platform_device
>>>  > > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>  > > and allowing each subarch to customize it as needed.
>>>  > >
>>>  > > As a starting point, each subarch's <mach/device.h> creates an empty
>>>  > > struct pdev_machdata.
>>>  > >
>>>  >  > Shouldn't that pdev_archdata and pdev_machdata be pointer or
>>> something
>>>  > so that multiple platform_device can share something in common?
>>>
>>> Forcing it to be a pointer has allocation and lifetime implications.
>>> Making it a struct allows the subarch to duplicate or share
>>> (via a private pointer) data as it sees fit.
>> Yes, the allocation/lifetime issues were why a struct was chosen.
>>
> 
> Mmm... this makes sense to me. I'm ok with this patch - just wondering
> for the moment what to put for the pxa architecture - I'll see what davinci
> will do first, of course :)

Well, I'll be doing OMAP before davinci, and the pdev_machdata will 
bascailly contain an OMAP specific struct (omap_device) that keeps track 
of various OMAP-specific device proerties (powerdomain, clock(s), PM 
register offsets, etc. etc.)  Basically, nothing that would be shared by 
other arches.

If down the road we figure out stuff common to all ARM platforms, we 
could put it in the pdev_archdata struct.

Kevin

[PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Kevin Hilman]

Eric Miao <eric.y.miao@gmail.com> writes:

> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> Mikael Pettersson wrote:
>>>
>>> Eric Miao writes:
>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>> ?> <khilman@deeprootsystems.com> wrote:
>>> ?> > On ARM platforms, power management can be very platform specific.
>>> ?> > This patch allows ARM subarches to extend the platform_device
>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>> ?> > and allowing each subarch to customize it as needed.
>>> ?> >
>>> ?> > As a starting point, each subarch's <mach/device.h> creates an empty
>>> ?> > struct pdev_machdata.
>>> ?> >
>>> ?> ?> Shouldn't that pdev_archdata and pdev_machdata be pointer or
>>> something
>>> ?> so that multiple platform_device can share something in common?
>>>
>>> Forcing it to be a pointer has allocation and lifetime implications.
>>> Making it a struct allows the subarch to duplicate or share
>>> (via a private pointer) data as it sees fit.
>>
>> Yes, the allocation/lifetime issues were why a struct was chosen.
>>
>
> Mmm... this makes sense to me. I'm ok with this patch - just wondering
> for the moment what to put for the pxa architecture - I'll see what davinci
> will do first, of course :)

OK, after no further comments, sending this patch to the patch system.

Kevin

[linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Magnus Damm]

On Tue, Oct 27, 2009 at 8:13 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Eric Miao <eric.y.miao@gmail.com> writes:
>> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>> Mikael Pettersson wrote:
>>>> Eric Miao writes:
>>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>> ?> <khilman@deeprootsystems.com> wrote:
>>>> ?> > On ARM platforms, power management can be very platform specific.
>>>> ?> > This patch allows ARM subarches to extend the platform_device
>>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>> ?> > and allowing each subarch to customize it as needed.

[snip]

> OK, after no further comments, sending this patch to the patch system.

Hi Kevin,

Thanks for your work on this. I found this patch marked as superseeded
in the tracker here:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=5773/1

I'd now like to use struct pdev_archdata myself on mach-shmobile, so
almost a year later I wonder why this patch didn't make it.

I realize that you use struct omap_device instead of struct
pdev_archdata. I prefer not to wrap if possible. This because I'd like
to reuse already existing drivers and PM code with the SuperH
architecture.

Do you remember what happened with this patch?

Cheers,

/ magnus

Re: [linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Grant Likely]

"Magnus Damm" <magnus.damm@gmail.com> wrote:

>On Tue, Oct 27, 2009 at 8:13 AM, Kevin Hilman
><khilman@deeprootsystems.com> wrote:
>> Eric Miao <eric.y.miao@gmail.com> writes:
>>> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
>>> <khilman@deeprootsystems.com> wrote:
>>>> Mikael Pettersson wrote:
>>>>> Eric Miao writes:
>>>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>>> ?> <khilman@deeprootsystems.com> wrote:
>>>>> ?> > On ARM platforms, power management can be very platform specific.
>>>>> ?> > This patch allows ARM subarches to extend the platform_device
>>>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>>> ?> > and allowing each subarch to customize it as needed.
>
>[snip]
>
>> OK, after no further comments, sending this patch to the patch system.
>
>Hi Kevin,
>
>Thanks for your work on this. I found this patch marked as superseeded
>in the tracker here:
>
>http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=5773/1
>
>I'd now like to use struct pdev_archdata myself on mach-shmobile, so
>almost a year later I wonder why this patch didn't make it.
>
>I realize that you use struct omap_device instead of struct
>pdev_archdata. I prefer not to wrap if possible. This because I'd like
>to reuse already existing drivers and PM code with the SuperH
>architecture.
>
>Do you remember what happened with this patch?

I don't have all the details in front of me because I'm on my phone, but I advised against pdev_archdata because it is multiplatform-unfriendly.

g.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Magnus Damm]

On Sun, Jul 25, 2010 at 5:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> "Magnus Damm" <magnus.damm@gmail.com> wrote:
>>On Tue, Oct 27, 2009 at 8:13 AM, Kevin Hilman
>><khilman@deeprootsystems.com> wrote:
>>> Eric Miao <eric.y.miao@gmail.com> writes:
>>>> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
>>>> <khilman@deeprootsystems.com> wrote:
>>>>> Mikael Pettersson wrote:
>>>>>> Eric Miao writes:
>>>>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>>>> ?> <khilman@deeprootsystems.com> wrote:
>>>>>> ?> > On ARM platforms, power management can be very platform specific.
>>>>>> ?> > This patch allows ARM subarches to extend the platform_device
>>>>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>>>> ?> > and allowing each subarch to customize it as needed.

>>Do you remember what happened with this patch?
>
> I don't have all the details in front of me because I'm on my phone, but I advised against pdev_archdata because it is multiplatform-unfriendly.

Ok, I did not expect that. =) But after thinking a bit it does make
sense. I wonder what my options are. I'm not so fond of the idea to
wrap the platform devices - that's not more multi-platform friendly,
is it?

How about using devres and platform bus notifiers?

For a Runtime PM prototype using devres (instead of pdev_archdata or
wrapping) look here:
https://patchwork.kernel.org/patch/113605/

To make it work with modules I propose adding a driver bind event:
https://patchwork.kernel.org/patch/113865/

Looks pretty multi-platform friendly to me. Any suggestions?

Thanks,

/ magnus

[linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Kevin Hilman]

Magnus Damm <magnus.damm@gmail.com> writes:

> On Sun, Jul 25, 2010 at 5:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> "Magnus Damm" <magnus.damm@gmail.com> wrote:
>>>On Tue, Oct 27, 2009 at 8:13 AM, Kevin Hilman
>>><khilman@deeprootsystems.com> wrote:
>>>> Eric Miao <eric.y.miao@gmail.com> writes:
>>>>> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
>>>>> <khilman@deeprootsystems.com> wrote:
>>>>>> Mikael Pettersson wrote:
>>>>>>> Eric Miao writes:
>>>>>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>>>>> ?> <khilman@deeprootsystems.com> wrote:
>>>>>>> ?> > On ARM platforms, power management can be very platform specific.
>>>>>>> ?> > This patch allows ARM subarches to extend the platform_device
>>>>>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>>>>> ?> > and allowing each subarch to customize it as needed.
>
>>>Do you remember what happened with this patch?
>>
>> I don't have all the details in front of me because I'm on my phone,
>> but I advised against pdev_archdata because it is
>> multiplatform-unfriendly.
>
> Ok, I did not expect that. =) But after thinking a bit it does make
> sense. I wonder what my options are. I'm not so fond of the idea to
> wrap the platform devices - that's not more multi-platform friendly,
> is it?

[sorry for the lag, been on vacation]

Wrapping is more multi-platform friendly because only platform-specific
code accesses the wrapped code.  It's also logically consistent as 
a struct device is contained by a platform_device which is then
contained by an omap_device (in our case.)   Only OMAP-specific code
ever knows about or touches that layer.

> How about using devres and platform bus notifiers?

That seems fine too, and probably better if the amount of data/code you need
is small.  In the OMAP case, it's rather complicated so it's cleaner
IMHO to keep it in a separate omap_device layer and struct.

> For a Runtime PM prototype using devres (instead of pdev_archdata or
> wrapping) look here:
> https://patchwork.kernel.org/patch/113605/
>
> To make it work with modules I propose adding a driver bind event:
> https://patchwork.kernel.org/patch/113865/
>
> Looks pretty multi-platform friendly to me. Any suggestions?

Your patches look multi-platform friendly, but there are still some
outstanding issues with making runtime PM support multi-platform
friendly that are not direclty related to the above patches.

1) weak symbols

We need to change the overriding of weak symbols into some form of
register/unregister so multiple platforms in the same kernel could work.
That's the easy one.   

2) custom vs. platform bus.

The other issue under discussion between Grant & myself[1] has been the
use of a custom bus instead of the platform bus.  Following your lead,
(and preferring that option) I continued to use the platform_bus since
I only need to override a few of the dev_pm_ops functions.

However, Grant is not happy about overriding the platform_bus.  He would
rather see each platform create a custom bus with it's own PM methods.

In this thread[1], I did a quick and dirty proof of concept to show that
it is possible, but quite frankly, I still much prefer continuing to use
the platform_bus since it is mostly identical.  

After I catch up on the rest of my mail, I will get back to this topic.

Kevin

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/018925.html

[linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Magnus Damm]

On Wed, Aug 4, 2010 at 1:16 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Magnus Damm <magnus.damm@gmail.com> writes:
>> On Sun, Jul 25, 2010 at 5:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>> "Magnus Damm" <magnus.damm@gmail.com> wrote:
>>>>On Tue, Oct 27, 2009 at 8:13 AM, Kevin Hilman
>>>><khilman@deeprootsystems.com> wrote:
>>>>> Eric Miao <eric.y.miao@gmail.com> writes:
>>>>>> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
>>>>>> <khilman@deeprootsystems.com> wrote:
>>>>>>> Mikael Pettersson wrote:
>>>>>>>> Eric Miao writes:
>>>>>>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>>>>>> ?> <khilman@deeprootsystems.com> wrote:
>>>>>>>> ?> > On ARM platforms, power management can be very platform specific.
>>>>>>>> ?> > This patch allows ARM subarches to extend the platform_device
>>>>>>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>>>>>> ?> > and allowing each subarch to customize it as needed.
>>
>>>>Do you remember what happened with this patch?
>>>
>>> I don't have all the details in front of me because I'm on my phone,
>>> but I advised against pdev_archdata because it is
>>> multiplatform-unfriendly.
>>
>> Ok, I did not expect that. =) But after thinking a bit it does make
>> sense. I wonder what my options are. I'm not so fond of the idea to
>> wrap the platform devices - that's not more multi-platform friendly,
>> is it?
>
> [sorry for the lag, been on vacation]
>
> Wrapping is more multi-platform friendly because only platform-specific
> code accesses the wrapped code. ?It's also logically consistent as
> a struct device is contained by a platform_device which is then
> contained by an omap_device (in our case.) ? Only OMAP-specific code
> ever knows about or touches that layer.

Sure, as long as all platform devices are wrapped into omap_device
then I see no problem. I guess my worries are about mixing platform
devices and omap_device on the same system. The answer to that may
simply be "don't". =)

For the mixed case my main concern is the use of to_omap_device() on a
struct platform device which may or may not be an omap_device. You
have your magic check in omap_device_is_valid() so i guess that's ok,
but compared to the rest of the driver model this extended level of
wrapping does not come with any pointer for class/type/bus. Platform
devices all use the platform_bus_type symbol for device->bus, so in
theory it's possible to check the bus type before going from struct
device to struct platform_device using to_platform_device(). In the
wrapped platform device case you first have to speculate using
container_of() and then check for magic. Seems a bit hackish to me. I
prefer the other way around, check wrapping type first then use
container_of().

I guess the question is if it's really needed to differentiate between
platform devices and omap devices, and I guess the only place where it
may be a problem is the runtime pm code. Perhaps thanks to the weak
symbols, sorry about that...

>> How about using devres and platform bus notifiers?
[snip]

> Your patches look multi-platform friendly, but there are still some
> outstanding issues with making runtime PM support multi-platform
> friendly that are not direclty related to the above patches.

I agree!

> 1) weak symbols
>
> We need to change the overriding of weak symbols into some form of
> register/unregister so multiple platforms in the same kernel could work.
> That's the easy one.

Yeah. Perhaps it's possible to reuse part of the pm_generic_... functions.

> 2) custom vs. platform bus.
>
> The other issue under discussion between Grant & myself[1] has been the
> use of a custom bus instead of the platform bus. ?Following your lead,
> (and preferring that option) I continued to use the platform_bus since
> I only need to override a few of the dev_pm_ops functions.
>
> However, Grant is not happy about overriding the platform_bus. ?He would
> rather see each platform create a custom bus with it's own PM methods.
>
> In this thread[1], I did a quick and dirty proof of concept to show that
> it is possible, but quite frankly, I still much prefer continuing to use
> the platform_bus since it is mostly identical.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/018925.html

Thanks for the pointer. I've been thinking of using a custom bus as
well, but from my point of view it's always looked like a lot of
coding without any clear benefit. I understand the idea of wanting to
use a single binary on a wide range of systems, and solving that seems
like a good plan.

I'm not sure if a custom bus is the best idea. I wouldn't mind being
able to create platform bus instances though. Or custom buses using
some kind of platform bus library. A lot of drivers use the platform
bus, so there has to be a very good reason to move away from that IMO.
A new bus type seems a bit overkill to me though, what we need from my
point of view is:

1) Mach/Plat hardware configuration data for platform devices
-> Can be kept in struct pdev_archdata (clock and power domain configuration)
-> Can be kept in a wrapped structure (clock and power domain configuration)
-> Use clkdev tables to handle the device name to clock translation
-> Power domain configuration without wrapping/pdev_archdata, not sure

2) Mach/Plat runtime data for each platform device
-> Data can be kept in the wrapped data structure or struct pdev_archdata
-> Could be solved by bus notifiers and dynamic allocation using devres

3) Mach/Plat specific runtime PM
-> Need to move away from weak symbols to register/unregister interface
-> Struct pdev_archdata could perhaps point out a per-mach/plat dev_pm_ops?

Any ideas?

Cheers,

/ magnus

[linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Grant Likely]

[cc'ing gregkh w.r.t. the bus notifiers in modules bit at the bottom]

On Sun, Jul 25, 2010 at 7:51 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Sun, Jul 25, 2010 at 5:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> "Magnus Damm" <magnus.damm@gmail.com> wrote:
>>>On Tue, Oct 27, 2009 at 8:13 AM, Kevin Hilman
>>><khilman@deeprootsystems.com> wrote:
>>>> Eric Miao <eric.y.miao@gmail.com> writes:
>>>>> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
>>>>> <khilman@deeprootsystems.com> wrote:
>>>>>> Mikael Pettersson wrote:
>>>>>>> Eric Miao writes:
>>>>>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>>>>> ?> <khilman@deeprootsystems.com> wrote:
>>>>>>> ?> > On ARM platforms, power management can be very platform specific.
>>>>>>> ?> > This patch allows ARM subarches to extend the platform_device
>>>>>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>>>>> ?> > and allowing each subarch to customize it as needed.
>
>>>Do you remember what happened with this patch?
>>
>> I don't have all the details in front of me because I'm on my phone, but I advised against pdev_archdata because it is multiplatform-unfriendly.
>
> Ok, I did not expect that. =) But after thinking a bit it does make
> sense. I wonder what my options are. I'm not so fond of the idea to
> wrap the platform devices - that's not more multi-platform friendly,
> is it?
>
> How about using devres and platform bus notifiers?

I think bus notifiers are appropriate.  I hadn't thought of using
devres to attach additional behaviour, but looking at your prototype
it seems to be sane.

> For a Runtime PM prototype using devres (instead of pdev_archdata or
> wrapping) look here:
> https://patchwork.kernel.org/patch/113605/

While I'm looking at this patch; some thoughts off the top of my head:

The static symbols should still be prefixed with 'sh_pm_runtime_' or
something similar.  There is a risk of things like
"platform_bus_notify" colliding with things defined in the global
namespace.

Looking at he '#else' clause of CONFIG_PM_RUNTIME triggered a warning
flag.  If the runtime PM stuff was as a module as suggested below,
then the drivers would get probed before the clock is enabled... Maybe
I'm misunderstanding it though because I see that the .c file is not
set up to be a module.

Also, that particular implementation is rather non-discriminant; and
every platform_device would get this binding regardless of what the
actual attachment to the system is.  For example, ASoC makes use of
platform devices to bind together an audio complex, but those devices
represent a set of connections, not an actual devices.  It probably
wouldn't be appropriate to have bus-specific runtime pm hooks on ASoC
devices.  But I understand that this is an early prototype and I
understand the intent.

> To make it work with modules I propose adding a driver bind event:
> https://patchwork.kernel.org/patch/113865/
>
> Looks pretty multi-platform friendly to me. Any suggestions?

The idea sane to me (haven't dug deeply enough to comment on the
implementation, but I suspect that there is a race condition in the
implementation which could cause drivers getting both BIND and BOUND
notifications).  I think it is entirely desirable for notifiers to be
informed of already existing drivers.

I had posted a somewhat related patch earlier, but never pursued it
because I found a different way around (and I was a little worried
about the race condition).  My patch to the approach of sending add
and bind events for each driver that is already registered/bound when
a new notifier is registered.  Here's the patch and the comments:

http://patchwork.ozlabs.org/patch/24152/

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Grant Likely]

On Tue, Aug 3, 2010 at 10:16 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Magnus Damm <magnus.damm@gmail.com> writes:
>
>> On Sun, Jul 25, 2010 at 5:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>> "Magnus Damm" <magnus.damm@gmail.com> wrote:
>>>>On Tue, Oct 27, 2009 at 8:13 AM, Kevin Hilman
>>>><khilman@deeprootsystems.com> wrote:
>>>>> Eric Miao <eric.y.miao@gmail.com> writes:
>>>>>> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
>>>>>> <khilman@deeprootsystems.com> wrote:
>>>>>>> Mikael Pettersson wrote:
>>>>>>>> Eric Miao writes:
>>>>>>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>>>>>> ?> <khilman@deeprootsystems.com> wrote:
>>>>>>>> ?> > On ARM platforms, power management can be very platform specific.
>>>>>>>> ?> > This patch allows ARM subarches to extend the platform_device
>>>>>>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>>>>>> ?> > and allowing each subarch to customize it as needed.
>>
>>>>Do you remember what happened with this patch?
>>>
>>> I don't have all the details in front of me because I'm on my phone,
>>> but I advised against pdev_archdata because it is
>>> multiplatform-unfriendly.
>>
>> Ok, I did not expect that. =) But after thinking a bit it does make
>> sense. I wonder what my options are. I'm not so fond of the idea to
>> wrap the platform devices - that's not more multi-platform friendly,
>> is it?
>
> [sorry for the lag, been on vacation]
>
> Wrapping is more multi-platform friendly because only platform-specific
> code accesses the wrapped code. ?It's also logically consistent as
> a struct device is contained by a platform_device which is then
> contained by an omap_device (in our case.) ? Only OMAP-specific code
> ever knows about or touches that layer.

(I just noticed this; will also reply on the other thread so it is
recorded in the public record) But it is also really dangerous;
particularly in the case of dynamically allocated platform_devices.
When handed a random platform_device pointer, you have absolutely *no*
idea whether or not it is valid to dereference a pointer at a lower
address from the platform_device pointer.  It is very likely that
there will be other code in the system that will register
platform_devices without the omap_device wrapper.

>> How about using devres and platform bus notifiers?
>
> That seems fine too, and probably better if the amount of data/code you need
> is small. ?In the OMAP case, it's rather complicated so it's cleaner
> IMHO to keep it in a separate omap_device layer and struct.

but it is safe

>> For a Runtime PM prototype using devres (instead of pdev_archdata or
>> wrapping) look here:
>> https://patchwork.kernel.org/patch/113605/
>>
>> To make it work with modules I propose adding a driver bind event:
>> https://patchwork.kernel.org/patch/113865/
>>
>> Looks pretty multi-platform friendly to me. Any suggestions?
>
> Your patches look multi-platform friendly, but there are still some
> outstanding issues with making runtime PM support multi-platform
> friendly that are not direclty related to the above patches.
>
> 1) weak symbols
>
> We need to change the overriding of weak symbols into some form of
> register/unregister so multiple platforms in the same kernel could work.
> That's the easy one.
>
> 2) custom vs. platform bus.
>
> The other issue under discussion between Grant & myself[1] has been the
> use of a custom bus instead of the platform bus. ?Following your lead,
> (and preferring that option) I continued to use the platform_bus since
> I only need to override a few of the dev_pm_ops functions.
>
> However, Grant is not happy about overriding the platform_bus. ?He would
> rather see each platform create a custom bus with it's own PM methods.
>
> In this thread[1], I did a quick and dirty proof of concept to show that
> it is possible, but quite frankly, I still much prefer continuing to use
> the platform_bus since it is mostly identical.

I quite possibly could be convinced that the devres approach is the
RightThing to do.  It neatly sidesteps the issue I see with the
omap_device container approach.  I'd need to see a prototype to be
sure.

Cheers,
g.

[linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Grant Likely]

On Tue, Aug 3, 2010 at 9:56 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Wed, Aug 4, 2010 at 1:16 AM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> Magnus Damm <magnus.damm@gmail.com> writes:
>>> On Sun, Jul 25, 2010 at 5:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>>> "Magnus Damm" <magnus.damm@gmail.com> wrote:
>>>>>On Tue, Oct 27, 2009 at 8:13 AM, Kevin Hilman
>>>>><khilman@deeprootsystems.com> wrote:
>>>>>> Eric Miao <eric.y.miao@gmail.com> writes:
>>>>>>> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
>>>>>>> <khilman@deeprootsystems.com> wrote:
>>>>>>>> Mikael Pettersson wrote:
>>>>>>>>> Eric Miao writes:
>>>>>>>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>>>>>>> ?> <khilman@deeprootsystems.com> wrote:
>>>>>>>>> ?> > On ARM platforms, power management can be very platform specific.
>>>>>>>>> ?> > This patch allows ARM subarches to extend the platform_device
>>>>>>>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>>>>>>> ?> > and allowing each subarch to customize it as needed.
>>>
>>>>>Do you remember what happened with this patch?
>>>>
>>>> I don't have all the details in front of me because I'm on my phone,
>>>> but I advised against pdev_archdata because it is
>>>> multiplatform-unfriendly.
>>>
>>> Ok, I did not expect that. =) But after thinking a bit it does make
>>> sense. I wonder what my options are. I'm not so fond of the idea to
>>> wrap the platform devices - that's not more multi-platform friendly,
>>> is it?
>>
>> [sorry for the lag, been on vacation]
>>
>> Wrapping is more multi-platform friendly because only platform-specific
>> code accesses the wrapped code. ?It's also logically consistent as
>> a struct device is contained by a platform_device which is then
>> contained by an omap_device (in our case.) ? Only OMAP-specific code
>> ever knows about or touches that layer.
>
> Sure, as long as all platform devices are wrapped into omap_device
> then I see no problem. I guess my worries are about mixing platform
> devices and omap_device on the same system. The answer to that may
> simply be "don't". =)

yes

> For the mixed case my main concern is the use of to_omap_device() on a
> struct platform device which may or may not be an omap_device. You
> have your magic check in omap_device_is_valid() so i guess that's ok,
> but compared to the rest of the driver model this extended level of
> wrapping does not come with any pointer for class/type/bus. Platform
> devices all use the platform_bus_type symbol for device->bus, so in
> theory it's possible to check the bus type before going from struct
> device to struct platform_device using to_platform_device().

Yes, this is guaranteed safe.

> In the
> wrapped platform device case you first have to speculate using
> container_of() and then check for magic. Seems a bit hackish to me. I
> prefer the other way around, check wrapping type first then use
> container_of().

Not just hackish.  Dangerous.

> I guess the question is if it's really needed to differentiate between
> platform devices and omap devices, and I guess the only place where it
> may be a problem is the runtime pm code. Perhaps thanks to the weak
> symbols, sorry about that...
>
>>> How about using devres and platform bus notifiers?
> [snip]
>
>> Your patches look multi-platform friendly, but there are still some
>> outstanding issues with making runtime PM support multi-platform
>> friendly that are not direclty related to the above patches.
>
> I agree!
>
>> 1) weak symbols
>>
>> We need to change the overriding of weak symbols into some form of
>> register/unregister so multiple platforms in the same kernel could work.
>> That's the easy one.
>
> Yeah. Perhaps it's possible to reuse part of the pm_generic_... functions.
>
>> 2) custom vs. platform bus.
>>
>> The other issue under discussion between Grant & myself[1] has been the
>> use of a custom bus instead of the platform bus. ?Following your lead,
>> (and preferring that option) I continued to use the platform_bus since
>> I only need to override a few of the dev_pm_ops functions.
>>
>> However, Grant is not happy about overriding the platform_bus. ?He would
>> rather see each platform create a custom bus with it's own PM methods.
>>
>> In this thread[1], I did a quick and dirty proof of concept to show that
>> it is possible, but quite frankly, I still much prefer continuing to use
>> the platform_bus since it is mostly identical.
>>
>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/018925.html
>
> Thanks for the pointer. I've been thinking of using a custom bus as
> well, but from my point of view it's always looked like a lot of
> coding without any clear benefit. I understand the idea of wanting to
> use a single binary on a wide range of systems, and solving that seems
> like a good plan.
>
> I'm not sure if a custom bus is the best idea. I wouldn't mind being
> able to create platform bus instances though.

The only problem with multiple platform_bus instances would be that
drivers intended to work on both would need to be registered twice;
once on the regular platform bus, and once on the custom bus.  All the
rest of the code would be shared, but it probably still doesn't
reflect the model that you're shooting for.

However, on the flipside the question must be asked; are you trying to
describe inherent bus-type behaviour that the plaform bus does not
address?  ie. is the OMAP bus fundamentally different from a normal
'dumb' bus?  What is the real count of device drivers that will need
to be registered on the platform bus and the omap bus (or sh, etc)?  A
modified platform bus type instance may require duplicate driver
registrations, but it is also potentially a lot less complex for a
reader to understand what is going on (ie. the runtime-pm calls are
explicit instead of being indirect through a bus notifier).

> Or custom buses using
> some kind of platform bus library. A lot of drivers use the platform
> bus, so there has to be a very good reason to move away from that IMO.
> A new bus type seems a bit overkill to me though, what we need from my
> point of view is:

bus types are cheep, especially when the code is shared.

> 1) Mach/Plat hardware configuration data for platform devices
> -> Can be kept in struct pdev_archdata (clock and power domain configuration)

Careful.  putting mach/plat specific stuff into pdev_archdata is
multiplatform unfriendly.  I think pdev_archdata should be restricted
to arch-specific stuff.

> -> Can be kept in a wrapped structure (clock and power domain configuration)
> -> Use clkdev tables to handle the device name to clock translation
> -> Power domain configuration without wrapping/pdev_archdata, not sure
>
> 2) Mach/Plat runtime data for each platform device
> -> Data can be kept in the wrapped data structure or struct pdev_archdata
> -> Could be solved by bus notifiers and dynamic allocation using devres
>
> 3) Mach/Plat specific runtime PM
> -> Need to move away from weak symbols to register/unregister interface
> -> Struct pdev_archdata could perhaps point out a per-mach/plat dev_pm_ops?

registerable per-mach/plat ops structures sound sane.  However, I
think we can do better since this is not an arch-specific problem.
Already ARM and SH needs a solution, and I can see it being applicable
to the other embedded archs too.  I'd like to see a non-arch-specific
solution.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Magnus Damm]

On Thu, Aug 5, 2010 at 7:41 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> [cc'ing gregkh w.r.t. the bus notifiers in modules bit at the bottom]
>
> On Sun, Jul 25, 2010 at 7:51 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> How about using devres and platform bus notifiers?
>
> I think bus notifiers are appropriate. ?I hadn't thought of using
> devres to attach additional behaviour, but looking at your prototype
> it seems to be sane.
>
>> For a Runtime PM prototype using devres (instead of pdev_archdata or
>> wrapping) look here:
>> https://patchwork.kernel.org/patch/113605/
>
> While I'm looking at this patch; some thoughts off the top of my head:
>
> The static symbols should still be prefixed with 'sh_pm_runtime_' or
> something similar. ?There is a risk of things like
> "platform_bus_notify" colliding with things defined in the global
> namespace.

Sure, avoiding colliding with the global name space makes sense!

> Looking at he '#else' clause of CONFIG_PM_RUNTIME triggered a warning
> flag. ?If the runtime PM stuff was as a module as suggested below,
> then the drivers would get probed before the clock is enabled... Maybe
> I'm misunderstanding it though because I see that the .c file is not
> set up to be a module.

Oh, I didn't intend to allow the Runtime PM code to be a module. Sorry
for the unclear wording, I meant to support being notified before the
probe() at insmod time for platform drivers built as modules.

> Also, that particular implementation is rather non-discriminant; and
> every platform_device would get this binding regardless of what the
> actual attachment to the system is. ?For example, ASoC makes use of
> platform devices to bind together an audio complex, but those devices
> represent a set of connections, not an actual devices. ?It probably
> wouldn't be appropriate to have bus-specific runtime pm hooks on ASoC
> devices. ?But I understand that this is an early prototype and I
> understand the intent.

The Runtime PM code for SH-Mobile ARM does not differentiate between
various types of platform devices. The code relies on clkdev doing the
matching. So if there is no clkdev mapping for the platform device
then nothing is done. Perhaps the generic runtime pm hooks should be
called for that case instead.

>> To make it work with modules I propose adding a driver bind event:
>> https://patchwork.kernel.org/patch/113865/
>>
>> Looks pretty multi-platform friendly to me. Any suggestions?
>
> The idea sane to me (haven't dug deeply enough to comment on the
> implementation, but I suspect that there is a race condition in the
> implementation which could cause drivers getting both BIND and BOUND
> notifications). ?I think it is entirely desirable for notifiers to be
> informed of already existing drivers.

Hm, I have not seen any race myself, but the registered bus notifiers
will receive all kinds of events - ie both BIND and BOUND.

> I had posted a somewhat related patch earlier, but never pursued it
> because I found a different way around (and I was a little worried
> about the race condition). ?My patch to the approach of sending add
> and bind events for each driver that is already registered/bound when
> a new notifier is registered. ?Here's the patch and the comments:
>
> http://patchwork.ozlabs.org/patch/24152/

That patch makes sense for code built as modules. I do my best to
avoid that situation by just allowing the code to be built-in. =)

Thanks for your comments!

/ magnus

[linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Magnus Damm]

On Thu, Aug 5, 2010 at 8:10 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Tue, Aug 3, 2010 at 9:56 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> On Wed, Aug 4, 2010 at 1:16 AM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>> 2) custom vs. platform bus.
>>>
>>> The other issue under discussion between Grant & myself[1] has been the
>>> use of a custom bus instead of the platform bus. ?Following your lead,
>>> (and preferring that option) I continued to use the platform_bus since
>>> I only need to override a few of the dev_pm_ops functions.
>>>
>>> However, Grant is not happy about overriding the platform_bus. ?He would
>>> rather see each platform create a custom bus with it's own PM methods.
>>>
>>> In this thread[1], I did a quick and dirty proof of concept to show that
>>> it is possible, but quite frankly, I still much prefer continuing to use
>>> the platform_bus since it is mostly identical.
>>>
>>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/018925.html
>>
>> Thanks for the pointer. I've been thinking of using a custom bus as
>> well, but from my point of view it's always looked like a lot of
>> coding without any clear benefit. I understand the idea of wanting to
>> use a single binary on a wide range of systems, and solving that seems
>> like a good plan.
>>
>> I'm not sure if a custom bus is the best idea. I wouldn't mind being
>> able to create platform bus instances though.
>
> The only problem with multiple platform_bus instances would be that
> drivers intended to work on both would need to be registered twice;
> once on the regular platform bus, and once on the custom bus. ?All the
> rest of the code would be shared, but it probably still doesn't
> reflect the model that you're shooting for.

Do they really have to be registered twice? With the current driver
model yes, but perhaps it's possible to adjust the platform bus to
allow device<->driver matching across buses somehow. I would prefer to
register drivers only once.

> However, on the flipside the question must be asked; are you trying to
> describe inherent bus-type behaviour that the plaform bus does not
> address? ?ie. is the OMAP bus fundamentally different from a normal
> 'dumb' bus? ?What is the real count of device drivers that will need
> to be registered on the platform bus and the omap bus (or sh, etc)? ?A
> modified platform bus type instance may require duplicate driver
> registrations, but it is also potentially a lot less complex for a
> reader to understand what is going on (ie. the runtime-pm calls are
> explicit instead of being indirect through a bus notifier).

I suspect that Runtime PM is the main reason why people all of a
sudden need to extend the platform bus. =)

>> Or custom buses using
>> some kind of platform bus library. A lot of drivers use the platform
>> bus, so there has to be a very good reason to move away from that IMO.
>> A new bus type seems a bit overkill to me though, what we need from my
>> point of view is:
>
> bus types are cheep, especially when the code is shared.

Agreed!

>> 1) Mach/Plat hardware configuration data for platform devices
>> -> Can be kept in struct pdev_archdata (clock and power domain configuration)
>
> Careful. ?putting mach/plat specific stuff into pdev_archdata is
> multiplatform unfriendly. ?I think pdev_archdata should be restricted
> to arch-specific stuff.

Not sure if it has to be multiplatform-unfriendly. You could have one
structure per mach/plat inside pdev_archdata. That aside, code and
data should of course be shared as much as possible.

>> -> Can be kept in a wrapped structure (clock and power domain configuration)
>> -> Use clkdev tables to handle the device name to clock translation
>> -> Power domain configuration without wrapping/pdev_archdata, not sure
>>
>> 2) Mach/Plat runtime data for each platform device
>> -> Data can be kept in the wrapped data structure or struct pdev_archdata
>> -> Could be solved by bus notifiers and dynamic allocation using devres
>>
>> 3) Mach/Plat specific runtime PM
>> -> Need to move away from weak symbols to register/unregister interface
>> -> Struct pdev_archdata could perhaps point out a per-mach/plat dev_pm_ops?
>
> registerable per-mach/plat ops structures sound sane. ?However, I
> think we can do better since this is not an arch-specific problem.
> Already ARM and SH needs a solution, and I can see it being applicable
> to the other embedded archs too. ?I'd like to see a non-arch-specific
> solution.

Yes, a more generic solution would be nice!

Cheers,

/ magnus

[linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Kevin Hilman]

Magnus Damm <magnus.damm@gmail.com> writes:

> On Thu, Aug 5, 2010 at 8:10 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Tue, Aug 3, 2010 at 9:56 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
>>> On Wed, Aug 4, 2010 at 1:16 AM, Kevin Hilman
>>> <khilman@deeprootsystems.com> wrote:
>>>> 2) custom vs. platform bus.
>>>>
>>>> The other issue under discussion between Grant & myself[1] has been the
>>>> use of a custom bus instead of the platform bus. ?Following your lead,
>>>> (and preferring that option) I continued to use the platform_bus since
>>>> I only need to override a few of the dev_pm_ops functions.
>>>>
>>>> However, Grant is not happy about overriding the platform_bus. ?He would
>>>> rather see each platform create a custom bus with it's own PM methods.
>>>>
>>>> In this thread[1], I did a quick and dirty proof of concept to show that
>>>> it is possible, but quite frankly, I still much prefer continuing to use
>>>> the platform_bus since it is mostly identical.
>>>>
>>>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/018925.html
>>>
>>> Thanks for the pointer. I've been thinking of using a custom bus as
>>> well, but from my point of view it's always looked like a lot of
>>> coding without any clear benefit. I understand the idea of wanting to
>>> use a single binary on a wide range of systems, and solving that seems
>>> like a good plan.
>>>
>>> I'm not sure if a custom bus is the best idea. I wouldn't mind being
>>> able to create platform bus instances though.
>>
>> The only problem with multiple platform_bus instances would be that
>> drivers intended to work on both would need to be registered twice;
>> once on the regular platform bus, and once on the custom bus. ?All the
>> rest of the code would be shared, but it probably still doesn't
>> reflect the model that you're shooting for.
>
> Do they really have to be registered twice? With the current driver
> model yes, but perhaps it's possible to adjust the platform bus to
> allow device<->driver matching across buses somehow. I would prefer to
> register drivers only once.

I would too.  My primary objection to the custom bus approach is because
I don't want drivers to have to care what bus (or SoC) they are
connected to.

Kevin

[linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata

[Kevin Hilman]

Grant Likely <grant.likely@secretlab.ca> writes:

> On Tue, Aug 3, 2010 at 10:16 AM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> Magnus Damm <magnus.damm@gmail.com> writes:
>>
>>> On Sun, Jul 25, 2010 at 5:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>>> "Magnus Damm" <magnus.damm@gmail.com> wrote:
>>>>>On Tue, Oct 27, 2009 at 8:13 AM, Kevin Hilman
>>>>><khilman@deeprootsystems.com> wrote:
>>>>>> Eric Miao <eric.y.miao@gmail.com> writes:
>>>>>>> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
>>>>>>> <khilman@deeprootsystems.com> wrote:
>>>>>>>> Mikael Pettersson wrote:
>>>>>>>>> Eric Miao writes:
>>>>>>>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>>>>>>> ?> <khilman@deeprootsystems.com> wrote:
>>>>>>>>> ?> > On ARM platforms, power management can be very platform specific.
>>>>>>>>> ?> > This patch allows ARM subarches to extend the platform_device
>>>>>>>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>>>>>>> ?> > and allowing each subarch to customize it as needed.
>>>
>>>>>Do you remember what happened with this patch?
>>>>
>>>> I don't have all the details in front of me because I'm on my phone,
>>>> but I advised against pdev_archdata because it is
>>>> multiplatform-unfriendly.
>>>
>>> Ok, I did not expect that. =) But after thinking a bit it does make
>>> sense. I wonder what my options are. I'm not so fond of the idea to
>>> wrap the platform devices - that's not more multi-platform friendly,
>>> is it?
>>
>> [sorry for the lag, been on vacation]
>>
>> Wrapping is more multi-platform friendly because only platform-specific
>> code accesses the wrapped code. ?It's also logically consistent as
>> a struct device is contained by a platform_device which is then
>> contained by an omap_device (in our case.) ? Only OMAP-specific code
>> ever knows about or touches that layer.
>
> (I just noticed this; will also reply on the other thread so it is
> recorded in the public record) But it is also really dangerous;
> particularly in the case of dynamically allocated platform_devices.
> When handed a random platform_device pointer, you have absolutely *no*
> idea whether or not it is valid to dereference a pointer at a lower
> address from the platform_device pointer.  It is very likely that
> there will be other code in the system that will register
> platform_devices without the omap_device wrapper.
>
>>> How about using devres and platform bus notifiers?
>>
>> That seems fine too, and probably better if the amount of data/code you need
>> is small. ?In the OMAP case, it's rather complicated so it's cleaner
>> IMHO to keep it in a separate omap_device layer and struct.
>
> but it is safe
>

/me is beaten into submission.  ;)

OK, it would not be too much work to move the OMAP implementation to
devres + notifiers either.  I can give it a spin.

Kevin