Re: [PATCH v5 00/14] CPU idle for Armada XP

2014-03-26 Thread Gregory CLEMENT
On 26/03/2014 01:42, Jason Cooper wrote:
> Gregory,
> 
> On Tue, Mar 25, 2014 at 11:48:11PM +0100, Gregory CLEMENT wrote:
> ...
>> The first patch should go through ARM subsystem and should be taken by
>> Russell King. I made few change on it following Lorenzo advice and
>> now it will reuse the cpu v7 suspend and resume function and just do
>> specific operation before calling them.
>>
>> The 13th patch 'cpuidle: mvebu: Add initial cpu idle support for
>> Armada 370/XP SoC' is the only one who should go to the cpuidle
>> subsystem. But of course I would like that Daniel Lezcano or Rafael
>> J. Wysocki have a look on the whole series and especially patches 10,
>> 12 and 14.
> 
> Ok, I'm tired.  :)  Help me out here.  Patches 1 and 13 are depended on
> by the other patches and vice-versa, right?  In that case, I'm thinking
> it's best to seek Acks from the other maintainers and keep the whole
> branch together.  Please tell me if I'm wrong.
> 

Actually for the build there is no dependencies between patch 1, 13 and the
other ones.

About running the kernel obviously you need the full series to have the CPU
idle working, but if patch 13 is not applied or if it is applied alone, the
kernel won't crash, the only consequence will be that the cpu idle driver won't
be loaded.

If all patches are applied except patch 1 then we could experiment some issues.
However, now the the amount of code is very small in this patch, I planed
to submit it to Russell King's patch system soon.

About patch 13, I agree that if Daniel and Rafael agree to give their acked-by,
it will be easier to handle if you can take it in a single series, but it is not
mandatory.

Thanks,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v5 00/14] CPU idle for Armada XP

2014-03-26 Thread Gregory CLEMENT
On 26/03/2014 01:42, Jason Cooper wrote:
 Gregory,
 
 On Tue, Mar 25, 2014 at 11:48:11PM +0100, Gregory CLEMENT wrote:
 ...
 The first patch should go through ARM subsystem and should be taken by
 Russell King. I made few change on it following Lorenzo advice and
 now it will reuse the cpu v7 suspend and resume function and just do
 specific operation before calling them.

 The 13th patch 'cpuidle: mvebu: Add initial cpu idle support for
 Armada 370/XP SoC' is the only one who should go to the cpuidle
 subsystem. But of course I would like that Daniel Lezcano or Rafael
 J. Wysocki have a look on the whole series and especially patches 10,
 12 and 14.
 
 Ok, I'm tired.  :)  Help me out here.  Patches 1 and 13 are depended on
 by the other patches and vice-versa, right?  In that case, I'm thinking
 it's best to seek Acks from the other maintainers and keep the whole
 branch together.  Please tell me if I'm wrong.
 

Actually for the build there is no dependencies between patch 1, 13 and the
other ones.

About running the kernel obviously you need the full series to have the CPU
idle working, but if patch 13 is not applied or if it is applied alone, the
kernel won't crash, the only consequence will be that the cpu idle driver won't
be loaded.

If all patches are applied except patch 1 then we could experiment some issues.
However, now the the amount of code is very small in this patch, I planed
to submit it to Russell King's patch system soon.

About patch 13, I agree that if Daniel and Rafael agree to give their acked-by,
it will be easier to handle if you can take it in a single series, but it is not
mandatory.

Thanks,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v5 00/14] CPU idle for Armada XP

2014-03-25 Thread Jason Cooper
Gregory,

On Tue, Mar 25, 2014 at 11:48:11PM +0100, Gregory CLEMENT wrote:
...
> The first patch should go through ARM subsystem and should be taken by
> Russell King. I made few change on it following Lorenzo advice and
> now it will reuse the cpu v7 suspend and resume function and just do
> specific operation before calling them.
> 
> The 13th patch 'cpuidle: mvebu: Add initial cpu idle support for
> Armada 370/XP SoC' is the only one who should go to the cpuidle
> subsystem. But of course I would like that Daniel Lezcano or Rafael
> J. Wysocki have a look on the whole series and especially patches 10,
> 12 and 14.

