[v14,03/10] qcom: spm: Add Subsystem Power Manager driver

SPM is a hardware block that controls the peripheral logic surrounding
the application cores (cpu/l$). When the core executes WFI instruction,
the SPM takes over the putting the core in low power state as
configured. The wake up for the SPM is an interrupt at the GIC, which
then completes the rest of low power mode sequence and brings the core
out of low power mode.

The SPM has a set of control registers that configure the SPMs
individually based on the type of the core and the runtime conditions.
SPM is a finite state machine block to which a sequence is provided and
it interprets the bytes and executes them in sequence. Each low power
mode that the core can enter into is provided to the SPM as a sequence.

Configure the SPM to set the core (cpu or L2) into its low power mode,
the index of the first command in the sequence is set in the SPM_CTL
register. When the core executes ARM wfi instruction, it triggers the
SPM state machine to start executing from that index. The SPM state
machine waits until the interrupt occurs and starts executing the rest
of the sequence until it hits the end of the sequence. The end of the
sequence jumps the core out of its low power mode.

Add support for an idle driver to set up the SPM to place the core in
Standby or Standalone power collapse mode when the core is idle.

Based on work by: Mahesh Sivasubramanian <msivasub@codeaurora.org>,
Ai Li <ali@codeaurora.org>, Praveen Chidambaram <pchidamb@codeaurora.org>
Original tree available at -
git://codeaurora.org/quic/la/kernel/msm-3.10.git

Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
 .../devicetree/bindings/arm/msm/qcom,saw2.txt      |  31 +-
 drivers/soc/qcom/Kconfig                           |   8 +
 drivers/soc/qcom/Makefile                          |   1 +
 drivers/soc/qcom/spm.c                             | 338 +++++++++++++++++++++
 include/soc/qcom/pm.h                              |  31 ++
 5 files changed, 403 insertions(+), 6 deletions(-)
 create mode 100644 drivers/soc/qcom/spm.c
 create mode 100644 include/soc/qcom/pm.h

On Tue, Dec 02 2014 at 10:40 -0700, Lina Iyer wrote:
+
[...]
>+static int spm_dev_probe(struct platform_device *pdev)
>+{
>+	struct spm_driver_data *drv;
>+	struct resource *res;
>+	const struct of_device_id *match_id;
>+	void __iomem *addr;
>+	int cpu;
>+	struct cpuidle_device *dev;
>+
>+	drv = spm_get_drv(pdev, &cpu);
>+	if (!drv)
>+		return -EINVAL;
>+
>+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>+	drv->reg_base = devm_ioremap_resource(&pdev->dev, res);
>+	if (IS_ERR(drv->reg_base))
>+		return PTR_ERR(drv->reg_base);
>+
>+	match_id = of_match_node(spm_match_table, pdev->dev.of_node);
>+	if (!match_id)
>+		return -ENODEV;
>+
>+	drv->reg_data = match_id->data;
>+
>+	/* Write the SPM sequences first.. */
>+	addr = drv->reg_base + drv->reg_data->reg_offset[SPM_REG_SEQ_ENTRY];
>+	__iowrite32_copy(addr, drv->reg_data->seq,
>+			ARRAY_SIZE(drv->reg_data->seq) / 4);
>+
>+	/*
>+	 * ..and then the control registers.
>+	 * On some SoC if the control registers are written first and if the
>+	 * CPU was held in reset, the reset signal could trigger the SPM state
>+	 * machine, before the sequences are completely written.
>+	 */
>+	spm_register_write(drv, SPM_REG_CFG, drv->reg_data->spm_cfg);
>+	spm_register_write(drv, SPM_REG_DLY, drv->reg_data->spm_dly);
>+	spm_register_write(drv, SPM_REG_PMIC_DLY, drv->reg_data->pmic_dly);
>+	spm_register_write(drv, SPM_REG_PMIC_DATA_0,
>+				drv->reg_data->pmic_data[0]);
>+	spm_register_write(drv, SPM_REG_PMIC_DATA_1,
>+				drv->reg_data->pmic_data[1]);
>+
>+	per_cpu(cpu_spm_drv, cpu) = drv;
>+
>+	/* Register the cpuidle device for the cpu, we are ready for cpuidle */
>+	dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
>+	if (!dev)
>+		return -ENOMEM;
>+
>+	dev->cpu = cpu;
>+	return cpuidle_register_device(dev);
>+}
>+
>+static struct qcom_cpu_pm_ops lpm_ops = {
>+	.standby = qcom_cpu_standby,
>+	.spc = qcom_cpu_spc,
>+};
>+
>+static struct platform_device qcom_cpuidle_drv = {
>+	.name	= "qcom_cpuidle",
>+	.id	= -1,
>+	.dev.platform_data = &lpm_ops,
>+};
>+
>+static struct platform_driver spm_driver = {
>+	.probe = spm_dev_probe,
>+	.driver = {
>+		.name = "saw",
>+		.of_match_table = spm_match_table,
>+	},
>+};
>+
>+static int __init qcom_spm_init(void)
>+{
>+	int ret;
>+
>+	/*
>+	 * cpuidle driver need to registered before the cpuidle device
>+	 * for any cpu. Register the device for the the cpuidle driver.
>+	 */
>+	ret = platform_device_register(&qcom_cpuidle_drv);
>+	if (ret)
>+		return ret;
Stephen pointed out that we would have the platform device lying around
on a non-QCOM device when using multi_v7_defconfig.

So instead of doing this here, we could do this in the probe..

 if (!cpuidle_get_driver()) {
         int ret = platform_device_register(&qcom_cpuidle_drv);
         if (ret)
                 return ret;
 }

Would that be okay?

The successful probe indicates that we are on a QCOM SoC, and we have not
registered a cpuidle_driver before this.

Thanks,
Lina

>+
>+	return platform_driver_register(&spm_driver);
>+}
>+module_init(qcom_spm_init);
>+
>+MODULE_LICENSE("GPL v2");
>+MODULE_DESCRIPTION("SAW power controller driver");
>+MODULE_ALIAS("platform:saw");
>diff --git a/include/soc/qcom/pm.h b/include/soc/qcom/pm.h
>new file mode 100644
>index 0000000..d9a56d7
>--- /dev/null
>+++ b/include/soc/qcom/pm.h
>@@ -0,0 +1,31 @@
>+/*
>+ * Copyright (c) 2009-2014, The Linux Foundation. All rights reserved.
>+ *
>+ * This software is licensed under the terms of the GNU General Public
>+ * License version 2, as published by the Free Software Foundation, and
>+ * may be copied, distributed, and modified under those terms.
>+ *
>+ * 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.
>+ *
>+ */
>+
>+#ifndef __QCOM_PM_H
>+#define __QCOM_PM_H
>+
>+enum pm_sleep_mode {
>+	PM_SLEEP_MODE_STBY,
>+	PM_SLEEP_MODE_RET,
>+	PM_SLEEP_MODE_SPC,
>+	PM_SLEEP_MODE_PC,
>+	PM_SLEEP_MODE_NR,
>+};
>+
>+struct qcom_cpu_pm_ops {
>+	int (*standby)(void *data);
>+	int (*spc)(void *data);
>+};
>+
>+#endif  /* __QCOM_PM_H */
>-- 
>2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 12/03/2014 12:05 AM, Lina Iyer wrote:
> On Tue, Dec 02 2014 at 10:40 -0700, Lina Iyer wrote:
> +
> [...]

