Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
On Fri, Aug 28, 2015 at 6:12 PM, Krzysztof Kozlowskiwrote: > W dniu 28.08.2015 o 17:35, Javier Martinez Canillas pisze: >> >> Ok, I'll see if I can take a look what is needed to implement a Exynos542x >> CPUidle >> driver. I'm quite busy with other stuff right now but I should be less busy >> in a >> couple of weeks. > > The only useful users of Exynos542x cpuidle would be Chromebooks. > Probably the same goes with suspend to RAM. Non-mobile devices could > leave without it. > > In the same time cpuidle and S2R would require a significant amount of > work. Testing would have to be performed on Chromebooks. I have doubts > it would work on Odroid XU3. > > I dug into S2R issues on Odroid XU3 and after fixing trivial imprecise > abort I don't have clue. It just dies somewhere in firmware/bootloader. > Vendor code has a lot more stuff related to suspend and testing it > one-by-one whether it fixes the issue is frustrating. > > Do we really need cpuidle or S2R on Exynos542x/5800? Cpuidle support on Odroid-XU3 and Peach-Pi would be useful for general PM/scheduler work on big.LITTLE systems. On the Odroid, it has the additional benefit of allowing power measurements, which helps. Regards, Amit -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hello Bartlomiej and Lorenzo, Thanks a lot for your explanations. On 08/27/2015 06:58 PM, Bartlomiej Zolnierkiewicz wrote: Hi, On Tuesday, August 25, 2015 05:09:32 PM Lorenzo Pieralisi wrote: On Tue, Aug 25, 2015 at 03:35:29PM +0100, Bartlomiej Zolnierkiewicz wrote: [ added Lorenzo and linux-pm to Cc: ] Hi, On Tuesday, August 25, 2015 11:43:38 AM Javier Martinez Canillas wrote: [adding Kevin Hilman as cc who was also interested in CPUidle for Exynos] Hello Krzysztof, On 08/23/2015 03:26 AM, Krzysztof Kozlowski wrote: [snip] 2015-08-21 16:21 GMT+09:00 Javier Martinez Canillas jav...@osg.samsung.com: The big.LITTLE cpuidle driver is not a typical Exynos cpuidle driver. It only executes CPU suspend on a cluster which essentially is a power down operation. You are correct, looking at the the big.LITTLE CPUidle driver I see that it only has two C-states: C0 (normal WFI) and C1 (single CPU power-down) which as you said, places the CPU into power-down mode by using the MCPM infrastructure so it's basically a CPU suspend AFAIU. So what you are saying is that there are deeper C-states supported by the Exynos 542x SoC family but these are not handled by the b.L CPUidle driver. When we talk about cpuidle on Exynos, we have in mind one of sleep modes: AFTR or LPA (sometimes instead of LPA there is LPD or W-AFTR). Actually this is more like a system idle mode, not CPU idle. The power savings are much bigger than disabling only one cluster. Interesting, I was not aware of AFTR and LPA but I looked in the manual now. Thanks a lot for the information. I see that the Exynos CPUidle driver (drivers/cpuidle/cpuidle-exynos.c) also has only two C-states (WFI and C1) but C1 makes the system to enter in AFTR (system-level power gating). This is similar to what the downstream ChromiumOS 3.8 kernel CPUidle driver does IIUC [0]. Yes but upstream does it in a clean way, has support for platforms requiring secure firmware operations and also implements coupled AFTR mode on a few platforms. So the question is still valid - whether someone wants or plans to implement cpuidle for Exynos 542x family. Odroid XU3 is not a priority here because energy consumption is not an issue there. This is not a mobile device. That's true but it will be interesting for the 5420 and 5800 based Chromebooks since optimizing power consumption would be useful there. I would be happy to help with reviewing patches etc. but personally I don't have any plans for doing this work. I may look into adding support for newer ARM64 SoCs (Exynos5433) if I find some extra time (quite unlikely currently). I thought that big.LITTLE platforms were encouraged to use the generic b.L CPUidle driver just like DT platforms should use the generic CPUFreq DT driver but I guess I misunderstood. So the b.L CPUidle driver is only to have minimum CPUidle support but a SoC specific driver is needed to fine tune and get most out of the platform? Or should the b.L CPUidle driver be extended to add per platform C-states? This is a good question. Daniel/Lorenzo? To move the b.L driver to multiple C-states we should first convert it to the generic CPUidle driver (by defining an MCPM enable-method): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/cpuidle/cpuidle-arm.c?id=refs/tags/v4.2-rc8 Then we have to figure out how to determine how many CPUidle drivers we have to create (since idle states are different on different CPUs), since using the MIDR does not really scale. For certain I won't support coupled C-states in the DT idle states code, and every platform requiring them is considered buggy and not worth merging in the mainline kernel from now onwards, HW should be fixed, eventually, I am not willing to see code like drivers/cpuidle/cpuidle-exynos.c in the mainline kernel anymore, I am sorry. For Exynos chipsets coupled C-states are not strictly required for having cpuidle support but make it more useful. On Exynos chipsets secondary CPUs must be disabled to allow system to go into deeper idle modes and this is assured by using coupled C-states. Original Android drivers don't use coupled C-states and depend on the rest of the system to offline secondary CPUs when not needed. I would of course prefer not to have handle this in software and be automatically handled by hardware/firmware but that doesn't mean that we should be declining mainline support for ugly hardware (this has never been the Linux way of doing things). Coming back to the platforms in question (ARM32 big.LITTLE based Odroid XU3 boards etc.) they have been shipped long time ago and the best we can do nowadays is to support them as well as possible. I agree. If somebody wants to implement a separate Exynos542x/Exynos5800 big.LITTLE cpuidle driver for them I see no problem with it and I'm willing to help in maintaining it. Ok, I'll see if I can take a look what
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
W dniu 28.08.2015 o 17:35, Javier Martinez Canillas pisze: Hello Bartlomiej and Lorenzo, Thanks a lot for your explanations. On 08/27/2015 06:58 PM, Bartlomiej Zolnierkiewicz wrote: If somebody wants to implement a separate Exynos542x/Exynos5800 big.LITTLE cpuidle driver for them I see no problem with it and I'm willing to help in maintaining it. Ok, I'll see if I can take a look what is needed to implement a Exynos542x CPUidle driver. I'm quite busy with other stuff right now but I should be less busy in a couple of weeks. The only useful users of Exynos542x cpuidle would be Chromebooks. Probably the same goes with suspend to RAM. Non-mobile devices could leave without it. In the same time cpuidle and S2R would require a significant amount of work. Testing would have to be performed on Chromebooks. I have doubts it would work on Odroid XU3. I dug into S2R issues on Odroid XU3 and after fixing trivial imprecise abort I don't have clue. It just dies somewhere in firmware/bootloader. Vendor code has a lot more stuff related to suspend and testing it one-by-one whether it fixes the issue is frustrating. Do we really need cpuidle or S2R on Exynos542x/5800? Maybe is a little bit out of topic but since Anand also asked about CPUFreq support, are you planning on re-posting your cpufreq: add generic cpufreq driver support for Exynos5250/5800 platforms [0] series? That would be useful. Bartlomiej, do you have plans for continuing the work? Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hi, On Friday, August 28, 2015 09:42:35 PM Krzysztof Kozlowski wrote: W dniu 28.08.2015 o 17:35, Javier Martinez Canillas pisze: Hello Bartlomiej and Lorenzo, Thanks a lot for your explanations. On 08/27/2015 06:58 PM, Bartlomiej Zolnierkiewicz wrote: If somebody wants to implement a separate Exynos542x/Exynos5800 big.LITTLE cpuidle driver for them I see no problem with it and I'm willing to help in maintaining it. Ok, I'll see if I can take a look what is needed to implement a Exynos542x CPUidle driver. I'm quite busy with other stuff right now but I should be less busy in a couple of weeks. The only useful users of Exynos542x cpuidle would be Chromebooks. Probably the same goes with suspend to RAM. Non-mobile devices could leave without it. In the same time cpuidle and S2R would require a significant amount of work. Testing would have to be performed on Chromebooks. I have doubts it would work on Odroid XU3. I dug into S2R issues on Odroid XU3 and after fixing trivial imprecise abort I don't have clue. It just dies somewhere in firmware/bootloader. Vendor code has a lot more stuff related to suspend and testing it one-by-one whether it fixes the issue is frustrating. Do we really need cpuidle or S2R on Exynos542x/5800? Maybe is a little bit out of topic but since Anand also asked about CPUFreq support, are you planning on re-posting your cpufreq: add generic cpufreq driver support for Exynos5250/5800 platforms [0] series? That would be useful. Bartlomiej, do you have plans for continuing the work? Yes. It is still on my TODO but may take a while (1-2 weeks) before I find some time to actually do it. Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hi, On Tuesday, August 25, 2015 05:09:32 PM Lorenzo Pieralisi wrote: On Tue, Aug 25, 2015 at 03:35:29PM +0100, Bartlomiej Zolnierkiewicz wrote: [ added Lorenzo and linux-pm to Cc: ] Hi, On Tuesday, August 25, 2015 11:43:38 AM Javier Martinez Canillas wrote: [adding Kevin Hilman as cc who was also interested in CPUidle for Exynos] Hello Krzysztof, On 08/23/2015 03:26 AM, Krzysztof Kozlowski wrote: [snip] 2015-08-21 16:21 GMT+09:00 Javier Martinez Canillas jav...@osg.samsung.com: The big.LITTLE cpuidle driver is not a typical Exynos cpuidle driver. It only executes CPU suspend on a cluster which essentially is a power down operation. You are correct, looking at the the big.LITTLE CPUidle driver I see that it only has two C-states: C0 (normal WFI) and C1 (single CPU power-down) which as you said, places the CPU into power-down mode by using the MCPM infrastructure so it's basically a CPU suspend AFAIU. So what you are saying is that there are deeper C-states supported by the Exynos 542x SoC family but these are not handled by the b.L CPUidle driver. When we talk about cpuidle on Exynos, we have in mind one of sleep modes: AFTR or LPA (sometimes instead of LPA there is LPD or W-AFTR). Actually this is more like a system idle mode, not CPU idle. The power savings are much bigger than disabling only one cluster. Interesting, I was not aware of AFTR and LPA but I looked in the manual now. Thanks a lot for the information. I see that the Exynos CPUidle driver (drivers/cpuidle/cpuidle-exynos.c) also has only two C-states (WFI and C1) but C1 makes the system to enter in AFTR (system-level power gating). This is similar to what the downstream ChromiumOS 3.8 kernel CPUidle driver does IIUC [0]. Yes but upstream does it in a clean way, has support for platforms requiring secure firmware operations and also implements coupled AFTR mode on a few platforms. So the question is still valid - whether someone wants or plans to implement cpuidle for Exynos 542x family. Odroid XU3 is not a priority here because energy consumption is not an issue there. This is not a mobile device. That's true but it will be interesting for the 5420 and 5800 based Chromebooks since optimizing power consumption would be useful there. I would be happy to help with reviewing patches etc. but personally I don't have any plans for doing this work. I may look into adding support for newer ARM64 SoCs (Exynos5433) if I find some extra time (quite unlikely currently). I thought that big.LITTLE platforms were encouraged to use the generic b.L CPUidle driver just like DT platforms should use the generic CPUFreq DT driver but I guess I misunderstood. So the b.L CPUidle driver is only to have minimum CPUidle support but a SoC specific driver is needed to fine tune and get most out of the platform? Or should the b.L CPUidle driver be extended to add per platform C-states? This is a good question. Daniel/Lorenzo? To move the b.L driver to multiple C-states we should first convert it to the generic CPUidle driver (by defining an MCPM enable-method): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/cpuidle/cpuidle-arm.c?id=refs/tags/v4.2-rc8 Then we have to figure out how to determine how many CPUidle drivers we have to create (since idle states are different on different CPUs), since using the MIDR does not really scale. For certain I won't support coupled C-states in the DT idle states code, and every platform requiring them is considered buggy and not worth merging in the mainline kernel from now onwards, HW should be fixed, eventually, I am not willing to see code like drivers/cpuidle/cpuidle-exynos.c in the mainline kernel anymore, I am sorry. For Exynos chipsets coupled C-states are not strictly required for having cpuidle support but make it more useful. On Exynos chipsets secondary CPUs must be disabled to allow system to go into deeper idle modes and this is assured by using coupled C-states. Original Android drivers don't use coupled C-states and depend on the rest of the system to offline secondary CPUs when not needed. I would of course prefer not to have handle this in software and be automatically handled by hardware/firmware but that doesn't mean that we should be declining mainline support for ugly hardware (this has never been the Linux way of doing things). Coming back to the platforms in question (ARM32 big.LITTLE based Odroid XU3 boards etc.) they have been shipped long time ago and the best we can do nowadays is to support them as well as possible. If somebody wants to implement a separate Exynos542x/Exynos5800 big.LITTLE cpuidle driver for them I see no problem with it and I'm willing to help in maintaining it. I
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
[ added Lorenzo and linux-pm to Cc: ] Hi, On Tuesday, August 25, 2015 11:43:38 AM Javier Martinez Canillas wrote: [adding Kevin Hilman as cc who was also interested in CPUidle for Exynos] Hello Krzysztof, On 08/23/2015 03:26 AM, Krzysztof Kozlowski wrote: [snip] 2015-08-21 16:21 GMT+09:00 Javier Martinez Canillas jav...@osg.samsung.com: The big.LITTLE cpuidle driver is not a typical Exynos cpuidle driver. It only executes CPU suspend on a cluster which essentially is a power down operation. You are correct, looking at the the big.LITTLE CPUidle driver I see that it only has two C-states: C0 (normal WFI) and C1 (single CPU power-down) which as you said, places the CPU into power-down mode by using the MCPM infrastructure so it's basically a CPU suspend AFAIU. So what you are saying is that there are deeper C-states supported by the Exynos 542x SoC family but these are not handled by the b.L CPUidle driver. When we talk about cpuidle on Exynos, we have in mind one of sleep modes: AFTR or LPA (sometimes instead of LPA there is LPD or W-AFTR). Actually this is more like a system idle mode, not CPU idle. The power savings are much bigger than disabling only one cluster. Interesting, I was not aware of AFTR and LPA but I looked in the manual now. Thanks a lot for the information. I see that the Exynos CPUidle driver (drivers/cpuidle/cpuidle-exynos.c) also has only two C-states (WFI and C1) but C1 makes the system to enter in AFTR (system-level power gating). This is similar to what the downstream ChromiumOS 3.8 kernel CPUidle driver does IIUC [0]. Yes but upstream does it in a clean way, has support for platforms requiring secure firmware operations and also implements coupled AFTR mode on a few platforms. So the question is still valid - whether someone wants or plans to implement cpuidle for Exynos 542x family. Odroid XU3 is not a priority here because energy consumption is not an issue there. This is not a mobile device. That's true but it will be interesting for the 5420 and 5800 based Chromebooks since optimizing power consumption would be useful there. I would be happy to help with reviewing patches etc. but personally I don't have any plans for doing this work. I may look into adding support for newer ARM64 SoCs (Exynos5433) if I find some extra time (quite unlikely currently). I thought that big.LITTLE platforms were encouraged to use the generic b.L CPUidle driver just like DT platforms should use the generic CPUFreq DT driver but I guess I misunderstood. So the b.L CPUidle driver is only to have minimum CPUidle support but a SoC specific driver is needed to fine tune and get most out of the platform? Or should the b.L CPUidle driver be extended to add per platform C-states? This is a good question. Daniel/Lorenzo? Best regards, Krzysztof [0]: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/cpuidle.c Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
On Tue, Aug 25, 2015 at 03:35:29PM +0100, Bartlomiej Zolnierkiewicz wrote: [ added Lorenzo and linux-pm to Cc: ] Hi, On Tuesday, August 25, 2015 11:43:38 AM Javier Martinez Canillas wrote: [adding Kevin Hilman as cc who was also interested in CPUidle for Exynos] Hello Krzysztof, On 08/23/2015 03:26 AM, Krzysztof Kozlowski wrote: [snip] 2015-08-21 16:21 GMT+09:00 Javier Martinez Canillas jav...@osg.samsung.com: The big.LITTLE cpuidle driver is not a typical Exynos cpuidle driver. It only executes CPU suspend on a cluster which essentially is a power down operation. You are correct, looking at the the big.LITTLE CPUidle driver I see that it only has two C-states: C0 (normal WFI) and C1 (single CPU power-down) which as you said, places the CPU into power-down mode by using the MCPM infrastructure so it's basically a CPU suspend AFAIU. So what you are saying is that there are deeper C-states supported by the Exynos 542x SoC family but these are not handled by the b.L CPUidle driver. When we talk about cpuidle on Exynos, we have in mind one of sleep modes: AFTR or LPA (sometimes instead of LPA there is LPD or W-AFTR). Actually this is more like a system idle mode, not CPU idle. The power savings are much bigger than disabling only one cluster. Interesting, I was not aware of AFTR and LPA but I looked in the manual now. Thanks a lot for the information. I see that the Exynos CPUidle driver (drivers/cpuidle/cpuidle-exynos.c) also has only two C-states (WFI and C1) but C1 makes the system to enter in AFTR (system-level power gating). This is similar to what the downstream ChromiumOS 3.8 kernel CPUidle driver does IIUC [0]. Yes but upstream does it in a clean way, has support for platforms requiring secure firmware operations and also implements coupled AFTR mode on a few platforms. So the question is still valid - whether someone wants or plans to implement cpuidle for Exynos 542x family. Odroid XU3 is not a priority here because energy consumption is not an issue there. This is not a mobile device. That's true but it will be interesting for the 5420 and 5800 based Chromebooks since optimizing power consumption would be useful there. I would be happy to help with reviewing patches etc. but personally I don't have any plans for doing this work. I may look into adding support for newer ARM64 SoCs (Exynos5433) if I find some extra time (quite unlikely currently). I thought that big.LITTLE platforms were encouraged to use the generic b.L CPUidle driver just like DT platforms should use the generic CPUFreq DT driver but I guess I misunderstood. So the b.L CPUidle driver is only to have minimum CPUidle support but a SoC specific driver is needed to fine tune and get most out of the platform? Or should the b.L CPUidle driver be extended to add per platform C-states? This is a good question. Daniel/Lorenzo? To move the b.L driver to multiple C-states we should first convert it to the generic CPUidle driver (by defining an MCPM enable-method): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/cpuidle/cpuidle-arm.c?id=refs/tags/v4.2-rc8 Then we have to figure out how to determine how many CPUidle drivers we have to create (since idle states are different on different CPUs), since using the MIDR does not really scale. For certain I won't support coupled C-states in the DT idle states code, and every platform requiring them is considered buggy and not worth merging in the mainline kernel from now onwards, HW should be fixed, eventually, I am not willing to see code like drivers/cpuidle/cpuidle-exynos.c in the mainline kernel anymore, I am sorry. I think it is time to draw a line with CPUidle on ARM, take stock, clean it up and find a way forward, current situation is a potpourri of solutions that all differ in a slightly incompatible way. Support on ARM64 SoC must be PSCI based and for that there is already support in the mainline kernel (through the PSCI back-end and the DT idle states bindings). Lorenzo -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
[adding Kevin Hilman as cc who was also interested in CPUidle for Exynos] Hello Krzysztof, On 08/23/2015 03:26 AM, Krzysztof Kozlowski wrote: [snip] 2015-08-21 16:21 GMT+09:00 Javier Martinez Canillas jav...@osg.samsung.com: The big.LITTLE cpuidle driver is not a typical Exynos cpuidle driver. It only executes CPU suspend on a cluster which essentially is a power down operation. You are correct, looking at the the big.LITTLE CPUidle driver I see that it only has two C-states: C0 (normal WFI) and C1 (single CPU power-down) which as you said, places the CPU into power-down mode by using the MCPM infrastructure so it's basically a CPU suspend AFAIU. So what you are saying is that there are deeper C-states supported by the Exynos 542x SoC family but these are not handled by the b.L CPUidle driver. When we talk about cpuidle on Exynos, we have in mind one of sleep modes: AFTR or LPA (sometimes instead of LPA there is LPD or W-AFTR). Actually this is more like a system idle mode, not CPU idle. The power savings are much bigger than disabling only one cluster. Interesting, I was not aware of AFTR and LPA but I looked in the manual now. Thanks a lot for the information. I see that the Exynos CPUidle driver (drivers/cpuidle/cpuidle-exynos.c) also has only two C-states (WFI and C1) but C1 makes the system to enter in AFTR (system-level power gating). This is similar to what the downstream ChromiumOS 3.8 kernel CPUidle driver does IIUC [0]. So the question is still valid - whether someone wants or plans to implement cpuidle for Exynos 542x family. Odroid XU3 is not a priority here because energy consumption is not an issue there. This is not a mobile device. That's true but it will be interesting for the 5420 and 5800 based Chromebooks since optimizing power consumption would be useful there. I thought that big.LITTLE platforms were encouraged to use the generic b.L CPUidle driver just like DT platforms should use the generic CPUFreq DT driver but I guess I misunderstood. So the b.L CPUidle driver is only to have minimum CPUidle support but a SoC specific driver is needed to fine tune and get most out of the platform? Or should the b.L CPUidle driver be extended to add per platform C-states? Best regards, Krzysztof [0]: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/cpuidle.c Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hi all, On 08/21/2015 09:21 AM, Javier Martinez Canillas wrote: [Adding Przemyslaw Marczak who was working on porting Odroid BL1/BL2/SPL] This work is currently on hold, but the mainline spl support will not solve early-boot issues caused by cpu running in a non-secure state. But I think, that still some hacking is possible, and will continue a research on it later, when I finish some more important tasks. Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com Hello, On 08/21/2015 05:59 AM, Krzysztof Kozlowski wrote: On 21.08.2015 12:41, Anand Moon wrote: Hi Krzysztof, On 21 August 2015 at 06:25, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 21.08.2015 03:15, Anand Moon wrote: Hi Daniel, On 20 August 2015 at 21:40, Daniel Lezcano daniel.lezc...@free.fr wrote: On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html Thanks for the explanation. I was just referring following the source code. https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/mach-exynos/cpuidle-exynos5422.c It seem that cpufreq and cpuidle go hand in hand. Bartlomiej was working on cpufreq for Exynos542x: http://lkml.iu.edu/hypermail/linux/kernel/1504.2/03139.html It would be nice to have also cpuidle and suspend features working on Exynos542x family but this depends on firmware. Some time ago I struggled with suspend on Arndale Octa (Exynos5420) and I failed. I think the firmware is the issue here. There were a lot of Suspend-to-RAM bug fixes lately mostly related to critical clocks being gated. It would be nice to give a try on recent kernels and see if is still not working. Actually I am not sure what is your question Anand. You are asking if someone plans to do this? Yes I am asking are their plans to implement cpufreq and cpuidle simultaneously. There are no obstacles for implementing them simultaneously so the question is rather who plans to do the cpuidle driver for Exynos542x? I If the firmware is in a good shape (unfortunately as mentioned by Daniel, the one in the Odroids are not) then the generic ARM big.LITTLE CPUidle driver (CONFIG_ARM_BIG_LITTLE_CPUIDLE) should work. It is at least working for me on the Exynos5800 based Peach Pi Chromebook: $ cat /sys/devices/system/cpu/cpuidle/current_driver big_idle $ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name WFI C1 $ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/usage 7745 10578 don't... at least in nearby future. If I had some spare time then probably I would try to make suspend working. Suspend-to-RAM is at least working on the Exynos5420 and Exynos5800 Chromebooks. As you mentioned it may depend on the firmware so that does not hold true for all the Exynos5420/5422/5800 boards but it would be good to know what is the causing S2R to fail. Best regards, Krzysztof Best regards, -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
2015-08-21 16:21 GMT+09:00 Javier Martinez Canillas jav...@osg.samsung.com: [Adding Przemyslaw Marczak who was working on porting Odroid BL1/BL2/SPL] Hello, On 08/21/2015 05:59 AM, Krzysztof Kozlowski wrote: On 21.08.2015 12:41, Anand Moon wrote: Hi Krzysztof, On 21 August 2015 at 06:25, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 21.08.2015 03:15, Anand Moon wrote: Hi Daniel, On 20 August 2015 at 21:40, Daniel Lezcano daniel.lezc...@free.fr wrote: On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html Thanks for the explanation. I was just referring following the source code. https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/mach-exynos/cpuidle-exynos5422.c It seem that cpufreq and cpuidle go hand in hand. Bartlomiej was working on cpufreq for Exynos542x: http://lkml.iu.edu/hypermail/linux/kernel/1504.2/03139.html It would be nice to have also cpuidle and suspend features working on Exynos542x family but this depends on firmware. Some time ago I struggled with suspend on Arndale Octa (Exynos5420) and I failed. I think the firmware is the issue here. There were a lot of Suspend-to-RAM bug fixes lately mostly related to critical clocks being gated. It would be nice to give a try on recent kernels and see if is still not working. Actually I am not sure what is your question Anand. You are asking if someone plans to do this? Yes I am asking are their plans to implement cpufreq and cpuidle simultaneously. There are no obstacles for implementing them simultaneously so the question is rather who plans to do the cpuidle driver for Exynos542x? I If the firmware is in a good shape (unfortunately as mentioned by Daniel, the one in the Odroids are not) then the generic ARM big.LITTLE CPUidle driver (CONFIG_ARM_BIG_LITTLE_CPUIDLE) should work. It is at least working for me on the Exynos5800 based Peach Pi Chromebook: $ cat /sys/devices/system/cpu/cpuidle/current_driver big_idle $ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name WFI C1 $ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/usage 7745 10578 don't... at least in nearby future. If I had some spare time then probably I would try to make suspend working. Suspend-to-RAM is at least working on the Exynos5420 and Exynos5800 Chromebooks. The big.LITTLE cpuidle driver is not a typical Exynos cpuidle driver. It only executes CPU suspend on a cluster which essentially is a power down operation. When we talk about cpuidle on Exynos, we have in mind one of sleep modes: AFTR or LPA (sometimes instead of LPA there is LPD or W-AFTR). Actually this is more like a system idle mode, not CPU idle. The power savings are much bigger than disabling only one cluster. So the question is still valid - whether someone wants or plans to implement cpuidle for Exynos 542x family. Odroid XU3 is not a priority here because energy consumption is not an issue there. This is not a mobile device. Best regards, Krzysztof As you mentioned it may depend on the firmware so that does not hold true for all the Exynos5420/5422/5800 boards but it would be good to know what is the causing S2R to fail. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
[Adding Przemyslaw Marczak who was working on porting Odroid BL1/BL2/SPL] Hello, On 08/21/2015 05:59 AM, Krzysztof Kozlowski wrote: On 21.08.2015 12:41, Anand Moon wrote: Hi Krzysztof, On 21 August 2015 at 06:25, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 21.08.2015 03:15, Anand Moon wrote: Hi Daniel, On 20 August 2015 at 21:40, Daniel Lezcano daniel.lezc...@free.fr wrote: On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html Thanks for the explanation. I was just referring following the source code. https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/mach-exynos/cpuidle-exynos5422.c It seem that cpufreq and cpuidle go hand in hand. Bartlomiej was working on cpufreq for Exynos542x: http://lkml.iu.edu/hypermail/linux/kernel/1504.2/03139.html It would be nice to have also cpuidle and suspend features working on Exynos542x family but this depends on firmware. Some time ago I struggled with suspend on Arndale Octa (Exynos5420) and I failed. I think the firmware is the issue here. There were a lot of Suspend-to-RAM bug fixes lately mostly related to critical clocks being gated. It would be nice to give a try on recent kernels and see if is still not working. Actually I am not sure what is your question Anand. You are asking if someone plans to do this? Yes I am asking are their plans to implement cpufreq and cpuidle simultaneously. There are no obstacles for implementing them simultaneously so the question is rather who plans to do the cpuidle driver for Exynos542x? I If the firmware is in a good shape (unfortunately as mentioned by Daniel, the one in the Odroids are not) then the generic ARM big.LITTLE CPUidle driver (CONFIG_ARM_BIG_LITTLE_CPUIDLE) should work. It is at least working for me on the Exynos5800 based Peach Pi Chromebook: $ cat /sys/devices/system/cpu/cpuidle/current_driver big_idle $ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name WFI C1 $ cat /sys/devices/system/cpu/cpu0/cpuidle/state*/usage 7745 10578 don't... at least in nearby future. If I had some spare time then probably I would try to make suspend working. Suspend-to-RAM is at least working on the Exynos5420 and Exynos5800 Chromebooks. As you mentioned it may depend on the firmware so that does not hold true for all the Exynos5420/5422/5800 boards but it would be good to know what is the causing S2R to fail. Best regards, Krzysztof Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hi Krzysztof, On 21 August 2015 at 06:25, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 21.08.2015 03:15, Anand Moon wrote: Hi Daniel, On 20 August 2015 at 21:40, Daniel Lezcano daniel.lezc...@free.fr wrote: On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html Thanks for the explanation. I was just referring following the source code. https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/mach-exynos/cpuidle-exynos5422.c It seem that cpufreq and cpuidle go hand in hand. Bartlomiej was working on cpufreq for Exynos542x: http://lkml.iu.edu/hypermail/linux/kernel/1504.2/03139.html It would be nice to have also cpuidle and suspend features working on Exynos542x family but this depends on firmware. Some time ago I struggled with suspend on Arndale Octa (Exynos5420) and I failed. I think the firmware is the issue here. Actually I am not sure what is your question Anand. You are asking if someone plans to do this? Yes I am asking are their plans to implement cpufreq and cpuidle simultaneously. -Anand Moon Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. -Anand Moon -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
On 21.08.2015 03:15, Anand Moon wrote: Hi Daniel, On 20 August 2015 at 21:40, Daniel Lezcano daniel.lezc...@free.fr wrote: On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html Thanks for the explanation. I was just referring following the source code. https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/mach-exynos/cpuidle-exynos5422.c It seem that cpufreq and cpuidle go hand in hand. Bartlomiej was working on cpufreq for Exynos542x: http://lkml.iu.edu/hypermail/linux/kernel/1504.2/03139.html It would be nice to have also cpuidle and suspend features working on Exynos542x family but this depends on firmware. Some time ago I struggled with suspend on Arndale Octa (Exynos5420) and I failed. I think the firmware is the issue here. Actually I am not sure what is your question Anand. You are asking if someone plans to do this? Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
On 08/20/2015 08:15 PM, Anand Moon wrote: Hi Daniel, On 20 August 2015 at 21:40, Daniel Lezcano daniel.lezc...@free.fr wrote: On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html Thanks for the explanation. I was just referring following the source code. https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/mach-exynos/cpuidle-exynos5422.c Ah, thanks for the pointer. So for my information, is that driver not working with the exynos5422 ? It seem that cpufreq and cpuidle go hand in hand. At the first glance, there is a dependency with the cluster power state. It is not allowed to enter the cluster power down if another subsystem deny it. The driver itself is a pack of hacks based on cpuidle legacy code and wildly backported from older kernels with arbitrary latency and residency values. -- 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 linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hi Daniel, On 20 August 2015 at 21:40, Daniel Lezcano daniel.lezc...@free.fr wrote: On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html Thanks for the explanation. I was just referring following the source code. https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/mach-exynos/cpuidle-exynos5422.c It seem that cpufreq and cpuidle go hand in hand. -Anand Moon -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
On 21.08.2015 12:41, Anand Moon wrote: Hi Krzysztof, On 21 August 2015 at 06:25, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On 21.08.2015 03:15, Anand Moon wrote: Hi Daniel, On 20 August 2015 at 21:40, Daniel Lezcano daniel.lezc...@free.fr wrote: On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html Thanks for the explanation. I was just referring following the source code. https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/mach-exynos/cpuidle-exynos5422.c It seem that cpufreq and cpuidle go hand in hand. Bartlomiej was working on cpufreq for Exynos542x: http://lkml.iu.edu/hypermail/linux/kernel/1504.2/03139.html It would be nice to have also cpuidle and suspend features working on Exynos542x family but this depends on firmware. Some time ago I struggled with suspend on Arndale Octa (Exynos5420) and I failed. I think the firmware is the issue here. Actually I am not sure what is your question Anand. You are asking if someone plans to do this? Yes I am asking are their plans to implement cpufreq and cpuidle simultaneously. There are no obstacles for implementing them simultaneously so the question is rather who plans to do the cpuidle driver for Exynos542x? I don't... at least in nearby future. If I had some spare time then probably I would try to make suspend working. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
On 08/20/2015 12:54 PM, Anand Moon wrote: Hello Krzysztof/Kukjim, CPUIdle seen to be not working for Exynos5422 Odroid boards. Is their any way this feature will be implemented in the future. Yeah a good willing to fix the bl1. More than one year asking for that ! nooo way !! Your answer is at the end of http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html