Ok, I'm tired.  :)  Help me out here.  Patches 1 and 13 are depended on
by the other patches and vice-versa, right?  In that case, I'm thinking
it's best to seek Acks from the other maintainers and keep the whole
branch together.  Please tell me if I'm wrong.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v5 00/14] CPU idle for Armada XP

2014-03-25 Thread Gregory CLEMENT
Hello,

This patch set adds the CPU idle support for Armada XP and prepares
the support for Armada 370. This was based on the work of Nadav
Haklai.

As for the last version there were many changes done, see the
changelog for the details. And again I think that I should have
managed to comply with all the reviewer wishes.

A notable change is that patches 7 and 8 are here to have a coherent
series, but they will be part of a different series which will be send
soon, so don't focus too much on it. These 2 patches introduce a new
compatible string for PMSU which will be needed for CPU idle
(obviously) but also for the SMP support for Armada 375 and Armada
38x. So instead of having SMP for Armada 375/38x depending on CPU idle
for Armada XP or the opposite we choose to submit soon a small series
needed for those two bigger series.

Most of the patches modify the mvebu code in order to prepare the
support for CPU idle, hence the patches 2 to 6 and from 9 to 12 should
go to mvebu subsystem (and then arm-soc).

The first patch should go through ARM subsystem and should be taken by
Russell King. I made few change on it following Lorenzo advice and
now it will reuse the cpu v7 suspend and resume function and just do
specific operation before calling them.

The 13th patch 'cpuidle: mvebu: Add initial cpu idle support for
Armada 370/XP SoC' is the only one who should go to the cpuidle
subsystem. But of course I would like that Daniel Lezcano or Rafael
J. Wysocki have a look on the whole series and especially patches 10,
12 and 14.

The 14th patch should go to mvebu subsystem.

The whole series is also available in the branch CPU-idle-ArmadaXP-v5
at https://github.com/MISL-EBU-System-SW/mainline-public.git

Thanks,

Changelog:
v4 -> v5:

* Call v7 version of suspend and resume from the pj4b callback instead
  of copying the code, following Lorenzo advice.

* Split the low level functions to manipulate HW coherency

* Reorder the included headers in cpuidle-armada-370-xp.c

* Added comment in the inline asm part of armada_370_xp_cpu_suspend
  function where the CR_C is restored.

* Added comment about the fact that Armada XP can us ldrex/strex
  without MMU enabled

* Fixed commit logs

* Added the acked-by from Thomas Petazzoni

* Extend the pmsu registers instead of adding a new set of register

* Move the pm initialization outside of the board file in a
  arch_initcall

* Move most of the architecture specific code in arch/arm/mach-mvebu
  and use platform device data file to pass the callback as suggested
  by Daniel.

* Added the tlb flush if the wfi failed.

* Check the cpu_suspend return value

* rebased on mvebu/for-next to be in sync all the change made in mach-mvebu

v3 -> v4:

* factorized the code in coherency_ll.S and make it autodetect as mush
  as possible

* reordered the introduction of the device tree binding

* removed all the EXPORT_SYMBOL_GPL as the driver can only be built
  into the kernel and never be built as a module.

* moved the armada_370_xp_pmsu_enable_l2_powerdown_onidle function in
  armada_370_cp.c file during the initialization of the platform.

* fixed various coding style issue and typos pointed by Thomas

* fixed all the coding issue style, made the comments more coherent
  and add more comment in the suspend-armada-370-xp.S file.

* moved all the device tree related check from
  armada_370_xp_cpuidle_probe to armada_370_xp_dt_init.

* used cpu_pm_enter() instead of directly calling platform code in
  Armada_370_xp_enter_idle.