[ ... ]

>> +static int __init qcom_spm_init(void)
>> +{
>> +    int ret;
>> +
>> +    /*
>> +     * cpuidle driver need to registered before the cpuidle device
>> +     * for any cpu. Register the device for the the cpuidle driver.
>> +     */
>> +    ret = platform_device_register(&qcom_cpuidle_drv);
>> +    if (ret)
>> +        return ret;
> Stephen pointed out that we would have the platform device lying around
> on a non-QCOM device when using multi_v7_defconfig.

Perhaps I am missing the point, but this is not supposed to happen, no ?

> So instead of doing this here, we could do this in the probe..
>
> if (!cpuidle_get_driver()) {
>          int ret = platform_device_register(&qcom_cpuidle_drv);
>          if (ret)
>                  return ret;
> }
>
> Would that be okay?
>
> The successful probe indicates that we are on a QCOM SoC, and we have not
> registered a cpuidle_driver before this.
>
> Thanks,
> Lina
>
>> +
>> +    return platform_driver_register(&spm_driver);
>> +}
>> +module_init(qcom_spm_init);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("SAW power controller driver");
>> +MODULE_ALIAS("platform:saw");
>> diff --git a/include/soc/qcom/pm.h b/include/soc/qcom/pm.h
>> new file mode 100644
>> index 0000000..d9a56d7
>> --- /dev/null
>> +++ b/include/soc/qcom/pm.h
>> @@ -0,0 +1,31 @@
>> +/*
>> + * Copyright (c) 2009-2014, The Linux Foundation. All rights reserved.
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * 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.
>> + *
>> + */
>> +
>> +#ifndef __QCOM_PM_H
>> +#define __QCOM_PM_H
>> +
>> +enum pm_sleep_mode {
>> +    PM_SLEEP_MODE_STBY,
>> +    PM_SLEEP_MODE_RET,
>> +    PM_SLEEP_MODE_SPC,
>> +    PM_SLEEP_MODE_PC,
>> +    PM_SLEEP_MODE_NR,
>> +};
>> +
>> +struct qcom_cpu_pm_ops {
>> +    int (*standby)(void *data);
>> +    int (*spc)(void *data);
>> +};
>> +
>> +#endif  /* __QCOM_PM_H */
>> --
>> 2.1.0
>>

