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
On Wed, Dec 17, 2014 at 01:15:28PM +, 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
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
On 12/04/2014 07:20 PM, 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
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
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
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
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
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
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
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
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;
+
+/*
+
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
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
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
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;
+
+/*
+
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 =
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
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
19 matches
Mail list logo