* convert the sequence to disable the coherency to the one used in
  TC2.

* Rebased on v3.14-rc1

v2 -> v3:

* Converted the driver to use module_platform_driver. This lead to the
  introduction of a new patch (PATCH 11). Pointed by Daniel Lezcano.

* Used PUIDLE_DRIVER_FLAGS_MASK to store the deep idle information,
  suggested by Daniel Lezcano.

* Removed cpu_init call from armada_370_xp_enter_idle
  function. Pointed by Lorenzo Pieralisi.

* Rebased on v3.12-rc5


v1 -> v2:

* Removed the pm_level kernel parameter. As Kevin Hilman pointed, its
  usage can be replaced by using
  /sys/devices/system/cpu/cpu*/cpuidle/state*/disable or the kernel
  parameter cpuidle.off.

* Used BIT() macro (reported by Ezequiel)

* Made the function more readable the
  armada_370_xp_pmsu_idle_prepare() function (reported by Thomas)

* Moved the config entry in Kconfig.arm, and rename the config symbol
  according the pattern used by other arm cpu: ARM_"soc name"_CPUIDLE

* Moved the build rule under the new ARM SoC section in the Makefile

* Rebased on Linus Torvalds master branch of Thursday September 12

Gregory CLEMENT (14):
  ARM: PJ4B: Add cpu_suspend/cpu_resume hooks for PJ4B
  ARM: mvebu: remove the address parameter for ll_set_cpu_coherent
  ARM: mvebu: ll_set_cpu_coherent always uses the current CPU
  ARM: mvebu: Remove the unused argument of set_cpu_coherent()
  ARM: mvebu: Split low level functions to manipulate HW coherency
  ARM: mvebu: Low level function to 

[PATCH v5 00/14] CPU idle for Armada XP

2014-03-25 Thread Gregory CLEMENT
Hello,

This patch set adds the CPU idle support for Armada XP and prepares
the support for Armada 370. This was based on the work of Nadav
Haklai.

As for the last version there were many changes done, see the
changelog for the details. And again I think that I should have
managed to comply with all the reviewer wishes.

A notable change is that patches 7 and 8 are here to have a coherent
series, but they will be part of a different series which will be send
soon, so don't focus too much on it. These 2 patches introduce a new
compatible string for PMSU which will be needed for CPU idle
(obviously) but also for the SMP support for Armada 375 and Armada
38x. So instead of having SMP for Armada 375/38x depending on CPU idle
for Armada XP or the opposite we choose to submit soon a small series
needed for those two bigger series.

Most of the patches modify the mvebu code in order to prepare the
support for CPU idle, hence the patches 2 to 6 and from 9 to 12 should
go to mvebu subsystem (and then arm-soc).

The first patch should go through ARM subsystem and should be taken by
Russell King. I made few change on it following Lorenzo advice and
now it will reuse the cpu v7 suspend and resume function and just do
specific operation before calling them.

The 13th patch 'cpuidle: mvebu: Add initial cpu idle support for
Armada 370/XP SoC' is the only one who should go to the cpuidle
subsystem. But of course I would like that Daniel Lezcano or Rafael
J. Wysocki have a look on the whole series and especially patches 10,
12 and 14.

The 14th patch should go to mvebu subsystem.

The whole series is also available in the branch CPU-idle-ArmadaXP-v5
at https://github.com/MISL-EBU-System-SW/mainline-public.git

Thanks,

Changelog:
v4 - v5:

* Call v7 version of suspend and resume from the pj4b callback instead
  of copying the code, following Lorenzo advice.

* Split the low level functions to manipulate HW coherency

* Reorder the included headers in cpuidle-armada-370-xp.c

* Added comment in the inline asm part of armada_370_xp_cpu_suspend
  function where the CR_C is restored.

* Added comment about the fact that Armada XP can us ldrex/strex
  without MMU enabled

* Fixed commit logs

* Added the acked-by from Thomas Petazzoni