On Wed, Dec 03 2014 at 02:11 -0700, Daniel Lezcano wrote:
>On 12/03/2014 12:05 AM, Lina Iyer wrote:
>>On Tue, Dec 02 2014 at 10:40 -0700, Lina Iyer wrote:
>>+
>>[...]
>
>[ ... ]
>
>>>+static int __init qcom_spm_init(void)
>>>+{
>>>+    int ret;
>>>+
>>>+    /*
>>>+     * cpuidle driver need to registered before the cpuidle device
>>>+     * for any cpu. Register the device for the the cpuidle driver.
>>>+     */
>>>+    ret = platform_device_register(&qcom_cpuidle_drv);
>>>+    if (ret)
>>>+        return ret;
>>Stephen pointed out that we would have the platform device lying around
>>on a non-QCOM device when using multi_v7_defconfig.
>
>Perhaps I am missing the point, but this is not supposed to happen, no ?
>
This would happen, since the file would compile on multi_v7 and we would
initialize and register this device regardless. The cpuidle-qcom.c
driver probe would bail out looking for a matching compatible property.
So we would not register a cpuidle driver but the device would lay
around.

>>So instead of doing this here, we could do this in the probe..
>>
>>if (!cpuidle_get_driver()) {
>>         int ret = platform_device_register(&qcom_cpuidle_drv);
>>         if (ret)
>>                 return ret;
>>}
>>
>>Would that be okay?
>>
>>The successful probe indicates that we are on a QCOM SoC, and we have not
>>registered a cpuidle_driver before this.
>>
>>Thanks,
>>Lina
>>
>>>+
>>>+    return platform_driver_register(&spm_driver);
>>>+}
>>>+module_init(qcom_spm_init);
>>>+
>>>+MODULE_LICENSE("GPL v2");
>>>+MODULE_DESCRIPTION("SAW power controller driver");
>>>+MODULE_ALIAS("platform:saw");
>>>diff --git a/include/soc/qcom/pm.h b/include/soc/qcom/pm.h
>>>new file mode 100644
>>>index 0000000..d9a56d7
>>>--- /dev/null
>>>+++ b/include/soc/qcom/pm.h
>>>@@ -0,0 +1,31 @@
>>>+/*
>>>+ * Copyright (c) 2009-2014, The Linux Foundation. All rights reserved.
>>>+ *
>>>+ * This software is licensed under the terms of the GNU General Public
>>>+ * License version 2, as published by the Free Software Foundation, and
>>>+ * may be copied, distributed, and modified under those terms.
>>>+ *
>>>+ * 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.
>>>+ *
>>>+ */
>>>+
>>>+#ifndef __QCOM_PM_H
>>>+#define __QCOM_PM_H
>>>+
>>>+enum pm_sleep_mode {
>>>+    PM_SLEEP_MODE_STBY,
>>>+    PM_SLEEP_MODE_RET,
>>>+    PM_SLEEP_MODE_SPC,
>>>+    PM_SLEEP_MODE_PC,
>>>+    PM_SLEEP_MODE_NR,
>>>+};
>>>+
>>>+struct qcom_cpu_pm_ops {
>>>+    int (*standby)(void *data);
>>>+    int (*spc)(void *data);
>>>+};
>>>+
>>>+#endif  /* __QCOM_PM_H */
>>>--
>>>2.1.0
>>>
>
>
>-- 
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
>Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
><http://twitter.com/#!/linaroorg> Twitter |
><http://www.linaro.org/linaro-blog/> Blog
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, Dec 03 2014 at 07:31 -0700, Lina Iyer wrote:
>On Wed, Dec 03 2014 at 02:11 -0700, Daniel Lezcano wrote:
>>On 12/03/2014 12:05 AM, Lina Iyer wrote:
>>>On Tue, Dec 02 2014 at 10:40 -0700, Lina Iyer wrote:
>>>+
>>>[...]
>>
>>[ ... ]
>>
>>>>+static int __init qcom_spm_init(void)
>>>>+{
>>>>+    int ret;
>>>>+
>>>>+    /*
>>>>+     * cpuidle driver need to registered before the cpuidle device
>>>>+     * for any cpu. Register the device for the the cpuidle driver.
>>>>+     */
>>>>+    ret = platform_device_register(&qcom_cpuidle_drv);
>>>>+    if (ret)
>>>>+        return ret;
>>>Stephen pointed out that we would have the platform device lying around
>>>on a non-QCOM device when using multi_v7_defconfig.
>>
>>Perhaps I am missing the point, but this is not supposed to happen, no ?
>>
>This would happen, since the file would compile on multi_v7 and we would
>initialize and register this device regardless. The cpuidle-qcom.c
>driver probe would bail out looking for a matching compatible property.
>So we would not register a cpuidle driver but the device would lay
>around.
>
Not the best thing to do, but I noticed that ACPI driver does reference
count to register cpuidle driver for the first device and remove them as
the reference count decreases. I am not sure, if we need to reference
count here, since the SPM devices themselves are not removable.

>>>So instead of doing this here, we could do this in the probe..
>>>
>>>if (!cpuidle_get_driver()) {
>>>        int ret = platform_device_register(&qcom_cpuidle_drv);
>>>        if (ret)
>>>                return ret;
>>>}
>>>
>>>Would that be okay?
>>>
>>>The successful probe indicates that we are on a QCOM SoC, and we have not
>>>registered a cpuidle_driver before this.
>>>
>>>Thanks,
>>>Lina
>>>
>>>>+
>>>>+    return platform_driver_register(&spm_driver);
>>>>+}
>>>>+module_init(qcom_spm_init);
>>>>+
>>>>+MODULE_LICENSE("GPL v2");
>>>>+MODULE_DESCRIPTION("SAW power controller driver");
>>>>+MODULE_ALIAS("platform:saw");
>>>>diff --git a/include/soc/qcom/pm.h b/include/soc/qcom/pm.h
>>>>new file mode 100644
>>>>index 0000000..d9a56d7
>>>>--- /dev/null
>>>>+++ b/include/soc/qcom/pm.h
>>>>@@ -0,0 +1,31 @@
>>>>+/*
>>>>+ * Copyright (c) 2009-2014, The Linux Foundation. All rights reserved.
>>>>+ *
>>>>+ * This software is licensed under the terms of the GNU General Public
>>>>+ * License version 2, as published by the Free Software Foundation, and
>>>>+ * may be copied, distributed, and modified under those terms.
>>>>+ *
>>>>+ * 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.
>>>>+ *
>>>>+ */
>>>>+
>>>>+#ifndef __QCOM_PM_H
>>>>+#define __QCOM_PM_H
>>>>+
>>>>+enum pm_sleep_mode {
>>>>+    PM_SLEEP_MODE_STBY,
>>>>+    PM_SLEEP_MODE_RET,
>>>>+    PM_SLEEP_MODE_SPC,
>>>>+    PM_SLEEP_MODE_PC,
>>>>+    PM_SLEEP_MODE_NR,
>>>>+};
>>>>+
>>>>+struct qcom_cpu_pm_ops {
>>>>+    int (*standby)(void *data);
>>>>+    int (*spc)(void *data);
>>>>+};
>>>>+
>>>>+#endif  /* __QCOM_PM_H */
>>>>--
>>>>2.1.0
>>>>
>>
>>
>>-- 
>><http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>>Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>><http://twitter.com/#!/linaroorg> Twitter |
>><http://www.linaro.org/linaro-blog/> Blog
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wednesday 03 December 2014 07:31:22 Lina Iyer wrote:
> >>>+static int __init qcom_spm_init(void)
> >>>+{
> >>>+    int ret;
> >>>+
> >>>+    /*
> >>>+     * cpuidle driver need to registered before the cpuidle device
> >>>+     * for any cpu. Register the device for the the cpuidle driver.
> >>>+     */
> >>>+    ret = platform_device_register(&qcom_cpuidle_drv);
> >>>+    if (ret)
> >>>+        return ret;
> >>Stephen pointed out that we would have the platform device lying around
> >>on a non-QCOM device when using multi_v7_defconfig.
> >
> >Perhaps I am missing the point, but this is not supposed to happen, no ?
> >
> This would happen, since the file would compile on multi_v7 and we would
> initialize and register this device regardless. The cpuidle-qcom.c
> driver probe would bail out looking for a matching compatible property.
> So we would not register a cpuidle driver but the device would lay
> around.

I think the problem is registering a platform_device. I've complained
about this before, but it still seems to get copied all over the
place. Please don't do this but have a driver that looks at DT to
figure out whether to access hardware or not.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 12/03/2014 09:35 PM, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 07:31:22 Lina Iyer wrote:
>>>>> +static int __init qcom_spm_init(void)
>>>>> +{
>>>>> +    int ret;
>>>>> +
>>>>> +    /*
>>>>> +     * cpuidle driver need to registered before the cpuidle device
>>>>> +     * for any cpu. Register the device for the the cpuidle driver.
>>>>> +     */
>>>>> +    ret = platform_device_register(&qcom_cpuidle_drv);
>>>>> +    if (ret)
>>>>> +        return ret;
>>>> Stephen pointed out that we would have the platform device lying around
>>>> on a non-QCOM device when using multi_v7_defconfig.
>>>
>>> Perhaps I am missing the point, but this is not supposed to happen, no ?
>>>
>> This would happen, since the file would compile on multi_v7 and we would
>> initialize and register this device regardless. The cpuidle-qcom.c
>> driver probe would bail out looking for a matching compatible property.
>> So we would not register a cpuidle driver but the device would lay
>> around.
>
> I think the problem is registering a platform_device. I've complained
> about this before, but it still seems to get copied all over the
> place. Please don't do this but have a driver that looks at DT to
> figure out whether to access hardware or not.

We did this approach but, I can remember why, someone was complaining 
about it also :)

The platform device/driver paradigm allowed us to split the arch 
specific parts by passing the pm ops through the platform data.

Would make sense to have a single common place for the ARM arch where we 
initialize the platform device for cpuidle ?

On Thursday 04 December 2014 09:52:39 Daniel Lezcano wrote:
> On 12/03/2014 09:35 PM, Arnd Bergmann wrote:
> > On Wednesday 03 December 2014 07:31:22 Lina Iyer wrote:
> >>>>> +static int __init qcom_spm_init(void)
> >>>>> +{
> >>>>> +    int ret;
> >>>>> +
> >>>>> +    /*
> >>>>> +     * cpuidle driver need to registered before the cpuidle device
> >>>>> +     * for any cpu. Register the device for the the cpuidle driver.
> >>>>> +     */
> >>>>> +    ret = platform_device_register(&qcom_cpuidle_drv);
> >>>>> +    if (ret)
> >>>>> +        return ret;
> >>>> Stephen pointed out that we would have the platform device lying around
> >>>> on a non-QCOM device when using multi_v7_defconfig.
> >>>
> >>> Perhaps I am missing the point, but this is not supposed to happen, no ?
> >>>
> >> This would happen, since the file would compile on multi_v7 and we would
> >> initialize and register this device regardless. The cpuidle-qcom.c
> >> driver probe would bail out looking for a matching compatible property.
> >> So we would not register a cpuidle driver but the device would lay
> >> around.
> >
> > I think the problem is registering a platform_device. I've complained
> > about this before, but it still seems to get copied all over the
> > place. Please don't do this but have a driver that looks at DT to
> > figure out whether to access hardware or not.
> 
> We did this approach but, I can remember why, someone was complaining 
> about it also 
> 
> The platform device/driver paradigm allowed us to split the arch 
> specific parts by passing the pm ops through the platform data.
> 
> Would make sense to have a single common place for the ARM arch where we 
> initialize the platform device for cpuidle ?

No. It's really not a device, and if you pretend that it is, you get
into problems like this.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Dec 04 2014 at 02:02 -0700, Arnd Bergmann wrote:
>On Thursday 04 December 2014 09:52:39 Daniel Lezcano wrote:
>> On 12/03/2014 09:35 PM, Arnd Bergmann wrote:
>> > On Wednesday 03 December 2014 07:31:22 Lina Iyer wrote:
>> >>>>> +static int __init qcom_spm_init(void)
>> >>>>> +{
>> >>>>> +    int ret;
>> >>>>> +
>> >>>>> +    /*
>> >>>>> +     * cpuidle driver need to registered before the cpuidle device
>> >>>>> +     * for any cpu. Register the device for the the cpuidle driver.
>> >>>>> +     */
>> >>>>> +    ret = platform_device_register(&qcom_cpuidle_drv);
>> >>>>> +    if (ret)
>> >>>>> +        return ret;
>> >>>> Stephen pointed out that we would have the platform device lying around
>> >>>> on a non-QCOM device when using multi_v7_defconfig.
>> >>>
>> >>> Perhaps I am missing the point, but this is not supposed to happen, no ?
>> >>>
>> >> This would happen, since the file would compile on multi_v7 and we would
>> >> initialize and register this device regardless. The cpuidle-qcom.c
>> >> driver probe would bail out looking for a matching compatible property.
>> >> So we would not register a cpuidle driver but the device would lay
>> >> around.
>> >
>> > I think the problem is registering a platform_device. I've complained
>> > about this before, but it still seems to get copied all over the
>> > place. Please don't do this but have a driver that looks at DT to
>> > figure out whether to access hardware or not.
>>
>> We did this approach but, I can remember why, someone was complaining
>> about it also
>>
>> The platform device/driver paradigm allowed us to split the arch
>> specific parts by passing the pm ops through the platform data.
>>
>> Would make sense to have a single common place for the ARM arch where we
>> initialize the platform device for cpuidle ?
>
>No. It's really not a device, and if you pretend that it is, you get
>into problems like this.

Arnd, the problem is that the provides function pointers to the SoC code
that the cpuilde driver uses to call based on the idle state.

After much discussions, we came down to using function pointers from
translating from DT strings, other than using that again, I dont see a
good way of achieving the ability of cpuidle driver staying a separate
driver from the SPM driver.

Daniel, thoughts?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thursday 04 December 2014 09:28:34 Lina Iyer wrote:
> On Thu, Dec 04 2014 at 02:02 -0700, Arnd Bergmann wrote:
> >On Thursday 04 December 2014 09:52:39 Daniel Lezcano wrote:
> >> On 12/03/2014 09:35 PM, Arnd Bergmann wrote:
> >> > On Wednesday 03 December 2014 07:31:22 Lina Iyer wrote:
> >> >>>>> +static int __init qcom_spm_init(void)
> >> >>>>> +{
> >> >>>>> +    int ret;
> >> >>>>> +
> >> >>>>> +    /*
> >> >>>>> +     * cpuidle driver need to registered before the cpuidle device
> >> >>>>> +     * for any cpu. Register the device for the the cpuidle driver.
> >> >>>>> +     */
> >> >>>>> +    ret = platform_device_register(&qcom_cpuidle_drv);
> >> >>>>> +    if (ret)
> >> >>>>> +        return ret;
> >> >>>> Stephen pointed out that we would have the platform device lying around
> >> >>>> on a non-QCOM device when using multi_v7_defconfig.
> >> >>>
> >> >>> Perhaps I am missing the point, but this is not supposed to happen, no ?
> >> >>>
> >> >> This would happen, since the file would compile on multi_v7 and we would
> >> >> initialize and register this device regardless. The cpuidle-qcom.c
> >> >> driver probe would bail out looking for a matching compatible property.
> >> >> So we would not register a cpuidle driver but the device would lay
> >> >> around.
> >> >
> >> > I think the problem is registering a platform_device. I've complained
> >> > about this before, but it still seems to get copied all over the
> >> > place. Please don't do this but have a driver that looks at DT to
> >> > figure out whether to access hardware or not.
> >>
> >> We did this approach but, I can remember why, someone was complaining
> >> about it also
> >>
> >> The platform device/driver paradigm allowed us to split the arch
> >> specific parts by passing the pm ops through the platform data.
> >>
> >> Would make sense to have a single common place for the ARM arch where we
> >> initialize the platform device for cpuidle ?
> >
> >No. It's really not a device, and if you pretend that it is, you get
> >into problems like this.
> 
> Arnd, the problem is that the provides function pointers to the SoC code
> that the cpuilde driver uses to call based on the idle state.
> 
> After much discussions, we came down to using function pointers from
> translating from DT strings, other than using that again, I dont see a
> good way of achieving the ability of cpuidle driver staying a separate
> driver from the SPM driver.
> 
> Daniel, thoughts?

Maybe the problem is trying too hard to separate two things that really
belong together then. In general, the strategy of coming up with subsystems
for a class of devices and them turning platform code into drivers for
that subsystem has worked out really well, but I think for cpufreq, cpuidle
and smp, it really hasn't, and in the third case we haven't even tried
coming up with a subsystem for that reason.

Having all cpuidle code generally live in drivers/cpuidle is still a good
idea IMO, but using a platform device just for the purpose of passing
data between some platform specific code and another platform specific
driver hasn't worked out that well here.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, Dec 04 2014 at 11:20 -0700, Arnd Bergmann wrote:
>On Thursday 04 December 2014 09:28:34 Lina Iyer wrote:
>> On Thu, Dec 04 2014 at 02:02 -0700, Arnd Bergmann wrote:
>> >On Thursday 04 December 2014 09:52:39 Daniel Lezcano wrote:
>> >> On 12/03/2014 09:35 PM, Arnd Bergmann wrote:
>> >> > On Wednesday 03 December 2014 07:31:22 Lina Iyer wrote:
>> >> >>>>> +static int __init qcom_spm_init(void)
>> >> >>>>> +{
>> >> >>>>> +    int ret;
>> >> >>>>> +
>> >> >>>>> +    /*
>> >> >>>>> +     * cpuidle driver need to registered before the cpuidle device
>> >> >>>>> +     * for any cpu. Register the device for the the cpuidle driver.
>> >> >>>>> +     */
>> >> >>>>> +    ret = platform_device_register(&qcom_cpuidle_drv);
>> >> >>>>> +    if (ret)
>> >> >>>>> +        return ret;
>> >> >>>> Stephen pointed out that we would have the platform device lying around
>> >> >>>> on a non-QCOM device when using multi_v7_defconfig.
>> >> >>>
>> >> >>> Perhaps I am missing the point, but this is not supposed to happen, no ?
>> >> >>>
>> >> >> This would happen, since the file would compile on multi_v7 and we would
>> >> >> initialize and register this device regardless. The cpuidle-qcom.c
>> >> >> driver probe would bail out looking for a matching compatible property.
>> >> >> So we would not register a cpuidle driver but the device would lay
>> >> >> around.
>> >> >
>> >> > I think the problem is registering a platform_device. I've complained
>> >> > about this before, but it still seems to get copied all over the
>> >> > place. Please don't do this but have a driver that looks at DT to
>> >> > figure out whether to access hardware or not.
>> >>
>> >> We did this approach but, I can remember why, someone was complaining
>> >> about it also
>> >>
>> >> The platform device/driver paradigm allowed us to split the arch
>> >> specific parts by passing the pm ops through the platform data.
>> >>
>> >> Would make sense to have a single common place for the ARM arch where we
>> >> initialize the platform device for cpuidle ?
>> >
>> >No. It's really not a device, and if you pretend that it is, you get
>> >into problems like this.
>>
>> Arnd, the problem is that the provides function pointers to the SoC code
>> that the cpuilde driver uses to call based on the idle state.
>>
>> After much discussions, we came down to using function pointers from
>> translating from DT strings, other than using that again, I dont see a
>> good way of achieving the ability of cpuidle driver staying a separate
>> driver from the SPM driver.
>>
>> Daniel, thoughts?
>
>Maybe the problem is trying too hard to separate two things that really
>belong together then. In general, the strategy of coming up with subsystems
>for a class of devices and them turning platform code into drivers for
>that subsystem has worked out really well, but I think for cpufreq, cpuidle
>and smp, it really hasn't, and in the third case we haven't even tried
>coming up with a subsystem for that reason.
>
>Having all cpuidle code generally live in drivers/cpuidle is still a good
>idea IMO, but using a platform device just for the purpose of passing
>data between some platform specific code and another platform specific
>driver hasn't worked out that well here.
>
To achieve both, I cant think of a better way to initialize the cpuidle
driver without the use of reference count (0 ==>
platform_driver_register).

I tried creating dummy platform device in the DT but something or
another gives in to an ugly implementation.

Any other ideas?

Lina.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tuesday 16 December 2014 15:12:22 Daniel Lezcano wrote:
> At the beginning, all that become from not including mach files from the 
> drivers directory which make sense.
> 
> Perhaps it is time to write a similar mechanism for the cpuidle drivers 
> where we can still separate the low level PM code from the generic 
> cpuidle code.

That way you basically duplicate the same thing we already have, which
isn't much better.

In the example of drivers/soc/qcom/spm.c, just call cpuidle_register
from the spm_dev_probe() function and be done with it. You already
have a device that is responsible for handling this, don't try to
construct more than you already need.

I would assume that the same can be done for most other platforms.

There are probably cases where the same piece of hardware is responsible
for both cpuidle and cpufreq, but what that means is really that you
should have a single driver for it that does both things. Same for
SMP support: if you have one register block that does both the SMP
bringup and the cpuidle stuff, then have *one* driver for this block
that does it all. There are currently a few dependencies that require
doing SMP bringup early during boot, but we decided years ago that those
are all artificial dependencies and we should be able to boot secondary
CPUs much later than we currently do.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Friday 05 December 2014 08:45:26 Lina Iyer wrote:
> On Thu, Dec 04 2014 at 11:20 -0700, Arnd Bergmann wrote:
> >On Thursday 04 December 2014 09:28:34 Lina Iyer wrote:

> >Having all cpuidle code generally live in drivers/cpuidle is still a good
> >idea IMO, but using a platform device just for the purpose of passing
> >data between some platform specific code and another platform specific
> >driver hasn't worked out that well here.
> >
> To achieve both, I cant think of a better way to initialize the cpuidle
> driver without the use of reference count (0 ==>
> platform_driver_register).
> 
> I tried creating dummy platform device in the DT but something or
> another gives in to an ugly implementation.
> 
> Any other ideas?

Hi Lina,

sorry for missing your mail earlier, I just replied to Daniel on this
topic, when the thread popped up again.
	
	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 12/16/2014 06:38 AM, Arnd Bergmann wrote:
> On Tuesday 16 December 2014 15:12:22 Daniel Lezcano wrote:
>> At the beginning, all that become from not including mach files from the 
>> drivers directory which make sense.
>>
>> Perhaps it is time to write a similar mechanism for the cpuidle drivers 
>> where we can still separate the low level PM code from the generic 
>> cpuidle code.
> That way you basically duplicate the same thing we already have, which
> isn't much better.
>
> In the example of drivers/soc/qcom/spm.c, just call cpuidle_register
> from the spm_dev_probe() function and be done with it. You already
> have a device that is responsible for handling this, don't try to
> construct more than you already need.
>
> I would assume that the same can be done for most other platforms.
>
> There are probably cases where the same piece of hardware is responsible
> for both cpuidle and cpufreq, but what that means is really that you
> should have a single driver for it that does both things. Same for
> SMP support: if you have one register block that does both the SMP
> bringup and the cpuidle stuff, then have *one* driver for this block
> that does it all. There are currently a few dependencies that require
> doing SMP bringup early during boot, but we decided years ago that those
> are all artificial dependencies and we should be able to boot secondary
> CPUs much later than we currently do.
>

+1. The SPM harware is used for hotplug, suspend, cpuidle, as well as
provides a regulator for a CPU, so all these things should be done in a
single driver. Booting secondary CPUs early is not hard here either if
we move the smp ops into the same driver. The only downside then is that
it can't be a module, but I would guess that we can work on making that
possible by allowing smp ops to be inserted and removed at any time.

On Tuesday 16 December 2014 11:18:18 Stephen Boyd wrote:
> On 12/16/2014 06:38 AM, Arnd Bergmann wrote:
> > On Tuesday 16 December 2014 15:12:22 Daniel Lezcano wrote:
> >> At the beginning, all that become from not including mach files from the 
> >> drivers directory which make sense.
> >>
> >> Perhaps it is time to write a similar mechanism for the cpuidle drivers 
> >> where we can still separate the low level PM code from the generic 
> >> cpuidle code.
> > That way you basically duplicate the same thing we already have, which
> > isn't much better.
> >
> > In the example of drivers/soc/qcom/spm.c, just call cpuidle_register
> > from the spm_dev_probe() function and be done with it. You already
> > have a device that is responsible for handling this, don't try to
> > construct more than you already need.
> >
> > I would assume that the same can be done for most other platforms.
> >
> > There are probably cases where the same piece of hardware is responsible
> > for both cpuidle and cpufreq, but what that means is really that you
> > should have a single driver for it that does both things. Same for
> > SMP support: if you have one register block that does both the SMP
> > bringup and the cpuidle stuff, then have *one* driver for this block
> > that does it all. There are currently a few dependencies that require
> > doing SMP bringup early during boot, but we decided years ago that those
> > are all artificial dependencies and we should be able to boot secondary
> > CPUs much later than we currently do.
> >
> 
> +1. The SPM harware is used for hotplug, suspend, cpuidle, as well as
> provides a regulator for a CPU, so all these things should be done in a
> single driver. Booting secondary CPUs early is not hard here either if
> we move the smp ops into the same driver. The only downside then is that
> it can't be a module, but I would guess that we can work on making that
> possible by allowing smp ops to be inserted and removed at any time.

Right, I don't see modular SMP operations happening any time soon,
but it also doesn't seem like a fundamental restriction.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 12/16/2014 03:38 PM, Arnd Bergmann wrote:
> On Tuesday 16 December 2014 15:12:22 Daniel Lezcano wrote:
>> At the beginning, all that become from not including mach files from the
>> drivers directory which make sense.
>>
>> Perhaps it is time to write a similar mechanism for the cpuidle drivers
>> where we can still separate the low level PM code from the generic
>> cpuidle code.
>
> That way you basically duplicate the same thing we already have, which
> isn't much better.
>
> In the example of drivers/soc/qcom/spm.c, just call cpuidle_register
> from the spm_dev_probe() function and be done with it. You already
> have a device that is responsible for handling this, don't try to
> construct more than you already need.

If you have to call cpuidle_register, then the cpuidle_driver should be 
provided with all the idle states definition and so on.

That is exactly the opposite of what we have been doing since a couple 
of years where each SoC had their own driver, in their own directory and 
duplicating the code again and again from one platform to another platform.

The changes we have been through cleaned up most of the situation but 
still we have more to do and I would like to prevent stepping back or 
give the opportunity to step back.

I don't think we separated code which is not supposed to be. That has a 
positive side effect of cleaning up the drivers.

Also, I understand your point and I am willing to solve this issue but 
still by keeping the pm low level code separated from the cpuidle driver.

> I would assume that the same can be done for most other platforms.
>
> There are probably cases where the same piece of hardware is responsible
> for both cpuidle and cpufreq, but what that means is really that you
> should have a single driver for it that does both things. Same for
> SMP support: if you have one register block that does both the SMP
> bringup and the cpuidle stuff, then have *one* driver for this block
> that does it all. There are currently a few dependencies that require
> doing SMP bringup early during boot, but we decided years ago that those
> are all artificial dependencies and we should be able to boot secondary
> CPUs much later than we currently do.

I agree with this point and given the number of drivers, the easiest way 
to do that is to create cpu pm ops as I gave in the previous email and 
reuse them for cpu hotplug/bringup. And I believe that is possible if we 
continue our approach by splitting the low level pm code from the 
cpuidle driver.

What about doing something simple ? Like creating a struct 
arm_cpu_pm_ops variable visible from everywhere and filled by the 
different platform ?

On Wed, Dec 17, 2014 at 01:15:28PM +0000, Daniel Lezcano wrote:

[...]

> > I would assume that the same can be done for most other platforms.
> >
> > There are probably cases where the same piece of hardware is responsible
> > for both cpuidle and cpufreq, but what that means is really that you
> > should have a single driver for it that does both things. Same for
> > SMP support: if you have one register block that does both the SMP
> > bringup and the cpuidle stuff, then have *one* driver for this block
> > that does it all. There are currently a few dependencies that require
> > doing SMP bringup early during boot, but we decided years ago that those
> > are all artificial dependencies and we should be able to boot secondary
> > CPUs much later than we currently do.
> 
> I agree with this point and given the number of drivers, the easiest way 
> to do that is to create cpu pm ops as I gave in the previous email and 
> reuse them for cpu hotplug/bringup. And I believe that is possible if we 
> continue our approach by splitting the low level pm code from the 
> cpuidle driver.
> 
> What about doing something simple ? Like creating a struct 
> arm_cpu_pm_ops variable visible from everywhere and filled by the 
> different platform ?

I agree with this approach, which by the way consists in defining
cpu operations as ARM64 does and use those from cpuidle, suspend and
hotplug code. The MCPM interface does that already, probably we should
enhance/rename it since people think it must be used for multicluster
power management whereas it is a pretty generic [drivers -> mach] code
interface (I am talking about the API, not the synchronization scheme),
and can certainly be extended/refactored according to new platforms need.

Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Dec 16 2014 at 12:18 -0700, Stephen Boyd wrote:
>On 12/16/2014 06:38 AM, Arnd Bergmann wrote:
>> On Tuesday 16 December 2014 15:12:22 Daniel Lezcano wrote:
>>> At the beginning, all that become from not including mach files from the
>>> drivers directory which make sense.
>>>
>>> Perhaps it is time to write a similar mechanism for the cpuidle drivers
>>> where we can still separate the low level PM code from the generic
>>> cpuidle code.
>> That way you basically duplicate the same thing we already have, which
>> isn't much better.
>>
>> In the example of drivers/soc/qcom/spm.c, just call cpuidle_register
>> from the spm_dev_probe() function and be done with it. You already
>> have a device that is responsible for handling this, don't try to
>> construct more than you already need.
>>
>> I would assume that the same can be done for most other platforms.
>>
>> There are probably cases where the same piece of hardware is responsible
>> for both cpuidle and cpufreq, but what that means is really that you
>> should have a single driver for it that does both things. Same for
>> SMP support: if you have one register block that does both the SMP
>> bringup and the cpuidle stuff, then have *one* driver for this block
>> that does it all. There are currently a few dependencies that require
>> doing SMP bringup early during boot, but we decided years ago that those
>> are all artificial dependencies and we should be able to boot secondary
>> CPUs much later than we currently do.
>>
>
>+1. The SPM harware is used for hotplug, suspend, cpuidle, as well as
>provides a regulator for a CPU, so all these things should be done in a
>single driver. Booting secondary CPUs early is not hard here either if
>we move the smp ops into the same driver. The only downside then is that
>it can't be a module, but I would guess that we can work on making that
>possible by allowing smp ops to be inserted and removed at any time.
>
I am not sure, just because the hardware supports multiple
functionality, everything should go into the same file.

If you think of a SPM driver as something that provides a service, you
would see that all the functionality of cpuidle, hotplug, suspend, use
the service and can have their own place to share their commonality. SPM
h/w is not just for cpus. It could be a generic power controller (to an
extent) for the cpu, cache, coherenency interface and pretty much any
bus/clock exports the services of that device. There needs to be a
distinction between an entity that provides the functionality and a one
that uses it. You cannot build on additional functionality neatly if you
have them all together.

As such, I am quite appalled by the addition of the idle functions in
the SPM driver, but seems like its the direction many want, hence went
with it. But, please dont suggest using SPM driver as a dumping ground
for all functionality that SPM may indirectly influence.

Thanks,
Lina
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html