* Extend the pmsu registers instead of adding a new set of register

* Move the pm initialization outside of the board file in a
  arch_initcall

* Move most of the architecture specific code in arch/arm/mach-mvebu
  and use platform device data file to pass the callback as suggested
  by Daniel.

* Added the tlb flush if the wfi failed.

* Check the cpu_suspend return value

* rebased on mvebu/for-next to be in sync all the change made in mach-mvebu

v3 - v4:

* factorized the code in coherency_ll.S and make it autodetect as mush
  as possible

* reordered the introduction of the device tree binding

* removed all the EXPORT_SYMBOL_GPL as the driver can only be built
  into the kernel and never be built as a module.

* moved the armada_370_xp_pmsu_enable_l2_powerdown_onidle function in
  armada_370_cp.c file during the initialization of the platform.

* fixed various coding style issue and typos pointed by Thomas

* fixed all the coding issue style, made the comments more coherent
  and add more comment in the suspend-armada-370-xp.S file.

* moved all the device tree related check from
  armada_370_xp_cpuidle_probe to armada_370_xp_dt_init.

* used cpu_pm_enter() instead of directly calling platform code in
  Armada_370_xp_enter_idle.

* convert the sequence to disable the coherency to the one used in
  TC2.

* Rebased on v3.14-rc1

v2 - v3:

* Converted the driver to use module_platform_driver. This lead to the
  introduction of a new patch (PATCH 11). Pointed by Daniel Lezcano.

* Used PUIDLE_DRIVER_FLAGS_MASK to store the deep idle information,
  suggested by Daniel Lezcano.

* Removed cpu_init call from armada_370_xp_enter_idle
  function. Pointed by Lorenzo Pieralisi.

* Rebased on v3.12-rc5


v1 - v2:

* Removed the pm_level kernel parameter. As Kevin Hilman pointed, its
  usage can be replaced by using
  /sys/devices/system/cpu/cpu*/cpuidle/state*/disable or the kernel
  parameter cpuidle.off.

* Used BIT() macro (reported by Ezequiel)

* Made the function more readable the
  armada_370_xp_pmsu_idle_prepare() function (reported by Thomas)

* Moved the config entry in Kconfig.arm, and rename the config symbol
  according the pattern used by other arm cpu: ARM_soc name_CPUIDLE

* Moved the build rule under the new ARM SoC section in the Makefile

* Rebased on Linus Torvalds master branch of Thursday September 12

Gregory CLEMENT (14):
  ARM: PJ4B: Add cpu_suspend/cpu_resume hooks for PJ4B
  ARM: mvebu: remove the address parameter for ll_set_cpu_coherent
  ARM: mvebu: ll_set_cpu_coherent always uses the current CPU
  ARM: mvebu: Remove the unused argument of set_cpu_coherent()
  ARM: mvebu: Split low level functions to manipulate HW coherency
  ARM: mvebu: Low level function to disable 

Re: [PATCH v5 00/14] CPU idle for Armada XP

2014-03-25 Thread Jason Cooper
Gregory,

On Tue, Mar 25, 2014 at 11:48:11PM +0100, Gregory CLEMENT wrote:
...
 The first patch should go through ARM subsystem and should be taken by
 Russell King. I made few change on it following Lorenzo advice and
 now it will reuse the cpu v7 suspend and resume function and just do
 specific operation before calling them.
 
 The 13th patch 'cpuidle: mvebu: Add initial cpu idle support for
 Armada 370/XP SoC' is the only one who should go to the cpuidle
 subsystem. But of course I would like that Daniel Lezcano or Rafael
 J. Wysocki have a look on the whole series and especially patches 10,
 12 and 14.

Ok, I'm tired.  :)  Help me out here.  Patches 1 and 13 are depended on
by the other patches and vice-versa, right?  In that case, I'm thinking
it's best to seek Acks from the other maintainers and keep the whole
branch together.  Please tell me if I'm wrong.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/